fix(mothership): persist embedded workflow block positions

[BillLeoutsakosvl346]

Summary

Restores position persistence when an editable workflow is embedded as a Sim Chat resource.

The embedded canvas already allowed block movement visually, but it did not wire the drag start/stop lifecycle that records undo state and calls the existing collaborative batch-position operation. This PR makes the interaction policy explicit: editable embedded canvases can move blocks, but cannot structurally re-parent them; normal editable canvases retain both behaviors; read-only/locked/snapshot canvases retain neither.

No new API, persistence protocol, debounce, schema, or public type is introduced.

• Slack ticket and before recording: https://sim-ai.slack.com/archives/C093DF8MA21/p1786662044110359
• Root cause: embedded canvases set nodesDraggable={false} and omitted onNodeDragStart/onNodeDragStop, so React Flow could show transient movement without crossing the workflow's collaborative persistence boundary.
• Fix: reuse the existing drag-stop path and collaborativeBatchUpdatePositions, while continuing to skip embedded container-intersection/re-parenting logic.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• Other: ___________

Testing

Automated validation on the latest origin/staging base:

• bunx vitest run 'app/workspace/[workspaceId]/w/[workflowId]/utils/workflow-canvas-helpers.test.ts' — 19 passed
• bun run format:check — passed
• bun run lint:check — passed (one pre-existing unused-suppression warning in lib/workspace-files/shell-layout.test.ts)
• bun run check:audits — 33/33 passed
• bun run docs-manifest:check — passed
• bun run check:migrations origin/staging — no new migrations
• bunx turbo run type-check — 26/26 tasks passed
• bun run test — 19/19 workspace tasks passed; @sim/app 2,212 files and 31,288 tests passed (3 files/46 tests skipped)
• CI-equivalent bunx turbo run build --filter=@sim/app with .github/workflows/test-build.yml environment values — passed
• git diff --check — passed

Browser verification used authenticated Chrome against dedicated local app/realtime processes on ports 3013/3014 and a disposable workflow/chat:

Scenario	Result
Main-editor drag, live embedded update, and main-editor reload	Passed
Embedded drag and live main-editor update	Passed
Embedded reload and close/reopen	Passed
Open workflow in the main editor after embedded drag	Passed
Embedded drag over Loop changes position without changing Loop membership	Passed; persisted subflow membership remained unchanged
Normal-editor drop into Loop	Passed; collaborative parent update added the block to Loop membership
Embedded pan, double-click zoom, and Open workflow	Passed
Embedded selection editing, block editor opening, connections, and re-parenting remain unavailable	Passed

The disposable workflow and chat were soft-deleted after verification.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

Screenshots/Videos

1. Embedded canvas immediately after the drag

2. Same embedded position after reload

3. Main editor showing the same persisted position

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Aug 24, 2026 10:10pm

[cursor]

PR Summary

Medium Risk
Touches core workflow canvas drag/persistence and collaborative updates; scope is narrow (policy helper + gating) but regressions could affect main-editor re-parenting or read-only canvases.

Overview
Introduces getWorkflowCanvasInteractionPolicy so drag behavior depends on edit access and embedded vs full editor: editable canvases can move blocks; only the full editor can re-parent into/out of loops and parallels.

Embedded editable workflows previously looked draggable but did not run onNodeDragStart / onNodeDragStop or set nodesDraggable correctly, so moves never hit the existing collaborative position path. The canvas now wires those handlers and nodesDraggable from canDragNodes, while container drop highlighting and re-parenting still bail when canReparentNodes is false.

^{Reviewed by Cursor Bugbot for commit 04ec0a4. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Greptile Summary

Restores durable block-position updates in editable embedded workflow canvases while preserving read-only restrictions and preventing embedded re-parenting.

• Introduces an explicit interaction policy separating node movement from structural re-parenting.
• Wires embedded node drag start and stop into the existing collaborative persistence and undo lifecycle.
• Adds focused policy tests for normal, embedded, and read-only canvases.

Confidence Score: 5/5

The PR appears safe to merge, with embedded position persistence correctly enabled without exposing structural re-parenting or read-only edits.

The new permission policy preserves snapshot, workflow-lock, block-protection, and effective-access restrictions, while embedded drag-stop persists clamped positions and exits before any parent or edge mutation.

Important Files Changed

Filename	Overview
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/workflow.tsx	Applies the interaction policy consistently to node-level dragability and React Flow callbacks while retaining the early guard against embedded re-parenting.
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/utils/workflow-canvas-helpers.ts	Adds a small policy helper that permits position edits only with edit access and permits re-parenting only outside embedded canvases.
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/utils/workflow-canvas-helpers.test.ts	Covers the interaction-policy matrix for editable normal canvases, editable embedded canvases, and both read-only variants.

_{Reviews (1): Last reviewed commit: "fix(mothership): persist embedded workfl..." | Re-trigger Greptile}

[icecrasher321]

@BillLeoutsakosvl346 does this ignore putting blocks into loops/parallels?