fix: complete live visual editing interactions

[steve8708]

Completes the remaining live visual-edit interaction lane after PR 5576. Adds a physical Chromium regression for distinct localhost URL screens at overview zoom, including deep selection and cross-screen drag handoff. More follow-up fixes and beta verification will land on this single PR.

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[steve8708]

Claude (Fable) watchdog — resume NOW (01:15Z / 18:15 PDT): turn ended early and the local stack is down

1. You ended your turn at 00:53:34Z with the cross-screen fix incomplete ("live cross-screen fix and beta verification remain incomplete") and have been idle since. That violates the standing rule (WDALL24): do not end the turn until the final PR is merged and beta-verified, or it is 12:30Z, or you hit a blocker only Steve can resolve. ~20 minutes of the 08:00Z implementation budget are gone. Resume and keep the turn running.
2. The local Clips dev server (localhost:3102) and the design bridge (127.0.0.1:7331) are BOTH DOWN — only Chrome :9222 is listening. "The current run times out loading the first live frame" may be exactly this. Restart Clips on 3102 and design connect --daemon using the PERSISTED bridge secret at templates/clips/.agent-native/design-bridge-token (the Make live visual-edit screens fully editable #5489 restart-safe path — do NOT re-pair the connection row), confirm the anonymous beta preview token registers 200 against 7331, then rerun the physical regression.
3. PR fix: complete live visual editing interactions #5580 is the final lane. Checks are green (26 success). Leave it OPEN and keep committing slices onto it. So far it carries three TEST-ONLY commits (fixture fixes); the product fix for live→live drag is still missing. Order: failing physical test → fix at the shared drop boundary → commit → Apply loop on Clips (diff pasted, then reverted) → interleaved undo/redo + signed-out pass → owner pointer proof → merge → beta E2E → honest handback.
4. Clock: implementation by 08:00Z, integrated + local matrix green by 10:00Z, merged by 10:30Z, beta E2E + fixes by 12:30Z. 06:00 PDT = 13:00Z. If an item will not converge by 10:00Z, say so explicitly; do not drop it silently.
5. Also verify the externally merged fix: keep overview live editors mounted in interact mode #5576 same-iframe change on beta once its Design deploy is live (same iframe, no "Preparing…", app state kept on return to Edit) — it is live without beta proof.

[steve8708]

Claude (Fable) watchdog — 01:30Z: the fixture is eating the budget; stop building it

You ended the turn again at 01:29Z (fourth early stop since 00:13Z) with FOUR test-only commits and no product fix. The Clips server and bridge are back (good). Two changes:

1. STOP building a bespoke multi-route fixture. The live→live drop bug is about the DROP BOUNDARY between two live screens, not about two distinct routes. Reproduce it with TWO screens pointing at the SAME existing physical fixture route (distinct screen ids) — that fixture already renders. If that does not reproduce the "drop had no effect" behavior within 15 minutes, drop the fixture entirely and reproduce against the REAL stack that is up now (Clips :3102 + bridge :7331, the real Design build in your local Chromium harness or the beta PR preview), fix at the shared drop boundary, and encode the regression AFTER the fix.
2. The turn keeps ending because you finish with a status summary and a status block. When your harness forces a turn end, end with the single next action you are about to take and nothing else; I will send "continue" within minutes. No more status-only turns.

Clock unchanged: implementation by 08:00Z, integrated by 10:00Z, merged by 10:30Z, beta E2E by 12:30Z (06:00 PDT).

[builder-io-integration]

⚠️ Review Agent ran into a problem and couldn't finish reviewing the latest commit.

We've been automatically notified and are looking into it. Push a new commit to re-trigger the review, or contact support@builder.io if this keeps happening.

Error ID: 66fcd028e2614567b75e52ce1e2ddc28

[builder-io-integration]

Builder reviewed your changes and found 2 potential issues 🔴

Review Details

Code Review Summary

This incremental update adds fresh redo request IDs and rollback routing, explicitly routes insert messages by screen, and acknowledges same-slot existing-node reorders. The prior redo-both-legs and repeated board-drop issues were verified fixed and their review threads were resolved.

Key Findings

• 🔴 High: The reuse guard compares the destination request screenId with the destination bridge's designCanvasScreenId, which is true for every routed cross-screen insert. Two live screens with the same stable node/runtime IDs can therefore reorder the destination's unrelated node, acknowledge success, and delete the actual source.
• 🟡 Medium: The unconditional acknowledgement for a no-op reorder is treated by the host as an inserted pending edit. Undoing that no-op can then delete the existing runtime element even though no DOM mutation occurred.

Focused unit and bridge checks were reported passing; Chromium-backed lifecycle tests remain unavailable because Playwright Chromium is not installed. Risk is standard. 🧪 Browser testing: Will run after this review (PR touches UI code).

[builder-io-integration]

🔴 Do not treat destination routing identity as source-document identity

e.data.screenId === designCanvasScreenId is true for every insert routed to this destination bridge, so it cannot prove that the incoming runtime instance already belongs to the same document as the source. If two live routes render the same node and runtime-instance IDs, this reuse branch reorders the destination's unrelated node, acknowledges the insert, and releases the paired source deletion. Pass an explicit same-document/reorder signal or avoid reuse for cross-screen inserts.

Additional Info

Found independently by 1 of 3 agents; confirmed against the destination-only screen routing semantics.

[builder-io-integration]

🟡 Do not record no-op reorders as inserted edits

When applyRuntimeReorder returns false because the existing node is already at the requested placement, this unconditional applied acknowledgement is still recorded by the host as an inserted pending structure edit. Undoing that no-op can delete the existing runtime element even though the operation made no DOM change. Use a distinct no-op acknowledgement that releases transaction waiters without creating a pending insert, or only acknowledge as applied after a mutation.

Additional Info

Found by 1 of 3 agents; confirmed against the host's pending-edit acknowledgement handler.