codex-workflow-v2 2.0.0-alpha.6.2 → 2.0.0-alpha.7.1

package/docs/alpha7.1-implementation-brief.md

@@ -0,0 +1,268 @@
+# codex-workflow-v2 2.0.0-alpha.7.1 implementation brief
+
+## Status and authority
+
+This document is the single source of truth for the local `2.0.0-alpha.7.1`
+release candidate. It was authorized in the current Codex task on 2026-08-14.
+Workflow V2 must not be used to organize or authorize this development work.
+
+The candidate is based on the published tag `v2.0.0-alpha.7` at commit
+`b7ce0b5e14791e8177c104a2344dfb46f459696f` and is developed in the standalone
+repository `/Users/home-pc/htdocs/codex-workflow-v2` on the isolated branch
+`codex/workflow-v2-alpha7-1`.
+
+No tag, push, or npm publication is authorized. The `signal_v4` repository,
+its external Workflow state, and its Milestone 3 state are read-only evidence
+and must not be changed.
+
+## Problem statement
+
+Alpha.7 adds a bounded Milestone autonomy contract, but its guarded remediation
+state machine is not internally consistent after a strict Step review failure
+causes Project Knowledge refresh, Task Knowledge rebind, and delegated
+reauthorization.
+
+The production-shaped failure is:
+
+1. A guarded Step fails two strict reviews and records two ordinary remediation
+   events.
+2. The Step's commits make Project Knowledge stale.
+3. Project Knowledge is reconciled and approved, then the Task Plan is rebound
+   and reauthorized under a new Plan hash.
+4. The Task remains runnable and the failed Step remains the remediation target,
+   but `next` no longer advertises `task corrective-decision` because the gate is
+   derived only for `needs_fix`.
+5. `recordStepCorrectiveDecision` also accepts only `needs_fix` or a narrowly
+   defined `blocked` unverified-review posture, so the advertised and executable
+   transitions can diverge.
+
+This creates a lifecycle deadlock and previously encouraged signal-specific
+rescue patches. Alpha.7.1 must fix the generic transition semantics. It must not
+hard-code repository names, Task IDs, Step IDs, revisions, commits, Plan hashes,
+or package-upgrade rescue identities.
+
+The real-agent E2E exposed a second autonomy deadlock. A normal Task that adds a
+new test can cause the repository scanner to add that file as a supporting
+Knowledge source. The Milestone autonomy contract currently permits only
+content-hash-only atomic refresh, so the new source forces another human approval
+even when its exact path, category, authority, and reason were declared in the
+authorized Task Plan. Alpha.7.1 must distinguish such Plan-bounded supporting
+source additions from unplanned source-set or authority changes.
+
+## User outcomes
+
+1. A Milestone coordinator can execute a bounded Milestone autonomously without
+   asking for repeated human approvals covered by the Milestone autonomy
+   contract.
+2. A guarded Step gets at most two ordinary remediation attempts, then exactly
+   one independently audited corrective attempt when `continue-fix` is chosen.
+3. Project Knowledge refresh, Task Knowledge rebind, and delegated
+   reauthorization preserve the remediation posture rather than losing or
+   bypassing it.
+4. `next` always recommends a transition that the corresponding command can
+   execute from the same immutable state, subject only to the evidence explicitly
+   named by that recommendation.
+5. A third failed guarded remediation reaches a hard stop. Only split or stop
+   escalation is permitted; a fourth run is impossible.
+6. Discovery quality is checked, but ordinary human incompleteness and
+   non-blocking unknowns do not require the user to pre-plan agent behavior.
+7. A Task may add a supporting Knowledge source declared by its already
+   authorized Plan without creating another human gate; undeclared additions,
+   canonical-source additions, removals, authority/category changes, gaps, and
+   conflicts still fail closed.
+
+## Required state-machine semantics
+
+### R1 — generic corrective posture
+
+Derive the corrective posture from the current guarded Step, current Plan Risk
+Audit, remediation history, and corrective-decision history. Do not infer it
+solely from `Task.status`.
+
+The derivation must work when the same failed guarded Step is represented in any
+legitimate post-failure/post-refresh status produced by the Workflow, including
+`needs_fix`, post-rebind `ready`, post-authorization `ready`, and the existing
+blocked/unverified strict-review retry posture.
+
+### R2 — `next`/command consistency
+
+If a guarded Step has two failed remediation events and no decision for attempt
+3, `next` must advertise `task corrective-decision` before `task run` regardless
+of a content-only Knowledge refresh, Plan rebind, or delegated reauthorization.
+
+When `next` advertises `task corrective-decision`,
+`recordStepCorrectiveDecision` must accept the same Task/Step state with the
+recommended revision, Plan Risk Audit, actor/lease posture, and independent
+auditor evidence.
+
+### R3 — Plan rebind continuity
+
+Knowledge rebind may create a new Plan hash. Historical remediation events remain
+immutable. A corrective decision is bound to the current Plan hash and the exact
+covered remediation event IDs. Rebind must not reset attempt counts or permit a
+third ordinary attempt.
+
+### R4 — bounded recovery
+
+- Attempts 1 and 2 are ordinary.
+- Attempt 3 requires an independent corrective decision.
+- `continue-fix` enables exactly the third corrective attempt.
+- `replan-required` requires an actual new Plan posture before execution.
+- `split-required` and `stop-escalate` block execution.
+- After a third failed remediation event, `next` must expose a stable hard-stop
+  action and must not throw while merely reporting status.
+- A fourth `task run` and a fourth `continue-fix` decision are prohibited.
+
+### R5 — priority ordering
+
+Pending strict review for an already recorded completion commit outranks
+Knowledge refresh. After that review is terminal, required Project Knowledge
+refresh and Task Knowledge rebind remain mandatory. Once current knowledge and
+authorization are restored, an outstanding corrective decision outranks another
+run. C1 claim/handoff constraints remain authoritative and must not be bypassed.
+
+### R6 — Milestone autonomy
+
+The alpha.7 Milestone autonomy contract remains bounded by its immutable semantic
+scope, delegate, expiry, policy hash, and allowed transitions. It may cover
+Milestone execution/final acceptance, Task execution/final acceptance, and
+content-only Project Knowledge approval. Semantic scope changes still require
+new human authority. Alpha.7.1 must not broaden these permissions.
+
+### R7 — Plan-bounded supporting-source refresh
+
+The user explicitly authorized this bounded delegated-approval expansion in the
+current Codex task after the real-agent E2E exposed the supporting-source
+deadlock. The authorization is limited to the complete fail-closed predicate
+below.
+
+The atomic delegated `task context-refresh` transition may accept a newly
+discovered Knowledge source only when all of the following are true:
+
+- the active Task belongs to the Milestone named by the autonomy grant;
+- the current authorized Task Plan declares `knowledgeImpact: create` and an
+  exact `knowledgeTargets` entry for the new path and category;
+- the scanner classifies that exact path and category as `supporting`;
+- no previously approved source is removed;
+- no existing source changes category or authority;
+- no unplanned source is added;
+- gaps and conflicts are unchanged and no new conflict exists.
+
+The transition remains atomic: reconcile, approve the exact safe candidate,
+rebind Task Knowledge, and supersede execution authorization together. It must
+not permit standalone Project Memory approval, canonical-source creation,
+wildcard/directory targets, or mutation beyond the Task's current Plan and the
+existing Milestone autonomy policy. `next` must expose this delegated refresh
+only when the complete predicate is satisfied and otherwise report the concrete
+unsafe differences.
+
+## Required tests
+
+### Deterministic replay (release-blocking)
+
+Add a production-shaped regression using opaque, non-hard-coded Step IDs. It must
+replay the complete sequence:
+
+1. Milestone autonomy and delegated Task authorization.
+2. Guarded Step completion and strict-review failure 1.
+3. Ordinary remediation, completion, and strict-review failure 2.
+4. Project Knowledge staleness, content-only reconcile/approval, Task Knowledge
+   rebind, refreshed Plan Risk Audit, and delegated reauthorization.
+5. `next -> task corrective-decision` and successful recording by an auditor
+   distinct from the latest strict reviewer.
+6. Corrective attempt 3 and successful strict review, followed by Task completion.
+7. A sibling replay where attempt 3 fails and proves stable hard-stop reporting,
+   rejection of a fourth run, and rejection of `continue-fix` for attempt 4.
+
+The replay must assert state, sidecar bindings, attempt ordinals, Plan hashes,
+returned actions, and absence of repository-specific rescue logic.
+
+Add a sibling deterministic replay for R7. It must prove that one exact
+Plan-declared supporting test source can be accepted through atomic delegated
+context refresh, while an undeclared source, a canonical addition, a removal,
+and an authority/category change remain ineligible and cannot mutate state.
+
+### Existing suites (release-blocking)
+
+`npm run validate`, `npm run release:check`, `npm run pack:check`,
+`npm run smoke:downstream`, and `npm run plugin:check` must pass sequentially
+under the repository's supported Node version. Parallel build/clean scripts are
+not valid evidence because they race on shared output directories.
+
+### Real-agent isolated E2E (release-blocking)
+
+Create `test-runs/2.0.0-alpha.7.1/project` as a disposable repository inside the
+standalone project. Use the sibling `codex-home`, `workflow-state`, `plugin-root`,
+`npm-cache`, and `evidence` directories for complete isolation. Install the
+candidate from a local `npm pack` tarball, not the public registry. The globally
+installed Codex Workflow plugin remains disabled; the real agent loads only the
+candidate gateway from the isolated plugin root.
+
+Run a real Delegate agent through:
+
+`initial Discovery -> Milestone -> bounded Milestone autonomy -> Tasks -> strict
+review/remediation and Knowledge refresh -> merge/handback -> Milestone validate
+-> delegated final accept`.
+
+The Milestone must be small enough to finish but contain at least three Tasks:
+
+1. A bounded safe-contract implementation Task that adds a Plan-declared
+   supporting test source and exercises the R7 atomic refresh path.
+2. A guarded persistence/documentation Task that causes content drift and two
+   deterministic strict-review failures before a bounded corrective success,
+   exercising reconcile, rebind, and reauthorization.
+3. A composition/acceptance Task that closes the Milestone.
+
+The initial Discovery prompt should imitate a real product-owner request: desired
+outcome, examples and constraints are present, while implementation details,
+exact Step decomposition, retry mechanics, and some non-blocking design choices
+are deliberately omitted. The agent must discover and resolve what it can,
+record non-blocking unknowns honestly, and proceed without asking the user to
+predict its implementation behavior. The signal_v4 M3 Discovery may be used as
+read-only style evidence, but its domain and identifiers must not be copied into
+the candidate logic.
+
+E2E acceptance requires the Milestone to reach final acceptance, all Tasks to be
+terminal, repository state clean, no active or stale writer leases, no action
+requiring human approval inside the granted semantic scope, and an evidence log
+that identifies every command/action and final entity status without secrets.
+The run must include at least one new supporting test source admitted through the
+R7 atomic delegated context-refresh path; manually approving that source is not
+acceptable passing evidence.
+
+## Ownership and integration
+
+- Main coordinator: owns this Brief, integration, local tarball, isolated E2E,
+  final evidence, and all decisions that cross file ownership.
+- State-machine implementer: owns production changes in `src/` and directly
+  related contracts/reference documentation. Must not edit E2E evidence.
+- E2E/test owner: owns deterministic regression tests, fixtures, and isolated E2E
+  harness documentation/scripts. Must not change production semantics without a
+  written finding to the coordinator.
+- Independent auditor: starts only after implementation and E2E evidence are
+  complete; reviews Brief-to-diff traceability, test validity, release artifacts,
+  and residual risks without editing implementation files.
+
+All contributors share the worktree, must preserve concurrent edits, and must not
+revert changes they did not create.
+
+## Stop-loss and release gate
+
+All local iterations retain version `2.0.0-alpha.7.1`; individual failures do not
+create alpha.7.2/alpha.7.3 versions. No publication occurs until deterministic
+replay, the real-agent Milestone, and independent audit all pass.
+
+If real-agent execution cannot be completed because Codex cannot be launched with
+the required isolation or cannot exercise a deterministic failure seam, that is
+a release blocker, not permission to substitute a mocked test.
+
+## Deliverables
+
+1. This Brief.
+2. Generic source diff and reference documentation.
+3. Deterministic replay and all package validation evidence.
+4. Local alpha.7.1 tarball identity and downstream installation evidence.
+5. Real-agent E2E evidence through Milestone final acceptance.
+6. Independent audit with every finding resolved or explicitly accepted by the
+   user.
+7. Remaining risks and a release recommendation. No tag, push, or publish.

package/docs/autonomy-guardrails.md

@@ -1,11 +1,11 @@
 # Autonomous Development Guardrails
 
 These rules keep delegated execution autonomous without turning approval into a rubber stamp.
-Alpha.6 adds no persistent canonical state fields and keeps `stateSchemaVersion: 2`.
+Alpha.7 adds no persistent canonical entity fields and keeps `stateSchemaVersion: 2`.
 
 ## Plan Risk Audit
 
-Before execution authorization, every alpha.6 Task needs a current Plan Risk Audit sidecar
+Before execution authorization, every alpha.7 Task needs a current Plan Risk Audit sidecar
 bound to the current Brief, Plan, and approved Knowledge Map. This is mandatory even when all
 Steps are unguarded and the decision is `approved`.
 
@@ -15,6 +15,8 @@ The payload must classify every current Step exactly once and declare:
 - `decision`: `approved`, `approved-with-rationale`, `split-required`, or `stop-escalate`
 - per-Step guarded categories, concrete `failureModes`, and `reviewRequired`
 - `requiredEvidence` entries that exactly match executable checks in that Step
+- one proof obligation per guarded failure mode, with a hostile counterexample, expected safe
+  result, and evidence that exactly matches `requiredEvidence`
 - `splitRationale` when migration is intentionally coupled to recovery or runtime composition
 
 The workflow rejects omitted Steps, extra Steps, duplicate classifications, stale bindings,
@@ -70,15 +72,21 @@ path. The Auditor must differ from the failed-review author and cover every late
 `replan-required`, `split-required`, and `stop-escalate` are stop decisions: Core does not
 start another implementation loop.
 
-For alpha.6 guarded Steps, remediation attempts are also tracked in
+For guarded Steps, remediation attempts are also tracked in
 `remediation-events.jsonl`. Two ordinary remediation attempts are allowed. A third ordinary
 retry is blocked until `task corrective-decision` records a current corrective decision in
-`corrective-decisions.jsonl`. `continue-fix` allows bounded continuation; the other decisions
-stop or redirect ordinary execution. If that third, corrective remediation review also fails,
-Core enters a hard stop: a fourth run and another `continue-fix`/`replan-required` decision are
-rejected. Only `split-required` or `stop-escalate` may be recorded.
-
-## Content-only context refresh
+`corrective-decisions.jsonl`. The corrective gate is derived from the guarded Step, current
+Plan Risk Audit, remediation history, and corrective-decision history, so it remains visible
+after content-only context refresh, Task Knowledge rebind, and reauthorization. `continue-fix`
+allows bounded continuation; `replan-required` requires an actual new Plan posture before
+execution; the other decisions stop or redirect ordinary execution. If that third, corrective
+remediation review also fails, Core enters a hard stop: `next` must report the stop without
+throwing, a fourth run and another `continue-fix`/`replan-required` decision are rejected,
+and only `split-required` or `stop-escalate` may be recorded. At the corrective boundary,
+`next` derives a distinct `agent:corrective-auditor:<task-id>` actor; selecting that actor is
+not a human approval, while auditor independence remains mandatory.
+
+## Atomic context refresh
 
 When `next.contextRefresh` offers an exact option, a project-scoped delegate may run one
 composite transition:
@@ -92,10 +100,20 @@ task context-refresh
 ```
 
 The command requires the exact Task and Knowledge Map revisions, delegate actor, and grant.
-Core validates both grant transitions before the first write. It is allowed only when an
-already approved source set has content-hash drift and its category, scope, authority, gaps,
-and conflicts are unchanged. New or removed sources and any classification/authority change
-stop on the ordinary visible Knowledge Map flow.
+Core validates both grant transitions and the complete Knowledge diff before the first write.
+The existing content-only path remains limited to an already approved source set whose category,
+scope, authority, gaps, and conflicts are unchanged.
+
+A Milestone Autonomy Grant may additionally admit a new supporting source when the current,
+already execution-authorized Task Plan declares `knowledgeImpact: create` and the source's exact
+normalized file path and scanner category in `knowledgeTargets`. Every added source must match;
+wildcards and directory-like targets are not authority. The Task must belong to that exact
+Milestone and the delegate and grant must still satisfy the immutable autonomy contract. Removed
+sources, canonical additions, unplanned additions, changes to existing category/scope/authority
+or classification identity, changed gaps, and changed or non-empty conflicts fail closed before
+state is written. `next.contextRefresh.addedSources` exposes the exact eligible additions, while
+`next.contextRefreshBlocked.unsafeDifferences` reports the concrete mismatches.
+Standalone Project Memory approval is never enabled by this path.
 
 ## Chat ownership
 
@@ -113,7 +131,13 @@ An expired lease is also a blocker until the ordinary explicit stale-lock repair
 The command is read-only and reports every blocker. It does not install a package or migrate
 state. When `stateSchemaVersion` remains `2`, the external project state is reused unchanged.
 Existing schema 2 projects then use `state adoption-prepare` and `state adoption-apply`; they
-do not use `state migrate` for alpha.6 adoption.
+do not use `state migrate` for schema-2 adoption.
+
+Alpha.7 also exposes `update rescue-preflight` for one narrow alpha.6 deadlock: a pending strict
+review whose completion commit changed canonical knowledge while Knowledge rebind is forbidden
+by the still-in-progress Step. Eligibility requires an exact alpha.6 dependency, one pending
+review, exact clean completion HEAD, valid history, and no active lease. The command is read-only
+and returns only stale-lock repair plus strict-review actions.
 
 ## Milestone closure
 
@@ -123,15 +147,27 @@ compare Result, evidence, Plan hash, and validated HEAD. A delegate may accept o
 exact `milestone.final_accept` option, must remain the recorded actor, and must pass the
 current `MSA-*` code. Without that option the ordinary later-message human gate applies.
 
-## Human-only Milestone scope change and C1 handoff
+## Bounded Milestone autonomy and C1 handoff
+
+Initial assembly may materialize every linked Task before one complete `milestone plan-set`;
+the Milestone cannot execute until all reverse memberships are classified. Ordinary semantic
+scope change remains explicit and human-only through `milestone scope-change-prepare` and
+`milestone scope-change-apply`.
 
-Milestone scope change beyond the initial empty planning posture is explicit and human-only:
-use `milestone scope-change-prepare` and `milestone scope-change-apply`. The change is
-journaled across `state.json`, `plan.json`, and `scope-change-events.jsonl`, and delegated
-approval never authorizes it.
+After the initial Plan, one human may approve a time-bound (maximum 72 hours) Milestone
+Autonomy Contract. It creates a milestone-scoped grant for Task/Milestone execution and final
+acceptance plus Project Memory approval only inside an atomic Task context refresh for the same
+Milestone. That refresh covers content-only drift and the exact Plan-bounded supporting-source
+addition described above. Standalone Project Memory approval remains forbidden. The contract binds
+the immutable outcome, success signal, acceptance, checks, discovery, and base branch.
+`milestone autonomy-evolve` may only alter Task memberships; it records the
+agent actor plus the autonomy-contract event hash in the journaled scope-change sidecar and
+supersedes execution authorization. Any semantic drift, expiry, revocation, actor mismatch,
+or contract hash mismatch fails closed.
 
 `C1` handoff uses `task handoff-prepare`, `task claim --claim-token ...`, and terminal
-`task handback-create`. Preparation returns a one-time token and prompt bound to a stable
+`task handback-create`. When target actor is omitted, Core derives
+`agent:worker:<task-id>`. Preparation returns a one-time token and prompt bound to a stable
 `handoffId`, revision, Brief/Plan/Knowledge hashes, Milestone and Task display numbers,
 expected next action, delegate/grant, creation time, and expiry. Only the claim-token hash is
 stored; `task handoff-show` cannot recover it. Claim fails closed on expiry, actor, token,

package/docs/decisions.md

@@ -80,7 +80,19 @@ This document closes the requirement gaps identified during the V2 design review
 15. **Safe update preflight.** Dependency updates begin with a read-only preflight requiring
     a clean checkout, no running Step, and no active writer lease. It does not install,
     migrate, or mutate project state.
-16. **Claimed-C1 rescue is one guarded transition.** The alpha.6.1 backport may bypass only
-    the stale Knowledge binding that blocks one exact pending strict review. It requires the
-    original claimant actor and writer token, preserves the lease, rechecks clean completion
-    HEAD and C1 bindings, and never composes stale-lock repair with review.
+16. **Strict-review recovery precedes Knowledge rebind.** A pending strict review is bound to
+    its immutable completion commit, Plan, and historical knowledge binding. It therefore
+    runs before a current-map rebind; the rebind remains mandatory before the next Step. A
+    read-only alpha.6 rescue profile exposes only this exact recovery shape.
+17. **Bounded Milestone autonomy.** Initial linked Tasks may be assembled before one complete
+    membership Plan. One human-confirmed, expiring Milestone contract may then authorize the
+    existing Task/Milestone approval transitions, guarded content-only Task context refresh,
+    and membership-only evolution. Standalone Project Memory approval remains forbidden.
+    Outcome, success signal, acceptance, checks, discovery, and base branch remain immutable;
+    semantic change stays human-only.
+18. **Planning proof obligations.** Every newly recorded guarded audit maps each failure mode
+    to one hostile counterexample, expected safe result, and exact executable Step check.
+    Historical alpha.6 audit events remain readable only to preserve safe lifecycle recovery.
+19. **Derived independent actors.** Core derives stable Task Worker and corrective Auditor
+    actors from Task identity. This removes name-selection pauses without weakening C1 claim,
+    lease, or auditor-independence checks.

package/docs/delegated-approval.md

@@ -52,12 +52,19 @@ delegation.transition
 acceptance still requires the current `MSA-*` code, preserving the revision/hash/HEAD binding;
 the pre-issued grant replaces only the later human-message requirement.
 
-Alpha.6 does not widen this allow-list. Delegated approval does not authorize:
+Alpha.7 does not widen the generic delegation allow-list. Generic delegated approval does not authorize:
 
 - `state adoption-apply`
 - `milestone scope-change-prepare`
 - `milestone scope-change-apply`
-- any replacement human gate for Milestone membership repair or scope decisions
+- semantic Milestone scope changes
+
+A separate `milestone autonomy-prepare` / `milestone autonomy-grant` contract issues one
+milestone-scoped grant over the existing Task/Milestone approval transitions, adds
+membership-only evolution authority, and permits Project Memory approval only as the guarded
+half of an atomic content-only Task context refresh in that Milestone. Standalone Project Memory
+approval remains project-scoped. The contract does not add a generic delegation transition:
+outcome, success signal, acceptance, checks, discovery, and base branch remain immutable.
 
 ## Starting a delegate chat
 
@@ -81,9 +88,9 @@ scope changes are not approval transitions: the delegate stops and asks the user
 Independent Reviewer roles may implement or review work, but the coordinating delegate alone
 uses the grant and passes `--delegation-grant` to the Core transition.
 
-This matters more in alpha.6 because Milestone scope changes are explicitly journaled,
-human-only lifecycle actions. A delegate may continue ordinary Milestone execution only inside
-the already approved scope.
+Ordinary semantic Milestone scope changes remain journaled, human-only lifecycle actions. A
+contract delegate may evolve only the membership graph inside the cryptographically bound
+semantic scope.
 
 ### Milestone delegate prompt
 

package/docs/development-flow.md

@@ -21,9 +21,9 @@ Materialization requires an observable outcome, scope, acceptance criteria, and
 blocking unknowns. No Task identifier or branch exists before this gate. Task authorization
 is hash-bound to Brief and Plan. Later Plan changes supersede it.
 
-In alpha.6, execution authorization also requires a current Plan Risk Audit bound to the same
+In alpha.7, execution authorization also requires a current Plan Risk Audit bound to the same
 Brief, Plan, Knowledge Map, and exact Step set. For existing schema 2 projects upgraded into
-alpha.6, execution additionally requires adoption posture first; remaining legacy scope then
+alpha.7, execution additionally requires adoption posture first; remaining legacy scope then
 uses a bootstrap audit over the preserved non-`completed`, non-`skipped` Steps only.
 The audit names a Plan author and independent auditor, binds each guarded failure mode to
 exact executable evidence, and blocks authorization on `split-required` or `stop-escalate`.
@@ -67,7 +67,7 @@ replay, and crash claims include restart/crash-window evidence; provider work in
 failure injection and hidden-default verification. After two failed independent reviews,
 another Plan requires a distinct corrective Auditor and `--corrective-audit-file`. Only a
 `continue-fix` audit may continue; replan, split, and stop decisions return to coordination.
-For guarded alpha.6 remediation, a third ordinary retry is blocked until a current
+For guarded remediation, a third ordinary retry is blocked until a current
 `task corrective-decision` exists for the same Step and Plan binding. If that corrective
 attempt fails review, the third failure is a hard stop and no fourth run is permitted.
 
@@ -93,10 +93,15 @@ and prevents new linked Tasks from starting. A Task that has started cannot be r
 it can be retained as waived/cancelled with history and reason. Tasks already in progress
 may finish while an amendment awaits authorization.
 
-After the initial empty planning posture, alpha.6 does not use ordinary `milestone plan-set`
-for scope changes. It uses human-only `milestone scope-change-prepare` and
-`milestone scope-change-apply`, with journaled recovery across `state.json`, `plan.json`, and
-`scope-change-events.jsonl`.
+During initial planning, all linked Tasks may be materialized before one complete
+`milestone plan-set`; no execution is available until the Plan classifies every reverse
+membership. After that boundary, semantic changes use human-only
+`milestone scope-change-prepare` and `milestone scope-change-apply`. A previously issued
+Milestone Autonomy Contract may instead use `milestone autonomy-evolve` for membership-only
+changes while the outcome, success signal, acceptance, checks, discovery, and base branch
+remain unchanged. The same contract may complete an atomic content-only Task context refresh
+without a new human gate, but cannot approve Project Memory independently. Both paths retain
+journaled recovery across `state.json`, `plan.json`, and `scope-change-events.jsonl`.
 
 A Milestone has no integration branch. Validation requires all required Tasks to be
 `merged`, checks the current clean base branch, and writes evidence plus Result. Final

package/docs/release.md

@@ -20,18 +20,16 @@ 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:
+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;
-- alpha.6 adoption is presented as `state migrate` instead of posture sidecars.
+- 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
 performed by local validation commands.
-
-The `2.0.0-alpha.6.x` backport line publishes with the dedicated `backport-alpha6`
-dist-tag (or by exact version). It must never move npm's `next` tag, which remains owned by
-the alpha.7 line.

package/docs/updating-existing-project.md

@@ -22,45 +22,15 @@ state schema. Совпадение `stateSchemaVersion` до и после об
 нужна. Для alpha.6 при `stateSchemaVersion: 2` применяется не migration, а sidecar-only
 adoption posture.
 
-## Исключение: claimed C1 strict-review deadlock в alpha.6
-
-Не обновляйте dependency, если alpha.6 Task уже имеет `in_progress` Step с completion evidence,
-pending strict review и stale Knowledge binding. Для такого состояния используйте внешний
-точный runner `2.0.0-alpha.6.1`; сам проект до завершения recovery остаётся закреплён на
-`2.0.0-alpha.6`.
-
-Сначала выполните только `update rescue-preflight`. Продолжать разрешено исключительно при
-`eligible=true` и одной exact action `update rescue-review`. Передайте returned Task ID, Step
-ID, revision, claimant actor и исходный bound writer token. Не выводите token в чат и не
-передавайте другому actor.
-
-Recovery не требует и не допускает предварительный `locks repair`: alpha.6.1 проверяет token
-сразу против существующего lease и C1 hash, затем сохраняет и heartbeat'ит тот же lease в
-единственной guarded review-команде. Active и stale lease допустимы только при exact binding.
-Неверный actor/token, dirty checkout, advanced HEAD, второй pending review
-или посторонний lease блокируют переход без изменения Task state.
-
-После successful review следуйте обычному `next`: reconcile/approve Knowledge Map, выполните
-knowledge rebind, свежую authorization и завершите Task. Только на безопасной lifecycle-границе
-запускайте обычное обновление dependency и gateway.
-
-## Исключение: signal_v4 после двух failed review в alpha.6
-
-Если точный alpha.6 state уже дошёл до Task revision 14/status `ready`, `STEP-001` имеет два
-distinct verified strict-review failure, remediation `attemptCount=2`, а corrective decision
-отсутствует, используйте только внешний runner `2.0.0-alpha.6.2`. Dependency проекта при этом
-остаётся точно `2.0.0-alpha.6`.
-
-Сначала выполните mutation-free `update corrective-rescue-preflight`. Он требует clean checkout
-на exact HEAD `5c63798cc7b8fbb5e1c8b26ebf93876bc642295a`, неизменные Brief/Plan/Milestone bindings,
-claimed C1 и ровно один token-bound lease. Stale lease допустим только при точном совпадении
-claimant/token binding; plaintext token команда не возвращает.
-
-При `eligible=true` команда `update corrective-rescue-apply` принимает исходный actor/token,
-полный corrective Plan, independent `continue-fix` decision audit и отдельный independent Plan
-audit. Она использует канонические переходы, heartbeat'ит существующий lease только после
-проверки actor/token и не удаляет его. Нельзя вручную редактировать state, Brief, Step 2,
-requirements/acceptance или Milestone scope.
+### Исключение для 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. Подготовьте отдельный чат обновления