/test — the user does the work

Follow PROTOCOL.md § "Test protocol" and § "Judge rubric". Compressed here:

Pick the problem. Priority: (1) the problem the user named — any curriculum problem, a topic ("quiz me on graphs" → weakest-KC test problem there), or an outside problem (custom); (2) the pair of the last /teach; (3) the recommender's pick in review mode. If a pair's test problem was already used, pick another curriculum problem covering the same KCs; only improvise a variant (custom) if none exists.

Set up the attempt file — code never goes in chat:

1. Run python3 scripts/scaffold.py <slug> --with-ref (add --lang js|java|cpp if the user prefers; ask once and remember via profile).
2. Author the checks per PROTOCOL.md § "Authoring checks": stated examples as case(...), edge cases from the checklist, brute-force oracle + generator in the _ref_ file, stress(...) last. Then machine-verify: run the checks against the reference and fix any expectation the reference disputes — the user never receives unexecuted expected values. Do NOT write solution code or hints in the attempt file itself (the brute force lives only in the _ref_ file).
3. Offer both ways to work, user's pick (remember it):
   • Workbench (GUI): python3 scripts/workbench.py — browser editor with a Run button over the attempt file (run it in the background so chat stays free).
   • Their own editor: open the file, run python3 <path> themselves. Either way: code there, run as often as they like, then say "done" (or "stuck") here.

Before they code: require the approach in words (iron rule 4) and probe complexity. If they want to skip straight to coding, remind them once that interviews grade the talking, then let them proceed and note it.

While they work: stay quiet. Hints only when asked — count every hint. "Stuck" gets a laddered hint (question → nudge → direction), never the answer.

When they say done:

1. Read the attempt file; run it if it's Python. Test results inform but do not decide verdicts — passing asserts with the wrong idea is still partial.
2. Judge each target KC by its signals from the topic file: demonstrated / partial / failed, every verdict citing what they said or wrote (file lines or their words).
3. Walk through their code: what earned each verdict, the clean solution where they diverged, complexity. If they failed on something spatial, a short stepper visual of the correct algorithm running on THEIR failing case (per PROTOCOL.md § Visuals) is the strongest possible debrief.
4. Write evidence to memory/.staging/evidence.json (type: "test", user_approach, user_code (the file contents), hints_used, approach_first), run python3 scripts/log_episode.py, show the deltas.
5. If this was the 3rd+ test since the last reflection, suggest /reflect.

On a phone? Skip the attempt file entirely and use PROTOCOL.md § "Phone-mode testing": approach in words, then fill-in-the-blank on the KC-bearing lines or "you drive, I type" dictation. Log with "mode": "mobile". For a full bite-sized session, /commute is the better shape.

Mis-graded something? python3 scripts/retract.py <episode-id> undoes it exactly — offer it if the user disputes a verdict and they're right.