Ask the agent that wrote a change to review it, and it will mostly agree with itself. It remembers what it meant to write, and it reads that.
Wayari never asks. The reviewer is never the author, and the code refuses a sign-off from anyone listed among the authors of the work.
01a seat that reads and never edits
Since 0.5.0, a reviewer reads every channel once its gate goes green. It works at the exact commit the gate passed, so it reads what was checked.
The reviewer is a read-only shift, staffed from outside the channel's authors. Its brief tells it that it reads this change and does not edit it.
The brief leaves one thing out on purpose: that tests must pass. A reviewer told that runs the suite, fixes what it finds, and its whole review is lost.
It runs on the lead's model, inside 30 minutes, and inside $2 when you pay by the API. A repository can name its own reviewer model in package.json.
If the reviewer goes silent, Wayari stops it once and never restarts it. The pull request still opens ready.
02findings pinned to a line
The reviewer does not write an essay about the change. It writes findings, one at a time, each pinned to a file and a line:
wayari finding <path>:<line> "<headline>" --scenario "..." --severity blocking
A finding names the scenario in which the code goes wrong. Its severity is blocking, should-fix or note.
wayari review prints the findings under "What the reviewer found". A quiet review says found nothing. A review that never ran says so, with the reason.
It never prints a verdict. You get what was found and where, and the decision stays with you.
03on the pull request, where you read
Blocking and should-fix findings that name a line go onto the pull request as inline comments, each starting Wayari review:. A note stays in the pull request's body.
When a later commit fixes a finding, Wayari replies once with that commit and resolves the thread. A repository can turn the comments off in its package.json.
04what was asked, and what changed anyway
Two more reads sit beside the reviewer's. The first checks every sentence of the goal against the diff.
Only a sentence that names a path or a file can be checked that way. Every other sentence is listed as needing your look.
That list stays hidden until the diff is settled. A builder cannot read which of its claims are unanswered and then declare itself done.
The second is the behaviour diff. It compares five things at the channel's base and at its head:
- the help text
- the
--jsonshapes - the declared checks
- the skills
- the MCP tools
Those are the changes nobody reads a diff for.
If the base cannot be checked out, the behaviour diff says cannot compare. It never shows a clean result it did not take.
05prove it, then keep it
A repository can ask for an adversarial review by naming wayari.review.proof in its package.json. The reviewer then has to prove a finding with a new test.
Wayari runs that test twice. It prints the test as proof only when it breaks the same way both times.
A finding that gets fixed becomes a review rule. Wayari promotes it to a skill under .claude/skills/on-review-<name>/, and the next reviewer on that repository runs it.
A blocking finding also holds a merge grant. While one stands, Wayari will not merge that pull request overnight, whatever the gate says.
