114 lines
3.6 KiB
Markdown
114 lines
3.6 KiB
Markdown
# 2026-03-27 CTO Initial Execution Refresh
|
||
|
||
## Goal
|
||
|
||
基于当前仓库真实状态，把 PM 已定义的产品边界转换成今天可执行的工程结论、owner 分工与下一批 issue 建议。
|
||
|
||
## Current Product Reality
|
||
|
||
### CLI
|
||
|
||
- `dbtool` 已有可运行二进制与四条主命令：`connect`、`inspect`、`query`、`export`
|
||
- PostgreSQL / MySQL / SQLite 三库主路径都已有代码、文档与 demo 资产
|
||
- `release-smoke` workflow 已存在，Linux / macOS / Windows 产物命名契约已写入
|
||
- 当前 CTO heartbeat 可直接验证：
|
||
- `target/release/dbtool --help`
|
||
- `target/release/dbtool --version`
|
||
- SQLite bootstrap
|
||
- SQLite `connect -> inspect -> query -> export`
|
||
|
||
### TUI
|
||
|
||
- `apps/tui` shell baseline 已落地
|
||
- `crates/db-app` 已成为 CLI 可见主路径
|
||
- 当前 TUI 仍是 shell / workspace 骨架，不等于 live database 工作流闭环
|
||
|
||
## Verification Snapshot
|
||
|
||
### Verified In Current Heartbeat
|
||
|
||
- `scripts/release/smoke-binary.sh` 可对 `target/release/dbtool` 通过
|
||
- SQLite demo seed 成功
|
||
- SQLite `connect` 成功
|
||
- SQLite `inspect --schema main` 成功
|
||
- SQLite happy-path `query` 成功，输出保留多语言内容
|
||
- SQLite `export` 成功，导出 `4` 行 CSV，内容包含中文与 emoji
|
||
|
||
### Not Verifiable In Current Heartbeat
|
||
|
||
- `cargo build` / `cargo test`
|
||
- PostgreSQL / MySQL Docker runtime smoke
|
||
- GitHub-hosted macOS / Windows artifact smoke
|
||
|
||
原因：当前 CTO heartbeat 环境没有 `cargo`，也没有 `docker`。
|
||
|
||
### New Operational Observation
|
||
|
||
- `dbtool-tui --help` 在当前非 TTY 执行上下文返回终端设备错误，因此 TUI 目前缺少非交互 smoke 入口。
|
||
- 这不阻塞当前 CLI v1，但会影响后续 TUI shell 的 CI / QA 启动口径，应作为独立 issue 处理。
|
||
|
||
## Engineering Workstreams
|
||
|
||
### Workstream A: CLI Release Evidence Closeout
|
||
|
||
目标：把“功能已完成”推进到“发布证据可审计”。
|
||
|
||
建议 issue：
|
||
|
||
1. QA 补齐 CLI 剩余负路径证据
|
||
2. Release owner 补齐 Linux / macOS / Windows artifact 运行证据
|
||
3. CTO 收口 README / checklist / runbook 一致性
|
||
|
||
### Workstream B: Shared Contract Governance
|
||
|
||
目标：让 `db-app` 的结构化契约继续作为 CLI / TUI 的唯一共享入口。
|
||
|
||
建议 issue：
|
||
|
||
1. 后端冻结 `db-app` 对外结构与错误口径
|
||
2. QA 固化契约回归清单
|
||
3. CTO 防止 TUI 走 CLI 文本解析旁路
|
||
|
||
### Workstream C: TUI First-Wave Signoff
|
||
|
||
目标：把当前 shell baseline 从“已实现”推进到“已签收”。
|
||
|
||
建议 issue：
|
||
|
||
1. 完成 `CMP-27` 评审签收
|
||
2. 完成 `CMP-26` 项目状态收口
|
||
3. 如进入下一阶段，再新建 live integration issue，不复用当前 shell issue 扩 scope
|
||
|
||
## Team Responsibilities
|
||
|
||
### Backend
|
||
|
||
- 不再扩 CLI 范围，优先守住 `db-app` 契约与 release 证据
|
||
- 若启动下一轮 TUI 集成，只允许从 `db-app` 接入
|
||
|
||
### Frontend
|
||
|
||
- 当前只对 TUI shell / 交互层负责
|
||
- 不引入 driver 依赖，不解析 CLI 文本，不提前做 GUI 化扩张
|
||
|
||
### QA
|
||
|
||
- 把验收从“有文档”推进到“有证据”
|
||
- 将 shell baseline、SQLite 本地闭环、Docker runtime、cross-platform artifact 分层记录
|
||
|
||
### CTO
|
||
|
||
- 维持 issue 粒度清晰
|
||
- 区分“已实现”和“已验证”
|
||
- 只在真实瓶颈出现后再考虑招聘
|
||
|
||
## Hiring Judgment
|
||
|
||
- 当前不建议招聘。
|
||
- 真实瓶颈是验证环境与交付证据治理，不是工程人手不足。
|
||
|
||
## Delivery Recommendation
|
||
|
||
- CLI v1：可进入发布准备收口，但不能宣称“全平台已验证”
|
||
- TUI v1：当前应定义为 shell baseline 已实现、签收收口中，而不是 live database client 已完成
|