CLAUDE.md — LLM Wiki Schema

This file is the Schema Layer of the CMDS LLM Wiki. It governs how LLMs (Claude Code, Cursor, etc.) read, write, and maintain this vault.

Architecture: Karpathy LLM Wiki Pattern

Raw Sources = 소스코드 (immutable)

Wiki = 실행 파일 (LLM이 관리)

Schema = 이 문서 (CLAUDE.md)

⚠️ CRITICAL RULES

Indentation Rules

YAML frontmatter: 2 SPACES (절대 탭 금지)
Markdown body: TAB (절대 스페이스 금지)

Wikilink Rules

YAML 내 wikilinks는 반드시 큰따옴표: "[[link]]"
Markdown body에서는 따옴표 없이: [[link]]

Description Rule

description 값은 항상 큰따옴표로 감쌀 것 — 값에 콜론(: )·엠대시(—)·괄호·#·wikilink 등이 들면 unquoted YAML 은 파싱 에러로 노트 전체가 렌더 실패한다.
- ✅ description: "RLHF: 인간 피드백 기반 정렬 (3단계)."
- ❌ description: RLHF: 인간 피드백 기반 정렬 (3단계).
값 안에 " 가 있으면 \" 이스케이프하거나 문장을 재작성. 빈 값도 description: "".

Provenance Rule (author + model + effort)

에이전트가 쓰는 모든 콘텐츠 페이지(raw-source·wiki-page·research-question·query-result·synthesis·moc·inbox·paper-hub·paper-analysis)는 author 바로 뒤에 model·effort 를 항상 기록 — Claude Code·Codex·Grok 가 누가·어떤 모델·어떤 강도로 썼는지 교차 확인.
- model: 상세 모델 id (claude-opus-4-8, claude-sonnet-5, gpt-5.4-codex, grok-4 …). 복수 기여 시 list.
- effort: 추론 강도/모드 (low/medium/high/xhigh/max 또는 타 에이전트 등가). 미상은 default.
- harness 정의 파일(command/skill)의 자기 frontmatter 엔 넣지 않음 — Description Rule 만 적용.

Mermaid Rules

모든 노드/엣지 라벨은 큰따옴표로 감쌀 것 — 한글·특수문자 안정성
- ✅ A["시작"] --> B{"선택?"}
- ❌ A[시작] --> B{선택?}
[/ 로 시작하는 라벨 금지 — trapezoid 도형 기호로 파싱됨 (lexical error)
- ❌ C[/query 스킬]
- ✅ C["/query 스킬"] 또는 C["query 스킬"]
엣지 라벨도 따옴표 권장: B -->|"한글 라벨"| C
라벨 안에 마크다운(**bold**, [[wikilink]]) 금지 — 렌더 깨짐

Markdown Table Rules

표는 리스트 불릿(-/1.) 안에 들여쓰지 말 것 — 최상위 레벨(들여쓰기 0)에 두고 앞뒤에 빈 줄을 둔다. 불릿 아래에 탭/스페이스로 들여쓴 표는 Quartz 가 표로 렌더하지 못하고 | ... | 원문 그대로 노출된다.
- ✅ 불릿에서 표를 소개하려면 불릿 문장으로 안내하고 표는 다음 줄부터 최상위 레벨에 배치
```
**적립 구조** — 구간별 비율:

| 구간 | 비율 |
|---|---|
| A | 1% |
```
- ❌ - **적립 구조**: 아래에 \t| 구간 | 비율 | 처럼 표를 들여쓰기
(참고) 통화 $ 는 정상 렌더된다 — Quartz LaTeX(KaTeX) 플러그인은 비활성화됨( $…$ 를 수식으로 오인해 통화가 깨지던 문제 해소). 실제 수식이 필요하면 그때만 플러그인을 켜고 통화는 \$ 로 이스케이프.

Pre-Flight Checklist (Before Every Write/Edit)

Essential (Post-Compact)

컨텍스트 압축 후에도 반드시 기억:

YAML: 2 SPACES / Body: TAB

Wikilinks in YAML: 큰따옴표 "[[link]]"

Mermaid 라벨: 큰따옴표 A["label"] / [/ 로 시작 금지

3 Layers: Raw Sources (immutable) → Wiki (LLM-maintained) → Schema (this file)

Operations: Capture Tabs/Market Scan → Inbox → Ingest → Query → Verify/Audit → Lint (+Status/Reindex/Refresh). Codex/Claude 양 harness 공유 — .codex/commands/ + .agents/skills/ mirror .claude/commands/.

필수 프로퍼티 7개: type, aliases, description (English, 항상 큰따옴표), author, date created, date modified, tags

Core Context 먼저 읽기: 모든 operation 전에 Core Context 로 사용자 목적·철학 정렬

미래의 나에게 보내는 편지: /ingest 는 반드시 수집 목적 1회 질문 → collectionPurpose 프로퍼티에 기록

Provenance 항상 (v6): 에이전트 작성 페이지는 author + model(상세 모델 id) + effort(추론 강도) 기록 — Claude/Codex/Grok 교차 참조

🧭 Core Context (반드시 먼저 로드)

모든 operation 전에 Core Context 를 먼저 읽는다.

해당 노트는 (1) 사용자의 정체성·7 재활용 축·철학 + (2) 옵션: 별도 mothership 볼트가 있다면 그 시스템 파일 snapshot 을 담는다. 이 맥락 없이는 LLM Wiki 의 모든 operation 이 “목적 없는 자동 정리” 로 전락한다.

(옵션) Mothership 볼트가 있는 경우

별도의 mothership Obsidian 볼트를 운영하고 있다면 (예: CMDSPACE 같은 개인 PKM 볼트), 그 시스템 파일들을 Core Context 의 “동적 참조” 섹션에 등록한다. mothership pattern 예시는 cmds-system-files 참고.

mothership 이 없다면 이 LLM Wiki 단독으로 운영한다 — Core Context §5 는 비워두거나 삭제.

Core Context 은 snapshot_date 기준. 30일 이상 오래되면 lint 가 flag → re-snapshot.

Vault Overview

이 볼트는 Karpathy LLM Wiki Pattern을 구현한 LLM 전용 지식 베이스입니다.

목적: LLM이 raw sources를 컴파일하여 persistent, structured wiki를 유지
철학: RAG(매번 검색+합성)가 아닌, 한 번 컴파일된 위키가 compounding artifact로 성장
연결: (옵션) mothership Obsidian 볼트의 satellite 로 운영 가능

(옵션) Mothership 볼트 연결

별도 PKM 볼트가 있다면 본 LLM Wiki 를 satellite 로 두고 cross-reference.

항목	값
메인 볼트 경로	`{PATH_TO_YOUR_MOTHERSHIP_VAULT}`
이 볼트 경로	`/c/Users/David/Desktop/Vaults/04_GuWiki`
Cross-reference	`source-vault` 프로퍼티로 메인 볼트 노트 참조

Mothership pattern 예시: cmds-system-files (Karpathy Wiki pattern 과 분리된 PKM harness).

위성 데이터 볼트 연결 (Satellite Data Vault: 05_SalesReport)

위 “Mothership 볼트 연결”과는 반대 방향이다 — 이 GuWiki 볼트는 (Mode A 단독 운영이라 자신의 상위 mothership은 없지만) 특정 업무 데이터를 위한 외부 특화 볼트를 **위성(satellite)**으로 등록해 참조할 수 있다. 2026-08-04 등록, 현재 1개.

항목	값
위성 볼트 이름	`05_SalesReport`
위성 볼트 경로	`/c/Users/David/Desktop/Vaults/05_SalesReport`
이 볼트(모선) 경로	`/c/Users/David/Desktop/Vaults/04_GuWiki`
목적	Turbo Air 판매실적 Power BI 시맨틱 모델의 스키마·비즈니스 용어·산출 방법론 참조 (원본 Google Sheets 데이터는 GuWiki가 커넥터로 직접 조회 — 05_SalesReport는 데이터가 아니라 스키마 설명서 역할)
주요 참조 문서	Data Catalog/Semantic Model.md, Data Catalog/Business Glossary.md, Data Catalog/Tables/Sales.md·Oders.md·_Measures.md, Reports/판매실적 분석보고서 (2026-08).md
등록 경로	영업판매실적 조회 절차 (Wiki Guide) — 위성 볼트 접근 절차·크로스레퍼런스 표 전체 수록
Cross-reference 프로퍼티	`satelliteVaultRelated` (신규, camelCase) — `obsidian://open?vault=05_SalesReport&file=...` 클릭 가능 링크 리스트

satelliteVaultRelated 사용 규칙:

판매실적/영업 관련 Wiki 페이지·Raw Source·Query Result 중 05_SalesReport 문서를 근거로 삼는 경우 frontmatter에 satelliteVaultRelated로 해당 문서의 obsidian://open?vault=05_SalesReport&file=... 링크를 기록한다.
mainVaultRelated(§Mothership, 이 볼트가 위성으로서 상위 개인 PKM을 참조하는 용도, 현재 Mode A로 미사용)와 절대 혼용하지 않는다 — 방향이 반대다.
05_SalesReport의 Data Catalog/Business Glossary를 이 볼트에 그대로 복사하지 않는다 — 두 곳에 같은 내용이 있으면 드리프트가 생긴다(실제로 TA QLD 관련 서술이 두 볼트에서 어긋난 적이 있었다, 2026-08-04 확인 및 수정).
원본 판매 데이터(Google Sheets Sales Data)는 05_SalesReport를 거치지 않고 이 GuWiki가 Google Drive 커넥터로 직접 조회한다. 상세 절차는 영업판매실적 조회 절차 참고.

3-Layer Architecture

Layer 1: Raw Sources (`10. Raw Sources/`)

불변층 — 원본 자료를 그대로 보관. 절대 수정하지 않음.

10. Raw Sources/
├── 11. Articles/     # 웹 기사, 블로그 포스트
├── 12. Papers/       # 학술 논문, 기술 보고서
├── 13. Books/        # 도서 노트, 챕터 요약
├── 14. Transcripts/  # 강연, 팟캐스트, 영상 전사
├── 15. Clippings/    # 웹 클리핑, 스크랩
├── 16. AI Research/  # ChatGPT/Gemini/Grok/Claude/Perplexity 선행 조사 묶음
└── 19. TAB Project/  # Turbo Air Brain 사내 프로젝트 전용 (부서별 13개 서브폴더, source-type 이 아닌 업무영역 기준)

규칙:

원본 텍스트를 그대로 보존
수정이 필요하면 Wiki 페이지에서 재해석
type: raw-source frontmatter 사용
date ingested 프로퍼티로 인제스트 시점 기록

19. TAB Project/ 예외

다른 Raw Source 카테고리(11~~16)는 자료 유형 기준이지만, 19. TAB Project/ 는 업무영역(부서) 기준 서브폴더 13개(00_참고자료~~12_규정_컴플라이언스)를 쓴다 — TAB(Turbo Air Brain) 사내 데이터 프로젝트 전용. 모든 하위 문서를 다루기 전에 19. TAB Project/00_TAB_프로젝트_선언문.md 를 최우선으로 읽는다. 상세 라우팅: TAB Project (사내 데이터 프로젝트).

Layer 2: The Wiki (`20. Wiki/`)

LLM 관리층 — LLM이 직접 작성하고 업데이트하는 지식 페이지.

20. Wiki/
├── 21. Concepts/     # 추상 개념 (Attention, Transformer, RLHF, ...)
├── 22. Entities/     # 사람, 조직, 제품 (OpenAI, Karpathy, GPT-4, ...)
├── 23. Guides/       # How-to, 튜토리얼, 실전 가이드
├── 24. Maps/         # MOC (Map of Content), 주제별 인덱스
└── 25. Questions/    # Research Question — 1급 연구 질문 카드 (v6.1)

규칙:

21~24 페이지는 type: wiki-page, 25. Questions 카드는 type: research-question frontmatter 사용
관련 Raw Source를 source 프로퍼티로 역참조
모든 주장에 출처 명시 (Wiki 내 링크 또는 Raw Source 참조)
Cross-reference: 관련 개념은 반드시 [[wikilink]]로 연결
모순 발견 시 > [!warning] Contradiction callout으로 플래그
To-do/미해결 항목은 > [!question] Open Question callout 사용
반복 등장하거나 산출물로 이어질 질문은 Open Question 콜아웃에서 25. Questions/ 의 Research Question 카드로 승격 (sourceCallout 으로 역추적)

Layer 3: Schema (이 파일)

규칙층 — LLM의 행동을 제어하는 harness 문서.

30. Queries/ 는 4번째 레이어가 아니다

3-Layer 는 구조 축 (Raw Sources → Wiki → Schema) 이고, Ingest → Query → Lint 는 운영 축 이다. 30. Queries/ 는 새로운 구조 레이어가 아니라 Query 단계의 산출물이 떨어지는 위치다 — 컴파일된 Wiki 에서 합성한 답변을 보관하는 운영 결과물. 마찬가지로 70. Outputs/ 도 도구 산출물 보관소일 뿐 레이어가 아니다. 구조(무엇을 보관하는가) 와 운영(어떤 동작의 결과인가) 을 혼동하지 말 것.

TAB Project (사내 데이터 프로젝트)

TAB (Turbo Air Brain) 은 Turbo Air 호주법인 사내 데이터(영업·재무·운영·인사)를 다루는 별도 프로젝트 라인이다. 다른 카테고리(11~~16, 01~~05)는 자료 유형(Articles/Papers/…) 기준이지만, TAB Project 는 업무영역(부서) 기준으로 13개 서브폴더를 공유한다:

00. Inbox/09. TAB Project/          10. Raw Sources/19. TAB Project/
├── 00_참고자료                      ├── 00_참고자료
├── 01_회사개요                      ├── 01_회사개요
├── 02_조직과인력                    ├── 02_조직과인력
├── 03_제품과서비스                  ├── 03_제품과서비스
├── 04_영업                          ├── 04_영업
├── 05_재무                          ├── 05_재무
├── 06_운영_물류                     ├── 06_운영_물류
├── 07_인사                          ├── 07_인사
├── 08_고객_CRM                      ├── 08_고객_CRM
├── 09_프로세스_SOP                  ├── 09_프로세스_SOP
├── 10_전략_기획                     ├── 10_전략_기획
├── 11_IT_시스템                     ├── 11_IT_시스템
└── 12_규정_컴플라이언스             └── 12_규정_컴플라이언스

규칙:

선언문 우선 로드: 19. TAB Project/ 하위 문서를 다루는 모든 operation( /inbox, /ingest, /query, /lint, /audit)은 10. Raw Sources/19. TAB Project/00_TAB_프로젝트_선언문.md 를 먼저 읽고 그 목적·원칙 아래에서 작업한다.
라우팅: 신규 TAB 자료는 00. Inbox/09. TAB Project/{부서폴더}/ 에 임시 보관 → /ingest 시 같은 부서 번호의 10. Raw Sources/19. TAB Project/{부서폴더}/ 로 이동. 부서를 특정하기 애매하면 00_참고자료.
Wiki 컴파일 대상: TAB 자료 컴파일 결과는 20. Wiki/22. Entities/(조직·인물·제품) 또는 20. Wiki/23. Guides/(SOP·프로세스) 등 표준 Wiki 레이어에 그대로 흡수한다 — TAB 전용 Wiki 서브폴더는 만들지 않는다. collectionPurpose 기본값은 "CMDS 시스템" 축.
민감 데이터 취약폴더: 05_재무, 07_인사 는 선언문 원칙 #4(확인된 사실/추정 엄격 구분)를 특히 강하게 적용 — confidence 를 보수적으로 매기고 Bias Check 콜아웃을 생략하지 않는다.
collectionPurpose: TAB 관련 소스는 /ingest 목적 질문에서 별도 답변을 다시 받기보다 기본값 "CMDS 시스템 — TAB(Turbo Air Brain) 프로젝트" 를 제안하고 사용자 확인만 받는다(반복 질문 최소화).

K-Master 브랜드 (Turbo Air 하위 신규 브랜드, 쿼리 기본값 규칙)

신규 브랜드/사업부 공유 드라이브는 /drive-onboard로

K-Master는 이 온보딩 패턴의 최초 워크드 예시다. 앞으로 신규 브랜드/사업부의 Google Drive 공유 드라이브를 위키에 통합할 때는 매번 처음부터 설계하지 말고 /drive-onboard 스킬을 사용한다 — 구조 탐색 → (데이터 카탈로그가 필요한 시트가 있는지 사용자에게 먼저 확인 후에만 진행) → Raw Source 변환 → Wiki 컴파일 → 이 문서 같은 쿼리 disambiguation 섹션 신설 → pull-shared-drive-inbox.mjs에 드라이브 등록까지 전체 절차가 정의돼 있다.

K-Master는 Turbo Air Pty Ltd(호주법인)가 새로 런칭한 저가형(value-tier) 상업용 냉장 브랜드다(2026-08-27 등록). Raw Source는 10. Raw Sources/20. K-Master/(TAB Project와 별도의 신규 카테고리, flat 구조 — 문서 수가 적어 부서별 서브폴더 없이 시작, 성장하면 TAB Project 패턴 참고해 세분화), Wiki 컴파일은 표준 레이어(22. Entities/K-Master.md, 23. Guides/K-Master Sales Data (DB) 테이블 명세 및 데이터 카탈로그.md)에 흡수, MOC는 MOC-K-Master(TAB 프로젝트와 분리)로 관리한다. 원본 자료는 KM Drive(Google Drive 공유 드라이브)에서 인제스트.

쿼리 기본 브랜드 disambiguation — 반드시 지킬 것

이 볼트에서 브랜드 관련 질문(/query, /ask 사이트 봇 등 모든 질의응답 경로)은 명시적 표시가 없는 한 기본적으로 Turbo Air(본브랜드)에 대한 질문으로 간주한다. “K-Master” 또는 “케이마스터”라는 단어가 질문에 포함된 경우에만 그 질문을 K-Master 관련(또는 K-Master를 포함한) 질문으로 선언하고, K-Master·MOC-K-Master 및 하위 Raw Source/Guide를 근거로 삼는다. 이 규칙은:

Wiki/vault 측: /query 실행 시 이 규칙을 적용 — 브랜드 미명시 질문에 K-Master 데이터를 섞지 않는다.

사이트 /ask 봇 측: functions/api/ask.js의 시스템 프롬프트에도 동일 규칙이 반영되어 있다(2026-08-27 추가) — 상세: Cloudflare Pages Function + Claude API로 Wiki 기반 Q&A 봇 만들기 관련 섹션.

판매 데이터 측: TAB Sales Data(Turbo Air)와 K-Master DB(KM_Database)는 별개의 Google Sheet다 — 브랜드 미명시 매출/딜러 질문은 TAB Sales Data만 조회하고 K-Master 수치를 섞지 않는다. K-Master 매출 질문은 반드시 “K-Master”/“케이마스터”가 명시돼야 KM_Database를 조회한다. (2026-09-28: /ask 봇에도 이 게이트 그대로 query_km_sales_data 도구가 구현됐다 — 그 전까지는 규칙만 있고 조회 경로가 없어 K-Master 질문에 수치를 낼 수 없었다. 같은 날 딜러 속성 조회용 query_dealer_master도 신설. 상세: Cloudflare Pages Function + Claude API로 Wiki 기반 Q&A 봇 만들기 §18)

TA Service (애프터서비스·부품판매, 쿼리 기본값 규칙)

TA Service는 별도 브랜드가 아니라 Turbo Air Pty Ltd(호주법인)의 애프터서비스·부품판매 업무기능이다(2026-08-31 온보딩, /drive-onboard 두 번째 워크드 예시). K-Master가 신규 브랜드인 것과 달리 TA Service는 본브랜드 제품의 서비스 티켓·부품판매·B급 재고를 다루는 공유 드라이브 “TA Service”(driveId 0AOiFPdtlwbPWUk9PVA) 전체를 온보딩한 것이다. Raw Source는 10. Raw Sources/21. TA Service/(부서 서브폴더 구조 채택 — 55개+ 파일이 9개 이상 뚜렷이 다른 카테고리에 걸쳐 있어 K-Master의 flat 구조 대신 TAB Project형 서브폴더를 곧바로 도입: 00_참고자료/Part Sales/Report to Factory/TA Spec/Master Specs/TA-Service Log/Service Monthly Report/Service Inv Reports/B급 재고 관리/Service Manual/User Manual), Wiki 컴파일은 표준 레이어(22. Entities/TA Service.md, 23. Guides/TA-Service Log 테이블 명세 및 데이터 카탈로그.md)에 흡수, MOC는 MOC-TA Service(TAB 프로젝트와 분리)로 관리한다.

쿼리 기본값 disambiguation — 반드시 지킬 것

이 볼트에서 매출/부품/서비스 관련 질문은 명시적 표시가 없는 한 기본적으로 TAB 완제품 사업(Sales Data)에 대한 질문으로 간주한다. “부품”/“파츠”/“서비스”/“AS”/“수리”/“TA Service” 등의 단어가 질문에 포함된 경우에만 그 질문을 TA Service 관련 질문으로 선언하고, TA Service·MOC-TA Service 및 하위 Raw Source/Guide를 근거로 삼는다. 이 규칙은:

Wiki/vault 측: /query 실행 시 이 규칙을 적용 — 매출/딜러 질문에 TA Service 데이터를 섞지 않는다.

사이트 /ask 봇 측: functions/api/ask.js의 시스템 프롬프트에도 동일 규칙이 반영되어 있다(2026-08-31 추가) — 상세: Cloudflare Pages Function + Claude API로 Wiki 기반 Q&A 봇 만들기 관련 섹션.

판매 데이터 측: TAB Sales Data(완제품 매출)와 TA Service Part Sales from 2023(애프터마켓 부품 매출)는 별개의 Google Sheet다 — 브랜드/기능 미명시 매출 질문은 TAB Sales Data만 조회하고 부품판매 수치를 섞지 않는다. 부품판매 질문은 반드시 “부품”/“파츠” 등이 명시돼야 Part Sales from 2023를 조회한다.

데이터 카탈로그 범위: TA-Service Log(서비스 티켓 로그)만 데이터 카탈로그 대상이다(David 명시 결정) — Part Sales from 2023는 행 단위 원장이지만 카탈로그를 만들지 않기로 명시적으로 결정했다.

Google Form 출처: TA-Service Log는 Google Form 응답 스프레드시트가 원천이다 — 폼 자체는 mime type 미지원으로 구조를 직접 추출하지 못해 응답 시트 헤더에서 역추론했다(2026-08-31-ta-service-log-form-pointer 참고).

비한국어 소스 처리 (한국어 요약 병기)

에이전트가 웹 검색·직접 수집으로 00. Inbox/ 에 자료를 저장할 때(Web Clipper 캡처 제외), 원문 언어가 한국어가 아니면 원문 보존과 별도로 한국어 요약을 병기한다.

규칙:

원문 보존 우선: ## Content / ## Original Content 의 원문은 그대로 둔다 — 번역으로 대체 금지, 불변 원칙 유지.
전문 번역이 아닌 요약: 문장 단위 전역 번역 대신 핵심 사실(5W1H·수치·인용 요지)을 담은 한국어 요약을 ## 한국어 요약 (Korean Summary) 섹션으로 원문 앞이나 바로 뒤에 추가한다. 저작권상 원문 전체를 다른 언어로 그대로 옮기는 것은 지양하고, 사실관계를 압축한 요약을 원칙으로 한다.
frontmatter: language 는 원문 언어 그대로 기록(예: en), summaryLanguage: ko 를 추가해 한국어 요약이 존재함을 표시한다.
Web Clipper 예외: 결정론적 JSON 템플릿(LLM 미개입)으로 캡처된 파일은 클립 시점에 번역이 불가능하므로 예외 — /ingest 또는 /inbox 실행 시 에이전트가 이 규칙에 따라 한국어 요약을 보완한다.
적용 범위: 00. Inbox/, 10. Raw Sources/ 의 모든 비한국어 원문 자료(Articles/Papers/Transcripts/Clippings/AI Research/TAB Project 등 카테고리 무관).

Operations

🤖 Agent Note (Claude Code & Codex & Antigravity): Claude Code 의 operation entrypoint 는 .claude/commands/{operation}.md 이다. Codex mirror 는 .codex/commands/{operation}.md 와 .agents/skills/{operation}/SKILL.md 에 둔다. 같은 operation 은 양쪽 harness 에 같은 이름으로 둔다. 두 harness 는 같은 Schema(이 파일 + AGENTS.md)를 공유하되, Claude 작업에서는 CLAUDE.md + .claude/commands/ 가, Codex 작업에서는 AGENTS.md + .codex/commands/ 가 우선이다.

Cross-Agent Compatibility Matrix

같은 operation 을 추가할 때는 반드시 .claude/commands/{name}.md, .codex/commands/{name}.md, .agents/skills/{name}/SKILL.md 를 함께 맞춘다.

Parity Contract (CLAUDE.md ↔ AGENTS.md)

이 두 스키마는 같은 규칙의 미러다. 다음 섹션은 양쪽이 동일해야 하며 한쪽만 편집 금지: (1) Cross-Agent Compatibility Matrix, (2) Frontmatter Standards (7 필수 + v2/v3/v4/v5/v6/v6.1/v6.2 키), (3) Verification Properties (v5) 3 기준, (4) Callout Conventions. 편집 시 CLAUDE.md 와 AGENTS.md 를 함께 고치고 /lint + parity 체크리스트로 확인. .codex/·.agents/ 는 untracked 라 diff 에 안 보이므로 수동 대조가 필요하다.

Operation	Claude command	Codex command	Codex skill	Notes
Capture Tabs	`.claude/commands/capture-tabs.md`	`.codex/commands/capture-tabs.md`	`.agents/skills/capture-tabs/SKILL.md`	AI research / browser tab bundle → Inbox
Market Scan	`.claude/commands/market-scan.md`	`.codex/commands/market-scan.md`	`.agents/skills/market-scan/SKILL.md`	web search across 7 TAB axes (market/business/customer/competitor/regulation/general/other), 5–10 new total → Inbox
Tech Scan	`.claude/commands/tech-scan.md`	`.codex/commands/tech-scan.md`	`.agents/skills/tech-scan/SKILL.md`	recency-first web scan across 7 build axes (ai/dashboard/powerbi-fabric/llm-wiki/web-build/data-app/knowledge), 5–10 newest → Inbox
Inbox	`.claude/commands/inbox.md`	`.codex/commands/inbox.md`	`.agents/skills/inbox/SKILL.md`	pending source preview + ingest routing
Ingest	`.claude/commands/ingest.md`	`.codex/commands/ingest.md`	`.agents/skills/ingest/SKILL.md`	purpose gate + Raw Source + Wiki compile
Query	`.claude/commands/query.md`	`.codex/commands/query.md`	`.agents/skills/query/SKILL.md`	compiled Wiki synthesis + Query Result
Lint	`.claude/commands/lint.md`	`.codex/commands/lint.md`	`.agents/skills/lint/SKILL.md`	health check + frontmatter coverage
Status	`.claude/commands/status.md`	`.codex/commands/status.md`	`.agents/skills/status/SKILL.md`	counts + coverage snapshot
Reindex	`.claude/commands/reindex.md`	`.codex/commands/reindex.md`	`.agents/skills/reindex/SKILL.md`	qmd update/embed/status
Refresh Context	`.claude/commands/refresh-context.md`	`.codex/commands/refresh-context.md`	`.agents/skills/refresh-context/SKILL.md`	Core Context from mothership system files
Verify	`.claude/commands/verify.md`	`.codex/commands/verify.md`	`.agents/skills/verify/SKILL.md`	single-page verification
Audit	`.claude/commands/audit.md`	`.codex/commands/audit.md`	`.agents/skills/audit/SKILL.md`	vault/MOC audit + `/verify` queue
Diagnose	`.claude/commands/diagnose.md`	`.codex/commands/diagnose.md`	`.agents/skills/diagnose/SKILL.md`	TAB 진단 리포트(TAB-DR-NNN) 생성 → 볼트 `31. Diagnosis Reports/` synthesis + 사이트 `/reports` 발행. 디자인 템플릿 `.agents/skills/diagnose/resources/report-template.html`
Translate Answers	`.claude/commands/translate-answers.md`	`.codex/commands/translate-answers.md`	`.agents/skills/translate-answers/SKILL.md`	`30. Queries/` 문서 중 사이트 답변보기(zh/en) 번역 누락분을 찾아 번역(제목/질문 frontmatter pin + 본문) → i18n 번들 재생성 → staging 검증 → 프로덕션 배포. 유일하게 `quartz-site` 저장소까지 건드리는 cross-repo operation
Drive Onboard	`.claude/commands/drive-onboard.md`	`.codex/commands/drive-onboard.md`	`.agents/skills/drive-onboard/SKILL.md`	신규 브랜드/사업부의 Google Drive 공유 드라이브를 위키에 온보딩 — 구조 탐색 → Raw Source 변환 → Wiki 컴파일(Entity/Guide/MOC) → 쿼리 disambiguation 거버넌스(CLAUDE.md+AGENTS.md+`ask.js`) → (사용자 확인 시만) 데이터 카탈로그 → `pull-shared-drive-inbox.mjs`에 드라이브 등록해 자동 동기화. `quartz-site` 저장소까지 건드리는 cross-repo operation, K-Master가 최초 워크드 예시(`10. Raw Sources/20. K-Master/`)
Weekly Digest	`.claude/commands/weekly-digest.md`	`.codex/commands/weekly-digest.md`	`.agents/skills/weekly-digest/SKILL.md`	매주 월요일 주간 동향 보고서(TAB-WD-NNN) 작성 → 볼트 `32. Weekly Digests/` 마크다운 1개. 실적은 `scripts/weekly-metrics.mjs`(KPI 규칙 고정)로 집계하고 웹 5축을 훑는다. 렌더·배포는 `generate-digests.ps1` + 매시간 리빌드가 전담 — 에이전트는 HTML 을 쓰지 않는다
Review Answer	`.claude/commands/review-answer.md`	`.codex/commands/review-answer.md`	`.agents/skills/review-answer/SKILL.md`	사이트 `/ask` 자동답변 1건을 재분석·재작성하고, 원답변이 실패·부실·오답이면 그 원인이 된 도구/규칙 자체를 고친다. 무인 실행 전용 러너 `quartz-site/run-answer-review.ps1`(스케줄 작업 `TAB-Answer-Review`, 매시 :40)이 미검토 문서를 찾아 이 스킬을 호출하고, 워커 수정은 `scripts/verify-worker.mjs` 게이트를 통과해야만 남긴다(실패 시 자동 revert). 질문자 알림은 기존 `notify-answer-updates.ps1` 이 `date modified` 변화를 보고 발송(David 참조). `quartz-site` 저장소까지 건드리는 cross-repo operation

/onboard (.claude/commands/onboard.md) 는 Claude 전용 first-run 셋업 인터뷰로, mirror 가 없다.

Codex Compatibility Notes

Codex 작업에서는 AGENTS.md 가 primary schema 이고, .codex/commands/ + .agents/skills/ 가 operation harness 다.
File edits use patch-style changes; Raw Sources remain immutable except ingest/update policy.
qmd search (qmd query, qmd vsearch) is the preferred local retrieval fallback when MCP tools are unavailable.
Browser/Computer Use capture may be used for visible tab groups, but public share links, uploads, sends, and account-setting changes need action-time user confirmation.
Hooks: .claude/hooks/*.sh are wired via .claude/settings.json (uses $CLAUDE_PROJECT_DIR); .codex/hooks/*.sh are wired via .codex/hooks.json (set the /c/Users/David/Desktop/Vaults/04_GuWiki placeholder to your absolute vault path). Both enforce ## Original Content on Raw Sources and keep qmd fresh after writes.

0. Capture Tabs / AI Research Capture (선행 조사 보존)

/capture-tabs 는 ChatGPT, Gemini, Grok, Claude, Perplexity, 일반 source tab 으로 만든 Chrome 탭 그룹을 00. Inbox/05. AI Research/ 에 Markdown research bundle 로 저장하는 pre-ingest capture layer 다.

Entrypoints:

Claude command: .claude/commands/capture-tabs.md
Codex mirror: .codex/commands/capture-tabs.md + .agents/skills/capture-tabs/SKILL.md
Template: 90. Settings/Templates/Template_AI Research Capture.md

규칙:

원문·복사본·export 는 ## Original Content 아래에 보존한다.
에이전트의 요약·불일치·Wiki 제안은 ## Agent Capture Notes 아래에 둔다. 기존 ## Codex Capture Notes 파일은 레거시 호환으로 인정한다.
기본 저장 위치는 00. Inbox/05. AI Research/YYYY-MM-DD-ai-research-{topic-slug}.md 이다.
source URL, platform, visible model/account/workspace, capture method, capture limitation 을 기록한다.
공개 share link 생성, 계정 설정 변경, 대화창 전송, 파일 업로드는 사용자 action-time confirmation 없이 금지한다.
inbox-only, run-inbox, ingest-now 중 다음 단계를 명시하고, ingest-now 는 /ingest 의 목적 질문과 메인 볼트 연결 검색을 그대로 따른다.

0-b. Market Scan (TAB 7축 시장·경영 뉴스 수집)

/market-scan 은 웹을 검색해 TAB 프로젝트에 도움이 되는 신규 자료를 00. Inbox/01. Articles/ 에 캡처 노트로 쌓는 pre-ingest capture layer 다. /capture-tabs 가 브라우저 탭을 읽는다면, /market-scan 은 웹 검색으로 직접 찾는다. 7개 축을 스캔하되 축별 정해진 개수 없이 전체 5~10개의 새로운 자료를 모은다:

market — 호주 상업용 냉장/냉동고 시장 (규모·트렌드·리포트·수요 변화)
business — 자사 Turbo Air (제품·가격·그룹·호주법인)
customer — 고객사(딜러사)와 수요측 체인·세그먼트
competitor — 위키가 추적 중인 경쟁사
regulation — 호주 법령·규제·표준 변동 (HFC/냉매·GEMS/MEPS·관세·세제·컴플라이언스)
general — 경영 의사결정에 유용한 일반 비즈니스·경제 뉴스 (물류비·에너지·금리·환율·외식업)
other — 그 밖에 TAB 프로젝트에 도움이 되는 문서

Entrypoints:

Claude command: .claude/commands/market-scan.md
Codex mirror: .codex/commands/market-scan.md + .agents/skills/market-scan/SKILL.md
Template: 90. Settings/Templates/Template_Market Scan Article.md

규칙:

검색 전 반드시 볼트 내 기존 엔티티·개념(프로젝트 선언문의 자사, 20. Wiki/22. Entities/ 경쟁사·딜러, 30. Queries/ 경쟁사·시장 분석, 21. Concepts/ 규제·경제 개념)을 근거로 검색어를 만든다 — 이름을 지어내지 않는다.
중복 방지 = URL + 주제: 10. Raw Sources/·30. Queries/ 의 기존 source:/source_url: 과 중복되면 건너뛰고, 핵심 사실이 이미 위키에 보고된 항목도 건너뛴다(재수집이 아니라 새 전개를 수집). 위키가 적게 다룬 축(시장·규제·일반·기타)에 가중.
축별 할당량 없음. 전체 5~10개의 새로운 자료를 목표로 하되, 관련성 낮은 기사로 채우지 않는다. 새 자료가 없으면 아무것도 수집하지 않고 그 사실을 보고한다.
각 파일은 scanBucket: market|business|customer|competitor|regulation|general|other 프로퍼티로 축을 표시하고, ## 선정 사유 (Curation Note) 에 왜 선정했는지·위키 대비 무엇이 새로운지·어느 기존 Wiki 페이지와 연결되는지 기록한다.
비한국어 원문은 ## 비한국어 소스 처리 규칙에 따라 ## 한국어 요약 (Korean Summary) 를 병기한다.
/ingest//inbox 를 자동 실행하지 않는다 — Inbox 적재까지만 하고 다음 단계는 사용자에게 안내.

0-c. Tech Scan (TAB 시스템 구축용 기술 자료 수집)

/tech-scan 은 웹을 검색해 TAB 시스템(turboairbrain.uk 위키 + /ask 봇 + 대시보드 + 데이터 파이프라인)을 구축·개선하는 데 필요한 기술 자료를 00. Inbox/01. Articles/ 에 캡처 노트로 쌓는 pre-ingest capture layer 다. /market-scan 이 사업·시장 인텔리전스를 모은다면, /tech-scan 은 시스템 구축 재료를 모은다. 7개 축을 스캔하되 축별 정해진 개수 없이 전체 5~10개를 수집하되 반드시 최근 1개월(≈30일) 이내 게시물만 수집한다(하드 윈도우 — 아무리 좋아도 1개월 넘은 자료는 제외):

ai — AI/LLM 신기술 (프런티어 모델·에이전트·RAG·프롬프팅·평가·에이전트 메모리·MCP)
dashboard — 대시보드·BI·데이터 시각화 구축 (디자인 패턴 + 도구)
powerbi-fabric — Microsoft Power BI + Fabric (시맨틱 모델·DAX·Fabric 워크로드·Direct Lake·Power BI MCP)
llm-wiki — LLM/에이전트 지식베이스 패턴 (Karpathy LLM wiki·컴파일 위키 vs RAG·에이전트 메모리·지식그래프)
web-build — 웹사이트 구축 (Quartz·정적 사이트 생성기·Cloudflare Pages/Workers/KV·프런트엔드·인증)
data-app — 데이터 앱·자동화 (커넥터·파이프라인·임베딩/벡터검색·Google Sheets/API·서버리스)
knowledge — 지식수집·PKM·인제스트 방법론, 그 밖에 TAB 구축에 유용한 문서

Entrypoints:

Claude command: .claude/commands/tech-scan.md
Codex mirror: .codex/commands/tech-scan.md + .agents/skills/tech-scan/SKILL.md
Template: 90. Settings/Templates/Template_Tech Scan Article.md

규칙:

현 시스템을 먼저 읽는다: CLAUDE.md 아키텍처 + 20. Wiki/23. Guides/ 를 훑어, 이미 문서화된 how-to(Quartz→Cloudflare 배포, Cloudflare Pages Function + Claude API /ask 봇, Sales Data/KPI, Power BI 시맨틱 모델)는 재수집하지 않는다. 실제 스택 기준으로 “다음에 필요한 것”을 검색.
최신 우선 · 1개월 하드 윈도우: 최근 ~30일 이내 게시물만 수집, 그보다 오래된 자료는 품질과 무관하게 제외. 동일 주제면 더 최신을 채택. 검색어에 현재 월/연도·“this month/week”·changelog 활용.
중복 방지 = URL + 주제: 기존 source:/source_url: 중복 스킵 + 기존 Guide 에 이미 있는 내용도 스킵.
축별 할당량 없음. 전체 5~10개의 새 자료 목표, 관련성 낮은 자료로 채우지 않는다. 새 자료 없으면 수집하지 않고 보고.
각 파일은 techBucket: ai|dashboard|powerbi-fabric|llm-wiki|web-build|data-app|knowledge 프로퍼티로 축을 표시하고(clip_type: tech-scan), ## 선정 사유 (Curation Note) 에 어느 축·왜 유용·시스템의 어느 부분 개선·기존 Guide 대비 신규성·최신성을 기록.
비한국어 원문은 ## 한국어 요약 (Korean Summary) 를 병기한다.
/ingest//inbox 를 자동 실행하지 않는다 — Inbox 적재까지만 하고 다음 단계는 사용자에게 안내.

1. Ingest (새 자료 흡수)

Variants

Standard Ingest (기본): 단일 URL/파일/텍스트 → 1 Raw Source + 10~15 Wiki pages

Book Ingest (Progressive Stubs): 멀티 페이지 책·문서 사이트 (mdBook/VitePress/GitBook/Docusaurus/ReadTheDocs/Nextra, TOC 에 5+ 챕터) → 1 Book Index + N chapter stubs + 소수 Wiki (책·저자·앵커 개념). 사용자가 장을 읽을 때 해당 stub 을 “promote” (verbatim 삽입 + Wiki 컴파일 + status: stub → completed). 상세: Book Ingest Pattern + .claude/commands/ingest.md “Book Ingest Mode” 섹션.

Paper Ingest Mode (Academic Papers, v6.2): 논문(PDF/DOI/arXiv/Abstract+References) 자동 감지 → .agents/skills/ingest/resources/paper-ingest.md 리소스 로드 (12단 원자화, citekey 네이밍, RQ 연결, p7_verify.py 게이트). Standard/Book 와 공존, /ingest 단일 진입점. 사용자 매뉴얼: 90. Settings/Sharing/Paper Ingest Guide.md.

새 source가 00. Inbox/에 들어오면:

🎯 목적 질문 (미래의 나에게 보내는 편지): LLM은 사용자에게 단일 질문 을 던진다 — “이 소스를 왜 수집했나요? (7 재활용 축: PhD / 학술 / 강의 / 컨설팅 / CMDS 시스템 / 에세이 / 제품 중 어디에 쓰일 예정인가요?)”. 답변 없이 ingest 하지 않음. 답변은 collectionPurpose 프로퍼티에 기록. 0-a. 🔗 메인 볼트 연결 검색 (옵션, mothership 운영 시만): 사용자 답변을 받으면 메인 볼트에서 유사 노트·개념을 검색 한다 (mcp__qmd__query vec/hyde + Grep path={PATH_TO_YOUR_MOTHERSHIP_VAULT}). 2~5개 후보를 mainVaultRelated 프로퍼티에 기록하고 사용자에게 확인. mothership 이 없다면 이 단계는 건너뜀.
분석: source의 핵심 주제, 엔티티, 개념 추출
저장: 10. Raw Sources/{적절한 하위폴더}/로 이동 (원본 보존). Raw Source frontmatter에 collectionPurpose, mainVaultRelated, mainVaultCmds 추가.
컴파일: 관련 Wiki 페이지 10~15개를 incremental update
- 기존 페이지가 있으면 → 새 정보 추가/업데이트
- 새 개념이면 → 새 Wiki 페이지 생성
연결: cross-reference 링크 추가, MOC 업데이트. Wiki 페이지에도 mainVaultRelated 프로퍼티로 모선 링크 유지.
로그: log.md에 ingest 기록 추가 — collectionPurpose 한 줄 포함.
인덱스: Wiki.md(볼트 루트 마스터 인덱스, 사이트에서는 /wiki로 발행) 업데이트 (필요 시)

2. Query (지식 검색+합성)

질문을 받으면:

Wiki에서 relevant pages 검색
정보 종합하여 답변 생성
답변 과정에서 발견한 gap이나 모순은 Wiki에 피드백
필요시 30. Queries/에 합성 결과 저장
반응형 답변을 넘어 능동적 논증 구성(thesis + 근거 + 반론)이 필요하면 같은 폴더에 type: synthesis 카드로 저장 (v6.1)

3. Lint / Health Check (자가 정화)

주기적으로 수행:

Orphan 검사: 어디에도 링크되지 않은 Wiki 페이지 찾기
Stale 검사: 오래된 정보 플래그
모순 검사: 페이지 간 상충하는 정보 발견 → callout 추가
누락 링크: [[link]]가 있지만 페이지가 없는 경우 → 생성 또는 플래그
인덱스 동기화: Wiki.md가 실제 Wiki 구조와 일치하는지 확인

4. Source Update (기존 자료 업데이트)

이미 ingest된 Raw Source의 원본이 변경된 경우 (웹 기사 수정, 스레드 추가 등).

⚠️ 중요: Source Update가 감지되면, 반드시 사용자에게 의견을 묻고 진행 방식을 확인받을 것.

시나리오별 처리:

시나리오	Raw Source 처리	Wiki 처리	커밋 메시지
Minor (오타, 문법)	기존 파일 유지	Lint에서 수정	`lint: minor correction from {source}`
Major (새 정보, 수정된 주장)	새 버전 파일 생성 (suffix `-v2`)	Re-ingest: 영향받는 Wiki 페이지 업데이트	`ingest: {source} v2 — {변경 요약}`
Contradiction (기존 내용과 모순)	모든 버전 보존	`> [!warning]` callout 추가	`update: {page} — contradiction flagged`

규칙:

Raw Source v1은 절대 삭제하지 않음 (불변 원칙 유지)
Major update 시 새 파일: YYYY-MM-DD-{title}-v2.md
새 파일의 frontmatter에 supersedes: "[[원본 파일]]" 프로퍼티 추가
원본 파일의 frontmatter에 superseded-by: "[[새 파일]]" 프로퍼티 추가
Wiki 페이지의 source 프로퍼티에 최신 버전 추가 (기존 참조도 유지)

5. Verify (단일 페이지 검증, v5)

/verify {page} — 한 Wiki 페이지를 3 기준 (지식요건해당성·정합성·확증가능성) 에 대해 검증.

Entrypoints:

Claude command: .claude/commands/verify.md
Codex mirror: .codex/commands/verify.md + .agents/skills/verify/SKILL.md

규칙:

verificationStatus, verifiedAt, verifiedBy, claimType, evidenceScope, disputed 를 기록한다.
source-backed 검증 없이 explored: true 로 바꾸지 않는다. 사용자의 명시 확인이 필요하다.
충돌은 삭제하지 않고 disputed: true + > [!warning] Disputed Claim 으로 보존한다.
confidence 는 source count, source type, counter-evidence 를 기준으로 독립 재산정한다.

6. Audit (전체 볼트 검증, v5)

/audit — vault 전체를 3 기준으로 점검. 모든 페이지 개별 검증이 아니라 drift pattern 발견 + 우선순위 큐 생성 이 목표.

Entrypoints:

Claude command: .claude/commands/audit.md
Codex mirror: .codex/commands/audit.md + .agents/skills/audit/SKILL.md

규칙:

/audit 은 Wiki page 를 직접 수정하지 않는 read-only planning operation 이다.
MOC cluster 단위 consistency, high-confidence / stale unexplored / disputed page sampling 을 수행한다.
결과가 substantial 하면 30. Queries/YYYY-MM-DD-Q-vault-audit.md 로 저장하고 log.md 에 기록한다.
Top 10 /verify queue 를 출력한다.

Folder Structure

CMDS_LLM_Wiki/
├── .obsidian/              # Obsidian 설정
├── .claude/                # Claude Code commands/hooks (+ settings.json)
├── .codex/                 # Codex command + hook harness (commands/ · hooks/ · hooks.json)
├── .agents/skills/         # Codex reusable operation skills ({operation}/SKILL.md)
├── CLAUDE.md               # Schema — Claude Code (이 파일)
├── AGENTS.md               # Schema — Codex / 타 에이전트 (mirror)
├── Wiki.md                 # 마스터 인덱스 (alias: index — 사이트에서는 `/wiki`로 발행, 루트 `/`는 별도 랜딩 페이지)
├── log.md                  # 변경 이력
├── 00. Inbox/              # 새 자료 임시 저장 (Web Clipper 대상)
│   ├── 01. Articles/       # 웹 기사, 블로그
│   ├── 02. Papers/         # 학술 논문, 기술 보고서
│   ├── 03. Transcripts/    # 강연, 팟캐스트, 영상 전사
│   ├── 04. Clippings/      # 짧은 스니펫, 발췌
│   ├── 05. AI Research/    # ChatGPT/Gemini/Grok/Claude/Perplexity 선행 조사 묶음 (/capture-tabs 대상)
│   └── 09. TAB Project/    # Turbo Air Brain 사내 데이터 임시 보관 (부서별 13 서브폴더, [[#TAB Project (사내 데이터 프로젝트)]])
├── 10. Raw Sources/        # Layer 1: 불변 원본
│   ├── 11. Articles/
│   ├── 12. Papers/
│   ├── 13. Books/
│   ├── 14. Transcripts/
│   ├── 15. Clippings/
│   ├── 16. AI Research/
│   └── 19. TAB Project/    # TAB 프로젝트 선언문 + 부서별 13 서브폴더 (source-type 아님, 업무영역 기준)
├── 20. Wiki/               # Layer 2: LLM 관리 위키
│   ├── 21. Concepts/
│   ├── 22. Entities/
│   ├── 23. Guides/
│   ├── 24. Maps/
│   └── 25. Questions/      # Research Question 카드 (RQ-{slug}.md)
├── 30. Queries/            # 합성된 질의 결과 (+ synthesis) — /ask Q&A 산출물. 사이트 '답변보기'(/answers)로 렌더
├── 31. Diagnosis Reports/  # /diagnose 진단 리포트(TAB-DR-NNN) 전용 — 30. Queries 와 분리, 사이트 '진단 리포트'(/reports)로 발행
├── 40. Paper Analyses/     # 논문별 12단 분석 (folder = {citekey}/) — 허브 S00 + 원자 S02~S12 (v6.2)
├── 70. Outputs/            # (옵션) 외부 도구 산출물 (Layer 4: tool outputs)
│   ├── graphify/           # /graphify 결과 — YYYY-MM-DD-{topic}/ 단위
│   ├── …/                  # 향후 다른 도구도 같은 패턴
│   └── .tool-state/        # cross-run 캐시·manifest (gitignore 가능)
├── 80. References/         # 첨부 파일
│   └── Attachments/
└── 90. Settings/           # 템플릿, 설정, 스크립트
    ├── Templates/          # 노트 템플릿 11종 + 12-Step Analysis Schemes
    └── Scripts/            # p7_verify.py (Paper Mode P-7 게이트)

`70. Outputs/` 규칙 (Tool Output Convention, 옵션)

외부 도구 (graphify, audio-transcriber 등) 가 생성하는 부산물은 Wiki 본체와 격리되어야 한다. Karpathy 패턴에서 Wiki 는 컴파일 결과물 이지만, 도구 산출물은 분석 결과 — 둘은 라이프사이클이 다르다. 해당 도구를 쓰지 않으면 이 폴더 자체를 만들지 않아도 됨.

경로 패턴: 70. Outputs/{tool-name}/2026-07-28-{topic-slug}/

예: 70. Outputs/graphify/2026-04-30-knowledge-graph/
예: 70. Outputs/audio-transcriber/2026-05-12-meeting-notes/

규칙:

한 번의 실행 = 한 개의 dated 폴더 (덮어쓰지 않음, 비교 가능)
입력 스냅샷이 있으면 _corpus/ 또는 _input/ 서브폴더로 보존 (재현성)
Cross-run 상태 (캐시, manifest) 는 70. Outputs/.tool-state/{tool-name}/ 로 분리
결과물에서 발견한 인사이트는 30. Queries/ 에 별도 노트로 정제 (output != insight)
Wiki 본체 (10/20/30/80) 에서 outputs 를 직접 wikilink 하지 않음 — 발견을 정제해 Wiki 페이지로 흡수하거나, Query 결과로 인용
Outputs 자체는 LLM 의 schema 규칙 (필수 7 프로퍼티, naming convention) 적용 면제 — 도구가 자기 형식으로 생성

Frontmatter Standards

필수 프로퍼티 (7개)

모든 .md 파일에 반드시 포함:

Property	Type	Description
`type`	text	노트 유형: `documentation`, `raw-source`, `wiki-page`, `research-question` (v6.1), `query-result`, `synthesis` (v6.1), `moc`, `inbox` (capture 단계 pre-ingest), `paper-hub` (v6.2 — 논문 허브), `paper-analysis` (v6.2 — 논문 원자), `log`
`aliases`	list	대체 이름
`description`	text	English, 1-2 sentences for LLMs — 값은 항상 큰따옴표 (`description: "..."`)
`author`	list	작성자 (LLM인 경우 `Claude` / `Codex` / `Grok`)
`date created`	datetime	ISO 8601
`date modified`	datetime	ISO 8601
`tags`	list	관련 태그

Provenance 프로퍼티 (v6 신설 — 항상 기록)

에이전트가 생성·갱신하는 모든 콘텐츠 페이지(raw-source·wiki-page·research-question·query-result·synthesis·moc·inbox·paper-hub·paper-analysis) frontmatter 는 author 바로 뒤에 아래 2 키를 항상 포함한다. 목적: Claude Code·Codex·Grok 어떤 에이전트가 읽어도 “누가(role) · 어떤 모델(id) · 어떤 강도(effort)로 썼는가” 를 즉시 확인 — cross-agent provenance.

author: (기존 필수) 역할/작성자 — Claude / Codex / Grok / "[[David]]" (사람).
model: (v6 신설) 상세 모델 id. 예: claude-opus-4-8, claude-sonnet-5, gpt-5.4-codex (Codex), grok-4 (Grok). 여러 모델 기여 시 list.
effort: (v6 신설) 작성 시점의 추론 강도·모드. low / medium / high / xhigh / max 또는 타 에이전트 등가. 미상은 default.

author:
  - Claude
model: claude-opus-4-8
effort: high

harness 정의 파일(.claude/commands/*, .codex/commands/*, .agents/skills/*)의 자기 frontmatter 에는 provenance 를 넣지 않는다 (슬래시 커맨드/스킬 파서 혼선 방지) — Description Rule(큰따옴표)만 적용.

Layer별 추가 프로퍼티

Raw Source (type: raw-source):

source: 원본 URL 또는 참조
date ingested: 인제스트 일시 (Book Ingest stub 의 경우 scaffold 날짜)
category: Articles / Papers / Books / Transcripts / Clippings / AI Research / (TAB Project 는 부서 서브폴더명, 예 04_영업 — TAB Project (사내 데이터 프로젝트))
status: (v2 신설) ingested (기본) / stub (Book Ingest 미독서) / reading (독서 중) / completed (독서 완료 + Wiki 컴파일 완료). 표준 ingest 는 ingested 만 사용.
collectionPurpose: (필수, v2 신설) 사용자가 명시한 수집 목적 — 미래의 나에게 보내는 편지. 7 재활용 축 중 하나 이상. 예: "PhD 연구 — AI readiness 측정 도구", "컨설팅 deliverable — 기업 임원교육 사례"
mainVaultRelated: (v2 신설) ingest 시 메인 볼트에서 검색된 유사 노트 2~5개 — [노트명](obsidian://open?vault=...) 클릭 가능 링크 (ingest Step 0-a 에서 stat 검증한 값만 사용)
mainVaultCmds: (v2 신설) 관련 CMDS 카테고리 — "[[📚 601 Knowledge Management]]" quoted wikilink (메인 볼트 기준이므로 이 볼트에서는 resolve 안 되지만 메타데이터로 보존)

Book Ingest 전용 키 (Raw Source chapter stub, status: stub):

bookIndex: (v3 신설) 소속 책의 Book Index — "[[YYYY-MM-DD-{authorSlug}-{bookSlug}-book-index]]" quoted wikilink
chapterNumber: (v3 신설) 챕터 번호 (정수, TOC 기준)
chapterPart: (v3 신설) 챕터가 속한 편/파트 이름 — 원문 언어 보존 (예: "Part I", "第一篇")
chapterPrev, chapterNext: (v3 신설) 이전·다음 챕터 wikilink, null 가능

Wiki Page (type: wiki-page):

source: 참조한 Raw Source 링크 목록
related: 관련 Wiki 페이지 링크
confidence: high / medium / low (정보 신뢰도)
layer: concepts / entities / guides / theory / method / scale (theory/method/scale = v6.2, 논문 승격 재사용 단위 — 21. Concepts 내 layer 태그로 구분, 별도 폴더 없음. scale 페이지는 measuredConstruct·itemCount + Template_Scale Page)
mainVaultRelated: (v2 신설) 메인 볼트의 관련 에세이·MOC — [노트명](obsidian://open?vault=...) 클릭 가능 링크
mainVaultCmds: (v2 신설) 연결될 CMDS 카테고리
explored: (v4 신설) Exploration Gate 상태. 새 Wiki 페이지 기본값은 false. 사용자가 직접 읽었거나 에이전트가 별도 검증 루프를 수행한 뒤에만 true.
exploredBy: (v4 선택) explored: true 로 바꾼 사람 또는 에이전트 이름
exploredDate: (v4 선택) Exploration Gate 완료일 (YYYY-MM-DD)
claimType: (v5 신설) 페이지의 지배적 claim 유형 — definition / empirical / theoretical / historical / prescriptive / interpretive / mixed. /verify 가 분류·기록.
evidenceScope: (v5 신설) 증거 범위 — single-source / multi-source-primary / multi-source-mixed / synthesis-only / user-original. /verify 가 분류·기록.
verificationStatus: (v5 신설) 검증 상태 — verified (3 기준 모두 통과) / partial (일부 통과) / unverified (미검증, 기본값) / disputed (충돌 미해결). /verify 가 기록.
verifiedAt: (v5 선택) 최종 /verify 실행일 (YYYY-MM-DD)
verifiedBy: (v5 선택) agent / human / both
disputed: (v5 선택) true 일 때 충돌하는 다른 Wiki 페이지와 양방향 > [!warning] Disputed Claim callout 으로 연결. /verify Phase 2.2 또는 /audit Phase B 가 기록. 삭제 대신 disputed 처리하는 것이 원칙.

Query Result (type: query-result):

query: 원래 질문
source: 참조한 Wiki 페이지
reusableFor: (v2 신설, 선택) 7 재활용 축 중 어디에 쓰일지
askedBy / askedVia: (v6.3 신설, 선택) 외부 채널(예: turboairbrain.uk/ask 사이트 Q&A)에서 자동 생성된 Query Result에 질문자·채널을 기록. tags에 site-ask 포함. 사람이 직접 /query 실행 시에는 생략.

Synthesis (type: synthesis, v6.1 신설 — 능동 논증층):

30. Queries/ 에 query-result 와 같은 폴더, type 으로만 구분 (폴더 분할 안 함 — 결정 근거 아래). Query 가 반응형 답변 이면 Synthesis 는 능동적 논증 구성: thesis statement + 근거 claim(각 인용) + 반론 + gap + 타깃 산출물.
thesis: (필수) 이 합성이 방어하는 한 문장 주장
targetVenue: 타깃 산출물·채널 (예: "논문", "책 챕터", "블로그 시리즈", "제품 결정 문서")
supports: 근거가 되는 Wiki 페이지·Research Question [[link]] 목록
counters: 반론·경쟁 가설 (본문 > [!warning] 로도 보존)
cites: (권장) 인용 문헌 citekey 목록 — Citation Standard(옵션) 채택 시 ## References 의 원천
reusableFor: 7 재활용 축
공통 7 필수 + ## Thesis / ## Argument (claim + 근거) / ## Counter-arguments / ## Gap / (## References) 섹션.

폴더 결정 — 30. Queries/ 를 쪼개지 않는다

Query 와 Synthesis 는 둘 다 “compiled wiki 를 발화한 산출물”(Karpathy: 좋은 답을 위키로 역피드백)의 두 flavor 다 — type 필드로 깔끔히 구분된다. Synthesis 가 대량 축적되면 그때 하위폴더로 분리 (파일명 기반 wikilink 라 이동은 저렴). YAGNI — 지금은 flat + type: synthesis.

MOC (type: moc):

topic: 주제 영역
related: 하위 MOC 또는 관련 MOC

Research Question (type: research-question, v6.1 신설 — 질문의 1급 객체화):

볼트의 5번째 Wiki 카드 타입. 20. Wiki/25. Questions/ 에 저장. 파일명 RQ-{slug}.md. in-page > [!question] Open Question 콜아웃을 1급 카드로 승격 — 반복 등장하거나 산출물(논문·책·블로그 시리즈·제품 결정)로 이어질 질문을 first-class object 로 다뤄 답이 아니라 질문 자체를 추적한다.
status: (필수) open / investigating / answered / parked / superseded
questionType: (필수) descriptive / causal / comparative / methodological / normative / design
feedsInto: (필수) 어느 산출물로 흘러가나 (예: "논문 2장", "블로그 시리즈 — AI 도입 가이드", "제품 로드맵 결정")
evidenceFor / evidenceAgainst: 지지·반대 증거 — [[wiki page]] (+ Citation Standard 채택 시 [@citekey]) 혼합
hypotheses: 후보 답변 목록
cites: (권장) 인용 문헌 citekey 목록 (Citation Standard 채택 시)
sourceCallout: 이 질문이 승격돼 나온 원본 wiki 페이지 [[link]] (역추적)
related: 관련 RQ·concept
공통 7 필수 + explored(기본 false). RQ 는 claim 이 아니라 질문이므로 v5 claimType/verificationStatus 대신 위 status 를 쓴다.

Paper Hub (type: paper-hub, v6.2 신설 — 논문 12단 분석 앵커):

paperType: (필수) quantitative / qualitative / theory-concept / mixed-methods / scale-development / meta-analysis
citekey: (필수) BetterBibTeX authYearShorttitle (Citation Standard). Raw Source·허브·원자 동일 토큰. Zotero 미사용 시 provisional citekey.
doi: (선택) DOI 문자열
targetManuscript: (필수) 이 논문이 기여할 Research Question — "[[RQ-…]]" quoted wikilink 또는 none
source: 논문 Raw Source "[[…]]" · collectionPurpose: (v2 재사용) · explored/verificationStatus: v4/v5 그대로
provenance(model/effort) 필수 (에이전트 작성 콘텐츠)

Paper Analysis (type: paper-analysis, v6.2 신설 — 12단 좌표를 가진 지식 원자):

paperType: (필수) 허브와 동일값 (자기완결 + “모든 양적논문 S08” 필터)
analysisStep: (필수) 정수 2~12 (S01 CITATION 은 항상 허브가 보유)
analysisStepName: (필수) 유형별 정식 단계명 (12-Step Analysis Schemes verbatim)
paperHub: (필수) "[[{Surname} {Year} - S00 Hub]]" quoted wikilink
citekey: (필수) 허브와 동일 · source: Raw Source wikilink · status: completed / stub
claimType/evidenceScope 면제 (단일 논문 요약은 퇴화) — 검증은 p7_verify.py 인용 충실도 검사로 대체
provenance(model/effort) 필수

새 YAML 키는 camelCase

✅ collectionPurpose, mainVaultRelated, mainVaultCmds, reusableFor, bookIndex, chapterNumber, chapterPart, chapterPrev, chapterNext, explored, exploredBy, exploredDate, claimType, evidenceScope, verificationStatus, verifiedAt, verifiedBy, disputed, model, effort, citekey, cites, questionType, feedsInto, evidenceFor, evidenceAgainst, sourceCallout, thesis, targetVenue, supports, counters, paperType, analysisStep, analysisStepName, paperHub, targetManuscript, doi, measuredConstruct, itemCount, scanBucket, askedBy, askedVia, satelliteVaultRelated (v1.11 신설 — §Satellite Data Vault, mainVaultRelated와 반대 방향), techBucket (v1.13 신설 — /tech-scan 축: ai/dashboard/powerbi-fabric/llm-wiki/web-build/data-app/knowledge), displayTitle·displayTopic (v1.14 신설 — 30. Queries 문서가 사이트 ‘답변보기(/answers)’ 렌더 시 자기 제목/주제색을 고정. displayTitle은 verbatim(자동 절단 안 함), displayTopic은 색 축 override. generate-answers.ps1 처리), displayTitleZh·displayTitleEn (v1.15 신설 — 사이트 ko/zh/en 다국어화. 30. Queries 문서가 ‘답변보기’ 목록·상세의 zh/en 제목을 직접 지정. 미지정 시 zh/en 화면에서도 한국어 제목 그대로 유지 — 자동번역 안 함, generate-answers.ps1 처리), displayQuestionZh·displayQuestionEn (v1.16 신설 — 같은 다국어화의 연장, 답변보기 목록의 한 줄 질문 미리보기 + 상세 페이지 <p class="lede">용 zh/en 텍스트를 문서가 직접 지정. displayTitleZh/En과 동일한 override 순서(frontmatter pin > 스크립트 내 $questionI18n 맵 > 미지정 시 한국어 유지), generate-answers.ps1 처리)
❌ collection_purpose, main-vault-related, book_index, chapter-number, explored_by, claim_type, verification-status, cite_key, feeds_into — camelCase 네이밍 컨벤션 위반

Citation Standard (v6.1 — 옵션, Zotero-ready 인용 규약)

논문·책·리포트처럼 엄밀한 인용이 필요한 산출물을 목표로 하는 사용자를 위한 옵션 규약이다. 채택하지 않아도 볼트 운영에는 지장 없다 — Research Question / Synthesis 의 cites 는 이 규약 채택 시에만 채운다. 단, Paper Ingest Mode (v6.2) 는 citekey 를 항상 사용한다 — Zotero 미사용 시에도 provisional citekey 를 로컬 생성. 진리 원천은 Zotero (BetterBibTeX) 이며, Wiki 는 citekey 만 참조 → 나중에 Zotero .bib export 가 Pandoc/Obsidian 에서 formatted reference 로 자동 렌더.

Citekey 규약: BetterBibTeX 표준 authYearShorttitle (예: yang2024sweAgent, wu2024longMemEval).
Inline citation: Pandoc/CSL 스타일 [@citekey] (필요 시 [@citekey, p. 12]) — Zotero·Pandoc 네이티브라 export 시 자동 변환.
두 링크의 분리: 내부 지식 참조는 [[wikilink]] (“우리가 컴파일한 X 지식 참조”), 외부 문헌 인용은 [@citekey] (“문헌 X 가 확립함”). 둘은 공존한다. 벤더/2차 소스가 아니라 primary work 를 citekey 로 가리킨다.
cites: frontmatter: 카드가 인용한 citekey 목록. ## References 의 원천.
## References 섹션: 인용 문헌을 나열. Zotero 연동 전에는 수기 full citation (- [@yang2024sweAgent] Yang et al. (2024). SWE-agent... NeurIPS 2024. arXiv:2405.15793), 연동 후 Pandoc 이 자동 생성.
citekey: on Raw Source: 어떤 raw source 가 특정 primary work 의 ingested 사본이면 그 raw source frontmatter 에 citekey 를 달아 [[raw source]](읽은 사본) ↔ [@citekey](정식 인용)를 이중 연결.

Quality Control Properties (v4)

새 Wiki 페이지와 대형 업데이트는 다음 규칙을 따른다:

새 type: wiki-page 는 반드시 explored: false 를 갖는다.
explored: true 는 사람이 읽었거나, 별도 검증 루프에서 source-backed review 를 끝낸 뒤에만 사용한다.
confidence: high 로 올리는 페이지는 반대해석 또는 데이터 공백을 최소 1 줄 기록한다 (Bias Check 콜아웃).
/lint 는 explored 누락, explored: false backlog, high-confidence 페이지의 bias check 누락을 보고한다.

Verification Properties (v5)

v4 Exploration Gate 가 “누가 읽었나”만 추적하던 한계를 보완 — claim 단위 정합성·확증가능성을 형식화. 다음 3 기준으로 모든 Wiki 페이지가 평가될 수 있어야 한다:

지식요건해당성 (Eligibility) — 주어·술어·객체·출처·증거 범위·Claim type 의 6 요소를 갖춘 형식적 지식 단위인가? claimType + evidenceScope 가 분류 가능해야 함.
정합성 (Consistency) — vs source / vs other Wiki pages / vs CLAUDE.md policy / vs Core Context 4 frame 모두에서 충돌이 없는가? 충돌 시 양쪽 페이지에 disputed: true + > [!warning] Disputed Claim callout 으로 보존 — 삭제 금지.
확증가능성 (Confirmability) — 출처 수·종류·반대증거를 종합해 독립적으로 산출한 confidence 가 declared confidence: 와 일치하는가? Overclaim (high-conf + single source) / Underclaim (low-conf + multi-source) 모두 flag.

운영 규칙:

신규 type: wiki-page 의 기본값: verificationStatus: unverified, claimType/evidenceScope 분류 시도, disputed: false (또는 키 생략).
/verify {page} 가 단일 페이지 3 기준 통과 후 verificationStatus: verified + verifiedAt/verifiedBy 기록.
/audit 가 MOC cluster 단위 consistency + sampling 기반 confirmability 로 vault 전체 점수 산출 → Top 10 /verify 큐 생성.
충돌은 항상 disputed 처리. /verify --resolve 만이 disputed → verified 또는 한쪽 confidence 강등 가능.
/query 는 인용 시 verificationStatus + confidence 를 함께 읽고, verified + high 면 단언, partial 또는 medium 이하면 hedge, disputed 면 양쪽 명시 후 답변.

Images & Attachments Policy

모든 이미지·첨부파일은 80. References/Attachments/ 로 일원화. Raw Sources · Wiki · Queries 하위에 이미지 폴더를 만들지 않음.

Obsidian 설정: Settings → Files & Links → Default location for new attachments = 80. References/Attachments/
Web Clipper 가 이미지를 CDN URL 로 남겨도 OK — URL 은 원본의 일부이므로 Raw Source body 에서 그대로 보존 (validate-raw-source.sh hook 이 verbatim 강제)
로컬로 저장해야 하는 이미지 (스크린샷, 사용자 업로드) 는 모두 80. References/Attachments/YYYY-MM-DD-{description}.{ext} 포맷
Wiki 페이지에서 임베드: ![[{filename}]] (Obsidian 단축 경로)

File Naming Convention

Layer	Pattern	Example
Raw Source	`YYYY-MM-DD-{title}.md`	`2026-04-10-Attention-Is-All-You-Need.md`
Raw Source — Book Index	`YYYY-MM-DD-{authorSlug}-{bookSlug}-book-index.md`	`2026-04-20-author-slug-book-slug-book-index.md`
Raw Source — Book Chapter Stub	`YYYY-MM-DD-{authorSlug}-{bookSlug}-ch{NN}-{slug}.md`	`2026-04-20-author-slug-book-slug-ch03-agent-loop.md`
Wiki Page	`{Topic Name}.md`	`Transformer.md`, `Andrej Karpathy.md`
Wiki Page — CJK Person Entity	네이티브 스크립트만 (한글·한자·일본어) · 영문 이름은 aliases	`홍길동.md` (alias: `Gildong Hong`), `张汉东.md` (alias: `Zhang Handong`)
Wiki Page — Latin Person / Handle	원어 표기 그대로	`Andrej Karpathy.md`, `kepano (Steph Ango).md` (핸들 + 실명)
Query Result	`YYYY-MM-DD-Q-{question}.md`	`2026-04-10-Q-How-does-RLHF-work.md`
MOC	`MOC-{Topic}.md`	`MOC-Large Language Models.md`
Research Question	`RQ-{slug}.md` (`20. Wiki/25. Questions/`)	`RQ-agent-memory-architecture.md`
Paper Analysis 폴더	`40. Paper Analyses/{citekey}/`	`40. Paper Analyses/wu2024longMemEval/`
Paper Hub	`{Surname} {Year} - S00 Hub.md`	`Wu 2024 - S00 Hub.md`
Paper 원자	`{Surname} {Year} - S{NN} {세부주제}.md`	`Wu 2024 - S08 평가 지표 분석.md`
Raw Source — TAB Project	`YYYY-MM-DD-{title}.md` (`19. TAB Project/{부서폴더}/`)	`2026-08-01-2026년-3분기-매출실적.md`
Log	`log.md` (단일 파일)	—

CJK Person Naming Rule

한국어·중국어·일본어 이름의 인물 entity 는 네이티브 스크립트로만 파일명을 짓고, 영문 로마자 표기는 aliases 프로퍼티에 둔다:

# 20. Wiki/22. Entities/홍길동.md
---
type: wiki-page
aliases:
  - Gildong Hong
  - 홍길동
  - johndoe   # 핸들도 alias
---

이유: (1) 파일명 중복 (홍길동 (Gildong Hong)) 은 wikilink 작성 시 인지 부담 증가, (2) 영문 표기는 transliteration 일 뿐 고유 이름이 아니므로 aliases 위치가 맞다, (3) Obsidian graph/검색은 aliases 를 인식하므로 접근성에 손실 없음.

적용 대상: 한국인·중국인·일본인 등 CJK 이름을 가진 person entity. 제외: 영문 핸들 + 실명 조합 (kepano (Steph Ango)), 책·제품 등 non-person entity.

Callout Conventions

> [!info] Source
> 
> 출처 또는 참조 정보
 
> [!warning] Contradiction
> 
> 모순되는 정보 플래그
 
> [!warning] Disputed Claim
> 
> (v5) 다른 Wiki 페이지와 충돌하는 claim. 양쪽 페이지에 `disputed: true` + 상호 링크로 보존 (삭제 금지). `/verify --resolve` 만이 해소.
 
> [!question] Open Question
> 
> 아직 해결되지 않은 질문
 
> [!tip] Key Insight
> 
> 핵심 인사이트 강조
 
> [!note] Update
> 
> 최근 업데이트 내용
 
> [!note] Bias Check
> 
> Counter-argument: 가능한 반대해석 또는 과잉일반화 위험
> Data gap: 추가 source, 실제 사용 사례, 수치 검증 등 아직 비어 있는 근거
 
> [!check] Exploration Gate
> 
> Status: explored / unexplored / needs-review
> Evidence: 사용자가 읽은 근거 또는 에이전트 검증 요약
 
> [!info] Analysis Context
> 
> (v6.2) Paper Analysis 원자의 자기완결 계약 — H1 직후 4행 (Paper / 수집맥락 / 위치 Step N/12 / 이 원자+인접).
 
> [!quote] 원문 (p.12, §4.2)
> 
> (v6.2) Paper Analysis 인용 규율 — Raw Source `## Original Content` 에서 verbatim (grep 대조). 페이지 우선 locator (Zotero PDF 로 복구), 없으면 §섹션. 요약을 quote 안에 넣지 않음.

Cross-Vault Reference

(옵션) 이 볼트를 별도 mothership PKM 볼트의 satellite 로 운영할 수 있다. 그럴 경우 양방향 참조 규약:

Vault Registry (채워서 사용)

역할	볼트	경로
Mothership	`{your-mothership-vault-name}`	`{PATH_TO_YOUR_MOTHERSHIP_VAULT}`
Satellite (this)	`{your-llm-wiki}`	`/c/Users/David/Desktop/Vaults/04_GuWiki`

메인 볼트 참조하기 (위성 → 모선)

Obsidian은 볼트 간 직접 wikilink 불가. 다음 조합 사용:

Frontmatter:

source-vault: {your-mothership-vault-name}

Markdown body:

→ {your-mothership-vault-name}: 00. Inbox/{capture-lane}/2026-04-06-llm-wiki-karpathy.md
→ {your-mothership-vault-name}: 30. Permanent Notes/{essay-folder}/📜 예시 에세이...

메인 볼트에서 이 볼트 참조하기 (모선 → 위성)

메인 볼트에 진입점 노트를 만들어 두면 편리합니다 (예시 경로):

{your-mothership-vault-name}/40. Docs/🛰 CMDS_LLM_Wiki Satellite Vault.md

메인 볼트 노트는 이 진입점을 [[🛰 CMDS_LLM_Wiki Satellite Vault]]로 wikilink하고, 구체적 page는 텍스트 참조:

→ LLM Wiki: LLM Wiki Pattern (Concepts)
→ LLM Wiki: MOC-Knowledge Management

Graph view 한계

Obsidian Graph view는 볼트 내부만 시각화. Cross-vault 연결은 frontmatter property로만 인식 가능하며, 사람이 눈으로 읽는 메타데이터로 기능합니다.

Git Integration

이 볼트는 Git으로 버전 관리합니다:

모든 Wiki 변경사항은 commit으로 추적
Ingest 시 commit message: ingest: {source title}
Wiki 업데이트 시: update: {page name} — {변경 요약}
Lint 수정 시: lint: {수정 내용}

TAB Project Wiki

탐색기

CLAUDE

CLAUDE.md — LLM Wiki Schema

⚠️ CRITICAL RULES

Indentation Rules

Wikilink Rules

Description Rule

Provenance Rule (author + model + effort)

Mermaid Rules

Markdown Table Rules

Pre-Flight Checklist (Before Every Write/Edit)

Essential (Post-Compact)

🧭 Core Context (반드시 먼저 로드)

(옵션) Mothership 볼트가 있는 경우

Vault Overview

(옵션) Mothership 볼트 연결

위성 데이터 볼트 연결 (Satellite Data Vault: 05_SalesReport)

3-Layer Architecture

Layer 1: Raw Sources (10. Raw Sources/)

Layer 2: The Wiki (20. Wiki/)

Layer 3: Schema (이 파일)

TAB Project (사내 데이터 프로젝트)

K-Master 브랜드 (Turbo Air 하위 신규 브랜드, 쿼리 기본값 규칙)

TA Service (애프터서비스·부품판매, 쿼리 기본값 규칙)

비한국어 소스 처리 (한국어 요약 병기)

Operations

Cross-Agent Compatibility Matrix

Codex Compatibility Notes

0. Capture Tabs / AI Research Capture (선행 조사 보존)

0-b. Market Scan (TAB 7축 시장·경영 뉴스 수집)

0-c. Tech Scan (TAB 시스템 구축용 기술 자료 수집)

1. Ingest (새 자료 흡수)

2. Query (지식 검색+합성)

3. Lint / Health Check (자가 정화)

4. Source Update (기존 자료 업데이트)

5. Verify (단일 페이지 검증, v5)

6. Audit (전체 볼트 검증, v5)

Folder Structure

70. Outputs/ 규칙 (Tool Output Convention, 옵션)

Frontmatter Standards

필수 프로퍼티 (7개)

Provenance 프로퍼티 (v6 신설 — 항상 기록)

Layer별 추가 프로퍼티

새 YAML 키는 camelCase

Citation Standard (v6.1 — 옵션, Zotero-ready 인용 규약)

Quality Control Properties (v4)

Verification Properties (v5)

Images & Attachments Policy

File Naming Convention

CJK Person Naming Rule

Callout Conventions

Cross-Vault Reference

Vault Registry (채워서 사용)

메인 볼트 참조하기 (위성 → 모선)

메인 볼트에서 이 볼트 참조하기 (모선 → 위성)

Graph view 한계

Git Integration

그래프 뷰

목차

백링크

Layer 1: Raw Sources (`10. Raw Sources/`)

Layer 2: The Wiki (`20. Wiki/`)

`70. Outputs/` 규칙 (Tool Output Convention, 옵션)