From b2a0c1d86543e6561a2b61c55b0249185c336261 Mon Sep 17 00:00:00 2001 From: yibo Date: Tue, 18 Aug 2026 14:43:45 +0800 Subject: [PATCH] docs(27-P3C): max_parallel_tasks 放 company.json —— 开放问题全部关闭 --- docs/todo/system-design/27-p3c-goal-task-model.md | 8 ++++++-- docs/todo/system-design/27-requirement.md | 1 + 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/docs/todo/system-design/27-p3c-goal-task-model.md b/docs/todo/system-design/27-p3c-goal-task-model.md index 0360741..600153f 100644 --- a/docs/todo/system-design/27-p3c-goal-task-model.md +++ b/docs/todo/system-design/27-p3c-goal-task-model.md @@ -444,7 +444,9 @@ for (const t of queuedTasks) { ### 5.2 并发上限与唯一索引 -`company.json` 加一个字段（不新建表，`companyService.get` 已经在读这个文件）： +**定案（2026-08-18）：配置放 `company.json`，不建 `company_settings` 表。** `companyService.get` 已经在读这个文件，零新增读路径；建表要多一张表、一套读写、一次迁移，而目前公司级配置项只有这一个。公司级配置项涨到 3 个以上时再考虑建表（届时连 `company.json` 里已有的那些一起收）。 + +`company.json` 加一个字段： ```jsonc { "max_parallel_tasks": 1 } // 缺省 1 = 与今天完全同行为 @@ -664,7 +666,9 @@ for (const t of queuedTasks) { 2. ~~goal 级的验收谁做？~~ **已定案（2026-08-18）：仍然是 `org-validator`**，在 goal 层再调一次同一个本体，输入是该 goal 全部 task 的产物合集。详见 §四.10。 3. ~~失败的 task 挡不挡住依赖它的下游？~~ **已定案（2026-08-18）：自动转 `blocked` 并在界面标红**，给「重跑上游」与「强制放行」两个出路；`blocked` 每次 `tick` 重算而不落死，上游恢复后下游自己回 `queued`。详见 §五.1.2。 4. ~~跨公司任务总览 / 两套任务树并存~~ **已定案（2026-08-18）：统一到 `tasks` 表一套，删掉会话反推那套。** 详见 §十二（批 5）。 -5. **`max_parallel_tasks` 放 `company.json` 还是建 `company_settings` 表？** v1 选前者（`companyService.get` 已经在读那个文件，零新增读路径）。公司级配置项超过 3 个时再考虑建表。 +5. ~~`max_parallel_tasks` 放 `company.json` 还是建 `company_settings` 表？~~ **已定案（2026-08-18）：放 `company.json`。** 详见 §五.2。 + +> **本文档的开放问题至此全部关闭。** 后续新增的疑问按惯例继续往这一节追加，不要在正文里留疑问句。 6. ~~goal 级总预算怎么定口径？~~ **已定案（2026-08-18）：预算先不考虑，不做 goal 级闸门。** `goals.budget_json` 保持砍掉。**但 `planning_tokens` / `validation_tokens` 两个记账字段保留** —— 它们不是闸门，是让 goal 层那两次 agent 调用的花费**可见**；不记就是 `defaultPlanWorkGraph` 注释点名的「隐形的一半」，而且界面上「本次拆分消耗 ~N tokens」这个确认步骤要用它。 7. ~~排队中的任务能不能改依赖？~~ **已定案（2026-08-18）：可以改。** `queued` 状态开放 `depends_on` 的 `PATCH`，见 §六.3。当初担心的「改完位次怎么算」不成立：`queuePosition` 只按 `priority → seq → created_at` 排，`depends_on` 决定的是**够不够格出队**，两者正交，改依赖不动位次。 diff --git a/docs/todo/system-design/27-requirement.md b/docs/todo/system-design/27-requirement.md index b8fc648..93b0004 100644 --- a/docs/todo/system-design/27-requirement.md +++ b/docs/todo/system-design/27-requirement.md @@ -550,6 +550,7 @@ git diff，最后 W13 只能把计数挪去另一个被 ignore 的文件。`file | 3 | goal 级总预算口径？ | **先不考虑**，不做 goal 级闸门 | P3C §十一.6 | | 4 | 排队中的任务能不能改依赖？ | **可以改**，`queued` 开放 `depends_on` 的 PATCH | P3C §六.3 | | 5 | `/api/tasks` + `TaskTimeline` 那套同名不同源的任务树怎么收？ | **统一到 `tasks` 表一套，删掉另一套** | P3C §十二（批 5）| +| 6 | `max_parallel_tasks` 放 `company.json` 还是建 `company_settings` 表？ | **放 `company.json`**（`companyService.get` 已在读它，零新增读路径）| P3C §五.2 | **定案 2 的要点是「不新造验收 agent」**：task 级与 goal 级验的是**基数不同的东西**（R-12 / NAMING §四 那张表）——task 级问「这一个 task 的 `task-goal` 达成没有」，goal 级问「N 个 task 合起来，人提的需求达成没有」。5 个 task 全 `completed` 不等于人要的东西做出来了，这个缺口正是 goal 层存在的理由。所以是**同一个本体在 goal 层再调一次**，不是复用 task 级的结论。单 task 的 goal 跳过这次调用（两级验收此时是同一件事）。 -- libgit2 0.21.4