GloriousFlywheel Wave 0 and Wave 1 Classification Matrix 2026-04-17

GloriousFlywheel Wave 0 and Wave 1 Classification Matrix 2026-04-17

Snapshot date: 2026-04-17

Purpose

Convert the active adoption board into an execution matrix.

This note is intentionally operational:

  • it captures what is already known for the current Wave 0 and Wave 1 repos
  • it marks unknowns explicitly instead of inventing certainty
  • it provides the shortest path to repo-by-repo truthing work

Companion notes:

Field Definitions

Runner pattern

  • shared labels
  • repo-owned dedicated lane
  • raw self-hosted compatibility
  • hosted escape hatch

Workspace pattern

  • per-job isolated checkout and cache
  • default runner workspace
  • mixed
  • unknown

Nix bootstrap

  • explicit
  • not needed
  • mixed
  • unknown

Cache posture

  • Attic yes/no/unknown
  • Bazel yes/no/unknown

Wave 0

Repo Runner pattern Workspace pattern Nix bootstrap Attic Bazel Hosted escape hatches Current truthing read Next step
tinyland-inc/GloriousFlywheel mixed shared labels plus hosted default-branch CI mixed mixed yes on self-hosted lanes yes on self-hosted lanes yes, extensively on validate, image, release, docs, and publication flows source-of-truth repo still does not use one normal default-branch self-dogfood path move ARC runner proof into routine default-branch CI and decide which hosted jobs are authority versus drift
Jesssullivan/MassageIthaca repo-owned dedicated lane via PRIMARY_LINUX_RUNNER_LABELS_JSON plus recent hosted post-deploy jobs per-job isolated checkout on core CI; beta and alpha alignment is in the new PR path not needed no current evidence of Attic use no current evidence of Bazel use yes, beta and alpha post-deploy checks were the key hosted escape hatches best current product-repo dogfood proof; blocker is hosted validation drift, not runner substrate failure verify PR #189 and then record repo-owned product-lane pattern as canonical
tinyland-inc/lab shared tinyland-nix labels plus a raw self-hosted macOS build lane default runner workspace explicit yes yes no clear hosted escape hatch in the inspected Bazel and Nix build paths; Darwin is a separate raw self-hosted lane strongest cache and builder canary, and the clearest live FlakeHub consumer, but still not one homogeneous contract pin one canonical lab path as the shared Linux runner plus setup-flywheel and FlakeHub contract, then document Darwin and benchmark lanes as exceptions
tinyland-inc/tinyland.dev mixed hosted default CI plus a shared tinyland-nix build lane default runner workspace mixed yes yes yes, extensively: Bazel CI, nix-check, and staging deploy all run on ubuntu-latest repo proves Bazel remote-cache and Attic usage, but not GloriousFlywheel runner homogeneity; the main CI path is still hosted decide whether tinyland.dev is supposed to be a product dogfood repo or a mixed cache-and-infra repo, then migrate its authoritative CI path accordingly
Jesssullivan/XoxdWM mixed shared labels, raw [self-hosted, honey] hardware lanes, and hosted fallback default runner workspace mixed yes unknown yes, cache-warm.yml still falls back to ubuntu-latest and some hardware flows remain exceptional strongest public user-owned canary, but the repo currently blends canonical shared lanes, hardware-only jobs, and fallback behavior into one surface split the canonical shared path from hardware and compatibility lanes, and remove hosted fallback from any lane we claim as dogfood
tinyland-inc/blahaj shared tinyland-docker and tinyland-dind lanes plus hosted utility jobs default runner workspace not needed for the inspected domain, image, and tofu flows no strong current evidence no yes, detect-changes and several utility paths still run on ubuntu-latest real GloriousFlywheel consumption exists here, but the repo is mostly cluster-ops and container ownership rather than a clean downstream contract example keep blahaj in the exception register and classify each workflow family as shared-runner consumption, cluster-ops ownership, or hosted utility work
Jesssullivan/acuity-middleware repo-owned dedicated lane for package CI and publish plus explicit hosted deploy default runner workspace with clean: false checkout and cleanup-based hygiene not needed no yes yes, package workflows use verified repo-specific runner labels, but deploy-modal.yml and other utility flows still run on ubuntu-latest important because it exposed a platform hygiene defect inside a real repo-owned downstream contract, not just a hypothetical template path fix workspace hygiene in ci-templates and the runner envelope, then decide whether Modal deploy remains a named hosted exception
Jesssullivan/yt-text shared self-hosted Nix labels plus hosted Pages deploy default runner workspace mixed unknown in workflow code no yes, docs.yml keeps Pages deployment on ubuntu-latest because self-hosted OIDC has been unreliable strongest current heavy-Nix runner canary, but the workflow still relies on runner state instead of encoding the cache and bootstrap contract explicitly make the heavy-lane bootstrap and cache contract explicit in workflow code, then benchmark cold and warm behavior against the baseline lane

Wave 1

Repo Runner pattern Workspace pattern Nix bootstrap Attic Bazel Hosted escape hatches Current truthing read Next step
tinyland-inc/tinyvectors hosted shared-template consumer unless repo variables override the template default default runner workspace with cleanup-based hygiene from ci-templates not needed no yes yes, the shared package template defaults to ["ubuntu-latest"] and this repo does not pass runner labels in workflow code active Bazel package consumer, but not a proven GloriousFlywheel runner consumer on main from workflow code alone verify whether the repo actually sets PRIMARY_LINUX_RUNNER_LABELS_JSON; until then, treat it as a hosted template consumer rather than runner dogfood
tinyland-inc/betterkvm hosted-only on current default branch default runner workspace explicit yes no strong current evidence yes, the whole default-branch CI surface is still ubuntu-latest this repo is a Nix and Attic consumer waiting for runner migration, not a current GloriousFlywheel runner proof point either schedule explicit tinyland-nix adoption or remove it from runner-adoption claims until that work lands
Jesssullivan/scheduling-kit repo-owned dedicated lane via verified PRIMARY_LINUX_RUNNER_LABELS_JSON default runner workspace with cleanup-based hygiene from ci-templates not needed no yes no current hosted authority in the inspected CI and publish paths product-adjacent package repo is already a real repo-owned self-hosted consumer, but the contract is still encoded through a hygiene-weak shared template keep it as the first js-bazel-package V2 pilot and use it to prove the dedicated-lane contract without hosted fallback
Jesssullivan/tinyclaw hosted-only default runner workspace mixed no no strong current evidence yes, the inspected build, PR, GHCR, release, and Nix check flows are all on ubuntu-latest this repo is active, but it is not currently part of the GloriousFlywheel runner or cache contract beyond ordinary GitHub-hosted caching leave it out of runner-adoption claims until a self-hosted or cache-contract lane actually exists
Jesssullivan/remote-juggler mixed, but currently dominated by hosted CI and hosted Nix/Attic workflows default runner workspace explicit on Nix flows yes no strong current evidence yes, the inspected ci.yml, nix-ci.yml, containers.yml, tofu-apply.yml, and release paths are all GitHub-hosted this repo is more honestly a hosted Nix and Attic consumer than a GloriousFlywheel runner consumer on main today separate cache-adoption claims from runner-adoption claims and only promote it once a real self-hosted path exists on the default branch
Jesssullivan/tummycrypt hosted Nix and Attic consumer default runner workspace explicit on Nix flows yes no strong current evidence yes, the inspected CI, Nix CI, docs, and release surfaces are GitHub-hosted real cache consumer with multi-platform Nix builds and Attic push, but not a GloriousFlywheel runner consumer on main today keep it in the cache-adoption lane and only count it toward runner adoption after a real self-hosted default-branch path exists

Unknowns That Matter

These unknowns should be treated as planned inspection work, not as harmless documentation gaps:

  • which repos that appear in code search are actually self-hosted consumers on their default branch versus hosted template or hosted cache consumers
  • which repos still assume the default persistent self-hosted workspace
  • which repos still use hosted runners for dogfood-claimed paths
  • which repos need explicit Nix bootstrap but have not encoded it yet

Immediate Inspection Order

Recommended order for repo-level truthing work:

  1. GloriousFlywheel
  2. MassageIthaca
  3. lab
  4. XoxdWM
  5. yt-text
  6. tinyland.dev
  7. acuity-middleware
  8. blahaj
  9. remote-juggler
  10. tummycrypt

Reason:

  • this order closes source-of-truth and product-dogfood gaps first
  • then it proves cache and heavy-Nix behavior
  • only after that does it widen into the ambiguous cache-adjacent Wave 1 set

Exit Condition

  • every Wave 0 repo has a filled row with no unknown fields in the core contract columns
  • Wave 1 repos are either promoted to named canaries or explicitly left as ordinary consumers
  • the platform can explain not just who uses the runners, but how each active repo consumes the GloriousFlywheel contract

GloriousFlywheel