# dsh-control-plane 长期路线图

本文档是公开仓库的长期规划源文件。根目录 `ROADMAP.md` 只引用本文档；阶段细节可以拆到 `docs/roadmap/`，但不能形成第二套总体路线图。

## 项目愿景

`dsh-control-plane` 是一个 local-first 的开发者控制平面，用于统一管理多个 DeepSeek Harness Runtime、Profile、Preset、Session、计划和知识引用。

它面向公开 GitHub 开发者，不是 Harvis 私有工作区的备份，不是某一台机器的部署脚本集合，也不替代 DSH 本身。

## 公共边界

公开仓库可以包含：

- Runtime、Profile、Preset、Session、Plan、Knowledge Reference 的公开 schema；
- Scenario Adapter 和场景摘要的公开 schema；
- 多 Runtime 管理器的通用接口和安全 Adapter；
- DSH Host Service 和 Client Panel 的插件集成；
- 计划、知识引用和场景适配器协议；
- 示例配置、测试 fixture、文档、CI 和发布脚本。

公开仓库不得包含：

- Token、Cookie、API Key、`.env`、凭据、原始聊天记录、真实 Session；
- 私有知识库、品牌资料、内部 SOP、完整运行日志和诊断快照；
- 用户目录、绝对本机路径、真实 `DSH_HOME`、私有端口布局；
- 官方 DSH、Zhitro DSH 或 Harvis Dev DSH 的私有部署文件。

机器配置只放在 ignored 的 `agentworkos.local.toml`，公开仓库使用占位符示例。

## 总体架构

```text
dsh-control-plane
├── Control Plane Core
│   ├── Runtime Registry
│   ├── Profile / Preset Registry
│   ├── Session Bridge
│   ├── Plan / Knowledge References
│   └── Scenario Adapter Registry
│
├── DSH Integration Bundle
│   ├── dsh.bundle.patch
│   ├── DSH Host Service
│   └── DSH Client Panel
│
└── Runtime Adapter Layer
    ├── Official DSH
    ├── Zhitro DSH
    ├── Harvis Dev DSH
    └── Custom DSH
```

Runtime 管理必须通过显式 allowlisted Adapter。UI 不得执行任意 shell。Host 与 Client 只交换 JSON-safe 的最小标量数据，不传递完整 Context、Service、Session、Snapshot、React 元素、函数、凭据或原始日志。

## 阶段 0：项目章程和公共边界

交付：README、VISION、ARCHITECTURE、SECURITY、CONTRIBUTING、LICENSE、CHANGELOG、公开配置示例、`.gitignore` 和本路线图。

验收：新贡献者只阅读公开文档即可理解项目目标、非目标、数据边界和当前状态；仓库不依赖本机私有路径；后续实现位置和发布边界明确。阶段 0 不实现 Runtime 生命周期、Slot、Host Service 或 Client UI；这些名称在本文中只是后续阶段的验收标准。

## 阶段 1：基础契约

定义并测试 Runtime、Profile、Preset、Session、Plan、Knowledge Reference schema、版本号和兼容策略。使用虚构 ID 和 fixture，不接入真实知识库或真实 Session。

验收：示例可以脱离本机运行；对象可安全序列化；没有私有数据依赖。

## 阶段 2：本地 Runtime Manager MVP

实现 Runtime 注册、Profile 检查、启动、停止、健康检查、隔离 `DSH_HOME` 和错误摘要。官方 DSH、Zhitro DSH、Harvis Dev DSH 通过独立 Adapter 接入。

验收：隔离目录可启动测试 Runtime；停止后无残留进程或锁；一个 Runtime 失败不会阻塞其他 Runtime；不存在任意命令执行入口。

## 阶段 3：DSH Plugin 接入

实现可安装的 `dsh.bundle.patch`、Host Service、Web Client Bundle、Runtime Catalog、Session Board 和 Plan Panel。公开分发使用一个可安装的 Bundle；Bundle 内的每个可选功能都有独立 Cordis effect、Slot disposer、错误边界、卸载、重载和禁用恢复路径。

验收：隔离 Web Profile 冷启动、亮暗色检查、控制台检查、停止/卸载/重载和仅禁用新增行的恢复检查通过。

## 阶段 4：知识库和计划桥接

以 Markdown-first、Reference-first 方式连接 Plan、Artifact 和 Knowledge Provider。公共仓库只定义接口和示例，不同步私有知识全文或原始聊天。

验收：计划和知识引用可显示、可关联、可追踪，但不会自动上传私有内容。

## 阶段 5：场景适配器

提供 Generic Project、Developer Workspace、BrandOS 和 Interview Learning Adapter。`Agent-Job-Interview` 作为第一个外部场景验证计划、主题进度、题目集合和 Session 关联；接入时保留来源、commit/release 和许可证信息。

验收：场景适配器可替换；核心不依赖单一项目；示例数据与真实私有数据分离。

## 阶段 6：安全、测试和 DeepSeek Pro 审核

每个阶段生成脱敏 Review Pack，按 [`docs/review-protocol.md`](review-protocol.md) 使用隔离本地 DSH DeepSeek Pro 审核架构、Cordis/DSH 契约、隐私、测试和文档声明。DSH Pro 是审查者，不是发布授权者。

验收：静态安全扫描、单元/契约测试、Bundle 构建、隔离 Profile 冷启动、UI/控制台、卸载重载和禁用恢复检查通过。

## 阶段 7：GitHub Release Candidate 与公共发布

完成公共 README、License、CI、安全扫描、Bundle 构建、离线 Profile 验证、tarball 检查、版本 Tag 和公开 Release。发布阶段使用本地 `dsh-plugin-release` 技能及其 `pnpm run check`、`pnpm run pack:dsh`、`pnpm run verify:dsh-offline` 门禁。

验收：Git 历史、manifest、lockfile、Release tarball、本地 dry-run 和公开仓库状态一致；没有私有文件。当前公开版本为 [`v0.1.0`](https://github.com/Harzva/dsh-control-plane/releases/tag/v0.1.0)。

## 阶段 8：awesome-dsh-plugin 提交

Release 成功后，满足仓库年龄和提交数门槛，再提交插件 YAML 和生成后的 README，运行目录校验、安装 smoke test 和 CI 检查后创建 PR。PR 合并前不能宣称已被收录。

## 阶段 9：Harzva Plugin Registry

建立独立的 [`Harzva/dsh-plugin-registry`](https://github.com/Harzva/dsh-plugin-registry)
作为 Harzva 自有插件的可控发布目录和事实源。第一阶段只做 GitHub-native
静态注册表、JSON Schema、来源 commit、Release tarball、DSH 兼容矩阵、权限声明、
许可证和审核证据；不把它包装成官方 DSH 市场，也不复制一个没有治理边界的通用
marketplace。`dsh-plugin-store` 可以作为未来的 Web/DSH UI，读取这个 registry，
但不应先于 registry 成为第二个事实源。

现有生态已经有社区市场和目录，因此本项目的差异点应是“Harzva first-party、
可审计、可禁用、可回滚、只发布公开元数据”：

- `awesome-dsh-plugin`：社区精选列表和上游收录入口；
- `dsh-market`、`dsh-marketplace`、`dsh-subscribe`：社区市场、安装器或 storefront；
- `dsh.pub`、`dsh.directory`：公共发现和目录服务。

验收：注册表拥有独立 schema、唯一插件 ID、来源和版本 pin、CI 校验、审核状态、
撤回/禁用状态和生成索引；`dsh-control-plane` 只通过只读 reference 消费它，不把
第三方源码、凭证、私有 Profile、原始 Session 或私有知识库同步进去。

## 阶段 10：长期维护

维护 DSH 版本兼容矩阵、Runtime Adapter、Profile/Preset/Slot/Bundle 变更记录、迁移指南、弃用周期和每次发布的 DSH Pro 审核及隐私扫描。

## 当前状态

阶段 0、阶段 1、阶段 2、阶段 3、阶段 4、阶段 5、阶段 6 和阶段 7 已完成并有本地提交、
隔离 DSH 验证和 DeepSeek Pro 审核记录。阶段 8 已提交 Draft PR，当前等待年龄门槛后重跑；阶段 1 的实现规范位于
[`docs/roadmap/stage-1-foundation-contract.md`](roadmap/stage-1-foundation-contract.md)。
阶段 2 的实现规范位于
[`docs/roadmap/stage-2-runtime-manager.md`](roadmap/stage-2-runtime-manager.md)。
阶段 3 的实现规范位于
[`docs/roadmap/stage-3-dsh-plugin.md`](roadmap/stage-3-dsh-plugin.md)。阶段 4
的实现规范位于
[`docs/roadmap/stage-4-plan-knowledge-bridge.md`](roadmap/stage-4-plan-knowledge-bridge.md)。
阶段 5 的实现规范位于
[`docs/roadmap/stage-5-scenario-adapters.md`](roadmap/stage-5-scenario-adapters.md)。
阶段 5 已完成。阶段 6 的实现规范位于
[`docs/roadmap/stage-6-security-review.md`](roadmap/stage-6-security-review.md)。
Stage 6 已完成；阶段 7 的实现规范位于
[`docs/roadmap/stage-7-release-candidate.md`](roadmap/stage-7-release-candidate.md)。
阶段 7 的公共发布已完成：仓库、`main`、`v0.1.0` Tag、Release tarball 和
`dsh-plugin` topic 均已核验。阶段 8 的实现规范位于
[`docs/roadmap/stage-8-awesome-submission.md`](roadmap/stage-8-awesome-submission.md)；
当前已创建 Draft PR，但 submission gate 等待仓库满 1 天后重跑，awesome 收录仍不可
提前宣称。阶段 9 的实现规范位于
[`docs/roadmap/stage-9-plugin-registry.md`](roadmap/stage-9-plugin-registry.md)，
第一阶段最小 registry skeleton 已创建并发布到
[`Harzva/dsh-plugin-registry`](https://github.com/Harzva/dsh-plugin-registry)；
扩展多插件治理、发布审核和可选 Store UI 仍是后续计划。