<!-- Terminal verification is ENABLED for this project. -->

## Terminal Mode (when `terminal.verifyPatterns` matches an edited file)

> **Precondition: the change must actually have terminal-observable behavior.** If the edited code is not reachable from a CLI / REPL / shell / full-screen TUI, this section does NOT apply — `MCP:tdt_*` tools drive a program through a PTY. Just do browser verification.

If the project has terminal verification enabled (`ironbee terminal enable` once at setup) and your edits touch matching paths, the stop hook also enforces a terminal cycle. The same `verification-start` covers both cycles; one platform-agnostic verdict covers both.

### Mode behavior (terminal cycle)
- **default** (no arg or `default`): exercise only the CLI flows / commands your diff touched.
- **full**: exercise every CLI command / flow reachable from files matching `terminal.verifyPatterns`.
- `visual` / `functional`: browser-only modes; terminal cycle behaves as `default` when they are passed.

### Steps (run within step 3 of the Universal steps above)
1. **Pick an evidence path** for the changed code:
   - **Run-evidence** (a one-shot command proves the change works): `MCP:tdt_pty_run` with the command line — it returns the full output AND the exit code in one call. Confirm the output is what the change should produce AND the exit code is expected (`0` for success, or the specific non-zero code an error/flag path returns). A command that prints the right text but exits non-zero is a fail.
   - **Interactive-evidence** (driving a REPL / shell / full-screen TUI proves the change is live):
     - Spawn the program: `MCP:tdt_pty_start` → returns a `paneId`.
     - Drive input: `MCP:tdt_interaction_send-keys` (tmux key syntax — `Enter`, `C-c`, `Up`, `Tab`) or `MCP:tdt_interaction_send-text` (literal text).
     - **Synchronize, don't guess delays**: `MCP:tdt_sync_wait-for` blocks until the expected output appears.
     - Capture: `MCP:tdt_content_capture` — `mode: stream` for line-oriented programs (REPLs, shells; pass an incremental `since` cursor to read only new lines), `mode: screen` for full-screen TUIs (rendered screen buffer). Confirm it shows the expected result.
     - Stop the pane: `MCP:tdt_pty_stop`.
     - Auxiliary (NOT gate evidence): `MCP:tdt_sync_wait-for-idle` waits until output stops changing; `MCP:tdt_content_get-cursor` reports cursor position; `MCP:tdt_pty_resize` / `MCP:tdt_pty_signal` / `MCP:tdt_pty_list` manage panes.
2. **Submit verdict** — platform-agnostic, just status + checks (+ issues/fixes).

### Verdict (platform-agnostic)
```json
{
  "session_id": "...",
  "status": "pass",
  "checks": ["`mycli --json` emits valid JSON and exits 0", "REPL `:help` lists the new command"]
}
```

For a multi-cycle pass, both browser and terminal pass criteria must hold.

---

## Default Mode (terminal cycle)

Focus on the CLI flows or commands your diff touched — not the entire program.

### 1. Study the changes
1. Run `git diff --name-only` and `git diff --name-only HEAD~1`
2. **Ignore `.ironbee/`, `.claude/`, `.cursor/`** — tool config, not application code
3. **Read the full diff** for every terminal-facing file in scope — note new commands, changed flags / args, new output formats, changed exit codes, new REPL / TUI states
4. Before running, identify: which command / subcommand / REPL state is affected? Which invocation exercises it? What output and exit code should it now produce?

### 2. Verify in a PTY
- **Run-evidence**: run the affected command via `MCP:tdt_pty_run` — confirm the output matches the change AND the exit code is correct
- **Interactive-evidence**: spawn the program, drive the affected flow with `send-keys` / `send-text`, `wait-for` the expected output, then capture it — the captured output must show the expected result after your change

---

## Full Mode (`/ironbee-verify full`, terminal cycle)

Verify every CLI command / flow reachable from files matching `terminal.verifyPatterns`, not just the changed files. Do NOT run `git diff` or scope to recent changes.

- Run every command / subcommand in scope
- Exercise at least one happy-path invocation AND one error-path invocation (bad flag / missing arg) per command, confirming both output and exit code
- For REPL / TUI surfaces, drive each affected state and capture the rendered output