codex-workflow-v2 2.0.0-beta.12 → 2.0.0-beta.12.10

package/docs/validation-report.md

@@ -1,98 +1,105 @@
-# V2 beta.12 Validation Report
+# V2 beta.12.10 Validation Report
 
-Release candidate `2.0.0-beta.12` was validated on 2026-08-27 with Node.js 24.17.0.
+Release candidate `2.0.0-beta.12.10` was validated on 2026-08-31 (Europe/Moscow) with
+Node.js 24.17.0.
 
 ## Automated release evidence
 
-- `npm ci` completed from the committed lockfile with 0 reported vulnerabilities.
-- The final `npm run validate` passed `321/321` sequential tests with no failures, skips,
-  cancellations, or todos. The focused Signal T04 recovery suite passed independently (`5/5`).
-- `npm run pack:check` passed outside the filesystem-restricted sandbox. The beta.12 tarball
-  contains 269 files; package size is 955.6 kB and unpacked size is 3.7 MB.
-- `npm run smoke:downstream` packed and installed the actual beta.12 tarball in an empty temporary
-  project, then passed the packaged CLI handshake. The first sandboxed attempt was network-blocked
-  while fetching pinned `ajv`; the authorized network retry passed.
-- `npm run plugin:check`, the official Codex plugin validator, `npm run docs:pdf:check`, exact
-  `RELEASE_TAG=v2.0.0-beta.12 npm run release:check`, and `git diff --check` passed. The bundled
-  gateway cachebuster is `0.1.0+codex.20260827003726`.
-
-The first full post-version-bump validation exposed three failures before the Signal T04 runtime
-scenario began: a historical read-only snapshot truthfully targeted beta.11, while its replay
-assertion incorrectly required the current package version. The fix keeps the snapshot immutable at
-`2.0.0-beta.11`, binds the synthetic replay dependency to current `PACKAGE_VERSION`, and makes the
-release check verify both identities separately. The focused suite then passed `5/5`, and the final
-complete suite passed `321/321`.
-
-## Continuable remediation and review-routing evidence
-
-- A guarded Task remains in the same Task/Step and reaches a passing strict review after five
-  consecutive failed review cycles. Attempts 1–2 are ordinary; attempts 3+ are corrective
-  diagnostics but remain executable and review-gated.
-- Attempt count no longer selects a terminal lifecycle transition. It is retained as diagnostic
-  history only; explicit `split-required` and `stop-escalate` remain the stop authorities.
-- A failed review defaults to `route=fix` (or an omitted route) and continues the same Task/Step.
-  `route=replan` is valid only with exact `planClause`, `whyFixCannotFit`, and `minimalPlanChange`
-  evidence.
-- Replan returns to ordinary `task plan-set`; objective, requirements, and acceptance remain
-  immutable, while only implementation Steps may change. The replacement Plan still passes the
-  normal Plan Risk Audit and execution-authorization gates.
-- Failed-review routing evidence is hash-chained in the public Step Review event schema. Drift,
-  malformed evidence, unrelated Knowledge changes, forged actors, and corrupt chains remain
-  fail-closed.
-
-## Retained dependency, feasibility, and recovery evidence
-
-- P04-A retains the canonical Milestone dependency DAG, atomic initial Plan transaction/recovery,
-  dependency-bound handoff/claim/start, legacy fail-closed policy, and unconditional structural
-  replacement shutdown.
-- P01-A retains three versioned read-only analyzers, canonical in-event evidence/hash binding,
-  exact pre-start and corrective source selection, and phase-aware freshness before claim/start/run.
-- The exact Signal T04 revision-26 fixture still proves that only a verified historical Step Review
-  can retain its completion commit across corrective replan. Pending review is never trusted, and a
-  corrupt strict-review hash chain is rejected.
-- Bounded beta.11 `task plan-integrity-recover` compatibility remains green for its exact first
-  ordinary checks-failed case. It does not edit the Plan, package manifest, or worktree and still
-  fails closed for writable-manifest scope, unrelated dirty files, binding drift, or tampering.
-- Read-only Milestone progress still preserves `T03 cancelled → T08 replacement`; project-monotonic
-  chat allocation and deterministic long-title fallback/readback remain green.
-
-## Packaged real-agent lifecycle replay
-
-- A fresh disposable Git project installed the locally packed beta.12 tarball, declared the exact
-  `2.0.0-beta.12` dependency, and passed packaged `gateway handshake` plus `doctor` with protocol 2,
-  state schema 2, current dependency identity, and a clean checkout.
-- The trusted harness invoked the real packaged CLI sequentially for handshake, doctor, direct first
-  Discovery bootstrap, `status`, and fresh `next`. The resulting navigation advertised
-  `project-memory scan`.
-- `node scripts/validate-lifecycle-transcript.mjs` accepted all `10/10` post-provenance events with
-  no failed invocation, unadvertised mutation, or missing checkpoint. The semantic log SHA-256 is
-  `ab4ef10ad00e2fd9f54810ec5d0bbfb4106e1b211b3a185869d8a46787a5062d`; the raw packaged-result
-  log SHA-256 is `e693a839604c7ba2055f99e43c49c5ab63ac0cf6e790adc901db5dd8eb0ffae9`.
-- Credential-marker inspection found no writer, claim, delegation, bearer, or secret material, and
-  the disposable product checkout remained clean. Logs and external workflow state stayed outside
-  this repository.
-
-This replay validates package resolution, clean bootstrap, one real mutation, and mandatory
-post-mutation navigation discipline. It does not claim a second full product Milestone replay;
-deeper remediation, P01-A, and P04-A behavior is covered by deterministic and integration tests.
-
-## beta.12 PDF release documentation evidence
-
-- Three tracked Russian PDFs were deterministically regenerated from reviewable Markdown sources
-  under `docs/pdf/sources/`; `npm run docs:pdf:check` reported an empty stale set.
-- All 24 pages were rendered and visually inspected: architecture is 6 pages, the delegated
-  chat-only guide is 8 pages, and the technical reference is 10 pages. No blank, clipped, or orphaned
-  page was found.
-- Visible titles, headers, package commands, and release gates identify beta.12. The content covers
-  continuable remediation, evidence-bound fix/replan routing, Milestone dependency authority,
-  P01-A mechanical feasibility, C1 credentials, external-sealed review, Plan-integrity compatibility,
-  structural-replacement shutdown, and the limited derived-graph role of `codebase-memory-mcp`.
-
-## Not claimed
-
-- Validation itself performs no npm publication, Git tag, push, Signal Workflow mutation, or local
-  plugin reinstall. Tagging and remote push are separate actions after the exact candidate gates.
-- Structural replacement remains intentionally disabled; beta.12 does not claim P04-B replacement
-  materialization or completed-Step adoption.
-- A real project must install the published exact beta.12 package, update/reinstall the bundled
-  gateway, and follow fresh project-local `handshake → doctor → status → next` navigation.
+- `npm ci` completed from the exact lockfile with 0 reported vulnerabilities.
+- `npm run validate` passed typecheck and `344/344` sequential tests with no failures, skips,
+  cancellations, or todos in 2,087,253.659208 ms.
+- `npm run test:signal-remediation-e2e` passed the focused Signal-shaped end-to-end scenario.
+  The test starts from an active Milestone whose required Task has a current `stop-escalate` Plan
+  Risk Audit, materializes one audited upstream remediation Task, completes its Plan/audit/C1/Step/
+  review/accept/merge lifecycle, replans the original Task, and completes a later Step there.
+- Negative coverage rejects a non-exact predecessor frontier, duplicate remediation, stale revisions,
+  non-required or non-active Milestone posture, topology drift, reused audit evidence, and ordinary
+  standalone/post-execution `stop-escalate` cases that must keep the existing `task plan-set` route.
+- The complete lifecycle inventory names `milestone remediation-materialize` and
+  `WorkflowService.materializeAuditedRemediationTask`; read-only purity, transaction rollback/
+  roll-forward, concurrent writers, credentials, Core receipts and prior Signal compatibility tests
+  all passed.
+- Package dry-run produced `codex-workflow-v2-2.0.0-beta.12.10.tgz` with 278 files, 1,050,219 bytes
+  packed and 4,196,113 bytes unpacked. The broad `docs` package allowlist was narrowed so the
+  repository-local `docs/quality` observation journal cannot enter the tarball. The first invocation
+  encountered a root-owned user npm cache (`EPERM`); the exact retry used an isolated temporary cache.
+- `npm run smoke:downstream` built and installed the tarball in a disposable consumer project and
+  returned `ok=true`. The sandboxed attempt could not resolve npm (`ENOTFOUND`); the same command
+  passed with network access.
+- `npm run plugin:check` passed for bundled gateway
+  `0.1.0+codex.20260830183000`.
+- `npm run docs:pdf:check` reported an empty stale set and exact beta.12.10 package binding.
+- `RELEASE_TAG=v2.0.0-beta.12.10 npm run release:check` and `git diff --check` passed after this
+  report and the exact package allowlist were recorded.
+
+## Root cause corrected by beta.12.10
+
+An active Milestone could reach a genuine pre-execution dead end when a required Task's current Plan
+Risk Audit truthfully returned `stop-escalate` because an upstream capability did not exist. The old
+choices were insufficient: replanning the same Task could not manufacture the missing capability,
+while the generic scope-change path required a separate human approval and permitted a much wider
+semantic change than the evidence justified.
+
+The problem was missing bounded topology authority, not an insufficient number of implementation or
+review attempts. Repeating the blocked Task could only reproduce the same unmet prerequisite.
+
+## Implemented lifecycle contract
+
+- Fresh `next` advertises audited remediation only for an `awaiting_execution_authorization`
+  required Task of an active Milestone with a current `stop-escalate` Plan Risk Audit. Standalone,
+  post-execution, `split-required`, and other stop postures preserve their existing routes.
+- Coordinator first records a normal capability Discovery. `milestone remediation-materialize`
+  then performs one project transaction that appends exactly one required remediation Task and adds
+  exactly one dependency edge from the blocked Task to it.
+- The new Task must inherit the blocked Task's exact direct predecessor frontier, and every predecessor
+  must already be merged. Milestone outcome, success signal, acceptance, checks, base, old memberships
+  and all unrelated dependency edges remain byte-semantically unchanged.
+- The scope-change event binds Milestone revision, blocked Task revision, Brief/Plan hashes, exact Plan
+  Risk Audit event/hash, remediation Discovery revision, new Task identity and predecessor frontier.
+  Reuse or topology drift fails closed.
+- A `corrective-derived` authorization, bound to the audited evidence and exact actor
+  `agent:milestone-remediation:<MS-ID>`, replaces the superseded Milestone execution authorization.
+  It authorizes only current required Task execution acceptance transitions; it is neither a general
+  delegation grant nor human impersonation.
+- The remediation route requires no human approval. After its Task merges, the original Task returns
+  to `task plan-set`, must receive a semantically new Plan and fresh Plan Risk Audit, and then proceeds
+  through the ordinary C1, checks, commits and reviews.
+- Public handshake capabilities include `audited-remediation-topology-v1` and
+  `corrective-derived-task-authority-v1`.
+
+## Signal-shaped evidence
+
+The release E2E mirrors the observed Signal deadlock: four already merged provider Tasks, one blocked
+required consumer Task, a current pre-execution `stop-escalate` audit, and a missing upstream
+capability. It proves the entire recovery cycle rather than only the new materialization command.
+
+Live Signal installation and mutation are intentionally separate post-publication actions. They must
+use exact repository-local beta.12.10, a clean/idle update boundary, fresh `status -> next`, and the
+advertised compatibility/recovery route if the dependency update advances active Milestone base
+state. No manual state edit, Git history rewrite, Task cancellation, or duplicate Milestone is part of
+the release mechanism.
+
+## PDF release documentation evidence
+
+- All three tracked Russian PDFs were regenerated from beta.12.10 Markdown sources.
+- Architecture is 8 pages, the delegated chat-only guide is 10 pages, and the technical reference is
+  12 pages. All 30 pages were rendered and visually inspected; the changed recovery sections were
+  checked at full-page resolution.
+- Titles, package bindings, Cyrillic text, tables, code blocks, margins, footers and section transitions
+  have no visible clipping, overlap or unreadable content.
+
+## Existing boundaries and non-claims
+
+- The new route does not permit arbitrary Task insertion, task removal, semantic Milestone scope
+  change, arbitrary dependency rewiring, completed-Step adoption or `split-required` replacement.
+- Human approval is removed only from this exact evidence-derived corrective topology transition.
+  Final Milestone acceptance and generic semantic scope changes retain their existing authority model.
+- Protocol version remains 2 and state schema remains 2; older projects remain readable without a
+  state migration.
+- No Git commit, tag, remote push, npm publication or live Signal recovery is claimed by this
+  pre-publication report.
+
+Confidence is high for the package implementation, topology invariants, no-human corrective authority,
+regression compatibility, tarball composition, downstream installation, plugin and documentation.
+Live Signal confidence remains conditional on successful publication, exact dependency installation,
+fresh Core readback and Coordinator completion of the advertised remediation route.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-workflow-v2",
-  "version": "2.0.0-beta.12",
+  "version": "2.0.0-beta.12.10",
   "description": "Requirements-first Codex development workflow with local state and explicit Git ownership.",
   "repository": {
     "type": "git",
@@ -33,7 +33,10 @@
     "roles",
     "references",
     "plugins",
-    "docs",
+    "docs/*.md",
+    "docs/lifecycle",
+    "docs/pdf",
+    "docs/problem-briefs",
     "scripts/generate-pdf-docs.py",
     "scripts/run-pdf-docs.mjs",
     "README.md"
@@ -44,6 +47,8 @@
     "typecheck": "tsc -p tsconfig.json --noEmit",
     "test": "node scripts/with-validation-lock.mjs test",
     "test:signal-t04-recovery": "node scripts/with-validation-lock.mjs test-signal-t04",
+    "test:signal-t03-replan-e2e": "node scripts/with-validation-lock.mjs test-signal-t03-replan",
+    "test:signal-remediation-e2e": "node scripts/with-validation-lock.mjs test-signal-remediation-topology",
     "validate": "npm run typecheck && npm test",
     "pack:check": "npm run build && npm pack --dry-run",
     "smoke:downstream": "npm run build && node scripts/downstream-smoke.mjs",

package/plugins/codex-workflow-gateway/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-workflow-gateway",
-  "version": "0.1.0+codex.20260827003726",
+  "version": "0.1.0+codex.20260830183000",
   "description": "Thin personal Codex gateway for exact project-local Codex Workflow V2 packages and codebase-memory-mcp.",
   "author": {
     "name": "Codex Workflow Maintainers"

package/plugins/codex-workflow-gateway/references/protocol.md

@@ -1,6 +1,6 @@
 # Gateway Protocol V2
 
-## beta.12 continuable remediation, coordinator projections, and retained recovery compatibility
+## beta.12.6 compatibility transitions and continuable remediation
 
 - When fresh `next` advertises `task plan-integrity-recover`, consume its exact Task revision,
   Step, actor, and writer-token contract. This route is valid only for the Core-derived
@@ -8,12 +8,54 @@
   It records a replan posture without changing Plan or product files; corrective yield and the
   existing state-bound corrective-replan Human gate remain mandatory.
 
+- When fresh `next` advertises `task downstream-proof-recover`, Core has proved that every dirty
+  file outside the active Step belongs to a completed transitive predecessor and that recorded Git
+  history is intact. Invoke the exact lease-bound transition once. It preserves product files and
+  HEAD, invalidates stale predecessor completion authority with an append-only event, yields C1,
+  and routes the same Task to ordinary `task plan-set`. The replacement Plan, risk audit, and
+  execution authorization are fresh authority; no Task or Milestone recreation is involved.
+
+- When an older installed package cannot reach that recovery because its normal update preflight
+  requires a clean checkout, beta.12.6 permits one bounded dependency transport. The active
+  Milestone base and Task branch must first receive separate exact commits changing only
+  `package.json` and `package-lock.json`; product work remains dirty and uncommitted. Fresh beta.12.6
+  `next` must then advertise `update downstream-proof-dependency-recover`. Its preflight proves the
+  Task history at `HEAD^`, the dependency candidate at `HEAD`, aligned version surfaces, no lease or
+  transaction, exact predecessor ownership, and a content hash of the dirty set. Recovery registers
+  only the dependency commit. It does not mutate product files or Step state; fresh `next` must
+  proceed to `task downstream-proof-recover`, which outranks manifest-induced Knowledge staleness.
+
 - `update dependency-provenance-preflight --id <TASK-ID>` is read-only. The matching
   `update dependency-provenance-recover --id <TASK-ID> --expected-revision <N> --actor <ACTOR>
   --reason <TEXT>` is valid only when preflight and fresh `next` both advertise it. Historical
   product commits absent from the current corrective Step are recognized only through intact passed
   strict-review plus verified reviewer-attestation chains and remain separately auditable as
   `retainedHistoricalCommits`.
+  Task-local manifest/lock fields from recorded history may differ from the base, but the candidate
+  commit must preserve them exactly while changing only the Workflow dependency entries.
+- `task historical-step-provenance-preflight --id <TASK-ID>` is read-only. The matching
+  `task historical-step-provenance-recover` is available only for one unexpected product commit
+  with an intact passed strict-review chain, matching prior final acceptance, no lease or pending
+  operation, and dirty files confined to the current active Step. It retains historical authority
+  without changing Git, worktree bytes, or the current Plan.
+- `update historical-step-dependency-preflight/recover` handles the same proof when the beta.12.9
+  dependency-only commit is the unregistered HEAD. It binds the exact dependency candidate and the
+  reviewed historical Step commit in one recovery record, preserves active product bytes, and then
+  requires fresh `status` and `next`.
+- `task stop-override-prepare` is a read-only Human gate for the exact beta.11 attempt-four stop
+  shape. `task stop-override-apply` requires the same Task revision, Step, actor, reason, Plan, HEAD,
+  evidence binding, and returned `SOO-*` code in a later user turn. It appends evidence without
+  deleting `stop-escalate`; it never applies to `split-required`.
+- After an applied stop override, one or more ordinary delegated `task context-refresh` transitions
+  may rebind the Plan before attempt four. Fresh `next` returns `task run` only when Core validates
+  the complete contiguous Plan/rebind/audit chain, mechanical equivalence at every hop, shared
+  delegated authority, and append-only chronology. HEAD may differ from the override only when every
+  intervening commit is an exact registered dependency-provenance recovery changing only
+  `package.json` and `package-lock.json`. If C1 remains claimed but the lease was lost at the Human
+  boundary, use only the simultaneously advertised `task writer-credential-replace` action.
+  A provenance recovery recorded after the final context-refresh audit may explain exactly one
+  additional Task revision only when it belongs to that verified Git chain. Any unexplained
+  revision remains a `doctor` boundary.
 - `milestone progress --id <MS-ID>` is a read-only projection and the sole source for Coordinator
   progress tables. It preserves cancelled/replacement Tasks as distinct membership rows.
 - `scripts/chat-registry.mjs` atomically allocates project-monotonic `#NNN`, builds all six title
@@ -49,6 +91,11 @@ Current capability set:
 - `corrective-plan-audit-v1`
 - `safe-update-preflight-v1`
 - `bounded-dependency-provenance-recovery-v1`
+- `task-local-dependency-provenance-recovery-v1`
+- `legacy-stop-escalate-override-v1`
+- `stop-override-context-rebind-v1`
+- `stop-override-context-rebind-chain-v1`
+- `stop-override-post-audit-dependency-revision-v1`
 - `retained-reviewed-history-recovery-v1`
 - `milestone-progress-projection-v1`
 - `strict-reviewer-v1`
@@ -79,6 +126,8 @@ Current capability set:
 - `remediation-mode-recovery-v1`
 - `plan-proof-obligations-v1`
 - `bounded-plan-integrity-recovery-v1`
+- `downstream-proof-predecessor-recovery-v1`
+- `active-downstream-proof-dependency-recovery-v1`
 - `corrective-yield-journal-v1`
 - `corrective-replan-journal-v1`
 - `corrective-replan-human-gate-v1`
@@ -154,6 +203,13 @@ actor through `--actor`; reviewer identity remains internal to the route.
 An unrecorded commit is Git history drift. Stop instead of adding another commit or editing
 workflow state manually; recovery remains coordinator-controlled.
 
+If a Docker proof fails with `EPERM`, `operation not permitted`, or `permission denied` at the
+Docker socket/CLI boundary, classify it as sandbox access, not daemon failure. Re-run the exact
+read-only health probe or Plan command once with sandbox escalation; do not charge an infrastructure
+retry. Restarting Docker Desktop or pulling another image is forbidden on this evidence alone. A
+Docker infrastructure failure exists only when an escalated call reaches Docker and independently
+proves the daemon unavailable.
+
 ## Plan Risk Audit and remediation breaker
 
 Before `task authorize`, every new alpha.7 Task requires:
@@ -187,6 +243,12 @@ explicit stop or redirection decisions. They are never inferred from attempt cou
 explicit decision, another failed strict review continues the same Task through its evidence-bound
 `fix`/`replan` route.
 
+One append-only compatibility exception exists for a beta.11 policy-created attempt-four stop.
+Fresh `next` must advertise `task stop-override-prepare`; run it with exact human inputs, present the
+complete binding, and stop. A later explicit user turn may run `task stop-override-apply` with the
+same inputs and confirmation code. Any split decision, Plan/revision/HEAD drift, missing attempt-3
+continue authority, lease, transaction, or journal damage blocks the route.
+
 ## Context refresh
 
 Before `task plan-set`, compare exact Step `allowedWrites` and expected output paths with scanner
@@ -247,6 +309,12 @@ working memory. In claimed C1 posture, fresh `next` exposes `writerTokenContract
 pass the receipt token through its declared `--writer-token` option on the first run call. The
 successful run returns the refreshed writer receipt for later lease-bound transitions.
 
+`task result-set` is also lease-bound. It requires the active `--writer-token` and the exact C1
+claimant in `--actor` when the Task is claimed. Success releases the lease before the Task enters
+`awaiting_final_acceptance`; the token is no longer valid. The Human gate must therefore remain
+lease-free for an arbitrary amount of time. After acceptance, obtain the new merge credential only
+through the `writerCredentialRecovery` action advertised by fresh `next`.
+
 ## Milestone assembly, autonomy, and human gate
 
 During initial planning, materialize every linked Task and then call `milestone plan-set` once

package/plugins/codex-workflow-gateway/skills/codex-workflow-gateway/SKILL.md

@@ -50,6 +50,37 @@ pending/corrupt transaction. After success run sequential `status` then `next` a
 returned lifecycle action; Knowledge reconciliation or atomic Task context refresh may legitimately
 be next because the dependency files changed.
 
+When beta.12.9 fresh `next` advertises `task historical-step-provenance-recover`, Core has found
+exactly one product commit that a corrective Plan omitted from current Step evidence even though the
+commit still has a complete hash-valid passed strict Step Review chain and a matching prior final
+acceptance. First run the advertised read-only `task historical-step-provenance-preflight --id
+<TASK-ID>` and require `eligible=true`, the exact Task revision/Plan/Brief/HEAD, the advertised
+commit SHA, no lease/transaction/Core operation, and dirty files confined to the one active Step's
+`allowedWrites`. Invoke recovery with that exact commit, actor, and a substantive reason. The
+transition records the commit as invalidated historical Step authority plus an audit record; it does
+not adopt the completed Step into the current Plan and does not create, remove, amend, reset, rebase,
+or merge Git commits. Reject multiple or arbitrary unexpected commits, pending/failed review,
+mismatched final acceptance, unrelated dirty files, or damaged sidecars. After success run
+sequential `status` then `next`; the active corrective Step should resume through its ordinary
+credential and `task step-complete` route.
+
+When beta.12.9 must itself be installed while this exact historical Step blocker is active, preserve
+the Task worktree and create only two dependency transport commits: one on the active Milestone base
+and one at Task-branch HEAD, each changing exactly `package.json` and `package-lock.json` to the exact
+beta.12.9 package. Do not switch the dirty Task checkout to update the base; use a separate temporary
+worktree. Install the repository-local target package, then require fresh `next` to advertise
+`update historical-step-dependency-recover`. Run the matching read-only preflight and require the
+exact dependency HEAD/parent, Task revision, active Step/Plan, retained historical SHA, dirty-file
+set and dirty-worktree hash, with no lease or pending operation. The matching recover registers both
+authorities without modifying product bytes or Git. After recovery run sequential `status` and
+`next`; do not substitute ordinary dependency recovery, manual state edits, rebase, reset, or amend.
+
+Beta.12.1 permits product-owned manifest/lock fields already present in the exact recorded Task
+history to differ from the Milestone base. Core compares candidate parent to candidate HEAD after
+removing only the Workflow dependency entries, so the dependency commit must preserve every such
+field exactly. Do not rebase, copy the base manifest over Task-local scripts, or interpret this as
+permission for product payload in the candidate commit.
+
 The beta.11 bounded Plan-integrity route prevents a known impossible check from consuming a second
 ordinary remediation attempt. Use `task plan-integrity-recover` only when fresh `next` advertises
 it for the exact failed Task/Step/revision. Require `state=eligible`, no blockers, one first
@@ -61,6 +92,20 @@ active writer token when the C1 contract requires it. The recovery records only
 `task run` merely to manufacture the second failure, and never invoke this recovery for a generic
 test failure, a writable manifest, or unconfined changes.
 
+When fresh `next` advertises `task downstream-proof-recover`, the active proof Step has produced
+uncommitted files inside its own `allowedWrites` and has also exposed required changes owned by one
+or more completed transitive predecessor Steps. Do not invoke `task step-complete`: its scope is
+known to be stale. Use only the exact returned Task revision, claimant/lease actor, writer-token
+contract, and a substantive reason. The atomic recovery preserves the worktree and HEAD, moves the
+predecessor completion commits into historical `invalidatedStepCommits`, clears only the invalidated
+completion evidence, blocks the active proof Step, supersedes execution authorization, appends
+`downstream-proof-invalidations.jsonl`, releases C1/lease authority, and returns the same Task to
+ordinary `task plan-set`. Build the replacement Plan from the full unfinished remainder, attach a
+fresh Plan Risk Audit, then obtain fresh execution authorization. Never use this route for an
+unrelated dirty file, a non-predecessor file, unregistered Git history, strict-review evidence, or
+without explicit fresh `next` eligibility. Do not reset, stash, commit, or recreate the Task or
+Milestone around this transition.
+
 If any step fails, report the concrete diagnostic. Do not load workflow
 semantics from this skill.
 
@@ -87,6 +132,36 @@ into Plan `acceptance` as exact array members; semantic prose may be added but c
 IDs. Bind the Plan to the returned `briefHash` and active `knowledgeMap` revision/hash. Stop if the
 contract is absent or conflicts with the current Task/Knowledge state.
 
+When fresh repository `next` reports `planRiskAuditDecision.state=recorded-blocking`, decision
+`stop-escalate`, and an `auditedRemediation` object, do not retry authorization and do not invent a
+free-form Milestone scope change. Follow only the advertised route:
+
+1. If action is `discovery start`, create one Discovery for the exact missing upstream capability
+   proved by the audit. Preserve the current Milestone outcome, success signal, acceptance, checks,
+   and original Task scope. Resolve factual unknowns from repository evidence; a genuine unresolved
+   product decision remains a semantic blocker.
+2. If action is `discovery update`, complete that same remediation Discovery until it is
+   `ready_to_materialize`; do not reuse an unrelated Discovery.
+3. If action is `milestone remediation-materialize`, use its exact Milestone/Task revisions and
+   audit binding. The JSON input contains only `discoveryId`, `expectedDiscoveryRevision`, `title`,
+   and `predecessorTaskIds`; the predecessor list must exactly equal
+   `auditedRemediation.requiredPredecessorTaskIds`. No actor, confirmation code, delegation grant,
+   replacement Milestone Plan, or human approval is accepted.
+4. Run sequential `status` then repository `next`. Core must prioritize the new remediation Task.
+   Plan, audit, hand off, implement, review, accept, and merge it normally. At Task execution
+   authorization and final acceptance, use the exact `correctiveDerivedApproval.actor` returned by
+   fresh `next`; `humanApprovalRequired` must be false. Do not pass a delegation grant.
+5. After the remediation Task is `merged`, fresh `next` must return the original blocked Task to
+   `task plan-set` with `auditedRemediation.state=merged-replan-required`. Replace its rejected Plan,
+   record a fresh Risk Audit, use the same current derived approval only when advertised, and
+   continue through at least the next ordinary Step boundary.
+
+This is an idempotent, additive topology transition bound to one exact Plan Risk Audit. Dirty Git,
+any lease/transaction/Core operation, a started blocked Task, stale Task/Milestone/audit bindings,
+non-merged or non-exact predecessors, duplicate use of the audit, or any changed Milestone semantic
+field is a hard stop. Generic `stop-escalate` shapes without `auditedRemediation` remain terminal
+user attention. Final Milestone acceptance remains an ordinary human/delegated gate.
+
 When `next` returns top-level `action: task context-refresh`, use only that atomic action for
 the returned Task/map revisions, actor, and grant. Do not run standalone `project-memory reconcile`
 first: Core rejects it because it would create a human-approval gap and strand the Task. A
@@ -103,6 +178,64 @@ command shape or consuming a replacement Discovery. Never rebind, refresh, repla
 resume, cancel, or manually replace the historical Task. Continue only after a later P04-B/P05
 package explicitly advertises a topology-preserving replacement capability.
 
+When beta.12.6 `next` advertises `task stop-override-prepare`, the route is limited to the exact
+beta.11 attempt-four policy stop: two ordinary failures, one corrective failure, a matching
+attempt-3 `continue-fix`, and a matching attempt-4 `stop-escalate` under the unchanged Plan. Invoke
+prepare with the exact Task/Step/revision, explicit human actor, and user-supplied reason. It is
+read-only. Show the returned binding and `SOO-*` code, then stop. Only a later explicit user turn may
+invoke `task stop-override-apply` with the identical inputs and code. Never delegate the gate,
+override `split-required`, edit either journal, or reuse a code after Task revision, Plan, HEAD, or
+evidence changes. Successful apply preserves the original stop, appends
+`stop-escalate-overrides.jsonl`, and requires fresh sequential `status` then `next` before attempt
+four runs through the normal strict-review cycle.
+
+After an applied override, one or more ordinary delegated `task context-refresh` transitions may
+change only the Plan's canonical Knowledge Map binding. A package update may also advance HEAD, but
+only through the exact `update dependency-provenance-recover` route advertised by fresh `next`.
+Continue only when fresh `next` advertises `task run` with
+`stopOverrideContextRebind.state=validated` for the exact override and stop decision. Core verifies
+the complete source-to-current Plan/audit/rebind chain and, when HEAD changed, every intervening Git
+commit as registered dependency-only provenance. If C1 remains claimed but the lease was lost at
+the Human boundary, first use the simultaneously advertised `task writer-credential-replace`
+action for the exact claimant. A doctor route, semantic Plan drift, an unregistered or non-dependency
+commit, missing delegated authority, a broken chain, or damaged chronology is a hard stop.
+When advertised navigation records dependency provenance after the final context-refresh audit,
+Core may account for exactly one Task revision per ordered verified recovery. Never infer this
+compatibility from revision arithmetic alone: continue only when fresh `next` returns the validated
+`task run` route. An unrelated extra revision remains a hard stop.
+
+For the exact beta.12.6 active-downstream-proof update deadlock, do not apply the ordinary
+clean-boundary update recipe and do not stash/reset/commit product work. This exception is available
+only when a completed transitive predecessor and the active proof Step already own the complete dirty
+set, no writer lease/transaction/Core operation exists, and the active Milestone base can be updated
+in a separate worktree. Commit only exact `package.json`/`package-lock.json` dependency changes on
+that base, then commit only the same dependency files on the current Task branch while leaving all
+product bytes untouched. Install the exact beta.12.6 package and use only a fresh advertised
+`update downstream-proof-dependency-recover`. Run its read-only preflight first and require
+`eligible=true`, empty blockers, exact Task revision and non-null `activeDownstreamProof` binding.
+Require recorded Task history to validate at `HEAD^` and the exact dependency-only candidate to be
+`HEAD`; neither boundary may contain an unrelated or unregistered commit. The mutation registers
+only the dependency HEAD. Immediately run sequential `status` then `next`;
+continue only to the returned `task downstream-proof-recover` (including advertised writer-credential
+recovery when required). Any unrelated dirty path, unknown history, wider candidate commit, stale
+base, version mismatch, lease, transaction, or different route is a hard stop and never authorizes
+manual external-state edits.
+
+For the exact beta.12.6 post-recovery knowledge-rebind deadlock, an exact beta.12.7 external runner
+may execute only the read-only `update downstream-proof-replan-update-preflight` before dependency
+transport. Require `eligible=true`, source version beta.12.6 on declared/locked/installed/current/base
+surfaces, the exact Task revision/HEAD/dirty hash, no current audit for the rebound Plan, and no lease,
+transaction, or Core operation. Commit only `package.json` and `package-lock.json` on the active
+Milestone base, then only the same dependency files on the Task branch without touching product
+bytes. Install beta.12.7 and follow fresh `next` only through
+`update downstream-proof-replan-dependency-recover`, then
+`task downstream-proof-replan-recover`, and finally ordinary `task plan-set`. The recovery keeps the
+same Task, history, Knowledge binding, invalidated predecessor evidence, and dirty worktree. After
+the replacement Plan is audited and authorized, `task run` is valid only when fresh `next` reports
+`downstreamProofCarryover.state=validated` for one Step owning the complete hash-bound dirty set.
+Any wider dependency commit, dirty-byte change, current audit, extra Task revision, missing binding,
+or alternate route is a hard stop.
+
 When `next` returns `milestone initial-assembly`, execution is unavailable. Follow only the
 advertised `linked-task-assembly.commands` (`discovery start` and `discovery materialize`) until all
 intended linked Tasks exist. The closing `milestone plan-set` option appears only after at least one
@@ -123,6 +256,17 @@ For `task start`, the policy applies only when choosing `--workspace-owner local
 `task step-complete`, `task merge`, and `task sync-base`, the advertised transition itself
 writes Git metadata.
 
+Treat Docker access diagnostics before classifying an infrastructure failure. `EPERM`,
+`operation not permitted`, or `permission denied` while opening the Docker socket or invoking the
+Docker CLI from a sandbox means the proof is unavailable at the current execution boundary; it is
+not evidence that the daemon or image is broken. Re-run the exact read-only health probe or exact
+Plan check once with the required sandbox escalation. This escalation rerun does not consume a
+Workflow remediation attempt or a local infrastructure retry. Only an escalated probe that reaches
+Docker and reports an unavailable daemon may be classified as a Docker infrastructure failure.
+Never start, stop, or restart Docker Desktop, pull a substitute image, or mutate Docker state merely
+because the sandboxed call returned a permission error; those actions require their own explicit
+authorization and evidence.
+
 When `next` includes `writerTokenContract`, treat it as an exact first-call precondition. Retain
 the active writer lease from the first-field `writerLeaseReceipt` returned by `task run` and pass it using the advertised `option` for that
 transition. The token is sensitive: never print, summarize, persist, or substitute a redacted
@@ -137,6 +281,16 @@ the fresh `next.writerTokenContract` requires it. Successful `task run` returns
 `writerLeaseReceipt`; retain it only until Core releases that lease.
 Never search later payload fields for either credential and never copy credentials into evidence.
 
+When a passed final Task review routes to `task result-set`, pass the active writer credential and,
+for claimed C1 posture, the exact claimant as `--actor`. A successful `result-set` consumes that
+execution lease before entering `awaiting_final_acceptance`; never reuse the old token and never
+leave or manufacture a lease while waiting for the Human decision. After `task accept`, follow fresh
+`next`: local merge or external merge confirmation normally advertises
+`task writer-credential-replace`, which acquires a new bounded lease for the exact recovery actor.
+If a Task created under beta.12.7 or earlier is already at the Human gate with a stale lease, use
+only the exact `locks repair` route returned by repository-level `next`, verify that Task revision,
+review, Result/Evidence hashes, and HEAD did not change, and stop before acceptance.
+
 Command discovery with `codex-workflow <noun> [action] --help` is read-only. Use it only when the
 exact invocation syntax is not already available from `next` and this protocol. Consume declared
 `requiredOptions` and `optionalOptions`; when `exactOptionContractAvailable=false`, consult the
@@ -381,7 +535,8 @@ Plan audit based only on count. Follow fresh `next`: ordinary findings default t
 `route=replan` is valid only with the exact Plan clause, obstruction, and minimal Plan change
 retained by Core. A remediation Plan may change implementation Steps but must preserve the Task
 objective, requirements, and acceptance. Explicit split or stop decisions still stop ordinary
-continuation.
+continuation; only an exact Core-advertised audited-remediation route may turn a pre-execution
+`stop-escalate` into additive upstream work.
 
 When `next.strictStepReview.recommendedMode` is `external-sealed`, do not launch the nested local
 reviewer from inside a Codex App sandbox. Run the advertised read-only `task step-review-packet`,

package/schemas/authorization-event.schema.json

@@ -19,7 +19,7 @@
     "evidenceHash": { "$ref": "#/$defs/nullableHash" },
     "headCommit": { "$ref": "#/$defs/nullableHash" },
     "reason": { "type": "string" },
-    "authorizationMode": { "enum": ["human", "delegated"] },
+    "authorizationMode": { "enum": ["human", "delegated", "corrective-derived"] },
     "delegation": { "$ref": "#/$defs/delegation" },
     "mechanicalFeasibility": { "$ref": "#/$defs/mechanicalFeasibility" }
   },
@@ -30,6 +30,13 @@
         "required": ["authorizationMode"]
       },
       "then": { "required": ["delegation"] }
+    },
+    {
+      "if": {
+        "properties": { "authorizationMode": { "const": "corrective-derived" } },
+        "required": ["authorizationMode"]
+      },
+      "then": { "not": { "required": ["delegation"] } }
     }
   ],
   "$defs": {