GloriousFlywheel Downstream Adoption And Migration Kit 2026-04-16

GloriousFlywheel Downstream Adoption And Migration Kit 2026-04-16

Snapshot date: 2026-04-16

Purpose

Turn the direct-adoption research into an executable migration program for the owned repo surface.

Execution still needs to be phased, but the target policy is now broader than a small named tranche: all non-fork Jesssullivan and tinyland-inc repos should converge to GloriousFlywheel runners and cache surfaces unless an explicit exception is recorded.

GitHub owner: #210

First Execution Tranche

The operational first execution tranche remains 5 repos:

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

Current repo roles:

  • GloriousFlywheel: source-of-truth product and runner platform repo
  • blahaj: adjacent infra and cluster-ops consumer
  • lab: operator and MCP-adjacent tooling consumer
  • tinyland.dev: product-site and Nix workflow consumer
  • XoxdWM: named user-repo canary and legacy path consumer

This is not the full policy boundary. The broader direct usage inventory now lives in gloriousflywheel-downstream-adoption-inventory-matrix-2026-04-16.md, which tracks the literal-label surface, named variable-driven dogfood repos, and the larger owned-repo target set while keeping this first execution tranche separate from that broader program.

The tranche-1 repo-by-repo contract sheet now lives in gloriousflywheel-first-tranche-repo-contracts-2026-04-16.md.

The first repo-specific execution playbooks now live in:

  • 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-massageithaca-dogfood-playbook-2026-04-17.md

Tranche Goals

  1. inventory exactly how each repo consumes GloriousFlywheel today
  2. define a migration kit that lets those repos converge without manual archaeology
  3. separate “product contract” from “legacy compatibility” in downstream docs and examples
  4. use the first execution tranche to validate the migration kit before widening from named dogfood repos to the rest of the owned repo surface

Inventory Dimensions

Each downstream repo should be classified across these dimensions:

  • workflow labels in use
    • tinyland-docker
    • tinyland-nix
    • tinyland-dind
    • any legacy or private installation-specific labels
  • composite action references
    • tinyland-inc/GloriousFlywheel/.github/actions/...
    • Jesssullivan/GloriousFlywheel/.github/actions/...
  • cache assumptions
    • Attic only
    • Bazel only
    • Nix + Attic
    • Docker-only
  • secret and bootstrap assumptions
    • GitHub App only
    • GitLab compatibility
    • private kubeconfig or tailnet dependency
  • rollout criticality
    • blocks honey rollout
    • adjacent platform dependency
    • canary-only

Migration Kit Outputs

The first migration kit should produce:

  • a canonical label contract
    • what each shared runner label means
    • what is stable versus canary or additive
  • a canonical cache contract
    • what is auto-injected
    • what downstream repos may override
    • what remains compatibility-only
  • a canonical composite action reference surface
    • preferred action paths
    • deprecated paths
    • migration examples
  • a downstream secret/bootstrap checklist
    • GitHub-side prerequisites
    • optional GitLab compatibility prerequisites
    • rollout verification steps
  • a rollback note
    • how a downstream repo reverts to GitHub-hosted or a previous workflow shape if needed
  • one public downstream migration checklist
    • the first repo-facing version now lives in docs/runners/downstream-migration-checklist.md

Repo-By-Repo First Pass

GloriousFlywheel

  • role: source-of-truth and dogfood consumer
  • expected output:
    • self-consistent docs
    • no stale Jesssullivan/... action paths
    • no Bates-era environment examples

blahaj

  • role: adjacent infra consumer and strongest operational dependency
  • expected output:
    • explicit separation between cluster-ops ownership and runner-platform consumption
    • stable contract for any GloriousFlywheel labels or cache expectations used in blahaj workflows

lab

  • role: operator tooling and validation consumer
  • expected output:
    • clear statement of whether lab is a direct runner consumer, a cache consumer, or both
    • reduced stale cache/runtime relearning

tinyland.dev

  • role: representative product-repo consumer
  • expected output:
    • one clean GitHub Actions pattern using shared labels and the current cache contract

XoxdWM

  • role: user-repo canary and legacy-path cleanup target
  • expected output:
    • remove old Jesssullivan/GloriousFlywheel/.github/actions/... references
    • validate that one user-owned repo can consume the current public contract

Current Execution Status

Execution moved past inventory on 2026-04-16:

  • XoxdWM has a patched local clone in /tmp/XoxdWM
    • stable shared-runner jobs were detached from the repo-specific tinyland-inc/XoxdWM guard
    • cache-consuming workflows now use tinyland-inc/GloriousFlywheel/.github/actions/setup-flywheel@main
    • hardware-only flows remain compatibility-only
  • tinyland.dev has a patched local checkout in /tmp/tinyland.dev
    • public Nix cache reads now target https://nix-cache.tinyland.dev/main
    • self-hosted tinyland-nix builds use setup-flywheel
    • direct Attic push setup now follows the injected runtime endpoint
  • tinyland.dev container.yml and staging-deploy.yml remain separate by design in this first pass
  • lab has a patched local checkout in /tmp/lab
    • bazel-build.yml now sources tinyland-inc/GloriousFlywheel/.github/actions/setup-flywheel@main before using BAZEL_REMOTE_CACHE
    • the FlakeHub-oriented Nix workflows remain intentionally unchanged
  • blahaj has a patched local checkout in /tmp/blahaj
    • build-images.yml now explicitly marks image builds as the stable shared-runner lane
    • the OpenTofu/domain workflows remain classified as cluster-ops ownership, not the canonical downstream runner contract
  • GloriousFlywheel has an in-repo dogfood patch
    • .github/actions/nix-job/action.yml and .github/actions/docker-job/action.yml now point at the correct local setup-flywheel path
    • test-arc-runners.yml now validates the injected cache/runtime contract through setup-flywheel

That means #210 is now in selective execution mode, not inventory-only mode.

Published tranche-1 PR set:

  • XoxdWM: Jesssullivan/XoxdWM#28
  • tinyland.dev: tinyland-inc/tinyland.dev#136
  • lab: tinyland-inc/lab#72 (merged 2026-04-16 16:26:56Z)
  • blahaj: tinyland-inc/blahaj#68 (merged 2026-04-16 16:36:55Z)

Current PR triage:

  • lab#72 has already merged and now serves as the first completed tranche-1 canary
  • tinyland.dev#136 is the active next tranche-1 blocker; the lockfile refresh cleared Lint & Typecheck, but the PR surfaced a broader tinyland.dev monorepo issue where internal semver dependencies are being installed as local workspace links in Docker without a matching repo-wide package resolution/build-order contract
  • XoxdWM#28 is the strongest user-owned canary, but it touches 7 workflow files and is slightly broader than the org-owned canaries; its current block is self-hosted runner capacity, not a surfaced code failure
  • Jesssullivan/acuity-middleware#37 exposed a separate platform problem: stale read-only files in persistent honey-am-* runner workdirs can fail actions/checkout before downstream repo code runs; this now belongs to a GloriousFlywheel runner hygiene lane rather than another downstream repo patch
    • owner surface: #213
  • another downstream Rust-heavy CI signal exposed a runner-envelope problem: clippy was SIGKILLed on honey and only stabilized after workflow-level parallelism was capped; that now belongs to a GloriousFlywheel runner memory envelope and placement lane rather than being treated as a pure downstream lint problem
    • owner surface: #214
  • blahaj#68 has already merged as the branch-specific boundary patch on domain/tinyland.dev

Remaining merge order once tinyland.dev#136 is resolved or intentionally split:

  1. tinyland-inc/tinyland.dev#136
  2. Jesssullivan/XoxdWM#28

Acceptance Criteria

  • each of the first 5 repos has a written classification entry
  • at least one canonical migration example exists for:
    • label-only consumer
    • label + cache consumer
    • legacy action-path consumer
  • stale Jesssullivan/GloriousFlywheel action references are eliminated from the first tranche
  • downstream docs stop implying that every repo needs custom manual setup

Non-Goals

  • do not migrate all owned repos in one wave
  • do not use literal label search alone as the inventory boundary
  • do not leave repo-local exceptions implicit once the default policy is GloriousFlywheel runners plus cache surfaces

Suggested Follow-On Work

  1. turn the tranche-1 contract sheet into a public migration checklist
  2. patch the directly exposed downstream repos one by one
  3. decide which tranche-2 repos become named support canaries
  4. only then estimate the second adoption tranche

GloriousFlywheel