release: freeze Nexus One AI 1.0.0-rc1

specs/001-enterprise-experience/analysis/gate-1-decision-dossier.md

@@ -0,0 +1,119 @@
+# Gate 1 Decision and Evidence Dossier
+
+**Status**: All 30 architecture decisions approved; Gate 1 closure is recorded as **PASS** in
+`gate-evidence-allocation.md`. Evidence-open conditions are allocated to Gates 2-6. Implementation is
+still not authorized by this docs-only task.
+
+**Scope**: Offline Workstation AMD64 first implementation target plus shared contracts required by
+all four bootable products. Approval here does not authorize ISO building, installer implementation,
+Server-offline implementation or general release.
+
+## How to Record a Decision
+
+For every row, the visible accountable organization is **Cezen Technologies**. Record the chosen value
+or explicit risk acceptance, an internal approval-record ID, decision date, expiry/review date where
+applicable, evidence URI/path and status `approved`, `rejected` or `deferred`. The authorized human
+approver and role MUST be attributable inside access-controlled approval evidence but need not be
+named in this repository. A deferred mandatory row keeps Gate 1 failed. Any amendment to a normative
+contract requires a consistency-analysis rerun before approval.
+
+This privacy convention does not weaken separation of duties: where executor and independent reviewer
+must differ, the restricted approval/evidence record proves they are different authorized people even
+though the public specification displays only Cezen Technologies and opaque record IDs.
+
+## A. Trust, Signing and Threat Ownership
+
+| ID | Decision required | Recommended baseline / acceptable outcome | Accountable roles | Required evidence | Status |
+|---|---|---|---|---|---|
+| G1-01 | Release/license/test trust-domain separation and Ed25519 release signatures | Approve `release-signing-trust.md`; retain RSA license compatibility as a separate domain | Security, Platform | Trust-domain hierarchy and purpose constraints approved under `CT-G1-2026-003` | Approved 2026-07-14 |
+| G1-02 | Signing hardware, root/subordinate generation, backup and custody | Non-exportable signer where supported; offline root; dual/threshold custody; named primary and alternate custodians | Security | Offline-root/isolated-signer/dual-or-threshold direction approved under `CT-G1-2026-003`; hardware, locations, custodians and ceremony evidence open | Approved 2026-07-14; evidence open |
+| G1-03 | Key lifetimes, overlap, expiry and historical verification | Annual-or-shorter subordinate rotation; explicit overlap; old supported artifacts governed by signed-time/non-revoked policy | Security, Release | Rotation direction approved under `CT-G1-2026-003`; exact lifetime/overlap table and tests open | Approved 2026-07-14; evidence open |
+| G1-04 | Revocation maximum age and emergency behavior | Signed monotonic offline lists; stale state blocks new activation; recovery/data access preserved unless signed emergency rule says otherwise | Security, Product, Support | Behavior approved under `CT-G1-2026-003`; maximum age, reason/action values and tabletop evidence open | Approved 2026-07-14; evidence open |
+| G1-05 | Compromised-root field recovery | Independently protected recovery authority/media; ordinary compromised-root signatures cannot restore trust | Security, Support | Separate recovery-authority/media direction approved under `CT-G1-2026-003`; custody and field runbook open | Approved 2026-07-14; evidence open |
+| G1-06 | Threat model and residual-risk ownership | Accept/amend all TM-01–TM-18 controls; assign every residual risk | Security, Platform, Release, Product, Support | TM-01–TM-18 controls approved under `CT-G1-2026-003`; residual-risk assignments and executed evidence open | Approved 2026-07-14; evidence open |
+| G1-07 | Firmware/Secure Boot/TPM, disk encryption and administrator boundary | Declare exact mandatory baseline and unsupported threat boundary for AMD64 Workstation | Security, Platform, Product | Requirement for an explicit baseline approved under `CT-G1-2026-003`; exact baseline and exception policy open | Approved 2026-07-14; evidence open |
+
+## B. Manifest, Compatibility and Artifact Identity
+
+| ID | Decision required | Recommended baseline / acceptable outcome | Accountable roles | Required evidence | Status |
+|---|---|---|---|---|---|
+| G1-08 | Manifest/signature schemas and canonical bytes | Approve current Draft 2020-12 schemas and canonical UTF-8 lexical-key serialization | Platform, Security | Approved under `CT-G1-2026-002`; existing validator evidence linked as E-G1-002 | Approved 2026-07-14 |
+| G1-09 | Compatibility order/reason codes and security floor | Default deny; approve deterministic evaluation and break-glass ownership | Platform, Security, Product | Approved under `CT-G1-2026-002`; compatibility vectors linked as E-G1-002 | Approved 2026-07-14 |
+| G1-10 | Artifact naming, SemVer, channels, SBOM/provenance formats | Approve canonical naming; SPDX 3.0.1 JSON; in-toto v1.2 Statement v1/SLSA Provenance v1 | Release, Security, Platform | Formats approved under `CT-G1-2026-002`; production toolchain/sample release evidence remains required | Approved 2026-07-14 |
+| G1-11 | Publication/archive locations, retention and withdrawal | Immutable stable bytes; signed channel/withdrawal history; named archive and privacy periods | Release, Security, Support | Immutable publication/withdrawal direction approved under `CT-G1-2026-002`; concrete archive locations, access and retention periods remain evidence-open | Approved 2026-07-14; evidence open |
+
+## C. Workstation Hardware, Runtime and Payload
+
+| ID | Decision required | Recommended baseline / acceptable outcome | Accountable roles | Required evidence | Status |
+|---|---|---|---|---|---|
+| G1-12 | First-release architecture and AMD GPU scope | AMD64 universal adaptive ISO; CPU-only fallback plus approved NVIDIA profiles; AMD GPU/ROCm/Strix Halo acceleration excluded | Product, Platform, Delivery | Product direction approved under `CT-G1-2026-001`; physical validation remains G1-13/Gates 4-5 | Approved 2026-07-14 |
+| G1-13 | Representative physical machines | Name exact CPU-only/sub-threshold, 8 GB, 24 GB and 48 GB-or-higher NVIDIA targets, firmware and peripherals | Product, Delivery, Security | CPU-only/sub-threshold, NVIDIA 8 GB, 24 GB and 48 GB-or-higher profile matrix approved under `CT-G1-2026-006`; exact CPU/GPU/RAM/storage, asset IDs, firmware and availability remain evidence-open | Approved 2026-07-14; evidence open |
+| G1-14 | Driver, CUDA, kernel and runtime pins | Resolve immutable mutually compatible versions and safe fallback behavior | Platform, AI | Ubuntu 22.04.5 AMD64, R570 open driver at least 570.124.06, CUDA 12.8.1, vLLM 0.10.2 by OCI digest and NVIDIA-independent CPU behavior approved under `CT-G1-2026-007`; exact locks and physical/rollback evidence open | Approved 2026-07-14; evidence open |
+| G1-15 | Starter models and redistribution | Approve exact revisions/layers/files/digests/licenses/notices; no mutable model names | AI, Platform, Legal/Product | Pinned Phi-3 Mini Ollama manifest/layer (MIT), Nomic Embed Text v1.5 manifest (Apache-2.0) and Microsoft Phi-3 Mini commit (MIT, validated 24 GB-or-higher profiles only) approved under `CT-G1-2026-008`; exact packaged files/digests, notices and redistribution evidence open | Approved 2026-07-14; evidence open |
+| G1-16 | Complete Offline Workstation payload | Resolve every package/image/wheel/runtime/source object by version, architecture, digest, bytes and license | Platform, Release, Legal/Product | Ubuntu 22.04.5 base, immutable platform/help, locked packages/environments, approved NVIDIA/container/Ollama/vLLM/starter-model payload, offline license/trust, manifests/SBOM/provenance/recovery/evidence tools and explicit exclusion boundary approved under `CT-G1-2026-009`; signed resolved inventory and measurements open | Approved 2026-07-14; evidence open |
+| G1-17 | ARM64/DGX Spark later scope | Explicitly defer to separate build identity, approve future workstream, or remove claim; no AMD64 support claim | Product, Platform | Deferred to a later separately evidenced ARM64 build identity under `CT-G1-2026-001`; AMD64 media makes no DGX Spark claim | Approved 2026-07-14 |
+
+## D. Online Acquisition, Update, Rollback and Licensing
+
+| ID | Decision required | Recommended baseline / acceptable outcome | Accountable roles | Required evidence | Status |
+|---|---|---|---|---|---|
+| G1-18 | Online production endpoint classes and owners | Dedicated HTTPS index/artifact/auth endpoints with signed payload index and immutable content | Platform, Security | Endpoint classes and signed immutable index approved under `CT-G1-2026-004`; production names/owners open | Approved 2026-07-14; evidence open |
+| G1-19 | Online credentials, mirrors, proxy/customer CA, retry/cache/SLA | Short-lived scoped credentials; explicit CA/proxy flow; bounded retry and content-addressed resume/cache | Platform, Security, Support | Security/resume direction approved under `CT-G1-2026-004`; issuer, mirrors, proxy/CA and numeric values/tests open | Approved 2026-07-14; evidence open |
+| G1-20 | Update activation/checkpoint implementation contract | Approve atomic switch/snapshot choices per surface and full affected-state inventory | Platform, Support | Side-by-side/atomic-where-supported and complete-checkpoint direction approved under `CT-G1-2026-004`; surface mechanisms/matrix open | Approved 2026-07-14; evidence open |
+| G1-21 | Backup/rollback SLA, retention, quota and health window | Retain current plus last-known-good; verified full backup; no automatic recovery deletion; approve health duration | Product, Platform, Support | Retention/no-auto-deletion direction approved under `CT-G1-2026-004`; quotas, SLA and health duration/tests open | Approved 2026-07-14; evidence open |
+| G1-22 | Driver/kernel/OS and rollback-failure recovery | Declare automatic, restore-based or recovery-required path before authorization | Platform, Support, Security | Preauthorization classification requirement approved under `CT-G1-2026-004`; per-surface runbook/tests open | Approved 2026-07-14; evidence open |
+| G1-23 | Offline license staging/expiry/time matrix | Explicit restricted staging allowlist; no default tier entitlement; approve continuity, tolerance and uncertain-time behavior | Product, Security, Support | Restricted staging/no-default-entitlement/fail-closed uncertain-time direction approved under `CT-G1-2026-004`; values/matrix open | Approved 2026-07-14; evidence open |
+| G1-24 | Device identity, binding, rehost and revocation ownership | Binding mandatory where policy requires; named rehost authority; signed monotonic trust/revocation flow | Security, Product, Support | Binding/rehost/monotonic-revocation direction approved under `CT-G1-2026-004`; identity mechanism, authority, procedure/tests open | Approved 2026-07-14; evidence open |
+
+## E. Model Lifecycle, Lab and Evidence
+
+| ID | Decision required | Recommended baseline / acceptable outcome | Accountable roles | Required evidence | Status |
+|---|---|---|---|---|---|
+| G1-25 | Model quarantine/store/reference mechanisms and quotas | Non-executable bounded quarantine; exact-digest store; transactional references; zero-reference GC only | Platform, AI, Security | Lifecycle architecture approved under `CT-G1-2026-005`; store mechanism, quotas and reconciliation evidence open | Approved 2026-07-14; evidence open |
+| G1-26 | Model-created customer data and license-change behavior | Uninstall/expiry never silently deletes customer data; approve retention/export/grace/rehost/withdrawal rules | Product, Legal, Support, Security | No-silent-deletion direction approved under `CT-G1-2026-005`; classification, retention/export/grace/rehost values open | Approved 2026-07-14; evidence open |
+| G1-27 | Offline lab people, hardware, topology, tools and schedule | Named executor/reviewer separation; two physical targets plus no-route capture and air-gap confirmation | Delivery, Support, Security | Lab method approved under `CT-G1-2026-005`; restricted person attribution, assets, tools, topology and dates open | Approved 2026-07-14; evidence open |
+| G1-28 | Evidence storage, signing/indexing, privacy and retention | Hash/signed index, failed-run retention, redaction, access control and immutable review record | Security, Release, Support | Tamper-evident/redacted/controlled evidence direction approved under `CT-G1-2026-005`; repository, signing method and periods open | Approved 2026-07-14; evidence open |
+| G1-29 | Zero-network and interruption acceptance inventory | Approve every required clean, malicious, incompatible, power-loss and recovery case; manual repair invalidates a run | Delivery, Platform, Security | Complete no-manual-repair acceptance inventory approved under `CT-G1-2026-005`; traceability and executed evidence open | Approved 2026-07-14; evidence open |
+| G1-30 | Server L/Max split disposition | For later planning only: prove support/runtime/validation distinction after large models are excluded, or reconsider duplicate ISO | Product, Platform, Support | Deferred under `CT-G1-2026-005` until Workstation evidence proves a support/runtime/validation distinction; tier naming alone cannot justify duplication | Approved 2026-07-14 |
+
+## Gate 1 Evidence Index
+
+Populate this index only with immutable or version-controlled evidence. “Discussed”, meeting notes
+without a decision, screenshots without artifact identity, and unreviewed test output do not pass.
+
+| Evidence ID | Covers decisions | Artifact/path/URI and digest | Executor | Independent reviewer | Date | Result |
+|---|---|---|---|---|---|---|
+| E-G1-001 | G1-01–G1-07 | `contracts/release-signing-trust.md`, `contracts/installer-threat-model.md`; approval `CT-G1-2026-003` | Cezen Technologies | Restricted attribution | 2026-07-14 | Architecture approved; operational values and executed evidence open |
+| E-G1-002 | G1-08–G1-11 | `contracts/test-vectors/verification-evidence.md`; approval `CT-G1-2026-002` | Cezen Technologies | Restricted attribution | 2026-07-14 | Decisions approved; G1-10 production tooling and G1-11 operational values/evidence open |
+| E-G1-003 | G1-12–G1-17 | `contracts/workstation-hardware-model-baseline.md`, `contracts/workstation-runtime-compatibility-baseline.md`, `contracts/payload-inventory-sizing.md`; approvals `CT-G1-2026-001`, `CT-G1-2026-006`, `CT-G1-2026-007`, `CT-G1-2026-008`, `CT-G1-2026-009` | Cezen Technologies | Restricted attribution | 2026-07-14 | All decisions approved; physical/runtime/model/payload inventory and measurement evidence open |
+| E-G1-004 | G1-18–G1-24 | `contracts/online-universal-acquisition.md`, `contracts/update-rollback-policy.md`, `contracts/offline-license-policy.md`; approval `CT-G1-2026-004` | Cezen Technologies | Restricted attribution | 2026-07-14 | Architecture approved; production values/mechanisms and executed evidence open |
+| E-G1-005 | G1-25–G1-30 | `contracts/model-pack-lifecycle.md`, `contracts/offline-validation-lab.md`; approval `CT-G1-2026-005` | Cezen Technologies | Restricted attribution | 2026-07-14 | Architecture approved; operational values, lab assignment and executed evidence open |
+
+## Decision Outcome
+
+Current result: **30 of 30 mandatory architecture decisions approved; Gate 1 PASS.** Downstream
+evidence is incomplete and remains gate-blocking where allocated. G1-12 and G1-17 are approved
+under Cezen Technologies record `CT-G1-2026-001`; G1-08 through G1-11 are approved under
+`CT-G1-2026-002`. G1-10 still requires production toolchain/sample-release evidence and G1-11 still
+requires concrete archive locations, access controls and retention periods. G1-13's matrix is approved
+but lacks exact physical evidence. G1-14 is approved under `CT-G1-2026-007` but lacks exact package/
+image locks and physical/rollback evidence. G1-15 is approved under `CT-G1-2026-008`; exact packaged
+model files/digests, notices and redistribution evidence remain open. G1-16's payload inclusion/
+exclusion boundary is approved under `CT-G1-2026-009`; the resolved signed object inventory, exact
+sizes/digests/licenses, extracted-media reconciliation and measured capacity evidence remain open.
+G1-01 through G1-07
+are approved under `CT-G1-2026-003`; signing hardware/custody details, exact lifetimes and revocation
+age, root-recovery procedure, residual-risk assignments, platform security baseline and executed
+control evidence remain open.
+G1-18 through G1-24 are approved under `CT-G1-2026-004`; production endpoint/credential/proxy values,
+surface activation and recovery mechanisms, quotas/SLA/health windows, license clock/state values,
+device identity/rehost procedure and executed failure evidence remain open.
+G1-25 through G1-30 are approved under `CT-G1-2026-005`; model store/quota/data-retention values,
+lab people/assets/tools/schedule, evidence repository/retention and executed traceability remain open.
+Server L/Max split work is explicitly deferred until Workstation evidence proves a real distinction.
+G1-13's representative profile matrix is approved under `CT-G1-2026-006`; exact physical machine
+specifications and availability remain evidence-open and MUST NOT be inferred from this approval.
+
+All decision rows are approved, but approval and evidence completion are separate. Follow
+`gate-evidence-allocation.md` for Gates 2-6. Gate 1 pass authorizes only detailed Offline Workstation
+implementation planning; it does not authorize implementation by itself.

specs/001-enterprise-experience/analysis/gate-evidence-allocation.md

@@ -0,0 +1,67 @@
+# Installer Evidence Gate Allocation
+
+**Audit date**: 2026-07-14  
+**Gate 1 result**: **PASS — architecture ready for detailed Offline Workstation implementation
+planning; implementation/build remains unauthorized in this docs-only task.**
+
+## Gate 1 Closure Test
+
+The normative gate definition in `contracts/installer-artifact-contract.md` requires the release
+matrix, payload boundaries, threat model, trust ownership, manifest schemas, compatibility rules,
+recovery matrix and test inventory to be approved. It does not require an ISO, measured payload,
+physical installation or executed update/model test; those are explicitly Gates 2-5.
+
+| Gate 1 requirement | Evidence | Result |
+|---|---|---|
+| Four-product matrix and Workstation-first boundary | `spec.md` FR-030/FR-031; artifact contract; G1-12/G1-16/G1-17 | Pass |
+| Exact offline and payload boundaries | FR-032/FR-033/FR-047-FR-049; payload contract; G1-16 | Pass |
+| Threat model | `installer-threat-model.md`; TM-01-TM-18; G1-06/G1-07 | Pass |
+| Trust ownership and signing architecture | `release-signing-trust.md`; G1-01-G1-05 | Pass |
+| Manifest/signature schemas | Draft 2020-12 schemas and fixture evidence; G1-08 | Pass |
+| Compatibility rules | `compatibility-evaluation.md`, reason codes/vectors; G1-09 | Pass |
+| Recovery/interruption matrix | Installer, update, license and model contracts; G1-20-G1-26 | Pass |
+| Test inventory and evidence method | `offline-validation-lab.md`, threat abuse set; G1-27-G1-29 | Pass |
+| Architecture approval record | G1-01-G1-30 have `CT-G1-2026-001` through `CT-G1-2026-009` | Pass |
+
+Gate 1 therefore passes. This design-gate result does not prove that current scripts, the zero-byte
+repository ISO, a future ISO, physical hardware or any production service conforms.
+
+## Downstream Evidence Allocation
+
+| Open item | Correct gate | Reason |
+|---|---|---|
+| Signing devices/custodians/operators, lifetimes, revocation age and recovery procedure | Gate 2 | Concrete operators and policy are implementation-readiness inputs |
+| Secure Boot/firmware/disk-encryption/admin baseline | Gate 2 | The threat control is approved; exact platform policy precedes implementation |
+| Kernel/driver/CUDA/toolkit/Ollama/Python/container locks | Gate 2 | Pinned payload inventory is the explicit Gate 2 requirement |
+| Starter-model files, notices and redistribution record | Gate 2 | License mapping and immutable inventory precede assembly |
+| Complete package/image/wheel/runtime/source inventory | Gate 2 | Explicit implementation-ready evidence |
+| Online endpoint/credential/proxy/CA/retry/cache values | Gate 2 for Online Universal | Independent of first Offline Workstation planning |
+| Update mechanisms, backup quota/SLA, health and recovery values | Gate 2 | Concrete mechanisms/operators must precede coding |
+| License timing/binding/rehost values and authority | Gate 2 | Concrete policy and operators must precede coding |
+| Model-store transaction/quota/data-retention values | Gate 2 | Concrete implementation and data policy |
+| Lab people/assets/tools/schedule and evidence repository | Gate 2 | Required before artifact/physical evidence execution |
+| Build, SBOM/provenance, signatures, digests and measured size | Gate 3 | Exists only for a built candidate artifact |
+| Physical, zero-network, interruption and reboot results | Gate 4 | Explicit Offline-install-ready evidence |
+| Update/model/tamper/rollback/revocation results | Gate 5 | Explicit Update/model-ready evidence |
+| Source-to-artifact review, support runbook and release approval | Gate 6 | Explicit release-ready evidence |
+| Server L/Max split justification | After Workstation Gates 1-5 | Server-offline planning is deferred |
+
+## Repository Contradiction Allocation
+
+| Contradiction | Blocking gate |
+|---|---|
+| C1 missing offline builder; C2 Workstation/Server ambiguity | Gate 2 implementation design |
+| C3 checksum-only foundation; C4 mutable inputs | Gate 2 implementation and Gate 3 artifact evidence |
+| C5 zero-byte checked-in ISO | Gate 3; it is not a release artifact |
+| C6 no distinct Server L/Max payload | Deferred Server decision after Workstation Gates 1-5 |
+| C7 driver 550/CUDA 12.4 vs approved R570/CUDA 12.8.1 | Gate 2 correction and Gate 4 validation |
+
+## Authorization Boundary and Next Gate
+
+The next formal target is **Gate 2: Implementation-ready** for Offline Workstation only. It requires
+the immutable payload/license inventory, concrete mechanisms/policy values, restricted operators,
+lab/evidence assignments and an implementation task plan that corrects C1-C4 and C7.
+
+This audit does not expand authority. No installer code, dependency download, payload assembly, ISO
+build, physical test, commit, push, deploy or runtime modification is authorized. Those actions
+require a separate explicit scope expansion.

specs/001-enterprise-experience/analysis/installer-release-consistency.md

@@ -0,0 +1,349 @@
+# Fresh Consistency Analysis: Installer Release Architecture
+
+**Run date**: 2026-07-14  
+**Scope**: `spec.md`, `plan.md`, `research.md`, `data-model.md`, `quickstart.md`, `tasks.md`, constitution,
+installer artifact contract, and observed repository installer/offline documentation.  
+**Result**: **CONSISTENT; GATE 1 PASS; GATE 2 IMPLEMENTATION/EVIDENCE IN PROGRESS; NO RELEASE ARTIFACT**
+
+## Consistent Decisions
+
+- The product taxonomy consistently keeps Workstation separate from Server S/M/L/Max and preserves
+  compatibility slugs `starter/basic/pro/max`.
+- The agreed four bootable products, Workstation-first order, separate large-model packs, and shared
+  offline update format are now normative and do not require a separate feature spec.
+- Zero-network acceptance, fail-closed integrity, durable operations, recovery evidence, and artifact
+  provenance align with the constitution's lifecycle, entitlement, and evidence principles.
+- The existing broad three-phase customer-experience rollout and the packaging workstream can coexist:
+  packaging is cross-cutting and has independent artifact gates.
+
+## Contradictions Requiring Correction During Implementation
+
+| ID | Evidence | Contradiction | Required resolution |
+|---|---|---|---|
+| C1 | `autoinstall/offline/README.md` names `build-iso-offline.sh`; repository inventory lacks it | Documented build stage has no current build path | Implement only after approval, or change the referenced path when the design is selected |
+| C2 | Offline directory describes “Server Payload” and script comments say “Server Starter”; README and variables describe Workstation | First implementation category is ambiguous in current runtime material | Rename/split runtime material during implementation and bind manifest category to `workstation` |
+| C3 | README says ISO signature/integrity; current bundle builder writes SHA-256 only and asks for later signing | Current foundation does not enforce signature verification before mutation | Define manifest/signature tooling and trust policy before calling any artifact offline |
+| C4 | Current builder fetches mutable install scripts/tags and records some digests after pull | Reproducibility and immutable input requirements are not yet met | Pin URLs by digest/version, images by digest, models by immutable revision, and record verified sources |
+| C5 | `autoinstall/cezen-ai-ubuntu2204.iso` is 0 bytes | Repository artifact cannot be booted, verified, sized or called current | Replace only through an authorized reproducible build and record real artifact evidence |
+| C6 | Server M/L/Max playbooks currently use the same role set; large models are now separate packs | Current source does not prove a materially distinct L/Max boot payload | Approve a support/validation/runtime distinction or reconsider duplication during implementation planning |
+| C7 | NVIDIA role installs driver 550/CUDA 12.4; Starter declares CUDA 12.6; vLLM 0.10.2 uses CUDA 12.8.1; approved profiles include Blackwell | Current runtime declarations are mutually inconsistent and driver 550/CUDA 12.4 cannot cover the approved Blackwell-capable matrix | Approve `workstation-runtime-compatibility-baseline.md`, resolve exact R570/CUDA 12.8.1-compatible locks, then validate every physical profile and rollback path |
+
+## Downstream Gaps and Readiness Blockers
+
+The governing architecture choices are approved. These gaps are allocated to Gates 2-6 in
+`gate-evidence-allocation.md` and remain real blockers at those downstream gates.
+
+| ID | Severity | Blocker |
+|---|---|---|
+| B1 | Critical | `contracts/release-signing-trust.md` now defines separate release/license/test trust domains, purpose-constrained root/subordinate roles, separation of duties, dual-controlled offline custody, digest-bound signing receipts, rotation/expiry, monotonic offline trust distribution, revocation behavior, compromised-root recovery and acceptance vectors. Named owners, approved hardware/custody/backup, lifetimes/overlap, maximum revocation age, disconnected time policy, field root-recovery design, emergency authority and executed ceremony evidence remain outstanding. |
+| B2 | Critical | Draft schemas, canonicalization, deterministic compatibility evaluation, all artifact-type examples and Ed25519 signatures, negative vectors, and passing automated Draft 2020-12/signature/compatibility evidence now exist. Technical fixture work is complete; security/platform approval remains outstanding. |
+| B3 | Critical | Workstation is universal and hardware-adaptive within each CPU architecture; AMD64 scope/profile classes and later separate ARM64 identity are approved. `contracts/workstation-runtime-compatibility-baseline.md` now proposes an R570 (at least 570.124.06)/CUDA 12.8.1-compatible baseline because current driver 550/CUDA 12.4/CUDA 12.6/vLLM 12.8.1 declarations conflict. Exact physical machines, kernel/package/image/environment locks, model file inventory, redistribution approval and executed compatibility/rollback evidence remain outstanding. |
+| B4 | Critical | `contracts/online-universal-acquisition.md` now defines endpoint classes, TLS/auth, signed index/manifest acquisition, cache/resume, failure recovery, and evidence gates. Production hostnames/owners, credentials, mirrors, proxy/customer-CA, retry/cache values, and approval remain outstanding. Current mutable default-branch clone remains contradictory legacy behavior. |
+| B5 | High | `contracts/update-rollback-policy.md` now defines update classes, ownership, ordering, current/last-known-good retention, checkpoint scope, atomic activation target, ten-minute validation proposal, interruption and rollback outcomes. Actual switch/snapshot mechanisms, full backup inventory/SLA, supported prior versions, disk quota, driver/kernel recovery, and owner approval remain outstanding. Current data-only ZIP is explicitly insufficient as complete platform rollback. |
+| B6 | High | `contracts/offline-license-policy.md` now defines offline import/activation, explicit staging, clock confidence/rollback, expiry continuity, binding/rehost, revocation/trust updates, interruption and evidence. Staging/expiry matrices, clock tolerance, device identity, rehost authority, revocation ages and owner approval remain. Current optional machine-ID enforcement and `basic` staging compatibility default are explicit implementation blockers. |
+| B7 | High | `contracts/payload-inventory-sizing.md` now defines four-artifact boundaries, candidate inputs, role matrix, exact-digest deduplication, sizing worksheet, capacity arithmetic and evidence gates. Immutable resolved object inventories/build measurements are still absent; Server offline sizes remain unpublished and L/Max split justification remains open. |
+| B8 | High | `contracts/offline-validation-lab.md` now defines isolation topology, packet-attempt detection, physical hardware matrix, clean/interruption/negative runs, evidence package, separation of duties and stop/retry rules. Named staff, exact machines/lab topology, approved tools, schedule, evidence storage and owner assignment remain outstanding. |
+| B9 | Medium | `contracts/release-lifecycle-provenance.md` now proposes semantic versions, canonical filenames/identity, channels, SPDX 3.0.1 SBOM, in-toto Attestation Framework v1.2 Statement v1 with SLSA Provenance v1 (SLSA spec v1.2), reproducibility classes, retention, support/cadence and withdrawal. Toolchain, publication/archive locations, final periods/windows/cadence and named owner approval remain outstanding. |
+| B10 | Medium | `contracts/model-pack-lifecycle.md` now defines bounded non-executable quarantine, malicious/partial import rejection, exact-digest object sharing, signed dependencies, atomic activation, uninstall/data preservation, reference-safe garbage collection, entitlement and redistribution-license changes, interruption tests and Gate 5 reconciliation. Store/transaction mechanisms, quotas/retention, customer-data rules, continuity/rehost policy, withdrawal/GC authority, named owners and executed evidence remain outstanding. |
+| B11 | Critical | `contracts/installer-threat-model.md` now defines protected assets, adversaries, trust boundaries, eighteen threat/control cases, state invariants, abuse/interruption evidence and residual risks across source, build, signing, distribution, install, activation, recovery and evidence export. Owner acceptance, residual-risk assignment and linked executed control evidence remain outstanding; Secure Boot/firmware/TPM, build isolation, root/admin, disk encryption, evidence-signing and physical custody choices remain open. |
+
+## Next-Step Remediation Completed
+
+`contracts/architecture-decisions.md` records repository-derived defaults and separates them from
+decisions requiring named Cezen approval. Draft JSON Schemas now cover the shared artifact manifest
+and detached signature envelope. These drafts reduce B2/B3 ambiguity but do not close the gates until
+owners approve them and immutable test vectors/payload revisions exist.
+
+The next technical pass removed a circular self-digest from the manifest schema: the canonical
+manifest digest belongs only in its detached signature envelope. `compatibility-evaluation.md` now
+defines fail-closed evaluation order and stable reason codes, with non-production structural and
+compatibility fixtures under `contracts/test-vectors/`. Cryptographic approval remains blocked until
+a dedicated test key and real signatures are created under approved key-handling policy.
+
+The B3 evidence pass verified immutable candidate pins for both Ollama starter models and the Hugging
+Face Phi-3 snapshot, plus vendor hardware facts. It also surfaced a release-architecture contradiction:
+the singular AMD64 Workstation ISO cannot also boot ARM64 DGX Spark. Following product clarification,
+`contracts/workstation-hardware-model-baseline.md` now requires one universal hardware-adaptive ISO
+per CPU architecture: the AMD64 artifact spans CPU-only and low/mid/high GPU classes, while a later
+ARM64 artifact may cover DGX Spark under the same customer-facing Workstation category.
+
+## Readiness Decision
+
+The architecture is coherent and every Gate 1 requirement is approved. The closure audit in
+`analysis/gate-evidence-allocation.md` records **Gate 1 PASS**. Subsequent explicit user authorization
+permitted isolated Gate 2 resolver, verification, checkpoint and disposable-install evidence, but did
+not authorize a release artifact, commit, push or deployment. Gate 2 remains blocked by operational,
+immutable-inventory, mechanism, operator,
+lab and evidence-storage items. Offline Workstation MUST remain the only first implementation candidate.
+Offline Server S/M and L/Max remain planning-only until a real Workstation artifact passes the shared
+zero-network, signature, update/model, interruption, rollback, and evidence gates. No ISO can be
+called offline from the current repository material alone.
+
+Gate 2 resolver evidence initially appeared to expose a bcrypt/Chroma contradiction, but fresh repo
+inspection proved that the backend, Chroma and platform dependencies are installed into separate
+virtual environments and wheelhouses. The corrected resolver preserved those boundaries and produced
+363 measured wheel objects without changing either constraint. It also exposed the actual readiness
+blocker: unpinned platform requirements currently select CUDA 13 Python components, conflicting with
+the approved CUDA 12.8.1 runtime baseline. The candidate cannot be reviewed until that ML stack is
+explicitly pinned and its three environments pass offline installation/import and license evidence.
+
+Resolver increment 002 removes that version-selection contradiction using the exact dependency pins
+embedded in vLLM 0.10.2: Torch 2.8.0, Torchaudio 2.8.0 and Torchvision 0.23.0. The fresh candidate has
+no explicitly CUDA-13-named objects and 14 explicitly CUDA-12-named objects. This is not yet runtime
+acceptance: physical R570/CUDA 12.8.1 testing, disconnected Python 3.11 install/import, license review,
+and proof that the CPU-only profile does not require NVIDIA packages remain Gate 2 blockers.
+
+Disconnected Python 3.11 validation subsequently passed for all three wheelhouses using a
+digest-pinned validator container, `--network none` and `pip --no-index`. CPU execution passed with
+CUDA hidden; a supplemental RTX 3050/Open Driver 595.58.03 test also executed CUDA 12.8 tensor work.
+This narrows but does not close Gate 2: the 8 GB test is not the exact R570 reference or the 24/48 GB
+matrix, and carrying CUDA wheels is not proof that CPU-profile installation excludes NVIDIA runtime
+dependencies. License/provenance review and bare-metal/interruption/model-serving evidence remain open.
+
+Profile-selection increment 001 closes the Python CPU payload-boundary ambiguity: the universal AMD64
+medium carries profile alternatives, while installation selects exactly one. A strict 196-wheel CPU
+selection contains no NVIDIA/CUDA/Triton/bitsandbytes objects and passed disconnected installation as
+Torch `2.8.0+cpu` with no compiled CUDA runtime. The machine-readable selector and validator fail
+closed on missing, altered or forbidden wheels. Installer integration, signed membership, detection,
+journal/resume/rollback and tamper/interruption tests remain open and are allocated to T143.
+
+Planner increment 001 now makes those state transitions deterministic without wiring them into the
+installer. Six planner tests and build-host vectors prove safe CPU fallback, fully-ready NVIDIA
+selection, same-profile resume and rollback-required profile changes. This is structural evidence only:
+the test receipt is not cryptographically verified, and no atomic journal, checkpoint, installer
+mutation, power-loss recovery or production signature-verifier integration exists yet. T143 remains
+open; the planner prevents later wiring from inventing different state semantics.
+
+Receipt increment 001 closes the unsafe bare-boolean handoff in the structural planner. A closed schema
+now binds the manifest/envelope, key, trust snapshot, policy, namespace, profiles, time and verifier
+build, and test receipts are forbidden by default. This is still not production signature evidence:
+no production verifier, trust-policy evaluation, key ceremony or durable atomic journal/checkpoint
+writer exists. Those blockers are explicitly allocated to T146 before T143 installer integration.
+
+Atomic-journal increment 001 now implements the persistence mechanism and rejects stale writers,
+altered records, identity changes, missing checkpoints and invalid transitions. Build-host vectors
+reached `installing` only after a recorded checkpoint and retained mode `0600` plus digest linkage.
+T146 is still open because a recorded checkpoint ID is not checkpoint creation/verification,
+filesystem power loss has not been injected, and production Ed25519/trust-policy verification is not
+implemented.
+
+Ed25519 verifier increment 001 implements the cryptographic and structural handoff using OpenSSL and
+passes positive/tamper/environment tests on Ubuntu with ephemeral test keys. It does not close T146:
+there is no production key ceremony, approved trust snapshot, revocation/time-policy evaluation,
+locked verifier/OpenSSL build, or independently approved production signature. The implementation is
+ready for those inputs without treating test-key success as release evidence.
+
+Checkpoint increment 001 now creates, verifies and restores hashed Python-environment snapshots and
+handles originally absent targets without silent deletion. The build-host disposable vector restored
+the original bytes exactly. Forced-process crash vectors now also prove that no partial checkpoint is
+accepted, a published checkpoint verifies, interrupted restore completes from preserved quarantine,
+and post-activation retry is idempotent. T146/T143 remain open because physical power loss,
+disk-full tests, real target metadata coverage, orchestration and production trust inputs are absent.
+
+Pre-mutation orchestration increment 001 connects the previously isolated components through durable
+`checkpoint_ready` and proves idempotent re-entry with no package mutation. Remaining orchestration
+starts at the mutation boundary: offline install, health validation, installed/rollback transitions,
+service integration, real paths and production verification receipts remain unproved.
+
+Disposable installation increment 001 crosses the Python mutation boundary for the strict CPU profile:
+network-disabled install, pre/post activation health, fsynced atomic activation and final `installed`
+state pass; offline dependency failure records rollback without changing the original target. This does
+not close Gate 2 because NVIDIA execution, service integration, real paths/metadata, forced failure
+after activation, reboot resume and bare-metal zero-network acceptance remain open.
+
+Post-activation rollback increment 001 now proves the disposable CPU executor can recover from process
+death after activation but before post-health/final journal commit. Exact checkpoint restoration,
+failed-environment quarantine and terminal rollback all pass. Reboot/power-loss recovery, service-level
+health, disk exhaustion, NVIDIA rollback and live installer integration remain blockers.
+
+Disposable NVIDIA installation increment 001 proves the complete cu128 Python environment can install
+and execute CUDA 12.8 tensors on the 8 GB RTX 3050 under Open Driver 595.58.03. It narrows the GPU gap
+but does not satisfy the exact R570 reference, 24/48 GB matrix, vLLM/model-serving, NVIDIA rollback,
+reboot recovery or bare-metal acceptance requirements.
+
+`analysis/gate-1-decision-dossier.md` is now the consolidated approval surface. Its fresh count is
+**30/30 mandatory architecture decisions approved; Gate 1 PASS; downstream evidence incomplete**. Cezen Technologies record `CT-G1-2026-001` approves G1-12
+(AMD64 universal adaptive first-release direction with NVIDIA acceleration, CPU fallback and AMD GPU/
+ROCm/Strix Halo acceleration excluded) and G1-17 (DGX Spark/ARM64 deferred to a separately evidenced
+later build identity). G1-13's profile matrix is separately approved but lacks physical evidence.
+G1-14 is approved under `CT-G1-2026-007` for Ubuntu 22.04.5 AMD64, R570 open driver at least
+570.124.06, CUDA 12.8.1, vLLM 0.10.2 by immutable OCI digest and NVIDIA-independent CPU behavior;
+exact locks and physical/rollback evidence remain open. G1-15 is approved under `CT-G1-2026-008` for
+the pinned Phi-3 Mini Ollama manifest/layer, Nomic Embed Text v1.5 manifest and Microsoft Phi-3 Mini
+commit with their recorded licenses and hardware boundary; packaged file/digest/notice and
+redistribution evidence remain open. G1-16's Offline Workstation inclusion/exclusion boundary is
+approved under `CT-G1-2026-009`; resolved signed object inventory, exact sizes/digests/licenses,
+extracted-media reconciliation and measured capacity evidence remain open.
+Existing schema/vector evidence and hardware/model
+research are partial technical inputs, not approvals.
+Cezen Technologies record `CT-G1-2026-002` additionally approves G1-08 through G1-11: the manifest/
+signature schemas, deterministic default-deny compatibility, canonical naming/SBOM/provenance formats,
+and immutable publication/withdrawal direction. Production tooling/sample-release evidence and exact
+archive/access/retention values remain open.
+Cezen Technologies record `CT-G1-2026-003` approves G1-01 through G1-07: separate trust domains,
+offline-root/isolated-signer custody direction, rotation, monotonic revocation, compromised-root
+recovery direction, TM-01–TM-18 controls and the requirement for a platform security baseline.
+Concrete hardware/custody, timing values, recovery procedures, residual-risk assignments, exact
+platform baseline and executed evidence remain open. Cezen Technologies record `CT-G1-2026-004`
+approves G1-18 through G1-24: secure online endpoint/acquisition direction, scoped credentials and
+resumable cache, staged/atomic update direction, last-known-good retention, explicit rollback classes,
+restricted offline staging and binding/rehost/monotonic revocation. Production endpoints and numeric
+operational values, exact mechanisms/runbooks and executed evidence remain open.
+Cezen Technologies record `CT-G1-2026-005` approves G1-25 through G1-30: model quarantine/reference/
+GC and customer-data preservation, the isolated lab and tamper-evident evidence methods, the complete
+no-manual-repair acceptance inventory, and deferral of the Server L/Max split until Workstation evidence
+proves a real distinction. Operational values, lab assignments and executed evidence remain open.
+Cezen Technologies record `CT-G1-2026-006` approves the G1-13 representative profile matrix, but not
+the existence or results of physical machines; exact CPU/GPU/RAM/storage, asset IDs, firmware and
+availability remain evidence-open.
+`gate-evidence-allocation.md` now separates Gate 1 approval evidence from Gates 2-6 execution evidence.
+
+## Fresh Audit Pass 2
+
+**Audit date**: 2026-07-14  
+**Result**: **DOCUMENT SET INTERNALLY CONSISTENT; SUPERSEDED BY PASS 3 GATE ALLOCATION**
+
+- All 12 checked-in JSON schemas/fixtures parse as JSON; the recorded full vector-suite evidence
+  remains the technical result of record pending independent approval.
+- Functional- and success-criterion identifiers have no duplicates; contract and analysis paths in
+  the plan exist; Markdown whitespace validation passes.
+- At Pass 2, C1-C6 remained repository/runtime contradictions; later explicitly authorized Gate 2
+  increments changed the status of C2 and partially remediated C3/C4/C7 as recorded in Pass 4 below.
+- Eight sizing rows contain 40 `TBD` markers in the measured payload worksheet. They are evidence
+  holes, not unspecified behavior: T106 cannot resolve them without authorized immutable dependency
+  resolution, artifact assembly and measurement.
+- The signing decision package was aligned with the signing trust contract: the artifact signer is
+  isolated from builders and is not described as an online build signer.
+- There are 18 unchecked installer task lines. They are not 18 sequential documentation passes:
+  most consolidate into the 30 decisions in the Gate 1 dossier, followed by evidence execution and
+  a Gate 1 rerun. T083 is intentionally later, after Workstation passes Gates 1-5.
+
+Pass 2 correctly blocked while decisions were open. All decisions are now approved; Pass 3 in
+`gate-evidence-allocation.md` supersedes that result and allocates remaining evidence to Gates 2-6.
+
+## Fresh Audit Pass 4 — Gate 2 Implementation Evidence
+
+**Audit date**: 2026-07-14  
+**Result**: **INTERNALLY CONSISTENT; GATE 2 NOT READY; OFFLINE WORKSTATION REMAINS THE ONLY BUILD CANDIDATE**
+
+All specification JSON files parse, the current local deployment suite passes 36 tests with one
+expected Mac OpenSSL/Ed25519 capability skip, shell/Python syntax and whitespace checks pass, and the
+artifact directory remained empty in every recorded build-host increment.
+
+### Contradiction Reconciliation
+
+| ID | Pass 4 status | Evidence and remaining work |
+|---|---|---|
+| C1 | Open | `build-iso-offline.sh` is still referenced but absent. No lock-consuming media builder exists. |
+| C2 | Resolved for the new path | New resolver, profile and evidence surfaces consistently identify Offline Workstation. Legacy Server material has not been promoted. |
+| C3 | Partially remediated | Ed25519/profile receipt, fail-closed planner, journal/checkpoint and disposable mutation exist; production keys/trust policy and release-artifact signature enforcement do not. |
+| C4 | Partially remediated | Source, OCI manifests, APT closure and Python wheels have candidate locks. Ubuntu media, runtime archives, OCI exported bytes, models, repository/index provenance and licenses remain unresolved. |
+| C5 | Open | The checked-in ISO remains zero bytes; no bootable artifact exists or is claimed. |
+| C6 | Deferred | Server L/Max material distinction remains intentionally deferred until Workstation passes its gates. |
+| C7 | Partially remediated | Python uses the vLLM-aligned Torch 2.8.0/CUDA 12.8 split and CPU-only alternative. The production NVIDIA Ansible/package path still declares legacy driver/CUDA behavior and the exact R570 matrix is unproved. |
+
+### Gate 2 Readiness Blockers
+
+1. Candidate payload lock resolution 004 is not reviewed/signed and still lacks complete Ubuntu,
+   runtime, model and measured container objects.
+2. APT/Python/OCI index provenance, licenses/notices and redistribution approval remain incomplete;
+   49 Python license fields require review.
+3. Production release keys, trust snapshot, revocation/time rules, verifier/OpenSSL build locks and
+   independent signing evidence do not exist.
+4. Exact R570 validation plus 24 GB and 48 GB-or-higher physical profiles remain absent; RTX 3050/
+   driver 595 evidence is supplemental `gpu-lite` coverage only.
+5. No lock-driven acquisition/assembly path or bootable Offline Workstation ISO exists; the legacy
+   mutable builder remains intentionally unreachable.
+6. Sudden-power-loss recovery, post-activation or recovery-reserve exhaustion, production service-stack
+   health, real ownership/ACL/xattr behavior and bare-metal zero-network acceptance remain unproved.
+   Controlled OS-reboot and pre-activation target byte/inode exhaustion are proven only for disposable
+   strict-CPU vectors; an external post-activation service-probe rollback is also proven only in
+   disposable staging.
+7. Named lab/operators, restricted evidence store, retention and independent approval remain open.
+8. The payload-sizing worksheet still has eight unmeasured rows (40 `TBD` markers); media capacity and
+   extracted peak/rollback space cannot be approved before real assembly evidence.
+9. The checked-in real service graph is incomplete: `cezen-api.service` orders after Ollama without
+   requiring it, omits ChromaDB dependency/ordering, and no production proxy dependency or consecutive
+   semantic-health window is wired to rollback. T163 proves only an isolated mock graph; T164 provides
+   structurally validated candidate definitions but does not replace or validate the real units.
+10. T165 supplies deterministic health-window implementation and disconnected loopback evidence, but
+    no signed production health profile, approved timing, real Nexus semantic endpoint matrix or
+    production unit installation/security evidence exists.
+
+Gate 2 therefore remains **NOT READY**. The next implementation evidence may continue on Offline
+Workstation, but Offline Server S/M and L/Max and all release/build claims remain blocked.
+
+Operator-flow remediation T156 removes the misleading executable build sequence from the offline
+README. It now identifies every current tool as candidate-resolution, structural/disposable evidence,
+available fail-closed validation, or blocked/absent assembly. C1 remains openly documented rather than
+being implied complete by instructions that referenced a nonexistent script.
+
+NVIDIA rollback increment T158 closes the disposable 8 GB Python post-activation process-crash case:
+checkpoint restoration, executable failed-environment quarantine and terminal rollback pass. The
+remaining NVIDIA blockers are reboot/physical-power recovery, exact R570 and 24/48 GB hardware,
+vLLM/service/model health, real paths/metadata and bare-metal zero-network installation.
+
+Boot-dispatcher increment T159 closes the narrower fresh-process recovery wiring gap for the strict
+CPU profile: a distinct offline container recovered a generation-3 `installing` journal to generation
+5 `rolled_back`, restored the checkpoint, retained the activated environment and no-op'd on a second
+terminal invocation. This is consistent with the interruption contract but does not change the Gate 2
+decision: actual OS reboot and sudden-power-loss durability, production boot ordering, real filesystem
+metadata, capacity exhaustion and service health remained unproved at T159; T160/T161 narrow those
+gaps below.
+
+The post-T159 synchronized build-host suite passes 29 tests with no skips and zero artifact entries.
+This refresh does not alter any open contradiction or readiness blocker.
+
+Controlled-reboot increment T160 closes the disposable strict-CPU OS-reboot recovery gap. It also
+proved persistent static networking at `172.16.10.144/24`. An initial exact-path mismatch failed
+closed before restore; a fresh mount-consistent vector then recovered during boot to generation 5
+`rolled_back`. The temporary boot unit was removed. Gate 2 remains not ready because physical power
+loss, production unit packaging/order, live paths and metadata, capacity exhaustion, service/model
+health and bare-metal zero-network installation remained unproved at T160; T161 narrows target
+pre-activation exhaustion below.
+
+Capacity increment T161 closes pre-activation target byte and inode exhaustion for disposable
+strict-CPU installs. The vectors independently constrained the executable target to 128 MiB and 2,000
+inodes, produced real `ENOSPC`, preserved the original target and reached generation 5 `rolled_back`
+using separately reserved journal/checkpoint capacity. Gate 2 remains not ready: production capacity
+reservation/preflight, reserved-state exhaustion, post-activation exhaustion, live metadata and
+service-level rollback are still open.
+
+Service-health increment T162 closes the generic external-probe failure path after strict-CPU atomic
+activation: the probe observed the new environment, exited `23`, and exact checkpoint rollback plus
+quarantine and generation-5 terminal state passed. Gate 2 remains not ready because the probe is not
+yet a locked production component and no real Nexus systemd/API/portal/model service dependency graph,
+health window, live path metadata or traffic behavior has been validated.
+
+The post-T162 synchronized build-host suite passes 31 tests with no skips and zero artifact entries.
+
+Systemd increment T163 proves explicit dependency ordering, three consecutive semantic-health samples
+and `OnFailure` rollback in a fully isolated four-service graph. A forced vector 503 restored the
+checkpoint and quarantined the candidate at generation 5. All temporary units were removed. This does
+not close production service readiness: the real unit graph and actual Nexus model/vector/API/proxy
+health semantics remain unimplemented/unvalidated and are now an explicit Gate 2 blocker.
+
+Candidate-unit increment T164 defines the corrected production dependency and rollback direction while
+preserving nginx recovery/help access during API failure. `/tmp`-only systemd 249 structural validation
+passes without candidate errors or cycles. Gate 2 remains not ready: the health-window executable,
+signing/locking, category-specific graph generation, real executables/nginx, approved timing, actual
+restart/timeout behavior and production security analysis are absent, and current Ansible units remain
+unchanged.
+
+Health-window increment T165 closes the isolated validator behavior for ready, explicitly allowed
+optional degradation, timeout, malformed JSON and HTTP-503 rejection. Rejection exit 23 now matches the
+candidate systemd `OnFailure` contract. Gate 2 remains not ready because profiles/tool/unit bytes are
+unsigned candidates, the real service graph/endpoints and total health deadline are unproved, and no
+production units have been installed or security-scored.
+
+The post-T165 synchronized build-host suite passes 36 tests with no skips and zero artifact entries;
+the updated candidate health unit also passes `/tmp`-only systemd 249 structural/cycle validation.
+
+Deadline/storm increment T166 closes isolated monotonic total-window enforcement and pre-HTTP systemd
+restart-ceiling behavior. Real temporary units produced exit-23 `WINDOW_TIMEOUT` and `RESTART_STORM`
+evidence, and were removed afterward. Gate 2 remains not ready: production timing/restart limits are
+unsigned/unapproved, restart baseline/reset semantics and real-unit storms are unproved, and these
+failure codes have not yet been chained through the candidate rollback unit in one transaction.
+
+The post-T166 synchronized build-host suite passes 38 tests with no skips and zero artifact entries;
+the deadline-aware candidate unit also passes `/tmp`-only systemd 249 structural/cycle validation.