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.

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:

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.

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. 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.