Publish sync activity from the CLI so every UI shows syncs however they were started

[youknowriad]

Related issues

• Fixes STU-2176
• Builds on Block site start/stop and other site actions while a sync, import or export is touching the site #4954 and Let every Studio host receive CLI events, so the browser UI sees changes made elsewhere #4955 (both merged); part of Unify how the CLI and Studio apps communicate: remaining work #4963 (phase 1)

How AI was used in this PR

Claude Code (Opus 5.5) designed and implemented this with me. It traced why the two push implementations diverged (git history) and wrote the tests. It also verified the full pipeline with the built CLI in an isolated config: a studio pull run from a terminal, using a deliberately invalid token, showed up live in the browser UI. I reviewed the design and the diff.

Proposed Changes

• Problem: when the agent (or a terminal, or another window) pushed, pulled or published a preview, the UI didn't react: no progress, no busy state, no toast, no refreshed data. Only syncs started from that window's own buttons reported anything, because the progress plumbing was tied to the button's own request.
• Fix: the UI reacts to state, not to who started the sync. The CLI commands that run syncs (push, pull, preview create/update) now publish their activity as events: pending, phase and progress, then success, error or cancelled. The UI's sync indicator, toasts and data refreshes are all driven by those events, so a sync looks the same whether a button, the agent or a terminal started it.
• One push implementation instead of two. The button's push used to run a separate reimplementation (pushSite) built from the same pieces as CLI push. It existed because CLI push had no structured output. Since then, selective sync, cancel and waiting for the remote import were each added to one copy only. The button now runs studio push, just as pull already ran studio pull.
  • CLI push gains --include-only, structured phases, the classified remote-import error messages, and --suppress-tracks-event.
  • pushSite, the per-sync progress channels (IPC and SSE), and the connectors' progress callbacks are all gone.
• Cancel now actually stops the CLI. The CLI's existing SIGTERM listener stopped Node from exiting, so a cancelled pull most likely kept running in the background. Push and pull now report "cancelled" and exit when the host terminates them. They ignore the signal once they're past the point where stopping is safe, following the same rules the UI uses to offer Cancel.
• AGENTS.md: a new pitfall entry, "One Implementation Per Site Operation", so this kind of drift doesn't happen again.
• Out of scope:
  • Cancelling a sync the agent started, from the UI. The agent runs syncs inside its own process, so the UI can't terminate them.
  • Import, which is still reported by the import dialog on the client.
  • Tracks. The UI still records sync events itself; moving that to the CLI would change the analytics props.

Testing Instructions

• Unit tests: npm test -- apps/cli/commands/tests apps/cli/lib/tests apps/ui/src/data packages/common/sites apps/local. They cover push phases, the classified failure, pull's reported result, cancel handling, and a sync the UI didn't start being shown and announced.
• Agentic UI, in both the Desktop app and studio ui:
  • Push and pull a connected site with the buttons. Progress, cancelling during the upload or download, the toasts and the refreshed "last synced" time should behave as before.
  • Ask the agent to push, pull or create a preview. The sidebar indicator, the dropdown progress and the toasts should appear as if you had clicked the button.
  • Run studio pull --path <site> --remote-site <id> --options all in a terminal. The open UI should follow it the same way.
• ⚠️ Needs a real push and pull against a live site before merge: the end-to-end check above only exercised the error path.

Pre-merge Checklist

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

🤖 Generated with Claude Code

[wpmobilebot]

📊 Performance Test Results

Comparing 8305bdb vs trunk

app-size

Metric	trunk	8305bdb	Diff	Change
App Size (Mac)	1455.51 MB	1455.50 MB	0.01 MB	⚪ 0.0%

site-editor

Metric	trunk	8305bdb	Diff	Change
load	1147 ms	1160 ms	+13 ms	⚪ 0.0%

site-startup

Metric	trunk	8305bdb	Diff	Change
siteCreation	7521 ms	7515 ms	6 ms	⚪ 0.0%
siteStartup	2873 ms	3369 ms	+496 ms	🔴 17.3%

---

Results are median values from multiple test runs.

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