PR length is a doctrine problem: a round cap with successor PRs, issue sizing as a triage duty, and the Round log's verbatim mirror (#196 revisited)

[dan-claude-bot]

Filed by crew's triage out of heavy-duty/crew#456, at @danmt's ask on that thread: "did you file the ceremony issues for this? or a discussion or something so its picked up at some point?" — and per his earlier direction there, "if we need to change stuff in ceremony, file it as a thorough discussion." Nothing here is minted, in either repo.

The engine halves are recorded on crew#327 as entries 27, 28 and 31 of its ## To mint when this arc opens list, held at release-init step 1 until the operator blesses wave 1 (ruled B, 2026-08-15). Those bullets are crew-side and cannot reach this board — which is exactly why this discussion exists. This is the doctrine half, and it is a different half in each of the three cases below.

---

What forced it

Two mornings, two days, two stalled PRs in heavy-duty/incubator (#188, #210), both terminal at a green head with every check passing. Cause, measured: crew's _resume_attach_comments passes a PR's whole comment thread to jq on argv, which binds at MAX_ARG_STRLEN (32 pages, 131,072 bytes) — not ARG_MAX. #210's thread was 152,094 B, #188's 273,114 B. Above the limit the execve fails, the failure is swallowed, and the PR drops out of resume detection permanently, because a thread never shrinks.

That line is crew's to fix and it is not what this discussion is about. What it exposed is a doctrine question ceremony owns:

• docs: FLEET.md reconciled against crew@01fb49c — registry is the scope #188's body was 203,623 bytes on its own.
• Round replies run 6–9 KB each; average comment 2.3–2.5 KB.
• Both PRs crossed 128 KiB somewhere around their fifth or sixth review round.
• The crossing comment on fix: checks_state never grades the label machine's own runs (#208) #210 was a previous round's completion notice. The ceremony's own prose was the payload that defeated the machine watching for round completions.

The engine's ability to rescue a stranded PR degrades as the PR accumulates rounds — so it fails hardest on exactly the PRs most likely to need rescuing. Raising the ceiling does not address why we keep walking into it. Three doctrine asks follow, in @danmt's framing, with what is already ruled marked as ruled and what is open marked as open.

---

D1 — Cap the rounds; the branch continues in a successor PR, and the predecessor closes as a ledger

The direction. After a threshold number of rounds, the branch continues in a new PR carrying the code forward. The new PR's body holds only the current state. The predecessor closes and stands as the ledger of how we got there — every comment, every verdict, every ruling, intact. The issue points at all of its PRs in an ordered list, so the chain is navigable: the history is relocated, not deleted. This bounds every per-PR payload in the engine by construction rather than by limit-checking.

Already ruled by @danmt on crew#456, and not up for re-argument here:

1. The ledger is a closed PR, not open-as-read. Open-as-read was the one property that broke this direction as drafted: crew's resume discovery walks every open PR of the author unconditionally and re-fetches its whole thread every tick, so the predecessor would have been the largest thread in the repository, re-read forever, a permanent stranded-set candidate with a head that never moves again. Closed has none of those, and the direction consequently needs no new engine state and no ledger marker at all.
2. The panel's approvals are spent by the cut, and that cost is accepted. (Triage's note that this argues for cutting at a round boundary rather than at a byte count stands as sizing advice for whoever writes it.)
3. Closes #N moves with the code, once — the predecessor becomes Refs #N in the same act that makes the successor the closer.

What is still open, and it is the whole of what blocks a mint: what N is, and who performs the cut (the builder at the round close? the engine at the handoff? triage?).

The doctrine surfaces this touches, measured against this repo's main at this write:

• BUILDER.md line 3 — "You turn one issue into one PR." This direction makes it one issue → an ordered chain of k PRs. That sentence is the contract's opening line and a successor-PR rule contradicts it directly; it has to be amended, not worked around. The same phrase rides .github/pull_request_template.md's header ("One issue, one PR — draft while building").
• BUILDER.md, claiming and handoff — what a builder does at the cut, and whether an in-flight claim survives it.
• REVIEWER.md — that approvals do not survive a cut, and that the review target is the successor while the predecessor is read-only history.
• TRIAGE.md — the issue body carries the ordered list of its PRs, and who maintains it.

---

D2 — Issue size is a triage responsibility, and round count is the signal it is failing

The direction, in @danmt's words: "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.

His own rule of thumb from the thread: "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."

This one is entirely ceremony's. Measured: TRIAGE.md on this repo's main contains no sizing language of any kind — not "size", not "small", not "split", not "large". The issue contract governs density (context, spec, tasks, acceptance criteria, test plan, dependencies) and says nothing about extent. crew ships no doctrine, so crew's half of this is only round count surfaced to triage as sizing evidence rather than only as a stalled PR — a telemetry deliverable that carries no cross-repo blocker as drafted, and gains one the moment it must read a rule that does not exist yet.

One caveat the rule must absorb, because it is arithmetic rather than taste. TRIAGE.md's own contract (#288) makes every newer issue on a shared deliverable declare an unconditional 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. crew's core migration chain is four issues deep for exactly that reason, and crew's board sat at zero ready / zero claimed while this was being measured. A sizing rule that ignores this trades stalled PRs for a queue that is idle by construction. The split that pays is across disjoint deliverables, and the contract offers no discount for near-disjoint ones — that is precisely @danmt's "ideally disjointed", and the rule should say it in the contract's own vocabulary.

@danmt has priced the k-deep idle cost and taken it ("I'd rather have multiple issues idle due to blocking than super large PRs that never close"), so that trade is settled; what is not written anywhere is the rule itself.

---

D3 — The Round log stops being a verbatim mirror. This revisits ceremony#196's ruling, and it should be revisited knowingly

This is the one with real prior art, and it is a ruling of @danmt's own.

ceremony#196 — "Handoff spends a session reconstructing a record the round log was already supposed to hold" — was RULED 2026-07-28 (danmt): the engine appends it, mechanically. The builder keeps exactly one obligation, the one it already had (answer the round whole, in one reply); the engine mirrors that reply into the PR body's ## Round log. The reasoning was explicit and good: "Nothing new is asked of the builder, so there is no new thing to forget, and the durable record appears without discipline", and a guard "checks that a record exists; it can never check that it is true."

That ruling is what put 6–9 KB of verbatim prose per round into PR bodies. #188's 203,623-byte body is that ruling, working as designed, at eleven rounds. The mechanism is BUILDER.md's own text on this repo's main:

"the engine mirrors it under the PR body's Round log, newest last and marked with the round's head, which makes a retry a no-op; you owe the reply and no body edit" — L196-198

"The builder composes no new summary: the authored record already lives in the Round log, mirrored from each whole-round reply." — L305-306

@danmt's new direction, from crew#456 at 2026-08-15T11:04:03Z:

"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."

So: a rolling summary, not an append-only log. It keeps the property #196 was really after — the record lives where the merging human looks — and drops the property that made it grow.

The one decision this needs, and it is the reason it is a discussion and not an issue:

Who writes the rolling summary?

• (a) The engine renders it. Preserves Handoff spends a session reconstructing a record the round log was already supposed to hold #196's load-bearing property exactly — nothing new is asked of the builder, nothing new to forget. But an engine can render facts (round number, head SHA, verdicts, who approved, files touched); it cannot render "what was requested by reviewers" as minimal prose without copying verdict bodies verbatim, which is the growth curve again under a new name. The engine's honest ceiling here is a rendered per-round line plus permalinks.
• (b) The builder writes it. Delivers exactly the artifact described — and reinstates the precise obligation Handoff spends a session reconstructing a record the round log was already supposed to hold #196 removed, so its rejected-options analysis comes back with it ("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"). It also repeals BUILDER.md's "no body edit" — a prohibition the direction does not name. If (b) is the answer, the repeal must be written, not implied.

Two mechanical facts either answer must respect, measured rather than assumed:

1. A body edit fires no notification. "The PR's body is what reviewers use (ignoring all comments)" has a hard cost: GitHub does not notify anyone on a body edit, so a reviewer waiting on a round is never woken by it. The round-answered event must stay a comment — which is also what crew's engine requires, since its round detection is temporal and reads per-comment author, createdAt and a 40-hex head SHA out of the thread. A body summary cannot answer "was the newest round answered at the current head" at any length or quality, because it carries no per-event author, time or head.
2. That constraint is a feature, not an obstacle. If the substance moves to the body and the round 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. D3 in the (b) shape pays down the class of bug that started all of this, on top of bounding the body. That is worth having on the record before the shape is chosen.

And one defect in the current mirror, reported as what it is — read from crew's code, not observed firing. _mirror_rounds fetches comments(first:100) — the oldest hundred — while crew's answered-head.jq uses last:100. #188 carried 108 comments. Past a hundred, the newest replies fall outside the window and recent rounds mirror as "Round passed with no written reply": a false record, written by the engine, in the body BUILDER.md points the merging human at. It is crew's bug and is recorded there; it belongs here only as evidence that the verbatim mirror is already not faithful at the lengths that provoked this.

---

What I am asking for

Argue and converge on the three above — particularly D1's N and who cuts, and D3's (a)/(b) — so that whoever mints here has a spec rather than options. Two coordination notes:

• The crew halves are held, not racing this: all three sit on crew#327's to-mint list behind release-init step 1. Whichever side mints second owes the other a cross-repo dependency edge, named with its repository qualified.
• D3 is the one where an engine change landing first would contradict live doctrine — BUILDER.md's "no body edit" is vendored byte-identical into every consumer and guarded by docs-sync, so crew cannot amend it locally. D1 and D2 are independent as drafted.

Dedup, searched rather than assumed: this repo carries no issue and no discussion, open or closed, on PR sizing, round caps, or successor PRs. On the Round log, ceremony#196 is the only prior art and it is the ruling D3 revisits.

[dan-claude-bot]

Triage: the three directions restated as four decisions in the house ruling form — and the one thing re-measurement changed

Triage 2026-08-15 11:2xZ, measured against origin/main 97f91a0 rather than read off my own post above. Nothing is minted and no label is set anywhere. This repo's board carries zero open issues and zero open pull requests at this write — 0.7.3 published at 09:04Z, main re-armed to 0.7.4-dev, changelog.d/ holding no unconsumed fragment, no release window standing — so there is no board item to host a needs-ruling flag, and no ladder runs. The four asks below are the canonical shape, not a flag; the venue is this discussion, and it waits for @danmt.

---

What re-measurement did to my own claims

I wrote both sides of this, so the claims above are assertions until somebody goes and checks them. Re-derived from origin/main in this tick:

claim in the post above	verdict
BUILDER.md line 3 — "You turn one issue into one PR."	holds, verbatim, and it is line 3
.github/pull_request_template.md header — "One issue, one PR — draft while building"	holds
TRIAGE.md carries no sizing language	holds — size, sizing, small, split, large, extent match nothing in the file
#196 is RULED 2026-07-28 (danmt)	holds — the ruling sits in #196's body, quoting you directly; its needs-ruling cleared at 17:02:09Z, ~8 minutes before a builder claimed it
dedup: no issue, no discussion, open or closed, on sizing / round caps / successor PRs	holds
BUILDER.md, TRIAGE.md, REVIEWER.md are all in docs/VENDORED.txt	holds — so D1 and D3 land in bytes that every governed repo mirrors byte-identically
the mirror quote is at BUILDER.md L197-198	corrected → L196-198. The quoted sentence starts mid-196; following the old cite loses its first clause. The body above is fixed. A body edit notifies nobody — which is D3's own finding — hence this line.

And one thing changed in substance, which is why the asks below are not in the order the post puts them: D1's N is derived from D3's outcome, so D3 is asked first. Under the verbatim mirror as it stands, a round costs 6–9 KB of body and the binding constraint is bytes. Under any rolling-summary shape, per-round body growth collapses to a marked line and bytes stop being the binding constraint — what is left is your own reason, "the longer a PR runs, the harder it is to get consensus from all agents", which is a review-surface argument and yields a different number. Ruling D1's N before D3 would fix a number against a curve that D3 is about to change.

---

R1 — D3: who writes the rolling summary (ask this one first)

🧭 needs-ruling — Who authors the PR body's rolling round summary?
Options:  A — the engine renders it (facts only: round no., head SHA, verdicts, permalinks)
          B — the builder writes it, and BUILDER.md's "no body edit" is repealed
          C — both: the engine renders the per-round row at the round close, the builder fills
              the "what was requested / what was done" prose, and handoff is gated on it
Recommend: C, because it is the only cell that keeps #196's load-bearing property — the record
          appears without discipline — while producing the prose no engine can render, and it
          restores the gate whose absence is exactly why #196 rejected "doctrine alone".
Blocked:  the D3 mint stops entirely (BUILDER.md L196-198, L303, L305-306; REVIEWER.md's review
          target; crew's mirror change), and R2's number stops with it. Nothing else stops: the
          board is empty, and crew's entries 27/28/31 are held at release-init step 1 by their
          own hold, not by this.
Default:  none — hard block

Analysis — why C is a real cell and not a fudge

The axis is who writes, and its exhaustive set is {engine, builder, both}. The post above enumerated the first two; C is the third cell of the same axis, and it is where the two objections cancel:

• A's ceiling is real. An engine can render round number, head SHA, each verdict's author and state, files touched, and permalinks. It cannot render "what was requested by reviewers" as minimal prose without copying verdict bodies verbatim — which is the growth curve again under a new name.
• B's cost is real and it is Handoff spends a session reconstructing a record the round log was already supposed to hold #196's own. "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." B reinstates precisely the obligation Handoff spends a session reconstructing a record the round log was already supposed to hold #196 removed, and it repeals a prohibition (you owe the reply and no body edit) that your direction does not name.
• C splits them at the seam: the engine writes the row, so the record exists whether or not the builder is diligent; the builder fills one prose cell, so the artifact is the one you described; and because the row exists mechanically, an empty prose cell is machine-visible — the handoff gate Handoff spends a session reconstructing a record the round log was already supposed to hold #196 wanted but could not have. Handoff spends a session reconstructing a record the round log was already supposed to hold #196's objection was that a guard "checks that a record exists; it can never check that it is true." That objection is unchanged and C does not answer it: C buys existence, not truth. It is the same bargain every guard in this repo makes.

Two mechanical facts constrain all three cells equally, and neither is negotiable:

1. The round-answered event stays a comment. A body edit fires no notification, so a reviewer waiting on a round is never woken by one; and crew's round detection is temporal, reading per-comment author, createdAt and a 40-hex head SHA. A body summary cannot answer "was the newest round answered at the current head" at any length.
2. If the substance moves to the body, the round reply shrinks to a short marked comment. The thread stops growing too — the same 100-comment thread falls from ~250 KB to a few KB. Under B or C this direction pays down the bug class that started all of this, on top of bounding the body. Under A it does not, because the reply must still carry the substance somewhere.

R2 — D1: what triggers the cut, and at what number

🧭 needs-ruling — What triggers the successor-PR cut?
Options:  A — a fixed round count: cut at the close of round N
          B — a size budget: cut at the first round boundary after body-or-thread crosses a
              byte threshold
          C — judgment: no threshold; the builder or the panel calls it
Recommend: A, N = 5 — cut at the close of round 5, the sixth round opens in the successor.
          Both measured crossings happened at the fifth-or-sixth round, so 5 is the largest
          number that bounds every payload under the limit with today's verbatim mirror; and a
          round count is a number the builder and the engine both already have without
          measuring anything. If R1 lands B or C, the D3 mint re-derives N on the
          consensus-surface axis, where it will likely be larger.
Blocked:  the D1 mint stops on R2 and R3 together; each is answerable on its own.
Default:  none — hard block

Analysis — why not B, and where the number comes from

B is the thing this direction exists to replace. The premise you ruled on is that raising or checking a ceiling does not address why we keep walking into it; a byte budget is limit-checking with a nicer failure mode. It also makes the cut point unpredictable to the builder mid-round, and it re-measures a quantity that changes under R1.

C is honest but it does not bind. Every stalled PR in evidence was authored by an agent that had no rule telling it to stop, and judgment is exactly what was exercised for eleven rounds on incubator#188.

The number. incubator#188's body reached 203,623 B over 11 rounds — ~18.5 KB of body per round, so the body alone crosses MAX_ARG_STRLEN at round 7. The threads crossed earlier, at the fifth or sixth round (#210 at 152,094 B, #188 at 273,114 B). Cutting at the close of round 5 leaves the predecessor under the limit on both axes with margin, and the successor restarts at round 1 with a body holding only current state — so the bound is per-PR by construction rather than cumulative. This is the sizing advice you already accepted in another form: cut at a round boundary, not at a byte count, because the panel's approvals are spent by the cut and a mid-round cut spends a round's work as well.

R3 — D1: who performs the cut

🧭 needs-ruling — Who performs the successor-PR cut?
Options:  A — the builder, at the round close
          B — the engine, at round-complete detection
          C — triage, from the board
Recommend: A, because every act in the cut is an authoring act the builder already performs —
          open the successor on the same branch, move `Closes #N` to `Refs #N` once, close the
          predecessor, add the row to the issue's ordered PR list. The engine's part is to
          count and to say so at the boundary, which is instruction, not performance; triage
          never touches a branch.
Blocked:  with R2, the D1 mint. Nothing else.
Default:  none — hard block

Analysis — what each option would have to own

• A (builder). Needs BUILDER.md's opening contract line amended (one issue → an ordered chain of k PRs), plus claiming and handoff: whether the in-flight claim survives the cut. It should — the claim is on the issue, and the issue is unchanged by which PR carries its code. REVIEWER.md needs the other half: approvals do not survive a cut, and the review target is the successor while the predecessor is read-only history.
• B (engine). Would need to compose the successor's current-state body, which is the same thing R1 says an engine cannot render. It can, and should, detect the boundary and post the instruction — under R1's C that is the same row-rendering pass.
• C (triage). Puts a board actor in the middle of a branch operation, adds a hop between the round closing and the next round opening, and has no access to anything the builder does not already have. It is the option with the worst latency and no compensating property.

TRIAGE.md's half is unchanged under all three: the issue body carries the ordered list of its PRs, and triage maintains it — which is also the only place the chain is navigable, since the predecessor closes.

R4 — D2: mint the sizing rule now, or hold it behind R2

🧭 needs-ruling — Does D2 mint now, or wait for R2's number?
Options:  A — mint now: D2 is independent as drafted, and the rule needs no cap to state
          B — hold: mint after R2, so the rule can name the cap as its own failure signal
Recommend: A. Everything D2 needs is settled — sizing is triage's duty, complexity means an
          epic of ideally-disjoint issues, and you have priced and taken the k-deep idle cost.
          The rule can say "a PR that keeps generating rounds is evidence the issue was
          mis-sized" without citing a number, and R2's number amends one sentence later.
Blocked:  nothing stops either way. A gets the mint in this same tick.
Default:  A at 2026-08-16T11:30Z if no ruling — reversible: a minted issue can be closed, and
          nothing it produces reaches `main` without your merge.

Analysis — what the D2 mint would carry, and the one caveat it must absorb

The deliverable is TRIAGE.md gaining sizing language it has never had: the contract today governs an issue's density and says nothing about its extent. The rule as I would write it:

1. Sizing is part of the issue contract, sitting beside dedup — before minting, triage asks whether one builder can carry this to a verdict in a bounded number of rounds.
2. Complexity means an epic, in your own vocabulary: "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."
3. The caveat is arithmetic, not taste, and the rule must state it. TRIAGE.md's own TRIAGE.md — one deliverable, one claimable issue: the collision edge is declared, or its absence is recorded #288 contract makes every newer issue on a shared deliverable declare an unconditional Blocked by #N against the newest open carrier. So splitting one issue into k on a single axis yields a k-deep serial chain, not k claimable issues. A sizing rule that ignores this trades stalled PRs for a queue idle by construction. The split that pays is across disjoint deliverables, and the contract offers no discount for near-disjoint ones. You have already taken that trade — "I'd rather have multiple issues idle due to blocking than super large PRs that never close" — so it goes in as a stated cost, not an open question.
4. Round count is sizing evidence, which is the seam crew's half plugs into.

Board facts the mint would carry at this write, so whoever writes it does not re-derive them: no release window stands, so the mint takes no membership call; no open ready/claimed/blocked issue carries any part of this deliverable, so it declares no collision edge. Both change the moment D1 mints against the same files — whichever lands second declares Blocked by the first.

---

Two notes on how this waits

• There is no clock on R1–R3. They are hard blocks for the plainest reason: on each one the option chosen is the deliverable, so there is nothing to write until you pick — a default could not fire into anything. R1 additionally revisits a ruling of your own, which triage does not overturn on a timer. With no board item to carry needs-ruling, the 12h/24h ladder has nothing to anchor to either, so these three wait for you and triage will not pick them for you. R4 is different in kind and that is why it carries a default: it decides when a settled rule is written down, not what it says — and a mint is not itself the org-policy act, since every word of it still stops at your merge.
• Whichever side mints second owes the other a cross-repo edge, named with its repository qualified. crew's halves remain held on crew#327 behind release-init step 1; nothing over there is racing this.

[danmt]

R1 — D3: who writes the rolling summary (ask this one first) C
R2 — D1: what triggers the cut, and at what number A N=5 is fine.
R3 — D1: who performs the cut A
R4 — D2: mint the sizing rule now, or hold it behind R2 A

@dan-claude-bot

[dan-claude-bot]

Ruled, all four — recorded as decisions, and minted: epic #417 with #418, #419, #420

Thank you @danmt. Every ask went to its recommendation, so nothing below re-argues anything; this comment is the record and the mint.

ask	ruled	recorded as
R1 — who authors the PR body's rolling round summary	C	the engine renders the per-round row (facts); the builder writes the prose cells; handoff is gated on the prose being present — #418 D3, D4
R2 — what triggers the cut, and at what number	A, N=5	cut at the close of round 5 — #420 D1
R3 — who performs the cut	A	the builder, at the round close — #420 D4, D5
R4 — does the sizing rule mint now	A	minted this tick, naming no number — #419

No needs-ruling label was set anywhere and none is cleared: this repo's board carried zero open issues and zero open pull requests through the whole ask, so there was never a board item to host the flag. No attention is set either — nothing is claimed and nothing is assigned, so there is no assignee whose next move this delivers.

---

One thing your ruling supersedes, and it is mine

My R2 carried a conditional — "If R1 lands B or C, the D3 mint re-derives N on the consensus-surface axis, where it will likely be larger." You ruled C and named 5 in the same message, so the conditional is spent and N = 5 is ruled, not derived. A builder reading this thread top-to-bottom meets my conditional four screens before your ruling, so it is written into #420's spec as superseded (D1) and into the epic as a decision (E2) rather than left to be inferred here.

What the ruling does change is the reason the number is written down. Under C, per-round body growth collapses to a row and bytes stop being the binding constraint — so the cap is now a consensus-surface rule that happens to bound bytes, which is your own "the longer a PR runs, the harder it is to get consensus from all agents". #420 D2 makes the doctrine say it in that order, so the rule does not read as obsolete the first time the byte numbers move.

One thing re-measurement added

git grep -iE "one issue,? one PR|one issue into one PR" over main returns three lines, not the two this discussion named: BUILDER.md L3 and the PR template header — and CONTRIBUTING.md L26, "Builders turn one issue into one PR." My own post missed it. It is now a task and an acceptance criterion on #420, and the "cases that must fail" section names it as the failure mode with evidence behind it.

The mint

Four issues, documentation + scope:docs throughout, no release window standing so no membership call on any of them:

• #417 — the epic. Carries the four rulings, the ordering, and the fence.
• #418 ready — the rolling summary. BUILDER.md, REVIEWER.md, .github/pull_request_template.md.
• #419 ready — issue sizing. TRIAGE.md.
• #420 blocked — the five-round cap. Adds CONTRIBUTING.md to the four files above.

The fence, computed per path (#288): #418 is the newest open carrier of BUILDER.md / REVIEWER.md / the template, #419 of TRIAGE.md, so #420 declares both edges. #418 and #419 are genuinely disjoint — empty intersection — so neither prunes the other away and two issues are claimable right now, rather than the three-deep chain a naive ordering would have produced. Each file's fence is a single path, not a fork.

Two things a builder will meet and should not have to ask about, so both are decided in the specs rather than left open:

• Doctrine lands before the engine, by construction. BUILDER.md, REVIEWER.md and TRIAGE.md are vendored byte-identical and guarded by docs-sync, so crew cannot amend them locally and an engine change landing first would contradict live doctrine in every consumer. Every rule is therefore written to read correctly with no engine at all, and BUILDER.md, REVIEWER.md — the Round log becomes a rolling summary: the engine renders the row, the builder writes the prose #418 D8 says what the builder owes in the window before crew's row renderer exists: until the engine renders the row, the builder writes the row too.
• The successor cannot be opened while the predecessor is open. GitHub permits one open PR per (base, head) pair, so A five-round cap — the branch continues in a successor PR and the predecessor closes as the ledger #420 D5 fixes the order — answer the round, don't re-request the panel, Closes #N → Refs #N, close the predecessor, then open the successor on the same branch. The alternative (a second branch at the same commit) is rejected in the spec with its reason.

No consumer reds on any of these merges: docs-sync --check is consumer-side and compares against the consumer's pinned ceremony tag, so a consumer sees nothing until it bumps, and re-vendors at that bump.

crew

Unmoved and not racing this: entries 27, 28 and 31 on crew#327 remain held at release-init step 1 behind wave 1. Ceremony minted first, so the cross-repo edge is crew's to declare, qualified, naming #418 and #420. Nothing here declares an edge into crew, because there is nothing over there to name yet.

Closing this as resolved — the asks are answered and the work is on the board. #417 is where the arc is tracked from here.