A leader (foreman) agent — steering, plan confirmation, rulings from precedent, and a merge door no bot has today

[dan-claude-bot]

Moved from #225, filed from the sherpa session on 2026-08-01 and flagged needs-triage by the sweep the same minute. Nothing is retracted or summarised away: the proposal is carried verbatim at the foot of this thread. It is here rather than on the board because an issue is a work order a builder must be able to execute without asking anyone anything (TRIAGE.md), and this one is a design proposal that parks itself.

Why triage sent it back through this door

Three reasons, any one of which would be enough:

1. It parks itself. Its own text: "Deferred by design: parked for 0.2.0. Right now the focus is platform stability/robustness with the current five-box roster … Pick this up once the current design is battle-tested", and it signs off "needs triage refinement before placement." An issue that says it is not to be built is a design thread wearing a label. Minting it anyway would put a blocked work order on the board carrying its ambiguity forward to whichever builder eventually picks it up — which is exactly the move TRIAGE.md exists to prevent.

2. Its stated hard precondition is four open issues, and one of them is waiting on a human right now. Verified against the board at the time of writing: #210, #211, #213 are open and blocked; #212 (a ruleset on main) is open, blocked, and has carried needs-ruling since its labeled event at 2026-07-31T20:29:00Z — the ladder's 24h rung falls at 2026-08-01T20:29Z. (Struck by triage 2026-08-01 22:4xZ against #212's label events: that rung passed and the ruling is closed. needs-ruling was removed at 20:36:48Z and triage picked option A — a main ruleset requiring release-guards / guards, strict: true, with a bypass actor for the repository's own Actions identity and no required_pull_request_reviews. #212 itself is still open and blocked behind #211 and #162, so the precondition's issue count is unchanged — what moved is that no part of it waits on a human decision any more. What the pick produced instead is discussion #269, and it lands on Q3 below.) The proposal's own sequencing puts "close #210–#213" first, and merge authority for any agent cannot be specified before the merge door itself is decided.

3. The open questions are the load-bearing ones. Where the two brains live, what "the plan" is as an artifact, and what the leader's merge policy checks mechanically are all unspecified. A builder handed this today would guess three times over, and guessing is the failure this flow exists to prevent.

The questions whose answers let triage write the issues

Three, pointed, in the order their answers unblock work. @danmt — the first is the cheap one and yields the first buildable issue on its own.

Q1 — the two brains, concretely: where do they live and what reads them?

The proposal calls the fleet-wide brain "its own repo (analog of a global CLAUDE.md)" and the repo-scoped brain "lives in each repo (analog of a project CLAUDE.md)", with the injection point "the crew duty engine pulls both brains into context before any duty fires." Each phrase hides a different work order:

• Fleet-wide: a new heavy-duty/<name> repository, or a directory inside an existing one? A new repo means a new read grant on every box's identity — the fleet is trustless and each box acts as itself, so this is fleet-config work, not a file drop.
• Repo-scoped: which path, and how does it relate to what a repo already ships — the AGENTS.md router and the vendored .ceremony/ mirror? Beside them, or the same file? (.ceremony/ is machine-managed and must not be hand-edited in a governed repo, so it cannot be the home.)
• Injection: fetched per tick by duty.sh, baked in at hire time, or assembled into the session prompt? Per-tick fetch is a network dependency on the hot path; hire-time baking goes stale between crew up runs. These are different builds with different failure modes, and the proposal's own sequencing calls this step "cheap, leader-independent, immediately useful" — it is, once these three are answered.

Q2 — what is "the plan", as an artifact?

The proposal says "a versioned artifact (file/milestone structure in the ceremony repo)" and that triage "proposes placement as a small PR/comment" which the leader "approves-or-repositions." Two things to name:

• The artifact: a file in a repo, GitHub milestones, or an epic-issue tree? The board already has a plan of exactly this kind — three gates (the 0.1.0 acceptance run — deploy it, run a real crew, and let a second operator set one up #207 acceptance, 0.1.2 — polish after first real use, and the fixes that only a used fleet can justify #162 0.1.1, 0.2.0 — the crew works for weeks, and the operator only rules and merges #163 0.2.0) over a set of epics — so the answer decides whether this is new machinery or a new reader of the machinery that exists. The second is far cheaper and may be most of the value.
• The approval, on the board: what does "the leader confirmed the placement" look like as a fact someone can read — a label, a merged PR, a comment? A confirmation loop with no observable state is the silent-stall shape this fleet has already been bitten by five times (The review duty auto-approves over a standing request-changes — 3 of its 4 fires were wrong #114, round_owed is the third round-close predicate, and the only one that ignores the head #147, duty-builder's handoff query asks for 200 comments — GraphQL rejects it, and the error body defeats the empty-payload guard #155, AUTO_APPROVE_REREQUEST=0 also suppresses re-review over a standing block — the flag gates one branch too many #158, gh api --jq discards its filter on a GraphQL error — three duty guards can never fire #161).

Q3 — does the leader merge, or prepare merges? (danmt's alone)

This is the one triage will not pick for you at any rung. "Only humans merge" is one of the two rules that bind every role in .ceremony/AGENTS.md — it is governing doctrine vendored from heavy-duty/ceremony, not a crew convention — and under LABELS.md org policy is a hard block by construction. Two sub-questions size the work:

• Where does the change land? In ceremony's doctrine first — making it true for box, rig and cast too — or does crew carve an exception for itself, and say so out loud where the next reader of AGENTS.md will find it?
• Who evaluates the mechanical policy? "CI green, review threshold met, issue traceable to the plan" is either a check a bot performs before pressing merge, or a ruleset GitHub performs — which is main — a ruleset with required checks and strict up-to-date, so a release PR cannot merge stale #212's exact shape and argues for settling that ruling first. Note the fleet's identities cannot create a ruleset today: triage's own token reports "admin": false, "maintain": false. Updated 2026-08-01 22:4xZ: that ruling is settled — option A, above — so this sub-question is no longer waiting on it. It is now harder rather than easier, and #269 is why: under a strict: true ruleset nothing in this fleet reads mergeStateStatus, so a BEHIND PR reads as mergeable to both writers of state:needs-human. A leader agent that merges would be pressing a button the board is currently lying about. That defect is a precondition of any merge authority, agent or human, and it is asked there rather than here.

The proposal's separation-of-duties argument — the leader writes no code, so it never merges its own work — is sound and worth keeping whichever way this goes.

Where this sits on the board meanwhile

Recorded on #163 (0.2.0 — the crew works for weeks, and the operator only rules and merges) as a candidate against its requirement 6, which says of rulings and merges: "nothing on the board covers this … It should get one before 0.2.0 starts." That requirement asks for the human's two remaining jobs to be excellent; this proposal asks whether one of them stops being the human's. Same subject from opposite ends, and neither is minted until the questions above are answered.

Nothing on the board is blocked by this thread. #207, #162 and #163 are unaffected, and every ready issue continues.

---

The proposal, as filed on #225 — verbatim

Summary

Add a leader (foreman) agent to the fleet: a sixth box whose job is steering, not building. It defines goals/vision, keeps the plan, adjudicates, and (eventually) merges to main — while the human gate narrows to release PRs only.

Deferred by design: parked for 0.2.0. Right now the focus is platform stability/robustness with the current five-box roster; the operator + sherpa act as interim leader. Pick this up once the current design is battle-tested.

Division of labor (decided)

• Triage (narrowed): takes a rough human idea and refines it — problem space, implications, trade-offs, what it blocks/unblocks — then attaches it to the plan in the right place, with confirmation from the leader.
• Leader: owns goals and vision. Is everyone working? Is a ruling needed? Are two builders building the same thing? What are the priorities? Proposes release scope (drafts the release PR); the operator approves it. The leader never writes code.

Authorities

• Merge-to-main authority for the leader, with human gating only release PRs. Since the leader authors no code, it never merges its own work — separation of duties for free.
• Hard precondition: the merge-door holes .github/actions/release-artifact — build crew-<version>.sh through ceremony's asset hook, so both release doors attach it #210–drills — bind the drill record to the tree it drilled, so a release cannot inherit another tree's green #213 (no artifact asset, unverified tip, zero branch protection, vacuous drill guard) must be closed before any agent gets merge rights.
• Mechanical merge policy: CI green, review threshold met, issue traceable to the plan; anything touching the release process bounces to the operator.

Plan + confirmation loop

• The plan is a versioned artifact (file/milestone structure in the ceremony repo). Triage proposes placement as a small PR/comment; the leader's duty loop approves-or-repositions on its next pass. Silence never blocks a builder from starting refined-and-placed work.
• Degraded mode (leader box down / cron paused): fleet continues on the last-approved plan; triage queues placements. No stall.

Rulings + the two brains

• The leader rules from precedent. Fleet-wide brain = case law, including the operator's codified standing rules. No precedent → escalate to the operator; the answer is written back as new precedent. Every escalation shrinks the set of future escalations.
• Fleet-wide brain: its own repo (analog of a global CLAUDE.md). Leader writes directly.
• Repo-scoped brain: lives in each repo (analog of a project CLAUDE.md). Builders propose entries via PR; the leader merges.
• Injection point: the crew duty engine pulls both brains into context before any duty fires.
• Day-one seed: migrate the sherpa session's accumulated gotchas (gh re-request behavior, Coolify pull invariant, box sudo -i exec breakage, …) into the fleet brain — currently that knowledge is invisible to the boxes.

Sequencing

1. Close .github/actions/release-artifact — build crew-<version>.sh through ceremony's asset hook, so both release doors attach it #210–drills — bind the drill record to the tree it drilled, so a release cannot inherit another tree's green #213 (merge door).
2. Stand up the two brains + duty-engine injection (cheap, leader-independent, immediately useful).
3. Hire the leader box: plan confirmation, rulings, merge authority.
4. (Future, separate issue) voice comms on the Fleet Floor as the interface to the leader.

Out of scope

• Voice comms (future).
• Any change to builder duty loops beyond reading the plan/brains.

---

Rough issue from an operator + sherpa design session (2026-08-01); needs triage refinement before placement.

[dan-claude-bot]

The precondition this thread cited as "waiting on a human" is settled — and Q3 got harder, not easier

Two passages in the body above are struck and corrected in place, against /repos/heavy-duty/crew/issues/212/timeline rather than against #212's thread. Nothing about this thread's outcome changes: it is still ask, still waiting on @danmt, and Q1 is still the cheap one that yields a buildable issue on its own.

What moved. #212's ruling closed at 2026-08-01T20:36:48Z — needs-ruling removed, option A recorded as a decision, picked by triage at the past-24h rung and mine to answer for. A main ruleset requiring release-guards / guards, strict: true, a bypass actor for the repository's own Actions identity, and deliberately no required_pull_request_reviews. #212 is still open and still blocked behind #211 and #162, so the "four open issues" precondition is numerically unchanged — what is no longer true is that any part of it is parked on a human's turn.

Why that makes Q3 heavier. Reason 2 in the body treated the pending ruling as the thing in the way. Closing it surfaced what was actually underneath, and it is now discussion #269: nothing in this fleet reads mergeStateStatus. Both readers of a PR's mergeability read only mergeable, which never reports behind. Under a strict: true ruleset a PR twelve commits behind main is still MERGEABLE, so the engine hands it off and both writers of state:needs-human — crew's engine and ceremony's reconciler — assert a label whose contract is "this PR could be merged right now" about a PR GitHub will refuse.

That is A-conditional and nothing is wrong on main today. But it is a precondition of merge authority for any merger, agent or human: a leader agent that merges would be pressing a button the board is currently lying about, and it would be doing so faster and more often than an operator who notices the greyed-out button. So Q3's second sub-question — who evaluates the mechanical policy — cannot be answered "a ruleset GitHub performs" without #269's answer first. The ordering the proposal itself asked for is intact; the item at the head of it changed.

What this does not change. The proposal's separation-of-duties argument still holds, Q1 and Q2 are untouched, and "only humans merge" is still governing doctrine vendored from heavy-duty/ceremony — still the one thing triage will not pick at any rung. Nothing on the board is blocked by this thread.

Triage, 2026-08-01.

[dan-claude-bot]

Correction — this thread's header says #225 closed, and since 13:01Z today that is false. The outcome does not change.

Re-read from /repos/heavy-duty/crew/issues/225/timeline rather than from this thread:

• 2026-08-01T13:02:06Z — closed by dan-claude-bot, the move this thread's header describes.
• 2026-08-02T13:01:36Z — reopened by dan-claude-bot, enhancement + scope:duty + blocked applied two seconds later.

#225 is back on the board as the leader chair's charter under the new governance-chairs epic #295 — sentinel detects, medic acts, leader rules — minted at danmt's direction from the acting-leader sessions of 2026-08-01/02, with #128 (sentinel) and #296 (medic) beside it. #225 now declares Part of #295 and Blocked by #163, and carries a field addendum recording what two days of doing the job for real taught.

The three questions are unchanged and still unanswered. I checked each against the addendum and against #295's text rather than assuming:

	status
Q1 — where the two brains live, and what reads them	open. #295's sequencing says "the two brains stand up (#225), seeded with the … case law" and the addendum extends the seed's contents. Neither says which repository or path, or whether injection is per-tick, hire-time or prompt-assembly. Those are still three different builds with three different failure modes.
Q2 — what "the plan" is as an artifact, and what the leader's confirmation looks like on the board	open. Nothing in the addendum or #295 names a file, a milestone set or an epic tree, or the observable fact that says a placement was confirmed.
Q3 — does the leader merge, or prepare merges	open, and still danmt's alone. #295 orders it ("leader's merge authority last") and re-affirms the #210–#213 precondition, but ordering a decision is not making it. "Only humans merge" is still governing doctrine vendored from heavy-duty/ceremony.

The addendum is genuinely valuable and none of it is a substitute for these: it records how the ruling loop runs, that recording is the job rather than the paperwork after it, and that a leader whose approval queue grows with fleet size is mis-specified. That is doctrine for the chair, not a spec for the brains.

What actually changed for this thread. The answers no longer produce a fresh mint from here — they land on #225's charter and on #295's sequencing, where the work is now organized. This thread stays the design record and the place the questions were put. Outcome unchanged: ask, waiting on @danmt, and Q1 is still the cheap one that yields a buildable issue on its own.

Nothing is stalled by the ask. #225 is blocked behind #163 (0.2.0), so no builder can reach the ambiguity, and #295 is blocked on the same gate. I have added a pointer to these three questions at the head of #225's body so nobody has to find this thread to learn its spec is open.

Triage, 2026-08-02.

[dan-claude-bot]

Correction — my comment above says #295 is blocked, and its label events say that stopped being true twenty-two minutes after I wrote it

My comment yesterday closed with:

"Nothing is stalled by the ask. #225 is blocked behind #163 (0.2.0), so no builder can reach the ambiguity, and #295 is blocked on the same gate."

Re-read from /repos/heavy-duty/crew/issues/295/timeline rather than from this thread: blocked was applied at 2026-08-02T13:00:47Z and removed at 14:33:55Z — my comment was written at 14:11:07Z, and the sentence has been wrong for the twenty-two hours since. #295 carries enhancement, scope:duty and epic, and nothing else.

The removal was right, and the conclusion it supported is stronger without it. An epic is exempt from the one-of-ready/claimed/blocked/post-merge invariant, and #295's own body says where its hold actually lives: "It is carried as a Blocked by #163 declaration on each of the three children." Re-read from their label events, all three still carry it — #128 blocked since 2026-08-02T13:01:41Z, #225 since 13:01:38Z, #296 since 13:01:21Z, none lifted. So the gate holds the work at the three places a builder could pick it up, and builders never pick an epic in the first place. Nothing is stalled by the ask was the right claim resting on the wrong label.

Recorded here rather than left to the next reader to diff, because this thread's whole ask is about who holds which authority, and a scanning agent reads the label.

The three questions are unchanged and still unanswered, re-checked against the board rather than assumed: Q1 (where the two brains live and what reads them), Q2 (what "the plan" is as an artifact and what the leader's confirmation looks like on the board), and Q3 (does the leader merge, or prepare merges) — still @danmt's alone, still governed by "only humans merge" vendored from heavy-duty/ceremony. Q3's precondition set is also unchanged: #210, #211, #212 and #213 are all open and all still blocked, and discussion #269 — nothing in this fleet reads mergeStateStatus — is re-verified at main's head today and still unanswered.

Outcome unchanged: ask, waiting on @danmt, and Q1 is still the cheap one that yields the first buildable issue on its own.

Triage, 2026-08-03.

[dan-claude-bot]

The precondition this thread called "four open issues" is now zero open issues and one release window — and the ordering it asked for is the roadmap's chain

My comment at 12:38Z closed on "#210, #211, #212 and #213 are all open and all still blocked" and "#225 is back on the board as the leader chair's charter." Re-read from the issues' own timelines rather than from this thread: none of the five is open. The operator-directed board-hygiene pass closed everything outside the current window between 15:54Z and 15:55Z today.

issue	closed	carried by
#210 — the artifact door	15:54:33Z	#332 (0.1.9 — harden the doors)
#211 — guards at the post-release tip	15:54:36Z	#332
#212 — a main ruleset	15:54:38Z	#332
#213 — bind the drill record	15:54:41Z	#332
#225 — the leader charter	15:54:47Z	#163 (0.2.0)
#291 — the droid model	15:54:55Z	#333 (0.2.1)

Every one still carries blocked — a close does not move the queue label, so the labels lie and the close events do not. Each close comment says the same thing (#210's is the pattern): not declined and not lost, carried by the named epic, re-opened or re-minted by triage when that window opens.

What that does to reason 2 — the hard precondition

The proposal's own sequencing is "1. Close #210–#213 (merge door). … 3. Hire the leader box: plan confirmation, rulings, merge authority." That precondition is unchanged in substance and now enforced by the release chain instead of by four tickets: #332 is 0.1.9 and lists all seven merge-door holes as its children; the leader's own charter sits on #163 (0.2.0), which the chain gates behind 0.1.10 and #207's unattended week. So the merge door opens a full release before the chair that would use it — the ordering this proposal asked for, arrived at from the other side.

What it costs is immediacy: the four holes are no longer four claimable issues on a gate that could close this week. They are a window seven ahead of the current one, opened by hand at triage's release-init. Nobody should read the closes as the merge door being shut. Not one of the seven shipped a fix.

What has not changed: all three questions

Re-checked against the board rather than assumed:

• Q1 — where the two brains live and what reads them — open. the governance chairs — sentinel detects, medic acts, leader rules: the loop that replaces the operator's weekend #295 still names "the two brains stand up (Leader (foreman) agent: steering, plan confirmation, rulings, merge authority #225)" in its sequencing and no epic names a repository, a path or an injection point.
• Q2 — what "the plan" is as an artifact, and what a confirmation looks like on the board — open, and the roadmap has quietly made half of it concrete without answering it: the plan today is an epic tree with a gate chain and a release-init cycle (discussion #338). Whether that is the artifact the leader confirms, or whether the leader wants something else, is still unanswered — but a reader of Q2 should now start from what exists rather than from a blank page.
• Q3 — does the leader merge, or prepare merges — open, still @danmt's alone, still governed by "only humans merge" vendored from heavy-duty/ceremony. Its second sub-question is unchanged too: discussion #269 is re-verified at this write — gh api repos/heavy-duty/crew/rulesets returns [] and branches/main/protection 404s, and mergeStateStatus still returns zero hits across the whole tree at main's head. Nothing in this fleet reads the field that would tell a merger the truth.

One thing the pass created that lands on Q1

The three charters (#225, #128, #296) are carried by #163, while the droid model they are written against (#291 — one droid per role, one room per droid) is carried by #333. Two roadmap epics, one dependency between them. It is recorded as an open placement question on #163, on #333 and on the roadmap, and it is @danmt's call — it bears directly on Q1, because where the chair's design lives and where the chair's instance model lives cannot be two different windows without someone reconciling them at init.

And the decomposition duty #295 records survives the closes, in a new form. It said triage owes each charter a decomposition into criteria-bearing children before #163 closes, or a re-pointing off the gate, because a criteria-free charter promoted by sweep is the #116 trap. With the charters closed, no sweep can promote anything — the duty becomes: re-open or re-mint them with acceptance criteria at 0.2.0's init, never as a bare re-open. Recorded so the close is not mistaken for the duty being discharged.

Outcome unchanged: ask, waiting on @danmt

Q1 is still the cheap one and still yields the first buildable issue on its own. Nothing is stalled by the ask — and less than before: the charter is closed, so no builder can reach the ambiguity at all. Nothing is waiting on this thread, re-derived at this write over all 22 open blocked bodies with blockers.jq's own clause parse: every one names #346, none names this thread.

Triage, 2026-08-03.

[dan-claude-bot]

Four days on: the placement question this thread recorded as "@danmt's call" is now a canonical ruling ask on the roadmap — and the three questions are unchanged

First comment here since 2026-08-03 18:05Z. Everything below is re-measured at main's head f5bd61c and from label and close events, not carried forward from this thread.

1. The one thing that pass created now has an addressee, a default and a decider

My last comment closed on:

"The three charters (#225, #128, #296) are carried by #163, while the droid model they are written against (#291) is carried by #333. Two roadmap epics, one dependency between them. […] it is @danmt's call — it bears directly on Q1."

It was recorded on three surfaces and asked on none. Since 2026-08-04T12:03:51Z it is a canonical ruling ask on the roadmap: exhaustive options, a recommendation (A — #291 to 0.2.0), a blocked/continues statement, and a default keyed to #163's window-open. It is still unanswered at this write, and triage returns there on 2026-08-11.

So Q1's "one thing the pass created" should be followed there rather than re-raised here. One question, one surface — that is the whole reason this thread's own header exists.

2. The chain is one row longer, and it does not move this thread

#367 — 0.3.1, many operators — was minted 2026-08-05 and written onto the roadmap today. It sits after 0.3.0, so it adds no distance in front of #163: 0.2.0 is still nine windows from the one being cut now.

3. The three questions, re-checked rather than assumed

• Q1 — where the two brains live and what reads them. Open. #295 is open carrying epic alone; the three charters are all still closed and all still carry blocked — #128 2026-08-03T15:54:25Z, #225 15:54:47Z, #296 15:54:58Z, a close moving no queue label. Nothing has shipped against any of them, so no repository, path or injection point has been named by code either.
• Q2 — what "the plan" is as an artifact, and what a confirmation looks like on the board. Open, and the answer-from-what-exists reading is stronger than it was: the plan today is an epic tree with a gate chain and a by-hand release-init cycle, and that cycle has now been run through a full window rather than only declared.
• Q3 — does the leader merge, or prepare merges. Open, still @danmt's alone, still governed by "only humans merge" vendored from heavy-duty/ceremony. Its second sub-question is unchanged and re-verified at this write rather than quoted: gh api repos/heavy-duty/crew/rulesets returns [], branches/main/protection returns 404, and mergeStateStatus returns zero hits across the whole tree at f5bd61c. Discussion #269 is still unanswered.

4. The measurement my last comment closed on is void

It read "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." That census described the 0.1.2 working surface at its widest; the window is now at its cut.

Board at this write: 31 open — 19 epic, 6 post-merge, 3 blocked, 2 claimed, 1 ready (19+6+3+2+1 = 31), zero needs-triage, attention, stale and offsite, and two open PRs — #401 in draft at blocker:ci-red and #410 at state:needs-human. The blocker parse over every open blocked body: #406 → {#402, #403}, #408 → {#406}, #411 → {#408}. Union {#402, #403, #406, #408} — none of them this thread.

One needs-ruling does stand on this board, and it is worth naming rather than leaving to be found: it went on #400 at 2026-08-07T21:32:17Z, asking how much of the admitted set must land before the real-host drill round. It is the release cut's, not this thread's, and nothing in it touches the leader chair.

Outcome unchanged: ask, waiting on @danmt

Q1 is still the cheap one and still yields the first buildable issue on its own; Q3 is still the one triage will not pick at any rung. Nothing is waiting on this thread — no open issue's parsed blocker set names it, and the charters it discusses are closed, so no builder can reach the ambiguity.

And this ask gets the return date its siblings carry. No needs-ruling label is owed here — nothing on the board is held by this thread — so the ruling ladder, which runs from an episode's labeled event, has no clock and no rung fires. What applies is the 7-day nudge: absent real activity triage returns on 2026-08-14, the same discipline #317 holds for 2026-08-10 and #338 and #351 for 2026-08-11.

Triage, 2026-08-07.

[dan-claude-bot]

The 7-day return, two days late — the placement ask it hands to #338 is itself unanswered, and its own return was missed on the same run

Triage 2026-08-16 12:1xZ. This is the return my comment of 2026-08-07 21:42Z promised for 2026-08-14; it is two days overdue. Measured at this write rather than carried.

1. The question this thread handed off is still open, and the ambiguity behind it is intact

That comment recorded the placement question as "now a canonical ruling ask on the roadmap" — #338's 12:03Z ask of 2026-08-04, which epic owns #291. It has no reply. Eleven comments have posted on #338 since its last nudge of 2026-08-07 19:16Z, and not one of them mentions the ask — every one is a map or figure correction. Its own 7-day return, due 2026-08-11, was never written. It is served in this same tick.

The ambiguity is not stale, it is live — re-read from the two epics' bodies rather than from that ask:

• #291 is CLOSED (2026-08-03T15:54:55Z) and still carries blocked, because a close moves no label.
• Both #163 (0.2.0) and #333 (0.2.1) still name it in their bodies at this write. Neither has given it up, which is the whole of the question.

2. Nothing about this thread's own preconditions moved

The three charters remain closed and carried on #295, which is open, epic + scope:duty, with no queue label, and gated on #163 — open, epic + release, no queue label, window not opened. No builder can reach the ambiguity this thread describes, because no charter is claimable.

3. The board this ran against

26 open — 19 epic, 5 post-merge (#181, #217, #240, #359, #400), 2 blocked (#454, #457) — and 0 each of ready, claimed, needs-triage, needs-ruling, attention, stale and offsite. 0 open pull requests; main is at 394bdad, PR #453 of 2026-08-12, still the last merge. The shipped blockers.jq over both blocked bodies returns #454 → {327, 452} and #457 → {327, 454}; neither names this thread, and the promotion set is empty. The claimable queue is empty for an unrelated reason: 0.1.3 is at release-init step 1, and that window's issues are minted as one wave by your own instruction.

4. Why this is late

Four asks were due a 7-day return and none was written: this one and #269 on 2026-08-14, #351 and #338's #291 ask on 2026-08-11. All four are served in this tick; #317's falls tomorrow and is not yet owed. What triage did write in that window was map and figure corrections on #327 and #338 — the nudges were the thing that did not get written. Recorded rather than quietly re-dated.

Outcome unchanged: ask, waiting on @danmt

Q1 is still the cheap one and still yields the first buildable issue on its own; Q3 is still the one triage will not pick at any rung. No needs-ruling is owed and none is set — nothing on the board is held by this thread, so no rung of the ladder fires.

You are present and this is not sitting behind an absent human — your last write here is the #455 reply of 2026-08-14T21:03:42Z, and you were closing work in heavy-duty/incubator as recently as 2026-08-16T11:32:15Z. One word answers this, and one word parks it; if you park it, triage stops nudging until you unpark it. Absent either, triage returns on 2026-08-23.

Triage, 2026-08-16.

[dan-claude-bot]

The return, 9 days late — the preconditions are intact, and the board around them is unrecognisable

Triage 2026-09-01. This is the return my comment of 2026-08-16 promised for 2026-08-23; it is nine days overdue. Re-measured at main 70bd7d4, 178 commits past the head that comment ran against. Every comment on this page is still triage's.

1. The question this thread handed off is still open, and is now 28 days old

The placement ask this thread delegated — #338's 12:03Z ask of 2026-08-04, which epic owns #291 — still has no reply, and its own return of 2026-08-23 was missed too. It is served in this same tick.

The ambiguity behind it is live rather than stale, re-read from the two epics' bodies at this write: #291 is CLOSED and still carries blocked (a close moves no label), and both #163 (0.2.0) and #333 (0.2.1) still name it — seven references and three, counted. Neither has given it up.

2. This thread's own preconditions have not moved at all

• #295 — the governance-chairs epic carrying the three closed charters — is open, epic + scope:duty, no queue label, and still gated on 0.2.0 — the crew works for weeks, and the operator only rules and merges #163.
• #163 (0.2.0) is open, epic + release, no queue label, window not opened.

No builder can reach the ambiguity this thread describes, because no charter is claimable. Unchanged, and checked rather than carried.

3. What did move, and why it makes the standstill more visible rather than less

The board this thread was last measured against had zero claimable work for a structural reason — 0.1.3 was at release-init step 1. That reason is gone:

	2026-08-16	today
open issues	26	51
ready	0	10
claimed	0	2
blocked	2	20
open PRs	0	2

0.1.3's wave landed in the interval. So the last comment's "the claimable queue is empty for an unrelated reason" no longer applies — there are ten claimable issues today and builders are working two of them. The chairs are still unreachable, and now they are the only thing that is. Last time the standstill was indistinguishable from the board-wide one; today it is specific to this thread's dependency, which is a sharper statement of the same ask.

4. Nothing is held by this thread — re-measured

The shipped blockers.jq's own parse over all 20 open blocked bodies names neither this thread nor #295 nor #163. Board-wide: 0 needs-ruling, 0 attention, 0 needs-triage, 0 stale. No needs-ruling is owed and none is set, so no rung of the ruling ladder fires and triage does not pick — Q3 in particular is still the one triage will not pick at any rung.

5. Why this is nine days late, and the measurement taken instead of a fifth apology

Fourth consecutive recorded miss across this family — this thread, #269 and #338 due 2026-08-23, #317 due 2026-08-24 — found overdue and unhonoured on 08-27, 08-29 and 08-31 before today. All four are served in this tick.

The premise this page has asserted four times is the one I re-measured. @danmt has commented on eight crew issues since these returns fell due, most recently 2026-08-31T21:40:23Z; on zero of the fourteen open crew discussions; and the last @danmt reply on any crew discussion at all was 2026-08-19T19:17Z. The full measurement, including the closed-discussion control that keeps it from being overstated, is in #317's return of today.

It changes no outcome and licenses no pick. It is here because "you are present and this is not sitting behind an absent human" is true, has been written on this page repeatedly, and has not worked — which is information about triage's method rather than about you.

Outcome unchanged: ask, waiting on @danmt

Q1 is still the cheap one and still yields the first buildable issue on its own. Q3 is still the one triage will not pick at any rung.

One word answers this, and one word 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.