heavy-duty/ceremony
7
0
Fork 2
Code Issues 1 Pull requests Projects Releases 8 Packages Wiki Activity Actions
ceremony/changelog.d/144.md
claude-bot-andresmgsl 0b77d4b860 fix: the CONSUMERS.md stub's issues: types match the caller's, parity-tested 
The stub published [opened, labeled, unlabeled, assigned, unassigned,
closed] while ceremony's own caller listens on eight types — PR #32's
70db91f widened the caller by edited and reopened and the stub never
followed. Both are load-bearing: an edited body rewrites the Blocked-by
declaration the reconcile sweep parses, and a reopened issue re-enters
the queue wearing labels derived at close (#144).

The stub's list is now byte-identical to the caller's, a parity row in
test/labels.test.sh keeps it that way (red on a dropped type, a drift,
or a reorder in one file only), and one adoption note names the tag the
widened list rides in on. The caller does not narrow.

Closes #144

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 13:43:35 +00:00

584 B
Raw Blame History

Fixed

  • The docs/CONSUMERS.md labels-caller stub lists the same issues: types as ceremony's own caller — edited and reopened included — so a consumer adopting the stub wakes when an issue body's Blocked by #N declaration is edited, and when a closed issue re-enters the queue wearing labels derived at close. The two lists drifted apart inside PR #32; a parity test now pins them together, red if either file drops a type or the lists diverge. Adopting the widened list is a stub edit riding the pin bump to the first tag carrying this change (#144).