A failed task should describe the environment, observed behavior and unresolved condition. It should not become a universal claim that all agents are unable to perform that task.
- 1Expected behavior
- 2Actual output
- 3Reproduction
- 4Bounded conclusion
Work through the example
Write a failure note that another developer can reproduce using synthetic data. Separate missing access from incorrect implementation.
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.
6. Reporting failure
Report outcomes faithfully. Specifically:
- If tests fail, say so and paste the failure.
- If you skipped a step, say which and why.
- If you could not reproduce a bug, say that — do not ship a speculative fix as a confirmed one.
- If part of the scope is blocked, finish everything else in full and state exactly what you left out.
A partial result honestly labelled is more useful than a complete-looking result that is wrong, because the human can act on the first and will be misled by the second.
Acceptance and failure review
| Checkpoint | What to inspect | If it does not match |
|---|---|---|
| Expected behavior | Confirm the input and environment | Preserve the failure and return to this step |
| Actual output | Inspect the intermediate artifact | Preserve the failure and return to this step |
| Reproduction | Run the focused check | Preserve the failure and return to this step |
| Bounded conclusion | 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.
Ten failure categories
These categories distinguish causes; they are not a prevalence ranking or a list of impossible tasks.
| Observed category | First diagnostic step |
|---|---|
| Executable missing | Check the installed command path |
| Expired authentication | Use the client’s local sign-in flow |
| Missing runtime | Inspect available simulator runtimes |
| Wrong scheme | List schemes in the selected project |
| Unavailable API | Inspect SDK and deployment target |
| Isolation mismatch | Trace ownership and mutation sites |
| Stale response | Exercise cancellation and replacement |
| Lost persistence | Terminate and reopen a test store |
| UI clipping | Use long text and larger type |
| False-positive finding | Reduce to positive and negative fixtures |
Evidence and limits
No evidence supports a universal list of ten things agents cannot do; the lesson teaches failure classification instead.
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
- Review AI-generated Swift before you trust it
A focused review, a small patch and a real test beat a confident completion message.
- 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: Local persistence contracts: Reading List JSON storage and a SwiftData alternative