codex-workflow-v2 2.0.0-beta.1 → 2.0.0-beta.11

package/docs/stable-release-defect-register.md

@@ -1,11 +1,11 @@
 # Stable Release Defect Register
 
 This register captures defects and operational gaps found while running the
-alpha.7 line against the `signal_v4` Milestone 3 lifecycle. It is intentionally
+alpha.7 through beta.9 lines against the `signal_v4` Milestone 3 lifecycle. It is intentionally
 separate from implementation briefs: an item stays here until it is either
 verified fixed by a regression test or explicitly classified as downstream-only.
 
-Last reviewed: 2026-08-15.
+Last reviewed: 2026-08-22.
 
 ## Severity and status
 
@@ -14,6 +14,468 @@ Last reviewed: 2026-08-15.
 - **Closed-regression** means a patch exists; the stable release must retain its regression coverage.
 - **Downstream** means the finding belongs to `signal_v4`, not to the workflow package.
 
+## Post-beta.5 open findings
+
+### WF-STABLE-030 — chat order and replacement progress are not observable
+
+- Status: Closed-regression in beta.9
+- Severity: High
+- Area: Codex App routing, title identity, Milestone supervision
+- Evidence: automatically created Task/reviewer titles had no project sequence, long semantic
+  segments were unpredictably shortened, and the Coordinator summary did not expose that cancelled
+  T03 had been replaced by a distinct T08.
+- Fix: the gateway owns one atomic project registry with non-reusable monotonic `#NNN`, six compact
+  title families, exact readback and deterministic fallback. Core exposes a read-only Milestone
+  progress projection; Task and Coordinator chats emit progress tables at defined boundaries.
+- Regression: concurrent allocations remain unique and monotonic; long Cyrillic titles and multiple
+  review attempts traverse fallback/readback; projection keeps `T03 cancelled → T08 replacement`
+  as two rows with exact Step status.
+
+### WF-STABLE-029 — dependency-only Workflow update strands an active Task
+
+- Status: Closed-regression in beta.9
+- Severity: Critical
+- Area: Git provenance integrity, package update, active Task recovery
+- Evidence: Signal T04 contained the beta.8 dependency update commit at HEAD after all recorded Task
+  commits. `task submit` correctly rejected the unregistered commit, but no bounded route could
+  classify it as Workflow-owned provenance.
+- Fix: fresh navigation advertises recovery only for one clean, local, dependency-only HEAD after
+  exact recorded history, with no Step/lease/transaction activity and complete beta.9 alignment
+  across runtime, manifest, lock, install, Task branch, and Milestone base. Recovery only appends
+  that SHA to `systemCommits` with an audit record; it never mutates Git.
+- Regression: exact candidate succeeds and is idempotent; product-file contamination and stale-base
+  divergence fail closed.
+
+### WF-STABLE-028 — passed guarded Step strands later final Task-review remediation
+
+- Status: Closed-regression in beta.8
+- Severity: High
+- Area: guarded remediation breaker, final Task review, navigation/mutation agreement
+- Evidence: Signal Task `TASK-01M0HVK4YDJ3W9X0N72TYNV8WK` reached a verified passing third
+  sealed Step review after two ordinary failures and one independently authorized `continue-fix`.
+  A later final Task review found two new defects and `next` correctly advertised `task plan-set`,
+  but the mutation rejected the Plan because the already-consumed `continue-fix` event still
+  matched the current Plan. The suggested current-Plan retry was impossible because the guarded
+  Step was already `completed`.
+- Risk: a valid append-only review history can leave a nonterminal Task with no executable
+  transition even though its state is clean and navigation advertises a corrective Plan update.
+- Fix: a verified passing Step-review event now closes the preceding breaker cycle for that Step.
+  Resolved `continue-fix`, remediation, and decision events remain immutable evidence but do not
+  gate a later final Task-review remediation cycle. A changed guarded Step starts a fresh bounded
+  cycle under the replacement Plan Risk Audit; unresolved and failed cycles retain the existing
+  hard-stop behavior.
+- Regression: `tests/alpha7-remediation-replay.test.ts` reproduces the full sequence through two
+  failed sealed reviews, `continue-fix`, a verified pass, failed final Task review, atomic Plan and
+  Risk Audit replacement, execution authorization, and successful `task run` of the reopened
+  guarded Step while proving the historical sidecars are retained.
+
+### WF-STABLE-027 — Milestone coordinator stops supervising after Task-chat dispatch
+
+- Status: Closed-regression in beta.7
+- Severity: High
+- Area: Codex App Task isolation, Milestone orchestration, autonomous completion
+- Evidence: the beta.6 `signal_v4` recovery coordinator created seven same-title forked chats,
+  marked one actionable and six waiting, and then ended its own turn. The first chat continued as a
+  Task worker while the coordinator stayed idle; no wait/read/resume loop routed completion or the
+  remaining membership.
+- Risk: the apparent delegate autonomy stops at chat creation. The user must manually monitor and
+  restart every Task, while inherited history, duplicate titles, and placeholder chats weaken Task
+  isolation and make the sidebar audit trail ambiguous.
+- Fix: the packaged gateway now requires standalone `create_thread` dispatch with Task-only input,
+  deterministic title readback, just-in-time sequential creation, a bounded `wait_threads` cursor
+  loop, full `read_thread` verification, same-thread `send_message_to_thread` recovery, and a
+  secret-free CoordinatorReport. A coordinator may end with a nonterminal dispatched Task only for
+  an explicit checkpoint or a genuine human/semantic, integrity, permission, or exhausted
+  infrastructure blocker.
+- Regression evidence: plugin validation pins every supervision primitive and the no-premature-final
+  rule. A live two-Task Codex App E2E proved isolated self-start, title truncation repair,
+  sequential dispatch, cursor progression, non-human blocker recovery in the same thread, and
+  terminal completion without user intervention. Core lifecycle tests remain `287/287` green.
+
+### WF-STABLE-025 — a new Codex task receives a stale personal-plugin skill path
+
+- Status: Investigation; behavior reproduced, ownership boundary not yet isolated
+- Severity: High
+- Area: personal plugin installer, cachebuster registration, Codex App skill discovery
+- Evidence: after `signal_v4` was updated to `codex-workflow-v2@2.0.0-beta.5` and the packaged
+  `codex-workflow-gateway` installer completed, the new Codex task `Возобновить recovery
+  Milestone 3` received the catalog path ending in cachebuster `0.1.0+codex.20260818092852`.
+  That file no longer existed. The actually installed skill was under
+  `0.1.0+codex.20260821083915`; the agent found it only by searching the local plugin cache.
+- Reproduction: open a new task after installing a cachebuster update, use the skill path supplied
+  to that task, and observe an immediate file-not-found failure before any workflow action. The
+  task can continue only after out-of-band cache discovery. This contradicts the installer guidance
+  that starting a new task is sufficient to load the updated plugin.
+- Risk: routine Workflow starts produce a noisy, repeated failure. More importantly, if both cache
+  generations remain present, a task may silently load stale gateway rules instead of failing,
+  weakening exact-version routing and human-gate guarantees.
+- beta.9 live readback (2026-08-22): after the source was validated, copied through the packaged
+  installer, and `codex plugin add` reported installed root `0.1.0+codex.20260822110519`, three new
+  worktree Tasks were still injected with missing path `0.1.0+codex.20260822065726`. All three
+  found the actual cache only by read-only search and then verified beta.9 content. This rules out a
+  missed source copy or failed install and localizes the remaining defect to App catalog/runtime
+  invalidation.
+- Required closure:
+  - determine whether the stale reference is emitted by the packaged installer/registration flow
+    or retained by Codex App's skill catalog;
+  - after an A-to-B cachebuster update, every newly created task must resolve B without filesystem
+    search and must never advertise a missing or superseded A path;
+  - if an application restart is an unavoidable boundary, the installer must detect and report it
+    explicitly instead of claiming that a new task alone is sufficient;
+  - retain an integration regression covering install, cachebuster update, new-task discovery, and
+    exact `SKILL.md` content identity.
+- Scope note: no workflow-state mutation occurred before the fallback lookup. This finding is
+  independent from the stale Plan Risk Audit recovery defect observed later in the same task.
+
+### WF-STABLE-026 — Milestone authorization can bypass stale Project Memory
+
+- Status: Closed-regression in beta.6
+- Severity: Critical
+- Area: repository navigation, Project Memory authority, Milestone authorization
+- Evidence: while resuming `signal_v4` Milestone 3 on beta.5, the persisted Project Memory map was
+  active but its current scan was stale after the workflow dependency changed. Repository `next`
+  still advertised Milestone authorization, and direct Milestone authorization/autonomy methods did
+  not independently require a current approved map.
+- Risk: an existing Milestone could be authorized against stale Project Memory, after which linked
+  Task Plan contracts would bind obsolete source hashes or force an unadvertised manual recovery.
+- Fix: repository navigation now derives the current map status before Discovery or Milestone
+  authorization and routes `project-memory reconcile`/`approve` first. Direct Milestone authorize,
+  autonomy prepare, and autonomy grant also fail closed unless the current map is active and
+  approved.
+- Regression evidence: `tests/milestone.test.ts` proves that reconcile/approval preserves the exact
+  existing Milestone and Plan, then advertises Milestone authorization and binds the linked Task
+  Plan contract to the refreshed map revision/hash. A separate witness proves stale Project Memory
+  outranks replacement Discovery.
+
+## Beta.2 closure candidates
+
+### WF-STABLE-009 — initial assembly creates a state rejected by `status` and `next`
+
+- Status: Closed-regression in beta.2
+- Severity: Critical
+- Area: Milestone initial assembly, reverse membership, repository navigation
+- Evidence: both the beta.1 real-agent E2E and the live read-only `signal_v4` reincarnation
+  materialized a first linked planning Task successfully, after which `status` and `next` returned
+  `MILESTONE_SCOPE_INCOMPLETE` for the intentionally repairable pre-Plan membership gap.
+- Risk: the documented seven-Task initial assembly cannot follow authoritative `next`; agents must
+  either stop before work begins or bypass navigation and invalidate lifecycle evidence.
+- Closure evidence: centralized initial-assembly assessment, deterministic fresh/adopted/unsafe
+  regressions, exact copied `signal_v4` snapshot replay, and real-agent seven-Task assembly all pass;
+  strict reverse-membership blocking remains active outside the exact predicate.
+
+### WF-STABLE-010 — beta.1 release E2E continued after failed `next`
+
+- Status: Closed-regression in beta.2; clean release E2E verified
+- Severity: Critical
+- Area: release evidence, real-agent transcript validation
+- Evidence: the beta.1 final E2E transcript contains failed `status` and `next` calls with
+  `MILESTONE_SCOPE_INCOMPLETE`; the Delegate labelled the gap expected, invoked direct
+  `milestone plan-set`, and the final audit still accepted the run despite the Brief explicitly
+  declaring a `next` bypass invalid.
+- Risk: a real-agent run can conceal a Core lifecycle defect and produce a false release
+  recommendation.
+- Candidate evidence: the append-only transcript validator rejects navigation bypasses,
+  unadvertised mutations, failed non-retryable mutations, unresolved syntax retries, and
+  unterminated harness invocations. Final-21 passed the complete validator with `250/250` events.
+
+### WF-STABLE-011 — pending Task review `next` names a non-autonomous primitive
+
+- Status: Closed-regression in beta.2; clean release E2E verified
+- Severity: High
+- Area: Task final review, truthful navigation, real-agent evidence
+- Evidence: the first beta.2 real-agent diagnostic run reached a submitted Task with pending review;
+  `next` returned `task review-record`, while the packaged and successfully executed autonomous
+  command was `task review-launch`.
+- Risk: an agent following the exact autonomous route appears to bypass authoritative navigation,
+  while an agent following the literal response must manufacture reviewer output instead of using
+  the isolated reviewer launcher.
+- Candidate evidence: deterministic navigation regressions prove exact `task review-launch` while
+  preserving `task result-set` after a passed review. Final-21 completed strict Step review and the
+  final independent Task review without a rejected lifecycle mutation.
+
+### WF-STABLE-012 — Core-owned Git transitions omit the sandbox permission contract
+
+- Status: Closed-regression in beta.2; clean release E2E verified
+- Severity: High
+- Area: Task execution, truthful navigation, Codex sandbox integration
+- Evidence: the rebuilt beta.2 real-agent E2E followed `next.action = task step-complete`; Core ran
+  its owned checks and then failed non-mutating at `git add` because `.git/index.lock` was denied.
+  The exact same transition succeeded after a bounded Git-metadata escalation.
+- Risk: a nominally autonomous Milestone learns required authority only by failing a lifecycle
+  mutation. This creates noisy retry history, invalidates clean release transcripts, and can strand
+  less capable agents despite a valid Plan and grant.
+- Candidate evidence: positive and negative navigation regressions cover the four local Git-writing
+  transitions and absence on read-only/external routes. Final-21 consumed the policy before local
+  start, Step completion, and Core merge without a rejected lifecycle mutation.
+
+### WF-STABLE-013 — strict reviewer can wait indefinitely or fail before launch
+
+- Status: Closed-regression in beta.2; clean release E2E verified
+- Severity: Critical
+- Area: strict Step review, final Task review, non-interactive Codex subprocess lifecycle
+- Evidence: beta.2 `real-agent-release-final-6` left two `task step-review` parents and two nested
+  `codex exec` reviewers alive for more than five minutes at unchanged Task revision `6`. Neither
+  invocation returned a terminal success or failure result.
+- Additional evidence: beta.2 `real-agent-release-final-10` exposed an integration error in the
+  first correction: the global `--ask-for-approval never` option was placed after `exec`, which the
+  real Codex CLI rejected with status `2`. Two launch failures consumed the two ordinary
+  remediation attempts before the run was stopped.
+- Root cause: the strict reviewer used inherited/default approval behavior despite intentionally
+  probing a denied write, the synchronous subprocess had no host-side deadline, and the initial
+  correction did not test the real CLI's global-option ordering contract.
+- Risk: an autonomous Milestone can hang forever inside Core before review evidence exists; a retry
+  can create a second concurrent reviewer for the same Step/revision.
+- Candidate evidence: strict reviewers now place `approval=never` before the `exec` subcommand,
+  retain read-only sandboxing, and have a fixed host-side execution deadline that returns terminal
+  `unverified` evidence on timeout. Focused tests assert the exact global-option ordering as well as
+  deadline propagation and timeout fail-closed behavior. Final-21 completed both strict reviewer
+  invocations under the non-interactive, ephemeral, ignore-config/rules, read-only contract.
+
+### WF-STABLE-014 — transcript validator accepts a started mutation with no terminal result
+
+- Status: Closed-regression in beta.2; clean release E2E verified
+- Severity: Critical
+- Area: release evidence, append-only harness transcript, indeterminate mutation recovery
+- Evidence: the incomplete `real-agent-release-final-6` transcript originally returned PASS with
+  `181` checked events even though two `task step-review` commentaries had no matching mutation
+  result and the Task remained at revision `6`. Final-8 then exposed the same class for read-only
+  commands: successful `milestone autonomy-prepare` had no terminal observation event, so the
+  wrapper log alone could not distinguish success, failure, or interruption.
+- Risk: a hung or externally interrupted mutation can be presented as valid release evidence; an
+  agent may re-enter the same semantic transition without knowing whether the first process is
+  still active.
+- Candidate evidence: the validator pairs trusted-harness invocation commentary with the exact
+  terminal navigation, mutation, or read-only observation result; rejects failed observations,
+  EOF with a pending invocation, and any second command before the pending invocation resolves.
+  Immutable final-6 and final-8 transcripts are retained as diagnostic evidence and rejected for
+  their respective stranded invocations.
+
+### WF-STABLE-015 — `task plan-set` navigation omits its exact inclusion contract
+
+- Status: Closed-regression in beta.2; clean release E2E verified
+- Severity: High
+- Area: Task planning navigation, autonomous Plan construction, fail-before-write usability
+- Evidence: the Delegate followed `next.action = task plan-set` and produced substantive acceptance
+  statements, but Core rejected the first Plan because it did not contain the opaque Task acceptance
+  ID `AC-001` as an exact array member. The Task remained planning at revision `1`; the transcript
+  correctly rejected the run as failed release evidence.
+- Root cause: Core validates exact Task requirement and acceptance ID inclusion, while `next`
+  previously exposed only the action and revision. The machine-readable precondition was visible
+  only indirectly in large status/Brief output and was not part of the exact transition contract.
+- Candidate evidence: every `task plan-set` navigation now returns `taskPlanContract` with exact
+  required requirement IDs, acceptance IDs, current risks, Brief hash, and current Knowledge Map binding. The
+  packaged gateway requires planners to copy those exact IDs before adding semantic detail.
+
+### WF-STABLE-016 — Git-completion navigation omits the required writer lease input
+
+- Status: Closed-regression in beta.2; clean release E2E verified
+- Severity: High
+- Area: Task completion/merge navigation, writer lease continuity, autonomous execution
+- Evidence: after successful implementation, strict Step review, Task review, result, and delegated
+  acceptance, `next` advertised `task merge` plus `gitMutationPolicy`. The Delegate followed that
+  response without `--writer-token`; the CLI rejected the invocation before any mutation.
+- Root cause: the mandatory writer lease was enforced by each transition but absent from the exact
+  machine-readable navigation contract. The gateway therefore had no local precondition telling it
+  to retain and pass the sensitive lease on the first call.
+- Candidate evidence: `next` returns a non-secret `writerTokenContract` for `task step-complete`,
+  `task submit`, `task merge`, and `task merge-confirm`, and omits it for non-consuming adjacent
+  transitions. The packaged gateway treats it as a first-call precondition and never prints or
+  persists the token.
+
+### WF-STABLE-017 — subcommand `--help` is treated as a lifecycle mutation
+
+- Status: Closed-regression in beta.2; clean release E2E verified
+- Severity: High
+- Area: CLI command discovery, autonomous execution, release transcript integrity
+- Evidence: after clean seven-Task assembly and an active owner autonomy grant, the real Delegate
+  invoked `milestone authorize --help`. The CLI dispatched the underlying lifecycle operation and
+  rejected it with `INVALID_ARGUMENT: Missing required option --id` before any state write.
+- Root cause: CLI dispatch had no early help route; parsed `--help` remained an unused option while
+  noun/action matching entered the ordinary mutation implementation.
+- Candidate evidence: help is intercepted before repository/state construction, returns exit `0`
+  with a machine-readable `readOnly` response at top-level, noun, and action scopes, and never
+  requests mutation inputs or changes workflow state. Critical autonomous transitions expose exact
+  required and optional option lists. The transcript validator recognizes safe trusted-harness help
+  observations, rejects mutation-style help inputs, and requires a fresh successful `next` before
+  any subsequent mutation.
+
+### WF-STABLE-018 — credential-bearing receipts are buried after large Task payloads
+
+- Status: Closed-regression in beta.2; clean release E2E verified
+- Severity: High
+- Area: C1 handoff, writer lease continuity, autonomous credential consumption
+- Evidence: the real Delegate completed initial assembly through `task handoff-prepare` with zero
+  rejected lifecycle calls, then reported that the one-time claim token was unavailable. The raw
+  successful CLI result proves that the token was emitted exactly once but was buried after roughly
+  5 KiB of Task/event data; the wrapper did not truncate stdout.
+- Root cause: credential-bearing values shared the same large compatibility payload as canonical
+  Task state and context. Although Core emitted the token correctly, the response supplied no
+  compact, prominent transfer receipt for an autonomous consumer.
+- Candidate evidence: `task handoff-prepare` now emits first-field `credentialHandoff`, and `task
+  run` emits first-field `writerLeaseReceipt`. Both name the intended next action, source, target or
+  owner, option, and sensitivity; the exact credential occurs once, while legacy payload data and
+  read-only responses contain no duplicate secret.
+
+### WF-STABLE-019 — claimed Task run requires a lease that navigation says will be issued later
+
+- Status: Closed-regression in beta.2; clean release E2E verified
+- Severity: High
+- Area: C1 claim, writer lease continuity, truthful Task navigation
+- Evidence: the real Delegate consumed the first-field claim token and completed `task claim`, then
+  safely paused for bounded Git permission. After resume, Core-owned `task start` succeeded. The
+  following `next` advertised `task run` without a writer-token contract, and the exact call was
+  rejected because claimed posture already required the lease created by claim.
+- Root cause: the first writer-lease receipt was emitted by `task run`, but claimed posture requires
+  that same credential as an input to run. `task claim` returned the lease only inside its large
+  payload, while action-only navigation intentionally omitted `task run` from the writer contract.
+- Candidate evidence: `task claim` now emits first-field `writerLeaseReceipt` with `task run` as its
+  consuming action, and claimed `task run` navigation advertises the exact `--writer-token`
+  precondition. Unclaimed runs still acquire their initial lease without a token.
+
+### WF-STABLE-020 — transcript validator rejects safe top-level help
+
+- Status: Closed-regression in beta.2
+- Severity: High
+- Area: release transcript integrity, read-only CLI discovery
+- Evidence: phase 1 completed initial assembly, one complete Plan, and autonomy preparation with
+  zero rejected lifecycle calls. A successful trusted-harness top-level `--help` was immediately
+  followed by fresh successful `next`, but packaged validation returned
+  `Unsupported read-only observation`.
+- Root cause: CLI help semantics covered top-level, noun, and action scopes, while the transcript
+  recognizer's regular expression required at least one noun before `--help`.
+- Candidate evidence: the validator recognizes bare top-level `--help` as safe help, retains the
+  mandatory fresh-`next` barrier, and still rejects failed help or embedded mutation inputs.
+
+### WF-STABLE-021 — checkpoint guidance permits parallel invocations rejected by release validation
+
+- Status: Closed-regression in beta.2; clean release E2E verified
+- Severity: Critical
+- Area: gateway protocol, release transcript integrity, lifecycle checkpoints
+- Evidence: `real-agent-release-final-21` completed phase-1 initial assembly with no individually
+  rejected command, but four times started `next` before the paired `status` had emitted its
+  terminal result (or vice versa). The strict validator rejected the first overlap with
+  `INCOMPLETE_INVOCATION` at event index `29`, before owner grant or Task execution.
+- Root cause: the packaged gateway required both `status` and `next` after each boundary but did not
+  state that the first invocation must terminate before the second starts. Real agents may
+  parallelize independent-looking read-only calls, while the append-only validation contract
+  deliberately treats overlapping lifecycle invocations as indeterminate evidence.
+- Candidate evidence: Skill, protocol, recovery guide, and E2E Brief now require terminal
+  `status` followed by terminal `next` and explicitly prohibit parallel tool batches. An exact
+  transcript fixture proves that overlapping checkpoint starts remain rejected. The final clean
+  `real-agent-release-final-21` followed every `status` then `next` checkpoint sequentially through
+  final acceptance; the complete transcript validates at `250/250` with no overlap.
+
+### WF-STABLE-022 — raw real-agent evidence persists one-time C1 credentials
+
+- Status: Closed-regression in beta.2; clean release E2E verified
+- Severity: Critical
+- Area: real-agent evidence, C1 credentials, release security
+- Evidence: the corrected `real-agent-release-final-21` consumed credential-first handoff, claim,
+  and run receipts successfully, but Codex `exec --json` serialized the literal `--claim-token`,
+  `--writer-token`, and credential-bearing stdout into the raw session JSONL. The semantic lifecycle
+  log remained secret-free, but the raw diagnostic artifact contradicted the stated memory-only
+  handling rule.
+- Root cause: raw Codex JSONL was redirected directly to evidence without a streaming redaction
+  boundary. A language-model tool call necessarily contains the CLI argument it invokes, even when
+  the agent does not echo the value in prose.
+- Candidate evidence: a streaming structural sanitizer removes exact credential fields and CLI
+  options before JSONL is persisted, preserves non-secret token metrics, and provides a fail-closed
+  post-run inspection mode. Deterministic tests cover command arguments, embedded receipt JSON,
+  structured receipts, and already-sanitized evidence. The final clean final-21 used the streaming
+  sanitizer from process start for both phases; fail-closed inspection reports zero credential
+  findings in both persisted raw JSONL artifacts.
+
+### WF-STABLE-023 — claimed strict-review navigation omits its writer lease precondition
+
+- Status: Closed-regression in beta.2; clean release E2E verified
+- Severity: Critical
+- Area: claimed C1 review, truthful navigation, writer lease continuity
+- Evidence: sanitized `real-agent-release-final-21` completed one guarded Step and its Core-owned
+  commit, then `next` advertised `task step-review` without `writerTokenContract`. The exact first
+  call was rejected non-mutating with `TRANSITION_BLOCKED` because claimed posture requires the
+  active lease token.
+- Root cause: navigation enumerated always-lease-bound completion actions and claimed `task run`,
+  but not the later claimed-C1 mutations that call the same handoff authorization predicate.
+- Candidate evidence: writer-token navigation is now posture-aware for every claimed-C1 action
+  that can consume an optional lease, including `task step-review` and `task review-launch`.
+  Regressions cover both claimed review boundaries while preserving token-free unclaimed review
+  navigation. The final clean final-21 exposed the contract and succeeded on the first call for
+  both `task step-review` and `task review-launch`, with zero rejected lifecycle mutations.
+
+## Beta.2 current evidence
+
+- The first `real-agent-release-final-21` is immutable diagnostic evidence for WF-STABLE-021: its
+  lifecycle commands individually succeeded, but packaged validation rejected four overlapping
+  checkpoint pairs. It stopped before owner grant and was not resumed.
+
+- Final clean `real-agent-release-final-21` used a rebuilt tarball with SHA-256
+  `24a7b69b0ada9d922946a8c0c593384d5806d58a35e04fae171d26f83585ac4f` and an isolated
+  `final21` marketplace/plugin cache. Phase 1 assembled exactly seven linked Tasks and stopped at
+  the autonomy gate; phase 2 completed the sole required guarded Task, strict Step review,
+  content-only context refresh, final review, delegated acceptance, Core merge, Milestone
+  validation, and delegated Milestone final acceptance. Task
+  `TASK-01M04B516YDHY5D1B78S2XEV0S` is `merged` at revision `14`; Milestone
+  `MS-01M04B42MC7VCEKTQ7K8ZYK0G1` is `accepted` at revision `5`; accepted head is
+  `64a2e58e030dfb95f5f5724fb1825b02143ffaa7`. Final `next` is repository idle with
+  `discovery start`. Transcript validation passes `250/250`, both credential scans report zero
+  findings, waived Tasks executed is zero, and rejected lifecycle mutations is zero.
+- Post-WF-STABLE-023 full sequential validation on Node `24.17.0` passed `153/153` in
+  `644031 ms`. Plugin check, release check, isolated-cache dry-pack, downstream smoke, root
+  workflow regression, and `git diff --check` passed. The E2E-tested pre-evidence-doc tarball SHA-1 is
+  `4519d05b31fa08b39f5f5f9f9e2b9f0e13941935`.
+
+- Post-WF-STABLE-020 sequential package validation passed `149/149` under Node `24.17.0`.
+  Current validation accepts the immutable `final-20` phase-1 transcript as `132/132`, while its
+  packaged pre-fix validator deterministically rejects it. Rebuilt package dry-pack, plugin check,
+  release check, downstream smoke, root regression, and `git diff --check` passed; dry-pack shasum
+  is `d5ca042dd1bb90e52c6d5313dafa6730e5d3795f`.
+- Post-WF-STABLE-019 sequential package validation passed `149/149` under Node `24.17.0`.
+  Rebuilt package dry-pack, plugin validation, release check, downstream smoke, root workflow
+  regression, and `git diff --check` all passed; dry-pack shasum is
+  `547166399294368c89ae7c581192cf81a6391638`.
+- Post-WF-STABLE-018 sequential package validation passed `147/147` under Node `24.17.0`.
+  Rebuilt package dry-pack with isolated npm cache, plugin validation, release check, downstream
+  smoke, root workflow regression, and `git diff --check` all passed; package shasum is
+  `04571ca2f51f48661c984e8d16a2e32c336efe64`.
+- Final post-WF-STABLE-015 sequential package validation passed `141/141` under Node `24.17.0`.
+- Package archive, downstream smoke, plugin validation, release check, and root workflow regression
+  passed on the rebuilt candidate. One root-regression setup attempt lacked Node on the child-process
+  `PATH`; the authoritative rerun with the declared Node 24 environment passed.
+- Exact copied `signal_v4` snapshot replay passed without live-project or live-state writes.
+- Disposable final-6 phase 1 assembled seven Tasks and stopped cleanly at the autonomy boundary.
+  Phase 2 authorized and completed the guarded Step, then correctly stopped as invalid evidence
+  when strict Step review remained indeterminate.
+- Disposable final-11 assembled all seven Tasks and authorized the Milestone, then stopped on the
+  first rejected `task plan-set` because exact `AC-001` inclusion was not discoverable from `next`.
+  It is immutable diagnostic evidence for WF-STABLE-015, not release evidence.
+- Disposable final-12 reached delegated Task acceptance and `task merge`, then stopped on the first
+  rejected merge because `next` did not advertise mandatory `--writer-token`. It is immutable
+  diagnostic evidence for WF-STABLE-016, not release evidence.
+- Disposable final-13 passed clean bootstrap/preflight but the real Codex transport failed before
+  the first workflow action. It made no workflow mutation and is external diagnostic evidence, not
+  a package-defect or release signal.
+- Disposable final-16 cleared transport, completed initial assembly and the owner grant, then
+  stopped on the first rejected `milestone authorize --help`. It is immutable diagnostic evidence
+  for WF-STABLE-017, not release evidence.
+- Disposable final-17 completed seven-Task initial assembly with zero rejected mutations and proved
+  read-only help plus fresh `next`, but the packaged validator still rejected that help observation.
+  It stopped before owner grant and is immutable WF-STABLE-017 diagnostic evidence.
+- Disposable final-18 completed initial assembly through C1 handoff preparation with zero rejected
+  lifecycle calls. It then exposed WF-STABLE-018: the exact one-time claim token existed in complete
+  stdout but was buried after the large Task/event payload and was not retained by the Delegate.
+  The run is immutable diagnostic evidence and is not eligible for continuation or release evidence.
+- Disposable final-19 completed seven-Task assembly, delegated authorization, credential-first
+  handoff/claim, and bounded Core `task start`. It then exposed WF-STABLE-019 when claimed
+  `task run` was advertised without its already-bound lease precondition and was rejected once.
+  The run is immutable diagnostic evidence and is not eligible for continuation.
+- Disposable final-20 completed clean seven-Task phase-1 assembly and autonomy preparation with no
+  rejected lifecycle call, then exposed WF-STABLE-020 when transcript validation rejected safe
+  top-level help plus fresh `next`. No owner grant was issued; the run is immutable diagnostic
+  evidence and is not eligible for continuation.
+- The rebuilt tarball, fresh clean final-acceptance/idle E2E, transcript/security checks, and all
+  deterministic/package release gates are green. The independent source/evidence audit completed
+  with `PASS`, found no material blocker, and confirmed the beta.2 release recommendation.
+
 ## Workflow findings closed for beta.1
 
 ### WF-STABLE-001 — `locks repair` exposes a full writer token
@@ -115,7 +577,7 @@ Last reviewed: 2026-08-15.
   active but non-completable Milestone.
 - Stable-release requirement:
   - ship a canonical `split-required` operator/delegate recovery prompt;
-  - require `status`/`next` after every state boundary;
+  - require sequential terminal `status` then terminal `next` after every state boundary;
   - distinguish Task creation, replacement linkage, membership evolution, and execution
   reauthorization;
 - prohibit manual state editing and resumption of the failed Step.

package/docs/updating-existing-project.md

@@ -29,9 +29,29 @@ adoption posture.
 используйте внешний точный runner alpha.7 только для `update rescue-preflight`. Продолжать
 можно лишь при `eligible=true`; допустимы только перечисленные им `locks repair` и
 `task step-review`. Этот путь не меняет dependency и не разрешает другие команды alpha.7.
+Для `task step-review` используйте lifecycle-actor из `next` или rescue-preflight; это claimant
+или required actor, а не identity независимого reviewer-процесса.
 После terminal review выполните обычный Knowledge reconcile/rebind, доведите Task до безопасной
 границы и только затем обновляйте package/lock обычным способом.
 
+### Исключение beta.10 для retained reviewed commit
+
+Если corrective replan уже убрал evidence завершённой попытки из текущего Step, но её product
+commit остался в Git между `baseCommit` и новым dependency-only HEAD, beta.10 может штатно принять
+такую историю. Это допустимо только при полной криптографически целостной strict-review цепочке с
+решением `passed` и verified reviewer attestation. Pending/failed review, отдельный `evidence.json`,
+повреждённый sidecar или неизвестный product commit не подходят.
+
+Не регистрируйте сохранённый product commit вручную в `systemCommits`. После установки beta.10
+выполните свежий `next`; продолжайте только если он рекламирует
+`update dependency-provenance-recover`. Затем последовательно выполните read-only
+`update dependency-provenance-preflight`, проверьте `eligible=true`, точные Task revision/HEAD,
+пустой `blockers` и ожидаемый список `retainedHistoricalCommits`, и только после этого вызывайте
+рекламируемый recover с той же revision. Успешный recover записывает dependency HEAD в
+`systemCommits`, а исторические reviewed product commits — отдельно в recovery evidence. После
+него обязательны последовательные `status` и `next`; выполняйте возвращённый Knowledge reconcile
+или `task context-refresh`, если manifest/lock сделали Knowledge Map stale.
+
 ## 1. Подготовьте отдельный чат обновления
 
 Не обновляйте пакет во время выполняющегося Worker Step. Дождитесь завершения текущего ответа
@@ -78,6 +98,15 @@ plugin за пределами workspace. Это ожидаемая границ
 8. `update preflight` до изменения подтвердил чистую lifecycle-границу.
 9. Для alpha.6 существующий schema 2 проект либо уже имеет `adoption-posture.jsonl`,
    либо `next`/`status` требуют `state adoption-prepare` и затем `state adoption-apply`.
+10. При переходе с protocol v1 на v2 неизменённый и криптографически целостный adoption sidecar
+    остаётся читаемым как legacy evidence. Runtime не переписывает его автоматически; неизвестная
+    версия или смешанная protocol-цепочка считаются повреждением state.
+
+Protocol v2 меняет navigation/CLI corrective-replan и lifecycle epoch, но не Task state schema.
+До обновления не должно быть `in_progress` Step, writer lease, Core Task operation mutex или
+незавершённого corrective Task journal. Такие состояния требуют штатного completion/repair старой
+версией; переносить или удалять journal вручную нельзя. Старые grants/receipts не получают authority
+в epoch 2 — новый corrective replan всегда проходит новый prepare/human-gate/execute цикл.
 
 Изменение `projectId`, исчезновение сущностей или ошибка unsupported state schema — причина
 остановиться. Не соглашайтесь на «починку» удалением state. Агент должен вернуть dependency к
@@ -224,14 +253,40 @@ Grant сам не запускает агента и не прикрепляет
 `next.delegatedApprovalOptions`. Внутренние Worker и Independent Reviewer grant не используют:
 его применяет координатор после получения их evidence.
 
-Рекомендуемые названия чатов:
+Все автоматически создаваемые чаты получают проектный монотонный номер из
+`plugins/codex-workflow-gateway/scripts/chat-registry.mjs`; `count + 1` запрещён. Основные формы:
 
 ```text
-NN - M2 delegated coordinator
-NN - M2/T1 delegated execution
-NN - Standalone delegated task
+#NNN · M<NN> · Coord · <Milestone title> · <MS-ID>
+#NNN · M<NN>/T<NN> · Task · <Task title> · <TASK-ID>
 ```
 
+Task-чат создавайте только как новую standalone Codex task (`create_thread`) в том же Project, а
+не как fork/handoff/продолжение Milestone-чата. В начальный prompt передавайте только exact
+TaskContextPacket: repository, точные Milestone/Task ID и ordinal, текущие Task revision/title,
+Brief/Plan bindings, Task requirements/acceptance, свежий маршрут `status -> next --task <Task
+ID>`, Task-local scope/checks/stop conditions и exact actor/grant ID при необходимости. Не
+переносите transcript Milestone-чата, историю recovery/approval, соседние Tasks, reasoning или
+confirmation/handoff/writer credentials.
+
+До создания проверьте, нет ли уже чата для exact Task ID. После создания передайте прочитанный
+title в registry readback и применяйте только возвращённый deterministic fallback. Title должен
+быть уникален и содержать exact `#NNN`, membership ordinal и ID. Input должен состоять из
+TaskContextPacket; допустима только добавленная Codex App служебная `codex_delegation`-обёртка с
+`source_thread_id`, но не parent turns или transcript. Если title отсутствует или нормализован
+неверно, переименуйте и перепроверьте. Ошибка `create_thread` допускает один
+последовательный retry после проверки списка, но не разрешает fallback на `fork_thread`.
+Создавайте или переиспользуйте Task-чат непосредственно перед dispatch этой Task, а не как пустой
+placeholder для всего membership; `T<NN>` берите только из утверждённого membership order.
+
+После dispatch Milestone-координатор не заканчивает turn: он ждёт exact Task-чат bounded-вызовами
+`wait_threads`, сохраняет cursor, читает completed/attention результат и обязательно сверяет его
+через `status -> next`. Recoverable non-human продолжение отправляется в тот же чат через
+`send_message_to_thread`; пользователь нужен только для mandatory human/semantic gate, внешнего
+разрешения, unrecoverable integrity conflict или исчерпанного infrastructure retry. Следующий
+Task-чат создаётся только после Core-подтверждения `terminal + merged`. Завершённый Task-чат сам по
+себе не доказывает terminal state и не пробуждает уже завершившийся coordinator turn.
+
 После завершения автономного окна попросите отдельный контрольный чат показать
 `delegation list`, использованные authorization events и отозвать ненужный широкий grant.