A claim and its round record do not survive a builder identity replacement — the fork is the reason, and the fix has three shapes

[dan-claude-bot]

🧭 needs-ruling — which shape does "a claim, its branch and its round record survive an identity replacement" take?
Options:  A — written handover procedure, no engine change   B — an engine verb that performs the handover   C — fleet work stops building on forks, branches live on the org repo
Recommend: A now, C if #291's CPU swap is really the road, because a checklist is worth having whatever the answer and C dissolves the class rather than managing it.
Blocked:  nothing stops — #243's own fix shipped in 0.1.1 and no open issue declares this as a gate. What continues: everything; this thread is the only thing waiting.
Default:  none — hard block. C changes the permission story and every repo's flow, which is org policy, and org policy is a hard block by construction (#50 D13).

A, B and C are options 1, 2 and 3 in "Why this is a discussion and not an issue" below, in that order; the block above is the canonical form the ruling contract requires and the prose below is unchanged.

A is separable and is not held by this ask. Triage will mint it on one word from @danmt — the procedure is fully specifiable today from the #281 → #288 recovery measured below, and it does not pre-empt B or C. It is left unminted rather than slipped in, because an issue enters a release by decision and not by triage's default.

---

Opened by triage 2026-08-03 from @andriujoseba's fleet-intel finding set on #290 — finding 4 of six. It is the one finding in that set that is real, measured, and not mintable as an issue today, because its fix is a design choice nobody has made rather than a defect with a known repair. Per TRIAGE.md, an issue that carries an open question just moves triage's job onto the builder, so it comes here instead.

What happened, measured

On 2026-08-02 the codex builder's identity was replaced mid-run. The cost, from the report's hand-touch ledger:

UTC	what	cost
11:35–11:36	operator-directed identity handover: PR #281 closed, #243 transferred to @andriujoseba	the prior implementation and the round's unresolved findings had to be carried by hand into a replacement PR
11:34:47–12:13:26	@andriujoseba rebuilt it as #288	one replacement build session, 38m 39s draft→merge (corrected 2026-08-03 — this read 38m 16s, which measured from the handover comment at 11:35:10Z, not from the draft the label named)

The cause is not "identity" in the abstract — it is fork ownership

Verified against both PRs rather than inferred:

• #281 head: codex-bot-andresmgsl:build/243-resume-stranded-pr, opened 09:57:26Z, closed 11:35:13Z.
• #288 head: andriujoseba:fix/243-resume-stranded-pr, opened 11:34:47Z, merged 12:13:26Z.

The branch lived on the outgoing identity's fork. The incoming identity cannot push to another account's fork, so continuing #281 was not something the fleet declined to do — it was structurally unavailable. Everything that was lost followed from that one fact: the diff, the round's verdicts, the review conversation, and the claimed state on #243, each reconstructed by hand.

@andriujoseba's closing comment on #281 is the honest record of it: "Superseded by #288 after the builder identity changed mid-run … Closing this PR keeps #243 attached to one active deliverable."

Why this is a discussion and not an issue

The end state is easy to state — a claim, its branch and its round record survive the replacement of the identity holding them — and there are at least three ways to get there, with genuinely different costs. Picking one is the decision this thread is for.

1. A written handover procedure. No engine change: the operator (later the medic, #296) follows a checklist that carries the diff, re-opens against the new fork, and re-points the claim, with the round record linked rather than preserved. Cheapest, and it accepts the 38 minutes as the price each time.
2. Engine support for the handover. A verb that re-pushes the branch under the new identity, opens the replacement PR carrying the original's body and round log, and moves the assignee and the queue label in one act. Turns a hand recovery into a command; costs real work and a new failure surface.
3. Stop building on forks for fleet work. Branches on the org repo, so identity replacement never strands a branch at all. Structurally removes the class — and touches every repo's flow, the panel model, and the permission story, which is why it is not a thing to slide in under a fix.

The questions — @danmt, they are yours

Q2 is the one that decides the other two, and it is the cheap one: if the fork model is not
load-bearing, option 3 dissolves this class instead of managing it and Q1 stops mattering.
Named here rather than left open to the room, because this thread's siblings all name a decider
and an ask with no addressee is the zombie discussion TRIAGE.md
warns about. Triage's own read, offered rather than taken: option 1 today, option 3 if #291's
CPU swap is really the road — a written handover is cheap enough to be worth having whatever
the answer is, and engine support (option 2) is the one to build last, not first.

1. Is the class expected to recur? Identity replacement was a one-off this weekend, but #291 makes instances first-class and explicitly contemplates a CPU swap under a stable chair — if that is the road, this stops being an incident and becomes a lifecycle event, and option 1 stops being enough.
2. Is the fork model itself load-bearing? If fleet branches could live on the org repo, option 3 dissolves the class instead of managing it. What does the fork buy today that the org repo does not?
3. What must actually survive? The branch and the claim are mechanical. The round record — verdicts cast against a head that no longer exists on a PR that is closed — may be worth linking rather than preserving, and that is a cheaper answer than either of the first two.

Note the shape this is not: #296's ring 1 already lists orphaned claims as pathology the medic detects and contains. Detecting the orphan is not the same as being able to transfer it, and nothing on the board today owns the transfer. #291 rules identity migration explicitly out as a motivation for the droid model, which is right for that issue and leaves this unowned.

An answer here becomes an issue through triage in the usual way. Nothing waits on it: #243's own fix landed in 0.1.1, and the recovery cost is already on the record in #290's report.

[dan-claude-bot]

Converged — escalate, and the ask is now in canonical form

This thread was opened by triage as an escalation and then left without the shape the escalation contract requires, which is the one thing a decider should not have to reconstruct. Recording the outcome and what changed.

Outcome: escalate. The decision is @danmt's — option C changes the permission story and every repo's branch flow, which is org policy, and LABELS.md makes org policy a hard block by construction. Triage does not pick this one.

What was missing. The body carried the substance — three exhaustive, mutually exclusive options, triage's recommendation, and the fact that nothing waits on it — but not the fixed field labels that BUILDER.md's ruling ask specifies, and no Default: line at all. A missing default is not a neutral omission: the ladder applies whatever Default: says, and an absent one reads as unstated rather than as a block. It is now none — hard block, stated as such, above the fold.

No needs-ruling label is owed anywhere. Re-read from the board rather than asserted: no open issue declares this thread as a gate, and #243's own fix shipped in 0.1.1. TRIAGE.md puts the flag on an issue only when the decision blocks something already on the board. Nothing does, so the flag would be a lie about where the board's work is stopped. The thread is the whole wait.

One thing @danmt can unblock in a word. Option A — the written handover procedure — is separable from the choice between B and C, and is fully specifiable today from the measured #281 → #288 recovery in the body. Triage will mint it on request. It is deliberately not minted pre-emptively: an issue enters a release by decision and not by triage's default, and minting A would read as the decision having been made.

Triage, 2026-08-03.

[dan-claude-bot]

Both issues this ask's recommendation is conditioned on were closed an hour before I posted it — and the condition it names is now a scheduled release

My escalation an hour ago put the ruling in canonical form and recommended "A now, C if #291's CPU swap is really the road." That conditional points at an issue that was already closed when I wrote it, and the answer to the condition is now on the board. Correcting it here rather than leaving a decider to discover it.

Read from the issues' timelines: #291 closed 2026-08-03T15:54:55Z and #296 closed 15:54:58Z, in the operator-directed board-hygiene pass. Both still carry blocked; a close does not move the queue label. Neither was declined — each close comment names the roadmap epic carrying it: #291 → #333 (0.2.1 — more chairs), #296 → #163 (0.2.0).

What that does to the questions, one by one

Q1 — is the class expected to recur? The body argued it becomes a lifecycle event if #291's droid model is really the road. The roadmap answers that it is, and dates it: #333's own row for #291 reads "one droid per role, one room per droid, an identity that survives the CPU swap." So the CPU swap is not a hypothetical this ask has to guess at — it is a declared 0.2.1 deliverable, and on that road identity replacement stops being an incident.

Q2 — is the fork model load-bearing? Untouched. Nothing on the roadmap names branch hosting, permissions, or the fork, and option C is still an org-policy decision.

Q3 — what must actually survive? Now partly pre-empted, and by a different window than option B would have sat in. #335 (0.2.3 — restore and continuity: a member survives its box) carries a to-mint bullet reading "member state manifest: what must be exported for a faithful restore (identity, claims, working memory, ledgers)" plus crew restore <member>. A manifest that enumerates identity and claims is Q3's question answered as a spec for a neighbouring purpose — box death rather than identity replacement — and the two want the same list.

What this does to the recommendation, and what it does not

The block stands and the options are unchanged. Default: none — hard block; C changes the permission story and every repo's branch flow, which is org policy. Triage does not pick this one.

What is now visible, and was not when the ask was posted: B has a natural home — #335's restore manifest and #333's identity-survives-the-CPU-swap work are the two places an engine-side handover verb would live, in windows that already exist. So the honest shape of the ruling today is A now, and B or C as a decision about which of two scheduled arcs absorbs it — rather than a choice between three unhomed shapes. That does not change what the decision costs, and it does not make it triage's.

A is still separable and still unminted. Fully specifiable from the measured #281 → #288 recovery in the body, minted on one word from @danmt, and deliberately not minted pre-emptively.

Outcome unchanged: escalate, waiting on @danmt

No needs-ruling label is owed anywhere — re-derived at this write with blockers.jq's own clause parse over all 22 open blocked bodies: every one names #346, none names this thread, and the two issues it discusses are closed. The thread is the whole wait.

Triage, 2026-08-03.

[dan-claude-bot]

The issue this ask's recommendation turns on is itself under a live ruling ask now — same decider, and the two answers interact

One delta since my comment of 2026-08-03 18:15Z, which answered Q1 by pointing at where #291 sits:

"#333's own row for #291 reads 'one droid per role, one room per droid, an identity that survives the CPU swap.' So the CPU swap is not a hypothetical this ask has to guess at — it is a declared 0.2.1 deliverable."

The window in that sentence is now contested. At 2026-08-04T12:03Z triage put a canonical ruling ask on the roadmap asking which epic owns #291 — #163 (0.2.0) or #333 (0.2.1) — because #291's own body still opens "Part of #163. Blocked by #163" while its close comment carried it to #333. Re-read from the close events rather than from either thread: #291 closed 2026-08-03T15:54:55Z naming #333; the body line predates it and was never struck. Triage's read there is A (#291 to 0.2.0), and the stated default is A at 0.2.0's window-open if nothing rules first.

What that does to this thread's three questions

• Q1 — is the class expected to recur? The answer is unchanged and does not depend on the window: identity replacement becomes a lifecycle event on the droid road under all three options, because none of them declines the droid model. What moves is when — a window earlier under The crew roadmap — 0.1.x nervous system, 0.2.x expansion, 0.3.0 federation #338's option A, unchanged under B, and split under C. So my 18:15Z sentence should be read as "a declared deliverable, in a window currently under ruling", not as 0.2.1 settled.
• Q2 — is the fork model load-bearing? Untouched by any of it. Still the question that decides this thread, still org policy, still nothing on the roadmap names branch hosting or permissions.
• Q3 — what must actually survive? Untouched. #335 (0.2.3) still carries the restore manifest that enumerates identity, claims, working memory, ledgers, and The crew roadmap — 0.1.x nervous system, 0.2.x expansion, 0.3.0 federation #338's question does not move 0.2.3 — restore and continuity: a member survives its box #335.

Why this is worth a comment rather than a footnote: both asks are addressed to @danmt, and answering this one A now, C if the CPU swap is really the road while answering that one B would leave the CPU-swap road one window later than the sentence this thread's recommendation leans on. Neither answer is wrong; they are just easier to give together than apart.

Outcome unchanged: escalate, waiting on @danmt

And the wait has a date, which it did not have stated before. This ask carries no needs-ruling label — none is owed, because nothing on the board is held by it — so the ruling ladder, which runs from an episode's labeled event (LABELS.md), has no clock here and no rung of it fires. What does apply is the 7-day nudge: this escalation was posted 2026-08-03T16:43Z, so absent real activity triage returns on 2026-08-10 and says so again rather than letting it go quiet indefinitely. A is still separable, still fully specifiable from the measured #281 → #288 recovery in the body, and still unminted — an issue enters a release by decision, not by triage's default.

Nothing is waiting on this thread. Re-derived at this write by running blockers.jq's clause parse over all 22 open blocked bodies: every one names #346 and twelve now also name a same-file predecessor after the 19:27Z edge pass; none names this thread, and both issues it discusses are closed. The board is 43 open — 22 blocked, 18 epic, 3 post-merge — zero ready, zero claimed, zero open PRs, and no needs-ruling anywhere.

Triage, 2026-08-04.

[dan-claude-bot]

The 7-day return — and Q1 gained a second road to recurrence that does not wait on #338's ruling

This is the return my comment of 2026-08-04 21:21Z promised for today, rather than letting the ask go quiet indefinitely. No reply of any kind has been posted here since the escalation of 2026-08-03 16:43Z. Everything below is re-run at main's head bf4c3de and off the live label sets, not carried forward — which is this thread's own discipline, because the whole ask rests on one structural fact and a structural fact is exactly the kind that gets quietly repaired.

1. The load-bearing fact, re-measured — the fork model is intact

The cause this thread names is fork ownership, not identity in the abstract. Measured over the last 40 pull requests on this repository, open and merged, by headRepositoryOwner:

head lives on	count
andriujoseba	24
cndgrr	15
dan-claude-bot	1
heavy-duty/crew	0

Both PRs open right now are the same shape — #450 at andriujoseba/build/400-cut-0-1-2 and #451 at cndgrr/fix/449-pipefail-guard-reach. Not one fleet branch has ever lived on the org repository. So Q2's question — what does the fork buy today that the org repo does not? — is exactly as unanswered as it was, and option 3 still dissolves the class rather than managing it.

And the class has not recurred by incident. No identity replacement has happened since 2026-08-02; the 38m 39s in the table above is still the only measurement this thread has. That is the honest reading of the quiet: nothing has forced the decision, which is precisely why it is still open eight days later.

2. What actually moved — #442, minted 2026-08-09

My 2026-08-03 answer to Q1 — is the class expected to recur? rested entirely on #291's CPU swap, and my last comment then had to weaken it to "a declared deliverable, in a window currently under ruling" when #291's window became contested. It no longer has to rest there.

#442 (0.2.5 — ephemeral boxes) was minted 2026-08-09 and says, in its own words: a member's box is "minted or woken on claim, torn down when the duty ends", and

"0.2.3 (#335) makes a member survive its box, without which a box per duty is lossy"

"Restore-on-wake — 0.2.3's member manifest becomes the routine path rather than the recovery path."

Re-read from #335's body at this write rather than quoted from my own earlier comment, that manifest is "what must be exported for a faithful restore (identity, claims, working memory, ledgers)" — Q3's list, near enough verbatim.

So Q1 now has two independent roads to yes, and they do not share a decider. One is #291's CPU swap under a stable chair, whose window is what #338's ruling ask is about. The other is #442, which nobody has contested: once a box is destroyed at the end of every completed duty, a claim and its round record surviving the disappearance of the thing that held them stops being an incident shape and becomes the normal path, executed many times a day. What #338's ruling still moves is the date, not the answer.

3. What #442 does not do — and it is the half this thread is actually about

A restore manifest can carry a claim, a ledger and a working memory across a box boundary. It cannot make an incoming identity able to push to an outgoing identity's fork. #442 changes what happens when a box dies; this thread is about what happens when the account holding the branch is replaced, and those are different boundaries that happen to look alike. A member restored on a fresh box under the same identity finds its branch exactly where it left it. A member restored under a new identity finds it unreachable, in the same way #281 was.

So: Q2 is untouched by any of this and remains the question that decides the other two. If the fork model is not load-bearing, option 3 removes both boundaries at once and Q1's date stops mattering. If it is, then 0.2.5 makes the cheap half routine while leaving the expensive half exactly where it is today — which is a worse place to discover it than here.

4. The sibling ask, and nothing waiting on this thread

#338's ask — which epic owns #291, 0.2.0 (#163) or 0.2.1 (#333) — is still unanswered at 2026-08-04T12:03:51Z + six days: all eleven comments on that page are triage's, with no reply and no reaction from anyone else. Triage's read there is still A, and its own return falls tomorrow, 2026-08-11. Re-verified rather than assumed: #291 and #296 are both CLOSED (2026-08-03 15:54Z) and both still carry blocked, a close moving no queue label; #163 and #333 are both open, epic + release, neither carrying a queue label.

Nothing on the board is held by this thread, and this time the population says so rather than an inspection. The open blocked set is empty — zero open issues carry blocked at this write — so blockers.jq's clause parse has nothing to run over and the union is empty by population, not by reading 22 bodies as in my last two censuses here. Board, read from the live label sets at this write: 28 open — 20 epic, 6 post-merge, 2 claimed (#400, #449), and zero ready, blocked, needs-triage, needs-ruling, attention, stale and offsite. Two open PRs, as above.

Outcome unchanged: escalate, waiting on @danmt

@danmt — the ask is the block at the top of this thread, unchanged: A, B, or C, with triage's read still A now, C if the CPU swap is really the road — and after §2, "if the CPU swap is really the road" is a weaker condition than it was, because #442 gets to the same recurrence without it.

No needs-ruling label is owed and none is set — nothing on the board is held by this ask, so the ruling ladder, which runs from an episode's labeled event (LABELS.md), has no clock here and no rung of it fires. What applies is the 7-day nudge, and this comment is it. Absent real activity, triage returns on 2026-08-17.

A is still separable, still fully specifiable today from the #281 → #288 recovery measured in the body, and still unminted — one word from you mints it, and it pre-empts neither B nor C. It stays unminted rather than slipped in, because an issue enters a release by decision and not by triage's default.

Triage, 2026-08-10.

[dan-claude-bot]

The 7-day return — the exposure is live right now, on two other boards, and a login is about to become configuration in three

This is the return my comment of 2026-08-10 10:48Z promised for today. No reply of any kind has been posted here since the escalation of 2026-08-03 16:43Z — every comment on this page is triage's. Everything below is re-measured at this write rather than carried, which is this thread's own discipline.

1. The load-bearing fact, re-measured — and this time at full-history scope, which corrects one cell of my last table

The last-40-pull-request window I measured on 2026-08-10 returns the identical split today — andriujoseba 24, cndgrr 15, dan-claude-bot 1, heavy-duty/crew 0 — but that window has shifted by three pull requests since, and a figure reproducing is not the same as a figure holding. So I ran it over every pull request this repository has ever had, by headRepositoryOwner:

head lives on	count
dan-claude-bot	44
andriujoseba	40
codex-bot-andresmgsl	36
cndgrr	34
claude-bot-andresmgsl	29
kimi-bot-andresmgsl	4
grok-bot-andresmgsl	3
heavy-duty	1
total	191

The 0 in my last table was a 40-PR figure, and at full scope it is a 1 — #182, head heavy-duty:fix/176-177-hire-and-drill, opened 2026-07-30T18:39:12Z and merged 19:05:18Z, by @danmt. That is the human operator pushing to the org repository directly, not a fleet member. So the sentence that cell was supporting — "not one fleet branch has ever lived on the org repository" — is unchanged and now measured over 191 pull requests instead of 40, which is a stronger claim than the one it replaces. It is corrected here rather than left for a decider to trip over, because a structural fact is exactly the kind that gets quietly repaired and this ask rests on one.

Note the first row while it is on screen: even triage's own 44 pull requests live on a fork. The fork model is not a builder convention, it is how every identity in this fleet has ever opened work.

2. What is genuinely new: the exposure is four pull requests wide at this moment, and none of it is on this board

My last comment read the quiet on this repository as "nothing has forced the decision." That reading was right about crew and would be wrong about the fleet today, so it is re-scoped rather than repeated. crew's board has zero open pull requests and main has not moved since 2026-08-12T12:34:02Z. The two builders are not idle — they are working on the sibling boards, and every head is a fork:

pull request	head	last touched
ceremony#454	andriujoseba:build/452-fleet-builders	2026-08-16 23:00Z
ceremony#455	cndgrr:build/453-fleet-dedup	2026-08-16 23:11Z
incubator#256	andriujoseba:build/241-ai-email-disclosure	2026-08-16 22:36Z
incubator#246	cndgrr:build/239-legal-disposition	2026-08-17 00:14Z

Four in-flight branches, four forks, zero on an org repository — the last of them touched at 2026-08-17T00:14Z, minutes before this write. If either identity were replaced right now, that is four #281-shaped recoveries and not one, in two repositories neither of which has this thread on it.

And the class still has not recurred by incident. No new builder login has appeared: the newest 40 heads here are cndgrr, andriujoseba and dan-claude-bot only, the 2026-08-02 replacement is still the sole instance, and its 38m 39s is still this thread's only measurement. What changed is not the frequency — it is that the standing exposure is now measurable, and it is four wide.

3. New for Q3 — a builder login is about to become configuration in three repositories

#458 was minted on this board 2026-08-16, transcribing @danmt's ruling on ceremony#435 — option A, taken across the fleet: a per-author panel[<login>]= row for each live builder login in each governed repository's .github/labels.conf. Its two siblings are ceremony#452 (claimed by @andriujoseba, PR ceremony#454 above) and incubator#257 (ready).

When those three land, cndgrr and andriujoseba are named by literal login, in checked-in configuration, in three repositories. That does not touch Q2 — it is not about branch hosting. It moves Q3 — what must actually survive — and it moves it in a direction Q3's current answer does not cover: #335's restore manifest enumerates identity, claims, working memory, ledgers, all of which are state. A roster row is not state; it is a config round in three repositories that a manifest cannot carry and a restore cannot perform.

And the reason those rows exist is this thread's own cause, arriving in a second place. #458 states the mechanism plainly: "The identity that owns the branch cannot rerun its own head — a fork PR's run lives in the base repository and rerunning it needs actions: write there." That is fork ownership producing a second structural unavailability — this time not "the incoming identity cannot push" but "no identity can service its own red run" — and the fix for it is an allow-list keyed to login. Option C dissolves that one too. Worth stating precisely, because it is the strongest thing in this comment: on crew the cost is deferred (this board has no ci-rerun caller and no rerun-owed label, so #458 is inert here today), but on ceremony the refusal has been live since 2026-08-15.

4. A retraction landed on #442, and it does not reach §2 of my last comment

Anyone arriving at #442 — the second road to recurrence in my 2026-08-10 §2 — now meets a retraction posted 2026-08-15T16:03Z. Saying what it did and did not touch, so nobody has to re-derive it:

• It postdates §2 by five days. It corrects a comment of 2026-08-15T15:19Z; §2 could not have rested on figures that did not exist when it was written.
• It retracts field measurements, not the design. The withdrawn claim was a cost figure (+13.4 GB in 24 days) taken on a builder box and attributed to the triage box. §2 quoted 0.2.5 — ephemeral boxes: a box per duty, forty members on one host #442's body — "minted or woken on claim, torn down when the duty ends" and "restore-on-wake — 0.2.3's member manifest becomes the routine path rather than the recovery path" — and those are untouched.
• The retraction says so itself: "the argument in the retracted comment stands … ephemerality retires the accumulation class completely."

So Q1 still has two independent roads to yes, and #338's ruling still moves the date rather than the answer.

5. The sibling ask, and nothing waiting on this thread

#338's ask — which epic owns #291, 0.2.0 (#163) or 0.2.1 (#333) — is still unanswered, thirteen days on. My last comment said its own return fell "tomorrow, 2026-08-11"; it was missed by five days and nudged 2026-08-16 12:1xZ, and its next return is 2026-08-23. Triage's read there is still A.

Nothing on the board is held by this thread, measured rather than inspected. Running blockers.jq's own clause parse over all three open blocked bodies at this write:

issue	parsed blockers	state
#454	{#327, #452}	#327 open, #452 closed
#457	{#327, #454}	both open
#458	{#327}	open

This thread appears in none of them, and every live term is the 0.1.3 release-init hold. The board, read from the live label sets: 27 open — 19 epic, 5 post-merge, 3 blocked — and zero each of ready, claimed, needs-triage, needs-ruling, attention, stale, offsite; 0 open pull requests; main at 394bdad.

No needs-ruling label is owed and none is set. Nothing on the board is held by this ask, so the ruling ladder — which runs from an episode's labeled event (LABELS.md) — has no clock here and no rung of it fires. What applies is the 7-day nudge, and this comment is it.

Outcome unchanged: escalate, waiting on @danmt

@danmt — the ask is the block at the top of this thread, unchanged: A (written handover procedure), B (an engine verb), or C (branches live on the org repo). Triage's read is still A now, C if the CPU swap is really the road — and §3 strengthens the second half of that, because C now dissolves two fork-ownership walls rather than one.

A is still separable, still fully specifiable today from the measured #281 → #288 recovery in the body, and still unminted. One correction to how I put that last time: "one word from you mints it" was asserted, and it is now demonstrated — #458 is the worked example of a non-member issue minted during a standing release window, naming #327 as its blocker and adding nothing to the gate. So the 0.1.3 window is not what holds A. Only the ruling is. It stays unminted rather than slipped in, because an issue enters a release by decision and not by triage's default.

Absent real activity, triage returns on 2026-08-24.

Triage, 2026-08-17.

[dan-claude-bot]

The return, 8 days late — §3's prediction is now fact, and the premise that made it cheap on crew has flipped

Triage 2026-09-01. This is the return my comment of 2026-08-17 promised for 2026-08-24. It is eight days overdue, which is dealt with at the foot of this comment rather than passed over. Everything below is re-measured at main 70bd7d4, not carried — the previous return was written against 394bdad and 178 commits have landed since.

Still no reply of any kind on this page since the escalation of 2026-08-03. Every comment here is triage's.

1. §3 predicted a thing; the thing happened. All three issues are closed

Last time this section read "a builder login is about to become configuration in three repositories." It has:

issue	state
crew#458	CLOSED 2026-08-24T16:54:29Z
ceremony#452	CLOSED 2026-08-17T00:46:22Z
incubator#257	CLOSED 2026-08-17T13:27:06Z

Read from the tree rather than from the closes — .github/labels.conf at 70bd7d4 carries both logins literally, on lines 2 and 3:

panel[cndgrr]=claude-bot-andresmgsl codex-bot-andresmgsl kimi-bot-andresmgsl
panel[andriujoseba]=claude-bot-andresmgsl codex-bot-andresmgsl kimi-bot-andresmgsl

So Q3 — what must actually survive — now has a concrete answer it did not have, and it is one #335's restore manifest still does not cover. That manifest enumerates identity, claims, working memory and ledgers, all of which are state. These two rows are not state: they are a config round in three repositories that a manifest cannot carry and a restore cannot perform. Last time that was a forecast about Q3's shape; it is now a measurable gap with a file and a line number.

2. The premise that made #458 cheap on crew is false now, and this is the biggest delta on the page

§3 closed with a hedge: "on crew the cost is deferred (this board has no ci-rerun caller and no rerun-owed label, so #458 is inert here today), but on ceremony the refusal has been live since 2026-08-15."

Both halves of that hedge are now false on crew. Measured:

• .github/workflows/ci-rerun.yml exists at 70bd7d4 and calls heavy-duty/ceremony/.github/workflows/ci-rerun.yml@0.7.7 on pull_request_target: [labeled], with actions: write — "the rerun no fork PR author can start; the whole reason this exists."
• The rerun-owed label exists on this repository, checked against the live label set rather than against labels.conf (which carries only scope rows and the roster, so its absence there proves nothing — I checked that too before saying it).

So the fork-ownership wall this thread names is no longer deferred here; it is instrumented here, and #574 — ready + operator — is on the board waiting for the fleet's first live rerun-owed service on a genuinely red fork PR. That issue is this thread's cause with a queue label on it. It strengthens option C exactly as §3 argued — C dissolves the wall rather than servicing it — and it is the first time the argument has had a board entry rather than a forecast behind it.

3. The exposure is wider than last time, and crew is no longer the quiet board

Last time: four in-flight fork branches, all on sibling boards, crew with zero open PRs and main frozen since 08-12. Now, measured across the fleet at this write:

pull request	head owner
crew#630	andriujoseba
crew#631	cndgrr
ceremony#593	cndgrr
incubator#481	andriujoseba
incubator#482	cndgrr

Five in flight, five forks, zero on an org repository — and two of them are on this board, which had none last time. If either identity were replaced right now that is five #281-shaped recoveries, two of them here.

And the class still has not recurred by incident. Same two builder logins, no new one has appeared, the 2026-08-02 replacement is still the sole instance and its 38m 39s is still this thread's only measurement. What has changed is only the standing exposure, and it is now five wide.

4. Nothing on the board is held by this thread — re-measured, not assumed

The board is transformed since last time: 51 open (was 26) — 18 epic, 20 blocked, 10 ready, 2 claimed, 1 post-merge, 7 operator — with 0 needs-ruling, 0 attention, 0 needs-triage and 0 stale. Ten claimable issues where there were none; 0.1.3's wave landed in the interval.

Running the shipped blockers.jq's own clause parse over all 20 open blocked bodies, this thread appears in none of them, and no open issue body is gated on it. No needs-ruling label is owed anywhere and none is set — so the ruling ladder, which runs from an episode's labeled event, still has no clock here and no rung of it fires. The seven-day nudge is what applies, and this comment is it.

5. Why this is eight days late, and the measurement that says re-promising alone will not fix it

This is the fourth consecutive recorded miss on this family of returns: #229, #269 and #338 promised 2026-08-23, this one 2026-08-24, and all four were found overdue and unhonoured on 08-27, 08-29 and 08-31 before today. Recorded rather than quietly re-dated.

And a measurement worth having, taken because "the human is absent" is the premise most likely to be wrong and least likely to be checked. It is wrong, and not in the direction that flatters the nudging:

• @danmt has commented on the crew issue board on eight issues since these returns came due — shared/test/run.sh — 2145 assertions in one 15,110-line file with no section markers, so every issue on this board serializes on it: a ten-deep chain with zero open PRs behind it #470, shared/lib/common.sh — 29 functions and six unrelated subjects in one file, so twelve members of this window serialise on it: split by the code's own axis, suites mirroring source #507, shared/bin/claim-issue.sh — a failed claim mutation strips ready and the repair is guarded on the state it never reached: restore from the pre-mutation read, and fail closed on a missing label #459, the ceremony pin moves 0.6.2 → 0.7.6 across nine references and the .ceremony/ mirror, and the fleet gets the rerun servicing it cannot start for itself #505, shared/lib/common/ — the engine should declare its own operating limits and flag them, rather than discovering them by execve failure in a subprocess #482, bot_quota_report() — optional vendor quota, enriching the usage report without founding it #485, fleet-floor/server/floor.py — the fleet's two watch registries are host files, so re-pointing one droid at a different repository takes ssh and several edits by hand #488, Move the ceremony pin from 0.7.6 to 0.7.7 — ten refs, one tag, no migration crossed #603 — most recently 2026-08-31T21:40:23Z, yesterday.
• @danmt has commented on zero of the fourteen open crew discussions.
• Across every closed crew discussion, @danmt has replied to exactly three — #455 and #460, both of which they opened, and #456, filed and answered the same day. The last reply on any crew discussion was 2026-08-19T19:17Z, thirteen days ago.

So the decider is present, is engaging daily, and is engaging on issues. These four asks are long-running and triage-authored, and have drawn no reply in 29 days. That is not an inference about intent and I am not offering one — it is the surface statistic, and it says a fifth identically-shaped nudge on this surface is the thing that has already failed four times. Triage is not changing the outcome or picking anything on the strength of it: nothing on the board is held, no rung fires, and the decision is still yours. It is reported because it is the one fact about this thread that the thread itself cannot show.

Outcome unchanged: escalate, waiting on @danmt

@danmt — the ask is the block at the top of this thread, unchanged: A (a written handover procedure), B (an engine verb), or C (branches live on the org repo). Triage's read is still A now, C if the CPU swap is really the road, and §2 above is the strongest evidence C has yet had — the wall it dissolves is now live on this board with an issue waiting on it.

A is still separable, still fully specifiable today from the measured #281 → #288 recovery in the body, and still unminted. It stays unminted rather than slipped in, because an issue enters a release by decision and not by triage's default.

One line answers this and one line parks it. If you park it, triage stops nudging until you unpark it. Absent either, triage returns on 2026-09-08.

Triage, 2026-09-01.