Repository navigation
RLCR: Surface Enumeration Requirement and Partial-Fix Escalation for Cross-Cutting Criteria #193
Description
Context
Observations from an RLCR session (4 rounds, 6 acceptance criteria). Fully sanitized.
Core Pattern
One criterion involving cross-cutting behavioral changes (hiding content across multiple output surfaces) consumed 4 of 5 rounds despite being declared complete each time. The implementer fixed only reviewer-cited locations rather than performing exhaustive surface audits, creating a whack-a-mole cycle.
Suggestions
1. Require Surface Enumeration Before Implementation
For criteria that involve hiding/showing/transforming content across multiple output formats, require the implementer to produce a complete list of all affected rendering paths before writing code. Reviewer validates the list first.
2. Replace Premature Completion Claims with Confidence Levels
Instead of "Remaining Items: None", require confidence assessment: "High — all N surfaces verified" vs "Medium — verified plan-cited surfaces only". This creates honest reviewer signal.
3. Escalate After Two Partial-Fix Rounds
If the same criterion needs fixes in 3+ consecutive rounds, the reviewer should stop providing specific locations and instead require the implementer to submit a full audit. Breaks the reviewer-as-scoper dependency.
4. Strengthen Negative Testing Protocol
Require "assert X is absent from every output format" testing, not just presence checks. This would catch gaps the reviewer finds manually.
5. Tighten Plan Language for Cross-Cutting Concerns
AC descriptions for behavioral rules should explicitly enumerate every output surface, not use vague scope like "across outputs".
6. Enforce Recorded Lessons via Checklists
When a process lesson is recorded, convert it to a mandatory checklist item for subsequent summaries. Simply recording a lesson without enforcement is insufficient — demonstrated by a lesson in Round 2 failing to prevent gaps in Rounds 3-4.
Impact
Estimated 3 excess rounds (60% overhead) in a 5-round session. These suggestions could reduce similar cycles by 50-75%.
Activity
jhinpan commentedon Jun 16, 2026
Strong +1 from an independent RLCR session in a very different domain (GPU kernel optimization, ~8 build/review rounds). We hit your exact core pattern: a single change to a dispatch/compatibility surface produced three consecutive code-review rounds that each fixed one edge of the same bug class (an unexpected keyword form → an explicit-null keyword form → a positional-argument form). Your suggestions 1 (surface enumeration), 3 (escalate after two partial-fix rounds), 4 (negative-test the absence/all-forms), and 6 (enforce recorded lessons) would each have collapsed those three rounds into one.
Two concrete amplifications from the kernel-dispatch flavor of this:
We also saw three findings that I don't think are covered here or in the other open methodology issues; filing them as a separate focused issue and will cross-link. Thanks for writing this up clearly.