release: freeze Nexus One AI 1.0.0-rc1

specs/001-enterprise-experience/spec.md

@@ -244,6 +244,97 @@ licensed capabilities, key first tasks, help resources, and support evidence wit
   and provides truthful completion, rollback-limit, recovery, and escalation outcomes.
 - **FR-029**: Every new operation, recovery, removal, diagnostic, and support-evidence interface MUST
   enforce server-side authorization and MUST be covered by allowed-role and denied-role tests.
+- **FR-030**: Release packaging MUST use exactly four bootable products: Online Universal Server,
+  Offline Workstation, Offline Server S/M, and Offline Server L/Max. Workstation MUST NOT appear in
+  the Server tier selector, and no offline Server image may select a tier outside its named pair.
+- **FR-031**: Offline Workstation is the first offline implementation target. Offline Server S/M and
+  Offline Server L/Max remain blocked until the shared offline contract passes on Workstation.
+- **FR-032**: An artifact MUST NOT be described as offline unless a clean target, with every network
+  interface disabled or physically disconnected from boot until acceptance completes, installs and
+  reaches its declared ready or explicitly degraded state without DNS, routing, mirrors, registries,
+  repositories, license servers, time services, telemetry, or other network responses.
+- **FR-033**: Each offline ISO MUST contain the Ubuntu boot/install base, installer logic, the exact
+  platform revision, all packages/runtimes/images required by its category and selectable tiers,
+  local help, trust roots, manifests, and only the approved starter-model set. Optional connectors
+  MAY be installed but MUST be reported unavailable, not failed or ready, when their remote targets
+  are unreachable.
+- **FR-034**: Large models MUST be distributed as separately signed model packs and MUST NOT be
+  duplicated in bootable media. A model pack MUST declare compatible product categories, tiers,
+  platform versions, hardware/storage prerequisites, content identity, and installed-state effect.
+- **FR-035**: All installed products MUST accept one shared signed offline-update bundle format.
+  Bundles MUST declare source and target platform versions, compatible categories/tiers, ordered
+  actions, space and service-impact prerequisites, payload digests, and rollback classification.
+- **FR-036**: ISO payloads, model packs, and update bundles MUST use a versioned manifest, a digest for
+  every payload object, a detached release signature, an identified signing key, and an offline
+  trust/revocation policy. Verification MUST fail closed before any target mutation.
+- **FR-037**: Update and import operations MUST stage and verify before activation, preserve the last
+  known-good state or a documented pre-change backup, commit atomically where supported, and report
+  whether rollback is automatic, operator-invoked, restore-based, or impossible before confirmation.
+- **FR-038**: Interrupted boot, install, first boot, payload verification, model import, update staging,
+  activation, reboot, and rollback MUST each have a deterministic outcome: safe resume, safe restart,
+  automatic rollback, operator recovery, or a non-destructive blocked state with evidence.
+- **FR-039**: Published media guidance MUST be derived from measured release artifacts. Required media
+  capacity is the smallest common capacity with at least 20% headroom above the finalized artifact
+  and any flashing overhead; estimates MUST be labelled estimates and Server offline sizes MUST not
+  be published before payload build and deduplication evidence exists.
+- **FR-040**: No installer product may advance from planned to implementation-ready, release candidate,
+  or generally releasable without the evidence gates defined in the installer artifact contract.
+- **FR-041**: Offline Workstation media MUST be universal and hardware-adaptive within its CPU
+  architecture. GPU vendor model or VRAM class MUST NOT create separate Workstation products, media,
+  or commercial tiers. Hardware detection MUST select safe local capability profiles and truthfully
+  disable unsupported model/runtime functions while preserving the supported core platform.
+- **FR-042**: CPU architecture is an artifact compatibility boundary. An AMD64 Workstation ISO MUST
+  NOT claim ARM64 DGX Spark support; any ARM64 or proven multi-architecture media requires its own
+  build identity and complete artifact evidence while remaining the same Workstation product category.
+- **FR-043**: The first Offline Workstation release MUST support NVIDIA acceleration and truthful
+  CPU-only fallback on approved AMD64 hosts. AMD GPU acceleration, ROCm, and Strix Halo acceleration
+  are outside the first release and MUST NOT be advertised as supported merely because the ISO boots
+  on an AMD64 CPU.
+- **FR-044**: An update MUST NOT claim complete rollback based only on a customer-data backup. The
+  rollback checkpoint MUST cover every affected application, configuration, service, runtime,
+  container, schema, model, trust, driver, kernel, and OS surface or explicitly classify the update
+  as restore-based/recovery-required before authorization.
+- **FR-045**: Offline license activation MUST fail closed for invalid signature, unsupported policy,
+  untrusted time, expiry, revocation, category/tier mismatch, unavailable or mismatched required
+  machine binding, and MUST NOT treat a compatibility default as purchased entitlement.
+- **FR-046**: Field staging MUST be an explicit restricted capability allowlist, not a free Server
+  tier or fallback for invalid license material. License expiry/revocation/replacement MUST preserve
+  customer data, backup/export, diagnostics and safe recovery according to approved policy.
+- **FR-047**: Every release artifact MUST have a complete immutable object inventory with architecture,
+  license, exact byte sizes and digests before assembly. Media and target-storage guidance MUST be
+  calculated from built evidence; a placeholder, sparse or zero-byte ISO is not a release artifact.
+- **FR-048**: Shared payload objects MUST be deduplicated by exact digest within an artifact. Separate
+  Server L/Max media MUST have an approved support, validation or payload distinction after large
+  models are excluded; tier naming alone is insufficient justification for duplicated boot media.
+- **FR-049**: Offline acceptance MUST use an instrumented no-route capture segment plus physical-air-gap
+  confirmation, classify every non-loopback attempt, and fail for any attempted external dependency
+  fetch even when no response is received or a local fallback later succeeds.
+- **FR-050**: Release evidence MUST identify executor and independent reviewer, preserve failed runs,
+  distinguish invalid lab runs from product failures, and prohibit manual target repair within an
+  acceptance run.
+- **FR-051**: Every artifact MUST use a canonical semantic version, product/type/architecture identity,
+  SBOM, provenance attestation, signed channel mapping, support window and retention status. Mutable
+  filenames, branches or tags MUST NOT define release identity or promotion.
+- **FR-052**: Stable release promotion MUST preserve immutable artifact bytes, retain withdrawal and
+  revocation history, and provide an evidenced successor/update/recovery path through the declared
+  support lifecycle.
+- **FR-053**: Model-pack import MUST use bounded non-executable quarantine, reject unsafe or undeclared
+  archive content, and publish a fully verified runtime view atomically. Shared content MUST be keyed
+  and referenced by exact digest; interruption MUST leave the prior model set unchanged or recoverable.
+- **FR-054**: Model-pack deactivation, uninstall and garbage collection MUST preserve dependencies,
+  rollback/evidence holds and customer-created data, delete only zero-reference objects, and respond
+  deterministically to entitlement, tier/category, redistribution-license and security-withdrawal
+  changes without silently granting access or remotely deleting customer content.
+- **FR-055**: Production release signing MUST use purpose-constrained keys in a release trust domain
+  separate from license and test keys, dual-controlled offline root custody, independently approved
+  digest-bound signing requests and immutable receipts. Rotation, expiry, revocation, monotonic offline
+  trust updates and compromised-root recovery MUST fail closed for new activation without silently
+  destroying customer data or recovery access.
+- **FR-056**: Every release path MUST maintain an approved threat model from source and dependency
+  intake through build, signing, distribution, installation, activation, recovery and evidence export.
+  Security controls and tests MUST cover substitution, replay, unsafe archives, entitlement bypass,
+  hidden network dependency, partial activation, rollback mismatch, reference deletion, evidence
+  tampering, secret disclosure, insider role conflict, clock manipulation and architecture mismatch.
 
 ### Enterprise Appliance Requirements *(mandatory)*
 
@@ -310,6 +401,42 @@ licensed capabilities, key first tasks, help resources, and support evidence wit
   interactions on supported browsers.
 - **SC-016**: Consequential-operation submission provides acknowledgement or a validation result
   within 2 seconds in at least 95% of measured trials under normal appliance conditions.
+- **SC-017**: Every accepted offline ISO completes three clean zero-network installations, including
+  one reboot-boundary interruption run, with zero attempted dependency fetches and no undocumented
+  intervention.
+- **SC-018**: 100% of tampered, unsigned, expired-policy, revoked-key, incompatible-category/tier, and
+  insufficient-space model/update artifacts are rejected before target mutation.
+- **SC-019**: Every accepted interruption point produces the contractually declared recovery outcome
+  and a complete operation/evidence record; no tested interruption leaves an ambiguous active state.
+- **SC-020**: Every released ISO, model pack, and update bundle is reproducibly identified by product,
+  version, source revision, manifest digest, signature identity, byte size, and whole-artifact digest.
+- **SC-021**: The same AMD64 Offline Workstation ISO passes clean zero-network installation and
+  truthful capability selection on representative CPU-only/sub-threshold, 8 GB, 24 GB, and
+  48 GB-or-higher NVIDIA GPU profiles without presenting any profile as a Server tier.
+- **SC-022**: Every supported update path passes successful activation, power-loss interruption at
+  each mutating boundary, declared automatic or restore-based rollback, and rollback-failure recovery
+  with active application inventory and data/schema version in a consistent evidenced state.
+- **SC-023**: 100% of offline license-state, clock, binding, revocation, staging, replacement and
+  interruption cases produce the same entitlement decision across installer, backend, portal and
+  evidence surfaces, with no unauthorized capability or raw license/binding secret exposed.
+- **SC-024**: For every candidate ISO, signed inventory totals reconcile exactly with independently
+  extracted media, and measured clean-install peak target/staging/rollback usage supports the
+  published USB and disk minimum arithmetic with at least the required headroom.
+- **SC-025**: Every accepted offline artifact completes at least three clean runs, including two
+  physical targets and one declared interruption run, with classified packet evidence showing zero
+  attempted external dependency fetches and independent review of the evidence index.
+- **SC-026**: 100% of stable artifacts reconcile their inventory, canonical SBOM, provenance, signed
+  manifest/channel index and published digest, and an independent rebuild has no unexplained trusted
+  content difference.
+- **SC-027**: 100% of model-pack import, shared-object, dependency, license-change, uninstall and
+  garbage-collection acceptance cases finish with matching signed-pack inventory, reference graph,
+  runtime-visible models, entitlement decision, disk usage and independently reviewed evidence.
+- **SC-028**: 100% of signing acceptance cases reconcile approved input/output digests and receipts,
+  while wrong-domain/purpose/namespace/channel, unknown, revoked, expired, future, stale-sequence,
+  tampered, approval-mismatch and production-test-key cases are rejected with reviewed evidence.
+- **SC-029**: Every threat-register case has an assigned control, deterministic expected safe state,
+  linked automated or physical evidence and independent review; no artifact advances while a required
+  control test fails or a residual risk lacks an accountable accepting owner.
 
 ### Verification Evidence *(mandatory)*
 
@@ -354,3 +481,4 @@ licensed capabilities, key first tasks, help resources, and support evidence wit
 - Claiming high availability, redundancy, offline model availability, or recovery objectives that the
   deployed product has not been designed and validated to provide.
 - Implementing feature changes during this specification phase.
+- Embedding large optional models in any bootable ISO or creating tier-specific update formats.