Opening a document by any route other than clicking the sidebar tree left the sidebar highlight stale — internal markdown links, New File, open-in-split, and tab switching/cycling all did it. AppSidebar owned `selection` as local state, written in exactly two places: its own tree-click handler and its own inline-create. So the highlight answered "what did you last click in the sidebar", not "what document is open". Two sources of truth, and the sidebar's was an input event rather than state. Inverts the dependency. Workspaces now report the document they are actually showing via `WorkspaceProps.onActiveDocumentChange`; App holds that as `activeDocument` and passes it to AppSidebar, which renders it read-only and no longer tracks selection at all. The sidebar's click handler just calls onOpenEntry and lets the highlight follow the document opening. This is what makes the class of bug unreachable rather than fixed once: there is no longer anything a navigation feature must remember to update. A new way to reach a document keeps the highlight correct because the highlight is derived from what the workspace shows, not announced by whoever caused the change. The tiling side is `tabsModel.activeDocument(map, tileId)` — pure, and unit tested including the case that motivates the design: a tab switch is not an "open", yet must still move the highlight. Loading and errored slots count as shown, since the tile is displaying that request either way. Remaining seam, deliberately not closed: a *new workspace kind* could still forget to call onActiveDocumentChange. The contract is documented on the prop. Closing it structurally would require the shell to infer focus across a workspace's slots, which only the workspace knows. Also extracts `treeQueryKey` so the sidebar's file-tree query key has one definition; a second consumer is coming and a drifted copy would silently double the IPC. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>