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
|
|
|
### 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
|
test(issueflow): each of the three sites is caught by behaviour, not only by the pin (#210)
@codex-reviewer-andresmgsl's two scope items, applied before the first review
round rather than after.
1. THE GUARD IS COMMENT-AWARE, WITH CONTROLS. It already stripped comments —
it has to, because the #188 warning that explains why has("pull_request") is
wrong contains the string. Without controls that was an untested property,
and the pressure it creates is real: a raw grep would push a builder into
deleting the very warning that prevents recurrence. Two fixtures now prove
it: the explanatory comment is allowed, an executable jq filter is rejected.
2. ALL THREE SITES ARE DRIVEN BY BEHAVIOUR. The pin makes any revert red, but a
pin proves a string is absent, not that each replacement means the intended
thing:
BOARD_RECORDS the forgejo-shaped board is not read as empty
release_bodies an open `release` issue whose gate holds an open
member makes a claimable NON-member draw a window
flag — empty carriers, no flag, so the row
discriminates the site instead of merely reaching it
reconcile_issue_pass the scalar payload: key-present-null is an issue,
object-valued is a PR, key-absent is still an issue
The release_bodies row did NOT discriminate on its first write — it asserted
an issue number that BOARD_RECORDS also produces, so reverting the site left
it green. Caught by mutating each site separately rather than trusting the
suite total.
Mutation, per site: BOARD_RECORDS 3 red, release_bodies 2 red,
reconcile_issue_pass 2 red.
test/run.sh 28/28; issueflow 510/510; shellcheck 0.10.0 clean.
Refs #210
2026-08-05 14:37:37 +00:00
|
|
|
was stated in a comment and violated forty lines below it. It strips comments,
|
|
|
|
|
so the #188 warning that explains the trap is allowed to stay (#210).
|
|
|
|
|
|
|
|
|
|
- All three sites are covered behaviourally, not only by the pin: the board
|
|
|
|
|
gather, the release-body gather through an observable window flag, and the
|
|
|
|
|
per-issue payload check (#210).
|