GloriousFlywheel tinyland.dev First Patch Playbook 2026-04-16

GloriousFlywheel tinyland.dev First Patch Playbook 2026-04-16

Snapshot date: 2026-04-16

Purpose

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

GitHub owner: #210

Why tinyland.dev Goes Second

tinyland.dev is the best org-owned product-repo example in tranche 1:

  • it is a cleaner representative product repo than blahaj or lab
  • it has distinct Nix, container, and deploy workflows
  • if it uses the shared runner contract cleanly, it becomes the best reference example for other org repos

Observed Workflow Reality

From direct workflow inspection on 2026-04-16:

  • nix.yml
    • runs nix-check on ubuntu-latest
    • runs nix-build on tinyland-nix
    • still points at stale https://nix-cache.fuzzy-dev.tinyland.dev values
    • still manages Attic push configuration manually
  • container.yml
    • stays on ubuntu-latest
    • uses GitHub-hosted Buildx/GHCR flow
  • staging-deploy.yml
    • still uses CIVO_KUBECONFIG
    • still uses a Civo/S3-shaped staging path
    • is not the right first proof point for the shared runner contract

First Patch Goal

Make tinyland.dev the canonical example of an org product repo using the shared GitHub runner contract, without dragging in the old cloud-deploy path.

That means:

  1. fix the Nix runner path first
  2. move it onto current cache/runtime truth
  3. leave the staging deploy workflow out of the first migration proof

Patch 1: Normalize the Nix workflow

Target file:

  • nix.yml

Desired outcome:

  • tinyland-nix remains the shared runner label
  • stale fuzzy-dev cache URLs are removed
  • the workflow uses the current GloriousFlywheel cache/runtime contract instead of carrying older manual cache setup assumptions

Patch 2: Keep container workflow separate

Target file:

  • container.yml

Desired outcome:

  • no unnecessary self-hosted migration pressure
  • keep GHCR container publishing independent from the first shared-runner proof

Patch 3: Reclassify staging deploy as separate work

Target file:

  • staging-deploy.yml

Desired outcome:

  • clearly treat the Civo-shaped staging deploy as a separate deployment-lane migration, not as the first downstream runner-contract example

Execution Status

Current execution state on 2026-04-16:

  • nix.yml is patched in a real local checkout at /tmp/tinyland.dev/.github/workflows/nix.yml
  • the patch updates stale https://nix-cache.fuzzy-dev.tinyland.dev references to https://nix-cache.tinyland.dev/main
  • the patch moves the self-hosted nix-build job onto tinyland-inc/GloriousFlywheel/.github/actions/setup-flywheel@main
  • direct Attic push setup now uses injected ATTIC_SERVER instead of a hard-coded fuzzy-dev endpoint
  • container.yml and staging-deploy.yml remain intentionally untouched in this first pass

Verification completed for the local checkout patch:

  • workflow YAML parses cleanly
  • no stale fuzzy-dev cache references remain in the patched nix.yml
  • git diff --check passes in the local checkout
  • the patch has been pushed upstream as tinyland-inc/tinyland.dev#136

Current blocker after PR execution:

  • Lint & Typecheck was cleared by the lockfile refresh
  • the PR then exposed a broader container-build issue in ContainerFile
  • pnpm-lock.yaml now contains 23 local link:../... workspace package resolutions
  • at least tinyland-admin-validation -> tinyland-auth and tinyland-caldav-client -> tinyland-calendar are being installed as local workspace links while their package manifests still use semver ranges instead of workspace:*
  • that means the runner-contract PR is currently blocked on a repo-level internal package resolution/build-order policy decision, not on GloriousFlywheel runner setup itself

What Not To Do First

  • do not start by migrating staging-deploy.yml
  • do not use the old fuzzy-dev cache coordinates as a reference for new repos
  • do not make the canonical product-repo example depend on the residual cloud path

Acceptance Criteria

  • tinyland.dev has one clean shared-runner Nix workflow that matches the current GloriousFlywheel contract
  • the repo can be cited as the reference org product-repo consumer
  • the old staging deploy path is clearly separated from the shared-runner story
  • the PR is either green on its own merits or explicitly split from the broader internal workspace package-resolution fix

GloriousFlywheel