# Proof-out: is a stable-release channel useful in a fast-moving repo? (2026-06-10)

**Question.** Does a gate-driven stable channel actually earn its keep in a repo
that cuts rolling releases continuously — or does it just rubber-stamp whatever
the latest tag is?

**Origin.** This concept and its existence-proof were developed in the DOS repos
(`dos` / `dos-kernel`) and first run against `dos-kernel-public` on its public
launch day. This file is the fleet-local adaptation: fleet has the same two-channel
design (`/release` for rolling `vX.Y.Z`, `/stable-release` for `stable/<codename>`),
re-grounded on fleet's own gate rows rather than DOS's PyPI/kernel-pytest signals.
The verdict below is reproduced because the gate logic fleet runs is the same shape.

**Method.** Run the actual stable-release gate against a genuinely fast-moving
testbed and check three things: (1) does the gate *refuse* a bad candidate with
typed, evidence-backed reasons; (2) is the inter-release narration honest without
trusting it; (3) does the witness go RED on a planted lie (so a green is meaningful).

## The testbed was genuinely fast-moving

The DOS testbed cut **four rolling releases inside 40 minutes**, two of them red in
*different* ways (one with a broken publish pipeline, one with a real regression
failing every CI matrix leg). HEAD advanced under the gate as a concurrent agent
loop committed to `master` mid-experiment. This is exactly the distribution of
candidates a stable channel exists to filter — and exactly the hot-tree shape of
fleet's own shared multi-session worktree.

## What the gate said (the headline)

The gate **refused the newest tag**, with independent typed blockers — not a vibe,
a row-by-row reading. Mapped onto fleet's five gate rows
(`tools/stable_release_context.py`):

| Row | What it catches | Verdict in the proof |
|---|---|---|
| `release_topology` | candidate unreachable / `VERSION` drift / unparseable workflow YAML | structural coherence check — passed/failed per candidate |
| `local_release_tests` | the release machinery itself is broken | mixed real regressions with hot-tree flakes — **noisy on a shared tree** |
| `dos_doctor` | the trust substrate can't resolve the workspace | clean |
| `ci_green` | a build broken on infra the promoter's box never ran | **decisive RED** on the regressing candidate — the row that earned its keep |
| `tag_age` | a just-cut tag promoted in the same breath | **FAIL** — refused a 10-minute-old tag against the 3-day window |

The `ci_green` asymmetry was the lesson: the local suite row was noisy (real
failures mixed with sibling-loop artifacts on a hot tree), but the third-party CI
row was unambiguous and non-forgeable. That is *why* `ci_green` can only ever ADD a
blocker — it reads a verdict recorded on infrastructure the promoter doesn't
control.

## The narration was honest without being trusted

Sweeping the inter-release commit range with `dos commit-audit` reported the
release contents as a *witnessed* answer (claim-vs-diff per commit, ~0% drift on the
checkable claims), not a trusted one. A planted commit whose subject claimed a code
fix over a docs-only diff was flagged `UNWITNESSED [subject-only]`, exit 1 — so the
0% drift is a meaningful green, not a rubber stamp.

## Where the gate is honestly NOT the whole answer

- **The local-suite row is fragile on a hot tree.** On a shared worktree, concurrent
  peers make `local_release_tests` both over- and under-block. The structural answer
  is the `ci_green` row; the operational answer is to run the test leg in an isolated
  worktree off the pinned candidate SHA.
- **The soak row is calendar policy, not evidence.** `tag_age ≥ window_days` is a
  proxy for "it survived contact with reality." The upgrade path (an N-day
  clean-`dos verify` soak, consumer feedback) threads into the context script without
  touching the kernel.
- **A history rewrite amputates the verify rung.** A squash/re-seed of `master`
  discards the grep-based ship-stamp evidence, so `dos verify` falls back to a
  conservative NOT_SHIPPED. This is precisely why the gate's substrate-health probe
  uses a sentinel rather than gating on any specific shipped phase.
- **Fleet-specific: CI carries no signal pre-launch.** Fleet's GitHub Actions is
  red fleet-wide from a *billing* failure — the job never starts. The gate classifies
  this as `CI_BILLING` (advisory, `action: fix_ci_billing`), so the load-bearing rows
  here are the local ones until the operator fixes billing and the repo goes public.

## Verdict

A gate-driven stable channel **is** useful in a fast-moving repo, and the DOS run
was an existence proof rather than an argument. On a repo cutting four releases in
40 minutes, the gate refused the newest tag on independent grounds (one a real
regression witnessed by infra the promoter doesn't control), certified the
release-range narration without trusting a single commit message, and demonstrably
goes red on a forged claim. The two-channel thesis held in the wild: rolling tags
*should* move fast and break often — the stable channel's job is to make "which tag
do I pin / roll back to" a typed, evidence-backed refusal rather than a guess. The
limits found are real but peripheral (hot-tree suite noise, a calendar soak proxy,
history-rewrite amputation), and each has a designed upgrade path that does not touch
the kernel.
