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

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

@@ -1,508 +0,0 @@
----
-title: Codex Workflow V2: delegated chat-only guide
-subtitle: Актуальный beta.13 путь от нового Discovery до принятого Milestone без ручного CLI
-part: Часть 2 из 3 | Практика
-document_version: 2.0
-date: 2 сентября 2026
-subject: Практическое руководство по delegated Discovery и Milestone в Workflow V2 beta.13
----
-
-# 1. Рабочая модель beta.13
-
-Пользователь работает в одном Codex Project и формулирует продуктовый outcome. Coordinator выполняет
-CLI, создаёт отдельные Task/Reviewer chats и ведёт supervision loop. Workflow Core остаётся authority
-для lifecycle, revisions, credentials, dependencies и Git commits.
-
-> **Золотое правило:** текст промпта задаёт intent и ограничения, но не разрешает transition. Перед каждой мутацией агент использует exact project-local package, успешные `status` и свежий `next`.
-
-Delegated mode уменьшает количество approval pauses, но не делегирует смысловые продуктовые решения.
-Blocking unknown, scope change, grant issuance или unrecoverable integrity conflict возвращаются
-пользователю.
-
-## 1.1. Что делает пользователь
-
-- подключает правильную папку как primary project folder;
-- задаёт outcome, scope, acceptance и ограничения;
-- отдельным сообщением подтверждает DGA/MAC issuance codes;
-- отвечает на semantic unknowns и human-only scope changes;
-- проверяет terminal Result и при необходимости отзывает grant.
-
-## 1.2. Что делает Coordinator
-
-- проверяет AGENTS.md, exact package, handshake, status и next;
-- проводит Discovery без materialization при blocking unknowns;
-- собирает complete Milestone Plan с explicit dependencies;
-- создаёт Task chats just-in-time через project registry;
-- передаёт только host-local credential references; bearer secrets не читает и не помещает в CLI/chat;
-- supervises routed Task до terminal Workflow state;
-- выполняет Milestone validation и exact final gate.
-
-# 2. Подготовка проекта перед новым Discovery
-
-1. Убедитесь, что checkout чистый и выбран правильный repository root.
-2. Установите beta.13 как точную devDependency после публикации release.
-3. Обновите и переустановите bundled `codex-workflow-gateway` этого release.
-4. Проверьте, что declared и installed package versions равны.
-5. Запустите новый Coordinator chat, не fork старого Milestone conversation.
-
-```text
-Минимальная session sequence агента:
-
-AGENTS.md
--> project-local gateway resolution
--> gateway handshake
--> status              # compact projection по умолчанию
--> status --full       # только для обоснованного historical investigation
--> next
--> doctor только как дополнительная диагностика
-```
-
-Handshake beta.13.5 должен сообщать `packageVersion=2.0.0-beta.13.5`, `protocolVersion=2`,
-`stateSchemaVersion=2`, dependency DAG, initial Plan transaction, mechanical feasibility,
-Milestone autonomy, host-safe credential reference, failed-Step continuation transaction,
-cause-bound rolling refinement, structural production edge, compact status, reviewer runtime preflight,
-explicit review mode, observed-route matrix и structural replacement disabled capabilities.
-
-# 3. Два уровня delegation
-
-Для нового `AUTO` Milestone до появления MS-ID может понадобиться короткий project-scoped DGR.
-Он используется только для allow-listed approval transitions, которые fresh `next` признал eligible.
-После полного initial Milestone Plan предпочтителен bounded Milestone Autonomy Contract.
-
-| Фаза | Authority | Назначение |
-|---|---|---|
-| До entity ID / во время Discovery | Human intent, опциональный project DGR | Knowledge Map и exact allow-listed approvals |
-| Complete initial Milestone Plan | Human `MAC-*` confirmation | Выдать bounded Milestone autonomy grant |
-| Task execution | C1 handoff/claim и Core routing | Не использует approval grant как writer credential |
-| Semantic change | Human scope-change gate | Outcome, success signal, checks, acceptance, discovery, base |
-| Audited pre-execution remediation | Core-derived, без нового Human gate | Только один upstream Task и одна dependency edge; semantic fields неизменны |
-
-## 3.1. Опциональный bootstrap DGR для AUTO
-
-Grant issuance всегда занимает два пользовательских сообщения. Agent не может сам выдать, расширить
-или продлить grant.
-
-```text
-ПОДГОТОВКА POLICY В ОТДЕЛЬНОМ ЧАТЕ
-
-Подготовь краткоживущую delegated approval policy для нового AUTO Milestone.
-Principal: user:owner.
-Delegate: agent:milestone-coordinator.
-Scope: текущий project.
-Разрешённые transitions перечисли явно и минимально из:
-project_memory.approve,
-milestone.execution_authorize,
-milestone.final_accept,
-task.execution_authorize,
-task.final_accept.
-
-Выполни только delegation prepare. Покажи полный scope, transitions,
-expiresAt, policyHash и DGA-code. Остановись. Grant в этом turn не выпускай.
-```
-
-```text
-ОТВЕТ ПОЛЬЗОВАТЕЛЯ СЛЕДУЮЩИМ СООБЩЕНИЕМ
-
-Одобряю exact policyHash <POLICY-HASH> и DGA-code <DGA-CODE>.
-Выпусти grant, затем покажи DGR-ID, delegate, scope, transitions,
-expiresAt и revision.
-```
-
-Перед использованием DGR Coordinator выполняет `delegation show` и сверяет project, active status,
-delegate, scope, transitions и expiry. DGR передаётся только если тот же `next` вернул exact
-`delegatedApprovalOptions` для этого grant и transition.
-
-# 4. Копируемый prompt: новый delegated Discovery
-
-Этот prompt запускает Coordinator. Пользователь не должен заранее открывать Task chats или назначать
-их номера.
-
-```text
-НОВЫЙ COORDINATOR CHAT
-
-Проведи новый Milestone через Codex Workflow V2 beta.13 в delegated режиме.
-Repository: <ABSOLUTE-REPOSITORY-ROOT>.
-Milestone ID: AUTO.
-Delegate actor: agent:milestone-coordinator.
-Bootstrap delegation grant: <DGR-ID или NONE>.
-
-Пользовательский outcome: <OUTCOME>.
-Начальные ограничения: <CONSTRAINTS>.
-
-Начни с AGENTS.md, exact project-local gateway, handshake, status и next.
-Проверь declared/installed package version и protocol/state schema. Если
-указан DGR-ID, выполни delegation show и проверь его точные bindings.
-Не создавай, не расширяй и не продлевай grant.
-
-Проведи Discovery: outcome, success signal, scope, out-of-scope,
-acceptance, constraints и blocking unknowns. Не materialize сущности,
-пока остаётся semantic ambiguity. Не принимай продуктовые решения за
-пользователя.
-
-После готового Discovery следуй только fresh next. Во время milestone
-initial-assembly materialize все intended linked Tasks, затем один раз
-опубликуй complete Milestone Plan. Для каждой membership явно укажи
-required/waived/cancelled, reason и dependsOnTaskIds, включая [] для
-независимой Task. Не выводи dependencies из ordinal или названия.
-
-Когда fresh next предложит milestone autonomy-prepare, подготовь один
-bounded Milestone Autonomy Contract, покажи полный semantic binding,
-expiry, policyHash и MAC-code и остановись. Не выполняй autonomy-grant
-в том же turn.
-
-После отдельного exact human confirmation продолжай как active
-Coordinator. Создавай Task chats just-in-time как новые standalone Codex
-tasks через project chat registry, никогда fork/handoff текущего чата.
-Передавай только закрытый TaskContextPacket без transcript и bearer
-credentials. Supervise routed Task до terminal Workflow result, затем
-проверяй status, next и milestone progress перед следующей Task.
-
-Используй C1 handoff/claim только через claim/writer credential references,
-external-sealed reviewers с explicit ordinary/security mode и exact recovery
-routes. Не запрашивай и не печатай claim/writer tokens. Для обычного review
-используй ordinary mode и не запускай implicit security scan. При split-required остановись на
-STRUCTURAL_REPLACEMENT_REQUIRED: P04-A replacement не реализует.
-
-После merge всех required Tasks выполни Milestone validation на чистом
-base HEAD. Final acceptance выполняй только по exact eligible grant и
-текущему MSA-code; иначе покажи полный requiredHumanGate и остановись.
-```
-
-<!-- pagebreak -->
-
-## 4.1. Что должно получиться до autonomy gate
-
-- Discovery без blocking unknowns;
-- materialized Milestone и все intended linked Tasks;
-- complete membership Plan без reverse-membership gaps;
-- explicit `dependsOnTaskIds[]` для каждой membership;
-- checks и acceptance, связанные с outcome и success signal;
-- один свежий `next`, рекламирующий `milestone autonomy-prepare`;
-- MAC policy с principal, delegate, expiry, semantic scope hash и code;
-- отсутствие product Step execution в Coordinator chat.
-
-## 4.2. Подтверждение Milestone Autonomy Contract
-
-```text
-ОТВЕТ ПОЛЬЗОВАТЕЛЯ В СЛЕДУЮЩЕМ СООБЩЕНИИ
-
-Одобряю показанный Milestone Autonomy Contract для <MS-ID>,
-policyHash <POLICY-HASH>, semanticScopeHash <SCOPE-HASH>
-и MAC-code <MAC-CODE>. Выполни только рекламируемый autonomy-grant
-с этими exact bindings и продолжи Milestone supervision.
-```
-
-Если fresh `next` изменил revision, Plan hash, policy hash или MAC-code, старое подтверждение нельзя
-использовать. Coordinator показывает новый gate.
-
-# 5. Initial assembly и dependency routing
-
-Во время initial assembly Coordinator выполняет последовательные checkpoint pairs. После каждой
-mutation он ждёт успешный `status`, затем fresh `next`. Параллельный status/next и direct closing
-`milestone plan-set` после failed checkpoint запрещены.
-
-```text
-Discovery materialize Milestone
--> next: milestone initial-assembly
--> linked Task Discovery start/update/materialize
--> status -> next
--> повторить для intended membership
--> один complete milestone plan-set
--> autonomy prepare / direct authorization
-```
-
-P04-A вычисляет полный runnable set. Task может стать actionable только когда каждый declared required
-predecessor merged. Sequential scheduler выбирает из runnable set, но не добавляет искусственные edges.
-
-Coordinator печатает `milestone progress` после старта/resume, каждой terminal/attention Task boundary и
-membership change. Таблица берётся из Core, а не из памяти чата.
-
-# 6. Автоматическое создание Task chats
-
-Coordinator создаёт Task chat только когда repository-level `next` назвал exact actionable Task.
-Нельзя заранее создавать пустые chats для всех memberships.
-
-Registry title имеет одну из форм:
-
-```text
-#NNN · M<NN>/T<NN> · Task · <Task title> · <TASK-ID>
-#NNN · M<NN>/T<NN>/S<NN> · Step Review A<N> · <Step title> · <TASK-ID>
-#NNN · M<NN>/T<NN> · Final Review A<N> · <Task title> · <TASK-ID>
-```
-
-TaskContextPacket содержит только repository root, exact package requirement, Milestone/Task IDs и
-ordinals, Task revision/title/objective, requirement/acceptance IDs, Brief/Plan hashes, нужный actor/grant,
-Task-local scope/checks/stop conditions и обязательную session sequence. В packet никогда не включаются
-Coordinator transcript, sibling Plans, reasoning, confirmation codes или credentials.
-
-Task chat продолжает через planning, execution, reviews, recovery, acceptance и merge, пока fresh
-navigation разрешает действия. На blocker/terminal boundary он возвращает non-secret CoordinatorReport.
-
-# 7. C1 writer credentials
-
-Credential и approval grant решают разные задачи.
-
-1. `task handoff-prepare` возвращает публичную `claimCredentialReference`, связанную с project, Task,
-   target actor, action и expiry.
-2. Coordinator передаёт reference целевому Task chat; underlying secret остаётся в host-local vault.
-3. Target Task actor выполняет exact `task claim --claim-credential-ref <CREF-...>`; successful claim
-   consumes одноразовый reference.
-4. Claim проверяет dependency binding и возвращает `writerCredentialReference`, а не plaintext token.
-5. `task run` и другие lease-bound действия принимают только `--writer-credential-ref` согласно fresh
-   `next.writerTokenContract` и обновляют lease без вывода secret.
-6. `task step-complete`, review record и другие guarded mutations используют только рекламируемый option.
-7. После passed final review `task result-set` использует active writer reference и освобождает lease до
-   `awaiting_final_acceptance`; Human gate не должен удерживать credential.
-8. После acceptance старый reference не используется: fresh `next` рекламирует
-   `task writer-credential-replace`, затем разрешает merge или merge confirmation.
-
-Vault file обязан быть regular и mode `0600`. CLI проверяет reference binding и не выводит secret в
-argv, stdout, stderr, error, packet или evidence. Legacy `--claim-token`/`--writer-token` запрещены.
-Нельзя искать token в payload fields или заменять reference redacted fingerprint. Потеря reference не
-разрешает новый handoff либо lease acquisition вне fresh recovery route.
-
-# 8. Plan, Knowledge Map и mechanical feasibility
-
-Перед `task plan-set` Planner копирует exact requirement/acceptance IDs из `next.taskPlanContract`.
-Каждый Step объявляет dependencies, exact outputs, allowedWrites, forbiddenScope и executable checks.
-Knowledge files, которые будут созданы, указываются как exact `knowledgeTargets`.
-
-Plan Risk Audit определяет guarded Steps до execution. Fresh authorization запускает bounded mechanical
-analyzers. Подтверждённое противоречие, например отсутствующий exact root npm script без ответственного
-manifest writer, возвращает Plan на `task plan-set` без authorization write.
-
-`unverified` analyzer result не доказывает Plan и не блокирует unsupported semantics. Planner и human/delegate
-approval остаются ответственными за смысловую достаточность.
-
-Если независимая PRA классифицирует consumer multi-Step Task как `runtime-composition`, Plan обязан
-включить `requiresProductionEdges=true` и назвать transitive owner Step, consumer Step и exact executable
-check consumer. Пропуск flag или edge planner'ом не отключает gate; простой one-Step runtime исключён.
-При failed check beta.13 может добавить доказанный transitive component-owner path в
-effective scope той же Task только внутри затронутой component boundary и без изменения objective,
-requirements, acceptance или security boundary. Это structural admission: оно не доказывает product
-truth, не заменяет фактический check/review и не заявляет реализацию P02 Step-validity authority.
-
-В beta.13.1 production-edge authority применяется prospective. Новые ordinary/corrective PRA получают
-hash-chained marker `required-v1`. Markerless PRA и Task без production-edge fields считаются legacy и не
-переписываются; content-only refresh сохраняет эту posture. Для native Task refresh обязан сохранить exact
-`requiresProductionEdges`, `productionEdges[]` и строку edge в новом Plan artifact. Не редактируй state
-вручную: после update следуй только fresh advertised reconcile/context-refresh route.
-
-# 9. Atomic context refresh
-
-Когда top-level `next.action` равен `task context-refresh`, нельзя сначала выполнять standalone
-`project-memory reconcile`. Coordinator вызывает только указанный atomic action с exact Task/map revisions,
-actor и Milestone Autonomy Grant.
-
-Core может разрешить:
-
-- content-only drift без semantic map changes;
-- exact Plan-bounded supporting-source addition, если её заранее объявил current Plan;
-- одновременные reconcile, approve, rebind и reauthorize как одну transaction.
-
-Category, scope, authority, conflicts, gaps или unsafe source changes переходят в обычный visible
-Knowledge Map approval path. Milestone grant не разрешает standalone map approval.
-
-# 10. External-sealed review
-
-В Codex App нельзя запускать nested local reviewer как substitute для независимого процесса.
-Это правило действует и для release E2E: реальный Task agent должен использовать отдельный App reviewer
-через external-sealed packet/record, а не проверять nested native launch как production-путь.
-
-| Gate | Правильный путь |
-|---|---|
-| Guarded Step review | `step-review-packet --review-mode ordinary|security` -> новый Reviewer chat -> `step-review-record` |
-| Submitted Task review | `review-packet --review-mode ordinary|security` -> новый Final Reviewer chat -> `review-sealed-record` |
-| Explicit corrective disposition (если выбран) | Отдельный read-only Corrective/Plan Auditor chat; не attempt-count gate |
-
-Reviewer получает неизменённый packet, проверяет exact commit/diff/evidence и возвращает closed JSON.
-Task chat записывает его только при совпадении packet и repository seal hashes. Reviewer не исправляет код,
-не применяет grant и не принимает Result.
-
-Для native reviewer closed JSON задаётся API-compatible strict Structured Output schema: все properties
-обязательны, а необязательные значения finding явно nullable. Неполный или семантически противоречивый
-ответ считается unverified и не создаёт remediation authority.
-
-Перед packet Core выдаёт reviewer-runtime preflight: exact Node/Workflow provenance, совпадение declared,
-locked и repository-local installed versions, hash-verified runtime build manifest и writable temporary
-cache вне sealed checkout. Перед каждым packet preflight заново с диска разрешает recursive runtime
-dependency graph по parent-aware, nested-first правилам Node и сверяет exact package manifests и SHA-256
-attested runtime-файлов. Уже прогретый module cache не скрывает удалённую, подменённую, конфликтующую или
-symlink-redirected dependency. После disk attestation preflight синхронно загружает exact installed
-gateway, reviewer и workflow graph; общий с CLI gateway descriptor подтверждает exact
-package/protocol/schema. Отдельный child process, timeout/retry и cached trust decision не используются;
-raw process output и argv в packet не попадают. Preflight ничего не устанавливает и не изменяет checkout.
-Missing/stale build либо dependency closure, module-load failure или contract mismatch дают
-`prepared=false`: это инфраструктурный blocker, а не основание ослабить review. Для
-обычной проверки выбирайте `ordinary`: implicit security scan запрещён. `security` выбирается только
-когда security-focused review запрошен явно; mode связан с packet hash.
-
-Каждый finding по возможности получает stable `causeId`, описывающий первопричину без номера попытки.
-Distinct cause продолжает ту же Task без лимита циклов. Повтор одной authoritative причины требует
-root-cause replan только для mechanically normalized check failure либо того же reviewer `causeId` с
-`planConflict=true`. Сходство текста, число итераций и reviewer `causeId` без Plan conflict не создают
-replan authority.
-
-# 11. Recovery без micro-patching
-
-| Состояние | Действие |
-|---|---|
-| Step check failed с allowlisted dirty bytes | Beta.13 одной transaction сохраняет hashes и Task `needs_fix`, освобождает lease и не меняет product bytes; затем fresh credential replacement и continuation той же Task |
-| Новый distinct cause после fix/review | Продолжить ту же Task без numeric hard stop и выполнить новый strict review |
-| Повтор mechanically normalized cause | Fresh route требует root-cause replan той же Task |
-| Повтор reviewer cause | Replan только при том же stable `causeId` и `planConflict=true`; prose similarity недостаточно |
-| Failed check указал transitive owner той же component | Только advertised evidence-bound same-Task augmentation; semantic boundary неизменна |
-| Plan требует production edge | До authorization явно указать owner, consumer и consumer-executed `checkRef`; это не product acceptance |
-| First proven impossible npm check после legacy/late authorization | Только рекламируемый `task plan-integrity-recover` |
-| Direct imported migration checksum/catalog authority вне Step scope | beta.12.16: advertised `task plan-integrity-recover`, затем тот же Step с exact derived support path; Human replan не нужен |
-| In-flight Plan-integrity Task требует package update | beta.12.19 external preflight выводит coherent exact beta.12 source из пяти version surfaces; затем только dependency-only transport и advertised recovery |
-| Новый Plan явно принял ранее derived check-support path, но старый event выглядит corrupt | beta.12.19 external preflight требует exact post-rebind scope adoption и неизменные dirty bytes; затем dependency-only transport, Knowledge rebind, PRA и fresh authorization без Human gate |
-| После rebind и authorization `next` показывает `task run`, но checkout содержит сохранённые Step bytes | Продолжать только если beta.12.19 `next` показывает `planIntegrityDirtyCarryover.state=validated`; HEAD, Plan chain, paths и content hash уже проверены Core. При `doctor` запуск запрещён |
-| Downstream proof требует изменить completed predecessor | Только `task downstream-proof-recover`, затем новый Plan/risk audit/authorization в той же Task |
-| Failed guarded review | Core атомарно освобождает exact lease; distinct cause продолжает ту же Task, а repeated authoritative cause также завершает C1 и открывает root-cause replan без Human gate |
-| Finding `route=fix` | Продолжить тот же Step; count остаётся диагностикой |
-| Finding `route=replan` с exact Plan conflict | `task plan-set`, меняются только implementation Steps |
-| `split-required` | Stop: `STRUCTURAL_REPLACEMENT_REQUIRED`, никаких replacement writes |
-| Старая версия + active downstream proof блокируют update | Только beta.12.6 exact dependency commits и advertised `update downstream-proof-dependency-recover` |
-| После downstream recovery beta.12.6 вернула отвергнутый Plan через Knowledge rebind | Только beta.12.7 replan update bridge, затем recovery и новый consolidated Plan той же Task |
-| Corrective Plan потерял authority ранее принятого Step commit | Только advertised beta.12.9 historical-Step preflight/recovery; без rebase/reset и без новой Task |
-| Exact beta.11 attempt-four `stop-escalate` | Только advertised prepare, затем отдельный Human-confirmed apply; исходный stop сохраняется |
-| Pre-execution `stop-escalate` + `auditedRemediation` | Discovery -> `milestone remediation-materialize` -> новый upstream Task -> merge -> replan исходной Task |
-| Любой другой explicit `stop-escalate` | Terminal user attention |
-| Stale dependency binding | Новый handoff/claim только по fresh `next` |
-| Review seal drift | Discard review и создать fresh packet |
-
-Plan-integrity recovery не редактирует Plan, package.json или worktree и не синтезирует второй failure.
-Для beta.12.16 check-support evidence fresh `task run` обязан показать `boundedEffect=record-machine-derived-check-support-scope`
-и добавить ровно рекламируемый support path в Worker `allowedWrites`. Для иных Plan-integrity видов
-сохраняется `replan-required` route.
-P04-A не переносит completed Steps и не rewires dependencies при split.
-
-Audited remediation beta.12.11 не является generic scope-change. Coordinator использует только exact
-route из fresh `next`: создаёт Discovery для доказанной отсутствующей upstream capability, доводит его
-до ready и вызывает `milestone remediation-materialize` с текущими revisions и exact
-`requiredPredecessorTaskIds`. Core не принимает новый Milestone Plan: сохраняет outcome/success signal,
-acceptance/checks и старые memberships, append-only добавляет один required Task и делает исходную Task
-зависимой от него. Новый Task получает приоритет. Его `task authorize` и `task accept` используют только
-`correctiveDerivedApproval.actor` с `humanApprovalRequired=false`; Worker, checks, commits и reviews
-остаются обычными. После merge fresh `next` возвращает исходную Task к `task plan-set`, свежему Risk
-Audit и как минимум следующему Step. Dirty checkout, lease/transaction, stale audit, started Task,
-неполный predecessor frontier или повторное использование audit означают hard stop.
-
-После обновления package fresh `next` может добавить
-`auditedRemediation.dependencyKnowledgeRefresh`. Продолжайте без Human approval только при
-`eligible=true`: Core доказал clean checkout, exact aligned version surfaces, единственный изменённый
-Knowledge path `package.json` и dependency-only Git chain. Refresh будет применён атомарно во время
-`milestone remediation-materialize`. Если объект отсутствует или содержит blockers, не маскируйте
-документационный/product drift под update — используйте обычный Project Knowledge flow.
-
-`task downstream-proof-recover` также не редактирует product files и не создаёт новую Task. Он сохраняет
-dirty worktree/HEAD, append-only фиксирует invalidated predecessor evidence, освобождает C1 и возвращает
-текущую Task к `task plan-set`. Если fresh `next` не рекламирует этот переход, вызывать его нельзя.
-
-Если этот переход доступен только после update, не stash/reset product work. Обновите active base в
-отдельном worktree и текущую Task branch двумя отдельными commits только `package.json`/lock, установите
-beta.12.6 и требуйте от fresh `next` `update downstream-proof-dependency-recover`. Read-only preflight
-должен вернуть `eligible=true`, exact `HEAD`/`HEAD^`, Task revision, пустые blockers и content-hash
-binding dirty set. Recover регистрирует только dependency HEAD; следующий fresh `next` должен вернуть
-обычный `task downstream-proof-recover`. Любой иной diff/history/dirty path/lease означает stop.
-
-Для beta.12.9 historical-Step blocker обновите base в отдельном worktree и Task branch двумя commits
-только package/lock. После install продолжайте лишь при advertised `update historical-step-dependency-recover`
-и preflight, связавшем HEAD/parent, passed+accepted historical SHA, Plan/Step, dirty hash и отсутствие lease.
-Recover сохраняет product bytes; затем обязательны `status -> next -> task step-complete`. Если package
-уже зарегистрирован, используйте advertised `task historical-step-provenance-preflight/recover`.
-
-Для beta.12.11 Task, застрявшей на selector-required `npm run validate:affected` без selector, сначала
-остановите Worker и дождитесь отсутствия active/stale lease. Внешний exact beta.12.12 runner допускается
-только для read-only `update plan-integrity-update-preflight`; требуйте `eligible=true`, exact failed Step,
-полную remediation history и неизменённый dirty allowlist. После единственного dependency-only commit
-на base и Task branch fresh repository-local `next` должен рекламировать
-`update plan-integrity-dependency-recover`. Recovery атомарно регистрирует commit и dependency-only
-Knowledge refresh. Затем выполните advertised credential recovery, `task plan-integrity-recover` и
-`task corrective-yield`. Replacement Plan меняет только неисполняемую check на
-`npm run validate:affected -- --files=<Step allowedWrites>` и проходит fresh Plan Risk Audit до нового run.
-
-Если update произошёл уже после `task corrective-yield`, beta.12.15 допускает только advertised
-`update plan-integrity-dependency-recover`. Между последним зарегистрированным recovery commit и HEAD
-может быть один или несколько пропущенных package updates, но каждый обязан менять ровно
-`package.json`/`package-lock.json`, только exact Workflow pin и образовывать непрерывную parent chain.
-Core атомарно регистрирует всю доказанную цепочку; failed Step, Plan, remediation IDs, dirty paths и
-dirty SHA-256 должны полностью совпадать. После recovery снова запросите `status -> next`; ожидаемый
-route остаётся `task corrective-replan-prepare`.
-Если новый package сначала сообщает `TASK_TRANSACTION_INTEGRITY_FAILED` только для terminal
-corrective-replan journals предыдущего release, не repair/delete/edit state. beta.12.15 читает лишь
-точно зарегистрированные completed manifest/runtime/catalog tuples; pending либо неизвестный tuple
-остаётся блокером. После установки обязательно повторите handshake и последовательные `status -> next`.
-
-Для exact beta.12.6 stranded-replan shape сначала нужен eligible read-only source preflight с exact
-revision/HEAD/dirty hash. Затем два beta.12.7 dependency-only commits и advertised dependency/replan
-recoveries. После Knowledge refresh `next` обязан остаться на `task plan-set`; новый единый Step должен
-владеть всем dirty set, а `task run` требует `downstreamProofCarryover.state=validated`.
-
-Ошибка Docker socket/CLI `EPERM`, `operation not permitted` или `permission denied` в sandbox не считается
-падением daemon и не расходует retry. Повторите exact read-only probe или Plan check один раз с sandbox
-escalation. Не перезапускайте Docker Desktop и не меняйте image без отдельного разрешения и подтверждённого
-escalated daemon failure.
-
-После stop override выполняйте только advertised context/dependency recoveries и каждый раз повторяйте
-`status -> next`; attempt 4 требует `stopOverrideContextRebind.state=validated`. Lost credential
-восстанавливает только advertised exact claimant route. Semantic drift, broken chain, необъяснённый HEAD
-или revision означают stop; продолжение разрешено только когда fresh `next` сам вернул `task run`.
-
-## 11.1. Наблюдение и route boundary beta.13
-
-Для routine supervision используйте compact `status`: он показывает active Task/Step, action,
-blockedAction, observation reasons и stable route fingerprint без всей historical state. `status --full`
-запрашивайте только для конкретного расследования, которому нужны полные entity arrays.
-
-Каждый fresh `next` связывает action с versioned matrix v2 для 13 классов, наблюдавшихся в Signal.
-У каждого класса есть unique priority и один exact production-transition witness либо real terminal
-observation. Это не обещание, что E2E прошла каждая action: action-level metadata явно сообщает
-`executable-witnessed`, `unwitnessed` или `unsupported`. Unsupported action — manual/terminal boundary,
-а не приглашение составить команду по догадке. Boundary
-`signal-observed-route-class-witnesses` намеренно не утверждает полноту всей state machine; неизвестный
-будущий route остаётся blocker.
-
-# 12. Milestone final acceptance
-
-После merge всех required Tasks Coordinator проверяет clean base HEAD и выполняет рекламируемую
-Milestone validation. `next` возвращает revision, Plan/Result/evidence hashes, validated HEAD и MSA-code.
-
-При active eligible `milestone.final_accept` grant delegate может применить current code в том же turn:
-контролирующим human decision является прежний grant issuance. Если exact option отсутствует, Coordinator
-показывает полный `requiredHumanGate` и останавливается до следующего сообщения пользователя.
-
-# 13. Standalone Task
-
-Standalone Task не использует Milestone dependency DAG или Milestone Autonomy Contract. Она начинает с
-Discovery, следует Task Plan/authorization/C1/review lifecycle и использует direct human gates либо exact
-Task/project DGR. `dependencyBinding` для standalone handoff равен null.
-
-# 14. Итоговый checklist пользователя
-
-- beta.13.1 exact package и новый bundled gateway установлены; handshake показывает
-  `packageVersion=2.0.0-beta.13.5`, protocol/state schema `2/2` и beta.13 capabilities;
-- новый Coordinator chat не является fork старого Milestone;
-- bootstrap DGR, если нужен, выдан отдельным exact human confirmation;
-- Discovery не materialized при blocking unknowns;
-- complete initial Plan содержит dependencies для каждой membership;
-- Milestone Autonomy Contract подтверждён отдельным MAC turn;
-- Coordinator сам создаёт и supervises Task/Reviewer chats;
-- только credential references появились в CLI/chat; bearer secret отсутствует в argv/output/errors,
-  prompts, reports и evidence, а vault file имеет mode `0600`;
-- routine observation использует compact `status`; full projection запрашивается только через `--full`;
-- reviewer runtime preflight подготовлен, а каждый packet имеет explicit `ordinary` или `security` mode;
-- distinct findings продолжают ту же Task без numeric cap, repeated authoritative cause ведёт к
-  root-cause replan, а attempt number/prose similarity не используются как authority;
-- transitive component owner и production edge остаются structural admission, а product truth
-  подтверждается фактическими checks/reviews/acceptance;
-- route metadata находится в Signal-observed matrix; unsupported action не превращается в invented CLI;
-- каждый transition пришёл из fresh `next`;
-- beta.11 stop override, если рекламировался, прошёл отдельные prepare и user-confirmed apply без journal rewrite;
-- downstream predecessor recovery, если рекламировался, сохранил worktree и завершился новым Plan authority;
-- active-proof package bridge, если понадобился, зарегистрировал только exact dependency HEAD перед recovery;
-- stranded-replan bridge, если понадобился, завершился новым Plan и полным Step checks/review, а не только сменой navigation;
-- historical-Step recovery, если рекламировался, сохранил exact accepted commit и довёл текущий Step до обычного `step-complete` без history rewrite;
-- split-required остановился без replacement mutations;
-- Milestone validation и final acceptance связаны с текущим clean base HEAD.