# Nexus One AI Offline Workstation Payload

This directory contains Gate 2 Offline Workstation payload-resolution and disposable-validation
tools. **It does not currently contain a lock-driven bundle assembler or `build-iso-offline.sh`.**
No command in this directory produces a release ISO, and the existing mutable body in
`build-bundle.sh` is deliberately unreachable.

The agreed bootable release matrix is:

1. Online Universal Server ISO with Server S/M/L/Max selection.
2. Offline Workstation ISO.
3. Offline Server S/M ISO.
4. Offline Server L/Max ISO.

Large models remain separate signed model packs. Signed update bundles patch
installed appliances without an operating-system reinstall, and validated
updates are periodically rolled into refreshed ISO builds.

## Offline Workstation contents

- the exact `aipackage` source revision used for the build
- Ubuntu, Docker, NVIDIA and appliance `.deb` packages
- Python wheels for the backend, RAG, ChromaDB and optional JupyterLab
- Miniconda installer and an offline Python 3.11 environment package
- Ollama runtime with `phi3:mini` and `nomic-embed-text`
- vLLM and web/monitoring container images
- the pinned Phi-3 Hugging Face model snapshot used by vLLM
- K3s, MinIO and `mc` binaries for update/model packs (not enabled by Starter)
- SHA-256 manifests and build provenance

Server L/Max models are intentionally separate signed model packs. Optional external
connectors cannot operate without a customer-approved route to their target.

## Current operator flow

The only authorized/current flow is:

1. Resolve candidate inventory on a connected, isolated staging host.
2. Review candidate object identity, bytes, origin, license and unresolved entries.
3. Validate the candidate lock; it MUST fail while status is not `reviewed` or unresolved entries exist.
4. Exercise signed-profile, checkpoint, install and rollback components only against disposable targets.
5. Stop. Assembly, ISO injection, signing and release validation are not implemented.

| Stage | Tool | Current status |
|---|---|---|
| Source/OCI candidate resolution | `resolve-payload-lock.py` | Evidence-only; OCI archive bytes/licenses remain open |
| Clean APT closure | `resolve-apt-lock.py` | Evidence-only; repository snapshot/origin/licenses and NVIDIA APT closure remain open |
| Backend/Chroma/platform wheel closures | `resolve-python-lock.py` | Evidence-only; three independent environments, candidate lock only |
| Whole-lock preflight | `validate-payload-lock.py` | Available and fail-closed |
| CPU/NVIDIA profile bytes | `validate-python-runtime-profile.py` | Available for exact candidate directories |
| Signed membership | `verify-python-profile-membership.py` | Implemented/test-key proven; production trust inputs absent |
| Selection planning | `plan-python-runtime-profile.py` | Non-mutating; production receipt required by default |
| Atomic journal/checkpoint preparation | `prepare-python-profile-operation.py` | Disposable/pre-mutation evidence only |
| Offline Python mutation/rollback | `install-python-profile.py` | Disposable targets only; not installer-wired |
| Bundle assembly | `build-bundle.sh` | Hard blocked after lock validation; legacy body unreachable |
| Offline ISO build | `autoinstall/build-iso-offline.sh` | Absent; C1 readiness blocker |

## Candidate resolution stages

1. Resolve `payload-lock.candidate.json` into a reviewed `payload-lock.json` containing every object
   version, architecture, source, target, byte size, SHA-256 and license. The candidate intentionally
   fails validation while any entry is unresolved.
   The first connected resolution stage is:
   `python3 autoinstall/offline/resolve-payload-lock.py --candidate
   autoinstall/offline/payload-lock.candidate.json --source-root . --container-sources
   autoinstall/offline/container-sources.json --staging <gate2-staging> --output <candidate-lock>`.
   It creates a deterministic source archive and resolves the Linux/AMD64 OCI manifests without
   pulling image layers. Registry-declared bytes are not final measured payload bytes.
   Resolve the Ubuntu package closure from an empty package state with
   `python3 autoinstall/offline/resolve-apt-lock.py --lock <candidate-lock> --packages
   autoinstall/offline/apt-packages.txt --work <apt-staging> --output <next-candidate-lock>`.
   The result records exact `.deb` bytes but remains unresolved until repository snapshot/origin,
   license/notice, and the separate NVIDIA R570/CUDA 12.8.1 closure are approved.
   Resolve the three independent Python 3.11 wheel closures with
   `python3 autoinstall/offline/resolve-python-lock.py --lock <candidate-lock>
   --backend-requirements ansible/roles/cezen-backend/files/requirements.txt
   --platform-requirements autoinstall/offline/python-packages.txt --work <python-staging>
   --output <next-candidate-lock>`. The resolver pins its own pip version, accepts binary wheels only,
   and hashes every wheel. Index provenance, licenses, offline install/import and CUDA compatibility
   remain review gates.
2. Run `python3 autoinstall/offline/validate-payload-lock.py
   autoinstall/offline/payload-lock.json`. No acquisition or output deletion occurs before this passes.
3. Do not run `build-bundle.sh` expecting output. It validates the lock and then stops because
   lock-driven acquisition is not implemented. It will not fall back to the legacy mutable path.

## Disposable profile evidence

- `python-runtime-profiles.json` defines exactly-one `cpu-only` or `nvidia-cu128` selection.
- `verify-python-profile-membership.py` emits the closed receipt consumed by the planner; structural
  test receipts require an explicit test-only switch and are rejected in production mode.
- `prepare-python-profile-operation.py` validates membership and wheel bytes, writes the atomic journal,
  creates/verifies the checkpoint and stops at `checkpoint_ready` without mutation.
- `install-python-profile.py` installs from a selected local wheel directory with `--no-index`, performs
  health checks, atomically activates, and supports checkpoint rollback. It is currently authorized
  only for disposable evidence paths.

## Mandatory stop conditions

Stop without assembly or mutation when any of the following is true: lock status is not `reviewed`,
unresolved entries remain, a required object/hash/profile membership is missing, signature/trust policy
is unverified, the journal/checkpoint is invalid, the selected hardware profile is unsupported, or the
target is not an explicitly disposable evidence path.

An ISO must not be labelled offline merely because source or candidate payload bytes were embedded.
Only a future signed, lock-driven artifact that passes the full disconnected acceptance matrix may use
the Offline Workstation release label.