poll.py keys the reviewer wake on result=GAPS, so a CONVERGED verdict carrying B2 or advisory items is invisible on both channels nf-30d ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/679 by tools/beads/import_github.py's reconcile pass.

Filed unclaimed from a strategic-uplift window. Evidence is first-hand: I missed B2 items on three consecutive passes of #654 and closed every reply with *"nothing outstanding"*.

The premise that is wrong

tools/pr/poll.py:444 states it plainly:

```python # nfr verdicts join the fingerprint only when they carry WORK: a GAPS # verdict un-idles the loop; a PASS carries nothing to action and must # not reset the counter (#341 review). ```

A CONVERGED verdict routinely carries work. Two kinds:

• B2 items — "is the PR description still true?" These are findings about the artifact Aedan reads, and they are reported *outside* the Findings section.
• Advisory findings — reported under ### Findings on a CONVERGED verdict.

Both channels are blind to it, independently

| mechanism | line | keys on | |---|---|---| | fingerprint (drives --check) | poll.py:457 | "result=GAPS" in first_verdict_line(...) | | open_ledger (drives WAKE + cadence hold) | poll.py:592 | same string |

So a CONVERGED verdict with open B2 items:

• does not perturb the fingerprint → --check prints NO-CHANGE
• does not raise WAKE: N unactioned GAPS ledger(s)
• does not hold the cadence

A session that follows the documented loop — run --check, act on the decision line — never learns the verdict exists. The comment at :585 is exactly right about GAPS ledgers hiding on the quiet path; this is the same hiding place with the door left open.

It is not theoretical, and one instance was a real bug

#654, 4bc3e8b verdict — CONVERGED, and the reviewer's advisory F14 said:

> *"delete refuse_if_nested(git, root) from main() and all 11 of those tests stay green"*

I ran that deletion. All 145 tests passed. The guard for #648 — a fix that PR Closes — was silently deletable, and nothing in the suite would have noticed. That finding arrived on a CONVERGED verdict, so under the current logic it produced no WAKE and did not move the fingerprint.

⚠️ I only read it because I happened to have pushed a commit, which moved headRefOid and made --check say CHANGED. Had I been idle — the exact situation the quiet ladder is designed for — --check would have said NO-CHANGE and that verdict would have sat unread while the cadence stepped out to 2h and then 4h.

Four consecutive B2 items on the following pass, three of them carried from earlier passes, are the same failure in slower motion.

Suggested fix

The reviewer already emits what is needed — its recent verdicts put ⚠️ Four B2 items, three of them carried unaddressed from earlier passes in the header prose, above the ledger. So the cheapest version needs no reviewer change:

1. Widen the fingerprint from result=GAPS to *any* nfr verdict whose body carries a ❌ B2 row or a ### Findings entry. A verdict with nothing to action still must not reset idle — so key on content, not on the result token.
2. Add a wake below the GAPS one, e.g. WAKE: N verdict(s) with unactioned B2/advisory items — read the verdict. It should *not* hold the cadence the way STALE-DISPATCH and GAPS do; these are real but not urgent.

⚠️ Whatever the shape, result= is the wrong key. It answers "did this gate?", and the loop needs "is there anything here to do?" — which is a different question the current code conflates.

Two smaller things noticed in the same read

• open_ledger's reply detection is timestamp-only (:596): *any* jcantsp-bot comment newer than the GAPS verdict clears it, including one that never mentions the ledger. A session that replies about something else marks a ledger answered.
• The ⏭/⚠️ cadence-hold rule (:600) is well documented and correct; nothing here should change it.

Refs #540 (the IDLE_TICKS ladder being hard to reach), #461 (only ⚠️ holds cadence), #341 (where the "a PASS carries nothing" premise was set).