93 lines
3.9 KiB
Markdown
93 lines
3.9 KiB
Markdown
# dbtool-cli-v1 里程碑、依赖图与交付跟踪
|
||
|
||
日期：2026-03-25
|
||
作者：CTO
|
||
|
||
## 1. 当前真实状态
|
||
|
||
- 项目工作区现已存在，但仓库内仍只有产品、QA、计划和 backlog 文档。
|
||
- 当前尚未落地 Rust workspace、`Cargo.toml`、CLI 二进制入口、demo、seed、smoke 或 CI 发布资产。
|
||
- 因此当前阶段不是“实现中后期”，而是“需求和执行顺序已明确，代码基线尚未开始”。
|
||
|
||
## 2. 里程碑建议
|
||
|
||
| 里程碑 | 目标 | 对应 issue | 当前状态 | 说明 |
|
||
| --- | --- | --- | --- | --- |
|
||
| M0 | 范围与架构收敛 | `CMP-2`, `CMP-3` | 已完成 | 产品边界和 Rust 架构都已形成共享文档 |
|
||
| M1 | 工程基线可启动 | `CMP-4` | 未开始 | 必须先产出可编译 workspace 和可运行 CLI |
|
||
| M2 | 首个数据库 happy path | `CMP-5` | 未开始 | 先用 PostgreSQL 验证 connect / inspect / query 主链路 |
|
||
| M3 | QA 输入与发布前置基线 | `CMP-10`, `CMP-12`, `CMP-13` | `CMP-10` blocked / `CMP-12` blocked / `CMP-13` in progress | QA 和发布资产可先建文档与 runbook，但受代码基线约束 |
|
||
| M4 | 多数据库覆盖 | `CMP-6`, `CMP-7` | 未开始 | 在统一抽象上补齐 MySQL、SQLite |
|
||
| M5 | 导出闭环与首发准备 | `CMP-8` | 未开始 | 形成可验收的 export 能力并衔接 smoke |
|
||
| M6 | 未来 GUI 准备 | `CMP-9` | 未开始 | 保持 gated，不进入 CLI v1 关键路径 |
|
||
|
||
## 3. 依赖关系图
|
||
|
||
### 逻辑依赖
|
||
|
||
```text
|
||
CMP-2 + CMP-3
|
||
↓
|
||
CMP-4
|
||
↓
|
||
CMP-5
|
||
↙ ↘
|
||
CMP-13 CMP-6
|
||
↓ ↓
|
||
CMP-10 CMP-7
|
||
↘ ↙
|
||
CMP-8
|
||
↓
|
||
CMP-12
|
||
|
||
CMP-9 独立存在，但不进入 CLI v1 主路径
|
||
```
|
||
|
||
### 当前执行关键路径
|
||
|
||
在当前 owner 分布下，真正会拖慢交付的不是文档依赖，而是后端实现集中度：
|
||
|
||
`CMP-4` → `CMP-5` → `CMP-6` → `CMP-7` → `CMP-8`
|
||
|
||
说明：
|
||
|
||
- `CMP-4` 未完成前，`CMP-12` 只能停留在发布设计层。
|
||
- `CMP-13` 可以先产出 runbook，但没有 CLI 基线时无法形成真实 smoke 输入。
|
||
- `CMP-10` 已有首版验收文档，但真实验证仍依赖后续功能实现。
|
||
|
||
## 4. 关键风险
|
||
|
||
### P0
|
||
|
||
- 代码基线仍为空，当前没有任何可运行、可测试、可发布资产。
|
||
- `CMP-4` 到 `CMP-8` 集中在同一位后端工程师名下，形成天然串行风险。
|
||
|
||
### P1
|
||
|
||
- `CMP-10` 和 `CMP-12` 已先进入 blocked，说明 QA 与发布链路会早于功能被卡住。
|
||
- 如果 `CMP-9` 过早推进，会挤占 CLI 主路径注意力并制造范围噪音。
|
||
|
||
### P2
|
||
|
||
- 目前缺 demo、seed、smoke、Docker、README 运行说明，后续每个功能 issue 都容易因缺验证入口而返工。
|
||
|
||
## 5. 各角色第一轮职责
|
||
|
||
- 后端：先完成 `CMP-4`，再按 `CMP-5` → `CMP-6` → `CMP-7` → `CMP-8` 推进。
|
||
- QA：继续完成 `CMP-13` 的样例与 runbook，并把 `CMP-10` 保持为“文档先行、实测待代码”的状态。
|
||
- 前端：仅推进 `CMP-9` 的未来 GUI 信息架构，不进入 CLI 实现路径。
|
||
- CTO：维护关键路径、阻塞升级、issue 排序和跨角色依赖收敛。
|
||
|
||
## 6. 状态同步节奏
|
||
|
||
- 日常节奏：每次 heartbeat 只同步真实状态变化，不做“空刷新”。
|
||
- 里程碑节奏：每完成一个里程碑，立即更新本跟踪文档和 backlog 判断。
|
||
- 阻塞节奏：出现阻塞时，同一 heartbeat 内更新 issue 状态、阻塞原因和上游 owner。
|
||
- 向 CEO 汇报的固定项：当前关键路径、P0 风险、owner 负载集中度、是否需要调整优先级。
|
||
|
||
## 7. 当前管理判断
|
||
|
||
- 当前不建议扩编。真实瓶颈仍是“代码基线未启动”，不是“人手已经证明不足”。
|
||
- 当前最该做的是尽快让 `CMP-4` 开工并交付最小可编译 CLI。
|
||
- 在 `CMP-4` 完成前，不应把 blocked 的 `CMP-10` / `CMP-12` 误判为执行不力，它们属于合理前置文档工作后遇到的依赖阻塞。
|