Commit e20d437526c04dec7cda6073daaa25c125b69fcb
1 parent
cd2066a7
docs(27-P3C): 头部补状态行 —— 五批未开工，且批次与 phase 不是一一对齐
刚提醒过并行会话「27-graph-agent-architecture 的状态行落后两个阶段， 会连累每一次迁移判断」，回头看自己这份也有同类问题：文档名叫 p3c、 自述「P3 收尾」，但内容已经溢出 P3 的边界。 补清楚三件事： - 批 1-3 才是真正的 P3 收尾，是本文档主体 - 批 4（并行）归 27-P4 §一.3，那边是设计权威（§五.2 已有警示块） - 批 5（两套任务体系统一）不属于任何既有 phase，是跨阶段技术债清理 以及最要紧的一行：五批全部未开工，0 行代码。判断能否搬 done 时 按批看，别按文档名看。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Showing
1 changed file
with
6 additions
and
1 deletions
docs/todo/system-design/27-p3c-goal-task-model.md
| 1 | 1 | # 27-P3C. 公司目标与任务 —— goal / task 两级模型 + 控制台任务列表 |
| 2 | 2 | |
| 3 | -> **所属**: [27 Graph Agent 架构](./27-graph-agent-architecture.md) 的 P3 收尾，直接续 [27-P3/P4 执行控制台](./27-p3-p4-work-graph-console.md) §四.B 与 [27-P3B 真跑跑道](./27-p3b-real-run-runway.md)。 | |
| 3 | +> **所属**: [27 Graph Agent 架构](./27-graph-agent-architecture.md) 的 **P3 收尾**（P3C），直接续 [27-P3/P4 执行控制台](./27-p3-p4-work-graph-console.md) §四.B 与 [27-P3B 真跑跑道](./27-p3b-real-run-runway.md)。 | |
| 4 | 4 | > **日期**: 2026-08-18 |
| 5 | +> **状态**: 📝 **设计完成，五批全部未开工**（0 行代码）。开放问题已全部关闭，批 1 可直接开工。 | |
| 6 | +> **⚠️ 批次与 phase 的对应不是一一对齐的**，判断「这份能不能搬进 done」时按批看，别按文档名看： | |
| 7 | +> · **批 1-3 = 真正的 P3 收尾**（goal/task 两级模型 + `task-planning` + 排队），本文档的主体； | |
| 8 | +> · **批 4（并行）归 [27-P4](./27-p4-parallel-and-artifacts.md) §一.3**，那边是设计权威，本文档只服从（见 §五.2 的警示块）； | |
| 9 | +> · **批 5（两套任务体系统一）不属于任何既有 phase** —— 是跨阶段的技术债清理，风险面也与前四批完全不同（坏了是所有 agent 互相派不了活），见 §十二.6。 | |
| 5 | 10 | > **交付物**: ① `goals` / `tasks` 两张表，把「人类下达的需求」与「lemonboss 执行的单元」拆成两级；② 基于这两张表的**排队与并行**；③ 执行控制台（`/:id/graph-console`）最左侧新增**目标·任务两级列表栏**。 |
| 6 | 11 | > **命名**: 全文遵循 [27-NAMING](./27-naming-conventions.md)，本文档**落地**的正是它 §四 定义但代码里一直没有载体的 `goal 1 : task N` 基数关系。 |
| 7 | 12 | > **代码引用体例**: 沿用 27-P3/P4 头部约定 —— 只写 `文件名` + 函数名 / 常量名，**不写行号**。 | ... | ... |