M8 release qualification plan

M8 is the active milestone. Slice 1 establishes the executable plan; slices 2–4 are in progress and slices 2–9 and all seven qualification items remain open. M6 remains complete only for the supervised Windows 11 x64 / Node 24 / local SQLite developer profile accepted by D-M6-01. M7’s scoped local acceptance is complete. No new platform, production, PostgreSQL or long-duration support is established by publishing this plan, and the released SDK 0.3.0 binaries retain their existing scope.

The repository’s M8 build/qualification plan is the execution contract. It includes evidence fields, operator/reviewer responsibilities, commands and per-slice stopping conditions. The backlog maps Q01–Q07 to it; BUILD-PLAN tracks completion. These repository links require access to the private project.

Ordered slices and claims

Slice	Work and dependencies	What a passing result enables
1 — plan	Complete as planning; follows bounded M6 and scoped M7	Execution can start; no support expansion
2 — exact-host capacity (Q01)	After 1; reference 4-vCPU/8-GiB and constrained 2-vCPU/4-GiB CP-01–CP-08 ladders	Measured component envelope and overload behavior for exact hosts/configurations
3 — native delivery candidates (Q05)	After 1; native hosts and signing access	Candidate install/upgrade evidence; platform support waits for 4/7/9
4 — real host boundaries (Q06)	After 1; concrete identity, secret, ACL, private IPC and containment adapters	Tested security contract for named adapters; unattended support waits for 5–7/9
5 — governed capacity/sizing (Q02)	After 2/3/4 for the same profile	Production-path measurements and allocated-storage retention estimates, not a general throughput promise
6 — endurance (Q04)	After 5; frozen candidate at sustainable load	Tested 24-hour and seven-day real-time envelope after both pass, not months-long reliability
7 — machine/storage recovery (Q07)	After 3/4 and representative load from 2 or 5	Enumerated sleep/restart/interruption/restore guarantees for tested storage
8 — PostgreSQL (Q03)	After 5’s SQLite baseline and 4’s host contract	Candidate conformance and identical-input comparison; support also needs backend-specific 3–7/9
9 — integrated release	After every gate applicable to the selected release profile	Exact version/platform/backend/adapter support statement backed by reviewed evidence

Slices 2/3/4 can proceed in parallel. Slice 7 can overlap 5/6; PostgreSQL implementation can overlap 6/7. Use separate measured hosts/allocations, installations, disks and evidence destinations. Native delivery preparation does not wait for real host adapters; final acceptance combines both, avoiding a circular dependency or fixture-based production claim.

The native target matrix remains Windows 11 25H2 x64/arm64, macOS 15 Intel/Apple Silicon, Ubuntu 24.04 and Debian 13 x64/arm64, and Debian 13 Docker linux/amd64 and linux/arm64. Test minimum and newest claimed OS versions separately, with current servicing verified at execution. Container/emulated results do not qualify a native cell. A limited release can list passing cells only; full M8 remains open until all Q-items and initial matrix requirements pass. PostgreSQL can be excluded from a SQLite release without pretending that Q03 is complete.

Evidence and pass/fail gates

Every attempt retains source/runtime/package/adapter hashes, exact host and storage proof, configuration/seeds, commands, budgets, real timing, raw latency/resource/fault logs, independent provider/receipt oracles, pre/post accounting and state reconciliation, and a named review decision. Keep aborted/failed attempts and immutable evidence inventories. No credentials or live databases belong in the public documentation or source download.

Capacity qualification uses three seeds, two-minute warmup, at least ten-minute measurement and 1,000 completed controls per cell. For the specified combined reference cell, inspect p95 must be at most 250 ms, pause/cancel p95 each 500 ms, available-capacity dispatch p95 250 ms, event-loop p99 100 ms, coordinator RSS 1 GiB and first authorized inspection after restart 30 seconds. Reference latency targets are diagnostics on constrained hosts; safe bounded backpressure remains mandatory. Fairness, ceilings, accounting and UNKNOWN ownership must hold at every load. Capacity qualification explains existing tools and their measurement boundaries. Whole-server RSS and simulated providers do not satisfy complete production resource attribution or governed dispatch measurements.

Stop a cell on its declared resource/time budget, safety failure or failed evidence capture. Higher unrun cells remain NOT_MEASURED. Stop and diagnose lost committed work, unauthorized dispatch, oversubscription, erased UNKNOWN responsibility, secret leaks or containment escape; shared defects block all affected claims. Missing native access, genuine adapters, signing capability or real elapsed duration is Blocked. A smoke pass, skipped test, fixture identity or clean process restart cannot replace its missing qualification gate.

Repeat only after a recorded diagnosis/fix or environment change. Keep targets and failures visible; approved target revisions apply to future attempts. Documentation-only updates do not require rerunning unchanged benchmarks. Runtime/schema/adapter changes need an impact review and reruns of invalidated evidence. One passing 24-hour soak leaves the seven-day gate open; accelerated clocks do not supply endurance or power-loss evidence.

Release decision

Slice 9 combines native acceptance, real enrollment and host boundaries, recovery, capacity/endurance, all applicable conformance cases, native SDK and shared parity tests, engine regressions, browser controls, package installs and supported migration/restore paths. Final candidate CI, examples, standard/profile, coverage, compatibility, runbooks, website/offline exports and source downloads must agree with the reviewed manifest.

The claim names the exact version, profile, OS/architecture, backend, adapters and tested workload/recovery/endurance envelope. Production or unattended wording needs all applicable gates, not just working authentication. Public publication still requires explicit owner authorization, separate from technical readiness and private repository updates.

Slice 2 now uses owner-selected Ubuntu 24.04 fixed Hyper-V guests on LIVING-ROOM, with separate 4-vCPU/8-GiB and 2-vCPU/4-GiB allocations. Provisioning is complete; both guests passed all eight component smoke checks and combined HTTPS smoke checks. The reference ladder is stopped after a recurring CP-04 stall, with 56 runs completed. Separate diagnostics reproduced a telemetry startup lock timeout and subsequent requests to dead workers. Timeout propagation and worker failure handling are validated separately; the campaign retains its original candidate. Monitoring continues diagnosis only until a reviewed decision on resumption. The execution record tracks evidence and stopping conditions; no Ubuntu capacity pass is claimed yet. The existing D-M6-01 acceptance and measurement-only reference reports remain unchanged. See deployment qualification for current candidate tooling.

Slice 3 delivery progress

The delivery preparation record inventories all ten cells, current signing inputs, native-host blockers and install/upgrade evidence requirements. The available Windows x64 host is shared with capacity qualification, so heavy local delivery testing is deferred. The capacity guests, checkout and evidence remain reserved for slice 2.

Windows x64 candidate 0.0.0-m8.2.1 now has a signed full-package catalog and passed all nine hosted package acceptance checks in run 36791069855. This is hosted Windows Server evidence, not native Windows 11 acceptance. Native installation, macOS notarization, supported binary/schema upgrade edges, migration interruption and state-preserving uninstall still require implementation or acceptance evidence. All native target cells remain unverified and D-M6-01 is unchanged.

Slice 3 now includes pinned package provenance, Docker runtime-schema parity and offline candidate install/replacement/deregistration tooling. Replacement stays held for native acceptance; no schema migration edge or production service updater is supplied. Existing platform and D-M6-01 claims remain unchanged.

Next is native acceptance of the selected signed candidate on an independent Windows 11 host or after slice 2 releases the local computer. Executable schema upgrades and other platform cells remain open. Slice 4 real identity/secret/ACL/IPC/containment adapter work can proceed separately while native access is unavailable. See the retained candidate review.

Slice 4 host boundary progress

Slice 4 has started with a Windows DPAPI CurrentUser secret adapter and an optional in-memory TLS credential provider. Provider errors stop control-host startup before opening the engine database; they never select a plaintext fallback. Hosted Windows component tests exercise real DPAPI with disposable fixture values. They do not qualify a service account, native Windows 11, or a complete production host.

The implementation record records selected mechanisms and infrastructure gaps. Owner enrollment/fresh human verification, service-profile availability, owner-only ACLs, authenticated worker IPC and restricted workloads remain open. Q06 and D-M6-01 are unchanged. The signed slice 3 candidate remains evidence for its original source, not these new adapters. See TLS provider integration.

Cross-platform local authentication direction

The selected enrollment direction is local OS-backed human verification on Windows, macOS and Linux. Organization OIDC remains an optional contract path; Entra setup is not required for this implementation direction. Concrete local authenticators and recovery mechanisms still need selection and native tests. An existing desktop login or a service credential cannot substitute for fresh verified human approval.

Windows DPAPI is the first secret adapter, not a restriction of the engine or SDKs to Windows. Shared engine contracts cover enrollment, authorization, sessions and worker access policy; platform adapters enforce secrets, permissions, private IPC and containment. The full Windows/macOS/Linux/Docker matrix remains M8 scope, with qualification per profile. Docker needs an explicitly bound human-verification integration and cannot assume a desktop authenticator inside the container.

Native Windows acceptance waits until slice 2 releases the selected computer. Other native acceptance hosts remain unallocated. The implementation record includes a draft policy limiting workers to task workspaces, approved tools and explicitly granted network/credential access. That policy is not yet an enforced capability. D-M6-01 remains the existing Windows developer acceptance boundary.

Slice 4 subslices

4A (complete as a contract increment) defines the portable access-policy contract, SDK parity and example. 4B is in progress with concrete resource/coding-plan bindings, human revocation and worker delivery fences. Policy-bound execution stays held pending live authority and native enforcement; 4C supplies OS adapters (the initial Windows DPAPI component is here); 4D integrates and qualifies each profile. Neither a valid policy document nor the DPAPI component closes Q06.

4C now includes internal preparation of installation-, owner-, service- and action-bound human-verification challenges. Their validity grants no identity or execution authority. The adapter preparation record describes the candidate Windows, macOS, Ubuntu, Debian and Docker integrations and tests. Durable one-time enrollment storage is implemented; genuine native verification and protected registration remain open. Service account, ACL, private IPC and containment acceptance follows; local Windows acceptance waits until slice 2 releases the host. Production startup and policy-bound dispatch remain blocked.

The internal enrollment store atomically consumes the setup capability, exact challenge and verified-identity handle with the owner grant and audit record. It checks current revision, trusted time, boot/auth/coordinator epochs and identity/service bindings. Competing commits produce one owner; replay rejects. Restart invalidates pending credentials while preserving established ownership. Recovery lock cannot be used to reset an owner. Capabilities and handles are stored as hashes and returned once.

These are trusted storage operations, not a public login/enrollment API. A genuine OS adapter must supply verified identity; tests use fixture facts only. No human session or execution authority is issued. Protect enrollment records as installation data, and do not downgrade their optional schema to a candidate that does not understand it.

The Windows Hello source component now creates or opens an OS-held signing key and requests a fresh Hello signature. Unsupported package/session contexts reject before prompting. The companion’s protected registration, service channel and native acceptance remain open. A strict signature checker binds proofs to the approved public key and exact live challenge, but explicitly does not claim verified human identity from a signature alone. Hosted compilation/negative checks and software-key tests cannot substitute for real interactive verification. Other platform adapters remain in M8 scope.

The Windows candidate now has an immutable public-key registration journal. Enrollment binds its review to the approved registration and owner policy, checks the signed challenge against that key plus trusted internal companion observations, and stores the proof receipt and one-use identity handle atomically. Observations expire within 30 seconds; commit rechecks expiry and key/channel revocation. Key revocation locks recovery without removing an established owner or work. The generic verification path cannot bypass registered checks.

This storage boundary does not authenticate a native peer by itself. Independent key approval, protected bootstrap/storage, companion packaging, authenticated IPC and automatic channel-disconnect observation still need implementation and native acceptance. Test keys and peer facts are fixtures only. No public login route, session provider or policy execution is enabled. The build plan keeps 4C in progress and retains macOS, Ubuntu, Debian and Docker as M8 targets; D-M6-01 remains unchanged.

Unsigned Windows companion packaging and a read-only owner setup review are now available as preparation components. The packaging recipe validates x64/arm64 payloads with MakeAppx, checks extracted payload hashes and uses the existing AIWS favicon for package assets. Hosted native CI retains unsigned candidates and reports; it does not install or trust them. The review shows installation/key fingerprints, pinned identities, proposed permissions and recovery instructions, rejecting policy text that does not match the registered digest. It escapes display text and has no approval controls, credentials or execution authority.

The initial preparation boundary described here is superseded by the opt-in integration below. Protected registration bootstrap, signed publisher/package approval, authenticated service IPC and native acceptance remain open. Full-trust desktop packaging is not worker containment. No local provisioning or interactive testing is authorized on the capacity host until it is released; other OS adapters and D-M6-01 boundaries remain unchanged.

The Windows companion now has a source-level transport foundation using local named pipes with explicit access rules, two-way checks of independently pinned processes/SIDs/sessions, identification-only client token checks and bounded messages/deadlines. Invalid or dropped connections close permanently. Hosted tests exercise real pipes using same-account fixtures; this does not establish service-account isolation or genuine native acceptance.

The initial transport component has since been connected to the helper and enrollment journal as described below. Trusted broker launch, package/signer verification, protected setup/review, disconnect revocation and per-platform acceptance remain open. No human identity or policy execution authority is granted by a successful pipe connection. Capacity resources and D-M6-01 remain unchanged.

The Windows source now checks a pinned MSIX archive’s signature, signer certificate, manifest identity and helper bytes before permitting a suspended owner-side launch. The installed helper must match, and the created process must have the expected package, owner, session and executable path before resume. File locks, restricted handle inheritance and an owned job protect this candidate’s launch lifecycle. It cannot elevate or switch users.

Hosted checks cover unsigned-package rejection, changed pins, manifest/payload matching, unpackaged-process rejection and file locks. The current unsigned artifacts cannot pass successful launch verification. Trusted signed artifacts, supported packaged activation, a broker watchdog, protected review/IPC and enrollment integration remain open. No login or enrollment endpoint is enabled, and no native acceptance runs on the capacity host.

Internal companion-session wiring now connects registered challenge creation, proof storage and owner commit. Disconnect/cancellation invalidates the channel; late replies are ignored, and cleanup cancels only the same pending enrollment. Normal completion also closes and revokes the channel. If commit wins a disconnect race, the owner remains enrolled; cleanup failure is reported without reopening setup. Tests use explicit software-key/native-fact fixtures and real storage workers.

The session port has no default provider or public endpoint. A qualified native broker must still supply package/process verification, protected review, real OS observations and owned helper shutdown. This wiring does not convert unsigned candidates or fixture facts into native identity, issue login sessions, or release the policy execution hold.

Reviewed setup now has an internal sequence from the exact permissions/recovery review to companion verification and durable owner enrollment. Declining the review does not open a helper; changing the caller’s data during review cannot change the signed setup request. Cancellation and engine restart are checked before enrollment.

On Windows, the native helper exchange now joins verified package launch to exact challenge delivery and bounded proof collection. The helper must acknowledge that it received the complete request before the sender closes input; this receipt is not identity evidence. An incomplete answer, missing/incorrect receipt, unexpected diagnostic output, failed helper, timeout or cancellation rejects; the helper is stopped on cleanup. Hosted fixtures cover these paths without invoking Windows Hello. They do not prove that a signed installed companion can activate successfully.

The Windows candidate now includes a native setup window and an authenticated bridge to the engine service. A first review creates a Windows-backed owner key; the second shows its actual fingerprint and requests verification before saving the owner. Declining, disconnecting or receiving an invalid proof leaves execution locked. Interrupted key creation can leave an unused key/registration requiring explicit reconciliation.

Trusted deployment code opts in through startControlHost.ownerBootstrap, with no work plans. It supplies an administrator-protected configuration and exact signed delivery pins; prepareWindowsOwnerConfiguration produces the configuration bytes and identity digests. The app checks the service process, while the service checks the owner process, account, interactive session and package. The engine uses its existing coordinator and storage writer, exposes setup completion through ownerSetup, and cancels setup during shutdown. No public setup route or login session is enabled. Enrollment grants no workflow execution.

The native workflow builds the app/helper MSIX for x64 and arm64. Manual signing retains a private installation candidate with exact package, signer and executable hashes. Headless CI checks do not invoke Hello or establish native qualification. Installation must still provision a distinct service account and verify protected paths/configuration/ACLs. Real owner verification, activation, permission denials, shutdown and containment await an allocated native host. This computer stays reserved for slice 2 until explicitly released. 4C remains open; D-M6-01, the policy execution hold and macOS/Linux M8 requirements remain.

PR #20 merged at 94393101db631a4b1ef0e820acb039d7109e95e1. The main signing run produced signed x64/arm64 owner-setup candidates; the earlier branch-only Azure rejection is resolved. Downloaded package/app bytes and packaged app/helper hashes matched the retained delivery records. Signing proves delivery provenance, not native qualification.

Offline preparation is available through node scripts/engine-owner-install.mjs: inspect <delivery-dir> <approved-report-sha256> checks the approved report and package/app hashes; prepare <delivery-dir> <approved-report-sha256> <reviewed-request.json> <new-staging-dir> also writes public owner-setup.bin and installation-plan.json. Obtain the report pin from the independently reviewed signing record, not the untrusted download itself. The plan binds the selected architecture, owner/service identities, package identity and installation paths. Target paths are data only; the tool never installs or launches binaries, changes accounts/ACLs/services, opens a database or grants workflow authority.

Preparation does not validate actual account memberships, signatures on this host, package identity, filesystem protections or service communication. Those checks, genuine owner verification and containment acceptance still require an allocated native host. The fresh slice 2 campaign retains this computer. 4C/4D remain open, execution stays held, and macOS/Linux adapters remain required. D-M6-01 is unchanged.