Cross-platform parity

Every PolyForge command exists twice: once as a PowerShell module, once as a POSIX shell script. They are kept command-for-command identical.

The two implementations

Platform	Wrapper	Initializer
Windows	scripts/polyforge.psm1, scripts/learn.psm1, scripts/forge.psm1	polyforge.ps1
Linux / macOS / WSL	polyforge.sh, learn.sh, forge.sh	polyforge.sh activate

Only the initializer differs in how you invoke it. After activation the command surface is the same everywhere:

Windows (PowerShell)

polyforge status
learn go loops
forge list

Linux / macOS / WSL

polyforge status
learn go loops
forge list

Not “the equivalent command” — the same command, the same flags, the same output shape.

Why it matters more than it sounds

Most polyglot developers are not on one machine. A Windows desktop, a Mac laptop, a WSL environment for Linux-native work, maybe a remote box. A tool that is 90% the same across them is worse than one that is either 100% the same or obviously different — because the 10% is exactly what you will get wrong, at speed, from muscle memory.

Parity is the feature. The implementations are an implementation detail.

What this constrains

Keeping parity means PolyForge will not adopt a capability that only one side can express. A PowerShell-only convenience that has no clean POSIX equivalent does not ship, even if it would be nice on Windows.

Contributing

A change to one implementation is not complete until the other one matches. Treat scripts/*.psm1 and *.sh as a single unit under review.

Where platform differences remain visible

Two places, both unavoidable:

• The initializer invocation — .\polyforge.ps1 activate versus ./polyforge.sh activate.
• Profile location — $PROFILE versus ~/.bashrc / ~/.zshrc.

Everything after that point is shared.

Documentation on this site reflects that: snippets are shown in PowerShell and Bash tabs wherever the two differ, and in a single block wherever they do not.