okstra 0.31.0 → 0.32.1

package/runtime/templates/reports/final-report.template.md

@@ -1,162 +1,160 @@
+{# OKSTRA Final Report — Jinja2 template (schemas/final-report-v1.0).
+   Consumed by scripts/okstra-render-final-report.py against the JSON
+   SSOT at runs/<task-type>/reports/final-report-<task-type>-<seq>.data.json.
+   Custom filters: format_int, format_usd, format_duration_ms,
+   yaml_scalar, yaml_inline_list (defined in render_final_report.py).
+   Token Usage cells render as `--` while tokenUsage.*.totalTokens is
+   null in Phase 6; Phase 7 mutates the data.json then re-renders. #}
 ---
-title: OKSTRA Final Report - {{TASK_KEY}}
-id: {{FM_ID}}
-tags: {{FM_TAGS}}
-status: in-progress
-aliases: {{FM_ALIASES}}
-date: {{TASK_DATE}}
-task-id: "{{TASK_ID}}"
-task-group: "{{TASK_GROUP}}"
-project-id: "{{PROJECT_ID}}"
-taskType: "{{FM_TASK_TYPE}}"
+title: {{ frontmatter.title | yaml_scalar }}
+id: {{ frontmatter.id | yaml_scalar }}
+tags: {{ frontmatter.tags | yaml_inline_list }}
+status: {{ frontmatter.status }}
+aliases: {{ frontmatter.aliases | yaml_inline_list }}
+date: {{ frontmatter.date }}
+task-id: {{ frontmatter.taskId | yaml_scalar }}
+task-group: {{ frontmatter.taskGroup | yaml_scalar }}
+project-id: {{ frontmatter.projectId | yaml_scalar }}
+taskType: {{ frontmatter.taskType | yaml_scalar }}
+workerId: {{ frontmatter.workerId | yaml_scalar }}
 ---
 
-<!--
-Template authoring notes (NOT rendered to readers — HTML comments).
-
-  - All `<!-- ... -->` blocks in this file are author-side guidance. Do NOT
-    convert them into Markdown quote blocks (`> …`) in the produced report.
-  - "Conditional block" guards: where a section heading is wrapped in a
-    `<!-- RENDER_IF: <condition> -->` … `<!-- /RENDER_IF -->` pair, the
-    report-writer MUST delete the entire heading + body when the condition is
-    false. Leaving a section heading with placeholder body ("No prior X" /
-    "Not applicable") is a contract violation that the validator will catch.
-  - Section ordering rule: Verdict Card → Approval Block (planning only) →
-    Carry-in (only if non-empty) → Summary/Ticket/Status → Token table →
-    §1–§7. The reader's first 30 lines must answer "what was decided" and
-    "what do I do next"; deep evidence lives further down.
--->
-
-# {{TASK_KEY}} - Multi-Agent Cross Verification Final Report
-
-- Created at: {{RUN_TIMESTAMP_ISO}}
-- Task Key: {{TASK_KEY}}
-- Task Type: {{TASK_TYPE}}
-- Report Owner: `Claude lead`
-- Report Author: `<Report writer worker | Claude lead (release-handoff or recorded-fallback only)>`
-- Lead Model: `{{LEAD_MODEL}}`
-- Okstra Version: `{{OKSTRA_VERSION}}`
+# {{ header.taskKey }} - Multi-Agent Cross Verification Final Report
+
+- Created at: {{ header.createdAt }}
+- Task Key: {{ header.taskKey }}
+- Task Type: {{ header.taskType }}
+- Report Owner: `{{ header.reportOwner }}`
+- Report Author: `{{ header.reportAuthor }}`
+- Lead Model: `{{ header.leadModel }}`
+- Okstra Version: `{{ header.okstraVersion }}`
 
 ## Verdict Card
 
-한눈에 보는 결과 카드. 본 표의 모든 값은 `## 2. Final Verdict` 및 `## 6. Recommended Next Steps` 의 권위 있는 값과 정확히 일치해야 합니다. 두 곳의 값이 다르면 본 카드를 깨진 인덱스로 간주합니다.
+한눈에 보는 결과 카드. 본 표의 모든 값은 `## 2. Final Verdict` 및 `## 6. Recommended Next Steps` 의 권위 있는 값과 정확히 일치해야 합니다.
 
 | 항목 | 값 |
 |------|----|
-| Final Conclusion | <한 줄 결론 — `## 2.` 의 Final Conclusion 셀과 동일> |
-| Verdict Token | `<accepted / conditional-accept / blocked / not-applicable>` |
-| Direction | `<continue-investigation / begin-implementation / approve / reject / hold>` |
-| Approval Required? | `<yes — User Approval Request 블록 참조 / no>` |
-| Next Step | <한 줄 — `## 6.` 첫 항목과 동일> |
-
-<!-- RENDER_IF: task-type == implementation-planning -->
+| Final Conclusion | {{ verdictCard.finalConclusion }} |
+| Verdict Token | `{{ verdictCard.verdictToken }}` |
+| Direction | `{{ verdictCard.direction }}` |
+| Approval Required? | `{% if verdictCard.approvalRequired %}yes — User Approval Request 블록 참조{% else %}no{% endif %}` |
+| Next Step | {{ verdictCard.nextStep }} |
 
+{% if header.taskType == 'implementation-planning' %}
 ## User Approval Request (사용자 승인 게이트)
 
 다음 `implementation` run 은 아래 체크박스가 `[x]` 일 때에만 진입할 수 있습니다 (`okstra_ctl.run._validate_approved_plan` 가 line-anchored 정규식으로 검사). `## 5. Clarification Items` 표에서 `Blocks=approval` 인 모든 행이 `resolved` / `obsolete` 가 된 뒤 승인해 주세요.
 
-- 승인 체크박스 (사용자가 직접 편집): `- [ ] Approved`
+- 승인 체크박스 (사용자가 직접 편집): `- [{% if approvalBlock.approved %}x{% else %} {% endif %}] Approved`
 - 승인 후 다음 단계 명령 (수동 편집 방식):
-  - Claude Code: `/okstra-run task-key={{TASK_KEY}} task-type=implementation approved-plan=<이 보고서 경로>`
-  - 별도 터미널: `scripts/okstra.sh --task-key {{TASK_KEY}} --task-type implementation --approved-plan <이 보고서 경로>`
+  - Claude Code: `/okstra-run task-key={{ header.taskKey }} task-type=implementation approved-plan=<이 보고서 경로>`
+  - 별도 터미널: `scripts/okstra.sh --task-key {{ header.taskKey }} --task-type implementation --approved-plan <이 보고서 경로>`
 - 승인 + 실행 한 번에 (진입 명령 자체를 승인 의사로):
-  - Claude Code: `/okstra-run task-key={{TASK_KEY}} task-type=implementation approved-plan=<이 보고서 경로> approve`
-  - 별도 터미널: `scripts/okstra.sh --task-key {{TASK_KEY}} --task-type implementation --approved-plan <이 보고서 경로> --approve`
+  - Claude Code: `/okstra-run task-key={{ header.taskKey }} task-type=implementation approved-plan=<이 보고서 경로> approve`
+  - 별도 터미널: `scripts/okstra.sh --task-key {{ header.taskKey }} --task-type implementation --approved-plan <이 보고서 경로> --approve`
 - 보류·거부: 체크박스를 `[ ]` 로 두고 `--approve` 를 사용하지 마세요. 필요 변경은 `## 5.` 표에 `Blocks=approval` 행으로 등록한 뒤 같은 phase 를 재실행합니다.
 
-<!-- /RENDER_IF -->
-
-<!-- RENDER_IF: CLARIFICATION_RESPONSE_RELATIVE_PATH is non-empty
-     When empty, DELETE this entire `## 0.` heading and body. The validator
-     fails an empty Section 0 stub ("No prior clarification was provided"). -->
-
+{% endif %}
+{% if clarificationCarryIn and clarificationCarryIn.sourceFile %}
 ## 0. Clarification Response Carried In From Previous Run
 
-- Source file: `{{CLARIFICATION_RESPONSE_RELATIVE_PATH}}`
+- Source file: `{{ clarificationCarryIn.sourceFile }}`
 - 이전 보고서의 `## 5. Clarification Items` 표 매 행(`C-001`, `C-002`, …) 을 새 증거에 비추어 검토하고, 각 행의 `Status` 를 `resolved` 또는 `obsolete` 로 갱신한 뒤 본 run 의 `## 5.` 표에 carry-in 합니다. 해소 근거(파일:라인 / 로그 / 워커 결과) 를 함께 인용합니다.
 
-<!-- /RENDER_IF -->
-
+{% endif %}
 ## Summary of the Problem or Verification Target
 
 3~5 개 row 로 핵심 문제·요구사항·검증 대상을 표로 정리합니다. brief, 소스 자료, worker 결과를 근거로 작성합니다.
 
 | ID | Ticket ID | 한 줄 요약 | 출처 (brief/source/worker) |
 |----|-----------|------------|----------------------------|
-| P-001 | `<TICKET-or-fallback>` | <핵심 항목 한 줄> | <출처> |
+{% for row in summary -%}
+| {{ row.id }} | `{{ row.ticketId }}` | {{ row.summary }} | {{ row.source }} |
+{% endfor %}
 
+{% if ticketCoverage.omit %}
+{# Ticket Coverage omitted entirely — release-handoff / final-verification #}
+{%- else %}
 ## Ticket Coverage
 
 본 run 이 다룬 ticket 의 역방향 인덱스. 본문 항목들은 모두 `Ticket ID` 컬럼 또는 `[TICKETID: <id>]` 태그로 ticket 과 묶여 있습니다.
 
-- 단일 ticket run 인 경우: 표 대신 다음 한 줄 — `- Single ticket run: <TICKET-or-task-fallback>`
-- 다중 ticket 이거나 `Issue / Ticket` 이 비어 `Task ID` 폴백이 섞여 있는 경우: 표를 채웁니다.
-
+{% if ticketCoverage.singleTicket -%}
+- Single ticket run: {{ ticketCoverage.singleTicket }}
+{%- else %}
 | Ticket ID | 등장 섹션 | 관련 항목 IDs |
 |-----------|-----------|---------------|
-| `<TICKET-123>` | `1.1, 3.1, 4.5.4` | `F-001, F-003, A1` |
+{% for row in ticketCoverage.rows -%}
+| `{{ row.ticketId }}` | `{{ row.sections }}` | `{{ row.relatedIds }}` |
+{% endfor %}
+{%- endif %}
 
-규칙: `Ticket ID` 는 본문에서 등장한 ticket 키와 정확히 동일 문자열. `Issue / Ticket` 이 비어 폴백된 경우 `Task ID` 값을 prefix 없이 그대로 (예: `8852`). 식별 불가는 `unknown`. `관련 항목 IDs` 는 `F-001`, `M-002`, `A1`, `Q1` 같은 row ID 를 콤마로 나열하고, row ID 가 없는 경우 섹션 번호 (예: `4.5.3`) 를 적습니다.
+규칙: `Ticket ID` 는 본문에서 등장한 ticket 키와 정확히 동일 문자열. `Issue / Ticket` 이 비어 폴백된 경우 `Task ID` 값을 prefix 없이 그대로 (예: `8852`). 식별 불가는 `unknown`.
 
+{% endif %}
 ## Execution Status by Agent
 
 각 worker 의 status, 배정 모델, key finding 을 한 표에 모읍니다. worker 산출물을 근거 없는 주장으로 대체하지 않습니다.
 
-{{EXECUTION_STATUS_TABLE_ROWS}}
+| Agent | Role | Model | Status | 처리 토큰 | 환산 토큰 | 비용 (USD) | Duration | Summary of Key Findings |
+|-------|------|-------|--------|-----------|-----------|------------|----------|-------------------------|
+{% for row in executionStatus -%}
+| {{ row.agent }} | {{ row.role }} | {{ row.model }} | {{ row.status }} | {{ row.totalTokens | format_int }}{% if row.cliTotalTokens %} (CLI: {{ row.cliTotalTokens | format_int }}){% endif %} | {{ row.billableTokens | format_int }} | {{ row.costUsd | format_usd }}{% if row.cliCostUsd %} (+ CLI {{ row.cliCostUsd | format_usd }}){% endif %} | {{ row.durationMs | format_duration_ms }} | {{ row.summary }} |
+{% endfor %}
 
 ## Token Usage Summary
 
 | 항목 | 처리 토큰 | 환산 토큰 (input 기준) | 비용 (USD) |
 |------|-----------|------------------------|------------|
-| Lead | `{{LEAD_TOTAL_TOKENS}}` | `{{LEAD_BILLABLE_TOKENS}}` | `{{LEAD_COST_USD}}` |
-| Worker 합계 | `{{WORKER_TOTAL_TOKENS}}` | `{{WORKER_BILLABLE_TOKENS}}` | `{{WORKER_COST_USD}}` |
-| **전체 합계** | **`{{GRAND_TOTAL_TOKENS}}`** | **`{{GRAND_BILLABLE_TOKENS}}`** | **`{{GRAND_COST_USD}}`** |
-| Codex/Gemini CLI 추가 비용 |  |  | `{{CLI_COST_USD}}` |
-
-<!--
-환산식 설명·"읽는 법"·캐시 가중치 등은 `docs/kr/architecture.md#token-accounting`
-및 audit 사이드카에서 참조하세요. 본문 가독성 회복을 위해 인용구는 제거했습니다.
-
-placeholders 정책:
-  - Phase 6 시점에는 10 개 `{{...}}` 토큰을 verbatim 으로 둡니다.
-  - Phase 7 의 `okstra-token-usage.py --substitute-final-report` 가 치환합니다.
-  - 임의 값 (`0` / `N/A` / `--` / `not-collected` / `pending`) 으로 대체 금지.
-    Validator 가 치환 실패와 임의 값 모두 fail 합니다.
--->
+| Lead | `{{ tokenUsage.lead.totalTokens | format_int }}` | `{{ tokenUsage.lead.billableTokens | format_int }}` | `{{ tokenUsage.lead.costUsd | format_usd }}` |
+| Worker 합계 | `{{ tokenUsage.worker.totalTokens | format_int }}` | `{{ tokenUsage.worker.billableTokens | format_int }}` | `{{ tokenUsage.worker.costUsd | format_usd }}` |
+| **전체 합계** | **`{{ tokenUsage.grand.totalTokens | format_int }}`** | **`{{ tokenUsage.grand.billableTokens | format_int }}`** | **`{{ tokenUsage.grand.costUsd | format_usd }}`** |
+| Codex/Gemini CLI 추가 비용 |  |  | `{{ tokenUsage.cli.costUsd | format_usd }}` |
 
-## 1. Cross Verification Results
+{# Phase 6 시점에는 numeric cells 가 null → 모두 `--` 로 렌더링.
+   Phase 7 의 okstra-token-usage.py 가 data.json 의 tokenUsage 를 채우고
+   이 renderer 를 재호출하여 최종 markdown 을 다시 생성합니다. #}
 
-### 1.0 Round History (convergence-enabled runs only)
+## 1. Cross Verification Results
 
-`state/convergence-<task-type>-<seq>.json` 의 값을 그대로 옮깁니다. convergence 가 비활성화된 run 에서는 이 sub-section 전체를 삭제합니다.
+{% if crossVerification.roundHistory and not crossVerification.roundHistory.disabled -%}
+### 1.0 Round History
 
 | Round | inputQueueSize | resolvedCount | carriedForwardCount | dispatches (worker:status:durationMs) | skippedWorkers (worker:reason) |
 |-------|----------------|---------------|----------------------|----------------------------------------|---------------------------------|
-| 1     | 3              | 2             | 1                    | codex-worker:completed:184221, gemini-worker:completed:201337 | claude-worker:no-items |
-| 2     | 1              | 1             | 0                    | claude-worker:completed:92110         | --                              |
+{% for row in crossVerification.roundHistory.rounds -%}
+| {{ row.round }} | {{ row.inputQueueSize }} | {{ row.resolvedCount }} | {{ row.carriedForwardCount }} | {{ row.dispatches }} | {{ row.skippedWorkers }} |
+{% endfor %}
 
-- `round2SkippedReason`: `not-skipped`  ← 값은 `queue-empty | max-rounds-1 | all-reverify-non-result | not-skipped` 중 하나.
-- 실행된 round 수가 0 (Round 0 에서 모든 finding 이 곧장 full-consensus) 이면 표 대신 한 줄 — `- Round 0 grouping 에서 모든 finding 이 합의되어 재검증 라운드가 실행되지 않았습니다.`
+- `round2SkippedReason`: `{{ crossVerification.roundHistory.round2SkippedReason }}`  ← 값은 `queue-empty | max-rounds-1 | all-reverify-non-result | not-skipped | convergence-disabled | single-analyser-only` 중 하나.
 
+{% endif %}
 ### 1.1 Consensus
 
+{% if crossVerification.consensus | length == 0 -%}
+- 합의 항목 없음.
+{%- else %}
 | ID | Ticket ID | Statement | Source items (worker:item) | Evidence (path:line / log / worker report) |
 |----|-----------|-----------|----------------------------|---------------------------------------------|
-| C-001 | `<TICKET-or-fallback>` | <합의된 결론> | claude:F-001, codex:1.1, gemini:F-3 | <증거 위치> |
-
-표 우선 (bullet 으로 degrade 금지). 합의된 결론을 row 마다 기록합니다.
+{% for row in crossVerification.consensus -%}
+| {{ row.id }} | `{{ row.ticketId }}` | {{ row.statement }} | {{ row.sourceItems | join(', ') }} | {{ row.evidence }} |
+{% endfor %}
+{%- endif %}
 
-`Source items` 규칙: 본 합의 row 가 어느 워커의 어느 항목들에서 합성됐는지를 `<worker>:<item-id>` 페어 콤마-리스트로 적습니다. 워커 항목 ID 는 워커 자체가 부여한 leading-column ID 입니다 (claude 는 `F-NNN`, codex 는 `1.1` 같은 hierarchical, gemini 는 자유). 바로 이 컬럼이 합성된 `C-NNN` 을 원본 worker-results 파일로 역추적하는 단 하나의 다리입니다 — 단순 워커 이름만 (`claude, codex, gemini`) 적으면 추적성이 끊깁니다. 자세한 정책은 `prompts/profiles/_common-contract.md` "Cross-worker traceability" SSOT.
+`Source items` 규칙: 본 합의 row 가 어느 워커의 어느 항목들에서 합성됐는지를 `<worker>:<item-id>` 페어 콤마-리스트로 적습니다. 자세한 정책은 `prompts/profiles/_common-contract.md` "Cross-worker traceability" SSOT.
 
 ### 1.2 Differences
 
+{% if crossVerification.differences | length == 0 -%}
+- 유의미한 차이 없음. 1.1 Consensus 가 그대로 유효합니다.
+{%- else %}
 | ID | Ticket ID | Disagreement | Workers (position + item) | Evidence |
 |----|-----------|--------------|---------------------------|----------|
-| D-001 | `<TICKET-or-fallback>` | <차이 요약> | claude:F-005 (A) / codex:1.3 (B) / gemini:-- | <증거 위치> |
-
-유의미한 차이 없음: 표 대신 — `- 유의미한 차이 없음. 1.1 Consensus 가 그대로 유효합니다.`
-
-`Workers (position + item)` 규칙: 1.1 의 `Source items` 와 동일한 `<worker>:<item-id>` 형식이되 워커마다 `(<position>)` 라벨 (`A` / `B` / `-` 등) 을 함께 적어 어느 워커가 어느 입장을 취했는지 표시합니다. 해당 plan item 에 의견을 내지 않은 워커는 `<worker>:--` 로 기록합니다.
+{% for row in crossVerification.differences -%}
+| {{ row.id }} | `{{ row.ticketId }}` | {{ row.disagreement }} | {% for w in row.workersPosition %}{{ w.worker }}:{{ w.itemId }} ({{ w.position }}){% if not loop.last %} / {% endif %}{% endfor %} | {{ row.evidence }} |
+{% endfor %}
+{%- endif %}
 
 ## 2. Final Verdict
 
@@ -164,469 +162,430 @@ placeholders 정책:
 
 | 항목 | 값 |
 |------|----|
-| Final Conclusion | <한 줄 결론> |
-| Verdict Token | `<accepted / conditional-accept / blocked / not-applicable>` |
-| Direction | `<continue-investigation / begin-implementation / approve / reject / hold>` |
-| 근거 요약 | <`1.1`, `3.1` 등 본 보고서 행 ID 를 콤마로> |
-| 다음 단계 | <Section 6 또는 7 중 어디로 이어지는지> |
+| Final Conclusion | {{ finalVerdict.finalConclusion }} |
+| Verdict Token | `{{ finalVerdict.verdictToken }}` |
+| Direction | `{{ finalVerdict.direction }}` |
+| 근거 요약 | {{ finalVerdict.rationaleRowIds | join(', ') }} |
+| 다음 단계 | {{ finalVerdict.nextStep }} |
 
 ## 3. Evidence and Detailed Analysis
 
 ### 3.1 Primary Evidence
 
+{% if evidence.primary | length == 0 -%}
+- 주 증거 없음.
+{%- else %}
 | ID | Ticket ID | Evidence | Source items (worker:item) | Source (path:line / log) |
 |----|-----------|----------|----------------------------|---------------------------|
-| E-001 | `<TICKET-or-fallback>` | <증거 한 줄 요약> | claude:F-002, codex:1.4 | `<path>:<line>` 또는 로그 인용 |
+{% for row in evidence.primary -%}
+| {{ row.id }} | `{{ row.ticketId }}` | {{ row.evidence }} | {{ row.sourceItems | join(', ') }} | {{ row.source }} |
+{% endfor %}
+{%- endif %}
 
-`Source items` 컬럼 규칙은 §1.1 과 동일 — `<worker>:<item-id>` 페어 콤마-리스트로 어느 워커 항목들에서 본 증거가 도출됐는지 기록합니다. 워커 결과 인용 없이 lead 가 독립적으로 (예: MCP 직접 조회로) 얻은 증거는 `lead:mcp-<순번>` 형식으로 적습니다 (예: `lead:mcp-1`). `Source (path:line / log)` 컬럼은 코드/로그 위치 자체를 기록합니다.
+`Source items` 컬럼 규칙은 §1.1 과 동일.
 
 ### 3.2 Secondary Evidence or Alternate Interpretations
 
+{% if not evidence.secondary or evidence.secondary | length == 0 -%}
+- 보조 증거 또는 대안 해석 없음.
+{%- else %}
 | ID | Ticket ID | Hypothesis or supporting evidence | Source / confidence |
 |----|-----------|-----------------------------------|---------------------|
-| S-001 | `<TICKET-or-fallback>` | <보조 증거 또는 대안 해석> | <출처 + low/mid> |
-
-해당 없음 시: `- 보조 증거 또는 대안 해석 없음.`
+{% for row in evidence.secondary -%}
+| {{ row.id }} | `{{ row.ticketId }}` | {{ row.hypothesis }} | {{ row.confidence }} |
+{% endfor %}
+{%- endif %}
 
 ## 4. Missing Information and Risks
 
+{% if missingInformation | length == 0 -%}
+- 누락된 정보·위험 없음.
+{%- else %}
 | ID | Ticket ID | Item | Risk if ignored | Mitigation Owner |
 |----|-----------|------|-----------------|------------------|
-| R-001 | `<TICKET-or-fallback>` | <누락 정보 또는 불확실 항목> | <무시할 때의 위험> | <역할 / 팀> |
-
-`I don't know` / `uncertain` 항목은 모두 표 안에 두고 본문 산문으로 흩지 않습니다.
-
-<!-- RENDER_IF: task-type == implementation-planning
-     Delete the entire `## 4.5` block + sub-sections otherwise.
-
-     Validator (validators/validate-run.py PLANNING_REQUIRED_SECTIONS) does
-     substring matching for these 9 English keywords in order:
-       Option Candidates, Trade-off, Recommended Option,
-       Stepwise Execution Order, Dependency, Validation Checklist, Rollback,
-       User Approval Request, Plan Body Verification
-     The first 7 + 9th live below; "User Approval Request" is satisfied by
-     the top-of-report Approval block heading. Do NOT recreate a §4.5.8 stub
-     in body — validator now fails reports that contain one. -->
+{% for row in missingInformation -%}
+| {{ row.id }} | `{{ row.ticketId }}` | {{ row.item }} | {{ row.risk }} | {{ row.owner }} |
+{% endfor %}
+{%- endif %}
 
+{% if header.taskType == 'implementation-planning' %}
 ## 4.5 Implementation Plan Deliverables
 
 ### 4.5.1 Option Candidates (옵션 후보)
 
-최소 두 개의 구현 옵션. 각 옵션마다:
+{% for opt in implementationPlanning.optionCandidates %}
+**{{ opt.name }}**
 
-- **File Structure** — 파일 단위 책임을 한 줄씩 (`Ticket ID` 채움):
+- File Structure:
 
   | ID | Ticket ID | Action | Path (and line-range) | Change summary |
   |----|-----------|--------|------------------------|----------------|
-  | OF-001 | `<TICKET-or-fallback>` | Create / Modify / Delete | `<path>[:<line-range>]` | <한 줄 요약> |
+{% for fs in opt.fileStructure -%}
+  | {{ fs.id }} | `{{ fs.ticketId }}` | {{ fs.action }} | `{{ fs.path }}` | {{ fs.summary }} |
+{% endfor %}
+
+- 영향 인터페이스 / 공개 계약 / 다운스트림 소비자: {{ opt.interfaces }}
+- 폭발 반경 추정: {{ opt.blastRadius }}
 
-- 영향을 받는 인터페이스 / 공개 계약 / 다운스트림 소비자.
-- 폭발 반경 추정 (units, configs, deployment manifests, data migrations).
+{% endfor %}
 
 ### 4.5.2 Trade-off Matrix (트레이드오프 매트릭스)
 
 | Option | Complexity | Risk | Reversibility | Test Coverage Cost | Rollout Cost |
 |--------|-----------|------|---------------|--------------------|--------------|
-| <Option A> | <…> | <…> | <…> | <…> | <…> |
+{% for row in implementationPlanning.tradeoffMatrix -%}
+| {{ row.option }} | {{ row.complexity }} | {{ row.risk }} | {{ row.reversibility }} | {{ row.testCoverageCost }} | {{ row.rolloutCost }} |
+{% endfor %}
 
 ### 4.5.3 Recommended Option (권장 옵션)
 
 | 항목 | 값 |
 |------|----|
-| Recommended Option | <옵션 이름> |
-| 핵심 이유 | <한 줄> |
-| 근거 (Trade-off 행 / 원칙) | <4.5.2 행 + 적용 디자인 원칙: isolation / files-that-change-together / follow-established-patterns / YAGNI> |
-| 채택되지 않은 옵션 요약 | <짧게: 어떤 비용 때문에 탈락> |
+| Recommended Option | {{ implementationPlanning.recommendedOption.name }} |
+| 핵심 이유 | {{ implementationPlanning.recommendedOption.coreReason }} |
+| 근거 (Trade-off 행 / 원칙) | {{ implementationPlanning.recommendedOption.rationale }} |
+| 채택되지 않은 옵션 요약 | {{ implementationPlanning.recommendedOption.rejectedSummary }} |
 
 ### 4.5.4 Stepwise Execution Order (단계별 실행 순서)
 
 | Step | Ticket ID | Action (≤ 5min) | Files | Command / Test | Expected outcome |
 |------|-----------|------------------|-------|----------------|-------------------|
-| 1 | `<TICKET-or-fallback>` | <예: 실패하는 테스트 작성> | `tests/foo_test.py` | `pytest tests/foo_test.py::test_x -v` | FAIL with <reason> |
+{% for row in implementationPlanning.stepwiseExecution -%}
+| {{ row.step }} | `{{ row.ticketId }}` | {{ row.action }} | `{{ row.files }}` | `{{ row.commandOrTest }}` | {{ row.expectedOutcome }} |
+{% endfor %}
 
-규칙: 한 step 은 약 2~5 분. 모든 step 은 정확한 파일 경로와 명령어 포함. TDD 가능 영역은 failing test → implementation → green → commit 순서.
+규칙: 한 step 은 약 2~5 분. 모든 step 은 정확한 파일 경로와 명령어 포함.
 
 ### 4.5.5 Dependency / Migration Risk (의존성·마이그레이션 위험)
 
-순서 제약, 데이터 백필, feature-flag 선행 조건, repo-internal sequencing. 외부 승인·권한·vendor 조율은 위험/일정 항목으로 등록하지 않습니다. 해당 없음: `- 의존성·마이그레이션 위험 없음.`
-
-| ID | Kind (order / backfill / flag-precondition / repo-sequencing / other) | Item | 영향 | 완화 / 선행 작업 |
-|----|------------------------------------------------------------------------|------|------|------------------|
-| DM-001 | <kind> | <한 줄 요약> | <영향 범위> | <대응 방안> |
+{% if implementationPlanning.dependencyMigrationRisk | length == 0 -%}
+- 의존성·마이그레이션 위험 없음.
+{%- else %}
+| ID | Kind | Item | 영향 | 완화 / 선행 작업 |
+|----|------|------|------|------------------|
+{% for row in implementationPlanning.dependencyMigrationRisk -%}
+| {{ row.id }} | {{ row.kind }} | {{ row.item }} | {{ row.impact }} | {{ row.mitigation }} |
+{% endfor %}
+{%- endif %}
 
 ### 4.5.6 Validation Checklist (검증 체크리스트)
 
 | Phase | Ticket ID | Check | Command / Observation | Expected outcome |
 |-------|-----------|-------|------------------------|-------------------|
-| pre   | `<TICKET-or-fallback>` | <체크 이름> | `<정확한 명령어 또는 관찰 지점>` | <기대 출력 / 상태> |
-| mid   | `<TICKET-or-fallback>` | <체크 이름> | `<...>` | <...> |
-| post  | `<TICKET-or-fallback>` | <체크 이름> | `<...>` | <...> |
-
-추상적 서술 금지. 모든 row 는 명령어 또는 관찰 가능한 결과를 포함.
+{% for row in implementationPlanning.validationChecklist -%}
+| {{ row.phase }} | `{{ row.ticketId }}` | {{ row.check }} | `{{ row.commandOrObservation }}` | {{ row.expectedOutcome }} |
+{% endfor %}
 
 ### 4.5.7 Rollback Strategy (롤백 전략)
 
-| ID | Step | Action (revert command / flag toggle / migration down) | Trigger signal (error rate / latency / user report 등) | 확인 방법 |
-|----|------|---------------------------------------------------------|--------------------------------------------------------|-----------|
-| RB-001 | 1 | `<예: git revert <SHA>>` | <예: 에러율 > 1% 5분 지속> | `<관찰 명령 / 대시보드>` |
+| ID | Step | Action | Trigger signal | 확인 방법 |
+|----|------|--------|----------------|-----------|
+{% for row in implementationPlanning.rollbackStrategy -%}
+| {{ row.id }} | {{ row.step }} | `{{ row.action }}` | {{ row.triggerSignal }} | `{{ row.verificationMethod }}` |
+{% endfor %}
 
 ### 4.5.9 Plan Body Verification (계획 본문 검증)
 
-Phase 6 에서 report-writer 가 합성한 4.5 본문을 lead 가 plan-item 단위로 워커들에게 다시 던지고 `AGREE / DISAGREE / SUPPLEMENT` 평결을 수집한 결과. 라운드 프로토콜은 `skills/okstra-convergence/SKILL.md` "Plan-body verification mode" 참조.
+Phase 6 에서 report-writer 가 합성한 4.5 본문을 lead 가 plan-item 단위로 워커들에게 다시 던지고 평결을 수집한 결과.
 
-- **Round count**: `<N>` (default: 1)
-- **Gate result**: `<passed | passed-with-dissent | blocked-by-disagreement | aborted-non-result>`
-  - `passed` → 상단 `User Approval Request` 체크박스 라인 렌더.
-  - `passed-with-dissent` → 체크박스 렌더 + 반대 의견은 아래 `Dissent log` 에 기록.
-  - `blocked-by-disagreement` → 체크박스 라인 **렌더하지 않음**. majority DISAGREE 인 plan item 마다 `## 5.` 에 `Blocks=approval` row 추가.
-  - `aborted-non-result` → 워커 dispatch 가 모두 non-result. 체크박스 라인 렌더하지 않음 + `## 5.` 에 "plan-body verification could not run" row.
+- **Round count**: `{{ implementationPlanning.planBodyVerification.roundCount }}`
+- **Gate result**: `{{ implementationPlanning.planBodyVerification.gateResult }}`
 
 #### Verdict summary
 
-각 plan item 1 행. `Plan item` 열은 `P-Opt-<N>` / `P-Step-<N>` / `P-Dep-<N>` / `P-Val-<N>` / `P-Rb-<N>` prefix. `Section` 열은 4.5 내부 sub-section 번호. 워커별 평결은 아래 `Verdict details` 표로 분리합니다 (워커 수에 비례해 가로 폭이 폭발하던 단일 wide 표를 두 개로 쪼개 시인성을 회복).
-
 | Plan item | Ticket ID | Section | Classification |
 |-----------|-----------|---------|----------------|
-| P-Opt-1   | `<id>`    | 4.5.1   | full-consensus |
-| P-Step-3  | `<id>`    | 4.5.4   | majority-disagree → C-7 |
-
-- `Classification` ∈ `{full-consensus, partial-consensus, worker-unique, majority-disagree → C-<N>}`.
-- `majority-disagree → C-<N>` 의 `C-<N>` 은 `## 5. Clarification Items` 의 row ID 와 1:1 일치해야 합니다.
+{% for row in implementationPlanning.planBodyVerification.verdictSummary -%}
+| {{ row.planItem }} | `{{ row.ticketId }}` | {{ row.section }} | {{ row.classification }} |
+{% endfor %}
 
 #### Verdict details
 
-워커별 평결을 plan item × worker 쌍으로 1 행씩 기록합니다. 워커 수가 늘어나도 가로 폭이 늘지 않고 행 수만 늘어납니다. `Verdict` ∈ `{AGREE, DISAGREE, SUPPLEMENT, verification-error}`. `Breakage kind` 는 `DISAGREE` 일 때만 채우며 spec 의 `(a|b|c|d|e)` 중 하나 (a=참조 file path / symbol 불일치, b=… 자세한 정의는 `skills/okstra-convergence/SKILL.md`).
-
-| Plan item | Worker | Verdict | Breakage kind | Note (선택) |
-|-----------|--------|---------|---------------|-------------|
-| P-Opt-1   | claude-worker | AGREE | -- |  |
-| P-Opt-1   | codex-worker  | AGREE | -- |  |
-| P-Step-3  | claude-worker | DISAGREE | a | 참조한 `crates/.../mod.rs:120` 가 없음 |
-| P-Step-3  | codex-worker  | DISAGREE | a | 동일 — 파일 path 미존재 |
-| P-Step-3  | gemini-worker | SUPPLEMENT | -- | 대체 step 제안 (Dissent log 참조) |
+| Plan item | Worker | Verdict | Breakage kind | Note |
+|-----------|--------|---------|---------------|------|
+{% for row in implementationPlanning.planBodyVerification.verdictDetails -%}
+| {{ row.planItem }} | {{ row.worker }} | {{ row.verdict }} | {{ row.breakageKind or '--' }} | {{ row.note or '' }} |
+{% endfor %}
 
 #### Dissent log
 
-`partial-consensus` 와 `worker-unique` 의 반대 의견을 plan item 별로 묶어 적습니다. `majority-disagree` 항목의 반대 의견은 본 섹션 대신 `## 5.` 의 해당 row `Statement` 컬럼에 옮겨 적습니다.
-
-- **P-XXX-N**: `<worker-role>` — `<반대 의견 본문 2-3 sentences>`
-
-<!-- /RENDER_IF (task-type == implementation-planning) -->
-
-<!-- RENDER_IF: task-type == release-handoff
-     Delete the entire `## 4.6` block + sub-sections otherwise. -->
+{% if implementationPlanning.planBodyVerification.dissentLog | length == 0 -%}
+- 반대 의견 없음.
+{%- else %}
+{% for row in implementationPlanning.planBodyVerification.dissentLog -%}
+- **{{ row.planItem }}**: `{{ row.workerRole }}` — {{ row.body }}
+{% endfor %}
+{%- endif %}
 
+{% endif %}
+{% if header.taskType == 'release-handoff' %}
 ## 4.6 Release Handoff Deliverables
 
-git/gh mutating 명령이 실행된 phase 의 감사 기록. 모든 mutating command 는 반드시 아래 `User Selections` 표의 사용자 응답과 1:1 대응되어야 하며, 대응되지 않는 mutating command 가 있으면 self-review 가 `contract-violated` 로 종료해야 합니다.
+git/gh mutating 명령이 실행된 phase 의 감사 기록.
 
-### 4.6.1 Source Verification Report (선행 final-verification 인용)
+### 4.6.1 Source Verification Report
 
-- Path (project-relative): `<runs/final-verification/.../reports/final-report-final-verification-<seq>.md>`
-- Quoted `Verdict Token` row from that report's `## 2.` table (값이 정확히 `accepted` 여야 함):
-  > <원문 인용>
-- 원본 `Verdict Token` 값이 `accepted` 가 아니면 본 run 은 실행되지 않아야 했습니다. self-review 에서 contract-violated 처리하고 routing 을 `final-verification` 으로 되돌립니다.
+- Path (project-relative): `{{ releaseHandoff.sourceVerificationReport.path }}`
+- Quoted `Verdict Token` row from that report's `## 2.` table:
+  > {{ releaseHandoff.sourceVerificationReport.verdictTokenQuote }}
 
 ### 4.6.2 Feature Branch & Working-Tree State (run 시작 시점)
 
-- Feature branch (`git rev-parse --abbrev-ref HEAD`): `<branch-name>`
+- Feature branch: `{{ releaseHandoff.featureBranchState.branchName }}`
 - `git status --short` 출력:
   ```
-  <원문 그대로>
+  {{ releaseHandoff.featureBranchState.gitStatusShort }}
   ```
-- 기존 PR 존재 여부 (`gh pr list --head <branch> --state open --json url --jq '.[0].url'`): `<URL or empty>`
+- 기존 PR 존재 여부: `{{ releaseHandoff.featureBranchState.existingPrUrl or '(none)' }}`
 
 ### 4.6.3 User Selections (메뉴 응답 기록)
 
 | 질문 ID | 질문 본문 | 사용자 응답 (원문) | 응답이 가능한 보기 |
 |---------|-----------|--------------------|--------------------|
-| H1 | 어떤 작업을 실행할까요? | <`local only` / `push + PR` / `skip`> | `local only` / `push + PR` / `skip` |
-| H2 | PR base 브랜치를 골라주세요. (H1=`push + PR` 인 경우에만 묻습니다) | <`staging` / `preprod` / `prod` / `main` / `dev` / 사용자가 입력한 브랜치명> | 위 + 직접 입력 |
-| H3 | lead 가 작성한 PR title / PR body 초안을 어떻게 처리할까요? | <`use as-is` / `edit then proceed` / `cancel`> | `use as-is` / `edit then proceed` / `cancel` |
-
-H1 = `skip` 이거나 H3 = `cancel` 인 경우 4.6.4 ~ 4.6.6 은 빈 결과로 채우고 (mutating 명령 미실행) 4.6.7 routing 만 채웁니다.
+| H1 | 어떤 작업을 실행할까요? | `{{ releaseHandoff.userSelections.h1 }}` | `local only` / `push + PR` / `skip` |
+| H2 | PR base 브랜치 (H1=`push + PR` 인 경우) | `{{ releaseHandoff.userSelections.h2 or '(n/a)' }}` | staging / preprod / prod / main / dev / 사용자 입력 |
+| H3 | PR title/body 초안 처리 | `{{ releaseHandoff.userSelections.h3 }}` | `use as-is` / `edit then proceed` / `cancel` |
 
-### 4.6.4 Executed Commands (실행한 git / gh 명령 로그)
-
-- Mutating commands: 정확한 명령행 / exit code / 한 줄 stdout 요약을 한 행씩 모두 기록 (누락은 contract-violated).
-- Read-only inspection commands: 요약 또는 명령행 목록만으로 충분.
+### 4.6.4 Executed Commands
 
+{% if releaseHandoff.executedCommands | length == 0 -%}
+- (mutating 명령 미실행 — H1=`skip` 또는 H3=`cancel`)
+{%- else %}
 | # | command (verbatim) | exit code | stdout/stderr 요약 |
 |---|---------------------|-----------|--------------------|
-| 1 | `<예: git add path/to/file.py>` | `0` | `<요약>` |
-
-### 4.6.5 Commit List (생성된 commit)
-
-`implementation` phase 에서 이미 생성된 commit 범위 (`git log <base>..HEAD`) 를 기록. release-handoff 는 새 commit 을 만들지 않습니다. 각 commit 의 short SHA / full SHA / subject / 영향 파일 목록.
-
-commit 범위가 비어 있으면 release-handoff 는 실행되면 안 됩니다 → `- No implementation commits found; release-handoff is blocked.` + routing 을 `implementation` 으로 되돌림.
-
-### 4.6.6 Merge Conflict Probe (사전 머지 충돌 점검)
-
-`push + PR` 경로에서만 실행. 다음 셋 중 정확히 하나의 형식으로 한 줄을 기록합니다 (read-only — `git fetch origin <base>` + `git merge-tree --merge-base origin/<base> HEAD origin/<base>` 만 허용; mutating git 명령 금지):
-
-- `- Not run (user picked local only or skip).`
-- `- Clean — no conflicts against <base> at <origin/base SHA>.`
-- `- Conflicts detected against <base> at <origin/base SHA>; user chose <proceed anyway | change base branch | cancel>. Conflicting paths: <list>.`
-
-`push + PR` 인데 본 항목이 없거나 위 셋 외의 자유 서술이면 self-review 가 `contract-violated` 로 종료합니다 (`release-handoff` profile self-review 6번 — merge-conflict probe audit).
-
-### 4.6.7 Pull Request Outcome (PR 결과)
-
-다음 네 가지 중 정확히 하나의 형식으로 한 줄:
-
-- `- No PR action requested.` (H1 = `local only` 또는 `skip`)
-- `- PR created: <url>` + 타이틀 + base 브랜치
-- `- PR reused: <url>` (run 시작 시 같은 head 의 open PR 이 이미 존재해 `gh pr create` 생략)
-- `- PR creation skipped: <reason>` (H3 = `cancel`, 또는 push/PR 도중 사용자 중단)
-
-### 4.6.8 Routing Recommendation (마지막 phase 라우팅)
-
-`release-handoff` 는 lifecycle 종착 phase 이므로 일반적으로 `done` 으로 라우팅합니다. H1 = `skip` 또는 H3 = `cancel` 로 종료된 경우 재진입 가능 여부를 한 줄로 명시합니다.
-
-형식 예시: `- Routing: done. PR <url> opened against <base>; no follow-up required.`
-
-<!-- /RENDER_IF (task-type == release-handoff) -->
-
-<!-- RENDER_IF: task-type == implementation
-     Delete the entire `## 4.7` block + sub-sections otherwise. -->
-
+{% for row in releaseHandoff.executedCommands -%}
+| {{ row.number }} | `{{ row.command }}` | `{{ row.exitCode }}` | {{ row.outputSummary }} |
+{% endfor %}
+{%- endif %}
+
+### 4.6.5 Commit List
+
+{% if releaseHandoff.commitList.empty -%}
+- No implementation commits found; release-handoff is blocked.
+{%- else %}
+| Short SHA | Full SHA | Subject | Files |
+|-----------|----------|---------|-------|
+{% for row in releaseHandoff.commitList -%}
+| `{{ row.shortSha }}` | `{{ row.fullSha }}` | {{ row.subject }} | {{ row.files }} |
+{% endfor %}
+{%- endif %}
+
+### 4.6.6 Merge Conflict Probe
+
+{% if releaseHandoff.mergeConflictProbe.kind == 'not-run' -%}
+- Not run (user picked local only or skip).
+{%- elif releaseHandoff.mergeConflictProbe.kind == 'clean' -%}
+- Clean — no conflicts against {{ releaseHandoff.mergeConflictProbe.baseBranch }} at {{ releaseHandoff.mergeConflictProbe.baseSha }}.
+{%- else -%}
+- Conflicts detected against {{ releaseHandoff.mergeConflictProbe.baseBranch }} at {{ releaseHandoff.mergeConflictProbe.baseSha }}; user chose {{ releaseHandoff.mergeConflictProbe.userChoice }}. Conflicting paths: {{ releaseHandoff.mergeConflictProbe.conflictingPaths | join(', ') }}.
+{%- endif %}
+
+### 4.6.7 Pull Request Outcome
+
+{% if releaseHandoff.pullRequestOutcome.kind == 'no-action' -%}
+- No PR action requested.
+{%- elif releaseHandoff.pullRequestOutcome.kind == 'created' -%}
+- PR created: {{ releaseHandoff.pullRequestOutcome.url }} — title: {{ releaseHandoff.pullRequestOutcome.title }} (base: {{ releaseHandoff.pullRequestOutcome.baseBranch }})
+{%- elif releaseHandoff.pullRequestOutcome.kind == 'reused' -%}
+- PR reused: {{ releaseHandoff.pullRequestOutcome.url }}
+{%- else -%}
+- PR creation skipped: {{ releaseHandoff.pullRequestOutcome.reason }}
+{%- endif %}
+
+### 4.6.8 Routing Recommendation
+
+{{ releaseHandoff.routingRecommendation }}
+
+{% endif %}
+{% if header.taskType == 'implementation' %}
 ## 4.7 Implementation Deliverables
 
-`implementation` profile 의 "Required deliverable shape" 를 보고서 본문 구조로 옮겨 적습니다. 모든 sub-section 은 필수이며, 비어 있는 경우에도 헤딩은 유지하고 본문에 명시적 빈 상태 한 줄을 적습니다. validator 는 8 개 substring (`Approved Plan Reference`, `Commit List`, `Diff Summary`, `Out-of-plan Edits`, `Validation Evidence`, `Verifier Results`, `Rollback Verification`, `Routing Recommendation`) 의 등장 여부를 검사합니다.
+### 4.7.1 Approved Plan Reference
 
-### 4.7.1 Approved Plan Reference (승인된 계획 참조)
+- Plan file (project-relative): `{{ implementation.approvedPlanReference.planFile }}`
+- Approval evidence:
+  > {{ implementation.approvedPlanReference.approvalEvidence }}
+- 본 run 의 `EXECUTOR_WORKTREE_PATH`: `{{ implementation.approvedPlanReference.executorWorktreePath }}`
+- 본 run 의 base ref: `{{ implementation.approvedPlanReference.baseRefSha }}`
 
-- Plan file (project-relative): `<runs/implementation-planning/.../reports/final-report-implementation-planning-<seq>.md>`
-- Approval evidence (해당 plan 의 정확한 인용 — `- [x] Approved` 마커 + Section 4.5.3 Recommended Option 한 줄):
-  > <원문 인용>
-- 본 run 의 `EXECUTOR_WORKTREE_PATH`: `<absolute path>`
-- 본 run 의 base ref (`{{EXECUTOR_WORKTREE_BASE_REF}}`): `<commit SHA>`
-
-### 4.7.2 Commit List (생성된 commit)
+### 4.7.2 Commit List
 
+{% if implementation.commitList | length == 0 -%}
+- No implementation commits produced; routing recommendation must be back to implementation-planning.
+{%- else %}
 | # | Short SHA | Full SHA | Plan Step | Subject | Files |
 |---|-----------|----------|-----------|---------|-------|
-| 1 | `<abc1234>` | `<full-sha>` | Step 1 | `<exact commit subject>` | `<file paths>` |
-
-규칙: 한 commit = 한 plan step (또는 cohesive sub-step). `Subject` 는 git log 에 적힌 원문 그대로 — 재해석·요약 금지. commit 이 없으면 본 run 은 실행되지 않아야 했음 → `- No implementation commits produced; routing recommendation must be back to implementation-planning.` 한 줄.
+{% for row in implementation.commitList -%}
+| {{ row.number }} | `{{ row.shortSha }}` | `{{ row.fullSha }}` | {{ row.planStep }} | {{ row.subject }} | {{ row.files }} |
+{% endfor %}
+{%- endif %}
 
-### 4.7.3 Diff Summary (변경 요약)
+### 4.7.3 Diff Summary
 
 ```
-<git diff --stat <base>..HEAD 의 raw 출력>
+{{ implementation.diffSummary.rawStat }}
 ```
 
-다음으로 file-by-file 한 줄 요약 표:
-
 | File | Action | Lines (+/-) | Plan step / Out-of-plan |
 |------|--------|-------------|--------------------------|
-| `<path>` | created / modified / deleted | `+12 / -3` | Step 2 또는 `Out-of-plan` |
-
-### 4.7.4 Out-of-plan Edits (계획 외 편집)
-
-승인된 plan 의 file list 에 없는 파일을 편집한 경우 row 로 기록. 없으면 `- 계획 외 편집 없음.` 한 줄.
-
-| ID | File | Rationale | Trigger (어떤 step 수행 중 발견) |
-|----|------|-----------|--------------------------------|
-| OOP-001 | `<path>` | <한 두 문장> | Step `<N>` |
-
-### 4.7.5 Validation Evidence (검증 증거)
-
-plan 의 `4.5.6 Validation Checklist` 의 pre / mid / post 각 row 에 대해 실제 명령과 출력 / exit code 를 모두 기록합니다. 요약·"tests pass" 같은 단어 금지 — 명령 line 과 exit code 는 원문 그대로.
-
-| Phase | Command | Exit code | Output tail (≤10 lines) | TDD evidence (failing→passing SHAs) |
-|-------|---------|-----------|--------------------------|--------------------------------------|
-| pre   | `<cmd>` | `0` | <인용> | -- |
-| mid   | `<cmd>` | `0` | <인용> | `<failing SHA>` → `<passing SHA>` |
-| post  | `<cmd>` | `0` | <인용> | -- |
-
-### 4.7.6 Verifier Results (verifier 별 결과)
-
-verifier role 마다 한 sub-block 으로 정리합니다 (`Claude verifier`, `Codex verifier`, opt-in 시 `Gemini verifier`). 각 verifier 의 read-only 명령 로그, 독립 재실행 결과, lint/format/typecheck 결과, 그리고 Discrepancy 라인을 모두 보존합니다. lead 는 합의 verdict 를 합성하되 의견을 collapse 하지 않습니다.
-
-- **Claude verifier** — Verdict: `<PASS | CONCERNS | FAIL>`
-  - Read-only command log: <verifier 의 worker result 에서 원문 인용>
-  - Independent validation re-run: <plan validation command 별 exit code + tail>
-  - Style / lint / type-check: <도구·exit code·새 위반 수>
-  - Declined fix recommendations: <한 줄씩 — 없으면 `- 없음.`>
-  - Discrepancy (vs executor): `- 없음.` 또는 `- <plan step / command>: executor=<result>, verifier=<result>`
-- **Codex verifier** — Verdict: ...
-- **Gemini verifier** (opt-in 시) — Verdict: ...
-
-합의 verdict (lead 합성): `<PASS | CONCERNS | FAIL>` — 한 verifier 라도 `FAIL` 이면 합의는 `FAIL` (override 시 lead 가 구체적 재현 시점 이유 인용 필수).
-
-### 4.7.7 Rollback Verification (롤백 검증)
-
-변경 카테고리별로 다른 강도의 확인. 표 1 행 = 1 카테고리.
+{% for row in implementation.diffSummary.files -%}
+| `{{ row.file }}` | {{ row.action }} | `{{ row.lines }}` | {{ row.planStep }} |
+{% endfor %}
+
+### 4.7.4 Out-of-plan Edits
+
+{% if implementation.outOfPlanEdits | length == 0 -%}
+- 계획 외 편집 없음.
+{%- else %}
+| ID | File | Rationale | Trigger |
+|----|------|-----------|---------|
+{% for row in implementation.outOfPlanEdits -%}
+| {{ row.id }} | `{{ row.file }}` | {{ row.rationale }} | {{ row.trigger }} |
+{% endfor %}
+{%- endif %}
+
+### 4.7.5 Validation Evidence
+
+| Phase | Command | Exit code | Output tail | TDD evidence |
+|-------|---------|-----------|-------------|--------------|
+{% for row in implementation.validationEvidence -%}
+| {{ row.phase }} | `{{ row.command }}` | `{{ row.exitCode }}` | {{ row.outputTail }} | {{ row.tddEvidence or '--' }} |
+{% endfor %}
+
+### 4.7.6 Verifier Results
+
+{% for block in implementation.verifierResults %}
+- **{{ block.verifier }}** — Verdict: `{{ block.verdict }}`
+  - Read-only command log: {{ block.readOnlyCommandLog }}
+  - Independent validation re-run: {{ block.independentValidationRerun }}
+  - Style / lint / type-check: {{ block.styleLintTypecheck or '--' }}
+  - Declined fix recommendations: {{ block.declinedFixRecommendations or '- 없음.' }}
+  - Discrepancy: {{ block.discrepancy or '- 없음.' }}
+{% endfor %}
+
+### 4.7.7 Rollback Verification
 
 | Category | Rollback command | Verification | Result |
 |----------|-------------------|---------------|--------|
-| Pure code | `git revert <SHA>` | `git rev-parse <SHA>` 가 resolve 됨 | `ok` |
-| Feature-flag-gated | flag off 상태 validation run | 위 4.7.5 의 해당 명령 인용 | `ok` |
-| Schema/config/stateful | rollback step `<cmd>` dry-run | exit code + stdout 인용 | `ok` 또는 `unable — route back to planning` |
-
-dry-run 모드가 없는 stateful 변경은 본 항목을 `unable` 로 적고 `## 6.` 의 첫 항목을 `implementation-planning` 재진입으로 권장해야 합니다.
-
-### 4.7.8 Routing Recommendation (다음 phase 라우팅)
-
-다음 셋 중 하나의 형식으로 한 줄:
-
-- `- Routing: final-verification. All plan steps satisfied; rollback verified; verifier consensus <PASS|CONCERNS>.`
-- `- Routing: error-analysis. <한 줄 — 어떤 결함이 추가 분석을 요구하는지>.`
-- `- Routing: implementation-planning. <한 줄 — 왜 새 plan 이 필요한지 (drift / scope-mismatch / stateful-rollback-gap)>.`
+{% for row in implementation.rollbackVerification -%}
+| {{ row.category }} | `{{ row.rollbackCommand }}` | {{ row.verification }} | `{{ row.result }}` |
+{% endfor %}
 
-<!-- /RENDER_IF (task-type == implementation) -->
+### 4.7.8 Routing Recommendation
 
-<!-- RENDER_IF: task-type == final-verification
-     Delete the entire `## 4.8` block + sub-sections otherwise. -->
+{{ implementation.routingRecommendation }}
 
+{% endif %}
+{% if header.taskType == 'final-verification' %}
 ## 4.8 Final Verification Deliverables
 
-`final-verification` profile 의 "Required deliverable shape" 를 본문 구조로 옮겨 적습니다. 모든 sub-section 필수. validator 는 6 개 substring (`Source Implementation Report`, `Acceptance Blockers`, `Residual Risk`, `Validation Evidence`, `Read-only Command Log`, `Routing Recommendation`) 등장과 `## 2. Final Verdict` 의 `Verdict Token` 값이 `accepted` / `conditional-accept` / `blocked` 중 하나인지 검사합니다.
+### 4.8.1 Source Implementation Report
 
-### 4.8.1 Source Implementation Report (선행 implementation 인용)
-
-- Path (project-relative): `<runs/implementation/.../reports/final-report-implementation-<seq>.md>`
+- Path (project-relative): `{{ finalVerification.sourceImplementationReport.path }}`
 - 인용된 commit list / diff summary 요약:
-  > <원문 인용 — `## 4.7.2` / `## 4.7.3` 에서>
-- 검증 대상 worktree path: `<absolute path>`
-- run 시작 시 capture 한 head/base SHA: `<base SHA> .. <head SHA>`
+  > {{ finalVerification.sourceImplementationReport.commitListQuote }}
+- 검증 대상 worktree path: `{{ finalVerification.sourceImplementationReport.worktreePath }}`
+- run 시작 시 capture 한 head/base SHA: `{{ finalVerification.sourceImplementationReport.baseHeadSha }}`
 - `git status --short` (run 시작 시점):
   ```
-  <원문 그대로>
+  {{ finalVerification.sourceImplementationReport.gitStatusShort }}
   ```
 
-### 4.8.2 Acceptance Blockers (수락 차단 항목)
-
-비어 있으면 표 대신 `- No acceptance blockers found.` 한 줄. 모든 blocker 는 구체적 artifact (file:line, log, exit code, MCP SELECT 결과) 인용 필수 — 증거 없는 blocker 는 4.8.3 residual risk 로 강등.
-
-| ID | Severity | Statement | Evidence (path:line / log / exit code) | Recommended follow-up phase |
-|----|----------|-----------|-----------------------------------------|------------------------------|
-| AB-001 | `critical / major / minor` | <한 줄 결함 요약> | `<file>:<line>` 또는 로그 인용 | `error-analysis` / `implementation-planning` |
+### 4.8.2 Acceptance Blockers
 
-### 4.8.3 Residual Risk (잔존 위험)
+{% if finalVerification.acceptanceBlockers | length == 0 -%}
+- No acceptance blockers found.
+{%- else %}
+| ID | Severity | Statement | Evidence | Recommended follow-up phase |
+|----|----------|-----------|----------|------------------------------|
+{% for row in finalVerification.acceptanceBlockers -%}
+| {{ row.id }} | `{{ row.severity }}` | {{ row.statement }} | {{ row.evidence }} | `{{ row.followUpPhase }}` |
+{% endfor %}
+{%- endif %}
 
-blocker 는 아니지만 추적해야 할 위험. 각 항목에 mitigation owner 와 blocker 로 격상되는 trigger 를 명시.
+### 4.8.3 Residual Risk
 
+{% if finalVerification.residualRisk | length == 0 -%}
+- 추적 대상 잔존 위험 없음.
+{%- else %}
 | ID | Item | Mitigation owner | Escalation trigger |
 |----|------|------------------|---------------------|
-| RR-001 | <한 줄> | <역할 / 팀> | <어떤 조건이면 AB-? 로 격상> |
-
-비어 있으면: `- 추적 대상 잔존 위험 없음.`
+{% for row in finalVerification.residualRisk -%}
+| {{ row.id }} | {{ row.item }} | {{ row.owner }} | {{ row.escalationTrigger }} |
+{% endfor %}
+{%- endif %}
 
 ### 4.8.4 Validation Evidence (요구사항 커버리지)
 
-선행 plan / task brief 의 모든 요구사항에 대해 cover 한 artifact 를 cite. 패러프레이즈 ("verified") 금지.
-
-| ID | Requirement (plan/brief 인용) | Artifact (commit SHA / test output / log line / MCP SELECT) | Status (covered / blocker AB-? / gap) |
-|----|--------------------------------|--------------------------------------------------------------|----------------------------------------|
-| VE-001 | <한 줄> | `<artifact>` | covered |
+| ID | Requirement (plan/brief 인용) | Artifact | Status |
+|----|--------------------------------|----------|--------|
+{% for row in finalVerification.validationEvidence -%}
+| {{ row.id }} | {{ row.requirement }} | `{{ row.artifact }}` | {{ row.status }} |
+{% endfor %}
 
-### 4.8.5 Read-only Command Log (실행 명령 로그)
+### 4.8.5 Read-only Command Log
 
-본 run 에서 실행한 모든 명령 (Tier 1 plan validation + Tier 2 `project.json.qaCommands`) 을 실행 순서대로 한 row 씩 기록. mutating 명령은 등장하면 안 됨.
+| # | Tier | Command (verbatim) | Exit code | Output tail |
+|---|------|---------------------|-----------|-------------|
+{% for row in finalVerification.readonlyCommandLog -%}
+| {{ row.number }} | {{ row.tier }} | `{{ row.command }}` | `{{ row.exitCode }}` | {{ row.outputTail }} |
+{% endfor %}
 
-| # | Tier | Command (verbatim) | Exit code | Output tail (≤5 lines) |
-|---|------|---------------------|-----------|-------------------------|
-| 1 | 1    | `<plan validation cmd>` | `0` | <인용> |
-| 2 | 2    | `cargo clippy --all-targets -- -D warnings` | `0` | <인용> |
+### 4.8.6 Routing Recommendation
 
-`project.json.qaCommands` 의 category 가 비어 있으면 `qa-command not configured: <lint/format/typecheck/test>` 한 줄. deny-list (`--fix`, `--write`, ` -w`, ` -u`, `--snapshot-update`, `INSTA_UPDATE=<not-no>`, `cargo update`, `npm install` without `ci` 등) 토큰을 포함한 cmd 는 `qa-command rejected (denied token: <token>): <label>` 한 줄로 기록 후 실행하지 않음.
-
-### 4.8.6 Routing Recommendation (다음 phase 라우팅)
-
-`## 2. Final Verdict` 의 `Verdict Token` 과 1:1 대응. 다음 셋 중 하나:
-
-- `- Routing: release-handoff. Verdict Token = accepted; PR-ready.`
-- `- Routing: release-handoff with conditions. Verdict Token = conditional-accept; conditions listed in 4.8.2 / 4.8.3 must be resolved before push.`
-- `- Routing: error-analysis (or implementation-planning). Verdict Token = blocked; <blocker AB-?> requires <re-analysis | replan>.`
-
-<!-- /RENDER_IF (task-type == final-verification) -->
+{{ finalVerification.routingRecommendation }}
 
+{% endif %}
 ## 5. Clarification Items
 
-다음 run 으로 넘어가기 전에 사용자가 답하거나 자료를 첨부해야 하는 항목을 **한 표 안에서** 추적합니다. `task-type` 이 `error-analysis` / `requirements-discovery` 이고 지금까지의 증거만으로 확신 있는 최종 판단이 어려울 때는 반드시 채웁니다. 그 외 task-type 에서는 lead 가 필요하다고 판단할 때만 채우고, 그렇지 않다면 `- 추가 정보 요청 없음. Section 2 의 최종 판단이 그대로 유효합니다.` 한 줄만 남깁니다.
-
-작성 원칙:
-
-- 개발자가 아닌 사람도 한 번 읽고 무엇을 어디서 가져와야 하는지 이해할 수 있게, 줄임말과 내부 용어 대신 풀어 쓴 문장.
-- 한 행은 "왜 필요한지", "무엇을 묻거나 받아야 하는지", "어떤 형태의 답을 기대하는지" 가 모두 드러나야 함.
-- 항목별 ID (`C-001`, `C-002`, …) 는 run 간 유지. 답변된 항목은 다음 run 에서도 삭제하지 말고 `Status` 만 `resolved` / `obsolete` 로 갱신.
+다음 run 으로 넘어가기 전에 사용자가 답하거나 자료를 첨부해야 하는 항목을 **한 표 안에서** 추적합니다.
 
+{% if clarificationItems | length == 0 -%}
+- 추가 정보 요청 없음. Section 2 의 최종 판단이 그대로 유효합니다.
+{%- else %}
 답을 채우신 뒤 같은 phase 를 다시 실행:
 
-- Claude Code: `/okstra-run resume-clarification task-key={{TASK_KEY}}`
-- 별도 터미널: `scripts/okstra.sh --resume-clarification --task-key {{TASK_KEY}}`
+- Claude Code: `/okstra-run resume-clarification task-key={{ header.taskKey }}`
+- 별도 터미널: `scripts/okstra.sh --resume-clarification --task-key {{ header.taskKey }}`
 
-| ID | Ticket ID | Kind | Statement (무엇이 필요한지 + 왜) | Expected form (답·자료의 모양) | Blocks | Status | User input |
-|----|-----------|------|----------------------------------|-------------------------------|--------|--------|-----------|
-| C-001 | `<TICKET-or-fallback>` | `decision` | <예: "지난 주 새벽 결제 실패가 일회성이었는지 재발했는지 알려주세요. 다음 run 의 task-type 이 `error-analysis` 로 갈지 `requirements-discovery` 로 갈지가 갈립니다."> | <예: "(a) 일회성, (b) 재발 — 최근 시각 YYYY-MM-DD HH:MM, 영향 사용자 수 약 N명"> | `next-phase` | open | <빈칸으로 두고 다음 run 전에 사용자가 채움> |
-| C-002 | `<TICKET-or-fallback>` | `material` | <예: "오류 시각 전후 30분 worker 로그가 필요합니다. Datadog `service:worker env:prod` 필터, 시각 2026-04-30 09:30~10:30 KST. `.project-docs/okstra/tasks/8852/logs/worker-2026-04-30.log` 로 저장해 주세요."> | <예: "위 경로의 .log 파일 (gzip 가능)"> | `next-phase` | open |  |
-| C-003 | `<TICKET-or-fallback>` | `data-point` | <예: "본 배치 시작 직전 `common.FontManualClassifiers` 의 `prediction=0` / `prediction=1` 행 수가 필요합니다. acceptance #5 의 동일성 검증 ground truth."> | <예: "두 정수 (prediction=0 count, prediction=1 count) 한 줄로"> | `approval` | open |  |
+| ID | Ticket ID | Kind | Statement | Expected form | Blocks | Status | User input |
+|----|-----------|------|-----------|---------------|--------|--------|-----------|
+{% for row in clarificationItems -%}
+| {{ row.id }} | `{{ row.ticketId }}` | `{{ row.kind }}` | {{ row.statement }} | {{ row.expectedForm }} | `{{ row.blocks }}` | {{ row.status }} | {{ row.userInput or '' }} |
+{% endfor %}
 
 컬럼 가이드 (전체 정의는 `prompts/profiles/_common-contract.md §Clarification request policy` SSOT 참조):
 
 - **`Kind`** ∈ `{material, decision, data-point}`.
-- **`Blocks`** ∈ `{approval, next-phase, none}` — `approval` 은 implementation-planning 의 승인 게이트 차단.
+- **`Blocks`** ∈ `{approval, next-phase, none}`.
 - **`Status`** ∈ `{open, answered, resolved, obsolete}`.
-
-안티패턴 (validator 가 fail 처리):
-
-- 같은 항목을 별도 sub-section (`5.1 추가 자료 요청` / `5.2 사용자 확인 질문` / `4.5.9 Open Questions`) 으로 분리하기 — 본 8-열 표 한 곳으로만 표현합니다.
-- 한 행을 두 개로 쪼개기 — 자료 + yes/no 가 묶인 항목은 `Kind=material`, `Expected form` 에 "파일 경로 + yes/no" 라고 적은 한 행.
-- 사용자가 답하지 않아도 진행 가능한 항목을 `Blocks=approval` 로 표시 — `Blocks=none` / `next-phase` 로 정확히 표시.
+{%- endif %}
 
 ## 6. Recommended Next Steps
 
-This section is **always present** — never omit the heading. If there are no concrete actions, write the single line `- No further action required. Final verdict in section 2 stands.` and stop.
-
-When concrete actions exist, list them as a numbered list. Each item includes the exact copy-pasteable command(s). Show **both** the in-session form (`/okstra-run …`) and the external-terminal form (`scripts/okstra.sh …`) — the Node `okstra` admin CLI does NOT accept `--task-key` / `--task-type` / `--resume-clarification`.
-
-1. **Highest-priority next action.** State what + why in one sentence, then the command.
-   - Same phase rerun:
-     - Claude Code: `/okstra-run task-key={{TASK_KEY}} task-type={{TASK_TYPE}}`
-     - 별도 터미널: `scripts/okstra.sh --task-key {{TASK_KEY}} --task-type {{TASK_TYPE}}`
-   - Next phase (omit `task-type` to use the manifest's `workflow.nextRecommendedPhase` when concrete):
-     - Claude Code: `/okstra-run task-key={{TASK_KEY}} task-type=<next-phase>`
-     - 별도 터미널: `scripts/okstra.sh --task-key {{TASK_KEY}} --task-type <next-phase>`
-2. **Additional read-only verification** before moving to the next phase (test commands, log queries, dashboard URLs). No state-mutating commands here.
-3. **Follow-up tasks** if needed. Reference by `task-key` when they exist; otherwise describe the new brief to draft.
-4. **If `## 5.` has any row with `Status` in `{open, answered}`**, the highest-priority next step MUST be the clarification turn-around:
-   - Preferred: `/okstra-run resume-clarification task-key={{TASK_KEY}}` / `scripts/okstra.sh --resume-clarification --task-key {{TASK_KEY}}`.
-
-Empty-state placeholder (copy verbatim when nothing else applies): `- No further action required. Final verdict in section 2 stands.`
+{% if recommendedNextSteps | length == 0 -%}
+- No further action required. Final verdict in section 2 stands.
+{%- else %}
+{% for step in recommendedNextSteps -%}
+{{ loop.index }}. {{ step.text }}
+{% if step.commands -%}
+{% for cmd in step.commands %}
+   - {{ cmd.label }}:
+     - Claude Code: `{{ cmd.claudeCode }}`
+     - 별도 터미널: `{{ cmd.terminal }}`
+{% endfor -%}
+{%- endif %}
+{% endfor %}
+{%- endif %}
 
 ## 7. Follow-up Tasks (후속 작업)
 
-본 run 이 끝난 뒤 사용자가 이어갈 모든 task 를 한 표에 정리. 두 종류가 동거합니다:
-
-1. **phase-continuation row (필수)** — 본 task 의 다음 phase. `Suggested task-type` 은 `## 2. Final Verdict` 의 다음 phase 와 byte-identical. `Auto-spawn? = no` 로 고정 (다음 phase 는 사용자가 `/okstra-run` 으로 직접 진입하며, spawn 스크립트가 task 디렉토리를 자동 생성하지 않음).
-2. **scope-boundary row (선택)** — 본 run 의 구현·검증 범위를 **넘어서는** 작업. lead 가 필요하다고 판단할 때만.
-
-phase-continuation row 의무 적용 범위:
-
-- `task-type` ∈ {`requirements-discovery`, `implementation-planning`, `error-analysis`, `implementation`, `final-verification`}: **필수**. 다음 phase 가 자명하므로 phase-continuation row 한 개를 반드시 채움.
-- `release-handoff`: 다음 phase 없음 → phase-continuation 생략. scope-boundary row 만 (있다면) 채움.
-
-후속 항목 출처(`Origin` 컬럼): `phase-continuation` / `out-of-plan` / `verifier-concern` / `scope-boundary` / `open-question` / `manual` 중 하나.
-
-규칙: `Auto-spawn? = yes` 인 row 는 Phase 7 의 `scripts/okstra-spawn-followups.py` 가 자동으로 `tasks/<TASK_GROUP>/<New Task ID>/` 디렉터리 + `task-manifest.json` (status: `todo`) + stub task-brief 를 생성. `no` 는 사람이 처리. `phase-continuation` row 는 항상 `no` — 같은 task-key 를 재사용하여 다음 phase 로 진입하므로 새 task 디렉터리를 만들면 안 됨. `New Task ID` 는 task-group 내 유일한 알파숫자·하이픈 slug(phase-continuation row 의 경우 현재 task-id 를 그대로 사용). 동일 follow-up 이 여러 run 에 등장하면 `New Task ID` 를 동일하게 유지하여 중복 spawn 방지.
-
+{% if followUpTasks | length == 0 -%}
+- 후속 작업 없음. 본 run 의 다음 phase 는 §6 (Recommended Next Steps) 참고.
+{%- else %}
 | ID | Ticket ID | Origin | New Task ID | Title | Suggested task-type | Scope (files/areas) | Reason / Why deferred | Priority (P0/P1/P2) | Auto-spawn? |
 |----|-----------|--------|-------------|-------|---------------------|---------------------|------------------------|---------------------|-------------|
-| FU-001 | `<TICKET-or-fallback>` | `phase-continuation` | `<current-task-id>` | <다음 phase 진입 요약> | `<next-task-type>` | `<scope summary>` | <다음 phase 가 자동으로 추천되는 사유 한 줄> | `P0` | `no` |
-| FU-002 | `<TICKET-or-fallback>` | `<out-of-plan / verifier-concern / scope-boundary / open-question / manual>` | `<new-task-id-slug>` | <한 줄 제목> | `<task-type>` | `<files / areas>` | <한 두 문장 사유> | `P1` | `yes` |
-
-빈 상태(phase-continuation 의무가 없는 task-type 이고 scope-boundary 도 없을 때): `- 후속 작업 없음. 본 run 의 다음 phase 는 §6 (Recommended Next Steps) 참고.`
-
-본 섹션이 채워진 경우 Section 6 의 "Follow-up tasks" 항목에 진입 명령(phase-continuation 은 `/okstra-run` 형태, auto-spawn 된 row 는 새 task-key)을 함께 적어 사용자가 즉시 이어갈 수 있게 합니다.
-
-## Writing Rules
-
-- Markdown. 본문은 한국어. 기술 식별자 (파일 경로, 코드 심볼, 모델명, status 값) 는 원형 유지.
-- 섹션 구조는 brief 가 명시적으로 다른 구조를 요구하지 않는 한 보존.
-- 증거 기반 (speculation 금지). 메타 코멘트 (저장소·세션·이전 메시지 언급) 로 본문 대체 금지.
-- 본 문서는 `Claude lead` 의 최종 합성이지 raw worker dump 가 아닙니다.
-- 표 우선. 같은 모양의 항목을 여러 개 나열할 때 bullet 으로 degrade 금지.
-- Reading Confirmation / 워커 raw output / 환산식 설명 등 audit 자료는 본문이 아닌 사이드카에 둡니다 (`runs/<task-type>/worker-results/<worker>-audit-<task-type>-<seq>.md`).
+{% for row in followUpTasks -%}
+| {{ row.id }} | `{{ row.ticketId }}` | `{{ row.origin }}` | `{{ row.newTaskId }}` | {{ row.title }} | `{{ row.suggestedTaskType }}` | `{{ row.scope }}` | {{ row.reason }} | `{{ row.priority }}` | `{{ row.autoSpawn }}` |
+{% endfor %}
+{%- endif %}