# Windows Native Scaffolding (Experimental)

> **Status: experimental, NOT a supported install path.** Use the WSL path from the
> top-level README unless you have a specific reason to run priority-forge as a
> Windows-side service.

This directory holds Task Scheduler XML templates and a stub PowerShell installer for
running the priority-forge backend and frontend as Windows native services, without WSL.

## What's missing vs the WSL path

- No watchdog (no port-flap recovery, no auto-restart on crash beyond Task Scheduler's
  built-in retry).
- `npm run verify` has no Windows branch — it will report `Platform: win32` and skip the
  service status checks.
- `setup.sh` does not invoke `install.ps1`; you have to run it manually from PowerShell.
- The MCP proxy install path resolves to `%LOCALAPPDATA%\priority-forge\mcp-proxy.js`
  but `npm run setup:mcp` writes `.mcp.json` files using forward-slash paths from
  `os.homedir()`; on Windows these work for Node but may confuse hand-edited tooling.
- No equivalent of `./setup.sh stop` / `status` / `logs` — use Task Scheduler UI or
  `schtasks.exe /query`.

## Files

| File | Purpose |
|---|---|
| `priority-forge-backend.task.xml.template` | Task Scheduler XML for the backend (port 3456). |
| `priority-forge-frontend.task.xml.template` | Task Scheduler XML for the frontend (Vite, port 5173). |
| `install.ps1` | PowerShell stub that resolves `@@TOKENS@@` and runs `schtasks.exe /create /xml`. |

## Tokens

The XML templates use the same `@@TOKEN@@` convention as the macOS launchd plist templates:

- `@@NODE_EXE@@` — absolute path to `node.exe` (e.g. `C:\Program Files\nodejs\node.exe`)
- `@@INSTALL_DIR@@` — absolute path to the priority-forge repo
- `@@USERPROFILE@@` — `%USERPROFILE%` value at install time
- `@@USER_ID@@` — `whoami` output (used in the `<UserId>` element)

## Install

From an elevated PowerShell, with the repo checked out at `C:\Users\<you>\priority-forge`:

```powershell
cd C:\Users\<you>\priority-forge
.\windows\install.ps1
```

The script will:
1. Resolve tokens against the current environment.
2. Write resolved XML to `$env:LOCALAPPDATA\priority-forge\tasks\`.
3. Register the tasks via `schtasks.exe /create /xml ... /tn "PriorityForge\backend"`.

## Uninstall

```powershell
schtasks.exe /delete /tn "PriorityForge\backend" /f
schtasks.exe /delete /tn "PriorityForge\frontend" /f
```

## When to prefer WSL instead

Almost always. The WSL path:
- Uses systemd user units that are battle-tested with this stack.
- Shares its MCP proxy install with Linux contributors and CI.
- Has full `verify`, `watchdog`, `setup.sh` coverage.

This directory exists so a future contributor has a concrete starting point rather than a
blank slate. If you finish wiring it up end-to-end (watchdog, verify branch, setup.sh
subcommand), please remove the "experimental" label from this README and the top-level one.
