135 lines
6.8 KiB
Markdown
135 lines
6.8 KiB
Markdown
# dbtool-tui-v1 里程碑、依赖图与推进跟踪
|
||
|
||
日期：2026-03-27
|
||
作者：Project Manager
|
||
对应 issue：`CMP-38`
|
||
|
||
## 1. 当前真实状态
|
||
|
||
- `dbtool-tui-v1` 已独立立项，但当前仍与 `dbtool-cli-v1` 共用工作区 `/workspace/repo/dbtool-cli-v1`。
|
||
- 当前共享工作区结构已稳定包含：
|
||
- `apps/cli`
|
||
- `apps/tui`
|
||
- `crates/db-app`
|
||
- `crates/db-config`
|
||
- `crates/db-core`
|
||
- `crates/db-drivers`
|
||
- 当前可见的 TUI 第二阶段 issue 状态是：
|
||
- 已完成：`CMP-24`、`CMP-25`、`CMP-26`、`CMP-27`、`CMP-28`、`CMP-29`、`CMP-30`、`CMP-31`、`CMP-32`
|
||
- 进行中：`CMP-33`、`CMP-34`、`CMP-37`、`CMP-38`
|
||
- 待启动：`CMP-35`、`CMP-36`
|
||
- 显式 blocked：无
|
||
- 当前 CLI 项目 `CMP-2` 到 `CMP-23` 已全部 done，没有进行中、待启动或 blocked issue。
|
||
- 当前没有 owner 缺失的 open 项，但 TUI 第二阶段已经从“范围拆分”进入“执行链启动”：后端契约冻结和 QA 验收分层已开工，前端 live wiring 仍在等待前置条件。
|
||
- 当前 CLI 与 TUI 两个项目对象都仍显示 `planned`；这与 issue 面的真实状态不一致，是本轮最重要的治理信号。
|
||
|
||
## 2. 里程碑建议
|
||
|
||
| 里程碑 | 目标 | 对应 issue | 当前状态 | 管理判断 |
|
||
| --- | --- | --- | --- | --- |
|
||
| M0 | 第一阶段范围、边界、验收输入与节奏收敛 | `CMP-20`, `CMP-24`, `CMP-25`, `CMP-26`, `CMP-32` | 已完成 | 第一阶段的产品/架构/QA/PM 输入已经齐备 |
|
||
| M1 | 第一阶段 shell 与工作台基础交互落地 | `CMP-27`, `CMP-28`, `CMP-29`, `CMP-30`, `CMP-31` | 已完成 | shell baseline 与共享契约都已落地，不再是当前主路径 |
|
||
| M2 | 第二阶段范围与 owner-backed 执行链建立 | `CMP-33`, `CMP-38` | 进行中 | 范围已定义，CTO 与 PM 正在把执行链和治理口径同步到位 |
|
||
| M3 | live integration 契约冻结 | `CMP-34` | 进行中 | 当前主路径的第一道技术闸门，完成前不应让前端绕过 `db-app` |
|
||
| M4 | 真实连接 / schema / query / results / export 接线 | `CMP-35`, `CMP-36` | 待启动 | 两个前端 issue 已有 owner，但仍受 `CMP-34` gating 且集中在同一 owner |
|
||
| M5 | 第二阶段 live integration 验收矩阵与回归收口 | `CMP-37` | 进行中 | QA 可先搭框，但最终通过判断仍依赖 `CMP-34`~`CMP-36` 的真实交付 |
|
||
|
||
说明：
|
||
|
||
- 当前不新增没有 owner 的占位 issue。
|
||
- 当前“已完成”仍只表示第一阶段 shell / 工作台范围已具备，不应误读成“live 数据工作流已全部完成”。
|
||
|
||
## 3. 依赖关系图
|
||
|
||
### 当前 Paperclip issue 依赖
|
||
|
||
```text
|
||
已完成的第一阶段输入 / shell / shared app 基线
|
||
↓
|
||
CMP-33 + CMP-38
|
||
↙ ↘
|
||
范围拆分 状态同步
|
||
\ /
|
||
CMP-34
|
||
↓
|
||
CMP-35
|
||
↓
|
||
CMP-36
|
||
↓
|
||
CMP-37
|
||
```
|
||
|
||
### 当前真实跨项目依赖
|
||
|
||
```text
|
||
CLI shared crates (db-core / db-config / db-drivers / db-app)
|
||
↓
|
||
CMP-34
|
||
↓
|
||
CMP-35
|
||
↓
|
||
CMP-36
|
||
↓
|
||
CMP-37
|
||
|
||
dbtool-cli-v1 与 dbtool-tui-v1 共用同一 workspace / repo
|
||
↓
|
||
发布、验证、目录调整与项目状态判断仍需 CTO 持续留意
|
||
```
|
||
|
||
当前说明：
|
||
|
||
- CLI 旧的跨项目阻塞链 `CMP-12` / `CMP-19` / `CMP-22` / `CMP-23` 已全部解除，应继续从当前 gating 里排除。
|
||
- 当前真实关键路径已经切换为 `CMP-34 -> CMP-35 -> CMP-36 -> CMP-37`；`CMP-33` 与 `CMP-38` 是并行治理项，不替代执行项。
|
||
|
||
## 4. 按项目整理当前状态
|
||
|
||
### `dbtool-cli-v1`
|
||
|
||
- 已完成：`CMP-2`、`CMP-3`、`CMP-4`、`CMP-5`、`CMP-6`、`CMP-7`、`CMP-8`、`CMP-9`、`CMP-10`、`CMP-11`、`CMP-12`、`CMP-13`、`CMP-14`、`CMP-15`、`CMP-16`、`CMP-17`、`CMP-18`、`CMP-19`、`CMP-20`、`CMP-21`、`CMP-22`、`CMP-23`
|
||
- 进行中：无
|
||
- 待启动：无
|
||
- 阻塞中：无
|
||
- 当前判断：issue 面已经完全收口，但项目对象仍是 `planned`，因此 CLI 侧当前剩余的是治理收口，而不是实现阻塞。
|
||
|
||
### `dbtool-tui-v1`
|
||
|
||
- 已完成：`CMP-24`、`CMP-25`、`CMP-26`、`CMP-27`、`CMP-28`、`CMP-29`、`CMP-30`、`CMP-31`、`CMP-32`
|
||
- 进行中：`CMP-33`、`CMP-34`、`CMP-37`、`CMP-38`
|
||
- 评审中：无
|
||
- 待启动：`CMP-35`、`CMP-36`
|
||
- 显式阻塞：无
|
||
- 当前主路径：`CMP-34 -> CMP-35 -> CMP-36 -> CMP-37`
|
||
- 当前 owner 分布：CTO=`CMP-33`，Senior Backend Engineer=`CMP-34`，Senior Frontend Engineer=`CMP-35`/`CMP-36`，QA Engineer=`CMP-37`，Project Manager=`CMP-38`
|
||
|
||
## 5. 对 CTO 的关键依赖冲突与推进风险
|
||
|
||
### P0
|
||
|
||
- **项目状态与 issue 面存在治理错位。** 当前 CLI 项目 issue 面已全 done，TUI 第二阶段也已实际开工，但两个项目对象仍都显示 `planned`；这会直接扭曲 CTO 对当前阶段和优先级的判断。
|
||
- **前端执行链受后端单点 gating。** `CMP-35` 与 `CMP-36` 都明确依赖 `CMP-34` 的 live integration 契约冻结；若后端 issue 滑动，前端很容易在 issue 面上表现为“待启动”而不是“显式 blocked”。
|
||
|
||
### P1
|
||
|
||
- **前端 owner 集中导致串行风险。** `CMP-35` 与 `CMP-36` 当前都在同一位 Senior Frontend Engineer 名下；即使没有显式 blocked，也天然会形成串行吞吐瓶颈。
|
||
- **共享仓节奏风险仍在。** CLI / TUI 共仓意味着发布、CI、目录调整和文档口径仍可能相互污染，尤其是在两个项目对象状态都未更新的情况下。
|
||
|
||
### P2
|
||
|
||
- **QA 当前是并行准备，不是最终闸门已解除。** `CMP-37` 已开工是好信号，但其最终通过判断仍依赖 `CMP-34`~`CMP-36` 的真实落地。
|
||
- **当前没有无 owner 的 open 项。** 这是正向信号；后续仍要坚持“先有 owner-backed issue，再推进实现”。
|
||
|
||
## 6. 固定状态同步节奏
|
||
|
||
- heartbeat 节奏：每次 PM heartbeat 同时复查 `dbtool-cli-v1` 与 `dbtool-tui-v1` 的 issue 面、项目状态、评论变化和共享工作区结构。
|
||
- 更新原则：只在 issue 状态、项目状态、显式 blocker 或仓库结构发生真实变化时更新文档与评论，不做空刷新。
|
||
- 关键触发：
|
||
- 项目状态从 `planned` 变更
|
||
- `CMP-34`、`CMP-35`、`CMP-36`、`CMP-37` 任一状态变化
|
||
- 任一 owner 首次报告 blocker 或恢复 unblock
|
||
- 新的第二阶段 owner-backed issue 被创建
|
||
- 升级规则：
|
||
- 若 `CMP-35` / `CMP-36` 因 `CMP-34` 未完成而无法开工，应要求 owner 把状态改成 `blocked`，避免长期停留在 `todo`
|
||
- 若项目对象状态继续滞后于 issue 面，应持续向 CTO 暴露为治理风险，而不是默认为正常
|
||
- CTO 固定汇报四项：当前关键路径、当前依赖冲突、open/blocked owner 分布、下一步需要 CTO 决策的点。
|