@timurproko/a1 0.2.7-dev.1249 → 0.2.7-dev.1252

package/docs/architecture/boundaries.md

@@ -1,56 +1,51 @@
 # Architecture boundaries
 
-## Terminal and launch-instance ownership
+## One process per launch
 
-Every interactive command uses this profile-neutral lifecycle path:
+Every interactive command uses this profile-neutral path:
 
 ```text
-mutable a1 entry
-  -> verified immutable release
-  -> Node launch guardian loading the verified process-guardian addon
-  -> addon-held per-instance containment and profile-aware runtime selection
+mutable a1 entry (bin/cli.js)
+  -> runBootstrap selects the verified approved immutable release
+  -> one directly attached child: node <release>/bin/ui.js [session arguments], stdio inherited
   -> owned Pi-backed composition, with A1 surfaces enabled only for bare a1
 ```
 
-Launch-instance ownership is plural. The supervisor tracks any number of independently authenticated `a1` and `a1 pi` instances and never uses one product-wide foreground mutex. Closing one instance closes only its verified process tree. Persisted rows alone do not prove liveness, and uncertainty never authorizes terminating an unrelated process.
+The launcher waits for the child and returns its exit code. When the child reports that the active release changed during startup, the launcher re-reads the release store once and starts the newer release. There is no supervisor, launch guardian, control store, control protocol, cohort coordination, or process containment: any number of `a1` and `a1 pi` processes run independently, and only the session writer guard coordinates them. Closing the terminal ends the attached child through the operating system, as upstream Pi behaves; tool subprocesses behave as they do in upstream Pi.
 
-The launch guardian and process-guardian addon do not read ordinary terminal input, parse or relay runtime output, render cells, infer frames, or synthesize terminal responses. Their only terminal output is the bounded reset and sanitized armed exit notice after runtime failure. Both profiles use the same owned rendering and input pipeline. Bare `a1` exposes A1-owned surfaces; `a1 pi` withholds those surfaces and uses Pi's ordinary profile root. The containment boundary carries only bounded identity, readiness, stop, and outcome data.
+The launcher does not read terminal input, parse or relay output, render cells, or synthesize terminal responses. Its only terminal output after an unclean child exit is the bounded terminal reset and the armed exit notice. Both profiles use the same owned rendering and input pipeline. Bare `a1` exposes A1-owned surfaces; `a1 pi` withholds them and uses Pi's ordinary profile root.
 
-A detached Node exit watcher sits outside the launch guardian's containment. It waits for the guardian, performs bounded Unix process-group cleanup, and may deliver the same claimed exit notice. A kill aimed at every Node runtime also kills this watcher; the accepted loss of the notice and Unix fallback cleanup in that case is documented in [`process-guardian-provenance.md`](process-guardian-provenance.md), and A1 starts no native executable to close that gap.
-
-The owned Pi-backed surface is not an arbitrary-CLI terminal multiplexer. A feature that requires resident arbitrary CLI sessions, internal tabs, terminal-state reconnection, or A1-authoritative scrollback must introduce and certify the separate composed-terminal authority rather than reactivating the retired transparent attachment path.
+The owned Pi-backed surface is one agent per terminal. It is not a terminal multiplexer and has no tabs, resident sessions, reattach, or A1-authoritative scrollback. Any multi-agent or composed-terminal feature needs its own approved change.
 
 ## Current module responsibilities
 
-- `lifecycle`: dependency-free launch-instance, process identity, state transition, outcome, and control-command contracts.
-- `process-containment`: process-guardian addon loading and artifact verification, OS-verifiable process inspection, in-process containment adapters, and bounded graceful/forced cleanup; it owns no terminal content.
-- `launch-guardian`: one profile-neutral Node instance coordinator above runtime selection, plus the fixed Node exit-watcher entry used only for owner-death cleanup and the armed notice.
-- `protocol`: additive control handshake, bounded line framing, authenticated launch-instance commands, typed stop intent, snapshots, and command results.
-- `launch`: resolves the effective profile home and the history-specific data root. Composition uses its public path resolver to select `~/.a1/data` for history unless `A1_DATA_DIR` is explicit; global control/release/runtime/cache paths stay unchanged.
-- `prompt-history`: narrowly typed user-input retention in separate profile-owned databases under `~/.a1/data/history` (or `<A1_DATA_DIR>/history`), with bounded worker queues and no supervisor/control-store payloads. It receives a resolved root rather than importing launch-feature internals; it never probes, imports, or deletes the former platform-default history. The editor's owned history state machine remains inside the Pi component boundary; the session UI only coordinates snapshots and classified submissions.
+- `lifecycle` (`src/foundation/lifecycle`): product paths, session selection, launch-profile identifiers, and the repository-context helpers behind `a1 session worktrees` / `link-worktree` / `unlink-worktree`. Worktree claims are serialized by a `proper-lockfile` claim gate, and runtime liveness is `process.kill(pid, 0)`.
+- `launch-context`: the neutral private environment contract a launcher passes to the release it starts.
+- `session-writer-lock`: one writer per Pi session file through `proper-lockfile`. Lock directories live in one per-user directory, keyed by the session file's canonical identity so aliases contend for one lock; stale locks are reclaimed after a 10-second bound. Every writer route goes through it, which `check-session-writer-guard.mjs` enforces.
+- release/update/bootstrap (`src/foundation/release`): package-derived immutable release identity, certified release manifests, durable update transactions, atomic activation, rollback, age-based retention, and the dependency-light command entry. Before certified fast-path reuse it checks every recorded product file is present; a missing or altered file is replaced only from the matching installed package when its size and digest reproduce the approved release, followed by full verification. Dependency layers keep their separate verification and repair policy.
+- `startup`: startup trace phases and the startup budget evaluator.
+- `terminal-cleanup`: bounded, idempotent emergency restoration, the exit notice, and fatal-exit diagnostics for an explicitly owned terminal. It does not inspect commands, relay terminal input/output, or emulate terminal state. The owned UI installs its fatal boundary before terminal activation; the launcher performs the same bounded reset and delivers the armed notice when the child exits uncleanly. Fatal records retain at most ten 16 KiB records with trusted classifications and code locations, never prompts, attachments, raw input, credentials, or arbitrary exception messages.
+- `launch` (`src/features/launch`): resolves the effective profile home and the history-specific data root. Composition uses its public path resolver to select `~/.a1/data` for history unless `A1_DATA_DIR` is explicit; global release/runtime/cache paths stay unchanged.
+- `prompt-history`: narrowly typed user-input retention in separate profile-owned databases under `~/.a1/data/history` (or `<A1_DATA_DIR>/history`), with bounded worker queues. It receives a resolved root rather than importing launch-feature internals; it never probes, imports, or deletes the former platform-default history. The editor's owned history state machine remains inside the Pi component boundary; the session UI only coordinates snapshots and classified submissions.
 - `prompt-suggestions`: opt-in bounded diagnostic snapshots of neutral suggestion lifecycle metadata. Composition supplies an explicit local destination; this feature never imports Pi, generates suggestions, stores conversation text, or owns the editor. See [prompt suggestion diagnostics](prompt-suggestions.md).
-- `storage`: SQLite migrations, prior-boot reconciliation, and plural launch-instance persistence. Legacy foreground rows are historical migration input and never authorize current ownership.
-- `supervisor`: endpoint identity, plural cohort ownership, per-instance reconciliation, and aggregate release shutdown coordination. It owns no terminal surface.
-- `pi-engine-adapter`, `pi-component-adapter`, and `pi-tui-runtime-adapter`: isolate pinned Pi engine and presentation knowledge behind neutral contracts; product features do not import them directly. Inside the engine adapter, one process-level engine host owns what is process-wide (the HTTP dispatcher, the theme singletons, the one-time changelog and package-update announcements, the startup trace) and is the only place sessions are created, so every session id is unique per process.
+- `pi-engine-adapter`, `pi-component-adapter`, and `pi-tui-runtime-adapter` (`src/integrations/pi`): isolate pinned Pi engine and presentation knowledge behind neutral contracts; product features do not import them directly. Inside the engine adapter, one process-level engine host owns what is process-wide (the HTTP dispatcher, the theme singletons, the one-time changelog and package-update announcements, the startup trace) and is the only place sessions are created, so every session id is unique per process.
 - `session-shell` (`src/app/session-shell`): the application layer that composes the feature owners, the UI foundations, and the three Pi adapters into the interactive session; only composition imports it. Its render root assembles semantic document and dock rows, while its focused viewport controller owns follow state, pointer routing, selection, and interaction timers. Owned-app route lifecycle belongs to the neutral `ui-apps` owner and is only hosted by the session shell.
-- release/update/bootstrap: package-derived immutable release identity, native-addon integrity, cohort selection, durable update transactions, rollback, and dependency-light command entry. Before certified fast-path reuse it checks every recorded product file is present; a missing or altered file is replaced only from the matching installed package when its size and digest reproduce the approved release, followed by full verification. Dependency layers keep their separate verification and repair policy. After an unsuccessful bare-A1 child exit, the launch owner or its Node watcher restores owned terminal modes and emits only the armed bounded notice.
-- `terminal-cleanup`: bounded, idempotent emergency restoration and fatal-exit diagnostics for an explicitly owned terminal. It does not inspect commands, relay terminal input/output, or emulate terminal state. The owned UI installs its fatal boundary before terminal activation; packaged bootstrap and checkout launch provide the surviving-owner fallback. Fatal records retain at most ten 16 KiB records with trusted classifications and code locations, never prompts, attachments, raw input, credentials, or arbitrary exception messages.
 
 ## Dependency direction
 
 Terminal boundaries are application-agnostic. They may not select behavior from executable names, arguments, CLI-specific environment variables, or visible text. Production code may not import private Pi distribution APIs or use a Pi-specific terminal workaround.
 
-The JavaScript product path has no PTY or terminal-emulator dependency. Reintroducing `node-pty`, xterm state, custom input encoders, mode/query trackers, cadence-derived frame inference, or renderer/projection code requires an approved capability change and cannot become a second terminal authority. The Rust process guardian is a lifecycle-only Node-API addon loaded by the launch guardian and is independent from the terminal-host Node-API addon. No A1-built executable is part of the production process surface.
+The product has no native code and no PTY or terminal-emulator dependency: no module under `src/` may import `node-pty` or a terminal emulator or spawn a pseudoterminal. Reintroducing xterm state, custom input encoders, mode/query trackers, cadence-derived frame inference, or renderer/projection code requires an approved capability change and cannot become a second terminal authority. The published package is pure JavaScript.
 
 `scripts/governance/check-architecture.mjs` enforces the structural parts of these boundaries. Cross-cutting rationale belongs here; implementation history belongs in Git and archived OpenSpec changes.
 
 ## Session shell composition
 
-The session presenter (`src/app/session-shell/session-shell.ts`) coordinates; it does not own per-concern state. Each concern implements `SessionConcern` (`session-concern.ts`): it resets its own state in `onSessionReplaced` and releases it in `dispose`, and the presenter lists its concerns once, in reset order, in `#createConcerns`. New submission, routing, dialog, login, or resident-tab behavior goes into the concern that owns it, or a new concern added to that list. The render root (`session-shell-root.ts`) likewise picks one `ShellLayout` at construction and delegates transcript caching to `TranscriptDocument`, dock chrome to `DockChrome`, workflow output to `WorkflowOutput`, extension surfaces to `ExtensionSurface`, and the dock's input surface to `InputSurfaceSwitch`. The engine adapter serves the shell through the ports built in `src/integrations/pi/engine/ports.ts`, and the composition root delegates runtime claims, the startup release note, and the resident-tab bridge to their own modules under `src/composition/`.
+The session presenter (`src/app/session-shell/session-shell.ts`) coordinates; it does not own per-concern state. Each concern implements `SessionConcern` (`session-concern.ts`): it resets its own state in `onSessionReplaced` and releases it in `dispose`, and the presenter lists its concerns once, in reset order, in `#createConcerns`. New submission, routing, dialog, or login behavior goes into the concern that owns it, or a new concern added to that list. The render root (`session-shell-root.ts`) likewise picks one `ShellLayout` at construction and delegates transcript caching to `TranscriptDocument`, dock chrome to `DockChrome`, workflow output to `WorkflowOutput`, extension surfaces to `ExtensionSurface`, and the dock's input surface to `InputSurfaceSwitch`. The engine adapter serves the shell through the ports built in `src/integrations/pi/engine/ports.ts`, and the composition root delegates runtime claims and the startup release note to their own modules under `src/composition/`.
 
 ## Unit size ratchet
 
-Module boundaries do not stop one class or function inside a module from absorbing every feature. The architecture gate therefore measures every production TypeScript class under `src/` (methods and fields) and every TypeScript or Rust function under `src/` and `native/<crate>/src/` (inclusive lines), excluding vendored sources and Rust `#[cfg(test)]` code. A unit with more than 20 methods, 15 fields, or 100 function lines must be recorded in `config/baselines/size-ratchet.json`, and its recorded counts can only shrink:
+Module boundaries do not stop one class or function inside a module from absorbing every feature. The architecture gate therefore measures every production TypeScript class under `src/` (methods and fields) and every TypeScript function under `src/` (inclusive lines), excluding vendored sources. A unit with more than 20 methods, 15 fields, or 100 function lines must be recorded in `config/baselines/size-ratchet.json`, and its recorded counts can only shrink:
 
 - A recorded count that grows fails the gate. Split the unit instead. If growth is truly unavoidable, raise the entry by hand in the same pull request and say why in its description, so the growth is reviewed rather than silent.
 - An unrecorded unit over a threshold fails the gate; split it before it lands.
@@ -60,25 +55,13 @@ The measurement in `scripts/governance/size-ratchet-policy.mjs` masks strings, c
 
 ## Multi-session limits of the pinned engine
 
-The engine host removes A1's own obstacles to several Pi sessions in one process, but three remain in the pinned Pi SDK and must be planned around, not discovered:
+The engine host removes A1's own obstacles to several Pi sessions in one process (session switch, fork, and resume replace the session in place), but three limits remain in the pinned Pi SDK and must be planned around, not discovered:
 
 - The extension cache is keyed by one working directory and cleared on reload (`core/extensions/loader.js`), so sessions in different directories reload each other's extensions.
 - `SettingsManager` writes under a lockfile but never re-reads the file, so a second in-memory copy goes stale after another session writes a setting (`core/settings-manager.js`). The host keeps the one process-wide effect, the HTTP dispatcher, consistent itself.
 - `AgentSessionRuntime.dispose()` releases the session but not the model runtime or the resource loader it was created with (`core/agent-session-runtime.js`), so a session's services outlive it until the process ends.
 
-## Planned multi-agent boundaries
-
-The multi-agent workspace feature, its dependency-free contracts, the structured-agent runtime, and the Node side of the terminal-host protocol were removed from `develop`; their last state is commit `243eb7a7` in `develop` history. That structured-workspace plan was retired on 2026-10-10 in favor of `add-persistent-multi-agent-tabs`, where every tab runs the complete A1 UI under the native terminal host. A future implementation starts from the current codebase rather than from that copy. The boundary rules below remain the design intent for that work.
-
-The workspace feature may depend on workspace contracts and the structured/terminal-host foundations. Those foundations may depend only on dependency-free workspace contracts, never on product features, launch profiles, or each other unless an approved capability adds the dependency. Launch profiles do not import, initialize, launch, or connect to composed terminal-host infrastructure.
-
-Default future agents and composed hosts are children of the originating bare-`a1` launch instance and terminate when it closes. A process that survives command closure requires a separately approved explicit resident capability; durable identity or state recovery never implies an implicitly surviving process.
-
-The structured-agent runtime uses a versioned adapter hello and feature negotiation before readiness. Runtime state must use typed events, commands, snapshots, cancellation, and recovery evidence. It must not infer structured semantics from terminal text, terminal timing, or visual content and must not own pseudoterminals or renderer state.
-
-The JavaScript-to-native terminal-host boundary carries only the fixed role arguments, host command, return code, session-lock calls, and typed semantic bridge data. `host-entry.js` does not touch Node's stdin/stdout streams; pseudoterminal bytes, per-event child input, rendered cells, cell grids, framebuffers, and screen buffers remain inside the addon's native roles and their bounded native IPC. The verified addon and fixed entry are the packaged production host; no console host executable exists. Replacing libghostty-vt with a lightweight custom parser/renderer is forbidden. A desktop-native window and GPU application shell are postponed and are not required for the terminal-hosted product.
-
-Resource queues, retained state, evidence, logs, and diagnostics follow `docs/architecture/resource-and-data-policy.md`. Terminal content and authentication material are never control-store records. Unknown data is potentially sensitive by default and must be rejected or redacted before persistence.
+Resource queues, retained state, evidence, logs, and diagnostics follow `docs/architecture/resource-and-data-policy.md`. Terminal content and authentication material are never persisted as diagnostics. Unknown data is potentially sensitive by default and must be rejected or redacted before persistence.
 
 ## The rules every surface follows
 

package/docs/architecture/code-documentation.md

@@ -9,8 +9,8 @@ Every first-party TypeScript class exposed through a production owner's public e
 Do not add JSDoc solely because a function, type, constructor, property, or method is exported. Do not document a class by repeating its name or listing its methods. Private and protected members never use JSDoc.
 
 ```ts
-/** Persists complete workspace views and recovery references through the control-store boundary. */
-export class WorkspaceStore {
+/** Persists durable update transaction phases so an interrupted update can resume or roll back. */
+export class UpdateTransactionStore {
 ```
 
 ## Implementation comments

package/docs/architecture/internal-naming.md

@@ -14,7 +14,7 @@ The nightly publication workflow runs `full-release`, including `naming-full`, a
 - Parser fixtures: `test/repository-governance/naming-inspection.test.ts`.
 - Git selection fixtures: `test/repository-governance/naming-selection.test.ts`.
 
-TypeScript/JavaScript and Python use syntax trees. Rust uses a token-aware scanner. Workflow environment maps, embedded Node scripts, JSON environment definitions, and supported shell assignments are inspected. Dependencies, immutable vendor files, generated output, and other worktrees are excluded; owned test helpers and locally adapted source ports are not. Unsupported owned inputs fail explicitly. Python inspection uses a bundled development-only grammar, not an installed Python interpreter.
+TypeScript/JavaScript and Python use syntax trees. Workflow environment maps, embedded Node scripts, JSON environment definitions, and supported shell assignments are inspected. Dependencies, immutable vendor files, generated output, and other worktrees are excluded; owned test helpers and locally adapted source ports are not. Unsupported owned inputs fail explicitly. Python inspection uses a bundled development-only grammar, not an installed Python interpreter.
 
 The exact externally branded key/member authority is `config/internal-naming-policy.json`. It records each setting's owner, evidence, exposure, and value semantics. Arbitrary uppercase properties are not public environment settings. No compatibility-alias exposure category is allowed. Test snippets and negative-test input data are not declarations or supported aliases.
 
@@ -24,14 +24,11 @@ The exact externally branded key/member authority is `config/internal-naming-pol
 
 | Keys | Producer / consumer and exposure |
 | --- | --- |
-| `A1_CONFIG_DIR`, `A1_DATA_DIR`, `A1_RUNTIME_DIR`, `A1_DATABASE_PATH`, `A1_ENDPOINT` | User/shell configuration consumed by `src/foundation/lifecycle/paths.ts`; documented public overrides, unchanged. |
+| `A1_CONFIG_DIR`, `A1_DATA_DIR`, `A1_RUNTIME_DIR` | User/shell configuration consumed by `src/foundation/lifecycle/paths.ts`; documented public overrides, unchanged. |
 | `A1_PROFILE_HOME` | Caller-supplied profile-home override consumed by `src/features/launch/profile-paths.ts`; exact existing exposure-review entry. |
 | `A1_STARTUP_TRACE` | Caller-supplied diagnostic path and trace context in `src/foundation/startup/startup-runtime.ts`; exact existing exposure-review entry. |
 | `A1_DEV_INSTANCE_ID`, `A1_DEV_ROOT` | Caller-supplied development overrides consumed by `src/features/launch/development-launch.ts`; exact existing exposure-review entries. |
-| `A1_PROCESS_GUARDIAN_PATH` | Explicit executable override in `src/foundation/process-containment/native-guardian-containment.ts`, also configured by CI; exact existing exposure-review entry. |
-| `A1_PROBE_TRACE` | Opt-in diagnostics read by native terminal-host code; exact existing exposure-review entry. |
 | `A1_BUILD_VERBOSE`, `A1_DEV_SHELL` | Developer invocation controls in the build helper and development launcher; exact existing exposure-review entries. |
-| `A1_PANE_ID`, `A1_TERMINAL_SESSION_ID` | Reserved compatibility identities retained in the product identity manifest; the resident host does not currently emit them. |
 
 Pending review preserves a possible external interface, not an obsolete private alias. Once a setting is established as private, it cannot keep its branded spelling through that category.
 
@@ -39,19 +36,14 @@ Pending review preserves a possible external interface, not an obsolete private
 
 | Keys | Producer / consumer and value semantics |
 | --- | --- |
-| `LAUNCH_CONTEXT_RELEASE_ROOT`, `LAUNCH_CONTEXT_RELEASE_ID`, `LAUNCH_CONTEXT_RELEASE_DIGEST`, `LAUNCH_CONTEXT_RELEASE_LAYERS` | Release bootstrap writes the selected verified immutable identity; supervision, guardian, and startup/cache readers consume it. Layers are comma-separated and can be empty. |
-| `LAUNCH_CONTEXT_PROFILE` | Bootstrap or the development launcher writes the selected `a1`/`pi` profile; guardian and UI entries consume it. |
+| `LAUNCH_CONTEXT_RELEASE_ROOT`, `LAUNCH_CONTEXT_RELEASE_ID`, `LAUNCH_CONTEXT_RELEASE_DIGEST`, `LAUNCH_CONTEXT_RELEASE_LAYERS` | Release bootstrap writes the selected verified immutable identity; the UI entry and startup/cache readers consume it. Layers are comma-separated and can be empty. |
+| `LAUNCH_CONTEXT_PROFILE` | Bootstrap or the development launcher writes the selected `a1`/`pi` profile; the UI entry consumes it. |
 | `LAUNCH_CONTEXT_WARMUP` | Release warmup writes exactly `1`; the private warmup entry requires it together with release context. |
 | `RELEASE_CLEANUP_HOLDS`, `RELEASE_CLEANUP_RUN_ID` | Cleanup scheduler/worker handoff in `src/foundation/release/release-gc.ts`; serialized holds and a worker run identity. |
 | `SOURCE_LEDGER_PATH`, `SOURCE_LEDGER_SCAN_ROOT`, `SOURCE_LEDGER_PORT_ROOT` | Source-ledger governance fixture overrides; produced by its tests and consumed by `check-pinned-pi-source-ledger.mjs`. |
 | `RELEASE_RUNNER_LABEL` | Release/full-regression workflows supply certification-runner provenance to `run-release-gates.mjs`. |
-| `TERMINAL_FIXTURE_INPUT`, `TERMINAL_FIXTURE_TOKEN` | Native terminal probe producer/consumer in `native/terminal-host/src/main.rs`; expected input and fixture token. |
-| `TERMINAL_HOST_LOCAL_BUILD` | Developer shell sets exactly `1`; `native/terminal-host/build.rs` then permits a Windows build outside CI. |
-| `TERMINAL_HOST_EXPORT_VT` | Native validation lanes in `.github/workflows/ci.yml` name a directory; `build.rs` copies the linked terminal library, headers, and manifest there for upload. |
-| `TERMINAL_HOST_PREBUILT_VT` | Developer shell names a fetched library directory; with `TERMINAL_HOST_LOCAL_BUILD=1` and no `CI`, `build.rs` verifies its manifest and links it instead of running Zig. |
 | `DOCS_AUTO_MERGE_POLL_ATTEMPTS`, `DOCS_AUTO_MERGE_POLL_MS` | Documentation automation polling controls, produced by governance tests and consumed by `manage-documentation-auto-merge.mjs`. |
 | `VALIDATION_JOB_STARTED_MS`, `RENDERING_JOB_STARTED_MS` | CI timing handoffs within `.github/workflows/ci.yml`; epoch milliseconds. |
-| `RUN_PROCESS_CONTAINMENT_INTEGRATION` | CI enables the real containment fixture with exactly `1`; platform containment tests consume it. |
 | `PACKAGE_MESSAGE_SCENARIO` | Package-message worker parent/child JSON scenario handoff. |
 | `RECOVERY_TEST_CANCEL_AFTER`, `RECOVERY_TEST_REMOVAL_MARKER` | Recovery test parent/fake-npm handoff; mutation index and disposable sentinel path. |
 
@@ -61,12 +53,12 @@ The private launch contract is `neutral-launch-v1`, declared by the package's `p
 
 These names are already neutral; their definitions and consumers remain the authority for their existing behavior:
 
-- Development aggregate: `CHANGES_RESULT`, `DOCS_RESULT`, `DOCUMENTATION_RESULT`, `DOCUMENTATION_REQUIRED`, `VALIDATE_RESULT`, `CONTAINMENT_RESULT`, `STARTUP_RESULT`, `RENDERING_RESULT`, `RENDERING_TIER`, `DOCS_ONLY`, `VERSION_ONLY`, `OPENSPEC_TOUCHED`, `SELECTED_HEAD`, `EXPECTED_HEAD`, `EVENT_BASE_SHA`, `EVENT_HEAD_SHA`. The workflow produces these and `require-development-validation.mjs` or the selector consumes them.
+- Development aggregate: `CHANGES_RESULT`, `DOCS_RESULT`, `DOCUMENTATION_RESULT`, `DOCUMENTATION_REQUIRED`, `VALIDATE_RESULT`, `STARTUP_RESULT`, `RENDERING_RESULT`, `RENDERING_TIER`, `DOCS_ONLY`, `VERSION_ONLY`, `OPENSPEC_TOUCHED`, `SELECTED_HEAD`, `EXPECTED_HEAD`, `EVENT_BASE_SHA`, `EVENT_HEAD_SHA`. The workflow produces these and `require-development-validation.mjs` or the selector consumes them.
 - Naming aggregate: `NAMING_RESULT`, `NAMING_REQUIRED`, `NAMING_HEAD`, produced by CI and consumed by the same required aggregate.
 - Validation: `VALIDATION_BUILD_READY`, `VALIDATION_CANDIDATE_TARBALL`, `VALIDATION_DOCUMENTATION_FULL_READY`, `VALIDATION_SELECTION_JSON`, `STARTUP_PERFORMANCE_RESULT`, owned by validation orchestration and exact-package fixtures.
 - Publication workflow-local handoffs: `BUILD`, `EVENT_NAME`, `EXISTS`, `EXPECTED_INTEGRITY`, `EXPECTED_REGISTRY_INTEGRITY`, `EXPECTED_REGISTRY_SHASUM`, `EXPECTED_SHASUM`, `MODE`, `PACKAGE`, `PLAN`, `PUBLISH`, `PULLS_PATH`, `PULL_REQUEST`, `REGISTRY_TARBALL`, `RELEASE_CHANNEL`, `RELEASE_VERSION`, `REQUESTED_CHANNEL`, `REQUESTED_SHA`, `SOURCE_SHA`, `VALIDATE`, `VERSION`, `WORK`, defined and consumed in `.github/workflows/publish.yml`.
-- Isolated fixture controls: `PROMPT_SUGGESTION_AGENT_DIR`, `RUN_PROMPT_SUGGESTION_PROVIDER_TEST`, `TEST_SUPERVISOR_SECRET`, owned by their specific provider/supervisor tests.
-- Host/tool integration: `CARGO`, `ZIG`, `PATH`, `HOME`, `USERPROFILE`, `APPDATA`, `LOCALAPPDATA`, XDG directory variables, `TERM`, `COLORTERM`, `TERM_PROGRAM`, `WT_SESSION`, `EXEPATH`, `MINGW_PREFIX`, `MSYSTEM`, and third-party `PI_*`, `GITHUB_*`, `GH_TOKEN`, and npm variables. Their external spellings and caller values are not private product naming targets. The forwarding of an arbitrary user's environment is distinct from defining an owned setting.
+- Isolated fixture controls: `PROMPT_SUGGESTION_AGENT_DIR`, `RUN_PROMPT_SUGGESTION_PROVIDER_TEST`, owned by their specific provider tests.
+- Host/tool integration: `PATH`, `HOME`, `USERPROFILE`, `APPDATA`, `LOCALAPPDATA`, XDG directory variables, `TERM`, `COLORTERM`, `TERM_PROGRAM`, `WT_SESSION`, `EXEPATH`, `MINGW_PREFIX`, `MSYSTEM`, and third-party `PI_*`, `GITHUB_*`, `GH_TOKEN`, and npm variables. Their external spellings and caller values are not private product naming targets. The forwarding of an arbitrary user's environment is distinct from defining an owned setting.
 
 ### Removed or reclassified registry entries
 
@@ -78,9 +70,9 @@ The old environment registry included `fixture` and `inputAcknowledgement`, but
 
 An update is performed by the release that is already installed, so the contract is negotiated rather than cut over. `neutral-launch-v1` is the only contract this build **writes** for its own releases, and the superseded `A1_RELEASE_*`/`A1_IMMUTABLE_WARMUP` keys are still **read** when an older launcher starts this build, and still **written** when this build starts a retained release that declares no contract. An installation therefore stays launchable across the cutover in both directions, and no user is asked to stop processes and reinstall by hand.
 
-Metadata that predates contract declaration is stale, never fatal. A pre-cutover active record does not stop a launch: it is ignored, the installed payload is materialized, and ordinary cohort selection activates it. A launch that cannot take the installed payload at all — an installation being replaced right now — starts the retained active release instead of failing, and leaves activation to the next launch. What still requires `neutral-launch-v1` outright is narrow and never blocks a launch: the installed package's own manifest must declare it, and an update recovery capsule is never translated.
+Metadata that predates contract declaration is stale, never fatal. A pre-cutover active record does not stop a launch: it is ignored, the installed payload is materialized, and ordinary active-release selection activates it. A launch that cannot take the installed payload at all — an installation being replaced right now — starts the retained active release instead of failing, and leaves activation to the next launch. What still requires `neutral-launch-v1` outright is narrow and never blocks a launch: the installed package's own manifest must declare it, and an update recovery capsule is never translated.
 
-Activation after the global installation is handed over the same way. The package manifest declares `updateActivationContracts` (`activate-v1`) and ships `bin/activate.js`; an updater that serves a declared contract starts that entry with the data directory and the target version and relays its line-delimited progress events (`materializing`, `phase`, `warmup`, `completed`, `failed`) into its own journal and progress bar, while the entry materializes, certifies, warms, and supervises the tree it ships in with that tree's own code. The updater resolves nothing inside the installed tree but `package.json` and that entry; `test/repository-governance/update-activation-contract.test.ts` pins this. A tree that declares no contract the updater serves is activated in-process with the layout it had, which keeps an updater older than the contract and a downgrade to an older preview working.
+Activation after the global installation is handed over the same way. The package manifest declares `updateActivationContracts` (`activate-v1`) and ships `bin/activate.js`; an updater that serves a declared contract starts that entry with the data directory and the target version and relays its line-delimited progress events (`materializing`, `phase`, `warmup`, `completed`, `failed`) into its own journal and progress bar, while the entry materializes, certifies, and warms the tree it ships in with that tree's own code. The updater resolves nothing inside the installed tree but `package.json` and that entry; `test/repository-governance/update-activation-contract.test.ts` pins this. A tree that declares no contract the updater serves is activated in-process with the layout it had, which keeps an updater older than the contract and a downgrade to an older preview working.
 
 `test/foundation/release/update-predecessor.integration.test.ts` is the gate for this. It installs each of the most recent published releases and drives the candidate through **that release's own** materialization and warmup, because a fixture built from the candidate would only prove the candidate agrees with itself. On Windows it also drives the newest predecessor's protected package replacement from a user-style A1 prefix with npm beside a separate Node installation, then exercises the explicit `0.2.2` installer-context bridge. Candidate-only recovery success therefore cannot hide a target-side fix that its installed predecessor cannot reach. No reset or migration runs automatically. If disposable state blocks installation, inspect its resolved paths and obtain separate approval before removal.
 

package/docs/architecture/project-structure.md

@@ -28,13 +28,12 @@ src/
       session-presenters/          pinned Pi selectors and transcript renderers built from engine objects
       tui-runtime/                 neutral presentation runtime over pinned Pi TUI
   foundation/
-    launch-guardian/               authenticated launch-instance coordination
-    lifecycle/                     dependency-free launch, process identity, and path contracts
-    process-containment/           verified native containment and process inspection
-    protocol/                      authenticated control framing and client contracts
-    release/                       immutable releases, update, rollback, cohorts, and cleanup
-    storage/                       control-store persistence
-    supervision/                   endpoint, launch-instance, and release-cohort ownership
+    launch-context/                neutral private launch environment contract
+    lifecycle/                     paths, session selection, and session worktree claims
+    release/                       immutable releases, bootstrap, update, rollback, and age-based cleanup
+    session-writer-lock/           one writer per Pi session file through proper-lockfile
+    startup/                       startup trace phases and startup budgets
+    terminal-cleanup/              bounded terminal reset, exit notice, and fatal-exit diagnostics
   ui/
     apps/                          application registry and host lifecycle
     components/                    vendor-neutral terminal UI primitives
@@ -47,8 +46,6 @@ Three layer boundaries hold regardless of the DAG: `src/contracts/*` import noth
 
 `src/cli` contains command policy but delegates runtime work. `src/composition` is the concrete dependency-injection boundary: it may know both neutral contracts and Pi implementations, while product features receive vendor-neutral ports. Foundation modules never import product features. Pi package knowledge remains inside the Pi adapter owners.
 
-Release-owned endpoint observation and recovery coordinate with supervision-owned publication and storage-owned boot reconciliation through the process guardian's OS-released gates; see [startup recovery](../launch-recovery.md) for the identity, concurrency, and diagnostic boundaries.
-
 Shared code moves to foundation only when it is product-agnostic, has a precise contract, and has more than one real consumer. Do not create `core`, `common`, `utils`, or `misc` dumping grounds.
 
 ## Feature ownership
@@ -89,7 +86,7 @@ Prefer the smallest independent boundary that proves the observable result. Do n
 
 The repository has one root `package.json`, `package-lock.json`, TypeScript configuration, Vitest configuration, and dependency installation. Nested manifests, lockfiles, `node_modules`, vendored package caches, logs, sessions, browser profiles, generated output, and runtime state are forbidden under production and feature trees.
 
-Build output mirrors the production namespaces directly under ignored `dist/`, without an intermediate `src/` directory; generated release/test evidence and agent-selected scratch files belong in ignored `.artifacts/`; task worktrees and local package outputs belong in ignored `.worktrees/` and `.builds/`. Repository tooling is grouped under `scripts/governance`, `scripts/release`, `scripts/pi`, and `scripts/development`; the few root scripts are standalone maintenance or build commands. Package contents are selected by the root manifest. The Rust process guardian and console terminal-host proof live under `native/`; Cargo output is ignored. Third-party terminal parser sources are isolated under `native/terminal-host/vendor/` and are not owned application modules.
+Build output mirrors the production namespaces directly under ignored `dist/`, without an intermediate `src/` directory; generated release/test evidence and agent-selected scratch files belong in ignored `.artifacts/`; task worktrees and local package outputs belong in ignored `.worktrees/` and `.builds/`. Repository tooling is grouped under `scripts/governance`, `scripts/release`, `scripts/pi`, and `scripts/development`; the few root scripts are standalone maintenance or build commands. Package contents are selected by the root manifest. The repository contains no native code; the published package is pure JavaScript.
 
 ## Development worktrees
 
@@ -123,7 +120,7 @@ A stale Git registration elsewhere whose directory is missing and whose row is `
 
 Claude Code uses its established `EnterWorktree` tool by task name. The tracked `.claude/settings.json` wires `scripts/governance/claude-worktree-create.mjs` to create `.worktrees/<task-id>` detached at fresh `origin/develop`, or return an already registered path. The agent must still establish ownership before reusing that path and create the topic branch in a new detached worktree before editing. Passing an absolute `path` to `EnterWorktree` is reserved for a worktree created by hand, from primary before any shell command in that session. The matching `WorktreeRemove` hook declines removal: leave with `ExitWorktree` `keep` and use only the guarded cleanup tool for removal. Other agents do not need these tools or hooks.
 
-A1 linking acquires a cooperative live-session editing claim and switches footer repository/PR discovery; an existing draft PR is not required when linking first succeeds. Clean unlink/disposal releases that runtime claim; a crashed A1 owner becomes reusable only after exact process death is verified. Runtime association does not change process or tool cwd, create a Git lock, or register, release, or authorize cleanup. Context verification and editing handoff also grant no acceptance, finalization, merge, deletion, or cleanup authority. Repository commands therefore keep an explicit worktree path. The primary worktree stays on `develop` for integration and must not be used for task edits. Do not edit, adopt, move, or remove another session's worktree.
+A1 linking acquires a cooperative live-session editing claim and switches footer repository/PR discovery; an existing draft PR is not required when linking first succeeds. Clean unlink/disposal releases that runtime claim; a crashed A1 owner becomes reusable only after its recorded process is no longer running. Runtime association does not change process or tool cwd, create a Git lock, or register, release, or authorize cleanup. Context verification and editing handoff also grant no acceptance, finalization, merge, deletion, or cleanup authority. Repository commands therefore keep an explicit worktree path. The primary worktree stays on `develop` for integration and must not be used for task edits. Do not edit, adopt, move, or remove another session's worktree.
 
 An agent that directly chooses a transient file path for a PR/comment body, command payload, captured output, temporary patch/diff, or ad hoc log must place it beneath the verified task worktree's exact `.artifacts/` root, never the primary checkout, another worktree, OS temp, home/desktop, or a sibling path. Such scratch remains ignored, unstaged, uncommitted, disposable, non-authoritative, and secret-free. This repository path rule does not relocate storage internally selected by tools, product runtime code, or hermetic tests.
 
@@ -140,6 +137,4 @@ An agent that directly chooses a transient file path for a PR/comment body, comm
 
 Both interactive profiles use the owned rendering pipeline. Bare `a1` exposes A1-owned surfaces; `a1 pi` withholds those surfaces while using Pi's ordinary profile root. The retired transparent attachment owner is not part of the production tree or dependency map.
 
-The current JavaScript control plane does not provide arbitrary-CLI tabs. Such tabs require the separately bounded console terminal host to own PTYs, authoritative terminal state, rendering, input routing, inactive-surface lifecycle, and reconnection. JavaScript may exchange typed identity, topology revision, capability, lifecycle, status, and recovery messages only; it must not relay terminal output, per-event child input, or rendered cells.
-
-Structured agents remain semantically separate and use typed events, commands, snapshots, cancellation, and recovery evidence. They must not derive state from ANSI text, terminal timing, or screen content. Native source ownership remains outside `src/`; packaged host selection is governed by release/package owners. Architecture tests reject terminal-host hot-path bytes in JavaScript protocols, terminal inference in structured runtimes, and replacement lightweight terminal parsers or renderers.
+Each launch runs one agent in one directly attached process; there are no tabs, resident sessions, or arbitrary-CLI terminal surfaces. Production code under `src/` may not import `node-pty` or a terminal emulator or spawn a pseudoterminal, and the architecture gate rejects replacement lightweight terminal parsers or renderers. A multi-agent or composed-terminal feature needs its own approved change.

package/docs/architecture/resource-and-data-policy.md

@@ -1,32 +1,21 @@
-# Multi-agent resource and data policy
+# Resource and data policy
 
-This policy is mandatory for the multi-agent workspace. It prevents one adapter, terminal pane, recovery record, or proof artifact from exhausting the workspace and prevents accidental persistence of credentials or terminal streams.
+This policy bounds what one A1 process may queue, retain, or persist, and prevents accidental persistence of credentials or terminal content. A1 runs one agent per directly attached process; it keeps no control store, workspace registry, or terminal model of its own.
 
 ## Resource budgets
 
-Budgets are minimum defaults, not promises of capacity. An implementation may lower them per agent, adapter, pane, host, or platform, but may not silently remove a limit.
+Budgets are minimum defaults, not promises of capacity. An implementation may lower them per feature or platform, but may not silently remove a limit.
 
 | Resource | Default budget | Required outcome on breach |
 |---|---:|---|
-| Structured event payload | 64 KiB | Reject only that event and preserve diagnostics |
-| Structured snapshot payload | 1 MiB | Reject resynchronization and mark the agent degraded |
-| Structured attachment payload | 2 MiB | Reject only that attachment |
-| Queued structured events per agent | 256 | Apply negotiated pause, rejection, compaction, or disconnect |
-| Concurrent structured commands per agent | 4 | Reject or queue deterministically with a capability explanation |
-| Reconnect replay per adapter | 1,024 events | Stop replay, request a snapshot if available, or mark discontinuity |
-| Native-host control message | 1 MiB | Close the incompatible protocol channel without touching panes |
-| Native topology nodes per tab | 1,024 | Reject the topology mutation atomically |
-| Terminal sessions per host | 64 | Reject additional sessions as unsupported capacity |
-| Terminal launch arguments | 1,024 | Reject that launch request |
-| Terminal environment entries | 512 | Reject that launch request |
-| Retained terminal model per pane | Host-defined, always bounded | Apply documented compaction, backpressure, pause, or termination |
-| Scrollback per pane | Host-defined, always bounded | Compact from oldest data first without cross-pane mutation |
-| Proof evidence file | 16 MiB | Reject and request summarized evidence |
 | Diagnostic payload | 256 KiB | Redact, truncate, and retain enough evidence for the failed operation |
+| Fatal-exit records | 10 records of 16 KiB each | Drop the oldest record; never retain prompt or input content |
+| Evidence file | 16 MiB | Reject and request summarized evidence |
 | Packaged release-note resource | 1 MiB total; 128 KiB per note | Reject the damaged resource and retain the note as unacknowledged |
 | Release-note acknowledgement/claim | 4 KiB per profile; one claim; one-hour stale bound | Ignore malformed acknowledgement, recover stale claim, and never acknowledge implicitly |
+| Session writer lock | one writer per session file; 10-second stale bound | Refuse a second writer and offer a fork; reclaim a stale lock after the bound |
 
-Every asynchronous consumer must implement a finite queue or window. Backpressure must isolate the offending agent/pane and must not block unrelated identities.
+Every asynchronous consumer must implement a finite queue or window. Backpressure must isolate the offending operation and must not block unrelated sessions or processes.
 
 Stable release-note preparation generates Pi-style Markdown with a
 `## [version] - YYYY-MM-DD` heading and applicable categorized `###` sections. Human
@@ -40,13 +29,11 @@ and total catalog limits apply when the snapshot is combined with committed hist
 
 | Class | Examples | Storage policy |
 |---|---|---|
-| Workspace metadata | IDs, names, lifecycle, capability versions, topology revisions, recovery references | May persist in the control store |
+| Release and update state | Immutable release records, update transaction journal, retention timestamps | May persist in A1's data directory; never stores session content or credentials |
 | Release-note state | Last acknowledged stable A1 version and opaque bounded claim token/time | May persist atomically in profile-isolated A1 configuration; never stores note text or Pi settings |
-| Structured payloads | Messages, tool calls, snapshots, attachments | Bound and process; arbitrary payload persistence remains unsupported |
-| User-authored prompt recall | Canonical interactive input and bounded provenance | May persist only through the profile-isolated prompt-history policy below, never in the control store |
-| Terminal content | PTY bytes, scrollback, selection, rendered cells | Never persist in A1's control store or diagnostics |
-| Host topology metadata | Window/tab/pane/session IDs, layout shape, dimensions, revision | May persist; not terminal content |
-| Native proof evidence | Artifact hashes, source revisions, workloads, latency/resource measurements, paint diagnostics | May persist in versioned evidence files without terminal content |
+| Session worktree claims | Runtime and agent identity, process ID, canonical worktree path | May persist under A1 state; not terminal content |
+| User-authored prompt recall | Canonical interactive input and bounded provenance | May persist only through the profile-isolated prompt-history policy below |
+| Terminal content | Terminal bytes, scrollback, selection, rendered cells | Never persist in A1 state or diagnostics |
 | Environment values | `PATH`, profile overrides, arbitrary launch environment | Do not persist; treat as potentially sensitive |
 | Credentials and tokens | API keys, OAuth tokens, cookies, auth files, passwords | Never copy, log, or persist outside the owning agent/profile |
 | Authentication state | Pi profile auth, provider sessions, platform keychains | Owned only by the selected agent/profile |
@@ -81,12 +68,10 @@ retention, failure semantics, profile identity, and stopped-instance removal.
 
 ## Required architectural outcomes
 
-- Structured/RPC semantics must not be inferred from ANSI text, terminal timing, or visual content.
-- Native-host protocol code must not carry PTY bytes, per-event child input, rendered cells, cell grids, framebuffers, or screen buffers.
-- `a1 pi` must not import, initialize, launch, or connect to composed terminal-host infrastructure.
-- Transparent direct attachment must remain independent of composed infrastructure and must not relay terminal data.
-- Recovery records store identity and bounded references, not terminal streams, authentication material, or arbitrary environment values.
-- A failed in-terminal 2×2 proof cannot be waived to merge composed infrastructure.
-- Proof automation must not launch, focus, drive, resize, or close terminal applications on an active workstation.
+- Agent semantics must not be inferred from ANSI text, terminal timing, or visual content.
+- No module may own a pseudoterminal, emulate a terminal, or relay terminal bytes between the user's terminal and the UI.
+- `a1 pi` uses the same directly attached pipeline with A1 surfaces withheld and never persists A1-owned state into the Pi profile.
+- Persisted records store identity and bounded references, not terminal streams, authentication material, or arbitrary environment values.
+- Test automation must not launch, focus, drive, resize, or close terminal applications on an active workstation.
 
 The executable repository policy tests cover these invariants alongside the architecture checker.

package/docs/architecture/toolchain.md

@@ -9,7 +9,8 @@ Exact package versions are recorded in `package-lock.json`.
 | Node.js | `>=22.19.0` |
 | Package manager | npm 11, lockfile v3 |
 | Language | TypeScript, strict native ESM, `NodeNext`, ES2023 |
-| Control storage | Built-in `node:sqlite` `DatabaseSync`, WAL mode |
+| Prompt history storage | Built-in `node:sqlite` `DatabaseSync`, WAL mode |
+| Session writer and worktree claim locks | `proper-lockfile` |
 | Process/version helpers | `cross-spawn`, `semver` |
 | Tests | Vitest |
 
@@ -23,24 +24,20 @@ Physical desktop automation is absent from the active repository baseline. Any f
 
 ## Package contents
 
-The published package contains:
+The published package is pure JavaScript and contains:
 
-- the sole public `a1` command;
-- the internal supervisor, launch-guardian, exit-watcher, and fixed terminal-host role entries;
-- immutable release/bootstrap, lifecycle, protocol, storage, update, owned-UI, and Pi-adapter modules, plus `process-guardian.node` and `terminal-host.node` for every supported target with manifests and terminal-host notices;
+- the sole public `a1` command and its directly attached `bin/ui.js` entry;
+- the internal activation, warmup, automatic-update, update-recovery, and release-cleanup entries;
+- immutable release/bootstrap, lifecycle, session-writer-lock, update, owned-UI, and Pi-adapter modules;
 - current user and architecture documentation.
 
-It contains no executable built from A1 sources, separate session-lock addon, browser/desktop GUI, physical automation driver, or generated runtime data. PTY ownership, terminal emulation, composition, and input translation exist only inside the terminal-host addon; the JavaScript product path does not relay terminal bytes.
+It contains no native addon, executable built from A1 sources, browser/desktop GUI, physical automation driver, or generated runtime data. No module owns a pseudoterminal, emulates a terminal, or relays terminal bytes; the UI child inherits the terminal directly.
 
-## Native addon layer
+## Build
 
-`npm run doctor` reports this contract against the current machine—Node range, npm major, git, the GitHub CLI, Rust/Cargo, Windows Microsoft C++ readiness where applicable, and whether `node_modules` matches the lockfile—and names the explicit setup action for anything missing. `npm run build` resolves the same native environment and runs the check before cleaning or compiling, so an unmet prerequisite fails by name rather than inside a module resolver, Cargo, or the linker. Unmet tool prerequisites block; a Node or npm version outside the declared contract is reported as an advisory without failing the build.
+`npm run doctor` reports this contract against the current machine—Node range, npm major, git, the GitHub CLI, and whether `node_modules` matches the lockfile—and names the explicit setup action for anything missing. `npm run build` runs the same check before compiling, so an unmet prerequisite fails by name rather than inside a module resolver. Unmet tool prerequisites block; a Node or npm version outside the declared contract is reported as an advisory without failing the build.
 
-Source builds require Rust/Cargo 1.85 or newer; `rust-toolchain.toml` pins the exact version CI and publication install through `scripts/development/prepare-ci-rust.sh`, and rustup selects that version for Cargo commands inside the repository, installing it on first use. On Windows, the resolver honors explicit `CARGO` and `RUSTC` executables, then the launching `PATH`, then `%USERPROFILE%\.cargo\bin`; the fallback changes only build-child state. Windows native linking also requires Visual Studio or Visual Studio Build Tools with the Desktop development with C++ workload, MSVC x64/x86 tools, and a Windows SDK. Visual Studio Code is not a compiler prerequisite. An already valid developer environment is retained; otherwise the resolver uses the installed stable Visual Studio locator and `vcvars64.bat`, verifies that `cl.exe` and Microsoft's `link.exe` come from the selected VC tools, and passes the captured environment only to child processes. This prevents Git Bash's GNU `link.exe` from shadowing MSVC without changing persistent `PATH`. A1 never installs these tools, elevates privileges, or accepts licenses automatically. The Zig cache (`mlugg/setup-zig`, one entry per workflow and platform per run, bounded to 512 MiB) stays enabled: measured on 2026-10-16, a cold Zig build of `libghostty-vt` added about 40 to 60 seconds to a terminal-host test build (Linux 2m21s cold against 1m20s warm, Windows 2m05s against 1m26s), which the cache saves on every warm run.
-
-`npm run build` compiles `native/process-guardian` as the host platform's Node-API 9 addon, places `process-guardian.node` under `dist/native/<platform>-<architecture>/`, loads it to observe its version identity, and writes the v2 integrity manifest. It also builds the current platform's release-profile `terminal-host.node`, whose v2 manifest binds the addon, `dist/foundation/resident-tabs/host-entry.js`, and notices, so the ordinary `npm run build && ./scripts/dev` handoff exercises resident tabs without deployment. On Windows the normal build reuses a compatible ignored terminal-library cache or downloads the newest compatible library from the current branch or a successful CI run belonging to a pull request already merged into `develop`, then links it under the crate's manifest verification; it never silently invokes the quarantined Zig package fetch. An unavailable or mismatched prerequisite fails the build instead of leaving a nominally successful single-agent-only tree. The npm `prepare` lifecycle and validation preflight use the explicit core build because selected native lanes assemble and certify terminal hosts separately.
-
-Preview and stable candidate workflows build the addons on isolated Windows, Linux, and macOS arm64 runners, cross-compile the macOS x64 addons on the arm64 runner with `--target x86_64-apple-darwin`, and assemble all targets before packing. Those release runners retain their explicit `npm run build:terminal-host` step and pinned Zig input rather than consuming a workstation cache; Development validation lanes may instead restore a CI-built release addon from an exact-input cache and re-verify it (see [`../ci-release-runbook.md`](../ci-release-runbook.md)). Cross-compiled artifacts record a Mach-O architecture check when they cannot be loaded on the producing runner. Supported native code is always loaded by Node; an absent, incompatible, or unsupported addon fails before runtime startup rather than falling back to PID-only cleanup. The process-guardian addon inherits terminal handles but transports no terminal bytes. Its separate Node-hosted exit watcher restores terminal state after guardian failure, subject to the documented node-wide-kill gap. See [`process-guardian-provenance.md`](process-guardian-provenance.md), [`terminal-host-provenance.md`](terminal-host-provenance.md), and [`resident-tabs.md`](resident-tabs.md).
+`npm run build` compiles TypeScript, runs the existing resource generators, and writes the runtime payload inventory. The npm `prepare` lifecycle runs the same build. Preview and stable candidate workflows pack the built tree once and validate those exact bytes on Windows, Linux, and macOS; there are no per-platform artifacts.
 
 ## Gates
 
@@ -89,19 +86,17 @@ One reusable workflow publishes both npm channels: `.github/workflows/publish.ym
 
 ## A1 state paths
 
-These paths are A1 control and release state, not Pi profile roots. All are overrideable for hermetic tests.
+These paths are A1 release, update, and runtime state, not Pi profile roots. All are overrideable for hermetic tests.
 
 | Purpose | Override | Windows default | Unix default |
 |---|---|---|---|
 | Config | `A1_CONFIG_DIR` | `%APPDATA%\\a1` | `$XDG_CONFIG_HOME/a1` or `~/.config/a1` |
-| Control/release data | `A1_DATA_DIR` | `%LOCALAPPDATA%\\a1` | `$XDG_DATA_HOME/a1` or `~/.local/share/a1` |
+| Release data | `A1_DATA_DIR` | `%LOCALAPPDATA%\\a1` | `$XDG_DATA_HOME/a1` or `~/.local/share/a1` |
 | Runtime | `A1_RUNTIME_DIR` | `%LOCALAPPDATA%\\a1\\runtime` | `$XDG_RUNTIME_DIR/a1` or `<data>/runtime` |
-| Database | `A1_DATABASE_PATH` | `<data>/control.sqlite3` | `<data>/control.sqlite3` |
-| Endpoint | `A1_ENDPOINT` | runtime-scoped `a1-*` named pipe | `<runtime>/supervisor.sock` |
 
 ### Identity hard cut and cleanup
 
-A1 does not read or migrate legacy `ADDONE_*` variables, `AddOne`/`addone` control-state directories, release manifests, database schemas, endpoint records, or protocol frames. Remove obsolete control state only after stopping old processes: `%APPDATA%\\AddOne` and `%LOCALAPPDATA%\\AddOne` on Windows, or the former `addone` directories under XDG config, data, and runtime roots on Unix. This cleanup is manual and never imports data into A1.
+A1 does not read or migrate legacy `ADDONE_*` variables, `AddOne`/`addone` control-state directories, release manifests, or schemas. Remove obsolete control state only after stopping old processes: `%APPDATA%\\AddOne` and `%LOCALAPPDATA%\\AddOne` on Windows, or the former `addone` directories under XDG config, data, and runtime roots on Unix. This cleanup is manual and never imports data into A1.
 
 Do **not** remove `~/.a1/agent`; it is A1's current Pi profile root. `~/.pi/agent` remains the vanilla Pi profile.
 
@@ -118,7 +113,7 @@ The required PR naming job inspects complete new and changed source files. `npm
 Prompt history has a separate default: `<effective-home>/.a1/data/history/<profile-id>.sqlite3`
 on Windows, Linux, and macOS. The effective home follows launch-profile resolution
 (`A1_PROFILE_HOME` or the OS home), not `XDG_DATA_HOME`. An explicit `A1_DATA_DIR`
-continues to select `<A1_DATA_DIR>/history` as well as the control/release data root.
+continues to select `<A1_DATA_DIR>/history` as well as the release data root.
 The home-based history default does not relocate the paths above or the compile
 cache at `<data>/cache/compile`. See [prompt history](../features/prompt-history.md)
 for the deliberate fresh start without migration, privacy, and manual removal.

package/docs/architecture/ui-reference-provenance.md

@@ -6,8 +6,8 @@ decisions, and the decisions are where the work is: column arithmetic, sticky-he
 reservation, block-jump targets, span overlay under styling, and pointer hit regions.
 
 This file records what came from where, so a divergence can be judged against its source
-instead of argued from memory. It is the same discipline as
-[`terminal-host-provenance.md`](terminal-host-provenance.md), applied to UI source.
+instead of argued from memory. It applies the same discipline as
+[`history-editor-provenance.md`](history-editor-provenance.md) to UI source.
 
 ## Source
 

package/docs/ci-release-runbook.md

@@ -103,7 +103,7 @@ The real three-release `update-predecessor` scenario is exhaustive because its f
 
 Development outcomes report each owner/scope invocation separately while sharing authenticated build/package preparation. The aggregate reports setup, scope, job, aggregate-processing, total runner, and runner-critical-path durations. The acceptance targets are at most eight minutes of runner critical path and five minutes for one PR-required scope; an over-target result remains unmet without retries, timeout increases, workload reduction, or mutable installation caches. Hosted queue time is reported separately when available and is not counted as test execution.
 
-Candidate-packing Development lanes restore the release `terminal-host.node`, its manifest, and its third-party notices from an exact-input `actions/cache` entry keyed by the native tree, `rust-toolchain.toml`, the provenance configuration, the build scripts, the pinned Zig version, and the runner image. On a hit the lane skips the Rust toolchain, Zig, and `cargo` build steps, re-records the manifest's `host-entry.js` digest from the current TypeScript build (`build-terminal-host.mjs --reuse`), and still runs `verify-native-artifacts.mjs --local` before the build receipt; any tampered or mismatched restored file fails the lane instead of rebuilding. A miss builds as before and saves the result. This is build-output reuse with a complete input key, not a mutable installation cache, and publication lanes keep building in-run. Before this reuse, each `packs_candidate` lane spent 2.6 to 3.4 minutes on the release build, and a resident-tabs pull request repeated it in four lanes. Likewise the Linux terminal-host lane caches the `cargo-fuzz 0.13.2` binary by version and nightly date instead of compiling it each run, and the three terminal-host partition jobs run only their `role_integration` slice, so the crate's unit tests execute once per target per run rather than four times.
+Candidate-packing Development lanes build the pure-JavaScript product once per lane with `npm run build` and record the build receipt; there is no native artifact to build, cache, restore, or certify.
 
 Inspect local committed and worktree impact without running tests:
 
@@ -127,7 +127,7 @@ Rendering evidence captures each selected producer/mode/workload matrix once and
 
 ## Resource-sensitive fast validation
 
-The authoritative fast-tier declaration identifies tests that repeatedly create temporary repositories, launch child processes, mutate storage, or coordinate release cohorts. The planner removes those files from the parallel remainder and runs them exactly once in one serial `vitest-fast-resource-sensitive` process with file parallelism disabled, on an isolated runner that no other partition shares. One process instead of one per file removes about twenty cold starts from the partition; each file still gets a fresh module context. Pull-request, development-package, and complete release plans use the same partition on every platform.
+The authoritative fast-tier declaration identifies tests that repeatedly create temporary repositories, launch child processes, or mutate release and update state. The planner removes those files from the parallel remainder and runs them exactly once in one serial `vitest-fast-resource-sensitive` process with file parallelism disabled, on an isolated runner that no other partition shares. One process instead of one per file removes about twenty cold starts from the partition; each file still gets a fresh module context. Pull-request, development-package, and complete release plans use the same partition on every platform.
 
 The partition runs under an explicit `--testTimeout=30000`, the same hang bound the other explicit fast-tier invocations use. That bound is a hang detector, not a performance gate: shared Windows runners vary by a factor of two or more for identical work, and a fixed five-second wall-clock limit failed passing suites on runner noise. Per-test durations remain in the reporter evidence; `scripts/release/report-resource-sensitive-validation.mjs` records repeated executions and lists every test body above five seconds under `slowTests` so a real slowdown is visible without failing the pull request. A failure is still not retried or converted to success, and the bound is not raised to create margin.
 
@@ -154,7 +154,7 @@ For applicable code changes, it requires the dedicated Defender-enabled exact-pa
 | Windows Node 22 | Required for applicable changes | Not scheduled | Retained | Retained |
 | Windows Node 24 | Not scheduled | Retained | Retained | Retained |
 
-Each selected startup lane runs the package-install scenarios once: a failed budget remains failed and is never retried to obtain a warmed result. The budgets are the ones the `a1-shell` capability declares (2 seconds after an update and on a warm launch, 2.5 seconds with no live supervisor); development validation, development previews, nightly publication, and Full regression record an overrun as a warning and are judged by the three-run persistent-overrun verdict, while stable candidate validation fails on it (see `STARTUP_BUDGET_ENFORCEMENT` in [validation](validation.md)). The publication lane set comes from `scripts/release/publication-validation-matrix.mjs`: a numbered preview validates on the Windows, Linux, and macOS Node 24 lanes, and nightly covers the same head on Windows Node 22 within a day. Node 24 runtime support, other PR jobs, Defender, and publication gates are unchanged. Full validation retains every deferred startup, image, and history test through its existing suite owners.
+Each selected startup lane runs the package-install scenarios once: a failed budget remains failed and is never retried to obtain a warmed result. The budgets are the ones the `a1-shell` capability declares (2 seconds after an update and on a warm launch, 2.5 seconds on a restart-equivalent launch); development validation, development previews, nightly publication, and Full regression record an overrun as a warning and are judged by the three-run persistent-overrun verdict, while stable candidate validation fails on it (see `STARTUP_BUDGET_ENFORCEMENT` in [validation](validation.md)). The publication lane set comes from `scripts/release/publication-validation-matrix.mjs`: a numbered preview validates on the Windows, Linux, and macOS Node 24 lanes, and nightly covers the same head on Windows Node 22 within a day. Node 24 runtime support, other PR jobs, Defender, and publication gates are unchanged. Full validation retains every deferred startup, image, and history test through its existing suite owners.
 
 The trade-off is delayed detection: a Node-24-specific regression can reach `develop` before nightly catches it, and the same is true for a real published-predecessor regression. A green bounded PR check does not certify Node 24 or real historical predecessor execution, and nightly failure still blocks its publication. For an unselected candidate or diagnosis, explicitly request the non-publishing standalone Full regression workflow for the desired branch or tag:
 
@@ -333,10 +333,10 @@ extra-path, wrong-body, or ambiguous work is refused. An existing reopening bran
 without that exact PR is preserved rather than overwritten. The local preparation
 checkout is never committed, reset, or used to publish package bytes.
 
-Candidate validation builds the process guardian on all supported platforms, stamps
+Candidate validation builds the product, stamps
 the version, packs each package once, runs the complete stable suite against those
 bytes on Windows, Linux, and macOS, and retains the pair for 30 days as
-`release-package-<version>`. Stable publication skips the guardian builds and
+`release-package-<version>`. Stable publication skips the build and
 validation lanes, adopts that retained pair, publishes both to npm `latest` with
 provenance from the `npm-publish` environment, and exercises the exact published
 installer/application pair in isolated prefixes on every release lane. Only after