GloriousFlywheel Dashboard Mutation Authority Hold 2026-04-16
Snapshot date: 2026-04-16
Purpose
Make the current decision for #172 explicit:
- keep GitLab-backed mutation as a compatibility surface for now
- do not pretend a replacement mutation authority exists yet
- keep monitoring and visibility work moving without blocking on a full control redesign
This is a hold decision, not a final architecture.
Companion notes:
- gloriousflywheel-dashboard-control-plane-assumptions-2026-04-16.md
- gloriousflywheel-dashboard-control-authority-options-2026-04-16.md
- gloriousflywheel-dashboard-mutation-compatibility-2026-04-16.md
- gloriousflywheel-program-surface-2026-04-15.md
- gloriousflywheel-milestone-execution-matrix-2026-04-15.md
Current Repo Grounding
Today the dashboard mutation surface is split like this:
- read-side config visibility uses local tfvars inspection
- runner pause/resume uses GitLab runner APIs when configured
- submitted config changes create a GitLab branch and merge request
- interactive login still commonly enters through GitLab OAuth when that path is configured
There is no implemented replacement mutation authority in the repo today.
Holding Decision
For the current phase:
- keep GitLab-backed mutation available as compatibility
- stop presenting it as a strategic default
- keep monitoring, visibility, and tailnet-friendly access work moving
- defer mutation-authority replacement until a concrete target is chosen
Why Hold Instead Of Replacing Now
The repo still lacks several prerequisites for a clean mutation-authority replacement:
- an explicitly chosen desired-state authority for runner config changes
- a cross-forge mutation design that is more real than the current GitLab path
- a cluster-native mutation design with audit and safety boundaries
- a final auth model that ties operator identity to mutation permissions
Without those pieces, replacing the current compatibility path now would create more ambiguity, not less.
What This Allows
This hold makes it safe to continue:
- monitoring-first dashboard work
- tailnet-first access cleanup
- passkey and proxy-header auth improvements
- admin-side auth and control audit visibility improvements
- documentation cleanup that stops overstating GitLab control
What It Does Not Allow
This hold does not mean:
- GitLab mutation becomes the endorsed long-term product direction
- the dashboard control plane is considered complete
- route names like
/gitopsimply a mature forge-neutral control layer
Exit Condition
Replace this hold only when the repo has:
- a named replacement mutation authority
- an explicit audit and permission model
- a documented desired-state source of truth
- a migration story for existing GitLab-backed compatibility flows