$ARGUMENTS

---
description: Interactively test a Pi extension in a human-visible terminal
argument-hint: "<extension> :: <scenario>"
---

# Live Pi Extension Test

Test through real interactive Pi:

```text
$ARGUMENTS
```

- Load `terminal-harness` and follow it for terminal setup, interaction, observation, and cleanup.
- Prefer provider CLI/API for pane input and capture.
  Reserve desktop-driving for terminal-host bindings, mouse/focus behavior, or visual-only evidence.
- Resolve the target extension, working directory, workflow, and success criteria.
  Ask one focused question only when ambiguity blocks testing.
- Start a fresh Pi with the target extension and default configured real model.
  Exclude unrelated extensions; load support resources only when the workflow needs them.
- Drive Pi as a user would: enter prompts and commands, press keys, wait for visible state changes, and inspect each resulting screen.
- Treat terminal and browser UI as product behavior.
  If the extension opens browser UI, use the appropriate browser-driving skill.
- Exercise the requested workflow plus relevant failure, cancellation, reload, and session behavior.
- Do not replace interactive observation with unit tests, session files, or the nested Pi agent's claims.
  Use those only for independent verification or when recording a harness limitation.
- Record defects with reproduction steps, expected behavior, actual behavior, severity, and evidence.
  Separate product defects from harness failures.
- Finish with `pass`, `issues found`, or `blocked`, followed by concise findings and terminal inspection or cleanup information.