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

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

package/docs/features/launch-profiles.md

@@ -4,17 +4,13 @@
 
 | Command | Purpose | Pi user profile |
 |---|---|---|
-| `a1` | A1 | `~/.a1/agent` |
+| `a1` | A1, one agent in this terminal | `~/.a1/agent` |
 | `a1 --session <path\|id>` | Resume a persisted A1 session | `~/.a1/agent` (or explicitly selected storage) |
-| `a1 solo` | Fresh A1 direct single-agent mode | `~/.a1/agent` |
-| `a1 solo --session <path\|id>` | Resume a persisted A1 session in direct single-agent mode | `~/.a1/agent` (or explicitly selected storage) |
 | `a1 pi` | Pi-compatible direct comparison surface using the ordinary Pi profile | ordinary `~/.pi/agent` |
 
-`a1 solo` is available in release and prerelease builds. Without arguments it starts a fresh single-agent session; with `--session` and optional `--session-dir` it resumes a saved session. Both forms omit the tab strip and the Tabs settings section.
-
 `a1 pi` is a development instrument for comparing A1 against pinned Pi. Prerelease builds — what `a1 update --develop` or `a1 update --develop <number>` installs — expose it. A release build does not recognize the launch form. Repository development can run the comparison directly with `npm start:pi`.
 
-There is no `a1 agent` command. The former `a1 ui` subcommand is removed. Unsupported commands return quietly without selecting another runtime. Bare `a1` is the normal A1 product surface.
+There is no `a1 agent` command. The former `a1 ui` subcommand, the `a1 solo` launch word, and the `a1 tabs …` maintenance commands are removed; like any other unsupported command they return quietly without selecting another runtime. Bare `a1` is the normal A1 product surface.
 
 ## First launch
 
@@ -37,20 +33,18 @@ Run Pi’s normal `/login` independently in each profile that needs stored authe
 
 ## Resume a session
 
-After a conversation has been persisted, exit A1 and run the command it prints from the original project directory. Exited solo sessions print the solo form; tabbed A1 sessions keep the tabbed form:
+After a conversation has been persisted, exit A1 and run the command it prints from the original project directory:
 
 ```sh
 a1 --session <id>
 a1 --session-dir '/path/to/session store' --session <id>
-a1 solo --session <id>
-a1 solo --session-dir '/path/to/session store' --session <id>
 ```
 
 `--session` also accepts a `.jsonl` file path; `--session-dir` may come before or after it. Explicit storage overrides `PI_CODING_AGENT_SESSION_DIR`, which overrides default storage. IDs are searched in the current project before other projects within the A1 store. A cross-project ID match asks before creating a fork with a new identity; an explicit file resumes directly using its stored working directory. Missing or invalid targets fail rather than create an empty replacement.
 
-Resume uses the shipped Pi's public restoration behavior, including the compaction format it writes. It sends no model prompt by itself and does not recover, convert, or modify an unrelated conversation. A tabbed selection opens in a new A1 tab or focuses the tab already holding it; a solo selection opens in the direct strip-free UI without starting the resident host. A live session remains protected by its single-writer lease. Pi picker/continue CLI aliases and `a1 pi --session` are not supported; in-UI `/resume` is unchanged.
+Resume uses the shipped Pi's public restoration behavior, including the compaction format it writes. It sends no model prompt by itself and does not recover, convert, or modify an unrelated conversation. A session already open in another A1 process stays protected by the session writer guard, so A1 offers a fork instead of attaching to it. Pi picker/continue CLI aliases and `a1 pi --session` are not supported; in-UI `/resume` is unchanged.
 
-Regression evidence creates disposable sessions through Pi 0.84.2, then executes the emitted command through the packed public entry, bootstrap, guardian, and owned UI. Default/custom storage, Windows Git Bash quoting, supervisor restart, failure cleanup, and simultaneous distinct selections are covered in `test/foundation/release/session-resume.integration.test.ts`. CI runs it in the resource-sensitive `package-smoke` scope, not the fast remainder. Unsupported synthetic retained-tail certification is separate deferred work.
+Regression evidence creates disposable sessions through the pinned Pi, then executes the emitted command through the packed public entry, bootstrap, and owned UI. Default/custom storage, Windows Git Bash quoting, an occupied session, failure cleanup, and simultaneous distinct selections are covered in `test/foundation/release/session-resume.integration.test.ts`. CI runs it in the resource-sensitive `package-smoke` scope, not the fast remainder. Unsupported synthetic retained-tail certification is separate deferred work.
 
 ## Pi comparison profile
 
@@ -58,14 +52,14 @@ Regression evidence creates disposable sessions through Pi 0.84.2, then executes
 
 ## Terminal behavior
 
-All interactive launch forms run the A1-owned full-viewport TUI over pinned Pi engine, component, and terminal APIs. Bare `a1` attaches to the native resident host; each tab runs the owned UI in a holder-owned pseudoterminal, while Node never relays or renders terminal bytes. `a1 solo` uses the direct owned path without resident infrastructure. `a1 pi` uses that same direct pipeline with A1-specific screens withheld.
+All interactive launch forms run the A1-owned full-viewport TUI over pinned Pi engine, component, and terminal APIs. The installed `a1` command selects the approved active release and runs its UI as one directly attached child process with the terminal inherited; nothing relays or renders terminal bytes in between. `a1 pi` uses that same pipeline with A1-specific screens withheld.
 
-## Concurrent instance lifecycle
+## Concurrent launches
 
-Each `a1 solo` or `a1 pi` invocation receives a unique non-detachable launch instance. Normal A1 clients instead attach to the profile's tab set, which can be viewed from concurrent terminals with explicit input-controller transfer. Profile files remain shared according to the selected profile root.
+Every `a1` or `a1 pi` invocation is an independent process. Any number can run at once in different terminals; profile files remain shared according to the selected profile root, and the session writer guard keeps each session file to one writer.
 
-Normal exit or terminal closure tears down a solo/comparison launch instance within bounded graceful and forced deadlines. Closing or detaching a normal A1 client leaves its tabs running; a tab and its process tree stop only when the user explicitly closes that tab.
+Quitting with `/quit` or `Ctrl+C` twice ends the agent and returns to the shell. Closing the terminal ends the agent too, as it does for upstream Pi. If the UI exits uncleanly, the launcher restores the terminal and prints the resume command.
 
-## Recovery and comparison
+## Comparison and reporting
 
-If A1's normal mode cannot start, bare `a1` falls back to the direct path with one notice. To start single agent mode explicitly, run `a1 solo` from the same working directory. To compare against the pinned Pi profile, run `a1 pi`; its profile data is intentionally separate, so authentication or settings may need independent configuration. Use `a1 --version` to record the installed A1 release before reporting a difference.
+To compare against the pinned Pi profile, run `a1 pi`; its profile data is intentionally separate, so authentication or settings may need independent configuration. Use `a1 --version` to record the installed A1 release before reporting a difference.

package/docs/features/prompt-history.md

@@ -44,11 +44,11 @@ imported automatically.
 The default uses A1's effective profile home: `A1_PROFILE_HOME` when set, otherwise
 the operating-system home. A custom agent-profile directory changes the history
 identity, not this default root. `A1_DATA_DIR` takes precedence for storage;
-`XDG_DATA_HOME` does not redirect default history. Control metadata, settings,
+`XDG_DATA_HOME` does not redirect default history. Release state, settings,
 agent resources, releases, logs, runtime files, and caches keep their existing
 locations. For repository-local `./scripts/dev` launches, history uses a stable
-checkout-wide data root so two independent solo instances share the selected
-Shared database, while control and runtime data remain isolated per launch.
+checkout-wide data root so two independent instances share the selected
+Shared database, while release and runtime data remain isolated per launch.
 The development-only `A1_DEV_HISTORY_DATA_DIR` selects that root; an explicit
 `A1_DATA_DIR` still overrides its launcher default. Existing histories in old
 per-instance development roots are not moved or combined.
@@ -62,14 +62,14 @@ Old and new releases using different roots do not synchronize history.
 In Shared mode the filename is the original `a1-` SHA-256 profile identity,
 independent of project, session, checkout, and release. In Unique mode (the
 default), a domain-separated digest also includes the stable conversation session
-ID; two solo launches or resident tabs therefore use different databases and
+ID; two concurrent launches therefore use different databases and
 image sidecars. Resuming the same session reuses its store; starting or forking a
 session selects a different one. Windows ordinary case and separator variants
 normalize together. Moving a profile, unresolved symlink aliases, or selecting a
 different data root can select a different history; A1 never silently merges or
 imports it.
 
-The database is separate from `control.sqlite3`, agent resources, and disposable
+The database is separate from release state, agent resources, and disposable
 caches. Upgrades, ordinary npm uninstall/reinstall, release rollback, cache cleanup,
 and conversation deletion do not clear it. Reusing saved history requires the
 same profile and history root; explicitly deleting user data still removes it.
@@ -91,9 +91,9 @@ The History section in `/settings` provides:
   storage and durable recall for subsequent launches, not current-session
   recovery. Existing enabled instances keep running until closed.
 - **History scope:** Unique (default) keeps each agent session's durable prompts
-  separate across solo launches and resident tabs. Shared restores the former
-  profile-wide store. Switching applies to running agents, including other solo
-  processes and resident tabs, when their shared settings update arrives. New
+  separate across concurrent launches. Shared restores the former
+  profile-wide store. Switching applies to running agents, including other A1
+  processes, when their shared settings update arrives. New
   prompts use the newly selected store; already-submitted writes finish in their
   original store. Switching never transfers or deletes records, and it preserves
   unsent drafts. Existing profiles without this setting default to Unique, so
@@ -145,9 +145,8 @@ Build the checkout, then launch it through `./scripts/dev`. Use an isolated
 `A1_DATA_DIR` for disposable history checks; keep that same directory on each
 restart and in both concurrent terminals. The development launcher always sets
 an isolated `A1_DATA_DIR`; to try the home-based location in that launcher,
-explicitly select `A1_DATA_DIR=<effective-home>/.a1/data` and keep
-`A1_DATABASE_PATH` in a separate disposable directory so control metadata is not
-placed beside history. For a history-only review, `NODE_DISABLE_COMPILE_CACHE=1`
+explicitly select `A1_DATA_DIR=<effective-home>/.a1/data` in a disposable
+profile home. For a history-only review, `NODE_DISABLE_COMPILE_CACHE=1`
 also avoids creating compile-cache files under that explicitly overridden root.
 The focused path/composition tests cover normal no-override selection. Test:
 

package/docs/local-worktree-cleanup.md

@@ -99,6 +99,32 @@ node scripts/governance/local-worktree-cleanup.mjs discard \
 
 An open, merged, reopened, forked, protected, reserved, advanced, dirty, active, linked, nested, replaced, current, or unverifiable candidate remains blocking. Remote deletion followed by a Windows lock or later local blocker is reported as `partial`; the journal preserves the remaining worktree/local ref for the same exact confirmed command to inspect and resume. The command never scans by age or name, adopts another session's checkout, enables queue/watch, or turns PR close events into automatic discard authority.
 
+### Closed-unmerged branch without a checkout
+
+Use the same explicitly confirmed `discard` operation with `--branch` instead of `--path` when the checkout is already gone and no live cleanup registration owns the ref. The selectors are mutually exclusive:
+
+```bash
+cd /d/Git/a1 && node scripts/governance/local-worktree-cleanup.mjs discard --repo D:/Git/a1 --branch feature/rejected-example --change rejected-example --pr 123 --confirm-closed-unmerged
+```
+
+Branch mode verifies the named same-repository PR is still closed-unmerged into `develop`, its implementation association matches the requested change, no other open PR uses the branch, no Git worktree has it checked out, and no nonterminal registration owns the ref. Protected/reserved refs, advanced local or remote tips, malformed evidence, conflicting journals, and scoped lock contention block. It never creates a checkout, invents a filesystem identity, deletes a directory, or adopts a worktree.
+
+A branch-scoped `branch-discard-<ref-digest>.json` journal beside the ordinary cleanup state pins the repository, exact ref, change, PR, expected head, and deletion step without changing existing worktree records. After local preflight, the command journals intent, revalidates live evidence, expected-head deletes only the remote ref, verifies remote absence, and compare-and-deletes the unchanged local ref. Absent refs support resumption. Repeated completed requests report `already-discarded` only while both refs remain absent; a recreated ref is retained as `discard-ref-recreated`. Command reports, not the worktree-only registration list, describe this branch-scoped state. Sweep and queue never invoke branch-only discard.
+
+## Explicit disposable-link remediation
+
+Ordinary completion and sweep still refuse external descendant links. For one released, eligible merged candidate, a separately confirmed `unlink-disposable-link` operation can remove one explicitly named ignored descendant link beneath a central disposable root without admitting its external target into purge:
+
+```bash
+cd /d/Git/a1 && node scripts/governance/local-worktree-cleanup.mjs unlink-disposable-link --repo D:/Git/a1 --path D:/Git/a1/.worktrees/example-task --change example-task --pr 123 --link .artifacts/agent/shared-node-modules --confirm-link-only
+```
+
+The command requires the existing released registration, exact candidate/change/PR, accepted HEAD ancestry, eligible merged/archive evidence, absent remote topic ref, and clean local content except for that one named link. Invoke it from primary, with no known conflicting editor, using integrated repository policy. Owned, current, replaced, dirty, ineligible, unregistered, or resource-busy candidates remain blocked. Other unsafe links remain blockers; no wildcard or bulk-link option exists.
+
+Only a relative slash-separated path strictly below a central disposable root is accepted. The path must be ignored and untracked, its parents must be real non-link directories inside the canonical worktree, and its final entry must be a resolvable symlink or junction with a target outside that worktree. Internally targeted links remain on the ordinary generated-content path and are rejected by this no-target-enumeration operation. Escapes, root substitutions, ordinary files/directories, cycles, Git-metadata targets, identity/target/parent drift, and locked links block. The command revalidates candidate authority, full local content, ancestor identities, link fingerprint, and target before every bounded non-recursive unlink attempt, including Windows junction fallback. It never enumerates, traverses, modifies, or removes the target.
+
+An `unlinked` report records the candidate and removed link identity without target contents. The worktree and its released registration remain intact; a later ordinary `complete` or sweep must independently repeat every normal gate. The operation enables nothing, deletes no ref, does not grant ongoing link-removal authority, and cannot repair locked leftover directories. A missing selected link reports a named blocker rather than fabricating prior success.
+
 ## Explicit redundant no-PR retirement
 
 A non-empty unregistered checkout is never adopted by sweep, preview, queue/watch, branch pruning, age, or ancestry. After the maintainer explicitly authorizes one exact redundant checkout, use the repository-owned operation from the primary checkout:
@@ -170,7 +196,7 @@ Registration binds the repository, exact directory/filesystem identity, candidat
 
 A CI/base/older-ancestor checkout does not qualify automatically. Version 3 has no local acceptance/archive checkout to register. No local archive checkout is required when a legacy archive was generated entirely on GitHub. Legacy version-1/version-2 linkage remains supported, but individually reviewing and registering a legacy checkout is explicit adoption, not a bulk sweep.
 
-Low-level `register` keeps an explicit disposable allowlist for legacy and diagnostic use. The standard `complete` command supplies the central repository policy automatically; agents do not choose flags for normal completed-delivery cleanup. Neither route permits discarding tracked, staged, unstaged, untracked, unknown ignored, unapproved linked, special, or actual nested repository/submodule content. The sole link exception is the guarded exact-root or contained descendant behavior above. Declaring or centrally recognizing a generated directory does not bypass ignored-path, identity, type, or traversal checks.
+Low-level `register` keeps an explicit disposable allowlist for legacy and diagnostic use. The standard `complete` command supplies the central repository policy automatically; agents do not choose flags for normal completed-delivery cleanup. Neither route permits discarding tracked, staged, unstaged, untracked, unknown ignored, unapproved linked, special, or actual nested repository/submodule content. Automatic purge admits only the guarded exact-root or contained descendant behavior above. Separately confirmed named-link remediation removes only its exact link entry and never widens purge authority. Declaring or centrally recognizing a generated directory does not bypass ignored-path, identity, type, or traversal checks.
 
 Before handing a completed checkout to cleanup, stop its development processes, leave its directory, and release it using the returned ID and current generation:
 
@@ -214,6 +240,7 @@ State, journals, stop controls, and execution reports live in `<git-common-dir>/
 - `blocked`: ownership, content, path, provenance, authentication, or identity needs attention.
 - `unmanaged`: no local registration; no automatic adoption. Reason `empty-directory-recent` marks an all-empty folder still inside its ten-minute grace, and in preview `empty-directory` marks one an execution pass would remove.
 - `removed`: worktree and eligible local-ref operations were verified.
+- `unlinked`: only the explicitly named disposable link entry was removed; its target, worktree, and released registration were preserved.
 - `already-absent`: a completed journal's path/ref are still absent.
 - `retired`: either evidence was unverifiable but nothing remained to delete and the merged PR registration completed with `retired-nothing-left`, or an exact confirmed `retire-redundant` operation safely removed its no-PR checkout and local ref.
 - `forgotten`: the maintainer explicitly closed an all-absent entry with `forget`.

package/docs/manual-owned-ui-checkpoint.md

@@ -22,7 +22,6 @@ $manualRoot = (Resolve-Path ".artifacts/manual-owned-ui").Path
 $env:A1_CONFIG_DIR = "$manualRoot\state\config"
 $env:A1_DATA_DIR = "$manualRoot\state\data"
 $env:A1_RUNTIME_DIR = "$manualRoot\state\runtime"
-$env:A1_DATABASE_PATH = "$manualRoot\state\data\control.sqlite3"
 ```
 
 Run each installed launch form yourself:

package/docs/validation.md

@@ -6,7 +6,7 @@ Development validation computes one exact base/head selection with:
 npm run select:validation-impact -- --base <full-base-sha> --head <full-head-sha> --output .artifacts/validation/impact.json
 ```
 
-The versioned `config/validation-ownership.json` registry maps stable product and test path groups to a mandatory PR core, an explicit critical floor per owner, changed and bounded transitive consumers, resource-sensitive tests, and integration owners. The coarse owners are UI/rendering, launch/startup, release/package/update, Pi, native containment, image/history, governance, and shared product inputs. Each integration owner in `config/integration-owners.json` declares `pull-request`, `direct-impact`, or `exhaustive` cadence. A changed pull-request test selects its owner; a changed exhaustive test selects focused deterministic contracts and records the exhaustive owner as cadence-deferred. Shared support selects every declared PR consumer and records affected exhaustive consumers; copies, renames, and deletions inspect both identities. Reasons and changed paths are recorded in `impact.json`.
+The versioned `config/validation-ownership.json` registry maps stable product and test path groups to a mandatory PR core, an explicit critical floor per owner, changed and bounded transitive consumers, resource-sensitive tests, and integration owners. The coarse owners are UI/rendering, launch/startup, release/package/update, Pi, image/history, governance, and shared product inputs. Each integration owner in `config/integration-owners.json` declares `pull-request`, `direct-impact`, or `exhaustive` cadence. A changed pull-request test selects its owner; a changed exhaustive test selects focused deterministic contracts and records the exhaustive owner as cadence-deferred. Shared support selects every declared PR consumer and records affected exhaustive consumers; copies, renames, and deletions inspect both identities. Reasons and changed paths are recorded in `impact.json`.
 
 Reviewed `refinements` can narrow a coarse owner's tests and integration links for known subareas: scrollbar/settings, clipboard/editor/repository commands, documentation/cleanup/delivery governance, and development-environment tooling. Each rule keeps an explicit minimum test set; a bounded relative-import graph across `test/`, `src/`, `scripts/`, and `bin/` adds at most 24 sorted transitive consumers per changed path, including consumers outside the coarse owner, and integration owners of those retained consumers. The graph is supplemental, not sole coverage authority. Unreviewed or absent source identities and an unavailable graph retain the coarse owner. Changed tests, shared support, and mixed source/support changes retain their coarse contracts; rename and deletion classification still includes both identities. Some UI changes deliberately select more tests than before because the graph exposes formerly missed shell consumers.
 
@@ -40,7 +40,7 @@ Do not run preflight, `test:fast`, `test:full`, `test:release`, or directory-wid
 npm run preflight                  # pull-request validation's fast gates on the committed head
 ```
 
-Preflight selects the committed merge-base diff with `origin/develop` exactly as validation does (uncommitted paths are reported, not checked), writes it to `.artifacts/validation/local-impact.json`, and stops at the first failure. It runs the core job's install build and receipt, `typecheck`, `check:architecture`, changed-file code documentation, release documentation, changed-file naming, docs governance, strict OpenSpec validation with the workflow's pinned validator, the delivery-guidance test, and the core job's `pr-core-tests` and `pr-selected-tests` scopes. Each step invokes the script and arguments its workflow job runs, so a failure reports the same rule identifier and path. It never builds the native host, does not run resource-sensitive or integration owners, and CI remains the authority.
+Preflight selects the committed merge-base diff with `origin/develop` exactly as validation does (uncommitted paths are reported, not checked), writes it to `.artifacts/validation/local-impact.json`, and stops at the first failure. It runs the core job's install build and receipt, `typecheck`, `check:architecture`, changed-file code documentation, release documentation, changed-file naming, docs governance, strict OpenSpec validation with the workflow's pinned validator, and the core job's `pr-core-tests` and `pr-selected-tests` scopes. Each step invokes the script and arguments its workflow job runs, so a failure reports the same rule identifier and path. It does not run resource-sensitive or integration owners, and CI remains the authority.
 
 `test:pr-core` is not a replacement for `test:fast`: CI combines it with directly changed and coarse-owner tests from the exact impact selection. Selected resource-sensitive tests run independently on an isolated Windows runner. Selected package, startup, rendering, Pi, compatibility, and platform owners also run independently after their actual prerequisites.
 
@@ -50,13 +50,7 @@ Conservative Development retains every critical owner floor and the small set of
 node scripts/release/generate-validation-ownership-ledger.mjs --output .artifacts/validation/ownership-ledger.json
 ```
 
-Containment-selected modular jobs build and test the debug `process-guardian.node` addon for their exact platform, export `A1_PROCESS_GUARDIAN_PATH` to that file, and run the launch-owner integration fixtures as Node processes. The tests exercise the real addon-held Windows job or Unix process group, addon-backed identity and terminal operations, and the Node exit watcher; no fixture invokes a process-guardian executable. The Windows startup lane keeps Defender real-time protection enabled while packaged startup loads the release addon.
-
-The `terminal-host` owner is CI-only. A change under `native/terminal-host/` or to its run scripts selects, per platform (Windows x64, Linux x64, macOS arm64), one **Native terminal host** job and three **Native terminal host tests** partition jobs. The partition jobs each build the test profile and run one third of the serialized `role_integration` suite (`run-terminal-host-probe.mjs --partition <i>/3`, partitioned by sorted test name read from the suite's source) and nothing else; the crate's unit tests run once, in the build-and-probe job, rather than once per partition. The feature-gated `role-host` binary stands in only for the fixed role grammar inside Rust integration tests and is never packaged. The build-and-probe job runs `npm run test:terminal-host` with the role suite skipped (`TERMINAL_HOST_PARTITION=none`), which runs the `--lib --bins` unit tests and the `release_isolation` integration test, building `terminal-host.node` with Rust, Node-API 9, and Zig 0.15.2 for the lane's exact target and baseline CPU model. It loads the addon for its version and non-interactive probes, verifies the shared session-writer lock export, and uploads the debug addon and frozen protocol manifest; Linux also runs bounded decoder fuzzing with a `cargo-fuzz` binary restored from an exact version-and-nightly cache when one exists.
-
-Candidate-packing lanes need the release terminal host but not its toolchain when an exact-input cache entry exists: they restore the addon, manifest, and notices, re-record the manifest's `host-entry.js` digest from the current build with `build-terminal-host.mjs --reuse`, and verify the result with `verify-native-artifacts.mjs --local` before recording the build receipt. See the Development cadence section of [`ci-release-runbook.md`](ci-release-runbook.md).
-
-The protected aggregate requires every partition of every selected platform, keyed by `partition` in the outcome authority and job envelope. Because the role suite no longer warms the resident launch paths in the build-and-probe job, its certification step runs one unmeasured `measure-resident-tabs.mjs` pass before the measured pass whose budgets are unchanged. Fidelity, latency, chaos, and certification start roles as `process.execPath dist/foundation/resident-tabs/host-entry.js` with `A1_TERMINAL_HOST_PATH` naming the addon. Windows cleanup identifies those Node-hosted residents by command line; it never kills every `node.exe` by image name. Locally, `npm run test:terminal-host` without a partition is unchanged and runs everything in one process. Local Windows builds fail in `build.rs` unless `TERMINAL_HOST_LOCAL_BUILD=1` is set, because Zig's package fetch unpacks test data that workstation antivirus quarantines. Native lanes also publish the terminal library they linked; a local build can link it instead of running Zig (see Local native iteration in [`architecture/resident-tabs.md`](architecture/resident-tabs.md)), which is development evidence only and never replaces selected CI. `TERMINAL_HOST_CONTRACTS_ONLY=1` is a library-only diagnostic and cannot substitute for selected CI. See [`native/terminal-host/README.md`](../native/terminal-host/README.md).
+The repository has no native code, so no validation lane builds, caches, or certifies a native artifact; every lane builds the TypeScript product with `npm run build` and tests it as JavaScript. The Windows startup lane keeps Defender real-time protection enabled while it measures packaged startup.
 
 ## Coverage-preserving efficiency
 
@@ -96,7 +90,7 @@ For GitHub's explicit **re-run failed jobs** action, a successful job that GitHu
 
 Checkout-bound type, architecture, governance, unit, and smoke outcomes bind head/run/selection/scope authority without inventing package identity. Build and package receipts remain mandatory wherever validation consumes emitted or packed bytes: package, startup, update, compatibility, preview, release, and publication boundaries.
 
-A build receipt binds checkout head, complete build inputs, toolchain, emitted files, and native artifacts. A package receipt additionally binds exact tarball bytes, packed entries, manifest/bin identity, producer, and verified build/source authority. `VALIDATION_BUILD_READY` and `VALIDATION_CANDIDATE_TARBALL` only locate prerequisites; stale or tampered receipts cause fresh preparation or failure.
+A build receipt binds checkout head, complete build inputs, toolchain, and emitted files. A package receipt additionally binds exact tarball bytes, packed entries, manifest/bin identity, producer, and verified build/source authority. `VALIDATION_BUILD_READY` and `VALIDATION_CANDIDATE_TARBALL` only locate prerequisites; stale or tampered receipts cause fresh preparation or failure.
 
 Npm download bytes may be reused with integrity checks and `--prefer-offline`, with normal network fallback. Every installation prefix remains fresh. Installed package trees, dependency certification, startup/profile state, mutable fixture repositories, passing outcomes, and publication evidence are never restored from caches.
 
@@ -143,7 +137,7 @@ Download these artifacts from the exact workflow run:
 - `development-validation-impact`: base/head, global selection identity, PR-core tests, selected pull-request owners, cadence-deferred exhaustive owners, exclusions, and bounded reasons.
 - `development-validation-outcome-<job>-<platform>-node<node>-attempt-<attempt>`: attempt-qualified outcome, content-free envelope, per-scope authority and duration, and applicable exact-artifact evidence.
 - `development-validation-aggregate-<head>-<run>-<attempt>`: selected/deferred owners, accepted/reused attempts, evidence count, runner critical path, total runner time, aggregate processing, setup/gate/scope time, cache state, and invocation count.
-- `pr-full-regression-selection-<run>-<attempt>` plus `complete-regression-aggregate-<run>-<attempt>`: current PR/head/base/metadata selection identity and all four exact-run native lane envelopes. Missing, mismatched, stale, failed, cancelled, or unexpected skip evidence blocks the protected aggregate. It reports the eight-minute critical-path and five-minute individual-scope targets as met or unmet; hosted queue delay is not test execution and remains separate.
+- `pr-full-regression-selection-<run>-<attempt>` plus `complete-regression-aggregate-<run>-<attempt>`: current PR/head/base/metadata selection identity and all four exact-run platform lane envelopes. Missing, mismatched, stale, failed, cancelled, or unexpected skip evidence blocks the protected aggregate. It reports the eight-minute critical-path and five-minute individual-scope targets as met or unmet; hosted queue delay is not test execution and remains separate.
 - startup/resume phase JSONL and performance JSON: first-attempt launch evidence and retained failed setup/readiness records.
 
 For selected implementation candidates, record focused and pre-finalization full observations before finalization. Keep final head/run/selection identity in Actions and handoff rather than adding a post-success commit that invalidates that evidence. A successful selected PR run replaces an additional mandatory dispatch; standalone runs remain diagnostic, and numbered-package nightly recovery remains independent.

package/docs/worktree-link-recovery.md

@@ -4,9 +4,9 @@ A1 coordinates worktree-claim mutations separately from the editing claims thems
 
 ## Automatic recovery
 
-Updated A1 holds an OS lock on the persistent `session-worktree-claims/mutation.authority` file. The OS releases it when the process exits, including a crash. `mutation.lock` is now a persistent directory that blocks older file-lock writers; its `owner.json` is only diagnostic metadata.
+Updated A1 holds a `proper-lockfile` gate, the `mutation.authority.gate` lock directory beside the persistent `session-worktree-claims/mutation.authority` file, for each mutation. The holder refreshes it while working; a gate left by a crashed or stalled process becomes stale after 10 seconds and the next mutation reclaims it. `mutation.lock` is a persistent directory that blocks older file-lock writers; its `owner.json` is only diagnostic metadata.
 
-The next mutation safely recovers abandoned owner/pending metadata after taking native authority. Empty, truncated, NUL-filled, or otherwise malformed metadata does not prevent this recovery. One bounded `recovery.json` records the recovery reason/time, not the original bytes or session contents. A live native holder remains protected. Acquisition waits at most two seconds by default and honors cancellation.
+The next mutation safely recovers abandoned owner/pending metadata after taking the gate. Empty, truncated, NUL-filled, or otherwise malformed metadata does not prevent this recovery. One bounded `recovery.json` records the recovery reason/time, not the original bytes or session contents. A live gate holder remains protected. Acquisition waits at most two seconds by default and honors cancellation.
 
 If startup registration fails temporarily, the running session retries on its 30-second refresh interval. Slow attempts are coalesced rather than queued indefinitely. Once registration succeeds, retry the explicit worktree link in the same session. Switching an agent's session replaces its publication identity, and disposal drains publication before releasing claims.
 
@@ -18,19 +18,19 @@ An existing regular-file `mutation.lock` belongs to the old protocol. Updated A1
 
 For this one-time legacy case, stop all older A1 processes normally, move only that exact regular lock file to a backup while they are stopped, then start updated A1. Keep sessions, runtime records, associations, editing claims, Git locks, and worktrees. Reinstalling/downgrading alone does not clear persisted legacy state. Never move the new directory or delete `mutation.authority` while A1 is running.
 
-When the old gate is absent, updated A1 initializes its compatibility barrier automatically. Older versions cannot mutate worktree claims after this point: all participating sessions must use the updated version. This intentionally prevents two incompatible mutation protocols from running concurrently. The installed native addon must support the new gate; there is no unsafe PID-file fallback if the addon is missing or outdated.
+When the old gate is absent, updated A1 initializes its compatibility barrier automatically. Older versions cannot mutate worktree claims after this point: all participating sessions must use the updated version. This intentionally prevents two incompatible mutation protocols from running concurrently.
 
 ## Diagnostics
 
 | Code | Meaning / next step |
 | --- | --- |
-| `worktree-claim-busy` | A mutation still holds native authority. Retry the link shortly; runtime registration retries automatically. |
+| `worktree-claim-busy` | A mutation still holds the gate. Retry the link shortly; runtime registration retries automatically. |
 | `worktree-legacy-recovery-required` | Retained old-format gate. Use the stopped-process legacy procedure above. |
-| `worktree-coordination-unavailable` | Missing or outdated native support. Repair/update the A1 installation. |
+| `worktree-coordination-unavailable` | The installation cannot coordinate worktree claims. Repair/update the A1 installation. |
 | `worktree-coordination-io` | Gate/metadata filesystem access failed. Check permissions and storage availability. |
 | `worktree-coordination-boundary` | Unexpected file type, link, or entry. Retain it for inspection; do not clear the store. |
 | `session-runtime-unavailable` | Runtime registration has not succeeded. Retry after the next refresh and address any specific coordination failure. |
-| `process-inspection-unavailable` / `session-runtime-unverifiable` | Exact process identity cannot be checked. Repair inspection support; no ownership takeover is authorized. |
+| `session-runtime-unverifiable` | The runtime's recorded process cannot be checked. Retry; no ownership takeover is authorized. |
 | `worktree-active-in-another-session` | Another live agent owns the target. Use a different worktree or have that owner release it. |
 | `worktree-owner-unverifiable` | The editing claim itself is uncertain. Gate recovery cannot make that claim available. |