Magistr records verification with the work it checks. A result can include the command, output, exit code, observed source inputs, and a receipt identifying that attempt. Written reviews are separate from executed commands.
Before verification, connect the agent, agree on the task’s acceptance criteria, and configure check commands that actually work in your project.
Choose checks for the change
Use focused verification for a bounded change: select checks for the changed behavior and affected consumers. Explain why those checks establish the result. A documentation link fix and a persistence-format change need different checks.
Use full verification for an explicit full-suite request or a concrete risk requiring every configured gate. A roadmap chunk does not by itself require every test, package build, or release check.
For an interface change, include interaction and visual review. For example, a form validation change needs both the rejected-input behavior and a readable, usable error state.
Run and record checks
Ask the connected agent to run named project gates or use check_work with
the actual command. Command checks are executed by Magistr; their recorded
exit status comes from that execution.
The check belongs to an active work task. A standalone command that passes without being recorded for the task is useful diagnostic output, but does not establish completion of that task.
Read the command, selected inputs, result, and output. A tool returning successfully is not the same as the check passing. Timeouts, launch failures, and failed tests must remain visible.
Interpret failures and stale results
| Result | Meaning and next action |
|---|---|
| Passed | The command succeeded for the recorded inputs. Check that it covers the acceptance criterion. |
| Failed | Inspect the actual failure, correct its cause, then rerun the affected check. |
| Timed out or could not launch | The intended verification did not complete. Diagnose the command, environment, or budget. |
| Inputs changed | Earlier evidence may no longer describe the current work. Rerun checks affected by those inputs. |
| Reused receipt | A matching successful result was reused. Read its original receipt; no new execution occurred. |
Eligible successful test, lint, and typecheck results can be reused for up to 24 hours when command, source, configuration, tools, and environment still match. Builds and reviews need fresh results. Custom gate reuse must be explicitly configured with adequate inputs.
If files change during a check, its tests can pass while completion remains refused because the evidence no longer describes stable inputs. Save the intended changes and rerun the affected command. Include dependencies in bounded input lists; omit the list when the full dependency set is unknown.
Review the interface
Exercise the real controls and meaningful states. Capture at supported sizes and appearances, then open the images and inspect layout, readable text, contrast, focus, clipping, and control placement.
Record what was inspected and its limitations as a review. A screenshot’s existence does not establish visual review. Headless browser testing does not establish native operating-system input or assistive-technology behavior.
Run the full configured gate
From the project root:
magistr validateOr use $validate in Codex or /validate in Claude Code. This runs the
configured standard checks and required custom checks. It does not implement
a roadmap item. A required failure blocks a successful full-gate result.
Finish with evidence
Before completion, ask the agent to identify the current checks, the acceptance criteria they support, reviewed interface evidence, and any unverified behavior. Required checks must pass and remain applicable to the finished source.