develop-screenpipe-windows

name	develop-screenpipe-windows
description	Develop and test Screenpipe Windows-native changes on a disposable Azure VM created from the prepared Screenpipe Windows dev image. Use for Windows compiler, process, service, local API, desktop, capture, installer, or permission behavior. Do not use for React-only work proved by the browser mock.

Develop Screenpipe on Windows

Use a disposable VM created from the validated Screenpipe Windows dev image for all Windows-native work. The image includes the desktop, Codex, build toolchain, native caches, and evidence tooling. Read references/dev-image.md completely before creating, updating, or using the image.

The disposable VM owns the entire task after one dispatch: Codex execution, native validation, its interactive console desktop, video recording, durable evidence upload, branch push, PR creation and update, credential cleanup, and shutdown. The dispatching computer may disconnect or power off immediately. There is no inbound RDP rule, operator desktop session, or host-held agent. Do not cross-compile and present that as Windows evidence.

Never develop or test on the live release builder, and never clone it as a per-task fallback. If no validated dev image exists, stop and report that the one-time image build is required.

Shared workflow

1. Record the exact source worktree, base SHA, acceptance invariant, forbidden actions, and cleanup target. Preserve unrelated user changes.
2. Dispatch an immutable validated image version with one immutable task blob. Its runtime managed identity may read only the required Key Vault secrets and private task/evidence blobs. Never copy host credentials into it.
3. Let the VM fetch and verify the exact requested Git revision. Do not retain a controller process or connect an operator desktop after dispatch.
4. Use only repository-supported native commands. For src-tauri, run bun run test:tauri <one-filter> -- --nocapture; never raw Cargo or Tauri.
5. Test observable behavior, including every branch of the product invariant, rather than merely proving compilation or matching source text.
6. Record the VM-owned console desktop and upload durable logs, native exit code, video, and exact tested SHA before delivery.
7. When delivery is authorized, the VM pushes the branch, creates the PR, and updates its body with the durable video link and tested SHA.
8. The VM clears runtime credentials and shuts itself down even after failure. Delete the exact disposable resources later; keep the immutable image.

This workflow never authorizes publishing an app release, tag, updater metadata, or release pointer.