codex-workflow-v2 2.0.0-beta.12.12 → 2.0.0-beta.12.14

package/docs/pdf/sources/codex-workflow-v2-architecture-ru.md

@@ -1,10 +1,10 @@
 ---
-title: Codex Workflow V2: архитектура beta.12.12
+title: Codex Workflow V2: архитектура beta.12.14
 subtitle: Источники истины, lifecycle, роли, delegation, зависимости Tasks и границы доверия
 part: Часть 1 из 3 | Архитектура
 document_version: 2.0
 date: 31 августа 2026
-subject: Архитектура и границы Codex Workflow V2 beta.12.12
+subject: Архитектура и границы Codex Workflow V2 beta.12.14
 ---
 
 # 1. Назначение и граница системы
@@ -18,7 +18,7 @@ Codex Workflow V2 - локальный state machine поверх Codex App, Git
 Система рассчитана на одного пользователя и одну машину. Она не предоставляет distributed locking,
 криптографическую идентификацию actor string или безопасную синхронизацию state между компьютерами.
 
-## 1.1. Что beta.12.12 гарантирует
+## 1.1. Что beta.12.14 гарантирует
 
 - exact project-local npm package и совместимый handshake до lifecycle действий;
 - Discovery до materialization Task или Milestone;
@@ -41,7 +41,7 @@ Codex Workflow V2 - локальный state machine поверх Codex App, Git
   один additive remediation Task без нового Human gate; Core сохраняет Milestone semantics и выводит
   authority из текущей Milestone authorization и exact audit evidence.
 
-## 1.2. Что beta.12.12 не гарантирует
+## 1.2. Что beta.12.14 не гарантирует
 
 - правильность продуктовой идеи или автоматически выбранного provider Task;
 - semantic sufficiency Plan, если точные факты нельзя доказать поддерживаемым analyzer;
@@ -323,6 +323,17 @@ manifest/runner hashes, HEAD и dirty allowlist. Exact beta.12.11 update bridge
 Результат — один `replan-required` decision и обычный corrective replan с исполняемой check command;
 повтор старой команды, ручной commit product files и state editing не допускаются.
 
+beta.12.14 устраняет следующий доказанный разрыв этого пути. Corrective-replan credential раздельно
+связывает исходную Knowledge revision/hash Task и целевую active Knowledge revision/hash replacement
+Plan. Различие разрешено только при exact Plan-integrity dependency recovery: текущий system commit,
+package version, failed Step, Plan, полная remediation history, dirty file set и их bytes должны
+совпасть. Следующее dependency-only обновление после corrective yield может перенести ту же compatibility
+на новый HEAD только при точном parent commit и неизменном worktree. Completed corrective-yield journal
+остаётся историческим prefix-доказательством и не блокирует последующие append-only handoff events.
+Completed corrective-replan journal также остаётся читаемым после эволюции binding manifest, но только
+если его завершённый manifest/runtime/catalog tuple есть в append-only historical registry. Pending и
+неизвестные identity по-прежнему fail-closed, поэтому compatibility не выдаёт новую authority.
+
 Docker socket `EPERM` в sandbox не является доказательством сломанного daemon. Gateway один раз
 повторяет exact health probe или Plan check с sandbox escalation без расходования remediation attempt.
 Restart Docker Desktop требует отдельного разрешения и допустим только после escalated daemon failure.
@@ -332,7 +343,7 @@ Restart Docker Desktop требует отдельного разрешения
 # 10. Operational checklist
 
 - exact package version установлен, bundled gateway соответствует release и переустановлен;
-- handshake подтверждает protocol 2, state schema 2 и beta.12.12 capabilities;
+- handshake подтверждает protocol 2, state schema 2 и beta.12.14 capabilities;
 - каждый mutation следует свежему `status -> next` и exact option contract;
 - Docker permission failure сначала классифицируется как sandbox boundary, а не как infra retry;
 - semantic unknowns и human gates не маскируются delegation;

package/docs/pdf/sources/codex-workflow-v2-chat-only-guide-ru.md

@@ -1,13 +1,13 @@
 ---
 title: Codex Workflow V2: delegated chat-only guide
-subtitle: Актуальный beta.12.12 путь от нового Discovery до принятого Milestone без ручного CLI
+subtitle: Актуальный beta.12.14 путь от нового Discovery до принятого Milestone без ручного CLI
 part: Часть 2 из 3 | Практика
 document_version: 2.0
 date: 31 августа 2026
-subject: Практическое руководство по delegated Discovery и Milestone в Workflow V2 beta.12.12
+subject: Практическое руководство по delegated Discovery и Milestone в Workflow V2 beta.12.14
 ---
 
-# 1. Рабочая модель beta.12.12
+# 1. Рабочая модель beta.12.14
 
 Пользователь работает в одном Codex Project и формулирует продуктовый outcome. Coordinator выполняет
 CLI, создаёт отдельные Task/Reviewer chats и ведёт supervision loop. Workflow Core остаётся authority
@@ -40,7 +40,7 @@ Blocking unknown, scope change, grant issuance или unrecoverable integrity co
 # 2. Подготовка проекта перед новым Discovery
 
 1. Убедитесь, что checkout чистый и выбран правильный repository root.
-2. Установите beta.12.12 как точную devDependency после публикации release.
+2. Установите beta.12.14 как точную devDependency после публикации release.
 3. Обновите и переустановите bundled `codex-workflow-gateway` этого release.
 4. Проверьте, что declared и installed package versions равны.
 5. Запустите новый Coordinator chat, не fork старого Milestone conversation.
@@ -56,7 +56,7 @@ AGENTS.md
 -> doctor только как дополнительная диагностика
 ```
 
-Handshake beta.12.12 должен сообщать `packageVersion=2.0.0-beta.12.12`, `protocolVersion=2`,
+Handshake beta.12.14 должен сообщать `packageVersion=2.0.0-beta.12.14`, `protocolVersion=2`,
 `stateSchemaVersion=2`, dependency DAG, initial Plan transaction, mechanical feasibility,
 Milestone autonomy и structural replacement disabled capabilities.
 
@@ -117,7 +117,7 @@ delegate, scope, transitions и expiry. DGR передаётся только е
 ```text
 НОВЫЙ COORDINATOR CHAT
 
-Проведи новый Milestone через Codex Workflow V2 beta.12.12 в delegated режиме.
+Проведи новый Milestone через Codex Workflow V2 beta.12.14 в delegated режиме.
 Repository: <ABSOLUTE-REPOSITORY-ROOT>.
 Milestone ID: AUTO.
 Delegate actor: agent:milestone-coordinator.
@@ -360,6 +360,15 @@ Knowledge refresh. Затем выполните advertised credential recovery,
 `task corrective-yield`. Replacement Plan меняет только неисполняемую check на
 `npm run validate:affected -- --files=<Step allowedWrites>` и проходит fresh Plan Risk Audit до нового run.
 
+Если update произошёл уже после `task corrective-yield`, beta.12.14 допускает только advertised
+`update plan-integrity-dependency-recover`: parent должен быть предыдущим зарегистрированным recovery
+commit, а failed Step, Plan, remediation IDs, dirty paths и dirty SHA-256 — полностью совпадать. После
+recovery снова запросите `status -> next`; ожидаемый route остаётся `task corrective-replan-prepare`.
+Если новый package сначала сообщает `TASK_TRANSACTION_INTEGRITY_FAILED` только для terminal
+corrective-replan journals предыдущего release, не repair/delete/edit state. beta.12.14 читает лишь
+точно зарегистрированные completed manifest/runtime/catalog tuples; pending либо неизвестный tuple
+остаётся блокером. После установки обязательно повторите handshake и последовательные `status -> next`.
+
 Для exact beta.12.6 stranded-replan shape сначала нужен eligible read-only source preflight с exact
 revision/HEAD/dirty hash. Затем два beta.12.7 dependency-only commits и advertised dependency/replan
 recoveries. После Knowledge refresh `next` обязан остаться на `task plan-set`; новый единый Step должен
@@ -392,7 +401,7 @@ Task/project DGR. `dependencyBinding` для standalone handoff равен null.
 
 # 14. Итоговый checklist пользователя
 
-- beta.12.12 exact package и новый bundled gateway установлены;
+- beta.12.14 exact package и новый bundled gateway установлены;
 - новый Coordinator chat не является fork старого Milestone;
 - bootstrap DGR, если нужен, выдан отдельным exact human confirmation;
 - Discovery не materialized при blocking unknowns;

package/docs/pdf/sources/codex-workflow-v2-technical-reference-ru.md

@@ -1,10 +1,10 @@
 ---
-title: Codex Workflow V2: технический справочник beta.12.12
+title: Codex Workflow V2: технический справочник beta.12.14
 subtitle: Protocol 2, state schema 2, transactions, credentials, dependency authority, review и recovery
 part: Часть 3 из 3 | Technical reference
 document_version: 2.0
 date: 31 августа 2026
-subject: Технический контракт Codex Workflow V2 beta.12.12
+subject: Технический контракт Codex Workflow V2 beta.12.14
 ---
 
 # 1. Runtime contract
@@ -13,9 +13,9 @@ Workflow V2 предоставляет локальные revisioned transitions
 и `value` либо структурированную ошибку с `code`, `message` и `details`. Chat, PDF и gateway не создают
 authority сами: mutating permission определяется runtime state и свежим `next`.
 
-| Параметр beta.12.12 | Значение |
+| Параметр beta.12.14 | Значение |
 |---|---|
-| npm package | `codex-workflow-v2@2.0.0-beta.12.12` |
+| npm package | `codex-workflow-v2@2.0.0-beta.12.14` |
 | protocolVersion | 2 |
 | stateSchemaVersion | 2 |
 | lifecycle epoch | 2 |
@@ -37,7 +37,7 @@ Gateway выполняет:
 5. вызов только package-local `dist/src/cli.js --repo <root>`;
 6. `gateway handshake` до lifecycle действий.
 
-Ключевые beta.12.12 capabilities:
+Ключевые beta.12.14 capabilities:
 
 | Группа | Capabilities |
 |---|---|
@@ -468,6 +468,31 @@ corrective-derived reconcile/approval; прочий drift fail-closed. Product b
 переносятся. Fresh route продолжается через credential replacement, `plan-integrity-recover`, yield и
 corrective replan с selector-bearing check.
 
+# 13.6. beta.12.14 source/target Knowledge binding
+
+Corrective-replan receipt теперь включает две разные пары. `knowledgeRevision/knowledgeHash` связывает
+исходное состояние Task; `targetKnowledgeRevision/targetKnowledgeHash` связывает active Project
+Knowledge Map и replacement Plan. Executor проверяет source под Task lock, candidate Plan — по target,
+а Risk Audit и materialized Task получают target binding.
+
+Source и target могут различаться только при exact `dependencyProvenanceRecoveries.planIntegrity` для
+текущего HEAD и package version. Record обязан совпасть по Plan, failed Step, всей remediation event ID
+последовательности, dirty paths и повторно вычисленному dirty SHA-256. Для последовательного package
+update после corrective yield Core переносит compatibility лишь с зарегистрированного `HEAD^`; любое
+изменение product bytes, Step status, Plan, decision или C1 posture отключает route.
+
+Completed corrective-yield transaction проверяет неизменный canonical yield event как prefix текущей
+append-only handoff history. Это сохраняет tamper detection, но разрешает новый handoff после успешного
+corrective replan. E2E release gate проходит prepare/confirm/execute, authorization, handoff/claim,
+selector-bearing Step completion commit и strict Step review.
+
+Completed corrective-replan transaction сохраняет authority identity своего release. Текущий manifest
+обязателен для любой pending/in-flight transaction; completed journal может использовать только exact
+tuple из append-only registry: manifest SHA-256, runtime fingerprint и catalog hash. Неизвестный tuple,
+legacy tuple у незавершённой transaction, повреждённый intent/phase chain или owned target остаётся
+`journal-invalid`. Это позволяет читать terminal beta.12.12 history после расширения binding manifest,
+не превращая legacy identity в новую execution authority.
+
 # 14. P04-A structural replacement boundary
 
 Command shape `task replacement-materialize` retained только для compatibility diagnostics. Любая попытка
@@ -530,7 +555,7 @@ Docker socket/CLI `EPERM`, `operation not permitted` или `permission denied`
 После каждой successful mutation обязателен sequential `status`, затем fresh `next`. Failed status/next
 не разрешает direct mutation. Syntax help read-only и не заменяет navigation authority.
 
-# 18. Public command surface beta.12.12
+# 18. Public command surface beta.12.14
 
 | Область | Actions |
 |---|---|
@@ -551,15 +576,17 @@ Docker socket/CLI `EPERM`, `operation not permitted` или `permission denied`
 Exact options берутся из fresh `next`; command help используется только когда
 `exactOptionContractAvailable=false` или syntax действительно неизвестен.
 
+<!-- pagebreak -->
+
 # 19. Release и package update gates
 
 Перед package update project-local `update preflight` должен вернуть `safe=true`: clean checkout, нет
 running Step и active/stale writer lease. Исключения — документированный alpha.7 rescue, beta.12.6
 active-downstream-proof bridge, beta.12.7 exact stranded-replan bridge, beta.12.9 historical-Step
-dependency bridge и beta.12.12 Plan-integrity bridge; все они fail-closed и не дают общего разрешения
+dependency bridge и beta.12.14 Plan-integrity bridge; все они fail-closed и не дают общего разрешения
 dirty update.
 
-Перед beta.12.12 tag обязательны `npm ci`, `npm run validate`, `npm run test:signal-remediation-e2e`, `npm run pack:check`,
+Перед beta.12.14 tag обязательны `npm ci`, `npm run validate`, `npm run test:signal-remediation-e2e`, `npm run pack:check`,
 `npm run smoke:downstream`, `npm run plugin:check`, official plugin/skill validators,
 `npm run docs:pdf:check`, `npm run release:check` с exact tag binding и validation
 append-only real-agent lifecycle log.

package/docs/validation-report.md

@@ -1,134 +1,112 @@
-# V2 beta.12.12 Validation Report
+# V2 beta.12.14 Validation Report
 
-Release candidate `2.0.0-beta.12.12` was validated on 2026-08-31 (Europe/Moscow) with
+Release candidate `2.0.0-beta.12.14` was validated on 2026-08-31 (Europe/Moscow) with
 Node.js 24.17.0.
 
 ## Automated release evidence
 
-- `npm ci` completed from the exact lockfile; the audit reported zero vulnerabilities.
-- The first full `npm run validate` run found two compatibility regressions in the pre-existing
-  corrective-recovery suite. Plan-integrity preflight was made non-authoritative while a repairable
-  legacy remediation-history defect exists, and an old test was aligned with the intentional
-  corrective-yield-before-context-refresh priority. Both focused reproductions then passed.
-- The mandatory second `npm run validate` passed typecheck and `348/348` sequential tests with no
-  failures, skips, cancellations, or todos in 2,149,397.21 ms.
-- The full suite includes the beta.12.12 selector-contract E2E: four sequential failures of one
-  guarded Step, dependency-only update transport, exact compatibility registration, automatic
-  package-only Knowledge refresh, Plan-integrity recovery, corrective yield, and fresh corrective
-  replan without losing the Step worktree.
-- `npm run test:signal-remediation-e2e` passed both focused scenarios (`2/2`). It still proves the
-  audited upstream-remediation route through a later Step and rejects unrelated Knowledge drift.
-- Package dry-run produced `codex-workflow-v2-2.0.0-beta.12.12.tgz` with 281 files, 1,070,498 bytes
-  packed and 4,283,430 bytes unpacked. The tarball SHA-1 is
-  `349bcd371b09a2467496057166c78d879e99e937`. The first invocation encountered a root-owned user npm
-  cache (`EPERM`); the exact retry passed with an isolated temporary cache and no system permission
-  changes.
-- `npm run smoke:downstream` built and installed that tarball in a disposable consumer project and
-  returned `ok=true`. The sandboxed attempt could not resolve npm (`ENOTFOUND`); the same command
-  passed with approved network access.
-- `npm run plugin:check` passed for bundled gateway `0.1.0+codex.20260830183000`. The installed
-  Codex CLI exposes no `plugin validate` subcommand, so the repository validator plus successful
-  packaged downstream installation are the available plugin release evidence.
-- `npm run docs:pdf:check` reported an empty stale set and exact beta.12.12 package binding.
-- `RELEASE_TAG=v2.0.0-beta.12.12 npm run release:check` and `git diff --check` passed.
-- `node scripts/validate-lifecycle-transcript.mjs --file
-  tests/fixtures/lifecycle-transcripts/valid-normal-sequence.jsonl` passed with four checked events;
-  the full validator suite also passed all positive and negative transcript fixtures.
+- A clean `npm ci` completed from the exact lockfile and reported zero vulnerabilities. The first
+  sandboxed attempt failed only on registry DNS (`ENOTFOUND`); the exact network-enabled retry passed.
+- `npm run validate` passed typecheck and `349/349` sequential tests with no failures, skips,
+  cancellations or todos in 2,224,925.03 ms.
+- The new regression case completes a corrective-replan transaction, rewrites its self-bound
+  identity and phase chain to the exact beta.12.12 historical tuple, and proves observation remains
+  clean. An unknown tuple and the same historical tuple on a pending transaction both remain
+  `journal-invalid`.
+- The full suite still includes the beta.12.13 Signal-shaped E2E: repeated selector-contract
+  failures, consecutive dependency-only updates, exact carried compatibility, source/target
+  Knowledge separation, corrective replan, fresh authorization/C1, selector-bearing validation,
+  Core Step commit and strict Step review.
+- `npm run test:signal-remediation-e2e` passed `2/2`; `npm run
+  test:signal-t03-replan-e2e` passed `1/1`; and `npm run test:signal-t04-recovery` passed `11/11`.
+- Package dry-run passed with 281 files (approximately 1.1 MB packed and 4.3 MB unpacked), and the
+  disposable downstream installation returned `ok=true` for the exact beta.12.14 tarball.
+- `npm run plugin:check`, `npm run docs:pdf:check`,
+  `RELEASE_TAG=v2.0.0-beta.12.14 npm run release:check`, and `git diff --check` all passed. PDF
+  freshness reported an empty stale set and exact beta.12.14 package binding.
+
+## Live Signal reproduction
+
+The beta.12.13 package was published and installed into Signal through one dependency-only commit
+`51e5e61b39ff9a234dcc9ccb80d81da710570f55`. Declared, locked, installed, Task-branch and `main`
+versions all became exact `2.0.0-beta.12.13`; the three uncommitted STEP-001 product files retained
+their original SHA-256 values.
+
+Fresh beta.12.13 handshake succeeded with protocol/state schema `2/2`, but read-only `status` failed
+closed with `TASK_TRANSACTION_INTEGRITY_FAILED`. It identified exactly three `journal-invalid`
+completed Task transactions:
+
+- `TASK-01M0HVJ4S7GF6JNCNDHPMAVG8Y` / `c66a4bf6b4e67c2b406cccd8229e827a96b7c99e5609d9e025b835817c45e523`;
+- `TASK-01M0HVNAWGQGSSXCDJ4DDGEZXV` / `52838ab5e81da7e471a377ff29828f0ad5326bcb20581c9ee65387e617e1446d`;
+- `TASK-01M0WXJ2GHGYRH86HR7FMKWSTS` / `d5024dc6ab5b2d85da57b6c7d44b8927e0c1558e890ee434f3911712f6faa56a`.
+
+All three were terminal corrective-replan transactions created by the prior 28-field binding model.
+Their exact common identity was manifest SHA-256
+`edab7ee7ac4018e759f5fc702a11a0fd113ef4f2cf8ed8fa823a59fde3012a1a`, runtime fingerprint
+`bd4e7a0ddfcb6abc0c5eb107775e6aea7e08c4606dda4d945d77af8a4520710d`, and catalog hash
+`fa1d11860d4f07978c3b8e85d1f91cd3d15b17284b05f41e05d462d3bb092aed`.
+
+The beta.12.14 implementation was built locally and its transaction observer was run read-only
+against the real Signal external state. It returned `pending=0`, `corrupt=0`. No state, journal,
+sidecar, Git history or product file was modified by this reproduction.
 
 ## Root cause corrected
 
-Signal Task `TASK-01M1B79C660YMNSRRZ236NTR1T` reached revision 12 with four recorded
-`checks-failed` events. The approved Step check was `npm run validate:affected`, while the existing
-repository script delegates to `tools/validation/run.mjs affected`, whose public contract requires at
-least one of `--base`, `--head`, or `--files`. The command therefore failed before validation and could
-not become successful through another implementation attempt.
-
-Two Workflow gaps made the state non-recoverable:
-
-1. mechanical feasibility proved that the npm script existed but did not verify the mandatory
-   selector contract of the repository-owned runner; and
-2. bounded Plan-integrity recovery recognized only the first failed attempt with no corrective
-   decision, so it could not convert the already accumulated four-event history into a fresh Plan.
-
-The primary defect was an invalid executable Plan contract plus an incomplete late-recovery route,
-not insufficient Worker effort and not an attempt-count problem.
-
-## Implemented lifecycle contract
-
-- Mechanical feasibility now uses the versioned analyzer `wf2.root-npm-script-arguments@1`. It
-  conservatively recognizes only a root npm script whose command is a repository-relative Node
-  `affected` runner and whose source contains the established selector contract. A Plan check without
-  `--base`, `--head`, or `--files` is blocked when the runner is outside current/predecessor
-  `allowedWrites`; an explicit forwarded selector passes. Unsupported syntax remains `unverified`.
-- Plan-integrity evidence schema v2 binds the current Task revision, Step and Plan hashes, every
-  sequential remediation event, package manifest and runner bytes, Git HEAD, dirty Step files, and a
-  canonical conflict hash. Existing v1 evidence remains readable.
-- Recovery accepts one or more contiguous `checks-failed` events only when no corrective decision has
-  consumed them. It appends one `replan-required` decision at the next ordinal and covers the complete
-  failed history; it does not synthesize an extra failure.
-- A published update from beta.12.11 is permitted only through the read-only
-  `update plan-integrity-update-preflight` proof. Transport may commit only `package.json` and
-  `package-lock.json` on the active Milestone base and carry that exact dependency commit to the Task
-  branch while preserving all product bytes.
-- Fresh `next` then advertises `update plan-integrity-dependency-recover` only when current HEAD,
-  package version, parent commit, Task/Step/Plan, remediation IDs, dirty paths and their content hash,
-  absence of leases, and transaction state still match the preflight boundary.
-- Dependency registration and a Project Knowledge refresh are one Project transaction. The refresh is
-  allowed without a Human gate only when the sole canonical drift is the exact Workflow pin in
-  `package.json`; any unrelated Knowledge change fails closed.
-- The compatibility record is authority only for the exact post-update Plan-integrity recovery. A
-  fresh replacement Plan must bind the current Knowledge Map and replace the invalid check with an
-  executable selector-bearing command. Ordinary authorization, C1, Core commit, strict review, and
-  subsequent navigation remain mandatory.
-- A repairable legacy remediation-mode defect outranks this new preflight. Plan-integrity assessment
-  reports itself ineligible and leaves `next` free to advertise the established
-  `task remediation-mode-recover` route.
-- Handshake adds `plan-integrity-update-recovery-v1`; protocol and state schema remain `2/2`.
-
-## Signal-shaped and negative evidence
-
-The new synthetic E2E reproduces the real Signal boundary rather than testing a helper in isolation:
-
-- beta.12.11 package/lock and approved Knowledge Map;
-- an active claimed guarded Step with four distinct `checks-failed` events;
-- the same missing selector contract as Signal;
-- the exact allowlisted dirty worktree;
-- a dependency-only beta.12.12 commit;
-- automatic package-only Knowledge refresh and compatibility registration;
-- writer credential replacement, Plan-integrity recovery, corrective yield, and fresh corrective
-  replan preparation.
-
-Negative coverage rejects a runner inside the current Step write scope, unrelated dirty files,
-tampered evidence, an active lease, wider dependency commits, changed worktree bytes, stale
-Task/Plan/Step bindings, transaction conflicts, and unrelated Knowledge drift. Existing tests also
-prove that Plan-integrity preflight cannot hide the older remediation-mode recovery route.
-
-Live Signal mutation remains post-publication work. It must preserve the three current Worker files,
-transport only package/lock, use fresh repository-local handshake/status/next before each mutation,
-and follow only advertised recovery actions. No manual Workflow-state edit, history rewrite, Task
-cancellation, duplicate Task, or replacement Milestone is authorized by this release.
+beta.12.13 expanded the live corrective-replan binding manifest from 28 to 30 fields so source Task
+Knowledge and target replacement-Plan Knowledge could differ under exact Plan-integrity compatibility.
+The transaction journal validator compared every stored journal with only the current manifest hash.
+Consequently, already completed and otherwise intact beta.12.12 transactions became unreadable after
+the legitimate manifest evolution.
+
+The problem was not corrupted Signal state and not a missing repair operation. It was missing
+versioned read compatibility for consumed, terminal Core transaction authority. Repairing, deleting or
+rewriting those journals would have destroyed evidence and hidden the product defect.
+
+## Implemented compatibility contract
+
+- The current binding manifest remains mandatory for every new, pending or in-flight
+  corrective-replan transaction.
+- An append-only registry records exact historical completed identities as a three-value tuple:
+  manifest SHA-256, runtime semantic fingerprint and runtime catalog hash.
+- A non-current identity is accepted only when the journal phase is `completed` and the full tuple is
+  present in that registry.
+- Existing schema validation, path identity, intent hash, phase hash chain, target inventory, owned
+  preimage/postimage digests, sidecar anchors, completion result and canonical-target readback remain
+  mandatory. Historical registration bypasses none of them.
+- Unknown tuples and historical tuples on nonterminal transactions remain fail closed. A historical
+  completed journal is read evidence only; it cannot mint a new receipt, resume execution or become
+  current transition authority.
+- Protocol and state schema remain `2/2`; no state migration or repair command is required.
+
+## Existing beta.12.13 contract retained
+
+- Corrective-replan credentials still separate source `knowledgeRevision`/`knowledgeHash` from target
+  `targetKnowledgeRevision`/`targetKnowledgeHash`.
+- Source/target difference still requires an exact current Plan-integrity recovery matching HEAD,
+  package version, system commit, Plan, failed Step, full remediation history, dirty paths and dirty
+  worktree hash.
+- Consecutive package-only updates can still carry compatibility only from one exact registered
+  recovery at `HEAD^`, with unchanged product bytes and no C1 posture.
+- Completed corrective-yield journals still require their owned event bytes to be an exact prefix of
+  a valid current append-only handoff history.
 
 ## PDF release documentation evidence
 
-- All three tracked Russian PDFs were regenerated from beta.12.12 Markdown sources.
-- Architecture is 9 pages, the delegated chat-only guide is 10 pages, and the technical reference is
-  13 pages. All 32 pages were rendered and visually inspected through contact sheets.
-- Titles, version bindings, Cyrillic text, tables, code blocks, margins, footers and selector-recovery
-  sections show no clipping, overlap, or unreadable content.
-
-## Existing boundaries and non-claims
-
-- The analyzer does not execute or infer arbitrary shell grammar and does not claim to understand
-  every repository validation framework.
-- The compatibility route cannot change product files, Plan semantics, Milestone topology, Task
-  membership, dependency edges, completed-Step provenance, or unrelated Knowledge.
-- The release does not make a failing implementation pass, approve a broken check, or increase retry
-  limits. It creates a bounded route to replace a mechanically impossible approved check.
-- Protocol version remains 2 and state schema remains 2; no state migration is required.
-- This report does not claim Git commit/tag/push, npm publication, live Signal installation, or Task
-  completion before those operations receive their own readbacks.
-
-Confidence is high for selector detection, repeated-failure recovery, update compatibility,
-transaction atomicity, regression compatibility, package composition, downstream installation,
-gateway and documentation. Live Signal confidence remains conditional on exact publication,
-installation, fresh Core readback, and completion of the previously blocked Step.
+- All three tracked Russian PDFs were regenerated from beta.12.14 sources.
+- Architecture is 9 pages, delegated chat-only guide is 10 pages, and technical reference is 14
+  pages. All 33 pages were rendered and visually inspected; the release-gate appendix has an explicit
+  page boundary, and no clipping, overlap or unreadable content was observed.
+
+## Boundaries and non-claims
+
+- The historical registry is not a wildcard, schema migration, state repair or permission to accept
+  arbitrary old bytes. Each prior identity must be added explicitly and tested.
+- The patch does not weaken pending transaction recovery, current Core authority, dirty-worktree
+  boundaries, review gates or product checks.
+- This report does not claim commit/tag/push, npm publication, live beta.12.14 installation, dependency
+  recovery or STEP-001 completion before each operation receives its own readback.
+
+Confidence is high for historical completed-journal compatibility because the focused test, full
+349-test gate and read-only real Signal state inspection agree. End-to-end confidence remains
+conditional on publication, exact Signal installation, fresh repository-local `status -> next`, and
+completion of the blocked STEP-001 through Core-advertised routes.

package/package.json

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

package/schemas/corrective-replan-credentials.private.schema.json

@@ -12,14 +12,16 @@
     },
     "bindingValues": {
       "type": "object", "additionalProperties": false,
-      "required": ["transitionId", "runtimeFingerprint", "catalogHash", "lifecycleEpoch", "taskId", "revision", "currentPlanHash", "briefHash", "knowledgeRevision", "knowledgeHash", "gitHead", "guardedStepId", "correctiveDecisionEventId", "correctiveDecisionHash", "attemptCount", "remediationTailHash", "candidatePlanHash", "candidateStepSetHash", "planAuthorIdentityHash", "planValidationHash", "planValidatorIdentityHash", "riskAuditHash", "riskAuditorIdentityHash", "actorIdentityHash", "actorRole", "humanPrincipalIdentityHash", "capabilityId", "capabilityVersion"],
+      "required": ["transitionId", "runtimeFingerprint", "catalogHash", "lifecycleEpoch", "taskId", "revision", "currentPlanHash", "briefHash", "knowledgeRevision", "knowledgeHash", "targetKnowledgeRevision", "targetKnowledgeHash", "gitHead", "guardedStepId", "correctiveDecisionEventId", "correctiveDecisionHash", "attemptCount", "remediationTailHash", "candidatePlanHash", "candidateStepSetHash", "planAuthorIdentityHash", "planValidationHash", "planValidatorIdentityHash", "riskAuditHash", "riskAuditorIdentityHash", "actorIdentityHash", "actorRole", "humanPrincipalIdentityHash", "capabilityId", "capabilityVersion"],
       "properties": {
         "transitionId": { "const": "task.plan.corrective-replan" },
         "runtimeFingerprint": { "$ref": "#/$defs/hash" }, "catalogHash": { "$ref": "#/$defs/hash" },
         "lifecycleEpoch": { "const": 2 }, "taskId": { "$ref": "#/$defs/id" },
         "revision": { "type": "integer", "minimum": 0, "maximum": 9007199254740991 }, "currentPlanHash": { "$ref": "#/$defs/hash" },
         "briefHash": { "$ref": "#/$defs/hash" }, "knowledgeRevision": { "type": "integer", "minimum": 0, "maximum": 9007199254740991 },
-        "knowledgeHash": { "$ref": "#/$defs/hash" }, "gitHead": { "type": "string", "pattern": "^(?:[a-f0-9]{40}|[a-f0-9]{64})$" },
+        "knowledgeHash": { "$ref": "#/$defs/hash" },
+        "targetKnowledgeRevision": { "type": "integer", "minimum": 0, "maximum": 9007199254740991 },
+        "targetKnowledgeHash": { "$ref": "#/$defs/hash" }, "gitHead": { "type": "string", "pattern": "^(?:[a-f0-9]{40}|[a-f0-9]{64})$" },
         "guardedStepId": { "$ref": "#/$defs/id" }, "correctiveDecisionEventId": { "$ref": "#/$defs/id" },
         "correctiveDecisionHash": { "$ref": "#/$defs/hash" }, "attemptCount": { "type": "integer", "minimum": 2, "maximum": 9007199254740991 },
         "remediationTailHash": { "$ref": "#/$defs/hash" }, "candidatePlanHash": { "$ref": "#/$defs/hash" },

package/schemas/transition-definition.schema.json

@@ -436,6 +436,8 @@
           "projection.corrective-replan.candidate@1:field.plan-validator-identity-hash",
           "projection.corrective-replan.candidate@1:field.risk-audit-hash",
           "projection.corrective-replan.candidate@1:field.risk-auditor-identity-hash",
+          "projection.corrective-replan.candidate@1:field.target-knowledge-hash",
+          "projection.corrective-replan.candidate@1:field.target-knowledge-revision",
           "projection.corrective-replan.execution-receipt@1:field.actor-identity-hash",
           "projection.corrective-replan.execution-receipt@1:field.actor-role",
           "projection.corrective-replan.execution-receipt@1:field.attempt-count",
@@ -461,6 +463,8 @@
           "projection.corrective-replan.execution-receipt@1:field.risk-audit-hash",
           "projection.corrective-replan.execution-receipt@1:field.risk-auditor-identity-hash",
           "projection.corrective-replan.execution-receipt@1:field.runtime-fingerprint",
+          "projection.corrective-replan.execution-receipt@1:field.target-knowledge-hash",
+          "projection.corrective-replan.execution-receipt@1:field.target-knowledge-revision",
           "projection.corrective-replan.execution-receipt@1:field.task-id",
           "projection.corrective-replan.execution-receipt@1:field.task-revision",
           "projection.corrective-replan.execution-receipt@1:field.transition-id",
@@ -535,6 +539,8 @@
           "projection.input.execution-receipt@1:field.risk-audit-hash",
           "projection.input.execution-receipt@1:field.risk-auditor-identity-hash",
           "projection.input.execution-receipt@1:field.runtime-fingerprint",
+          "projection.input.execution-receipt@1:field.target-knowledge-hash",
+          "projection.input.execution-receipt@1:field.target-knowledge-revision",
           "projection.input.execution-receipt@1:field.task-id",
           "projection.input.execution-receipt@1:field.task-revision",
           "projection.input.execution-receipt@1:field.transition-id",
@@ -620,6 +626,8 @@
         "field.runtime-fingerprint",
         "field.step-id",
         "field.step-status",
+        "field.target-knowledge-hash",
+        "field.target-knowledge-revision",
         "field.task-id",
         "field.task-plan-hash",
         "field.task-revision",