[jieyuexing]

Note

Drafted by Claude Opus 5.5 in Claude Code (via T3 Code); reviewed and posted by @jieyuexing.

Problem

In the boring sidebar, threads in a project folder are sorted only by my last message. Running, waiting, and finished threads are mixed together, so I have to read every row to find the threads that need me.

Change

Inside each folder, threads are now sorted by status. Threads that need you come first, then failed and finished threads, then waiting threads, and running threads come last. Threads with the same status keep their current order. The status check is the same one that the dot on a closed folder uses. This change adds no new button or setting, and it only changes the boring sidebar.

Scope and approval

There is no maintainer approval yet. The need is discussed in #30980 and #33380. #32565 also moves running threads down, but it needs Sections by project and adds a Working row. This PR is a smaller step that works without them.

Verification

• I added a unit test for the new order, and it fails when I swap waiting and working.
• vp run check:changed passes.
• I checked it in the dev app with the Replay provider: one folder has an approval thread, six done threads, and one working thread.
• I could not make a waiting thread with Replay, so that case is covered only by the unit test.

Before / after:

Before	After

Made with Claude Opus 5.5 and Claude Sonnet 5.5 in Claude Code (via T3 Code).

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — Folder-mode sidebars will automatically prioritize threads needing attention and put running threads last, preserving existing order within each status tier. A human must confirm this change to the product’s default folder ordering.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

Project-folder thread lists now order active threads by status. The sorter prioritizes threads needing attention, then failed threads, ready threads with unseen completions, other ready threads, waiting threads, and remaining statuses. The sidebar documentation describes the ordering and how to start a thread in a project.

Changes: Project folder thread ordering

Layer / File(s)	Summary
Status-based thread sorting apps/web/src/components/Sidebar.logic.ts, apps/web/src/components/Sidebar.logic.test.ts	A new sorter orders threads by status tier and preserves input order within each tier. Tests check the tier order, working-thread order, and empty input.
Project-folder ordering integration apps/web/src/components/Sidebar.tsx, docs/user/thread-sidebar.md	Project-folder mode applies the sorter after sorting working threads by send order. The documentation describes the ordering and how to start a thread in a project.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Feature

Possibly related issues

• Issue 31974 requests manual ordering in project folders. This PR changes folder thread ordering but does not add manual order-key sorting.
• Issue 24914 describes pending-question threads that can remain classified as running. This PR prioritizes threads by status but does not change status classification.

Suggested reviewers: t3dotgg, saphid

Merge Risk: Minimal · up to 7f4aa

Project-folder ordering is mergeable. On older servers, an unseen completed thread may appear after a seen one, but the thread remains visible and marked unseen.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly identifies the main change: sorting threads in boring sidebar folders so threads that need attention appear above running threads.
Description check		The description covers the problem, change, scope, and verification, including test results and screenshots. It also states that maintainer approval is not yet available; the required approval comment…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Description check

Explanation

The description covers the problem, change, scope, and verification, including test results and screenshots. It also states that maintainer approval is not yet available; the required approval comment or a rationale for an approval exemption is missing.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 0a9abdd
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: c875825f-7944-4136-b158-3121e0f961aa

Commits

Reviewing files that changed from the base of the PR and between 0a9abdd and 7f4aa9b.

Files selected for processing: 4

• apps/web/src/components/Sidebar.logic.test.ts
• apps/web/src/components/Sidebar.logic.ts
• apps/web/src/components/Sidebar.tsx
• docs/user/thread-sidebar.md

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

Verified head 7f4aa9b5ae810bc9df3107c26eff4df3e9fe25d4 on this Linux VM using the real dev web client, repository Playwright, /usr/bin/google-chrome, and Codex gpt-6.1-sol. Created the project and threads through the app against a real Git repository. No replay provider, mocks, fixtures, or seeded demo data.

Reproduced on github/main at 9cd7a04797184c92a8f636ae1e918f42c139d850: the newer running thread appeared above the approval and completed threads. Stopped main before starting the exact PR head and reused that isolated app-created database. Restarting ended the active requests, so I sent fresh real turns in the same named threads before capturing the PR result.

On the PR, the folder shows approval, completed, then running. The approval is a supervised shell write request; the running thread executes sleep 240. Approving the request runs the command, creates the file, and returns the thread to completed ordering. While both threads were running, their send order was preserved. Two read completions also retained send order. Marking the older completion unread moved it above the newer read completion; opening it restored their order.

Nearby checks passed: collapse/reopen retains the attention dot and selected thread, pin/unpin keeps pinned threads outside the folder and restores folder ordering, and turning the boring sidebar off and on restores the classic and folder layouts.

Runtime transcript:

main: serverPort=16733 webPort=8693
main folder: 03 running -> 02 needs approval -> 01 completed
PR: serverPort=13773 webPort=5733
PR folder: 02 needs approval -> 01 completed -> 03 running
UI: Approve shell request -> command completed successfully with exit code 0
$ cat /home/user/sidebar-verification/approval-check.txt
approval-check
$ blacksmith-check run --id <task-owned-box> "vp i && vp test run apps/web/src/components/Sidebar.logic.test.ts"
Test Files 1 passed; Tests 84 passed

All 33 reported PR checks were successful. No source changes were needed. Uploaded images were checked at their original 1440x1000 size; the 19-second recording was inspected and its uploaded playback and seeking exercised in Chrome.

Not verified

Native desktop, iOS and Android clients; macOS and Windows; remote relay/tunnel connections; other providers. Runtime failed, usage-limit, pending-question, and waiting tiers were not created in this pass. The focused existing unit suite covers the sorter tiers, including failed and waiting; that is not a claim of live provider coverage for those states.