docs(27-P3C): max_parallel_tasks 放 company.json —— 开放问题全部关闭

companyService.get 已经在读这个文件，零新增读路径；建表要多一张表、一套读写、一次迁移，而目前公司级配置项只有这一个。涨到 3 个以上时再考虑建表。这是 P3C 最后一个开放问题，§十一至此全部关闭。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs(27-P3C): max_parallel_tasks 放 company.json —— 开放问题全部关闭
companyService.get 已经在读这个文件，零新增读路径；建表要多一张表、一套读写、一次迁移，而目前公司级配置项只有这一个。涨到 3 个以上时再考虑建表。这是 P3C 最后一个开放问题，§十一至此全部关闭。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
yibo
1 parent 2abb0820
Showing 2 changed files with 7 additions and 2 deletions
docs/todo/system-design/27-p3c-goal-task-model.md
docs/todo/system-design/27-requirement.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` 决定的是**够不够格出队**，两者正交，改依赖不动位次。
@@ -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 跳过这次调用（两级验收此时是同一件事）。