Operator act needed: run the #195 drill on a fresh Debian — one session discharges four acceptance criteria and PR 199's round 2

[dan-claude-bot]

⚠️ Read this before running anything on this page — updated 2026-09-03

The run this door asked for has happened, and the command block below is superseded: it has been wrong in every line since 2026-09-02, and the runbook that replaced it was executed on 2026-09-03. Running either reproduces nothing and burns a machine. The drill is destructive on purpose.

This door is still open, and what it asks for now is in the latest comment — chiefly a paste of the 2026-09-03 session's complete final stdout, which needs no machine at all. The body below is kept as the record of how this door opened; every statement in it about board state, runbooks and deadlines has been superseded by the comments, in order.

---

@danmt — #195 needs one live drill run on a fresh Debian machine, and this thread is the door for it. That single run is the entire remainder of rig's open board.

Opening it because triage set a tripwire on itself and it has now fired. The 2026-08-26 16:2xZ census on #195 said: if no run stdout has landed by 2026-08-28 12:28Z — 48 hours from the builder's last handoff re-statement — triage re-examines this claim and opens an "Operator act needed" discussion door for the run, the way #132 and #173 were opened. Re-read at 12:2xZ today from #195's own timeline and PR 199's state rather than from the thread: no stdout, and no push, review or comment anywhere since 2026-08-26 12:28:20Z. A claim carrying an open PR is invisible to the 48-hour staleness sweep by construction, so this wait has no automatic floor. This thread is the floor.

State, measured today rather than recalled

fact	value
#195	claimed by @andriujoseba since 2026-08-26 11:46:42Z; enhancement + scope:drill + scope:docs; the last write of any kind on it is triage's own at 19:52:08Z
PR 199	open draft at head 06470dee, MERGEABLE/CLEAN, state:addressing, every check context green at that head (eight rollup entries, six distinct)
review	round 1 closed 2026-08-26 12:20:52Z — one approval, two changes-requested; the fixes are pushed, and the builder is holding the round-complete signal until the stdout arrives (12:25:48Z)
criteria	four of the ten are operator-owned and all four ride this one run — the end-to-end curl run, the record path and full text on stdout, --users-from-github danmt converging operators, and a second person following drill/README.md without reconstructing a step. Stated by triage on the issue at 16:2xZ
candidate	andriujoseba/rig branch build/195-one-command-drill @ 06470dee; its raw URL serves 200, checked 12:2xZ. heavy-duty/rig carries no such branch, so the fork form below is the only one that resolves

The run

The prerequisites are drill/README.md at the candidate head, which is the authority — read that, not a paraphrase of it; the instrument enforces every one of them in pre-flight, before the tailnet key is spent. Its own command form, with the fork's repo and ref substituted:

RIG_REPO=andriujoseba/rig
RIG_REF=build/195-one-command-drill
TS_AUTHKEY=tskey-... bash <(curl -fsSL \
  "https://raw.githubusercontent.com/$RIG_REPO/$RIG_REF/drill/drill.sh") \
  --rig-repo "$RIG_REPO" --rig-ref "$RIG_REF" --box-ref 0.9.0 \
  --users-from-github danmt --run-id drill-2026-08-28-a --yes

Three things the README carries that the handoff comment does not, each of which stops a run at the door:

• --yes. The handoff's command omits it. The drill is destructive on purpose and confirms interactively; with no TTY it exits 2 (drill.sh:441). Keep it for an unattended run.
• The machine. A fresh box VM is the known-good substrate: box new drill-rig --template blank --vm --cpu 4 --memory 8GiB --disk 60GiB. Not staging-box — that template converges rig at mint through BOX_BOOTSTRAP_ROLE, so the guest is not scratch. A container is not a substrate at all, and box doctor needs box 0.9.0 or newer to pass nested.
• The entry path. box shell preserves a non-admin SUDO_USER, which pre-flight now refuses by name — the trap that cost the 0.3.2 session a whole run. Enter with incus exec drill-rig -- bash -l, or unset SUDO_USER in a root shell.

TS_AUTHKEY is a single-use, tag:local key for the default staging-server role. --rig-ref and --box-ref are both required, and --box-ref is a tag on purpose.

What to do with the output

Paste the instrument's complete final stdout into a comment on #195 — that is exactly the convention this issue is writing down, in drill/README.md's Who runs it, and where the record goes.

No drills/ commit is asked of this run. 0.3.2 shipped 2026-08-25 23:57Z, no cut is in flight, and which number carries this narrowing is the open question on discussion #197. The record the instrument writes to /root/drills/<version>.md is acceptance evidence for #195's criteria and nothing more; a release record is committed on a cut branch, and there is no cut branch.

A failed run is a valid answer. Two of #195's criteria are refusals that must fire, and the gate wants evidence, not success. Please paste the stdout either way.

What happens after

The stdout lands on #195 → its four operator-owned criteria become checkable, the builder signals round 2 and takes PR 199 out of draft, the panel re-reads the tree it shipped, and #195's close is the last one epic #192 needs. Nothing else in rig is queued behind anything.

If the run is not happening this cycle, say so here

That is a useful answer, and it changes what triage does. @andriujoseba's claim on #195 has been parked on this run since 2026-08-26 16:01Z and, carrying an open PR, will never age out on its own. If you tell this thread the run is not coming soon, triage re-examines that claim on the record instead of letting it sit.

What triage cannot do is pick this one. TRIAGE.md's past-24-hour rung has triage choose the option a builder proceeds on when a ruling goes unanswered — but that rung needs an option triage can execute, and every option here is an act on a physical fresh host. Default: none — hard block. For the same reason #195 carries no flag: needs-ruling names a decision only a human owns and this is an act, not a decision; attention names a demand parked for the assignee, and the ball here is yours rather than theirs.

Triage's next tripwire, again set on itself, is 2026-08-30 12:28Z. If neither the stdout nor an answer here has landed by then, triage re-examines #195's claim in public on the issue and records what it weighed. Struck 2026-08-30 20:4xZ — retracted, spent rather than fired. The claim it promised to re-examine ended before its deadline: @danmt merged PR 199 at 2026-08-29T20:20:29Z, #195 closed at 20:20:31Z on its Closes reference, and the assignee was released with it — so there was no claim left to re-examine and nothing for the tripwire to fire on. It was recorded as retracted on #192's task list at 22:3xZ on 2026-08-29 and not here, which left it standing live on this page for a day; a settled call has to reach every body that states it. No new tripwire replaces it — rig's board now holds no open issue and no open pull request, so nothing waits on this run and a deadline here would be theatre. The last sentence of the struck text stands and is why this door stays open: silence is the one outcome that leaves this debt invisible again.

[dan-claude-bot]

Premise update, 2026-08-29 22:4xZ — half of this door's stated purpose is spent, the other half is not, and the ledger of what one session buys has grown. The ask itself is unchanged and there is nothing new to answer.

1 — what changed. This thread's title says one session discharges four acceptance criteria and PR 199's round 2. The round is gone: the builder answered round 1 whole at 2026-08-29T19:42:16Z without the run, the panel approved head 06470dee, and @danmt merged PR 199 at 20:20:29Z. Its Closes #195 shut #195 at 20:20:31Z with all four operator-owned criteria still unticked, and #192 — the epic — closed an hour ago. So no PR waits on this run, no claim waits on it, and no builder is idle for it.

What has not changed is the evidence. The reworked drill has still never been run. Every criterion ticked at the merge is a fixture, a grep, a CI context or a document read; this thread has held no comment of any kind since it opened.

2 — the ledger, corrected upward. It is six criteria across three closed issues, not four across one. All three of #192's children closed on Closes merges, so nothing ticked them; triage ticked what it could measure today and left exactly this:

criterion	issue	discharged by
end-to-end bash <(curl …) run on fresh Debian 13, writes a record	#195	the default run below
the record's path printed and its full text on stdout	#195	the default run
--users-from-github danmt converges, asserted by leg 1's own check	#195	the default run
a second person follows drill/README.md without reconstructing a step	#195	the default run — the operator following it is the second person
leg 2's real round-trip on a machine that never had Docker, record says PASS	#194	the default run — leg 2 is that leg
rig bootstrap control-plane-server still converges	#194	only a --role control-plane-server pass
rig bootstrap runner-server still converges: role marker, tag:ci, tag:server refusal	#193	only a --role runner-server pass, with a tag:ci key

The last two are new to this door and were priced for the first time today. They are the same class of live-convergence evidence, they were never named here, and the default run does not touch them — the instrument converges staging-server unless told otherwise, and it accepts both roles by name (drill.sh:374). runner-server needs a key minted for tag:ci, not the tag:local the default role uses and not tag:server, which that role refuses by design.

3 — the commands. The first is unchanged from the ask above and still executable exactly as written: the candidate branch still resolves to 06470dee, polled 22:3xZ.

# the default run — discharges five of the seven rows above
RIG_REPO=andriujoseba/rig
RIG_REF=build/195-one-command-drill
TS_AUTHKEY=tskey-...   # tag:local
bash <(curl -fsSL "https://raw.githubusercontent.com/$RIG_REPO/$RIG_REF/drill/drill.sh") \
  --rig-repo "$RIG_REPO" --rig-ref "$RIG_REF" --box-ref 0.9.0 \
  --users-from-github danmt --run-id drill-2026-08-29-a --yes

Each of the two role passes is the same line with --role control-plane-server (same key) or --role runner-server (a tag:ci key), on its own fresh guest — a converged machine is not a scratch machine, so they do not stack on one box. They are strictly optional: nothing waits on those two criteria either, and a run that skips them leaves the record on this thread saying so.

Prerequisites are drill/README.md's own What you need, not this paraphrase — in particular a VM, not a container, box new drill-rig --template blank --vm --cpu 4 --memory 8GiB --disk 60GiB as the known-good substrate, entry by incus exec drill-rig -- bash -l (the drill refuses box shell by name in pre-flight), and --yes because it exits 2 with no TTY. A failed run is a valid answer and is pasted the same way.

4 — one trip may now produce two records. box PR 248, the 0.10.0 cut, was opened at 21:03:38Z and carries blocker:drill-pending: box is waiting on the same class of act on the same class of host. rig's own CONTRIBUTING says drills sharing a substrate share one --run-id so their records can be joined afterwards. That is an offer about scheduling, not a dependency in either direction.

5 — nothing is blocked, and there is a backstop. rig cannot cut a release without a drill record: drill-recorded refuses a bare-VERSION tree that has no drills/<version>.md. So the instrument cannot ship unexercised past the next cut, whenever that opens — which is discussion #197's unanswered question. A run posted here before then buys the seven rows above and de-risks that cut; a run that waits until the cut evidences the instrument against the release candidate instead, and leaves those seven standing as they are. Both are legitimate.

6 — the answer that closes this door without a run. Say "it rides the next cut" and triage records that on #193, #194 and #195 as the wake for their remaining criteria and closes this thread. No flag moves either way; nothing here is a hard block on anything.

[dan-claude-bot]

Premise update, 2026-08-30 20:4xZ — clause 4 of yesterday's comment is withdrawn, the tripwire this door set on itself is retracted as spent, and the ask is otherwise unchanged and still executable exactly as written. Nothing new to answer, and nothing here asks the assignee for anything.

1 — the runbook still works, checked rather than assumed. This door's whole value is a command, so I re-derived it before writing anything else: andriujoseba/rig@build/195-one-command-drill still resolves to 06470dee, and drill/drill.sh is fetchable at that ref over plain curl — 200, 34,334 bytes, polled 20:3xZ. The command block in the 22:4xZ comment is correct as posted and needs no edit, and a merged PR does not delete a fork's branch. The seven-row ledger in that comment is also unchanged: nothing has ticked, no evidence for any row has ever existed, and this thread has held no comment from anyone but triage since it opened.

2 — clause 4 is withdrawn: one trip no longer produces two records. It read "box PR 248, the 0.10.0 cut, was opened at 21:03:38Z and carries blocker:drill-pending." PR 248 closed unmerged at 2026-08-30T14:08:52Z on @danmt's ruling, box#222 went back to blocked and unassigned, and box's window took six more members (box#182, wave 10). box has no cut branch, so there is no tree for a 0.10.0 record to be committed to, and no blocker:drill-pending stands anywhere on that board. Its remaining path is priced on #197 and is three steps in front of its own drill.

Nothing about rig's run changes, because the offer was scheduling only and never a dependency in either direction. But this is the second withdrawal of that same offer in two days — made 2026-08-29 07:4xZ, withdrawn 15:2xZ, restored 22:4xZ, withdrawn now — so the honest form is the rule rather than the instance: do not schedule rig's run around box's. box's cut date is not a fact anyone can be told once, and rig's run has never needed it.

3 — the 2026-08-30 12:28Z tripwire is retracted, spent rather than fired. This issue's body promises that if neither stdout nor an answer landed by then, triage re-examines @andriujoseba's #195 claim in public and records what it weighed. That claim ended before the deadline arrived: @danmt merged PR 199 at 2026-08-29T20:20:29Z, #195 closed at 20:20:31Z on its Closes reference, and the assignee was released with it. There is no claim to re-examine, so the tripwire had nothing to fire on and its retraction costs nobody anything.

It was recorded as retracted on #192's task list at 22:3xZ yesterday and not here, which left the promise standing live on this page for a day — a settled call has to reach every body that states it, not just the nearest one. The body is triage's, and it is struck there in this same tick rather than left for the next reader. No new tripwire is set: nothing on rig's board waits on this run, so a deadline here would be theatre.

4 — what this door is now, stated plainly. rig has no open issue and no open pull request — the board is empty, main is at 34c03a9, VERSION is 0.3.3-dev, changelog.d/ holds four fragments and no cut is in flight. This thread asks for evidence on seven acceptance criteria across three already-closed issues, and for nothing else. Nobody is idle for it and nothing is blocked on it; the drill-recorded guard is still the backstop that stops the reworked instrument shipping unexercised past whatever cut eventually opens.

Both answers named in clause 6 of the last comment remain available and still cost one sentence: paste a run — a failed run is a valid answer and is pasted the same way — or say "it rides the next cut", and triage records that on #193, #194 and #195 as the wake for their remaining criteria and closes this door.

[dan-claude-bot]

Premise update, 2026-08-31 14:2xZ — two clauses on this page went false today, and the runbook gets simpler: the instrument is on main now, so this run no longer needs a fork. The ask itself is unchanged, still executable, and still asks nothing of any assignee.

Polled 14:1x–14:2xZ rather than recalled.

1 — what went false

a. "rig's board now holds no open issue and no open pull request" (the 20:4xZ comment, in the paragraph that explains why no new tripwire replaces the struck one). #204 was opened at 13:05Z — the 0.3.3 window, on @danmt's direction. So the board holds one open issue again.

What that does not change: it is an epic + release issue with no queue label and no assignee, its window is shut until @danmt opens it, and it has no members. Open PR count is still zero. So the sentence that mattered — nothing waits on this run, nobody is idle for it — is still true, and the reason a deadline here would be theatre is unchanged.

b. "which number carries this narrowing is the open question on [discussion #197]" (this door's opening body, under What to do with the output). @danmt answered #197 today — "lets do both into the same epic whether its 0.3.3 or 0.4.0 i dont really care that much, i just want to make sure we dont lose the research points" — and that thread is closed as resolved. The number is decided at the cut, not before.

c. What survives, and now for a second reason. "No drills/ commit is asked of this run" still holds. #204 carries its own drill criterion, and it is a different artifact: a record committed on the cut branch at the window's head. There is no cut branch, so there is nothing for a record to be committed to. The run this door asks for remains acceptance evidence and nothing more.

2 — the runbook, re-derived rather than assumed, and it shortens

PR 199 merged on 2026-08-29, so the instrument is on main. Measured just now:

fetched	HTTP	bytes	sha256
heavy-duty/rig@main → drill/drill.sh	200	34,334	23f1796e5aa081489f75afff6960d0166bbe268134248a29ce5d0b20a22eb82c
andriujoseba/rig@build/195-one-command-drill (this door's original)	200	34,334	identical
checkout of main at 34c03a9	—	34,334	identical

Byte-identical, so either form runs the same instrument — a prepared run against the fork is not wrong. But main is the better subject: it is the tree that actually shipped, it does not depend on a fork branch surviving, and --rig-ref main installs the rig whose behaviour these criteria are about.

The command is drill/README.md's own block with the refs substituted — read that file, not this paraphrase; every flag below is required by the harness or by a refusal it enforces at the door:

RIG_REPO=heavy-duty/rig
RIG_REF=main
TS_AUTHKEY=tskey-... bash <(curl -fsSL \
  "https://raw.githubusercontent.com/$RIG_REPO/$RIG_REF/drill/drill.sh") \
  --rig-repo "$RIG_REPO" --rig-ref "$RIG_REF" --box-ref 0.9.0 \
  --users-from-github danmt --run-id drill-2026-08-31-a --yes

--box-ref 0.9.0 is still the right pin: commands/bootstrap.sh:737 reads BOX_RELEASE=0.9.0, and --box-ref is a tag on purpose. The three things that stop a run at the door are unchanged and all three are in that README: --yes (no TTY → exit 2), the machine (box new drill-rig --template blank --vm --cpu 4 --memory 8GiB --disk 60GiB — never staging-box, never a container), and the entry path (incus exec drill-rig -- bash -l, or unset SUDO_USER; box shell is refused by name).

3 — the ledger is unchanged, and nothing has ticked

Six criteria across three closed issues (#193, #194, #195), exactly as the 22:4xZ comment listed them. The reworked drill has still never been run, and this thread has still held no comment from anyone but triage since it opened.

One thing worth adding, because #204 changes where the debt lands if this run never happens: the window's own drill runs at the cut, on a branch that is red on drill-recorded by construction until its record is committed. That is the worst place to discover that the instrument's first real end-to-end run fails — a red release head, with a builder and a panel already on it. A run today is the same work, spent where a failure is free. A failed run is still a valid answer; two of #195's criteria are refusals that must fire.

4 — what this door asks, unchanged

One session, stdout pasted whole. Post it here or on #195 — either is fine now that #195 is closed; triage does the bookkeeping against the criteria in both cases.

No tripwire replaces the struck one, and nothing here sets a flag: no issue on this board is claimed or assigned, needs-ruling names a decision and this is an act, and attention on an unassigned issue would be a board bug rather than a demand. If the run is not happening this cycle, saying so here is a useful answer — it is still the one outcome that leaves this debt invisible.

[dan-claude-bot]

Premise update, 2026-09-02 — do not run the command block on this page. Every line of it is now wrong in at least one way, and a session spent on it would produce a record that discharges nothing. The ask itself is unchanged in kind and still asks nothing of any assignee; what moved is its shape and its wake. Polled rather than recalled.

1 — the runbook on this page is superseded, in four independent ways

the page says	why it no longer runs
--rig-repo "$RIG_REPO" --rig-ref "$RIG_REF" off andriujoseba/rig@build/195-one-command-drill	@danmt, today: "the rig drill needs a RIG_REPO and RIG_REF, etc… that's lame." #220 deletes both flags and both environment variables outright, and its acceptance criterion is that neither name survives anywhere in drill/drill.sh. The fork ref may still resolve — that is reachability, not the right subject. #195's instrument has been on main since PR 199 merged.
--box-ref 0.9.0	the live window is #206, rig 0.3.3 integrating box 0.10.0, which box published 2026-09-02T16:54:12Z. A 0.9.0 run drills the version this release exists to replace.
box new drill-rig --template blank --vm …	box 0.10.0 refuses that command — "--template blank is retired — omit --template for a blank box". #208 fixed rig's own pages for this on 2026-09-02; this discussion page was outside that grep and still prints it.
"Not staging-box — that template converges rig at mint through BOX_BOOTSTRAP_ROLE"	box#214 removed the mint hook, the seeds' installer line and BOX_BOOTSTRAP_ROLE entirely. The warning's reason is gone; box#212 D3 kept staging-box minus rig. Whether the advice survives on other grounds — it is still VM-only and autostarting — is #208's answer, not this page's.

Two more sentences on this page have gone false and are corrected here rather than left standing: "rig's board now holds no open issue and no open pull request" — the board holds four open issues (#204, #206, #211, #220) and one open PR (#221); and "No drills/ commit is asked of this run … there is no cut branch" — #211 is the 0.3.3 cut, and under @danmt's ruling of 2026-08-21 ("the drill runs against a PR, not main") its record is committed on that cut branch.

2 — the four criteria are not orphaned, and this is where they went

Their substance survives whole — a drill runs end to end on a fresh Debian 13, the record's path and full text reach stdout, --users-from-github danmt converges the operators, and a second person follows drill/README.md without reconstructing a step. What changed is the invocation that produces the evidence, and the 0.3.3 session is what discharges them (#220 D8). #206 carries the same run as its own acceptance criterion, worded so a record produced the old way does not satisfy it:

drills/0.3.3.md comes from a run that needed no repository name, no ref, no clone and no GitHub credential on the drill host — one file copied to a fresh Debian 13, run, and a record.

The new procedure, as specified — three lines, and it is the whole thing:

# on your machine, in the checkout you want to drill
bash dist/release-artifact.sh --version 0.3.3-rc1 --assets-dir /tmp/a
scp /tmp/a/rig-0.3.3-rc1.sh root@drill-host:

# on the throwaway Debian 13, as root — no git, no credentials, no ref to retype
bash rig-0.3.3-rc1.sh
TS_AUTHKEY=tskey-… /opt/rig/current/drill/drill.sh --users-from-github danmt --yes

Neither half of that exists yet. #219 builds the artifact and is claimed by @andriujoseba with PR #221 open; #220 is blocked behind it and unassigned.

3 — so there is nothing to book today, and that is the actionable part

This door stays open and its ask stays a hard block — the run has still never happened, and silence is the one outcome that makes that debt invisible again, which is the sentence this page has always closed on. But the session cannot usefully be booked until #219 and #220 have merged, because the instrument it needs is being built right now. Booking one against the current instrument would burn a fresh host and produce a record that neither #206 nor #195 accepts.

Default: none — hard block, unchanged and for the unchanged reason. TRIAGE.md's past-24-hour rung has triage pick the option a builder proceeds on — but that rung needs an option triage can execute, and every option here is an act on a physical fresh host. No flag is set anywhere for this: needs-ruling names a decision only a human owns and this is an act, not a decision, and attention names a demand parked for an assignee, of which this has none.

No new tripwire is set here, and the reason is stated so its absence is not read as an oversight. What this run waits on is now a merge queue rather than an operator's calendar — #220 landing is the wake condition, it is visible on #206's task list, and a date-based nudge would fire against work that is actively moving. Triage returns here when #220 merges, with the runbook rewritten to the three lines above and re-derived against the tree that ships them rather than pasted from this comment.

(One thing worth carrying into the eventual record: box's own 0.10.0 drill, drills/0.10.0.md, is 71/71 but ran on Debian 12, outside box's supported host set. rig's drill wants Debian 13 anyway, so a rig run against box 0.10.0 on Debian 13 incidentally closes coverage box's own window left open.)

[dan-claude-bot]

Premise update, 2026-09-03 — the digit this door's evidence rides is now 0.4.0, not 0.3.3, and the census in the last comment has moved. The ask is unchanged in kind, still asks nothing of any assignee, and still has no new tripwire. Narrow update; the 22:15Z comment above stands in every other particular, including its central instruction — do not run the command block in this page's body.

1 — @danmt ruled the window's number, and this page quotes it by filename

On #211, 2026-09-02T23:35:19Z:

Let's do 0.4.0 and move the current 0.4.0 to 0.4.1

So #206 is rig 0.4.0 and #204 is 0.4.1. needs-ruling — set on #211 at 2026-09-02T20:45:03Z and the last flag on this board — was cleared on it; triage's close-out is there.

Why that reaches this page rather than only those issues. The comment above quotes #206's acceptance criterion as the thing this run discharges, and quotes it by the record's filename:

the 22:15Z comment says	reads now
"drills/0.3.3.md comes from a run that needed no repository name, no ref, no clone and no GitHub credential on the drill host"	drills/0.4.0.md — re-stamped on #206 in the same tick as the ruling
"the 0.3.3 session is what discharges them" (#220 D8)	the 0.4.0 session
"the live window is #206, rig 0.3.3 integrating box 0.10.0"	rig 0.4.0 integrating box 0.10.0 — the box pin is untouched by the ruling
the illustrative --version 0.3.3-rc1 / rig-0.3.3-rc1.sh block	0.4.0-rc1

drill-recorded looks for drills/<VERSION>.md and no other name, so this is not cosmetic: a session that emits the old filename is a second session. --box-ref 0.10.0 is unchanged and remains the pin this window exists for.

2 — the board census in that comment has moved, and it moved the right way

It read "four open issues (#204, #206, #211, #220) and one open PR (#221)". Re-taken 2026-09-03T01:2xZ:

• dist/ — rig publishes rig-<version>.sh: one file you scp to a fresh machine and run, with no GitHub in the path #219 merged and closed (PR feat(installer): publish standalone rig artifact #221, 2026-09-02T23:11:31Z); its one post-merge criterion was split verbatim to #222, which triage ticks against the published release.
• drill/ — the tree under test arrives on the machine, not from GitHub: --rig-repo and --rig-ref come out #220 is claimed by @cndgrr since 23:40:13Z, with PR #223 open and out of draft. That is the artifact half and the drill half now in flight together — both halves the 22:15Z comment said did not exist yet.
• The 0.4.0 cut — VERSION stamped, fragments assembled, the drill record on the PR, and the removals named where a consumer will read them #211 is blocked behind drill/ — the tree under test arrives on the machine, not from GitHub: --rig-repo and --rig-ref come out #220 alone, unassigned, carrying no flag.
• Five open issues, one open PR, nothing claimable.

3 — what this door is waiting for, unchanged

The wake is still a merge, not a calendar. #220 lands → the cut is claimed → the 0.4.0 session runs against that PR's head, per @danmt's 2026-08-21 ruling that the drill runs against a PR and never main. That one session discharges this door's four criteria, #194's and #193's live-convergence rows insofar as the roles are exercised, and #206's own "no repository name, no ref, no clone and no credential" criterion.

Nothing here asks you for anything today, and there is nothing to schedule yet: the instrument this door's evidence must come from is still being built in PR #223. Triage closes this thread in the pass that ticks those criteria against the session's stdout. A run booked before #220 merges still buys nothing — that is the 22:15Z comment's finding and the ruling does not touch it.

[dan-claude-bot]

Premise update, 2026-09-03 07:3xZ — the wake this door has been waiting on since it opened has fired. The run is bookable now, it is bookable against a real head, and this is the first update on this page that asks @danmt to actually do something.

Polled rather than recalled. The instruction from the 22:15Z comment still stands and is now the only thing on this page that matters more than what follows: do not run the command block in this page's body. The runbook below replaces it.

1 — what fired

the last comment said	what happened
"the instrument this door's evidence must come from is still being built in PR #223"	PR #223 merged 2026-09-03T05:58:40Z and closed #220 at 05:58:42Z. The instrument is on main
"#220 lands → the cut is claimed → the session runs against that PR's head"	all three. The sweep flipped #211 blocked → ready at 05:59:47Z; @cndgrr claimed it at 07:17:57Z and opened PR #225 at 07:21:46Z
"nothing here asks you for anything today"	superseded. The cut PR exists, everything a builder can produce is in it, and the only thing between this window and its tag is one hardware session

Every build member of the #206 window is closed — #207, #208, #209, #210, #216, #219, #220. There is nothing left to wait for.

2 — the run, against PR #225's head

The authority is drill/README.md at PR #225's head — read that, not this paraphrase. (That is a permalink at the head's SHA on the fork the PR is cut from, cndgrr/rig@build/211-cut-0-4-0; #225 touches only VERSION, CHANGELOG.md and changelog.d/, so the file is byte-identical to the same path on main at 93c5a68 — either address serves and both were checked to resolve.) It carries every prerequisite the instrument enforces in pre-flight, before the tailnet key is spent, and a condensed runbook is exactly how a required flag goes missing. What follows is the builder's own form, quoted from their ask on #211.

The substrate. A throwaway Debian 13 VM — not a container, and not staging-box. A fresh box VM is the known-good one:

box new --name drill-rig --vm --cpu 4 --memory 8GiB --disk 60GiB
incus exec drill-rig -- bash -l     # NOT `box shell` — see trap 4

The three lines. The first two on your machine, in a checkout of build/211-cut-0-4-0; the third on the throwaway, as root:

bash dist/release-artifact.sh --version 0.4.0 --assets-dir /tmp/a
scp /tmp/a/rig-0.4.0.sh root@drill-host:

bash rig-0.4.0.sh
TS_AUTHKEY=tskey-... /root/.local/share/rig/current/drill/drill.sh \
  --box-ref 0.10.0 --users-from-github danmt --run-id drill-2026-09-03-a --yes

Four traps, each of which costs a re-run. They are the ones #220's D2 corrected, and they are the builder's list rather than a fresh one:

1. --box-ref 0.10.0 is required. The harness refuses to start unpinned and aborts if the box that installed disagrees with the one asked for.
2. The entry path is /root/.local/share/rig/current/drill/drill.sh. install.sh:58 is DEST="${RIG_HOME:-$HOME/.local/share/rig}" — never /opt/rig, which earlier versions of these bodies wrongly said.
3. A Debian 13 VM, not a container and not staging-box — the drill converges an Incus host.
4. Enter as root with no non-admin SUDO_USER. box shell preserves one and is refused by name in pre-flight.

The record's filename is not something you can get wrong from this command. --version names the asset file only — dist/make-installer.sh:82: "tree's own VERSION file names the install directory, so it is not rewritten" — and the drill takes the record's name from the installed tree (drill/drill.sh:721, :744). VERSION on that branch is bare 0.4.0, so the record lands at /root/drills/0.4.0.md, which is the one filename drill-recorded looks for.

A failed run is a valid answer and is pasted the same way. It names what the instrument does on real hardware, which is the whole point.

3 — what the one session buys, so it is not run twice

Paste the complete final stdout on #211. That single paste discharges:

• this door's four criteria on #195 — the end-to-end run, the record path and full text on stdout, --users-from-github danmt converging operators, and a second person following drill/README.md without reconstructing a step;
• #224 in full — it is that criterion and nothing else;
• The 0.4.0 cut — VERSION stamped, fragments assembled, the drill record on the PR, and the removals named where a consumer will read them #211's two record criteria — the record is real rather than waived, and names --box-ref 0.10.0 with the rig tree measured off VERSION/SOURCE_COMMIT/INSTALLED_FROM;
• rig 0.4.0 — integrate box 0.10.0: the pin, the renamed profile, the retired template, and the edge box stopped carrying #206's own "no repository name, no ref, no clone and no GitHub credential on the drill host", and its operator-owned "no page in rig prints a box new command box 0.10.0 refuses", whose evidence is free on a host that has box 0.10.0 installed;
• drill/ — the tree under test arrives on the machine, not from GitHub: --rig-repo and --rig-ref come out #220's leg-1 criterion, reclassified operator-owned by triage this morning — its mechanism is proved at the head, but "leg 1 completes on a machine" is not a fixture's to show (record).

Triage ticks each set where it lives and closes this thread in that same pass.

4 — what is not a reason to wait

PR #225 is red, and the red is the design. It fails drill-recorded and only that — the record is not in the diff because the builder does not write, fake or waive it (D4), and this is the guard doing its job. Every other check at head c85efad is green: shellcheck, cli, release and drill suites, changelog-armed, changelog-monotonic, changelog-assembled, install, db-integration, refs-not-closing. (runner-isolated, sha-pinned and docs-sync are skipped rather than green — the four release guards are sequential steps of one job, so they get no verdict until the record turns it green. That is the known sequencing defect carried as a candidate on #204; it costs this cut one re-run and nothing else.)

Nothing here asks the assignee for anything. @cndgrr's claim is parked — confirmed by triage this pass — and no push of theirs produces this evidence; CONTRIBUTING.md bars a builder session inside a box from running the host drill at all.

5 — the tripwire, which is triage's and not yours

A parked claim carrying an open PR is invisible to the 48-hour reclaim sweep by construction, so this wait again has no automatic floor. If no stdout has landed on #211 by 2026-09-05T07:2xZ, triage re-examines the park, re-derives whether this is still the right thing to book, and refreshes this door. It is not a deadline on you and it moves nothing on the board by itself.

One thing worth putting in the record if it holds. box's own drills/0.10.0.md is 71/71 on Debian 12, outside box's supported Ubuntu 24.04 / Debian 13 host set. A rig run against box 0.10.0 on Debian 13 incidentally closes coverage box's own window left open.

[dan-claude-bot]

Premise update, 2026-09-03 17:1xZ — the session this door has asked for since it opened has happened. The door does not close, because what it asks for changed shape rather than being spent: three of its seven rows are answered, one was answered in the negative, and the outstanding half was parked on an issue that has since closed.

Measured this pass against the committed record and the criteria's own text, not recalled.

1 — the run

@danmt ran the 0.4.0 drill on 2026-09-03T14:48:35Z against PR #225's head c85efad, by the three-line artifact procedure the 07:2xZ comment above set out. The record and the operator's diagnosis are on #211; @cndgrr committed the record verbatim as drills/0.4.0.md at 470f8d2, @danmt merged at 15:37:39Z, and 0.4.0 is published.

Checks: 12 passed, 2 failed, 1 skipped.

A failed run was always a valid answer here and this one is a real record — #211 D10 ruled that a red record ships and neither failure re-runs it. Nothing below is a complaint about the result.

Do not run the 07:2xZ runbook again, and do not run the one in this page's body. The first is spent; the second has been superseded since 2026-09-02 and every line of it is wrong.

2 — the seven-row ledger, re-priced against what the record actually says

The ledger is the one this door has carried since the 22:4xZ comment of 2026-08-29. It comes out of this pass in three states, not two.

Rows 1–4 — #195's four. Answered by the run; the tick waits on a paste, not a machine

Triage read these criterion by criterion at 15:12Z and ticked none. The reason is the paste's contents, not the run's verdict: what landed is the record, and three of the four are only visible in the stdout around it.

row	where it stands
1 — end to end on a fresh Debian 13, no checkout, writes a record	the record corroborates every clause — Debian GNU/Linux 13 (trixie), kvm, INSTALLED_FROM … artifact:rig-0.4.0.sh sha256:977302aa… (the one-file channel, not a clone), and Candidate box: box@unresolved, which is ref_sha's documented output on a machine with no git. The criterion's own named evidence is still the complete final stdout
2 — the record's path is printed and its full text is on stdout	the full text ✓. The printed path cannot be in the record: publish_record emits record written: /root/drills/0.4.0.md before the text
3 — --users-from-github danmt converges, asserted by leg 1's own operator check	leg 1 is PASS (35s). That is the verdict, not the operator/account/key lines that produced it, and the record does not show which flag was used
4 — a second person follows drill/README.md without reconstructing a step	the operator's own statement is owed. And there is something specific for it to answer: the record's host line reads 2 vCPU / 4 GB RAM, against the --cpu 4 --memory 8GiB this criterion's Surface clause names as known-good. A documented line not followed verbatim is exactly what row 4 exists to surface

All four tick off one paste. @danmt's own comment reports the original stdout preserved locally with SHA-256 checksums, so nothing here books a second machine.

Row 5 — #194's leg 2. The run answered it, and the answer was no

The criterion, verbatim: "The drill's leg 2 runs a real round-trip on a machine that never had Docker, and the record says PASS, not SKIPPED."

The record:

| test/db-integration.sh | SKIPPED — docker not installed — nothing to exercise |
- FAIL: Docker package installation exited 0 but the daemon does not answer
Skipped — these did NOT run, and this record is not evidence for them:
- SKIP: db round-trip did not run — skip: docker not installed — nothing to exercise

This row is not merely un-discharged — the session booked to discharge it produced the exact word the criterion excludes, and this door never priced that possibility.

The cause is known and is not the machine's. #228 measured it: drill/drill.sh:881 collapses "no docker on PATH" and "the daemon does not answer" into one && chain and one message naming only the second, and polls neither — so the daemon was ready one second after the harness gave up. @danmt's diagnosis says the same: "a readiness race in the drill scaffolding."

The consequence for this door is a dependency it has never carried: row 5 is not bookable by anybody. #228 is closed as folded and its spec rides #204 as Candidate B, unminted, in a window that is shut. Until that fix ships, every future drill reproduces this same SKIPPED — which is precisely the compounding cost the fold comment flagged it for. Booking a machine for row 5 today would burn it.

Rows 6–7 — the two role passes. Untouched, and each still needs its own guest

The run converged staging-server — "convergence — bootstrap staging-server reaches its role | PASS (35s)". Neither role criterion was in its path:

• #194: "rig bootstrap control-plane-server --users <file> still converges unchanged"
• #193: "rig bootstrap runner-server --users <file> still converges: role marker, tag:ci, and the tag:server refusal all unchanged"

Each is the same invocation with --role <name> on its own fresh guest — a converged machine is not a scratch machine, so they do not stack — and runner-server needs a key minted for tag:ci, not the tag:local the default role uses and not tag:server, which that role refuses by design. Both remain strictly optional; nothing waits on them.

3 — why this door stays open, stated plainly

Because the outstanding ask lost its page. #195's four criteria name their wake as "the operator pastes the complete final stdout on #211" — and #211 closed at 15:37:41Z on PR #225's Closes, minutes after triage wrote that ask onto it. #195 itself has been closed since 2026-08-29. An obligation with no open page evaporates; this door is the open page, and it was built for exactly this class of act.

What it asks for now, in full:

1. The paste — @danmt's complete final stdout from the 2026-09-03 session. Here or anywhere on this repo; triage does the bookkeeping either way. No machine, no re-run. Discharges rows 1–4.
2. Optionally, the two role passes (rows 6–7), each on its own fresh guest, runner-server needing a tag:ci key.
3. Nothing at all for row 5, which is now a code fix ahead of a machine.

One thing worth knowing about the ordering, and it is the only thing here with a clock: rows 1–4's evidence already exists and lives on one person's disk. Everything else this door has ever asked for could be produced again on demand; that transcript cannot, if it is lost. That is an argument for the paste being the cheap thing to do first, not a deadline on anyone.

4 — the tripwire in the 07:2xZ comment is retracted, spent rather than fired

It read: "If no stdout has landed on #211 by 2026-09-05T07:2xZ, triage re-examines the park, re-derives whether this is still the right thing to book, and refreshes this door."

The park it watched ended two days before that deadline. @cndgrr's claim on #211 was unparked at 15:20:30Z, the record was committed at 15:12–15:24Z, the PR merged at 15:37:39Z and #211 closed. There is no park left to re-examine. This comment is the refresh it promised, delivered early and by the event rather than by the clock.

No new tripwire replaces it, and the reason is stated so its absence is not read as an oversight. rig's board is one shut release window with no queue label, no assignee, no open PR and nothing claimable; nobody is idle for this and nothing is blocked on it. A deadline here would be theatre, which is this door's own standing finding and is unchanged.

Nothing here sets a flag. needs-ruling names a decision and every item above is an act; attention names a demand parked for an assignee, and there is no assignee anywhere on this board.

[dan-claude-bot]

Premise update, 2026-09-04 — one row is restored to this door's ledger, and three bodies closed on the 0.4.0 session now say what they discharged. The ask is unchanged and nothing new is owed by anyone.

Measured this pass against the closed bodies and this thread's own comments, not recalled.

1 — the row the re-pricing dropped: #220's leg-1 criterion

The 07:2xZ comment listed, among what the one session buys:

#220's leg-1 criterion, reclassified operator-owned by triage this morning — its mechanism is proved at the head, but "leg 1 completes on a machine" is not a fixture's to show.

The 17:17Z re-pricing does not mention #220 anywhere. That was not a judgement about the criterion — it re-priced the seven-row ledger this door has carried since 2026-08-29, and #220's criterion was never one of the seven; it was added a fortnight later, as an extra beneficiary of the same paste. Re-pricing the seven silently dropped the eighth.

Where it stood while nobody was looking. The criterion is:

Leg 1 completes on a machine where /root/.local/share/rig/current/drill/drill.sh is the running script — the reinstall never deletes the tree it is executing from.

It is operator-owned, reclassified in #220's body at 07:21Z on 2026-09-03, and its wake condition read "the 0.4.0 session's stdout pasted on #211 — the same paste #224 waits on." #211 closed 2026-09-03T15:37:41Z and #224 closed at 15:40:27Z. So an operator-owned criterion on a closed issue was waking on a paste to two closed pages, and had been dropped from the one open page that tracks that paste — which is the shape this door exists to catch, stated in its own words: an obligation with no open page evaporates.

Re-homed here today, in #220's body where the criterion stands rather than only in this comment. It books no second machine — the transcript exists on @danmt's disk with SHA-256 checksums, and this is the same paste rows 1–4 ride.

2 — what the paste discharges, corrected

rows 1–4 — #195's four operator-owned criteria	unchanged from the 17:17Z reading
#220's leg-1 criterion	restored to this list today. Needs one line of the stdout: leg 1 passing, from a drill invoked at /root/.local/share/rig/current/drill/drill.sh
#224's criterion	discharged and off this list — ticked against the committed record on @danmt's ruling that the post-merge remainders close on the drill that ran. Nothing on #224 waits on the paste
#211's, #206's window criterion	#211's record criteria were ticked at its close-out; #206's two carried remainders live on #204's body, where release-init reads them
row 5 — #194's leg 2	unchanged: not bookable by anybody until the drill's Docker prerequisite is fixed (0.4.1 candidate B). Nothing to run
rows 6–7 — the two role passes	unchanged, still optional, each still its own fresh guest, runner-server still needing a tag:ci key

So the ask on this door is exactly what it was, with one more thing riding it: the complete final stdout of the 2026-09-03 session, here or anywhere on this repo. No machine, no re-run.

3 — three bodies were closed with their ticks unwritten, and that is fixed

Found by re-reading the closed pages rather than the comments on them, which is what turned up §1 as well:

• #222 — its close-out comment is headed "Ticked and closed" and no box on the issue moved. Ticked 2026-09-04 with the evidence re-run in the criterion's own stated commands rather than read off that comment: both assets on the 0.4.0 release, sha256sum -c printing rig-0.4.0.sh: OK against the asset as downloaded, and the artifact hook step succeeding in job release / release-on-merge with release-on-tag skipped.
• #224 — same shape, same fix, with the tick carrying the two readings its close-out stated rather than hiding them. Its operator task row carried two acts in one checkbox — run the drill and paste the stdout on The 0.4.0 cut — VERSION stamped, fragments assembled, the drill record on the PR, and the removals named where a consumer will read them #211. The run happened; the paste did not. The row is split in the body, left unticked, and the paste's half re-homed here.
• #220 — the wake re-homing in §1, plus the strike of a sentence saying The 0.4.0 drill session — the end-to-end run on a fresh Debian 13 that #220's instrument exists to make possible #224's criterion "still wakes on that paste landing on The 0.4.0 cut — VERSION stamped, fragments assembled, the drill record on the PR, and the removals named where a consumer will read them #211", which stopped being true when that criterion was ticked on the record instead.

Nothing here sets a flag and nothing asks the assignee of anything, because there is no assignee anywhere on this board. rig's open board is still one shut release window (#204), no queue label, no open pull request, nothing claimable — so nobody is idle for this paste and nothing is blocked on it. No tripwire is set, for the reason this door already gave twice: a deadline with nothing waiting behind it is theatre.

— triage, 2026-09-04