The exploit-probe QA tab now carries a Run probe now button — capture the probe spec inline, POST to the existing route, and watch the new result row land without leaving the page.
Run the Probe From the QA Tab
The exploit-probe QA tab shipped last week with a small honesty caveat: the only way to populate stage 3 (the adversarial exploit probe) was from CI or the SDK, by POSTing to /scoring/exploit-probe/run. The QA tab read the results just fine; it just couldn't kick off a new run. Authors iterating on their assertions had to bounce out of the page, commit a change to a CI config, push, wait, and come back.
This follow-up closes that loop.
What it is
On the QA tab's stage-3 detail panel, there's now a small ghost button: Run probe now. Click it and the panel expands inline with a form that captures exactly what the backend's ExploitProbeRunIn Pydantic body requires:
- Trajectory name — the per-row identifier the probe groups results under.
- Prompt — the user-facing prompt the bad-actor agent receives.
- Context — a JSON object the agent reads from.
- Accept patterns — a comma-separated list of substrings. The probe assertion returns true if any pattern appears in the bad-actor output — i.e. your grader would have accepted garbage.
- Strategies — an optional subset of the 6 default attack strategies (
no_op,empty_dict,literal_truthy,numeric_zero,echo_question,mass_dump). Leave them all unchecked to use all six. - Notes — free-form context for future readers.
Hit Run probe, and the form POSTs to the route the CI hook has been using since 2026-05-21. On success, the form collapses, state resets, and the QA tab re-fetches — the new probe row appears in the panel below, expanded inline like every other row.
What it isn't
It isn't a modal. It isn't a new tab. It isn't a settings page. The form lives inside the same QA tab the author was already on; nothing else moved. Cancel restores the empty state with one click.
Where it fits
This is one of four A3 follow-ups tracked in UNBUILT-FEATURES.md. The other three (per-row stage_1_passed / stage_2_passed backend, typed dataset_id column + 90-day author-only window, "Tighten assertion" jump from the QA tab to the row editor) remain in flight. None of them block this one.
For SMEs iterating on assertion tightness, that's the whole loop closed: read the failure, tighten the assertion in the dataset row, re-run the probe, watch stage 3 go green.