codex-workflow-v2 2.0.0-alpha.3 → 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,137 @@ 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 не включается автоматически после обновления. Существующие авторизации и
+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.
+
+Рекомендуемые названия чатов:
+
+```text
+NN - M2 delegated coordinator
+NN - M2/T1 delegated execution
+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,28 +1,51 @@
 # V2 Alpha Validation Report
 
-Release candidate `2.0.0-alpha.3` 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 41 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.
-- 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.3.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.3`.
-- The alpha.3 CLI read the existing Signal project state created by alpha.2 without migration:
-  project ID and accepted Milestone 1 were preserved, while repository-level `next` returned
-  `idle` instead of the historical cancelled Task.
+- `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.3",
+  "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,12 +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`.
+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
@@ -29,6 +171,21 @@ codex-workflow milestone accept --repo <git-root> --id <MS-ID> \
 Do not infer approval from the request that initiated validation. A changed revision, hash,
 or HEAD requires a new gate.
 
+## Delegated Approval
+
+`delegation prepare --file <policy.json>` returns a `delegation_grant_issuance` gate with a
+project-bound policy hash and `DGA-*` confirmation code. Display it and end the turn. A later
+explicit user message containing the exact code permits `delegation grant`.
+
+Active eligible grants appear in `next.delegatedApprovalOptions`. Use only the option whose
+transition matches the requested command, with the named delegate as actor and the grant ID
+as `--delegation-grant`. The resulting authorization event records the grant and both actors.
+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,14 +61,20 @@ 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.
 
 ## Human Gates
 
-Treat `requiredHumanGate` from the project-local package as a mandatory turn boundary.
+Treat `requiredHumanGate` from the project-local package as a mandatory turn boundary unless
+the same `next` response contains a currently eligible `delegatedApprovalOptions` entry for
+the exact transition and the agent is the entry's named delegate.
 For `milestone_final_acceptance`, show the user the Milestone ID, revision, Plan hash,
 Result hash, evidence hash, validated HEAD, and confirmation code. Ask whether the user
 accepts that exact result, then stop without invoking `milestone accept`.
@@ -75,6 +85,31 @@ A generic instruction such as “continue”, “finish”, or “bring it to fi
 final acceptance. If `next` returns a different code or binding, discard the old response
 and ask again.
 
+## Delegated Approval
+
+Delegation issuance is itself a mandatory human turn boundary. Run `delegation prepare` with
+the proposed policy, show the complete principal, delegate, scope, transitions, expiry,
+policy hash, and `DGA-*` confirmation code, then stop. Only after a later user message
+explicitly approves that exact code may `delegation grant` be invoked.
+
+Never create, broaden, renew, or replace a grant from an agent's own judgment. Never record
+the delegate as the user. When `next` exposes an eligible option, pass its grant ID through
+`--delegation-grant` and use the exact delegate string as `--actor`. The core remains the
+authority for status, expiry, scope, transition, and revocation checks.
+
+For delegated Milestone final acceptance, the current `MSA-*` code is still required, but a
+new user turn is not: the previously issued grant is the controlling decision. If no eligible
+option is returned, follow the ordinary human-gate rule above. Knowledge Map approval is
+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.
@@ -84,4 +119,4 @@ and ask again.
 - An action would make MCP or the local map authoritative project memory.
 - A requested mutation is not authorized by the package CLI state.
 - A human gate was emitted but the user has not approved its exact confirmation code in a
-  later message.
+  later message and no exact eligible delegated approval option exists.

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,29 @@ 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
+allow-list of approval transitions. Delegated transitions fail closed on actor, scope,
+transition, expiry, revocation, or project mismatch. Their authorization events record
+`authorizationMode: delegated` plus the grant ID, policy hash, principal, delegate, and exact
+transition; the delegate is never recorded as the user.
+
 When an approved Project Knowledge Map changes between Task Steps, the coordinator first
 reconciles and obtains approval for the new map, then uses `task knowledge-rebind`. This
 mechanical transition preserves Step definitions, runtime status, and evidence, records both
@@ -13,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
@@ -21,6 +50,25 @@ valid only after a later explicit user response repeats that code; the CLI requi
 explicit actor and the exact code. Cancellation records intent but performs no Git reversal.
 If the base HEAD or final artifacts change before acceptance, `next` withholds the gate and
 requires Milestone validation again; revalidation supersedes the previous candidate binding.
+An already issued grant containing `milestone.final_accept` may cross that gate autonomously,
+but the acceptance command still requires the current `MSA-*` code so the use remains bound
+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