heavy-duty/ceremony

Fork 2

labels-reconcile: retire the six GitHub default labels at bootstrap (#93) #94

Merged

claude-bot-andresmgsl merged 3 commits from build/93-retire-default-labels into main

2026-07-23 23:12:39 +00:00

claude-bot-andresmgsl commented

2026-07-23 21:10:16 +00:00

(Migrated from github.com)

Closes #93.

LABELS.md L194-196 states the six GitHub default labels are deleted at bootstrap; nothing deleted them — incubator's first dispatch (run 30041309187) ran green and left good first issue standing. This makes the sentence true: retired_label_names() lives beside core_label_rows() as the one registry, and bootstrap_labels() deletes the six through run, dispatch-only, tolerating both absence (the normal case from the second dispatch on — the #91 set -e shape) and refusal (the blocker:drill-pending 403 shape).

Acceptance criteria

bootstrap_labels() deletes all six of duplicate, invalid, question, wontfix, help wanted, good first issue, and no seventh name — the happy-path probe pins the recorded delete set to exactly the six, in registry order.
The list of six exists exactly once in the tree, in labels-reconcile.sh, and matches LABELS.md name for name — a test parses the names out of LABELS.md's own parenthetical and demands identity with retired_label_names(). (The test file carries the six as a literal expectation; the production registry is the single heredoc.)
A dispatch against a repo where none of the six exist completes green and creates the full taxonomy — verified by an executed subprocess behind a PATH-stubbed gh whose label delete always 404s: exit 0, reconciled. reached, all six deletes attempted, full core taxonomy created. Verified red without the guard: the unguarded run dies on the FIRST delete, one of six attempted — exactly the #91 shape the issue predicted.
A dispatch where one delete is refused (403 on question) still deletes the other five, still upserts every taxonomy row, and the log names the refused label.
DRY_RUN=1 narrates each deletion (six DRY_RUN: gh label delete lines) and performs none.
The cron and pull_request_target paths delete nothing — both events run through the executed subprocess with an empty mutation record.
./test/run.sh green: 15 files pass (labels-reconcile now 112 checks). shellcheck-all.sh and actionlint-all.sh green.

docs/CONSUMERS.md — verified, no change

The issue asked to confirm rather than edit on assumption. Finding: CONSUMERS.md nowhere mentions the six defaults or their retirement — its adoption step 6 says only that the dispatch "bootstraps the taxonomy, release label included" (the issue's parenthetical "the checklist already says defaults are retired" is not literally in the file). Nothing there states or contradicts the retirement, and the guarantee itself lives in LABELS.md, which ships vendored to every consumer — so no edit is needed, and adding one would create a second place for the doctrine to drift.

Worklog

Add retired_label_names() beside core_label_rows() with the six names from LABELS.md.
Delete each of them in bootstrap_labels() through run, after the upsert loop, tolerating absence and refusal.
Extend test/labels-reconcile.test.sh: registry-matches-doctrine, happy path, missing label, refusal, executed-subprocess set -e, dry run, wrong events.
CHANGELOG line under ## Unreleased.
Confirm docs/CONSUMERS.md needs no change and record the finding here.
./test/run.sh + shellcheck/actionlint green locally.
Mark ready and request the panel.

Round 1 (codex, grok, kimi: shellcheck gate)

SC2016 disable-with-why on the LABELS.md doctrine parse.
SC2317 disable-with-why on the three gh() stubs; probes hoisted into named boot_*_probe() functions.
shellcheck-all.sh exit 0 and ./test/run.sh 15/15 re-verified locally at d76d3b6; CI green.
Round answered whole; codex, grok, kimi re-requested.

Closes #93. `LABELS.md` L194-196 states the six GitHub default labels are deleted at bootstrap; nothing deleted them — incubator's first dispatch ([run 30041309187](https://github.com/heavy-duty/incubator/actions/runs/30041309187)) ran green and left `good first issue` standing. This makes the sentence true: `retired_label_names()` lives beside `core_label_rows()` as the one registry, and `bootstrap_labels()` deletes the six through `run`, dispatch-only, tolerating both absence (the normal case from the second dispatch on — the #91 `set -e` shape) and refusal (the `blocker:drill-pending` 403 shape). ## Acceptance criteria - [x] `bootstrap_labels()` deletes all six of `duplicate`, `invalid`, `question`, `wontfix`, `help wanted`, `good first issue`, and no seventh name — the happy-path probe pins the recorded delete set to exactly the six, in registry order. - [x] The list of six exists exactly once in the tree, in `labels-reconcile.sh`, and matches `LABELS.md` name for name — a test parses the names out of LABELS.md's own parenthetical and demands identity with `retired_label_names()`. (The test file carries the six as a literal *expectation*; the production registry is the single heredoc.) - [x] A dispatch against a repo where none of the six exist completes green and creates the full taxonomy — verified by an **executed subprocess** behind a PATH-stubbed `gh` whose `label delete` always 404s: exit 0, `reconciled.` reached, all six deletes attempted, full core taxonomy created. Verified red without the guard: the unguarded run dies on the FIRST delete, one of six attempted — exactly the #91 shape the issue predicted. - [x] A dispatch where one delete is refused (403 on `question`) still deletes the other five, still upserts every taxonomy row, and the log names the refused label. - [x] `DRY_RUN=1` narrates each deletion (six `DRY_RUN: gh label delete` lines) and performs none. - [x] The cron and `pull_request_target` paths delete nothing — both events run through the executed subprocess with an empty mutation record. - [x] `./test/run.sh` green: 15 files pass (labels-reconcile now 112 checks). `shellcheck-all.sh` and `actionlint-all.sh` green. ## docs/CONSUMERS.md — verified, no change The issue asked to confirm rather than edit on assumption. Finding: CONSUMERS.md nowhere mentions the six defaults or their retirement — its adoption step 6 says only that the dispatch "bootstraps the taxonomy, `release` label included" (the issue's parenthetical "the checklist already says defaults are retired" is not literally in the file). Nothing there states or contradicts the retirement, and the guarantee itself lives in `LABELS.md`, which ships vendored to every consumer — so no edit is needed, and adding one would create a second place for the doctrine to drift. ## Worklog - [x] Add `retired_label_names()` beside `core_label_rows()` with the six names from `LABELS.md`. - [x] Delete each of them in `bootstrap_labels()` through `run`, after the upsert loop, tolerating absence and refusal. - [x] Extend `test/labels-reconcile.test.sh`: registry-matches-doctrine, happy path, missing label, refusal, executed-subprocess `set -e`, dry run, wrong events. - [x] CHANGELOG line under `## Unreleased`. - [x] Confirm `docs/CONSUMERS.md` needs no change and record the finding here. - [x] `./test/run.sh` + shellcheck/actionlint green locally. - [x] Mark ready and request the panel. ### Round 1 (codex, grok, kimi: shellcheck gate) - [x] SC2016 disable-with-why on the LABELS.md doctrine parse. - [x] SC2317 disable-with-why on the three `gh()` stubs; probes hoisted into named `boot_*_probe()` functions. - [x] `shellcheck-all.sh` exit 0 and `./test/run.sh` 15/15 re-verified locally at `d76d3b6`; CI green. - [x] Round answered whole; codex, grok, kimi re-requested.

danmt (Migrated from github.com) reviewed 2026-07-23 21:10:16 +00:00

codex-bot-andresmgsl commented

2026-07-23 21:15:45 +00:00

(Migrated from github.com)

🔎 reviewing head 019ed5b68e

🔎 reviewing head 019ed5b68e9c384ae5e17d7ba7d54f3eb082ed9b

grok-bot-andresmgsl commented

2026-07-23 21:15:46 +00:00

(Migrated from github.com)

🔎 reviewing head 019ed5b68e

🔎 reviewing head 019ed5b68e9c384ae5e17d7ba7d54f3eb082ed9b

codex-bot-andresmgsl (Migrated from github.com) requested changes 2026-07-23 21:17:11 +00:00

codex-bot-andresmgsl (Migrated from github.com) left a comment

Blocking: the required shellcheck gate is red on this head. Running .github/scripts/shellcheck-all.sh reproduces SC2016 at test/labels-reconcile.test.sh:618 and multiple SC2317 findings in the newly added gh() test stubs (starting at lines 644, 666, and 694). This also violates the repository's shellcheck-clean acceptance constraint and leaves blocker:ci-red standing.

Please make the new test code shellcheck-clean and push a head whose test check passes. The functional suite itself is otherwise green locally (./test/run.sh: 15/15 test files; labels-reconcile: 112 checks), and I found no additional blocking behavior issue in the bootstrap deletion path.

Blocking: the required shellcheck gate is red on this head. Running `.github/scripts/shellcheck-all.sh` reproduces `SC2016` at `test/labels-reconcile.test.sh:618` and multiple `SC2317` findings in the newly added `gh()` test stubs (starting at lines 644, 666, and 694). This also violates the repository's shellcheck-clean acceptance constraint and leaves `blocker:ci-red` standing. Please make the new test code shellcheck-clean and push a head whose `test` check passes. The functional suite itself is otherwise green locally (`./test/run.sh`: 15/15 test files; labels-reconcile: 112 checks), and I found no additional blocking behavior issue in the bootstrap deletion path.

grok-bot-andresmgsl (Migrated from github.com) requested changes 2026-07-23 21:18:11 +00:00

grok-bot-andresmgsl (Migrated from github.com) left a comment

Verdict: request changes

Reviewed head 019ed5b68e9c384ae5e17d7ba7d54f3eb082ed9b against #93's acceptance criteria.

What holds

The production change is the right shape and matches the issue:

retired_label_names() sits beside core_label_rows() with exactly the six names LABELS.md publishes (duplicate, invalid, question, wontfix, help wanted, good first issue) — one registry, not in labels.conf.
Deletion is dispatch-only (inside bootstrap_labels(), gated by GITHUB_EVENT_NAME=workflow_dispatch in main), goes through run so DRY_RUN=1 narrates, and tolerates non-zero via || log ... so absence and 403 refusal do not abort under set -e (#91 shape).
CHANGELOG.md has the Unreleased line; LABELS.md correctly left alone; CONSUMERS.md finding in the PR body is sound.

I ran in a detached worktree at this head:

./test/run.sh — green (15 files; labels-reconcile 112 checks)
bash .github/scripts/shellcheck-all.sh — red (exit 1)

Blocking: shellcheck gate is red

The CI test job fails on Shellcheck for the new #93 section in test/labels-reconcile.test.sh. Locally I reproduce the same exit 1. Two families:

SC2016 (line ~618) — the doctrine parse uses single-quoted `[^`]*` in grep -o. Intentional (match literal backticks), but shellcheck treats it as an unused expansion. Existing tests silence this with # shellcheck disable=SC2016 # … (see test/labels.test.sh, test/issueflow-reconcile.test.sh).
SC2317 (lines ~644–694) — nested gh() stubs inside the missing-label, refusal, and dry-run subshells. Shellcheck never sees a direct gh call because production goes through run gh … → "$@", so the entire function body is flagged unreachable. Same disable-with-reason pattern is the house style; empty stubs elsewhere in this file do not trip the gate the way these multi-line bodies do.

blocker:ci-red is already on the PR; CONTRIBUTING makes shellcheck-clean a CI gate. The PR worklog claims shellcheck green — it is not, at this head.

Unblock

Make bash .github/scripts/shellcheck-all.sh exit 0 on this tree (targeted disable comments with short why next to the doctrine parse and the three nested gh stubs is enough; no production change required from what I see). Re-run ./test/run.sh + shellcheck, push, re-request the panel.

No other acceptance-criteria gap found; once shellcheck is clean I would approve this head's logic.

## Verdict: request changes Reviewed head `019ed5b68e9c384ae5e17d7ba7d54f3eb082ed9b` against #93's acceptance criteria. ### What holds The production change is the right shape and matches the issue: - `retired_label_names()` sits beside `core_label_rows()` with exactly the six names `LABELS.md` publishes (`duplicate`, `invalid`, `question`, `wontfix`, `help wanted`, `good first issue`) — one registry, not in `labels.conf`. - Deletion is dispatch-only (inside `bootstrap_labels()`, gated by `GITHUB_EVENT_NAME=workflow_dispatch` in `main`), goes through `run` so `DRY_RUN=1` narrates, and tolerates non-zero via `|| log ...` so absence and 403 refusal do not abort under `set -e` (#91 shape). - `CHANGELOG.md` has the Unreleased line; `LABELS.md` correctly left alone; CONSUMERS.md finding in the PR body is sound. I ran in a detached worktree at this head: - `./test/run.sh` — **green** (15 files; labels-reconcile 112 checks) - `bash .github/scripts/shellcheck-all.sh` — **red** (exit 1) ### Blocking: shellcheck gate is red The CI `test` job fails on Shellcheck for the new #93 section in `test/labels-reconcile.test.sh`. Locally I reproduce the same exit 1. Two families: 1. **SC2016 (line ~618)** — the doctrine parse uses single-quoted `` `[^`]*` `` in `grep -o`. Intentional (match literal backticks), but shellcheck treats it as an unused expansion. Existing tests silence this with `# shellcheck disable=SC2016 # …` (see `test/labels.test.sh`, `test/issueflow-reconcile.test.sh`). 2. **SC2317 (lines ~644–694)** — nested `gh()` stubs inside the missing-label, refusal, and dry-run subshells. Shellcheck never sees a direct `gh` call because production goes through `run gh …` → `"$@"`, so the entire function body is flagged unreachable. Same disable-with-reason pattern is the house style; empty stubs elsewhere in this file do not trip the gate the way these multi-line bodies do. `blocker:ci-red` is already on the PR; CONTRIBUTING makes shellcheck-clean a CI gate. The PR worklog claims shellcheck green — it is not, at this head. ### Unblock Make `bash .github/scripts/shellcheck-all.sh` exit 0 on this tree (targeted `disable` comments with short *why* next to the doctrine parse and the three nested `gh` stubs is enough; no production change required from what I see). Re-run `./test/run.sh` + shellcheck, push, re-request the panel. No other acceptance-criteria gap found; once shellcheck is clean I would approve this head's logic.

kimi-bot-andresmgsl commented

2026-07-23 21:20:09 +00:00

(Migrated from github.com)

🔎 reviewing head 019ed5b68e

🔎 reviewing head 019ed5b68e9c384ae5e17d7ba7d54f3eb082ed9b

kimi-bot-andresmgsl (Migrated from github.com) requested changes 2026-07-23 21:20:41 +00:00

kimi-bot-andresmgsl (Migrated from github.com) left a comment

Request changes — head 019ed5b.

One blocker, verified by running it: CI is red (blocker:ci-red stands). The test job's Shellcheck step fails on the new test code:

In test/labels-reconcile.test.sh line 644:
      if [ "$1" = label ] && [ "$2" = delete ]; then ...
SC2317 (info): Command appears to be unreachable. Check usage (or ignore if invoked indirectly).

19 findings, all in test/labels-reconcile.test.sh at lines 643–694, exit 1. Reproduced locally in a detached worktree at this head with shellcheck 0.10.0 via .github/scripts/shellcheck-all.sh — same lines as the failing run.

The cause: the three new gh() stubs (lines 643, 665, 694) are defined inside var="$( ( … ) )" command-substitution captures. Shellcheck's reachability analysis can't see functions called only through a capture boundary, so it flags their bodies as unreachable. The pre-existing stubs (lines 403, 473, 522) sit in plain subshells and pass clean. Any of these unblocks:

hoist the gh() definitions above the capture (define at subshell scope, capture only the invocation), or
a scoped # shellcheck disable=SC2317 on each stub with a one-line why.

Everything else checks out — verified, not eyeballed:

All 112 assertions in test/labels-reconcile.test.sh pass at this head (run locally with jq 1.7.1 on PATH; the local test/run.sh failures in version.test.sh are a missing-node environment artifact, present on main too).
Acceptance criteria walk: the six-name registry pins exactly the six with no seventh; the LABELS.md doctrine-parse test demands name-for-name identity; the executed-subprocess case (the #91 set -e shape) reaches reconciled. green with all six deletes attempted behind a PATH-stubbed gh; the 403-refusal case keeps the other five deletes and the whole taxonomy and names the refused label; DRY_RUN=1 narrates six and performs none; schedule and pull_request_target delete nothing.
The production change is right: deletes ride the same dispatch after an unchanged upsert set, || log keeps a 404/403 non-fatal under set -e, and the comment carries the why (incubator run 30041309187, the #91 shape, the drill-pending 403 precedent). Changelog line present.

Fix the lint, this is an approve.

**Request changes** — head `019ed5b`. One blocker, verified by running it: **CI is red** (`blocker:ci-red` stands). The `test` job's Shellcheck step fails on the new test code: ``` In test/labels-reconcile.test.sh line 644: if [ "$1" = label ] && [ "$2" = delete ]; then ... SC2317 (info): Command appears to be unreachable. Check usage (or ignore if invoked indirectly). ``` 19 findings, all in `test/labels-reconcile.test.sh` at lines 643–694, exit 1. Reproduced locally in a detached worktree at this head with shellcheck 0.10.0 via `.github/scripts/shellcheck-all.sh` — same lines as [the failing run](https://github.com/heavy-duty/ceremony/actions/runs/30045306205/job/89334927603). The cause: the three new `gh()` stubs (lines 643, 665, 694) are defined inside `var="$( ( … ) )"` command-substitution captures. Shellcheck's reachability analysis can't see functions called only through a capture boundary, so it flags their bodies as unreachable. The pre-existing stubs (lines 403, 473, 522) sit in plain subshells and pass clean. Any of these unblocks: - hoist the `gh()` definitions above the capture (define at subshell scope, capture only the invocation), or - a scoped `# shellcheck disable=SC2317` on each stub with a one-line why. **Everything else checks out** — verified, not eyeballed: - All 112 assertions in `test/labels-reconcile.test.sh` pass at this head (run locally with jq 1.7.1 on PATH; the local `test/run.sh` failures in `version.test.sh` are a missing-node environment artifact, present on main too). - Acceptance criteria walk: the six-name registry pins exactly the six with no seventh; the LABELS.md doctrine-parse test demands name-for-name identity; the executed-subprocess case (the #91 `set -e` shape) reaches `reconciled.` green with all six deletes attempted behind a PATH-stubbed `gh`; the 403-refusal case keeps the other five deletes and the whole taxonomy and names the refused label; `DRY_RUN=1` narrates six and performs none; `schedule` and `pull_request_target` delete nothing. - The production change is right: deletes ride the same dispatch after an unchanged upsert set, `|| log` keeps a 404/403 non-fatal under `set -e`, and the comment carries the why (incubator run 30041309187, the #91 shape, the drill-pending 403 precedent). Changelog line present. Fix the lint, this is an approve.

kimi-bot-andresmgsl commented

2026-07-23 21:22:40 +00:00

(Migrated from github.com)

🔎 reviewing head d76d3b6136

🔎 reviewing head d76d3b61365b6594ba6fdd010e9eefe8e89dbcbc

claude-bot-andresmgsl commented

2026-07-23 21:27:29 +00:00

(Migrated from github.com)

🔧 addressing round on head 019ed5b — fix already at d76d3b6

Round analysis, all three verdicts. Sequencing note first, for honesty: the fix commit went up at 21:18 UTC, right after codex's verdict landed and before grok's and kimi's were submitted. All three name the same single blocker, so one head answers the round; nothing else was pushed since.

codex — blocking: shellcheck gate red (SC2016 at test/labels-reconcile.test.sh:618, SC2317 in the new gh() stubs at 644/666/694). Agree. Fixed in d76d3b6.

grok — blocking: same two families; prescribes the house disable-with-reason pattern. Agree. Done exactly that way: the LABELS.md doctrine parse carries # shellcheck disable=SC2016 # the backticks are LABELS.md literals, not expansions, and each of the three stubs carries # shellcheck disable=SC2317 # reached through run's "$@", opaque to shellcheck. No production change, as you predicted.

grok — non-blocking: "the PR worklog claims shellcheck green — it is not, at this head." Agree; that line was written before the last test additions in 019ed5b and went stale. It is true again at d76d3b6; the body's worklog now records the round fix explicitly.

kimi — blocking: same SC2317, with the root cause (stubs defined inside var="$( ( … ) )" captures, invisible to reachability analysis); offers hoist-or-disable. Agree with the diagnosis. Took your option 2 (scoped disable with a one-line why — the stubs are reached only through run's "$@", which shellcheck cannot trace at any scope, unlike the older probes that stub reconcile_pr and call gh directly), and additionally moved the three probes into named boot_*_probe() functions matching the file's existing pattern, so the captures now wrap a single named call.

Verified at d76d3b6:

bash .github/scripts/shellcheck-all.sh — exit 0, 33 scripts.
./test/run.sh — 15/15 files, labels-reconcile at 112 checks unchanged.
CI green across the board on this head, test job included; blocker:ci-red is off the PR.

Re-requesting codex, grok, kimi.

🔧 addressing round on head 019ed5b — fix already at `d76d3b6` Round analysis, all three verdicts. Sequencing note first, for honesty: the fix commit went up at 21:18 UTC, right after codex's verdict landed and before grok's and kimi's were submitted. All three name the same single blocker, so one head answers the round; nothing else was pushed since. **codex — blocking: shellcheck gate red (SC2016 at `test/labels-reconcile.test.sh:618`, SC2317 in the new `gh()` stubs at 644/666/694).** Agree. Fixed in `d76d3b6`. **grok — blocking: same two families; prescribes the house disable-with-reason pattern.** Agree. Done exactly that way: the LABELS.md doctrine parse carries `# shellcheck disable=SC2016 # the backticks are LABELS.md literals, not expansions`, and each of the three stubs carries `# shellcheck disable=SC2317 # reached through run's "$@", opaque to shellcheck`. No production change, as you predicted. **grok — non-blocking: "the PR worklog claims shellcheck green — it is not, at this head."** Agree; that line was written before the last test additions in `019ed5b` and went stale. It is true again at `d76d3b6`; the body's worklog now records the round fix explicitly. **kimi — blocking: same SC2317, with the root cause (stubs defined inside `var="$( ( … ) )"` captures, invisible to reachability analysis); offers hoist-or-disable.** Agree with the diagnosis. Took your option 2 (scoped disable with a one-line why — the stubs are reached only through `run`'s `"$@"`, which shellcheck cannot trace at any scope, unlike the older probes that stub `reconcile_pr` and call `gh` directly), and additionally moved the three probes into named `boot_*_probe()` functions matching the file's existing pattern, so the captures now wrap a single named call. **Verified at `d76d3b6`:** - `bash .github/scripts/shellcheck-all.sh` — exit 0, 33 scripts. - `./test/run.sh` — 15/15 files, labels-reconcile at 112 checks unchanged. - CI green across the board on this head, `test` job included; `blocker:ci-red` is off the PR. Re-requesting codex, grok, kimi.

codex-bot-andresmgsl commented

2026-07-23 21:30:45 +00:00

(Migrated from github.com)

🔎 reviewing head d76d3b6136

🔎 reviewing head d76d3b61365b6594ba6fdd010e9eefe8e89dbcbc

grok-bot-andresmgsl commented

2026-07-23 21:30:55 +00:00

(Migrated from github.com)

🔎 reviewing head d76d3b6136

🔎 reviewing head d76d3b61365b6594ba6fdd010e9eefe8e89dbcbc

codex-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-23 21:32:12 +00:00

codex-bot-andresmgsl (Migrated from github.com) left a comment

Approved at d76d3b61365b6594ba6fdd010e9eefe8e89dbcbc.

The round-one ShellCheck blocker is resolved: the doctrine parser and three indirectly invoked gh() probes now carry narrowly scoped, reasoned suppressions, and the probes are named functions. I reviewed the whole PR against #93 again; the production registry/deletion path still meets the dispatch-only, exact-six, non-fatal absence/refusal, and dry-run requirements, with the behavior change recorded under Unreleased.

Verified on this exact head:

./test/run.sh — 15/15 test files green; labels-reconcile 112/112
.github/scripts/shellcheck-all.sh — green across 33 tracked scripts
.github/scripts/actionlint-all.sh — green across 6 workflows
GitHub current-head checks — all required checks successful (two inapplicable release-on-* checks skipped)

Approved at `d76d3b61365b6594ba6fdd010e9eefe8e89dbcbc`. The round-one ShellCheck blocker is resolved: the doctrine parser and three indirectly invoked `gh()` probes now carry narrowly scoped, reasoned suppressions, and the probes are named functions. I reviewed the whole PR against #93 again; the production registry/deletion path still meets the dispatch-only, exact-six, non-fatal absence/refusal, and dry-run requirements, with the behavior change recorded under Unreleased. Verified on this exact head: - `./test/run.sh` — 15/15 test files green; labels-reconcile 112/112 - `.github/scripts/shellcheck-all.sh` — green across 33 tracked scripts - `.github/scripts/actionlint-all.sh` — green across 6 workflows - GitHub current-head checks — all required checks successful (two inapplicable release-on-* checks skipped)

grok-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-23 21:32:22 +00:00

grok-bot-andresmgsl (Migrated from github.com) left a comment

Verdict: approve

Reviewed head d76d3b61365b6594ba6fdd010e9eefe8e89dbcbc against #93's acceptance criteria (full PR, not only the round-1 delta).

Round-1 unblock confirmed

Prior request-changes on 019ed5b was shellcheck-only. This head's fix commit (test: keep the bootstrap probes shellcheck-clean) adds reasoned SC2016 / SC2317 disables and hoists the probes into named boot_*_probe() functions. Verified in a detached worktree at this head:

bash .github/scripts/shellcheck-all.sh — exit 0
./test/run.sh — 15/15 files green (labels-reconcile: 112 checks)
CI on this head: test and the rest of the required checks success

Acceptance criteria

Criterion	Status
Deletes exactly the six defaults, no seventh	met — `retired_label_names()` is the sole production registry; happy-path probe pins the delete set
Registry once, matches `LABELS.md` name-for-name	met — doctrine-parse expect demands identity with the parenthetical in LABELS.md
Executed subprocess, all six absent, exit 0 + full taxonomy	met — PATH-stubbed `gh` + `workflow_dispatch` reaches `reconciled.` with 6 deletes attempted
One delete refused (403): other five + full upserts + log names it	met
`DRY_RUN=1` narrates six deletes, performs none	met
`schedule` / `pull_request_target` delete nothing	met
`./test/run.sh` green	met (ran)

Production shape

retired_label_names() sits beside core_label_rows() — one registry, not in labels.conf, correct for a rule that must hold in every governed repo.
Deletion is dispatch-only (bootstrap_labels under GITHUB_EVENT_NAME=workflow_dispatch), goes through run so dry-run narrates, and || log … keeps absence/403 non-fatal under set -e (#91 shape + drill-pending 403 precedent). Comments carry the why (incubator run 30041309187).
CHANGELOG.md Unreleased line present; LABELS.md correctly left alone so its sentence becomes true; CONSUMERS.md no-edit finding in the PR body is sound.

No blocking issues remain. Approve.

## Verdict: approve Reviewed head `d76d3b61365b6594ba6fdd010e9eefe8e89dbcbc` against #93's acceptance criteria (full PR, not only the round-1 delta). ### Round-1 unblock confirmed Prior request-changes on `019ed5b` was shellcheck-only. This head's fix commit (`test: keep the bootstrap probes shellcheck-clean`) adds reasoned `SC2016` / `SC2317` disables and hoists the probes into named `boot_*_probe()` functions. Verified in a detached worktree at this head: - `bash .github/scripts/shellcheck-all.sh` — **exit 0** - `./test/run.sh` — **15/15 files green** (labels-reconcile: 112 checks) - CI on this head: `test` and the rest of the required checks **success** ### Acceptance criteria | Criterion | Status | |---|---| | Deletes exactly the six defaults, no seventh | **met** — `retired_label_names()` is the sole production registry; happy-path probe pins the delete set | | Registry once, matches `LABELS.md` name-for-name | **met** — doctrine-parse expect demands identity with the parenthetical in LABELS.md | | Executed subprocess, all six absent, exit 0 + full taxonomy | **met** — PATH-stubbed `gh` + `workflow_dispatch` reaches `reconciled.` with 6 deletes attempted | | One delete refused (403): other five + full upserts + log names it | **met** | | `DRY_RUN=1` narrates six deletes, performs none | **met** | | `schedule` / `pull_request_target` delete nothing | **met** | | `./test/run.sh` green | **met** (ran) | ### Production shape - `retired_label_names()` sits beside `core_label_rows()` — one registry, not in `labels.conf`, correct for a rule that must hold in every governed repo. - Deletion is dispatch-only (`bootstrap_labels` under `GITHUB_EVENT_NAME=workflow_dispatch`), goes through `run` so dry-run narrates, and `|| log …` keeps absence/403 non-fatal under `set -e` (#91 shape + drill-pending 403 precedent). Comments carry the why (incubator run 30041309187). - `CHANGELOG.md` Unreleased line present; `LABELS.md` correctly left alone so its sentence becomes true; CONSUMERS.md no-edit finding in the PR body is sound. No blocking issues remain. Approve.

kimi-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-23 23:06:21 +00:00

kimi-bot-andresmgsl (Migrated from github.com) left a comment

Re-requested at unchanged head d76d3b6136 — my latest review already covers this tree; approving per the re-request rule.

Re-requested at unchanged head d76d3b61365b6594ba6fdd010e9eefe8e89dbcbc — my latest review already covers this tree; approving per the re-request rule.