dan-claude-bot b07e734fc0 fix(labels): survive a repo that lacks the new blocker labels ... Round 1 review (claude-bot, codex-bot — both raised 1 and 2). 1. `gh issue edit --add-label` rejects the WHOLE call on one unknown label name, and the blocker:* labels are created only by the dispatch-only bootstrap. So the first sweep after this lands would have converged NOTHING on exactly the PRs this change exists to heal, surfacing only as a WARNING in a cron log. Batching state and blockers into one edit for anti-flicker is what widened that blast radius. Every label about to be ADDED is now filtered against the repo's real label set, read once per sweep; removals need no filter because they are built from has_label. An unreadable label set does not filter, so a failed read cannot silently strip the board. 2. blocker:unrequested fired only on MISSING, so a round whose approvals all staled behind a push — with nothing re-requested — carried no blocker at all, though the agent owes exactly the same ask. Now MISSING or STALE: both mean this head has no verdict from that reviewer. 3. LABELS.md: restore the substantive "Leaves when" text for state:addressing, and widen the blocker:unrequested row to name both shapes now that (2) changes what the label means. Fixtures 66 -> 68. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>		2026-07-20 17:49:44 +00:00
..
cli.sh	fix: read a manifest's final line when the file has no trailing newline	2026-07-20 12:48:39 +00:00
db-integration.sh	test(db): add real dump/restore round-trip probe + CI job + manual proof docs	2026-07-17 15:48:51 +00:00
labels-reconcile.sh	fix(labels): survive a repo that lacks the new blocker labels	2026-07-20 17:49:44 +00:00
release.sh	fix(release): re-arm the changelog heading, and guard it against VERSION	2026-07-19 19:40:27 +00:00