宜博 / lemonboss

Commit 81e28e56bffeaa20dd2b58ce48f729b2851078eb

Authored by yibo
1 parent 92bebc5d

feat(task-decomposition): goal→task 支持子任务（43 号文档 Phase 0-3） 

实现路径：task-planning 判断是否 itemized（硬规则 5 开例外让 LLM 写这
一个字段）→ org-planner 收尾把 acceptance.md 物化成子任务 → coder-validator
用新工具 task subtask-result 逐条上报，settleNode() 新增闸门强制核对
子任务全部 completed 才认这一轮 success。

- work-graph-db.js: tasks 加 acceptance_mode 列，createTask 支持
  parentTaskId（复用既有列），新增 settleSubtaskResult 条件更新
- graph-engine.js: maybeMaterializeItemizedSubtasks（org-planner 结算
  success 后物化子任务，agent_call/subgraph 两种形态都认，subgraph 场景
  扫子 run 全节点找 acceptance.md，找不到优雅降级不阻塞主产出）；
  coder-validator 判 success 前新增子任务完整性闸门
  （ENGINE_FAIL_REASONS.SUBTASKS_INCOMPLETE）
- task-planning.js / company.js: acceptance_mode 字段透传链路
- bin/lemon.js: 新增 task subtasks / task subtask-result 两个子命令
- coder-validator/agent.md、task-planning/agent.md: 对应提示词更新

真实回归验证过（新建公司走完整链路），过程中发现两个跟本次改动无关的
预存在问题：一次瞬时的 produces_missing 误判（重试即愈）、一个结构性的
writesArtifacts 产出闸门不匹配 bug（另立 44 号文档记录，未修复）。

全量单测 1120/1123 通过，3 个失败与本次改动无关（git stash 验证过）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U7xYyvv3pzuV9diMVUH5QL
Inline Side-by-side
Showing 12 changed files with 730 additions and 17 deletions
bin/lemon.js
  View file @81e28e5
... ... @@ -195,6 +195,25 @@ async function run() {
195 195 });
196 196 } catch { /* best-effort，静默丢弃 */ }
197 197 }
  198 + // 43 号文档 Phase 3：itemized 任务列出它物化出的子任务（coder-validator 逐条验收前先拿列表）
  199 + else if (command === 'task subtasks') {
  200 + const { values } = parseArgs({ args: args.slice(2), options: {
  201 + companyId: { type: 'string' }, taskId: { type: 'string' }
  202 + }});
  203 + const res = await request('GET', `/company/${values.companyId}/tasks?parentTaskId=${encodeURIComponent(values.taskId)}`);
  204 + console.log(JSON.stringify(res.data, null, 2));
  205 + }
  206 + // 43 号文档 Phase 3：逐条上报一个子任务的验收结果（每判完一条验收项调一次）
  207 + else if (command === 'task subtask-result') {
  208 + const { values } = parseArgs({ args: args.slice(2), options: {
  209 + companyId: { type: 'string' }, taskId: { type: 'string' },
  210 + status: { type: 'string' }, summary: { type: 'string', default: '' }
  211 + }});
  212 + const res = await request('POST', `/company/${values.companyId}/tasks/${values.taskId}/subtask-result`, {
  213 + status: values.status, summary: values.summary
  214 + });
  215 + console.log(JSON.stringify(res.data, null, 2));
  216 + }
198 217 else if (command === 'pipeline create') {
199 218 const { values } = parseArgs({ args: args.slice(2), options: {
200 219 companyId: { type: 'string' }, file: { type: 'string' }
... ...
server/routes/company.js
  View file @81e28e5
... ... @@ -1023,6 +1023,9 @@ function taskView(t, progress = null, positions = null) {
1023 1023 blockedReason: t.blocked_reason,
1024 1024 reportTo: t.report_to,
1025 1025 assigneeAgentId: t.assignee_agent_id || null,
  1026 + // 43 号文档：子任务树的父子指针 + 这条 task 走哪种验收模式（看板据此决定要不要画子任务）
  1027 + parentTaskId: t.parent_task_id || null,
  1028 + acceptanceMode: t.acceptance_mode || 'holistic',
1026 1029 createdAt: t.created_at,
1027 1030 queuedAt: t.queued_at,
1028 1031 startedAt: t.started_at,
... ... @@ -1409,10 +1412,19 @@ function buildTaskPlans(specs, { priority, budget, mode, seqBase = 0 } = {}) {
1409 1412 if (rawDeps !== undefined && rawDeps !== null && !Array.isArray(rawDeps)) {
1410 1413 return { error: `tasks[${i}].depends_on 必须是数组` };
1411 1414 }
  1415 + // 43 号文档：跟 mode/priority/budget 不同——这个字段**透传**、不继承 goal 级默认值。
  1416 + // 要不要按验收条目拆子任务是语义判断，task-planning 已经在 specs 里判过一次；
  1417 + // 没给就是没判断要拆，缺省 holistic（保守），不是「服务端注入默认值」那类字段。
  1418 + const rawAMode = s.acceptance_mode !== undefined ? s.acceptance_mode : s.acceptanceMode;
  1419 + const acceptanceMode = rawAMode == null ? 'holistic' : rawAMode;
  1420 + if (!['holistic', 'itemized'].includes(acceptanceMode)) {
  1421 + return { error: `tasks[${i}].acceptance_mode 只能是 'holistic' 或 'itemized'，收到: ${JSON.stringify(rawAMode)}` };
  1422 + }
1412 1423 plans.push({
1413 1424 seq: base + i + 1, // seq 显式给，别靠 MAX+1 —— depends_on 的 seq 引用要能对得上服务端分配的号
1414 1425 title: String(s.title || '').trim() || deriveTitle(d),
1415 1426 description: d,
  1427 + acceptanceMode,
1416 1428 // 优先级：task 自己的 mode > goal 级 mode（第三个候选）> 'manual'。
1417 1429 // 「继承 goal」这一层是批 2 加的，对显式传 tasks[] 的调用方是行为变化（此前恒 manual），
1418 1430 // 保留它是因为反过来更荒谬：用户在表单上把整个 goal 选成 auto，拆出来的 task 却全是
... ... @@ -1450,6 +1462,7 @@ function insertTasksForGoal(wdb, goal, plans, createdBy) {
1450 1462 priority: p.priority,
1451 1463 budgetJson: p.budget, // 建行时就存下来：草稿路径上请求体活不到 dispatch（缺陷 F3）
1452 1464 createdBy,
  1465 + acceptanceMode: p.acceptanceMode,
1453 1466 })
1454 1467 );
1455 1468 const bySeq = new Map(created.map((t) => [String(t.seq), t.id]));
... ... @@ -2065,6 +2078,8 @@ router.get(&#39;/:companyId/tasks&#39;, (req, res) =&gt; {
2065 2078 const tasks = wdb.listCompanyTasks(req.params.companyId, {
2066 2079 status: req.query.status || null,
2067 2080 goalId: req.query.goalId || req.query.goal_id || null,
  2081 + // 43 号文档：coder-validator 用它列出一个 itemized 任务物化出的全部子任务
  2082 + parentTaskId: req.query.parentTaskId || req.query.parent_task_id || null,
2068 2083 includeArchived: req.query.includeArchived === '1' || req.query.includeArchived === 'true',
2069 2084 limit: Number.isInteger(limit) ? limit : null,
2070 2085 });
... ... @@ -2308,6 +2323,40 @@ router.patch(&#39;/:companyId/tasks/:taskId&#39;, (req, res) =&gt; {
2308 2323 });
2309 2324  
2310 2325 /**
  2326 + * POST /api/company/:companyId/tasks/:taskId/subtask-result — 43 号文档 Phase 3
  2327 + * body: { status: 'completed' | 'failed', summary? }
  2328 + *
  2329 + * `coder-validator` 逐条验收 itemized 任务的验收条目时，每判完一条就调一次这个端点上报
  2330 + * 那一条子任务的结果——不是解析它写的 checks[]/verdict 自由文本 JSON（那份格式在几个
  2331 + * validator 之间只是约定俗成，从没被任何服务端代码强制校验过，见 graph-engine.js 的
  2332 + * unsatisfiedRequiredProduces 一带）。状态改变走真实工具调用，这是本仓库一贯的做法。
  2333 + *
  2334 + * 只接受**子任务**（`parent_task_id` 非空）：顶层 task 的终态由 run 收敛走
  2335 + * `settleTaskFromRun` 那条路，这个端点不是它的替代品。
  2336 + */
  2337 +router.post('/:companyId/tasks/:taskId/subtask-result', (req, res) => {
  2338 + try {
  2339 + const wdb = require('../services/work-graph-db');
  2340 + const task = requireTask(req, res);
  2341 + if (!task) return;
  2342 + if (!task.parent_task_id) {
  2343 + return res.status(400).json({
  2344 + error: `${task.id} 不是子任务（没有 parent_task_id）——这个端点只服务 43 号文档物化出来的子任务，顶层任务的终态由 run 收敛决定`,
  2345 + });
  2346 + }
  2347 + const { status, summary } = req.body || {};
  2348 + if (!['completed', 'failed'].includes(status)) {
  2349 + return res.status(400).json({ error: `status 只能是 'completed' 或 'failed'，收到: ${JSON.stringify(status)}` });
  2350 + }
  2351 + const changed = wdb.settleSubtaskResult(task.id, status, summary || null);
  2352 + res.json({ ok: true, changed: changed > 0, task: taskView(wdb.getTask(task.id)) });
  2353 + } catch (err) {
  2354 + console.error('[TaskEntry] Error:', err.message);
  2355 + res.status(500).json({ error: err.message });
  2356 + }
  2357 +});
  2358 +
  2359 +/**
2311 2360 * POST /api/company/:companyId/tasks/:taskId/enqueue — 单条入队（27-P3C §六.3）
2312 2361 *
2313 2362 * 与 `goals/:goalId/dispatch` 的差别只是粒度：那条把 goal 下所有 draft 一起推进队列，
... ...
server/services/graph-engine.js
  View file @81e28e5
... ... @@ -62,6 +62,8 @@ const {
62 62 // 39 号文档「确定性通路」：回退熔断收敛时顺手开一条 draft task，见 maybeProposeReplanTask
63 63 createTask,
64 64 getGoal,
  65 + // 43 号文档：settleNode 成功路径顺手物化 itemized 子任务，见 maybeMaterializeItemizedSubtasks
  66 + getTask,
65 67 } = require('./work-graph-db');
66 68  
67 69 /**
... ... @@ -221,6 +223,11 @@ const ENGINE_FAIL_REASONS = Object.freeze({
221 223 // 会静默拿一份没有角色指导的提示词去跑真实 CLI（真实样本见 34 号文档 §五）。
222 224 // 字符串与招聘路径的 'body_not_ready' 同名同义，不是两套判词。
223 225 BODY_NOT_READY: 'body_not_ready',
  226 + // 43 号文档 Phase 3：coder-validator 判自己 success，但它验的 task 是 itemized 且
  227 + // 子任务还没全部 completed——agent 自己写的 checks[]/verdict 没人解析（见下面
  228 + // maybeCheckSubtasksComplete 的注释），真正说了算的是 tasks.status，这里同样是
  229 + // 把一个此前只进提示词的软约束收成硬闸门，不是发明新语义。
  230 + SUBTASKS_INCOMPLETE: 'subtasks_incomplete',
224 231 });
225 232  
226 233 /** 归因/结构化产出文件名（agent.md「产出格式」：runs/{rootRunId}/nodes/{nodeRunId}/attempt-{n}.json） */
... ... @@ -1845,9 +1852,35 @@ function settleNode(runId, nodeRunId, outcome = {}) {
1845 1852 timelineNote({ runId, nodeRunId }, 'node.output',
1846 1853 `节点声明必需的上游产物 ${missingInputs.join(', ')} 在索引里查不到实例，按 fail 结算`,
1847 1854 { node_run_id: nodeRunId, missing_kinds: missingInputs, degraded: 'missing_required_input' });
  1855 + } else {
  1856 + // 43 号文档 Phase 3：coder-validator 判自己 success 之前，再核一遍它管的 task 是不是
  1857 + // itemized 且有子任务——有的话必须全部 completed 才认这次 success。coder-validator
  1858 + // 自己写的 checks[]/verdict 是没人解析的自由文本（同一段代码里 unsatisfiedRequiredProduces
  1859 + // 的教训：软产物必须收成硬闸门，不能只指望 agent 自觉），真正说了算的是 tasks.status，
  1860 + // 由 coder-validator 调 /subtask-result 端点逐条写（server/routes/company.js）。
  1861 + const dRole = def0.nodes.get(nodeRun0.def_node_id);
  1862 + if (dRole && dRole.systemAgentId === 'coder-validator' && run0.task_id) {
  1863 + const subtasks = getDb().prepare(`SELECT id, status FROM tasks WHERE parent_task_id = ?`).all(run0.task_id);
  1864 + const notDone = subtasks.filter((t) => t.status !== 'completed').map((t) => t.id);
  1865 + if (notDone.length) {
  1866 + to = 'fail';
  1867 + failReason = ENGINE_FAIL_REASONS.SUBTASKS_INCOMPLETE;
  1868 + timelineNote({ runId, nodeRunId }, 'node.output',
  1869 + `这条 task 是 itemized，还有 ${notDone.length}/${subtasks.length} 条子任务没有上报 completed（${notDone.join(', ')}），不认这次 success`,
  1870 + { node_run_id: nodeRunId, unresolved_subtasks: notDone, degraded: 'subtasks_incomplete' });
  1871 + }
  1872 + }
1848 1873 }
1849 1874 }
1850 1875 }
  1876 + // 43 号文档：故意放在 !isSubgraphNode 这道闸门**之外**——org-planner 在 org 层的节点
  1877 + // 类型是 subgraph（org 层节点全是 subgraph，见上面 isSubgraphNode 的注释），真正核实
  1878 + // 生产数据发现它当前总是靠 workgraph-planning 展开成 planner.json 那张 5 节点子图，
  1879 + // 不是直接一个 agent_call；acceptance.md（如果有）落在子 run 里，不在这个节点自己的
  1880 + // 私有目录（subgraph 节点的 output_ref 恒为 null）。两种形态都要认，见函数内部。
  1881 + if (to === 'success' && run0 && nodeRun0 && def0) {
  1882 + maybeMaterializeItemizedSubtasks({ runId, nodeRunId, run: run0, nodeRun: nodeRun0, def: def0, isSubgraphNode });
  1883 + }
1851 1884 }
1852 1885  
1853 1886 const changed = sse.transitionNode(runId, nodeRunId, 'running', to, {
... ... @@ -2207,6 +2240,109 @@ function maybeProposeReplanTask(runId, rootRunId, nodeRun, def, remediationNote)
2207 2240 }
2208 2241  
2209 2242 /**
  2243 + * 解析 org-planner 写的 acceptance.md（`| # | 验收项 | 判定方式 | pass 条件 |` 表格，
  2244 + * 见 `system/agents/org-planner/tools.md` §3 的模板）。只信表格形状，不信位置——
  2245 + * 列数不足 4、分隔行（`---`）、编号列不是纯数字的行一律跳过，不抛异常：格式不对
  2246 + * 就是「没有可用的验收条目」，交给调用方按空数组处理。
  2247 + */
  2248 +function parseAcceptanceMd(text) {
  2249 + const rows = [];
  2250 + for (const line of String(text || '').split('\n')) {
  2251 + const m = line.match(/^\s*\|(.*)\|\s*$/);
  2252 + if (!m) continue;
  2253 + const cells = m[1].split('|').map((c) => c.trim());
  2254 + if (cells.length < 4) continue;
  2255 + const [seqCell, item, method, passCondition] = cells;
  2256 + if (!/^\d+$/.test(seqCell) || !item) continue; // 表头 / 分隔行 / 编号写歪的行
  2257 + rows.push({ seq: Number(seqCell), item, method, passCondition });
  2258 + }
  2259 + return rows;
  2260 +}
  2261 +
  2262 +/**
  2263 + * 在一条 run 名下**全部**节点的私有目录里找 acceptance.md，返回第一份找到的绝对路径。
  2264 + *
  2265 + * 不假设固定节点名/固定模板：org-planner 到底展开成哪张 work graph（`planner.json` 的
  2266 + * 5 节点 fan-out，还是别的骨架）是 workgraph-planning 现场选的，谁写 acceptance.md
  2267 + * 因模板而异（43 号文档 Phase 2 核实真实生产数据后的结论），扫全部节点比认一个固定
  2268 + * 节点名更不容易随模板改动跟着碎。
  2269 + */
  2270 +function findAcceptanceMdFile(run) {
  2271 + try {
  2272 + const rows = getDb().prepare(`SELECT id FROM graph_run_nodes WHERE run_id = ?`).all(run.id);
  2273 + for (const r of rows) {
  2274 + const file = path.join(nodeArtifactDir(run, r.id), 'acceptance.md');
  2275 + if (fs.existsSync(file)) return file;
  2276 + }
  2277 + } catch { /* 目录读不出来就当没有，best-effort */ }
  2278 + return null;
  2279 +}
  2280 +
  2281 +/**
  2282 + * 43 号文档 Phase 2：`task.acceptance_mode='itemized'` 时，org-planner 这一轮真正判定
  2283 + * success 之后，把它（或它展开出的子图）写的 acceptance.md 逐行物化成子任务。
  2284 + *
  2285 + * org 层节点全是 `nodeKind='subgraph'`（见上面 isSubgraphNode 的注释），真实核实生产数据
  2286 + * 发现 org-planner 现在总是靠 workgraph-planning 展开成子图在跑，不是直接一个 agent_call——
  2287 + * 两种形态都要认：agent_call 就在它自己的私有目录找，subgraph 就去它的子 run 里全节点扫
  2288 + * （见 findAcceptanceMdFile）。
  2289 + *
  2290 + * 纯 best-effort：查不到 task / 不是 itemized / 文件不存在 / 解析不出条目，一律安静跳过
  2291 + * 并留一条 timeline note——**这一步失败绝不能把 org-planner 这一轮真正有价值的产出打成
  2292 + * fail**，物化子任务是「顺手做的」，不是节点判定的一部分（33 号文档的教训：把一个软产物
  2293 + * 当成硬闸门，会把整条链路拖进死循环）。
  2294 + *
  2295 + * 幂等：父任务名下已经有子任务就不再重复建——覆盖的是节点被 retry 后二次结算 success
  2296 + * 这种情况，不是想同步 acceptance.md 后续的编辑（那需要人工介入，不是这一步的职责）。
  2297 + */
  2298 +function maybeMaterializeItemizedSubtasks({ runId, nodeRunId, run, nodeRun, def, isSubgraphNode }) {
  2299 + try {
  2300 + const d = def && nodeRun && def.nodes.get(nodeRun.def_node_id);
  2301 + if (!d || d.systemAgentId !== 'org-planner') return;
  2302 + if (!run.task_id) return;
  2303 +
  2304 + const task = getTask(run.task_id);
  2305 + if (!task || task.acceptance_mode !== 'itemized') return;
  2306 +
  2307 + const already = getDb().prepare(`SELECT COUNT(*) AS n FROM tasks WHERE parent_task_id = ?`).get(task.id).n;
  2308 + if (already > 0) return;
  2309 +
  2310 + const searchRun = isSubgraphNode ? getRun(nodeRun.child_run_id) : run;
  2311 + const file = searchRun ? findAcceptanceMdFile(searchRun) : null;
  2312 + if (!file) {
  2313 + timelineNote({ runId, nodeRunId }, 'node.output',
  2314 + `task.acceptance_mode='itemized' 但没找到 acceptance.md，跳过子任务物化（仍按 holistic 收尾）`,
  2315 + { node_run_id: nodeRunId, task_id: task.id, degraded: 'acceptance_md_missing' });
  2316 + return;
  2317 + }
  2318 +
  2319 + const rows = parseAcceptanceMd(fs.readFileSync(file, 'utf-8'));
  2320 + if (!rows.length) {
  2321 + timelineNote({ runId, nodeRunId }, 'node.output',
  2322 + `acceptance.md 存在但解析不出任何验收条目（表格形状不对？），跳过子任务物化`,
  2323 + { node_run_id: nodeRunId, task_id: task.id, degraded: 'acceptance_md_unparseable' });
  2324 + return;
  2325 + }
  2326 +
  2327 + for (const row of rows) {
  2328 + createTask({
  2329 + goalId: task.goal_id,
  2330 + companyId: task.company_id,
  2331 + title: row.item.slice(0, 120),
  2332 + description: `判定方式：${row.method || '(未写明)'}\npass 条件：${row.passCondition || '(未写明)'}`,
  2333 + createdBy: 'org-planner',
  2334 + parentTaskId: task.id,
  2335 + });
  2336 + }
  2337 + timelineNote({ runId, nodeRunId }, 'node.output',
  2338 + `按 acceptance.md 物化了 ${rows.length} 条子任务`,
  2339 + { node_run_id: nodeRunId, task_id: task.id, subtask_count: rows.length });
  2340 + } catch (err) {
  2341 + console.error('[graph-engine] maybeMaterializeItemizedSubtasks 失败（不影响节点结算）：', err.message);
  2342 + }
  2343 +}
  2344 +
  2345 +/**
2210 2346 * 解析跨层地址 → 「该退到哪个子 run 的哪一行」（**纯查询，不改任何状态**）。
2211 2347 *
2212 2348 * 输入的地址来自失败节点行的 `fail_node_ref`（三值透传的第四值，见 normalizeNodeRef 那段）。
... ...
server/services/task-planning.js
  View file @81e28e5
... ... @@ -42,8 +42,14 @@ const PLAN_MAX_ROUNDS = 3;
42 42 */
43 43 const MAX_TASKS = 8;
44 44  
45   -/** 产出里允许出现的键。多余键一律按 schema 打回：那些字段要么服务端生成、要么人在界面上定 */
46   -const ALLOWED_KEYS = new Set(['seq', 'title', 'description', 'depends_on', 'dependsOn']);
  45 +/** 产出里允许出现的键。多余键一律按 schema 打回：那些字段要么服务端生成、要么人在界面上定
  46 + *
  47 + * 43 号文档：`acceptance_mode` 是这四个字段之外**唯一**的例外——要不要按验收条目拆子任务，
  48 + * 是一次语义判断（跟「要不要拆多个 task」用的是同一种判断力），没法像 mode/priority/budget
  49 + * 那样交给服务端按 goal 级默认值机械注入，所以必须让 agent 自己决定、自己写出来。
  50 + */
  51 +const ALLOWED_KEYS = new Set(['seq', 'title', 'description', 'depends_on', 'dependsOn', 'acceptance_mode', 'acceptanceMode']);
  52 +const ACCEPTANCE_MODES = new Set(['holistic', 'itemized']);
47 53  
48 54 // ────────────────────────────────────────────────────────────────
49 55 // 注入点（仿 graph-engine.setPlanWorkGraph）
... ... @@ -76,7 +82,7 @@ function planTasks(ctx) {
76 82 *
77 83 * @param {{companyId: string, goal: object}} ctx goal 是 goals 表的整行
78 84 * @returns {Promise<{specs: object[], tokens: number, rounds: number}>}
79   - * specs 形如 `[{seq, title, description, depends_on: [seq…]}]`，seq 恒为 1..N 连续
  85 + * specs 形如 `[{seq, title, description, depends_on: [seq…], acceptance_mode}]`，seq 恒为 1..N 连续
80 86 * @throws 轮次耗尽 / 调用本身炸了；两种情况都在 error 上挂了 `tokens`（已烧掉的那部分）
81 87 */
82 88 async function defaultPlanTasks(ctx) {
... ... @@ -203,14 +209,20 @@ function buildTaskPlanningPrompt(ctx, { round = 1, errors = null, lastOutput = &#39;
203 209 describeHiredRoles(ctx.companyId),
204 210 '',
205 211 '## 交回方式（引擎只读你回复里最后一个 ```json 代码块）',
206   - '顶层是**数组**，每个元素恰好四个字段：',
  212 + '顶层是**数组**，每个元素四个必填字段 + 一个可选字段：',
207 213 '```json',
208   - '[{"seq":1,"title":"…","description":"…","depends_on":[]}]',
  214 + '[{"seq":1,"title":"…","description":"…","depends_on":[],"acceptance_mode":"holistic"}]',
209 215 '```',
210 216 `- \`seq\`：1..N 连续整数、不重复、与数组顺序一致；条数上限 **${MAX_TASKS}**。`,
211 217 '- `depends_on`：只能写本次产出的 `seq` 数字（1-based）。**不许写 task id** —— id 由服务端'
212 218 + '在你交回之后才生成，你根本看不到；写字符串一定被打回。没有依赖就写 `[]`（不能省）。',
213   - '- 只输出这四个字段。`id` / `status` / `mode` / `budget` / `priority` / `agent` 一律不许出现。',
  219 + '- `acceptance_mode`（可选，缺省 `"holistic"`）：这条 task 的验收后续要不要按验收条目拆成'
  220 + + '子任务逐条判——判断轴跟 Step 2 判「要不要拆多个 task」是同一种（够不够独立成立、值不值得'
  221 + + '单独验收）。多数任务留空/写 `"holistic"` 即可；只有一件对外是单一交付物、但内部有多条'
  222 + + '可以各自独立验收的验收标准的任务，才写 `"itemized"`。不确定就留 `"holistic"`——错误地'
  223 + + '拆细比保守合并的代价更高。',
  224 + '- 只输出这五个字段（`acceptance_mode` 可以不写）。`id` / `status` / `mode` / `budget`'
  225 + + ' / `priority` / `agent` 一律不许出现。',
214 226 '- 每条 `description` 必须**自包含**：下游每条 task 起独立的 run，那个 run 只看得到自己'
215 227 + '这一条描述（它会成为该 run 的 task-goal.json），不许写「同上」「见 task 1」这类跨条引用。',
216 228 '- 拆分理由写在 JSON 代码块**前面**的正文里；代码块之后不要再写任何字。',
... ... @@ -370,7 +382,18 @@ function validatePlannedTasks(raw) {
370 382 }
371 383 const extra = Object.keys(item).filter((k) => !ALLOWED_KEYS.has(k));
372 384 if (extra.length) {
373   - errors.push({ rule: 'schema', detail: `${at} 有多余键 ${extra.join(' / ')}：只许 seq / title / description / depends_on` });
  385 + errors.push({ rule: 'schema', detail: `${at} 有多余键 ${extra.join(' / ')}：只许 seq / title / description / depends_on / acceptance_mode` });
  386 + }
  387 +
  388 + // 没写就是没判断要拆——缺省 holistic（保守，不引入新行为），不是错误
  389 + const rawMode = item.acceptance_mode !== undefined ? item.acceptance_mode : item.acceptanceMode;
  390 + let acceptanceMode = 'holistic';
  391 + if (rawMode !== undefined && rawMode !== null) {
  392 + if (!ACCEPTANCE_MODES.has(rawMode)) {
  393 + errors.push({ rule: 'schema', detail: `${at} 的 acceptance_mode 只能是 "holistic" 或 "itemized"，收到 ${JSON.stringify(rawMode)}` });
  394 + } else {
  395 + acceptanceMode = rawMode;
  396 + }
374 397 }
375 398  
376 399 const description = String(item.description == null ? '' : item.description).trim();
... ... @@ -406,6 +429,7 @@ function validatePlannedTasks(raw) {
406 429 title: String(item.title == null ? '' : item.title).trim(),
407 430 description,
408 431 depends_on: deps,
  432 + acceptance_mode: acceptanceMode,
409 433 });
410 434 });
411 435  
... ...
server/services/work-graph-db.js
  View file @81e28e5
... ... @@ -531,6 +531,10 @@ function getDb() {
531 531 -- queued 现在就在取值域里，但排队逻辑（调度器 / run_status='queued'）另批实现：
532 532 -- 取值域是数据形状的一部分，先钉死它，免得批 3 再来改一次列注释
533 533 execution_mode TEXT NOT NULL DEFAULT 'manual' CHECK (execution_mode IN ('manual','auto')),
  534 + -- 43 号文档：itemized 的 task 由 org-planner 收尾时按验收条目物化出子任务
  535 + -- （parent_task_id 指回这一行）；holistic 保持现状「一次性给总分」不物化任何东西。
  536 + -- 子任务本身恒为 holistic（不允许递归再拆一层），见 createTask 里的校验。
  537 + acceptance_mode TEXT NOT NULL DEFAULT 'holistic' CHECK (acceptance_mode IN ('holistic','itemized')),
534 538 depends_on TEXT NOT NULL DEFAULT '[]', -- JSON 数组，同 goal 内的 task id
535 539 budget_json TEXT,
536 540 current_run_id TEXT, -- 最近一次 root run（逻辑外键，见 §四.6）
... ... @@ -632,6 +636,11 @@ function getDb() {
632 636 if (!hasColumn(db, 'tasks', 'execution_conv_id')) {
633 637 db.exec(`ALTER TABLE tasks ADD COLUMN execution_conv_id TEXT`);
634 638 }
  639 + // 43 号文档：ADD COLUMN 加不了 CHECK（同上 executor 那条注释的 SQLite 限制），
  640 + // 存量库上 acceptance_mode 的取值域只由 createTask 的应用层校验守。
  641 + if (!hasColumn(db, 'tasks', 'acceptance_mode')) {
  642 + db.exec(`ALTER TABLE tasks ADD COLUMN acceptance_mode TEXT NOT NULL DEFAULT 'holistic'`);
  643 + }
635 644 // ⚠️ 这条索引**必须建在 ALTER 之后**，不能放进上面的建表块：
636 645 // 建表块整体先于迁移块执行，而存量库上 `CREATE TABLE IF NOT EXISTS tasks` 是 no-op ——
637 646 // 表还是批 4 的形态、没有 assignee_agent_id，那一句 CREATE INDEX 会直接抛
... ... @@ -1856,6 +1865,10 @@ function validateDependsOn(goalId, taskId, dependsOn) {
1856 1865 * **必须能在建行时就存下来**（缺陷 F3）：草稿路径（`POST /:cid/tasks` 撞 409 → 存草稿 →
1857 1866 * 之后 dispatch）上，请求体里的 budget 早就不在了。只有写侧没有读侧的列 = 用户填了、
1858 1867 * 接口回了 200、run 却拿着 DEFAULT_TASK_BUDGET 在跑，中途预算耗尽 blocked 且没人知道为什么。
  1868 + * @param {string|null} [p.parentTaskId] 43 号文档：子任务指回父任务。图流水线（`insertTasksForGoal`）
  1869 + * 建的顶层 task 恒为 null；只有 org-planner 收尾物化子任务时才传。
  1870 + * @param {string} [p.acceptanceMode='holistic'] 'holistic' | 'itemized'。子任务恒为 'holistic'
  1871 + * （不允许递归再拆一层）——传 `parentTaskId` 时若给了 'itemized' 会被拒。
1859 1872 * @returns {object} 刚插入的整行
1860 1873 */
1861 1874 function createTask({
... ... @@ -1870,14 +1883,25 @@ function createTask({
1870 1883 budgetJson = null,
1871 1884 reportTo = null,
1872 1885 createdBy = null,
  1886 + parentTaskId = null,
  1887 + acceptanceMode = 'holistic',
1873 1888 } = {}) {
1874 1889 if (!goalId) throw new Error('createTask: goalId 必填');
1875 1890 if (!title) throw new Error('createTask: title 必填');
1876 1891 if (!description) throw new Error('createTask: description 必填');
  1892 + if (!['holistic', 'itemized'].includes(acceptanceMode)) {
  1893 + throw new Error(`createTask: acceptanceMode 非法: ${acceptanceMode}`);
  1894 + }
  1895 + if (parentTaskId && acceptanceMode === 'itemized') {
  1896 + throw new Error('createTask: 子任务（有 parentTaskId）不允许再声明 itemized，不支持递归拆分');
  1897 + }
1877 1898  
1878 1899 const db = getDb();
1879 1900 const goal = getGoal(goalId);
1880 1901 if (!goal) throw new Error(`createTask: goal 不存在: ${goalId}`);
  1902 + if (parentTaskId && !getTask(parentTaskId)) {
  1903 + throw new Error(`createTask: parentTaskId 不存在: ${parentTaskId}`);
  1904 + }
1881 1905  
1882 1906 // company_id 这一列冗余存在的**唯一**理由是让调度器不必 JOIN；让调用方各传各的，
1883 1907 // 就等于给这份冗余留了一条能对不上的路。默认从 goal 抄，传了也以 goal 为准的那种「以防万一」
... ... @@ -1902,8 +1926,8 @@ function createTask({
1902 1926 const ins = db.prepare(`
1903 1927 INSERT INTO tasks (id, goal_id, company_id, seq, title, description, status,
1904 1928 execution_mode, depends_on, priority, budget_json, report_to, created_by,
1905   - created_at, updated_at)
1906   - VALUES (?, ?, ?, ?, ?, ?, 'draft', ?, ?, ?, ?, ?, ?, ?, ?)
  1929 + parent_task_id, acceptance_mode, created_at, updated_at)
  1930 + VALUES (?, ?, ?, ?, ?, ?, 'draft', ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
1907 1931 `);
1908 1932 const id = insertWithFreshId('tasks', genTaskId, (tid) => ins.run(
1909 1933 tid, goalId, String(cid), nextSeq, String(title), String(description),
... ... @@ -1911,7 +1935,7 @@ function createTask({
1911 1935 // report_to 不落库就等于没有：请求作用域的闭包活不过一次排队（§四.7 禁令二）。
1912 1936 // goal 上有就继承下来，别让每个调用方各记一遍。
1913 1937 reportTo || goal.report_to || null,
1914   - createdBy, now, now
  1938 + createdBy, parentTaskId, acceptanceMode, now, now
1915 1939 ));
1916 1940 return getTask(id);
1917 1941 }
... ... @@ -1937,7 +1961,9 @@ function listGoalTasks(goalId, { includeArchived = false } = {}) {
1937 1961 * 这里再写一份就是第二个持有者 —— canDispatch 的取值域被前端复述了一遍、还多写一个值，
1938 1962 * 导致公司失败一次后再也下不了任务，就是这么来的。要位次找调度器要。
1939 1963 */
1940   -function listCompanyTasks(companyId, { status = null, goalId = null, includeArchived = false, limit = null } = {}) {
  1964 +function listCompanyTasks(companyId, {
  1965 + status = null, goalId = null, parentTaskId = null, includeArchived = false, limit = null,
  1966 +} = {}) {
1941 1967 const where = ['company_id = @companyId'];
1942 1968 const params = { companyId };
1943 1969 if (status) {
... ... @@ -1948,6 +1974,12 @@ function listCompanyTasks(companyId, { status = null, goalId = null, includeArch
1948 1974 where.push('goal_id = @goalId');
1949 1975 params.goalId = goalId;
1950 1976 }
  1977 + // 43 号文档 Phase 3：coder-validator 用它列出「这个 itemized 任务物化出了哪些子任务」，
  1978 + // 才知道要逐条上报哪几个 taskId
  1979 + if (parentTaskId) {
  1980 + where.push('parent_task_id = @parentTaskId');
  1981 + params.parentTaskId = parentTaskId;
  1982 + }
1951 1983 if (!includeArchived) where.push('archived_at IS NULL');
1952 1984 const lim = Number.isInteger(limit) && limit > 0 ? ` LIMIT ${limit}` : '';
1953 1985 return getDb()
... ... @@ -2084,6 +2116,31 @@ function settleTaskFromRun(taskId, runId, status) {
2084 2116 }
2085 2117  
2086 2118 /**
  2119 + * 43 号文档 Phase 3：coder-validator 逐条上报子任务验收结果的落库口。
  2120 + *
  2121 + * 与 `settleTaskFromRun` 同款条件更新（终态幂等闸门）：子任务可能因为 coder-validator
  2122 + * 被 retry 而重复上报，已经是终态的行不该被后一次调用覆盖。**只服务子任务**——
  2123 + * `parent_task_id IS NOT NULL` 这道 WHERE 挡住顶层 task（它的终态走 run 收敛那条路，
  2124 + * 不该被这个端点绕开）。
  2125 + *
  2126 + * @returns {number} 受影响行数；0 = 已经是终态 / 不是子任务，调用方据此判断这次上报有没有生效
  2127 + */
  2128 +function settleSubtaskResult(taskId, status, summary = null) {
  2129 + if (!['completed', 'failed'].includes(status)) {
  2130 + throw new Error(`settleSubtaskResult: status 只能是 'completed' 或 'failed'，收到: ${status}`);
  2131 + }
  2132 + const now = new Date().toISOString();
  2133 + return getDb()
  2134 + .prepare(`
  2135 + UPDATE tasks SET status = @status, summary = @summary, finished_at = @now, updated_at = @now
  2136 + WHERE id = @id
  2137 + AND parent_task_id IS NOT NULL
  2138 + AND status NOT IN (${TASK_TERMINAL_STATUS.map((s) => `'${s}'`).join(', ')})
  2139 + `)
  2140 + .run({ id: taskId, status, summary, now }).changes;
  2141 +}
  2142 +
  2143 +/**
2087 2144 * 「上游已经不可能满足了」这个 blocked 的原因前缀（27-P3C §五.1.2）。
2088 2145 *
2089 2146 * 它同时是**判据**：只有 `blocked_reason` 以它开头的 blocked task 才是调度器**推导**出来的，
... ... @@ -2715,6 +2772,7 @@ module.exports = {
2715 2772 taskProgress,
2716 2773 maxTaskSeq,
2717 2774 settleTaskFromRun,
  2775 + settleSubtaskResult,
2718 2776 GRAPH_TAKEOVER_ASSIGNEE,
2719 2777 // 批 3 排队：三条都是条件更新，调用方靠 changes 判「是不是我做的」
2720 2778 claimQueuedTask,
... ...
server/tests/unit/company-goal-task-routes.test.js
  View file @81e28e5
... ... @@ -400,7 +400,8 @@ describe(&#39;company goal/task routes（27-P3C §六）&#39;, () =&gt; {
400 400  
401 401 const ok = validatePlannedTasks([{ seq: 1, title: 'a', description: 'A', depends_on: [] }]);
402 402 expect(ok.ok).toBe(true);
403   - expect(ok.specs[0]).toEqual({ seq: 1, title: 'a', description: 'A', depends_on: [] });
  403 + // 43 号文档：acceptance_mode 没写就缺省 'holistic'
  404 + expect(ok.specs[0]).toEqual({ seq: 1, title: 'a', description: 'A', depends_on: [], acceptance_mode: 'holistic' });
404 405  
405 406 const rules = (raw) => validatePlannedTasks(raw).errors.map((e) => e.rule);
406 407 // seq 与数组顺序错位：错位后 depends_on 引的是另一条 task，而那条错误依赖完全合法，
... ... @@ -415,6 +416,9 @@ describe(&#39;company goal/task routes（27-P3C §六）&#39;, () =&gt; {
415 416 expect(rules(Array.from({ length: 9 }, (_, i) => ({ seq: i + 1, description: 'x', depends_on: [] }))))
416 417 .toContain('limit');
417 418 expect(rules([{ seq: 1, description: 'A', depends_on: [], mode: 'auto' }])).toContain('schema');
  419 + // 43 号文档：acceptance_mode 是允许出现的第五个键，itemized 合法、乱写值按 schema 打回
  420 + expect(validatePlannedTasks([{ seq: 1, description: 'A', depends_on: [], acceptance_mode: 'itemized' }]).ok).toBe(true);
  421 + expect(rules([{ seq: 1, description: 'A', depends_on: [], acceptance_mode: 'bogus' }])).toContain('schema');
418 422  
419 423 // 正向引用（第 1 条依赖第 2 条）不成环，是合法输入 —— 批 1 缺陷 4 就是被它咬的
420 424 expect(validatePlannedTasks([
... ...
server/tests/unit/graph-engine-fail-reason.test.js
  View file @81e28e5
... ... @@ -123,7 +123,7 @@ describe(&#39;引擎自判失败的 fail_reason 与失败上下文（W12 补完 / W9
123 123 // W12 补完 · 三类引擎自判失败都在 fail_reason 上留名
124 124 // ────────────────────────────────────────────────────────────────
125 125  
126   - it('取值域：六个引擎取值与 agent 的归因取值域**不重叠**（复用会劫持精确 fail 边的路由）', () => {
  126 + it('取值域：七个引擎取值与 agent 的归因取值域**不重叠**（复用会劫持精确 fail 边的路由）', () => {
127 127 const engineReasons = Object.values(engine.ENGINE_FAIL_REASONS);
128 128 expect(engineReasons).toEqual([
129 129 'node_error', 'boundary_escape', 'child_run_failed',
... ... @@ -131,6 +131,9 @@ describe(&#39;引擎自判失败的 fail_reason 与失败上下文（W12 补完 / W9
131 131 'missing_required_input', 'produces_missing',
132 132 // 35 号文档提案 A：本体完整性闸门（runClaimedNode 派发前检查）新增的取值
133 133 'body_not_ready',
  134 + // 43 号文档 Phase 3：coder-validator 判自己 success 但 itemized 任务的子任务没全部
  135 + // completed 时新增的取值（settleNode 的 success 判定里，与上面两个契约闸门同一处）
  136 + 'subtasks_incomplete',
134 137 ]);
135 138 // infra_flake 在 routeFailure 里有特判（原地重跑、不烧计数）。任何一个引擎取值撞上它
136 139 // 都会让确定性失败（如 Agent not found）原地重跑到预算耗尽。
... ...
server/tests/unit/task-acceptance-mode.test.js 0 → 100644
  View file @81e28e5
  1 +/**
  2 + * 43 号文档 Phase 0：`tasks.acceptance_mode` + `createTask({parentTaskId})` 的落库校验。
  3 + *
  4 + * 隔离：先设 GRAPH_DB_PATH 再 require（清 require.cache），仓库 data/graph.sqlite 全程不碰
  5 + * ——写法与 graph-edge-contracts.test.js 同源。
  6 + */
  7 +import { describe, it, expect, beforeAll, afterAll } from 'vitest';
  8 +import fs from 'fs';
  9 +
  10 +const TEST_DB_PATH = '/tmp/test-task-acceptance-mode.sqlite';
  11 +const DB_FILES = [TEST_DB_PATH, `${TEST_DB_PATH}-shm`, `${TEST_DB_PATH}-wal`];
  12 +
  13 +describe('43 号文档 Phase 0：acceptance_mode / parentTaskId', () => {
  14 + let wdb;
  15 +
  16 + beforeAll(() => {
  17 + for (const f of DB_FILES) { try { fs.unlinkSync(f); } catch {} }
  18 + process.env.GRAPH_DB_PATH = TEST_DB_PATH;
  19 + delete require.cache[require.resolve('../../services/graph-db')];
  20 + delete require.cache[require.resolve('../../services/work-graph-db')];
  21 + wdb = require('../../services/work-graph-db');
  22 + });
  23 +
  24 + afterAll(() => {
  25 + for (const f of DB_FILES) { try { fs.unlinkSync(f); } catch {} }
  26 + delete process.env.GRAPH_DB_PATH;
  27 + delete require.cache[require.resolve('../../services/graph-db')];
  28 + delete require.cache[require.resolve('../../services/work-graph-db')];
  29 + });
  30 +
  31 + function goalId() {
  32 + const g = wdb.createGoal({ companyId: 'co-amode', title: 'g', description: 'd' });
  33 + return g.id;
  34 + }
  35 +
  36 + it('缺省 acceptance_mode=holistic、parent_task_id=null（图流水线现状不变）', () => {
  37 + const t = wdb.createTask({ goalId: goalId(), title: 't', description: 'd' });
  38 + expect(t.acceptance_mode).toBe('holistic');
  39 + expect(t.parent_task_id).toBeNull();
  40 + });
  41 +
  42 + it('可以显式建一条 itemized 的顶层 task', () => {
  43 + const t = wdb.createTask({ goalId: goalId(), title: 't', description: 'd', acceptanceMode: 'itemized' });
  44 + expect(t.acceptance_mode).toBe('itemized');
  45 + });
  46 +
  47 + it('非法 acceptanceMode 直接拒', () => {
  48 + expect(() => wdb.createTask({ goalId: goalId(), title: 't', description: 'd', acceptanceMode: 'bogus' }))
  49 + .toThrow(/acceptanceMode 非法/);
  50 + });
  51 +
  52 + it('子任务：parentTaskId 指回父任务，acceptance_mode 恒 holistic', () => {
  53 + const gid = goalId();
  54 + const parent = wdb.createTask({ goalId: gid, title: 'parent', description: 'd', acceptanceMode: 'itemized' });
  55 + const child = wdb.createTask({ goalId: gid, title: 'child A.1', description: 'd', parentTaskId: parent.id });
  56 + expect(child.parent_task_id).toBe(parent.id);
  57 + expect(child.acceptance_mode).toBe('holistic');
  58 + });
  59 +
  60 + it('子任务不允许递归声明 itemized（不支持二级拆分）', () => {
  61 + const gid = goalId();
  62 + const parent = wdb.createTask({ goalId: gid, title: 'parent', description: 'd' });
  63 + expect(() => wdb.createTask({
  64 + goalId: gid, title: 'child', description: 'd', parentTaskId: parent.id, acceptanceMode: 'itemized',
  65 + })).toThrow(/不支持递归拆分/);
  66 + });
  67 +
  68 + it('parentTaskId 指向不存在的 task 直接拒，不静默建成孤儿行', () => {
  69 + expect(() => wdb.createTask({ goalId: goalId(), title: 't', description: 'd', parentTaskId: 'T-not-exist' }))
  70 + .toThrow(/parentTaskId 不存在/);
  71 + });
  72 +});
... ...
server/tests/unit/task-decomposition-materialize.test.js 0 → 100644
  View file @81e28e5
  1 +/**
  2 + * 43 号文档 Phase 2：org-planner 节点结算 success 后，把 acceptance.md 物化成子任务。
  3 + *
  4 + * org 层节点全是 subgraph（isSubgraphNode 恒真），真正的产出在 workgraph-planning 展开出的
  5 + * 子 run 里——所以这里跟 goal-task-acceptance.test.js 同源，用 `setPlanWorkGraph` 注入假
  6 + * 规划（返回一张手造的单节点 work graph），再用 `setAgentExecutor` 注入那个节点的假执行，
  7 + * 不真起 Claude CLI。
  8 + */
  9 +import { describe, it, expect, beforeAll, afterAll } from 'vitest';
  10 +import fs from 'fs';
  11 +import os from 'os';
  12 +import path from 'path';
  13 +
  14 +const TEST_DB_PATH = '/tmp/test-task-decomp-materialize.sqlite';
  15 +const DB_FILES = [TEST_DB_PATH, `${TEST_DB_PATH}-shm`, `${TEST_DB_PATH}-wal`];
  16 +const MODULES = [
  17 + '../../services/graph-db',
  18 + '../../services/graph-service',
  19 + '../../services/org-graph-service',
  20 + '../../services/work-graph-db',
  21 + '../../services/graph-run-sse',
  22 + '../../services/graph-engine',
  23 +];
  24 +
  25 +const ORG_NODES = ['org-planner', 'org-coder', 'org-validator'];
  26 +const ORG_EDGES = [
  27 + { from: 'org-planner', to: 'org-coder', condition: 'success' },
  28 + { from: 'org-coder', to: 'org-validator', condition: 'success' },
  29 +];
  30 +
  31 +const ACCEPTANCE_MD = `# 验收清单
  32 +
  33 +| # | 验收项 | 判定方式 | pass 条件 |
  34 +|---|--------|----------|-----------|
  35 +| 1 | 方向键控制移动 | 手动操作 | 蛇按方向键移动 |
  36 +| 2 | 吃到食物加分 | 手动操作 | 分数 +1 |
  37 +`;
  38 +
  39 +describe('43 号文档 Phase 2：acceptance.md → 子任务物化', () => {
  40 + let wdb;
  41 + let org;
  42 + let engine;
  43 + let runsDir;
  44 +
  45 + beforeAll(() => {
  46 + for (const f of DB_FILES) { try { fs.unlinkSync(f); } catch {} }
  47 + process.env.GRAPH_DB_PATH = TEST_DB_PATH;
  48 + runsDir = fs.mkdtempSync(path.join(os.tmpdir(), 'task-decomp-runs-'));
  49 + process.env.GRAPH_RUNS_DIR = runsDir;
  50 + for (const m of MODULES) delete require.cache[require.resolve(m)];
  51 + wdb = require('../../services/work-graph-db');
  52 + org = require('../../services/org-graph-service');
  53 + engine = require('../../services/graph-engine');
  54 + });
  55 +
  56 + afterAll(() => {
  57 + for (const f of DB_FILES) { try { fs.unlinkSync(f); } catch {} }
  58 + delete process.env.GRAPH_DB_PATH;
  59 + try { fs.rmSync(runsDir, { recursive: true, force: true }); } catch {}
  60 + delete process.env.GRAPH_RUNS_DIR;
  61 + for (const m of MODULES) delete require.cache[require.resolve(m)];
  62 + });
  63 +
  64 + function ensureAgent(id) {
  65 + const db = wdb.getDb();
  66 + const now = new Date().toISOString();
  67 + db.prepare(`INSERT OR IGNORE INTO system_agents
  68 + (id, name, scope, owner_company_id, legacy_path, status, created_at, updated_at)
  69 + VALUES (?, ?, 'public', NULL, ?, 'active', ?, ?)`)
  70 + .run(id, id, `system/agents/${id}`, now, now);
  71 + }
  72 +
  73 + /** 建一家公司的 org 图 + 一条 task，起一条 org run，跑到 org-planner（含它展开的子图）结算为止 */
  74 + async function setupAndRunPlanner(companyId, { acceptanceMode = 'itemized', writeFile = true } = {}) {
  75 + expect(org.writeGraph(companyId, { nodes: ORG_NODES, edges: ORG_EDGES }).ok).toBe(true);
  76 + ensureAgent('planner-worker');
  77 +
  78 + const goal = wdb.createGoal({ companyId, title: 'g', description: '贪吃蛇游戏' });
  79 + const task = wdb.createTask({
  80 + goalId: goal.id, title: '实现贪吃蛇', description: 'd', acceptanceMode,
  81 + });
  82 +
  83 + const run = wdb.createRun({ graphKind: 'org', graphId: companyId, companyId, taskId: task.id });
  84 + engine.markRunReady(run.id);
  85 + engine.startRun(run.id, { mode: 'manual' });
  86 +
  87 + engine.setPlanWorkGraph(async () => {
  88 + const g = wdb.createWorkGraph({
  89 + companyId, nodes: [{ nodeName: 'planner-worker', systemAgentId: 'planner-worker' }], edges: [],
  90 + });
  91 + expect(g.errors || []).toEqual([]);
  92 + return { workGraphId: g.id };
  93 + });
  94 + let childRunId;
  95 + try {
  96 + const planned = await engine.nextStep(run.id); // org-planner：规划出子图，父节点转 running 等子 run
  97 + childRunId = planned.node && planned.node.childRunId;
  98 + } finally {
  99 + engine.setPlanWorkGraph(null);
  100 + }
  101 + expect(childRunId).toBeTruthy();
  102 +
  103 + engine.setAgentExecutor(async (ctx) => {
  104 + const dir = path.join(runsDir, ctx.run.root_run_id, 'nodes', ctx.nodeRunId);
  105 + fs.mkdirSync(dir, { recursive: true });
  106 + if (writeFile) fs.writeFileSync(path.join(dir, 'acceptance.md'), ACCEPTANCE_MD);
  107 + return { status: 'success', outputRef: dir };
  108 + });
  109 + try {
  110 + await engine.advanceOne(childRunId); // 子图里唯一的那个节点
  111 + } finally {
  112 + engine.setAgentExecutor(null);
  113 + }
  114 + return { task, run, childRunId };
  115 + }
  116 +
  117 + it('itemized + acceptance.md 存在 → org-planner 结算 success 后按表格行数物化子任务', async () => {
  118 + const { task, run } = await setupAndRunPlanner('co-materialize-1');
  119 + const plannerNode = wdb.getDb().prepare(`
  120 + SELECT status FROM graph_run_nodes WHERE run_id = ?
  121 + AND def_node_id = (SELECT id FROM org_graph_nodes WHERE company_id='co-materialize-1' AND role_name='org-planner')
  122 + `).get(run.id);
  123 + expect(plannerNode.status).toBe('success'); // 前提：子图真的收敛回了父节点
  124 +
  125 + const children = wdb.getDb()
  126 + .prepare(`SELECT * FROM tasks WHERE parent_task_id = ? ORDER BY created_at`)
  127 + .all(task.id);
  128 + expect(children).toHaveLength(2);
  129 + expect(children[0].title).toBe('方向键控制移动');
  130 + expect(children[0].acceptance_mode).toBe('holistic');
  131 + expect(children[0].description).toContain('手动操作');
  132 + expect(children[0].description).toContain('蛇按方向键移动');
  133 + expect(children[1].title).toBe('吃到食物加分');
  134 + });
  135 +
  136 + it('holistic 任务：org-planner 成功结算，不物化任何子任务', async () => {
  137 + const { task } = await setupAndRunPlanner('co-materialize-2', { acceptanceMode: 'holistic' });
  138 + const n = wdb.getDb().prepare(`SELECT COUNT(*) AS n FROM tasks WHERE parent_task_id = ?`).get(task.id).n;
  139 + expect(n).toBe(0);
  140 + });
  141 +
  142 + it('itemized 但 acceptance.md 不存在：org-planner 仍判 success，不物化子任务（软失败，不拖累主产出）', async () => {
  143 + const { task, run } = await setupAndRunPlanner('co-materialize-3', { writeFile: false });
  144 + const n = wdb.getDb().prepare(`SELECT COUNT(*) AS n FROM tasks WHERE parent_task_id = ?`).get(task.id).n;
  145 + expect(n).toBe(0);
  146 + const plannerNode = wdb.getDb().prepare(`
  147 + SELECT status FROM graph_run_nodes WHERE run_id = ?
  148 + AND def_node_id = (SELECT id FROM org_graph_nodes WHERE company_id='co-materialize-3' AND role_name='org-planner')
  149 + `).get(run.id);
  150 + expect(plannerNode.status).toBe('success'); // 找不到 acceptance.md 不该把这一步打成 fail
  151 + });
  152 +});
... ...
server/tests/unit/task-decomposition-validator-gate.test.js 0 → 100644
  View file @81e28e5
  1 +/**
  2 + * 43 号文档 Phase 3：coder-validator 判自己 success 之前，子任务必须全部 completed
  3 + * 才认；以及 settleSubtaskResult 这个落库口本身的条件更新/幂等/校验。
  4 + */
  5 +import { describe, it, expect, beforeAll, afterAll } from 'vitest';
  6 +import fs from 'fs';
  7 +import os from 'os';
  8 +import path from 'path';
  9 +
  10 +const TEST_DB_PATH = '/tmp/test-task-decomp-validator-gate.sqlite';
  11 +const DB_FILES = [TEST_DB_PATH, `${TEST_DB_PATH}-shm`, `${TEST_DB_PATH}-wal`];
  12 +const MODULES = [
  13 + '../../services/graph-db',
  14 + '../../services/graph-service',
  15 + '../../services/org-graph-service',
  16 + '../../services/work-graph-db',
  17 + '../../services/graph-run-sse',
  18 + '../../services/graph-engine',
  19 +];
  20 +
  21 +describe('43 号文档 Phase 3', () => {
  22 + let wdb;
  23 + let engine;
  24 + let runsDir;
  25 +
  26 + beforeAll(() => {
  27 + for (const f of DB_FILES) { try { fs.unlinkSync(f); } catch {} }
  28 + process.env.GRAPH_DB_PATH = TEST_DB_PATH;
  29 + runsDir = fs.mkdtempSync(path.join(os.tmpdir(), 'task-decomp-gate-runs-'));
  30 + process.env.GRAPH_RUNS_DIR = runsDir;
  31 + for (const m of MODULES) delete require.cache[require.resolve(m)];
  32 + wdb = require('../../services/work-graph-db');
  33 + engine = require('../../services/graph-engine');
  34 + });
  35 +
  36 + afterAll(() => {
  37 + for (const f of DB_FILES) { try { fs.unlinkSync(f); } catch {} }
  38 + delete process.env.GRAPH_DB_PATH;
  39 + try { fs.rmSync(runsDir, { recursive: true, force: true }); } catch {}
  40 + delete process.env.GRAPH_RUNS_DIR;
  41 + for (const m of MODULES) delete require.cache[require.resolve(m)];
  42 + });
  43 +
  44 + function ensureAgent(id) {
  45 + const db = wdb.getDb();
  46 + const now = new Date().toISOString();
  47 + db.prepare(`INSERT OR IGNORE INTO system_agents
  48 + (id, name, scope, owner_company_id, legacy_path, status, created_at, updated_at)
  49 + VALUES (?, ?, 'public', NULL, ?, 'active', ?, ?)`)
  50 + .run(id, id, `system/agents/${id}`, now, now);
  51 + }
  52 +
  53 + // ── settleSubtaskResult 本身 ─────────────────────────────────────
  54 +
  55 + it('settleSubtaskResult：非法 status 直接拒', () => {
  56 + expect(() => wdb.settleSubtaskResult('T-whatever', 'running')).toThrow(/status 只能是/);
  57 + });
  58 +
  59 + it('settleSubtaskResult：不是子任务（parent_task_id 为空）不生效，changes=0', () => {
  60 + const goal = wdb.createGoal({ companyId: 'co-gate-1', title: 'g', description: 'd' });
  61 + const top = wdb.createTask({ goalId: goal.id, title: 't', description: 'd' });
  62 + const changed = wdb.settleSubtaskResult(top.id, 'completed');
  63 + expect(changed).toBe(0);
  64 + expect(wdb.getTask(top.id).status).toBe('draft'); // 没被动过
  65 + });
  66 +
  67 + it('settleSubtaskResult：正常上报 + 终态幂等（第二次不同结果上报不生效）', () => {
  68 + const goal = wdb.createGoal({ companyId: 'co-gate-2', title: 'g', description: 'd' });
  69 + const parent = wdb.createTask({ goalId: goal.id, title: 'p', description: 'd', acceptanceMode: 'itemized' });
  70 + const child = wdb.createTask({ goalId: goal.id, title: 'c', description: 'd', parentTaskId: parent.id });
  71 +
  72 + expect(wdb.settleSubtaskResult(child.id, 'completed', '通过')).toBe(1);
  73 + const after1 = wdb.getTask(child.id);
  74 + expect(after1.status).toBe('completed');
  75 + expect(after1.summary).toBe('通过');
  76 + expect(after1.finished_at).toBeTruthy();
  77 +
  78 + // 已经是终态，再上报 failed 不该覆盖——防的是 coder-validator 因 retry 重复上报
  79 + expect(wdb.settleSubtaskResult(child.id, 'failed', '改判')).toBe(0);
  80 + expect(wdb.getTask(child.id).status).toBe('completed');
  81 + });
  82 +
  83 + // ── 引擎侧的闸门：coder-validator 判 success 前核子任务 ─────────────
  84 +
  85 + async function runValidator(companyId, taskId) {
  86 + ensureAgent('coder-validator');
  87 + const g = wdb.createWorkGraph({
  88 + companyId,
  89 + taskId,
  90 + nodes: [{ nodeName: 'v', systemAgentId: 'coder-validator' }],
  91 + edges: [],
  92 + });
  93 + expect(g.errors || []).toEqual([]);
  94 + const run = wdb.createRun({ graphKind: 'work', graphId: g.id, companyId, taskId });
  95 + engine.markRunReady(run.id);
  96 + engine.startRun(run.id, { mode: 'manual' });
  97 + engine.setAgentExecutor(async () => ({ status: 'success' }));
  98 + let out;
  99 + try {
  100 + out = await engine.advanceOne(run.id);
  101 + } finally {
  102 + engine.setAgentExecutor(null);
  103 + }
  104 + return out;
  105 + }
  106 +
  107 + it('itemized 任务 + 子任务还没全部 completed → coder-validator 判自己 success 但被引擎打回 fail', async () => {
  108 + const companyId = 'co-gate-3';
  109 + const goal = wdb.createGoal({ companyId, title: 'g', description: 'd' });
  110 + const parent = wdb.createTask({ goalId: goal.id, title: 'p', description: 'd', acceptanceMode: 'itemized' });
  111 + const c1 = wdb.createTask({ goalId: goal.id, title: 'c1', description: 'd', parentTaskId: parent.id });
  112 + wdb.createTask({ goalId: goal.id, title: 'c2', description: 'd', parentTaskId: parent.id });
  113 + wdb.settleSubtaskResult(c1.id, 'completed'); // 只完成一半
  114 +
  115 + const out = await runValidator(companyId, parent.id);
  116 + // 单节点图没有兜底边可退，fail 之后引擎会继续把它收敛成 blocked（等人）——
  117 + // 这里要验的是「没被判 success」+「归因是 subtasks_incomplete」，不是具体停在哪个终态
  118 + expect(out.node.status).not.toBe('success');
  119 + expect(out.node.failReason).toBe('subtasks_incomplete');
  120 + });
  121 +
  122 + it('itemized 任务 + 子任务全部 completed → coder-validator 正常判 success', async () => {
  123 + const companyId = 'co-gate-4';
  124 + const goal = wdb.createGoal({ companyId, title: 'g', description: 'd' });
  125 + const parent = wdb.createTask({ goalId: goal.id, title: 'p', description: 'd', acceptanceMode: 'itemized' });
  126 + const c1 = wdb.createTask({ goalId: goal.id, title: 'c1', description: 'd', parentTaskId: parent.id });
  127 + const c2 = wdb.createTask({ goalId: goal.id, title: 'c2', description: 'd', parentTaskId: parent.id });
  128 + wdb.settleSubtaskResult(c1.id, 'completed');
  129 + wdb.settleSubtaskResult(c2.id, 'completed');
  130 +
  131 + const out = await runValidator(companyId, parent.id);
  132 + expect(out.node.status).toBe('success');
  133 + });
  134 +
  135 + it('holistic 任务（没有子任务）：闸门不生效，success 照常通过', async () => {
  136 + const companyId = 'co-gate-5';
  137 + const goal = wdb.createGoal({ companyId, title: 'g', description: 'd' });
  138 + const task = wdb.createTask({ goalId: goal.id, title: 't', description: 'd' }); // 缺省 holistic
  139 +
  140 + const out = await runValidator(companyId, task.id);
  141 + expect(out.node.status).toBe('success');
  142 + });
  143 +});
... ...
system/agents/coder-validator/agent.md
  View file @81e28e5
... ... @@ -68,6 +68,31 @@ node server/services/goal-contract.js run --target &lt;雿迤撉漱隞頝臬
68 68 **撠梢嚗** 瘥蝏嚗 / 銝 + 霂嚗挾 `辣:銵`嚗
69 69 憟漲憯唳葵閬笆摨閮ㄟ葵停閬嚗蜓瘚停銵
70 70  
  71 +### Step 4bis 繚 餈 task itemized 遙閬銝嚗43 ﹝嚗
  72 +
  73 +銝銝迤撉 task 瓷◤遙嚗itemized` 遙holistic` 瘝⊥
  74 +
  75 +```bash
  76 +node bin/lemon.js task subtasks --companyId <ID> --taskId <隞餃ID>
  77 +```
  78 +
  79 +餈征” = 餈 task `holistic`嚗歲餈甇伐 Step 4 acceptance_criteria 韏啜
  80 +
  81 +餈征”嚗**瘥摮遙停撖孵撉**嚗rg-planner 撠暹 acceptance.md
  82 + Step 2/3 瘜遛嚗摰**瘥摰撠曹銝甈**嚗
  83 +
  84 +```bash
  85 +node bin/lemon.js task subtask-result --companyId <ID> --taskId <摮遙ID> --status completed --summary "霂"
  86 +node bin/lemon.js task subtask-result --companyId <ID> --taskId <摮遙ID> --status failed --summary "辣:銵 + 銝"
  87 +```
  88 +
  89 + **餈甇乩兮鞎蝖祇**嚗雿銋銝 task 遙
  90 +銝****鈭 `completed` 銝瘝⊥鈭 `failed`嚗頧桀捏
  91 +`"verdict": "passed"` 餈隡◤撘**撘箏憭梯揖**嚗敶撘撌勗雿
  92 +雿餈遢銵券摰fail_reason` ‵撘”嚗澆摰
  93 +`attempt-N.json` `checks[]` 蝏犖恣霈⊥嚗**瘝⊥遙雿蝡臭誨圾**
  94 +迤霂港雿瓷銝餈隞日銝
  95 +
71 96 ### Step 5 繚 鈭批
72 97  
73 98 fail `remediation_note` 敹◆霈 coder 撘撌伐**`辣:銵` + 蛹 + 憟賭**
... ... @@ -170,6 +195,8 @@ fail `remediation_note` 敹◆霈 coder 撘撌伐**`辣:銵`
170 195 mock ◤瘚笆鞊 / 閬辣嚗
171 196 4. acceptance_criteria 餈鈭撠望銵
172 197 憟漲憯唳葵/秤閮
  198 +4bis. 餈 `task subtasks` 鈭遙銝瘥靚 `task subtask-result`
  199 + 銝嚗 attempt-N.json checks[] 撠曹誑銝箏
173 200 5. 瓷敢憿箸鈭銵誨捂鈭停瘝⊥洵鈭
174 201 6. fail_reason ‵ impl_bug / input_underspecified / infra_flake / null 銋
175 202 憛 infra_flake 餈漣摰 impl_bug嚗
... ...
system/agents/task-planning/agent.md
  View file @81e28e5
... ... @@ -3,11 +3,11 @@
3 3 ## ⚡ 硬约束（这 9 条排在最前面，因为它们是判「这一轮算不算数」的全部依据）
4 4  
5 5 1. **你的产出是一个 JSON 数组，不是别的任何东西。** 形状固定：
6   - `[{ "seq": 1, "title": "…", "description": "…", "depends_on": [] }]`
  6 + `[{ "seq": 1, "title": "…", "description": "…", "depends_on": [], "acceptance_mode": "holistic" }]`
7 7 2. **`depends_on` 里只能出现本次产出的 `seq` 数字**（1-based）。**不许写 task id** —— id 由服务端在你交回之后才生成，你根本看不到。写字符串 id 一定被打回。
8 8 3. **`seq` 必须是 1..N 连续整数、不重复、按你数组的顺序排。** 别跳号，别从 0 开始。
9 9 4. **条数上限 8。** 超过 8 条，说明你在拆步骤而不是拆任务（见「Step 2」）。
10   -5. **只输出这四个字段。** 不许产出 `id` / `taskId` / `status` / `mode` / `budget` / `priority` / `agent` / `assignee` —— 这些要么由服务端生成，要么由人在界面上定，你写了会被当成脏字段打回。
  10 +5. **只输出这五个字段，其中 `acceptance_mode` 可以不写（缺省 `"holistic"`）。** 不许产出 `id` / `taskId` / `status` / `mode` / `budget` / `priority` / `agent` / `assignee` —— 这些要么由服务端生成，要么由人在界面上定，你写了会被当成脏字段打回。`acceptance_mode` 是唯一的例外：它需要你的语义判断，服务端给不出默认值以外的答案，见「Step 2bis」。
11 11 6. **JSON 代码块必须是你回复的最后一段。** 拆分理由写在它**前面**的正文里。代码块之后不要再写任何字。
12 12 7. **一条也算合法产出。** goal 本身就是一件事时，输出**恰好 1 条** `seq:1 / depends_on:[]`。这不是失败，是正确答案（见「Step 2」的不拆信号）。
13 13 8. **不许发明需求。** goal 描述里没有的东西，一个字都不许出现在你的 task 里。拆分是**切分**，不是扩写、不是补全、不是「顺便建议」。
... ... @@ -89,6 +89,19 @@
89 89  
90 90 ---
91 91  
  92 +## Step 2bis · 这条 task 的验收要不要拆成子任务逐条判（`acceptance_mode`）
  93 +
  94 +这是**这条 task 内部**的判断，跟 Step 2「要不要拆成多条 task」是同一个轴（够不够独立成立、值不值得单独验收），只是尺度缩小了一级——Step 2 判的是「这个 goal 该拆成几条 task」，这里判的是「这一条 task 的验收标准该不该拆成几条子任务」。
  95 +
  96 +- **`"holistic"`（缺省，不确定就选它）**：这条 task 是一个不可再分的交付物，验收时一次性给总分。绝大多数 task 都是这个。
  97 +- **`"itemized"`**：这条 task 对外是**单一交付物**（不满足 Step 2 拆多条 task 的条件），但它的验收标准天然由**多条互相独立、可以各自单独判定通过与否**的条目组成——拿掉其中一条，剩下的验收条目仍然各自成立。org-planner 收尾时会把这些验收条目物化成子任务，挂在看板上，coder-validator 会逐条判而不是给总分。
  98 +
  99 +例子：「实现一个贪吃蛇小游戏」是一个交付物（不该按 Step 2 拆成「方向控制」「计分」「碰撞」「重开」四条 task——那是同一个交付物的四个功能点，不是四个可以分开验收的交付物），但它的验收标准（方向键控制、吃到食物加分、碰撞结束游戏、可以重新开始）彼此独立、可以逐条判定——这种情况写 `"itemized"`。反例：「产出可跑通的后端服务」这条 task 的验收标准可能也有好几条（能启动、接口能上传、接口能下载、错误有正确返回码），但如果这些条目本身互相依赖、拆开单独判没有意义（比如"能上传"离开"能启动"根本无法验证），就该留 `"holistic"`。
  100 +
  101 +**判断错的代价是不对称的**：错误地写 `"itemized"`（验收标准其实互相依赖）会让后续验收拆出没法独立成立的子任务，比漏写、保守选 `"holistic"` 的代价更高。拿不准就留 `"holistic"`。
  102 +
  103 +---
  104 +
92 105 ## Step 3 · 定依赖
93 106  
94 107 `depends_on` 只写**真的拿不到前一条的产物就开不了工**的那种依赖。
... ... @@ -100,7 +113,7 @@
100 113  
101 114 ---
102 115  
103   -## Step 4 · 自查（六条，逐条对着你写好的 JSON 过一遍再交）
  116 +## Step 4 · 自查（七条，逐条对着你写好的 JSON 过一遍再交）
104 117  
105 118 | # | 检查 | 不过怎么办 |
106 119 |---|---|---|
... ... @@ -108,8 +121,9 @@
108 121 | 2 | `depends_on` 每个元素都是 1..N 里的整数、不等于自己、无环 | 删掉引用不到的 |
109 122 | 3 | N ≤ 8 | 回 Step 2 合并 |
110 123 | 4 | 每条 `description` 单独读得懂、写清了「做完什么算达成」 | 补全背景，别写跨条引用 |
111   -| 5 | 四个字段之外没有多余键；`depends_on` 是数组（哪怕是空的 `[]`）也必须在 | 删掉多余键，补上 `[]` |
  124 +| 5 | 五个字段之外没有多余键；`depends_on` 是数组（哪怕是空的 `[]`）也必须在 | 删掉多余键，补上 `[]` |
112 125 | 6 | N 条加起来正好覆盖 goal，没漏、**也没多发明** | 漏了补一条；多了删掉 |
  126 +| 7 | 写了 `"itemized"` 的每一条，验收标准确实由几条互相独立的条目组成，不是硬凑的 | 拿不准就改回 `"holistic"`（省略也一样） |
113 127  
114 128 ---
115 129  
... ... @@ -142,6 +156,18 @@
142 156 ]
143 157 ```
144 158  
  159 +`acceptance_mode` 不写就是 `"holistic"`，上面三条都省了。只有验收标准天然拆成几条互相独立条目的单一交付物才需要显式写 `"itemized"`（见 Step 2bis 的贪吃蛇例子）：
  160 +
  161 +```json
  162 +[{
  163 + "seq": 1,
  164 + "title": "实现可在浏览器直接玩的贪吃蛇游戏",
  165 + "description": "用 HTML/CSS/JS 实现一个完整的贪吃蛇小游戏。达成判据：方向键控制移动、吃到食物加分、撞墙或撞自己游戏结束、可以重新开始。",
  166 + "depends_on": [],
  167 + "acceptance_mode": "itemized"
  168 +}]
  169 +```
  170 +
145 171 最小合法产出（goal 本身就是一件事时，**这是正确答案，不是偷懒**）：
146 172  
147 173 ```json
... ...