From f5e1a22075b2b16496ba9900c95e50f0432c9d3a Mon Sep 17 00:00:00 2001 From: yibo Date: Tue, 18 Aug 2026 14:26:56 +0800 Subject: [PATCH] docs(27-P3C): 开放问题 3 已被 R-20.5 定案，收掉 --- docs/todo/system-design/27-p3c-goal-task-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 2169f48..ed9d40a 100644 --- a/docs/todo/system-design/27-p3c-goal-task-model.md +++ b/docs/todo/system-design/27-p3c-goal-task-model.md @@ -614,7 +614,7 @@ for (const t of queuedTasks) { 1. ~~谁把 goal 拆成 task？~~ **已定案（2026-08-18）：`task-planning` agent 进 v1**，产出 `draft` 任务清单由人确认后下达，详见 §四.9。 2. **goal 级的验收谁做？** 现在 `org-validator` 验的是 task 级（`task-goal`）。一个 goal 的 5 个 task 全 `completed`，不等于人的需求达成了。要不要在 goal 收敛时再跑一次 goal 级验收（`goal-benchmark` 天然就是干这个的）？倾向做，但需要先定「goal 级验收的输入是什么」—— 是 N 个 task 的产物合集吗？留到 P5。 -3. **失败的 task 挡不挡住依赖它的下游？** 当前设计：`depends_on` 只认 `completed`，所以上游 failed 会让下游**永远排队**。需要一个显式的「跳过依赖强制入队」操作，还是把这类 task 自动转 `blocked`？倾向后者（自动转 `blocked` 并在界面标红），但要防止级联误判。 +3. ~~失败的 task 挡不挡住依赖它的下游？~~ **已定案（2026-08-18）：自动转 `blocked` 并在界面标红**，给「重跑上游」与「强制放行」两个出路；`blocked` 每次 `tick` 重算而不落死，上游恢复后下游自己回 `queued`。详见 §五.1.2。 4. **跨公司任务总览**。`/api/tasks` + `TaskTimeline` 是从会话反推的另一套任务树，与本文档的 `tasks` 表同名不同源。将来是把它改成读这张表，还是并存？本次不碰，但这是个明确待收的口子。 5. **`max_parallel_tasks` 放 `company.json` 还是建 `company_settings` 表？** v1 选前者（`companyService.get` 已经在读那个文件，零新增读路径）。公司级配置项超过 3 个时再考虑建表。 6. **goal 级总预算怎么定口径？** §四.1 砍掉了 `goals.budget_json`，因为预算闸门只认 root run，goal 级没有执行机制。真要做，三选一：(a) 建 task 时按条数平分 goal 额度；(b) 预算池上移到 goal，`spendBudget` 从 `root_run_id` 改成上溯 `goal_id`（改动最大但语义最正）；(c) 不做 goal 级，只在界面上把 N 个 task 的消耗加起来显示。**倾向 (c)** —— 一个 goal 的 task 数会变（rerun、后补 task），平分和总池都会让"还剩多少"变成一个解释不清的数。 -- libgit2 0.21.4