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

package/docs/autonomy-guardrails.md

@@ -2,9 +2,9 @@
 
 ## Approval and independent evidence
 
-Human approval is the default. A principal can issue an expiring grant to a distinct delegate after confirming its exact code in a later message. Only the current scope and enumerated transition are delegated. Events retain principal, delegate and policy hash; expired, revoked, mismatched or expanded authority is rejected.
+Human mode retains explicit human approval. In delegate mode the human decides Discovery creation/edits and grant issuance/expansion; operational decisions inside those boundaries belong to the Coordinator, independent agents and Core. A principal issues an expiring grant to a distinct delegate after confirming its exact bound code. Only the current scope and enumerated transition are delegated. Events retain principal, delegate and policy hash; expired, revoked, mismatched or expanded authority is rejected.
 
-The grant allow-list covers Knowledge approval, Task execution/final acceptance and Milestone execution/final acceptance. A full Milestone autonomy contract additionally permits membership-only evolution and Knowledge approval inside an eligible atomic Task context refresh. It never permits standalone Knowledge approval, arbitrary semantic changes, grant expansion or self-renewal. Use only the eligible option returned by the same fresh `next` response. Ordinary writer actions do not consume approval grants.
+The grant allow-list covers `project.adopt`, Knowledge approval, Task execution/final acceptance and Milestone execution/final acceptance. Standalone adoption and Knowledge approval require an eligible project-scoped grant. An existing exact Milestone grant containing all four Task/Milestone execution and final-acceptance transitions can derive its autonomy contract through the advertised `milestone autonomy-bind` without issuing or expanding a grant or asking for another confirmation. That contract permits membership-only evolution. Scoped Knowledge approval inside an eligible atomic Task context refresh additionally requires the explicit Knowledge permission issued with a full autonomy grant; a four-transition grant does not acquire it through binding. Neither permits standalone Knowledge approval. Use only the eligible option returned by the same fresh `next` response. Ordinary writer actions do not consume approval grants.
 
 Every Plan requires an independent Risk Audit. Guarded risks include persistence changes, concurrency, crash/restart/replay, providers, composition and security boundaries. Each classified failure mode names a hostile counterexample, expected safe result and exact executable evidence. Unsupported or missing proof is not success.
 
@@ -15,7 +15,7 @@ Strict Step and final Task reviews must be independent of the Worker and coordin
 | Boundary | Allowed continuation | Preserved invariant |
 |---|---|---|
 | Ordinary failed check/review | Same-Step or same-Task fix and fresh checks/review | Failure count creates no approval or arbitrary stop |
-| Proven Plan obstruction | Independent corrective evidence and advertised replan | Objective, requirements, acceptance and completed evidence remain bound |
+| Proven Plan obstruction | Independent corrective evidence; eligible `task corrective-replan-authorize` in delegate mode, or the human preparation/confirmation route | Objective, requirements, acceptance and completed evidence remain bound |
 | Mechanically impossible check | Exact `task plan-integrity-recover` route | No synthetic second failure and no arbitrary scope widening |
 | Active downstream proof touches predecessor-owned paths | `task downstream-proof-recover`, then current planning | Preserve product bytes/HEAD; invalidate only proven predecessor authority |
 | Knowledge-only drift | Current rebind or eligible atomic context refresh | No semantic Plan rewrite, implicit grant or writer replacement |
@@ -38,6 +38,6 @@ Existing append-only history remains verifiable. Readers of already recorded eve
 
 Claim and writer credentials use local credential references bound to project, entity, action and actor. Do not pass raw bearer tokens in CLI arguments, prompts or evidence. A pending claim blocks competing execution; a claimed Task keeps its exact actor. Handoff evidence alone does not prove a physically independent reviewer.
 
-A real confirmation gate requires the displayed state and a later exact user response unless a current eligible delegation already authorizes it. Scope changes retain their own consent. Infrastructure denial is not a Workflow grant failure; report its real layer and use only authorized recovery. Never restart services or change product checks to conceal an access failure.
+In delegate mode a current eligible grant replaces operational human confirmation; it does not remove the bound decision, audit, evidence or executor checks. Technical adoption uses `state adoption-apply` with the current confirmation binding and an eligible `project.adopt` grant. Missing authority is a grant decision, not permission to impersonate the principal. Acceptance and criteria of success must never be weakened to declare completion: an unattainable outcome requires evidence and a return to Discovery. Human mode retains its explicit bound confirmation route. Infrastructure denial is not a Workflow grant failure; report its real layer and use only authorized recovery. Never restart services or change product checks to conceal an access failure.
 
 Do not repeatedly execute an unchanged failing route. Preserve the command, state binding and blocker; distinguish an external wait, human gate, integrity failure and unsupported transition. No arbitrary retry counter establishes completion. A1 remains a release blocker until actual continuation evidence covers the supported routes.

package/docs/development-flow.md

@@ -16,11 +16,11 @@ Authorization binds the Plan and its audit. Plan changes supersede it. Local exe
 
 The Worker changes only the dispatched Step's effective allowed paths and leaves changes uncommitted. Core `task step-complete` runs checks, verifies history, makes the atomic Step commit and records evidence. Guarded Steps remain pending until an independent strict review and attestation bind that exact commit. Never substitute a manual commit or a self-authored review.
 
-Failed review ordinarily returns to a fix in the same Task. Attempt count does not authorize success or impose an artificial terminal stop. A replan requires recorded evidence of a Plan obstruction and preserves Task objective, requirements and acceptance. Completed Steps remain verified history. See [guardrails](autonomy-guardrails.md) for recovery and authority boundaries.
+Failed review ordinarily returns to a fix in the same Task. Attempt count does not authorize success or impose an artificial terminal stop. A replan requires recorded evidence of a Plan obstruction and preserves Task objective, requirements and acceptance. In delegate mode, an eligible execution grant and independently validated same-scope candidate use `task corrective-replan-authorize`; the human prepare/confirm route remains available in human mode. Completed Steps remain verified history. No route may weaken acceptance to force success. See [guardrails](autonomy-guardrails.md) for recovery and authority boundaries.
 
-After Knowledge changes between Steps, use the current rebind or atomic context-refresh route described in [project memory](project-memory.md). Pending completion/review and already-started failed-Step recovery must not be bypassed with a Knowledge refresh. A fresh execution authorization is required where Core superseded the prior one.
+After Knowledge changes between Steps, use the current rebind or atomic context-refresh route described in [project memory](project-memory.md). Pending completion/review and already-started failed-Step recovery must not be bypassed with a Knowledge refresh. A fresh execution authorization is required where Core superseded the prior one; an eligible delegated context refresh supplies it without a repeat human question.
 
-Submission binds a clean, auditable Task HEAD. Passing independent review permits Result creation. Result entry releases the execution lease before the human final-acceptance wait; reacquire the credential through fresh `next` before merge. Base advancement can require synchronization, validation and acceptance again.
+Submission binds a clean, auditable Task HEAD. Passing independent review permits Result creation. Result entry releases the execution lease before final acceptance; use an eligible delegated approval in delegate mode, or the explicit human gate in human mode. Recover the credential through fresh `next` before merge; same-scope recovery already covered by the actual authorization does not require a new operational question. Base advancement can require synchronization, validation and acceptance again.
 
 After every required Task is merged, Milestone validation binds Result, checks and the clean base HEAD. Acceptance uses its exact current confirmation binding. Cancellation retains history and never reverts merged code.
 
@@ -28,15 +28,17 @@ After every required Task is merged, Milestone validation binds Result, checks a
 
 | Role | Owns | Does not grant |
 |---|---|---|
-| User / principal | Semantic scope, classifications, consent and grant policy | Fabricated evidence |
+| User / principal | Discovery creation/edits and grant issuance/expansion in delegate mode; explicit gates in human mode | Fabricated evidence or weakened acceptance to manufacture completion |
 | Scope Lead | Discovery and unresolved questions | Product edits |
 | Technical Planner | Plan and requirement/check mapping | Execution approval |
-| Coordinator | Current route, dispatch, supervision and closure | Arbitrary authority or scope expansion |
+| Coordinator | Current route, authorized dispatch, delegated operational decisions, supervision and closure | Arbitrary authority, semantic scope expansion or self-authored independent review |
 | Worker | One dispatched Step | Plan changes, self-review or manual Core commits |
 | Independent Reviewer | Immutable review packet and evidence | Fixes or acceptance |
 | Core | State, hashes, transactions, ownership and Git mechanics | Semantic product decisions |
 
-Use one dedicated Task chat per required Task and a supervising Milestone coordinator. Dispatch uses the packaged registry's unique mapping and fresh TaskContextPacket. A completed chat is not a merged Task: inspect Core state before dispatching a successor. Recoverable continuation stays in the same Task chat. The coordinator waits on active work and stops for a real user gate, an unrecoverable blocker or terminal closure.
+Use one dedicated Task chat per required Task and a supervising Milestone coordinator. Dispatch uses the packaged registry's unique mapping and fresh TaskContextPacket. A completed chat is not a merged Task: inspect Core state before dispatching a successor. Recoverable continuation stays in the same Task chat. The coordinator waits on active work and continues through recoverable intermediate states until the assigned scope is terminal. In delegate mode it returns to the human only for Discovery or grant decisions; a reproduced workflow/App/infrastructure blocker is reported with its exact layer and safe continuation requirements, not relabeled as a new approval. A completed Step, chat or review is not Task closure.
+
+Reuse actual user authorization for required role-chat creation, minimum packet transfer, checks, fresh review packets and same-scope credential recovery. Model/reasoning are omitted by default so destination settings apply. Do not request separate approval for each operation already covered; an actual App refusal still cannot be bypassed.
 
 For a tracked Worker, verify the real App checkout with `dispatch-context-check` before the first write and after a checkout/branch change. A match is not a writer credential or filesystem permission. Independent reviewers inspect only the bound immutable packet and repository evidence; a different reviewer checkout is not a reason to mutate or reconcile it.
 

package/docs/project-memory.md

@@ -2,11 +2,11 @@
 
 Version-controlled repository files are durable project knowledge. The local Knowledge Map stores paths, classification, scope, authority and hashes; it does not create a second memory bank or make an MCP index authoritative.
 
-Scope Lead discovers sources and unresolved conflicts; the user approves canonical/supporting classifications. Plans bind approved sources and declare Knowledge impact. Workers update only authorized targets, reviewers verify the result, and coordinators reconcile changed source bindings.
+Scope Lead discovers sources and unresolved conflicts. Canonical/supporting classifications require recorded approval: the user in human mode, or the eligible delegate under a project-scoped Knowledge approval grant in delegate mode. A Milestone grant does not authorize standalone Knowledge approval. Plans bind approved sources and declare Knowledge impact. Workers update only authorized targets, reviewers verify the result, and coordinators reconcile changed source bindings.
 
 A changed approved file makes its map binding stale. Rebind is mechanical: it preserves Step definitions, status and evidence, records old/new bindings and supersedes execution authorization. It cannot run over an active Worker Step or conceal a Plan obstruction. Pending strict review retains its immutable historical binding and precedes current-map rebind.
 
-When fresh `next` returns `task context-refresh`, use its exact eligible delegate/grant and Task/Knowledge revisions without standalone reconcile first. Core atomically combines reconciliation, scoped approval, rebind and, where execution is eligible, reauthorization. A planning-only refresh preserves stopped planning without execution authority. Content-only drift is eligible only with unchanged classifications, scope, authority, gaps and conflicts. A Milestone contract may additionally admit exact supporting sources already declared by the authorized Plan. Removed, canonical, undeclared or conflicting sources require ordinary classification/approval.
+When fresh `next` returns `task context-refresh`, use its exact eligible delegate/grant and Task/Knowledge revisions without standalone reconcile first. Core atomically combines reconciliation, scoped approval, rebind and, where execution is eligible, reauthorization. A planning-only refresh preserves stopped planning without execution authority. Content-only drift is eligible only with unchanged classifications, scope, authority, gaps and conflicts. A Milestone contract may additionally admit exact supporting sources already declared by the authorized Plan. Removed, canonical, undeclared or conflicting sources require ordinary classification/approval under its own eligible authority; context refresh cannot silently approve them. Within a valid delegated route, changed Knowledge hashes do not require another human approval. If no suitable grant covers the needed approval, request grant issuance/expansion; if the change alters the product intent or acceptance, return to Discovery.
 
 ## Workflow code discovery
 

package/docs/release.md

@@ -71,7 +71,13 @@ The entry point re-verifies the passport, source, tag and packed package identit
 
 The specific A1 and M04 route results retain their accepted scope. Broader A4 autonomy metrics, R2 escaped-session cleanup, native host startup diagnosis and any absent live App qualification remain explicit. Positive validator tests use temporary synthetic records; they test rejection/acceptance logic and never substitute for a real App run. A publication decision does not silently close these findings or demonstrate universal lifecycle completion.
 
-## 2.0.0-beta.14 candidate inventory
+## beta.14.1 candidate
+
+The current candidate is `codex/release-candidate-beta.14.1`, based on published
+`v2.0.0-beta.14`. See [the current delegate contract](autonomy-guardrails.md).
+Release eligibility is established only by the fresh exact-candidate passport.
+
+## Historical beta.14 assembly inventory
 
 The reproducible branch is `codex/release-candidate-beta.14`, based on tag
 `v2.0.0-beta.13.16` (commit `500c783d469f8c571a136c6763b7781091406cb1`).

package/docs/updating-existing-project.md

@@ -26,3 +26,40 @@ not a successful update. Diagnose incomplete version/base bindings rather than p
 The gateway plugin resolves the installed package; it does not copy Workflow assets into the consumer. Refresh its installed source through the supported plugin installation flow when the package changes, then verify a new Task loads the intended skill. Package text validation alone does not prove the App installation boundary.
 
 This guide does not authorize updating a live consumer while auditing the workflow package. Such a change is a separate explicitly scoped operation.
+
+## Paused external failed-check update: beta.14 to beta.14.1
+
+The verified Milestone 4 repair has a separate, bounded checkpoint: an external Task at
+`awaiting_execution_authorization`, exactly one failed Step with its native check-failure
+receipt, retained regular dirty files, independently reviewed completed predecessors, the
+original Worker claim, and no lease or pending operation. A missing or negative rebound Plan
+audit is planning evidence only. This route does not approve product work or weaken acceptance.
+It is limited to the exact beta.14 → beta.14.1 package transition; it is not a general dirty-update route.
+
+1. Obtain the exact published beta.14.1 tarball outside the consumer. Its unpacked target runtime
+   may run only `update failed-checkpoint-source-preflight --id <Task> --tarball <artifact>`
+   against the source Worker checkout. Require `eligible=true` and retain the returned `receipt`
+   object outside the checkout. Candidate qualification may use an unpublished tarball only in
+   an isolated copy. A live transport requires the published, verified artifact.
+2. In separate base and Task checkouts, create exactly one dependency-only commit on each
+   receipt-bound source HEAD. Change only the workflow entries in package.json/package-lock.json.
+   If package.json already contains dirty product scripts, stage the dependency change derived
+   from committed HEAD, not the whole working manifest; retain the product delta in the working
+   file. Preserve every other byte, including formatting; only the literal workflow version
+   string may change in a dirty package.json. Dirty package-lock.json, symlinks, deleted files,
+   extra commits, changed product bytes, leases or changed state make this checkpoint ineligible.
+3. Install that same exact target and run its handshake, status and next. Follow
+   `update failed-checkpoint-transport-preflight --id <Task> --tarball <artifact> --file <receipt>`.
+   Only an eligible proof permits `update failed-checkpoint-recover` using its exact revision,
+   original actor and an explicit reason. The runtime reconstructs the original source proof;
+   an edited receipt cannot authorize transport.
+4. Recovery registers the target dependency commit and an explicit `failedCheckpoint` provenance
+   record. It preserves completed-Step evidence, the failed-Step receipt, dirty product changes,
+   authorizations and claim history. Original and transported dirty hashes remain distinguishable;
+   no historical evidence is rewritten and no new execution authority is granted. Replaying the
+   recovery after its revision change fails.
+5. Follow fresh Knowledge reconciliation and a new independently bound Plan audit before any
+   corrective decision/replan or execution. An old auditor report remains historical evidence,
+   not a fresh audit for the transported candidate. Continue only through the current advertised
+   corrective and authorization routes. The release qualification must prove this continuation,
+   not merely that the state schema can be read.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-workflow-v2",
-  "version": "2.0.0-beta.14",
+  "version": "2.0.0-beta.14.1",
   "description": "Requirements-first Codex development workflow with local state and explicit Git ownership.",
   "repository": {
     "type": "git",

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

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

package/plugins/codex-workflow-gateway/references/chat-dispatch.md

@@ -29,10 +29,12 @@ report only outside repository checkouts under actual permissions; zero-write in
 1. `allocate` for the exact role/entity/membership/review attempt. Use its title verbatim.
    Reuse the existing matching reservation; neither a new number nor a missing App listing proves
    an earlier creation failed. Review attempt numbers come from the Workflow review cycle.
-2. Prepare a private request with repositoryRoot, appProjectId, hostId, promptFile and modelRequest.
-   Populate the destination's supported models/efforts from its current App tool contract.
-   Model overrides require user authorization; policy data does not supply it. When authorized,
-   let `scripts/chat-model-policy.mjs` select the pair; do not copy a stale matrix or guess aliases.
+2. Prepare a private request with repositoryRoot, appProjectId, hostId and promptFile. Omit
+   modelRequest by default: registry createArgs/followUpArgs omit model and thinking and retain
+   destination/user settings. Do not ask for a model per role. Only for an explicit user override,
+   provide modelRequest `{userAuthorized:true, model, thinking?, availableModels}` using the exact
+   selected model and actual destination catalog. The assertion is not a grant of App authority;
+   unavailable choices fail without silent substitution.
 3. Run `dispatch-begin` before the App call. Only `createAllowed=true` permits one
    `create_thread` using its exact `createArgs`; save the complete receipt privately.
 4. Record `dispatch-result` from the actual App result. A pending client ID is not a thread ID.
@@ -71,10 +73,20 @@ prove Task completion. On restart reconcile App readback, saved cursors and Core
 The Task chat supervises its independent reviewers; the Milestone coordinator supervises its Task
 chats. Use fresh `task show` and `milestone progress` for progress, preserving cancelled/replacement
 membership identities. After required Tasks merge, follow Milestone validation and acceptance.
-A user checkpoint or real permission/human/integrity/infrastructure blocker may end supervision;
+A user checkpoint or evidenced integrity/infrastructure/App blocker may end supervision;
 report the exact pending Task and route so resumption does not create duplicates.
 
 For a material phase change, authorized `model-select` returns settings for the same bound chat.
 It changes neither role nor authority. Keep settings otherwise; do not escalate model or retries
 because a review failed. A workflow incident is a bounded diagnostic packet, not authorization to
 publish or message a patch chat. Obtain the required user authorization before external dispatch.
+
+## Scoped delegate authorization
+
+In delegate mode the human decides Discovery and grant only. Authorized creation of required
+role tasks includes their minimum Task/Brief/Plan/Knowledge/commit/seal/check context, intended
+public one-time claim reference, and reports back to the authorized coordinator chain. Reuse that
+actual authorization across routine revisions and fresh review packets; do not ask separately for
+creation, default model, packet transfer, check execution or same-scope credential recovery.
+Preserve recipient/scope/expiry/one-time checks and never transmit vault secrets. If App rejects
+an action despite this authorization, report its exact refusal; the workflow cannot override it.

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

@@ -1,55 +1,51 @@
 # Current action inputs
 
-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.
+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
 
-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.
+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.
 
-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.
-
-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.
+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`, 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.
-
-The record input is the full envelope, not a flattened review:
-
-- `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`.
-
-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.
+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 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.
-
-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.
+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;
@@ -79,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;
@@ -297,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,45 +1,30 @@
-// Relative cost/latency policy, not a price list or an availability oracle.
-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', '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']],
-};
+// 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 };
 }

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

@@ -17,7 +17,8 @@ Stop on missing/ranged/mismatched versions or an incompatible handshake. Do not
 global package, mutable tag, external runner or MCP ADR memory.
 
 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.
+`update navigation-source-preflight` or `update failed-checkpoint-source-preflight`; read
+`docs/updating-existing-project.md` from that exact target package for the matching boundary.
 Only an eligible source receipt permits its two dependency transports; recovery uses the newly installed local target.
 
 For workflow source development, use the requested source checkout and record its Git revision
@@ -48,15 +49,19 @@ Report repeated unchanged states without progress as an incident; they do not au
 
 ## Respect human decisions
 
-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.
+In delegate mode ask the human only to form/edit Discovery or issue/expand grant. Use the exact
+currently eligible `delegatedApprovalOptions` for operational approvals; retain required machine
+confirmation-code bindings. Missing authority requires grant issuance/expansion, never invented
+human identity or confirmation. Outside delegate mode, present a `requiredHumanGate` and execute
+only after a later explicit approval of its unchanged code.
 
-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.
+Routine role creation/minimum packet dispatch, declared Plan checks and same-actor credential
+recovery do not require repeated questions when covered by the actual scoped authorization.
+Use destination model defaults unless explicitly overridden by the user. Actual App/sandbox
+denials remain enforceable and must be reported, not bypassed. Grant issuance, expansion and
+renewal extending authority remain human decisions. Product-intent changes return to Discovery;
+never weaken approved acceptance or checks to declare completion. Core eligibility does not grant
+external-operation or filesystem permissions beyond the actual authorization.
 
 ## Keep execution and review separate
 
@@ -84,7 +89,7 @@ Before authorized App dispatch, read [chat dispatch](../../references/chat-dispa
 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.
+to create a duplicate. Omit model/reasoning overrides by default; an explicit user choice must match the destination tool contract.
 
 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

package/references/state-machine.md

@@ -68,7 +68,9 @@ During initial planning, all linked Tasks may be materialized before one complet
 materialization, with explicit `discovery start` and `discovery materialize` commands. After at
 least one linked Task exists, it also exposes the closing `milestone plan-set` command. Failed navigation is fail-closed and cannot be treated as an
 expected assembly signal. After that boundary, semantic updates use human-only `milestone scope-change-prepare` and
-`milestone scope-change-apply`. A human-confirmed, expiring Milestone Autonomy Contract may
+`milestone scope-change-apply`; in delegate mode a product-intent change returns to Discovery.
+An expiring Milestone Autonomy Contract can be bound mechanically by `milestone autonomy-bind`
+from an existing sufficient grant, without issuing new authority or another Human confirmation. It may
 use `milestone autonomy-evolve` only for membership changes while outcome, success signal,
 acceptance, checks, discovery, and base branch remain fixed. It may also approve Project Memory
 only within an atomic context refresh for a Task in that Milestone; standalone map approval

package/roles/delivery-coordinator.md

@@ -3,21 +3,22 @@
 Own state transitions, dispatch envelopes, evidence collection, and recovery guidance.
 
 - Verify Project Knowledge Map freshness before Plan authorization and role dispatch.
-- After an approved knowledge change between Steps, reconcile and approve the map, perform
-  the mechanical Task knowledge rebind, and request fresh user authorization.
+- After a knowledge change between Steps, use the advertised atomic delegated context-refresh
+  without separately reconciling/approving the map first. For other changes use the eligible
+  Knowledge approval route; do not request authorization already covered by the grant.
 - Own derived map revisions and context selection, but never edit the meaning of canonical project files.
 - Treat CLI `status`, `next`, revision, and lock state as authoritative machine state.
 - Never bypass authorization, scope checks, failed validation, or stale review.
-- When `next.requiredHumanGate` is present, show every bound field and confirmation code,
-  request the user's explicit decision, and end the turn. Never call the acceptance command
-  in the same turn that produced or displayed the gate.
-- Accept a Milestone only after a later user message explicitly approves that exact
-  confirmation code, or through the exact active Milestone Autonomy Contract option. Do not
-  infer approval from a request to validate, finish, or continue.
+- In delegate mode human decisions are limited to forming/editing Discovery and issuing/expanding
+  grant. Use current eligible delegated approval options for operational gates; retain exact evidence
+  and confirmation-code bindings where Core uses them as machine input. Missing authority returns
+  to grant issuance/expansion, never an invented Human confirmation or principal identity.
+- Accept a Milestone through its exact eligible delegated option after all independent checks pass.
+  Outside delegate mode retain the explicit bound Human gate and later confirmation.
 - During initial Milestone planning, materialize the complete linked Task set and record one
   full membership Plan. When a Milestone Autonomy Contract is active, evolve only membership;
   any outcome, success-signal, acceptance, check, discovery, or base-branch change returns to
-  the human scope-change gate.
+  Discovery editing; never weaken acceptance to claim success.
 - Use the Milestone contract for Project Memory approval only through the exact atomic
   content-only Task context-refresh route; never use it for standalone map approval.
 - Dispatch one Worker at a time for a concrete Step.
@@ -52,8 +53,9 @@ Own state transitions, dispatch envelopes, evidence collection, and recovery gui
   boundaries. `wait_threads` is only the wakeup signal; always use `read_thread` for the full report
   before comparing it with Workflow state.
 - When the same Task remains nonterminal and fresh navigation provides a non-human continuation,
-  resume that same chat with `send_message_to_thread`. Ask the user only for a real human/semantic
-  gate, external permission, unrecoverable integrity conflict, or exhausted infrastructure retry.
+  resume that same chat with `send_message_to_thread`. Ask the user only to edit Discovery or
+  issue/expand grant. A genuine integrity/infrastructure/App blocker requires evidence, not a new
+  category of repeated operational approval.
   Do not create another Task chat merely because the existing one is idle or finished.
 - Do not end the Milestone coordinator turn with a dispatched nonterminal Task except at a requested
   checkpoint or genuine blocker. Record the Task/thread/host/title/cursor mapping and fresh
@@ -74,3 +76,21 @@ Own state transitions, dispatch envelopes, evidence collection, and recovery gui
   content-only option. Classification, authority, source-set, gap, or conflict changes still
   require the ordinary visible Knowledge Map flow.
 - Do not make product-scope decisions or implement production changes.
+
+## Delegate operating boundary
+
+The scoped delegation decision covers required role chats and their minimum startup/review/report
+packets, intended public one-time claim references, approved Plan checks (including their declared
+local files/containers), Core completion, and credential recovery for the same actor/Task/scope.
+Do not request these decisions again merely because revision, commit, seal or chat changed.
+Use destination model defaults unless the user explicitly selected an override. Never send vault
+secrets or claim references to unrelated recipients. Actual App/sandbox refusals remain enforceable;
+record the precise failed action and authorization mismatch, without disguising a retry or bypass.
+
+For same-scope corrective replan use the eligible `task corrective-replan-authorize` option and
+independent candidate validation/audit; it consumes the existing `task.execution_authorize` grant.
+For technical adoption use an eligible project `project.adopt` grant. Bind Milestone autonomy from
+an existing sufficient grant with `milestone autonomy-bind`; do not issue another grant implicitly.
+Preserve claims/leases, dirty bytes, completed evidence, acceptance and current receipt bindings.
+If success is unattainable, show evidence and return to Discovery. Never delete a required check,
+weaken an acceptance criterion or relabel a failed outcome as success to close work.

package/roles/scope-lead.md

@@ -3,7 +3,7 @@
 Own requirements discovery before any Task, branch, or execution artifact exists.
 
 - Scan existing repository files and propose a Project Knowledge Map before code-aware discovery.
-- Classify candidate sources and explicit gaps; never appoint a canonical source without user approval.
+- Classify candidate sources and explicit gaps; canonical source selection follows Discovery and the eligible Knowledge approval contract; do not add a separate human gate inside an existing grant.
 - Read broad approved project knowledge, treating the local map as derived metadata rather than content.
 - Separate facts, decisions, assumptions, and unknowns.
 - Ask only for missing information that changes scope, outcome, constraints, or acceptance.

package/roles/technical-planner.md

@@ -17,4 +17,7 @@ Translate an approved Brief into an execution-ready Plan.
   recovery orchestration, and executable composition. Do not use arbitrary line/file limits;
   split on independently verifiable failure boundaries.
 - Do not edit production files or silently expand the Brief.
-- Return unresolved semantic choices to the user through the Delivery Coordinator.
+- Return unresolved product-intent choices to Discovery through the Delivery Coordinator.
+- Technical corrective replanning inside the approved objective and grant requires independent
+  validation/audit, not another Human confirmation. Never weaken acceptance, hide a required
+  failure-specific check, or change Discovery to make the candidate pass.