@timurproko/a1 0.2.6 → 0.2.7-dev.1221

package/docs/architecture/boundaries.md

@@ -7,23 +7,24 @@ Every interactive command uses this profile-neutral lifecycle path:
 ```text
 mutable a1 entry
   -> verified immutable release
-  -> Node launch guardian and authenticated launch-instance registration
-  -> native process guardian and per-instance containment
-  -> profile-aware owned-UI runtime selection
+  -> Node launch guardian loading the verified process-guardian addon
+  -> addon-held per-instance containment and profile-aware runtime selection
   -> 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.
 
-Neither guardian reads ordinary terminal input, parses or relays runtime output, renders cells, infers frames, synthesizes terminal responses, or emits display control. 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 private guardian boundary carries only bounded identity, readiness, stop, and outcome data.
+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.
+
+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.
 
 ## Current module responsibilities
 
 - `lifecycle`: dependency-free launch-instance, process identity, state transition, outcome, and control-command contracts.
-- `process-containment`: artifact verification, OS-verifiable process inspection, containment adapters, and bounded graceful/forced cleanup; it owns no terminal content.
-- `launch-guardian`: one profile-neutral instance coordinator above runtime selection.
+- `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.
@@ -32,17 +33,31 @@ The owned Pi-backed surface is not an arbitrary-CLI terminal multiplexer. A feat
 - `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.
 - `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, process-guardian integrity, cohort selection, durable update transactions, rollback, and dependency-light command entry. After an unsuccessful bare-A1 child exit, the bootstrap restores owned terminal modes; neither guardian emits terminal controls.
+- 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 native boundary and is independent from the held composed terminal host.
+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.
 
 `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/`.
+
+## 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:
+
+- 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.
+- A count that shrinks, or a unit that falls below every threshold, fails until `node scripts/governance/update-size-ratchet.mjs` lowers or removes the entry. That script never adds or raises an entry; `--check` reports without writing.
+
+The measurement in `scripts/governance/size-ratchet-policy.mjs` masks strings, comments, and regular expressions and counts braces, so it needs no build; a file whose braces do not balance is reported rather than mismeasured. Keys are `<path>::<Class>`, `<path>::<Class>.<method>`, or `<path>::<Type>::<fn>`, so moving or renaming a unit means moving its entry.
+
 ## 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:
@@ -61,7 +76,7 @@ Default future agents and composed hosts are children of the originating bare-`a
 
 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 terminal-host protocol boundary may carry only bounded typed control and semantic lifecycle messages. Pseudoterminal bytes, per-event child input, rendered cells, cell grids, framebuffers, and screen buffers are forbidden across it. Console host executables and packaging live outside the current JavaScript production owners and remain unavailable until the isolated in-terminal proof passes; replacing them 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.
+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.
 

package/docs/architecture/evidence/resident-tabs/linux-x64.md

@@ -0,0 +1,37 @@
+# Resident tabs acceptance: Linux x64
+
+State: CI-verified
+
+Physical acceptance against a published candidate package is pending; the operator runs [the checklist](../../../manual-resident-tabs-acceptance.md) and fills in this record. Until every item passes, resident tabs on this platform are CI-verified, not certified.
+
+| Field | Value |
+|---|---|
+| Package version | pending (first published candidate carrying the terminal host) |
+| terminal-host SHA-256 | pending (from that package's `terminal-host.manifest.json`) |
+| OS build | pending |
+| Terminal | pending |
+| Operator or worker | pending |
+| Date | pending |
+
+## Automated evidence
+
+- Pull-request `terminal-host` lane on `ubuntu-24.04`: native unit and role-integration suites, every named crash point recovering to a clean start, the 10,000-schedule simulation corpus, `a1 tabs` maintenance end to end, and the release build of the terminal host with its manifest, session lock, and notices.
+- Pull-request `resident-chaos` lane on `ubuntu-24.04`: bounded randomized kills of servers, holders, and agents against the release-built host, with no duplicate tabs or holders and no orphaned processes.
+- Publication `terminal_hosts` job on `ubuntu-24.04`: the release artifact is rebuilt, its `--version` identity checked, and packing refuses a missing or altered artifact.
+- Bounded fuzzing of every decoder and parser runs on this lane; it proves parser robustness, not platform behavior.
+
+## Physical verdicts
+
+| # | Item | Verdict | Notes |
+|---|---|---|---|
+| 1 | Terminal close mid-turn | pending |  |
+| 2 | SSH or remote-session loss | pending |  |
+| 3 | Forced attach-client kill | pending |  |
+| 4 | Reattach fidelity | pending |  |
+| 5 | Input and render smoothness | pending |  |
+| 6 | Extension text UI | pending |  |
+| 7 | Two clients and controller transfer | pending |  |
+| 8 | Server, holder, and child failure | pending |  |
+| 9 | Sensitive-data separation | pending |  |
+| 10 | Conflict-safe direct rollback | pending |  |
+| 11 | Logout (Linux) | pending |  |

package/docs/architecture/evidence/resident-tabs/macos-arm64.md

@@ -0,0 +1,36 @@
+# Resident tabs acceptance: macOS arm64
+
+State: CI-verified
+
+Physical acceptance against a published candidate package is pending; the operator runs [the checklist](../../../manual-resident-tabs-acceptance.md) and fills in this record. Until every item passes, resident tabs on this platform are CI-verified, not certified.
+
+| Field | Value |
+|---|---|
+| Package version | pending (first published candidate carrying the terminal host) |
+| terminal-host SHA-256 | pending (from that package's `terminal-host.manifest.json`) |
+| OS build | pending |
+| Terminal | pending |
+| Operator or worker | pending |
+| Date | pending |
+
+## Automated evidence
+
+- Pull-request `terminal-host` lane on `macos-15`: native unit and role-integration suites, every named crash point recovering to a clean start, the 10,000-schedule simulation corpus, `a1 tabs` maintenance end to end, and the release build of the terminal host with its manifest, session lock, and notices.
+- Pull-request `resident-chaos` lane on `macos-15`: bounded randomized kills of servers, holders, and agents against the release-built host, with no duplicate tabs or holders and no orphaned processes.
+- Publication `terminal_hosts` job on `macos-15`: the release artifact is rebuilt, its `--version` identity checked, and packing refuses a missing or altered artifact.
+
+## Physical verdicts
+
+| # | Item | Verdict | Notes |
+|---|---|---|---|
+| 1 | Terminal close mid-turn | pending |  |
+| 2 | SSH or remote-session loss | pending |  |
+| 3 | Forced attach-client kill | pending |  |
+| 4 | Reattach fidelity | pending |  |
+| 5 | Input and render smoothness | pending |  |
+| 6 | Extension text UI | pending |  |
+| 7 | Two clients and controller transfer | pending |  |
+| 8 | Server, holder, and child failure | pending |  |
+| 9 | Sensitive-data separation | pending |  |
+| 10 | Conflict-safe direct rollback | pending |  |
+| 11 | Logout (Linux) | not applicable | Linux-only item. |

package/docs/architecture/evidence/resident-tabs/macos-x64.md

@@ -0,0 +1,35 @@
+# Resident tabs acceptance: macOS x64
+
+State: CI-verified
+
+Physical acceptance against a published candidate package is pending; the operator runs [the checklist](../../../manual-resident-tabs-acceptance.md) and fills in this record. Until every item passes, resident tabs on this platform are CI-verified, not certified.
+
+| Field | Value |
+|---|---|
+| Package version | pending (first published candidate carrying the terminal host) |
+| terminal-host SHA-256 | pending (from that package's `terminal-host.manifest.json`) |
+| OS build | pending |
+| Terminal | pending |
+| Operator or worker | pending |
+| Date | pending |
+
+## Automated evidence
+
+- Publication `terminal_hosts` and `guardians` jobs on `macos-15` (arm64): the release terminal host and process guardian are cross-compiled for Intel macOS with `--target x86_64-apple-darwin`, the host's `--version` identity is checked through Rosetta 2 when the runner can execute it (otherwise the manifest records a Mach-O architecture check), and packing refuses a missing or altered artifact. Before 2026-10-16 the same builds ran natively on `macos-15-intel`.
+- Known gap: the pull-request `terminal-host` and `resident-chaos` suites run on macOS arm64 only, because modular validation outcomes are keyed by platform without architecture. Intel macOS has build and identity evidence but no automated behavior suite of its own.
+
+## Physical verdicts
+
+| # | Item | Verdict | Notes |
+|---|---|---|---|
+| 1 | Terminal close mid-turn | pending |  |
+| 2 | SSH or remote-session loss | pending |  |
+| 3 | Forced attach-client kill | pending |  |
+| 4 | Reattach fidelity | pending |  |
+| 5 | Input and render smoothness | pending |  |
+| 6 | Extension text UI | pending |  |
+| 7 | Two clients and controller transfer | pending |  |
+| 8 | Server, holder, and child failure | pending |  |
+| 9 | Sensitive-data separation | pending |  |
+| 10 | Conflict-safe direct rollback | pending |  |
+| 11 | Logout (Linux) | not applicable | Linux-only item. |

package/docs/architecture/evidence/resident-tabs/windows-x64.md

@@ -0,0 +1,36 @@
+# Resident tabs acceptance: Windows x64
+
+State: CI-verified
+
+Physical acceptance against a published candidate package is pending; the operator runs [the checklist](../../../manual-resident-tabs-acceptance.md) and fills in this record. Until every item passes, resident tabs on this platform are CI-verified, not certified.
+
+| Field | Value |
+|---|---|
+| Package version | pending (first published candidate carrying the terminal host) |
+| terminal-host SHA-256 | pending (from that package's `terminal-host.manifest.json`) |
+| OS build | pending |
+| Terminal | pending |
+| Operator or worker | pending |
+| Date | pending |
+
+## Automated evidence
+
+- Pull-request `terminal-host` lane on `windows-2025`: native unit and role-integration suites, every named crash point recovering to a clean start, the 10,000-schedule simulation corpus, `a1 tabs` maintenance end to end, and the release build of the terminal host with its manifest, session lock, and notices.
+- Pull-request `resident-chaos` lane on `windows-2025`: bounded randomized kills of servers, holders, and agents against the release-built host, with no duplicate tabs or holders and no orphaned processes.
+- Publication `terminal_hosts` job on `windows-2025`: the release artifact is rebuilt, its `--version` identity checked, and packing refuses a missing or altered artifact.
+
+## Physical verdicts
+
+| # | Item | Verdict | Notes |
+|---|---|---|---|
+| 1 | Terminal close mid-turn | pending | Milestone 2 passed this item against development build `09028be5` (run 38159593912); that evidence is for that build, not this package. |
+| 2 | SSH or remote-session loss | pending | Milestone 2 passed Windows OpenSSH loss against development build `09028be5`; it is not evidence for this package. |
+| 3 | Forced attach-client kill | pending |  |
+| 4 | Reattach fidelity | pending |  |
+| 5 | Input and render smoothness | pending |  |
+| 6 | Extension text UI | pending |  |
+| 7 | Two clients and controller transfer | pending |  |
+| 8 | Server, holder, and child failure | pending |  |
+| 9 | Sensitive-data separation | pending |  |
+| 10 | Conflict-safe direct rollback | pending |  |
+| 11 | Logout (Linux) | not applicable | Linux-only item. |

package/docs/architecture/internal-naming.md

@@ -31,7 +31,7 @@ The exact externally branded key/member authority is `config/internal-naming-pol
 | `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` | Produced by `native/terminal-host/src/workspace.rs` and exported to launched programs; external integration names, unchanged. |
+| `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.
 
@@ -47,6 +47,8 @@ Pending review preserves a possible external interface, not an obsolete private
 | `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/docs/architecture/process-guardian-provenance.md

@@ -1,27 +1,35 @@
 # Process guardian provenance
 
-A1 launch-instance containment uses a standalone native executable named `process-guardian`. The approved implementation is a separate Rust crate at `native/process-guardian`; it is not a Node-API addon and does not reuse or resume the held composed terminal-host implementation.
+A1 launch-instance containment uses the Node-API 9 addon `process-guardian.node`. The approved implementation is the separate Rust crate at `native/process-guardian`; it produces no product executable. The foreground Node launch guardian loads the addon and holds the containment boundary in-process.
 
 ## Boundary
 
-The executable owns platform process containment and launches one immutable `a1-ui` runtime with inherited terminal handles. It does not create a PTY, read ordinary terminal input, capture or parse runtime output, render, or relay terminal bytes. Its private parent/child coordination is restricted to bounded lifecycle and identity data.
+The addon owns platform process containment and launches one immutable A1 UI runtime with inherited terminal handles. It also provides native process-start inspection, terminal-mode capture and restoration, exit-notice delivery, and the bounded process-wait and process-group operations used by the exit watcher. It does not create a PTY, read ordinary terminal input, capture or parse runtime output, render, or relay terminal bytes.
 
-On Windows it uses `windows-sys 0.61.2` to create a Job Object, enables `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE`, assigns the runtime before resuming it, denies silent breakaway by never enabling breakaway limits, monitors the verified Node parent process, and terminates remaining job members after root or parent exit.
+On Windows it uses `windows-sys 0.61.2` to create a Job Object, enables `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE`, and creates the runtime directly in that job through `PROC_THREAD_ATTRIBUTE_JOB_LIST`. The runtime is a job member from its first instruction; the former suspended-create, assign, and resume sequence is gone. Ordinary jobs do not enable breakaway, and closing the addon-held job handle terminates remaining members.
 
-On Linux and macOS it creates a dedicated POSIX process group before exec, transfers foreground-terminal ownership only when a terminal is present, monitors the verified parent, applies bounded TERM/KILL cleanup to that group, and restores the prior foreground group. Linux derives process start identity from procfs. macOS derives it from the native `proc_pidinfo(PROC_PIDTBSDINFO)` start timestamp; PID liveness alone is never treated as identity.
+On Linux and macOS it uses `posix_spawn` to create a dedicated process group, transfers foreground-terminal ownership only when a terminal is present, applies bounded TERM/KILL cleanup to that group, and restores the prior foreground group. Linux derives process start identity from procfs. macOS derives it from `proc_pidinfo(PROC_PIDTBSDINFO)`; PID liveness alone is never treated as identity.
+
+## Exit watcher
+
+After the contained runtime starts, the launch guardian starts `dist/foundation/launch-guardian/exit-watcher.js` in another Node runtime outside the guardian's containment. The watcher waits for the guardian, performs bounded Unix process-group cleanup when needed, and claims and delivers the armed exit notice with the captured terminal modes. On Windows the addon creates that Node process outside both the runtime job and the guardian's inherited job; on Unix it remains in the terminal session so terminal hang-up reaches it naturally. The guardian itself delivers the notice on ordinary completion, and claim-by-rename ensures only one owner can print it.
+
+There is one accepted gap: a machine-wide kill aimed at every Node process, such as `taskkill /IM node.exe` or `pkill node`, kills the watcher together with the guardian and runtime. No exit notice is then printed and, on Unix, non-Node descendants left in the runtime process group are not signalled by the watcher. A1 does not work around that case by starting an A1-built executable. Terminal closure, `Ctrl+Break`, guardian failure, runtime termination, and a kill aimed only at the guardian remain covered.
 
 ## Artifact contract
 
-Release builds place the exact executable at:
+Release builds place the addon at:
 
 ```text
-dist/native/win32-x64/process-guardian.exe
-dist/native/linux-x64/process-guardian
-dist/native/darwin-x64/process-guardian
-dist/native/darwin-arm64/process-guardian
+dist/native/win32-x64/process-guardian.node
+dist/native/linux-x64/process-guardian.node
+dist/native/darwin-x64/process-guardian.node
+dist/native/darwin-arm64/process-guardian.node
 ```
 
-Each supported artifact must be named in the release integrity manifest with target triple, crate version, guardian protocol version, SHA-256, byte size, build provenance, and signature/attestation status. The build marks a platform supported only after its native containment integration runs on that platform. A missing, altered, incompatible, unsupported, or wrong-platform artifact is a concise containment launch error; A1 never silently falls back to PID-only cleanup.
+The publication `guardians` job builds them on `windows-2025`, `ubuntu-24.04`, and `macos-15` arm64; the macOS arm64 job also cross-compiles x64 with `--target x86_64-apple-darwin`. A native build is identified by loading the addon into Node and reading `version()`. When the producing runner cannot load the cross-compiled x64 addon, its manifest records only the observed Mach-O architecture.
+
+Each `a1-process-guardian-artifact-v2` manifest records `kind: "node-addon"`, Node-API 9, target platform and architecture, crate and protocol versions, SHA-256, byte size, build provenance, and signature/attestation status. A supported artifact is verified before loading. A missing, altered, incompatible, unsupported, or wrong-platform artifact is a concise containment launch error; A1 never silently falls back to PID-only cleanup. If a certified immutable release file disappears or changes, bootstrap restores it only from a matching installed package whose source bytes reproduce the certified size and digest, then verifies the complete release again.
 
 ## Licensing
 

package/docs/architecture/project-structure.md

@@ -103,6 +103,14 @@ a1 session link-worktree <absolute-worktree>
 git -C .worktrees/<task-id> status
 ```
 
+Claude Code sessions have no A1 shell-tool session, so they link with Claude Code's `EnterWorktree` tool by task name. The tracked `.claude/settings.json` wires a `WorktreeCreate` hook, `scripts/governance/claude-worktree-create.mjs`, that creates `.worktrees/<task-id>` detached at fresh `origin/develop`, or returns it when it is already registered, so Claude Code anchors the session there without an approval prompt. The agent then creates the task branch inside it:
+
+```sh
+git -C .worktrees/<task-id> switch -c <type>/<short-description>
+```
+
+Passing an absolute `path` to `EnterWorktree` is reserved for a worktree created by hand, from the primary checkout, before any shell command in that session; Claude Code otherwise keeps its shell tools anchored to the primary checkout and refuses their commands. The matching `WorktreeRemove` hook declines removal, so sessions leave with `ExitWorktree` `keep` and worktrees are removed only by the cleanup tool.
+
 Inventory is read-only and advisory because another runtime may win a later race. A successful link response confirming the exact canonical worktree is required before planning, implementation, test, or delivery-documentation edits. If inventory or linking fails, reports a live/unverifiable owner, loses a race, or confirms another path, stop task edits and report the blocker; use a separate fresh worktree rather than overriding, unlinking, or recovering that owner. A session resuming an existing delivery or switching streams atomically claims and links the exact worktree before editing it.
 
 The link acquires a cooperative live-session editing claim and switches bare A1's footer repository context and pull-request discovery. It does not change process or tool cwd, create a Git worktree lock, or register, release, or authorize cleanup. Clean unlink/disposal releases live editing authority; a crashed owner becomes reusable only after exact process death is verified. 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.

package/docs/architecture/resident-tabs-requirements.md

@@ -0,0 +1,18 @@
+# Resident tabs — target requirements
+
+Status: one requirement remains outside the delivered milestones. Milestones 1–6 moved every other requirement into their OpenSpec changes, and the canonical specs now hold them. This file keeps only what no milestone has delivered yet; it binds nothing until a later change adopts it. See [`resident-tabs.md`](resident-tabs.md#roadmap).
+
+## Capability: `resident-terminal-host`
+
+### ADDED Requirements
+
+#### Requirement: Host topology mutations are revisioned and atomic
+Client/server topology messages SHALL use the generation-1 protocol established by `resident-tabs-contracts`. A topology subscription SHALL begin with one complete snapshot and monotonic revision, followed by ordered changes. Every create, rename, reorder, close, retry, fresh-start, and stop-all mutation SHALL carry its expected topology or registry revision and SHALL either commit completely at the next revision or be rejected without a partial change. A method absent from an older same-generation server SHALL disable only that operation.
+
+##### Scenario: Two clients mutate one revision
+- **WHEN** two clients submit topology mutations against the same expected revision
+- **THEN** at most one SHALL commit, the stale mutation SHALL receive a typed revision conflict, and every client SHALL converge on the committed topology
+
+##### Scenario: Newer client calls an unavailable method
+- **WHEN** a newer same-generation client attaches to an older server that lacks one optional topology method
+- **THEN** attachment and unrelated operations SHALL remain available while only that method is disabled