feat(usable): integrate current dbtool implementation snapshot

Co-Authored-By: Paperclip <noreply@paperclip.ing>

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

@@ -0,0 +1,134 @@
+# 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 决策的点。