loop-hardening-contract

Loop Hardening Contract

Use this contract after loop-readiness-review when repeated delivery needs tighter execution evidence. It is a review and packet format, not a runner or scheduler.

1. Harness Stripping

Remove harness complexity only through an isolated, one-component experiment:

1. Record the component, its intended failure mode, and its operating cost.
2. Capture a representative baseline for completion, verification, cost, and failures.
3. Disable exactly one non-safety component between runs, never during a live run.
4. Repeat the same bounded case and classify REMOVE, RESTORE, HARMFUL, or INCONCLUSIVE.
5. Retain the evidence and human settlement decision.

Never strip sandboxing, budgets, stop conditions, human gates, root verification, or protected-data boundaries.

2. Runtime-Path Sprint Packet

Freeze this packet before execution:

• sprint_id and version;
• one concrete deliverable;
• 3–7 observable acceptance predicates;
• the actual runtime path to exercise;
• explicit out-of-scope items;
• owned files or write boundary;
• stop conditions and budget;
• verification commands, device/browser steps, and expected evidence.

The executor cannot accept its own result. A mid-run requirement change creates a new packet version with a reason and explicit human confirmation.

3. Broken-Window Revalidation

Before a new sprint, re-run the latest accepted result through its real runtime path:

• STILL_GREEN: the accepted predicates still pass;
• REOPENED: a previously accepted predicate now fails;
• INCONCLUSIVE: the required runtime or evidence is unavailable.

On REOPENED, stop new work, retain the evidence, reopen the result, and propose a bounded repair. Do not auto-revert. A revert may erase useful subsequent work or hide the causal change and therefore requires an inspected, human-approved settlement.

Compilation is not Cardputer device proof. Unit tests are not browser or production proof when the accepted claim names those runtime paths.