GloriousFlywheel MassageIthaca Branch Authority Decision 2026-04-18

GloriousFlywheel MassageIthaca Branch Authority Decision 2026-04-18

Superseded on 2026-04-23 by the pooled substrate dogfood reset.

Correction on 2026-04-23: Repo-specific runner labels such as massageithaca-* are not the intended GloriousFlywheel architecture. Treat earlier repo-shaped lane language in this note as historical drift, not as the active platform direction.

Additional correction on 2026-04-24: Preserve this note only for branch-authority and runtime evidence. The older repo-owned runner framing and branch-exception recommendation are historical workarounds, not the active pooled-substrate direction.

Snapshot date: 2026-04-18

Correction on 2026-04-24:

  • the later Phase 2 live test showed the historical multilabel array ["self-hosted","Linux","X64","honey","massageithaca"] was not broker-assigned
  • the current proven repo variable is ["massageithaca"]
  • treat the older array in this note as historical intent, not current authority truth

Purpose

Resolve the historical reporting ambiguity that existed around Jesssullivan/MassageIthaca.

This repo was a useful downstream evidence point, but it also captured the wrong architectural vocabulary. Keep it for the branch split facts, not as a template for repo-local runner strategy.

At the time of this snapshot, the repo had 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-local runner contract that was then in use:

  • 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-local pet-runner setup was not available.

So the current problem is not that the repo lacks self-hosted intent. The problem is that the active product branch used a branch-local runner setup that the default-branch census did 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 downstream repo with branch-local runner configuration

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”
  • “repo-specific runner labels are a valid product surface”

It can honestly be cited as:

  • “active product branch contained repo-local runner configuration during the false-turn period”

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

Historical Recommendation, Now Superseded

At the time, the least disruptive reporting move was Option B immediately and Option C as the follow-on.

That recommendation is now superseded by the pooled-substrate reset. The lasting lesson is narrower: branch authority may affect evidence gathering, but it should not be used to preserve repo-shaped runner strategy.

That means:

  1. classify MassageIthaca as a branch-authority exception in GloriousFlywheel reporting right now
  2. count dev/main, not main, for runner-adoption truth while the split exists
  3. do not switch the default branch in the middle of the current reconciliation cycle
  4. 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 shared capability-class-backed contract is visible on that authoritative branch, or any temporary exception is explicitly marked as debt
  • adoption reporting no longer needs a MassageIthaca caveat

GloriousFlywheel