# PRD 작성 및 유지보수 규칙 ## 1. 적용 시점 - 사용자가 새 기능의 요구사항 정리, PRD 작성·보완 또는 구현 계획 전 요구사항 명확화를 요청하면 이 문서를 따른다. - PRD 작성 전에 관련 사용자 요청, 기존 제품 문서, API Contract, 구현 코드와 알려진 제약을 확인한다. - PRD 작업은 요구사항 문서 범위다. 사용자가 구현까지 요청하지 않았다면 애플리케이션 코드와 설정을 변경하지 않는다. ## 2. 기준 템플릿과 위치 - 실제 PRD는 `docs/YYYYMMDD_구현할내용한글/prd.md`에 둔다. - [PRD 샘플](../sample/sample-prd.md)을 원본 템플릿으로 사용하고 필수 section과 추적 필드를 임의로 생략하지 않는다. - 공통 샘플은 `docs/sample/`에서만 관리하며 기능별 문서 디렉터리에 복제하지 않는다. - 실제 PRD에서는 `<...>`, 예시 ID, 선택지와 설명용 placeholder를 모두 구체적인 값으로 교체한다. ## 3. 요구사항 작성 규칙 - 요구사항 ID는 `-NNN` 형식을 사용하고 한 행에는 독립적으로 판정 가능한 요구사항 하나만 기록한다. - 상태는 `확정`, `미결`, `외부 의존`, `권고`, `제외`만 사용한다. - 모든 확정 요구사항에는 사용자가 관찰하거나 test로 판정할 수 있는 수용 기준을 둔다. - 미결 항목에는 현재 권고, 결정 주체와 결정 시점 또는 다음 행동을 기록한다. - 외부 의존에는 담당 주체, 영향받는 기능과 재개 조건을 기록한다. endpoint·DTO·enum·오류 status/key를 추정하지 않는다. - 제외 항목에는 제외 이유, 결정 기록과 다시 포함할 조건을 둔다. - Non-Goal, 반응형 capability, 접근성, 보안·데이터 처리, 성능과 지원 환경을 명시한다. - backend 구현 전 UI 확인이 필요하면 explicit development mock mode, production 금지, no-auto-fallback과 mock/server 완료 상태 분리를 요구사항으로 명시한다. ## 4. 문서 간 추적 - 제품 결정과 사용자 요구는 PRD가 소유한다. - request/response/error와 endpoint 세부 계약은 `api-contract.md`가 소유한다. - 구현 순서, Files, Interfaces, Task/Goal과 완료 증거는 `plan-task.md`가 소유한다. - 모든 확정 요구사항을 API Contract section 또는 명시적인 contract 불필요 판정, 하나 이상의 Phase/Goal, 자동·수동 검증으로 연결한다. - Open Question과 외부 의존을 혼합하지 않는다. 제품이 결정할 수 없는 backend 계약은 별도 외부 의존 ID로 관리한다. ## 5. 변경과 결정 기록 - 요구사항이 변경되면 PRD Decision Log → 관련 요구사항·수용 기준 → API Contract → `plan-task.md` 순서로 갱신한다. - 기존 결정은 삭제하거나 덮어쓰지 않는다. 정정은 날짜·사유·영향 범위와 함께 새 Decision Log 행으로 추가한다. - 구현 중 범위가 달라지면 코드 변경 전에 PRD와 `plan-task.md`를 먼저 갱신한다. - 완료된 요구사항의 회귀나 위반은 [코드 리뷰 및 QA 기록 규칙](./review.md)에 따라 review 문서에 기록하고, 확정된 문제만 회귀 수정 Task/Goal로 전환한다. ## 6. 계획 작성 전 자체 검토 `plan-task.md`를 만들기 전에 다음을 확인한다. - 목표, Non-Goal과 포함·제외 범위가 충돌하지 않는다. - 사용자·권한·핵심 흐름과 라우팅 경계가 명확하다. - 모든 요구사항 ID가 고유하고 상태·수용 기준을 가진다. - 미결·외부 의존·제외 항목에 다음 행동과 담당 주체가 있다. - API endpoint와 payload 규칙이 `api-contract.md`로 추적된다. - 기능·UX·보안·성능 성공 기준이 자동 또는 수동 검증 가능한 표현이다. - placeholder, 근거 없는 최대값과 추정 계약이 없다.