# Dominds 发展规划（Roadmap）

英文版：[English](./roadmap.md)

## 摘要

本文档描述 Dominds 的阶段性目标与大版本演进方向，用于对齐研发优先级与架构决策。它不是交付承诺；细节会随验证结果调整。

Dominds 的长期方向是把“智能体分工协作”沉淀为一个可复用、可扩展、可安装/卸载的运行时体系：**微内核 + Apps**。

相关命名口径（主线/支线等）：[`dominds-terminology.md`](./dominds-terminology.md)

---

## 最终目标（North Star）

成为**智能体社会化分工协作的微内核**：

- **微内核只负责运行调度**：对话/任务编排、事件与流式转录、权限与能力边界、持久化与可观测性、App 生命周期与注册机制。
- **能力按需安装**：工具集、交互控制、UI、工作流/DSL 等都以 **Dominds App** 的形式提供；并且**以 rtws（runtime workspace）为单位**独立管理——每个 rtws 都能按需安装/卸载、启用/禁用所需 Apps。
- **可多前端共存**：同一 rtws 中允许多个前端 App（例如 WebUI / TUI / 专用可视化：业务数据看板、流程可视化、业务运营前/中/后台 UI、互动游戏 UI）以一致的协议接入与协作。

---

## 0.x：概念验证（PoC）与预览发布（Preview）

核心定位：验证“稳定有效的工作模式”，把关键机制跑通、跑稳、可调试。

- 建立可复用的工作范式：主线对话推进 + 支线对话并行推进 + 回传聚合（诉请 / FBR 等）。
- 打磨最小可用的运行时闭环：对话持久化、工具调用、流式输出与转录、基础可观测性与故障定位。
- 以小步快跑方式迭代：允许内部结构快速变化，但持续沉淀“什么是稳定有效”的方法论与约束边界。

---

## 1.x：微内核架构迁移（Kernel ↔ Dominds Apps）

核心定位：把系统特性清晰分化为“内核部分”与“Dominds Apps”，形成可扩展、可按需安装的能力体系。

### 1) 内核与 Apps 的边界

- 内核：只保留运行调度、协议与持久化等“必需且通用”的能力。
- Apps：承载“可选、可替换、可多样化”的能力（工具集、交互控制组件、UI、工作流等）。

### 2) Apps 按需安装到 rtws

- Apps 在 rtws 粒度安装/卸载，并能在运行时启用/禁用。
- Apps 可**动态注册**：
  - 工具集（tools）
  - 运行控制组件（run-control components，例如：阶段门、审批、人机协作节拍器、预算/限额器）
  - 事件订阅与可视化面板（例如：对话流式子流、队友协作状态）

### 3) WebUI 作为一个 App（多元化前端）

- 将 WebUI 视为可替换/可并存的 App，而不是内核“自带界面”。
- 允许多元化前端 App：
  - 不同交互范式（聊天/看板/图谱/时间线/回放）
  - 面向不同角色（开发者、运营者、审计者、观察者）

### 4) Phaser App：把工作流做成可操作的“系统”

- 开发 **Phaser App** 作为一个交互式前端/可视化运行台，用于承载更强的“可操作性”与“节拍控制”。
- 基于 **Mermaid** 实现 DSL（以图为代码 / graph-as-code）：
  - 用状态机机制表达工作流（states / transitions / guards）
  - 以 **Phase-Gate（阶段门）** 支持“可控转阶段”：关键跃迁需要明确条件、证据与（可选的）人工确认
  - 将“可机械化的流程”显式化，把不确定性留给智能体，把可控性留给系统

---

## 2.x：Dominds 成为真正的微内核（Only Scheduling）

核心定位：Dominds 只负责运行调度，其他一切都成为可安装/卸载的 App。

- 工具集、交互控制、UI 全部迁移为独立 App（内核不再内置默认实现）。
- 更强的 App 生态能力：
  - App 清单/依赖/版本与兼容性约束
  - 能力边界与权限策略（最小权限、可审计）
  - 可观测性标准化（事件、指标、回放）

---

## 关键原则（跨版本）

- **rtws-first**：能力与状态以 rtws 为边界，便于按项目/团队隔离与复用。
- **协议优先**：内核与 Apps、前端与后端以稳定协议对齐，避免“只能一起升级”的紧耦合。
- **可调试性是一等公民**：任何流式/并发/分工机制都必须可复盘、可定位、可解释。
- **保活优先，语义可自愈**：Dominds 的产品目标不是让技术状态机在每个瞬间都显得完美，而是让人类与智能体组成的业务对话尽量继续运行。遇到技术磕绊、局部语义失真或投影不一致时，只要仍能基于人类和智能体的判断继续推进，并能在后续交互中语义上自愈，系统应优先保活；真正会导致错误交付、重复消费或无法判责的冲突仍必须 loud diagnostic。
- **顺直优先，少额外抽象**：在不削弱保活的前提下，系统还应尽量让业务意图的表达更直白，少加额外抽象、少造新口径、少用技术概念遮住业务意思。真正的“这里不该太啰嗦”应体现在具体业务场景的表达里，而不是把“短路径”或“少噪音”当作低阶工作的直接口令。
