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

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

@@ -1,458 +1,51 @@
-# Gateway Protocol V2
-
-## beta.12.6 compatibility transitions and continuable remediation
-
-- When fresh `next` advertises `task plan-integrity-recover`, consume its exact Task revision,
-  Step, actor, and writer-token contract. This route is valid only for the Core-derived
-  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.
-
-- When fresh `next` advertises `task downstream-proof-recover`, Core has proved that every dirty
-  file outside the active Step belongs to a completed transitive predecessor and that recorded Git
-  history is intact. Invoke the exact lease-bound transition once. It preserves product files and
-  HEAD, invalidates stale predecessor completion authority with an append-only event, yields C1,
-  and routes the same Task to ordinary `task plan-set`. The replacement Plan, risk audit, and
-  execution authorization are fresh authority; no Task or Milestone recreation is involved.
-
-- When an older installed package cannot reach that recovery because its normal update preflight
-  requires a clean checkout, beta.12.6 permits one bounded dependency transport. The active
-  Milestone base and Task branch must first receive separate exact commits changing only
-  `package.json` and `package-lock.json`; product work remains dirty and uncommitted. Fresh beta.12.6
-  `next` must then advertise `update downstream-proof-dependency-recover`. Its preflight proves the
-  Task history at `HEAD^`, the dependency candidate at `HEAD`, aligned version surfaces, no lease or
-  transaction, exact predecessor ownership, and a content hash of the dirty set. Recovery registers
-  only the dependency commit. It does not mutate product files or Step state; fresh `next` must
-  proceed to `task downstream-proof-recover`, which outranks manifest-induced Knowledge staleness.
-
-- `update dependency-provenance-preflight --id <TASK-ID>` is read-only. The matching
-  `update dependency-provenance-recover --id <TASK-ID> --expected-revision <N> --actor <ACTOR>
-  --reason <TEXT>` is valid only when preflight and fresh `next` both advertise it. Historical
-  product commits absent from the current corrective Step are recognized only through intact passed
-  strict-review plus verified reviewer-attestation chains and remain separately auditable as
-  `retainedHistoricalCommits`.
-  Task-local manifest/lock fields from recorded history may differ from the base, but the candidate
-  commit must preserve them exactly while changing only the Workflow dependency entries.
-- `task historical-step-provenance-preflight --id <TASK-ID>` is read-only. The matching
-  `task historical-step-provenance-recover` is available only for one unexpected product commit
-  with an intact passed strict-review chain, matching prior final acceptance, no lease or pending
-  operation, and dirty files confined to the current active Step. It retains historical authority
-  without changing Git, worktree bytes, or the current Plan.
-- `update historical-step-dependency-preflight/recover` handles the same proof when the beta.12.9
-  dependency-only commit is the unregistered HEAD. It binds the exact dependency candidate and the
-  reviewed historical Step commit in one recovery record, preserves active product bytes, and then
-  requires fresh `status` and `next`.
-- `task stop-override-prepare` is a read-only Human gate for the exact beta.11 attempt-four stop
-  shape. `task stop-override-apply` requires the same Task revision, Step, actor, reason, Plan, HEAD,
-  evidence binding, and returned `SOO-*` code in a later user turn. It appends evidence without
-  deleting `stop-escalate`; it never applies to `split-required`.
-- After an applied stop override, one or more ordinary delegated `task context-refresh` transitions
-  may rebind the Plan before attempt four. Fresh `next` returns `task run` only when Core validates
-  the complete contiguous Plan/rebind/audit chain, mechanical equivalence at every hop, shared
-  delegated authority, and append-only chronology. HEAD may differ from the override only when every
-  intervening commit is an exact registered dependency-provenance recovery changing only
-  `package.json` and `package-lock.json`. If C1 remains claimed but the lease was lost at the Human
-  boundary, use only the simultaneously advertised `task writer-credential-replace` action.
-  A provenance recovery recorded after the final context-refresh audit may explain exactly one
-  additional Task revision only when it belongs to that verified Git chain. Any unexplained
-  revision remains a `doctor` boundary.
-- 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.
-
-## Handshake
-
-Run:
-
-```text
-codex-workflow gateway handshake --repo <git-root>
-```
-
-Require:
-
-- package name `codex-workflow-v2`
-- protocol version `2`
-- state schema version `2`
-- the capabilities needed for the requested operation
-
-Current capability set:
-
-- `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`
-
-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.
+# Current action inputs
+
+Fresh Core navigation defines eligibility; current help/schemas define serialization.
+Read this reference for planning, context refresh and sealed review, not as another transition catalog.
+
+## Planning and Knowledge
+
+For `task plan-set`, use `taskPlanContract`: retain every `requiredRequirementIds` and
+`requiredAcceptanceIds` member, Brief hash and Knowledge Map revision/hash. Prose cannot replace IDs.
+Replanning preserves completed evidence and semantic/safety boundaries; contradictory bindings block submission.
+Compare exact `allowedWrites`/outputs with scanner classifications. New Knowledge sources require
+`knowledgeImpact: create` and exact normalized path/category in `knowledgeTargets`, not wildcards/directories.
+Approved repository evidence defines source authority; planners cannot infer delegated eligibility.
+
+For advertised `task context-refresh`, use its exact Task/map revisions, delegate and grant atomically;
+do not reconcile/approve separately first. Unsafe differences follow Core's Knowledge approval route.
+Additional scope uses `change explain` with a closed proposal; its diagnostic is not approval.
+
+## Sealed review
+
+For `external-sealed`, obtain the advertised Step/Task packet and send only immutable evidence and
+the read-only role to an independent reviewer. Thread identity alone proves no review: obtain the
+actual result with unchanged bindings. Do not substitute a nested local App-sandbox reviewer.
+Record the full envelope: `protocol`, `packetHash`, `repositorySealHash`, `reviewerThreadId`,
+`reviewMode`, and nested `review` containing `status`, `reviewer`, `summary`, `findings`.
+Use `task step-review-record --help` or `task review-sealed-record --help` for its schema/example.
+Mode belongs in the envelope, not an invented CLI option. Use the lifecycle actor/reference from
+`next`, separately from reviewer identity. Discard results with changed packet, commit or seal.
+Unverified launch or permission denial is not a semantic implementation failure.
+
+## Context and authority changes
+
+Help and derived actor names waive no claim, lease, audit or authority checks. Review findings grant
+no scope expansion/new Task: follow current fix/replan/stop and preserve history. Choose alternatives
+consistent with user intent; advertised cancellation/publication/grant issuance is not authorization.
+Result submission may release the lease before acceptance; use fresh navigation/credential recovery,
+not the old reference. Normal updates require installed `update preflight` with `safe=true`; for an
+explicit blocked-checkpoint update follow the gateway's exact-target exception. Unsafe state never
+permits manual state editing or deleting retained work.
+
+## Delegated corrective replan
+
+For `task corrective-replan-authorize`, retain the independently validated candidate and add
+`delegation: {grantId, actor}` from the eligible execution option. `authority.actorIdentityHash` is
+SHA256 of the exact grant delegate UTF-8 string; `authority.humanPrincipalIdentityHash` hashes its
+principal string as provenance, not new Human confirmation. Preserve objective, requirements,
+acceptance and completed evidence. Core revalidates grant at issuance and execution.
+Run authorize with `--id --file`, then `task corrective-replan-execute` with its exact returned
+credential. The receipt contains `delegated`, no `human` confirmation; never use prepare/confirm
+for it. Missing/expired authority returns to grant issuance/expansion; unattainable acceptance returns
+to Discovery, never a weakened Plan.

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

@@ -29,7 +29,17 @@ function promptMatches(value, digest) {
   if (typeof value !== 'string') return false;
   if (hash(value) === digest) return true;
   const wrapped = /^<codex_delegation>\s*<source_thread_id>[^<]+<\/source_thread_id>\s*<input>([\s\S]*)<\/input>\s*<\/codex_delegation>$/.exec(value);
-  return wrapped !== null && hash(wrapped[1]) === digest;
+  if (wrapped === null) return false;
+  const input = wrapped[1];
+  // Older App transports carried literal input. Keep exact bytes authoritative.
+  if (hash(input) === digest) return true;
+  // Decode only the five XML text entities, exactly once. No trimming, recursive
+  // unescape, HTML/numeric entities or Unicode normalization may alter the packet.
+  // In particular, original literal `&gt;` arrives as `&amp;gt;` and stays `&gt;`.
+  if (input.includes('<') || /&(?!amp;|lt;|gt;|quot;|apos;)/.test(input)) return false;
+  const entities = { amp: '&', lt: '<', gt: '>', quot: '"', apos: "'" };
+  const decoded = input.replace(/&(amp|lt|gt|quot|apos);/g, (_match, name) => entities[name]);
+  return hash(decoded) === digest;
 }
 function view(entry) {
   const d = entry.dispatch;
@@ -64,7 +74,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,
@@ -73,7 +89,7 @@ export function dispatchAction(action, entry, input = {}) {
     };
     return { ...view(entry), createAllowed: true, nextAction: 'create-thread-once', createArgs: {
       target: { type: 'project', projectId: appProjectId, environment: { type: executionMode } },
-      title: entry.requestedTitle, prompt: dispatchedPrompt, model: selection.model, thinking: selection.thinking,
+      title: entry.requestedTitle, prompt: dispatchedPrompt, ...selection.dispatchArgs,
     } };
   }
   const d = entry.dispatch;
@@ -291,7 +307,7 @@ export function dispatchAction(action, entry, input = {}) {
     d.selection = selection;
     d.selectionHistory.push(selection);
     return { ...view(entry), followUpArgs: { threadId: entry.threadId, hostId: entry.hostId,
-      model: selection.model, thinking: selection.thinking } };
+      ...selection.dispatchArgs } };
   }
   throw new Error(`Unknown dispatch action: ${action}`);
 }

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

@@ -1,43 +1,30 @@
-// Relative cost/latency policy, not a price list or an availability oracle.
-export const MODEL_POLICY_VERSION = 'chat-model-policy-v1';
-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']],
-};
-const TYPES = ['coordinator', 'task', 'step-review', 'final-review', 'corrective-audit', 'plan-audit'];
+// Destination settings are authoritative unless the user explicitly chose an override.
+export const MODEL_POLICY_VERSION = 'chat-model-policy-v3';
+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)
-    || !['planning', 'implementation', 'mechanical', 'review', 'coordination'].includes(request.phase)
-    || typeof request.rationale !== 'string' || !request.rationale.trim()
-    || typeof request.highRisk !== 'boolean') throw new Error('Explicit phase, complexity, highRisk and rationale are required.');
+  if (request == null) return {
+    policyVersion: MODEL_POLICY_VERSION, profile: 'destination-default', dispatchArgs: {},
+  };
+  // This records the caller's explicit-user-selection assertion; it is not an App
+  // permission or a substitute for the actual user instruction at dispatch time.
+  if (request.userAuthorized !== true || typeof request.model !== 'string' || !request.model.trim()) {
+    throw new Error('Model override requires an explicit user-authorized model; otherwise omit modelRequest and use destination defaults.');
+  }
   if (!Array.isArray(request.availableModels) || request.availableModels.length === 0
     || request.availableModels.some(m => !m || typeof m.id !== 'string' || !Array.isArray(m.reasoningEfforts)
       || m.reasoningEfforts.some(e => typeof e !== 'string'))
     || new Set(request.availableModels.map(m => m.id)).size !== request.availableModels.length) {
     throw new Error('Provide the destination host model/effort catalog; never infer availability.');
   }
-  const reviewRole = type.endsWith('review') || type.endsWith('audit');
-  let profile;
-  if (request.highRisk || request.complexity === 'complex') profile = 'complex';
-  else if (type === 'step-review' && request.complexity === 'routine') profile = 'scoped-review';
-  else if (reviewRole || request.phase === 'review') profile = 'review';
-  else if (request.phase === 'planning') profile = 'planning';
-  else if (request.phase === 'mechanical') {
-    if (request.complexity !== 'routine') throw new Error('Mechanical phase requires routine complexity.');
-    profile = 'mechanical';
-  } else if (type === 'coordinator' || request.phase === 'coordination' || request.complexity === 'routine') profile = 'scoped';
-  else profile = 'implementation';
-  const selected = PROFILES[profile].find(([id, effort]) => request.availableModels.some(m => m.id === id && m.reasoningEfforts.includes(effort)));
-  if (!selected) throw new Error(`No supported model/effort for ${profile}; explicit policy revision required, never inherit coordinator settings.`);
-  return {
-    policyVersion: MODEL_POLICY_VERSION, profile, model: selected[0], thinking: selected[1],
-    phase: request.phase, complexity: request.complexity, highRisk: request.highRisk,
-    rationale: request.rationale.trim(), fallback: selected !== PROFILES[profile][0],
-  };
+  const selected = request.availableModels.find(m => m.id === request.model);
+  if (!selected || (request.thinking !== undefined && !selected.reasoningEfforts.includes(request.thinking))) {
+    throw new Error('User-selected model/effort is unavailable on the destination host; no automatic substitution.');
+  }
+  const dispatchArgs = { model: request.model,
+    ...(request.thinking === undefined ? {} : { thinking: request.thinking }) };
+  return { policyVersion: MODEL_POLICY_VERSION, profile: 'explicit-user-selection',
+    ...dispatchArgs, userAuthorized: true, dispatchArgs };
 }