mesalogo
56ebd40bd8
Remove Ask/Execute modes and general product tool approvals so requests use the selected runtime, enabled capabilities, and execution account permissions. Migrate retired application metadata while preserving user content. Retire the Results page while retaining conversation images and stored artifacts. Add local and remote workspace file imports, timestamps and sorting, improve image discovery and saving, and refine workspace navigation and supervision responsiveness. Include the accompanying web-search changes, tests, probes, and product documentation. Remote imports require an updated Agent. Existing artifacts are not automatically copied into project directories. Validation evidence and outstanding failures remain documented in feature progress files; no full test suite or real-model calls were rerun for this commit. Release note: Run requests without switching work modes, import files into a selected local or remote workspace folder, sort workspace files by date, and keep using conversation images after removal of the Results page.
12 KiB
工具执行环境 User Stories
文档信息
| 项目 | 内容 |
|---|---|
| 状态 | 已实施，验收中 |
| 版本 | 0.3 |
| 日期 | 2026-09-02 |
| 关联 PRD | 工具执行环境 PRD |
| 关联逻辑 | 工具执行环境功能逻辑设计 |
1. 角色
1.1 普通用户
希望直接使用文档、演示文稿或数据处理 SKILL，不理解 Node.js、Python、pip 或 PATH。
1.2 MCP 使用者
希望配置一个本机工具服务，并由 GoodBuddy 解决其基础解释器启动问题。
1.3 专业开发者
已有明确的 Node、Python、虚拟环境或 Conda 环境，希望控制实际版本和绝对路径。
1.4 内网与离线用户
无法稳定访问公网，需要使用选定镜像或离线准备环境，同时不向远程 Host 传播本机配置。
2. Epic A：普通用户无需预装环境
US-A0 首次看到准确默认状态
作为普通用户，我希望第一次打开设置时看到 GoodBuddy 已提供什么、还需要安装什么，以免 误以为所有工具都已就绪。
验收：
- 全新安装默认选择 GoodBuddy 托管 Node 和 Python
- 托管 Node 立即执行真实诊断并显示版本
- 未安装的托管 Python 显示“尚未安装”和安装入口
- 检测到的系统解释器只作为自定义候选，不改变默认来源
- “工具执行环境”Tab 持续说明只对新启动的本机 Runtime 和 stdio MCP 生效
US-A1 直接使用托管 Node
作为普通用户，我希望安装 GoodBuddy 后即可使用 Node.js SKILL，以免单独安装 Node.js。
验收：
- Given 系统 PATH 没有 Node.js
- When 本机请求运行普通 JavaScript SKILL
- Then
node使用 GoodBuddy 托管来源 - And
npm、npx与该 Node 来源一致 - And 设置显示实际 Node 版本
US-A2 按需安装 Python
作为普通用户，我希望在设置中安装 Python，以便运行 Python SKILL 而不离开 GoodBuddy。
验收：
- Given 系统没有 Python 且托管 Python 未安装
- When 用户点击安装
- Then 页面显示下载、校验和安装进度
- And 成功后真实 Python、pip、venv 诊断通过
- And 失败不会留下半安装目录
US-A3 看懂缺失依赖
作为普通用户，我希望区分“没有 Python”和“缺少 python-pptx”，以便采取正确修复操作。
验收：
- 工具解释器不可用时显示工具环境错误
- 解释器可用但能力包缺失时显示能力依赖错误
- 页面不把
python --version成功描述为 SKILL 已完全可用 - 错误保留原任务和可执行的下一步
US-A4 看懂部分就绪
作为用户，我希望知道解释器可用但配套命令损坏，以免把所有失败都理解为没有安装环境。
验收：
- Node 可用而 npm/npx 失败时显示“部分可用”和具体失败项
- Python 可用而 pip、venv 或 SSL 失败时显示“部分可用”和具体失败项
- 不依赖失败项的能力仍可通过实际诊断标记就绪
- 没有能力专属诊断时显示“依赖未验证”，不推断为就绪
3. Epic B：本机 MCP 使用一致环境
US-B1 启动 Python MCP
作为 MCP 使用者，我希望 python -m my_mcp_server 使用设置中的 Python，以免配置第二套
解释器。
验收：
- 裸
python、python3和pip解析到当前选择 - Main 直连工具链和本机 Runtime 使用相同来源
- 绝对命令路径不被替换
- MCP 自身包缺失时准确报告依赖错误
US-B2 启动 Node.js MCP
作为 MCP 使用者，我希望 node server.js 或 npx package 使用同一 Node 组合。
验收：
node、npm、npx来源一致- npm lifecycle 子进程使用当前 Node
- 取消或关闭应用后没有遗留 MCP 进程
US-B3 保持网络 MCP 不变
作为 MCP 使用者，我希望 HTTP/SSE MCP 不受本机解释器设置影响。
验收：
- HTTP/SSE 配置不显示本机解释器要求
- GoodBuddy 不管理远端 MCP 服务端依赖
- 切换工具执行环境不重建 HTTP/SSE 服务
4. Epic C：专业用户明确控制环境
US-C1 使用检测到的系统解释器
作为专业开发者，我希望从版本和绝对路径列表中选择解释器，以便使用已有工具链。
验收：
- “自定义环境”入口始终可操作，不因尚无候选而禁用
- 点击“自定义环境”只展开选择流程，不自动采用第一个候选
- 候选覆盖启动时继承的用户/系统 PATH、当前虚拟环境、Conda 环境和常见安装位置
- 候选经过真实版本和架构诊断
- 相同真实路径不重复显示
- 用户必须明确选择一个候选后才保存并切换来源
- 保存后状态显示实际生效来源
- PATH 后续变化不会自动替换选择
US-C2 指定项目虚拟环境
作为专业开发者，我希望选择未被自动发现的 Python，以便使用自己的 venv 或 Conda 环境。
验收：
- 文件选择由 Main 管理
- 没有候选时仍可从“自定义环境”流程直接打开文件选择器
- 取消文件选择不报错、不保存，也不改变当前来源
- 保存前验证 Python 3、版本和架构
- 验证失败在 Python 卡片的路径操作附近显示，并保留原设置
- GoodBuddy 不安装、升级或删除该环境
- 路径失效时不静默回退
US-C3 返回托管环境
作为专业开发者，我希望随时切回 GoodBuddy 托管环境，以便恢复标准组合。
验收：
- 切换前显示新启动进程才生效
- 新 Runtime 和 stdio MCP 使用托管来源
- 已运行进程不中途换环境
US-C4 明确设置何时生效
作为专业开发者，我希望知道环境切换何时影响进程，以免一个运行中的任务突然换解释器。
验收：
- 保存前后都说明只对新启动进程生效
- 有活动请求的 Runtime 保持启动时环境
- 空闲 Runtime 在下一次使用前按现有入口重建
- 已启动 stdio MCP 在关闭、重连或显式测试后使用新环境
- 活动记录不根据最新设置改写历史解释器来源
5. Epic D：范围和生命周期可理解
US-D1 不影响远程主机
作为远程项目用户，我希望清楚知道本机环境不会上传到 Host，以免错误预期远程脚本可用。
验收：
- “工具执行环境”Tab 显示范围说明
- 远程主机设置页显示本机 Skills 和 MCP 不适用
- Host PATH、Agent 包和 Runtime 包不包含本机选择
US-D2 删除托管 Python
作为用户，我希望删除不再使用的托管 Python，以便释放磁盘空间。
验收：
- 删除前说明受影响的本机 SKILL 和 MCP
- 只删除 GoodBuddy-owned Python 目录
- 不删除系统、自定义或工作区文件
- 使用中的进程先按现有生命周期停止
US-D3 升级后保持既有解释器
作为现有用户，我希望升级 GoodBuddy 后已有脚本仍使用原来的系统解释器。
验收：
- 首次迁移把有效系统解释器保存为自定义绝对路径
- 无有效解释器时才选择托管来源
- 迁移结果只写一次
US-D4 取消 Python 安装
作为用户，我希望可以取消耗时的 Python 安装，并在之后重试。
验收：
- 下载、校验、安装和候选诊断阶段都响应取消
- 取消后清理本次暂存
- 取消不发布未验证候选
- 页面回到操作前的未安装状态或健康旧版本
- 取消不显示为安装失败
US-D5 安全更新托管 Python
作为用户，我希望更新托管 Python 失败时仍能使用旧版本，以免现有能力全部中断。
验收：
- 下载和验证候选期间旧版继续服务已有进程
- 应用更新前说明需要停止哪些本机 Runtime/MCP
- 用户确认后才通过现有生命周期停止相关进程
- 无法停止时不替换当前版本
- 候选完整诊断成功后才发布
- 更新失败继续使用健康旧版本
US-D6 安装解释器不改变能力范围
作为用户，我希望安装 Node/Python 后仍按已启用能力运行，内部文本调用保持无工具。
验收：
- 工具环境不新增 Runtime 工具
- 命令可用性由当前 Runtime 的实际注册能力决定
- 内部文本调用不因解释器存在而获得工具
- 工具继续使用本机账号权限
6. Epic E：受限网络与离线行为明确
US-E1 通过所选官方来源安装 Python
作为内网用户，我希望在“工具执行环境”Tab 中选择原生地址或 OSS 镜像，以便符合当前 网络条件。
验收：
- 默认使用 Python 工件的固定原生地址
- 选择 OSS 后，Python 只请求固定 OSS 对象
- 页面显示本次下载冻结的来源和准确失败原因
- 同一次安装不在原生地址和 OSS 之间静默切换
- 失败保留健康旧版本或未安装状态
US-E2 完全离线时使用已有环境
作为完全离线用户，我希望清楚知道首期可用路径，以免等待一个无法完成的下载。
验收：
- 托管 Node 安装后可离线使用
- 托管 Python 未缓存且来源不可达时明确说明无法下载
- 首期不展示未实现的 Python 离线导入入口
- 用户可以选择设备上已经离线安装的自定义 Python
US-E3 所有受管工具工件遵循同一下载通道
作为用户，我希望未来新增的受管 Runtime 和工具链遵循同一个下载源选择，以免每种工具 产生不同规则。
验收：
- 受管工具目录中的每个外部工件同时声明原生地址和 OSS Target
- 两个 Target 对应相同字节数和 SHA-256
- 下载任务开始后冻结来源
- 所选来源缺少该工件时明确显示不可用
- pip/npm 依赖、模型、应用更新、Agent 和用户 URL 不受该设置影响
7. Epic F：统一管理能力与执行环境
US-F1 从一个入口管理相关能力
作为用户，我希望从一个设置入口访问 Skills、MCP 和工具执行环境，以便理解能力配置及其 本机依赖之间的关系。
验收：
- 设置中心只显示一个“能力与工具”一级分类
- 第一阶段依次显示
Skills、MCP两个水平 Tab - 工具执行环境完成后在同一组中追加第三个
工具执行环境Tab - 未完成前不显示禁用或占位的
工具执行环境 - 首次进入默认打开
Skills - 每个 Tab 使用独立、可命名的
tabpanel - 水平 Tab 支持方向键、Home、End 和可见焦点
- 窄屏时页签保持单行横向滚动，不换成多行或下拉框
US-F2 保持业务数据和编辑状态
作为现有用户，我希望合并设置导航后原有 Skills 和 MCP 配置保持不变，并且切换水平 Tab 不丢失正在编辑的信息。
验收：
- 原独立 Skills/MCP 左侧分类由一个“能力与工具”分类替代，不保留重复入口
- 合并导航不修改 Skill 启停、导入、分配或 MCP 配置、凭据和分配数据
- MCP 原有内部分组页签继续位于 MCP 面板内
- 切换三个外层 Tab 后返回时保留本次设置面板会话中的编辑状态
- 关闭并重新打开设置时，普通入口仍默认显示 Skills，不持久化上次外层 Tab
- 未来新增 Skills/MCP 定向入口时打开对应水平 Tab
US-F3 聚焦默认内置能力
作为普通用户，我希望默认只加载通用文档工具，不让低频产品营销说明占用每次会话的上下文。
验收：
- Skills 列表只把五个具备独立入口或执行器的内置能力显示为顶层 Skill
- 产品营销的九种文档配方从
product-marketing内部按需读取 deai-writing和longdoc-docx在没有保存状态时默认启用- 三个产品营销 Skill 在没有保存状态时默认停用
- 用户显式保存的启停状态和 Runtime 分配不因版本升级而重置
- 用户导入的 Skill 继续使用现有默认启用和 Runtime 分配规则