heavy-duty/ceremony
7
0
Fork 2
Code Issues 1 Pull requests Projects Releases 8 Packages Wiki Activity Actions
ceremony/changelog.d/210.md
cluade-reviewer-andresmgsl 877e09e015
All checks were successful
CI / test (pull_request) Successful in 3m8s
Details
CI / release-exercise (pull_request) Successful in 11s
Details
CI / self-guards (pull_request) Successful in 7s
Details
CI / action-exercise (pull_request) Successful in 6s
Details
CI / docs-sync-exercise (pull_request) Successful in 6s
Details
Refs guard / refs-not-closing (pull_request) Has been skipped
Details
labels / labels (pull_request) Successful in 8s
Details
fix(issueflow): the board discriminator is .pull_request == null, not has() (#210) 
issueflow-reconcile has been blind on this forge since the 0.6.0 merge landed.
Run 368 — #198's own post-merge acceptance probe — printed:

  issueflow: no open issues.
  issueflow: reconciled.

over a board of nine.

Every Forgejo entry CARRIES the `pull_request` key, valued null on an issue, so
`select(has("pull_request") | not)` selects zero rows. Measured again today:
#209 (an issue) has the key valued null; #208 and #207 (PRs) have it valued as
objects.

This is mine. #188 fixed exactly this and the file's own comment at :1113
states the rule, with :1121 already using it correctly. Resolving hunk 4 of the
merge I took upstream's board block wholesale and carried the wrong
discriminator into three sites — the gather, the release-body gather, and
reconcile_issue_pass — in the PR whose stated purpose was to stop blind sweeps
reporting success.

Cost while it stood: no issue transitions, no claim reclaims, no nudges, no
board flags — and no `post-merge` transitions, which is why #192 and #198 both
still read `claimed` after their PRs merged, and why #198's own closure
criterion could not complete.

Two guards, because a comment did not hold:

  * A GATHER-LEVEL CASE against a Forgejo-shaped fixture — every entry carrying
    the key. The existing discriminator cases assert jq expressions in
    isolation and passed throughout this regression; they never ran the gather
    that uses them, which is precisely how it survived review.
  * A SOURCE PIN forbidding has("pull_request") on this surface, so a future
    sync cannot reintroduce it 40 lines below the comment forbidding it.

Reverting the board gather reds both. Reverting reconcile_issue_pass reds the
pin.

test/run.sh 28/28 under jq 1.7 and jq 1.6; issueflow 503/503; shellcheck 0.10.0
and actionlint clean.

Refs #210
2026-08-05 14:27:40 +00:00

917 B
Raw Blame History

Fixed

  • issueflow-reconcile sees this forge's issues again. The board gather used has("pull_request"), and every Forgejo entry carries that key — so it selected zero rows on every sweep while printing reconciled. (#210).

  • Three sites take .pull_request == null, the discriminator the file's own comment already specified and that one of its four call sites already used (#210).

  • post-merge transitions can fire again: they could not, because the sweep saw no issues to transition (#210).

Added

  • A gather-level case drives the real board read against a Forgejo-shaped fixture — every entry carrying the key. The existing discriminator cases assert jq expressions in isolation and passed throughout this regression (#210).

  • A source pin forbids has("pull_request") on this surface, because the rule was stated in a comment and violated forty lines below it (#210).