GloriousFlywheel Rollout Gates And Failure Modes 2026-04-17

Snapshot date: 2026-04-17

Purpose

Define the go/no-go gates, stop conditions, and rollback rules for the contract rollout stack.

This note exists to prevent the rollout from drifting into optimistic merging without operational proof.

Companion notes:

• gloriousflywheel-contract-rollout-pr-stack-2026-04-17.md
• gloriousflywheel-source-default-branch-proof-package-2026-04-17.md
• gloriousflywheel-js-bazel-package-v2-rollout-2026-04-17.md

Gate Types

Code Gate

The workflow or template change is merged and syntactically correct.

Proof Gate

The changed path runs successfully on the intended runner class.

Stability Gate

The changed path succeeds often enough that it can be cited in status and PM surfaces without caveat.

Reporting Gate

PM and docs surfaces are updated only after code, proof, and stability are all good enough.

PR Gates

PR 1: Source Default-Branch Proof

Code gate:

• new proof workflow merged in GloriousFlywheel

Proof gate:

• one successful default-branch run on:
  • tinyland-docker
  • tinyland-nix
  • tinyland-nix-heavy

Stability gate:

• at least 3 successful runs without needing feature-branch-only proof

Stop condition:

• if any lane repeatedly fails due to runner registration, routing, or missing injected contract state, block PR 2 and route to runtime integrity work

Rollback rule:

• keep the proof workflow
• reduce command payloads first
• do not remove default-branch proof unless the platform is genuinely unstable

PR 2: js-bazel-package V2

Code gate:

• V2 interface is merged with compatibility preserved

Proof gate:

• at least one consumer can still run in compatibility mode
• one local or staging validation shows self-hosted contract wiring is active

Stability gate:

• no broad breakage across existing consumers after merge

Stop condition:

• if V2 requires repo-specific hacks just to keep compatibility consumers alive, stop and narrow the template

Rollback rule:

• keep V1 compatibility path available temporarily
• do not revert to ambiguous hosted fallback as the only explanation

PR 3: scheduling-kit Pilot

Code gate:

• repo is switched to V2 explicitly

Proof gate:

• CI and publish path succeed on the verified dedicated lane

Stability gate:

• at least 2 successful routine runs on the new contract

Stop condition:

• if the repo needs per-repo workspace or cache hacks beyond the template contract, stop and repair V2 before continuing

Rollback rule:

• pin the repo back to compatibility mode if needed

PR 4: acuity-middleware Pilot

Code gate:

• package path uses V2 explicitly

Proof gate:

• package path succeeds self-hosted
• hosted Modal deploy remains explicit and unaffected

Stability gate:

• at least 2 successful runs on the package path

Stop condition:

• if hybrid repos cannot keep hosted exceptions narrow, stop broad rollout and tighten the contract boundary first

Rollback rule:

• revert only the package-template migration if needed
• do not broaden the hosted deploy path into the package path

PR 5: tinyvectors Decision

Code gate:

• repo explicitly declares hosted or self-hosted intent

Proof gate:

• if promoted, one clean successful self-hosted run
• if left hosted, no runner-adoption claim remains

Stability gate:

• ambiguity is removed from repo code and planning docs

Stop condition:

• if the repo still depends on undocumented org or repo variables, do not count it as promoted

Rollback rule:

• hosted intent is an acceptable steady state

PR 6: Reporting Cleanup

Code gate:

• docs and PM surfaces updated

Proof gate:

• must be backed by merged PRs, not open branches or intended changes

Stability gate:

• no tier count should depend on one unverified pilot

Stop condition:

• if code and docs diverge, freeze reporting changes until counts are retruthed

Failure Modes

Failure Mode 1: Runner Contract Missing On Self-Hosted Jobs

Symptoms:

• no ATTIC_SERVER
• no BAZEL_REMOTE_CACHE
• no explicit Nix bootstrap where required

Interpretation:

• this is a template or source contract failure, not a repo-specific failure

Response:

• stop rollout
• fix the shared contract first

Failure Mode 2: Persistent Workspace Pollution

Symptoms:

• stale files
• permission issues
• cleanup-path churn
• repo-local hacks to make repeated self-hosted runs work

Interpretation:

• this is a #213 platform hygiene failure

Response:

• stop promoting repos as clean self-hosted consumers
• fix template or runner hygiene before broadening rollout

Failure Mode 3: Self-Hosted Publish Is Harder Than The Contract Allows

Symptoms:

• provenance only works hosted
• registry auth differs by environment
• artifact publishing succeeds only with hosted-specific behavior

Interpretation:

• the contract should encode a hosted publish exception, not pretend the package path is uniform

Response:

• use publish_mode=hosted_exception
• do not force self-hosted publish just for narrative symmetry

Failure Mode 4: Hybrid Repos Are Reported As Clean Dogfood

Symptoms:

• package path is self-hosted
• deploy or authority path remains hosted
• repo is still reported as homogeneous adoption

Interpretation:

• this is a PM and classification failure

Response:

• keep the repo in Tier X until the hosted authority path is either removed or explicitly bounded

Failure Mode 5: Source Repo Proof Is Too Synthetic

Symptoms:

• proof workflow only echoes environment state
• no real command runs on the lane

Interpretation:

• the repo still lacks credible self-dogfood

Response:

• keep the workflow
• add one real lightweight command per lane

Promotion Gates For Metrics

A repo should only move into the runner-dogfood count when all are true:

1. authoritative workflow is merged
2. default-branch proof exists
3. runner intent is explicit
4. hosted authority for the claimed path is absent or explicitly exceptional

A repo should move out of ambiguity when either:

• it proves self-hosted use cleanly
• or it explicitly declares hosted intent

Minimum Evidence Artifacts

Each completed rollout PR should leave behind:

• one merged PR reference
• one successful workflow run reference
• one updated classification row or scorecard entry

Without those three artifacts, the rollout is not complete enough to cite.

Recommendation

Use a conservative rule:

“Code merged” is not enough.

“Green once” is not enough.

“Explained clearly and stable enough to classify” is the real rollout gate.