GloriousFlywheel Active Owned Repo Adoption Board 2026-04-17

GloriousFlywheel Active Owned Repo Adoption Board 2026-04-17

Snapshot date: 2026-04-17

Purpose

Turn the broad adoption plan into a concrete active-repo board.

This note is the Phase 0 execution board for the current owned-repo surface:

  • which active repos already show GloriousFlywheel runner or cache adoption
  • which repos are the real dogfood blockers
  • which repos are merely adjacent and should not steal focus

Companion notes:

Evidence Basis

This board is grounded in:

  • current visible gh repo list activity for non-fork repos in tinyland-inc and Jesssullivan
  • live workflow adoption evidence gathered on 2026-04-17
  • existing dogfood, benchmark, and downstream-adoption notes already in this repo

Important limitation:

  • GitHub code-search rate limits hit during the broader cache census
  • runner-label evidence is stronger than cache-specific evidence for the full active set
  • where cache or FlakeHub posture is not yet directly proven, the board says so explicitly instead of inferring too much

Triage Classes

dogfood-blocker

Use this when the repo directly affects whether GloriousFlywheel can make an honest product claim right now.

Typical reasons:

  • source-of-truth repo drift
  • named product dogfood lane
  • benchmark canary
  • platform bug surfaced by a real consumer

active-consumer

Use this when the repo is a real runner or cache consumer but not the next place where platform truth is blocked.

adjacent-surface

Use this when the repo shapes templates, publication, or platform adjacency without being the highest-value runner-contract proof point itself.

hold

Use this when the repo is active but there is not yet enough evidence that it should be in the near-term GloriousFlywheel migration queue.

Active Board

Repo Active role Current GF evidence Triage class Near-term action
tinyland-inc/GloriousFlywheel source-of-truth platform repo mixed hosted and self-hosted CI on default branch; strongest ARC test flow still branch-gated; live self-dogfood exists but is not the routine proof path dogfood-blocker move normal runner-contract proof onto default-branch CI and stop letting source-of-truth drift hide behind hosted checks
Jesssullivan/MassageIthaca named product dogfood repo repo-owned PRIMARY_LINUX_RUNNER_LABELS_JSON lane for core CI; beta and alpha post-deploy jobs were the hosted escape hatch dogfood-blocker land and verify the self-hosted beta-validation PR path; use this repo as the proof that product repos do not need hosted escape hatches
tinyland-inc/lab cache and builder canary explicit tinyland-nix runner use, setup-flywheel in Bazel builds, and live FlakeHub cache and publish actions in the Nix workflow dogfood-blocker treat lab as the first benchmark and cache-contract canary, and define one canonical path instead of treating every lane as equally authoritative
tinyland-inc/tinyland.dev representative org product repo mixed truth: Bazel CI and staging deploy are still on ubuntu-latest, while the heavy Nix build path runs on tinyland-nix and pushes to Attic dogfood-blocker decide whether this repo is supposed to prove GloriousFlywheel runners or just GloriousFlywheel caches, then align the authoritative CI path with that answer
Jesssullivan/XoxdWM strongest user-owned public canary explicit tinyland-* labels and visible setup-flywheel usage; still mixes stable shared lanes with hardware and compatibility flows dogfood-blocker finish normalizing the shared fast path and keep hardware-only jobs clearly outside the public contract
tinyland-inc/blahaj infra-adjacent operational dependency real shared-runner usage exists on tinyland-docker and tinyland-dind, but large parts of the repo are cluster-ops or hosted utility flows rather than a clean downstream contract dogfood-blocker keep clarifying cluster-ops ownership versus stable shared-runner consumption and stop treating the repo as one homogeneous dogfood surface
Jesssullivan/acuity-middleware active product-adjacent consumer that surfaced platform defects package CI and publish already use a verified repo-specific self-hosted lane through the shared template, while Modal deploy remains explicitly hosted dogfood-blocker treat this repo as proof for workspace and checkout hygiene work in ci-templates and the runner envelope, then decide whether hosted deploy is a durable exception
Jesssullivan/yt-text heavy Nix dogfood canary core CI runs on shared self-hosted Nix labels, but docs deploy stays GitHub-hosted and cache/bootstrap assumptions are still mostly implicit in runner state dogfood-blocker use it to prove heavy-Nix lane value under measured load and make the lane contract explicit in workflow code
tinyland-inc/tinyvectors active org consumer shared JS and Bazel package template is in use, but workflow code does not pass runner labels, so current behavior is hosted unless repo variables override it active-consumer verify actual repo-variable use before counting this repo toward runner adoption and otherwise treat it as a hosted template consumer
tinyland-inc/betterkvm active org consumer current default-branch CI is still fully ubuntu-latest; it consumes Nix and Attic today, but not GloriousFlywheel runners yet active-consumer classify it as a hosted cache consumer for now and schedule explicit tinyland-nix adoption before counting it toward runner penetration
Jesssullivan/scheduling-kit active platform-adjacent product repo CI and publish use a verified repo-specific self-hosted lane through the shared JS and Bazel template, but that template is still cleanup-based and hosted-fallback capable active-consumer use it as the first clean pilot for js-bazel-package V2 and promote it from repo-variable indirection into an explicit documented dedicated-lane contract
Jesssullivan/tinyclaw active user consumer inspected build, PR, GHCR, release, and Nix flows are all GitHub-hosted today; it is active, but not a GloriousFlywheel runner consumer on main active-consumer keep it out of runner-adoption claims until a real self-hosted or cache-contract lane lands
Jesssullivan/remote-juggler active user consumer strong Nix and Attic usage is real, but the inspected default-branch CI and release paths are still GitHub-hosted rather than GloriousFlywheel-hosted active-consumer separate cache-consumer status from runner-consumer status and only promote it once a real default-branch self-hosted lane exists
Jesssullivan/tummycrypt cache-adjacent active repo strong hosted Nix and Attic usage is real, but the inspected default-branch surfaces are GitHub-hosted rather than GloriousFlywheel-hosted active-consumer keep it in the cache-contract wave and only promote it into runner-adoption metrics after self-hosted default-branch use is real
tinyland-inc/ci-templates reusable CI template surface recent active repo; adjacency is strong because it can encode or spread runner and cache patterns adjacent-surface align templates with GloriousFlywheel contract after the contract itself is stable enough to template
tinyland-inc/.github org-level policy and default automation surface active org-level repo, but not a direct runner proof point in current evidence adjacent-surface use it later for policy rollout after runner-contract language is settled
tinyland-inc/bazel-registry Bazel ecosystem adjacency active and strategically relevant, but not yet a named runner-contract or dogfood repo in current evidence adjacent-surface keep it out of the first migration wave and revisit once Bazel dogfood is benchmarked more clearly
Jesssullivan/jesssullivan.github.io personal lane consumer, not repo-owned baseline current notes explicitly say personal-nix and personal-docker are not repo-owned baseline lanes adjacent-surface keep separate from the baseline product claim and avoid letting personal-lane policy pollute the public contract
tinyland-inc/FinanceBro active internal repo currently active by push date, but no strong runner or cache evidence in the current GloriousFlywheel notes hold verify workflow shape before pulling it into the migration queue
Jesssullivan/tinyland-reorg active private repo active by push date, but no current runner-contract evidence in the active notes hold leave out of the near-term queue until there is explicit platform relevance

Current Waves

Wave 0: Dogfood Blockers

These repos should drive the next execution window:

  • GloriousFlywheel
  • MassageIthaca
  • lab
  • tinyland.dev
  • XoxdWM
  • blahaj
  • acuity-middleware
  • yt-text

Reason:

  • together they cover source-of-truth drift, product dogfood, user canaries, builder/cache proof, infra-adjacent consumption, workspace hygiene, and heavy-Nix scaling truth

Wave 1: Active Consumers

Move here after Wave 0 is cleaner:

  • tinyvectors
  • betterkvm
  • scheduling-kit
  • tinyclaw
  • remote-juggler
  • tummycrypt

Reason:

  • these repos appear active and relevant, but they do not currently define the credibility of the platform claim

Wave 2: Adjacent Surfaces

Do not let these repos lead the migration narrative:

  • ci-templates
  • .github
  • bazel-registry
  • jesssullivan.github.io

Reason:

  • they shape policy, packaging, or future builder/publication surfaces
  • they should consume the contract after the contract is more stable

Immediate Outputs Needed

1. Repo Classification Matrix

For Wave 0 and Wave 1, add one row per repo covering:

  • runner pattern
  • workspace pattern
  • Nix bootstrap mode
  • Attic expectations
  • Bazel expectations
  • hosted escape hatches
  • rollback path

The first working version now lives in:

2. Benchmark Pack Mapping

The first measured pack should use:

  • GloriousFlywheel
  • lab
  • tinyland.dev
  • XoxdWM
  • yt-text
  • MassageIthaca for product-repo post-deploy truth

3. Exception Register

Track every current exception explicitly:

  • hosted jobs on dogfood repos
  • raw [self-hosted, ...] selectors outside documented hardware cases
  • personal lanes mistaken for baseline product lanes

Success Criteria

  • the near-term queue is no longer “all active repos”
  • Wave 0 repos each have one named blocker or proof obligation
  • the platform can explain why a repo is in dogfood-blocker, active-consumer, adjacent-surface, or hold
  • the next migration wave can be driven by evidence rather than by whichever repo was edited most recently

Recommendation

The next work should stay concentrated on Wave 0 until all of these are true:

  • GloriousFlywheel default-branch CI contains routine self-hosted proof
  • MassageIthaca no longer depends on hosted beta validation
  • lab and yt-text provide real cache and heavy-Nix benchmark evidence
  • XoxdWM is a clean public user-repo contract example
  • acuity-middleware checkout hygiene work is closed at the platform layer

Only then should Wave 1 become the default execution lane.

GloriousFlywheel