okstra 0.186.2 → 0.186.4

package/docs/architecture.md

@@ -865,11 +865,11 @@ The manifest-provided `lead-events-*.jsonl` file is the canonical record for str
 
 `activityContractVersion: 1` is an interpretation version for new `implementation-planning` artifacts. A run without that field remains a historical run and does not require activity events or an `agentActivity[]` projection.
 
-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.
+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 schema-invalid composed record is still published so `validate-run` can scan it; the step itself fails. A historical v2 manifest retains the in-place projection path. A failed Phase 7 step does not skip later checks: `validate-run` still runs, and only `teardown-stages` is skipped. 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)
 

package/docs/cli.md

@@ -862,7 +862,7 @@ The `okstra` Node CLI (`bin/okstra`) provides both installer/admin commands and
 | `okstra approval-decision <open\|resolve\|carry> --ledger <approval-decisions.json> …` | Write the lead-owned clarification and approval ledger. `open` validates classification-specific dispositions and complete option fields, `resolve` requires real `A-NNN` check references, and `carry` keeps prior resolved decisions outside the active clarification list. |
 | `okstra design-snapshot --narrative <report-narrative.md> --output <design-preparation.json>` | Detect implementation-planning design surfaces and write the detector-owned snapshot consumed by final report assembly. |
 | `okstra plan-verify --narrative <report-narrative.md> --state <plan-body-verification.json>` | Recompute the plan-body gate from the convergence-owned state before `data.json` publication. `--report <historical-data.json>` remains the v2 reader. |
-| `okstra report-finalize --project-root <dir> --run-manifest <path> --report <final-report.md>` | Run Phase 7 in the manifest's contract order. Contract v3 collects usage into team state, assembles all single-owner inputs into `data.json` once, then checks, renders, spawns follow-ups, validates, and tears down eligible stage worktrees. Contract v2 retains its historical in-place projection sequence as a read-only compatibility path. Stops at the first non-zero exit except deferred token collection, reports each step, and prints the ordered `--only` recovery tail. This is the shared path for every lead adapter. |
+| `okstra report-finalize --project-root <dir> --run-manifest <path> --report <final-report.md>` | Run Phase 7 in the manifest's contract order. Contract v3 collects usage into team state, assembles all single-owner inputs into `data.json` once, then checks, renders, spawns follow-ups, validates, and tears down eligible stage worktrees. Contract v2 retains its historical in-place projection sequence as a read-only compatibility path. A failed step still runs every later check through `validate-run`; only `teardown-stages` is skipped so a failed run does not reclaim worktrees. Reports each step and prints the ordered `--only` recovery tail from the earliest failure. This is the shared path for every lead adapter. |
 | `okstra render-views <final-report.data.json\|final-report.md>` | The Phase 7 `render-views` step, runnable on its own. Schema v2 data is rendered directly, and schema v3 data uses the same always-generated, task-specific human HTML path. The full reading copy uses `templates/reports/final-report-v2.template.md` and is rendered on demand with `okstra render-final-report`. Passing the Markdown sibling locates the same data.json. Schema v1 and quick reports keep the legacy conditional renderer. The Node wrapper calls `scripts/okstra-render-report-views.py`; `validators/validate-report-views.py` verifies source/schema/template digests, required human fields, form controls, external assets, diagram/table ID parity, and Response ID parity. |
 | `okstra design-prep <list\|show\|write>` | Review AI-prepared implementation design requests, inspect their effective confirmed response, or append a confirmed user/wizard response without editing the planning report |
 | `okstra wizard <init\|step\|render-args\|confirmation\|outcome> --state-file <path>` | Interactive input state machine for okstra-run, implemented by `okstra_ctl.wizard`. Seed a state file with `init`, then repeatedly call `step --answer <val>` to receive the next `Prompt` JSON. `--answer` is **required**; use `--no-submit` to peek at the next prompt without submitting a response. A `pick` with more choices than the host picker can display keeps `kind: "pick"` but adds `presentation: "numbered-text"`; render every option as a numbered Markdown list and submit the user's 1-based number, exact value, or exact label. Invalid, out-of-range, and ambiguous answers re-prompt without dropping choices. `render-args` returns the final `render-bundle` argument map, and `confirmation` returns the user echo block. On a completed wizard, `outcome` returns `renderArgs`, `persistActions`, and `confirmationText` together; project/global release-handoff PR-template persistence appears as `persistActions[].command == "config.set"`. For an `implementation` task type, `stage_pick` follows `approved_plan_pick` and selects the stage before `executor_pick`. The brief step appears only for entry task types—requirements-discovery, error-analysis, improvement-discovery, project-analysis, feature-analysis, and change-impact-analysis. Analysis inputs use `feature_evidence_pick` / `feature_evidence`, `project_evidence_pick` / `project_evidence`, and `analysis_target_pick` / `analysis_target`; a revision-requested report prioritizes its same-task, same-type rerun. Downstream lifecycle phases automatically carry the manifest brief, with a three-option `brief_carry` fallback when none is registered; `release-handoff` has no brief and enters multi-select `handoff_stage_pick` for eligible stage groups or the whole task |

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. 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 or answered approval blockers → `/okstra-user-response`; 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.
+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/project-structure-overview.md

@@ -343,7 +343,7 @@ Important modules:
 | `plan_derivations.py` | the supersession sweep `_common-contract.md` requires an author to do by hand — extracts the symbols, paths, and ids an answered clarification names and reports every plan string that mentions one. Advisory: it locates candidates and never judges which are now false |
 | `scope_provenance.py` | single source of truth for the scope-provenance grammar every phase-emitted requirement must declare, shared by `validators/validate-run.py` and `validators/validate_fanout.py` so the planning report and fan-out packets cannot drift |
 | `worker_artifact_paths.py` | canonical worker artifact path derivation (e.g. `audit_sidecar_rel` inserts `-audit-` after the first `-worker-` token), so dispatch and validation agree on non-canonical-path rejection |
-| `report_finalize.py` | Phase 7 post-report sequence **SSOT** — runs `check-source` → `token-usage` → `render-views` → `spawn-followups` → `validate-run` in that load-bearing order, stops at the first non-zero exit and names the failing step — except `token-usage`, whose failure defers so the later steps still produce their artifacts. Both lead paths converge here: the Codex adapter calls it in-process (`codex_dispatch`), a Claude-led run reaches it through `okstra report-finalize`. Neither reimplements the sequence |
+| `report_finalize.py` | Phase 7 post-report sequence **SSOT** — runs `check-source` → `token-usage` → `render-views` → `spawn-followups` → `validate-run` in that load-bearing order. A non-zero exit still runs every later check through `validate-run` and names the earliest failure; `teardown-stages` is skipped when any earlier step failed. Both lead paths converge here: the Codex adapter calls it in-process (`codex_dispatch`), a Claude-led run reaches it through `okstra report-finalize`. Neither reimplements the sequence |
 | `wrapper_status.py` | worker wrapper status sidecar reader — the host-side reader of the sidecar `worker_runner.py` writes. `is_terminal` is the one question it answers for the dispatch record and the pane reclaim: does `stage` read `exited` |
 | `worker_runner.py` | runs one worker CLI and records what happened — shared by every provider entrypoint. Owns the `selectors` pump over the child's streams, the stream-arrival idle watchdog (`killpg` on breach), the run-wide progress cap on the log copy, and the status sidecar's whole life. A run that dies after launch still closes its sidecar, so `worker_liveness` never reads a dead worker as running |
 | `session_transcript.py` | worker session transcript — one line per event (time, speaker, body) with a run-wide progress-line cap (`LOG_LINE_CAP`, elision notice) so a single-file dispatch's tool echo cannot dominate the project's `.okstra/` bytes; the fixed shape lets a later lead write share the same file |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "okstra",
-  "version": "0.186.2",
+  "version": "0.186.4",
   "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.2",
-  "builtAt": "2026-08-24T02:07:41.323Z",
+  "package": "0.186.4",
+  "builtAt": "2026-08-24T05:51:42.489Z",
   "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`.
 
@@ -429,7 +430,7 @@ After persistence, reply briefly in the resolved Report Language. **Lead this re
 
 Pick the next action from this table; the first matching row wins:
 
-- Open or answered `blocks: approval` rows → `/okstra-user-response` (name the `C-NNN` ids). Do not start implementation and do not re-run planning until those answers exist.
+- 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`.

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 an unresolved (`open` or `answered`) `blocks: approval` clarification, `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. **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`
     섹션 본문. 사이드카 부재 시 빈 문자열.

package/runtime/python/okstra_ctl/implementation_direction.py

@@ -13,6 +13,7 @@ from dataclasses import dataclass
 from pathlib import Path
 from typing import Any, Mapping
 
+from .clarification_items import USER_INPUT_BLOCKS, progress_blocking_ids
 from .final_report_paths import final_report_data_path
 from .exact_coverage import ExactCoverageError, calculate_plan_exact_coverage
 from .final_report_schema import (
@@ -309,15 +310,13 @@ def _selected_option(
 def _validate_no_blockers(data: Mapping[str, Any], option: Mapping[str, Any]) -> None:
     if option.get("safetyBlockers") or option.get("unresolvedFeasibilityFacts"):
         raise DirectionSelectionError("selected candidate has a safety blocker")
-    for row in data.get("clarificationItems") or ():
-        if (
-            isinstance(row, Mapping)
-            and row.get("blocks") == "next-phase"
-            and row.get("status") not in {"resolved", "obsolete"}
-        ):
-            raise DirectionSelectionError(
-                "selection report has an unresolved next-phase blocker"
-            )
+    blockers = progress_blocking_ids(
+        data.get("clarificationItems"), USER_INPUT_BLOCKS
+    )
+    if blockers:
+        raise DirectionSelectionError(
+            "selection report has an unresolved next-phase blocker"
+        )
 
 
 def _direction_payload(option: Mapping[str, Any]) -> dict[str, Any]:

package/runtime/python/okstra_ctl/next_phase.py

@@ -9,7 +9,10 @@ from __future__ import annotations
 
 from typing import Any, Mapping
 
-from okstra_ctl.clarification_items import APPROVAL_BLOCKS, UNRESOLVED_STATUSES
+from okstra_ctl.clarification_items import (
+    APPROVAL_BLOCKS,
+    progress_blocking_ids,
+)
 
 STATUS_READY = "ready"
 STATUS_PENDING = "pending"
@@ -219,24 +222,9 @@ def _from_option_selection(report_data: Mapping[str, Any]) -> dict[str, str]:
 
 
 def _unresolved_approval_ids(report_data: Mapping[str, Any]) -> list[str]:
-    rows = report_data.get("clarificationItems")
-    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().lower()
-        row_id = row.get("id")
-        if (
-            blocks in APPROVAL_BLOCKS
-            and status in UNRESOLVED_STATUSES
-            and isinstance(row_id, str)
-            and row_id
-        ):
-            ids.append(row_id)
-    return ids
+    return progress_blocking_ids(
+        report_data.get("clarificationItems"), APPROVAL_BLOCKS
+    )
 
 
 def _planning_approval_block_reason(
@@ -245,8 +233,10 @@ def _planning_approval_block_reason(
     """plan-ready 인데 승인할 수 없으면 근거, 아니면 빈 문자열.
 
     자문 게이트(`passed-with-dissent`)와 재현 실패 `has-dissent` 는 여기 안
-    들어온다. 차단은 `blocked-by-disagreement` / `aborted-non-result` 와
-    `Status` 가 open/answered 인 `Blocks=approval` 행뿐이다.
+    들어온다. 차단은 `aborted-non-result` 와, 사용자가 아직 진행 처분을
+    고르지 않은 `Blocks=approval` 행이다. `blocked-by-disagreement` 는 그
+    행들이 전부 `accept-risk` / `select` / `answer` 이면 증거가 된 뒤라
+    포인터를 막지 않는다.
     """
     ids = _unresolved_approval_ids(report_data)
     if ids:
@@ -261,11 +251,23 @@ def _planning_approval_block_reason(
     gate = ""
     if isinstance(verification, Mapping):
         gate = str(verification.get("gateResult") or "").strip().lower()
-    if gate in _BLOCKING_PLAN_GATES:
+    if gate == "aborted-non-result":
         return (
             f"계획 본문 게이트가 `{gate}` 이라 승인할 수 없습니다. "
             "구현을 시작하거나 계획 단계를 바로 다시 돌리지 마세요."
         )
+    if gate == "blocked-by-disagreement":
+        approval_rows = [
+            row
+            for row in (report_data.get("clarificationItems") or [])
+            if isinstance(row, Mapping)
+            and str(row.get("blocks") or "").strip().lower() in APPROVAL_BLOCKS
+        ]
+        if not approval_rows:
+            return (
+                f"계획 본문 게이트가 `{gate}` 이라 승인할 수 없습니다. "
+                "구현을 시작하거나 계획 단계를 바로 다시 돌리지 마세요."
+            )
     return ""
 
 

package/runtime/python/okstra_ctl/render_final_report.py

@@ -44,6 +44,7 @@ from typing import Any
 import okstra_vendor  # noqa: F401 — side effect: sys.modules aliases
 from jinja2 import ChainableUndefined, Environment, FileSystemLoader
 
+from okstra_ctl.clarification_items import USER_INPUT_BLOCKS, progress_blocking_ids
 from okstra_ctl.final_report_schema import (
     SchemaError,
     load_schema_for_data,
@@ -555,14 +556,9 @@ def _ai_markdown_context(data: dict, schema: dict | None) -> dict:
     )
     context["aiTaskProperty"] = TASK_TYPE_DATA_PROPERTY.get(task_type, "")
     context["aiTaskTemplate"] = _markdown_task_template(task_type)
-    context["aiBlockingIds"] = [
-        row.get("id")
-        for row in data.get("clarificationItems", [])
-        if isinstance(row, dict)
-        and row.get("status") in {"open", "answered"}
-        and row.get("blocks") in {"approval", "next-phase"}
-        and isinstance(row.get("id"), str)
-    ]
+    context["aiBlockingIds"] = progress_blocking_ids(
+        data.get("clarificationItems", []), USER_INPUT_BLOCKS
+    )
     sections = ReportSections(data, schema or {})
     context["md"] = sections.section
     context["md_rest"] = sections.rest

package/runtime/python/okstra_ctl/report_assembly.py

@@ -9,6 +9,7 @@ from pathlib import Path
 from typing import Any, Callable, Mapping, Sequence
 
 from .agent_activity import agent_activity_rows
+from .clarification_items import clarification_disposition, row_blocks_progress
 from .final_report_schema import load_schema_version, validate
 from .report_inputs import ReportInputPath, report_input_paths, uses_report_contract_v3
 from .json_boundary import JsonBoundaryError, load_owned_object, serialize_owned_object
@@ -330,7 +331,10 @@ def _attach_metadata(data: dict[str, Any], manifest: Mapping[str, Any]) -> None:
     data["meta"] = {"reportLanguage": str(manifest.get("reportLanguage") or "en")}
     clarifications = data.get("clarificationItems") or []
     blocked = any(
-        isinstance(row, Mapping) and row.get("status") in {"open", "answered"}
+        isinstance(row, Mapping)
+        and row_blocks_progress(
+            str(row.get("status") or ""), clarification_disposition(row)
+        )
         for row in clarifications
     )
     frontmatter = {
@@ -460,7 +464,12 @@ def assemble_report(
     project_root: Path, manifest_path: Path, *,
     replace: Callable[[str, str], None] = os.replace,
 ) -> dict[str, Any]:
-    """모든 입력이 유효할 때만 계약 3.0 정본을 한 번 교체한다."""
+    """계약 3.0 정본을 조립해 게시한다.
+
+    입력이 없어 조립 자체가 안 되면 기존 파일을 건드리지 않는다. 조립은
+    됐는데 스키마만 깨진 기록은 게시한 뒤 거부한다. 게시를 건너뛰면
+    `validate-run` 이 이번 런 내용을 보지 못한다.
+    """
     manifest_row = ReportInputPath("run-manifest", "orchestrator", manifest_path)
     manifest = _read_json(manifest_row)
     if not uses_report_contract_v3(manifest):
@@ -486,9 +495,13 @@ def assemble_report(
         raise ReportAssemblyError(tuple(input_issues))
     data = _compose(project_root, manifest_path, manifest, inputs, schema)
     errors = validate(data, schema)
+    value = manifest.get("expectedReportRecordPath")
+    if not isinstance(value, str) or not value:
+        _fail("orchestrator", manifest_path, "expectedReportRecordPath", "required")
+    target = Path(value)
+    target = target if target.is_absolute() else project_root / target
+    _publish(target, data, replace)
     if errors:
-        target = Path(str(manifest.get("expectedReportRecordPath") or "data.json"))
-        target = target if target.is_absolute() else project_root / target
         raise ReportAssemblyError(
             tuple(
                 AssemblyIssue(
@@ -500,10 +513,4 @@ def assemble_report(
                 for error in errors
             )
         )
-    value = manifest.get("expectedReportRecordPath")
-    if not isinstance(value, str) or not value:
-        _fail("orchestrator", manifest_path, "expectedReportRecordPath", "required")
-    target = Path(value)
-    target = target if target.is_absolute() else project_root / target
-    _publish(target, data, replace)
     return data

package/runtime/python/okstra_ctl/report_finalize.py

@@ -7,17 +7,21 @@ read-only compatibility. The order is load-bearing: rendering before assembly
 or usage collection publishes stale derived views, and validating before
 rendering trips the report-views contract.
 
-`token-usage` is the one step whose failure does not stop the sequence, which
-deliberately accepts that first state: its input is the lead session log, so a
-refusal there would otherwise delete every artifact the later steps produce.
-The run does not pass in that state. `validators/validate-run.py` re-collects
-when the recorded usage is all zeros against an `unavailable` session source
-(`_needs_token_autofix`) and refuses the run rather than ship zeroed counts
-(`accuracy-failed`); a legacy v1 report is caught earlier still, by its
-unsubstituted `{{...}}` placeholders, which a v2 report never carries because
-its numeric cells are `null` until this step fills them. Substituting the
-tokens on a later retry then leaves the already-rendered html stale for
-`validators/validate-report-views.py`.
+A non-zero exit no longer stops the sequence before `validate-run`. A schema
+cap used to hide the contract scan: assembly refused, later steps never ran,
+and the lead only saw those failures after a second finalize. Each step still
+records its own exit; `ok` stays False when any step failed. `teardown-stages`
+is the exception — it reclaims worktrees, so a failed prefix skips it.
+
+`token-usage` reads the lead session log (state outside this run). A refusal
+there used to delete every later artifact; it no longer does, because the
+sequence continues. `validators/validate-run.py` re-collects when the recorded
+usage is all zeros against an `unavailable` session source (`_needs_token_autofix`)
+and refuses the run rather than ship zeroed counts (`accuracy-failed`). A
+legacy v1 report is caught earlier still, by its unsubstituted `{{...}}`
+placeholders, which a v2 report never carries because its numeric cells are
+`null` until this step fills them. Substituting the tokens on a later retry
+then leaves the already-rendered html stale for `validators/validate-report-views.py`.
 
 The translation sidecar is NOT one of these steps. `render-views` overlays it,
 so a non-English run dispatches the translator before this sequence starts —
@@ -447,26 +451,14 @@ def run_finalize(
     before_step: Callable[[str], None] | None = None,
     only: Sequence[str] | None = None,
 ) -> dict[str, Any]:
-    """Run the Phase 7 steps in contractual order.
-
-    A non-zero exit stops the sequence, with one exception: ``token-usage``
-    defers. Its input is the lead session log — state outside this run — so a
-    refusal there is not evidence that the artifacts after it are unwritable.
-    The deferred failure becomes the result's ``reason`` when nothing later
-    fails, and yields to any later failure, which is the step that actually
-    blocked the run.
-
-    ``before_step`` fires immediately before each step is spawned, letting an
-    adapter settle state the step will read (the Codex adapter marks the report
-    writer `completed` before `validate-run` inspects team-state).
-
-    ``only`` restricts the run to the named steps, preserving contractual
-    order. The last step (`validate-run`) is the one that usually fails, and
-    re-running the whole sequence to retry it repeats every preceding idempotent
-    step at full token and wall-clock cost.
+    """계약 순서로 Phase 7 을 돌리고, 실패해도 `validate-run` 까지 모은다.
+
+    `before_step` 은 각 단계 프로세스 직전에 호출된다. Codex 어댑터가
+    `validate-run` 앞에 작성기 상태를 `completed` 로 표시하는 자리이다.
+
+    `only` 는 고른 단계만 계약 순서로 남긴다.
     """
     steps: list[dict[str, Any]] = []
-    deferred = ""
     try:
         if ctx.report_contract_version != "3.0":
             write_execution_roles(ctx)
@@ -476,7 +468,9 @@ def run_finalize(
 
     if only:
         selected = set(only)
-        contract_order = V3_STEP_ORDER if ctx.report_contract_version == "3.0" else STEP_ORDER
+        contract_order = (
+            V3_STEP_ORDER if ctx.report_contract_version == "3.0" else STEP_ORDER
+        )
         unknown = sorted(selected - set(contract_order))
         if unknown:
             return {
@@ -486,75 +480,70 @@ def run_finalize(
             }
         commands = [(name, cmd) for name, cmd in commands if name in selected]
 
+    first_failure = ""
     for name, command in commands:
+        # 실패한 시퀀스가 worktree 를 거두면 재작업 대상이 사라진다.
+        if name == STEP_TEARDOWN_STAGES and first_failure:
+            continue
         if before_step is not None:
             before_step(name)
-        if name == STEP_PROJECT_ACTIVITY:
-            try:
-                if ctx.report_contract_version == "3.0":
-                    assembled = assemble_report(ctx.project_root, ctx.manifest_path)
-                    count = len(assembled.get("agentActivity") or [])
-                else:
-                    rows = project_agent_activity(
-                        ctx.project_root,
-                        ctx.manifest_path,
-                        ctx.data_path,
-                    )
-                    count = len(rows)
-            except (ActivityProjectionError, ReportAssemblyError) as exc:
-                result = subprocess.CompletedProcess(
-                    command,
-                    1,
-                    "",
-                    str(exc),
-                )
-            else:
-                result = subprocess.CompletedProcess(
-                    command,
-                    0,
-                    json.dumps({"count": count}),
-                    "",
-                )
-        else:
-            result = None
-        if name == STEP_TEARDOWN_STAGES:
-            result = _teardown_stage_worktrees(ctx, command)
-        if name == STEP_VALIDATE_RUN:
-            try:
-                _link_lead_result_for_validation(ctx)
-            except (DispatchError, OSError, json.JSONDecodeError) as exc:
-                return {
-                    "ok": False,
-                    "reason": f"lead result linkage failed: {exc}",
-                    "steps": steps,
-                }
-        if result is None:
-            result = subprocess.run(
-                command,
-                cwd=ctx.project_root,
-                text=True,
-                capture_output=True,
-            )
+        result = _run_finalize_step(ctx, name, command)
         steps.append(step_payload(name, command, result))
-        if result.returncode != 0:
-            failure = f"{name} failed with exit code {result.returncode}"
-            # Token collection reads the lead session log, which lives outside
-            # this run. One refusal there (`grandTotalTokens=0`) took the whole
-            # run's output with it: html never rendered, follow-ups never
-            # spawned, and `validate-run` then blocked on `report-views:
-            # missing html artifact`. So this step alone defers instead of
-            # stopping the sequence. It hides nothing — the non-zero exit stays
-            # in `steps`, `ok` stays False, and the closing `validate-run`
-            # still refuses the run.
-            if name == STEP_TOKEN_USAGE:
-                deferred = failure
-                continue
-            return {"ok": False, "reason": failure, "steps": steps}
-    if deferred:
-        return {"ok": False, "reason": deferred, "steps": steps}
+        if result.returncode != 0 and not first_failure:
+            first_failure = f"{name} failed with exit code {result.returncode}"
+    if first_failure:
+        return {"ok": False, "reason": first_failure, "steps": steps}
     return {"ok": True, "reason": "", "steps": steps}
 
 
+def _run_finalize_step(
+    ctx: FinalizeContext,
+    name: str,
+    command: Sequence[str],
+) -> subprocess.CompletedProcess[str]:
+    """한 Phase 7 단계를 실행하고 그 단계의 종료 코드만 돌려준다."""
+    if name == STEP_PROJECT_ACTIVITY:
+        return _run_project_activity(ctx, command)
+    if name == STEP_TEARDOWN_STAGES:
+        return _teardown_stage_worktrees(ctx, command)
+    if name == STEP_VALIDATE_RUN:
+        try:
+            _link_lead_result_for_validation(ctx)
+        except (DispatchError, OSError, json.JSONDecodeError) as exc:
+            return subprocess.CompletedProcess(
+                command, 1, "", f"lead result linkage failed: {exc}"
+            )
+    return subprocess.run(
+        command,
+        cwd=ctx.project_root,
+        text=True,
+        capture_output=True,
+    )
+
+
+def _run_project_activity(
+    ctx: FinalizeContext,
+    command: Sequence[str],
+) -> subprocess.CompletedProcess[str]:
+    """계약 3.0 은 조립, 그 외는 활동 투영만 한다."""
+    try:
+        if ctx.report_contract_version == "3.0":
+            assembled = assemble_report(ctx.project_root, ctx.manifest_path)
+            count = len(assembled.get("agentActivity") or [])
+        else:
+            rows = project_agent_activity(
+                ctx.project_root,
+                ctx.manifest_path,
+                ctx.data_path,
+            )
+            count = len(rows)
+    except (ActivityProjectionError, ReportAssemblyError) as exc:
+        return subprocess.CompletedProcess(command, 1, "", str(exc))
+    return subprocess.CompletedProcess(
+        command, 0, json.dumps({"count": count}), ""
+    )
+
+
 def write_execution_roles(ctx: FinalizeContext) -> None:
     """Write the exact manifest role set onto the final-report data.json."""
     if not ctx.data_path.is_file() or not ctx.manifest_path.is_file():
@@ -685,13 +674,11 @@ def _recovery_step_names(
     """The steps a retry has to re-run: every step from the earliest failure on.
 
     Naming only the failed steps would prescribe half a recovery. `token-usage`
-    defers, so `render-views` already wrote an html view from unsubstituted
-    data; substituting the tokens on a retry leaves that view stale
+    can fail while `render-views` still writes html from unsubstituted data;
+    substituting the tokens on a retry leaves that view stale
     (`validators/validate-report-views.py` checks `source-sha256` against the
-    md body). And a sequence that stopped early never reached `validate-run`,
-    which is the step that decides whether the run is shippable. Resuming from
-    the earliest failure redoes both while still skipping the prefix that
-    succeeded — the saving `--only` exists for.
+    md body). Resuming from the earliest failure redoes the tail while skipping
+    the prefix that succeeded — the saving `--only` exists for.
     """
     failed = {
         string_value(step.get("name"))

package/runtime/python/okstra_ctl/run.py

@@ -49,8 +49,10 @@ from .analysis_inputs import (
 )
 from .stage_fix_carry import derive_stage_fix_carry
 from .clarification_items import (
+    APPROVAL_BLOCKS,
     attached_user_responses_section,
     clarification_response_with_sidecars,
+    progress_blocking_ids,
     scan_approval_gate,
 )
 from .error_report import prior_run_error_digest
@@ -283,6 +285,29 @@ def _data_json_gate_result(data: dict) -> str:
     return str(verification.get("gateResult") or "").strip().lower()
 
 
+def _blocking_gate_survives_user_decision(data: dict, gate: str) -> bool:
+    """사용자가 진행 처분을 골라도 이 게이트 값이 승인을 막는가.
+
+    `aborted-non-result` 는 투표가 없어 사용자 판단의 대상이 아니다.
+    `blocked-by-disagreement` 는 승인 행이 있고 그 행이 전부 진행 처분이면
+    DISAGREE 를 증거로 남긴 채 막지 않는다. 승인 행이 없으면 판단 기록이
+    없으므로 막는다.
+    """
+    if gate != "blocked-by-disagreement":
+        return True
+    rows = data.get("clarificationItems")
+    if not isinstance(rows, list):
+        return True
+    has_approval_row = any(
+        isinstance(row, dict)
+        and str(row.get("blocks") or "").strip().lower() in APPROVAL_BLOCKS
+        for row in rows
+    )
+    return (not has_approval_row) or bool(
+        progress_blocking_ids(rows, APPROVAL_BLOCKS)
+    )
+
+
 def _record_approved_flag(path: Path) -> bool | None:
     """정본 `frontmatter.approved`. 정본이 없으면(schema-v1) None."""
     loaded = _load_final_report_data_if_present(path)
@@ -317,7 +342,10 @@ def _reject_blocking_plan_body_gate(path: Path, body: str, *, action: str) -> No
     if loaded is not None:
         data_path, data = loaded
         data_gate = _data_json_gate_result(data)
-        if data_gate in BLOCKING_PLAN_BODY_GATES:
+        if (
+            data_gate in BLOCKING_PLAN_BODY_GATES
+            and _blocking_gate_survives_user_decision(data, data_gate)
+        ):
             raise PrepareError(
                 f"{action} rejected because approved plan data.json Gate result is "
                 f"`{data_gate}`: {data_path}\n"
@@ -421,7 +449,10 @@ def _set_data_json_approved_true_if_present(path: Path) -> bool:
         return False
     data_path, data = loaded
     data_gate = _data_json_gate_result(data)
-    if data_gate in BLOCKING_PLAN_BODY_GATES:
+    if (
+        data_gate in BLOCKING_PLAN_BODY_GATES
+        and _blocking_gate_survives_user_decision(data, data_gate)
+    ):
         raise PrepareError(
             f"--approve rejected because approved plan data.json Gate result is "
             f"`{data_gate}`: {data_path}"
@@ -555,7 +586,7 @@ def _validate_approved_plan(path: str) -> None:
     _reject_blocking_plan_body_gate(p, "", action="approved plan validation")
     _validate_approved_plan_conformance(p)
     # frontmatter approved == true 상태. §1 Clarification Items 의
-    # Blocks=approval 행이 아직 open/answered 면 승인을 무효화한다.
+    # Blocks=approval 행이 아직 진행 처분 없이 열려 있으면 승인을 무효화한다.
     scan = scan_approval_gate(p)
     if scan.unreadable_reason:
         raise PrepareError(

package/runtime/python/okstra_ctl/user_response.py

@@ -57,6 +57,7 @@ from okstra_ctl.paths import resolve_under_root
 from okstra_ctl.run_context import dir_flock
 from okstra_ctl.clarification_items import (
     ClarificationItem,
+    UNRESOLVED_STATUSES,
     read_clarification_rows,
     sidecar_answers,
     _section_1_slice,
@@ -885,7 +886,7 @@ def _open_blocker_rows(report_path: Path) -> list[dict[str, Any]]:
         row
         for row in rows
         if row["item"].blocks in {"approval", "next-phase"}
-        and row["item"].status in {"open", "answered"}
+        and row["item"].status in UNRESOLVED_STATUSES
         and row["item"].row_id not in answered
     ]
 

package/runtime/skills/okstra-run/SKILL.md

@@ -390,4 +390,4 @@ Do not read the wizard state file directly. `okstra wizard outcome` exposes any
 
 - Echo each captured answer (`result.echo`) on one short line so the user sees what was registered.
 - Never invent identity; if a `text` prompt returns an empty answer where the wizard rejects it, the user must retry.
-- After Step 6, begin the lead workflow without re-summarizing the skill itself. For a single run, the end of Step 6 is the end of the run — but in an unattended chain where `orchestration.chainStages` has 2+ elements, repeat Step 6 per stage until Step 7's queue is empty (or it stops at a "not ready" / exception gate), then finish. When the lead (or this skill, after the lead returns) reports the run over, close with the user's next action — one command they can run now. A prohibition is not a next action. After `implementation-planning`, read `workflow.awaitingApproval` and the next-phase pointer from the task manifest. Open or answered `blocks: approval` rows → `/okstra-user-response`. Awaiting approval → `/okstra-run` → `implementation` or `--approve` (do not start another planning run). Phase 7 `validate-run` failed → one-line cause, then `/okstra-run` to re-run this phase with the sidecar, or `/okstra-inspect recap`. Pointer `status: ready` → `/okstra-run` for that phase. Otherwise `/okstra-inspect status`.
+- After Step 6, begin the lead workflow without re-summarizing the skill itself. For a single run, the end of Step 6 is the end of the run — but in an unattended chain where `orchestration.chainStages` has 2+ elements, repeat Step 6 per stage until Step 7's queue is empty (or it stops at a "not ready" / exception gate), then finish. When the lead (or this skill, after the lead returns) reports the run over, close with the user's next action — one command they can run now. A prohibition is not a next action. After `implementation-planning`, read `workflow.awaitingApproval` and the next-phase pointer from the task manifest. Open `blocks: approval` rows → `/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). Phase 7 `validate-run` failed → one-line cause, then `/okstra-run` to re-run this phase with the sidecar, or `/okstra-inspect recap`. Pointer `status: ready` → `/okstra-run` for that phase. Otherwise `/okstra-inspect status`.

package/runtime/validators/validate-run.py

@@ -88,6 +88,13 @@ from okstra_ctl.incremental_scope import (  # noqa: E402
     stages_for_clarification,
 )
 from okstra_ctl import next_phase  # noqa: E402
+from okstra_ctl.clarification_items import (  # noqa: E402
+    APPROVAL_BLOCKS,
+    PROCEEDING_DISPOSITIONS,
+    clarification_disposition,
+    progress_blocking_ids,
+    row_blocks_progress,
+)
 from okstra_ctl.workflow import (  # noqa: E402
     ERROR_ANALYSIS_ROUTING_DIRECTIONS,
     PHASE_SEQUENCE,
@@ -4188,40 +4195,31 @@ def _plan_item_ids_for_clarification(
     ]
 
 
-def _resolved_noncritical_dissent_ids(data: dict) -> set[str]:
-    """Plan items whose remaining dissent the user explicitly accepted."""
+def _user_accepted_plan_item_ids(data: dict) -> set[str]:
+    """사용자가 진행 처분을 고른 승인 행이 가리키는 계획 항목.
+
+    DISAGREE 표는 그대로 남는다. 게이트만 `has-dissent` 로 내린다.
+    """
     accepted: set[str] = set()
     for row in data.get("clarificationItems") or []:
         if not isinstance(row, dict) or row.get("blocks") != "approval":
             continue
-        context = row.get("approvalContext")
-        if not isinstance(context, dict):
-            continue
-        resolution = _clarification_resolution(row, context)
-        if (
-            row.get("status") != "resolved"
-            or context.get("classification") != "noncritical-dissent"
-            or not isinstance(resolution, dict)
-            or resolution.get("disposition") != "accept-risk"
-            or not str(resolution.get("userText") or "").strip()
+        if row_blocks_progress(
+            str(row.get("status") or ""), clarification_disposition(row)
         ):
             continue
-        row_id = str(row.get("id") or "")
-        if context.get("planItemIds") or context.get("activityIds"):
-            if not _approval_context_activity_refs_exist(
-                data, row_id, context, resolution
-            ):
-                continue
-            accepted.update(
-                item_id
-                for item_id in context.get("planItemIds") or []
-                if isinstance(item_id, str)
-            )
-            continue
+        context = row.get("approvalContext")
+        if not isinstance(context, dict):
+            context = {}
         accepted.update(_plan_item_ids_for_clarification(row, context, data))
     return accepted
 
 
+def _resolved_noncritical_dissent_ids(data: dict) -> set[str]:
+    """호환 별칭. 새 코드는 `_user_accepted_plan_item_ids` 를 쓴다."""
+    return _user_accepted_plan_item_ids(data)
+
+
 def _is_dissent_downgraded(
     item: dict,
     pbv: dict,
@@ -4229,16 +4227,11 @@ def _is_dissent_downgraded(
 ) -> bool:
     """Whether a surviving `majority-disagree` item stops blocking approval.
 
-    Exhausting the automatic self-fix budget records the unresolved dissent but
-    does not accept it. Only an explicit, resolved noncritical risk-acceptance
-    row can lower the item to `has-dissent`. Correctness-critical defects remain
-    blocking regardless of the user's selected disposition.
+    사용자 진행 처분(`accept-risk` / `select` / `answer`)이 있으면 표는 남기고
+    게이트만 `has-dissent` 로 내린다. 분류와 자가수정 소진 여부는 보지 않는다.
     """
     return (
         _classify_plan_item_gate(item) == "majority-disagree"
-        and not _is_correctness_critical(item)
-        and _has_planner_fixable_majority(item)
-        and _self_fix_budget_exhausted(pbv)
         and str(item.get("id") or "") in accepted_item_ids
     )
 
@@ -4554,11 +4547,15 @@ def _gate_blocking_causes(
 
 
 _APPROVAL_DISPOSITIONS_BY_CLASSIFICATION = {
-    "user-decision": frozenset({"select", "request-revision", "reject"}),
+    "user-decision": frozenset(
+        {"select", "accept-risk", "request-revision", "reject"}
+    ),
     "noncritical-dissent": frozenset(
         {"accept-risk", "request-revision", "reject"}
     ),
-    "correctness-critical": frozenset({"request-revision", "reject"}),
+    "correctness-critical": frozenset(
+        {"accept-risk", "request-revision", "reject"}
+    ),
 }
 
 
@@ -5026,6 +5023,8 @@ def _validate_resolved_approval(
             f"final-report data.json: resolved approval clarification `{row_id}` "
             "requires non-empty resolution.userText."
         )
+    if str(resolution.get("disposition") or "") in PROCEEDING_DISPOSITIONS:
+        return
     check_refs = resolution.get("checkRefs")
     if not isinstance(check_refs, list) or not any(
         isinstance(value, str) and value for value in check_refs
@@ -5174,6 +5173,7 @@ def _validate_correctness_resolution(
     if (
         context.get("classification") != "correctness-critical"
         or row.get("status") != "resolved"
+        or clarification_disposition(row) in PROCEEDING_DISPOSITIONS
     ):
         return
     row_id = str(row.get("id") or "<unknown>")
@@ -5426,11 +5426,13 @@ def _validate_approval_context(
             activity_timestamps,
             failures,
         )
-        if report_approved and row.get("status") in {"open", "answered"}:
+        if report_approved and row_blocks_progress(
+            str(row.get("status") or ""), clarification_disposition(row)
+        ):
             failures.append(
                 f"final-report data.json: approval is true while clarification `{row_id}` "
-                f"has status `{row.get('status')}`; open and answered approval "
-                "rows remain blocking."
+                f"has status `{row.get('status')}`; open and return-disposition "
+                "approval rows remain blocking."
             )
 
 
@@ -5502,7 +5504,9 @@ def _validate_v3_approval_context(data: dict, failures: list[str]) -> None:
             row, context, failures, schema_version="3.0"
         )
         _validate_v3_resolution_links(row, activities, failures)
-        if approved and row.get("status") in {"open", "answered"}:
+        if approved and row_blocks_progress(
+            str(row.get("status") or ""), clarification_disposition(row)
+        ):
             failures.append(
                 f"final-report data.json: approval is true while clarification "
                 f"`{row.get('id')}` remains `{row.get('status')}`."
@@ -6261,11 +6265,8 @@ def _next_step_texts(steps: object) -> list[str]:
 
 
 def _has_unresolved_approval_blocker(data: dict) -> bool:
-    return any(
-        isinstance(row, dict)
-        and row.get("blocks") == "approval"
-        and str(row.get("status") or "") in {"open", "answered"}
-        for row in data.get("clarificationItems") or []
+    return bool(
+        progress_blocking_ids(data.get("clarificationItems"), APPROVAL_BLOCKS)
     )
 
 
@@ -6277,7 +6278,14 @@ def _planning_gate_blocks_approval(data: dict) -> bool:
     if not isinstance(verification, dict):
         return False
     gate = str(verification.get("gateResult") or "").strip().lower()
-    return gate in {"blocked-by-disagreement", "aborted-non-result"}
+    if gate == "aborted-non-result":
+        return True
+    if gate != "blocked-by-disagreement":
+        return False
+    return _has_unresolved_approval_blocker(data) or not any(
+        isinstance(row, dict) and row.get("blocks") == "approval"
+        for row in data.get("clarificationItems") or []
+    )
 
 
 def _validate_rerun_guidance(data: dict, failures: list[str]) -> None: