ADR-0015 — Stage2 산출물 라우팅¶

Context¶

ADR-0013·ADR-0014가 wiki 자동화 흐름을 박제했지만 Stage2의 sink는 wiki/ 단일. 그러나 d-edu monorepo는 ADR-0004·ADR-0005로 3계층 docs 분리가 이미 정해져 있다:

wiki/ — LLM이 유지하는 도메인·컨셉·결정 (Karpathy 패턴, ADR-0011)
mvp-back/docs/ — Backend architecture · patterns · api-conventions · frd
mvp-front/docs/ — Frontend architecture · frd

Slack 멘션·Notion ingest가 "Backend API 컨벤션 변경", "Frontend 새 화면 FRD" 같은 코드-인접 도큐멘트일 때 무조건 wiki/로만 박제하면 도큐 계층 깨짐. 반대로 모든 ingest를 mvp-back/docs/로 분기하면 LLM wiki의 누적적 성격 (ADR-0011) 깨짐.

본 ADR은 Stage2 산출물의 라우팅 정책.

Decision¶

§A — 산출물 4 sink¶

sink	조건	형식
`wiki/inbox/<n>-<slug>.md`	기본 (키워드 미매치 시)	concept draft, frontmatter `status: draft`
`mvp-back/docs/frd/<feature>/spec.md`	본문에 `[backend-frd]` 또는 "백엔드 FRD" 키워드	ADR-0005 frd schema 준수
`mvp-front/docs/frd/<feature>/spec.md`	본문에 `[frontend-frd]` 또는 "프론트엔드 FRD" 키워드	ADR-0005 frd schema 준수
*`wiki/decisions/ADR-NNNN-.md`**	본문에 `[adr]` 또는 "결정 박제" 키워드	ADR-0011 ADR template

Stage2 prompt 안에서 LLM이 본문 보고 자동 라우팅. 사람이 Issue body 첫 줄에 [backend-frd] 같은 태그를 명시하면 강제 분기.

§B — wiki/inbox → 정식 페이지 승급 (사람 수동)¶

Stage2가 wiki/inbox에 박제한 draft는 사람이 나중에 /wiki-ingest 또는 직접 편집으로 wiki/{domains,concepts,decisions}/로 승급. LLM이 자동 승급하지 않는 이유: ADR-0011 §C "wiki는 careful curation, raw는 unfiltered ingestion". inbox는 unfiltered → curated 사이의 staging.

§C — Stage2 prompt 키워드 라우팅 규칙 (소스 코드)¶

wiki-stage2.yml prompt 안에서 정확히:

1. Issue 본문 첫 줄에 다음 키워드 검사:
   - [backend-frd] 또는 "백엔드 FRD"·"backend FRD" → sink = mvp-back/docs/frd/<slug>/spec.md
   - [frontend-frd] 또는 "프론트엔드 FRD"·"frontend FRD" → sink = mvp-front/docs/frd/<slug>/spec.md
   - [adr] 또는 "ADR" 명시 → sink = wiki/decisions/ADR-NNNN-<slug>.md (NNNN은 max+1)
   - 그 외 → sink = wiki/inbox/<n>-<slug>.md
2. 해당 sink로 1개 파일 박제. 다른 디렉토리 수정 X.

§D — 라벨 확장 (선택)¶

ADR-0014 §C 5개 라벨에 2개 추가 (Stage1 자동 분류):

신규 라벨	색	의미
`docs:backend`	`#5319e7` 보라	mvp-back/docs/frd 대상 — Stage2가 키워드 매치로 자동 부착
`docs:frontend`	`#5319e7` 보라	mvp-front/docs/frd 대상 — 동상

라벨 부착은 Stage1 LLM 분류 단계에서. 사람은 라벨만 보고 PR을 어느 docs에 가는지 즉시 파악.

§E — frontmatter 통일¶

Stage2가 박제하는 3 sink 모두 frontmatter 필수. 형식은 sink 디렉토리 정책 따름:

wiki/inbox/ — ADR-0011 wiki frontmatter (id/title/type/status/sources/updated)
mvp-back/docs/frd/<feature>/spec.md — ADR-0005 frd frontmatter (별도 정책)
mvp-front/docs/frd/<feature>/spec.md — 동상
wiki/decisions/ADR-NNNN-*.md — ADR template (Context/Decision/Consequences/Alternatives/Status/Date)

prompt에 각 sink 별 frontmatter snippet 명시.

Consequences¶

긍정¶

3계층 docs 정합성 유지 — wiki·backend docs·frontend docs 자동 분기로 ADR-0004·ADR-0005 정책 보존
사람 부담 최소 — Issue body에 키워드 한 줄만 적으면 자동 라우팅. 키워드 미명시 시 안전 default (wiki/inbox)
단일 워크플로 — Stage2 1개 YAML이 4 sink 다 처리. 워크플로 폭증 방지

부정¶

prompt 복잡도 ↑ — Stage2 prompt가 라우팅 분기 + frontmatter 분기 모두 처리. max_turns 30 유지·증가 가능성
LLM 분류 오류 위험 — 키워드 미명시 시 backend FRD 본문이 wiki/inbox로 잘못 갈 수도. 완화: 사람이 PR review에서 sink 수정 가능
wiki/inbox 누적 — staging 디렉토리가 정기 cleanup 안 되면 dead pages 누적. /wiki-lint로 1주+ old inbox draft 감지

Alternatives 거부¶

옵션	거부 사유
Stage2 4개로 분리 (stage2-wiki, stage2-backend-frd, stage2-frontend-frd, stage2-adr)	워크플로 폭증 + 라벨 trigger 분기 복잡
모든 ingest → wiki/inbox만, 사람이 docs로 이동	사람 부담 ↑. ADR-0014의 자동화 가치 줄어듦
별도 Stage4 (docs ingest 전용)	Stage1·2·3 흐름과 비대칭. ADR-0013 2단계 정책과 충돌

Status¶

2026-05-25: accepted

Date¶

2026-05-25