cli-setup-verifylisted

# Verifying the Doppl CLI setup & UX in a closed loop The Doppl CLI's first impression is: `curl | sh` → run `omnigent` → pick a model credential → start a session. This skill lets an agent **enter that flow, examine the UI/UX, and prove whether a change is verifiable** — without a browser, without real credentials, and **without ever touching the developer's real `~/.omnigent`**. The engine is `verify_cli.py` (next to this file). It drives the real `omnigent` binary through a pseudo-terminal (`pexpect`) inside a throwaway sandbox, captures what renders, runs assertions, and prints one machine-readable `SUMMARY {json}` line. > **The whole point is a verifiable loop**, not a one-shot check: > 1. Run a scenario on the **unfixed** code → baseline (`--label before`). > 2. Make the change. > 3. Run the **same** scenario → `--label after`. > 4. Diff the two `SUMMARY` lines. A fix is "verifiable" only if a concrete > check or note **flips** between the two runs. If it doesn't flip, you > can't prove the fix did anything — go back to step 2. ## Why this is safe (read first) The real `~/.omnigent` here can be **many GB** (chat DB, runner logs, native harness state). The sandbox isolates every write three ways: - **`HOME` is redirected into the sandbox by default.** This is the load-bearing one. `OMNIGENT_CONFIG_HOME` / `OMNIGENT_DATA_DIR` (`omnigent/cli.py` `_CONFIG_HOME_ENV_VAR` / `_DATA_DIR_ENV_VAR`) redirect config + data — but the CLI's **diagnostics logger ignor