PR #710 follow-ups: probe_gate baseline-staleness line nf-4a6u ← Beads

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

Suggestions from ninefold-reviewer's review of #710. All three are below the gate floor — the PR is CONVERGED — and none block anything. Unclaimed.

1. behind is optional, and its default renders an assertion rather than a shrug

render_report(..., behind: int | None = None) in tools/pr/probe_gate.py. A caller that simply forgets the argument gets

``` compared against the sweep recorded at base999 — distance from main unknown — that sha is not in this clone, on windows ```

which is a confident statement of fact about the clone, not a default. Five existing call sites in tools/tests/test_probe_gate.py (lines 319, 375, 386, 1018, 1062) already render it that way today without meaning to.

There is one production call site and it always passes behind, so nothing is wrong now. But this is the file whose thesis is that the report must be true (#412 item 1), and it already carries the precedent: the --force announcement was gated on --force alone until someone noticed it printed "re-sweeping a tree that is already recorded" after any merge at all. Making behind a required keyword-only argument costs five behind=None in tests and removes the trap.

2. "that sha is not in this clone" names one cause as fact

baseline_distance returns None whenever git() returns "" — and git() returns "" for *any* non-zero exit: an unresolvable sha, a missing or unfetched origin/main, a bad root, git itself failing. The docstring is careful about this ("an unknown sha, an unfetched ref, a history rewrite"); the user-facing line picks one of the three and asserts it.

distance from main unmeasurable, or naming both candidates, says the same thing without claiming to know which. Same standard as item 1.

3. The line names commits and platform, but never the date

#580's own framing was "54 commits and ~2.5 days", and the PR body leads with both. The shipped line carries the commit count and the platform; the time is only reachable via --show, which prints the raw JSON.

That gap has a specific shape here, because of the #637 re-stamp. An inert merge advances the baseline's sha while deliberately carrying swept forward untouched — with an explicit warning in main() that letting swept advance would make --show "claim main was swept minutes ago on the strength of a sweep that happened days earlier". The new distance is measured from the re-stamped sha, so after a run of inert merges the line reads current while the last actual probe launch was days ago.

That is not wrong — the re-stamp only fires when the sweep's inputs are provably unchanged, so the baseline genuinely does describe main's current tree. But swept_at(baseline) already exists and is already carried forward for exactly this honesty reason, and appending it (… — current, swept 2026-08-04, on windows) would make the one number a re-stamp can hide visible next to the one it advances.