GloriousFlywheel Dashboard Control Plane Assumptions 2026-04-16

GloriousFlywheel Dashboard Control Plane Assumptions 2026-04-16

Snapshot date: 2026-04-16

Purpose

Capture the exact stack, module, and app-level assumptions that still keep the runner dashboard control plane GitLab-native even after the local-first backend/init cleanup.

This note sharpens the remaining #169 and #172 work.

Companion notes:

Current Repo Facts

Direct inspection on 2026-04-16 shows:

  • tofu/stacks/runner-dashboard/main.tf and tofu/modules/runner-dashboard/main.tf still require a GitLab-backed control shape:
    • GitLab OAuth client ID and secret
    • GitLab URL
    • GitLab API token
    • GitLab group ID and project ID
    • runner_stack_name for GitOps tfvars mutation
  • the dashboard module writes GITLAB_*, RUNNER_STACK_NAME, and ATTIC_DEFAULT_ENV into the app ConfigMap and Secret
  • app auth is mixed-mode at the edge:
    • hooks.server.ts accepts proxy-header auth for tailscale and mTLS
    • WebAuthn is present
    • but the primary interactive login and callback path is still GitLab OAuth
  • dashboard data and runner control remain GitLab-native:
    • /api/runners and /api/runners/[name] call GitLab group runner APIs
    • pause/resume routes call GitLab runner pause/resume APIs
  • GitOps mutation remains GitLab-native:
    • app/src/lib/server/gitops/repository.ts reads and writes repo files through GitLab project APIs
    • app/src/lib/server/gitops/pipeline.ts creates GitLab branches and merge requests
  • ARC is present mainly as a read-side substrate:
    • the dashboard module supports ARC namespaces in RBAC and config
    • the app has Kubernetes readers for ARC resources
    • but there is no parallel GitHub-native control or mutation path

Exact Classification

1. Access Auth Is Mixed-Mode

Current supported envelopes:

  • GitLab OAuth
  • WebAuthn after OAuth bootstrap
  • Tailscale proxy-header auth
  • mTLS proxy-header auth

Important limit:

  • tailscale and mTLS currently change the access envelope, not the underlying runner control authority

2. Runner Inventory And Control Are GitLab-Native

The dashboard still treats GitLab as the authoritative source for:

  • runner listing
  • runner detail lookup
  • pause
  • resume

If GITLAB_TOKEN and GITLAB_GROUP_ID are absent, the app falls back to mock data rather than a parallel real control plane.

3. GitOps Mutation Is GitLab-Native

The dashboard’s change submission flow still assumes:

  • GitLab project repository APIs
  • GitLab branches
  • GitLab merge requests

That is not yet a forge-neutral or GitHub-native path.

4. Kubernetes Access Is More Generic Than Control

The stack and module already support:

  • generic kubeconfig context selection
  • ARC namespaces
  • caddy tailscale and mTLS ingress modes

So the infrastructure edge is ahead of the dashboard control plane itself.

What This Means For #169

The remaining #169 gap is not root init anymore. It is concentrated in the runner-dashboard stack and app contract:

  • stack and module variable surfaces still encode GitLab-first control inputs
  • app auth, data, and GitOps mutation still assume GitLab as the current control authority
  • comments and examples need to describe this honestly until the redesign happens

What This Means For #172

#172 should not treat tailscale or mTLS ingress as sufficient on their own.

That work still needs an answer for:

  • what replaces GitLab as the authoritative control API, if anything
  • whether monitoring and mutation should be split into separate surfaces
  • whether GitHub ARC control is a real target or only read-side visibility

Recommendation

Recommended next execution order:

  1. reclassify runner-dashboard comments, variable descriptions, and docs to describe the current GitLab-backed control plane honestly
  2. fix any app-level bugs that obscure the current control contract
  3. decide whether the dashboard remains GitLab-backed legacy support or gets a new control authority
  4. only then redesign auth, GitOps mutation, and runner control around a new operator plane

Exit Condition

  • the repo has one explicit note describing what is still GitLab-native in the dashboard control plane
  • #169 and #172 no longer rely on vague “legacy assumptions” language
  • future dashboard redesign work can target named control-plane seams

GloriousFlywheel