GloriousFlywheel Advanced Runner Proof Matrix 2026-04-22

GloriousFlywheel Advanced Runner Proof Matrix 2026-04-22

Snapshot date: 2026-04-22

Owner surfaces:

  • #320 / TIN-335
  • #333 / TIN-371
  • #338 / TIN-377
  • #340 / TIN-378
  • #335 / TIN-376
  • #312 / TIN-330
  • #44

This note turns the broad “advanced runners” productization language into one ordered proof matrix.

The goal is not to claim broad support. The goal is to say which runner-class lane is real now, which one is next, and what would count as proof before the platform broadens its claims.

Current Ordering

  1. KVM
  2. GPU / WebGPU / Dawn
  3. macOS
  4. riscv
  5. broader cross-forge or rarer follow-on execution lanes

Matrix

Lane Current state Real proof already landed Next truth surface Why it is not mature yet
KVM active adjacent platform ask shared tinyland-nix-kvm lane is landed; repo-scoped nix-vm-test-kvm ran real terminal-first Rocky 10_1 smoke broader rockies execution, queue behavior, graphical/Budgie follow-on proof on honey execution is still too narrow and queue pressure still shapes the product boundary
GPU / WebGPU / Dawn tightened bounded repo-scoped proof surface Jesssullivan/cmux GPU Smoke Test (Self-Hosted) run 24756928163 completed success on main; job GPU smoke test (cmux-nix) built libghostty, built cmux-linux, ran Zig tests, and completed the GPU smoke workload behind the gpu-tests environment gate promote beyond repo-scoped cmux proof into one named shared honey GPU lane, then keep Dawn / WebGPU-specific canaries and operator docs as the broader follow-on the proof is real but repo-scoped, environment-gated, and still does not establish a shared ARC / honey GPU lifecycle or a Dawn / WebGPU contract
macOS tightened bounded repo-scoped proof surface tinyland-inc/lab Nix Build has repeated successful Build aarch64-darwin jobs on self-hosted runner xoxd-bates; lab#149 removed job-level continue-on-error, removed the permissive shell fallback on the Darwin build step, and re-proved Darwin on branch plus main decide whether to promote beyond repo-scoped proof into a platform-owned shared macOS runner contract the proof is real and now stricter, but it is still repo-scoped, self-hosted-mac-specific, and not a shared platform-owned contract
riscv not started none name the first workload, owner repo, and runtime boundary the lane is still demand-shaped, not product-shaped
Cross-forge follow-ons compatibility only Forgejo honey proof exists as bounded compatibility evidence repeatable GitHub-first runtime pattern before any parity claim there is still no mature multi-forge runtime contract

Explicit Backlog Mapping

  • #312 / TIN-330: KVM execution substrate
  • #338 / TIN-377: bounded cmux GPU proof surface
  • #340 / TIN-378: first shared honey GPU lane after the bounded cmux floor
  • #44: broader GPU / Dawn / WebGPU-specific slice after the first shared lane
  • #333 / TIN-371: broader advanced-runner proof matrix and sequencing
  • #335 / TIN-376: bounded macOS proof surface
  • TIN-127: Linux-builder / FlakeHub publication boundary
  • TIN-165: bazel-registry truth convergence

What Graduation Should Mean

For any advanced runner class, “proved” should require:

  • a named runner lane with explicit lifecycle ownership
  • one real runtime proof surface on an authoritative branch
  • explicit cache, bootstrap, and cleanup behavior
  • one downstream canary or owned-repo workload
  • public docs that describe the proved path rather than only prerequisites or design notes

Current Recommendation

  • keep treating KVM as the only active richer-runner productization lane
  • treat cmux GPU smoke as a named bounded proof surface, not as a shared platform-owned GPU contract
  • treat the next GPU move as one named shared honey lane with one real canary before broadening into Dawn / WebGPU maturity claims
  • treat lab Darwin success as a named bounded macOS proof surface, not as a shared platform-owned contract
  • do not broaden riscv or cross-forge claims until each lane has a named proof surface

GloriousFlywheel