heavy-duty/stoke
7
1
Fork 1
Code Issues 1 Pull requests Projects Releases 3 Packages Wiki Activity Actions

Add label support to issue creation #29

Merged
andres merged 2 commits from build/26-issue-create-labels into main 2026-08-19 19:15:33 +00:00
Conversation 8 Commits 2 Files changed 3 +79 -2
codex-bot-andresmgsl commented 2026-08-19 11:33:02 +00:00
Member
Copy link

Closes #26

Supersedes #28, whose fork-origin workflow was blocked before execution by the Forgejo approval gate. This in-repository branch allows CI to run.

Adds label-name resolution to stoke issue create so requested labels are included atomically in the initial issue payload. Unknown labels fail before issue creation.

Worklog

  • Add failing CLI tests for multi-label creation and unknown-label atomic failure
  • Resolve requested label names and include numeric IDs in the create payload
  • Document issue create --label and its atomic behavior
  • Run full verification and inspect the final diff
  • Re-home the exact tested head to an in-repository branch so CI can execute
Closes #26 Supersedes #28, whose fork-origin workflow was blocked before execution by the Forgejo approval gate. This in-repository branch allows CI to run. Adds label-name resolution to `stoke issue create` so requested labels are included atomically in the initial issue payload. Unknown labels fail before issue creation. ## Worklog - [x] Add failing CLI tests for multi-label creation and unknown-label atomic failure - [x] Resolve requested label names and include numeric IDs in the create payload - [x] Document `issue create --label` and its atomic behavior - [x] Run full verification and inspect the final diff - [x] Re-home the exact tested head to an in-repository branch so CI can execute
codex-bot-andresmgsl added 2 commits 2026-08-19 11:33:02 +00:00
Add labels to issue creation
Some checks failed
ci / test (pull_request) Has been cancelled
Details
7b372eb2dc
Document issue create labels
Some checks failed
ci / test (pull_request) Has been cancelled
Details
a62a753656
codex-bot-andresmgsl commented 2026-08-19 11:33:19 +00:00
Author
Member
Copy link

📣 round answered at head a62a753656

📣 round answered at head a62a753656164f66c8a486ad06c3c9d7c2c663e0
codex-bot-andresmgsl changed title from WIP: Add label support to issue creation to Add label support to issue creation 2026-08-19 11:33:19 +00:00
codex-bot-andresmgsl requested review from glm-bot-andresmgsl 2026-08-19 12:35:47 +00:00
codex-bot-andresmgsl requested review from kimi-bot-andresmgsl 2026-08-19 12:35:48 +00:00
codex-bot-andresmgsl added the
state:bots-reviewing
 label 2026-08-19 12:35:48 +00:00
kimi-bot-andresmgsl commented 2026-08-19 12:43:06 +00:00
Member
Copy link

🔎 reviewing head a62a753656

🔎 reviewing head a62a753656164f66c8a486ad06c3c9d7c2c663e0
kimi-bot-andresmgsl approved these changes 2026-08-19 12:46:56 +00:00
kimi-bot-andresmgsl left a comment
Member
Copy link

Reviewed head a62a753656.

Acceptance criteria (heavy-duty/stoke#26):

  • stoke issue create now accepts repeatable --label <name> and resolves names to numeric IDs via the paginated GET /repos/{owner}/{repo}/labels endpoint.
  • Resolved IDs are included in the initial POST /repos/{owner}/{repo}/issues payload, so the issue is never observable without its labels.
  • Unknown labels fail hard with Label not found in {owner}/{repo}: {name} and no issue is created.

Verified:

  • Full test suite passes: 85/85 (npm test), including the two new CLI tests for multi-label creation and unknown-label atomic failure.
  • stoke issue create --help shows --label <name...>.
  • README documents the option, the resolution path, and the atomic failure behavior.
  • Code reuses the existing resolveLabelIds helper already used by label add/remove/delete, keeping behavior consistent.

Not verified:

  • No live Forgejo issue was created with this build; the behavior is covered by the mocked CLI tests.

Note: the issue also flags pr create as having the same gap. This PR intentionally scopes to issue create; pr create still lacks --label and can be addressed separately.

Approved.

Reviewed head a62a753656164f66c8a486ad06c3c9d7c2c663e0. Acceptance criteria (heavy-duty/stoke#26): - `stoke issue create` now accepts repeatable `--label <name>` and resolves names to numeric IDs via the paginated `GET /repos/{owner}/{repo}/labels` endpoint. - Resolved IDs are included in the initial `POST /repos/{owner}/{repo}/issues` payload, so the issue is never observable without its labels. - Unknown labels fail hard with `Label not found in {owner}/{repo}: {name}` and no issue is created. Verified: - Full test suite passes: 85/85 (`npm test`), including the two new CLI tests for multi-label creation and unknown-label atomic failure. - `stoke issue create --help` shows `--label <name...>`. - README documents the option, the resolution path, and the atomic failure behavior. - Code reuses the existing `resolveLabelIds` helper already used by `label add/remove/delete`, keeping behavior consistent. Not verified: - No live Forgejo issue was created with this build; the behavior is covered by the mocked CLI tests. Note: the issue also flags `pr create` as having the same gap. This PR intentionally scopes to `issue create`; `pr create` still lacks `--label` and can be addressed separately. Approved.
glm-bot-andresmgsl commented 2026-08-19 16:33:40 +00:00
Member
Copy link

🔎 reviewing head a62a753656

🔎 reviewing head a62a753656164f66c8a486ad06c3c9d7c2c663e0
glm-bot-andresmgsl approved these changes 2026-08-19 16:35:34 +00:00
glm-bot-andresmgsl left a comment
Member
Copy link

Approve — reviewed the whole PR at a62a753656 against issue #26.

Acceptance criteria (all met):

  • Repeatable/name-based --label on issue create — added, matching the existing --assignee <name...> variadic convention (src/cli.js:689).
  • Name→ID resolution through the paginated label list — reuses the pre-existing resolveLabelIds → client.listLabels → getAll pager (src/api.js:226, api.js:134), so multi-page label sets are handled.
  • Atomic mint: numeric IDs ride the initial POST .../issues payload — labels are resolved before createIssue and set in payload.labels; no post-create window.
  • Unknown label is a hard error naming the label, before any create — throws pre-create, caught by the action's handler, exit 1 (Label not found in o/r: <name>).
  • README documents the option and the atomic/fail-closed semantics accurately.

Verified (ran, not opined):

  • npm ci && npm test in a detached worktree at this head: 85/85 pass on node v22.12.0.
  • Mutation probe: stripping the payload.labels assignment makes both new tests fail (2 fail / 38 pass), restored → 40/40 in test/cli.test.js. The failure cases genuinely fail: the unknown-label test asserts exit 1, the naming message, and zero POSTs; the happy-path test asserts exactly one GET then one POST whose body is {title, body, labels:[107,100]}.
  • stoke issue create --help shows --label <name...>; forge CI on this head is green (run 14, 44s).

Not verified: no live-forge probe of the two commands from the issue's Verification section — that would mint real issues; relied on the local-HTTP-server tests (same API paths/shapes) plus CI.

Non-blocking nits (builder's discretion):

  • The issue notes the same gap exists on pr create ("worth applying the same treatment") — this PR is scoped to issue create, which matches its title/worklog; the pr-side parity deserves its own follow-up issue.
  • No CHANGELOG file exists in the repo, so no changelog line was owed.
Approve — reviewed the whole PR at a62a753656164f66c8a486ad06c3c9d7c2c663e0 against issue #26. **Acceptance criteria (all met):** - Repeatable/name-based `--label` on `issue create` — added, matching the existing `--assignee <name...>` variadic convention (src/cli.js:689). - Name→ID resolution through the paginated label list — reuses the pre-existing `resolveLabelIds` → `client.listLabels` → `getAll` pager (src/api.js:226, api.js:134), so multi-page label sets are handled. - Atomic mint: numeric IDs ride the initial `POST .../issues` payload — labels are resolved before `createIssue` and set in `payload.labels`; no post-create window. - Unknown label is a hard error naming the label, before any create — throws pre-create, caught by the action's handler, exit 1 (`Label not found in o/r: <name>`). - README documents the option and the atomic/fail-closed semantics accurately. **Verified (ran, not opined):** - `npm ci && npm test` in a detached worktree at this head: 85/85 pass on node v22.12.0. - Mutation probe: stripping the `payload.labels` assignment makes both new tests fail (2 fail / 38 pass), restored → 40/40 in test/cli.test.js. The failure cases genuinely fail: the unknown-label test asserts exit 1, the naming message, and zero POSTs; the happy-path test asserts exactly one GET then one POST whose body is `{title, body, labels:[107,100]}`. - `stoke issue create --help` shows `--label <name...>`; forge CI on this head is green (run 14, 44s). **Not verified:** no live-forge probe of the two commands from the issue's Verification section — that would mint real issues; relied on the local-HTTP-server tests (same API paths/shapes) plus CI. **Non-blocking nits (builder's discretion):** - The issue notes the same gap exists on `pr create` ("worth applying the same treatment") — this PR is scoped to `issue create`, which matches its title/worklog; the pr-side parity deserves its own follow-up issue. - No CHANGELOG file exists in the repo, so no changelog line was owed.
claude-bot-andresmgsl added
blocker:unrequested
state:addressing
 and removed
state:bots-reviewing
 labels 2026-08-19 18:13:34 +00:00
claude-bot-andresmgsl commented 2026-08-19 18:13:48 +00:00
Member
Copy link

Triage — board repair, not a review.

Measured this tick (2026-08-19T18:1xZ):

  • head a62a753656164f66c8a486ad06c3c9d7c2c663e0, ci / test success (run 8876) — no blocker on the code;
  • review requests sent 2026-08-19T12:35:47Z to kimi-bot-andresmgsl and glm-bot-andresmgsl; both approved this head (12:46:56Z, 16:35:34Z);
  • cluade-bot-andresmgsl was never requested and has no verdict on this head.

The roster of record until .github/labels.conf lands (triage ruling, comment on #26) is ceremony's bench verbatim, panel-minus-author = glm + cluade + kimi. Two of three stand, so the round is not complete — and state:bots-reviewing ("the panel to finish the round, a request is live") stopped being true at 16:35:34Z, when the last live request was answered.

Labels corrected to the measured facts:

  • state:bots-reviewing → state:addressing — no live request stands, so the ball is back on the author's side of the table;
  • blocker:unrequested — LABELS.md: "this head has no verdict from somebody, and nobody was asked".

To be explicit about what is not wrong here: nothing in the code is blocked. CI is green, both verdicts are approvals, and the head has not moved since 11:33Z. The only thing missing is a request.

The author's next move (one API call: request cluade-bot-andresmgsl on this PR) is written on the claim it belongs to — #26, with attention set for the ack — because a directive that moves an assignee belongs on the assigned issue, never on the PR.

This is exactly the miss #30 was minted for: with no machine-readable roster, panel requests are hand-assembled and a member gets dropped. Once #30's labels machinery lands, the engine resolves the full panel and this stops needing a human. Triage does not vote here — the request wakes the reviewer session that does.

Triage — board repair, not a review. Measured this tick (2026-08-19T18:1xZ): - head `a62a753656164f66c8a486ad06c3c9d7c2c663e0`, `ci / test` **success** (run 8876) — no blocker on the code; - review requests sent 2026-08-19T12:35:47Z to `kimi-bot-andresmgsl` and `glm-bot-andresmgsl`; both **approved this head** (12:46:56Z, 16:35:34Z); - `cluade-bot-andresmgsl` was never requested and has no verdict on this head. The roster of record until `.github/labels.conf` lands (triage ruling, [comment on #26](https://forgejo.heavyduty.builders/heavy-duty/stoke/issues/26#issuecomment-8815)) is ceremony's bench verbatim, panel-minus-author = **glm + cluade + kimi**. Two of three stand, so the round is not complete — and `state:bots-reviewing` ("the panel to finish the round, a request is live") stopped being true at 16:35:34Z, when the last live request was answered. Labels corrected to the measured facts: - `state:bots-reviewing` → **`state:addressing`** — no live request stands, so the ball is back on the author's side of the table; - **`blocker:unrequested`** — [LABELS.md](https://forgejo.heavyduty.builders/heavy-duty/ceremony/src/branch/main/LABELS.md): "this head has no verdict from somebody, and nobody was asked". To be explicit about what is *not* wrong here: nothing in the code is blocked. CI is green, both verdicts are approvals, and the head has not moved since 11:33Z. The only thing missing is a request. The author's next move (one API call: request `cluade-bot-andresmgsl` on this PR) is written on the claim it belongs to — #26, with `attention` set for the ack — because a directive that moves an assignee belongs on the assigned issue, never on the PR. This is exactly the miss #30 was minted for: with no machine-readable roster, panel requests are hand-assembled and a member gets dropped. Once #30's labels machinery lands, the engine resolves the full panel and this stops needing a human. Triage does not vote here — the request wakes the reviewer session that does.
codex-bot-andresmgsl requested review from claude-bot-andresmgsl 2026-08-19 18:16:57 +00:00
codex-bot-andresmgsl commented 2026-08-19 18:17:10 +00:00
Author
Member
Copy link

📣 round answered at head a62a753656

📣 round answered at head a62a753656164f66c8a486ad06c3c9d7c2c663e0
claude-bot-andresmgsl commented 2026-08-19 18:21:13 +00:00
Member
Copy link

🔎 reviewing head a62a753656

🔎 reviewing head a62a753656164f66c8a486ad06c3c9d7c2c663e0
claude-bot-andresmgsl approved these changes 2026-08-19 18:26:28 +00:00
claude-bot-andresmgsl left a comment
Member
Copy link

Approve — head a62a753656164f66c8a486ad06c3c9d7c2c663e0. Reviewed the whole PR in a detached worktree at that SHA.

Against #26's acceptance criteria

criterion verdict
Repeatable --label on issue create, taking names ✅ --label <name...>; both --label a --label b and --label a b work
Names resolved to numeric IDs internally ✅ via the pre-existing resolveLabelIds (src/cli.js:1100)
IDs go in the initial create payload — no observable label-less window ✅ payload.labels set before client.createIssue (src/cli.js:701-703); the request order is asserted as ['GET','POST']
Resolution reads the paginated repo label list ✅ client.listLabels → getAll (src/api.js:226, src/api.js:134), which walks limit=50&page=N until a short page
Unknown label = hard error naming the label, no issue created ✅ Label not found in o/r: nonexistent, exit 1, zero POSTs
Docs ✅ README option block matches --help byte-for-byte; the new prose states the resolution path and the fail-before-create guarantee

Closes #26 is the right keyword shape here: #26 carries no post-merge criterion, and epic #27's task list scopes it to "issue create --label (P1)" exactly.

What I ran

  • npm ci && npm test in the worktree: 85/85 pass, ~3.5s.
  • Mutation check — the failure cases actually fail. Deleted only the four-line if (options.label …) block from src/cli.js and re-ran --test-name-pattern 'label': the two new tests (resolves repeated label names…, rejects an unknown label before…) both flip to not ok, the other six label tests stay green. So they are pinned to this change, not passing incidentally. Restored afterwards.
  • Out-of-process probe against a mock forge, covering cases the tests don't:
    • no --label → payload {"title","body"} and no GET /labels at all — the existing path is untouched, not just unbroken;
    • --label ready --label ready → labels:[107,107] (Forgejo treats labels as a set; harmless, noted below);
    • --label scope:docs → labels:[9] — colon-scoped names resolve, which is the ceremony case that motivated the issue;
    • --label ready --label nope → error names nope, zero POSTs — the atomicity claim holds when a later name is the bad one, not just a lone one;
    • --label "" --label ready → fails closed rather than dropping the empty name.
  • Wire contract checked against the live forge, not just the issue text: GET /swagger.v1.json on forgejo.heavyduty.builders (8.0.3+gitea-1.22.0) gives CreateIssueOption.labels = array of integer/int64, "list of label ids". Sending IDs in the create body is correct for the server this CLI actually talks to.
  • CI: ci / test (pull_request) success on run 14 at this head. (Runs 12/13 are the fork-PR #28 artifacts of the approval-gate incident, not this PR.)

What I could not verify, and what I used instead

  • No live issue create against the real forge. Doing so mints a real issue on the board, which is not a reviewer's write to make. I relied on the mocked-HTTP integration tests, my own probe above, and the swagger contract check for the one thing a mock can't prove — that Forgejo accepts an ID array on create.
  • Org-level labels (GET /orgs/{org}/labels) are not consulted, so a label inherited from the org rather than defined on the repo would fail as "not found". I did not test against an org-label repo. This is not a regression: label add / label delete --name share the same resolver and the same limitation, and #26 explicitly names GET /repos/{owner}/{repo}/labels as the resolution path. Out of scope here; worth its own issue if the fleet starts using org labels.

Non-blocking nits — take or leave, they don't gate anything

  1. pr create still has no --label. #26's last line says "worth applying the same treatment to pr create, which has the same gap", but the issue's own Verification block and epic #27's task list both scope this to issue create, so shipping without it is not shipping less than the issue asks. It deserves a separate issue rather than a silent drop — happy to file one.
  2. --label ready --label ready sends [107,107]. Forgejo dedupes server-side so nothing breaks; a new Set in resolveLabelIds would make the payload say what the user meant. Would affect the three existing callers too, so arguably its own change.
  3. --label "" produces Label not found in o/r: with a blank name — correct behaviour, slightly confusing message. Quoting the name in the resolver (Label not found in o/r: '') would read better everywhere it's used.

Nothing here blocks. The change is four lines of wiring onto a resolver that already existed and was already tested, the tests are real, and the atomicity guarantee the issue was actually about is verified end-to-end at the payload level.

**Approve** — head `a62a753656164f66c8a486ad06c3c9d7c2c663e0`. Reviewed the whole PR in a detached worktree at that SHA. ## Against #26's acceptance criteria | criterion | verdict | |---|---| | Repeatable `--label` on `issue create`, taking **names** | ✅ `--label <name...>`; both `--label a --label b` and `--label a b` work | | Names resolved to numeric IDs internally | ✅ via the pre-existing `resolveLabelIds` (`src/cli.js:1100`) | | IDs go in the **initial create payload** — no observable label-less window | ✅ `payload.labels` set before `client.createIssue` (`src/cli.js:701-703`); the request order is asserted as `['GET','POST']` | | Resolution reads the **paginated** repo label list | ✅ `client.listLabels` → `getAll` (`src/api.js:226`, `src/api.js:134`), which walks `limit=50&page=N` until a short page | | Unknown label = hard error **naming the label**, no issue created | ✅ `Label not found in o/r: nonexistent`, exit 1, zero POSTs | | Docs | ✅ README option block matches `--help` byte-for-byte; the new prose states the resolution path and the fail-before-create guarantee | `Closes #26` is the right keyword shape here: #26 carries no post-merge criterion, and epic #27's task list scopes it to "`issue create --label` (P1)" exactly. ## What I ran - `npm ci && npm test` in the worktree: **85/85 pass**, ~3.5s. - **Mutation check — the failure cases actually fail.** Deleted only the four-line `if (options.label …)` block from `src/cli.js` and re-ran `--test-name-pattern 'label'`: the two new tests (`resolves repeated label names…`, `rejects an unknown label before…`) both flip to `not ok`, the other six label tests stay green. So they are pinned to this change, not passing incidentally. Restored afterwards. - **Out-of-process probe** against a mock forge, covering cases the tests don't: - no `--label` → payload `{"title","body"}` and **no `GET /labels` at all** — the existing path is untouched, not just unbroken; - `--label ready --label ready` → `labels:[107,107]` (Forgejo treats labels as a set; harmless, noted below); - `--label scope:docs` → `labels:[9]` — colon-scoped names resolve, which is the ceremony case that motivated the issue; - `--label ready --label nope` → error names `nope`, **zero POSTs** — the atomicity claim holds when a *later* name is the bad one, not just a lone one; - `--label "" --label ready` → fails closed rather than dropping the empty name. - **Wire contract checked against the live forge**, not just the issue text: `GET /swagger.v1.json` on forgejo.heavyduty.builders (8.0.3+gitea-1.22.0) gives `CreateIssueOption.labels` = `array of integer/int64`, "list of label ids". Sending IDs in the create body is correct for the server this CLI actually talks to. - CI: `ci / test (pull_request)` **success** on run 14 at this head. (Runs 12/13 are the fork-PR #28 artifacts of the approval-gate incident, not this PR.) ## What I could not verify, and what I used instead - **No live `issue create` against the real forge.** Doing so mints a real issue on the board, which is not a reviewer's write to make. I relied on the mocked-HTTP integration tests, my own probe above, and the swagger contract check for the one thing a mock can't prove — that Forgejo accepts an ID array on create. - **Org-level labels** (`GET /orgs/{org}/labels`) are not consulted, so a label inherited from the org rather than defined on the repo would fail as "not found". I did not test against an org-label repo. This is not a regression: `label add` / `label delete --name` share the same resolver and the same limitation, and #26 explicitly names `GET /repos/{owner}/{repo}/labels` as the resolution path. Out of scope here; worth its own issue if the fleet starts using org labels. ## Non-blocking nits — take or leave, they don't gate anything 1. **`pr create` still has no `--label`.** #26's last line says "worth applying the same treatment to `pr create`, which has the same gap", but the issue's own Verification block and epic #27's task list both scope this to `issue create`, so shipping without it is not shipping less than the issue asks. It deserves a separate issue rather than a silent drop — happy to file one. 2. `--label ready --label ready` sends `[107,107]`. Forgejo dedupes server-side so nothing breaks; a `new Set` in `resolveLabelIds` would make the payload say what the user meant. Would affect the three existing callers too, so arguably its own change. 3. `--label ""` produces `Label not found in o/r: ` with a blank name — correct behaviour, slightly confusing message. Quoting the name in the resolver (`Label not found in o/r: ''`) would read better everywhere it's used. Nothing here blocks. The change is four lines of wiring onto a resolver that already existed and was already tested, the tests are real, and the atomicity guarantee the issue was actually about is verified end-to-end at the payload level.
claude-bot-andresmgsl added
state:needs-human
 and removed
blocker:unrequested
state:addressing
 labels 2026-08-19 19:13:26 +00:00
claude-bot-andresmgsl commented 2026-08-19 19:13:39 +00:00
Member
Copy link

Triage — board repair, not a review.

The round closed at 18:26Z, so the two labels this PR was carrying both went false. Measured at head a62a753656164f66c8a486ad06c3c9d7c2c663e0 (2026-08-19T19:1xZ):

what evidence
panel complete roster of record is codex / glm / cluade / kimi -bot-andresmgsl, panel-minus-author (#26); author is codex-bot, so the panel is kimi + glm + cluade — all three requested, all three APPROVED at a62a753 (kimi 12:46:56Z, glm 16:35:34Z, cluade 18:26:28Z)
no standing non-approving verdict three reviews total on this PR, all APPROVED, none against a stale head
CI ci / test success (run 8876) at a62a753
merges mergeable: true, no conflict

So:

  • blocker:unrequested removed — it was true at 18:13Z because cluade-bot had never been asked; codex-bot requested the round at 18:17Z and the verdict landed at 18:26Z. Nobody is unasked now.
  • state:addressing removed — that label means the round finished without full approval, or a blocker is up. Neither holds.
  • state:needs-human set — which on this board means exactly one thing: this PR could be merged right now. Zero blockers, whole panel approved the current head.

Nothing is owed by the builder here, so no attention flag: the ball is on a human to merge. On merge, #26 moves to post-merge by hand (stoke has no label engine until #30 lands) and triage ticks the epic #27 child.

Triage — board repair, not a review. The round closed at 18:26Z, so the two labels this PR was carrying both went false. Measured at head `a62a753656164f66c8a486ad06c3c9d7c2c663e0` (2026-08-19T19:1xZ): | what | evidence | |---|---| | panel complete | roster of record is codex / glm / cluade / kimi `-bot-andresmgsl`, panel-minus-author ([#26](../issues/26)); author is codex-bot, so the panel is kimi + glm + cluade — **all three requested, all three `APPROVED`** at `a62a753` (kimi 12:46:56Z, glm 16:35:34Z, cluade 18:26:28Z) | | no standing non-approving verdict | three reviews total on this PR, all `APPROVED`, none against a stale head | | CI | `ci / test` **success** (run 8876) at `a62a753` | | merges | `mergeable: true`, no conflict | So: - `blocker:unrequested` **removed** — it was true at 18:13Z because cluade-bot had never been asked; codex-bot requested the round at 18:17Z and the verdict landed at 18:26Z. Nobody is unasked now. - `state:addressing` **removed** — that label means the round finished *without* full approval, or a blocker is up. Neither holds. - `state:needs-human` **set** — which on this board means exactly one thing: **this PR could be merged right now.** Zero blockers, whole panel approved the current head. Nothing is owed by the builder here, so no `attention` flag: the ball is on a human to merge. On merge, [#26](../issues/26) moves to `post-merge` by hand (stoke has no label engine until [#30](../issues/30) lands) and triage ticks the epic [#27](../issues/27) child.
andres merged commit 4c6185898e into main 2026-08-19 19:15:33 +00:00
claude-bot-andresmgsl removed the
state:needs-human
 label 2026-08-20 21:13:51 +00:00
claude-bot-andresmgsl commented 2026-08-20 21:13:52 +00:00
Member
Copy link

Triage — board repair, not a review. Clearing the one stale state label on this board.

state:needs-human was true when it was set (2026-08-19T19:13:26Z: zero blockers, full panel approved at a62a753) and went false 2m07s later, when @andres merged this PR at 19:15:33Z (4c618589). Nothing cleared it, and nothing ever will by machine: ceremony's sweep enumerates open PRs only (labels-sweep.yml: "every sweep covers every open PR"), so a state label stranded on a merged PR is permanent until a hand removes it. The #30 adoption will not fix this one.

It was also the board's only such stranding — the other thirteen merged/closed PRs (!2–!6, !12, !14–!20, !28) carry no labels at all, so this was an outlier, not a convention.

A state answers whose ball is it (LABELS.md: exactly one per open PR), and state:needs-human says one specific thing — this PR could be merged right now. On a PR merged 26 hours ago there is no ball and nothing to merge, so the label now lies in the one way its family is least able to afford. Removed; no other label, and nothing on the issue side, changed.

Rest of this tick's sweep: the board is otherwise true — #1 stays blocked (!21 open, unmerged, mergeable but carrying a standing REQUEST_CHANGES and a failed ci / test at 33079afb); #30 stays claimed (codex-bot, !31 open with Refs #30, so the 48h reclaim clock does not apply); #23/#24/#25/#32 stay ready and unassigned, each verified still-unfixed against origin/main at 4c61858 (repo create has no -o/--owner, no repo sync verb exists, release create has no --asset, package.json reads 1.3.0); epic #27's task list matches its children.

**Triage — board repair, not a review.** Clearing the one stale state label on this board. `state:needs-human` was true when it was set (2026-08-19T19:13:26Z: zero blockers, full panel approved at `a62a753`) and went false 2m07s later, when @andres merged this PR at 19:15:33Z (`4c618589`). Nothing cleared it, and nothing ever will by machine: ceremony's sweep enumerates **open** PRs only ([labels-sweep.yml](https://forgejo.heavyduty.builders/heavy-duty/ceremony/src/tag/0.6.1/.github/workflows/labels-sweep.yml): *"every sweep covers every open PR"*), so a state label stranded on a merged PR is permanent until a hand removes it. The #30 adoption will not fix this one. It was also the board's only such stranding — the other thirteen merged/closed PRs (!2–!6, !12, !14–!20, !28) carry no labels at all, so this was an outlier, not a convention. A state answers *whose ball is it* ([LABELS.md](https://forgejo.heavyduty.builders/heavy-duty/ceremony/src/branch/main/LABELS.md): exactly one per **open** PR), and `state:needs-human` says one specific thing — *this PR could be merged right now*. On a PR merged 26 hours ago there is no ball and nothing to merge, so the label now lies in the one way its family is least able to afford. Removed; no other label, and nothing on the issue side, changed. Rest of this tick's sweep: the board is otherwise true — #1 stays `blocked` (!21 open, unmerged, `mergeable` but carrying a standing REQUEST_CHANGES and a failed `ci / test` at `33079afb`); #30 stays `claimed` (codex-bot, !31 open with `Refs #30`, so the 48h reclaim clock does not apply); #23/#24/#25/#32 stay `ready` and unassigned, each verified still-unfixed against `origin/main` at `4c61858` (`repo create` has no `-o/--owner`, no `repo sync` verb exists, `release create` has no `--asset`, `package.json` reads `1.3.0`); epic #27's task list matches its children.
Sign in to join this conversation.
Reviewers
No reviewers
kimi-bot-andresmgsl
glm-bot-andresmgsl
claude-bot-andresmgsl
Labels
Clear labels   
attention

A demand is parked here for the assignee: pick up the thread, ack by removing this label

  
blocked

Waiting on another PR or issue to land first

  
blocker:ci-red

A check is failing — the agent owes a fix (not a rebase)

  
blocker:conflict

Does not merge — the branch conflicts and the agent owes a rebase

  
blocker:drill-pending

A release PR whose version has no drills/X.Y.Z.md record — correct but unevidenced

  
blocker:unrequested

Somebody still owes a verdict and nobody was asked for one

  
bug

Something isn't working

  
claimed

A builder owns it: assignee set, draft PR expected shortly

  
documentation

Improvements or additions to documentation

  
enhancement

New feature or request

  
epic

Organizes other issues via a dependency-ordered task list — builders never pick it

  
merge-next

Head of the merge queue — merge this one next (set by hand/agent, cleared here)

  
needs-ruling

A human decision is pending — question, options and a recommendation are in the comment

  
needs-triage

Did not come through triage — owes normalization into work or a reasoned refusal

  
offsite

Issue deliverable is a PR in another repository — claim clock paused

  
post-merge

Refs-linked PR merged; post-merge criteria remain and triage owns completion

  
ready

Triaged, spec complete, unblocked — a builder can start now and succeed

  
release

Release flow and version/packaging work

  
scope:ci

.forgejo/workflows/, .github/, and .ceremony/ — the test, label, and governance gates

  
scope:cli

src/ — the command surface (cli.js, api.js, config.js)

  
scope:docs

root Markdown and docs/ — the prose contract

  
scope:manifests

manifests/ — the fleet repo registry data

  
scope:packaging

scripts/, release workflow, package manifests, changelog, and fragments — release packaging and version surfaces

  
stale

No activity for 48h — needs a poke (sweep-managed)

  
state:addressing

All bots reviewed — coding agent owes the single reply + fixes

  
state:bots-reviewing

Waiting on the bot reviewers to finish the round

  
state:building

Pre-round: the builder is still building — draft is evidence for it, not the definition

  
state:needs-human

No blockers, all bots approve — waiting on the human reviewer

No labels
attention
blocked
blocker:ci-red
blocker:conflict
blocker:drill-pending
blocker:unrequested
bug
claimed
documentation
enhancement
epic
merge-next
needs-ruling
needs-triage
offsite
post-merge
ready
release
scope:ci
scope:cli
scope:docs
scope:manifests
scope:packaging
stale
state:addressing
state:bots-reviewing
state:building
state:needs-human
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
4 participants
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/stoke#29
No description provided.
Delete branch "build/26-issue-create-labels"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?