Skip to main content

HolonDesktop Real Desktop Validation

Use this guide when you need evidence about the actual HolonDesktop shell instead of renderer-only behavior.

When To Use This Lane​

Run npm --prefix ./Frontend/HolonDesktop run test:real-desktop for claims about:

  • desktop startup through the real Tauri shell
  • workspace navigation in the real desktop window
  • chat send behavior through real Tauri IPC
  • host diagnostics, log capture, and runtime truth from the running app process

Do not use Frontend/HolonClient/tests/e2e as proof of those behaviors. That surface is still useful for renderer regression coverage, but it does not prove the real desktop shell started or that Rust host commands responded.

Current Validation Floor​

The current lane is Windows-first and runs against dev:light.

It proves:

  • the Tauri app launched
  • Playwright attached to the live WebView2 DOM over CDP
  • window.__TAURI_INTERNALS__ existed in the running page
  • real host commands and diagnostics responded
  • the shell could create or open a workspace and submit a chat request

If provider or model configuration is unavailable, a clearly captured blocked state is still valid smoke evidence for this lane. Do not report a successful model-backed reply unless the evidence shows a configured provider path and a real accepted response.

Supported Command​

From the repo root:

npm --prefix ./Frontend/HolonDesktop run test:real-desktop

From Frontend/HolonDesktop:

npm run test:real-desktop

Evidence Expectations​

Each run writes evidence under Frontend/HolonDesktop/tests/real-desktop/artifacts/.

Important artifacts include:

  • evidence-manifest.json
  • agent-snapshot.json
  • current-page.png
  • dev-stdout.log
  • dev-stderr.log
  • event-streams.json
  • failure-diagnostics.json
  • Playwright results.json and report-html/

Agent or reviewer claims about real desktop behavior should reference these artifacts when they are present.

Runtime Isolation​

The harness sets HOLON_DESKTOP_E2E_DATA_DIR for debug or test runs so desktop app data, diagnostics, and holon.db state stay isolated from the developer's normal app data.

The harness also uses WebView2 remote debugging with a temporary user-data folder so Playwright can attach to the real desktop DOM without sharing browser profile state across runs.