Module layout 

Functions

apply_atomic 🔒

Apply a fallible structural mutation to a tab’s layout tree atomically: operate on a clone, run balance_node, and commit back to tab.rootnode only if both succeed. On any error the tab’s tree is left untouched — no partial mutation is visible to a later snapshot or to the next operation. [codex P2 #1868]

clear_dangling_focus_magnify 🔒

Clear the tab’s focus/magnify ids when they no longer resolve to a node in its (already-edited) tree, given their values from BEFORE the edit. Returns (was_focused, was_magnified): whether each one was cleared. Shared by every edit that can remove a leaf — a node delete, and a pane tab move that empties its source pane — see handle_layout_delete_node for the two ways an id can dangle after a delete.

handle_create_block_in_stack 🔒

Create a block and place it in a pane’s tab stack in one step. Placement is validated FIRST: if no pane holds target_block_id, nothing is created — a block never exists without a pane.

handle_layout_clear 🔒

handle_layout_delete_node 🔒

handle_layout_delete_node_by_block 🔒

SPEC_864 site #6 — delete the layout node holding block_id. Resolution happens here because the reducer owns the tree; the caller (the delete_block saga) only knows the block id.

handle_layout_insert_node 🔒

handle_layout_insert_node_at_index 🔒

handle_layout_move_node 🔒

handle_layout_queue_backend_actions 🔒

SPEC_864 Phase 4 — append backend actions to a tab’s pendingbackendactions queue. The reducer does NOT model the queue in TabRecord (it is a transient backend→frontend mailbox the frontend drains via REPLACE-clear slices, not layout-tree state), so this arm only validates and passes the payload through; the persist subscriber APPENDs it to LayoutState.pendingbackendactions.

handle_layout_replace_node 🔒

handle_layout_resize_nodes 🔒

handle_layout_set_tree 🔒

handle_layout_split_horizontal 🔒

handle_layout_split_vertical 🔒

handle_layout_stack_activate 🔒

handle_layout_stack_move 🔒

Reorder block_id within its own pane, or move it into a different pane — a same-leaf reorder never changes which member is visible unless activate is set. Refuses (an Error event, tree untouched) when either block doesn’t exist in the tab’s tree.

handle_layout_stack_push 🔒

handle_layout_swap_nodes 🔒

handle_set_focused_node 🔒

Phase E.4 (Option A) — set the focused layout-node id on a tab. Errors (non-fatal) if the tab is unknown to the reducer; no-op short-circuit when the value is already current. Empty node_id clears the field. Bumps the version only on real changes so a burst of identical sets doesn’t churn the event stream.

handle_set_magnified_node 🔒

Phase E.4 (Option A) — set the magnified layout-node id on a tab. Same shape as handle_set_focused_node. Empty node_id is the toggle-off / clear case.

op_error 🔒

Event::Error for an operation failure (pure-fn or balance error).

reconcile_focus_magnify 🔒

Clear focused/magnified ids that no longer resolve in the (post-op, post-balance) tree. balance_node’s single-leaf collapse can rewrite a parent’s id and structural ops can remove nodes, so every structural arm reconciles — same intent as handle_layout_delete_node’s post-walk.

stack_tree_edit 🔒

Event::Error for an unknown tab. Apply a pane-tab edit to the tab’s tree and emit the tree-only LayoutTreeReplaced (no slices: focus, magnify, leaf order and the pending-action queue are untouched). edit returns false when it found nothing to act on.

unknown_tab 🔒