Skip to content

RLCR Methodology: Severity-based phase termination and transitive fix directives #164

@mockiemochi

Description

@mockiemochi

Context

12-round RLCR session (5 new tasks, 8 ACs). Structured review phase (rounds 0-4) caught critical issues effectively. Code review phase (rounds 5-11) produced valid but diminishing-severity findings. Session could have safely terminated 5 rounds earlier.

Findings

F1: Two-Phase Review Mode Not Formalized

Sessions naturally divide into structured AC review → diff-based code review, but the methodology doesn't formalize this transition. Post-AC-completion rounds continued cycling on P3 findings with diminishing returns.

F2: Cascading Fixes From Single Root Cause (3 rounds)

Incorrect seeded data produced findings across 3 consecutive rounds because neither reviewer nor implementer performed a transitive search for all references to the same data.

F3: Schema Migration Not Pre-Planned

3 rounds spent on migration issues that should have been a plan-level checklist item.

Recommendations

M1: Define Hardening Phase Bound [High]

After structured review declares all ACs met, enter a hardening phase with max 3 rounds. Terminate when 2 consecutive rounds produce no P0/P1 findings.

M2: Require Transitive Fix Directives [High]

When review finds incorrect data, the directive must enumerate ALL locations where the same data appears. Fix all in one round, not piecemeal.

M3: Pre-Plan Schema Migration Requirements [Medium]

Plans that modify existing service schemas must include an explicit checklist item for idempotent migration statements.

M4: Pre-Classify Validation Activities [Medium]

Tag each validation activity as "per-round" or "pre-completion" to prevent deferring full-pipeline testing.

M5: Expand Validation Centralization Scope [Low]

When review finds a validation bypass, require auditing ALL code paths that write the same data, not just the specific path found.

M6: Lower BitLesson Extraction Threshold [Low]

Generate lessons for any fix requiring multi-file interaction understanding, even if the pattern isn't novel.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions