GloriousFlywheel Runner Dashboard Release Authority Change Gate 2026-04-16
Snapshot date: 2026-04-16
Purpose
Define what must become true before the runner dashboard is allowed to change release authority away from the current GHCR image workflow.
This note narrows the last remaining planning edge in #171.
Companion notes:
- gloriousflywheel-runner-dashboard-publication-decision-2026-04-16.md
- gloriousflywheel-runner-dashboard-consumption-contract-2026-04-16.md
- gloriousflywheel-runner-dashboard-promotion-gate-2026-04-15.md
gloriousflywheel-clean-derivation-promotion-workflow-2026-04-15.md
Current Repo Facts
Direct inspection on 2026-04-16 shows:
.github/workflows/build-image.ymlpublishes the dashboard fromapp/Dockerfiletoghcr.io/tinyland-inc/runner-dashboard- that workflow already includes:
- Docker Buildx
- GHCR push
- Trivy scanning
- cosign keyless signing
.github/workflows/release.ymlalso publishes the dashboard image to GHCR and now applies the same Trivy and cosign coverage on the tagged release pathflake.nixexports bothpackages.runner-dashboardandpackages.runner-dashboard-image- no active workflow publishes
packages.runner-dashboard-image tofu/stacks/runner-dashboard/main.tfdeploys a plain image string throughvar.image- no operator-facing docs or workflows currently treat a flake derivation or Nix-built image as release authority
Current Authority
Today the dashboard release authority is:
- Dockerfile-based image builds
- GHCR publication
- Trivy and cosign on that image path
That means the repo’s Nix derivation and Nix image surfaces are currently:
- valid build and validation surfaces
- not the authoritative public release path
What Counts As A Release-Authority Change
A release-authority change means any of the following:
- the Nix image path becomes the canonical published dashboard image
- the derivation itself becomes a public discovery or release surface
- the repo intentionally adopts dual publication with one declared canonical source of truth
Required Gates
Do not change release authority unless all of these are true.
1. Source-Of-Truth Gate
The repo must declare which surface is authoritative:
- Dockerfile image path
- Nix image path
- derivation plus separately defined image assembly path
- dual publication with one canonical release authority
Current status:
- not met for any non-current alternative
2. Security-Parity Gate
Any new authoritative path must carry security guarantees at least as strong as the current GHCR image workflow.
Minimum required capabilities:
- vulnerability scanning
- signing or provenance strong enough to replace current cosign coverage
- documented ownership for failures
Current status:
- not met for the Nix image path or direct derivation publication
3. Publication-Parity Gate
The new authority path must expose the same practical release semantics as the current image workflow.
Minimum required semantics:
- intentional release trigger
- stable versioned publication surface
- immutable or digest-addressable install target
- clear distinction between CI validation output and released artifact
Current status:
- not met outside the current GHCR image path
4. Deployment-Consumption Gate
The deployment stack and operator path must be able to consume the authoritative surface without ambiguity.
For this repo that means:
tofu/stacks/runner-dashboardstill gets a single clear install contract- docs and examples stop mixing a released image path with a different unpublished authoritative source
Current status:
- only met for image-based release authority
5. Documentation-Convergence Gate
Primary docs must tell one story across:
- dashboard overview
- container build docs
- release docs
- operator onboarding
Current status:
- only met for image-based release authority
6. Ownership Gate
The repo must define who owns breakage and promotion when release authority changes.
Minimum requirement:
#171owns the transition plan until a concrete workflow and maintainer boundary exist
Current status:
- planning ownership exists
- operational ownership for a changed authority does not
Recommendation
Recommended current rule:
- keep release authority on the GHCR image path
- keep
packages.runner-dashboardas the canonical Nix build artifact - keep
packages.runner-dashboard-imageas a non-authoritative Nix image path - do not start FlakeHub dashboard publication work until a non-image authority actually clears these gates
Exit Condition
- the repo has an explicit gate for changing dashboard release authority
- future FlakeHub or derivation-publication work can only proceed by clearing named requirements
#171no longer needs to treat release-authority change as an implicit background assumption