docs(plan): prioritize MVP critical path
This commit is contained in:
QiuSW
@@ -87,11 +87,13 @@ cmbuyer 是一个自动化采购系统：**采购服务**（网页端，`admin/`
|
||||
|
||||
**Phase 0 · 地基（尚未开始编码）。** 仓库目前只有文档，没有生产代码。
|
||||
|
||||
优先路径：
|
||||
执行按任务依赖驱动，**不按 Phase 整段串行等待**。当前优先路径：
|
||||
|
||||
1. Phase 0：网页端 / 桌面端 MVP 原型人工确认、两端骨架与数据模型。
|
||||
2. **Phase 1：真机取证（最高风险，生死线）。**
|
||||
3. Phase 2：采购服务核心（含**授权超时**，不得推后）。
|
||||
1. 并行完成 T-001 采购服务骨架与 T-002 采购工具骨架。
|
||||
2. T-001 完成后推进 T-004 数据模型；T-002 完成后立即推进
|
||||
**T-101 → T-102 → T-103 真机取证**；两端骨架都完成后可并行补 T-003 统一入口。
|
||||
3. T-103 结论确认后，才开始依赖真机可读字段的 Phase 2 生产页面；采购服务核心与
|
||||
T-104 → T-107 后续真机安全判据按依赖并行推进。
|
||||
4. Phase 3：双端打通与**第一趟试选**端到端。
|
||||
5. Phase 4：**第二趟下单**与收尾。
|
||||
6. V2 及以后：图搜、Excel、ERP、订单自动核对、AI 辅助。
|
||||
|
||||
@@ -15,6 +15,27 @@
|
||||
4. **本文只在规划变化时修改**：单个任务开工或完成**不**修改本文。
|
||||
5. **动手前**先读 `00-ai-start-here.md`、`05-coding-rules.md` 和 `current-state.md`。
|
||||
|
||||
## 并行执行与关键路径
|
||||
|
||||
执行顺序以任务表中的 `依赖` 为准，Phase 是里程碑分组，**不是要求整段串行的栅栏**。
|
||||
在 `write_paths` 不重叠且依赖已完成的前提下，按以下波次推进：
|
||||
|
||||
| 波次 | 采购服务方向 | 采购工具 / 真机方向 | 集成方向 |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | T-001 初始化 `admin/` | T-002 初始化 `client/` | - |
|
||||
| 2 | T-001 后立即做 T-004 | T-002 后立即做 T-101 → T-102 → **T-103** | T-001、T-002 都完成后做 T-003 |
|
||||
| 3 | T-103 通过后推进 T-201 → T-207 | T-103 后推进 T-104 → T-107 | T-208 等待 T-207 与 T-107 均完成 |
|
||||
| 4 | T-301 → T-302 | T-302 后交接 T-303 → T-304 → T-306 | T-306 与 T-104 完成后做 T-305 |
|
||||
| 5 | - | T-305、T-208、T-306 后做 T-401 | T-401 后并行 T-402 / T-403，再做 T-404 → T-405 |
|
||||
|
||||
**T-103 是当前最高优先级和 MVP 生死线。** T-002 一完成就启动 T-101，不等待 T-003、
|
||||
T-004 或整个 Phase 0 收尾。并行只优化等待关系，不改变下列门禁：
|
||||
|
||||
- T-103 的真机结论出来前，不写依赖真机可读字段的 Phase 2 生产页面。
|
||||
- `needs_device: true` 的任务仍只能由人完成验收。
|
||||
- 不复用前序项目页面判据，不放宽三道价格闸门，不让第一趟引用任何下单函数。
|
||||
- 第三个 agent 优先做写路径独立的集成任务或只读复核，不与两端任务争写共享文档。
|
||||
|
||||
## 建议拆分清单
|
||||
|
||||
### Phase 0 · 地基
|
||||
|
||||
+12
-15
@@ -24,17 +24,17 @@
|
||||
`client/requirements.txt` 判断两端是否初始化；当前会以退出码 3 结束并列出 T-001 / T-002
|
||||
——这是预期行为
|
||||
- 标准验证路径：目前只有 `python scripts/validate_agent_context.py` 可跑通
|
||||
- 当前 blocker：T-005“采购服务”Web 表格工作台和 T-006 第三轮“采购工具”桌面工作区均已通过
|
||||
自动检查；两者经人工确认前不开始对应生产 UI。
|
||||
- 当前 blocker：无外部 blocker。T-001 / T-002 尚未落成任务文件和初始化代码；两者是
|
||||
下一波可并行任务。T-002 完成后立即进入 T-101，不等待整个 Phase 0 收尾。
|
||||
|
||||
## 当前目录要点
|
||||
|
||||
| 路径 | 状态 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| `docs/` | 已有 | 项目规范化文档，本次已完整生成 |
|
||||
| `docs/tasks/` | 已有（2 个活动任务） | T-005 / T-006 均为 `DOING`，含 `README.md` 与 `_template.md` |
|
||||
| `docs/design/` | 已有（6 个原型） | web 登录 / 建单 / 工作台 / 详情，desk 采购执行 / 配置；待人工确认 |
|
||||
| `scripts/` | 已有 | `validate_agent_context.py` |
|
||||
| `docs/tasks/` | 已有（T-005～T-009） | T-005～T-008 已完成；T-009 记录关键路径与并行波次 |
|
||||
| `docs/design/` | 已有（6 个原型） | web 登录 / 建单 / 工作台 / 详情，desk 采购执行 / 配置；均已人工确认 |
|
||||
| `scripts/` | 已有 | 上下文门禁、Vikunja 单向导出与 MCP 启动包装 |
|
||||
| `admin/` | **待建** | “采购服务”Go 后端与管理页面（T-001） |
|
||||
| `client/` | **待建** | “采购工具”Python 桌面端（T-002） |
|
||||
| `init.ps1` / `init.sh` | 已有（骨架） | 统一入口。两端目录建好后由 T-003 补全并验证 |
|
||||
@@ -43,16 +43,13 @@
|
||||
|
||||
任务状态以 `docs/tasks/` 各任务文件 frontmatter 的 `status` 为准。本节只写项目级摘要：
|
||||
|
||||
- 已完成：T-007（项目 / 产品名称与 `admin/`、`client/` 源码目录契约）。
|
||||
- 正在进行：T-005（“采购服务”网页端 MVP 交互原型）、T-006（桌面端 MVP 交互原型）。
|
||||
T-005 已将三泳道改为传统表格并统一网页端品牌名称；T-006 第三轮已把执行记录详情从模态框
|
||||
改为左侧内联双视图，支持连续选行、可见返回按钮、`Esc` 层级、异常读取状态和紧凑宽度
|
||||
单视图。两项自动验证均已完成，都因 `needs_human_review: true` 保持 `DOING`。
|
||||
- **下一步：人工浏览 6 个原型，重点确认 Web 表格与详情抽屉，以及桌面端顶部状态区、图片
|
||||
证据、两列执行记录和左侧内联详情 / 返回路径。** 明确确认后才能把 T-005 / T-006 改为
|
||||
`DONE`。
|
||||
- 原型使用假数据、不调用真实接口、不驱动真机；T-001 / T-002 骨架可在确认后并行，
|
||||
Phase 2 生产页面还必须等待相关真机结论。
|
||||
- 已完成：T-005（采购服务交互原型）、T-006（采购工具交互原型）、T-007（产品名称与
|
||||
源码目录契约）、T-008（Vikunja 任务权威与单向导出）、T-009（MVP 关键路径与并行波次）。
|
||||
- **下一步：并行落成并启动 T-001 与 T-002。** T-001 完成后可推进 T-004；T-002 完成后
|
||||
立即推进 T-101 → T-102 → T-103；两端骨架都完成后可并行补 T-003。
|
||||
- T-103 是当前最高优先级和 MVP 生死线。通过前不开发依赖真机可读字段的 Phase 2 生产页面。
|
||||
- 已确认原型继续只作信息架构依据；原型假数据不调用真实接口、不驱动真机。真机结论改变
|
||||
可读字段时必须先回修原型与交互清单。
|
||||
|
||||
## 当前可运行内容
|
||||
|
||||
|
||||
+13
-3
@@ -3,7 +3,7 @@ id: T-009
|
||||
title: 明确 MVP 关键路径与并行开发波次
|
||||
phase: 0
|
||||
deps: [T-008]
|
||||
status: DOING
|
||||
status: DONE
|
||||
created: 2026-08-03
|
||||
vikunja_task_id: 16
|
||||
context_ref: 31b08d7
|
||||
@@ -17,7 +17,7 @@ write_paths:
|
||||
- docs/current-state.md
|
||||
---
|
||||
|
||||
<!-- BEGIN VIKUNJA EXPORT id=16 synced=2026-08-03T09:41:51Z sha256=c7603e88450fcc8ec5e2b5e0c6f6ddc270fe89c03a3c165332b39278bb6238e4 -->
|
||||
<!-- BEGIN VIKUNJA EXPORT id=16 synced=2026-08-03T09:46:54Z sha256=e2541b909a42349c6459a241adbe4776dc518d93c599348846ee9f3a6413250c -->
|
||||
## 问题 / 背景
|
||||
|
||||
T-005 至 T-008 已完成，但当前状态快照仍把 T-005、T-006 写成等待人工确认；入口文档的阶段顺序也容易被理解为必须完成整个 Phase 0 后才能开始 Phase 1。现有依赖实际上允许 T-002 完成后立即进入 T-101，并让 T-004 与真机取证并行。若不把这条关键路径写入仓库，后续 agent 会按阶段串行执行，延迟 MVP 生死线 T-103。
|
||||
@@ -46,7 +46,17 @@ T-005 至 T-008 已完成，但当前状态快照仍把 T-005、T-006 写成等
|
||||
|
||||
## 执行记录
|
||||
|
||||
（暂无）
|
||||
### 2026-08-03T09:42:43Z · ila
|
||||
|
||||
T-009 已落成：Vikunja 任务 #16 与 Git 本地任务文件已建立，T-008 precedes T-009 依赖已配置。任务定义提交：4948afc。基线结果：validate_agent_context.py 通过；init.ps1 按预期以退出码 3 提示 T-001/T-002 尚未初始化。
|
||||
|
||||
### 2026-08-03T09:44:49Z · ila
|
||||
|
||||
T-009 实施完成（2026-08-03）：更新 docs/00-ai-start-here.md、docs/06-tasks.md、docs/current-state.md，明确 T-001/T-002 并行、T-002 后立即 T-101→T-103、T-001 后 T-004、两端骨架后 T-003，并保留 T-103 前禁止开发依赖真机字段的 Phase 2 生产页面。验证：文档断言通过；python scripts/validate_agent_context.py 通过；git diff --check 通过；requirements/architecture/api/coding-rules 均未修改。
|
||||
|
||||
### 2026-08-03T09:46:42Z · ila
|
||||
|
||||
复核发现 @0xk3vin/vikunja-mcp@1.1.1 的 tasks_update 在仅提交 done/percentDone 时会清空 description。已使用包含原 description 的完整更新载荷恢复正文并保持 done=true；后续通过此 MCP 更新任务时必须携带现有 description，不能把部分更新当作 PATCH。该发现不改变本任务产品范围。
|
||||
<!-- END VIKUNJA EXPORT -->
|
||||
|
||||
## 边界
|
||||
|
||||
Reference in New Issue
Block a user