工作台开发：六步速览

版本：2026-10-08 · 详细规则见工作台开发规范；投稿见工作台市场验收规范。

1. 确认需求：从用户本次请求及已确认的上下文写明业务场景、目标用户和用户完成一次任务的核心流程。通用开发指令、目录名和现有代码不能代替用户确认；缺任一项时只问一个合并问题，等答复后再设计业务功能。
2. 检查项目：查看 pwd、目录内容、git status --short（若为 Git 仓库）、现有脚本、包管理器及 Desktop 版本；保留未提交改动。
3. 确定最小业务流程与布局：定入口、主要动作、完成状态和失败恢复；明确选择标准分栏或 customFrame，以及首次无会话时的入口。紧凑的会话伴随工具适合分栏；报表、看板和宽表格作为主任务时考虑整页布局。
4. 实现：按开发规范第 3 节制作插件包和业务面板；按第 4–7 节处理实际使用的会话、工作区和界面能力。业务区按自身容器宽度重排，不只依赖整窗断点。
5. 包校验：运行 pnpm pack；检查 .tgz 内有声明的服务端/客户端入口和 cordis.patch.yml，没有凭证或用户数据。
6. 本机安装实测：按开发规范 3.6 探测当前 Desktop 可用的本地安装方式并安装该包；完成所需重启后，从“已安装的工作台”和左侧入口打开，按第 8 节记录实际结果。无法安装时交付校验过的包，并列出未实测项。

在目标 DSH Desktop 内开发时：Agent 不要自行关闭或重启 DSH Desktop、Harness，也不要用 ps、pgrep 等进程探测来尝试管理重启。请用户完整退出并重新打开 DSH Desktop；用户回来确认已重开后，再做加载与界面验收。在此之前将这些项目标为待验证。应用外的 Agent 按正常重启流程操作。

界面验收：分别检查首次无会话、已关联会话、侧栏展开/收起及较窄窗口。标准分栏要看宿主通用引导与业务面板并列时是否可用；customFrame 要提供自己的首次使用入口。用真实长度的中英文内容检查，不能出现单字竖排、控件裁切或整页横向溢出；保留宿主公共入口。

空目录示例：用户只粘贴 Desktop 的通用开发指令，目录为空，也没有业务目标。Agent 下一步是一个合并问题：“这个工作台要服务谁、解决什么业务场景？用户从进入到完成任务的核心步骤是什么？”等待答复时可运行 pwd、ls、git status 或探测 Desktop 版本；答复前不得创建 package.json、业务代码或界面，也不得构建、安装或投稿。