Historical - GloriousFlywheel Runner Platform Reset 2026-04-15

Historical - GloriousFlywheel Runner Platform Reset 2026-04-15

Snapshot date: 2026-04-15

Status

Historical grounding note.

This document captures the initial reset framing from 2026-04-15. It is still useful background, but it is not an active control-plane note anymore.

Use these notes first for current execution:

Purpose

Reset GloriousFlywheel planning around current repo and runtime truth.

The repo is no longer just an attic-iac or Civo-era cache experiment. It is already acting as part of a broader Tinyland runner and CI/CD substrate, but its docs, defaults, planning objects, and some active branches still describe an older operating model.

This document is the grounding artifact for the next milestone and initiative.

Current Truth

Repo and planning surface

  • local checkout: tinyland-inc/GloriousFlywheel
  • local branch: feat/honey-arc-runner
  • GitHub repo description still says: Recursive IaC flywheel infrastructure system — Nix, Bazel, Civo K8s, Attic cache
  • GitHub has one open PR and four open issues as of 2026-04-15
  • GitHub milestones exist only as closed March 2026 sprint buckets
  • Linear has no GloriousFlywheel-specific initiative, project, or document yet

Current runtime direction from adjacent repo truth

From the current blahaj operating docs dated 2026-04-13 and 2026-04-14:

  • honey is the live control plane and state anchor
  • bumble is the staged worker and bulk-storage node
  • sting is joined and policy-contained
  • tailnet-first management is the intended operator default
  • Civo is transitional edge or failover infrastructure, not the center
  • Liqo is removed from the current operating model

Repo drift against that runtime

The repo still carries major older assumptions:

  • README.md, CONTRIBUTING.md, MODULE.bazel, flake.nix, Justfile, and multiple docs still describe attic-iac
  • overlay and GitLab-first framing still dominate the public architecture docs
  • several stacks and workflows still assume GitLab HTTP state and GitLab PAT flow
  • default cache endpoints still reference nix-cache.fuzzy-dev.tinyland.dev
  • docs still over-index on Civo and pre-migration cache conventions

GitHub reality anchor

GitHub issue #167, opened on 2026-04-15, is the sharpest current cache and state truth anchor:

  • current public Attic HTTP target should be https://nix-cache.tinyland.dev
  • private Bazel gRPC target is bazel-cache-grpc.taila4c78d.ts.net:9092
  • public Bazel HTTP still has edge-routing problems
  • repo defaults still point at stale fuzzy-dev endpoints
  • current comment on the issue states the live cache stack is not actually HA
  • current comment also states RustFS-backed Tofu state should be treated as an explicit follow-through item, not an already-finished migration

Adjacent repo dependence

  • linux-xr already treats GloriousFlywheel as active CI infrastructure and builds on tinyland-docker ARC runners
  • blahaj still documents GloriousFlywheel as a runner and cache substrate, but that mapping still carries transitional Civo language
  • cmux is not a direct infrastructure dependency, but it is relevant to the operator UX and multi-agent workflow story that the product still lacks

Main Gaps

1. Identity drift

The repo is named GloriousFlywheel, but core public docs and metadata still describe attic-iac, attic-cache, or overlay-upstream-first semantics.

This weakens every planning conversation because the product appears smaller and older than the actual execution surface.

2. Cache and state drift

The codebase still mixes:

  • old fuzzy-dev endpoints
  • GitLab HTTP backend assumptions
  • partially migrated RustFS/S3 state intent
  • Attic-first language that does not clearly distinguish Attic, Bazel cache, FlakeHub, and RustFS roles

This is the highest-value truthing lane because it directly affects downstream consumer configuration.

3. Runner topology drift

PR #166 proposed honey-nix ARC scheduling through Liqo virtual nodes, but that PR was closed on 2026-04-15.

That is materially out of sync with the current blahaj operating truth, which explicitly says Liqo is removed from the present model. The runner topology needs a local-first, post-Liqo design before more branch work piles onto older assumptions.

4. Bazel, Nix, and builder-contract drift

Bzlmod and Nix are present, but they are not yet presented as a coherent first-class product contract.

Related gaps:

  • stale module naming
  • stale flake metadata
  • no clear Linux builder contract for linux-xr
  • no explicit clean derivation or artifact-authority story across caches, builders, and downstream consumers

5. Tailnet and deployment drift

The repo already contains Tailscale-aware dashboard and proxy surfaces, but the docs do not yet present tailnet-first operator access as part of the main GloriousFlywheel story.

Likewise, there is no clean current statement of how this repo should deploy into the ../blahaj local cluster and RustFS-backed environment.

6. Planning drift

GitHub and Linear are both missing the current program shape:

  • GitHub milestones stopped at Sprint 5 and reflect March planning
  • Linear has broad Infrastructure work, but no GloriousFlywheel-specific initiative or project for the runner platform reset
  • there is no current user-story or storyboard artifact for the operator, org-admin, or repo-consumer experience

Assets Worth Preserving

  • ARC runner labels and baseline topology: tinyland-nix, tinyland-docker, tinyland-dind
  • runner dashboard work, especially the Tailscale-aware proxy/auth surface
  • RustFS module and related backend work, but only if reclassified as incomplete and truthfully documented
  • GitHub issue #167 as the current cache-default migration anchor
  • linux-xr as a concrete high-value Linux builder consumer and canary
  • existing MinIO and RustFS work as input into a clearer storage and cache contract rather than more one-off substrate growth

Proposed Program Structure

Linear initiative

GloriousFlywheel Runner Platform Reset

Intent:

  • move from partially functional Civo-era MVP framing to a local-first, tailnet-first, multi-org FOSS runner platform
  • make repo, runtime, and planning truth agree again

Linear project

GloriousFlywheel: Truthing, Runners, and CI/CD Reset

Suggested summary:

Truth and substrate reset for GloriousFlywheel: repo identity, cache/state contracts, runner topology, builder capacity, and local-first deployment.

Linear milestone sequence

  1. M1: Truthing and Identity Reset
  2. M2: Cache, FlakeHub, and State Convergence
  3. M3: Runner Substrate and Builder Contracts
  4. M4: Local-First Deployment and Tailnet Operations
  5. M5: UX, Storyboarding, and FOSS Product Surface

GitHub milestone

Milestone 6: Truthing, Cache/State Realignment, Runner Platform Reset

This should replace the stale Sprint 1-5 planning sequence as the active public execution bucket.

First Workstreams

Workstream A: Repo identity and documentation truth

  • remove stale attic-iac naming from the primary public surfaces
  • stop presenting overlay and GitLab-first flow as the dominant product story
  • rewrite the top-level story around runner platform, cache platform, and local-first deployment

Workstream B: Cache, FlakeHub, and state contract

  • close GitHub issue #167
  • replace stale fuzzy-dev defaults
  • document Attic vs FlakeHub roles explicitly
  • document Bazel HTTP vs private gRPC boundary explicitly
  • verify whether RustFS-backed tofu-state is real runtime or only intended design
  • document present HA limits honestly

Workstream C: Runner topology and capacity

  • carry the post-Liqo topology decision through issue #170
  • define the post-Liqo local-first runner placement model
  • define multi-org and org-plus-user ARC enrollment model
  • define scale-up and scale-down lifecycle ownership for runner pools

Workstream D: Bazel, Nix, and builder authority

  • make the Bzlmod and Nix surface name and metadata truthful
  • define builder classes and their responsibilities
  • explicitly support linux-xr as the Linux builder CI canary
  • define clean derivation and cache publication boundaries

Workstream E: Deployment and cluster integration

  • state how GloriousFlywheel deploys into the ../blahaj cluster
  • state what still belongs on Civo and what does not
  • align state, cache, and service exposure with the local RustFS-backed environment
  • move tailnet-first access from side-detail to first-class operator model

Workstream F: UX and user stories

  • operator story: deploy, recover, inspect, and scale runner pools
  • org-admin story: enroll repos and orgs into ARC safely
  • maintainer story: publish artifacts, consume caches, and debug CI
  • downstream user story: pick the right runner and understand cache behavior
  • agent/operator story: manage the platform through MCP, Linear, GitHub, and local repo tooling without reintroducing tribal memory

Seed Issue Set

These are the first issues that should exist under the reset milestone and project:

  1. Rename and reframe public repo identity away from attic-iac
  2. Replace stale Attic defaults and document real cache endpoints
  3. Decide and document Attic vs FlakeHub vs RustFS roles
  4. Verify and document real Tofu state backend authority
  5. Reconcile or retire Liqo-based runner expansion assumptions
  6. Define Linux builder CI contract using linux-xr as canary workload
  7. Define multi-org and org-plus-user GitHub ARC enrollment model
  8. Define runner lifecycle scaling policy and ownership boundaries
  9. Define tailnet-first operator plane for dashboard and management paths
  10. Define deployment contract into the blahaj local cluster

Exit Criteria For The Reset Milestone

  • no primary repo surface still defaults to stale fuzzy-dev cache endpoints
  • no primary repo surface still presents attic-iac as the current identity
  • current state backend truth is explicit and verified
  • current runner topology no longer depends on stale Liqo assumptions
  • FlakeHub, Attic, Bazel, and RustFS roles are written down coherently
  • there is a named builder contract for Linux-heavy CI workloads
  • GitHub and Linear planning surfaces both reflect the active program
  • the product story is strong enough to present GloriousFlywheel as a serious FOSS runner platform rather than a half-migrated internal cache repo

GloriousFlywheel