feat(sidebar): pin tasks waiting for input to the top, make task names readable

[oluies]

What

Two changes to the left sidebar task list.

1. A "Waiting for you" tray, pinned under + New Task

When several tasks run in parallel, the one that just stopped to ask you something is wherever it happens to sit in the list — easy to miss, and easy to lose again once the list scrolls. This adds a tray between the + New Task button and the scrollable list holding every task blocked on an answer, newest question first. It sits outside the scroll container, so it never scrolls away.

Each row shows the status dot, the task name, the project it belongs to (the row is out of its project group, so it needs the label), and how long it has been waiting. Clicking a row opens the task and restores its last focused panel, so the question can be answered in one click.

Tasks stay in their project group as well — the tray is a shortcut, not a move. That keeps the data-task-index ↔ taskOrder mapping drag-reorder depends on intact, and keeps list positions stable.

It's a mode: sidebarNeedsInputFirst, persisted, on by default, with an × in the tray header and a Settings → Behavior checkbox to turn it back on.

Pinning on — two tasks asked, most recent on top	Pinning off — plain grouped list

Ordering by recency needed a question-onset timestamp, which nothing recorded. taskStatus now stamps one per agent when a question appears, clears it when the question goes away, and exposes getTaskQuestionSince(taskId).

2. Task names you can actually read

Long names were clipped mid-word. Three separate causes, all fixed:

• The name span sat in a flex row with no min-width: 0, so text-overflow: ellipsis never applied and the text was simply cut by the row's overflow: hidden. Names now wrap to at most two lines with the full name as a tooltip.
• Rows are flex children of the scrolling task column, so they were shrunk below their content height — the second line got clipped. Rows now set flex-shrink: 0.
• The task-item appear animation tweens max-height to a fixed 40px, shorter than any two-line row, and the class stays on the element. The keyframe now animates only opacity and transform.

Both screenshots above show the result — every name renders on two full lines with a proper ellipsis.

Alongside that: the direct branch badge moved after the name so the name claims width first (and the badge is capped and ellipsised), project group headers ellipsise while keeping their (n) count visible, and row spacing went 1px → 3px.

Testing

npm run typecheck, npm run lint, npm run format:check clean; full suite 1683 passed / 24 skipped.

New src/store/sidebar-attention.test.ts covers the ordering: newest question first, collapsed tasks included, unknown timestamps sink to the bottom, missing task ids skipped, no task listed twice.

Verified in the running app, not just in tests: launched Electron against a scratch profile seeded with two projects and four tasks, driven by stub agents that print a question and wait, so the real PTY question detector fires. The tray appeared with one entry, then two, with the later question sorted above the earlier one; the × persisted the mode to state.json. The two clipping bugs above were found because of that run — they were invisible to typecheck, lint, and unit tests.

[johannesjo]

Thanks — I carefully re-reviewed the complete current head (71a466f), including the surrounding task-status, multi-agent tab, shell-focus, persistence, and sidebar-ordering paths. The full suite (1,683 tests), typecheck, lint, formatting, and git diff --check all pass.

I found two cases that I think should be fixed before merge:

1. A task with an open question can be omitted from the tray when another status has higher priority. computeNeedsInputTasks() requires getTaskAttentionState(taskId) === 'needs_input', but that function returns error or review before checking question state. In a multi-agent task, one agent can exit non-zero while another running agent is asking; the task remains blocked on human input but disappears from “Waiting for you.” The same conflict can occur with needsReview. Tray membership should come directly from open-question state rather than the single prioritized display status, with a mixed error/question regression test.

2. Clicking a tray row does not necessarily open the terminal that asked the question. jumpToWaitingTask() restores the previously focused panel. If a non-selected AI agent asks while terminals are in tabs mode, its pane remains hidden; if a shell asks, the click can focus an AI terminal, Notes, or Prompt instead. That means another click is still required to answer. Please carry the newest asking agent/panel through the tray entry and focus its exact ai-terminal:<id> or shell:<index> target, with coverage for a non-selected tab or shell question.

A small helper returning the newest open question's { agentId, since } (or resolved panel target) could address both cases without adding another broad abstraction. Other than these two issues, I did not find additional correctness problems in the current diff.

[oluies]

desktopNotifications.ts:97 and remoteStatusSync.ts:38 still classify needs_input from getTaskAttentionState, so they carry the same masking. In the scenario you described, the "Task Needs Input" desktop notification never fires and the mobile overview shows only the error. getTaskOpenQuestion is what both would use. I didn't change it