Lesson 21 — Verification that becomes stale correctly

Outcome

Run deterministic project checks against an exact candidate revision and invalidate their usefulness when code changes.

Why this comes now

A green test badge is dangerous if it silently survives later code changes.

Understand

Verification Definition says what to run; Verification Run records what happened against a revision. Historical runs never mutate into having run against new code. “stale” is the relationship between a current candidate and an old run.

Project-defined commands cross the Project Trust boundary and must execute through ProcessRunner/ExecutionEnvironment.

Build the real project

1. Add VerificationDefinition and VerificationRun storage/domain.
2. Add project trust check before executing project-defined commands.
3. Add RUN_VERIFICATION Operation.
4. Bind run to CandidateRevision.
5. Capture status/output summary without dumping unlimited output into memory/DB.
6. Display Passed/Failed/Error and Current/Stale.
7. Modify code after a pass and prove the UI/core shows it stale.

Completion gate

A pass for revision A is not considered current for B. Untrusted projects cannot silently run configured verification commands. Cancellation/error states are visible.

Pitfalls to avoid

Do not make verification exit code the only possible semantic result when a check protocol later carries richer status. Do not store megabytes of stdout blindly in a Task row.

References

SECURITY.md, DATA_MODEL.md.

Checkpoint

Keep OD-001 open unless using the loop gives enough evidence to decide whether failed required checks hard-block approval.