feat(code): add Board view to inbox alongside the existing list

[fercgomes]

Summary

• Adds a List/Board toggle to the inbox toolbar so users can switch between the current flat list and a kanban-style board grouped by status.
• New ReportBoardPane renders horizontal lanes for ready, pending_input, in_progress, candidate, potential, and failed, reusing the existing ReportCardContent, click/cmd/shift selection, multi-select checkboxes, and motion fade-in animations from the list rows.
• Choice persists via inboxSignalsFilterStore.viewMode ("list" | "board") so it survives reloads. Infinite-scroll is preserved by anchoring the load-more sentinel to the tallest lane.

Why

The inbox has been getting noisy with many items at once. Switching to a status-grouped board makes it much easier to scan what's actually actionable (Ready, Needs input) vs. what is still being processed.

Notes

• Lane width is fixed at 280px and the board scrolls horizontally inside the existing left pane. Drag the pane's resize handle to see more lanes at once.
• Lane headers are intentionally non-sticky to avoid layering conflicts with the existing sticky toolbar above.
• Empty lanes show a small "No reports" hint so the board still feels populated when most reports are in one status.

Test plan

• Open the Inbox tab — default view is List (existing behavior).
• Click the kanban icon in the toolbar — Board view appears, lanes are grouped by status with counts.
• Click a card in any lane — detail pane opens; cmd-click and shift-click still extend selection across lanes.
• Toggle back to List — same selection persists, no flicker.
• Reload the app — selected view mode is restored.
• In Board view: scroll the longest lane to the bottom — load-more triggers further pages.
• In Board view: trigger an empty filter combination — see "No reports match current filters" empty state.
• In Board view: simulate an error (e.g. offline) — Retry button appears.

[greptile-apps]

Comments Outside Diff (1)

1. apps/code/src/renderer/features/inbox/components/board/InboxBoardView.tsx, line 611-612 (link)

   Column count only reflects locally-loaded data

   The badge shows reports.length, which is the count of items from pages already fetched for that column — not the server-side total. When there are more pages to load, a user in the "ready" lane could see "4" even though 40 items exist in that status. Because the load-more sentinel is anchored to the single tallest column, items in shorter columns never get their "true" count shown and users have no signal that more exist elsewhere. Consider appending a + suffix (e.g. 4+) when hasNextPage is true, or keeping the column count blank/hidden until all pages are loaded.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: apps/code/src/renderer/features/inbox/components/board/InboxBoardView.tsx
   Line: 611-612
   
   Comment:
   **Column count only reflects locally-loaded data**
   
   The badge shows `reports.length`, which is the count of items from pages already fetched for that column — not the server-side total. When there are more pages to load, a user in the "ready" lane could see "4" even though 40 items exist in that status. Because the load-more sentinel is anchored to the single tallest column, items in shorter columns never get their "true" count shown and users have no signal that more exist elsewhere. Consider appending a `+` suffix (e.g. `4+`) when `hasNextPage` is true, or keeping the column count blank/hidden until all pages are loaded.
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
apps/code/src/renderer/features/inbox/components/board/InboxBoardView.tsx:611-612
**Column count only reflects locally-loaded data**

The badge shows `reports.length`, which is the count of items from pages already fetched for that column — not the server-side total. When there are more pages to load, a user in the "ready" lane could see "4" even though 40 items exist in that status. Because the load-more sentinel is anchored to the single tallest column, items in shorter columns never get their "true" count shown and users have no signal that more exist elsewhere. Consider appending a `+` suffix (e.g. `4+`) when `hasNextPage` is true, or keeping the column count blank/hidden until all pages are loaded.

### Issue 2 of 2
apps/code/src/renderer/features/inbox/components/InboxSignalsTab.tsx:463-498
**Board detail pane resize duplicates the existing sidebar resize logic**

The board detail pane's `handleBoardDetailResizeMouseDown` + its `useEffect` for `mousemove`/`mouseup` are structurally identical to the existing sidebar resize that handles `handleResizeMouseDown`. Both set `body.style.cursor/userSelect` on drag start, compute width from the same pattern, and clean up on mouseup. This is an OnceAndOnlyOnce violation — consider extracting a shared `useResizeHandle(isResizing, setIsResizing, setWidth, containerRef, options)` hook that both handles can reuse.

```suggestion
  // TODO: extract a shared useResizeHandle hook to cover both this and the
  // sidebar resize below — both use identical mousemove/mouseup logic.
  const handleBoardDetailResizeMouseDown = useCallback(
    (e: React.MouseEvent) => {
      e.preventDefault();
      setBoardDetailIsResizing(true);
      document.body.style.cursor = "col-resize";
      document.body.style.userSelect = "none";
    },
    [setBoardDetailIsResizing],
  );

  useEffect(() => {
    const handleMouseMove = (e: MouseEvent) => {
      if (!boardDetailIsResizing || !boardContainerRef.current) return;
      const rect = boardContainerRef.current.getBoundingClientRect();
      const containerWidth = rect.width;
      const maxWidth = Math.max(420, containerWidth * 0.7);
      const newWidth = Math.max(
        420,
        Math.min(maxWidth, rect.right - e.clientX),
      );
      setBoardDetailWidth(newWidth);
    };
    const handleMouseUp = () => {
      if (boardDetailIsResizing) {
        setBoardDetailIsResizing(false);
        document.body.style.cursor = "";
        document.body.style.userSelect = "";
      }
    };
    document.addEventListener("mousemove", handleMouseMove);
    document.addEventListener("mouseup", handleMouseUp);
    return () => {
      document.removeEventListener("mousemove", handleMouseMove);
      document.removeEventListener("mouseup", handleMouseUp);
    };
  }, [boardDetailIsResizing, setBoardDetailWidth, setBoardDetailIsResizing]);
```

_{Reviews (1): Last reviewed commit: "feat(code): group inbox board by actiona..." | Re-trigger Greptile}

[greptile-apps]

Board detail pane resize duplicates the existing sidebar resize logic

The board detail pane's handleBoardDetailResizeMouseDown + its useEffect for mousemove/mouseup are structurally identical to the existing sidebar resize that handles handleResizeMouseDown. Both set body.style.cursor/userSelect on drag start, compute width from the same pattern, and clean up on mouseup. This is an OnceAndOnlyOnce violation — consider extracting a shared useResizeHandle(isResizing, setIsResizing, setWidth, containerRef, options) hook that both handles can reuse.

Suggested change

	const handleBoardDetailResizeMouseDown = useCallback(
	(e: React.MouseEvent) => {
	e.preventDefault();
	setBoardDetailIsResizing(true);
	document.body.style.cursor = "col-resize";
	document.body.style.userSelect = "none";
	},
	[setBoardDetailIsResizing],
	);
	useEffect(() => {
	const handleMouseMove = (e: MouseEvent) => {
	if (!boardDetailIsResizing || !boardContainerRef.current) return;
	const rect = boardContainerRef.current.getBoundingClientRect();
	const containerWidth = rect.width;
	const maxWidth = Math.max(420, containerWidth * 0.7);
	const newWidth = Math.max(
	420,
	Math.min(maxWidth, rect.right - e.clientX),
	);
	setBoardDetailWidth(newWidth);
	};
	const handleMouseUp = () => {
	if (boardDetailIsResizing) {
	setBoardDetailIsResizing(false);
	document.body.style.cursor = "";
	document.body.style.userSelect = "";
	}
	};
	document.addEventListener("mousemove", handleMouseMove);
	document.addEventListener("mouseup", handleMouseUp);
	return () => {
	document.removeEventListener("mousemove", handleMouseMove);
	document.removeEventListener("mouseup", handleMouseUp);
	};
	}, [boardDetailIsResizing, setBoardDetailWidth, setBoardDetailIsResizing]);
	// TODO: extract a shared useResizeHandle hook to cover both this and the
	// sidebar resize below — both use identical mousemove/mouseup logic.
	const handleBoardDetailResizeMouseDown = useCallback(
	(e: React.MouseEvent) => {
	e.preventDefault();
	setBoardDetailIsResizing(true);
	document.body.style.cursor = "col-resize";
	document.body.style.userSelect = "none";
	},
	[setBoardDetailIsResizing],
	);
	useEffect(() => {
	const handleMouseMove = (e: MouseEvent) => {
	if (!boardDetailIsResizing || !boardContainerRef.current) return;
	const rect = boardContainerRef.current.getBoundingClientRect();
	const containerWidth = rect.width;
	const maxWidth = Math.max(420, containerWidth * 0.7);
	const newWidth = Math.max(
	420,
	Math.min(maxWidth, rect.right - e.clientX),
	);
	setBoardDetailWidth(newWidth);
	};
	const handleMouseUp = () => {
	if (boardDetailIsResizing) {
	setBoardDetailIsResizing(false);
	document.body.style.cursor = "";
	document.body.style.userSelect = "";
	}
	};
	document.addEventListener("mousemove", handleMouseMove);
	document.addEventListener("mouseup", handleMouseUp);
	return () => {
	document.removeEventListener("mousemove", handleMouseMove);
	document.removeEventListener("mouseup", handleMouseUp);
	};
	}, [boardDetailIsResizing, setBoardDetailWidth, setBoardDetailIsResizing]);

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/features/inbox/components/InboxSignalsTab.tsx
Line: 463-498

Comment:
**Board detail pane resize duplicates the existing sidebar resize logic**

The board detail pane's `handleBoardDetailResizeMouseDown` + its `useEffect` for `mousemove`/`mouseup` are structurally identical to the existing sidebar resize that handles `handleResizeMouseDown`. Both set `body.style.cursor/userSelect` on drag start, compute width from the same pattern, and clean up on mouseup. This is an OnceAndOnlyOnce violation — consider extracting a shared `useResizeHandle(isResizing, setIsResizing, setWidth, containerRef, options)` hook that both handles can reuse.

```suggestion
  // TODO: extract a shared useResizeHandle hook to cover both this and the
  // sidebar resize below — both use identical mousemove/mouseup logic.
  const handleBoardDetailResizeMouseDown = useCallback(
    (e: React.MouseEvent) => {
      e.preventDefault();
      setBoardDetailIsResizing(true);
      document.body.style.cursor = "col-resize";
      document.body.style.userSelect = "none";
    },
    [setBoardDetailIsResizing],
  );

  useEffect(() => {
    const handleMouseMove = (e: MouseEvent) => {
      if (!boardDetailIsResizing || !boardContainerRef.current) return;
      const rect = boardContainerRef.current.getBoundingClientRect();
      const containerWidth = rect.width;
      const maxWidth = Math.max(420, containerWidth * 0.7);
      const newWidth = Math.max(
        420,
        Math.min(maxWidth, rect.right - e.clientX),
      );
      setBoardDetailWidth(newWidth);
    };
    const handleMouseUp = () => {
      if (boardDetailIsResizing) {
        setBoardDetailIsResizing(false);
        document.body.style.cursor = "";
        document.body.style.userSelect = "";
      }
    };
    document.addEventListener("mousemove", handleMouseMove);
    document.addEventListener("mouseup", handleMouseUp);
    return () => {
      document.removeEventListener("mousemove", handleMouseMove);
      document.removeEventListener("mouseup", handleMouseUp);
    };
  }, [boardDetailIsResizing, setBoardDetailWidth, setBoardDetailIsResizing]);
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!