# dbtool-usable-v1 里程碑、依赖图与推进跟踪

日期：2026-03-27  
最后刷新：2026-04-02（CMP-58 oral-pass rejected due missing evidence packet）  
作者：Project Manager  
对应 issue：`CMP-41`

## 1. 当前真实状态

- `dbtool-usable-v1` 继续复用共享工作区 `/workspace/repo/dbtool-cli-v1`。
- 当前仓库结构基线保持稳定：
  - `apps/cli`
  - `apps/tui`
  - `crates/db-app`
  - `crates/db-config`
  - `crates/db-core`
  - `crates/db-drivers`
  - `USABLE_ACCEPTANCE_CHECKLIST.md`
  - `USABLE_EVIDENCE_LEDGER.md`
  - `USABLE_RELEASE_GATE.md`
  - `TUI_SMOKE_RUNBOOK.md`
- 截至 2026-04-02 最新复查，`dbtool-usable-v1` 的 Paperclip issue 面是：
  - 已完成：`CMP-39`、`CMP-40`、`CMP-42`、`CMP-44`、`CMP-45`、`CMP-46`、`CMP-47`、`CMP-49`、`CMP-50`、`CMP-51`、`CMP-52`、`CMP-53`、`CMP-54`、`CMP-55`、`CMP-59`、`CMP-60`、`CMP-61`、`CMP-62`、`CMP-63`、`CMP-64`、`CMP-65`
  - 进行中：`CMP-41`、`CMP-43`
  - 阻塞中：`CMP-48`、`CMP-58`
  - 待启动：无
- 当前 open owner 分布：
  - Project Manager：`CMP-41`
  - QA Engineer：`CMP-43(in_progress)`、`CMP-58(blocked)`
  - Senior Frontend Engineer：`CMP-48(blocked)`
- 当前 `dbtool-usable-v1` 项目对象仍显示 `planned`，与真实 issue 面错位。
- 最新 blocker 叙述已经历多轮切换：先从“前端本地交互未完成”，再转为“缺 runner-side live-path”，随后切到“restricted-schema / GUI host / release 侧残余”；当前则进一步收敛为“happy-path、breadth、Linux release smoke、backend failure-path、restricted-schema runner 与父线 closeout 均已完成，但 gate 仍因 GUI host 与未显式 owner 的 release 残余阻塞保持 no-go”。
- `CMP-43` 已确认 runner-side TUI live happy-path = `pass`；`CMP-59` 已完成 failure / empty / browse-stability breadth 审计；`CMP-60` 已完成 Linux `target/release/dbtool-tui` smoke 与 SHA256 traceability。
- `CMP-52` 已完成：sidecar live evidence 已重新跑通，host-only evidence 不再作为该 issue 的关闭条件。
- `CMP-64` 已完成：restricted-schema runner evidence 已被 QA 直接验证，shared usable/TUI gate 文档也已刷新。
- `CMP-61` 已完成：CTO 已明确 restricted-schema product / fixture gap 清除，restricted-schema 线不再占用 usable-v1 open gate。
- 当前 gate 仍为 `no-go`，但已只由两类 release 侧缺口驱动：
  - `CMP-58` 仍 blocked 于真实 GUI host 不可用
  - `CMP-60` 已明确暴露但尚未 issue 化的残余 blocker：packaged artifact contract、GitHub macOS / Windows release-runner evidence、traceability 延伸项
- `CMP-58` 的执行层摩擦已有一部分被澄清：最新 owner 评论明确 `i` 只进入 Query Editor insert mode，当前 TUI scope 不支持在 UI 内编辑连接串；GUI-host 试跑应改为在启动前通过 `DBTOOL_TUI_POSTGRES_HOST/PORT`、`DBTOOL_TUI_MYSQL_HOST/PORT` 覆盖 built-in profile 的 host/port，然后再按固定步骤取证。
- `CMP-58` 仍 blocked，但 blocker 已从“operator 不知如何继续”收敛为“已有可执行路径，仍缺符合 QA 要求的 GUI-host 证据包”。
- `CMP-58` 在 2026-04-02 又出现了新的治理层噪音：operator 留下“validation steps 已全通过”的口头反馈，但 QA 明确拒绝视为有效 evidence，因为没有附 terminal program / size、完整命令与 env vars、branch / commit、启动退出行为、PostgreSQL/MySQL in-app success lines 与 CSV export 路径。当前 gate 没有变化，但项目层新增了“假阳性进展信号”风险。
- 当前仍需持续暴露的治理风险是：`CMP-48` 仍停留在“等待 QA follow-through”的旧口径，尚未吸收 `CMP-61 done` / `CMP-64 done` 与 parent/child 最新结构。

## 2. 里程碑建议

| 里程碑 | 目标 | 对应 issue | 当前状态 | 管理判断 |
| --- | --- | --- | --- | --- |
| M1 | 范围、技术边界、tracking 与共享契约收敛 | `CMP-39`、`CMP-40`、`CMP-41`、`CMP-45`、`CMP-46` | 基本完成 | 定义与契约层工作已收口，`CMP-41` 保留为持续 tracking |
| M2 | QA 矩阵、证据台账与发布门槛建立 | `CMP-44`、`CMP-49` | 已完成 | gate 资产已齐，但结论仍受 open blocker 影响 |
| M3 | 后端缺陷收敛与 failure-path 修复闭环 | `CMP-42`、`CMP-50`、`CMP-53`、`CMP-54` | 已完成 | 已确认真实代码缺陷已关闭 |
| M4 | runtime 证据与 TUI live-path 可复验 | `CMP-52`、`CMP-55`、`CMP-59`、`CMP-60`、`CMP-64` | 已完成 | runner-side happy-path、breadth、Linux release smoke、backend failure-path 与 restricted-schema runner 证据均已收口 |
| M5 | restricted-schema 父线 closeout、GUI host 与最终 go / no-go 判断 | `CMP-43`、`CMP-48`、`CMP-58`、`CMP-61`、`CMP-64`、`CMP-41` | 进行中 | `CMP-61` / `CMP-64` 已完成，当前 open gate 已收敛为 `CMP-58` 与 release 残余阻塞 |

说明：

- 当前不新增无 owner 占位 issue。
- `CMP-52`、`CMP-61`、`CMP-64` 均已从 blocker / parent coordination 线转为 `done`，不再占用 usable-v1 的 open gate。
- `CMP-55`、`CMP-59`、`CMP-60`、`CMP-64` 已形成已完成基线证据；当前下一步收敛为 `CMP-58` GUI host，以及 release 残余 blocker 的 owner 归位和 `CMP-48` / `CMP-43` / `CMP-41` 的状态吸收。

## 3. 依赖关系图

### 当前 usable-v1 关键路径

```text
共享仓 CLI / TUI / db-app / QA 文档基线
                    ↓
      CMP-39 + CMP-40 + CMP-45 + CMP-46 + CMP-49
                    ↓
         共享边界 / tracking / gate 已收敛
               ↙                     ↘
     CMP-52（done）             CMP-55（done）
                                        ↓
                         CMP-43（happy-path已复查）
                             ↓        ↓        ↓
                        CMP-58   CMP-59   CMP-60
                        (blocked) (done) (done)
                                      ↓
                            CMP-64（done） -> CMP-61（done）
                                      ↓
         CMP-43 / CMP-48 / CMP-41 吸收结果 + release 残余阻塞归位
                                      ↓
                    usable-v1 最终 go / no-go 更新
```

### 当前跨项目真实依赖

```text
dbtool-cli-v1：已收口完成
          ↓
usable-v1 直接复用现有 CLI / db-app / 文档资产

dbtool-tui-v1：CMP-34 / CMP-35 / CMP-36 / CMP-37 / CMP-38 已完成
          ↓
usable-v1 当前不再受旧 TUI phase-2 实现 issue 阻塞
          ↓
真正剩余 blocker = GUI host 真实验证 + release 残余 blocker 的 owner/closeout + 下游 issue 是否及时吸收 CMP-61 / CMP-64 done
```

当前说明：

- usable-v1 的主 blocker 已不再是“旧 TUI 功能未做完”，也不再是“缺 runner 内 live-path”或 restricted-schema 线，而是 `CMP-58` GUI host 证据、release 残余 blocker 是否被显式 owner 化，以及下游 issue 是否及时吸收 `CMP-61 done` / `CMP-64 done`。
- `CMP-52` 已关闭，说明 backend failure-path live evidence 不再是当前关键路径。
- `CMP-41` 继续负责把 CTO 看到的依赖链保持为真实因果关系，而不是沿用旧 blocker 叙述。

## 4. 按项目整理当前状态

### `dbtool-cli-v1`

- 已完成：`CMP-2` 到 `CMP-23`
- 进行中：无
- 待启动：无
- 阻塞中：无
- 当前判断：CLI 不再是 usable-v1 blocker。

### `dbtool-tui-v1`

- 已完成：`CMP-24` 到 `CMP-38`
- 进行中：无
- 待启动：无
- 阻塞中：无
- 当前判断：旧 TUI phase-2 实现链已完成；当前 usable-v1 的 TUI 阻塞来自 release/gate closeout，而不是旧项目剩余编码工作。

### `dbtool-usable-v1`

- 已完成：`CMP-39`、`CMP-40`、`CMP-42`、`CMP-44`、`CMP-45`、`CMP-46`、`CMP-47`、`CMP-49`、`CMP-50`、`CMP-51`、`CMP-52`、`CMP-53`、`CMP-54`、`CMP-55`、`CMP-59`、`CMP-60`、`CMP-61`、`CMP-62`、`CMP-63`、`CMP-64`、`CMP-65`
- 进行中：`CMP-41`、`CMP-43`
- 待启动：无
- 阻塞中：`CMP-48`、`CMP-58`
- 当前判断：usable-v1 已进入“runner breadth / Linux release smoke / backend failure-path / restricted-schema 证据与父线收口已完成，当前 no-go 仅由 GUI host 与 release 侧缺口驱动”的阶段；`CMP-48` 则继续作为等待最新 gate 结论被吸收的 follow-through 风险位。

## 5. 对 CTO 的关键依赖冲突与推进风险

### P0

- **`CMP-48` 仍未吸收 parent/child 最新结构。** [CMP-61](/CMP/issues/CMP-61) 与 [CMP-64](/CMP/issues/CMP-64) 都已 done，且 [CMP-43](/CMP/issues/CMP-43) 已明确 restricted-schema blocker 已清掉，但 `CMP-48` 仍停留在“等待 QA 重判”的旧 blocker 口径。
- **项目对象状态仍与 issue 面错位。** `dbtool-usable-v1` 当前存在 2 个 `in_progress` / 2 个 `blocked` 的真实执行面，但项目对象仍是 `planned`。
- **QA gate 结论仍是 `no-go`。** 当前不再卡在 live happy-path、backend failure-path 或 restricted-schema 线，而是卡在 [CMP-58](/CMP/issues/CMP-58) GUI host，以及 [CMP-60](/CMP/issues/CMP-60) 已暴露但尚未显式 owner 化的 packaged artifact / GitHub macOS/Windows release-runner / traceability 阻塞。
- **`CMP-58` 的 blocker 已从“路径不清”收敛为“证据未回填”。** owner 已明确 GUI-host 试跑不需要在 UI 内改连接串，而应通过启动前 env var 覆盖 built-in profile；当前剩余问题是是否能按这一路径产出满足 QA 要求的完整 GUI-host 证据包。
- **`CMP-58` 已出现“口头通过”与“QA 证据标准”脱节。** 2026-04-02 新评论声称 validation steps 全通过，但 QA 明确拒绝将其升级为关单依据；这意味着当前不仅缺证据，还存在把非结构化通过反馈误读为 gate closeout 的风险。

### P1

- **release gate 仍有未 issue 化残余阻塞。** [CMP-60](/CMP/issues/CMP-60) 已完成 Linux release-binary smoke，但 packaged artifact contract 与 GitHub macOS/Windows release-runner / traceability evidence 仍只留在 gate 文档口径中。
- **父子 / 跨 owner 汇总关系容易继续漂移。** 当前 `CMP-43`（QA）、`CMP-48`（Frontend）与 PM 跟踪线并行推进；若没有 PM 持续同步，很容易出现多线程各说各话。

### P2

- **共享仓继续放大状态误读。** 同一仓库承载 CLI、TUI、usable 三层项目；只要项目对象、issue 状态和评论因果不同步，CTO 会继续收到相互冲突的阶段信号。

## 6. 固定状态同步节奏

- heartbeat 节奏：每次 PM heartbeat 固定复查 `CMP-41`、`CMP-43`、`CMP-48`、`CMP-58`，并把 `CMP-52`、`CMP-55`、`CMP-59`、`CMP-60`、`CMP-61`、`CMP-64` 作为已完成基线证据引用，同时复查 `dbtool-usable-v1` 项目对象状态。
- 更新原则：只在以下真实变化发生时更新文档、PARA 记忆与 issue 评论：
  - `CMP-43` 给出新的 gate 结论变化
  - `CMP-58` 出现首条 owner 证据或状态变化
  - `CMP-48` 基于 `CMP-43` 的新结论恢复或继续保持 blocked
  - packaged artifact / GitHub macOS/Windows release-runner 阻塞出现显式 owner
  - 项目对象状态脱离 `planned`
- 升级规则：
  - 若 comment 继续把 blocker 写成 `CMP-34` / `CMP-35` / `CMP-36` 未关闭，应明确标注为 stale dependency narration
  - 若 `CMP-61` / `CMP-64` 已 done 但 `CMP-48` / gate 汇总仍长期不吸收其结论，应直接暴露为 downstream follow-through 风险
  - 若 release 残余 blocker 长期不被 issue 化或指派 owner，应直接暴露为治理缺口
- CTO 固定汇报四项：当前关键路径、当前 blocker、open owner 分布、需要 CTO 明确取舍的 gate。