Skip to content

RLCR methodology: 10 improvement suggestions from a 43-round session #148

@Leopold-Fitz-AI

Description

@Leopold-Fitz-AI

Context

A recent RLCR session ran 43 rounds against a 42-round target. The plan had 12 acceptance criteria across 6 dependency-ordered gates and 19 numbered tasks. The loop converged (12/12 ACs met, code review passed) but consumed roughly 1.7× the planned round budget. A sanitized methodology audit of the round summaries and review results surfaced 10 improvement suggestions.

Top three findings

  1. Goal-alignment review was blind to correctness defects. The implementation phase ended at 12/12 ACs accepted, then the review phase produced 11 more rounds of P2/P3 correctness fixes (silent fallbacks, missing canonicalization, mismatched contracts, dropped state on overwrite, bypassed validators). Implementation-phase review systematically missed runtime-correctness defects.

  2. Isolated-subsystem-without-wiring rejections. At least 4 gates required 2 rounds: round N delivered a helper / data class / manager, round N+1 wired it into the production path. Grepping for production call sites was a recurring reviewer probe.

  3. Lateral drift on the same blocker. "ADVANCED / REQUEST_CHANGES" appeared 31 times in 32 implementation rounds. Several stretches of 3-4 consecutive rounds had the AC counter unchanged while rejection reasons drifted laterally.

Suggestions

  1. Run two parallel reviewer passes per round. Implementation reviewer asks "is the AC met?"; code reviewer asks adversarially "what could be wrong on plausible inputs?" Either's REQUEST_CHANGES blocks acceptance.

  2. Mandate a production-wiring proof in every round contract for any AC that names a production entry point: a search probe showing the new symbol has a production call site, plus a regression test driving the production entry (not the helper directly).

  3. Pre-flight a "definition of done" against the plan, not just the round contract. Round contracts must include a "Plan clauses in scope" section quoting the plan; reviewers audit against the plan, not the contract.

  4. Replace binary STALLED/ADVANCED with a 0–4 throughput score per round. Trip a stagnation alert when the rolling sum stalls.

  5. Stagnation trigger after 2 stagnant rounds: implementer must run every reviewer probe from the previous 2 rejections and commit outputs before writing new code. Escalate after 3 stagnant rounds (different reviewer model or written counter-argument).

  6. Cap the review phase by triage, not round count. Exit when 2 consecutive rounds yield zero P2+ findings AND no new defects introduced.

  7. Constrain round scope to limit defect introduction. Each review-phase round bounds modified files; reviewer rejects out-of-scope diffs without justification.

  8. Front-load infrastructure rounds for multi-gate plans: terminology lint, canonical identity scheme, fixture/replay regen scripts checked in early.

  9. Reviewer-write-only goal tracker. Implementer marks `claude-completed-pending-review`; only the reviewer transitions to `completed-and-verified`.

  10. 5-line blocker delta header on every round summary. Closed / open / new blockers. Reviewer anchors audit on this delta first.

Estimated impact

Suggestion 1 (decouple structural from correctness review) alone would have caught most of the 11 review-phase rounds inline, eliminating ~25% of total round count. Suggestions 2 and 4 together address the bulk of the lateral-drift cost.

The full sanitized analysis report is local to the originating session and is not attached here per the methodology audit's sanitization rules. The 10 patterns above are project-agnostic and reflect general RLCR loop dynamics for multi-gate plans.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions