dbtool-cli-v1/plans/2026-03-26-dbtool-tui-v1-delivery-tracking.md

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 依赖

已完成的第一阶段输入 / shell / shared app 基线
                    ↓
           CMP-33 + CMP-38
             ↙          ↘
         范围拆分      状态同步
              \        /
                CMP-34
                   ↓
                CMP-35
                   ↓
                CMP-36
                   ↓
                CMP-37

当前真实跨项目依赖

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 决策的点。