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

package/docs/architecture/evidence/terminal-host-spike/terminal-spike-acceptance-record.json

@@ -1,18 +0,0 @@
-{
-  "schema": "a1-terminal-spike-acceptance-record-v1",
-  "recordedAt": "2026-08-14T07:12:07.445Z",
-  "change": "evolve-bare-a1-into-multi-agent-workspace",
-  "hostMode": "console-inside-existing-terminal",
-  "artifact": null,
-  "technicalVerdict": "pending",
-  "physicalVerdict": "pending",
-  "physicalMethod": "not-run",
-  "decision": "pending",
-  "integrationAllowed": false,
-  "milestoneMergeAllowedForComposedTerminal": false,
-  "waivers": [],
-  "waiverPolicy": "no-waivers-after-evidence",
-  "structuredWorkIndependent": true,
-  "transparentModesIndependent": true,
-  "notes": "Acceptance is pending the isolated in-terminal 2x2 spike artifact and a manual or isolated-worker physical verdict."
-}

package/docs/architecture/native-fixture-isolation.md

@@ -1,23 +0,0 @@
-# Native fixture validation
-
-## Normal automatic CI
-
-Development, Full regression and publication run native builds and fixtures directly on their normal GitHub-hosted runners. The agent-added sandbox, restricted OS accounts, network provisioning, fixture receipts, feature/runtime permission checks and additional security gates have been removed.
-
-The existing required suites remain required: terminal-host partitions, release isolation, resident chaos, exact-package published-predecessor continuity, terminal fidelity/latency certificates and bounded decoder fuzzing. Their platform coverage and product assertions are unchanged. Production publication protection is unchanged.
-
-When implementation outcomes are complete, trusted readiness/finalization publishes the exact candidate head and normal PR validation starts automatically. A repair push triggers the same flow for its new head. No fixture approval, deployment review, manual dispatch or workflow restart is required. Failed, missing or cancelled required results block integration; the maintainer chooses when to merge after required checks pass.
-
-## Optional local checks
-
-`npm run check:local` runs typechecking, architecture/identity/naming checks and non-native workflow regression tests. It does not build native artifacts or launch application/fixture processes. It is a convenience command, not an execution permission system or a prerequisite for CI advancement.
-
-The previous Defender report is unresolved historical evidence, not a passing security verdict. This workflow rollback changes no workstation protection setting or quarantined file.
-
-## macOS custody
-
-The macOS predecessor custody repair remains independent of CI provisioning. `getaudit_addr` supplies kernel audit user/session IDs; `audit_session_self()` returns only a process-local Mach port name.
-
-For immutable predecessors using the older metadata, the explicit source route still requires unchanged boot, exact native PID/start identity, source credentials/epoch and a connected kernel `LOCAL_PEERTOKEN` matching PID, real/effective UID and current audit user/session. Incomparable metadata is retained, not treated as proof of login equality or termination. Generic cross-release admission is unchanged.
-
-Static/workflow tests are not native platform execution evidence. Required exact-head native results remain the CI authority.

package/docs/architecture/process-guardian-provenance.md

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

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

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