Release Qualification Conveyor

Release Qualification Conveyor

The operator selected an ordered conveyor for release qualification: Docker is built and checked first, a Docker station sits between the VirtualBox Linux-guest and Windows-guest stages, and another follows the Windows guest. Each transition is therefore Docker-to-Docker: the same harness judges what one VM stage handed off and whether the next may start. This is planned (REQ-085, REQ-086), not an implemented gate.

Station	Kind	Work	Exit condition
D0	Docker	Build the transition harness and the existing LUnit gate images from the candidate commit; record their digests; run both existing LUnit gates.	Both LUnit conditions pass for the candidate, and the harness digest is recorded.
V1	VirtualBox Linux guest	The ubuntu-linux and ubuntu-windows-public lanes.	Each lane is terminal with its required proof and completed cleanup.
D1	Docker	Harness verifies the D0 record and each V1 lane's handoff, and that no qualification-owned V1 resource remains pending.	PASS admits V2.
V2	VirtualBox Windows guest	The windows-linux lane.	The lane is terminal with its required proof and completed cleanup.
D2	Docker	Harness verifies the D1 record and the V2 handoff, and emits the conveyor summary.	PASS makes the summary available to the release gate; it does not publish anything.

Rationale and constraints:

• Fail early and cheaply. D0 rejects a candidate whose images or LUnit checks fail before any scarce VM time is spent. The Linux-guest stage precedes the Windows guest because its lanes are shorter and exercise the public lifecycle first; this ordering is an efficiency choice, not a dependency claim between guest families.
• Strict order, no borrowing. A stage starts only after its predecessor station reports PASS for the same conveyor ID and resolved candidate. A record from another conveyor, candidate, or harness digest cannot fill a gap. FAIL or UNKNOWN halts the conveyor; a restart begins a new conveyor ID at D0. Resuming after a failed station would need a separately reviewed rule proving that earlier records remain applicable, so it is not part of this direction.
• One harness, no authority. D0 builds the harness image from the candidate; D1 and D2 run that exact digest with networking disabled, read-only inputs, an allowlisted environment, and no hypervisor device, Docker socket, or GitHub credential. The launcher must enforce and attest that sandbox; the harness's own refusal checks are defense in depth and cannot detect every mounted secret or control path. It evaluates records; it never starts, stops, restores, or cleans up a VM and never writes to GitHub. Lane cleanup remains each lane's obligation under REQ-074, so a station that sees pending cleanup reports UNKNOWN rather than performing it.
• Verified evidence, not assertions. A station judges handoffs only through evidence already verified under REQ-071 through REQ-080: lane lineage, invocation binding, known-answer job, dependency identities, and cleanup. D0 likewise requires authenticated LUnit gate evidence, including candidate-built image and suite identities, run identity, and completion time within the existing 90-day limit. A self-asserted PASS, complete, or syntactically valid digest is not evidence; unverifiable evidence is UNKNOWN.
• One record per station. Station records for a conveyor are append-only in the protected authority. A second, different record for the same conveyor and station is a fork and fails the conveyor; an identical repeat adds no new authority. The harness cannot enforce this by itself because a fresh output location would accept a rerun.
• Chained, not authenticated. Each station record binds conveyor ID, candidate commit, station index, harness digest, and its predecessor record digest. The chain detects reordering and substitution only among records it is given; it does not authenticate them, resist host-storage rollback, or attest a VM. REQ-076 and REQ-077 still govern integrity and continuity, and the release gate independently revalidates every proof under REQ-075 rather than trusting a D2 PASS.
• Host placement. Lanes run on different VirtualBox hosts, so a station may run on a different Docker host than its neighbors. The harness image is a Linux container and needs no Windows containers. Pinning by digest, not by tag, keeps the judgment identical across hosts. Another host must receive the D0 image by content digest; a local rebuild is a different harness unless its digest matches, and the launcher, not the harness, must bind the running image to the recorded digest. The existing LUnit gates keep their current GitHub-hosted runner classes (ubuntu-latest and windows-2022); D0 orders them, it does not move them.
• Docker-to-Docker conformance. Because stations consume only records, the transition logic can be exercised entirely in Docker with synthetic stage records, before any live VM work. Synthetic records stand in for verified evidence there and must never be accepted outside conformance. Such a run tests the harness; it is not a release qualification and must not be reported as one.