GloriousFlywheel Productization Horizon

Correction on 2026-04-24: This note remains useful as next-horizon product context, but it is not the current execution surface. The pooled-substrate dogfood reset takes precedence over the broader productization horizon until the reset is complete. Read this note as later-horizon planning, not as today’s active route.

Date: 2026-04-22

Why This Exists

GloriousFlywheel is now real enough on the GitHub + honey path that the next question is no longer only cleanup.

The broader question is productization:

• how cache-first, verify-later becomes a real owned-repo contract instead of mostly substrate posture
• how heavier runner classes become honest product surfaces instead of undifferentiated ambition
• how Attic, Bazel remote cache, and FlakeHub get explicit roles
• how multi-org, user-owned, and future multi-forge claims are gated by proof instead of by template reuse alone

This note is the supporting planning surface for:

• GitHub #320
• GitHub #322
• Linear TIN-335
• Linear TIN-336
• Linear initiative GloriousFlywheel Productization Horizon (May–Aug 2026)
• Linear project GloriousFlywheel Productization — Cache-First Dogfood and Advanced Runners

North Star

By the end of this horizon, GloriousFlywheel should be able to say:

• cache-first, verify-later is dogfooded on the repos that matter most, not only inside the platform substrate
• the advanced runner-class story is ordered and proved: KVM first, then GPU/WebGPU/Dawn, then any rarer or costlier lanes
• Attic, Bazel cache, and FlakeHub have explicit non-overlapping product roles
• GitHub-first remains the honest primary control plane
• any broader user, org, or forge claims are backed by repeatable operator patterns and runtime proof

Non-Negotiable Boundaries

These remain fixed while productization expands:

• honey stays the real on-prem baseline
• GitHub stays the primary forge surface
• Attic and Bazel are acceleration layers first
• FlakeHub is publication and discovery work, not runtime bootstrap
• runner classes should only be described as real after they have a named proof surface
• broader VCS-agnostic language should follow runtime proof, not precede it

Primary Workstreams

1. Cache-First Bazel Dogfood

Make cache-first Bazel behavior a first-class owned-repo contract.

This means:

• name the first authoritative Bazel dogfood tranche
• define what counts as success: cache use, runtime speedup, fallback behavior, and repeatable owned-repo use
• stop treating optional Bazel cache availability as equivalent to productized Bazel dogfood

The first explicit execution slice is #322 / TIN-336.

Tranche 1 repos:

• GloriousFlywheel itself
• tinyland-inc/lab
• tinyland.dev
• Jesssullivan/scheduling-kit
• Jesssullivan/acuity-middleware

Adjacent but not tranche 1:

• Jesssullivan/cmux
• tinyland-inc/bazel-registry
• Jesssullivan/nix-vm-test
• rockies
• linux-xr

2. Advanced Runner Proof Matrix

Treat runner classes as an ordered proof matrix, not one broad bucket.

Order:

1. KVM execution substrate
2. GPU/WebGPU/Dawn
3. macOS release and runtime surfaces
4. riscv and other rarer execution classes
5. broader multi-forge or parity claims only after the above have real proof

Current state:

• KVM is the first real adjacent productization lane
• GPU/WebGPU/Dawn is still largely represented by backlog and documentation
• macOS and riscv are strategically relevant but not current GloriousFlywheel product surfaces

3. Publication And Builder Surface Boundaries

Keep these roles explicit:

• Attic: mutable Nix acceleration and binary-cache substrate
• Bazel remote cache: mutable action/CAS acceleration
• FlakeHub: post-bootstrap publication and discovery only when derivation and release authority are genuinely clear

Productization should reduce fuzzy language here, not add more of it.

4. Multi-Org, User, And Forge Claims

Broader claims should be earned in this order:

• org-owned GitHub repos with repeatable runner enrollment
• user-owned GitHub repos with explicit, honest boundaries
• future Forgejo / GitLab / Woodpecker or VCS-agnostic claims only after there is a repeatable operator pattern, not just one disposable proof

Suggested Sequencing

Phase A: May 2026

• finish narrowing the current month-scale hardening lanes
• make the first cache-first Bazel dogfood tranche explicit and public through #322 / TIN-336
• keep the source-repo Bazel proof package explicit and green on main as the first tranche-1 execution proof
• move next to lab for benchmark and cache-evidence truth instead of pretending tranche-1 is already broadly proved
• keep KVM execution substrate work attached to Jesssullivan/nix-vm-test and rockies truth surfaces

Phase B: June 2026

• move from KVM substrate proof toward broader heavy execution truth
• define the first GPU/WebGPU/Dawn proof surface and operator boundary
• tighten the Attic/Bazel/FlakeHub product contract in public docs

Phase C: July–August 2026

• revisit user and multi-org parity from actual rollout evidence
• revisit broader forge claims only if GitHub-first proof is materially stronger
• decide which runner classes are real product surfaces versus still-adjacent research

Success Metrics

The board should push toward visible proof, not only more docs.

Examples:

• named first-tranche repos with cache-first Bazel proof
• explicit runner-class matrix with proved, experimental, and backlog states
• at least one real heavy execution path beyond KVM substrate proof
• clear public wording for Attic vs Bazel cache vs FlakeHub
• fewer “optional” or “adjacent” claims in the primary product surface

What This Should Not Become

This should not become:

• a reopening of already-settled month-1 cleanup decisions
• a generic ambition list for every possible runner class
• a claim that GloriousFlywheel is already VCS-agnostic or multi-runner-class mature
• an excuse to blur the difference between acceleration, publication, and operator control

The point is to make the next growth phase explicit and honest.