PR #687 follow-ups: WRAP_UP evidence counts the ledger, not the predicate, and the claims half asserts more than it checked nf-wvo ← Beads

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

Suggestions from ninefold-reviewer's review of #687. Both are below that PR's severity floor and neither blocks it — filing so the tension lands in the tracker rather than the thread. Unclaimed.

#687 makes WRAP_UP self-evidencing: it now prints the ledger path, the count of numbers in it, and the sid the claim search used. These are the two places where the new line still asserts more than it verified.

1. The ledger evidence counts lines in the file, not the predicate's input

tools/pr/poll.py, emit_idle — the new where expression uses len(tracked_numbers(tracked)). The predicate's actual input is tracked_open, which is already a parameter of the same function. They diverge on exactly the cases worth diagnosing:

- a paused PR — excluded from tracked_open by design (#512 F2), and the one #687's body says "would have fit exactly" for #684; - a merged number not yet dropped from tracked-prs.txt; - a PR whose gh pr view failed and hit the ⚠ COULD NOT READ PR branch.

Each of those renders as (1 number(s): #485) printed directly under no open tracked PRs — visually the #684 contradiction, with no actual contradiction in it. That is the false positive that inverts the fix: a session reading it concludes the bug recurred and refuses a legitimate wrap-up.

emit_tracked_prs does explain paused inline, so the *digest* stays diagnosable — but the point of the change was that the *line* is. Suggestion:

``` evidence · ledger: <path> (4 number(s): #653, #662, #665, #680; 0 counted as live work) ```

One variable already in scope.

2. The claims half has no fail-safe, and now makes a positive claim

evidence · claims: sid <8>, no open issue held by <label> reads as a search that ran and found nothing. But Gh.issue_list is self.json(argv, default=[]) or [] (tools/nflib/gh.py) running under poll.py's lenient_run, which never raises — so a failed or rate-limited gh issue list yields mine == [] and prints the identical line.

The asymmetry is the argument: the PR half of the same and has an explicit fail-safe (⚠ COULD NOT READ PR #n (gh failed) — counting it as OPEN, promoted in-gate on #401 for precisely this reason). The issue half has none, and #687 now states its result affirmatively.

Cheapest closure is to name what was scanned — N open issue(s) scanned — so a zero-length scan is distinguishable from a clean one.

Overlaps #628 and #630, which own the general "a degraded gh read is indistinguishable from a quiet one" problem. Listed here because it is the specific line #687 added, not because it is new; whoever takes #628 may subsume it.

Not filed

Three further items from the same review are actionable on #687's own branch and were raised there instead: the absent-ledger WRAP_UP suppression #618 proposes, the missing Refs #618, and poll.py's own WRAP_UP block still saying DELETE the poll cron while wrap_up.py gained the routine warning.