GloriousFlywheel Adoption, Homogeneity, And Dogfood Plan 2026-04-17

GloriousFlywheel Adoption, Homogeneity, And Dogfood Plan 2026-04-17

Snapshot date: 2026-04-17

Purpose

Turn the current runner-adoption and builder-runtime notes into one honest program.

This note is intentionally explicit about four things:

  1. what GloriousFlywheel can honestly claim today
  2. where the current contract is still fragmented
  3. what “homogeneity” should actually mean for owned repos
  4. the phased path from today’s mixed runner usage to real dogfood of runners, Bazel, Nix, Attic, and later FlakeHub

Companion notes:

Honest Current Position

What We Can Honestly Claim Today

  • GloriousFlywheel is a real on-prem GitHub Actions runner platform on honey with live ARC scale sets.
  • owned repos already use those runners in production-like CI paths
  • Attic and Bazel remote cache are real acceleration layers in the platform
  • the platform already has at least one explicit heavy-Nix additive lane: tinyland-nix-heavy
  • named dogfood repos like MassageIthaca prove that repo-owned self-hosted lanes can carry core CI

What We Cannot Honestly Claim Today

  • that owned repos already use one uniform GloriousFlywheel contract
  • that setup-flywheel or the public composite-action surface is the default downstream experience
  • that FlakeHub is part of the active runtime, bootstrap, or publication path
  • that ARC self-scales memory or CPU envelope per job
  • that GloriousFlywheel itself fully self-dogfoods on its default branch

Current Facts

Live GitHub inspection on 2026-04-17 plus current repo notes show:

  • current visible gh repo list output shows 236 non-fork repos across tinyland-inc and Jesssullivan
  • older planning notes used a larger 264-repo non-fork denominator, so the owned-repo census itself should be re-truthed rather than treated as stable
  • literal workflow references to tinyland-* runner labels appear across at least 15 repos:
    • 7 under tinyland-inc
    • 8 under Jesssullivan
  • at least one additional repo-owned dogfood path is variable-driven rather than literal-label driven: Jesssullivan/MassageIthaca
  • workflow references to tinyland-inc/GloriousFlywheel/.github/actions/setup-flywheel@main appear in only 3 repos:
    • tinyland-inc/GloriousFlywheel
    • tinyland-inc/lab
    • Jesssullivan/XoxdWM
  • GloriousFlywheel itself still mixes hosted and self-hosted CI on the default branch:
    • validate.yml runs app and MCP checks on tinyland-docker
    • the same workflow still runs config, OpenTofu, markdown, and link checks on ubuntu-latest
    • image and release publication flows remain GitHub-hosted
  • the strongest self-dogfood workflow, .github/workflows/test-arc-runners.yml, is still gated to feat/arc-runners and workflow_dispatch, not normal default-branch CI
  • Nix bootstrap truth is now clear: self-hosted tinyland-nix workflows cannot assume Nix is preinstalled and should use DeterminateSystems/determinate-nix-action@v3 or nix-job
  • Attic and Bazel are implemented mutable acceleration layers
  • FlakeHub is still not implemented in primary repo surfaces
  • ARC auto-scales runner count horizontally, not runner memory vertically

Honest Scorecard

Area Current reality Honest status
Owned-repo runner adoption real but limited to a small visible subset of repos partial
Workflow homogeneity mixed shared labels, raw self-hosted selectors, repo variables, and hosted escape hatches weak
Self-dogfood in GloriousFlywheel present but not the default proof path partial
Bazel dogfood real platform injection exists, but downstream standardization is still thin weak
Nix dogfood real and improving, but bootstrap still leaks into repo-specific fixes partial
Attic dogfood real cache usage exists, but not yet a uniform downstream contract partial
FlakeHub strategic future surface only aspirational
Self-scaling story horizontal ARC autoscaling exists; vertical autoscaling does not partial but often overstated

What Homogeneity Should Mean

Homogeneity should not mean every repo literally uses the same label string.

That would blur two different things:

  • shared public runner classes
  • repo-owned dedicated dogfood lanes for high-value product repos

The real homogeneous target is:

  1. one stable contract shape
  2. one explicit exception model
  3. one honest publication boundary

Stable Contract Shape

Every owned repo should land in one of these patterns:

  • shared baseline CI
    • tinyland-docker
    • tinyland-nix
    • tinyland-nix-heavy
    • tinyland-dind
  • repo-owned dedicated dogfood lane
    • expressed through a repo variable such as PRIMARY_LINUX_RUNNER_LABELS_JSON
  • compatibility exception
    • a consciously recorded hosted or raw-self-hosted path with an owner and exit condition

Exception Model

Any repo that still uses:

  • ubuntu-latest for a path we claim is dogfooded
  • raw [self-hosted, ...] selectors outside a documented compatibility case
  • stale Jesssullivan/GloriousFlywheel/... references

should be treated as an exception, not as an invisible part of the default contract.

Publication Boundary

Homogeneity also requires saying the builder/publication story the same way everywhere:

  • Attic = mutable Nix acceleration
  • Bazel remote cache = mutable build acceleration
  • GHCR = current durable OCI publication
  • FlakeHub = later clean-derivation discovery and publication, not current bootstrap or runtime

Main Gaps From The Promise

1. Adoption Is Broader Than The Old Tranche But Still Shallow

The platform is clearly in use, but not yet in the form of a default owned-repo product.

Current gap:

  • many repos use runner labels
  • far fewer repos use the GloriousFlywheel action or cache contract directly
  • the long tail of owned repos is not yet classified by active need, repo role, or migration priority

2. Dogfood Proof Is Still Split Between Strong Canaries And Weak Defaults

The current source-of-truth repo is still not saying:

“our normal default-branch CI proves our normal default platform contract.”

Current gap:

  • the default-branch self-dogfood path is partial
  • the strongest ARC validation workflow is not part of ordinary mainline proof
  • product repos like MassageIthaca have only recently started closing hosted beta escape hatches

3. Bazel, Nix, And Attic Are Not Yet One Unified Consumer Story

Current gap:

  • Bazel dogfood is still thin outside a small number of repos
  • Nix dogfood now has a real bootstrap truth, but that truth is still not uniformly encoded across downstream workflows
  • Attic is real, but many workflows still consume it implicitly rather than via one obvious platform path

4. FlakeHub Is Still A Story Boundary, Not A Delivery Surface

Current gap:

  • FlakeHub remains strategically interesting
  • but the repo still has no real clean-derivation gate or publication automation
  • trying to make FlakeHub part of the current runtime promise would still be premature and misleading

5. “Self-Scaling” Needs Tighter Language

Current gap:

  • ARC does scale runner count
  • ARC does not resize the memory envelope for one running pod
  • the existence of free cluster RAM does not mean a job on tinyland-nix avoids OOM
  • the real answer today is additive lanes and placement policy, not magical autosizing

Phase 0: Truth Surface And Classification

Owner surfaces:

  • #210
  • #212

Goal:

  • replace vague adoption language with one owned-repo classification surface

Work:

  • classify all active owned repos into:
    • shared-label consumers
    • repo-owned dogfood lanes
    • compatibility exceptions
    • no-current-need repos
  • record for each repo:
    • runner pattern
    • Bazel usage
    • Nix usage
    • Attic expectations
    • publication path
    • current hosted escape hatches
  • publish a short “what we can claim today” note derived from measured facts, not intent

Exit signal:

  • the repo stops using literal-label hits as the only adoption metric
  • named dogfood repos and exception repos are both visible
  • runner-adoption reporting is split from cache-adoption reporting

Phase 1: Close Self-Dogfood Gaps In The Source Repo

Owner surfaces:

  • #210
  • #213
  • #214

Goal:

  • make GloriousFlywheel itself prove the contract it asks others to use

Work:

  • move test-arc-runners.yml onto the default-branch truth path or equivalent recurring CI path
  • decide which validate.yml jobs should stay hosted and which should become standard self-hosted proof points
  • keep publication workflows hosted where that is still the right authority, but stop using hosted defaults for builder/runtime proof
  • close persistent runner workspace hygiene issues so checkout reliability is part of the dogfood story

Exit signal:

  • a normal mainline GloriousFlywheel CI run proves:
    • tinyland-docker
    • tinyland-nix
    • tinyland-nix-heavy
    • injected Bazel and Attic coordinates
    • explicit Nix bootstrap

Phase 2: Normalize Runner And Workspace Homogeneity

Owner surface:

  • #210

Goal:

  • make repo workflows look like one family instead of four unrelated idioms

Work:

  • standardize on one self-hosted workspace pattern for long-lived runners: per-job checkout paths and per-job caches
  • standardize on one variable shape for repo-owned dedicated lanes
  • standardize on one shared-label contract for ordinary repos
  • keep raw [self-hosted, ...] selectors only where hardware or compatibility really require them

Exit signal:

  • named dogfood repos stop mixing hosted escape hatches and ad hoc self-hosted selectors without explanation
  • the repo has one short authoritative guide for “shared label” versus “repo-owned dedicated lane”

Phase 3: Real Bazel, Nix, And Attic Dogfood

Owner surfaces:

  • #210
  • #212

Goal:

  • turn cache/runtime surfaces into active defaults, not just platform plumbing

Work:

  • pick a small benchmark pack of real repos and compare:
    • GitHub-hosted baseline
    • tinyland-docker
    • tinyland-nix
    • tinyland-nix-heavy where applicable
  • require explicit Nix bootstrap on all self-hosted Nix jobs
  • increase setup-flywheel or equivalent contract usage across the most active owned repos
  • document which repo classes should use:
    • labels only
    • docker-job
    • nix-job
    • setup-flywheel

Exit signal:

  • at least one Bazel-heavy repo, one Nix-heavy repo, and one product repo have benchmarked before/after results
  • downstream docs can show measured wins and known losses instead of generic acceleration claims

Phase 4: Scaling Truth And Lane Governance

Owner surfaces:

  • #214
  • #212

Goal:

  • replace “self-scaling” ambiguity with a clear lane and capacity model

Work:

  • prove tinyland-nix-heavy under a real heavy workload, not only a named policy object
  • decide whether any baseline lane envelopes should change after measured runs
  • publish the rule: horizontal scaling is automatic; heavier job envelopes require additive lanes and explicit placement policy
  • define what qualifies a new additive lane for promotion or demotion

Exit signal:

  • the repo has one explicit answer for heavy Rust/Nix jobs
  • product language stops implying vertical autoscaling that does not exist

Phase 5: Publication Boundary And FlakeHub

Owner surface:

  • #215

Goal:

  • add FlakeHub only after the builder and publication contract is real enough to support it

Work:

  • define the clean-derivation gate
  • choose one candidate output family for first-class publication
  • keep GHCR as the concrete OCI publication path
  • keep Attic and Bazel as mutable acceleration layers
  • add FlakeHub only when the repo has a real durable publication workflow to point at

Exit signal:

  • FlakeHub is introduced as a real implemented publication or discovery path, not as aspirational copy

Sequencing

Recommended sequence:

  1. classify the owned-repo surface honestly
  2. close self-dogfood gaps in GloriousFlywheel
  3. normalize runner and workspace homogeneity in named dogfood repos
  4. benchmark and expand real Bazel, Nix, and Attic dogfood
  5. prove the scaling lane story under load
  6. only then broaden FlakeHub into primary product language

What We Should Say Publicly Right Now

Safe honest claim:

  • GloriousFlywheel operates self-hosted GitHub Actions runners on honey with live Attic and Bazel acceleration, and a growing set of owned repos already use those lanes

Unsafe claim:

  • all owned repos already run on a uniform GloriousFlywheel contract
  • FlakeHub is part of the default runtime or bootstrap path
  • self-scaling means memory-heavy jobs resize automatically

Near-Term Success Criteria

Within the next execution window, the program should aim to show:

  • named dogfood repos have no hidden hosted escape hatches on the primary proof paths
  • GloriousFlywheel default-branch CI contains a routine self-hosted proof lane
  • the top active owned repos use one recognizable runner-contract shape
  • explicit Nix bootstrap is normal rather than exceptional
  • measured benchmark evidence exists for at least:
    • one product repo
    • one Nix-heavy repo
    • one Bazel-oriented repo
  • FlakeHub is still described honestly as later publication and discovery work until the clean-derivation gate is implemented

Non-Goals

  • do not migrate all 236 owned repos at once
  • do not pretend homogeneity means one literal label for every workload
  • do not describe Attic or Bazel cache fill as publication
  • do not use FlakeHub to paper over missing bootstrap, cache, or scaling work
  • do not claim platform competitiveness without measured workload evidence

Recommendation

The immediate planning stance should be:

  • runner adoption is real enough to justify a broader migration program
  • homogeneity is still weak enough that the next work should emphasize contract cleanup over expansion marketing
  • Bazel, Nix, and Attic should be dogfooded through a small set of hard benchmarked canaries before widening to the long tail
  • FlakeHub should stay narrow and late
  • “self-scaling” should be described as horizontal autoscaling plus explicit heavy lanes, not as automatic per-job resizing

That is the shortest honest path from today’s platform reality to a product claim that can survive contact with live repos.

GloriousFlywheel