我把桌面宠物做成了一个真正的任务入口

在 Electron shell-v3 的浅色主题验收里，桌面宠物已经不只是停在屏幕上的装饰角色：点击它可以打开任务面板，提交任务；任务完成后，面板会留下结果摘要，用户可以复制结果，也可以再次执行上一个由宠物提交的任务。

这次改动的难点不在于增加一个点击事件，而在于重新定义桌面宠物和任务系统的关系。我借助 AI 开发工具梳理需求、拆分状态和检查改动，最后把它推进成一个有执行过程、有结果保留、允许中止，也有明确重跑边界的轻量入口。

先把“宠物能做什么”拆成完整任务流程

我先没有从界面细节入手，而是把需求拆成一条完整流程：用户如何提交任务，执行中能看到什么，什么时候可以停止，完成或失败后留下什么，以及空闲时哪些内容可以再次使用。

因此，任务面板需要覆盖几种不同状态。运行期间展示推理、工具调用和耗时状态；用户可以停止任务，也可以跳转到完整会话继续处理确认。任务结束后，无论完成还是失败，都保留摘要并支持复制。

这个拆分也避免了把“重跑”理解成简单复制按钮。只有由桌面宠物入口提交的最近任务，才会出现在空闲状态下的再次执行入口里。完整会话历史不能直接被当成桌面快捷操作，否则入口边界会变得模糊。

拖动位置和 Shift+点击弹出独立窗口，则是桌面入口本身的交互基础。前者保证宠物可以放在合适的位置，后者让任务面板可以脱离原来的驻留形态工作。

重跑功能先处理身份和数据边界

重跑看起来是一个轻量功能，实际需要先回答两个问题：最近一次任务属于谁，以及弹出窗口需要知道多少数据。

我的处理方式是把重跑提示词只保存在内存中，并按 Profile 隔离。切换 Profile 时立即清空这份内容，避免一个身份留下的任务被另一个身份重新执行。这里没有把提示词当成长期历史保存，重跑能力只服务于当前 Profile 的最近一次宠物任务。

跨窗口传递也做了收缩。弹出窗口只接收“是否允许重跑”的布尔状态，不接收原始提示词。这样，窗口只知道自己是否可以提供这个动作，真正的任务内容仍留在更小的作用范围里，减少了跨窗口暴露的数据。

这两个判断决定了重跑功能的边界：它不是对所有历史任务开放的通用复现机制，而是一个受入口、身份和内存生命周期限制的快捷操作。对桌面宠物来说，这个范围足够实用，也更容易解释和检查。

主线合并后，重点返工的是边界状态

开发过程中并不是把原有实现直接保留下来就结束了。与远端主线合并时，我需要保留桌面宠物的重跑能力，同时适配主线更新后的桌面路由和依赖。

这类返工容易被忽略，因为功能名称没有变化，真正变化的是它所依赖的运行环境。我的检查重点因此放在状态和入口之间是否仍然连得上：运行中的任务能否停止，完成态是否保留摘要，弹出窗口是否拿到正确的重跑许可，Profile 切换后旧提示词是否已经清空。

验收还暴露出窄面板布局和交互状态需要修正。除了正常完成态，我把运行态、弹出态、深色主题、浅色主题和减少动效模式都纳入检查，避免桌面宠物只在单一尺寸和单一主题下成立。

中英文、深浅主题、窄布局和减少动效模式也因此被视为同一项交互适配问题，而不是后续再补的装饰项。任务入口一旦常驻桌面，状态文字、布局和动效就会直接影响它是否可用。

用类型、测试和真实 Electron 壳层检查结果

AI 开发工具可以帮助我快速整理实现路径，但它不能替代对结果的核对。为了确认改动没有停留在界面层，我按不同层次检查了代码和实际壳层表现。

桌面 TypeScript 类型检查通过，目标范围的 ESLint 检查也通过。测试方面，8 个 Vitest 文件共 95 项测试通过；桌面主进程及相关能力的两组 Node 测试共 87 项通过。

这些检查覆盖了类型、规则、桌面侧逻辑和主进程相关能力，但我没有把它们当成唯一结论。Electron shell-v3 还完成了浅色、深色、运行中、完成态、弹出窗口和减少动效场景的验收，重点确认任务状态和窗口交互在真实壳层中仍然成立。

最终留下的不是一个会动、会弹窗的桌面宠物，而是一个有明确职责的任务入口：它能接收任务，展示执行过程，允许中止，保留结果，并且只在当前 Profile 和限定入口内重跑最近任务。