Windows: detect-changes CLI maps 0 functions while the MCP detect_changes_tool maps them correctly

[hoh-2K112]

Environment

• OS: Windows 11 (PowerShell 5.1)
• code-review-graph: 2.3.5 (latest on PyPI), installed via uv tool install code-review-graph
• Python: 3.11
• Repo: ~133 files (python/powershell/javascript), 21.8k nodes / 148k edges
• PYTHONUTF8=1 set

Summary

On Windows, the CLI code-review-graph detect-changes resolves 0 changed functions for a diff that genuinely touches many indexed functions, and then reports a misleading "~100% token savings". The MCP tool detect_changes_tool, run against the same graph, same repo, and same git base, correctly resolves the changed functions. So the graph and git-diff are fine — only the CLI's change→node path resolution is broken on Windows.

Steps to reproduce

1. Build a graph on Windows for a repo whose source lives in subfolders (e.g. tools/...).
2. Make commits that modify several indexed functions across ~15 files.
3. Run the CLI:

   $env:PYTHONUTF8="1"
   code-review-graph detect-changes --base HEAD~1

4. Run the MCP tool against the same server (e.g. via an MCP client, the same way VS Code does):

   detect_changes_tool(base="HEAD~1")
   

Actual results

CLI (15 files detected, but 0 functions):

"summary": "Analyzed 15 changed file(s):\n  - 0 changed function(s)/class(es)\n  - 0 affected flow(s)\n  - 0 test gap(s)\n  - Overall risk score: 0.00",
"changed_functions": [],
"context_savings": { "saved_tokens": 85436, ... }

MCP detect_changes_tool (same 15 files, 37 functions):

"summary": "Analyzed 15 changed file(s):\n  - 37 changed function(s)/class(es)\n  - 37 affected flow(s)\n  - 22 test gap(s)\n  - Overall risk score: 0.75",
"changed_functions": [ { "name": "stations", "file_path": "C:\\...\\admin\\routes.py", ... }, ... ]

Expected

The CLI should resolve the same changed functions as the MCP tool (37), not 0.

Likely root cause

The graph stores node file_path as absolute, backslash paths (e.g. C:\repo\tools\myapp\notifications.py), while git diff --name-only emits relative, forward-slash paths (e.g. tools/myapp/notifications.py). The MCP detect_changes_tool code path normalizes these before matching (it works); the CLI detect-changes path apparently compares them without the same normalization, so 0 nodes match. The "files detected = 15" but "functions = 0" split is the tell: file-level listing works, function-node matching does not.

Impact

• CLI detect-changes is unusable on Windows (always 0 functions) and reports a false ~100% token-savings number.
• Not a blocker for the VS Code/Copilot integration, which uses the MCP tool (works correctly).

Suggested fix

Normalize both sides to the same form (relative, forward-slash, case-folded on Windows) in the CLI detect-changes change-resolution step, reusing whatever normalization the MCP detect_changes_tool already does.