RLCR methodology hardening: 7 suggestions from a clean single-round run

[shaofengzou233-cell]

Context

Sanitized methodology findings from one RLCR-style loop run that completed
in a single build round (all acceptance criteria met, review passed, zero
drift at finalize). No project-specific information is included.

The loop performed well; these are hardening suggestions for larger,
multi-round, or less disciplined runs.

Suggestions

S1. Make "full-scope round" an explicit contract mode

• Pattern: the round-contract template prescribes one or two acceptance
  criteria per round, but a plan legitimately sized for one round forced an
  informal override targeting all criteria.
• Improvement: add an explicit full-scope-round mode to the contract schema
  with a justification field and machine-checkable preconditions
  (single-round plan declaration, acyclic task graph, gate-verifiable
  criteria). Require per-task commits and per-task self-verification
  checkpoints when active; otherwise enforce the one-or-two-criteria rule.

S2. Require durable evidence for process-ordering claims

• Pattern: a mandated test-first (red-then-green) sequence was claimed but
  not recoverable from the final state and had to be accepted on trust.
• Improvement: require a durable artifact for mandated process steps
  (captured failing-phase output or a gate that logs execution order), or
  add a "process claims: verified / unverifiable" field to the review
  result schema.

S3. Assemble review prompts conditionally on the active loop mode

• Pattern: the review prompt carried a large rule block for a loop mode the
  plan had explicitly disabled; most instructions were inapplicable
  boilerplate.
• Improvement: compose review prompts from mode-scoped rule blocks, include
  only enabled blocks, and state in a header which mode is active.

S4. Always emit a verdict artifact for every invoked review phase

• Pattern: a final review phase announced result/captured-output files,
  produced none because the review was clean, and incremented the round
  number despite no build work.
• Improvement: write a result file on every review invocation (even a
  one-line "no issues, proceed"), and number review-phase invocations
  separately from build rounds.

S5. Add a lesson-consumption handshake

• Pattern: lesson capture worked well, but nothing forces the next round to
  demonstrably apply stored lessons.
• Improvement: require an "applicable lessons" field in the round contract
  (lesson identifiers plus how each constrains execution, or explicit
  none-found), checked by the reviewer like gate results; record a fallback
  note when the lesson-selection helper is broken.

S6. Give queued side issues an owner and an escalation rule

• Pattern: a broken auxiliary tool was correctly parked as non-blocking, but
  its revisit trigger had no owner and no deadline.
• Improvement: add owner and max-age / must-recheck-by columns to the
  queued-issues table, and require the finalize summary to list all
  surviving queued issues.

S7. Codify the reviewer gate re-run rule

• Pattern: the reviewer independently re-ran every machine-checkable gate
  instead of trusting the summary; this appears to be practice, not an
  enforced rule.
• Improvement: state in the review handoff contract that every
  machine-verifiable criterion must be independently re-executed, and that
  narrative-only evidence needs an accompanying artifact to support a pass.

What worked well (keep)

• Honest self-reporting of mid-round failures and self-detected false
  positives.
• Tasks marked verified only after reviewer results existed.
• Immutable goal-tracker anchor with a logged, empty plan-evolution table.
• Blocking vs queued triage kept a real defect off the critical path.
• Evidence-graded completion plus a zero-drift finalize identity check.
• Machine-parseable progress verdict and final action token.