| name | verify |
| description | > Use when this capability is needed. |
Every change must be verified before declaring completion,
including documentation-only changes.
If $ARGUMENTS is provided (auto, minimal, code, proof, proto, full),
use it as a hint to prioritize relevant scopes.
If $ARGUMENTS is absent or ambiguous, use automatic scope detection.
Blast-radius analysis (always first)
Before selecting test commands,
run the blast-radius detector script:
cargo make blast-radius
The script returns JSON with these fields:
changed_files
affected_crates
risk_flags
docs_only
recommended_scopes
recommended_commands
Use this output as the source of truth for scope selection
and command execution order.
If the script is unavailable or fails,
use this fallback procedure:
- List changed files (staged and unstaged).
If there are no local changes,
compare against
main if available.
- Map changed paths to affected areas:
proto/
crates/pessimistic-proof*
crates/<crate-name>/
- docs-only changes (
docs/, README.md, markdown/adoc/rst/txt prose)
- Determine
affected_crates.
Use docs/knowledge-base/src/architecture.md as the ownership map.
- Detect
risk_flags:
- proof pipeline changes
- protobuf schema changes
- storage schema/migration changes
- settlement/signer/contract changes
- configuration schema changes
- Derive
docs_only:
true only when all changed files are documentation/prose and
no runtime code/config/proto files changed
false otherwise
- Derive
recommended_scopes:
minimal always
code when runtime behavior may change
proof when proof crates changed
proto when protobuf schema changed
- Derive
recommended_commands as exact commands in execution order.
If $ARGUMENTS explicitly requests additional scopes,
append the missing scope commands.
minimal always remains required.
Docs-only branch
If blast-radius reports docs_only: true:
-
Always run recommended_commands from blast-radius.
-
Ensure this command is included:
mdbook build docs/knowledge-base/
-
Skip runtime-heavy scopes (code, proof, proto)
unless the user explicitly requested them via $ARGUMENTS.
Scopes
Run all matching scopes (scopes are cumulative).
minimal always runs.
Additional scopes come from blast-radius output,
optionally constrained by $ARGUMENTS.
When available,
run recommended_commands directly in the provided order.
Minimal (always runs)
cargo check --workspace --tests --all-features
cargo check only type-checks; it does not execute tests.
Never treat a passing cargo check as proof that changes work.
When any scope below matches the changed files, it must also run.
Code behavior (features, bug fixes, refactors)
cargo make ci-all
cargo nextest run --workspace
cargo make ci-all runs: format check, clippy, typos,
and clippy on the PP program.
Test selection rules for cargo nextest run (fallback only,
when blast-radius did not provide recommended_commands):
-
If blast-radius reports broad impact
(core types/storage/rpc/proto boundaries or many crates),
run:
cargo nextest run --workspace
-
Otherwise run package-targeted nextest for affected crates first.
-
If package-targeted tests fail in a way that suggests transitive impact,
escalate to cargo nextest run --workspace.
Pessimistic proof (crates/pessimistic-proof*)
cargo make pp-check-vkey-change
If the vkey changed, ask the user for explicit confirmation
before running:
cargo make pp-accept-vkey-change
Protobuf (proto/)
cargo make generate-proto
Then verify no uncommitted diffs in generated code.
Fix-and-rerun protocol
- If checks fail, attempt focused fixes for failures plausibly caused
by your changes, then rerun checks.
- Stop after 2 fix-and-rerun cycles,
or if failures appear unrelated to your changes.
- Hand control back with a brief summary of what passed, what failed,
and what you tried.
Reporting
Always report:
- Exact command(s) run.
- Whether each passed or failed.
- If failed: the relevant error output.
- Blast-radius result summary and chosen scope rationale.
Source: agglayer/agglayer — distributed by TomeVault.