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

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,13 @@ 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.6, 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;
+- alpha.6 adoption is presented as `state migrate` instead of posture sidecars.
+
 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,8 @@ gateway, но не удаляет и не пересоздаёт это сост
 Никогда не разрешайте агенту вручную редактировать, переносить или удалять внешний state.
 Команда миграции нужна только тогда, когда документация новой версии прямо сообщает о новой
 state schema. Совпадение `stateSchemaVersion` до и после обновления означает, что миграция не
-нужна.
+нужна. Для alpha.6 при `stateSchemaVersion: 2` применяется не migration, а sidecar-only
+adoption posture.
 
 ## 1. Подготовьте отдельный чат обновления
 
@@ -33,10 +34,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 +65,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 +98,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 +189,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 +225,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,51 @@
 # 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.6` was validated through 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.
+- `npm run typecheck`, `npm run build`, `npm test`, `npm run validate`, `npm run plugin:check`,
+  `npm run smoke:downstream`, `npm run release:check`, and `npm run pack:check` passed in the
+  task evidence recorded for TASK-002.
+- The final sequential full suite passed `81/81` on 2026-08-14.
+- Plan Risk Audit coverage includes the combined `plan-set --risk-audit-file` path, atomic
+  rejection before Task/Plan acceptance, distinct planner/auditor identities, exact current
+  Step-set equality, concrete failure modes, executable evidence binding, coupled
+  migration/recovery rationale, blocking split/stop decisions, and adoption-aware
+  remaining-scope bootstrap handling.
+- Strict high-risk Step Review coverage includes workflow-owned completion commits,
+  `task step-review` routing, commit-bound reviewer attestation, and fail-closed rejection of
+  stale, malformed, unverified, and wrong-commit review evidence.
+- Guarded remediation coverage includes the per-Step circuit breaker: two ordinary retries
+  allowed, third gated by bounded `continue-fix`, a hard stop after a third failed corrective
+  review, and stop/redirection handling for `split-required` and `stop-escalate`.
+- Milestone coverage includes human-only scope-change prepare/apply, journaled recovery of
+  `state.json`, `plan.json`, and `scope-change-events.jsonl`, plus membership-integrity
+  blocking for stale or contradictory Milestone/Task state, including reverse detection of a
+  live linked Task missing from required/waived/cancelled membership.
+- `C1` coordination coverage includes the full prepared bundle, one-time and expiring claim
+  token, Task/Plan/Knowledge/Milestone bindings, exact expected-next prompt, optional grant,
+  target-only claim, claimant-only mutation, mandatory claim before Milestone Task start,
+  lease-token binding, and terminal evidence-bound handback.
+- Adoption coverage includes sidecar-only `state adoption-prepare` and `state adoption-apply`,
+  automatic posture initialization for fresh alpha.6 projects, preservation of terminal
+  Milestones and Tasks, preservation of completed and skipped legacy Steps, and execution
+  blocking until posture is present.
+- Compatibility checks passed for `protocolVersion: 1`, `STATE_SCHEMA_VERSION: 2`, unchanged
+  canonical Task and Milestone shapes, and unchanged delegated transition allow-list.
+- Gateway handshake coverage includes the alpha.6 capabilities:
+  `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`, and
+  `alpha6-adoption-posture-v1`, plus strengthened contracts advertised as
+  `semantic-plan-risk-audit-v2`, `guarded-remediation-hard-stop-v1`,
+  `milestone-reverse-membership-integrity-v1`, and `task-c1-handoff-bundle-v2`.
+- npm dry-run packaging produced `codex-workflow-v2-2.0.0-alpha.6.tgz` with runtime, schemas,
+  references, docs, and plugin source. Downstream installation and the packaged CLI handshake
+  passed, and the install created none of `.codex`, `.tasks`, `.increments`, or
+  `.memory-bank` in the temporary project.
 
-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.
+Not claimed here:
+
+- no final release publish;
+- no final task audit beyond the recorded subtask evidence;
+- no new real-Codex isolation probe beyond the existing fail-closed strict-reviewer
+  implementation and its automated coverage.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-workflow-v2",
-  "version": "2.0.0-alpha.4",
+  "version": "2.0.0-alpha.6",
   "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,154 @@ 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:
+
+- 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`
+
+Protocol `1` and schema `2` remain valid only because alpha.6 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:
 
-## Milestone Human Gate
+```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.6 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, and bind guarded failure modes to exact Step checks. 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`.
+
+## 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. No thread id is required or accepted as authority.
+
+## Milestone scope change and human gate
+
+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 path is human-only. 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 +183,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, Milestone scope change, or any other new
+human-only alpha.6 action.
+
 ## Graph Refresh Request
 
 The package returns:

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

@@ -38,6 +38,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 +61,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 +103,13 @@ 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`.
 
+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.
+
+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,21 @@ 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.6 keeps canonical entity JSON unchanged at `stateSchemaVersion: 2` and adds lifecycle
+evidence through sidecars. `protocolVersion: 1` remains valid only because the alpha.6
+surface is additive and capability-advertised.
+
+Before execution authorization, every alpha.6 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. 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 +36,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 alpha.6 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 +55,21 @@ 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.
 
+After the initial empty planning posture, Milestone scope updates no longer use ordinary
+`milestone plan-set`. They must go through `milestone scope-change-prepare` and
+`milestone scope-change-apply`, which journal `state.json`, `plan.json`, and
+`scope-change-events.jsonl` together and remain human-only. 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. 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.

package/roles/delivery-coordinator.md

@@ -14,4 +14,15 @@ Own state transitions, dispatch envelopes, evidence collection, and recovery gui
 - Accept a Milestone only after a later user message explicitly approves that exact
   confirmation code. Do not infer approval from a request to validate, finish, or continue.
 - Dispatch one Worker at a time for a concrete Step.
+- A Milestone coordinator creates one dedicated user-visible Codex Task chat for each required
+  Task. The Milestone chat owns ordering, exact delegated approvals, merge observation,
+  validation, and final acceptance; it does not accumulate implementation for every Task.
+- Before authorizing a high-risk Plan, require the Technical Planner's migration/concurrency/
+  restart/crash/provider risk review and failure-specific checks.
+- After a second failed independent Task review, require a separate corrective Plan Auditor
+  and pass its evidence through `--corrective-audit-file`. Continue only for
+  `decision=continue-fix`; replan/split/stop decisions return to the coordinator or user.
+- Use `task context-refresh` only when `next.contextRefresh` offers the exact delegated,
+  content-only option. Classification, authority, source-set, gap, or conflict changes still
+  require the ordinary visible Knowledge Map flow.
 - Do not make product-scope decisions or implement production changes.

package/roles/independent-reviewer.md

@@ -7,4 +7,7 @@ Compare requirements, acceptance, Plan, task-branch diff, checks, and generated
 - Operate read-only and do not fix findings.
 - Mark the review `unverified` when read-only isolation or required evidence is unavailable.
 - A failed review must contain actionable findings; a passed review contains none.
+- For migrations, concurrency, restart/replay, crash recovery, and external providers, reject
+  green happy-path evidence that omits populated upgrades, deterministic races, restart/crash
+  windows, or provider failure/default behavior required by the approved Plan.
 - Do not grant final acceptance on behalf of the user.

package/roles/technical-planner.md

@@ -6,5 +6,12 @@ Translate an approved Brief into an execution-ready Plan.
 - Declare `knowledgeImpact`, its reason, targets, and `graphUse`; do not hide missing knowledge as an implementation choice.
 - Every requirement must be covered by at least one `STEP-*`.
 - Each Step declares dependencies, outputs, allowed writes, forbidden scope, and checks.
+- Perform a risk review before `plan-set`. A Plan that touches migrations, concurrent state,
+  restart/replay, crash recovery, or an external provider must include failure-specific checks
+  in the original Steps: populated forward upgrades, deterministic races, restart/crash
+  windows, and provider failure/default behavior as applicable.
+- Split a Task when one acceptance slice would otherwise combine persistence migration,
+  recovery orchestration, and executable composition. Do not use arbitrary line/file limits;
+  split on independently verifiable failure boundaries.
 - Do not edit production files or silently expand the Brief.
 - Return unresolved semantic choices to the user through the Delivery Coordinator.

package/roles/worker.md

@@ -7,4 +7,8 @@ Implement exactly one dispatched Step under its context envelope.
 - Read only declared inputs and repository context needed for the Step.
 - Write only `allowedWrites`; stop on required scope expansion.
 - Run the declared checks and report limitations honestly.
+- Leave all Step changes uncommitted. Do not run `git add`, `git commit`, `git amend`,
+  reset, rebase, or another Git-history mutation. The coordinator invokes
+  `task step-complete`; Workflow core then runs the configured checks, creates the atomic
+  Step commit, and records its evidence.
 - Do not edit the Brief, Plan, acceptance, other Steps, workflow state, or Git history manually.