docs(architect): architect-design-spec.md — A 의 책임 / 부분 그래프 / status lifecycle 규약

[hagyutae]

배경

M4 본격 진입 전 A 의 설계 책임 / 출력 규약 / 그래프 모델 lifecycle 의 spec 문서를 먼저 작성. 이후 M4 의 모든 이슈가 본 문서를 참조 (사용자 답변 A.4 — proposal 너무 길어 별도 문서 추천).

스코프

docs/architect-design-spec.md 신규 작성

다룰 내용:

1. A 가 만드는 설계 결과물의 구성

   • 기술 스택 결정 (배경 / 근거)
   • OO 모델링 — 모듈 / 인터페이스 / 클래스 그래프
   • 데이터 모델
   • 모듈별 docstring (요약)
   • 설계 주요 특징

2. 그래프 출력 규약

   • 부분 그래프 원칙 (사용자 답변 A.5) — 지시 받은 요구사항 관련 노드만, 인접 일부만 포함
   • mermaid 표현 형식 (classDiagram / flowchart 등)
   • 사용자 인터페이스에서 mermaid 렌더링 가정

3. graph db 의 노드 lifecycle

   • status: "designed" \| "implemented" property 표현 (사용자 답변 Q7)
   • 노드 ID 동일 유지, status 만 전이
   • lifecycle 전이 규칙 (designed → implemented 는 M5+ Eng diff 색인 시점)

4. A → L (graph 도구) 인터페이스

   • graph_upsert(nodes, edges, status) — 신규 / 변경 노드 upsert
   • get_neighborhood(node_id, depth) — 영향 분석 / 부분 그래프 탐색

5. A 의 sub-agent 루프 (proposal §3.2 참조)

   • 메인 설계 → 검증 → 최종 컨펌 (LLM 모델 분리 가능)
   • self-validation 과 사용자 컨펌의 역할 분담

6. 사용자와의 상호작용 패턴

   • 도중 의견 구하기 — INPUT_REQUIRED state + UG 라우팅
   • 1차 컨펌 (M4 종착점)

비-스코프

• 실제 코드 구현 (별 이슈)
• proposal.md 본문 보강 (별도 chore 로 차후)

검증

• 문서 commit
• M4 의 다른 이슈들이 본 문서를 reference 로 사용
• 사용자 리뷰 — 의도와 일치하는지 확인