BCR / Bzlmod Posture (May 2026)

BCR / Bzlmod Posture — May 2026

Snapshot date: 2026-05-10. Author: C3 of the May 10-16 sprint plan (2026-05-10-cache-forward-toward-rbe.md).

This is a decision-quality writeup and status record. The output is a clear statement of where package authority stands, what already changed, what would force the remaining decisions, and what each path costs.

For the broader cross-stream view (cache, RBE, RustFS, BCR), see the BCR/RBE/RustFS Product Reality Review.

TL;DR

Two BCR/Bzlmod decisions remain open, and one package-authority gap closed:

  1. TIN-1041 is closed — scheduling-bridge 0.4.10 was historically consistent with scheduling-kit 0.7.7, and current tummycrypt_scheduling_bridge@0.5.11 is now registered with tummycrypt_scheduling_kit@0.8.0.
  2. Module-name compatibility — the Bazel module is still attic-iac for downstream compatibility while the product identity is GloriousFlywheel. Decide: when (and how) to rename and cut the compatibility window.
  3. Internal vs public BCR — package releases currently flow through an internal registry. Decide: which packages (if any) graduate to the public Bazel Central Registry, and what evidence forces the move.

These are not blocked on each other and should not be conflated with RBE or RustFS work.

TIN-1041 — Scheduling-bridge dependency pin reconcile

What is true today

  • The source release for tummycrypt_scheduling_bridge@0.4.10 really depended on scheduling-kit ^0.7.7. The old registry entry was historical metadata, not a stale pin to edit in place.
  • tinyland-inc/bazel-registry#42 added current tummycrypt_scheduling_bridge@0.5.11.
  • The new 0.5.11 registry entry depends on tummycrypt_scheduling_kit@0.8.0, matching the current scheduling-bridge source release and the existing scheduling-kit registry entry.
  • Post-merge registry validation on 7dcf57a1cd777cf97c799e8ce558581616642cb4 passed npm run validate, npm run smoke:resolve, and npm run smoke:stage1-consumer in run 25637800822.
  • Status: Done. TIN-1041 is closed.

Decision criteria

The decision was to hold old release metadata and advance through a current release entry:

  • Do not mutate 0.4.10; it describes the source tag that was published.
  • Represent the current package graph by registering 0.5.11.
  • Keep consumer impact tied to module resolution through immutable versions, not historical metadata rewrites.

Done condition

Per the ticket: the scheduling-bridge BCR dependency pin is either confirmed intentional with rationale or updated through the package authority path. This is done by preserving 0.4.10 and adding 0.5.11.

What this sprint should NOT do

  • Do not treat the registry update as RBE evidence. Package authority and execution authority are different problems with different blast radii.
  • Do not infer public BCR readiness from the internal registry correction.

Module-name compatibility

What is true today

  • MODULE.bazel:18-21 declares module(name = "attic-iac", version = "0.1.0").
  • Public-docs and BUILD metadata describe the repo as GloriousFlywheel.
  • Downstream consumers using bazel_dep(name = "attic-iac") are part of the current narrow consumer path.
  • docs/architecture/bzlmod-topology.md is the canonical truth surface.

Why it hasn’t moved

  • A formal downstream rename + compatibility cutover hasn’t shipped.
  • Consumers pinning attic-iac would break on a hard rename; a soft rename needs both names to resolve for a compatibility window.
  • The internal-vs-public-BCR decision is a prerequisite — public BCR makes the rename a registry-policy event, not just a repo edit.

What would force the decision

  • A public-BCR publication intent for any module from this repo (the public BCR will not accept attic-iac as a long-term name for a product called GloriousFlywheel).
  • A downstream consumer that needs the new name (none today).
  • Internal noise — operators repeatedly explaining the name mismatch — at high enough volume to outweigh the rename cost.

Default for this sprint

Hold the compatibility name. Document the gap clearly. Do not invent a rename plan ahead of one of the forcing functions.

Internal vs public BCR

What is true today

  • The repo participates in an internal Bazel registry (bazel-registry/ in consumer paths).
  • Public BCR is not a current dependency: rules_nixpkgs_rust / rules_nixpkgs_cc / rules_nixpkgs_go are not in BCR (only rules_nixpkgs_core and rules_nixpkgs_nodejs are). The 2026-05-10 toolchain wedge moved language-toolchain sourcing onto canonical BCR rules (rules_rust, rules_cc, rules_go). See Toolchain Coverage.
  • No GloriousFlywheel-owned module is currently a public BCR submission candidate.

Decision criteria for graduating to public BCR

Pro-public conditions:

  • A specific module has external consumers (or a credible imminent external consumer) who would benefit from bazel_dep discovery and version resolution.
  • The module surface is small, stable, and has an LTS-shaped release cadence.
  • Module-name decision (above) is settled — public BCR will hold us to the name.

Hold-internal conditions:

  • The module is still in active shape change.
  • The module is owner-coupled (carries operator/topology/auth surfaces that shouldn’t be public).
  • External consumers are speculative, not measured.

Default for this sprint

Stay internal. The substrate is still in active shape change, and the narrow GF REAPI Cell proof + toolchain wedge work should land before any public-BCR submission decision.

What this note does NOT cover

  • RBE backend selection — separate gate; see roadmap “Later” section.
  • RustFS storage authority for CAS/action-cache — separate decision; see Backend Authority Decision (May 2026).
  • Public-alpha repo visibility — separate decision; tracked in TIN-551 closeout context.

Coordination

  • Jess: owner of the rename forcing-function decisions.
  • Codex: package-authority guard and registry validation work is in scope when it directly supports active sprint package-authority hygiene.
  • Claude (this note): keeps the decision shape clean and surfaces ambiguity rather than inventing answers.

GloriousFlywheel