GloriousFlywheel MassageIthaca Dogfood Playbook 2026-04-17

GloriousFlywheel MassageIthaca Dogfood Playbook 2026-04-17

Snapshot date: 2026-04-17

Purpose

Capture the clearest current proof that the GloriousFlywheel dogfood runner structure is real, but still incomplete at the beta-validation edge.

GitHub owner: #210

Why MassageIthaca Matters

Jesssullivan/MassageIthaca is not just another downstream repo:

  • it already uses a repo-owned honey runner lane rather than only the shared tinyland-nix or tinyland-docker labels
  • it is a real product repo with deploy, smoke, and Playwright-style beta validation instead of only build-only CI
  • it exposes the remaining contract gap cleanly inside one repo: core CI is already dogfooded on self-hosted runners, while beta validation still escapes to GitHub-hosted runners

Observed Workflow Reality

From direct workflow, variable, and run inspection on 2026-04-17:

  • .github/workflows/ci.yml
    • test-unit, theme-validate, check, and build all use: runs-on: ${{ fromJSON(vars.PRIMARY_LINUX_RUNNER_LABELS_JSON || '["ubuntu-latest"]') }}
    • repository variable PRIMARY_LINUX_RUNNER_LABELS_JSON is set to: ["self-hosted","Linux","X64","honey","massageithaca"]
    • smoke-beta and e2e-beta still use plain ubuntu-latest
  • dev/main run 24561967515
    • green: Theme Validation (71812543065), Unit Tests (71812543084), Type Check (71812629814), and Build (71812629852)
    • failed before runner assignment: E2E Tests (Beta) (71812744601) and Smoke Test (Beta) (71812744629)
    • GitHub’s job annotation says those jobs were not started because recent account payments failed or the spending limit needs to be increased
  • newer PR run 24562197983 for MassageIthaca#186 is green, so the repo is still moving and the blocker is not a fresh application regression
  • theme-validate already succeeds on the repo-owned runner lane with Playwright Chromium install, which shows the remaining problem is narrower than “Playwright cannot run on self-hosted runners”
  • e2e-beta still uses npx playwright install --with-deps chromium, which is a strong sign that browser/bootstrap assumptions still lean on the GitHub-hosted image path

Current Problem Shape

The problem is not runner registration and it is not app logic.

The actual problem is that the repo-owned dogfood story stops too early:

  • primary CI already uses dedicated self-hosted honey labels
  • beta post-deploy validation still depends on GitHub-hosted ubuntu-latest
  • GitHub billing can therefore block the visible promotion path even when the self-hosted dogfood lane is healthy

First Patch Goal

Treat MassageIthaca as proof that GloriousFlywheel must own post-deploy beta validation too, not just pre-deploy CI.

That means:

  1. move smoke-beta and e2e-beta onto the same repo-controlled runner-label variable or another explicit repo-owned dogfood selector
  2. make browser/bootstrap expectations explicit for self-hosted beta checks instead of inheriting ubuntu-latest image folklore
  3. keep GitHub-hosted fallback, if still needed, as explicit compatibility rather than the authoritative dogfood path

MassageIthaca is now the cleanest repo-owned dogfood signal for the next runner-contract patch because:

  • it already proves the dedicated honey lane is live
  • its current failure is isolated to hosted beta escape hatches
  • it lets GloriousFlywheel tighten the dogfood contract without confusing this work with the heavy-Nix lane or GitLab compatibility work

What Not To Do First

  • do not call this a new application regression when the failed jobs never started
  • do not use GitHub billing noise as evidence that the self-hosted dogfood lane is unstable
  • do not patch unrelated green jobs before closing the hosted beta escape hatch
  • do not describe ubuntu-latest beta jobs as if they were the actual GloriousFlywheel dogfood contract

Acceptance Criteria

  • GloriousFlywheel docs cite MassageIthaca as a live repo-owned dogfood surface
  • dogfood planning distinguishes healthy primary self-hosted CI from billing-sensitive hosted beta validation
  • follow-on patch work is scoped toward beta validation runner authority and explicit browser/bootstrap assumptions

GloriousFlywheel