Repository navigation
test(context-guard, rate-limit-guard): mod tests fail on Windows because they hard-code a POSIX home (/srv/u) #11368
Description
Problem
On Windows, scripts/validate-plugins.sh --only "harness-ops" fails on a clean origin/main (6d6939f): 15 of 151 mod tests fail. Since #11360 made the check-affected pre-push hook run on Windows, this blocks every Windows push that touches harness-ops.
(fail) zones.json: custom edges move the crossings, and a later edit takes effect at the next call
test's fs.stat hook was skipped: test: ENOENT: D:\srv\u\.claude\context-guard\zones.json
...
136 pass
15 fail
Mod tests failed.
Cause (UNVERIFIED in detail)
plugins/context-guard/hooks/context-guard.test.ts:10-12 sets HOME = '/srv/u' and keys its fake files by POSIX paths such as /srv/u/.claude/context-guard/zones.json. On Windows the mod resolves that home to D:\srv\u\..., so the test's fake fs.stat never matches and the run reads the real disk. plugins/rate-limit-guard/hooks/rate-limit-guard.test.ts uses the same pattern (the ENOENT on D:\srv\u\.claude.json). CI runs on ubuntu-24.04, so CI stays green.
Fix direction
Build the fake home and its file keys with the platform's path rules (for example path.resolve('/srv/u') and path.join), and compare expected text through the same helper, so the tests pass on Windows and Linux.
🤖 Generated with Claude Code
Activity
github-actions commentedon Oct 30, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Low
Uncertainty: Known
Flags: none
Blocked by: none
Understood: the context-guard and rate-limit-guard mod tests hard-code a POSIX home (/srv/u). On Windows the mods resolve it to D:\srv\u, so the fake fs never matches and 15 tests fail. The fix is to build the fake home and file keys with path.resolve and path.join, and to build the expected text from the same constants. The refinement comment already lists the acceptance criteria. I found no likely duplicates among the open issues.
Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Oct 30, 2026
Not admitted to the issue lane yet: open pull request #11369 is for it.
melodic-automation-lanes commentedon Oct 30, 2026
The latest triage verdict holds nothing: the issue is at
status: ready.melodic-automation-lanes commentedon Oct 30, 2026
Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. On an issue a listed human filed, it counts as the issue's spec once posted, while unedited; it is still model text, so check it.
Intended outcome: Both guard test files build the fake home, file keys and expected path text with node:path (resolve/join) so the mod tests pass on Windows and Linux.
Acceptance criteria
External state: none
Related work
Sources read
Automated refinement by the lanes App. Intake triages the issue again with it.