Module layout_helpers 

Layout-tree + pending-action writers used by the tear-off / promote / redock handlers. SPEC_864 Phase 3/4 — all of them route through the reducer (seed_layout_via_reducer / queue_layout_actions_via_reducer); nothing here writes mstore directly anymore. setup_torn_off_block_layout is re-exported crate-wide (the pane app-API uses it).

Functions

queue_source_layout_delete 🔒

Phase E.5.5 — append a layout-delete action to the source tab’s LayoutState.pendingbackendactions so the source window’s frontend tears the moved block out of its layout tree on next poll. Used by the TearOffBlock/PromoteBlockToTab/RedockFloatingPane RPC handlers (the wcore-direct tear_off_block this used to mirror was dead code, deleted in SPEC_864 Phase 5).

queue_target_layout_insert 🔒

Floating-pane re-dock — enqueue an “insert” action on the TARGET tab’s LayoutState.pendingbackendactions so the target window’s frontend adds a new leaf for the redocked block through its LayoutTreeActionType.InsertNode reducer pathway.

queue_target_layout_split 🔒

Phase 4b/4c — enqueue a directional split action on the TARGET tab’s LayoutState.pendingbackendactions so the redocked block lands in the exact slot the ghost overlay previewed.

queue_target_stack_move 🔒

Tell the frontend that block_id was moved — already, in the reducer — to position relative to target_block_id (Command::LayoutStackMove): a same-pane reorder when both are already in one leaf’s stack, otherwise a cross-pane move. Matches LayoutTreeActionType.StackMove = "stackmove" in frontend/layout/lib/types.ts. position is the same "before"/"after"/"end" string pane.moveTab’s caller supplied — reused verbatim, not re-derived, so the frontend applies the identical operation rather than inferring it from resulting tree state. activate rides on LayoutActionData.focused — the same field queue_target_stack_push above already overloads for this purpose (that call hardcodes true, since CreateBlockInStack always activates; this one carries the caller’s actual activate value since a reorder may or may not). SPEC_PANE_TAB_DRAG_AND_DROP_2026_09_19.md §4.1, Phase 3.

queue_target_stack_push 🔒

Tell the frontend that block_id was added — already, in the reducer — as the visible tab of the pane holding target_block_id (Command::CreateBlockInStack). Matches LayoutTreeActionType.StackPush = "stackpush" in frontend/layout/lib/types.ts. SPEC_PANE_TABS_REDUCER_COMMANDS_2026_09_18.md §3.3.

setup_torn_off_block_layout 🔒

Phase E.5.5 — set up the layout tree for a tab that just received its first block via the TearOffBlock saga. Called from the TearOffBlock / PromoteBlockToTab handlers and the floating pane.open path after the saga’s reducer-state portion (CreateTab + MoveBlock) completes. (NOT RedockFloatingPane — that redocks into an EXISTING tab and goes through queue_target_layout_insert/_split instead; reagent P2 on #1971.)

source_delete_action 🔒

The frontend delete action for one block: its handler removes just that stack member (the leaf goes with the last one) and never runs closeNode.