[maria-rcks]

Pending questions now have a fixed Needs input count that opens each waiting thread in turn, while thread order stays unchanged and a static border marks pending rows. Submitted answers appear beside the activity label, expand into the original question details, and composer questions render Markdown links.

Verified next-question navigation in the real app with 80 demo threads and 8 pending questions, no border animation, web typecheck, targeted lint, and the existing 318-test pass from the initial implementation.

Original sidebar (sampled capture):

Previous animated proposal:

Final static navigation, same demo threads:

Implemented with gpt-5.6-sol in the Codex harness.

---

Note

Low Risk
Mostly sidebar and timeline presentation; work-log derivation changes how resolved user-input rows read in the activity feed but does not touch auth or persistence.

Overview
Adds a fixed Needs input · N control at the top of the sidebar (via SidebarQuestionIndicators) that cycles through non-archived threads with hasPendingUserInput, calling navigateToThread without reordering the list. Pending rows are highlighted with data-pending-question, the sidebar-question-pending indigo border overlay, and the same styling in both Sidebar and LegacySidebar.

Resolved user-input activities in deriveWorkLogEntries now populate optional userInputSummary and richer detail (questions, options, answers); the message timeline shows the summary next to the work-log label and includes it in accessible text. Pending composer questions render through ChatMarkdown instead of plain text.

^{Reviewed by Cursor Bugbot for commit cbbcb3e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add pending-question sidebar indicators and user-input summaries to timeline

• Adds SidebarQuestionIndicators component that lists non-archived threads with pending user input, shows a count, and cycles to the next pending thread when activated
• SidebarContent renders the indicator above its scroll area when a navigation callback is supplied; both Sidebar and LegacySidebar wire up the callback
• Sidebar thread rows in both sidebars receive a pending-question class and data attribute; a CSS overlay adds an indigo border to marked rows
• ComposerPendingUserInputCard now renders the active question as ChatMarkdown instead of plain text
• deriveWorkLogEntries in session-logic.ts parses submitted answers for resolved user-input activities and attaches a compact userInputSummary plus structured detail to the work-log entry; PlainWorkEntryRow displays the summary as truncated secondary text
• Risk: WorkLogEntry.userInputSummary is a new optional field — existing consumers of WorkLogEntry that do not handle the field will simply ignore it, but timeline rendering changes for entries that now carry summaries

^{Macroscope summarized cbbcb3e.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This adds an always-on pending-question discovery and navigation workflow across both sidebar implementations, while also changing production chat and timeline rendering. The cross-cutting user-facing behavior is beyond an isolated UI tweak and merits human review.

Notes:

• Diff unchanged. Approvability was decided on eligibility alone.

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

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit cbbcb3e. Configure here.}

[flamboh]

Astra asking so many questions makes this such a good addition!

[juliusmarminge]

Thanks for working on this. We merged the orchestrator V2 rewrite in #2829, and we are closing this PR as part of that transition.

The patch conflicts with the rewrite in apps/web/src/components/chat/MessagesTimeline.logic.ts. Even where the conflict is small enough to rebase, we are asking for fresh PRs against the new base so we can review and verify the behavior in V2.

Sorry for the extra work this creates. If the change is still needed on V2, please rebuild it on current main, verify it there, and open a new PR linking back here. We're closing the current implementation without assuming the underlying request is resolved.