# Step 4: Testing

Display: `Orientation → Walkthrough → Detail Pass → [Testing]`

## RULES

- Every code reference uses clickable `path:line` format per the standing rule.
- **Front-load then shut up.** Present all suggestions in a single message. Do not drip-feed.
- This is **experiential**, not analytical. The detail pass asked "did you think about X?" — this says "you could see X with your own eyes."
- Do not prescribe. The human decides whether observing the behavior is worth their time. Frame suggestions as options, not obligations.
- Do not duplicate CI, test suites, or automated checks. Assume those exist and work. This is about manual observation — the kind of confidence-building no automated test provides.
- If the change has no user-visible behavior, say so explicitly. Do not invent observations.

## IDENTIFY OBSERVABLE BEHAVIOR

Scan the diff and spec for changes that produce behavior a human could directly observe. Categories to look for:

- **UI changes** — new screens, modified layouts, changed interactions, error states
- **CLI/terminal output** — new commands, changed output, new flags or options
- **API responses** — new endpoints, changed payloads, different status codes
- **State changes** — database records, file system artifacts, config effects
- **Error paths** — bad input, missing dependencies, edge conditions

For each observable behavior, determine:

1. **What to do** — the specific action (command to run, button to click, request to send)
2. **What to expect** — the observable result that confirms the change works
3. **Why bother** — one phrase connecting this observation to the change's intent (omit if obvious from context)

Target 2–5 suggestions for a typical change. If more than 5 qualify, prioritize by how much confidence the observation provides relative to effort. A change with zero observable behavior is fine — do not pad with trivial observations.

## PRESENT

Output as a single message:

```
Orientation → Walkthrough → Detail Pass → [Testing]
```

Then the testing suggestions using this format:

```
### How to See It Working

**{Brief description}**
Do: {specific action}
Expect: {observable result}

**{Brief description}**
Do: {specific action}
Expect: {observable result}
```

Include code blocks for commands or requests where helpful.

If the change has no observable behavior, replace the suggestions with:

```
### How to See It Working

This change is internal — no user-visible behavior to observe. The diff and tests tell the full story.
```

### Closing

End the message with:

```
---

You've seen the change and how to verify it. From here:
- **"I've seen enough"** — we wrap up this {change_type}
- or just ask anything
```

**Do NOT speak again until the human responds.**

## WRAP-UP

When the human says "I've seen enough" or signals they're done:

```
---

Review complete. What's the call on this {change_type}?
- **Approve** — ship it
- **Request changes** — I'll help draft feedback
- **Discuss** — something's still on your mind
```

Act on their decision:

- **Approve**: Acknowledge briefly. If reviewing a PR, offer to approve via `gh pr review --approve` — but confirm with the human before executing, since this is a visible action on a shared resource.
- **Request changes**: Ask what needs changing. Help draft specific, actionable feedback tied to `path:line` locations.
- **Discuss**: Open conversation — answer questions, explore concerns, dig into any aspect.
