Run the initial setup steps as one chain - #276

Stacked on #274. Review that one first — it is the kill path this PR's Stop button depends on. The diff below is this branch against #274, not against trunk.

Why

After the clone finishes, the setup checklist stops and waits. Install npm dependencies, then Run full build — two clicks, with no decision to make between them. The contributor's only job is to notice a step ended and press the next button.

That is the wrong shape for a wizard. Someone who walks away during the clone — which is what you do during a ten-minute clone at a Contributor Day — comes back to a checklist waiting on them rather than to an environment they can work in. #246 makes the case at length.

What changes

Setup becomes the third chain of the shape the app already runs twice: planUpdateSteps (fetch → install → build) for a trunk update, planApplySteps (apply → install → build) for a patch, both sharing updateStepStatuses and updateOutcome. planSetupSteps joins them, and the chain starts on its own when the clone finishes — no button.

What makes running unattended reasonable rather than presumptuous, and each of these is the reason the issue gives:

• It is visible. A banner names the running step and counts it (step 2 of 3), and every line of npm output still goes to the Terminal (Run first full build hides npm output and failures from the visible terminal #41).
• It stops. Stop setup, and Ctrl+C in the Terminal, end the child — install included, which is what Let Stop end a running npm install #274 is for.
• It stops at the first failure. A build on a half-installed tree cannot work, and its failure would bury the one that mattered (Initialization wizard treats partial npm installs as complete and prevents recovery #42).
• It starts once, on an edge. The clone going from running to finished, once per row. A site already cloned when its row appears never triggers, so reopening the app on a half-finished site lands on the manual checklist rather than launching a half-hour build nobody asked for.

Deliberately not in it: starting the dev server. #246 lists it as the fourth link, and I left it out — that step also calls markSkipWizard() and hands the contributor to a WordPress setup wizard in a browser, so running it unattended would end the checklist on their behalf and leave a server listening that nobody asked for. Also not in it: resuming the chain after a stop. Retry is a plain button on the failed step; a cancel followed by a retry must not silently restart a half-hour build.

It also closes the open half of #44. The checklist ladder moves out of index.jsx into setupStepStatuses and gains a failed state, so a step whose last attempt lost says Failed, keeps its retry, and does not hand current to the next step. #258 fixed the label half ("Ready" until an action runs); the explicit failed/retryable state was the acceptance criterion still open, and a chain that can stop is what made it necessary rather than nice.

How to test this

Platforms: any for 1 and 4–6; do 2 and 3 on both macOS and Windows — process-tree killing is where they differ.

Starting state: the app, with no site for the WordPress repo you are about to create. This is a real clone plus a real install plus a real build, so budget for it — the point of steps 2 and 3 is that you do not have to sit through the build.

1. Create a WordPress Core site. Watch the Download WordPress development version step. It should say the install and build start on their own when it finishes.
2. When the clone finishes, click nothing. The blue banner appears, Install npm dependencies turns In progress, and npm output streams into the Terminal. When install ends, the build follows on its own and the banner reads step 3 of 3.
   • Start dev server & finish wizard must still read Ready and must not have started.
3. Press Stop setup while npm install is running. The install actually dies — check no node/npm child of the app survives. The build never starts, the banner is replaced by Setup stopped, and the install step offers Retry npm install.
4. Press Stop setup during the build instead (create a second site, let install finish). The whole Grunt tree dies, not just the runner (Quitting the app leaves dev servers and watchers running #83, Playground and stop handlers bypass the tested child-process modules #146).
5. A failing install. Easiest is to pull the network mid-install. The step reads Failed in red with its retry live, the build stays Locked, and the chain does not advance.
6. Reopen mid-setup. Quit during the build, relaunch, open the site. The checklist shows the real state from disk and the chain does not restart by itself.
7. Skip initialization wizard during a running chain. The checklist goes away, the chain keeps running, the Terminal still shows it.

What must not have happened:

• The dev server must not have started, and the wizard must not be marked skipped. The chain ends at the build. If you land on a running server or a post-init view without clicking, that is the regression.
• No orphaned npm/node process after a Stop, on either platform.
• A stop must not be reported as a failure. A killed npm exits non-zero — on Windows without even a signal — so the step must read Setup stopped, not npm install failed.
• A stop must not respawn itself. Watch for a second install starting a moment after you stopped the first (that is Let Stop end a running npm install #274's cancelled flag doing its job).
• Reopening the app must not start anything. Step 6 is the one that would be easy not to notice: it only misbehaves on a site you left half-finished, and the symptom is your laptop quietly building for half an hour.

Risks and limitations

The end-to-end chain has not been driven by hand. I could not: this Electron build does not expose its accessibility tree to the automation available here, and creating a site needs a native folder picker. What I did verify is that the renderer bundles and mounts with these changes, lint is clean, and both Node runtimes are green (840 tests). Steps 1–7 above are unverified and want a human, and step 3 in particular is the one that justifies the whole feature.

buildFailed is session-local. Only the install outcome is persisted (src/main.js records it on the site's meta), so after a restart a failed build reads Ready again rather than Failed. That is the honest fallback — the app still knows there is no build on disk, just not that the last attempt lost — and persisting it is a separate change.

Auto-start is once per row mount, not once per site. Switching away from a site and back during a clone remounts the row; if the clone finishes after that remount the chain still fires, which is the wanted behaviour, but it does mean the guard is memory, not state on disk. The hasNodeModules check is what stops that mattering.

The banner says the build can take up to half an hour on Windows (#72). It runs a production build where a dev build would do — that is #92, untouched here, and auto-starting makes it more worth fixing, not less.

Related

Closes #246. Closes the remaining acceptance criterion of #44. Depends on #274. Makes #57 (the redundant nested npm install between the two steps) easier to fix now the two are one run.