Multi-Repo Layout

Multi-Repo Layout

This document describes the repo layout that matters today, plus the older compatibility-era layout that still explains some surviving files and docs.

Current Primary Layout

Current Repository Roles

GloriousFlywheel

  • Host: GitHub (tinyland-inc/GloriousFlywheel)
  • Role: primary source of truth for the runner platform, cache surfaces, dashboard, and operator tooling
  • Current deployment target: the honey cluster
  • Current product boundary: GitHub-first, tailnet-first, cache-backed dev+CI substrate from this repo
  • Does not own: personal-account GitHub App media, private owner tfvars, or repo-scoped compatibility anchors as product structure

Implementation Overlays

  • Role: owner-specific deployment repositories or config packages that consume GloriousFlywheel modules and carry private implementation facts
  • Current Tinyland authority: tinyland-inc/tinyland-infra, with PR #2 merged for the Honey overlay repair
  • Current Jess authority: Jesssullivan/jesssullivan-infra, with PR #2 merged for the initial personal-boundary overlay and PR #4 merged for the core-pin refresh
  • Current gap: the selected Jess personal-boundary ARC residue has been rehomed and reconciled, but compatibility-lane retirement and capacity policy across owner-distinct scale sets remain explicit follow-up
  • Future examples: another tenant’s on-prem deployment config
  • Allowed contents: GitHub App installation media, tfvars, backend config, tenant cache views, private endpoint names, and operator access details
  • Not allowed as product claim: repo-specific runner labels or per-repo runner products

Implementation overlays may point at the same honey backend substrate when the cache, namespace, secret, and tenant boundaries are explicit.

Downstream Consumers And Canaries

  • Examples:
    • tinyland-inc/lab
    • tinyland-inc/tinyland.dev
    • tinyland-inc/blahaj
    • Jesssullivan/XoxdWM
    • Jesssullivan/yt-text
  • Role: exercise the shared runner contract, bootstrap rules, cache contract, and migration kit on real repos outside GloriousFlywheel itself. They are downstream beneficiaries, not the source-repo dogfood integrity criterion.

Compatibility Surfaces

The repo still contains compatibility paths for:

  • GitLab-oriented runner and dashboard control paths
  • Codeberg and cross-forge documentation
  • historical overlay-oriented deployment notes

These are not the primary operating model anymore.

Current CI And Deployment Flow

  1. Work is developed and applied from this repo.
  2. The operator path uses repo-managed Just/Nix entrypoints such as just tofu-init, just tofu-plan, and just tofu-apply.
  3. honey is the only physical cluster target.
  4. Downstream repos consume runner labels, composite actions, and shared cache conventions from GloriousFlywheel.

Historical Overlay And GitLab Context

Earlier versions of the system were organized around:

  • a public upstream repo
  • private overlays
  • GitLab-driven CI and HTTP state
  • mirrored or forwarded GitHub-to-GitLab repository flows

That context still matters for:

  • reading older docs
  • understanding compatibility paths
  • interpreting the surviving archived gf-overlay state surface

It should not be treated as the current primary repo layout. The current overlay boundary is narrower: deployment facts belong outside the core product repo, while runner taxonomy remains shared capability classes.

GloriousFlywheel