GloriousFlywheel Ci Templates Capability Matrix 2026-04-18

Snapshot date: 2026-04-18

Purpose

Publish the simple reusable-workflow matrix that Queue B called for.

The goal is to stop talking about ci-templates as if it were one capability surface. The live repo actually exposes a very small reusable-workflow surface, and the two workflows do not mean the same thing.

Live Reusable Workflow Surface

On tinyland-inc/ci-templates:main, the current reusable workflows are:

• .github/workflows/js-bazel-package.yml
• .github/workflows/npm-publish.yml

There are no other reusable workflows on the default branch today.

Capability Matrix

Workflow Notes

js-bazel-package.yml

Live contract evidence:

• runner_mode supports:
  • compat
  • hosted
  • shared
  • repo_owned
• workspace_mode supports:
  • isolated
  • persistent_compat
• publish_mode supports:
  • same_runner
  • hosted_exception
• validation and publish jobs resolve runs-on from:
  • shared labels
  • repo-owned labels
  • or ["ubuntu-latest"]
• the workflow uses:
  • tinyland-inc/ci-templates/.github/actions/nix-setup@main

Interpretation:

• this is the only reusable workflow in ci-templates that currently spans hosted, shared, and repo-owned execution modes
• it is the real active template contract for current GloriousFlywheel runner adoption

npm-publish.yml

Live contract evidence:

• the workflow is reusable through workflow_call
• all inspected jobs run on ubuntu-latest
  • build-and-test
  • publish-gpr
  • publish-npm

Interpretation:

• this workflow is hosted-only today
• it should not be described as shared-capable or repo-owned-capable
• it belongs in hosted template consumer reporting, not runner adoption

Current Consumer Read

js-bazel-package.yml

Current known consumers on the active surface:

• Jesssullivan/scheduling-kit
  • repo-owned template consumer
• Jesssullivan/acuity-middleware
  • repo-owned template consumer
• tinyland-inc/tinyvectors
  • hosted template consumer

npm-publish.yml

Current known consumers on the recent scanned surface:

• tinyland-inc/vite-plugin-a11y
• tinyland-inc/tinyland-rate-limit
• tinyland-inc/tinyland-physics
• tinyland-inc/tinyland-color-utils
• tinyland-inc/tinyland-a11y-engine

Those repos are all archived and should be treated as hosted template consumers outside the active migration queue.

Important Operational Consequence

The current template surface is not:

• one mixed bundle of unknown capability
• or a broad reusable-workflow platform that still needs major discovery

It is a very small surface with one real active contract and one hosted-only package publication contract.

That means the next template decisions are narrower than they looked:

• maintain accurate mode reporting around js-bazel-package.yml
• decide whether npm-publish.yml should remain permanently hosted-only
• do not inflate runner-adoption claims from raw ci-templates usage

Documentation Gap

The current ci-templates README.md describes js-bazel-package, but does not document npm-publish.yml in the reusable workflow section.

That is a docs gap, not a capability ambiguity.

The workflow itself is still clearly hosted-only from live source.

Recommendation

Use this matrix directly in:

• Queue B planning
• orgwide enrollment reporting
• template consumer mode reporting

And use this wording:

• ci-templates currently exposes two reusable workflows on main
• only js-bazel-package.yml is runner-flexible
• npm-publish.yml is hosted-only and currently associated with archived package consumers

Exit Condition

This note can retire once:

• the capability matrix is reflected directly in public or canonical docs
• npm-publish.yml either gains explicit self-hosted modes or is declared permanently hosted-only
• ci-templates usage is no longer treated as a proxy for runner enrollment