#2781 gatorwalk-factory: review prompts define severity and scale to the change, so a small change doesn't loop on logistics findings

In the 2026-09-29 trial (work item cue-er7koww5, lifecycle ~/src/factory/lifecycles/cue.yaml, adapted from build-swamp-extension.yaml), plan review ran five rounds on a one-character change to a JS key regex. Rounds 2, 3 and 4 each raised one high finding, which triggered rework automatically. All three were about the plan's manual-verification logistics, not about a defect the code would ship. The plan grew from 2.3 KB and 4 steps to 6.8 KB and 7 steps, almost all of it test procedure. Code review then found 4 low findings. When the driver added a severity bar to the round-5 prompt, no high finding appeared.

Cause

• Severity is undefined. FINDINGS_SCHEMA is a bare enum (payload_schema.ts:556-582).
• The review prompt says "Record findings with severities; do not soften them", with no bar and no sense of proportion. That wording appears in lifecycles/build-swamp-extension.yaml:81-85 and in the review-plan template being removed in #2767. Every lifecycle adapted from them inherits it.
• A reviewer told not to soften, and given no bar, rates "your manual test cannot run" as high. Because rework is automatic on any high finding, each such finding costs a full round with no person involved.
• Round 1 went round even though nothing blocked. Seth wanted two medium and four low findings folded in, and the only way to do that was revise plus a full new adversarial review. Approving would already have carried the findings into implement, which injects plan-review, but nothing said so.

Fix

1. Severity rubric, in every bundled and example lifecycle's review prompts (plan and code review), and in the findings contract's description:

   • critical or high: the change would ship a defect, lose data, break a stated rule, or make the declared checks meaningless;
   • gaps in process, logistics or manual verification that the automated checks already cover: medium at most.

   Decision for the implementer: where the rubric lives so lifecycles share it. Options are a paragraph each prompt carries, a referenced doc, or the schema description. A lifecycle may tighten it; a security review is the obvious case.

2. Proportionality line in the same prompts: "Judge the plan against the size of the change. Do not ask for verification machinery bigger than the change. For each finding, say the smallest adequate fix." Keep "do not soften" for the severity of real defects, so the two don't contradict each other.

3. Approving carries the findings. At a plan approval stop where nothing blocks, the skill says that approving carries the open medium and low findings into implement, which already receives plan-review. revise is for when the person wants the plan itself changed and reviewed again. Document the pattern in the bundled lifecycles.

Done when

• build-swamp-extension.yaml, swamp-extensions.yaml and the lifecycles in examples/ (#2767) carry the rubric and the proportionality line in every review prompt. A test pins it, for example: each dispatch stage that records findings has a prompt containing the rubric marker.
• The skill's human-stop guidance says what approving does with non-blocking findings.
• Replaying the trial's round-2 plan (v2, in the trial's work-item data) against the new plan-review prompt yields no critical or high finding for PR2-1's "the hand check cannot run" issue. This is a manual check; record the outcome in the PR.

Related: the human-stop and churn-rule skill issue filed alongside this one, and #2776 (the driver rewrote reviewer prompts).