codex-workflow-v2 2.0.0-beta.4 → 2.0.0-beta.5

package/docs/release.md

@@ -22,7 +22,7 @@ The downstream smoke packs the actual tarball, installs it into an empty tempora
 runs the packaged CLI handshake, and proves installation created none of `.codex`, `.tasks`,
 `.increments`, or `.memory-bank` in that project.
 
-For beta.4, the release gate also relies on `npm run release:check` to fail if:
+For beta.5, the release gate also relies on `npm run release:check` to fail if:
 
 - canonical entity schema 2 shapes drift;
 - protocol 2 is not the active public contract, or intact protocol-1 adoption evidence stops being readable through the bounded compatibility window;
@@ -35,6 +35,8 @@ For beta.4, the release gate also relies on `npm run release:check` to fail if:
 - truthful initial-assembly navigation capability is absent from the packaged surface.
 - corrective-yield/replan protocol-v2 commands, closed schemas, Human gate, retained journals,
   explicit recovery, or dual-readback capabilities are absent from the packaged surface.
+- scoped Task navigation, credential replacement recovery, or sealed external Task/Step review
+  commands are absent from the packaged surface.
 
 The separate lifecycle transcript validator fails if the real-agent log contains a mutation that
 bypasses failed `status`/`next`, an unadvertised or failed mutation, an unresolved syntax-only

package/package.json

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

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

@@ -79,6 +79,12 @@ wait for its terminal success, and only then run `next`; never launch the checkp
 parallel or in one parallel tool batch. If either fails, stop; do not
 describe the reverse-membership gap as expected and invoke a direct closing command.
 
+When `next` includes `milestoneCancellationOption`, treat it as an advertised alternative only
+when the user has explicitly requested cancellation or supersession of that exact Milestone.
+Use the returned Milestone ID and expected revision verbatim, require a substantive user-supplied
+reason, and preserve every historical Task and sidecar. Absence of this option means cancellation
+is not currently navigable; do not invoke `milestone cancel` directly.
+
 When `next` includes `gitMutationPolicy`, obtain bounded permission for that exact Git-writing
 transition before the first call. Do not probe and retry after a `.git/index.lock` failure.
 For `task start`, the policy applies only when choosing `--workspace-owner local`; for
@@ -104,6 +110,13 @@ exact invocation syntax is not already available from `next` and this protocol.
 `requiredOptions` and `optionalOptions`; when `exactOptionContractAvailable=false`, consult the
 packaged protocol instead of guessing. Help never replaces a fresh `next` before mutation.
 
+When two or more Tasks are actionable, a dedicated Task chat may call `next --task <exact Task ID>`
+after the repository `status` checkpoint. The selector is read-only routing, not authorization: the
+response must name that same Task and all ordinary milestone, observation, adoption, Knowledge, and
+credential gates still apply. Omit `--task` for repository-level coordination. If Core reports that
+the selected Task is missing or not actionable, stop rather than falling back to another Task or
+invoking a direct mutation.
+
 ## Product Or Workflow Graph Refresh
 
 1. Run `graph refresh-request --kind product|workflow --mode moderate`.
@@ -171,6 +184,10 @@ changes, grant issuance, and grant expansion are never delegated by `delegated-a
 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
 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
+requested delegated Milestone operation; otherwise follow the ordinary `milestone authorize`
+human gate.
 The resulting grant covers the existing Task/Milestone approval transitions and the Project
 Memory approval portion of an atomic Task context refresh for the same Milestone. Besides
 content-only drift, Core may accept exact supporting-source additions predeclared by the current
@@ -184,6 +201,25 @@ After two failed Task reviews, follow `next.correctivePlanGate`: obtain a distin
 corrective Auditor result and pass it through `--corrective-audit-file`. Do not continue for
 replan, split, or stop decisions.
 
+When `next.strictStepReview.recommendedMode` is `external-sealed`, do not launch the nested local
+reviewer from inside a Codex App sandbox. Run the advertised read-only `task step-review-packet`,
+create a separate user-visible reviewer chat for that exact packet, and require one closed
+`ReviewInput` JSON result bound to its reviewed commit. The reviewer must not modify repository or
+Workflow state. Then run only the advertised `task step-review-record` with the unchanged packet
+and repository-seal hashes, the separate reviewer thread ID, the lifecycle actor from `next`, and
+the active writer token when required. Never author the independent review in the Worker or
+Delivery Coordinator chat, never alter the packet, and never treat an unverified local reviewer
+launch as a semantic remediation failure. If Core reports the seal changed, discard the review and
+stop; do not regenerate evidence against a moving checkout.
+
+When `next.strictTaskReview.recommendedMode` is `external-sealed`, apply the same isolation rule to
+the final submitted-Task review. Run the advertised read-only `task review-packet`, send the exact
+packet to a separate user-visible Independent Reviewer chat, and accept only a closed `ReviewInput`
+bound to the unchanged packet and repository-seal hashes. Record it only through the advertised
+`task review-sealed-record`, using the lifecycle actor from `next` and the active writer token when
+required. Do not call `task review-launch` from inside a Codex App sandbox, do not use the Worker or
+Delivery Coordinator as reviewer, and discard the result if a fresh packet changes either hash.
+
 When `next` returns a derived C1 Worker or corrective Auditor actor, use that exact actor without
 asking the user to name one. Derivation removes a routing pause; handoff claim, writer lease,
 strict review, and auditor-independence checks remain mandatory.

package/schemas/task-handoff-event.schema.json

@@ -50,7 +50,7 @@
     "grantId": { "type": ["string", "null"], "minLength": 1 },
     "claimTokenHash": { "$ref": "#/$defs/hash64" },
     "expiresAt": { "type": "string", "format": "date-time" },
-    "eventType": { "enum": ["handoff", "claim", "yield", "handback"] },
+    "eventType": { "enum": ["handoff", "claim", "credential-replace", "yield", "handback"] },
     "coordinationLevel": { "const": "C1" },
     "actor": { "type": "string", "minLength": 1 },
     "targetActor": { "type": ["string", "null"], "minLength": 1 },