okstra 0.186.1 → 0.186.3

package/docs/architecture.md

@@ -867,9 +867,9 @@ The manifest-provided `lead-events-*.jsonl` file is the canonical record for str
 
 The shared `okstra report-finalize` entrypoint reads canonical activity before translation source checking. Under contract v3 its in-process `project-activity` step assembles the report, filtering events by run identity and validating activity ID order before `agentActivity[]` is published. A historical v2 manifest retains the in-place projection path. For a non-English report, the lead runs `token-usage`, `project-activity`, and `check-source` before translator dispatch, then resumes at `render-views` after the translation sidecar exists. Conformance compares the resulting `agentActivity[]` IDs, order, and core fields with the canonical events for every lead host.
 
-Approval blockers use `open`, `answered`, `resolved`, and `obsolete`. Both `open` and `answered` block approval because `answered` means that a user response exists but has not passed application and checking. A response sidecar hides an answered row from the next user-input prompt, but it does not change the approval status of an existing report.
+Approval blockers use `open`, `answered`, `resolved`, and `obsolete`. `open` blocks until the user judges. `answered` with `accept-risk` / `select` / `answer` does not block approval or the next phase; the DISAGREE votes stay on the plan item as evidence. A response sidecar with a proceeding disposition unblocks the same way. `request-revision` and `reject` still withhold the next phase.
 
-An approval row classifies its cause as `user-decision`, `noncritical-dissent`, or `correctness-critical`. A `noncritical-dissent` row can become `passed-with-dissent` only after the user explicitly selects `accept-risk` and the report records the related activity evidence. A `correctness-critical` row cannot use `accept-risk`; it becomes resolved only after the plan is revised and the affected target passes re-verification.
+An approval row classifies its cause as `user-decision`, `noncritical-dissent`, or `correctness-critical`. `accept-risk` is available to all three: it ends the gate and keeps the dissent on the record for later stages. `correctness-critical` can still take `request-revision` when the user wants the plan corrected and re-verified.
 
 ## Final report views (HTML)
 
@@ -887,7 +887,7 @@ Entry points:
 - Python routing references: `scripts/okstra_ctl/report_views.py` owns the version split; `scripts/okstra_ctl/report_html/router.py` maps all v2 task types to dedicated view-model builders and templates. The HTML JavaScript response serializer remains byte-identical to Python `serialize_user_response`.
 - CLI: `scripts/okstra-render-report-views.py <final-report.data.json|final-report.md>` or delegated Node wrapper `bin/okstra render-views <path>`.
 - Validation: `validators/validate-report-views.py` checks schema/source/template digests, required human fields, form controls, external assets, SVG/table ID parity, and Response ID parity. The v2 renderer rejects an unknown task type instead of falling back to a generic page.
-- User-response sidecar schema source of truth: `templates/reports/user-response.template.md`. The in-session skill reads `okstra user-response show-view`, then the cited `path:line` artifacts and linked plan items that view lists, before asking. The recorded answer still comes from `options[]` via `--option-number`. Task pick, each clarification, and the record confirmation use the current host's native question tool from the relay `native-single` mapping (`AskUserQuestion`, `ask_user_question`, or `request_user_input`). A numbered list is only the fallback when that tool is missing or the option count misses `nativeLimits`.
+- User-response sidecar schema source of truth: `templates/reports/user-response.template.md`. The in-session skill reads `okstra user-response show-view`, then the cited `path:line` artifacts and linked plan items that view lists, before asking. The recorded answer still comes from `options[]` via `--option-number`. Task pick, each clarification, and the record confirmation use the current host's native question tool from the relay `native-single` mapping (`AskUserQuestion`, `ask_user_question`, or `request_user_input`). The picker shows those choices only — it does not append `Enter directly`; custom text uses the host free-text row. A numbered list is only the fallback when that tool is missing or the option count misses `nativeLimits`.
 - In-run user confirmation before an approval blocker follows the same briefing order and the same host picker: the lead investigates cited plan items, worker findings, and files, then asks through the adapter `prompt_user` mapping (`prompts/lead/okstra-lead-contract.md`).
 
 Generating a view never modifies the original final-report MD.

package/docs/for-ai/skills/okstra-run.md

@@ -221,7 +221,7 @@ Inform the user on one line.
 Took over as Okstra lead (`<host-runtime>`) for `<taskKey>` (`<task-type>`). Run dir: `<RUN_DIR_RELATIVE_PATH>`. Beginning Phase 1 (context loading).
 ```
 
-For a single-element chain, the end of Step 6 is the end of the run. Step 7 below applies only when the `chain-stages` CSV has 2 or more elements. After an `implementation-planning` run, if `workflow.awaitingApproval` is true, tell the user to approve the plan; do not start another planning run. If the pointer is `blocked`, send the user to `okstra-user-response` first.
+For a single-element chain, the end of Step 6 is the end of the run. Step 7 below applies only when the `chain-stages` CSV has 2 or more elements. When the run is over, close with the user's next action — one command they can run now. A prohibition is not a next action. After `implementation-planning`: open approval blockers → `/okstra-user-response`; a recorded `accept-risk` / `select` / `answer` is not an open blocker; awaiting approval → `/okstra-run` → `implementation` or `--approve` (do not start another planning run); `validate-run` failed → one-line cause then `/okstra-run` or `/okstra-inspect recap`; pointer `ready` → `/okstra-run` for that phase.
 
 ## implementation unattended chaining (chain-stages)
 

package/docs/for-ai/skills/okstra-user-response.md

@@ -27,8 +27,8 @@ The legacy `list` and `show` JSON commands remain for automation compatibility.
 ## Flow
 
 1. Run `okstra preflight --runtime <host-runtime>` for the current harness. On `Okstra preflight: failed`, show `Reason` and `Recovery`, then stop. On `Okstra preflight: ready`, carry `Project root`, `Project ID`, `Runtime`, and `Relay contract`, then run `okstra paths --field home`.
-2. Read the relay `Wizard interaction relay` JSON. When `native-single` is available and the option count fits `nativeLimits`, call `interactions.native-single.function` (`AskUserQuestion` / `ask_user_question` / `request_user_input` from that field). Do not print a numbered list in chat while the native tool is available. Otherwise render a numbered Markdown list. Do not substitute one host function name for another.
-3. Select a task from `list-view` through that host picker.
+2. Read the relay `Wizard interaction relay` JSON. When `native-single` is available and the option count fits `nativeLimits`, call `interactions.native-single.function` (`AskUserQuestion` / `ask_user_question` / `request_user_input` from that field). Do not print a numbered list in chat while the native tool is available. Otherwise render a numbered Markdown list. Do not substitute one host function name for another. Pass only the choices this step already owns. Do not append `Enter directly`. Claude Other, Grok `z`, and Codex's free-form row are `Enters an answer`; on a numbered list, so is a next message that is not a listed label or its 1-based number. Do not ask a second question for the custom value.
+3. Select a task from `list-view` through that host picker. A host free-text row or unmatched next message is the report path or task key.
 4. Read only `show-view --report <reportPath> --project-root <projectRoot>` for report facts. The view also prints `Why asked`, `Linked plan items`, and `Cited artifacts`.
 5. Read every cited `path:line` under the project root and every linked plan-item definition before asking. Do not search beyond that list. Investigation explains; it never changes `options[]`.
 6. Ask one open clarification at a time in the user's language through the host picker. The question body is why, what is already decided, the fork, and what stays blocked. Do not lead with `Kind`, `Blocks`, `Expected form`, or `C-NNN`. Keep the row id in parentheses at the end.

package/docs/project-structure-overview.md

@@ -277,6 +277,7 @@ Important modules:
 | `report_assembly.py` | Validates the role-owned report inputs and publishes the contract 3.0 record once (assembled in a temp file, then atomically promoted); a bad input aborts with owner / artifact path / field path / reason and preserves the existing `data.json` |
 | `report_projections.py` | Pure projections turning role-owned execution inputs (agent activity, execution status, convergence, design, token usage) into canonical final-report fragments |
 | `report_narrative.py` | Lossless read/write contract for the report-writer-owned narrative Markdown (`report-narrative-<task-type>-<seq>.md`) — the only artifact the report-writer authors under contract 3.0 |
+| `report_synthesis_packet.py` | Builds the frozen, read-only synthesis input packet handed to the report-writer — collects each source's label / owner / path / content digest into `report-writer-synthesis-packet-<task-type>-<seq>.{json,md}`, materialized at dispatch by `initial_prompt_materialization.py` so the writer synthesizes from a byte-stable snapshot. `report_assembly.py` calls `verify_report_synthesis_packet_sources` at publish time so a drifted source aborts the record; schema is `schemas/report-synthesis-packet-v1.0.schema.json` |
 | `approval_decisions.py` | Lead-owned approval-decision input ledger — `disposition` (`select`/`accept-risk`/`request-revision`/`reject`), reach, scope effect, and classification invariants (`correctness-critical`/`noncritical-dissent`/`user-decision`) |
 | `design_snapshot.py` | Builds the design-surface-detector-owned snapshot from the report narrative — reproducible design surfaces plus conservative `PREP-NNN` preparation items (delegates surface detection to `design_surfaces.py`) |
 | `report_markdown.py` | Schema-ordered Markdown serialisation of a data.json subtree for the full reading copy — headings, tables for uniform row sets, prose for narrative fields; field order read from the schema, not from the mapping |
@@ -696,4 +697,4 @@ Clarifications now live in the unified `## 1. Clarification Items` table. Deprec
 
 ---
 
-*Updated: 2026-08-23 · Source of truth checked against `package.json`, `bin/okstra`, `src/cli-registry.mts`, `src/lib/skill-catalog.mts`, `tools/build.mjs`, `scripts/`, `skills/`, `agents/`, `templates/`, `schemas/`, `validators/`, and tests.*
+*Updated: 2026-08-24 · Source of truth checked against `package.json`, `bin/okstra`, `src/cli-registry.mts`, `src/lib/skill-catalog.mts`, `tools/build.mjs`, `scripts/`, `skills/`, `agents/`, `templates/`, `schemas/`, `validators/`, and tests.*

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "okstra",
-  "version": "0.186.1",
+  "version": "0.186.3",
   "description": "Host-aware multi-provider cross-verification orchestrator runtime and agent skills.",
   "license": "MIT",
   "author": "devonshin",

package/runtime/BUILD.json

@@ -1,5 +1,5 @@
 {
-  "package": "0.186.1",
-  "builtAt": "2026-08-23T17:23:36.757Z",
+  "package": "0.186.3",
+  "builtAt": "2026-08-24T04:42:58.072Z",
   "repoRoot": "/home/runner/work/okstra/okstra"
 }

package/runtime/prompts/lead/okstra-lead-contract.md

@@ -139,16 +139,17 @@ The sequence is fixed:
 4. On an answer — record the raw text in the row's `userInput`, set `status: answered` and `userConfirmation: asked-and-answered`, and apply the selected disposition in this run.
 5. Only when asking fails does the row stay open: `asked-awaiting` when the user has not answered, `deferred-no-interactive-session` when this run has no user to ask.
 
-For report contract v3 `implementation-planning`, record active approval decisions only through `okstra approval-decision`; report assembly derives each report row's status, resolution, and backtraces from that lead-owned ledger plus the activity ledger. Classify a user-owned selection as `user-decision`, a surviving non-correctness majority disagreement as `noncritical-dissent`, and a cited path/symbol mismatch, `P-Req-*` coverage mismatch, or independent Requirement Coverage blocker as `correctness-critical`. `select` is limited to `user-decision`, `accept-risk` is limited to `noncritical-dissent`, and `request-revision` / `reject` are available to all three classifications. `correctness-critical` never offers or records `accept-risk`. Contract v2 remains read-only compatible; do not create a new v2 report. **Enforced:** `scripts/okstra_ctl/approval_decisions.py` rejects invalid option/disposition combinations, and `validators/validate-run.py` `_validate_v3_approval_context` recomputes report backtraces.
+For report contract v3 `implementation-planning`, record active approval decisions only through `okstra approval-decision`; report assembly derives each report row's status, resolution, and backtraces from that lead-owned ledger plus the activity ledger. Classify a user-owned selection as `user-decision`, a surviving non-correctness majority disagreement as `noncritical-dissent`, and a cited path/symbol mismatch, `P-Req-*` coverage mismatch, or independent Requirement Coverage blocker as `correctness-critical`. `select` is limited to `user-decision`. `accept-risk` is available to all three classifications: it ends the gate, keeps the DISAGREE votes and the clarification row as evidence, and later stages read that record. `request-revision` / `reject` are available to all three and still withhold the next phase. Contract v2 remains read-only compatible; do not create a new v2 report. **Enforced:** `scripts/okstra_ctl/approval_decisions.py` rejects invalid option/disposition combinations, and `validators/validate-run.py` `_validate_v3_approval_context` recomputes report backtraces.
 
 The approval state transitions are fixed:
 
 - `open → answered` when the raw user response is recorded
-- `answered → resolved` only after the selected disposition is applied and its checks pass
-- `answered → open` when application or checking fails
+- `answered → resolved` after the selected disposition is applied, when that work actually completed
 - `open → obsolete` only when a plan change removes the question
 
-`open` and `answered` continue to block approval; only `resolved` and `obsolete` are non-blocking. `user-decision` resolves after the choice is applied and structure / extraction / Requirement Coverage checks pass. `noncritical-dissent` resolves only after an explicit `accept-risk` with non-empty user text and activity-backed checks. `correctness-critical` resolves only after the correction's targeted re-verification records `AGREE` or an acceptable `SUPPLEMENT` for every linked item and no independent coverage blocker remains. A user-directed correction does not consume the automatic self-fix limit, and a verification failure after that correction does not restart the automatic loop.
+Do not move `answered` back to `open` because a check failed. The user's choice stands. Record the failed check on the row; later stages still see the DISAGREE votes.
+
+`open` blocks until the user judges. `answered` with `select` / `accept-risk` / `answer`, `resolved`, and `obsolete` do not block approval or the next phase. `request-revision` and `reject` still withhold the next phase. `accept-risk` does not require re-verification `AGREE`. The worker votes stay on the plan item so a later stage can still see the dissent. **Enforced:** `scripts/okstra_ctl/clarification_items.py` `row_blocks_progress`, `validators/validate-run.py` `_user_accepted_plan_item_ids`.
 
 When a terminal row preserves a pre-correction dissent classification, keep superseded votes in `state/plan-body-verification-implementation-planning-<seq>.json`. Activities that implement or check the decision record the exact `C-NNN` in `clarificationRefs` and the affected `P-*` identifiers in `planItemIds`. Report assembly verifies that every resolution `checkRefs` value names an existing activity and derives each plan item's `clarificationRefs`; the lead never copies those references into `approvalContext`. A corrected coverage-only blocker keeps its `C-NNN` in the non-blocking Requirement Coverage row's `decisionRefs`. An `obsolete` row is invalid while its disagreement or coverage blocker remains active in the current plan. **Enforced:** `scripts/okstra_ctl/report_assembly.py` `_clarification_row` / `_attach_plan_backlinks` and `validators/validate-run.py` `_validate_v3_approval_context`.
 
@@ -425,7 +426,19 @@ jq -s 'group_by(.errorType) | map({type: .[0].errorType, count: length})' <runDi
 
 The errors log is informational. Its presence/absence does not affect the final verdict. Do not block report writing on it.
 
-After persistence, reply briefly in the resolved Report Language with: completion status, the human report path, the report record path, team-state path, validator result, resume command path, any remaining blocker. For `implementation-planning` that left `workflow.awaitingApproval` true, the first sentence after the task identity tells the user to approve this plan (`okstra-run` → `implementation`, which asks `approve_plan_confirm`, or `--approve`) and does not propose another planning run. For a `blocked` pointer after planning, the first sentence names the open `C-NNN` ids and sends the user to `okstra-user-response`; do not start implementation and do not re-run planning until those answers exist. **Lead this reply with the run's task identity** — state `<task-group>/<task-id>` (or the full `taskKey`) first, so the reader knows which task the reply is about. **Every run-artifact path in this reply MUST be task-qualified** — report the human report as `.okstra/tasks/<task-group>/<task-id>/runs/<task-type>/reports/final-report-<task-type>-<seq>.html` rooted at the task bundle, NOT the bare `runs/<task-type>/reports/...` form (byte-for-byte identical across every task of the same task-type, so it cannot identify the task). Under that, cite the report record (`.data.json`) and one line to render the full reading copy: `okstra render-final-report <task-qualified data.json>`. The same task-qualified rule applies to the team-state path, resume command path, and any other run-artifact path this reply cites.
+After persistence, reply briefly in the resolved Report Language. **Lead this reply with the run's task identity** — state `<task-group>/<task-id>` (or the full `taskKey`) first. Then: completion status, the task-qualified human report path, the report record path, validator result, any remaining blocker. **Close with the user's next action** — one command they can run now. A prohibition (`do not start implementation`) is not a next action. A status dump is not a close.
+
+Pick the next action from this table; the first matching row wins:
+
+- Open `blocks: approval` rows → `/okstra-user-response` (name the `C-NNN` ids). Do not start implementation until those answers exist. An `accept-risk` / `select` / `answer` already recorded is not an open blocker.
+- `workflow.awaitingApproval` is true → `/okstra-run` → `implementation` (asks `approve_plan_confirm`) or `--approve`. Do not propose another planning run.
+- Phase 7 `validate-run` failed → one line naming the blocking cause, then `/okstra-run` to re-run this phase with the recorded sidecar, or `/okstra-inspect recap` if the resume flags are unknown.
+- Pointer `status: ready` → `/okstra-run` for that `phase`.
+- Otherwise → `/okstra-inspect status` for this task.
+
+When the host native picker is available and two of those rows could apply, ask with that picker (recommended first). Do not end the turn after the status dump.
+
+**Every run-artifact path in this reply MUST be task-qualified** — report the human report as `.okstra/tasks/<task-group>/<task-id>/runs/<task-type>/reports/final-report-<task-type>-<seq>.html` rooted at the task bundle, NOT the bare `runs/<task-type>/reports/...` form (byte-for-byte identical across every task of the same task-type, so it cannot identify the task). Under that, cite the report record (`.data.json`) and one line to render the full reading copy: `okstra render-final-report <task-qualified data.json>`. The same task-qualified rule applies to the team-state path, resume command path, and any other run-artifact path this reply cites.
 
 ## Run-scoped worker-resource lifecycle
 

package/runtime/prompts/lead/plan-body-verification.md

@@ -430,18 +430,18 @@ round before any host or provider process starts.
    - `Blocks=approval`
    - the report record's `planItems[].clarificationRefs[]` reaching that `C-<N>`. Under contract v3 the report record carries the **plural** field and the v3.0 schema forbids `clarificationId` on a plan item; report assembly derives the refs from the activity ledger's `clarificationRefs[]` + `planItemIds[]`, so record the decision through `okstra approval-decision` rather than writing the link by hand. The lead-owned state file keeps the singular `clarificationId`. `validators/validate-run.py` `_validate_plan_body_clarification_matching` recomputes each item's class and fails when a majority-disagree item reaches no clarification, or reaches one that is missing or not `blocks: approval`.
    - set `approvalContext.classification` to `user-decision` for a majority `needs-user-input` item, `correctness-critical` for `DISAGREE(a)`, `DISAGREE(f)` on `P-Req-*`, or an independent Requirement Coverage blocker, and `noncritical-dissent` for another surviving majority disagreement.
-   - record the decision through `okstra approval-decision open`. Each option carries `disposition`, exactly one `reach`, and optional `scopeEffects`. The activity ledger carries affected `planItemIds` and `clarificationRefs`; the approval row never copies those backtrace IDs. `select` is allowed only for `user-decision`, `accept-risk` only for `noncritical-dissent`, and `request-revision` / `reject` for any classification. `correctness-critical` never offers or records `accept-risk`. **Enforced:** `scripts/okstra_ctl/approval_decisions.py` and report assembly.
-   - **Self-fix exhaustion is not risk acceptance.** A `noncritical-dissent` item remains blocking until the user explicitly selects `accept-risk`. Record the user's non-empty original text and existing activity check references through `okstra approval-decision resolve`; report assembly derives the report `resolution`.
-   - **Correctness-critical defects cannot be waived.** After the user-directed correction, targeted re-verification of every linked item MUST record only `AGREE` or an acceptable `SUPPLEMENT`, and any independent Requirement Coverage blocker MUST be removed before the row becomes `resolved`. A `DISAGREE` or `verification-error` returns it to `open`. **Enforced:** `validators/validate-run.py` `_validate_correctness_resolution`.
+   - record the decision through `okstra approval-decision open`. Each option carries `disposition`, exactly one `reach`, and optional `scopeEffects`. The activity ledger carries affected `planItemIds` and `clarificationRefs`; the approval row never copies those backtrace IDs. `select` is allowed only for `user-decision`. `accept-risk` is allowed for every classification, including `correctness-critical`: it ends the gate and keeps the DISAGREE votes as evidence. `request-revision` / `reject` withhold the next phase. **Enforced:** `scripts/okstra_ctl/approval_decisions.py` and report assembly.
+   - **Self-fix exhaustion is not risk acceptance.** A remaining item stays blocking until the user selects `accept-risk`, `select`, or `answer`. Record the user's non-empty original text. Do not require a second verification round to honour `accept-risk`.
+   - **Correctness-critical `accept-risk` does not rewrite the votes.** The linked items keep their DISAGREE (or remaining dissent) so a later stage can still see them. `request-revision` is the path that corrects the plan and re-verifies. **Enforced:** `validators/validate-run.py` `_user_accepted_plan_item_ids` / `_validate_correctness_resolution`.
    - When a correctness-critical `planner-fixable` item is promoted, its `Statement` MUST state "planner self-fix attempted but unresolved" and name the stop reason. `validators/validate-run.py` `_validate_self_fix_before_clarification` fails when a planner-fixable majority item is promoted while the budget is not exhausted — it requires `selfFixRoundsApplied >= 1` **and** `selfFixStopReason` in `{no-progress, max-rounds-reached}`, so neither `all-resolved` nor `not-attempted` can excuse a promotion.
    - Approval state transitions are fixed:
      - `open → answered` when the raw user response is recorded
      - `answered → resolved` only after the selected disposition is applied and its checks pass
      - `answered → open` when application or checking fails
      - `open → obsolete` only when a plan change removes the question
-     `open` and `answered` continue to block approval; only `resolved` and `obsolete` are non-blocking. A user-directed correction does not consume the automatic self-fix limit, and a failed check does not restart the automatic loop.
+     `open` blocks until the user judges. `answered` with a proceeding disposition (`accept-risk` / `select` / `answer`) does not block. `request-revision` / `reject` still withhold the next phase. A user-directed correction does not consume the automatic self-fix limit, and a failed check does not restart the automatic loop or reopen the row.
    - A terminal row preserves its original dissent classification only from the convergence-owned state history. Every `user-decision-required` / `user-decision-evaluated` activity cites the row's `C-NNN` in `clarificationRefs` and affected plan items in `planItemIds`. A resolved decision names only existing `A-NNN` checks. Report assembly validates those links and derives the report backtraces; it does not accept copied IDs from the approval ledger. When an independent coverage-only blocker is corrected, keep the `C-NNN` in the non-blocking Requirement Coverage row's `decisionRefs`. `obsolete` is valid only after current evidence shows that the question or blocker disappeared.
-9. Approval lives in the report record `frontmatter.approved` field — there is no in-body marker line. The user may set it to `true` (via `--approve` or the in-session wizard) only when the Gate result is `passed` or `passed-with-dissent`. **Enforced:** run-prep (`scripts/okstra_ctl/run.py` `_validate_approved_plan`) fail-closes an `approved: true` plan whose record carries a blocking `gateResult` or an open/answered `Blocks: approval` clarification row, and `validators/validate-run.py` `_validate_plan_body_gate_recompute` rejects a declared `gateResult` healthier than the recorded votes.
+9. Approval lives in the report record `frontmatter.approved` field — there is no in-body marker line. The user may set it to `true` (via `--approve` or the in-session wizard) when remaining `Blocks=approval` rows are user-proceeded (`accept-risk` / `select` / `answer`) even if the recorded `gateResult` is still `blocked-by-disagreement`. `aborted-non-result` still withholds approval. **Enforced:** run-prep (`scripts/okstra_ctl/run.py` `_validate_approved_plan` / `_blocking_gate_survives_user_decision`) and `validators/validate-run.py` `_validate_plan_body_gate_recompute`.
 
 ## `plan-body-verification-<task-type>-<seq>.json` schema
 

package/runtime/prompts/lead/report-writer.md

@@ -112,7 +112,7 @@ Never dispatch the translator before report assembly and `check-source`. For a n
 
 `workflow.nextRecommendedPhase` has `phase`, `status`, and `rationale`. The status vocabulary is `ready`, `pending`, `blocked`, and `terminal`.
 
-`phase` is non-empty only for an authored `ready` pointer. `prepare` may lower `ready` to `pending` while retaining `phase` in `scripts/okstra_ctl/render.py::_derive_next_recommended_phase`; readers must use `status` for launchability. When `finalVerification.routingRecommendation.target` is `release-handoff(stage-group)`, write `phase` as `release-handoff`. When `implementationPlanning.outcome` is `plan-ready` and the plan-body gate is `blocked-by-disagreement` or `aborted-non-result`, or a `Blocks=approval` row is still `open`/`answered`, write `status` `blocked` (empty `phase`) — do not write `ready` at `implementation`. When that outcome is `plan-ready` and the plan is approvable, write `ready` at `implementation`; the user still has to approve it separately.
+`phase` is non-empty only for an authored `ready` pointer. `prepare` may lower `ready` to `pending` while retaining `phase` in `scripts/okstra_ctl/render.py::_derive_next_recommended_phase`; readers must use `status` for launchability. When `finalVerification.routingRecommendation.target` is `release-handoff(stage-group)`, write `phase` as `release-handoff`. When `implementationPlanning.outcome` is `plan-ready` and a `Blocks=approval` row still blocks progress (`open`, or `request-revision` / `reject`), or the plan-body gate is `aborted-non-result`, write `status` `blocked` (empty `phase`). `blocked-by-disagreement` with every approval row user-proceeded (`accept-risk` / `select` / `answer`) is approvable — write `ready` at `implementation`. The user still has to approve it separately.
 
 ## Compatibility
 

package/runtime/prompts/profiles/_clarification-recommendation.md

@@ -6,7 +6,7 @@
     - `scopeEffects` — optional tokens drawn from `{new-schema, deferrable}`.
     - `addedWork` — one sentence naming the work this choice creates that the other choices do not. Name the files, stages, or commands; do not substitute a cost adjective.
     - `directionChange` — one sentence naming what this choice reverses: an approved plan item, a recorded decision, an earlier answer. Name that item. When it reverses nothing, say so.
-    - `disposition` — the effect of selecting the option. Use `select` for `user-decision`, `accept-risk` for `noncritical-dissent`, and `request-revision` or `reject` when the option sends the plan back. `correctness-critical` never offers `accept-risk`.
+    - `disposition` — the effect of selecting the option. Use `select` for `user-decision`. Use `accept-risk` on any classification, including `correctness-critical`, when the user ends the gate and leaves the DISAGREE on the record. Use `request-revision` or `reject` when the option sends the plan back.
   - report assembly derives `approvalContext`, status, and resolution. `approvalContext` contains only `classification`, `unblockCondition`, and `recommendedDisposition`; it never copies plan or activity identifiers.
   - the three impact fields answer three different questions — how far the change reaches, what new work it creates, and what it overturns. Someone choosing between options needs all three, so never fold them into one sentence: whichever axis is easiest to write would silently stand in for the other two.
   - a row that omits `options[]`, offers fewer than two, or marks zero or two options as `recommended` is incomplete and must be completed before the report is finalised.

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

@@ -195,8 +195,8 @@ roles:
   - dependency / migration risk assessment (ordering constraints, data backfills, feature-flag prerequisites, repo-internal sequencing)
   - **Cross-Project Dependencies (conditionally required):** when the plan depends on work in another project / repo / published package, add (a) a `kind: cross-project` DM row to `dependencyMigrationRisk`, and (b) a matching `XP-NNN` row to `crossProjectDependencies`. An upstream-precondition row must have concrete `requiredWork` / `verificationSignal` / `howToStart` — `validators/validate-run.py` enforces that a DM `cross-project` ⇒ at least one `direction: upstream-precondition` XP row, and the schema enforces non-empty row fields. A cross-project dependency is recorded as this structured precondition, not as a soft Recommended Next Step. A single-project plan uses an empty array.
   - **recommendedNextSteps policy:** keep the substance of cross-project preconditions/carries in `crossProjectDependencies`, and put in `§3 Recommended Next Steps` only a pointer to that section (`§5.4 Cross-Project Dependencies`) — no double recording.
-  - **Resuming from an approval blocker (BLOCKING).** When this report carries any `blocks: approval` clarification, one `recommendedNextSteps` entry MUST name the `--answered-clarifications` re-run, in its `text` or in one of its `commands`. The reader of the report is the person who has to act, and until now the mechanics of resuming lived only in the lead prompt — which is read after the next run has already started. Point them at `okstra recap assemble`, which prints the answered ids, the exact flag value, the sidecar paths, and whether the re-verification would fall back to full. Do not restate those values here: they are unknown while you write, because the user has not answered yet. The first human action is answering those rows (`okstra-user-response`); do not tell the reader to start another planning run before the answers exist. **Enforced:** `validators/validate-run.py` `_validate_rerun_guidance`.
-  - **Asking for approval (BLOCKING).** When `outcome` is `plan-ready`, the gate is `passed` or `passed-with-dissent`, and no `blocks: approval` row is open, one `recommendedNextSteps` entry MUST tell the reader to approve (`--approve` or the in-session wizard). Do not recommend another `implementation-planning` run. **Enforced:** `validators/validate-run.py` `_validate_approval_guidance`.
+  - **Resuming from an approval blocker (BLOCKING).** When this report carries a progress-blocking `blocks: approval` clarification (`open`, or `request-revision` / `reject`), `recommendedNextSteps[0]` MUST be a command the reader can run now: `/okstra-user-response`, and the `--answered-clarifications` re-run in that step's `text` or `commands`. Do not write "The Okstra lead will …" as the first step. Point them at `okstra recap assemble`, which prints the answered ids, the exact flag value, the sidecar paths, and whether the re-verification would fall back to full. Do not restate those values here: they are unknown while you write, because the user has not answered yet. Do not tell the reader to start another planning run before the answers exist. An `accept-risk` / `select` / `answer` already recorded is not this case. **Enforced:** `validators/validate-run.py` `_validate_rerun_guidance`.
+  - **Asking for approval (BLOCKING).** When `outcome` is `plan-ready` and no `blocks: approval` row still blocks progress, one `recommendedNextSteps` entry MUST tell the reader to approve (`--approve` or the in-session wizard). A remaining `blocked-by-disagreement` whose rows the user already accepted does not send them back to planning. Do not recommend another `implementation-planning` run. **Enforced:** `validators/validate-run.py` `_validate_approval_guidance`.
   - 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
   - **Requirement admissibility (scope boundary):** a brief line becomes a Requirement Coverage row only when **a stage can satisfy it by changing files in this repository** — source, tests, config, or deployment *manifest files*. A line whose satisfaction needs a person's approval, a ticket status change, or an action against live infrastructure (applying a manifest, a cutover, creating a dashboard or alert, validating in staging/production) is NOT a requirement for this phase: it belongs to the brief's `## External Gates`, and this plan neither creates a stage for it nor cites it in coverage. Briefs generated by `okstra-brief-gen` pre-split these into the end-state sections `## Expected Behavior` / `## Preserved Behavior` / `## Expected Outcome` (admissible) and `## External Gates` (not); when reading an older brief that carries a raw Definition-of-Done checklist, apply the same test line by line. The boundary is the *action*, not the topic — "add the flag to `values-prod.yaml`" is admissible, "apply that manifest to prod" is not. Planning an operational stage this phase cannot execute (see the run-scope rule above forbidding deployments) produces steps whose commands never resolve, which the §5.5.9 gate then correctly blocks — the plan must not create that deadlock in the first place.
@@ -232,10 +232,9 @@ roles:
   - **§5.5.9 Plan Body Verification (BLOCKING).** After report-writer finishes the draft, the lead runs a worker peer-review round on the persisted queue. Selected-direction plans begin with `P-Dir-1`; legacy candidate-comparison plans begin with `P-Opt-*`; both continue with the shared execution items. The fixed order remains initial verification → one planner self-fix → targeted re-verification → user gate. Gate recomputation, extraction completeness, approval-context reconciliation, and self-fix limits remain enforced by `validators/validate-run.py`; verdict details and dissent format are owned by `prompts/lead/plan-body-verification.md`.
   - **Approval decision state.** The lead records active and carried decisions through `okstra approval-decision`. Every option carries `disposition`, one `reach`, and optional `scopeEffects`. A resolved decision names existing `A-NNN` checks; report assembly derives `approvalContext`, status, resolution, and reverse links.
     - `open → answered` when the raw user response is recorded
-    - `answered → resolved` only after the selected disposition is applied and its checks pass
-    - `answered → open` when application or checking fails
+    - `answered → resolved` after the selected disposition is applied, when that work completed
     - `open → obsolete` only when a plan change removes the question
-    `open` and `answered` block approval; only `resolved` and `obsolete` are non-blocking. **Enforced:** `validators/validate-run.py` `_validate_approval_context` plus run-prep `scripts/okstra_ctl/run.py` `_validate_approved_plan`.
+    `open` blocks until the user judges. `answered` with `accept-risk` / `select` / `answer` does not block. Do not move `answered` back to `open` because a check failed. **Enforced:** `scripts/okstra_ctl/clarification_items.py` `row_blocks_progress`, `validators/validate-run.py` `_validate_approval_context`, run-prep `scripts/okstra_ctl/run.py` `_validate_approved_plan`.
   - **Terminal approval evidence.** A resolved correctness-critical decision names a later successful evaluation through `resolutionInput.checkRefs`. Each referenced activity carries the same `C-NNN` in `clarificationRefs[]`, the affected `planItemIds[]`, zero-exit commands, and the plan-body state result. Report assembly rejects a missing activity or reverse link before publication. **Enforced:** `scripts/okstra_ctl/report_assembly.py::_clarification_row` and `_attach_plan_backlinks`.
   - **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 chosen realization introduces against the three criteria:
     1. **Hard to reverse** — would changing the decision later cost meaningfully more than deciding now?

package/runtime/python/okstra_ctl/approval_decisions.py

@@ -21,7 +21,7 @@ CLASSIFICATIONS = frozenset(
     {"user-decision", "noncritical-dissent", "correctness-critical"}
 )
 _FORBIDDEN_BY_CLASSIFICATION = {
-    "correctness-critical": frozenset({"select", "accept-risk"}),
+    "correctness-critical": frozenset({"select"}),
     "noncritical-dissent": frozenset({"select"}),
     "user-decision": frozenset(),
 }

package/runtime/python/okstra_ctl/clarification_items.py

@@ -32,6 +32,7 @@ from __future__ import annotations
 
 import json
 import re
+from collections.abc import Mapping
 from dataclasses import dataclass
 from pathlib import Path
 from typing import Optional
@@ -295,6 +296,7 @@ def _v2_row(entry: dict) -> Optional[dict]:
             if isinstance(options, list)
             else []
         ),
+        "disposition": clarification_disposition(entry),
     }
 
 
@@ -377,7 +379,8 @@ def parse_section_1_rows(report_text: str) -> list[dict]:
     return rows
 
 
-UNRESOLVED_STATUSES = {"open", "answered"}
+# 아직 사용자 판단이 없는 상태. `answered` 는 판단 기록이며 다시 묻지 않는다.
+UNRESOLVED_STATUSES = {"open"}
 
 # `Blocks` values that gate the user's `approved: true` flip.
 APPROVAL_BLOCKS = frozenset({"approval"})
@@ -393,6 +396,76 @@ ANSWER_DISPOSITIONS = frozenset({
     "request-revision",
     "reject",
 })
+# 사용자가 진행을 고른 처분. DISAGREE 표와 행은 증거로 남고 게이트는 내리다.
+PROCEEDING_DISPOSITIONS = frozenset({"answer", "select", "accept-risk"})
+# 사용자가 이 계획으로 진행하지 않겠다고 고른 처분.
+RETURN_DISPOSITIONS = frozenset({"request-revision", "reject"})
+
+
+def clarification_disposition(row: Mapping[str, object]) -> str:
+    """행에 기록된 사용자 처분. 없으면 빈 문자열."""
+    resolution = row.get("resolution")
+    if not isinstance(resolution, Mapping):
+        context = row.get("approvalContext")
+        if isinstance(context, Mapping):
+            resolution = context.get("resolution")
+    if isinstance(resolution, Mapping):
+        disposition = str(resolution.get("disposition") or "").strip()
+        if disposition:
+            return disposition
+    user_input = str(row.get("userInput") or "").strip()
+    options = row.get("options")
+    if user_input and isinstance(options, list):
+        for option in options:
+            if (
+                isinstance(option, Mapping)
+                and str(option.get("answer") or "").strip() == user_input
+            ):
+                return str(option.get("disposition") or "").strip()
+    return ""
+
+
+def row_blocks_progress(status: str, disposition: str = "") -> bool:
+    """이 행이 승인·다음 단계 진입을 막는가.
+
+    진행 처분(`accept-risk` / `select` / `answer`)은 고치지 않은 DISAGREE 를
+    행과 투표에 남긴 채로 게이트만 내린다. `request-revision` / `reject` 는
+    사용자가 진행을 거절한 것이므로 막는다. 처분이 없는 `answered` 도 판단
+    기록이므로 막지 않는다.
+    """
+    normalized_status = status.strip().lower()
+    normalized_disposition = disposition.strip().lower()
+    if normalized_status == "obsolete":
+        return False
+    if normalized_disposition in PROCEEDING_DISPOSITIONS:
+        return False
+    if normalized_disposition in RETURN_DISPOSITIONS:
+        return True
+    return normalized_status not in {"answered", "resolved"}
+
+
+def progress_blocking_ids(
+    rows: object,
+    blocking_values: frozenset[str] = APPROVAL_BLOCKS,
+) -> list[str]:
+    """게이트를 아직 막는 행 id. 사용자 진행 처분이 있는 행은 빠진다."""
+    if not isinstance(rows, list):
+        return []
+    ids: list[str] = []
+    for row in rows:
+        if not isinstance(row, Mapping):
+            continue
+        blocks = str(row.get("blocks") or "").strip().lower()
+        status = str(row.get("status") or "").strip()
+        row_id = row.get("id")
+        if (
+            blocks in blocking_values
+            and row_blocks_progress(status, clarification_disposition(row))
+            and isinstance(row_id, str)
+            and row_id
+        ):
+            ids.append(row_id)
+    return ids
 
 
 @dataclass(frozen=True)
@@ -410,10 +483,18 @@ class ClarificationScan:
 
 
 def scan_approval_gate(report_path: Path) -> ClarificationScan:
-    """Scan for unresolved ``Blocks=approval`` rows (``Status`` in
-    ``{open, answered}``), refusing to guess whenever the schema drifted."""
+    """Scan for ``Blocks=approval`` rows that still block progress.
+
+    A recorded user proceeding disposition (`accept-risk` / `select` /
+    `answer`), including one that lives only in the sidecar, does not block.
+    ``request-revision`` / ``reject`` still block. The scan refuses to guess
+    whenever the schema drifted.
+    """
     return scan_clarification_blockers(
-        report_path, APPROVAL_BLOCKS, honor_sidecar_answers=False
+        report_path,
+        APPROVAL_BLOCKS,
+        honor_sidecar_answers=True,
+        sidecar_unblocks_proceeding_only=True,
     )
 
 
@@ -430,43 +511,61 @@ def scan_clarification_blockers(
     blocking_values: frozenset[str],
     *,
     honor_sidecar_answers: bool,
+    sidecar_unblocks_proceeding_only: bool = False,
 ) -> ClarificationScan:
     """Shared fail-closed clarification walk for both gates above — schema-v2
     reads its rows from the data sibling and schema-v1 from the §1 table.
-    ``honor_sidecar_answers`` controls whether a user's sidecar hides answered
-    rows from this scan; approval deliberately passes ``False``."""
+    ``honor_sidecar_answers`` hides rows the sidecar already answered.
+    ``sidecar_unblocks_proceeding_only`` keeps ``request-revision`` / ``reject``
+    as blockers so a return choice cannot start the next phase.
+    """
     v2_scan = _scan_v2_blockers(report_path, blocking_values)
     scan = (
         v2_scan if v2_scan is not None
         else scan_section_1_blockers(_read_report_text(report_path), blocking_values)
     )
     return (
-        _resolve_blockers_answered_by_user(report_path, scan)
+        _resolve_blockers_answered_by_user(
+            report_path,
+            scan,
+            proceeding_only=sidecar_unblocks_proceeding_only,
+        )
         if honor_sidecar_answers
         else scan
     )
 
 
 def _resolve_blockers_answered_by_user(
-    report_path: Path, scan: ClarificationScan
+    report_path: Path,
+    scan: ClarificationScan,
+    *,
+    proceeding_only: bool = False,
 ) -> ClarificationScan:
     """사용자가 사이드카로 답한 행을 blocker 에서 뺀 스캔.
 
     답의 정본은 사용자의 `user-responses/` 사이드카다. 리포트의 `Status` 는 그
     run 이 스스로 적어둔 값이고, 답이 사이드카로만 들어오는 경로(HTML 뷰의
     `Export user response`, `okstra user-response write`)에서는 갱신되지 않는다.
-    사용자 입력 목록은 사이드카 답변이 있는 항목을 다시 묻지 않는다.
+    사용자 입력 목록은 사이드카 답변이 있는 항목을 다시 묻지 않는다. 승인
+    게이트는 진행 처분만 차단에서 뺀다.
 
     fail-closed 는 그대로다: 행 자체를 못 읽은 스캔(`unreadable_reason`)은
     어떤 id 가 blocker 인지 모르는 상태이므로 사이드카로 덮지 않는다.
     """
     if scan.unreadable_reason is not None or not scan.blockers:
         return scan
-    answers = sidecar_answers(report_path)
-    if not answers:
+    dispositions = sidecar_dispositions(report_path)
+    if not dispositions:
+        return scan
+    answered_ids = {
+        row_id
+        for row_id, disposition in dispositions.items()
+        if (not proceeding_only) or disposition in PROCEEDING_DISPOSITIONS
+    }
+    if not answered_ids:
         return scan
     return ClarificationScan(
-        [b for b in scan.blockers if b.row_id not in answers], None
+        [b for b in scan.blockers if b.row_id not in answered_ids], None
     )
 
 
@@ -507,7 +606,7 @@ def scan_section_1_blockers(
         ))
     blockers = [
         it for it in table.items
-        if it.blocks in blocking_values and it.status in UNRESOLVED_STATUSES
+        if it.blocks in blocking_values and row_blocks_progress(it.status)
     ]
     return ClarificationScan(blockers, None)
 
@@ -538,7 +637,9 @@ def _scan_v2_blockers(
     blockers = [
         row["item"] for row in rows
         if row["item"].blocks in blocking_values
-        and row["item"].status in UNRESOLVED_STATUSES
+        and row_blocks_progress(
+            row["item"].status, str(row.get("disposition") or "")
+        )
     ]
     return ClarificationScan(blockers, None)
 
@@ -655,35 +756,47 @@ def _sidecars_for_attachment(source: Path) -> list[Path]:
     return sorted([*ordinary, *selected])
 
 
-def sidecar_answers(source: Path) -> dict[str, str]:
-    """`user-responses/` 사이드카들의 답변을 `{clarification-id: value}` 로 모은다.
-
-    사용자가 답한 항목이 무엇인지 아는 단일 참조점 — carry-in 병합도, 승인
-    게이트도, 스킬의 열린 항목 목록도 전부 이 한 곳을 본다.
+def _sidecar_answer_records(source: Path) -> dict[str, tuple[str, str]]:
+    """사이드카 답을 `{id: (value, disposition)}` 로 모은다.
 
     `disposition` 이 `ANSWER_DISPOSITIONS` 에 속하는 항목만 답으로 센다.
-    `reframe` 은 "다음 run 에서 다시 물어달라" 이지 답이 아니므로
-    (`skills/okstra-user-response/SKILL.md` 의 "A reframe is not an answer")
-    답 집합에서 빠져야 사용자 입력 목록에 그 항목이 계속 남는다.
-
-    같은 id 가 여러 사이드카에 나오면 이름순 마지막(최신 seq)이 이긴다 — 최신이
-    reframe 이거나 값이 비면 앞선 답을 지운다. 그래야 답을 물렀을 때 그 항목이
-    미해결로 돌아온다. `user_response` 를 지연 import 해 순환 참조를 피한다.
+    `reframe` 은 답이 아니므로 집합에서 빠진다. 같은 id 는 이름순 마지막이
+    이긴다 — 최신이 reframe 이거나 값이 비면 앞선 답을 지운다.
     """
     from okstra_ctl.user_response import parse_user_response_entries
 
-    answers: dict[str, str] = {}
+    answers: dict[str, tuple[str, str]] = {}
     for sidecar in user_response_sidecars(source):
         for entry in parse_user_response_entries(
             sidecar.read_text(encoding="utf-8")
         ):
             if entry.value and entry.disposition in ANSWER_DISPOSITIONS:
-                answers[entry.response_id] = entry.value
+                answers[entry.response_id] = (entry.value, entry.disposition)
             else:
                 answers.pop(entry.response_id, None)
     return answers
 
 
+def sidecar_answers(source: Path) -> dict[str, str]:
+    """`user-responses/` 사이드카들의 답변을 `{clarification-id: value}` 로 모은다.
+
+    사용자가 답한 항목이 무엇인지 아는 단일 참조점 — carry-in 병합도, 승인
+    게이트도, 스킬의 열린 항목 목록도 전부 이 한 곳을 본다.
+    """
+    return {
+        row_id: value
+        for row_id, (value, _disposition) in _sidecar_answer_records(source).items()
+    }
+
+
+def sidecar_dispositions(source: Path) -> dict[str, str]:
+    """사이드카 답의 처분을 `{clarification-id: disposition}` 로 모은다."""
+    return {
+        row_id: disposition
+        for row_id, (_value, disposition) in _sidecar_answer_records(source).items()
+    }
+
+
 def attached_user_responses_section(source: Path) -> str:
     """`source` 형제 `user-responses/` 사이드카만 모은 `# Attached User Responses`
     섹션 본문. 사이드카 부재 시 빈 문자열.