An unavailable client is a setup boundary, not evidence that a model cannot build an app. Preserve the same task contract while documenting exactly which execution step cannot be performed.
- 1Check executable
- 2Verify authentication
- 3Discover local tools
- 4Run shared contract
Work through the example
Prepare the brief and acceptance checks without substituting a different client. A later run must record the installed version and actual failures.
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 |
|---|---|---|
| Check executable | Confirm the input and environment | Preserve the failure and return to this step |
| Verify authentication | Inspect the intermediate artifact | Preserve the failure and return to this step |
| Discover local tools | Run the focused check | Preserve the failure and return to this step |
| Run shared contract | 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
Antigravity is not installed in this environment. Its app-building tutorial is blocked; no commands or behavior are invented here.
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
- Choose an AI client for your iOS workflow
Understand the difference between a skill, a local MCP connection and ChatGPT web setup.
- Gemini CLI: connect once and review one iOS feature
Avoid duplicate connections and keep setup evidence separate from app evidence.
What to do next
Next: Prepare a Muse app-building trial beyond tool discovery