rnd-iterationlisted

# R&D Iteration ## Overview When the Verifier issues NEEDS ITERATION or FAIL, the Builder gets feedback and revises. This cycle has a budget to prevent infinite rework. **Core principle:** Feedback describes WHAT is wrong with evidence. The Builder reasons about HOW to fix. Repeated iteration on the same criterion is a signal the task needs re-decomposition, not more attempts. ## When to Use - After a Verifier returns NEEDS ITERATION or FAIL - When a Builder receives feedback from verification - When iteration budget is approaching or exceeded ## Information Barrier During Iteration When passing Verifier feedback to the Builder: **INCLUDE:** - The "Feedback" section from the verification report - Which assertions failed and what evidence showed the failure — the feedback string for each failing assertion MUST cite the assertion ID verbatim (e.g., "Assertion M1.verifier.prose-report-per-assertion: …") - The failing assertion IDs from the verdict map, so the Builder can map feedback to specific Validation Contract assertions **EXCLUDE:** - The Verifier's internal reasoning - Suggested fixes (Verifier should not have provided these) - Other tasks' verification results ## Builder's Response to Feedback When receiving verification feedback: 1. **Read the feedback carefully** — Understand WHAT failed, not just that it failed. Each failing assertion ID is cited verbatim in the feedback; use those IDs to look up the exact assertion in the Validation Contract. 2. **Diagnos