Repository navigation
Feature: support PowerShell as a runtime target and a Windows platform for the CLI #332
Description
Context
Cortex today installs capabilities into three runtimes (Pi, OpenCode, Claude Code) and ships binaries for darwin_arm64 and linux_amd64. Two related gaps block a whole class of agents:
- Runtime target. PowerShell-based agent surfaces cannot receive skills/actors: there is no projection, no runtime-compatibility policy, and no QA backend binding for them. Add a Hermes Agent runtime target for skill and QA actor installs #303 (Hermes Agent runtime target) establishes the pattern this would follow.
- Platform. The CLI has no Windows support: no releases, unverified path/mode semantics (canonical file modes, shadow-root validation, install state), and runtime probes designed around POSIX.
Desired outcome
Two phases, each independently valuable:
- Phase A — PowerShell runtime target. A capability projection for a PowerShell runtime (where skills/actors land, what the install plan looks like), runtime-compatibility admission, and a QA route/backend binding — following the runtime-target precedent of Add a Hermes Agent runtime target for skill and QA actor installs #303 and the QA binding contract used for pi/claude/opencode.
- Phase B — Windows platform. Release binaries for windows_amd64, verified install/update/uninstall semantics on Windows (path canonicality, file modes, backup/state layout), and runtime probes validated on PowerShell.
Scope and sequencing
- Phase A does not require Phase B; a PowerShell target can land while the CLI remains POSIX-only.
- Each phase needs its own scoped plan and readiness gate before implementation (roadmap policy: new directions become milestones only through a maintainer-approved revision appended to the index Roadmap ODD index for Cortex #288).
Non-goals
- No promise of dates or versions (roadmap rule).
- No QA lifecycle changes beyond the backend binding each phase needs.
Activity
barbatdev commentedon Oct 19, 2026
Maintainer-approved scoped plan for both phases: docs/design/issue-332-powershell-windows.md (branch design/issue-332-powershell). Roadmap index revision appended in #288 (comment); milestones created: PowerShell runtime target (milestone 4), Windows platform (milestone 5). Work-unit issues are created only when each phase's readiness gate resolves — Phase A needs destination evidence and the open decisions in the plan resolved; Phase B needs a real Windows verification environment and the mode/backup semantics design.
docs(design): scoped plan for PowerShell runtime target and Windows p…
test(community): register scoped-plan doc in publication inventory (R…
test(community): reconcile publication inventory count after main reb…
merge: reconcile branch after rebase onto main (Refs #332)
docs(design): scoped plan for PowerShell runtime target and Windows p…
barbatdev commentedon Oct 19, 2026
Phase A readiness gate resolved (maintainer decision, 2026-10-19): the target is a directory projection mode (
cortex install --target-dir <path>), not a new runtime family.Evidence and rationale in the revised scoped plan (docs/design/issue-332-powershell-windows.md, Phase A revision v2, merged to main):
Milestone "PowerShell runtime target" (milestone 4) keeps its outcome name with this revised scope. Work-unit issues for the directory mode follow.
docs(design): revise Phase A to a directory projection target (Refs #332
barbatdev commentedon Oct 23, 2026
I ran a targeted Windows compatibility check against main. Evidence supporting the Phase B scope, all verifiable on main today:
Build blocker (tracked in #370).
internal/filetxn/directories.go:258andinternal/filetxn/restart.go:406type-assertinfo.Sys().(*syscall.Stat_t), which does not compile on Windows.docs/verification.md:16already states Windows "does not currently build".CI has no Windows coverage.
.github/workflows/ci.ymlandpr-validation.ymlrun only onubuntu-latest. There is nowindows-latestjob, so Windows behavior of filetxn and atomicfile is unverified on every commit.Release targets. Published prereleases are
darwin_arm64andlinux_amd64only (README.md install instructions, docs/verification.md); nowindows_amd64archive exists.Existing Windows-awareness worth preserving.
internal/atomicfile/create.goalready branches on GOOS for mode checks (rootedCreateModeOKtreats the Windows mode comparison as write-bit only), andinternal/qapi/runner.go:96has aruntime.GOOS == "windows"branch. The atomic-file layer is closer to Windows-ready than the filetxn layer.Suggested readiness inputs for the Phase B gate. (1) A
windows-latestCI job runninggo build ./...andgo vet ./...would catch compile regressions like #370 early, even before full verification exists. (2) The mode/backup semantics design the gate already requires. The dominant gate condition (a real Windows verification environment) remains unchanged.Refs #370