GloriousFlywheel blahaj First Patch Playbook 2026-04-16

GloriousFlywheel blahaj First Patch Playbook 2026-04-16

Snapshot date: 2026-04-16

Purpose

Define the first concrete downstream patch target for tinyland-inc/blahaj under #210.

GitHub owner: #210

Why blahaj Goes Fourth

blahaj is the strongest infra-adjacent downstream repo in tranche 1:

  • it uses shared runner labels extensively
  • it is also the cluster-ops repo for the actual platform environment
  • that means the first job is boundary clarity, not pretending every workflow is a generic downstream consumer example

Observed Workflow Reality

From direct workflow inspection on 2026-04-16:

  • build-images.yml
    • uses tinyland-dind
    • is the clearest stable shared-runner consumer lane
  • opentofu.yml, infra-stacks.yml, mcp-services.yml, domain-pipeline.yml, domain-services.yml, liqo.yml, and liqo-deploy.yml
    • use shared labels, but they are fundamentally cluster-ops workflows
    • still carry Civo- and RustFS-backed cluster-management assumptions
    • should not be treated as the canonical downstream runner contract example
  • mail and domain health workflows are mixed, but they still sit closer to service operations than to the portable runner-contract story

First Patch Goal

Make the repo boundary explicit:

  1. identify the stable shared-runner consumer lane
  2. keep cluster-ops ownership separate
  3. avoid treating the whole repo as a standard downstream runner consumer

Current Execution Status

Current execution state on 2026-04-16:

  • build-images.yml is patched in a real local checkout at /tmp/blahaj/.github/workflows/build-images.yml
  • the patch adds an explicit note that image builds are the stable shared-runner consumer surface in blahaj
  • the patch also states that OpenTofu/domain workflows remain cluster-ops ownership, not the canonical downstream runner example
  • git diff --check passes in the local checkout
  • workflow YAML parses cleanly

What Not To Do First

  • do not rewrite the OpenTofu/domain workflows as if they were ordinary downstream app CI
  • do not treat Civo- and backend-authority cleanup in blahaj as part of the same lane as the runner-adoption kit
  • do not use blahaj as the first canonical product-repo example

Acceptance Criteria

  • blahaj has an explicit written boundary between stable shared-runner consumption and cluster-ops ownership
  • the repo is classified correctly in tranche 1
  • future blahaj cleanup can proceed without confusing rollout/platform-ops work with the generic downstream runner contract

GloriousFlywheel