GloriousFlywheel Internal Platform Brief And Boundary Rules 2026-04-23
Snapshot date: 2026-04-23
Product Brief
GloriousFlywheel is Tinyland’s internal-first runner, cache, and control-plane platform.
Today it exists to give Tinyland a real, cache-first, self-hosted CI substrate with:
- GitHub-first runner execution
- Attic and Bazel acceleration
- local-first OpenTofu operations
- a dashboard and operator surface
- proven on-prem runner lanes on
honey
Its eventual public form, if one is published, should be a truthful FOSS cache-first, self-bootstrapping runner/cache/control-plane platform.
That public form does not exist yet.
Primary Users Right Now
- Tinyland operators who run and repair the platform
- Tinyland repo owners who consume the shared runner and cache contract
- internal product/platform planners deciding what should later become public
What GloriousFlywheel Is Not Yet
It is not yet:
- a clean public documentation set
- a settled public product surface
- a forge-neutral mutation authority surface
- a fully generated single-source-of-truth deployment/docs system
Non-Goals Right Now
Do not optimize for:
- public polish before internal contract clarity
- random doc cleanup without a contract decision
- tracker burn-down as a substitute for product definition
- compatibility-era overlay/Bzlmod stories as the lead identity
- public claims ahead of reproducible internal truth
Boundary Rules
Internal-only by default
These classes of material are internal and should not be part of a future public product surface by default:
- internal planning and evidence notes
- agent-execution and worker instruction material
- operator runbooks with live topology or host access details
- live private endpoints, tailnet names, private IPs, and SSH paths
- secrets-adjacent auth, proxy, or operator access implementation detail
Public-canonical only by explicit promotion
A document should be treated as future public-canonical only when it:
- describes the supported product or operator contract
- avoids live internal topology disclosure
- avoids internal planning/process detail
- is aligned to the internal live contract
- is written for reproducible external comprehension, not tribal context
Compatibility is bounded
Compatibility material may remain in the internal repo, but it should not lead the main product story.
That includes:
- overlay-era deployment flows
- legacy GitLab-first control or state assumptions
- compatibility consumer guidance that no longer defines the primary path
Source-Of-Truth Model
For this phase:
- this repo is the internal source of truth
- the internal live contract is defined here first
- any future public surface is extracted, generated, or intentionally rewritten later from that internal truth
Immediate Consequence
When there is tension between:
- public-looking docs cleanup
- compatibility preservation
- and internal contract clarity
choose internal contract clarity first.