/** * 27-P3C 批 1 的验收清单里，能在单测里真跑的那几条（§八 验收 4 / 5 / 6 / 10 / 11 / 12b）。 * * 与 `company-goal-task-routes.test.js` 的分工：那份验的是**不起 run** 的一半（列表 / 详情 / * 改 / 归档）；这份专门走**起 run 那条路** —— 存量入口 `POST /:cid/tasks` 的兼容性、 * 起 run 之后才生效的 task 级描述冻结、以及写侧读侧是否落在同一个 run 目录上。 * * ⚠️ 先设 env 再 require（§八 验收 12b 的警示块）：`graph-engine.js` / `graph-run-sse.js` * 都在**模块加载时**快照 `GRAPH_RUNS_DIR`，先 require 再设 env 会让它们拿着 null 往仓库 * `data/companies/` 里写 —— 而且不报错。 * * 公司实体用 `CompanyService.prototype.get` 打桩：`company-service` 的 DATA_DIR 是硬编码的 * 仓库 `data/companies/`，不认任何 env，真建一家公司就等于往用户仓库里落目录。 * agent 一律不真调：org node 是 subgraph 节点，规划走 `setPlanWorkGraph` 注入的假规划。 */ const fs = require('fs'); const os = require('os'); const path = require('path'); const TEST_DB_PATH = '/tmp/test-goal-task-acceptance.sqlite'; const DB_FILES = [TEST_DB_PATH, `${TEST_DB_PATH}-shm`, `${TEST_DB_PATH}-wal`]; // 这几个模块在加载时快照 GRAPH_DB_PATH / GRAPH_RUNS_DIR，必须先设 env 再 require const MODULES = [ '../../services/graph-db', '../../services/org-graph-service', '../../services/work-graph-db', '../../services/graph-run-sse', '../../services/graph-engine', '../../services/goal-contract', '../../routes/company', ]; const ORG_NODES = ['org-planner', 'org-coder', 'org-validator']; const ORG_EDGES = [ { from: 'org-planner', to: 'org-coder', condition: 'success' }, { from: 'org-coder', to: 'org-validator', condition: 'success' }, ]; let wdb; let engine; let orgSvc; let goalContract; let runsDir; let server; let origCompanyGet; /** 一次请求 → [status, json]（没有 supertest，express 起在随机端口上用 fetch 打） */ async function call(method, url, body) { const r = await fetch(`http://127.0.0.1:${server.address().port}${url}`, { method, headers: { 'Content-Type': 'application/json' }, body: body === undefined ? undefined : JSON.stringify(body), }); return [r.status, await r.json()]; } let seq = 0; const companies = []; /** 每个用例一家独立公司：active root run 的唯一索引是按 company 约束的 */ function newCompany() { const cid = `acc-co-${++seq}`; companies.push(cid); expect(orgSvc.writeGraph(cid, { nodes: ORG_NODES, edges: ORG_EDGES }).ok).toBe(true); return cid; } /** * `OkrService` 的 DATA_DIR 是硬编码的仓库 `data/`，不认 `GRAPH_RUNS_DIR` 也不认任何 env， * 而它的构造函数就 mkdir —— 打一次 `GET /:cid/okr` 就在用户仓库里留一个 * `data/companies/{cid}/okr/`。测试自己收拾干净，别把残留留给下一个人。 * 只删本文件造出来的前缀目录，且必须确认里面没有 `company.json`（真公司一定有这个文件）。 */ function cleanupLeakedCompanyDirs() { const root = path.resolve(__dirname, '../../../data/companies'); for (const cid of companies) { const dir = path.join(root, cid); if (!fs.existsSync(dir) || fs.existsSync(path.join(dir, 'company.json'))) continue; try { fs.rmSync(dir, { recursive: true, force: true }); } catch { /* 删不掉就留着，不让清理反过来炸测试 */ } } } describe('27-P3C 批 1 验收（§八 4 / 5 / 6 / 10 / 11 / 12b）', () => { beforeAll(async () => { for (const f of DB_FILES) { try { fs.unlinkSync(f); } catch { /* 本来就没有 */ } } process.env.GRAPH_DB_PATH = TEST_DB_PATH; runsDir = fs.mkdtempSync(path.join(os.tmpdir(), 'p3c-acceptance-runs-')); process.env.GRAPH_RUNS_DIR = runsDir; for (const m of MODULES) delete require.cache[require.resolve(m)]; wdb = require('../../services/work-graph-db'); orgSvc = require('../../services/org-graph-service'); engine = require('../../services/graph-engine'); goalContract = require('../../services/goal-contract'); // 公司实体：只有 POST /:cid/tasks 的存在性检查在读它 const { CompanyService } = require('../../services/company-service'); origCompanyGet = CompanyService.prototype.get; CompanyService.prototype.get = function (companyId) { return { id: companyId, name: companyId, status: 'running' }; }; const express = require('express'); const app = express(); app.use(express.json()); app.use('/api/company', require('../../routes/company')); // 验收 11：OKR 只剩这一个挂载点，/api/goals 那条别名已退役 app.use('/api/okr', require('../../routes/okr')); await new Promise((resolve) => { server = app.listen(0, resolve); }); }); afterAll(() => { if (server) server.close(); if (origCompanyGet) require('../../services/company-service').CompanyService.prototype.get = origCompanyGet; for (const f of DB_FILES) { try { fs.unlinkSync(f); } catch { /* 已经删了 */ } } try { fs.rmSync(runsDir, { recursive: true, force: true }); } catch { /* ignore */ } cleanupLeakedCompanyDirs(); delete process.env.GRAPH_DB_PATH; delete process.env.GRAPH_RUNS_DIR; for (const m of MODULES) delete require.cache[require.resolve(m)]; }); // ────────────────────────────────────────────────────────────── // 验收 4 · 存量调用方一行不用改 // ────────────────────────────────────────────────────────────── it('POST /:cid/tasks 不带 goal_id 仍 201，且自动建出一个 goal（验收 4）', async () => { const cid = newCompany(); const [status, body] = await call('POST', `/api/company/${cid}/tasks`, { task: '做个官网' }); expect(status).toBe(201); // 存量响应字段一个都不能少 —— DispatchTaskButton 与外部 agent 的 curl 直接读它们 expect(body).toMatchObject({ success: true, companyId: cid, task: '做个官网', executionMode: 'manual' }); expect(body.runId).toMatch(/^run_/); expect(body.links.next).toBe(`/api/graph-runs/${body.runId}/next`); // 新增的那一个字段：goal 真的建出来了，描述与 task 同源（它就是验收边界） expect(body.goalId).toMatch(/^G-[0-9a-z]+-[0-9a-f]{4}$/); const goal = wdb.getGoal(body.goalId); expect(goal.description).toBe('做个官网'); expect(goal.company_id).toBe(cid); // 下达即冻结：dispatched_at 就是 goal 级描述冻结点（§四.4） expect(goal.dispatched_at).toBeTruthy(); expect(goal.status).toBe('active'); const tasks = wdb.listGoalTasks(goal.id); expect(tasks.map((t) => t.id)).toEqual([body.taskId]); expect(tasks[0].current_run_id).toBe(body.runId); // task id 带 4 位后缀，与 /task/dispatch 那套同毫秒会撞号的 `T-{base36}` 肉眼可分（§九.5） expect(body.taskId).toMatch(/^T-[0-9a-z]+-[0-9a-f]{4}$/); }); // ────────────────────────────────────────────────────────────── // T-mt5dkvjm · assignee_agent_id 不再是永远的 NULL // ────────────────────────────────────────────────────────────── it('POST /:cid/tasks 入队后 assignee_agent_id 不是 NULL —— COO 心跳巡检靠 to 字段判「有没有人接」，一直是 null 会被误报成孤儿任务（T-mt5dkvjm）', async () => { const cid = newCompany(); const [status, body] = await call('POST', `/api/company/${cid}/tasks`, { task: '起个图跑任务' }); expect(status).toBe(201); // 入队当下就该有占位 assignee —— 这正是 task-service.getAggregatedTasks 回给 COO 的 `to` 字段 expect(wdb.getTask(body.taskId).assignee_agent_id).toBe(wdb.GRAPH_TAKEOVER_ASSIGNEE); // run 收敛之后也不能被冲回 null：settleTaskFromRun 的 COALESCE 只在为空时兜底，不覆盖已有值 const sse = require('../../services/graph-run-sse'); expect(sse.transitionRun(body.runId, 'running', 'completed', {}, { summary: '用例直推终态' })).toBeTruthy(); const settled = wdb.getTask(body.taskId); expect(settled.status).toBe('completed'); expect(settled.assignee_agent_id).toBe(wdb.GRAPH_TAKEOVER_ASSIGNEE); }); // ────────────────────────────────────────────────────────────── // 验收 12b · 写侧与读侧落在同一个 run 目录（路径缺陷 A） // ────────────────────────────────────────────────────────────── it('GRAPH_RUNS_DIR 覆盖下，task-goal.json 的写侧与读侧是同一个路径（验收 12b）', async () => { const cid = newCompany(); const description = '把首页的加载时间压到 1 秒以内'; const [status, body] = await call('POST', `/api/company/${cid}/tasks`, { task: description }); expect(status).toBe(201); // 写侧：落在临时目录里，仓库 data/companies/ 一个字节都不该多 const written = path.join(runsDir, body.runId, 'artifacts', 'task-goal.json'); expect(fs.existsSync(written)).toBe(true); expect(JSON.parse(fs.readFileSync(written, 'utf-8')).task).toBe(description); expect(fs.existsSync(path.join(__dirname, '../../../data/companies', cid, 'runs', body.runId))).toBe(false); // 读侧之一：goal-contract 的 resolveRunDir（验收 12c 修的就是它这一半） expect(path.join(goalContract.resolveRunDir(cid, body.runId), 'artifacts', 'task-goal.json')).toBe(written); // 读侧之二 —— 真正会咬人的那个：引擎拼提示词时读得回真实描述。 // describeTask 没有导出，所以从 subgraph 节点的规划入口把 ctx.task 抓出来： // 读不到文件时它会**静默**退化成兜底文案「执行图节点任务」，agent 不知道要干什么却照样烧预算。 let plannedTask = null; engine.setPlanWorkGraph(async (ctx) => { plannedTask = ctx.task; const db = wdb.getDb(); const now = new Date().toISOString(); db.prepare(` INSERT OR IGNORE INTO system_agents (id, name, scope, owner_company_id, legacy_path, status, created_at, updated_at) VALUES ('acc-worker', 'acc-worker', 'public', NULL, 'system/agents/acc-worker', 'active', ?, ?) `).run(now, now); const g = wdb.createWorkGraph({ companyId: cid, nodes: ['acc-worker'], edges: [] }); expect(g.errors || []).toEqual([]); return { workGraphId: g.id }; }); try { await engine.nextStep(body.runId); } finally { engine.setPlanWorkGraph(null); } expect(plannedTask).toBeTruthy(); expect(plannedTask.startsWith(description)).toBe(true); expect(plannedTask).not.toContain('执行图节点任务'); }); // ────────────────────────────────────────────────────────────── // 缺陷 F1 / F2 · run 收敛之后到底发生了什么 // ────────────────────────────────────────────────────────────── it('root run 转终态 → task 回写 + goal 收敛 + OKR 恰好写一次（缺陷 F1 / F2）', async () => { const cid = newCompany(); // OkrService 的 DATA_DIR 是硬编码的仓库 data/，真写会往用户仓库里落 objective 文件； // 这里只需要证明「写了、且只写了一次」，打桩 updateNode 即可（构造函数那次 mkdir 由 // cleanupLeakedCompanyDirs 收拾）。 const { OkrService } = require('../../services/okr-service'); const origUpdateNode = OkrService.prototype.updateNode; const okrCalls = []; OkrService.prototype.updateNode = function (objectiveId, nodeId, updates) { okrCalls.push({ companyId: this.companyId, objectiveId, nodeId, status: updates.status }); return { id: nodeId }; }; try { const [status, body] = await call('POST', `/api/company/${cid}/tasks`, { task: '把注册转化率提到 20%', okr_node_id: 'O-001.1', }); expect(status).toBe(201); expect(wdb.getTask(body.taskId).status).toBe('running'); // §四.7 禁令一：度量目标只挂在 goal 上，run 上一律不带 —— 否则 N 个 task 反复覆写同一节点 expect(wdb.getRun(body.runId).okr_node_id).toBeFalsy(); expect(wdb.getGoal(body.goalId).okr_node_id).toBe('O-001.1'); // 直接推唯一漏斗。stopRun / 预算耗尽 → blocked 都不走 settleRun， // 钩子挂在 transitionRun 上才覆盖得全（§五.1.1）。 const sse = require('../../services/graph-run-sse'); expect(sse.transitionRun(body.runId, 'running', 'completed', {}, { summary: '用例直推终态' })).toBeTruthy(); const task = wdb.getTask(body.taskId); expect(task.status).toBe('completed'); // 修之前这里永远是 running expect(task.finished_at).toBeTruthy(); expect(wdb.getGoal(body.goalId).status).toBe('done'); expect(okrCalls).toEqual([ { companyId: cid, objectiveId: 'O-001', nodeId: 'O-001.1', status: 'done' }, ]); // 幂等：再收敛一次不产生第二次 OKR 写（并行完成的多个 task 会同时走到这里） const taskSettle = require('../../services/task-settle'); expect(taskSettle.settleRootRun(wdb.getRun(body.runId), 'completed')).toBeNull(); expect(okrCalls).toHaveLength(1); // F1 的直接后果：归档不再永久 409（修之前 task 卡在 running，而 hint 给的 stop // 对一条 completed 的 run 会抛 InvalidTransitionError —— 自救路径本身是死路） const [del, archived] = await call('DELETE', `/api/company/${cid}/goals/${body.goalId}`); expect(del).toBe(200); // 只看 200 不够：归档要真落到行上，否则下一次列表照样把它画出来（「历史任务看不见」的反面） expect(archived.goal.archivedAt).toBeTruthy(); expect(wdb.getGoal(body.goalId).archived_at).toBeTruthy(); expect(wdb.getTask(body.taskId).archived_at).toBeTruthy(); } finally { OkrService.prototype.updateNode = origUpdateNode; } }); it('人工停止 → task 记 cancelled、goal 判 failed（stopped 不是「执行失败」，但也不是达成）', async () => { const cid = newCompany(); const [status, body] = await call('POST', `/api/company/${cid}/tasks`, { task: '一个会被停掉的任务' }); expect(status).toBe(201); const sse = require('../../services/graph-run-sse'); sse.transitionRun(body.runId, 'running', 'stopped', {}, { summary: '用例模拟人工停止' }); const task = wdb.getTask(body.taskId); expect(task.status).toBe('cancelled'); // finished_at 是「这条 task 什么时候不再动了」的唯一时间戳：只改 status 不写它， // 列表上这条任务会显示成「已取消，但还没有结束时间」，耗时统计里也永远缺一条 expect(task.finished_at).toBeTruthy(); expect(wdb.getGoal(body.goalId).status).toBe('failed'); }); it('预算耗尽 → blocked → 人加预算恢复 → 跑完：task=completed / goal=done / OKR 恰好写一次（第二轮复核 缺陷 1 / 2）', async () => { // stopped 与 blocked 是 §五.1.1 点名的两条最常漏的路径（`stopRun` 的注释自己写着 // 「不经过 settleRun」，预算耗尽走的是 suspendRunTree → transitionRun(blocked)）。 // // ⚠️ 这条用例**必须走完整条恢复链**。第一轮只验到「转 blocked 的那一瞬间」，于是 // 「blocked 被当成终态」这个错误口径全绿通过，实跑出来的却是：加完预算 run 跑到 completed， // 而 `settleTaskFromRun` 的终态闸门命中 0 行、`settleGoalStatus` 因 goal 已 failed 也命中 0 行， // 两次静默 no-op → run=completed / task=blocked / goal=failed **永久不一致**。 // 断言序列就是那条链本身：挂起 → 恢复 → 收敛。 const { OkrService } = require('../../services/okr-service'); const origUpdateNode = OkrService.prototype.updateNode; const okrCalls = []; OkrService.prototype.updateNode = function (objectiveId, nodeId, updates) { okrCalls.push({ nodeId, status: updates.status }); return { id: nodeId }; }; try { const cid = newCompany(); const [status, body] = await call('POST', `/api/company/${cid}/tasks`, { task: '一个会烧完预算的任务', okr_node_id: 'O-002.1', }); expect(status).toBe(201); const sse = require('../../services/graph-run-sse'); // ① 预算耗尽：run → blocked expect(sse.transitionRun(body.runId, 'running', 'blocked', {}, { summary: '用例模拟预算耗尽' })).toBeTruthy(); // task 行要看得见「卡住了」—— 这是界面上唯一的信号 expect(wdb.getTask(body.taskId).status).toBe('blocked'); // 界面上那句「卡在哪」的小字（真实链路里由 describeRunBlock + noteTaskBlockedReason 写） expect(wdb.noteTaskBlockedReason(body.taskId, body.runId, '节点 xxx 卡住（budget_exhausted）')).toBe(1); expect(wdb.getTask(body.taskId).blocked_reason).toBeTruthy(); // 但 goal 不许收敛：挂起等人加预算 ≠ 需求失败。判 failed 会写 OKR、唤醒上级、 // 并把 goal 锁进终态，人加完预算跑完也再改不回 done（缺陷 2：误报 + 白烧一轮 LLM） expect(wdb.getGoal(body.goalId).status).toBe('active'); expect(okrCalls).toEqual([]); // ② 人加完预算恢复：blocked → running 是 RUN_TRANSITIONS 里的合法转换 // （`POST /api/graph-runs/:id/start` 与 `reviveParentFromChild` 走的都是这条） expect(sse.transitionRun(body.runId, 'blocked', 'running', {}, { summary: '用例模拟加预算恢复' })).toBeTruthy(); expect(wdb.getRun(body.runId).run_status).toBe('running'); // 恢复期间 task 行仍停在 blocked：RUN_TO_TASK_STATUS 只在收敛时回写，没有 running 这一档。 // 这半截不一致正是下面那条归档守卫要挡的东西 expect(wdb.getTask(body.taskId).status).toBe('blocked'); // ③ 真跑完 expect(sse.transitionRun(body.runId, 'running', 'completed', {}, { summary: '用例直推终态' })).toBeTruthy(); const task = wdb.getTask(body.taskId); expect(task.status).toBe('completed'); // 修之前这里永远钉死在 blocked expect(task.finished_at).toBeTruthy(); // 33 号文档同批修的另一个真实 bug：settleTaskFromRun 只写 status，不清 blocked_reason， // 于是任务列表在「已完成」绿色状态旁边，还会一直挂着上一次卡住时留下的那句红字 // ——真实回归任务 T-mt2r6fz0-125b 复现过（org-coder 恢复跑完后，界面仍显示 // 「节点 org-coder 卡住（missing_required_input）」）。 expect(task.blocked_reason).toBeNull(); expect(wdb.getGoal(body.goalId).status).toBe('done'); expect(okrCalls).toEqual([{ nodeId: 'O-002.1', status: 'done' }]); // 收敛完了才归档得掉 const [del] = await call('DELETE', `/api/company/${cid}/goals/${body.goalId}`); expect(del).toBe(200); } finally { OkrService.prototype.updateNode = origUpdateNode; } }); it('blocked 期间不许归档：run 随时会被恢复，藏起来就等于让它在界面外继续烧钱', async () => { // 守卫改宽之后（task 不再因 blocked 进终态）必须同步补上这一条： // 只看 `task.status === 'running'` 的旧判据，会把「挂起等预算」和「恢复后 run 已 running // 但 task 行还停在 blocked」这两种状态一起放行。 const cid = newCompany(); const [status, body] = await call('POST', `/api/company/${cid}/tasks`, { task: '一个卡住的任务' }); expect(status).toBe(201); const sse = require('../../services/graph-run-sse'); sse.transitionRun(body.runId, 'running', 'blocked', {}, { summary: '用例模拟预算耗尽' }); const [del, err] = await call('DELETE', `/api/company/${cid}/goals/${body.goalId}`); expect(del).toBe(409); expect(err.runningTasks).toEqual([body.taskId]); // 拒绝还不够，得给出走得通的自救路径：blocked → stopped 是合法转换 expect(err.hint).toContain(`/api/graph-runs/${body.runId}/stop`); // 单条 task 的归档口径必须与 goal 级一致，否则绕一下就穿了 const [delTask] = await call('DELETE', `/api/company/${cid}/tasks/${body.taskId}`); expect(delTask).toBe(409); // 恢复成 running 之后 task 行还停在 blocked —— 这正是复核抓到的「守卫过松」现场 sse.transitionRun(body.runId, 'blocked', 'running', {}, { summary: '用例模拟加预算恢复' }); expect(wdb.getTask(body.taskId).status).toBe('blocked'); const [stillBlocked] = await call('DELETE', `/api/company/${cid}/goals/${body.goalId}`); expect(stillBlocked).toBe(409); // 真停掉之后才放行（stopped 不在 run 的活跃取值域里） sse.transitionRun(body.runId, 'running', 'stopped', {}, { summary: '用例模拟人工停止' }); const [ok] = await call('DELETE', `/api/company/${cid}/goals/${body.goalId}`); expect(ok).toBe(200); }); it('goal 下有一条 failed 时收敛为 failed，OKR 节点在最后一条终态时才写、且只写一次（缺陷 F2）', async () => { const cid = newCompany(); const { OkrService } = require('../../services/okr-service'); const origUpdateNode = OkrService.prototype.updateNode; const okrCalls = []; OkrService.prototype.updateNode = function (objectiveId, nodeId, updates) { okrCalls.push({ nodeId, status: updates.status }); return { id: nodeId }; }; try { const [created, goal] = await call('POST', `/api/company/${cid}/goals`, { description: '把注册流程重做一遍', okr_node_id: 'O-002.1', tasks: [{ description: '改后端接口' }, { description: '改前端表单' }], }); expect(created).toBe(201); const [t1, t2] = goal.tasks; const sse = require('../../services/graph-run-sse'); // 第一条失败 const [d1, r1] = await call('POST', `/api/company/${cid}/goals/${goal.goalId}/dispatch`); expect(d1).toBe(201); expect(r1.started.taskId).toBe(t1.taskId); sse.transitionRun(r1.started.runId, 'running', 'failed', {}, { summary: '用例模拟执行失败' }); expect(wdb.getTask(t1.taskId).status).toBe('failed'); // 还有一条 draft 没跑，goal 不许提前收敛 —— 提前写 OKR 就是「一条失败的尾巴把节点翻掉」， // 而后面那条可能还会成功。§四.7 禁令一挪走 run 级 okr_node_id 要挡的就是这个 expect(wdb.getGoal(goal.goalId).status).toBe('active'); expect(okrCalls).toEqual([]); // 第二条成功；至此全部 task 到终态 → goal 收敛。 // 批 3 起**不能再调一次 dispatch**：那一次已经把 goal 下所有 draft 一起入队了（§六.2）， // 现在 t2 是 queued 而不是 draft。而它是 manual，调度器故意不自动出队（§五.2bis）， // 所以由人点「开始」把它从队里拉起来 —— 这正是那个端点存在的理由。 const [d2, r2] = await call('POST', `/api/company/${cid}/tasks/${t2.taskId}/start`); expect(d2).toBe(201); expect(r2.started.taskId).toBe(t2.taskId); sse.transitionRun(r2.started.runId, 'running', 'completed', {}, { summary: '用例直推终态' }); expect(wdb.getTask(t2.taskId).status).toBe('completed'); // 判词口径：全部 completed 才 done。「最后一条成功了就算达成」会让半截需求被判合格 expect(wdb.getGoal(goal.goalId).status).toBe('failed'); expect(okrCalls).toEqual([{ nodeId: 'O-002.1', status: 'failed' }]); } finally { OkrService.prototype.updateNode = origUpdateNode; } }); // ────────────────────────────────────────────────────────────── // §四.10 · goal 级验收（org-validator 在 goal 层再调一次） // ────────────────────────────────────────────────────────────── /** 异步验收跑在 setImmediate 里；等到条件成立再断言，别靠数固定几个 tick */ async function waitFor(pred, label) { for (let i = 0; i < 50; i += 1) { if (pred()) return; await new Promise((r) => setImmediate(r)); } throw new Error(`等不到：${label}`); } /** * 等一个**最终**判词。 * * 不能直接等 `verdict` 非空：CAS 抢到收敛权时会同步认领一个占位判词（`VERDICT_PENDING_PREFIX` 打头， * 见 task-settle 常量处 —— 没有它，验收窗口里一重启就静默丢一次验收，且在库里和 * 「1 条 task 跳过验收」完全同形）。等非空就会在占位值上立刻返回，后面对判词内容的断言 * 变成一场竞态。所以判据是「非空**且**不是占位值」。 */ async function waitVerdict(goalId, label = 'goal 级验收回写') { const { isPendingVerdict } = require('../../services/task-settle'); await waitFor(() => { const v = wdb.getGoal(goalId).verdict; return v && !isPendingVerdict(v); }, label); } /** 建一个两条 task 的 goal，逐条 dispatch → 推到指定终态。返回建出来的 goal 视图 */ async function runTwoTaskGoal(cid, [s1, s2], extra = {}) { const [created, goal] = await call('POST', `/api/company/${cid}/goals`, { description: '把注册流程重做一遍：后端发验证码，前端收验证码', tasks: [{ description: '后端加发验证码的接口' }, { description: '前端表单接上验证码' }], ...extra, }); expect(created).toBe(201); const sse = require('../../services/graph-run-sse'); // 批 3：一次 dispatch 把两条都入队，队头那条立刻起跑 const [d1, r1] = await call('POST', `/api/company/${cid}/goals/${goal.goalId}/dispatch`); expect(d1).toBe(201); sse.transitionRun(r1.started.runId, 'running', s1, {}, { summary: '用例直推终态' }); // 第二条是 manual，调度器不碰它（§五.2bis），由人点「开始」 const second = goal.tasks.find((t) => t.taskId !== r1.started.taskId); const [d2, r2] = await call('POST', `/api/company/${cid}/tasks/${second.taskId}/start`); expect(d2).toBe(201); sse.transitionRun(r2.started.runId, 'running', s2, {}, { summary: '用例直推终态' }); return goal; } it('≥2 条 task 全 completed → 调一次 org-validator；判 fail 时 goal 翻成 failed，OKR 写的是最终结论', async () => { // 这条用例守的是 §四.10 的整个理由：每条 task 都按自己的描述做完了，不等于拼起来是人要的东西。 // 也守住约束 5 —— OKR / report_to 必须拿**验收后**的状态，验收前就汇报等于对外说了个会被改的结论。 const cid = newCompany(); const validation = require('../../services/goal-validation'); const { OkrService } = require('../../services/okr-service'); const origUpdateNode = OkrService.prototype.updateNode; const okrCalls = []; OkrService.prototype.updateNode = function (objectiveId, nodeId, updates) { okrCalls.push({ nodeId, status: updates.status }); return { id: nodeId }; }; const seen = []; validation.setValidateGoal(async (ctx) => { seen.push(ctx); return { pass: false, verdict: '后端发的是 6 位码，前端只收 4 位，两条 task 各自都对，合起来跑不通', tokens: 1234 }; }); try { const goal = await runTwoTaskGoal(cid, ['completed', 'completed'], { okr_node_id: 'O-010.1' }); await waitVerdict(goal.goalId); const row = wdb.getGoal(goal.goalId); expect(seen).toHaveLength(1); // 一个 goal 只验一次：CAS 之后才调，不是每条 task 各调一次 expect(seen[0].goal.id).toBe(goal.goalId); expect(seen[0].tasks.map((t) => t.status)).toEqual(['completed', 'completed']); expect(row.status).toBe('failed'); // CAS 先占位写 done，验收判 fail 后改写 expect(row.verdict).toContain('前端只收 4 位'); expect(row.validation_tokens).toBe(1234); // 验收烧的 token 记在 goal 上（没有 run 的预算池可扣） // 汇报只有一次，且带的是最终状态；验收前抢跑就会看到一条 done expect(okrCalls).toEqual([{ nodeId: 'O-010.1', status: 'failed' }]); // 幂等：收敛权已被拿走，再推一次不会二次验收（org-validator 是真花钱的） const settle = require('../../services/task-settle'); expect(settle.settleGoalIfAllTasksDone(goal.goalId)).toBeNull(); expect(seen).toHaveLength(1); } finally { validation.setValidateGoal(null); OkrService.prototype.updateNode = origUpdateNode; } }); it('有一条 task 没 completed → 直接 failed，不调 org-validator（显然没交付，省一次调用）', async () => { const cid = newCompany(); const validation = require('../../services/goal-validation'); const seen = []; validation.setValidateGoal(async (ctx) => { seen.push(ctx); return { pass: true }; }); try { const goal = await runTwoTaskGoal(cid, ['failed', 'completed']); await new Promise((r) => setImmediate(r)); expect(wdb.getGoal(goal.goalId).status).toBe('failed'); expect(seen).toEqual([]); } finally { validation.setValidateGoal(null); } }); it('只有 1 条 task 时跳过 goal 级验收（两级验收问的是同一件事，再调一次纯浪费）', async () => { const cid = newCompany(); const validation = require('../../services/goal-validation'); const seen = []; validation.setValidateGoal(async (ctx) => { seen.push(ctx); return { pass: false, verdict: '不该被调到' }; }); try { const [status, body] = await call('POST', `/api/company/${cid}/tasks`, { task: '把周报发出去' }); expect(status).toBe(201); require('../../services/graph-run-sse') .transitionRun(body.runId, 'running', 'completed', {}, { summary: '用例直推终态' }); await new Promise((r) => setImmediate(r)); expect(seen).toEqual([]); expect(wdb.getGoal(body.goalId).status).toBe('done'); } finally { validation.setValidateGoal(null); } }); it('验收本身炸了 → 保守判 done 且在 verdict 里写明没验过，绝不把 goal 卡在半路（约束 4）', async () => { // 「读不到判词就判 fail」是最自然的错法，而 failed 是终态、会写 OKR、会唤醒上级 —— // 误杀一次真交付不可撤销。反过来 done 至少有「全部 task 都 completed」这个既成事实兜着。 const cid = newCompany(); const validation = require('../../services/goal-validation'); const { OkrService } = require('../../services/okr-service'); const origUpdateNode = OkrService.prototype.updateNode; const okrCalls = []; OkrService.prototype.updateNode = function (objectiveId, nodeId, updates) { okrCalls.push({ nodeId, status: updates.status }); return { id: nodeId }; }; validation.setValidateGoal(async () => { const e = new Error('org-validator 起不来'); e.tokens = 77; // 炸之前已经烧掉的那部分，照样要记账 throw e; }); try { const goal = await runTwoTaskGoal(cid, ['completed', 'completed'], { okr_node_id: 'O-011.1' }); await waitVerdict(goal.goalId, '兜底判词回写'); const row = wdb.getGoal(goal.goalId); expect(row.status).toBe('done'); expect(row.verdict).toContain('验收未执行'); expect(row.validation_tokens).toBe(77); expect(okrCalls).toEqual([{ nodeId: 'O-011.1', status: 'done' }]); // 卡不住：照样汇报 } finally { validation.setValidateGoal(null); OkrService.prototype.updateNode = origUpdateNode; } }); // ────────────────────────────────────────────────────────────── // 第三轮复核 缺陷 2 / 3 · 验收窗口内重启不丢、汇报炸了不杀进程 // ────────────────────────────────────────────────────────────── /** * 造一个「另一个进程留下的」占位判词。 * 占位值现在是「前缀 + 唯一 token」而不是一个常量 —— 常量形态下认领语句的 WHERE 里必然 * 含有它自己要写的值，闸门当场失效（见 task-settle 常量处那段）。这里的 token 故意与 * 本进程的 PROC_TAG 无关：模拟的就是别的实例写下的那一个。 */ let stuckSeq = 0; const foreignPending = () => `${require('../../services/task-settle').VERDICT_PENDING_PREFIX}otherproc-${++stuckSeq}`; /** 把一条 goal 摆成「CAS 已写终态、验收还没回来」的形状 —— 也就是重启前一瞬间的库 */ function stuckGoal(cid, verdict = foreignPending()) { const goal = wdb.createGoal({ companyId: cid, title: '两件事', description: '两件事合起来才算数' }); const a = wdb.createTask({ goalId: goal.id, companyId: cid, title: 'A', description: 'A' }); const b = wdb.createTask({ goalId: goal.id, companyId: cid, title: 'B', description: 'B' }); wdb.updateTask(a.id, { status: 'completed' }); wdb.updateTask(b.id, { status: 'completed' }); expect(wdb.settleGoalStatus(goal.id, 'done')).toBe(1); return wdb.updateGoal(goal.id, { verdict }); } it('CAS 同步写占位判词：验收在跑 ≠ 验收丢了 ≠ 本来就没验，三者在库里分得开（缺陷 2）', async () => { // 占位值存在的全部理由：`verdict IS NULL` 同时也是「1 条 task 跳过验收」那条合法路径的形态。 // 不写占位，窗口里一重启就没有任何查询能把「丢了」从「本来就没验」里挑出来。 const cid = newCompany(); const settle = require('../../services/task-settle'); const validation = require('../../services/goal-validation'); let release; validation.setValidateGoal(() => new Promise((r) => { release = r; })); // 卡住不回，模拟验收在跑 try { const goal = wdb.createGoal({ companyId: cid, title: '两件事', description: '两件事合起来才算数' }); const a = wdb.createTask({ goalId: goal.id, companyId: cid, title: 'A', description: 'A' }); const b = wdb.createTask({ goalId: goal.id, companyId: cid, title: 'B', description: 'B' }); wdb.updateTask(a.id, { status: 'completed' }); wdb.updateTask(b.id, { status: 'completed' }); expect(settle.settleGoalIfAllTasksDone(goal.id)).toBe('done'); // 同步可见：占位值和 CAS 在同一个 tick 里落库，不是等验收起来才写 const row = wdb.getGoal(goal.id); expect(row.status).toBe('done'); expect(settle.isPendingVerdict(row.verdict)).toBe(true); // 验收本体是在 setImmediate 里才被调到的，先让出一次，release 才拿得到 await waitFor(() => release, '验收本体被调起'); release({ pass: true, verdict: '合起来对上了', tokens: 9 }); await waitVerdict(goal.id); expect(wdb.getGoal(goal.id).verdict).toBe('合起来对上了'); // 真判词覆盖占位值 } finally { validation.setValidateGoal(null); } }); it('启动重推：窗口内重启丢掉的验收会被补跑，且补跑本身幂等（缺陷 2）', async () => { const cid = newCompany(); const settle = require('../../services/task-settle'); const validation = require('../../services/goal-validation'); const { OkrService } = require('../../services/okr-service'); const origUpdateNode = OkrService.prototype.updateNode; const okrCalls = []; OkrService.prototype.updateNode = function (objectiveId, nodeId, updates) { okrCalls.push({ nodeId, status: updates.status }); return { id: nodeId }; }; const seen = []; validation.setValidateGoal(async (ctx) => { seen.push(ctx.goal.id); return { pass: false, verdict: '补跑后判 fail：少了退款流程', tokens: 42 }; }); try { const goal = stuckGoal(cid); wdb.updateGoal(goal.id, { okrNodeId: 'O-099.1' }); expect(await settle.resumePendingGoalValidations()).toBeGreaterThanOrEqual(1); const row = wdb.getGoal(goal.id); expect(seen).toContain(goal.id); expect(row.status).toBe('failed'); // 补跑判 fail → 终态被改写成真结论 expect(row.verdict).toBe('补跑后判 fail：少了退款流程'); expect(row.validation_tokens).toBe(42); expect(okrCalls).toContainEqual({ nodeId: 'O-099.1', status: 'failed' }); // 补的不只是判词，还有那次没做的汇报 // 幂等：占位值已被真判词覆盖，再推一次连认领都拿不到，不会二次烧钱 / 二次汇报 const before = seen.length; await settle.resumePendingGoalValidations(); expect(seen.length).toBe(before); expect(okrCalls.filter((c) => c.nodeId === 'O-099.1')).toHaveLength(1); } finally { validation.setValidateGoal(null); OkrService.prototype.updateNode = origUpdateNode; } }); it('重推不覆盖别处已定案的判词（人已经在界面上看到那句话了）', async () => { const cid = newCompany(); const settle = require('../../services/task-settle'); const validation = require('../../services/goal-validation'); const { OkrService } = require('../../services/okr-service'); const origUpdateNode = OkrService.prototype.updateNode; const okrCalls = []; OkrService.prototype.updateNode = function (o, nodeId, u) { okrCalls.push(nodeId); return { id: nodeId }; }; let target; validation.setValidateGoal(async (ctx) => { // 认领之后、回写之前的那几十秒里，别人（人工 / 另一个进程）把这条定了案 if (ctx.goal.id === target) wdb.updateGoal(target, { status: 'done', verdict: '人工判 pass' }); return { pass: false, verdict: '重推的结论，不该落库', tokens: 5 }; }); try { const goal = stuckGoal(cid); wdb.updateGoal(goal.id, { okrNodeId: 'O-098.1' }); target = goal.id; await settle.resumePendingGoalValidations(); const row = wdb.getGoal(goal.id); expect(row.verdict).toBe('人工判 pass'); // ⚠️ 第四轮改动：判词输了，但**账要记** —— 这一次 org-validator 是真跑了、token 是真烧了。 // 原断言钉住的正是「输家的钱静默蒸发」那个缺陷本身（与 settleGoalPlanning 那条 // 「没命中也补记账」的分支自相矛盾）。现在改成断言它被记上。 expect(row.validation_tokens).toBe(5); expect(okrCalls).not.toContain('O-098.1'); // 也不能再汇报一次：OKR 写两次、上级叫醒两次都不可重放 } finally { validation.setValidateGoal(null); OkrService.prototype.updateNode = origUpdateNode; } }); it('汇报环节同步抛出时只丢一行日志，不变成 unhandledRejection 杀进程（缺陷 3）', async () => { // reportGoalOutcome 有两条同步抛出面（terminalAgentId 读库、OkrService.updateNode 的 fs 写）。 // 批 1 走同步路径，异常由 graph-run-sse 的 try/catch 兜住；这条路跑在 setImmediate 的 async // 函数里，同一个异常会逃成 unhandledRejection —— Node ≥15 默认直接杀掉整个服务。 const cid = newCompany(); const settle = require('../../services/task-settle'); const validation = require('../../services/goal-validation'); const { OkrService } = require('../../services/okr-service'); const origUpdateNode = OkrService.prototype.updateNode; OkrService.prototype.updateNode = function () { throw new Error('ENOENT: OKR 目录被删了'); }; validation.setValidateGoal(async () => ({ pass: true, verdict: '合起来对上了', tokens: 1 })); const rejections = []; const onRejection = (e) => rejections.push(e); process.on('unhandledRejection', onRejection); try { const goal = wdb.createGoal({ companyId: cid, title: '两件事', description: '两件事合起来才算数' }); wdb.updateGoal(goal.id, { okrNodeId: 'O-097.1' }); const a = wdb.createTask({ goalId: goal.id, companyId: cid, title: 'A', description: 'A' }); const b = wdb.createTask({ goalId: goal.id, companyId: cid, title: 'B', description: 'B' }); wdb.updateTask(a.id, { status: 'completed' }); wdb.updateTask(b.id, { status: 'completed' }); settle.settleGoalIfAllTasksDone(goal.id); await waitVerdict(goal.id); // 判词照样落了库（汇报炸在回写之后），进程也没被一个逃逸的 rejection 掀翻 expect(wdb.getGoal(goal.id).verdict).toBe('合起来对上了'); await new Promise((r) => setTimeout(r, 20)); // 给 unhandledRejection 事件一个真到达的机会 expect(rejections).toEqual([]); } finally { process.off('unhandledRejection', onRejection); validation.setValidateGoal(null); OkrService.prototype.updateNode = origUpdateNode; } }); // ────────────────────────────────────────────────────────────── // 第二轮复核（批 2）· 多实例并发下的认领与回写，以及「汇报丢了」的可查性 // ────────────────────────────────────────────────────────────── /** * 三个用例守的是同一件事：goal 收敛带着两个**不可重放**的副作用（写一次 OKR 节点、 * 唤醒一次上级 agent，后者真起一轮 LLM）。它们各盯一层闸门： * ① 认领 —— 唯一 token + WHERE 只认上一个态（上一版把自己要写的值也放进了 WHERE， * changes 恒为 1，闸门当场失效）； * ② in-flight —— 本进程还在飞的验收不是窟窿，重推不许把它当「丢了」抢走； * ③ 回写 —— `WHERE verdict = @claim` 决出唯一赢家，输的一个副作用都不做。 * 三层缺一层，实测的结果就是复核给出的那三个数字：验收调 2 次、OKR 写 2 条、token 记 100。 */ /** 装一副 OKR 打桩，返回 [收集数组, 还原函数]（真 updateNode 会往仓库 data/ 里落文件） */ function stubOkr() { const { OkrService } = require('../../services/okr-service'); const orig = OkrService.prototype.updateNode; const calls = []; OkrService.prototype.updateNode = function (objectiveId, nodeId, updates) { calls.push(`${nodeId}:${updates.status}`); return { id: nodeId }; }; return [calls, () => { OkrService.prototype.updateNode = orig; }]; } it('两个扫描者拿着同一份快照认领同一条 goal：只有一个赢，验收 / OKR / token 都只发生一次', async () => { // 复核实跑复现的就是这个形态：A、B 两个实例几乎同时 SELECT 出同一批占位值的 goal， // 然后各自 UPDATE 去认领。上一版的认领是 // `SET verdict = RESUMING WHERE verdict IN (PENDING, RESUMING)` // —— **写进去的值自己也在 WHERE 里**，已被 A 认领的行照样匹配 B 的条件，changes 恒为 1。 // 于是 org-validator 被调 2 次、同一个 OKR 节点写 2 条、validation_tokens 记成两倍。 const cid = newCompany(); const settle = require('../../services/task-settle'); const validation = require('../../services/goal-validation'); const [okrCalls, restoreOkr] = stubOkr(); const seen = []; validation.setValidateGoal(async (ctx) => { seen.push(ctx.goal.id); return { pass: true, verdict: '合起来对上了', tokens: 50 }; }); try { const goal = stuckGoal(cid); wdb.updateGoal(goal.id, { okrNodeId: 'O-096.1' }); const snapshot = wdb.getGoal(goal.id).verdict; // 两个实例手里的那份快照 // 实例 A：走完整条重推 expect(await settle.resumePendingGoalValidations()).toBeGreaterThanOrEqual(1); // 实例 B：它的 SELECT 早于 A 的认领，手里还是那份旧快照 —— 跨进程时 inFlight 帮不上忙 // （那是进程内的知识），守门的只有这一句 SQL 本身。 const bClaim = wdb.claimGoalSlot(goal.id, 'verdict', { from: snapshot, to: `${settle.VERDICT_PENDING_PREFIX}instB-1`, }); expect(bClaim).toBe(0); // 修之前这里是 1 // B 认领不到，于是它这一轮什么都不做；再扫一次也只会看到 A 写下的真判词 await settle.resumePendingGoalValidations(); const row = wdb.getGoal(goal.id); expect(seen).toEqual([goal.id]); // org-validator 只起一次 expect(okrCalls.filter((c) => c.startsWith('O-096.1'))).toEqual(['O-096.1:done']); // OKR 只写一条 expect(row.validation_tokens).toBe(50); // token 不双记（不是 100） expect(row.verdict).toBe('合起来对上了'); expect(row.reported_at).toBeTruthy(); } finally { validation.setValidateGoal(null); restoreOkr(); } }); it('主路径验收在飞时撞上启动重推：本进程认得出「这条还活着」，不当窟窿抢走', async () => { // 上一版的判据是一句只对单进程成立的断言：「没有任何 in-flight 验收能活过一次重启， // 所以此刻挂着占位值的全是丢掉的」。pm2 cluster / 滚动重启下，B 起来时 A 还活着、 // 验收还在飞 —— 那些 goal 的 verdict 正是占位值，会被整批当成「丢了」抢走。 // 同进程这一半必须彻底堵死（跨进程那一半由回写决胜兜底，见下一条）。 const cid = newCompany(); const settle = require('../../services/task-settle'); const validation = require('../../services/goal-validation'); const [okrCalls, restoreOkr] = stubOkr(); const seen = []; let release; validation.setValidateGoal(async (ctx) => { seen.push(ctx.goal.id); return new Promise((r) => { release = r; }); // 卡住，模拟分钟级的 LLM 调用 }); try { const goal = wdb.createGoal({ companyId: cid, title: '两件事', description: '两件事合起来才算数' }); wdb.updateGoal(goal.id, { okrNodeId: 'O-094.1' }); const a = wdb.createTask({ goalId: goal.id, companyId: cid, title: 'A', description: 'A' }); const b = wdb.createTask({ goalId: goal.id, companyId: cid, title: 'B', description: 'B' }); wdb.updateTask(a.id, { status: 'completed' }); wdb.updateTask(b.id, { status: 'completed' }); // 主路径：CAS → 认领占位判词 → 验收挂在 setImmediate 上 expect(settle.settleGoalIfAllTasksDone(goal.id)).toBe('done'); await waitFor(() => release, '主路径的验收本体被调起'); const claimed = wdb.getGoal(goal.id).verdict; expect(settle.isPendingVerdict(claimed)).toBe(true); // 重推撞上来：这条还在飞，不许碰 await settle.resumePendingGoalValidations(); expect(seen).toEqual([goal.id]); // 没有第二次 org-validator expect(wdb.getGoal(goal.id).verdict).toBe(claimed); // 占位 token 没被换掉 release({ pass: true, verdict: '合起来对上了', tokens: 50 }); await waitVerdict(goal.id); const row = wdb.getGoal(goal.id); expect(seen).toEqual([goal.id]); expect(row.validation_tokens).toBe(50); expect(okrCalls.filter((c) => c.startsWith('O-094.1'))).toEqual(['O-094.1:done']); // 收敛完再扫一遍：判词已定案、汇报已盖戳，连窟窿都不是了 await settle.resumePendingGoalValidations(); expect(seen).toEqual([goal.id]); expect(okrCalls.filter((c) => c.startsWith('O-094.1'))).toEqual(['O-094.1:done']); } finally { validation.setValidateGoal(null); restoreOkr(); } }); it('跨进程被抢走时靠回写决胜：输的那一方判词写不进去，也绝不汇报', async () => { // 跨进程判活要租约 + 心跳（另排），所以真有别的实例把在飞的这条抢走时，多烧的那一次 // org-validator 是拦不住的。拦得住的是**副作用**：回写是 `WHERE verdict = @claim` 的 // 条件更新，抢跑者换掉了 token，主路径的 changes = 0 —— 判词不覆盖、token 不记、不汇报。 // 上一版这里是「getGoal 读一下 + updateGoal 写回去」的 check-then-act，读写之间隔着 // 一整轮事件循环，跨进程根本不是原子的。 const cid = newCompany(); const settle = require('../../services/task-settle'); const validation = require('../../services/goal-validation'); const [okrCalls, restoreOkr] = stubOkr(); const seen = []; let release; validation.setValidateGoal(async (ctx) => { seen.push(ctx.goal.id); if (seen.length === 1) return new Promise((r) => { release = r; }); return { pass: false, verdict: '抢跑者的结论：少了退款流程', tokens: 30 }; }); try { const goal = wdb.createGoal({ companyId: cid, title: '两件事', description: '两件事合起来才算数' }); wdb.updateGoal(goal.id, { okrNodeId: 'O-093.1' }); const a = wdb.createTask({ goalId: goal.id, companyId: cid, title: 'A', description: 'A' }); const b = wdb.createTask({ goalId: goal.id, companyId: cid, title: 'B', description: 'B' }); wdb.updateTask(a.id, { status: 'completed' }); wdb.updateTask(b.id, { status: 'completed' }); expect(settle.settleGoalIfAllTasksDone(goal.id)).toBe('done'); await waitFor(() => release, '主路径的验收本体被调起'); const claimed = wdb.getGoal(goal.id).verdict; // 另一个实例把它抢走（它没有本进程的 inFlight 这份知识） const stolen = `${settle.VERDICT_PENDING_PREFIX}instB-2`; expect(wdb.claimGoalSlot(goal.id, 'verdict', { from: claimed, to: stolen })).toBe(1); // 主路径这才拿到结论 —— 回写必须整段落空 release({ pass: true, verdict: '主路径的结论，不该落库', tokens: 50 }); await new Promise((r) => setTimeout(r, 20)); const mid = wdb.getGoal(goal.id); expect(mid.verdict).toBe(stolen); // 没被覆盖 // ⚠️ 第四轮改动：判词输了，但**账要记** —— 这一次 org-validator 是真跑了、token 是真烧了。 // 原断言钉住的正是「输家的钱静默蒸发」那个缺陷本身（与 settleGoalPlanning 那条 // 「没命中也补记账」的分支自相矛盾）。现在改成断言它被记上。 expect(mid.validation_tokens).toBe(50); // 输家的 token 现在记账（原为 0 = 静默蒸发） expect(mid.reported_at).toBeFalsy(); // **一次都没汇报**：汇报不可重放，宁可等抢跑者报 expect(okrCalls.filter((c) => c.startsWith('O-093.1'))).toEqual([]); // 抢跑者跑完自己那一轮：这时候才轮到唯一的一次汇报 await settle.resumePendingGoalValidations(); const row = wdb.getGoal(goal.id); expect(row.verdict).toBe('抢跑者的结论：少了退款流程'); // 总账 = 输家 50 + 赢家 30。两次 org-validator 是真跑了两次（跨进程抢跑拦不住多烧一次， // 设计已明写认账），拦住的是**不可重放的副作用**：判词只写一次、汇报只发一次。 expect(row.validation_tokens).toBe(80); expect(row.status).toBe('failed'); expect(okrCalls.filter((c) => c.startsWith('O-093.1'))).toEqual(['O-093.1:failed']); } finally { validation.setValidateGoal(null); restoreOkr(); } }); it('汇报丢了在库里查得出来，启动重推只补汇报、不重跑验收（半修残留）', async () => { // 判词一落库，这条 goal 就永远退出了**验收**重推的扫描面（那边只认占位判词）， // 而紧接着的汇报原来是发射后不管的 fetch。进程在这几十毫秒到几秒里被杀、或端点回 5xx， // OKR 永不写、上级永不醒，**而库里这条 goal 长得和一次完美收敛一模一样**。 // reported_at 就是把这两者分开的那一格。 const cid = newCompany(); const settle = require('../../services/task-settle'); const validation = require('../../services/goal-validation'); const seen = []; validation.setValidateGoal(async (ctx) => { seen.push(ctx.goal.id); return { pass: true, verdict: '不该被调到' }; }); const [status, body] = await call('POST', `/api/company/${cid}/tasks`, { task: '给上级交一份周报', report_to: 'ceo', okr_node_id: 'O-092.1', }); expect(status).toBe(201); const origFetch = globalThis.fetch; const posted = []; let httpOk = false; globalThis.fetch = (url, init) => { posted.push(JSON.parse(init.body)); return Promise.resolve({ ok: httpOk, status: httpOk ? 200 : 500 }); }; try { require('../../services/graph-run-sse') .transitionRun(body.runId, 'running', 'completed', {}, { summary: '用例直推终态' }); await waitFor(() => posted.length >= 1, '第一次汇报打出去'); // 等这次汇报**真的结束**（拿到 500 才算完）。还没拿到响应之前它是「在飞」而不是「窟窿」， // 重推会正确地跳过它 —— 这里模拟的是进程死后重启，那时候没有任何东西还在飞。 await new Promise((r) => setTimeout(r, 10)); // 可查性：这条 goal 只有 1 条 task（跳过验收 → verdict 恒为 NULL，那是合法形态）， // 唯一能把「汇报丢了」认出来的就是 reported_at 上停着的占位值 const row = wdb.getGoal(body.goalId); expect(row.status).toBe('done'); expect(row.verdict).toBeFalsy(); expect(String(row.reported_at).startsWith(settle.REPORT_PENDING_PREFIX)).toBe(true); // 把占位值**做旧**再重推 —— 上面那句注释说的就是这件事：「模拟的是进程死后重启」。 // 认领带租约（CLAIM_LEASE_MS）之后，活着的认领不许抢、过期的才准抢；死掉的那个进程 // 留下的占位值在重启时必然已经过期。不做旧就等于在模拟「另一个实例正在汇报」， // 那时候正确行为恰恰是**跳过**（第三轮复核实跑复现的跨进程重复汇报就是这么来的）。 const stale = String(wdb.getGoal(body.goalId).reported_at).replace(/@\d+$/, `@${Date.now() - 3600_000}`); wdb.getDb().prepare('UPDATE goals SET reported_at = ? WHERE id = ?').run(stale, body.goalId); // 重推：补的是**汇报**那一步，一次 org-validator 都不该起（重跑验收 = 白烧一轮 LLM， // 还可能给出和库里那句不一样的判词） httpOk = true; await settle.resumePendingGoalValidations(); expect(seen).toEqual([]); expect(posted).toHaveLength(2); expect(posted[1].taskId).toBe(body.goalId); expect(posted[1].status).toBe('done'); // 报成了才盖真时间戳；从此这条不再是窟窿 expect(wdb.getGoal(body.goalId).reported_at).toMatch(/^\d{4}-\d{2}-\d{2}T/); await settle.resumePendingGoalValidations(); expect(posted).toHaveLength(2); // 绝不重复汇报 } finally { globalThis.fetch = origFetch; validation.setValidateGoal(null); } }); it('判词解析：取最后一个 JSON 块、认得 audit_verdict、读不出结论时返回 null', () => { const { extractAuditVerdict } = require('../../services/goal-validation'); // 本体正文和分析过程里常常引用判决样例，从前往后取会认错那一份 const twoBlocks = '前面举个例子：\n```json\n{"audit_verdict":"pass"}\n```\n结论：\n' + '```json\n{"audit_verdict":"fail","verdict":"少了退款流程"}\n```'; expect(extractAuditVerdict(twoBlocks)).toEqual({ pass: false, verdict: '少了退款流程' }); // JSON 写坏了（尾逗号）但结论还在原文里：捞结论、判词退回摘要，好过整次验收作废 const broken = '```json\n{"audit_verdict": "pass", "verdict": "都对上了",}\n```'; expect(extractAuditVerdict(broken).pass).toBe(true); // 连结论都没有 → null，调用方走保守收敛。绝不能默认判 fail expect(extractAuditVerdict('我觉得还行吧')).toBeNull(); expect(extractAuditVerdict('')).toBeNull(); }); it('goal 级验收的提示词必须自带「不在任何 run 里」的覆盖声明，否则本体会照 run 级流程误杀（§四.10）', () => { // org-validator/agent.md 的六步工作流整个建立在 run 级寻址上（runs//、 // acceptance.json、goal-contract.js run --run-id）。goal 级调用里那些路径一个都不存在， // 不明说它会按「契约不全 → input_underspecified」立刻判 fail —— 一次正常交付被误杀， // 而且理由看上去很有道理。这段声明是整条链路上最容易被人当客套话删掉的东西。 const { buildGoalValidationPrompt } = require('../../services/goal-validation'); const cid = newCompany(); const goal = wdb.createGoal({ companyId: cid, title: '注册流程', description: '注册要能发验证码并校验' }); const t1 = wdb.createTask({ goalId: goal.id, companyId: cid, title: '后端', description: '发验证码接口' }); const t2 = wdb.createTask({ goalId: goal.id, companyId: cid, title: '前端', description: '表单校验验证码' }); const empty = buildGoalValidationPrompt({ companyId: cid, goal, tasks: [t1, t2] }); expect(empty).toContain('本次调用不在任何 graph run 里'); expect(empty).toContain('input_underspecified'); // 点名那条误判路径，不是泛泛说「注意」 expect(empty).toContain('注册要能发验证码并校验'); // ① 验收边界 = 需求原文 expect(empty).toContain('发验证码接口'); // ② 每条 task 的描述 // 写入边界段头出现在这里会翻转 PromptBuilder 的分叉（同 task-planning 那条） expect(empty).not.toContain('[写入边界'); // 空索引是一条真信号而不是「这段就别写了」：不写出来，agent 会拿 task 描述当产出想象 expect(empty).toContain('产物索引为空'); // 有产物时给的必须是绝对路径：agent 的 cwd 在 system/agents/org-validator/{cid}/{goalId}/， // 裸相对路径它一个都打不开，而且不报错 wdb.recordFile({ companyId: cid, taskId: t1.id, relPath: 'tasks/x/code/sms.js', kind: 'code' }); const withFiles = buildGoalValidationPrompt({ companyId: cid, goal, tasks: [t1, t2] }); expect(withFiles).not.toContain('产物索引为空'); expect(withFiles).toMatch(/- \[task \d+\] code：\//); }); it('并行收敛只有一个赢家：CAS 在验收之前，org-validator 恰好被调一次（§四.10）', async () => { // 上面那条验的是「验收跑完之后再推一次不会二次验收」，挡不住真正要防的那个形态： // N 条 task 在**同一个 tick 里**各自收敛，各自都算出「全都到终态了」。闸门放在验收之后的话 // 这里会烧 N 份 org-validator 的钱，而其中 N-1 份的结论最后连库都写不进去。 const cid = newCompany(); const validation = require('../../services/goal-validation'); const settle = require('../../services/task-settle'); const seen = []; validation.setValidateGoal(async (ctx) => { seen.push(ctx.goal.id); return { pass: true, verdict: '两条合起来对上了', tokens: 5 }; }); try { const goal = wdb.createGoal({ companyId: cid, title: '两件事', description: '两件事合起来才算数' }); const a = wdb.createTask({ goalId: goal.id, companyId: cid, title: 'A', description: 'A' }); const b = wdb.createTask({ goalId: goal.id, companyId: cid, title: 'B', description: 'B' }); wdb.updateTask(a.id, { status: 'completed' }); wdb.updateTask(b.id, { status: 'completed' }); // 同步连调两次 = 两条 task 的收敛钩子挤在同一个 tick 上（真实形态就是这样： // 钩子是 transitionRun 尾巴上的同步调用，异步的只有验收本身） const r1 = settle.settleGoalIfAllTasksDone(goal.id); const r2 = settle.settleGoalIfAllTasksDone(goal.id); expect([r1, r2]).toEqual(['done', null]); // 'done' 是 CAS 占位值，验收判 fail 时会被改写 await waitVerdict(goal.id); expect(seen).toEqual([goal.id]); expect(wdb.getGoal(goal.id).validation_tokens).toBe(5); } finally { validation.setValidateGoal(null); } }); // ────────────────────────────────────────────────────────────── // 验收 19 / 22 · 拆分产出是草稿清单，人确认后才按依赖顺序跑 // ────────────────────────────────────────────────────────────── /** 轮询到 goal 离开 planning（拆分是后台 setImmediate，202 先回） */ async function waitSplitDone(goalId, tries = 200) { for (let i = 0; i < tries; i += 1) { const g = wdb.getGoal(goalId); if (g && g.status !== 'planning') return g; await new Promise((r) => setTimeout(r, 10)); } throw new Error(`goal ${goalId} 一直停在 planning —— 正是 §四.9 约束 2 要消灭的那个卡死态`); } it('拆分产出全是 draft、可改可删，「全部下达」按依赖顺序一条条起（验收 19）', async () => { // 拆分不自动下达是这条的全部重点：产出是**草稿清单**，人看过改过才开跑。 // 直接入队的话，一次拆错就是 N 条真跑起来的 run，每条都在烧钱。 const cid = newCompany(); const tp = require('../../services/task-planning'); const validation = require('../../services/goal-validation'); const sse = require('../../services/graph-run-sse'); validation.setValidateGoal(async () => ({ pass: true, verdict: '合起来对上了', tokens: 3 })); tp.setPlanTasks(async () => ({ specs: [ { seq: 1, title: '后端', description: '实现发验证码的接口', depends_on: [] }, { seq: 2, title: '前端', description: '注册表单接上验证码', depends_on: [1] }, { seq: 3, title: '文档', description: '写接口文档', depends_on: [1] }, ], tokens: 321, })); try { const [status, body] = await call('POST', `/api/company/${cid}/goals`, { description: '把注册流程重做一遍' }); expect(status).toBe(202); const goalId = body.goalId; const g = await waitSplitDone(goalId); expect(g.planning_tokens).toBe(321); // 验收 21：goal 层的花费不再隐形 let tasks = wdb.listGoalTasks(goalId); expect(tasks.map((t) => t.status)).toEqual(['draft', 'draft', 'draft']); expect(tasks.map((t) => t.current_run_id)).toEqual([null, null, null]); // 一条 run 都没起 const [t1, t2, t3] = tasks; expect(JSON.parse(t2.depends_on)).toEqual([t1.id]); // 可改：draft 上 queued_at 还是空的，描述这类冻结字段随便改 const [patched, view] = await call('PATCH', `/api/company/${cid}/tasks/${t2.id}`, { description: '注册表单接上验证码，并加倒计时', }); expect(patched).toBe(200); expect(view.description).toContain('倒计时'); // 可删：归档只是隐藏，行还在 const [deleted] = await call('DELETE', `/api/company/${cid}/tasks/${t3.id}`); expect(deleted).toBe(200); expect(wdb.listGoalTasks(goalId).map((t) => t.id)).toEqual([t1.id, t2.id]); // 「全部下达」：批 3 起它把 goal 下**所有** draft 一起推进队列（§六.2）， // 起跑的仍然是跑得动的那条 —— 依赖没就绪不再是拒绝的理由，是「先排着」 const [d1, r1] = await call('POST', `/api/company/${cid}/goals/${goalId}/dispatch`); expect(d1).toBe(201); expect(r1.started.taskId).toBe(t1.id); // 两条都入了队；t2 没起跑，如实带着它的队列位次回来 expect(r1.queued.map((q) => q.taskId).sort()).toEqual([t1.id, t2.id].sort()); expect(r1.queued.find((q) => q.taskId === t2.id).queuePosition).toBe(1); expect(wdb.getTask(t2.id).status).toBe('queued'); expect(wdb.getGoal(goalId).status).toBe('active'); // 首条下达 = goal 的描述冻结点 // t1 没跑完之前 t2 起不来：现在挡它的是**依赖**（上游没 completed）， // 而不是「公司已有任务在跑」那条已经被批 3 删掉的 409。报的是谁挡的它 const [d2, e2] = await call('POST', `/api/company/${cid}/tasks/${t2.id}/start`); expect(d2).toBe(409); expect(e2.blockedBy).toEqual([t1.id]); sse.transitionRun(r1.started.runId, 'running', 'completed', {}, { summary: '用例直推终态' }); expect(wdb.getTask(t1.id).status).toBe('completed'); // 上游 completed 了，下游才轮到。manual 不参与自动出队，所以由人点「开始」 const [d3, r3] = await call('POST', `/api/company/${cid}/tasks/${t2.id}/start`); expect(d3).toBe(201); expect(r3.started.taskId).toBe(t2.id); sse.transitionRun(r3.started.runId, 'running', 'completed', {}, { summary: '用例直推终态' }); // 两条都完了 → goal 收敛，归档掉的那条不参与判定（它已经不在需求里了） await waitVerdict(goalId); expect(wdb.getGoal(goalId).status).toBe('done'); } finally { tp.setPlanTasks(null); validation.setValidateGoal(null); } }); it('存量 POST /:cid/tasks 与 split:false 一次 LLM 都不调（验收 22）', async () => { // 计数不能只数注入桩：链路绕过 planTasks 直接 new AgentManager 也一样是花钱， // 所以把最底下那层 callAgent 一并挡住 —— 它被调到就说明有人偷偷起了 CLI。 const cid = newCompany(); const AgentManager = require('../../src/core/agent-manager'); const tp = require('../../services/task-planning'); const origCall = AgentManager.prototype.callAgent; let llm = 0; let planned = 0; AgentManager.prototype.callAgent = async function stubCallAgent() { llm += 1; throw new Error('这条路径不该起 agent'); }; tp.setPlanTasks(async () => { planned += 1; throw new Error('不该被调到'); }); try { const [a, ta] = await call('POST', `/api/company/${cid}/tasks`, { task: '把周报发出去' }); expect(a).toBe(201); // 起完 run 再收掉，免得占着唯一索引让下一条 409（这里验的是花不花钱，不是并发约束） require('../../services/graph-run-sse') .transitionRun(ta.runId, 'running', 'completed', {}, { summary: '用例直推终态' }); const [b] = await call('POST', `/api/company/${cid}/goals`, { description: '同步建的 goal', split: false }); expect(b).toBe(201); await new Promise((r) => setImmediate(r)); // 给后台路径一个开口，真调了就会被数到 expect({ llm, planned }).toEqual({ llm: 0, planned: 0 }); } finally { AgentManager.prototype.callAgent = origCall; tp.setPlanTasks(null); } }); it('goal 带 report_to 时只汇报、不再自己写 OKR（同一个节点不许写两次，缺陷 F2）', async () => { // reportGoalOutcome 是 either/or：`/api/agent/task/report` 那条链路自己会更新 OKR 节点， // 这边再写一次就是同一个节点被写两遍（两次的 summary 还不一样，后写的赢）。 // 「先写 OKR 再汇报」是最自然的错法，所以两条分支都得有人盯着。 const cid = newCompany(); const { OkrService } = require('../../services/okr-service'); const origUpdateNode = OkrService.prototype.updateNode; let okrWrites = 0; OkrService.prototype.updateNode = function (objectiveId, nodeId) { okrWrites += 1; return { id: nodeId }; }; const [status, body] = await call('POST', `/api/company/${cid}/tasks`, { task: '给上级交一份周报', okr_node_id: 'O-003.2', report_to: 'ceo', }); expect(status).toBe(201); expect(wdb.getGoal(body.goalId).report_to).toBe('ceo'); // fetch 只在这一小段里换掉：call() 自己也用它，换久了整个用例都没法发请求 const origFetch = globalThis.fetch; const posted = []; globalThis.fetch = (url, init) => { posted.push({ url: String(url), body: JSON.parse(init.body) }); return Promise.resolve({ ok: true, status: 200 }); }; try { const sse = require('../../services/graph-run-sse'); sse.transitionRun(body.runId, 'running', 'completed', {}, { summary: '用例直推终态' }); } finally { globalThis.fetch = origFetch; OkrService.prototype.updateNode = origUpdateNode; } expect(posted).toHaveLength(1); expect(posted[0].url).toContain('/api/agent/task/report'); // 汇报的是 **goal id**：上级 agent 靠它把 goal 级验收和 run 级「这次跑成什么样」分开 expect(posted[0].body).toMatchObject({ taskId: body.goalId, to: 'ceo', status: 'done', nodeId: 'O-003.2' }); expect(okrWrites).toBe(0); }); // ────────────────────────────────────────────────────────────── // 缺陷 F3 / F6 · dispatch 那条路上被丢掉和被违反的两个约定 // ────────────────────────────────────────────────────────────── /** * 只比「申报的额度」，剥掉 spent。 * * spent 是**运行期账本**：run 一进 running，墙钟就往里写 active_ms / started_at * （见 budget-wallclock-active.test.js）。整个对象 deepEqual 会让这条用例在账本 * 新增字段时红，而它守的是「用户填的额度没被静默换成默认值」—— 跟账本长什么样无关。 * 账本本身另有断言：起跑那一刻还没花钱，agent_calls / tokens 必须仍是 0。 */ const limitsOf = (o) => { const { spent, ...limits } = typeof o === 'string' ? JSON.parse(o) : o; return limits; }; const spentOf = (o) => (typeof o === 'string' ? JSON.parse(o) : o).spent || {}; it('草稿上申报的 budget 能活到 dispatch，run 拿到的不是默认额度（缺陷 F3）', async () => { const cid = newCompany(); const budget = { total_agent_calls: 3, total_tokens: 5000000, wallclock_ms: 60000, spent: { agent_calls: 0, tokens: 0 } }; // 建 goal（草稿）→ 之后 dispatch，中间隔着一整个请求：请求体活不到那时候， // 所以 budget 必须落在 tasks.budget_json 上，dispatch 再读回来 const [s1, goal] = await call('POST', `/api/company/${cid}/goals`, { description: '一件预算很紧的活', budget, split: false }); expect(s1).toBe(201); expect(JSON.parse(wdb.getTask(goal.tasks[0].taskId).budget_json)).toEqual(budget); const [s2, dispatched] = await call('POST', `/api/company/${cid}/goals/${goal.goalId}/dispatch`); expect(s2).toBe(201); // 修之前这里是 DEFAULT_TASK_BUDGET（100 次调用）：用户填的 3 次被静默丢弃， // 他只会看到任务跑到一半 blocked，而没有任何地方说过预算被换掉了 const dispatchedBudget = wdb.getRun(dispatched.started.runId).budget_json; expect(limitsOf(dispatchedBudget)).toEqual(limitsOf(budget)); expect(spentOf(dispatchedBudget)).toMatchObject({ agent_calls: 0, tokens: 0 }); // 起跑那一刻还没花钱 // 本次 dispatch 的 body 仍然覆盖草稿上的申报值（优先级：body > 草稿 > 默认） const cid2 = newCompany(); const [, goal2] = await call('POST', `/api/company/${cid2}/goals`, { description: '同样带预算', budget, split: false }); const override = { total_agent_calls: 9, spent: { agent_calls: 0, tokens: 0 } }; const [s3, d2] = await call('POST', `/api/company/${cid2}/goals/${goal2.goalId}/dispatch`, { budget: override }); expect(s3).toBe(201); expect(limitsOf(wdb.getRun(d2.started.runId).budget_json)).toEqual(limitsOf(override)); }); it('坑被占着时 POST /tasks 不再 409 而是入队，申报的 budget 一路带到出队（批 3 · 缺陷 F3 的现场）', async () => { // **这条用例本身就是批 3 的分界线。** 批 1/2 时它验的是「撞唯一索引 → 409 + 存成草稿 + // hint 让你稍后 dispatch」。批 3 把那条 409 删了：坑被占着不再是错误，是排队。 // 保住的不变式没变 —— 用户填的 budget 必须一路带到真正起跑那一刻， // 不落库的话他只会看到任务跑到一半 blocked，而没有任何地方说过预算被换掉了。 const cid = newCompany(); const budget = { total_agent_calls: 2, total_tokens: 1000, wallclock_ms: 30000, spent: { agent_calls: 0, tokens: 0 } }; const db = wdb.getDb(); const intruderId = `run_intruder_${cid}`; const now = new Date().toISOString(); // 先把这家公司唯一的执行坑占掉（一条 running 的 root run） db.prepare(`INSERT INTO graph_runs (id, graph_kind, graph_id, company_id, root_run_id, run_status, created_at, updated_at) VALUES (?, 'org', ?, ?, ?, 'running', ?, ?)`).run(intruderId, cid, cid, intruderId, now, now); const [status, body] = await call('POST', `/api/company/${cid}/tasks`, { task: '一件排在后面的活', budget }); // 201，不是 409 —— 这就是「409 消失」的地方 expect(status).toBe(201); expect(body.status).toBe('queued'); expect(body.queuePosition).toBe(1); // 排第一位：告诉用户他在等什么，而不是让他猜 const queuedTask = wdb.getTask(body.taskId); expect(queuedTask.status).toBe('queued'); // 入队即建 run（queued 的 run 不占唯一索引的坑），budget 当场就挂在它身上 const queuedRun = wdb.getRun(body.runId); expect(queuedRun.run_status).toBe('queued'); expect(JSON.parse(queuedRun.budget_json)).toEqual(budget); // 申报值同样落在 task 行上：/enqueue 与 /rerun 读的是它 expect(JSON.parse(queuedTask.budget_json)).toEqual(budget); // 前一条任务收敛，坑空出来 → 人点「开始」，起的还是同一条 run、同一份预算 db.prepare(`UPDATE graph_runs SET run_status = 'completed' WHERE id = ?`).run(intruderId); const [ok, started] = await call('POST', `/api/company/${cid}/tasks/${body.taskId}/start`); expect(ok).toBe(201); expect(started.started.runId).toBe(body.runId); // 不是新起一条，是把排着的那条拉起来 const runBudget = JSON.parse(wdb.getRun(body.runId).budget_json); expect(limitsOf(runBudget)).toEqual(limitsOf(budget)); expect(spentOf(runBudget)).toMatchObject({ agent_calls: 0, tokens: 0 }); expect(runBudget.total_agent_calls).not.toBe(100); // DEFAULT_TASK_BUDGET 的值，钉住「不是默认额度」 }); it('正向依赖（第 1 条依赖第 2 条）不再把 goal 卡死：dispatch 起的是跑得动的那条（第二轮复核 缺陷 4）', async () => { const cid = newCompany(); const [status, goal] = await call('POST', `/api/company/${cid}/goals`, { description: '上线一个服务', tasks: [ { description: '部署到测试环境', depends_on: [2] }, // seq 最小的这条反而依赖后一条 { description: '构建镜像' }, ], }); expect(status).toBe(201); const [deploy, build] = goal.tasks; expect(deploy.dependsOn).toEqual([build.taskId]); // 修之前两版都不对： // v0 恒取 drafts[0] = 部署，直接起 run —— 收下了依赖又无声违反它； // v1 恒取 drafts[0] 且有阻塞就 409 —— 这个 goal 通过 API 就**永远下达不了** // （validateDependsOn 只拒环、不拒正向引用，而 dispatch 从不换人挑）。 const [ok, res1] = await call('POST', `/api/company/${cid}/goals/${goal.goalId}/dispatch`); expect(ok).toBe(201); expect(res1.started.taskId).toBe(build.taskId); // 跳过被挡住的部署，起构建 // 批 3：被挡住的那条不再留在 draft 干等下一次 dispatch，而是**进队排着** expect(res1.queued.map((q) => q.taskId).sort()).toEqual([build.taskId, deploy.taskId].sort()); expect(wdb.getTask(deploy.taskId).status).toBe('queued'); // 依赖仍是硬约束，一条都没抢跑 // 构建跑完 → 部署的上游就绪，人点「开始」就轮到它（manual 不参与自动出队） const sse = require('../../services/graph-run-sse'); sse.transitionRun(res1.started.runId, 'running', 'completed', {}, { summary: '用例直推终态' }); expect(wdb.getTask(build.taskId).status).toBe('completed'); const [ok2, res2] = await call('POST', `/api/company/${cid}/tasks/${deploy.taskId}/start`); expect(ok2).toBe(201); expect(res2.started.taskId).toBe(deploy.taskId); }); it('一条都跑不动时不再 409，而是全部入队并就地推导成 blocked，级联一次算到底（批 3 · §五.1.2）', async () => { // 批 1/2 这里是 409「一条都跑不动」。批 3 把它换成了排队 + 依赖推导，理由是 409 之后 // 那两条 task 仍是 draft，界面上和「还没下达」一模一样；而 blocked + blocked_reason // 说得出**是谁挡着它**，`⋯` 菜单据此给出「重跑上游 / 强制放行」两条出路。 const cid = newCompany(); const [status, goal] = await call('POST', `/api/company/${cid}/goals`, { description: '发一个版本', tasks: [ { description: '构建镜像' }, { description: '部署到测试环境', depends_on: [1] }, { description: '跑冒烟用例', depends_on: [2] }, ], }); expect(status).toBe(201); const [build, deploy, smoke] = goal.tasks; // 构建失败了 → 部署等着一个永远不会 completed 的上游，冒烟又等着部署 wdb.updateTask(build.taskId, { status: 'failed' }); const [ok, res] = await call('POST', `/api/company/${cid}/goals/${goal.goalId}/dispatch`); expect(ok).toBe(201); expect(res.started).toBeUndefined(); // 谁都跑不动，一条 run 都没起 const { UPSTREAM_BLOCK_PREFIX } = wdb; // 部署：直接被 failed 的上游挡住 const d = wdb.getTask(deploy.taskId); expect(d.status).toBe('blocked'); expect(d.blocked_reason).toBe(`${UPSTREAM_BLOCK_PREFIX}${build.taskId}`); // 冒烟：级联一次算到底 —— blocked 同样不是 completed，所以它也永远等不到 const sm = wdb.getTask(smoke.taskId); expect(sm.status).toBe('blocked'); expect(sm.blocked_reason).toBe(`${UPSTREAM_BLOCK_PREFIX}${deploy.taskId}`); // **级联要解得开**：blocked 只是每轮 tick 推导出来的，不落成不可逆状态。 // 上游恢复 → 下一次 tick 把两条依次放回队列（这是「注释承诺的防线真的存在」那条） wdb.updateTask(build.taskId, { status: 'completed' }); require('../../services/task-scheduler').tick(cid); expect(wdb.getTask(deploy.taskId).status).toBe('queued'); expect(wdb.getTask(deploy.taskId).blocked_reason).toBeNull(); require('../../services/task-scheduler').tick(cid); expect(wdb.getTask(smoke.taskId).status).toBe('queued'); }); it('409 hint 里的 seq 自救路径真的通：PATCH seq 能换下达顺序，非整数 400（缺陷 4）', async () => { // 修之前 hint 写着「顺序不对就改依赖或 seq：PATCH …/tasks/{id}」，而那个 PATCH 从不读 // body.seq —— 用户照着做完拿到 200（假确认），再 dispatch 还是原来那条。 const cid = newCompany(); const [status, goal] = await call('POST', `/api/company/${cid}/goals`, { description: '写两篇稿子', tasks: [{ description: '写初稿' }, { description: '写终稿' }], }); expect(status).toBe(201); const [first, second] = goal.tasks; const [bad] = await call('PATCH', `/api/company/${cid}/tasks/${second.taskId}`, { seq: 'abc' }); expect(bad).toBe(400); // seq 直接进 ORDER BY，非整数必须挡在信任边界上 const [okPatch, patched] = await call('PATCH', `/api/company/${cid}/tasks/${second.taskId}`, { seq: 0 }); expect(okPatch).toBe(200); expect(patched.seq).toBe(0); const [okDispatch, res] = await call('POST', `/api/company/${cid}/goals/${goal.goalId}/dispatch`); expect(okDispatch).toBe(201); expect(res.started.taskId).toBe(second.taskId); // 顺序真的换了，不是回个 200 就完事 // 另一条也入了队（批 3：dispatch 把 goal 下所有 draft 一起推进队列），排在第 1 位 expect(res.queued.map((q) => q.taskId).sort()).toEqual([first.taskId, second.taskId].sort()); expect(res.queued.find((q) => q.taskId === first.taskId).queuePosition).toBe(1); }); it('auto 模式收敛只唤醒上级一次，且 from 是交付者不是 human（第二轮复核 缺陷 3）', async () => { // 修之前有两条汇报打同一个 POST /api/agent/task/report：goal 级（task-settle）+ run 级 // （company.js 挂在 auto driver 上的 reportRunOutcome）。批 1 是 1 goal : 1 task， // 于是同一件事把上级叫醒两次（那个端点第 5 步会 setImmediate 自调 /api/agent/{to}/chat）。 const cid = newCompany(); const engineMod = require('../../services/graph-engine'); const origStartRun = engineMod.startRun; // auto 的 driver 会真跑整张图（分钟级、要调 agent），这里换成一个手动兑现的 promise： // 关键是它必须在 run 已经收敛**之后**才 resolve —— 那正是真实时序，也正是双唤醒的现场。 let resolveDriver; const driver = new Promise((r) => { resolveDriver = r; }); engineMod.startRun = (runId, opts) => { origStartRun(runId, { ...opts, mode: 'manual' }); // 只标 running + 点亮入口节点 return { driver }; }; let created; try { const [status, body] = await call('POST', `/api/company/${cid}/tasks`, { task: '把周报发出去', mode: 'auto', report_to: 'ceo', okr_node_id: 'O-004.1', }); expect(status).toBe(201); created = body; } finally { engineMod.startRun = origStartRun; } const origFetch = globalThis.fetch; const posted = []; globalThis.fetch = (url, init) => { posted.push({ url: String(url), body: JSON.parse(init.body) }); return Promise.resolve({ ok: true, status: 200 }); }; try { const sse = require('../../services/graph-run-sse'); sse.transitionRun(created.runId, 'running', 'completed', {}, { summary: '用例直推终态' }); resolveDriver(); // 让 driver 的 then 链（如果还有的话）跑完再数：不 flush 就等于没验 await new Promise((r) => setImmediate(r)); await new Promise((r) => setImmediate(r)); } finally { globalThis.fetch = origFetch; } expect(posted).toHaveLength(1); expect(posted[0].body.taskId).toBe(created.goalId); // 留下的是 goal 级那条 // from = 交付者（org graph 末节点），不是下单人。created_by 默认就是字符串 'human'， // 下游拿它去 readStateFile('human','todo.md') 全部落空且不报错。 expect(posted[0].body.from).toBe(`${cid}:org-validator`); expect(posted[0].body.from).not.toBe('human'); }); // ────────────────────────────────────────────────────────────── // 验收 5 · 描述冻结（goal 与 task 各一个冻结点） // ────────────────────────────────────────────────────────────── it('已下达的 goal 改 description → 409 + hint，改 title → 200（验收 5）', async () => { const cid = newCompany(); const [, created] = await call('POST', `/api/company/${cid}/tasks`, { task: '写一版 landing page' }); const [conflict, err] = await call('PATCH', `/api/company/${cid}/goals/${created.goalId}`, { description: '换个需求', }); expect(conflict).toBe(409); expect(err.frozenFields).toEqual(['description']); expect(err.hint).toBeTruthy(); // 只说「不许改」而不说「怎么办」，用户就卡在这儿了 expect(wdb.getGoal(created.goalId).description).toBe('写一版 landing page'); // title 只是列表上的标签，不进任何 agent 的上下文，冻结之后照样能改 const [ok, patched] = await call('PATCH', `/api/company/${cid}/goals/${created.goalId}`, { title: '改个名' }); expect(ok).toBe(200); expect(patched.title).toBe('改个名'); }); it('task 同理：queued_at 一非空就拒改 description，title 仍可改（验收 5）', async () => { const cid = newCompany(); const [, created] = await call('POST', `/api/company/${cid}/tasks`, { task: '接入支付' }); // 起 run 那一刻描述已经写进 task-goal.json 被 agent 读走了，再改就是篡改审计输入 expect(wdb.getTask(created.taskId).queued_at).toBeTruthy(); const [conflict, err] = await call('PATCH', `/api/company/${cid}/tasks/${created.taskId}`, { description: '改成接入退款', }); expect(conflict).toBe(409); expect(err.frozenFields).toEqual(['description']); expect(wdb.getTask(created.taskId).description).toBe('接入支付'); const [ok] = await call('PATCH', `/api/company/${cid}/tasks/${created.taskId}`, { title: '支付' }); expect(ok).toBe(200); }); // ────────────────────────────────────────────────────────────── // 验收 6 · depends_on 成环 // ────────────────────────────────────────────────────────────── it('depends_on 写成环 → 400，且库里没有半条脏数据（验收 6）', async () => { const cid = newCompany(); const goal = wdb.createGoal({ companyId: cid, title: '双周迭代', description: '双周迭代' }); const t1 = wdb.createTask({ goalId: goal.id, title: 'T1', description: '先做 T1' }); const t2 = wdb.createTask({ goalId: goal.id, title: 'T2', description: '再做 T2' }); const [ok] = await call('PATCH', `/api/company/${cid}/tasks/${t2.id}`, { depends_on: [t1.id] }); expect(ok).toBe(200); // T1 反过来依赖 T2 就闭环了。环不是「跑起来才发现」的问题：调度器会把两条都判成 // 「上游没完成」，于是谁都不出队 —— 表现是任务静默躺着，界面上跟正常排队一模一样。 const [status, err] = await call('PATCH', `/api/company/${cid}/tasks/${t1.id}`, { depends_on: [t2.id] }); expect(status).toBe(400); expect(err.error).toMatch(/环/); // 「建完再查一次」才算验完：校验必须发生在写之前，半条脏数据都不许留 expect(JSON.parse(wdb.getTask(t1.id).depends_on)).toEqual([]); expect(JSON.parse(wdb.getTask(t2.id).depends_on)).toEqual([t1.id]); }); // ────────────────────────────────────────────────────────────── // 验收 10 · 列表端点不 N+1 // ────────────────────────────────────────────────────────────── it('5 goal × 3 task 的列表只发一次 graph_run_nodes 查询（验收 10）', async () => { const cid = newCompany(); const db = wdb.getDb(); const now = new Date().toISOString(); for (let g = 0; g < 5; g++) { const goal = wdb.createGoal({ companyId: cid, title: `G${g}`, description: `目标 ${g}` }); for (let t = 0; t < 3; t++) { const task = wdb.createTask({ goalId: goal.id, title: `T${g}-${t}`, description: `活 ${g}-${t}` }); // 每条 task 挂一条 run + 2 个节点行：没有 run 的 task 走不到进度查询，挡不住 N+1。 // run_status 用 completed —— 活跃 root run 是要占公司执行坑的（批 4 前还有一条同名唯一索引）， // 而这里要的是 15 条历史 run 同时出现在列表上（那正是 N+1 最疼的形态）。 const runId = `run_n1_${g}_${t}`; db.prepare(`INSERT INTO graph_runs (id, graph_kind, graph_id, company_id, root_run_id, run_status, created_at, updated_at) VALUES (?, 'org', ?, ?, ?, 'completed', ?, ?)`).run(runId, cid, cid, runId, now, now); for (const [i, st] of ['success', 'pending'].entries()) { db.prepare(`INSERT INTO graph_run_nodes (id, run_id, def_node_id, status, created_at, updated_at) VALUES (?, ?, ?, ?, ?, ?)`).run(`${runId}_n${i}`, runId, `d${i}`, st, now, now); } wdb.updateTask(task.id, { currentRunId: runId }); } } // 数的是 prepare 而不是 statement 执行：work-graph-db 每次调用都现 prepare 一条， // 改成逐行查进度必然体现为 15 次。 const origPrepare = db.prepare.bind(db); let nodeQueries = 0; db.prepare = (sql) => { if (/graph_run_nodes/.test(sql)) nodeQueries++; return origPrepare(sql); }; try { const [status, body] = await call('GET', `/api/company/${cid}/goals?withTasks=1`); expect(status).toBe(200); expect(body.goals).toHaveLength(5); expect(body.goals.flatMap((g) => g.tasks)).toHaveLength(15); // 顺带把口径钉住：只数 prepare 次数的话，一条恒返回空的查询也是 1 次 expect(body.goals[0].tasks[0].progress).toEqual({ done: 1, total: 2 }); expect(nodeQueries).toBe(1); nodeQueries = 0; const [taskStatus, taskBody] = await call('GET', `/api/company/${cid}/tasks`); expect(taskStatus).toBe(200); expect(taskBody.tasks).toHaveLength(15); expect(nodeQueries).toBe(1); } finally { delete db.prepare; // 还原成原型上的那个，别把桩留给同进程的后续用例 } }); // ────────────────────────────────────────────────────────────── // 验收 11 · /goals 的 OKR 别名退役 // ────────────────────────────────────────────────────────────── it('/:cid/goals 归 goal 两级模型，/:cid/okr 仍是 OKR（验收 11）', async () => { const cid = newCompany(); const goal = wdb.createGoal({ companyId: cid, title: '别名退役', description: '别名退役' }); // 别名还在的话这条会被 OkrService 接走，返回 objective 数组而不是 { goals: [...] } const [status, body] = await call('GET', `/api/company/${cid}/goals`); expect(status).toBe(200); expect(body.goals.map((g) => g.goalId)).toEqual([goal.id]); const [okrStatus, okrBody] = await call('GET', `/api/company/${cid}/okr`); expect(okrStatus).toBe(200); expect(Array.isArray(okrBody)).toBe(true); // OkrService.list() 的形状，没被 goal 模型顶掉 }); it('两个 server 入口都不再挂 /api/goals 别名（验收 11）', () => { // 这条是源码级断言：别名的注册点在 index.js / agent-server.js，路由测试够不着。 // 漏掉任何一个入口，agent-server.js 那条路上 /api/goals 就仍指向 OKR —— // 而两个入口的差异恰恰是最不容易被人想起来跑一遍的地方。 for (const entry of ['../../index.js', '../../agent-server.js']) { const src = fs.readFileSync(path.resolve(__dirname, entry), 'utf-8'); expect(src).not.toMatch(/app\.use\(\s*['"]\/api\/goals['"]/); expect(src).toMatch(/app\.use\(\s*['"]\/api\/okr['"]/); } }); });