Historical - GloriousFlywheel Implementation Gap Matrix 2026-04-15

Historical - GloriousFlywheel Implementation Gap Matrix 2026-04-15

Snapshot date: 2026-04-15

Status

Historical reset-era evidence note.

This matrix is still useful for understanding the original drift shape, but it is no longer the primary planning or execution surface.

Use these notes first for current execution:

Purpose

Translate the reset into repo-grounded evidence.

This document focuses on the actual GloriousFlywheel implementation surfaces and answers four questions:

  • what core platform pieces already exist and should be preserved
  • what is still encoded around old attic-iac, GitLab, Civo, and stale cache assumptions
  • which operator and consumer flows are truly possible today
  • which current GitHub and Linear work items those gaps should feed

Quantitative Drift Snapshot

These counts are grep-derived indicators, not semantic proofs, but they are good enough to prioritize the reset:

  • 45 files still carry attic-iac or attic-cache identity drift
  • 135 files still carry GitLab coupling
  • 37 files still carry cache/runtime contract terms
  • 17 files still encode GitLab HTTP state backend semantics
  • 76 refs still point at Civo-era assumptions
  • 44 app files still carry direct GitLab coupling
  • 277 runner-dashboard refs across stack/module/app still point at GitLab env vars or concepts
  • 0 non-research refs mention FlakeHub, flakehub, or clean derivations
  • 51 non-research refs mention tailnet, Tailscale, or mTLS across 11 files

What Is Already Real

This repo is not just stale docs around a non-existent product. Several real primitives are already present:

  • The ARC stack is usable now. tofu/stacks/arc-runners/main.tf:85-207 deploys first-class tinyland-nix, tinyland-docker, and tinyland-dind pools and already supports extra_runner_sets.
  • The ARC runner module already injects cache env vars in the right place. tofu/modules/arc-runner/locals.tf:43-60 wires ATTIC_SERVER, ATTIC_CACHE, BAZEL_REMOTE_CACHE, and NIX_CONFIG into runner pods.
  • The Attic stack already includes a Bazel remote cache deployment. tofu/stacks/attic/main.tf:1293-1350 instantiates the bazel-cache module, and tofu/stacks/attic/main.tf:1026-1043 exports cache endpoints.
  • The composite GitHub Actions surface is real. .github/actions/setup-flywheel/action.yml:21-40 and .github/actions/nix-job/action.yml:33-49 already give downstream repos a usable cache-aware runner workflow.
  • The dashboard already has reusable observability primitives. app/src/routes/api/cache/+server.ts:10-70 exposes cache health, app/src/lib/server/k8s/client.ts:14-208 supports multi-namespace K8s inspection, and app/src/hooks.server.ts:28-45 already supports passkey-adjacent proxy auth via tailscale or mTLS headers.
  • Multi-org ARC scoping is already modeled. tofu/stacks/arc-runners/variables.tf:299-321 and docs/guides/github-app-adoption.md:149-213 show a real path for org-scoped and repo-scoped extra scale sets.

Gap Matrix

1. Identity And Product Story

Strongest current asset:

  • the repo already has a coherent ARC, cache, and dashboard substrate

Deep mismatch:

  • the main public surface still frames the repo as an attic-iac upstream plus overlay system. README.md:15-16, README.md:20, README.md:82, README.md:99, and README.md:121-128 are still explicit about that
  • MODULE.bazel:1-12 still declares the module name as attic-iac
  • flake.nix:1-2, flake.nix:182-183, flake.nix:215-216, and flake.nix:245-246 still carry old descriptions and source labels
  • .github/workflows/build-image.yml:45-51 and .github/workflows/build-image.yml:76-82 still publish image metadata against Jesssullivan/attic-iac
  • app/src/lib/config/app-config.json:2-8 still points the dashboard source repo at a GitLab attic-cache project

Impact:

  • the repo reads like an attic-era overlay toolkit even where the code already behaves more like a GitHub ARC and cache platform

Backlog mapping:

  • #168
  • TIN-124

2. Cache, Publication, And Runtime Truth

Strongest current asset:

  • the repo already has ARC-side cache injection and a MinIO-backed Bazel remote cache implementation

Deep mismatch:

  • .github/actions/setup-flywheel/action.yml:21-37 assumes cluster-DNS cache access for self-hosted runners, which is directionally correct
  • but the broader repo still encodes stale or conflicting cache coordinates: flake.nix:289, flake.nix:386, docs/runners/cache-integration.md:9-24, docs/runners/cache-integration.md:63-109, docs/runners/github-actions.md:80-93, and docs/runners/project-onboarding.md:99
  • docs/architecture/cache-architecture.md:88-93 still presents public cache ingress in an older generic form rather than current runtime truth
  • there are 0 non-research references to FlakeHub or clean derivations

Impact:

  • downstream consumers have real cache wiring available, but the publication and authority story is still folklore
  • the repo cannot yet explain when a build result belongs in Attic, Bazel remote cache, FlakeHub, or a future clean-derivation flow

Backlog mapping:

  • #167
  • #171
  • TIN-125
  • TIN-127

3. Deployment And State Contract

Strongest current asset:

  • every stack is already organized as a real OpenTofu deployment target

Deep mismatch:

  • all stack backends still encode GitLab managed HTTP state: tofu/stacks/arc-runners/backend.tf:1-8, tofu/stacks/gitlab-runners/backend.tf:1-8, tofu/stacks/runner-dashboard/backend.tf:1-8, tofu/stacks/attic/backend.tf:1-42
  • .github/workflows/deploy-arc-runners.yml:37-76 and .github/workflows/deploy-arc-runners.yml:126-177 still depend on ubuntu-latest, Civo CLI kubeconfig generation, and a GitLab PAT-backed state flow
  • tofu/stacks/attic/main.tf:47-76 and tofu/stacks/attic/variables.tf:7-24 still frame Kubernetes access around GitLab Agent semantics
  • tofu/stacks/attic/variables.tf:202-234 still carries Civo backup assumptions
  • docs/infrastructure/proxy-and-access.md:8-42 still leads with SOCKS proxy and treats Tailscale as optional instead of primary operator posture

Impact:

  • GloriousFlywheel cannot yet honestly claim a local-first deployment contract against Tinyland cluster truth while its own workflows and backend docs remain GitLab-state and Civo-first

Backlog mapping:

  • #169
  • TIN-128
  • #167
  • TIN-125

4. Runner Topology And Lifecycle

Strongest current asset:

  • the GitHub ARC topology is already more advanced than the repo narrative

Deep mismatch:

  • tofu/stacks/arc-runners/main.tf:82-207 and tofu/stacks/arc-runners/variables.tf:299-321 already support a clear multi-pool ARC model, including repo- and org-scoped extra scale sets
  • but README.md:34-38 still presents GitLab runners as a first-class core platform component next to ARC, and docs/runners/README.md:16-29 still centers a six-runner cross-forge matrix
  • docs/runners/self-service-enrollment.md:1-169 is still mostly a GitLab HPA enrollment guide
  • .github/workflows/validate.yml:31-45 and .github/workflows/validate.yml:63-69 still validate the legacy GitLab runner stack as a peer primary surface
  • the closed PR #166 exposed design pressure because the repo has not yet written down the post-Liqo lifecycle model for ARC growth; that decision now lives in issue #170

Impact:

  • the platform has a decent ARC substrate, but not a first-class ARC lifecycle story
  • org-level and repo-level GitHub enrollment is technically possible, but it is not yet the dominant documented or operational path

Backlog mapping:

  • #170
  • #172
  • TIN-126
  • TIN-129

5. Dashboard And Operator Plane

Strongest current asset:

  • the dashboard already spans cache, K8s, monitoring, passkeys, and proxy-aware access hooks

Deep mismatch:

  • the runner dashboard stack and module are still fundamentally GitLab-backed: tofu/stacks/runner-dashboard/main.tf:40-125, tofu/stacks/runner-dashboard/variables.tf:38-130, tofu/modules/runner-dashboard/main.tf:125-186, tofu/modules/runner-dashboard/variables.tf:45-136
  • the app follows the same pattern: app/src/routes/api/runners/+server.ts:8-19, app/src/routes/api/runners/[name]/+server.ts:8-27, app/src/routes/api/runners/[name]/pause/+server.ts:7-24, and app/src/routes/api/runners/[name]/resume/+server.ts:7-24 all call GitLab APIs or fall back to mocks
  • GitOps submission is GitLab MR-based: app/src/lib/server/gitops/repository.ts:7-82 and app/src/lib/server/gitops/pipeline.ts:62-129
  • app/src/lib/config/environments.json:2-32 still hardcodes Beehive, Rigel, and Tinyland examples from older GitLab-shaped environments
  • app/src/hooks.server.ts:28-45 shows tailscale and mTLS only as proxy-header auth helpers, not as the primary operator contract
  • app/src/hooks.server.ts:87-96 still allows outbound connect-src only to https://gitlab.com

Impact:

  • the dashboard is useful as a monitoring shell, but it is not yet a native GitHub ARC and tailnet-first operator plane
  • the repo currently has monitoring parity across forges faster than it has control-plane parity across forges

Backlog mapping:

  • #172
  • #173
  • TIN-128
  • TIN-129
  • TIN-130

6. Builder Contract And FOSS Surface

Strongest current asset:

  • the repo already has a real Bazel module, Nix shell, and image build workflow

Deep mismatch:

  • MODULE.bazel:139-162 shows the intended Bazel and Nix split clearly enough
  • tofu/modules/bazel-cache/main.tf:1-257 gives the repo a real remote build cache implementation
  • but README.md:15-16, README.md:121-128, and many architecture docs still frame the build story around private overlays, not a first-class FOSS product
  • .github/workflows/build-image.yml:45-46 and .github/workflows/build-image.yml:76-77 still publish user-scoped images rather than a stable org-facing contract
  • there are 0 non-research refs to FlakeHub or clean derivations, so the repo currently has no first-class story for those capabilities even in docs

Impact:

  • the build substrate is real, but the repo still under-describes how external consumers should trust, consume, and extend it

Backlog mapping:

  • #171
  • #173
  • TIN-127
  • TIN-130

Flow Readout

These are the main user and operator flows that appear from the current code.

Platform Maintainer Deploys Or Updates A Stack

Current reality:

  • the stack layout is usable
  • the actual execution path is still GitLab HTTP state plus Civo or GitLab Agent-shaped kube access

Implication:

  • this flow needs to be rewritten before GloriousFlywheel can present itself as a local-first Tinyland-native deployment system

Org Admin Enrolls A New GitHub Org Or Repo

Current reality:

  • technically possible today via extra_runner_sets, extra secrets, and ARC scale-set registration

Implication:

  • this is a strong hidden capability that needs first-class docs, lifecycle ownership, and likely a safer operator experience

Repo Consumer Runs Nix Or Bazel On ARC

Current reality:

  • this is the strongest ready-now user flow
  • ARC labels, cache injection, and composite actions already exist

Implication:

  • this should become the primary proof path for GloriousFlywheel rather than sitting beneath GitLab-era docs

Operator Monitors And Controls The Fleet

Current reality:

  • cache health and K8s monitoring are partially forge-agnostic
  • runner list, pause, resume, and GitOps change submission are still GitLab-only

Implication:

  • the dashboard should be treated as a partial control-plane shell, not a finished operator product

Security-Conscious Operator Accesses The Dashboard

Current reality:

  • passkeys, tailscale, and mTLS are present
  • GitLab OAuth is still the primary login and policy center

Implication:

  • the security model is already drifting toward tailnet-native access, but the repo still documents and configures it as secondary

Immediate Research Implications

  • preserve the ARC stack, cache injection, bazel-cache module, and dashboard observability shell
  • stop treating the repo as if it needs a total rewrite; the deeper issue is mismatched truth and ownership surfaces
  • make the Attic vs Bazel vs FlakeHub vs clean-derivation contract explicit before more downstream guidance is written
  • decide the state-backend and deployment authority model before doing broad Tofu cleanup
  • separate GitLab legacy-support surfaces from the primary GloriousFlywheel product story

Backlog Use

This document should act as the evidence layer for the current reset backlog:

  • #168 / TIN-124 should use the identity and product-story evidence above
  • #167 and #171 / TIN-125 and TIN-127 should use the cache and builder evidence, especially the absence of any non-research FlakeHub contract
  • #169 / TIN-128 should use the deployment and state-contract evidence
  • #170 / TIN-126 should use the ARC-versus-legacy topology evidence
  • #172 / TIN-129 should use the operator-plane and multi-org enrollment evidence
  • #173 / TIN-130 should use the flow readout as the starting storyboard surface

GloriousFlywheel