Should project task lists progressively reveal tasks?

[Phoenix500526]

English

Context

@Astro-Han, PR #1732 moved project task navigation to the official Astryx shell and explicitly said that the old four-item preview path was not retained in parallel.

We would like to understand whether that was a migration-scope decision, or a product decision that should still guide the current sidebar.

In day-to-day agent work, users often create one task for each unit of work and keep several tasks running in parallel. A project can therefore accumulate many tasks. The current By project view renders every task at once, so one project can make the sidebar very long and harder to scan.

Proposed direction

A progressive-disclosure pattern similar to Codex may improve this:

• show the first 5 tasks in each project;
• show a Show more control when more tasks exist;
• reveal 10 additional tasks on each activation;
• keep revealing 10 at a time until all tasks are visible;
• keep the project count badge showing the total task count.

One related question is what should happen when the active task is outside the currently visible range. The old four-item implementation expanded automatically so that the active task was not hidden.

Questions

1. Was the old preview removed only because the TreeList migration should not keep a parallel custom path, or was progressive disclosure itself considered undesirable?
2. Would restoring progressive disclosure in the current sidebar be consistent with the intended design?
3. If restored, should an active task outside the current 5 + 10 window become visible automatically?
4. Are there interaction or accessibility constraints from the Astryx migration that this proposal should preserve?

No implementation is being proposed until the intended product behavior is clear.

Drafted with OpenAI Codex at the contributor direction and reviewed by the contributor of record.

简体中文

背景

@Astro-Han，PR #1732 将项目任务导航迁移到了官方 Astryx shell，并明确说明不再并行保留旧的四项预览路径。

我们希望确认：这只是当时迁移范围上的取舍，还是一项今天仍应遵循的产品决策。

在日常使用 Agent 时，用户通常会为每个工作单元创建一个任务，并让多个任务并行推进。因此，一个项目下面很容易积累大量任务。当前的 按项目 视图会一次性渲染全部任务，单个项目就可能把侧栏拉得很长，扫描和切换体验都不理想。

建议方向

可以考虑采用类似 Codex 的渐进展开方式：

• 每个项目初始显示前 5 个任务；
• 还有更多任务时显示 Show more；
• 每次点击再显示 10 个任务；
• 持续按每次 10 个追加，直到全部显示；
• 项目右侧的数量徽标始终显示任务总数。

还有一个相关问题：如果当前选中的任务不在已显示范围内，应该如何处理。旧的四项预览实现会自动展开，避免隐藏当前任务。

希望确认的问题

1. 旧预览机制被移除，只是因为 TreeList 迁移不希望保留并行的自定义路径，还是因为渐进显示本身不符合产品方向？
2. 在当前侧栏重新引入渐进显示，是否符合原本的设计意图？
3. 如果重新引入，当前任务位于 5 + 10 的可见窗口之外时，是否应自动显示？
4. Astryx 迁移带来的交互或无障碍约束中，有哪些是新方案必须继续保持的？

在产品行为明确之前，我们暂不开始实现。

本文由 OpenAI Codex 按贡献者要求协助起草，并由贡献者本人审阅和负责。

[Astro-Han]

Good question to ask before building — thanks for checking rather than assuming.

It was a migration-scope decision. What I wrote in #1732 was that the four-item preview path "is not retained in parallel," and the concern was the parallel path: TreeList had taken over project expansion, and keeping a second custom implementation of the same behaviour alongside it was what I didn't want. Progressive disclosure as an interaction was never the objection. So restoring it is consistent with the intent.

The active task outside the visible window — the old implementation already answered this, and I'd keep its answer. It expanded automatically when the active session's index fell past the limit, so the thing you're currently working on is never hidden behind a control you have to find. That rule should survive whatever window size we pick.

On 5 + 10, that seems reasonable and I don't have a strong view. The old limit was 4, Codex uses 5; either is fine. Keeping the badge on the total count is right.

But before anyone starts: Astryx has no primitive for this, including in the latest release. I checked 0.5.2 (we're on 0.5.0). The gap isn't a missing button — it's that every related component has only two states, and this needs a cursor that can be advanced repeatedly:

• OverflowList — closest by name, but it's a horizontal list that decides how many items fit from the container's available width. maxVisibleItems is a width-overflow cap, maxRows is bounded wrapping, collapseFrom picks which end collapses. The state is measured, not advanced by the user.
• Collapsible — whole-section open/close. No "first N visible" middle state.
• MoreMenu — overflowing items leave the list and go into a dropdown, rather than staying in place.
• Pagination — paged navigation replaces the previous page instead of accumulating.

Across all 587 type definitions in the package, maxVisibleItems appears only on OverflowList and its useOverflow hooks. TreeList itself takes only items, density, variant, and header.

So my suggestion is to raise this upstream with Astryx as a TreeList feature request rather than build it here. Three reasons:

1. Building it ourselves is more work than it looks — the window, the cumulative reveal, the auto-expand rule, and the keyboard and screen-reader behaviour all have to hold together inside a tree.
2. It would pull us away from the primitives, which is the thing refactor: adopt official Astryx desktop shell #1732 was correcting. A custom list shadowing TreeList's own expansion state is exactly the parallel path I removed.
3. A vertically capped list with cumulative reveal is a general pattern, not a Maka one — it belongs in the design system. And frankly, we don't currently have a designer or a dedicated frontend person in the community, so component-level interaction design is better done by the people who own the system than approximated by us.

If upstream can't take it, we can revisit building a thin layer here — but it should be one path, not a second implementation next to TreeList.

On accessibility, the old implementation is the reference either way. It carried aria-expanded, aria-controls pointing at the group body, and a showMoreAriaLabel(hiddenCount) announcing how many items were hidden. Whatever we end up with should keep that, and TreeList's own arrow-key traversal has to stay intact.

简体中文

在动手之前先问清楚，这个做法很好——感谢你来确认，而不是直接假设。

那是迁移范围上的取舍。 我在 #1732 里的原话是四项预览路径「不再并行保留」，我顾虑的是那条并行路径：TreeList 已经接管了项目展开，在它旁边再保留一份实现同样行为的自定义代码，才是我不想要的。渐进展开这个交互本身从来不是反对的对象。所以重新引入它符合原本的意图。

关于当前任务落在可见范围之外——旧实现已经给出了答案，我会沿用它。当活跃会话的下标超出上限时，它会自动展开，因此你正在使用的东西不会被藏在一个需要你去找的控件后面。无论最终选多大的窗口，这条规则都应该保留。

关于 5 + 10，我觉得合理，也没有很强的偏好。 旧的上限是 4，Codex 用 5，都可以。徽标保持显示总数是对的。

但在动手之前：Astryx 没有对应的原语，最新版本也没有。 我查了 0.5.2（我们目前用 0.5.0）。缺的不是一个按钮，而是每个相关组件都只有两种状态，而这个需求需要一个可以反复推进的游标：

• OverflowList —— 名字最接近，但它是横向列表，根据容器剩余宽度自动决定能放几个。maxVisibleItems 是宽度溢出的上限，maxRows 是有界换行，collapseFrom 决定从哪一端收起。它的状态是测量出来的，不是由用户推进的。
• Collapsible —— 整段开合，没有「先显示前 N 条」这种中间状态。
• MoreMenu —— 溢出的条目会离开列表进入下拉菜单，而不是留在原位。
• Pagination —— 翻页是替换上一页，而不是累加。

整个包的 587 个类型定义里，maxVisibleItems 只出现在 OverflowList 和它的 useOverflow hooks 上。TreeList 本身只接受 items、density、variant、header。

所以我的建议是把它作为 TreeList 的功能需求提到 Astryx 上游，而不是我们自己实现。 三个理由：

1. 自己做比看上去麻烦——窗口、累积展开、活跃项自动展开的规则，以及键盘和读屏行为，都要在一棵树内部同时成立。
2. 这会让我们再次脱离原语，而那正是 refactor: adopt official Astryx desktop shell #1732 当初要纠正的问题。一个与 TreeList 自身展开状态并行的自定义列表，恰恰是我当时移除的那条并行路径。
3. 纵向限量加累积展开是一个通用模式，不是 Maka 特有的，它应该属于设计系统。而且坦率地说，我们社区目前既没有设计师，也没有专职的前端，组件级别的交互设计交给拥有这套系统的人来做，比我们自己近似实现要好。

如果上游无法接收，我们可以再回来考虑在这里做薄薄的一层——但它必须是单一路径，而不是 TreeList 旁边的第二份实现。

无障碍方面，无论走哪条路，旧实现都是参照。 它带有 aria-expanded、指向分组主体的 aria-controls，以及会播报隐藏条目数量的 showMoreAriaLabel(hiddenCount)。最终方案应当保留这些，同时 TreeList 自身的方向键遍历必须完好。

(Drafted with AI assistance; I verified the removed implementation in #1732 and the Astryx 0.5.2 component surface myself.)