Problem: packages/gittensory-miner/lib/gate-verdict-poller.js (#4273, built under Wave 2) has zero production callers anywhere in the package (confirmed via grep across lib/ and bin/), and — per its own header comment (added during #5394's investigation) — the endpoint it was built to poll doesn't have a real match today: the only real route serving a contributor their own open-PR state is GET /v1/contributors/:login/open-pr-monitor (src/api/routes.ts, backed by buildContributorOpenPrMonitor), but its response shape is a LIST of { repoFullName, number, classification: OpenPrWorkClassification, ... } packets across every open PR for a login, not the single decided { disposition | gateDisposition | verdict } field this module's own readGateDisposition expects for ONE targeted PR.
loop-cli.js's real CI/gate-status observation (#5394, shipped in #5429) uses ci-poller.js's real GitHub check-run polling instead as the documented fallback — a real, working signal, but a heuristic (check-run conclusion), not the authoritative server-side gate_decision state this module was designed to read.
Area: Miner / Governor
Proposal: Pick one, similar to the #5395 pattern (this needs a maintainer decision, not a contributor guess):
- Build a new single-PR gate-decision API route that returns this module's expected
{ disposition | gateDisposition | verdict } shape for one targeted PR, then wire pollGateVerdict into loop-cli.js alongside (or in place of) the ci-poller.js fallback.
- Rewrite
readGateDisposition/mapGateDisposition to work against open-pr-monitor's real classification: OpenPrWorkClassification vocabulary instead, then wire it in.
- Remove the module as dead code if the
ci-poller.js heuristic is judged good enough long-term.
Boundaries: Whichever direction, this needs real tests exercising the actual chosen response shape -- not the currently-untested-in-production { disposition } assumption.
Found via a maintainer audit auditing Wave 1-3.5 completion against Wave 4's actual issue list (2026-07-12).
Problem:
packages/gittensory-miner/lib/gate-verdict-poller.js(#4273, built under Wave 2) has zero production callers anywhere in the package (confirmed via grep acrosslib/andbin/), and — per its own header comment (added during #5394's investigation) — the endpoint it was built to poll doesn't have a real match today: the only real route serving a contributor their own open-PR state isGET /v1/contributors/:login/open-pr-monitor(src/api/routes.ts, backed bybuildContributorOpenPrMonitor), but its response shape is a LIST of{ repoFullName, number, classification: OpenPrWorkClassification, ... }packets across every open PR for a login, not the single decided{ disposition | gateDisposition | verdict }field this module's ownreadGateDispositionexpects for ONE targeted PR.loop-cli.js's real CI/gate-status observation (#5394, shipped in #5429) usesci-poller.js's real GitHub check-run polling instead as the documented fallback — a real, working signal, but a heuristic (check-run conclusion), not the authoritative server-sidegate_decisionstate this module was designed to read.Area: Miner / Governor
Proposal: Pick one, similar to the #5395 pattern (this needs a maintainer decision, not a contributor guess):
{ disposition | gateDisposition | verdict }shape for one targeted PR, then wirepollGateVerdictintoloop-cli.jsalongside (or in place of) theci-poller.jsfallback.readGateDisposition/mapGateDispositionto work againstopen-pr-monitor's realclassification: OpenPrWorkClassificationvocabulary instead, then wire it in.ci-poller.jsheuristic is judged good enough long-term.Boundaries: Whichever direction, this needs real tests exercising the actual chosen response shape -- not the currently-untested-in-production
{ disposition }assumption.Found via a maintainer audit auditing Wave 1-3.5 completion against Wave 4's actual issue list (2026-07-12).