One path, four ways through it
Every change follows the same path: you describe it, a command is picked, it is built, it is checked, and it becomes one commit. How do I ask for a change walks that path once.
What differs is how much of it your request actually uses. Below are the four kinds you will meet, each walked from the sentence you type to the commit, so you can tell in advance where yours is going to stop and ask you something.
Something small and settled
A label that reads wrong. A sentence in a screen. A spacing, a colour, the order two elements sit in.
You say what it should read and on which screen. Nothing here decides anything: there is no state to tell apart, no rule that comes out one way for one record and another way for the next, and no second reasonable answer to choose between.
Because of that, the investigation step is skipped. What replaces it is one reading: the screen you named is opened to confirm it holds what you said it holds, and the thing being changed is searched for across the project to confirm it is not read somewhere you did not name. If it is — the same wording appearing on two other screens — the request stops being this size and takes the long route instead, because somebody would be reading something nobody decided to change.
Then it is built, every file it wrote goes through the analyzer, and if the result shows on a screen somebody opens it and looks. One commit. This is the fastest route and the one most requests take.
What looks small and is not. A column added to a list, a filter, a field pulled in from somewhere else. They read like one-line requests, but they change what the screen fetches, and that is the change most likely to slow it down — so they take the long route, and their speed is measured before and after.
Something you can see
A screen, a component, a flow, a control, data displayed.
Same route as whichever of the other three your request belongs to. What changes is the proof.
A change a person can see is never proved by the command that wrote it. It is handed to the verification command, which opens a real browser, walks the promise point by point, and reports one result per point plus a single verdict — no partial passes. It is walked in every state the plan tells apart, not only the one your database happens to be in, and it is walked again after the last step that wrote data, because validation itself can move a flow into a state the first pass never saw.
What is checked is not that the page loaded. Each element is checked for being fully visible with nothing covering it; a modal is checked for opening above the page, scrolling inside itself, and leaving no backdrop and no locked scroll behind when it closes. Every result names the screen and the element.
A failing pass produces a correction, not an excuse. The verification writes the correction itself, into the same plan and ready to be built, and the cycle runs again — three builds in all. After that the plan is what needs revisiting, and you are told so rather than watching a fourth attempt.
Something complex
It decides something. It reaches several places. Or it is not clear yet what it should do.
This is the one that is planned before it is built. If you asked for it to be built anyway, the run stops before touching a file, hands you every gap it found together, and tells you to plan it — it does not start planning on your behalf and it does not answer half the questions here and half there.
Planning reads what the project already documents, explores the code for what that leaves open, puts the whole scope to you at once, and asks you only what reading cannot settle. Then it checks every claim the plan makes against the code before the plan is written down, so a decision resting on something untrue is caught before it becomes work. It also reads the code the change reaches, so the technical choices that change the risk or the cost are asked now rather than halfway through the build, and the plan closes with a technical plan: where the change runs and the risks to watch for. When the change is something you will see, you are shown a drawing of the screen as it is and as it would be, and you approve the design before anything is built.
What you get back is a written plan, saved in your project so it outlives the conversation. The build step follows it instead of improvising, treats its decisions as settled, and does not reopen them halfway through. Its technical plan is the one part followed as guidance: where the code turns out different, the build corrects it and keeps going without asking you, unless the correction would change what the plan asks for. If the code turns out to refute something the plan argued from, the run stops and hands it back to planning rather than guessing — because everything built on top of that claim was built on something untrue.
Planning before building covers what it asks you and what it leaves behind.
Something urgent and broken
It worked yesterday. It does not work now. People are waiting.
Say it is broken and say what you see: the screen, what you did, what happened, and who it happens to. If it only fails for one role or one kind of record, say that too.
The first thing that happens is that it gets reproduced. Before a single file is modified, the failure is reached through whatever actually exercises it — the screen for what you see, the command or job for what you do not — in the states you named. A defect that does not reproduce stops there and asks you rather than receiving a speculative fix: a fix aimed at something that is not happening is a change nobody can verify.
Once it reproduces, the fix is the smallest one that makes the confirmed behavior work. Existing behavior outside the defect is preserved, and a redesign, a rewrite or an opportunistic improvement is not what a defect buys — unless you asked for one.
If the urgent change has to be planned, say it is urgent when planning asks. That answer has one concrete effect: a project with no product vision written down normally has to write one before planning starts, and an urgent task carries on without it and is told the vision is still worth writing later — see Write the product vision.
What being in a hurry does not skip. The analyzer still runs over every file that was written, until they come back clean. What you can see is still opened in a browser and walked point by point. Nothing is pushed, no branch is created, and nothing that already worked is torn out to make room for the fix. Urgency changes what is investigated, never what is proved.
Next
- How do I ask for a change — the whole path in one pass, with the diagram.
- Planning before building — the fork the complex route turns on.
- What each command does — the command behind each of these routes.