GloriousFlywheel Bazel Dogfood Tranche 1 2026-04-22

Correction on 2026-04-24: This note is preserved as historical tranche planning from the pre-reset productization frame. It is not the active execution slice. Read repo-owned package-lane and tranche-proof language here as historical context, not as the current pooled-substrate contract.

Snapshot date: 2026-04-22

Purpose

Turn the broader productization horizon into one concrete execution slice.

This note names the first authoritative Bazel dogfood tranche and the proof criteria required before GloriousFlywheel can claim that cache-first, verify-later is a real owned-repo contract rather than mostly substrate capability.

Owner surfaces:

• #320
• #322
• TIN-335
• TIN-336

Companion notes:

• gloriousflywheel-productization-horizon-2026-04-22.md
• gloriousflywheel-active-owned-repo-adoption-board-2026-04-17.md
• gloriousflywheel-first-tranche-repo-contracts-2026-04-16.md
• gloriousflywheel-js-bazel-package-v2-rollout-2026-04-17.md
• gloriousflywheel-cache-publication-contract-2026-04-15.md

Why This Tranche Is Small

The point of tranche 1 is not to include every strategically relevant repo.

The point is to cover the five repo classes that matter most to the cache-first claim:

1. source-of-truth repo
2. benchmark and builder canary
3. representative org product repo
4. clean repo-owned shared JS/Bazel package consumer
5. hybrid package/deploy consumer with one explicit hosted exception

If those five classes are not proved, adding heavier or rarer repos will only make the product story noisier.

Tranche 1 Repos

Explicitly Not Tranche 1

These repos matter to the broader horizon, but they are not the first Bazel dogfood slice:

Proof Criteria

Every tranche-1 repo should be evaluated against the same five questions.

1. Runner Authority

The authoritative Bazel path must say whether it is:

• hosted by policy
• shared self-hosted
• repo-owned self-hosted

Ambiguous fallback is not acceptable.

2. Cache Authority

The workflow must make cache authority visible:

• Bazel remote cache for Bazel action/CAS acceleration
• Attic only where Nix bootstrap or Nix build surfaces are also part of the repo contract

The repo should not rely on “cache maybe exists on the runner” as the product explanation.

3. Validation Boundary

The path must say where validation happens relative to acceleration:

• cache-first does not mean trust-before-build
• validated outputs remain the promotion boundary
• publish or deploy authority must remain explicit when it differs from build authority

4. Fallback And Exception Policy

If a repo still needs hosted publish, deploy, or external-authority steps, they must be named as durable or temporary exceptions.

The same authoritative build path should not silently flip between hosted and self-hosted modes.

5. Measurement Expectation

Each repo needs one recorded proof package, not just a merged workflow:

• one green run on the authoritative path
• one visible cache signal such as configured remote-cache use, cache hits, or a benchmark comparison against an uncached baseline
• one short note saying what was actually proved

Repo-Specific Read

GloriousFlywheel

This repo is not allowed to hide behind generic substrate language.

The first tranche-1 execution proof is now explicit:

• Source Bazel Proof on tinyland-nix
• nix develop -c bazel build --config=ci-cached //:deployment_bundle

What remains for this repo is not “add any Bazel proof at all.” It is:

• keep that bounded source-repo package green on main
• use it as the canonical proof package while broader tranche-1 repos catch up
• keep public docs honest that this is the first source-of-truth proof, not full tranche completion

lab

lab is the benchmark canary, not just another downstream consumer.

For tranche 1 it needs:

• the benchmark pack to be named explicitly
• Bazel remote-cache behavior to be part of the proof package
• shared-runner contract language to stay distinct from MCP, deploy, or other adjacency

tinyland.dev

tinyland.dev is the representative org product repo.

For tranche 1 it needs:

• the current hybrid-by-policy split to remain explicit
• one authoritative explanation of the Bazel path instead of a mixed hosted and self-hosted folklore story

scheduling-kit

This is the cleanest current dedicated package-lane proof target.

For tranche 1 it needs:

• explicit runner intent
• explicit workspace intent
• explicit cache and validation behavior through the shared JS/Bazel package contract

acuity-middleware

This is the hybrid package-lane proof target.

For tranche 1 it needs:

• the package path to read as a first-class self-hosted contract
• the Modal deploy path to remain a named hosted exception instead of bleeding back into package-lane ambiguity

Suggested Order

1. GloriousFlywheel
   • keep the canonical proof package and doc language stable on main
2. lab
   • make the benchmark and cache evidence repeatable
3. scheduling-kit
   • prove the clean dedicated JS/Bazel package contract
4. acuity-middleware
   • prove the hybrid package plus hosted-deploy boundary
5. tinyland.dev
   • tighten the representative org-product repo story after the contract is clearer

This is the preferred proof order, not a requirement that only one repo move at a time.

Exit Signal

Tranche 1 is done when:

• the five repos above are still the named tranche-1 set
• each repo has one recorded proof package against the criteria above
• the public docs can describe Bazel dogfood as an owned-repo contract without leaning mainly on substrate implementation detail
• adjacent runner-class work such as KVM, GPU, macOS, riscv, and broader forge claims still stays explicitly adjacent instead of being mixed into the first Bazel proof story