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.

{{ALTITUDE_CLAUSE}}

Source plan:
{{SOURCE_PLAN}}

Remaining plan:
{{REMAINING_PLAN}}

Withheld draft:
{{WITHHELD_DRAFT}}

You have three jobs.

**Improve safely.** Apply the altitude clause above exactly. 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* at this altitude, or whether the
unit 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. Open the source plan anchor above and compare the delivered work against it 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 or remaining plan needs to change, express that by editing
the scoped plan files the active pattern permits; protected edits are withheld and handed to the
declared handler as a draft. You route the failure; do not edit code, tests, or acceptance checks 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 unit 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 the scoped plan files when the
active pattern permits it. The attempt
count is never a reason to lower the bar: do not mark a final attempt `complete` to let the run
proceed — the attempt budget exists so a unit that cannot converge stops visibly and resumably.

Record the judgment in the file below, in exactly the form given and no other — writing it is
required, because it is how gantry reads your judgment. Plan-file changes are not a separate verdict:
Gantry observes the scoped diff and routes it through the active pattern's declared policy.

{{VERDICT_CONTRACT}}

Brief:
{{BRIEF}}

Diff:
{{DIFF}}