RLCR: Fix-revert oscillation and unbounded quality polishing phase in 19-round session

[zevorn]

Context

A 19-round RLCR session (cancelled by user) exhibited a sharp two-phase efficiency split: Rounds 0-3 completed a full AC lifecycle (implementation through acceptance) at high efficiency, while Rounds 4-18 consumed 15 rounds on code robustness fixes with sharply diminishing returns. The most damaging pattern was an 8-round fix-revert oscillation in a single subsystem's thread lifecycle management.

This extends the observations in #54 (whack-a-mole pattern) with concrete oscillation data and proposes specific circuit-breaker improvements.

Observations

1. Two-phase efficiency divergence: Rounds 0-3 achieved ~0.25 AC/round (1 AC fully verified in 4 rounds). Rounds 4-18 achieved 0 new ACs in 15 rounds, all spent on robustness hardening. The marginal value of each subsequent round dropped precipitously.

2. 8-round fix-revert oscillation (Rounds 9-17): In a single subsystem's resource lifecycle:

   • Round 4: Added resource cleanup → Round 9: Reverted due to use-after-free
   • Round 12: Added handle reclamation → Round 13: Reverted due to double-delete
   • Round 12: Added handle storage elsewhere → Round 14: Reverted due to stale handle
   • Round 15: Re-added handle reclamation with wait → Retained
   • Round 16: Added state check → Round 17: Replaced with volatile flag

   Root cause: Each fix only addressed the single symptom the reviewer identified, without designing the complete ownership model. The RLCR per-round fix cycle degrades into "whack-a-mole" when facing cross-cutting design concerns.

3. Review scope expanded unboundedly: Round 4 reviews began with "verify no regressions from this change" and gradually expanded to "find any potential issue in the codebase related to this refactoring." Pre-existing defects and migration gaps were surfaced alongside genuine regressions, turning the review phase into an open-ended code audit.

4. Reviewer lacked "acceptable risk" semantics: In 15 review rounds, the reviewer never judged "current state is good enough; remaining issues can be documented as known limitations." Even a 20-byte one-time memory leak (explicitly marked "acceptable" by the implementer in Round 13) was re-raised in subsequent rounds.

5. Communication quality degraded with diminishing returns: Round 0-3 summaries and reviews were structured, evidence-rich documents. After Round 10, summaries shrank to under 30 lines and reviews to single-issue descriptions, reflecting the declining marginal value of each round.

Suggested Improvements

#	Suggestion	Mechanism
1	Add oscillation detection circuit breaker	When the same subsystem has fix-revert cycles exceeding 2 occurrences within N rounds, force a "design discussion round" — implementer proposes a complete design, reviewer evaluates feasibility, both agree before coding resumes.
2	Separate "acceptance convergence" from "quality polishing"	After an AC passes acceptance, subsequent review rounds should have explicit exit conditions (e.g., 2 consecutive rounds with no P1 findings = polishing complete).
3	Bound review scope to change-introduced issues	Review phase should only cover regressions and direct risks from the current change. Pre-existing issues should be logged to a separate issue tracker, not added to the RLCR round's fix list.
4	Add issue severity threshold for auto-convergence	When all remaining issues are P3 or lower, trigger an automatic convergence decision rather than continuing the loop.
5	Allow "accepted risk" declarations that persist	If the implementer marks an issue as "acceptable" with justification and the reviewer agrees, it should not reappear in future rounds. Add an "Accepted Risks" section to the goal tracker.

Quantitative Summary

Metric	Value
Total rounds	19
Exit reason	User cancelled
ACs completed	1 (AC-7, verified Round 3)
Implementation phase (Rounds 0-3)	4 rounds, 1 AC completed — efficient
Polishing phase (Rounds 4-18)	15 rounds, 0 new ACs — diminishing returns
Fix-revert oscillation rounds	8 (Rounds 9-17, same subsystem)
Reviewer false positive rate	0%
Estimated waste from oscillation	6-7 rounds (with design-first at Round 10)