Hope Verify
Verification proves the requested behavior. It is not a list of commands and it
does not decide the development order; use ha-test-strategy for that.
Build An Evidence Matrix
For each explicit requirement or completion criterion, record:
| Requirement |
Direct evidence |
Status |
Gap |
| Expected behavior |
test, runtime observation, diff, artifact, or read-back |
proven / failed / blocked / unverified |
next useful check |
Evidence must be current, attributable to the changed state, and strong enough
for the requirement. A compile check cannot prove a UI interaction; a child
Agent finishing cannot prove the parent outcome; a generated artifact cannot
prove delivery without read-back.
Choose The Smallest Sufficient Check
Follow repository instructions first. Typical order:
- Inspect the final diff and state transition.
- Run the focused unit, fixture, command, or reproduction for the changed path.
- Add integration or E2E only when the contract crosses that boundary.
- Use manual smoke evidence for visual or environment-dependent behavior.
- Run full gates only when requested, required by the repository, or justified
by a broad closeout.
For long background work, rely on completion injection and use status queries
for snapshots. Do not busy-wait.
Interpret Results
- Confirm the command exercised the intended case, not merely that it exited 0.
- Record failures and skipped checks; do not reuse a result from before the last
relevant edit.
- Separate product failure from fixture, environment, credential, and external
service failure.
- Treat deterministic substitutes as substitutes, not as real external proof.
- If evidence is indirect or missing, the requirement remains unverified.
Completion Audit
Before claiming a phase, Goal, or task complete:
- Re-read the actual request and named plan.
- Enumerate every required artifact, invariant, gate, and cleanup action.
- Inspect authoritative current state for each item.
- Confirm no required work remains and no stale status contradicts closure.
- State what was proven, what was not run, and any residual risk.
Goal closure remains controlled by the Goal runtime and its evidence/grader
contract. This skill may gather evidence but cannot bypass acceptance or close a
Goal by assertion.
Repository-Friendly Defaults
- Docs-only: inspect content, references, and whitespace.
- Rust: focused test or
cargo check -p <crate> during implementation.
- Frontend: targeted component test or repository typecheck.
- Runtime behavior: fixture, local reproduction, logs, DB state, or read-back.
- Push: rely on the repository pre-push gate instead of manually duplicating it.
Smoke Prompts
- "Prove whether this phase is actually complete."
- "Choose the right checks for this fix."
- "Audit the implementation against every roadmap item."
1---2name: ha-verify3description: Hope-native completion and verification discipline: map each requirement to current direct evidence, choose the smallest sufficient checks, and distinguish proven, failed, blocked, stale, or unverified claims.4---5
6# Hope Verify
7
8Verification proves the requested behavior. It is not a list of commands and it
9does not decide the development order; use `ha-test-strategy` for that.
10
11## Build An Evidence Matrix
12
13For each explicit requirement or completion criterion, record:
14
15| Requirement | Direct evidence | Status | Gap |
16|---|---|---|---|
17| Expected behavior | test, runtime observation, diff, artifact, or read-back | proven / failed / blocked / unverified | next useful check |
18
19Evidence must be current, attributable to the changed state, and strong enough
20for the requirement. A compile check cannot prove a UI interaction; a child
21Agent finishing cannot prove the parent outcome; a generated artifact cannot
22prove delivery without read-back.
23
24## Choose The Smallest Sufficient Check
25
26Follow repository instructions first. Typical order:
27
281. Inspect the final diff and state transition.
292. Run the focused unit, fixture, command, or reproduction for the changed path.
303. Add integration or E2E only when the contract crosses that boundary.
314. Use manual smoke evidence for visual or environment-dependent behavior.
325. Run full gates only when requested, required by the repository, or justified
33 by a broad closeout.
34
35For long background work, rely on completion injection and use status queries
36for snapshots. Do not busy-wait.
37
38## Interpret Results
39
40- Confirm the command exercised the intended case, not merely that it exited 0.
41- Record failures and skipped checks; do not reuse a result from before the last
42 relevant edit.
43- Separate product failure from fixture, environment, credential, and external
44 service failure.
45- Treat deterministic substitutes as substitutes, not as real external proof.
46- If evidence is indirect or missing, the requirement remains unverified.
47
48## Completion Audit
49
50Before claiming a phase, Goal, or task complete:
51
521. Re-read the actual request and named plan.
532. Enumerate every required artifact, invariant, gate, and cleanup action.
543. Inspect authoritative current state for each item.
554. Confirm no required work remains and no stale status contradicts closure.
565. State what was proven, what was not run, and any residual risk.
57
58Goal closure remains controlled by the Goal runtime and its evidence/grader
59contract. This skill may gather evidence but cannot bypass acceptance or close a
60Goal by assertion.
61
62## Repository-Friendly Defaults
63
64- Docs-only: inspect content, references, and whitespace.
65- Rust: focused test or `cargo check -p <crate>` during implementation.
66- Frontend: targeted component test or repository typecheck.
67- Runtime behavior: fixture, local reproduction, logs, DB state, or read-back.
68- Push: rely on the repository pre-push gate instead of manually duplicating it.
69
70## Smoke Prompts
71
72- "Prove whether this phase is actually complete."
73- "Choose the right checks for this fix."
74- "Audit the implementation against every roadmap item."
shiwenwen