@timurproko/a1 0.2.7-dev.767 → 0.2.7-dev.779

package/docs/architecture/terminal-host-provenance.md

@@ -8,7 +8,13 @@ The composed-terminal proof uses a small console-hosted stack. It runs inside th
 |---|---|---|---|
 | `libghostty-vt` | `ghostty-org/ghostty` commit `c5a21edfcbc2d5b46540ad91b7980aca31f5f1f3` | Terminal parsing, retained state, and input semantics | MIT |
 | `portable-pty` | version `0.9.0` | ConPTY/Unix PTY and process ownership | MIT |
-| Crossterm | version `0.29.0` | Outer-terminal raw mode and host input events | MIT-compatible candidate; notice must be vendored before packaging |
+| Crossterm | version `0.29.0` | Outer-terminal raw mode and host input events | MIT; license text ships in the generated notices |
+
+`libghostty-vt` is built with `-Dsimd=true`, which statically links simdutf `9.0.0` (Apache-2.0 OR MIT, vendored in the libghostty tree) and Highway at commit `66486a10623fa0d72fe91260f96c892e41aceb06` (Apache-2.0 OR BSD-3-Clause, fetched by the pinned Zig build). Their license texts are kept under `native/terminal-host/vendor/third-party-licenses/` with digests recorded in `config/terminal-host-provenance.json`, beside the upstream napi-rs license that the published `napi` and `napi-sys` crates omit.
+
+## Release notices
+
+`scripts/release/generate-terminal-host-notices.mjs` writes `terminal-host-THIRD-PARTY-NOTICES.txt` beside each release artifact. It walks the locked Cargo graph for the build target (normal dependencies, including the `node-addon` session lock; proc-macro crates and their subtrees never reach the binary), adds the Zig-linked components, and fails on a license expression outside MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, Unicode-3.0, or Zlib (the `LLVM-exception` addendum is accepted), on a crate without license text, or on a pinned text whose digest changed.
 
 A buffered A1-owned frame composer is the initial presentation layer. Ratatui is an optional evaluation candidate only if the narrow composer increases rendering risk; it is not selected by default.
 
@@ -46,8 +52,8 @@ The console proof requires:
 
 - Rust/Cargo for the A1 terminal host;
 - Zig `0.15.x` with patch `>= 0.15.2` to build `libghostty-vt`;
-- the platform C/C++ build toolchain required by Rust and the PTY/input crates (Visual Studio 2022 Build Tools/MSVC on Windows);
-- Windows 10/11 x64 or ARM64 for the first proof;
+- the platform C/C++ build toolchain required by Rust and the PTY/input crates (Visual Studio 2022 Build Tools/MSVC on Windows, the runner image's Xcode Clang on macOS, GCC on Linux);
+- release builds on `windows-2025`, `ubuntu-24.04`, `macos-15` (arm64), and `macos-15-intel` (x64);
 - an existing terminal emulator for manual validation;
 - an isolated disposable worker for automated physical validation.
 
@@ -67,3 +73,7 @@ Every spike or production host artifact must record:
 - evidence workload schema version and physical/manual verdict reference.
 
 Unverified, mismatched, or unsigned/unattested artifacts are not eligible for composed-terminal integration.
+
+## Release artifact
+
+`npm run build:terminal-host` (`scripts/development/build-terminal-host.mjs`) runs only on the release runners. It builds the `terminal-host` executable and the `node-addon` session-writer lock (`a1_session_lock.node`) with `cargo build --release --locked`, checks the executable's `--version` report (protocol, generation, crate version, pinned `libghostty-vt` commit, and that neither `fault-injection` nor `resident-fixtures` is compiled in), writes the notices, and records `terminal-host.manifest.json` (schema `a1-terminal-host-artifact-v1`) with the SHA-256 and size of all three files plus the target triple, Rust and Zig versions, and `Cargo.lock` digest. The publication `package` job refuses to pack unless every platform's guardian and terminal host are present and match their manifests, and A1 verifies the manifest before every execution.

package/docs/architecture/toolchain.md

@@ -36,7 +36,7 @@ It contains no PTY, terminal emulator, browser/desktop GUI, custom renderer, inp
 
 `npm run doctor` reports this contract against the current machine—Node range, npm major, git, the GitHub CLI, Rust/Cargo, and whether `node_modules` matches the lockfile—and names the install command for anything missing. `npm run build` runs the same check as its first step, so an unmet prerequisite fails by name rather than inside a module resolver or Cargo. 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. `npm run build` compiles the standalone `native/process-guardian` crate for the host platform, places it under `dist/native/<platform>-<architecture>/`, and writes an integrity manifest. Preview and stable candidate workflows build platform artifacts on isolated Windows, Linux, and macOS runners and assemble them before packing. macOS remains explicitly unsupported until its exact containment adapter is certified; the package must fail before runtime startup rather than use PID-only cleanup.
+Source builds require Rust/Cargo 1.85 or newer. `npm run build` compiles the standalone `native/process-guardian` crate for the host platform, places it under `dist/native/<platform>-<architecture>/`, and writes an integrity manifest. Preview and stable candidate workflows build platform artifacts on isolated Windows, Linux, macOS arm64, and macOS x64 runners and assemble them before packing. The same runners build the release terminal host and its session-writer lock with `npm run build:terminal-host`; the local `npm run build` does not, because the Zig fetch for `libghostty-vt` is quarantined by workstation antivirus on Windows (see [`terminal-host-provenance.md`](terminal-host-provenance.md)). macOS remains explicitly unsupported until its exact containment adapter is certified; the package must fail before runtime startup rather than use PID-only cleanup.
 
 The process guardian inherits terminal handles but transports no terminal bytes. See [`process-guardian-provenance.md`](process-guardian-provenance.md).
 

package/docs/ci-release-runbook.md

@@ -89,7 +89,7 @@ effect of stable publication, not a trigger.
 | `.github/workflows/release-tag-cleanup.yml` | When a stable Release is deleted, or on dispatch with a version (`gh workflow run release-tag-cleanup.yml -f version=X.Y.Z`): the release-automation App deletes the leftover `vX.Y.Z` tag only while no Release uses it and npm serves neither package; a published version's tag is permanent |
 | `.github/workflows/full-regression.yml` | Additional on-demand complete regression without publication authority |
 | `.github/workflows/pi-upstream-sync.yml` | Nightly at `03:23 UTC`: when npm publishes a newer Pi than the pin that no closed proposal skipped, proposes the upgrade as a draft pull request with the vendored copies that follow upstream merged, the kept copies reported with their upstream delta, the ledger, headers, inventories, public API and feature baselines, startup graph, and parity evidence regenerated, and every gate verdict (passed, failed, or blocked by conflict markers) and review item in the body; never merges and never replaces a proposal a human has continued |
-| `.github/workflows/nightly-regression-triage.yml` | After every completed `Full regression` run on `develop` or scheduled `Publish` validation: judges the startup budget across the three most recent runs and, after a failure or a persistent overrun, opens `fix/nightly-regression-<date>` as a draft pull request carrying the failed commands per lane, their tests, a bounded log excerpt, the `develop` commits since the last green run, and an OpenSpec fix scaffold, or refreshes the open candidate with the same failed scope set; re-runs nothing, never writes `develop`, never merges |
+| `.github/workflows/nightly-regression-triage.yml` | After every completed `Full regression` run on `develop` or scheduled `Publish` validation: judges the startup budget across the three most recent runs and, after a failure or a persistent overrun, opens `fix/nightly-regression-<date>` as a draft pull request in the ordinary delivery layout with its two implementation outcomes and one acceptance outcome generated, posts a triage comment carrying the failed commands per lane, their tests, a bounded log excerpt, and the `develop` commits since the last green run, and commits an OpenSpec fix scaffold, or refreshes the open candidate with the same failed scope set through another comment and design record; re-runs nothing, never writes `develop`, never merges |
 
 ## Impact-aware development validation
 
@@ -358,7 +358,7 @@ Rules that do not bend:
 
 - **PR validation fails:** fix the code and push; do not mark a failed PR-cadence tier optional. If real predecessor history is needed, run Full regression rather than changing the exhaustive result into PR success.
 - **Nightly startup budget overruns:** a single overrun on Full regression or nightly publication is a warning in the run summary, not a failure; the triage judges the key across the three most recent `develop` runs and opens a `package-startup` candidate only when all three overran. Stable candidate validation still fails on one overrun; rerun it with the measured phases in hand.
-- **Nightly regression fails:** the triage workflow opens or refreshes a draft `fix/nightly-regression-<date>` pull request whose body and change carry the evidence and whose `regression-provenance.json` binds the source run; start the fix there. A failed Full regression source created by `openspec-ci` selects PR-attached Full regression, while a Publish-only failure or successful-run persistent overrun retains ordinary PR validation. Reproduce from the listed tests or commands on the failed lane and fix without weakening assertions, budgets, timeouts, or coverage. Record focused implementation evidence and pre-finalization observations in the change, then require `Development validation required` and, when selected, PR-attached Full regression on the finalized exact head. Put final run/head/selection in Actions and handoff rather than making another evidence-recording commit. Standalone dispatch remains diagnostic; numbered-package nightly recovery is independent. A day whose failed scope set differs from every open candidate opens a new one. A Full regression dispatched on a candidate's own branch is that candidate's proof but never selected PR authority; its failures never open another candidate. A failure with no candidate means the triage workflow itself failed; read its run summary and dispatch it with the failed run id and `dry_run` off.
+- **Nightly regression fails:** the triage workflow opens or refreshes a draft `fix/nightly-regression-<date>` pull request whose triage comment and change carry the evidence and whose `regression-provenance.json` binds the source run; start the fix there. Its body is the ordinary delivery layout with the two implementation outcomes, the acceptance outcome, and the triage key already generated: check each outcome as it completes, never rewrite the generated items, and let trusted readiness promote the all-checked draft like any other. A failed Full regression source created by `openspec-ci` selects PR-attached Full regression, while a Publish-only failure or successful-run persistent overrun retains ordinary PR validation. Reproduce from the listed tests or commands on the failed lane and fix without weakening assertions, budgets, timeouts, or coverage. Record focused implementation evidence and pre-finalization observations in the change, then require `Development validation required` and, when selected, PR-attached Full regression on the finalized exact head. Put final run/head/selection in Actions and handoff rather than making another evidence-recording commit. Standalone dispatch remains diagnostic; numbered-package nightly recovery is independent. A day whose failed scope set differs from every open candidate opens a new one. A Full regression dispatched on a candidate's own branch is that candidate's proof but never selected PR authority; its failures never open another candidate. A failure with no candidate means the triage workflow itself failed; read its run summary and dispatch it with the failed run id and `dry_run` off.
 - **Nightly exhaustive predecessor validation fails:** treat the focused PR result as insufficient, keep publication blocked, and repair the incompatibility without reducing predecessor count, timeouts, or exact-package isolation.
 - **Documentation auto-merge fails:** leave the pull request open, inspect its exact
   changed-file classification, docs-sensitive inventory, and workflow permissions,

package/docs/features/launch-profiles.md

@@ -4,13 +4,16 @@
 
 | Command | Purpose | Pi user profile |
 |---|---|---|
-| `a1` | Fresh A1-owned Pi-compatible UI session | `~/.a1/agent` |
+| `a1` | A1 | `~/.a1/agent` |
 | `a1 --session <path\|id>` | Resume a persisted A1 session | `~/.a1/agent` (or explicitly selected storage) |
-| `a1 pi` | Pi-compatible comparison surface using the ordinary Pi profile | ordinary `~/.pi/agent` |
+| `a1 solo` | A1 direct single-agent mode | `~/.a1/agent` |
+| `a1 pi` | Pi-compatible direct comparison surface using the ordinary Pi profile | ordinary `~/.pi/agent` |
+
+`a1 solo` is available in release and prerelease builds. It starts A1 in single agent mode, is argument-free, and omits both 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 owned agent product surface and remains the entry point when multi-agent UX is introduced.
+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.
 
 ## First launch
 
@@ -42,7 +45,7 @@ a1 --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. Bare `a1` remains a fresh launch. Pi picker/continue CLI aliases and `a1 pi --session` are not supported by this repair; 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. The selected session opens in a new A1 tab or focuses the tab already holding it. Pi picker/continue CLI aliases, `a1 solo --session`, 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.
 
@@ -52,14 +55,14 @@ Regression evidence creates disposable sessions through Pi 0.84.2, then executes
 
 ## Terminal behavior
 
-Both launch forms run the A1-owned full-viewport TUI over pinned Pi engine, component, and terminal APIs. A1 owns composition, input routing, modal focus, selection behavior, scrolling, and restoration without inserting a PTY or terminal-byte relay. Bare `a1` enables A1-owned screens; `a1 pi` uses the same pipeline with those screens withheld.
+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.
 
 ## Concurrent instance lifecycle
 
-Every invocation receives a unique non-detachable launch instance. There is no product-wide foreground slot: the same profile or both profiles may run concurrently in separate terminals. Profile files remain shared according to the selected profile root, while process ownership, lifecycle outcome, and cleanup remain scoped to the command that launched them.
+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.
 
-Normal root exit, terminal closure, guardian failure, and verified update shutdown all close the instance's remaining process tree within bounded graceful and forced deadlines. Closing one instance never closes another. A control supervisor may remain idle afterward, but closed instances leave no UI, Pi, extension daemon, agent worker, tool, or descendant process.
+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.
 
 ## Recovery and comparison
 
-If bare `a1` cannot start or a UI workflow diverges, run `a1 pi` from the same working directory and compare the behavior. Profile data is intentionally separate, so authentication or settings may need to be configured independently. Use `a1 --version` to record the installed A1 release before reporting a difference.
+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.

package/docs/manual-resident-tabs-acceptance.md

@@ -0,0 +1,51 @@
+# Resident tabs physical acceptance
+
+This checklist certifies resident tabs on one platform against one published candidate package. Automated suites (simulation, crash points, fuzzing, the `resident-chaos` group, and exact-package tests) are required first; this checklist covers what only a real terminal, a real remote session, and a real operating system can show.
+
+## Rules
+
+- Install the exact published candidate with `a1 update --develop <version>` and record its version and the SHA-256 of `dist/native/<platform>-<arch>/terminal-host[.exe]` from its `terminal-host.manifest.json`.
+- Run on a manual operator machine or an isolated disposable worker. Physical automation never runs on an active workstation.
+- Each platform is certified independently: Windows x64, Linux x64, macOS arm64, and macOS x64. Evidence is never copied from another platform or another package.
+- Record every item as `pass`, `fail`, or `pending`. A platform is `CI-verified` while any item is `pending` or `fail`, and `certified` only when every item passes.
+- Do not paste prompts, terminal content, session files, or credentials into a record. Describe what was observed.
+
+## Checklist
+
+| # | Item | How to check | Expected |
+|---|---|---|---|
+| 1 | Terminal close mid-turn | Start a long streaming turn in a tab, close the terminal window. Reopen a terminal and run `a1`. | The turn kept running; the tab reattaches with its retained output and the turn's result. |
+| 2 | SSH or remote-session loss | Over SSH (or the platform's remote session), start a streaming turn, then drop the connection without exiting. Reconnect and run `a1`. | Same as item 1; no tab restarted. |
+| 3 | Forced attach-client kill | Kill the attach client process from another terminal while a turn streams. | The tab keeps running; the outer terminal is restored (cursor, modes, screen); `a1` reattaches. |
+| 4 | Reattach fidelity | After items 1–3, compare the reattached screen with what the tab showed. | Scrollback, colors, wide characters, and cursor position match; nothing is replayed twice. |
+| 5 | Input and render smoothness | Type quickly, paste a large block, resize repeatedly, and run a high-rate output command. | No lost or duplicated input, no stalls, no torn frames. |
+| 6 | Extension text UI | Open an extension that draws its own text UI inside a tab. | It renders and accepts input as in `a1 solo`. |
+| 7 | Two clients and controller transfer | Attach the same tab from two terminals and type in each in turn. | Control moves to the terminal that typed; each input is attributed to one client; nothing interleaves. |
+| 8 | Server, holder, and child failure | Kill the resident server, then one holder, then one tab's A1 process, using pids from `a1 tabs host status` and `a1 tabs`. | The server is replaced without losing tabs; the holder and the A1 process restart into the session; `a1 tabs host status` counts each recovery. |
+| 9 | Sensitive-data separation | Run `a1 tabs doctor` after items 1–8 and inspect the bundle. | Logs, crash records, status, and redacted registry only; no prompts, terminal content, journals, drafts, last screens, stderr, or credentials. |
+| 10 | Conflict-safe direct rollback | With tabs running, run `a1 solo` on a session a live tab holds, then `a1 tabs host stop`. | `a1 solo` refuses or forks the held session and never writes it; `a1 tabs host stop` stops every tab and the host. |
+| 11 | Logout (Linux) | On a `systemd` session with `KillUserProcesses=yes`, log out with tabs running, log back in, run `a1`. | Tabs end at logout as documented; previous sessions stay resumable; nothing is corrupted. |
+
+## Record template
+
+Each platform record lives at `docs/architecture/evidence/resident-tabs/<platform>.md`.
+
+```markdown
+# Resident tabs acceptance: <platform>
+
+State: CI-verified | certified
+
+| Field | Value |
+|---|---|
+| Package version | |
+| terminal-host SHA-256 | |
+| OS build | |
+| Terminal | |
+| Operator or worker | |
+| Date | |
+
+| # | Item | Verdict | Notes |
+|---|---|---|---|
+| 1 | Terminal close mid-turn | pending | |
+...
+```

package/docs/openspec-archive-automation.md

@@ -11,8 +11,8 @@ Version-1 and version-2 deliveries and their existing comments, acceptance PRs,
 1. **Draft plan:** create one normally named branch/PR such as `feature/...`, `fix/...`, or `chore/...`. Start the body with `## Proposal`, use it for one or two sentences of intent, and follow it with two to ten unchecked, outcome-sized task items under `## Implementation`. Omit generic process tasks, quoted phase lines, and routine validation command lists, and keep machine linkage under final collapsed `Automation`. Keep it draft and include only planning artifacts until the maintainer approves the plan and explicitly requests implementation.
 2. **Same-PR implementation:** continue after explicit approval in the same worktree, branch, history, draft PR, and phase-free body. Check an Implementation item as soon as its associated implementation, focused pre-ready evidence, and detailed task bookkeeping are complete; an ordinary progress edit changes only `[ ]` to `[x]` and is not deferred until handoff. Adding, removing, reordering, or rewriting an item is a scope refinement requiring explicit approval and coherent planning updates, with affected scope left unchecked. Reconcile approved refinements before corresponding code edits.
 3. **Complete evidence:** finish implementation, required pre-ready tests/evidence, substantive tasks, and explicit known-gap disposition. CI success is later objective evidence, not acceptance, and GitHub check counts are not Implementation task progress.
-4. **Plain acceptance list:** before checking the final item, keep the body phase-free and add final `## Acceptance` with one to ten concise implementation-specific behavior-and-result bullets. Do not use checkboxes, generic review/CI/approval/archive statements, URLs, mentions, or automated-test inventory.
-5. **Automatic readiness and finalization:** reconcile and push current `origin/develop`, then check the final item. That checkbox update completes the agent-owned implementation job; agents never mark implementation PRs ready themselves. Trusted automation revalidates the exact fully complete version-3 task-list snapshot and all pre-finalization inputs, marks the PR ready, and then conservatively synchronizes all deltas, moves the active change into its dated archive, stages the conditional acceptance manifest, commits that to the same branch with the archive App identity, and writes the emitted paths into the body's implementation fence. It never checks tasks or infers completion. Running the [finalization command](#finalization-command) locally first is optional and yields the same bytes.
+4. **Plain acceptance list:** before checking the final item, keep the body phase-free and add final `## Acceptance` with one to ten concise implementation-specific behavior-and-result bullets. Do not use checkboxes, generic review/CI/approval/archive statements, angle-bracket placeholders or HTML, URLs, mentions, or automated-test inventory.
+5. **Automatic readiness and finalization:** reconcile and push current `origin/develop`, run the [delivery body check](#delivery-body-check) on the intended final body, then check the final item. That checkbox update completes the agent-owned implementation job; agents never mark implementation PRs ready themselves. Trusted automation revalidates the exact fully complete version-3 task-list snapshot and all pre-finalization inputs, marks the PR ready, and then conservatively synchronizes all deltas, moves the active change into its dated archive, stages the conditional acceptance manifest, commits that to the same branch with the archive App identity, and writes the emitted paths into the body's implementation fence. It never checks tasks or infers completion. Running the [finalization command](#finalization-command) locally first is optional and yields the same bytes.
 6. **Validate:** one normal exact-head workflow validates the finalized head: implementation, synchronized specs, archive, manifest, tasks/evidence, exact PR-body list, and every selected product/governance scope before emitting the stable protected aggregate. A new commit or acceptance-list change re-finalizes automatically when needed and requires full renewed validation; no lifecycle body edit or second workflow run is required.
 7. **Maintainer integration accepts:** after reviewing the finalized candidate, an authorized human either manually merges the exact validated head after the stable protected aggregate succeeds or personally enables GitHub native auto-merge for that unchanged head so protected integration waits for the aggregate. That human action means the listed scenarios are accepted. Agents, Apps, bots, merge queue, automation-owned implementation arms, and documentation integration remain forbidden. A changed head, acceptance list, or finalization invalidates the earlier arm and requires the maintainer to choose again.
 8. **Verify and clean:** trusted post-merge policy derives `Archived` and reports `accepted-and-archived` from committed bytes and immutable GitHub provenance without editing the accepted PR body. It publishes no lifecycle branch or PR. Shared exact-head remote cleanup may delete the unchanged topic ref; local cleanup remains separately ownership-controlled: the agent parks the worktree with `handoff` at step 7, and the next session's `sweep` removes it once the merge, archive, and remote-ref evidence verify (see [local cleanup](local-worktree-cleanup.md)).
@@ -141,13 +141,25 @@ Use plain bullets:
 - Finalized specs and archive match the implementation.
 ```
 
+Each Implementation and Acceptance item is one line of 20 to 300 bytes. It must not contain angle-bracket text such as `<job>` or other HTML, URLs, or `@` mentions, and Acceptance items must not be checkboxes. Write a concrete example instead of a placeholder, such as `Develop / Build process guardian`.
+
+### Delivery body check
+
+Before checking the final Implementation item, write the intended final body to an ignored artifact file and run the same body validators that trusted promotion uses:
+
+```bash
+node scripts/governance/check-delivery-body.mjs --body-file .artifacts/agent/pr-body.md --final
+```
+
+`--final` validates the body as if every Implementation item were checked, so it can run before the last marker changes. `--pr <n>` reads the current pull request body instead. A defect exits 1 and prints the same `draft-<code>` reason the finalization run would report. The check covers association, Implementation, layout, and Acceptance only; detailed tasks, evidence, and target state remain covered by the [finalization command](#finalization-command) inspection mode.
+
 The committed conditional manifest contains the same ordered text. Trusted policy validates membership but never checks or edits it and never claims that the scenarios passed. The authorized maintainer's manual merge or personal native auto-merge arm for the unchanged exact head is the acceptance decision; no acceptance comment, checkbox edit, review-approval requirement, JSON edit, acceptance PR, archive PR, or later command is needed.
 
 If the body list changes, candidate validation reruns and compares it with the committed manifest. If the head changes, all prior exact-head CI is stale. If only the body changes to disagree with the manifest, integration remains blocked until the list and committed candidate agree again. No lifecycle body edit is needed after green CI.
 
 ## Automated finalization
 
-The `OpenSpec finalization` workflow (`.github/workflows/openspec-finalization.yml`) runs on `pull_request_target` for `opened`, `synchronize`, `ready_for_review`, `reopened`, and `edited` events targeting `develop`, one event at a time per PR. It checks out default-branch policy, installs the pinned tooling without hooks, and runs `scripts/governance/publish-openspec-finalization.mjs --pr <n>`; the PR head enters that process only as the `openspec/` tree the pinned OpenSpec engine reads. An all-checked version-3 task-list draft with valid Acceptance and complete detailed pre-finalization inputs is re-read as one exact snapshot and marked ready; no content is changed, and incomplete, malformed, legacy, unassociated, forked, or raced drafts remain draft with a stable reason. Closed PRs are skipped. For a ready version-3 candidate the workflow reconciles the head to its finalized form:
+The `OpenSpec finalization` workflow (`.github/workflows/openspec-finalization.yml`) runs on `pull_request_target` for `opened`, `synchronize`, `ready_for_review`, `reopened`, and `edited` events targeting `develop`, one event at a time per PR. It checks out default-branch policy, installs the pinned tooling without hooks, and runs `scripts/governance/publish-openspec-finalization.mjs --pr <n>`; the PR head enters that process only as the `openspec/` tree the pinned OpenSpec engine reads. An all-checked version-3 task-list draft with valid Acceptance and complete detailed pre-finalization inputs is re-read as one exact snapshot and marked ready; no content is changed, and incomplete, malformed, legacy, unassociated, forked, or raced drafts remain draft with a stable reason. A draft with any unchecked item is skipped quietly. A draft whose every task-list item is checked but whose promotion is refused for a body, task, evidence, or other content defect fails the run with an `OpenSpec finalization` error annotation naming the `draft-<code>` reason, so the stall shows as a red check instead of a green skip. Closed PRs are skipped. For a ready version-3 candidate the workflow reconciles the head to its finalized form:
 
 - **Active and current:** ordinary finalization with today's UTC date; one `docs(openspec): finalize <change>` commit.
 - **Finalized, valid, and current:** nothing is pushed; the run reports `already-finalized`.

package/docs/validation.md

@@ -24,6 +24,14 @@ npm run test:full                  # complete deduplicated local composition
 npm run test:release               # release gates; publication authority is unchanged
 ```
 
+Before every push, run the fast governance gates locally:
+
+```bash
+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.
+
 `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.
 
 Conservative Development retains every pull-request owner but does not schedule exhaustive owners. The complete regression implementation runs inside a PR only when base policy verifies an `openspec-ci` App-created repair, its generated candidate identity, and a failed Full regression source in `regression-provenance.json`. Publishing/prerequisite/validation-authority impact, shared inputs, unknown paths, labels, Publish-only repairs, and successful-run persistent-overrun candidates retain bounded ordinary validation. Planning-only generated repair drafts stay exempt; eligible implementation drafts get feedback without integration authority. The selected exact-head evidence must include Windows Node 22/24, Linux Node 24, and macOS Node 24. Full regression and nightly/stable release retain both cadence classes and the same coverage through the shared implementation. The real three-release `update-predecessor` exact-package oracle is exhaustive; deterministic predecessor command, fixture, materialization, warmup, package, and update contracts remain PR-eligible. Preview and release continue to consume exact candidate bytes under their channel-specific contracts. A standalone manual Full regression remains useful for diagnosis or an unselected candidate, but never replaces automatically selected current-PR evidence. The generated ownership ledger command is:
@@ -32,7 +40,7 @@ Conservative Development retains every pull-request owner but does not schedule
 node scripts/release/generate-validation-ownership-ledger.mjs --output .artifacts/validation/ownership-ledger.json
 ```
 
-The `terminal-host` owner is CI-only. A change under `native/terminal-host/` or to its run scripts selects Windows x64, Linux x64, and macOS arm64 **Native terminal host** jobs. Each builds the binary and Node-API lock artifact with Rust and Zig 0.15.2 for the lane's exact target and baseline CPU model, runs `npm run test:terminal-host`, and uploads the debug artifacts and frozen protocol manifest; Linux also runs bounded decoder fuzzing. 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 along with the installed process guardian. `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 `terminal-host` owner is CI-only. A change under `native/terminal-host/` or to its run scripts selects Windows x64, Linux x64, and macOS arm64 **Native terminal host** jobs. Each builds the binary and Node-API lock artifact with Rust and Zig 0.15.2 for the lane's exact target and baseline CPU model, runs `npm run test:terminal-host`, and uploads the debug artifacts and frozen protocol manifest; Linux also runs bounded decoder fuzzing. 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 along with the installed process guardian. 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).
 
 ## Windows Full regression shards
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@timurproko/a1",
-  "version": "0.2.7-dev.767",
+  "version": "0.2.7-dev.779",
   "description": "Standalone terminal workspace for supervised native and managed agents",
   "type": "module",
   "privateLaunchContract": "neutral-launch-v1",
@@ -25,8 +25,10 @@
     "clean": "node scripts/clean.mjs",
     "build": "node scripts/development/check-environment.mjs && npm run clean && tsc -p tsconfig.build.json && node scripts/release/generate-release-notes-resource.mjs && node scripts/pi/build-pi-settings-metadata.mjs && node scripts/pi/build-startup-public.mjs && node scripts/development/build-process-guardian.mjs && node scripts/release/generate-runtime-payload-inventory.mjs",
     "build:process-guardian": "node scripts/development/build-process-guardian.mjs",
+    "build:terminal-host": "node scripts/development/build-terminal-host.mjs",
     "typecheck": "tsgo -p tsconfig.json --noEmit && tsgo -p tsconfig.bin.json",
     "check:architecture": "node scripts/governance/check-architecture.mjs && node scripts/governance/check-session-writer-guard.mjs && node scripts/governance/check-product-identity-boundaries.mjs && node scripts/governance/check-package-identity.mjs && node scripts/governance/check-pinned-pi-source-ledger.mjs && node scripts/governance/check-terminal-host-provenance.mjs",
+    "preflight": "node scripts/development/run-preflight.mjs",
     "check:names": "node scripts/governance/product-identifier-policy.mjs --check",
     "check:names:changed": "node scripts/governance/product-identifier-policy.mjs --check --selection .artifacts/validation/impact.json",
     "check:code-documentation": "node scripts/governance/check-code-documentation.mjs --mode full",
@@ -49,6 +51,7 @@
     "test:full": "node scripts/release/run-validation-tier.mjs full-release",
     "test:release": "node scripts/release/run-release-gates.mjs",
     "test:terminal-host": "node scripts/development/run-terminal-host-probe.mjs",
+    "test:resident-chaos": "node scripts/development/run-resident-chaos.mjs --build",
     "test:pi-engine-conformance": "vitest run test/integrations/pi/engine/conformance.test.ts test/integrations/pi/engine/runtime-integration.test.ts test/integrations/pi/engine/session-integration.test.ts",
     "report:pi-engine-conformance": "npm run build --silent && node scripts/pi/run-pi-engine-conformance.mjs",
     "report:rendering-stability": "tsx scripts/pi/report-rendering-stability.ts",
@@ -57,6 +60,7 @@
     "update:pi-component-parity": "tsx scripts/pi/update-pi-component-parity.ts",
     "update:pi-event-frame-parity": "tsx scripts/pi/update-pi-event-frame-parity.ts",
     "proof:terminal-host": "node scripts/development/run-terminal-host.mjs",
+    "proof:terminal-host:ci": "node scripts/development/certify-ci-terminal-host.mjs",
     "start": "npm run build && node scripts/development/dev-launch.mjs",
     "start:pi": "npm run build && node scripts/development/dev-launch.mjs pi",
     "prepack": "node scripts/release/validate-packaged-release-note.mjs && node scripts/release/prepack-gate.mjs",