daytona-windows-cert

# Skill: Daytona Windows Enterprise Certificate Test

Run the verified Windows repro for iPolloWork enterprise TLS behavior: install a
fake corporate CA into the Windows machine store, serve healthy and broken HTTPS
control planes, install a Windows build, and prove the desktop app and spawned
runtimes use the operating system trust path.

Use this as the Windows companion to `daytona-electron-test`. Use `fraimz` when
the result needs frame-by-frame proof, screenshots, or PR evidence. Reuse the
repo support assets instead of copying their logic: `scripts/support/setup-ipollowork-tls-repro.ps1`,
`scripts/support/ipollowork-doctor.ps1`, and `docs/support/enterprise-network-doctor.md`.

## When to use

- User says "test on Windows", "Windows sandbox", or "daytona windows".
- User is validating an enterprise CA, corporate certificate, GPO cert, or
  self-hosted cert path on Windows.
- User reports `TLS fetch failed`, `fetch failed`, or a certificate-specific
  failure when connecting iPolloWork to a self-hosted control plane.
- User needs to prove the Windows app uses OS trust and spawned runtimes receive
  the OS trust bundle via `NODE_EXTRA_CA_CERTS`.

## Prereqs

- Daytona CLI must be at least the API version. The verified CLI was v0.194:

```bash
brew upgrade daytonaio/cli/daytona
brew link --overwrite daytona
daytona version
```

- `gh` must be authenticated to `Devin-AXIS/iPolloWork` and able to create/delete
  temporary public prereleases.
- Have a Windows iPolloWork build or installer ready. Keep secrets and customer
  materials out of the temporary release asset.

## 1. Create the Windows sandbox

Windows sandboxes are VM-only and are created from Daytona's prebuilt `windows`
snapshot. Available classes are `windows-small` (1 vCPU / 4 GB),
`windows-medium` (2 vCPU / 8 GB), and `windows-large` (4 vCPU / 16 GB). The
verified path used `windows-medium`:

```bash
daytona create --snapshot windows-medium
```

The command prints a sandbox ID and a web terminal URL. Save the ID once:

```bash
SANDBOX_ID="<SANDBOX_ID>"
```

Windows sandboxes may auto-stop. Restart the sandbox before continuing:

```bash
daytona sandbox start <ID>
```

Use the saved shell variable for later commands:

```bash
daytona sandbox start "$SANDBOX_ID"
```

## 2. exec vs VNC (the session-0 trap)

**Important:** `daytona ssh <ID>` is interactive-only and fails from scripts on
the host-key prompt. Use this shape for setup commands instead:

```bash
daytona exec <ID> -- <cmd>
```

For example:

```bash
daytona exec "$SANDBOX_ID" -- whoami
```

`daytona exec` runs as `nt authority\system` in Windows session 0. That is useful
for admin setup, but it **cannot see the interactive VNC user's app UI**, and
`$env:APPDATA` resolves to the SYSTEM profile, not `C:\Users\Administrator`.
Do not inspect app UI state, userData, or installed app settings through SYSTEM
profile paths.

Human GUI access is: Daytona Dashboard -> sandbox -> ⋮ menu -> **VNC** ->
Connect. Use `exec` for setup and logs; use VNC to drive the installed iPolloWork
app and observe the user-visible result.

## 3. Get the app build in

For large Windows builds, zip the build, attach it to a temporary **public
prerelease**, and download it inside the VM with the Windows-bundled `curl.exe`
and `tar`. The `curl.exe` 8.x and `tar` binaries ship in the Windows image.

From the repo root on the host, stage a zip that expands under `C:\ow`. Include
the app build plus the support scripts from this repo so the VM reuses the
checked-in harness:

```bash
TAG="ipollowork-win-cert-repro-$(date +%Y%m%d%H%M%S)"
ZIP="/tmp/${TAG}.zip"
# Put your Windows app build under /tmp/ipollowork-win-cert-upload/ipollowork/app
# and include scripts/support/setup-ipollowork-tls-repro.ps1 plus
# scripts/support/ipollowork-doctor.ps1 under ipollowork/scripts/support/.
# Include .opencode/skills/daytona-windows-cert/scripts/ca-probe.js as
# ipollowork/ca-probe.js.
ditto -c -k --keepParent /tmp/ipollowork-win-cert-upload/ipollowork "$ZIP"
gh release create "$TAG" "$ZIP" --repo Devin-AXIS/iPolloWork --prerelease
```

The release command shape from the verified session was:

```bash
gh release create <tag> <zip> --repo Devin-AXIS/iPolloWork --prerelease
```

Download and extract inside Windows:

```bash
DOWNLOAD_URL="https://github.com/Devin-AXIS/iPolloWork/releases/download/${TAG}/$(basename "$ZIP")"
daytona exec "$SANDBOX_ID" -- cmd /c 'mkdir C:\ow 2>NUL'
daytona exec "$SANDBOX_ID" -- cmd /c "curl.exe -L -o C:\ow\app.zip $DOWNLOAD_URL"
daytona exec "$SANDBOX_ID" -- cmd /c 'tar -xf C:\ow\app.zip -C C:\ow'
```

The Windows download/extract shape from the verified session was:

```bash
daytona exec "$SANDBOX_ID" -- cmd /c 'curl.exe -L -o C:\ow\app.zip <release-download-url>'
daytona exec "$SANDBOX_ID" -- cmd /c 'tar -xf C:\ow\app.zip -C C:\ow'
```

If the zip only contains the app, fetch the support scripts from the same branch
instead of rewriting them:

```bash
daytona exec "$SANDBOX_ID" -- cmd /c 'mkdir C:\ow\ipollowork\scripts\support 2>NUL'
daytona exec "$SANDBOX_ID" -- cmd /c 'curl.exe -L -o C:\ow\ipollowork\scripts\support\setup-ipollowork-tls-repro.ps1 https://raw.githubusercontent.com/Devin-AXIS/iPolloWork/dev/scripts/support/setup-ipollowork-tls-repro.ps1'
daytona exec "$SANDBOX_ID" -- cmd /c 'curl.exe -L -o C:\ow\ipollowork\scripts\support\ipollowork-doctor.ps1 https://raw.githubusercontent.com/Devin-AXIS/iPolloWork/dev/scripts/support/ipollowork-doctor.ps1'
```

## 4. Stand up the enterprise-TLS repro

`scripts/support/setup-ipollowork-tls-repro.ps1` creates a fake corporate root and
intermediate, trusts the root in `Cert:\LocalMachine\Root`, maps
`poc.ipollowork.test` to localhost, and serves:

- `https://poc.ipollowork.test:8443` — healthy chain.
- `https://poc.ipollowork.test:9443` — broken chain with the intermediate removed.

Do not run the listeners only inside a one-off `daytona exec`; the PowerShell
listeners die when that exec session closes. Persist them with a scheduled task