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

package/docs/updating-existing-project.md

@@ -1,726 +1,28 @@
-# Обновление Workflow V2 в начатом проекте через Codex
+# Updating the one supported consumer
 
-Эта инструкция предназначена для проекта, где Workflow V2 уже создал Discovery, Tasks или
-Milestones. Пользователь не выполняет команды самостоятельно: все проверки, установка и
-Git-операции поручаются Codex.
+Only the latest package is maintained. The installed dependency remains an exact version, and declared, locked, installed and relevant Git bindings must agree. This is reproducibility, not support for running old releases.
 
-## Что обновляется, а что сохраняется
+1. Finish or reach a supported clean boundary using the currently installed local package. Run its `update preflight`; inspect all blockers. An active Step, writer lease, pending/corrupt transaction or unclassified dirty work is not an update boundary.
+2. Select the published exact target version and install it with `--save-dev --save-exact`. Keep dependency changes separate from product changes and preserve the Task/base history required by the current preflight. Do not amend, reset or hand-edit Workflow evidence.
+3. Run the newly installed local CLI's handshake, `status`, then `next`. If Core advertises ordinary dependency provenance recovery, run its matching preflight and exact recovery. A dependency-only record never approves product work or Knowledge.
+4. Follow current Knowledge reconciliation/rebind/authorization and credential routes. Read the actual returned action and local command help; do not replay a historical version recipe or use an external old/new runner over mismatched state.
 
-Версия `codex-workflow-v2` закреплена точным значением в `package.json` и lock-файле каждого
-проекта. Поэтому разные проекты могут использовать разные версии. Обновление одного проекта
-не переключает остальные.
+If the existing state cannot reach a supported boundary, report the concrete state/HEAD and blocker. There is no general dirty-update bypass. Recovery from already recorded evidence remains bounded by its current reader; no blanket migration or consumer-state rewrite is implied.
 
-Состояние Workflow хранится отдельно от репозитория в
-`$CODEX_HOME/workflow-state/v2/projects/<project-id>`. Оно определяется идентичностью Git
-репозитория, а не версией npm-пакета. Обычное совместимое обновление заменяет зависимость и
-gateway, но не удаляет и не пересоздаёт это состояние. Уже принятые Milestones, ревизии,
-авторизации, evidence и Results сохраняются.
+## Retained navigation checkpoint update
 
-Никогда не разрешайте агенту вручную редактировать, переносить или удалять внешний state.
-Команда миграции нужна только тогда, когда документация новой версии прямо сообщает о новой
-state schema. Совпадение `stateSchemaVersion` до и после обновления означает, что миграция не
-нужна. Для alpha.6 при `stateSchemaVersion: 2` применяется не migration, а sidecar-only
-adoption posture.
+The bounded exception supports a ready/planned native `navigation-fix-dirty-carryover` checkpoint,
+one unregistered source dependency commit ending at `2.0.0-beta.13.16`, and exactly one subsequent
+target dependency commit. It requires no leases or pending operations. It does not authorize product work.
 
-### beta.13.1: legacy PRA compatibility after beta.13
+1. Obtain the exact target tarball and unpacked target runtime outside the consumer. Before transport, run that target's read-only `update navigation-source-preflight --id <Task> --tarball <artifact> --repo <consumer>`. Require `eligible=true`; retain its `receipt` object outside the checkout. The artifact must match the executing package bytes. Repair stale leases with the installed source, then repeat. An active lease must reach its supported release boundary; absence of a lease requires no repair.
+2. Only with this receipt and explicit update authorization, create one dependency-only target commit on the bound base branch in a separate checkout, and one on the Task branch directly after source HEAD. Change only the Workflow entries in package.json/package-lock.json; install the same exact tarball locally. Preserve all dirty product bytes. Do not reset, amend, stash, rewrite state or expand scope. For a live update the target must already be published and verified through the release gate; an unpublished package is permitted only in an isolated qualification scenario.
+3. Run the installed target handshake, status, next; then `update navigation-transport-preflight --id <Task> --tarball <same artifact> --file <receipt>`. Require `eligible=true` and follow its returned `update navigation-recover` with the exact revision, original claimant actor, same receipt/artifact and an explicit reason. The receipt is not authority: Core reconstructs its source proof from Git, state, sidecars, dirty bytes and target artifact. Changed or foreign evidence blocks recovery. The timestamp binds stored Task state, not an editable claim of wall-clock freshness; all evidence is revalidated against the current boundary.
+4. Recovery registers the two dependency commits in one Task-state write and sets `awaiting_execution_authorization`. It preserves original authorizations, completed Steps and C1. Follow fresh status/next through Knowledge refresh, independent audit and ordinary authorization; only fresh execution authority for the target HEAD can resume the Step. Replaying recovery after the revision changes is rejected. Preserve the source receipt with the update evidence.
 
-`2.0.0-beta.13.1` preserves the beta.13 protocol/schema `2/2` and adds no state migration. The
-structural production-edge rule is prospective: every newly written ordinary or atomic
-corrective-replan PRA receives the hash-chained `structuralProductionEdgeAuthority=required-v1`
-marker, and its current Plan must satisfy the edge contract. A markerless PRA and Task written
-before that authority existed remain readable; Workflow must not reinterpret their historical
-`runtime-composition` classification as proof that their old Plan contained beta.13 fields.
-Historical PRA events from an earlier Plan are hash/shape validated but are not compared with the
-current Plan's edges. This compatibility rule never edits, migrates or silently approves external
-state. A later Plan/PRA recorded by beta.13.1 must satisfy the full structural boundary.
+The source and target dependency transports are separate Git operations; interrupted transport is
+not a successful update. Diagnose incomplete version/base bindings rather than proceeding to execution.
 
-This does not add signed provenance to local Workflow state. A full privileged rewrite of Task
-state and its complete self-hashed sidecar chain remains outside the trust model; repository rules
-continue to prohibit manual state edits. The regression proves compatibility and fail-closed
-partial mismatch, not authenticity against the machine owner.
+The gateway plugin resolves the installed package; it does not copy Workflow assets into the consumer. Refresh its installed source through the supported plugin installation flow when the package changes, then verify a new Task loads the intended skill. Package text validation alone does not prove the App installation boundary.
 
-The normal safe-update sequence below targets exact `2.0.0-beta.13.1`. It is also the supported
-patch path from beta.13 when `status` or `next` reports `STATE_CORRUPT` solely because a markerless
-pre-beta.13 PRA lacks production-edge fields: run the old-version read-only preflight first, install
-the patch dependency-only, and resume from a fresh handshake. Never edit the PRA sidecar manually.
-
-### beta.13: coherent continuation and host-safe credentials
-
-`2.0.0-beta.13.1` сохраняет `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.1 сама по себе не
-является 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.1` без диапазона и измените только
-   `package.json` и lock-файл.
-3. Новой repository-local версией подтвердите совпадение declared, locked и installed
-   `2.0.0-beta.13.1`, прежний `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
-завис между completion commit, обязательным strict review и запрещённым Knowledge rebind,
-используйте внешний точный runner alpha.7 только для `update rescue-preflight`. Продолжать
-можно лишь при `eligible=true`; допустимы только перечисленные им `locks repair` и
-`task step-review`. Этот путь не меняет dependency и не разрешает другие команды alpha.7.
-Для `task step-review` используйте lifecycle-actor из `next` или rescue-preflight; это claimant
-или required actor, а не identity независимого reviewer-процесса.
-После terminal review выполните обычный Knowledge reconcile/rebind, доведите Task до безопасной
-границы и только затем обновляйте package/lock обычным способом.
-
-### Исключение beta.10 для retained reviewed commit
-
-Если corrective replan уже убрал evidence завершённой попытки из текущего Step, но её product
-commit остался в Git между `baseCommit` и новым dependency-only HEAD, beta.10 может штатно принять
-такую историю. Это допустимо только при полной криптографически целостной strict-review цепочке с
-решением `passed` и verified reviewer attestation. Pending/failed review, отдельный `evidence.json`,
-повреждённый sidecar или неизвестный product commit не подходят.
-
-Не регистрируйте сохранённый product commit вручную в `systemCommits`. После установки beta.10
-выполните свежий `next`; продолжайте только если он рекламирует
-`update dependency-provenance-recover`. Затем последовательно выполните read-only
-`update dependency-provenance-preflight`, проверьте `eligible=true`, точные Task revision/HEAD,
-пустой `blockers` и ожидаемый список `retainedHistoricalCommits`, и только после этого вызывайте
-рекламируемый recover с той же revision. Успешный recover записывает dependency HEAD в
-`systemCommits`, а исторические reviewed product commits — отдельно в recovery evidence. После
-него обязательны последовательные `status` и `next`; выполняйте возвращённый Knowledge reconcile
-или `task context-refresh`, если manifest/lock сделали Knowledge Map stale.
-
-В beta.12.1 preflight сравнивает parent и candidate после удаления только записей зависимости
-`codex-workflow-v2`. Поэтому ранее закоммиченные Task-local scripts и другие product-owned поля
-`package.json`/lockfile могут отличаться от Milestone base и сохраняются. Это не ослабляет сам
-candidate: его HEAD обязан менять ровно `package.json` и `package-lock.json`, только точную Workflow
-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
-checkout. Но если dirty set уже является подтверждаемым конфликтом между активным proof Step и
-completed transitive predecessor, ожидание чистой границы создаёт цикл: штатный recovery существует
-только в новой версии, а установить её до recovery нельзя. beta.12.6 разрешает только этот exact
-bootstrap и не ослабляет общий preflight.
-
-Сначала убедитесь, что нет active/stale writer lease, pending/corrupt transaction и Core operation.
-Не stash/reset/commit product files и не завершайте Step вручную. В отдельном временном worktree
-обновите active Milestone base до точной beta.12.6 и создайте commit только с `package.json` и
-`package-lock.json`. Затем в текущей Task branch установите ту же точную версию и создайте второй
-commit только из этих двух файлов, оставив существующий product dirty set неизменным. Не merge и
-не переносите product commits между ветками.
-
-Fresh project-local beta.12.6 `next` обязан вернуть
-`update downstream-proof-dependency-recover`. Выполните read-only
-`update downstream-proof-dependency-preflight --id <TASK-ID>` и продолжайте только при
-`eligible=true`, пустом `blockers`, ожидаемых `HEAD`/`HEAD^`, exact Task revision и непустом
-`activeDownstreamProof`. Binding включает current Plan, единственный active Step, все dirty paths,
-SHA-256 их содержимого и completed predecessor Steps, чья authority будет инвалидирована позже.
-После advertised recover повторите `status -> next`: ожидается `task downstream-proof-recover`,
-который имеет приоритет над Knowledge refresh, вызванным manifest/lock commit. Только после него
-выполняются новый Plan, Risk Audit, authorization и возвращённые `next` Knowledge actions.
-
-Read-only preflight является наблюдением, а не confirmation token: recover заново вычисляет и
-записывает binding текущего dirty content. Поэтому изменение допустимого product content до
-recover создаёт другой hash, который нужно сверить в ответе. После recover этот hash остаётся
-аудит-доказательством сохранённых bridge bytes; downstream-proof заново проверяет текущие paths,
-ownership и history, а новый Plan и review оценивают текущий content. Путь fail-closed при unrelated dirty path,
-неизвестном commit до candidate, candidate шире двух dependency-файлов, stale Milestone base,
-version divergence, branch/Plan/Step mismatch, lease или transaction. В этом случае не правьте
-`systemCommits` или внешний state вручную.
-
-### Исключение beta.12.7 для stranded downstream replan
-
-Это исключение применимо только если beta.12.6 уже записала downstream-proof invalidation, а затем
-Project Knowledge approval ошибочно rebound-нул отвергнутый Plan и вернул Task в
-`awaiting_execution_authorization`. До изменения dependency запустите beta.12.7 source/runtime
-read-only `update downstream-proof-replan-update-preflight --id <TASK-ID>`. Требуются
-`eligible=true`, source version `2.0.0-beta.12.6`, exact Task revision/branch/base/HEAD, неизменные
-dirty paths/content hash и пустые blockers.
-
-Затем тем же двухкоммитным способом обновите active base и Task branch только в `package.json` и
-`package-lock.json`, установите exact beta.12.7 и следуйте fresh `next`. Допустимая цепочка:
-`update downstream-proof-replan-dependency-preflight` ->
-`update downstream-proof-replan-dependency-recover` ->
-`task downstream-proof-replan-recover`. После repair manifest change обычно делает Project Knowledge
-stale: выполните рекламируемые reconcile/approve, но не `task knowledge-rebind` старого Plan. Fresh
-`next` обязан вернуть `task plan-set`.
-
-Новый Plan должен заново классифицировать весь unfinished remainder. Сохранённые dirty bytes не
-становятся completed evidence и не коммитятся административным recovery. Они могут быть приняты
-только одним planned Step, `allowedWrites` которого точно покрывает весь dirty set. Перед `task run`
-fresh `next` обязан показать `downstreamProofCarryover.state=validated`; после run обязательны checks,
-Core-owned Step commit и strict review, если Step guarded. Изменение content/path/HEAD, дополнительная
-Task revision, audit/authorization старого Plan, lease или transaction блокируют исключение.
-
-### Исключение beta.12.1 для beta.11 attempt-four stop
-
-Если beta.11 записал `stop-escalate` перед четвёртой попыткой только после последовательности
-`ordinary`, `ordinary`, `corrective`, и перед третьей попыткой уже существовал exact
-`continue-fix`, fresh `next` может вернуть `task stop-override-prepare`. Не создавайте новый
-Milestone и не редактируйте sidecar вручную. Сначала выполните только read-only prepare с exact
-Task revision, Step, human actor и содержательной причиной. Проверьте, что ответ связывает тот же
-stop decision, Plan hash, Git HEAD, все три remediation events и policy
-`beta11-attempt4-stop-compatibility-v1`, затем остановитесь перед Human gate.
-
-В отдельном пользовательском сообщении разрешите apply с теми же параметрами и возвращённым
-`SOO-*` кодом. `task stop-override-apply` добавляет одну запись в
-`stop-escalate-overrides.jsonl`, сохраняя исходный `stop-escalate`; после него выполните
-последовательные `status` и `next`. Обычно ожидаемый route — `task run` того же Step с последующим
-новым strict review. Beta.12.4 покрывает и последовательность package self-update/context-refresh
-циклов после override. Перед `task run` выполняйте только свежие advertised
-`update dependency-provenance-recover` и delegated `task context-refresh`; циклов может быть
-несколько. Workflow продолжит attempt 4 лишь когда докажет contiguous source-to-current chain:
-каждый Plan отличается только canonical Knowledge Map binding, каждый rebind совпадает с Plan
-artifacts, каждый Plan Risk Audit является mechanical rebound, а current approval/authorization
-сохраняют одну delegated authority. HEAD может продвинуться только через зарегистрированные
-single-parent dependency-provenance commits, каждый с exact `package.json`/`package-lock.json` diff.
-Новая stop-override recovery-запись не создаётся — используется существующая append-only evidence.
-Если advertised navigation сначала завершила последний `task context-refresh`, а затем разрешила
-`update dependency-provenance-recover`, административный recovery может объяснить ровно один
-post-audit Task revision. Core принимает его только как часть уже проверенной dependency-only Git
-chain; арифметика audit revision + refresh boundary + exact post-audit recoveries должна точно
-равняться current Task revision. Любой необъяснённый revision остаётся blocker.
-Если C1 остаётся claimed, но writer lease после Human boundary отсутствует, `next` вместе с
-`task run` рекламирует `task writer-credential-replace`; сначала восстановите credential exact
-claimant-актора, затем запускайте Step.
-
-Этот путь не работает для `split-required`, другого attempt ordinal, семантически изменённого
-Plan, отсутствующего attempt-3 continue, разорванной rebind/audit chain, незарегистрированного или
-product HEAD commit, повреждённой chronology, active/stale lease на Human prepare/apply boundary
-или незавершённой Task transaction.
-Delegated approval для самого stop override отсутствует; delegation относится только к обычному
-context refresh после уже подтверждённого Human override.
-
-## 1. Подготовьте отдельный чат обновления
-
-Не обновляйте пакет во время выполняющегося Worker Step, кроме exact beta.12.6 downstream-proof
-исключения выше. В обычном случае дождитесь завершения текущего ответа Codex и откройте в нужном
-проекте отдельный чат `Workflow update`.
-
-Передайте агенту этот промпт, заменив `<НОВАЯ_ВЕРСИЯ>` точной опубликованной версией:
-
-```text
-Обнови Codex Workflow V2 в этом проекте до точной версии <НОВАЯ_ВЕРСИЯ>
-из npm: https://www.npmjs.com/package/codex-workflow-v2.
-
-Все команды выполняешь ты. Сначала прочитай AGENTS.md и определи Git root.
-До изменений запусти project-local gateway handshake, doctor, status, next и
-read-only `update preflight`;
-зафиксируй текущую версию, protocolVersion, stateSchemaVersion, projectId,
-активные сущности и наличие writer lease. Продолжай только если preflight
-вернул safe=true: checkout чистый, running Step и active writer lease отсутствуют.
-Иначе остановись без обновления и покажи blockers.
-
-Обнови только точную npm-зависимость и lock-файл, без диапазона версий.
-Не удаляй и не редактируй вручную $CODEX_HOME/workflow-state/v2.
-Не запускай state migration, если stateSchemaVersion не изменилась.
-После установки проверь совпадение declared и installed версии, выполни
-handshake, doctor, status и next новой версией. Затем установи или обнови
-персональный codex-workflow-gateway из установленного npm-пакета штатным
-installer скриптом. Покажи diff файлов репозитория и результаты проверок.
-Не начинай продуктовую реализацию в этом чате.
-```
-
-Агенту может потребоваться ваше разрешение на установку npm-зависимости и запись персонального
-plugin за пределами workspace. Это ожидаемая граница безопасности Codex, а не миграция state.
-
-## 2. Проверьте отчёт чата обновления
-
-До завершения чат должен подтвердить:
-
-1. В `package.json` указана точная версия без `^`, `~`, `latest` или `next`.
-2. Lock-файл и фактически установленный пакет содержат ту же версию.
-3. Handshake возвращает ожидаемые package/protocol/state-schema версии.
-4. `doctor` не сообщает о несовместимой зависимости или повреждённом state.
-5. `projectId` совпадает со значением до обновления.
-6. Существующие Task/Milestone ID, revisions и terminal statuses сохранились.
-7. Персональный gateway обновлён из установленного пакета.
-8. `update preflight` до изменения подтвердил чистую lifecycle-границу.
-9. Для alpha.6 существующий schema 2 проект либо уже имеет `adoption-posture.jsonl`,
-   либо `next`/`status` требуют `state adoption-prepare` и затем `state adoption-apply`.
-10. При переходе с protocol v1 на v2 неизменённый и криптографически целостный adoption sidecar
-    остаётся читаемым как legacy evidence. Runtime не переписывает его автоматически; неизвестная
-    версия или смешанная protocol-цепочка считаются повреждением state.
-
-Protocol v2 меняет navigation/CLI corrective-replan и lifecycle epoch, но не Task state schema.
-До обновления не должно быть `in_progress` Step, writer lease, Core Task operation mutex или
-незавершённого corrective Task journal. Такие состояния требуют штатного completion/repair старой
-версией; переносить или удалять journal вручную нельзя. Старые grants/receipts не получают authority
-в epoch 2 — новый corrective replan всегда проходит новый prepare/human-gate/execute цикл.
-
-Изменение `projectId`, исчезновение сущностей или ошибка unsupported state schema — причина
-остановиться. Не соглашайтесь на «починку» удалением state. Агент должен вернуть dependency к
-предыдущей точной версии либо ждать официального мигратора.
-
-## 3. Откройте новый чат после установки gateway
-
-Codex загружает набор skills/plugin при старте чата. Уже открытый чат может продолжать видеть
-старую gateway-инструкцию, даже если файлы plugin обновлены. Поэтому дальнейшую работу всегда
-начинайте в новом чате проекта.
-
-Промпт для контрольного чата:
-
-```text
-Возобнови проект через установленный Codex Workflow V2.
-Все команды выполняешь ты. Начни с AGENTS.md, project-local gateway
-handshake, doctor, status и next. Подтверди точную declared/installed
-версию, protocolVersion, stateSchemaVersion и прежний projectId.
-
-Проверь Knowledge Map штатно. Если изменение package.json или lock-файла
-сделало карту stale, выполни scan/reconcile и покажи мне классификацию и
-изменения до approve. Не редактируй внешний workflow-state вручную.
-Следуй только текущему ответу next и остановись перед любой human gate.
-```
-
-Обновление dependency меняет `package.json` и обычно lock-файл. Если один из этих файлов входит
-в Knowledge Map, изменение его content hash штатно делает карту `stale`. Это не потеря state:
-нужно выполнить `scan/reconcile`, показать пользователю изменения классификации и получить
-approval, если он требуется.
-
-## 3.0. Alpha.6 adoption для существующего schema 2 проекта
-
-Если проект уже вёлся на alpha.5 или другой schema 2 версии без alpha.6 posture, новый runtime
-не разрешит execution-переходы, пока не будет записан adoption sidecar. Это нормальное
-fail-closed поведение, а не повреждение state.
-
-Порядок:
-
-1. `update preflight --repo .`
-2. `state adoption-prepare --repo .`
-3. Проверить returned baseline и `ADA-*` confirmation code
-4. `state adoption-apply --repo . --actor <human-actor> --confirmation-code <ADA-CODE>`
-
-Граница должна быть безопасной:
-
-- checkout чистый;
-- нет `in_progress` Step;
-- нет active writer lease;
-- stale writer lease сначала чинится обычным repair-путём.
-
-Alpha.6 adoption сохраняет:
-
-- terminal Milestones со статусом `accepted` или `cancelled`;
-- terminal Tasks со статусом `merged` или `cancelled`;
-- completed и skipped Steps в активных Tasks вместе с их evidence.
-
-Alpha.6 adoption не делает:
-
-- не переписывает canonical entity JSON;
-- не переоткрывает terminal-сущности;
-- не прогоняет заново уже completed legacy Steps;
-- не использует `state migrate`.
-
-После adoption remaining legacy scope должен получить bootstrap Plan Risk Audit только для
-оставшихся non-`completed` и non-`skipped` Step.
-
-## 3.1. При необходимости включите delegated approval
-
-Delegated approval не включается автоматически после обновления. Существующие авторизации и
-terminal-сущности не меняются, а `stateSchemaVersion` остаётся `2`. Пользователь один раз
-подтверждает точную policy; после этого named delegate может выполнять только перечисленные
-переходы до истечения срока или revocation.
-
-Для заместителя, который должен планировать ещё не созданные Milestones и Tasks, нужен
-ограниченный по времени project scope. Более узкий Milestone/Task scope безопаснее, когда ID
-уже известен. Пример policy:
-
-```json
-{
-  "principal": "user:owner",
-  "delegate": "agent:deputy",
-  "scope": { "kind": "project" },
-  "transitions": [
-    "project_memory.approve",
-    "milestone.execution_authorize",
-    "milestone.final_accept",
-    "task.execution_authorize",
-    "task.final_accept"
-  ],
-  "expiresAt": "<ISO-8601 UTC>"
-}
-```
-
-Промпт для выпуска grant:
-
-```text
-Подготовь delegated approval policy для этого проекта: principal user:owner,
-delegate agent:deputy, project scope, переходы project_memory.approve,
-milestone.execution_authorize,
-milestone.final_accept, task.execution_authorize и task.final_accept, срок до
-<ДАТА_И_ВРЕМЯ_UTC>. Создай временный JSON вне репозитория и выполни только
-delegation prepare. Покажи всю policy, projectId, policyHash и DGA-код, затем
-остановись. Grant в этом же ответе не выпускай.
-```
-
-После проверки ответьте отдельным сообщением:
-
-```text
-Одобряю выпуск delegated approval grant для policy hash <POLICY_HASH>
-с кодом <DGA-CODE>. Выпусти grant и покажи DGR-ID, scope, transitions,
-expiresAt и revision.
-```
-
-`delegation list` и `status` показывают grants. Для досрочной остановки автономности агент
-выполняет `delegation revoke` от имени точного principal с текущей revision и причиной.
-Revocation запрещает будущие использования, но не переписывает уже записанные события.
-
-Важно: это локальная проверка policy и audit trail, а не криптографическая аутентификация
-Codex-процесса. Любой процесс с доступом к локальному state и CLI может заявить строку
-delegate. Поэтому project-wide grant должен быть короткоживущим, а секреты, платежи, реальные
-торговые операции и иные необратимые действия требуют отдельных технических ограничений и не
-должны полагаться только на delegated approval. Alpha.6 не расширяет allow-list transitions:
-grant не даёт authority на adoption apply, Milestone scope change или другие новые
-human-only guardrails.
-
-## 3.2. Запустите delegate в новом чате
-
-Grant сам не запускает агента и не прикрепляется к существующему чату. После получения
-`DGR-ID` откройте новый Local-чат в том же Codex Project. Новый чат нужен ещё и потому, что он
-загрузит актуальную gateway-инструкцию. Передайте точные `delegate` и `DGR-ID`; `DGA-код`
-больше не нужен.
-
-Перед запуском проверьте выбор scope:
-
-- новый Milestone или новая standalone Task с `AUTO` требуют project scope;
-- существующий Milestone и его linked Tasks могут использовать Milestone scope;
-- одна существующая Task может использовать Task scope;
-- Knowledge Map approval доступен только project-scoped grant с
-  `project_memory.approve`.
-
-Полные копируемые промпты для Milestone delegate и Task delegate находятся в
-`docs/delegated-approval.md` и chat-only PDF. В обоих промптах delegate обязан сначала
-выполнить `delegation show`, а каждый approval применять только при exact записи в текущем
-`next.delegatedApprovalOptions`. Внутренние Worker и Independent Reviewer grant не используют:
-его применяет координатор после получения их evidence.
-
-Все автоматически создаваемые чаты получают проектный монотонный номер из
-`plugins/codex-workflow-gateway/scripts/chat-registry.mjs`; `count + 1` запрещён. Основные формы:
-
-```text
-#NNN · M<NN> · Coord · <Milestone title> · <MS-ID>
-#NNN · M<NN>/T<NN> · Task · <Task title> · <TASK-ID>
-```
-
-Task-чат создавайте только как новую standalone Codex task (`create_thread`) в том же Project, а
-не как fork/handoff/продолжение Milestone-чата. В начальный prompt передавайте только exact
-TaskContextPacket: repository, точные Milestone/Task ID и ordinal, текущие Task revision/title,
-Brief/Plan bindings, Task requirements/acceptance, свежий маршрут `status -> next --task <Task
-ID>`, Task-local scope/checks/stop conditions и exact actor/grant ID при необходимости. Не
-переносите transcript Milestone-чата, историю recovery/approval, соседние Tasks, reasoning или
-confirmation/handoff/writer credentials.
-
-До создания проверьте, нет ли уже чата для exact Task ID. После создания передайте прочитанный
-title в registry readback и применяйте только возвращённый deterministic fallback. Title должен
-быть уникален и содержать exact `#NNN`, membership ordinal и ID. Input должен состоять из
-TaskContextPacket; допустима только добавленная Codex App служебная `codex_delegation`-обёртка с
-`source_thread_id`, но не parent turns или transcript. Если title отсутствует или нормализован
-неверно, переименуйте и перепроверьте. Pending `clientThreadId`, тайм-аут или отсутствие в
-`list_threads` не доказывают, что создание не состоялось, и не разрешают повторный `create_thread`.
-До первого вызова сохраните `dispatch-begin`; после него используйте `dispatch-result/status`,
-поиск коррелированного сеанса и `dispatch-observe` с фактическим `read_thread`. На одну
-резервацию выдаётся только одно разрешение создания. Не обходите его новой резервацией или fork.
-Полный контракт восстановления, сохранения supervisor/cursor и явного выбора `model`/`thinking`
-по роли, фазе и сложности находится в
-`plugins/codex-workflow-gateway/references/chat-dispatch.md`. Выбор модели требует соответствующего
-поручения пользователя и актуального списка поддерживаемых пар на целевом host; нельзя молча
-наследовать дорогую конфигурацию координатора или снижать уровень независимого аудита.
-Создавайте или переиспользуйте Task-чат непосредственно перед dispatch этой Task, а не как пустой
-placeholder для всего membership; `T<NN>` берите только из утверждённого membership order.
-
-После dispatch Milestone-координатор не заканчивает turn: он ждёт exact Task-чат bounded-вызовами
-`wait_threads`, сохраняет cursor, читает completed/attention результат и обязательно сверяет его
-через `status -> next`. Recoverable non-human продолжение отправляется в тот же чат через
-`send_message_to_thread`; пользователь нужен только для mandatory human/semantic gate, внешнего
-разрешения, unrecoverable integrity conflict или исчерпанного infrastructure retry. Следующий
-Task-чат создаётся только после Core-подтверждения `terminal + merged`. Завершённый Task-чат сам по
-себе не доказывает terminal state и не пробуждает уже завершившийся coordinator turn.
-
-После завершения автономного окна попросите отдельный контрольный чат показать
-`delegation list`, использованные authorization events и отозвать ненужный широкий grant.
-
-Для Milestone delegate отдельный Task-чат обязателен для каждой required Task. Это сохраняет
-пользовательский audit trail и не позволяет одному длинному Milestone-чату накапливать
-реализацию, compaction и review всех Tasks.
-
-## 4. Продолжите начатый Milestone или создайте следующий
-
-Terminal Milestone со статусом `accepted` остаётся закрытым. Для следующего результата нужно
-начать новый Discovery и материализовать новый Milestone; переписывать историю предыдущего не
-следует.
-
-Промпт для планирования следующего Milestone:
-
-```text
-Создай следующий Milestone проекта через Workflow V2.
-Все команды выполняешь ты. Начни с AGENTS.md, gateway handshake, doctor,
-status и next. Проверь Knowledge Map штатно и показывай мне её смысловые
-изменения до approve.
-
-Проведи Discovery: outcome, scope, out-of-scope, acceptance, constraints,
-unknowns и success signal. Не materialize сущность при blocking unknowns.
-После согласования создай Milestone и тонкие связанные Tasks, подготовь
-membership Plan и покажи его мне для execution authorization. После моей
-явной авторизации доведи Milestone до active, выдай порядок required Tasks
-и остановись. Реализацию в этом чате не начинай.
-```
-
-## 5. Как теперь закрывается Milestone
-
-После merge всех `required` Tasks откройте отдельный чат финальной проверки:
-
-```text
-Возобнови Milestone <MS-ID> и подготовь его к финальному принятию.
-Все команды и проверки выполняешь ты. Начни с AGENTS.md, handshake,
-doctor, status и next. Проверь, что все current required memberships merged,
-выполни штатную Milestone validation и покажи Result, evidence, checks и
-validated HEAD.
-
-Когда next вернёт requiredHumanGate, покажи мне все связанные поля и код
-подтверждения, запроси моё явное final acceptance и заверши ответ. Не
-вызывай milestone accept в этом же ответе и не считай этот промпт заранее
-выданным согласием.
-```
-
-После этого Codex должен остановиться. Если результат устраивает, ответьте отдельным сообщением:
-
-```text
-Принимаю Milestone <MS-ID> для revision <REVISION> с кодом <MSA-CODE>.
-Выполни штатный final acceptance и подтверди status accepted.
-```
-
-Код связан с Milestone ID, revision, Plan hash, Result hash, evidence hash и validated HEAD.
-Если любой из них изменился, старый код недействителен и агент должен повторно показать новую
-границу принятия.
-
-## 6. Проверка исправленного `next`
-
-`next` не должен возвращать незапущенную историческую Task, если её текущее membership имеет
-disposition `waived`/`cancelled` либо её Milestone уже `accepted`/`cancelled`. Для активного
-Milestone он выбирает только `required` Tasks. Уже начатая Task может завершить допустимый
-переход, поэтому её наличие анализируется отдельно от незапущенной истории.
-
-Если после совместимого обновления `next` всё ещё показывает неподходящую Task, агент должен
-собрать `status`, целевые Task/Milestone state и memberships и остановиться с диагностикой. Не
-следует вручную менять JSON state или обходить transition checks.
+This guide does not authorize updating a live consumer while auditing the workflow package. Such a change is a separate explicitly scoped operation.