The situation

A release is two days out. The invitation model changed last sprint: one user can now belong to several workspaces. Nobody has a list of which of the 1,400 approved cases still describe the product, which need new steps, and which should be executed before the release ships.

What the agent does

  1. Calls get_project_rules, then smart_search_cases with the behaviour rather than the ticket title, and reads every candidate in full.
  2. Writes a changeset into a draft, not into the vault: cases to update, cases to add, cases whose intent stays untouched.
  3. Waits. The QA Engineer edits the draft, rejects two proposals, approves the rest.
  4. Applies the approved changeset with update_test_case, create_test_case and bulk_update_test_cases, and saves the same selection as a run template with create_run_template.
  5. Seeds the release run from that template with create_test_run. Cases that have a linked Playwright spec are executed and recorded with bulk_record_results; the rest are left pending for people.

What the human reviews

One run. Every result carries an immutable snapshot of the case as it was when it was executed, so a later edit to the case cannot rewrite history. get_run_statistics shows what passed, what failed, and what is still waiting for a human—the same numbers whether the result came from a person or an agent.

Why it works

The run is not a separate artefact the agent invents at the end. It is the reviewed changeset, executed. Because selection, approval and execution all point at the same approved cases, the release evidence is traceable back to the spec change that caused it.

The instrument below walks the five stages: find, stage, review, apply, run.