GloriousFlywheel Runner Dashboard Promotion Gate 2026-04-15

GloriousFlywheel Runner Dashboard Promotion Gate 2026-04-15

Snapshot date: 2026-04-15

Purpose

Define the actual clean-derivation promotion gate for packages.runner-dashboard, which is currently the strongest repo-native candidate in the flake output surface.

This note is for TIN-127 and issue #171.

Companion notes:

Current Repo Facts

Direct inspection on 2026-04-15 shows:

  • flake.nix exports:
    • packages.runner-dashboard
    • packages.runner-dashboard-image
  • packages.runner-dashboard is a repo-native derivation built from:
    • workspace lockfiles and root package metadata
    • app/
    • config/
  • that derivation currently runs:
    • pnpm install --frozen-lockfile
    • pnpm build
  • the GitHub validate workflow currently runs for the dashboard app:
    • pnpm check
    • pnpm test
    • pnpm build
  • the GitHub validate workflow now also runs:
    • nix build .#runner-dashboard
  • active publication for the dashboard image currently uses Docker Buildx to GHCR via .github/workflows/build-image.yml and .github/workflows/release.yml
  • no flake check currently verifies nix build .#runner-dashboard, but a primary GitHub validation surface now does
  • the current consumption answer now lives in gloriousflywheel-runner-dashboard-consumption-contract-2026-04-16.md

Gate Definition

Promote packages.runner-dashboard as a clean derivation only when all of the following are true:

1. Source Scope Gate

The derivation source set is intentionally bounded and reviewable.

Current status:

  • met enough to proceed

Reason:

  • the flake already narrows the source set to workspace metadata, app/, and config/

2. App Validation Gate

The app-facing validation surface is green in CI.

Required checks:

  • pnpm check
  • pnpm test
  • pnpm build

Current status:

  • met through the existing validate workflow

3. Nix Derivation Gate

The repo must validate the actual derivation, not just the app source tree.

Required evidence:

  • CI or flake checks must run nix build .#runner-dashboard
  • breakage in the Nix packaging path must fail a primary validation surface

Current status:

  • met through the validate workflow

Why it matters:

  • a clean derivation must be promotable as the derivation that the repo actually exports
  • source-level pnpm build is not enough to prove the flake output itself is healthy

4. Consumption Gate

The repo must say what packages.runner-dashboard is for.

Acceptable answers:

  • directly discoverable build artifact
  • canonical image input
  • both, with explicit boundaries

Current status:

  • met through gloriousflywheel-runner-dashboard-consumption-contract-2026-04-16.md

Why it matters:

  • the repo currently publishes the dashboard image through Docker Buildx, not through the Nix image output
  • without an explicit answer, promoting the derivation would create a discovery surface with no clear consumption story

5. Publication Gate

The durable publication surface must be explicit.

Required answer:

  • GHCR remains the current OCI publication surface
  • FlakeHub is only the future publication/discovery surface for promoted clean derivations, not an already-implemented path

Current status:

  • met through gloriousflywheel-runner-dashboard-publication-decision-2026-04-16.md

6. Ownership Gate

The repo must identify who owns breakage and promotion decisions for this surface.

Minimum requirement:

  • #171 / TIN-127 continues to own the contract until a real publication workflow exists

Current status:

  • met enough for planning

Current Classification

packages.runner-dashboard is:

  • the strongest current clean-derivation candidate
  • not yet a promoted clean derivation

Reason:

  • the app validation gate exists
  • the derivation gate now exists
  • the consumption gate now exists
  • the publication gate now exists

Initial Scope Decision

Curated upstream Attic pins are out of the initial clean-derivation rollout.

That means:

  • packages.attic-server is out for the first rollout
  • packages.attic-client is out for the first rollout
  • packages.default is also out because it is only an alias of packages.attic-client

Reasoning:

  • they are pinned upstream artifacts, not repo-authored product outputs
  • attic-client is primarily a bootstrap/tooling dependency
  • publishing curated upstream pins is a separate product decision from promoting the repo’s own clean derivations

Revisit only if:

  • the repo explicitly decides it wants a curated-upstream publication surface as part of the GloriousFlywheel product

Recommendation

Recommended next execution order:

  1. keep curated upstream Attic pins out of scope until the repo-native promotion path is coherent
  2. treat the current durable public release surface as image-only unless release authority changes
  3. only then revisit whether a FlakeHub publication path should expose the derivation itself
  4. only after that design any future FlakeHub publication path around packages.runner-dashboard

That release-authority change must clear gloriousflywheel-runner-dashboard-release-authority-change-gate-2026-04-16.md.

Exit Condition

  • the repo has an explicit promotion gate for its strongest clean-derivation candidate
  • initial rollout scope is clear
  • future FlakeHub work is now blocked on an intentional release-authority change instead of a vague publication question

GloriousFlywheel