[chubes4]

Related issues

• Follows Studio: Finish site creation when the CLI reports done, not when telemetry lets the process exit #5522.

How AI was used in this PR

Claude (via the Pi coding agent in a Roadie session) traced the start/stop timing, wrote the change and the test, and measured the CLI message ordering below. I reviewed the diff and the measurements.

Proposed Changes

Starting or stopping a site from the app resolves when the site start/site stop process exits. After finishing, both commands send a Tracks event, so the status button keeps its spinner while the request completes.

Since #5522, the start/stop could resolve on the CLI's done message instead, but that loses a race. The site stays "transitioning" until the event releasing its start/stop operation arrives, and that event reaches the app in the same millisecond as done (8 of 8 runs). When done wins, the app sees the operation still held and refetches the whole site list. In a CI run with only that change, siteStartup went from 1,594 to 1,868 ms (build 24349).

This PR removes the race instead of waiting it out:

• site start and site stop report the site after the operation is released, with its running state.
• startSite/stopSite resolve with that site when the command reports done, and the app writes it into the cached list the same way it applies a site event.
• With nothing to show, such as a site serving its PHP error page or a stop that failed, the app reads the list as before.
• This replaces the check for whether the list already showed the site, so start/stop no longer depend on the order of events and command results.

Measured with a production CLI build forked over IPC:

reported site after start / already running	running: true, no operation
reported site after stop / already stopped	running: false, no operation
failed stop	no result, rejects as before
time from done to exit, telemetry on (from #5522)	start 161–174 ms, stop 165–326 ms

That tail is the time the app no longer waits after a start or stop. It depends on the user's connection. CI skips Tracks, so CI's performance metrics should stay flat for siteStartup.

Testing Instructions

• npm test -- apps/ui/src/data/queries/use-sites.test.tsx
• The updated test starts and stops a site whose release event hasn't arrived yet. It shows the reported site without refetching the list, and fails without this change.
• Manually, in a packaged build with analytics on: start and stop a site, and the status button settles as soon as the site is running or stopped.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing e115743 vs trunk

app-size

Metric	trunk	e115743	Diff	Change
App Size (Mac)	954.75 MB	954.75 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	e115743	Diff	Change
load	1200 ms	1238 ms	+38 ms	⚪ 0.0%

site-startup

Metric	trunk	e115743	Diff	Change
siteCreation	5374 ms	5070 ms	304 ms	🟢 -5.7%
siteStartup	1551 ms	1543 ms	8 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)