GloriousFlywheel Builder Runtime Sprint Priorities 2026-04-16
Snapshot date: 2026-04-16
Purpose
Turn the newly clarified builder/runtime truths into a near-term sprint focus instead of leaving them scattered across longer research notes.
This note is intentionally biased toward:
- runtime truth before broader publication storytelling
- dogfood and downstream builder reliability before broader FlakeHub ambition
- explicit ownership for heavy-Nix rollout instead of hand-waving about autoscaling
Current Truth
These four statements are now the active baseline:
- FlakeHub is still publication/discovery later
- Nix bootstrap is still workflow-owned
- ARC still scales runner count horizontally
- memory-heavy Rust/Nix jobs should go to
tinyland-nix-heavy, not expecttinyland-nixto resize on demand
Near-Term Sprint Priorities
P0: Source Repo Default-Branch Proof Path
Owner surfaces:
#210#214
Why now:
- the source repo still relies on branch-gated
test-arc-runners.ymlfor its clearest self-hosted proof - until
mainvisibly provestinyland-docker,tinyland-nix, andtinyland-nix-heavy, downstream status will keep depending on canaries more than on source-of-truth dogfood
Sprint target:
- add one explicit default-branch platform-proof workflow
- reuse existing local contract primitives:
./.github/actions/docker-job./.github/actions/nix-job./.github/actions/setup-flywheel
- keep docs, release, image, and FlakeHub publication paths visibly hosted where that remains the honest boundary
Exit signal:
mainhas one ordinary proof workflow for:tinyland-dockertinyland-nixtinyland-nix-heavy
- no one has to cite
feat/arc-runnersto explain source-repo self-dogfood
P0: Heavy Nix Lane On honey
Owner surface:
#214
Why now:
- the repo now defines
tinyland-nix-heavyin additive ARC policy - until that lane is actually rolled out on
honey, the platform answer is still partly theoretical
Sprint target:
- apply the updated
arc-runnersstack onhoney - verify the
tinyland-nix-heavyscale set exists and registers cleanly - run at least one heavy Rust/Nix canary against that lane
- capture whether envelope alone is enough or whether placement policy is also required
Current execution read after live apply and runtime audit:
- live
honeyARC surface already includes:linux-xr-docker,personal-docker,personal-nix,tinyland-dind,tinyland-docker,tinyland-nix, andtinyland-nix-heavy - repo-owned heavy-Nix canary is now live:
tinyland-nix-heavy8CPU limit16Gimemory limitnodeSelector["kubernetes.io/hostname"] = "sting"- toleration for
dedicated.tinyland.dev/compute-expansion:NoSchedule
- repo-owned baseline runtime drift is now corrected:
- live
tinyland-nixnow usesATTIC_SERVER = http://attic.nix-cache.svc.cluster.local - live
tinyland-dockernow usesBAZEL_REMOTE_CACHE = grpc://bazel-cache.nix-cache.svc.cluster.local:9092
- live
- live cluster usage does not indicate a broad RAM shortage:
honeyis at roughly40%memory usagestingis at roughly6%memory usage
stingcurrently carriesdedicated.tinyland.dev/compute-expansion:NoSchedule, so it is not part of the default ARC scheduling surface unless a lane is designed for it- the local operator path now includes:
dev-policy.tfvarsdev.tfvarsdev-extra-runner-sets.tfvars
- the additive heavy lane is now explicitly modeled as
stingcompute- expansion capacity via:node_selector["kubernetes.io/hostname"] = "sting"- toleration for
dedicated.tinyland.dev/compute-expansion:NoSchedule
- listeners still remain on
honey, while the heavy runner lane itself now targetssting - remaining runtime drift is now narrower:
personal-nixstill usesATTIC_SERVER = http://attic-api.nix-cache.svc:8080personal-nixandpersonal-dockerare not repo-owned baseline lanes; they arejesssullivan/jesssullivan.github.ioscale sets usinggithub-personal-secret
- surviving legacy state is still partial for other stacks:
attic-devandarc-runners-devexist in archivedgf-overlay, whilerunner-dashboard-devandgitlab-runners-devdo not
Exit signal:
tinyland-nix-heavyis live onhoneytinyland-nix-heavyactually lands onstingas the explicit stateless compute-expansion node- repo-owned baseline runtime no longer depends on stale
attic-api.nix-cache.svc:8080 - first real heavy-lane canary is now published as
Jesssullivan/yt-text#67 - one real heavy Rust/Nix run still needs to complete on that lane to prove it under load
P0: Normalize Workflow-Owned Nix Bootstrap
Owner surfaces:
#210- local dogfood and shared-doc slices
Why now:
lab#73proved the current contract: self-hosted Nix lanes cannot assume Nix is already present- this must stop being a niche repo-specific fix and become a visible shared contract
Sprint target:
- keep pushing downstream repos toward either:
tinyland-inc/GloriousFlywheel/.github/actions/nix-job@main, or- explicit
DeterminateSystems/determinate-nix-action@v3before rawnix
- dogfood the same contract in GloriousFlywheel-facing workflows and examples
- make benchmark notes treat bootstrap time as its own measured phase
Exit signal:
- the common downstream examples all show explicit Nix bootstrap
- no public GF docs imply
tinyland-nixguarantees preinstalled Nix
P0: Shared JS And Bazel Template Contract V2
Owner surfaces:
#210#213
Why now:
- live repo inspection shows the real downstream contract debt is concentrated
in one reusable workflow:
tinyland-inc/ci-templates/.github/workflows/js-bazel-package.yml - current downstream reality is now clearer:
scheduling-kitalready has a verified repo-owned self-hosted package laneacuity-middlewarealready has a verified repo-owned self-hosted package lane plus hosted Modal deploytinyvectorsis the remaining hosted-template control case
- until the template makes runner intent and workspace intent explicit, downstream rollout will keep spreading hosted fallback and persistent workspace hygiene
Sprint target:
- introduce V2 inputs for:
- runner intent
- workspace intent
- publish authority intent
- integrate
setup-flywheelfor self-hosted modes - support isolated workspace behavior
- migrate pilot repos in order:
scheduling-kitacuity-middlewaretinyvectorsdecision lane
Exit signal:
- the shared template no longer depends on
clean: falsein the normal path - at least one dedicated-lane pilot and one hybrid pilot run cleanly on V2
- hosted template consumers are either promoted or left explicitly hosted
P0: Close Hosted Escape Hatches In Dogfood Repos
Owner surfaces:
#210- dogfood repo follow-on patches
Why now:
Jesssullivan/MassageIthacarun24561967515proved the repo-owned primary CI lane already uses dedicatedhoneylabels successfully- the actual blocker was narrower:
smoke-betaande2e-betastill pinubuntu-latestand were blocked by GitHub billing before any repo code ran - until dogfood beta validation can run on repo-owned runners, billing noise can still masquerade as platform instability
Sprint target:
- move repo-owned beta validation jobs toward the same repo-controlled runner label variable used by primary CI where feasible
- make browser/bootstrap assumptions explicit so Playwright jobs do not depend on GitHub-hosted image folklore
- keep GitHub-hosted fallback only as explicit compatibility or bounded external-authority exception, not as the primary dogfood proof
Exit signal:
- at least one repo-owned dogfood repo completes beta post-deploy validation without GitHub-hosted runners
- GitHub billing can no longer block the main dogfood proof path
- durable hosted policy exceptions such as docs or publication are no longer being confused with claim-breaking hosted product-proof drift
P1: FlakeHub Cleanup And Narrow RFC
Owner surface:
#215
Why now:
- FlakeHub still matters strategically
- but it should now be isolated to the right boundary: publication/discovery after builder bootstrap and runner-envelope design are already clear
Sprint target:
- clean remaining builder-facing wording that still risks implying FlakeHub is part of the active runtime contract
- define the narrow RFC as: post-bootstrap clean-derivation publication and discovery
- keep Attic and Bazel classified as acceleration layers, not publication
Exit signal:
- the repo has one clear FlakeHub owner lane
- public docs stop mixing FlakeHub into the runtime/bootstrap story
Sequence
Recommended sequence for the next sprint:
- finish heavy-lane validation on
honeywith a completed real canary - establish a source-repo default-branch proof path
- normalize workflow-owned Nix bootstrap in dogfood and downstream examples
- ship shared JS and Bazel template V2 and run the first pilots
- close GitHub-hosted beta escape hatches in repo-owned dogfood repos
- then tighten FlakeHub into a narrower publication/discovery RFC
Non-Goals
Do not treat these as near-term sprint promises:
- dynamic vertical pod resizing for ARC runner pods
- FlakeHub as the answer to Nix installation on self-hosted runners
- FlakeHub as the answer to memory-heavy Rust/Nix workloads
- broad publication rollout before the heavy-Nix lane and bootstrap boundary are stable