feat(web): drag sidebar threads between categories - #8001

💭 I'm checking the current PR diff at head 8e613a3 to see which previously flagged UI issues have been resolved versus still outstanding, so I don't repost fixed items. The cursor styling issue looks resolved now that the thread row uses a grab cursor class. The aria-expanded handling now separates the actual expanded prop from a presentational value, which looks fixed too. The snoozed rail issue still seems unresolved though — the shelf header still displays even when there's an empty snoozed count, so that finding should stay in the report. The regular rail fallback divider now correctly gets a droppable ref, so that's fixed, and the aria-hidden boundary logic looks corrected as well. I still need to check whether the tooltip on the un-settle button was restored at this head, so I'm going to pull up the Sidebar.tsx code around the slim row and un-settle button to verify.

1. git_tools — Tooltip — rejected: repo.url: required parameter is missing or empty;repo: required parameter is missing or empty

2. git_tools — d7ea7c2..8e613a3

💭 The repo URL might actually be pingdotgg/t3code, so I should try searching with that repo parameter instead.

3. git_tools — Tooltip

💭 I'm checking the row region around lines 1279-1500 to see the unsettle button's tooltip state at the head.

4. browse_code — apps/web/src/components/Sidebar.tsx

💭 The tooltip issue looks resolved now that the "Un-settle thread" tooltip is present, though the "Wake thread now" button still lacks one—I need to check whether that's pre-existing or introduced by this change. I should compare the merge base against head to confirm what's actually new versus what was already there before this PR. Going through the previously flagged items—the empty Snoozed section header, boundary aria attributes, missing tests, droppable behavior, cursor styling—they all appear fixed now, so no need to reflag those. I'm now scanning for new UI consistency issues, like whether the shelf header components properly reflect drop-target hover states, since it seems the isOver highlighting isn't wired into the shelf header component itself. I'm checking the scroll-area and sidebar viewport ref forwarding, the inert attribute handling on drag shell list items, and the contain-intrinsic-size values for card versus slim variants, making sure the numbers line up with the actual rendered row heights including padding. It also blocks propagation for touch pointers, preventing drag on touch while keeping the pan-y behavior. I'm checking the selection-safe data attribute wiring in the shelf header and confirming the DnD listeners attach correctly to the list item. Now looking at the shelf header button styling, which gained rounded corners and a transition-colors class. Since there's no background color change anywhere, that transition is inert—minor, probably not worth flagging. I'm also noticing the drag overlay hardcodes row heights (82/36) as TS constants while the actual CSS defines heights separately via classes, which is a duplication of geometry that could cause inconsistency if one changes without the other—checking if there's an existing CSS variable for row height that should be reused instead.

5. git_tools — sidebar-row|4.875rem|h-[2.25rem]|--sidebar-content-inset

💭 I'm tracing the row height math—78px card height plus 2px padding on each side gives 82px—and noticing the same 82/36 constants appear duplicated in both the TS and CSS layers. That's a real drift risk if the CSS variable changes independently, though switching to a measurement-based approach would be a much bigger refactor than it's worth flagging here. Now I want to check that neither --sidebar-content-inset nor --sidebar-row-content-inset actually affects the outer fixed height, just inner padding, so 82 should hold unless the h-[4.875rem] class itself changes. Let me look at the slim row region around lines 1210-1245 to confirm its height calculation matches.

6. browse_code — apps/web/src/components/Sidebar.tsx

💭 Checking the row height confirms 36px matches expectations. I'm looking at the drag overlay styling that uses important-flagged classes to override the shared row surface during drag state — the opacity override on isInFlight seems like a deliberate but slightly forceful pattern, though arguably acceptable rather than a real issue. Now I'm tracing a possible bug: when rendering the drag overlay, the card variant drops its py-0.5 padding class along with the content-visibility sizing hints, which could throw off the expected 82px total height calculation for the card view during drag. This would produce a small 2px jump at the end of the drop animation since the row surface is inset while the overlay isn't — low confidence and minor, so I'd rather look for stronger findings. Let me instead check whether the "Wake thread now" button lacking a tooltip (unlike its siblings Un-settle, Unpin, Dismiss Woke) is pre-existing by comparing against the merge base.

7. git_tools — Wake thread now

💭 This is pre-existing, not a new finding. I want to double-check the head version of SidebarThreadBoard to confirm the snoozed rail issue still holds and see if anything new shows up.

8. browse_code — apps/web/src/components/sidebar/SidebarThreadBoard.tsx

💭 I'm confirming the shelf header button's missing focus styling is unchanged from the original, and noting the new rounded corners and transition-colors class are purely cosmetic additions. I also check that swapping the wrapping <li> for a <div data-thread-selection-safe> while keeping the <li> as the outer boundary doesn't break anything. The removal of per-variant keying (using just threadKey instead of combining it with rowVariant) is an intentional change letting variant transitions morph in place rather than crossing via FLIP, matching the docs, as is the dropped autoAnimate list animation. I also verify the drag-view variant fallback logic and confirm renderBoardThread still passes wokeAt correctly while now being a plain unmemoized function, before turning to check how draft blocks are rendered inside the role="list" container. Confirming SidebarDraftBlock renders as <li> elements directly within the ul, and that DragOverlay's ul wrapper properly contains the dragged li — this all looks consistent. Now I want to check the new viewportRef prop added to ScrollArea, making sure it's correctly forwarded to the Viewport ref without conflicting with any existing ref handling in that file.

9. browse_code — apps/web/src/components/ui/scroll-area.tsx

💭 No CSS files were touched in this diff, so that part of the check doesn't apply. I want to trace where the added overflow-anchor class on SidebarContent actually gets applied, so I'm looking at the SidebarContent component definition in ui/sidebar.tsx to see how it forwards className.

10. browse_code — apps/web/src/components/ui/sidebar.tsx

💭 The overflow-anchor: none applied to the inner content wrapper excludes it and its descendants from scroll anchoring, effectively disabling the behavior for everything inside since that div is the sole child of the viewport. Now I'm checking whether removing SidebarThreadDndShell breaks something that queries [data-thread-item] elsewhere, like keyboard navigation or drag selection logic. Data-thread-selection-safe is still fine since the shelf header isn't nested inside a thread row anymore, so the pointer-down capture check via closest() won't matter here. I want to see what changed between the last reviewed commit and head, so I should pull the PR's commit list to diff more carefully.

11. github_api_read_only — repos/{owner}/{repo}/pulls/{pull_number}/commits?per_page=100

💭 Looking at the commit history since the last review, I see only two substantive fixes addressing my earlier comments—both appear correct—with no other new web UI code. There's still an unfixed prior finding around the empty Sno case I need to look at further. Rechecking the sidebar boundary fix more carefully: the aria-hidden logic correctly resolves to undefined (attribute absent) when neither content is null nor the section is regular, so pinned rails and snoozed/settled headers get properly announced, and the empty regular-section divider stays hidden. The rails contain no focusable elements, so there's no accessibility conflict there either. I have no new findings this run, and the one outstanding unfixed issue (empty Snoozed rail) was already flagged previously, so reposting it would be duplicate. Given the guidance to bias toward success when there's nothing new to report, I'll report this as clear rather than fail again on an already-known issue.