feat(ui): discuss priority-based conversation ordering and activity filtering

## Problem

Maka's conversation sidebar becomes harder to scan as the number of local, cloud, linked-child, and long-running sessions grows.

Today the ordinary history list has one fixed ordering policy:

- pinned conversations are separated and shown first;
- conversations inside each section are ordered by `lastMessageAt`;
- status, streaming state, and unread state are presented on each row, but they do not provide a user-selectable ordering mode.

This is predictable, but recent low-attention activity can push a conversation that is waiting for the user, still running, or newly completed with an unread result out of view. The user must scan multiple groups to find the next conversation that needs action.

Codex recently introduced two related sidebar concepts:

1. **Priority sorting** keeps the full list but promotes conversations that need input or have unread activity.
2. **Activity / priority filtering** shows only unread, active, or awaiting-response conversations.

Reference screenshot (Chinese locale):


The screenshot is a product reference, not a request to copy its exact layout or terminology.

## Desired outcome

Discuss whether Maka should add a user-selectable conversation ordering model, and whether an attention-only activity view should be part of the same feature or a later follow-up.

A successful design would let users answer two different questions:

- **What needs me now?** ? priority ordering or an attention-only view.
- **What changed most recently?** ? current last-updated ordering.

It must not change task execution priority, runtime scheduling, model effort, or permissions. This is only a deterministic projection of existing conversation state.

## Why the feature appears to have many rules

"Priority" is not one signal. Each candidate signal represents a different user need and should be documented rather than hidden inside an opaque score.

| Signal or option | Why it exists | Proposed behavior |
| --- | --- | --- |
| Awaiting user input | Work cannot continue until the user answers a question or approval | Highest attention bucket |
| Blocked/error requiring action | The task may need recovery, a permission decision, or a changed constraint | High attention only when the state actually requires user action; not every historical error should float forever |
| Running/streaming | The user may want to monitor current work | Visible near the top, below conversations that cannot proceed without the user |
| Unread update/result | Work changed while the user was elsewhere | Promote until the conversation is read |
| Pinned | Explicit, durable user intent | Keep a separate pinned section; apply the selected ordering within that section rather than silently overriding pinning |
| Last updated | Best answer to "what happened recently?" and the current Maka behavior | Preserve as an explicit mode and use as a deterministic tie-breaker |
| Manual order | Gives users a stable personal arrangement independent of activity | Only add if we are willing to support drag/keyboard reordering, persistence, deletion cleanup, and new-session placement |
| Activity filter | Reduces the list to conversations that need attention | Treat as filtering, not as another sort mode; ordinary conversations are hidden but never mutated or archived |

These are not interchangeable:

- **Priority** is operational: it helps the user decide what to handle next.
- **Last updated** is chronological: it helps the user reconstruct recent work.
- **Manual** is intentional: it preserves a stable arrangement chosen by the user.
- **Activity view** is a focus mode: it removes non-matching rows instead of merely moving them down.

Adding all of them at once may create more UI and persistence complexity than value. A staged decision is preferable.

## Proposed product behavior

### Phase 1: selectable ordering

Add a small "Sort conversations by" control with:

1. **Priority**
2. **Last updated**

Suggested priority buckets:

```text
1. awaiting user input / approval
2. blocked state that has a current user action
3. running or streaming
4. unread update or result
5. everything else
```

Within the same bucket, order by `lastMessageAt` descending and then by stable session ID. The exact order of running versus unread should be validated with users; the important invariant is that action-required work outranks merely active work.

The current mode should remain available and the selected mode should be visible. For a conservative rollout, keep **Last updated** as the default until the priority policy is validated.

### Phase 2: optional activity view

If Phase 1 is useful but busy sidebars still require too much scanning, add a toggle that shows only:

- awaiting-user conversations;
- currently active conversations;
- unread conversations;
- actionable blocked/error conversations.

The view should have a clear empty state such as "Nothing needs attention" and a one-click way to return to the normal list. It must not mark anything as read or archive anything simply because the view was opened or closed.

### Phase 3: manual ordering only if justified

Manual ordering should not be included merely to match another product. It requires a real contract for:

- mouse and keyboard reordering;
- persistence scope;
- new conversation placement;
- linked child-session placement;
- project grouping;
- archived/deleted conversation cleanup;
- synchronization when multiple windows are open.

If those requirements are not worth the maintenance cost, Priority + Last updated is a complete and understandable feature without Manual order.

## Rough implementation approach

Keep the change as a projection over authoritative session state.

1. Introduce a small persisted UI preference such as:
```ts
type ConversationSortMode = 'priority' | 'updated_at';
```
Add `manual` only if Phase 3 is approved.

2. Add pure derivation functions for:
- attention reason;
- priority bucket;
- deterministic comparison;
- optional activity-view membership.

3. Derive signals from existing state rather than duplicating them:
- `SessionSummary.status`;
- live streaming/running state;
- `hasUnread`;
- current pending interaction/approval state;
- `isFlagged`;
- `lastMessageAt`.

4. Preserve hierarchy:
- pinned remains a separate section;
- linked child sessions stay attached to their parent;
- project grouping is not flattened by sorting;
- ordering is applied at the appropriate sibling/group boundary.

5. Persist the chosen mode at a clearly documented scope. A global desktop preference is simplest; per-project or per-sidebar-mode persistence should only be added if there is a demonstrated need.

6. Use explicit reason labels/tooltips where helpful. Avoid an unexplained numeric "AI priority score."

7. Add focused verification:
- unit tests for every bucket and tie-break;
- transitions when a session becomes waiting, running, unread, read, completed, or archived;
- pinned and linked-child invariants;
- persistence/restart behavior;
- keyboard and screen-reader behavior for the selector/toggle;
- renderer E2E coverage for switching modes without changing session data.

## Non-goals

- Reordering runtime execution or background-job scheduling.
- Asking a model to judge the semantic importance of conversation content.
- Changing permission or approval priority.
- Automatically pinning, archiving, or marking conversations as read.
- Copying Codex's exact visual design.

## Questions for discussion

1. Is priority ordering useful enough to add alongside the current last-updated order?
2. Should the first release include only sorting, or also the attention-only activity filter?
3. Should unread results rank above running work, or should running work remain more visible?
4. Which blocked/error states are genuinely actionable and should be promoted?
5. Should the preference be global, per workspace, or per sidebar mode?
6. Should pinned conversations always remain in a separate top section?
7. Is manual ordering worth its persistence and accessibility cost, or should it be deliberately omitted?
8. Should Priority eventually become the default after an opt-in period and usage feedback?

---

中文说明

## 问题

随着本地任务、云端任务、关联子会话和长时间运行的会话不断增加，Maka 左侧对话列表越来越难以快速浏览。

目前普通会话历史只有一套固定排序规则：

- 置顶会话单独分组并显示在前面；
- 每个分组内按照 `lastMessageAt` 排序；
- 会话行虽然展示状态、流式运行状态和未读状态，但用户不能选择其他排序方式。

这种规则很稳定，但一个正在等待用户输入、仍在执行、或者刚刚完成且结果尚未阅读的会话，可能被近期发生过普通更新的会话挤到视野之外。用户必须检查多个分组，才能找出下一项真正需要处理的工作。

Codex 最近增加了两个相关但不同的侧栏概念：

1. **优先级排序**：保留全部会话，但把需要输入或存在未读动态的会话提前。
2. **活动/优先级筛选**：只显示未读、正在执行或等待用户回复的会话。

上方截图只是产品行为参考，并不是要求复制 Codex 的具体视觉样式或文案。

## 期望结果

讨论 Maka 是否应该加入用户可选择的会话排序方式，以及“只看需要关注的会话”应当与排序功能一起实现，还是作为后续功能单独加入。

理想的设计需要回答两个不同问题：

- **现在什么事情需要我处理？**——使用优先级排序或活动筛选视图。
- **最近有哪些事情发生了变化？**——使用当前的最近更新时间排序。

这个功能只能调整会话列表的展示顺序，不能改变任务实际执行优先级、后台调度、模型思考强度或权限规则。排序结果应当完全由现有会话状态确定。

## 为什么看起来有这么多规则

“优先级”不是单一信号。每个候选信号解决的用户问题不同，因此需要公开说明，而不能把它们藏在一个无法解释的分数里。

| 信号或选项 | 为什么需要 | 建议行为 |
| --- | --- | --- |
| 等待用户输入 | 用户不回答问题或审批，工作就无法继续 | 放入最高关注层级 |
| 需要用户处理的阻塞或错误 | 任务可能需要恢复、权限决定或修改约束 | 只有当前确实需要用户操作时才提前；历史错误不能永久占据顶部 |
| 正在运行或流式输出 | 用户可能希望查看当前工作的进展 | 靠前显示，但排在无法继续、必须等待用户处理的会话之后 |
| 未读更新或结果 | 用户离开期间工作发生了变化 | 在用户阅读之前提前显示 |
| 置顶 | 表示用户明确且持久的关注意图 | 继续保留独立的置顶分组，并在该分组内部应用所选排序，不能让自动优先级悄悄覆盖置顶意图 |
| 最近更新 | 最适合回答“最近发生了什么”，也是 Maka 当前行为 | 保留为明确可选模式，同时作为同一优先级内的稳定次级排序条件 |
| 手动排序 | 让用户获得不受活动变化影响的固定排列 | 只有愿意承担拖拽/键盘排序、持久化、删除清理和新会话插入规则时才加入 |
| 活动筛选 | 把列表缩小到真正需要关注的会话 | 它属于筛选而不是排序；普通会话会被隐藏，但不会被修改或归档 |

这些选项不能互相替代：

- **优先级**属于操作视角，帮助用户判断下一步处理什么。
- **最近更新**属于时间视角，帮助用户回顾刚刚发生的事情。
- **手动排序**属于用户意图视角，保存用户自己决定的稳定结构。
- **活动视图**属于专注模式，它会隐藏不匹配的会话，而不只是把它们往下移动。

一次性加入全部选项可能带来超过实际价值的界面和持久化复杂度，因此建议分阶段决定。

## 建议的产品行为

### 第一阶段：可选择的排序方式

先增加一个小型“对话排序方式”控件，只提供：

1. **优先级**
2. **最近更新**

建议的优先层级：

```text
1. 等待用户输入或审批
2. 当前存在用户可处理动作的阻塞状态
3. 正在运行或流式输出
4. 存在未读更新或结果
5. 其他会话
```

同一层级内按 `lastMessageAt` 从新到旧排序，最后再用稳定的会话 ID 打破平局。正在运行和未读结果谁更靠前，可以根据实际使用反馈调整；重要的不变量是“必须由用户处理才能继续”的会话应当高于仅仅仍在运行的会话。

必须保留当前的最近更新模式，并让当前选中的模式清晰可见。为了保守上线，第一版可以继续默认使用**最近更新**，等优先级规则经过验证后再讨论是否改变默认值。

### 第二阶段：可选的活动视图

如果第一阶段有效，但会话很多时仍然需要大量扫描，可以再增加一个开关，只显示：

- 等待用户输入的会话；
- 当前仍在活动的会话；
- 存在未读内容的会话；
- 当前需要用户处理的阻塞或错误会话。

没有匹配内容时，应显示类似“没有需要关注的任务”的明确空状态，并提供一步返回普通列表的操作。打开或关闭该视图不能自动把会话标记为已读，也不能归档会话。

### 第三阶段：只有确有需要时才加入手动排序

不能仅仅为了与其他产品保持一致而加入手动排序。它需要完整定义：

- 鼠标拖拽和键盘排序；
- 排序数据保存在哪个范围；
- 新会话插入到哪里；
- 关联子会话如何跟随父会话；
- 项目分组如何处理；
- 已归档或已删除会话如何清理；
- 多窗口同时打开时如何同步。

如果这些成本不值得承担，那么“优先级 + 最近更新”已经是一套完整、容易理解的功能，不必加入手动排序。

## 大致实现方式

这个功能应当只是权威会话状态之上的展示投影。

1. 增加一个体积很小、可持久化的界面偏好：

```ts
type ConversationSortMode = 'priority' | 'updated_at';
```

只有第三阶段获批后才增加 `manual`。

2. 增加纯函数，用来推导：
- 为什么某个会话需要关注；
- 会话所属的优先级层级；
- 确定性的比较排序；
- 可选活动视图是否应包含该会话。

3. 直接使用现有状态，不再复制一套状态来源：
- `SessionSummary.status`；
- 当前流式输出或运行状态；
- `hasUnread`；
- 当前待处理的交互或审批；
- `isFlagged`；
- `lastMessageAt`。

4. 保持现有层级关系：
- 置顶继续作为独立分组；
- 关联子会话继续跟随父会话；
- 项目分组不能被排序过程打散；
- 排序只能作用于正确的同级会话或分组边界。

5. 明确排序偏好的持久化范围。全局桌面偏好最简单；只有确认存在真实需求时，才扩展为按项目或按侧栏模式分别保存。

6. 必要时通过状态原因标签或提示文字解释为什么某个会话靠前，避免出现无法解释的“AI 优先级分数”。

7. 增加有针对性的验证：
- 每个优先层级和次级排序规则的单元测试；
- 等待、运行、未读、已读、完成、归档等状态转换；
- 置顶和关联子会话不变量；
- 重启后的偏好恢复；
- 排序控件和筛选开关的键盘及屏幕阅读器行为；
- 切换模式不会修改会话数据的渲染端 E2E 测试。

## 不在范围内

- 调整运行时任务或后台工作的真实执行顺序。
- 让模型阅读对话内容并判断哪个项目“更重要”。
- 改变权限或审批的处理优先级。
- 自动置顶、归档或标记已读。
- 复制 Codex 的具体视觉设计。

## 需要讨论的问题

1. 优先级排序是否值得作为最近更新排序之外的新模式？
2. 第一版只加入排序，还是同时加入只看重点会话的活动筛选？
3. 未读结果和正在运行的任务，哪一种应该更靠前？
4. 哪些阻塞或错误状态真的需要用户操作，应该被提前？
5. 排序偏好应当全局保存、按工作区保存，还是按侧栏模式保存？
6. 置顶会话是否应当始终保留独立的顶部区域？
7. 手动排序是否值得承担持久化和无障碍成本，还是应该明确不做？
8. 在经历一段自愿启用和使用反馈之后，优先级排序是否应成为默认模式？

No implementation files or tests are named. Start by locating the conversation sidebar and existing session-state derivations for SessionSummary.status, hasUnread, isFlagged, lastMessageAt, and pending interaction or approval state. Done means an agreed scope and deterministic priority or filtering behavior, with persistence, hierarchy, accessibility, and verification requirements resolved before implementation.

Written by the indexing model from the issue text.