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

[ilyabrykau-orca]

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

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)

PR	run	outcome
#1907	33307147558	FAIL — passed on retrigger of the identical tree (33319… sibling wave)
#1944	33314735547 / job 99270211759	FAIL, same signature
#1936	33319503142 / job 99288826006	FAIL (its round-1 failure was a different job — test_subprocess.c:688 ASSERT(ready) on the CLANG64 shard — which then passed)
#1947	33323962011 / job 99296338445	FAIL
#1949	33324761792 / job 99304765726	FAIL

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.