main's probe baseline can only ever be advanced from Windows, so the UI gate goes report-only as dev moves to Linux nf-pvmy ← Beads

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

Consequence of #566 that neither #567 nor #573 addresses, and it grows rather than shrinks as dev moves off Windows. Filing rather than fixing: the fix is a design choice with a real trade-off, and picking wrong makes the UI gate quieter than it looks.

The state now

#567 made the probe baseline platform-aware: the record carries "platform", and a sweep whose platform differs from the baseline's reports but refuses to record. That was necessary — without it, the first Linux merge would have written *"all 34 probes on main are broken"* into the shared screenshots branch, and it demonstrably tried to (post-merge gate on 572692e: 0 passed, 34 failed, all Godot console exe not found at C:/Tools/Godot/…, refused).

But "refuses to record" is permanent in one direction. The stored baseline says windows (unstamped legacy → windows, fail-closed). So:

• A merge performed on Linux never advances main's baseline. It sweeps, it reports, it discards.
• probe_gate.py only records when HEAD == origin/main, i.e. immediately post-merge. So the baseline advances *only* on merges performed from Windows.
• main's baseline is currently pinned at e010817 (2026-08-04), and main has moved well past it.

⚠️ The failure mode is quiet, which is the part that matters. The gate keeps printing a full, correct-looking report every merge. Nothing says "this comparison is against a baseline N merges old and will never move from here". That is the #389 shape the file's own docstring invokes — a gate that runs and reports while doing less than the reader assumes — and #566's whole direction is more Linux, not less.

Why #572 does not cover it

#572 is *why* 5 probes diverge on Linux (focus-grammar, focus-ring, new-pattern, playhead-song, single-screen-pill). Even if all five were fixed tomorrow and Linux matched Windows exactly, this issue would remain: the baseline is stamped windows, so a Linux sweep still refuses to record. The guard keys off the platform label, not off whether the results happen to agree.

Directions, not a decision

• Per-platform baselines — probe-baseline/main-<platform>.json. Each platform keeps and advances its own; the "shared so concurrent sessions compare against the same set" property survives *within* a platform. Probably the right model, since probe pass/fail genuinely differs per platform. Costs: two baselines to reason about, each only as fresh as the last merge on that box, and a migration for the existing file.
• Let a matching-platform-or-empty baseline be adopted — i.e. allow the first sweep from a new platform to re-stamp when the old baseline is staler than some threshold. Cheap, and I would argue against it: it makes "whose memory is this" depend on timing.
• Record the sweep but not the verdict — store per-platform failing sets under one file, compare only within your own. A middle road that keeps one artifact.
• Decide that main's UI gate is a Windows-box responsibility and say so out loud, in notes/probes.md and in the gate's own output, so a Linux merge prints "baseline not advanced — main's UI gate is recorded from Windows only". Does not fix it, but converts a silent gap into a loud one, which is this repo's usual floor.

Whichever way it goes, the gate's output should name the staleness it is comparing against. That part is cheap and is worth doing regardless.

Related: #572 (why the five diverge), #566 (the move to Linux), #417 (where CI would run — a second box running the sweep is the other answer), #389 (the original rotted-UI-gate incident).

Unclaimed.