codex-workflow-v2 2.0.0-beta.13.13 → 2.0.0-beta.13.15

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

@@ -15,6 +15,13 @@ repository.
 Never use a global workflow package, a mutable npm range, `latest`, V1 overlay
 files, or MCP ADR storage as a fallback.
 
+Read this skill once per chat/package revision; do not reopen it merely to recover details already
+captured in the current task context. For code discovery, first read
+`../../references/codebase-memory-routing.md` and follow its exact-source-root gate. Knowledge Map
+approval is not an MCP index. Use `codebase-memory-mcp` before filesystem code search, select the
+graph from fresh Core `graph status`, by exact `sourceRoot`, and record the documented fallback
+reason whenever direct code search is unavoidable.
+
 ## Resolve The Active Package
 
 1. Resolve the active Git root with `git rev-parse --show-toplevel`.
@@ -92,7 +99,7 @@ active writer token when the C1 contract requires it. The recovery records only
 `task run` merely to manufacture the second failure, and never invoke this recovery for a generic
 test failure, a writable manifest, or unconfined changes.
 
-For beta.13.13, the exact published target runner may perform only read-only
+For beta.13.13 and beta.13.14, the exact published target runner may perform only read-only
 `update plan-integrity-update-preflight --id <TASK-ID>` against a coherent beta.13
 source from beta.13.11 with a strictly newer target and a freshly proved V4 literal
 test invocation conflict. Require eligible=true, exact Task/Plan/HEAD and dirty
@@ -109,6 +116,11 @@ classification changes, changed dirty bytes or unavailable authority block this
 route. Do not refresh source context first to conceal the failed-Step boundary,
 edit state, or apply the extra test patch before Core grants its bounded scope.
 
+In beta.13.14, historical root-cause carryover is assessed only for a planned
+replacement Step, matching execution. It must not mask current failed-Step scope
+recovery. Preserve the original C1 claimant; delegated context refresh does not
+issue or renew a writer credential. Follow fresh navigation for credential recovery.
+
 When fresh `next` includes `preExecutionReplanOption.state=eligible`, an independent Plan auditor
 may stop a `ready` Task before its next Step because the current implementation Plan is obstructed.
 Use only `task preexecution-replan` with the exact advertised Task revision, Brief hash, Plan hash,
@@ -491,8 +503,8 @@ Task details, other Task Plans, unrelated repository analysis, reasoning traces,
 credentials. The new Task chat may read repository files and its own Workflow Task/Brief/Plan; it
 must not rely on the parent conversation as evidence or authority.
 
-Every automatically created Coordinator, Task, Step Review, Final Review, Corrective Audit, and
-Plan Audit chat must use the project registry/title builder at
+Every automatically created Coordinator, Task, Step Review, Final Review, Corrective Audit, Plan
+Audit, and Workflow Blocker chat must use the project registry/title builder at
 `../../scripts/chat-registry.mjs`. Before `create_thread`, call `allocate` with exact `projectId`,
 chat type, Milestone/Task/Step membership ordinals, semantic title, authoritative entity ID, and
 review attempt. Use returned `requestedTitle` verbatim. Never derive its prefix from
@@ -524,6 +536,7 @@ The builder owns these compact title families; callers must not hand-compose var
 #NNN · M<NN>/T<NN> · Final Review A<N> · <Task title> · <TASK-ID>
 #NNN · M<NN>/T<NN>/S<NN> · Corrective A<N> · <Step title> · <TASK-ID>
 #NNN · M<NN>/T<NN> · Plan Audit A<N> · <Task title> · <TASK-ID>
+<exact next beta patch version>                                      # Workflow Blocker
 ```
 
 When the Milestone ID is known, allocate and bind the coordinator chat before dispatch. During
@@ -613,20 +626,62 @@ transcripts. No chat may wait indefinitely for a child after ending its own turn
 cross-restart background orchestration requires a separate app wakeup/automation facility and is
 not implied by this skill.
 
+
+## Workflow Blocker Incident Route
+
+Core only describes this route. It does not create a chat, authorize repository changes, run a
+release, publish a package, update a downstream project, or message another chat. The originating
+Coordinator owns incident initiation and verifies that the new chat received its closed instructions.
+The patch chat in `codex-workflow-v2` owns diagnosis, implementation, verification, publication,
+and the callback to the Coordinator.
+
+Treat `next.workflowBlockerRoute.state=gateway-confirmation-required` as a candidate incident, not
+as an executable Core transition. Refresh `status` and `next` sequentially without mutation and
+continue this route only when the same `blockerId` remains, no executable Core action, repair
+transition, or Human gate exists, and the responsible product chat is not progressing the blocked
+action. If an ordinary route appears, use it and do not create a patch chat.
+
+For a confirmed incident, the Coordinator must:
+
+1. Resolve the exact `codex-workflow-v2` App project with `list_projects`; never hardcode an App
+   project ID or create the patch chat in the product project.
+2. Build the closed incident packet from the descriptor's `requiredPacketFields`, fresh status and
+   next hashes, bounded repository state, and the expected product continuation. Exclude bearer
+   credentials, confirmation codes, transcripts, and reasoning traces.
+3. Allocate `type=workflow-blocker` with `entityId=<blockerId>` and
+   `semanticTitle=<dispatch.title>`. This type has no Milestone/Task membership and its sole title
+   candidate is the exact beta version. Run the normal `dispatch-begin -> create_thread ->
+   dispatch-result -> dispatch-observe -> readback -> bind` sequence. Use the policy-selected
+   explicit model and effort; never inherit the Coordinator settings.
+4. Confirm once with `read_thread` that the created patch chat received the exact closed incident
+   packet and has started it. Do not poll, wait on, or supervise this chat. The patch chat must run
+   every remaining step autonomously and use `send_message_to_thread` to deliver the closed callback
+   to the originating Coordinator after the exact patch is published.
+5. When that callback arrives, verify the published artifact, follow the advertised downstream update route in the product
+   repository, rerun fresh `status -> next`, and continue the existing responsible product chat
+   with only that route and changed bindings. Do not replace the Coord or product chat solely
+   because a workflow incident occurred.
+
+The incident descriptor grants no Core mutation or publication authority. A callback claim does
+not replace package readback or fresh product navigation.
+
 ## Product Or Workflow Graph Refresh
 
-1. Run `graph refresh-request --kind product|workflow --mode moderate`.
-2. Use `codebase-memory-mcp` to list projects and match the request source root.
-3. Stop for user selection when more than one project remains plausible.
-4. Check `index_status`; call `index_repository` with the request source root,
-   mode, and `persistence: false` when missing or stale.
-5. Build evidence exactly as specified in `../../references/protocol.md`.
-6. Pipe `{ "request": ..., "evidence": ... }` to `graph bind --stdin`, passing
+Follow `../../references/codebase-memory-routing.md`. In particular, select only the MCP project
+whose normalized root exactly equals the fresh Core request's `sourceRoot`; never choose by name,
+repository generation, or Knowledge Map membership.
+
+1. Run `graph refresh-request --kind product|workflow --mode moderate|full` for the intended code.
+2. Use `codebase-memory-mcp` to list projects and exact-match the request source root.
+3. Check `index_status`; call `index_repository` with the request source root,
+   requested mode, and `persistence: false` when missing or stale.
+4. Build evidence exactly as specified in `../../references/protocol.md`.
+5. Pipe `{ "request": ..., "evidence": ... }` to `graph bind --stdin`, passing
    the current binding revision when one exists.
 
-When MCP is unavailable, run `graph fallback --kind ... --reason ...`. Continue
-with Git, direct file reads, and configured tests unless another requirement
-independently blocks the workflow.
+When MCP is unavailable after its normal retry boundary, run
+`graph fallback --kind ... --reason ...`. Only then use direct filesystem code discovery, while Git,
+exact package resolution, named authority artifacts, and configured tests retain their normal tools.
 
 ## Role Use
 
@@ -787,6 +842,22 @@ returns `safe=true` with a clean checkout, no running Step, and no active writer
 
 ## Explain an implementation change before escalating
 
+For registry `step-review`, `final-review`, `corrective-audit`, and `plan-audit` roles, inspect
+only the canonical repository and immutable commit/packet/seal or audit-request evidence. Verify
+those bindings before reading and returning the result. A detached or different App branch does
+not require Task-branch reconciliation for read-only review. Do not change product files, Git
+history or Workflow state, or invoke lifecycle mutations. Save an explicitly requested report only
+outside repository checkouts under actual filesystem permissions; the dispatch prompt grants no
+access. This review boundary does not apply to a Worker merely using a review-phase model.
+
+Read-only Workflow diagnostics are not necessarily write-free: `next` can prepare an external
+reviewer runtime cache and write/remove `.write-probe`. Check actual cache permissions for normal
+review diagnostics. When the user explicitly prohibits every write, reuse current bound receipts
+and the prior successful same-session handshake, read immutable evidence directly, and avoid
+runtime-preflight APIs. Do not rerun `next` or save an artifact under that prohibition; report any
+unverified current binding. The user's zero-write instruction controls. See
+`../../references/chat-dispatch.md` for the distinction.
+
 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