GloriousFlywheel Tinyland.dev Claim Classification 2026-04-18

GloriousFlywheel Tinyland.dev Claim Classification 2026-04-18

Snapshot date: 2026-04-18

Purpose

Classify what tinyland-inc/tinyland.dev currently proves for the GloriousFlywheel story.

This repo has been easy to overstate because it does have real GloriousFlywheel runner and cache usage, but those lanes do not currently own the whole authoritative CI and deploy surface.

Current Evidence

Default branch is main.

Workflow Reality On main

Hosted authority paths:

  • bazel.yml
    • all scanned jobs are runs-on: ubuntu-latest
  • container.yml
    • build path is runs-on: ubuntu-latest
  • publish.yml
    • publish path is runs-on: ubuntu-latest
  • staging-deploy.yml
    • all scanned jobs are runs-on: ubuntu-latest

GloriousFlywheel-backed path:

  • nix.yml
    • one path is runs-on: tinyland-nix
    • that path configures Attic directly and pushes cache artifacts

PR State

Open PR tinyland-inc/tinyland.dev#136 is explicitly scoped as a narrow runner contract pass:

  • replace stale cache coordinates
  • use setup-flywheel for the self-hosted tinyland-nix build path
  • leave container.yml and staging-deploy.yml out of scope

That is useful evidence because it makes the current repo intent explicit:

  • the self-hosted Nix lane is being improved
  • the hosted authority paths are not yet being migrated

Live Interpretation

tinyland.dev is currently proving:

  • real Attic-backed Nix runner usage
  • some GloriousFlywheel runner value on a real product repo

It is not currently proving:

  • homogeneous shared ARC adoption
  • authoritative CI ownership by GloriousFlywheel runners
  • authoritative deploy ownership by GloriousFlywheel runners

Classification Options

Option A: Call It A Runner-Dogfood Repo

This is too generous today.

Why:

  • Bazel CI is still hosted
  • container authority is still hosted
  • staging deploy authority is still hosted

This framing would overstate convergence.

Option B: Call It A Cache-First Hybrid Repo

This is the most accurate current classification.

Why:

  • the tinyland-nix lane is real
  • Attic use is real
  • the repo demonstrates acceleration and builder value
  • but the core authority paths are still mixed

This framing preserves the useful proof without pretending runner convergence has happened already.

Option C: Remove It From The Runner Story Entirely

This is too harsh.

Why:

  • real self-hosted and cache-backed usage does exist on main

The repo is not hosted-only. It is hybrid.

Recommendation

Use Option B.

tinyland.dev should currently be described as:

  • a cache-first hybrid repo
  • a real shared-runner consumer on a secondary Nix lane
  • not yet a clean runner-dogfood repo

What Must Change Before The Claim Can Upgrade

To promote tinyland.dev into a stronger runner-adoption claim, at least one of these must happen:

  1. move Bazel CI onto GloriousFlywheel-backed runners
  2. move staging deploy authority onto GloriousFlywheel-backed runners
  3. define the hosted paths as durable exceptions and narrow the claim to the Nix builder lane only

Without one of those changes, the repo should stay in the hybrid bucket.

Practical Near-Term Recommendation

Do not spend reporting capital calling tinyland.dev a converged runner repo.

Instead:

  • keep it in the GloriousFlywheel story as a cache and Nix builder canary
  • keep it out of the “clean runner enrollment” count
  • only promote the classification after #136 is resolved and the repo decides whether Bazel and deploy authority are actually meant to move

Exit Condition

This note can retire once tinyland.dev is one of these clearly:

  • a clean runner-dogfood repo
  • a clean cache-first hybrid-by-policy repo
  • a hosted repo that only consumes GloriousFlywheel acceleration indirectly

GloriousFlywheel