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

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

@@ -1,458 +1,55 @@
-# Gateway Protocol V2
+# Current action inputs
 
-## beta.12.6 compatibility transitions and continuable remediation
+Read this reference when preparing a Plan, a context refresh or a sealed review. Fresh Core
+navigation is the eligibility authority; command help and current schemas define serialization.
+This reference does not enumerate transitions or provide another compatibility contract.
 
-- 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
-  first-failure missing-root-npm-script evidence and must be followed by fresh `status -> next`.
-  It records a replan posture without changing Plan or product files; corrective yield and the
-  existing state-bound corrective-replan Human gate remain mandatory.
+## Planning and Knowledge
 
-- 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 `next` advertises `task plan-set`, consume its `taskPlanContract`. Preserve every
+`requiredRequirementIds` and `requiredAcceptanceIds` member in the corresponding Plan arrays;
+prose does not replace IDs. Bind the returned Brief hash and Knowledge Map revision/hash.
+Preserve completed Step evidence and the current semantic/safety boundaries when replanning.
+Missing or contradictory bindings stop Plan submission.
 
-- 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.
+Compare planned exact `allowedWrites` and output paths with scanner classifications. A planned
+new Knowledge source requires `knowledgeImpact: create` and an exact normalized path/category
+in `knowledgeTargets`. A wildcard or directory is not an exact declaration. Source authority
+comes from approved repository evidence; the planner cannot infer delegated approval eligibility.
 
-- `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.
-- Before a credential-consuming mutation, check the public `writerCredentialReference.expiresAt`
-  against the current time and its actor/action binding. Lease heartbeat or renewal does not
-  extend that reference's expiry. An expired, missing, consumed or unverifiable reference requires
-  the simultaneously advertised `next.writerCredentialRecovery` action with its exact Task,
-  revision and `requiredActor`, followed by fresh `status` and `next`; use the new reference.
-  If no recovery is advertised, stop before mutation. Never read or patch the vault, extend expiry
-  manually, or reuse the old reference. This check also applies after independent reviews and pauses.
-- `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
-  families, verifies exact readback, supplies deterministic fallbacks, and binds the verified chat.
-  It also journals a single creation permit, pending/actual IDs, evidence-based resolution and
-  supervision cursors. Missing App listings never permit a retry. See `chat-dispatch.md` for
-  dispatch commands and the explicit role/phase model + thinking policy. These are App routing
-  helpers; they do not change Workflow protocol/state schema or grant approval authority.
+If top-level `next` advertises `task context-refresh`, execute that atomic action with the returned
+Task/map revisions, named delegate and grant. Do not approve/reconcile Knowledge separately first.
+Unsafe differences use the visible Knowledge approval route returned by Core. For additional
+implementation scope, `change explain` consumes a closed proposal; its diagnostic is not approval.
 
-## Handshake
+## Sealed review
 
-Run:
+For `external-sealed`, request the advertised Step or Task review packet and dispatch an independent
+reviewer with only the immutable evidence and its read-only role. A separate thread identity alone
+does not establish that a review occurred. Obtain the actual result and verify unchanged bindings.
+Do not launch a nested local reviewer in an App sandbox when external-sealed is recommended.
 
-```text
-codex-workflow gateway handshake --repo <git-root>
-```
+The record input is the full envelope, not a flattened review:
 
-Require:
+- `protocol`: the current Step/Task envelope protocol;
+- `packetHash`, `repositorySealHash`, `reviewerThreadId`, `reviewMode`: exact packet/result bindings;
+- `review`: the closed object containing `status`, `reviewer`, `summary`, and `findings`.
 
-- package name `codex-workflow-v2`
-- protocol version `2`
-- state schema version `2`
-- the capabilities needed for the requested operation
+Consult `task step-review-record --help` or `task review-sealed-record --help` for the applicable
+schema/example. Mode belongs in the envelope; do not invent an extra record-command option.
+Use the lifecycle actor from `next`, separately from the independent reviewer identity, and the
+advertised credential reference. Discard a review whose packet, commit or seal changed.
+An unverified launch or permission denial is not evidence of a semantic implementation failure.
 
-Current capability set:
+## Context and authority changes
 
-- `project-memory-v1`
-- `graph-binding-v1`
-- `local-state-v1`
-- `milestone-lifecycle-v1`
-- `milestone-human-final-gate-v1`
-- `delegated-approval-v1`
-- `task-knowledge-rebind-v1`
-- `task-context-refresh-v1`
-- `structural-task-replacement-disabled-v1`
-- `project-composite-transaction-journal-v1`
-- `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`
-- `legacy-snapshot-v1`
-- `plan-risk-audit-sidecar-v1`
-- `step-strict-review-sidecar-v1`
-- `step-remediation-circuit-breaker-sidecar-v1`
-- `milestone-scope-change-sidecar-v1`
-- `milestone-membership-integrity-v1`
-- `milestone-task-dependency-dag-v1`
-- `milestone-initial-plan-transaction-v1`
-- `task-c1-handoff-sidecar-v1`
-- `task-mechanical-feasibility-v1`
-- `semantic-plan-risk-audit-v2`
-- `guarded-remediation-continuation-v1`
-- `milestone-reverse-membership-integrity-v1`
-- `task-c1-handoff-bundle-v2`
-- `alpha6-adoption-posture-v1`
-- `alpha6-strict-review-rescue-v1`
-- `milestone-initial-assembly-v1`
-- `milestone-initial-assembly-navigation-v2`
-- `milestone-autonomy-contract-v1`
-- `milestone-autonomy-content-refresh-v1`
-- `milestone-autonomous-membership-evolution-v1`
-- `task-c1-derived-worker-actor-v1`
-- `guarded-corrective-auditor-routing-v1`
-- `corrective-decision-context-recovery-v1`
-- `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`
-- `corrective-replan-protocol-v2`
+Help cannot waive any current claim, lease, independent audit or human gate. An actor derived by
+Core removes a naming question, not its authority checks. A new review finding does not by itself
+permit scope expansion or a new Task. Follow its current fix/replan/stop route and preserve history.
+When the response offers several alternatives, choose only one consistent with the user's intent;
+cancellation, publication and delegation issuance do not acquire authorization by appearing there.
 
-Protocol `1` and schema `2` remain valid only because alpha.7 is additive. The gateway must
-not claim compatibility if canonical entity shapes or non-additive command semantics change.
-
-## Alpha.6 adoption posture
-
-For an existing schema 2 project without alpha.6 posture, repository-level `next` blocks
-execution behind adoption:
-
-- `action: "state adoption-apply"` when the repository is already at a safe boundary
-- `action: "restore safe boundary, then state adoption-prepare"` otherwise
-
-Use:
-
-```text
-codex-workflow state adoption-prepare --repo <git-root>
-codex-workflow state adoption-apply --repo <git-root> \
-  --actor <HUMAN-ACTOR> --confirmation-code <ADA-CODE>
-```
-
-The confirmation is bound to project identity, package version, protocol version, schema
-version, canonical entity summaries, and the current sidecar baseline hash. Adoption is not
-`state migrate`.
-
-## Worker Step completion and strict Step Review
-
-`task run` dispatches one Step and returns a first-field `writerLeaseReceipt`, followed by the
-credential-free lease metadata, Task state, and Worker envelope. Consume the receipt before the
-remaining payload and retain its token only in working memory. The Worker
-must leave all changes uncommitted and must not stage, commit, amend, reset, rebase, or
-modify Git history.
-
-While that Step is `in_progress`, repository-level `next` normally returns
-`action: "task step-complete"`, the exact `stepId`, and a `commitPolicy` declaring
-`workflow-core` ownership. The coordinator invokes that transition with the current revision
-and writer token. Core then runs configured checks, validates `allowedWrites`, stages the
-changes, creates the atomic commit, and records evidence.
-When `next` also 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 the coordinator
-chooses `--workspace-owner local`.
-
-When `next` also includes `writerTokenContract`, the coordinator must retain the active writer
-lease from `writerLeaseReceipt` and pass it with the advertised option on the first transition call.
-The contract never contains the token value. Do not print, persist, reconstruct, or replace the
-token with a redacted fingerprint; stop before mutation when the active lease is unavailable.
-Satisfy this contract separately from any `gitMutationPolicy` on the same response.
-
-`codex-workflow <noun> [action] --help` is a read-only command-discovery route. It exits without
-constructing workflow state or validating lifecycle inputs. Use exact option lists only when the
-response says `exactOptionContractAvailable=true`; otherwise consult this packaged protocol. After
-help, obtain a fresh `next` before invoking the lifecycle transition.
-
-If the current Plan Risk Audit marks that Step for strict review, the commit is still
-workflow-owned, but `next` then returns `action: "task step-review"` with the same `stepId`
-and the exact `completionCommit`. Canonical Step completion remains blocked until the strict
-review and reviewer attestation sidecars verify against that exact commit.
-Invoke `task step-review` with the same lifecycle actor advertised by `next`
-(`c1Handoff.claimant` or `requiredActor` when present). The isolated reviewer is launched
-inside Core; do not substitute the reviewer identity into `--actor`. In claimed C1 posture,
-`next.writerTokenContract` is mandatory for both `task step-review` and the later
-`task review-launch`; pass the retained active lease on the first call of each exact action.
-
-After submission, a pending Task review is advertised as `action: "task review-launch"`, not
-`task review-record`. That compound route launches the read-only reviewer and atomically
-records the returned review. If claimant-bound mutation is active, pass the same lifecycle
-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:
-
-```text
-codex-workflow task plan-risk-audit --repo <git-root> \
-  --id <TASK-ID> --expected-revision <REVISION> --file <audit.json>
-```
-
-The audit must classify every current Step exactly once, name distinct planner/auditor
-actors, bind guarded failure modes to exact Step checks, and map each guarded failure mode to
-one hostile counterexample, expected safe result, and exact executable evidence command. Use `decision=approved` for an
-unguarded Plan. Missing, stale, `split-required`, or `stop-escalate` evidence blocks
-authorization.
-
-For guarded remediation, the first two failed cycles are recorded as `ordinary` and later cycles as
-`corrective`. This mode is diagnostic: a third or later retry remains executable and still requires
-a fresh strict review. A finding defaults to `route=fix`; `route=replan` is accepted only with exact
-Plan-conflict evidence and routes to ordinary `task plan-set` for implementation-Step changes.
-
-An explicit corrective disposition can still be recorded when the actor deliberately chooses a
-stop, split, or compatible historical recovery route:
-
-```text
-codex-workflow task corrective-decision --repo <git-root> \
-  --id <TASK-ID> --step <STEP-ID> --expected-revision <REVISION> --file <decision.json>
-```
-
-`continue-fix` permits continuation; `replan-required`, `split-required`, and `stop-escalate` are
-explicit stop or redirection decisions. They are never inferred from attempt count. Without such an
-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
-classifications. A planned new scanner-visible Knowledge file must be declared with
-`knowledgeImpact: create` and an exact path/category `knowledgeTargets` entry. Wildcards,
-directories, and inferred authority are not declarations; only Core may decide whether the final
-diff is eligible for delegated refresh.
-
-For every `task plan-set` navigation, consume `next.taskPlanContract` before building the Plan.
-Its `requiredRequirementIds` and `requiredAcceptanceIds` are exact-membership preconditions, not
-descriptive hints. Preserve each ID verbatim in the corresponding Plan array and use the returned
-Brief hash plus Knowledge Map revision/hash as the planning binding. Missing or stale contract data
-is a stop condition.
-
-Use `task context-refresh` only when the same `next` response returns it as the top-level action and
-exposes `contextRefresh` for the exact grant. Pass Task revision, map revision, delegate actor, and
-grant ID. Never run standalone `project-memory reconcile` first; Core blocks that non-atomic route
-when the exact delegated composite is available. The composite
-operation accepts content-hash-only drift and, under a Milestone Autonomy Grant, an exact
-supporting-source addition predeclared by the current execution-authorized Task Plan. Core checks
-the full fail-closed predicate; do not reconstruct it in the gateway. When `next` instead returns
-`contextRefreshBlocked.unsafeDifferences`, keep the change on the normal visible Knowledge path.
-
-Before updating the installed package, run `update preflight`. Continue only for `safe=true`.
-For an alpha.6 project trapped between a pending strict review and forbidden Knowledge rebind,
-an exact external alpha.7 runner may run `update rescue-preflight`. Continue only for
-`eligible=true` and only with the returned lock-repair and strict-review actions.
-
-## C1 handoff
-
-`C1` coordination is machine-bound and local. Use:
-
-```text
-codex-workflow task handoff-prepare --repo <git-root> --id <TASK-ID> \
-  --expected-revision <REVISION> --actor <CURRENT-ACTOR> \
-  [--target-actor <TARGET-ACTOR>] --reason <TEXT> [--writer-token <TOKEN>] \
-  [--delegation-grant <GRANT>] [--expires-at <ISO-TIMESTAMP>]
-codex-workflow task handoff-show --repo <git-root> --id <TASK-ID>
-codex-workflow task claim --repo <git-root> --id <TASK-ID> \
-  --expected-revision <REVISION> --actor <TARGET-ACTOR> --claim-token <TOKEN> \
-  [--writer-token <WRITER-TOKEN>]
-codex-workflow task handback-create --repo <git-root> --id <TASK-ID> \
-  --expected-revision <REVISION> --actor <CLAIMANT> --reason <TEXT> \
-  --recommended-next <TEXT> [--limitation <TEXT>] [--writer-token <TOKEN>]
-```
-
-While a handoff is pending, `next` blocks the previous action behind `task claim`. While
-claimed, only the claimant may mutate the Task, and lease-bound mutations must present the
-bound writer token. Milestone-linked Tasks must be claimed before start, and handback is
-terminal and evidence-bound. When target actor is omitted, Core derives
-`agent:worker:<task-id>`. No thread id is required or accepted as authority.
-The successful prepare response begins with `credentialHandoff`. Consume that receipt before the
-Task/event/bundle payload, retain its token only in working memory, and pass it exactly once to the
-declared `task claim --claim-token` action for the declared target actor. The later bundle remains
-contextual and intentionally contains no second copy of the claim token.
-The successful claim response then begins with `writerLeaseReceipt`. Retain that token only in
-working memory. In claimed C1 posture, fresh `next` exposes `writerTokenContract` on `task run`;
-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
-with the complete membership. Execution is blocked while reverse membership is incomplete.
-Before Task 1 and between linked Tasks, follow top-level `next.action = "milestone initial-assembly"`.
-Its `linked-task-assembly.commands` permit `discovery start` and `discovery materialize`; after the
-first linked Task exists, the separate closing option permits `milestone plan-set`. If `status` or `next` fails, stop: never label
-the gap expected and invoke `milestone plan-set` directly.
-
-Every required navigation checkpoint is strictly sequential: start `status`, wait until its
-terminal result is recorded, then start `next` and wait for its terminal result. Never issue the
-pair concurrently or through a parallel tool call. The trusted transcript validator treats a
-second invocation before the first terminal result as indeterminate release evidence.
-
-After that Plan, one human may prepare and grant a maximum-72-hour Milestone Autonomy Contract:
-
-```text
-codex-workflow milestone autonomy-prepare --repo <git-root> --id <MS-ID> \
-  --expected-revision <REVISION> --principal <HUMAN> --delegate <AGENT> --expires-at <ISO>
-codex-workflow milestone autonomy-grant --repo <git-root> --id <MS-ID> \
-  --expected-revision <REVISION> --principal <HUMAN> --delegate <AGENT> --expires-at <ISO> \
-  --confirmation-code <MAC-CODE>
-```
-
-The contract issues a milestone-scoped grant for the existing Task/Milestone approval transitions
-and Project Memory approval only inside an atomic Task context refresh for the same Milestone.
-That composite path covers content-only drift plus exact Plan-bounded supporting-source additions;
-it cannot approve Project Memory independently. `milestone autonomy-evolve --file
-<plan.json>` is permitted only when outcome, success signal, acceptance, checks, discovery, and
-base branch still match the contract. It journals agent actor plus contract evidence and requires
-reauthorization afterward.
-
-After the initial empty planning posture, Milestone scope updates use:
-
-```text
-codex-workflow milestone scope-change-prepare --repo <git-root> \
-  --id <MS-ID> --expected-revision <REVISION> --actor <HUMAN-ACTOR> --file <plan.json>
-codex-workflow milestone scope-change-apply --repo <git-root> \
-  --id <MS-ID> --expected-revision <REVISION> --actor <HUMAN-ACTOR> \
-  --confirmation-code <MSC-CODE> --file <plan.json>
-```
-
-This ordinary semantic-change path is human-only. Generic delegated approval never authorizes it.
-
-At `awaiting_final_acceptance`, `next` returns `requiredHumanGate` with kind
-`milestone_final_acceptance`, Milestone ID, revision, Plan/Result/evidence hashes, validated
-HEAD, and a confirmation code. Display the complete object and end the turn. Only a later
-explicit user message that approves the same code authorizes:
-
-```text
-codex-workflow milestone accept --repo <git-root> --id <MS-ID> \
-  --expected-revision <REVISION> --actor <USER-ACTOR> \
-  --confirmation-code <MSA-CODE>
-```
-
-Do not infer approval from the request that initiated validation. A changed revision, hash,
-or HEAD requires a new gate.
-
-## Delegated Approval
-
-`delegation prepare --file <policy.json>` returns a `delegation_grant_issuance` gate with a
-project-bound policy hash and `DGA-*` confirmation code. Display it and end the turn. A later
-explicit user message containing the exact code permits `delegation grant`.
-
-Active eligible grants appear in `next.delegatedApprovalOptions`. Use only the option whose
-transition matches the requested command, with the named delegate as actor and the grant ID
-as `--delegation-grant`. The resulting authorization event records the grant and both actors.
-For `milestone.final_accept`, also pass the current `MSA-*` code; the existing grant replaces
-the later-message requirement, not the state binding.
-Do not pass `--delegation-grant` to ordinary C1 handoff, claim, run, step-complete,
-step-review, merge, or sync-base calls. Those transitions are not authorized by a Milestone
-approval grant unless the same `next` response explicitly advertises an eligible grant for the
-exact transition.
-
-Delegated approval does not cover adoption apply or the ordinary semantic Milestone scope-change
-path. Membership-only evolution requires the separate Milestone Autonomy Contract.
-
-## Graph Refresh Request
-
-The package returns:
-
-```json
-{
-  "protocolVersion": 1,
-  "requestId": "uuid",
-  "projectId": "local-project-id",
-  "graphKind": "product",
-  "sourceRoot": "/absolute/local/path",
-  "rootFingerprint": "sha256",
-  "indexedHead": "git-sha-or-null",
-  "packageVersion": null,
-  "manifestHash": null,
-  "mode": "moderate",
-  "persistence": false,
-  "issuedAt": "ISO-8601"
-}
-```
-
-`workflow` requests set packageVersion and manifestHash and point sourceRoot to
-the prepared versioned workflow view.
-
-## Evidence
-
-Return the request unchanged with:
-
-```json
-{
-  "requestId": "same-uuid",
-  "provider": "codebase-memory-mcp",
-  "projectKey": "provider-project-key",
-  "rootFingerprint": "same-sha256",
-  "indexedHead": "same-git-sha-or-null",
-  "packageVersion": null,
-  "manifestHash": null,
-  "mode": "moderate",
-  "status": "ready",
-  "nodeCount": 100,
-  "edgeCount": 200,
-  "observedAt": "ISO-8601"
-}
-```
-
-The package rejects mismatched or stale requests. Absolute source paths remain
-local workflow data and are not project knowledge.
-
-## Retention
-
-Product binding stores only the current evidence. Workflow binding stores the
-current package evidence plus one previous package snapshot. A new snapshot is
-retained only after the new binding is ready.
+A successful result submission can release the execution lease before final acceptance. After a
+human pause, use fresh navigation and its credential recovery; do not reuse the earlier reference.
+Before a package update, require the installed package's `update preflight` to report `safe=true`.
+An unsafe boundary is a diagnostic, not permission to edit state or clean away retained work.

package/plugins/codex-workflow-gateway/scripts/chat-dispatch.mjs

@@ -64,7 +64,13 @@ export function dispatchAction(action, entry, input = {}) {
     const selection = selectChatModel(entry.type, input.modelRequest);
     const id = randomUUID();
     const marker = `[workflow-dispatch:${id}:${hash(prompt)}]`;
-    const dispatchedPrompt = `${marker}\n${prompt}\nExecution boundary: use the actual child checkout returned by App readback. Before any write, reconcile it with the exact Task branch and run dispatch-context-check. A repository path in this packet is identity context, not authorization to write outside that checkout.`;
+    // Only the registry's explicit review/audit roles receive a read-only boundary.
+    // A model phase or packet prose cannot turn a product Worker into a reviewer.
+    const reviewRole = ['step-review', 'final-review', 'corrective-audit', 'plan-audit'].includes(entry.type);
+    const boundary = reviewRole
+      ? 'Review boundary: use the exact canonical repository and immutable commit, packet/seal or audit-request bindings supplied for this independent review. Verify those bindings before reading evidence and before returning the result; stop if they change. The App checkout may be detached or on another branch: do not switch it or require Task-branch dispatch-context-check for read-only inspection. Do not modify product files, Git history, or Workflow state, and do not invoke lifecycle mutations. Save the review result only to an explicitly requested artifact path outside all repository checkouts, under actual filesystem permissions; this instruction grants no filesystem access. A repository path identifies read evidence, never write authority.'
+      : 'Execution boundary: use the actual child checkout returned by App readback. Before any product or repository write, reconcile it with the exact Task branch and run dispatch-context-check. A repository path in this packet is identity context, not authorization to write outside that checkout.';
+    const dispatchedPrompt = `${marker}\n${prompt}\n${boundary}`;
     entry.dispatch = {
       version: 1, id, state: 'creating', appProjectId, hostId, repositoryRoot, gitDir, executionMode,
       promptPath, promptHash: hash(prompt), dispatchedPromptHash: hash(dispatchedPrompt), marker,

package/plugins/codex-workflow-gateway/scripts/chat-model-policy.mjs

@@ -1,15 +1,17 @@
 // Relative cost/latency policy, not a price list or an availability oracle.
-export const MODEL_POLICY_VERSION = 'chat-model-policy-v1';
+export const MODEL_POLICY_VERSION = 'chat-model-policy-v2';
 const PROFILES = {
   mechanical: [['gpt-5.4-mini', 'low'], ['gpt-5.6-luna', 'low']],
-  scoped: [['gpt-5.6-luna', 'medium'], ['gpt-5.6-terra', 'medium']],
-  implementation: [['gpt-5.6-terra', 'medium'], ['gpt-5.6-sol', 'medium']],
-  planning: [['gpt-5.6-sol', 'medium'], ['gpt-6-astra', 'medium']],
-  review: [['gpt-5.6-sol', 'high'], ['gpt-6-astra', 'high']],
-  'scoped-review': [['gpt-5.6-terra', 'medium'], ['gpt-5.6-sol', 'medium']],
-  complex: [['gpt-6-astra', 'high'], ['gpt-5.6-sol', 'high']],
+  scoped: [['gpt-5.6-luna', 'low'], ['gpt-5.4-mini', 'medium']],
+  implementation: [['gpt-5.6-terra', 'low'], ['gpt-5.6-luna', 'medium']],
+  planning: [['gpt-5.6-terra', 'low'], ['gpt-5.6-luna', 'medium']],
+  review: [['gpt-5.6-terra', 'low'], ['gpt-5.6-luna', 'medium']],
+  'scoped-review': [['gpt-5.6-luna', 'low'], ['gpt-5.4-mini', 'medium']],
+  complex: [['gpt-5.6-terra', 'medium'], ['gpt-5.6-luna', 'medium']],
 };
-const TYPES = ['coordinator', 'task', 'step-review', 'final-review', 'corrective-audit', 'plan-audit'];
+const TYPES = [
+  'coordinator', 'task', 'step-review', 'final-review', 'corrective-audit', 'plan-audit', 'workflow-blocker',
+];
 export function selectChatModel(type, request) {
   if (!TYPES.includes(type)) throw new Error('Unknown chat type.');
   if (!request || !['routine', 'standard', 'complex'].includes(request.complexity)

package/plugins/codex-workflow-gateway/scripts/chat-registry.mjs

@@ -14,7 +14,9 @@ import process from 'node:process';
 import { randomUUID } from 'node:crypto';
 import { dispatchAction, dispatchInput } from './chat-dispatch.mjs';
 
-const TYPES = new Set(['coordinator', 'task', 'step-review', 'final-review', 'corrective-audit', 'plan-audit']);
+const TYPES = new Set([
+  'coordinator', 'task', 'step-review', 'final-review', 'corrective-audit', 'plan-audit', 'workflow-blocker',
+]);
 const LOCK_STALE_MS = 30_000;
 const LOCK_WAIT_MS = 2_000;
 
@@ -26,9 +28,12 @@ export function allocateChat(options) {
     const sequence = registry.nextSequence;
     const reservationId = randomUUID();
     const candidates = buildTitleCandidates({ ...options, sequence });
+    const milestoneOrdinal = options.type === 'workflow-blocker'
+      ? null
+      : requiredOrdinal(options.milestoneOrdinal, 'M');
     const existing = registry.entries.find(entry => entry.status !== 'abandoned'
       && entry.type === options.type && entry.entityId === options.entityId
-      && entry.milestoneOrdinal === requiredOrdinal(options.milestoneOrdinal, 'M')
+      && entry.milestoneOrdinal === milestoneOrdinal
       && entry.taskOrdinal === optionalOrdinal(options.taskOrdinal, 'T')
       && entry.stepOrdinal === optionalOrdinal(options.stepOrdinal, 'S')
       && (['task', 'coordinator'].includes(options.type)
@@ -38,7 +43,7 @@ export function allocateChat(options) {
       sequence,
       reservationId,
       type: options.type,
-      milestoneOrdinal: requiredOrdinal(options.milestoneOrdinal, 'M'),
+      milestoneOrdinal,
       taskOrdinal: optionalOrdinal(options.taskOrdinal, 'T'),
       stepOrdinal: optionalOrdinal(options.stepOrdinal, 'S'),
       entityId: requiredText(options.entityId, 'entityId'),
@@ -191,6 +196,15 @@ export function showRegistry(options) {
 }
 
 export function buildTitleCandidates(options) {
+  if (options.type === 'workflow-blocker') {
+    const entityId = requiredText(options.entityId, 'entityId');
+    const semantic = compactWhitespace(requiredText(options.semanticTitle, 'semanticTitle'));
+    validateTypeBindings(options.type, null, null, entityId);
+    if (!/^\d+\.\d+\.\d+-beta(?:\.\d+)+$/u.test(semantic)) {
+      throw new Error('workflow-blocker title must be the exact target beta patch version.');
+    }
+    return [semantic];
+  }
   const prefix = `#${String(positiveInteger(options.sequence, 'sequence')).padStart(3, '0')}`;
   const milestone = requiredOrdinal(options.milestoneOrdinal, 'M');
   const task = optionalOrdinal(options.taskOrdinal, 'T');
@@ -331,11 +345,15 @@ function validateProjectId(projectId) {
 
 function validateTypeBindings(type, taskOrdinal, stepOrdinal, entityId) {
   if (!TYPES.has(type)) throw new Error(`Unsupported chat type: ${type}`);
-  if (type !== 'coordinator' && !taskOrdinal) throw new Error(`${type} requires a Task membership ordinal.`);
+  if (!['coordinator', 'workflow-blocker'].includes(type) && !taskOrdinal) {
+    throw new Error(`${type} requires a Task membership ordinal.`);
+  }
   if ((type === 'step-review' || type === 'corrective-audit') && !stepOrdinal) {
     throw new Error(`${type} requires a Step membership ordinal.`);
   }
-  const validEntity = type === 'coordinator'
+  const validEntity = type === 'workflow-blocker'
+    ? /^[a-f0-9]{64}$/u.test(entityId)
+    : type === 'coordinator'
     ? entityId === 'DISCOVERY' || /^MS-[0-9A-HJKMNP-TV-Z]{26}$/.test(entityId)
     : /^TASK-[0-9A-HJKMNP-TV-Z]{26}$/.test(entityId);
   if (!validEntity) throw new Error(`${type} requires its full authoritative entity ID.`);