GloriousFlywheel Dashboard Mutation Compatibility 2026-04-16

GloriousFlywheel Dashboard Mutation Compatibility 2026-04-16

Snapshot date: 2026-04-16

Purpose

Make the current dashboard mutation path explicit so #172 does not keep describing a generic GitOps control plane that the repo does not actually have.

This note is intentionally narrow. It covers the user-facing mutation path and the corresponding UI language, not the full long-term control-plane redesign.

Companion notes:

Current Repo Truth

From the current app and server implementation:

  • runner list and runner detail views read through internal API routes that use GitLab group-runner APIs when configured, or mock data otherwise
  • the GitOps configuration view currently reads tfvars from the local repo checkout through app/src/routes/api/gitops/config/+server.ts
  • submitted configuration changes go through app/src/lib/server/gitops/pipeline.ts, which creates a GitLab branch, commits the tfvars update, and opens a GitLab merge request
  • pause and resume actions for runners go through GitLab runner APIs when configured
  • successful compatibility mutations now also leave control audit events that admins can inspect in Settings

This means the dashboard does not currently expose a forge-neutral or cluster-native mutation plane.

Required User-Facing Framing

The UI should describe the current path as:

  • monitoring and visibility first
  • local tfvars inspection for read-side configuration visibility
  • GitLab-backed compatibility flows for pause/resume and submitted config changes

The UI should not describe the current path as:

  • a generic GitOps control plane
  • a forge-neutral mutation surface
  • a future GitLab path that is not already in use

Why This Matters

Without this distinction, the repo keeps teaching two contradictory stories at once:

  • planning docs say monitoring should be primary and mutation is still a legacy or compatibility surface
  • the dashboard UI implies mutation is already a normal first-class control path

That contradiction makes #172 look more complete than it is and obscures the actual next decision.

Current Recommendation

For the current phase:

  1. keep the read-side dashboard surfaces active
  2. label mutation flows as GitLab-backed compatibility
  3. avoid implying that GitLab control is hypothetical or future
  4. defer any new mutation authority until it is chosen explicitly

Exit Condition

  • dashboard UI copy matches the real mutation path
  • server comments stop implying that current GitLab-backed control is only a future swap target
  • #172 can distinguish monitoring progress from mutation-authority redesign

GloriousFlywheel