Squashed '.vendor/stage-pilot/' changes from 7ab085e..551777b

551777b feat: add interface contract and data model baseline support to bootstrap-baseline
f17e086 feat: add bootstrap seed file support to bootstrap-baseline skill
be85338 feat: introduce lightweight change path, change-req skill, and release feedback loop
949bb40 docs(skill): new-discovery 병렬 Discovery 및 active-cycle 처리 규칙 강화
7f96130 docs: fix draft-req skill template paths
94b1445 diff --git a/.github/skills/draft-batch-design/SKILL.md b/.github/skills/draft-batch-design/SKILL.md index 5f87d00..944e075 100644 --- a/.github/skills/draft-batch-design/SKILL.md +++ b/.github/skills/draft-batch-design/SKILL.md @@ -1,6 +1,6 @@  ---  name: draft-batch-design -description: "Use when: drafting the design document for an existing batch, running /draft-batch-design with a BAT ID, filling docs/batches/<BAT_ID>/design.md, or recording architecture and interface decisions before implementation." +description: "Use when: drafting the design document for an existing batch, running /draft-batch-design with a BAT ID, filling docs/batches/<BAT_ID>/design.md, recording architecture and interface decisions before implementation, or planning updates to docs/project-structure.md and docs/runtime-flows.md."  argument-hint: "예: bat-001 또는 docs/batches/bat-001_20260424_scaffold"  user-invocable: true  --- @@ -9,27 +9,43 @@ user-invocable: true
d1ce3ce 프로세스 완전 변경

git-subtree-dir: .vendor/stage-pilot
git-subtree-split: 551777bc7009ee133fbaab1267ca324f1dc3c6bb

README.md

@@ -13,6 +13,22 @@ git subtree add --prefix=.vendor/stage-pilot stage-pilot main --squash
 bash .vendor/stage-pilot/bootstrap/install.sh .
 ```
 
+설치 직후에는 Copilot Chat에서 `/bootstrap-baseline`을 먼저 실행해 `docs/project-structure.md`, `docs/runtime-flows.md`, `docs/interface-contract.md`, `docs/data-model.md`, 각 active index를 초기화한다. 이 단계는 Discovery/REQ/Batch/Release 중 어느 것도 아니며, 첫 real Discovery 전에 수행하는 bootstrap 단계다.
+
+greenfield 저장소처럼 읽을 코드나 설정이 없으면 `bootstrap-baseline`은 사용자에게 최소 질문 세트와 필요한 선택 follow-up(`interface-contracts`, `interface-inputs`, `interface-outputs`, `interface-errors`, `core-entities`, `persistence-backend`, `compatibility-rules`)를 묻고, 답변을 `.stagepilot/bootstrap/baseline.yaml`에 저장한 뒤 baseline 문서를 렌더링한다.
+
+seed 파일만 먼저 만들고 싶으면 helper를 사용할 수 있다.
+
+```bash
+# vendor wrapper 사용
+bash .vendor/stage-pilot/bootstrap/stagepilot.sh bootstrap-seed .
+
+# 설치된 script 직접 사용
+python3 .github/scripts/stagepilot-bootstrap-seed.py .
+```
+
+bootstrap-baseline 실행 결과 예시는 `examples/bootstrap-baseline/`에 포함돼 있다.
+
 ## 업데이트
 
 ```bash
@@ -29,112 +45,369 @@ bash .vendor/stage-pilot/bootstrap/update.sh --repo-url https://github.com/genic
 bash .vendor/stage-pilot/bootstrap/update.sh --skip-install .
 ```
 
-## SDLC 프롬프트 사용법
+## 검증
 
-`.github/prompts/`에 단계별 프롬프트가 정의되어 있으며, Copilot Chat에서 `/프롬프트이름 인자` 형태로 실행한다.
+```bash
+# vendor subtree에서 doctor 실행
+bash .vendor/stage-pilot/bootstrap/stagepilot.sh doctor .
 
-### 빠른 시작
+# 설치된 .github/scripts를 직접 실행
+python3 .github/scripts/stagepilot-doctor.py .
 
-처음부터 전체 SDLC 초안 세트를 만들고 싶다면 아래 명령으로 같은 번호의 draft 문서 세트를 한 번에 생성할 수 있다.
+# active docs가 반드시 있어야 하는 workspace라면 엄격 모드 사용
+python3 .github/scripts/stagepilot-doctor.py --strict-missing-docs .
 
-```text
-/new-sdlc 결제 실패 알림 정책을 도입한다
+# Markdown 리포트를 파일로 저장
+python3 .github/scripts/stagepilot-doctor.py --report artifacts/stagepilot-doctor.md .
 ```
 
-이 명령은 `dcy/pln/dsn/imp/ver/rel/ops` 문서를 같은 번호로 모두 `draft` 상태로 만든다. 다만 승인 작업은 Discovery부터 순차적으로 진행해야 한다.
+`stagepilot-doctor`는 아래 항목을 검사한다.
 
-초안 생성 후 순차 검토/승인을 자동 실행하려면 아래 명령을 사용한다.
+- active 문서 루트 존재 여부
+- index와 본문 문서의 상태 동기화
+- REQ traceability matrix (`Discovery -> REQ -> Batch -> Release`)
+- feedback loop summary (`Release -> Discovery/REQ/change-req input`)
+- change-req 이후 상태 되돌림 누락 (`Status Recommendation`, 재검증 필요, 구현 무효화와 현재 REQ 상태의 불일치)
+- orphan REQ (`Approved`인데 batch 미포함, release-candidate batch 미포함 등)
+- feedback 미연결 release (`released`인데 `feedback-captured` 미전환 등)
+- 남아 있는 placeholder
+- 상대 markdown 링크 경로
+- REQ 타입 분류 일관성
+- `Next Requirement ID` 규칙
+- template-skill contract 불일치
+- bootstrap source allowlist drift
+- bootstrap 완료 저장소에서 선택 cross-cutting baseline 문서(`docs/interface-contract.md`, `docs/data-model.md`) 누락
 
-```text
-/run-sdlc dcy-001 홍길동
-```
+active 문서가 아직 없는 패키지 저장소나 초기 host 저장소에서는 package contract 검사만 수행하고, active docs 부재는 기본적으로 warning으로 보고한다.
 
-이 명령은 Discovery부터 Operations까지 순서대로 검토/승인을 시도한다. 이미 승인된 단계는 건너뛰며, 중간 단계에서 승인 불가면 해당 단계에서 멈추고 미충족 항목과 추가 결정사항을 알려준다.
+fresh host 저장소에서 baseline 초기화가 아직 끝나지 않았으면 doctor는 `INFO [bootstrap-required]`로 `/bootstrap-baseline` 실행과 누락된 bootstrap 파일 목록을 함께 안내한다.
 
-### 기본 실행 순서
+`--report`를 주면 findings와 traceability matrix를 별도 Markdown 리포트로 저장한다. 기본 동작은 stdout 출력만 유지한다.
 
-1. Discovery
-2. Planning
-3. Design
-4. Implementation
-5. Verification
-6. Release
-7. Operations
+## 예제
 
-### 단계별 명령 예시
+- `examples/bootstrap-baseline/`: fresh host 저장소에서 `/bootstrap-baseline`을 실행한 직후의 baseline 문서와 sample output
+- `examples/p3-change-management/`: change-req와 suggest-next-discovery가 연결되는 P3 sample workspace
 
-```text
-# Discovery
-/new-sdlc 결제 실패 알림 정책을 도입한다
-/review-discovery sdlc-001
-/confirm-discovery sdlc-001
+## Active 문서 루트와 Source of Truth
 
-# Planning
-/draft-planning sdlc-001
-/review-planning sdlc-001
-/confirm-planning sdlc-001
+### 필수 루트
 
-# Design
-/draft-design sdlc-001
-/review-design sdlc-001
-/confirm-design sdlc-001
+| 경로 | 역할 |
+| --- | --- |
+| `docs/discovery/index.md` | Discovery 전역 인덱스 |
+| `docs/discovery/*.md` | Discovery 본문 |
+| `docs/srs/index.md` | REQ 전역 인덱스와 상태 정의 |
+| `docs/srs/<Type>/req-XXX_<slug>.md` | 개별 REQ 문서 |
+| `docs/batches/index.md` | batch 전역 인덱스 |
+| `docs/batches/<BAT_ID>/planning.md` | batch 계획 |
+| `docs/batches/<BAT_ID>/design.md` | batch 설계 |
+| `docs/batches/<BAT_ID>/implementation.md` | batch 구현 로그 |
+| `docs/batches/<BAT_ID>/verification.md` | batch 검증 근거 |
+| `docs/releases/index.md` | release 전역 인덱스 |
+| `docs/releases/rel-XXX_*.md` | 개별 release 문서 |
 
-# Implementation
-/draft-implementation sdlc-001
-/run-implementation sdlc-001
-/review-implementation sdlc-001
-/confirm-implementation sdlc-001
+### 선택 cross-cutting 문서
 
-# Verification
-/draft-verification sdlc-001
-/review-verification sdlc-001
-/confirm-verification sdlc-001
+| 경로 | 역할 |
+| --- | --- |
+| `docs/project-structure.md` | 저장소 구조, 모듈 경계, 의존 규칙 baseline |
+| `docs/runtime-flows.md` | 대표 entry point와 실행 흐름 baseline |
+| `docs/interface-contract.md` | 외부 API, CLI, 이벤트, 파일 I/O 계약 baseline |
+| `docs/data-model.md` | 핵심 엔티티, 관계, 상태, persistence 규칙 baseline |
 
-# Release
-/draft-release sdlc-001
-/review-release sdlc-001
-/confirm-release sdlc-001
+이 문서들은 active unit 자체는 아니지만 여러 REQ와 batch에서 반복 참조하는 공통 기술 기준선이다.
 
-# Operations
-/draft-operation sdlc-001
-/review-operation sdlc-001
-/confirm-operation sdlc-001
-/operation-triage 문제: 로그인 후 세션 만료 시 특정 브라우저에서 무한 리다이렉트가 발생한다. 증상: 만료된 세션으로 접근하면 /login 과 /callback 사이를 반복 이동한다. 기대 동작: 세션 만료 시 로그인 페이지로 1회 이동하고 재로그인 안내를 보여야 한다. 영향도: Safari 사용자 일부가 서비스 재진입 불가. 재현 조건: Safari 17, 기존 세션 쿠키 보유, rel-001 배포 이후. 관련 문서: rel-001 ops-001
-```
+### 4.2 명령, 템플릿, 가이드 경로
 
-### 문서 ID 규칙
+| 경로 | 역할 |
+| --- | --- |
+| `.github/skills/bootstrap-baseline/SKILL.md` | 프로젝트 시작 시 baseline 문서와 active index를 초기화하는 bootstrap entrypoint |
+| `.github/skills/` | active skill entrypoint 집합 |
+| `.github/skills/run-sdlc/SKILL.md` | 현재 상태를 읽고 다음 skill을 안내하는 orchestrator |
+| `.github/templates/bootstrap/baseline-seed.yaml` | bootstrap 질문 결과를 저장하는 seed 템플릿 |
+| `.github/templates/discovery/discovery.md` | Discovery 생성 템플릿 |
+| `.github/templates/project-structure.md` | baseline 구조 문서 템플릿 |
+| `.github/templates/runtime-flows.md` | baseline 실행 흐름 문서 템플릿 |
+| `.github/templates/interface-contract.md` | 선택형 인터페이스 계약 문서 템플릿 |
+| `.github/templates/data-model.md` | 선택형 데이터 모델 문서 템플릿 |
+| `.github/instructions/placeholder-guide.md` | placeholder 치환 규칙과 active 경로 가이드 |
 
-모든 단계 문서는 동일한 CYCLE_ID를 공유한다.
+### 4.3 비활성 경로 정책
 
-- CYCLE_ID 형식: `sdlc-<3자리>_<YYYYMMDD>_<topic-slug>` (예: `sdlc-001_20260417_stage-pilot`)
-- 각 단계 파일: `1_discovery.md` ~ `7_operation.md`
+- prompt 기반 stage command는 active flow에 포함하지 않는다.
+- legacy stage template는 active source of truth가 아니다.
+- active 작업은 `docs/discovery/`, `docs/srs/`, `docs/batches/`, `docs/releases/` 기준으로만 수행한다.
 
-### 언제 새 Discovery를 만드는가
+## 5. 단위별 상태 모델
 
-운영 중 문제를 발견했을 때는 먼저 `/operation-triage`로 분류한 뒤 아래 기준으로 판단한다.
+### 5.1 Discovery 상태
 
-| operation-triage 판정 결과 | 상황 | 새 Discovery 필요 여부 | 권장 처리 |
-|---|---|---:|---|
-| 구현 문제 | 기존 요구사항/설계/검증 기준은 있었는데 구현이 어긋남, 그리고 관련 문서가 `confirmed` 이후 상태임 | 필요 | corrective change용 Discovery를 새로 만들고 Planning부터 다시 진행 |
-| 구현 문제 | 관련 문서가 모두 `draft`이고 기존 범위 안에서 수정 가능 | 불필요 | 기존 Discovery/Design/Implementation/Verification 문서에 흡수 |
-| 설계·요구사항 누락 | 기능은 있었지만 예외 시나리오, 비기능 요구, 운영 리스크가 빠짐 | 필요 | 누락 요구를 위한 새 Discovery 생성 |
-| 신규 범위 | 기존 SDLC 문서에 실질적으로 없는 기능/정책/요구 | 필요 | 새 Discovery 생성 |
-| 운영 보완만 필요 | 코드/요구 변경 없이 모니터링, 런북, 공지, 절차만 보완 | 불필요 | Operations 문서 보강 |
-| 판단 보류 | 관련 문서 부족, 근거 상충, 재현 불충분 | 보류 | 정보 보강 후 `/operation-triage` 재실행 |
-| Hotfix 필요 | 서비스 중단, 데이터 손실, 보안 영향 등 긴급 대응 우선 | 필요 | Hotfix로 즉시 대응 후 후속 Discovery 생성 및 Postmortem 환류 |
+| 상태 | 의미 |
+| --- | --- |
+| `draft` | 초안 상태이며 REQ drafting 전 |
+| `confirmed` | REQ drafting으로 넘길 수 있도록 확인 완료 |
 
-짧은 판단 기준:
+Discovery는 구현 완료 상태를 표현하는 단위가 아니다. Discovery의 역할은 문제 정의와 handoff 준비다.
 
-1. 완료된 SDLC 결과물을 바꾸는 수정이면 새 Discovery를 만든다.
-2. 아직 draft 단계 문서 보정이면 기존 문서에 흡수한다.
-3. 운영 문서 보완만 하면 되면 새 Discovery는 만들지 않는다.
+### 5.2 REQ 상태
 
-### 참고 파일
+| 상태 | 의미 |
+| --- | --- |
+| `Proposed` | 초안 상태이며 구현 기준으로 확정되지 않음 |
+| `Approved` | 구현 기준으로 승인됨 |
+| `Implemented` | 구현과 검증이 완료됨 |
+| `Deprecated` | 더 이상 유지하지 않음 |
 
-1. 시작 가이드: `.github/START-HERE.md`
-2. 단계 규칙: `.github/instructions/`
-3. 프롬프트 정의: `.github/prompts/`
-4. 템플릿: `.github/templates/`
-5. Operations 템플릿: `.github/templates/operations-note.template.md`
-6. 플레이스홀더 가이드: `.github/instructions/placeholder-guide.md`
+### 5.3 Batch 상태
 
+| 상태 | 의미 |
+| --- | --- |
+| `draft` | batch 초안만 생성된 상태 |
+| `in-delivery` | planning, design, implementation, verification 중 일부가 진행 중 |
+| `release-candidate` | verification 확인이 끝나 release 입력으로 사용 가능 |
+| `released` | 하나 이상의 release에 포함됨 |
+| `archived` | 더 이상 active delivery 단위로 사용하지 않음 |
+
+### 5.4 Release 상태
+
+| 상태 | 의미 |
+| --- | --- |
+| `draft` | release 초안 상태 |
+| `confirmed` | rollout, rollback, verification 준비가 승인됨 |
+| `released` | 배포 실행이 완료됨 |
+| `feedback-captured` | 운영 환류까지 기록 완료 |
+
+## 6. 기본 운영 흐름
+
+### 6.0 프로젝트 시작 시 baseline 초기화
+
+새 저장소에 StagePilot을 처음 적용할 때는 Discovery를 만들기 전에 `bootstrap-baseline`을 먼저 실행한다.
+
+1. `bootstrap-baseline`
+	필요하면 최소 질문 세트(`project-summary`, `primary-domain`, `tech-stack`, `primary-runtime`, `primary-entrypoints`)와 선택 follow-up(`interface-contracts`, `core-entities`)를 묻고, 답을 `.stagepilot/bootstrap/baseline.yaml`에 저장한 뒤 `docs/project-structure.md`, `docs/runtime-flows.md`, `docs/interface-contract.md`, `docs/data-model.md`, `docs/discovery/index.md`, `docs/srs/index.md`, `docs/batches/index.md`, `docs/releases/index.md`를 렌더링한다.
+	이 단계는 bootstrap 단계이며, Discovery/REQ/Batch/Release 단위로 계산하지 않는다.
+	샘플 결과는 `examples/bootstrap-baseline/bootstrap-baseline-output.md`를 참고한다.
+2. `new-discovery`
+	baseline 초기화가 끝난 뒤 첫 real Discovery를 실제 제품/서비스 변경 주제로 생성한다.
+
+이미 코드와 실행 경로가 있는 기존 저장소에 StagePilot을 처음 적용할 때도 시작점은 동일하게 `bootstrap-baseline`이다. 차이는 bootstrap이 질문만으로 baseline을 만들지 않고, 현재 저장소 구조와 실행 흔적을 먼저 읽어 `observed` 또는 `mixed` baseline을 만든다는 점이다.
+
+1. 설치 직후 `python3 .github/scripts/stagepilot-doctor.py .` 또는 `bash .vendor/stage-pilot/bootstrap/stagepilot.sh doctor .`로 누락된 bootstrap 파일과 active docs 상태를 확인한다.
+2. active SDLC 문서가 아직 없다면 `/bootstrap-baseline`을 실행해 기존 저장소 기준의 `docs/project-structure.md`, `docs/runtime-flows.md`, `docs/interface-contract.md`, `docs/data-model.md`, active index를 만든다.
+3. 저장소만으로 프로젝트 정체성이나 계획 runtime을 충분히 설명할 수 없으면 `python3 .github/scripts/stagepilot-bootstrap-seed.py .` 또는 `bash .vendor/stage-pilot/bootstrap/stagepilot.sh bootstrap-seed .`로 `.stagepilot/bootstrap/baseline.yaml`을 먼저 만들고, 그 다음 `/bootstrap-baseline`을 실행해 baseline을 `mixed`로 보강한다.
+4. bootstrap이 끝난 뒤 첫 real Discovery는 baseline 생성 자체가 아니라 현재 진행하려는 기능 변경, 운영 이슈, 기술 결정 중 하나를 주제로 `new-discovery`에서 시작한다.
+5. 이미 `docs/discovery/`, `docs/srs/`, `docs/batches/`, `docs/releases/` 아래 active unit가 운영 중인 저장소라면 bootstrap을 광범위하게 다시 수행하지 말고 `run-sdlc <ID>` 또는 해당 active unit의 skill로 이어서 처리한다. 이 경우 `bootstrap-baseline`은 단순 누락 복구에만 사용한다.
+
+### 6.1 Requirements Phase
+
+1. `new-discovery`
+	baseline 초기화 이후 사용자 요청, 운영 피드백, issue 입력을 실제 변경 주제의 Discovery 초안으로 만든다.
+2. `confirm-discovery`
+	Discovery를 저장소 현실과 대조하고 REQ drafting 가능 상태로 `confirmed` 전환한다.
+3. `draft-req`
+	confirmed Discovery에서 승인 가능한 REQ 문서를 만든다.
+4. `confirm-req`
+	REQ를 `Approved`로 전환한다.
+5. `change-req`
+	기존 REQ 수정이 필요할 때 Change Log 기반 변경 요청을 먼저 기록하고 상태 되돌림/재검증 범위를 판정한다.
+6. `suggest-batch-reqs`
+	Approved REQ를 어떤 batch로 묶을지 후보를 제시한다.
+	`change-req` 이후에도 delivery로 이어질 REQ만 batch 후보로 본다.
+7. `draft-batch`
+	선택된 REQ 묶음으로 `standard` 또는 `batch-lite` profile의 batch 폴더와 기본 문서를 생성한다.
+
+### 6.2 Delivery Phase
+
+1. `draft-batch-planning`
+	batch 범위, 제외 범위, 의존성, 마일스톤, 리스크를 정리한다.
+2. `draft-batch-design`
+	batch 수준의 architecture summary, changed areas, key decisions를 정리한다. `batch-lite`에서 구조 영향이 없으면 생략할 수 있다.
+3. `run-batch-implementation`
+	실제 코드 변경을 수행하고 implementation 문서에 changed files, execution log, validation을 기록한다.
+4. `draft-batch-verification`
+	REQ acceptance criteria를 evidence에 연결한다. `batch-lite`는 planning과 implementation만으로도 검증할 수 있지만, 구조 영향이 생기면 design을 추가해야 한다.
+5. `confirm-batch-verification`
+	evidence가 충분하면 batch를 `release-candidate`로 전환한다.
+6. `confirm-req-implemented`
+	`release-candidate` 또는 `released` batch의 verification evidence를 기준으로 포함 REQ를 `Implemented`로 동기화한다.
+
+### 6.3 Release & Feedback Phase
+
+1. `draft-release`
+	하나 이상의 `release-candidate` batch로 release 문서를 생성하고 `docs-only`, `tooling`, `app-service` 중 하나의 release profile을 선택한다.
+2. `confirm-release`
+	rollout, rollback, verification checklist와 profile별 검증 항목을 점검하고 release를 `confirmed`로 전환한다.
+3. `capture-release-feedback`
+	배포 후 운영 관찰 결과와 후속 Discovery/REQ/change-req 입력을 release 문서에 남긴다.
+4. `suggest-next-discovery`
+	release feedback, baseline gap, 미구현/변경 대기 REQ를 읽고 다음 반복 후보를 추천한다.
+
+### 6.4 경량 변경 경로
+
+아래 조건을 모두 만족하면 `minor-change` fast path를 사용할 수 있다.
+
+- `Approved` REQ가 정확히 1개다.
+- 범위가 문서, 템플릿, 스크립트, bootstrap, 설정처럼 국소적이다.
+- 구조, 인터페이스, runtime flow 변경이 없다.
+- 독립 release가 가능하고 사람 선택이 필요한 묶음 판단이 남아 있지 않다.
+
+이 경로에서는 `suggest-batch-reqs`를 생략하고 바로 `draft-batch`를 실행해 `Profile: batch-lite` batch를 만든다. `batch-lite`는 최초에 `index.md`와 `planning.md`만 만들고, implementation/verification 문서는 해당 단계 진입 시 추가한다. design은 planning의 `Design Gate`가 `yes`가 될 때만 생성한다.
+
+### 6.5 Orchestrator 사용 기준
+
+`run-sdlc`는 현재 문서 상태를 읽고 다음에 실행할 skill을 1단계씩 안내하는 entrypoint다.
+
+- active unit가 아직 없고 baseline 문서나 active index가 비어 있으면 `bootstrap-baseline`을 먼저 제안한다.
+- Discovery 입력이면 `confirm-discovery`, `draft-req`, `suggest-batch-reqs` 중 다음 단계를 제안한다.
+- REQ 입력이면 `confirm-req`, `change-req`, `suggest-batch-reqs`, `draft-batch`, `confirm-req-implemented` 중 다음 단계를 제안한다. 단일 저위험 REQ면 `minor-change -> batch-lite` 경로를 우선 제안할 수 있다.
+- Batch 입력이면 `draft-batch-planning`, `draft-batch-design`, `run-batch-implementation`, `draft-batch-verification`, `confirm-batch-verification`, `confirm-req-implemented`, `draft-release` 중 다음 단계를 제안한다.
+- Release 입력이면 선택된 release profile과 feedback handoff 상태를 기준으로 `confirm-release`, `capture-release-feedback`, `suggest-next-discovery`, `change-req`를 제안한다.
+
+### 6.6 변경 관리와 개선 루프
+
+- 기존 REQ의 `Requirement`, `Acceptance Criteria`, `Impacted Area`를 바꿀 때는 먼저 `change-req`로 새 Change Log 항목을 만든다.
+- 변경이 기존 구현/검증을 무효화하면 REQ 상태를 `Implemented -> Approved` 또는 필요 시 `Proposed`로 되돌린다.
+- release feedback는 `Discovery Input`, `REQ Input`, `Change Request Input`으로 나눠 기록한다.
+- 다음 개선 루프의 우선순위만 먼저 정하고 싶으면 `suggest-next-discovery`를 사용한다.
+
+## 7. Phase Gate 기준
+
+### 7.1 Requirements 완료 기준
+
+아래 조건을 만족해야 Delivery로 넘어간다.
+
+- Discovery가 `confirmed` 상태다.
+- 구현 대상으로 채택할 REQ가 `Approved` 상태다.
+- REQ의 Acceptance Criteria가 구현 판단 가능한 수준이다.
+- 사람 결정 필요 항목과 후속 backlog 항목이 분리되어 있다.
+- 기존 REQ 변경이 있었다면 `change-req` 기록과 상태 동기화가 끝났다.
+
+### 7.2 Delivery 완료 기준
+
+아래 조건을 만족해야 Release & Feedback으로 넘어간다.
+
+- batch planning, implementation, verification 문서가 존재한다.
+- `standard` batch이거나 `batch-lite`에서 구조 영향이 생긴 경우 design 문서가 존재한다.
+- batch에 포함된 REQ acceptance criteria가 evidence와 연결된다.
+- verification blocker가 해소되었다.
+- batch 상태가 `release-candidate`다.
+- 구현과 검증이 완료된 포함 REQ는 필요 시 `Implemented` 상태로 동기화되었다.
+
+### 7.3 Release & Feedback 완료 기준
+
+아래 조건을 만족해야 release 단위를 닫는다.
+
+- release 계획이 `confirmed` 상태를 통과했다.
+- 배포 결과가 기록되었다.
+- 운영 관찰 결과가 release 문서에 남았다.
+- 후속 Discovery, REQ, change-req 입력이 정리되었다.
+
+## 8. 사람 판단이 필요한 경계
+
+다음 항목은 AI가 임의로 확정하지 않는다.
+
+- 승인자 지정
+- Owner 지정
+- 정책 선택
+- 우선순위 승인
+- 외부 시스템 또는 외부 데이터 확인 결과
+- `suggest-batch-reqs` 결과 중 어떤 후보를 실제 batch로 채택할지에 대한 선택
+
+특히 `suggest-batch-reqs`는 추천안을 만드는 단계이며, 최종 batch 묶음은 사람 선택이 필요하다. 따라서 orchestrator는 이 경계에서 자동 진행하지 않고 멈춘다. 단, 단일 저위험 REQ는 `minor-change` fast path로 바로 `batch-lite`를 만들 수 있다.
+
+## 9. 자동화 규칙
+
+### 9.1 Discovery 자동 생성 확장 규칙
+
+현재 StagePilot 기본 패키지에는 GitHub issue label 기반 Discovery 자동 생성 workflow/script가 포함되어 있지 않다.
+
+호스트 저장소가 별도 workflow 또는 script를 추가해 Discovery 자동 생성을 확장할 수 있으며, 그런 자동화는 아래 규칙을 따라야 한다.
+
+- Discovery ID는 `dcy-<3자리>_<YYYYMMDD>_<topic-slug>` 형식을 사용한다.
+- 동일 issue에 대해 반복 실행해도 중복 Discovery를 만들지 않는다.
+- discovery index에 문서 링크와 상태를 등록한다.
+- 결과는 issue comment로 다시 보고한다.
+
+자동화를 추가하지 않는 경우에도 Discovery 생성과 index 갱신의 source of truth는 여전히 `new-discovery` skill과 `docs/discovery/` 문서다.
+
+### 9.2 Index 관리 규칙
+
+- `docs/discovery/index.md`는 자동 생성 및 자동 갱신 결과를 포함할 수 있다.
+- `docs/srs/index.md`, `docs/batches/index.md`, `docs/releases/index.md`는 각 confirm 또는 draft 단계에서 상태와 register를 함께 맞춘다.
+- 상태 변경은 본문 문서와 index가 항상 함께 갱신되어야 한다.
+
+## 10. 표준 작업 절차
+
+### 10.1 신규 기능 또는 운영 이슈가 들어온 경우
+
+1. issue 또는 요청 내용을 기준으로 `new-discovery`를 실행한다.
+2. Discovery를 저장소 현실과 맞춰 보강한 뒤 `confirm-discovery`를 실행한다.
+3. Discovery를 REQ로 쪼개고 `draft-req`를 수행한다.
+4. 각 REQ를 `confirm-req`로 승인한다.
+5. REQ가 여러 개이거나 묶음 판단이 필요하면 `suggest-batch-reqs`로 batch 후보를 받고, 사람이 묶음을 선택한다.
+6. 단일 저위험 REQ면 `draft-batch`를 `minor-change -> batch-lite` 경로로 바로 실행한다.
+7. 그 외 경우 선택된 묶음으로 `draft-batch`를 실행한다.
+8. planning, design(필요한 경우), implementation, verification을 순서대로 수행한다.
+9. `confirm-batch-verification`으로 release-candidate를 만든다.
+10. `confirm-req-implemented`로 구현/검증 완료 REQ를 `Implemented`로 동기화한다.
+11. `draft-release`, `confirm-release`로 배포를 준비하고 실행한다. 이때 release profile은 `docs-only`, `tooling`, `app-service` 중 하나를 선택한다.
+12. `capture-release-feedback`으로 운영 환류를 남긴다.
+13. 필요하면 `suggest-next-discovery`로 다음 반복 후보를 정리하거나, 기존 REQ 수정이면 `change-req`로 바로 연결한다.
+
+### 10.2 이미 존재하는 문서를 이어서 처리하는 경우
+
+1. 가장 가까운 식별자 하나를 선택한다.
+2. `run-sdlc <ID>`로 현재 단위의 다음 skill을 확인한다.
+3. 제안된 다음 skill을 실행한다.
+4. 사람이 결정해야 하는 경계에 도달하면 그 결정만 먼저 확정한다.
+
+## 11. Hotfix 예외 경로
+
+긴급 핫픽스는 Requirements와 Delivery 설계를 경량화할 수 있다. 단, 아래 4가지는 생략하지 않는다.
+
+1. 최소 요구사항 정의
+	증상, 영향, 성공 조건을 기록한다.
+2. 최소 검증
+	재현 테스트 또는 핵심 시나리오 확인을 남긴다.
+3. 배포 전 롤백 계획
+	실패 시 복구 방법을 명시한다.
+4. 배포 후 Postmortem
+	운영 결과를 기록하고 다음 sprint 입력으로 환류한다.
+
+## 12. 유지보수 규칙
+
+이 메뉴얼을 수정해야 하는 경우는 아래와 같다.
+
+- skill 이름이 바뀌는 경우
+- active 문서 루트가 바뀌는 경우
+- 상태 모델이 바뀌는 경우
+- workflow 또는 자동 생성 경로가 바뀌는 경우
+- phase gate 기준이 바뀌는 경우
+
+위 항목이 바뀌면 아래 파일들도 함께 점검한다.
+
+- `.github/copilot-instructions.md`
+- `.github/skills/run-sdlc/SKILL.md`
+- 관련 `confirm-*`, `draft-*`, `run-*`, `capture-*` skill
+- `docs/discovery/index.md`
+- `docs/srs/index.md`
+- `docs/batches/index.md`
+- `docs/releases/index.md`
+
+## 13. 빠른 점검표
+
+### 13.1 Requirements 진입 전
+
+- 요청 또는 운영 이슈가 명확한가
+- 기존 Discovery를 갱신할지 새로 만들지 판단했는가
+
+### 13.2 Delivery 진입 전
+
+- 관련 REQ가 모두 `Approved`인가
+- batch 범위와 제외 범위가 정리되었는가
+
+### 13.3 Release 진입 전
+
+- batch가 `release-candidate`인가
+- rollout plan, rollback plan, verification checklist가 준비되었는가