Validation and evidence

Hop binds validation to immutable source trees. It does not guess which tests a project needs—the agent, repository policy, or controller supplies the command.

Evidence, not a universal test suite

hop check can run any executable command:

hop check P_... -- go test ./...
hop check P_... -- npm test
hop check P_... -- cargo clippy --all-targets
hop check P_... -- ./scripts/verify-release.sh

Hop records the command, sanitized output, exit code, exact source-tree ID, and time. A successful record proves that command passed for that tree—not that the project has no bugs or that an unrelated test suite ran.

Checkpoint validation

hop check STATE -- COMMAND first freezes the live workspace as an immutable checkpoint. It materializes that checkpoint in a detached temporary worktree, runs the command there, and stores the resulting evidence. Concurrent edits in the live workspace cannot change what was tested.

If code changes after a check, create a new check. A proposal points at an exact tree and can report matching evidence for that same tree.

Final-tree validation

The proposal tree may need to merge with newer accepted work or a newer remote tip. Therefore proposal evidence alone is not enough. Supply the strongest relevant command to landing:

hop land R_... -- go test ./...

Hop constructs the exact final integrated tree in a disposable worktree and runs the command before advancing accepted state. A nonzero exit leaves the accepted head unchanged.

Failures

• Exit 22 means the supplied validation command failed.
• The failed execution remains durable evidence.
• Fix the live workspace, check again, create a new proposal, and land again.
• Do not bypass a failing final check with controller-only acceptance.
• Choose validation proportional to the change: focused tests during iteration, then the strongest relevant final check at the acceptance boundary.