okstra 0.123.0 → 0.124.0

package/docs/task-process/implementation-planning.md

@@ -2,23 +2,23 @@
 
 ## Index
 
-- [1. 목적](#1-목적)
-- [2. okstra-run wizard 흐름](#2-okstra-run-wizard-흐름)
-- [3. prepare_task_bundle 처리](#3-prepare_task_bundle-처리)
-- [4. lead 실행 흐름](#4-lead-실행-흐름)
-- [5. design preparation과 final report gate](#5-design-preparation과-final-report-gate)
-- [6. 금지선](#6-금지선)
-- [7. 확인한 코드](#7-확인한-코드)
+- [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. design preparation and final report gate](#5-design-preparation-and-final-report-gate)
+- [6. Forbidden actions](#6-forbidden-actions)
+- [7. Verified code](#7-verified-code)
 
-## 1. 목적
+## 1. Purpose
 
-`implementation-planning`은 coding 전에 구현 방향을 정하는 phase다. 최소 두 개의 implementation option, trade-off, recommended option, stepwise execution order, validation checklist, rollback strategy를 만들고 사용자 approval gate를 둔다.
+`implementation-planning` is the phase that decides the implementation direction before coding. It produces at least two implementation options, trade-offs, a recommended option, a stepwise execution order, a validation checklist, and a rollback strategy, and it places a user approval gate.
 
-## 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-planning]
     Type --> Worktree{active task worktree?}
     Worktree -->|yes| Defaults[Use defaults / Customize]
@@ -33,9 +33,9 @@ flowchart TD
     Confirm --> Render[render-bundle]
 ```
 
-wizard는 현재 `--no-plan-verification`을 묻지 않는다. okstra-run 경로에서는 plan-body verification이 기본 enabled로 준비된다. shell/CLI 경로에는 `--no-plan-verification` flag가 있다.
+The wizard currently does not ask about `--no-plan-verification`. On the okstra-run path, plan-body verification is prepared as enabled by default. The shell/CLI path has a `--no-plan-verification` flag.
 
-## 3. prepare_task_bundle 처리
+## 3. prepare_task_bundle handling
 
 ```mermaid
 sequenceDiagram
@@ -55,9 +55,9 @@ sequenceDiagram
     P-->>W: prepared lead prompt
 ```
 
-runtime prepare 단계는 source edit를 막는 것이 아니라 "현재 phase boundary를 lead prompt와 manifest에 박아 넣는" 방식이다. 실제 no-edit/no-build 규칙은 lead와 worker가 profile을 읽고 지켜야 한다.
+The runtime prepare stage does not block source edits itself; instead it "bakes the current phase boundary into the lead prompt and manifest." The actual no-edit/no-build rules must be honored by the lead and workers reading the profile.
 
-## 4. lead 실행 흐름
+## 4. lead execution flow
 
 ```mermaid
 flowchart TD
@@ -74,28 +74,28 @@ flowchart TD
     NoApproval --> P7
 ```
 
-Plan-body verification은 Phase 5.5와 다른 queue를 쓴다. Phase 5.5는 worker finding을 검증하고, Phase 6 sub-step은 report-writer가 만든 consolidated plan body를 `P-*` plan item 단위로 다시 검증한다.
+Plan-body verification uses a different queue from Phase 5.5. Phase 5.5 verifies worker findings, and the Phase 6 sub-step re-verifies the consolidated plan body produced by the report-writer at the `P-*` plan-item level.
 
-## 5. design preparation과 final report gate
+## 5. design preparation and final report gate
 
-lead는 Stage Map에서 domain contract, persistence schema, external interface, transaction/consistency, transformation mapping, lifecycle state machine, rollout/observability, manual user test surface를 결정적으로 탐지한다. report-writer는 사용자에게 빈칸부터 묻지 않고, 알려진 사실과 근거를 사용해 각 surface의 구체적인 AI 초안을 먼저 작성한다.
+The lead deterministically detects domain contract, persistence schema, external interface, transaction/consistency, transformation mapping, lifecycle state machine, rollout/observability, and manual user test surface from the Stage Map. The report-writer does not ask the user starting from blanks; instead it first writes a concrete AI draft for each surface using known facts and evidence.
 
-`designPreparation.items[]`의 상태는 완성도를 강제로 한 단계에 고정하지 않는다.
+The status of `designPreparation.items[]` does not forcibly pin completeness to a single stage.
 
-| 상태 | 의미 | implementation 진입 시 처리 |
+| Status | Meaning | Handling on implementation entry |
 |---|---|---|
-| `ready` | 구현 계약이 planning snapshot 안에서 충분히 확정됨 | 해당 stage 진행 |
-| `provisional` | 되돌릴 수 있는 working assumption과 guardrail이 있어 지금 진행해도 안전함 | 해당 stage 진행, assumption을 executor prompt에 주입하고 지정한 review point에서 재확인 |
-| `blocked` | 안전한 기본값이 없고 외부 권한·비즈니스 정책·파괴적 변경 결정이 필요함 | 이 item의 `stageRefs`에 속한 stage만 input 대기 또는 replan |
-| `not-applicable` | detector가 찾은 surface가 이 stage에서는 별도 계약을 요구하지 않음 | 구체적인 사유를 남기고 진행 |
+| `ready` | The implementation contract is sufficiently finalized within the planning snapshot | Proceed with that stage |
+| `provisional` | There is a reversible working assumption and guardrail, so it is safe to proceed now | Proceed with that stage, inject the assumption into the executor prompt, and re-confirm at the designated review point |
+| `blocked` | There is no safe default and it needs an external authorization, business policy, or destructive-change decision | Only the stage in this item's `stageRefs` waits for input or is replanned |
+| `not-applicable` | The surface found by the detector does not require a separate contract in this stage | Record a concrete reason and proceed |
 
-탐지된 surface가 없고 interface/acceptance를 바꾸는 manual test input도 없으면 `mode: no-design-inputs`와 구체적인 사유를 쓴다. 따라서 간단한 작업에 형식적인 빈 문서를 만들 필요가 없다.
+If there is no detected surface and no manual test input that changes the interface/acceptance, write `mode: no-design-inputs` with a concrete reason. So there is no need to create a formal empty document for a simple task.
 
-`manual-user-test`는 planning 시점에 실행 방법을 완전히 고정하지 않아도 된다. 실제 diff를 보기 전에도 안전한 기본 절차가 있으면 `provisional`과 `ifStillOpen: follow-up`으로 진행하고, 구현 리포트가 실제 변경에 맞춘 `implementation.manualUserTest`를 최종 소유한다. 반대로 사용자만 제공할 수 있는 acceptance 방법 없이는 해당 stage를 안전하게 완료할 수 없을 때만 `blocked`를 사용한다.
+`manual-user-test` does not have to fully fix the execution method at planning time. If there is a safe default procedure even before seeing the actual diff, proceed with `provisional` and `ifStillOpen: follow-up`, and the implementation report finally owns the `implementation.manualUserTest` aligned to the actual change. Conversely, use `blocked` only when the stage cannot be safely completed without an acceptance method that only the user can provide.
 
-Phase 7은 `provisional`/`blocked` item마다 AI proposal이 채워진 `design-prep-requests/` 문서를 결정적으로 만든다. 사용자 또는 wizard가 초안을 승인·수정·거부·보류하면, 확인 이후에만 `design-prep-inputs/` 아래 새 revision sidecar를 append한다. 이 응답은 approved planning report를 수정하지 않는다.
+Phase 7 deterministically creates a `design-prep-requests/` document filled with an AI proposal for each `provisional`/`blocked` item. When the user or wizard approves, edits, rejects, or holds the draft, only after confirmation does it append a new revision sidecar under `design-prep-inputs/`. This response does not modify the approved planning report.
 
-plan approval과 design-preparation 상태는 독립된 gate다. plan-body verification이 통과했다면 `blocked` item이 있어도 계획 자체는 승인할 수 있다. 실제 `implementation` preflight가 선택한 stage의 item만 해소하며, unrelated stage는 계속 진행한다.
+Plan approval and design-preparation status are independent gates. If plan-body verification passed, the plan itself can be approved even when there is a `blocked` item. The actual `implementation` preflight resolves only the items of the selected stage, and unrelated stages keep proceeding.
 
 ```mermaid
 flowchart LR
@@ -111,7 +111,7 @@ flowchart LR
     Approval --> Impl[Next run: implementation]
 ```
 
-validator가 section heading의 영문 substring을 찾기 때문에 다음 문자열은 heading line에 그대로 남아야 한다.
+Because the validator searches for the English substring of the section heading, the following strings must remain verbatim on the heading line.
 
 - `Option Candidates`
 - `Trade-off`
@@ -127,9 +127,9 @@ validator가 section heading의 영문 substring을 찾기 때문에 다음 문
 - `Requirement Coverage`
 - `Implementation Design Preparation`
 
-approval은 YAML frontmatter의 `approved: true`와 선택한 `implementation-option`으로 기록한다. `Blocks=approval` clarification row가 unresolved이면 frontmatter가 승인 상태여도 implementation prepare에서 거부된다. design-preparation의 `blocked` 상태 자체는 `Blocks=approval`과 같지 않으며, 해당 stage의 implementation preflight에서만 작동한다.
+Approval is recorded with `approved: true` in the YAML frontmatter and the chosen `implementation-option`. If a `Blocks=approval` clarification row is unresolved, the implementation prepare rejects it even when the frontmatter is in an approved state. The `blocked` status of design-preparation is not the same as `Blocks=approval`, and it operates only at that stage's implementation preflight.
 
-## 6. 금지선
+## 6. Forbidden actions
 
 ```mermaid
 flowchart TD
@@ -140,9 +140,9 @@ flowchart TD
     Plan -. forbidden .-> NextPhase[start implementation in same run]
 ```
 
-이 phase는 plan document만 만든다. code-level micro-optimization, source edit, build, migration, deployment, run artifact directory 밖 write는 금지된다.
+This phase only produces the plan document. Code-level micro-optimization, source edit, build, migration, deployment, and any write outside the run artifact directory are forbidden.
 
-## 7. 확인한 코드
+## 7. Verified code
 
 - [`prompts/profiles/implementation-planning.md`](../../prompts/profiles/implementation-planning.md)
 - [`templates/reports/implementation-planning-input.template.md`](../../templates/reports/implementation-planning-input.template.md)

package/docs/task-process/implementation.md

@@ -2,25 +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)
   - [3.1 design-preparation preflight](#31-design-preparation-preflight)
-- [4. executor와 verifier](#4-executor와-verifier)
-- [5. stage와 consumers](#5-stage와-consumers)
-- [6. 산출물](#6-산출물)
-- [7. 금지선](#7-금지선)
-- [8. 확인한 코드](#8-확인한-코드)
+- [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]
@@ -39,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
 
@@ -70,23 +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.
 
 ### 3.1 design-preparation preflight
 
-stage 선택 직후, worktree provision과 `consumers.jsonl`의 `status:"started"` append 전에 approved plan의 design preparation을 해소한다. resolver는 선택한 stage가 `stageRefs`에 포함된 item만 읽으므로 다른 stage의 미확정 결정은 현재 run을 막지 않는다.
+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 동작 |
+| outcome | runtime behavior |
 |---|---|
-| `proceed` | effective AI proposal, confirmed override, guardrail, provisional working assumption을 `DESIGN_PREP_CONTEXT`로 executor prompt에 주입하고 worktree를 만든다. |
-| `wait_for_input` | `stage <N> waits for design input: ...; <request paths>`로 중단한다. worktree와 started consumer row는 만들지 않는다. |
-| `replan` | `stage <N> requires implementation-planning rerun: ...`으로 중단한다. 새로 승인·수정된 결정이 planning snapshot 또는 Stage Map을 바꾸게 한다. |
+| `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`, `no-design-inputs`는 진행한다. `provisional`은 안전한 working assumption이 있으므로 응답이 없어도 진행할 수 있으며, non-triggering 승인/수정은 그 assumption과 override를 prompt에 명시한다. `blocked` 무응답은 해당 stage만 대기시키고, blocked 초안을 승인·수정한 경우에는 그 권한을 approved plan에 반영하도록 replan한다. markerless legacy plan은 report를 고치지 않고 `legacy-unassessed` warning과 함께 진행한다.
+`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도 같은 유연한 상태를 사용한다. planning의 초안은 implementation이 실제 diff에 맞춰 검증 방법을 구체화하기 위한 seed이며, 최종 실행 방법의 SSOT는 implementation report의 `implementation.manualUserTest`다. planning sidecar를 final-verification이 직접 실행하지 않는다.
+`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와 verifier
+## 4. executor and verifier
 
 ```mermaid
 flowchart TD
@@ -103,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
@@ -123,11 +123,11 @@ flowchart LR
     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
@@ -140,22 +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
-- 실제 diff에 맞춰 확정한 `implementation.manualUserTest`와 실행 가능 여부
+- `implementation.manualUserTest` finalized against the actual diff and whether it is executable
 - follow-up tasks table
 
-## 7. 금지선
+## 7. Forbidden actions
 
 ```mermaid
 flowchart TD
@@ -168,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.123.0",
+  "version": "0.124.0",
   "description": "Multi-agent cross-verification orchestrator runtime + Claude Code skills.",
   "license": "MIT",
   "author": "devonshin",