GloriousFlywheel Milestone Execution Matrix 2026-04-15

GloriousFlywheel Milestone Execution Matrix 2026-04-15

Snapshot date: 2026-04-15

Purpose

Turn the reset backlog into a concrete file and surface sequence for GloriousFlywheel.

Public status and roadmap now live in ../current-state.md and ../roadmap.md. This matrix is a detailed sequencing note, not the primary public roadmap.

This matrix is intentionally biased toward:

  • primary repo truth before long-tail cleanup
  • runtime authority before renames that would have to be redone
  • GitHub ARC and cache-consumer flows before legacy cross-forge storytelling
  • operator-plane clarity before dashboard feature work

Execution Rules

  1. Fix primary surfaces before secondary docs.
  2. Fix runtime and state authority before broad copy cleanup.
  3. Preserve working ARC and cache paths while reclassifying legacy GitLab surfaces.
  4. Treat gitlab-runners and GitLab dashboard control as legacy-support surfaces unless explicitly promoted.

Live GitHub Control Plane

Verified on 2026-04-16:

  • open GitHub milestones: 0
  • historical rollout issue: #208, closed at 2026-04-16T16:56:05Z
  • merged rollout baseline: PR #209
  • adjacent planning lanes: #210, #211, and #212
  • open PR count: 0

This matrix still uses M1 through M5 as local sequencing vocabulary, not as the current live GitHub milestone surface.

Milestone Map

M1: Truthing And Identity Reset

Goal:

  • stop presenting GloriousFlywheel as attic-iac first and ARC/cache platform second

Status:

  • P0 completed on 2026-04-15
  • P1 completed for the primary architecture and onboarding docs on 2026-04-15
  • remaining M1 work is now a secondary sweep, not a blocking identity reset

Primary execution set:

Priority Surface Files Why it belongs in M1 Change mode Backlog
P0 repo landing surface README.md, docs/index.md these two files currently define the public meaning of the repo rewrite TIN-124, #168
P0 module identity MODULE.bazel, flake.nix the module name and flake metadata still encode the old product boundary decide then rewrite TIN-124, #168
P0 published image identity .github/workflows/build-image.yml, .github/workflows/release.yml image metadata and release text still point at Jesssullivan/attic-iac rewrite TIN-124, #168
P0 app-facing project identity app/src/lib/config/app-config.json dashboard still points users at old GitLab attic-cache source rewrite TIN-124, #168
P1 primary architecture story docs/architecture/bzlmod-topology.md, docs/architecture/multi-repo-layout.md, docs/architecture/overlay-system.md these docs still define the repo as upstream-plus-overlay infrastructure reframe TIN-124, #168
P1 docs navigation docs/getting-started-guide.md, docs/infrastructure/quick-start.md, docs/infrastructure/overlay-creation.md these onboarding docs reinforce the wrong repo identity and deployment shape re-sequence TIN-124, #168

Exit condition:

  • a new reader can land in the repo and understand GloriousFlywheel as a GitHub ARC, cache, and operator platform without reading overlay-era context

M2: Cache, FlakeHub, And State Convergence

Goal:

  • write down and then enforce the actual authority model for cache endpoints, state backend, and publication surfaces

Status:

  • P0 partially executed on 2026-04-15
  • active cache defaults and primary cache-consumer docs were normalized around the implemented stack coordinates
  • root local init now supports TOFU_BACKEND_CONFIG_DIR plus a concrete per-stack backend-file example
  • the ARC deploy workflow now prefers explicit kubeconfig and backend-config secrets, with legacy Civo/GitLab fallback retained for compatibility
  • backend authority and deploy-workflow authority still remain the blocking P0 work inside M2
  • the canonical decision note for that blocking work now lives in docs/research/gloriousflywheel-deployment-authority-decision-2026-04-15.md
  • the ordered edit sequence for that work now lives in docs/research/gloriousflywheel-deployment-authority-execution-plan-2026-04-15.md
  • the narrowed option set for that work now lives in docs/research/gloriousflywheel-backend-authority-options-2026-04-15.md
  • the backend target-direction note for honey rollout convergence now lives in docs/research/gloriousflywheel-backend-target-state-2026-04-16.md
  • root init/help text and the primary stack examples now reflect that current backend inputs still target backend "http" and that future S3-compatible migration is a later coordinated stack change
  • the remaining ARC CI input split now lives in docs/research/gloriousflywheel-arc-ci-input-contract-2026-04-15.md
  • additive ARC runner-set ownership is now classified explicitly in docs/research/gloriousflywheel-arc-additive-policy-governance-2026-04-15.md

Primary execution set:

Priority Surface Files Why it belongs in M2 Change mode Backlog
P0 cache defaults in active code flake.nix, .github/actions/setup-flywheel/action.yml, .github/actions/nix-job/action.yml these files set the effective Nix and Bazel cache behavior for users and CI correct runtime truth TIN-125, #167
P0 stack backend authority tofu/stacks/arc-runners/backend.tf, tofu/stacks/attic/backend.tf, tofu/stacks/gitlab-runners/backend.tf, tofu/stacks/runner-dashboard/backend.tf, Justfile, tofu/stacks/attic/Justfile, tofu/stacks/runner-dashboard/Justfile, tofu/stacks/gitlab-runners/Justfile, config/backend.http.example.hcl active stacks now expose a generic HTTP contract at the root, but the repo still needs one real non-legacy authority to supply it consistently and stop treating HTTP bootstrap examples as the architectural destination decide target backend then refactor TIN-128, historical #169, historical #208, PR #209
P0 deploy workflow authority .github/workflows/deploy-arc-runners.yml, docs/infrastructure/quick-start.md, docs/getting-started-guide.md, docs/reference/environment-variables.md, tofu/stacks/arc-runners/dev-policy.tfvars, tofu/stacks/arc-runners/dev-extra-runner-sets.tfvars, tofu/stacks/arc-runners/legacy-civo.tfvars workflow automation now prefers explicit secrets and committed dev policy, supports org-specific additive policy, but still relies on fallback Civo/GitLab authority for part of the compatibility path redesign TIN-128, #169
P1 consumer cache docs docs/runners/cache-integration.md, docs/runners/github-actions.md, docs/runners/nix-builds.md, docs/reference/environment-variables.md current docs still point at stale endpoints and lack any FlakeHub contract rewrite from contract TIN-125, TIN-127, #167, #171
P1 cache architecture docs docs/architecture/cache-architecture.md, docs/build-system/watch-store.md these files describe implemented Attic/Bazel behavior and should anchor the new contract tighten and classify TIN-125, TIN-127, #167, #171
P1 storage integration decision tofu/stacks/attic/main.tf, tofu/modules/bazel-cache/main.tf, tofu/modules/rustfs/* repo has real Attic and Bazel integration plus an unused RustFS storage module classify and stage TIN-125, TIN-127, #171

Exit condition:

  • the repo has one explicit answer for state authority and one explicit answer for Attic vs Bazel vs FlakeHub vs RustFS roles
  • the backend target family for on-prem rollout is written down explicitly enough that primary docs no longer imply generic HTTP is the final design

M3: Runner Substrate And Builder Contracts

Goal:

  • make ARC the primary runner narrative and define the Linux builder contract around it

Status:

  • P1 builder-contract grounding started on 2026-04-15
  • repo-adoption, forge-parity, and competitive-reality findings now live in docs/research/gloriousflywheel-adoption-forge-and-competitive-reality-2026-04-16.md
  • the direct follow-on execution notes now live in:
    • docs/research/gloriousflywheel-downstream-adoption-and-migration-kit-2026-04-16.md
    • docs/research/gloriousflywheel-downstream-adoption-inventory-matrix-2026-04-16.md
    • docs/research/gloriousflywheel-first-tranche-repo-contracts-2026-04-16.md
    • docs/research/gloriousflywheel-xoxdwm-first-patch-playbook-2026-04-16.md
    • docs/research/gloriousflywheel-tinyland-dev-first-patch-playbook-2026-04-16.md
    • docs/research/gloriousflywheel-runner-benchmark-methodology-2026-04-16.md
    • docs/research/gloriousflywheel-benchmark-scorecard-template-2026-04-16.md
    • docs/research/gloriousflywheel-github-first-forge-parity-2026-04-16.md
    • docs/research/gloriousflywheel-forge-support-matrix-2026-04-16.md
  • those follow-on notes now have explicit GitHub owners:
    • #210 downstream adoption and migration kit
    • #211 GitHub-first forge-parity boundary
    • #212 benchmark methodology and competitive comparison
  • those findings now split the direct-adoption surface into:
    • 12 directly exposed runner-label repos
    • 5 repos in the operational first migration tranche
    • the full 264 non-fork repo footprint as a longer-tail addressable set
  • the first explicit builder note now lives in docs/research/gloriousflywheel-linux-builder-contract-2026-04-15.md
  • the Nix-bootstrap versus memory-scaling split now lives in docs/research/gloriousflywheel-nix-builder-bootstrap-and-scaling-options-2026-04-16.md
  • the first execution step from that note is now in repo code: tinyland-nix-heavy exists as an additive heavy Nix canary in tofu/stacks/arc-runners/dev-extra-runner-sets.tfvars
  • the near-term sprint priorities for heavy-Nix rollout, workflow-owned Nix bootstrap, and FlakeHub cleanup now live in docs/research/gloriousflywheel-builder-runtime-sprint-priorities-2026-04-16.md
  • the live owner lane for the FlakeHub portion of that work is now #215
  • additive-versus-first-class builder promotion criteria now live in docs/research/gloriousflywheel-builder-surface-promotion-criteria-2026-04-15.md
  • the recommended clean-derivation promotion flow now lives in docs/research/gloriousflywheel-clean-derivation-promotion-workflow-2026-04-15.md
  • the actual flake-output candidate set for that work now lives in docs/research/gloriousflywheel-nix-output-candidates-2026-04-15.md
  • the first candidate-specific promotion gate now lives in docs/research/gloriousflywheel-runner-dashboard-promotion-gate-2026-04-15.md
  • the runner-dashboard consumption contract now lives in docs/research/gloriousflywheel-runner-dashboard-consumption-contract-2026-04-16.md
  • the runner-dashboard durable publication decision now lives in docs/research/gloriousflywheel-runner-dashboard-publication-decision-2026-04-16.md
  • the runner-dashboard release-authority change gate now lives in docs/research/gloriousflywheel-runner-dashboard-release-authority-change-gate-2026-04-16.md
  • lab#71 and merged lab#73 now provide one concrete builder-contract signal: self-hosted tinyland-nix workflows must bootstrap Nix explicitly before any FlakeHub login/cache or repo build logic runs

Primary execution set:

Priority Surface Files Why it belongs in M3 Change mode Backlog
P0 runner topology code tofu/stacks/arc-runners/main.tf, tofu/stacks/arc-runners/variables.tf, tofu/modules/arc-runner/* this is the real ARC platform surface and already contains multi-org primitives document and refine TIN-126, TIN-129, #170, #172
P0 runner topology docs docs/runners/README.md, docs/runners/github-actions.md, docs/guides/github-app-adoption.md docs understate ARC and overstate GitLab HPA centrality rewrite TIN-126, TIN-129, #170, #172
P0 legacy cross-forge positioning docs/guides/cross-forge-ci.md, docs/runners/self-service-enrollment.md, docs/runners/runner-selection.md these files currently keep GitLab HPA as a co-equal default story demote or split legacy support TIN-126, TIN-129, #170, #172
P1 CI validation surface .github/workflows/validate.yml validation still treats gitlab-runner, gitlab-user-runner, and gitlab-agent-rbac as primary module peers reclassify or keep as legacy coverage TIN-126, #170
P1 builder contract surface MODULE.bazel, tofu/modules/bazel-cache/main.tf, docs/build-system/containers.md, docs/build-system/greedy-build-pattern.md these are the closest existing surfaces to a real Linux builder contract extend and publish TIN-127, #171
P1 downstream adoption kit docs/research/gloriousflywheel-downstream-adoption-and-migration-kit-2026-04-16.md, docs/research/gloriousflywheel-downstream-adoption-inventory-matrix-2026-04-16.md, docs/research/gloriousflywheel-first-tranche-repo-contracts-2026-04-16.md, docs/research/gloriousflywheel-xoxdwm-first-patch-playbook-2026-04-16.md, docs/research/gloriousflywheel-tinyland-dev-first-patch-playbook-2026-04-16.md, docs/research/gloriousflywheel-lab-first-patch-playbook-2026-04-16.md, docs/research/gloriousflywheel-blahaj-first-patch-playbook-2026-04-16.md, docs/research/gloriousflywheel-dogfood-first-patch-playbook-2026-04-16.md, docs/runners/downstream-migration-checklist.md, downstream repo workflow patches, published PRs, PR triage notes, future migration docs the first 5 migration repos need an explicit kit, repo-by-repo contract sheet, repo-specific first-patch playbooks, a public checklist, a broader 12-repo direct-usage inventory, real canary execution evidence from XoxdWM, tinyland.dev, lab, blahaj, and GloriousFlywheel itself, two completed merges (lab#72, blahaj#68), one repo-level blocker (tinyland.dev#136), and one capacity blocker (XoxdWM#28) resolve or split tinyland.dev#136, then clear XoxdWM#28 runner-capacity blockage #210
P1 benchmark and forge positioning docs/research/gloriousflywheel-runner-benchmark-methodology-2026-04-16.md, docs/research/gloriousflywheel-benchmark-scorecard-template-2026-04-16.md, docs/research/gloriousflywheel-github-first-forge-parity-2026-04-16.md, docs/research/gloriousflywheel-forge-support-matrix-2026-04-16.md, future benchmark artifacts commercial comparison and GitHub-first product positioning need explicit ownership, measurable scorecards, and a visible forge support boundary measure, classify, then publish #211, #212

Exit condition:

  • the repo has a first-class post-Liqo ARC model and a named Linux builder contract that downstream repos can adopt without guesswork

M4: Local-First Deployment And Tailnet Operations

Goal:

  • redefine GloriousFlywheel operations around local-first cluster truth and a tailnet-native operator plane

Status:

  • dashboard control-plane assumptions are now captured explicitly in docs/research/gloriousflywheel-dashboard-control-plane-assumptions-2026-04-16.md
  • dashboard control-authority options and the current recommendation now live in docs/research/gloriousflywheel-dashboard-control-authority-options-2026-04-16.md
  • dashboard mutation compatibility and user-facing control labeling now live in docs/research/gloriousflywheel-dashboard-mutation-compatibility-2026-04-16.md
  • the current hold decision for mutation authority now lives in docs/research/gloriousflywheel-dashboard-mutation-authority-hold-2026-04-16.md
  • the current tailnet-first operator identity contract now lives in docs/research/gloriousflywheel-tailnet-operator-identity-2026-04-16.md
  • the current operator permission policy now lives in docs/research/gloriousflywheel-dashboard-operator-permission-policy-2026-04-16.md
  • the current dashboard read-data classification now lives in docs/research/gloriousflywheel-dashboard-read-data-policy-2026-04-16.md
  • the first real admin auth workflow now lives in docs/research/gloriousflywheel-dashboard-admin-auth-workflows-2026-04-16.md
  • the first dashboard auth audit-event surface now lives in docs/research/gloriousflywheel-dashboard-auth-audit-events-2026-04-16.md
  • the first dashboard control audit-event surface now lives in docs/research/gloriousflywheel-dashboard-control-audit-events-2026-04-16.md
  • stack and module comments now describe the current GitLab-backed dashboard control plane more honestly
  • the dashboard app now uses the configured GitLab origin in CSP instead of hard-coding https://gitlab.com
  • /api/runners now returns a stable { runners } shape, and the two primary page loads tolerate both old and new shapes during the transition
  • the dashboard UI and read-side comments now distinguish local config visibility from GitLab-backed compatibility mutation instead of presenting a generic forge-neutral control path
  • the dashboard nav, pipeline view, and auth docs now treat GitLab-backed mutation and interactive OAuth as compatibility surfaces rather than implied strategic defaults
  • trusted proxy identity now takes precedence over stored interactive sessions, and dashboard sessions are signed when SESSION_SECRET is configured
  • current runner pause/resume and config-submission mutations are now enforced server-side for operator and admin roles only, with matching read-only UI cues on the dashboard
  • all non-public dashboard API routes now require an authenticated identity at the hook boundary, with 401 for unauthenticated API callers and public health left exempt
  • config and drift detail reads are now operator-plus, while runtime auth-policy summary is admin-only in Settings
  • admins can now inspect and revoke dashboard passkeys across users through the Settings surface
  • interactive session establishment, logout, and passkey lifecycle actions now leave durable auth audit events that admins can inspect in Settings
  • successful GitLab-backed compatibility mutations now leave durable control audit events that admins can inspect in Settings
  • primary docs and config examples now encode one physical on-prem cluster, honey, with bumble and sting treated as node-role placement inputs
  • GitHub M#6 is now a historical closeout tranche with 0 open and 7 closed issues, so #169 and #172 are historical owner references, not the live execution bucket
  • historical rollout issue #208 is now closed, and the live on-prem rollout execution surface is PR #209

Primary execution set:

Priority Surface Files Why it belongs in M4 Change mode Backlog
P0 dashboard deployment contract tofu/stacks/runner-dashboard/main.tf, tofu/stacks/runner-dashboard/variables.tf, tofu/modules/runner-dashboard/* dashboard stack still encodes GitLab OAuth and GitLab project/group control as the default operator plane redesign TIN-128, TIN-129, #172
P0 dashboard app control plane app/src/routes/api/runners/+server.ts, app/src/routes/api/runners/[name]/+server.ts, app/src/routes/api/runners/[name]/pause/+server.ts, app/src/routes/api/runners/[name]/resume/+server.ts, app/src/lib/server/gitops/repository.ts, app/src/lib/server/gitops/pipeline.ts monitor paths exist, but control flows are still GitLab-backed split monitoring from control; redesign control TIN-128, TIN-129, TIN-130, #172, #173
P0 operator auth surface app/src/hooks.server.ts, app/src/lib/server/auth/gitlab-oauth.ts, app/src/lib/server/auth/session.ts, app/src/routes/auth/login/+page.svelte tailscale, mTLS, and passkeys are secondary to GitLab OAuth in current behavior promote tailnet-native auth model TIN-128, TIN-130, #172, #173
P0 on-prem cluster truth docs/infrastructure/quick-start.md, docs/getting-started-guide.md, docs/infrastructure/cluster-access.md, docs/infrastructure/clusters-and-environments.md, docs/infrastructure/proxy-and-access.md, config/organization.example.yaml, scripts/validate-org-config.sh, app/scripts/generate-environments.ts these surfaces must encode one physical cluster honey and must stop implying that bumble or sting are separate cluster targets rewrite around corrected on-prem truth TIN-128, historical #208, PR #209, historical #169, historical #172
P1 environment and access follow-through docs/infrastructure/deployment-ordering.md, docs/reference/config-reference.md, docs/reference/justfile-commands.md, docs/infrastructure/customization-guide.md these secondary surfaces should reinforce the same honey-only cluster model and logical env mapping tighten and align TIN-128, historical #208, PR #209, historical #169
P1 environment examples app/src/lib/config/environments.json old Beehive/Rigel/Tinyland examples distort the current operator model replace or clearly mark legacy TIN-128, TIN-130, #173

Exit condition:

  • operator access and deployment docs read as tailnet-first and local-cluster native rather than GitLab Agent or SOCKS-proxy default
  • no primary deployment surface models bumble or sting as separate clusters

Secondary Sweep After M1 Through M4

These files should not lead the reset, but they should follow once the primary surfaces are corrected:

  • docs/reference/config-reference.md
  • docs/reference/justfile-commands.md
  • docs/reference/tofu-modules.md
  • docs/runners/project-onboarding.md
  • docs/runners/runbook.md
  • docs/runners/troubleshooting.md
  • Justfile
  • any remaining gitlab-runner, gitlab-user-runner, and gitlab-agent-rbac module docs that need legacy-support labeling

Suggested Execution Sequence

  1. M1 P0 files
  2. M2 P0 files
  3. M3 P0 files
  4. M4 P0 files
  5. M1 through M4 P1 files
  6. secondary sweep and storyboarding

Notes

  • This matrix is for execution sequencing, not final architecture.
  • If the state-backend decision changes, M2 and M4 should be re-checked before broad cleanup proceeds.
  • After the first executable M2 pass, #167 should carry cache and publication-contract work, while #169 should carry backend, workflow, and operator-entrypoint authority.
  • PR #166 was closed on 2026-04-15; the runner-topology decision pressure now lives in issue #170.
  • PR #209 is the merged rollout baseline for honey convergence.
  • Additional work should be sliced into new reviewable follow-on PRs rather than added as more broad milestone-era reconciliation tracks.

GloriousFlywheel