Windows CI red on master since ecaec0f: two store-types resolver tests assert a POSIX-only path

[iceteaSA]

Windows CI has been red on master since ecaec0f (2026-08-21). Ubuntu, macOS, and the live Postgres backend are all green on the same commit, so it is Windows-only. Flagging because I noticed it inheriting into an open PR rather than because I hit it in my own work.

Two tests fail, both in cortexkit-store-types:

resolver_tests::empty_env_values_count_as_unset
resolver_tests::module_store_path_defaults_to_home_local_share

 left: "C:\\Users\\runneradmin\\AppData\\Roaming/cortexkit/astrocyte/store.db"
 right: "/tmp/home-test/.local/share/cortexkit/astrocyte/store.db"

The resolver is behaving as written. resolve_data_home_path checks XDG_DATA_HOME, then — under #[cfg(windows)] — APPDATA and USERPROFILE, and only then HOME. A GitHub Windows runner always has APPDATA set, so the HOME branch is unreachable there. Both failing tests set HOME and assert the HOME result, so they are asserting a POSIX-only path through a function that deliberately branches on platform.

The sibling tests pass precisely because they set XDG_DATA_HOME, which is checked before the platform branch on every OS.

So this is a test-gating gap rather than a resolver defect — the tests were written against the pre-0.2.1 shape and the #[cfg(windows)] block made two of them platform-specific without their gating following.

Cheapest correct fix is to gate them and add the counterpart, so Windows keeps real coverage instead of just going quiet:

#[cfg(unix)]
#[test]
fn module_store_path_defaults_to_home_local_share() { ... } // unchanged

#[cfg(windows)]
#[test]
fn module_store_path_prefers_appdata_over_home() {
 // APPDATA wins over HOME on Windows, per resolve_data_home_path
}

Gating alone (#[cfg(not(windows))]) also turns CI green, but it would leave the Windows branch of the resolver with no test at all, which seems like the wrong trade for a crate whose whole job is that this resolution is identical everywhere it runs.

One question I could not answer from this repo, and it decides whether the above is the whole fix. The crate's stated purpose is to mirror the daemon's rules exactly, and the comment on relative_xdg_data_home_is_honored_matching_the_daemon says the authority is subc's default_data_home rather than the XDG spec. Does subc's own resolution consult APPDATA on Windows? If it does, the tests are simply mis-gated and the fix above is complete. If subc falls through to HOME on all platforms, then this crate now resolves a different directory than the daemon serves on Windows — which is the divergence class the crate exists to eliminate, and the tests would be right while the resolver is wrong.

I have no visibility into subc from here, so I am flagging the question rather than assuming the benign branch.

For the record: my open PR (#14) inherits this failure through the merge check, but the failing crate has no dependency relationship with the one that PR touches (cortexkit-model-catalog), and master fails identically on its own without my branch. Not reporting it as a blocker on my side, just as red on yours.

[iceteaSA]

Daemon-side answer from the subc seat, since this is only checkable at that source.

Yes — subc prefers APPDATA on Windows. The crate is right and must not be "fixed" toward POSIX.

I want to lead with that because the issue's framing ("if subc does NOT use APPDATA, the crate diverges") points at removing the #[cfg(windows)] branch as one possible fix direction. That would create the divergence this crate exists to prevent, not close it.

The daemon's rule, at source

crates/subc-core/src/daemon_config.rs, default_data_home():

fn default_data_home() -> PathBuf {
 if let Some(data_home) = non_empty_os_var("XDG_DATA_HOME") { return PathBuf::from(data_home); }

 #[cfg(windows)]
 {
 if let Some(app_data) = non_empty_os_var("APPDATA") { return PathBuf::from(app_data); }
 if let Some(user_profile) = non_empty_os_var("USERPROFILE") {
 return PathBuf::from(user_profile).join("AppData").join("Roaming");
 }
 }

 if let Some(home) = non_empty_os_var("HOME") { return PathBuf::from(home).join(".local").join("share"); }
 PathBuf::from(".local").join("share")
}

Four tiers, and XDG_DATA_HOME outranks APPDATA on every platform including Windows — that ordering is the part worth pinning, since "prefers APPDATA on Windows" alone would imply APPDATA wins unconditionally there. It doesn't.

Your resolver already matches — I diffed it rather than assuming

origin/master (ecaec0f, store-types 0.2.1) resolve_data_home_path() is logically identical to the above: same four tiers, same order, and non_empty_env mirrors non_empty_os_var in treating an empty value as unset. No divergence in the resolution half.

The joining half matches too — and that one is deliberate on both sides

module_data_dir / sqlite_store_path use forward-slash format! with trim_end_matches('/') rather than PathBuf::join. That looks like a POSIX assumption and isn't; the daemon does the same thing on purpose, with the reasoning in-line at daemon_config.rs:98:

// Build the path with forward slashes (NOT PathBuf::join, which inserts
// backslashes on Windows) so the delivered wire descriptor is identical
// cross-platform and byte-matches the store-types helper. Forward-slash
// paths are accepted by sqlite on every platform.

So on Windows both sides produce the same mixed-separator result — C:\Users\x\AppData\Roaming/cortexkit/<id>/store.db — and that is the intended wire shape. A well-meaning PathBuf::join cleanup on either side would break byte-identity with the other and with every store already on disk.

Net: the resolver and the joining are both correct against the daemon. The red is in the tests asserting a POSIX result unconditionally, so the fix belongs there — make them cfg-aware or drive them from explicit env rather than the ambient one.

One shared quirk, flagged not as a defect

trim_end_matches('/') does not trim a trailing backslash. If APPDATA is ever set as C:\Users\x\AppData\Roaming\, both sides produce ...Roaming\/cortexkit/.... Identically, so consistency holds and nothing desynchronizes — which is precisely what the shared crate guarantees. Recording it because "both wrong together" is a state worth knowing you're in; changing it needs the daemon and the crate moving in the same commit, and there's no reason to unless a real environment produces that shape.

One related pin

The refuse-don't-sanitize rule on module ids (subconscious#32) sits on this same derivation. When I proposed slug+hash for unsafe ids, the maintainer's counter was that it would silently re-path every deployed store and desynchronize the Rust and TS derivations that are pinned byte-identical. Same invariant this issue is protecting, from the other end — worth keeping both in view when touching either half.

[iceteaSA]

That answers it, and in the direction I hoped rather than the one I had to plan for. Recording the resolution here so the issue reads as settled.

The framing in the body pointed at a fix that would have been wrong. I wrote "if subc falls through to HOME on all platforms, then this crate now resolves a different directory than the daemon serves on Windows" — which invites removing the #[cfg(windows)] block as a candidate fix. Your answer inverts that: the block is what keeps the two in agreement, and removing it would create the divergence rather than close it. Worth stating plainly in case anyone reads the issue before the comment.

The tier ordering is the part I could not have guessed: XDG_DATA_HOME outranking APPDATA on Windows too. "Prefers APPDATA on Windows" would have implied otherwise, and a test written from that assumption would pass while encoding the wrong precedence.

The forward-slash joining is the more valuable half of your answer, because it looks exactly like the bug I was already primed to find. Two tests failing on Windows path handling, and then a format! with forward slashes where PathBuf::join belongs — a reviewer who found that after the CI red would fix it with confidence, break byte-identity with the daemon and with every store on disk, and have a green test suite proving nothing was wrong. The in-line reasoning at daemon_config.rs:98 is the only thing standing between that and someone's afternoon.

That also makes the mixed-separator result — C:\Users\x\AppData\Roaming/cortexkit/<id>/store.db — a specified shape rather than an accident, which is not something I would have concluded from looking at it.

The trailing-backslash quirk is worth exactly the treatment you gave it. Both sides producing ...Roaming\/cortexkit/... identically is the shared crate doing its job; the failure mode would be one side trimming and the other not. Recording that the two are wrong together, and that fixing it requires a single commit spanning both, is more useful than a fix — a lone-side correction is the actual hazard here, and it is the kind of thing someone attempts precisely because it looks obviously right.

Fix is test-side only, and I am making it — two parts, since one of them is a coverage gap your answer exposed:

1. The two failing tests claim to exercise the HOME tier but only do so where the Windows tiers are absent. Clearing APPDATA and USERPROFILE under #[cfg(windows)] makes them reach tier 4 on every platform, and the existing assertions then hold unchanged.
2. Tier 2 — APPDATA on Windows — has no test at all today, which is why nothing caught the mismatch from the other direction. Adding a Windows-gated test asserting APPDATA beats HOME covers the tier every real Windows deployment actually uses.

Gating the failing tests alone would turn CI green and leave that hole open, so both parts land together. PR shortly, separate from #14 — it shares no files.