okstra 0.48.0 → 0.50.0

package/runtime/prompts/profiles/_implementation-verifier.md

@@ -83,7 +83,7 @@ A mocked unit test cannot observe the SQL a query builder actually emits — `co
 - **Requirement when fired.** The verifier MUST reproduce a real-DB execution: run the `db-test` tier (Tier 1 = plan `validation` db step; else Tier 2 = `project.json.qaCommands.db-test`) against a **local / replica** datastore (same engine + schema — never shared / staging / prod, consistent with the verifier forbidden-actions list) and record its exact command + exit code. A mock, an in-memory shim that does not parse real SQL, or static reasoning does NOT satisfy this.
 - **No `db-test` command available → blocking, not a passive skip.** If neither tier declares a `db-test` command, the verifier records the blocking finding `db-test not configured — DB change unverified (mock-only)` and sets the verdict to `FAIL`; it MUST NOT emit only the passive `qa-command not configured` note and pass. Recommended fix: declare a `db-test` command in `project.json.qaCommands` or the plan's validation set.
 - **Mock-only evidence → unverified.** If the diff's only DB coverage is mocked, the verifier labels the DB portion `정적 분석상 …, 미검증(실행 안 함)` (never `검증됨`), records it as a blocking finding, and sets `FAIL`. Never downplay the real run as "too heavy / static proof suffices".
-- **Surface it at every layer.** The finding is copied verbatim into the verifier result and MUST survive into the final report's `## 1.` and Verdict Card, so the user sees the DB-unverified state continuously — it is the load-bearing reason a downstream `final-verification` cannot reach `accepted` and `release-handoff` cannot push.
+- **Surface it at every layer.** The finding is copied verbatim into the verifier result and MUST survive into the final report's `## 6.` and Verdict Card, so the user sees the DB-unverified state continuously — it is the load-bearing reason a downstream `final-verification` cannot reach `accepted` and `release-handoff` cannot push.
 
 ## All-verifier-failure policy
 

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

@@ -25,7 +25,7 @@
   - uncertainty boundaries
   - practical next diagnostic steps
 - Clarification request policy (phase-specific addenda — shared policy is in `_common-contract.md`):
-  - if any blocking uncertainty remains at the time of writing the final report, populate `## 5. Clarification Items` in `final-report-template.md` (a single unified table; `Blocks=next-phase` for items the next run cannot start without)
+  - if any blocking uncertainty remains at the time of writing the final report, populate `## 1. Clarification Items` in `final-report-template.md` (a single unified table; `Blocks=next-phase` for items the next run cannot start without)
   - prefer plain Korean over abbreviations (e.g. write "초당 평균 요청 수" instead of "QPS", "재현 절차" instead of "repro")
   - every clarification row carries a recommended answer + one-line rationale inside the `Expected form` cell; rows that lack a recommendation are rejected as half-formed.
   - **Codebase-first ambiguity resolution (defect rule)**: any ambiguity about repro, file behavior, or symbol semantics that can be answered by `Read` / `Grep` / log inspection MUST be resolved that way and recorded with file:line (or log-line) evidence. Writing a clarification row for something the codebase or shipped logs already answer is a defect of this phase.

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

@@ -29,7 +29,7 @@
   - if the cited implementation report is missing, lacks commits for delivered code changes, or the current checkout does not match the implementation report's commit list / diff summary, the run MUST end with status `blocked` and route back to `implementation` or `implementation-planning` rather than verifying an ambiguous target.
 - Required deliverable shape (final report, in addition to the standard sections):
   - **Source Implementation Report**: relative path of the originating `implementation` final-report file, the quoted commit list / diff summary used as the verification target, the worktree path inspected, and the base/head SHAs captured at run start. The lead injects this same target snapshot into every analyser prompt (`**Worktree:** / **Verification base ref:** / **Verification head SHA:** / **Verification diff stat:**`); a worker that cannot confirm its analysis ran against that exact head MUST record a `tool-failure` rather than verify an ambiguous target.
-  - **Verdict vocabulary**: Section 2 (`Final Verdict`) MUST include a `Verdict Token` field whose value is exactly one of `accepted`, `conditional-accept`, or `blocked`. `conditional-accept` requires an explicit, exhaustive list of conditions; ambiguous verdicts ("looks good", "mostly ready") are not allowed. Each condition MUST be recorded as a row in the **Conditional Acceptance Conditions** deliverable (`id` `CA-NNN`, `condition`, `evidenceRequired`, `blocksReleaseHandoff`). The validator enforces verdict↔deliverable consistency: `accepted` ⇒ zero acceptance blockers, `blocked` ⇒ at least one, `conditional-accept` ⇒ at least one condition, and a `release-handoff` routing recommendation is allowed only when the verdict is `accepted`.
+  - **Verdict vocabulary**: Section 7 (`Final Verdict`) MUST include a `Verdict Token` field whose value is exactly one of `accepted`, `conditional-accept`, or `blocked`. `conditional-accept` requires an explicit, exhaustive list of conditions; ambiguous verdicts ("looks good", "mostly ready") are not allowed. Each condition MUST be recorded as a row in the **Conditional Acceptance Conditions** deliverable (`id` `CA-NNN`, `condition`, `evidenceRequired`, `blocksReleaseHandoff`). The validator enforces verdict↔deliverable consistency: `accepted` ⇒ zero acceptance blockers, `blocked` ⇒ at least one, `conditional-accept` ⇒ at least one condition, and a `release-handoff` routing recommendation is allowed only when the verdict is `accepted`.
   - **Acceptance Blockers block** (under section 4): one row per blocker with `id`, `severity` (`critical` / `major` / `minor`), evidence (file path, log excerpt, or test output), and the recommended follow-up phase (`error-analysis` or `implementation-planning`). Empty block is acceptable and preferred — render the single line `- No acceptance blockers found.`
   - **Residual Risk block** (under section 4): risks that are not blockers but should be tracked, each with mitigation owner and a trigger that would escalate them to a blocker.
   - **Validation Evidence**: for every requirement in the originating plan or task brief, cite the artifact (commit SHA, test output, log line, MCP SELECT result) that demonstrates coverage. Paraphrased "verified" claims without an artifact are rejected.
@@ -37,7 +37,7 @@
   - **Two-tier command lookup (shared with `implementation`):** when this phase performs its own independent re-validation, the command source is exactly the same two tiers `implementation` verifiers use — Tier 1 is the originating task brief / approved plan's `validation` set, Tier 2 is `<PROJECT_ROOT>/.okstra/project.json` under `qaCommands`. Auto-detecting tools from manifest files is forbidden; missing tiers are recorded as `qa-command not configured: <category>` and do NOT trigger a guess. The `cmd` deny-list (`--fix`, `--write`, ` -w`, ` -u`, `--snapshot-update`, `INSTA_UPDATE=<not-no>`, `cargo update`, `npm install` without `ci`, etc.) is enforced identically. NOTE: runtime fail-fast validation (`okstra_ctl.qa_commands.validate_qa_commands`) only fires at `--task-type implementation` run-prep, so this phase MUST self-check each `qaCommands` entry against the deny-list before executing it — if a denied token is present, skip the command and record it as a `Read-only command log` line `qa-command rejected (denied token: <token>): <label>`.
   - **Routing recommendation**: the next safe phase — one of `release-handoff`, `done`, `error-analysis`, `implementation-planning` — tied to the verdict and blocker list. `release-handoff` is allowed ONLY when the Verdict Token is `accepted`.
 - Clarification request policy (phase-specific addendum — shared policy is in `_common-contract.md`):
-  - populate `## 5. Clarification Items` only when a blocker hinges on information only the user can supply (deployment intent, intended target environment, business-rule interpretation); use `Blocks=next-phase` for items that gate continuing to release-handoff
+  - populate `## 1. Clarification Items` only when a blocker hinges on information only the user can supply (deployment intent, intended target environment, business-rule interpretation); use `Blocks=next-phase` for items that gate continuing to release-handoff
 - Self-review pass before finalising the report (`Claude lead` runs this; do not delegate to a generic subagent):
   1. **Verdict precision** — section 2 includes `Verdict Token` with one of the three allowed verdict tokens; `conditional-accept` lists every condition as an actionable item.
   2. **Blocker traceability** — every blocker cites a concrete artifact (file:line, log excerpt, test exit code, MCP SELECT). Blockers without evidence are demoted to residual risk or removed.

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

@@ -17,7 +17,7 @@
   - inspect the current state of every file the task names (or the closest matching files if names are stale) — record current responsibilities, public interfaces, and known coupling points
   - skim recent commits touching those files (`git log -- <path>`) to surface in-flight work or contested areas
   - **codebase-first ambiguity resolution**: any ambiguity that can be answered by `Read` / `Grep` MUST be resolved that way and recorded with file:line evidence. Only ambiguities that genuinely require a human decision are escalated as `Clarification Items` rows. Writing a clarification row for something the code already answers is a defect of this phase.
-  - flag any requirement that is ambiguous, contradictory, or missing success criteria — register each one as a row in the report's `## 5. Clarification Items` table with `Blocks=approval` instead of guessing
+  - flag any requirement that is ambiguous, contradictory, or missing success criteria — register each one as a row in the report's `## 1. Clarification Items` table with `Blocks=approval` instead of guessing
   - read `<PROJECT_ROOT>/.okstra/glossary.md` and `<PROJECT_ROOT>/.okstra/decisions/` titles if present. Absent okstra memory files are the normal state — do not error. Treat the brief's `terminology:*` resolutions from `requirements-discovery` (if any) as authoritative; if missing, resolve any remaining fuzzy term as a `Blocks=approval` clarification row.
 - Primary focus areas:
   - requirement gaps
@@ -39,7 +39,7 @@
   - The YAML frontmatter `approved: true|false` field is the only authorised approval gate. report-writer always emits `approved: false`. The user clears it either by (a) editing the frontmatter line to `approved: true` directly, or (b) invoking the next phase with `--approve` so the CLI flips the frontmatter on the user's behalf. `okstra_ctl.run._validate_approved_plan` reads this field and refuses entry until it is `true`.
 - Cross-verification mode:
   - Phase 5.5 finding convergence runs in **adversarial mode** for this phase (`convergence.adversarial=true`). Verifiers actively try to refute each worker finding (requirement gap / risk / option) by re-inspecting its cited evidence; the burden of proof sits on the claim. See `skills/okstra-convergence/SKILL.md` §"Adversarial Verification Mode".
-  - §4.5.9 plan-body verification runs with an **adversarial posture** (`skills/okstra-convergence/SKILL.md` §"Adversarial plan-body posture"): verifiers open and confirm every cited path / command and put the burden of proof on the plan. The gate threshold is unchanged — a *majority* `DISAGREE` (`majority-disagree`) is still required to block approval; a single dissent does not.
+  - §5.5.9 plan-body verification runs with an **adversarial posture** (`skills/okstra-convergence/SKILL.md` §"Adversarial plan-body posture"): verifiers open and confirm every cited path / command and put the burden of proof on the plan. The gate threshold is unchanged — a *majority* `DISAGREE` (`majority-disagree`) is still required to block approval; a single dissent does not.
   - **Coverage critic (opt-in)**: when `convergence.critic.enabled=true` (chosen via the okstra-run picker or `--critic`), a reused-worker critic pass runs after convergence to surface missed findings; its gaps are merged only after a 1-round adversarial reverify. See `skills/okstra-convergence/SKILL.md` "Coverage critic pass".
 - Non-goals:
   - code-level micro-optimization unless it changes the implementation approach
@@ -55,7 +55,7 @@
   - The final report MUST include section headings containing each of the following exact strings: `Option Candidates`, `Trade-off`, `Recommended Option`, `Stage Map`, `Stage Exit Contract`, `Stage Validation`, `Dependency`, `Validation Checklist`, `Rollback`. (Approval is no longer a body section — it is the YAML frontmatter `approved` field.)
   - Korean translations are allowed in parentheses (e.g. `### Recommended Option (권장 옵션)`), but the English keyword must be present verbatim in the heading line.
   - The shape and ordering follow `final-report-template.md` section 4.5 (`Implementation Plan Deliverables`). Do NOT translate the heading keywords — `validators/validate-run.py` does substring matching on the raw report text and 7-of-8 missing strings is a real, repeatedly observed failure mode (root cause: writer translated the headings to Korean).
-  - Beyond substring matching, when the Plan Body Verification gate result is `passed` / `passed-with-dissent`, `validators/validate-run.py` runs the **structural** Stage Map validator (`validators/validate-implementation-plan-stages.py`) at the planning boundary — the exact `## 4.5 Stage Map` heading, each `## 4.5.<i> Stage <i>:` section with its four required subsections, the per-stage effective step count (≤6), and the `depends-on` DAG are all enforced here, not deferred to the `implementation` entry gate.
+  - Beyond substring matching, when the Plan Body Verification gate result is `passed` / `passed-with-dissent`, `validators/validate-run.py` runs the **structural** Stage Map validator (`validators/validate-implementation-plan-stages.py`) at the planning boundary — the exact `## 5.5 Stage Map` heading, each `## 5.5.<i> Stage <i>:` section with its four required subsections, the per-stage effective step count (≤6), and the `depends-on` DAG are all enforced here, not deferred to the `implementation` entry gate.
 - Required deliverable shape (final report, in addition to the standard sections):
   - at least two implementation options. **Each option must include**:
     - **File Structure**: an explicit list of files to create / modify / delete with each file's responsibility (one-line each). Use the form `Create: path — responsibility` / `Modify: path:line-range — change summary` / `Delete: path — reason`.
@@ -64,7 +64,7 @@
   - trade-off matrix across options (rows = options, columns at minimum: complexity, risk, reversibility, test coverage cost, rollout cost)
   - recommended option with rationale tied to the design principles above
   - **Stage Map (mandatory — always emitted, even when N=1):** a table of all stages with `stage | title | depends-on | step-count | exit-contract-summary`. `depends-on` is `(none)` or a comma-separated stage number list. Stages with `depends-on (none)` can be implemented in parallel by two simultaneous `implementation` runs.
-  - **Per-stage subsections** (`## 4.5.<i> Stage <i>: <title>` for each `i`), each containing the four required subsections:
+  - **Per-stage subsections** (`## 5.5.<i> Stage <i>: <title>` for each `i`), each containing the four required subsections:
     - `### Carry-In` — for `depends-on (none)`: task-brief only. Otherwise: each depended-on stage's static exit contract + runtime sidecar path `runs/<impl-key>/carry/stage-<i>.json` placeholder.
     - `### Stepwise Execution Order` — bite-sized table with `step | action | files | command | expected`. **Effective row count ≤ 6** (excluding header / divider / blank). Each step is one action completable in 2–5 minutes; for code steps include actual code or diff sketch; prefer TDD ordering (failing test → implementation → green → commit).
     - `### Stage Exit Contract` — predicted added/modified files, newly exposed identifiers/types/endpoints, downstream-usable resources.
@@ -76,9 +76,9 @@
   - validation checklist (pre / mid / post) — each item is an exact command or observable outcome
   - rollback strategy — exact revert path (commits, flags, migrations) and the signal that triggers rollback
   - the YAML frontmatter MUST include the line `approved: false` (report-writer always emits the unflipped value). The user authorises the next `implementation` run by flipping it to `approved: true` (manual edit or `--approve` CLI). Do NOT recreate any `User Approval Request` body block — the validator fails reports that contain one (see `validators/validate-run.py` deprecated patterns).
-  - **the frontmatter `approved: false` line is rendered unconditionally; if the plan-body verification gate (§4.5.9) returns `blocked-by-disagreement` or `aborted-non-result`, the writer MUST keep `approved: false` and the validator refuses any report that ships with `approved: true` under such a gate result.**
-  - every ambiguity flagged during pre-planning that the user must resolve before approval registered as a `Blocks=approval` row in the `## 5. Clarification Items` table (do NOT create a separate `Open Questions` block under `4.5.x` — the unified table is the single home)
-  - **§4.5.9 Plan Body Verification (BLOCKING).** After report-writer finishes the draft, the lead MUST run a worker peer-review round on the consolidated plan body (sections 4.5.1 – 4.5.7) and populate `### 4.5.9 Plan Body Verification` in the final report. The round protocol, plan-item ID scheme (`P-Opt-*` / `P-Step-*` / `P-Dep-*` / `P-Val-*` / `P-Rb-*`), verdict semantics, gate-result classification, and dissent log format are defined in `skills/okstra-convergence/SKILL.md` "Plan-body verification mode". The four gate-result values are `passed`, `passed-with-dissent`, `blocked-by-disagreement`, `aborted-non-result`. When the gate would have been `blocked-by-disagreement` or `aborted-non-result`, the lead MUST NOT silently flip it to one of the passing values to "unblock" the run — that is a contract violation. When `convergence.adversarial=true` (the default for this phase), this round uses the adversarial posture — verifiers confirm cited paths/commands and the burden of proof is on the plan — but the gate threshold stays `majority-disagree` (see that skill's §"Adversarial plan-body posture").
+  - **the frontmatter `approved: false` line is rendered unconditionally; if the plan-body verification gate (§5.5.9) returns `blocked-by-disagreement` or `aborted-non-result`, the writer MUST keep `approved: false` and the validator refuses any report that ships with `approved: true` under such a gate result.**
+  - every ambiguity flagged during pre-planning that the user must resolve before approval registered as a `Blocks=approval` row in the `## 1. Clarification Items` table (do NOT create a separate `Open Questions` block under `4.5.x` — the unified table is the single home)
+  - **§5.5.9 Plan Body Verification (BLOCKING).** After report-writer finishes the draft, the lead MUST run a worker peer-review round on the consolidated plan body (sections 4.5.1 – 4.5.7) and populate `### 5.5.9 Plan Body Verification` in the final report. The round protocol, plan-item ID scheme (`P-Opt-*` / `P-Step-*` / `P-Dep-*` / `P-Val-*` / `P-Rb-*`), verdict semantics, gate-result classification, and dissent log format are defined in `skills/okstra-convergence/SKILL.md` "Plan-body verification mode". The four gate-result values are `passed`, `passed-with-dissent`, `blocked-by-disagreement`, `aborted-non-result`. When the gate would have been `blocked-by-disagreement` or `aborted-non-result`, the lead MUST NOT silently flip it to one of the passing values to "unblock" the run — that is a contract violation. When `convergence.adversarial=true` (the default for this phase), this round uses the adversarial posture — verifiers confirm cited paths/commands and the burden of proof is on the plan — but the gate threshold stays `majority-disagree` (see that skill's §"Adversarial plan-body posture").
   - **Decision-record evaluation (sole owner)**: this phase is the **single owner** of decision-record evaluation in the okstra lifecycle. The brief never evaluates or drafts decision records — it only forwards `adr-candidate:*` signals. Every `adr-candidate:*` entry inherited from the brief's `Open Questions` is a mandatory evaluation target. In addition, evaluate every decision the recommended option introduces against the three criteria:
     1. **Hard to reverse** — would changing the decision later cost meaningfully more than deciding now?
     2. **Surprising without context** — would a future reader, seeing only the code, wonder "why was it built this way?"?
@@ -95,7 +95,7 @@
   1. **Spec coverage** — for every requirement in the task brief, point to the option(s) and step(s) that satisfy it. List gaps explicitly.
   2. **Placeholder scan** — search the report for the patterns in the No-placeholder rule above and fix inline.
   3. **Internal consistency** — option file lists, trade-off matrix, and recommended step list must agree on file paths, names, and signatures. A symbol called `clearLayers()` in the matrix and `clearFullLayers()` in the steps is a bug.
-  4. **Ambiguity check** — any requirement that could be read two ways must be made explicit or moved to the `## 5. Clarification Items` table as a `Blocks=approval` row.
+  4. **Ambiguity check** — any requirement that could be read two ways must be made explicit or moved to the `## 1. Clarification Items` table as a `Blocks=approval` row.
   5. **Scope check** — if the recommended plan now spans multiple independent subsystems, recommend splitting into separate planning runs rather than shipping an oversized plan.
-  6. **Plan-body verification reconciliation (BLOCKING for implementation-planning).** Inspect the `### 4.5.9 Plan Body Verification` verdict table. For every plan-item row classified as `majority-disagree → C-<N>`, the corresponding `C-<N>` row MUST exist in `## 5. Clarification Items` with `Kind` chosen per the standard policy and `Blocks=approval`. Do NOT create a parallel `### 4.5.x Open Questions` block — the unified table is the single home. Conversely, the `Classification` column's `C-<N>` reference and the `## 5. Clarification Items` `ID` column MUST match 1:1; an orphan on either side is a contract violation. For `partial-consensus` and `worker-unique` plan-items, the dissenting opinion lives in §4.5.9 `Dissent log` and is NOT promoted to §5.
+  6. **Plan-body verification reconciliation (BLOCKING for implementation-planning).** Inspect the `### 5.5.9 Plan Body Verification` verdict table. For every plan-item row classified as `majority-disagree → C-<N>`, the corresponding `C-<N>` row MUST exist in `## 1. Clarification Items` with `Kind` chosen per the standard policy and `Blocks=approval`. Do NOT create a parallel `### 5.5.x Open Questions` block — the unified table is the single home. Conversely, the `Classification` column's `C-<N>` reference and the `## 1. Clarification Items` `ID` column MUST match 1:1; an orphan on either side is a contract violation. For `partial-consensus` and `worker-unique` plan-items, the dissenting opinion lives in §5.5.9 `Dissent log` and is NOT promoted to §5.
   7. **Stage Map self-check** — for every stage, count the effective rows of its `Stepwise Execution Order` table by hand; reject the draft if any stage exceeds 6. Walk the `depends-on` graph and confirm it is a DAG (no cycle, no self-reference). For each `depends-on` link, confirm it encodes a real data/contract dependency — do NOT add links to serialise unrelated work, and do NOT split a stage merely to create more parallel stages. **Parallel-safety:** for every pair of `depends-on (none)` stages, confirm their `Stage Exit Contract` predicted file sets are disjoint; if they share a file, merge them or add a `depends-on` link (validator S9 rejects overlap).

package/runtime/prompts/profiles/improvement-discovery.md

@@ -13,7 +13,7 @@
   - this phase REQUIRES a codebase-scan brief whose frontmatter contains `scope: codebase`. A brief without that marker is rejected before worker dispatch.
   - the brief's `priority-lenses` MUST be a non-empty subset (size 1..4) of the lens whitelist defined in `scripts/okstra_ctl/improvement_lenses.py`. Lenses outside the whitelist are rejected.
   - the brief's `scan-scope` defines the only paths workers may read for candidate evidence. `out-of-scope` paths MUST be ignored even when the codebase is otherwise reachable.
-  - the brief's `candidate-cap` (default 8 if absent, absolute cap 12) bounds the number of rows in `## 4.9 Improvement Candidates`.
+  - the brief's `candidate-cap` (default 8 if absent, absolute cap 12) bounds the number of rows in `## 5.9 Improvement Candidates`.
   - Apply the shared reporter-confirmation precondition as written. For this phase any unresolved `intent-check:` / `conversion-block:` row uses `Blocks=next-phase`.
 - Primary focus areas:
   - candidate discovery within the lens whitelist
@@ -29,11 +29,11 @@
 - Decision-tree walk (bounded):
   - When candidates branch on a structural question (e.g. "is module X meant to own this responsibility?"), resolve via `Read` / `Grep` first. Only escalate to the user inside the Phase 1.5 budget.
 - Expected output emphasis:
-  - the `## 4.9 Improvement Candidates` table populated with rows that obey the 10-column schema from `validators/validate-improvement-report.py` (Cand ID `I-NNN`, Lens from whitelist, Title, Scope ⊆ scan-scope, Severity, Effort, Consensus, Source workers `<worker>:<id>` from {claude, codex, gemini}, Recommended next-phase ∈ {requirements-discovery, implementation-planning, error-analysis}, Evidence as path:line list)
-  - `## 2. Final Verdict` Verdict Token ∈ {`candidates-ready`, `no-candidates`, `blocked`}; Direction `routing`; Next Step "사용자에게 후보 K개 선택 의뢰 (## 4.9 표 참조)"
-  - `## 6. Recommended Next Steps` first entry summarises per-candidate routing and proposes new task-key names of the form `<task-group>/imp-<Cand-ID>`
+  - the `## 5.9 Improvement Candidates` table populated with rows that obey the 10-column schema from `validators/validate-improvement-report.py` (Cand ID `I-NNN`, Lens from whitelist, Title, Scope ⊆ scan-scope, Severity, Effort, Consensus, Source workers `<worker>:<id>` from {claude, codex, gemini}, Recommended next-phase ∈ {requirements-discovery, implementation-planning, error-analysis}, Evidence as path:line list)
+  - `## 7. Final Verdict` Verdict Token ∈ {`candidates-ready`, `no-candidates`, `blocked`}; Direction `routing`; Next Step "사용자에게 후보 K개 선택 의뢰 (## 5.9 표 참조)"
+  - `## 3. Recommended Next Steps` first entry summarises per-candidate routing and proposes new task-key names of the form `<task-group>/imp-<Cand-ID>`
 - Clarification request policy (phase-specific addenda — shared policy is in `_common-contract.md`):
-  - if scan-scope or priority-lenses cannot be made concrete during Phase 1.5, end the run with Verdict Token `blocked`, populate `## 5. Clarification Items` with `Blocks=next-phase` rows, and do not run worker dispatch
+  - if scan-scope or priority-lenses cannot be made concrete during Phase 1.5, end the run with Verdict Token `blocked`, populate `## 1. Clarification Items` with `Blocks=next-phase` rows, and do not run worker dispatch
   - every clarification row carries a recommended answer + one-line rationale inside the `Expected form` cell
 - Non-goals:
   - concrete implementation plans, cost estimates, or code edits for any candidate

package/runtime/prompts/profiles/release-handoff.md

@@ -6,12 +6,12 @@
 - Lead-only contract (replaces the shared team contract for this phase):
   - The Claude lead is the sole agent for this run. No `Agent(...)` worker dispatch, no `TeamCreate`, no parallel sub-agents, no convergence loop.
   - The lead drafts the PR title and PR body **inline** by reading the run brief, the cited final-verification report, `git log --oneline <base>..HEAD`, and `git diff <base>..HEAD --stat`. No drafter worker is dispatched.
-  - The lead authors the final-report file directly (no `Report writer worker` dispatch). The report still conforms to the standard `okstra-final-report.template.md` structure, including the `## 4.6 Release Handoff Deliverables` section.
+  - The lead authors the final-report file directly (no `Report writer worker` dispatch). The report still conforms to the standard `okstra-final-report.template.md` structure, including the `## 5.6 Release Handoff Deliverables` section.
   - The shared anti-escalation rule from the common contract still applies: do not start any other lifecycle phase from inside this run.
   - The shared "authority & permissions assumption" rule from the common contract still applies: assume the user holds every permission needed; do not block on hypothetical approvals.
   - The shared "MCP read-only" rule still applies if the brief lists MCP servers, though most release-handoff runs do not use MCP.
 - Pre-handoff entry gate (mandatory — refuse to start if any item fails):
-  - the task brief MUST cite the originating `final-verification` final-report path under `## Source Verification Report`. The lead opens that file and confirms section `## 2. Final Verdict` contains a `Verdict Token` field whose value is exactly `accepted`.
+  - the task brief MUST cite the originating `final-verification` final-report path under `## Source Verification Report`. The lead opens that file and confirms section `## 7. Final Verdict` contains a `Verdict Token` field whose value is exactly `accepted`.
   - if the verdict is `conditional-accept`, `blocked`, or any other token (including ambiguous phrasing like "looks good"), the run MUST end immediately with status `blocked` and a routing recommendation back to `error-analysis` or `implementation-planning`. Do NOT prompt the user; Do NOT run any git command.
   - the lead MUST capture `git status --short` and confirm the working tree is clean. Dirty state aborts the run; release-handoff packages the commits produced by `implementation`, it does not stage or commit changes.
   - the lead MUST capture `git rev-parse --abbrev-ref HEAD` and record it as the **feature branch**. If the current branch is itself `main`, `master`, `prod`, `preprod`, `staging`, or `dev`, the run MUST end immediately — release-handoff never operates on a base branch.

package/runtime/prompts/profiles/requirements-discovery.md

@@ -39,14 +39,14 @@
   - When the brief's `Desired Outcome`, classification, or routing target depends on a chain of decisions, walk that chain one branch at a time. Each branch is one `Clarification Items` row, not a free-form interview.
   - For every clarification row, put the single best answer and one-line rationale in `Expected form` as `Recommended: ...`. Put other options and one-sentence consequences in the same cell as `Alternatives: ...`.
   - **Codebase-first rule**: if a branch can be resolved by `Read` / `Grep` / file inspection, resolve it that way and record `Evidence checked: <path:line>` in the `Statement` cell. Do NOT escalate to the user.
-  - Budget: the unified `## 5. Clarification Items` table caps at the smaller of (a) one row per unresolved decision branch, (b) 8 rows total. Beyond the cap, fold remaining ambiguity into the routing recommendation's risk notes.
+  - Budget: the unified `## 1. Clarification Items` table caps at the smaller of (a) one row per unresolved decision branch, (b) 8 rows total. Beyond the cap, fold remaining ambiguity into the routing recommendation's risk notes.
 - Expected output emphasis:
   - evidence-backed routing decision
   - uncertainty boundaries and missing inputs
   - next recommended phase and safe resume guidance
   - canonical-term resolution for every `terminology:*` brief item, written as a one-line `<term> = <definition>` line in a new `Domain Alignment` subsection of the final report; alongside each, propose whether `<PROJECT_ROOT>/.okstra/glossary.md` should be updated (proposal only — actual writes happen via `okstra-brief` Step 4.5 on a subsequent run)
 - Clarification request policy (phase-specific addenda — shared policy is in `_common-contract.md`):
-  - if any blocking input is missing at the time of writing the final report, populate `## 5. Clarification Items` in `final-report-template.md` (a single unified table; `Blocks=next-phase` for items the next run cannot start without)
+  - if any blocking input is missing at the time of writing the final report, populate `## 1. Clarification Items` in `final-report-template.md` (a single unified table; `Blocks=next-phase` for items the next run cannot start without)
   - prefer concrete questions whose answers map directly to a routing decision (`bugfix` vs `feature`, `error-analysis` vs `implementation-planning`, etc.). State each option in plain language with one sentence describing what choosing it would mean for the next phase.
   - every clarification row carries a recommended answer + one-line rationale inside the `Expected form` cell; rows that lack a recommendation are rejected as half-formed.
   - **Codebase-first ambiguity resolution (defect rule)**: any ambiguity that can be answered by `Read` / `Grep` / file inspection MUST be resolved that way and recorded with file:line evidence. Writing a clarification row for something the codebase already answers is a defect of this phase.

package/runtime/python/okstra_ctl/clarification_items.py

@@ -1,6 +1,6 @@
-"""Parse the ``## 5. Clarification Items`` table from a final-report markdown.
+"""Parse the ``## 1. Clarification Items`` table from a final-report markdown.
 
-The unified §5 table (introduced when §4.5.9 / §5.1 / §5.2 collapsed into a
+The unified §1 table (introduced when §4.5.9 / §5.1 / §5.2 collapsed into a
 single section) is the canonical home for every clarification an
 implementation-planning run owes the user — decisions, file attachments,
 single data points. Each row carries a ``Blocks`` column whose value picks
@@ -12,7 +12,7 @@ This module exposes one read function for that gate so both
 ``_validate_approved_plan`` (pre-implementation run-prep) and any later
 validator can share the same parsing logic.
 
-Legacy compatibility: reports written before the §5 unification used
+Legacy compatibility: reports written before the §1 unification used
 ``4.5.9 Open Questions`` + ``5.1 Additional Materials`` + ``5.2 Questions
 for the User`` and lacked a ``Blocks`` column. Those reports cannot be
 gate-checked by Blocks; the parser returns ``None`` to signal "schema
@@ -26,13 +26,13 @@ from pathlib import Path
 from typing import Optional
 
 
-SECTION_HEADING_PATTERN = re.compile(r"^##\s+5\.\s+Clarification Items\s*$", re.MULTILINE)
-NEXT_TOP_LEVEL_HEADING_PATTERN = re.compile(r"^##\s+(?!5\.)", re.MULTILINE)
+SECTION_HEADING_PATTERN = re.compile(r"^##\s+1\.\s+Clarification Items\s*$", re.MULTILINE)
+NEXT_TOP_LEVEL_HEADING_PATTERN = re.compile(r"^##\s+(?!1\.)", re.MULTILINE)
 
 
 @dataclass(frozen=True)
 class ClarificationItem:
-    """One row of the §5 table.
+    """One row of the §1 table.
 
     ``raw_*`` fields preserve the exact cell text (after backtick stripping)
     for diagnostics; canonical lowercased versions live in ``blocks`` /
@@ -77,9 +77,9 @@ def _is_separator_row(line: str) -> bool:
     return True
 
 
-def _section_5_slice(report_text: str) -> Optional[str]:
-    """Return the substring spanning the §5 section (heading exclusive of the
-    next ``##`` heading), or None if §5 is absent."""
+def _section_1_slice(report_text: str) -> Optional[str]:
+    """Return the substring spanning the §1 section (heading exclusive of the
+    next ``##`` heading), or None if §1 is absent."""
     start_match = SECTION_HEADING_PATTERN.search(report_text)
     if not start_match:
         return None
@@ -89,7 +89,7 @@ def _section_5_slice(report_text: str) -> Optional[str]:
 
 
 def parse_clarification_items(report_text: str) -> Optional[list[ClarificationItem]]:
-    """Return the list of §5 rows. ``None`` means "no unified §5 table
+    """Return the list of §1 rows. ``None`` means "no unified §1 table
     detected" (legacy report or missing section) — caller must NOT treat
     that as "table is empty".
 
@@ -97,7 +97,7 @@ def parse_clarification_items(report_text: str) -> Optional[list[ClarificationIt
     just the ``- 추가 정보 요청 없음.`` placeholder); that IS a confident
     "no approval-blocking items".
     """
-    section = _section_5_slice(report_text)
+    section = _section_1_slice(report_text)
     if section is None:
         return None
 

package/runtime/python/okstra_ctl/render.py

@@ -75,7 +75,7 @@ def _strip_phase_blocks(text: str, current_phase: str) -> str:
     entirely. When *current_phase* is empty or not one of the four
     block-targetable phases (e.g. `requirements-discovery`,
     `error-analysis`), every block is dropped — correct because none of
-    the `## 4.5` / `4.6` / `4.7` / `4.8` deliverable sections apply
+    the `## 5.5` / `5.6` / `5.7` / `5.8` deliverable sections apply
     there.
 
     Observed (fontsninja-classifier-v2 RD run): the raw final-report

package/runtime/python/okstra_ctl/render_final_report.py

@@ -9,7 +9,7 @@ the canonical user-facing markdown.
 
 Why this exists: prior to v0.32, report-writer-worker wrote the markdown
 directly. Free-form authoring led to silent contract violations — missing
-columns in the Execution Status table, omitted §7 phase-continuation
+columns in the Execution Status table, omitted §4 phase-continuation
 rows, invented ``## Index`` sections. Routing everything through one
 template + schema cuts those failure modes to zero.
 

package/runtime/python/okstra_ctl/report_views.py

@@ -3,9 +3,9 @@
 Single product, single source of truth:
 
 * ``render_html(src_md, *, run_meta)`` — deterministic self-contained
-  HTML renderer for human readers. Sections §5/§6/§7 user-actionable
-  rows (those reachable from §5 ``C-*`` IDs) get embedded ``<form>``
-  controls. §4.6 / §4.7 / §4.8 deliverable sub-sections are explicitly
+  HTML renderer for human readers. Sections §1/§3/§4 user-actionable
+  rows (those reachable from §1 ``C-*`` IDs) get embedded ``<form>``
+  controls. §5.6 / §5.7 / §5.8 deliverable sub-sections are explicitly
   excluded from form attachment — they are read-only deliverables.
 
 User responses are NEVER merged back into the original report. The HTML
@@ -57,7 +57,7 @@ def _strip_leading_frontmatter(text: str) -> str:
 
 from .clarification_items import (
     _is_separator_row,
-    _section_5_slice,
+    _section_1_slice,
     _split_pipe_row,
     parse_clarification_items,
 )
@@ -79,7 +79,7 @@ _LINK_PATTERN = re.compile(r"\[([^\]]+)\]\(([^)]+)\)")
 
 # Sections whose Response-ID-bearing rows must NOT get form attachment
 # (read-only deliverables — see plan §1.4).
-_NO_FORM_SECTION_PREFIXES = ("## 4.6", "### 4.6", "## 4.7", "### 4.7", "## 4.8", "### 4.8")
+_NO_FORM_SECTION_PREFIXES = ("## 5.6", "### 5.6", "## 5.7", "### 5.7", "## 5.8", "### 5.8")
 
 
 @dataclass(frozen=True)
@@ -161,7 +161,7 @@ def _markdown_to_html(
     headings: list[tuple[int, str, str]] = []
     i = 0
     n = len(lines)
-    current_section_path: list[str] = []  # ['## 5. ...', '### 5.1 ...'] etc.
+    current_section_path: list[str] = []  # ['## 1. ...', '### 1.1 ...'] etc.
 
     while i < n:
         line = lines[i]
@@ -394,7 +394,7 @@ class _GroupedSpec:
     value`` metadata cell led by ``headline_col``; the long columns
     (``wide_cols``) each keep their own min-width column.
 
-    ``kind == "clarification"`` additionally re-attaches the §5 form
+    ``kind == "clarification"`` additionally re-attaches the §1 form
     widget to the ``user_input_col`` cell and the ``data-*`` row attrs."""
     headline_col: int
     group_cols: tuple[int, ...]
@@ -407,21 +407,12 @@ class _GroupedSpec:
     user_input_col: int = -1
 
 
-_FOLLOWUP_WIDE_PREFIXES: tuple[str, ...] = ("title", "scope", "reason")
-
-
 def _grouped_table_spec(
     header_cells: list[str], section_path: list[str]
 ) -> Optional[_GroupedSpec]:
-    """Return a ``_GroupedSpec`` for the three wide final-report tables
-    that benefit from the compact layout — Execution Status, §5
-    Clarification Items, §7 Follow-up Tasks — or ``None`` for every other
-    table (which keeps the default per-cell ``td-narrow`` rendering).
-
-    Each table is identified by stable header tokens (the i18n token/cost
-    columns are never used as anchors). ``wide_cols`` lists the long-prose
-    columns that must keep a guaranteed min-width; everything else short
-    collapses into the leading metadata cell."""
+    """Only §1 Clarification Items is grouped in the HTML view (it keeps the
+    interactive form and stays flat in the .md). All other narrative tables are
+    already rendered compactly by the template, so no grouping is applied here."""
     norm = [h.strip() for h in header_cells]
 
     def _spec(headline: int, wide: tuple[int, ...], **kw) -> _GroupedSpec:
@@ -429,12 +420,8 @@ def _grouped_table_spec(
         group = tuple(c for c in range(len(norm)) if c != headline and c not in wide_set)
         return _GroupedSpec(headline_col=headline, group_cols=group, wide_cols=wide, **kw)
 
-    # Execution Status by Agent — Agent … Summary of Key Findings.
-    if len(norm) >= 3 and norm[0] == "Agent" and norm[-1] == "Summary of Key Findings":
-        return _spec(0, (len(norm) - 1,), kind="plain")
-
-    # §5 Clarification Items — keep the interactive form, but collapse the
-    # short ID/Kind/Status/… columns and widen Statement + User input.
+    # §1 Clarification Items — keep the interactive form, and widen the three
+    # long-prose columns (Expected form is prose too, not a code column).
     if (
         any("Clarification Items" in h for h in section_path)
         and not _section_forbids_form(section_path)
@@ -444,9 +431,15 @@ def _grouped_table_spec(
     ):
         statement_col = next(i for i, h in enumerate(norm) if h.startswith("Statement"))
         user_input_col = norm.index("User input")
+        expected_col = next(
+            (i for i, h in enumerate(norm) if h.startswith("Expected form")), -1
+        )
+        wide_cols = tuple(
+            c for c in (expected_col, statement_col, user_input_col) if c >= 0
+        )
         return _spec(
             norm.index("ID"),
-            (statement_col, user_input_col),
+            wide_cols,
             kind="clarification",
             id_col=norm.index("ID"),
             kind_col=norm.index("Kind") if "Kind" in norm else -1,
@@ -455,16 +448,6 @@ def _grouped_table_spec(
             user_input_col=user_input_col,
         )
 
-    # §7 Follow-up Tasks — widen Title / Scope / Reason, collapse the rest.
-    if any("Follow-up Tasks" in h for h in section_path) and "ID" in norm:
-        wide = tuple(
-            i
-            for i, h in enumerate(norm)
-            if any(h.lower().startswith(p) for p in _FOLLOWUP_WIDE_PREFIXES)
-        )
-        if wide:
-            return _spec(norm.index("ID"), wide, kind="plain")
-
     return None
 
 
@@ -491,7 +474,7 @@ def _grouped_meta_cell(
 def _grouped_clarification_row(
     row: list[str], spec: _GroupedSpec
 ) -> tuple[str, str]:
-    """Return ``(tr_attrs, wide_cells_html)`` for one §5 row, re-attaching
+    """Return ``(tr_attrs, wide_cells_html)`` for one §1 row, re-attaching
     the form widget + ``data-*`` attrs to ``C-\\d+`` rows exactly as the
     non-grouped path does."""
     rid = row[spec.id_col] if 0 <= spec.id_col < len(row) else ""
@@ -768,6 +751,10 @@ def _inline(text: str) -> str:
     out = _LINK_PATTERN.sub(
         lambda m: f'<a href="{m.group(2)}">{m.group(1)}</a>', out
     )
+    # Preserve explicit <br> line breaks used inside compact meta cells (the
+    # markdown source intentionally stacks short fields with <br>). html.escape
+    # above turned them into &lt;br&gt;; restore the tag.
+    out = out.replace("&lt;br&gt;", "<br>").replace("&lt;br/&gt;", "<br>").replace("&lt;br /&gt;", "<br>")
     return out
 
 
@@ -835,7 +822,7 @@ def serialize_user_response(
 # --------------------------------------------------------------------------- #
 
 def report_has_clarification_items(src_md: str) -> bool:
-    """True when the final-report MD has at least one §5 ``C-*``
+    """True when the final-report MD has at least one §1``C-*``
     clarification row. This is the single predicate that gates HTML-view
     generation: the self-contained html's only value over the markdown is
     the embedded ``<form>`` widgets for those rows, so a clarification-free
@@ -857,7 +844,7 @@ def render_html_view(
 ) -> Path | None:
     """Write ``<stem>.html`` next to ``src_md_path`` and return its path,
     or return ``None`` when generation is skipped because the report has
-    no §5 clarification rows (see ``report_has_clarification_items``).
+    no §1 clarification rows (see ``report_has_clarification_items``).
     Idempotent — overwrites an existing html sibling, and removes a stale
     one when a previously-clarification-bearing report no longer has rows."""
     src_text = src_md_path.read_text(encoding="utf-8")

package/runtime/python/okstra_ctl/run.py

@@ -175,14 +175,14 @@ def _validate_approved_plan(path: str) -> None:
             f"approved plan is not yet approved (frontmatter `approved: {m.group(1)}`): {path}\n"
             "  open the report and change the frontmatter line to `approved: true`, "
             "or re-run okstra with `--approve` to flip it from the CLI.\n"
-            "  resolve any `Blocks=approval` rows in `## 5. Clarification Items` first."
+            "  resolve any `Blocks=approval` rows in `## 1. Clarification Items` first."
         )
-    # frontmatter approved == true 상태. §5 Clarification Items 의
+    # frontmatter approved == true 상태. §1 Clarification Items 의
     # Blocks=approval 행이 아직 open/answered 면 승인을 무효화한다.
     blockers = unresolved_approval_blockers(body)
     if blockers:
         lines = [
-            f"approved plan frontmatter has `approved: true` but §5 has {len(blockers)} "
+            f"approved plan frontmatter has `approved: true` but §1 has {len(blockers)} "
             f"unresolved `Blocks=approval` row(s); resolve them or mark them obsolete first:",
         ]
         for b in blockers:

package/runtime/python/okstra_ctl/wizard.py

@@ -205,6 +205,28 @@ S_CONFIRM = "confirm"
 S_EDIT_TARGET = "edit_target"
 S_DONE = "done"
 
+# ---- 멀티탭 배치 프롬프트 그룹 (방출 계층 전용) ----
+# 그룹 id 는 S_* 가 아니므로 prompts JSON SOT / step-id 동기화 검사 대상이 아니다.
+GROUP_MODELS = "models"
+GROUP_OPTIONS = "options"
+GROUP_MAX_TABS = 4  # AskUserQuestion 의 질문(탭) 수 한도
+
+# 멤버는 모두 서로 의존이 없는 단일선택 픽 step 이어야 한다.
+# *_TEXT 후속 / workers_override / pr_template_scope 는 의존성 때문에 개별 유지.
+PROMPT_GROUPS: dict[str, tuple[str, ...]] = {
+    GROUP_MODELS: (S_LEAD_MODEL, S_EXECUTOR_MODEL, S_CLAUDE_MODEL,
+                   S_CODEX_MODEL, S_GEMINI_MODEL, S_REPORT_WRITER_MODEL),
+    GROUP_OPTIONS: (S_DIRECTIVE_PICK, S_RELATED_TASKS_PICK,
+                    S_CLARIFICATION_PICK, S_PR_TEMPLATE_PICK),
+}
+GROUP_LABELS: dict[str, str] = {
+    GROUP_MODELS: "모델 선택 (탭별로 선택)",
+    GROUP_OPTIONS: "추가 옵션 (탭별로 선택)",
+}
+_STEP_TO_GROUP: dict[str, str] = {
+    sid: gid for gid, ids in PROMPT_GROUPS.items() for sid in ids
+}
+
 
 # ---- Data types ----------------------------------------------------------
 
@@ -305,9 +327,11 @@ class Prompt:
     help: str = ""
     echo_template: str = ""  # e.g. "task-group: {value}"
     multi: bool = False  # only meaningful when kind == "pick"
+    # only meaningful when kind == "pick_group": one entry per AskUserQuestion tab
+    questions: list["Prompt"] = field(default_factory=list)
 
     def to_json(self) -> dict[str, Any]:
-        return {
+        out = {
             "step": self.step,
             "kind": self.kind,
             "label": self.label,
@@ -316,6 +340,14 @@ class Prompt:
             "echoTemplate": self.echo_template,
             "multi": self.multi,
         }
+        if self.kind == "pick_group":
+            out["questions"] = [
+                {"step": q.step, "label": q.label,
+                 "options": [asdict(o) for o in q.options],
+                 "multi": q.multi}
+                for q in self.questions
+            ]
+        return out
 
 
 class WizardError(Exception):
@@ -373,12 +405,12 @@ def _validate_approved_plan(path_str: str, project_root: Path) -> Path:
             "  edit the report and change the line to `approved: true`, or re-run "
             "okstra with `--approve` to flip it from the CLI."
         )
-    # frontmatter approved == true 라도 §5 의 Blocks=approval 행이 미해결이면
+    # frontmatter approved == true 라도 §1 의 Blocks=approval 행이 미해결이면
     # 승인이 무효 — prepare_task_bundle 의 _validate_approved_plan 과 동일 규약.
     blockers = unresolved_approval_blockers(body)
     if blockers:
         lines = [
-            f"approved plan frontmatter has `approved: true` but §5 has {len(blockers)} "
+            f"approved plan frontmatter has `approved: true` but §1 has {len(blockers)} "
             f"unresolved `Blocks=approval` row(s); resolve them or mark them obsolete first:",
         ]
         for b in blockers:
@@ -2218,6 +2250,30 @@ def init_state(
     )
 
 
+def _build_group_prompt(state: WizardState, group_id: str) -> Prompt:
+    """그룹의 적용가능·미답변 픽 멤버를 최대 GROUP_MAX_TABS 개 모은다.
+
+    멤버가 1개뿐이면 멀티탭 UI가 불필요하므로 그 멤버의 평범한 픽을 반환한다.
+    호출부(next_prompt)는 적용 가능한 멤버가 최소 1개일 때만 진입하므로 빈 그룹은
+    도달 불가다.
+    """
+    members: list[Prompt] = []
+    for sid in PROMPT_GROUPS[group_id]:
+        if sid in state.answered:
+            continue
+        step = STEP_BY_ID[sid]
+        if not step.applies(state):
+            continue
+        members.append(step.build(state))
+        if len(members) >= GROUP_MAX_TABS:
+            break
+    assert members, f"group {group_id!r} reached with no applicable members"
+    if len(members) == 1:
+        return members[0]
+    return Prompt(step=group_id, kind="pick_group",
+                  label=GROUP_LABELS[group_id], questions=members)
+
+
 def next_prompt(state: WizardState) -> Prompt:
     if state.confirmed:
         return Prompt(step=S_DONE, kind="done")
@@ -2225,10 +2281,39 @@ def next_prompt(state: WizardState) -> Prompt:
         if step.id in state.answered:
             continue
         if step.applies(state):
+            group_id = _STEP_TO_GROUP.get(step.id)
+            if group_id is not None:
+                return _build_group_prompt(state, group_id)
             return step.build(state)
     return Prompt(step=S_DONE, kind="done")
 
 
+def _submit_group(state: WizardState, prompt: Prompt, value: str) -> dict[str, Any]:
+    """pick_group 답(JSON 객체)을 각 멤버 submit() 으로 라우팅한다.
+
+    멤버 submit 이 WizardError 를 던지면 그대로 전파되어 같은 그룹을 재-프롬프트한다.
+    answered 마킹은 모든 멤버 submit 이 통과한 뒤에만 일괄 수행한다(answered 단위의
+    전부-아니면-전무). 개별 멤버가 변경한 state 필드는 롤백하지 않지만, 재-프롬프트 시
+    같은 그룹이 다시 나와 사용자 입력으로 덮어쓰므로 무해하다.
+    """
+    try:
+        answers = json.loads(value or "{}")
+    except json.JSONDecodeError as exc:
+        raise WizardError(f"pick_group answer must be a JSON object: {exc}")
+    if not isinstance(answers, dict):
+        raise WizardError("pick_group answer must be a JSON object")
+    echoes: list[str] = []
+    for q in prompt.questions:
+        echo = STEP_BY_ID[q.step].submit(state, str(answers.get(q.step, "") or ""))
+        if echo:
+            echoes.append(echo)
+    for q in prompt.questions:
+        if q.step not in state.answered:
+            state.answered.append(q.step)
+    nxt = next_prompt(state)
+    return {"echo": "; ".join(echoes), "next": nxt.to_json()}
+
+
 def submit(state: WizardState, value: str) -> dict[str, Any]:
     """Validate the answer for the *currently active* step and advance.
 
@@ -2238,6 +2323,8 @@ def submit(state: WizardState, value: str) -> dict[str, Any]:
     prompt = next_prompt(state)
     if prompt.kind == "done":
         return {"echo": "", "next": prompt.to_json()}
+    if prompt.kind == "pick_group":
+        return _submit_group(state, prompt, value)
     step = STEP_BY_ID[prompt.step]
     echo = step.submit(state, value or "")
     if prompt.step not in state.answered:

package/runtime/python/okstra_ctl/workflow.py

@@ -87,7 +87,7 @@ PHASE_RULES: dict[str, dict[str, str]] = {
             "  - trade-off matrix across options (complexity, risk, reversibility, test cost, rollout cost) and recommended option with rationale tied to isolation / single-responsibility / YAGNI principles\n"
             "  - bite-sized stepwise execution order for the recommended option (each step ~2-5 min, exact file paths and commands, TDD ordering when applicable, no placeholders)\n"
             "  - dependency / migration risk assessment, validation checklist (pre / mid / post with exact commands), rollback strategy with revert path and trigger signal\n"
-            "  - every unresolved ambiguity registered as a `Blocks=approval` row in the `## 5. Clarification Items` table (do NOT create a separate `Open Questions` block under `4.5.x` — the unified table is the single home)\n"
+            "  - every unresolved ambiguity registered as a `Blocks=approval` row in the `## 1. Clarification Items` table (do NOT create a separate `Open Questions` block under `5.5.x` — the unified table is the single home)\n"
             "  - YAML frontmatter line `approved: false` awaiting human flip to `true`\n"
             "  - self-review confirmation (spec coverage, placeholder scan, internal consistency, ambiguity, scope)"
         ),