GloriousFlywheel Tier Scorecard And Template Remediation 2026-04-17

Snapshot date: 2026-04-17

Purpose

Take the exception register and repo matrix one step further:

• score the current active repo set by evidence tier
• identify the highest-leverage contract debt
• define the first two promotion packages that would materially improve the scorecard

Companion notes:

• gloriousflywheel-exception-register-and-promotion-rules-2026-04-17.md
• gloriousflywheel-active-owned-repo-adoption-board-2026-04-17.md
• gloriousflywheel-wave0-wave1-classification-matrix-2026-04-17.md

Active Set Scorecard

This scorecard uses the current active repo set from the adoption board:

• 8 Wave 0 repos
• 6 Wave 1 repos
• 14 active repos total

Strict scoring rule:

• use the current authoritative workflow surface
• score the default branch unless the repo is visibly being driven through a different named authority branch
• do not count feature-branch-only or manual-only proof as routine adoption

Tier Distribution

Strict Current-State View

Near-Term View After The Known MassageIthaca Promotion

If Jesssullivan/MassageIthaca#189 lands cleanly on the active product branch, the score becomes:

• Tier 4: MassageIthaca
• Tier X drops from 6 to 5

That is the clearest single downstream promotion currently visible.

What The Scorecard Means

1. Real Runner Dogfood Is Still Small

Strict current-state score after verifying repo-variable-backed dedicated lanes:

• Tier 3 plus Tier 4 repos: 3 of 14
• that is about 21% of the active set

Near-term optimistic score after the known MassageIthaca promotion:

• Tier 3 plus Tier 4 repos: 4 of 14
• that is about 29% of the active set

That is the honest answer to “how close are we to the promise?” for active repos.

2. The Middle Of The Program Is Not Self-Hosted Yet

The largest block that can be moved without inventing new infrastructure is:

• Tier 1 hosted cache consumers: 3
• Tier 2 hosted template consumers: 1
• Tier X hybrids with already-real self-hosted lanes but unresolved exceptions: 6

That means the next gains come from two different directions:

• lifting hosted cache and template repos into self-hosted use
• collapsing hybrid repos into cleaner contract shapes

3. The Biggest Reporting Risk Is Hybrid Overstatement

Tier X is currently 6 repos.

Those are the easiest repos to overstate in status reports because they contain real platform usage and real exceptions in the same surface.

That group includes both:

• the source repo itself
• named product dogfood and canary repos

The Highest-Leverage Debt Surface

That surface is tinyland-inc/ci-templates.

Observed blast radius from live repo inspection:

• js-bazel-package.yml is imported by:
  • tinyvectors
  • scheduling-kit
  • acuity-middleware
• live repo-variable inspection now shows:
  • scheduling-kit has a repo-specific self-hosted label variable
  • acuity-middleware has a repo-specific self-hosted label variable
  • tinyvectors does not show a repo-level variable today
• tinyvectors currently imports the shared template without passing runner labels in workflow code
• npm-publish.yml exists as a separate hosted-first workflow surface

This is small enough to fix quickly and important enough to move multiple repos at once.

Template Contract Debt

1. Hosted Fallback Is The Default

js-bazel-package.yml currently defaults runner_labels_json to ["ubuntu-latest"].

That means:

• a repo can look “platform-aligned” because it imports the shared workflow
• while still being fully hosted unless a repo variable or explicit input is present

This is acceptable as a migration bridge.

It is not acceptable as a long-term adoption metric.

2. Persistent Workspace Hygiene Is Still Encoded In The Template

The shared workflow uses:

• actions/checkout with clean: false
• repo-provided cleanup_paths
• best-effort chmod plus rm -rf

That means the template currently spreads the old self-hosted workspace model instead of replacing it.

3. The Template Does Not Integrate The Platform Contract

js-bazel-package.yml currently does not use:

• setup-flywheel
• explicit self-hosted cache injection
• a standardized per-job scratch workspace
• explicit separation between hosted publish requirements and self-hosted build requirements

So even when the template runs on self-hosted runners, it is not expressing the GloriousFlywheel contract clearly.

4. The Publish Path Is Still Mixed By Environment

The template already special-cases npm provenance on hosted versus self-hosted via runner.environment.

That is reasonable, but it means publication behavior is already environment dependent.

The repo should make that dependency explicit in policy instead of letting it sit as incidental shell logic.

Promotion Package A: Source Repo Self-Dogfood

Goal

Make GloriousFlywheel itself prove the normal platform contract on a normal default-branch path.

Why This Matters

Right now the source repo splits proof between:

• default-branch hosted validation
• partial shared-runner app checks
• branch-gated ARC runner proof

That weakens every downstream claim.

Smallest Useful Package

1. create or promote one default-branch workflow that runs on:
   • tinyland-docker
   • tinyland-nix
   • tinyland-nix-heavy
2. move the current test-arc-runners.yml assertions into that routine path:
   • Nix bootstrap
   • cache endpoint injection
   • heavy-lane basic validation
3. keep hosted utility and publication paths visibly separate as exceptions:
   • docs
   • external link checking
   • release publication
   • image builds if they still need hosted authority

Expected Scorecard Effect

• does not change repo count immediately
• but removes the biggest credibility gap in the whole program

Promotion Package B: js-bazel-package V2

Goal

Turn the shared JS and Bazel package workflow from a migration bridge into a real platform contract.

Smallest Useful Package

1. require explicit runner intent
   • runner_mode: hosted | shared | repo_owned
   • keep runner_labels_json as an override, not as the primary policy input
2. remove persistent workspace dependence
   • use actions/checkout with clean behavior restored
   • or stage work into a per-job path under $RUNNER_TEMP
3. add explicit platform integration for self-hosted modes
   • call setup-flywheel
   • define cache or scratch paths predictably
4. split build validation from publication authority
   • allow build and package validation on self-hosted lanes
   • keep hosted publish as a named policy exception when provenance or hosted token flows still require it

First Pilot Repos

• Jesssullivan/acuity-middleware
• Jesssullivan/scheduling-kit

Reason:

• both already use the template
• both already express runner indirection
• both currently inherit the hygiene defect directly

Expected Scorecard Effect

If the template is fixed and both repos stay on their verified repo-owned self-hosted lanes:

• Tier counts do not change much immediately
• but one Tier 4 repo and one Tier X hybrid repo become clean contract proofs
• that is still the biggest multi-repo quality gain currently available from one shared change

If the same template then promotes tinyvectors onto verified self-hosted use:

• Tier 2 drops from 1 to 0
• Tier 4 rises from 1 to 2
• runner-dogfood score moves from 3/14 to 4/14 even before counting MassageIthaca

Secondary Promotion Packages

These matter, but they should follow the two packages above.

tinyland.dev

Promotion condition:

• move authoritative product CI off ubuntu-latest

Why second, not first:

• the repo is important, but it is still mixed across product CI, staging deploy, Nix package builds, and infra concerns

betterkvm

Promotion condition:

• move default-branch Nix CI from hosted to tinyland-nix

Why second, not first:

• it is a clean hosted cache consumer, but less leveraged than fixing the template or the source repo

Recommended Metric Model

Stop reporting one adoption number.

Use these four numbers instead:

1. real runner dogfood repos
   • Tier 3 and Tier 4 only
2. hosted cache consumers
   • Tier 1
3. hosted template consumers
   • Tier 2
4. hybrid exception repos
   • Tier X

That model makes overstatement harder and promotion easier to reason about.

Recommendation

If only two engineering moves happen next, they should be:

1. promote source-repo self-dogfood onto a default-branch proof path
2. replace js-bazel-package.yml with a real self-hosted contract and pilot it in acuity-middleware and scheduling-kit

Those two moves would improve both the real platform and the honesty of the platform story at the same time.