codex-workflow-v2 2.0.0-beta.13 → 2.0.0-beta.13.10

package/docs/updating-existing-project.md

@@ -22,23 +22,45 @@ state schema. Совпадение `stateSchemaVersion` до и после об
 нужна. Для alpha.6 при `stateSchemaVersion: 2` применяется не migration, а sidecar-only
 adoption posture.
 
+### beta.13.1: legacy PRA compatibility after beta.13
+
+`2.0.0-beta.13.1` preserves the beta.13 protocol/schema `2/2` and adds no state migration. The
+structural production-edge rule is prospective: every newly written ordinary or atomic
+corrective-replan PRA receives the hash-chained `structuralProductionEdgeAuthority=required-v1`
+marker, and its current Plan must satisfy the edge contract. A markerless PRA and Task written
+before that authority existed remain readable; Workflow must not reinterpret their historical
+`runtime-composition` classification as proof that their old Plan contained beta.13 fields.
+Historical PRA events from an earlier Plan are hash/shape validated but are not compared with the
+current Plan's edges. This compatibility rule never edits, migrates or silently approves external
+state. A later Plan/PRA recorded by beta.13.1 must satisfy the full structural boundary.
+
+This does not add signed provenance to local Workflow state. A full privileged rewrite of Task
+state and its complete self-hashed sidecar chain remains outside the trust model; repository rules
+continue to prohibit manual state edits. The regression proves compatibility and fail-closed
+partial mismatch, not authenticity against the machine owner.
+
+The normal safe-update sequence below targets exact `2.0.0-beta.13.1`. It is also the supported
+patch path from beta.13 when `status` or `next` reports `STATE_CORRUPT` solely because a markerless
+pre-beta.13 PRA lacks production-edge fields: run the old-version read-only preflight first, install
+the patch dependency-only, and resume from a fresh handshake. Never edit the PRA sidecar manually.
+
 ### beta.13: coherent continuation and host-safe credentials
 
-`2.0.0-beta.13` сохраняет `protocolVersion: 2` и `stateSchemaVersion: 2`; отдельная state migration
+`2.0.0-beta.13.1` сохраняет `protocolVersion: 2` и `stateSchemaVersion: 2`; отдельная state migration
 для перехода с beta.12.19 не нужна. Обновление выполняется только на безопасной границе обычного
 `update preflight`: нет running Step, active/stale writer lease, незавершённой transaction/Core
 operation и неучтённых dirty product bytes. Если хотя бы одно условие не выполнено, сначала
-завершите advertised recovery текущей repository-local версией; установка beta.13 сама по себе не
+завершите advertised recovery текущей repository-local версией; установка beta.13.1 сама по себе не
 является recovery-route и не разрешает переносить или редактировать внешний state.
 
 Точный путь обновления:
 
 1. Старой repository-local версией зафиксируйте `handshake`, `status`, `next` и read-only
    `update preflight`; продолжайте только при `safe=true`.
-2. Установите exact `codex-workflow-v2@2.0.0-beta.13` без диапазона и измените только
+2. Установите exact `codex-workflow-v2@2.0.0-beta.13.1` без диапазона и измените только
    `package.json` и lock-файл.
 3. Новой repository-local версией подтвердите совпадение declared, locked и installed
-   `2.0.0-beta.13`, прежний `projectId`, protocol/schema `2/2`, затем выполните `handshake`,
+   `2.0.0-beta.13.1`, прежний `projectId`, protocol/schema `2/2`, затем выполните `handshake`,
    `doctor`, компактный `status` и `next`.
 4. Обновите персональный `codex-workflow-gateway` только штатным installer из установленного
    exact пакета и продолжайте работу в новом чате, который загрузит новую skill-инструкцию.
@@ -614,8 +636,16 @@ title в registry readback и применяйте только возвращё
 быть уникален и содержать exact `#NNN`, membership ordinal и ID. Input должен состоять из
 TaskContextPacket; допустима только добавленная Codex App служебная `codex_delegation`-обёртка с
 `source_thread_id`, но не parent turns или transcript. Если title отсутствует или нормализован
-неверно, переименуйте и перепроверьте. Ошибка `create_thread` допускает один
-последовательный retry после проверки списка, но не разрешает fallback на `fork_thread`.
+неверно, переименуйте и перепроверьте. Pending `clientThreadId`, тайм-аут или отсутствие в
+`list_threads` не доказывают, что создание не состоялось, и не разрешают повторный `create_thread`.
+До первого вызова сохраните `dispatch-begin`; после него используйте `dispatch-result/status`,
+поиск коррелированного сеанса и `dispatch-observe` с фактическим `read_thread`. На одну
+резервацию выдаётся только одно разрешение создания. Не обходите его новой резервацией или fork.
+Полный контракт восстановления, сохранения supervisor/cursor и явного выбора `model`/`thinking`
+по роли, фазе и сложности находится в
+`plugins/codex-workflow-gateway/references/chat-dispatch.md`. Выбор модели требует соответствующего
+поручения пользователя и актуального списка поддерживаемых пар на целевом host; нельзя молча
+наследовать дорогую конфигурацию координатора или снижать уровень независимого аудита.
 Создавайте или переиспользуйте Task-чат непосредственно перед dispatch этой Task, а не как пустой
 placeholder для всего membership; `T<NN>` берите только из утверждённого membership order.
 

package/docs/validation-report.md

@@ -1,13 +1,34 @@
-# V2 beta.13 Validation Report
+# V2 beta.13.1 Validation Report
 
-Release candidate `2.0.0-beta.13` was validated during 2026-09-02--03 (Europe/Moscow) with
+Release candidate `2.0.0-beta.13.1` was validated during 2026-09-02--03 (Europe/Moscow) with
 Node.js 24.17.0.
 
+## beta.13.1 post-publication compatibility correction
+
+After published beta.13 was installed dependency-only into the clean Signal `main` checkout,
+declared, locked and installed versions and registry integrity matched, but the first compact
+`status` failed before navigation. The loader had applied the new structural production-edge rule
+to the first markerless beta.12.19 PRA for `TASK-01M1B79C660YMNSRRZ236NTR1T`; that historical Task
+contains neither `requiresProductionEdges` nor `productionEdges`. This was a runtime compatibility
+defect, not corrupt Signal state.
+
+beta.13.1 makes the authority prospective and Plan-bound. New ordinary and atomic
+corrective-replan PRA writers persist one hash-chained marker. Stored structural validation runs only
+for the current Plan when either that marker or the new Task fields establish the boundary.
+Markerless pre-authority events remain hash/shape validated and readable, while marker-bearing
+current events still fail closed if Task structural fields are removed. A source-built read-only
+probe against the untouched real Signal external state changed the exact failing observation into
+the expected `project-memory reconcile` route with the retained-historical frozen-M3 cancellation
+option. The focused production-edge and corrective-replan executor suites passed `14/14` before
+the full release gate. The compatibility gate does not claim signed provenance against a privileged
+rewrite of the entire local Task and self-hashed chain; it proves ordinary read compatibility and
+fail-closed partial mismatch within the existing trusted-local-state model.
+
 ## Automated release evidence
 
 - A clean `npm ci` completed from the exact lockfile. A network-enabled `npm audit --json` reported
   zero vulnerabilities at every severity across all eight installed dependencies.
-- `npm run validate` passed typecheck and `408/408` sequential tests with no failures, skips,
+- `npm run validate` passed typecheck and `409/409` sequential tests with no failures, skips,
   cancellations or todos in 2,761,796.900458 ms.
 - `npm run test:signal-t10-check-support-e2e` passed `8/8` after the final clean install in
   203,155.332125 ms. It covers an impossible selector-less check, machine-derived support scope,
@@ -20,7 +41,7 @@ Node.js 24.17.0.
   recovers an accidental rebind, replans and completes the consolidated guarded Step.
 - `npm run test:signal-t04-recovery` passed `11/11` in 22,021.439625 ms. It preserves only exact
   reviewed Step provenance and rejects pending, corrupt, unrelated or stale recovery evidence.
-- `npm run pack:check` produced the exact `2.0.0-beta.13` tarball with 309 files, package size
+- `npm run pack:check` produced the exact `2.0.0-beta.13.1` tarball with 309 files, package size
   1.2 MB and unpacked size 4.8 MB. It includes the shared gateway-handshake module and the
   hash-verifiable reviewer runtime build manifest.
 - `npm run smoke:downstream` packed the release, installed it into an empty project and returned
@@ -28,7 +49,7 @@ Node.js 24.17.0.
   network-enabled invocation passed.
 - `npm run plugin:check`, `npm run docs:pdf:check`, `npm run typecheck` and `git diff --check` all
   passed. The PDF checker reported no stale generated document. `npm run release:check` passed
-  `103/103` tests in 300,945.515375 ms and returned the exact package/version assertion.
+  `104/104` tests in 298,521.790541 ms and returned the exact package/version assertion.
 
 ## Release-candidate regressions found and closed
 
@@ -92,8 +113,8 @@ stale nearer-copy regressions expanded the complete suite.
 A real native reviewer preflight then exposed an API-level Structured Output incompatibility: every
 declared object property must also be present in `required`. The reviewer schema now makes nullable
 optional semantics explicit, while the semantic parser still rejects absent or contradictory
-cause/plan-conflict evidence. The complete suite consequently reached `408/408`, and the expanded
-release check reached `103/103`.
+cause/plan-conflict evidence. The complete suite consequently reached `409/409`, and the expanded
+release check reached `104/104`.
 
 The same real-agent exercise corrected the release proof boundary without weakening Core. A nested
 `codex exec` reviewer is not treated as independent production evidence: the Coordinator stops at a
@@ -154,8 +175,8 @@ mutation. This changes release-evidence interpretation only; it grants no lifecy
 - This report does not claim commit/tag/push, npm publication, installation into Signal or Milestone
   4 readiness until those operations receive exact readback.
 
-Confidence is high for package behavior and the stated compatibility boundary: the final `408/408`
-run, `103/103` release check, four Signal-shaped E2E suites, package/downstream smoke, CPU-saturation,
+Confidence is high for package behavior and the stated compatibility boundary: the final `409/409`
+run, `104/104` release check, four Signal-shaped E2E suites, package/downstream smoke, CPU-saturation,
 warm-cache and fail-closed negative cases agree. Live Signal readiness remains conditional on
 publication, exact repository-local installation, safe
 closure of the frozen Milestone 3 authority and a fresh read-only `status`/`next` observation.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-workflow-v2",
-  "version": "2.0.0-beta.13",
+  "version": "2.0.0-beta.13.10",
   "description": "Requirements-first Codex development workflow with local state and explicit Git ownership.",
   "repository": {
     "type": "git",
@@ -68,6 +68,7 @@
   },
   "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/references/chat-dispatch.md

@@ -0,0 +1,204 @@
+# Durable App dispatch and explicit model selection
+
+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.
+
+## 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.
+
+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
+
+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.
+
+## Execution context before product writes
+
+`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.
+
+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.

package/plugins/codex-workflow-gateway/references/protocol.md

@@ -56,10 +56,21 @@
   A provenance recovery recorded after the final context-refresh audit may explain exactly one
   additional Task revision only when it belongs to that verified Git chain. Any unexplained
   revision remains a `doctor` boundary.
+- Before a credential-consuming mutation, check the public `writerCredentialReference.expiresAt`
+  against the current time and its actor/action binding. Lease heartbeat or renewal does not
+  extend that reference's expiry. An expired, missing, consumed or unverifiable reference requires
+  the simultaneously advertised `next.writerCredentialRecovery` action with its exact Task,
+  revision and `requiredActor`, followed by fresh `status` and `next`; use the new reference.
+  If no recovery is advertised, stop before mutation. Never read or patch the vault, extend expiry
+  manually, or reuse the old reference. This check also applies after independent reviews and pauses.
 - `milestone progress --id <MS-ID>` is a read-only projection and the sole source for Coordinator
   progress tables. It preserves cancelled/replacement Tasks as distinct membership rows.
 - `scripts/chat-registry.mjs` atomically allocates project-monotonic `#NNN`, builds all six title
   families, verifies exact readback, supplies deterministic fallbacks, and binds the verified chat.
+  It also journals a single creation permit, pending/actual IDs, evidence-based resolution and
+  supervision cursors. Missing App listings never permit a retry. See `chat-dispatch.md` for
+  dispatch commands and the explicit role/phase model + thinking policy. These are App routing
+  helpers; they do not change Workflow protocol/state schema or grant approval authority.
 
 ## Handshake