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

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.6, 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/docs/stable-release-defect-register.md

@@ -1,11 +1,11 @@
 # Stable Release Defect Register
 
 This register captures defects and operational gaps found while running the
-alpha.7 line against the `signal_v4` Milestone 3 lifecycle. It is intentionally
+alpha.7 through beta.6 lines against the `signal_v4` Milestone 3 lifecycle. It is intentionally
 separate from implementation briefs: an item stays here until it is either
 verified fixed by a regression test or explicitly classified as downstream-only.
 
-Last reviewed: 2026-08-15.
+Last reviewed: 2026-08-21.
 
 ## Severity and status
 
@@ -14,6 +14,57 @@ Last reviewed: 2026-08-15.
 - **Closed-regression** means a patch exists; the stable release must retain its regression coverage.
 - **Downstream** means the finding belongs to `signal_v4`, not to the workflow package.
 
+## Post-beta.5 open findings
+
+### WF-STABLE-025 — a new Codex task receives a stale personal-plugin skill path
+
+- Status: Investigation; behavior reproduced, ownership boundary not yet isolated
+- Severity: High
+- Area: personal plugin installer, cachebuster registration, Codex App skill discovery
+- Evidence: after `signal_v4` was updated to `codex-workflow-v2@2.0.0-beta.5` and the packaged
+  `codex-workflow-gateway` installer completed, the new Codex task `Возобновить recovery
+  Milestone 3` received the catalog path ending in cachebuster `0.1.0+codex.20260818092852`.
+  That file no longer existed. The actually installed skill was under
+  `0.1.0+codex.20260821083915`; the agent found it only by searching the local plugin cache.
+- Reproduction: open a new task after installing a cachebuster update, use the skill path supplied
+  to that task, and observe an immediate file-not-found failure before any workflow action. The
+  task can continue only after out-of-band cache discovery. This contradicts the installer guidance
+  that starting a new task is sufficient to load the updated plugin.
+- Risk: routine Workflow starts produce a noisy, repeated failure. More importantly, if both cache
+  generations remain present, a task may silently load stale gateway rules instead of failing,
+  weakening exact-version routing and human-gate guarantees.
+- Required closure:
+  - determine whether the stale reference is emitted by the packaged installer/registration flow
+    or retained by Codex App's skill catalog;
+  - after an A-to-B cachebuster update, every newly created task must resolve B without filesystem
+    search and must never advertise a missing or superseded A path;
+  - if an application restart is an unavoidable boundary, the installer must detect and report it
+    explicitly instead of claiming that a new task alone is sufficient;
+  - retain an integration regression covering install, cachebuster update, new-task discovery, and
+    exact `SKILL.md` content identity.
+- Scope note: no workflow-state mutation occurred before the fallback lookup. This finding is
+  independent from the stale Plan Risk Audit recovery defect observed later in the same task.
+
+### WF-STABLE-026 — Milestone authorization can bypass stale Project Memory
+
+- Status: Closed-regression in beta.6
+- Severity: Critical
+- Area: repository navigation, Project Memory authority, Milestone authorization
+- Evidence: while resuming `signal_v4` Milestone 3 on beta.5, the persisted Project Memory map was
+  active but its current scan was stale after the workflow dependency changed. Repository `next`
+  still advertised Milestone authorization, and direct Milestone authorization/autonomy methods did
+  not independently require a current approved map.
+- Risk: an existing Milestone could be authorized against stale Project Memory, after which linked
+  Task Plan contracts would bind obsolete source hashes or force an unadvertised manual recovery.
+- Fix: repository navigation now derives the current map status before Discovery or Milestone
+  authorization and routes `project-memory reconcile`/`approve` first. Direct Milestone authorize,
+  autonomy prepare, and autonomy grant also fail closed unless the current map is active and
+  approved.
+- Regression evidence: `tests/milestone.test.ts` proves that reconcile/approval preserves the exact
+  existing Milestone and Plan, then advertises Milestone authorization and binds the linked Task
+  Plan contract to the refreshed map revision/hash. A separate witness proves stale Project Memory
+  outranks replacement Discovery.
+
 ## Beta.2 closure candidates
 
 ### WF-STABLE-009 — initial assembly creates a state rejected by `status` and `next`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-workflow-v2",
-  "version": "2.0.0-beta.4",
+  "version": "2.0.0-beta.6",
   "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 },