A heuristic can flag a suspicious pattern without proving a compiler error, and a clean compile can leave behavior wrong. Treat each result as evidence for a specific question.

Static finding → Inspect context → Compile → Exercise behavior
  1. 1Static finding
  2. 2Inspect context
  3. 3Compile
  4. 4Exercise behavior

Work through the example

Keep a real finding and a false-positive fixture beside a rule. Explain which context the scanner cannot model.

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.

2. Every claim carries a label

Each factual claim in a report falls into exactly one bucket, and the report says which:

Label Means Requires
VERIFIED A command was run; this is its real output The command and its output, verbatim
INSPECTED The code was read and reasoned about The file:line that was read
UNVERIFIED Could not be checked The reason (no scheme, no simulator, no network)

A report with zero VERIFIED claims and no explanation of why is a failed report, regardless of how confident it sounds.

UNVERIFIED is a legitimate, useful result. "I could not build this — there is no Xcode on this machine, so the isolation fix is INSPECTED only" is honest and actionable. Quietly implying it built is not.

Acceptance and failure review

Checkpoint What to inspect If it does not match
Static finding Confirm the input and environment Preserve the failure and return to this step
Inspect context Inspect the intermediate artifact Preserve the failure and return to this step
Compile Run the focused check Preserve the failure and return to this step
Exercise behavior 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

Do not count a suppressed warning as a repaired defect.

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.

What to do next

Next: App Store readiness: the checks before you upload an agent-built app