GloriousFlywheel Dashboard Control Authority Options 2026-04-16

GloriousFlywheel Dashboard Control Authority Options 2026-04-16

Snapshot date: 2026-04-16

Purpose

Turn the dashboard control-plane readout into explicit options and a current recommendation for #172.

This note does not claim the redesign is implemented. It defines the most defensible next direction from the repo’s actual state.

Companion notes:

Current Constraint

The repo already supports a more local and tailnet-friendly access envelope than its dashboard control plane.

That means the next decision is not “should tailscale exist?” It is:

  • what should count as authoritative runner control after access reaches the dashboard

Option Set

Option A: Keep GitLab As Primary Control Authority

Meaning:

  • GitLab stays authoritative for runner inventory, pause/resume, and GitOps mutation
  • tailscale, mTLS, and WebAuthn only change who can reach the dashboard

Strengths:

  • lowest implementation risk
  • matches most current code

Weaknesses:

  • keeps the dashboard strategically tied to GitLab
  • does not make ARC or tailnet-first operation the primary product story

Recommendation:

  • valid only as explicit legacy support, not as the target operator plane

Option B: Split Monitoring From Mutation

Meaning:

  • make Kubernetes, ARC, and Prometheus read-side monitoring the primary dashboard plane
  • demote GitLab-backed mutation to legacy support or remove it from the primary operator story
  • defer a new mutation authority until it is chosen explicitly

Strengths:

  • matches the repo’s current strengths
  • avoids pretending GitHub ARC control already exists
  • allows tailnet-first access to become primary without inventing a fake mutation path

Weaknesses:

  • leaves mutation as a separate later decision
  • may reduce dashboard ambition in the short term

Recommendation:

  • best immediate direction

Option C: Replace GitLab Mutation With GitHub/GitOps Mutation

Meaning:

  • shift mutation from GitLab project APIs and merge requests to GitHub-native repo APIs, PRs, or runner-management APIs

Strengths:

  • better aligns with the ARC and GitHub runner story
  • reduces strategic dependence on GitLab

Weaknesses:

  • not implemented anywhere in the repo today
  • still requires a clear desired-state repository and mutation workflow

Recommendation:

  • plausible later phase after Option B, not the first move

Option D: Make The Dashboard A Cluster-Native Control Plane

Meaning:

  • use Kubernetes resources or in-cluster controllers as the authoritative mutation surface
  • dashboard writes directly to cluster state instead of forge-hosted GitOps

Strengths:

  • strongest local-first posture
  • least dependent on forge-specific APIs

Weaknesses:

  • largest redesign
  • weakest current repo grounding
  • higher safety and audit burden

Recommendation:

  • not the next move from current repo state

Recommended path:

  1. adopt Option B now
  2. classify GitLab-backed control and GitOps mutation as legacy support
  3. make dashboard monitoring the primary tailnet-first operator surface
  4. decide a later mutation authority explicitly before reintroducing first-class control actions

Why Option B Fits Best

It is the only option that:

  • matches the repo’s current ARC and Kubernetes read-side strengths
  • avoids pretending GitHub-native mutation already exists
  • gives #172 a clean operator-plane story without blocking on a full forge migration
  • lets GitLab-backed control remain available as compatibility instead of disappearing abruptly

Immediate Implications

If Option B is accepted, the next cleanup wave should:

  • describe the dashboard primarily as a monitoring and operator-visibility surface
  • mark GitLab control actions as legacy/current compatibility
  • avoid presenting GitLab OAuth as the sole strategic auth path
  • avoid presenting GitLab Agent as a primary deployment or access authority

Exit Condition

  • #172 has an explicit control-authority recommendation
  • the repo can distinguish access auth from mutation authority
  • future dashboard redesign work has a concrete first-phase target

GloriousFlywheel