Atlas-KK/prd-lifecycle

PRD Lifecycle

원래 분산되어 있던 PRD 생성, 보완, 리뷰 및 실행 계획 기능을 하나의 진입점으로 통합하면서도 각 단계의 서로 다른 권한 경계와 확인 게이트를 유지합니다.

모드 라우팅

사용자가 현재 보유한 자료와 원하는 결과물을 먼저 판단하여 필요한 모드로만 진입하며, 사용자가 처음부터 전체 프로세스를 강제로 따르도록 하지 않습니다.

모드	일반적인 입력	주요 결과물	주요 경계
create 생성	기능 구상 + 기존 저장소	현황 보고서, 확인 기준, 버전 관리된 PRD	먼저 증거 수집, 단계별 확인, 기준선 승인 전까지 PRD 생성 불가
refine 보완	PRD/요구사항 초안	단계별 수정본, 버전 기록, 선택적 .docx	각 단계마다 먼저 검토, 확인 후에만 작성 및 버전 업
review 레드팀 리뷰	지정된 PRD + 선택적 기준선/저장소	등급별 문제, 증거, 수정 제안	리뷰만 수행, 문서 수정 및 코드 구현 금지
execute 실행 계획	승인된 PRD + 기존 저장소	준비 감사, 개발 실행 문서, 추적 매트릭스, 제어 프롬프트	계획만 수립, PRD 수정 및 코드 구현 금지

라우팅 규칙:

• 구상만 있고 기존 프로젝트와 결합하여 PRD를 만들고자 하는 경우: create 사용.
• 이미 초안이 있고 목표가 보완, 수정, 정교화 또는 최종본 생산인 경우: refine 사용.
• 모순, 위험, 누락 또는 검증 불가능한 항목을 찾는 것이 목적이며 대신 수정을 요구하지 않는 경우: review 사용.
• 명확하게 승인된 버전이 있고 Codex에 단계적으로 개발을 맡기는 것이 목적인 경우: execute 사용.
• 사용자가 종단 간(end-to-end) 처리를 요청하는 경우, 가장 빠른 적용 가능 단계부터 시작합니다. 아래 게이트에 도달할 때마다 권한 부여를 기다리며 자동으로 단계를 넘어가지 않습니다.
• "검토해 줘"가 리뷰 또는 대신 수정을 의미할 수 있는 경우, 우선 읽기 전용 review를 사용하고, 리뷰 결과는 사용자가 별도로 권한을 부여하면 refine으로 전환할 수 있음을 설명합니다.
• 사용자가 기존 저장소의 특정 코드, UI, 상호작용, 리팩터링 또는 아키텍처 변경만 평가 및 구현하려는 경우, repo-grounded-change를 사용합니다. PRD를 먼저 작성하도록 강제하지 않습니다.

공유 제약 조건

권위 순서

사용자가 별도로 지정하지 않는 한, 다음 순서로 충돌을 처리합니다.

1. 사용자의 현재 명시적 지시.
2. 현재 작업에서 명확히 확인된 결정.
3. 지정된 승인된 요구사항 기준선 및 PRD.
4. 현재 코드와 테스트로 입증된 기존 동작.
5. 현재 제품 문서.
6. 역사적 초안, 리뷰 기록 및 제안.

대상 PRD가 당연히 올바른 것은 아닙니다. 충돌 발생 시 충돌, 영향 및 필요한 결정을 표시하고, 조용히 한쪽을 선택하지 않습니다. 코드는 현재 상태를 입증하는 데 사용되며, 이미 승인된 새로운 요구사항을 부정할 수 없습니다.

사실 및 제안 레이블

결론이 혼동될 수 있는 경우 사용: 확인됨, 코드 사실, 문서 사실, 제품 가정, 기술 제안, 확인 대기, 이번 주기에서는 구현 안 함.

권한 부여 경계

• 비즈니스 규칙, 상태, 임계값, 권한, 우선순위, 종속성, 외부 통합 또는 승인 기준을 임의로 만들지 않습니다.
• 단계 완료, 리뷰 통과 또는 계획 생성을 구현 권한으로 간주하지 않습니다.
• 비즈니스 코드를 수정하지 않으며, 커밋, 푸시, 배포하지 않고, 외부 프로덕션 시스템을 호출하지 않습니다.
• 작업 트리를 확인하고 사용자의 기존 변경 사항을 보호합니다. 안전하게 회피할 수 없는 경우 중단하고 중복 영역을 설명합니다.
• 사용자가 요청한 현재 모드만 실행합니다. 다음 모드로 전환하려면 명시적인 요청 또는 확인이 필요합니다.

create: 저장소 증거 수집 후 PRD 생성

1. project-discovery.md를 읽고 저장소, 제품 자료, 테스트 및 작업 트리를 확인하여 현재 상태 보고서를 출력합니다. 사용자가 명시적으로 병합 흐름을 요청하지 않는 한, 현황 확인을 위해 중단합니다.
2. clarification-rounds.md를 읽고 증거 격차에 따라 주제를 계획합니다. 각 라운드에서는 하나의 주제만 논의하고 1-3개의 상호 배타적인 선택 문제를 제시합니다. 권장 항목을 앞에 배치하고 영향을 설명합니다.
3. 사용자가 답변한 후, 먼저 이번 라운드의 확인된 항목, 미확인 항목, 충돌 및 하위 영향을 요약한 다음, 이번 라운드 요약 확인을 기다립니다. 미확인 상태에서는 다음 주제로 진행할 수 없습니다.
4. 모든 관련 주제가 확인되면 baseline-and-prd.md를 읽고 요구사항 확인 기준선을 생성한 후 중단합니다.
5. 사용자가 기준선을 명시적으로 승인하고 PRD 생성을 요청한 경우에만 버전 관리된 PRD를 생성합니다. 기존 버전을 검색하여 증가시키며, 조용히 덮어쓰지 않습니다.

완료 기준: PRD가 확인된 결정과 일치하고, 범위와 비목표가 명확하며, 요구사항과 수락이 추적 가능하고, 저장소 영향에 대한 증거가 있으며, 미해결 사항이 최종 요구사항으로 위장되지 않음.

refine: 단계별 보완 및 버전 관리된 수정

1. 전체 원문을 읽고 원래 의미를 유지하며 작업 기준선을 설정합니다. 새로운 Markdown 작업 문서가 필요한 경우 scripts/prd_doc.py init을 사용하여 v1.0 및 섹션 구조를 만듭니다.
2. refinement-steps.md의 현재 단계 하위 섹션을 읽습니다. 기본 구조는 다음과 같습니다.
   • 요구사항 명확화 및 사용자 스토리
   • 기능 계획
   • 경계 조건
   • 수락 기준
3. 한 번에 현재 단계만 수행합니다. 먼저 대화에서 검토할 내용을 제시하고, 파일에 미리 쓰지 않습니다.
4. 사용자가 수정 또는 추가를 요청하면 현재 단계에 머무르며 버전을 올리지 않습니다. 사용자가 명시적으로 확인한 후에만 문서에 작성하고 versioning.md에 따라 마이너 버전 업 및 수정 기록을 수행합니다.
5. 지표, 종속성 일정, 위험 롤백, 규정 준수 또는 리뷰 의견 피드백이 필요한 경우 확장 단계를 삽입할 수 있습니다. 동일하게 "생성 → 검토 → 확인 → 작성 → 버전 업" 게이트를 수행합니다.
6. 모든 단계가 확인되면 전체 초안을 병합하고 메이저 버전 업을 수행합니다. 사용자가 .docx를 요청하는 경우 scripts/prd_doc.py export를 사용하고, 사용 가능한 문서 도구에 따라 형식 검증을 완료합니다.

각 단계의 내용은 보완할 뿐만 아니라 원본의 모호함, 모순, 검증 불가능한 항목 및 놓치기 쉬운 시나리오도 지적해야 합니다. 사용자 스토리, 기능, 경계 및 수락 간에는 역추적이 가능해야 합니다. 수락 항목에는 명확한 조건과 관찰 가능한 결과가 포함되어야 합니다.

수정 완료가 PRD의 비즈니스 승인을 의미하지는 않으며, 자동으로 review 또는 execute로 전환되지 않습니다.

review: 증거 기반 레드팀 리뷰

1. review-protocol.md를 읽고 대상 버전, 리뷰 범위, 권위 있는 출처, 저장소 증거 및 누락된 자료를 확인합니다. 대상 PRD를 전체적으로 읽습니다.
2. 범위, 유형, 상태, 임계값, 권한, 데이터, 시간, 우선순위 및 수락 불변성을 추출합니다.
3. finding-taxonomy.md를 읽고 기준선 회귀, 내부 일관성, 수명 주기, 데이터 기록, 인터페이스 멱등성, 권한 감사, 프로토타입 경계, NFR, 실행 가능성 및 FR/AC 추적을 각각 검사합니다.
4. 중복을 제거하고 증거, 결과 및 수정 가능한 문제만 보관합니다. 포괄적으로 보이기 위해 발견 사항을 만들지 않습니다.
5. review-report.md를 읽고 Pass, Pass with changes, Blocked 또는 Limited review 결과를 제공하고 심각도에 따라 발견 사항, 증거, 영향 및 최소 수정 제안을 출력합니다.

리뷰는 기본적으로 읽기 전용입니다. 명백한 문제가 발견되어도 PRD를 직접 수정할 수 없습니다. 사용자가 수정을 승인한 후에 refine으로 전환합니다.

execute: Codex 개발 실행 문서로 전환

전제 조건은 식별 가능한 버전의 승인된 PRD가 있어야 합니다. 수정 완료 또는 레드팀 통과 자체가 승인을 의미하지는 않습니다.

1. readiness-audit.md를 읽고 PRD 버전, 확인 기준선, 대상 릴리스 범위, 미해결 사항, 현재 저장소 및 테스트를 확인하여 격차 표와 준비 결론을 만듭니다.
2. 제품 동작을 고유하게 결정할 수 없거나, 권위 충돌이 있거나, 수락을 관찰할 수 없거나, 승인되지 않은 종속성/통합/마이그레이션이 필요한 경우 결론은 BLOCKED이며 중단하고 문제를 기술 가정에 숨기지 않습니다.
3. execution-document.md를 읽고 PRD를 충족하는 최소 아키텍처 경계, 소유권, 상태, 데이터, 인터페이스, 지속성, 클록, 성능 저하 및 기존 시스템 보호를 정의합니다.
4. 읽기 전용 Phase 0부터 시작하여 종속성 순서가 있고 독립적으로 검토 가능한 단계를 생성합니다. 각 단계에는 FR/AC, 파일 범위, 금지 사항, 테스트, 수락 증거, 품질 게이트 및 중단 게이트를 명시합니다.
5. traceability-and-gates.md를 읽고 범위 내 각 FR/AC를 단계, 코드 영역, 테스트 및 증거에 매핑하고, 고아 요구사항과 권한 초과 작업을 식별합니다.
6. codex-control-prompt.md를 읽고 마스터 제어 프롬프트와 단계별 프롬프트를 생성합니다. 프롬프트는 버전, 권위 순서, 실제 테스트, 사용자 변경 보호 및 단계별 권한 부여를 유지해야 합니다.

완료 기준: 다른 Codex 인스턴스가 읽기 전용 감사부터 시작하여 승인된 하나의 단계만 실행하고, 실제 명령으로 검증하고, 추적 결과를 보고하고 중단할 수 있어야 합니다. 문서는 가정, 제외 사항, 차단 항목, 연기 항목 및 보호된 동작을 명확히 합니다.

단계 간 전환 게이트

• create → refine: 사용자가 생성된 PRD에 여전히 보완 또는 수정이 필요하다고 판단하는 경우에만 진입합니다.
• create/refine → review: 사용자가 명시적으로 리뷰를 요청해야 합니다. 리뷰가 자동으로 대신 수정하지는 않습니다.
• review → refine: 사용자가 지정된 발견 사항 처리를 명시적으로 승인한 후에 진입하며, 발견 사항 ID와 수정 매핑을 보존합니다.
• create/refine/review → execute: "승인된" PRD 버전과 대상 릴리스 범위를 명시적으로 지정해야 합니다.
• execute → implementation: 실행 문서는 제어 계획만 제공합니다. 실제 구현은 사용자가 후속 작업에서 별도로 승인해야 합니다.

피드백 학습

워크플로우 시작 시 feedback-learning.md 및 learned-guidance.md를 읽습니다. 피드백은 먼저 현재 작업에 적용됩니다. 사용자가 특정 규칙과 범위를 명시적으로 기억하고 확인하도록 요청한 경우에만 지속화가 허용됩니다. 학습된 규칙은 현재 지시, 단계 게이트, 사실 확인, 버전 관리 또는 권한 부여 경계를 재정의할 수 없습니다.