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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-workflow-v2",
-  "version": "2.0.0-beta.13.9",
+  "version": "2.0.0-beta.14",
   "description": "Requirements-first Codex development workflow with local state and explicit Git ownership.",
   "repository": {
     "type": "git",
@@ -16,7 +16,7 @@
     "access": "public"
   },
   "engines": {
-    "node": ">=22"
+    "node": "24.17.0"
   },
   "bin": {
     "codex-workflow": "dist/src/cli.js"
@@ -28,36 +28,35 @@
   },
   "files": [
     "dist",
+    "src",
     "schemas",
     "templates",
     "roles",
     "references",
     "plugins",
     "docs/*.md",
-    "docs/lifecycle",
-    "docs/pdf",
-    "docs/problem-briefs",
-    "scripts/generate-pdf-docs.py",
-    "scripts/run-pdf-docs.mjs",
     "README.md"
   ],
   "scripts": {
     "clean": "node --eval \"import('node:fs').then(({rmSync}) => { rmSync('dist', {recursive:true, force:true}); rmSync('.test-dist', {recursive:true, force:true}); })\"",
-    "build": "npm run clean && tsc -p tsconfig.build.json && node scripts/mark-cli-executable.mjs",
+    "build": "node scripts/with-validation-lock.mjs build",
     "typecheck": "tsc -p tsconfig.json --noEmit",
     "test": "node scripts/with-validation-lock.mjs test",
     "test:signal-t04-recovery": "node scripts/with-validation-lock.mjs test-signal-t04",
     "test:signal-t03-replan-e2e": "node scripts/with-validation-lock.mjs test-signal-t03-replan",
     "test:signal-remediation-e2e": "node scripts/with-validation-lock.mjs test-signal-remediation-topology",
     "test:signal-t10-check-support-e2e": "node scripts/with-validation-lock.mjs test-signal-t10-check-support",
-    "validate": "npm run typecheck && npm test",
-    "pack:check": "npm run build && npm pack --dry-run",
-    "smoke:downstream": "npm run build && node scripts/downstream-smoke.mjs",
+    "validate": "node scripts/with-validation-lock.mjs validate",
+    "pack:check": "node scripts/with-validation-lock.mjs pack",
+    "smoke:downstream": "node scripts/with-validation-lock.mjs smoke",
     "plugin:check": "node scripts/validate-plugin.mjs",
     "docs:pdf": "node scripts/run-pdf-docs.mjs",
     "docs:pdf:check": "node scripts/run-pdf-docs.mjs --check",
     "release:check": "node scripts/release-check.mjs",
-    "publish:release": "node scripts/publish.mjs"
+    "publish:release": "node scripts/publish.mjs",
+    "release:verify": "node scripts/release-passport.mjs verify",
+    "release:passport": "node scripts/release-passport.mjs attach",
+    "prepublishOnly": "node scripts/block-direct-publish.mjs"
   },
   "dependencies": {
     "ajv": "8.20.0",
@@ -68,7 +67,6 @@
   },
   "devDependencies": {
     "@types/node": "24.10.1",
-    "codex-workflow-source-beta136": "npm:codex-workflow-v2@2.0.0-beta.13.6",
     "typescript": "5.9.3"
   },
   "license": "MIT"

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

@@ -1,6 +1,6 @@
 {
   "name": "codex-workflow-gateway",
-  "version": "0.1.0+codex.20260830183000",
+  "version": "0.1.0+codex.20260910143746",
   "description": "Thin personal Codex gateway for exact project-local Codex Workflow V2 packages and codebase-memory-mcp.",
   "author": {
     "name": "Codex Workflow Maintainers"
@@ -24,7 +24,7 @@
     ],
     "defaultPrompt": [
       "Show the next valid Codex Workflow V2 action.",
-      "Refresh the project code graph for planning.",
+      "Check the installed workflow graph.",
       "Check project memory and workflow readiness."
     ],
     "brandColor": "#2563EB"

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

@@ -1,204 +1,80 @@
-# Durable App dispatch and explicit model selection
+# Authorized App dispatch
 
-This is an App orchestration journal, not Workflow authority. It does not call the App, approve
-Git writes, renew grants, mint credentials, or replace Core status/next. All commands below use
-`node <exact-package>/plugins/codex-workflow-gateway/scripts/chat-registry.mjs` and the existing
-24-hex Workflow `--project-id`. The App project ID is a separate field.
+Use the exact package's `scripts/chat-registry.mjs` under this plugin for reservations, titles,
+creation receipts and supervision. Workflow `projectId` and App `appProjectId` are distinct.
+The journal supplies routing evidence; it grants no App, Git, credential or approval authority.
+Use the script's command contract for arguments rather than reimplementing title/model logic.
 
-## One reservation, one creation attempt
-
-`allocate` reuses the same non-abandoned role/entity/membership/attempt reservation. Task and
-Coordinator allocations also reuse it when a caller changes the attempt number. Review attempts
-advance only after the actual Workflow review cycle advances. Never invent a new attempt or
-reservation to bypass unresolved creation. Existing v1 registries remain readable; legacy bound
-threads remain usable with explicit model/thinking arguments from the same policy; `model-select`
-and `supervision-record` currently require a tracked dispatch and do not retrofit legacy evidence.
-Legacy unbound reservations may have already created a chat: reconcile
-those using real App/source evidence before using the new dispatch flow.
-
-1. Save the closed context packet to a private local file. Do not include bearer credentials,
-   parent transcript, or approval narratives. Prepare a private dispatch request JSON:
-
-   ```json
-   {
-     "repositoryRoot": "/absolute/canonical/repository",
-     "appProjectId": "project-id-from-list-projects",
-     "hostId": "local",
-     "promptFile": "/private/tmp/task-context.txt",
-     "modelRequest": {
-       "phase": "planning",
-       "complexity": "standard",
-       "highRisk": false,
-       "rationale": "New multi-file implementation plan with established requirements.",
-       "availableModels": [
-         {"id": "gpt-5.6-sol", "reasoningEfforts": ["low", "medium", "high", "xhigh", "max", "ultra"]}
-       ]
-     }
-   }
-   ```
-
-   Populate `availableModels` from the destination App tool's actual model/effort contract, not
-   this example, the parent's settings, API pricing pages, or a guessed alias. Explicit user
-   authorization to select models is required; journal input is not user authorization.
-2. Run `dispatch-begin --reservation-id ID --file request.json` **before** `create_thread`.
-   Save its complete output to a mode-600 file. It atomically persists a creation marker, packet
-   hashes, repository binding and requested model selection, then returns `createAllowed:true`
-   and exact `createArgs` including `model` and App field `thinking`.
-3. Only the process receiving that one permission may make **one** `create_thread(createArgs)`
-   call. A second begin, even after restart or timeout, returns `createAllowed:false` and no
-   create arguments. Do not reissue the external call after a lost/ambiguous response. The marker
-   prepended to the packet is routing provenance, not parent history.
-4. Save the full App result locally, normalize its successful tool text JSON to
-   `{"result":{"clientThreadId":"client-new-thread:...","hostId":"local"}}` or
-   `{"result":{"threadId":"actual-uuid","hostId":"local"}}`, and run `dispatch-result`.
-   Preserve raw evidence separately. Never parse truncated displayed stdout as the full receipt.
-   Invalid JSON cannot change the journal. A pending client ID is never a usable thread ID.
-5. Use `dispatch-status` to resume. Missing `list_threads` results are not proof of failure.
-   If the actual ID is unavailable, identify candidate rollout files from creation-time/worktree
-   evidence and run `dispatch-discover --file candidates.json`, where the file is
-   `{"sessionFiles":["/absolute/rollout.jsonl"]}`. The helper reads only supplied files, checks
-   actual session metadata, exact original dispatched prompt (including the App's routing XML),
-   and the Git common directory. It ignores guardian/subagent sessions and unrelated prompts.
-   It prints candidate IDs/paths only, never transcripts or reasoning. Use bounded candidate
-   lists, not vault searches. Malformed, oversized or partially written files need a later fresh
-   read; they never authorize another creation.
-6. Confirm a correlated candidate using `read_thread`. Save its full response as
-   `{"observation": <parsed read_thread JSON>}` and run `dispatch-observe`. It checks actual UUID,
-   host, repository/worktree and App project when supplied. One candidate still requires App
-   readback; several candidates produce a duplicate conflict and require explicit disposition,
-   not arbitrary selection. After confirming one canonical child, inspect every other candidate,
-   reconcile any work it performed, and archive only idle duplicates. Record
-   `dispatch-resolve-duplicates` with `canonicalThreadId` and `dispositions`, one object per duplicate:
-   `{threadId, observation: <read_thread JSON>, archiveResult: {threadId, archived: true}}`.
-   Preserve the actual archive tool receipt; never fabricate it. Repeat canonical readback and bind.
-   Candidate history is retained and no creation permit is restored. This is a local evidence
-   check, not independent App attestation.
-7. Run ordinary title `readback`/rename until exact match. After any rename, repeat
-   `dispatch-observe` with fresh App readback, then `readback` and `bind`. Binding a tracked
-   dispatch requires the same actual ID, host and observed title. Rebinding it to another child,
-   binding a client ID or sharing one child between reservations is rejected.
-8. Run `supervision-record --file report.json` with `threadId`, `ownerThreadId`, `state`
-   (`active|attention|completed`), `cursor` and `nextAction`. Persist significant wait boundaries;
-   only that supervisor waits for this child. The journal stores routing state, not a Workflow
-   verdict. Do not put secrets, CREFs or confirmation codes in it. On restart, read the child and
-   fresh Core status/next before continuing. Worker reports stay local; the coordinator pulls.
-
-A crash between durable begin and actual submission is deliberately ambiguous. There is no
-App idempotency-key API here, so this provides **at most one create permit per reservation**,
-not an exactly-once guarantee. Never clear the marker, abandon it, or expire it by time to retry.
-If no positive creation evidence can be found, report that exact unresolved App operation. A
-permission denial is a separate real gate; do not reroute it through another chat. Fresh user
-approval does not establish that an ambiguous prior creation never happened.
-
-## Model matrix
-
-The versioned policy is `scripts/chat-model-policy.mjs`. It expresses a conservative relative
-cost/latency preference, not measured savings or guaranteed account availability:
-
-| Work | Preferred model | App thinking | Compatible fallback |
-| --- | --- | --- | --- |
-| Routine mechanical transitions, formatting, retrieval | gpt-5.4-mini | low | gpt-5.6-luna / low |
-| Coordinator supervision; small implementation | gpt-5.6-luna | medium | gpt-5.6-terra / medium |
-| Standard implementation | gpt-5.6-terra | medium | gpt-5.6-sol / medium |
-| Task planning | gpt-5.6-sol | medium | gpt-6-astra / medium |
-| Routine Step review | gpt-5.6-terra | medium | gpt-5.6-sol / medium |
-| Standard Step review, final review, plan/corrective audit | gpt-5.6-sol | high | gpt-6-astra / high |
-| Complex work or high risk, any role | gpt-6-astra | high | gpt-5.6-sol / high |
-
-`routine` means a small, well-specified change or mechanical action with an existing check;
-`standard` is ordinary multi-file work; `complex` covers new architecture, unresolved concurrency,
-recovery/provenance or distributed state. Mark `highRisk` for authorization, security-sensitive
-paths, data-loss exposure or irreversible migrations. The coordinator records the concrete
-rationale; classification is a human/agent judgment, not an automatic risk detector. Unknown
-complexity is not routine. Review/audit role floors override a falsely mechanical phase. No
-automatic xhigh/max/ultra, and no escalation merely because a review failed or a tool timed out.
+## Closed packets
 
-The policy chooses only a listed supported pair. If neither preferred nor fallback pair is
-available, stop selection rather than silently inheriting the coordinator or lowering the review
-floor. API docs explain the reasoning/latency tradeoff, while App availability and accepted field
-names come from the live App tool contract:
-https://developers.openai.com/api/docs/guides/latest-model
+A Task packet contains only canonical repository/package identity; Milestone membership ordinal;
+Task ID/revision/title; objective and requirement/acceptance IDs; Brief/Plan hashes; scope/checks;
+and actors/grant IDs required by fresh routing. Exclude credentials, confirmation codes, parent
+transcripts, reasoning, sibling Plans and approval narratives. A host `codex_delegation` routing
+envelope is acceptable only when its input remains that exact packet.
 
-For a phase change in an existing bound chat, call `model-select` with its same `threadId` and
-fresh `modelRequest`; copy the returned `followUpArgs` into `send_message_to_thread` with the
-closed follow-up prompt. For example, planning uses Sol/medium, implementation Terra/medium,
-then mechanical lifecycle work Mini/low. Do not create another Task just to switch model.
-Keep the previous selection unless the phase/risk/scope changes materially. The journal records
-requested settings; tool acceptance/runtime readback, when available, is required to claim the
-actual model used. A model change never changes role, scope, credentials or approval authority.
+Require startup through repository instructions, local gateway/handshake, `status`, then
+`next --task <exact Task ID>`. Stop if another Task is returned. The task continues through its
+advertised planning/execution/review/merge routes until terminal or a real gate/blocker.
+Its non-secret result report identifies Task revision/status, outcome, next action, user-decision
+need and check/commit/review evidence. The receiver verifies those claims against Core.
 
-## Execution context before product writes
+Reviewer/auditor packets carry the immutable commit/packet/seal or audit-request and read-only role,
+not Worker history. Verify canonical evidence before reading and before returning a result.
+Read-only review does not require switching a detached checkout to the Task branch. Save a requested
+report only outside repository checkouts under actual permissions; zero-write instructions forbid it.
 
-`dispatch-begin` accepts optional `executionMode: "local" | "worktree"` (default `worktree`).
-Choose local only for an explicit user request to execute in the saved checkout. The observed
-child checkout, not an absolute path copied from the parent's prompt, is the write destination.
-`dispatch-observe` records it and refuses silent movement of a bound child.
-
-Before the first write, and after any branch/cwd change, use read-only `dispatch-context-check`
-with a fresh App observation, `writeRoot`, and `expectedBranch` from the current Core Task.
-Require `matched=true`, then refresh Core next and writer authority. Mismatch means reconcile the
-same Worker context; it never permits another create, an indirect write or an automatic handoff.
-A matched context does not authorize external operations. See packaged `docs/change-model.md`.
-
-### Existing legacy bindings
-
-`dispatch-context-check` also accepts an already bound legacy entry with no dispatch marker.
-Supply the exact current Task `repositoryRoot` in addition to the fresh actual Worker observation,
-`writeRoot`, and `expectedBranch`. The check verifies the bound thread/host, common Git repository,
-actual checkout/write root and Task branch without changing the registry. It reports
-`contextBinding=legacy-current-observation` and `historicalCheckoutVerified=false`: no historical
-creation marker or checkout provenance is invented. It never enables another create permit.
-This observation does not move a chat, authorize a write or reconcile a tracked dispatch whose
-previous checkout changed; those remain explicit App/context operations followed by fresh checks.
-
-### Explicit App handoff reconciliation
-
-An App handoff can return a new destination thread ID while retaining the task history.
-`bind` still rejects replacing a bound child. After the App operation succeeds, use the
-separate `dispatch-handoff-reconcile --reservation-id ... --file ... --project-id ...` route:
-
-```json
-{
-  "sourceThreadId": "actual-source-thread-uuid-from-the-handoff-call",
-  "sourceHostId": "local",
-  "repositoryRoot": "/absolute/repository-from-fresh-Task",
-  "expectedBranch": "exact-task-branch",
-  "receipt": {
-    "operationId": "actual-operation-id",
-    "revision": 12,
-    "status": "success",
-    "destinationThreadId": "actual-destination-thread-uuid",
-    "destinationHostId": "local",
-    "destinationCwd": "/absolute/destination-checkout",
-    "threadTitle": "exact-current-bound-title"
-  },
-  "observation": { "thread": {
-    "id": "actual-destination-thread-uuid",
-    "hostId": "local",
-    "kind": "codex",
-    "cwd": "/absolute/destination-checkout",
-    "title": "exact-current-bound-title"
-  } }
-}
-```
-
-Copy the complete successful `get_handoff_status` receipt, including any extra returned fields,
-and obtain a fresh destination `read_thread`. Preserve the source `handoff_thread` tool call:
-its source ID is supplied separately because the result need not contain it. Pending, failed,
-cancelled or inconsistent results cannot change the registry. The destination must match the
-bound title, actual Git repository and current Task branch, and cannot belong to another entry.
-
-This route changes only the existing reservation's current thread/host and, for tracked dispatch,
-current execution context. An append-only `handoffHistory` retains the receipt, source and prior
-dispatch snapshot; the original creation marker is never fabricated for legacy entries. Existing
-observations and selection history are preserved. A tracked supervisor's old cursor is cleared
-so it must observe the destination again. No create permit, grant, Task claim or lifecycle
-transition is issued. Ordinary `dispatch-observe` still rejects an unexplained checkout change.
-An exact retry of the latest handoff leaves registry bytes unchanged; changed receipts or replay
-of a superseded handoff are rejected. Refresh Core status/next and writer authority after handoff.
+## One reservation, one creation attempt
 
-These caller-supplied App results are coherence evidence, not cryptographic proof of origin or
-external write authority. The coordinator must obtain genuine tool results and independently
-check retained history and the safe writer boundary. The package does not execute a handoff,
-verify arbitrary transcript continuity, or authorize writes merely because reconciliation passes.
-Only destinations readable on the checking host with the same Git common directory are supported.
+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.
+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.
+   Resume with `dispatch-status`; after lost/ambiguous results never repeat creation.
+5. Resolve candidates with genuine App/source evidence. `dispatch-discover` accepts a bounded
+   `sessionFiles` list, not a transcript/vault search. Confirm with `read_thread`, then
+   `dispatch-observe`. Missing listings are not negative proof. Multiple candidates require
+   explicit duplicate disposition with actual readback/archive receipts before binding.
+6. Use registry `readback`, its returned rename/fallback, fresh observation and `bind` to verify
+   exact title, actual thread ID, host and execution context. Never truncate entity IDs or bind
+   another child over an existing one. Unresolved evidence stops dispatch, not all diagnosis.
+
+This is at most one create permit per reservation, not guaranteed exactly-once App delivery.
+Do not clear, expire or abandon an ambiguous marker to obtain another permit. Source discovery
+ignores guardian/subagent sessions; such sessions are not proof of the requested App creation.
+
+## Execution context and supervision
+
+Before a product write and after any branch/cwd change, run `dispatch-context-check` using fresh
+App observation, the actual `writeRoot` and expected Task branch. Require `matched=true`, then
+refresh Core/writer authority. A match does not grant filesystem access. Reconcile the same child
+on mismatch; do not silently write into the canonical checkout or create a replacement chat.
+
+Use worktree execution unless the user requests the saved checkout. After an explicit App handoff,
+use `dispatch-handoff-reconcile` with the successful full receipt, original source ID and fresh
+destination readback. Ordinary bind cannot replace a child; reconciliation creates no new permit
+or writer authority. Obtain genuine tool receipts; caller-supplied JSON is not independent proof.
+
+Persist one owner, Task-to-thread mapping, cursor and next action with `supervision-record`.
+Use bounded `wait_threads` with `afterCursor`; a timeout does not authorize another writer.
+On attention/completion, read the full child report, then fresh sequential Core `status` and `next`.
+If the same nonterminal Task has a permitted continuation, send it only the fresh route and changed
+bindings. Continue supervising; a finished chat does not implicitly resume its coordinator or
+prove Task completion. On restart reconcile App readback, saved cursors and Core before dispatch.
+
+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;
+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.

package/plugins/codex-workflow-gateway/references/codebase-memory-routing.md

@@ -0,0 +1,57 @@
+# Workflow codebase-memory routing
+
+Knowledge Map records approved project knowledge; `codebase-memory-mcp` indexes code structure.
+Neither an approved source nor a similarly named MCP project establishes the correct code graph.
+
+## Select the exact source
+
+| Investigation | Source authority |
+| --- | --- |
+| Installed workflow behavior | Fresh local `graph status --kind workflow --mode full` request's `sourceRoot` |
+| Workflow implementation/release | Exact requested workflow Git checkout, HEAD and dirty state |
+
+Match normalized absolute roots against `list_projects[].root_path`. Zero matches requires
+indexing that root; multiple exact matches require resolving ambiguity. Never choose by basename,
+project name or an earlier checkout. Do not index or bind product code through this gateway.
+
+Call `index_status`; use full indexing with `persistence: false` when missing or stale. Reuse a
+ready immutable installed-package index whose version/manifest match; do not reindex each chat.
+For source work, check HEAD and changes affecting the queried files, including uncommitted edits.
+Refresh stale evidence or record the exact files absent from the index as fallback evidence.
+
+For installed workflow, bind provider evidence through the local Core:
+
+1. Obtain `graph refresh-request --kind workflow --mode full` and retain it unchanged.
+2. Index/check that exact root; obtain the actual provider project key, counts and observation time.
+3. Pipe `{ "request": ..., "evidence": ... }` to `graph bind --stdin`, passing the current binding
+   revision when present. Evidence copies requestId, rootFingerprint, indexedHead, packageVersion,
+   manifestHash and mode from the verified request, with provider `codebase-memory-mcp`, actual
+   projectKey, status `ready`, nodeCount, edgeCount and observedAt. Never invent provider evidence.
+4. If request bindings changed, obtain a new request and evidence before binding.
+
+Source development uses its source index directly; it does not create consumer lifecycle state.
+
+## Search and fallback
+
+Use architecture, graph search and traces to locate symbols, then fetch selected snippets.
+Narrow broad results before considering filesystem search.
+
+Direct filesystem discovery requires a recorded reason: MCP unavailable after a bounded retry,
+index/refresh failure, stale bindings that cannot be refreshed, or an exact new/generated/ignored
+artifact absent from the graph. Record operation, source root and failure; installed use also
+records `graph fallback --kind workflow --mode full --reason ...` when permitted.
+Git status, exact package resolution and specifically named authority artifacts remain ordinary
+filesystem operations. A zero-write instruction forbids index/binding writes too: use existing
+immutable evidence and disclose the resulting freshness limitation.
+
+## Product graph: inactive
+
+Product graph indexing is not used by the active workflow. Do not request its refresh or binding.
+Absent or stale product bindings do not gate next, Plans, Knowledge approval or context refresh.
+Existing bindings remain readable through explicit diagnostic commands; they are not Knowledge authority.
+Project Knowledge Map continues to use deterministic repository file scanning and its existing approval contract.
+Keep the Plan schema field `graphUse`; use `not-applicable` for new product Plans. Existing `code-aware`
+values do not require an index or a new Knowledge approval. No product refresh owner or schedule is introduced.
+
+The installed-workflow graph indexes the exact installed package. The maintainer graph indexes the
+exact workflow development checkout. Neither is the product graph or a replacement for Knowledge Map.