Context
This issue distills methodology improvement patterns observed from a 16-round RLCR session. All content is fully sanitized — no project-specific identifiers, paths, names, or code.
Improvement Suggestions
1. Queue-with-obsolescence needs forced-retirement semantics
Pattern: A finding was queued in Round 15 with a correct obsolescence rationale (a future user directive would regenerate the artifact end-to-end). The reviewer re-raised the identical finding in Round 16 anyway, costing a full round of pure process friction on a mechanical fix both parties already agreed was correct.
Proposed change: Add a rule to the reviewer prompt: "If a finding was queued in the previous round with an obsolescence justification, and the agent has not yet engaged the obsolescence trigger, the reviewer may either (a) accept the queue and omit the finding from this round's output, or (b) escalate it to blocking with a one-sentence justification for why obsolescence does not apply. The reviewer must not re-raise the same queued finding at the same severity without escalation rationale."
2. Introduce a "round budget exhaustion" signal at round 10
Pattern: Rounds 1–5 delivered broad implementation progress; Rounds 6–10 found high-impact latent bugs; Rounds 11–16 degenerated into micro-iterations on a single small script (one regex / parser / schema fix per round). Diminishing returns were visible but not acted upon.
Proposed change: At round 10, the reviewer must include an explicit "Productivity Assessment" estimating remaining rounds. If the assessment is "1–2 rounds of micro-fixes on a single curated artifact," the reviewer should recommend a "batch round" contract: the agent is authorized to fix up to N related small findings in one round, provided each fix is independently validated and the round summary uses a checklist format.
3. Harden "AC overstatement" detection in the agent's pre-submission checklist
Pattern: The agent overstated AC completion three times across the session, each time treating "honest documentation of a limitation" as equivalent to "AC satisfied." The reviewer caught it each time, but three rounds were spent on the same cognitive error. The Plan Evolution Log captured corrections but did not prevent recurrence.
Proposed change: Add a mandatory pre-submission checklist item to the agent's round-summary template: "For each AC marked Complete/Pass, verify that the immutable acceptance criterion text is literally satisfied, not merely explained or documented. If an AC is NOT_MET, it must remain in Active/Blocking status regardless of how well the limitation is documented."
4. Distinguish "review phase" from "hardening phase" in contract semantics
Pattern: After all ACs were met (Round 5), the session entered a review phase where the reviewer inspected already-accepted code and found new bugs. These were not regressions against the ACs — they were latent defects discovered by deeper inspection. The contract semantics did not change, so every round still carried full AC-status overhead even though the work had shifted to code quality.
Proposed change: When the reviewer issues an "all ACs met" verdict, the next round's contract should explicitly enter "Hardening Phase" semantics: AC-status tables are frozen, the round contract focuses on a specific module or failure class, and the reviewer evaluates against "did this round reduce latent defect count?" rather than "did this round advance ACs?"
5. Require the reviewer to classify findings by failure class, not just severity
Pattern: Three separate rounds (10, 11, and 14) were all instances of the same failure class: a silent default / fallback value masking a missing or edge-case input. The reviewer caught each independently without noting the pattern. If the reviewer had flagged the pattern in Round 10, the agent could have audited the entire script for similar fallback patterns in Round 11, potentially preventing later rounds.
Proposed change: Add a "Failure Class" tag to each reviewer finding (e.g., silent-fallback, unit-mismatch, schema-drift, shadowed-binding). When two findings in a session share a class, the reviewer must add a cross-reference and recommend an agent-side audit for that class. This turns isolated bug reports into pattern detection.
Verdict
The methodology earned approximately 12 of its 16 rounds. The 4 compressible rounds were in the late-phase micro-iteration clusters (rounds 11–16). A tighter RLCR with batch-round authorization at round 10 and forced queue-retirement semantics would have reached the same end-state without loss of quality.
Context
This issue distills methodology improvement patterns observed from a 16-round RLCR session. All content is fully sanitized — no project-specific identifiers, paths, names, or code.
Improvement Suggestions
1. Queue-with-obsolescence needs forced-retirement semantics
Pattern: A finding was queued in Round 15 with a correct obsolescence rationale (a future user directive would regenerate the artifact end-to-end). The reviewer re-raised the identical finding in Round 16 anyway, costing a full round of pure process friction on a mechanical fix both parties already agreed was correct.
Proposed change: Add a rule to the reviewer prompt: "If a finding was queued in the previous round with an obsolescence justification, and the agent has not yet engaged the obsolescence trigger, the reviewer may either (a) accept the queue and omit the finding from this round's output, or (b) escalate it to blocking with a one-sentence justification for why obsolescence does not apply. The reviewer must not re-raise the same queued finding at the same severity without escalation rationale."
2. Introduce a "round budget exhaustion" signal at round 10
Pattern: Rounds 1–5 delivered broad implementation progress; Rounds 6–10 found high-impact latent bugs; Rounds 11–16 degenerated into micro-iterations on a single small script (one regex / parser / schema fix per round). Diminishing returns were visible but not acted upon.
Proposed change: At round 10, the reviewer must include an explicit "Productivity Assessment" estimating remaining rounds. If the assessment is "1–2 rounds of micro-fixes on a single curated artifact," the reviewer should recommend a "batch round" contract: the agent is authorized to fix up to N related small findings in one round, provided each fix is independently validated and the round summary uses a checklist format.
3. Harden "AC overstatement" detection in the agent's pre-submission checklist
Pattern: The agent overstated AC completion three times across the session, each time treating "honest documentation of a limitation" as equivalent to "AC satisfied." The reviewer caught it each time, but three rounds were spent on the same cognitive error. The Plan Evolution Log captured corrections but did not prevent recurrence.
Proposed change: Add a mandatory pre-submission checklist item to the agent's round-summary template: "For each AC marked Complete/Pass, verify that the immutable acceptance criterion text is literally satisfied, not merely explained or documented. If an AC is NOT_MET, it must remain in Active/Blocking status regardless of how well the limitation is documented."
4. Distinguish "review phase" from "hardening phase" in contract semantics
Pattern: After all ACs were met (Round 5), the session entered a review phase where the reviewer inspected already-accepted code and found new bugs. These were not regressions against the ACs — they were latent defects discovered by deeper inspection. The contract semantics did not change, so every round still carried full AC-status overhead even though the work had shifted to code quality.
Proposed change: When the reviewer issues an "all ACs met" verdict, the next round's contract should explicitly enter "Hardening Phase" semantics: AC-status tables are frozen, the round contract focuses on a specific module or failure class, and the reviewer evaluates against "did this round reduce latent defect count?" rather than "did this round advance ACs?"
5. Require the reviewer to classify findings by failure class, not just severity
Pattern: Three separate rounds (10, 11, and 14) were all instances of the same failure class: a silent default / fallback value masking a missing or edge-case input. The reviewer caught each independently without noting the pattern. If the reviewer had flagged the pattern in Round 10, the agent could have audited the entire script for similar fallback patterns in Round 11, potentially preventing later rounds.
Proposed change: Add a "Failure Class" tag to each reviewer finding (e.g.,
silent-fallback,unit-mismatch,schema-drift,shadowed-binding). When two findings in a session share a class, the reviewer must add a cross-reference and recommend an agent-side audit for that class. This turns isolated bug reports into pattern detection.Verdict
The methodology earned approximately 12 of its 16 rounds. The 4 compressible rounds were in the late-phase micro-iteration clusters (rounds 11–16). A tighter RLCR with batch-round authorization at round 10 and forced queue-retirement semantics would have reached the same end-state without loss of quality.