> ## Content Index > Fetch the complete content index at: https://vibe2value.com/llms.txt > Use this file to discover other available public pages before exploring further. # 4.1.1 - You Haven't Finished a Deploy Until You've Practised Undoing It - URL: https://vibe2value.com/you-havent-finished-a-deploy-until-youve-undone-it/ - Published: 2026-08-25T09:19:59.000Z - Updated: 2026-09-07T06:30:53.000Z - Description: Decide what triggers a deploy to each environment, how you confirm it landed and the exact route back to the previous version. - Author: vibe2value - Tags: run, release, deploy, reversibility, reducing risk, shape+build+launch+run+close ## Deploy and rollback When this goes wrong at five to five, how do you get back to the version that worked? ## The call Write down what triggers a deploy to each environment, what runs during it, how you confirm it landed and the exact steps back. Undoing is the half people find out they never built. ## Sharpen deploy and rollback with AI This is a Run idea, so the AI move is **Run it for real**. You can sharpen the decision here, but it only proves out against a system that is actually live. **New here? Let your AI do this with you.** Paste your problem into [Guide me](https://vibe2value.com/guide-me/) and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt. Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see [how to use vibe2value](https://vibe2value.com/how-to-use/). Or copy this prompt into AI chat, replace the bracketed lines with your real deploy and keep the instruction exactly as visible here. It helps you put your `deploy.md` together by refining your three lines until somebody who did not build this could act on them. ``` You are checking whether this deploy and rollback plan is clear enough before you move forward. Constraint: Someone who has never deployed this project must be able to deploy it, confirm it landed and get back to the previous version using only what is written down. Example of the standard: Vague: "It deploys automatically when we merge and we can roll back if we need to." Sharp: "A change to the skill or the digest job triggers the deploy. You know it worked by sending a test capture and getting the digest back, rather than by trusting a green tick. To get back, republish the previous version, which takes about five minutes and has been practised once before anyone else had it. That has to be handled separately." The sharp version can be followed by a stranger under pressure. The vague one cannot. Working draft: What triggers a deploy to each environment: [merge, tag, manual run, schedule] How you know it worked: [the check you make against the running thing] The route back: [exact steps and roughly how long] Task: Decide whether a person who has never done this could deploy, confirm and roll back from these three lines alone. If not, rewrite them to meet the standard above. If the route back does not exist yet, say so plainly rather than describing one nobody has ever run. Check: - Does "how you know it worked" check the running thing, or does it trust the report of whatever ran the deploy? - Have you actually performed the rollback, or only assumed it? - Do data changes ride along with the code? Does undoing one undo the other? Return: - Verdict: clear, or needs work - The corrected three lines - Anything that has never actually been tested, named as such ``` Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it. Deciding the route back is the decision. Knowing where the thing actually runs is the craft. That is [Where the code runs](https://vibe2value.com/where-the-code-runs/) plus [Guaranteeing the steps that matter](https://vibe2value.com/guaranteeing-the-steps-that-matter/). ## The same idea on a recipe card A cook who has never taken a plate back off the pass does not really know how. The wrong plate is not the problem. The problem is the twenty minutes of standing there working out what to do about it, because nobody had thought it through while things were calm. Kitchens that run well have a stock answer ready before service. Remake it. The spare is here. The answer exists before it is needed, which is the only time it is cheap to work out. The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See [the recipe card](https://vibe2value.com/project/recipecard/). ## What it really means A deploy has two halves. Everyone builds the outward half, because nothing works until they do. Almost nobody builds the return half, because everything works without it right up until the moment it does not. There is a second trap in how you know it worked. A runner can report success for a step that did nothing. If your confirmation is a green tick rather than something you checked against the running system, you have confirmed the report rather than the deploy. And data usually comes apart from code. A rollback of the code is not a rollback of a migration. Finding that out during an incident is the expensive way to learn it. ## Make deploy and rollback concrete Compare the version that sounds responsible with the version somebody could act on. - **Too vague:** It deploys automatically when we merge and we can roll back if we need to. - **Concrete enough to act on:** A change to the skill or the digest job triggers the deploy. You know it worked by sending a test capture and getting the digest back, rather than by trusting a green tick. To get back, republish the previous version, which takes about five minutes and has been practised once before anyone else had it. The second version can be followed by somebody who has never done it, at the worst possible time, which is when it will actually be read. Both versions come from **consideredContent**, the one project carried through all 35 ideas. [See the project](https://vibe2value.com/project/considered-content/). Something is wrongon live, right nowIs the routeback written?yesnoTwo minutesyou have done itAn hourworking it out nowdecided months ago, while nothing was wrong A route back you have written and taken once costs two minutes. One you have only assumed costs an hour, and you pay it while the thing is broken and somebody is waiting. The difference between those two was settled months earlier, on a quiet afternoon when nothing was wrong. ## Check deploy and rollback - **Pass:** Someone who has not done it before can deploy to each environment from this file, confirm it landed and get back to the previous version. - **Fail:** The route back is not written down, or "how you know it worked" is that nobody complained. The route back is not real until somebody has taken it. ## What you'll walk away with This post is about the running decision: what has to be true once the thing is already live. You'll come out with your own `knowledge-base/system/environments/deploy.md` written and sharpened: every environment named, what triggers a deploy to each, the check that confirms it landed against the running thing and the exact route back with a rough time on it. ## Write it down Your `deploy.md` is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again. `knowledge-base/system/environments/deploy.md` is just a suggested name and place for this information. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI. ## Risk and mitigation - **Risk:** Something goes out that should not have, at the worst time. The first person to look has to work the way back out from scratch. - **Mitigation:** Write the route back before you need it, then take it once on purpose while nothing is wrong. ## Key takeaway Do not call a deploy finished until someone who has not done it before could take it back. ## How to document your deploy and rollback Write it up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this. ``` # Deploy ## Answer What triggers a deploy to each environment: [merge, tag, manual run, schedule] How you know it worked: [the check you make against the running thing] The route back: [exact steps and roughly how long] ## Evidence When you last rolled back, how long it took and what surprised you. ## Decision What you are optimising for. What you are accepting, for example forward-only migrations. ## Risk What breaks if this is wrong. ## Standing instruction What the AI should do every time it touches this. For example: if a change alters the deploy or the data shape, say what it does to the route back before writing the code. ```