Summary
The shared router strips backslashes out of Windows-style literal payloads before they reach the target MCP tool. This affects commands like ooo run and ooo interview that forward $1 into skill frontmatter.
Scope / caveat
I know native Windows is currently documented as experimental in docs/platform-support.md, and that some workflow operations still assume POSIX-style paths. I am filing this as a concrete router-layer bug report inside that caveated area, not as a claim that native Windows support is already complete.
Reproduction on current main
from ouroboros.router import resolve_skill_dispatch
print(resolve_skill_dispatch(r"ooo run C:\temp\seed.yaml --strict", cwd="/tmp"))
print(resolve_skill_dispatch(r"ooo interview C:\Users\me\notes\spec.md", cwd="/tmp"))
Observed payloads on current main:
seed_path == 'C:tempseed.yaml --strict'
initial_context == 'C:Usersmenotesspec.md'
Expected payloads:
seed_path == r'C:\temp\seed.yaml --strict'
initial_context == r'C:\Users\me\notes\spec.md'
Root cause
extract_first_argument() in the shared router uses POSIX shlex.split() and then rejoins the tokens. That works for natural-language normalization, but it is destructive for Windows-style literal paths because backslashes are treated as escapes and disappear.
Impact
Since #459 centralized deterministic dispatch, the bug is now shared across all runtimes that rely on the router.
Even with the Windows caveat, this still seems worth tracking because:
- the corruption happens before runtime-specific logic sees the payload
- it can turn a literal path into different text entirely
- the failure mode is silent payload mutation rather than a clean validation error
Acceptance criteria
- Windows-style drive-letter and UNC path payloads are preserved exactly by router dispatch
- regression coverage exists for backslash-preserving literal payloads
- no existing natural-language normalization tests regress
Notes
I also verified this locally with router-level tests. If maintainers want to improve this now despite the experimental Windows caveat, the change appears small and isolated to the shared dispatch layer.
Summary
The shared router strips backslashes out of Windows-style literal payloads before they reach the target MCP tool. This affects commands like
ooo runandooo interviewthat forward$1into skill frontmatter.Scope / caveat
I know native Windows is currently documented as experimental in
docs/platform-support.md, and that some workflow operations still assume POSIX-style paths. I am filing this as a concrete router-layer bug report inside that caveated area, not as a claim that native Windows support is already complete.Reproduction on current
mainObserved payloads on current
main:seed_path == 'C:tempseed.yaml --strict'initial_context == 'C:Usersmenotesspec.md'Expected payloads:
seed_path == r'C:\temp\seed.yaml --strict'initial_context == r'C:\Users\me\notes\spec.md'Root cause
extract_first_argument()in the shared router uses POSIXshlex.split()and then rejoins the tokens. That works for natural-language normalization, but it is destructive for Windows-style literal paths because backslashes are treated as escapes and disappear.Impact
Since #459 centralized deterministic dispatch, the bug is now shared across all runtimes that rely on the router.
Even with the Windows caveat, this still seems worth tracking because:
Acceptance criteria
Notes
I also verified this locally with router-level tests. If maintainers want to improve this now despite the experimental Windows caveat, the change appears small and isolated to the shared dispatch layer.