[Bug] UI交互优化

[wangl886]

What happened? / 问题描述

1.选择交互面板缺少背景色，

2.主题窗口和侧边窗口缺少背景区分

3.窗口呼出隐藏快捷键建议合成一个，切换方便

4.左侧面板交互建议参考codex，添加固定新会话按钮，在新会话中可以选择项目
历史会话加入是否按照日期合并

5.项目管理中无法真正删除项目

App version / 应用版本

0.14.8

Operating system / 操作系统

Windows

Extra environment / 其他环境信息

No response

Logs / 日志

Screenshots / 截图

No response

[vastsa]

下个版本安排上～

[wangl886]

加油佬友，猛猛干~

[vastsa]

这条 issue 里 5 项混在一起，我按「能否从代码证实」逐条分了类，其中只有第 5 项是可证实的缺陷，已修复；PR：#439

第 5 项「项目管理中无法真正删除项目」——确认是缺陷，已修

菜单里其实有删除动作，但只要项目下有任何会话在运行就会被拒绝：

const runningCount = entry.sessions.filter((s) => runningSessions[s.id] === true).length;
if (runningCount > 0) { showToast(t("project.deleteRunningBlocked"), { variant: "warning" }); return; }

setDeleteProjectFor(entry) 根本到不了，ProjectDeleteDialog 也就永远不会挂载。这条拒绝是一条转瞬即逝的 toast，没有任何可继续的路径 —— 有任务在跑的项目就是删不掉，和你的描述完全一致。

改动：侧边栏菜单和项目索引菜单现在始终打开对话框，各自传入该项目当前在运行的会话 id；对话框在每次渲染时从该 prop 推导文案，所以对话框打开期间新开始或结束的回合都会在你确认之前被反映出来。对话框新增一行警告点名有 {{count}} 个会话正在运行，确认按钮文案换成「停止任务并删除」；确认会先精确中止这些会话，然后才调用删除。取消不删除任何东西。

也就是说，删除一个正在运行的回合仍然是针对已陈述后果的、第二次显式确认。宿主侧的守卫没有放宽：只要仍有关联会话存在运行中的回合，projects.remove 依旧以 CONFLICT 拒绝，对话框也依旧把它映射为 project.deleteRunningBlocked —— 这条兜底正是为「中止循环之后才开始的回合」准备的。没有削弱任何权限、确认或安全检查。

顺带说明：pnpm test:e2e 里本就有 E2E-PROJECT-delete-removes-project-and-owned-sessions 等场景是绿的，所以问题确实在渲染层的这道前置拒绝，而不在删除本身。

另外 4 项的分类（未实现，需要你决定）

#	报告项	结论	依据
1	选择交互面板缺少背景色	无法从代码证实	相关交互表面（权限卡、计划审批、提问面板）的背景都取自既有的 --ds-* 表面层，代码里看不到「缺一个背景」这种客观事实。这属于渲染结果，而你给的 6 张截图我们看不到。需要当前版本的截图。
2	主题窗口和侧边窗口缺少背景区分	无法从代码证实	侧边栏与主题窗口背景都来自同一 --ds-* 表面层，且按设计刻意接近；「区分不够」是视觉判断而不是代码事实。同样需要当前版本截图。
3	窗口呼出/隐藏快捷键合成一个	属于功能变更，会改默认值	确实存在两个独立全局快捷键（pluginLauncherAccelerator 与 summonWindowAccelerator，在 bootstrap/launcher.ts 注册/注销，bootstrap/shutdown.ts 也参与）。合并等于移除或改写一个用户可能依赖的快捷键，属于用户可见的默认值变更，按仓库规则不应悄悄改。建议单开 issue，并明确是「合并 / 加别名 / 删除」哪一种。
4	固定新会话按钮 + 新会话里选项目 + 历史按日期合并	功能请求	新增 UI 入口 + 信息架构调整，不是缺陷。

第 1、2 项如果你想推进，麻烦补一张 0.14.8 或更新版本的截图，并说明你期望这些表面跟哪个参照面区分开（比如「和输入框一样」或「比侧边栏更亮」），我就能把它变成可判定的任务。

验证

在集成后的本地 main（merge commit 9b1f3631，已包含当时的 origin/main）上：build:js、typecheck、lint:biome、docs:check(443 页) 通过；pnpm -r --if-present test 通过（desktop 2026/2026，0 fail）；pnpm test:e2e（含新增 E2E-PROJECT-delete-running-sessions-are-named-and-stopped）、test:e2e:boot、test:e2e:layout(37/37)、test:e2e:transcript、test:e2e:transcript-disclosure、test:e2e:theme-surfaces、test:e2e:skill-market(5/5)、test:e2e:subagents(31/31) 全部通过。project-delete.test.mjs 已扩展覆盖运行中会话这条路径，无修复时会失败。

集成过程中还处理了一次决策编号冲突：main 上刚落地的另一项改动占用了 D429，所以本项记为 D431（同批的展开详情修复记为 D430）。

[vastsa]

补一条：上一条评论里我对第 1、2 项的结论只说「无法从代码证实」，不够具体，而且第 2 项的框架我说错了。逐行量过之后，真实情况如下。

第 2 项更正：侧栏与窗口从不相等，真正同色的是另一对

对比	浅色	深色
侧栏 .sidebar（chrome.css:201 → --ds-bg-sidebar）	#f3f3f3（tokens.css:187）	#000000（tokens.css:39 → --ds-bg-under:50）
主窗 / 面板底（--ds-bg-primary）	#ffffff（:186）	#181818（:38 → --gray-900:29）
差值	约 4.7%	约 9.4%

所以「主题窗口和侧边窗口缺少背景区分」在代码层面不成立——两者一直是不同值，深色下差异还相当明显；浅色下确实较弱（4.7%），那更像设计口味。

真正逐字节相同的那一对是：面板头 / 浏览器条 vs 主窗（浅色）。work-panel.css:130 / :997 / :1148 用 --ds-bg-dock-raised，它在浅色下就是 #ffffff（tokens.css:194），与主窗 #ffffff 完全一致。如果你截图里觉得「糊在一起」的是工作面板顶部那一条（而不是侧栏），那就对上了 —— 这是一个可定位、可修改的目标。要改的话建议给 --ds-bg-dock-raised 一个浅色下的独立值；但这会改变内置外观，按「token 默认值保持观感不变」的约定需要维护者先拍板。

第 1 项：面板并不缺背景声明，是「底纹太淡」

所有「选择类」面板的根元素都有显式背景，例如 .asktool-card（messages.css:62-68，背景在 :67 = var(--ds-tile)）、.asktool-option、.permission-card、.plan-approval-bar、.extension-prompt-option、.turn-outcome-card，菜单/popover 用 --ds-bg-elevated-opaque。

真正的原因更可能是：--ds-tile 只是 3.5% 的墨色混合（tokens.css:97 深色 / :211 浅色），铺在 #181818 上几乎看不出来。所以这是对比度口味问题，不是「缺少背景色」的缺陷。要提高它就得改内置观感，同样属于设计决策。

结论（需要你或维护者回答才能继续）

1. 第 2 项：你截图里觉得糊在一起的是侧栏 vs 主窗，还是工作面板顶部条 vs 主窗？如果是后者，我可以直接给出改动方案（给 --ds-bg-dock-raised 浅色独立值）。
2. 第 1 项：你希望这些面板比周围更亮一点吗？如果是，请给一个参照面（例如「和输入框一样」或「比消息底更亮」），我就能把它变成可判定的任务。
3. 两项都属于「会改变内置外观」的设计决策，所以都需要维护者确认，而不是当作 bug 直接改。

第 3、4 项维持上一条评论的分类（功能请求，第 3 项需先明确是合并 / 别名 / 删除）。第 5 项已修，见 PR #439。

[vastsa]

本轮处理结果，5 项逐条落地如下。

第 1 项「选择交互面板缺少背景色」——确认是缺陷，已修并合入 main（PR #488，决策 D437）

它不是「没有背景」，而是画在了错的层：卡片挂在透明的 composer dock 里（Composer.tsx 直接渲染在 .composer-stack 下），却仍在用流动层的 --ds-tile（3.5% 墨色、无阴影），所以浅色下就是一块 #f7f7f7 贴着白底。同槽位的 Plan/Goal 批准条本来就用 --ds-bg-composer + --ds-shadow-composer，03-permission-ux.md §9 与 08-component-spec.md §11.5 也明文要求「透明 dock 内画 composer 板」——dock 规则的注释甚至已经这么写，只是实现没跟上。现在卡壳画 composer 板，选项行与自定义输入改用板上的内嵌层 --ds-tile-deep。全部走既有 --ds-* 令牌，浅/深两套都用真实 Chromium 抓图像素验证过。

第 5 项「项目管理无法真正删除项目」——已验证此前已修

main 上 ProjectDeleteDialog 现在接收 runningSessionIds、显示警告、确认时先 abort 再删除，调用方的提前 return 已移除，宿主侧守卫未放宽。

第 2 项「主题窗口和侧边窗口缺少背景区分」——维持不动（已决策）

实测两张投稿图边界两侧就是 #f3f3f3 ↔ #ffffff（浅色约 4.7%），本来就不同色，属「差异小」的观感问题。全仓唯一逐字节相同的一对是浅色 --ds-bg-dock-raised = --ds-bg-primary = #ffffff，而这是 D419 有意保留的 46px chrome 连续带。决定：不动，改它等于改内置外观。

第 3 项「呼出/隐藏快捷键合成一个」——已决策：合并成一个切换键

summonWindow（Mod+Shift+W）与 closeWindow（Mod+W）目前是 D384 定的对称键。决定：合并为一个切换键（Mod+W 呼出/隐藏），弃用 Mod+Shift+W，并会用新的决策记录取代 D384 里对称键的口径。已在排期，落地后会在这里同步。

第 4 项「侧栏参考 codex」——部分已实现，其余暂不做

• 历史按日期分组已经实现：项目分组内有 today / yesterday / 本周 / 14 天内 / 更早。
• 固定新会话按钮与**「新会话里先选项目」**：决定暂不做（当前入口够用：侧栏滚动区的「新建临时会话」与项目行的 +）。

[vastsa]

第 3 项已落地并合入 main（PR #495，决策 D438，取代 D384 的对称键口径）：

• 目录里只剩一个 toggleWindow = Mod+W：窗口可见且在前台 → 隐藏；否则 → 显示并聚焦。Mod+Shift+W 不再注册。
• 三条入口共用同一个动作：全局加速键、macOS 菜单项（新增原生 toggleMainWindow）、渲染层按键。
• 「隐藏」就是 Window.hide()：不调 close() / destroy() / app.quit()，所以关闭行为询问、window-all-closed、before-quit（含应用内更新重启的确认）都不会被触达，应用与窗口都存活；托盘、同一个键、macOS 应用激活都能唤回。窗口标题栏的关闭按钮仍是唯一进入关闭行为的入口。
• 存量配置在读取时折叠（幂等、不改写存储）：已有 toggleWindow 原样胜出；否则第一个带绑定值的退役项胜出（closeWindow 优先，因为 Mod+W 正是开关键保留的那个键）；只写 null 的退役项在没有绑定值竞争时被尊重；等于自身退役默认值的存储值视为无意图并丢弃。

真机验证（macOS，候选 commit，临时 profile，CDP + 真实键盘事件）：真实 Cmd+W 能隐藏前台窗口（visibilityState=hidden）并再次唤回，窗口未销毁、应用未退出；真实 Cmd+Shift+W 无任何反应。Windows / Linux 为源码与单测级证据。

至此这条 issue 的 5 项都已处置：第 1 项已修（#488），第 2、4 项按前述决定不动/暂不做，第 3 项本次落地（#495），第 5 项此前已验证修好（#439）。

[vastsa]

复核结论：该 issue 的 5 项已逐项处置。第 1 项由 PR #488 修复并合入；第 3 项由 PR #495 修复并合入；第 5 项由 PR #439 修复并合入；第 2 项经代码核对确认是既有色彩层级/设计取舍，不是缺失背景；第 4 项的日期分组已实现，其余入口调整已明确暂不做。因此不再作为未修复 bug 跟踪，后续若要改变设计或补充入口请另开 enhancement。