Bzlmod Topology

Bzlmod Topology

This document describes the current Bazel module shape for GloriousFlywheel.

The short version:

  • GloriousFlywheel is operated as a cache-backed dev+CI substrate from this repository
  • the Bazel module name still remains attic-iac for compatibility
  • implementation overlays are the current ownership boundary for private deployment facts such as GitHub App installs, tfvars, backend settings, and operator topology
  • the older symlink-merge overlay machinery is historical and compatibility context, not the current primary adoption story

Current Topology

Today the primary Bazel shape is one module that contains:

  • OpenTofu validation and packaging rules
  • the SvelteKit dashboard app
  • documentation
  • runner and cache-related build tooling

The repo product identity is GloriousFlywheel. The Bazel module name is still attic-iac only because the repo has not yet completed a formal downstream rename and compatibility cutover.

Module Dependency Graph

Compatibility Module Name

The repo still declares:

module(name = "attic-iac", version = "0.1.0")

That name should currently be read as a compatibility artifact, not as the current product name or recommended public framing.

Public docs and BUILD metadata should describe the repo as GloriousFlywheel even while the Bazel module name remains unchanged for compatibility.

Implementation Overlay Boundary

The active implementation-overlay story is not “fork the product per repo.” It is a separation of reusable substrate code from owner-specific deployment facts.

Core GloriousFlywheel owns:

  • reusable OpenTofu modules
  • shared runner capability classes
  • cache attachment contracts
  • composite actions and examples
  • product and operator docs

Implementation overlays own:

  • GitHub App installation IDs and private keys
  • owner or organization-specific githubConfigUrl values
  • tfvars and backend state settings
  • private endpoints, topology, and operator access details

This is the correct place to solve the tinyland-inc versus jesssullivan GitHub auth gap. The designated overlay repositories are now:

  • tinyland-inc/tinyland-infra for Tinyland Honey owner configuration; its overlay authority PR #2 merged at 4b31f6ddf12033cbe52e2e7192649295cf2bc473.
  • Jesssullivan/jesssullivan-infra for Jess personal-boundary owner configuration; PR #2 merged the initial implementation overlay and PR #4 refreshed its core pin at 0c6490048be94806f612f4cbf5903a7a3b44d91a.

Both overlays currently pin selected stable GloriousFlywheel core commit 637b7167c400a842cdc7af0709b2251c0542a48a, and strict enrollment preflight passes for both. The overlays may point at the same backend substrate when tenant/cache boundaries and secret ownership are explicit. Owner-distinct ARC scale-set names solve GitHub App registration scope; they are not repo-specific workflow labels and they are not a global capacity policy by themselves. The #421/TIN-568 live ARC residue disposition is complete for the six selected Jess personal-boundary compatibility releases; remaining work is GitHub #412 compatibility-lane retirement, not Bzlmod auth discovery. TIN-627 records the shared-label capacity boundary and keeps it guarded by diagnostics.

Bzlmod helps package that split. It does not create a GitHub personal-account runner group or justify repo-specific runner labels.

Optional Downstream Consumption

If a downstream Bazel consumer still depends on this repo as a module, the current compatibility form is:

bazel_dep(name = "attic-iac")

That should be treated as a narrow consumer path. The canonical implementation-overlay story is about deployment ownership, not downstream repos becoming their own runner products.

New consumers should start from the flake/devshell, runner, and cache contract: enter through direnv or nix develop, attach caches through the documented environment variables, and run just cache-contract-strict before treating Bazel as GloriousFlywheel-backed.

Why The App And Build Tooling Stay In One Module

npm_translate_lock (from rules_js) processes exactly one pnpm-lock.yaml per Bazel module. Because the dashboard application has its own lockfile, it stays in the same module boundary as the rest of the repo’s build tooling.

That constraint still matters, but it does not mean downstream repos should clone the product into repo-specific runner lanes. Reusable product code stays in this module; private deployment values belong in implementation overlays.

Historical Overlay Context

Overlay-oriented local overrides and symlink-merge machinery still exist in the repo as compatibility and migration context.

They are useful for:

  • understanding older deployment patterns
  • reading compatibility docs
  • supporting legacy downstream consumers that still rely on that shape

They are not the same thing as the current implementation-overlay boundary. Implementation overlays own private deployment facts; legacy symlink overlays are only one compatibility mechanism for older consumers.

GloriousFlywheel