"New Folder" Still shows up in Lists

[Adron]

The "New Folder" at the top of the Github backed lists still shows up in the native app. This should show up as there is not a "folders" feature to the lists.

[Adron]

Implementation plan

Root cause — a toolbar leak, not leftover Lists code

I grepped the whole tree. The string "New Folder" exists in exactly one place, and it is not in the Lists feature:

• App/Features/Documents/DocumentsSidebarView.swift:78-87 — a ToolbarItem labelled "New Folder" (folder.badge.plus), inside a .toolbar { } attached to the Documents folder-tree sidebar.

Nothing under App/Features/Lists/** declares it. ListRowsView renders its own inline action bar (New Issue / Add Row / Delete / view-mode picker) with no folder affordance. And the List Folders feature was fully removed in PR #19 (merge 898d063, 2026-09-06). So this is residue from the Documents sidebar bleeding into the window toolbar — not a surviving Lists feature.

Mechanism. App/Navigation/MainWindowView.swift:123 builds the detail column as:

} detail: {
    if let selection {
        SidebarDetailDispatcher(section: selection, …)   // ← no .id()
    }
}

SidebarDetailDispatcher (MainWindowView.swift:265) is a bare switch over SidebarSection. DocumentsRootView hosts DocumentsSidebarView inside a NavigationStack, and a .toolbar declared on a view inside the detail column is hoisted into the shared window toolbar, which is owned by the NavigationSplitView/window — not by the branch that declared it. Tearing down the declaring view does not reliably retract the hoisted item on macOS, so "New Folder" survives into the Lists chrome.

That predicts a specific signature: it only appears after you have visited Documents in the same session.

---

Step 0 — confirm the diagnosis and measure the trade-off

Two things to establish on a running build before writing code. Both take one session.

0a. Confirm the repro.

1. Launch, select Documents → window toolbar shows "New Folder".
2. Switch to Lists, open a GitHub-backed list.
3. Is "New Folder" still in the window toolbar?

If it only appears after visiting Documents → diagnosis confirmed, proceed. If it appears on a cold launch straight into Lists → different cause (most likely LaunchPrefetchCoordinator warming FolderTreeViewModel in a way that materialises the sidebar) and I re-scope.

0b. Measure what section-switching already costs. In my first comment I flagged that adding .id(selection) would discard per-section transient state. On closer reading that warning is overstated, and the correction matters for which fix we pick.

A switch inside a @ViewBuilder compiles to nested _ConditionalContent. When the branch changes, SwiftUI already tears down the outgoing branch's @State. Every section root holds its view model as @State — TimelineRootView.swift:33, SearchRootView.swift:30, DirectMessagesRootView.swift:28 — so that state is already discarded on every section switch today. The pre-warmed view models survive regardless, because LaunchPrefetchCoordinator is owned by MainWindowView and passed in.

So the concrete check: switch Timeline → Lists → Timeline and see whether scroll position and navigation depth are preserved today. I expect they are not. If confirmed, .id(selection) costs essentially nothing and both fixes land. If some state does survive today, .id() becomes a real regression and I ship the scoping fix alone.

---

The fix — two changes, both worth landing

Fix 1 (primary, structural) — stop Documents hoisting a window-toolbar item.

The root defect is that a pane-local action is declared as a window-level toolbar item. ListRowsView already solves this correctly for Lists with an inline action bar. Bring Documents in line: move the button out of .toolbar into an inline header row at the top of the sidebar's List.

// DocumentsSidebarView — replace the .toolbar { … } block
private var sidebarHeader: some View {
    HStack {
        Text("Folders").font(.ilMono(10)).foregroundStyle(.secondary)
        Spacer()
        Button { showNewRootFolder = true } label: {
            Label("New Folder", systemImage: "folder.badge.plus")
                .labelStyle(.iconOnly)
        }
        .buttonStyle(.borderless)
        .help("Create a new top-level folder")
        .accessibilityLabel("New Folder")
    }
    .padding(.horizontal, 8)
    .padding(.vertical, 4)
}

This fixes the leak at source with zero collateral, is consistent with how the rest of the app builds per-pane actions, and cannot regress any other section. The showNewRootFolder alert and createFolder(name:parentId:) call are untouched — the affordance moves, it does not disappear.

Fix 2 (hardening) — give the detail column stable identity.

SidebarDetailDispatcher(section: selection, …)
    .id(selection)

SidebarSection is already Hashable (MainWindowView.swift:20), so this compiles as-is. It forces a full teardown on section change and closes the whole class of bug — any future per-section toolbar, focus, or first-responder leak. Gated on the 0b result.

Both, in that order. Fix 1 removes today's bug; Fix 2 stops the next one. If 0b shows meaningful state survives section switches today, ship Fix 1 alone and open a separate issue for the identity question.

---

File-by-file task list

#	File	Change
1	App/Features/Documents/DocumentsSidebarView.swift	Delete the .toolbar { } block; add sidebarHeader as the first row of the List. Update the header comment to say why it is inline.
2	App/Navigation/MainWindowView.swift	Add .id(selection) to the SidebarDetailDispatcher call (gated on 0b). Note why in a comment so it is not "tidied away" later.
3	AppTests/SidebarDetailDispatcherTests.swift (new)	Structural guard — see below.
4	AppTests/FolderTreeViewModelTests.swift	No change expected; re-run to confirm folder creation is untouched.
5	docs/decisions/ (optional)	If Fix 2 lands, one short note that the detail column is identity-keyed by section, so it survives future refactors.

---

Tests

A hoisted-toolbar leak is not directly unit-testable in SwiftUI, so coverage is structural plus a scripted manual pass.

AppTests/SidebarDetailDispatcherTests.swift (new)

• test_givenEverySection_whenIdentified_thenIdsAreUnique — SidebarSection.allCases maps to distinct ids, so .id(selection) genuinely re-identifies. Guards a future case added with a duplicate rawValue.
• test_givenSectionEnum_whenHashed_thenConformsToHashable — compile-time guard that the .id(selection) call site keeps compiling.

AppTests/DocumentsSidebarTests.swift (new, small)

• Happy: the sidebar still exposes a reachable "New Folder" affordance — the fix must not silently delete the feature.
• Invalid: empty folder name → create is not attempted.
• Upstream failure: createFolder throws → error surfaces, sidebar stays usable.
• Boundary: whitespace-only name treated as empty.

(Quartet per CLAUDE.md. The first two are the ones that would actually catch a regression; the latter two are cheap and cover FolderTreeViewModel.createFolder at the same time.)

Manual regression script — add to the QA pass:

1. Documents → Lists → toolbar shows only Lists' items. ✅ the bug
2. Documents → New Folder still works (root and sub-folder). ✅ no feature loss
3. Walk all ten sidebar sections in sequence; no section shows another's toolbar items.
4. If Fix 2 landed: confirm no new state loss versus the 0b baseline.

---

Verification gate

xcodebuild -scheme InterlinedList -destination 'platform=macOS' build
xcodebuild -scheme InterlinedList -destination 'platform=macOS' \
  CODE_SIGNING_ALLOWED=NO test
grep -rn "import InterlinedKit" App/Features App/Navigation App/MenuCommands   # must be zero

Then the manual script above. CODE_SIGNING_ALLOWED=NO is required for the App test target on this machine.

---

Shape of the work

Single PR off dev, branch fix/lists-new-folder-toolbar-leak, in a worktree under .claude/worktrees/ per CLAUDE.md. Roughly: repro + 0b measurement, then a contained Documents-sidebar change and a one-line navigation change, then the regression sweep across all ten sections — which is where most of the time actually goes.

Risks

• 0b comes back the other way → Fix 2 is dropped; Fix 1 still resolves the reported bug. Low impact.
• Inline header looks wrong in the sidebar → it is a visual judgement call; if it reads poorly, the fallback is .toolbar(id:) with an explicit stable identity, which keeps the toolbar placement but makes the item removable.
• The leak survives Fix 1 → means the item is being retained by the window toolbar itself; Fix 2 then becomes the primary and the manual sweep tells us immediately.

Rollback — both changes are independently revertable; neither touches persistence, networking, or the Xcode project file.

---

One clarification

The issue reads "This should show up as there is not a 'folders' feature to the lists" — I have read that as a typo for should not show up: "New Folder" must disappear from the Lists chrome entirely while remaining available in Documents. Everything above assumes that. Say the word if you meant something else.