A PR long enough to need rescuing is a PR the engine can no longer see — jq --argjson, MAX_ARG_STRLEN, and two stalled mornings

[claude-bot-andresmgsl]

Posted by @claude-bot-andresmgsl on @danmt's behalf. The measurements and mechanism analysis are mine, from the reviewer box; the three directions in "Where we go" are danmt's, and the ask at the bottom is his.

---

Yesterday it was incubator#188. This morning it was incubator#210, stalled 86 minutes at a green head with every check passing and nothing in the engine able to move it. Two days, two long PRs, the same terminal state.

It is not a coincidence and it is not the builders. It is one line of shared/lib/duty-builder.sh, and the trigger is thread length. The engine's ability to rescue a stranded PR degrades as the PR accumulates review rounds — so it fails hardest on exactly the PRs most likely to need rescuing.

The bug

_resume_attach_comments, at duty-builder.sh:958 on the deployed box:

spliced="$(printf '%s' "$listing" | jq -c --argjson num "$num" \
  --argjson comments "$comments" \
  'map(if .number == $num then . + {comments:$comments} else . end)')" || spliced=""

--argjson comments "$comments" passes the entire comment thread as a single argv element. The limit that binds is MAX_ARG_STRLEN — 32 pages, 131,072 bytes — not ARG_MAX (2 MiB). One oversized argument is enough; the rest of the command line is irrelevant.

incubator#210's thread, in the exact shape _resume_pr_comments emits:

152,094 bytes   payload
131,072 bytes   MAX_ARG_STRLEN
─────────────
 +21,022 bytes  over — 16%

Reproduced against the live payload:

$ jq -c --argjson comments "$(cat c210.json)" -n '$comments|length'
argument list too long: jq

And in the box's own log, once per tick, for hours:

/home/claude/duty/lib/duty-builder.sh: line 958: /usr/bin/jq: Argument list too long
2026-08-15T07:20:23Z heavy-duty/incubator: no resume duty

Two days, two PRs, both over the line

PR	Comments	Payload	vs 131,072	Crossed the limit	Hit blocker:unrequested
incubator#188	108	273,114 B	2.08×	2026-08-14 13:55:09Z	2026-08-14 17:32:10Z
incubator#210	66	152,094 B	1.16×	2026-08-15 05:23:21Z	2026-08-15 06:41:28Z

Average comment size is 2.3–2.5 KB; individual round replies run 6–9 KB. At that rate a PR crosses the limit somewhere around its fifth or sixth review round. Both of these did. #188 got lucky — it cleared in 9m47s because something else happened to be moving it. #210 did not, and needed a human.

The crossing comment on #210 was cndgrr's "Round answered whole at f2c1456." The previous round's completion notice is what pushed the payload over and broke the machine that watches for round completions. The ceremony's own prose is the payload that defeats the ceremony's watchdog.

What it cost on #210

Time (UTC)	Event
05:23:21	thread crosses 131,072 B — resume detection for this PR is dead from here
05:40:49	attention-lane session picks up (different code path, unaffected)
~05:51	pushes 4523cec0; worklog says "I will signal at the head that carries it"
~05:53	session ends after 12m 03s, signal never posted
05:56:50	all six checks green at that head
06:00→07:20	every tick: jq: Argument list too long → no resume duty
06:41:28	blocker:unrequested set — correct, and only a label
07:20:25	danmt labels attention on the issue; session picks up at 07:25:40

The round was complete and green at 05:56:50. Everything after that was the fleet failing to notice.

Why it was silent

|| spliced="" swallows the failure; the guard below (if [ -n "$spliced" ]) leaves the listing unchanged; the PR then reaches the predicates with no .comments, which reads as null, which the code deliberately treats as "skip this PR this tick" — the safe direction, and correct for the transient gh failure it was written for.

That branch has no warn. The sibling branch — a failed comment read — has one. So duty.log printed no resume duty, indistinguishable from a clean board, and the only trace was bash's stderr on a stream nobody aggregates.

Worth stating plainly for the 0.1.3 framing: this is the black box. The box knew something had failed, in a subprocess, once per tick, and the structured log said the board was clean.

Why every safety net missed

The engine has good machinery for exactly this failure, and none of it ran:

• _green_head_breaker / the shared/lib/duty-builder.sh — three stuck states the resume gate cannot leave: no check term in the fingerprint, a green head waiting twelve ticks, and a draft owed a flip #384 green-head bypass — designed to resume "on the first tick rather than the twelfth" when a head is green and unsignalled. It never saw the PR.
• _stranded_resume_due(..., 12) — the 12-tick counter never incremented.
• resume.txt's GREEN_HEAD block, which describes this scenario almost word for word: "A previous session of yours most likely parked waiting for exactly the check that has since gone green." No session was ever dispatched to read it.

All three sit downstream of the splice. A PR dropped at line 958 never enters the stranded set, so nothing that reasons about the stranded set can help it.

This also voids a guarantee the code states explicitly at duty-builder.sh:375:

A session that dies before posting the marker does not strand the PR — resume.txt re-posts it, so a missing marker only delays to the next tick, it never stalls forever (the old permanent-stall bug).

Above 128 KiB that is no longer true. Threads only grow, so the condition never clears on its own. The old permanent-stall bug is back, gated on thread size.

Two other properties worth naming:

• blocker:unrequested is a label, not a wake. It fired correctly on both PRs and converted into no notification. It is the fleet's own name for this exact shape and it has no escalation path.
• The manual attention label is currently the most reliable recovery mechanism we have. Triage used it four times on fix: crew hire on a never-hired box, and a drill that hires the way the fleet does #184 overnight; danmt used it at 07:20 and had a session in five minutes. On .github/actions/release-artifact — build crew-<version>.sh through ceremony's asset hook, so both release doors attach it #210 it was not a workaround — the automated path was structurally dead, so it was the only lever that could have worked.

The engine fix

1. Get the JSON off argv. --slurpfile reads a file and has no size limit:

printf '%s' "$comments" >"$tmpf"
spliced="$(printf '%s' "$listing" | jq -c --argjson num "$num" \
  --slurpfile c "$tmpf" \
  'map(if .number == $num then . + {comments:$c[0]} else . end)')" || spliced=""

2. Stop shipping full bodies. Every consumer on this path reads only a body prefix: answered-head.jq:29 does startswith($mark) then captures a 40-hex SHA; near-miss-signal.jq:39 anchors on ^\{\{MARK_[A-Z0-9_]+\}\}. Truncating body to ~256 chars inside _resume_pr_comments's --jq cuts the payload roughly 20× and preserves both predicates. Verify against _stranded_resume_keys and _flip_owed_resume_rows first — round-log.jq does read full bodies, but that is a different path.

3. Make it loud. A warn on the jq-failure branch. A silent drop that prints no resume duty is how 86 minutes passed with the board looking clean.

Fix 1 alone unblocks it. Fix 2 stops it recurring at 256 KiB. Fix 3 is what makes the next instance visible in minutes instead of hours.

Where we go — danmt

The line fix is necessary and it is not sufficient. Raising a ceiling does not address why we keep walking into it. Three directions, and I want all three considered rather than the cheapest one taken:

1. Cap PR rounds; hand the torch to a successor PR. After a threshold number of rounds, the branch continues in a new PR that carries the code forward. The new PR's body holds only the current state; the old PR stays open-as-read as a ledger of how we got there. The issue then points at all of its PRs in an ordered list, so the chain is navigable and no history is lost — it is relocated, not deleted. This bounds every per-PR payload in the engine by construction rather than by limit-checking.

2. Make PRs smaller, and make that a triage responsibility. We have precedent for splitting. The observation driving this: the longer a PR runs, the harder it is to get consensus from all agents. Every additional round widens the surface a reviewer must hold, and reviewers that disagree generate more rounds, which lengthen the PR further. That loop should be an input to how triage sizes an issue in the first place — a large issue that will obviously produce a ten-round PR should be split before a builder claims it, not after the thread is 150 KB.

3. Sizes should matter, and the engine should know them. The crew engine should know its own operating limits — argv, payload, page counts, whatever else has one — and flag when a PR is approaching them, rather than discovering them by execve failure in a subprocess. A canary that warns at, say, 100 KB would have caught #188 on the 14th and made #210 a non-event. This is 0.1.3's thesis applied to the engine's own plumbing: the box should not be a black box to itself.

The ask

I want this turned into issues in the 0.1.3 window. For now the candidate issues are going up as comments on #327 so they are attached to the release that owns them, and I would rather they were argued here before anyone mints them.

The engine fix is not optional and should not wait on the design conversation — it is a one-line class of bug that has cost us two mornings. The three directions above are where I want the discussion.

Reproduction

# payload in the exact shape _resume_pr_comments emits
gh api --paginate "repos/heavy-duty/incubator/issues/210/comments?per_page=100" \
  --jq '.[] | {author:{login:(.user.login // "")}, body:(.body // ""),
               createdAt:(.created_at // ""), id:((.id // "") | tostring)}' \
  | jq -sc '.' > c210.json

wc -c c210.json            # 152094
getconf PAGESIZE | awk '{print $1*32}'   # 131072  (MAX_ARG_STRLEN)
getconf ARG_MAX            # 2097152     (not the binding limit)

jq -c --argjson comments "$(cat c210.json)" -n '$comments|length'
# argument list too long: jq

[dan-claude-bot]

Triage disposition — all four are recorded on #327 as entries 26–29, the engine fix is at a ruling, and two of the four are two mints each

Triage 2026-08-15 07:5xZ. Nothing is minted by this comment. The four candidates are now entries 26–29 of #327's ## To mint when this arc opens, folded into that body in this same tick and recorded on that thread — bullets rather than comments because release-init step 1 counts bullets and does not reach a comment. The list goes from twenty-five to twenty-nine, and #327's three count sites and the roadmap's 0.1.3 row were corrected with it.

Everything below is measured at origin/main 394bdad at this write, not read off the post. Where it agrees with you I say so once; where it changes something, that is the substance.

---

The bug reproduces at HEAD, and the line number is not the one to fix against

You measured the deployed box — crew@0.1.2, installed 2026-08-10T21:25:18Z, line 958. origin/main carries the identical code six lines later: the splice at L964-L966, --argjson comments "$comments", || spliced="", no warn, against the sibling branch that has one. The guarantee it voids is at L384, not L375. Same offset throughout — worth naming because it decides whether this is a mint at all, and because a patch written against 958 lands in the wrong function here.

Reproduced independently on the triage box rather than re-run from yours: a synthetic 148,791-byte payload in the shape _resume_pr_comments emits → jq --argjson → argument list too long: jq; the same payload through --slurpfile parses. getconf PAGESIZE × 32 = 131,072; ARG_MAX = 2,097,152 and is not what binds. D1 stands as written.

D2 is sound, and the truncation is not free

I checked what you asked to be checked before truncating. Every consumer of the spliced .comments — L1100, L1113, L1182, L1262, L1331 — wraps the field into the GraphQL shape and runs only answered-head.jq or near-miss-signal.jq. round-log.jq is fed from a different payload at L286, so your caveat holds and _stranded_resume_keys / _flip_owed_resume_rows are clean.

But neither predicate reads a prefix. They anchor on one and then capture from an unbounded remainder: answered-head.jq:31 runs capture("(?<sha>[0-9a-f]{40})") over the whole body after ltrimstr($mark), and near-miss-signal.jq:23-24 after its sub. The wire format puts the SHA around byte 25 — MARK_ANSWERED="📣 round answered at head" + " <full-sha>" — so 256 is generous in practice and bounded by nothing in principle, and _stranded_resume_keys's own header says the parser is tolerant "because fleet comments may wrap the SHA in backticks or put punctuation after the marker". The mint's test plan therefore owes one must-fail case you did not list: a valid signal whose SHA sits past the truncation point must not classify as unsignalled. Otherwise the fix converts a signalled PR into a resumed one — this same defect, pointed the other way.

---

Direction 1 (cap rounds, successor takes the torch): one property of the engine defeats it as drafted

"Open-as-read" is not a state this engine has. Resume discovery walks gh pr list --state open --author "$ME" unconditionally — every open PR of mine, no filter — and _resume_attach_comments then fetches each one's whole thread, paginated, every tick. A predecessor left open as a ledger is:

• the largest thread in the repository, re-fetched once per tick forever, which is the cost this direction exists to bound and instead makes permanent;
• a candidate for the stranded set on every tick, since its head never moves again — so whether it is quietly resumed depends on whether its last comment happens to be a current-head MARK_ANSWERED, which is not a property anyone will maintain;
• and, being over the limit by construction, the one PR whose splice keeps failing even after D1 lands, if D2 does not.

So the direction is right and the mechanism needs one more decision: either the ledger is closed — a closed PR keeps every comment, every verdict and every ruling, and the issue's ordered list is what makes it navigable — or the engine learns a ledger marker and excludes it from resume discovery, round detection and the request path. My recommendation is closed, because it costs nothing to read, it needs no new engine state, and "relocated, not deleted" is satisfied by the ordered list you already want on the issue.

Two more things that do not carry themselves, since your third question asks:

• The panel's approvals cannot survive the cut. A review belongs to a pull request, so the successor starts at zero approvals even at a byte-identical head — and the engine's handoff predicate counts approvals at the current head of that PR. The cut therefore spends a full panel round unless it is timed to happen immediately after one closes. That is an argument for cutting at a round boundary, not at a byte count.
• The Closes #N link must move with the code and only once. Two open PRs both claiming to close one issue is the shape ceremony's actions/refs-not-closing exists to catch; the predecessor becomes Refs #N in the same act that makes the successor the closer, or the reconciler's notion of the deliverable PR is ambiguous while both are open.

What I cannot settle and will not guess: N, and who cuts. Both are yours. I will say that N argued from rounds is right and that the round boundary above is a stronger anchor than any byte figure.

Direction 2 (smaller PRs): the doctrine half is not crew's, and the split has a priced cost

.ceremony/ in this repo is a machine-managed byte-identical mirror of heavy-duty/ceremony — "a hand edit goes red" — and it moves only when the pin in .github/workflows/release.yml moves. So D1 is a heavy-duty/ceremony mint, not a crew one, and crew's half is D2 alone: round count surfaced to triage as sizing evidence rather than only as a stalled PR. As drafted the two are independent, so crew's half carries no cross-repo blocker; it gains one the moment it must read a rule the doctrine has not yet stated. I searched ceremony for prior art on sizing or round caps and there is none, open or closed.

D3 is arithmetic rather than a caveat, and it is worth writing into whatever rule lands. TRIAGE.md's own contract makes every newer issue on a shared deliverable declare Blocked by #N against the newest open carrier — so splitting one issue into k on a single axis does not produce k claimable issues, it produces a k-deep serial chain, one claim at a time. The core migration chain on this board is four issues deep for exactly that reason. A sizing rule that ignores this trades stalled PRs for a queue that is idle by construction, which is what the board looks like right now: zero ready, zero claimed. The split that actually pays is across disjoint deliverables, and the contract has no discount for near-disjoint ones.

Direction 3 (the engine knows its limits): agreed, and one of its four criteria is already decided

This is the one I would most like to see minted, and it needs the least argument — it is this window's thesis pointed at the engine's own plumbing. One correction to the draft: D4's "whatever 0.1.3 lands as the human-facing channel" is already settled, at 21:3xZ yesterday. The out-of-band alerter rides the floor process, because notify.sh is a singleton on the triage box and a box has no path to a sibling, so it structurally cannot observe one; "what always running on the host should be" is #328's question. Entry 29 inherits that rather than re-taking it.

Also worth having on the record beside your blocker:unrequested observation: entry 26's D3 is the instance and direction 3's D3 is the class, and they should not be minted as one issue. The instance is a one-line warn on a known branch; the class is an audit over every || x="" on a decision path.

---

The one thing I am asking a human for

Whether the engine fix mints now, ahead of this window's wave, or with it. Your post says both "I would rather they were argued here before anyone mints them" and "the engine fix is not optional and should not wait", and this window is separately held at release-init step 1 until @danmt orders the wave — a hold I do not get to override. It is needs-ruling on #327, recommending mint now, defaulting to that at 2026-08-15T18:00Z if nobody rules, and it holds entry 26 alone — 27–29 are held by step 1 exactly as before.

Entries 27, 28 and 29 are yours and @danmt's to argue here. Nothing about that conversation is on a clock, and none of it blocks anything on the board.

One last note, since it will matter at step 2 rather than here: entries 17 and 26 are both shared/lib/duty-builder.sh — the zero-action resume breaker's visibility and the splice, different functions, one file. Whichever mints second owes the other an unconditional Blocked by #N.

[danmt]

Do we even need the entire comment thread? i mean, isn't the PRs body comment already a summary of all the convo? regardless for this PR https://github.com/heavy-duty/incubator/pull/188 the limit was exceeded by the PRs body itself. I proposed some options. --- i also agree with @dan-claude-bot: So the direction is right and the mechanism needs one more decision: either the ledger is closed — a closed PR keeps every comment, every verdict and every ruling, and the issue's ordered list is what makes it navigable — or the engine learns a ledger marker and excludes it from resume discovery, round detection and the request path. My recommendation is closed, because it costs nothing to read, it needs no new engine state, and "relocated, not deleted" is satisfied by the ordered list you already want on the issue. > totally agree, lets go with close. --- its fine if we lose approvals after a PR cut due to the round cap. The Closes #N link must move with the code and only once yes agree with this. --- if we need to change stuff in ceremony, file it as a thorough discussion. i agree with your take, but I'd rather have multiple issues "idle" due to blocking than super large PRs that never close, but i see what you're saying its not split into the smaller possible issues but rather it needs some thinking: my take is simple, is the PR to fix this issue complex? yes? then its an epic and has multiple issues that are ideally disjointed, we avoid having multiple issues touching the same few lines of a file, group when we can without introducing overwhelming complexity. the important part is recording all of this in 0.1.3 so once the release starts we mint all these issues. one last thing that I want to add to 0.1.3 even tho its slightly out of scope: I want the repos.txt and notify.txt configurable from the crew floor, being able to change the "global" ones, and also being able to get into a droid and change toggle repos, in the current state of affairs i'd have a builder working exclusively in crew while the other is wrapping things up for incubator's launch, this requires ssh, knowing where these files are and modify multiple places, this is easily fixed through the crew floor.

[dan-claude-bot]

Recorded — five answers folded in, a thirtieth entry added, and one question of yours is still the one I cannot answer

Triage 2026-08-15 08:2xZ, against your 08:10:26Z reply. All of it is now on #327 — the record comment, with each decision annotated on the bullet it decides rather than only in a thread. Nothing is minted.

What you settled, and it moves real weight:

• The ledger is a closed PR. This is the one that mattered. Open-as-read was the single property that broke direction 1 as drafted — resume discovery walks every open PR unconditionally and re-fetches its whole thread every tick, so the predecessor would have been the largest thread in the repo re-read forever, a permanent stranded-set candidate with a frozen head, and the one PR whose splice keeps failing even after the engine fix lands. Closed has none of those. The direction now needs no ledger marker and no new engine state at all.
• Approvals spent by the cut — accepted. (The round-boundary point survives as sizing advice: cut after a round closes, not at a byte count.)
• Closes #N moves with the code, once.
• Ceremony changes open as a discussion, at the mint.
• The k-deep-chain idle cost — you priced it and took it, so it is settled and I will not re-raise it when these mint.

Entry 30 — repos.txt / notify.txt from the floor — is recorded as yours, placed by you, with the note that it displaces nothing in the fleet-floor epics. Three things I measured that change the shape of it:

1. It is notify-repos.txt. A patch written against notify.txt lands nowhere.
2. notify-repos.txt is the wrong lever for what you described. It is strictly additive — the notify set is repos.txt ∪ notify-repos.txt, and its own header says it is "NOT an alternative registry". Scoping one builder to crew and another to incubator is a repos.txt edit; the other file only ever widens what is watched.
3. Half of it already exists. apply_registry already does converge-or-preserve over both files against a provenance hash, so a hand-diverged box keeps its edit across an install, and engine-manifest.sh deliberately excludes them from drift reporting because of it. The global-vs-per-droid model you want is a surface gap, not a storage one.

And one flag on it that is yours, not mine: shared/README.md carries your 2026-07-25 ruling — "repos.txt IS the scope; out-of-scope work is logged, never acted on" — from #26, where a drill box wrote to production. A floor button that writes repos.txt widens a box's blast radius from a web page. Who may fire it, and what gets logged, wants a decision before that issue is written.

---

The one thing still open

Does the engine fix — the jq --argjson resume splice, entry 26 — mint now, or with the wave?

• A — mint it today as a ready member of the 0.1.3 gate.
• B — hold it with the other twenty-nine until you bless wave 1 at release-init step 4.

Your reply reads on 27–29 and I have taken it as such. It does not name the engine fix, and it does not touch the carve-out in your original post — "the engine fix is not optional and should not wait on the design conversation." Your sentence "recording all of this in 0.1.3 so once the release starts we mint all these issues" sits in the issue-sizing paragraph and, for 27–29, restates what was already true of them.

I have suspended the 18:00Z default rather than fired it, and said so on #327. That default was justified on silence, and you have now written on this thread after the ask went up — so firing A would mean overriding your own step-1 hold on a reading I have called ambiguous, which is not mine to do. At 18:00Z I hold. If it is still unanswered at the ladder's 24h rung (2026-08-16T07:53Z) I pick, record it as a decision, and own it.

"A" or "B" is the whole answer. For what it is worth my recommendation is unchanged — A, because the defect is live at origin/main 394bdad, it has cost two mornings in two days, the attention lever only works while somebody is watching, and the board carries zero ready issues for a builder to take instead.

[danmt]

Lets go with B @dan-claude-bot

[dan-claude-bot]

Answering the one question of yours I left on the floor: no, we don't need the prose — and the PR body is not what broke it

Triage 2026-08-15 08:4xZ. My 08:19Z reply answered everything in your message except its first two sentences, which is the substantive half. Measured at origin/main 394bdad — still HEAD at this write — rather than read off the post. Folded onto entry 26 as a sub-bullet on #327's ## To mint when this arc opens list (the list still stands at thirty top-level bullets — a sub-bullet moves no count) in this same tick. Nothing is minted.

Your body figure is right. The mechanism it implies is not.

incubator#188's body is 203,623 bytes — over MAX_ARG_STRLEN on its own, exactly as you said. But no PR body ever reaches argv on this path. The listing is piped to jq on stdin:

spliced="$(printf '%s' "$listing" | jq -c --argjson num "$num" \
  --argjson comments "$comments" ...

$listing — which is where body lives — goes down the pipe, and a pipe has no MAX_ARG_STRLEN. $comments is the only argv element on that line. So the oversized body did not stall #188; its 108-comment, 273,114-byte thread did.

That is worth having on the record because "shrink the PR body" is the intuitive fix and it would have fixed neither morning. Conversely --slurpfile fixes both.

Do we need the whole thread? No — we need its events, not its prose.

The engine's question is temporal: was the newest round answered at the current head? It answers it off per-comment author, createdAt, and a 40-hex SHA sitting behind a marker — roughly the first 60 bytes of each comment.

So the PR body cannot substitute, at any length or quality of summary: it carries no per-event author, no timestamp, and no head SHA. A summary tells you what the conversation concluded; the engine needs to know who said it, when, and against which commit. That is the argument for D2 — keep the thread, truncate the bodies — and it is now argued rather than asserted.

Where your instinct does land on something real

body is on that listing (L1829 fetches number,isDraft,headRefOid,body,statusCheckRollup,reviewRequests, every tick, for every open authored PR) and it is read exactly once — _resume_pr_fingerprints — to capture one #N from the first closes|refs|fixes|resolves match.

So the shape you're reacting to is real and it is on the body path too: carry 200 KB to extract three characters. It is simply stdin-bound, so it is not this bug — a fixer must not touch it under entry 26. It is the natural first case for entry 29's canary, which measures payloads rather than arguments.

And I audited the file for a second instance, since that is the obvious next question

One candidate: L1999-L2002 passes --argjson reviews on argv. Its source is latestOpinionatedReviews(first:50) over {author{login}, state, commit{oid}} — ~6.6 KB at fifty worst-case nodes against 131,072, bounded by construction. Not a second occurrence. Every other --arg/--argjson in the file carries a marker, a login, a repo name or a panel list.

_resume_attach_comments is the only unbounded argv payload on this path, which is precisely why D1 alone is sufficient.

---

Housekeeping on the ruling, so it is not carried by a comment nobody re-reads

The 07:5xZ flag itself still read Default: A at 2026-08-15T18:00Z — the suspension was only in a later comment, and the flag is what a session at 18:00Z actually reads. It now carries the suspension in place (flag), plus two figures the entry-30 fold-in had rotted. No default fires at 18:00Z; triage holds.

The A/B question is unchanged and still the only thing I need from you:

A — mint the jq --argjson fix today as a ready member of the 0.1.3 gate. B — hold it with the other twenty-nine until you bless wave 1.

Still recommending A. Unruled at 2026-08-16T07:53Z I pick, record it as a decision, and own it.

[danmt]

@dan-claude-bot honestly I think the PR body also carries too much info, so the round cap plus cutting (close + ledger) will probably make things easier. but yes, there should be minimal prose in the PR's body and we should scope that into 0.1.3 too

[dan-claude-bot]

Both taken: B is recorded and the flag is cleared, and the PR-body direction is entry 31 — where the measurement moves its owner

Triage 2026-08-15 09:2xZ. Two deltas since my last write, one each way.

---

1. B — ruled, closed out, and nothing is left running

Entry 26 mints with the wave at release-init step 4, not ahead of it. Recorded in four places in one tick: the ruling record on #327, the epic's entries-26–29 header note and entry 26's own bullet, the flag comment annotated in place, and the 0.1.3 row on #338.

• needs-ruling is off 0.1.3 — telemetry: the box stops being a black box #327. The repo now carries none anywhere.
• No default fires at 18:00Z — it was suspended at 08:2xZ and is now void, not fired — and triage owes no pick at 2026-08-16T07:53Z: you ruled inside the ladder's first rung, so that rung is void with it.
• Entry 26 now carries no hold of its own. It is held by step 1 exactly like the other thirty bullets.
• I recommended A and you ruled B. That recommendation is spent and I will not re-raise it when this mints.

What B costs is on the record once, in the closeout, and not re-argued here: the splice stays live at origin/main, it never clears on its own because a thread only grows, and until the wave lands it the only lever that reaches a PR already dropped out of resume detection is a human setting attention by hand — on the assigned issue that owns the claim, never on the PR. blocker:unrequested fires correctly and notifies nobody. That is now a known, priced cost rather than a surprise.

---

2. "Minimal prose in the PR body" — recorded as entry 31, and the measurement inverts who owns it

Recorded on #327 as a bullet in the same tick — the record — with the list moved thirty → thirty-one and all four figure sites corrected with it. Nothing is minted.

Your instinct is right and the fix is not where it looks. A builder writes no PR-body prose at all: BUILDER.md says the whole-round reply is the record — "you owe the reply and no body edit" — and at handoff "the builder composes no new summary".

The body grows because the engine writes it. _mirror_rounds copies each whole-round reply verbatim into ## Round log, one block per round, newest last. At 6–9 KB a round, that is your 203,623 bytes on #188. So a doctrine telling builders to write less would change nothing — the same shape as this morning's body-vs-argv correction, pointed at a different writer.

The deliverable is that the Round log stops being a verbatim mirror. The one open decision — and it is yours or the mint's, not mine — is what replaces it: a rendered per-round line (head, verdicts, what changed, plus a permalink to the reply, which already exists as a comment), or a bounded window of the last N rounds with the rest linked. The constraint either answer must respect is BUILDER.md's own: the Round log is where the merging human looks, and the handoff comment points at it.

And you are right that 27 does most of this — the cap bounds the body by cutting the PR, entry 31 bounds what each round adds. They compose; neither makes the other redundant.

One thing I found while measuring it, reported as what it is — read from the code, not observed firing. _mirror_rounds fetches comments(first:100), the oldest hundred, while answered-head.jq uses last:100 on its path. #188 had 108 comments. Past a hundred, the newest replies fall outside the window, so recent rounds mirror as "Round passed with no written reply" — a false record, written by the engine, in the body we point the merging human at. It rides entry 31's bullet rather than a separate mint: same function, same tick's work.

---

Nothing here is on a clock. Entries 27–29 are still yours and @claude-bot-andresmgsl's to argue — the two that still block 27's mint are unchanged: what N is, and who cuts the successor. Everything on the list, all thirty-one, is held by release-init step 1 until you bless wave 1.

[danmt]

what about this?

Direction 2 (smaller PRs): the doctrine half is not crew's, and the split has a priced cost
.ceremony/ in this repo is a machine-managed byte-identical mirror of heavy-duty/ceremony — "a hand edit goes red" — and it moves only when the pin in .github/workflows/release.yml moves. So D1 is a heavy-duty/ceremony mint, not a crew one, and crew's half is D2 alone: round count surfaced to triage as sizing evidence rather than only as a stalled PR. As drafted the two are independent, so crew's half carries no cross-repo blocker; it gains one the moment it must read a rule the doctrine has not yet stated. I searched ceremony for prior art on sizing or round caps and there is none, open or closed.

D3 is arithmetic rather than a caveat, and it is worth writing into whatever rule lands. TRIAGE.md's own contract makes every newer issue on a shared deliverable declare Blocked by #N against the newest open carrier — so splitting one issue into k on a single axis does not produce k claimable issues, it produces a k-deep serial chain, one claim at a time. The core migration chain on this board is four issues deep for exactly that reason. A sizing rule that ignores this trades stalled PRs for a queue that is idle by construction, which is what the board looks like right now: zero ready, zero claimed. The split that actually pays is across disjoint deliverables, and the contract has no discount for near-disjoint ones.

did you file the ceremony issues for this? or a discussion or something so its picked up at some point? @dan-claude-bot --- copying the round verbatim in the body was so that you could read the entire thing in the body but thats unrealistic as after 5 rounds it becomes too much text anyway. I think what we should do is after every round update the PR body to mention the round and stuff with minimal prose. so the PRs body is what reviewers use (ignoring all comments) --- if you do round 1 and get N change requests, for round 2, the body will hold whats done in round 1 and what was requested by reviewers --- builder reads the body and acts on it, once a result is in, the PR body is also updated --- this way we end up with a rolling summary of the PR in the body. hopefully with the round cap we'll never get a 100kb plus body which would be crazy imo.

[dan-claude-bot]

No — nothing was filed, and that was the recorded plan rather than an oversight. It is filed now: ceremony#416. And the rolling summary revisits a ruling of your own

Triage 2026-08-15 11:1xZ. Two things in your message, one each way. Nothing is minted, no flag is set, and nothing here is on a clock — everything below is recorded on #327 as sub-bullets on entries 27, 28 and 31, folded in this same tick. The list still stands at thirty-one bullets; sub-bullets move no count.

---

1. The ceremony half — not filed, now filed, and you were right to ask

Straight answer: no issue, no discussion, nothing. What I recorded at 08:2xZ was your own direction — "if we need to change stuff in ceremony, file it as a thorough discussion" — as "ceremony changes open as a discussion, at the mint." That reading is defensible and it has one hole, which your question is: a bullet on crew#327 is invisible to ceremony's board. Nothing over there would ever have picked it up, and "at the mint" is behind a step-1 hold with no date on it. So the honest answer is that the doctrine half had no home at all, and "at some point" was doing more work than it could carry.

Filed: heavy-duty/ceremony#416 — one thorough discussion carrying the doctrine halves of entries 27, 28 and 31, because all three amend the same round-and-PR-lifecycle text and each is unreadable without the others; ceremony's triage splits at the mint if that is the right shape. A discussion is not a mint: this window's step-1 hold is untouched, and B still stands.

Two things I measured while writing it that neither of us had named:

• The sentence direction 1 contradicts is BUILDER.md's third line: "You turn one issue into one PR." A round cap with a successor makes that one issue → an ordered chain of k PRs. So the amendment is to the contract's opening sentence, not to a paragraph inside the round section — which is a bigger doctrine change than "cap the rounds" sounds like, and worth knowing before anyone prices it. The same phrase also rides the PR template header in both repos.
• TRIAGE.md has no sizing language at all — not size, not small, not split, not large. The issue contract governs an issue's density and says nothing about its extent. Direction 2's doctrine half is a write, not an amendment; there is no existing rule to correct.

The three points you already settled (closed ledger, approvals spent by the cut, Closes #N moves once) travel there as settled. The two open ones — what N is and who cuts — are stated there as the mint blockers, which is exactly why it is a discussion.

---

2. The rolling summary — taken, and it re-opens ceremony#196, which you ruled

Recorded on entry 31. Your shape is neither of the two candidates I had on that bullet: not a rendered per-round line, not a bounded window of the last N rounds, but a rolling summary — overwritten, not appended. That is a better fit for what the log is actually for, and I have replaced the bullet's candidates with it.

The thing you should see before it mints: the verbatim mirror is ceremony#196, RULED 2026-07-28 by you — "the engine appends it, mechanically" — and it was chosen on this reasoning:

"Nothing new is asked of the builder, so there is no new thing to forget, and the durable record appears without discipline."

incubator#188's 203,623-byte body is that ruling working exactly as designed, at eleven rounds. Nothing went wrong; the design's cost simply showed up at a length nobody had. Revisiting it is right — I only want it revisited knowingly, so the mint does not re-derive an option that was already argued and rejected there.

Which leaves one decision, and the two answers are not interchangeable:

• The engine renders it. Keeps fix(floor): pause and resume report a zero crontab count as a refusal #196's load-bearing property intact. But an engine can render facts — round, head SHA, verdicts, approvers, files — and cannot render "what was requested by reviewers" as minimal prose without copying verdict bodies verbatim, which is the same growth curve under a new name. Its honest ceiling is a rendered line plus permalinks.
• The builder writes it. Delivers precisely what you described — and reinstates the obligation fix(floor): pause and resume report a zero crontab count as a refusal #196 removed, bringing back its rejected-option reasoning ("the ONE time it was caught is the time somebody happened to look, and that is not a gate, it is luck with good manners"), and repeals BUILDER.md's "you owe the reply and no body edit" — a prohibition your direction does not name. If it is this one, that repeal is doctrine and has to be written rather than implied.

Two mechanical facts either answer has to respect:

1. A body edit fires no notification. So "the PR's body is what reviewers use, ignoring all comments" cannot be the whole of it — a reviewer waiting on a round is never woken by a body edit. The engine agrees independently: round detection is temporal and reads the thread (author, createdAt, a 40-hex head SHA), so the round-answered event stays a comment either way.
2. And that constraint is where it pays. If the substance moves to the body and the reply shrinks to a short marked comment — "Round N answered at <sha>, see the Round log" — then the comment thread stops growing too: the same 100-comment thread falls from ~250 KB to a few KB. In the builder-written shape, entry 31 pays down entry 26's entire class, on top of bounding the body. That is the strongest argument for it and it is not one either of us had.

Both are on #416 as the explicit (a)/(b) question. This is also the one of the three where a crew engine change landing first would contradict live vendored doctrine — .ceremony/BUILDER.md is machine-mirrored and docs-sync reds a hand edit — so unlike 27 and 28, crew's half here waits on ceremony's answer.

---

Where that leaves the board: thirty-one bullets, all held by release-init step 1, nothing minted, no needs-ruling anywhere in the repo, and no timed default running. The open questions — N, who cuts, and (a)/(b) — are arguments to have, not a clock: nothing on the board is blocked on them. @claude-bot-andresmgsl's directions 1–3 are still his and yours to argue, here or on #416.

[dan-claude-bot]

Closing as resolved — the ceremony half was filed, and the crew halves are all minted

Triage 2026-08-25, board-sweep pass. This thread converged on 2026-08-15 with the ceremony half filed as ceremony#416 and the crew halves recorded as sub-bullets on #327's entries 27, 28 and 31. Release-init minted them on 2026-08-24:

• #479 — ready — _resume_attach_comments hands a PR's whole comment thread to jq on argv, so a thread past 128 KiB drops that PR out of resume detection permanently. This is the defect this thread is named for.
• #482 — the engine declares its own operating limits rather than discovering them by execve failure.
• #502 / #503 / #504 — the round-cap family.

One correction worth carrying, found on 2026-08-24: ceremony had already shipped the round cap (BUILDER.md §308, N=5 fixed) and TRIAGE.md's ## Sizing in 0.7.4 — so #502 and #504's specs were amended in place where they contradicted shipped doctrine. A negative search is a measurement and expires.

Nothing is owed here. Closing so the board shows only threads waiting on somebody.