okstra 0.39.0 → 0.40.0

package/docs/kr/architecture.md

@@ -384,6 +384,13 @@ okstra phase 는 PRD / issue file 을 직접 쓰지 않습니다. 동등한 결
 위상정렬이 담고, task 화 이후의 통합 일정은 okstra-schedule 이 맡는다. okstra-brief 는
 이 경로에 개입하지 않는다. 검증: `validators/validate_fanout.py`(validate-run 훅).
 
+### branch_confirm (worktree 결정 확인)
+
+okstra-run wizard 는 최종 confirm 직전에 `branch_confirm` 단계로 "새 브랜치/worktree 생성 vs
+현재 worktree 재사용"을 명시 확인한다. 결정은 `worktree.preview_worktree_decision()`(부수효과 없음)
+으로 미리보고, 같은 헬퍼를 `provision_task_worktree` 가 실행에 쓰므로 미리보기와 실제가 일치한다.
+worktree 격리 동작 자체는 변경 없음(확인 게이트만).
+
 
 ---
 
@@ -855,7 +862,7 @@ Claude가 작성하는 최종 보고서는 아래 구조를 우선 사용합니
 - `## 1. 문제 또는 검증 대상 요약` — §1.1 Consensus / §1.2 Differences 표 각각 `Source items (worker:item)` 컬럼 보존 (cross-worker traceability).
 - `## 2. 에이전트별 실행 현황`
 - `## 3. Cross Verification 결과` — §3.1 Primary Evidence 에 `Source items (worker:item)` + `Source (path:line / log)` 컬럼.
-- `## 4. 최종 판단` — `implementation-planning` 의 §4.5.9 Plan Body Verification 은 두 표 (`Verdict summary` 4-열, `Verdict details` 5-열, plan item × worker) 로 분할 emit.
+- `## 4. 최종 판단` — `implementation-planning` 의 §4.5.9 Plan Body Verification 은 `Verdict details` 표 (5-열, plan item × worker) 하나로 emit.
 - `## 5. Clarification Items` — 통합 8-열 표 한 곳. 기존 §5.1 / §5.2 / §4.5.8 / §4.5.9 Open Questions 는 deprecated 되어 validator 가 등장 시 fail.
 - `## 6. 권장 다음 단계`
 - `## Token Usage Summary` — sentinel (`pending` / `N/A` / `--` / `?` / 빈 셀) 또는 zero (`0` / `$0.00`) 박제 시 validator 가 출고를 차단합니다. `Codex/Gemini CLI 추가 비용` 행만 "CLI 미사용" 의미로 `$0.00` 허용.
@@ -904,7 +911,8 @@ Phase 7 step 1.5 가 final-report MD 한 본을 입력으로 두 view 를 결정
 - `scripts/okstra-codex-exec.sh`, `scripts/okstra-gemini-exec.sh` 는 dispatch 마다 prompt path 옆에 `<prompt>.log` sidecar 를 만들고 stdout 을 거기로 mirror 합니다 (`tee`, `PIPESTATUS[0]` 로 종료코드 보존). stderr 은 같은 파일에 append (subagent stderr 캡처 contract 보존), 매 dispatch 시 truncate. 호출 subagent 의 `BashOutput` 폴링은 60s 간격이라 long-running run (analysis 의 large-codebase scan, implementation 의 cargo / pytest) 동안 사용자가 stalled state 를 탐지할 수 없는 문제를 해소합니다.
 - `$TMUX` 가 셋팅된 lead 환경이면 wrapper 가 sibling pane 을 자동 분할해 `tail -F <log-path>` 를 띄웁니다. trace pane title 은 `<cli>-<role>-<pid>-trace[from=<caller-pane-id>]` (e.g. `codex-worker-93421-trace[from=%5]`, `gemini-executor-93422-trace[from=%5]`); 동일 시점에 caller (worker) pane title 도 `<cli>-<role>-<pid>` 로 셋팅됩니다. `<pid>` 는 wrapper 자기 자신의 PID 라서 동일 role 의 worker 가 둘 이상 동시에 spawn 돼도 서로 구분되며, trace title 에 박힌 caller pane id 덕분에 worker pane title 이 외부에서 덮어써져도 (Claude Code TUI 가 OSC 2 escape 로 자기 pane title 을 지속 emit) trace ↔ worker 매핑이 깨지지 않습니다. caller pane id 는 우선 `$TMUX_PANE` 에서, 비어 있으면 `tmux display-message -p '#{pane_id}'` (active pane) 으로 fallback — Claude Code Bash tool 환경처럼 `$TMUX_PANE` 가 stripping 돼도 caller pane 을 정확히 잡습니다. trace pane split 도 caller pane 을 `-t` 로 명시 anchor 합니다. role 은 wrapper 의 5번째 optional positional 인자이며, 누락 시 기본값 `worker` 로 떨어집니다. caller 가 다른 라벨(예: `executor`)을 원하면 5번째 인자로 명시해야 합니다. wrapper 진입 직전의 caller pane title 은 capture 해두고 EXIT trap 에서 복원하므로, dispatch 사이의 stale title 이 남지 않습니다. focus 는 caller pane 으로 복귀하고, CLI 종료 후 pane 은 유지돼 스크롤백 가능. `$TMUX` 미설정, split 실패, 구버전 tmux 등 모든 경로는 silent degrade.
 - **Claude `/exit` 시 자동 정리**: trace pane 의 `tail -F` 는 tmux 셸의 자식이라 Claude 가 종료돼도 살아남는 문제를 막기 위해, wrapper 는 spawn 한 pane id 를 caller `$TMUX_PANE` 으로 키된 registry (`${TMPDIR:-/tmp}/okstra-trace-panes/<caller-pane>.list`) 에 append 합니다. `templates/reports/settings.template.json` 의 `hooks.SessionEnd` 가 `$HOME/.okstra/bin/okstra-trace-cleanup.sh` 를 호출해 자신의 caller pane registry 만 읽어 `tmux kill-pane` 합니다. caller pane 단위로 scope 가 잡혀 있어 같은 tmux 세션에 Claude 인스턴스가 여러 개 떠 있어도 서로의 trace pane 을 죽이지 않습니다. tmux 가 없거나 stale pane id 인 경우 silent degrade.
-- **Phase 종료 시 사용자 확인**: 매 phase 의 마지막 단계로 lead 가 `okstra-trace-cleanup.sh --list` 로 등록된 pane 목록을 출력한 뒤 사용자에게 "모두 닫기 / 그대로 두기" 양자택일을 묻고 응답대로 처리합니다 (`prompts/profiles/_common-contract.md` 의 *Phase wrap-up* 항목). `$TMUX_PANE` 미설정 환경에서는 단계 자체가 silent-skip. `--list` 모드는 pane 을 죽이지 않고 `<pane_id>\t<pane_title>` 만 출력하므로 사용자가 무엇이 닫힐지 시각적으로 확인할 수 있습니다.
+- **phase 전환 시 자동 정리 + worker-agent pane 포함**: `okstra-trace-cleanup.sh` 는 trace pane(registry) 뿐 아니라 dispatch 된 서브에이전트가 점유하는 worker-agent pane(title `claude-worker` / `codex-worker` / `gemini-worker` / `report-writer-worker`)도 lead 세션(`tmux list-panes -s`) 범위에서 title allowlist 로 식별해 닫습니다. lead 자신의 pane(`$TMUX_PANE`)은 title 이 걸려도 절대 죽이지 않습니다. lead 는 새 phase 의 worker 를 dispatch 하기 직전(`PROGRESS: phase-5.5-convergence` / `phase-6-synthesis` 마커 직전) 이 스크립트를 무인자로 호출해 이전 phase 의 pane 을 prompt 없이 정리합니다.
+- **Phase 종료 시 사용자 확인**: run 최종 종료 시점(마지막 단계)에 lead 가 `okstra-trace-cleanup.sh --list` 로 잔여 okstra pane(worker-agent + trace) 목록을 출력한 뒤 사용자에게 "모두 닫기 / 그대로 두기" 양자택일을 묻고 응답대로 처리합니다 (`prompts/profiles/_common-contract.md` 의 *Phase wrap-up* 항목). `$TMUX_PANE` 미설정 환경에서는 단계 자체가 silent-skip. `--list` 모드는 pane 을 죽이지 않고 `<pane_id>\t<pane_title>` 만 출력하므로 사용자가 무엇이 닫힐지 시각적으로 확인할 수 있습니다.
 - 디스크 누적은 `okstra-logs` skill 이 read-only 로 인벤토리 + cleanup 명령을 제안합니다 (실행은 사용자 copy-paste).
 
 ### Linked-worktree `.git/` write 권한 (codex / gemini)

package/docs/kr/cli.md

@@ -591,4 +591,4 @@ chmod +x ~/.local/bin/okstra-ctl
 
 ### Live-log sidecar
 
-codex / gemini wrapper 는 매 dispatch 마다 `runs/<task-type>/prompts/<worker>-prompt-<phase>-<seq>.log` sidecar 를 만들고 stdout / stderr 를 mirror 합니다. tmux 안에서 lead 를 띄우면 wrapper 가 자동으로 `tail -F` pane 을 분할합니다 (trace pane title: `<cli>-<role>-<pid>-trace`, caller (worker) pane title: `<cli>-<role>-<pid>` — wrapper PID 가 동일 role 의 동시 dispatch 를 구분합니다). 분할된 trace pane 은 caller `$TMUX_PANE` 으로 키된 registry 에 등록돼, Claude `/exit` 시 `SessionEnd` 훅이 `okstra-trace-cleanup.sh` 로 자동 정리합니다. 사용량 인벤토리와 `find … -delete` cleanup 명령은 `okstra-logs` skill 이 read-only 로 제안합니다. 자세한 와이어링은 [`docs/kr/architecture.md`](architecture.md) 의 *Live-log mirror* 절 참고.
+codex / gemini wrapper 는 매 dispatch 마다 `runs/<task-type>/prompts/<worker>-prompt-<phase>-<seq>.log` sidecar 를 만들고 stdout / stderr 를 mirror 합니다. tmux 안에서 lead 를 띄우면 wrapper 가 자동으로 `tail -F` pane 을 분할합니다 (trace pane title: `<cli>-<role>-<pid>-trace`, caller (worker) pane title: `<cli>-<role>-<pid>` — wrapper PID 가 동일 role 의 동시 dispatch 를 구분합니다). 분할된 trace pane 은 caller `$TMUX_PANE` 으로 키된 registry 에 등록돼, Claude `/exit` 시 `SessionEnd` 훅이 `okstra-trace-cleanup.sh` 로 자동 정리합니다. 같은 스크립트는 dispatch 된 worker-agent pane(title `claude-worker` / `codex-worker` / `gemini-worker` / `report-writer-worker`)도 lead 세션 범위에서 함께 정리하며(lead 자신의 pane 은 제외), lead 는 새 phase dispatch 직전 이를 호출해 이전 phase 의 okstra pane 을 자동 정리합니다. 사용량 인벤토리와 `find … -delete` cleanup 명령은 `okstra-logs` skill 이 read-only 로 제안합니다. 자세한 와이어링은 [`docs/kr/architecture.md`](architecture.md) 의 *Live-log mirror* 절 참고.

package/docs/project-structure-overview.md

@@ -163,7 +163,7 @@ Top-level scripts:
 | `okstra-render-report-views.py` | Render slim MD + HTML views from final-report Markdown |
 | `okstra-error-log.py` | Normalize worker/lead error sidecars |
 | `okstra-spawn-followups.py` | Follow-up spawning helper |
-| `okstra-trace-cleanup.sh` | tmux trace pane cleanup |
+| `okstra-trace-cleanup.sh` | tmux okstra pane cleanup (worker-agent + trace, lead pane 제외) |
 
 ### 4.3 `scripts/okstra_ctl/` — Python orchestration core
 

package/docs/superpowers/plans/2026-06-02-final-verification-protocol-hardening.md

@@ -0,0 +1,326 @@
+# final-verification 검증 프로토콜 강화 Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** final-verification 을 "리뷰 의견 수집"에서 **target 일치성 → 요구사항 커버리지 → read-only validation → 구조화된 verdict** 로 이어지는 검증 프로토콜로 강화한다.
+
+**Architecture:** lead 의 강한 entry gate 와 동일한 기준을 (1) 워커 dispatch contract, (2) 입력 템플릿, (3) report schema/template, (4) validator 에 구조화해 전달·강제한다. 변경은 저위험 prose/contract(PR1)와 고위험 schema/validator(PR2) 둘로 나눈다.
+
+**Tech Stack:** Markdown 프로파일/템플릿, JSON Schema, Python(validate-run.py + pytest), Jinja2 렌더 + i18n(en/ko json), okstra 빌드(`npm run build`).
+
+근거: 본 계획은 두 출처를 병합한다 — (A) 검증 초점 분석(이 세션), (B) 다른 에이전트의 final-verification contract 분석. 아래 모든 항목은 소스 직접 확인으로 검증됨.
+
+---
+
+## 범위 결정 (먼저 확인)
+
+- **PR1 (저위험, schema 무변경):** 프로파일 prose 정정 + 검증 초점 재설계 + 워커 dispatch target snapshot + 입력 템플릿. 단독으로 가치 있음.
+- **PR2 (고위험, breaking — pre-1.0 라 compat 불필요):** report schema/template/i18n + validator 강제 + golden fixture. PR1 위에 쌓는다.
+- **범위 밖 (별도):** `analysis-material` 이 brief 전체를 복사하는 중복([material.py](../../../scripts/okstra_ctl/material.py)). **모든 task-type 에 영향을 주는 cross-cutting** 이라 이 PR 들에 섞지 않고 별도 후속 작업으로 분리.
+
+브랜치: PR1/PR2 각각 `main` 기준 새 브랜치 (pane-cleanup PR 과 무관).
+
+---
+
+## File Structure
+
+**PR1**
+- Modify: `prompts/profiles/final-verification.md` — 검증 초점 재설계, no-mutation audit 범위 축소, routing vocab, section-name 호환, conditional-accept 참조, deliverable target-snapshot.
+- Modify: `templates/worker-prompt-preamble.md` — `implementation` 전용 Worktree 블록을 `final-verification` 까지 확장(+ base ref / head SHA / diff stat anchor).
+- Modify: `templates/reports/final-verification-input.template.md` — `## Requirement Coverage Source` 섹션 + target/requirement 질문.
+
+**PR2**
+- Modify: `schemas/final-report-v1.0.schema.json` — `sourceImplementationReport`(diffSummaryQuote/implementationBaseRef/gitDiffStat), `finalVerdict`(conditionalAcceptanceConditions), `ReadonlyCommandRow`(status/nullable exitCode/rejectionReason).
+- Modify: `templates/reports/final-report.template.md` — §4.8.1 새 필드 렌더, §4.8.x Conditional Acceptance Conditions, Read-only Command Log status 렌더.
+- Modify: `templates/reports/i18n/en.json` + `ko.json` — 신규 `evidenceMeta`/라벨 키.
+- Modify: `validators/validate-run.py` — verdict↔blocker/condition/routing 일관성 강제 + 섹션 목록.
+- Modify: `tests/test_validate_run.py`(또는 해당 파일) — 강제 로직 회귀 테스트.
+- Modify: `tests/fixtures/reports/golden-final-verification.md`, `tests/fixtures/final-report-data/final-verification-001.data.json` — 새 필드 반영.
+- Modify: `CHANGES.md` — 사용자 영향 엔트리(PR2 에서, 또는 양쪽).
+
+`runtime/` 는 gitignored build output — 커밋에 포함 안 함. profile/template/preamble/schema/i18n 변경 후 `npm run build` 로 동기화.
+
+---
+
+# PR1 — 저위험 prose / contract
+
+## Task 1: 검증 초점 재설계 + Expected output emphasis 제거
+
+**Files:** Modify `prompts/profiles/final-verification.md:11-21`
+
+- [ ] **Step 1:** `Primary focus areas` + `Expected output emphasis` 블록(11-21행)을 아래로 교체.
+
+```markdown
+- Primary focus areas (each maps to a deliverable section below):
+  - Acceptance-gating — a failure here pushes the verdict toward `blocked` / `conditional-accept`:
+    - requirement & acceptance coverage — every must-pass point in the brief's `## Acceptance Criteria` (and the approved plan's requirements) is covered with a cited artifact or raised as an Acceptance Blocker; no silent omissions
+    - delivered artifacts match recorded expected values in `reference-expectations` (config files, deployment manifests, other recorded expected states); when reference-expectations are absent, record it as missing information rather than assuming a match
+    - test & validation suite pass status — independently re-run the read-only two-tier command set (Tier 1 = brief/approved-plan `validation`, Tier 2 = `project.json` `qaCommands`) and confirm each passes on the verified head, citing exact command + exit code
+    - test correctness — delivered tests actually assert the intended behaviour: no gutted/weakened assertions, no tautological or always-passing tests, no tests exercising only mocks; new behaviour has matching coverage
+    - no new defects introduced — the diff does not break previously-working behaviour and adds no new bug (logic/off-by-one, null/empty handling, resource leaks, broken error paths)
+    - scope conformance — the delivered diff stays within the approved plan's scope; flag out-of-scope edits, unrelated file changes, leftover debug/commented-out code, and unintended deletions
+  - Residual-tracked — note as Residual Risk unless severe enough to block:
+    - unresolved edge cases
+    - regression risk in adjacent code paths not directly changed
+    - documentation or rollout gaps
+    - production-specific failure modes not caught by tests (env/config drift across stages, secrets & permission/auth changes, migration ordering & rollback executability, observability gaps)
+```
+
+- [ ] **Step 2:** `grep -n "Expected output emphasis" prompts/profiles/final-verification.md` → 0건(제거 확인). `grep -rn "Expected output emphasis" tests/ validators/` → 0건(참조 없음, 이미 확인됨).
+- [ ] **Step 3:** `npm run build && bash validators/validate-workflow.sh` → OK.
+- [ ] **Step 4:** commit `feat(profiles/final-verification): 검증 초점 재설계 — gating/residual 2계층 + 테스트정확성·범위·신규버그 추가`.
+
+## Task 2: no-mutation audit 범위 축소 (자기모순 제거)
+
+**Files:** Modify `prompts/profiles/final-verification.md:43`
+
+- [ ] **Step 1:** self-review 5번 항목을 교체.
+
+old:
+```
+  5. **No-mutation audit** — scan the run's session transcripts for any Edit / Write / mutating Bash command. Any occurrence means the run has crossed into implementation and MUST be re-routed; do NOT silently strip the evidence.
+```
+new:
+```
+  5. **No source-mutation audit** — scan the run's session transcripts for Edit / Write or state-mutating Bash commands that touch paths OUTSIDE `<PROJECT_ROOT>/.okstra/**` and outside the assigned run-artifact paths. Writes to worker prompts, audit sidecars, team-state, the final-report `data.json`, and rendered reports under the run directory are allowed okstra artifacts. Any source/schema/deployment mutation means the run has crossed into implementation and MUST be re-routed; do NOT silently strip the evidence.
+```
+
+- [ ] **Step 2:** `npm run build` → OK. commit `fix(profiles/final-verification): no-mutation audit 를 source-mutation 으로 한정 (.okstra artifact 허용)`.
+
+## Task 3: routing vocabulary + section-name 호환 + conditional-accept 참조
+
+**Files:** Modify `prompts/profiles/final-verification.md` (23, 29, 35행)
+
+- [ ] **Step 1 (routing, 35행):** `Routing recommendation` deliverable 줄 교체.
+
+old:
+```
+  - **Routing recommendation**: brief note on the next safe phase (`done`, `error-analysis`, `implementation-planning`) tied to the verdict and blocker list.
+```
+new:
+```
+  - **Routing recommendation**: the next safe phase — one of `release-handoff`, `done`, `error-analysis`, `implementation-planning` — tied to the verdict and blocker list. `release-handoff` is allowed ONLY when the Verdict Token is `accepted`.
+```
+
+- [ ] **Step 2 (section-name 호환, 23행):** entry-gate 줄에서 implementation report 필수 섹션 인용을 양쪽 표기 허용으로.
+
+old fragment: ``includes `Plan link & approval evidence`, `Commit list`, ``
+new fragment: ``includes the approved-plan reference (heading `Approved Plan Reference` or `Plan link & approval evidence`), `Commit list`, ``
+
+- [ ] **Step 3 (conditional-accept 참조, 29행):** `conditional-accept` 설명에 구조화 deliverable 참조 추가(현 문장 끝에 append).
+
+append: ` Each condition MUST be recorded as a row in the **Conditional Acceptance Conditions** deliverable (id, condition, evidence required, blocks-release-handoff).`
+
+> 주의: 이 줄은 PR2 의 §4.8 Conditional Acceptance Conditions 섹션·schema 와 짝이다. PR1 만 단독 머지할 경우 이 Step 3 는 PR2 와 함께 가도록 보류 가능 — 실행 시점에 결정.
+
+- [ ] **Step 4:** `npm run build && bash validators/validate-workflow.sh` → OK. commit `fix(profiles/final-verification): routing 에 release-handoff 추가 + approved-plan 섹션명 호환`.
+
+## Task 4: 워커 dispatch 에 verification target snapshot 전달
+
+**Files:** Modify `templates/worker-prompt-preamble.md:84-88`, `prompts/profiles/final-verification.md`(deliverable)
+
+- [ ] **Step 1 (preamble):** `For the implementation phase specifically...` 블록(84-88)을 implementation + final-verification 둘 다 커버하도록 교체.
+
+old:
+```
+For the **implementation phase** specifically, the dispatched prompt MUST also include:
+
+- `**Worktree:** <absolute-path>` — the task worktree path.
+- `cwd for every mutating command: <absolute-path>` — same as Worktree path; used by codex / gemini wrappers as `--add-dir` / `--include-directories`.
+```
+new:
+```
+For the **implementation phase** specifically, the dispatched prompt MUST also include:
+
+- `**Worktree:** <absolute-path>` — the task worktree path.
+- `cwd for every mutating command: <absolute-path>` — same as Worktree path; used by codex / gemini wrappers as `--add-dir` / `--include-directories`.
+
+For the **final-verification phase** specifically, the dispatched prompt MUST also include the verification target snapshot so every analyser verifies the SAME target the lead captured at the entry gate:
+
+- `**Worktree:** <absolute-path>` — the checkout under verification (read-only).
+- `**Verification base ref:** <base-ref>` — the implementation base for the diff.
+- `**Verification head SHA:** <sha>` — head SHA captured at run start.
+- `**Verification diff stat:** <git diff --stat output>` — the captured diff-stat that bounds the verification scope.
+```
+
+- [ ] **Step 2 (profile deliverable, final-verification.md "Source Implementation Report" deliverable 28행 근처):** 워커가 이 snapshot 을 기준으로 검증하고 보고서가 cite 하도록, deliverable 의 Source Implementation Report 항목에 한 줄 추가:
+
+append: ` The lead injects this same target snapshot into every analyser prompt (`**Worktree:** / **Verification base ref:** / **Verification head SHA:** / **Verification diff stat:**`); a worker that cannot confirm its analysis ran against that exact head MUST record a `tool-failure` rather than verify an ambiguous target.`
+
+- [ ] **Step 3:** `npm run build && bash validators/validate-workflow.sh` → OK. commit `feat(worker-preamble,final-verification): 워커 dispatch 에 verification target snapshot 전달`.
+
+## Task 5: 입력 템플릿에 Requirement Coverage Source 추가
+
+**Files:** Modify `templates/reports/final-verification-input.template.md` (`## Source Implementation Report` 다음)
+
+- [ ] **Step 1:** `## Source Implementation Report` 블록 종료(40행 인용구) 다음에 신규 섹션 삽입.
+
+```markdown
+
+## Requirement Coverage Source
+
+- Approved implementation-planning report path:
+- Requirement source used for coverage (plan section / brief Acceptance Criteria):
+- Requirement IDs / acceptance IDs to verify:
+- Requirements intentionally excluded from this verification:
+
+> final-verification 은 위 source 의 각 requirement / acceptance id 마다 Validation Evidence 에 artifact 를 cite 해야 한다. source 가 비면 brief 의 `## Acceptance Criteria` 를 기본 source 로 사용한다.
+```
+
+- [ ] **Step 2:** 입력 템플릿의 analyser 질문 목록(85행 근처) 맨 앞에 target-integrity 질문 2개 추가:
+
+```markdown
+1. Does the verification target (head SHA / diff stat) match the implementation report's commit list and diff summary?
+2. For each requirement / acceptance criterion, what exact artifact (commit SHA, test output, log line, config value) proves coverage?
+```
+(기존 번호 질문들은 뒤로 밀린다.)
+
+- [ ] **Step 3:** `npm run build`. 렌더 검증: `python3 -m pytest tests/test_template_full_render_both_langs.py -q` → PASS. commit `feat(final-verification-input): Requirement Coverage Source + target-integrity 질문`.
+
+## Task 6: PR1 검증 + PR
+
+- [ ] **Step 1:** `python3 -m pytest tests/ -q` → 전부 PASS(또는 tmux skip). `bash validators/validate-workflow.sh` → OK. `node bin/okstra --version`.
+- [ ] **Step 2:** diff critique — 새 토큰 grep(`grep -rn "Verification base ref\|Requirement Coverage Source\|No source-mutation audit" prompts/ templates/`), runtime parity.
+- [ ] **Step 3:** push + `gh pr create --base main` (제목 `feat(final-verification): 검증 프로토콜 강화 — 초점/target snapshot/입력 (PR1)`).
+
+---
+
+# PR2 — report contract (schema / template / i18n / validator)
+
+> PR1 머지 후 `main` 기준 새 브랜치에서 진행. breaking schema 변경(pre-1.0, compat 불필요).
+
+## Task 7: schema — sourceImplementationReport diff-stat 분리
+
+**Files:** Modify `schemas/final-report-v1.0.schema.json` (`sourceImplementationReport`, 현 ~547행)
+
+- [ ] **Step 1 (test first):** schema 검증 테스트 추가 — diff-stat/diffSummaryQuote 누락 시 invalid. (해당 schema 검증 테스트 파일은 `tests/test_validate_run*.py` 또는 schema 단위 테스트; 실행 시 위치 확인 후 케이스 추가.)
+- [ ] **Step 2:** `sourceImplementationReport` 를 교체:
+
+```json
+"sourceImplementationReport": {
+  "type": "object",
+  "required": ["path", "commitListQuote", "diffSummaryQuote", "worktreePath", "implementationBaseRef", "capturedHeadSha", "gitStatusShort", "gitDiffStat"],
+  "additionalProperties": false,
+  "properties": {
+    "path": { "type": "string" },
+    "commitListQuote": { "type": "string" },
+    "diffSummaryQuote": { "type": "string" },
+    "worktreePath": { "type": "string" },
+    "implementationBaseRef": { "type": "string" },
+    "capturedHeadSha": { "type": "string" },
+    "gitStatusShort": { "type": "string" },
+    "gitDiffStat": { "type": "string" }
+  }
+}
+```
+(주의: 기존 `baseHeadSha` → `implementationBaseRef` + `capturedHeadSha` 분리. template/i18n/fixture 동반 수정 필요 — Task 10/11.)
+
+- [ ] **Step 3:** schema 테스트 PASS. commit.
+
+## Task 8: schema — conditionalAcceptanceConditions
+
+**Files:** Modify `schemas/final-report-v1.0.schema.json` (`finalVerdict` + `$defs`)
+
+- [ ] **Step 1 (test first):** verdict=`conditional-accept` 인데 conditions 비면 invalid 케이스.
+- [ ] **Step 2:** `finalVerdict.properties` 에 추가 + `$defs` 에 row 정의:
+
+```json
+"conditionalAcceptanceConditions": {
+  "type": "array",
+  "items": { "$ref": "#/$defs/ConditionalAcceptanceConditionRow" }
+}
+```
+```json
+"ConditionalAcceptanceConditionRow": {
+  "type": "object",
+  "required": ["id", "condition", "evidenceRequired", "blocksReleaseHandoff"],
+  "additionalProperties": false,
+  "properties": {
+    "id": { "type": "string", "pattern": "^CA-\\d{3,}$" },
+    "condition": { "type": "string", "minLength": 1 },
+    "evidenceRequired": { "type": "string", "minLength": 1 },
+    "blocksReleaseHandoff": { "type": "boolean" }
+  }
+}
+```
+(`finalVerdict.required` 에는 넣지 않음 — accepted/blocked 에선 빈 배열 허용; 강제는 validator 에서 verdict 조건부로.)
+
+- [ ] **Step 3:** 테스트 PASS. commit.
+
+## Task 9: schema — ReadonlyCommandRow status / nullable exitCode
+
+**Files:** Modify `schemas/final-report-v1.0.schema.json` (`ReadonlyCommandRow`, 현 ~1306행)
+
+- [ ] **Step 1 (test first):** status=`rejected`, exitCode=null 인 row 가 valid 케이스 + status=`executed` 인데 exitCode=null 이면 invalid(아래 Step 2 의 조건).
+- [ ] **Step 2:** `ReadonlyCommandRow` 교체:
+
+```json
+"ReadonlyCommandRow": {
+  "type": "object",
+  "required": ["number", "tier", "command", "status", "exitCode", "outputTail"],
+  "additionalProperties": false,
+  "properties": {
+    "number": { "type": "integer", "minimum": 1 },
+    "tier": { "enum": [1, 2] },
+    "command": { "type": "string", "minLength": 1 },
+    "status": { "enum": ["executed", "rejected", "not-configured"] },
+    "exitCode": { "type": ["integer", "null"] },
+    "rejectionReason": { "type": ["string", "null"] },
+    "outputTail": { "type": "string" }
+  },
+  "allOf": [
+    { "if": { "properties": { "status": { "const": "executed" } } },
+      "then": { "properties": { "exitCode": { "type": "integer" } } } },
+    { "if": { "properties": { "status": { "const": "rejected" } } },
+      "then": { "required": ["rejectionReason"] } }
+  ]
+}
+```
+
+- [ ] **Step 3:** 테스트 PASS. commit.
+
+## Task 10: template §4.8 — 새 필드 렌더
+
+**Files:** Modify `templates/reports/final-report.template.md` (§4.8.1, + 신규 conditions 섹션, Read-only Command Log)
+
+- [ ] **Step 1:** §4.8.1 Source Implementation Report 렌더에 diffSummaryQuote / implementationBaseRef / gitDiffStat 추가, baseHeadSha → capturedHeadSha 로 변경 (i18n 키는 Task 11).
+- [ ] **Step 2:** §4.8.x `Conditional Acceptance Conditions` 섹션 추가 — verdict=`conditional-accept` 일 때 행 렌더, 아니면 `- Not applicable (verdict is not conditional-accept).`.
+- [ ] **Step 3:** Read-only Command Log 렌더에 `status` 열 + rejected 행의 `rejectionReason`, exitCode null 처리.
+- [ ] **Step 4:** `npm run build`. `python3 -m pytest tests/test_template_full_render_both_langs.py tests/test_render_phase_blocks.py -q` → PASS(또는 fixture 갱신 후). commit.
+
+## Task 11: i18n 키 + golden fixture
+
+**Files:** Modify `templates/reports/i18n/en.json`, `ko.json`, `tests/fixtures/reports/golden-final-verification.md`, `tests/fixtures/final-report-data/final-verification-001.data.json`
+
+- [ ] **Step 1:** `en.json` + `ko.json` 의 `evidenceMeta` 에 키 추가: `diffSummaryAtRunStart`, `implementationBaseRef`, `gitDiffStatAtRunStart` (+ conditions/command-status 라벨). 기존 `capturedHeadBaseSha` → `capturedHeadSha` 의미로 정리.
+- [ ] **Step 2:** golden data.json 에 새 필드 채우고, golden md 를 새 렌더 결과로 갱신 (`npm run build` 후 렌더러로 재생성하거나 수동 갱신).
+- [ ] **Step 3:** `python3 -m pytest tests/test_template_full_render_both_langs.py tests/test_report_views.py -q` → PASS. commit.
+
+## Task 12: validator — verdict↔blocker/condition/routing 일관성 강제
+
+**Files:** Modify `validators/validate-run.py` (final-verification 블록 ~1172), `tests/test_validate_run*.py`
+
+- [ ] **Step 1 (test first):** 4개 회귀 테스트 추가:
+  - verdict=`accepted` + acceptanceBlockers 비어있지 않음 → fail
+  - verdict=`blocked` + acceptanceBlockers 0개 → fail
+  - verdict=`conditional-accept` + conditions 0개 → fail
+  - routingRecommendation 이 `release-handoff` 인데 verdict ≠ `accepted` → fail
+- [ ] **Step 2:** `if task_type == "final-verification":` 블록(1172)에 위 4개 검사 추가. 신규 §4.8 섹션 추가했으면 `FINAL_VERIFICATION_REQUIRED_SECTIONS`(876)에 `"Conditional Acceptance Conditions"` 등 반영.
+- [ ] **Step 3:** `python3 -m pytest tests/test_validate_run.py -q` → PASS. commit.
+
+## Task 13: PR2 검증 + docs + PR
+
+- [ ] **Step 1:** `python3 -m pytest tests/ -q`, `bash validators/validate-workflow.sh`, golden 렌더 테스트 전부 PASS.
+- [ ] **Step 2:** `CHANGES.md` 에 사용자 영향 엔트리(verdict 일관성 강제 + diff-stat/conditions/command-status 구조화).
+- [ ] **Step 3:** diff critique(rule #5) — schema↔template↔i18n↔fixture↔validator 5자 정합, 새 식별자 grep.
+- [ ] **Step 4:** push + `gh pr create --base main` (`feat(final-verification): report contract 구조화 — diff-stat/conditions/command-status + verdict 강제 (PR2)`).
+
+---
+
+## Self-Review (작성자 체크)
+
+- **Spec coverage:** 다른 에이전트 8개 항목 매핑 — #1 target snapshot=Task4, #2 diff-stat=Task7/10/11, #3 requirement source=Task5, #4 no-mutation=Task2, #5 conditions=Task3/8/10/12, #6 command status=Task9/10/12, #7 routing=Task3, #8 section-name=Task3. + 검증 초점 재설계=Task1.
+- **범위 밖 명시:** material.py 중복(cross-cutting)은 별도 — spawn 권장.
+- **Placeholder:** schema/profile/preamble/input 은 완전한 텍스트 포함. template/i18n/fixture(Task10/11)는 정확한 위치·키를 지정하되, 렌더 결과 golden md 는 빌드로 재생성하는 절차로 둠(수작업 전체 전사 비현실적).
+- **enforcement 정직성:** 검증 초점(Task1)·no-mutation(Task2)·target snapshot(Task4)은 선언 레벨(런타임 강제 없음). verdict↔blocker/condition/routing(Task12)·schema 필드(Task7-9)는 validator/schema 가 런타임 강제.
+- **의존성:** Task3 Step3(conditional 참조)는 PR2 의 conditions 와 짝 — PR1 단독이면 보류.