Define and implement a staged native Windows support contract

[codeforester]

Goal

Add a deliberate native Windows support path for Base, beginning with a small, testable contract for local repository readiness and GitHub-centered development workflows.

Background

Base currently supports macOS and Ubuntu/Debian runtime environments. Ubuntu/Debian under WSL2 is treated as a Linux runtime and does not constitute native Windows support. The current product also depends heavily on Bash, Homebrew or apt-backed setup, Unix path semantics, shell startup files, and GitHub Actions that do not include a Windows runner.

Native Windows support is a strategic gap if Base is intended to reach a broader independent-developer audience. It should not be presented as supported merely because Git Bash or WSL2 can run the existing scripts.

Relevant documentation:

• README.md compatibility section
• docs/linux-support.md
• docs/technical-overview.md

Scope

• Define the minimum native Windows support contract: Windows version, supported shells, Git distribution, Python/runtime requirements, installation method, state/cache locations, and supported command subset.
• Introduce a platform boundary for Windows paths, process execution, environment handling, permissions, line endings, and local state without scattering Windows branches through command implementations.
• Provide a native PowerShell entrypoint or equivalent supported launcher; do not require Bash startup-file mutation for the initial path.
• Add a Windows CI job covering the first supported contract, including read-only readiness, manifest parsing, workspace/project discovery, dry-run behavior, and GitHub workflow command surfaces that do not require private credentials.
• Document the staged parity model and keep WSL2 explicitly identified as a separate Linux runtime.
• Decide which setup, activation, demo, IDE, and project-command features are deferred until their platform adapters exist.

Acceptance Criteria

• The repository has a reviewed native Windows support specification and a visible compatibility matrix.
• A clean native Windows environment can install or obtain Base through the documented path and run the initial supported command subset.
• check, doctor, manifest validation, workspace discovery, dry-run output, and GitHub-facing read-only or local commands behave correctly on windows-latest.
• Tests cover Windows path quoting, spaces, environment propagation, line endings, executable resolution, and relevant permission or symlink behavior.
• The implementation does not depend on Homebrew, apt, Bash dotfiles, or WSL2 for the native contract.
• Documentation does not claim full command parity until setup, activation, project execution, demos, and IDE integrations have explicit Windows behavior.
• Existing macOS, Ubuntu/Debian, and WSL2 behavior remains unchanged.

Validation

• Run the Windows CI job on windows-latest.
• Run the focused platform, launcher, manifest, workspace, and output-contract tests on Windows.
• Run the existing macOS and Ubuntu/Debian supported gates.
• Rehearse the documented clean-install path without relying on a pre-existing Base checkout.
• Run git diff --check.

Non-Goals

• Do not treat Git Bash or WSL2 as a substitute for native Windows support.
• Do not promise complete parity in the first implementation slice.
• Do not add project-specific dependency ownership or GUI IDE setup before the platform contract is stable.
• Do not broaden Linux distribution support in this issue.
• Do not rewrite unrelated command behavior merely to increase platform coverage.

Project Fields

• Status: Backlog
• Priority: P1
• Size: L
• Area: Setup
• Initiative: Adoption Polish

Agent Assignment

Human first. This requires a product/platform decision and should be decomposed into implementation slices after the support contract is agreed.