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

package/docs/pdf/README.md

@@ -1,24 +0,0 @@
-# Russian PDF documentation
-
-The three tracked PDFs in this directory are deterministic release artifacts generated from the
-reviewable Markdown files in [`sources`](sources/).
-
-Generate them with:
-
-```bash
-npm run docs:pdf
-```
-
-Verify that the tracked binaries match the current sources and package version with:
-
-```bash
-npm run docs:pdf:check
-```
-
-The generator reads the exact version from the root `package.json`, uses embedded TrueType font
-subsets, and writes deterministic PDF bytes. A release must update source and PDF together. The
-PDFs are human-facing artifacts; runtime code, schemas, the bundled gateway and ordinary Markdown
-documents remain the technical authority.
-
-The runner uses `CODEX_WORKFLOW_PDF_PYTHON` when supplied, then the bundled Codex App Python, then
-`python3`. Non-Codex environments can install the pinned dependency from `requirements.txt`.

package/docs/pdf/requirements.txt

@@ -1 +0,0 @@
-reportlab==4.4.9

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

@@ -1,478 +0,0 @@
----
-title: Codex Workflow V2: архитектура beta.13
-subtitle: Источники истины, lifecycle, роли, delegation, зависимости Tasks и границы доверия
-part: Часть 1 из 3 | Архитектура
-document_version: 2.0
-date: 2 сентября 2026
-subject: Архитектура и границы Codex Workflow V2 beta.13
----
-
-# 1. Назначение и граница системы
-
-Codex Workflow V2 - локальный state machine поверх Codex App, Git и файлов проекта. Codex выполняет
-исследование и реализацию. Workflow Core решает, разрешена ли конкретная мутация, связывает её с
-актуальными revisions и hashes, управляет writer credentials и создаёт проверяемые Git evidence.
-
-> **Главная граница:** файлы проекта и Git history являются долговременной продуктовой памятью. Локальный Workflow state хранит производный lifecycle и не может заменять repository knowledge.
-
-Система рассчитана на одного пользователя и одну машину. Она не предоставляет distributed locking,
-криптографическую идентификацию actor string или безопасную синхронизацию state между компьютерами.
-
-## 1.1. Что beta.13 гарантирует
-
-- exact project-local npm package и совместимый handshake до lifecycle действий;
-- Discovery до materialization Task или Milestone;
-- утверждённую Project Knowledge Map и Plan, связанный с её точной revision/hash;
-- mechanical-feasibility проверку поддерживаемых форм Plan до новой Task authorization;
-- явный Milestone dependency DAG и один общий runnable predicate для routing, handoff, claim и start;
-- один C1 writer lease, host-safe credential references и Core-owned Step commits: secret хранится
-  только в project-bound local vault с mode `0600`, а argv и CLI output содержат только reference;
-- lease-free Human final-acceptance gate: `task result-set` проверяет и освобождает active writer
-  lease, а после acceptance merge получает новый credential только через fresh recovery route;
-- external-sealed Step/Task review в отдельных Codex tasks;
-- state-bound human gates либо ранее выданные bounded delegation contracts;
-- journaled recovery для составных переходов и fail-closed поведение при drift/corruption.
-- bounded recovery, когда downstream proof требует изменить уже завершённый predecessor Step:
-  worktree и HEAD сохраняются, stale completion authority снимается, та же Task возвращается в planning.
-- bounded compatibility recovery, если beta.12.6 после этого recovery ошибочно rebind-нула отвергнутый
-  Plan: exact dirty bytes сохраняются до нового consolidated Step, а Knowledge refresh не отменяет `plan-set`.
-- corrective Plan сохраняет authority исключённых completed Step commits, а beta.12.9 bounded recovery
-  исправляет уже stranded state только при passed strict review и прежнем hash-bound final acceptance.
-- pre-execution `stop-escalate`, доказавший отсутствующую upstream capability, может materialize ровно
-  один additive remediation Task без нового Human gate; Core сохраняет Milestone semantics и выводит
-  authority из текущей Milestone authorization и exact audit evidence.
-- исторический check-support decision проверяется против собственного Plan hash, а новый Plan может
-  продолжить только после явного принятия каждого support path в `allowedWrites` и `expectedOutputs`;
-  implicit scope carry-over и Human approval для этого exact machine-proved случая отсутствуют.
-- после dependency registration и Knowledge rebind один общий fail-closed assessor управляет и
-  навигацией, и `task run`: переносится только точный dirty set с тем же content hash, registered HEAD,
-  непрерывной Plan/rebind chain и явным scope текущей Step; drift переводит route в `doctor`.
-- failed check фиксируется одной project transaction: Core связывает checks и dirty-worktree hashes,
-  сохраняет неизменные product bytes, переводит Task в `needs_fix` и освобождает writer lease;
-- failed strict review так же атомарно связывает remediation, Task pause и lease release; при повторной
-  authoritative reviewer cause та же transaction добавляет C1 yield до рекламы root-cause replan;
-- rolling cause-bound refinement без числового лимита: новая причина остаётся в той же Task, а повтор
-  mechanically normalized cause либо stable reviewer `causeId` с `planConflict=true` требует replan
-  первопричины;
-- evidence-bound transitive component-owner augmentation при неизменной semantic boundary и
-  PRA-derived production-edge obligation для multi-Step `runtime-composition` consumer с transitive
-  owner и исполняемым consumer check; простой one-Step runtime исключён;
-- компактный `status` по умолчанию, подготовительный reviewer-runtime preflight вне sealed checkout и
-  явный review mode `ordinary|security` без неявного security scan;
-- versioned matrix для route classes, реально наблюдавшихся в Signal: unique priority, predicate,
-  CLI/executor binding и successor witness; unsupported действия перечисляются явно.
-
-## 1.2. Что beta.13 не гарантирует
-
-- правильность продуктовой идеи или автоматически выбранного provider Task;
-- semantic sufficiency Plan, если точные факты нельзя доказать поддерживаемым analyzer;
-- параллельную работу нескольких writers в одном checkout;
-- автоматический structural replacement после `split-required`;
-- восстановление вручную повреждённого state без штатной recovery transition.
-- product truth только из structural production-edge contract: он доказывает форму owner/consumer/check,
-  но не корректность требований, поведения продукта или Step-validity authority P02;
-- глобально полный каталог state machine: observed-route matrix ограничена route classes из Signal и
-  хранит отдельный unsupported inventory;
-- generic import product-first/shadow history либо синтетическое принятие Step, Task или Milestone.
-
-# 2. Шесть уровней и источники истины
-
-| Уровень | Источник истины | Ответственность |
-|---|---|---|
-| Пользователь / principal | Явные ответы и подтверждённые policies | Scope, semantic unknowns, grant issuance, human gates |
-| Codex App | Project folders, tasks, permissions | User-visible execution contexts и bounded tool access |
-| Роли агентов | Fresh ContextPacket и Workflow projection | Discovery, planning, execution, review, coordination |
-| Project-local gateway | Exact installed package и protocol | Handshake, routing discipline, app chat boundary |
-| Workflow Core | Runtime transitions и schemas | Revisions, hashes, locks, Git ownership, evidence |
-| Repository и local state | Git/files и revisioned state | Durable product facts и производный lifecycle |
-
-При расхождении приоритет имеют runtime Core и обычные файлы текущего repository. PDF объясняет
-контракт человеку, но не заменяет `status`, свежий `next`, schemas или package-local help.
-
-## 2.1. Exact package boundary
-
-Продуктовый repository обязан объявить `codex-workflow-v2` точной версией в `devDependencies`.
-Gateway разрешает только `node_modules/codex-workflow-v2/dist/src/cli.js` этого repository,
-сравнивает installed и declared versions, затем выполняет `gateway handshake`.
-
-```text
-AGENTS.md
--> project-local gateway
--> gateway handshake
--> status              # bounded compact projection
--> status --full       # только когда действительно нужна полная historical projection
--> next [--task <exact TASK-ID>]
--> только рекламируемая transition
-```
-
-`doctor` является диагностикой, но не заменяет успешные `status` и `next`. Help разрешён только для
-уточнения syntax после свежего routing response.
-
-# 3. Долговременные и производные артефакты
-
-| Артефакт | Где находится | Кто владеет записью |
-|---|---|---|
-| Product code, tests, Markdown docs | Git repository | Worker в Plan scope; Git commit создаёт Core |
-| AGENTS.md и Project Knowledge | Git repository | Пользователь и обычный reviewable change |
-| Knowledge Map | Local Workflow state | Project-memory transitions |
-| Discovery state | Local Workflow state | Discovery transitions |
-| Brief, Plan, Result, evidence | Local Workflow state с versioned artifacts | Core transitions |
-| Task/Milestone state и sidecars | Local Workflow state | Core, CAS и schema validation |
-| Writer locks и private credentials | Local Workflow state; credential vault files mode `0600` | Lock manager и C1 transitions |
-| Transaction journals | Local Workflow state | Composite transition recovery |
-| codebase graph binding | Local Workflow state | Derived evidence, не product authority |
-
-Ручное редактирование state, locks, sidecars или `.versions` запрещено. Оно ломает hash chain,
-expected revision и восстановимость составных операций.
-
-# 4. Discovery, Task и Milestone
-
-| Сущность | Назначение | Terminal success |
-|---|---|---|
-| Discovery | Уточнить outcome, scope, acceptance, constraints и unknowns | Готова к materialization |
-| Task | Один самостоятельный проверяемый результат | Reviewed, accepted и merged |
-| Step | Атомарный инкремент внутри Task | Checks, один Core commit и evidence |
-| Milestone | Сквозной outcome из связанных Tasks | Required Tasks merged, validation и acceptance |
-
-## 4.1. Task lifecycle
-
-```text
-Discovery -> materialize -> Plan -> Plan Risk Audit
--> mechanical feasibility -> execution authorization
--> C1 handoff -> claim -> start -> Steps
--> submit -> external-sealed review -> Result
--> final acceptance -> merge
-```
-
-`task result-set` является последним execution lease-bound переходом. Он требует рекламируемую
-writer credential reference, освобождает lease до `awaiting_final_acceptance` и тем самым допускает неограниченную
-по времени Human pause без stale-lock блокировки repository. После acceptance прежний token не
-переиспользуется: fresh `next` выдаёт bounded `task writer-credential-replace` для merge.
-
-Fresh Task authorization записывает versioned mechanical-feasibility evidence. Analyzer может
-выдать `blocked`, `pass` или `unverified`. `unverified` не означает semantic approval; он означает,
-что поддерживаемая точная грамматика не доказала противоречие.
-
-## 4.2. Milestone initial assembly
-
-После materialization Milestone Core возвращает `milestone initial-assembly`. Coordinator создаёт
-linked Task Discoveries и materializes Tasks только через команды, рекламируемые `next`. После
-появления полного intended membership один `milestone plan-set` атомарно публикует state и plan.json.
-До этого execution недоступно.
-
-Каждая membership содержит:
-
-```text
-taskId
-disposition: required | waived | cancelled
-reason
-dependsOnTaskIds: [exact predecessor Task IDs]
-```
-
-Даже независимая Task обязана объявить `dependsOnTaskIds: []`. Отсутствующее поле в legacy state
-означает unknown dependency authority, а не пустой граф.
-
-## 4.3. Runnable predicate P04-A
-
-Task runnable только когда Milestone active, membership required и все canonical predecessors имеют
-status `merged`. Ordinal, название, время создания и порядок в чате не создают dependency.
-
-Один predicate применяется к repository routing, Task-specific routing, handoff preparation,
-claim до lease acquisition и direct start. Authorization не обходит dependency block.
-
-# 5. Delegated approval и Milestone autonomy
-
-Delegation не превращает agent в human actor. Event отдельно хранит principal, delegate, grant,
-policy hash, transition, scope и expiry.
-
-| Механизм | Когда применять | Что не разрешает |
-|---|---|---|
-| Direct human gate | Default path | Никакой последующей автономии |
-| DGA/DGR delegated approval | Exact allow-listed approval transition | Scope expansion, grant issuance, обычные execution transitions |
-| Milestone Autonomy Contract | После полного initial Milestone Plan | Outcome/check/base/discovery changes и standalone map approval |
-
-Для нового `AUTO` Discovery допустим короткий project-scoped DGR, если нужен exact
-`project_memory.approve` или будущий approval transition. Blocking semantic unknown всегда возвращается
-пользователю. После полного initial Milestone Plan предпочтителен один bounded
-`milestone autonomy-prepare` gate и отдельное подтверждение `MAC-*`, затем `autonomy-grant`.
-
-Milestone Autonomy Contract покрывает разрешённые Task/Milestone approvals, membership-only evolve и
-Project Memory approval только внутри atomic Task context refresh этого Milestone. Grant не применяется
-к handoff, claim, run, step-complete, reviews, sync-base или merge.
-
-# 6. Codex App chat topology
-
-Milestone coordinator и Task chats являются отдельными user-visible Codex tasks, не fork одного
-conversation. Coordinator создаёт Task chat just-in-time, передаёт закрытый TaskContextPacket и
-остаётся активным supervisor до terminal Milestone либо настоящего user gate.
-
-```text
-Coordinator
-  -> Task T01 chat
-       -> Step Review chat при external-sealed gate
-       -> Final Review chat
-       -> Corrective/Plan Audit chat при необходимости
-  -> status -> next -> milestone progress
-  -> следующий runnable Task chat
-```
-
-Project chat registry атомарно выдаёт monotonic `#NNN`. Название всегда содержит membership ordinal и
-полный entity ID. Sidebar count, creation order и ручное `01/02` не являются authority.
-
-Coordinator ждёт routed Task через bounded waits, читает закрытый CoordinatorReport, затем проверяет
-repository `status -> next`. Завершение дочернего чата само по себе не доказывает terminal Task.
-
-# 7. C1 handoff, lease и Git ownership
-
-`task handoff-prepare` возвращает `claimCredentialReference`, связанную с project, Task, target actor,
-action и expiry. CLI разрешает `task claim` только с `--claim-credential-ref`, после успешного claim
-удаляет одноразовый reference и возвращает `writerCredentialReference`. Lease-bound действия используют
-только `--writer-credential-ref`. Legacy `--claim-token` и `--writer-token` отклоняются до transition.
-
-Underlying bearer secret хранится только в regular local-vault file с mode `0600`; он не появляется в
-argv, stdout, stderr, errors, packets или evidence. Reference не является переносимой authority: Core
-проверяет project/entity/action/actor/expiry и integrity hash. Если reference утрачен или lease истёк,
-используется только рекламируемая `task writer-credential-replace` для exact claimant.
-
-Worker меняет только `allowedWrites` и оставляет изменения uncommitted. Coordinator вызывает точный
-`task step-complete`; Core запускает checks, проверяет scope/history, создаёт один commit и evidence.
-
-# 8. Knowledge Map и context refresh
-
-Project Knowledge Map хранит paths, categories, scope, authority, hashes, gaps и conflicts, но не
-копирует содержимое файлов. Scan является read-only. Reconcile и approve выполняются только через Core.
-
-Если top-level `next` возвращает `task context-refresh`, Coordinator вызывает только эту atomic
-transition с указанными revisions, actor и grant. Standalone reconcile перед ней создаёт human-approval
-gap и блокируется.
-
-Кроме content-only drift, Core может допустить exact supporting-source addition, заранее объявленное
-execution-authorized Plan и покрытое тем же Milestone Autonomy Contract. Unsafe differences возвращают
-обычный видимый reconcile/approve/rebind/reauthorize flow.
-
-# 9. Review и corrective recovery
-
-В Codex App strict review выполняется external-sealed:
-
-1. Core формирует read-only review packet и repository seal.
-2. Task chat создаёт отдельный Reviewer chat.
-3. Reviewer возвращает закрытый schema-valid result без mutations.
-4. Core записывает его только если packet и seals не изменились.
-
-Native reviewer использует API-compatible strict Structured Output schema: каждый объявленный ключ object
-обязателен, а семантически необязательные значения finding передаются как nullable. Malformed сочетание
-`route`, `causeId` и `planConflict` не превращается в remediation authority и даёт unverified review.
-
-Каждый packet создаётся только с явным `--review-mode ordinary|security`. Mode `ordinary` не запускает
-и не подменяет проверку неявным security scan; mode `security` используется только когда security focus
-запрошен явно. До выдачи packet Core формирует read-only reviewer-runtime preflight: exact Node и package
-provenance, exact declared/locked/repository-local installed Workflow version, hash-verified runtime
-build manifest и writable temporary cache за пределами sealed checkout. Перед каждым packet preflight
-заново с диска разрешает фактический recursive dependency graph по parent-aware, nested-first правилам
-Node и сверяет exact package manifests и SHA-256 runtime-файлов с build attestation. Поэтому уже
-прогретый module cache не может скрыть удалённую, подменённую, конфликтующую либо symlink-redirected
-dependency. Только после этой проверки preflight синхронно загружает через Node exact installed gateway,
-reviewer и workflow graph. Общий gateway descriptor, который использует и CLI, подтверждает exact
-package/protocol/schema; отдельный child process, произвольный timeout, cached trust decision и process
-output не используются. Missing/stale build или dependency closure и failed runtime contract дают
-`prepared=false`. Preflight не устанавливает dependencies и не изменяет checkout.
-
-Новая beta.13 history не ограничивает число исправлений счётчиком. Каждый failure получает cause
-bindings. Новая или неавторитетная причина продолжает ту же Task и проходит новый strict review.
-Повтор одной authoritative причины после заявленного fix требует root-cause replan: для checks это
-mechanically normalized fingerprint; для внешнего review — тот же stable `causeId` только вместе с
-`planConflict=true`. Сходство текста и номер попытки authority не создают. `route=replan` меняет лишь
-implementation Steps, не objective, requirements или acceptance. Legacy history без cause bindings
-сохраняет прежний compatibility circuit; explicit `split-required` и `stop-escalate` остаются
-stop/redirect decisions.
-
-Если Step check не пройден, beta.13 одной transaction записывает remediation event, Task `needs_fix` с
-hash-bound `failurePause` и удаление lease. Git HEAD и dirty bytes не меняются. Readback сверяет revision,
-status, remediation hash, отсутствие lease, HEAD, dirty paths и их aggregate hash. Fresh `next` сначала
-выдаёт credential replacement при отсутствии usable lease, затем route той же Task — fix или root-cause
-replan. Ручной commit, state edit или потеря worktree не являются продолжением.
-
-Failed strict review использует тот же continuation principle: review sidecars остаются append-only, а
-одна project transaction записывает remediation и Task pause и удаляет exact proven lease. Если новый
-event повторяет authoritative reviewer cause, transaction одновременно добавляет C1 yield. Поэтому
-`task plan-set` рекламируется только при отсутствии writer lease и C1 claim; crash после durable review
-sidecars восстанавливает один pause без duplicate remediation.
-
-Для доказанного failed check Core может найти transitive component owner только по bounded static import
-graph repository-local runner и только внутри уже затронутой component boundary. Same-Task augmentation
-разрешена при неизменных objective, requirements, acceptance и security boundary hashes. Для multi-Step
-Task независимая PRA-классификация consumer как `runtime-composition` требует
-`requiresProductionEdges=true` и edge к существующему transitive owner Step с exact `checkRef`, который
-действительно выполняет consumer. Пропуск planner-owned flag или edge блокирует admission; простой
-one-Step runtime не требует искусственного predecessor. Это структурная admission-проверка, а не
-доказательство product truth и не реализация Step-validity authority P02.
-
-Beta.13.1 делает эту authority prospective и Plan-bound. Markerless PRA, созданная до появления
-production-edge contract, читается без ретроактивной проверки отсутствующих полей, но только пока и PRA,
-и Task не заявляют новую authority. Обычная новая PRA и atomic corrective replan записывают hash-chained
-marker `required-v1`; content-only knowledge rebind сохраняет production edges у native Task, а у
-действительно legacy Task сохраняет markerless posture. Миграция или ручное переписывание state не нужны.
-Граница доверия остаётся repository-local state: это не криптографическая защита от полного
-привилегированного переписывания всей hash chain.
-
-Versioned observed-route matrix v2 связывает все 13 Signal-observed route classes с unique priority и
-одним exact production-transition witness либо real terminal observation на класс. Это class-level
-доказательство: action-level metadata отдельно различает `executable-witnessed`, `unwitnessed` и
-`unsupported`. Действия без CLI authority находятся в explicit unsupported inventory. Boundary
-`signal-observed-route-class-witnesses` не заявляет полноту всех actions или будущих transition families.
-
-Beta.12.1 добавила одну append-only compatibility оговорку: beta.11 attempt-four
-`stop-escalate` после exact `ordinary, ordinary, corrective` и prior attempt-3 `continue-fix` можно
-возобновить через read-only `stop-override-prepare` и отдельный Human-confirmed
-`stop-override-apply`. Исходный stop сохраняется, `split-required` не подходит, а stale revision,
-Plan, HEAD, lease, transaction или повреждённая chain блокируют переход. Попытка 4 снова проходит
-обычный `task run` и новый strict review.
-
-Beta.12.4 сохраняет этот override при последовательности delegated `task context-refresh`, если
-каждая версия Plan изменилась только в canonical Knowledge Map binding. Core проверяет весь
-contiguous rebind/audit chain, mechanical equivalence каждого Plan Risk Audit, общую delegated
-authority и корректную chronology. Git HEAD может продвинуться только через последовательность
-зарегистрированных dependency-provenance commits, каждый из которых меняет ровно package.json и
-package-lock.json. При утрате claimed writer lease используется только одновременно рекламируемый
-`task writer-credential-replace`; semantic Plan drift, разрыв chain или любой другой commit
-возвращают `doctor`.
-
-Если последний dependency-provenance recovery записан уже после mechanical audit, он объясняет
-ровно один дополнительный Task revision. Core требует, чтобы audit boundary плюс количество
-проверенных post-audit recoveries точно равнялись current revision; произвольное увеличение
-revision, неверный parent или повреждённая provenance остаются blocker.
-
-Dependency-provenance recovery beta.12.1 также сохраняет ранее закоммиченные Task-local поля
-manifest/lock, даже если base их не содержит. Candidate остаётся dependency-only: после удаления
-только Workflow dependency parent и HEAD обязаны совпасть по всем product-owned полям.
-
-beta.11 `task plan-integrity-recover` существует для одного первого checks-failed legacy/late case:
-отсутствует exact root npm script и текущий Step не может изменить package.json. Recovery не меняет
-worktree или Plan и не создаёт synthetic second failure; он записывает bound `replan-required`.
-
-beta.12.6 различает другой случай: активный downstream proof оставил изменения в собственном scope и
-показал необходимость исправить completed transitive predecessor. Fresh `next` вместо невозможного
-`step-complete` рекламирует `task downstream-proof-recover`. Atomic transition сохраняет dirty files и
-HEAD, переносит predecessor commits в historical `invalidatedStepCommits`, очищает только stale Step evidence,
-yield C1 и возвращает ту же Task к новому Plan/risk audit/authorization. Unrelated dirty file,
-non-predecessor ownership, повреждённый journal или unregistered commit fail closed.
-
-Если старая версия не может установить этот fix из-за running Step/dirty preflight, beta.12.6
-добавляет отдельный update bridge. После двух exact dependency-only commits на active base и Task
-branch Core проверяет Task history на `HEAD^`, candidate на `HEAD`, все version surfaces, отсутствие
-leases/transactions, predecessor ownership и content hash dirty set. Переход регистрирует только
-dependency commit, не меняет product bytes/Step и делает обычный `task downstream-proof-recover`
-достижимым до manifest-induced Knowledge refresh. Это не общее разрешение dirty update.
-
-beta.12.7 закрывает следующий доказанный Signal case: beta.12.6 уже выполнила downstream-proof
-invalidation, но последующее Project Knowledge approval механически вернуло старый двух-Step Plan в
-`awaiting_execution_authorization`. Read-only `update downstream-proof-replan-update-preflight`
-сначала связывает exact beta.12.6 revision, HEAD, шесть dirty paths и content hash. После двух
-dependency-only commits `update downstream-proof-replan-dependency-preflight/recover` регистрирует
-только новый Workflow HEAD. `task downstream-proof-replan-recover` затем атомарно возвращает ту же
-Task в `needs_fix`; stale Knowledge можно reconciliate/approve, но fresh `next` всё равно требует
-новый `task plan-set`. Новый Plan может передать сохранённые bytes только одному Step, который владеет
-всем dirty set. `task run` принимает carryover лишь при exact HEAD/path/hash match, после чего Step
-проходит обычные checks, Core-owned commit и strict review.
-
-beta.12.9 закрывает исторический provenance gap corrective replan. Новые replan transitions автоматически
-переносят evidence commits исключённых Steps в `invalidatedStepCommits`. Для уже существующего gap Core
-требует один неожиданный commit, complete passed strict-review chain, verified reviewer attestation и
-совпадающий прежний final acceptance. Если пакет уже зарегистрирован, recovery меняет только Task state.
-Если exact beta.12.9 dependency commit ещё находится в HEAD, отдельный update compatibility route
-регистрирует dependency и historical authority одной revision. Оба пути сохраняют dirty bytes текущего
-Step, не переписывают Git и завершаются fresh обычным `step-complete` flow.
-
-beta.12.11 закрывает иной класс тупика до начала выполнения. Если current Plan Risk Audit required Task
-записал `stop-escalate`, потому что нужной upstream capability нет в scope этой Task, Core рекламирует
-audited remediation. Coordinator сначала формализует capability обычным Discovery. Затем одна Project
-transaction append-only создаёт required remediation Task на exact merged predecessor frontier исходной
-Task, добавляет dependency blocked -> remediation и сохраняет все Milestone semantic fields и старые
-memberships. Scope-change event связан с Task revision, Brief/Plan и audit hashes; повторное применение
-того же audit невозможно. Текущая Milestone execution authorization и audit выводят
-`corrective-derived` authority для Task authorize/accept без нового Human gate. Remediation Task проходит
-обычный Plan, audit, C1, commits и reviews. После её merge исходная Task обязана заменить отвергнутый Plan,
-пройти fresh audit и продолжить Step. Final Milestone acceptance не выводится автоматически.
-
-Dependency-only update не должен создавать промежуточный Human gate. Если stale Knowledge отличается
-только content hash `package.json`, все package surfaces уже равны runtime version, checkout clean, а
-каждый Git commit, менявший `package.json` после approved hash, затрагивает ровно manifest/lock и только
-Workflow pin, Core переносит reconcile и `corrective-derived` approval внутрь той же atomic remediation
-transaction. Изменение любого другого Knowledge source, classification, gap или conflict fail-closed
-остаётся в обычном явном approval flow.
-
-beta.12.12 закрывает доказанный runtime Plan-integrity gap. Mechanical feasibility теперь статически
-распознаёт repository-local `node <runner> affected`, когда исходник runner явно требует selector,
-и блокирует authorization для `npm run <script>` без `--base`, `--head` или `--files`. Для уже начатой
-Task recovery связывает не только первую, а всю последовательную checks-failed history, точный Plan,
-manifest/runner hashes, HEAD и dirty allowlist. Exact beta.12.11 update bridge сохраняет product bytes,
-регистрирует только dependency commit и атомарно обновляет Knowledge, если изменился только Workflow pin.
-Результат — один `replan-required` decision и обычный corrective replan с исполняемой check command;
-повтор старой команды, ручной commit product files и state editing не допускаются.
-
-beta.12.15 устраняет следующий доказанный разрыв этого пути. 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 updates после corrective yield могут
-перенести ту же compatibility на новый HEAD: Core идёт назад до последнего зарегистрированного system
-commit, проверяет каждый промежуточный commit как exact manifest/lock-only Workflow pin update и
-атомарно регистрирует всю цепочку. Любой product diff, разрыв parent chain или изменённый worktree
-fail-closed. 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.
-
-beta.12.16 закрывает следующий доказанный разрыв: migration Step мог владеть новой SQL migration,
-manifest и bootstrap, но не владеть TypeScript-модулем, который direct import из обязательного check
-использовал как независимую SHA/catalog authority. Новый `wf2.check-support-anchor@1` блокирует такой
-Plan до execution authorization. Для уже выполняемой Task после первого `checks-failed` Core связывает
-Plan/Step/HEAD, полный dirty set, runner/support hashes, direct import, отсутствующий declared output и
-существующие anchors. Если доказательство однозначно, append-only decision `continue-fix` выдаёт только
-один exact support path как effective Step scope. Human replan не нужен, Plan hash и product bytes не
-меняются, а Worker envelope, Core commit и sealed review packet явно используют и раскрывают derived
-scope. Indirect import, dynamic shell, forbidden path, unrelated dirty file или отсутствие SHA anchors
-fail-closed и не расширяют authority.
-
-beta.12.17 закрывает transport-разрыв перед этим recovery: внешний runner больше не ожидает один
-зашитый source release. Он выводит exact beta.12 source из declared dependency, требует равенства
-locked, installed, current Task branch и active Milestone base и допускает только patch от .11 до
-версии ниже runner. Dirty scope, отсутствие lease/transaction и dependency-only Git transport
-остаются обязательными; product bytes и Workflow state вручную не изменяются.
-
-beta.12.18 закрывает следующий post-rebind разрыв. Исторический check-support event остаётся валиден
-по Plan hash, при котором был создан, даже если новый Plan теперь прямо владеет derived support path.
-External preflight допускает продолжение только при одном таком event, неизменных dirty bytes,
-отсутствии активного Step/lease/transaction и полном explicit scope adoption в planned Step. После
-dependency-only transport Core заново связывает Knowledge и authorization; старый event не создаёт
-скрытой authority и не модифицируется задним числом.
-
-beta.12.19 закрывает оставшийся execution-boundary разрыв. Успешные transport, rebind, PRA и
-authorization больше не заканчиваются рекламируемым, но невыполнимым `task run`: `next` и `runStep`
-используют одну проверку registered recovery commit, exact dirty paths/content hash, historical
-decision, Plan/rebind ancestry и current Step ownership. Совпадение разрешает только принятие уже
-доказанных байтов; любое отличие блокирует запуск и не создаёт lease или commit.
-
-Docker socket `EPERM` в sandbox не является доказательством сломанного daemon. Gateway один раз
-повторяет exact health probe или Plan check с sandbox escalation без расходования remediation attempt.
-Restart Docker Desktop требует отдельного разрешения и допустим только после escalated daemon failure.
-
-> **Стоп P04-A:** `split-required` возвращает `STRUCTURAL_REPLACEMENT_REQUIRED` и `structuralReplacementAvailable=false`. Нельзя вызывать retained replacement command, потреблять replacement Discovery или вручную менять topology. Продолжение возможно только после P04-B/P05.
-
-# 10. Operational checklist
-
-- exact package version установлен, bundled gateway соответствует release и переустановлен;
-- handshake подтверждает `packageVersion=2.0.0-beta.13.9`, protocol 2, state schema 2 и beta.13
-  capabilities;
-- routine observation начинается с компактного `status`; `status --full` запрашивается только для
-  расследования, которому действительно нужна полная historical projection;
-- каждый mutation следует свежему `status -> next` и exact option contract;
-- Docker permission failure сначала классифицируется как sandbox boundary, а не как infra retry;
-- semantic unknowns и human gates не маскируются delegation;
-- Task chats создаёт coordinator; CLI получает только local-vault references и никогда не bearer secret;
-- Reviewer packet прошёл runtime preflight и явно связан с `ordinary` либо `security` mode;
-- production-edge contract трактуется как structural admission, а не как product acceptance;
-- advertised route имеет Signal-observed matrix binding либо явно помечен unsupported;
-- dependencies, progress и review posture берутся из Core projections;
-- local state не редактируется вручную; release и package update выполняются только после safe preflight и обязательных checks.