Cleanup Program

Cleanup Program

This page turns the current GloriousFlywheel cleanup and convergence work into one explicit program.

Use this page when the question is not “what is GloriousFlywheel?” but “what still needs to be reconciled, in what order, and under which boundaries?”

Snapshot date: 2026-04-20

Purpose

The repo is past foundational truthing and the completed longevity sprint:

  • the major sprint execution slices have landed
  • honey is the real on-prem baseline
  • the next month is now focused on four follow-on hardening and expansion lanes

This program exists to keep that work structured instead of letting it drift back into one large mixed lane.

Non-Negotiable Boundaries

These are already settled for the current cleanup cycle:

  • honey is the only physical cluster target
  • bumble is the durable-state node inside honey
  • sting is the stateless compute-expansion node inside honey
  • GitHub is the primary forge surface
  • GitLab and Codeberg are compatibility surfaces, not equal-maturity control planes
  • Nix bootstrap on self-hosted Nix runners is workflow-owned
  • ARC scales runner count horizontally, not one runner pod’s memory envelope
  • heavy Rust and Nix workloads belong on tinyland-nix-heavy
  • Attic and Bazel are acceleration layers, not publication surfaces
  • FlakeHub is post-bootstrap publication and discovery work, not runtime or bootstrap

Cleanup work should not reopen those decisions casually.

Recently Completed

Workstream 1: Backend Authority To Environment-Owned S3 State

Owner issues:

  • #276
  • TIN-278

Focus:

  • migrate backend authority away from transitional HTTP
  • lock the active stacks onto the now-proven environment-owned S3-compatible backend path on honey
  • update operator docs and env-var docs so the new authority contract is primary

Done means:

  • transitional HTTP is no longer the active backend authority surface
  • one S3-compatible state path is the canonical authority
  • primary docs and validation surfaces agree on that contract

Active Workstreams

Workstream 2: Broader Downstream Rollout

Owner issues:

  • #277
  • TIN-279

Focus:

  • move beyond tranche-1 canary proof into a wider rollout set
  • turn the landed adoption evidence into a repeatable migration path
  • keep repo-owned, user-owned, and hosted-exception boundaries honest as the rollout widens

Done means:

  • the next rollout tranche is explicitly named and validated
  • migration guidance is repeatable beyond the first canary set
  • canonical docs describe more than tranche-1 proof

Workstream 3: Dashboard Control-Plane Debt Reduction

Status: completed via #278 / TIN-280

Owner issues:

  • #278
  • TIN-280

Focus:

  • clarify dashboard read and mutation authority
  • reduce remaining GitLab-shaped or compatibility-only control-plane assumptions
  • align dashboard docs, API surfaces, and operator expectations

Done means:

  • dashboard control authority is explicit and internally consistent
  • compatibility-only paths are isolated, retired, or documented as such
  • the surface is a cleaner base for later automation work

Workstream 4: Runner Hygiene And Orgwide Enrollment Automation

Owner issues:

  • #279
  • TIN-281

Focus:

  • automate the honey runner hygiene loop beyond manual remediation
  • tighten orgwide enrollment reporting and promotion rules
  • reduce the gap between recent repo activity and real runner enrollment

Done means:

  • runner hygiene no longer depends mainly on operator-driven repair
  • enrollment reporting and automation are materially stronger than the current reality-check baseline
  • canonical docs and runbooks reflect automated lifecycle management

Sequence

The intended order is:

  1. migrate backend authority and harden runner/enrollment automation first
  2. broaden downstream rollout in parallel once those contracts are clearer
  3. reduce dashboard control-plane debt without reopening settled runtime facts
  4. keep longer-tail backlog lanes visible, but outside this active month-scale execution board

This is a sequence, not a claim that only one issue can move at a time.

Merge Discipline

Future cleanup work should follow these rules:

  • one PR should correspond to one workstream or one narrow sub-slice
  • every runtime-affecting PR should state the live proof surface or missing proof surface
  • public docs should be updated alongside runtime or contract changes when the user-facing story changes
  • research notes should support the canonical docs, not replace them

Where To Look Next

GloriousFlywheel