test(windows): add red regressions for platform-specific failures

[Flipper1994]

Summary

Windows-only integration tests that drive the product surface (a real
codebase-memory-mcp.exe over JSON-RPC stdio / CLI / HTTP UI, real SQLite DB),
found during a native-Windows red-test campaign. Deterministic, standard-library
Python 3 only, and pass on Linux/macOS.

Updated after review + rebased onto current main. Three of the four
originally-red findings were fixed upstream since the branch was cut at b075f05,
so they are now green regression guards; the fourth is a genuine, still-open
Windows bug kept as a known red. This PR still contains no production fixes.

Test	Issue	Status
test_non_ascii_path.py	#636 / #357	GREEN guard — fixed by #700 (cbm_fopen routing in the pass readers)
test_hook_augment.py	#618	GREEN guard — fixed by #619 (cbm_is_walkable_abs_path accepts X:/)
test_ui_drive_listing.py	#548	GREEN guard — fixed (drives via the roots field); test rewritten
test_cli_non_ascii_arg.py	#423 / #20	RED (open) — main() is still narrow-argv, no wide command line

Re-verified on this Windows host (11 Pro 26200, drives C:/D:/E:): the three
guards pass green, the keeper stays red.

What changed since the first review

• Rebased onto current main (the only conflict was .gitignore; resolved).
• test_non_ascii_path.py / test_hook_augment.py kept as-is functionally
  (they already pass on fixed code) and re-framed as green guards for Bug: File parsing fails silently on Windows when project path contains accented/non-ASCII characters #700 / fix(hook): make hook-augment work on Windows drive-letter paths #619.
• test_ui_drive_listing.py rewritten. The D:\ drive and custom path cannot be selected in server UI #548 fix intentionally exposes
  drives through a new roots array, not the dirs array the original test
  asserted — so the old assertion would stay red against fixed code. It now asserts
  every fixed drive appears in roots and is browsable (GET /api/browse?path=X:/).
  Meaningful on a single-drive machine too, so it also gates single-drive CI.
• test_cli_non_ascii_arg.py unchanged — still genuinely red (main() narrow argv).
• scripts/test-windows.ps1 now splits green guards (must stay green, gate
  CI) from opt-in known-reds (expected red, never gate CI); adds -GuardsOnly.
  Indexing runs in-process (CBM_INDEX_SUPERVISOR=0) so a guard reflects the
  path/hook/drive fix under test, not the orthogonal index-supervisor worker path.
• CI wiring (.github/workflows/_test.yml): new test-windows-guards job builds
  the product+UI binary (scripts/build.sh --with-ui) and runs the guards with
  -GuardsOnly, so Bug: File parsing fails silently on Windows when project path contains accented/non-ASCII characters #700 / fix(hook): make hook-augment work on Windows drive-letter paths #619 / D:\ drive and custom path cannot be selected in server UI #548 stay enforced on Windows. This is separate
  from the existing test-windows sanitizer C-suite job.
• RED_TEST_ANALYSIS.md refreshed to record the landed fixes and status.

Guards (fixed on main, enforced here)

test_non_ascii_path.py — #636 / #357 (fixed by #700)

Byte-identical TypeScript fixtures under non-ASCII parent paths (Latin-1 accents,
Cyrillic, CJK, Greek) must extract the same definitions as the ASCII baseline.
Before #700, native Windows extracted only File/Folder nodes for non-ASCII
paths (the pass readers fopen()'d a UTF-8 path in the ANSI code page); #700
routed those reads through cbm_fopen → _wfopen. Guard fails if that regresses.

test_hook_augment.py — #618 (fixed by #619)

hook-augment (the PreToolUse Grep/Glob augmenter) must emit hookSpecificOutput
for a drive-letter cwd. Before #619 it bailed on cwd[0] != '/'; #619 added
cbm_is_walkable_abs_path (accepts X:/). Guard fails if that regresses.

test_ui_drive_listing.py — #548 (fixed)

The UI directory picker must let the user reach every logical drive. handle_browse
now appends "roots":["C:/","D:/",...] (via GetLogicalDrives) to every
/api/browse response. Needs a UI build (cbm-with-ui), which the CI job builds.

Known red (still open, opt-in)

test_cli_non_ascii_arg.py — #423 / #20

cli index_repository rejects a non-ASCII repo_path ("repo_path is required")
because main() (src/main.c) is int main(int argc, char **argv) with no
wmain / GetCommandLineW, so on Windows argv arrives in the ANSI code page.
Opt-in only; never gates CI. Real MCP clients pass repo_path inside byte-clean
JSON-RPC over stdio, so this affects the documented cli entrypoint and the
hook/install flows that shell out to it.

How to run

pwsh -File scripts/test-windows.ps1            # build (with UI) + guards + known-reds
pwsh -File scripts/test-windows.ps1 -GuardsOnly # only the green guards (the CI gate)

Each test exits 0 (green), 1 (red), or 2 (precondition/setup). Full
environment, commands, ruled-out seed areas, and fix references are in
tests/windows/RED_TEST_ANALYSIS.md.

Runner scope / isolation

• The three green guards are wired into Windows CI (the test-windows-guards job)
  so the landed fixes stay enforced; the opt-in known-red is never run in CI.
• No production changes — the diff is limited to tests/windows/,
  scripts/test-windows.ps1, and the CI job in .github/workflows/_test.yml.
• The harness launches only the locally built codebase-memory-mcp.exe (JSON-RPC
  stdio / CLI) and, for the drive-picker guard, the project's own embedded HTTP UI
  bound to loopback; it makes no network calls and writes only to temp dirs.

Related issues

Guards fixes: #700 (→ #636/#357), #619 (→ #618), #548. Reproduces (open): #423,
#20. Also documents ruled-out seed areas (#513/#530.x/#635, #422/#348, #274,
#371/#137, #627, #272, #511, #331, #185/#406, #227/#367) and cross-platform
out-of-scope items (#571, #530.2/.4/.5, #394 umbrella) in the analysis.

[DeusData]

Huge thanks for opening this PR and for the work you put into it.

The maintainer shop is currently full, so this may sit for a bit before it gets a proper review. We will come back to this as soon as possible with real feedback; I wanted to make sure it did not sit unacknowledged in the meantime.

[DeusData]

Thanks for putting these Windows repros together. Before this can proceed, please remove generated/session attribution from the PR text and make sure the red-test runner remains outside the normal green test path. Since the harness launches local binaries and an HTTP server, maintainers will review the runner scope carefully.

[Flipper1994]

Thanks for the feedback — both points are addressed:

• Attribution: removed the generated/session footer from the PR description.
• Runner scope: added a "Runner scope / isolation" section to the description spelling out that the runner is opt-in (scripts/test-windows.ps1 only), is referenced by no Makefile / make test target / .github/ workflow, ships no production changes, and only launches the locally built binary and the project's own loopback HTTP UI (no network, temp-only writes).

Happy to adjust the runner further if you'd like it gated or relocated differently.

[DeusData]

Thank you for this — the mcp_stdio.py harness fills a real gap (we've wanted a Windows product-binary harness for a while), and the tests are deterministic and well-engineered. The catch: the branch was cut at b075f05 and main has moved — 3 of the 4 reds are stale: the hook-augment case was fixed by #619 (issue #618 is closed), the non-ASCII pass readers were fixed by #700 (cbm_fopen everywhere), and the drive-listing test asserts drives appear in the dirs array while the landed fix intentionally exposes them via the roots field — so it stays red against fixed code, which is as misleading as a false green. The keeper is test_cli_non_ascii_arg.py: main() is still narrow argv with no wide entry point, so that red is genuine. Could you: rebase + re-run on Windows; convert the two now-green tests into permanent green guards (ideally wired into the windows CI job so #619/#700 stay enforced); rewrite the drive-listing test against the roots-field/user-level invariant; and refresh or drop the analysis doc (it snapshots claims that are no longer true of main)? With that, this becomes a great addition. Thanks!

[Flipper1994]

Thanks — this was exactly right, and I've reworked the PR accordingly.

Rebased onto current main (only .gitignore conflicted). Re-ran on Windows (11 Pro, drives C:/D:/E:) and confirmed your read on all four:

• test_non_ascii_path.py (Windows: tree-sitter definitions pass fails on ALL files when repo_path contains non-ASCII (CJK / Cyrillic / Arabic / accented Latin / etc.) characters #636/Windows non-ASCII path support issue in indexing pipeline #357 → Bug: File parsing fails silently on Windows when project path contains accented/non-ASCII characters #700) and test_hook_augment.py (hook_augment PreToolUse augmenter is a structural no-op on Windows (POSIX-only path guards) #618 → fix(hook): make hook-augment work on Windows drive-letter paths #619) are green on main now. Kept both as green regression guards and wired them into a new test-windows-guards CI job so Bug: File parsing fails silently on Windows when project path contains accented/non-ASCII characters #700/fix(hook): make hook-augment work on Windows drive-letter paths #619 stay enforced.
• test_ui_drive_listing.py (D:\ drive and custom path cannot be selected in server UI #548) rewritten. You were right that it asserted drives in dirs while the fix exposes them via roots — the old assertion stayed red against fixed code. It now asserts every fixed drive is in roots and is browsable. Green on main (roots=['C:/','D:/','E:/']), and meaningful on a single-drive box too, so it also gates the single-drive CI runner.
• test_cli_non_ascii_arg.py (codebase-memory-mcp cli index_repository asking for path but path is specified (Windows) #423/Issue with windows paths? #20) is the genuine keeper — main() is still narrow-argv with no wide command line. Opt-in, never gates CI.

One implementation note: the runner sets CBM_INDEX_SUPERVISOR=0 so the guards index in-process — the passes under test (#700's cbm_fopen) run in-process either way, and it keeps the guards independent of the index-supervisor's separate worker process. Happy to switch to the supervised path if you'd prefer.

Refreshed RED_TEST_ANALYSIS.md to record the landed fixes. Thanks again for the careful review.

[DeusData]

Thank you — and thanks especially for the rebase: converting the three now-fixed reds into green regression guards (non-ASCII paths via #703, hook-augment via #619, drive-listing via the roots API) while keeping the CLI-argv case as an opt-in known-red is exactly the right shape for a platform-guard board. Verified each against main. Merged as 7388921; the new Windows-guards CI job is a welcome addition. Two small follow-ups on our side: the non-ASCII fix is #703 (not #700), and #423/#20 need reopening since the CLI narrow-argv bug your known-red guards is genuinely still present. Appreciated!