codex-workflow-v2 2.0.0-alpha.4 → 2.0.0-alpha.7

package/docs/project-memory.md

@@ -30,6 +30,13 @@ definition, status, and evidence record, records the old/new binding, supersedes
 authorization, and cannot run while a Step is in progress. If local state is lost, the map
 is rebuilt from repository files.
 
+For delegated autonomy, repository `next` may expose `contextRefresh` when the stored map was
+active and inspection proves content-hash-only drift. `task context-refresh` then performs
+reconcile, delegated map approval, Task rebind, and delegated execution authorization while
+preserving the ordinary audit events. The command rejects new/removed sources, category,
+scope or authority changes, changed gaps, and conflicts. Those changes always remain visible
+for normal classification and approval.
+
 ## Codebase graph
 
 The graph is an optional derived index, never the durable memory authority. The gateway asks

package/docs/release.md

@@ -20,6 +20,15 @@ The downstream smoke packs the actual tarball, installs it into an empty tempora
 runs the packaged CLI handshake, and proves installation created none of `.codex`, `.tasks`,
 `.increments`, or `.memory-bank` in that project.
 
+For alpha.7, the release gate also relies on `npm run release:check` to fail if:
+
+- canonical entity schema 2 shapes drift;
+- protocol 1 compatibility is no longer additive;
+- the delegated transition allow-list expands;
+- schema-2 adoption is presented as `state migrate` instead of posture sidecars;
+- alpha.7 rescue, Milestone autonomy (including guarded content refresh), derived actor, or
+  proof-obligation capabilities and schemas are absent from the packaged surface.
+
 Tag releases as `v<package-version>`. The tag workflow verifies the tag/package match and
 uses npm trusted publishing with public access. For a public GitHub repository and public
 package, npm trusted publishing generates provenance automatically. Publishing is never

package/docs/updating-existing-project.md

@@ -19,7 +19,18 @@ gateway, но не удаляет и не пересоздаёт это сост
 Никогда не разрешайте агенту вручную редактировать, переносить или удалять внешний state.
 Команда миграции нужна только тогда, когда документация новой версии прямо сообщает о новой
 state schema. Совпадение `stateSchemaVersion` до и после обновления означает, что миграция не
-нужна.
+нужна. Для alpha.6 при `stateSchemaVersion: 2` применяется не migration, а sidecar-only
+adoption posture.
+
+### Исключение для 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.
+После terminal review выполните обычный Knowledge reconcile/rebind, доведите Task до безопасной
+границы и только затем обновляйте package/lock обычным способом.
 
 ## 1. Подготовьте отдельный чат обновления
 
@@ -33,10 +44,12 @@ Codex и откройте в нужном проекте отдельный ча
 из npm: https://www.npmjs.com/package/codex-workflow-v2.
 
 Все команды выполняешь ты. Сначала прочитай AGENTS.md и определи Git root.
-До изменений запусти project-local gateway handshake, doctor, status и next;
+До изменений запусти project-local gateway handshake, doctor, status, next и
+read-only `update preflight`;
 зафиксируй текущую версию, protocolVersion, stateSchemaVersion, projectId,
-активные сущности и наличие writer lease. Если Worker сейчас выполняется,
-остановись без обновления.
+активные сущности и наличие writer lease. Продолжай только если preflight
+вернул safe=true: checkout чистый, running Step и active writer lease отсутствуют.
+Иначе остановись без обновления и покажи blockers.
 
 Обнови только точную npm-зависимость и lock-файл, без диапазона версий.
 Не удаляй и не редактируй вручную $CODEX_HOME/workflow-state/v2.
@@ -62,6 +75,9 @@ plugin за пределами workspace. Это ожидаемая границ
 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`.
 
 Изменение `projectId`, исчезновение сущностей или ошибка unsupported state schema — причина
 остановиться. Не соглашайтесь на «починку» удалением state. Агент должен вернуть dependency к
@@ -92,6 +108,42 @@ handshake, doctor, status и next. Подтверди точную declared/inst
 нужно выполнить `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 не включается автоматически после обновления. Существующие авторизации и
@@ -147,7 +199,9 @@ Revocation запрещает будущие использования, но н
 Codex-процесса. Любой процесс с доступом к локальному state и CLI может заявить строку
 delegate. Поэтому project-wide grant должен быть короткоживущим, а секреты, платежи, реальные
 торговые операции и иные необратимые действия требуют отдельных технических ограничений и не
-должны полагаться только на delegated approval.
+должны полагаться только на delegated approval. Alpha.6 не расширяет allow-list transitions:
+grant не даёт authority на adoption apply, Milestone scope change или другие новые
+human-only guardrails.
 
 ## 3.2. Запустите delegate в новом чате
 
@@ -181,6 +235,10 @@ NN - Standalone delegated task
 После завершения автономного окна попросите отдельный контрольный чат показать
 `delegation list`, использованные authorization events и отозвать ненужный широкий grant.
 
+Для Milestone delegate отдельный Task-чат обязателен для каждой required Task. Это сохраняет
+пользовательский audit trail и не позволяет одному длинному Milestone-чату накапливать
+реализацию, compaction и review всех Tasks.
+
 ## 4. Продолжите начатый Milestone или создайте следующий
 
 Terminal Milestone со статусом `accepted` остаётся закрытым. Для следующего результата нужно

package/docs/validation-report.md

@@ -1,38 +1,56 @@
 # V2 Alpha Validation Report
 
-Release candidate `2.0.0-alpha.4` was validated on 2026-08-12 with Node.js 24.17.0.
+Release candidate `2.0.0-alpha.7` was validated on 2026-08-14 with Node.js 24.17.0.
 
 - TypeScript typecheck and build passed.
-- All 47 unit and integration tests passed. Coverage includes the complete Task lifecycle,
-  a Project Knowledge Map change between Steps, preservation of completed Step evidence,
-  mandatory reauthorization, the public `task knowledge-rebind` CLI route, no-op and active
-  Worker rejection, current gateway capability negotiation, and rejection of deprecated
-  state schema instead of migration.
-- Delegated approval coverage includes DGA-bound grant issuance, project/Milestone/Task
-  scopes, Knowledge Map approval, all Task/Milestone execution and final transitions,
-  `next.delegatedApprovalOptions`, explicit principal/delegate audit metadata, actor,
-  transition and scope rejection, expiry, revocation, duplicate issuance, and policy-hash
-  tamper rejection.
-- Milestone scheduling now ignores unstarted Tasks with cancelled/waived or terminal
-  membership paths. Final Milestone acceptance exposes a revision/hash/HEAD-bound human gate,
-  rejects a wrong code, and regenerates its code after base advancement and revalidation.
-- Milestone amendments, graph binding, deterministic V1 snapshot, symlink rejection, writer
-  leases, and strict reviewer fail-closed behavior also passed.
-- npm dry-run packaging produced `codex-workflow-v2-2.0.0-alpha.4.tgz` with runtime, schemas,
-  roles, references, docs, and plugin source.
-- Downstream installation from that tarball and the packaged CLI handshake passed; the
-  installation created none of the forbidden repository workflow directories.
-- Plugin validation and the repository release check passed for `2.0.0-alpha.4`.
-- The alpha.4 CLI read the existing Signal schema 2 project state without migration:
-  project ID `b06d0f18f790f4521a23c770`, accepted Milestone 1 revision 10, historical
-  authorization events, and all entity IDs were preserved; `delegations` was an empty
-  additive collection and repository-level `next` remained `idle`.
-- The three Russian PDFs were regenerated and all 40 pages were rendered to PNG for visual
-  inspection; delegated approval, compatibility, grant issuance, audit, revocation, and
-  chat-only grant issuance and Milestone/Task delegate launch prompts are present without
-  layout defects.
-
-The strict reviewer implementation did not change in this release candidate. Its original
-2026-07-16 real Codex CLI isolation probe denied a repository write and returned
-`isolationProbe: "denied"`. The reviewer remains fail-closed: inability to prove isolation
-records `unverified` and blocks acceptance.
+- The authoritative sequential suite passed `86/86` with `--test-concurrency=1`. An earlier
+  ordinary parallel run also passed its then-current `85/85` suite, but CLI subprocess
+  contention made one test take 165 seconds; the final sequential exit is the release evidence.
+- `npm run pack:check`, `npm run smoke:downstream`, `npm run release:check`,
+  `npm run plugin:check`, and `git diff --check` passed. Packaging and downstream smoke used
+  an isolated temporary npm cache because the user cache contains pre-existing root-owned
+  entries.
+- The repository-level `tools/tests/codex-workflow-regression.mjs` update/install regression
+  completed with `status: PASS`.
+- Dry-run packaging produced `codex-workflow-v2-2.0.0-alpha.7.tgz` with 139 files; downstream
+  installation and packaged CLI handshake passed.
+
+Alpha.7 regression coverage includes:
+
+- pending strict Step Review outranks Knowledge Map reconcile/rebind after a knowledge-changing
+  completion commit; review succeeds against the exact historical approved binding even while
+  the current map is stale, and rebind remains mandatory before the next Step;
+- read-only alpha.6 rescue-preflight rejects active leases and accepts only one exact pending
+  strict-review candidate on the clean recorded completion HEAD;
+- seven linked Tasks can be materialized during initial Milestone assembly and classified by
+  one complete initial Plan without repeated scope-change approvals;
+- one maximum-72-hour Milestone Autonomy Contract issues the existing Task/Milestone approval
+  permissions, permits Project Memory approval only inside an atomic content-only Task context
+  refresh, permits journaled membership-only evolution, requires reauthorization, and rejects
+  both standalone Project Memory approval and semantic scope drift; a later human semantic
+  change invalidates future uses of the autonomy grant;
+- C1 Worker and corrective Auditor actors are deterministically derived while claim, lease,
+  handoff, and reviewer/auditor independence checks remain fail-closed;
+- every newly recorded guarded Plan Risk Audit requires an exact proof obligation per failure
+  mode: hostile counterexample, expected safe result, and executable evidence command;
+  historical alpha.6 audits remain readable for recovery only;
+- existing Milestone journal recovery, reverse-membership integrity, delegation, adoption,
+  Knowledge Map, graph, strict reviewer, Git ownership, and remediation hard-stop tests remain
+  green.
+
+Compatibility claims verified:
+
+- `protocolVersion: 1` and `STATE_SCHEMA_VERSION: 2` remain unchanged;
+- canonical Task and Milestone schemas remain byte-identical;
+- the generic delegated transition allow-list remains unchanged;
+- new evidence is additive through `autonomy-contract-events.jsonl`, optional autonomous
+  fields on scope-change events, and optional proof obligations on Plan Risk Audit events;
+- the gateway handshake advertises alpha.7 rescue, initial assembly, autonomy, derived actor,
+  corrective routing, and proof-obligation capabilities.
+
+Not claimed here:
+
+- no npm publication, Git tag, push, or downstream project mutation was performed;
+- no manual rewrite of external Workflow state is part of the recovery design;
+- the local package cannot cryptographically prove a real human identity or a physically
+  separate Codex task beyond the existing actor, process-isolation, sidecar, and lease evidence.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-workflow-v2",
-  "version": "2.0.0-alpha.4",
+  "version": "2.0.0-alpha.7",
   "description": "Requirements-first Codex development workflow with local state and explicit Git ownership.",
   "repository": {
     "type": "git",

package/plugins/codex-workflow-gateway/references/protocol.md

@@ -8,13 +8,186 @@ Run:
 codex-workflow gateway handshake --repo <git-root>
 ```
 
-Require package name `codex-workflow-v2`, protocol version `1`, state
-schema version `2`, and the capabilities needed for the requested operation. Task execution
-that may cross a Project Knowledge Map revision requires `task-knowledge-rebind-v1`.
-Milestone final acceptance requires `milestone-human-final-gate-v1`.
-Autonomous approval requires `delegated-approval-v1`.
+Require:
 
-## Milestone Human Gate
+- package name `codex-workflow-v2`
+- protocol version `1`
+- state schema version `2`
+- the capabilities needed for the requested operation
+
+Current capability set:
+
+- `project-memory-v1`
+- `graph-binding-v1`
+- `local-state-v1`
+- `milestone-lifecycle-v1`
+- `milestone-human-final-gate-v1`
+- `delegated-approval-v1`
+- `task-knowledge-rebind-v1`
+- `task-context-refresh-v1`
+- `corrective-plan-audit-v1`
+- `safe-update-preflight-v1`
+- `strict-reviewer-v1`
+- `legacy-snapshot-v1`
+- `plan-risk-audit-sidecar-v1`
+- `step-strict-review-sidecar-v1`
+- `step-remediation-circuit-breaker-sidecar-v1`
+- `milestone-scope-change-sidecar-v1`
+- `milestone-membership-integrity-v1`
+- `task-c1-handoff-sidecar-v1`
+- `semantic-plan-risk-audit-v2`
+- `guarded-remediation-hard-stop-v1`
+- `milestone-reverse-membership-integrity-v1`
+- `task-c1-handoff-bundle-v2`
+- `alpha6-adoption-posture-v1`
+- `alpha6-strict-review-rescue-v1`
+- `milestone-initial-assembly-v1`
+- `milestone-autonomy-contract-v1`
+- `milestone-autonomous-membership-evolution-v1`
+- `task-c1-derived-worker-actor-v1`
+- `guarded-corrective-auditor-routing-v1`
+- `plan-proof-obligations-v1`
+
+Protocol `1` and schema `2` remain valid only because alpha.7 is additive. The gateway must
+not claim compatibility if canonical entity shapes or non-additive command semantics change.
+
+## Alpha.6 adoption posture
+
+For an existing schema 2 project without alpha.6 posture, repository-level `next` blocks
+execution behind adoption:
+
+- `action: "state adoption-apply"` when the repository is already at a safe boundary
+- `action: "restore safe boundary, then state adoption-prepare"` otherwise
+
+Use:
+
+```text
+codex-workflow state adoption-prepare --repo <git-root>
+codex-workflow state adoption-apply --repo <git-root> \
+  --actor <HUMAN-ACTOR> --confirmation-code <ADA-CODE>
+```
+
+The confirmation is bound to project identity, package version, protocol version, schema
+version, canonical entity summaries, and the current sidecar baseline hash. Adoption is not
+`state migrate`.
+
+## Worker Step completion and strict Step Review
+
+`task run` dispatches one Step and returns its writer token and Worker envelope. The Worker
+must leave all changes uncommitted and must not stage, commit, amend, reset, rebase, or
+modify Git history.
+
+While that Step is `in_progress`, repository-level `next` normally returns
+`action: "task step-complete"`, the exact `stepId`, and a `commitPolicy` declaring
+`workflow-core` ownership. The coordinator invokes that transition with the current revision
+and writer token. Core then runs configured checks, validates `allowedWrites`, stages the
+changes, creates the atomic commit, and records evidence.
+
+If the current Plan Risk Audit marks that Step for strict review, the commit is still
+workflow-owned, but `next` then returns `action: "task step-review"` with the same `stepId`
+and the exact `completionCommit`. Canonical Step completion remains blocked until the strict
+review and reviewer attestation sidecars verify against that exact commit.
+
+An unrecorded commit is Git history drift. Stop instead of adding another commit or editing
+workflow state manually; recovery remains coordinator-controlled.
+
+## Plan Risk Audit and remediation breaker
+
+Before `task authorize`, every new alpha.7 Task requires:
+
+```text
+codex-workflow task plan-risk-audit --repo <git-root> \
+  --id <TASK-ID> --expected-revision <REVISION> --file <audit.json>
+```
+
+The audit must classify every current Step exactly once, name distinct planner/auditor
+actors, bind guarded failure modes to exact Step checks, and map each guarded failure mode to
+one hostile counterexample, expected safe result, and exact executable evidence command. Use `decision=approved` for an
+unguarded Plan. Missing, stale, `split-required`, or `stop-escalate` evidence blocks
+authorization.
+
+For guarded remediation, `next.correctivePlanGate` or the runtime gate blocks a third
+ordinary retry on the same guarded Step until a current corrective decision exists. Record it
+with:
+
+```text
+codex-workflow task corrective-decision --repo <git-root> \
+  --id <TASK-ID> --step <STEP-ID> --expected-revision <REVISION> --file <decision.json>
+```
+
+Only `continue-fix` permits bounded continuation. `replan-required`, `split-required`, and
+`stop-escalate` are stop or redirection decisions. If the third corrective review fails, a
+fourth run is prohibited; only split or stop may be recorded.
+
+## Context refresh
+
+Use `task context-refresh` only when the same `next` response exposes `contextRefresh` for the
+exact grant. Pass Task revision, map revision, delegate actor, and grant ID. The composite
+operation is restricted to content-hash-only drift and records the ordinary delegated map and
+Task authorization evidence. Any semantic map change remains on the normal visible path.
+
+Before updating the installed package, run `update preflight`. Continue only for `safe=true`.
+For an alpha.6 project trapped between a pending strict review and forbidden Knowledge rebind,
+an exact external alpha.7 runner may run `update rescue-preflight`. Continue only for
+`eligible=true` and only with the returned lock-repair and strict-review actions.
+
+## C1 handoff
+
+`C1` coordination is machine-bound and local. Use:
+
+```text
+codex-workflow task handoff-prepare --repo <git-root> --id <TASK-ID> \
+  --expected-revision <REVISION> --actor <CURRENT-ACTOR> \
+  [--target-actor <TARGET-ACTOR>] --reason <TEXT> [--writer-token <TOKEN>] \
+  [--delegation-grant <GRANT>] [--expires-at <ISO-TIMESTAMP>]
+codex-workflow task handoff-show --repo <git-root> --id <TASK-ID>
+codex-workflow task claim --repo <git-root> --id <TASK-ID> \
+  --expected-revision <REVISION> --actor <TARGET-ACTOR> --claim-token <TOKEN> \
+  [--writer-token <WRITER-TOKEN>]
+codex-workflow task handback-create --repo <git-root> --id <TASK-ID> \
+  --expected-revision <REVISION> --actor <CLAIMANT> --reason <TEXT> \
+  --recommended-next <TEXT> [--limitation <TEXT>] [--writer-token <TOKEN>]
+```
+
+While a handoff is pending, `next` blocks the previous action behind `task claim`. While
+claimed, only the claimant may mutate the Task, and lease-bound mutations must present the
+bound writer token. Milestone-linked Tasks must be claimed before start, and handback is
+terminal and evidence-bound. When target actor is omitted, Core derives
+`agent:worker:<task-id>`. No thread id is required or accepted as authority.
+
+## Milestone assembly, autonomy, and human gate
+
+During initial planning, materialize every linked Task and then call `milestone plan-set` once
+with the complete membership. Execution is blocked while reverse membership is incomplete.
+
+After that Plan, one human may prepare and grant a maximum-72-hour Milestone Autonomy Contract:
+
+```text
+codex-workflow milestone autonomy-prepare --repo <git-root> --id <MS-ID> \
+  --expected-revision <REVISION> --principal <HUMAN> --delegate <AGENT> --expires-at <ISO>
+codex-workflow milestone autonomy-grant --repo <git-root> --id <MS-ID> \
+  --expected-revision <REVISION> --principal <HUMAN> --delegate <AGENT> --expires-at <ISO> \
+  --confirmation-code <MAC-CODE>
+```
+
+The contract issues a milestone-scoped grant for the existing Task/Milestone approval transitions
+and Project Memory approval only inside an atomic content-only Task context refresh for the same
+Milestone. It cannot approve Project Memory independently. `milestone autonomy-evolve --file
+<plan.json>` is permitted only when outcome, success signal, acceptance, checks, discovery, and
+base branch still match the contract. It journals agent actor plus contract evidence and requires
+reauthorization afterward.
+
+After the initial empty planning posture, Milestone scope updates use:
+
+```text
+codex-workflow milestone scope-change-prepare --repo <git-root> \
+  --id <MS-ID> --expected-revision <REVISION> --actor <HUMAN-ACTOR> --file <plan.json>
+codex-workflow milestone scope-change-apply --repo <git-root> \
+  --id <MS-ID> --expected-revision <REVISION> --actor <HUMAN-ACTOR> \
+  --confirmation-code <MSC-CODE> --file <plan.json>
+```
+
+This ordinary semantic-change path is human-only. Generic delegated approval never authorizes it.
 
 At `awaiting_final_acceptance`, `next` returns `requiredHumanGate` with kind
 `milestone_final_acceptance`, Milestone ID, revision, Plan/Result/evidence hashes, validated
@@ -42,6 +215,9 @@ as `--delegation-grant`. The resulting authorization event records the grant and
 For `milestone.final_accept`, also pass the current `MSA-*` code; the existing grant replaces
 the later-message requirement, not the state binding.
 
+Delegated approval does not cover adoption apply or the ordinary semantic Milestone scope-change
+path. Membership-only evolution requires the separate Milestone Autonomy Contract.
+
 ## Graph Refresh Request
 
 The package returns:

package/plugins/codex-workflow-gateway/skills/codex-workflow-gateway/SKILL.md

@@ -27,6 +27,11 @@ files, or MCP ADR storage as a fallback.
 6. Run `gateway handshake` before other actions. Stop on package, protocol, or
    state-schema incompatibility.
 
+The sole exception is the alpha.7 `update rescue-preflight` compatibility profile. An exact
+external alpha.7 runner may inspect a project still pinned to alpha.6 only when this read-only
+command reports `eligible=true`. Execute only its returned stale-lock repair and strict-review
+actions; do not use the external runner for any other transition or dependency mutation.
+
 If any step fails, report the concrete diagnostic. Do not load workflow
 semantics from this skill.
 
@@ -38,6 +43,10 @@ classifications, hashes, gaps, conflicts, and approval evidence.
 
 Do not create a memory directory or write project files during scan.
 
+When `next` exposes an exact delegated `contextRefresh`, use `task context-refresh` only for
+the returned Task/map revisions, actor, and grant. Never use it when the source set,
+classification, authority, gaps, or conflicts changed.
+
 ## Product Or Workflow Graph Refresh
 
 1. Run `graph refresh-request --kind product|workflow --mode moderate`.
@@ -57,8 +66,12 @@ independently blocks the workflow.
 
 - Scope Lead: architecture and broad search only.
 - Technical Planner: architecture, search, and trace evidence.
-- Worker: targeted search, trace, and snippets for its Step.
+- Worker: targeted search, trace, and snippets for its Step. It leaves all file changes
+  uncommitted and never stages or mutates Git history; the coordinator invokes the exact
+  `task step-complete` returned by `next`, and core owns checks, commit creation, and evidence.
 - Delivery Coordinator: list, status, index, detect, and bind lifecycle.
+- A Milestone Delivery Coordinator creates a dedicated user-visible Task chat for every
+  required Task and keeps implementation out of the Milestone chat.
 - Independent Reviewer: receives recorded evidence and confirms critical
   claims against files, Git, and tests.
 
@@ -95,6 +108,27 @@ option is returned, follow the ordinary human-gate rule above. Knowledge Map app
 delegable only through an explicit project-scoped `project_memory.approve` permission. Scope
 changes, grant issuance, and grant expansion are never delegated by `delegated-approval-v1`.
 
+For an entire Milestone, prefer one bounded `milestone autonomy-prepare` gate after the complete
+initial membership Plan exists. Show principal, delegate, expiry, semantic-scope hash, policy
+hash, and `MAC-*` code, then stop. A later exact approval permits `milestone autonomy-grant`.
+The resulting grant covers the existing Task/Milestone approval transitions and the Project
+Memory approval portion of an atomic content-only Task context refresh for the same Milestone;
+it never permits standalone Project Memory approval. It also permits `milestone autonomy-evolve`
+only for membership changes; any change to outcome, success signal, acceptance, checks,
+discovery, or base branch requires the ordinary human scope-change gate. Never self-renew or
+replace the contract.
+
+After two failed Task reviews, follow `next.correctivePlanGate`: obtain a distinct read-only
+corrective Auditor result and pass it through `--corrective-audit-file`. Do not continue for
+replan, split, or stop decisions.
+
+When `next` returns a derived C1 Worker or corrective Auditor actor, use that exact actor without
+asking the user to name one. Derivation removes a routing pause; handoff claim, writer lease,
+strict review, and auditor-independence checks remain mandatory.
+
+Before an npm package update, run the project-local `update preflight` and stop unless it
+returns `safe=true` with a clean checkout, no running Step, and no active writer lease.
+
 ## Stop Conditions
 
 - Dependency version is missing, ranged, or differs from the installed package.

package/references/git-policy.md

@@ -3,5 +3,8 @@
 The default mode uses a dedicated task branch in the current clean checkout. The core
 does not create or remove worktrees. An externally supplied worktree or clone must already
 be on a dedicated non-base branch; its provider owns merge and cleanup. Every completed
-Step becomes one commit with Task and Step trailers. Unexpected changed paths block the
-commit. Base advancement invalidates validation and final acceptance before merge.
+Step becomes one commit with Task and Step trailers. The Worker leaves its changes
+uncommitted; `task step-complete` owns configured checks, staging, commit creation, and Step
+evidence. A Worker must not run `git add`, `git commit`, amend, reset, rebase, or otherwise
+change Git history. Unexpected changed paths or unrecorded commits block Step completion.
+Base advancement invalidates validation and final acceptance before merge.

package/references/state-machine.md

@@ -6,6 +6,22 @@ to the task commit and Brief, Plan, and evidence hashes. Final acceptance is a s
 human event bound to Result, evidence, and commit. Locks expire only diagnostically;
 removing a stale lock is always an explicit repair operation.
 
+Alpha.7 keeps canonical entity JSON unchanged at `stateSchemaVersion: 2` and adds lifecycle
+evidence through sidecars. `protocolVersion: 1` remains valid only because the alpha.7
+surface is additive and capability-advertised.
+
+Before execution authorization, every alpha.7 Task must have a current Plan Risk Audit bound
+to the current Brief, Plan, Knowledge Map, and exact Step set. The audit is required even when
+all Steps are unguarded, must name distinct planner/auditor actors, and must bind guarded
+failure modes to exact Step checks. Each newly recorded guarded failure mode also requires one
+hostile counterexample, expected safe result, and exact evidence command. Missing, stale, inconsistent, `split-required`, or
+`stop-escalate` evidence blocks authorization.
+
+If the current Plan Risk Audit marks a Step for strict review, `task step-complete` still
+creates the workflow-owned commit but keeps the Step non-terminal. Repository `next` routes to
+`task step-review` until a valid strict review and reviewer attestation bind to that exact
+commit.
+
 Human approval remains the default. A user may instead issue a time-bound delegation grant
 after confirming a deterministic `DGA-*` code bound to the project and exact policy hash.
 The policy names a distinct principal and delegate, a project/Milestone/Task scope, and an
@@ -21,6 +37,12 @@ bindings, supersedes execution authorization, and returns the Task to
 `awaiting_execution_authorization`. It cannot run while a Step is `in_progress` or while the
 Task is `blocked`; unrelated blocks must be resolved through their owning transition.
 
+For guarded remediation, two ordinary remediation attempts are allowed. A third
+ordinary retry is blocked until a current corrective decision exists for the same Step and
+Plan binding. `continue-fix` allows bounded continuation; `replan-required`,
+`split-required`, and `stop-escalate` stop ordinary execution. A failed third corrective
+attempt is a hard stop: no fourth run or new continue/replan decision is accepted.
+
 Milestone authorization is bound to its Plan and membership revision. Plan amendments
 supersede authorization. Milestone validation and acceptance are bound to the current base
 HEAD. In `awaiting_final_acceptance`, `next` returns a state-bound human gate. The agent must
@@ -34,6 +56,27 @@ but the acceptance command still requires the current `MSA-*` code so the use re
 to the validated revision, hashes, and HEAD. Grant issuance itself always remains a prior
 human turn boundary.
 
+During initial planning, all linked Tasks may be materialized before one complete
+`milestone plan-set`; execution remains blocked until every reverse membership is classified.
+After that boundary, semantic updates use human-only `milestone scope-change-prepare` and
+`milestone scope-change-apply`. A human-confirmed, expiring Milestone Autonomy Contract may
+use `milestone autonomy-evolve` only for membership changes while outcome, success signal,
+acceptance, checks, discovery, and base branch remain fixed. It may also approve Project Memory
+only within an atomic content-only context refresh for a Task in that Milestone; standalone map
+approval remains forbidden. Both update paths journal
+`state.json`, `plan.json`, and `scope-change-events.jsonl` together. Membership integrity is validated
+before scheduling, Task start, Milestone validation, scope change, and repository `next`.
+The same guard scans in reverse and blocks every live Task whose `milestoneId` is absent from
+the Milestone's required/waived/cancelled classification.
+
+`C1` coordination is machine-bound but local: `task handoff-prepare` returns a one-time claim
+token and prompt bound to a stable handoff ID, revision, context hashes, Milestone positions,
+delegate/grant, expected next action, and expiry. `task claim` validates those bindings and
+activates claimant-only mutation; terminal `task handback-create` returns result, evidence,
+review, knowledge, limitation, and recommended-next bindings. Milestone Tasks must be claimed
+before start. If no target is supplied, Core derives `agent:worker:<task-id>`. No part of this
+contract requires or proves a physically separate Codex thread.
+
 Repository-level scheduling respects current Milestone membership. An unstarted linked Task
 is eligible only for an `active` Milestone with `required` disposition. Historical unstarted
 Tasks from `waived`, `cancelled`, accepted, or cancelled Milestone paths cannot shadow the

package/references/validation-and-review.md

@@ -1,18 +1,45 @@
 # Validation and Review
 
-Configured Step checks must pass before the Step commit is recorded. Submission produces
+The Worker leaves Step changes uncommitted. `task step-complete` runs the configured checks,
+creates the atomic Step commit, and records its evidence. Manual Worker commits are rejected
+as unrecorded history. Submission produces
 evidence for the exact task-branch head. Independent review is read-only and produces a
 version-bound result. Any later commit or change to Brief, Plan, or evidence makes that
 review stale. The user grants final acceptance only after a passing fresh review and a
 human-readable Result.
 
+High-risk evidence is failure-oriented. Migration acceptance includes a populated forward
+upgrade, concurrent state includes deterministic races, restart/replay claims include crash
+windows, and provider integrations include failure injection plus hidden-default checks.
+Happy-path green tests do not replace this evidence.
+
+After two failed independent reviews, another corrective Plan requires a distinct Auditor.
+The Auditor covers every latest finding and records `continue-fix`, `replan-required`,
+`split-required`, or `stop-escalate`. Only `continue-fix` may be passed to `task plan-set`
+through `--corrective-audit-file`; the other decisions stop implementation.
+
 The strict path is `task review-launch`. It starts an ephemeral Codex process with user
 configuration and rules ignored, a read-only sandbox, structured output, and an attempted
 write probe. The core seals repository HEAD, status, and content before/after the process.
 Any process error, malformed output, successful write, or changed seal records an
 `unverified` review and blocks Result creation and final acceptance.
 
+Alpha.6 adds a Step-level strict path for high-risk work. If the current Plan Risk Audit marks
+the completed Step for strict review, `next` routes to `task step-review` instead of
+advancing ordinary execution. The workflow validates:
+
+- the exact completion commit
+- the current Plan hash
+- the Step definition hash
+- the review sidecar chain in `step-review-events.jsonl`
+- the reviewer attestation chain in `reviewer-attestations.jsonl`
+
+Any stale, malformed, unverified, or wrong-commit evidence fails closed and keeps the Step out
+of canonical `completed` status.
+
 Milestone validation similarly binds Result and evidence to the clean base HEAD. Its final
 acceptance is a separate turn: `next` emits a confirmation code bound to the current
 revision, Plan, Result, evidence, and HEAD; the coordinator shows it and stops. A later user
 response must explicitly approve that exact code before the CLI transition is invoked.
+With a matching delegated option, the exact delegate may use the current code in the same
+turn, but the authorization event must keep the delegate actor and principal/grant evidence.