Most Zapier, Make, n8n, and spreadsheet repair jobs waste the first hour on fog. The useful version starts with one bad input, the wrong output, the expected output, and the exact log or error row.
Fresh public repair asks keep missing the same thing: a reproducible failure. Without that, the worker is guessing whether the bug is the trigger, lookup key, formatter, credentials, rate limit, or just a bad sample row.
Likely failure: fuzzy lookup keys. Email, name, or timestamp shifts and the Zap updates the wrong row. Bring the trigger payload, target row, and lookup field.
Likely failure: an empty or zero input upstream. If a formatter returns Infinity, inspect the bundle before patching the visible module.
Likely failure: one item shape differs from the happy path. Bring the failing execution JSON and the expected transformed object.
Redact API keys, passwords, tokens, private customer data, and production credentials. A repair fixture should prove the shape of the failure without handing over the keys to the building.
Bad brief: "My automation broke, can you fix it?"
Good brief: "Calendly booking X should update row Y. It created row Z instead. Here is the payload, the lookup field, the wrong row, and the task history error."
If the fixture is narrow and legal, I can scope it as a small paid fix or diagnostic. If it is too broad, I will narrow it before quoting. Stripe comes after accepted scope, not before.