> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tiny-brain.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Adversarial review

> Every implementation commit gets challenged by an agent that wasn't in the room

The weakness of agent-written code isn't usually syntax — it's an agent
grading its own homework. tiny-brain's answer is structural: the moment a
`feat:` commit lands, a **separate review agent with an isolated context**
challenges the work. It didn't write the code, didn't see the conversation,
and has no investment in the approach.

## What the reviewer does

The reviewer reads the commit against the task it claims to implement and
attacks it: does the implementation cheat the tests? Does the code or its
docs overstate what actually exists? Is complexity hidden, is a claim
unsupported, did an unrelated change ride along? It then returns one of two
verdicts:

* **clean** — the cycle closes, the loop moves on.
* **needs-refactoring** — concrete findings, each with a suggested change.

Verdicts and findings are persisted per task and per commit, so the
dashboard (and any teammate) can see not just *that* a task passed review,
but what the reviewer objected to along the way.

## The refactor gate

Findings aren't advisory. The hooks only accept a `refactor:` commit while
a review is active, and a needs-refactoring verdict expects one — the
findings get addressed (or explicitly rebutted) before the task's cycle
closes. This is the REFACTOR stage of [the loop](/concepts/tdd-loop): driven
by a reviewer's findings, not by taste.

## Beyond adversarial: the wider pipeline

Adversarial review is the always-on gate (`enableAdversarial` in the repo's
tiny-brain config). Around it sits a configurable quality pipeline that can
include coverage analysis, mutation testing (`enableMutationTesting`),
security scanning (`enableSecurityScanning`), and repository-wide quality
runs — analyser passes plus specialist review agents (code quality,
security, performance, testing) whose scored results are written into the
repo under `docs/quality/`.

The principle across all of it: **the pipeline is the quality bar.** Agents
don't invent their own review standards per session — they run the gates the
repo has configured, and the gates leave a record.