Keep account authority separate from code editing. Signing changes should be deliberate, reviewed and performed through the appropriate local account flow.

Code task → Need account change? → Explicit review → Local configuration
  1. 1Code task
  2. 2Need account change?
  3. 3Explicit review
  4. 4Local configuration

Work through the example

Prompt: Do not change signing or provisioning to hide this build error. Explain whether the selected simulator destination needs signing.

One practical example

Use the prompt above on one small, named part of your app. Before accepting an edit, ask the agent to point to the source or configuration that supports its answer. If it cannot locate that context, resolve the missing input before expanding the task.

In the diagram, each arrow represents a handoff you can inspect. Keep the intermediate result rather than jumping directly to the final claim. For example, a reported finding should retain its location, and an executed check should retain its outcome. This gives the next attempt a concrete starting point and makes a misleading completion message easier to challenge.

Apply it to your project

Prompt: Do not change signing or provisioning to hide this build error. Explain whether the selected simulator destination needs signing. Then compare the resulting diff with the original request. If it changed a neighboring concern, ask why that change was necessary. Save the result only after the relevant check has run, and record any part that remains unverified.

Evidence and limits

An absolute ban is not necessary for every authorized workflow; secret values still stay out of chat and source.

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: Reading agent transcripts: the three phrases that mean it guessed