refactor(workflow): DAG 编排剥成 @helios/workflow，依赖只有 ports（A-9 部分）

[fujiwarazz]

A-9。base 是 main（#49–#55 已全部合入）。

先说 A-9 的前提只对了一半

原表述：「workflow.ts 落在 packages/kernel/src/agentSpec/，但 DAG 编排比 session 高一层，kernel 的职责是『跑一个 run』」。

查下来不成立。workflow 不是 kernel 的上层，它是 kernel 注册给模型的一个工具（agentSpec/agentTools.ts），运行时嵌在 session 里、靠会话级 DerivedAgentExecutor 干活。

而且照字面搬会包级循环依赖：workflow.ts 的唯一调用方在 kernel 内，而它自己又反过来 import kernel 的 load / validate / selectTools / portResolver / derivedAgentExecutor。

所以这期只剥出纯算法层。把它抬到 kernel 之上（做成 extension）依赖 A-8 —— agentTools.ts 现在靠 executorFor: (sessionId) => … 取会话级执行器，那正是 A-8 要删的 service locator。已在 docs/follow-up-work.md 把 A-9 标为「部分 DONE」并记下这条依赖。

做了什么

新包 @helios/workflow，依赖只有 @helios/ports，方向 kernel → workflow 单向：

文件	职责
compile.ts	纯图算法：解引用、查环、拓扑分层、定唯一终止节点
schedule.ts	只按计划调度；对"派生执行器"的需求以窄接口表达（WorkflowControl / NodeOutcome / WorkflowRunContext），不 import kernel 的类

三个共用纯函数落到 ports/agentSpec.ts（两个包都要用，公共部分只能放共同下层，与 skill.ts 的 parseFrontmatter 同一先例）：isWorkflowSpec / resolveDefinition / workflowNodeId。workflowNodeId 带前缀是刻意的 —— nodeId 在 session.ts 里指消息树节点，同名不同义。

顺带收紧两处：

• CompileContext 的 allTools + portResolver 两个字段收成一个 checkAssembly。「这个 agent 装得起来吗」是 kernel 的知识（它才持有工具池与 Port 白名单），workflow 只要一个「是/否 + 原因」。字段变少了，边界反而更清楚。
• WorkflowRunContext.executor 是死字段，runWorkflow 从来没用过它（测试里一路 executor: {} as never 传着）。删掉。

护栏

packages/workflow/test/dependency-direction.test.ts —— 对源码 import 与 package.json 的静态断言，含一条「护栏本身不是空的」自检（防 readdir 指错目录时前两条永远绿）。

⚠️ 这类反向依赖 typecheck 抓不到：pnpm workspace 里 @helios/kernel 本来就解析得到，TS 会愉快编过去，只在拆包 / 发版 / 拓扑构建时才炸。

变异 9/9 命中：源码 import kernel / package.json 加 kernel 依赖 / 护栏扫错目录 / 分层按完成顺序 / 多终止节点放过 / 上游拼接乱序 / 节点失败仍跑下游 / checkAssembly 不调 / 嵌套深度上限失效。

顺带修掉三处测试质量问题

这三处都是这轮跑回归时被逼出来的，不是顺手重构。

① workflow live 用例长期假红

它把代码属性和模型能力混在一条断言里（toContain("PINEAPPLE-42") 同时要求「数据沿 DAG 流动」和「叶子 agent 会去调 Read」）。

补两条确定性断言：joiner 的 prompt 里确实有 <upstream node="pw"> 块 —— 那正是本次搬走的 buildNodeInput 产出的。然后按语义判据分流：

• 上游 pw 自己都没拿到口令 → 叶子没干活（模型问题）→ skip 并打印原因
• 上游有、终点没有 → 数据真没流过来 → 硬红

不按标记形态识别是吃过教训的：实测已见四种形态（<｜DSML｜invoke> / <use_mcp_tool> / <function_calls> / <tool_use>），我追加过一轮又漏了第四种 —— 那是无穷枚举。

验证 skip 没吞掉真回归：变异掉 buildNodeInput 的拼接后，用例仍在 <upstream> 断言上变红。

② eval 的分母一直是错的

以前一律拿全集 DEFECTS.length 作分母，于是每轮往 eval set 加缺陷都会把所有场景的分数稀释一遍。我曾把 39/41 → 41/44 → 24/46 当趋势报给你 —— 那是三个不同的量，denominator 和被审文件集都在变，不可比。这是我的测量错误。

现在各场景按自己的文件范围算分母（分子也要过滤，否则打出 10/8 这种数字）。修完各场景是满分：

readonly 8/8 · async 3/3 · robustness 3/3 · trust 3/3 · cross-file 3/3
numeric 3/3 · layering 3/3 · duplication 3/3 · loader 3/3
registration-order 3/3 · dependency-direction 2/2

另外 readonly 广度扫描已经撞了 600s 上限被截断（单跑必超时，批内勉强跑完但结论不全）—— 那才是「24/46」的真因，不是模型变差。范围钉死到 4 个文件；它只负责回答「一次广度扫描能不能捞到有意义的东西」，新类别请配套新增专项场景而不是往这个 scope 里加文件。

③ CLI e2e 两个用例间歇假红

runCliArgs 完全没有内部看门狗，子进程不退出就靠 vitest 的 5s 兜底 —— 而那条路径不杀子进程，留下一个还在跑的 tsx 孤儿，报错也只有无信息量的「Test timed out」。

configDiscovery 更荒谬：内部看门狗 10s > 外层 5s，于是那句精心写的诊断（CLI did not become ready. Output:...）永远不可能出现。内层预算大于外层 = 把诊断关掉了。

已加看门狗（20s，小于 testTimeout 30s）并放宽外层。

验证（三层退出码均为 0）

层	结果
typecheck	0
单测	951 passed
live 全套	20 passed / 4 files
CLI 真机	3 turn、零失败调用

eval set 44 → 46，新增第十一类「依赖方向」：

id	形状
upward-import	plan.ts（底层图算法）import 了上层 orchestrator，形成相互依赖
leaked-upper-type	compile 收了上层整个 Orchestrator，实际只用它一个方法

与 layering-review 那一类的区别：那边判据写在 README 的架构约定里，这边写在被违反的那个文件自己的 JSDoc 里，而违反的痕迹只有一行 import —— 不看另一个文件就不知道那是"上层"。新场景 dependency-direction-review 命中 2/2。