PR #716 follow-ups: three comments in probe_gate.py that #716 falsified nf-2881 ← Beads

closed priority 2 task unassigned

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

Suggestions from ninefold-reviewer's review of #716. Unclaimed, and none of it blocks that PR — it converged.

PR #716 keys the probe baseline on <platform>-<host> and removes the platform guard's record-blocking side effect. Three passes on that PR fixed the same class of defect at six sites (F2 the docstring's "Where the baseline lives"; F3 notes/machines.md, notes/merging.md, render_report's ⚠ NAME THE AGE, the wipeout arm's ⚠ UNWRAPPED; F5 the docstring's opening paragraph). Three more sites in tools/pr/probe_gate.py carry the same falsehood and were not reached. In each the operative conclusion still holds — only the stated reason is now false — which is why they are here rather than on the PR.

1. wipeout()'s docstring (~:384) — states the change as future work:

> hands the operator a paste-ready gh issue create blaming an innocent commit for breaking everything (measured, #632) and — once #580 lifts the platform guard that incidentally blocks it today — writes all 34 into the shared baseline

Issue #580 is closed by #716. It lifted.

2. The if wipeout(sweep) comment in main() (~:1172) — same, in the present tense:

> Today the platform guard (#566) blocks this by accident on Linux, which is the only box that has produced a wipeout. #580 exists to remove that guard, so this must not depend on it.

This is the load-bearing one of the three. PR #716's own safety argument is that removing the platform guard is safe *because* #662's wipeout guard and #665's retry now do those jobs on purpose — i.e. the wipeout guard is the sole remaining thing stopping an all-red Linux sweep entering a baseline. The comment sitting on that guard tells a reader the platform guard still backs it up. The conclusion ("this must not depend on it") is right and the code does not depend on it; only the framing is stale.

3. The ⚠ NOT "a missing engine" comment in render_report (~:627):

> "no display server" stays: that check answers None on Windows, which is the platform the baseline describes, so it genuinely can reach this banner there.

After the change the baseline describes *this box*; on either Linux box it describes Linux. Windows is still a reachable case (a Windows box can record into main-windows-<host>.json), so keeping "no display server" in the list is still right — the reason given for it is not. Worth noting this one sits six lines above the ⚠ UNWRAPPED comment PR #716 rewrote for exactly this, so the F3 fix passed within a screenful of it.

All three are comment edits. Fold them into whatever next touches this file.

Dependencies

None.

Comments

No comments.

Add a comment