GloriousFlywheel Contract Rollout PR Stack 2026-04-17

GloriousFlywheel Contract Rollout PR Stack 2026-04-17

Snapshot date: 2026-04-17

Purpose

Convert the contract remediation packages into a merge-order plan with clear dependencies, acceptance gates, and fallback behavior.

Companion notes:

Primary owner surfaces:

  • #210
  • #213
  • #214

Stack Principles

1. Source Proof Before Downstream Story

The source repo should prove the platform on main before downstream rollout is used as the main credibility surface.

2. Shared Contract Before Repo Cleanup

When multiple repos consume one reusable workflow, fix the reusable workflow before spending time on repo-local cleanup that the next template rev would invalidate.

3. Pilot Repos Before Broad Promotion

The template should be proven in one clean dedicated-lane repo and one hybrid repo before trying to promote the remaining hosted-template consumer.

4. Metrics Update Last

Do not update the headline adoption language before the code paths and pilot repos are actually merged.

PR 1: GloriousFlywheel Source Default-Branch Proof

Repo:

  • tinyland-inc/GloriousFlywheel

Scope:

  • add platform-proof.yml or equivalent default-branch proof workflow
  • reuse:
    • .github/actions/nix-job/action.yml
    • .github/actions/docker-job/action.yml
    • .github/actions/setup-flywheel/action.yml
  • reduce test-arc-runners.yml to soak or manual coverage if needed

Why first:

  • removes the biggest source-of-truth credibility gap
  • gives the downstream rollout a live upstream proof path to cite

Blocking dependencies:

  • none

Acceptance gate:

  • default branch visibly proves:
    • tinyland-docker
    • tinyland-nix
    • tinyland-nix-heavy

Safe fallback:

  • keep test-arc-runners.yml as manual soak lane if the new proof workflow needs iteration

PR 2: ci-templates js-bazel-package V2 Compatibility Introduction

Repo:

  • tinyland-inc/ci-templates

Scope:

  • add explicit:
    • runner_mode
    • workspace_mode
    • optional publication-mode policy
  • integrate setup-flywheel for self-hosted modes
  • add isolated workspace support
  • retain temporary compatibility mode for existing consumers

Why second:

  • downstream pilots depend on the new contract surface
  • changing pilots first would either duplicate work or cement the old contract

Blocking dependencies:

  • none strictly
  • but easier to explain after PR 1 exists

Acceptance gate:

  • existing consumers can still run in compatibility mode
  • V2 path exists for one clean dedicated-lane pilot

Safe fallback:

  • retain V1-compatible defaults temporarily while pilots move

PR 3: scheduling-kit V2 Pilot

Repo:

  • Jesssullivan/scheduling-kit

Scope:

  • switch CI and publish to the V2 template contract
  • keep repo-owned dedicated lane explicit
  • move off persistent-workspace assumptions

Why third:

  • cleanest verified dedicated-lane downstream proof
  • best first pilot for the new shared contract

Blocking dependencies:

  • PR 2

Acceptance gate:

  • CI and publish remain self-hosted
  • no inspected hosted authority remains in the package path
  • workspace behavior is isolated or explicitly documented

Safe fallback:

  • keep the repo on compatibility mode until V2 is stable

PR 4: acuity-middleware V2 Hybrid Pilot

Repo:

  • Jesssullivan/acuity-middleware

Scope:

  • move package CI and publish to V2
  • keep deploy-modal.yml as a named hosted exception unless separately changed

Why fourth:

  • proves the contract works even when one hosted deploy exception remains
  • directly addresses the workspace hygiene defect that surfaced in this repo

Blocking dependencies:

  • PR 2
  • ideally after PR 3 proves the clean dedicated-lane path

Acceptance gate:

  • package path is self-hosted and isolated
  • hosted deploy remains explicit and narrow

Safe fallback:

  • keep hosted deploy untouched
  • revert only the template-consumer path if V2 introduces instability

PR 5: tinyvectors Decision PR

Repo:

  • tinyland-inc/tinyvectors

Scope:

one of two outcomes:

  • promote to verified self-hosted use with explicit runner intent
  • or encode hosted intent explicitly and stop implying runner adoption

Why fifth:

  • this repo is the control case for whether template consumers can be promoted cleanly

Blocking dependencies:

  • PR 2

Acceptance gate:

  • the repo stops being ambiguous

Safe fallback:

  • leave it hosted intentionally and remove it from runner-adoption reporting

PR 6: Reporting And PM Surface Cleanup

Repo:

  • tinyland-inc/GloriousFlywheel

Scope:

  • update current PM language and status surfaces to use:
    • runner dogfood count
    • hosted cache consumer count
    • hosted template consumer count
    • hybrid count

Why last:

  • metrics should follow merged reality, not planned intent

Blocking dependencies:

  • PR 1
  • PR 2
  • at least PR 3 or PR 4

Acceptance gate:

  • no PM surface uses one undifferentiated adoption number

Parallelism Rules

Can Run In Parallel

  • PR 1 and PR 2 can overlap if needed
  • PR 3 and PR 4 can overlap after PR 2 merges

Should Not Run In Parallel

  • multiple incompatible revisions of js-bazel-package.yml
  • repo pilots that depend on different incompatible versions of the same template

Best Sequence If Keeping Review Load Low

  1. PR 1
  2. PR 2
  3. PR 3
  4. PR 4
  5. PR 5
  6. PR 6

Blocking Risks

Risk A: Source Repo Proof Still Feels Synthetic

If PR 1 creates a workflow that only runs contrived echo checks, it will not repair the credibility gap.

Required response:

  • keep the proof path light
  • but ensure it runs one real command per lane

Risk B: Template V2 Tries To Solve Everything At Once

If PR 2 tries to redesign build, publish, runner policy, and docs all at once, review load will spike and pilots will stall.

Required response:

  • keep PR 2 focused on:
    • runner intent
    • workspace intent
    • self-hosted contract wiring

Risk C: Hybrid Repos Re-Pollute The Metrics

If acuity-middleware or tinyland.dev are reported as clean runner adoption after only partial cleanup, the reporting model regresses.

Required response:

  • keep hybrid classification until the hosted authority path is explicitly removed or bounded

Verification Matrix

PR Main verification
PR 1 default-branch shared-runner proof jobs execute successfully
PR 2 template supports explicit runner and workspace modes without breaking compatibility
PR 3 verified dedicated-lane repo runs cleanly on V2
PR 4 hybrid repo runs clean package path on V2 while hosted deploy remains narrow
PR 5 hosted-template ambiguity is removed
PR 6 PM surfaces report tiers, not one flattened adoption number

Recommendation

The shortest honest rollout is:

  1. prove the platform in the source repo
  2. fix the one shared downstream contract
  3. prove that contract in one clean repo and one hybrid repo
  4. only then update the story everywhere else

That keeps execution aligned with the actual leverage points instead of the loudest repos.

GloriousFlywheel