[Change] Start a built Gutenberg site's dev server without the build watch - #500

## Why

While the setup wizard is still installing (banner *step 2 of 3,
Installing dependencies*, `npm ci` streaming in the terminal), the
**Install npm dependencies** step flipped to **COMPLETED** and **Run
full build** to **READY** with its button enabled. A click there starts
a build over a half-written `node_modules`. Seen on Windows during the
v1.2.0-beta.1 pass on a Gutenberg site, whose install is long enough to
switch windows during; the rule is shared by every site (#495).

## What changes

**Root cause.** `computeSetupStepState` took the step as done when
`node_modules` exists and is non-empty and the last install did not
fail. It ignored `installing`. Any status refresh mid-install (switching
back to the window triggers one) reads the partial directory as done.

**The fix.** An install still running overrides existence, exactly as a
failed one already did (#42): `installOk` also requires `!installing`.
One line. When `npm ci` exits 0 the flag clears, the next status read
sees the full directory, and the step completes as before.

## How to test this

Platforms: either. Build: the Buildkite artifact for the current head,
or `npm start` from the repository root.

**Starting state:** no site yet, or a site whose wizard is at the
download step.

1. Create a Gutenberg site (its install runs for minutes) and wait until
the banner reads *step 2 of 3, Installing dependencies*.
2. Switch to another application and back, two or three times, while the
terminal still shows `npm http fetch` lines. Expected: **Install npm
dependencies** keeps its in-progress state and **Run full build** stays
locked.
3. Let the install finish. Expected: the step turns **COMPLETED** and
the build starts on its own (the wizard chains it).
4. On an existing, fully installed site, open it. Expected: the step
reads **COMPLETED** as before; nothing regresses for a site that is not
installing.

**What must not have happened:** **Run full build** enabled while `npm
ci` is running; a completed site's install step reading as not done.

Test: `tests/unit/setup-steps.test.cjs`, *a half-written node_modules
during an install does not complete the step*. Fails on trunk, checked
in a trunk worktree.

## Risks and limitations

None beyond the one-line rule. The `installing` flag is set by the
renderer for the wizard's install and for a manual `npm install` from
the terminal alike, so both paths get the same hold.

## Related

Fixes #495. Part of the v1.2.0-beta.1 pass, follows #489, #491, #493.

---

<details>
<summary>Review outcome (required — see AGENTS.md)</summary>

- **Review:** completed in-session on head 44570f4 / base 4c53900.
Deterministic layer: eslint clean, `npm test` 1589 pass, 33 journeys.
Judgement: the change is one predicate in a pure module with a test that
fails on trunk; the only question checked was whether `installing` is
set on every install path (it is, for the wizard's chain and for a
terminal `npm install`), so the hold applies to both; no security,
performance or platform surface.
- **Since review:** `44570f4 → 2b6634c` checked: rebase onto trunk
`5167e88` (#500) only, no conflict, same diff; eslint clean, `npm test`
1594 pass on the new head. Reproduced again on 19 Sep 2026 on Windows
with the trunk artifact, see #495.

</details>

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

…504)

## Why

On a Gutenberg site the wizard's **Run full build** step flipped to
**COMPLETED** ("Build complete") and **Start dev server & finish
wizard** to **READY** while `npm run build` was still running: banner on
*step 3 of 3*, terminal in phase 4 (widgets). Seen on 20 Sep 2026 on
Windows (UTM VM, trunk artifact `ffbdb3c`), right after #496 fixed the
same thing for the install step. Since #500 a click there starts
Playground at once on that half-written `build/` (#502).

## What changes

**Root cause.** `computeSetupStepState` took the build step as done when
the status's `hasBuilt` was true. That is one marker file,
`build/scripts/block-library/index.min.js`, which Gutenberg's build
writes mid-way (phase 2), with routes, widgets and the PHP registries
still to come. Any status refresh during the build (switching windows is
enough) read the site as built. The `building` flag was ignored, exactly
as `installing` was in #495.

**The fix.** The step is built only when the marker is there **and** no
build is running **and** the last build did not fail: `builtOk =
hasBuilt && !building && !buildFailed`. It drives the build step's done
state and the dev step's ready state; the step's label and the button's
variant follow the step state instead of the raw flag. The failed-build
half comes from the self-review: a build stopped or failed late leaves
the marker on disk, and within a session `buildFailed` is never stale
(every build path clears it on success), so a flag still set outranks
the marker.

## How to test this

Platforms: either; Windows is where the build is slow enough to catch.
Build: the Buildkite artifact for the current head, or `npm start` from
the repository root.

**Starting state:** no site, or a Gutenberg site at the download step.

1. Create a Gutenberg site and let the wizard reach *step 3 of 3*.
2. While the terminal is past *Transpiled …* and into *Built route …*,
switch to another window and back, two or three times. Expected: **Run
full build** stays **IN PROGRESS** with its button busy, **Start dev
server & finish wizard** stays **LOCKED**.
3. Let the build finish. Expected: the step turns **COMPLETED**, "Build
complete", the dev step **READY**; click it and the site opens.
4. New site, same steps, but press Ctrl+C in the terminal during *Built
route …*. Expected: the build step reads **FAILED** with "Retry the
build", the dev step stays **LOCKED**; retry, let it finish, and the
step completes.
5. Open an existing, fully built site. Expected: the step reads
**COMPLETED** as before.

**What must not have happened:** the dev server enabled while `npm run
build` runs; a build stopped mid-way reading "Build complete"; a built
site's step reading anything but complete.

Tests: `tests/unit/setup-steps.test.cjs`, *a marker written mid-build
does not complete the build step* and *a build still running reads in
progress, whatever the marker says* fail on trunk (`build.done` was the
raw marker) and pass here; *a build that failed over an existing marker
reads failed, not complete* replaces the earlier test that had the
opposite premise, with the reason in its comment. Lint clean, 1596 unit
tests pass.

## Risks and limitations

- `buildFailed` is session-local: after an app restart a build that
failed late over an existing marker reads complete again, as on trunk.
Persisting it like the install outcome is in #503.
- Outside the wizard, **Start dev server** and **Start build watch** are
still reachable while a build runs from the terminal or an apply;
pre-existing, #503.

## Related

Fixes #502. Same rule as #496 (#495). Follow-up #503. Part of the
v1.2.0-beta.1 pass.

---

<details>
<summary>Review outcome (required — see AGENTS.md)</summary>

2 [fix here] · 1 [follow-up] on `e5b762d` — both fix-here fixed in
`f1ed783`.

- Fixed: a build that failed or was stopped over an existing marker read
complete and unlocked the dev server (`builtOk` now requires
`!buildFailed`; `build.failed` no longer tests the raw marker; the
colliding test's premise revisited and rewritten).
- Fixed: the "In progress" status string had no ladder assertion; added.
- Fixed (style): the build button's variant keyed off the raw marker
while its label followed the step state.
- Deferred to #503: the skip-wizard path (action bar reachable while a
build runs) and persisting the build outcome across restarts; both
pre-existing.

- **Review:** completed — `/self-review` (Explore subagent, judgement
pass; lint and unit inline); reviewed head `e5b762d` / base `ffbdb3c`
(trunk); evidence: findings above; outcome: 2 fixed, 1 deferred.
- **Since review:** `e5b762d → f1ed783` checked: the fixes above plus
their tests; lint clean, 1596 unit tests pass on the new head.

</details>

<details>
<summary>Screenshots or recording</summary>

No new surface: the same checklist, now honest about a running build.
The Windows screenshot of the bug is on #502.

</details>

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

## Why

`v1.1.0` shipped on 16 September. Sixteen commits since then reach
trunk, and this beta is the first build that carries the Gutenberg
contribution target (#251): a site can now be a checkout of
`WordPress/gutenberg`, served through Playground as a plugin in a stock
WordPress, with a GitHub issue as its work item, pull request checkout
from that issue, and a pull request opened against `WordPress/gutenberg`
from the app. The manual pass of that work ran on macOS and on Windows
over 18 to 20 September and found six issues; the four that affected the
first-run path are fixed on trunk (#489, #493, #496, #500, #504, and
#491 for the hint), the rest are on the `v1.2.0-beta.2` milestone.

`electron-builder` derives artifact names from `package.json`, so the
version has to move before the tag and the artifacts exist. A beta is a
pre-release, so `releases/latest` stays on `v1.1.0`.

## What changes

Only the version. All three package-version fields in `package.json` and
`package-lock.json` move together from `1.1.0` to `1.2.0-beta.1`. No
dependency versions change, and there is no application behaviour change
in this PR.

## How to test this

Platforms: any for the suite; macOS and Windows for the artifact checks
that follow the merge.

1. `npm run lint` is clean and `npm test` passes.
2. `node -e "console.log(require('./package.json').version)"` prints
`1.2.0-beta.1`.
3. `python3 -c "import
json;d=json.load(open('package-lock.json'));print(d['version'],
d['packages']['']['version'])"` prints `1.2.0-beta.1 1.2.0-beta.1`.

**What must not have happened:** no dependency version may change. `git
diff` must show exactly three changed lines, all of them the root
package version.

After merge, the release build must produce artifacts named
`wordpress-contributor-toolkit-1.2.0-beta.1-*`; the asar root must be
exactly `node_modules`, `package.json`, `src`, with npm 11 under
`node_modules/npm` and no `.codesigning` directory; on macOS
`CFBundleShortVersionString` reads `1.2.0-beta.1`.

## Risks and limitations

No UI change. The risk is a mis-scoped edit in `package-lock.json`,
where dependencies also carry version fields; the replacement was
confined to the first 2000 bytes of the file, which hold the two root
entries and nothing else, and both files were re-parsed as JSON
afterwards.

Verified locally on this branch: lint clean, `npm test` 1596 pass / 0
fail.

## Related

Part of #251. Release notes follow on the pre-release; docs publish for
the tag per #487.

---

<details>
<summary>Review outcome (required — see AGENTS.md)</summary>

0 [fix here] · 0 [follow-up]. Deterministic layer only: lint clean, 1596
tests pass, both files valid JSON, diff confined to the three root
version fields. No judgement pass was run: this change has no logic to
review.

- **Review:** completed — deterministic layer, in session; head is the
single bump commit / base `b5ca272` (trunk); evidence above; outcome:
nothing to fix.
- **Since review:** none.

</details>

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

…ng temp path (#531)

## Why

The manual **Real WordPress setup** workflow fails both Gutenberg jobs
on trunk ([run
35885170190](https://github.com/WordPress/contributor-toolkit/actions/runs/35885170190),
229d3eb), so it cannot vouch for v1.2.0 final. Core passes on both
platforms. The two Gutenberg failures are different, and neither is an
app bug on macOS:

- **macOS:** the test waits 3 minutes for the watch to reach `watching`.
Since #500 it starts the watch by hand after the wizard's build, and
`npm run dev` removes `build/` and redoes the whole build first: the
wizard's own build took 554 s on that runner. The tab was still
`(building)` when the wait ran out.
- **Windows:** the watch exited 1. Gutenberg's `tsc --build` in `npm run
dev` reported `TS2349 ... deprecated ... has no call signatures` in
`packages/theme/src/private-apis.ts`, after the one-shot build had
passed. The site sat under the runner's short 8.3 temp path
(`C:\Users\RUNNER~1\...`) while TypeScript cited the long one
(`C:/Users/runneradmin/...`).

## What changes

Test only, no app code.

- Bigger time budgets, sized for the slowest runner days seen: the
Gutenberg watch wait goes from 3 to 30 minutes, the wait for the site to
be ready from 40 to 75 (a Windows `npm install` has taken over 40), the
Playwright test budget from 45 to 110, and the job's limit from 60 to
120. The test proves the setup works, not that it is fast; the cost is
that a real hang takes up to two hours to report, on a workflow only
ever run by hand.
- The temp parent is built on `fs.realpathSync.native( os.tmpdir() )`:
the long path on Windows, `/private/var` on macOS. No contributor's site
sits under an 8.3 path. The short path as the cause of the Windows error
is a hypothesis this PR's run checks; see Risks.

## How to test this

Platforms: both, on GitHub's runners. Nothing to do by hand: the
workflow is the test.

**Starting state:** this branch.

1. Dispatch **Real WordPress setup** on `fix/real-setup-watch-wait`,
platform `both`. Running: [run
36058342616](https://github.com/WordPress/contributor-toolkit/actions/runs/36058342616)
on 6aa9462. The earlier [run
36016090853](https://github.com/WordPress/contributor-toolkit/actions/runs/36016090853)
on d741208 ran out of the smaller budgets, see the comment below.
2. Expected: four green jobs. Gutenberg reaches `Build watcher
(watching)`, and Stop leaves no watcher process behind on macOS.

**What must not have happened:** the Core jobs slowing down or changing;
they take none of the new waits.

## Risks and limitations

- If Windows Gutenberg still fails with the same TS2349 on the long
path, the short-path hypothesis is wrong and the error likely comes from
Gutenberg trunk (`24.1.0-rc.1` in the failing run). I will report it
here before changing anything else.
- The run is a workflow dispatch, so it does not show as a check on this
PR; its result will be posted as a comment.
- Review: 1 [fix here], fixed (the budget raise).

## Related

Follow-up to #500, which made the test start the watch by hand.

---

<details>
<summary>Design decisions and alternatives considered</summary>

- **Raise the budget in the config, not `test.setTimeout()` for
Gutenberg only.** One number for the whole run is easier to reason about
against the job's limit, and Core finishes well inside it anyway.
- **Not dropping the watch step.** It is what the process-tree check
after Stop exercises on a Gutenberg site.

</details>

<details>
<summary>Review outcome (required, see AGENTS.md)</summary>

- **Review:** completed, fresh-context subagent following
`.github/instructions/code-review.instructions.md`; reviewed head
d741208 / base c2b47c1; `npm run lint` clean, `npm test` 1665 pass 0
fail; 1 [fix here] · 0 [follow-up]: the 45-minute Playwright test
timeout, not the job's 60, bounded the new 15-minute watch wait, so a
slow Windows setup would time out the whole test instead. Fixed by
raising it to 50.
- **Checked fine:** realpath keeps the dialog path, `sitePath`,
`getSiteStatus` and the `pgrep` match on the same path; cleanup removes
the path it was given.
- **Since review:** d741208 → 6aa9462, budget numbers and their comments
only (workflow `timeout-minutes`, config `timeout`, two waits in the
spec); no logic changed, lint clean.

</details>

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>