[Feature] 项目行聚合「运行中 / 刚结束」状态：折叠时也能看到在跑几个，并覆盖定时任务运行

[HanawaBanana]

想要的效果（一句话）

侧栏里折叠了会话列表的项目也能一眼看出：这个项目下有几个在跑（包含定时任务的运行），跑完有提示，并且能区分「全部结束」和「还有在跑」；点一下就能进到对应的会话 / 定时任务运行。这是个设计讨论，想先听你们的意见，同意方向我再开工。

现状（我都核对过代码）

• 会话级状态已经有：apps/desktop/src/lib/sidebar-session-status.ts 的 sidebarSessionStatus() 返回 running | permission | selected | completed | failed，样式在 apps/desktop/src/styles/sessions.css 的 .thread-item-status（运行中＝warning 点、需要批准＝紫点、完成＝绿勾、失败＝红叹号），动画的有界实现见 fix(sidebar): 限制运行状态呼吸动画，避免持续出帧 #1070 / fix(desktop): bound idle status indicator animations #1402。
• 项目级没有任何聚合状态：项目行只有 disclosure chevron + 文件夹图标；折叠时 .sidebar-session-group-body.project.collapsed + aria-hidden 把会话整个藏掉，于是「这个项目里还有 3 个在跑」这类信息完全消失。现在唯一用到「项目里有人在跑」的地方是删除项目的二次确认（Sidebar.tsx 里 entry.sessions.some(... runningSessions ...)）。
• 定时任务的运行在侧栏完全不可见：feat(scheduled): 定时任务页改造为「任务 + 运行记录」主从视图（#1291 阶段一） #1298 之后自动化转写已从会话列表/搜索收回（listableSessions），运行状态只在定时任务页里看；scheduled.finishRun 之后渲染层拿不到任何事件，也没有对应通知。
• 可以复用的：runningSessions、latestSessionOutcomes（会话级 outcome 徽标，读过通知即清除）、待批准的原生通知 + 提示音管线（stores/runtime/notification-runtime.ts）、NotificationCenter、托盘已有的「运行中/未读」入口（feat(tray): 托盘菜单支持运行中/未读/置顶会话快捷入口，并共享行额度 #402）、以及定时任务页现有的「任务 + 运行记录 + 打开会话/返回行」（feat(scheduled): 定时任务页改造为「任务 + 运行记录」主从视图（#1291 阶段一） #1298）。
• 相邻在做的事：feat(sidebar): align every row's leading edge, group pinned projects, and sweep running titles #1160（@zeroy1024，open）正在改行首对齐、单一前导字形和运行指示的动画范围，动的文件与本提案高度重叠（Sidebar.tsx、sidebar-session-status.ts、sessions.css、sidebar-threads.css）。

我的提案（推荐 A）

A1. 项目行左侧加一个「状态位」（保留文件夹图标形状，在它右下叠一个状态点/环，不用图标换色来表达状态，避免和 hover / 选中语义打架）

状态	表现	说明
运行中	warning 点 + 数字徽标	数字＝该项目当前运行中的会话数，含定时任务运行；aria-label 给全量语义（如「2 个会话 · 1 个定时任务运行中」）
需要你介入	紫点（沿用 permission 语义）优先于运行中点	权限/提问/Plan 待批准；数字仍只统计运行中
全部结束	绿色 ✓，短驻留	例如 10–15 秒，或被「查看过这个项目」清掉；提示「3 个会话已完成」
部分结束	warning 点 + 数字继续显示，冒一条瞬时提示	「1 个已完成，仍有 2 个在跑」，或在数字旁临时加 ✓1
有失败	红色 ⚠（沿用 failed）	与完成提示同一条通道

A2. 折叠态与展开态都显示状态位（折叠时才是刚需），折叠只影响是否列出会话。

A3. 项目行尾加一个独立的小入口（不改动「点击行＝展开/收起」的既有语义）：点开一个小浮层，分两节列出「运行中」与「刚刚结束 / 失败」，每条一键直达 —— 会话就切到对话，定时任务运行就跳到定时任务页并选中该任务与该次运行（#1298 已经有选中恢复）。浮层支持键盘、Esc、点外部关闭。

A4. 定时任务运行不建「临时会话」。 你原想法里的「临时会话看完即隐藏」我不建议做，原因具体：#1298 刚刻意把自动化转写从会话列表收回，临时会话会重新把它注入列表、和 reuse 模式（运行复用同一段会话）纠缠，还会带来「看过了但状态怎么算」的一致性问题。改成：

• 项目行数字分开计数：2 会话 · 1 定时；
• 浮层里单独一节「定时任务 · 任务名 · 已运行 3 分钟 · 查看运行记录」，点击直达；
• 运行结束同样走项目级「刚结束」提示，并且复用现有通知管线发一条「定时任务运行完成」（原生通知 + 可选提示音 + NotificationCenter），点它跳到对应运行 —— 这样也顺手补上了 feat(scheduled): 定时任务页改造为「任务 + 运行记录」主从视图（#1291 阶段一） #1298 之后「定时任务跑完没人告诉你」的空档。

A5. 读/清除语义：沿用现有「会话 outcome 徽标 + 读过即清」的模式：项目级提示在你查看该项目（或点开浮层）后清除，不常驻。

A6. 无障碍与主题：状态不单靠颜色（数字 + aria-label + 不同形状）；动画沿用有界呼吸并遵守 prefers-reduced-motion；亮/暗主题都用语义 token；浮层键盘可达。

可选 A7：同一套聚合镜像到托盘菜单与 macOS dock 角标（#402 已有托盘入口）。建议另开 PR，不塞进第一版。

替代方案

• B（更小）：只做「项目行数字 + 结束提示」，不做浮层入口；定时任务只在数字里体现。适合先把最有价值的部分落地。
• C（你原来的想法）：定时任务运行时在侧栏挂一个临时会话条目，看完/切换即隐藏。真要做需要先修订 feat(scheduled): 定时任务页改造为「任务 + 运行记录」主从视图（#1291 阶段一） #1298 的契约（自动化转写不进会话列表），我不推荐，但你们决定我就照做。
• D：侧栏不动，只在定时任务页增强运行提示。

想请你们定的几件事

1. 数字口径：定时任务运行是否合并进同一个数字，还是分开显示？（我建议分开：2 · 1 定时）
2. 结束提示驻留：短驻留（10–15 秒）还是常驻到查看为止？（我建议短驻留 + 查看即清，和现有 outcome 徽标一致）
3. 折叠态进入运行列表的交互：行尾独立按钮（我建议）还是长按/右键菜单？
4. 定时任务完成是否复用原生通知 + 提示音（现在提示音只在「需要你介入」时响）？默认开还是让用户设？
5. 是否同时做托盘 / dock 角标镜像，还是留后续 PR？
6. 和 feat(sidebar): align every row's leading edge, group pinned projects, and sweep running titles #1160 的顺序：等它落地后叠在它的「单一前导字形」模型上（我建议），还是先按当前结构做、事后再对齐？这两条路我都能配合。

实现草图（工作量可控，供评估）

• 数据：渲染层已有 runningSessions + 会话→项目归属 + latestSessionOutcomes；定时任务运行需要一个新的输入，建议 main 在 scheduled-runner 开始/结束时向渲染层发一条 scheduled.run.changed { taskId, runId, status, title }（最小、实时），渲染层不额外轮询 scheduled.listRuns。
• UI：Sidebar.tsx 项目行状态位 + 行尾入口 + 浮层组件；样式落在 sessions.css / sidebar-threads.css（与 feat(sidebar): align every row's leading edge, group pinned projects, and sweep running titles #1160 同文件，需要协调顺序）。
• i18n：预计 6–8 个新键 ×9 语言。
• 测试：渲染测试（折叠态数字、完成提示、权限优先、定时任务计数分开）、源契约测试（状态位与浮层入口）、E2E 计划场景（含定时任务运行的项目：折叠→数字→结束→绿点，覆盖「全部结束」与「部分结束」两种）+ 真机截图。
• 契约：component-spec §3 Sidebar（状态表）+ §20A（定时任务与侧栏的入口关系）+ E2E 场景，中英双语；是否加 ADR 看你们对本特性的定位。

如果你认可这个方向，告诉我走 A 还是 B（以及上面几个选择题的答案），我就开工出 PR：实现 + 双语契约 + 测试 + 真机截图一起交。@vastsa

[muzimu217]

方向同意，而且这是一份少见的"现状核对已经做完了"的提案——你引用的落点我们逐个对照过当前 main，全部属实：Sidebar.tsx:238 的 runningSessions 订阅、:1395 删除确认里现成的 entry.sessions.some(runningSessions) 聚合先例、:1824 的 collapsedProject 状态、sidebar-session-status.ts:14 的 sidebarSessionStatus()；scheduled.finishRun 在渲染层确实没有事件桥（stores 与 protocol.ts 均无），"定时任务运行侧栏不可见"的判断准确。

几点落地建议，供开工前对齐：

1. 聚合就放 selector，不要新 store：在项目行的 render 处从 entry.sessions + runningSessions 现算（:1395 已经是这个形状），折叠时也照常订阅——项目数通常 <几十，每行 O(sessions) 的成本可以忽略，不需要事件或缓存层。
2. 折叠行指示建议复用 .thread-item-status 的同一套视觉语义（运行中＝warning 点、需批准＝紫点），再加一个计数徽标；"全部结束 vs 还有在跑"可以用 latestSessionOutcomes 的 outcome 徽标同款绿勾表达"刚全部完成"——两种状态共用一套样式 token，避免侧栏出现第三种视觉语言。
3. 定时任务运行是本提案里唯一需要新管线的部分：host 侧已有 scheduled.finishRun，缺的是往渲染层广播这一跳。建议按 session:turnEnded 的既有桥接模式加一条 scheduled:runFinished 事件，顺带把 [Feature] 定时任务页改造成「任务 + 运行记录」主从视图：运行结果页内可读，定时任务会话从主界面会话列表收回 #1291 里"运行结果页内可读"的入口接上——点击折叠行徽标先落到运行详情，而不是落回会话列表。
4. 点击行为：折叠行上点徽标 = 展开该项目并滚动到第一个 running/permission 会话（permission 优先级高于 running，因为那是用户必须处理的）；这与 :1537 现有的会话定位逻辑可以直接复用。
5. 一个边界先想清楚：listableSessions（feat(scheduled): 定时任务页改造为「任务 + 运行记录」主从视图（#1291 阶段一） #1298）把定时任务转写从会话列表收回后，运行中的定时任务会话在 entry.sessions 里吗？如果不在，聚合就必须走第二条数据源（定时任务运行表），折叠行的"在跑几个"才会把定时任务算进去——这决定第 3 点是"接个事件"还是"接个事件 + 一条查询"。

政策提示：这是 feat，当前贡献窗口只收 fix/perf——建议开工前先和维护者确认这个是否在窗口内（或等窗口解除），避免做完合不进去。

[HanawaBanana]

谢谢确认，也谢谢逐行核对。逐条回应，其中第 5 点我用代码把结论定死了：

1（selector 聚合，不新增 store） 同意。补一层数据源拆分，正好回应你的第 5 点：

• 会话：项目行现有 entry.sessions 就够用（Sidebar.tsx:640 的 candidates 已经过 listableSessions），折叠时照常订阅，无额外成本。
• 定时任务运行：不在 entry.sessions 里 —— isAutomationSession() 只按 SessionSummary.scheduledRun === true 过滤（lib/session-origin.ts:14-34），而这些转写在侧栏被 listableSessions 直接剔除。但它们仍在 store 的 sessions 里（feat(scheduled): 定时任务页改造为「任务 + 运行记录」主从视图（#1291 阶段一） #1298 特意保留，供 Scheduled 页解析标题/来源/能力）。
• 关键一点：runtime/scheduled-runner.ts 开头就写着 "Runs through the same prompt entry point as an interactive desktop turn"，它调的是同一个 prompt(sessionId, content)，事件由 runtime/sidecar.ts 发 agentMessage —— 所以运行中的定时任务会话在渲染层同样是 runningSessions[id] === true。
• 结论：「在跑几个」不需要新查询，从「未过滤的 sessions + runningSessions + scheduledRun」按 projectPath 分组即可；真正缺的只是身份与结果（taskId / runId / 任务名 / 结束状态），这才是要补的那一跳。所以第 3 点不是「事件 + 一条查询」，而是「事件 + 一次 seed」（下面说）。

2（复用 .thread-item-status 语义） 同意，不加第三种视觉语言：warning 点＝运行中、紫点＝需批准、「刚全部完成」用现有 outcome 绿勾同款；计数徽标只加数字，状态不单靠颜色（数字 + aria-label 给全量语义）。

3（新增广播） 命名想按仓库既有风格对齐，建议 scheduledChanged → pi-desktop/scheduled/event/changed（和 sessionsChanged / todosChanged / plansChanged 同构；protocol.ts 的 event 表里没有 session:turnEnded 这个名字），payload 建议 { taskId, runId, taskTitle, status, sessionId, projectPath }。
另外光有事件会漏：渲染层如果是在运行开始之后才挂载/重载的，就不知道有运行在飞。建议 seed 走现成通道 —— 在 scheduled.list 的任务行上带一个 runningRun 摘要（Scheduled 页本来就要拿这个列表），不额外加新查询。点击徽标落到运行详情：同意，复用 #1298 的「选中任务 + 选中运行」恢复路径。

4（点击行为） 同意「展开 + 定位」，优先级按你说的 permission > running。不过你说的 :1537 我这边对不上 —— 那个位置是 moveSessionToProject 的运行中拦截；我会在实现时用现有的 reveal/定位通道（搜索跳转那条）确认并复用，如果确实需要新写一个定位函数我会在 PR 里说明。

5（边界） 见第 1 点：定时任务运行会话不在会话列表里，但在 store 里且在 runningSessions 里，所以计数能算、身份要补。

政策：这条 feat 我预期在窗口内 —— #1298 当时被按临时类型政策关闭过，@vastsa 随后更正为「维护者授权的定向贡献者，适用 §15 维护者例外」并重新打开，之后的两个 feat（#1326、#1391）也都正常合入。不过既然你专门提醒，我按你说的先请 @vastsa 确认一句。确认之前我只在分支上做实现与测试，不提前开 PR；一旦你或 @vastsa 点头，我就把实现 + 双语契约（component-spec §3 / §20A、E2E 场景）+ 真机截图一起交上来。

我这边同时会注意与 #1160 的重叠（同一个 Sidebar.tsx 与 sessions.css），落地时以它合并后的结构为准。

[muzimu217]

三处都按当前 main（278e929ca）复核了，先认错再确认：

• :1537 是我们引错了——Sidebar.tsx:1533 起就是 moveSessionToProject，:1537 是它的 runningSessions[sessionId] 运行中拦截，不是定位通道。点击定位请按你说的走搜索跳转那条现成通道，抱歉。
• 其余锚点在当前 main 都对得上：:238 runningSessions 订阅、:1395 的 entry.sessions.some(runningSessions) 聚合先例、:1824 collapsedProject。
• 你的两处论断验证无误：session-origin.ts 的 isAutomationSession / listableSessions（scheduledRun 过滤、转写留在 store）与 scheduled-runner.ts:4 的"同一 prompt 入口"注释，均在。
• 命名族确认：packages/shared/src/protocol.ts:407-411 正是 pi-desktop/session|plans|todos/event/changed，你提的 pi-desktop/scheduled/event/changed 同构成立。
• "事件 + 一次 seed"（scheduled.list 行带 runningRun 摘要）比我们原提的"事件 + 查询"更省，同意按这个收口。

政策脉络（§15 维护者例外、#1326/#1391 先例）与我们掌握的一致；先在分支做、确认后再开 PR 的节奏很稳妥，我们不再补噪声评论。

[HanawaBanana]

已收到开发团队的确认，按上面回应的方案开工并交上来了：

PR #1453 → #1453
分支 feat/project-running-status，基于 main 278e929ca，2 个提交。

落地的是第 1、2 点（selector 聚合、不新增 store / 复用 .thread-item-status 语义）+ 第 3 点（新增广播 scheduledChanged → pi-desktop/scheduled/event/changed，并在重载后用 scheduled.list + 每任务最近一次运行做 seed）+ 第 4 点（点击＝展开 + 定位，优先级 permission > running）：

• 折叠的项目行显示 3 · 定时任务 1 这类摘要，定时任务运行与会话分开计数，aria-label 给全量语义；需要你介入时用紫点并优先于运行中点；结果沿用未读规则，打开会话即清。
• 运行到达 / 结算 / 派发失败三处公告；结算只在 scheduled.finishRun 成功之后发。
• 契约（component-spec §3.9a、§20A.4、E2E 场景、D650）中英双语；测试 3606 passed / 0 failed；真机截图在 .github/pr-assets/project-running-status/。

没有塞进这一版的（都在 PR 里写明了）：浮层入口（A3）、定时任务完成的原生通知／提示音、托盘／dock 角标镜像（A7）。另外我这边没有动「临时会话」——维持 #1298 的契约，定时任务转写仍不进会话列表。

#1160 仍是 open，本 PR 按当前 Sidebar.tsx / sessions.css 落地；它合并后需要按它的「单一前导字形」模型再对齐一次，愿意配合。