A Release-Day Support Checklist You Run From Your Editor
The deploy goes green at 4:40 PM. You watch the logs for ninety seconds, see nothing alarming, close the tab, and start thinking about the next thing. The release is done.
Except three people wrote in about that bug over the last fortnight, and their tickets are still open. The help article describing the workaround you just made unnecessary is still live, still the top search result, still telling people to do something silly. And the one customer who chased twice will find out you fixed it whenever they happen to try again — if they try again.
None of that is a failure of discipline — it is a failure of location. Shipping is the single moment when the most support debt gets created, and every task that would clear it lives somewhere else: a helpdesk in a different tab, a knowledge base with a different login, a log dashboard you open only when something is already on fire. By the time you have switched contexts, the thing that made the work easy — knowing exactly what changed and why — has started fading.
The argument here is narrow and mechanical: the release checklist should run from your editor, at the moment of the release, because that is the only place the diff is still in front of you. Here is the sequence, and the one honest case for skipping it entirely.
The checklist that lives in the wrong tab
Every team that has been burned once writes the checklist. Close the tickets this fixes. Update the docs. Watch the error rate. It is a good checklist, and it gets run about twice before it becomes a document nobody opens.
The reason is not laziness — it is that the checklist is written in the support system's vocabulary while you are standing in the code's. You changed the retry logic in the invoice webhook handler. The helpdesk holds three tickets whose subjects say "invoice never arrived", "charged but no receipt", and "is your email broken?". Bridging those two descriptions is real cognitive work, and it is the work that gets skipped at 4:40 PM on a Friday.
An agent connected to your support desk over MCP collapses that bridge — it holds both halves at once, the diff on one side and the ticket text on the other. You are not asking it to be clever. You are asking it to do a join you would otherwise do by reading twenty subject lines and hoping.
The sequence, in order
Four steps, each one a sentence you type. Order matters: reading before writing, customers before docs, and the log check last because it needs the release to have been live for a while.
1. Find what this release answers
Start with a read, and start broad. Here is what I just shipped — list the open tickets in Ledgerly that might be about any of it. Behind that, list_tickets pulls the open queue and the agent matches against the change rather than a keyword you guessed. Worst case it proposes something unrelated and you say no.
What comes back is usually two or three tickets and one surprise — a ticket from five weeks ago you had filed mentally as user error, which turns out to describe the exact bug you just fixed. That surprise is the whole reason to run the step.
2. Reply from what actually changed
For each match, have the agent draft a reply — and read it before it goes anywhere. reply_to_ticket emails a real person immediately with no undo, so keep this step deliberate even when the rest of the sequence is automatic. Send the ones that are right; rewrite the one that is nearly right.
Where a ticket is close but not quite covered, add_ticket_note is the pressure valve — a staff-only line saying partially addressed, still broken for CSV imports costs nothing, is never emailed, and saves Future You from re-deriving it.
3. Fix the article that is now wrong
The workaround you documented in June is now actively misleading. search_articles finds the articles mentioning the behaviour you changed; update_article revises them. This is the step people skip most and regret longest, because a stale help article does not fail loudly — it quietly generates the tickets you answer next month.
If the release added something the knowledge base never covered, create_article while the details are in your head beats writing it later from memory.
4. Check the log for what you just introduced
Give it an hour, then look: list_log_issues for fingerprints first seen since the deploy, query_logs for the raw events behind one. New errors in the first hour after a release are the highest-signal thing in your log stream — the causal window is unambiguous. Nothing changed except your code.
Two of these steps only read. One writes staff-only text. Exactly one reaches a customer, and it is the one you should still be reading with your own eyes.
Why the reply is better when it comes from the diff
Here is the part that is genuinely different about running this from the editor rather than from the helpdesk, and it is not convenience.
A support reply written from the helpdesk says: Thanks for your patience — this has been fixed in our latest release. It is fine. It is also the sentence every company sends, it carries no information, and the customer has no way to tell whether you fixed their problem or a problem that shares a subject line with theirs. Half of them will write back to ask.
A reply written where the commit is says: Fixed as of today. The bug was in how we retried failed invoice emails — a retry after a transient bounce overwrote the delivery status, so the email showed as sent when it never went out. Yours was one of those; the receipt for invoice 2291 went out this morning.
The second is not better writing. It is better information, and it exists only because whatever composed it could read the change. It answers the follow-up before it gets asked, and it does the thing a generic reply cannot — it shows you understood their specific problem, which is what they wanted when they wrote in.
It is also the argument against batching. A week later the specifics have to be reconstructed, and reconstructed specifics are how you tell someone their issue was fixed when what you fixed was the one next to it.
When to skip the whole thing
Now the honest part. Most releases do not need any of this.
Ship a dependency bump, a refactor, a copy tweak, or a feature nobody has asked for, and there are no tickets to find, no articles that just went wrong, nobody waiting to hear from you. A four-step support sequence against that release produces four confident negative answers and a little self-congratulation. It is theatre — and worse, the kind of theatre that trains you to skim results, so when you finally ship something people were waiting on, you skim that one too.
The trigger is not "we deployed". It is "we deployed something a customer complained about". If you cannot name a person or a ticket that cares, close the terminal and go home. The one step that survives on every release is the log check, and only because it costs a sentence.
The bottom line
Support debt is created at deploy time and paid back at inbox time, usually by someone who has forgotten why the change was made. The checklist that prevents it is four sentences long, and it only gets run when running it is cheaper than the context switch — which means it has to live where you already are, next to the diff, while you still remember what you changed and who was waiting for it.
The deploy went green at 4:40. The question is whether the three people who told you about the bug find out from you, or find out by accident.
Run the release checklist where the diff is
Connect your editor to your support desk over MCP — read the queue, answer from the commit, fix the article that just went stale.