feat: redesign navigation with unified collapsible sidebar

[ErikBjare]

• Replace tab-based navigation with unified sidebar (similar to ChatGPT/Grok)
• Add collapsible sidebar with icons-only view and bottom toggle button
• Move Chat/Tasks navigation from top menu bar to left sidebar
• Create MainLayout component that handles both chat and tasks views
• Create UnifiedSidebar component with improved spacing and layout
• Remove extra padding and improve content area utilization
• Remove superseded LeftSidebar, Conversations, and TaskManager components
• Add leftSidebarCollapsed$ state management to sidebar store

This provides a cleaner, more intuitive navigation experience with better mobile responsiveness and follows modern UI patterns.

---

Important

Redesign navigation with a unified collapsible sidebar, replacing tab-based navigation and enhancing UI/UX.

• Navigation Redesign:
  • Replace tab-based navigation with a unified collapsible sidebar (MainLayout, UnifiedSidebar).
  • Move Chat/Tasks navigation from top menu bar to left sidebar.
  • Add collapsible sidebar with icons-only view and bottom toggle button (SidebarIcons).
• Component Changes:
  • Create MainLayout to handle both chat and tasks views.
  • Remove LeftSidebar, Conversations, and TaskManager components.
  • Update MenuBar to remove tab navigation.
• State Management:
  • Add leftSidebarCollapsed$ to sidebar store for managing sidebar state.
• UI Enhancements:
  • Improve content area utilization by removing extra padding.
  • Update ChatInput and ConversationContent for new layout.
• Testing:
  • Update conversation.spec.ts to reflect new sidebar behavior.

^{This description was created by for 8737673. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to a498019 in 2 minutes and 34 seconds. Click for details.

• Reviewed 2431 lines of code in 10 files
• Skipped 0 files when reviewing.
• Skipped posting 6 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. src/components/ConversationList.tsx:258

• Draft comment:
  Reduced padding ('p-2') improves content utilization; please verify that the touch/click targets remain sufficiently accessible.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to verify the accessibility of touch/click targets after a change in padding. This falls under asking the author to ensure behavior is intended or to double-check something, which is against the rules.

2. src/components/MainLayout.tsx:59

• Draft comment:
  The mobile detection useEffect attaches a resize event listener. Consider debouncing the handler to reduce frequent state updates during rapid resize events.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While debouncing could help reduce state updates, this is a very simple boolean state update that only affects whether the mobile or desktop layout is shown. The performance impact is likely minimal since: 1. The state update is just a single boolean 2. The resize event naturally has some browser-level throttling 3. The mobile/desktop switch doesn't need to be perfectly responsive I could be underestimating the performance impact of frequent state updates in React. There could be expensive re-renders triggered by this state change. Even with potential re-renders, this is a fundamental layout switch that happens rarely in practice (only when actually resizing the window). The complexity cost of adding debouncing likely outweighs the minimal performance benefit. While technically correct, this optimization suggestion is likely overkill for this simple use case and would add unnecessary complexity.

3. src/components/UnifiedSidebar.tsx:150

• Draft comment:
  Using useMemo to sort tasks is efficient; ensure that if the tasks array grows large, performance remains acceptable.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is purely informative and suggests ensuring performance remains acceptable, which violates the rules. It doesn't provide a specific code suggestion or ask for a specific test to be written.

4. src/components/UnifiedSidebar.tsx:422

• Draft comment:
  Inline styling for maxHeight (e.g. in the WorkspaceList section) works but consider externalizing it to a CSS class for better maintainability.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The inline styles here serve a dynamic purpose - they toggle between 0 and 200px based on component state. Moving this to CSS classes would require either: 1. Dynamic class names (which isn't necessarily cleaner) 2. CSS transitions (which might not give the same precise control) The current approach is clear and localized to where it's used. The suggestion feels like premature optimization. The comment has a point about maintainability - if we needed to change these heights later, we'd have to change them in multiple places. CSS classes could provide a single source of truth. However, the current inline approach provides clear, local control that's easy to understand and modify. The maxHeight values are simple and tied directly to their collapse state. Moving to CSS classes would add complexity without clear benefits. The inline styles here are justified and clear. Moving them to CSS classes would add complexity without significant maintainability benefits.

5. src/stores/sidebar.ts:28

• Draft comment:
  The toggleLeftSidebar function properly distinguishes desktop (using panel ref) from mobile (toggling state directly). Ensure that leftPanelRef is managed consistently across component lifecycles.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to ensure that leftPanelRef is managed consistently across component lifecycles. This falls under the category of asking the author to ensure something, which is against the rules. The comment does not provide a specific suggestion or point out a specific issue with the code.

6. src/components/MenuBar.tsx:20

• Draft comment:
  The MenuBar component is clear and utilizes tooltip components effectively. No issues noted.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

Workflow ID: wflow_ziZmOB5OKW7bIqOk

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

The recursive setTimeout in the step parameter check (lines 102–129) may run indefinitely if the conversation never connects. Consider adding a maximum attempt count or timeout to prevent an infinite loop.

[ellipsis-dev]

In the handleCreateTask callback, consider using the mutation’s result (e.g. the new task’s ID) for navigation rather than relying solely on selectedTaskId from the store.

[ErikBjare]

Issues:

• "show history" on main page doesn't work anymore
• collapsibleSize=5 for the UnifiedSidebar is 5% of screen size (we want a fixed width to fit the collapsed icons)
• breaks mobile (no way to open sidebar)
• probably more stuff

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 9341315 in 1 minute and 58 seconds. Click for details.

• Reviewed 22 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. src/components/MainLayout.tsx:101

• Draft comment:
  Consider using a reactive hook (e.g. use$(conversation$)) instead of calling conversation$.get() directly. This ensures that updates to the conversation trigger a re-render.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The code already has useObserveEffect() watching conversation$ for changes, and conversation$ gets updated via conversation$.set() in multiple places. The .get() call is used in a render function where the component will re-render anyway when conversation$ changes. The current approach seems intentional and working as designed. I could be wrong about the reactivity model - maybe use$() provides additional benefits beyond just getting the current value. The comment author may have deeper knowledge of the Legend state management library. While use$() might be a valid alternative pattern, there's no clear evidence that the current .get() approach is causing any issues, especially given the existing useObserveEffect() handlers. The comment suggests a change but doesn't demonstrate a concrete problem with the current approach. Without clear evidence of an issue, we should respect the existing implementation.

2. src/components/MainLayout.tsx:364

• Draft comment:
  The open condition now requires rightVisible, rightActiveTab and currentConversation to be truthy. Verify that gating the Sheet open state on both selection and conversation availability is intentional, since delayed conversation data might prevent the sidebar from opening.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

Workflow ID: wflow_bYjW5OWwjaFlrj13

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed d409d0b in 3 minutes and 51 seconds. Click for details.

• Reviewed 542 lines of code in 4 files
• Skipped 0 files when reviewing.
• Skipped posting 4 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. src/components/ConversationList.tsx:64

• Draft comment:
  The added scroll-check logic (lines 66–73) is a clear improvement to avoid unnecessary fetches. Ensure the 100px bottom threshold works well across devices, and note that excluding isFetching from dependencies is intentional.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 20% <= threshold 50% The comment starts by acknowledging an improvement, which is informative. It then suggests ensuring that the 100px threshold works well across devices, which is a request for confirmation and not specific enough. The note about excluding isFetching from dependencies being intentional is informative. Overall, the comment does not provide specific actionable feedback or suggestions.

2. src/components/MainLayout.tsx:418

• Draft comment:
  Updating container classes to use 'min-h-0' and 'flex-1' and setting collapsedSize to 0 improves layout consistency and responsiveness. Verify these layout changes visually on both mobile and desktop breakpoints.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to verify layout changes visually, which falls under the rule of not asking the author to double-check things. It does not provide a specific code suggestion or point out a potential issue that needs addressing.

3. src/components/SidebarIcons.tsx:22

• Draft comment:
  Consider memoizing the 'handleNavigateToSection' callback (e.g. with useCallback) to avoid unnecessary re-renders, especially if the component scales or re-renders frequently.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This seems like premature optimization. The function is very simple, just doing basic routing. The component itself is not complex and likely won't re-render frequently. The only prop is tasks array which affects the badge count. Adding useCallback would actually add complexity without clear benefits. React docs suggest not to memoize everything by default. The comment could be right if this component ends up being used in a performance-critical part of the app or if the tasks prop changes very frequently causing many re-renders. Even with frequent re-renders, the performance impact of recreating this simple function would be negligible compared to the actual DOM updates from re-rendering the component. Premature optimization should be avoided. Delete this comment as it suggests premature optimization that would add unnecessary complexity without clear performance benefits.

4. src/components/UnifiedSidebar.tsx:232

• Draft comment:
  The collapsible sections for Agents and Workspaces toggle state by inverting the incoming open flag (e.g. setAgentsCollapsed(!open)). For clarity, consider storing the expanded state directly (or renaming variables) to avoid double negation confusion.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_Y6KUvMuir2TrpVWj

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed a355ee3 in 2 minutes and 11 seconds. Click for details.

• Reviewed 160 lines of code in 4 files
• Skipped 0 files when reviewing.
• Skipped posting 4 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. e2e/conversation.spec.ts:9

• Draft comment:
  Using waitForLoadState('networkidle') ensures the page is fully loaded before assertions. Make sure the chosen timeout values (e.g., { timeout: 10000 }) work reliably across environments.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

2. src/components/MainLayout.tsx:225

• Draft comment:
  The conditional update of conversation$ is clear and handles the not-found case well. Consider using a debug logging mechanism instead of console.log to avoid verbose production logs.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

3. src/components/SidebarIcons.tsx:87

• Draft comment:
  Nice use of the data-testid attribute for the toggle button; this improves test reliability for the new unified sidebar layout.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

4. src/components/UnifiedSidebar.tsx:157

• Draft comment:
  The removal of the border class (border-b) from the section headers changes the visual separation of the sections. Confirm that this design change is intentional and consistent with overall UI guidelines.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

Workflow ID: wflow_xgnagQpaEN1Wpvzx

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 1fbd1af in 2 minutes and 56 seconds. Click for details.

• Reviewed 465 lines of code in 8 files
• Skipped 0 files when reviewing.
• Skipped posting 12 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. src/components/ChatInput.tsx:369

• Draft comment:
  The container div lost its centering and max-width classes. Confirm that removing 'mx-auto' and 'max-w-2xl' is intentional and does not adversely affect layout on larger screens.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% The rules explicitly state "Do NOT comment on any pure frontend UI or styling changes, only logic. Assume that if the author changed the UI, they did it correctly." This is a pure UI styling change affecting layout and width. The author likely had a good reason for making this change to the styling. Maybe this change could affect the usability of the chat input in a way that impacts functionality, not just aesthetics? No, this is still fundamentally a UI styling decision about layout and width. The rules are clear that we should trust the author on UI changes. This comment should be removed as it violates the rule about not commenting on pure UI/styling changes.

2. src/components/ConversationContent.tsx:245

• Draft comment:
  The chat input wrapper now includes 'mx-auto max-w-2xl' to center it. Verify that this addition aligns with responsive design goals and remains consistent across devices.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to verify that the change aligns with responsive design goals and remains consistent across devices. This falls under asking the author to ensure the behavior is intended, which is against the rules.

3. src/components/ExamplesSection.tsx:57

• Draft comment:
  The quick examples grid and its heading have been removed in favor of a simplified 'Examples' button. Ensure that removing the immediate suggestions does not negatively impact the user experience.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to ensure that the removal of a feature does not negatively impact user experience. This falls under the category of asking the author to double-check or ensure something, which is against the rules. The comment does not provide a specific suggestion or point out a specific issue with the code.

4. src/components/MainLayout.tsx:261

• Draft comment:
  Explicitly clearing conversation state when no conversationId or taskId is provided improves consistency. Verify that this reset logic does not conflict with any lazy-loading or state persistence you might expect.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to verify that the reset logic does not conflict with lazy-loading or state persistence. This falls under asking the author to ensure behavior is intended, which is against the rules.

5. src/components/MainLayout.tsx:292

• Draft comment:
  Fallback logic creates a minimal 'Loading...' conversation when none is found. Ensure this approach covers all edge cases so that users aren’t presented with confusing or incomplete information.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to ensure that the fallback logic covers all edge cases, which is a form of asking them to double-check their work. This violates the rule against asking the author to ensure behavior is intended or tested.

6. src/components/MainLayout.tsx:207

• Draft comment:
  The reactive combination of demo, API, and store conversations into a deduplicated map is innovative. Monitor for any performance issues if the conversation list grows large.
• Reason this comment was not posted:
  Confidence changes required: 40% <= threshold 50% None

7. src/components/SidebarIcons.tsx:33

• Draft comment:
  The sidebar container’s width and padding have been reduced (from w-12/p-2 to w-11/p-1). Confirm that these new dimensions align with the unified sidebar design and maintain accessibility.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to confirm alignment with a design and accessibility, which is not specific enough. It doesn't provide a specific suggestion or point out a clear issue with the code. It violates the rule against asking for confirmation of intention or ensuring behavior.

8. src/components/WelcomeView.tsx:55

• Draft comment:
  The layout in WelcomeView has been restructured, with the ChatInput and ExamplesSection rearranged. Verify that the new placement works across a range of screen sizes and maintains good accessibility.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

9. src/hooks/useConversation.ts:68

• Draft comment:
  The optimization to skip reloading conversation data when existing messages are present is efficient. Ensure that proper null-checks are in place for 'existingConversation.data.log' to avoid runtime errors.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The current code already has a null check with existingConversation && which protects against null/undefined. The suggestion to use optional chaining would be equivalent but just a different style. The current code is not wrong or unsafe. This seems like a stylistic preference rather than a necessary change. The comment does point out a valid alternative syntax that could make the code more concise. Maybe there are edge cases where data or log could be undefined that I'm not considering? The existing && check provides sufficient null safety. The suggested change is purely stylistic and doesn't add meaningful value or fix any actual issues. This comment should be deleted as it suggests an unnecessary stylistic change to code that is already safe and working correctly.

10. src/hooks/useConversation.ts:160

• Draft comment:
  A fixed 100ms delay is used after message completion for tool event coordination. Consider whether this delay is sufficient for all scenarios or if making it configurable might improve reliability.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

11. src/utils/api.ts:586

• Draft comment:
  In 'createConversationWithPlaceholder', the auto-sync logic using then/catch is functional but could be clearer with async/await. This may also improve error handling readability.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

12. src/utils/api.ts:293

• Draft comment:
  The auth token is appended as a URL query parameter for SSE connections. While necessary due to EventSource limitations, ensure that logging and browser history do not expose sensitive token information.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_NDP3KcQIDkLXU09X

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 8737673 in 1 minute and 22 seconds. Click for details.

• Reviewed 33 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. src/components/ConversationContent.tsx:245

• Draft comment:
  Nesting the centering classes in an inner
  improves layout control. Ensure the gradient background still spans the intended full width and that the centered ChatInput behaves as expected, especially on mobile.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

2. src/components/ConversationContent.tsx:246

• Draft comment:
  Typo: There's an extra leading space in the className attribute on this line (" mx-auto max-w-2xl"). Consider removing the extra space to keep consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the extra space, this is an extremely minor styling issue. The extra space in className won't affect the actual rendered CSS classes or functionality. It's more of a code style nitpick than a meaningful issue. Our rules say not to make comments that are obvious or unimportant. The space could be part of a consistent code style guide that I'm not aware of. Also, inconsistent spacing could make the code harder to maintain over time. Even if there is a style guide, this is too minor of an issue to warrant a PR comment. The impact on maintainability is negligible since the extra space doesn't affect functionality. Delete this comment as it points out an extremely minor formatting issue that doesn't impact functionality or readability in any meaningful way.

Workflow ID: wflow_7rSjTcpXMcVYtugg

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}