okstra 0.36.0 → 0.36.2

package/runtime/templates/worker-prompt-preamble.md

@@ -0,0 +1,108 @@
+# Worker Prompt Preamble (canonical)
+
+This file is the single source of truth for the boilerplate that every okstra analysis worker, verifier, and report-writer worker must honour. The lead injects ONE anchor line into each dispatched worker prompt — `**Worker Preamble Path:** <abs-path>` — pointing here. Workers Read this file end-to-end before producing any output.
+
+It replaces the previous practice of inlining ~80 lines of identical boilerplate into every worker prompt body.
+
+---
+
+## Required reading (analysis workers + report-writer worker)
+
+You are required to read every input file enumerated by the dispatcher (the lead's prompt lists them under `[Required reading]`) from the very first character to the very last character before you produce any analysis output. Skimming, partial reads, jumping to a single section, or relying on prior knowledge of a similar file's structure is not acceptable. Each file may contain decisive context that is not surfaced in its summary or first page.
+
+### Audience-scoped enumeration (BLOCKING — performance optimization)
+
+Different recipients need different files. Do NOT include `final-report-template.md` in analysis worker prompts: analysis workers produce findings (not the final report), and forcing them to read the template inflates token usage without changing finding quality.
+
+| Recipient | Files included in `[Required reading]` |
+|---|---|
+| Claude / Codex / Gemini analysis workers | task-brief, analysis-profile, analysis-material (if present), reference-expectations, clarification-response (if carry-in) |
+| Report writer worker (Phase 6) | all of the above **plus** `final-report-template.md` |
+| Reverify dispatches (Phase 5.5, lightweight mode) | **do NOT inject `[Required reading]` at all** — see [okstra-convergence](../skills/okstra-convergence/SKILL.md) "Reverify prompt: required-reading suppression". |
+
+### Reading rules
+
+- Use a single `Read` tool call per file with no `offset` and no `limit`. If a file is genuinely too large for one read, page through with explicit `offset` / `limit` covering the entire file, and state the page boundaries in your Findings.
+- For the carry-in clarification response, walk every row of `## 5. Clarification Items` (`C-001`, `C-002`, ...) in full, including rows whose `User input` cell is blank — a blank `User input` with `Status=open` is itself a signal you must surface. The structural similarity between the prior final report and the upcoming output is NOT a license to skim.
+- Write the Reading Confirmation block to your **audit sidecar** at `runs/<task-type>/worker-results/<worker>-audit-<task-type>-<seq>.md` (sibling to the main worker-results file). One short line per input file confirming end-to-end reading. Do NOT include a `## 0. Reading Confirmation` heading in the main worker-results file — the validator fails worker-results that contain one. If you cannot truthfully confirm a file end-to-end, record a `tool-failure` in the errors sidecar instead of fabricating Findings.
+- Do not collapse multiple input files into a single mental summary before reading them all individually. Each file has its own canonical role: brief = the user's request, profile = the lead's rules for this phase, reference-expectations = ground-truth config/deployment values, clarification-response = prior run's open questions and the user's answers, final-report-template = the structure your eventual writeup must conform to. Conflating them loses signal.
+
+---
+
+## Error reporting (all workers)
+
+If any tool call you make (Bash, Read, Edit, MCP, etc.) returns a non-zero exit code, raises an exception, or otherwise fails its intended effect, append a single entry to your worker errors sidecar at the absolute path the lead provided as `**Errors sidecar path:** <abs-path>`.
+
+If the sidecar file does not exist, create it with `{"schemaVersion": 1, "errors": []}` then append.
+
+### Entry schema
+
+```json
+{
+  "ts": "<ISO 8601 UTC>",
+  "phase": "<current okstra phase>",
+  "errorType": "tool-failure",
+  "command": "<failed command/tool signature>",
+  "commandKind": "bash | tool:Read | tool:Edit | mcp | ...",
+  "exitCode": <int or null>,
+  "durationMs": <int or null>,
+  "message": "<one-line human summary>",
+  "stderrExcerpt": "<first ~2KB of stderr, or null>",
+  "context": { ... or null }
+}
+```
+
+### Rules
+
+- Do NOT include `source` / `recordedAt` / `agent` / `agentRole` / `model` / `taskKey` — the lead fills those in when dumping the sidecar to the run-level errors log via `okstra-error-log.py append-from-worker`.
+- Do NOT use `errorType` values other than `"tool-failure"` in the sidecar. `cli-failure` events are recorded by CLI wrapper agents (codex / gemini) directly to the run-level errors log, not via the sidecar. `contract-violation` events are recorded by the lead after inspecting worker outputs.
+- Continue your task after recording; do not abort unless the failure makes the task impossible.
+
+### Path extraction (BLOCKING)
+
+Before recording anything, extract the absolute paths verbatim from the lead's dispatch prompt body:
+
+- `**Errors log path:** <abs-path>` — the run-level errors JSONL. Used by CLI wrapper agents via `okstra-error-log.py append-observed` for `cli-failure` events.
+- `**Errors sidecar path:** <abs-path>` — this worker's per-run sidecar JSON. Used by all workers for `tool-failure` events.
+
+If a required header line is absent from the dispatch prompt, return `<SENTINEL_PREFIX>_ERRORS_PATH_MISSING: lead prompt did not include **Errors log path:** / **Errors sidecar path:** headers` (substitute the worker's sentinel prefix — `CLAUDE_WORKER`, `CODEX`, `GEMINI`, or `REPORT_WRITER`) without proceeding. Do NOT synthesize the path from `<runDir>/logs/...` — that template syntax is documentation only; historical failure mode produced silently empty run-level error logs.
+
+---
+
+## Anchor headers (lead-injected, BLOCKING)
+
+Every worker prompt MUST begin with these anchor headers, in this exact order, before any other content. Workers extract them verbatim.
+
+1. `**Project Root:** <absolute-path>` — required so the worker can self-anchor without relying on inherited cwd.
+2. `**Prompt History Path:** <project-relative-path>`
+3. `**Result Path:** <project-relative-path>` — canonical destination for the worker's result file.
+4. `Assigned worker prompt history path: <absolute-path>` — same as the prompt-history path but resolved against `Project Root`. Codex / Gemini wrapper subagents extract this exact line.
+5. `**Worker Preamble Path:** <absolute-path>` — points to THIS file. Workers Read it end-to-end before doing anything else.
+6. `**Errors log path:** <absolute-path>` — run-level JSONL (see Error reporting above).
+7. `**Errors sidecar path:** <absolute-path>` — per-worker JSON (see Error reporting above).
+
+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`.
+
+When a worker reads any project-relative path from the prompt, it MUST resolve it against `Project Root` (e.g. `<Project Root>/<Result Path>`) — never use bare relative paths that depend on cwd.
+
+---
+
+## Worker output sections (analysis workers)
+
+Every analysis worker (Claude / Codex / Gemini) produces sections 1–5 with the same dimensions. The lead does NOT bias worker prompts with per-worker emphasis — sections 1–5 are the common core, and specialization lives only in optional Section 6.
+
+1. **Findings** — what you identified
+2. **Missing Information or Assumptions** — gaps in the analysis
+3. **Safe or Reasonable Areas** — parts that look correct
+4. **Uncertain Points** — areas needing further review
+5. **Recommended Next Actions** — suggested follow-ups
+6. **Specialization Lens (optional)** — additive content from your specialization lens. Items here are NOT subject to convergence cross-verification.
+
+Every item in sections 1–5 (and any section 6) MUST carry a worker-internal item ID unique within the file. Lead synthesis preserves these as `<worker>:<item-id>` in `Source items (worker:item)` columns.
+
+For task types `requirements-discovery`, `error-analysis`, `implementation-planning`, or `implementation`, every item in sections 1–5 MUST carry a ticket identifier. Use the `Ticket ID` column in table-form items and the `[TICKETID: <id>]` prefix in bullet/numbered items.
+
+See `skills/okstra-team-contract/SKILL.md` "Worker Output Contract" for the full frontmatter schema and section ordering rules. This preamble is consistent with that contract; the team-contract document is authoritative if the two ever diverge.

package/src/uninstall.mjs

@@ -20,14 +20,18 @@ const FALLBACK_SKILL_NAMES = [
   "okstra-setup",
   "okstra-brief",
   "okstra-run",
-  "okstra-status",
-  "okstra-history",
+  "okstra-inspect",
   "okstra-schedule",
-  "okstra-logs",
   "okstra-context-loader",
   "okstra-team-contract",
   "okstra-convergence",
   "okstra-report-writer",
+  // Pre-merge names — kept so uninstall on an upgraded machine still cleans
+  // them out of ~/.claude/skills/ once the user runs `okstra uninstall`.
+  // Safe to drop after a few releases when nobody has them installed.
+  "okstra-status",
+  "okstra-history",
+  "okstra-logs",
   "okstra-report-finder",
   "okstra-time-summary",
 ];

package/runtime/prompts/profiles/kr/_common-contract.md

@@ -1,92 +0,0 @@
-<!--
-모든 프로필이 INCLUDE 지시문으로 그대로 포함하는 공유 계약 조각입니다
-(scripts/okstra_ctl/run.py:_expand_profile_includes 참고).
-이 파일을 한 번 수정하면 다음 렌더링 때 모든 프로필에 반영됩니다. 이 파일에는
-phase별 규칙을 추가하지 마세요. phase 규칙은 각 프로필 문서에 둡니다.
--->
-- Team contract (공통):
-  - `Claude lead`는 종합만 담당하며 `Claude worker`와 분리됩니다. `implementation`에서는 `Executor` 및 verifier와도 구분됩니다.
-  - `Report writer worker`는 final-report 파일의 **작성자**입니다. `Claude lead`는 작성된 초안을 검토하고 승인하며 파일을 직접 작성하지 않습니다. 권위 있는 계약은 `okstra-team-contract`와 `okstra-report-writer`를 참고하세요.
-  - 기본 모델 할당은 중앙화된 기본값에서 해석됩니다. fallback 값은 `Claude lead`/`Report writer worker`=`opus`, `Claude worker`=`sonnet`, `Codex worker`=`gpt-5.5`, `Gemini worker`=`auto`입니다. phase별 override(예: `implementation`의 executor binding)는 각 프로필 문서에 둡니다.
-  - 각 프로필의 `Required workers:` 블록에 나열된 모든 필수 worker는 반드시 시도해야 합니다. 최종 verdict는 각 worker가 결과를 내거나 명시적인 terminal status(`timeout`, `error`, `not-run`)에 도달할 때까지 기다립니다.
-  - 이름 없는 일반 병렬 worker가 필수 역할 roster를 대체해서는 안 되며, 이 roster를 넘어서는 추가 sub-agent dispatch는 허용되지 않습니다.
-- Worker interaction model (공통 - roster만 보고 동작을 추론하기 전에 읽을 것):
-  - 각 프로필의 `Required workers:` 블록은 **roster**이지 동작 계약이 아닙니다. 각 역할의 상호작용 방식은 같은 run 안에서도 운영 phase에 따라 달라집니다.
-  - **Phase 4 / 5 (independent analysis)**: analyser worker(`claude`, `codex`, opt-in된 `gemini`)는 서로의 출력에 접근하지 않고 독립적으로 findings를 생성합니다. `report-writer`는 분석하지 않습니다.
-  - **Phase 5.5 (convergence - workers peer review)**: lead는 각 analyser의 findings를 *다른* analyser들에게 replay하고 최대 `effectiveMaxRounds` 라운드 동안 `AGREE` / `DISAGREE` / `SUPPLEMENT` verdict를 수집합니다. 이 phase에서 worker들은 서로의 findings에 대한 peer reviewer로 행동합니다. lead는 중재하지만 투표하지 않습니다. 라운드 프로토콜, queue invariant, 최종 분류(`full-consensus` / `partial-consensus` / `contested` / `worker-unique`)는 `skills/okstra-convergence/SKILL.md`를 참고하세요.
-  - roster만 보고 "peer review가 일어나지 않는다"고 결론내리지 마세요. analyser worker를 2개 이상 나열한 모든 프로필은 기본적으로 convergence를 실행합니다(`task-manifest.json`의 `convergence.enabled=true`).
-- Tooling - read-only MCP availability (공통):
-  - MCP는 암묵적인 okstra context가 아닙니다. task brief가 이번 run의 source material로 명시적으로 나열한 MCP server만 조회합니다. MCP에서 파생한 모든 finding은 server, table, 사용한 SELECT를 인용해야 합니다. MCP는 절대 write path로 사용해서는 안 됩니다. schema/data mutation은 사람이 검토하는 repository migration file을 통해 수행합니다.
-- Resource boundary (공통 - artifact-home rule):
-  - okstra가 소유하는 project artifact는 `<PROJECT_ROOT>/.project-docs/okstra/**` 아래에만 둡니다. 해당 subtree의 `project.json`, task bundle, run artifact, `glossary.md`, `decisions/`가 okstra memory의 canonical source입니다.
-  - `<PROJECT_ROOT>/.project-docs/okstra/**` 밖 path는 task brief의 `Source Material` 또는 `Reporter Confirmations`가 명시적으로 cite한 경우에만 source material로 읽습니다. 이 path들은 okstra memory가 아닙니다.
-  - create, modify, delete는 `<PROJECT_ROOT>/.project-docs/okstra/**` 안에서만 수행합니다. brief가 특정 non-okstra edit를 verbatim으로 요청한 경우에만 예외이며, 수행 phase는 final report에 사용자 지시 원문을 인용해야 합니다. implementation source edit도 승인된 implementation plan이 추가로 필요합니다.
-- Authority & permissions assumption (모든 okstra task-type에 적용):
-  - **사용자와 사용자 팀이 예상된 작업, 진행 중인 작업, follow-up 작업에 필요한 모든 권한과 permission을 보유하고 있다고 가정합니다.** task brief가 명시적으로 달리 말하지 않는 한 external approval, third-party access grant, role/IAM permission, organisational sign-off, legal/compliance review, vendor coordination, "verify access exists" 단계는 이미 충족된 것으로 취급합니다.
-  - 이런 항목을 routing decision, missing-materials list, clarification question, option trade-off, dependency/migration risk, validation checklist, rollout plan, acceptance blocker, residual risk, release recommendation, `## 5. Clarification Items` table, day/effort estimate에 추가하지 마세요. 일정 연장의 정당한 근거가 아닙니다.
-  - okstra 내부 phase handoff(예: `implementation-planning`의 `User Approval Request` 블록)는 영향을 받지 않습니다. 이는 사용자 본인이 승인하는 것이며 외부 coordination 없이 진행됩니다.
-  - 이 규칙은 phase별 Forbidden actions list를 완화하지 않습니다. 각 프로필 문서의 safety rule은 사용자 권한과 무관하게 계속 적용됩니다.
-- Anti-escalation rule (공통):
-  - "다음 단계 진행해" 또는 동등한 사용자 표현을 *다른* lifecycle phase를 시작하라는 authorisation으로 취급하는 것은 금지됩니다. 다음 phase는 새 `--task-type`으로 실행된 별도의 okstra run에서만 시작됩니다. 각 프로필 문서는 자기 범위 안에서 이를 더 제한할 수 있습니다.
-- Phase wrap-up - worker trace pane disposition (공통, 사용자에게 제어권을 돌려주기 직전 *마지막* 단계여야 함):
-  - Codex / Gemini worker wrapper는 lead의 tmux session에 `<cli>-<role>-<pid>-trace` 제목의 `tail -F` trace pane을 생성합니다(예: `codex-worker-93421-trace`, `gemini-executor-93422-trace`). 대응하는 caller(worker) pane 제목은 `<cli>-<role>-<pid>`이므로 공유 `<pid>` suffix로 worker와 trace pair를 맞출 수 있습니다. 이 pane들은 operator가 최종 출력을 스크롤해 볼 수 있도록 모든 worker invocation 이후에도 의도적으로 남지만, phase가 누적되면 화면을 어지럽힙니다.
-  - `$TMUX_PANE`이 설정되어 있으면, final-report 파일 작성과 routing recommendation 발행이 끝난 뒤 lead는 `$HOME/.okstra/bin/okstra-trace-cleanup.sh --list`를 정확히 한 번 실행해야 합니다. 출력은 이 Claude session에 등록된 모든 trace pane의 tab-separated `<pane_id>\t<pane_title>` 목록입니다.
-  - 목록이 비어 있으면 질문을 건너뜁니다. 물어볼 것이 없습니다.
-  - 그렇지 않으면 lead는 phase 완료를 선언하기 **전에** 사용자에게 엄격한 binary choice를 제시해야 합니다. 다음 형태의 prompt를 하나 사용하세요(나머지 run이 영어라면 영어도 허용되지만 한국어 권장):
-    > 현재 phase 종료 시점입니다. 다음 worker trace pane 이 열려 있습니다 — 닫을까요?
-    > <인용된 `--list` 출력>
-    > (예) 모두 닫기 / (아니오) 그대로 두기
-  - `예` / `y` / `close`이면 `$HOME/.okstra/bin/okstra-trace-cleanup.sh`(인자 없음)를 실행하고 kill count를 한 문장으로 보고합니다.
-  - `아니오` / `n` / `keep`이면 pane을 그대로 둡니다. Claude `/exit`가 `SessionEnd` hook을 실행할 때 자동으로 정리된다고 사용자에게 알려줍니다.
-  - 질문은 깨끗한 yes/no여야 합니다. "일부 닫기 / 일부 유지" 같은 부분 선택지를 제공하지 말고, "codex pane만 닫기" 같은 대안을 제안하지 마세요. 전체 집합 단위 결정이 wrap-up을 예측 가능하게 유지합니다.
-  - 이 단계는 모든 phase(`requirements-discovery`, `error-analysis`, `implementation-planning`, `implementation`, `final-verification`, `release-handoff`)에 필수입니다. `$TMUX_PANE`이 unset이면(lead가 tmux 밖에서 실행 중) 조용히 skip합니다. 이 경우 lead는 synthetic pane list를 만들어내면 안 됩니다.
-- Brief handoff contract (공통 - `okstra-brief`가 만든 task brief를 run이 소비할 때마다 적용):
-  - brief는 **pre-discovery artifact**입니다. domain-reporter의 말(비전문가 또는 개발자)을 expert가 소비할 수 있는 형태로 변환하여 이 phase와 이후 phase가 operator에게 추가 질문 없이 실행되도록 합니다. brief는 solution decision의 권위가 아니며, reporter intent의 권위입니다.
-  - **Reporter confirmation precondition (BLOCKING)**: brief frontmatter에는 `okstra-brief` Step 6.5가 설정한 `reporter-confirmations: <complete | partial | pending | skipped>`가 있습니다. brief를 소비하는 모든 phase는 분석 전에 이 field를 읽어야 합니다. 처리 matrix는 다음과 같습니다.
-    - `complete` -> 정상 진행.
-    - `partial` -> 진행하되, 아직 표시되지 않은 `intent-check:` / `conversion-block:` row는 `skipped` branch로 취급합니다.
-    - `skipped` -> 누락된 답을 조용히 추론하지 마세요. 표시되지 않은 각 `intent-check:` / `conversion-block:` row를 이 run의 `## 5. Clarification Items`로 승격하고 `Kind=decision`을 사용합니다. `implementation-planning`에서는 approval을 gate하므로 `Blocks=approval`, 그 외에는 `Blocks=next-phase`를 사용합니다. 권장 답변은 brief의 대응 내용에서 가져오고 `보고자 직접 확인 권장`이라고 명확히 표시합니다.
-    - `pending`(또는 field missing) -> analysis를 ABORT합니다. `Verdict Card`를 `Verdict Token = blocked` + `Direction = hold`로 렌더링하고, pending row를 요약하는 단일 `## Reporter Confirmation Required` 블록을 작성합니다(앞 번호 없음). `## 5. Clarification Items` table에는 pending item마다 한 row를 넣고, `implementation-planning`에서는 `Blocks=approval`, 그 외에는 `Blocks=next-phase`를 사용합니다. operator는 `okstra-brief` Step 6.5를 다시 실행해야 합니다. 이 경우 `## 0.`을 emit하지 마세요. Section 0은 clarification-response carry-in 전용입니다.
-    `Open Questions` row의 `[CONFIRMED <YYYY-MM-DD> → RC-N]` marker는 reporter가 해당 row에 답했다는 per-row signal입니다. 답변 원문은 brief의 `## Reporter Confirmations` 아래에 있습니다.
-  - `Source Material`은 reporter-verbatim입니다. 이를 paraphrase, summarize, reorder, restructure하지 마세요. 필요할 때 직접 인용합니다.
-  - `Augmentation` entry에는 `evidence-link`, `format-conversion`, `terminology-mapping`, `intent-inference` 네 label 중 하나가 붙습니다. 다음과 같이 취급합니다.
-    - `evidence-link` / `format-conversion` -> 재검증 없이 신뢰합니다.
-    - `terminology-mapping` -> `<PROJECT_ROOT>/.project-docs/okstra/glossary.md`(권위 있음)에 비추어 검증합니다. mapping이 없거나 glossary와 모순되면 `Clarification Items` row를 올립니다.
-    - `intent-inference` -> **검증되지 않은 가설**로 취급합니다. 모든 `intent-inference` augmentation은 brief에서 `intent-check:` prefix가 붙은 `Open Questions` row와 pair여야 합니다. codebase inspection으로 inference를 확인하거나 반박할 수 있는 경우가 아니라면, 해당 row를 이 run의 `## 5. Clarification Items` table에 `Kind=decision, Blocks=next-phase`(`implementation-planning`에서는 `Blocks=approval`)로 승격하고 권장 답변은 "보고자에게 직접 확인 후 응답"으로 설정합니다.
-  - `Open Questions` row prefix는 signal입니다. 승격할 때 제거하지 마세요.
-    - `intent-check:` -> `Kind=decision`, recommended answer = reporter confirmation. 이 layer에서 `intent-check:`를 추론으로 조용히 해결해서는 절대 안 됩니다.
-    - `terminology:` -> `Kind=decision`, recommended answer = `<PROJECT_ROOT>/.project-docs/okstra/glossary.md`의 canonical term(또는 "extend okstra glossary via brief Step 4.5").
-    - `conversion-block:` -> `Kind=decision`, recommended answer = "보고자에게 직접 확인". brief가 translation failed를 명시적으로 알리는 것입니다. reporter가 명확히 하기 전까지 추가 추론은 금지됩니다.
-    - `adr-candidate:` -> `implementation-planning`에서 처리합니다. 수정 없이 carry forward합니다. 승인된 decision file은 `<PROJECT_ROOT>/.project-docs/okstra/decisions/<NNNN>-<slug>.md`에만 저장합니다.
-    - `general:` -> free-form입니다. 표준 `Clarification Items` 규칙에 따라 분류합니다.
-  - 이 run의 어떤 decision이 brief의 `Source Material`과 모순되면 `Clarification Items` row를 통해 reporter에게 다시 올려야 합니다. 조용히 덮어쓰면 안 됩니다. reporter와의 불일치는 해당 row가 해결된 뒤에만 허용됩니다.
-  - 이 계약은 brief consumption에 대한 단일 권위입니다. phase-specific addendum은 이 규칙을 *강화*할 수 있지만 완화할 수 없습니다.
-- Clarification request policy (공통 - 프로필이 `## 5. Clarification Items`를 사용할 때마다 적용):
-  - **Canonical column schema (SSOT - `templates/reports/final-report.template.md` §5.1과 정확히 일치해야 함):** 모든 `## 5. Clarification Items` table은 정확히 다음 8개 column을 이 순서로 가집니다.
-    `| ID | Ticket ID | Kind | Statement | Expected form | Blocks | Status | User input |`.
-    프로필별 addendum은 cell content를 강화할 수 있지만 column을 추가, 제거, rename, reorder해서는 안 됩니다. `ID` cell은 `C-NNN`(3자리 zero-padded)을 사용하고, `Status` cell은 `{open, answered, resolved, obsolete}` 중 하나이며, `Kind` / `Blocks` legal value는 아래에 나열됩니다.
-  - section 5는 `final-report-template.md` 기준 **단일 unified table**입니다. 사용자가 파일을 첨부해야 하든, option을 골라야 하든, 단일 숫자/path를 제공해야 하든 모든 clarification item은 이 table의 한 row입니다. sub-section(`5.1 추가 자료 요청` / `5.2 사용자 확인 질문` / `4.5.9 Open Questions`)으로 쪼개지 말고, report 다른 곳에 parallel table을 만들지 말고, 같은 item을 top-of-report `User Approval Request (사용자 승인 게이트)` block이나 다른 section에 중복하지 마세요. 이를 다시 도입하면 validator가 실패합니다.
-  - 각 row의 `Kind` column은 `{material, decision, data-point}` 중 하나를 고릅니다. `material`은 사용자가 첨부해야 하는 파일/snapshot/log/screenshot입니다(`User input` cell에는 path 또는 URL이 들어갑니다). `decision`은 사용자만 할 수 있는 선택 및 yes/no confirmation입니다. `data-point`는 사용자가 inline으로 답할 수 있는 단일 숫자, ID, 날짜, 짧은 문자열입니다. "yes/no + yes이면 file path"가 섞인 item은 `Kind=material` 한 row로 표현하고 결합된 expectation을 `Expected form`에 씁니다.
-  - 각 row의 `Blocks` column은 `{approval, next-phase, none}` 중 하나를 고릅니다. `approval`은 approval action을 gate하는 item, 특히 `implementation-planning`의 User Approval Request용으로 예약됩니다. `implementation-planning` 밖에서는 unresolved brief reporter-confirmation row가 `next-phase`를 사용합니다. `next-phase`는 다음 run이 깨끗하게 시작되는 것을 막습니다. `none`은 정보/감사용입니다.
-  - 모든 entry는 비개발자가 추가 맥락 없이 실행할 수 있도록 완전하고 설명적인 문장으로 작성합니다. 약어와 내부 jargon을 피하세요. `Statement` cell은 *무엇*이 필요한지, 그 답변/첨부가 *왜* 다음 단계를 바꾸는지, (`material`의 경우) 사용자가 그것을 *어디에서 찾고 어디에 둘 수 있는지*를 말해야 합니다. `Expected form` cell은 답변 형태(예/아니오, 보기 중 하나, 숫자/날짜, 파일 경로, 짧은 서술 등)를 말해야 하며, 해당하면 구체적인 선택지를 제공합니다.
-  - phase가 recommended answer, alternative, evidence-check note를 요구하더라도 기존 8-column schema 안에 넣습니다. evidence note는 `Statement`에 `Evidence checked: <path:line>` 또는 `Evidence checked: none — <human-only reason>` 형태로 적고, recommendation/options는 `Expected form`에 `Recommended: <answer> — <rationale>; Alternatives: <options>` 형태로 적습니다. `Recommended`, `Evidence`, `Alternatives`, `evidence-checked` column을 추가하지 마세요.
-  - 같은 `final-report.md` 파일이 다음 run으로 carry되는 canonical artifact입니다. 사용자는 rerun 전에 답을 inline으로 append합니다. 권장 turnaround는 `scripts/okstra.sh --resume-clarification --task-key <project-id>:<task-group>:<task-id>`입니다(최신 report를 `$EDITOR`로 열고, 저장 후 `--clarification-response` carry-in으로 같은 phase를 자동 rerun). lower-level 형식인 `--clarification-response <path>`는 scripted run용으로 계속 사용할 수 있습니다.
-  - 이 run에 clarification response가 carry-in되었으면 조건부 `## 0. Clarification Response Carried In From Previous Run` section을 렌더링합니다(template의 `RENDER_IF` guard가 활성화됨). 이전 report의 `## 5. Clarification Items` table에 있는 모든 `C-*` row를 확인하고, 새 evidence와 대조해 각 row의 `Status`를 `resolved` 또는 `obsolete`로 갱신한 뒤 다음 decision/verdict를 발행합니다. carry-in path가 없으면 `## 0.` heading 전체를 생략합니다. 빈 Section 0 stub(예: "No prior clarification response was provided for this run.")을 emit하면 validator가 실패합니다.
-- Verdict Card (공통 - 모든 final-report에 적용):
-  - report 상단의 `## Verdict Card` block은 모든 final-report에서 필수입니다. `Verdict Token`, `Direction`, `Next Step` cell은 `## 2. Final Verdict`의 대응 cell 및 `## 6. Recommended Next Steps`의 첫 item과 byte-match해야 합니다. validator는 card를 비권위 index로 취급합니다. card 값이 권위 section과 다르면 run은 `contract-violated`입니다.
-- Cross-worker traceability (공통 - 모든 analysis worker output 및 lead의 final-report `## 1.` / `## 3.` table에 적용):
-  - **Worker-side item IDs (free-form but unique within the worker).** analysis worker 출력의 sections 1-5(및 선택 section 6)에 있는 모든 row item은 해당 worker result file 안에서 고유한 item ID를 가져야 합니다. ID convention은 worker가 선택합니다. 제안 schema에 따른 `F-001` / `F-002`, Codex가 자주 쓰는 `1.1` / `1.2` / `1.3`, 또는 다른 형태 모두 가능하지만, table-form item에서는 leading column으로, bullet/numbered item에서는 `[<ID>]` prefix로 나타나야 합니다. ID 없는 finding을 emit하는 worker는 cross-worker reconciliation을 불가능하게 만듭니다.
-  - **Lead-side ID assignment + source preservation.** lead(또는 `report-writer-worker`)가 worker output에서 `## 1.1 Consensus` / `## 1.2 Differences` / `## 3.1 Primary Evidence` row를 종합할 때 lead는 새 `C-NNN` / `D-NNN` / `E-NNN` row ID를 할당합니다. `Source items` column(또는 template이 아직 `Supporting workers` / `Workers (position)` / `Source`라 부르는 같은 column)은 기여한 모든 worker:item pair를 나열해야 합니다(예: `claude:F-001, codex:1.1, gemini:F-3`). 이렇게 하면 reviewer가 모든 worker-results file을 다시 읽지 않고도 종합 row를 각 worker 원문으로 추적할 수 있습니다. item ID 없는 bare worker name(예: `claude, codex, gemini`)은 이 table에서 deprecated입니다. validator는 아직 실패시키지 않지만 readability pass는 이를 contract violation으로 취급합니다.
-  - **Why this matters.** 실제 run에서 `claude=F-1..F-11`, `codex=1.1..1.8`, `gemini=F-3..F-9`처럼 세 가지 incompatible ID scheme이 있었습니다. lead가 `C-1..C-8`을 종합하면서 `C-3`이 "어느 worker file의 어느 문장"으로 돌아가는 링크가 사라졌습니다. Source-item preservation은 모든 worker에게 단일 ID prefix를 강제하지 않고도 그 링크를 복원합니다.
-- Audit sidecar (공통 - 모든 analysis-worker output 및 모든 final-report에 적용):
-  - Reading Confirmation line(입력 파일을 끝까지 읽었음을 확인하는 짧은 line)은 **worker audit sidecar**인 `runs/<task-type>/worker-results/<worker>-audit-<task-type>-<seq>.md`에 둡니다. worker의 main worker-results file에는 두지 않습니다. worker-results body는 section 1(Findings)에서 시작합니다. worker-results file에 `## 0. Reading Confirmation` heading이 있으면 validator가 실패합니다.
-  - audit sidecar에는 worker가 기록하고 싶은 다른 meta(tool-call count, MCP query summary, timing note 등)도 담습니다. lead의 final-report는 이 내용을 중복하지 않습니다. 이는 validator와 post-run audit tooling이 소비하는 것이며 end-user reader용이 아닙니다.
-
-- Markdown authoring (공통 - okstra template/schema가 이미 지배하지 않는 markdown 문서에 적용):
-  - ad-hoc markdown document는 `Index` section으로 시작하는 것을 권장합니다. final-report, worker-results, brief처럼 template이 지배하는 artifact는 자기 schema를 먼저 따릅니다.
-  - 사용자가 명시한 목적과 직접 관련된 요구사항을 충족하는 데 필요한 정보만 포함합니다.
-  - 사용자에게 지정받은 section, format, tone, scope와 필수 `Index` section만 따릅니다.
-  - task instruction 또는 work order를 작성할 때는 작업 범위를 명확하고 구체적으로 정의하고, 관련 deliverable, acceptance criteria, verification step을 포함합니다.
-  - 포함되는 작업을 말하는 방식으로 scope를 긍정적으로 정의합니다. 정의된 scope 밖의 작업은 수행하지 않습니다.
-  - 명시적으로 지정되지 않은 구조나 내용을 추가하기 전에는 필수 `Index` section을 제외하고 사용자 확인을 요청합니다.
-  - 완료 전에 문서가 요청된 scope와 정확히 일치하고 관련 없는 내용을 포함하지 않는지 검증합니다.

package/runtime/prompts/profiles/kr/error-analysis.md

@@ -1,36 +0,0 @@
-# Error Analysis Profile (오류 분석 프로필)
-
-- Purpose (목적): 보고된 error 또는 incident를 분석하고, 가능한 원인, 누락 evidence, validation path를 식별합니다.
-- Required workers:
-  - claude
-  - codex
-  - report-writer
-- Optional workers (opt-in via `--workers`):
-  - gemini - roster에 추가되면 analyser set에 참여합니다. 기본값은 omitted입니다.
-{{INCLUDE:_common-contract.md}}
-- Brief consumption (phase-specific addendum - 공유 규칙은 `_common-contract.md`의 "Brief handoff contract"에 있음):
-  - 공유 reporter-confirmation precondition을 그대로 적용합니다. 이 phase에서 unresolved `intent-check:` / `conversion-block:` row는 `Blocks=next-phase`를 사용합니다. confirmed되지 않은 inference는 label된 hypothesis로만 사용할 수 있습니다.
-  - `Source Material`에 있는 reporter의 symptom description이 재현할 대상에 대한 ground truth입니다. report에서 symptom을 말할 때 paraphrase하지 말고 인용합니다.
-  - symptom을 다시 성격 규정하는 `intent-inference` augmentation(예: "가끔 안 됨"을 "특정 code path의 intermittent failure"로 분류)은 confirmed symptom이 아니라 **hypothesis**입니다. matching `intent-check:` row에 `[CONFIRMED …]`가 있으면 confirmation을 symptom으로 취급합니다. 그렇지 않으면 위 precondition의 `skipped` branch를 따르고 root-cause analysis에서 inference를 hypothesis로 label합니다.
-  - `conversion-block:` row는 brief가 reporter statement를 project vocabulary로 mapping하지 못했다는 뜻입니다. 이 phase에서 누락된 mapping을 invent하지 마세요. 위 precondition이 이미 처리합니다.
-- Primary focus areas:
-  - symptom 및 trigger clarification
-  - root-cause candidate
-  - reproduction gap
-  - 기록된 expected value를 위반하는 config file 또는 deployment manifest
-  - prior analysis의 misleading assumption
-  - validation 및 rollback risk
-- Expected output emphasis:
-  - evidence-backed cause analysis
-  - uncertainty boundary
-  - practical next diagnostic step
-- Clarification request policy (phase-specific addenda - 공유 policy는 `_common-contract.md`에 있음):
-  - final report 작성 시점에 blocking uncertainty가 남아 있으면 `final-report-template.md`의 `## 5. Clarification Items`를 채웁니다(단일 unified table; 다음 run이 없이 시작할 수 없는 item은 `Blocks=next-phase`).
-  - 약어보다 쉬운 한국어를 선호합니다(예: "QPS" 대신 "초당 평균 요청 수", "repro" 대신 "재현 절차").
-  - 모든 clarification row는 `Expected form` cell 안에 recommended answer + 한 줄 rationale을 가져야 합니다. recommendation 없는 row는 half-formed로 rejected됩니다.
-  - **Codebase-first ambiguity resolution (defect rule)**: repro, file behavior, symbol semantics에 관한 ambiguity 중 `Read` / `Grep` / log inspection으로 답할 수 있는 것은 반드시 그렇게 해결하고 file:line(또는 log-line) evidence로 기록해야 합니다. codebase 또는 shipped log가 이미 답하는 내용을 clarification row로 쓰는 것은 이 phase의 defect입니다.
-  - **Evidence note는 `Statement` 안에 작성**: 모든 clarification row는 `Statement` cell에 `Evidence checked: <path:line>` 또는 `Evidence checked: none — <reporter-only reason>`을 포함합니다. `none`은 row 성격이 "reporter만 답할 수 있음"(reporter-side data, business priority, reporter가 관찰한 environment)일 때만 허용됩니다. code나 log로 답할 수 있었던 row가 `none`이면 defect입니다.
-- Non-goals:
-  - cause validation에 필요한 경우가 아니면 implementation detail을 다루지 않습니다.
-  - **source code edit, build, migration, deployment** - 이 run은 evidence와 cause analysis만 생산합니다. fix는 후속 `implementation-planning` run과 그 뒤의 `implementation` run에 속합니다.
-  - 이 run은 사용자 표현과 무관하게 `error-analysis`에 머뭅니다. 공유 anti-escalation rule이 적용됩니다.

package/runtime/prompts/profiles/kr/final-verification.md

@@ -1,48 +0,0 @@
-# Final Verification Profile (최종 검증 프로필)
-
-- Purpose (목적): final acceptance 전에 완료된 작업을 분석하고 남은 defect, omission, delivery risk를 식별합니다.
-- Required workers:
-  - claude
-  - codex
-  - report-writer
-- Optional workers (opt-in via `--workers`):
-  - gemini - roster에 추가되면 analyser set에 참여합니다. 기본값은 omitted입니다.
-{{INCLUDE:_common-contract.md}}
-- Primary focus areas:
-  - requirement coverage
-  - delivered config file 및 deployment manifest가 기록된 expected value를 만족하는지 여부
-  - unresolved edge case
-  - regression risk
-  - documentation 또는 rollout gap
-  - change가 production에서 여전히 실패할 수 있는 이유
-- Expected output emphasis:
-  - acceptance blocker
-  - residual risk
-  - final release recommendation
-- Pre-verification entry gate (필수 - 하나라도 실패하면 시작 거부):
-  - task brief는 `## Source Implementation Report` 아래 originating `implementation` final-report path를 반드시 cite해야 합니다. lead는 해당 file을 열고 `Plan link & approval evidence`, `Commit list`, `Diff summary`, `Validation evidence`, `Routing recommendation for final-verification`가 포함되어 있는지 확인합니다.
-  - task brief는 verification 대상 worktree / checkout과 implementation base ref를 식별해야 합니다. implementation report가 task worktree를 naming하면 final-verification은 caller의 original checkout이 아니라 같은 worktree를 inspect해야 합니다.
-  - lead는 worker dispatch 전에 verification worktree에서 `git rev-parse HEAD`, `git status --short`, `git diff --stat <implementation-base>..HEAD`를 capture해야 합니다. 이 값들은 verification target이며 final report에 cite되어야 합니다.
-  - cited implementation report가 없거나, delivered code change에 대한 commit이 없거나, current checkout이 implementation report의 commit list / diff summary와 match하지 않으면 run은 status `blocked`로 끝나고 ambiguous target을 검증하는 대신 `implementation` 또는 `implementation-planning`으로 route해야 합니다.
-- Required deliverable shape (표준 section에 더해 final report에 필요):
-  - **Source Implementation Report**: originating `implementation` final-report file의 relative path, verification target으로 사용한 quoted commit list / diff summary, inspect한 worktree path, run start에 capture한 base/head SHA.
-  - **Verdict vocabulary**: Section 2(`Final Verdict`)는 value가 정확히 `accepted`, `conditional-accept`, `blocked` 중 하나인 `Verdict Token` field를 포함해야 합니다. `conditional-accept`에는 explicit하고 exhaustive한 condition list가 필요합니다. ambiguous verdict("looks good", "mostly ready")는 허용되지 않습니다.
-  - **Acceptance Blockers block**(section 4 아래): blocker마다 `id`, `severity`(`critical` / `major` / `minor`), evidence(file path, log excerpt, test output), recommended follow-up phase(`error-analysis` 또는 `implementation-planning`)를 담은 row 하나. empty block은 허용되고 선호됩니다. 단일 line `- No acceptance blockers found.`를 렌더링합니다.
-  - **Residual Risk block**(section 4 아래): blocker는 아니지만 track해야 하는 risk. 각 risk에는 mitigation owner와 blocker로 escalation되는 trigger가 있어야 합니다.
-  - **Validation Evidence**: originating plan 또는 task brief의 모든 requirement에 대해 coverage를 증명하는 artifact(commit SHA, test output, log line, MCP SELECT result)를 cite합니다. artifact 없는 paraphrased "verified" claim은 rejected됩니다.
-  - **Read-only command log**: 이 run 중 실행한 pre-existing test/validation command는 exact command line과 exit code와 함께 나열해야 합니다. 여기에 mutating command가 나타나면 안 됩니다.
-  - **Two-tier command lookup (`implementation`과 공유):** 이 phase가 자체 independent re-validation을 수행할 때 command source는 `implementation` verifier가 사용하는 동일한 두 tier입니다. Tier 1은 originating task brief / approved plan의 `validation` set, Tier 2는 `<PROJECT_ROOT>/.project-docs/okstra/project.json` 아래 `qaCommands`입니다. manifest file에서 tool을 auto-detect하는 것은 금지됩니다. missing tier는 `qa-command not configured: <category>`로 기록하며 guess를 trigger하지 않습니다. `cmd` deny-list(`--fix`, `--write`, ` -w`, ` -u`, `--snapshot-update`, `INSTA_UPDATE=<not-no>`, `cargo update`, `npm install` without `ci` 등)는 동일하게 enforce됩니다. NOTE: runtime fail-fast validation(`okstra_ctl.qa_commands.validate_qa_commands`)은 `--task-type implementation` run-prep에서만 fire되므로, 이 phase는 각 `qaCommands` entry를 실행하기 전에 deny-list에 대해 self-check해야 합니다. denied token이 있으면 command를 skip하고 `Read-only command log` line `qa-command rejected (denied token: <token>): <label>`로 기록합니다.
-  - **Routing recommendation**: verdict와 blocker list에 연결된 다음 안전 phase(`done`, `error-analysis`, `implementation-planning`)에 대한 짧은 note.
-- Clarification request policy (phase-specific addendum - 공유 policy는 `_common-contract.md`에 있음):
-  - blocker가 사용자만 제공할 수 있는 정보(deployment intent, intended target environment, business-rule interpretation)에 달려 있을 때만 `## 5. Clarification Items`를 채웁니다. release-handoff로 계속 가는 것을 gate하는 item에는 `Blocks=next-phase`를 사용합니다.
-- Self-review pass before finalising the report (`Claude lead`가 실행. generic subagent에 위임하지 말 것):
-  1. **Verdict precision** - section 2는 세 allowed verdict token 중 하나를 가진 `Verdict Token`을 포함합니다. `conditional-accept`는 모든 condition을 actionable item으로 나열합니다.
-  2. **Blocker traceability** - 모든 blocker는 concrete artifact(file:line, log excerpt, test exit code, MCP SELECT)를 cite합니다. evidence 없는 blocker는 residual risk로 demote하거나 제거합니다.
-  3. **Coverage check** - originating plan/task brief의 모든 requirement는 artifact와 함께 covered로 표시되거나 blocker로 나열되어야 합니다. silent omission 금지.
-  4. **Verifier dissent preserved** - worker가 다른 verdict에 도달하면 disagreement가 section 1.2에 보이는가? synthesis가 아무것도 숨기지 않는가?
-  5. **No-mutation audit** - run session transcript에서 Edit / Write / mutating Bash command 발생 여부를 scan합니다. 발생했다면 run이 implementation으로 넘어간 것이므로 반드시 re-route해야 합니다. evidence를 조용히 제거하지 마세요.
-- Non-goals:
-  - delivered scope를 넘어서는 unrelated refactor 제안
-  - **source code edit, follow-up bug fix, scope expansion** - 이 run은 verdict만 렌더링합니다. 여기서 발견된 defect는 새 `error-analysis` 또는 `implementation-planning` run의 input이 됩니다.
-  - pre-existing test 또는 validation command의 read-only execution은 허용되지만 source, schema, deployment state를 mutate하는 command는 금지됩니다.
-  - 이 run은 발견된 issue를 기록하고 종료합니다. 공유 anti-escalation rule은 사용자 표현과 무관하게 in-run fix를 금지합니다.

package/runtime/prompts/profiles/kr/implementation-planning.md

@@ -1,90 +0,0 @@
-# Implementation Planning Profile (구현 계획 프로필)
-
-- Purpose (목적): coding이 시작되기 전에 requirement를 분석하고 안전한 implementation direction을 제안합니다.
-- Required workers:
-  - claude
-  - codex
-  - report-writer
-- Optional workers (opt-in via `--workers`):
-  - gemini - roster에 추가되면 analyser set에 참여합니다. 기본값은 omitted입니다.
-{{INCLUDE:_common-contract.md}}
-- Brief consumption (phase-specific addendum - 공유 규칙은 `_common-contract.md`의 "Brief handoff contract"에 있음):
-  - 공유 reporter-confirmation precondition을 그대로 적용합니다. 이 phase에서 unresolved `intent-check:` / `conversion-block:` row는 `Blocks=approval`을 사용합니다. 해당 row들이 resolved되기 전까지 operator는 `User Approval Request`를 toggle할 수 없습니다.
-  - unconfirmed `intent-inference` augmentation을 settled requirement처럼 두고 plan하지 마세요. precondition 실행 후 matching `intent-check:` row의 `[CONFIRMED …]` marker가 inference를 settled로 취급할 수 있다는 signal입니다. 그렇지 않으면 precondition의 `skipped` branch에 따라 `Blocks=approval` clarification item으로 남습니다.
-  - `conversion-block:` row는 precondition에서 처리됩니다. 번역되지 않은 reporter phrase를 바탕으로 planning하는 것은 해결 전까지 금지됩니다.
-- Pre-planning context exploration (option drafting 전에 필수):
-  - task brief, related-task brief, 인용된 spec / design doc을 끝까지 읽습니다.
-  - task가 이름 붙인 모든 file의 현재 상태를 검사합니다(이름이 stale이면 가장 가까운 matching file). 현재 responsibility, public interface, known coupling point를 기록합니다.
-  - 해당 file을 건드린 recent commit을 훑습니다(`git log -- <path>`). in-flight work 또는 contested area를 드러내기 위함입니다.
-  - **codebase-first ambiguity resolution**: `Read` / `Grep`으로 답할 수 있는 ambiguity는 반드시 그렇게 해결하고 file:line evidence로 기록해야 합니다. 진짜 human decision이 필요한 ambiguity만 `Clarification Items` row로 escalate합니다. code가 이미 답하는 내용을 clarification row로 쓰는 것은 이 phase의 defect입니다.
-  - ambiguous, contradictory, success criteria가 missing인 requirement를 flag합니다. 각 항목은 guess하지 말고 report의 `## 5. Clarification Items` table에 `Blocks=approval` row로 등록합니다.
-  - 존재하면 `<PROJECT_ROOT>/.project-docs/okstra/glossary.md` 및 `<PROJECT_ROOT>/.project-docs/okstra/decisions/` title을 읽습니다. okstra memory file이 없는 것은 정상입니다. error로 처리하지 마세요. `requirements-discovery`에서 나온 brief의 `terminology:*` resolution이 있으면 권위 있게 취급합니다. 없으면 남은 fuzzy term을 `Blocks=approval` clarification row로 해결합니다.
-- Primary focus areas:
-  - requirement gap
-  - affected component와 boundary
-  - expected target state에 도달하기 위해 변경해야 하는 config file 및 deployment manifest
-  - implementation option 및 trade-off
-  - hidden dependency 또는 migration risk
-  - validation 및 rollout approach
-- Design principles applied when scoring options:
-  - **Isolation & single responsibility**: 건드리는 각 unit은 명확한 목적 하나, well-defined interface, 독립 test 가능성을 가져야 합니다. unit responsibility를 넓히는 option은 감점합니다.
-  - **Files that change together live together**: technical layer가 아니라 responsibility 기준으로 나눕니다. 하나의 logical change를 무관한 layer들에 흩뿌리는 option은 감점합니다.
-  - **Follow established patterns**: 기존 codebase에서는 현재 convention을 따릅니다. 이미 수정하는 file의 targeted cleanup은 허용되지만 unrelated refactor는 아닙니다.
-  - **YAGNI ruthlessly**: 명시된 requirement에 기여하지 않는 feature, abstraction, configuration knob는 제거합니다.
-- Expected output emphasis:
-  - feasible plan option
-  - dependency 및 risk visibility
-  - recommended execution order
-- Approval gate (phase-specific addendum to shared authority rule):
-  - YAML frontmatter 의 `approved: true|false` field 가 유일한 authorized approval gate 입니다. report-writer 는 항상 `approved: false` 로 발행하고, 사용자는 (a) frontmatter 라인을 직접 `approved: true` 로 수정하거나, (b) 다음 phase 를 `--approve` 로 호출해 CLI 가 frontmatter 를 toggle 하게 하여 승인합니다. `okstra_ctl.run._validate_approved_plan` 이 이 field 를 읽어 `true` 가 아니면 implementation 진입을 거부합니다.
-- Non-goals:
-  - implementation approach를 바꾸는 경우가 아니면 code-level micro-optimization을 다루지 않습니다.
-  - **어떤 종류의 source code edit도 하지 않습니다** - 이 run은 plan document만 생산합니다. plan이 승인되고 별도 `implementation` run이 시작되기 전까지 project source file에 대한 Edit/Write는 금지됩니다.
-  - build, migration, deployment, 또는 run 자체 artifact directory(`reports/`, `prompts/`, `state/`, `manifests/`, `worker-results/`, `status/`, `sessions/`) 밖의 project state를 mutate하는 command 실행
-  - 이 run은 사용자 표현과 무관하게 `implementation-planning`에 머뭅니다. 공유 anti-escalation rule이 적용됩니다.
-  - required worker roster를 넘어서는 parallel sub-agent dispatch - worker fan-out은 okstra가 소유합니다.
-  - `<PROJECT_ROOT>/.project-docs/okstra/` 밖에 artifact 작성 - 이 phase에서는 run의 `reports/` directory가 canonical location입니다.
-- Clarification request policy (phase-specific addenda - 공유 policy는 `_common-contract.md`에 있음):
-  - 모든 clarification row는 `Expected form` cell 안에 recommended answer + 한 줄 rationale을 가져야 합니다. recommendation 없는 row는 half-formed로 rejected됩니다.
-  - **Evidence note는 `Statement` 안에 작성**: 모든 clarification row는 `Statement` cell에 `Evidence checked: <path:line>` 또는 `Evidence checked: none — <human-only reason>`을 포함합니다. `none`은 row 성격이 "사람만 답할 수 있음"(reporter intent, business priority, organisational decision)일 때만 허용됩니다. codebase로 답할 수 있었던 row가 `none`이면 이 phase의 defect이며, 위 pre-planning rule을 다시 진술한 것입니다.
-- Section heading contract (BLOCKING - validator가 이 literal English substring을 scan함):
-  - final report는 다음 정확한 문자열 각각을 포함하는 section heading을 반드시 가져야 합니다: `Option Candidates`, `Trade-off`, `Recommended Option`, `Stepwise Execution Order`, `Dependency`, `Validation Checklist`, `Rollback`. (Approval 은 더 이상 body section 이 아닙니다 — YAML frontmatter `approved` field 입니다.)
-  - 한국어 번역은 괄호 안에 허용됩니다(예: `### Recommended Option (권장 옵션)`). 하지만 heading line에는 English keyword가 그대로 있어야 합니다.
-  - shape와 ordering은 `final-report-template.md` section 4.5(`Implementation Plan Deliverables`)를 따릅니다. heading keyword를 번역하지 마세요. `validators/validate-run.py`는 raw report text에서 substring matching을 수행하며, 8개 중 7개 string이 누락되는 것은 실제로 반복 관찰된 failure mode입니다(root cause: writer가 heading을 한국어로 번역함).
-- Required deliverable shape (표준 section에 더해 final report에 필요):
-  - 최소 두 개의 implementation option. **각 option은 다음을 포함해야 합니다**:
-    - **File Structure**: create / modify / delete할 file의 명시적 목록과 각 file responsibility(한 줄씩). `Create: path - responsibility` / `Modify: path:line-range - change summary` / `Delete: path - reason` 형식을 사용합니다.
-    - affected interface / public contract 및 downstream consumer
-    - estimated blast radius(unit, config, deployment manifest, data migration)
-  - option 간 trade-off matrix(rows = options, columns 최소: complexity, risk, reversibility, test coverage cost, rollout cost)
-  - 위 design principle과 연결된 rationale을 포함한 recommended option
-  - **recommended option의 stepwise execution order**, bite-sized task로 작성:
-    - 각 step은 대략 2-5분에 완료 가능한 action 하나입니다(예: "write the failing test for X", "run it to confirm it fails", "implement minimal code", "run test to confirm pass", "commit").
-    - 모든 step은 정확한 file path와 정확한 command를 이름 붙입니다. code step의 경우 description이 아니라 actual code 또는 diff sketch를 포함합니다.
-    - touched area에 test가 있거나 만들 수 있으면 TDD ordering(failing test -> implementation -> green -> commit)을 선호합니다.
-  - dependency / migration risk assessment(ordering constraint, data backfill, feature-flag prerequisite, repo-internal sequencing)
-  - validation checklist(pre / mid / post) - 각 item은 정확한 command 또는 observable outcome입니다.
-  - rollback strategy - 정확한 revert path(commit, flag, migration)와 rollback을 trigger하는 signal
-  - YAML frontmatter 에 `approved: false` 라인을 반드시 포함합니다 (report-writer 는 항상 unflipped 값을 발행). 사용자가 `approved: true` 로 토글하면 다음 `implementation` run 이 진입 가능해집니다 (수동 편집 또는 `--approve` CLI). 어떤 `User Approval Request` body block 도 다시 만들지 마세요 — validator 가 이를 포함한 report 를 실패시킵니다 (`validators/validate-run.py` deprecated patterns 참고).
-  - **frontmatter `approved: false` 라인은 무조건 렌더링됩니다. plan-body verification gate(§4.5.9)가 `blocked-by-disagreement` 또는 `aborted-non-result` 를 반환하면 writer 는 `approved: false` 를 유지해야 하며, 이런 gate result 인 채로 `approved: true` 로 ship 된 report 는 validator 가 거부합니다.**
-  - pre-planning 중 flag된 ambiguity 중 user가 approval 전에 해결해야 하는 모든 것은 `## 5. Clarification Items` table의 `Blocks=approval` row로 등록합니다. `4.5.x` 아래 별도 `Open Questions` block을 만들지 마세요. unified table이 단일 home입니다.
-  - **§4.5.9 Plan Body Verification (BLOCKING).** report-writer가 draft를 끝낸 뒤, lead는 consolidated plan body(sections 4.5.1 - 4.5.7)에 대해 worker peer-review round를 실행하고 final report의 `### 4.5.9 Plan Body Verification`을 채워야 합니다. round protocol, plan-item ID scheme(`P-Opt-*` / `P-Step-*` / `P-Dep-*` / `P-Val-*` / `P-Rb-*`), verdict semantics, gate-result classification, dissent log format은 `skills/okstra-convergence/SKILL.md`의 "Plan-body verification mode"에 정의되어 있습니다. 네 gate-result 값은 `passed`, `passed-with-dissent`, `blocked-by-disagreement`, `aborted-non-result`입니다. gate가 `blocked-by-disagreement` 또는 `aborted-non-result`였을 때 lead가 run을 "unblock"하려고 passing value 중 하나로 조용히 뒤집어서는 안 됩니다. 이는 contract violation입니다.
-  - **Decision-record evaluation (sole owner)**: 이 phase는 okstra lifecycle에서 decision-record evaluation의 **단일 owner**입니다. brief는 decision record를 평가하거나 draft하지 않습니다. `adr-candidate:*` signal만 forward합니다. brief의 `Open Questions`에서 상속된 모든 `adr-candidate:*` entry는 mandatory evaluation target입니다. 추가로, recommended option이 도입하는 모든 decision을 세 criteria로 평가합니다.
-    1. **Hard to reverse** - 나중에 decision을 바꾸는 비용이 지금 결정하는 것보다 의미 있게 큰가?
-    2. **Surprising without context** - 미래 reader가 code만 보고 "왜 이렇게 만들었지?"라고 궁금해할까?
-    3. **Real trade-off** - 이름 붙은 alternative가 있었고, 구체적 이유로 하나를 선택했는가?
-    세 기준이 **모두** 성립하면 `Decision Drafts`라는 report appendix section으로 decision draft를 첨부합니다(결정 하나당 subsection 하나). 각 draft는 `## Context / ## Decision / ## Consequences / ## Alternatives Considered` shape를 사용하고, reject된 alternative와 이유를 이름 붙이며 `## Status: Proposed`로 시작합니다. 다음 decision number는 `(max existing in <PROJECT_ROOT>/.project-docs/okstra/decisions/ + 1)`을 4자리 zero-padded로 계산합니다. 세 기준 중 하나라도 없으면 decision draft를 올리지 마세요. 대신 `Decision Drafts` 아래에 `skipped adr-candidate: <topic> - reason: <criterion that failed>`를 한 줄로 기록해 다음 reader가 candidate를 평가했고 의도적으로 drop했음을 알 수 있게 합니다.
-    draft는 이 phase에서 쓰지 않습니다. approved plan의 stepwise execution order에는 `Create <PROJECT_ROOT>/.project-docs/okstra/decisions/<NNNN>-<slug>.md from the decision draft in section X` step이 포함되어야 하며, `implementation` run이 okstra subtree 안에서 해당 file을 commit합니다.
-  - **Glossary proposals**: term 또는 definition을 okstra institutional memory로 남겨야 하면 stepwise execution order에 `Update <PROJECT_ROOT>/.project-docs/okstra/glossary.md: <term> = <definition>` step을 추가합니다. 외부 domain doc edit를 계획하지 마세요.
-- No-placeholder rule (plan failures - 다음이 포함된 option 또는 step은 reject):
-  - "TBD", "TODO", "implement later", "fill in details", "add appropriate error handling", "handle edge cases", actual test code 없는 "write tests for the above"
-  - concrete content를 반복하지 않고 "similar to Option/Task N"이라고 참조하는 경우(reader는 section을 out of order로 소비할 수 있음)
-  - 다른 step이나 option이 정의하지 않은 type, function, flag, file에 대한 reference
-  - *무엇*을 할지 설명만 하고 *어떻게* 할지 보여주지 않는 step(code-touching step에는 command, code, exact diff가 필요)
-- Self-review pass before finalising the report (`Claude lead`가 실행. generic subagent에 위임하지 말 것):
-  1. **Spec coverage** - task brief의 모든 requirement에 대해 이를 만족하는 option 및 step을 가리킵니다. gap은 명시적으로 나열합니다.
-  2. **Placeholder scan** - 위 No-placeholder rule의 pattern을 report에서 검색하고 inline으로 고칩니다.
-  3. **Internal consistency** - option file list, trade-off matrix, recommended step list는 file path, name, signature에서 서로 일치해야 합니다. matrix에서는 `clearLayers()`이고 step에서는 `clearFullLayers()`인 symbol은 bug입니다.
-  4. **Ambiguity check** - requirement가 두 가지로 읽힐 수 있으면 명시적으로 만들거나 `## 5. Clarification Items` table의 `Blocks=approval` row로 옮깁니다.
-  5. **Scope check** - recommended plan이 이제 여러 독립 subsystem에 걸치면, oversized plan으로 shipping하지 말고 별도 planning run으로 나누도록 권장합니다.
-  6. **Plan-body verification reconciliation (implementation-planning의 BLOCKING).** `### 4.5.9 Plan Body Verification` verdict table을 검사합니다. `majority-disagree -> C-<N>`으로 분류된 모든 plan-item row에 대해 대응하는 `C-<N>` row가 `## 5. Clarification Items`에 존재해야 하며, `Kind`는 standard policy에 따라 선택하고 `Blocks=approval`이어야 합니다. parallel `### 4.5.x Open Questions` block을 만들지 마세요. unified table이 단일 home입니다. 반대로 `Classification` column의 `C-<N>` reference와 `## 5. Clarification Items`의 `ID` column은 1:1로 match해야 합니다. 어느 쪽이든 orphan이면 contract violation입니다. `partial-consensus`와 `worker-unique` plan-item의 dissenting opinion은 §4.5.9 `Dissent log`에 두며 §5로 승격하지 않습니다.