codex-workflow-v2 2.0.0-beta.13.1 → 2.0.0-beta.13.11

package/docs/beta13.2-signal-review-recovery.md

@@ -0,0 +1,38 @@
+# beta.13.2: pending-review recovery
+
+## Confirmed failure
+
+Signal M04 T01 completed the product changes for STEP-002 on beta.13.1, but its
+required independent Step review could not be prepared. The cumulative Task diff
+was 2,236,058 bytes, exceeding the default synchronous Git output buffer. The
+checkout remained clean and the completion commit remained recorded; review had
+not passed.
+
+After the writer lease expired, repository navigation preferred delegated
+Knowledge context refresh over the pending review's credential recovery. The
+context-refresh executor correctly rejected the still-in-progress Step. Thus
+navigation advertised an action its executor could not perform. Ordinary package
+update was also blocked by the in-progress Step.
+
+## Required recovery guarantees
+
+- Large Step and final Task review inputs are complete or fail explicitly; Git
+  errors have bounded diagnostics rather than dumping the input corpus.
+- Pending review and its exact writer credential recovery remain ahead of
+  Knowledge refresh. Refresh during a running Step stays forbidden.
+- Installation recovery validates the source version, exact Task/Plan/Step and
+  completion commit, clean checkout, recorded Git history, review journal, and
+  absence of active ownership or transactions.
+- Dependency transport preserves product bytes and the original reviewed commit.
+  Pending review never establishes passed-review provenance.
+- The original required review, delegated context refresh, Task acceptance and
+  merge remain mandatory after recovery. Grants are not broadened or renewed.
+
+## Release acceptance
+
+The package regression suite must cover oversized review inputs and the combined
+pending-review, expired-lease and stale-Knowledge state, including rejection of
+unsafe recovery candidates. Release validation also requires the ordinary package
+and external-review lifecycle gates. Actual Signal recovery must pass the blocked
+Step review and reach a subsequent executable lifecycle boundary; green fixture
+tests alone do not establish that the production Milestone has resumed.

package/docs/change-model.md

@@ -0,0 +1,118 @@
+# Execution context and change explanation
+
+A change is explained before it is attempted. The explanation is not an approval, a new grant,
+or a replacement lifecycle. Existing Core `next` remains authoritative.
+
+## One execution context
+
+App dispatch defaults to a worktree. An explicitly requested `executionMode: "local"` creates
+in the saved project instead. Use local only when the user requested that execution environment.
+The dispatch prompt separates repository identity from the child's actual write destination.
+Correlated App readback records the real checkout root. A second readback cannot silently move
+that bound Worker into another checkout, even when both share a Git common directory.
+
+Before the first write and after a branch/cwd change, call the packaged registry action
+`dispatch-context-check --reservation-id ... --file ... --project-id ...` with:
+
+```json
+{
+  "observation": { "thread": {
+    "id": "actual-bound-thread-uuid", "kind": "codex", "hostId": "local",
+    "cwd": "/absolute/actual/worker/checkout"
+  } },
+  "writeRoot": "/absolute/actual/worker/checkout",
+  "expectedBranch": "exact-branch-from-fresh-Task"
+}
+```
+
+Use a fresh App `read_thread` observation, never a fabricated cwd. This read-only check detects
+repository, checkout, write-root and branch mismatch. It does not replace Task revision, actor,
+lease/credential or external permission checks. Do not send another create request, change the
+target directory, or hand off an active writer merely to clear a mismatch. Reconcile the existing
+Worker and Workflow context. Tracked dispatch without recorded executionContext needs a correlated `dispatch-observe` before
+this check can match; it does not invent an existing checkout binding.
+
+## One change card
+
+`change explain --task TASK-ID --file proposal.json --repo /actual/checkout --json` reads the
+current Task and `next` from one observation. It changes no workflow state or product file.
+
+```json
+{
+  "reason": "The current check requires one additional support file.",
+  "paths": ["tools/check-support.ts"],
+  "intent": "implementation",
+  "expectedRevision": 12,
+  "executionContext": {
+    "cwd": "/absolute/actual/worker/checkout",
+    "writeRoot": "/absolute/actual/worker/checkout",
+    "expectedBranch": "exact-task-branch"
+  },
+  "externalDecision": "unknown"
+}
+```
+
+`paths` are exact normalized relative file paths, not globs. `expectedPlanHash` is also accepted.
+Inputs are closed; an agent cannot add a `supportProven` or `approved` flag. `externalDecision:
+"denied"` preserves an external denial as a separate blocker. It does not call or emulate the
+external permission service. `intent` may instead be `membership` or `semantic-scope`; declaring
+intent never proves semantic safety. Omitted context is reported as not supplied, not verified.
+
+The card binds Task revision/Plan, HEAD, request and bytes of proposed plus observed dirty paths.
+Undeclared dirty files are included; escaping symlinks block byte inspection. The output contains
+no confirmation/claim/writer values and no proposed file contents. A proposal hash is a diagnostic
+binding, not an apply token; always refresh `next` and ordinary mutation preconditions.
+
+## Adaptation routes
+
+- Implementation fixes continue within the same Task when the current Core route permits it.
+  Review count alone does not select corrective planning.
+- `bounded-plan-amendment` appears only when Core advertises the exact eligible check-support
+  scope extension and every out-of-Step file is covered by that evidence. Execute the existing
+  `task plan-integrity-recover` route and fresh `next`; its existing atomic evidence and authority
+  rules apply. The card never edits `allowedWrites`, enlarges a grant, or supplies an arbitrary
+  new Plan. This release reuses the proven bounded amendment mechanism rather than adding a
+  competing mutation protocol.
+- An unproved additional file requires Plan review. No broad glob or diff-size rule grants
+  automatic extension. Runtime changes and component-owner recovery retain their current audits.
+- Corrective planning and downstream recovery retain existing Task/Worker identity and historical
+  evidence. A Knowledge context refresh does not resolve a Plan conflict.
+- Membership is distinct from implementation. Existing audited remediation and full-contract
+  membership evolution remain the only corresponding machine routes. A reported membership
+  intent does not authorize deletion of a required Task or weakened acceptance.
+- Semantic scope requires an explicit user decision. External denial remains independent of
+  Workflow grants and file scope.
+
+`requiresUser: null` means the card has not established a specific human gate, not that all
+checks passed. The card is advisory and cannot intercept arbitrary editor/tool writes. Gateway
+agents must invoke the context check and fresh Core route before writing. No claim is made that
+an external approval system will accept the resulting operation.
+
+For a legacy Worker already bound before dispatch markers existed, the read-only context check
+uses its existing thread/host plus a freshly supplied Task repository root. It explicitly reports
+that historical checkout provenance is unavailable, preserves the legacy registry bytes and
+never creates or adopts another Worker. A tracked Worker whose checkout changes still reports a
+mismatch; no automatic App handoff or silent registry migration is performed.
+
+## Later independent corrective evidence after a fix review
+
+A failed guarded Step can reveal a Plan obstruction after its immutable strict review recorded
+`fix` without a Plan conflict. On a clean current Task checkout, after at least two real remediation
+failures and with no decision already bound to the current ordinal, `next` can expose the optional
+`correctiveDecisionOption`. The ordinary fix action remains the default. No failure, repeated run,
+review rewrite or arbitrary scope extension is required to obtain an independent corrective audit.
+The option is absent while a Step runs, a pending handoff exists, or an earlier navigation gate
+blocks ordinary continuation. Existing writer/C1 actor and token requirements still apply; a
+legitimate claimed Worker credential does not disable this independent audit route.
+
+Only a genuine independent audit justifies using the existing `task corrective-decision` command.
+Its resulting append-only decision preserves the original review and completed Steps. A decision
+requiring replan leads to the existing corrective yield/prepare/confirmation route, including its
+separate Human gate; the option supplies no replacement authority, grant or permission to write
+additional files. A conflicting existing decision cannot be overwritten.
+
+The option's revision, Brief/Plan/HEAD and remediation event hashes describe the observation used
+for the audit. They are not a new apply token or additional executor-enforced hash contract: the
+existing executor checks its revision, current decision ordinal, audit independence and actor/token
+preconditions. Refresh `next` and audit evidence before recording, including after a HEAD change
+that does not change the Task revision. Never treat stale option output as authorization.

package/docs/delegated-approval.md

@@ -66,6 +66,32 @@ half of an atomic content-only Task context refresh in that Milestone. Standalon
 approval remains project-scoped. The contract does not add a generic delegation transition:
 outcome, success signal, acceptance, checks, discovery, and base branch remain immutable.
 
+## Full contract during an active Milestone
+
+The human may request `milestone autonomy-prepare` / `milestone autonomy-grant` while a
+Milestone is `active`, as well as before its initial execution. This supports first full
+issuance or replacement after expiry/revocation without resetting the Milestone, altering
+its Plan or completed Task evidence, or recreating its Worker. Planning, blocked, validating,
+final-acceptance and terminal Milestones are not eligible for this route.
+
+Preparation is read-only. It requires a coherent registered repository, a complete current
+Plan and active Knowledge Map. Its MAC binds the status, revision, Plan, semantic scope,
+principal, delegate, exact expiry (at most 72 hours), policy and previous authority state.
+Show this complete contract and obtain a separate exact human confirmation. Never renew a
+contract automatically or treat general delegated execution as permission to issue authority.
+
+A still-valid full contract cannot be replaced. An explicitly revoked or expired contract
+may be replaced using a freshly prepared MAC. The previous confirmed code cannot undo a
+revocation. Exact retries retain the same contract/grant; an interrupted event-first write
+can be completed only with its original matching confirmation. Issuance and milestone grant
+revocation share a Milestone lock. History remains append-only.
+
+`next` exposes optional `activeMilestoneAutonomyOptions` even when a linked Task is selected;
+this does not change the immediate Task action or waive its credential/review/recovery gates.
+A coexisting generic grant remains unchanged and does not gain membership evolution or atomic
+context-refresh authority. The new full contract carries those existing bounded capabilities;
+it never grants standalone Project Knowledge approval or a semantic scope change.
+
 ## Starting a delegate chat
 
 A grant does not start an agent and is not attached to a Codex chat automatically. Open a new

package/docs/pdf/sources/codex-workflow-v2-architecture-ru.md

@@ -463,7 +463,7 @@ Restart Docker Desktop требует отдельного разрешения
 # 10. Operational checklist
 
 - exact package version установлен, bundled gateway соответствует release и переустановлен;
-- handshake подтверждает `packageVersion=2.0.0-beta.13.1`, protocol 2, state schema 2 и beta.13
+- handshake подтверждает `packageVersion=2.0.0-beta.13.11`, protocol 2, state schema 2 и beta.13
   capabilities;
 - routine observation начинается с компактного `status`; `status --full` запрашивается только для
   расследования, которому действительно нужна полная historical projection;

package/docs/pdf/sources/codex-workflow-v2-chat-only-guide-ru.md

@@ -57,7 +57,7 @@ AGENTS.md
 -> doctor только как дополнительная диагностика
 ```
 
-Handshake beta.13.1 должен сообщать `packageVersion=2.0.0-beta.13.1`, `protocolVersion=2`,
+Handshake beta.13.11 должен сообщать `packageVersion=2.0.0-beta.13.11`, `protocolVersion=2`,
 `stateSchemaVersion=2`, dependency DAG, initial Plan transaction, mechanical feasibility,
 Milestone autonomy, host-safe credential reference, failed-Step continuation transaction,
 cause-bound rolling refinement, structural production edge, compact status, reviewer runtime preflight,
@@ -168,8 +168,6 @@ base HEAD. Final acceptance выполняй только по exact eligible gr
 текущему MSA-code; иначе покажи полный requiredHumanGate и остановись.
 ```
 
-<!-- pagebreak -->
-
 ## 4.1. Что должно получиться до autonomy gate
 
 - Discovery без blocking unknowns;
@@ -481,8 +479,8 @@ Task/project DGR. `dependencyBinding` для standalone handoff равен null.
 
 # 14. Итоговый checklist пользователя
 
-- beta.13.1 exact package и новый bundled gateway установлены; handshake показывает
-  `packageVersion=2.0.0-beta.13.1`, protocol/state schema `2/2` и beta.13 capabilities;
+- beta.13.10 exact package и новый bundled gateway установлены; handshake показывает
+  `packageVersion=2.0.0-beta.13.11`, protocol/state schema `2/2` и beta.13 capabilities;
 - новый Coordinator chat не является fork старого Milestone;
 - bootstrap DGR, если нужен, выдан отдельным exact human confirmation;
 - Discovery не materialized при blocking unknowns;

package/docs/pdf/sources/codex-workflow-v2-technical-reference-ru.md

@@ -15,7 +15,7 @@ authority сами: mutating permission определяется runtime state
 
 | Параметр beta.13 | Значение |
 |---|---|
-| npm package | `codex-workflow-v2@2.0.0-beta.13.1` |
+| npm package | `codex-workflow-v2@2.0.0-beta.13.11` |
 | protocolVersion | 2 |
 | stateSchemaVersion | 2 |
 | lifecycle epoch | 2 |
@@ -333,7 +333,7 @@ local reviewer внутри Codex App sandbox.
 | Повтор stable reviewer `causeId` с `planConflict=true` | Root-cause replan той же Task обязателен |
 | Похожий prose, номер попытки или reviewer cause без Plan conflict | Не создаёт replan authority |
 | Finding `route=fix` или route отсутствует | Продолжить ту же Task/Step независимо от attempt count |
-| Finding `route=replan` с exact Plan conflict | `task plan-set`; меняются только implementation Steps |
+| Finding `route=replan` с exact Plan conflict, включая первый провал | Штатный corrective yield/replan; повторный run запрещён, меняются только implementation Steps |
 | `route=replan` без exact conflict | Невалидный review result, state не меняется |
 | Explicit `split-required` | Structural replacement stop |
 | Exact beta.11 attempt-four `stop-escalate` | Append-only Human-confirmed compatibility override |
@@ -669,6 +669,14 @@ beta.12.19 runner выдаёт `compatibilityMode=post-rebind-dirty-carryover`,
 обычный dependency-only transport, repository-local registration, Knowledge rebind, PRA,
 authorization, checks, Core commit и sealed review. Human approval не добавляется.
 
+В beta.13.10 `task context-refresh` различает `authority=execution` и
+`authority=planning-only`. Для начатой Task с failed Step, сохранённым stop-PRA и
+проверенной историей Knowledge-only rebind безопасный content-only refresh обновляет
+Knowledge-привязку и сохраняет отрицательный аудит. Task остаётся
+`awaiting_execution_authorization`: разрешение исполнения не создаётся.
+Далее требуется прежний corrective route, независимый аудит и точный human gate
+замены Plan. Повреждённая история и неподходящий drift не дают этого режима.
+
 # 15. P04-A structural replacement boundary
 
 Command shape `task replacement-materialize` retained только для compatibility diagnostics. Любая попытка
@@ -767,7 +775,7 @@ dirty update.
 observed-route matrix/compact-status/reviewer-runtime tests, legacy compatibility regressions,
 `npm run test:signal-t10-check-support-e2e`, `npm run test:signal-remediation-e2e`,
 `npm run pack:check`, `npm run smoke:downstream`, `npm run plugin:check`, official plugin/skill validators,
-`npm run docs:pdf:check` и `npm run release:check` с exact `v2.0.0-beta.13.1` tag binding и append-only
+`npm run docs:pdf:check` и `npm run release:check` с exact `v2.0.0-beta.13.11` tag binding и append-only
 real-agent lifecycle log. Candidate проверяется из clean source checkout; missing built module не должен
 превращаться в stack trace, а обязан быть детерминированно собран или диагностирован release gate.
 

package/docs/pending-review-update.md

@@ -0,0 +1,15 @@
+# Updating while a strict Step review is pending
+
+This narrow bridge supports source `codex-workflow-v2@2.0.0-beta.13.1` and the exact executing target package. It preserves the original completion commit, pending review chain, Plan and Knowledge authorization. It does not mark a review passed or bypass the following Knowledge refresh.
+
+Use only a verified, exact target package runner with capability `pending-strict-review-dependency-bridge-v1`. The source preflight checks its package/build manifest and runtime file hashes. Never use a mutable version range or a global runner. The target runner exception before installation permits only the read-only source preflight below. Use the installed source runner for an explicitly returned stale lease repair.
+
+1. Run the external target runner: `update pending-review-source-preflight --repo <repo> --id <Task> --json`. Save the complete JSON response outside the repository. If `staleLeaseRepair` names exactly this Task, use the **installed source** `locks repair --id <Task>` and rerun source preflight. The lock manager rechecks expiry; a live or unrelated lease is not repairable through this bridge. Do not transport until the fresh result has `eligible=true` and no blockers.
+2. Retain the exact source receipt. Create one dependency transport commit on its `baseBranch` at `baseHead`, using a separate temporary worktree. Create one on `taskBranch` at `completionCommit`. Each commit must have one parent, change exactly `package.json` and `package-lock.json`, and change only the exact Workflow dependency entries from source to target. Preserve all product-owned manifest/lock fields independently on each branch. Do not merge, amend, reset, rebase, copy the base manifest over Task changes, or transport product work.
+3. Install the exact target package in the Task repository. Use its repository-local runner for all remaining commands. Run `status`, then `next`; it must advertise `update pending-review-dependency-recover`. Run `update pending-review-dependency-preflight --id <Task> --file <source-receipt.json>`. Require `eligible=true` and no blockers.
+4. Run `update pending-review-dependency-recover --id <Task> --expected-revision <source-task-revision> --file <source-receipt.json> --actor <coordinator> --reason <substantive-reason>`. Both plain preflight results and CLI `{ok:true,value:...}` receipts are accepted. The receipt is not authority: recovery reconstructs every source binding from canonical Task, artifacts, strict-review sidecars and Git parent commits. It checks clean checkout, all target version surfaces, exact base transport, and absence of any writer lease or pending transaction/Core operation again.
+5. Recovery atomically registers the Task dependency commit in existing dependency provenance and writes the hash-chained `pending-review-updates.jsonl` sidecar. Task schema 2 is unchanged. It increments the Task revision but preserves the original pending event, product completion SHA and Step evidence. Repeating recovery is rejected rather than creating duplicate authority.
+6. Run `status`, then `next`. Recover the exact advertised C1 writer credential if necessary. Generate a fresh `task step-review-packet`; use an independent external sealed reviewer and record the unchanged result with `task step-review-record`. The packet binds the original product commit and includes revalidated transport evidence; its repository seal binds the current dependency HEAD. Any later HEAD, base, Plan, evidence, packet, or seal change fails closed. Local nested review retains its original HEAD guard.
+7. Follow fresh `status` and `next` after review. Under the original eligible Milestone Autonomy Grant, execute the advertised `task context-refresh` for predeclared supporting-source additions and dependency manifest drift. Then continue to the next normal Step or final Task boundary. Do not substitute standalone approval or manually edit state.
+
+A failed preflight is a stop for this bridge. Repair only a specifically documented obstruction, then rerun the read-only assessment; never edit the receipt to hide a blocker. A pending or corrupt transaction must be recovered through its ordinary exact route before retrying.

package/docs/release.md

@@ -1,9 +1,280 @@
 # Release Policy
 
+## beta.13.11: preserve production edges through corrective Plan admission
+
+The closed public corrective Plan schema now admits the existing optional
+`productionEdges` and `requiresProductionEdges` fields. A valid production Plan
+previously passed domain validation but failed public preparation as an unknown
+property. The fix retains the closed edge structure, domain checks, immutable
+candidate binding, and separate human confirmation. It does not widen Task scope
+or authorize execution.
+
+Release evidence must include public prepare/confirm/execute with nonempty
+production edges, exact persisted-field preservation, invalid/unknown-field
+rejection, and rejection of candidate changes after preparation. Schema parity
+coverage must catch future additions to the canonical Plan input contract.
+
+
 The npm package is `codex-workflow-v2` with public visibility. Consumers must pin
 an exact version. Stable compatibility covers the latest minor release of the current
 major only; older minors are unsupported unless a release note explicitly says otherwise.
 
+## beta.13.10: planning-only context refresh
+
+A dependency update can stale Knowledge while a started Task retains a failed Step
+and a stop-escalate Plan Risk Audit. Navigation and execution now share the verified
+planning-recovery predicate. Safe content-only refresh returns `authority: planning-only`,
+rebinds Knowledge, preserves the stopped audit and completed evidence, and leaves the
+Task awaiting execution authorization. It never authorizes the stopped Plan.
+The ordinary corrective decision, original Worker recovery, independent replacement
+audit and exact human corrective-replan gate remain required.
+
+The regression follows actual dependency transport and provenance recovery through
+Core-generated navigation and the refresh executor to the corrective human gate.
+Tampered history, stale revision, missing grant and write failure are rejected without
+partial Task/Knowledge/Plan/audit updates. Unsupported stopped Tasks are not offered
+an executable context refresh.
+
+## Prospective disposable-fixture bootstrap
+
+For candidates after beta.13.9, release tests may initialize a disposable synthetic
+fixture without requesting a live user's Knowledge approval for each candidate.
+This does not change the completed beta.13.9 gate or reinterpret its evidence.
+Production projects, including Signal, retain their existing human/delegation gates.
+
+Run the repository-only `scripts/bootstrap-disposable-release-fixture.mjs` with
+`--candidate <absolute tarball> --sha256 <exact SHA256> --version <exact version>`.
+Use `--preflight` first. The tool accepts no repository, state-root or template
+override: it creates fresh owned temporary roots, installs the verified candidate
+with lifecycle scripts disabled, and initializes a fixed fixture with an immutable README and a mutable smoke.txt marker. It uses
+the installed candidate's Core and explicit isolated state, following the existing
+test-helper bootstrap pattern. No production credentials or grants are imported.
+The same synthetic owner initializes a 24-hour fixture-project grant only for
+`agent:disposable-release-worker`, limited to Task execution authorization and final
+acceptance. Its confirmation is simulated and labelled accordingly. It grants no
+Knowledge refresh, scope expansion or production access. Expiry requires a new
+disposable run, not silent renewal. The fixed scenario must not modify Knowledge.
+
+The receipt explicitly labels Knowledge consent as **simulated**. Core's stored
+`authorizationMode: human` is test setup here, not evidence of an actual human
+approval. Neither that state nor its receipt may be imported into a production
+project or presented as production authorization. Candidate, template, repository
+and state identities must accompany every downstream evidence record.
+
+Synthetic lifecycle tests prove contract behavior, including approval rejection
+and credential recovery. They do not prove the actual App writer/reviewer boundary.
+The separate actual App gate remains required on the exact candidate: a live Worker
+changes the fixed smoke.txt line `Release smoke: pending.` to `Release smoke: complete.`,
+runs its declared check, and a separate App reviewer consumes a bound external-sealed
+Step or Task packet, as advertised by Core. The minimum App smoke ends after the Worker records that review through
+fresh `next` and obtains successful `status` then `next`; no additional human terminal
+acceptance is imposed by this smoke. No new fixture product feature is required per release.
+The App report must disclose the synthetic bootstrap and claim only the App behavior
+actually observed; it must not claim real user consent. Prior failed attempts,
+exact-candidate binding and the ordinary transcript validator remain mandatory.
+This is a test evidence policy, not a runtime approval bypass or an expanded grant.
+
+## beta.13.9: failed-Step planning recovery after Knowledge rebind
+
+A started Task can retain completed Steps and a failed guarded Step while a Knowledge
+rebind supersedes its execution authorization. A truthful blocking Plan Risk Audit must
+not require a false approval to reach corrective planning. This recovery uses the current
+blocking audit as planning evidence and proves its unchanged safety baseline through
+hash-checked Knowledge-only Plan history and the historical superseded authorization.
+It never treats either record as current execution authority.
+
+Fresh navigation can then advertise the existing independent corrective-decision route.
+The ordinary corrective yield, independent replacement validation and risk audit, exact
+human corrective-replan confirmation, and fresh execution authorization remain mandatory.
+An ordinary `plan-set` cannot bypass that chain. `continue-fix` is not a valid decision
+for this stopped planning posture; ordinary execution repair retains its existing choices.
+The additive upstream-remediation route remains limited to genuinely unstarted Tasks.
+
+Release evidence must exercise the complete callable recovery chain, including original
+Worker credential replacement and yield, repeated Knowledge rebind, unchanged completed
+Step and failed review evidence, and rejection of damaged Plan/audit/authorization history.
+
+The exact beta.13.9 runner retains the consumed-carryover compatibility profile from
+beta.13.6 with beta.13.9 as its pinned target. The source, ownership, lease, candidate
+Plan, provenance and transaction checks are unchanged. Historical beta.13.7 and
+beta.13.8 transcripts remain bound to their original targets.
+
+## beta.13.8: explain changes and continue active Milestones
+
+Full autonomy can be issued during an active Milestone using an exact new human-confirmed
+contract. Interrupted event-first issuance remains recoverable after expiry or revision change:
+a fresh confirmation may supersede an inert missing grant, preserving its event and creating a
+new grant identity. Known unpublished grant directories carry no authority; malformed state and
+unknown incomplete delegations still fail closed.
+
+The read-only `change explain` command separates execution context, external approval, semantic
+scope, bounded check-support amendment, Plan correction, membership and context refresh. It
+preserves the current Core route, including credential prerequisites and effective Step scope.
+Its proposal hash is diagnostic evidence, not permission to apply a patch.
+
+Chat dispatch records the observed child checkout and offers an advisory context check before
+writes. Existing Workers are preserved; a parent repository path does not authorize writing
+outside the actual child checkout. Model and reasoning selection remain task-specific.
+
+The exact beta.13.8 runner retains the tested beta.13.6 consumed-carryover source
+recovery profile with beta.13.8 as its pinned target. It does not admit a beta.13.7
+source or a running Step; historical beta.13.7 transcript evidence remains separately
+valid for its original target.
+
+All ordinary release gates below apply to the exact versioned candidate. Historical failed
+real-agent runs remain failed evidence; prior one-time release exceptions are not reused.
+Signal deployment additionally requires a fresh safe update boundary, exact installed provenance
+and verified continuation by the original Worker. This release does not waive external approval
+or claim to prevent every future product failure.
+
+## Active Milestone autonomy contract issuance
+
+The candidate extends full human-confirmed autonomy to an already active Milestone.
+Release evidence must cover both initial active issuance and replacement after revocation
+or expiry, without resetting Task state, changing membership/semantic scope, or replacing
+an existing Worker. A generic delegation is neither upgraded nor revoked implicitly.
+
+The MAC includes the previous contract/grant snapshot so a revoked confirmation cannot
+restore authority. Exact successful and interrupted-write retries must preserve identity;
+legacy event-first records retain their bounded pre-execution recovery. Shared Milestone
+exclusion protects issuance, revocation and scope/status transitions.
+
+Acceptance must continue through same-Worker execution and guarded atomic context refresh
+using the new full contract, with the old grant rejected without Task/Knowledge mutations.
+Include read-only preparation, stale bindings, valid-contract replacement refusal, malformed
+actors/expiry, unavailable Knowledge and disallowed Milestone states. Optional Task-first
+navigation must not replace the current execution/recovery action. Run the full test suite,
+release checks, downstream package smoke and plugin validation on the final candidate.
+
+## beta.13.7 candidate: retire completed carryover authority
+
+After a recovered Step passed review, its recorded dirty-work permission still
+overrode the next Step's route. A later repeated mechanical failure therefore
+returned `doctor` instead of ordinary Plan replacement. The completed record is
+now retained as history and consumed only after its completion evidence, exact
+PRA, required strict review and Git history are verified. Active or damaged
+bindings continue to fail closed. A corrective claim must belong to the same
+Worker who performed the terminal corrective yield.
+
+The exact published beta.13.7 read-only compatibility preflight can guide a
+stranded beta.13.6 source through its existing Plan replacement and original-Worker
+handoff commands before transport. It does not mutate state, authorize execution,
+or waive approval gates. Task and base transport must preserve all product bytes
+and change only the exact Workflow dependency. See the packaged gateway skill for
+the stage-specific bindings and mandatory source status/next readbacks.
+
+Release evidence must include the published beta.13.6 runtime reproducing the
+later-Step blocker, source Plan/PRA/authorization/handoff recovery, dependency
+transport, target provenance/context refresh, same-Worker execution and strict
+review. A route that reaches only `plan-set` is not sufficient. Prior one-time
+release-gate exceptions do not authorize this candidate.
+
+The trusted lifecycle harness must record each compatibility invocation and its
+terminal observation. For source `task plan-set`, record `inputBinding` computed
+from the actual files passed to that command: `candidatePlanHash` is the rendered
+Plan hash, and `candidateInputHash`/`riskAuditInputHash` are SHA-256 of recursively
+key-sorted canonical JSON inputs. Do not copy these values from an approval receipt
+without checking the executed inputs. The validator checks this binding, the resulting
+Plan hash, original-Worker ownership, ordered source status/next checkpoints, live-lease
+waiting, exact stale repair, and a fresh preflight before transport.
+
+## beta.13.6 candidate: preserve work across root-cause replan
+
+A repeated mechanical failure can legitimately yield the same Task to a replacement
+Plan while preserving uncommitted implementation. beta.13.5 authorizes that Plan but
+then rejects its planned Step because the checkout is dirty. Reaching planning or
+reauthorization therefore does not prove recovery.
+
+Acceptance for this candidate must exercise the complete repeated mechanical failure,
+automatic C1 yield, semantic replacement Plan, independent PRA, authorization, and
+same-Worker execution sequence with the original dirty bytes. The carryover assessment
+must bind the source remediation cycle, verified historical and current Plans, current
+PRA and authorization, completed evidence, HEAD, file set and content hash. Every carried
+path must already belong to the replacement Step and remain outside forbidden scope;
+carryover never expands scope or forgives unrelated work.
+
+Navigation and execution must use the same assessment. Changed bytes, paths, HEAD,
+Plan artifacts, audit/authorization evidence or ambiguous source history must fail
+closed before execution. Tests must continue beyond successful start through checks,
+Core commit and strict review, and reject each material binding mismatch.
+
+The stranded-source update must additionally prove a read-only compatibility preflight,
+no writer lease or pending Core operation, exact coherent source/target versions,
+dependency-only Task and Milestone-base commits, registration of the Task dependency
+commit after verification of the base transport, and unchanged product bytes. It must preserve the original Task and Worker and must not
+rely on manual product commits, stash/reset, installed-code edits or state-file edits.
+
+All ordinary release gates below apply. The user's one-time beta.13.5 CI-based release
+exception is consumed and is not evidence or an exception for this candidate.
+
+## beta.13.5 preventive Plan correction before execution
+
+A newly discovered implementation Plan defect can require changing unfinished scope
+before its next Step runs. The preventive route withdraws the current execution
+authorization under an independent blocking Plan Risk Audit, then requires a corrected
+Plan, fresh independent audit and ordinary execution authorization. It must preserve
+the same Task, completed Step definitions and evidence, requirements, acceptance,
+review history and grants. It must not manufacture a failed run to unlock planning.
+
+Initial eligibility is deliberately limited to a coherent, clean, idle `ready` Task
+with no C1 ownership or writer lease. Stale bindings, existing ownership, incomplete
+review, unexpected Git history and damaged state must fail closed. Regression gates
+must prove authority withdrawal and actual same-Task continuation, plus rejection of
+attempts to change the objective, discard completed evidence or weaken guarded scope.
+
+Replacement Plan publication commits Task state, the current and immutable Plan artifacts,
+and its independent audit atomically. Pending correction blocks C1 handoff and dependency
+transport until the corrected Plan can be authorized. Proof bindings retain each Step,
+failure mode and evidence association; revised proof prose requires an independent audit
+with an explicit rationale. Core does not determine whether natural-language proof claims
+are semantically stronger.
+
+External sealed-review CLI help specifies the complete envelope, including its nested
+review. Lifecycle validation admits one bounded expired-credential recovery between a
+review-input syntax refusal and retry, with unchanged sealed evidence and fresh sequential
+status/next bindings; unrelated or unbound mutations remain invalid.
+
+## beta.13.4 candidate: continuation after accepted corrective Plan
+
+This correction is included in beta.13.5; beta.13.4 was not published separately.
+
+The beta.13.3 first-conflict recovery stopped too early: after a replacement Plan
+was accepted and authorized, navigation still applied the old Plan's conflict to
+the now-planned Step. Release acceptance for this correction must exercise the
+complete same-Task sequence through fresh Plan Risk Audit, execution authorization,
+the existing Worker claim, actual Step execution, and another failed review.
+Reaching `task plan-set` alone is not sufficient evidence.
+
+An accepted semantic replacement must be distinguished from a Knowledge-only
+rebind using verified Plan artifacts and audit/review bindings. Historical failures
+and their global ordinals remain append-only. A missing or damaged artifact must
+not silently acknowledge a conflict, and a context refresh must not reopen execution.
+
+## beta.13.3 explicit Plan conflict recovery
+
+A first independently recorded reviewer `route=replan` with a validated Plan conflict
+blocks current execution immediately and exposes corrective replan. Historical
+rolling-cause classification remains unchanged; valid older histories are not
+reclassified as corrupt. Ordinary new fix findings still continue in the same Task.
+The failure transaction yields C1 and releases the exact writer lease. An older
+failed Task with a retained C1 claim follows credential recovery and
+`task corrective-yield` before planning; it cannot run or change its Plan while
+the claim remains. Recovery binds the validated remediation event and preserves
+the Task, review evidence, and existing worker identity.
+The release also includes durable App dispatch and explicit role/phase model selection;
+see the packaged `references/chat-dispatch.md`.
+
+## beta.13.2 review recovery gate
+
+The patch preserves protocol 2 and canonical entity schema 2. In addition to the
+ordinary release gates, `release:check` executes the large-diff, pending-review
+update, supporting-source refresh and Task guard regressions. Acceptance requires
+complete external-sealed Step and Task packets above 2 MiB, explicit bounded
+failure above the Git output limit, exact credential recovery before Knowledge
+refresh, and a Signal-shaped delegated update followed by actual review,
+context refresh and the next ordinary Step. A source preflight alone is not
+recovery completion. See `beta13.2-signal-review-recovery.md`.
+
 ## Release gate
 
 Before tagging a release:
@@ -52,8 +323,8 @@ surface and fails unless all of these release contracts remain present:
   adds C1 yield before root-cause replan; the Signal-shaped E2E continues through recovery, the next
   ordinary Step, Task completion, and next-Task dispatch;
 - five distinct or unclassified review findings continue in the same Task without a numeric cap,
-  while root-cause replan requires either a repeated normalized mechanical failure or the same
-  stable external reviewer `causeId` with `planConflict=true`;
+  while repeated normalized mechanical failures still require root-cause replan; a current
+  explicit external reviewer Plan conflict requires replan immediately, without a synthetic retry;
 - a transitive same-component check owner may refine the same Task only under the unchanged semantic
   boundary; for a multi-Step `runtime-composition` consumer the independent PRA classification,
   not a planner opt-in, requires an edge from a transitive owner to an exact executable consumer

package/docs/updating-existing-project.md

@@ -636,8 +636,16 @@ title в registry readback и применяйте только возвращё
 быть уникален и содержать exact `#NNN`, membership ordinal и ID. Input должен состоять из
 TaskContextPacket; допустима только добавленная Codex App служебная `codex_delegation`-обёртка с
 `source_thread_id`, но не parent turns или transcript. Если title отсутствует или нормализован
-неверно, переименуйте и перепроверьте. Ошибка `create_thread` допускает один
-последовательный retry после проверки списка, но не разрешает fallback на `fork_thread`.
+неверно, переименуйте и перепроверьте. Pending `clientThreadId`, тайм-аут или отсутствие в
+`list_threads` не доказывают, что создание не состоялось, и не разрешают повторный `create_thread`.
+До первого вызова сохраните `dispatch-begin`; после него используйте `dispatch-result/status`,
+поиск коррелированного сеанса и `dispatch-observe` с фактическим `read_thread`. На одну
+резервацию выдаётся только одно разрешение создания. Не обходите его новой резервацией или fork.
+Полный контракт восстановления, сохранения supervisor/cursor и явного выбора `model`/`thinking`
+по роли, фазе и сложности находится в
+`plugins/codex-workflow-gateway/references/chat-dispatch.md`. Выбор модели требует соответствующего
+поручения пользователя и актуального списка поддерживаемых пар на целевом host; нельзя молча
+наследовать дорогую конфигурацию координатора или снижать уровень независимого аудита.
 Создавайте или переиспользуйте Task-чат непосредственно перед dispatch этой Task, а не как пустой
 placeholder для всего membership; `T<NN>` берите только из утверждённого membership order.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-workflow-v2",
-  "version": "2.0.0-beta.13.1",
+  "version": "2.0.0-beta.13.11",
   "description": "Requirements-first Codex development workflow with local state and explicit Git ownership.",
   "repository": {
     "type": "git",
@@ -68,6 +68,7 @@
   },
   "devDependencies": {
     "@types/node": "24.10.1",
+    "codex-workflow-source-beta136": "npm:codex-workflow-v2@2.0.0-beta.13.6",
     "typescript": "5.9.3"
   },
   "license": "MIT"