The review prompt

A {{REVIEW_SUBJECT}}'s diff is below, with the brief it implemented. Its tests have already been run
and are green, so don't start by re-running them. The tests are scoped to this run and deliberately
blind to scope-of-work, so green tests do not prove the diff is either fully correct or complete —
correctness beyond the tests' coverage, and completeness, are both yours to judge.

{{EXTRA_JUDGMENT}}

Scoped plan files:
{{SCOPED_PLAN_FILES}}

You have three jobs.

**Improve safely.** Improve what you safely can with full judgment and taste — bias toward removal,
and don't "fix" what you don't understand the reason for. The bias toward removal covers tests: a
test this diff adds that pins authored wording or a hand-frozen count, depends on anything
machine-local (network, credentials, ambient environment, wall clock), or could not plausibly fail
is a defect of the diff — delete it rather than weaken it, and never demand a test for a change with
nothing mechanically checkable.
Never *silently* change a contract (a name, signature, or behavior) that later work relies on; when
such a change is right, make it and say so clearly, so the rest of the plan can be updated to match.
If you edit anything, run the tests yourself afterwards and leave them green — the tests being green
already is only true of the diff as handed to you.

**Judge scope.** Decide whether the diff actually *covers the brief*, or whether the task finished
only part of the scope. Check that everything the change made obsolete was removed. The brief covers
part of the run's source plan, and every requirement the source plan states about that part applies
in full. Compare the delivered work against that source plan and against how the plan's scope is
divided among the briefs: a requirement is unmet if it was delivered in reduced form, or if no brief
carries it. If scope is incomplete, choose `retry` only when the same brief should be re-executed.
If the brief asks for work that sibling briefs, later milestones, or other remaining run-plan files
own, the brief is defective; correct the scoped plan files identified in the run environment so each
piece of work has one owner. That correction is required when the scoped files make it expressible.
Rewriting a scoped brief and recording `complete` can be legitimate when the delivered work is
correct and the rewrite is the honest way to align remaining scope. Rewriting a brief so
delivered-but-wrong work passes is forbidden. You route the failure; do not edit code, tests,
acceptance checks, or run records to make an incomplete attempt pass.

When you route, use the run history in your environment section. Repeated failure on one brief is
evidence about the brief: if this task was already executed and rejected, repeating the same brief
needs a reason you can state — typically that the prior note named one specific gap, this diff closed
it, and the rest of the brief is plainly reachable in one more pass. Judge the whole brief each time,
not just what the previous review complained about:
successive attempts that each deliver a different fragment of the brief are the signature of a brief
asking for too many independent things — say so in your note and edit that brief where it is listed
above. A brief whose completion condition names work owned by sibling briefs or later milestones has
the same fault even before repeated attempts prove it. Your verdict is the convergence decision
unless the selected caller declares and consumes an attempt ceiling. An attempt ceiling is never a
reason to lower the bar: do not mark a final attempt `complete` to let the run proceed. When a caller
declares and consumes a ceiling, Gantry stops a task that cannot converge visibly and resumably.

Record the judgment in the declared outputs below — writing the verdict output is required, because
it is how gantry reads your judgment. Use exactly one of the verdict output's declared raw values,
with no TOML wrapper. When your verdict needs a note, write the note output too. Plan-file changes
are not a separate verdict: Gantry observes the scoped diff and routes it through the active
pattern's declared policy.

{{OUTPUTS}}

Brief:
{{BRIEF}}

Diff:
{{DIFF}}