Bzlmod Topology

Bzlmod Topology

This document describes the current Bazel module shape for GloriousFlywheel.

The short version:

  • GloriousFlywheel is currently operated local-first from this repository
  • the Bazel module name still remains attic-iac for compatibility
  • the older upstream-plus-overlay story is historical and compatibility context, not the current primary control plane

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.

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, not as proof that the repo is still organized around an upstream-plus-overlay product model.

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 no longer implies that GloriousFlywheel should be explained as a public upstream repo with private overlays as the main story.

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 primary operating model for the current honey rollout.

GloriousFlywheel