Quality model

Strict gates from the first commit

Quality is not a phase at the end of the project: it is a permanent entry barrier. The test pyramid and the target-environment replica exist before the features, and nothing merges red. Every milestone publishes its raw acceptance report — trust is measured, not declared.

Five levels

The pyramid

Fast checks run on every push; expensive, realistic ones gate releases. A merge gate must be hermetic and deterministic — realism lives at its own level, where flakiness cannot erode discipline.

LevelWhat runsTriggerGates
Unitgo test -race -count=2 (anti-flaky), per-package coverage floors — stricter on security pathsEvery pushMerge
IntegrationReal registries and identity providers in containers — no mocks of the OCI protocol, everEvery PRMerge
e2e coreHermetic container topology: seeded public/private registries, an air-gapped network with no route out (proven by an egress canary that must fail), k3s, real helm install at the endEvery PRMerge
e2e extendedSame topology, extended matrix — multi-arch, large blobs, Windows mirror flow on native runnersNightly + tagsRelease
CrucibleDisposable replica of the target environment on real VMs (Incus): internet-connected node, physical-transport simulation, air-gapped RKE2 clusterOn demand + every milestoneAcceptance
The crucible

A disposable replica of the real thing

Scenarios that containers cannot honestly model run on a throwaway copy of the target environment, driven byIncuson any Linux host with KVM (ADR-0014).

Air gap by absence of path

The isolated side sits on a bridge with no uplink — plus a canary check that attempts egress and must fail. If the topology ever leaks, the canary breaks, not the credibility.

The medium is a real device

A block volume attached to the connected node, formatted (exFAT/FAT32 cases included), filled, detached, re-attached air-gap side — faithfully exercising pre-flight checks and dirty-ejection resilience.

Scenario reset in seconds

ZFS/btrfs snapshots restore seeded states instantly between runs; fidelity nodes are VMs, fixtures are system containers — one API drives both.

Replayable per milestone

Writing its crucible scenarios is part of every milestone's definition of done. Scenarios are tagged by milestone and independently invocable: the whole suite of completed milestones — or any subset — runs on demand, forever.

The crown scenario: bootstrapping an RKE2 cluster on a bare OS in the air-gapped zone, entirely from Tobby — OS packages from served FileSets, RKE2 artifacts and images from the transported store, the cluster pulling through the zone registry with the generated mirror configuration. Final acceptance is a crucible run that has already passed dozens of times.

Supply chain

The gate gates itself

Acceptance reports

Raw results, published per milestone

Each milestone ships its acceptance report — every check listed, including skips and detected defects.