@fooksky/lodestar 0.0.0-stage → 0.2.0

package/docs/proposal.md

@@ -0,0 +1,129 @@
+# DSH 原生开发工作流提案
+
+日期：2026-11-06
+状态：讨论稿 v0.4；明确独立 intent、人的需求与方案审核、轻量材料边界。
+项目暂名：dsh-dev-workflow。
+
+## 提案的范围
+
+本提案说明工作流应做什么、经过哪些节点、人与 AI 如何参与，以及需要保存哪些材料。它是整体框架和执行流程，不是完整实现设计。
+
+具体字段、schema、状态枚举、工具 API、存储算法和校验脚本留到实现需要时再确定，不作为提案完成的前置条件。当前仍在设计讨论，尚未开始插件实现。
+
+## 目标与边界
+
+- 独立仓库、独立发布，面向 DSH 原生实现，充分复用 Agent Teams。
+- 覆盖从真实需求识别、方案设计到实施验证的完整过程，支持增量开发和新项目 MVP。
+- 人主要参与意图识别和框架方案设计；AI 负责调查、整理、实施规划、执行与验证。
+- 需求与方案必须经过人的判断，不能仅因 AI 认为信息充分就直接进入实施。
+- 文档和知识体系保持轻量；按需读取，避免重复记录、重复探索和无限验证。
+- 验证按任务需要配置。BrowserSkill 可选且可替换，不是必需依赖。
+- 本版交付到经过验证的开发结果与说明，不包含自动提交、推送、发布。插件自身的分发方式另行考虑。
+
+现有 Nuclio 的轻量工作流与知识组织值得保留；本项目主要解决 DSH 原生协作适配、流程边界与上下文效率问题，不以增加治理层和文档层为目标。[LabWarden 案例](research/labwarden-session-cost.md)说明，大截图矩阵、重复读取和无效压缩可能放大成本；工作流优化需观察整个团队，而非只减少主会话的 compact。
+
+## 主链路与人的参与
+
+```text
+用户提出需求（可以只有一句话）
+    ↓
+意图识别与澄清 ↔ 用户补充背景、纠正理解
+    ↓
+形成 intent：真实需求由用户确认
+    ↓
+方案与 spec 设计 ↔ 用户评审框架方案、关键取舍
+    ↓
+用户确认：这个方案符合预期，可以据此实施
+    ↓
+生成 plan
+    ↓
+执行 plan ↔ 验证与局部返修
+    ↓
+交付结果与必要知识整理
+```
+
+意图确认与方案审核是明确的人参与节点。简单需求可以在一次交流中一起确认，复杂需求可以分别往返讨论；不机械要求固定轮数，但不能省去用户判断。用户已明确确认相同需求与方案时，直接沿用，不因阶段切换或恢复再审批一次。
+
+方案审核前，AI 应完成必要调查并形成可评审的具体方案。审核要让用户能判断预期结果、影响范围、整体实现思路及重要取舍，而不是只问“是否继续”。用户拥有模型未必掌握的业务背景、外部约束和经验，这次审核本身具有价值，不只是权限检查。
+
+plan 负责落实已确认方案，默认由 AI 生成和执行，不另设固定人工审批。不能把应由人评审的框架选择藏到 plan 中。阶段名称也不等于宿主 Plan Mode。
+
+## intent、spec、plan 的分工
+
+| 材料 | 回答的问题 | 应保存的内容层次 |
+|---|---|---|
+| `intent.md` | 用户真正需要什么，为什么？ | 原始诉求、经澄清的真实需求、背景与目标、范围和重要约束 |
+| `spec.md` | 用什么方案实现 intent，结果应是什么样？ | 可供人审核的框架方案、关键取舍、预期行为和必要验收要求 |
+| `plan.md` | 如何把已确认方案做出来并验证？ | 实施步骤、工作分工、必要依赖和验证安排 |
+
+intent 独立保存，不能只作为 spec 中顺带描述的目标段落。它不是机械复述用户原话，也不能把 AI 的推测直接当成真实需求。意图识别结合定向调查和与用户沟通，发现一句话背后的场景与诉求，并由用户校正。
+
+例如，“不要再让我填 ID”可能表达的是“让我能可靠找到并选中目标对象”。intent 保存这个需求；spec 决定名称检索、同名区分和稳定 ID 绑定等解决方式；plan 决定相关接口、控件与验证如何实施。方案可以变化，需求仍能独立回看。
+
+三份材料按任务规模写，简单任务每份可以只有几行，不设置篇幅、章节数量或字段填满要求。spec 不复制 intent 全文，plan 不复制 spec；已有项目知识以引用为主。人的确认和关键决定就近简记，不新增审批表、决策账本或每阶段报告。
+
+## 四类必需场景
+
+| 场景 | 流程要求 |
+|---|---|
+| 增量需求，一次依次完成 | 澄清并确认 intent，设计并审核方案，AI 生成 plan 后实施验证 |
+| 实施验证后发现意图不足 | 回到 intent，与用户重新对齐真实需求，修正方案；新的需求/方案决定明确后继续受影响工作 |
+| 意图、方案或 plan 多次变化，实施可能循环 | 允许往返，按问题所在层调整；保留仍有效的成果，避免每轮全量重走 |
+| 新项目初始化 MVP | 与用户明确最小用户闭环和非目标，审核框架方案；按可运行的功能切片实施，直到核心流程得到验证 |
+
+新项目不建立第二套工作流。先跑通一条真实用户流程，再完善 MVP 必需能力；脚手架、构建成功和演示数据不等于 MVP 完成。增量需求则复用现有结构和知识，保护已有无关改动，不强制新建分支或清空工作区。
+
+## 调整与回退
+
+| 问题 | 调整方式 | 人是否参与 |
+|---|---|---|
+| 实现不符合已确认 spec | 局部修代码并验证 | AI 自主返修 |
+| 实施顺序、分工或技术细节不合适 | 调整 plan | AI 自主处理，不改变已确认方案 |
+| 框架方案不可行或重要取舍需要变化 | 修订 spec，说明差异与影响 | 用户审核改变的方案 |
+| 结果符合 spec，却没有满足真实需求 | 重新澄清 intent，再修订 spec/plan | 用户参与需求和方案对齐 |
+| 用户提出新的独立需求 | 明确当前工作与新增工作的边界 | 用户确认需求/方案，不悄悄扩展范围 |
+| 验证工具或环境出问题 | 排查环境或选择能证明同一结果的方式 | 通常由 AI 处理；确需用户提供条件时说明缺口 |
+
+用户的直接纠正若已把需求与方案说清楚，应作为当前决定使用，不再原样询问。发生变化时只评审必要差异，不重新审批整个历史。
+
+一般执行不依赖用户逐步监督。用户仍可随时提供反馈；涉及额外权限、外部副作用等特殊情况沿用宿主与用户已有授权规则，不另造权限系统。
+
+## 验证、收敛与恢复
+
+- plan 包含与改动相称的验证安排；实施过程中就近验证，最后做必要集成检查。验证同时对照 spec 和 intent，避免实现正确却需求错误。
+- 项目已有静态检查、测试、构建、API/CLI 或浏览器工具按需选择。替代方式应证明同一结果，不能用编译成功替代交互通过。
+- 留下简短验证结果和必要原始依据引用；工具成功不等于业务通过，截图生成不等于实际查看，fixture 不等于真实集成。
+- 返修后重验受影响部分及必要回归。未变化、仍适用的结果继续使用；compact 或任务重排不自动触发全部重验。
+- 同一问题反复失败时，先改变诊断或执行方法，不能靠原样重试、反复读图、不断创建代理消耗上下文。预算用于提醒调整方法，不用于降低验收标准。
+- 已满足确认的需求与规格、必需验证通过且没有未解决阻断，就结束当前交付。新增想法不自动扩大当前范围。
+- 恢复读取当前 intent、spec、plan、必要进度及验证结果，核对实际产物后继续。无需重演完整对话或重读全部材料。
+
+具体如何标识版本、判定证据失效和存储恢复状态，在实现时选择足够简单的办法；提案不预设完整证据管理系统。
+
+## 轻量知识与材料保存
+
+单次工作的主要材料是 intent、spec、plan。另保留足够继续工作的简短进度、验证结论及引用，可附于现有材料或使用原生记录，不规定额外成套文档。完整日志与大截图不搬进这些文件。
+
+项目长期知识与单次需求分开，沿用轻量组织原则：
+
+- 一个简短入口，指向少量实际有用的项目知识；不预建复杂分类和空目录。
+- 按当前问题读取相关部分，不要求每个阶段遍历整套知识。
+- 复用已有 README、架构和运行说明，不平行维护同内容副本。
+- 完成工作时只更新真正改变的稳定事实和已失效说明；无新知识就不制造总结文档。
+- 临时假设、调试过程和任务进度不沉淀为长期知识。
+
+提案确定这些内容需要保存，但不展开完整目录模板、字段规范、数据库设计或强制归档流程。优先使用人可读的项目文件；原生会话和任务记录已有的信息尽量引用。具体位置在实现时以易读、易恢复、少重复为准。
+
+## DSH 原生协作边界
+
+Lead 负责与用户对齐 intent/方案、组织实施、集成和交付。复杂任务使用 Agent Teams；有界独立调查可用 subagent；小任务直接完成，不固定角色数量。
+
+Team 承担任务、依赖和成员状态；plan 保留实施思路和任务引用，不复制第二张可写任务板。共享写入明确归属与交接。成员停止活动、任务完成和交付通过是不同事实，不能相互替代。
+
+复用 DSH 已有调度、权限、压缩与界面能力；不重做 DAG、任务引擎、压缩引擎或浏览器引擎。细节按阶段加载，大输出保留引用和有界片段。具体宿主 API 在实现前核对，不假设跨会话原成员一定可恢复。
+
+## 首版评估与后续工作
+
+用四类场景评估：需求是否识别正确、方案是否经过人审核、AI 能否按方案自主完成、返修是否局部收敛、新项目是否真正可用。结合中断恢复、可选浏览器和原生协作，观察漏验、重复劳动、Lead 与成员总成本及交付成功率，不单看 compact 次数。
+
+流程层面以本提案为准。接下来可检查是否还有缺失的必需节点，再进入最小实现设计；不必先把所有字段、边界和恢复协议讨论完。早期详细[行为合同草稿](workflow-contract.md)仅作为历史设计参考，其中弱化方案人工审核、合并 intent 的内容已被本提案取代，不作为首版必读文档或实施清单。

package/docs/research/agent-presets.md

@@ -0,0 +1,99 @@
+# 是否需要预设 Agent
+
+日期：2026-11-07。调查基线：本机 DSH 0.2.2-rc.1 的安装代码和本会话工具 schema。结论来自静态接口及调用链核对，没有创建测试成员、修改 profile 或安装插件。
+
+## 结论
+
+本文结论针对“按成员角色分别预设 Agent”：首版应提供可复用的角色指引，不为每个角色注册一个 DSH Agent preset。将整套开发流程组合为一个可选模式，是另一层设计，见[开发模式调查](development-mode.md)。Lead 继续使用用户当前 Agent，按任务需要选用 implementer、reviewer、verifier 三种职责，将对应指引和具体任务一起交给原生 subagent 或 Team 成员。角色不是必经阶段，不要求每次启动三个成员。
+
+这里区分三件事：
+
+- 角色指引：工作职责、输入、边界、完成标准和结果格式。
+- 原生 Agent preset：由 Cordis 子插件组成的能力配置，可能改变工具和服务。
+- 模型路由：provider/model/reasoning effort 等选择；不是给成员起角色名就会改变。
+
+首版的实际需求主要是稳定分工和交付质量，角色指引已足够。若未来确实需要不同的工具集、权限或上下文能力，再增加原生 preset；不能把“只读 reviewer”提示词描述为权限隔离。
+
+## 宿主证据
+
+安装代码根目录为 `/home/fooksky/.local/share/fnm/node-versions/v26.13.0/installation/lib/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/`。以下路径以该目录为基准，方便在其他安装位置重复调查。
+
+| 证据位置 | 已核对事实 | 设计影响 |
+|---|---|---|
+| dsh-agent-preset-registry/lib/types/definition.d.ts:4 | PresetDefinition 是 id/name/description/order/plugins | 原生 preset 是能力组合，不只是角色提示词 |
+| dsh-agent-preset-registry/lib/types/index.d.ts:52 | register 返回异步 disposer | 自建 preset 需要管理注册及生命周期 |
+| 同文件:99–132 | mount、composeFrom、select；子 Agent 可继承父 preset 的确切 revision；select 仅适用于首轮前 | 不能在正在运行的成员上随意切换角色 preset |
+| dsh-experimental-tool-agent-team/lib/index.js:251–289 | spawn_teammate 参数仅 name/description/prompt/context；fresh/fork provider 来自工具配置 | 当前公开 Team 工具无法逐成员指定 preset 或模型 |
+| dsh-experimental-agent-team/lib/index.js:1035–1045 | 成员 activation 传 provider、prompt、parent，没有逐成员 agentPreset | 不能只在技能里写一个 preset 名就认为 Team 会选用它 |
+| dsh-tool-subagent/lib/index.js:243–281 | agentPreset/allowedAgentPresets 配置；按 allowlist 暴露 agent_preset；provider 必须支持独立 preset 且不继承上下文 | fresh subagent 可有条件支持；不能无条件套用于 fork |
+| 本会话 subagent schema | 有 provider/model/reasoning_effort，没有 agent_preset | 当前会话不能直接测试按 preset 委派 |
+
+这些发现不代表宿主永远不支持 Team preset，只代表当前公开链路没有该选择入口。为首版改造 Team 或绕过原生工具创建成员，会扩大范围并引入第二条执行路径。
+
+## 角色设计
+
+### Lead：当前会话承担
+
+负责真实需求、方案取舍、用户确认、主文档、状态更新、任务拆分、整合与交付。不能把语义决策和授权判定委托给一个自动推进的角色。Lead 不需要新增 preset，已有 dev-workflow skill 提供流程规则。
+
+### implementer：实现或修复工作包
+
+输入：具体任务、已批准范围、相关 spec/plan 段落、验收 ID、允许写入的范围和必要上下文。
+
+职责：完成有界实现及与之相关的检查，报告修改与证据；发现范围或方案不成立时停止受影响工作并报告，不自行扩大需求。
+
+输出：完成情况、修改路径、相关验收、已执行验证及结果、未验证项、阻断。不能代替 Lead 更新主材料或登记用户授权。
+
+小任务由 Lead 自己实现；只有可独立交付或并行收益明确时才委派。按文件/模块工作包分工，不固定前端、后端、数据库等常驻岗位。
+
+### reviewer：独立审查
+
+输入：需要回答的审查问题、明确差异或方案范围、相关验收、必要上下文。
+
+职责：发现可说明触发条件和影响的实质问题，优先正确性、契约不一致、集成遗漏与需求偏差。没有问题时直接说明，不为凑数给风格建议。
+
+输出：结论；每个问题的具体位置、触发条件、影响、依据及必要修正方向；未覆盖边界。默认不修改文件，修复另行明确分派。
+
+在跨模块契约变化、重要迁移、复杂并发或容易自证的变更中使用。低风险局部修改不要求独立审查；不固定多评审轮数。fresh 上下文适合独立判断，但仍需提供足够约束，不能靠上下文缺失制造“独立”。
+
+### verifier：验证与证据收集
+
+输入：验收 ID 与对应行为、被测对象、环境、验证方法、现有证据及缺口。
+
+职责：实际检查验收命题，区分通过、失败和无法验证。浏览器、CLI、测试工具按当前可用能力选择；缺环境报告阻断，不生成假证据。默认不改产品代码，避免边修边验掩盖测试对象变化。
+
+输出：每项验收的观察、方法、被测版本/产物、环境、证据位置、未覆盖项及失败复现。结果是给 Lead 的证据报告，最终验收状态仍由 Lead 登记。
+
+复杂 UI、外部集成或需要独立端到端检查时单独委派。简单任务由实现者或 Lead 验证。批量视觉检查按有界工作包分配，保持完整覆盖并避免重复读图。
+
+## 指引的装配方式
+
+新增一份按需读取的 skill 参考 `references/delegation.md`，包含三段角色契约和一个委派模板，不增加三个独立 skill 或三套全量系统提示。
+
+Lead 发送的实际 prompt 必须自足，包含：
+
+1. 角色职责及本次具体问题/目标。
+2. projectRoot、changeId、任务 ID（Team 场景）、相关 A/P 编号及关键材料版本。
+3. 必要资料位置和足以开工的摘要；fresh 成员不能只收到“按上文做”。
+4. 允许写入范围、禁止触碰的主材料、依赖和已知并行成员。
+5. 验证要求、停止/反馈条件、结果格式。
+
+不要求成员读取整个技能或全量历史。角色规则写入成员任务提示；会改变的长说明通过明确路径引用。主流程规则只由 Lead 持有，避免子成员再次发起完整需求确认或重复组织 Team。
+
+需要持续交流、任务领取和多轮修复时使用 Teams；一次性调查或审查用普通 subagent；需要继承历史时才 fork。成员命名描述当前工作，如 storage-impl、api-review，而不是预建固定组织架构。
+
+模型选择继续使用宿主现有配置。首版不指定模型厂商或固定“高级 reviewer/低价 implementer”映射。角色质量应通过真实结果和成本评价，不能从模型名称推定。
+
+## 何时再引入原生 preset
+
+出现以下实际需求时再单独设计：验证角色需稳定的浏览器能力组合；审查角色需宿主可执行的只读限制；某个专用工具集过大，需要隔离以降低上下文成本。
+
+届时先核对可用 provider 的能力及宿主选择入口，决定是否只用于 fresh subagent；若必须用于 Team，则先扩展宿主公开契约。不能在本插件中另写成员管理器补洞。工具不暴露并不自动等于只读：shell、连接器等也可能写入，真正权限必须由宿主策略保证。
+
+原生 preset 的分发是可选独立配置，不改变用户默认 preset、不自动切换已有会话、不在安装时静默替换工具组。
+
+## 验收与取舍
+
+在原有四类提案场景中检查：小任务不强制委派；fresh 成员可凭任务包开工；reviewer 指出可复现的实质问题或明确无发现；verifier 区分已观察和推测；成员不写主状态；修复后只重验受影响项。
+
+比较直接执行和按需角色委派的缺陷发现、验收完成、重复读取和总成本。在没有实际收益证据前，不追加 researcher、architect、planner、knowledge-writer 等常驻角色。

package/docs/research/development-mode.md

@@ -0,0 +1,98 @@
+# 用 Agent preset 提供专门开发模式
+
+日期：2026-11-07。基线：本机 DSH 0.2.2-rc.1。范围：静态接口及安装代码调查，未注册 preset、修改 profile、启动新会话或实际验证 GUI。
+
+## 判断
+
+可行，而且比为 implementer/reviewer/verifier 分别创建 preset 更有价值。建议提供一个可选的 `dev-workflow` 开发模式：新会话选择后，获得开发流程入口、状态工具和经过验证的原生开发能力组合。核心 skill/状态工具仍可在其他兼容模式中单独使用。
+
+两层分工：工作流核心定义行为和状态契约，preset 定义入口和能力组合。模式不复制工作流规则，不增加执行引擎，不意味着开启更高权限或自动获得实施授权。
+
+建议将开发模式作为首版可选交付项，排在核心功能之后；先完成最小组合与宿主验证，再扩展可选集成。此处是设计建议，不代表用户已授权安装或修改默认模式。
+
+## 可行性证据
+
+代码根目录：`/home/fooksky/.local/share/fnm/node-versions/v26.13.0/installation/lib/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/`。下列位置均相对该根目录。
+
+| 位置 | 观察 | 影响 |
+|---|---|---|
+| dsh-agent-preset-registry/lib/types/definition.d.ts:4 | preset 有 id/name/description/order/plugins | 可声明一个具名开发能力组合；无直接 extends 字段 |
+| dsh-agent-preset-registry/lib/types/index.d.ts:52 | register(definition) 返回 disposer | 插件可声明模式并管理生命周期 |
+| dsh-agent-preset-registry/lib/index.js:219 | 子配置在 preset scope 加载，检查 failed rows 和 service leaks | 不能将整套 Host 服务随意嵌入模式 |
+| 同文件:717 | composeFrom 继承父 Agent 保留的确切 preset revision | 子 Agent 可沿用开发模式；具体 provider 路径仍需集成验证 |
+| 同文件:766 | 已有首轮或正在首轮的会话拒绝 select | 这是新会话模式，不是运行中切换工作流阶段的开关 |
+| dsh-client-ui-agent-preset/lib/client.js:2993–3082 | select 入口、新会话模式入口、会话标签与设置注册 | 可以复用现有 UI，无需添加自定义页面 |
+| dsh-system-prompt/lib/types/index.d.ts:47 | 支持带 scope 的 prompt section；complete section 会替代其他正文 | 可添加简短模式入口，不能用 complete 覆盖原生系统规则 |
+| dsh-tools/lib/types/index.d.ts:43–58 | scoped 工具可覆盖全局工具；restrict 限制继承工具 | preset 不是自动清空全局工具的独立容器 |
+| dsh-experimental-agent-team-profile/cordis.patch.yml:4–29 | 官方 Team profile 层关闭普通 subagent/control，并安装 Team 工具与 UI | 不能直接套用该 patch 后仍宣称两种委派同时可用 |
+
+注册 preset 不等于安装它引用的包，不保证 Browser/MCP 已登录，也不保证 Team 宿主服务存在。模式能力必须以实际组合检查为准。profile 策略可以禁用某些配置行，因此 registry 没有 broken 也不足以证明所有业务必需工具都存在。
+
+## 有价值的部分
+
+1. 用户在新会话中直接选择“开发工作流”，不用记 skill 名或每次说明流程。
+2. 明确并验证一套可复现的最低能力组合，降低“技能在、状态工具不在”或缺恢复工具的配置问题。
+3. 常驻提示只负责路由，阶段细则按需读取，避免每次委派和每轮对话注入完整流程。
+4. 可以清楚区分开发会话与一般问答；相关模式说明和配置在原生界面中可见。
+5. 团队部署可复用同一声明和兼容基线，出问题时能定位能力组合。
+
+仅新增名称和完整提示词副本，收益很低。减少 token、提高成功率、减少人工操作是待验证目标，不能从“有 preset”直接推出。已经熟练手动使用 skill 的单用户，新增价值主要在启动便利和配置一致性。
+
+## 推荐组合
+
+| 层次 | 内容 | 放置及约束 |
+|---|---|---|
+| 宿主基础 | 会话、模型连接、权限、文件 backend、工作目录、子 Agent provider、必要 Team 服务 | 复用部署；不在 preset 内重建全局服务 |
+| 模式必需 | dev-workflow skill、状态工具、短入口提示 | 从同一核心模块复用；避免全局与 scoped 重复注册同名贡献 |
+| 开发必需 | 文件读写/搜索、shell、job 查询、skill 加载、用户交互、历史查询和原生协作 | 核对实际工具和依赖；不只看包安装成功 |
+| 按需能力 | 图像/浏览器、联网搜索、worktree、goal、长期记忆、连接器 | 可用时按任务使用；不让不可用的可选项阻塞模式加载 |
+| 用户配置 | provider/model、权限、账号和密钥、默认模式 | 继续由宿主管理，不硬编码或自动变更 |
+
+首个受支持的部署组合以原生 Team 协作为基础，同时允许 Lead 直接执行小任务；只有部署确实同时提供普通 subagent 时才使用一次性委派。核心 skill 在无 Team 的模式中仍可按已有直接执行路径工作，但不把缺少 Team 的安装冒充已验证的完整开发模式。
+
+不直接复制整份 dsh-base patch，也不在运行时抓取用户 Standard preset 并私自修改。当前不存在已核对的“一行 extends standard”契约。应维护显式且有界的模式声明，复用宿主可见的能力，仅补入模式贡献；若某项必须实例化在 preset 内，使用公开插件配置及正确 isolate。该组合针对受支持宿主版本验证，不能声称跨任意 profile 即插即用。
+
+第一版不做通用组合生成器或动态依赖安装器。不为了所谓精简盲目屏蔽用户工具。确需限制时通过原生 scoped restrict，并测试目标实际工具视图；不要把少列几个 plugins 当成全局工具已经不可见。
+
+## 模式启动行为
+
+入口提示是短 section，不复制阶段规则，建议表达：
+
+> 本会话采用开发工作流。处理开发变更时先加载 dev-workflow，定位或创建 change，并按当前阶段继续。用户只要求调查、解释或设计时按该范围工作；选择本模式不构成实施、提交、发布或安装授权。受委派成员执行任务包中的角色职责，向 Lead 回报，不重新启动完整需求确认流程。
+
+Lead 负责主流程；继承模式的成员不自动成为新的 Lead。角色指引继续按需注入，不另建三个 preset。
+
+首次开始开发工作时检查一次必需能力，缺失时指出具体配置问题；阶段进入需要的可选能力时再检查该项。不要每轮重复完整探测。模式注册和选择本身不创建 change、不扫描项目、不启动成员、不生成计划。
+
+继续已有 change 时显式路径/ID优先，由 skill 恢复；preset 不保存全局 currentChange。已有非开发会话不能热切模式，但可在工具可用时直接调用核心 skill；需要开发模式完整组合时从新会话进入并恢复 change。
+
+## 发布和生命周期
+
+代码保持核心和模式适配入口分离，可以同仓库交付；不因此先拆成多个 npm 包。最终包声明应让模式适配入口可被显式配置，核心本身不依赖用户选中该模式。具体 export/patch 行在实现时对实际 profile 组合验证。
+
+preset 只是配置，所需模块必须已经安装。普通 bundle 安装影响 profile，preset 选择影响新会话，两者不可混同。安装后可以出现一个新选择项，但不自动设为默认、不切换已有会话、不启用更宽权限。
+
+Registry 会为运行中的 Agent 保留所用 preset revision；新声明与旧会话可能同时存在。插件不得假定更新定义会立刻更新全部现有会话。跨进程重启是否能恢复旧依赖组合不能仅由这个内存 revision 机制推断，需实际测试并说明版本兼容范围。
+
+卸载/停用清理自己的注册，运行中 revision 的保留与释放服从宿主机制；不强行清空其他模式或工具。状态材料仍保存在项目中，不绑定某个 UI 选择或 preset 生命周期。
+
+## 成本和验收
+
+主要成本是维护受支持版本的能力清单、scoped 注册、服务隔离、子 Agent 继承行为，以及与用户 profile 的组合兼容；状态和流程本身不应产生第二份实现。
+
+最小验证范围：
+
+- 新会话可见并可选“开发工作流”，普通模式和默认设置不被修改。
+- 开发模式实际工具视图完整，没有重复注册或泄漏服务。
+- 选择模式后，开发请求进入 skill；问答/调查不被强行转换为 change。
+- 用户“只设计”仍止于设计；角色成员不重复启动主流程。
+- Team 成员和可用的 subagent 路径获得预期能力，跨会话目录与状态不串用。
+- 运行中切换被宿主拒绝；新会话可以恢复已有 change。
+- 可选浏览器缺失不阻止普通开发，真实 UI 验收需要浏览器时明确报告阻断。
+- 升级、停用与重新启动的行为符合实际宿主保证，项目状态不丢失。
+
+四类提案场景分别比较“普通模式手动调用 skill”和“开发模式”，记录是否漏加载流程、缺工具、重复读入和反复确认，以及可得总成本。先证明入口与组合可靠，再讨论进一步裁剪工具或固定模型。
+
+## 建议决策
+
+保留已确认的三类角色指引；增加一个可选的整套开发模式作为产品入口。先实现并验证核心，再验证模式组合；不为成员分别注册 preset，也不修改宿主 Team 来支持逐成员选型。本轮只更新设计，实施和本地安装按各自授权范围推进。

package/docs/research/labwarden-session-cost.md

@@ -0,0 +1,91 @@
+# LabWarden 最新会话成本案例
+
+分析日期：2026-11-06。只读检查本地会话日志，没有修改 LabWarden、DSH 配置或历史记录。用于工作流设计讨论，不是运行时根因修复报告。
+
+## 样本与方法
+
+根会话：`session-dc96f7d2-1a18-4ba1-8b35-170c06e26a43`，工作区 `/home/fooksky/projects/fooksky/labwarden`。按日志创建/末事件时间确定最新根会话，而非按压缩文件 mtime（存在近期被迁移的旧日志）。
+
+根会话创建于北京时间 2026-11-06 17:19:21，样本末事件 21:45:28；首个实际用户请求约 17:35。共检查根会话及 17 个直属子会话，使用各自 v4 事件，不把旧格式副本、内嵌消息和 stream 重复计算。统计是读取时快照。
+
+原始日志位于 `~/.dsh/sessions/--home-fooksky-projects-fooksky-labwarden--/<session-id>/session.v4.jsonl.zstd`。本地分析脚本与有界投影在 `/tmp/labwarden-session-audit/`；截图子任务独立核对材料在 `/tmp/labwarden-browser-audit/`。临时材料不作为持久依赖；复核可按本文 ID 和 seq 定位原始日志。
+
+用户最初要求 BrowserSkill 逐页检查多余文案、下拉样式、系统信息；后续显式调用 Nuclio 修复。因此这个样本包含探索、方案、实现、验证和收尾，不是单纯浏览器验收耗时。
+
+## 统计结果
+
+| 范围 | step/end | 压缩尝试 | 成功产生摘要 |
+|---|---:|---:|---:|
+| 根会话 | 268 | 60 | 43 |
+| before 图片审查 d063e88d… | 44 | 61 | 51 |
+| after 图片审查 418bc6ef… | 43 | 50 | 43 |
+| 验证资产子任务 243b4d16… | 60 | 32 | 20 |
+| 子任务 21e16e2a… | 47 | 2 | 2 |
+| 其他直属子会话 | — | 0 | 0 |
+| 合计 | — | 205 | 159 |
+
+成功摘要由 compaction/summary 计数；不能把 205 次 start 全部称为成功 compact。
+
+记录到的 assistant/message usage.totalTokens 合计 46,454,391；成功压缩摘要 usage.totalTokens 合计 5,104,188；两者合计 **51,558,579**。其中 cacheReadTokens 为 **36,757,504**，inputTokens 为 14,235,668，outputTokens 为 565,407。
+
+这是逐次请求累计处理量，含反复送入模型的缓存上下文，不是唯一内容量，也不是等价收费 token。未包括没有 usage 的失败尝试、title 等其他调用，不能当成完整账单。
+
+主会话 compaction start/end 配对区间累计约 94.5 分钟，含失败尝试；不是净可节省时间。子任务并行，不能将各会话时长相加冒充用户等待时长。
+
+## 最明确的浪费：图片卸载后反复重读
+
+两个专门的图片审查任务分别持续约 59.2 分钟和 37.4 分钟。各有 72 张图片（24 场景 × 3 视口），工具调用如下：
+
+| 项目 | before | after |
+|---|---:|---:|
+| read_image 调用 | 302 | 216 |
+| 唯一图片 | 72 | 72 |
+| 重复读取 | 230 | 144 |
+| IMAGE_OFFLOAD_REQUIRED 尝试 | 26 | 17 |
+| 压缩失败 | 10 | 7 |
+
+518 次读取中 374 次为同一任务内重复读取，占 **72.2%**。这两个任务没有浏览器操作，不能把该部分耗时归因于浏览器点击或 DOM 工具。
+
+两者 assistant usage 加成功压缩 usage 合计 14,445,766，约占本样本已统计处理量的 **28.0%**。before 任务最终只确认 42/72 张实际预览，另外 30 张受图像传递限制；after 报告 72/72 通过。工具成功不等于图片实际可见，覆盖数字也必须区分工具调用与模型确认。
+
+可复核事件：
+
+- 根会话 seq1706、1723：分别委派 before/after 全量 72 张视觉审查，强制每张通过 read_image 实际查看。
+- before seq25/208/457/691/965：同一桌面 dashboard 图片重复读取五次。
+- before seq160/161：图片超预算及卸载。
+- before seq244/245：压缩失败，摘要 778 tokens 不小于被压缩内容 345 tokens。
+- before seq1108：最终仅确认 42/72 预览。
+- after seq856：报告全量通过，未报告新的视觉阻断。
+
+before 发现的窄屏裁切和标签越界主要是已知基线问题；after 主要说明 fixture 的覆盖局限。现有证据不支持把这段漫长审查解释为持续发现真实新缺陷。
+
+## 压缩失败具有重复性
+
+根会话 17 次失败全部是摘要不比原文短。例如 seq1799/1807/1814/1821，对约 4917 framed tokens 的内容反复生成不少于原内容的摘要；这不是有效减少上下文。
+
+两个截图任务的 17 次压缩失败中，16 次也是摘要不够短，1 次为 HTTP/2 流失败。图片预算、文本压缩阈值和固定提示成本是不同问题，不能预设多做文本摘要就能解决图片传递。
+
+已确认事件模式；尚未审计 DSH 压缩重试调度、图片预算实现或完整请求计量逻辑，因此不将其归因于某一个确定的运行时 bug。
+
+## 为什么验证矩阵会膨胀
+
+项目当前 `.dev-docs/knowledge/browser-validation.md` 要求：
+
+- UI 变更覆盖所有适用场景，布局/导航变化增加窄屏，有中间断点增加第三视口。
+- 每个适用场景保留 before/after 同场景截图。
+- 每张截图必须实际查看。
+
+这解释了大量截图的制度来源。它也明确只覆盖与变更有关的状态、允许不适用说明，不能简单说项目要求无条件全站全状态笛卡尔积。当前文件不等价于原始历史版本，但根会话委派本身确认了本次 72+72 张全量实际查看要求。
+
+Nuclio 流程成本、项目验证规范、模型的分包/重读策略和 DSH 图片/压缩机制共同参与；本样本不能把所有成本都归到 BrowserSkill 或 Nuclio 单方。
+
+## 对新工作流的设计建议（待讨论）
+
+1. **验证矩阵先收敛。** 按变更及验收命题选择场景，行为检查尽量用确定性断言；视觉检查针对真实布局风险。全量图片实际查看若确有要求，按小包完成，不能静默降级抽样。
+2. **小包前后对照。** 按页面/场景组织少量 before/after 配对，立即记录已查看证据与发现。不要把全部 before 和全部 after 分别塞进两个长会话；恢复只补未完成或失效项。
+3. **已检查证据可复用。** 记录图片身份/内容指纹、场景、视口、产物版本、检查结论；compact 不使已成立的证据自动失效。图片改变或结论缺乏实际观察依据时才重看。
+4. **工具与上下文失败不能伪装成产品失败。** 图片无法传递时调整批量或报告无法验证；摘要不能缩小时诊断/改变处理策略，避免继续做同样的无效尝试。具体机制需核对 DSH 能力。
+5. **完成条件明确。** 必需验收均有当前有效证据、无未解决阻断即可收尾；每次扩大或重跑验证须有新改动、新失败或未决问题依据。
+6. **同时衡量质量和成本。** 记录重复读取率、有效证据增量、成功/失败压缩、总 token 含缓存拆分、耗时及漏检，不能只追求主会话少 compact。
+
+新插件的知识设计需要保存的是“什么已经证实、针对哪个版本、什么尚未完成”，而非把所有截图内容和工具历史重新写成摘要。证据索引因此比冗长恢复叙事更有价值。

package/docs/research/workflow-survey.md

@@ -0,0 +1,136 @@
+# 开发工作流调研与下一轮设计议题
+
+调研日期：2026-11-06。状态：研究输入与设计建议，尚未批准为实现规范。
+
+## 方法与证据边界
+
+通过公开搜索发现候选，并读取下列项目官方仓库 README；对 OpenSpec、GSD Core、oh-my-deepseek-harness 追加读取概念/上下文/Team 合同。未安装或实际运行这些项目，未做完整代码审计。文档声明证明其设计意图，不证明可靠性或性能。来源跟随 main，会变化；本次没有锁定 commit，因此不是可重复性能基准。
+
+通用项目是否支持 DSH 不能凭通用 skills 格式推断。本次明确查到 DSH 专用项目两个；不声称穷尽生态。
+
+## 项目对比
+
+| 项目 | 已查到的设计 | 值得吸收 | 不直接照搬 |
+|---|---|---|---|
+| OpenSpec | 当前规格与 changes 分离；proposal/spec delta/design/tasks；归档合并规格增量；允许迭代 | 稳定知识与本次变化分离，明确增删改和收敛时机 | 每个小任务都生成整套文档；规格声称的行为不等于代码实际行为 |
+| GitHub Spec Kit | 规格驱动流程；bug fixing、idea assessment 独立入口；模板、preset、extension 等机制 | 按任务目的选择过程，需求与计划分离，项目约定可复用 | 完整移植其扩展生态或按旧印象描述为只有单一固定流水线 |
+| GSD Core | Discuss/Plan/Execute/Verify/Ship；fresh-context agents；STATE/CONTEXT 等跨会话材料 | 有界工作包，精简协调上下文，决策/研究/计划分工，恢复材料 | Lead 永不读源代码、每次工作都新建代理，以及文档中固定 200k 窗口假设 |
+| Superpowers | 可组合技能；设计讨论、实施计划、subagent-driven development、测试与审查 | 任务要可独立理解与验收，审查/验证参与实施闭环 | 所有任务一律走完整设计审批和强制 TDD；大量默认加载说明 |
+| oh-my-deepseek-harness | 专门映射 DSH goal、原生 Team、任务板、消息和恢复；能力矩阵；Team 任务板唯一执行台账 | Team 真正作为执行面，CAS、write scope、依赖就绪不唤醒、inactive 不等于完成 | 默认强制组队、固定双评审、固定降级阶梯、常驻大技能矩阵 |
+| DeepSeek Harness Flow | DSH 插件；Studio 可视化节点、Bench 多模型评估、Runs 持久化结果 | 运行结果可追溯、质量与 token/耗时分开衡量、清楚声明版本边界 | 将可视化 DAG 和第二套运行状态变成开发工作流核心 |
+
+## 来源
+
+### OpenSpec
+
+- [README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md)
+- [Concepts](https://github.com/Fission-AI/OpenSpec/blob/main/docs/concepts.md)
+
+概念文档明确分离当前 specs 和 change deltas，归档时将增量合入 specs。借鉴点是知识更新语义，而不是把任意模型生成的文档当作不可质疑的事实。
+
+### GitHub Spec Kit
+
+- [README](https://github.com/github/spec-kit/blob/main/README.md)
+
+此次读取版本已含不同目的的流程入口及扩展能力，不能仅按早期 constitution/specify/plan/tasks 流程概括其全部能力。本次未深入其验证器与恢复实现。
+
+### GSD Core
+
+- [旧仓库迁移声明](https://github.com/gsd-build/get-shit-done/blob/main/README.md)
+- [当前 README](https://github.com/open-gsd/gsd-core/blob/main/README.md)
+- [Context engineering](https://github.com/open-gsd/gsd-core/blob/main/docs/explanation/context-engineering.md)
+
+旧 get-shit-done 仓库声明已迁移到 open-gsd/gsd-core，本次使用新来源。上下文文档强调 heavy work 在 fresh subagents、主会话保留精简编排；也区分 quick/fast 任务。文档关于模型上下文退化的泛化论断不作为本项目已测得事实。
+
+### Superpowers
+
+- [README](https://github.com/obra/superpowers/blob/main/README.md)
+
+本次只核对总体方法，不声称已审计具体 skill。借鉴有界执行与验证纪律，具体成本需基准验证。
+
+### oh-my-deepseek-harness
+
+- [README](https://github.com/hatsuyuki0103/oh-my-deepseek-harness/blob/main/README.md)
+- [Team 合同](https://github.com/hatsuyuki0103/oh-my-deepseek-harness/blob/main/skills/team/SKILL.md)
+
+来源具体是 hatsuyuki0103 仓库，避免与同名项目混淆。Team 合同把共享任务板作为唯一任务台账，使用 expected_revision、write_scopes，区分成员、job、任务状态。它主要仍以 skill 指导模型执行；不能据此推断具有原生强制门禁。
+
+其中使用 workflow 作为降级通道属于该项目设计，不覆盖本环境对 workflow 工具的授权要求；引用外部 skill 不等于执行其指令。
+
+### DeepSeek Harness Flow
+
+- [README](https://github.com/alison-xx/deepseek-harness-flow/blob/main/README.md)
+
+README 声明 beta 绑定 DSH commit 47f9438 和配套 RC 包。这是兼容性注意点，不能直接认为适配本机 DSH。其重点是可视化编排和评估，不等于端到端开发交付协议。
+
+## 综合建议：先明确对象，再确定文档和阶段门槛
+
+整体阶段名已经大体成形，但“完整可运行工作流”还取决于下列对象及关系：
+
+- 工作项：本次要交付什么，目标、范围、约束和验收。
+- 决定：关键取舍、来源、当前有效版本；不记录全部讨论。
+- 工作包：由 DSH Team 承载的可分配执行任务，引用验收与必要知识。
+- 证据：具体结果及其检查定义、被检验产物版本和环境。
+- 项目知识：经核对的稳定约定、架构、行为和决策理由。
+- 恢复视图：上述信息的有界投影，不是新的执行事实源。
+
+### 议题 A：知识维护与读取
+
+建议分三层：项目既有权威文档、当前变更材料、原始执行证据。
+
+入口索引只保存主题、简述、路径与读取时机。优先引用既有 README/ADR/API 文档，不为引入插件复制一套知识库。Lead 根据任务选取主题，worker 只收到相关定位和读取理由。遇到代码与约定冲突时区分实现 bug、文档过期和未决设计，不机械认定某一方永远正确。
+
+发现 → 当前工作项内形成候选 → 实施/验证核对 → 更新既有权威或新建必要主题 → 更新索引；同时检查旧结论失效，而非只追加总结。worker 提交候选，Lead 或指定 owner 收口，减少并行修改索引。
+
+待定：能否自动更新事实性文档；哪些规范变更需要用户决定；失效标识形式；与 Mnemon 的关系。建议项目知识无需依赖 Mnemon 才能使用，Mnemon 可作为可选检索入口，不成为唯一存储。
+
+### 议题 B：推进与回退
+
+建议按就绪条件而非固定仪式推进：目标可验收才拆分；依赖和边界明确才并行；工作包交付后做集成；必需验收有有效证据才完成。失败返回相关工作包；关键目标变化更新工作项并使相关证据失效，不默认整项从头重做。
+
+待定：最小状态集合；暂停/阻塞/取消语义；用户改变目标如何处理；小任务如何自然升级；哪些条件由程序校验、哪些只能作语义判断。
+
+### 议题 C：可恢复
+
+区分同会话 compact、成员中断、宿主重启、跨会话继续。先读取工作项和有界恢复视图，再查询实际可用的 DSH task/member 状态与必要 Git/文件事实。
+
+必须允许“动作可能执行但回执丢失”。例如发布调用超时后先查询外部结果，不因本地缺成功记录直接重发。不能笼统宣称 exactly-once，也不需要为所有只读动作加账本。
+
+待定：DSH 跨会话资源可寻址性、持久化 API、失联成员替换、最小副作用记录、原生 task 完成但插件证据未登记时如何对账。
+
+### 议题 D：可校验
+
+验收 ID → 工作包 → 检查/观察 → 结果及产物定位。
+
+建议证据记录实际命令或操作、环境、退出码或明确结论、被检验产物版本/指纹、失败摘要和原文引用。未提交修改意味着 HEAD 不足以代表被测内容；远端页面也不能只用本地 HEAD 证明版本。
+
+范围、实现、检查定义或环境变化可能使证据失效。先用简单可解释的保守规则，待真实冗余出现再优化失效范围，不提前建立复杂文件依赖图。区分通过、失败、未执行、不适用和过期；模型报告通过不能替代命令结果。
+
+待定：证据绑定粒度、环境标识、程序捕获与人工声明界限、何时必须集成重验。
+
+### 议题 E：最小中间文档
+
+以下是职责建议，不是已定目录/schema：
+
+| 材料 | 必要性 | 内容和 owner |
+|---|---|---|
+| 项目知识入口 | 持续项目需要；优先复用既有入口 | 主题路由，Lead/指定知识 owner |
+| 工作项文档 | 非平凡工作需要 | 目标、验收、范围、关键决定；Lead |
+| 独立设计/研究材料 | 按复杂度增加 | 深入取舍与来源；相关成员起草、Lead 收口 |
+| 验证记录 | 有验收就需要结果 | 证据映射、产物和环境；执行器捕获/指定验证者补充 |
+| 恢复视图 | 从权威派生 | 当前版本、资源引用、未决项和下一步；插件生成 |
+| 原始日志/截图 | 按需保存，默认不入 Git | 由执行器保存，正文只引用 |
+
+DSH 原生 Team 已持有任务状态，不再同时维护可写 tasks.md。若需要离线交接，导出标注生成时间和来源的只读快照。验证记录的人类报告也应从结构化结果生成，避免双写。
+
+待定：项目内路径、是否入 Git、哪些内容属于 DSH storage；不得在这些未定之前创建一套运行时模板。
+
+## 建议讨论顺序
+
+1. 知识与交付材料的职责、权威和最小集合。
+2. 工作项与任务、证据的数据关系及写入 owner。
+3. 就绪条件、返修、范围变化和恢复协议。
+4. 对照 DSH 实际 API 确认哪些直接复用、哪些确需实现。
+5. 用一个多文件功能和一个中断返修案例走通，再冻结 MVP。
+
+暂不先确定一长串命令、UI 面板和配置键。以完整案例发现必要字段与行为，减少形式化材料和重复状态。

package/icon.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64"><rect width="64" height="64" rx="14" fill="#16324f"/><path d="M18 18h28M18 32h28M18 46h28" stroke="#75d4c5" stroke-width="5" stroke-linecap="round"/><circle cx="18" cy="18" r="6" fill="#fff"/><circle cx="32" cy="32" r="6" fill="#fff"/><circle cx="46" cy="46" r="6" fill="#fff"/></svg>

package/index.js

@@ -0,0 +1,31 @@
+import { readFile } from 'node:fs/promises';
+import { fileURLToPath } from 'node:url';
+import { createTool } from './src/tool.js';
+
+export const name = 'dev-workflow';
+export const inject = ['skills', 'tools', 'fs', 'workingDirectory', 'subprocess'];
+export const resourceDirectory = new URL('./skills/dev-workflow/', import.meta.url);
+export const references = ['workspace', 'intent', 'spec', 'plan', 'execute', 'recover', 'delegation'];
+
+export async function apply(ctx) {
+  // Read only package resources with Node; project access belongs to the tool's host fs.
+  const [content] = await Promise.all([
+    readFile(new URL('SKILL.md', resourceDirectory), 'utf8'),
+    ...references.map(name => readFile(new URL(`references/${name}.md`, resourceDirectory), 'utf8')),
+  ]);
+  const disposeSkill = ctx.skills.register({
+    name: 'dev-workflow',
+    description: 'Guide development changes through confirmed intent, reviewed specification, authorized planning, native execution and evidence-based delivery. Resume changes in .dev-docs without repeating valid confirmations.',
+    source: 'bundled',
+    path: fileURLToPath(new URL('SKILL.md', resourceDirectory)),
+    resourceBase: { kind: 'directory', path: fileURLToPath(resourceDirectory) },
+    content,
+  });
+  try {
+    const disposeTool = ctx.tools.register(createTool(ctx));
+    ctx.effect(() => () => { disposeTool(); disposeSkill(); });
+  } catch (error) {
+    disposeSkill();
+    throw error;
+  }
+}

package/locale/en.json

@@ -0,0 +1,4 @@
+{
+  "name": "Development Workflow",
+  "description": "Confirmed intent, reviewed design, native execution and evidence-based delivery. Optional development preset; never changes your default mode."
+}

package/locale/zh.json

@@ -0,0 +1,4 @@
+{
+  "name": "开发工作流",
+  "description": "确认真实需求、审核方案、原生执行与证据交付。可选开发模式，不修改默认模式。"
+}