GloriousFlywheel Exception Register And Promotion Rules 2026-04-17

GloriousFlywheel Exception Register And Promotion Rules 2026-04-17

Snapshot date: 2026-04-17

Purpose

Stop using one vague word, “adoption,” for several very different realities.

This note defines:

  • what counts as real GloriousFlywheel runner dogfood
  • what only counts as cache adoption
  • what remains hosted or hybrid
  • what exact change promotes a repo into the next credibility tier

Companion notes:

Evidence Tiers

These tiers are ordered from weakest to strongest.

Tier 0: Hosted Only

The authoritative default-branch workflow surface runs on GitHub-hosted runners only.

This does not count as GloriousFlywheel runner adoption.

Examples from the current active set:

  • Jesssullivan/tinyclaw

Tier 1: Hosted Cache Consumer

The repo explicitly uses Nix, Attic, or Bazel remote cache, but its default authoritative workflows are still GitHub-hosted.

This counts as cache adoption, not runner adoption.

Examples:

  • tinyland-inc/betterkvm
  • Jesssullivan/remote-juggler
  • Jesssullivan/tummycrypt

Tier 2: Hosted Template Consumer

The repo uses a shared workflow or shared contract surface that can target self-hosted runners, but the workflow code still defaults to ["ubuntu-latest"] or otherwise requires external repo configuration that is not visible in the workflow itself.

This is weak runner readiness, not proven runner dogfood.

Examples:

  • tinyland-inc/tinyvectors

Tier 3: Shared Self-Hosted Consumer

The repo’s default authoritative workflows visibly run on shared GloriousFlywheel lanes such as tinyland-docker, tinyland-nix, tinyland-nix-heavy, or tinyland-dind.

This counts as real runner adoption.

Examples:

  • tinyland-inc/lab
  • Jesssullivan/yt-text
  • parts of tinyland-inc/blahaj

Tier 4: Repo-Owned Dedicated Dogfood Lane

The repo uses a dedicated repo-owned self-hosted lane, usually through a repo variable such as PRIMARY_LINUX_RUNNER_LABELS_JSON, and the authoritative product path does not rely on hosted escape hatches.

This is the strongest downstream dogfood proof.

Near-term target example once the known promotion lands:

  • Jesssullivan/MassageIthaca

Tier X: Hybrid Or Mixed Surface

The repo spans more than one tier in ways that matter for platform claims.

This is not a failure state by itself, but it must not be reported as one clean kind of adoption.

Examples:

  • tinyland-inc/GloriousFlywheel
  • tinyland-inc/tinyland.dev
  • Jesssullivan/XoxdWM
  • tinyland-inc/blahaj

Promotion Rules

Rule 1: Runner Adoption Must Be Visible On The Default Branch

A repo does not count as runner dogfood if the real self-hosted proof only lives on:

  • feature branches
  • workflow dispatch only
  • non-authoritative optional lanes

Implication:

  • GloriousFlywheel does not get full self-dogfood credit from test-arc-runners.yml alone

Rule 2: Cache Adoption Does Not Equal Runner Adoption

Explicit Attic or Bazel remote-cache usage is valuable, but it does not mean the repo is consuming GloriousFlywheel runners.

Implication:

  • betterkvm, remote-juggler, and tummycrypt should improve the cache scorecard, not the runner-adoption number

Rule 3: Template Readiness Does Not Equal Proven Self-Hosted Use

If a repo uses ci-templates or repo-variable indirection that falls back to ["ubuntu-latest"], it should not be counted as a runner consumer unless one of these is true:

  • the workflow code passes self-hosted labels directly
  • the repo variable value is explicitly verified and recorded

Implication:

  • tinyvectors should be treated as a template consumer until its variable-backed or explicit self-hosted usage is proven
  • scheduling-kit and acuity-middleware have now crossed this proof bar, so their remaining problem is contract quality, not runner ambiguity

Rule 4: Dogfood Claims Require The Authoritative Path, Not A Side Lane

If the repo’s main CI or deployment authority still lives on hosted runners, then the repo is still mixed even if some heavy or specialized lane is self-hosted.

Implication:

  • tinyland.dev currently proves mixed cache and runner capability, not runner homogeneity

Rule 5: Raw [self-hosted, ...] Selectors Are Exceptions

Raw selectors are acceptable for:

  • hardware-bound jobs
  • platform compatibility jobs
  • temporary migration bridges

They are not the normal contract shape.

Implication:

  • XoxdWM hardware lanes
  • lab raw self-hosted macOS lane

must remain visibly exceptional

Rule 6: Implicit Runner State Is Not A Stable Contract

If a workflow relies on preinstalled Nix, preconfigured cache endpoints, or other runner-local assumptions without encoding them in workflow code or a documented shared action, then the repo is not yet homogeneous.

Implication:

  • yt-text is a real self-hosted canary, but still a weakly encoded contract

Rule 7: Persistent Workspace Hygiene Is A Platform-Level Exception

If the repo relies on actions/checkout with clean: false plus cleanup commands, that is still the persistent self-hosted workspace model.

This should be treated as a platform exception, not as a harmless repo detail.

Implication:

  • acuity-middleware
  • scheduling-kit
  • tinyvectors

inherit a hygiene risk from the shared template contract

Current Exception Register

Hosted Authority On Repos We Want To Count As Dogfood

These repos still keep important authority paths on GitHub-hosted runners:

  • tinyland-inc/GloriousFlywheel default-branch validate, release, docs, and publication paths
  • tinyland-inc/tinyland.dev Bazel CI, nix-check, and staging deploy
  • Jesssullivan/MassageIthaca beta and alpha post-deploy checks on dev/main until PR #189 lands
  • Jesssullivan/yt-text Pages deploy due to self-hosted OIDC routing problems

Branch-Gated Or Non-Routine Proof

  • tinyland-inc/GloriousFlywheel strongest ARC runner proof still lives behind feat/arc-runners and manual dispatch

Raw Self-Hosted Exception Lanes

  • Jesssullivan/XoxdWM raw [self-hosted, honey] hardware and VR surfaces
  • tinyland-inc/lab raw self-hosted macOS builder lane

Persistent Workspace Hygiene Exceptions

  • Jesssullivan/acuity-middleware
  • Jesssullivan/scheduling-kit
  • tinyland-inc/tinyvectors

Common issue:

  • shared JS and Bazel package template keeps clean: false checkout and cleanup-based hygiene rather than isolated per-job workspace

Implicit Bootstrap Or Cache Contract

  • Jesssullivan/yt-text self-hosted Nix path is real, but cache and bootstrap assumptions are mostly implicit in runner state

Hosted Cache Consumers Mistaken For Runner Consumers

  • tinyland-inc/betterkvm
  • Jesssullivan/remote-juggler
  • Jesssullivan/tummycrypt

Common issue:

  • real Nix and Attic usage exists
  • authoritative default-branch workflows are still hosted

Infra-Oriented Mixed Surfaces

  • tinyland-inc/blahaj mixes shared-runner image and domain lanes with cluster-ops ownership and hosted utilities
  • tinyland-inc/tinyland.dev mixes product CI, staging deploy, Nix package builds, and container concerns

Repo Promotion Ledger

Repo Current tier Smallest honest promotion
tinyland-inc/GloriousFlywheel Tier X hybrid move one authoritative default-branch CI path onto the normal self-hosted contract and stop relying on branch-gated proof
Jesssullivan/MassageIthaca Tier 4 once PR #189 lands keep repo-owned lane authoritative and remove hosted post-deploy drift from the product proof path
tinyland-inc/lab Tier 3 document one canonical shared Linux contract and keep raw Darwin and benchmark lanes explicitly exceptional
tinyland-inc/tinyland.dev Tier X hybrid move the authoritative product CI path off ubuntu-latest, not just the heavy Nix package lane
Jesssullivan/XoxdWM Tier X hybrid separate the canonical shared path from VR and raw hardware lanes, and remove hosted fallback from the shared path
tinyland-inc/blahaj Tier X hybrid split shared-runner consumer paths from cluster-ops ownership and stop counting the whole repo as one dogfood surface
Jesssullivan/acuity-middleware Tier X hybrid keep repo-owned package lanes self-hosted, replace cleanup-based persistent workspace behavior, and decide whether hosted Modal deploy remains a named exception
Jesssullivan/yt-text Tier 3 encode bootstrap and cache assumptions explicitly so the lane is reproducible outside runner-local state
tinyland-inc/tinyvectors Tier 2 verify or set self-hosted runner labels explicitly; otherwise leave it as hosted template consumption
tinyland-inc/betterkvm Tier 1 move default-branch CI from hosted Nix to tinyland-nix or remove it from runner-adoption metrics
Jesssullivan/scheduling-kit Tier 4 harden the shared-template workspace model and turn the repo-variable lane into an explicitly documented dedicated-lane contract
Jesssullivan/tinyclaw Tier 0 add one real self-hosted or cache-contract default-branch lane before counting it as GloriousFlywheel adoption
Jesssullivan/remote-juggler Tier 1 add a self-hosted default-branch path before promoting it beyond cache-adoption status
Jesssullivan/tummycrypt Tier 1 keep it as a cache canary unless default-branch self-hosted use becomes real

Immediate Program Implications

1. Fix The Metric

The platform needs at least three metrics, not one:

  • repos with real default-branch self-hosted runner adoption
  • repos with explicit cache adoption but hosted authority
  • repos with only template readiness or partial migration

2. Fix The Source Repo Claim

The source repo cannot keep speaking as though branch-gated ARC tests equal normal self-dogfood.

3. Fix The Shared Template Contract

The shared JS and Bazel package path is currently spreading:

  • hosted fallback
  • repo-variable ambiguity
  • persistent-workspace hygiene

That makes ci-templates one of the most leverage-heavy surfaces in the whole program.

4. Stop Overcounting Cache Users As Runner Users

This is the biggest current reporting risk.

The cache story is real. The runner story is real. They are not the same population today.

Recommendation

Use the following sentence as the internal planning standard:

“A repo only counts as GloriousFlywheel runner dogfood when its default-branch authoritative workflow visibly runs on a GloriousFlywheel lane or a verified repo-owned dedicated lane, without relying on hosted authority for the same claimed path.”

That one rule would eliminate most current overstatement.

GloriousFlywheel