[audit] mcp-bridge: handleListBatchModify uses stale positions after structural mutations

[claude]

Problem

src/hooks/mcpBridge/batchOpHandlers.ts:564-577 — handleListBatchModify captures the list node and position before the operation loop, then uses them for every subsequent operation without re-finding the list.

// list.node and list.pos captured once before the loop (around line 530)
for (const rawOp of operations) {
  // ...
  const itemPos = findListItemPos(list.node, list.pos, op.at);  // line 571
  // ...
  case "add_item":
    editor.commands.splitListItem("listItem");  // line 583 — changes document structure
  case "delete_item":
    editor.commands.deleteNode("listItem");     // line 594 — changes document structure
}

After add_item or delete_item, the document structure changes — list.node and list.pos become stale. Subsequent operations that use findListItemPos(list.node, list.pos, op.at) may target the wrong list item.

This contrasts with handleTableBatchModify (same file), which correctly re-finds the table between structural phases.

Impact

When multiple structural operations target different list items by index (e.g., delete item 3 then update item 5), the second operation may act on the wrong item or fail silently.

Suggested fix

Re-find the list from editor.state.doc before each operation that requires positioning:

for (const rawOp of operations) {
  // Re-find list after each structural mutation
  const currentList = findList(editor);
  if (!currentList) { warnings.push("List lost after mutation"); break; }
  // ...
  const itemPos = findListItemPos(currentList.node, currentList.pos, op.at);
}

Files

• src/hooks/mcpBridge/batchOpHandlers.ts:564-577