codex-workflow-v2 2.0.0-beta.13.9 → 2.0.0-beta.14

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

@@ -1,784 +1,93 @@
 ---
 name: codex-workflow-gateway
-description: Resolve and drive the exact codex-workflow-v2 package installed in the active repository, including derived codebase-memory graph refresh and fallback evidence.
+description: Operate the exact installed codex-workflow-v2 package or investigate its source, using current Core contracts and workflow codebase-memory evidence.
 ---
 
 # Codex Workflow Gateway
 
-## Boundary
+## Resolve authority
 
-This is a thin personal integration. It does not define workflow states, role
-semantics, requirements, approvals, or project knowledge. Those come from the
-exact `codex-workflow-v2` package and ordinary files in the active Git
-repository.
+Read once per chat/package revision. Core and repository evidence define workflow state;
+this skill routes work and does not grant scope, approvals, credentials or filesystem access.
 
-Never use a global workflow package, a mutable npm range, `latest`, V1 overlay
-files, or MCP ADR storage as a fallback.
+For installed use, resolve the Git root and require its exact `devDependencies.codex-workflow-v2`
+version to match the locally resolved `node_modules/codex-workflow-v2/package.json`.
+Invoke only that package's `dist/src/cli.js --repo <git-root>`; first run `gateway handshake`.
+Stop on missing/ranged/mismatched versions or an incompatible handshake. Do not substitute a
+global package, mutable tag, external runner or MCP ADR memory.
 
-## Resolve The Active Package
+For an explicitly requested blocked navigation update, the exact target may run only the read-only
+`update navigation-source-preflight`; read `docs/updating-existing-project.md` from that exact target package.
+Only an eligible source receipt permits its two dependency transports; recovery uses the newly installed local target.
 
-1. Resolve the active Git root with `git rev-parse --show-toplevel`.
-2. Read its `package.json` and require an exact version string for
-   `codex-workflow-v2` in `devDependencies`.
-3. Resolve `node_modules/codex-workflow-v2/package.json` from that root.
-4. Require the installed version to equal the declared exact version.
-5. Invoke only that package's `dist/src/cli.js` with the current Git root as
-   `--repo`.
-6. Run `gateway handshake` before other actions. Stop on package, protocol, or
-   state-schema incompatibility.
+For workflow source development, use the requested source checkout and record its Git revision
+and dirty state. Do not require a self-install or invoke a consumer's lifecycle to inspect source.
 
-The sole exception is the alpha.7 `update rescue-preflight` compatibility profile. An exact
-external alpha.7 runner may inspect a project still pinned to alpha.6 only when this read-only
-command reports `eligible=true`. Execute only its returned stale-lock repair and strict-review
-actions; do not use the external runner for any other transition or dependency mutation.
+## Orient before code discovery
 
-The beta.10 bounded dependency-provenance route is narrower than ordinary Git recovery. Use it only
-when fresh `next` advertises `update dependency-provenance-recover`. First run the read-only
-`update dependency-provenance-preflight --id <TASK-ID>` and require `eligible=true`, the same
-Task/revision/HEAD, and no blockers. The candidate must be the single unregistered HEAD after the
-recorded Task history, change exactly `package.json` and `package-lock.json`, and leave every
-declared, locked, installed, current-branch, and active Milestone-base version equal to the running
-package. A historical product commit whose current corrective Plan no longer carries Step evidence
-is admissible only when Core derives it from a complete, hash-valid `pending → review-recorded →
-attestation-verified` chain with `passed` decision and verified reviewer isolation. Raw evidence,
-pending review, a failed decision, or a damaged sidecar never establishes provenance. Recovery
-records the candidate dependency HEAD as a Workflow system commit and records admissible reviewed
-product commits separately as `retainedHistoricalCommits`; it does not relabel product work as a
-system commit and does not create, amend, reset, or merge Git history. Never use it for unknown
-product changes, multiple extra commits, a dirty checkout, any lease, an in-progress Step, or a
-pending/corrupt transaction. After success run sequential `status` then `next` and follow the exact
-returned lifecycle action; Knowledge reconciliation or atomic Task context refresh may legitimately
-be next because the dependency files changed.
+Use `codebase-memory-mcp` before filesystem code search. Knowledge Map approval is not an MCP index.
+Read [graph routing](../../references/codebase-memory-routing.md) for the exact `sourceRoot`
+selection, readiness and evidence-binding procedure. Index workflow code only; Product graph is inactive and must not be refreshed or used as a lifecycle/Knowledge gate. Record a failed operation and reason before filesystem fallback.
 
-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.
+## Follow the current 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.
+Read the current package's relevant role instruction once. At each lifecycle checkpoint, finish
+`status` successfully, then finish `next`; never run that pair concurrently. A Task chat may use
+`next --task <exact Task ID>` and must stop if another Task is returned.
 
-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.
+Execute only a fresh advertised eligible action with its exact entity, revision, actor, scope,
+evidence and credential bindings. Help describes syntax, not eligibility: obtain missing options
+from `<noun> [action] --help` and schemas; if its contract is incomplete, inspect the exact
+current implementation or report the missing contract. Never guess or replay an uncertain mutation.
+After help, a mutation or changed binding, repeat `status` then `next` before any mutation.
 
-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
-`checks-failed` remediation, an exact missing root npm script, `package.json` outside the Step's
-`allowedWrites`, and a dirty-file set confined to that Step. Pass the exact returned actor and the
-active writer token when the C1 contract requires it. The recovery records only a bound early
-`replan-required` decision: it does not edit the Plan or worktree. Then follow fresh `next` through
-`task corrective-yield` and the existing Human-confirmed corrective-replan flow. Never repeat
-`task run` merely to manufacture the second failure, and never invoke this recovery for a generic
-test failure, a writable manifest, or unconfined changes.
+For planning, review or context refresh, read [current action inputs](../../references/protocol.md).
+Use `taskPlanContract` and the advertised atomic refresh; do not reconstruct Core's eligibility rules.
+A blocked option, absent contract or contradictory route requires diagnosis, not a bypass.
+Report repeated unchanged states without progress as an incident; they do not authorize a new release.
 
-When fresh `next` includes `preExecutionReplanOption.state=eligible`, an independent Plan auditor
-may stop a `ready` Task before its next Step because the current implementation Plan is obstructed.
-Use only `task preexecution-replan` with the exact advertised Task revision, Brief hash, Plan hash,
-current Plan Risk Audit event hash, and HEAD. The audit file must be a genuine independent
-`stop-escalate` replacement audit: its planner remains the original planner, its auditor is the
-transition actor, and it retains current guarded categories, review requirements, failure modes,
-evidence commands, and proof bindings while recording the obstruction. This transition requires a
-clean checkout with no Step in progress, C1 posture, or writer lease. It appends immutable audit and
-provenance records, supersedes only current execution authorization, preserves completed Step
-authority and existing delegation scope, and does not require a new approval. After success, run
-sequential `status` then `next`; Core must advertise ordinary `task plan-set`, not audited-remediation
-topology. Submit a semantically changed Plan with the exact Task objective, requirements, and
-acceptance, preserve completed Steps and prior safety boundaries, attach a fresh Plan Risk Audit,
-then obtain fresh execution authorization. Never append an approved audit to the unchanged Plan,
-rebind context around the marker, invent a failure/corrective cause, or invoke the command when the
-option is absent or blocked.
+## Respect human decisions
 
-For this route, Core treats each `(Step ID, failureMode, evidence)` tuple as the immutable proof
-binding. It does not claim to understand whether revised `counterexample` or `expectedResult` prose
-is semantically stronger. Changing that prose therefore requires an independent
-`approved-with-rationale` audit, a changed substantive summary, and an explicit rationale; the
-earlier audit remains immutable history for human review.
+A `requiredHumanGate` ends the turn after presenting its complete bound decision and confirmation
+code. Execute only after a later explicit approval of that same code; changed bindings need a new
+decision. Generic instructions to continue are not acceptance. An exact currently eligible
+`delegatedApprovalOptions` entry permits its named delegate and grant for that transition only;
+retain any required current confirmation code. Existing authorization must not be requested again.
 
-When the exact beta.13.6 package reports validated root-cause corrective-replan dirty
-carryover, the retained work belongs to a previously failed execution of the same Task.
-Use the fresh advertised `task run` only with the current writer credential and exact
-Task/Step bindings. Core must verify the repeated mechanical cause, historical Plan,
-replacement Plan and independent PRA, authorization, completed evidence, HEAD, dirty
-paths and content hash. Every retained path must already be allowed by the new Step
-and remain outside forbidden scope. A changed binding or blocked assessment is a hard
-stop; never clean, stash, reset, manually commit, or edit state to make it eligible.
+Issuing, broadening, renewing or replacing delegation requires the human's bound decision;
+never infer it from a policy file or another grant. Semantic scope changes remain human decisions.
+Core eligibility does not replace permission for external operations or access to protected files.
 
-The beta.13.8 consumed-carryover compatibility profile also permits the exact
-published external beta.13.8 runner to execute only the read-only
-`update corrective-carryover-preflight --id <TASK-ID>` against a coherent beta.13.6
-repository. A completed, verified Step's carryover remains historical evidence;
-it must not override a later Step's repeated-cause recovery route.
+## Keep execution and review separate
 
-When `sourceRecovery.eligible=true`, execute only its exact `action` with the
-repository-installed beta.13.6 CLI. This narrow compatibility response, not the
-old source `next`, authorizes the source navigation repair. It may expose only
-`task plan-set`, `task handoff-prepare`, or `task claim`, bound to the current
-Task revision, Plan, completed history, terminal failure HEAD/dirty hash and
-corrective-yield actor. For Plan replacement, prepare the exact candidate Plan
-and independent PRA files, then pass them as `--file` and `--risk-audit-file`
-to this read-only preflight. Without both inputs no source mutation is authorized.
-Require the returned candidate Plan and input hashes; execute source `task plan-set`
-with those same unchanged files and verify its resulting Plan hash. Core rejects
-candidate inputs that omit or alter any completed Step before source mutation.
-Source execution
-authorization retains its ordinary human or exact eligible delegation gate.
-Use only the returned original Worker for handoff and claim. After every source
-mutation run source `status` then `next`, and repeat the target preflight before
-another compatibility action. `sourceRecovery` never authorizes transport or
-`task run`; top-level `eligible` remains false until transport itself is proved.
+Use only public `writerCredentialReference` and `claimCredentialReference` values through
+`--writer-credential-ref` and `--claim-credential-ref`. Check actor, action and reference expiry
+before use; a renewed lease does not renew the reference. Missing, expired or consumed references
+require the advertised credential recovery followed by fresh `status` and `next`. Never read,
+print or alter vault secrets, or include credentials and confirmation codes in dispatch evidence.
 
-Once the replacement Plan is authorized and that same Worker has claimed it,
-the preflight may expose the exact expired-lease repair described below. Never
-force-release a live lease. Require a fresh top-level `eligible=true` before
-dependency transport. beta.13.8 accepts one dependency-only commit on each of
-the Task and Milestone base, with the same exact source beta.13.6 and target
-beta.13.8. After installing the target, use its ordinary advertised
-dependency provenance recovery, atomic context refresh and original-Worker
-credential recovery. This profile permits no external state mutation, installed
-code patch, wider product commit, changed dirty bytes, or approval substitution.
+Workers leave product changes uncommitted; Core owns the advertised completion/check/commit
+operation. Follow `gitMutationPolicy` under actual permissions. Scope, lease and review failures
+are distinct from infrastructure denial; report the observed cause without manufacturing retries.
 
-The exact beta.13.9 runner supports the same bounded consumed-carryover profile
-with beta.13.6 as its source and beta.13.9 as its pinned target. Require the
-returned version bindings and all the same source-recovery and transport proofs.
-Historical beta.13.8 evidence is not proof for a beta.13.9 invocation.
+Independent reviewers/auditors verify immutable packet, commit and seal bindings without product,
+Git or workflow mutations. Under `external-sealed`, use a separate reviewer chat and record its
+closed result only through the advertised action. Neither Worker nor Coordinator authors that review.
 
-The historical beta.13.7 runner retains its own exact beta.13.6-to-beta.13.7 profile.
-The current beta.13.8 profile does not admit a beta.13.7 source or an in-progress
-Step and cannot be used to bypass the ordinary safe update boundary.
+A user prohibition on all writes also covers caches and reports: `next` may prepare runtime caches.
+Reuse unchanged bound receipts and inspect immutable evidence; disclose any unverified freshness
+instead of calling write-capable diagnostics under that prohibition.
 
-The historical beta.13.6 corrective-carryover update compatibility profile permits its exact
-external runner to execute only the read-only
-`update corrective-carryover-preflight --id <TASK-ID>` against a repository coherently
-pinned to beta.13.5. This is an explicit compatibility inspection, not permission to
-run ordinary transitions with an external or unpublished package. An active writer
-lease blocks transport. Wait for natural expiry. The target compatibility preflight
-may then return only an exact source-package stale-lease repair, after validating the
-sole expired Task lease, its original claimant, Task/Plan/PRA/authorization/HEAD and
-dirty-work bindings. This narrowly scoped preflight action is the authority for that
-source-package repair; do not describe it as an action advertised by the old source
-`next`. An active lease, another lease or any other blocker forbids the repair and
-transport. Never force-release a live lease. Preserve the original C1 claimant and
-hash-bound ownership event, log the preflight and exact repair, then run sequential
-source `status` and `next` and repeat the target preflight.
+## Dispatch and supervise within authorization
 
-After repair, require a fresh preflight with `eligible=true`, no blockers, and exact
-Task revision, source HEAD, replacement Plan/PRA/authorization, dirty paths/hash and
-original C1 ownership. Transport only the exact target dependency in `package.json`
-and `package-lock.json`: one commit on the Milestone base in a separate worktree and
-one at Task HEAD, leaving every product byte unchanged. Install the repository-local
-target, then follow fresh navigation through the existing
-`update dependency-provenance-recover` only when it advertises the matching carryover
-binding. Use current bounded credential recovery for the original Worker, and obtain
-fresh validated carryover before `task run`. Unknown history, wider commits, version
-misalignment, changed product bytes, different ownership, pending operations or missing
-bindings stop the update. This profile creates no scope or approval authority and does
-not authorize editing the installed package or Workflow state files.
+Before authorized App dispatch, read [chat dispatch](../../references/chat-dispatch.md).
+Create required Task/reviewer chats as fresh `create_thread` tasks with closed role packets;
+never use `fork_thread` to carry parent history into them. The packaged registry owns allocation,
+creation permits, exact title/context readback and binding. An ambiguous result is not permission
+to create a duplicate. Model selection requires user authorization and the destination tool contract.
 
-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.
-
-## Project Knowledge
-
-Use package commands `project-memory scan|show|status|approve|reconcile`.
-Project files are authoritative. The local map contains only paths,
-classifications, hashes, gaps, conflicts, and approval evidence.
-
-Do not create a memory directory or write project files during scan.
-
-Before `task plan-set`, the Technical Planner compares every exact `allowedWrites` and expected
-output path with the package scanner classifications. If the Plan will create a file that the
-scanner will treat as Project Knowledge (for example a test or documentation source), declare
-`knowledgeImpact: create` and one `knowledgeTargets` entry with that exact normalized path and
-scanner category. Do not replace the path with a wildcard or directory, do not infer or assign
-authority, and do not claim delegated-refresh eligibility; Core decides eligibility from the
-resulting repository diff and current authorization state.
-
-When `next.action` is `task plan-set` (including the corrective-audit variant), treat
-`next.taskPlanContract` as the exact transition precondition. Copy every
-`requiredRequirementIds` entry into Plan `requirements` and every `requiredAcceptanceIds` entry
-into Plan `acceptance` as exact array members; semantic prose may be added but cannot replace those
-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.
-
-An exact package update may make the approved Knowledge Map stale while this route is active. Continue
-without a Human approval only when fresh `next` includes
-`auditedRemediation.dependencyKnowledgeRefresh.eligible=true`. Core must prove that `package.json` is
-the sole changed Knowledge source, every version surface equals the repository-local runtime, and every
-Git commit that changed the approved manifest content altered only the exact Workflow dependency in
-`package.json`/`package-lock.json`. Do not run standalone reconcile first. The refresh is committed
-atomically by `milestone remediation-materialize` with corrective-derived evidence. Any other Knowledge
-path, classification, gap, conflict, dirty checkout, unaligned version or wider commit returns to the
-ordinary explicit Knowledge flow.
-
-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
-source-set change is eligible only when
-Core identifies it as a Plan-bounded supporting-source addition under the same Milestone
-Autonomy Grant. Never infer eligibility from the Plan yourself; if Core returns
-`contextRefreshBlocked.unsafeDifferences`, use the ordinary visible Knowledge Map flow.
-
-When `next` reports terminal `split-required`, follow `docs/split-required-recovery.md` from the
-installed package. P04-A returns `doctor` with blocked action `task replacement-materialize`,
-diagnostic `STRUCTURAL_REPLACEMENT_REQUIRED`, and
-`replacementGate.structuralReplacementAvailable=false`. Stop without invoking the retained
-command shape or consuming a replacement Discovery. Never rebind, refresh, replan, authorize,
-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
-linked Task exists; use it once with the complete membership. After every boundary, run `status`,
-wait for its terminal success, and only then run `next`; never launch the checkpoint pair in
-parallel or in one parallel tool batch. If either fails, stop; do not
-describe the reverse-membership gap as expected and invoke a direct closing command.
-
-When `next` includes `milestoneCancellationOption`, treat it as an advertised alternative only
-when the user has explicitly requested cancellation or supersession of that exact Milestone.
-Use the returned Milestone ID and expected revision verbatim, require a substantive user-supplied
-reason, and preserve every historical Task and sidecar. Absence of this option means cancellation
-is not currently navigable; do not invoke `milestone cancel` directly.
-
-When `next` includes `gitMutationPolicy`, obtain bounded permission for that exact Git-writing
-transition before the first call. Do not probe and retry after a `.git/index.lock` failure.
-For `task start`, the policy applies only when choosing `--workspace-owner local`; for
-`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 `writerCredentialReference` returned by `task run`, `task claim`, or
-`task writer-credential-replace`, including its public `credentialRef`, actor, allowed actions and
-`expiresAt`. Pass the reference using the advertised `--writer-credential-ref` option. The secret
-stays in the local vault: never read, print, copy, or edit vault records or substitute a redacted
-token. This input contract is independent from `gitMutationPolicy`; satisfy both when present.
-
-Before every credential-consuming mutation, especially after an independent review or a pause,
-compare the held reference's `expiresAt` with the current time and verify its actor/action binding.
-A live or renewed lease does not extend an existing reference's expiry; `reuse-reference` is not
-permission to reuse an expired reference. If the reference is expired, missing, consumed, or its
-validity cannot be established, use only the simultaneously advertised
-`next.writerCredentialRecovery` action with its exact Task, revision and `requiredActor` before
-attempting the blocked mutation. Follow successful replacement with `status` then `next`, retain
-the newly returned reference and expiry, and discard the prior reference. If recovery is not
-advertised, stop before mutation. Never extend expiry manually or retry with the old reference.
-
-Successful `task handoff-prepare` returns a one-time `claimCredentialReference`; use its
-`credentialRef` with the declared `--claim-credential-ref` option for `task claim` and the bound
-actor. Successful claim consumes that reference. A renewed claim/run may return
-`writerCredential.disposition=renewed` without a new reference; the held reference must still
-satisfy its own expiry and binding checks. Never search later payload fields for raw tokens 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 reference 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
-packaged protocol instead of guessing. Help never replaces a fresh `next` before mutation.
-
-When two or more Tasks are actionable, a dedicated Task chat may call `next --task <exact Task ID>`
-after the repository `status` checkpoint. The selector is read-only routing, not authorization: the
-response must name that same Task and all ordinary milestone, observation, adoption, Knowledge, and
-credential gates still apply. Omit `--task` for repository-level coordination. If Core reports that
-the selected Task is missing or not actionable, stop rather than falling back to another Task or
-invoking a direct mutation.
-
-## Codex App Chat Boundary
-
-A Milestone chat and its Task chats are separate user-visible execution contexts, not forks of one
-conversation. Create every Task chat as a brand-new Codex task with `create_thread`, an explicit
-Task-only prompt, and an explicit title. Never use `fork_thread`, thread handoff, or a continuation
-of the Milestone chat to create a Task chat: those paths carry parent history into the child. A
-confirmed failure to create a new task is a routing blocker. A pending `clientThreadId`, timeout,
-lost response, or absence from `list_threads` does not establish failure and never permits a
-second creation. Persist the attempt before calling the App, resolve its actual ID and confirm
-it with `read_thread`; never fall back to a fork. Read and follow
-`../../references/chat-dispatch.md` for the executable dispatch/recovery and model-selection contract.
-
-Codex App may wrap the supplied prompt in a host-generated `codex_delegation` envelope containing
-only routing provenance such as `source_thread_id`. That envelope is permitted and is not parent
-conversation context. Verify that the envelope's `input` is exactly the TaskContextPacket and that
-the new thread contains no copied parent turns, transcript, or assistant output.
-
-Create or reuse the Task chat just before dispatching that exact Task; do not create forked or empty
-placeholder chats for the whole membership. Derive `T<NN>` from the approved Milestone membership
-order, never from creation order or sidebar order.
-
-Before creation, look up the exact Task in current Workflow state and construct one closed
-TaskContextPacket containing only:
-
-- repository root and exact repository-local workflow package requirement;
-- Milestone number and ID, Task membership ordinal, exact Task ID, revision, and current title;
-- the Task objective, requirements/acceptance identifiers, Brief hash, and current Plan hash when
-  one exists;
-- the exact actor and grant ID only when the current routing requires them (never a confirmation
-  code, handoff credential, writer token, or other bearer value);
-- the mandatory start sequence `AGENTS.md -> project-local gateway -> handshake -> status -> next
-  --task <exact Task ID>`, with a requirement to stop if the response names another Task;
-- Task-local scope, checks, stop conditions, and the instruction to obtain all mutable facts from
-  fresh Workflow state rather than from the parent chat.
-- an autonomous completion contract: continue through planning, execution, required external
-  reviews, fix/review recovery, submission, final acceptance, and merge whenever fresh Workflow
-  navigation authorizes those transitions; stop only at a mandatory human/semantic gate, an
-  integrity or infrastructure blocker, or the terminal Task result.
-- a closed, non-secret CoordinatorReport requirement at a blocker or terminal boundary containing
-  the exact Task ID, observed Task revision/status, outcome (`attention` or `terminal`), reported
-  next action, whether a user decision is required, blocker class, commits/checks/review evidence,
-  and no confirmation code, handoff credential, writer token, or other bearer value.
-
-Do not include or summarize the Milestone-chat transcript, recovery/approval narrative, sibling
-Task details, other Task Plans, unrelated repository analysis, reasoning traces, or historical
-credentials. The new Task chat may read repository files and its own Workflow Task/Brief/Plan; it
-must not rely on the parent conversation as evidence or authority.
-
-Every automatically created Coordinator, Task, Step Review, Final Review, Corrective Audit, and
-Plan Audit chat must use the project registry/title builder at
-`../../scripts/chat-registry.mjs`. Before `create_thread`, call `allocate` with exact `projectId`,
-chat type, Milestone/Task/Step membership ordinals, semantic title, authoritative entity ID, and
-review attempt. Use returned `requestedTitle` verbatim. Never derive its prefix from
-`list_threads`, sidebar order, a count, or `count + 1`: allocation atomically reserves the
-project-wide monotonically increasing `#NNN`, and an abandoned number is never reused.
-Allocation reuses an existing matching reservation. For a new dispatch, call `dispatch-begin`
-with the closed packet and explicit model request, then call the App exactly once only when
-`createAllowed=true`, using returned `createArgs` unchanged. Record the full result via
-`dispatch-result`, resolve/read back via `dispatch-discover` and `dispatch-observe`, and bind.
-After restart use `dispatch-status`; an unresolved creation cannot be abandoned to create another.
-For legacy reservations without a dispatch marker, first reconcile existing App/source evidence;
-absence of the new marker does not prove no earlier creation occurred.
-
-When the user authorizes model selection, use the versioned role/phase/complexity matrix rather
-than coordinator inheritance. Both `model` and App `thinking` must be explicit in create arguments.
-Use the destination host's current supported model/effort catalog; no guessed aliases or silent
-fallback. Before a materially different phase, `model-select` returns explicit follow-up settings
-for the same bound thread. Routine lifecycle work should not retain planning/review reasoning by
-accident; security-sensitive and complex work must not be classified as routine to save tokens.
-Without user authorization for model selection, do not manufacture it from a registry field;
-resolve that policy choice before starting a new dispatch.
-
-The builder owns these compact title families; callers must not hand-compose variants:
-
-```text
-#NNN · M<NN> · Coord · <Milestone title> · <MS-ID>
-#NNN · M<NN>/T<NN> · Task · <Task title> · <TASK-ID>
-#NNN · M<NN>/T<NN>/S<NN> · Step Review A<N> · <Step title> · <TASK-ID>
-#NNN · M<NN>/T<NN> · Final Review A<N> · <Task title> · <TASK-ID>
-#NNN · M<NN>/T<NN>/S<NN> · Corrective A<N> · <Step title> · <TASK-ID>
-#NNN · M<NN>/T<NN> · Plan Audit A<N> · <Task title> · <TASK-ID>
-```
-
-When the Milestone ID is known, allocate and bind the coordinator chat before dispatch. During
-`AUTO` Discovery reserve the Coordinator number once; after materialization retain that sequence
-with registry `retitle`, then complete exact readback with the new Milestone ID instead of
-allocating a second Coordinator number.
-
-Put `#NNN` and membership ordinals first so clipped sidebar titles remain distinguishable. Never
-inherit the parent title, use a generic title such as `Milestone recovery` / `Task execution`, or
-reuse one title for different entity IDs. Maintain the registry-backed
-`Task ID -> thread ID -> title` mapping in
-the Milestone chat. Before supervision, verify from actual `read_thread` evidence that the title contains the exact
-ordinal and entity ID, is unique, and the new chat input contains only its TaskContextPacket plus
-the permitted host routing envelope. Never trust the `create_thread` title argument without a
-readback: pass the observed title to registry `readback`. If it returns `renameRequired=true`,
-rename to exact `renameTitle` and repeat. Deterministic fallbacks remove the semantic segment and
-compact the role while preserving `#NNN`, membership ordinals, attempt, and the full entity ID.
-Never invent another fallback or abbreviate the ID. Bind the verified entry to `threadId` and
-`hostId`; if all candidates fail, mark it blocked and stop routing. Visual sidebar clipping is
-harmless only when exact API readback still matches. Do not dispatch while title/context is wrong.
-Persist the single supervisor, cursor and next action using `supervision-record`. Large tool/CLI
-JSON must be saved completely to a private local file and parsed there, with only bounded non-secret
-summaries printed. For an uncertain mutation outcome, run fresh `status -> next` before recovery;
-never replay a mutation merely because displayed output was truncated. Review the exact serialized
-external-review envelope passed to Core, not a separately reconstructed object. Public CREF expiry
-is independent of lease expiry and must be checked before every credential-consuming transition.
-
-After every significant Task Step boundary—completion, failure, block, skip, sealed-review result,
-or corrective decision—the Task chat prints a compact Task progress Markdown table from fresh
-`task show`: Step ordinal/title, exact Step ID, status, and review/remediation posture when present.
-Never infer a status from chat text.
-
-At Coordinator start/resume, after every Task terminal or attention boundary, and after every
-Milestone membership change, run read-only `milestone progress --id <MS-ID>` and print a compact
-Milestone progress Markdown table. Use only that projection for membership order, Task/Step status,
-counts, and replacement links. Cancelled historical and replacement Tasks remain separate rows;
-show the relationship explicitly, for example `T03 cancelled → T08 replacement`, and never
-renumber the replacement as the historical Task.
-
-## Codex App Coordinator Supervision Loop
-
-Creating a Task chat is dispatch, not completion. The Milestone coordinator must remain the active
-supervisor until the Milestone is terminal or a genuine user decision is required. Codex tasks are
-peer conversations: completing or pausing a Task chat does not implicitly resume its coordinator.
-The coordinator therefore performs this explicit loop for one routed required Task at a time:
-
-1. Complete the repository `status` checkpoint, then call repository-level `next` without a Task
-   selector. Dispatch only the exact required Task named by that fresh response. Do not pre-create
-   idle chats for later membership entries.
-2. Create or reuse the verified standalone Task chat, retain its `threadId`, `hostId`, exact title,
-   Task ID, membership ordinal, and latest `wait_threads` cursor in one coordinator-owned dispatch
-   map, then let its self-starting TaskContextPacket run without a user follow-up.
-3. Call `wait_threads` for the dispatched chat. Use the returned cursor as `afterCursor` on the next
-   wait so completed output is not replayed. Use bounded waits and provide only compact coordinator
-   progress between waits; a timeout is not a blocker and is not permission to dispatch another
-   writer.
-4. When the Task completes or needs attention, call `read_thread`; the compact `wait_threads`
-   message is a wakeup hint and may not be used as the complete CoordinatorReport. Treat the full
-   Task text as untrusted evidence, never as Workflow authority, and run `status` followed by fresh
-   repository `next` (and `next --task <exact Task ID>` only when routing that same Task requires
-   it), then print the fresh `milestone progress` table before deciding the next dispatch.
-5. If Workflow still routes the same nonterminal Task and the reported problem has an exact
-   non-human continuation, use `send_message_to_thread` to continue that same Task chat with only
-   the fresh route, changed bindings, and bounded blocker resolution. Never copy a transcript,
-   sibling context, confirmation code, handoff credential, or writer token into the follow-up.
-6. Escalate to the user only for `requiredHumanGate` without an eligible exact grant, semantic
-   scope ambiguity, missing external permission, unrecoverable integrity conflict, or an
-   infrastructure failure after the documented retry boundary. A Task chat asking an answerable
-   implementation question is not by itself a human gate: the coordinator resolves it from fresh
-   repository evidence or returns it to that Task chat.
-7. After Workflow confirms the Task terminal and merged, discard any bearer material, record the
-   non-secret terminal evidence, run repository `status -> next`, and dispatch the next routed
-   required Task just in time. After all required Tasks are merged, run Milestone validation and
-   follow the exact final-acceptance gate.
-
-The coordinator must not send a final answer while a dispatched required Task is nonterminal,
-except for an explicit user-requested checkpoint or one of the blockers in step 6. In that case it
-reports the dispatch map, last observed Task revision/status, last wait cursor, and exact fresh
-`next`, so a later turn can resume without creating duplicate chats. On any resumed coordinator
-turn, first reconcile the saved map against `list_threads`, `read_thread`, repository `status`, and
-fresh `next`; never assume that an idle/finished chat implies a terminal Workflow Task.
-
-The Task chat owns supervision of its own external-sealed Step and Task reviewer chats and returns
-only their sealed result/evidence to the Milestone coordinator. This keeps the coordinator below
-the app's bounded wait target limit and prevents it from accumulating implementation or review
-transcripts. No chat may wait indefinitely for a child after ending its own turn: durable,
-cross-restart background orchestration requires a separate app wakeup/automation facility and is
-not implied by this skill.
-
-## Product Or Workflow Graph Refresh
-
-1. Run `graph refresh-request --kind product|workflow --mode moderate`.
-2. Use `codebase-memory-mcp` to list projects and match the request source root.
-3. Stop for user selection when more than one project remains plausible.
-4. Check `index_status`; call `index_repository` with the request source root,
-   mode, and `persistence: false` when missing or stale.
-5. Build evidence exactly as specified in `../../references/protocol.md`.
-6. Pipe `{ "request": ..., "evidence": ... }` to `graph bind --stdin`, passing
-   the current binding revision when one exists.
-
-When MCP is unavailable, run `graph fallback --kind ... --reason ...`. Continue
-with Git, direct file reads, and configured tests unless another requirement
-independently blocks the workflow.
-
-## Role Use
-
-- Scope Lead: architecture and broad search only.
-- Technical Planner: architecture, search, and trace evidence.
-- Worker: targeted search, trace, and snippets for its Step. It leaves all file changes
-  uncommitted and never stages or mutates Git history; the coordinator invokes the exact
-  `task step-complete` returned by `next`, and core owns checks, commit creation, and evidence.
-- Delivery Coordinator: list, status, index, detect, and bind lifecycle.
-- A Milestone Delivery Coordinator creates a dedicated user-visible Task chat for every
-  required Task, using the Codex App Chat Boundary above, and keeps implementation out of the
-  Milestone chat.
-- Independent Reviewer: receives recorded evidence and confirms critical
-  claims against files, Git, and tests.
-
-## Human Gates
-
-Treat `requiredHumanGate` from the project-local package as a mandatory turn boundary unless
-the same `next` response contains a currently eligible `delegatedApprovalOptions` entry for
-the exact transition and the agent is the entry's named delegate.
-For `milestone_final_acceptance`, show the user the Milestone ID, revision, Plan hash,
-Result hash, evidence hash, validated HEAD, and confirmation code. Ask whether the user
-accepts that exact result, then stop without invoking `milestone accept`.
-
-Only after a later user message explicitly approves and repeats the same confirmation code
-may you invoke `milestone accept` with explicit `--actor` and `--confirmation-code` values.
-A generic instruction such as “continue”, “finish”, or “bring it to final status” is not
-final acceptance. If `next` returns a different code or binding, discard the old response
-and ask again.
-
-## Delegated Approval
-
-Delegation issuance is itself a mandatory human turn boundary. Run `delegation prepare` with
-the proposed policy, show the complete principal, delegate, scope, transitions, expiry,
-policy hash, and `DGA-*` confirmation code, then stop. Only after a later user message
-explicitly approves that exact code may `delegation grant` be invoked.
-
-Never create, broaden, renew, or replace a grant from an agent's own judgment. Never record
-the delegate as the user. When `next` exposes an eligible option, pass its grant ID through
-`--delegation-grant` and use the exact delegate string as `--actor`. The core remains the
-authority for status, expiry, scope, transition, and revocation checks.
-If the same `next` response does not expose an eligible option for that exact transition, do
-not pass `--delegation-grant`. Ordinary C1 handoff, claim, run, step-complete, step-review,
-merge, and sync-base do not inherit a Milestone approval grant.
-
-For delegated Milestone final acceptance, the current `MSA-*` code is still required, but a
-new user turn is not: the previously issued grant is the controlling decision. If no eligible
-option is returned, follow the ordinary human-gate rule above. Knowledge Map approval is
-delegable only through an explicit project-scoped `project_memory.approve` permission. Scope
-changes, grant issuance, and grant expansion are never delegated by `delegated-approval-v1`.
-
-For an entire Milestone, prefer one bounded `milestone autonomy-prepare` gate after the complete
-initial membership Plan exists. An explicitly human-requested full contract may also be prepared
-for an `active` Milestone, including after a previous contract expired or was revoked. This is
-new issuance, never automatic renewal. Fresh Task-first or repository `next` may expose
-`activeMilestoneAutonomyOptions`; these are optional preparation routes and do not replace the
-current Task action. Preparation still requires coherent state and active Project Knowledge.
-A generic grant does not become a full contract and is not automatically revoked. A still-valid
-full contract must first be explicitly revoked by its principal before a different one is issued.
-The new confirmation binds the current Milestone status, revision, Plan, semantic scope, policy,
-and previous contract/grant state; any change requires preparation and confirmation again.
-An exact successful retry returns the same grant; an old code cannot revive a revoked grant. Show principal, delegate, expiry, semantic-scope hash, policy
-hash, and `MAC-*` code, then stop. A later exact approval permits `milestone autonomy-grant`.
-Use the delegated path only when the same `next` response exposes
-`milestoneAuthorizationOptions[].action = "milestone autonomy-prepare"` or an
-`activeMilestoneAutonomyOptions` entry for that exact Milestone, and the user explicitly
-requested delegated Milestone operation; otherwise follow the ordinary `milestone authorize`
-human gate.
-The resulting grant covers the existing Task/Milestone approval transitions and the Project
-Memory approval portion of an atomic Task context refresh for the same Milestone. Besides
-content-only drift, Core may accept exact supporting-source additions predeclared by the current
-execution-authorized Task Plan; unsafe differences remain blocked. The contract never permits
-standalone Project Memory approval. It also permits `milestone autonomy-evolve`
-only for membership changes; any change to outcome, success signal, acceptance, checks,
-discovery, or base branch requires the ordinary human scope-change gate. Never self-renew or
-replace the contract.
-
-When fresh `next` advertises `task corrective-decision` with
-`planningRecovery.authority = "planning-only"`, a started failed Step has a current
-blocking audit after a Knowledge-only Plan rebind. Core proves the historical approved
-safety baseline; the stopped audit does not authorize execution. Obtain the independent
-corrective decision against the returned bindings and preserve the exact original Worker
-credential/yield prerequisites. Follow the existing human-confirmed corrective-replan
-route, then fresh replacement Plan authorization. Never approve the obstructed Plan merely
-to unlock navigation, use ordinary `plan-set` to bypass the corrective gate, or create an
-upstream remediation Task for this already-started posture. `continue-fix` is unavailable
-for this planning-only route. A package update can require another Knowledge rebind and
-fresh blocking audit; do not rewrite or silently reuse a stale audit.
-
-Repeated failed Task reviews remain on the same Task and do not require a separate corrective
-Plan audit based only on count. Follow fresh `next`: ordinary findings default to `route=fix`;
-`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; 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`,
-create a separate user-visible reviewer chat for that exact packet, and require one closed
-`ReviewInput` JSON result bound to its reviewed commit. The reviewer must not modify repository or
-Workflow state. The `--file` passed to `task step-review-record` must be the full
-`ExternalStrictStepReviewInput` envelope: top-level `protocol`, `packetHash`,
-`repositorySealHash`, `reviewerThreadId`, and `reviewMode` (`ordinary` or `security`), plus the
-nested `review` object containing `status`, `reviewer`, `summary`, and `findings`. Copy both hashes
-and the mode from the packet; do not flatten `review`, and do not pass `--review-mode` to the record
-command because it reads the mode from the JSON file. Run `task step-review-record --help` for a
-complete minimal example. Then run only the advertised `task step-review-record` with the unchanged packet
-and repository-seal hashes, the separate reviewer thread ID, the lifecycle actor from `next`, and
-the active writer token when required. Never author the independent review in the Worker or
-Delivery Coordinator chat, never alter the packet, and never treat an unverified local reviewer
-launch as a semantic remediation failure. If Core reports the seal changed, discard the review and
-stop; do not regenerate evidence against a moving checkout.
-
-When `next.strictTaskReview.recommendedMode` is `external-sealed`, apply the same isolation rule to
-the final submitted-Task review. Run the advertised read-only `task review-packet`, send the exact
-packet to a separate user-visible Independent Reviewer chat, and accept only a closed `ReviewInput`
-bound to the unchanged packet and repository-seal hashes. Record it only through the advertised
-`task review-sealed-record`. Its `--file` must be the analogous full
-`ExternalStrictTaskReviewInput` envelope using protocol
-`codex-workflow-external-strict-task-review-v1`, the packet and repository-seal hashes,
-`reviewerThreadId`, top-level `reviewMode`, and nested `review`; its `--help` contains a minimal
-example. Use the lifecycle actor from `next` and the active writer token when
-required. Do not call `task review-launch` from inside a Codex App sandbox, do not use the Worker or
-Delivery Coordinator as reviewer, and discard the result if a fresh packet changes either hash.
-
-When `next` returns a derived C1 Worker or corrective Auditor actor, use that exact actor without
-asking the user to name one. Derivation removes a routing pause; handoff claim, writer lease,
-strict review, and auditor-independence checks remain mandatory.
-
-The beta.13.2 pending strict-review update exception is documented in
-`docs/pending-review-update.md` in the exact package. An exact external target runner may run
-only `update pending-review-source-preflight` against the known beta.13.1 source. Require its
-verified runtime build, exact Task/revision/Plan/HEAD/pending binding and no blockers. If it
-returns an exact stale Task lease repair, run that `locks repair` with the installed source and
-repeat preflight. Preserve the eligible receipt outside the checkout; transport only the two
-bound dependency commits on base and Task, then install the target locally. Fresh local `next`
-must advertise `update pending-review-dependency-recover`; run its matching read-only preflight
-with `--file <source-receipt>` before recovery. Recovery does not approve Knowledge or review.
-Use the original pending product SHA through the newly sealed external packet and record,
-then follow fresh credential/context-refresh/ordinary lifecycle actions. Never treat this as
-permission for other external-runner mutations, product transport, or manual state repair.
-
-Before an npm package update, run the project-local `update preflight` and stop unless it
-returns `safe=true` with a clean checkout, no running Step, and no active writer lease.
-
-## Stop Conditions
-
-- Dependency version is missing, ranged, or differs from the installed package.
-- Gateway handshake is incompatible.
-- MCP project identity is ambiguous.
-- A request changes before evidence is bound.
-- An action would make MCP or the local map authoritative project memory.
-- A requested mutation is not authorized by the package CLI state.
-- A lifecycle `status` or `next` failed; do not continue with a different lifecycle mutation.
-- A human gate was emitted but the user has not approved its exact confirmation code in a
-  later message and no exact eligible delegated approval option exists.
-
-## Explain an implementation change before escalating
-
-Before a product write by a tracked Worker, run the packaged registry `dispatch-context-check`
-using fresh App readback, the actual write root and the branch from the current Task. Resolve
-checkout mismatch without duplicate dispatch or silent canonical-checkout writes. A matching
-context is not a filesystem permission or writer credential.
-
-When a fix needs additional files, the route is unclear, or an external operation was denied,
-use read-only `change explain --task <exact Task ID> --file <closed proposal JSON>` as documented
-in `docs/change-model.md`. Present all known blocking layers together. Never relabel an external
-permission refusal as a missing grant. `requiresUser: null` is unknown, not blanket approval.
-For an exact Core-derived check-support amendment, follow the existing advertised recovery and
-fresh next; do not manually widen allowedWrites or issue new authority. Membership, semantic
-scope and Knowledge refresh retain their separate existing routes and evidence requirements.
+Maintain the Task-to-chat mapping and supervision cursor. A completed chat is evidence, not a
+terminal Workflow Task: reconcile fresh Core state, continue the same chat when permitted, and
+supervise until the assigned work is terminal or an explicit gate/blocker requires attention.
+Use fresh `task show` / `milestone progress` for progress, preserving membership identities.
+Scheduled continuation requires an authorized App automation; ending a turn does not create one.