Operator act needed: run the 0.3.2 drill — #107 has had no open door since 0.3.1 shipped waived #173
Replies: 19 comments 1 reply
|
The request now has a release attached to it: #182, the 0.3.2 window, states a real drill record as an acceptance criterion of the release. That is not a new door — this thread is still the door, and it is still addressed to you. What it changes is that 0.3.2 cannot be described as meeting its criteria without Board movement since this was opened, in case it changes when the afternoon is worth spending: #148 closed on your ruling C this morning, #154 and #181 are That is an argument about timing, not about whether. The prerequisites in the body are unchanged, including the one that has bitten before: If the answer is a third waiver, #182 records it as a decision on #107 rather than as a release that quietly met its criteria — the epic says so in those words. |
|
Update — the last thing you were reasonably waiting on landed today, and rig's board is now this request and nothing else. When this request opened yesterday, 0.3.2 still had build work in it and a moving registry pin, so "run it when the afternoon comes" cost nothing. Both of those are gone as of 19:17Z today:
So the board is empty except for you. Zero Nothing in the prerequisites has changed. Restated so this reply stands alone:
And the other answer is still a legitimate answer. If 0.3.2 ships waived, say so here in those words and I will record it on #107 as a third waiver decided — struck, not quietly met — strike criterion 2 from #182, and mint the cut in the same pass. That is the faster route to a tag. It is worth naming what it costs: Either way, one word here moves rig. It cannot move on silence. |
|
I want to run a drill for 0.3.2 - but I think it might be better to release rig-templates 0.1.0 so we pin rig to it. @dan-claude-bot |
|
Recorded as option A — no third waiver — and the pin idea is right, with one ordering correction. The board is updated; you owe one afternoon and nothing else. Pinning rig to a released registry is worth doing and its form is already ruled: D3 on rig-templates#8 — the pin carries the tag's commit SHA with the tag legible beside it, because the value resolves code that runs as root and a tag is mutable. rig's half is minted as #187, The one correction: the registry cannot be released before the drill — that order is a cycle. Your own D1-A ruling (2026-08-19 14:15:30Z) binds It still costs one afternoon, not two:
Why the drill's evidence survives the pin moving after it. The session runs at rig's current pin That reading is mine, it applies a doctrine already shipped here rather than inventing one, and it is reversible on one word until the tag is cut. The alternative is two sessions — drill, cut the registry, bump the pin, drill again — which costs a second afternoon and needs D1-A amended too, since neither session would then be "the one that produces both records". Say the word here if you want it that way. For the session itself — unchanged: a throwaway Debian 13 machine, a tailnet pre-auth key, a users file, a fork for the runner leg, a Two mechanical notes, both of which have bitten this family:
|
|
@dan-claude-bot the drill for rig-templates has nothing to do with the drill of rig. Those are separate things. I'd go further and say that rig-templates drill is a very simple thing, some simple checks, smoke-style. We should have an issue for rig-templates drill definition that blocks 0.1.0 release, once the drill definition is there, 0.1.0 opens up, once cut rig can integrate 0.1.0 and then release 0.3.2 |
|
Recorded — D1-A is overturned, the cycle dissolves, and rig's board no longer routes the registry's release through your afternoon. Applied to rig's three open issues in this tick. One question is yours before the registry board can mint the issue you asked for. You are right and the correction is sharper than a workaround. At 12:14Z I treated D1-A — " What changed on rig's board, done now
No label moved, because none of them stopped being true — both open issues are still The 0.3.2 route as you described itHead A no longer contains an operator act. Head B is one afternoon and is the only thing on rig's board with your name on it. They are concurrent — nothing in head B waits for head A or the reverse. One consequence worth having in writing, since it is the only place the two heads still touch: if your afternoon comes after #187 lands, the drill converges the registry at exactly the commit 0.3.2 ships and #182's third acceptance criterion reads literally, with #187's compare gate reduced to belt-and-braces. If it comes before, the run cites The registry's drill-definition issue — one answer decides its shapeThat issue belongs on rig-templates' board and I will mint it there, but not from "some simple checks, smoke-style": that names the class honestly and a builder cannot execute it without asking you, which is the thing I am supposed to absorb rather than forward. Your words map almost exactly onto an option already written on that board — D1-B, the one I did not recommend in August: "adopt the gate with a narrower meaning: I am reading your comment as re-ruling D1 from A to B, and I have recorded it that way on rig-templates#8 and #15. Say the word here if that is over-reading it. Two questions decide the rest, both with a default, so one word each is enough:
The first deliverable either way is rewriting Nothing on rig's board waits on those two answers. Head B is yours whenever the afternoon comes; head A is blocked on a mint that is blocked on you for one word. |
|
Follow-up to the two questions above: they are now one flagged ask on the registry's own board, with a deadline attached — so this does not sit on a discussion thread nobody's board shows. @danmt — nothing new is being asked. The two questions from
Default: A at One word here — converge, lint only, or hand-write it — mints the issue in the same tick and opens 0.1.0's path exactly as you described it. Your drill afternoon is not waiting on any of this, and neither is rig#107. |
|
|
Recorded — option A, and the issue you asked for is minted: rig-templates#16, Both answers are applied, on rig-templates#8 (where D1's record lives) and on #15 (the cut). What #16 says, so it does not have to be read to know what was decided
Your second answer is written in as a design constraint, not a preference. "If it's hard to drill, it will be waived" is why the converge needs no credential of any kind, why the default definition is the one no third party can red, and why a real finding does not make the script exit non-zero — a drill that fails loudly at people is one they stop running. One correction to the option you ruled on, since half of its argument does not survive this repo's permissions. I recommended A as costing "a CI job, not a machine". A The two boards, after this tick
Head A is now three builds and no operator act, exactly as you drew it on Thursday. The only thing in this family with your name on it is the rig drill session, and nothing in it has changed since This thread stays open as that session's door. Nothing else here is waiting on you. |
|
Head A landed — the last thing in the 0.3.2 window that was not your afternoon is done. Nothing new is being asked here; one prerequisite moved. @danmt — you merged PR #188 at What changed for the run: the tree. It is
One thing got simpler. The pin bump landing before the session means the drill converges the registry at exactly the commit 0.3.2 ships, so #107's fourth acceptance criterion now reads literally for all three pinned refs — there is no longer a two-SHA comparison for the record to carry. Recorded on #107. Everything else stands: prerequisites in |
|
Correction to the runbook, and it would have cost you the first ten minutes of the afternoon: the command I have been posting here omits two flags What was wrong
That refusal is the point of the harness — since #103 both installers have sane defaults, so an unstated ref silently drills the shipping pair instead of the candidate and leaves a record that looks like evidence. The command, corrected and completeOn the throwaway Debian 13 machine, as root, from a checkout of this repo: TS_AUTHKEY=tskey-... bash drill/drill.sh \
--rig-ref main --box-ref 0.9.0 \
--record drills/0.3.2.md \
--users ./drill-users --run-id drill-2026-08-<dd>-a \
--coolify-version 4.1.2 --runner-repo <you>/rig --yes
Legs run 1, 4, 2, 3, unattended after setup. A failing check never aborts the run. A failed drill closes #107 — the gate wants evidence, not success. The decision behind
|
|
Given that we have a circular dependency: rig uses box for machines that need to run vms, box uses rig for prepping the env within a VM. The box side seems like a harder constraint. Anyway, I think we have to figure out the right way to do this. I'd like both to have the latest version but seems impossible, my idea was release rig 0.3.2 with box 0.9.0, once box 0.10.0 is released, we pin it in rig and release 0.4.0 - but then box would be using an old release lol. Idk what to do, how can we figure this out @dan-claude-bot |
|
There is no cycle to break, and the measurement says so: the two edges are different kinds of edge. rig pins box with a hard-coded tag; box does not pin rig at all — it resolves rig's release at mint time. So box tracks rig for free, and only rig→box costs a release. Your plan works as stated, and "box would be using an old release" is not what happens. Measured just now, not recalled. The two edges
That asymmetry is the whole answer. A pinned constant needs a release to move; a runtime lookup does not. box catches up to rig by itself, on the next mint, the moment rig publishes a tag. So after you merge 0.3.2 and the door tags it, every box that mints a guest resolves The one thing that is wrong today, and it is the opposite of what you fearedbox 0.9.0 and 0.9.1 — the two that are published — read: rig_ref() { printf '%s\n' "${RIG_REF:-main}"; }— A released box converges its guests against rig's development tip, not an old release. That is box#150, which you closed yesterday at Honest caveat on the pair 0.3.2 ships, stated because you should hear it from me rather than find it: rig 0.3.2 + box 0.9.0 is a pair whose guest side converges rig So the order, with nothing waiting on anything
Nothing in that sequence waits on anything else in it. The recursion is real; the deadlock is not, because step 2 needs no input from step 1. What is still yours to decide, and it blocks nothingWhich rig window carries the No flag is set for this and none is owed. It gates no open issue: the bump issue does not exist yet and should not — it would be Nothing on the board moved for any of thisRe-measured against |
|
Box@0.10.0 is bumped in rig@0.3.3 --- I see that we don't have a deadlock, but box should never use the development tip, it should use the latest release, even then, it's a bit weird that you use the latest of rig and it could have some issue or whatever with box but that's unlikely and you can pin to a specific rig version in box, but still seems odd. I wonder if there's another solution, like a middleware of sorts. Note: if the best solution is rig pinning box and box using the latest release with optional pinning, that works fine for me. Although it seems still a bit odd and I'd like to know if there are other alternatives. |
|
Two things: your naming call is recorded, and here is the alternatives survey you asked for — measured against both trees this morning, not recalled. Nothing on rig's board moves for any of it, and #107 is still one afternoon. 1. Recorded — box 0.10.0's bump lands in rig 0.3.3"Box@0.10.0 is bumped in rig@0.3.3" settles the one thing I left open at The wake condition is unchanged and still mine to watch: box 2. "box should never use the development tip" — on
|
| # | shape | what it costs to move | what it bounds | verdict |
|---|---|---|---|---|
| 1 | status quo after box 0.10.0 — rig pins box by tag; box floats to rig's latest, RIG_REF pins |
one line + a drill per rig window; nothing on box's side | nothing forward | works — the missing bound is the gap |
| 2 | symmetric hard pin — box pins rig by tag too | a release on each side per bump, and each side's ceremony now contains the other's | both directions, exactly | already ruled against, on box's board |
| 3 | floor — box refuses a rig older than RIG_MIN |
a semver compare and one constant | backward only | half an answer, to the wrong half |
| 4 | tested-through ceiling — box records the newest rig it drilled and warns above it | one line, written by the ceremony that already writes the drill record | forward, softly | cheap, and it is the missing half |
| 5 | the middleware — a published matrix of drilled (rig, box) pairs, resolved at runtime by both | a third ceremony, a third silent staleness mode, a third host reachable at mint | both, and retroactively | not at two repos |
| 6 | contract number — rig declares what it speaks; box checks it at the fetch it already does | defining the contract, and the discipline of bumping it | both, precisely | right end state, wrong time |
| 7 | delete the edge — rig stops installing box and prints the command it already computes | one manual step for the operator | n/a — removes the pin, not the dependency | honest; yours to weigh |
The three that matter:
(2) is not open, and your instinct about it was right. box#189 rejected it in writing while closing #150: "A literal pin — a constant in bin/box, a token in the seeds — has to be rewritten every ceremony, and the release that forgets rewrites nothing and lies silently." Not a literal deadlock, but every rig release becomes unreachable to box's users until box cuts one, and box's release drills against a rig. That is the lockstep you were reaching for at 09:53Z.
(5), the middleware, taken seriously. It has one property nothing else here has: it can be updated without releasing either side, and the evidence it would carry is evidence the drill already produces — you drill (rig 0.3.2, box 0.9.0), the pair is published, and every box in the field learns the pair is good. That is genuinely attractive and it is why the instinct is a good one. What it costs is a third ceremony to forget, a third artifact that goes stale silently, and a network dependency on a third host at mint time. Note also that it does not remove either pin — it adds an oracle both pins must then agree with. It earns its keep when the pair space is wide; here it is two repos and one supported pair at a time. Worth revisiting when the family is three — drills/README.md already shows records citing cast alongside rig and box, and three repos is three edges, which is roughly where a matrix starts beating N pins.
(6) is where this ends up if a pair ever actually breaks. It is the middleware without the third repo: the oracle lives in rig's own tree and box reads it during the fetch it already performs, so it cannot go stale relative to the thing it describes — which is the failure mode that kills both (2) and (5). I am not recommending it today, because there has never been a compatibility break between these two, and a contract number defined against a surface that has never broken rots exactly like a pin, with the added cost that it looks authoritative. Build it the first time a pair genuinely fails. The ceiling in (4) is the thing that would tell you that happened.
6. Recommendation
Keep the asymmetry, add the cheap upper bound, do not build the matrix.
Concretely: (1) plus (4) — box carries the newest rig release it has drilled, and warns at mint when it resolves something newer. One line, written by the same ceremony that already writes the drill record, and — this is the part that answers #189's objection to (2) — a forgotten bump degrades into a warning, not a lie. That is the entire difference between a soft ceiling and a hard pin, and it is why the argument that killed (2) does not touch (4).
Your stated position survives intact: rig pins box, box takes the latest rig with optional pinning. It just stops the float from being silent at the far end.
7. What that means for the boards — nothing, unless you say so
Options (3), (4), (5) and (6) are box-side; rig's share of all four is zero lines. Under your own process ruling — "if you need to apply changes to another repo the process is to file an issue there" — none of it is minted here, and none of it should be minted out of this thread's prose either.
box has no discussion on this; its only open discussion is the welcome post. Say the word and I open one on box's board carrying this survey, and box's triage takes it from there. If you would rather it be narrower, say "the ceiling" and it goes as that one proposal.
No flag is set and none is owed. It gates nothing: box 0.10.0's window does not contain it, rig 0.3.3 does not exist yet, and rig 0.3.2 is untouched by every option above.
8. The board, re-measured before writing
main at cc6af3e: VERSION is 0.3.2-dev, drills/ holds 0.3.0.md and 0.3.1.md and both are waivers, changelog.d/ holds the same fifteen fragments, no open PRs, no claims. #107 blocked, #190 blocked behind it, #182 the window. Nothing moved for this comment — the single board write was D5's amendment on #190 recording 0.3.3.
One caveat restated, because it is the pair 0.3.2 actually ships and it belongs beside everything above: box 0.9.0's guest side converges rig main. That is box#150 unreleased, already fixed in box, and it is a reason to want box 0.10.0 — not a reason to hold rig 0.3.2.
The corrected command stands unchanged, --box-ref 0.9.0 included. This thread is still the door for the afternoon.
|
I agree but then I believe #190 should be unblocked if this doesn't affect rig's board. On the other hand, regarding box, yes please add the stuff that matters to box into a conversation @dan-claude-bot |
|
Both done. box's discussion is open and carries the survey. On #190: your premise is right and it does not reach that issue — #190 was never blocked on the box question, so there is nothing there to unblock. One word of yours does unblock it today, and it is the word you ruled against yesterday. Re-measured before writing; no label moved in this tick. 1. box — heavy-duty/box#205Opened under Ideas, addressed to box's board, and it says in its first line that box's triage owns everything that follows. What it carries:
My read is recorded there as a read, not a directive: worth one issue in a later box window, not 0.10.0, because landing it inside 0.10.0 would want the very drill run that is that window's last gate. box's triage may narrow it, re-window it, or decline it, and the survey is the record of why either way. 2. #190 — what it is actually blocked byThe premise is true: none of the box work touches rig's board. It just is not what holds #190. Label events re-read on What #190's Measured on 3. Why I am not flipping it anyway — the label would send a builder into a red PRThree mechanical facts, not a preference:
And the flip costs nothing when it becomes true. #190's declaration is a plain local issue reference, so the sweep moves it 4. The one thing that unblocks #190 today, and it is yoursSince you asked for it unblocked, the honest option set is two entries:
You ruled A on 5. The board after this tick
This thread is still the door for the afternoon. |
|
I'll manually close #107. Here's the thing, the drill runs against a PR, not main, otherwise you could drill something newer that's not making the cut. The flow is: file release issue -> PR to cut the release, changelog, etc -> Run drill (if the builder can, they run it, otherwise an operator runs it) In the case of the builder is close shut. Part of the work is running the drill and filing the evidence. For the operator is slightly different but the same in nature, the operator runs the drill and posts the evidence as a comment in the underlying issue. It's fine that the PR remains red until the drill is there, that's on the operator. If somehow this isn't part of the doctrine, file it as a discussion in ceremony. |
|
Done, and the answer to your conditional is: it is doctrine already — in four places, all at rig's own pin. No ceremony discussion is owed, and the route this window was built on was never what the doctrine said. #107 is closed out, #190 carries the drill, and it was claimed three minutes after your close. One correction I owe you is in §4. 1. The board, four minutes of it
Board now: one open issue, 2. Your conditional, answered — the doctrine already says thisYou wrote "If somehow this isn't part of the doctrine, file it as a discussion in ceremony." I checked before filing anything, and filing would have been noise:
So the doctrine was right and this window's route was wrong. #107 minted a record-on- One thing genuinely is not written anywhere: who runs it, and how an operator-run record reaches the branch. 3. What moved on the board
4. The
|
|
Closing this door — the act it asked for is done, and the one question that outlived it now has a thread of its own: #197. This thread opened on 2026-08-18 because #107's gate was an operator act with no open door. It has one outcome now, and it is the one it asked for. What discharged it
What is still live, and where it movedYour ruling here at Nothing is lost by closing — the record above stays citable, and #195's D5 still points here for the who-runs-the-drill rulings it owes |
Uh oh!
There was an error while loading. Please reload this page.
@danmt — 0.3.2 needs a real drill run on real hardware, and this is the request. There has not been one since 0.3.1 shipped waived.
Opening this because #107's gate is an operator act and the act has had no open door for 24 days. The previous door, discussion #132, was scoped to 0.3.1 and closed 2026-07-25 10:41Z when you ruled "Add a waiver as the drill" on PR #145. That ruling was answered and the thread closed correctly — but the debt rolled forward to 0.3.2 and nothing asked for the 0.3.2 run. #107 has been sitting
blockedon a request that no longer exists, which is exactly the shape TRIAGE.md names ("an operator act with no door is how ablockedissue goes quiet while the board reads as converged"). This thread is that door.State, measured against
mainatcea572ftodayVERSION0.3.2-devdrills/0.3.0.md,0.3.1.md— both waiversdrill/drill.shonmainsince PR #125 (2026-07-24)drill/README.md, same mergeBOX_RELEASE=0.9.0(commands/bootstrap.sh:723)Both excuses the earlier records gave are spent: rig has had an instrument since 0.3.1 and a written procedure on
mainsince PR #125. A 0.3.2 waiver would be the third consecutive one, and the family already has your ruling on that shape — on box#155, after box 0.9.1 shipped on its second waiver: do not draft a third; surface the issue first. This is the surfacing, in advance, with no release in flight.What the run needs
Condensed from
drill/README.md, which is the authority — read it before running:TS_AUTHKEY.--users) naming at least one operator — leg 1 asserts operators converged.--runner-repo).--coolify-version) for leg 4, or that leg records as SKIPPED rather than passing.Shape, from the README:
One caveat, and it is the difference between a record that counts and one that does not:
drill.shnames the record from the installed tree's ownVERSION. Run it against a tree reading0.3.2, or pass--record drills/0.3.2.md— otherwise the record lands atdrills/0.3.2-dev.md, where thedrill-recordedgate will not read it.A failed drill is a valid record. The gate wants evidence, not success; a leg that did not run records as skipped, distinctly from passing. What it must not be is another waiver.
What happens after
The run happens, pass or fail → triage flips #107
blocked→ready, and the remaining builder work is the PR that landsdrills/0.3.2.mdand nothing else. That PR is an ordinary claimable task.If the run is not happening this cycle, say so here. A third waiver is a decision only you own, and #107 will record it as one rather than let the board keep reading as merely waiting. Either answer closes this thread; silence is the one outcome that leaves the debt invisible again.
All reactions