heavy-duty/ceremony

Fork 2

attention — a state-machine wake for comment-borne demands #83

New issue

Closed

opened 2026-07-23 17:20:05 +00:00 by dan-claude-bot · 7 comments

dan-claude-bot commented

2026-07-23 17:20:05 +00:00

(Migrated from github.com)

Minted from discussion #82 at the operator's direction (@danmt, 17:15Z: "write up the issues needed and an epic if you see fit"). The proposal is @claude-bot-andresmgsl's and is accepted as filed, with one correction of fact (D1 below) and the open details closed out here.

All line references pinned at 87f2432.

Context — the hole the board has

Every wake condition in this fleet keys on state: labels, review requests, draft status, verdicts, mergeability (FLEET.md L45-L65). Nothing watches prose. So a comment that carries a demand — a ruling, an authorization, a "your move" — reaches nobody until a human notices.

Bought with an incident, same day: #16's 16:49Z ruling authorized the 0.1.0 cut — the last open acceptance criterion on a claimed issue, with the claimant named in the first line — and sat unowned until the operator asked about it. The claimant's box answered every state signal that day sharply. Pickup finally ran on a manual bridge.

The obvious fix was built and rejected the same day on the operator's catch: polling notifications for reason: mention re-arms on every comment in a thread, so ordinary round traffic burns a full agent session per tick on nothing actionable. A mention answers "was I named?"; only the writer knows "am I needed?". That difference is the whole design: the demand must be declared, and declared in the state machine the loops already read.

The approach

One label, attention, hand-set by whoever needs an assignee's hands on a thread, removed by that assignee as the ack. Three deliverables in dependency order: the row (#84), the contract (#85), the wake (#86). No new machinery — no reconciler path sets, clears, reads or enforces it. The label's whole job is to be visible to a one-call poll and to a human scanning the board.

Decisions

Shared constraints. Children implement them; do not reopen them in a PR.

D1 — the row lives in core_label_rows(), not .github/labels.conf. The discussion asked for a labels.conf row; that file is per-repo — panel, triage actors, and the repo's own scope:* set (.github/labels.conf). A core label put there would exist in ceremony and in no other governed repo. The core taxonomy is the heredoc in labels-reconcile.sh L382-L401, which every consumer's bootstrap dispatch reads by reference. That is where a label that must exist everywhere goes.
D2 — attention|D93F0B|A demand is parked here for the assignee: pick up the thread, ack by removing this label, verbatim, as approved on the discussion. 88 characters, inside GitHub's 100-character description limit.
D3 — the D93F0B collision with state:addressing is deliberate. Both mean the assignee owes the next move, which is what the color says in this taxonomy. They cannot appear on the same item: state:* is PR-only and machine-owned, attention is issue-only and hand-set (D4). Colors are family membership here, not identity.
D4 — issue-only. PR demands already have a state machine and a review-request channel; a second wake on PRs would duplicate state:addressing and blocker:* and disagree with them eventually.
D5 — additive, and inert to every sweep. It composes with ready/claimed/blocked and never substitutes for one; the queue invariant already ignores unknown labels by construction (queue_decision L70-L83). It grants no clock exemption — unlike offsite and needs-ruling (claim_clock_exempt L104-L117), which record legitimate silence. An attention nobody answered is the opposite of legitimate silence: it is exactly the claim the 48h reclaim should take.
D6 — it requires an assignee. A demand parked for nobody is a note. Doctrine states it; nothing enforces it (D8) — an unassigned issue carrying the flag is a board bug anyone may fix.
D7 — the ack is the removal, and it comes first. The pickup session's opening act is a short comment plus removing the label. The removal re-arms the wake for the next demand and makes an unanswered demand visible evidence on the board. A session that dies before acking is relaunched by the next tick — idempotent by construction, since the flag is still up.
D8 — no machinery this round. Nothing in actions/ changes. State that in the docs so nobody later builds enforcement believing it was specified here and left out.
D9 — the three-way distinction, stated once and repeated nowhere else: attention = an assignee owes a move on this thread; needs-ruling = a human owes a decision, with the escalation contract and ladder; a bare @-mention = an FYI that demands nothing. A demand that is also a human decision carries needs-ruling, not both.

Children

#84 — actions/labels-reconcile + LABELS.md — the row and its taxonomy entry (blocked on nothing) — shipped 2026-07-23 in #87 (merged 17:45Z); the attention row is in core_label_rows() (D1) and LABELS.md carries its taxonomy entry.
#85 — LABELS.md / TRIAGE.md / BUILDER.md — the contract — shipped 2026-07-23 in #88 (merged 18:12Z); LABELS.md carries the attention doctrine (the three-way distinction of D9), TRIAGE.md sets the flag when a directive delivers the assignee's next move, and BUILDER.md's pickup rule makes removing the label the ack (D7).
#86 — FLEET.md — the assignee's wake — shipped 2026-07-23 in #89 (merged 18:33Z); FLEET.md's wake list now reads an open assigned issue carrying attention via a one-call gh api poll, and the pickup acks by removing the label.

Operator items — not builder work, tracked here so they are not lost

Done 2026-07-24 15:03Z — the operator ran the labels workflow_dispatch on heavy-duty/ceremony (run concluded success 15:03:25Z) and the attention row is live, matching D2 byte-for-byte in name, colour and description. ~~Run the labels workflow's workflow_dispatch on heavy-duty/ceremony so the label is actually created~~ (bootstrap is dispatch-only — labels.yml L10 — and the agents team holds triage, which cannot dispatch). Same dispatch in each governed repo at its next ceremony pin bump.
Done 2026-07-24 15:17Z — the box-side duty.sh wake landed as heavy-duty/crew#13 (merged 15:17:39Z) and the operator confirmed the agents were notified (15:23Z). The wake is off paper.

Status — triage 2026-07-23: every build child is shipped (#84 in #87, #85 in #88, #86 in #89). What remains is not builder work — the two operator buttons above, each an operator/observation trailer with the same "wake exists on paper until dispatched" shape as #1's standing items. Triage leaves this epic open as their board home rather than closing it while the label it defines has not yet been bootstrapped anywhere.

Closed — triage 2026-07-24: both operator items are done and verified (the label live on this repo, the wake wired in heavy-duty/crew#13). The one thread that outlives this epic — attention reaching the four consumers — was always scoped to "each governed repo at its next ceremony pin bump" and now has a live home: discussion #102 tracks the gap, and the 0.3.0 pin bumps that carry the dispatch are on the board's critical path (#157/#160). Nothing left here is anyone's work.

Why this is an epic and not one issue

Three files, three audiences, one dependency chain: the row is machinery-adjacent config with tests, the contract is vendored doctrine that governs every consumer repo (LABELS.md, TRIAGE.md and BUILDER.md are all in docs/VENDORED.txt), and the wake is this fleet's own descriptive snapshot, explicitly not doctrine and never mirrored. Merging them would put a box-script spec inside a file that ships to every consumer.

Minted from discussion [#82](https://github.com/heavy-duty/ceremony/discussions/82) at the operator's direction ([@danmt, 17:15Z](https://github.com/heavy-duty/ceremony/discussions/82#discussioncomment-14520396): *"write up the issues needed and an epic if you see fit"*). The proposal is @claude-bot-andresmgsl's and is accepted as filed, with one correction of fact (D1 below) and the open details closed out here. All line references pinned at [`87f2432`](https://github.com/heavy-duty/ceremony/tree/87f243299d17b1a3831c3345fa11fa638eb21b1d). ## Context — the hole the board has Every wake condition in this fleet keys on **state**: labels, review requests, draft status, verdicts, mergeability ([FLEET.md L45-L65](https://github.com/heavy-duty/ceremony/blob/87f243299d17b1a3831c3345fa11fa638eb21b1d/FLEET.md#L45-L65)). Nothing watches **prose**. So a comment that carries a demand — a ruling, an authorization, a "your move" — reaches nobody until a human notices. Bought with an incident, same day: [#16's 16:49Z ruling](https://github.com/heavy-duty/ceremony/issues/16#issuecomment-5061051198) authorized the `0.1.0` cut — the last open acceptance criterion on a `claimed` issue, with the claimant named in the first line — and sat unowned until the operator asked about it. The claimant's box answered every *state* signal that day sharply. Pickup finally ran on a manual bridge. The obvious fix was built and rejected the same day on the operator's catch: polling notifications for `reason: mention` re-arms on **every** comment in a thread, so ordinary round traffic burns a full agent session per tick on nothing actionable. A mention answers *"was I named?"*; only the writer knows *"am I needed?"*. That difference is the whole design: the demand must be **declared**, and declared in the state machine the loops already read. ## The approach One label, `attention`, hand-set by whoever needs an assignee's hands on a thread, removed by that assignee as the ack. Three deliverables in dependency order: the row (#84), the contract (#85), the wake (#86). No new machinery — no reconciler path sets, clears, reads or enforces it. The label's whole job is to be visible to a one-call poll and to a human scanning the board. ## Decisions Shared constraints. Children implement them; do not reopen them in a PR. - **D1 — the row lives in `core_label_rows()`, not `.github/labels.conf`.** The discussion asked for a `labels.conf` row; that file is *per-repo* — panel, triage actors, and the repo's own `scope:*` set ([`.github/labels.conf`](https://github.com/heavy-duty/ceremony/blob/87f243299d17b1a3831c3345fa11fa638eb21b1d/.github/labels.conf)). A core label put there would exist in ceremony and in no other governed repo. The core taxonomy is the heredoc in [`labels-reconcile.sh` L382-L401](https://github.com/heavy-duty/ceremony/blob/87f243299d17b1a3831c3345fa11fa638eb21b1d/actions/labels-reconcile/labels-reconcile.sh#L382-L401), which every consumer's bootstrap dispatch reads by reference. That is where a label that must exist everywhere goes. - **D2 — `attention|D93F0B|A demand is parked here for the assignee: pick up the thread, ack by removing this label`,** verbatim, as approved on the discussion. 88 characters, inside GitHub's 100-character description limit. - **D3 — the `D93F0B` collision with `state:addressing` is deliberate.** Both mean *the assignee owes the next move*, which is what the color says in this taxonomy. They cannot appear on the same item: `state:*` is PR-only and machine-owned, `attention` is issue-only and hand-set (D4). Colors are family membership here, not identity. - **D4 — issue-only.** PR demands already have a state machine and a review-request channel; a second wake on PRs would duplicate `state:addressing` and `blocker:*` and disagree with them eventually. - **D5 — additive, and inert to every sweep.** It composes with `ready`/`claimed`/`blocked` and never substitutes for one; the queue invariant already ignores unknown labels by construction ([`queue_decision` L70-L83](https://github.com/heavy-duty/ceremony/blob/87f243299d17b1a3831c3345fa11fa638eb21b1d/actions/issueflow-reconcile/issueflow-reconcile.sh#L70-L83)). It grants **no clock exemption** — unlike `offsite` and `needs-ruling` ([`claim_clock_exempt` L104-L117](https://github.com/heavy-duty/ceremony/blob/87f243299d17b1a3831c3345fa11fa638eb21b1d/actions/issueflow-reconcile/issueflow-reconcile.sh#L104-L117)), which record legitimate silence. An `attention` nobody answered is the opposite of legitimate silence: it is exactly the claim the 48h reclaim should take. - **D6 — it requires an assignee.** A demand parked for nobody is a note. Doctrine states it; nothing enforces it (D8) — an unassigned issue carrying the flag is a board bug anyone may fix. - **D7 — the ack is the removal, and it comes first.** The pickup session's opening act is a short comment plus removing the label. The removal re-arms the wake for the next demand and makes an unanswered demand visible evidence on the board. A session that dies before acking is relaunched by the next tick — idempotent by construction, since the flag is still up. - **D8 — no machinery this round.** Nothing in `actions/` changes. State that in the docs so nobody later builds enforcement believing it was specified here and left out. - **D9 — the three-way distinction, stated once and repeated nowhere else:** `attention` = an **assignee** owes a move on this thread; `needs-ruling` = a **human** owes a decision, with the escalation contract and ladder; a bare `@`-mention = an FYI that demands nothing. A demand that is also a human decision carries `needs-ruling`, not both. ## Children - [x] #84 — `actions/labels-reconcile` + `LABELS.md` — the row and its taxonomy entry (blocked on nothing) — **shipped 2026-07-23** in [#87](https://github.com/heavy-duty/ceremony/pull/87) (merged 17:45Z); the `attention` row is in `core_label_rows()` (D1) and LABELS.md carries its taxonomy entry. - [x] #85 — `LABELS.md` / `TRIAGE.md` / `BUILDER.md` — the contract — **shipped 2026-07-23** in [#88](https://github.com/heavy-duty/ceremony/pull/88) (merged 18:12Z); LABELS.md carries the `attention` doctrine (the three-way distinction of D9), TRIAGE.md sets the flag when a directive delivers the assignee's next move, and BUILDER.md's pickup rule makes removing the label the ack (D7). - [x] #86 — `FLEET.md` — the assignee's wake — **shipped 2026-07-23** in [#89](https://github.com/heavy-duty/ceremony/pull/89) (merged 18:33Z); FLEET.md's wake list now reads an open assigned issue carrying `attention` via a one-call `gh api` poll, and the pickup acks by removing the label. ## Operator items — not builder work, tracked here so they are not lost - [x] **Done 2026-07-24 15:03Z** — the operator ran the `labels` `workflow_dispatch` on `heavy-duty/ceremony` (run concluded success 15:03:25Z) and the `attention` row is live, matching D2 byte-for-byte in name, colour and description. ~~Run the `labels` workflow's `workflow_dispatch` on `heavy-duty/ceremony` so the label is actually created~~ (bootstrap is dispatch-only — [`labels.yml` L10](https://github.com/heavy-duty/ceremony/blob/87f243299d17b1a3831c3345fa11fa638eb21b1d/.github/workflows/self-labels.yml#L10) — and the agents team holds `triage`, which cannot dispatch). Same dispatch in each governed repo at its next ceremony pin bump. - [x] **Done 2026-07-24 15:17Z** — the box-side `duty.sh` wake landed as [heavy-duty/crew#13](https://github.com/heavy-duty/crew/pull/13) (merged 15:17:39Z) and the operator confirmed the agents were notified ([15:23Z](https://github.com/heavy-duty/ceremony/issues/83#issuecomment-5071488584)). The wake is off paper. Status — triage 2026-07-23: **every build child is shipped** (#84 in #87, #85 in #88, #86 in #89). What remains is not builder work — the two operator buttons above, each an operator/observation trailer with the same "wake exists on paper until dispatched" shape as #1's standing items. Triage leaves this epic open as their board home rather than closing it while the label it defines has not yet been bootstrapped anywhere. **Closed — triage 2026-07-24:** both operator items are done and verified (the label live on this repo, the wake wired in [heavy-duty/crew#13](https://github.com/heavy-duty/crew/pull/13)). The one thread that outlives this epic — `attention` reaching the four consumers — was always scoped to "each governed repo at its next ceremony pin bump" and now has a live home: discussion #102 tracks the gap, and the `0.3.0` pin bumps that carry the dispatch are on the board's critical path (#157/#160). Nothing left here is anyone's work. ## Why this is an epic and not one issue Three files, three audiences, one dependency chain: the row is machinery-adjacent config with tests, the contract is **vendored** doctrine that governs every consumer repo (`LABELS.md`, `TRIAGE.md` and `BUILDER.md` are all in [`docs/VENDORED.txt`](https://github.com/heavy-duty/ceremony/blob/87f243299d17b1a3831c3345fa11fa638eb21b1d/docs/VENDORED.txt)), and the wake is this fleet's own descriptive snapshot, explicitly **not** doctrine and never mirrored. Merging them would put a box-script spec inside a file that ships to every consumer.

dan-claude-bot commented

2026-07-24 00:28:08 +00:00

(Migrated from github.com)

The dispatch item above has a question attached to it now: does the attention row ship at the family's next pin bump, or wait for this epic's machinery? It sits in discussion #102 (question 2), alongside the wider finding that attention, needs-ruling and offsite exist in no consumer and that nothing in the machinery can notice.

Triage leans ship-now — the row is already in the table on main, creating it is idempotent, and leaving it out buys a second round of the same bump when this epic lands. @danmt's call.

The dispatch item above has a question attached to it now: **does the `attention` row ship at the family's next pin bump, or wait for this epic's machinery?** It sits in [discussion #102](https://github.com/heavy-duty/ceremony/discussions/102) (question 2), alongside the wider finding that `attention`, `needs-ruling` and `offsite` exist in no consumer and that nothing in the machinery can notice. Triage leans ship-now — the row is already in the table on `main`, creating it is idempotent, and leaving it out buys a second round of the same bump when this epic lands. @danmt's call.

dan-claude-bot commented

2026-07-24 00:49:22 +00:00

(Migrated from github.com)

Operator item 1, verified — the dispatch creates exactly one label and changes nothing else.

Checked 2026-07-24 while working #102,
which found attention missing on all five repos. Two facts worth recording
here so the button can be pressed without re-deriving them:

Ceremony does not need a release for this. The self-consumption bypass
(labels.yml L73-L92)
runs ./actions/labels-reconcile from the default branch on this repo rather
than the CEREMONY_SELF_REF: "0.1.0" checkout, so a dispatch bootstraps from
main's table — which has carried the attention row since #87 merged. The
four consumers do need the release; that half is #102's.
Blast radius is one label. I diffed core_label_rows() on main against
ceremony's live label set row by row: attention is the only difference.
Every other core row matches on name, colour and description exactly, the
retired GitHub defaults are already gone (#93), and the scope:* rows come
from labels.conf and match. The upsert is gh label create --force, so the
matching rows are rewritten identically.

gh workflow run labels -R heavy-duty/ceremony

triage cannot dispatch a workflow, so this stays yours. Item 2 (the box-side
duty.sh wake) is unchanged and still on paper.

**Operator item 1, verified — the dispatch creates exactly one label and changes nothing else.** Checked 2026-07-24 while working [#102](https://github.com/heavy-duty/ceremony/discussions/102), which found `attention` missing on all five repos. Two facts worth recording here so the button can be pressed without re-deriving them: - **Ceremony does not need a release for this.** The self-consumption bypass ([labels.yml L73-L92](https://github.com/heavy-duty/ceremony/blob/5af1538463519577951bdd749f19dfc8f9643cb6/.github/workflows/labels.yml#L73-L92)) runs `./actions/labels-reconcile` from the default branch on this repo rather than the `CEREMONY_SELF_REF: "0.1.0"` checkout, so a dispatch bootstraps from `main`'s table — which has carried the `attention` row since #87 merged. The four consumers *do* need the release; that half is #102's. - **Blast radius is one label.** I diffed `core_label_rows()` on `main` against ceremony's live label set row by row: `attention` is the only difference. Every other core row matches on name, colour and description exactly, the retired GitHub defaults are already gone (#93), and the `scope:*` rows come from `labels.conf` and match. The upsert is `gh label create --force`, so the matching rows are rewritten identically. ```sh gh workflow run labels -R heavy-duty/ceremony ``` `triage` cannot dispatch a workflow, so this stays yours. Item 2 (the box-side `duty.sh` wake) is unchanged and still on paper.

dan-claude-bot commented

2026-07-24 11:23:00 +00:00

(Migrated from github.com)

Evidence for the first operator item, logged so it is not just a paper wake: the missing label bit a live thread today.

#117 10:35Z is a triage ruling that delivers the assignee’s next move in prose — the exact shape TRIAGE.md now says must carry attention (shipped in #85). It could not be set: gh label list on this repo still returns no attention row, and triage holds triage, which cannot create a label (404) or dispatch the labels workflow. The comment had to say "treat this comment as the demand" instead, and that thread is now closed, so the ask is buried there and lives here instead.

Nothing to build — #84 put the row in core_label_rows() yesterday. What is missing is one workflow_dispatch run of labels on heavy-duty/ceremony, @danmt. The #105 warning should be naming attention on every sweep now that it has landed, which is the second place this keeps surfacing until the button is pressed.

Evidence for the first operator item, logged so it is not just a paper wake: the missing label bit a live thread today. [#117 10:35Z](https://github.com/heavy-duty/ceremony/issues/117#issuecomment-5068870628) is a triage ruling that delivers the assignee’s next move in prose — the exact shape TRIAGE.md now says must carry `attention` (shipped in #85). It could not be set: `gh label list` on this repo still returns no `attention` row, and triage holds `triage`, which cannot create a label (404) or dispatch the `labels` workflow. The comment had to say "treat this comment as the demand" instead, and that thread is now closed, so the ask is buried there and lives here instead. Nothing to build — #84 put the row in `core_label_rows()` yesterday. What is missing is one `workflow_dispatch` run of `labels` on `heavy-duty/ceremony`, @danmt. The #105 warning should be naming `attention` on every sweep now that it has landed, which is the second place this keeps surfacing until the button is pressed.

dan-claude-bot commented

2026-07-24 12:23:14 +00:00

(Migrated from github.com)

Second evidence entry for the first operator item, alongside this morning's. Smaller than it first looks, and worth stating precisely, because this epic's operator item should be justified by what actually happened.

On #128 the builder's worklog carried a step no fleet identity can perform — DELETE /repos/… needs delete_repo, which no token here has. It retried and reported the same 403 at 11:46, 11:53, 11:56, 12:01, 12:06 and 12:13, holding the 0.2.0 release draft in state:building throughout.

Five of those six were not this epic's problem. They ran before triage had ruled; the builder was correctly stuck on a contract that named a step and never said who owned it — that gap is #135, and no wake would have shortened it.

The one that is this epic's shape is the sixth. The ruling landed at 12:09; the resume at 12:13 retried the dead call anyway, because resume continues from the worklog and there is no signal that says read the thread first. The builder picked the ruling up on its next pass and had the correction pushed by 12:16 — so prose did land, one wasted session and about six minutes later, on a release PR at the door.

That is D9's case in miniature: a demand that was neither a state change nor a human decision, addressed to an assignee with no flag to see it with. The cost here was one session; the #16 incident it was bought with was over an hour. attention still does not exist on this repo — POST /labels 404s on the triage credential — so the dispatch in the first operator item remains the whole fix. @danmt.

Second evidence entry for the first operator item, alongside [this morning's](https://github.com/heavy-duty/ceremony/issues/83#issuecomment-5069300244). Smaller than it first looks, and worth stating precisely, because this epic's operator item should be justified by what actually happened. On [#128](https://github.com/heavy-duty/ceremony/pull/128) the builder's worklog carried a step no fleet identity can perform — `DELETE /repos/…` needs `delete_repo`, which no token here has. It retried and reported the same 403 at 11:46, 11:53, 11:56, 12:01, 12:06 and 12:13, holding the 0.2.0 release draft in `state:building` throughout. **Five of those six were not this epic's problem.** They ran before triage had ruled; the builder was correctly stuck on a contract that named a step and never said who owned it — that gap is #135, and no wake would have shortened it. The one that is this epic's shape is the sixth. The ruling landed at [12:09](https://github.com/heavy-duty/ceremony/pull/128#issuecomment-5069686052); the resume at 12:13 retried the dead call anyway, because [resume continues from the worklog](https://github.com/heavy-duty/ceremony/blob/a602fd0/FLEET.md#L163-L169) and there is no signal that says *read the thread first*. The builder picked the ruling up on its next pass and had the correction pushed by 12:16 — so prose did land, one wasted session and about six minutes later, on a release PR at the door. That is D9's case in miniature: a demand that was neither a state change nor a human decision, addressed to an assignee with no flag to see it with. The cost here was one session; the #16 incident it was bought with was over an hour. `attention` still does not exist on this repo — `POST /labels` 404s on the triage credential — so the dispatch in the first operator item remains the whole fix. @danmt.

danmt commented

2026-07-24 15:23:23 +00:00

(Migrated from github.com)

i just notified all agents and added the label

danmt commented

2026-07-24 15:34:12 +00:00

(Migrated from github.com)

yo @dan-claude-bot anything missing to close this one?

dan-claude-bot commented

2026-07-24 15:45:28 +00:00

(Migrated from github.com)

Nothing is missing — closing.

Verified just now, not inferred from the comments:

Operator item 1: the labels workflow_dispatch ran on this repo at 15:03:25Z (success), and GET /repos/heavy-duty/ceremony/labels/attention returns the row matching D2 byte-for-byte — name, D93F0B, and the 88-character description exactly as approved. The #105 sweep warning stops naming attention from here.
Operator item 2: the box-side wake is real — heavy-duty/crew#13 merged 15:17:39Z, and your 15:23Z note confirms the agents picked it up. FLEET.md's wake list is no longer on paper.
Build children: #84/#85/#86 shipped yesterday in #87/#88/#89; nothing changed since.

The one thread that outlives this epic is the consumer half — attention still 404s on incubator, rig, crew and box — but that was always scoped to "each governed repo at its next ceremony pin bump," and it now has a live home instead of this open epic: discussion #102 tracks the gap, and the 0.3.0 cut minted today (#157, release #160) is the tag those bumps and dispatches ride. Body updated to match; both boxes ticked.

Nothing is missing — closing. Verified just now, not inferred from the comments: - **Operator item 1**: the `labels` `workflow_dispatch` ran on this repo at 15:03:25Z (success), and `GET /repos/heavy-duty/ceremony/labels/attention` returns the row matching D2 byte-for-byte — name, `D93F0B`, and the 88-character description exactly as approved. The #105 sweep warning stops naming `attention` from here. - **Operator item 2**: the box-side wake is real — [heavy-duty/crew#13](https://github.com/heavy-duty/crew/pull/13) merged 15:17:39Z, and your 15:23Z note confirms the agents picked it up. FLEET.md's wake list is no longer on paper. - **Build children**: #84/#85/#86 shipped yesterday in #87/#88/#89; nothing changed since. The one thread that outlives this epic is the consumer half — `attention` still 404s on incubator, rig, crew and box — but that was always scoped to "each governed repo at its next ceremony pin bump," and it now has a live home instead of this open epic: discussion #102 tracks the gap, and the `0.3.0` cut minted today (#157, release #160) is the tag those bumps and dispatches ride. Body updated to match; both boxes ticked.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/ceremony#83

No description provided.