Operator act needed: run the 0.3.1 drill — #107’s instrument landed, the run itself is yours

[dan-claude-bot]

Opened as promised. #107's triage block said: "What triage does when #125 merges: opens the run request on Discussions, addressed to @danmt, and links it here." PR #125 merged at 2026-07-24T07:00Z. This is that thread.

@danmt — 0.3.1 needs a real drill run on real hardware. Every gate a bot could clear is now cleared; the run is the only thing left, and it was never a builder's to do.

What changed in the last two minutes of merges

Landed	What it removed
#105 via PR #125, merge 3698eb5	The missing instrument. drill/drill.sh exists — four legs, idempotence decided by a mechanical state diff, an emitter that counts skips separately from passes. drill/README.md is the written-down procedure #107 asked for, so a run is repeatable rather than reconstructed.
#103 via PR #122, merge 8dcf529	The unpinned combination. BOX_RELEASE=0.9.0 in commands/bootstrap.sh:689 — a rig release now carries exactly one box release pin. This was #107's fourth acceptance criterion, and drills/0.3.0.md names its absence as a limit on what 0.3.0 proved: "even a passing drill would have proven a pair that drifts the moment box's main moves." It no longer drifts.

VERSION is 0.3.1-dev, drills/0.3.0.md is the waiver, and the debt's next payment is drills/0.3.1.md.

What you need

Condensed from drill/README.md; read it before running, it is the authority.

• A throwaway Debian 13 machine, reachable as root, that you can format. The drill hardens its sshd, renames it, joins it to a tailnet, and installs box/Incus, Coolify and a GitHub runner. It is not coming back — the machine is its own teardown.
• A single-use, tagged tailscale pre-auth key in TS_AUTHKEY. tag:local for the default staging-server role; bootstrap refuses tag:server outside the control-plane shapes.
• A users file naming at least one operator — leg 1 asserts the accounts and keys actually converged, so --no-users would leave it asserting nothing. One line per key:

  # user   roles       ssh public key
  danmt    admin,box   ssh-ed25519 AAAA... danmt@laptop
  

• A fork to register the runner against (--runner-repo <you>/rig), carrying a workflow_dispatch workflow — default name drill.yml — whose job is runs-on: [self-hosted, drill] and does something trivial (echo drilled). Tokens come from an authenticated gh, or RUNNER_TOKEN / RUNNER_REMOVE_TOKEN. Without a fork, leg 3 skips loudly into the record — a valid record, a smaller one.
• A Coolify version pin (--coolify-version 4.1.2). No pin, no leg: rig coolify install refuses to default a version and so does its drill.

The refs to pin, and the one thing to do first

The harness requires both refs and refuses to continue if what installed disagrees with what was asked (INSTALLED_FROM, both trees). So:

• --rig-ref release/0.3.1 — cut that branch first. (Amended 2026-07-24 23:10Z — there is no branch to cut; the candidate already exists.) --rig-repo codex-bot-andresmgsl/rig --rig-ref build/144-release-0-3-1 — the candidate is PR #145's branch on the builder's fork, tip 9b4ac5e, parked there until your record returns (ruling on #144). drill.sh takes --rig-repo first-class and install.sh honors it; the fork is public so the unauthenticated fetch works. The release/… naming existed to dissolve the box↔rig recursion — moot this cycle, because the box side is the literal tag below; the record pins the SHA, which is the identity that matters. Drilling main would still prove a tree that moves out from under the record — the fork branch is held still for you.
• --box-ref 0.9.0 — not a release/… branch this time. drill/README.md's example predates BOX_REF defaults to main — a released rig builds its VM host from box's development tree #103 landing; the box that will actually ship with rig 0.3.1 is now literally the tag BOX_RELEASE pins, and pinning the drill to anything else would drill a pair users do not receive.

The command

# on the throwaway machine, from a checkout of the candidate branch (the record lands in its drills/):
#   git clone -b build/144-release-0-3-1 https://github.com/codex-bot-andresmgsl/rig
TS_AUTHKEY=tskey-... bash drill/drill.sh \
  --rig-repo codex-bot-andresmgsl/rig --rig-ref build/144-release-0-3-1 \
  --box-ref 0.9.0 \
  --users ./drill-users --run-id drill-2026-07-24-a \
  --coolify-version 4.1.2 --runner-repo <you>/rig --yes

It runs unattended from there. Legs execute 1, 4, 2, 3 — Coolify's installer is what puts Docker on the machine and the db leg needs a daemon. A failing check never aborts the run: a failure is data, and the summary counts passes, failures and skips separately.

If you are drilling box or cast on the same substrate, reuse one --run-id across all three — the shared ID is the only thing that lets the per-repo records be joined afterwards.

What comes back

The run always ends by writing drills/0.3.1.md, on failures too. A failed drill closes #107 honestly. The gate wants evidence, not success; what it must not be is another waiver.

Hand the file (or the machine's copy of it) back here or on #107 and the PR that lands it is an ordinary build task a builder can claim. That split is #107's, stated when it was normalized: the run is yours, the record's PR is theirs.

The block

🔧 needs-operator-act — run the 0.3.1 drill on real hardware and hand back drills/0.3.1.md
What:     bash drill/drill.sh --rig-repo codex-bot-andresmgsl/rig --rig-ref build/144-release-0-3-1 --box-ref 0.9.0 --users … --coolify-version 4.1.2 --runner-repo <you>/rig --yes
          on a throwaway Debian 13 machine, with a tag:local single-use TS_AUTHKEY. (Amended 2026-07-24 23:10Z: no branch to cut — the candidate is PR #145's fork branch, tip 9b4ac5e, held still until the record returns.)
Blocked:  #107, and only on this. Both issue-shaped gates are gone: #105 (harness) merged 07:00Z, #103 (pin) merged 07:01Z. No builder is idling — #107 is `blocked`, not `ready`, precisely so nobody claims a deliverable they cannot produce.
Not blocked: the release itself is not waiting on a PASS. A FAILED drill is a complete record and satisfies every one of #107's acceptance criteria. Only another waiver does not.
Default:  none — hard block. A bot holding `triage` has no hardware, no tailnet key and no fork; there is no version of this that fires on a clock. It waits for you, and it will keep waiting rather than degrade into a reconstructed run.
Decider:  @danmt — as the operator, not as a decision-maker. Nothing here needs a ruling; it needs an afternoon.

What triage does with the answer

• Run happens (pass or fail) → The next release must carry a real drill record, not a waiver #107 flips to ready the moment drills/0.3.1.md can honestly be written, and a builder lands it as an ordinary PR.
• Run cannot happen this cycle → say so here and triage will not pretend otherwise: The next release must carry a real drill record, not a waiver #107 stays blocked, and 0.3.1 either waits or takes a second waiver — which is a maintainer's call to make out loud in drills/0.3.1.md, exactly as 0.3.0's was.
• Something in the procedure is wrong when you actually run it → that is the most valuable outcome on this list. drill/README.md has never met real hardware; report it here and it becomes an issue.

Refs: #107 (the debt, blocked), #105 / PR #125 (the harness, merged), #103 / PR #122 (the pin, merged), drills/0.3.0.md (the waiver this repays), #102 (the gate), #104 (the record format).

[dan-claude-bot]

Dedup note, and one thing this thread should carry before @danmt runs anything.

Two triage sessions were sweeping rig concurrently this morning and both opened this request, two seconds apart: this one and #131. This thread (#132) is the canonical one — it names the actual refs to pin and #133 already cites it. #131 is closed and points here. Nothing is owed on that thread.

Porting the one finding it had that this one does not:

The record's filename comes from VERSION, not from --rig-ref

drill.sh names the record from the installed tree's own VERSION (L378–380): DRILL_VERSION="$(head -n1 "$RIG_TREE/VERSION")", then RECORD="$ROOT/drills/$DRILL_VERSION.md". The drill-recorded guard reads drills/<released version>.md and nothing else (drill-recorded.sh L104).

main reads 0.3.1-dev today. So if you cut release/0.3.1 and drill it before the ceremony PR stamps VERSION, the run writes drills/0.3.1-dev.md — a real drill, correct in every other respect, whose record the release gate will not accept.

Two ways through, either fine:

• drill after VERSION on the branch reads 0.3.1, or
• pass --record drills/0.3.1.md explicitly (the flag exists — drill.sh L73).

Worth knowing before the afternoon rather than after it: everything else about the run is unattended, so this is the one detail that would cost the whole thing.

[dan-claude-bot]

@danmt — one correction to the runbook above, now that the candidate exists: do not cut release/0.3.1. There is no branch for you to create.

The builder claimed #144, did every deterministic step, and pushed the candidate as PR #145 — fork branch codex-bot-andresmgsl/rig:build/144-release-0-3-1, tip 9b4ac5e, held still until your record returns. The body's command, refs section and operator-act block are amended in place; the run is now exactly:

# from a checkout of the candidate branch (the record lands in its drills/):
#   git clone -b build/144-release-0-3-1 https://github.com/codex-bot-andresmgsl/rig
TS_AUTHKEY=tskey-... bash drill/drill.sh \
  --rig-repo codex-bot-andresmgsl/rig --rig-ref build/144-release-0-3-1 \
  --box-ref 0.9.0 \
  --users ./drill-users --run-id drill-2026-07-24-a \
  --coolify-version 4.1.2 --runner-repo <you>/rig --yes

Everything else in the body stands: the machine, the tailscale key, the users file, the runner fork, the Coolify pin, and the promise that a failed drill is a complete record. PR #145's red check is drill-recorded refusing 0.3.1 with no drills/0.3.1.md — it goes green the moment the record you hand back lands on that branch. Ruling and rationale recorded on #144.

[dan-claude-bot]

Resolution for the 0.3.1 scope of this request: @danmt ruled on PR #145 (comment, 2026-07-25 09:02Z) — "Add a waiver as the drill." The 0.3.1 run this discussion requested does not happen; the builder lands drills/0.3.1.md as a waiver record citing that ruling, and the release proceeds through the merge door.

The debt is not discharged: #107 stays open and blocked (amended 2026-07-25 09:18Z) — the release after 0.3.1 owes the real run, and this discussion remains the reference for how that run is performed (refs to pin per the fork-branch pattern, record handed back as drills/<version>.md).

[dan-claude-bot]

Closing this as resolved — the 0.3.1 cycle this thread requested a run for is over. PR #145 merged 2026-07-25 10:32Z, the 0.3.1 release is published, and drills/0.3.1.md is the waiver the operator ruled for; the record itself says the harness was available and the ruling gave no reason, so the debt's growth is visible in drills/ as it should be.

The debt lives at #107 (blocked, amended 09:18Z): the release after 0.3.1 owes the real run. When that cycle comes, this thread stays the reference for how the run is performed — pin the candidate's fork branch per the pattern above, mind that the record's filename comes from the installed tree's VERSION (or pass --record), and hand the record back onto the candidate branch.