GloriousFlywheel Broader Downstream Rollout Tranche 2 2026-04-22

Snapshot date: 2026-04-22

Purpose

Name the first post-tranche-1 rollout set explicitly so broader downstream rollout no longer depends on vague follow-on language.

Later on the same day, the active runner-execution subset narrowed again after live queue refresh and runner-inventory checks. See GloriousFlywheel Rollout Execution Refresh 2026-04-22 for the tighter execution read.

This note is intentionally bounded:

• it starts from the live orgwide enrollment queue categories
• it names the next rollout set by repo and by rollout track
• it keeps blocked surfaces honest instead of pretending the next tranche is a uniform promotion list

Inputs

• config/orgwide-enrollment-queue.json
• docs/current-state.md
• docs/guides/adoption-quickstart.md
• docs/runners/downstream-migration-checklist.md
• docs/research/gloriousflywheel-orgwide-enrollment-reality-check-2026-04-18.md

Named Post-Tranche-1 Rollout Set

Promotion Candidates

• Jesssullivan/tinyclaw
• Jesssullivan/remote-juggler

These are the repos that should consume actual rollout energy next, not because they are already proved, but because they are active enough to justify an explicit keep-hosted versus shared-runner decision.

Hybrid-Authority Cleanup

• tinyland-inc/tinyland.dev

This repo is not a promotion candidate in the same sense as the two repos above. It already has real shared authority, but the broader authoritative workflow story is still hybrid across Nix, container, publish, and deploy paths. It stays in the rollout set because it still shapes public rollout truth.

Platform Prerequisite

• tinyland-inc/betterkvm

This repo also stays in the rollout set, but explicitly as blocked work rather than as an immediate promotion candidate. The exit condition is still proving real shared-runner reachability instead of leaving the repo queued behind zero accessible self-hosted runners.

What Is Not In This Rollout Set

The following queue categories should not be described as tranche-2 rollout:

• template_contract_cleanup
• keep_hosted

Those surfaces matter to reporting honesty, but they are not the next repos that should consume active migration energy.

Repeatable Operator Path

The operator path beyond tranche-1 is now:

1. run just orgwide-enrollment-scoreboard
2. run just orgwide-enrollment-queue
3. classify the repo as promotion candidate, hybrid cleanup, platform prerequisite, template cleanup, or keep-hosted
4. apply the shared checklist in Downstream Migration Checklist
5. reflect the result back into canonical docs and tracker surfaces

This is the key shift from the earlier tranche-1 era: the next rollout set is now an operator-readable queue with named exit conditions, not just an issue comment about “more rollout later.”

Honest Boundary

This note does not claim that tranche-2 is already migrated.

It claims something narrower and more important:

• the next rollout set is now explicit
• the blocked surfaces are named honestly
• the repeatable migration path no longer ends at tranche-1