# eo-skills 配置约定

所有 eo-* skill 共享的路径与配置约定。本文档是**唯一权威来源**——其它 skill 引用本文，不重复定义。

## 用户级数据根 `~/.eo/`

`~/.eo/` 是整个 eo 生态（eo-skills + eo-platform 等）在单用户下共享的**用户级数据根**，避免配置与缓存散落各处。当前约定内容如下：

| 路径 | 性质 | 谁维护 |
|------|------|--------|
| `~/.eo/projects.json` | eo 生态项目注册表（`eo-board --all` / `eo-sync watch --all` 跨项目枚举） | `eo-board --register` / `--unregister` |
| `~/.eo/platform.db` | eo-platform 本地索引缓存（SQLite） | eo-platform |
| `~/.eo/logs/` | eo-platform 日志（按需） | eo-platform |
| `~/.eo/handbook-templates/<preset>/` | handbook 模板私有库（同名 preset 整套覆盖内置库） | 用户手工维护 |

根路径可通过环境变量 `EO_HOME` 覆盖（例如跑测试或多账号隔离时指向临时目录）。未设置时一律使用 `~/.eo/`。涉及该路径的内联命令一律写 `"${EO_HOME:-$HOME/.eo}"`。

## 两个配置文件

| 文件 | 作用域 | 谁维护 | 何时读 |
|------|--------|--------|--------|
| `<repo>/.eo-project.json` | 项目级·团队共享 | `eo-project-init` 生成，后续 skill 只读 | **所有 eo-* skill 启动时必读** |
| `<repo>/.eo-project.local.json` | 项目级·个人/机器覆盖（可选，**不提交**） | 协作者手工 / `eo-project-init` 协作者接入分支生成 | 与 `.eo-project.json` 同时读，顶层字段覆盖合并（local 优先） |

**合并结果**（`.eo-project.json` + 可选 local 覆盖）是**自包含**的——含所有需要的绝对路径，其它 skill 不需要再去读用户级文件。

## `<repo>/.eo-project.json` schema（项目级，必需）

```json
{
  "project_name": "my-project",
  "mode": "local",
  "project_root": "/Users/xxx/my-project/.eo-project",
  "doc_root": "eo-doc",
  "kanban_path": null,
  "sync": {
    "obsidian": { "enabled": true, "stub_dir": "board" },
    "github":   { "enabled": false }
  }
}
```

| 字段 | 类型 | 必填 | 说明 |
|------|------|------|------|
| `project_name` | string | ✅ | 项目显示名 |
| `mode` | `"local"` | ✅ | 运行模式 |
| `project_root` | string（绝对路径） | ✅ | **项目管理侧根**，= `<repo>/.eo-project` 的绝对路径。写成相对路径时（存量形态）读取层按 repo root 解析并解软链后放行 + 告警，见下「读取层归一化」 |
| `doc_root` | string（相对 repo root） | ✅ | **代码侧根**，默认 `"eo-doc"` |
| `kanban_path` | null | ❌ | 一律 `null`；存量值被所有 skill 忽略。项目级总览 = Bases 聚合各项目 roadmap.md frontmatter |
| `board.enabled` | bool | ❌（默认 `false`） | **存量字段**（新配置不再生成，仅兼容映射消费；首选写 `sync.obsidian.enabled`）。change 看板投影开关。开启后 `eo-sync`（obsidian 适配器）把 stub 卡片投影到 `<project_root>/board/`，见 `eo-shared/board-github.md` 与下文 `sync` 段 |
| `board.stub_dir` | string | ❌（默认 `"board"`） | **存量字段**（首选 `sync.obsidian.stub_dir`）。stub 目录名（相对 `project_root`） |
| `github.issue` | bool | ❌（默认 `false`） | **存量字段**（首选 `sync.github.issue`）。change ↔ GitHub issue 联动开关 |
| `github.pr` | `"auto"` \| `"always"` \| `"never"` | ❌（默认 `"never"`） | **存量字段**（首选 `sync.github.pr`）。archive 时的 PR 策略：`auto` = 在非默认分支且有 remote 时自动建 PR |
| `sync` | object \| null | ❌ | **首选**（init 新配置写本段，存量 `board`/`github` 仅存量兼容）。`eo-sync` 适配器启用制。**键存在性决定是否回落**：缺省（键不在）→ 由 `board`/`github` 兼容映射派生；键存在（含空 `{}` 或显式 `null`）→ 完全以其为准、绝不回落，其中 `{}`/`null` = 显式零目标；object 以外的类型（数字/字符串等）→ 配置错误。schema 见下 |
| `state` | object | ❌ | state 现状文档层启用制。键缺失 = 未表态（init 走问答）；`{"enabled": true}` 启用，`{"enabled": false}` 显式关闭不再询问。schema 见下 |

缺省 `board` / `github` 字段 = 全部关闭（存量项目兼容映射照常生效；新配置不含这两段）。

### `sync` 段（eo-sync 适配器启用制）

`eo-sync` 的投影目标由 `sync` 段显式启用——**发现 ≠ 执行**：PATH 上的 `eo-sync-*` 可执行文件负责「有哪些」，`sync` 段负责「启用哪些 + 参数」（这也是第三方可执行文件的信任边界）。

```json
{
  "sync": {
    "obsidian": { "enabled": true, "stub_dir": "board" },
    "github":   { "enabled": true, "issue": true, "pr": "auto" },
    "notion":   { "enabled": false, "database_id": "..." }
  }
}
```

| 键 | 说明 |
|----|------|
| `sync.<name>.enabled` | bool，仅 `true` 的适配器会被 `eo-sync run` 执行 |
| `sync.<name>.<其它>` | 该适配器的自定义参数，`enabled` 之外的键原样透传给适配器 |

**兼容映射**：以**键是否存在**判定（非「值是否非空」）——合并配置**无** `sync` 键时由存量 `board` / `github` 段等价派生启用集（`board.enabled`→`obsidian`、`github.issue`/`pr`→`github`）；`sync` 键**存在**（含空 `{}` 或显式 `null`）则完全以其为准、不与 `board`/`github` 深合并，其中 `{}`/`null` 是用户显式选择的零目标（绝不回落存量段）；`sync` 值为 object 以外的类型 → 配置校验失败（不静默降级）。存量项目无需改配置即按等价映射生效。Init 新配置只写 `sync` 段，重跑 init（1.5 分支）对仅有旧段的项目提示并代写等价 `sync` 段（旧段保留不删）。协议契约见 [../../docs/sync-adapter-protocol.md](../../docs/sync-adapter-protocol.md)。
### `state` 段（state 现状文档层）

`eo-doc/state/` 现状篇（业务现状活文档，代码为唯一信源）是否启用，由 `state` 段显式表达：

```json
{ "state": { "enabled": true } }
```

- 键缺失 = 未表态——init（首建与 1.5 分支）按封闭选择协议问一次，结论落本段
- `enabled: true`：`/eo-doc-manager sync` 按 cursor 增量再生 `state/` 现状篇（`eo-doc/.sync-cursor` 记录游标）；archive 收口自动联动
- `enabled: false`：显式关闭，不再询问；存量 `state/` 目录冻结留存（不删除）
- `enabled` 非 bool 或 `state` 值为 object 以外类型 → 配置校验失败
- 团队共享字段（文档层偏好是团队口径），不进 `.eo-project.local.json` 的机器相关覆盖清单

**设计约束**：
- `project_root` **生成时**永远写绝对路径，skill 一律走 `project_root`。
- **读取层归一化**（存量兼容）：合并结果的 `project_root` 是相对路径时（存量常写成软链相对路径），读取层按 repo root 解析并解软链，得到已存在的目录即放行并在 stderr 告警一行；解析不到已存在目录则仍按配置校验失败处理（不猜、不静默放行）。下游拿到的 `project_root` 恒为绝对路径，消费方无需感知。重跑 `/eo-project-init` 会把它回写成绝对路径（落点按 local 优先规则）。
- `.eo-project.json` 本身**提交到仓库**（团队共享配置）；`.eo-project.local.json` **不提交**（`eo-project-init` 默认写入 `.gitignore`）。
- 必填校验以**合并结果**为准——单个文件不要求自包含。

## `<repo>/.eo-project.local.json`（项目级个人覆盖，可选）

**动机**：`.eo-project.json` 提交进仓库，但 `project_root`（绝对路径）、`mode`、`sync` 因人/机器而异——协作者 clone 后拿到的是别人机器上的路径。local 文件承载这些机器相关字段，共享文件只留团队口径。

**规则**：

- 与 `.eo-project.json` **同目录**；schema 相同，**所有字段可选**。
- **顶层浅合并**，local 优先：local 出现的顶层字段整段覆盖共享文件的同名字段（`sync` 及 存量 `board` / `github` 是对象也**整段覆盖**，不做深合并）。
- 团队仓库的 `.eo-project.json` 可只保留共享字段（`project_name` / `doc_root`），机器相关字段（`project_root` / `mode` / `sync`）由每人的 local 文件提供。
- **字段写回**（如 sync 段后开补齐，见 `eo-shared/board-github.md`）：该顶层字段已存在于 local 文件 → 写 local（写共享文件会被覆盖屏蔽）；否则写 `.eo-project.json`。

## Skill 启动时的配置解析流程

**除 `eo-project-init` 外的所有 eo-* skill 启动时：**

1. 从 cwd 向上查找 `.eo-project.json`（到文件系统根为止）
2. 找不到 → 报错并退出：
   ```
   ❌ 未找到 .eo-project.json
   请先运行 /eo-project-init 初始化项目。
   ```
3. 找到 → 解析其内容；**同目录存在 `.eo-project.local.json` 时先做顶层字段覆盖合并（local 优先）**，后续一律用合并结果中的路径（**不读用户级文件**）
4. 合并结果缺必填字段（`project_root` / `mode` 等）→ 报错并提示运行 `/eo-project-init`（协作者 clone 场景见其「协作者接入」分支）

**`eo-project-init` 的启动行为更特殊**：
1. 先看 cwd 向上是否已有 `.eo-project.json`（已初始化过 → 走「1.5 更新/修复分支」）。
2. 未初始化 → 进入首次创建流程（见 `eo-project-init/SKILL.md`）。

## 目录结构参考

### 代码侧（仓库内 `<doc_root>/`，默认 `eo-doc/`）

`eo-doc-manager init` 建最小骨架：

```
eo-doc/
├── changes/          # 必建，change 工件流
├── agent-handbook/   # 可选，Agent 操作手册（篇目含 INDEX.md）
└── templates/        # 必建（空），eo-* 扩展点
```

### 项目管理侧（`project_root/`）

`eo-project-init` 建最小骨架：

```
<project_root>/
├── roadmap.md     # 必建（frontmatter 含 status/phase/summary，Bases 项目总览按此聚合）
├── backlog/       # 按需，待办/灵感卡片（每条一文件，status: backlog 上看板；archive/ 存归档卡）
├── phases/        # 按需，roadmap 拆解后生成
├── decisions/     # 按需，首次记录决策时建
├── lessons/       # 按需，首次记录经验时建（**项目级**，替代全局 _lessons/）
├── brainstorm/    # 按需，eo-brainstorming 首次产出时建
├── board/         # 按需，change 看板 stub（sync.obsidian（或存量 board.enabled）启用时由 eo-sync 投影维护）
├── research/      # 按需，调研沉淀（带 INDEX + frontmatter；eo-recall / eo-change 事实自查消费）
└── docs/          # 按需，原始 PRD / 设计 / 规划
```

`.eo-project/`（即 `project_root`）**缺省随仓库提交**——管理侧是协作者最需要的项目记忆；用户明确不想提交时才追加进 `.gitignore`。

# Handbook 模板机制

`eo-doc/agent-handbook/` 的篇目内容从模板生成：一套模板 = 一个 preset 目录，init 按项目信号匹配候选，用户确认后合并生成。handbook 定位：规范性、方向性、非 SSOT（代码为准）、不挂自动同步。

## 两个库

| 库 | 位置 | 来源 |
|----|------|------|
| 内置库 | `eo-project-init/templates/handbook/<preset>/` | 随整套 skill 软链分发 |
| 私有库 | `"${EO_HOME:-$HOME/.eo}/handbook-templates/<preset>/"` | 用户手工维护 |

同名 preset **私有库整套覆盖内置库**（按 preset 粒度替换，不做文件级合并）。

## 一套 preset 的结构

```
<preset>/
├── manifest.md   # frontmatter 声明适用信号与简介
├── INDEX.md      # handbook 索引（篇目表 + 待补区）
└── <篇目>.md     # 篇目文件组
```

`manifest.md` frontmatter：

```yaml
---
name: general             # preset 名，与目录名一致
summary: 一句话简介        # 封闭选择时展示给用户
signals: []               # 适用信号：相对仓库根的文件路径或 glob 列表
---
```

- signals 逐条在仓库根探测：文件路径存在、或 glob 有匹配，任一命中即该 preset 成为候选
- **空 signals 不参与命中**，仅在无其他候选时作为缺省候选

## 匹配与生成

**已有项目**（生成 = 匹配合并，不是裸 copy）：

1. 五面扫描（lint/commit 配置、`git log` 归纳的 commit 规律、目录结构、架构分工、UI token 用法）产出实证
2. 取两个库的 preset 集合（同名取私有库版本），按 signals 命中候选
3. 按封闭选择协议确认用哪套（含「不用模板」——纯按实证落盘）
4. 合并生成：实证 > 模板 > 待补——模板篇目为底，扫描实证覆盖冲突项，扫描不到依据的标「待补」；已配置文件化的只落一行指针（指向配置文件）
5. worktree 协作与 codegraph 使用两篇逐个询问授权后才写入（comments 注释纪律随 preset 默认生成；AGENTS.md 注入段有其硬入口指针）

**空项目**：无实证可扫；询问项目类型，选定 preset 纯 copy（「待补」占位随项目成形后补齐）。

# v1 项目迁移子流程（由 1.5 更新/修复分支触发）

> 检测到 v1 痕迹时执行。全程**幂等**、逐项汇报；除明确列出的写入外不动任何存量内容。人类背景版见仓库 docs/migration-v1-to-v2.md（本文件是可执行版，两者以本文件为准）。

## 触发信号（任一命中即进入本流程）

- `eo-doc/dev/` 目录存在（v1 模块维度）
- `.eo-project.json` 的 `kanban_path` 为非 null 字符串
- `<project_root>/log.md` 存在且 `eo-doc/changes/` 不存在
- `<project_root>/backlog.md`（或 backlog/todo.md 等扁平文件）存在且未标注「已迁移」

## 迁移步骤

1. **冻结存量 spec**：对每个 `eo-doc/dev/<module>/spec.md` 与 `spec-history.md`，frontmatter 补 `status: frozen`（已有则跳过）。它们保留作历史参考，v2 任何 skill 不再读写。
2. **建项目级 changes/**：`eo-doc/changes/INDEX.md` 不存在则创建；`seq` 起始号 = 扫描全部 `dev/*/changes/` 取最大 `NNN` + 1（新 change 按 v2 规则：slug 即 id，seq 只是显示别名，见 eo-shared/conventions.md §2）；INDEX 顶部加一行注记「此号之前的历史 change 见 `dev/<module>/changes/`（v1 存量，原地保留）」。
3. **在途 change 盘点**：列出旧目录里 status 非 archived 的 change，逐个告知：「走完余下生命周期即可（implement/test/review 照旧），**归档按现行 `/eo-archive` 执行**——不合并 Delta，直接结算 commit + 冻结」。不迁移文件位置。
4. **kanban 退役**：`kanban_path` 非 null → 改写为 `null`，提示「旧手工看板已退役，看板文件（如 00-Wiki/项目看板.md 中本项目条目）可自行归档删除；项目级总览改由 Bases 聚合 roadmap frontmatter」。
5. **roadmap frontmatter 补齐**：`roadmap.md` 缺 `status` / `phase` / `summary` 字段的，从正文推断补写（推断不出的问一次）；`status` 枚举 `active | researching | paused | done`。
6. **log.md 处置**：存在则提示「v2 不再写入 log.md，时间线由 changes/INDEX + git log 承担；文件可留存或归档」，不删除。
7. **lessons 存量**：`lessons/` 有文件但无 INDEX.md → 提示「跑 `/eo-project-record` 的 reindex 补建检索锚点与索引」；decisions/ 同理。
8. **backlog 打散**：存在旧扁平 `backlog.md`（或 backlog/todo.md 等）→ 按 /eo-backlog 的 migrate 动作把未完成条目打散成卡片（created 取原日期、行内 #tag 转 tags），已完成/放弃条目留存原文件，原文件顶部标注「已迁移」。

## 收尾

汇报迁移清单（冻结 N 个 spec / changes 起始编号 / 在途 change 数 / kanban 状态 / roadmap 补了什么），然后**继续 1.5 分支的常规步骤**（配置校验、骨架补齐、注入刷新、gitignore 核对、sync 联动问答）。

# Roadmap 拆解方法论

当 `eo-project-init` 需要从 PRD/MVP 文档或口头描述拆解出 roadmap 和 phase 时，读取本文件指导拆解过程。

---

## 核心取向：阶段性可验收

拆 phase 时手里只有一把尺子：**每个阶段结束时，用户能验收什么。**

验收的意思是：有人能打开真实界面、做一次真实操作、看到一个完整场景从头到尾跑通——哪怕这个场景很窄。做商城，先把"商品目录"从前端到后端打通（API 可以是 mock 的），能浏览、能点进去看详情，这就是一个可验收的阶段；接着再做"下单"。反过来，"用户体系和权限做完了，用 curl 都能调通"**不是**可验收的阶段——它只证明某一层在动。

判断有没有切对，问一个问题：这个阶段结束时，**验收动作越接近最终用户的真实操作，切得越对；越依赖命令行、测试脚本、API 调试器，越可能是横切了**。横切（把一整层做完再做下一层）是 roadmap 里最贵的错误：进度一直在走，但没有任何时刻能端到端看一眼，所有返工都堆在最后爆发。

这不排斥先后偏重。后端可以比前端先走半个身位，框架和骨架可以先搭——但骨架的验收物是"能打开的页面"，不是"配好的脚手架"；层与层的差距以"一个阶段内能合拢"为限。超出这个差距的领先不是进度，是库存。

---

## 拆解思维框架

### 第零步：前提质询

动手拆之前，先回头质疑需求本身：

1. **还原根本问题**：把「要做 X」还原成「要解决 Y」——X 是某人已经给好的解法，Y 才是拆解的输入。问：这个需求背后，用户真正痛的是什么？
2. **审计隐含前提**：需求陈述里藏着哪些假设（用户真的需要、现有能力撑不住、必须现在做、必须自己造）？逐条问「这个前提有证据吗」
3. **消解优先**：能不能不做、用现有能力拼、或改流程而不是造系统？最好的拆解是让需求变小的拆解

质询不落文档，落的是拆解起点的修正——前提站不住时，把疑问按提问纪律抛回用户，钉完再拆。

### 第一步：明确终态

在动手拆之前，先回答一个问题：

> **这个项目做完，用户能做到什么之前做不到的事？**

不是"实现了什么功能"，而是"改变了什么行为/能力"。这决定了 roadmap 的终点。

示例：
- ❌ "完成小程序开发" → 太模糊
- ✅ "用户能通过微信搜索找到我的小程序并付费使用" → 明确的终态

### 第二步：逆向拆解里程碑

从终态往回推，找出 **必须经过的中间状态**（里程碑），每个里程碑是一个可验证的"能做到"：

```
终态：用户付费使用
  ← 里程碑 3：有用户来（流量获取）
    ← 里程碑 2：能被找到（上线发布）
      ← 里程碑 1：能跑起来（MVP 可用）
        ← 起点：有想法
```

**里程碑的标准**：
- 可以 demo / 可以截图 / 可以测量——demo 的主角是用户不是工程师，能截图的是界面不是终端
- 不依赖后续里程碑就有独立价值——价值对用户可见，不是只对架构可见
- 如果项目在这里停下，之前的工作不浪费

### 第三步：里程碑 → Phase

每个里程碑对应一个 Phase。Phase 数量控制在 **2-5 个**：

| 数量 | 判断 |
|------|------|
| 只有 1 个 | 项目太小，不需要 roadmap，直接做 |
| 2-3 个 | 正常项目 |
| 4-5 个 | 大项目，检查是否能合并 |
| >5 个 | 太细了，合并或拆成多个项目 |

### 第四步：Phase 内任务拆解

每个 Phase 内部拆任务，遵循 **MECE 原则**（互不重叠、完全穷尽）：

1. **先列交付物**：这个 Phase 结束时，产出什么？
2. **再列依赖链**：要产出这些，必须先做什么？
3. **最后排序**：有依赖关系的按序，无依赖的并行标注

任务粒度标准：
- **太粗**："开发后端" → 拆
- **刚好**："实现用户登录接口" → ✅
- **太细**："写第 3 行代码" → 合并

经验法则：每个任务 **0.5-2 天**可完成。

---

## 拆解质量检查

拆完后，过一遍检查清单：

### Roadmap 层面
- [ ] 终态清晰，一句话能说明白
- [ ] Phase 之间有明确的先后依赖（不是随意排序）
- [ ] 每个 Phase 独立可交付（如果后面不做了，前面的成果仍有价值）
- [ ] 总 Phase 数 2-5 个

### Phase 层面
- [ ] 每个 Phase 有明确的"完成标志"（怎么判断这个阶段做完了）
- [ ] 任务清单覆盖了所有交付物所需的工作
- [ ] 没有"万能任务"（如"其他工作"、"收尾"）
- [ ] 每个任务 0.5-2 天粒度

### 常见陷阱
- **横切（最贵）**：按层拆——"先做完用户体系/安全/权限，再做业务功能"。进度一直在走，但没有任何时刻能端到端验收，前端长期空壳、返工堆在最后爆发 → 按完整场景切，每层只做到支撑当前场景所需的厚度
- **前期堆积**：把所有"基础设施"放 Phase 1 → 用户迟迟看不到价值（横切的变种）
- **平行铺开**：所有功能同时推进 → 没有一个先完整可用
- **完美主义**：Phase 1 就想做到 100% → MVP 思维缺失

---

## 拆解对话流程

**有 UI 的项目，开拆之前先建议把"长什么样"钉下来**：花一轮建立 design token 和高保真对比稿（走 `/eo-design` variants 出 HTML 对比页），把 UI/UX 操作方式用图钉死再拆——一张对比图暴露的分歧比十轮文字描述多；而且前端定下来之后，后端要支撑哪些操作、什么数据形态往往会自己浮出来，拆解的输入从猜测变成事实。这是建议不是前置：纯后端/工具类项目没有这一步，UI 方向已经很稳的也可以直接拆。

与用户对话时的节奏：

### 1. 确认终态（1 轮）
> "这个项目做完，你希望达到什么效果？"

### 2. 逆推里程碑（1-2 轮）
> "要达到这个效果，之前必须先做到什么？再往前呢？"

展示逆推出的里程碑链，让用户确认。

### 3. 展示 Phase 划分（1 轮）
> 根据里程碑生成 Phase 表格：

```markdown
| Phase | 目标 | 交付物 | 预估时间 |
|-------|------|--------|----------|
| 1 - MVP | 核心功能可用 | 可运行的最小版本 | 1-2 周 |
| 2 - 上线 | 用户可访问 | 备案 + 审核通过 | 1-3 周 |
| 3 - 增长 | 有人用 | 引流内容 + 数据验证 | 2-4 周 |
```

### 4. 确认后拆任务（1 轮）
> 逐个 Phase 展开任务清单，格式用 `- [ ]`。

### 5. 用户确认 → 写入文件

**整个过程不超过 5 轮对话**。避免过度讨论——先落地，再迭代。

---

## 不同项目类型的拆解模板

### 软件产品
```
Phase 1: MVP（核心功能跑通）
Phase 2: 合规上线（备案/审核/发布）
Phase 3: 增长验证（获客 + 数据反馈）
Phase 4: 迭代优化（基于数据改进）
```

### 内容/课程项目
```
Phase 1: 框架设计（大纲 + 前 N 节内容）
Phase 2: 内容生产（完成全部内容）
Phase 3: 分发上线（平台发布 + 推广）
```

### 调研/学习项目
```
Phase 1: 信息收集（素材 + 对标分析）
Phase 2: 知识整理（结构化 + 提炼）
Phase 3: 输出成果（报告/文章/分享）
```

### 自动化/工具项目
```
Phase 1: 手动验证（人工跑通流程）
Phase 2: 半自动化（脚本辅助核心步骤）
Phase 3: 全自动化（端到端无人值守）
```

---
type: phase
project: "{{project_name}}"
phase: {{phase_number}}
status: "{{phase_status}}"
created: "{{date}}"
updated: "{{date}}"
---

# Phase {{phase_number}}：{{phase_name}}

## 目标

{{phase_goal}}

## 验收画面

{{这个阶段结束时，用户能打开什么、操作什么、看到什么——一句话}}

## 任务

{{task_checklist}}

## 交付物

{{deliverables}}

---
type: roadmap
project: "{{project_name}}"
status: "{{status}}"        # active | researching | paused | done —— Bases 项目总览按此聚合
phase: "{{当前阶段一句话}}"
summary: "{{项目目标一句话}}"
created: "{{date}}"
updated: "{{date}}"
---

# {{project_name}}

## 目标

{{project_goal}}

## 阶段概览

| 阶段 | 目标 | 交付物 | 状态 |
|------|------|--------|------|
{{phase_table}}

## 备注

{{notes}}