Windows: profile domain detection never matches — cwd_to_project_id lowercases the id but profile `projects` keep original casing (hollow query_methodology, remember stores domain "")

[mbe14]

Environment

• Cortex 4.5.0 (marketplace install), Windows 11 Pro (26200), Python 3.13.13
• Profile built by rebuild_profiles: domain c--work-myrepo, 44 sessions, projects: ["C--Work-MyRepo"] (original filesystem casing)
• Project lives at C:\Work\MyRepo, which is outside every _discover_repos root — so resolve_cwd correctly returns '' and profile-based detection is the deciding path (the common Windows layout whenever code isn't under ~/dev-style roots)

Symptom — same live server, same cwd, A/B on the project argument

query_methodology(cwd="C:\Work\MyRepo")
  -> domain: null, confidence: 0, sessionCount: 0,
     "Domain \"None\" detected but no profile built yet. Run rebuild_profiles..."

query_methodology(cwd="C:\Work\MyRepo", project="C--Work-MyRepo")   # exact casing
  -> domain: "c--work-myrepo", confidence: 0.88, sessionCount: 44  # full profile

It also poisons writes: remember(directory="C:\Work\MyRepo") goes through _resolve_domain → detect_domain({"cwd": ...}) and stores the memory with domain: "" (verified live — the stored row's domain is empty), so new memories silently detach from their domain.

Root cause

cwd_to_project_id produces a lowercased id (c--work-myrepo), while profiles.json keeps the project id in original casing (C--Work-MyRepo). Both comparison sites in mcp_server/core/domain_detector.py compare raw:

def _score_project_match(project_id, domain):
    ...
    projects = domain.get("projects") or []
    return 1.0 if project_id in projects else 0.0      # never true on Windows

def map_project_to_domain(project_id, profiles):
    ...
        if project_id in projects:                     # same mismatch

Windows paths are case-insensitive, so on Windows this mismatch is the norm, not an edge case: any capital letter anywhere in the project path kills profile detection for every derived-id caller.

Fix (validated locally on 4.5.0)

Lowercase both sides at the two comparison sites:

def _score_project_match(project_id: str | None, domain: dict) -> float:
    if not project_id:
        return 0.0
    projects = {str(p).lower() for p in (domain.get("projects") or [])}
    return 1.0 if project_id.lower() in projects else 0.0

(and the same two lines inside map_project_to_domain). With just this patch on the live 4.5.0 server: query_methodology(cwd=...) with no project argument returns the full profile (0.88 / 44 sessions), and remember stores domain: "c--work-myrepo" again.

An alternative that fixes the class rather than the sites: normalize casing once at profile-write time (store projects pre-lowercased) — but that needs a migration for existing profiles.json; the two-site compare fix is backward-compatible with existing profiles.

Related: #18 was the slug-normalization variant of derived-id drift; this one is pure casing and survives its fix.

[cdeust]

Thanks for the diagnosis and the validated patch — the compare-both-sides fix is the right call, and it is consistent with the principle already established in cwd_to_project_id (#18): the path's dialect is detected from its syntax, never from the host OS — so a case-insensitive comparison should not be platform-gated either. Applied unconditionally.

While verifying, a wider grep over project_id/projects in core/ and handlers/ found two more sites with exactly the same raw comparison, beyond the two in your diff:

• handlers/record_session_end.py::_resolve_domain — this is precisely the site that produced the domain: "" you observed live on remember.
• core/bridge_finder.py — cross-domain bridge detection (find_bridges) also compared raw.

The fold is centralized in one function (shared/project_ids.py::normalize_project_id), reused at all four sites — same logic as your patch, deduplicated. The POSIX case-sensitivity trade-off (two sibling dirs differing only by case would share an id) is documented at the function with the rationale: extremely rare, worst case is a neighbor-domain attribution recoverable via rebuild_profiles.

Fixed in 2cb7cb83, merged to main (b2a69b65). 16 new tests including your exact C--Work-MyRepo / c--work-myrepo repro end-to-end (hollow profile → full profile; remember no longer stores domain: ""), 3586 existing tests green.

Same epistemic limit as #91/#93/#94: no Windows box here — if you can replay your live A/B (query_methodology cwd-only vs explicit project=) on main, that confirmation would let us close this. Ships in the next plugin release.

[mbe14]

Windows confirmation on main @ b2a69b65 (same box: Windows 11, Python 3.13.13, the real profiles.json with the 44-session domain). The live plugin here still runs the released 4.5.0, so I replayed the A/B at handler level against a main worktree — the exact code paths the live tools call:

normalize_project_id('C--Work-MyRepo')                        -> 'c--work-myrepo'
detect_domain({"cwd": r"C:\Work\MyRepo"}, profiles)           -> domain 'c--work-myrepo'   (was None)
detect_domain({"cwd": ..., "project": "C--Work-MyRepo"}, ...) -> domain 'c--work-myrepo'
remember._resolve_domain(r"C:\Work\MyRepo", "")               -> 'c--work-myrepo'          (was "")
record_session_end._resolve_domain("", cwd, "", profiles)     -> 'c--work-myrepo'

All four folded sites resolve, and both failure modes from the report (hollow profile on cwd-only, remember storing domain: "") are gone on main. Good catch on the two extra sites — record_session_end explains why my auto-captured memories were also landing with empty domains, which I had been attributing to the remember path alone.

I'll re-verify over the live MCP connection at the next plugin release and drop my local patch then. From my side this can close whenever you prefer.

[cdeust]

Released in v4.6.0. Your live A/B replay (cwd-only vs explicit project=) on this version would let us close.

[cdeust]

Closing on the strength of your handler-level A/B on main @ b2a69b65 — all four folded sites confirmed resolving on the affected box, which covers the substance of the report. The fix (2cb7cb83) has shipped in every release since v4.6.0; latest is v4.10.0 (released today), so a plugin update gives you the live-MCP confirmation path whenever convenient — feel free to reopen if the live replay ever disagrees with the worktree result. Thanks again for the diagnosis quality on this one: the validated patch, the exact repro (C--Work-MyRepo casing), and the live A/B made it a one-pass fix.