RLCR: Scope-challenge mechanism for review phase findings
Problem
In a completed 10-round RLCR loop, 6 rounds (60%) were spent on findings outside the plan's acceptance criteria. The implementer pushed back in one round—classifying two findings as pre-existing and out-of-scope with evidence—but the reviewer re-filed the same findings at lower severity the next round, effectively forcing implementation. The newly added code then generated cascading bug-fix rounds, delaying plan completion.
Concrete pattern observed
- Reviewer files P1 findings about code removed before the plan existed
- Implementer documents them as pre-existing, intentional decisions with commit evidence, queues them
- Reviewer re-files the same findings as P2, insisting on implementation
- Implementer capitulates and writes the compat code
- The compat code has edge-case bugs (flag syntax variants, file type routing, validation gaps, build integration)
- Each bug becomes a new review finding → 5 additional rounds
- Total: 1 scope dispute + 1 implementation round + 4 edge-case fix rounds = 6 rounds on out-of-plan work
The reviewer was correct that the findings were real—the old interface was indeed removed. But the plan explicitly excluded backward compatibility, and the project owner had intentionally made that decision. Forcing it back in created a costly detour.
Proposed Solution: Scope-Challenge Token
Add a lightweight mechanism that lets the implementer formally challenge a finding's scope without burning rounds on re-litigation.
Mechanism
When the implementer believes a finding falls outside all acceptance criteria in the plan, they respond with a scope challenge instead of a normal fix:
Challenge format (in the round summary):
## Scope Challenge: [Finding ID]
- Finding: [brief description]
- Outside ACs: [list which ACs it does NOT address]
- Evidence: [why it's out of scope: pre-existing decision, owner intent, separate module, etc.]
- Impact if deferred: [honest assessment]
Resolution rules
-
One challenge per finding per round. The implementer can challenge multiple findings but each gets its own block.
-
Reviewer must respond to the challenge explicitly in the next review:
- ACCEPT: Finding is permanently queued. It cannot be re-filed in future rounds (even at different severity).
- REJECT with escalation: Reviewer argues the finding IS in scope by citing specific AC(s). The finding is then treated as mainline.
- REJECT with amendment proposal: Reviewer acknowledges it's out of scope but argues it's important enough to amend the plan. This triggers a single plan-amendment round where ACs are updated. After that, the work proceeds under the amended plan.
-
No re-filing at lower severity. A finding that was challenged and accepted as queued cannot reappear as P1, P2, or any severity in later rounds. This closes the loophole.
-
If the implementer capitulates without challenging, the review loop proceeds normally—but the implementer should document in the round contract that new code is being added outside the plan scope.
When NOT to use
- When the finding addresses a plan AC, even tangentially → fix it
- When the implementer is unsure → ask the reviewer to clarify which AC it addresses
- When the finding is a real regression in the plan's work → fix it immediately
Expected impact
In the observed 10-round loop, a scope-challenge mechanism would have:
- Resolved the legacy compat dispute in 1 round (challenge → reviewer response)
- Saved 5 rounds (the implementation round + 4 edge-case fix rounds)
- Reduced total from 10 rounds to ~5 rounds without sacrificing quality on the plan's actual objectives
Comparison to alternatives
| Approach |
Rounds saved |
Risk |
| Scope-challenge token (proposed) |
5 |
Low—requires reviewer agreement |
| Hard scope lock (no out-of-plan fixes allowed) |
5 |
Medium—blocks legitimate peripheral fixes |
| Implementer veto power |
5 |
High—reviewer loses ability to enforce quality |
| Current state (no mechanism) |
0 |
Current: scope drift wastes rounds |
The scope-challenge occupies a middle ground: it doesn't give the implementer unilateral power (reviewer can escalate or amend), but it forces an explicit, one-round resolution instead of multi-round attrition.
RLCR: Scope-challenge mechanism for review phase findings
Problem
In a completed 10-round RLCR loop, 6 rounds (60%) were spent on findings outside the plan's acceptance criteria. The implementer pushed back in one round—classifying two findings as pre-existing and out-of-scope with evidence—but the reviewer re-filed the same findings at lower severity the next round, effectively forcing implementation. The newly added code then generated cascading bug-fix rounds, delaying plan completion.
Concrete pattern observed
The reviewer was correct that the findings were real—the old interface was indeed removed. But the plan explicitly excluded backward compatibility, and the project owner had intentionally made that decision. Forcing it back in created a costly detour.
Proposed Solution: Scope-Challenge Token
Add a lightweight mechanism that lets the implementer formally challenge a finding's scope without burning rounds on re-litigation.
Mechanism
When the implementer believes a finding falls outside all acceptance criteria in the plan, they respond with a scope challenge instead of a normal fix:
Challenge format (in the round summary):
Resolution rules
One challenge per finding per round. The implementer can challenge multiple findings but each gets its own block.
Reviewer must respond to the challenge explicitly in the next review:
No re-filing at lower severity. A finding that was challenged and accepted as queued cannot reappear as P1, P2, or any severity in later rounds. This closes the loophole.
If the implementer capitulates without challenging, the review loop proceeds normally—but the implementer should document in the round contract that new code is being added outside the plan scope.
When NOT to use
Expected impact
In the observed 10-round loop, a scope-challenge mechanism would have:
Comparison to alternatives
The scope-challenge occupies a middle ground: it doesn't give the implementer unilateral power (reviewer can escalate or amend), but it forces an explicit, one-round resolution instead of multi-round attrition.