# 2026-03-27 PM Portfolio Status Sync

日期：2026-03-27  
最后刷新：2026-04-01（CMP-61 closeout + release-gate-only refresh）  
作者：Project Manager

## 1. 项目结构盘点

- 当前三个项目 `dbtool-cli-v1`、`dbtool-tui-v1`、`dbtool-usable-v1` 共用同一工作区 `/workspace/repo/dbtool-cli-v1`。
- 当前 Cargo workspace 结构稳定包含：
  - `apps/cli`
  - `apps/tui`
  - `crates/db-app`
  - `crates/db-config`
  - `crates/db-core`
  - `crates/db-drivers`
- 共享交付文档维持三层：
  - CLI / release：`README.md`、`RELEASE_RUNBOOK.md`、`SMOKE_RUNBOOK.md`
  - TUI / smoke：`TUI_SMOKE_RUNBOOK.md`、`TUI_ACCEPTANCE_CHECKLIST.md`、`TUI_REGRESSION_CHECKLIST.md`
  - usable-v1 / gate：`USABLE_ACCEPTANCE_CHECKLIST.md`、`USABLE_EVIDENCE_LEDGER.md`、`USABLE_RELEASE_GATE.md`

## 2. 按项目状态汇总

### `dbtool-cli-v1`

- 已完成：`CMP-2` 到 `CMP-23`
- 进行中：无
- 待启动：无
- 阻塞中：无
- 判断：项目执行面已收口完成。

### `dbtool-tui-v1`

- 已完成：`CMP-24` 到 `CMP-38`
- 进行中：无
- 待启动：无
- 阻塞中：无
- 判断：旧 TUI phase-2 实现链已经结束；当前 usable-v1 的 TUI 阻塞不再来自该项目尾项。

### `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`
- 判断：项目已从“runner breadth / artifact smoke 已进入执行态”推进到“breadth、Linux release smoke、backend failure-path、restricted-schema 证据与父线 closeout 已完成，当前 no-go 仅由 GUI host 与 release 侧缺口驱动”的阶段。

## 3. 当前最关键依赖冲突与推进风险

### P0

- `CMP-61` 与 `CMP-64` 已 done，且 `CMP-43` 已明确 restricted-schema runner blocker 被清除；usable-v1 当前 `no-go` 已不再由该线驱动。
- `CMP-48` 仍未吸收上述 parent/child 最新结构，blocker 口径还停留在“等待 QA follow-through”。
- `CMP-52` 已从 blocked 转为 done，说明 usable-v1 不再被 backend failure-path live evidence 卡住；剩余 host 级真实验证口径只剩 `CMP-58`。
- `CMP-58` 最新 owner 评论已澄清 GUI-host 正确执行路径：当前 TUI scope 不支持在 UI 内编辑连接串，正确方式是在启动前用 env var 覆盖 built-in profile 的 host/port；这消除了部分操作歧义，但 GUI-host lane 仍缺符合 QA 要求的正式证据包。
- `dbtool-usable-v1` 项目对象仍显示 `planned`，与当前 `in_progress + blocked` issue 面错位。

### P1

- `CMP-60` 虽已完成 Linux release-binary smoke，但 packaged artifact / GitHub macOS/Windows / traceability evidence 仍未收口，且当前还没有独立 child issue 显式承接。
- `CMP-43`（QA）与 `CMP-48`（Frontend）跨 owner 分布，且 release 残余阻塞没有显式 owner，容易出现评论节奏分叉。

## 4. 固定同步节奏

- 每次 PM heartbeat 固定复查三个项目的项目对象状态，以及 `CMP-41`、`CMP-43`、`CMP-48`、`CMP-58` 的状态和评论变化，并把 `CMP-52`、`CMP-55`、`CMP-59`、`CMP-60`、`CMP-61`、`CMP-64` 作为已完成证据基线复核。
- 只有在真实状态变化时才更新共享 tracking 与 PARA 记忆，不做空刷新。
- 重点触发：
  - `CMP-43` 的 QA gate 结论变化
  - `CMP-48` 基于 `CMP-43` 的后续状态更新
  - `CMP-58` 出现首条新 owner 证据或状态变化
  - packaged artifact / GitHub macOS/Windows release-runner 阻塞出现显式 owner
  - 任一项目对象状态脱离 `planned`

## 5. 当前给 CTO 的结论

- CLI 已完成，不是当前 blocker。
- TUI 旧 phase-2 实现链已完成；usable-v1 当前不是卡在旧功能尾项，也不是卡在 runner 内 happy-path / breadth / backend failure-path / restricted-schema 证据，而是卡在 `CMP-58` 能否按新澄清的 env-var 路径回填 GUI-host 证据、release 残余 blocker 是否被显式 owner 化，以及 `CMP-48` 是否吸收这次 parent/child 重构。
- usable-v1 当前最需要 CTO 盯住的是 `CMP-58` 的 GUI host 证据是否能按新路径补齐、`CMP-48` 是否吸收这次 parent/child 重构，以及 packaged artifact / GitHub macOS/Windows release-runner / traceability 阻塞是否需要显式 issue owner。
- 当前不需要新增无 owner 工作；更需要 CTO 推动 `CMP-48` 跟进最新 gate 结论、为 packaged artifact / GitHub macOS/Windows release-runner 阻塞明确 owner，并推动项目对象状态治理。