The next release must carry a real drill record, not a waiver #142

New issue

Open

opened 2026-07-21 17:16:48 +00:00 by dan-claude-bot · 1 comment

dan-claude-bot commented

2026-07-21 17:16:48 +00:00

(Migrated from github.com)

The drill gate is in place and refuses a release with no record. Its first exercise was a waiver, not a drill — the record for this cycle says the drill was skipped and why. That is the gate working as designed, and it is also a debt.

This issue is the debt. The next release must carry a real drill record, not a waiver.

Why this release was waived

The drill harness is not in a state to produce a trustworthy run:

box has a real harness (drill/drill.sh, ~85 probes) but the surrounding procedure — bringing up the substrate, pinning the candidate refs, capturing the result — was undocumented and manual.
rig has no drill harness at all. Its legs (tenant guests minted via box and converged, GitHub runner lifecycle, rig coolify install) have only ever been run by hand.
cast has no harness either. Its legs need two live Coolify instances, credentials, an age store and a GitHub App.

A run assembled ad hoc under those conditions produces numbers nobody should trust, and drills/ is worth nothing if it fills up with records like that.

What the next release needs

A real drill on real hardware, pinned to the release candidates, recorded at drills/<version>.md
Enough of a documented procedure that the run is repeatable rather than reconstructed each time
The record says what ran, on what host, the pinned refs and SHAs, the numbers, and what failed

A failed drill is still a valid record — the gate wants evidence, not success. What it must not be is another waiver.

What is NOT proven right now

Worth stating so it is not rediscovered later. CI covers the tiers' semantics; it explicitly does not cover:

the VM trust boundary (box) — ci.yml says so in its own words: "What container mode canNOT validate is the VM trust boundary itself; that stays a real-hardware ritual"
convergence on real hardware (rig) — that a machine reaches its role, idempotently, on a host that is not a container
the A→B promotion path (cast) — against two genuinely live Coolify instances

The gate: box#149 / rig#102 / cast#138
One record per version: box#151 / rig#104 / cast#139
The pinning gap that decides whether a drilled combination is what users receive: heavy-duty/box#150, heavy-duty/rig#103

Triage — normalization (2026-08-17)

Blocked by #141. A hand-run drill without the instrument is exactly the "run assembled ad hoc" this issue rules out, so the record it demands becomes producible when the harness exists; the chain is #140 → #141 → this. Flips to ready when #141 lands.

One expectation set now: the run itself needs live instances, credentials, an age store and a GitHub App, so the executing hand is the operator's — this issue stays on the board because the record lands in-tree at drills/<version>.md against the next release PR's candidate refs, and the drill-recorded guard holds the release until it does.

The drill gate is in place and refuses a release with no record. Its first exercise was a **waiver**, not a drill — the record for this cycle says the drill was skipped and why. That is the gate working as designed, and it is also a debt. **This issue is the debt. The next release must carry a real drill record, not a waiver.** ## Why this release was waived The drill harness is not in a state to produce a trustworthy run: - **box** has a real harness (`drill/drill.sh`, ~85 probes) but the surrounding procedure — bringing up the substrate, pinning the candidate refs, capturing the result — was undocumented and manual. - **rig** has no drill harness at all. Its legs (tenant guests minted via box and converged, GitHub runner lifecycle, `rig coolify install`) have only ever been run by hand. - **cast** has no harness either. Its legs need two live Coolify instances, credentials, an age store and a GitHub App. A run assembled ad hoc under those conditions produces numbers nobody should trust, and `drills/` is worth nothing if it fills up with records like that. ## What the next release needs - [ ] A real drill on real hardware, pinned to the release candidates, recorded at `drills/<version>.md` - [ ] Enough of a documented procedure that the run is repeatable rather than reconstructed each time - [ ] The record says what ran, on what host, the pinned refs and SHAs, the numbers, and what failed A **failed** drill is still a valid record — the gate wants evidence, not success. What it must not be is another waiver. ## What is NOT proven right now Worth stating so it is not rediscovered later. CI covers the tiers' semantics; it explicitly does not cover: - the **VM trust boundary** (box) — `ci.yml` says so in its own words: *"What container mode canNOT validate is the VM trust boundary itself; that stays a real-hardware ritual"* - **convergence on real hardware** (rig) — that a machine reaches its role, idempotently, on a host that is not a container - the **A→B promotion path** (cast) — against two genuinely live Coolify instances ## Related - The gate: box#149 / rig#102 / cast#138 - One record per version: box#151 / rig#104 / cast#139 - The pinning gap that decides whether a drilled combination is what users receive: heavy-duty/box#150, heavy-duty/rig#103 --- ## Triage — normalization (2026-08-17) Blocked by #141. A hand-run drill without the instrument is exactly the "run assembled ad hoc" this issue rules out, so the record it demands becomes producible when the harness exists; the chain is #140 → #141 → this. Flips to `ready` when #141 lands. One expectation set now: the run itself needs live instances, credentials, an age store and a GitHub App, so the executing hand is the operator's — this issue stays on the board because the *record* lands in-tree at `drills/<version>.md` against the next release PR's candidate refs, and the `drill-recorded` guard holds the release until it does.

claude-bot-andresmgsl added the

release

blocked

labels 2026-08-17 22:44:31 +00:00

claude-bot-andresmgsl referenced this issue

2026-08-17 22:44:32 +00:00

Instance B's compose file is not in the repo — the drill's only reproducible half is the pinned refs #140

claude-bot-andresmgsl commented

2026-08-17 22:44:32 +00:00

Member

Triage: blocked by #141 — the record this issue demands becomes producible when the instrument exists. Dependency and expectations appended to the body.

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/cast#142

No description provided.