# wiki/ 폴더 규칙

AI가 raw/의 원본을 읽고 편집·유지하는 산출물 계층. 자세한 운영 규칙(Ingest/Query/Lint, 위키 규칙 14가지)은 `docs/CLAUDE.md`의 Wiki Schema 섹션을 따른다.

## 구조
- `index.md` — 전체 카탈로그. 모든 질의는 여기서 시작한다.
- `log.md` — 연대기 로그. append-only.
- `pages/B0x_이름/` — 프로젝트의 실제 B01~B09 폴더와 1:1 대응하는 페이지 단위 폴더. 하위에 `frontend.md`, `backend.md`, `db.md`, `api.md`, `dependencies.md`를 필요한 것만 생성한다.
- `concepts/` — 여러 페이지가 함께 쓰는 공유 자원의 1차 정의처. DB 스키마, 인증/RBAC, 저장 경로 규칙, 공통 유틸(`common_util_*`), API 공통 엔드포인트, 공통 Pydantic 스키마, 외부 라이브러리 의존성, workflow 상태 관리 등.

## 작성 규칙
- 모든 페이지에 YAML frontmatter 포함. `status`는 `draft`/`stable`/`stale` 셋 중 하나만 사용 (draft=계획서만 반영, stable=검증보고서로 확인, stale=raw 갱신됐는데 미반영).
- **`pages/` 하위 파일에는 반드시 `page_id: B0x_이름`(또는 `A0x_이름`)을 frontmatter에 추가한다.** 파일명(`frontend.md` 등)만으로는 소속 페이지를 알 수 없으므로, 폴더 밖에서 봐도 식별 가능해야 한다. concepts 파일에는 해당 없음.
- 내부 참조는 `[[페이지명]]` 위키링크 형식.
- 새 페이지를 만들기 전에 기존 페이지를 업데이트할 수 있는지 먼저 확인한다.
- 소스 요약은 사실만, 해석·종합은 concepts 페이지에서 다룬다.
- 계획서와 검증보고서가 충돌하면 **검증보고서를 채택**한다 (실제 코드 상태에 더 가까운 소스). 계획서 내용은 지우지 않고 "계획 당시 의도"로 남긴다.
- **공유 자원(두 페이지 이상이 쓰는 테이블·함수·API·의존성 등)은 concepts에만 정의한다.** 페이지 쪽 파일(`db.md` 등)에는 용도 설명 + 위키링크만 남긴다. concepts 쪽에는 사용처(역참조) 목록을 직접 적어 유지한다.
- **함수·API·테이블 등 개별 항목은 `항목 | 위치(파일:줄번호) | 역할` 표 형식으로만 기록한다.** 서술문 금지 — grep 없이 바로 코드 위치를 찾을 수 있어야 한다.
- **페이지(파일) 하나는 100줄을 넘지 않는다.** 넘으면 하위 주제별로 즉시 분할하고 index.md를 갱신한다.