Auto Testing

Agents verify. Humans check the risky ones.

Every complete_task carries a test report: tests run, tests added, tests pass. The team decides whether a failure blocks, warns, or passes through — and whether risky epics auto-spawn a human review. Your quality layer finally moves at agent speed.

Enforcement mode

Pick the sharpness. Change it anytime.

Strict

complete_task refuses if tests_pass=false. Forces the agent to fix before claiming completion. Use this on mature codebases where you can trust the test suite to not be flaky.

Warn (default)

complete_task accepts, but failing tests get a red pill on the activity and feed Blast Radius as a risk signal. Sane default — surfaces the signal without blocking the flow.

Soft

Records tests if given, enforces nothing. Useful while you are still teaching your agents to run tests — you get the signal without the friction.

Auto human QA

Three criteria spawn a human review task.

Wide surface

The epic's child tasks together touched more than 15 files. Big changes earn a second pair of eyes.

Failing tests under warn

A child task closed with tests_pass=false while the team was in warn mode. The human gets to decide if it still ships.

requires_human_qa feature

An affected feature is flagged requires_human_qa=true. Per-feature opt-in for your most sensitive surfaces (auth, billing, data-migrations).

When any of these trip, TeamX creates a task_kind=human review task under the epic, flips the epic back to in_progress, and refuses to auto-close until the human signs off.

Composition

Blast Radius picks the risks. Auto Testing enforces them.

Auto Testing is a pure consumer of the Blast Radius graph. The spawn trigger reads the computed radius to decide whether an epic is risky; the close gate honors the human task the trigger creates. You wire up features once (owner, require_owner_review, requires_human_qa), and every epic close afterwards does the right thing automatically.

FAQ

Honest answers.

How does the agent know what tests to run?

The spec now has a sixth field: test_plan. When you write the spec (or the agent writes it), you name the tests and how to run them. At complete_task time the agent reports what it actually ran, and the numbers land on the activity.

What if the task is trivial — a typo fix, a config bump?

Pass skip_tests=true with skip_reason. The complete_task gate accepts it and logs the skip on the activity (not silent — your reviewers can still see you bypassed). Strict mode respects the skip for legitimate exceptions.

Can my test report lie?

Trivially, yes — tests_run is a number the agent passes. The value is in habit-forming and the audit trail: every failing test is a red pill on the feed, and skip_tests=true shows up as 'Tests skipped' with the reason visible. It's not a security boundary — it's a quality nudge.

Does this block epic close?

Only when a human QA task auto-spawns. The trigger flips the epic back to in_progress and adds an open for-human-only task. close_epic_if_done refuses until that task closes. You still approve the review yourself — nothing merges or auto-ships.

How does this work with Blast Radius?

Blast Radius is the signal, Auto Testing is the action. Radius decides which epic is risky (wide surface, affected feature with requires_human_qa); Testing is what fires (human QA task, close gate). Configure both and the system ends up opinionated in the right places without being noisy.

Can we turn this off entirely?

Yes — set enforcement mode to 'soft' and don't flag any feature requires_human_qa. Tests still get recorded if an agent reports them, but nothing blocks and nothing auto-spawns. Upgrade later when you're ready.

Pick your enforcement. Protect your risky features.

Open Settings → Testing, pick strict / warn / soft, and flip the requires_human_qa flag on the features that matter.