ci: test-windows-guards intermittently dies in its own setup — "ASCII baseline did not index", nodes:None

Status: root cause found and fix open — PR #1958. index_and_count read node/edge counts exclusively from list_projects, whose stats columns are published asynchronously (on some venues never within a one-shot MCP session); index_repository's own response carries the synchronous counts. Reproduced deterministically off-CI: the project row arrives with no stats fields while the index response reports nodes=12,edges=21 and definition queries return 5 — exactly the nodes: None + definition_nodes: 5 signature below. #1958 gates on the index response and retries the setup steps once; #1961 additionally makes the fixture polyglot (TS+Go, #1959).

Type: CI flake report (harness setup, not a product regression — the same commits pass on retrigger).

Signature

tests/windows/test_non_ascii_path.py exits 2 before any guard runs:

SETUP FAIL: ASCII baseline did not index: {'name': 'C-Users-runneradmin-cbm-windows-guards-root-…-ascii_repo', 'nodes': None, 'edges': None, 'definition_nodes': 5}

The baseline fixture is the harness's own 2-file TypeScript repo (make_fixture: math.ts + main.ts). definition_nodes: 5 with nodes: None means the MCP one-shot indexed and counted definitions but the node/edge counts came back empty — the guard's index_and_count gate (base.get("error") or not base.get("nodes")) then aborts setup.

Occurrences today (2026-08-30, all on PR-CI runs of Go-gated diffs; the fixture is TS)

Same-day control group: #1939 and #1941 (other authors) passed the job first try; #1913/#1915/#1931/#1937/#1938 waves passed it.

Stronger signal: whole-harness environment failures in one job

#1936's round-2 job shows the setup failing at EVERY stage, not just the baseline index:

SETUP FAIL: ASCII baseline did not index: {'…', 'nodes': None, 'edges': None, 'definition_nodes': 5}
SETUP FAIL: permanent daemon did not start for the crash check
SETUP FAIL: index did not run:
SETUP FAIL: ASCII control did not index via CLI:

The permanent daemon not starting at all points at the runner environment (spawn/AV/socket), not at the indexed fixture. #1944 hit the job twice consecutively (round 2).

Why it matters

Fork contributors cannot rerun failed jobs (Must have admin rights), so every flake costs a full no-op force-push wave to retrigger ~35 checks. Five hits in one day suggests the failure rate is high enough to gate honest PRs on runner luck.

Possible directions (from reading the harness, not verified on a Windows box)

• index_and_count already collects cache log tails when projects comes back empty — the same diagnostics on the nodes: None path would show whether the one-shot's summary JSON was truncated or the store query raced the publish.
• A bounded retry of the baseline setup step (the fixture is byte-identical by construction) would de-flake the gate without weakening the non-ASCII comparisons it exists for.

Happy to PR the retry/diagnostics if that direction is acceptable.