Context
Feedback from a completed RLCR session (19 rounds, exited complete, all acceptance criteria met). The methodology worked well — no goal drift, no forgotten items, accurate goal tracking, high review true-positive rate, clear summaries/reviews/contracts. The following are refinements that could improve round economy by an estimated 15–25% for sessions of similar complexity. All observations are generalized; no project specifics included.
Observed patterns & suggestions
1. Incremental blocker revelation → multi-round single-subtask corrections
A single subtask sometimes took several consecutive rounds because each review surfaced one layer of blockers at a time.
Suggestion: Correction-round reviews should commit to being exhaustive ("all remaining blockers for this subtask are listed below") and sweep known subtask dimensions even when no primary blocker exists in them.
2. Premature completion claims
Tasks were claimed complete when self-validation covered implemented scope but not the acceptance criterion's actual verification surface (e.g., end-to-end typed paths, all operating modes, canonical tooling).
Suggestion: Each round contract carries a per-criterion verification checklist mapping every acceptance criterion to a named verification method and passing evidence; unverifiable items are explicitly flagged and carried forward.
3. Cross-field invariants caught late
A semantic inconsistency across derived fields survived several reviews because tests asserted per-field correctness but not the cross-field invariant.
Suggestion: For subsystems handling multiple external protocol variants, enumerate expected cross-field invariants in the contract and require at least one end-to-end invariant test per variant; add an "invariant coverage" review step.
4. Canonical-path vs. equivalent-path validation
An operational criterion was validated with a custom equivalent script rather than the canonical tool, which had its own guards the custom path didn't exercise.
Suggestion: Operational acceptance criteria (migrations, deployment, bootstrap) should name the authoritative tool/path; contracts prohibit substituting a non-canonical equivalent unless the canonical path is genuinely unavailable (documented).
5. Two-state task completion
A "complete (pending verification)" state created transient tracker inconsistency that needed manual correction.
Suggestion: Use distinct "implemented" vs "verified" states; the reviewer owns the implemented → verified transition. No task is "verified" before reviewer confirmation.
6. Subtask-dimension checklists for reviews
Multi-dimensional subtasks had gaps found sequentially because reviewers focused on the most visible dimension first.
Suggestion: Define subtask-type templates with dimension checklists (e.g., schema change: migration, typed struct, persistence, admin API, front-end types; protocol normalization: per-field correctness, cross-field invariant, integration test, observability) and apply the relevant template each review.
Net
Refinements, not fundamental flaws. The goal tracker, explicit acceptance criteria, and evidence-based review format all functioned as intended.
Context
Feedback from a completed RLCR session (19 rounds, exited
complete, all acceptance criteria met). The methodology worked well — no goal drift, no forgotten items, accurate goal tracking, high review true-positive rate, clear summaries/reviews/contracts. The following are refinements that could improve round economy by an estimated 15–25% for sessions of similar complexity. All observations are generalized; no project specifics included.Observed patterns & suggestions
1. Incremental blocker revelation → multi-round single-subtask corrections
A single subtask sometimes took several consecutive rounds because each review surfaced one layer of blockers at a time.
Suggestion: Correction-round reviews should commit to being exhaustive ("all remaining blockers for this subtask are listed below") and sweep known subtask dimensions even when no primary blocker exists in them.
2. Premature completion claims
Tasks were claimed complete when self-validation covered implemented scope but not the acceptance criterion's actual verification surface (e.g., end-to-end typed paths, all operating modes, canonical tooling).
Suggestion: Each round contract carries a per-criterion verification checklist mapping every acceptance criterion to a named verification method and passing evidence; unverifiable items are explicitly flagged and carried forward.
3. Cross-field invariants caught late
A semantic inconsistency across derived fields survived several reviews because tests asserted per-field correctness but not the cross-field invariant.
Suggestion: For subsystems handling multiple external protocol variants, enumerate expected cross-field invariants in the contract and require at least one end-to-end invariant test per variant; add an "invariant coverage" review step.
4. Canonical-path vs. equivalent-path validation
An operational criterion was validated with a custom equivalent script rather than the canonical tool, which had its own guards the custom path didn't exercise.
Suggestion: Operational acceptance criteria (migrations, deployment, bootstrap) should name the authoritative tool/path; contracts prohibit substituting a non-canonical equivalent unless the canonical path is genuinely unavailable (documented).
5. Two-state task completion
A "complete (pending verification)" state created transient tracker inconsistency that needed manual correction.
Suggestion: Use distinct "implemented" vs "verified" states; the reviewer owns the implemented → verified transition. No task is "verified" before reviewer confirmation.
6. Subtask-dimension checklists for reviews
Multi-dimensional subtasks had gaps found sequentially because reviewers focused on the most visible dimension first.
Suggestion: Define subtask-type templates with dimension checklists (e.g., schema change: migration, typed struct, persistence, admin API, front-end types; protocol normalization: per-field correctness, cross-field invariant, integration test, observability) and apply the relevant template each review.
Net
Refinements, not fundamental flaws. The goal tracker, explicit acceptance criteria, and evidence-based review format all functioned as intended.