@fooksky/lodestar 0.2.2 → 0.2.4

package/docs/research/development-mode.md

@@ -1,98 +0,0 @@
-# 用 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

@@ -1,91 +0,0 @@
-# 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

@@ -1,136 +0,0 @@
-# 开发工作流调研与下一轮设计议题
-
-调研日期：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/tests/scenarios.md

@@ -1,60 +0,0 @@
-# 开发工作流验证与行为验收记录
-
-程序验证和真实模型会话观察分别记录。`pnpm test` 的通过不等于以下模型场景已通过；本次没有安装 profile、切换现有会话或启动替代 GUI。
-
-## 首版已完成的可重复程序验证（历史记录）
-
-2026-11-07：使用已安装 DSH `0.2.2-rc.1`，设置 `DSH_HOST_ROOT` 后运行全套，26/26 通过、0 跳过。语法检查与包内容预览通过。
-
-- 状态：确认复用/撤回、原子多操作、当前材料依赖、阶段约束、验收与关闭。
-- 仓储：创建冲突、CAS 并发、正文变化检测、损坏/未知 schema、写入失败不覆盖。
-- 调用边界：Agent 身份、调用者目录、会话 sandbox policy、取消信号透传。
-- 真实 DSH 文件服务：相对项目根、原子并发、目录分页、符号链接路径边界。
-- 真实沙箱：Session + sandboxPolicy + SandboxedFileSystem 验证 workspace-write、read-only、projectRoot 越界及当前目录变化不扩大授权根。
-- 注册、资源和可选模式：真实 Cordis/SkillRegistry/ToolsService、Loader/AgentPresetRegistry 注册、卸载、scope 隔离、子 scope 继承和保留 revision 生命周期通过。模式测试的原生工具名称集合为夹具，未构造完整 Team 服务；不将该测试宣称为真实 Team 工具视图验收。
-
-## 分支扩展已完成的程序验证
-
-2026-11-07：使用已安装 DSH `0.2.2-rc.1`，设置 `DSH_HOST_ROOT` 后运行 `npm test`，**35/35 通过、0 跳过**；`npm run check`、`npm pack --dry-run` 和差异空白检查通过。未安装 profile、提交或推送。以下是实际自动验证的范围，与下方真实模型行为验收分开。
-
-| 范围 | 已验证结果 | 证据 |
-|---|---|---|
-| linked worktree 隔离 | main 与两个 linked worktree 使用同一 change ID，状态独立推进；知识继承提交快照，修改互不影响 | [真实工作区测试](host-workspace.test.js) |
-| 项目根边界 | 跨 checkout 的全部 action 被拒绝；同 checkout 项目子目录可创建/读取；子模块独立识别，从父仓库直接指向子模块被拒绝；普通目录要求位于 cwd 内 | [真实工作区测试](host-workspace.test.js)、[工作区单测](workspace.test.js) |
-| 绑定与重绑 | 创建 schemaVersion: 2 且 workspace 必填的状态；提交推进不锁定，同绑定操作不增 revision、不刷新 baseCommit；分支改名显示 mismatch 并拒绝常规写，独立重绑保留旧绑定和理由；混合操作失败不发布 | [真实工作区测试](host-workspace.test.js) |
-| 状态格式与 CAS | 仅接受 schemaVersion: 2 和必填 workspace；旧/未知 schema、缺失绑定在 get/list/bind 中均报错且不发布；缺失 state 的目录显示错误；错误 revision、原子并发与失败写入保护继续通过。简化后的真实宿主全套 35/35 通过 | [真实工作区测试](host-workspace.test.js)、[仓储测试](store.test.js)、[宿主仓储测试](host-store.test.js) |
-| Git 状态及错误 | detached 可读且 create/update/bind 均拒绝；unborn 可写且 baseCommit null；bare、损坏 gitfile/HEAD 拒绝；缺少服务/Git、spawn 失败、取消、有损输出不降级 | [真实工作区测试](host-workspace.test.js)、[工作区单测](workspace.test.js) |
-| 可移动绑定与合入历史 | 普通 checkout 搬目录后绑定仍匹配；change 材料合入 main 后来源绑定仍可读、常规写拒绝 | [真实工作区测试](host-workspace.test.js) |
-| 真实宿主边界 | 使用实际 fs、subprocess、sandbox、Session 和注册器；read-only 允许读取并拒绝写入；工具/skill/schema 注册及卸载通过；nullable schema 已适配 Host 的 oneOf 子集 | [沙箱测试](host-sandbox.test.js)、[注册测试](registration.test.js) |
-
-工作区单测通过绑定比较验证 HEAD 变化不参与身份判断；未另行重放完整 rebase、浅克隆、跨机器检出或真实 PR 服务。符号链接材料边界由既有真实文件服务测试覆盖。测试准备 Git 仓库可使用 Node child_process，插件生产路径的 Git 查询统一走宿主 subprocess/sandbox。
-
-## 真实模型会话验收（尚未执行）
-
-以下场景应在允许使用插件的隔离会话中观察；不能仅用文档检查宣布通过。无需自动安装到用户 profile。若部署环境未提供这些能力，记录具体阻断，不降低验收标准。
-
-| 场景 | 执行与观察要点 | 判定 |
-|---|---|---|
-| 增量顺序交付 | 两个独立需求分别建 change，确认→设计→授权→实施→实际验收；不自动合并范围 | 待观察 |
-| spec 满足而 intent 不足 | 验证揭示真实需求未满足，回到相应材料并沿用明确的已有确认，不凭测试通过 close | 待观察 |
-| 多轮变更 | intent/spec/plan 反复修订、局部验证失效与有效证据沿用；无旧版本授权串用 | 待观察 |
-| 空项目到 MVP | 按真实可运行切片完成，不以脚手架或假 fixture 冒充产品集成 | 待观察 |
-| 只设计 | 用户要求只设计，交付 spec 后停止，不建实施 plan/goal、不写产品代码 | 待观察 |
-| 确认复用 | 同一句批准需求、方案和实施，不再重复询问；“先别做”不得登记实施授权 | 待观察 |
-| Team 协作 | 原生 task revision/owner/write scopes；成员只做任务包，Lead 持有主材料；inactive 不当 completed | 待观察 |
-| 中断恢复 | 正文先写而状态未登记、回执未知、旧 Team 不可达；只补缺口，不全量重跑 | 待观察 |
-| 浏览器缺失 | 证明替代验证覆盖同一命题，或明确验证未完成，不以编译通过替代交互验收 | 待观察 |
-| 模式生命周期 | 新会话选择、子成员职责、停用后贡献移除、既有有效 change 恢复；普通会话不受影响 | 部分可由宿主集成测试覆盖，模型部分待观察 |
-
-### 分支扩展真实行为观察（尚未执行）
-
-| 场景 | 执行与观察要点 | 判定 |
-|---|---|---|
-| 外部工作区准备 | 外部助手领取 Issue、选择独立 worktree 和启动会话；模型先 workspace 再 create，不让插件创建分支、跨需求调度或扫描其他工作区；普通调查可不建 change | 待观察 |
-| 本地材料与委派 | 每个需求的 Lead 和成员使用本 worktree 的代码、知识、主材料及证据；任务包包含 projectRoot/changeId/预期分支/cwd；不共享材料根或复制后双写 | 待观察 |
-| 分支漂移恢复 | mismatch 先辨认归属，不凭相同 HEAD 猜测；分支改名、明确接管或普通目录初始化为仓库后有依据地独立重绑，历史必含 previous；缺失绑定或非法 schema 报错，不能靠重绑修复；detached 不写，历史合入项不批量改绑 | 待观察 |
-| 运行期间工作区稳定 | 不外部切分支、搬移或清理；同 checkout 不并发切换不同需求；CAS 不当任务锁，多 Lead 先明确交接 | 待观察 |
-| PR/MR 交付边界 | plan/交付记录地址、源/目标分支、评审/合入结果和证据；要求合入时先集成验证，边界为提交 PR 时不声称合入；反馈沿用原有退回、版本及局部失效 | 待观察 |
-| 语义集成与清理 | 知识和 state 冲突核对语义；保留需要的代码、材料及证据后按授权提交/清理；外部数据库、端口、账号等独立隔离，插件不自动接管 | 待观察 |
-
-每次观察记录工作区/分支、材料版本、输入表达、实际产物、验收证据、失败/阻断和结果；耗时/token 仅在宿主提供时记录，不解析私有日志补造指标。