What task are you trying to do?

I want the PawWork sidebar's first batch of sessions to represent the conversations I most recently used, based on the last time I sent a message in each session.

Today #470 fixes the timestamp for sessions that are already loaded into the sidebar window, but the first sidebar window is still selected by session creation time. That means an older session with a recent user message may not appear in the initial sidebar window at all.

Which area would this change affect?

App flow or product behavior

What do you do today?

Today the global session list can fetch the sidebar window by session.time.created, then the frontend can sort loaded rows by the latest loaded user message time when message cache is available.

This is better than showing creation time for loaded rows, but it is not a true global "recent user activity" list. A very old session that has recent user activity can still be hidden outside the first window until the user loads more sessions, searches, or opens that session another way.

What would a good result look like?

The first sidebar window should be selected and ordered primarily by the last valid user message time for each root session.

In plain terms: the conversations I most recently typed into should be the conversations I see first, even if those sessions were created a long time ago.

Fallback behavior should stay explicit:

• If a session has at least one valid user message, use the latest user message time.created.
• If a session has no user messages, no readable messages, or only invalid user message times, fall back to session.time.created.
• Assistant/background updates should not promote a session ahead of real user activity.

What would count as done?

• The initial PawWork sidebar session window is fetched/selected by last valid user message time, with session creation time as the fallback.
• The row timestamp displayed in the sidebar and the time-sort order use the same timestamp source.
• A session created long ago but with a recent user message appears ahead of a newer session whose last user message is older.
• Assistant-only updates or background session.time.updated changes do not promote old sessions.
• Pagination/windowing remains stable and deterministic when multiple sessions share the same computed activity time.
• Tests cover backend/API ordering, frontend row ordering, missing-message fallback, assistant-only fallback, and equal-time tie behavior.

What should stay out of scope?

• Do not use session.time.updated as a proxy for user activity.
• Do not change unrelated sidebar UI layout, copy, pinning behavior, session search, or project grouping.
• Do not bundle [Bug] Sidebar session timestamp shows creation time instead of last user message time #470's loaded-row timestamp fix into this issue; [Bug] Sidebar session timestamp shows creation time instead of last user message time #470 is about rows already in the sidebar window.
• Do not solve old session search/history UX beyond the initial window ordering contract.

Which audience does this matter to most?

Both

Extra context

Related:

• [Bug] Sidebar session timestamp shows creation time instead of last user message time #470 fixes loaded sidebar rows so their displayed time and row-level sorting use latest loaded user message time.
• PR fix(app): use last user message time in sidebar #471 intentionally does not change the global session window selection/pagination contract.

Likely implementation boundary:

• Add an explicit session list contract such as lastUserMessageAt / activity timestamp for root sessions, or an equivalent query mode that can order by latest user message with creation-time fallback.
• Keep pagination cursor semantics deterministic, probably with (activityAt, sessionID) or equivalent tie-breaking.
• Frontend should consume that timestamp for the initial sidebar window instead of relying on message cache after the fact.