Verify Gooeypi

Verify GooeyPi

GooeyPi is a desktop Electron app — that window is the only surface a user touches (there is no user-facing web page, CLI, or API). This skill launches the built app in an isolated, disposable profile, drives one user-facing feature the way a person would, and captures evidence. The driver mirrors the repo's own Playwright Electron harness (tests/e2e/app.spec.ts) but runs as a standalone controller you can invoke directly.

The maintained feature list lives in features/; read its index before driving, then use the matching feature file as the recipe.

Launch

• Build once. The driver launches the built bundle (package.json main → out/main/index.js). If it is missing, build it: npm run build. The driver aborts with a clear message when the bundle is absent.
• Toolchain. node/npm come from nvm (pinned 24.15.0 / 12.0.2). If node -v is not v24.15.0, select it first: export NVM_DIR="$HOME/.nvm"; . "$NVM_DIR/nvm.sh"; nvm use >/dev/null.
• Display. The app needs an X display. On a headless machine prefix every command with xvfb-run -a (e.g. xvfb-run -a --server-args="-screen 0 1600x1000x24" ...).
• Isolation. Every drive launches its own app instance with a throwaway HOME and Electron --user-data-dir, so it never reads or writes your real ~/.prime / ~/.omp / ~/.pi state and never drives an instance it did not start. Readiness is .app-shell[data-ready="true"]. A fresh HOME has no harness installed, so the driver first dismisses the No Pi family harness detected modal (that modal makes the shell inert).
• Command. xvfb-run -a node .cursor/skills/verify-gooeypi/control.mjs drive <scenario> --out <dir>

Doctor

Answer "is this instance worth driving?" before anything else, or whenever the app looks wrong:

xvfb-run -a node .cursor/skills/verify-gooeypi/control.mjs doctor --out /tmp/gooeypi-verify/doctor

It launches the app, asserts .app-shell[data-ready="true"], prints the window title (expect GooeyPi), and screenshots. A non-zero exit means the build is broken or the app never became ready — fix that before driving features.

Drive

• Harness: Playwright's _electron driving the built app. Prefer stable handles over coordinates: sidebar items are buttons with accessible names New session, Search, Projects, Activity, Scheduled, Capabilities; each page asserts its level-1 heading; Settings opens from the .sidebar__footer Settings button and lands on the General heading, with sections as buttons named Appearance, Pets, Harness, etc.
• Scenarios: node .cursor/skills/verify-gooeypi/control.mjs list → navigation, settings, capabilities. Each is one self-contained launch → drive → capture → teardown. The feature map documents these plus features (session messaging) that need the repo's hermetic fixture rather than this driver.

Evidence

• Each scenario writes PNG screenshots and .aria.txt ARIA snapshots to --out DIR (default /tmp/gooeypi-verify/<scenario>-<timestamp>) and prints a PROVEN: list of the assertions it checked.
• Proof standard: drive the real user path and capture both the action and the resulting page state (heading + ARIA), not just a final screen. For a mutation (creating a schedule or sending a message), also verify the side effect — a file written under the harness HOME, or a second read-only view — not just a toast. Record the feature ID and the entry point used.
• Artifacts survive teardown. Copy any you want to keep into /opt/cursor/artifacts for a PR walkthrough.

Cleanup

• The driver closes only the app instance it launched and removes only the throwaway fixture HOME/user-data-dir it created. It never deletes evidence dirs. Never kill Electron by name (pkill electron); the driver owns its own child process and tears it down.

Helpers

• control.mjs (executable). Subcommands: doctor, drive <scenario>, list. Invoke exactly as shown above; run under xvfb-run on headless machines.