subagent-driven-development: "no second fix wave" should not cover breakage the final fix wave itself introduced

• I searched existing issues and this has not been proposed before

What problem does this solve?

The final whole-branch review asked for an additional protection layer (block an admin path from outside the local network). The one allowed fix wave implemented it as a raw-path prefix check. The scoped re-review probed it and found a bypass: /%61dmin/login returned 200 — a new Important security finding that only the fix wave had created. The skill says: exactly one scoped re-review, no second fix wave, residual findings go to the human at finish. Right before a public deploy, that means knowingly presenting an open bypass as the result. I ruled a targeted second fix plus a second scoped re-review (two small subagent rounds); the fix matched on the router's resolved route instead of the raw path.

Both security gaps found in that run (host-header case sensitivity, an encoded path) were found only by reviewers that actively probed with requests, not by reading the diff.

Proposed solution

In Final Review, distinguish two kinds of residual findings after the scoped re-review:

• findings that already existed before the fix wave → unchanged: park or rule, surface at finish;
• Critical/Important breakage introduced by the fix wave itself → exactly one targeted fix by the same fixer plus one scoped re-review before anything is merged or deployed; if that still fails, stop and surface.

Additionally, when the reviewed change is a security layer (path filter, auth guard, rate limit), the review and re-review briefs ask for bypass probes executed against the running code (an in-process request injector, or curl --path-as-is), not only diff reading.

What alternatives did you consider?

Treating it as a normal residual and surfacing it: acceptable for an unreleased branch, wrong when the plan ends in a deploy — the cap protects against endless polishing, not against a regression the last round built in. Unlimited fix waves: rejected, the cost argument already in the skill is sound.

Is this appropriate for core Superpowers?

Yes; it concerns the generic final-review loop, not a stack.

Environment (required)

Field	Value
Superpowers version	observed on 6.3.0; the gap is still present on dev as of 2026-10-01
Harness (Claude Code, Cursor, etc.)	Claude Code (desktop app, Code tab)
Harness version	2.1.272
Your model + version	Claude Opus 5.5 (claude-opus-5-5)
All plugins installed	superpowers, task-observer, claude-mem, context7, plus private skill plugins unrelated to this area
OS + shell	Windows 11, Git Bash

Context

A companion proposal for plan verification steps (adversarial probes for security boundaries in writing-plans) is filed separately: #2432.