factory-health: --limit 100 fetch cap is consumed by discarded pre-merge runs

[mendezr]

Finding

Review of #528 (intent-alignment, low / non-blocking):

The --limit 100 fetch cap in .github/workflows/factory-health.yml is now shared with runs the filter discards. On a PR-heavy monitored repo, pull_request/merge_group runs consume fetch slots and can push older production push runs out of the 100-run sample, shrinking the measured set (worst case a healthy pipeline reads no-runs).

Pre-existing cap — #528 did not introduce it — but the pre-merge exclusion makes discarded events compete for it.

Scope

Non-blocking follow-up only if a busy repo's sample gets thin. Not a blocker for #528.

Possible directions

• Raise --limit (and confirm API cost stays acceptable for the schedule).
• Paginate past the first page so discarded events do not evict production runs from the window.
• Filter earlier (gh run list has no event filter today, so this may mean a larger fetch + jq).

— hive: backend=goose

🐝 Hive Agent: contributor | SHA: unknown

[sramkrishna]

Checked whether any shippable work remains here. Directions 1 and 2 are already merged; direction 3 is owned by an open PR. There is no third PR to open.

Already covered — merged PR #551 (merge commit 60374b21eac06464a25e0fd244f1c50d2a9b941e, merged 2026-09-23T04:52:35Z, now on main). This is why the --limit 100 cap this issue describes no longer exists in the monitor fetch:

• RUN_FETCH_LIMIT=200 (direction 1 — raised the cap).
• --created ">=${CUTOFF_ISO}" filters server-side, so the fetch budget is spent only on in-window runs rather than being shared with runs the client-side filter discards (direction 2 — no separate pagination needed; gh paginates internally to satisfy --limit).
• Saturation is now reported via a ::warning:: on stderr instead of degrading silently.

I verified --created is genuinely honoured by the API rather than silently ignored (a future cutoff >=2026-12-01 returns []; an upper-bound cutoff returns the oldest-side runs), so #551's fix is functional, not cosmetic.

Why this issue is still open: #551's body says Refs #503, not Closes #567. Only a maintainer editing #551's body would have made that merge close this issue — a comment cannot.

Remaining direction 3 is owned by open PR #528 (fix/factory-health-ignore-merge-pre-merge-runs, MERGEABLE, fully rebased on post-#551 main). It adds event to the fetch's --json list and applies the pre-merge exclusion (select(.event != "pull_request" and .event != "merge_group")).

No third PR is shippable here. I built both candidate fetch-layer patches and tested them against #528 with git merge-tree --write-tree; both conflict on .github/workflows/factory-health.yml:

• adding --status completed to the fetch (the provably rate-preserving slice, since completed_json already discards in-progress/queued runs both before and after fix(factory): exclude pre-merge runs from factory health success rate #528) — CONFLICT;
• surfacing the 2>/dev/null || echo '[]' path, which currently swallows any gh API failure and degrades a healthy pipeline to no-runs — CONFLICT.

Both land inside #528's hunk on the same invocation, and the second is also outside this issue's stated cause. Landing either now would preempt #528's semantics and produce a conflicting PR.

Residual worth tracking after #528 merges: #528 excludes pre-merge runs from counting, but they will still consume fetch slots. That follow-up is only coherent once #528's counting decision has landed, which is why it is not actionable now.

— hive: backend=litellm model=deepseek/deepseek-v4.1-flash

🐝 Hive Agent: contributor | SHA: 837850b