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

package/docs/autonomy-guardrails.md

@@ -1,321 +1,43 @@
-# Autonomous Development Guardrails
+# Current autonomy and recovery guardrails
 
-These rules keep delegated execution autonomous without turning approval into a rubber stamp.
-Alpha.7 adds no persistent canonical entity fields and keeps `stateSchemaVersion: 2`.
+## Approval and independent evidence
 
-## Plan Risk Audit
+Human approval is the default. A principal can issue an expiring grant to a distinct delegate after confirming its exact code in a later message. Only the current scope and enumerated transition are delegated. Events retain principal, delegate and policy hash; expired, revoked, mismatched or expanded authority is rejected.
 
-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`.
+The grant allow-list covers Knowledge approval, Task execution/final acceptance and Milestone execution/final acceptance. A full Milestone autonomy contract additionally permits membership-only evolution and Knowledge approval inside an eligible atomic Task context refresh. It never permits standalone Knowledge approval, arbitrary semantic changes, grant expansion or self-renewal. Use only the eligible option returned by the same fresh `next` response. Ordinary writer actions do not consume approval grants.
 
-The payload must classify every current Step exactly once and declare:
+Every Plan requires an independent Risk Audit. Guarded risks include persistence changes, concurrency, crash/restart/replay, providers, composition and security boundaries. Each classified failure mode names a hostile counterexample, expected safe result and exact executable evidence. Unsupported or missing proof is not success.
 
-- `planner` and a distinct `auditor`
-- `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
+Strict Step and final Task reviews must be independent of the Worker and coordinator. Follow the mode and packet command returned by Core. External-sealed review uses the complete closed envelope with packet/repository hashes, reviewer task identity, mode and nested review. Changed seals invalidate the result. Native reviewer launch failure is `unverified`, not a semantic failure that creates remediation authority.
 
-The workflow rejects omitted Steps, extra Steps, duplicate classifications, stale bindings,
-and self-contradictory classifications. `split-required` and `stop-escalate` block execution
-authorization. The sidecar, not informal Plan prose, is
-the source of truth for which Steps require strict review.
+## Current recovery
 
-## Audited remediation topology
+| Boundary | Allowed continuation | Preserved invariant |
+|---|---|---|
+| Ordinary failed check/review | Same-Step or same-Task fix and fresh checks/review | Failure count creates no approval or arbitrary stop |
+| Proven Plan obstruction | Independent corrective evidence and advertised replan | Objective, requirements, acceptance and completed evidence remain bound |
+| Mechanically impossible check | Exact `task plan-integrity-recover` route | No synthetic second failure and no arbitrary scope widening |
+| Active downstream proof touches predecessor-owned paths | `task downstream-proof-recover`, then current planning | Preserve product bytes/HEAD; invalidate only proven predecessor authority |
+| Knowledge-only drift | Current rebind or eligible atomic context refresh | No semantic Plan rewrite, implicit grant or writer replacement |
+| Pending transaction | Exact advertised recovery | Replay/rollback and readback preserve one coherent state |
+| Explicit structural split | Report the current unsupported boundary | No manual topology rewrite or disabled replacement invocation |
 
-A current pre-execution `stop-escalate` may prove that the Plan is blocked by a missing upstream
-capability rather than by an implementation defect inside the Task. Beta.12.10 handles only this
-shape without a new human approval. Repository `next` first requires one ordinary Discovery whose
-facts, scope, constraints, and acceptance describe the exact missing capability. When ready, it
-advertises `milestone remediation-materialize` with the blocked Task/Milestone revisions, audit
-binding, and required predecessor frontier.
+Check-support recovery derives its scope from the actual failed check and exact support path. Dirty files must remain inside the proven boundary and outside forbidden scope. Core owns completion and review; the added path never authorizes adjacent files.
 
-The transition is safe by construction rather than by agent judgment. Its input cannot supply a
-replacement Milestone outcome, success signal, acceptance, checks, or arbitrary membership graph.
-Core appends one required Task, copies the blocked Task's exact direct predecessor frontier, adds
-the remediation Task as one new dependency of the blocked Task, and changes nothing else. It runs
-under an idle, clean observation boundary and records one hash-chained `audited-remediation`
-scope-change event. Reuse of the same Plan Risk Audit is rejected.
+Retained dirty carryover admits a newly planned replacement start only when current Step ownership and the recorded HEAD/path/content bindings match. A failed retry uses its current effective scope. Historical carryover is not new authority to reinterpret a failed Step. Tampered evidence and unrelated dirty paths remain blockers.
 
-The previous current Milestone execution authorization and exact blocking audit derive a new
-`corrective-derived` Milestone execution authorization. While that authority remains current,
-`next.correctiveDerivedApproval` may authorize and finally accept required Tasks using the exact
-derived actor, without a human or delegation grant. This does not bypass Plan Risk Audit,
-mechanical feasibility, C1 handoff, Step checks/commits, strict review, Task review, dependency
-runnability, clean-Git requirements, or final Milestone acceptance. Any later arbitrary scope
-change supersedes this authority.
+For current native check failures started without a C1 claim, Core records the verified execution actor and the historical no-C1 boundary in the failure evidence. A repeated-cause replacement retains those exact bytes only after a fresh claim by that actor and the normal Plan, audit and authorization checks. This is not a fabricated yield or a repair of histories that lack the receipt.
 
-Guarded categories cover:
+A started failed Task retains its claimant through corrective yield, planning and credential recovery. Knowledge refresh does not issue a writer credential or resolve a semantic Plan conflict. Current `next` and the executor must use the same admission conditions at these intersections.
 
-- forward database or state migrations;
-- concurrent ownership, queues, cursors, compare-and-swap, or locking;
-- restart, replay, recovery, or crash windows;
-- external provider lifecycle, hidden retries, defaults, timeouts, or error mapping;
-- runtime composition boundaries, security boundaries, auth/secrets, and irreversible execution.
+An unstarted required Task with a current blocking audit may use the advertised audited-remediation route: append one upstream Task, preserve the merged predecessor frontier and Milestone semantics, merge that Task, then replan the original. This is not arbitrary Task replacement. Derived Task approval never bypasses checks, independent review or final Milestone acceptance.
 
-The original Plan must contain the corresponding failure evidence. A migration needs a
-populated forward-upgrade scenario, not only a clean bootstrap. Concurrent state needs
-deterministic race tests. Recovery needs restart and crash-window evidence. Provider work
-needs failure injection and verification of provider defaults. When persistence migration,
-recovery orchestration, and executable composition form independently verifiable failure
-boundaries, they are separate Tasks rather than one oversized Task.
+Existing append-only history remains verifiable. Readers of already recorded events do not authorize new execution of retired package-version repair procedures. No old-version runner or source-specific update recipe is supported.
 
-For adopted legacy Tasks, the bootstrap audit covers only the remaining non-`completed` and
-non-`skipped` Steps recorded at the adoption boundary.
+## Ownership and stopping
 
-## Strict Step Review
+Claim and writer credentials use local credential references bound to project, entity, action and actor. Do not pass raw bearer tokens in CLI arguments, prompts or evidence. A pending claim blocks competing execution; a claimed Task keeps its exact actor. Handoff evidence alone does not prove a physically independent reviewer.
 
-If the current Plan Risk Audit marks a Step for strict review, `task step-complete` still
-creates the workflow-owned commit, but the Step stays non-terminal and `next` routes to
-`task step-review`. Canonical completion is recorded only after the strict review and the
-reviewer attestation both bind to that exact completion commit.
-When `next` advertises `task step-review`, pass the exact claimant or required actor as
-`--actor`; the isolated reviewer identity is created inside Core and must not be substituted
-into the mutation actor slot.
+A real confirmation gate requires the displayed state and a later exact user response unless a current eligible delegation already authorizes it. Scope changes retain their own consent. Infrastructure denial is not a Workflow grant failure; report its real layer and use only authorized recovery. Never restart services or change product checks to conceal an access failure.
 
-Invalid or stale review sidecars fail closed. The workflow blocks downstream acceptance and
-normal continuation when review evidence is malformed, unverified, or commit-mismatched.
-
-## Repeated failed review and continuable remediation
-
-A failed final Task review returns the same Task to `needs_fix` and requires a changed or new
-remediation Step. The failed-review count is diagnostic evidence, not a lifecycle limit: another
-Plan does not require a separate corrective Plan Auditor merely because two or more reviews failed.
-Every replacement Plan must preserve the Task objective, requirements, and acceptance; changing
-those commitments requires an explicit scope decision outside ordinary remediation.
-
-For guarded Steps, every failed review is recorded in `remediation-events.jsonl`. Attempts one and
-two retain mode `ordinary`; later attempts use mode `corrective`, but the mode does not impose a
-maximum attempt ordinal. `next` continues to return `task run` for the same failed Step, and every
-new completion still requires a fresh strict review bound to its exact commit. Therefore repeated
-fixes cannot create an approval, while a fourth, tenth, or later reviewed attempt remains possible.
-
-Each failed review finding may carry `route: fix` or `route: replan`. `fix` is the backward-compatible
-default. `replan` is accepted only with `planConflict.planClause`, `whyFixCannotFit`, and
-`minimalPlanChange`; Core retains that evidence in the hash-chained Step-review event and routes
-the failed Step to `task plan-set`. Replan may change implementation Steps only. Explicit historical
-`continue-fix`, `replan-required`, `split-required`, and `stop-escalate` decisions remain readable;
-an explicit split or stop still outranks ordinary execution except for the narrow beta.11
-attempt-four stop compatibility route below.
-
-### Human-confirmed beta.11 attempt-four stop compatibility
-
-Beta.12.1 can resume one historical shape that beta.11 stopped mechanically: the same failed
-guarded Step has exactly two `ordinary` remediation events, one `corrective` third event, an exact
-attempt-3 `continue-fix` decision, and an attempt-4 `stop-escalate` decision under the unchanged
-Plan. Fresh `next` advertises `task stop-override-prepare` only for that shape and only on a clean
-local Task branch with no Step in progress, writer lease, Task transaction, or Core operation.
-
-Preparation is read-only and binds Task revision, Step, both corrective decisions, all three
-remediation events, Plan hash, Git HEAD, package version, actor, and reason to an `SOO-*`
-confirmation code. In a later explicit user turn, invoke `task stop-override-apply` with the same
-inputs and code. Apply appends `stop-escalate-overrides.jsonl`; it never deletes or rewrites the
-original stop. A stale binding, wrong code, duplicate/conflicting override, or damaged hash chain
-fails before continuation. Delegation is not accepted for this Human gate.
-
-This is not a general stop reversal. It does not apply to `split-required`, semantic Plan drift, a
-different attempt ordinal, missing attempt-3 continue authority, or an agent-authored semantic stop
-outside the beta.11 policy shape. After a valid append, attempt four returns to the normal `task run`
-then strict-review cycle; review quality and all later corrective decisions remain unchanged.
-
-Beta.12.4 also handles the case where the accepted third attempt changed approved Project Knowledge
-and package self-updates added later refreshes: the already-applied override may be followed by one
-or more ordinary delegated `task context-refresh` transitions before attempt four starts. A fresh
-`next` resumes `task run` only when Core can prove all of the following together: the same exact
-three-event remediation history and stop override remain hash-valid; every adjacent Plan differs
-only in its canonical Knowledge Map binding line; the Knowledge rebinds and mechanical Plan Risk
-Audit rebounds form one contiguous source-to-current chain; and the refreshed approval plus current
-execution authorization share the valid delegated authority. If Git HEAD advanced, every
-intervening commit must have one exact registered dependency-provenance recovery, one parent, a
-`systemCommits` binding, and exactly the `package.json`/`package-lock.json` diff. The proof is derived
-from existing append-only evidence, so this route does not create a second recovery journal.
-Missing evidence, semantic Plan change, an unregistered/product commit, a broken chain, or damaged
-chronology routes to `doctor` rather than weakening the generic two-attempt corrective recovery gate.
-
-If fresh navigation performs the final content refresh before the matching dependency-provenance
-recovery, that later administrative recovery may advance the Task revision without invalidating the
-mechanical audit. Core accepts the revision only when the exact count of post-audit recovery records
-fully explains the difference: each record must belong to the already verified single-parent Git
-chain, remain ordered, bind a Workflow system commit, and preserve the exact two-file dependency
-diff. A bare greater revision, unrelated Task write, duplicate record, damaged parent, product
-commit, or unverified recovery remains blocked.
-
-### First-failure Plan-integrity recovery
-
-A mechanically impossible Plan check must not consume another attempt merely to unlock its known
-correction. After the first guarded `checks-failed` event, Core performs a read-only bounded
-assessment. Existing missing-script and required-selector conflicts route to corrective replan.
-beta.12.16 additionally recognizes one exact check-support conflict when all of the following hold:
-
-- the failed Step contains an exact root `npm run <script>` check and declares an absent migration
-  output path that is inside its original `allowedWrites`;
-- the root script resolves to a repository-local runner whose direct static import resolves to a
-  tracked checksum/catalog support module;
-- that support module has SHA-256 anchors and names an existing migration in the same file family,
-  but is outside the Step's `allowedWrites` and `forbiddenScope`;
-- exactly one ordinary `checks-failed` remediation event exists for the Step;
-- no corrective decision exists for its second-attempt binding;
-- every dirty file remains inside the Step's current `allowedWrites` and outside its
-  `forbiddenScope`.
-
-The recovery appends one hash-bound `continue-fix` decision for attempt ordinal 2 and the exact
-support path. It preserves the worktree and Plan hash; it does not alter source or Git. The current
-C1 actor presents the existing writer token and fresh `task run` exposes the effective scope.
-`task step-complete` remains the only commit owner, all checks rerun, and strict review packets name
-the derived scope. Missing-script/selector conflicts still use `replan-required` plus the normal
-Human-confirmed corrective replan. Unproved or broader scope changes never receive this authority.
-
-### Downstream-proof predecessor recovery
-
-Core prevents `task step-complete` when the active proof Step has dirty files outside its own
-`allowedWrites`. A bounded recovery is advertised only when every such file belongs to a completed
-transitive predecessor, the branch and registered Git history are exact, the active Step has no
-completion evidence, and no unrelated path exists. The atomic transition preserves product files
-and HEAD, moves invalidated predecessor commits into historical `invalidatedStepCommits`, clears stale Step
-evidence, supersedes execution authority, yields C1, and routes the same Task to ordinary `plan-set`.
-The route grants no authority to change Task objective, requirements, acceptance, or Milestone
-topology.
-
-The beta.12.7 compatibility repair for an accidental post-invalidation Knowledge rebind is similarly
-non-semantic. It may restore `needs_fix` and preserve an exact dirty-worktree binding, but it cannot
-approve a replacement Plan, infer new requirements, or treat preserved bytes as completed evidence.
-After any required Knowledge refresh, the full unfinished remainder is planned again. Carryover into
-execution is valid only when one newly authorized Step owns every bound path and the current
-HEAD/path/content hashes still match; checks and strict review retain their ordinary authority.
-
-Docker permission diagnostics are classified before consuming retry authority. Sandbox `EPERM` or
-permission denial gets one exact escalated rerun of the health probe/Plan check. It is not an infra
-failure and cannot authorize a Docker Desktop restart or image substitution. Only an escalated
-invocation that reaches Docker and proves daemon unavailability establishes that failure class.
-
-## Atomic context refresh
-
-When `next` returns top-level `action: task context-refresh` with an exact option, a
-project-scoped delegate may run one composite transition and must not run standalone reconcile
-first:
-
-```text
-task context-refresh
-  = project-memory reconcile
-  + delegated project-memory approve
-  + task knowledge-rebind
-  + delegated task execution authorize
-```
-
-The command requires the exact Task and Knowledge Map revisions, delegate actor, and grant.
-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
-
-One Milestone coordinator chat owns Discovery, Task order, exact delegated approvals, merge
-observation, Milestone validation, and final acceptance. Every required Task runs in a
-dedicated user-visible Task chat. A Task chat may use internal Worker and Reviewer contexts,
-but only its delegate coordinator uses the grant. This prevents one long Milestone context
-from accumulating every implementation and review loop.
-
-The context boundary is literal: a Task chat is a new standalone Codex task created with an
-explicit Task-only prompt, never a fork or handoff of the Milestone chat. Its prompt contains the
-exact repository/Milestone/Task identifiers and fresh Task contract, but no parent transcript,
-sibling Task details, recovery narrative, reasoning trace, or bearer credential. Creation failure
-is a dispatch blocker, not permission to fork. The coordinator verifies one unique mapping from
-each Task ID to its thread and title before work begins.
-
-A host-generated `codex_delegation` envelope containing routing provenance such as
-`source_thread_id` is allowed; it must contain the TaskContextPacket as its complete input and must
-not carry completed parent turns. The coordinator reads the title back after creation and explicitly
-renames it when the supplied title was omitted or normalized.
-
-Chat titles are allocated atomically by the project registry; sidebar counts and `count + 1` are
-not valid numbering sources. Primary forms are:
-
-```text
-#NNN · M<NN> · Coord · <Milestone title> · <MS-ID>
-#NNN · M<NN>/T<NN> · Task · <Task title> · <TASK-ID>
-```
-
-The sequence and membership ordinal come first; the full ID prevents ambiguous identity. Exact
-readback is mandatory and only registry-supplied deterministic fallbacks may be used.
-
-Autonomy also requires active supervision. After just-in-time dispatch, the Milestone coordinator
-keeps a bounded `wait_threads` loop for the routed Task, inspects completion/attention, and verifies
-fresh Workflow `status -> next` before deciding what happened. It resumes a recoverable
-nonterminal Task in the same chat with `send_message_to_thread`; it does not shift ordinary
-implementation questions to the user. The coordinator may stop only for an exact human/semantic
-gate, exhausted infrastructure retry, unrecoverable integrity conflict, a user-requested
-checkpoint, or terminal Milestone closure. A finished chat is not proof of a terminal Task, and a
-child result does not automatically wake a coordinator turn that has already ended.
-
-## Update boundary
-
-Before changing the exact npm version, run `update preflight`. A compatible update is safe
-only when the repository is clean, no Step is `in_progress`, and no writer lease is active.
-An expired lease is also a blocker until the ordinary explicit stale-lock repair is completed.
-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 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
-
-After every current `required` Task is `merged`, run `milestone validate` on the clean base
-HEAD. `next` exposes a completion policy and the state-bound final gate. The coordinator must
-compare Result, evidence, Plan hash, and validated HEAD. A delegate may accept only through an
-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.
-
-## 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. During that exact
-window `next` returns non-executable `milestone initial-assembly` navigation with explicit
-linked-Task Discovery/materialization options; the closing Plan option appears after the first
-linked Task exists. A failed navigation call must not
-be bypassed with a direct Plan command. Ordinary semantic
-scope change remains explicit and human-only through `milestone scope-change-prepare` and
-`milestone scope-change-apply`.
-
-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`. 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,
-revision, context, grant, or writer-owner mismatch. While pending, `next` blocks normal
-execution behind claim; while claimed, only the
-claimant may mutate with the bound writer token. Milestone-linked Tasks require this claimed
-posture before start. Terminal handback preserves status, merge/result/evidence/review and
-Knowledge bindings, limitations, and recommended next action. This is machine-bound actor and
-lease evidence only; it is not proof of a separate thread.
+Do not repeatedly execute an unchanged failing route. Preserve the command, state binding and blocker; distinguish an external wait, human gate, integrity failure and unsupported transition. No arbitrary retry counter establishes completion. A1 remains a release blocker until actual continuation evidence covers the supported routes.

package/docs/decisions.md

@@ -1,113 +1,15 @@
-# Accepted V2 Decisions
+# Current product decisions
 
-This document closes the requirement gaps identified during the V2 design review.
-
-1. **Milestone lifecycle.** A Milestone aggregates Tasks on an ordinary base branch; it
-   has no integration branch. Its approved Plan defines required, waived, and cancelled
-   memberships plus cross-Task checks. Amendments supersede execution authorization and
-   block new Task starts until reauthorized. Started Tasks cannot be removed. Validation
-   runs on the current clean base HEAD, and final acceptance binds Result, evidence, and
-   that HEAD. Cancellation records a reason and never reverts merged code.
-2. **V1 transition.** V1 state is not mapped into V2 entities. `state migrate --dry-run`
-   inventories legacy paths. `state migrate --snapshot` writes a deterministic,
-   content-addressed gzip JSON archive outside the repository. It rejects symbolic links
-   and never changes, deletes, or semantically imports V1 state.
-3. **Registry and support.** The package identity is `codex-workflow-v2` and npm
-   visibility is public. Releases use tag-triggered trusted publishing. Stable support
-   covers the latest minor release in the current major; older minors receive no backports
-   unless separately declared.
-4. **Reviewer guarantee.** Role envelopes alone are advisory. The strict reviewer is a
-   separate ephemeral `codex exec` process with user configuration and rules ignored,
-   a read-only sandbox, a structured output schema, and a denied-write probe. Process
-   failure, invalid output, a successful write, or any repository mutation records
-   `unverified` and blocks final acceptance.
-5. **Gateway distribution.** The gateway is shipped as the personal plugin source at
-   `plugins/codex-workflow-gateway`. Its installer performs the CLI-driven cachebuster and
-   reinstall flow. The plugin negotiates the package protocol and never copies V2 workflow
-   assets into a project repository.
-6. **Graph binding.** `codebase-memory-mcp` remains the graph provider. The gateway obtains
-   a refresh request from the core, refreshes the product or workflow graph, and binds
-   returned evidence only when request identity and current repository/package fingerprints
-   agree. Product graph state retains the current binding; the workflow graph additionally
-   retains one previous package-version binding for rollback diagnosis. Provider failure is
-   recorded explicitly as fallback and does not replace repository knowledge.
-7. **Runtime boundary.** V2 targets one user operating on one machine. Workflow state,
-   locks, snapshots, graph bindings, and approvals live under the user's local Codex state
-   directory. Durable product knowledge lives only in ordinary version-controlled project
-   files. Remote coordination, distributed locking, and cross-machine synchronization are
-   outside the product contract.
-8. **Task knowledge rebind.** A Task whose approved project knowledge changes between Steps
-   uses a dedicated mechanical `task knowledge-rebind` transition. The transition cannot
-   edit semantic Plan fields or Step definitions, preserves runtime Step status and evidence,
-   records the previous and current bindings, supersedes execution authorization, and
-   requires user reauthorization. It is not a state migration mechanism. The state schema is
-   advanced without a compatibility migrator for pre-release Task state.
-9. **Repository scheduling and Milestone final gate.** Repository `next` treats current
-   Milestone membership as scheduling authority for unstarted linked Tasks. Only `required`
-   Tasks of an `active` Milestone are eligible; historical waived/cancelled memberships and
-   terminal Milestones cannot shadow the next lifecycle transition. After validation, the
-   core emits a deterministic confirmation code bound to Milestone revision, Plan, Result,
-   evidence, and base HEAD. The gateway must end the turn after showing it, and the CLI accepts
-   only an explicit actor and exact code from a later user-confirmed turn. This is state-bound
-   consent, not cryptographic proof of human identity.
-10. **Delegated approval.** Human approval stays the default, but a principal may issue a
-    project-bound, expiring grant to a distinct delegate after a separate confirmation-code
-    turn. Grants allow only enumerated Knowledge Map, Task, or Milestone approval transitions
-    and are scoped to the project, one Milestone, or one Task. Each use records
-    both actors and the policy hash; revocation blocks future uses. This is an additive schema
-    2 entity and optional authorization metadata, so existing schema 2 projects require no
-    migration. It is local policy evidence, not a cryptographic identity signature.
-11. **Core-owned Step commit.** `task run` dispatches a Worker that leaves changes
-    uncommitted. For an active Step, `next` returns the exact `task step-complete` transition
-    and Step ID. That transition validates history and allowed paths, runs checks, creates
-    the atomic commit, and records evidence. A manual Worker commit is unrecorded history and
-    fails closed without changing persisted Task state. This changes navigation and
-    diagnostics only; state schema 2 and protocol 1 remain unchanged.
-12. **Autonomous correction guardrail.** The initial Plan must make migration,
-    concurrency, restart/replay, crash-window, and provider risks visible. Repeated failed reviews
-    do not impose an attempt-count stop: findings default to a same-Task fix and may request replan
-    only with exact Plan-conflict evidence. Attempts after the second are marked corrective for
-    diagnosis, remain executable, and require another strict review. Explicit split/stop decisions
-    remain append-only authority and are never inferred from the counter.
-13. **Content-only context refresh.** A delegate may compose reconcile, approval, knowledge
-    rebind, and execution reauthorization only when the approved source classification is
-    identical and only content hashes changed. Core validates both delegated transitions
-    before writing. Source-set, category, scope, authority, gap, or conflict changes stay on
-    the ordinary visible approval path. State schema 2 and protocol 1 remain unchanged.
-14. **Autonomous chat and closure boundary.** A Milestone coordinator owns orchestration and
-    final acceptance while each required Task uses a dedicated user-visible Task chat.
-    `next` exposes the Milestone completion contract, and delegated acceptance retains the
-    delegate actor and exact state-bound MSA code.
-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. **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.
-20. **Stop-override authority survives mechanical update chains.** The exact Human-confirmed
-    beta.11 attempt-four override remains valid across any contiguous append-only sequence of
-    content-only Plan rebinds. Every adjacent immutable Plan, Knowledge rebind, and mechanical
-    Plan Risk Audit rebound must agree. Git HEAD may advance only through a contiguous chain of
-    already registered dependency-provenance commits, each single-parent and limited to
-    `package.json` plus `package-lock.json`. Semantic Plan drift, product commits, missing
-    provenance, or broken chronology still fails closed; generic corrective-decision recovery
-    remains direct and is not widened.
-21. **Administrative revision continuity is evidence-accounted.** A dependency-provenance
-    recovery recorded after the current mechanical Plan Risk Audit may explain exactly one later
-    Task revision without invalidating an already applied stop override. Core counts only ordered
-    recovery records from the independently verified override-to-authorization Git chain and
-    requires the resulting expected revision to equal the current Task revision. Unexplained
-    revisions and damaged provenance remain blocked; this is not a general `revision >=` rule.
+1. One user, one machine, one consumer project; that consumer updates to the latest package. Older package versions, source-version rescue runners and backports are not supported. Exact local package pins remain necessary for reproducible execution.
+2. Repository files own durable product knowledge. Local Workflow state owns lifecycle records, hashes, approvals and process/Task ownership. A graph is derived orientation evidence, never canonical knowledge or authority.
+3. Discovery establishes scope before Task/Milestone identities and execution branches. Plans bind requirements, Steps, paths, checks and approved Knowledge. Semantic decisions remain explicit.
+4. Core owns state transitions and Step commits. Revision/hash/HEAD checks, effective scope and one writer prevent conflicting work. Agents do not edit state or substitute manual Git commits.
+5. Milestone membership is a dependency DAG on an ordinary base branch. Required predecessors must merge first. Membership-only autonomy preserves semantic scope; arbitrary scope changes remain human-controlled.
+6. Independent audits and reviews are separate evidence producers. Role labels alone do not prove isolation. Invalid output, changed review seals or failed reviewer launch cannot establish acceptance.
+7. Delegation is exact, scoped, expiring and revocable. It records the principal and distinct delegate. It cannot authorize its own expansion or renewal.
+8. Rebind changes Knowledge bindings only. Current atomic context refresh composes approved transitions without widening them. Pending execution/review/recovery retains its own priority and identity.
+9. Repeated failures do not impose an attempt-count stop and do not create success. Replan requires actual obstruction evidence. Completed work remains verifiable; explicit stops and unsupported topology changes remain visible boundaries.
+10. Recovery preserves coherent state, bound product bytes and immutable evidence. Retaining a reader for existing evidence does not retain old-version execution routes or justify a new migration framework.
+11. A1 is the primary blocker: integrity guards alone do not establish reachability or termination. `next` and executors must share admission rules, and real transition tests must show successors under stated assumptions. Human decisions and external failures cannot be promised to terminate automatically.
+12. Validation is fresh and single-owner, with bounded child processes and no silent retries. The canonical release command runs the full suite once and then package checks. Timing evidence distinguishes host bootstrap stalls from running JavaScript.
+13. The supported entry documentation is six current guides. Historical design briefs and release narratives live in Git history; PDF exports and research material are outside package runtime instructions.