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

package/docs/problem-briefs/04-task-dependency-and-structural-replacement-integrity.md

@@ -1,12 +1,12 @@
 ---
 brief_id: WF2-P04
 problem: "Milestone Task execution is not guarded by explicit canonical dependencies"
-status: approved
+status: implemented
 owner: null
 created_at: 2026-08-23
 approved_at: 2026-08-24
-implemented_at: null
-revision: 5
+implemented_at: 2026-08-24
+revision: 6
 ---
 
 # Brief — P04-A Task Dependency Integrity
@@ -15,7 +15,7 @@ revision: 5
 
 The normal Task dependency gap is **confirmed**.
 
-Current Milestone membership represents:
+At the confirmed pre-P04-A baseline, Milestone membership represented:
 
 ```text
 taskId
@@ -27,11 +27,11 @@ It has no canonical Task dependency edges. `startTask` checks that the Milestone
 Task membership is required, but it does not check predecessor completion. Consequently, user or
 Coordinator intent such as “Required Tasks execute sequentially” is not enforced by Core.
 
-Current beta replacement already atomically updates Discovery, old Task, one replacement Task,
+The pre-P04-A beta replacement already atomically updated Discovery, old Task, one replacement Task,
 Milestone plan/state, Knowledge Map when eligible, and writer-lock state. It is a 1→1 operation and
 does not preserve completed Steps or rewire downstream Tasks.
 
-This brief implements **P04-A only**:
+The released implementation covers **P04-A only**:
 
 ```text
 canonical Task dependencies
@@ -44,6 +44,9 @@ It does not implement structural replacement. Until separate replacement authori
 current 1→1 route always fails closed; even an empty historical edge set cannot authorize the new
 Task boundary or topology.
 
+P04-A was released in exact `v2.0.0-beta.11` at commit `44e6734` and retained through the beta.12
+line. P04-B/P05 remains deferred and is not made implemented by this status change.
+
 Old active-M3 recovery, historical replacement IDs, and old T07/T08/T09/T10 topology are excluded
 from mandatory materialization evidence. The implementation is validated from a clean pre-Milestone
 repository and fresh Discovery.
@@ -564,3 +567,7 @@ P04-A may move from `approved` to `implemented` only when:
 - 2026-08-24 — The exact final combined P04-A/P01-A suite passed 319/319. The packaged handshake now
   advertises dependency DAG, atomic initial Plan, and structural-replacement-disabled capabilities
   instead of the unavailable legacy replacement capability. Status remains `approved`.
+- 2026-08-24 — Revision 6 records implementation acceptance. The combined P04-A/P01-A candidate
+  shipped as exact `v2.0.0-beta.11` at commit `44e6734` after the declared focused, transaction,
+  replay, and full-suite gates passed, and was retained in the beta.12 line. Status moved from
+  `approved` to `implemented`. P04-B/P05 structural replacement remains deferred.

package/docs/problem-briefs/README.md

@@ -24,10 +24,10 @@ A regression or disproven assumption should not silently move a brief backward.
 
 | # | Problem | File | Status |
 |---|---|---|---|
-| 01 | Механически невыполнимый Task Plan может получить execution authorization | `01-pre-implementation-integrity.md` | approved |
+| 01 | Механически невыполнимый Task Plan может получить execution authorization | `01-pre-implementation-integrity.md` | implemented |
 | 02 | STEP не является полезным инкрементом | `02-minimal-step-integrity.md` | hypothesis |
 | 03 | Разный контекст агентов и слишком позднее обнаружение проблем | `03-minimal-agent-context-integrity.md` | hypothesis |
-| 04 | Milestone Task execution не защищён явными зависимостями | `04-task-dependency-and-structural-replacement-integrity.md` | approved |
+| 04 | Milestone Task execution не защищён явными зависимостями | `04-task-dependency-and-structural-replacement-integrity.md` | implemented |
 | 05 | TBD | — | — |
 | 06 | TBD | — | — |
 | 07 | TBD | — | — |
@@ -85,21 +85,21 @@ This is an implementation-order recommendation, not a status change or approval
 
 | Brief | Decision | Reason and gate |
 |---|---|---|
-| P04-A | **GO to review/merge — candidate green** | Revision 5 passed its 306/306 checkpoint and the final combined P04-A/P01-A 319/319 suite on `codex/p04-task-dependencies`. Keep status `approved` until the candidate is merged/installed and accepted. |
-| P01-A | **GO to review/merge — candidate green** | Revision 5 implements the approved bounded evaluator after P04-A; typecheck, plugin/schema/release validation, 13 focused tests, beta.11 compatibility, and the final combined 319/319 suite pass. Keep status `approved` until merge/install and acceptance. P01-B remains deferred. |
+| P04-A | **DONE — implemented** | Revision 5 passed its 306/306 checkpoint and the final combined P04-A/P01-A 319/319 suite, shipped in exact `v2.0.0-beta.11` at `44e6734`, and remained part of the beta.12 line. The implementation acceptance gate is closed. P04-B remains deferred. |
+| P01-A | **DONE — implemented** | Revision 5 passed typecheck, plugin/schema/release validation, 13 focused tests, beta.11 compatibility, and the final combined 319/319 suite; it shipped with P04-A in exact `v2.0.0-beta.11` at `44e6734` and remained part of the beta.12 line. P01-B remains deferred. |
 | P02 | **NO-GO** | Do not implement until its output-to-evidence mapping and semantic-authority proposal pass the fresh/historical replay gate. The brief defines the required contract and current-state routing, but the causal Step hypothesis is still only partially confirmed. |
 | P03 | **NO-GO** | Required category-B evidence is absent. Reconsider only after P04-A and the relevant P01 authority exist and a fresh role-separated replay isolates a real context omission. |
 | P05 / P04-B | **NO-GO / not materialized** | Structural replacement, topology evolution, residual-scope redistribution, and completed-work adoption require a separate brief. P04-A blocks replacement rather than guessing these semantics. |
 
-Recommended implementation sequence:
+Remaining evidence-gated sequence:
 
 ```text
-P04-A -> P01-A -> validate P02 hypothesis -> validate P03 hypothesis
-                   +-> separately materialize P05/P04-B when replacement is required
+implemented P04-A -> implemented P01-A -> validate P02 hypothesis -> validate P03 hypothesis
+                                           +-> separately materialize P05/P04-B when replacement is required
 ```
 
-The four-brief set is therefore not one implementation-ready batch. Only the first two bounded
-phases have a recommended implementation route; P02 and P03 remain evidence-gated hypotheses.
+The four-brief set is therefore not one implementation-ready batch. The first two bounded phases
+are implemented; P02 and P03 remain evidence-gated hypotheses, and P04-B/P05 remains unmaterialized.
 
 ## Current validation boundary
 
@@ -112,8 +112,8 @@ evidence, not approval evidence for all four briefs:
   project-memory human gate stopped the isolated lifecycle;
 - it does not exercise structural replacement;
 - the source Signal repository was not modified;
-- P01-A and P04-A are `approved` combined-branch candidates; P02 and P03 remain `hypothesis`.
-  Candidate code and focused tests do not by themselves satisfy the merge/install implementation gate.
+- P01-A and P04-A are implemented and released from the combined candidate in `v2.0.0-beta.11`,
+  then retained through the beta.12 line; P02 and P03 remain `hypothesis`.
 
 Historical active-Milestone state and old M3 Task identifiers are not mandatory inputs to fresh
 materialization validation. Brief-specific replay requirements must use fresh authority unless a

package/docs/release.md

@@ -10,15 +10,23 @@ Before tagging a release:
 
 1. `npm ci`
 2. `npm run validate`
-3. `npm run pack:check`
-4. `npm run smoke:downstream`
-5. `npm run plugin:check`
-6. `npm run docs:pdf:check`
-7. `npm run release:check`
-8. validate `plugins/codex-workflow-gateway` with the Codex plugin validator
-9. validate the append-only real-agent log with
+3. `npm run test:signal-t10-check-support-e2e`
+4. `npm run test:signal-remediation-e2e`
+5. `npm run pack:check`
+6. `npm run smoke:downstream`
+7. `npm run plugin:check`
+8. `npm run docs:pdf:check`
+9. `npm run release:check`
+10. validate `plugins/codex-workflow-gateway` with the Codex plugin validator
+11. validate the append-only real-agent log with
    `node scripts/validate-lifecycle-transcript.mjs --file <lifecycle-log.jsonl>`
 
+The beta.13 real-agent gate follows the same Codex App boundary as production: the Task agent keeps
+its live writer authority while a separate App reviewer consumes an external-sealed packet, then the
+Task agent records the result. A nested native `codex exec` launched from inside another Codex agent
+is not accepted as release evidence. Packet generation is a logged read-only observation; recording
+the sealed result remains an exact `next`-authorized mutation followed by `status` and `next`.
+
 The downstream smoke packs the actual tarball, installs it into an empty temporary project,
 runs the packaged CLI handshake, and proves installation created none of `.codex`, `.tasks`,
 `.increments`, or `.memory-bank` in that project.
@@ -27,7 +35,55 @@ The PDF check deterministically regenerates all three Russian documents from
 `docs/pdf/sources`, binds the visible package version to the root manifest, and fails when any
 tracked PDF is stale. Source and binary PDFs are one release unit.
 
-For beta.12.8, the release gate also relies on `npm run release:check` to fail if:
+For beta.13, `npm run release:check` builds the exact current source before inspecting the packaged
+surface and fails unless all of these release contracts remain present:
+
+- the handshake advertises `cause-bound-rolling-refinement-v1`,
+  `failed-step-continuation-transaction-v1`, `host-safe-credential-reference-v1`,
+  `structural-production-edge-contract-v1`, `observed-route-matrix-v2`, `compact-status-v1`,
+  `reviewer-runtime-preflight-v1`, `explicit-review-mode-v1`, and
+  `app-owned-operational-preflight-v1`;
+- claim/writer credentials are transported only by project/entity/action/actor-bound local
+  references backed by mode-`0600` storage, legacy secret-bearing arguments fail closed, and secret
+  material is absent from argv, output, errors, tool/session/transcript fixtures, and evidence;
+- a failed check commits failure evidence, exact dirty-byte binding, Task continuation state, and
+  lease release through the `failed-step-continuation` transaction; a failed strict review similarly
+  binds remediation, Task pause and exact lease release, and a repeated authoritative reviewer cause
+  adds C1 yield before root-cause replan; the Signal-shaped E2E continues through recovery, the next
+  ordinary Step, Task completion, and next-Task dispatch;
+- five distinct or unclassified review findings continue in the same Task without a numeric cap,
+  while root-cause replan requires either a repeated normalized mechanical failure or the same
+  stable external reviewer `causeId` with `planConflict=true`;
+- a transitive same-component check owner may refine the same Task only under the unchanged semantic
+  boundary; for a multi-Step `runtime-composition` consumer the independent PRA classification,
+  not a planner opt-in, requires an edge from a transitive owner to an exact executable consumer
+  check. A simple one-Step runtime is exempt; neither assertion claims semantic product truth or
+  P02/P01-B authority;
+- the machine-readable route matrix gives every one of the 13 Signal-observed route classes a
+  unique priority and one exact production transition witness or real terminal observation. The
+  `signal-observed-route-class-witnesses` boundary does not claim every action is exercised:
+  action-level metadata remains `executable-witnessed`, `unwitnessed`, or `unsupported`, and unknown
+  actions fail closed;
+- default `status` is a bounded route-exact projection and full historical state requires explicit
+  `status --full`;
+- reviewer runtime preflight is read-only for the sealed checkout and requires exact declared,
+  locked and repository-local installed Workflow versions plus a hash-verified runtime build manifest;
+  on every call it re-resolves the exact recursive runtime dependency graph from each actual parent
+  package (nested before hoisted) and re-hashes package manifests and executable runtime files, so a
+  warm Node module cache cannot hide a removed, changed, conflicting or symlink-redirected dependency;
+  the exact installed gateway, reviewer, and workflow modules are loaded synchronously through the
+  current Node runtime and must report exact package/protocol/schema versions; this avoids a child-process
+  scheduler deadline without caching a trust decision, and every load or contract failure still fails closed;
+  the native reviewer output schema is accepted by API strict Structured Outputs: every object property
+  is required, optional finding values use explicit nullability, and malformed semantic combinations fail closed;
+  a missing install, missing/stale build or failed handshake returns `prepared=false` with an
+  actionable blocker; every sealed review packet binds `ordinary` or `security` mode, and ordinary
+  review cannot imply a security scan;
+- package-owned operational preflights report worktree observation, watchdog, consent, and
+  coordinator-replacement facts without claiming Codex App scheduling, chat mutation, consent, or
+  atomic App effects.
+
+For beta.12.19, the release gate also relies on `npm run release:check` to fail if:
 
 - canonical entity schema 2 shapes drift;
 - protocol 2 is not the active public contract, or intact protocol-1 adoption evidence stops being readable through the bounded compatibility window;
@@ -48,10 +104,28 @@ For beta.12.8, the release gate also relies on `npm run release:check` to fail i
   revision-26 fixture, or pending/corrupt-review rejection regressions are absent.
 - dependency recovery again requires Task-local manifest/lock fields to equal the Milestone base,
   or a candidate commit can alter any non-Workflow dependency payload.
+- corrective replan drops completed Step evidence from accepted Task history, or an already-stranded
+  Task can register arbitrary/unreviewed history instead of one exact passed and previously accepted
+  Step commit.
+- beta.12.9 cannot install through an exact dependency-only base/Task transport while preserving the
+  active Step worktree, or that compatibility route fails to bind the dependency HEAD, historical
+  commit, current Plan/Step, dirty paths/content hash, and absence of leases/transactions.
 - the read-only Milestone progress projection, replacement regression, project-monotonic chat
   registry, title fallback/readback, or long-Cyrillic multi-attempt E2E evidence is absent.
-- bounded first-failure Plan-integrity recovery, exact failed-remediation/manifest/worktree
+- bounded first- or repeated-failure Plan-integrity recovery, selector-required npm-check
+  feasibility, exact failed-remediation/manifest/worktree
   bindings, or the no-synthetic-second-failure regression is absent.
+- Plan-integrity update preflight again hard-codes one historical source release instead of deriving
+  a coherent exact beta.12 source from declared/locked/installed/current/base surfaces, or it accepts
+  a source before beta.12.11, a source not older than the runner, or any divergent version surface.
+- a direct migration check can import an external checksum/catalog authority without the producing
+  Step owning it; or in-flight recovery can widen beyond the exact imported support path, bypass
+  `forbiddenScope`, change the Plan hash, skip checks/Core commit/review disclosure, or require a
+  Human approval for the machine-proved scope-only correction.
+- historical check-support evidence is reinterpreted against a later Plan instead of the Plan hash
+  recorded by the event; or a post-rebind update is accepted without one planned Step explicitly
+  owning every previously derived support path in both `allowedWrites` and `expectedOutputs`, exact
+  dirty-byte continuity, coherent versions, and an otherwise idle recovery boundary.
 - downstream proof cannot invalidate only completed transitive-predecessor authority while
   preserving worktree/HEAD, yielding C1, and returning the same Task to fresh planning; or unrelated
   dirty files and damaged invalidation evidence do not fail closed.
@@ -72,6 +146,12 @@ For beta.12.8, the release gate also relies on `npm run release:check` to fail i
   feasibility capability is absent from the packaged handshake.
 - continuable guarded remediation or evidence-bound `fix`/`replan` review routing is absent, or a
   third/later failed review is again converted into an attempt-count stop.
+- audited remediation can change Milestone outcome/success signal/acceptance/checks, omit or add
+  arbitrary predecessor authority, reuse one blocking audit, run with dirty/owned state, or stop
+  before the new Task merges and the original Task completes a subsequent Step.
+- `corrective-derived` Task authorization/final acceptance can exist without the current exact
+  Milestone execution authorization and audited-remediation event, or final Milestone acceptance is
+  derived automatically.
 - the append-only, Human-confirmed beta.11 attempt-four stop override, its exact three-event/
   continue/stop binding, split rejection, stale-confirmation rejection, or tamper detection is
   absent from the package.

package/docs/updating-existing-project.md

@@ -22,6 +22,211 @@ state schema. Совпадение `stateSchemaVersion` до и после об
 нужна. Для alpha.6 при `stateSchemaVersion: 2` применяется не migration, а sidecar-only
 adoption posture.
 
+### beta.13: coherent continuation and host-safe credentials
+
+`2.0.0-beta.13` сохраняет `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 сама по себе не
+является 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` без диапазона и измените только
+   `package.json` и lock-файл.
+3. Новой repository-local версией подтвердите совпадение declared, locked и installed
+   `2.0.0-beta.13`, прежний `projectId`, protocol/schema `2/2`, затем выполните `handshake`,
+   `doctor`, компактный `status` и `next`.
+4. Обновите персональный `codex-workflow-gateway` только штатным installer из установленного
+   exact пакета и продолжайте работу в новом чате, который загрузит новую skill-инструкцию.
+5. Если dependency commit сделал Knowledge Map stale, используйте только свежий advertised
+   reconcile/rebind route. Не объявляйте обновление пакета доказательством продуктового изменения.
+
+После beta.13 credential contract меняется на host-safe references. Claim и writer transitions
+принимают `--claim-credential-ref` или `--writer-credential-ref`; секретное значение нельзя
+передавать в argv, prompt, transcript, stdout/stderr или JSON evidence. Ссылка указывает на локальную
+project/entity/action/actor-bound запись с режимом `0600`; one-time claim reference потребляется
+после успешного перехода. Старые secret-bearing CLI options fail closed. Если `next` требует свежую
+credential после failed Step, lease expiry или claim recovery, следуйте сначала рекламируемому
+credential replacement route и используйте только возвращённую reference, не старый secret/token.
+
+Failed Step beta.13 больше не должен требовать ручного сохранения worktree или глобального lock
+repair: Core одной `failed-step-continuation` transaction связывает failure evidence и точный hash
+dirty bytes, переводит Task в продолжимое состояние и освобождает lease. Fresh `status -> next`
+затем определяет ordinary same-Task fix либо root-cause replan. Количество review/fix циклов не
+ограничено числом: replan обязателен только при повторе механически нормализованной причины либо
+того же stable external reviewer `causeId` с `planConflict=true`; новая или неклассифицированная
+находка остаётся same-Task fix.
+
+Failed strict review также освобождает exact proven lease в одной transaction с remediation и Task
+pause. При повторной authoritative reviewer cause эта transaction одновременно завершает C1 claim,
+поэтому fresh `next` может рекламировать root-cause `task plan-set` без Human gate и без живой
+write-authority. Прерванная граница после уже записанных review sidecars повторно завершается без
+duplicate remediation.
+
+Для новых Plans beta.13 дополнительно проверяет transitive component owner. Для multi-Step Task
+независимая PRA-классификация consumer как `runtime-composition` требует явный structural production
+edge: transitive owner Step, consumer Step и named check, который реально выполняет consumer. Planner
+не может отключить эту проверку, пропустив flag или edge; простой one-Step runtime остаётся вне неё.
+Это проверка структурной полноты, а не доказательство продуктовой
+семантики и не реализация P02/P01-B. Generic shadow-history import, P04-B structural replacement и
+completed-Step adoption остаются неподдержанными.
+
+Операционные read-only контракты beta.13:
+
+- `status` по умолчанию возвращает bounded compact projection; полная история доступна только через
+  явный `status --full`;
+- sealed review packet проходит reviewer runtime preflight без изменения checkout: declared, locked и
+  repository-local installed Workflow versions совпадают, а runtime build manifest и каждый его JS hash
+  проверены; каждый вызов заново разрешает recursive runtime dependencies от их фактического parent package
+  (nested раньше hoisted) и сверяет package manifest и исполняемые файлы по хешам, поэтому warm module cache
+  не скрывает удалённую, изменённую, конфликтующую или symlink-перенаправленную зависимость;
+  текущий Node синхронно загружает exact installed gateway/reviewer/workflow graph и подтверждает
+  package/protocol/schema без child-process scheduler deadline и без кэширования trust decision;
+  missing install, missing/stale build либо failed module handshake дают
+  `prepared=false`, и packet не считается готовым; packet всегда несёт `--review-mode ordinary` или
+  `--review-mode security`; ordinary review не должен неявно запускать security scan;
+- observed-route matrix v2 покрывает 13 route classes, фактически наблюдавшихся в Signal: для каждого
+  класса есть один exact production-transition witness либо real terminal observation. Это не значит,
+  что проверена каждая action: metadata отдельно помечает `executable-witnessed`, `unwitnessed` и
+  `unsupported`, а coverage boundary равна `signal-observed-route-class-witnesses`;
+- chat replacement, consent inheritance, polling и scheduling остаются эффектами Codex App;
+  package сообщает только preflight/diagnostics и не утверждает, что выполнил эти действия.
+
+### beta.12.19: hash-bound check-support dirty carryover at Task run
+
+beta.12.18 could validate and transport a historical check-support recovery through a new Plan, but
+the final execution boundary still applied the ordinary clean-checkout rule. Consequently fresh
+`next` advertised `task run` after dependency registration, Knowledge rebind, Risk Audit and
+authorization, while the same `task run` rejected the preserved product bytes.
+
+beta.12.19 gives navigation and execution one shared fail-closed assessment. Carryover is valid only
+when the latest registered Plan-integrity dependency record binds the current history boundary, the
+current Plan is that record's Plan or its exact Knowledge-rebind descendant, the planned Step owns
+every dirty path, every derived support path is explicit in both `allowedWrites` and
+`expectedOutputs`, and the full dirty file list and content hash still match the validated historical
+decision. `next` then reports `planIntegrityDirtyCarryover.state=validated`; `task run` may adopt
+exactly those bytes. Any mismatch changes `next` to `doctor` and leaves execution blocked.
+
+An in-flight beta.12.18 Task already in the authorized dirty-carryover posture may use external exact
+beta.12.19 `update plan-integrity-update-preflight`. It returns
+`compatibilityMode=post-rebind-dirty-carryover` only when the existing registration and all ordinary
+version, Git, lease, transaction and Core-operation guards pass. Continue only through the reported
+dependency-only transport and fresh repository-local routes. No Human approval is introduced for
+this exact machine-proved continuation; checks, Core commit and external sealed review remain
+mandatory.
+
+### beta.12.18: historical check-support scope adoption after Knowledge rebind
+
+beta.12.18 closes a bounded post-rebind deadlock. A Task may already contain a valid beta.12.16
+`continue-fix` decision that derived one exact check-support path, then refresh Knowledge and adopt
+that path explicitly in a new Plan. The historical event must still be validated against its own
+Plan hash; comparing it with the new Plan incorrectly reports `STATE_CORRUPT` precisely because the
+new Plan now owns the path.
+
+An external exact beta.12.18 runner recognizes only this exact shape: the Task awaits execution
+authorization, no Step is running, one historical check-support decision binds the unchanged dirty
+worktree, and one planned Step directly lists every derived support path in both `allowedWrites` and
+`expectedOutputs`. Read-only `update plan-integrity-update-preflight` reports
+`compatibilityMode=post-rebind-scope-adoption` only when all ordinary version, lease, transaction,
+Core-operation, Git-head and dirty-byte guards also pass.
+
+After `eligible=true`, use the same dependency-only base/Task transport described below. Fresh
+repository-local Core registers it only through advertised
+`update plan-integrity-dependency-recover`; Knowledge rebind and Risk Audit then follow fresh
+`status -> next`. The adopted support path comes from the current Plan, not from implicit reuse of
+the historical event. No Human approval is required for this exact machine-proved recovery. Any
+additional path, dirty-byte drift, missing explicit Plan ownership, multiple matching events, active
+lease or incoherent version surface remains blocked.
+
+### beta.12.17: coherent beta.12 Plan-integrity update transport
+
+`update plan-integrity-update-preflight` больше не связывает совместимый transport с одним
+историческим source release. Внешний exact beta.12.17 runner выводит source version из declared
+dependency и требует, чтобы locked, installed, current Task branch и active Milestone base
+совпадали с ним. Source должен быть exact `2.0.0-beta.12.N`, где `N >= 11` и `N` меньше patch
+ordinal текущего runner. Расхождение хотя бы одной поверхности блокирует transport.
+
+Остальные границы не изменены: ровно одна eligible Plan-integrity conflict, coherent observation,
+нет lease/transaction/Core operation, а dirty set полностью совпадает с уже доказанным failed Step
+scope. После `eligible=true` один dependency-only commit обновляет только `package.json` и
+`package-lock.json` на Milestone base и в Task history; fresh repository-local package затем
+регистрирует commit через advertised `update plan-integrity-dependency-recover`. Product bytes,
+Plan hash и remediation evidence не переписываются. Этот контракт разрешает текущий `.15 -> .17`
+transport и не требует нового literal для следующего совместимого beta.12 patch.
+
+### beta.12.16: direct migration check-support authority
+
+Новый mechanical analyzer до execution authorization проверяет root `npm run` migration checks,
+repository-local `node`/`tsx` runner и его direct static relative imports. Если Step создаёт новую
+SQL migration, а импортированный TypeScript/JavaScript support-модуль закрепляет approved SHA-256,
+manifest или expected catalog той же migration family, этот support path должен входить в
+`allowedWrites` той же Step. Иначе Plan возвращается к `task plan-set` до запуска Worker.
+
+Для уже выполняемой Task с первым `checks-failed` fresh beta.12.16 `next` может рекламировать
+`task plan-integrity-recover` с reason `CHECK_SUPPORT_ANCHOR_OUTSIDE_ALLOWED_WRITES` и
+`boundedEffect=record-machine-derived-check-support-scope`. Выполните только этот route под текущим
+C1 actor/writer credential, затем снова прочитайте `next` и вызовите `task run`. Worker envelope
+должен добавить ровно `evidence.scopeExtensions`; Plan hash и существующие product bytes остаются
+неизменными. Core повторяет все checks, сам создаёт commit и включает derived scope в sealed review
+packet. Human corrective-replan для этого точного scope-only случая не требуется. Если route не
+рекламируется, есть indirect/dynamic import, лишний dirty path, forbiddenScope intersection или нет
+SHA/catalog anchors — не расширяйте scope вручную.
+
+### beta.12.12: неисполняемая Step check и сохранение текущей реализации
+
+Новые Plans больше не могут получить execution authorization, если root npm script запускает
+repository-local `affected` validator, сам validator явно требует `--base`, `--head` или `--files`,
+а Step check не передаёт ни одного selector. Исправьте check в Plan, например
+`npm run validate:affected -- --files=<allowedWrites>`; Worker и remediation attempt до этого не
+запускаются.
+
+Для Task, уже застрявшей на beta.12.11 после одного или нескольких одинаковых `checks-failed`,
+используется только bounded bridge. Внешний exact beta.12.12 runner выполняет read-only
+`update plan-integrity-update-preflight`; продолжение допустимо лишь при `eligible=true`, отсутствии
+lease/transaction и точном dirty set внутри failed Step `allowedWrites`. Затем один dependency-only
+commit (`package.json` и `package-lock.json`) должен оказаться и на Milestone base, и в Task history
+без изменения product bytes. Fresh repository-local `next` рекламирует
+`update plan-integrity-dependency-recover`; этот переход регистрирует dependency commit и, если
+Knowledge drift вызван только Workflow pin в `package.json`, атомарно выполняет corrective-derived
+Knowledge refresh без Human approval.
+
+После регистрации Core связывает всю append-only цепочку failed attempts, текущий Plan, HEAD,
+manifest, validator и SHA-256 dirty worktree. `task plan-integrity-recover` записывает один
+`replan-required` decision для следующего ordinal. Затем следуйте fresh
+`task corrective-yield -> task corrective-replan-*`; replacement Plan обязан сохранить Step и dirty
+allowlist, но заменить check на исполняемую selector-bearing команду. Не коммитьте product files,
+не редактируйте state и не повторяйте старую неисполняемую проверку.
+
+### beta.12.11: audited remediation и dependency-only Knowledge refresh
+
+После безопасного обновления существующий active Milestone может продолжить работу без пересоздания,
+если current `next` показывает pre-execution `stop-escalate` и объект `auditedRemediation`. Это не
+update compatibility bridge и не разрешение вручную менять state. Сначала выполните обычный
+`update preflight`; установите exact beta.12.11 только при `safe=true`, clean checkout, отсутствии
+running Step и leases, затем снова выполните repository-local handshake, `status` и `next`.
+
+Далее следуйте только свежему route: remediation Discovery -> ready ->
+`milestone remediation-materialize`. Передайте exact Milestone/Task revisions и JSON с Discovery,
+title и `predecessorTaskIds`, которые полностью совпадают с
+`next.auditedRemediation.requiredPredecessorTaskIds`. Переход не принимает confirmation code,
+actor, grant или новый Milestone Plan. После atomic materialization новый required Task должен стать
+repository priority и пройти обычную реализацию/review/merge. Его Task approval transitions используют
+только exact `correctiveDerivedApproval.actor` из fresh `next`. После merge исходная Task обязана
+вернуться к `task plan-set`, fresh Risk Audit и следующему Step. Если fresh `next` не рекламирует этот
+контракт, не вызывайте команды напрямую и не редактируйте Milestone state.
+
+Если exact dependency-only update сделал approved Knowledge Map stale только по `package.json`,
+`auditedRemediation.dependencyKnowledgeRefresh` должен подтвердить clean checkout, aligned
+declared/locked/installed/HEAD/base versions и полную Git-цепочку commits, меняющих только Workflow pin
+в `package.json`/lock. Такой content refresh не требует Human approval: он применяется в той же Project
+transaction, что и `milestone remediation-materialize`, с `corrective-derived` evidence. Любой другой
+Knowledge diff (включая README, документацию, classification, gap или conflict) не допускается в этот
+маршрут и остаётся в обычном reconcile/approval flow.
+
 ### Исключение для lifecycle-дедлока alpha.6
 
 Обычный `update preflight` намеренно блокирует обновление при `in_progress` Step. Если alpha.6
@@ -59,6 +264,36 @@ candidate: его HEAD обязан менять ровно `package.json` и `p
 dependency; любое другое поле, добавленное тем же candidate commit, неизвестный commit, stale base,
 dirty checkout, lease или transaction по-прежнему блокируют recovery.
 
+### Исключение beta.12.9 для Step commit, потерянного corrective Plan
+
+Если активный corrective Step сохраняет допустимый dirty worktree, а `task step-complete` обнаруживает
+ровно один старый product commit, beta.12.9 не требует переписывать Git. Пакет поддерживает два
+строго ограниченных входа в один и тот же recovery:
+
+- если beta.12.9 уже зарегистрирована, свежий `next` рекламирует
+  `task historical-step-provenance-recover`;
+- если для установки beta.12.9 на Milestone base и Task branch уже созданы ровно dependency-only
+  commits, свежий `next` рекламирует `update historical-step-dependency-recover`. Этот переход
+  атомарно регистрирует новый dependency HEAD и сохраняет authority старого Step commit.
+
+В обоих случаях Core сам доказывает для старого SHA полную hash-valid strict Step Review цепочку с
+решением `passed`, verified reviewer isolation и совпадающий прежний `final_acceptance`. Update-route
+дополнительно требует exact target version на declared/locked/installed/current-branch/base surfaces,
+dependency commit только из `package.json` и `package-lock.json`, а также неизменный hash активного
+dirty worktree относительно read-only assessment.
+
+Сначала выполните read-only `task historical-step-provenance-preflight --id <TASK-ID>`. Продолжайте
+только при `eligible=true`, точных Task revision, Plan/Brief/HEAD и commit SHA, отсутствии leases,
+transactions и Core operations, а также dirty paths строго внутри `allowedWrites` единственного
+активного Step. Recover принимает exact SHA, actor и содержательную reason, добавляет SHA в
+`invalidatedStepCommits` и записывает источник прежнего acceptance. Product bytes, HEAD и текущий
+Plan не меняются; старый Step не возвращается в Plan. После recovery обязательны последовательные
+`status` и `next`, затем обычный credential route и `task step-complete` текущего Step.
+
+Несколько unknown commits, pending/failed review, несовпадающий Plan прежнего acceptance,
+повреждённый sidecar, посторонний dirty path или lease являются hard stop. Запрещено заменять этот
+переход rebase/reset/amend, ручным `systemCommits` или переносом старого Step в текущий Plan.
+
 ### Исключение beta.12.6 для активного downstream proof
 
 Обычный `update preflight` по-прежнему правильно запрещает обновление при running Step и dirty