fix(kanban): fail-closed closing-issue lookups + totalCount (Bugbot .github#166)

[LukasWodka]

Two Medium Bugbot findings on the closing-issue advancement (the #1600/#168 drift fix), both the same fail-open class Bugbot has now caught 3× in this automation:

1. Silent skip on lookup failure — CIS=$(gh api ... 2>/dev/null) || CIS='{}' made an expired token / rate limit / cross-repo permission error indistinguishable from 'this PR closes no issues': advancement was skipped, cards stayed behind, and the run reported success — the exact drift this block exists to eliminate. Same for the per-issue IRESP lookup. Now both fail closed (RUN_FAILED=1 + continue, visible red run), never silently.
2. Silent truncation — closingIssuesReferences(first: 30) with no totalCount: a PR closing >30 issues advanced the first 30 and the rest looked like 'closed nothing'. Now first: 100 + totalCount with a loud warning + RUN_FAILED if a PR ever exceeds a page. projectItems bumped 10→20.

No fail-open path remains. Part of the same core-automation change — dry-run + review before merge (this ships on top of #168).

---

Note

Medium Risk
Changes core deploy kanban automation error handling; misclassified errors could still skip advancement or fail promotions, but behavior is stricter than the previous silent fail-open path.

Overview
Closing-issue advancement in advance-deploy-env no longer treats GraphQL lookup failures as “no issues to advance.” PR closing-issue and per-issue project queries fail closed (RUN_FAILED=1, red run) on real errors (token, rate limit, permissions) instead of swallowing stderr and substituting {}.

Benign non-PR numbers in the push are still skipped quietly by matching only GitHub’s Could not resolve to a PullRequest message—not broad “Not Found,” which would hide auth failures.

Pagination visibility:closingIssuesReferences goes from 30→100 with totalCount; runs warn and fail if a PR closes more than 100 issues. Per-issue projectItems goes 10→20 with totalCount and a warning when an issue is on more than 20 projects.

^{Reviewed by Cursor Bugbot for commit 2e01d67. Bugbot is set up for automated code reviews on this repo. Configure here.}

[LukasWodka]

Heads-up on a collision: this PR and #180 are independent fixes for the same two Bugbot findings on .github#166, opened ~15 minutes apart from different sessions. I opened #180; I did not open this one, and I am not closing either — that call is @LukasWodka's.

Recording the state so the choice is easy:

	#180	#181
fail-closed on unreadable reads	yes	yes
totalCount on closingIssuesReferences	yes	yes
totalCount on projectItems	yes (kept first: 10)	no — page bumped to first: 20 without it (Bugbot, Low)
unresolvable (#47) reference	skips as a notice	sets RUN_FAILED — would redden ordinary pushes (Bugbot, Medium)
error text in the log	yes	2>/dev/null

Both Bugbot findings here are real, and the first one was in #180 too until a few minutes ago — I had the same regression and fixed it after seeing this review. PR_NUMBERS is scraped from commit subjects and legitimately carries non-PR numbers, which the loop's own comment documents, so failing closed on them turns normal pushes red.

#180 now splits the two cases on the error text — Could not resolve to a PullRequest / ...to an Issue is a notice and a skip; a 401, rate limit or permission error sets RUN_FAILED — and echoes the error rather than discarding it, since a red run nobody can diagnose is barely better than a silent one.

If #180 is the one to keep, both findings here are already addressed there. Either way the two must not both merge.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a0e9cb3. Configure here.}

[LukasWodka]

Round-3 update on the #180 / #181 duplication, since both of these new findings are implementation-specific and neither applies to #180:

Bugbot finding on this PR	#180
High — cis_out=$(...) bare assignment under set -e makes the if [ $? -ne 0 ] branch unreachable	not present: both reads use if ! CIS=$(...) / if ! IRESP=$(...) — the pattern Bugbot itself names as the one that survives errexit
Medium — printf ... | grep -qi can return 141 via SIGPIPE under pipefail, misclassifying the benign error	not present: the error text is matched with case "$ERRTXT" in ... esac, no pipe, no grep

Running total across both: #181 has had 5 findings over 3 rounds, 2 currently open. #180 has had 3 over 2 rounds, 0 currently open. I am not claiming that as a virtue of mine — one of #180's three was a High I introduced myself, and I only found the fix because Bugbot reviewed this PR first.

The substantive difference is the approach to the cross-repo read. #181 keeps refining which error strings count as benign; #180 removed the benign case from that read entirely, on the rule that closingIssuesReferences entries were already resolved by GitHub — so a failure there is always missing access, never missing data. Text-matching has now reopened the fail-open hole twice (the Could not resolve to a Repository round and the Not Found round); the rule closes it structurally.

@LukasWodka — still your call, and I have not closed either. But every round they both stay open, the same findings get paid for twice.

[LukasWodka]

Handoff for review — do NOT fast-merge (moves every card on the board)

This PR (on top of #168) hardens the closing-issue advancement. It took 6 rounds of Bugbot findings, all now resolved — three of them regressions I introduced while fixing the previous one, all on the same fail-open/fail-closed + shell-safety boundary. Bugbot-green here means 'no known remaining hole', not 'validated correct.' It needs the two things below before merge:

1. Dry-run on real data (the only real validation)

advance-deploy-env.yml has a dry_run input (from #168). Exercise it on a controlled push and read the [DRY] would set … output. Confirm:

• A PR closing a cross-repo issue (e.g. a client PR closing a backend issue) resolves and advances that issue.
• Benign non-PR numbers (issue refs grepped from commits) are skipped quietly — no red run.
• A simulated real failure (scoped token / rate limit) fails the run (RUN_FAILED), does NOT silently skip.
• Only CLOSED closing-issues advance (open ones aren't yanked into deploy columns).

2. Careful human diff review

The fail-open/fail-closed logic is subtle (as the 6 rounds show). Read the CIS + IRESP blocks specifically: if ! cis_out=$(...) errexit-safety, the grep -qi "Could not resolve to a PullRequest" <<< "$cis_out" benign-match precision, RUN_FAILED propagation via the here-string loop, and the totalCount truncation guards.

Honest note

I kept mis-calibrating this specific logic — I'm not the right author to merge it unreviewed. Recommend consolidating #168 + #181 and dry-running them together once, with a human on the final diff.