pi-native-e2e-devlisted

Spin up a live local Doppl server + runner and exercise the native Pi TUI harness (pi-native) end-to-end — launch the real `pi` CLI via `omnigent pi`, drive turns through the web/bridge, smoke-test, and bug-bash. Load when developing, testing, or debugging the pi-native harness (omnigent/inner/pi_native_executor.py, pi_native_harness.py, omnigent/pi_native.py, pi_native_bridge.py, pi_native_credentials.py) or its bridge / extension / auth / model behavior.
sarptandoven/doppl-multiplayer · ★ 0 · Testing & QA · score 65

Install: claude install-skill sarptandoven/doppl-multiplayer

# Pi native harness: end-to-end dev & testing (local server/runner) The `pi-native` harness wraps the **real Pi coding-agent TUI** (`@earendil-works/pi-coding-agent`, the `pi` CLI). Unlike the SDK harnesses (cursor / copilot / antigravity), it does **not** run in-process: `omnigent pi` ensures a host daemon, the daemon spawns a **runner** that launches `pi` inside a runner-owned **tmux** terminal, and your TTY attaches to it. Doppl's web-UI turns are forwarded into that live `pi` process through a **file-inbox bridge** + a packaged **JS extension** (`pi.sendUserMessage`). This skill is the proven recipe for running it **for real against a live local server + runner** — not just the unit tests. > Like the other harnesses, the runner imports from your **current checkout**, so > testing here exercises exactly the code you're on. (CWD/venv selects the code, > not `PYTHONPATH`.) ## What actually runs where ``` your TTY ── (attach / pexpect) ──► omnigent pi (CLI, local) │ ensures ▼ host daemon ─────► local Doppl server (AP) │ spawns ▲ ▼ │ HTTP runner ── launches ──► pi (TUI, in tmux) │ loads