A client record is most useful when it says what did not run. Keep discovery, hook execution, model behavior and app acceptance as separate fields.
- 1Environment
- 2Command
- 3Observed result
- 4Explicit limits
Work through the example
Record versions and artifact paths without credentials or personal source. A boolean should name a concrete check, not vague compatibility.
Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.
Implementation reference
The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.
5. The report format
Every agent in this repository returns this shape:
VERDICT: <done | blocked | partial>
EVIDENCE
$ <command>
<real output>
$ <command>
<real output>
WHAT CHANGED
- path/to/File.swift:88 — <what and why>
NOT VERIFIED
- <claim> — <why it could not be checked>
FOLLOW-UPS
- <anything deliberately left, so nobody assumes it is covered>
NOT VERIFIED is not optional. An empty section is fine; omitting the section
suggests everything was verified, which is rarely true.
Acceptance and failure review
| Checkpoint | What to inspect | If it does not match |
|---|---|---|
| Environment | Confirm the input and environment | Preserve the failure and return to this step |
| Command | Inspect the intermediate artifact | Preserve the failure and return to this step |
| Observed result | Run the focused check | Preserve the failure and return to this step |
| Explicit limits | Record the observed result | Preserve the failure and return to this step |
Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.
Evidence and limits
Existing records are dated snapshots, not guarantees for later versions.
This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.
Inspect the source used in this lesson.
Related reading
- Which Muse Code MCP settings actually work with a local Swift review server?
A reproducible Muse 1.3.0 connection check, with the exact configuration and clear limits on what discovery proves.
- Muse Code: what our integration actually verifies
Discovery and hooks are useful milestones, but they are not a finished app.
What to do next
Next: Measuring whether a skill helps: a paired benchmark protocol