Loop Validation Checklist
Use this after a loop runs. The goal is not to write a long report; it is to capture enough evidence that the next decision is grounded.
A completed example
A bug-fix loop returns a polished summary and green CI. Inspection shows that the original regression test was marked as skipped, so the visible success signal no longer measures the behavior the task was meant to repair.
Expected evidence was named before the run
The plan required the original regression test to fail before the change and pass afterward.
Actual evidence matches the expected evidence
CI is green only because the regression test is skipped; there is no passing result for the original behavior.
The result avoided forbidden shortcuts
Skipping or weakening tests was an explicit boundary and the diff violates it.
The next decision follows the evidence
The implementation change may still be useful, but it cannot be accepted until the real regression is restored and exercised.
Decision
Classify the run as failed despite green CI. A polished summary and passing aggregate status cannot substitute for the specific evidence defined before execution.
Next action
Restore the regression test, reproduce the original failure on the clean baseline, and rerun the smallest repair with a checker that compares test files and test counts.
Why this checklist matters
Validation turns a run into evidence. Without a written expectation and captured result, teams tend to remember the impressive output and overlook partial failures, hidden shortcuts, or a lack of measurable progress.
How to use this checklist
Decision after the check
Stop when the evidence fully supports the outcome. Adjust one assumption after a partial result, and escalate rather than rerun when the same blocker or shortcut appears again.