# Preview readiness and operator gates

The reserved version is `0.2.0-preview.1`. A development archive, successful
local checks, or VICE execution is not a published or physically accepted
release. This checklist records the remaining decisions without granting them.

## Candidate record

Before any physical or publication request, record:

- Exact source commit and dirty state; candidate archive and source SHA-256.
- Both host executable hashes and observed Ubuntu 24.04 x86-64 / glibc 2.39
  build and runtime results.
- Corrected and buggy checkpoint PRG/map/ELF hashes, source snapshot identity,
  exact VICE 3.8 version, emulator acceptance record and registered checksums.
- Local automated check result and independent review disposition.
- Spindle result URL, candidate commit and observed resource limits, or
  explicitly `not verified` when the setup gate has not run.
- Corresponding-source, third-party notice and public-source privacy review.
  Mechanical archive verification cannot replace that human review.

Never put passwords, session tokens, private addresses or unreviewed raw run
files into this public record. Keep the private authorization and hardware
identity details with the operator's local evidence.

## Separate Spindle setup gate

1. Obtain permission for read-only inspection of the supplied Spindle/Knot
   linkage, installed version, engines, image names and limits.
2. Present any required settings/image changes separately for approval. Do not
   assume a generic image alias exists, expose the host Docker socket, or give
   CI credentials or hardware access.
3. Run the secret-free linkage/container smoke, then the full workflow for the
   candidate commit. Preserve its observable result. Local success does not
   satisfy `spindle_link_smoke` or `spindle_full_check`.

See [CI setup](CI.md).

## Separate physical gate

All implementation checks and the fixture/mutation review must pass first.
The operator then approves the read-only identity/service probe separately
from the proposed runs. Historical acceptance identifies a device; it does not
prove its current identity, firmware, configuration, availability or consent.

Present an exact budget derived from the selected manifests and current target
adapter, including failure and cleanup paths. The intended gate uses an explicit
fail-stop policy: no read retries, no best-effort screen fallback, no mutation
replay, and at most one resume request total for each attempted pause episode.
That resume is normal completion or an explicitly approved conditional cleanup,
not a second resume after an ambiguous response. Until that policy and its
attempt audit pass review and tests, do not execute this gate using ordinary
runner defaults. The proposed successful path is:

| Selected operation | Successful-path device mutations |
| --- | --- |
| Corrected `checkpoint-pass`, after eligible VICE baseline | One `run_prg`; one screen pause/resume pair; no startup command write |
| Separate known-good `smoke` health run | One `run_prg`; one coordinated startup-command pause/write/resume; one screen pause/resume pair |

This is **two separately counted resets**, not a standing authorization.
Checkpoint evidence itself reads a 4-byte marker, three 8-byte rows twice, and
the 4-byte marker again: 56 bytes, no writes or pause/resume. Deployment,
mailbox polling and screen reads are additional operations. Do not present the
successful-path table as a complete bound on error cleanup: review and disclose
those paths before approval, and stop if they exceed the permission granted.

Require unchanged pinned identity/configuration, observed terminal and screen
pass, expected stable ledger, a `matched` same-artifact pair, registered
checksums, resumed CPU, and the separately approved health pass. On ambiguous
acceptance or mutation failure, retain evidence and stop. No hidden retry,
extra recovery reset, stream start, REU/configuration/flash/power/native action
is permitted. Any further run requires new approval.

`ultimate_checkpoint_physical_acceptance` remains unverified until those
observable checks actually complete. Fake and VICE cannot satisfy it.

## Two-minute demonstration storyboard

Capture tooling is operator-assisted; this document is not a video recording.
Record only after deciding which verified evidence may be shown.

| Approximate time | View and explanation |
| --- | --- |
| 0:00–0:20 | Product goal and local dashboard. State whether the session uses fake observations, prebuilt replay or a real source build. |
| 0:20–0:50 | VICE buggy arithmetic: health 5 minus damage 9 wraps rather than clamping. Show the actual failed run and unique instrumented source diagnosis. Ordinary panic is not an exact-site result. |
| 0:50–1:15 | Corrected source/build, emulator pass, and independently checked frozen ledger. Keep variant hashes distinct. |
| 1:15–1:45 | Only if physically accepted: approved same-PRG VICE/Ultimate pair and `matched` rows. Otherwise show VICE repeatability and subtitle "physical comparison not yet verified". |
| 1:45–2:00 | Immutable evidence, support limits, first-result command and next step. "Earliest recorded logical checkpoint" is not earliest instruction or cause. |

Before recording, hide private addresses/hostnames/IDs, account names, absolute
paths, raw logs, credentials, token-bearing URLs and password prompts. Prefer
the sanitized static derivative over a raw evidence directory. Review all
frames, subtitles, audio and file metadata. Preserve gap/truncation/unavailable
labels. The operator approves the final derivative/video separately from its
creation and separately from publication. Record that approval as
`showcase_video_truth_and_privacy_review`; do not invent a demo link before a
reviewed video exists.

## First-use session

Ask one person who did not implement the feature to perform these tasks on the
documented prerequisites. Do not collect personal data.

1. Verify binary/source archive checksums and manually install both executables.
2. Run the local first-run sequence. Measure time to the first result; target
   at most ten minutes after prerequisites are available.
3. Open the dashboard, explain what failed, what source/evidence supports the
   conclusion, and why fake observations are not C64 execution proof.
4. Use the external-project template; explain which parts do not require SDK
   mailbox adoption.

Record task duration, obstacles, errors, and the participant's explanation
without a name or screen recording unless separately approved. Fix blocking
friction and rerun affected automated scenarios. Automated tutorial tests are
useful but do not satisfy `new_user_first_result_session`.

## Publication and download

Final human license/privacy review, annotated tag/push, account/PDS selection,
artifact publication and visibility changes each remain separate approvals.
Use the local preflight and dry-run before obtaining a secret. Never publish
from CI. After approved publication, verify anonymous binary/source/checksum
downloads and install from that location on the documented baseline. Keep
`published_artifact_download_install` unverified until observed.

See [release procedure](RELEASING.md). Until these gates are recorded, describe
the product as an unreleased preview candidate with explicit pending checks,
not an operational public release or newly accepted hardware workflow.