GloriousFlywheel

GloriousFlywheel MassageIthaca Branch Authority Decision 2026-04-18

Snapshot date: 2026-04-18

Purpose

Resolve the current reporting ambiguity around Jesssullivan/MassageIthaca.

This repo is one of the strongest downstream GloriousFlywheel dogfood proofs, but it currently has split branch authority:

GitHub default branch: main
active product branch: dev/main

That branch split directly affects runner-adoption reporting.

Current Evidence

Branch And PR State

default branch is main
Jesssullivan/MassageIthaca#189 merged into dev/main on 2026-04-17
open PR #216 promotes dev/main into main
open PR #217 reconciles main-only drift back into dev/main

That means the repo is currently running a two-way reconciliation loop:

dev/main -> main
main -> dev/main

This is strong evidence that main and dev/main are not just staging and release labels. They are currently separate authority surfaces.

Workflow Split

main currently shows a fully hosted ci.yml:

every scanned runs-on line is ubuntu-latest

dev/main currently shows the repo-owned runner contract:

runs-on: ${{ fromJSON(vars.PRIMARY_LINUX_RUNNER_LABELS_JSON || '["ubuntu-latest"]') }}
Playwright install and beta and alpha validation run on that same lane

The live repo variable is:

["self-hosted","Linux","X64","honey","massageithaca"]

Live Runtime Reality

Recent dev/main runs are queueing because the repo-owned pet runners are not available.

So the current problem is not that the repo lacks self-hosted intent. The problem is that the active product branch uses a branch-local runner contract that the default-branch census does not see.

What This Means

For Adoption Reporting

It is misleading to classify MassageIthaca using default-branch-only logic.

If default branch alone is used:

the repo looks hosted-only

If active product authority is used:

the repo is a real repo-owned runner consumer

So the repo is currently a branch-authority exception.

For Platform Claims

This repo should not be cited as:

“default branch proves repo-owned runners”

It can honestly be cited as:

“active product branch proves repo-owned runners”

That distinction matters because the platform adoption denominator is already small enough that one repo changes the narrative.

Options

Option A: Switch Default Branch To `dev/main` Now

Pros:

makes reporting line up immediately
makes the branch that actually carries the runner contract visible to the GitHub default-branch census

Cons:

this is risky while #216 and #217 are both open
it changes PR defaults and release ergonomics in the middle of a promotion split

Recommendation:

not the best immediate move

Option B: Keep `main` Default But Explicitly Classify The Repo As A Branch-Authority Exception

Pros:

accurate immediately
low-risk
does not disturb the current promotion lane while it is still reconciling

Cons:

reporting remains slightly more complex
repo-level truth still depends on branch caveats

Recommendation:

best immediate move

Option C: Collapse The Split Quickly And Return To One Authority Branch

Pros:

best long-term shape
removes the reporting caveat entirely

Cons:

blocked by real branch drift today
requires resolving #216 conflict and stabilizing the promotion model

Recommendation:

best medium-term target, not best immediate move

Recommendation

Use Option B immediately and Option C as the follow-on.

That means:

classify MassageIthaca as a branch-authority exception in GloriousFlywheel reporting right now
count dev/main, not main, for runner-adoption truth while the split exists
do not switch the default branch in the middle of the current reconciliation cycle
treat #216 and #217 resolution as the real prerequisite for removing the exception

Exit Condition

This note can retire once all of these are true:

one branch is clearly authoritative for both product and CI reporting
the repo-owned runner contract is visible on that authoritative branch
adoption reporting no longer needs a MassageIthaca caveat