GloriousFlywheel Square One Platform Definition 2026-04-23

Snapshot date: 2026-04-23

Purpose

Reset the planning frame before more execution work happens.

Recent work usefully:

• moved the repo to internal visibility
• surfaced documentation and contract drift
• created an initial management scaffold in Linear

But that scaffold still started too close to cleanup and surface repair.

This note resets the program to square one:

• define what GloriousFlywheel is now
• define what it may become
• define what it is not yet
• define the planning questions that should govern the next phase

This is the current root planning note for the productization horizon. The narrower internalization and surface-inventory notes remain useful evidence, but they are subordinate to this framing.

For the short-form operating brief and boundary rules, use GloriousFlywheel Internal Platform Brief And Boundary Rules 2026-04-23. For the future public projection strategy, use GloriousFlywheel Future Public Projection Strategy 2026-04-23.

Current Truth

What exists today

GloriousFlywheel already exists as an internal platform for Tinyland:

• GitHub-first self-hosted Actions runners
• Attic and Bazel cache acceleration
• OpenTofu-managed deployment and operator tooling
• a dashboard and operator-plane surface
• a real on-prem honey substrate with multiple runner classes and proven cache-first dogfood paths

That is enough to call it a real internal platform.

What does not exist yet

GloriousFlywheel does not yet exist as a clean external product surface.

It is not yet:

• a singular public documentation set
• a singular internal live contract for endpoints, auth, state, cache, and consumer setup
• a cleanly bounded public FOSS platform story
• a forge-neutral mutation authority surface
• a fully generated source-of-truth deployment and docs system

What the repo is for now

The repo should be treated as:

• the internal source of truth for platform reality
• the internal operator and planning surface
• the place where the internal product contract is defined first

The future public surface should be extracted, generated, or intentionally rewritten later from that internal truth.

North Star

GloriousFlywheel should become:

a truthful, FOSS cache-first, self-bootstrapping runner/cache/control-plane platform whose internal contract is strong enough that a public projection can be published without leaking topology, planning artifacts, or aspirational claims.

More concretely:

• internal-first operator platform now
• reproducible, cache-first CI substrate first
• explicit runner, cache, auth, and state contracts
• honest compatibility boundaries
• future public surface only after internal truth is stable

Non-Goals Right Now

Do not optimize for these yet:

• public polish for its own sake
• reopening repo-wide GitHub tracker debt
• one-off doc cleanup without contract decisions
• presenting a managed-control-plane product before internal control authority is settled
• claiming full configuration generation or parity where only partial centralization exists
• letting compatibility-era overlay/Bzlmod flows drive the main story

Governing Prompt

Use this as the planning prompt for the next phase:

Define GloriousFlywheel as an internal platform first. Do not optimize for public polish, tracker burn-down, or incidental docs cleanup. Establish the internal product contract, operator model, consumer model, topology boundaries, cache/state/auth truth, and config authority first. Only then design the extracted public surface.

Planning Questions

Everything in the next phase should answer one of these questions.

1. What is GloriousFlywheel supposed to become?

This requires:

• internal product brief
• north star
• non-goals
• definition of success

2. What is internal-only versus eventual public product surface?

This requires:

• explicit boundary rules
• classification of operator, planning, compatibility, and canonical surfaces
• clear exclusion rules for live topology and internal planning artifacts

3. What is the minimum truthful internal contract?

This requires one source of truth for:

• endpoints
• auth methods
• state authority
• cache roles
• runner classes
• flake and direnv expectations
• downstream consumer setup modes

4. What repo and topology strategy are we actually pursuing?

This requires explicit decisions about:

• this repo as internal source of truth
• future extracted/generated public surface
• monorepo versus compatibility-kit responsibilities
• bzl-cross-repo versus primary repo ownership
• config parity and completeness strategy

5. How should the internal docs system be structured?

This requires distinguishing:

• internal product docs
• internal operator docs
• internal planning/evidence docs
• historical or compatibility archives

6. What does a future public platform surface actually contain?

This requires:

• supported product story
• supported onboarding
• supported auth and control boundaries
• supported compatibility story
• explicit non-goals

Program Shape

The planning program should run in this order.

Phase 1: North Star And Boundary Model

Define:

• internal platform identity
• non-goals
• public/internal boundary rules

Phase 2: Topology, Surface Inventory, And Config Strategy

Define:

• repo and compatibility roles
• surface classification
• configuration authority and generation limits

Phase 3: Internal Live Contract

Define:

• endpoints
• auth
• state authority
• cache roles
• onboarding and consumer setup

Then align the stale/conflicted docs to that contract.

Phase 4: Public Projection Strategy

Only after the above:

• define the future public docs/product surface
• define what is rewritten versus generated
• define what remains internal permanently

Linear Mapping

The existing productization horizon is still the right umbrella.

But the adjacent project and issue wording should reflect square one rather than cleanup-first execution.

Recommended active project framing:

• GloriousFlywheel Square One — Platform Definition and Boundaries

Recommended milestone framing:

1. North Star and Boundary Model
2. Topology, Surface Inventory, and Config Strategy
3. Internal Live Contract
4. Public Projection Strategy

Recommended issue framing:

• define north star, non-goals, and boundary rules
• map topology, repo strategy, config authority, and surface inventory
• define the internal live contract
• define the future public projection

Preserve But De-Emphasize

Do not discard the recent notes.

Keep these as supporting evidence:

• gloriousflywheel-internalization-and-public-surface-reset-2026-04-23.md
• gloriousflywheel-surface-inventory-and-classification-2026-04-23.md

But do not let them remain the primary program frame.

The primary frame is now:

• square one product definition first
• contract clarity second
• public projection third

Next Move

The next execution step after this reset should not be random doc cleanup.

It should be:

• update Linear to match this square-one framing
• then write the first explicit internal product brief and boundary note
• then move into the internal live contract bundle