GloriousFlywheel First Tranche Repo Contracts 2026-04-16
Snapshot date: 2026-04-16
Purpose
Turn the #210 first migration tranche into an explicit repo-by-repo contract
sheet.
GitHub owner: #210
Scope
This note only covers the operational first migration tranche:
tinyland-inc/GloriousFlywheeltinyland-inc/blahajtinyland-inc/labtinyland-inc/tinyland.devJesssullivan/XoxdWM
It does not replace the broader direct-usage inventory. That broader surface
still lives in
gloriousflywheel-downstream-adoption-inventory-matrix-2026-04-16.md.
Evidence Basis
This sheet is grounded in:
- direct GitHub code-search counts and workflow-file inventories gathered on 2026-04-16
- local inspection of the current
GloriousFlywheelworkflows - repo roles already established in the planning surface
The exact per-label split for every downstream workflow was not fully resolved in this pass because GitHub code-search rate limits were hit mid-query. The current sheet is still sufficient to define migration order and contract shape.
Contract Table
| Repo | Workflow evidence | Current dependency shape | Contract to stabilize | First patch goal | Rollback path |
|---|---|---|---|---|---|
tinyland-inc/GloriousFlywheel |
4 workflow-file hits: build-image.yml, deploy-arc-runners.yml, mirror-images.yml, release.yml |
source-of-truth and dogfood repo; mostly GitHub-hosted release/image paths, with one live self-hosted ARC deploy compatibility path on tinyland-docker |
reference implementation for labels, cache defaults, release text, and operator docs | keep self-dogfood surfaces aligned with public contract; do not let self-reference drift reintroduce stale identity or private assumptions | GitHub-hosted workflow paths already exist for non-deploy jobs |
tinyland-inc/blahaj |
12 workflow-file hits across infra, image, DNS/domain, MCP, Tofu, and health flows |
strongest infra-adjacent shared-runner consumer; no direct composite-action dependency visible in code search | stable shared-label meaning, stable cache assumptions, no hidden public-management or alternate-cluster story | classify each workflow family by runner need and publish the cluster-ops vs runner-platform boundary explicitly | repo can fall back to GitHub-hosted runners per workflow if a shared label becomes unstable |
tinyland-inc/lab |
10 workflow-file hits across Bazel, Nix, deploy, validation, cache-warm, and runner-capacity benchmark flows |
strongest cache/builder/tooling consumer; likely the best downstream canary for cache and benchmark work | stable builder/cache contract, stable shared labels, explicit statement of what is runner consumption vs cache/MCP adjacency | turn lab into the benchmark and cache-contract canary instead of letting it re-learn stale runtime assumptions |
per-workflow fallback to GitHub-hosted or narrower shared labels if benchmark lanes are not ready |
tinyland-inc/tinyland.dev |
4 workflow-file hits: bazel.yml, container.yml, nix.yml, staging-deploy.yml |
cleanest representative org product-repo consumer; no direct composite-action dependency visible in code search | one canonical GitHub Actions consumer pattern for product repos using shared labels and current cache/publication contract | publish and validate the “reference downstream repo” story here before widening to tranche 2 | GitHub-hosted runners remain the obvious temporary fallback for product workflows |
Jesssullivan/XoxdWM |
8 workflow-file hits across cache, packaging, multi-arch, native deps, runner-health, and self-hosted fast paths |
strongest user-owned canary; visible downstream use of tinyland-inc/GloriousFlywheel/... workflow/action path |
prove the public downstream contract works for a user repo, not just org repos; remove brittle direct-path assumptions over time | patch the visible direct action-path dependency first and validate one clean public consumption pattern | user repo can revert to GitHub-hosted or keep a narrow self-hosted fast path while migration settles |
Repo-Specific Read
GloriousFlywheel
- This repo is not just a downstream consumer. It is the reference contract.
- Its job in tranche 1 is to stop lying about the product surface.
- The main risk is not adoption failure; it is self-dogfood drift causing bad examples to leak downstream.
blahaj
blahajis the strongest operational dependency because it sits closest to cluster and infra workflows.- It should not become the place where GloriousFlywheel-specific assumptions are rediscovered ad hoc.
- The contract here is boundary clarity: what belongs to cluster ops, what belongs to shared runners, and what belongs to shared cache/runtime policy.
lab
labis the strongest canary for cache and builder behavior.- It is the right place to validate whether the shared runner contract actually helps operator and tooling workflows instead of just product repo CI.
#212should treatlabas a named benchmark workload source, not a generic downstream repo.
tinyland.dev
tinyland.devis the cleanest representative product repo in the first tranche.- If the repo wants one public example of “how a downstream product repo uses GloriousFlywheel,” this is the best target.
- The goal is a canonical example, not bespoke platform archaeology.
XoxdWM
XoxdWMis the best user-owned canary because it is visibly downstream of the current action surface.- If the public contract works here, the story for user-owned repos becomes much more credible.
- If it fails here, the platform is still too org-internal.
Patch Order
Recommended order under #210:
XoxdWM- remove or harden the visible direct action-path dependency
- validate one clean public downstream pattern
tinyland.dev- publish one canonical org product-repo usage pattern
lab- lock cache/builder expectations and benchmark role
blahaj- separate cluster-ops ownership from shared runner contract
GloriousFlywheel- keep source-of-truth docs and examples aligned with what the other four repos actually need
Current Execution Status
Current downstream execution state on 2026-04-16:
XoxdWM- local clone patched in
/tmp/XoxdWM - stable shared
tinyland-nixjobs no longer depend ongithub.repository == 'tinyland-inc/XoxdWM' - stable cache workflows now use
tinyland-inc/GloriousFlywheel/.github/actions/setup-flywheel@main - hardware-only compatibility jobs remain intentionally unchanged
- local clone patched in
tinyland.dev- real local checkout patched at
/tmp/tinyland.dev .github/workflows/nix.ymlno longer uses stale fuzzy-dev cache coordinatescontainer.ymlandstaging-deploy.ymlremain explicitly out of scope for the first runner-contract proof
- real local checkout patched at
lab,blahaj, andGloriousFlywheellabnow has a patched local checkout at/tmp/lab.github/workflows/bazel-build.ymlnow sourcestinyland-inc/GloriousFlywheel/.github/actions/setup-flywheel@mainbefore usingBAZEL_REMOTE_CACHEblahajnow has a patched local checkout at/tmp/blahaj.github/workflows/build-images.ymlnow explicitly marks image builds as the stable shared-runner lane and keeps OpenTofu/domain workflows classified as cluster-ops ownership
GloriousFlywheelnow has an in-repo dogfood patch.github/actions/nix-job/action.ymland.github/actions/docker-job/action.ymlnow point at the correct local./.github/actions/setup-flywheelpath.github/workflows/test-arc-runners.ymlnow dogfoods the setup action instead of only probing raw cache endpoints
Published tranche-1 PR set on 2026-04-16:
Jesssullivan/XoxdWM#28tinyland-inc/tinyland.dev#136tinyland-inc/lab#72(merged 2026-04-16 16:26:56Z)tinyland-inc/blahaj#68(merged 2026-04-16 16:36:55Z)
Current live order:
tinyland-inc/tinyland.dev#136Jesssullivan/XoxdWM#28
Triage note:
tinyland-inc/tinyland.dev#136is the active next blocker; the runner contract patch is in place, but the PR surfaced a repo-level internal workspace package-resolution/build-order issue in the container laneJesssullivan/XoxdWM#28is currently blocked by self-hosted runner capacity, not by a surfaced code failureblahaj#68is complete and merged ondomain/tinyland.dev, which matched the active branch reality in the local checkout and remote branch surface
Acceptance Criteria
- each tranche-1 repo has a named contract and first patch goal
XoxdWMis no longer the only visible downstream action-path canary without a written migration plantinyland.devbecomes the reference org product-repo examplelabis explicitly classified as cache/builder canaryblahajis explicitly classified as infra-adjacent consumer, not an undifferentiated downstream repo
Related Notes
- gloriousflywheel-downstream-adoption-and-migration-kit-2026-04-16.md
- gloriousflywheel-downstream-adoption-inventory-matrix-2026-04-16.md
- gloriousflywheel-xoxdwm-first-patch-playbook-2026-04-16.md
- gloriousflywheel-tinyland-dev-first-patch-playbook-2026-04-16.md
- gloriousflywheel-lab-first-patch-playbook-2026-04-16.md
- gloriousflywheel-blahaj-first-patch-playbook-2026-04-16.md
- gloriousflywheel-dogfood-first-patch-playbook-2026-04-16.md
- gloriousflywheel-program-surface-2026-04-15.md