A task is done when production says so

Tests pass on the code you wrote. Production runs it against real traffic, real data and real dependencies. Before you tell the user a fix shipped, check that it changed what it was meant to change and nothing else.

0. How the tools work

The Sazabi MCP server lists only two tools, search and execute. Browse Sazabi's operations with search and namespace: "sazabi" (an empty query without a namespace lists connected connectors, not Sazabi operations). Before calling one, repeat search with namespace: "sazabi", the hit's full name as the query, and includeInputSchema: true to load its arguments. Then run it with execute as { name, arguments }, the name copied from the hit (for example sazabi/logs.ask). Questions about logs go to sazabi/logs.ask.

1. Pin down the deploy

Find when the change went live: the deploy time, or the first log line that carries the new version or commit. Every comparison below is "before that moment" against "after it". If the change is not live yet, say so and stop.

2. Did the change do its job?

Ask one question for the thing the change should affect, over a window on each side of the deploy:

• A fix: "how many times did <the error> occur per 10 minutes, 3 hours before and after <deploy time>". It should drop to zero, not just fall.
• A feature: "how many requests reached <new endpoint or log line> since <deploy time>, and how many failed". Zero traffic means it is not wired up yet.
• A performance change: ask for the latency or duration the logs record, per interval, on both sides.

3. Did it break anything else?

Ask for an overview of what is new or growing since the deploy. Look at each new kind of error line and decide if this change could cause it. Check sazabi/issues.search for issues first seen after the deploy.

4. Report