Skip to content

RLCR Methodology: Post-acceptance review gap and evidence-quality spiral #138

@mockiemochi

Description

@mockiemochi

Context

An RLCR session analyzing the methodology itself identified several improvement opportunities. These are presented as patterns observed across a completed session, with concrete suggestions.


1. Post-Acceptance Review Gap

Pattern: Acceptance criteria were declared met, but 11 subsequent correction rounds were needed for runtime correctness issues (restart behavior, resource lifecycle, auth boundaries, cross-app isolation).

Suggestion: Add a mandatory "runtime edge-case review" phase after acceptance criteria are met, focused on:

  • Container restart / retry behavior
  • Socket / thread / file descriptor lifecycle
  • Authentication boundary completeness
  • Cross-app data isolation

2. Evidence-Quality Spiral

Pattern: Three rounds were consumed trying to produce acceptable parity evidence because each round's evidence was incomplete (wrong config, stale artifacts, non-clean trials).

Suggestion: Add an "evidence quality checklist" to acceptance criteria. Before claiming any AC is met, the implementer must self-certify:

  • All trials use identical model/config
  • All trials have clean exit (no agent/verifier errors)
  • Evidence is in a dedicated directory, not scattered across historical runs
  • A reproducible script can regenerate the evidence table from raw artifacts
  • No backfilling from older runs without explicit justification

3. Diminishing Returns in Late Review Rounds

Pattern: Late review rounds each found only 1-2 narrowly scoped issues, suggesting the review scope should have been consolidated.

Suggestion: Implement thematic review rounds (e.g., one round for auth, one for network lifecycle, one for data integrity) or reviewer rotation to catch different blind spots in a single focused pass.


4. Plan Compliance Drift

Pattern: Some plan tasks were executed out of sequence or skipped until caught by review.

Suggestion: Add a "plan compliance checkpoint" before claiming completion, verifying: every task executed, every AC verified by its specified method, no out-of-sequence execution without documented rationale, and every deferred item has justification + revisit trigger.


5. Round Budget Escalation

Pattern: 19 rounds for a single stage suggests poor initial estimation and a "just one more round" trap.

Suggestion: Implement a round budget with escalation triggers. After 2 consecutive rejections for the same AC, reset and reassess the approach rather than continuing incremental fixes.


6. Summary Validation

Pattern: Round summaries contained placeholder text and unsubstantiated claims.

Suggestion: Add summary validation rules to the round contract: no placeholder text, every completion claim references verifiable evidence, and external-state claims include reviewer-verification instructions.

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