shared-references/write-safety.md

# Shared Ads Manager Write Safety

- After every create or upload, treat the write as succeeded only when the tool call succeeds and returns the expected resource id or file id. Retain successful ids for later steps and do not claim success from a missing or ambiguous result.
- Treat tool-schema or local input validation failures before a POST as Not attempted. Correct them only after any required confirmation; no resource was created for that preflight failure.
- In a multi-step flow, explicitly report Succeeded, Failed, and Not attempted steps; stop dependent creation after a failed or ambiguous parent step. Never recreate a successful account, campaign, ad group, ad, logo upload, or creative upload; reuse returned parent ids and file ids. After a failed step, propose the smallest safe correction that directly addresses the failure and unblocks the next dependent step, then ask for approval before any corrected retry or other consequential write. Ask for missing inputs for later dependent steps only after that retry succeeds.
- Retry an ambiguous campaign, ad-group, or ad create only with the exact same request body and idempotency key. If a correction changes the body or approved semantics, confirm it and use a new key. Account, logo, and creative uploads lack the same retry guarantee; inspect current Ads Manager state before another write and never blindly repeat them after an ambiguous outcome.

- Treat every create, update, and upload as consequential. Before writing, confirm the selected account, the target resource for an update, and the exact payload.
- Before any account-scoped write, maintain an account-scoped provenance ledger. Use campaign, ad-group, ad, feed, and file ids only when copied verbatim from a successful list or get result for the currently selected ad_account_id, or from a successful create or upload in the current flow for that account. Never synthesize, edit, truncate, reuse from another account, or copy ids from user text, examples, prior errors, or stale memory. An account change invalidates all prior account-scoped ids. Only a resource-specific 404 invalidates the requested id; treat dependent ids as untrusted until revalidated. Re-resolve from a fresh selected-account list or get result before retrying and never resend a known-stale id unchanged. After reauthentication or an ambiguous result, revalidate affected state before continuing.
- Immediately before any create, validate the approved plan against the live create schema and construct the smallest schema-valid payload; treat the schema as the allowed shape, not a template to fill. Include required fields and explicitly selected optional fields only; do not materialize omitted fields as `null`, empty arrays, or empty objects, and do not copy preview, list, get, or example fields into a write. If schema validation fails, use structured validation issues when available to correct only the indicated fields; do not retry an identical payload or guess a patch.
- A retry that changes the prior payload is a new consequential write. Show the correction and obtain confirmation again before sending it.
- Resolve ids from names. Default spend-capable resources to paused unless the user explicitly requested active, and follow every tool-specific monetary guardrail.
- Automation approval must bound spend, bids, end conditions, and creation count or frequency. Never infer open-ended monetary authority.