okstra 0.122.0 → 0.124.0

package/docs/task-process/implementation.md

@@ -2,24 +2,25 @@
 
 ## Index
 
-- [1. 목적](#1-목적)
-- [2. okstra-run wizard 흐름](#2-okstra-run-wizard-흐름)
+- [1. Purpose](#1-purpose)
+- [2. okstra-run wizard flow](#2-okstra-run-wizard-flow)
 - [3. runtime gate](#3-runtime-gate)
-- [4. executor와 verifier](#4-executor와-verifier)
-- [5. stage와 consumers](#5-stage와-consumers)
-- [6. 산출물](#6-산출물)
-- [7. 금지선](#7-금지선)
-- [8. 확인한 코드](#8-확인한-코드)
+  - [3.1 design-preparation preflight](#31-design-preparation-preflight)
+- [4. executor and verifier](#4-executor-and-verifier)
+- [5. stage and consumers](#5-stage-and-consumers)
+- [6. Deliverables](#6-deliverables)
+- [7. Forbidden actions](#7-forbidden-actions)
+- [8. Verified code](#8-verified-code)
 
-## 1. 목적
+## 1. Purpose
 
-`implementation`은 승인된 `implementation-planning` final report를 실제 code change와 local commit으로 실행한다. 이 phase에서만 source edit가 허용되지만, scope는 approved plan과 recorded out-of-plan justification으로 제한된다.
+`implementation` executes an approved `implementation-planning` final report into actual code changes and local commits. Source edit is allowed only in this phase, but scope is limited to the approved plan and recorded out-of-plan justification.
 
-## 2. okstra-run wizard 흐름
+## 2. okstra-run wizard flow
 
 ```mermaid
 flowchart TD
-    Start[/okstra-run/] --> Common[공통 task identity flow]
+    Start[/okstra-run/] --> Common[common task identity flow]
     Common --> Type[task-type = implementation]
     Type --> Worktree{active task worktree?}
     Worktree -->|yes| PlanPick[approved plan pick/text]
@@ -38,9 +39,9 @@ flowchart TD
     Confirm --> Render[render-bundle]
 ```
 
-`implementation`은 worker override 질문이 없다. wizard `render_args()`가 `workers`를 빈 문자열로 내보내고, runtime이 profile default roster를 사용한다. `stage_pick`은 완료/진행중/준비됨/대기 상태를 보여주는 multi-pick이다. 선택한 stage 집합은 의존성 closure와 위상정렬을 거쳐 `chain-stages` CSV가 되고, 각 실제 run은 그중 한 stage만 실행한다.
+`implementation` has no worker override question. The wizard `render_args()` emits `workers` as an empty string, and the runtime uses the profile default roster. `stage_pick` is a multi-pick that shows done/in-progress/ready/waiting status. The selected stage set goes through dependency closure and topological sort into a `chain-stages` CSV, and each actual run executes only one of those stages.
 
-현재 okstra-run wizard 경로는 승인 checkbox를 직접 flip하는 `--approve`를 노출하지 않는다. plan file에는 이미 recognized approval marker가 있어야 한다.
+The current okstra-run wizard path does not expose `--approve` that directly flips the approval checkbox. The plan file must already have a recognized approval marker.
 
 ## 3. runtime gate
 
@@ -61,6 +62,7 @@ sequenceDiagram
     P->>Stage: build Stage Lifecycle Snapshot
     P->>Reg: read active stage-key reservations
     P->>Stage: select exactly one ready stage
+    P->>Plan: resolve selected stage design preparation
     P->>WT: provision stage-N worktree + branch
     P->>QA: validate qaCommands deny-list
     P->>P: executor provider in resolved roster?
@@ -68,9 +70,23 @@ sequenceDiagram
     P-->>W: prepared implementation prompt or PrepareError
 ```
 
-`--approve`는 Python runtime에 존재하지만 okstra-run wizard가 args로 내보내지 않는다. shell path에서는 `--approve`가 unchecked approval line을 flip하고 audit line을 붙인 뒤 같은 validation path를 탄다.
+`--approve` exists in the Python runtime, but the okstra-run wizard does not emit it as args. On the shell path, `--approve` flips the unchecked approval line, appends an audit line, and then follows the same validation path.
 
-## 4. executor와 verifier
+### 3.1 design-preparation preflight
+
+Right after stage selection, before worktree provisioning and appending `status:"started"` to `consumers.jsonl`, it resolves the design preparation of the approved plan. The resolver reads only items whose `stageRefs` includes the selected stage, so an undecided decision in another stage does not block the current run.
+
+| outcome | runtime behavior |
+|---|---|
+| `proceed` | Inject the effective AI proposal, confirmed override, guardrail, and provisional working assumption into the executor prompt as `DESIGN_PREP_CONTEXT`, and create the worktree. |
+| `wait_for_input` | Stop with `stage <N> waits for design input: ...; <request paths>`. Do not create the worktree or the started consumer row. |
+| `replan` | Stop with `stage <N> requires implementation-planning rerun: ...`. Let a newly approved/edited decision change the planning snapshot or the Stage Map. |
+
+`ready`, `not-applicable`, and `no-design-inputs` proceed. `provisional` can proceed even without a response because there is a safe working assumption, and a non-triggering approval/edit states that assumption and override in the prompt. A `blocked` non-response makes only that stage wait, and when a blocked draft is approved/edited, it replans so that authorization is reflected into the approved plan. A markerless legacy plan proceeds with a `legacy-unassessed` warning without modifying the report.
+
+`manual-user-test` input uses the same flexible status. The planning draft is a seed for implementation to concretize the verification method against the actual diff, and the SSOT of the final execution method is the implementation report's `implementation.manualUserTest`. final-verification does not directly execute the planning sidecar.
+
+## 4. executor and verifier
 
 ```mermaid
 flowchart TD
@@ -87,9 +103,9 @@ flowchart TD
     Verdict --> Report[Final report preserves dissent]
 ```
 
-Executor만 project file을 mutate할 수 있다. verifier는 같은 worktree에서 read-only로 diff와 validation command를 독립 재실행한다. executor와 같은 provider도 verifier로 별도 fresh CLI session에서 다시 실행된다. 같은 session이 쓴 diff를 같은 session이 승인하는 구조를 막기 위함이다.
+Only the executor may mutate project files. The verifier independently re-runs the diff and validation command read-only in the same worktree. Even a verifier with the same provider as the executor runs again in a separate fresh CLI session. This is to prevent a structure where the same session approves a diff the same session wrote.
 
-## 5. stage와 consumers
+## 5. stage and consumers
 
 ```mermaid
 flowchart LR
@@ -98,18 +114,20 @@ flowchart LR
     Snapshot --> Resolve{stage arg}
     Resolve -->|auto| Next[lowest ready<br/>not done/started/reserved]
     Resolve -->|number| Forced[selected stage]
-    Next --> Base[resolve stage base commit]
-    Forced --> Base
+    Next --> Prep{selected-stage<br/>design preflight}
+    Forced --> Prep
+    Prep -->|proceed| Base[resolve stage base commit]
+    Prep -->|wait / replan| Stop[stop before worktree<br/>and started consumer]
     Base --> WT[create/reuse stage worktree]
     WT --> Started[append consumer status=started]
     Started --> Run[implementation executes one selected stage]
 ```
 
-stage 선택은 `auto` 또는 숫자다. 다른 task-type에서 `--stage`가 오면 `PrepareError`다. runtime은 Stage Lifecycle Snapshot에서 `consumers.jsonl`의 `done`/`started`, carry sidecar backfill, registry의 active stage-key를 함께 읽고 점유 stage를 제외한다. Snapshot은 새 저장 파일이 아니라 `stage_targets.py`의 read-side view다.
+Stage selection is `auto` or a number. If `--stage` comes from another task-type, it is a `PrepareError`. The runtime reads `done`/`started` of `consumers.jsonl`, carry sidecar backfill, and the active stage-key of the registry together in the Stage Lifecycle Snapshot, and excludes occupied stages. The Snapshot is not a new stored file but a read-side view of `stage_targets.py`.
 
-stage worktree base는 dependency 형태로 정한다. 독립 stage는 첫 implementation 진입 때 고정한 task-key worktree HEAD를 anchor로 삼고, 단일 의존 stage는 선행 stage의 done `head_commit`에서 분기한다. 다중 의존 stage는 모든 선행 done commit이 task-key worktree HEAD의 ancestor인지 확인한 뒤 그 HEAD에서 분기한다.
+The stage worktree base is decided by dependency shape. An independent stage uses the task-key worktree HEAD fixed at first implementation entry as its anchor, and a single-dependency stage branches from the predecessor stage's done `head_commit`. A multi-dependency stage branches from the task-key worktree HEAD after confirming that every predecessor done commit is an ancestor of that HEAD.
 
-## 6. 산출물
+## 6. Deliverables
 
 ```mermaid
 flowchart TD
@@ -122,21 +140,22 @@ flowchart TD
     Report --> Next[Routing recommendation<br/>final-verification or loop back]
 ```
 
-final report에는 최소 다음이 필요하다.
+The final report requires at least the following.
 
-- approved plan path와 quoted approval marker
-- selected stage, isolated stage worktree path, run artifact path(`runs/implementation/stage-<N>/`)
+- approved plan path and quoted approval marker
+- selected stage, isolated stage worktree path, run artifact path (`runs/implementation/stage-<N>/`)
 - commit SHA, message, plan step mapping
-- diff summary와 per-file summary
+- diff summary and per-file summary
 - out-of-plan edits block
-- plan validation command의 실제 stdout/stderr와 exit code
+- actual stdout/stderr and exit code of the plan validation command
 - TDD failing-then-passing evidence
-- verifier별 independent validation rerun result
-- `carry/stage-<N>.json` evidence sidecar와 `consumers.jsonl` started/done row
+- per-verifier independent validation rerun result
+- `carry/stage-<N>.json` evidence sidecar and `consumers.jsonl` started/done row
 - rollback verification
+- `implementation.manualUserTest` finalized against the actual diff and whether it is executable
 - follow-up tasks table
 
-## 7. 금지선
+## 7. Forbidden actions
 
 ```mermaid
 flowchart TD
@@ -149,9 +168,9 @@ flowchart TD
     Impl -. forbidden .-> Acceptance[declaring final acceptance]
 ```
 
-이 phase는 final acceptance를 선언하지 않는다. ready for final-verification 또는 needs new loop만 말한다.
+This phase does not declare final acceptance. It says only ready for final-verification or needs new loop.
 
-## 8. 확인한 코드
+## 8. Verified code
 
 - [`prompts/profiles/implementation.md`](../../prompts/profiles/implementation.md)
 - [`templates/reports/implementation-input.template.md`](../../templates/reports/implementation-input.template.md)

package/docs/task-process/release-handoff.md

@@ -2,27 +2,27 @@
 
 ## Index
 
-- [1. 목적](#1-목적)
-- [2. okstra-run wizard 흐름](#2-okstra-run-wizard-흐름)
-- [3. prepare 단계](#3-prepare-단계)
+- [1. Purpose](#1-purpose)
+- [2. okstra-run wizard flow](#2-okstra-run-wizard-flow)
+- [3. prepare stage](#3-prepare-stage)
 - [4. entry gate](#4-entry-gate)
-- [5. lead-only 실행 흐름](#5-lead-only-실행-흐름)
-- [6. PR template 결정](#6-pr-template-결정)
-- [7. 산출물](#7-산출물)
-- [8. 금지선](#8-금지선)
-- [9. 확인한 코드](#9-확인한-코드)
+- [5. lead-only execution flow](#5-lead-only-execution-flow)
+- [6. PR template resolution](#6-pr-template-resolution)
+- [7. Deliverables](#7-deliverables)
+- [8. Forbidden actions](#8-forbidden-actions)
+- [9. Verified code](#9-verified-code)
 
-## 1. 목적
+## 1. Purpose
 
-`release-handoff`는 `accepted` verdict가 나온 already-committed implementation 결과를 push하거나 PR로 넘기는 terminal phase다. whole-task mode는 검증된 task branch를 그대로 포장한다. stage-group mode는 선택 stage들을 collector branch에 assemble해 한 PR로 묶을 수 있으며, 이때 생성되는 merge commit은 `okstra handoff assemble`만 만든다.
+`release-handoff` is the terminal phase that pushes an already-committed implementation result with an `accepted` verdict, or hands it off as a PR. whole-task mode packages the verified task branch as-is. stage-group mode can assemble the selected stages into a collector branch and bundle them into a single PR, and the merge commit created here is produced only by `okstra handoff assemble`.
 
-이 phase는 worker dispatch가 없다. `claude`, `codex`, `report-writer` roster를 쓰지 않으며 Claude lead가 inline으로 git/gh inspection, 사용자 질문, PR draft, final report 작성을 모두 수행한다.
+This phase has no worker dispatch. It does not use the `claude`, `codex`, or `report-writer` roster; the Claude lead performs git/gh inspection, user questions, the PR draft, and the final report all inline.
 
-## 2. okstra-run wizard 흐름
+## 2. okstra-run wizard flow
 
 ```mermaid
 flowchart TD
-    Start[/okstra-run/] --> Common[공통 task identity flow]
+    Start[/okstra-run/] --> Common[common task identity flow]
     Common --> Type[task-type = release-handoff]
     Type --> Plan[approved plan auto/pick]
     Plan --> Scope[handoff stage pick<br/>whole-task or eligible stages]
@@ -39,11 +39,11 @@ flowchart TD
     Confirm --> Render[render-bundle]
 ```
 
-`release-handoff`는 worker roster prompt가 없다. wizard outcome의 `renderArgs`는 `pr-template-path`를 release-handoff일 때만 포함하고, runtime은 worker list를 강제로 empty로 만든다. scope 선택은 prepare 전에 끝나며, project/global 저장은 `outcome.persistActions[]`의 `config.set pr-template-path` action으로 `render-bundle` 전에 실행된다. whole-task는 accepted whole-task verification report가 있어야 하고, stage-group은 Stage Lifecycle Snapshot에서 accepted single-stage verification으로 `verified` 처리됐지만 아직 `pr`로 덮이지 않은 stage만 후보가 된다.
+`release-handoff` has no worker roster prompt. The wizard outcome's `renderArgs` includes `pr-template-path` only for release-handoff, and the runtime forces the worker list to empty. Scope selection finishes before prepare, and the project/global save runs before `render-bundle` via the `config.set pr-template-path` action of `outcome.persistActions[]`. whole-task requires an accepted whole-task verification report, and for stage-group only the stages that were marked `verified` by an accepted single-stage verification in the Stage Lifecycle Snapshot but not yet covered by a `pr` become candidates.
 
-주의할 점은 이 phase도 task worktree provisioning 대상이라는 것이다. 정상 흐름은 같은 task-key의 implementation/final-verification 결과를 재사용한다. 새 task로 시작하면 새 branch가 만들어질 수 있고, entry gate의 "implementation commit exists" 조건에서 막힐 가능성이 높다.
+Note that this phase is also a target of task worktree provisioning. The normal flow reuses the implementation/final-verification result of the same task-key. Starting a new task may create a new branch, and it is likely to be blocked at the entry gate's "implementation commit exists" condition.
 
-## 3. prepare 단계
+## 3. prepare stage
 
 ```mermaid
 sequenceDiagram
@@ -64,7 +64,7 @@ sequenceDiagram
     P-->>W: lead prompt for current session
 ```
 
-profile에 `Required workers:` block이 없고 `run.py`도 `release-handoff`에서는 worker override를 비운다. 따라서 `prompts/lead/okstra-lead-contract.md`의 일반 TeamCreate / convergence / report-writer 흐름을 타지 않는 것이 의도된 동작이다.
+The profile has no `Required workers:` block, and `run.py` also empties the worker override for `release-handoff`. So not going through the general TeamCreate / convergence / report-writer flow of `prompts/lead/okstra-lead-contract.md` is the intended behavior.
 
 ## 4. entry gate
 
@@ -86,18 +86,18 @@ flowchart TD
     Commits -->|yes| Ready[handoff questions may begin]
 ```
 
-lead는 사용자에게 push/PR 여부를 묻기 전에 다음을 확인한다.
+Before asking the user whether to push/PR, the lead confirms the following.
 
-- prepare 가 생성한 input 문서(`release-handoff-input.md`)의 `## Source Verification Report` 가 모드(`HANDOFF_MODE`)와 인용 보고서 표를 담고 있다. brief 는 entry phase 의 입력물이라 release-handoff 에는 없다 — 사용자의 stage 선택은 wizard `handoff_stage_pick` 또는 CLI `--stages` 로 prepare 전에 끝난다.
-- whole-task mode에서는 인용 report가 `verificationScope=whole-task`이고 `Verdict Token = accepted`여야 한다.
-- stage-group mode에서는 인용된 각 single-stage report가 `Verdict Token = accepted`여야 하며, prepare/`okstra handoff assemble`이 Stage Lifecycle Snapshot 기반 eligibility와 dependency closure를 다시 강제한다.
-- working tree가 clean이다.
-- 현재 branch가 `main`, `master`, `prod`, `preprod`, `staging`, `dev` 같은 base branch가 아니다.
-- `<base>..HEAD` commit range가 비어 있지 않다.
+- The `## Source Verification Report` of the input document (`release-handoff-input.md`) generated by prepare contains the mode (`HANDOFF_MODE`) and the cited report table. The brief is the input of the entry phase, so it does not exist in release-handoff — the user's stage selection finishes before prepare via the wizard `handoff_stage_pick` or the CLI `--stages`.
+- In whole-task mode, the cited report must be `verificationScope=whole-task` and `Verdict Token = accepted`.
+- In stage-group mode, each cited single-stage report must be `Verdict Token = accepted`, and prepare / `okstra handoff assemble` re-enforce the Stage Lifecycle Snapshot-based eligibility and dependency closure.
+- The working tree is clean.
+- The current branch is not a base branch such as `main`, `master`, `prod`, `preprod`, `staging`, or `dev`.
+- The `<base>..HEAD` commit range is non-empty.
 
-`conditional-accept`, `blocked`, 애매한 문장 verdict는 모두 즉시 종료 대상이다.
+`conditional-accept`, `blocked`, and vague-sentence verdicts are all immediate-termination targets.
 
-## 5. lead-only 실행 흐름
+## 5. lead-only execution flow
 
 ```mermaid
 stateDiagram-v2
@@ -126,15 +126,15 @@ stateDiagram-v2
     FinalReport --> [*]
 ```
 
-사용자 interaction은 정확히 세 단계다.
+User interaction is exactly three steps.
 
 1. Q1 action: `local checkout`, `push + PR`, `skip`
-2. Q2 PR base: `staging`, `preprod`, `main`, 직접 입력 등 profile menu의 branch
+2. Q2 PR base: a branch from the profile menu such as `staging`, `preprod`, `main`, or Enter directly
 3. Q3 PR title/body: `use as-is`, `edit then proceed`, `cancel`
 
-`push + PR`에서만 merge-conflict probe를 한다.
+The merge-conflict probe happens only for `push + PR`.
 
-stage-group mode에서는 `local checkout`을 제공하지 않는다. `push + PR`을 고른 뒤 PR base를 먼저 선택하고, 이미 고정된 `HANDOFF_STAGES`를 확인한 다음 `okstra handoff assemble`이 collector branch를 만든다. 이후 conflict probe와 PR title/body 확인은 collector branch를 head로 삼는다.
+In stage-group mode, `local checkout` is not offered. After choosing `push + PR`, first select the PR base, confirm the already-fixed `HANDOFF_STAGES`, and then `okstra handoff assemble` creates the collector branch. After that, the conflict probe and PR title/body confirmation take the collector branch as head.
 
 ```mermaid
 flowchart TD
@@ -148,9 +148,9 @@ flowchart TD
     Ask -->|cancel| Report[final report without push/PR]
 ```
 
-probe는 working tree를 바꾸지 않아야 한다. `git merge`, `git rebase`, `git pull`은 이 probe에 포함되지 않는다.
+The probe must not change the working tree. `git merge`, `git rebase`, and `git pull` are not part of this probe.
 
-## 6. PR template 결정
+## 6. PR template resolution
 
 ```mermaid
 flowchart TD
@@ -163,9 +163,9 @@ flowchart TD
     Global -->|missing| Default[okstra skill default template]
 ```
 
-customize path에서 사용자가 template을 고르면 okstra-run skill이 render-bundle 전에 project/global scope 저장을 수행한다. runtime은 resolved `PR_TEMPLATE_PATH`와 `PR_TEMPLATE_SOURCE`를 run context에 넣고, lead는 이 파일을 그대로 읽어 HTML comment를 제거한 뒤 placeholder를 채운다. section 구조를 hard-code하면 안 된다.
+When the user picks a template on the customize path, the okstra-run skill performs the project/global scope save before render-bundle. The runtime puts the resolved `PR_TEMPLATE_PATH` and `PR_TEMPLATE_SOURCE` into the run context, and the lead reads this file as-is, removes the HTML comments, and fills the placeholders. The section structure must not be hard-coded.
 
-## 7. 산출물
+## 7. Deliverables
 
 ```mermaid
 flowchart TD
@@ -179,20 +179,20 @@ flowchart TD
     Report --> Done[routing recommendation: done]
 ```
 
-final report에는 최소 다음이 필요하다.
+The final report requires at least the following.
 
-- originating final-verification report path와 quoted `accepted` verdict row
-- handoff mode(`whole-task` 또는 `stage-group`)와 selected stages
-- feature branch와 run start `git status --short`
-- 사용자 선택 기록
-- 실행한 모든 git/gh command와 exit code
+- originating final-verification report path and quoted `accepted` verdict row
+- handoff mode (`whole-task` or `stage-group`) and selected stages
+- feature branch and run start `git status --short`
+- record of user selections
+- all executed git/gh commands and exit codes
 - implementation commit list
-- merge-conflict probe 결과
-- stage-group이면 collector branch, merge commit SHA, dependency-closure 결과
-- PR 생성, 재사용, 생략 결과
+- merge-conflict probe result
+- for stage-group, the collector branch, merge commit SHA, and dependency-closure result
+- PR created, reused, or skipped result
 - routing recommendation `done`
 
-## 8. 금지선
+## 8. Forbidden actions
 
 ```mermaid
 flowchart TD
@@ -207,9 +207,9 @@ flowchart TD
     RH -. forbidden .-> Merge[gh pr merge]
 ```
 
-실패한 `git push`를 더 약한 안전장치로 재시도하면 안 된다. non-fast-forward 같은 실패가 나면 멈추고 사용자 지시를 받아야 하며, `--force` 계열 flag는 사용자 요청이 있어도 금지다.
+A failed `git push` must not be retried with weaker safeguards. When a failure such as non-fast-forward occurs, stop and take the user's instruction, and `--force`-family flags are forbidden even if the user requests them.
 
-## 9. 확인한 코드
+## 9. Verified code
 
 - [`prompts/profiles/release-handoff.md`](../../prompts/profiles/release-handoff.md)
 - [`templates/reports/release-handoff-input.template.md`](../../templates/reports/release-handoff-input.template.md)

package/docs/task-process/requirements-discovery.md

@@ -2,18 +2,18 @@
 
 ## Index
 
-- [1. 목적](#1-목적)
-- [2. okstra-run wizard 흐름](#2-okstra-run-wizard-흐름)
-- [3. prepare_task_bundle 처리](#3-prepare_task_bundle-처리)
-- [4. lead 실행 흐름](#4-lead-실행-흐름)
-- [5. 산출물과 routing](#5-산출물과-routing)
-- [6. 확인한 코드](#6-확인한-코드)
+- [1. Purpose](#1-purpose)
+- [2. okstra-run wizard flow](#2-okstra-run-wizard-flow)
+- [3. prepare_task_bundle handling](#3-prepare_task_bundle-handling)
+- [4. lead execution flow](#4-lead-execution-flow)
+- [5. Deliverables and routing](#5-deliverables-and-routing)
+- [6. Code reviewed](#6-code-reviewed)
 
-## 1. 목적
+## 1. Purpose
 
-`requirements-discovery`는 구현 전에 요청을 분류한다. bugfix, feature, improvement, refactor, ops 중 무엇인지 판단하고, 다음 안전 phase가 `error-analysis`인지 `implementation-planning`인지 고른다. 직접 `implementation`으로 넘기는 것은 profile상 유효하지 않다. implementation은 승인된 `implementation-planning` report가 있어야 시작할 수 있다.
+`requirements-discovery` classifies the request before implementation. It determines which of bugfix, feature, improvement, refactor, or ops it is, and chooses whether the next safe phase is `error-analysis` or `implementation-planning`. Going directly to `implementation` is not valid per the profile. Implementation can only start once an approved `implementation-planning` report exists.
 
-## 2. okstra-run wizard 흐름
+## 2. okstra-run wizard flow
 
 ```mermaid
 flowchart TD
@@ -42,9 +42,9 @@ flowchart TD
     Confirm --> Render[render-bundle]
 ```
 
-worker multi-pick에서 picker는 `report-writer`를 옵션으로 보여주지 않는다. 사용자가 `claude`만 골라도 wizard가 `report-writer`를 강제 append한다. optional `antigravity`는 사용자가 골랐을 때만 포함된다.
+In the worker multi-pick, the picker does not show `report-writer` as an option. Even if the user selects only `claude`, the wizard force-appends `report-writer`. The optional `antigravity` is included only when the user selects it.
 
-## 3. prepare_task_bundle 처리
+## 3. prepare_task_bundle handling
 
 ```mermaid
 sequenceDiagram
@@ -65,9 +65,9 @@ sequenceDiagram
     P-->>W: prepared lead prompt
 ```
 
-runtime에서 이 phase만을 위한 추가 hard gate는 없다. 중요한 gate는 profile file 존재, brief file 존재, base-ref가 first phase에서 resolvable해야 한다는 worktree gate, worker override가 profile roster 범위를 벗어나지 않아야 한다는 gate다.
+There is no additional hard gate in the runtime for this phase alone. The important gates are: the profile file exists, the brief file exists, the worktree gate requiring base-ref to be resolvable at the first phase, and the gate requiring worker overrides to stay within the profile roster range.
 
-## 4. lead 실행 흐름
+## 4. lead execution flow
 
 ```mermaid
 flowchart TD
@@ -79,9 +79,9 @@ flowchart TD
     R --> P7[Phase 7 token usage, validate, persist]
 ```
 
-`requirements-discovery`는 convergence default가 1 round다. 이 예외는 `render._build_convergence_block()`와 `prompts/lead/okstra-lead-contract.md` 모두에서 명시된다.
+`requirements-discovery` has a convergence default of 1 round. This exception is stated in both `render._build_convergence_block()` and `prompts/lead/okstra-lead-contract.md`.
 
-## 5. 산출물과 routing
+## 5. Deliverables and routing
 
 ```mermaid
 flowchart LR
@@ -94,17 +94,17 @@ flowchart LR
     Route -. invalid .-> Impl[implementation<br/>not allowed directly]
 ```
 
-final report는 다음을 특히 강조한다.
+The final report emphasizes the following in particular.
 
 - evidence-backed routing decision
-- missing input과 uncertainty boundary
-- 다음 phase 및 safe resume guidance
-- `terminology:*` brief item에 대한 canonical term resolution
-- blocking input이 있으면 `## 1. Clarification Items` unified table에 `Blocks=next-phase`
+- missing input and uncertainty boundary
+- the next phase and safe resume guidance
+- canonical term resolution for `terminology:*` brief items
+- if there is blocking input, `Blocks=next-phase` in the `## 1. Clarification Items` unified table
 
-Non-goal은 source edit, plan authoring, build, deployment다.
+Non-goals are source edit, plan authoring, build, and deployment.
 
-## 6. 확인한 코드
+## 6. Code reviewed
 
 - [`skills/okstra-run/SKILL.md`](../../skills/okstra-run/SKILL.md)
 - [`scripts/okstra_ctl/wizard.py`](../../scripts/okstra_ctl/wizard.py)
@@ -112,4 +112,3 @@ Non-goal은 source edit, plan authoring, build, deployment다.
 - [`scripts/okstra_ctl/workflow.py`](../../scripts/okstra_ctl/workflow.py)
 - [`prompts/profiles/requirements-discovery.md`](../../prompts/profiles/requirements-discovery.md)
 - [`prompts/lead/okstra-lead-contract.md`](../../prompts/lead/okstra-lead-contract.md)
-

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "okstra",
-  "version": "0.122.0",
+  "version": "0.124.0",
   "description": "Multi-agent cross-verification orchestrator runtime + Claude Code skills.",
   "license": "MIT",
   "author": "devonshin",

package/runtime/BUILD.json

@@ -1,5 +1,5 @@
 {
-  "package": "0.122.0",
-  "builtAt": "2026-07-16T04:13:37.510Z",
+  "package": "0.124.0",
+  "builtAt": "2026-07-19T03:50:18.974Z",
   "repoRoot": "/home/runner/work/okstra/okstra"
 }

package/runtime/agents/workers/antigravity-worker.md

@@ -106,7 +106,7 @@ The wrapper exists because Claude Code's Bash permission matcher rejects simple-
       2. Record a `cli-failure` event directly to the run-level error log via the exact `okstra error-log append-observed` template in §"Error reporting" — substitute `--exit-code 0`, `--duration-ms <observed-ms>`, `--message "okstra-antigravity-exec.sh exited 0 but no result file at <abs-path>"`, and `--stderr-excerpt-file <temp-tail-path>`.
       3. Return `ANTIGRAVITY_RESULT_MISSING: agy exited 0 but result file absent at <abs-path>` instead of the raw stdout. The lead is responsible for deciding redispatch per `team-contract` "Lead Redispatch Policy on Result-Missing".
 
-   d. **Normal return.** Otherwise (`exit_code == 0` AND result file exists), return the wrapper's accumulated stdout from `BashOutput`, prefixed by exactly one model-identity line copied verbatim from the `**Model:** Antigravity worker, <execution-value>` line in the lead prompt (per Worker Preamble → "Return message to the lead"):
+   d. **Normal return.** Otherwise (`exit_code == 0` AND result file exists), return the wrapper's accumulated stdout from `BashOutput`, prefixed by exactly one model-identity line per the preamble §"Return message to the lead":
       ```
       **Model:** Antigravity worker, <assigned-model-execution-value>
       ```
@@ -151,11 +151,11 @@ Before invoking the Antigravity CLI, you MUST:
 1. Extract the absolute path from the lead's `**Worker Preamble Path:**` anchor header and verify the CLI run will Read that file end-to-end (canonical SSOT for the Required Reading + Error Reporting + Output sections contract). The lead's prompt body — which you persist verbatim and feed into Antigravity via stdin — already contains this anchor; do not strip it.
 2. Verify the lead's prompt body lists the per-run primary input files under `## Inputs` (normally `analysis-packet.md` for analysis workers). The source files named inside that packet are fallback/evidence paths to open when needed. Analysis workers do NOT read `final-report-template.md` — that file is for the report writer only.
 
-The CLI writes a Reading Confirmation block to the **audit sidecar** at `runs/<task-type>/worker-results/antigravity-worker-audit-<task-type>-<seq>.md`. The sidecar's body begins with `# Antigravity Worker Audit — <task-key>` followed by one short line per input file confirming end-to-end reading. The main Antigravity output MUST NOT contain a `## 0. Reading Confirmation` heading — the validator fails worker-results that contain one. If any file was skipped, record a `tool-failure` in the errors sidecar instead of fabricating Findings.
+The CLI writes a Reading Confirmation block to the **audit sidecar** at `runs/<task-type>/worker-results/antigravity-worker-audit-<task-type>-<seq>.md`. The sidecar's body begins with `# Antigravity Worker Audit — <task-key>` followed by one short line per input file confirming end-to-end reading. Section-0 placement follows the worker preamble §"Reading rules" (canonical). If any file was skipped, record a `tool-failure` in the errors sidecar instead of fabricating Findings.
 
 ## Worker Output Structure
 
-The Antigravity CLI — not this wrapper — produces the worker result. Its required structure is defined in the preamble (the lead injects the `**Worker Preamble Path:**` anchor into the dispatched prompt you persist and forward, and the CLI Reads it) plus the team-contract resource (`prompts/lead/team-contract.md`) "Worker Output Contract": YAML frontmatter with `workerId: "antigravity"`, sections 1–5 (common core) plus optional Section 6, a unique item ID on every item, and ticket tagging on `requirements-discovery` / `error-analysis` / `implementation-planning` / `implementation` runs. This wrapper forwards the CLI's output unmodified except for the single `**Model:**` line (step 8d) — never reshape or summarize it.
+The Antigravity CLI — not this wrapper — produces the worker result. Its required structure is defined in the preamble (the lead injects the `**Worker Preamble Path:**` anchor into the dispatched prompt you persist and forward, and the CLI Reads it): YAML frontmatter with `workerId: "antigravity"`, sections 1–5 (common core) plus optional Section 6, a unique item ID on every item, and ticket tagging on `requirements-discovery` / `error-analysis` / `implementation-planning` / `implementation` runs. This wrapper forwards the CLI's output unmodified except for the single `**Model:**` line (step 8d) — never reshape or summarize it.
 
 ## Error reporting
 
@@ -219,7 +219,7 @@ pre-flight terminal status, not a runtime CLI error.
 - Always specify the assigned `--model` value for the current run.
 - Return error messages as-is on failure.
 - Do not summarize or modify Antigravity results beyond prepending the single `**Model:**` line on a normal return (step 8d).
-- Sections 1–5 of the worker output are the common core shared with the Claude and Codex workers — the dispatched prompt asks identical questions for all three roles, and the Antigravity CLI must answer all of them, not only requirement-interpretation findings. Your specialization (requirement interpretation, consistency, safety, documentation quality, alternative viewpoints) belongs only in optional Section 6 as additive depth. A Antigravity result whose Findings section is populated solely with requirement-interpretation items is in breach of contract; see `prompts/lead/team-contract.md` "Worker Output Contract".
+- Sections 1–5 of the worker output are the common core shared with the Claude and Codex workers — the dispatched prompt asks identical questions for all three roles, and the Antigravity CLI must answer all of them, not only requirement-interpretation findings. Your specialization (requirement interpretation, consistency, safety, documentation quality, alternative viewpoints) belongs only in optional Section 6 as additive depth. A Antigravity result whose Findings section is populated solely with requirement-interpretation items is in breach of contract; see the preamble §"Worker output sections".
 
 ## Stage evidence emission (BLOCKING, implementation task only)
 

package/runtime/agents/workers/claude-worker.md

@@ -70,7 +70,7 @@ Before producing any output, you MUST:
 
 ## Worker Output Structure
 
-Follow the **Worker output sections** contract in the preamble you Read via the `**Worker Preamble Path:**` anchor: YAML frontmatter, then sections 1–5 (common core) plus optional Section 6 (your specialization lens), every item carrying a unique worker-internal item ID, with ticket tagging on `requirements-discovery` / `error-analysis` / `implementation-planning` / `implementation` runs. Set `workerId: "claude"`. The full frontmatter schema, item-ID conventions, and authoritative section ordering live in the team-contract resource (`prompts/lead/team-contract.md`) "Worker Output Contract" — the SSOT if anything is ambiguous.
+Follow the **Worker output contract** in the preamble you Read via the `**Worker Preamble Path:**` anchor — it is the canonical source for the frontmatter schema, sections 1–5 + optional Section 6 ordering, item-ID conventions, and ticket tagging. Set `workerId: "claude"`.
 
 ## Stop Condition (BLOCKING)
 
@@ -78,7 +78,7 @@ When Lead dispatches you with `run_in_background: true`, its `Agent()` call retu
 
 After your `Write` to the assigned worker-results file (path provided by Lead as `**Result Path:**` — the canonical anchor header defined in `team-contract` "Worker Prompt Composition" — or derived under `runs/<task-type>/worker-results/claude-worker-<task-type>-<seq>.md`) succeeds:
 
-1. Return your final assistant message **immediately**. Begin every return with your model identity, copied verbatim from the `**Model:** Claude worker, <modelExecutionValue>` line in your dispatch prompt (per Worker Preamble → "Return message to the lead"), then the status line — for an analysis dispatch:
+1. Return your final assistant message **immediately**. Begin every return with your model identity, per the preamble §"Return message to the lead", then the status line — for an analysis dispatch:
    ```
    **Model:** Claude worker, <modelExecutionValue>
    Worker results written to <abs path>. Sections 1–5 complete. Findings: <n>.

package/runtime/agents/workers/codex-worker.md

@@ -106,7 +106,7 @@ The wrapper exists because Claude Code's Bash permission matcher rejects simple-
       2. Record a `cli-failure` event directly to the run-level error log via the exact `okstra error-log append-observed` template in §"Error reporting" — substitute `--exit-code 0`, `--duration-ms <observed-ms>`, `--message "okstra-codex-exec.sh exited 0 but no result file at <abs-path>"`, and `--stderr-excerpt-file <temp-tail-path>`.
       3. Return `CODEX_RESULT_MISSING: codex exited 0 but result file absent at <abs-path>` instead of the raw stdout. The lead is responsible for deciding redispatch per `team-contract` "Lead Redispatch Policy on Result-Missing".
 
-   d. **Normal return.** Otherwise (`exit_code == 0` AND result file exists), return the wrapper's accumulated stdout from `BashOutput`, prefixed by exactly one model-identity line copied verbatim from the `**Model:** Codex worker, <execution-value>` line in the lead prompt (per Worker Preamble → "Return message to the lead"):
+   d. **Normal return.** Otherwise (`exit_code == 0` AND result file exists), return the wrapper's accumulated stdout from `BashOutput`, prefixed by exactly one model-identity line per the preamble §"Return message to the lead":
       ```
       **Model:** Codex worker, <assigned-model-execution-value>
       ```
@@ -151,11 +151,11 @@ Before invoking the Codex CLI, you MUST:
 1. Extract the absolute path from the lead's `**Worker Preamble Path:**` anchor header and verify the CLI run will Read that file end-to-end (canonical SSOT for the Required Reading + Error Reporting + Output sections contract). The lead's prompt body — which you persist verbatim and feed into Codex via stdin — already contains this anchor; do not strip it.
 2. Verify the lead's prompt body lists the per-run primary input files under `## Inputs` (normally `analysis-packet.md` for analysis workers). The source files named inside that packet are fallback/evidence paths to open when needed. Analysis workers do NOT read `final-report-template.md` — that file is for the report writer only.
 
-The CLI writes a Reading Confirmation block to the **audit sidecar** at `runs/<task-type>/worker-results/codex-worker-audit-<task-type>-<seq>.md`. The sidecar's body begins with `# Codex Worker Audit — <task-key>` followed by one short line per input file confirming end-to-end reading. The main Codex output MUST NOT contain a `## 0. Reading Confirmation` heading — the validator fails worker-results that contain one. If any file was skipped, record a `tool-failure` in the errors sidecar instead of fabricating Findings.
+The CLI writes a Reading Confirmation block to the **audit sidecar** at `runs/<task-type>/worker-results/codex-worker-audit-<task-type>-<seq>.md`. The sidecar's body begins with `# Codex Worker Audit — <task-key>` followed by one short line per input file confirming end-to-end reading. Section-0 placement follows the worker preamble §"Reading rules" (canonical). If any file was skipped, record a `tool-failure` in the errors sidecar instead of fabricating Findings.
 
 ## Worker Output Structure
 
-The Codex CLI — not this wrapper — produces the worker result. Its required structure is defined in the preamble (the lead injects the `**Worker Preamble Path:**` anchor into the dispatched prompt you persist and forward, and the CLI Reads it) plus the team-contract resource (`prompts/lead/team-contract.md`) "Worker Output Contract": YAML frontmatter with `workerId: "codex"`, sections 1–5 (common core) plus optional Section 6, a unique item ID on every item, and ticket tagging on `requirements-discovery` / `error-analysis` / `implementation-planning` / `implementation` runs. This wrapper forwards the CLI's output unmodified except for the single `**Model:**` line (step 8d) — never reshape or summarize it.
+The Codex CLI — not this wrapper — produces the worker result. Its required structure is defined in the preamble (the lead injects the `**Worker Preamble Path:**` anchor into the dispatched prompt you persist and forward, and the CLI Reads it): YAML frontmatter with `workerId: "codex"`, sections 1–5 (common core) plus optional Section 6, a unique item ID on every item, and ticket tagging on `requirements-discovery` / `error-analysis` / `implementation-planning` / `implementation` runs. This wrapper forwards the CLI's output unmodified except for the single `**Model:**` line (step 8d) — never reshape or summarize it.
 
 ## Error reporting
 
@@ -219,7 +219,7 @@ pre-flight terminal status, not a runtime CLI error.
 - Ignore stderr warnings from MCP integration.
 - Return error messages as-is on failure.
 - Do not summarize or modify Codex results beyond prepending the single `**Model:**` line on a normal return (step 8d).
-- Sections 1–5 of the worker output are the common core shared with the Claude and Antigravity workers — the dispatched prompt asks identical questions for all three roles, and the Codex CLI must answer all of them, not only implementation-feasibility findings. Your specialization (implementation realism, code-path implications, edge cases, technical trade-offs) belongs only in optional Section 6 as additive depth. A Codex result whose Findings section is populated solely with implementation-feasibility items is in breach of contract; see `prompts/lead/team-contract.md` "Worker Output Contract".
+- Sections 1–5 of the worker output are the common core shared with the Claude and Antigravity workers — the dispatched prompt asks identical questions for all three roles, and the Codex CLI must answer all of them, not only implementation-feasibility findings. Your specialization (implementation realism, code-path implications, edge cases, technical trade-offs) belongs only in optional Section 6 as additive depth. A Codex result whose Findings section is populated solely with implementation-feasibility items is in breach of contract; see the preamble §"Worker output sections".
 
 ## Stage evidence emission (BLOCKING, implementation task only)