@moretea-labs/forge 1.8.0 → 1.8.2

package/docs/architecture/CURRENT.md

@@ -1,26 +1,99 @@
 # Forge Current Architecture
 
+### Historical source delivery and cleanup
+
+Branch and bundle preservation must bind the actual Git tip being retired. A WorkHandle expectedHead/checkpoint or older no-source-delta receipt cannot substitute for the current branch or verified bundle head. Bundle readback must cover that exact branch tip, and ref deletion uses expected-tip CAS so a concurrent successor remains intact.
+
+Worktree convergence separates source containment, model-authored acceptance and physical retirement. Terminal rh_work revisions, including same-terminal retries, enter the existing single-Work cleanup owner; Git integration never terminalizes a Work. Work inspection and verification use the shared structured Git candidate view for staged, unstaged and untracked paths. Runtime readiness detail uses the same live owner observation as summary. See [the 2026-10-17 decision](../researches/20261017-worktree-convergence.md).
+
+### Technical design baseline
+
+This authority applies one default design rule across new architecture and refactors: **Forge is thin but capable — stateless in coordination, stateful in facts, optimistic in concurrency, and explicit in effects.** The model/controller owns reasoning, workflow policy, validation strategy and semantic completion; Forge owns durable facts, execution capabilities, mechanical correctness and recoverable effects. Cognitive learning follows the same split: the model authors reusable semantic deltas and usage judgments, while the shared MCP transport may settle that bounded advisory metadata after any successful meaningful ordinary tool outcome; routine micro-steps do not create a learning lifecycle.
+
+- **One fact, one authority.** Do not repair ambiguity with mirrored status, a compatibility owner, a second lifecycle, or another orchestration store. Composition services should remain stateless over existing authorities whenever practical.
+- **Classify state explicitly.** Durable semantic facts survive restart; runtime handles/connections are ephemeral; summaries, indexes and status views are rebuildable projections. Transport or execution identity must never become semantic identity.
+- **Prefer optimistic concurrency.** Use expected-revision/CAS for semantic aggregates; serialize only the narrow aggregate or physical resource that truly conflicts, while unrelated aggregates remain parallel. Leases and fences protect liveness/physical mutation, not semantic truth.
+- **Effects are explicit.** Reserve stable effect/request identity before replay-sensitive external mutation. Reads may retry when provider semantics allow it; idempotent mutations reuse the same key; ambiguous non-idempotent outcomes become `outcome_unknown` and must be observed/reconciled before any replay. A Supervisor `effect_not_applied` receipt authorizes retry only for its exact latest dispatch generation; delayed evidence from earlier generations is non-authoritative, including when read from a pre-fix journal. Bootstrap pre-send negative proof is internal to the exact Computer dispatch owner's `not_attempted` return (no Send click); public bootstrap observation RPC can only commit `applied` or `unknown`. The generic browser RPC likewise cannot attest a negative dispatch outcome; only the in-process Computer dispatch owner may write that proof. Unknown provider mutation never becomes retry authority through an observer.
+- **Events trigger; state decides.** Duplicate wakes/recovery demand coalesce around canonical occurrence/effect identity. Contention is a scheduling condition rather than semantic failure when the operation can run later.
+- **Context review reads the exact Work checkout.** `rh_context.search(work_id=...)` resolves current source evidence through existing WorkContract placement and WorkHandle, then Repository Registry. It never silently reads dirty canonical main when a managed Work has a different checkout. An explicit conflicting checkout, unavailable/retired Work target, or WorkHandle HEAD drift fails closed; no second source-routing authority, provider, cache or Work lifecycle. Semantic-only Work without physical placement retains the caller's explicitly selected repository scope; capability and cognitive-only reads are unchanged.
+- **Supervisor terminal history is a projection, not archival authority.** `supervisor/control-plane.ts` derives the active view and typed DONE/NEEDS_USER/STOPPED history from existing Supervisor terminal events. MCP `supervisor_task list` defaults to active tasks; explicit `terminal_only=true` lists completed/stopped history and exact task/conversation identity without new state or deleting Work/Project records. Physical Chrome tab retirement (#286) is separate. Native ChatGPT conversation archive (#287) requires an independently verified exact reversible provider operation; this read path never performs one.
+- **Keep failure domains isolated.** Browser, MCP, plugin, provider or UI transport failure degrades that adapter/capability; it does not redefine Work/Scheduler semantics. Recovery reconstructs bindings from durable truth and reconciles effects; it does not invent a fallback authority. Direct Safe Patch sessions with no Work/Controller instance binding retain their repository identity but never acquire a new Runtime identity merely because `finalize_edit_session` is invoked by a Controller; Work-owned sessions still require exact durable identity for Runtime rebinding.
+- **Temp cleanup never owns Git source.** `src/runtime/maintenance/cleanup.ts` rejects Git worktrees, repositories, symlinks and uninspectable temp trees even when their name begins with `forge`. Canonical `/tmp` aliases are deduplicated; apply rechecks current source/liveness instead of trusting a preview. Work source cleanup belongs to Work/OwnedResource authority.
+- **No generated adoption helper compatibility wrappers.** `src/core/adoption/plan.ts` installs current declarative project assets without the retired project-local shell/TypeScript Helper wrapper generator. Production helper resolution remains in `src/cli/runtime/helper-runner.ts`; `src/core/adoption/helper-wrapper-plan.ts` must stay absent.
+- **One service/release text writer.** `src/runtime/shared/atomic-text-file.ts` is the shared implementation for Runtime/Connector service config, package-release materialization and CLI systemd-user units. It creates private parent directories, collision-resistant same-directory temporary files, honors explicit file modes, and removes unsuccessful temporary files. It is an atomic rename, not an fsync durability guarantee. The standalone Windows/WSL Controller Home migration script stays independent of Runtime source imports for host rescue.
+- **One Recovery operation lock writer.** `src/runtime/standalone-recovery/operation-lock.ts` owns cross-process mutation lock creation, liveness checks, stale-lock reconciliation and release for Core, installer and certification. `core.ts` adds action attribution and audit but does not implement a second lock acquisition algorithm; Runtime release/rollback authority remains separate.
+- **Chrome Profile identity remains stable.** The Computer-owned Chrome extension persists one provider instance ID in profile-local extension storage, shared by heartbeat, exact-tab binding and discovery. Service Worker restarts may not mint a new Controller-facing profile identity; the extension smoke validates this storage requirement and forbids stale transient-instance references.
+- **Computer ChatGPT reasoning is verified before Send.** `packages/plugin-runtime/computer/conversation-target.ts` owns the Computer Supervisor default (`xhigh`); the exact tab selects the highest supported level and returns the actual level before prompt insertion/Send, and both the pre-Send receipt and dispatch receipt preserve it. If the control or actual level cannot be verified, the operation is rejected before prompt insertion/Send. Browser automation and scheduled Controller bindings retain their existing canonical default (`high`) from `adapters/chatgpt/provider-delivery.ts`.
+- **Context Closure materiality stays with semantic navigation.** TypeScript Language Service policy-denied probes under `node_modules` remain denied and visible in bounded diagnostics, but do not by themselves block engineering admission when every requested target relationship resolves. Denied requested targets, denied returned locations, unresolved relationships, and denied non-dependency source reads remain blocking. `semantic-navigation-contract.ts` owns the sole dependency-probe classifier for the TypeScript sidecar and `rh_context` projection; no second readiness authority or bypass flag.
+- **One classifier per mechanical fact.** `src/runtime/execution/jobs/child-reference.ts` owns delegated Execution Job eligibility for both Scheduler and receipt recovery, reusing its canonical operation/local-action sets. `src/cli/repositories/structured-git.ts` owns Git porcelain status partitioning for live reads and `src/runtime/projections/git-status-sampler.ts`; sampling is a projection, not a second parser authority.
+- **Keep workflow policy above the Kernel.** Verification/review/merge ordering is user/model/project policy, not a reason to add durable `validating`, `reviewing`, `awaiting_acceptance`, `finalizing`, or similar Work states.
+- **Stay a modular monolith.** Kernel/domain modules expose small ports; adapters translate provider/transport semantics once; composition roots wire dependencies and do not own domain policy. Use distributed-systems correctness disciplines without distributed deployment machinery unless deployment actually requires it.
+- **MCP compatibility is adapter-owned.** `adapters/mcp/` owns MCP registration, schemas, transport and retained legacy handlers. CLI, Runtime, scripts and tests import the owners directly; retired CLI/Gateway re-exports stay absent under the architecture Gate. `adapters/mcp/tool-mapping/legacy-tool-service.ts` remains in production use. The canonical dispatcher rejects 41 retired names with `UNKNOWN_TOOL`; their unreachable handlers, schemas and helpers stay removed. `check:mcp-compatibility` verifies the full exposed tool-name fingerprint, preferred entry-point contracts and registered-definition collisions without a second exposure profile.
+- **Keep domain reconciliation in its owner.** Work validation lives in `src/runtime/control-plane/execution/work-validation-reconciler.ts`; MCP ingress lives in `adapters/mcp/runtime-gateway/`. Repository tool resolution must not promote WorkKind. Only admitted repository mutation, after the exact WorkHandle checkout/ownership and managed-worktree fences pass, promotes an open Work through the WorkContract writer; validation-only Safe Patch observations and no-mutation investigations never promote. WorkHandle, checkout identity and Git fences govern physical mutation independently of semantic classification. Historical decisions retain their original context.
+- **Self-host through a stable control plane.** Stable Runtime evaluates candidate source/runtime; candidate validation either promotes atomically or leaves Stable authority intact.
+- **Before adding state/store/service/daemon/queue/lock/retry paths, prove the missing fact or physical resource cannot be represented by the existing authority plus CAS, a narrow resource claim, or the existing effect ledger.**
+
+Computer ChatGPT extension projection stages the release files and retains the previous directory until replacement succeeds; if activation fails, the previous projection is restored. Browser configuration updates normalize and validate the complete candidate **before** committing the sole Controller Home v3 config with the existing atomic writer and legacy-file retirement. Explicit registry/manifest sync also migrates v1/v2 Browser config (including previously copied Controller Home files) using the Browser adapter's pure conversion and validation and the canonical atomic writer before retiring legacy files. Invalid legacy schema/JSON/CDP targets or configure requests leave authoritative Browser config and legacy sources untouched. Manifest/health reads remain read-only; repeated sync of v3 is byte-preserving.
+
 Status: **Runtime Authority**
 
 This file is the sole maintained architecture authority for the current Forge runtime. Executable code and persisted schemas are authoritative for implementation facts; this document defines the architecture contracts they are expected to preserve. Do not hard-code a source commit here: release-specific snapshots belong in [`versions/`](versions/).
 
 ## Product model
 
-Forge is an executable AI harness for a semantic controller. The controller owns requirement interpretation, repository understanding, implementation decisions, review, and the decision to keep exploring. Forge supplies fast context retrieval, deterministic local execution, provider actions, bounded verification, evidence, and optional durable continuity. Forge verification and evidence are factual inputs, not semantic acceptance rules: only the semantic Controller decides whether acceptance criteria are satisfied, whether another round is needed, or whether a Goal is complete.
+The macOS native ChatGPT composer pre-send boundary treats only a strictly text-empty single ProseMirror `<p><br></p>` placeholder as an empty editor. Layout newlines on that exact empty placeholder do not constitute user draft content; real text, including whitespace-only text nodes, remains protected from replacement. This classification never overrides the exact-conversation identity fence or the requirement to confirm the prepared composer before any Send.
+ChatGPT may hydrate the same already-applied Forge effect into unrelated Project composer tabs. The sole Supervisor ledger remains authority: a fresh bootstrap may replace only a full machine-owned draft whose effect is durably `effect_applied`, whose complete text matches the immutable effect payload modulo browser-added whitespace, and whose exact Project route and loaded replacement contract are verified. An unknown Send, modified/user draft, or mismatched page never qualifies. Existing never-dispatched STOPPED-effect retirement retains its stricter pre-Send fingerprint proof. This is one Computer preparation rule, not another provider, scheduler, or replay authority.
+
+An unbound bootstrap task reconciles its latest applied leaf against the exact conversation before dispatching any unstarted successor or recovery effect. If the exact conversation marker is not yet visible, the existing effect ledger's observation cooldown governs the next read-only reconciliation; no new send or conversation is created.
+
+
+
+Forge is an executable AI harness for a semantic controller. The controller owns requirement interpretation, repository understanding, implementation decisions and review. Forge supplies fast context retrieval, deterministic local execution, provider actions, bounded verification, evidence, and durable lower-layer continuity. Forge verification and evidence are factual inputs, not semantic acceptance rules.
+
+Long-running autonomous operation adds one higher lifecycle authority: **Workflow Supervisor** owns cross-assistant-turn scheduling for an original Goal after the current ChatGPT/MCP call stack has ended. The stable outer-turn identity is the exact logical conversation, not a Requirement, Work, MCP request, Browser tab, or provider session. When that conversation is inherited by a successor Work, reverse lookup may select only the unique open Work; completed predecessors retain historical bindings, and multiple open matches remain ambiguous. Existing Work-bound Supervisor tasks also retain their task/effect identity while a terminal predecessor resolves to a unique open successor only through explicit predecessor lineage and the same Requirement. ChatGPT still owns semantic reasoning and submits a bounded `CONTINUE | DONE | NEEDS_USER` decision in its completed final assistant reply; MCP tool completion cannot close the outer turn. Computer preserves message line boundaries; when an already-loaded extension still flattens a trailing compact receipt, Computer may accept only a read-only native observation of the same exact target, never a second send. Supervisor validates the final receipt against the challenge in the immutable applied effect prompt, including when bootstrap binding has subsequently changed the Task conversation identity. Supervisor derives the exact task, conversation and applied source effect locally. Persisted legacy tool receipts and older assistant-text envelopes remain read-only causal compatibility for already-durable conversations. `DONE` and `NEEDS_USER` become terminal only after the configured completion/blocker contracts validate authoritative evidence. Work, ControllerRound, Scheduler and MCP/session recovery remain lower-layer authorities and must not impersonate this outer turn scheduler. See [Workflow Supervisor authority](decisions/20260916-workflow-supervisor-authority.md). V1 persists this authority only in `${ControllerHome}/supervisor/supervisor.sqlite`; `control-plane.sqlite` and the declarative `workflow_run` namespace are lower-layer authorities and are not Supervisor storage.
+
+After explicit enrollment, the Supervisor task/effect/completion journal alone owns the prompt chain. A blocked, never-sent provider recovery cannot hide a completed assistant reply from its already-applied source: the native consumer keeps one bounded read-only receipt probe. If that source completion is committed before recovery dispatch begins, the now-obsolete recovery is excluded from pending-effect selection by the existing completion journal; no new lifecycle, writer, or retry authority is introduced. Once recovery dispatch starts, the original outcome-unknown fence remains intact. For an already-enrolled standalone Supervisor, the fifteenth **committed** `CONTINUE` receipt since the most recent conversation migration atomically changes the successor to a fresh enrollment and records the one canonical conversation move in the same Supervisor transaction. The fresh bootstrap must be a new `/c/<id>` and cannot rebind its source conversation. Only genuinely current provider UI (not message history) may report a terminal conversation-length limit and initiate a bounded CAS-fenced migration; the duplicate-migration guard counts moves without a subsequent successful completion rather than imposing a lifetime cap. A causal `CONTINUE` atomically reserves its fixed successor; it never requires a lower Work to remain present, a ControllerRound budget to reopen, or a manufactured ControllerSession claim/release. Lower round preparation remains initial admission/direct-effect bookkeeping, and authenticated repository mutations keep their own scope, ownership and resource fences. An explicit conversation rebind denies new sends to the previous conversation while already-started effects remain eligible for read-only reconciliation. Scheduler uses canonical Work lookup for relay-referenced semantic Work instead of treating a repository projection omission as deletion. See [Supervisor turn authority](decisions/20261001-supervisor-turn-authority.md).
 
 ```text
-Semantic Controller
-  -> Context Engine
-  -> Thin Execution Harness
+Original Goal / exact logical conversation
+  -> Workflow Supervisor (cross-turn durable authority; conversation-stable task)
+  -> active Requirement/Work scope
+  -> Semantic Controller / ChatGPT turn
+  -> Context + Thin Execution Harness / Forge Work
   -> Verification / Evidence
-  -> Optional Durable Workflow / External Effect boundary
+  -> Provider / External Effect boundary
 ```
 
+Project/browser discovery is a projection into that one authority, not another scheduler. A ChatGPT Project adapter may discover exact `/c/<id>` conversation identities for a repository-derived project scope and persist bounded discovery metadata. All Work-bound ChatGPT progression enters one stateless Runtime composition: launcher, Schedule and Scheduler liveness may prepare or reuse the same ControllerSession/ControllerBinding/ControllerRound mechanical facts, but none may submit a provider turn. `launcher_start` validates the request, optionally binds an explicit/current conversation, establishes retained controller identity when needed, invokes the canonical progression composition and returns without creating a Browser session or synchronously waiting for provider delivery. The composition derives/reuses the exact ControllerRound occurrence and provider-effect identity, then reserves the corresponding Workflow Supervisor task/effect. For a fresh Work with no canonical `/c/<id>`, Supervisor registers a bootstrap task against the ChatGPT root; only after that effect is durably reserved may the provider-neutral Computer ChatGPT target port ensure a target and dispatch the provider mutation. The Computer-owned Chromium extension is the sole Work-bound ChatGPT semantic provider; Apple Events remains an explicit native Computer primitive, never an automatic continuation fallback; neither provider owns or directly consumes the Supervisor effect ledger. After Send, the content script observes a newly committed exact user turn in-page instead of polling background snapshots; a missing commit proof remains outcome-unknown for Supervisor reconciliation and never authorizes resend. After the first confirmed submission exposes ChatGPT's canonical conversation URL, Supervisor atomically adopts that exact conversation as the durable task identity. For an already-bound conversation, the same registration RPC returns the existing conversation-stable task, including across explicit predecessor/successor Work turnover. Workflow Supervisor's effect ledger is the sole Work-bound ChatGPT send/retry/outcome-unknown replay authority; each applied turn settles through its existing task-scoped Forge automation receipt at the canonical MCP server dispatch boundary (after any successful execution, process, repository, durable or runtime tool lane, never solely inside a runtime adapter), with recovery/correction causality carried only as bounded model-facing advisory context; an idle provider response lacking a receipt remains an observable applied obligation and must not automatically trigger another provider send as though generation had hung; ControllerRound retains the lower mechanical occurrence/effect identity but is not a second provider replay owner. Browser/session/Supervisor unavailability before provider submission therefore remains lower-layer availability evidence and must not consume a provider-dispatch failure budget. Explicit `bound` transport without an existing binding or explicit URL is rejected rather than guessing from the foreground browser. Repeated discovery converges on the same conversation-stable Supervisor task. A mutable project title may select a discovery scope but never becomes conversation, Goal, Requirement, Work, or terminalization authority. Browser tabs, DOM, Accessibility, Native Messaging and project pages remain replaceable transports. Newly created and already-bound Chrome tabs use the same identity-checked content-script receiver restoration while waiting for the hydrated editor. Successful ensure always requires hydrated UI; failed ensure retains the exact created physical binding without Send authority, so repeated bootstrap attempts can reuse the Controller's canonical Surface rather than minting another Project tab. The Chrome extension may rebind a stale physical tab pin after Chrome restart only when its original provider instance reports exactly one verified tab for that exact conversation; the canonical Computer Surface lease updates the single binding, never changes profile principal or authorizes a new Send. Duplicate exact tabs remain ambiguous. The canonical Chrome extension repairs a missing content-script message receiver only on the already-resolved, revalidated exact conversation/Project tab: same-tab core/content script injection is a read-only preflight, never a new window, tab navigation, draft replacement or effect replay. Declarative injection and recovery injection share one document-local content listener guard so one physical Send cannot be handled by duplicate script listeners. A previously applied but unbound bootstrap effect stays eligible for late-receipt marker reconciliation at the same ledger-backed unknown-observation cadence as other uncertain effects, not once per consumer tick while a newer unknown effect is spaced. Chrome content-script preflight resolves one visible composer, prefers the active hydrated main, excludes hidden/inert shells, and fails closed on ambiguity; it never clears an unowned draft or bypasses effect reservation. Failed preparations retain only a bounded read-only composer classification/length/fingerprint and selector-version receipt in the original Supervisor effect event, never a draft payload or a second retry state. Computer Surface stable identities are immutable during active ownership. A rejected Supervisor bootstrap with a nonempty unowned composer never clears or sends it. An on-device exact task/effect/Project URL/fingerprint authorization marker can permit a 0600 local evidence copy from that same Chrome-extension snapshot; absent marker, nothing is saved. An additional 128-bit nonce in the marker permits a prepare-only same-tab replacement after that backup succeeds and only while the visible editor digest still matches; the Controller atomically consumes that nonce in a durable 0600 record before emitting the envelope (including on failed prepares), preventing replay across retries or Runtime restarts; the extension removes the internal guard before staging the canonical effect prompt and never sends the guard. Actual Send remains under Supervisor dispatch CAS. No draft text enters Supervisor receipts. Session-bound native Browser reads require the original pinned physical tab; even a different tab with the same URL is not an identity match; missing/ambiguous tabs fail closed without creating a replacement, switching to another profile, or invoking Playwright. Explicit new-page navigation has a separate create contract. A terminal Surface releases its physical tab binding index while retaining stable/alias identity for explicit reactivation; legacy terminal binding indexes may be reclaimed, but an active owner cannot be displaced. A separate terminal-binding key within the same Computer Surface index is negative migration evidence only: a repo-local legacy Browser session import cannot revive that terminated tab under another alias, while explicit current rebind can still claim the released live binding. The existing Computer index-ready marker upgrades this projection in place; tombstone retention removes the terminal key with its canonical record. ChatGPT provider mutation is one bounded external-resource lane per active authenticated Controller Browser/bridge identity: concurrent continuation/standalone sends serialize in the active Runtime, and Workflow Supervisor outer-turn delivery shares that Runtime's provider-pressure scope; explicit 429, timeout, stream-unavailable, or outcome-unknown evidence creates shared transient provider backpressure with bounded exponential delay and `Retry-After` preference; pre-submit rate limiting never becomes an ambiguous send; post-submit rate limiting remains outcome-unknown and is reconciled rather than replayed. Provider-failure classification uses dedicated live error/status UI and typed network diagnostics where available, never ordinary conversation text; while 429 backpressure is active, Workflow Supervisor may continue bounded local observation but must neither mint a rate-limit recovery effect nor submit a recovery prompt. Only an explicitly enrolled unattended-continuation task receives generation liveness recovery: if the exact conversation continues to advertise generation but its assistant/provider activity digest is unchanged for the bounded grace window, Supervisor treats that turn as stale and reserves the existing exactly-once same-conversation recovery effect; ordinary non-enrolled chats are never adopted, and the already-applied source effect is never replayed. A bound `/c/<id>` is transport identity, so navigation failure fails closed instead of falling back to the ChatGPT root or inventing a replacement conversation. Provider pressure/session state is mechanical and process-local, never Requirement/Plan/Work lifecycle authority; ControllerRound effect identity remains the durable replay fence across Runtime rotation. A canonical Runtime rotation may mechanically rebind an exact live same-principal ControllerRound to the successor Runtime, but it must preserve that round's durable authority id rather than requiring chat-driven rekey; explicit stale or foreign authority remains fail-closed. Canonical Runtime projects one package-owned Computer Chromium extension and its Native Messaging bridge into supported Chromium-family browsers, including Chrome and Vivaldi on macOS. The bridge exposes only typed Computer target commands plus bounded discovery; it does not expose Supervisor effect RPCs or create browser-specific workflow authority. Unattended Supervisor sends request highest available reasoning through the same typed Computer target; the Chromium extension first performs a read-only exact-tab content-script capability preflight (so stale pre-upgrade scripts cannot silently ignore the request), then verifies the actual provider control before prompt mutation and records the verified level in existing effect evidence. An unavailable or unverified control rejects before sending, and compatibility providers never silently claim Extra High. Direct Computer sends without a reasoning requirement preserve the user's current preference. Normal Browser sessions default to Forge-managed persistent Browser resources with native attach disabled; the macOS native browser automation bridge remains an explicit compatibility provider only. Screen unlock/frontmost requirements belong only to explicit physical-input or visible-capture capabilities that mechanically need the foreground desktop; ordinary Browser DOM delivery and Supervisor continuation do not depend on them. Ephemeral Forge-owned ChatGPT tabs are retired through the existing Computer Surface binding, not from Supervisor DONE text, URL matches, or a second tab lifecycle store. For Chrome extension targets, physical close requires the Controller's exact provider/profile/window/tab binding and Forge-created owner token attested in that Chrome browser session; a browser restart invalidates the physical attestation, and an unknown close outcome preserves the binding for explicit retry. Concurrent cleanup/release of one Surface coalesces the exact physical close through a process-local singleflight; the Computer Surface and its lease/CAS remain the only durable authority. User-opened, legacy unverified, or identity-drifted tabs are never automatically closed. The existing Supervisor task/effect projection protects pending/reconciling and applied-awaiting-receipt targets; a fully idle open conversation retains its physical attachment for a five-minute grace period, bounded to eight newest idle resources under pressure. Afterward Computer cleanup attempts the same attested retirement while the durable exact conversation remains reusable. Chrome heartbeat/observation must preserve a proven Forge-create token only while provider/profile/window/tab identity remains unchanged. Exact-target reconciliation or observation is read-only and cannot re-create a manually closed tab; only a separately authorized fresh Supervisor send may opt into creation. Live-Chrome 100-round/no-growth, schedule-near-wake and restart acceptance are still outstanding under #286; Project conversation archival remains separate under #287.
+
+Computer-owned ChatGPT delivery accepts an optional requested reasoning effort on the existing exact-target dispatch command. Unattended Workflow Supervisor prefers `xhigh`; the primary Chromium extension must select and verify the available composer level before mutation and report the **actual** verified effort (`xhigh`, `high`, or `medium`). A missing/disabled/unverified extension reasoning control fails closed. Only when the primary extension was proved unavailable **before mutation** may the existing target router select the Apple Events compatibility provider; it omits that optional effort preference, retains the exact effect and recovery mode, and never claims that `xhigh` was verified. A successful read-only exact-conversation reattachment to the compatibility provider also rebinds subsequent preparation/dispatch to that same Computer target; partial observation-only fallback with a stale sender is forbidden. When several tabs show one conversation, the extension first verifies the existing exact Computer provider binding and rejects unresolved ambiguity rather than choosing the frontmost tab. Extension heartbeats cover only attached Chromium instances and cannot certify the completeness of the cross-browser inventory; only the Native provider's full supported-browser enumeration makes that aggregated inventory complete, while the extension remains an optional metadata and exact-target supplement. The transient `providerInventoryReady` observation independently preserves prompt-delivery cadence when at least one provider's own inventory succeeds; incomplete global discovery alone does not impose exponential transport backoff on a healthy provider. A direct Apple Events request with an explicit reasoning requirement still fails closed. **Every Supervisor effect**, on either provider, sends the exact complete effect payload as plain text to a verified ChatGPT Project/conversation. Project instructions direct the model to the Forge tools; no App chip is selected or required. A legacy `@forge` prefix is removed only immediately before the exact effect marker; foreign App mentions, unrelated drafts or mismatched composers reject before Send. Transport ambiguity **after** provider submission remains `outcome_unknown` under the same Supervisor effect identity, with no cross-provider retry. This is one provider capability/transport contract, not a second Work, Scheduler, completion, or reasoning authority.
+
+Chrome Extension bootstrap target recovery uses the Controller-owned exact tab binding on every worker prepare/dispatch; its ephemeral service-worker bootstrap map is never canonical. The worker passes the target Project identity to the content script and requires a read-only per-tab capability attestation that the content script checks the Project before Send. A stale content script or mismatched Project rejects before mutation. No provider fallback may create a second tab when an Extension bootstrap binding or unknown creation outcome exists. Both Chrome and Apple Events compare the entire effect body including internal whitespace (only CRLF representation is normalized), and Mac checks the exact target URL within the final Send DOM action. These are Computer transport constraints, not additional Supervisor state or writers.
+
+Chrome extension exact-target read-only observations do not rewrite a durable Surface binding when the provider, browser instance, physical window/tab and owner token are unchanged; the observed-at timestamp alone is not a new binding or another durability requirement. A genuinely changed physical binding still uses the existing Surface lease writer.
+
+Computer Chromium read-only snapshots collect the entire page text only for explicit `includePageText` requests; ordinary exact-target observations must avoid unrelated full-page `innerText` layout reads and repeated composer discovery. Provider failure detection still excludes conversation message subtrees and checks visible provider status/error evidence, using structural exclusion before layout-dependent visibility checks.
+
 Quality is prioritized over interactive performance; performance is prioritized over durability machinery that does not materially improve ordinary coding.
 
 ## Runtime performance acceptance
 
-Work candidate JSON filters use a Work-defined, SQLite-maintained partial index initialized during Runtime database startup; Work JSON and CAS remain authority. Read paths perform no DDL. Recovery known-good is explicit release acceptance, requiring functional verification and fresh process/release-bound CPU evidence (60 seconds warmup, 5 minutes observation, mean <=5%, 10-second-window p95 <=10%, one core = 100%). The long read-only observation does not hold the exclusive Recovery mutation lock: every sample is fenced to exact Runtime/release identity, while final verification and known-good persistence reacquire the short mutation lock. Watchdog health does not grant this acceptance or trigger CPU-based recovery. Explicit rollback cannot be vetoed by an active known-good designation; stopped-owner and whole-release/backup safety checks remain mandatory. Historical functional attestations remain rollback evidence without being reclassified as performance evidence. See [design and evidence](../researches/runtime-cpu-work-candidate-recovery-acceptance.md).
+An installed Workflow Supervisor browser adapter is a derived part of the active
+whole-Runtime release. The existing Recovery transition owner reconciles it from
+the active immutable manifest before starting the sole Runtime, including
+rollback and stop-only restoration. An absent adapter remains an installation
+opt-in; isolated Candidate B must not register global Native Messaging hosts.
+Cutover reconciliation must verify the installed projection before committing
+success after interruption. Projection equality does not prove that an already
+open browser document loaded the new content script; that remains browser
+acceptance evidence. No Runtime-startup repair owner or additional readiness
+state is introduced.
+
+Recovery runaway acceptance is `runaway-cpu-v4`. Functional verification plus a fresh, process/release-bound CPU observation (10 seconds warmup, twenty 2.5-second windows, one core = 100%) still gate known-good, but runaway is decided by *sustained* consumption: a sample is rejected only when the mean exceeds the 25% ceiling or when at least half of the observed windows reach the 50% per-window ceiling. Nearest-rank p95 remains in the evidence for audit and is no longer the decision rule, because a tail-only estimator cannot separate bounded scheduled maintenance from runaway: the Canonical Runtime's release-fenced maintenance pass lasts several seconds and recurs about once per minute, so it always occupies the second-highest window of a 50-second observation (live rollbacks: mean 11-13% with p95 ~65% on a functionally healthy Runtime). The `runaway-cpu-v3` tail estimator described in the following paragraph is superseded by this rule; the same 25%/50% ceilings, the same 60-second budget and the separate Release Evaluation/Benchmark <=10% regression contract are unchanged.
+
+Work candidate JSON filters use a Work-defined, SQLite-maintained partial index initialized during Runtime database startup; Work JSON and CAS remain authority. Read paths perform no DDL. Recovery known-good is explicit release acceptance, requiring functional verification and fresh process/release-bound CPU runaway evidence: 10 seconds warmup plus twenty 2.5-second windows, with a safety ceiling of mean <=25% and p95 <=50% (one core = 100%). The `runaway-cpu-v3` tail estimator therefore treats p95 as the second-highest of twenty windows rather than the single maximum, so one transient 2.5-second burst cannot by itself become terminal runaway evidence while repeated high-tail windows still fail the unchanged ceiling. This is deliberately a catastrophic/runaway guardrail, not comparative performance acceptance: the governed Release Evaluation/Benchmark authority owns the <=10% candidate-vs-baseline CPU regression contract. A soaking ReleaseSession may consume an already-durable, exactly matching recoverable known-good attestation for the same active release instead of repeating CPU observation; it still fences exact live Runtime/release identity before terminalizing the session. Public MCP semantic acceptance is the authenticated MCP end-to-end session (initialize, initialized notification, tools/list, read-only tools/call, session close); the separate unauthenticated external MCP probe remains diagnostic and drives dedicated external/tunnel repair, but cannot alone veto full stable verification when that stronger MCP E2E succeeds. The bounded read-only observation does not hold the exclusive Recovery mutation lock: production CPU sampling runs in one short-lived supervised child of the exact immutable `forge-recovery` release, so the persistent single Recovery daemon can keep serving Gateway/watchdog work without delaying the sampler's monotonic windows. The child is read-only execution, not another Recovery owner or writer; every sample is fenced to exact Runtime/release identity, the parent fences Recovery-release and Runtime identity again after observation, and final verification plus known-good persistence reacquire the short mutation lock. Watchdog health does not grant this acceptance or trigger CPU-based recovery. Explicit rollback cannot be vetoed by an active known-good designation; stopped-owner and whole-release/backup safety checks remain mandatory. Historical functional attestations remain rollback evidence without being reclassified as performance evidence. See [design and evidence](../researches/runtime-cpu-work-candidate-recovery-acceptance.md).
+
+ReleaseSession Candidate B storage follows the same single-authority lifecycle. The ReleaseSession domain is the only durable semantic owner of normal Runtime release progression and rollback transaction semantics, and at most one non-terminal ReleaseSession may exist per Forge instance. ReleaseSession keeps wire `schemaVersion=1` so the immediately previous Recovery release can still inventory records after rollback, while `semanticEpoch=2` is the only current internal model; migration upgrades legacy epoch-1/epoch-less records once. RuntimeReleaseAuthority is a schema-v2 physical pointer/store only: active/previous immutable release identity plus the previous SQLite backup, with no ReleaseSession activation transaction state. A stateless ReleaseCoordinator always re-derives the next action from that durable phase and never creates a Work or coordinator-local state per release phase. Explicit/manual run-to-boundary calls may drain immediately executable phases within the existing fixed safety budget, but Runtime cutover itself has one caller-independent Connector quiet fence: automatic, explicit, and plugin-driven ReleaseSession progression still require zero MCP POST/stream/initialize activity plus the bounded session-idle window. To make that invariant achievable under continuous valid traffic, Recovery may arm one bounded transport-only drain marker under the existing Package Connector service root after exact Stable A/Candidate verification and immutable promotion. The marker is fenced to the exact old Connector service generation (`releaseId + installedAt + endpoint`) and Recovery process lifetime: that generation rejects new MCP POST/stream admission with retryable 503 while already-admitted responses drain; a Candidate or rollback Connector rebind changes the service generation and is therefore not blocked during strict post-switch verification. Recovery clears the marker on every cutover exit, and stale/dead-owner markers self-retire. The marker owns no release intent, semantic phase, retry policy or second readiness authority. Cutover transport safety is therefore an invariant of the existing provider boundary, not a request-id policy. Unattended release progression is narrower: the single persistent Standalone Recovery daemon hosts one serial trigger loop, and each reconciliation launches one short-lived supervised child of the exact immutable `forge-recovery` release that invokes exactly one `advanceConfiguredRuntimeReleaseStep`. The trigger runs only while a non-terminal ReleaseSession exists or, with no active session, when configured source HEAD differs from the active Runtime manifest `sourceCommit`; equal source identity is a strict no-op and unknown source identity fails closed. The child owns no durable state or release intent, and the next trigger always re-derives work from persisted ReleaseSession state after success, crash, timeout, cutover, or Runtime restart. Standalone Recovery implements the release-facing provider boundary for physical candidate preparation, Runtime activation, verification and rollback. Normal Runtime release reuses the installed Recovery release and never upgrades Recovery merely because Runtime source changed; Recovery upgrades remain an explicit independent operation when its own artifact/contract changes. Recovery CLI operations that can stop or replace the primary Runtime (including release-session advance/cutover/rollback, activation, restart, and recovery) must not be launched as children of the primary Runtime being replaced: the canonical Runtime owner PID is compared against the bounded actual OS parent chain before either CLI mutation. A matching ancestry fails closed with RECOVERY_CUTOVER_REQUIRES_INDEPENDENT_OWNER; the already-existing standalone Recovery daemon/MCP remains the execution authority and can outlive primary Runtime stop/restart. This is an execution-lifetime invariant, not a new ReleaseSession writer or a grant bypass. The Recovery process runs the health/watchdog policy in-process and owns health-driven restart/recovery only, never release intent. An interrupted `source_frozen` preparation resumes the same session when source and Stable A identity still match rather than creating another authority. A single prior ReleaseSession still in `soaking` may retain the original Stable A rollback and acceptance obligation when its autonomous continuation proof is missing; that cannot monopolize automatic release progress after canonical source HEAD changes. The existing ReleaseCoordinator reads configured source only in this exceptional single-soaking-predecessor case, preserves terminal-source no-replay, and permits one new `prepare` under Recovery's existing lock and exact predecessor/successor capacity contract. The old soaking session is terminalized only after the newer verified cutover, never merely because source advanced. The current `recovery/state/release-sessions` path is a storage location, not semantic ownership. Canonical Runtime maintenance is physical retention only: on the existing `releases` cleanup phase it may remove a path-fenced Candidate Home only when durable ReleaseSession phase proves Candidate B retired (`soaking`, `known_good`, `rolled_back`, or `failed`) and no live Candidate Runtime owner remains. Resumable phases and directories without readable ReleaseSession authority are retained and surfaced as bounded diagnostics; age alone never authorizes Candidate deletion. Ordinary repository Work completes at source-delivery acceptance and never waits for staging, cutover, soak or known-good. Release-level gates run once for the frozen ReleaseSession candidate, not once per contributing Work. No second cleanup daemon, ReleaseSession writer, runtime-switch Work state, or fallback authority is permitted.
 
 ## Controller efficiency contract
 
@@ -37,12 +110,24 @@ Work candidate JSON filters use a Work-defined, SQLite-maintained partial index
 - The first request may perform one broad parallel discovery fan-in; natural-language lexical terms are heuristic hints, not completeness obligations. Broad lexical discovery stops after sufficient distinct candidate evidence across multiple hints and reports the remaining coverage gap instead of scanning toward a quota for every guessed term; exact known-file and compiler-semantic retrieval remain strict.
 - Once credible paths or symbols are discovered, the semantic controller derives the next retrieval from returned source and prefers exact known paths, compiler-backed symbol navigation, or structural relationships over repeating the same broad lexical scan. Follow-up requests reuse in-process/session caches.
 - Exact known paths reserve retrieval budget and current raw source is authoritative.
-- Complete small files and complete matched symbols are preferred over arbitrary line windows.
-- CodeGraph is discovery/relationship evidence, not semantic-completeness authority. Stale structural evidence must be labeled and current changed files remain raw-source authoritative.
-- TypeScript Language Service navigation provides compiler-backed definition/reference/implementation lookup for TypeScript symbols through `rh_context`. Swift uses the same bounded `semantic_navigation` route with SourceKit-LSP, but only on explicit symbol requests and only when SwiftPM, BSP (`buildServer.json`), or compilation-database build settings are already available; Forge never performs an implicit build/index just to answer context. Xcode projects use `xcode-build-server` as the build-settings bridge. Because a present BSP can still return generic inferred flags instead of target settings, explicit Swift navigation verifies xcode-build-server compiler-option quality before starting SourceKit; obviously fallback options are rejected as incomplete. Manual `.compile` data produced from real `xcodebuild` output is validated locally, while automatic xcode-build-server mode uses a short cached BSP probe. SourceKit sessions are started lazily, serialized per repo/workspace, kept for a short two-minute idle TTL, and resynchronize changed open files; the first explicit Xcode semantic request has a bounded cold-start budget while warm requests retain the tighter interactive budget. Ordinary `rh_context` calls do not start either the BSP probe or SourceKit. Missing/stale/fallback build settings degrade explicitly to lexical/CodeGraph evidence rather than returning a false complete closure.
-- The default 19-tool MCP schemas are a deployment ABI because approved ChatGPT apps may retain a frozen action/input snapshot. Core quality capabilities therefore need a path through already-stable facade fields. `rh_context` supports precise `@tsnav` and `@swiftnav` directives in `query` as compatibility paths; refreshed clients may use the existing structured `semantic_navigation` field. For a newer semantic facade operation or newly required semantic field that an old `rh_work` schema cannot express, `operation=repair` plus `capability_id=semantic.v1:<bounded-payload>` is the generic transport-only compatibility envelope. The server owns an explicit per-operation allowlist and exact payload schema. The current allowlist admits `requirement_create` and `plan_create`: Requirement creation keeps `requirement_id` explicit outside the envelope, while frozen Plan creation transports only the missing bounded `obligation_dispositions`; Plan id, Requirement id, scope, source revision, steps and relation remain native stable arguments. Unknown operations/fields and conflicting native inputs fail closed, and both paths dispatch into the same canonical Requirement/Plan admission and Plan obligation-continuity authorities. Existing one-off field carrier `plan.obligations.v1` remains bounded migration debt for already deployed frozen clients, not a second Plan authority. No compatibility decoder owns semantic decisions or persistence. The generic envelope is removed once supported clients provide guaranteed schema/version negotiation rather than per-conversation frozen snapshots; until then new schema gaps must extend the allowlisted generic transport instead of minting one bespoke lifecycle/persistence path per field.
+- Complete small files and complete matched symbols are preferred over arbitrary line windows. Bounded source materialization never character-cuts a declared source range while reporting the original line bounds: oversized symbols are split into contiguous whole-line snippets, and if the file snippet budget is exhausted the final returned chunk is explicitly marked `truncated` with its actual end line. Partial source therefore degrades readiness instead of masquerading as complete code.
+- Ordinary source discovery uses bounded lexical/raw evidence by default without starting CodeGraph or requiring its index freshness. The integrated CodeGraph index and its Runtime bundle are retired; explicit symbol requests use existing language-service navigation. Stale structural evidence must be labeled and current changed files remain raw-source authoritative.
+- TypeScript Language Service navigation provides compiler-backed definition/reference/implementation lookup for TypeScript symbols through `rh_context`. Swift uses the same bounded `semantic_navigation` route with SourceKit-LSP, but only on explicit symbol requests and only when SwiftPM, BSP (`buildServer.json`), or compilation-database build settings are already available; Forge never performs an implicit build/index just to answer context. Xcode projects use `xcode-build-server` as the build-settings bridge. Because a present BSP can still return generic inferred flags instead of target settings, explicit Swift navigation verifies xcode-build-server compiler-option quality before starting SourceKit; obviously fallback options are rejected as incomplete. Manual `.compile` data produced from real `xcodebuild` output is validated locally, while automatic xcode-build-server mode uses a short cached BSP probe. SourceKit sessions are started lazily, serialized per repo/workspace, kept for a short two-minute idle TTL, and resynchronize changed open files; the first explicit Xcode semantic request has a bounded cold-start budget while warm requests retain the tighter interactive budget. Ordinary `rh_context` calls do not start either the BSP probe or SourceKit. Missing/stale/fallback build settings degrade explicitly to current lexical/raw source evidence rather than returning a false complete closure.
+- MCP tool names and input schemas are a deployed client ABI because approved ChatGPT apps may retain a frozen action/input snapshot. The current registry exposes every registered capability; historical conversations may still hold an older bounded snapshot until reconnect. Core quality capabilities therefore need a path through already-stable facade fields. `rh_context` supports precise `@tsnav` and `@swiftnav` directives in `query` as compatibility paths; refreshed clients may use the existing structured `semantic_navigation` field. For a newer semantic facade operation or newly required semantic field that an old `rh_work` schema cannot express, `operation=repair` plus `capability_id=semantic.v1:<bounded-payload>` is the generic transport-only compatibility envelope. The server owns an explicit per-operation allowlist and exact payload schema. The current allowlist admits `requirement_create` and `plan_create`: Requirement creation keeps `requirement_id` explicit outside the envelope, while frozen Plan creation transports only the missing bounded `obligation_dispositions`; Plan id, Requirement id, scope, source revision, steps and relation remain native stable arguments. Unknown operations/fields and conflicting native inputs fail closed, and both paths dispatch into the same canonical Requirement/Plan admission and Plan obligation-continuity authorities. Existing one-off field carrier `plan.obligations.v1` remains bounded migration debt for already deployed frozen clients, not a second Plan authority. No compatibility decoder owns semantic decisions or persistence. The generic envelope is removed once supported clients provide guaranteed schema/version negotiation rather than per-conversation frozen snapshots; until then new schema gaps must extend the allowlisted generic transport instead of minting one bespoke lifecycle/persistence path per field.
 - Exact lexical search remains necessary for dynamic registrations, manifests, string capability IDs, persisted aliases, and unrelated same-name implementations, but it is a discovery/fallback mechanism rather than the proof of static symbol completeness.
 
+## Cognitive Plane
+
+- Forge has one domain-independent Cognitive Plane for long-term learning and associative recall. It follows **learn early, trust gradually**, but semantic admission, abstraction and scope are model decisions: Forge must not convert repetition counts, kinds, keywords, confidence thresholds, failures or execution codes into a rule for what deserves learning or when knowledge becomes cross-project.
+- `MemoryUnit` / `MemoryEdge` / `LearningSignal` are advisory knowledge contracts, never Work/Controller/Scheduler authority. `LearningSignal.kind` is open descriptive vocabulary. A model may emit no learning or many semantic deltas; per-call item/byte limits are transport/resource envelopes and larger semantic deltas are recorded in additional batches. Forge derives provenance and persists through `CognitiveWriteAuthorityPort`; Cognition cannot terminalize Work, weaken safety or create a parallel lifecycle.
+- Canonical cognition metadata/relations/evidence share the Controller SQLite authority. Large immutable payloads may use SHA-256 content-addressed storage. Derived lexical/concept/vector/graph/usage projections are rebuildable accelerators and cannot become competing durable truths.
+- Existing `ExperienceRecord` remains a migration-compatible canonical record and is projected transiently into cognition during recall rather than durably duplicated. New generic memories use the cognition application service. When a deterministic `forge-incident-repair:*` Work closes a ControllerRound with current passed verification receipts, the same round-close learning composition records one evidence-backed `OutcomeObservation`, one durable repair `ExperienceRecord`, and one Cognitive `MemoryUnit` with exact source Work/Round provenance. This projection describes the verified repair candidate only; it is advisory and cannot change Work acceptance, mandatory checks, approval, ReleaseSession, Runtime cutover, or known-good authority.
+- Every meaningful task start/resumption uses one bounded advisory resolver: ordinary `rh_context` work, ControllerRound composition, Workflow Supervisor turns, and Codex/Claude thin-launcher prompts share the same activation semantics. Work/Requirement/Project/Workspace candidates compete in one relevance ranking; narrower scope is a modest prior, never a Workspace starvation rule. Exact concepts expose rebuildable lexical parts, so multi-cue natural language can qualify a long memory without lowering the global cue floor. Optional semantic expansion exists only when a provider is configured; Forge does not claim vector semantics otherwise. Consolidated memory and retained `derived_from` sources consume one ordinary recall slot, while conflict/supersession views remain visible. The returned `ActivationPack` is an initial working set, not semantic completeness.
+- Every Controller MCP tool shares one optional bounded cognition-settlement transport field, so ordinary repository/edit/process outcomes can learn too; the model emits it only at a meaningful successful outcome boundary, not on routine micro-steps. Forge settles it after the primary operation succeeds, derives repository/session/time and optional selected Work/Requirement provenance, validates reachable scope/evidence, and invokes the existing Cognitive writer/usage writer. A settlement defect is visible advisory metadata/warning and cannot convert an already-applied primary effect into retry authority. `rh_work learning_record` remains a compatibility surface over the same writer. This adds no Reflection/Memory lifecycle, per-tool reflection ritual, or second durable authority.
+- Consolidation may mechanically coalesce related traceable memories while retaining source provenance, but it does not author a more abstract lesson or promote scope. Project-to-Workspace generalization is explicit model-authored semantics: the model may use repeated independent evidence as justification, but Forge has no fixed corroboration count or source-category gate. Workspace writes require explicit portable intent and remain advisory; they never create policy authority.
+- `assistant_context_usage` remains canonical ControllerRound evidence. Used/rejected feedback affects retrieval applicability, not truth confidence; stale/contradicted rejection adds explainable conflict pressure without silently deleting memory. `rh_context search` exposes bounded read-only `knowledge_*` audit over reachable Project/Workspace/Work scopes, including provenance, relations, usage and activation reasons, but audit never contributes to source mutation readiness.
+- Hot/warm/cold are retrieval/retention hints, not independent stores. Machine-native encodings remain internal implementation details; MCP/ChatGPT projection is semantic typed JSON/text. See [`decisions/20260917-cognitive-memory-foundation.md`](decisions/20260917-cognitive-memory-foundation.md).
+
 ## Execution lanes
 
 ### Semantic classification authority
@@ -53,6 +138,10 @@ Execution placement, lifecycle, retry, authorization, and acceptance decisions c
 
 Machine-visible failures have a stable code plus an explicit class and retry disposition; transport projections such as HTTP status derive from that contract. Free-form messages exist for diagnostics and user presentation. A producer-specific adapter may translate a native SDK/OS error into the failure contract once, but retry policy must not be inferred from words such as `temporary`, `worker`, or `network`, and authorization must not be inferred from arbitrary prose. Ambiguous non-idempotent outcomes use an explicit reconciliation-before-retry disposition rather than generic transient retry.
 
+### Persistent service identity authority
+
+Forge core persistent service ownership is machine-enumerable in `src/runtime/platform/service-inventory.ts`. The inventory owns exact current Runtime/Connector/Recovery identities and an explicit exact retired set; platform service managers own only launchd/systemd mechanics. Standalone Recovery is one fault-domain-independent persistent service: its HTTP/MCP provider surface and watchdog policy share one process/lifecycle owner, while launchd/systemd supervises process death. Bounded read-only helper children, such as the known-good CPU sampler, may execute from the same immutable Recovery release but never become persistent service, mutation, or lifecycle authority. Historical Recovery Gateway/Watchdog service labels are retired migration identities, not current owners. Upgrade reconciliation may retire only exact entries from the retired Forge-core set and must verify service plus installed artifact absence. Broad `com.moretea.*` / `com.moretea.forge.*` prefix retirement is forbidden. Provider-owned services such as Desktop Operator and user-configured tunnel services remain outside Forge core retirement authority even when their labels share Forge naming.
+
 ### Tool Contract ABI authority
 
 The published tool contract is a transport ABI, not a second semantic authority. Current and frozen clients must enter the same canonical typed handlers. The stable `rh_work` operation registry is one ABI authority shared by MCP schema generation and server-side `SuggestedNextAction` admission, so lifecycle projection cannot invent an operation the published contract does not expose or reject an operation the schema already owns. New frozen `rh_work` compatibility travels through the versioned `semantic.v1` envelope; older ad-hoc `capability_id` prefixes are shrinking migration debt and new prefixes are rejected by the runtime architecture gate.
@@ -71,6 +160,8 @@ Repeated defects in routing, lifecycle, retry, authorization, schema compatibili
 6. Add focused behavioral regression for the old failure mode and an architecture guardrail when the defect class can recur mechanically. The regression must prove that the former heuristic no longer gains authority, not merely that the current example happens to pass.
 7. Run one representative end-to-end journey before closing the root issue family. Related issues close only after the canonical owner is in use, dominant consumers have migrated, the guardrail passes, and any tracked compatibility debt has shrunk or has an explicit remaining owner.
 
+Recurring infrastructure failures use one incident-repair authority. MCP failures and Scheduler progression/release/maintenance observations are normalized to a stable root code, recorded only as bounded evidence in the existing audit/event ledgers, and promoted after the existing recurrence threshold into one request-id-deduplicated system repair Work. Repeated observations append evidence to that Work; unrelated root codes remain separate; a terminal repair may create only the next generation for the same root. The repair Work still enters normal Work admission, approval, verification, Controller, ReleaseSession, and Runtime fencing. Event ledgers are evidence, never a second failure or Work state machine. Provider authorization, user-action waits, and outcome-unknown effects are excluded from automatic repair promotion.
+
 The runtime architecture gate maintains an AST-derived semantic-string debt ledger for authority-critical code. New human-readable string matching in machine-decision branches must not be normalized by casually extending that ledger; ledger additions are architecture exceptions requiring explicit review and a migration rationale. Ordinary repair work may only remove entries. This guardrail intentionally does not ban parsers, regexes, or string matching globally: discovery, presentation, input validation, and bounded compatibility ingress remain valid when they do not become downstream semantic authority.
 
 ### Ephemeral Direct — default
@@ -89,10 +180,15 @@ Persistent Work/Process state is reserved for actual continuity requirements: sc
 
 Remote or non-idempotent effects are explicit boundaries. Ambiguous outcomes are reported as `outcome_unknown`; Forge must not silently replay a non-idempotent remote operation.
 The low-level repository command facade classifies these operations as `durable` but does not dispatch them: it returns `not_started` with `never_auto_retry`. A typed provider action or explicitly owned Durable Workflow must perform the effect and reconcile remote state before any retry after an ambiguous result.
+Effectful plugin/provider actions follow the same continuity rule. Before provider dispatch, Forge binds the stable `request_id` to one durable Process identity; the MCP/ChatGPT stream is only an observation channel. Read-only actions and explicitly `direct_non_persistent` actions may remain direct, but every other effectful plugin action executes through the managed Process sidecar. Interactive timeout, stream interruption, MCP session replacement, or Runtime rotation must reattach to the same Process/receipt and must never reacquire the provider resource for a duplicate dispatch. `apply_mode=async` requests zero interactive wait and returns the durable Process/result reference immediately. A terminal sidecar writes the authoritative plugin receipt, after which repeating the same `request_id` deterministically reads/binds that receipt without replay. Before reserving a new managed Process request ID, plugin action application reuses the canonical Work-binding validator from the plugin store: only a `remote_effect` Work may bind a remote-write receipt; an ordinary `investigation` Work calls the plugin without `work_id`. Invalid bindings fail before consuming the date-scoped idempotency key; existing receipts still follow their original reconciliation. This introduces no second authority or provider.
 
 ## Work and Plan
 
-Work is a continuity/orchestration mechanism, not a coding-quality mechanism. File count, changed-line count, protected paths, dirty workspace state, review intent, or investigation alone must not create Work. Complex implementation quality is achieved through better repository understanding and fresh review, not heavier lifecycle state. Placement is a separate concern from Work creation: when continuity requirements already select a mutating durable Goal Work and a fresh trusted repository observation says the canonical checkout is dirty, admission must persist isolated-worktree placement before mutation so unrelated changes cannot enter that Work's ownership or later verification. Physical checkout isolation is also the Work execution boundary: a shared canonical-checkout Work and a disjoint isolated-checkout Work do not conflict merely because they share a repository id; same semantic scope and explicit overlapping resource claims remain stronger blockers, while the no-target shared mutation fallback serializes only shared-checkout writers. A bounded Direct Control mutation may still intentionally reuse a dirty current checkout; dirty state alone never promotes Direct work into Durable Work.
+Current-task semantics are a pure projection of the exact Work objective and explicit Work/Requirement/Plan lineage. Requirement and Plan identifiers may define broader Goal scope, but membership alone never pulls sibling Work into the current task, Controller mechanical fingerprint, continuation decision, or exact Work context. Repository-wide active Work remains repository inventory used only for typed ownership, conflict and release-admission observations; recency never establishes current-task authority. No current-task persistence store or second writer exists.
+
+Objective decomposition is represented only by optional `semanticParentWorkId` plus bounded `dependsOnWorkIds` on primary semantic Work. `semanticParentWorkId` is a decomposition edge and is distinct from execution-child `parentWorkId`; `dependsOnWorkIds` is explicit ordering only and is never inferred from Plan items. Both relations use the same semantic Work CAS/revision history, require existing primary Work in the same canonical Work scope, reject self/cyclic edges, and project current/history graphs on read without a graph database or projection writer. Continuation/replacement remains `predecessorWorkId`/`supersedes`/`supersededBy`, so decomposition, dependency, execution ownership and continuation are four separate meanings.
+
+Work is a continuity/orchestration mechanism, not a coding-quality mechanism. File count, changed-line count, protected paths, dirty workspace state, review intent, or investigation alone must not create Work. Complex implementation quality is achieved through better repository understanding and fresh review, not heavier lifecycle state. `work_complete` records the Controller's semantic completion decision rather than a Forge acceptance verdict, but semantic terminality is monotonic: `completed` and `cancelled` never reopen in place. If later evidence shows the same root cause remains incomplete, the model creates an explicit successor Work and preserves the prior terminal audit record. Terminal semantic state also starts reconciliation of Forge-owned execution resources by the existing `work_finalizer`; a repository completion receipt is delivery evidence, not a second cleanup authorization. The finalizer still independently proves exact OwnedResource identity, preserves dirty bytes and unique committed source, settles live process ownership, and honors explicit `retained_by_request` disposition before any physical removal; its cleanup receipt is durable progress/result evidence rather than lifecycle authority. Placement is a separate concern from Work creation. For mutating durable repository Work, omitted placement and the stable legacy/default `auto` placement are mechanical aliases for an isolated checkout with the Work start revision frozen; explicit `current` is the Controller/model choice to reuse the selected registered checkout. If an already-prepared WorkHandle has a conflicting explicit placement request, admission rejects the request before mutating WorkContract state rather than silently reusing the old checkout. Admission does not infer or rewrite topology from dirty paths, task risk, parallel relations, or lifecycle state. Physical checkout isolation remains an execution fact: a shared-checkout Work and a disjoint isolated-checkout Work do not conflict merely because they share a repository id, while concrete WorkHandle, Lease, Git identity, and overlapping resource conflicts remain authoritative at mutation time. Once a mutating Work starts, its source/base is frozen until the final delivery boundary; target integration is not an implementation-time baseline update.
 
 Plan is optional intent/coordination state. Initial likely paths are evidence, not a frozen semantic scope. The controller may discover and edit additional policy-allowed files without creating a second lifecycle solely because understanding improved. Durable semantic ownership is layered as `Requirement -> semantic scope -> stable Plan -> PlanRevision audit -> Work`: Requirement is portfolio/outcome authority, not a conflict domain; `scopeKey` identifies the bounded Plan slice; one current Plan identity owns that scope; ordinary replanning advances the same Plan through a staged durable revision; historical revision records are immutable audit evidence and never own active scope, Work, scheduling, or admission authority. `supersede` is reserved for true semantic Plan replacement, not normal iteration.
 
@@ -105,32 +201,44 @@ Engineering quality evidence is versioned Work-domain state, not a second Work/P
 
 For material high/critical mutation, Runtime composition accepts semantic precondition content and mints source-bound `ProductDoDReceipt`, `DesignDecisionContractReceipt` and `IndependentCritiqueReceipt`; raw MCP arguments never carry the trusted evidence object into Kernel. Product DoD records user outcome, completion conditions, non-regression, material performance expectations and non-goals. Design records semantic scope keys and mutation class plus ownership/single-writer, transaction, lifecycle, concurrency, persistence, failure, projection/cache, time, performance and compatibility decisions. Its complexity budget makes added writers, durable mechanisms, projection paths, global invalidations, lifecycle hooks and synchronous critical-path work explicit before mutation. File paths are discovery/policy evidence, never semantic-scope authority.
 
-Independent critique is bound to the fresh Requirement digest, current-source Context Closure, Project Contract digest, Product DoD and exact Design receipt and only an `approved` critique satisfies high/critical admission. A same-root-cause blocker always persists `return_to_design`; when the Work already has a formal Design receipt, it marks that design `revisit_required` and mutation cannot resume until a new design explicitly supersedes the prior receipt and receives an independently `approved` critique. Observe-only low/normal Work with no prior Design receipt records the blocker without fabricating an impossible supersession authority or `revisit_required` state; it remains governed by its existing risk profile. An unrelated blocker deterministically creates or reuses one parallel investigation Work, persists its exact `linkedWorkId` in the `linked_work` disposition, and does not widen the current Work semantic scope. These receipts live inside existing Work authority; they do not create another persistence writer, lease, scheduler or lifecycle.
+Independent critique is bound to the fresh Requirement digest, current-source Context Closure, Project Contract digest, Product DoD and exact Design receipt and only an `approved` critique satisfies high/critical admission. A same-root-cause blocker that invalidates an existing design persists `return_to_design`; when the Work already has a formal Design receipt, it marks that design `revisit_required` and mutation cannot resume until a new design explicitly supersedes the prior receipt and receives an independently `approved` critique. Progressive discovery inside the already selected architecture authority is instead classified explicitly as `same_root_cause_scope_extension`: it persists `extend_candidate`, keeps the exact Work/candidate, and continues through the same call without Design re-entry or sibling Work. Observe-only low/normal Work with no prior Design receipt keeps the conservative `same_root_cause` behavior unless the Controller explicitly classifies a bounded scope extension. An unrelated blocker deterministically creates or reuses one parallel investigation Work, persists its exact `linkedWorkId` in the `linked_work` disposition, and does not widen the current Work semantic scope. These receipts live inside existing Work authority; they do not create another persistence writer, lease, scheduler or lifecycle.
+
+### ControllerRound continuation and Workflow Supervisor boundary
 
-### Persistent autonomous continuation
+This section describes the durable **Requirement/Plan/Step/Work/ControllerRound execution lineage** and its boundary with the upper cross-assistant-turn Workflow Supervisor. Provider conversations, browser tabs, ControllerSession transport ids, and Schedule occurrences are delivery or trigger facts; none is allowed to become a second continuation lifecycle.
 
-A scheduled unattended workflow follows one durable **Requirement/Plan/Step/Work/ControllerRound semantic lineage**. Provider conversations, browser tabs, ControllerSession transport ids, and schedule occurrences are replaceable delivery or wake state; none of them is the durable goal identity. The authorities compose into one lifecycle:
+1. Scheduler owns only time/event/condition triggering. A Schedule occurrence contributes its exact occurrence identity and may request a ControllerRound action, but Scheduler does not persist continuation status, provider attempt state, provider receipts, semantic wait state, or replay authority. The retired `ScheduledContinuationDispatch` / `scheduler_continuation_dispatch` state machine must not be recreated.
+2. `ControllerRound` is the sole lower-layer continuation authority. It owns semantic disposition, exact occurrence binding, semantic fingerprint suppression, provider effect identity, dispatch start/attempt, receipt, `provider_dispatch_outcome_unknown`, `wait_for_user`, recovery fencing, and the currently open semantic round.
+3. Immediate lower-layer continuation does not require a Schedule. `continue_immediately` may close/release the current round and prepare the successor ControllerRound directly. A Schedule is used only when a real time/event/condition trigger is needed.
+4. `wait` keeps the lower semantic lane quiescent. The ControllerRound semantic fingerprint is derived from stable Requirement/Work/Handoff facts, excluding persistence timestamps and record ordering. An unchanged occurrence returns `semantic_wait` before provider dispatch; a meaningful semantic change may admit one successor round.
+5. `ControllerHost` is the provider-neutral delivery port. Provider/browser adapters may navigate, submit, observe, and reconcile external effects, but they never own Work or ControllerRound semantics. Before any non-idempotent provider submit, ControllerRound atomically records the provider effect id and dispatch start/attempt. A confirmed result records the receipt on that same round. An ambiguous submit records `provider_dispatch_outcome_unknown` and forbids blind replay.
+6. Any continuation ingress operating from a retained ControllerSession first rebinds that session to the current in-process Runtime write claim when the Runtime instance has rotated; this changes only the mechanical controller epoch and preserves the same durable Work authority. A launched Controller then claims the exact Work/ControllerRound and reconstructs bounded current Requirement/Plan/Step/Work/Handoff/source/runtime evidence. For relay-bound claims, relay claimability and authoritative ControllerSession ownership are revalidated under the canonical relay→session lock order, then committed through one control-plane SQLite transaction; a direct Work relay acknowledgement commits in that same transaction, while an inherited Requirement-scope relay is fenced but never rewritten for a sibling Work. Chat history and MCP/provider sessions are transport context, not durable semantic truth.
+7. Before a Controller round ends, the Controller records exactly one disposition: `continue_immediately`, `wait`, `wait_for_user` with an active Handoff, or `goal_complete`. `goal_complete` closes the lower Controller lane only; outer Goal completion still requires Workflow Supervisor `DONE` validation against canonical Requirement evidence.
+8. Once a Requirement-backed Work has an exact ChatGPT conversation binding, the Workflow Supervisor owns the next **outer assistant-turn submit** for that Goal. Scheduler, stalled-round maintenance, and `continue_immediately` may prepare or preserve the lower ControllerRound, but they must not send another outer ChatGPT message. Autonomous liveness must prepare the canonical lower ControllerRound before Supervisor enrollment; if the Requirement scope still points at a failed/cancelled, ownerless prior Work, canonical ControllerRound terminal reconciliation retires that stale relay before the current Work round is prepared. No Requirement-membership-only authority inheritance is permitted. The next assistant turn may claim the prepared `dispatching` ControllerRound through normal Controller authority.
+9. Supervisor enrollment is idempotent and Requirement/Goal-scoped, not per-Work. Task identity is repository-namespaced; successor Works in the same Requirement inherit the exact conversation binding. Lower layers derive the Supervisor boundary from canonical Work + conversation facts instead of copying an `owned` status into Scheduler or ControllerRound.
+10. Workflow Supervisor is co-hosted inside the existing Canonical Forge Runtime process. It owns a separate `supervisor.sqlite` and Unix socket under the exact configured Controller Home and is the only opener/writer of that Supervisor database. This preserves an independent authority namespace without adding a second launchd/systemd service or process lifecycle.
 
-1. A Schedule occurrence mechanically selects an already-bound active Work and requests `external_controller_wake`; it never invents semantic work. The occurrence fences replay of that wake, not the goal itself.
-2. Scheduler resolves the Work-scoped durable `ControllerBinding` (interaction target) and the currently retained Controller delivery session. A changed MCP/provider session updates delivery binding without changing Work, binding, Requirement, Plan, or ControllerRound identity.
-3. The provider host may reuse a healthy conversation/browser session, or create/reattach a successor delivery session when the prior one is unavailable. Conversation and browser identities are adapter state only. Dispatch evidence proves a provider effect, not a Controller claim or semantic completion.
-4. The launched Controller claims the exact Work and independently reconstructs bounded current Requirement/Plan/Step/Work/Schedule/Handoff/source/runtime evidence before deciding what to do. Chat history is useful transport context but is never the durable source of truth.
-5. The Controller performs semantic reasoning while Forge performs deterministic context, edit, process, provider, verification, and finalize operations. Forge may automatically execute explicitly requested checks or lifecycle mechanics, but it never infers that acceptance is satisfied.
-6. Before a Controller round ends, the Controller records exactly one semantic disposition: `continue_immediately`, `wait`, `wait_for_user` with an active Handoff, or `goal_complete`. ControllerRound authority and claim generation fence this transition independently of transport replacement.
-7. Round-owned delivery resources are cleaned only after the round reaches its settlement boundary. User-owned browser tabs are preserved; Forge-owned ephemeral tabs or provider sessions may be replaced without losing durable continuation authority.
-8. `wait` keeps the semantic goal resumable but quiescent. Scheduler computes the current ControllerRound semantic fingerprint from stable Requirement revision/state, Work lifecycle/evidence facts, and active Handoff semantics; persistence timestamps and record ordering are excluded. Interval/manual wakes with an unchanged fingerprint are recorded as `semantic_wait` and stop before provider dispatch. One meaningful semantic change may admit one successor round for the exact active Work. When the previous Work is terminal, only semantic Controller admission may create a successor Work; Scheduler never invents one. The successor records `predecessorWorkId` and preserves Requirement/Plan lineage. One already-approved dependency-satisfied next Plan step may be mechanically resolved, but multiple executable successors require an explicit Controller choice. `goal_complete` terminates the semantic goal and its continuation lane without creating another Work.
+### Canonical Work-bound schedules and Gmail owner notifications
 
-`ControllerHost` is the provider-neutral delivery port. ChatGPT Browser and Windows/WSL bridge implementations live in `adapters/chatgpt` behind one delivery contract; they own provider navigation/mutation/confirmation but never Work or ControllerRound semantics. Provider-specific prompt rendering may treat instructions explicitly scoped to a different Controller host/runtime as non-gating for the current host, but it must preserve the underlying repository engineering, acceptance, safety, permission, and authority constraints. The owning `ControllerRound` is the sole durable provider-dispatch receipt authority. Schedule occurrences may project the same dispatch receipt id for replay/debug evidence, while Browser/tab settlement records are resource-cleanup evidence only and cannot overrule the ControllerRound dispatch outcome.
+The only canonical Work-bound scheduled continuation operation is `controller_progression`. New Work continuation schedules and activation migrations write this operation; `external_controller_wake` remains compatibility for already persisted legacy records. Scheduler dispatch recognizes both but requires an exact `ControllerBinding` for the canonical operation and enters the existing `reconcileControllerProgression` / Workflow Supervisor boundary; the Schedule does not create a second continuation dispatcher. Canonical `controller_progression` schedules remain enabled after Supervisor enrollment; the legacy external-wake route retains its historical pause-on-enrollment behavior. Both operation identities share the same bounded failure/cooldown policy, and Console presents both as Work continuation. Resuming a legacy Schedule migrates it to `controller_progression` and binds the exact Supervisor task after migration; binding failure pauses the Schedule rather than leaving an enabled unbound lane. On each subsequent occurrence, Controller composition checks the exact Supervisor task's durable waiting state before lower ControllerRound preparation, so a lower-layer `semantic_wait` cannot suppress a valid scheduled outer-turn wake.
 
-A provider authentication, consent, or permission blocker is `wait_for_user`, not rejection. The ChatGPT adapter creates one bounded Handoff for the exact Work/round; resolving that Handoff wakes a fresh repository-event occurrence. The prior occurrence remains non-replayable. Conversation/session replacement during that recovery is normal delivery-state turnover and must preserve the same semantic Work/relay lineage.
+Scheduled Gmail archive and owner-notification actions use the dedicated `scheduled-gmail-automation` capability for the configured, live-profile-verified Gmail mailbox. `authorize_scheduled_gmail_automation` is the only grant creator and requires explicit authorization; it sends no email and grants at most 90 days. Archive accepts only one `message_id` and does not delete or reply; notification accepts subject/body only and fixes the recipient. The plugin store rejects those actions without an existing exact-target reusable grant. Supervisor notifications use stable request ids derived from blocker identity and the existing plugin action receipt ledger; exhausted alerts key on task, exact effect and exhaustion state, not an activity timestamp, while activity reconciliation reads the existing projection by exact ID even after it falls outside a bounded activity listing; missing reusable grants and exact provider-auth failures are represented as durable `UserRequest` records with the failing action/error code. A Gmail notification receipt with `effectOutcome=outcome_unknown` is read from the original request index before any fresh grant/send attempt; the exact immutable receipt is surfaced once through the existing direct-activity projection as an unresolved delivery outcome, without rekeying, replay, or a second Work/state authority. Failed sends are not silently retried or routed through another provider. Resend is not a second provider for this path.
 
-Machine-observable continuation health is derived from existing durable records rather than a new authority database: Requirement/Plan/Step, Schedule occurrence, WorkContract, Work-scoped ControllerBinding, ControllerSession, ControllerRound relay/disposition, provider dispatch receipt, verification/finalization receipts, and delivery cleanup evidence. Health reporting must distinguish `wake requested`, `provider dispatch attempted/confirmed/outcome_unknown`, `Controller claimed`, `semantic disposition recorded`, `lease released`, `verification/finalize outcome`, `delivery cleanup`, and `waiting/next eligible`; none of those states may be substituted for another.
+The recurring Supervisor lifecycle is durable in the existing effect/completion journal: a Work-bound task is bound one-way to its exact Schedule ID; a scheduled task may commit `WAIT` only when that binding exists; `WAIT` creates no immediate successor and is projected as `waiting`; the next Scheduler occurrence supplies its exact Schedule ID and occurrence ID to reserve one continuation effect from that WAIT completion. The unique effect origin and source-completion constraint make a repeated occurrence idempotent and prevent a second occurrence from consuming the same WAIT receipt. Completion chronology follows the durable `assistant_completion` event sequence when committed timestamps match, preserving causal order for rapid successive receipts. Browser polling omits waiting tasks until the Scheduler creates the next effect. A scheduled task's stale `DONE` or `NEEDS_USER` response is rejected through the existing correction path so it cannot silently terminate the daily loop; a validated human blocker remains durable, but the recurring task records it and returns to `WAIT`. The focused daily Gmail acceptance test creates a `0 8 * * *` cron Schedule and evaluates consecutive Asia/Shanghai timer-origin windows (`2026-10-17 08:00` and `2026-10-18 08:00`), plus due-time checks on both sides of a month boundary, through the real Scheduler adapter under a deterministic clock; after each `WAIT`, the same Supervisor task receives one new continuation effect and the Schedule remains enabled. This verifies cron-window and repeat-occurrence composition without claiming that the live wall-clock timer has been activated. Creating the source Schedule does not itself activate the Canonical Runtime; live activation and a post-activation second-occurrence acceptance test remain separate delivery requirements.
 
-If a non-idempotent provider submit may have committed but cannot be confirmed, the owning ControllerRound persists `provider_dispatch_outcome_unknown` and exits all automatic replay/re-arm paths. Known pre-submit/provider failures remain ordinary failures and may follow bounded retry policy; an ambiguous submit requires explicit reconciliation evidence before any replacement dispatch is admitted.
+A provider authentication, consent, capability-grant, or permission blocker is `wait_for_user`, not rejection. Resolving the exact Handoff creates new durable evidence that may re-admit continuation; conversation/session replacement during recovery is normal delivery-state turnover and must preserve the same Requirement/Work/ControllerRound lineage. A known non-ambiguous provider failure is retried within the same ControllerRound authority, occurrence and failure budget; it never creates a successor semantic round merely to retry delivery. Scheduler may mechanically reconstruct a missing Work-scoped ControllerBinding from the retained ControllerSession and existing conversation/predecessor projection, but it may not mint browser authorization or clear an outcome-unknown fence.
 
-Transient Runtime, connector, or browser-provider unavailability may delay a wake through bounded backoff/re-arm, but must not silently terminalize the Work or permanently freeze a healthy persistent schedule. Repeated-state fencing remains a protection against semantic self-spin; recovery requires new durable evidence or a valid new Controller claim rather than blind retries.
+Machine-observable continuation health is derived from canonical Requirement/Plan/Step, optional Schedule occurrence, semantic WorkContract, provider-effect/receipt facts, Supervisor task/effect journal, and real repository/process safety evidence. Persistent scheduled Work is ordinary pending intent, not a stuck Work or Runtime blocker. Health reporting distinguishes trigger, provider dispatch start/confirmed/outcome-unknown, outer-turn effect reservation/application, real execution outcome, and genuine waiting state; none may be substituted for another.
 
-Explicit **Scale** is the opt-in coordination form of this existing model, not a separate runtime tier. `rh_work mode=scale` requires a bound approved Plan step, routes through durable bounded Work with an isolated checkout, and lets the semantic controller decompose independent deliverables across multiple Plan steps. Independent Scale Work may proceed concurrently when existing Process/resource claims permit; conflicting claims still serialize or reject through the same Lease authority. Generic `requires_parallelism` alone does not imply Scale, Plan, Work, or isolation. Scale does not introduce an agent swarm, second scheduler, or second project lifecycle.
+Transient Runtime, connector, browser-provider, or Supervisor-adapter unavailability may delay progress, but it does not authorize a lower layer to seize outer-turn ownership. Once the exact conversation boundary exists, failure to enroll or reach Supervisor remains quiescent/retriable infrastructure state rather than a fallback permission for Scheduler or maintenance to double-send.
+
+Standalone Workflow Supervisor tasks may intentionally remain unbound under `model_semantic_completion`. When a task names `work_id` or `requirement_id`, DONE uses the same committed semantic proof as `forge_work_done` / `forge_requirement_done`; missing, ambiguous, or nonterminal bindings reject DONE and produce a correction effect. `repo_id` and objective/receipt text alone never create Work or Requirement authority. An existing nonterminal unbound task may acquire one explicit Work or Requirement binding through the existing `revise` operation only with the canonical completion-contract SHA-256 from `get` and the task objective CAS. The binding is one-way, recorded in the same Supervisor event ledger, and preserves task/conversation/effect identity; it never infers a target from objective text. Bootstrap upgrade may not erase an existing binding.
+
+ReleaseSession known-good promotion requires a bounded Supervisor acceptance task to prove `CONTINUE → CONTINUE → DONE` on the exact active release. The existing effect/completion ledger must show one dispatch and one applied receipt for each causal source effect, the third effect must be the successor of the second completion, the accepted `terminal_done` receipt must follow the third `assistant_completion`, and at least two distinct Runtime incarnations must appear. Long-running production Work may remain open; receipts before the active-release authority boundary never qualify.
+
+A dispatch-owner proof that Send was not clicked refunds that exact generation in the existing effect ledger and records the failure against the existing bounded per-release preflight gate. `provider_recovery_stop_pending` on a recovery effect is a live-turn observation and consumes neither budget; outcome-unknown mutations remain reconciliation-only and are never refunded or replayed.
+
+**Model owns reasoning and engineering policy. Forge owns capabilities, durable facts, execution mechanics and receipts.** Forge carries no route/mode vocabulary that selects Direct Control, durable Work, handoff, a worker/provider, verification, review, or completion on the model's behalf. Invoking `rh_work` is itself the explicit decision to use durable Work; `work_kind` is the explicit declaration of the technical evidence shape. Parallel delivery across independent Plan steps is expressed through explicit Work/Plan lineage plus existing Process/resource claims, which serialize or reject conflicts through the same Lease authority; no Forge-side task-size, complexity, or parallelism heuristic promotes a task into a lifecycle tier. There is no separate runtime tier, agent swarm, second scheduler, or second project lifecycle.
 
 ## State ownership
 
@@ -138,16 +246,29 @@ Explicit **Scale** is the opt-in coordination form of this existing model, not a
 - Edit Session owns one deterministic local patch transaction and reviewable diff evidence.
 - Lightweight process handles own only current-runtime attach state.
 - Validation results own check evidence for the exact inputs they verified.
-- Work owns durable continuity only when continuity is actually required.
+- Requirement, Plan, and optional Work are the only cross-domain model-authored semantic working-context records. Each has one stable identity and monotonic semantic revision with expected-revision CAS; append-only semantic revision records are history evidence, not second mutable authorities. Plan source/Requirement basis revisions are provenance and advisory staleness only, never execution gates. Legacy PlanContract lifecycle/steps remain migration execution data and cannot rewrite `semanticContext` once it exists.
+- Work owns an independently resumable semantic objective only when durable continuity is useful. Its semantic state is `open|completed|cancelled` and is independent from mechanical running/blocked/verification/review/delivery/cleanup/provider/recovery state. Model-selected Work result refs stay separate from mechanical completion/check receipts. Pre-semantic legacy Work may infer its initial semantic state once; new Work materializes semantic state at creation.
+- When creating a Work with explicit Plan/Requirement identity, Forge resolves their existing current semantic heads and records the adopted `planRevision`/`requirementRevision` in Work's own CAS/history; an explicitly chosen existing historical revision is also valid. A selected Plan may supply its already-authored Requirement identity when Work has no stronger explicit/predecessor binding, but Requirement membership never guesses a Plan or successor. Mismatching Plan/Requirement links and nonexistent revisions fail before Work creation or revision. Later upstream head changes are not silently adopted during manual or autonomous continuation: `rh_work get` projects the current head alongside Work's adopted basis and, for detail reads, both semantic snapshots when available. A model/user explicitly changes either basis through `rh_work revise` and Work `expected_revision` CAS, preserving the old basis in immutable Work revision history; terminal Work cannot switch its basis in place. Version drift is advisory context for model judgment, not a verification, execution or acceptance gate.
+- ResumeContext is assembled on demand from current Requirement/Plan/Work semantic views plus fresh source/resource facts, unresolved human requests, active durable handles, and pertinent receipts; it is not persisted as another aggregate. ControllerRound currently remains a lower-layer continuation/effect fence during migration, but its claim/lease mechanics do not own Requirement/Plan/Work semantic identity or revision authority.
+- Scheduler owns trigger/time/event/condition occurrence authority only; it does not own continuation lifecycle or provider-dispatch truth.
+- Workflow Supervisor owns committed assistant-turn and Goal-level `CONTINUE`/validated `DONE`/validated `NEEDS_USER` plus next outer assistant-turn startup. Its durable browser task identity is conversation-stable so one ChatGPT Project conversation survives explicit predecessor/successor Work turnover and Requirement takeover. Work-derived task ids are bootstrap reservation identities only; after exact conversation binding, the registered conversation task is canonical while the active semantic scope remains the exact Requirement/Work reported and validated for the current turn. Discovery observations may be durable, but only `WorkflowSupervisorControlPlane -> WorkflowSupervisorStore` may persist them; server/native-browser transports only normalize and submit typed observations. The dedicated database/socket remain co-hosted by the Canonical Runtime process under Controller Home. If an exact recovery preflight returns `provider_recovery_stop_pending`, the provider turn is still active: retain the same reserved recovery effect, and do not record a generic preparation failure, consume a dispatch generation, or spend the preflight-failure budget.
 - Durable Process owns persisted command/check lifecycle only when the selected lane is durable.
-- Runtime release/recovery state owns Forge service availability and immutable release activation; it is separate from ordinary command recovery. The canonical OS service executes an atomic byte-identical mirror of the selected signed Runtime entrypoint from the fixed physical `runtime/service/active-forge-runtime` path, while release resources and identity remain manifest-bound. The stable physical path prevents macOS TCC from treating every immutable release directory as a new responsible-process principal.
+- MCP transport owns only bounded request/session delivery, not semantic execution authority. Modern and legacy POSTs participate in the same active-request admission/health accounting. During Canonical Runtime shutdown or release cutover, the listener stops new admission first and already-admitted requests receive one bounded drain window; any still-unsettled request must be surfaced as explicit `outcome_unknown` / `reconcile` before session/socket teardown. A cutover ambiguity never authorizes blind replay: only an operation whose canonical idempotency authority already proves replay-safe may reconnect and replay. Transport completion/health therefore cannot infer Work, ControllerRound, or provider-effect completion, and a newly healthy Runtime does not retroactively prove an interrupted request completed.
+- Workflow Supervisor retry or provider-resume exhaustion remains a derived projection of the existing task/effect journal, not a new task state. Exhaustion is projected through Direct Activity so operators can see that automatic mutation has stopped; clearing the canonical stall closes that same projection. Exhaustion never suppresses read-only observation of the latest applied leaf: late provider activity continues to refresh its digest, but the exhausted recovery budget cannot reserve another automatic mutation. A late causal receipt may still settle that same applied effect and create its canonical successor. Outcome-unknown effects remain reconcile-only and are never replayed.
+- Runtime release/recovery state owns Forge service availability and immutable release activation; it is separate from ordinary command recovery. The canonical OS service executes an atomic byte-identical mirror of the selected signed Runtime launcher from the fixed physical `runtime/service/active-forge-runtime` path, while release resources and identity remain manifest-bound. That compiled launcher is deliberately narrow: it validates the manifest-attested Runtime bundle and release-owned Bun interpreter, supervises exactly one interpreter child, forwards lifecycle and diagnostic signals, and mirrors the child terminal outcome; it never loads the long-lived Runtime bundle into its own compiled JSC VM. The stable physical launcher path remains the macOS TCC responsible-process boundary for its Runtime descendants across releases. Heavy TypeScript compiler/LanguageService/AST work is not part of the canonical Runtime residency boundary: semantic navigation and TypeScript/JavaScript declaration indexing execute in the manifest-attested short-lived `forge-typescript-navigation` sidecar, preserve the caller's MCP read policy, and return only bounded plain-data results. The parent Runtime may cache those plain declaration ranges by content identity, but it must not retain TypeScript compiler modules, `LanguageService`, `Program`, `SourceFile`, or other compiler-owned object graphs across requests. The same residency rule applies to allocator-heavy Context Plane retrieval: `rh_context` and compatibility `controller_context` execute Context Pack search, source materialization, and bounded source-relationship fan-in inside the manifest-attested short-lived `forge-context-pack` sidecar, with the exact serialized MCP read policy and repository/session identity. The canonical Runtime remains the request/closure authority and may combine the returned bounded plain-data projection with semantic/readiness evidence, but it must not execute the Context Pack implementation in-process or preserve its transient JSC allocator lifetime. Compiler-intensive verification gates that measure TypeScript latency or run the TypeScript compiler share the existing repository `heavy-check` serialization fence, so acceptance latency is measured without same-repository compiler/JSC contention; this is scheduling metadata only and does not create a second execution authority.
 - Independent Windows/WSL host rescue is an emergency availability boundary outside both the source checkout and Controller Home. It owns one configuration/lock root and may start or restart only the exact canonical Runtime, loopback-only Secure-Tunnel Connector, its own WSL watchdog unit, and one configured OpenAI Secure Tunnel alias. That connector runs without local MCP auth because OpenAI Secure Tunnel is the external authorization boundary; it must never be reused as a public ingress. The rescue boundary never owns a Runtime release, Controller database, schedule, work execution, secret value, compatibility fallback, or arbitrary shell RPC. Windows is a cold-start client only; the WSL rescue lock serializes every rescue mutation.
 - Historical Issue/Task/Local Job and compatibility projections must not become second mutable authorities.
-- Work lifecycle policy is separated from persistence: `work-state-machine.ts` owns legal phase/dispatch/evidence/completion transitions, while `work-contract-store.ts` owns locked persistence and applies that policy. Work completion projection is centralized in `work-completion-authority.ts`, and Work verification execution/evidence is centralized in `work-verification-service.ts`. Transports may submit requests and encode results but must not reimplement these rules.
-- Work delivery/finalization is also an application service: `work-finalization-service.ts` owns the commit/merge/cleanup/receipt transaction and `work-execution-support.ts` owns shared exact identity/cleanup primitives. MCP `execution-tools.ts` and `rh_work` compatibility glue may prepare arguments or reconcile legacy handles, but they must enter that same finalization authority rather than perform Git delivery themselves.
+- Cognitive Plane owns advisory learned memory inside the existing Controller SQLite authority. Normal repository/Work admission establishes the semantic Project/Workspace binding when portable identity is available: an authored `.forge/project-engineering.json` `projectId` is preferred, canonical Git remote supplies a stable source fingerprint and only supplies the Project id when no authored id exists, and ProjectPlacement remains ForgeInstance-local. Repository registration alone never creates semantic Project authority. Existing Project identity/workspace is preserved, while contract/remote aliases or repository-placement conflicts block instead of silently rebinding. Learning scope is authored by the model: Project is the default home for project-specific observations; Workspace is valid only when the model explicitly chooses `workspace` plus portable intent for a genuinely cross-project abstraction. Forge does not auto-promote from repetition, category, score or execution outcome and does not auto-materialize Requirement candidates from learned patterns. Cognitive memory cannot mutate Project contracts, lifecycle, authorization, acceptance or verification authority; any durable product/architecture change still enters the normal Requirement/Plan/Work path explicitly.
+- Work lifecycle is a semantic CAS record: `open`, `completed`, or `cancelled`. `work-contract-store.ts` owns locked persistence and one-time legacy normalization; `work_complete` never admits or blocks Git, verification, review, or delivery. Repository execution and recovery own their own real safety conditions. Transports may submit requests and encode results but must not reimplement these rules.
+- Work delivery/finalization is also an application service: `work-finalization-service.ts` owns the commit/merge/cleanup/receipt transaction and `work-execution-support.ts` owns shared exact identity/cleanup primitives. MCP `execution-tools.ts` and `rh_work` compatibility glue may prepare arguments or reconcile legacy handles, but they must enter that same finalization authority rather than perform Git delivery themselves. Finalizer-owned validation may use one bounded Process attach window to settle freshly launched short checks inside the same delivery transaction; the budget is bounded and shared across that validation call, never becomes polling/re-execution authority, and a still-running check remains an explicit Process dependency. Finalization never derives cleanup authority from `skipped` stage projections: `cleanup=false` is represented by the durable terminal resource disposition, and a later cleanup request may re-arm retained managed resources only from that canonical provenance. Implementation-review authority is bound to the exact Work candidate rather than a moving target-branch ancestor. If the target advances after review, delivery may preserve review authority only when the integrated revision proves identical Work content, identical changed-path identity, unchanged architecture evidence, and exact transferable verification authority; otherwise delivery returns to a fresh exact review without broadening the original Work scope.
 - Work preparation/adoption is an application service as well: `work-preparation-service.ts` owns managed-workspace selection, WorkContract admission/reuse, exact successor-HEAD adoption and Controller ownership binding. MCP `execution-tools.ts` only decodes `work_prepare` / repository-bind requests and delegates; it must not recreate workspace admission or WorkHandle/WorkContract preparation transitions.
+
+**Identity-preserving checkout relocation** uses the same `work_prepare` writer with `relocate_to_new_worktree=true`, an existing `work_id`, and exact `expected_previous_head`, `adopt_candidate_head`, and matching `base_ref`. It applies only to an open, unfinalized `prepared`/`editing` WorkHandle. The replacement is a *new* Forge-managed checkout with the same Work/Requirement/Plan identity; a pre-existing checkout claimed by another Work is never adopted. The old checkout and all of its staged, unstaged, and untracked bytes stay untouched; candidate ancestry, dirty-path disjointness, live process ownership, and exact target HEAD are checked before handoff. The Kernel WorkContract writer updates portable execution placement and the execution WorkHandle through one SQLite CAS transaction; no extra lifecycle state or authority is introduced. Physical worktree preparation is idempotent by deterministic Work+candidate key and precedes the database commit, so a crash may leave a reusable orphan workspace but never half-committed Work placement. Validation evidence is invalidated after relocation and must be proven afresh at the new checkout. Terminal cleanup retains its normal owned-resource proof.
+
 - Work command execution and validation live in `work-operation-service.ts`. Both MCP Gateway and Durable Worker call this application service directly; Workers must never dynamic-import MCP transport to obtain Work semantics. The architecture gate also forbids any `runtime/control-plane` source from depending back on `runtime/gateway`.
-- Production Browser session persistence is Controller-home SQLite `BrowserSessionAuthority`. Compatibility JSON may be imported or used only when no Controller authority is available; handoff sidecars return interaction results and never write BrowserSession state directly.
+- `rh_work` remains a thin semantic-context and transport compatibility boundary. Controller identity, claim/disposition/release, and provider orchestration are internal recovery mechanics delegated to `work-controller-operations.ts`; ordinary model-facing operations never require their authority fields. Requirement and Plan APIs persist optional semantic context only: Plan approval, acceptance, dependencies, and steps do not select or authorize Work execution. Frozen-client compatibility decoding stays at the outer `work-adapter.ts` boundary and enters the same canonical Requirement/Plan/Work primitives without restoring lifecycle gates.
+- Direct Work ownership is durable across replaceable MCP request/transport and canonical Runtime bindings. A modern sessionless request may mechanically rebind an exact direct Work only when controller id/type, authenticated principal, exact Work identity, and the positively current canonical Runtime all still match, no ControllerRound relay owns the round, and the caller did not present a conflicting opaque capability. This rebind preserves the existing Work-bound capability digest; a Runtime epoch change advances the claim-generation fence. Relay-bound ControllerRounds, cross-principal/controller recovery, stale Runtime instances, and explicitly wrong capabilities remain hard-fenced and require their existing exact authority/recovery contracts.
+- Production Browser session identity is owned only by Controller-home SQLite `ComputerSurfaceTarget` authority. Legacy Browser session JSON is import-only migration input and is never a steady-state fallback when Controller execution context is absent; handoff sidecars return interaction results and never write Browser session state directly.
 
 ## Kernel V2 module and migration contract
 
@@ -165,7 +286,7 @@ packages/plugin-runtime/* --> neutral plugin/provider contracts
 ```
 
 - `packages/kernel/<domain>` owns durable domain semantics such as Work, Controller, Scheduler, Resources, Identity, and Execution. Each domain exposes one intentional public API; sibling modules do not deep-import its infrastructure or persistence internals.
-- Kernel Identity defines portable `ScopeRef` separately from node-local `ExecutionPlacement`. Requirement/Plan/Work identity may survive repository registration, checkout, host, or ForgeInstance changes; `repoId`/`checkoutId` are migration-era placement fields and must not define semantic Work identity. New Work records persist both forms, while legacy Work records are deterministically projected without deriving semantic scope from a local repository id.
+- Kernel Identity defines portable `ScopeRef` separately from node-local `ExecutionPlacement`. Requirement/Plan/Work identity may survive repository registration, checkout, host, or ForgeInstance changes; `repoId`/`checkoutId` are migration-era placement fields and must not define semantic Work identity. New Work records persist both forms, while legacy Work records are deterministically projected without deriving semantic scope from a local repository id. Repository mutation binds a concrete checkout through WorkHandle/resource fences at execution time; when a Thin semantic Work has no legacy checkout placement, Forge uses the actual repository target for that mutation and does not write the mechanical checkout back into semantic Work state.
 - `ExecutionPlacement.forgeInstanceId` is the canonical node target for Work execution. Repository admission and managed-worktree materialization preserve it alongside repository/checkout placement. ChatGPT continuation may select Browser vs WSL bridge only after the target Forge instance matches the currently installed Forge identity; a mismatch is a typed placement blocker and never falls back to the dispatcher host. Cross-instance selection belongs to the ChatGPT Connector boundary, not a second scheduler or provider-session identity.
 - ChatGPT MCP connector discovery names are instance-derived (`forge-<stable-instance-token>`) by default. The old shared `forge` name is migration-only; endpoint/tunnel/session rotation must not change the semantic `forgeInstanceId`, while rerunning setup migrates legacy shared connector names without changing the instance identity.
 - Syncable semantic records use bounded revision/provenance metadata with optimistic-concurrency preconditions. The current Controller SQLite revision/audit mechanism is the local persistence implementation; SQLite files, leases, sessions, and runtime ownership are not portable semantic state.
@@ -201,16 +322,19 @@ Source-line-count limits are review heuristics, not architecture truth, and must
 
 Within one migration slice, gather facts in batches, decide ownership once, implement a coherent patch, then review the whole slice for authority/dependency drift before running focused checks. Repeated full-suite validation after each small move is discouraged because it slows structural work without increasing semantic confidence. Milestone/candidate boundaries receive broader cross-module review, multi-review where useful, and whole-candidate validation. Runtime baseline activation is deliberately later than source integration: a locally passing partial slice does not become the active baseline until the integrated candidate satisfies the Kernel V2 architecture contract.
 
+Validation scheduling is derived from each check's concrete resource effects, not from a blanket assumption that every analysis gate writes the workspace or shared build cache. Proven source-read-only/no-emit checks declare reads (plus only the Git/temp/host resources they actually use) so resource-compatible gates may share one validation wave; missing or unknown effect metadata remains conservative. This projection never weakens the underlying lease conflict rules or creates a second scheduling authority.
+
 ## Runtime and MCP boundary
 
 - Canonical Runtime is activated as one immutable whole release with a previous release retained for rollback.
-- A compiled `standalone-binary` release has a closed manifest-owned execution surface: Process Runner, Check Runner, Scheduler Worker, and periodic cleanup are immutable executable components with artifact identities and release canaries. Scheduler/cleanup source entrypoints remain a development/source-backed execution mechanism only; compiled Runtime must never fall back to checkout paths or Bun virtual `import.meta.url` paths.
+- A compiled `standalone-binary` release has a closed manifest-owned execution surface: the long-lived Runtime bundle, its exact release-owned Bun interpreter, Process Runner, Check Runner, Scheduler Worker, and periodic cleanup are immutable artifacts with identities and release canaries. The signed compiled `forge-runtime` entrypoint is a supervision/identity boundary, not the long-lived JS VM. Runtime execution never resolves Bun from Homebrew, `~/.bun`, PATH, an ambient checkout, or Bun virtual `import.meta.url`; scheduler/cleanup source entrypoints remain development/source-backed mechanisms only. The single release-canary authority executes each manifest-attested entrypoint according to its artifact contract: standalone executables and non-Bun shebangs run directly, Bun shebang/source scripts use the explicitly resolved Bun runtime, and package Process Runner/Check Runner wrappers delegate the canary to their attested child rather than short-circuiting it. Every publication path runs that canary before known-good release publication.
+- Canonical Scheduler idle execution is event/deadline driven, not a generic control-plane poll loop. Execution-job/lease/policy mutations and terminal Check Process persistence advance the existing `wake-signal.json` notification revision and wake immediately; lifecycle truth remains in the existing Job, Process, and Work stores, and sibling scheduler health-state writes are not wake events. With no active execution, the loop does not run a full control-plane tick merely to satisfy the five-second reconciliation cadence; it waits for an authoritative mutation notification or the 30-second schedule-admission deadline, while coarse wake polling exists only as lost-filesystem-event protection. Five-second reconciliation still runs whenever active/event-driven ticks occur. Heartbeat persistence remains health/readiness evidence and must not become scheduler work-admission authority.
 - Runtime availability/recovery keeps Forge itself healthy; it does not imply exactly-once crash recovery for every local shell command.
-- The default Controller MCP schema is the stable **19-tool** surface.
-- `core` and `advanced` expose that same stable surface.
-- `toolset=full` is an explicit compatibility profile and may contain historical definitions; current default schema construction must not depend on those legacy definitions.
+- Controller MCP exposes **one complete tools/list inventory** assembled from the registered runtime and domain definitions. There is no `facade`/`core`/`advanced`/`full` exposure configuration; the small preferred-name catalog is routing guidance, not an alternate schema.
+- The 155-tool historical inventory is the initial migration baseline, not a target count or permanent compatibility layer. Migrate equivalent callers to canonical typed executors and remove redundant public handlers and schemas rather than introducing a hidden mode. Access grants remain independent of discovery.
 - Current schemas/handlers should live with their owning module. Legacy compatibility may delegate but must not independently own current business rules. Shared transport contracts and tool definitions belong in neutral contract/definition modules so the dependency direction remains transport -> application/domain authority rather than transport implementations importing one another.
-- Work-attributed verification is an application service, not an MCP/Local Bridge implementation detail: all Work verification resolves the Work checkout/check registry, runs through Process Runtime, validates terminal receipt identity, and records Work evidence through the same `work-verification-service.ts`.
+- MCP tool schemas may remain frozen for the lifetime of an already-open host conversation even when Runtime reconnects onto a newer release. A versioned frozen-session wire decoder may therefore translate only explicitly bounded historical carriers into the current semantic/controller API; it owns no lifecycle or persistence, may not restore retired verify/review/finalize/ControllerRound operations, and must preserve current CAS/authority checks. The pre-Thin `semantic.v1` and current-conversation enrollment carriers are such a migration decoder. Retire that decoder only after the minimum supported MCP client contract no longer advertises those carriers and release reconnect canaries prove no supported frozen-session consumer remains.
+- Work-attributed verification is an application service, not an MCP/Local Bridge implementation detail: all Work verification resolves the Work checkout/check registry, first reuses an exact-current authoritative pass/fail receipt or reconciles an already-terminal Work-bound Process with the same verification fingerprint, and only then runs a new Process when no current authority exists. Terminal receipt identity and Work evidence remain centralized in `work-verification-service.ts`; repeated verify calls for an unchanged candidate do not re-execute the check.
 - First-party external providers have one desired-contract reconciliation boundary: Controller plugin registry/manifest sync reconstructs the current Forge-owned permissions/capabilities/actions from source while preserving installed provider identity, transport target, lifecycle identity, provider/protocol version and enabled state. The canonical external-registration store remains the only fingerprint/revision persistence authority; manifest reads/execution never create a second registration authority or silently mutate durable state.
 - Product bootstrap has one instance-level desired/observed lifecycle authority behind the Bootstrap Control API. CLI setup, Local Bridge readiness, packaged Runtime install/upgrade/repair projection, and doctor observation consume that same authority rather than persisting parallel setup state. Browser/tunnel/provider implementations remain adapters beneath this API.
 - WSL ChatGPT browser bootstrap may create only a dedicated Forge-controlled Chromium profile when the runtime explicitly supports unpacked-extension startup. Ordinary user Chrome profiles are observational/existing-capability surfaces only; unsupported automatic extension loading must fail closed with a resumable user action.
@@ -233,15 +357,15 @@ Host hook files are integration surfaces, not lifecycle or architecture authorit
 
 ## Engineering Workloop boundary
 
-The V2 Engineering Workloop is a policy/evidence layer on the existing Requirement → Plan → Work → Controller/Process lifecycle, not a second lifecycle. Forge owns lifecycle, durable Work state, routing/policy gates, source/evidence identity, resource fencing, verification facts and recovery mechanics. ChatGPT Controller owns requirement interpretation, product/architecture decisions, root-cause judgement, semantic acceptance and whether another round is required.
+Engineering evidence is optional model/project context layered over semantic Requirement/Plan/Work records; it is not a lifecycle or admission plane. Forge owns durable facts, execution capabilities, resource fencing, source identity, verification facts, receipts, and recovery mechanics. The model owns requirement interpretation, product/architecture decisions, root-cause judgment, verification/review strategy, semantic acceptance, and whether another action is required.
 
-`EngineeringWorkProfile` is Kernel-owned generic method/risk policy and must not contain project-domain facts. `.forge/project-engineering.json` is the default source-controlled `ProjectEngineeringContract`: it may name project authority files, UX/performance/non-regression constraints, named checks and journeys, platform/tooling requirements, Skill references and explicit project exceptions. Controller state stores only a source-bound receipt containing the repository-relative path, project/contract identity, contract version, exact source revision, SHA-256 content digest and repository provenance time; it never persists a mutable copy that could become a second project authority. Skills own reusable professional methods such as iOS/Swift engineering, debugging and review technique. Semantic tools such as SourceKit-LSP, other language servers, compilers and CodeGraph provide factual source/build/navigation evidence but never own product intent. AGENTS/CLAUDE guidance remains thin repository/directory routing and local-guidance evidence; its wording is not proof that a Skill or semantic tool actually participated.
+`EngineeringWorkProfile` is Kernel-owned generic method/risk policy and must not contain project-domain facts. `.forge/project-engineering.json` is the default source-controlled `ProjectEngineeringContract`: it may name project authority files, UX/performance/non-regression constraints, named checks and journeys, platform/tooling requirements, Skill references, explicit Skill-to-kind bindings, and project exceptions. The Controller MCP policy treats this exact source-controlled contract path as writable while keeping sibling `.forge/**` controller/config/secret paths denied. Controller state stores only a source-bound receipt containing the repository-relative path, project/contract identity, contract version, exact source revision, SHA-256 content digest and repository provenance time; it never persists a mutable copy that could become a second project authority. Skills own reusable professional methods such as iOS/Swift engineering, debugging and review technique. Semantic tools such as SourceKit-LSP, other language servers, compilers provide factual source/build/navigation evidence but never own product intent. AGENTS/CLAUDE guidance remains thin repository/directory routing and local-guidance evidence; its wording is not proof that a Skill or semantic tool actually participated.
 
-Context Closure is a derived `rh_context` evidence layer, not another context database or lifecycle. It binds the exact source revision to current source/test paths, dirty/Work context, applicable repository guidance, ProjectEngineeringContract provenance, detected language/platform, project-declared Skill refs, semantic-provider evidence and bounded recent related changes. Skill/tool absence is explicit degraded evidence. Cross-file ownership/protocol/architecture claims require matching semantic navigation evidence or an explicit compiler/build fallback; a registered provider alone is not proof.
+Context Closure is a derived `rh_context` evidence layer, not another context database or lifecycle. It binds the exact source revision to current source/test paths, dirty/Work context, applicable repository guidance, ProjectEngineeringContract provenance, detected language/platform, project-declared Skill references/bindings, semantic-provider evidence and bounded recent related changes. Explicit Skill bindings own kind coverage when present; legacy `skillRefs` retain name-based compatibility matching. Skill/tool absence is explicit degraded evidence. Cross-file ownership/protocol/architecture claims require matching semantic navigation evidence or an explicit compiler/build fallback; a registered provider alone is not proof.
 
-`engineering-work-profile-v1` maps Work risk into `low | normal | high | critical`. `readonly/low` keeps the shortest valid path. `medium` maps to normal: required evidence gaps are recorded but Stage7A does not yet block legacy-compatible normal admission. `high` enforces exact source identity plus source-bound Project Contract, Context Closure, Product DoD, Design Decision and independent critique before mutation. `destructive` maps to critical and additionally requires semantic-tool evidence before mutation. Focused validation, fresh review and applicable real journeys are completion requirements rather than pre-mutation design substitutes.
+`engineering-work-profile-v1` maps Work risk into `low | normal | high | critical` solely to organize optional evidence and project guidance. Product DoD, Context Closure, design decisions, critique, semantic-tool output, validation, review, and journey evidence never admit or deny a repository mutation, delivery, or semantic Work completion. The model and project policy decide when they are useful. Capability admission remains limited to security/access, destructive authorization, secrets, dirty ownership, resource fencing, source CAS, concurrency, Git consistency, and external-effect idempotency.
 
-Every created Work may persist an `EngineeringContextReceipt` containing profile version, source identity, structured receipt ids, conditional semantic-tool/journey flags and bounded missing-admission/missing-completion lists. The Controller-facing `rh_work start` surface exposes the resolved profile and missing evidence but does not accept caller-supplied receipt ids as authority. `verifiedEngineeringEvidence` is an internal trusted input only, populated by Forge evidence authorities after source/provenance verification; raw MCP fields, prose, chat memory, test names, or syntactically valid invented ids cannot satisfy admission. A Project Contract receipt from another source revision fails closed. Stage7B/C automate Context/Skill/tool resolution and Product DoD/Design/critique receipt production so stricter governance does not turn low-risk edits into manual choreography.
+Every created Work may persist an `EngineeringContextReceipt` containing profile version, source identity, structured receipt ids, conditional semantic-tool/journey flags and bounded missing-evidence lists. The Controller-facing `rh_work start` surface may expose this context but does not accept caller-supplied receipt ids as safety authority. Provenance validation protects the integrity of recorded evidence; it does not turn absence, staleness, or a project-methodology disagreement into a Forge mutation gate. Stage7B/C may automate context, skill, tool, Product DoD, design, or critique evidence production only as optional assistance.
 
 ## Provider boundary
 
@@ -249,26 +373,27 @@ Typed provider/plugin actions should use Forge capability/resource semantics dir
 
 ### Computer and macOS provider boundary
 
-`Computer` is the user-facing interaction product boundary. Browser and Desktop remain distinct semantic subdomains inside that product: Browser owns DOM/tab/navigation/session/transaction semantics, while Desktop owns generic application observation, input, capture, and native-platform interaction. Browser may consume provider-native support through `computer.browser_automation.v1`, but neither the internal `browser` adapter identity nor concrete provider identity such as `desktop_operator` is a second user product or routing/session authority. Internal adapters remain exactly addressable only for trusted composition and migration.
+`Computer` is the user-facing interaction product boundary. Browser and Desktop remain distinct semantic subdomains inside that product: Browser owns DOM/tab/navigation/session/transaction semantics, while Desktop owns generic application observation, input, capture, and native-platform interaction. Ordinary Computer browser actions attach to existing native Chrome/Vivaldi windows and exact tabs (including background tabs); they never enter a Playwright CDP or managed/isolated-profile fallback. The independent Browser scripting provider may still run Playwright only through an explicitly selected scripted Browser route. Computer cannot create the first browser window merely because a browser process is running; a missing window fails closed instead of silently starting a new UI. An explicit existing-resource request also fails closed when no unique matching tab exists, never creating a replacement. The native Computer Browser capability is built into the first-party Forge release, registered and enabled by default in every repository; it is not installed, configured, or disabled through the independent Browser-script plugin. Its runtime readiness still depends on the target platform's native browser availability and permissions. Browser defaults attach to the existing user browser and fail closed when unavailable; legacy implicit managed-profile defaults migrate to native attach. Across multiple installed browsers, select a unique exact-URL match before any frontmost-browser preference, including on first use with an explicitly supplied but unbound session ID; same-origin presence is a profile hint, never authority to overwrite an unrelated user tab. Browser may consume provider-native support through `computer.browser_automation.v1`, but neither the internal `browser` adapter identity nor concrete provider identity such as `desktop_operator` is a second user product or routing/session authority. Internal adapters remain exactly addressable only for trusted composition and migration.
 
 On macOS, Forge Desktop Operator is the independently released native Computer provider. Its Git repository, app bundle identity, user LaunchAgent, socket endpoint, live native handles, and TCC permissions remain provider-owned and release-independent. Its trusted registration is explicitly provider-only: normal plugin discovery exposes `computer`, while diagnostics and lifecycle composition may still address `desktop_operator` exactly. Forge owns trusted catalog selection, registration, capability/action policy, authorization, provider selection, and the `forge computer setup|status|doctor|update|uninstall` product facade. The stable Desktop Operator bundle/LaunchAgent identity must not be renamed merely to match product wording because TCC identity and provider lifecycle are intentionally independent from Forge Runtime releases. Durable application interaction-target authority is Forge-owned in Controller SQLite. Public Computer actions use a stable `target_id`; provider session/handle identities are live bindings only. Rebind, target use, and retirement serialize on the same target-scoped authority lease, and a provider restart may rebuild a binding only after the stable application identity is re-verified. Rebinding occurs before semantic dispatch; once a non-idempotent provider mutation is dispatched, an unknown transport outcome is never automatically replayed. A host application or browser discovery result is not a Computer capability proof: a capability is supported only when the current platform has a compatible provider, and it is ready only when that provider is registered, enabled, declares the capability, and has recorded healthy evidence. On an unsupported platform, status and setup fail before probing a foreign provider; Runtime must not create a legacy provider binding or retry a foreign transport.
 
-`computer.console.unlock.v1` is a protected Computer capability, not a widening of `computer.input.v1`. Forge owns its provider-neutral contract, provider selection/negotiation, and explicit single-use authorization boundary; Desktop Operator owns macOS lock-state observation, exact `loginwindow` binding, bounded physical input, attempt limiting, and authoritative locked-to-unlocked postcondition verification. Raw macOS credentials never enter ChatGPT, MCP arguments, or Forge Runtime. The frozen 19-tool ChatGPT deployment ABI does not grow dedicated console-unlock tools: refreshed clients invoke typed `computer/console_unlock_prepare` and `computer/console_unlock` actions through the existing stable `plugin_action_execute` dispatcher. Those actions use the explicitly restricted `direct_non_persistent` lane: manifest/schema validation and per-invocation authorization still apply, but Work attribution is forbidden and the invocation bypasses plugin request indexes, receipts, Process/ExecutionJob state, evidence, and replay. While the console is unlocked, prepare asks Desktop Operator to collect the credential in a provider-local secure field and returns only a short-lived opaque single-use handle; unlock later consumes that handle while the console is locked. The old atomic `computer_console_unlock_prepare` / `computer_console_unlock` handlers remain registered only on the explicit full compatibility surface and enter the same canonical protected execution functions without becoming part of the stable connector schema. Results are allowlisted projections and cannot echo credential material. Ordinary `desktop_key`, `desktop_type_text`, batch, pointer, screenshot, application activation, shell, and compatibility paths cannot target the lock screen through this capability.
+`computer.console.unlock.v1` is a protected Computer capability, not a widening of `computer.input.v1`. Forge owns its provider-neutral contract, provider selection/negotiation, and explicit single-use authorization boundary; Desktop Operator owns macOS lock-state observation, exact `loginwindow` binding, bounded physical input, attempt limiting, and authoritative locked-to-unlocked postcondition verification. Raw macOS credentials never enter ChatGPT, MCP arguments, or Forge Runtime. The frozen 20-tool ChatGPT deployment ABI does not grow dedicated console-unlock tools: refreshed clients invoke typed `computer/console_unlock_prepare` and `computer/console_unlock` actions through the existing stable `plugin_action_execute` dispatcher. Those actions use the explicitly restricted `direct_non_persistent` lane: manifest/schema validation and per-invocation authorization still apply, but Work attribution is forbidden and the invocation bypasses plugin request indexes, receipts, Process/ExecutionJob state, evidence, and replay. While the console is unlocked, prepare asks Desktop Operator to collect the credential in a provider-local secure field and returns only a short-lived opaque single-use handle; unlock later consumes that handle while the console is locked. The old atomic `computer_console_unlock_prepare` / `computer_console_unlock` handlers remain internal-only and do not widen the stable Connector schema. Results are allowlisted projections and cannot echo credential material. Ordinary `desktop_key`, `desktop_type_text`, batch, pointer, screenshot, application activation, shell, and compatibility paths cannot target the lock screen through this capability.
 
-Trusted `ExternalPluginRegistration` is the endpoint/lifecycle authority for an installed Computer provider. A release-independent Desktop Operator install receipt may refresh only installed release metadata when it proves the same already-trusted socket, verified LaunchAgent, exact trusted executable binding, bundle identity, and provider manifest; the receipt's own program-name hint is only self-consistency evidence, never lifecycle authority. The receipt is evidence, never a second endpoint/lifecycle authority, and contradictory matching evidence fails explicitly. Its local JSONL transport uses a platform-local endpoint (a Unix-domain socket on Unix or a Windows named pipe on Windows), not a browser-discovery proxy or a second readiness authority. A bounded explicit compatibility fallback may support an old unregistered provider during migration, but it is never the primary endpoint authority and must not survive as a second discovery path after its compatibility window. Provider protocol negotiation prefers provider-neutral `computer_execute`; legacy `macos_browser_automation` is compatibility-only and cannot become Browser authority. Forge uninstall must complete the provider-owned native uninstall lifecycle before forgetting a registered provider, so package/registration cleanup cannot orphan a running native service.
+Trusted `ExternalPluginRegistration` is the endpoint/lifecycle authority for an installed Computer provider. A release-independent Desktop Operator install receipt may refresh only installed release metadata when it proves the same already-trusted socket, verified LaunchAgent, exact trusted executable binding, bundle identity, and provider manifest; the receipt's own program-name hint is only self-consistency evidence, never lifecycle authority. The receipt is evidence, never a second endpoint/lifecycle authority, and contradictory matching evidence fails explicitly. Its local JSONL transport uses a platform-local endpoint (a Unix-domain socket on Unix or a Windows named pipe on Windows), not a browser-discovery proxy or a second readiness authority. A Computer provider must resolve only from a trusted `ExternalPluginRegistration`; Runtime no longer binds an unregistered Desktop Operator socket as a compatibility provider. Provider protocol negotiation prefers provider-neutral `computer_execute`; legacy `macos_browser_automation` is compatibility-only and cannot become Browser authority. Forge uninstall must complete the provider-owned native uninstall lifecycle before forgetting a registered provider, so package/registration cleanup cannot orphan a running native service.
 
 ### iOS physical-device boundary
 
+- Physical-iPhone everyday App actions are exposed exclusively by the repository-scoped `computer` plugin's `physical_device_*` capability descriptors, dispatched by the existing `plugin_action_execute` authority. The `ios` plugin retains Xcode, Simulator and explicit agent-device/XCTest development/test actions. `computer` delegates to the existing CoreDevice executor and its exact-phone authorization, not a second transport or session writer. Physical app open reactivates the target App on both new and reused sessions (and honors explicit terminate-existing), invalidates earlier foreground observations before activation, and never infers foreground from a cached session or launch receipt. Cross-action RemoteXPC prewarm is deferred to the first input action, and validated screenshot dimensions avoid a redundant display query on observed opens. Physical app activation rejects devices that CoreDevice reports as disconnected and lock-state replies without an explicit boolean `passcodeRequired`; intent-ranked capability discovery uses live source-derived plugin manifests so persisted status projections cannot advertise retired action ownership, while discovery remains read-only. Strong-confirmed one-file App Documents exports reject basic truncated PDF/PNG/JPEG copies (and invalid HEIC first-box bounds) before atomically indexing verified framing receipts inside the same private Controller session folder; prior indexes are size-capped and validated against the exact App/session and each receipt before a subsequent phone copy, never silently overwritten when malformed; there is no separate document writer or medical inference service. Controller-scoped Computer actions do not expose repository-bound phone input.
 - `ios-device` is the single physical-device resource domain. Backend/engine details may vary, but they must not create independent mutation authority or concurrent ownership for the same phone.
 - Agent-device readiness is capability-negotiated from a reviewed version/help contract and a stable contract fingerprint. A preferred version is support guidance rather than authority; unsupported or unreviewed pre-1.0 contracts fail closed instead of guessing flags or semantic support.
 - Application adapters own app-specific semantic targeting and assertions; provider code owns transport, device/session lifecycle, and command execution. Semantic action failure is distinct from transport/session death, and unknown mutation outcomes are fenced rather than blindly replayed.
-- iOS evidence is bounded and redacted. Read-only lifecycle/screenshot capability must never be represented as proof of semantic mutation capability.
+- iOS evidence is bounded and redacted. Read-only lifecycle/screenshot capability must never be represented as proof of semantic mutation capability. The existing CoreDevice screenshot observation authority uses a private 0700 per-session artifact directory and 0600 screenshot files, invalidates old observations before recapture, deletes partial failures, and rejects missing, oversized or malformed PNG structures (including damaged chunk CRCs) before issuing an observation ID and a SHA-256/byte-count provenance receipt; image bytes alone never certify the foreground App or displayed product price. The source-only Computer smoke verifies the observed screenshot's file SHA-256 and byte count against its CoreDevice receipt before reporting the path and observation ID, but expressly makes no SKU/price or activated-Runtime claim. Computer reports CoreDevice `observationReady` separately from pinned RemoteXPC HID `inputReady`; an unavailable or incorrectly versioned toolchain may leave screenshots usable without claiming interaction readiness. Generic Browser/Desktop Computer manifest reads never invoke synchronous HID Python probes, including when CoreDevice itself is ready: they consult only the short-lived successful probe cache. Explicit RemoteXPC input retains the sole strict Python package/version probe. The single Controller-owned versioned Python path is provisioned by `scripts/install-ios-hid-toolchain.sh` only with authorized host execution, and never changes the active Runtime release.
 
 ## Browser Runtime V3 contract
 
 Browser Runtime V3 is the current Browser execution authority. Controller-home BrowserSession state is the sole durable browser-session authority; stable provider/resource identity is distinct from mutable observed URL/title, and provider-local live handles are acceleration state only. The accepted Browser Runtime V2 ADR remains historical rationale rather than a competing current authority.
 
-Browser providers are selected by declared capability. Common DOM and typed browser-internal operations must remain background-safe. Native macOS sessions reuse or recover only exact Forge-owned `windowId` + `tabId` identities. Provider-wide tab inventory is an optional optimization: when the installed broker cannot enumerate tabs, Forge may create a new plugin-owned tab or validate a saved exact ref, but it must not scan for or guess an unrelated user tab.
+Browser actions bind exactly one provider before execution, selected deterministically by the configured mode and exact target; registering multiple candidates or silently rebinding on a pre-action failure is forbidden. Attach mode uses one configured CDP endpoint or one explicit native browser product, not an ordered CDP/native/managed fallback chain. Managed Playwright requires explicit selection. Common DOM and typed browser-internal operations must remain background-safe. Native macOS sessions reuse or recover only exact Forge-owned `windowId` + `tabId` identities. Provider-wide tab inventory is an optional optimization: when the installed broker cannot enumerate tabs, Forge may create a new plugin-owned tab or validate a saved exact ref, but it must not scan for or guess an unrelated user tab.
 
 Foreground presentation is an explicit effect reserved for capabilities that truly require physical pointer/keyboard input or human handoff. Browser `trusted_input` never silently activates a background tab or converts CSS viewport coordinates into desktop coordinates. If the native broker lacks the required trusted-input capability, Browser fails with a typed capability error; an explicitly requested Desktop Operator foreground/physical action remains a separate authority boundary. Mutating provider actions are complete only when their declared postconditions are verified; transport, Apple Events, Accessibility, socket, or CGEvent success alone is not semantic completion.
 
@@ -306,8 +431,37 @@ Research notes, tasks, reviews, archived architecture pages, plans and Git histo
 
 ## Intentionally retained compatibility debt
 
-- Explicit `toolset=full` remains a supported legacy compatibility boundary for now. Issue/Task/project-board writers are migration-only compatibility and are permanently retired after the SQLite requirement-portfolio cutover marker; they must not become a second current control plane.
+- Issue/Task/project-board writers that remain in the complete registry are migration-only and must be deleted after their callers migrate; they must not become a second current control plane or justify an alternate tool exposure profile.
 - Some large runtime modules still aggregate multiple responsibilities and should be decomposed only when a clear ownership boundary is available.
-- CodeGraph may be structurally stale between index refreshes; current raw source and changed-file overlays remain authoritative.
+- Former CodeGraph indexes are retired. Current raw source and changed-file overlays remain authoritative.
 
 These items belong on the roadmap, not in parallel current-architecture documents.
+
+ChatGPT Supervisor browser submission requires a positive read-back of the exact ProseMirror plain-text effect payload before Send/Enter; a successful `fill`/keyboard receipt alone is insufficient. The ChatGPT Project instructions already direct tool selection, so the provider must not select or verify an App chip. Only the legacy `@forge` prefix immediately preceding a valid effect marker may be removed, preserving all other payload bytes and line breaks. A foreign App mention, unrelated draft, missing/mismatched composer or changed exact target rejects before Send, without consuming a provider send attempt. Before preparing and again in the final Send action, Computer verifies the live tab/project or canonical conversation identity; unknown post-Send results reconcile the same Supervisor effect rather than re-sending it. A real live ChatGPT conversation, meaningful Forge tool execution, the provider-observed completed final assistant reply, and its Supervisor completion receipt remain required for end-to-end acceptance. MCP calls cannot settle a Supervisor turn; its compact C/D/U challenge must be the last line of the final reply after the provider stops generating. A committed compact receipt is the sole successor authority even if the provider later collapses historical DOM content; a queued send still respects live provider busy, exact target, and unknown-outcome fences.
+
+Workflow Supervisor's Computer delivery now has one two-phase boundary: `ComputerChatgptConversationTarget.prepare` may prepare the local composer, verify the requested reasoning effort and exact plain-text effect payload, but must **never** click Send. Only a verified `ready` allows Supervisor's existing effect authority to append `effect_dispatch_started`; `dispatch` then rechecks the prepared editor and performs the one permitted Send. Failed preparation records `effect_preflight_rejected` in the **same Supervisor effect event log**, with zero provider generations consumed. The existing `supervisor_task get` stall projection exposes the latest stored preflight reason code for root-cause diagnosis, without creating another durable status or retry authority. The ledger permits at most one preparation attempt for the same effect and active Runtime release, and at most three distinct failed release identities in total. An unchanged broken Runtime cannot retry indefinitely after a process restart; a later verified Runtime revision can get a bounded opportunity without minting another effect. Uncertain post-Send outcomes remain in the established read-only reconciliation path and may never be re-sent merely because local preparation later succeeds. Browser transport preparation failures and provider send attempts are not interchangeable budget units.
+
+Supervisor fresh-conversation bootstrap uses one provider-owned Chrome tab per distinct Supervisor task. A ChatGPT Project URL is a scope only and **never** proves a tab belongs to a given bootstrap identity: the Chrome Extension may reuse only the task-keyed ephemeral tab mapping or the exact provider/tab/window binding already persisted by Controller's Computer target authority. On a service-worker restart the Controller binding is passed as an attachment hint and verified against the project before reuse. An absent or mismatched pinned tab fails closed without creating a second possibly duplicate conversation. New unbound bootstrap identities create dedicated background tabs; iOS and Android tasks sharing one Project must never claim each other's surface binding index. The enrollment prompt is a complete structured Supervisor effect with exact goal, immutable effect marker and end marker; Computer must read back the complete plain-text effect payload without any App chip before the first Send.
+
+A pre-send refusal is a property of the Browser provider, not necessarily of the Forge source release. If the Computer provider is repaired independently (for example, the installed Chrome extension worker is reloaded), the operator may use the existing Supervisor `task_recover` action for the *same exact pending effect* with `generations=0`. One `effect_preflight_operator_rearmed` event in the canonical Supervisor effect ledger permits a single additional preparation in that release, retaining the original enrollment prompt and effect marker; neither a new task/effect nor any dispatch-generation refund is created. Its next preparation failure has a new event key and counts toward the existing maximum of three failures. The operator rearm is allowed at most once per effect, idempotent by request ID, and forbidden for a submitted, applied or outcome-unknown effect. Ordinary service-worker restarts cannot cause an unbounded resend or bypass the Supervisor ledger.
+
+A STOPPED bootstrap draft may be replaced only from the canonical Supervisor ledger: the exact old effect must have a pre-terminal `effect_preflight_rejected` receipt proving `send_clicked=false`, the exact visible editor digest and zero dispatch generations; its task must be terminal `STOPPED` and its Project must match the current bootstrap. `FORGE_RETIRED_DRAFT_V1` is a prepare-only Computer instruction; the extension rechecks the live draft bytes and Project before replacement, and dispatch remains the sole Send authority.
+
+Repository delivery receipts use the WorkHandle immutable `baseCommit` to describe delivered source changes; `deliveryBaseCommit` remains the movable integration/validation baseline and cannot erase that scope after successor adoption. A genuinely empty repository delivery records `completed_no_change` only with a repository receipt whose delivery kind is `no_change` and whose changed paths are empty. The existing kernel invariant accepts this physical evidence while retaining semantic `repository_change` WorkKind; no receipt writer may reclassify semantic Work. Reconciliation after cleanup is idempotent. Physical delivery does not close semantic Work: the model still completes it with revisioned CAS after acceptance.
+
+Supervisor `forge_work_done` and Requirement DONE contracts read the existing canonical Work lineage before acceptance: explicitly bound Work, Requirement-linked Work, decomposition children and declared dependencies must be semantically terminal. Portable semantic rows override repository compatibility shadows; malformed relevant rows, missing declared dependencies and bounded snapshot exhaustion fail closed. Unrelated open Work and standalone model completion without a Work binding remain independent. This read-only validator neither completes Work nor introduces a lifecycle writer; the model uses the existing revisioned CAS to settle each obligation.
+
+MCP HTTP POST lifecycle diagnostics derive admission count and oldest-request duration from **one response-owned Map**, rather than maintaining a scalar counter beside a separate age store. Each admission is deleted idempotently on `finish` or `close`; admission and health/readiness observation also converge entries from Node's authoritative terminal `ServerResponse` flags in case a transport SDK removed or replaced those listeners. Request age never retires an entry: a connected unfinished response and every possibly in-flight effect remain protected regardless of duration. `/health.sessions.activePosts` and `oldestActivePostAgeMs` share this owner for modern stateless and legacy protocol calls. Recovery propagates the optional oldest active POST age into ReleaseSession cutover diagnostics, retaining the strict existing `activePosts=0`, `activeStreams=0`, initialization-empty, quiet-window safety predicate. Legacy `oldestPostAgeMs` alone does not describe modern HTTP requests and must not be used to conclude that the Connector is quiescent.
+
+**Autonomous continuation R1 baseline (2026-10-11):** The existing Supervisor journal remains the only Work-bound send authority. Task registration, objective revision, and effect rendering now share a single fail-closed objective bound: values exceeding 8,000 JavaScript characters are rejected explicitly, never silently sliced into an apparently successful shorter prompt. The actual Task objective is preserved byte-for-byte within the JSON envelope. Browser delivery validates that Forge's app name and exact app path belong to the same ProseMirror app chip; neither a plain `@forge` string nor separate HTML nodes prove that tool invocation is bound. These are safety/contract changes, not an assertion of a successful live ChatGPT MCP call. Runtime/Recovery/Computer versions and real causal receipt still require G0a/R3/R4 evidence.
+
+Browser Playwright dependency resolution has one ordered runtime contract. An immutable compiled Runtime resolves Browser dependencies from the release-owned `package/package.json` beside `forge-runtime-bundle.js` first, then from an explicitly authorized repository package when present, and finally from the executing source/bundle module anchor for development compatibility. Browser dependency availability checks and actual Playwright loading use this same ordered anchor set; consumer repositories are never required to install Forge's packaged Playwright, and no second dependency-resolution authority is maintained.
+
+
+The Chrome extension heartbeat is an inventory hint, not the durable ChatGPT conversation identity. If the heartbeat lacks an exact conversation during read-only Supervisor reconciliation, Computer uses the **same pinned Chrome profile** to request one read-only physical-tab `observe` by stable conversation identity; the extension itself verifies the sole matching tab (and refuses ambiguous matches or a live pinned tab whose identity drifted). Only a positive, hydrated, exact-URL observation may CAS-rebind the existing Computer Surface. This path never opens a tab, edits a draft, consumes a dispatch generation, or retries an unknown Send. If the tab is physically absent, the existing `EXACT_TARGET_ABSENT_READ_ONLY` boundary remains; a separately authorized exact-conversation open is required before observation can continue.
+
+**Supervisor bounded task-local delivery fuse (2026-10-18).** Actual failed Computer target operations, canonical no-Send preflight/provider-failure events, and bounded read-only no-progress watchdog observations form a single consecutive failure count in the Supervisor SQLite journal; a real effect-applied, committed completion or conversation migration resets that count. Three failed attempts across error codes and Runtime restarts trigger the existing CAS-fenced fresh-conversation migration in the same task, not a new task/scheduler/transport Provider. The existing cap of two consecutive unsuccessful migrations still applies. Rate-limited/provider-wide backpressure and human permission prompts are not a reason to change conversations. Outcome-unknown submitted effects block migration until reconciled; this fuse never retries an uncertain Send or erases an operator draft. A blocked fuse remains observable rather than silently manufacturing success. Independent investigation of ChatGPT mobile/Chrome stream interruptions remains issue #300.
+
+**Work-owned Supervisor close propagation (2026-10-18).** A semantic Work's explicit `completed` or `cancelled` transition stops only the exact enrolled `forge:<repoId>:work:<workId>` Supervisor via its canonical `terminal_stopped` ledger event. The Work facade requests the stop immediately after committing the semantic revision; the native Supervisor consumer rechecks the same canonical Work state at startup/tick so a temporary daemon failure cannot leave stale sends active. Work-bound dispatch admission also fails closed as soon as Work is terminal. Other standalone tasks, Requirement-owned original Goals, and separate successor operational Work/Schedules retain their own authority. Closing the historical Gmail development Work does not stop the separate daily Gmail digest Work or its 08:00 Scheduler. No second Supervisor writer, implicit Work reopen or provider resend is introduced.
+
+**Computer ChatGPT no-model-picker send (2026-10-18).** Supervisor submits durable effects against exactly one Computer ChatGPT target; the transport verifies exact conversation/Project identity, visible single editor, draft ownership, click receipt and outcome-unknown boundaries. It does **not** select, require, test, or mutate ChatGPT reasoning mode, which remains the user's browser preference. Deleted the old Medium/High/Extra High UI parser, slider driver, pre-Send gate, typed protocol fields and their brittle architecture assertions rather than adding a second fallback rule. Removal of the Chrome extension transport itself remains contingent on read-only direct native Browser equivalence for physical target pinning, authenticated profile, committed user-turn confirmation and outcome-unknown reconciliation; never run two automatic providers in parallel for one effect.