-
agent 之间派单（POST /api/agent/task/dispatch）与「跑一张 org graph」是 两种执行载体，硬说成一回事是骗自己：前者直接起一次 agent 对话，后者走 调度器出队 + 图执行。所以显式建模而不是让调度器去猜 —— executor（graph|agent）、assignee_agent_id、parent_task_id（派单链， 与 depends_on 的「同级先后」不是一回事）。 迁移的落点对：旧行 executor 缺省 'graph'（批 1-4 建的全是图任务）， 另两列 NULL。 ## 加这一步时踩到并修掉的一个会让存量库开不了的 bug 第一版把 CREATE INDEX ... ON tasks(assignee_agent_id) 写进了建表块。 建表块整体先于迁移块执行，而存量库上 CREATE TABLE IF NOT EXISTS tasks 是 no-op —— 表还是批 4 的形态、没有那一列，于是这句索引直接抛 「no such column」，getDb() 起不来 = **所有存量库一启动就炸**。 而新建库（单测默认走的那条路）完全正常，只测新建库根本看不见这个洞。 已把索引挪进迁移块、排在 ALTER 之后。 守卫：server/tests/unit/tasks-executor-migration.test.js —— 真造一个 批 4 形态的库（删索引 + 删三列）再重开，断言三列与索引都补回、 executor 默认值是 'graph'。 另记一处自己踩的：SQL 模板字符串里的注释用了反引号，把 db.exec 的模板 提前闭合了。DDL 注释里一律不用反引号，已写进那段注释。 已知不对称：ALTER TABLE ADD COLUMN 加不了 CHECK 也加不了外键，所以存量库 上 executor 的取值域只由应用层守，与新建库的 CHECK 不同源。写在注释里， 免得下一个人以为库层拦得住。 全量：129 文件 / 1245 测试全绿（+2 新守卫）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
