GloriousFlywheel

GloriousFlywheel Nix Output Candidates 2026-04-15

Snapshot date: 2026-04-15

Purpose

Enumerate the actual Nix outputs exposed by this repo and classify which ones are plausible clean-derivation candidates.

This note is intentionally narrower than the broader cache/publication contract. It is for TIN-127 and issue #171.

Companion notes:

Current Flake Facts

Direct inspection of flake.nix on 2026-04-15 shows these exported surfaces:

Packages

default -> alias of attic-client
attic-server
attic-client
container -> alias of attic-server-image
attic-server-image
attic-gc-image
container-tarball
runner-dashboard
runner-dashboard-image

Checks

formatting
statix
deadnix
attic-client-check
attic-server-check
container-check

Other Flake Outputs

devShells.default
devShells.ci
formatter
apps.default
apps.attic
apps.atticd
overlays.default
nixosModules.default

Classification Rules

For this note, a clean-derivation candidate means:

repo-facing output worth durable publication or discovery beyond mutable CI caches
not just a helper alias, validation artifact, local shell, or manual export convenience
not primarily an OCI publication concern already better served by GHCR

Candidate Matrix

Strongest Current Candidates

`packages.runner-dashboard`

Current basis:

repo-native derivation built from GloriousFlywheel sources

Why it is the strongest current candidate:

it is a real product output produced by this repo rather than a pure upstream passthrough
it can serve as the content basis for the dashboard image
it is easier to reason about as a clean derivation than the mutable cache layers around it

Current caution:

the repo does not yet document whether the standalone built dashboard output is meant to be consumed directly, or only as an image input
that current answer is now explicit in gloriousflywheel-runner-dashboard-consumption-contract-2026-04-16.md: canonical Nix image input, not current standalone public consumption surface

Conditional Candidates

`packages.attic-server`

Current basis:

upstream Attic package pinned through this repo’s flake

Why it is only conditional:

it is useful as a curated pinned infrastructure input
but it is not a GloriousFlywheel-authored output
promoting it would amount to publishing a curated upstream pin, not a unique product artifact from this repo

`packages.attic-client`

Current basis:

upstream Attic client pinned through this repo’s flake

Why it is only conditional:

it matters operationally for watch-store bootstrap and builder workflows
but it is primarily a bootstrap and tooling dependency, not a clean GloriousFlywheel product artifact
default is only an alias of this same package, so promoting default would not add clarity

OCI Publication Candidates, Not Clean-Derivation Candidates

`packages.attic-server-image`

`packages.attic-gc-image`

`packages.runner-dashboard-image`

`packages.container`

Current basis:

OCI image outputs

Why they should not be the first clean-derivation set:

OCI publication already maps more naturally to GHCR
the repo already uses GHCR in active workflows
runner-dashboard is currently published via Docker Buildx workflows, not via the Nix image output, so the primary publication contract is not yet converged on the flake image path

Important nuance:

these may still be important release artifacts
they are just not the best first answer to the clean-derivation question

Not Promotion Candidates

`packages.container-tarball`

Why not:

manual deployment helper only
convenience export, not a durable product surface

`checks.*`

Why not:

validation artifacts, not user-facing deliverables

`devShells.*`

Why not:

mutable developer and CI environments
useful for tooling, not for artifact publication

`formatter`

`apps.*`

Why not:

execution and helper entrypoints
not durable artifacts in their own right

Flake Outputs That Matter But Are Not Clean Derivations

`nixosModules.default`

Why it matters:

it is a real flake export worth eventual discovery and reuse

Why it is not a clean derivation:

it is a NixOS module surface, not a built derivation artifact

`overlays.default`

Why it matters:

useful for pinned package composition

Why it is not a clean derivation:

composition helper only

Current Recommendation

Recommended initial clean-derivation candidate set:

packages.runner-dashboard

Initial rollout scope decision:

the gate note in gloriousflywheel-runner-dashboard-promotion-gate-2026-04-15.md makes packages.runner-dashboard the only in-scope first-rollout candidate

Recommended conditional follow-on set only if the repo explicitly wants curated upstream pins in scope:

packages.attic-server
packages.attic-client

Do not treat these as the initial candidate set:

OCI image outputs
aliases
checks
devShells
manual tarball helpers

Implications For `#171`

The repo’s first realistic clean-derivation conversation should center on:

whether runner-dashboard should become a durably discoverable flake output
whether GloriousFlywheel wants to publish curated upstream Attic pins at all
how to converge the current Dockerfile-based dashboard image publication path with the existing Nix image output before claiming a coherent release story

This also means the repo is not yet ready to talk about a broad FlakeHub surface for “all Nix outputs.” The actual plausible set is much smaller.

For runner-dashboard specifically, the current durable public publication decision is image-only rather than direct derivation publication.

Exit Condition

the repo has an explicit list of real clean-derivation candidates
downstream publication planning no longer assumes every flake output is a publication target
future FlakeHub work can target a concrete output set instead of a vague category