Repository navigation
Windows support audit #91
Description
Summary
Windows support is inconsistent across documentation and implementation. The CLI builds Windows binaries (.goreleaser.yaml) but docs variously include, exclude, or ignore Windows. Need a clear support statement and consistent platform coverage.
Current State
| Location | Windows Status |
|---|---|
.goreleaser.yaml |
Builds windows_amd64.zip — binary ships |
docs/guides/writ/platform-awareness.md (line 48) |
"Windows (via WSL or native)" — claims support |
docs/guides/lore/create-manifests.md (lines 57-59) |
Manifest example shows platforms: [darwin, linux] — no Windows |
docs/guides/lore/pipeline.md |
No Windows examples |
install.sh |
Bash only — no PowerShell bootstrap |
| noblefactor-ops bootstrap scripts | Planned for both bash and PowerShell (noblefactor-ops#61) |
Gaps
- No clear support statement: Is Windows supported natively, via WSL only, or both? What's the official position?
- WSL vs native distinction: If both are supported, which features require WSL and which work natively?
- Missing platform in examples: Manifest examples omit Windows from platform lists, implying it's unsupported
- No Windows installation instructions: No PowerShell equivalent of
install.shfor devlore-cli - No Windows-specific testing: No CI matrix entry for Windows
Action Required
- Audit all platform references across docs and code
- Decide: native Windows, WSL-only, or both
- Create consistent Windows support statement
- Update manifest examples to include/exclude Windows consistently
- Add Windows installation path if supported
- Add Windows to CI matrix if supported
Source
Consolidated from TODO.md section 2.4.
Activity
ci(scenario): the writ-deploy scenario on ubuntu and macos (#350)
ci(scenario): the windows leg — GOEXE binaries, bash shell, empirical…
David-Noble-at-work commentedon Aug 9, 2026
Empirical audit findings from the writ-deploy scenario's windows leg (#346 phase 4, PR #351 — the scenario now passes on windows-latest):
filepath.Dirresults concatenated raw) —ToSlashat the conversion.file://prefix). Input-domain tests pin the contract.$(GOEXE)suffixing; the scenario job neededshell: bash(Windowsrun:defaults to PowerShell).TargetOrderreadsHOMEonly (real Windows users haveUSERPROFILE; the scenario harness sets both, masking it); symlink creation relies on elevated/Developer-Mode privilege (runners are admin — end-user Windows needs a policy); the emittedfile://-specific spelling on Windows (file://D:\...) is internally consistent but nonstandard per RFC 8089 Appendix E — fine as an identity tag, worth a deliberate ruling if tags ever leave the machine.