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

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

@@ -124,8 +124,8 @@ paths and content hash. Every retained path must already be allowed by the new S
 and remain outside forbidden scope. A changed binding or blocked assessment is a hard
 stop; never clean, stash, reset, manually commit, or edit state to make it eligible.
 
-The beta.13.7 consumed-carryover compatibility profile also permits the exact
-published external beta.13.7 runner to execute only the read-only
+The beta.13.8 consumed-carryover compatibility profile also permits the exact
+published external beta.13.8 runner to execute only the read-only
 `update corrective-carryover-preflight --id <TASK-ID>` against a coherent beta.13.6
 repository. A completed, verified Step's carryover remains historical evidence;
 it must not override a later Step's repeated-cause recovery route.
@@ -151,13 +151,22 @@ another compatibility action. `sourceRecovery` never authorizes transport or
 Once the replacement Plan is authorized and that same Worker has claimed it,
 the preflight may expose the exact expired-lease repair described below. Never
 force-release a live lease. Require a fresh top-level `eligible=true` before
-dependency transport. beta.13.7 accepts one dependency-only commit on each of
+dependency transport. beta.13.8 accepts one dependency-only commit on each of
 the Task and Milestone base, with the same exact source beta.13.6 and target
-beta.13.7. After installing the target, use its ordinary advertised
+beta.13.8. After installing the target, use its ordinary advertised
 dependency provenance recovery, atomic context refresh and original-Worker
 credential recovery. This profile permits no external state mutation, installed
 code patch, wider product commit, changed dirty bytes, or approval substitution.
 
+The exact beta.13.9 runner supports the same bounded consumed-carryover profile
+with beta.13.6 as its source and beta.13.9 as its pinned target. Require the
+returned version bindings and all the same source-recovery and transport proofs.
+Historical beta.13.8 evidence is not proof for a beta.13.9 invocation.
+
+The historical beta.13.7 runner retains its own exact beta.13.6-to-beta.13.7 profile.
+The current beta.13.8 profile does not admit a beta.13.7 source or an in-progress
+Step and cannot be used to bypass the ordinary safe update boundary.
+
 The historical beta.13.6 corrective-carryover update compatibility profile permits its exact
 external runner to execute only the read-only
 `update corrective-carryover-preflight --id <TASK-ID>` against a repository coherently
@@ -653,10 +662,20 @@ delegable only through an explicit project-scoped `project_memory.approve` permi
 changes, grant issuance, and grant expansion are never delegated by `delegated-approval-v1`.
 
 For an entire Milestone, prefer one bounded `milestone autonomy-prepare` gate after the complete
-initial membership Plan exists. Show principal, delegate, expiry, semantic-scope hash, policy
+initial membership Plan exists. An explicitly human-requested full contract may also be prepared
+for an `active` Milestone, including after a previous contract expired or was revoked. This is
+new issuance, never automatic renewal. Fresh Task-first or repository `next` may expose
+`activeMilestoneAutonomyOptions`; these are optional preparation routes and do not replace the
+current Task action. Preparation still requires coherent state and active Project Knowledge.
+A generic grant does not become a full contract and is not automatically revoked. A still-valid
+full contract must first be explicitly revoked by its principal before a different one is issued.
+The new confirmation binds the current Milestone status, revision, Plan, semantic scope, policy,
+and previous contract/grant state; any change requires preparation and confirmation again.
+An exact successful retry returns the same grant; an old code cannot revive a revoked grant. Show principal, delegate, expiry, semantic-scope hash, policy
 hash, and `MAC-*` code, then stop. A later exact approval permits `milestone autonomy-grant`.
 Use the delegated path only when the same `next` response exposes
-`milestoneAuthorizationOptions[].action = "milestone autonomy-prepare"` and the user explicitly
+`milestoneAuthorizationOptions[].action = "milestone autonomy-prepare"` or an
+`activeMilestoneAutonomyOptions` entry for that exact Milestone, and the user explicitly
 requested delegated Milestone operation; otherwise follow the ordinary `milestone authorize`
 human gate.
 The resulting grant covers the existing Task/Milestone approval transitions and the Project
@@ -668,6 +687,18 @@ only for membership changes; any change to outcome, success signal, acceptance,
 discovery, or base branch requires the ordinary human scope-change gate. Never self-renew or
 replace the contract.
 
+When fresh `next` advertises `task corrective-decision` with
+`planningRecovery.authority = "planning-only"`, a started failed Step has a current
+blocking audit after a Knowledge-only Plan rebind. Core proves the historical approved
+safety baseline; the stopped audit does not authorize execution. Obtain the independent
+corrective decision against the returned bindings and preserve the exact original Worker
+credential/yield prerequisites. Follow the existing human-confirmed corrective-replan
+route, then fresh replacement Plan authorization. Never approve the obstructed Plan merely
+to unlock navigation, use ordinary `plan-set` to bypass the corrective gate, or create an
+upstream remediation Task for this already-started posture. `continue-fix` is unavailable
+for this planning-only route. A package update can require another Knowledge rebind and
+fresh blocking audit; do not rewrite or silently reuse a stale audit.
+
 Repeated failed Task reviews remain on the same Task and do not require a separate corrective
 Plan audit based only on count. Follow fresh `next`: ordinary findings default to `route=fix`;
 `route=replan` is valid only with the exact Plan clause, obstruction, and minimal Plan change
@@ -736,3 +767,18 @@ returns `safe=true` with a clean checkout, no running Step, and no active writer
 - A lifecycle `status` or `next` failed; do not continue with a different lifecycle mutation.
 - A human gate was emitted but the user has not approved its exact confirmation code in a
   later message and no exact eligible delegated approval option exists.
+
+## Explain an implementation change before escalating
+
+Before a product write by a tracked Worker, run the packaged registry `dispatch-context-check`
+using fresh App readback, the actual write root and the branch from the current Task. Resolve
+checkout mismatch without duplicate dispatch or silent canonical-checkout writes. A matching
+context is not a filesystem permission or writer credential.
+
+When a fix needs additional files, the route is unclear, or an external operation was denied,
+use read-only `change explain --task <exact Task ID> --file <closed proposal JSON>` as documented
+in `docs/change-model.md`. Present all known blocking layers together. Never relabel an external
+permission refusal as a missing grant. `requiresUser: null` is unknown, not blanket approval.
+For an exact Core-derived check-support amendment, follow the existing advertised recovery and
+fresh next; do not manually widen allowedWrites or issue new authority. Membership, semantic
+scope and Knowledge refresh retain their separate existing routes and evidence requirements.