Loop Prevention with Max Iterations

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A build still fails after dependency repairs, risking repeated version changes without progress. The teaching task allows at most three attempts, each with an observed-error hypothesis, corresponding change and check. Budget exhaustion is not resolution.

Mechanism

Define the attempt unit, cap and early-stop conditions. Record signature, hypothesis, revision/change and covering result each round, comparing new evidence. Avoid unchanged repetitive paths. At the cap preserve diff/open status and the next needed input/decision. A resumed session reads the ledger rather than resetting counts.

Bad example

Keep changing dependencies and building until a pass. Reset attempts per session and mark complete when the budget expires.

Good example

Allow three attempts total for this fixture; each includes one evidenced hypothesis, matching change and covering check. Preserve revisions/signatures/results. Stop repeated paths without new evidence early. After three failures keep the diff, unresolved error and next necessary check; do not claim completion or reset counts after handoff. Existing attempts count.

Why the change matters

The cap bounds effort, while per-attempt evidence makes diagnosis comparable. Persistent counts prevent another try from becoming an endless loop across sessions.

Observable expectation

Three identical failing signatures yield unresolved status and a stopped current loop, not a passing build. Verify covering evidence and that resumed work recognizes all three attempts.

A second-attempt pass without new concerns ends the check early; do not keep editing to fill the budget.

Limits

Three is a teaching budget and the source’s five rounds belong to another workflow. Counts guarantee no convergence. Stop the attempt loop without erasing unfinished work or silently dropping real defects.