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

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.13
 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.13
 ---
 
 # 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.13 гарантирует
 
 - 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.13 не гарантирует
 
 - правильность продуктовой идеи или автоматически выбранного provider Task;
 - semantic sufficiency Plan, если точные факты нельзя доказать поддерживаемым analyzer;
@@ -323,6 +323,14 @@ 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.13 устраняет следующий доказанный разрыв этого пути. 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.
+
 Docker socket `EPERM` в sandbox не является доказательством сломанного daemon. Gateway один раз
 повторяет exact health probe или Plan check с sandbox escalation без расходования remediation attempt.
 Restart Docker Desktop требует отдельного разрешения и допустим только после escalated daemon failure.
@@ -332,7 +340,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.13 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.13 путь от нового 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.13
 ---
 
-# 1. Рабочая модель beta.12.12
+# 1. Рабочая модель beta.12.13
 
 Пользователь работает в одном 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.13 как точную 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.13 должен сообщать `packageVersion=2.0.0-beta.12.13`, `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.13 в delegated режиме.
 Repository: <ABSOLUTE-REPOSITORY-ROOT>.
 Milestone ID: AUTO.
 Delegate actor: agent:milestone-coordinator.
@@ -360,6 +360,11 @@ 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.13 допускает только 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`.
+
 Для 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 +397,7 @@ Task/project DGR. `dependencyBinding` для standalone handoff равен null.
 
 # 14. Итоговый checklist пользователя
 
-- beta.12.12 exact package и новый bundled gateway установлены;
+- beta.12.13 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.13
 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.13
 ---
 
 # 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.13 | Значение |
 |---|---|
-| npm package | `codex-workflow-v2@2.0.0-beta.12.12` |
+| npm package | `codex-workflow-v2@2.0.0-beta.12.13` |
 | 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.13 capabilities:
 
 | Группа | Capabilities |
 |---|---|
@@ -468,6 +468,24 @@ 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.13 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.
+
 # 14. P04-A structural replacement boundary
 
 Command shape `task replacement-materialize` retained только для compatibility diagnostics. Любая попытка
@@ -530,7 +548,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.13
 
 | Область | Actions |
 |---|---|
@@ -556,10 +574,10 @@ Exact options берутся из fresh `next`; command help используе
 Перед 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.13 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.13 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,134 @@
-# V2 beta.12.12 Validation Report
+# V2 beta.12.13 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.13` 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
+- The first full `npm run validate` passed 346 of 348 tests. The only two failures were exact
+  transition-definition identity pins intentionally changed by the two new Knowledge fields: the
+  serialized definition SHA-256 and the binding-manifest row count. The derived serialized digest,
+  runtime fingerprint, runtime catalog hash, and row count were recorded from the actual compiled
+  model; the focused authority suite then passed `4/4`.
+- The mandatory clean rerun of `npm run validate` passed typecheck and `348/348` sequential tests
+  with no failures, skips, cancellations, or todos in 2,131,076.63 ms.
+- The full suite includes a beta.12.13 Signal-shaped E2E: repeated selector-contract failures,
+  beta.12.12-like dependency recovery, a second package-only update, carried exact compatibility,
+  corrective replan against the active Knowledge Map, fresh authorization/C1, selector-bearing
+  validation, a Core Step commit, and strict Step review. It also proves that changed dirty bytes
+  make the carry preflight fail closed.
+- `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`.
+  Together they independently cover audited upstream remediation through a later Step, the
+  Signal-shaped accidental-rebind/replan path, bounded dependency recovery, and retained reviewed
+  Step provenance.
+- Package dry-run produced `codex-workflow-v2-2.0.0-beta.12.13.tgz` with 281 files (approximately
+  1.1 MB packed and 4.3 MB unpacked). The first invocation encountered the known 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.
+- `npm run plugin:check` passed for bundled gateway `0.1.0+codex.20260830183000`.
+- `npm run docs:pdf:check` reported an empty stale set and exact beta.12.13 package binding.
+- `RELEASE_TAG=v2.0.0-beta.12.13 npm run release:check` and `git diff --check` passed.
 
 ## 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.
+Signal Task `TASK-01M1B79C660YMNSRRZ236NTR1T` retained its three allowlisted Worker files and reached
+a legitimate `corrective-replan-prepare` route after beta.12.12 recovery. Preparation still failed:
+the Task source Plan remained bound to the older Project Knowledge Map, while the only admissible
+replacement Plan correctly bound the newer active map created by the package-only Knowledge refresh.
+The public corrective-replan path required those two bindings to be identical, so no candidate could
+satisfy both constraints.
 
-Two Workflow gaps made the state non-recoverable:
+A further release update exposed two related continuity gaps:
 
-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.
+1. Plan-integrity dependency recovery could derive compatibility only from a currently detectable
+   invalid-check assessment. After the first recovery and `replan-required` decision, a second
+   package-only update could no longer reconstruct the already registered exact compatibility.
+2. A completed corrective-yield journal required the whole current handoff sidecar to equal the
+   yield-owned bytes forever. A later valid append-only handoff therefore made historical readback
+   fail even though the original yielded entry was intact.
 
-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.
+The defect was not insufficient Worker effort, an invalid product implementation, or a need to
+increase attempts. It was an over-constrained source/target Knowledge identity plus incomplete
+append-only continuity across consecutive Workflow updates.
 
 ## 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`.
+- Corrective-replan credentials now bind two distinct pairs. `knowledgeRevision`/`knowledgeHash`
+  identify the unchanged source Task/Plan state under the Core lock;
+  `targetKnowledgeRevision`/`targetKnowledgeHash` identify the active Project Knowledge Map that the
+  candidate Plan, new Plan Risk Audit, and materialized Task state must bind.
+- Source and target Knowledge may differ only when the Task contains one exact current
+  Plan-integrity dependency-provenance recovery. It must match the current HEAD and package version,
+  a Workflow-owned system commit, current Plan and failed Step, the complete remediation-event list,
+  exact dirty paths, and a freshly recomputed dirty-worktree hash. Otherwise preparation remains
+  fail closed.
+- A consecutive package-only update may carry compatibility from exactly one prior registered
+  recovery on `HEAD^`. Carry is admitted only when the current Task still has the same Plan, failed
+  Step, full remediation history, dirty paths and bytes, one `replan-required` decision, and no C1
+  posture. It cannot infer compatibility from prose or widen the product boundary.
+- The corrective-replan private credential schema and binding manifest contain 30 exact fields.
+  Their serialized definition digest, runtime semantic fingerprint, and runtime catalog hash are
+  pinned by the authority-model suite.
+- A completed corrective-yield journal now proves that its owned handoff bytes remain an exact prefix
+  of the current canonical append-only history and validates the entire current JSONL chain. Pending
+  and in-flight phases retain exact-byte equality. Truncation, prefix mutation, or malformed appended
+  history still fails closed.
+- Protocol and state schema remain `2/2`; no lifecycle-state migration is required.
 
 ## 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.
+The new synthetic E2E reproduces the live boundary instead of testing a helper in isolation:
+
+- an active failed guarded Step with repeated selector-contract failures and three allowlisted dirty
+  product files;
+- an existing beta.12.12 Plan-integrity recovery and `replan-required` decision;
+- a subsequent exact package-only beta.12.13 update while the Task source Knowledge remains older
+  than the active Project Knowledge Map;
+- reconstruction of exact compatibility from `HEAD^` without modifying product bytes;
+- corrective replan whose source binding remains old and whose candidate target binding is current;
+- new execution authorization and C1 cycle;
+- the selector-bearing `validate:affected -- --files=...` check;
+- successful Step completion through a Workflow-owned Core commit and strict Step review.
+
+Negative coverage rejects changed dirty bytes, wider dirty scope, the wrong parent/system commit,
+stale Plan or Step, incomplete remediation history, a non-`replan-required` decision, active C1,
+unregistered Knowledge drift, truncated historical handoff bytes, mutated historical bytes, and
+malformed appended handoff history.
+
+Live Signal mutation remains post-publication work. Installation must preserve the three current
+Worker files, transport only package/lock through the advertised update compatibility route, use a
+fresh repository-local handshake/status/next before each mutation, and follow only Core-advertised
+actions. No manual Workflow-state edit, history rewrite, Task cancellation, duplicate Task, or
+replacement Milestone is authorized by this release.
 
 ## 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.
+- All three tracked Russian PDFs were regenerated from beta.12.13 Markdown sources.
+- Architecture remains 9 pages, the delegated chat-only guide 10 pages, and the technical reference
+  13 pages. All 32 pages were rendered and visually inspected; changed source/target Knowledge,
+  consecutive-update, and append-only yield sections were additionally checked at full resolution.
+- Titles, version bindings, Cyrillic text, tables, code blocks, margins and footers 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.
+- Compatibility is exact recovery authority, not general permission to rebind Knowledge, edit a
+  Plan, change product files, alter Milestone topology, adopt unrelated commits, or skip review.
+- The carry route supports a consecutive package-only update only when the previous recovery record
+  remains fully reproducible from current Git, Task and worktree evidence.
+- Historical corrective-yield readback accepts append-only continuation, not arbitrary sidecar drift.
+- The release does not make failing product logic pass, approve a broken check, increase retry limits,
+  or infer an executable selector. The replacement Plan must supply the exact selector-bearing command.
 - 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.
+Confidence is high for source/target Knowledge separation, consecutive-update compatibility,
+append-only yield continuity, Core authority closure, transaction recovery, package composition,
+downstream installation, gateway validation and documentation. Live Signal confidence remains
+conditional on exact publication, installation, fresh Core readback, and completion of the blocked
+Step through the advertised route.

package/package.json

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