@timurproko/a1 0.2.7-dev.792 → 0.2.7-dev.801

package/docs/openspec-archive-automation.md

@@ -1,6 +1,6 @@
 # Atomic OpenSpec delivery and legacy archival
 
-New OpenSpec deliveries use one ordinary development pull request from draft planning through implementation, validation, acceptance, specification synchronization, and archival. An authorized maintainer chooses integration by manually merging the exact validated head or personally enabling GitHub native auto-merge for that unchanged head. Agents, Apps, bots, merge queue, and repository automation never arm or invoke implementation integration and never create a version-3 acceptance or archive follow-up PR.
+New OpenSpec deliveries use one ordinary development pull request from draft planning through implementation, validation, acceptance, specification synchronization, and archival. An authorized maintainer chooses integration by manually merging the exact validated head, personally enabling GitHub native auto-merge for that unchanged head, or explicitly asking the active agent to merge the identified currently eligible head. Agents never infer or independently choose integration; Apps, bots, merge queue, workflows, and repository automation receive no implementation authority, and no version-3 acceptance or archive follow-up PR is created.
 
 Unrelated standalone documentation remains separate: a non-draft unassociated PR changing only `openspec/**`, `docs/**`, and/or root `README.md` retains the existing CI-gated automatic route. A new active change, implementation association, malformed lifecycle data, or mixed path remains outside documentation-owned integration. Before finalization or without valid human provenance, any arm is disabled; a finalized version-3 human arm remains a separate maintainer-owned route.
 
@@ -8,15 +8,29 @@ Version-1 and version-2 deliveries and their existing comments, acceptance PRs,
 
 ## Version-3 lifecycle
 
-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`. Each item names a delivered code outcome. Omit generic process tasks; run, verify, validate, evidence, or manual-test items; 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.
+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 one or more unchecked, outcome-sized task items under `## Implementation`, with no fixed maximum. Each item names a delivered code outcome. Omit generic process tasks; run, verify, validate, evidence, or manual-test items; 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 code and tests are written and its detailed task bookkeeping is 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 implementation:** finish the code and its tests, substantive tasks, and explicit known-gap disposition. CI runs those tests after readiness; its success is objective evidence, not acceptance, and GitHub check counts are not Implementation task progress. Manual validation is the maintainer's optional choice before integrating and never blocks a checkbox, finalization, or merge.
 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.
+7. **Maintainer integration accepts:** after reviewing the finalized candidate, an authorized human manually merges the exact validated head, personally enables GitHub native auto-merge for that unchanged head, or explicitly asks the active agent to merge that identified head while it is currently eligible. The agent route re-reads authoritative state, requires the exact finalized head and acceptance list, current `develop`, successful `Development validation required`, positive mergeability, and the maintainer's authenticated human `User`, then issues one protected squash merge with expected-head enforcement. It never waits, arms auto-merge, retries later, uses automation credentials or merge queue, or bypasses protection. Each route means the listed scenarios are accepted. A candidate change invalidates the decision 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)).
 
+### Maintainer-requested agent merge
+
+The permission is one-shot and candidate-bound. A same-session instruction such as “merge it” is sufficient only when the conversation identifies one handed-off PR and head unambiguously; implementation approval, green CI, an earlier request, or a standing preference is not merge authority. If the PR is not currently eligible, report the blocker and stop. Do not poll, watch, arm native auto-merge, or retain the instruction for later.
+
+Immediately before mutation, refresh the PR and authenticated principal. Require an open non-draft same-repository PR into `develop`, the requested exact finalized head and acceptance list, `MERGEABLE`/`CLEAN` state, successful `Development validation required` for that head, and a human `User` with write, maintain, or admin repository permission. Then use the ordinary protected route with no `--admin` or `--auto`:
+
+```bash
+gh pr merge <pr> --repo <owner>/<repository> --squash --match-head-commit <exact-head-sha>
+```
+
+GitHub branch protection remains authoritative. A refusal, changed head, advanced target, stale finalization, failed or pending check, ambiguous identity, or unavailable read ends the attempt and needs a fresh maintainer request. After success, use the ordinary read-only accepted/archive verification and cleanup path.
+
+The policy PR introducing this route must integrate through the previously deployed maintainer-owned route. Only a later candidate may use a requested agent merge after this policy is present on `develop`.
+
 ### Complete-regression evidence ordering
 
 PR-attached Full regression is selected only for a repair that the trusted triage created from a failed Full regression: base policy verifies the immutable `openspec-ci` App author, generated candidate identity, and `regression-provenance.json`. Human-authored lookalikes, publishing or validation-authority changes, labels, Publish-only repairs, and successful-run persistent-overrun candidates retain bounded ordinary validation. Generated repair drafts run no Development test suites, including after implementation begins. Finish substantive implementation tasks, focused local evidence, pre-finalization observations, and known-gap disposition before checking the final Implementation item. The ready active head defers testing while trusted finalization publishes the candidate; the finalized head then receives all four native lanes as new full evidence, required by `Development validation required` alongside the existing gates.
@@ -27,7 +41,7 @@ The implementation, synchronized canonical specs, conditional acceptance record,
 
 ## Draft PR body
 
-The first screen should separate purpose from delivery detail, not foreground CI mechanics. Distill `Proposal` into one or two sentences answering why the PR exists, then put two to ten unchecked, implementation-specific outcomes under `Implementation`. They are a coarse progress summary, not a copy of the detailed OpenSpec task ledger:
+The first screen should separate purpose from delivery detail, not foreground CI mechanics. Distill `Proposal` into one or two sentences answering why the PR exists, then put one or more unchecked, implementation-specific outcomes under `Implementation`, with no fixed maximum. They are a coarse progress summary, not a copy of the detailed OpenSpec task ledger:
 
 ```markdown
 ## Proposal
@@ -153,13 +167,13 @@ node scripts/governance/check-delivery-body.mjs --body-file .artifacts/agent/pr-
 
 `--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.
+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 direct merge, personal native auto-merge arm, or explicit request for the active agent to merge the unchanged currently eligible 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. 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:
+The `OpenSpec finalization` workflow (`.github/workflows/openspec-finalization.yml`) runs on `pull_request_target` for `opened`, `synchronize`, `ready_for_review`, `converted_to_draft`, `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 finalized PR returned to draft is promoted again when its body still has every item checked, its fence names the exact head as finalized, and the tree holds exactly that archive with no active change; otherwise it stays draft with `draft-finalization-redraft-form`. 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`.
@@ -214,7 +228,7 @@ Before a first finalization, canonical specs must still equal the selected targe
 
 ## Conditional acceptance and derived receipt
 
-`acceptance.md` truthfully says its verdict activates only when an authorized human manually merges the containing exact head after required current-head checks or personally arms native auto-merge for that unchanged head and GitHub integrates it after those checks. Its `openspec-delivery` block records stable pre-merge facts:
+`acceptance.md` truthfully says its verdict activates only when an authorized human directly merges the containing exact head after required current-head checks, explicitly asks the active agent to execute that protected exact-head merge while it is eligible, or personally arms native auto-merge for the unchanged head and GitHub integrates it after those checks. Its `openspec-delivery` block records stable pre-merge facts:
 
 - schema version, repository, change, and source PR;
 - archive and manifest paths and finalization date;
@@ -223,7 +237,7 @@ Before a first finalization, canonical specs must still equal the selected targe
 - archive, canonical-spec, task, and evidence digests; and
 - explicit known-gap dispositions.
 
-It does not predict source head, merge commit, merger, or merge time. The PR head contains the manifest, so required CI binds those bytes without a recursive self-hash. After merge, the shared reader combines the manifest with immutable GitHub source head, successful required run, authorized human actor and permission, integration route, merge commit/time, and `develop` ancestry. Direct manual integration requires no active automatic authority. Human-enabled native auto-merge additionally requires a matching final-head enable event and `auto_merge.enabled_by`, with no later candidate commit or disable event. Queue, App/Bot, automation-owned, stale, malformed, or differently authored authority remains invalid. A human enable followed by disable before a valid manual merge is an abandoned attempt, not contradictory provenance. That shared result is the durable version-3 receipt used by audit and cleanup.
+It does not predict source head, merge commit, merger, or merge time. The PR head contains the manifest, so required CI binds those bytes without a recursive self-hash. After merge, the shared reader combines the manifest with immutable GitHub source head, successful required run, authorized human actor and permission, integration route, merge commit/time, and `develop` ancestry. Direct integration, including an explicitly requested agent invocation through the maintainer's credential, requires no active automatic authority and retains the same authenticated-human merge provenance. Human-enabled native auto-merge additionally requires a matching final-head enable event and `auto_merge.enabled_by`, with no later candidate commit or disable event. Queue, App/Bot, automation-owned, stale, malformed, or differently authored authority remains invalid. A human enable followed by disable before a valid direct merge is an abandoned attempt, not contradictory provenance. That shared result is the durable version-3 receipt used by audit and cleanup.
 
 Unavailable, stale, automatic, unauthorized, conflicting, or contradictory provenance produces `invalid-provenance`/`blocked`, not acceptance. Post-merge code does not repair it by pushing `develop` or publishing another PR.
 
@@ -277,7 +291,7 @@ This bootstrap policy itself finishes under deployed version-2 authority. The fi
 - draft planning remaining unmerged;
 - explicit plan approval and same-PR implementation;
 - automated current-target finalization and exact-head CI;
-- authorized human integration, including manual merge and personally enabled exact-head native auto-merge, with plain acceptance scenarios;
+- authorized human integration, including direct merge, an explicit exact-head agent-merge request, and personally enabled exact-head native auto-merge, with plain acceptance scenarios;
 - integrated canonical specs/archive and no generated acceptance/archive PR;
 - read-only `accepted-and-archived` verification and exact-head branch cleanup;
 - stale head/body/base/arm, incomplete tasks/evidence, malformed manifest, and automated or unauthorized auto-merge refusal fixtures; and

package/docs/validation.md

@@ -48,7 +48,11 @@ 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, 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); the build-and-probe job runs `npm run test:terminal-host` with the role suite skipped (`TERMINAL_HOST_PARTITION=none`), building the binary and Node-API lock artifact with Rust and Zig 0.15.2 for the lane's exact target and baseline CPU model and uploading the debug artifacts and frozen protocol manifest; Linux also runs bounded decoder fuzzing. 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. 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 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).
+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); 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`), 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.
+
+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).
 
 ## Windows Full regression shards
 
@@ -122,7 +126,7 @@ Download these artifacts from the exact workflow run:
 
 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.
 
-Draft pull requests run no Development test suites. A ready version-3 PR whose body still identifies an active change defers testing and emits no protected aggregate while `OpenSpec finalization` publishes the candidate. A ready unassociated PR also fails closed when immutable base/head evidence shows that it introduces or restores active delivery content, or combines active-change edits with code or operational paths; it does not fall through to ordinary validation merely because its body fence is absent. Existing active-change documentation-only revisions and ordinary code PRs without active delivery paths retain their established routes. After finalization records the archive and acceptance manifest, the ordinary exact-head workflow runs selected product/governance lanes and `Finalized delivery validation` in parallel, then emits the stable protected `Development validation required` aggregate only when both authorities succeed. Green CI enables maintainer review and manual merge but does not claim human acceptance or merge automatically. The finalization fence update is the validation trigger, so no pre-finalization test run or later lifecycle body edit is required. Any subsequent eligible implementation commit changes the head and reruns applicable validation; any body change reruns readiness and finalized-record validation and must continue to match the committed manifest. Legacy acceptance-record-only PRs retain their separate trusted `Acceptance record validation` route. Queue availability remains explicitly unavailable inside a runner and is calculated from the Actions API during final run analysis rather than guessed.
+Draft pull requests run no Development test suites. A ready version-3 PR whose body still identifies an active change defers testing and emits no protected aggregate while `OpenSpec finalization` publishes the candidate. A ready unassociated PR also fails closed when immutable base/head evidence shows that it introduces or restores active delivery content, or combines active-change edits with code or operational paths; it does not fall through to ordinary validation merely because its body fence is absent. Existing active-change documentation-only revisions and ordinary code PRs without active delivery paths retain their established routes. After finalization records the archive and acceptance manifest, the ordinary exact-head workflow runs selected product/governance lanes and `Finalized delivery validation` in parallel, then emits the stable protected `Development validation required` aggregate only when both authorities succeed. Green CI enables maintainer review and an explicit integration decision but does not claim human acceptance or merge automatically. After green exact-head validation, the maintainer may directly merge, personally arm native auto-merge, or explicitly ask the active agent to perform one expected-head protected squash merge for that currently eligible candidate. The finalization fence update is the validation trigger, so no pre-finalization test run or later lifecycle body edit is required. Any subsequent eligible implementation commit changes the head and reruns applicable validation; any body change reruns readiness and finalized-record validation and must continue to match the committed manifest. Legacy acceptance-record-only PRs retain their separate trusted `Acceptance record validation` route. Queue availability remains explicitly unavailable inside a runner and is calculated from the Actions API during final run analysis rather than guessed.
 
 ## Rollback
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@timurproko/a1",
-  "version": "0.2.7-dev.792",
+  "version": "0.2.7-dev.801",
   "description": "Standalone terminal workspace for supervised native and managed agents",
   "type": "module",
   "privateLaunchContract": "neutral-launch-v1",
@@ -23,7 +23,9 @@
   },
   "scripts": {
     "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": "node scripts/development/check-environment.mjs && npm run build:managed && node scripts/development/prepare-local-terminal-host.mjs && node scripts/release/generate-runtime-payload-inventory.mjs",
+    "build:core": "node scripts/development/check-environment.mjs && npm run build:managed && node scripts/release/generate-runtime-payload-inventory.mjs",
+    "build:managed": "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",
     "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",
@@ -51,6 +53,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-parallel-progress": "node scripts/development/verify-resident-parallel-progress.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",
@@ -65,7 +68,7 @@
     "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",
     "prepublishOnly": "npm run test:release",
-    "prepare": "npm run build",
+    "prepare": "npm run build:core",
     "typecheck:bin": "tsgo -p tsconfig.bin.json"
   },
   "dependencies": {

package/dist/foundation/process-containment/darwin-process-inspector.d.ts

@@ -1,5 +0,0 @@
-import { WindowsNativeProcessInspector, type InspectorCommandRunner } from "./windows-process-inspector.js";
-/** Verifies Darwin process identity through the bounded native guardian inspection command. */
-export declare class DarwinNativeProcessInspector extends WindowsNativeProcessInspector {
-    constructor(helperPath: string, runner?: InspectorCommandRunner);
-}

package/dist/foundation/process-containment/darwin-process-inspector.js

@@ -1,7 +0,0 @@
-import { WindowsNativeProcessInspector } from "./windows-process-inspector.js";
-/** Verifies Darwin process identity through the bounded native guardian inspection command. */
-export class DarwinNativeProcessInspector extends WindowsNativeProcessInspector {
-    constructor(helperPath, runner) {
-        super(helperPath, runner, "darwin-proc-start:");
-    }
-}

package/dist/foundation/process-containment/native-guardian-containment.js

@@ -1,152 +0,0 @@
-import { spawn } from "node:child_process";
-import { mkdir, readFile, rm } from "node:fs/promises";
-import { dirname, resolve } from "node:path";
-import { PRODUCT_IDENTITY } from "../../product-identity.js";
-/** Delegates one root runtime to the native guardian and exposes its verified containment identity. */
-export class NativeGuardianContainment {
-    #identity;
-    #helper = null;
-    #rootIdentity = null;
-    #outcome = null;
-    instanceId;
-    helperPath;
-    statusPath;
-    exitNoticePath;
-    constructor(instanceId, helperPath, statusPath, exitNoticePath = null) {
-        this.instanceId = instanceId;
-        this.helperPath = helperPath;
-        this.statusPath = statusPath;
-        this.exitNoticePath = exitNoticePath;
-        this.#identity = { provider: "native-guardian-pending", token: instanceId };
-    }
-    get identity() {
-        return this.#identity;
-    }
-    async spawn(executable, arguments_, options) {
-        if (this.#helper)
-            throw new Error("process containment already has a root runtime");
-        await mkdir(dirname(this.statusPath), { recursive: true, mode: 0o700 });
-        await rm(this.statusPath, { force: true });
-        if (this.exitNoticePath)
-            await rm(this.exitNoticePath, { force: true });
-        const helper = spawn(this.helperPath, [
-            "--parent-pid", String(process.pid),
-            "--instance", this.instanceId,
-            "--status-file", this.statusPath,
-            ...(this.exitNoticePath ? ["--exit-notice", this.exitNoticePath] : []),
-            "--", executable, ...arguments_,
-        ], {
-            cwd: options.cwd,
-            env: {
-                ...options.environment,
-                ...(options.terminalType ? { TERM: options.terminalType } : {}),
-                // Protocol: the runtime arms this notice and the guardian prints it if the runtime dies unclean.
-                ...(this.exitNoticePath ? { [PRODUCT_IDENTITY.environment.exitNoticePath]: this.exitNoticePath } : {}),
-            },
-            shell: false,
-            stdio: "inherit",
-            windowsHide: false,
-        });
-        this.#helper = helper;
-        this.#outcome = helperOutcome(helper);
-        const status = await waitForReadyStatus(this.statusPath, this.#outcome, 5_000);
-        this.#rootIdentity = { pid: status.pid, startIdentity: status.startIdentity };
-        this.#identity = { provider: status.containmentProvider, token: status.containmentToken };
-        return { identity: this.#rootIdentity, outcome: this.#outcome };
-    }
-    async contains(identity) {
-        return this.#rootIdentity !== null
-            && identity.pid === this.#rootIdentity.pid
-            && identity.startIdentity === this.#rootIdentity.startIdentity;
-    }
-    async stop(force) {
-        const root = this.#rootIdentity;
-        if (!root)
-            return;
-        try {
-            process.kill(root.pid, force ? "SIGKILL" : "SIGTERM");
-        }
-        catch { }
-    }
-    async waitForEmpty(timeoutMs) {
-        if (!this.#helper || this.#helper.exitCode !== null || this.#helper.signalCode !== null)
-            return true;
-        return await new Promise(resolvePromise => {
-            const timer = setTimeout(() => finish(false), timeoutMs);
-            timer.unref();
-            const finish = (empty) => {
-                clearTimeout(timer);
-                this.#helper?.off("close", onClose);
-                resolvePromise(empty);
-            };
-            const onClose = () => finish(true);
-            this.#helper?.once("close", onClose);
-        });
-    }
-    async close() {
-        const helper = this.#helper;
-        if (helper && helper.exitCode === null && helper.signalCode === null)
-            helper.kill("SIGKILL");
-        await this.waitForEmpty(1_500);
-        await rm(this.statusPath, { force: true });
-        if (this.exitNoticePath)
-            await rm(this.exitNoticePath, { force: true });
-    }
-}
-export function resolveProcessGuardianPath(releaseRoot, environment = process.env, platform = process.platform, architecture = process.arch) {
-    const override = environment[PRODUCT_IDENTITY.environment.processGuardianPath]?.trim();
-    if (override)
-        return resolve(override);
-    const executable = platform === "win32"
-        ? `${PRODUCT_IDENTITY.artifacts.processGuardianExecutable}.exe`
-        : PRODUCT_IDENTITY.artifacts.processGuardianExecutable;
-    return resolve(releaseRoot, "dist", "native", `${platform}-${architecture}`, executable);
-}
-function helperOutcome(helper) {
-    return new Promise(resolvePromise => {
-        let settled = false;
-        const settle = (outcome) => {
-            if (settled)
-                return;
-            settled = true;
-            resolvePromise(outcome);
-        };
-        helper.once("error", error => settle({ kind: "guardian-error", message: error.message, code: errorCode(error) }));
-        helper.once("close", (code, signal) => {
-            if (signal)
-                settle({ kind: "signaled", signal });
-            else
-                settle({ kind: "exited", exitCode: code ?? 1 });
-        });
-    });
-}
-async function waitForReadyStatus(path, outcome, timeoutMs) {
-    const deadline = Date.now() + timeoutMs;
-    let terminalOutcome = null;
-    void outcome.then(value => { terminalOutcome = value; });
-    while (Date.now() < deadline) {
-        try {
-            const value = JSON.parse(await readFile(path, "utf8"));
-            if (isReadyStatus(value))
-                return value;
-            throw new Error("process guardian published invalid ready status");
-        }
-        catch (error) {
-            if (!(error instanceof Error && "code" in error && error.code === "ENOENT"))
-                throw error;
-        }
-        if (terminalOutcome)
-            throw new Error(`process guardian exited before readiness: ${JSON.stringify(terminalOutcome)}`);
-        await new Promise(resolvePromise => setTimeout(resolvePromise, 20));
-    }
-    throw new Error(`process guardian did not publish readiness within ${timeoutMs}ms`);
-}
-function isReadyStatus(value) {
-    return Number.isSafeInteger(value.pid) && Number(value.pid) > 0
-        && typeof value.startIdentity === "string" && value.startIdentity.length > 0
-        && typeof value.containmentProvider === "string" && value.containmentProvider.length > 0
-        && typeof value.containmentToken === "string" && value.containmentToken.length > 0;
-}
-function errorCode(error) {
-    return "code" in error && typeof error.code === "string" ? error.code : null;
-}

package/dist/foundation/process-containment/windows-process-inspector.d.ts

@@ -1,19 +0,0 @@
-import type { NativeProcessIdentity } from "../lifecycle/index.js";
-import type { NativeProcessInspector } from "./contracts.js";
-export interface InspectorCommandResult {
-    readonly exitCode: number;
-    readonly stdout: string;
-    readonly stderr: string;
-}
-export interface InspectorCommandRunner {
-    run(executable: string, arguments_: readonly string[]): Promise<InspectorCommandResult>;
-}
-/** Verifies Windows process identity through the bounded process-guardian inspection command. */
-export declare class WindowsNativeProcessInspector implements NativeProcessInspector {
-    readonly helperPath: string;
-    private readonly runner;
-    private readonly identityPrefix;
-    constructor(helperPath: string, runner?: InspectorCommandRunner, identityPrefix?: string);
-    observe(pid: number): Promise<NativeProcessIdentity | null>;
-    matches(identity: NativeProcessIdentity): Promise<boolean>;
-}

package/dist/foundation/process-containment/windows-process-inspector.js

@@ -1,56 +0,0 @@
-import { execFile } from "node:child_process";
-/** Verifies Windows process identity through the bounded process-guardian inspection command. */
-export class WindowsNativeProcessInspector {
-    helperPath;
-    runner;
-    identityPrefix;
-    constructor(helperPath, runner = defaultRunner, identityPrefix = "windows-filetime:") {
-        this.helperPath = helperPath;
-        this.runner = runner;
-        this.identityPrefix = identityPrefix;
-        if (!helperPath || helperPath.includes("\0"))
-            throw new TypeError("process guardian helper path is invalid");
-    }
-    async observe(pid) {
-        if (!Number.isSafeInteger(pid) || pid <= 0)
-            throw new TypeError("inspected PID must be a positive safe integer");
-        const result = await this.runner.run(this.helperPath, ["--inspect-pid", String(pid)]);
-        if (result.exitCode === 3)
-            return null;
-        if (result.exitCode !== 0) {
-            const detail = result.stderr.trim() || `helper exited ${result.exitCode}`;
-            throw Object.assign(new Error(`cannot inspect native process identity: ${detail}`), { code: "PROCESS_INSPECTION_FAILED" });
-        }
-        let value;
-        try {
-            value = JSON.parse(result.stdout);
-        }
-        catch {
-            throw Object.assign(new Error("process guardian returned malformed identity data"), { code: "PROCESS_INSPECTION_INVALID" });
-        }
-        if (!isIdentity(value) || value.pid !== pid || !value.startIdentity.startsWith(this.identityPrefix)) {
-            throw Object.assign(new Error("process guardian returned mismatched identity data"), { code: "PROCESS_INSPECTION_INVALID" });
-        }
-        return value;
-    }
-    async matches(identity) {
-        const observed = await this.observe(identity.pid);
-        return observed !== null && observed.startIdentity === identity.startIdentity;
-    }
-}
-const defaultRunner = {
-    async run(executable, arguments_) {
-        return await new Promise(resolvePromise => {
-            execFile(executable, [...arguments_], { windowsHide: true, timeout: 2_000, maxBuffer: 8 * 1_024 }, (error, stdout, stderr) => {
-                const exitCode = error && "code" in error && typeof error.code === "number" ? error.code : error ? 1 : 0;
-                resolvePromise({ exitCode, stdout, stderr });
-            });
-        });
-    },
-};
-function isIdentity(value) {
-    return typeof value === "object" && value !== null
-        && "pid" in value && Number.isSafeInteger(value.pid) && Number(value.pid) > 0
-        && "startIdentity" in value && typeof value.startIdentity === "string"
-        && value.startIdentity.length > 0 && value.startIdentity.length <= 512 && !value.startIdentity.includes("\0");
-}