Merge remote-tracking branch 'origin/main' into main

部署
2 parents 5313b4f2 a09b519b
Showing 43 changed files with 2296 additions and 92 deletions
CLAUDE.md
bin/lemon.js
docs/README.md
docs/todo/system-design/29-dream-design.md → docs/done/system-design/29-dream-design.md
docs/todo/system-design/33-needs-gate-role-filter-bug.md → docs/done/system-design/33-needs-gate-role-filter-bug.md
docs/todo/system-design/35-validation-rigor-and-body-readiness-proposal.md → docs/done/system-design/35-validation-rigor-and-body-readiness-proposal.md
docs/todo/system-design/39-boss-agent-task-supervision.md → docs/done/system-design/39-boss-agent-task-supervision.md
docs/todo/system-design/40-agent-chat-streaming-interrupt.md → docs/done/system-design/40-agent-chat-streaming-interrupt.md
docs/done/system-design/42-org-work-graph-reliability-followups.md
docs/todo/system-design/28-followups.md
docs/todo/system-design/31-work-graph-fail-fallback-coverage.md
docs/todo/system-design/34-validator-scored-without-real-deliverable.md
docs/todo/system-design/43-task-decomposition-granularity.md
server/index.js
server/routes/agent-chat.js
server/routes/company.js
server/routes/dream.js
server/routes/graph-run.js
server/services/company-service.js
server/services/dream-service.js
@@ -110,7 +110,7 @@ npm run okr:migrate               # goals → okr 存量迁移
 | `/ws/claude` | Claude 实时对话（仅 `index.js`） |
 | `/api/health` `/api/plugins` | 健康检查 / 插件状态 |
 | `/api/devloop/projects` | DevLoop：创建项目 + 跑 PM/Architect（POST）、列项目 / 查状态（GET，见下） |
-| `/api/dream/*` | 经验汇流（29-DREAM）：`dream-service.js` 能力的 REST 封装，只读查询 + 触发 `dreamOnce`/`dreamSweep`，不新增业务逻辑，见 [`docs/todo/system-design/29-dream-design.md`](docs/todo/system-design/29-dream-design.md) |
+| `/api/dream/*` | 经验汇流（29-DREAM）：`dream-service.js` 能力的 REST 封装，只读查询 + 触发 `dreamOnce`/`dreamSweep`，不新增业务逻辑，见 [`docs/done/system-design/29-dream-design.md`](docs/done/system-design/29-dream-design.md) |
 ### DevLoop 子系统
@@ -184,6 +184,16 @@ async function run() {
         phase: values.phase, artifact: values.artifact
       });
       console.log(JSON.stringify(res.data, null, 2));
+
+      // 42 号文档 Phase 4：额外打一次 graph-runs 的 phase-note 端点，把这次阶段流转
+      // 落进 timeline.ndjson（大多数调用方——legacy 会话式 agent——这个端点会安静
+      // no-op，因为 --artifact 不是 work graph 节点产物目录的形状；不影响上面那次
+      // 调用的结果，出错也不影响本命令的退出码）。
+      try {
+        await request('POST', '/graph-runs/phase-note', {
+          artifact: values.artifact, phase: values.phase, agentId: values.agentId
+        });
+      } catch { /* best-effort，静默丢弃 */ }
     }
     else if (command === 'pipeline create') {
       const { values } = parseArgs({ args: args.slice(2), options: {
@@ -31,6 +31,12 @@
 | [system-design/27-p3c-batch3-handover.md](./done/system-design/27-p3c-batch3-handover.md) | 批 3 交接 —— ✅ 已收口（2026-08-20）。**事故记录归档**：一份未经复核的代码被第三方会话提交进 main。留着是因为 §六 那几条多会话协作规则是真踩出来的 |
 | [system-design/38-auth-multi-tenant-isolation.md](./done/system-design/38-auth-multi-tenant-isolation.md) | 登录鉴权 + 公司级多租户隔离 —— ✅ Phase 0/1/2/3 全部完成（2026-08-25）。种子账号 `admin`/`hex1234` + 登录页；全站挂 `requireAuth`（`agent-chat.js` 用 `requireAuthOrInternal` 放行三处服务端自环调用）；`company.json` 加 `ownerId`，`canAccessCompany` 是全仓库唯一归属判据，`company.js`/`graph-run.js`/`devloop.js` 分别接入（`graph-run.js` 双挂载点参数形状不同，设计阶段描述不准确，实现时才发现）；`okr.js` 因是零导航入口的孤儿页面改挂 `requireAdmin` 而非归属校验。**Phase 3 验证阶段真查出一个漏洞**：`agent-chat.js` 靠 `:agentId` 的 `"companyId:role"` 前缀区分会话归属却从没做过归属校验，任意登录用户可跨租户读别家公司会话，已修复。全量 `vitest` 1433 passed |
 | [system-design/01-26](./done/system-design/) | 系统设计正文 01～26 章（14、25-harness-engineering-improvements 例外，见 todo/future/；27 例外，见 todo/），各章节状态见文内「状态」标记 |
+| [system-design/29-dream-design.md](./done/system-design/29-dream-design.md) | **dream（经验汇流）**— ✅ 已实现。定时整理所有 agent 在所有公司的记忆，提炼后跨公司沉淀（不泄漏公司信息）。四条取舍已拍板并实现：去敏独立判定、四落点分层写入（经验/`SKILL.md`/`soul.md`/`agent.md`，受管区块+三道闸门）、每日定时（串行+空转保护）、引用真伪自动查、REST+控制台入口（`/api/dream/*`、`/dream`）。`innovator-evolver` 真 CLI 跑通一次。**仍缺的**：「结论对不对」只能人抽查；「套进 org/work graph 来跑」评估后用户选了不做（作用域不匹配，见文内 §5.7） |
+| [system-design/33-needs-gate-role-filter-bug.md](./done/system-design/33-needs-gate-role-filter-bug.md) | ✅ **已修复**。`executor.json`/`executor-fanout.json` 里 `produces:["log"]` 声明了一个 test/integration 类节点永远不会被索引到的 kind，导致 `org-coder-validator` 被 `missing_required_input` 反复误判 blocked；改成 `required:false`（对齐 `validator.json` 既有写法）。文档记录了一条**走过的弯路**（按 role 过滤 `inboundContracts` 会削弱 T-mt25ecbd 的产出闸门，已撤回），发现于 31 号文档的真实回归验证过程中，与兜底边问题无关 |
+| [system-design/35-validation-rigor-and-body-readiness-proposal.md](./done/system-design/35-validation-rigor-and-body-readiness-proposal.md) | 📝 **复盘 + 改进方案，四条提案全部已实施**。承接 31/32/33/34 号的复盘结论：任务结果差主要是架构问题（完整性闸门 `missingBodyDefinition` 只在招聘时查、图执行侧完全没有第二道防线——新发现）+ 一个具体的招聘装配可靠性 bug，不是 agent 能力问题。提案 A：本体不完整时图执行前置判 `fail_reason=body_not_ready`，不扣预算。提案 D：`goal-contract.js` 的 `evidence_hint` 命中浏览器类关键词的维度必须有证据支撑，否则判不过。提案 C：新增 `scripts/visual-acceptance-check.mjs` 复用检查工具。提案 B：控制台「验收证据」小节展示每个维度有没有证据支撑 |
+| [system-design/40-agent-chat-streaming-interrupt.md](./done/system-design/40-agent-chat-streaming-interrupt.md) | ✅ **已实现**（commit `4d23f50`，2026-08-30）。回应"前端刷新不及时/没有打字机效果，要不要把 SSE 换成 WebSocket"——排查后结论是传输层不是瓶颈（对照 hermes-webui/hermes-agent/deepseek-harness 三个参考实现，全部走 SSE，不用 WebSocket）。三个独立缺口全部补上：① 打字机不流畅→后端按字符数切片 + 前端 `createTypewriterQueue` 匀速吐出；② 执行中无法打断并接上新消息→`stop` 端点改轮询确认锁真正释放，前端据此直接发送/强制发送兜底，顺带修了服务端对同 convId 并发缺闸门这个真实 bug；③ 串台加固→`handleEvent` 抽成纯函数并补齐 `9b1c3f1` 那条不变式的回归测试。已用真实 Claude CLI 会话在浏览器验证 |
+| [system-design/39-boss-agent-task-supervision.md](./done/system-design/39-boss-agent-task-supervision.md) | ✅ **P1-P5 全部已实现**（2026-08-30，`a00590a`/`5108d67`/`d967ac0`/`14cbaf5`）。boss agent（复用 `ceo`）监督 goal/task 看板闭环：draft task 回写、事件驱动+低频兜底唤醒、独立任务看板页、公司级 `target_dir`。**真实端到端测试**（建公司→下 goal→跑出一个 Playwright 5/5 验证通过的贪吃蛇游戏）撞出并记录了三个单测没覆盖的真问题，见文内「七、真跑复盘」；沉淀的待办已在 [42-org-work-graph-reliability-followups.md](./done/system-design/42-org-work-graph-reliability-followups.md) 全部收口 |
+| [system-design/42-org-work-graph-reliability-followups.md](./done/system-design/42-org-work-graph-reliability-followups.md) | ✅ **Phase 1-4 全部已实现**（2026-08-30，`6ae1f76`/`2a60fe1`/`ae7650e`/`2a0ffb8`）。39 号文档真跑复盘沉淀的四 phase 可靠性收尾：① 卡住恢复闭环（服务器重启僵尸节点检测 + 强制判失败端点）② `ceo` 自建 task 的闸门穿透性回归测试 ③ `target_dir` 的 API/UI 配置入口（Phase 3 前端缺一次真实浏览器点击验证，见该节说明，是唯一已知缺口）④ `timeline.ndjson` 承接 planning/reflection 轨迹——`--artifact` 路径本身编码 `rootRunId`/`nodeRunId`，不用改任何 agent.md 或塞新环境变量 |
 ## todo/（当前主线）
@@ -48,17 +54,13 @@ Graph Agent 架构重构（27 系列）。**已完成的阶段文档已移入 `d
 | [27-goal-contract-format.md](./todo/system-design/27-goal-contract-format.md) | 验收契约格式（`goal-benchmark` / `goal-test-data` / `goal-test-script` 的产物形态与跨节点传递） |
 | [27-p4-parallel-and-artifacts.md](./todo/system-design/27-p4-parallel-and-artifacts.md) | **P4（回收编号）并行执行与产物索引** — 📝 设计中，未实现。fan-out 真并发 + 同 agent 多实例隔离 + `files.json` 产物索引。三个 Phase，C 可插队 |
 | [28-followups.md](./todo/system-design/28-followups.md) | 28 号（Agent 注册表统一）的遗留清单 — 主文档已在 `done/`，这份装没做完的：dream 机制（设计见 29 号，已实现，见下）、`source_kind`（✅已删）/`legacy_path`（不能删）删列、三项「已实施未验证」。任务态清理（✅已实现，见下）。§五 是**已立起来的守卫清单**（别重复造，也别删） |
-| [29-dream-design.md](./todo/system-design/29-dream-design.md) | **dream（经验汇流）**— ✅ 已实现。定时整理所有 agent 在所有公司的记忆，提炼后跨公司沉淀（不泄漏公司信息）。四条取舍已拍板并实现：去敏独立判定、四落点分层写入（经验/`SKILL.md`/`soul.md`/`agent.md`，受管区块+三道闸门）、每日定时（串行+空转保护）、引用真伪自动查、REST+控制台入口（`/api/dream/*`、`/dream`）。`innovator-evolver` 真 CLI 跑通一次。**仍缺的**：「结论对不对」只能人抽查；「套进 org/work graph 来跑」评估后用户选了不做（作用域不匹配，见文内 §5.7） |
 | [30-task-delegation-reliability-gaps.md](./todo/system-design/30-task-delegation-reliability-gaps.md) | **任务委派可靠性现状**— 📝 调研记录，非设计方案。DevLoop `runUnit`、Company 招聘装配、Graph 执行三条链路核对结论一致：都是「失败预算耗尽 → 停等人工」，没有「卡住了主动通知人」这一层；DevLoop 当前还默认走 mock，真实 CLI 成功率无实证数据。2026-08-23 追加真实实例并已修：`infra_flake` 原地重跑没有熔断线，真撞上过一次确定性死循环（节点把诊断结论误判成自己的执行结果，反复重跑却从不路由到诊断建议的目标节点）；已加 `infra_flake_count` 列 + 硬顶 3 次熔断，连续判 infra_flake 超过硬顶就改判 blocked 交给人工 |
 | [31-work-graph-fail-fallback-coverage.md](./todo/system-design/31-work-graph-fail-fallback-coverage.md) | work graph 兜底边覆盖不全 — ✅ 已完成（除入口节点外强制兜底边，`planner.json`/`executor-fanout.json` 补 6 条边），978/978 单测通过；2026-08-21 又用真实 LLM 起了一条新任务做端到端回归验证，`org-planner-sdd` 自判失败后自动打回 `org-planner-prd`（3 次，零人工介入），修复确认生效 |
-| [39-boss-agent-task-supervision.md](./todo/system-design/39-boss-agent-task-supervision.md) | 📝 **设计评估中，未实现**。评估用户提出的五阶段方案（雇 boss agent 监督 goal/task 看板、独立任务看板页、心跳挨个调度、org/work graph 产出的 bug/新任务回写看板、公司级目标代码目录）。结论：P2 看板已实现、P1/P3 心跳与 `ceo` 本体基础设施已有大半、P5 的 `linked-existing` 模式已在 `path-resolver.js` 完整实现只差公司级默认值，**真正从零开始的是 P4（回写闭环）**——当前没有任何 agent 工具能读写 goal/task 板。建议顺序倒过来先建 P4 地基 |
 | [41-graph-vs-fde-reliability-discussion.md](./todo/system-design/41-graph-vs-fde-reliability-discussion.md) | 📝 **讨论记录 + 落地实测，非设计方案**。org/work graph 与 master-Innovator-FDE 两套工作流的稳定性对比：根因是"拓扑运行时生成 vs 写死"。问题 7 是真实执行记录——新建 `org-hunt/digest/evolve`（graph 原生协议，方法论抄 innovator-hunt/digest/evolver）跑 Hunt→Digest→Evolve，11 轮真跑中挖出并修复 5 个独立缺陷（建公司自动规划竞态、work-graph 模板库缺内容型交付物骨架、验收节点任务描述越权、两个规划 agent 的路径口径写错、R-19 产出索引 `indexNodeOutputs()` 不覆盖项目根——最后一条改了 `graph-engine.js` 核心逻辑，加 `contract.json` 的 `produces` 显式声明机制，全局生效，补了 2 条守卫测试）。最终产出与原生 FDE（`prd-methodology-trial`）对比：内容骨架可迁移、质量不打折，但过程严谨度不如原生 FDE，可靠性差距悬殊（原生一次跑通，graph 版 11 轮才稳定）。`routeFailure` 的 `infra_flake` 分支绕过跨层寻址（`target_node`）仍是唯一确认还没补的口子 |
 | [37-org-graph-department-scoping.md](./todo/system-design/37-org-graph-department-scoping.md) | 📝 **设计讨论，调用点扫描已完成，尚未立项实现**。现状 org graph 按 `company_id` 单例（`27-P2` 标题原文即"公司级"），塞不下 HR/财务/市场这类跟"交付流水线"无关的公司常设职能——`system/agents/hr/`（"招·留·管·退"）本体已存在却从没被装进任何图，全靠 fire-and-forget chat 招聘、无图执行审计轨迹。提议把 org graph 作用域从 `company_id` 升级为 `(company_id, department_id)`，一家公司可装配多张部门图，每张仍保持人工固定/慢变/可审计。全仓库调用点扫描结论：改造面是最初估算的 4 倍——真正的单点真相在 `work-graph-db.js:readDefGraph` 的裸 SQL 不变式（不在服务层），还牵涉两个易混淆服务文件间必须字节级一致的重复唯一索引、独立的 `graph-seed-service.js` 对账子系统、`company-hire-org-layer.test.js` 专属测试、`orggraph-planning`/`task-planning` 两份 agent 人设文档的自我认知改写 |
 | [36-prd-agent-methodology-training-feasibility.md](./todo/system-design/36-prd-agent-methodology-training-feasibility.md) | 📝 **调研 + 阶段一/二均已完成**。回应"落地页太单薄是不是该用 Innovator 先训练专业 agent、再用 Dream 持续迭代"——认同方向。**阶段一**：`graph-engine.js` 结算节点后把 `success`/`fail:<reason>` 写进本体 `memory.md`（此前只有人类对话路径会写，Dream 天天空转）。**阶段二**：新建独立试验节点 `prd-methodology-trial` 走真实 Hunt→Digest→Evolve，2 轮收敛（96/97 分，真实基线 50 分），三个真实历史项目反推验证方法论有效；过程中连带修复同一个 2026-08-16 改名批次遗留的 5 处 `innovator`→`org-innovator` 死链（后端两处硬编码、前端"重新训练"按钮、`/api/agent/list` 展示 id 来源的四个 `config.json`），以及 `AgentScaffold` 默认模板一处裸相对路径缺陷。结论：FDE 对方法论类角色确实管用，但收敛速度/验收严谨度依赖任务书显式写明的自纠正要求，非免人工黑盒。环节 3（训练产物 → 雇佣本体转换）尚未开工 |
-| [35-validation-rigor-and-body-readiness-proposal.md](./todo/system-design/35-validation-rigor-and-body-readiness-proposal.md) | 📝 **复盘 + 改进方案，四条提案全部已实施**。承接 31/32/33/34 号的复盘结论：任务结果差主要是架构问题（完整性闸门 `missingBodyDefinition` 只在招聘时查、图执行侧完全没有第二道防线——新发现）+ 一个具体的招聘装配可靠性 bug，不是 agent 能力问题。提案 A：本体不完整时图执行前置判 `fail_reason=body_not_ready`，不扣预算。提案 D：`goal-contract.js` 的 `evidence_hint` 命中浏览器类关键词的维度必须有证据支撑，否则判不过。提案 C：新增 `scripts/visual-acceptance-check.mjs` 复用检查工具。提案 B：控制台「验收证据」小节展示每个维度有没有证据支撑 |
 | [34-validator-scored-without-real-deliverable.md](./todo/system-design/34-validator-scored-without-real-deliverable.md) | 📝 **调研记录，checklist 已查完**。最初以为 `org-coder-impl` 从未产出任何 HTML/CSS，后来发现真实网站其实存在于 `graph_files` 索引不覆盖的「项目根」目录（已顺手修：控制台「产物」面板现在会展示项目根）。追加查清 validator 有没有真的做浏览器级检查——中途自我订正一次：不是"没工具做不到"（`bash` 能走到仓库自带的 Playwright，另一条对照任务证明可行），是**没人教它这么做**；抽查另外两个项目根后发现**验证严谨度完全不稳定**（同类任务有的做了真实 Playwright 级验证、有的只做静态正则、有的没验证就被取消），根因很可能是新招聘的 `unit-tester` 本体撞上了 [32 号文档](./todo/system-design/32-hire-body-fill-reliability.md) 那类"装配没填充完"的真实样本，不是平台工具限制 |
-| [40-agent-chat-streaming-interrupt.md](./todo/system-design/40-agent-chat-streaming-interrupt.md) | 📝 **需求文档，讨论中，未实现**。回应"前端刷新不及时/没有打字机效果，要不要把 SSE 换成 WebSocket"——排查后结论是传输层不是瓶颈（对照 hermes-webui/hermes-agent/deepseek-harness 三个参考实现，全部走 SSE，不用 WebSocket）。真正的三个独立缺口：① 打字机不流畅（ACP chunk 粒度太粗，方案是前后端都做匀速切片/渲染缓冲）；② 执行中无法打断并接上新消息（现状"先 Stop 再发"两步，方案是深度 1 的打断-排队，顺带发现服务端对同 convId 并发缺闸门这个现存 bug）；③ 串台已在 `9b1c3f1` 修复但没有回归测试兜底 |
-| [33-needs-gate-role-filter-bug.md](./todo/system-design/33-needs-gate-role-filter-bug.md) | ✅ **已修复**。`executor.json`/`executor-fanout.json` 里 `produces:["log"]` 声明了一个 test/integration 类节点永远不会被索引到的 kind，导致 `org-coder-validator` 被 `missing_required_input` 反复误判 blocked；改成 `required:false`（对齐 `validator.json` 既有写法）。文档记录了一条**走过的弯路**（按 role 过滤 `inboundContracts` 会削弱 T-mt25ecbd 的产出闸门，已撤回），发现于 31 号文档的真实回归验证过程中，与兜底边问题无关 |
+| [43-task-decomposition-granularity.md](./todo/system-design/43-task-decomposition-granularity.md) | 📝 **需求 + 方案定案 + 技术实现计划（5 个 Phase）已写完，尚未开工**。回应"org-planner 出 brd/prd/sdd 后，任务看板能不能展示成 task/sub-task 树，coder-validator 按清单逐条开发验收"。方案：goal→task 流水线自建父子机制、先只拆验收（开发仍整体完成）、`tasks.acceptance_mode` 由 task-planning 判断、子任务复用 `tasks.status` 既有状态语义、任一子任务 fail 父任务即 fail。**Phase 0-4** 逐条核实了代码形态：`createTask()`/`parent_task_id` 迁移模板、task-planning "硬规则 5"需要开例外让 LLM 多写一个字段、`org-planner` 产出的验收清单其实是 `acceptance.md` 不是 `acceptance.json`（且⚠️真实回归里从未被用上，落地前需先验证可靠性）、`coder-validator`（不是 org-validator，文档订正过一次）的 `checks[]` 目前没有任何服务端代码解析、看板树形渲染有 `FileNode.vue` 现成模板可抄。建议实施顺序 Phase 0→1→4→2→3 |
 ## todo/future/（暂缓，非当前重心）
 # 39. Boss Agent 任务看板监督 + 公司目标代码目录 — 需求评估与设计草案
-> **状态**：✅ P1-P5 已实现（2026-08-30，commit `a00590a` P1/P3/P4 后端、`5108d67` P2 前端、`d967ac0` P5）。本文档是落地前的设计草案，实现细节以代码为准，本文档不再更新，仅存档决策过程。**已知未覆盖的后续工作见文末新增的「六、已知遗留」**。
+> **状态**：✅ P1-P5 已实现（2026-08-30，commit `a00590a` P1/P3/P4 后端、`5108d67` P2 前端、`d967ac0` P5、`14cbaf5` graph-run.js 鉴权补丁）。本文档是落地前的设计草案，实现细节以代码为准，仅存档决策过程。**已知未覆盖的后续工作见「六、已知遗留」，真实端到端跑测的复盘见「七、真跑复盘」，复盘沉淀的待办已拆成独立文档 [42-org-work-graph-reliability-followups.md](./42-org-work-graph-reliability-followups.md)（按 phase 排开工顺序）**。
 > **日期**：2026-08-30
 > **背景**：承接对话讨论——goal/task 两级模型（[27-P3C](../../done/system-design/27-p3c-goal-task-model.md)）已落地，但推进它的是纯确定性代码（`task-scheduler.js` + `transitionRun` 钩子），没有任何 agent 在持续监督这块看板、处理异常、把执行中发现的新问题回写成新任务。用户提出五阶段方案补上这一层，并追加公司级目标代码目录需求。
 > **读者须知**：本文档大量引用现有代码路径核实"已有 vs 缺失"，结论以文内给出的具体函数/文件为准；这些引用会随代码演进过期，落地前请重新核实。
@@ -190,3 +190,29 @@
 1. **§四.4 定案的"回归测试钉死闸门"没有单独落地**。`ceo` 自主 `draft` + `enqueue` 走的是和人类调用完全相同的 `POST /:cid/tasks` → `POST /:cid/tasks/:taskId/enqueue` 两个端点（`max_parallel_tasks`/`DEFAULT_TASK_BUDGET`/goal 级 `org-validator` 这几道闸门都挂在数据层/调度器层，不认"谁创建的"，理论上自动覆盖），但没有一条测试专门断言"ceo 创建的 task 一样会被这几道闸门拦下"——现有测试（`task-entry-draft-mode.test.js`、`task-blocked-ceo-wake.test.js`）验的是 draft 模式本身和唤醒机制，不是闸门穿透性。理论上没有绕过的口子，但没有测试钉死就不能说"已确认"。
 2. **`company.json.target_dir`/`target_mode` 没有任何 API/UI 入口去设置**——现在只能手工编辑公司态目录下的 `company.json` 文件才能配置。P5 落地的是"读取并生效"这一半，"人怎么把这两个字段填进去"这一半还没做（哪怕只是一个 `PATCH /api/company/:cid` 端点）。
 3. **`server/routes/graph-run.js` 漏了同一处鉴权修复，已在真实跑动中撞出来并修复（2026-08-30）**。地基 0 当时只改了 `company.js`（goals/tasks 端点），`graph-run.js`（run 的 start/stop/retry/budget 等控制端点）还是纯 `requireAuth`。真实端到端测试里 `ceo` 被唤醒后能读写 goal/task 板，但调 `/api/graph-runs/*` 处理卡住的 run 时精确撞上 401，自己在对话记录里诊断出这一点并写出了人工需要跑的 curl 命令。已修：`router`/`companyRouter` 两个挂载点都改成 `requireAuthOrInternal`，两处 `:companyId`/`:id` 的 `param` 中间件加了与 `company.js` 一致的 `req.user?.internal` 旁路，`route-auth-gate.test.js` 同步更新断言，全量测试零回归（1469/1473，剩余 4 个是核实过的 pre-existing 失败）。**这次的教训**：地基 0 的"这一步做完了"判据不能只看 `company.js` 一个文件——`ceo` 需要触达的控制面横跨两个路由文件，遗漏了没有靠代码审查发现，是靠真实跑一遍才暴露的。
+
+---
+
+## 七、真跑复盘（2026-08-30，`snakegame-co` 端到端测试）
+
+P1-P5 落地后，用它做了一次真实端到端测试：建公司 → 手工配 `target_dir` 指向一个真实的空目录 → 下一个"做 HTML 版贪吃蛇游戏"的 goal → `task-planning` 真实拆分 → 全程真实 Claude CLI 调用把 org-planner（PRD/SDD/验收标准）→ org-coder（RESEARCH/PLAN/EXECUTE/VERIFY，含真实的 test/validator/impl 修正迭代）跑完，最终 `goal status: done`、`task status: completed`，产出的 `index.html` 用独立跑的 Playwright 测试验证 5/5 通过（一个可以在浏览器里直接玩的贪吃蛇游戏）。
+
+**核心结论：1469 个单测全绿，这一次真实端到端跑动却测出了至少三个单测完全没覆盖到的真问题。** "全部测试通过"不能当"系统能用"的证据——这次最有价值的发现，没有一个是单测挑出来的，全是真实跑一遍撞出来的。
+
+### 7.1 真跑撞出的技术缺口
+
+按发现顺序：
+
+1. **服务器重启会让 in-flight 的 graph 节点变僵尸，没有任何机制能自动发现**。为了让 `graph-run.js` 鉴权修复生效重启了一次服务器，正在跑 `org-planner-sdd` 的真实 Claude CLI 子进程被连带杀掉，但 `graph_run_nodes.status` 永远停在 `running`——`ceo` 的两条唤醒路径（事件驱动 + 30 分钟兜底扫描）判据都只认 `status='blocked'`，对"运行中但背后进程已死"这个状态完全不可见。查过现成的"重启后清理残留"机制（`server/index.js` 的 `resumeIncompleteTasks()`），发现它只管 ArenaSK 的 Skill 训练任务，跟 org/work graph 毫无关系；`shutdown()` 也只关插件管理器，不碰 `graph_run_nodes`。这是这次代价最大的一个坑，恢复时手写了一段脚本直接调 `graph-run-sse.transitionNode` 强制把节点判成 `fail`（走的是引擎自己的转换机制，不是绕过系统直接改数据库），才能接上标准的 `retry` 端点继续推进——但这条恢复路径本身也暴露了：**"这个节点看着卡住了，强制判失败以便恢复"这个动作现在没有任何 REST 入口**，只能改代码。
+2. **`graph-run.js` 的鉴权缺口**（见「六、已知遗留」第 3 条，已修复推送）。
+3. **规划/行动/反思没有统一的可追溯位置**。`org-coder` 的四段式阶段流转（RESEARCH→PLAN→EXECUTE→VERIFY）靠调 `bin/lemon.js task transition`，打到 `agent-chat.js` 的 `/task/transition` 端点——这个端点靠自己的 `sessions` Map 找"当前活跃会话"，但 `org-coder` 作为 work graph 节点跑的时候走的是 `graph-engine.js` → `AgentManager` → `session-pool.js`，是 CLAUDE.md 里早就记录过的"两个互不相干的会话池"那个坑的又一个受害者：阶段流转的业务逻辑（P0 审批拦截、OKR 子状态更新）在这条路径上**静默跳过**，`_plan.md` 这类中间产物既不进 `graph_files` 契约（这个是刻意的——validator 判定不该依赖"coder 计划写得像不像样"），也不进任何跨节点共享的轨迹，人类/`ceo` 事后想知道"这一步当时怎么想的"，只能去读原始的 agent transcript。
+
+这三条已经拆成具体的开发计划：[42-org-work-graph-reliability-followups.md](./42-org-work-graph-reliability-followups.md)。
+
+### 7.2 过程方法上的教训
+
+1. **三个并行 fork 分工做 P1-P5 这个模式本身是对的**——文件边界分得干净，`git diff` 核实过没有意外重叠，最后能精确按 hunk（不是整文件）拆成三个独立 commit。值得作为以后类似规模改动的默认工作方式。
+2. **"全部测试通过"不能替代真实跑一遍**——见上，这是本次复盘最核心的教训，直接决定了 41 号文档 Phase 1-2 优先做"让已经在跑的东西更可靠"而不是急着加新功能。
+3. **"这一步做完了"的判据容易只验证了子集**——`graph-run.js` 的鉴权缺口就是典型：地基 0 当时的验证只覆盖了 `company.js`，`ceo` 实际需要触达的控制面横跨两个路由文件。以后给 agent 开权限类的工作，落地前要先列一份"这个角色实际会调哪些端点"的清单，逐条核对，不能默认"改了一个入口就等于都改了"。
+4. **重启共享的开发服务器要谨慎**——为了让代码改动生效重启了一次服务器，没意识到这会杀掉正在跑的真实 Claude CLI 子进程，浪费了一整轮真实 LLM 调用（真金白银）。以后类似场景应该先确认有没有 in-flight 的真实执行，能等就等它到一个安全点再重启。
+5. **"为什么不能自动恢复"这类追问是复盘里最值钱的部分**——第一反应往往是"手动修一下继续跑"，是持续追问"这本该由谁负责、为什么没发生"才把表面的一次性意外，看清楚成系统性盲区（僵尸节点检测缺失）。这次几个最高价值的发现，都来自这种不满足于表面解释、继续往下问一层的模式，值得作为以后排查问题的默认姿势，不只是这一次的运气。
 # 40-agent-chat-streaming-interrupt. Agent Chat 打字机平滑 + 打断-排队 + 串台加固
 > **日期**: 2026-08-30
-> **状态**: 📝 需求文档，讨论中，尚未实现
+> **状态**: ✅ 已实现（commit `4d23f50`，2026-08-30）。三个方案全部落地：后端按字符数切片 +
+> 前端 `createTypewriterQueue` 匀速吐出（打字机平滑）；`stop` 端点改轮询确认
+> `agentChatLocks` 真正释放后返回 `cleaned`，前端据此直接发送或走强制发送兜底，执行中解锁
+> 输入框（打断-排队）；`handleEvent` 分发逻辑抽成不依赖组件实例的纯函数
+> （`agentChatEvents.js`），补上 `9b1c3f1` 那条不变式的回归测试（串台加固）。已用真实
+> Claude CLI 会话（非 mock）在浏览器里验证打字机效果与打断并发送。实现过程中顺手修了一个
+> 真实并发漏洞：同一 `agentId` + 同一 `convId` 的并发请求此前完全没有闸门。本文档不再更新，
+> 仅存档设计过程，实现细节以代码为准。
 > **触发**: 用户反馈"前端刷新不及时、没有打字机效果"，怀疑要不要把传输层从 HTTP 换成 WebSocket
 > 来解决打字机效果、多 Agent/多聊天切换、执行中无法打断这几个问题。经排查现状代码 +
 > 对照 [hermes-webui](file:///Users/yibo/Documents/lemonAI/hermes-webui)、
+# 42. Org/Work Graph 可靠性收尾 —— 39 号文档真跑复盘的待办
+
+> **状态**：Phase 1-4 全部 ✅ 已实现（2026-08-30）。Phase 3 前端缺一次真实浏览器验证（见该节说明），其余无已知缺口。
+> **日期**：2026-08-30
+> **背景**：[39-boss-agent-task-supervision.md](./39-boss-agent-task-supervision.md) 的 P1-P5 落地后，用它做了一次真实端到端测试（建公司 → 下 goal → `ceo` 监督 → 真实跑出一个可玩的贪吃蛇游戏，Playwright 5/5 验证通过）。**1469 个单测全绿，这次真跑却测出至少 3 个单测完全没覆盖到的真问题**——这份文档是那次复盘沉淀下来的待办，按开工顺序分四个 phase。
+> **读者须知**：每个 phase 的现状描述都来自那次真实测试里实际撞到的场景，不是推测；具体文件/行号落地前按惯例重新核实。
+
+---
+
+## 一、为什么排这个顺序
+
+四个 phase 分两类：**Phase 1-2 是"让已经在跑的东西更可靠"**（不改变行为，只是补上恢复路径和验证），**Phase 3-4 是"补功能缺口"**（新增能力）。前者优先——真跑复盘里代价最大的坑（僵尸节点、鉴权漏挂）都是"东西本来能跑，只是卡住了没人能救"这一类，越早补上，后面几个 phase 开工时越不容易被同样的坑绊到。Phase 5（timeline 承接规划轨迹）单独放最后，因为它是结构性改动，需要先摸清 `org-coder` 之外还有哪些角色也在打那条断线的 `/task/transition`，工作量比其余四个 phase 加起来还大。
+
+```
+Phase 1：卡住恢复闭环（僵尸节点检测 + 强制判失败端点）——两个互补的口子一起补
+Phase 2：§四.4 闸门穿透性回归测试 —— 纯测试，零设计风险
+Phase 3：target_dir 的 API/UI 入口 —— 纯加法
+Phase 4：timeline.ndjson 承接 planning/reflection 轨迹 —— 结构性改动，排最后
+```
+
+---
+
+## 二、Phase 1：卡住恢复闭环 —— ✅ 已实现（2026-08-30）
+
+**落地结果**（与下面的设计一一对应，实现时没有偏离）：
+- 1a：`graph-engine.js` 新增 `sweepOrphanedRunningNodes(cutoffIso)`，复用 `routeFailure` 的 `infra_flake` 分支；`server/index.js` 在 `PROCESS_STARTED_AT`（模块顶层捕获的本次进程启动时刻）挂上开机一次性调用，排在其余「开机补一次全量扫描」钩子之前。测试：`server/tests/unit/graph-engine-orphan-sweep.test.js`（4 例：孤儿转 infra_flake 原地重跑、晚于 cutoff 的不受影响、连续判孤儿撞硬顶转 blocked、无孤儿时安静 no-op）。
+- 1b：`graph-engine.js` 新增 `forceFailNode(runId, nodeRunId, failReason='operator_intervention')`；`graph-run.js` 新增 `POST /:id/nodes/:nodeId/force-fail`，只接受 `status='running'`。测试：`server/tests/unit/graph-run-force-fail.test.js`（8 例：正常转 fail 并可被 retry 接上、自定义 failReason 透传、五种非 running 状态各返 400、节点不存在返 404）。
+- 全量测试 1483/1487，零回归（剩余 4 个是核实过的 pre-existing 失败）。
+
+---
+
+### 1a. 服务器重启的僵尸节点检测
+
+**现状（真跑撞到的）**：`graph_run_nodes.status='running'` 这一行，没有任何机制确认"背后真的还有个活的进程"。真实测试里为了让 `graph-run.js` 鉴权修复生效重启了一次服务器，正在跑 `org-planner-sdd` 的 Claude CLI 子进程被连带杀掉，但那一行的状态永远停在 `running`——不会自己变成 `blocked`，`ceo` 的两条唤醒路径（事件驱动 + 30 分钟兜底扫描）判据都是 `status='blocked'`，对这个状态完全不可见。
+
+查过现成的"重启后清理残留"机制：`server/index.js` 的 `resumeIncompleteTasks()` 只处理 ArenaSK 的 Skill 训练任务（`skill-task-manager`），跟 org/work graph 毫无关系；`shutdown()`（`SIGTERM`/`SIGINT` 处理）只关插件管理器，不碰 `graph_run_nodes`。两处都不覆盖这个场景。
+
+**设计**：启动时扫一遍 `graph_run_nodes`，`status='running'` 且 `updated_at`（或 `startedAt`）早于**本次进程启动时间**的行，判定为孤儿（整个进程树都被换过一轮，不可能有真实进程还在跑它）。判定后按 **`infra_flake` 语义**处理，不发明新状态——原地重跑逻辑本来就是为"基础设施打断，跟设计/实现对不对无关"这类场景设计的，服务器重启只是这个桶里更严重的一个成员。复用 `graph-engine.js` 已有的 `routeFailure` 里 `INFRA_FLAKE_REASON` 那条分支，不用另起一套判定/熔断逻辑。
+
+**落点**：`server/index.js` 启动流程（挂在 `resumeIncompleteTasks()`/`sweepStuckActiveGoals()` 同一批"开机补一次全量扫描"的地方，跟这些既有钩子形状一致），加一个 `sweepOrphanedRunningNodes()`；判定逻辑放 `graph-engine.js` 或 `work-graph-db.js`（参照 `infra_flake` 现有实现挂在哪个文件）。
+
+**验收**：新增测试——起一个 `status='running'`、`startedAt` 早于"当前进程启动时间"的节点，跑一次 `sweepOrphanedRunningNodes()`，断言它被转成 `infra_flake` 路径能处理的状态，且不影响 `startedAt` 晚于启动时间的正常运行节点。
+
+### 1b. "强制判失败以便恢复"的 REST 端点
+
+**现状**：`POST /:id/nodes/:nodeId/retry` 只接受 `status ∈ {fail, blocked}` 的节点。真实测试里遇到一个卡住的 `running` 节点，唯一的恢复手段是**直接写一段脚本调用 `graph-run-sse.transitionNode` 内部函数**，绕过了任何 REST 接口——这对人类操作者或 `ceo` 都不现实，两者都只能走 HTTP。
+
+**设计**：新增 `POST /api/graph-runs/:id/nodes/:nodeId/force-fail`，语义是"我确认这个节点已经不可能再自己完成了，把它判成 `fail`（`failReason` 可选，默认某个通用值如 `operator_intervention`），交给既有的 fail→retry/backward-edge 路径处理"。**只接受 `status='running'` 的节点**（`fail`/`blocked` 已经有 `retry` 端点了，不重复造轮子）；调用方是人类还是 `ceo` 不做区分，鉴权走已有的 `requireAuthOrInternal`（跟着 Phase 1a 一起补，`graph-run.js` 这次已经全部换过了）。1a 落地后，这个端点的日常触发频率应该会显著下降（大部分"卡住"场景 1a 已经自动兜底），但保留它作为人工/`ceo` 判断"这个不是重启造成的，就是卡了"时的手动出口。
+
+**验收**：新增测试——`running` 节点调 `force-fail` 转 `fail` 且可被 `retry` 端点接上；`fail`/`blocked`/`pending` 状态调用返回 400（沿用 `ensureStatus` 现成的错误形状）。
+
+---
+
+## 三、Phase 2：§四.4 闸门穿透性回归测试 —— ✅ 已实现（2026-08-30）
+
+**落地结果**：新建 `server/tests/unit/ceo-created-task-gates.test.js`，3 例全部走 `ceo` 实际会用的通路（`POST /tasks` 的 `draft:true` + `created_by:'ceo'` → `/enqueue`，不抄近道直接摆数据库行）：
+1. `max_parallel_tasks=1` 时坑已占满，`ceo` 建的第二条任务落 `queued`，不插队。
+2. 预算给 `total_agent_calls:0`，`engine.checkBudget()` 照样判耗尽，`created_by='ceo'` 不改变结果。
+3. `ceo` 建的两条 task 挂在同一个 goal 下，全部 `completed` 后 `goal-validation` 的 `validateGoal` 钩子只被调一次（用 `validation.setValidateGoal()` 注入假验收，照抄 `goal-task-acceptance.test.js` 的既有手法）。
+
+全量测试 1486/1490，零回归（剩余 4 个是核实过的 pre-existing 失败）。
+
+**过程小插曲**：驱动第二条 task 的 run 出队时，先试了直接调 `task-scheduler.tick()`——撞上一个跟这次改动无关的既有工具链毛刺（`require.cache` 手工失效对 vitest 的 CJS 模块图不完全生效，`task-scheduler.js` 惰性 `require` 的 `work-graph-db` 引用有时会绑定到清缓存之前的实例，触发 `graph-db.js` 的"测试进程别碰生产库"守卫）。绕开的办法是不依赖 `scheduleTick` 的 `setImmediate` 时序，坑空出来后直接调 `updateRunStatus(runB,'queued','ready')`——这条路径本来就是准入事务的真实实现，只是不经过调度器这层编排，测试意图（"闸门拦不拦得住"）不受影响。
+
+**现状**：39 号文档 §四.4 已拍板"`ceo` 全权自主 `enqueue`，但 `max_parallel_tasks`/`DEFAULT_TASK_BUDGET`/goal 级 `org-validator` 这几道闸门必须照样拦住它"，落地时没有补这条测试（§六"已知遗留"记过一笔）。理论上这几道闸门挂在数据层/调度器层，不认"谁创建的"，天然覆盖，但没有测试钉死就不能说"已确认"。
+
+**设计**：不涉及任何设计决策，纯粹是补测试。新增用例（大致形状，落地时按现有测试文件的辅助函数抄写法）：
+1. 把公司 `max_parallel_tasks` 设成 1，已有一条 task 占着坑，`ceo` 走 `draft`+`enqueue` 建第二条——断言它排队而不是插队执行。
+2. 把公司 `DEFAULT_TASK_BUDGET` 设小，`ceo` 建的任务跑到预算耗尽——断言按现有 `budget-exhausted` 路径 `blocked`，不会因为"是 agent 建的"就获得额外预算。
+3. `ceo` 建的多 task goal 全部 `completed` 后，断言 goal 级 `org-validator` 照样被调一次（不因创建者是 agent 而跳过收敛验收）。
+
+**落点**：新建 `server/tests/unit/ceo-created-task-gates.test.js`，或并入现有 `task-blocked-ceo-wake.test.js`（按当时哪个更顺手）。
+
+---
+
+## 四、Phase 3：`target_dir` 的 API/UI 入口 —— ✅ 已实现（2026-08-30）
+
+**落地结果**：
+- 后端复用了已存在的 `PUT /api/company/:companyId`（`companyService.update()`），没有新建端点——设计里"如果已存在就扩展"这条命中了。`update()` 新增 `target_dir`/`target_mode` 分支，校验直接调 `path-resolver.validateLinkedTarget`（39 号文档 P5 抽出来的共享函数，和 `graph-engine.js` 运行时校验同一份判据），校验失败抛出，路由层 `try/catch` 转 400；`target_dir` 传空字符串清空配置；不传 `target_mode` 时默认 `linked-existing`，与 `graph-engine.js` 的 `readCompanyTargetConfig` 同一口径。测试：`server/tests/unit/company-target-dir-config.test.js`（8 例：`linked-existing`/`linked-new` 各自成功路径、默认 mode、敏感路径黑名单、`linked-new` 非空目录、`linked-existing` 不存在、清空配置、公司不存在）。
+- 前端：`CompanyDashboard.vue` 的"概览"tab 加一张卡片（目标目录输入框 + 模式下拉 + 保存按钮），本地表单状态不直接双向绑定 `selectedCompany`（保存失败时不该让用户刚打的字被冲掉）。
+
+**验证方式的取舍**：`npm run web:build` 编译通过 + 后端测试直接打真实路由层（不 mock service）。**没有做真实浏览器点击验证**——当时服务器上有其它并行会话真实在跑的 agent 进程（`ps` 能看到 3 个 `claude` 子进程），而重启服务器才能让后端改动生效，42 号文档 §二 已经记过一次"重启服务器杀掉别人真实进程"的教训，这次选择不重复。**这是一个已知的验证缺口，不是"做完了"**，下次服务器有安全窗口（没有并行会话在跑真实进程）时应该补一次真实点击验证。
+
+---
+
+**现状**：P5 落地的是"配了 `company.json.target_dir` 就生效"这一半，"人怎么把这两个字段填进去"这一半没做——真实测试里是手工编辑公司态目录下的 JSON 文件配的。
+
+**设计**：
+- **后端**：`PATCH /api/company/:companyId`（如果这个端点已存在就扩展，不存在就新建）接受 `target_dir`/`target_mode`，写回 `company.json`。校验复用 `path-resolver.js` 的 `validateLinkedTarget`（39 号文档 P5 已经抽出来的共享校验函数），配置阶段就能提前报错（不用等到第一次 `ensureProjectRoot` 才发现路径不对）。
+- **前端**：公司设置页面（或 `TaskBoard.vue`/`GraphConsole.vue` 附近，具体挂哪个页面待定）加一个表单，填目录路径 + 选 `linked-new`/`linked-existing`。
+
+**验收**：新增测试覆盖 `PATCH` 端点的校验分支（合法路径写入成功、`isSensitivePath` 命中黑名单拒绝、`linked-new` 目录非空拒绝）；前端至少过一次真实点击验证表单能提交成功。
+
+---
+
+## 五、Phase 4：`timeline.ndjson` 承接 planning/reflection 轨迹 —— ✅ 已实现（2026-08-30）
+
+**调研结论（落地前按设计要求先做的那一步）**：`grep` 全仓库 `system/agents/*/agent.md`，引用 `task transition` 的有 9 个真实角色（`_base`、`code-planner`、`coder`、`org-coder`、`org-planner`、`org-writer`、`pricing-api-integrator`、`unit-tester`、`workgraph-planning`，另有几个 `zz-*` 测试夹具不算）。**`_base` 在列**——这是所有新建 agent 复制的骨架模板，意味着这条能力管的不是几个角色的特例，是整个"多阶段流转"这一类角色的通用约定，往后任何继承 `_base` 的新角色自动适用。
+
+**关键发现，决定了整个实现方式**：`AgentManager.callAgent()` 的 `metadata`（含 `taskId`/`nodeRunId`/`rootRunId`）**只进服务端日志和 hook，agent 读不到**（代码原文注释）。但 agent 的节点私有产物目录本来就以 `data/companies/{cid}/runs/{rootRunId}/nodes/{nodeRunId}/` 这个形状写进它的提示词（`describeArtifactContract`），而 `--artifact` 参数本来就是这个目录下的文件路径——**两个 ID 已经现成地编码在调用方唯一知道、唯一会传的那个参数里**，不需要给 `AgentManager`/子进程塞任何新的环境变量，也不需要改一个字的 agent.md 提示词。
+
+**实现**（与设计里"两种做法二选一"对应：选的是**不改 `bin/lemon.js` 的 CLI 签名、不碰 `agent-chat.js`**这条更保守的路）：
+- `bin/lemon.js` 的 `task transition` 命令保持原有对 `/agent/:agentId/task/transition`（legacy）的调用完全不变，额外 best-effort 打一次新端点 `POST /api/graph-runs/phase-note`（body 只传 `artifact`/`phase`/`agentId`），失败静默吞掉，不影响命令本身的返回值/退出码。
+- 新端点从 `artifact` 路径正则解出 `rootRunId`/`nodeRunId`，校验 `rootRunId` 对应真实存在的 run（不存在就是 legacy 会话式调用的路径形状，安静返回 `not-a-graph-artifact`，不是错误），校验通过后调 `graph-run-sse.emitEvent()` 追加一条 `kind:'agent.phase'` 的 timeline 记录，`ref` 是 `nodeRunId`。
+- **`agent-chat.js` 完全没有改动**——这次特意避开了它：落地当天这个文件正被另一个并行会话实时编辑（`git status` 显示未提交修改），去碰一个正在被别人改的共享文件风险太高，改成把新能力放进这次 Phase 1-3 已经在用的 `graph-run.js`，物理上不产生交集。
+- **"不改的部分"边界确认成立**：新端点只调 `emitEvent`（纯追加 timeline，`apply` 传 `null`），不碰 `graph_run_nodes`/`graph_runs` 任何一行——测试里断言了这一点（节点状态在调用前后不变）。
+- **设计里 open 的第三个问题（P0 拦截/OKR 更新怎么处理）就此关闭**：答案是"完全不动"——这两段逻辑挂在 legacy `/task/transition` 里，图执行场景下（`sessions` Map 找不到会话）本来就从没触发过，这次也没打算让它们触发；新端点是完全独立的第二条路径，不是对旧端点的迁移或替换。
+
+**测试**：`server/tests/unit/graph-run-phase-note.test.js`（4 例：合法节点产物路径写进 timeline 且节点状态不受影响、路径形状不对时安静跳过、路径形状对但 run 不存在时安静跳过、没传 artifact 时报 `no-artifact`）。全量测试 1503/1506，零回归（剩余 3 个失败全部来自另一个并行会话正在进行中、还没提交的工作）。
+
+**现状（真跑撞到的，这是四个 phase 里最大的一个）**：`org-coder` 的四段式（RESEARCH→PLAN→EXECUTE→VERIFY）流转靠调 `bin/lemon.js task transition`，打到 `agent-chat.js` 的 `/task/transition` 端点——这个端点靠自己的 `sessions` Map 找"当前活跃会话"，但 `org-coder` 作为 work graph 节点跑的时候走的是 `graph-engine.js` → `AgentManager` → `session-pool.js`，是 CLAUDE.md 里早就记录过的"两个互不相干的会话池"那个坑的又一个受害者。结果：`org-coder` 在 work graph 里调这条流转指令时，`sessions.entries()` 根本找不到它的会话，阶段流转的业务逻辑（P0 审批拦截、OKR 子状态更新）**静默跳过**；它的中间产物（`_research.md`/`_plan.md`/`_lessons.md`）不进 `graph_files` 契约（这个是刻意的，见下"不改的部分"），但也**不进任何跨节点/跨角色共享的轨迹**，人类或 `ceo` 事后想搞清楚"这一步当时是怎么想的"，只能去读原始的 agent 会话 transcript（`GET /:id/nodes/:nodeRunId/transcript`），没有结构化的入口。
+
+**不改的部分（上一轮已经讨论定案，写在这里防止实现时跑偏）**：
+- `_plan.md` 这类中间产物**不进 `needs`/`produces` 契约**，`org-validator` 判定依据仍然只认 `acceptance.md` + `artifact`/`log`。理由：validator 判定"代码对不对"，不该依赖"coder 计划写得像不像样"，这条边界一旦模糊，两个坏结果都会发生——coder 学会把计划写漂亮而不是把代码写对；`graph_files` 的契约面失控（这个仓库反复栽在"两套体系不统一"上）。
+- 本 phase 只解决**可见性**（人类/`ceo` 事后能不能追溯），不解决**契约**（下游节点该不该依赖）——这是两件事，上一轮讨论已经拆开过。
+
+**设计**（需要先做的调研，落地前必做）：
+1. **调研范围**：`org-coder` 是这次撞到的一个，不代表只有它——扫一遍 `system/agents/*/agent.md` 里还有哪些角色的提示词也在调 `bin/lemon.js task transition`，把范围摸清楚再动手，不要只按 `org-coder` 这一个样本改。
+2. **迁移方向**：把"阶段流转"这个动作，从打 `agent-chat.js` 的 `/task/transition`（legacy，不认 graph run），改成写一条 `timelineNote()`（`graph-engine.js` 已有机制，per-run、append-only、永不改已写行），带上 `phase`（research/plan/execute/verify 或角色自定义的阶段名）+ `artifact` 路径。**具体是改 `bin/lemon.js task transition` 这条命令本身去打新端点，还是给它接一条新命令**，两种做法都要过一遍现有 agent 提示词的改动成本再定——这些提示词文件散在几十个 `agent.md` 里，改一条命令的调用方式等于牵动所有引用它的本体。
+3. **P0 审批拦截 / OKR 子状态更新这两块旧逻辑怎么处理**：`/task/transition` 里现在还挂着 P0 任务拦截、OKR 子状态更新这两段业务逻辑——这两者本身是不是还需要（尤其 OKR 那段，跟 P3C 的新 goal/task 模型是不是还有效对应），需要单独判断，不能假设"迁移流转机制"就等于"这两段逻辑原样照抄"。
+
+**验收**（待设计细化后补全，这里先占位）：至少要有一条测试证明——`org-coder`（或调研出的任意一个角色）在 work graph 里完成一次阶段流转后，`timeline.ndjson` 里能查到对应的 `phase`+`artifact` 记录，且这条记录不影响 `graph_files`/`needs`/`produces` 的既有行为（回归测试守住"不改的部分"那条边界）。
+
+---
+
+## 六、开放问题
+
+1. Phase 1a 的孤儿判定条件（`startedAt` 早于进程启动时间）在多进程/多副本部署下是否还成立？现在是单进程部署，这条先按当前架构写，多副本场景不在这次范围内。
+2. Phase 3 的 `PATCH /api/company/:companyId` 端点如果本来就不存在，是新建这一个端点，还是这次顺手看一下公司配置类的改动有没有更合适的既有入口——落地前查一遍 `company.js` 现状再定，不在这里预判。
+3. Phase 4 的调研如果发现有 10+ 个角色都在用旧的 `/task/transition`，工作量会明显超出"一个 phase"的量级，届时可能需要再拆细——先按"调研完再评估"处理，不在这里预先估工作量。
@@ -21,7 +21,7 @@
 ### 1.1 dream 机制
 **状态（2026-08-20 更新）**：设计已成文并已实现，见
-[29-dream-design.md](./29-dream-design.md)。四条取舍（去敏判据 / 沉淀落点 / 触发时机 /
+[29-dream-design.md](../../done/system-design/29-dream-design.md)。四条取舍（去敏判据 / 沉淀落点 / 触发时机 /
 质量评估）均已拍板，五步推进顺序 + 定时挂载 + 定义文件写入均已落地，
 `innovator-evolver` 上真 CLI 跑通一次（40 条原料 → 4 条抽象经验，8 条引用全部核对回原文）。
@@ -15,7 +15,7 @@
 > （零 `retryNode` 调用），最终 planner 子图收敛到 `completed`。**修复确认生效，有真实证据**。
 > 同一次验证顺带在 `org-coder` 子图撞见一个**独立的新 bug**（`inboundContracts` 未按 `role`
 > 过滤，把 `produces` 声明误当 `needs`，导致 `missing_required_input` 假阳性），与本文档无关，
-> 已记录在 [33-needs-gate-role-filter-bug.md](./33-needs-gate-role-filter-bug.md)。
+> 已记录在 [33-needs-gate-role-filter-bug.md](../../done/system-design/33-needs-gate-role-filter-bug.md)。
 ---
@@ -17,7 +17,7 @@
 > 前置闸门统一验证严谨度，留给下次设计。
 > **触发**: `e2e-demo` 公司真实回归任务 `T-mt2r6fz0-125b`（goal `G-mt2r62ia-73af`，
 > root run `run_0e9074815130`）——[31 号文档](./31-work-graph-fail-fallback-coverage.md)
-> 兜底边修复 + [33 号文档](./33-needs-gate-role-filter-bug.md) 契约修复之后，把这条任务
+> 兜底边修复 + [33 号文档](../../done/system-design/33-needs-gate-role-filter-bug.md) 契约修复之后，把这条任务
 > 真正推到 `completed`，回头查"最终产出在哪"时发现的
 ---
+# 43 · Goal 分解粒度：规划产出该长成文件，还是长成 task/subtask 树
+
+> **状态**: 📝 需求 + 现状调研，尚未设计、未实现
+> **日期**: 2026-08-31
+> **触发场景**: snakegame-co 公司，goal `G-mtfh23mu-bd63`（"HTML 贪吃蛇游戏"），task `T-mtfh2kuf-7c31`。
+> 该任务当天被 `missing_required_input` 死循环卡住（根因与修复见 [33 号文档](../../done/system-design/33-needs-gate-role-filter-bug.md) 的复发一例，
+> `tools.md` 范例与 `work-graph-db.js` 引擎层已同日修复），排查过程中用户提出了本篇的需求。
+> **格式对齐** `27-requirement.md`：原话照搬 + 结构化复述，现状调研另起一节。
+
+---
+
+## 原始需求（用户原话，一字不改）
+
+> 就这个任务，我讲讲我理想的状态，应该是 org planner 完成了brd prd sdd 后，在 task 任务看板应该能看到规划出来的 todo list 作为这个 html 贪吃蛇游戏 goal 的 task 和 sub task 展示出来，然后每一个 org coder 都是按照这个 task todo list 在逐个的开发完成，然后 org validator 应该是针对 task todo list 在逐个验收，这个现在是不是实现不了？
+
+---
+
+## 结构化复述
+
+用户设想的理想流程，拆成四步：
+
+1. **规划阶段**：org-planner 完成 brd/prd/sdd 之后，不只是产出文档，还应该把这份规划**分解成一份 todo 清单**。
+2. **展示阶段**：这份 todo 清单应该以 **task 和 sub-task** 的形态出现在任务看板上，挂在"HTML 贪吃蛇游戏"这个 goal 下面（例子：方向键控制、吃食物加分、碰撞结束、重新开始——即当前 `acceptance.json` 里的 A.1-A.5）。
+3. **开发阶段**：org-coder 不是一次性对着一大段任务描述写完整个交付物，而是**按 todo 清单逐条**开发。
+4. **验收阶段**：org-validator 也不是一次性给整个交付物判总分，而是**按 todo 清单逐条**验收。
+
+用户明确问：**现状是不是做不到这个？**
+
+---
+
+## 现状调研结论（本次会话核实，非最终设计）
+
+结论：**部分可以，"做不到"的那部分是当前 agent 设计上的主动选择，不是漏做的功能**。四层现状分别是：
+
+### 1. `tasks.parent_task_id`——字段在，但服务的是另一条流水线
+
+`tasks` 表（`server/services/work-graph-db.js`）确实有 `parent_task_id` 列，也确实有代码在读写它——但那是 **LemonBoss Agent Chat 的人工派单流程**（`server/routes/agent-chat.js` + `task-service.js` 建任务树），跟本篇讨论的 goal → task → org-graph/work-graph 这条流水线是两套独立机制。
+
+本篇关心的这条流水线里，真正负责"从 goal 生成 task 行"的函数是 `work-graph-db.js` 的 `createTask({goalId, companyId, seq, title, description, executionMode, dependsOn, priority, budgetJson, reportTo, createdBy})`——**这个函数签名里根本没有 `parentTaskId` 参数**。也就是说，子任务对这条流水线而言是**结构性够不着**，不是"字段有、没人填"。
+
+### 2. task-planning 阶段本身有能力拆多任务，但拆分依据不是"检查项"
+
+真正把 goal 拆成 task 的阶段是 `task-planning`（`server/services/task-planning.js` + `system/agents/task-planning/`，落库调用点在 `server/routes/company.js:1577 insertTasksForGoal`）。这一步**确实能一次拆出多条 task**（已有测试验证过 2 条以上的场景）。
+
+snakegame-co 这次只拆出 1 条 task，不是能力限制，是 **`system/agents/task-planning/agent.md` 第二步的明确设计判断**：拆分依据是"交付物/验收边界"，**不是"工作阶段"**。原文点名"①调研②设计③开发④测试⑤上线"这种按阶段拆是"最常见也最致命的错法"。按这份人设的判断，方向键/得分/碰撞/重开这四条，是**同一个交付物的验收清单**（正是最终 `acceptance.json` 里一起被同一份 Playwright 脚本验证的 A.1-A.5），不是四个可以独立排期验收的 task——agent 设计上就会拒绝把它们拆成四条 task。该 agent 人设还硬顶单 goal ≤ 8 条 task，整体偏"合并"不偏"细分"。
+
+### 3. org-planner 没有"建任务"这个工具
+
+org-planner 在跑的时候（`system/agents/org-planner/tools.md`）能力边界是：调研 → 阶段流转 → 写 brd/prd/sdd/acceptance.md 这几份**文件** → 向 CEO 汇报。**没有任何一个工具允许它创建新的 task 行**（org-coder / org-validator 同样没有）。规划阶段的产出，结构上只能落成文档，附着在它所属的那一条已经固定的 task 上，没法在跑的过程中反过来生出新的、可独立调度的子任务。
+
+### 4. 看板 UI 没有树形渲染
+
+`web/src/views/TaskBoard.vue`、`web/src/components/graph-console/GoalTaskPane.vue` 目前都没有父子任务的渲染逻辑——即便前三层都打通、数据库里真的出现了带 `parentTaskId` 的行，看板现在也画不出树形结构，只会当成平铺列表处理（或者干脆不显示子任务）。
+
+---
+
+## 设计决策（2026-08-31 定案，三选一各选完）
+
+| 问题 | 决定 | 理由 |
+|------|------|------|
+| 子任务挂在哪套机制上 | **goal → task 流水线里新建一套独立父子机制**（不复用 Agent Chat 的 `parent_task_id`） | 后者是为「人工派单、多轮对话」设计的语义，跟 org-graph 自动执行的生命周期（谁创建、何时终结）对不上，硬凑容易埋雷 |
+| 子任务要不要独立开发+验收循环 | **先只拆验收，开发仍整体完成**——org-coder 一次性写完整个交付物，验收侧改成按子任务（验收条目）逐条判，而不是给总分 | 改动小得多，且先解决「验收颗粒度太粗」这个更痛的点；独立开发循环（每个子任务各起一个 work-graph run）留作后续再评估 |
+| 什么粒度的 goal 该拆 | **由 task-planning agent 自己判断**，不写死规则 | 跟它现在「要不要拆多个 task」的判断逻辑同源，交给同一套"交付物/验收边界"标准，不额外发明一套阈值规则 |
+
+由这三条决定组合出的实现方向：**task-planning 判断"值不值得走细粒度验收"是一个粗粒度的开关，真正的子任务清单在 org-planner 写完 acceptance.json 之后才生成**——因为验收条目本身就是规划阶段的产出，task-planning 跑的时候 brd/prd/sdd 还不存在，没法预先知道要拆成哪几条。这意味着"判断要不要拆"和"生成子任务"是两个时间点、两个步骤：
+
+1. **task-planning（goal 创建时）**：新增一个判断维度——这个 task 的验收后续要不要走"逐条子任务"模式，写一个标记（例如 task 行上加 `acceptance_mode: 'holistic' | 'itemized'`，或等价字段），不生成任何子任务行。
+2. **org-planner 收尾（acceptance 产物写完之后，org-graph 流程内新增一步）**：如果上一步标记是 `itemized`，读验收条目，逐条 `createTask({parentTaskId, ...})` 生成子任务行，挂在同一个 goal 下。
+3. **`coder-validator`（work-graph 内既有节点，就是本 session 全程调试的那个 agent）**：判断逻辑从"给整个 task 一个总分"改成"遍历子任务逐条判"，每条子任务各自 success/fail，父任务的终态由子任务汇总（全 success → success，否则看具体子任务）。
+4. **看板 UI**：`TaskBoard.vue` / `GoalTaskPane.vue` 加父子任务树形渲染，只读展示，不涉及交互改动。
+
+## 实现细节决策（2026-08-31 定案）
+
+| 问题 | 决定 | 理由 |
+|------|------|------|
+| 标记字段怎么设计 | **`tasks` 表加 `acceptance_mode` 字段**，取值 `'holistic' \| 'itemized'`，命名风格对齐既有 `execution_mode`（manual/auto），由 task-planning 生成 task 行时一并写入 | 不额外发明隐式推导规则，创建时就能在库里直接看到这条 task 走哪种验收模式，调试/展示都直观 |
+| 部分子任务失败时父任务终态 | **必须全部子任务 success，父任务才 success**；任一子任务 fail → 父任务 fail | 跟当前"一次性给总分、不合格就是不合格"的严谨程度保持一致，也呼应 [34 号文档](./34-validator-scored-without-real-deliverable.md) 关于验证不能打折的教训；`optional` 子验收项留作后续需要时再加，先不预留这层复杂度 |
+| 子任务要不要复用现成的状态语义 | **复用**（pending/ready/running/success/fail/blocked 这套状态词汇） | 直接复用能白拿状态流转、看板渲染的既有约定，不用另起一套并行的状态语义 |
+
+> **落地时的订正**（技术设计阶段核实后发现）：上一行"复用现成状态机"字面上写的是 `graph_run_nodes` 那套，但子任务本质是 `tasks` 表的行（带 `parent_task_id`），不是某个 work-graph run 内部的节点实例——它没有自己独立的 run。所以真正落地时复用的是 **`tasks.status` 这套既有枚举**（`queued/running/blocked/completed/failed/cancelled`），只是**沿用同一套状态词汇的精神**（有限状态、终态幂等、`settleNode`/`settleTaskFromRun` 那一类条件更新闸门），不是字面上去 `graph_run_nodes` 表插行。见下方技术实现计划 Phase 3。
+
+> **另一处订正**：上面第 3 步原来写的是"org-validator"，但技术设计阶段查证后发现 **`org-validator` 和 `coder-validator` 是两个不同目录、不同职责的独立 agent**——`org-validator` 是 org-graph 顶层节点（整体验收），`coder-validator` 是 org-coder 这一层 work-graph 内部的节点（就是本 session 全程调试的那个，`work-validator/v1` 输出格式）。真正产出逐项验收证据、需要按子任务逐条判的是 **`coder-validator`**，已在上面订正。
+
+至此，43 号文档的方案层面已经全部定案。下面是核实过具体代码形态后的技术实现计划。
+
+---
+
+## 技术实现计划（2026-08-31，代码形态已核实，未开工）
+
+### Phase 0 · Schema
+
+- `tasks` 表加 `acceptance_mode` 列，`CHECK (acceptance_mode IN ('holistic','itemized')) DEFAULT 'holistic'`——语法上照抄 `execution_mode` 已有的 CHECK 写法（`work-graph-db.js:533`），迁移方式照抄 `parent_task_id` 自己当年落地时用的 `hasColumn` 判断 + `ALTER TABLE` 兜底那一段（`work-graph-db.js:626-627`），同一个文件里已有两份现成模板可抄，不用发明新的迁移写法。
+- `createTask({...})` 签名（`work-graph-db.js:1861-1873`）加 `parentTaskId`、`acceptanceMode` 两个参数，INSERT 列表（`work-graph-db.js:1902-1907`）跟着加。`parent_task_id` 列本身早就存在（是 Agent Chat 那条派单流程在用），这里只是**第一次让 goal→task 流水线自己也写这一列**——顺手确认一下现有读它的 `task-service.js:66-81` 那段任务树构建逻辑，会不会因为多了一类新来源的父子行而产生非预期的合并/展示（大概率不会，因为按 `company_id`/`goalId` 天然分域，但落地前应该跑一次它的既有测试）。
+- 守卫测试：图流水线创建的顶层 task（`insertTasksForGoal` 路径）`parent_task_id` 仍是 `NULL`；子任务的 `parent_task_id` 非空且指向父任务、`acceptance_mode` 恒为 `'holistic'`（子任务不允许再递归拆一层）。
+
+### Phase 1 · task-planning 判断 `acceptance_mode`
+
+`task-planning` 目前是纯"回复 JSON 代码块"模式（`system/agents/task-planning/tools.md:5`），产出 4 字段 `[{seq, title, description, depends_on}]`（`agent.md:120-142`），而且**硬规则 5**（`agent.md:10`）明确禁止 LLM 多写字段——"服务端生成，你写了会被当成脏字段打回"，`mode`/`priority`/`budget` 这些运营字段都是 `company.js:1396-1429 buildTaskPlans()` 在服务端按 goal 级默认值统一注入的（`company.js:1421-1423`），不是 LLM 决定的。
+
+`acceptance_mode` 要不要拆本质上是一次语义判断（跟"要不要拆多个 task"用的是同一种判断力，这正是当初选"由 agent 自己判断、不写死规则"的理由），**没法**像 `mode`/`priority`/`budget` 那样简单地由服务端注入默认值——所以这里必须**显式在硬规则 5 上开一个例外**：
+
+- `agent.md` 的 JSON schema 从 4 字段扩到 5 字段，加 `acceptance_mode`，并在硬规则 5 旁边补一句明确的例外说明（为什么这一个字段跟其它运营字段不同，避免以后被"这些字段都是服务端生成"的惯例带偏、被误当脏字段清掉）。
+- `buildTaskPlans()`（`company.js:1396-1429`）改成**透传** LLM 给的 `acceptance_mode`，而不是像其它字段那样用服务端默认值覆盖；LLM 没给这个字段时兜底 `'holistic'`（保守，不引入新行为，除非规划阶段明确判断要拆）。
+
+### Phase 2 · org-planner 收尾生成子任务（⚠️ 有一个真实风险要先处理）
+
+org-planner 的 4 阶段 FSM（`system/agents/org-planner/tools.md:19-23`，`node bin/lemon.js task transition --phase {plan|execute|verify}`）产出的验收清单叫 **`acceptance.md`**（不是 `.json`）——Markdown 表格 `| # | 验收项 | 判定方式 | pass 条件 |`（`tools.md:44-50`），一行一条验收项，是子任务清单最自然的数据源。这**不是**同名的 R-19-B `acceptance.json` 契约（`goal-contract.js:76` 定义的 `benchmark|test_data|test_script` 三段式，由另外三个独立的 `goal-benchmark`/`goal-test-data`/`goal-test-script` 节点产出）——两者名字像、来源和用途完全不同，写代码时一定要认清楚读的是哪一份。
+
+**⚠️ 已知风险，动工前必须先确认**：本 session 全程调试的 snakegame-co 这条真实任务，`acceptance.md` 和 `acceptance.json` **实际上都没有被真正当成验收依据用**——`coder-validator` 最终判定用的是自己临时写的一套 Playwright 测试（A.1-A.5），`goal-contract.js` 那份 `acceptance.json` 甚至报了 `note:"goal-contract.js cannot parse index.html as JSON...treat as no task-level contract"`，被当场判定"这个任务没有 task 级契约"直接跳过。如果子任务清单要建在 `acceptance.md` 之上，得先跑一次真实回归确认它确实会被稳定产出、格式跟文档描述一致——不能假设它已经可靠，这跟 33 号文档"建立在一个从来没人真正产出过的 `kind='log'` 之上"是同一类风险，值得先花一次真跑单独验证，而不是直接在上面盖楼。
+
+如果验证通过，新增步骤：org-planner 的 `verify` 阶段落盘 `acceptance.md` 之后，插入一步"物化子任务"——仅当父任务 `acceptance_mode==='itemized'` 时，逐行读表格，为每一条验收项调用 `createTask({parentTaskId: 当前 task.id, acceptanceMode:'holistic', title: 该行"验收项"文本, description: 该行"判定方式"+"pass 条件", ...})`。
+
+两个待确认的实现细节：
+
+- 这一步该是给 org-planner 加一个新工具（让它自己触发"物化子任务"），还是挂在服务端某个 hook 上（`verify` 阶段落盘后自动触发，agent 无感）？倾向后者——子任务生成是纯数据搬运，不需要占用一次 agent 调用去决定"要不要生成"（`acceptance_mode` 这个语义判断已经在 Phase 1 做完了），机械地转换 Markdown 表格到 task 行不需要 LLM 参与。
+- 本次调研**没能确认** org-planner"完成→进入 org-coder"具体由哪个信号触发（`verify` transition 本身，还是 `tools.md:59-65` 那个额外的 `task/report` 调用）——插入新步骤前必须先查清楚，避免插错时机打断现有的阶段流转。
+
+### Phase 3 · coder-validator 改成逐条判 + 回写子任务状态
+
+关键发现：`coder-validator` 现在产出的 `checks[]`/`verdict` 结构化 JSON（就是本 session 里 `attempt-2.json` 那种形状），**目前没有任何服务端代码解析它**——`graph-engine.js` 判定这个节点成功与否只看 executor 返回的顶层 `status` 字段，`checks[]` 纯粹是给人看的审计文本，`goal-contract.js` 走的是完全独立的另一条 CLI 路径（自己生成 `verdict_id`），跟 `coder-validator` 的输出没有关系。
+
+所以"逐条判"要真正影响子任务状态，**不能只是把 agent 提示词写得更细**——必须新增一个真实的工具调用：`coder-validator` 每判完一条验收项，调用一次新工具（例如 `report-subtask-result`），带上子任务 id + success/fail，服务端据此走一次 `tasks` 表的条件更新（复用 `settleTaskFromRun` 同款的"终态幂等闸门"思路：已经是终态的子任务不能被覆盖）。这跟本 repo 一贯的做法一致——状态改变走真实工具调用，不解析自由文本 JSON（`checks[]` 格式在 `org-validator`/`coder-validator`/`planner-validator`/`testdata-validator`/`benchmark-validator` 五个 validator 之间只是"约定俗成、没有强制"的 `work-validator/v1`，不是哪里都强制校验的 schema，解析它不安全）。
+
+父任务终态：全部子任务 `completed` → 父任务按现有 `settleNode` 逻辑判 success；任一子任务 `failed` → 父任务 fail（Phase 0 就已经决定）。
+
+### Phase 4 · 看板树形渲染
+
+- `web/src/components/FileNode.vue` 是现成的自递归 `<script setup>` 组件模板（`v-for="child in node.children"` + `depth*14+6` 缩进），照这个结构写一个 `TaskNode.vue`，不用发明新模式。
+- `GoalTaskPane.vue:78-131` 现在是纯平铺 `<ul class="tasks"><li v-for="t in g.tasks || []">`，改成先按 `parentTaskId` 把 `g.tasks` 分组建成树，再用 `TaskNode` 递归渲染。`TaskBoard.vue` 本身不用改——它是纯外壳，全权委托给 `GoalTaskPane.vue`（`TaskBoard.vue:23-32`）。
+- `taskView()`（`company.js:994-1031`，`GET /:companyId/goals?withTasks=1` 等多个路由共用的唯一整形函数）要把 `parent_task_id`、`acceptance_mode` 加进输出字段列表——目前两个字段都完全没有出现在响应里，包括未使用的形式都没有。
+
+### 建议的实施顺序
+
+**Phase 0 → 1 → 4 → 2 → 3。**
+
+Phase 4（看板渲染）提前到 Phase 2/3 之前：先用手工插入的测试数据验证树形展示对不对，把"看得见"和"能自动生成"两件事解耦，避免一次性大集成、出问题不知道是生成的问题还是展示的问题。
+
+Phase 2 排在 Phase 3 之前，且内部先做"acceptance.md 是否真的可靠"这次独立验证——这是唯一一个建在未经证实的既有产物之上的环节，值得单独花一次真跑确认，再决定要不要照原计划往下建。
@@ -18,6 +18,11 @@ const app = express();
 const server = http.createServer(app);
 const pluginManager = new PluginManager();
+// 42 号文档 Phase 1a：本次进程的启动时刻，早于它的 graph_run_nodes.status='running' 一律是
+// 上一个进程实例留下的孤儿（这个新进程刚起，不可能自己已经有节点在跑）。模块顶层捕获一次，
+// 不要在 sweepOrphanedRunningNodes 调用点现取——那样每次重试都会把截止线往后挪。
+const PROCESS_STARTED_AT = new Date().toISOString();
+
 // ─── 中间件 ───
 app.use(cors(config.cors));
 app.use(cookieParser());
@@ -160,6 +165,17 @@ async function start() {
             const taskSettle = require('./services/task-settle');
             taskSettle.resumePendingGoalValidations()
                 .catch(err => console.error('[Startup] 重推 goal 验收失败:', err.message));
+            // 42 号文档 Phase 1a：上一个进程实例被换代码重启杀掉时，正在跑的 graph_run_nodes
+            // 会留在 status='running'（背后进程已死，行本身不会自己变）——ceo 的两条唤醒路径都
+            // 只认 status='blocked'，对这个状态完全不可见。开机先清一遍，早于下面几个「补一次
+            // 全量扫描」的钩子，让被它们观察的下游（task/goal 是不是卡住了）看到的是清好的状态。
+            try {
+                const engine = require('./services/graph-engine');
+                const { scanned, swept } = engine.sweepOrphanedRunningNodes(PROCESS_STARTED_AT);
+                console.log(`[Startup] 🧟 孤儿 graph 节点清扫：扫到 ${scanned} 条，处理 ${swept.length} 条`);
+            } catch (err) {
+                console.error('[Startup] 孤儿 graph 节点清扫失败:', err.message);
+            }
             // T-mt622nil：上面那条只补「收敛钩子已经跑过、卡在验收/汇报半路」的。更前面那一步——
             // 钩子压根没被触发过（进程重启 / 异常吞掉 / 事件丢失）——task 早到终态但 goal 永远停在
             // active，只能靠人工 OKR 巡检才发现（e2e-demo 公司 G-mt2r62ia-73af 卡了 48 小时）。
@@ -1067,6 +1067,30 @@ function buildUploadContext(id, convId) {
   return contextBlock;
 }
+// 模型上下文预算 —— 现在跑的都是 1M 上下文的模型，历史记录分一半，剩下留给 system prompt / 工具产出 / 回复。
+// 换更小上下文的模型时改 AGENT_MODEL_CONTEXT_TOKENS 就行，不用改这段逻辑。
+const MODEL_CONTEXT_TOKENS = parseInt(process.env.AGENT_MODEL_CONTEXT_TOKENS || '1000000', 10);
+const HISTORY_TOKEN_BUDGET = Math.floor(MODEL_CONTEXT_TOKENS * 0.5);
+// ponytail: 4 字符≈1 token 的粗估算，不是真实分词器；预算掐得准不准全看这条，
+// 真出现估算偏差导致截断过早/过晚，再换成真实 tokenizer（如 tiktoken）计数
+const CHARS_PER_TOKEN = 4;
+function estimateTokens(text) {
+  return Math.ceil(text.length / CHARS_PER_TOKEN);
+}
+
+/** 按 token 预算从最新往最老收，超预算就把更老的历史丢掉（至少保留最近一条） */
+function truncateHistoryToBudget(history, budget) {
+  const kept = [];
+  let used = 0;
+  for (let i = history.length - 1; i >= 0; i--) {
+    const cost = estimateTokens(history[i].content);
+    if (kept.length > 0 && used + cost > budget) break;
+    used += cost;
+    kept.unshift(history[i]);
+  }
+  return kept;
+}
+
 function buildPrompt(agentDir, agentId, convId, userMessage, isNewSession) {
   // 注入上传文件上下文（按寻址名取，与上传端点的落点是同一份推导）
   const uploadContext = buildUploadContext(agentId, convId);
@@ -1086,12 +1110,11 @@ function buildPrompt(agentDir, agentId, convId, userMessage, isNewSession) {
     return `${systemPrompt}${cronInstructions}\n\n---\n\n## 用户消息\n\n${enrichedMessage}`;
   }
-  // 场景 C: 恢复上下文 — 注入历史摘要
-  const recentHistory = history.slice(-20);
-  const historyText = recentHistory.map(m => {
+  // 场景 C: 恢复上下文 — 按模型上下文动态算预算，装得下就整段注入，装不下从最早的开始丢
+  const boundedHistory = truncateHistoryToBudget(history, HISTORY_TOKEN_BUDGET);
+  const historyText = boundedHistory.map(m => {
     const role = m.role === 'user' ? 'Human' : 'Assistant';
-    const content = m.content.length > 500 ? m.content.slice(0, 500) + '...(截断)' : m.content;
-    return `${role}: ${content}`;
+    return `${role}: ${m.content}`;
   }).join('\n\n');
   return `${systemPrompt}${cronInstructions}\n\n---\n\n## 之前的对话历史（供你参考以保持上下文连贯）\n\n${historyText}\n\n---\n\n## 用户新消息\n\n${enrichedMessage}`;
@@ -2916,3 +2939,6 @@ module.exports.saveMeta = saveMeta;
 module.exports.appendHistory = appendHistory;
 module.exports.logMessage = logMessage;
 module.exports.flushLogBufferForConv = flushLogBufferForConv;
+module.exports.buildPrompt = buildPrompt;
+module.exports.truncateHistoryToBudget = truncateHistoryToBudget;
+module.exports.estimateTokens = estimateTokens;
@@ -191,8 +191,16 @@ router.get(&#39;/:companyId&#39;, (req, res) =&gt; {
 });
 // PUT /api/company/:companyId
+// 42 号文档 Phase 3：body 里带 target_dir 时，companyService.update() 会做真实的路径校验
+// （复用 path-resolver.validateLinkedTarget，敏感路径黑名单 / linked-new 非空 / linked-existing
+// 不存在等都在这一步拦，不用等到真正跑任务分配项目根才发现），校验失败抛出，这里接住转 400。
 router.put('/:companyId', (req, res) => {
-  const company = companyService.update(req.params.companyId, req.body);
+  let company;
+  try {
+    company = companyService.update(req.params.companyId, req.body);
+  } catch (err) {
+    return res.status(400).json({ error: err.message });
+  }
   if (!company) return res.status(404).json({ error: '公司不存在' });
   res.json({ success: true, company });
 });
@@ -1014,6 +1022,7 @@ function taskView(t, progress = null, positions = null) {
     queuePosition: (positions && positions.get(t.id)) || null,
     blockedReason: t.blocked_reason,
     reportTo: t.report_to,
+    assigneeAgentId: t.assignee_agent_id || null,
     createdAt: t.created_at,
     queuedAt: t.queued_at,
     startedAt: t.started_at,
 /**
- * dream —— 经验汇流的 REST 入口（[29-DREAM](../../docs/todo/system-design/29-dream-design.md)）。
+ * dream —— 经验汇流的 REST 入口（[29-DREAM](../../docs/done/system-design/29-dream-design.md)）。
  *
  * 只做一件事：把 `dream-service.js` 已有的能力（`dreamOnce` / `dreamSweep` /
  * `auditDistilled` / `definitionWritability`）从「只能靠脚本或定时器触发」
@@ -377,6 +377,81 @@ router.post(&#39;/:id/nodes/:nodeId/retry&#39;, h((req, res) =&gt; {
 }));
 /**
+ * POST /api/graph-runs/:id/nodes/:nodeId/force-fail — 「强制判失败」（42 号文档 Phase 1b）
+ * body: { failReason?: string }（默认 'operator_intervention'，刻意不是 'infra_flake'——
+ *        那个值有特殊语义：原地重跑、不烧计数，人工判定不该被误当成一次性抖动）
+ * 可用条件：节点 status = 'running'
+ *
+ * `retry` 端点管不到 running 的节点（那是它自己的既有约定，不是这次要改的）——这个端点补的
+ * 正是那个缺口：人类或 ceo 判断"这个节点已经不可能再自己完成了"时的手动出口。转 fail 之后
+ * 交给引擎既有的失败路由（selectFailEdge/handleBackwardEdge），不发明新路径。
+ */
+router.post('/:id/nodes/:nodeId/force-fail', h((req, res) => {
+  const run = loadRun(req, res);
+  if (!run) return;
+
+  const { nodeId } = req.params;
+  let nodeRun = getRunNode(nodeId);
+  if (!nodeRun || nodeRun.run_id !== run.id) nodeRun = getRunNodeByDefId(run.id, nodeId);
+  if (!nodeRun) {
+    return res.status(404).json({ error: `节点 ${nodeId} 不属于 run ${run.id}` });
+  }
+
+  if (nodeRun.status !== 'running') {
+    return res.status(400).json({
+      error: `「强制判失败」在节点 status='${nodeRun.status}' 下不可用，仅当节点 status = 'running' 时可用（fail/blocked 请用 retry 端点）`,
+      op: 'force-fail',
+      nodeStatus: nodeRun.status,
+      allowed: ['running'],
+    });
+  }
+
+  const { failReason } = req.body || {};
+  res.json(engine.forceFailNode(run.id, nodeRun.id, failReason || undefined));
+}));
+
+/**
+ * POST /api/graph-runs/phase-note — 42 号文档 Phase 4：planning/reflection 轨迹落进 timeline。
+ * body: { artifact: string, phase?: string, agentId?: string }
+ *
+ * `bin/lemon.js task transition` 在打 legacy 的 `/api/agent/:agentId/task/transition`
+ * 之外，额外（best-effort、不影响主流程）打这一个端点。它不需要 `:id`——调用方（跑在
+ * work graph 节点里的 agent）不知道自己的 runId，只知道自己刚写的 `--artifact` 绝对路径；
+ * 这个路径的形状（`.../runs/{rootRunId}/nodes/{nodeRunId}/...`）本身就带着两个 ID
+ * （节点私有产物目录的既有约定，见 `graph-engine.js` 的 `nodeArtifactDir`/`runRootDir`），
+ * 从路径里解出来就行，不用改任何 agent.md 的提示词、也不用改 `AgentManager` 往子进程塞
+ * 新的环境变量。
+ *
+ * 解不出来 / 解出来的 rootRunId 不对应真实存在的 run（legacy 会话式 agent 调用这条命令时
+ * 就是这样——它们的 `--artifact` 压根不是这个路径形状）：安静跳过，返回 `{ok:false,
+ * reason:'not-a-graph-artifact'}`，不是错误——这条端点存在的前提就是"大多数调用方都用不上它"。
+ *
+ * 只做**追加**：不碰 `graph_run_nodes`/`graph_runs` 任何一行，不影响 needs/produces 契约、
+ * 不影响 validator 的判定依据（39 号文档 §七.2 定案的边界——private 产物不能变成契约输入）。
+ */
+router.post('/phase-note', h((req, res) => {
+  const { artifact, phase, agentId } = req.body || {};
+  if (typeof artifact !== 'string' || !artifact) {
+    return res.json({ ok: false, reason: 'no-artifact' });
+  }
+
+  const m = artifact.match(/[\\/]runs[\\/]([^\\/]+)[\\/]nodes[\\/]([^\\/]+)[\\/]/);
+  if (!m) return res.json({ ok: false, reason: 'not-a-graph-artifact' });
+  const [, rootRunId, nodeRunId] = m;
+
+  if (!getRun(rootRunId)) return res.json({ ok: false, reason: 'not-a-graph-artifact' });
+
+  const sse = require('../services/graph-run-sse');
+  const event = sse.emitEvent(
+    rootRunId, 'agent.phase',
+    `${agentId || '(未知 agent)'} 阶段流转 → ${phase || '(未知阶段)'}`,
+    { agentId: agentId || null, phase: phase || null, artifact },
+    { ref: nodeRunId, kind: 'agent.phase' }
+  );
+  res.json({ ok: true, rootRunId, nodeRunId, timelineEventId: event && event.timeline && event.timeline.ts });
+}));
+
+/**
  * POST /api/graph-runs/:id/budget — 「追加预算」（运维操作，不在 §四.C 五个操作之列）
  * body: { total_agent_calls?, total_tokens?, wallclock_ms?, resume?: boolean }
  * 可用条件：run_status = 'blocked'
@@ -357,6 +357,26 @@ class CompanyService {
     }
     if (updates.sop !== undefined) company.sop = updates.sop;
     if (updates.heartbeat !== undefined) company.heartbeat = { ...company.heartbeat, ...updates.heartbeat };
+
+    // 42 号文档 Phase 3：target_dir 的配置入口。校验复用 path-resolver 的 validateLinkedTarget
+    // ——39 号文档 P5 落地时就是从这里抽出来的共享函数，graph-engine.js 的 ensureProjectRoot
+    // 用它做运行时校验，这里在配置阶段就先做一遍，不用等第一次真的分配项目根才发现路径不对。
+    // 校验失败直接抛出（调用方 try/catch 转 400），不静默吞掉、不写进一半的脏状态——
+    // 抛出发生在 _saveCompany() 之前，本次 update 里其它字段也不会被落盘（同一次保存，要么全写要么不写）。
+    if (updates.target_dir !== undefined) {
+      if (updates.target_dir === null || updates.target_dir === '') {
+        company.target_dir = null;
+        company.target_mode = null;
+      } else {
+        // 缺省 'linked-existing'：与 graph-engine.js 的 readCompanyTargetConfig 同一条默认值口径，
+        // 两处判据分叉是这个仓库反复栽过的坑（"两套体系不统一"），不能各写一份。
+        const mode = updates.target_mode === 'linked-new' ? 'linked-new' : 'linked-existing';
+        const { validateLinkedTarget } = require('./devloop/path-resolver');
+        company.target_dir = validateLinkedTarget(updates.target_dir, mode);
+        company.target_mode = mode;
+      }
+    }
+
     company.updatedAt = new Date().toISOString();
     this._saveCompany(company);
 /**
- * dream —— 经验汇流（[29-DREAM](../../docs/todo/system-design/29-dream-design.md)）。
+ * dream —— 经验汇流（[29-DREAM](../../docs/done/system-design/29-dream-design.md)）。
  *
  * 定时把**所有 agent 在所有公司**的原始记录提炼成不含公司特定信息的经验，
  * 沉淀到本体上，让经验跨公司汇流而不泄漏任何一家的具体信息。
@@ -2905,6 +2905,53 @@ function stopWallclockWatchdog() {
 }
 /**
+ * 42 号文档 Phase 1a：开机孤儿节点清扫。
+ *
+ * `graph_run_nodes.status='running'` 这一行不代表背后真的有个活的进程——它只是「上次问到的
+ * 状态」。服务器重启（比如换代码生效）会把正在跑的 Claude CLI 子进程连带杀掉，但这一行留在
+ * `running`，永远不会自己变成 `blocked`：`ceo` 的两条唤醒路径（事件驱动 + 30 分钟兜底扫描）
+ * 判据都只认 `status='blocked'`，对这个状态完全不可见（39 号文档 §七.1 真实撞出来的）。
+ *
+ * 不发明新状态：这本质上跟 `infra_flake`（基础设施打断，跟设计/实现对不对无关）是同一类事，
+ * 服务器重启只是这个桶里更严重的一个成员——原地重跑的熔断线（`INFRA_FLAKE_HARD_CAP`）现成能用。
+ * 复用 `routeFailure` 的 infra_flake 分支，不另起一套判定/熔断逻辑；调用形状照抄 `advanceOne`
+ * 里「先 `transitionNode` 落 fail_reason，再取新鲜的 `nodeRun`/`def` 传给 `routeFailure`」那一段。
+ *
+ * @param {string} cutoffIso 判定孤儿的时间线——`started_at` 早于这个时刻的 running 节点判定为
+ *   孤儿（本次进程启动前就已经在跑，不可能是本进程自己起的）。调用方传「本次进程启动时间」；
+ *   测试用任意时刻构造场景。
+ * @returns {{scanned:number, swept:Array<{runId:string, nodeRunId:string, infraRerun:boolean}>}}
+ */
+function sweepOrphanedRunningNodes(cutoffIso) {
+  const rows = getDb()
+    .prepare(`SELECT id, run_id FROM graph_run_nodes WHERE status = 'running' AND started_at IS NOT NULL AND started_at < ?`)
+    .all(cutoffIso);
+
+  const swept = [];
+  for (const row of rows) {
+    try {
+      const run = getRun(row.run_id);
+      if (!run) continue; // run 行本身没了（不该发生，防御性跳过）
+      const def = defIndex(run);
+
+      const changed = sse.transitionNode(row.run_id, row.id, 'running', 'fail', {
+        failReason: INFRA_FLAKE_REASON,
+        failNodeRef: null, outputRef: null, agentRunId: null, childRunId: null, completedAt: now(),
+      }, { summary: `开机孤儿节点清扫：服务器重启前处于 running，背后进程已不存在，判 infra_flake 交给既有熔断/重跑逻辑` });
+      if (!changed) continue; // 0 行 = 已经被别的路径结算过了，不重复处理
+
+      const nodeRun = getRunNode(row.id);
+      const out = { activated: [], backwardEdgeId: null, loop: null, contractDiff: null, crossLayer: null, reset: [], infraRerun: false };
+      routeFailure(row.run_id, def, nodeRun, out, null);
+      swept.push({ runId: row.run_id, nodeRunId: row.id, infraRerun: out.infraRerun });
+    } catch (err) {
+      console.error(`[graph-engine] sweepOrphanedRunningNodes node=${row.id} 异常: ${err.message}`);
+    }
+  }
+  return { scanned: rows.length, swept };
+}
+
+/**
  * 扣减（「只增不减」，§四.A.3）。始终写 root run 那一行。
  * ponytail: 读-改-写不是原子的，当前单进程串行驱动（runAuto 一次只推一个节点）下够用；
  * 升级路径是把自增下沉成一条 `UPDATE ... SET budget_json = json_set(...)` 的 SQL。
@@ -3439,6 +3486,52 @@ function retryNode(runId, nodeRunId, { reopenRun = true, remediationNote = null 
   };
 }
+/**
+ * 42 号文档 Phase 1b：「强制判失败以便恢复」。
+ *
+ * `retryNode` 只接受 `fail`/`blocked` 的节点——但真实运维里会遇到一种它管不到的情形：节点
+ * `status='running'`，人（或 `ceo`）判断它已经不可能再自己完成了（比如背后进程确实卡死，
+ * 不是 Phase 1a 那种"重启后一定是孤儿"，而是进程本身还在但没有任何进展）。在这条修复之前，
+ * 唯一的恢复手段是直接调 `graph-run-sse.transitionNode` 这个内部函数——对人类操作者或 `ceo`
+ * 都不现实，两者都只能走 HTTP。
+ *
+ * 语义："我确认这个节点救不回来了，把它判 fail，交给既有的 fail→retry/backward-edge 路径
+ * 处理"——不发明新的路由逻辑，`routeFailure` 该怎么选边还是怎么选边（默认原因不是
+ * `infra_flake`，所以不会走原地重跑那条特判，是走 `selectFailEdge`/`handleBackwardEdge`
+ * 的常规路径）。
+ *
+ * @param {string} runId
+ * @param {string} nodeRunId
+ * @param {string} [failReason='operator_intervention'] 默认值刻意不是 `infra_flake`——那个
+ *   值有特殊语义（原地重跑、不烧计数），人工判定"这个真的救不回来了"不该被误当成一次性抖动。
+ * @returns {{ok:boolean, reason?:string, nodeStatus?:string, runId?:string, nodeRunId?:string}}
+ */
+function forceFailNode(runId, nodeRunId, failReason = 'operator_intervention') {
+  const nodeRun = getRunNode(nodeRunId);
+  if (!nodeRun || nodeRun.run_id !== runId) throw new Error(`节点不属于该 run: ${nodeRunId}`);
+  if (nodeRun.status !== 'running') {
+    return { ok: false, reason: 'not-force-failable', nodeStatus: nodeRun.status };
+  }
+
+  const changed = sse.transitionNode(runId, nodeRunId, 'running', 'fail', {
+    failReason,
+    failNodeRef: null, outputRef: null, agentRunId: null, childRunId: null, completedAt: now(),
+  }, { summary: `人工「强制判失败」：running → fail（failReason=${failReason}），交给既有失败路由处理` });
+  if (!changed) return { ok: false, reason: 'taken-by-other', nodeStatus: (getRunNode(nodeRunId) || {}).status };
+
+  const run = getRun(runId);
+  const def = defIndex(run);
+  const fresh = getRunNode(nodeRunId);
+  const out = { activated: [], backwardEdgeId: null, loop: null, contractDiff: null, crossLayer: null, reset: [], infraRerun: false };
+  routeFailure(runId, def, fresh, out, null);
+
+  return {
+    ok: true, runId, nodeRunId,
+    nodeStatus: (getRunNode(nodeRunId) || {}).status,
+    runStatus: (getRun(runId) || {}).run_status,
+  };
+}
+
 // ────────────────────────────────────────────────────────────────
 // §四.C 末段：重试后级联下游的判据 = contract_hash 变没变
 // ────────────────────────────────────────────────────────────────
@@ -4775,6 +4868,9 @@ module.exports = {
   descendantRuns,
   landPause,
+  // 42 号文档 Phase 1b：running 节点的人工/ceo 强制判失败出口（retryNode 管不到 running）
+  forceFailNode,
+
   // 任务级总预算（§四.A.3）
   checkBudget,
   spendBudget,
@@ -4793,6 +4889,9 @@ module.exports = {
   startWallclockWatchdog,
   stopWallclockWatchdog,
+  // 42 号文档 Phase 1a：开机孤儿节点清扫（服务器重启杀掉 in-flight 进程，节点行留在 running）
+  sweepOrphanedRunningNodes,
+
   // 重试级联判据（§四.C 末段）
   diffContracts,
   applyRetryCascade,
@@ -458,8 +458,10 @@ function seedAgents() {
       // **只写不降级**：config.json 里的 status 是本体的**出生默认值**，而毕业与否是运行时
       // 从磁盘定义学到的事实（promoteDraftIfComplete / reconcile 的 E 分支）。原样 upsert 的话，
       // 每次进程重启 seedAgents 都会把已经转正的行按 config.json 打回 draft/training ——
-      // 闸门抬起来一次、下次启动又落下去，而且一处报错都没有（code-planner 的 config.json
-      // 至今写着 "training"）。所以：库里已经脱离未毕业域的行，不许再被推回去；其余照写。
+      // 闸门抬起来一次、下次启动又落下去，而且一处报错都没有（真实撞过的样本是 code-planner，
+      // 它的 config.json 当时写着 "training"，见 `graduation-criteria-reality.test.js`；
+      // 后来 config.json 已经改成了毕业态的 "enabled"，这条注释只留问题形状，不再钉死具体值，
+      // 避免又变成一处会随源码变化过期的死引用）。所以：库里已经脱离未毕业域的行，不许再被推回去；其余照写。
       const status = (existing && isUngraduatedStatus(configStatus) && !isUngraduatedStatus(existing.status))
         ? existing.status
         : configStatus;
@@ -2558,10 +2558,23 @@ function findFiles({ companyId, taskId = null, kinds = null }) {
   return rows.filter((r) => want.has(r.kind));
 }
+/**
+ * kind='log' 永远不能被声明成 required：`indexNodeOutputs()` 的三级认领规则
+ * （文件名匹配声明 kind → 已知文件名 → 唯一无歧义兜底）对 test/integration 类节点
+ * 结构性地认不出一个 kind='log' 的文件——它们落盘的是 coder.log/test.log 之类，
+ * 全部被归到 kind='artifact'。required:true 的 log 契约因此**永远无法满足**，
+ * 触发 requiredInputsMissing() 把节点打成 missing_required_input 死循环
+ * （33 号文档 + snakegame-co T-mtfh2kuf-7c31 复现两次：一次模板 executor.json 里
+ * 手滑漏了 required:false，一次 workgraph-planning agent 的 tools.md 例句没跟着改）。
+ * 与其指望每个模板作者 / 每次 LLM 规划都记得写对，不如把这条底线收在唯一的落库口。
+ */
+const NEVER_REQUIRED_KINDS = new Set(['log']);
+
 /** 在边上声明「这条边要传什么 kind」。规划时写，只有 kind 没有实例。 */
 function declareEdgeContract({ edgeLayer, edgeId, kind, required = true, role = 'produces' }) {
   if (!['org', 'work'].includes(edgeLayer)) throw new Error(`edgeLayer 非法: ${edgeLayer}`);
   if (!edgeId || !kind) throw new Error('declareEdgeContract 需要 edgeId / kind');
+  const effectiveRequired = required && !NEVER_REQUIRED_KINDS.has(kind);
   // role 默认 produces：出边声明产出是压倒性多数，needs 必须显式写。
   // 去重键仍是 (layer, edge, kind) 而不含 role —— 同一条边对同一个 kind 既声明 produces
   // 又声明 needs 是自相矛盾的输入（「我产它」和「我要别人产它」），
@@ -2574,7 +2587,7 @@ function declareEdgeContract({ edgeLayer, edgeId, kind, required = true, role = 
       ON CONFLICT(edge_layer, edge_id, kind) DO NOTHING
     `)
     .run(
-      newId('gec'), edgeLayer, String(edgeId), kind, required ? 1 : 0,
+      newId('gec'), edgeLayer, String(edgeId), kind, effectiveRequired ? 1 : 0,
       role === 'needs' ? 'needs' : 'produces', new Date().toISOString()
     );
 }
+/**
+ * Guard: 同一 convId 恢复上下文时（buildPrompt 场景 C）按模型上下文 token 预算动态注入历史，
+ * 不再是固定的 slice(-20) + 单条 500 字截断 —— 预算内整段塞进去，超预算才从最早的开始丢。
+ * 否则 ACP 进程重启/空闲超时后，早于第 20 条的历史会静默丢失，agent 会"忘了"之前聊过什么。
+ */
+const fs = require('fs');
+const path = require('path');
+
+const { buildPrompt, appendHistory, truncateHistoryToBudget, estimateTokens } = require('../../routes/agent-chat');
+
+const agentId = 'master';
+const agentDir = path.resolve(__dirname, `../../../system/agents/${agentId}`);
+
+describe('agent-chat buildPrompt 场景 C：同 convId 恢复上下文', () => {
+  it('注入完整历史，不按 slice(-20) 或单条 500 字截断', () => {
+    const convId = `test-history-guard-${Date.now()}`;
+    const convDir = path.resolve(__dirname, `../../../system/agents/${agentId}/_global/conversations/${convId}`);
+    try {
+      const longFirstMessage = 'X'.repeat(600); // 超过原来单条 500 字截断阈值
+      appendHistory(agentId, convId, { role: 'user', content: longFirstMessage });
+      for (let i = 0; i < 25; i++) {
+        appendHistory(agentId, convId, { role: 'assistant', content: `filler-${i}` });
+      }
+
+      const prompt = buildPrompt(agentDir, agentId, convId, '新消息', true);
+
+      expect(prompt).toContain(longFirstMessage);
+      expect(prompt).not.toContain('...(截断)');
+    } finally {
+      fs.rmSync(convDir, { recursive: true, force: true });
+    }
+  });
+});
+
+describe('truncateHistoryToBudget：预算超支时按 token 从最早的开始丢', () => {
+  it('预算装不下全部历史时，丢最老的，留最近的', () => {
+    const history = [
+      { role: 'user', content: 'oldest' },
+      { role: 'assistant', content: 'middle' },
+      { role: 'user', content: 'newest' },
+    ];
+    const budget = estimateTokens('middle') + estimateTokens('newest'); // 刚好够后两条，装不下 oldest
+
+    const kept = truncateHistoryToBudget(history, budget);
+
+    expect(kept.map(m => m.content)).toEqual(['middle', 'newest']);
+  });
+
+  it('单条消息本身就超预算时，仍然至少保留最近一条，不会返回空', () => {
+    const history = [{ role: 'user', content: 'X'.repeat(10000) }];
+
+    const kept = truncateHistoryToBudget(history, 1);
+
+    expect(kept).toHaveLength(1);
+  });
+});
+/**
+ * Unit Tests — ceo 自主创建的 task 仍然受既有闸门约束（42 号文档 Phase 2，39 号文档 §四.4）
+ *
+ * 39 号文档 §四.4 拍板："ceo 全权自主 enqueue，但 max_parallel_tasks / DEFAULT_TASK_BUDGET /
+ * goal 级 org-validator 这几道闸门必须照样拦住它"——这几道闸门挂在数据层/调度器层，理论上
+ * 不认"谁创建的"，天然覆盖，但落地时没有补一条测试钉死这一点（§六"已知遗留"记过一笔）。
+ * 这份文件补上，走 ceo 实际会用的通路（POST /tasks draft:true + created_by:'ceo' → /enqueue），
+ * 不抄近道直接摆数据库行。
+ *
+ * 隔离手法与 task-entry-draft-mode.test.js / goal-task-acceptance.test.js 一致。
+ */
+const fs = require('fs');
+const os = require('os');
+const path = require('path');
+
+const TEST_DB_PATH = '/tmp/test-ceo-created-task-gates.sqlite';
+const DB_FILES = [TEST_DB_PATH, `${TEST_DB_PATH}-shm`, `${TEST_DB_PATH}-wal`];
+const COMPANIES_DIR = path.resolve(__dirname, '../../../data/companies');
+const MODULES = [
+  '../../services/graph-db',
+  '../../services/work-graph-db',
+  '../../services/org-graph-service',
+  '../../services/graph-run-sse',
+  '../../services/graph-engine',
+  '../../services/task-settle',
+  '../../services/goal-validation',
+  '../../routes/company',
+];
+
+let wdb;
+let orgSvc;
+let engine;
+let server;
+let base;
+const createdCompanies = [];
+
+async function call(method, url, body) {
+  const r = await fetch(base + url, {
+    method,
+    headers: { 'Content-Type': 'application/json' },
+    body: body === undefined ? undefined : JSON.stringify(body),
+  });
+  return [r.status, await r.json()];
+}
+
+function ensureAgents(ids) {
+  const db = wdb.getDb();
+  const now = new Date().toISOString();
+  const ins = db.prepare(`
+    INSERT OR IGNORE INTO system_agents
+      (id, name, scope, owner_company_id, legacy_path, status, created_at, updated_at)
+    VALUES (?, ?, 'public', NULL, ?, 'active', ?, ?)
+  `);
+  for (const id of new Set(ids)) ins.run(id, id, `system/agents/${id}`, now, now);
+}
+
+/** 真实写一份 company.json（不是 mock）——maxActiveRootRuns() 直接读盘，绕不过去。 */
+function makeCompany(companyId, extra = {}) {
+  const dir = path.join(COMPANIES_DIR, companyId);
+  fs.mkdirSync(dir, { recursive: true });
+  fs.writeFileSync(path.join(dir, 'company.json'), JSON.stringify({ id: companyId, name: companyId, ...extra }));
+  createdCompanies.push(companyId);
+
+  ensureAgents(['org-planner', 'org-coder', 'org-validator']);
+  expect(
+    orgSvc.writeGraph(companyId, {
+      nodes: ['org-planner', 'org-coder', 'org-validator'],
+      edges: [
+        { from: 'org-planner', to: 'org-coder', condition: 'success' },
+        { from: 'org-coder', to: 'org-validator', condition: 'success' },
+      ],
+    }).ok
+  ).toBe(true);
+}
+
+describe('ceo 自主创建的 task 仍然受既有闸门约束（39 号文档 §四.4）', () => {
+  beforeAll(async () => {
+    for (const f of DB_FILES) { try { fs.unlinkSync(f); } catch { /* 本来就没有 */ } }
+    process.env.GRAPH_DB_PATH = TEST_DB_PATH;
+    process.env.GRAPH_RUNS_DIR = fs.mkdtempSync(path.join(os.tmpdir(), 'ceo-task-gates-runs-'));
+    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');
+
+    const express = require('express');
+    const app = express();
+    app.use(express.json());
+    app.use('/api/company', require('../../routes/company'));
+    await new Promise((resolve) => { server = app.listen(0, resolve); });
+    base = `http://127.0.0.1:${server.address().port}/api/company`;
+  });
+
+  afterAll(() => {
+    if (server) server.close();
+    for (const cid of createdCompanies) {
+      fs.rmSync(path.join(COMPANIES_DIR, cid), { recursive: true, force: true });
+    }
+    for (const f of DB_FILES) { try { fs.unlinkSync(f); } catch { /* 已经删了 */ } }
+    try { fs.rmSync(process.env.GRAPH_RUNS_DIR, { recursive: true, force: true }); } catch { /* ignore */ }
+    delete process.env.GRAPH_DB_PATH;
+    delete process.env.GRAPH_RUNS_DIR;
+    for (const m of MODULES) delete require.cache[require.resolve(m)];
+  });
+
+  // ──────────────────────────────────────────────────────────────
+  // 1. max_parallel_tasks：坑满了，ceo 建的任务一样排队，不能插队
+  // ──────────────────────────────────────────────────────────────
+  it('max_parallel_tasks=1 时坑已被占，ceo 走 draft+enqueue 建的第二条任务落 queued，不会插队执行', async () => {
+    const cid = 'ceo-gate-slots';
+    makeCompany(cid, { max_parallel_tasks: 1 });
+
+    // 人类下达第一条，占满唯一的执行位
+    const [s1, taskA] = await call('POST', `/${cid}/tasks`, { task: '人类下达的任务，占坑' });
+    expect(s1).toBe(201);
+    expect(wdb.getTask(taskA.taskId).status).toBe('running');
+
+    // ceo 走它自己的通路：draft 建 → enqueue
+    const [s2, taskB] = await call('POST', `/${cid}/tasks`, {
+      task: 'ceo 自主提的第二条任务', draft: true, created_by: 'ceo',
+    });
+    expect(s2).toBe(201);
+    expect(taskB.status).toBe('draft');
+
+    const [s3, enqueued] = await call('POST', `/${cid}/tasks/${taskB.taskId}/enqueue`);
+    expect(s3).toBe(201);
+
+    // 坑满：这条任务必须落 queued，不能因为是 ceo 建的就获得一个额外的执行位
+    const row = wdb.getTask(taskB.taskId);
+    expect(row.status).toBe('queued');
+    expect(enqueued.status).toBe('queued');
+    const run = wdb.getRun(row.current_run_id);
+    expect(run.run_status).toBe('queued');
+  });
+
+  // ──────────────────────────────────────────────────────────────
+  // 2. DEFAULT_TASK_BUDGET：预算给得再小，ceo 建的任务也不会被特殊放宽
+  // ──────────────────────────────────────────────────────────────
+  it('ceo 建的任务预算耗尽照样判 budget-exhausted，不会因为创建者是 agent 就获得额外预算', async () => {
+    const cid = 'ceo-gate-budget';
+    makeCompany(cid);
+
+    const tinyBudget = { total_agent_calls: 0, total_tokens: 0, wallclock_ms: 7_200_000 };
+    const [s1, task] = await call('POST', `/${cid}/tasks`, {
+      task: 'ceo 自主提的任务，预算给得极小',
+      draft: true,
+      created_by: 'ceo',
+      budget: tinyBudget,
+    });
+    expect(s1).toBe(201);
+
+    const [s2] = await call('POST', `/${cid}/tasks/${task.taskId}/enqueue`);
+    expect(s2).toBe(201);
+
+    const run = wdb.getRun(wdb.getTask(task.taskId).current_run_id);
+    expect(run.budget_json).toBeTruthy();
+    const parsed = JSON.parse(run.budget_json);
+    expect(parsed.total_agent_calls).toBe(0); // 存进去的确实是那份小预算，没有被谁悄悄改大
+
+    // checkBudget 不认「谁建的」，只认预算数字本身
+    const gate = engine.checkBudget(run);
+    expect(gate.ok).toBe(false);
+    expect(gate.exhausted).toContain('total_agent_calls');
+  });
+
+  // ──────────────────────────────────────────────────────────────
+  // 3. goal 级 org-validator：ceo 建的多 task goal 全部 completed 后，收敛验收照样跑一次
+  // ──────────────────────────────────────────────────────────────
+  it('ceo 建的两条 task 全 completed 后，goal 级 org-validator 照样被调一次（不因创建者是 agent 而跳过）', async () => {
+    const cid = 'ceo-gate-goal-validation';
+    makeCompany(cid);
+
+    const goal = wdb.createGoal({ companyId: cid, title: '两步都由 ceo 建的目标', description: '测试用' });
+
+    const [s1, taskA] = await call('POST', `/${cid}/tasks`, {
+      task: 'ceo 建的第一条子任务', draft: true, created_by: 'ceo', goal_id: goal.id,
+    });
+    expect(s1).toBe(201);
+    await call('POST', `/${cid}/tasks/${taskA.taskId}/enqueue`);
+
+    const [s2, taskB] = await call('POST', `/${cid}/tasks`, {
+      task: 'ceo 建的第二条子任务', draft: true, created_by: 'ceo', goal_id: goal.id,
+    });
+    expect(s2).toBe(201);
+    await call('POST', `/${cid}/tasks/${taskB.taskId}/enqueue`);
+
+    expect(wdb.getTask(taskA.taskId).created_by).toBe('ceo');
+    expect(wdb.getTask(taskB.taskId).created_by).toBe('ceo');
+
+    const validation = require('../../services/goal-validation');
+    const seen = [];
+    validation.setValidateGoal(async (ctx) => {
+      seen.push(ctx);
+      return { pass: true, verdict: '两条子任务合起来确实达成了目标', tokens: 42 };
+    });
+
+    try {
+      const sse = require('../../services/graph-run-sse');
+      const runA = wdb.getTask(taskA.taskId).current_run_id;
+      let runB = wdb.getTask(taskB.taskId).current_run_id;
+      expect(wdb.getRun(runB).run_status).toBe('queued'); // 同公司同一时间只有一个执行位
+
+      // 先让 runA 收尾，空出执行位。调度器出队走的是 setImmediate（挂在 transitionRun 钩子上），
+      // 这条用例不测调度时序本身（那是 task-slots-parallel.test.js 的职责）——坑空之后直接
+      // 用 updateRunStatus 把 runB 推 ready，走的还是真实的准入事务，只是不等 setImmediate。
+      sse.transitionRun(runA, wdb.getRun(runA).run_status, 'completed', {}, { summary: '用例直推终态' });
+      wdb.updateRunStatus(runB, 'queued', 'ready');
+      expect(wdb.getRun(runB).run_status).toBe('ready'); // 坑已空出，推 ready 成功
+      sse.transitionRun(runB, 'ready', 'running', {}, { summary: '用例直推终态' });
+      sse.transitionRun(runB, 'running', 'completed', {}, { summary: '用例直推终态' });
+
+      const { isPendingVerdict } = require('../../services/task-settle');
+      for (let i = 0; i < 50; i += 1) {
+        const v = wdb.getGoal(goal.id).verdict;
+        if (v && !isPendingVerdict(v)) break;
+        await new Promise((r) => setImmediate(r));
+      }
+
+      expect(seen).toHaveLength(1); // 一个 goal 只验一次，即便两条子任务都是 ceo 建的
+      expect(seen[0].goal.id).toBe(goal.id);
+      expect(seen[0].tasks.map((t) => t.created_by).sort()).toEqual(['ceo', 'ceo']);
+      expect(wdb.getGoal(goal.id).status).toBe('done');
+    } finally {
+      validation.setValidateGoal(null);
+    }
+  });
+});
+/**
+ * Unit Tests — PUT /api/company/:companyId 的 target_dir 配置入口（42 号文档 Phase 3）
+ *
+ * 39 号文档 P5 落地的是"配了 company.json.target_dir 就生效"这一半，"人怎么把这两个字段
+ * 填进去"这一半此前只能手工编辑 company.json。这条测试钉住新入口的校验分支——校验复用
+ * path-resolver.validateLinkedTarget（P5 已经抽出来的共享函数），跟 graph-engine.js 运行时
+ * 用的是同一份判据，不重新写一遍。
+ *
+ * 走真入口：把 router 挂到真 express 上 listen(0) 再 fetch，不 mock company-service。
+ */
+import { describe, it, expect, beforeAll, afterAll } from 'vitest';
+import fs from 'fs';
+import os from 'os';
+import path from 'path';
+import express from 'express';
+
+const COMPANIES_DIR = path.resolve(__dirname, '../../../data/companies');
+
+describe('PUT /api/company/:companyId — target_dir 配置（42 号文档 Phase 3）', () => {
+  let server;
+  let base;
+  const createdCompanies = [];
+  const createdDirs = [];
+
+  beforeAll(async () => {
+    const app = express();
+    app.use(express.json());
+    app.use('/api/company', require('../../routes/company'));
+    await new Promise((resolve) => { server = app.listen(0, resolve); });
+    base = `http://127.0.0.1:${server.address().port}/api/company`;
+  });
+
+  afterAll(() => {
+    if (server) server.close();
+    for (const cid of createdCompanies) {
+      fs.rmSync(path.join(COMPANIES_DIR, cid), { recursive: true, force: true });
+    }
+    for (const d of createdDirs) {
+      try { fs.rmSync(d, { recursive: true, force: true }); } catch { /* ignore */ }
+    }
+  });
+
+  function makeCompany(companyId) {
+    const dir = path.join(COMPANIES_DIR, companyId);
+    fs.mkdirSync(dir, { recursive: true });
+    fs.writeFileSync(path.join(dir, 'company.json'), JSON.stringify({ id: companyId, name: companyId }));
+    createdCompanies.push(companyId);
+    return dir;
+  }
+
+  async function put(companyId, body) {
+    const r = await fetch(`${base}/${companyId}`, {
+      method: 'PUT',
+      headers: { 'Content-Type': 'application/json' },
+      body: JSON.stringify(body),
+    });
+    return [r.status, await r.json()];
+  }
+
+  it('linked-existing：合法的已存在空目录，写入成功', async () => {
+    const cid = 'target-dir-cfg-existing';
+    makeCompany(cid);
+    const target = fs.mkdtempSync(path.join(os.tmpdir(), 'target-dir-cfg-existing-'));
+    createdDirs.push(target);
+
+    const [status, body] = await put(cid, { target_dir: target, target_mode: 'linked-existing' });
+    expect(status).toBe(200);
+    expect(body.company.target_dir).toBe(path.resolve(target));
+    expect(body.company.target_mode).toBe('linked-existing');
+
+    // 真的落盘了，不是只回了个内存对象
+    const onDisk = JSON.parse(fs.readFileSync(path.join(COMPANIES_DIR, cid, 'company.json'), 'utf8'));
+    expect(onDisk.target_dir).toBe(path.resolve(target));
+  });
+
+  it('linked-new：目录不存在时自动创建，写入成功', async () => {
+    const cid = 'target-dir-cfg-new';
+    makeCompany(cid);
+    const parent = fs.mkdtempSync(path.join(os.tmpdir(), 'target-dir-cfg-new-parent-'));
+    createdDirs.push(parent);
+    const target = path.join(parent, 'brand-new-project');
+
+    expect(fs.existsSync(target)).toBe(false);
+    const [status, body] = await put(cid, { target_dir: target, target_mode: 'linked-new' });
+    expect(status).toBe(200);
+    expect(body.company.target_mode).toBe('linked-new');
+    expect(fs.existsSync(target)).toBe(true); // validateLinkedTarget 的既有副作用：自动建目录
+  });
+
+  it('不传 target_mode 时默认按 linked-existing 处理（与 graph-engine.js 的默认口径一致）', async () => {
+    const cid = 'target-dir-cfg-default-mode';
+    makeCompany(cid);
+    const target = fs.mkdtempSync(path.join(os.tmpdir(), 'target-dir-cfg-default-'));
+    createdDirs.push(target);
+
+    const [status, body] = await put(cid, { target_dir: target });
+    expect(status).toBe(200);
+    expect(body.company.target_mode).toBe('linked-existing');
+  });
+
+  it('敏感路径命中黑名单 → 400，不写入', async () => {
+    const cid = 'target-dir-cfg-sensitive';
+    makeCompany(cid);
+    const sensitive = path.join(os.homedir(), '.ssh', 'target-dir-cfg-should-not-write');
+
+    const [status, body] = await put(cid, { target_dir: sensitive, target_mode: 'linked-existing' });
+    expect(status).toBe(400);
+    expect(body.error).toContain('sensitive_path');
+
+    const onDisk = JSON.parse(fs.readFileSync(path.join(COMPANIES_DIR, cid, 'company.json'), 'utf8'));
+    expect(onDisk.target_dir).toBeUndefined(); // 校验失败，company.json 没有被改动
+  });
+
+  it('linked-new 但目录已存在且非空 → 400，不写入', async () => {
+    const cid = 'target-dir-cfg-new-nonempty';
+    makeCompany(cid);
+    const target = fs.mkdtempSync(path.join(os.tmpdir(), 'target-dir-cfg-nonempty-'));
+    createdDirs.push(target);
+    fs.writeFileSync(path.join(target, 'already-here.txt'), 'x');
+
+    const [status, body] = await put(cid, { target_dir: target, target_mode: 'linked-new' });
+    expect(status).toBe(400);
+    expect(body.error).toContain('not empty');
+  });
+
+  it('linked-existing 但目录不存在 → 400，不写入', async () => {
+    const cid = 'target-dir-cfg-existing-missing';
+    makeCompany(cid);
+    const parent = fs.mkdtempSync(path.join(os.tmpdir(), 'target-dir-cfg-missing-parent-'));
+    createdDirs.push(parent);
+    const target = path.join(parent, 'does-not-exist');
+
+    const [status, body] = await put(cid, { target_dir: target, target_mode: 'linked-existing' });
+    expect(status).toBe(400);
+    expect(body.error).toContain('does not exist');
+  });
+
+  it('target_dir 传空字符串清掉已有配置', async () => {
+    const cid = 'target-dir-cfg-clear';
+    makeCompany(cid);
+    const target = fs.mkdtempSync(path.join(os.tmpdir(), 'target-dir-cfg-clear-'));
+    createdDirs.push(target);
+
+    const [s1, b1] = await put(cid, { target_dir: target, target_mode: 'linked-existing' });
+    expect(s1).toBe(200);
+    expect(b1.company.target_dir).toBeTruthy();
+
+    const [s2, b2] = await put(cid, { target_dir: '' });
+    expect(s2).toBe(200);
+    expect(b2.company.target_dir).toBeNull();
+    expect(b2.company.target_mode).toBeNull();
+  });
+
+  it('公司不存在 → 404', async () => {
+    const [status] = await put('target-dir-cfg-nope', { target_dir: '/tmp/whatever' });
+    expect(status).toBe(404);
+  });
+});
 /**
- * dream 的 REST 入口（29-DREAM，见 docs/todo/system-design/29-dream-design.md）。
+ * dream 的 REST 入口（29-DREAM，见 docs/done/system-design/29-dream-design.md）。
  *
  * 路由本身没有业务逻辑 —— 全部委托给已经测过的 `dream-service.js`。
  * 这份只验两件路由层独有的东西：
@@ -196,10 +196,14 @@ describe.skipIf(!fs.existsSync(CODE_PLANNER_DIR))(&#39;code-planner èƒ½è¢«æ–°å…¬å¸é
     expect(r.graduated).toContain('code-planner');
     expect(statusOf()).toBe('active');
-    // seedAgents ä¼šæŠŠ config.json çš„ status åŽŸæ · upsert â€”â€” å®ƒå†™ç€ "training"ã€‚
-    // ä¸åŠ ã€Œåªå†™ä¸é™çº§ã€çš„è¯ï¼Œè¿™é‡Œä¼šæŠŠåˆšè½¬æ£çš„è¡Œæ‰“å›žåŽ»ï¼Œæ¯æ¬¡è¿›ç¨‹é‡å¯éƒ½é‡æ¼”ä¸€éã€‚
+    // seedAgents ä¼šæŠŠ config.json çš„ status åŽŸæ · upsertã€‚ã€Œåªå†™ä¸é™çº§ã€å®ˆçš„æ˜¯ã€Œä¸è®¸è¢«
+    // config.json æŽ¨å›ž draft/trainingã€ï¼Œ**ä¸**ä¿è¯è½¬æ£åŽçš„å€¼åŽŸæ ·ä¸å˜â€”â€”config.json å½“å‰
+    // å†™çš„æ˜¯ä»€ä¹ˆå·²æ¯•ä¸šçŠ¶æ€ï¼ˆ"enabled" ä¹Ÿå¥½ã€åˆ«çš„ä¹Ÿå¥½ï¼Œåªè¦ä¸æ˜¯ draft/trainingï¼‰ï¼Œupsert å°±ä¼š
+    // ç”¨é‚£ä¸ªå€¼è¦†ç›–ï¼Œè¿™æ˜¯è®¾è®¡å¦‚æ¤ï¼Œä¸æ˜¯æœ¬ç”¨ä¾‹è¦æµ‹çš„ä¸œè¥¿ï¼ˆ2026-08-30 å¤æ ¸ï¼šconfig.json å·²ç»ä»Ž
+    // å†™æ»çš„ "training" æ”¹æˆäº† "enabled"ï¼Œä¸å†ç¡¬ç¼–ç å…·ä½“å€¼ï¼Œé¿å…è¿™æ¡æµ‹è¯•å†æ¬¡å› ä¸º config.json
+    // å†…å®¹å˜åŒ–è€Œå‡çº¢ï¼‰ã€‚
     seed.seedAgents();
-    expect(statusOf()).toBe('active');
+    expect(graphService.isUngraduatedStatus(statusOf())).toBe(false);
     // å¹‚ç‰ï¼šç¬¬äºŒéæ²¡æœ‰å¯è½¬æ£çš„è¡Œ
     expect(seed.reconcileDanglingRows().graduated).toEqual([]);
@@ -156,6 +156,27 @@ describe(&#39;R-19.A 边上的数据契约：声明 → 落库 → 读回&#39;, () =&gt; {
     expect(rows.map((r) => [r.kind, r.required])).toEqual([['acceptance', 0]]);
   });
+  it('① kind=log 永远落成 required=0，哪怕调用方（模板/LLM 规划）写的是 required:true（33 号文档 + snakegame-co T-mtfh2kuf-7c31 两次复现）', () => {
+    const companyId = 'co-contract-log-floor';
+    ensureAgents(['unit-tester', 'coder-validator']);
+    const g = wdb.createWorkGraph({
+      companyId,
+      taskId: 'T-log-floor',
+      nodes: [
+        { nodeName: 'l-test', systemAgentId: 'unit-tester' },
+        { nodeName: 'l-val', systemAgentId: 'coder-validator' },
+      ],
+      edges: [
+        // 裸数组写法 = normalizeContracts 默认 required:true，正是漂移复现的形状
+        { from: 'l-test', to: 'l-val', condition: 'success', produces: ['log'] },
+      ],
+    });
+    expect(g.errors || []).toEqual([]);
+    const def = wdb.readDefGraph('work', g.id);
+    const rows = wdb.edgeContracts('work', def.edges[0].id);
+    expect(rows.map((r) => [r.kind, r.required])).toEqual([['log', 0]]);
+  });
+
   it('① kind 大小写/空格被归一（"  PRD " 与 "prd" 是同一个契约，不产生两行）', () => {
     const companyId = 'co-contract-case';
     ensureAgents(['prd-planning', 'sdd-planning']);
@@ -36,7 +36,12 @@ describe(&#39;extendBudget · 追加预算并结清卡死的墙钟锚点&#39;, () =&gt; {
   beforeEach(() => wdb.getDb().prepare('DELETE FROM graph_runs').run());
   it('run_b962ea87f58f 的真实形态：追加后立即可用，且锚点被断开', () => {
-    const stuckStartedAt = '2026-08-23T05:23:52.886Z'; // 距 now() 已远超 2h
+    // ⚠️ 曾经硬编码成绝对时间戳 '2026-08-23T05:23:52.886Z'（真实事故发生时的时刻）——
+    // 这是一颗时间炸弹：随真实时间流逝，这个绝对值与 Date.now() 的差值只会越来越大，
+    // 迟早会超过下面追加后的 6h 上限，让断言从「追加后立即可用」变成「怎么追加都不够」，
+    // 而这条红跟被测代码毫无关系。改成相对 Date.now() 回退 3 小时——同时满足
+    // 「超过追加前 2h 上限」与「低于追加后 6h 上限」，且不会随时间推移而漂移。
+    const stuckStartedAt = new Date(Date.now() - 3 * HOUR).toISOString();
     const run = seedRun('r_stuck', {
       total_agent_calls: 100, total_tokens: 5_000_000, wallclock_ms: 2 * HOUR,
       spent: { agent_calls: 35, tokens: 249_324, active_ms: 0, started_at: stuckStartedAt },
+/**
+ * Unit Tests — graph-engine 的开机孤儿节点清扫（42 号文档 Phase 1a）
+ *
+ * 场景：服务器进程被重启（比如换代码生效），正在跑某个 work graph 节点的真实 Claude CLI
+ * 子进程被连带杀掉，但 `graph_run_nodes.status` 永远停在 'running'——不会自己变成 'blocked'，
+ * ceo 的两条唤醒路径都只认 'blocked'，对这个状态完全不可见。
+ *
+ * `sweepOrphanedRunningNodes(cutoffIso)` 扫一遍 `started_at` 早于 cutoff 的 running 节点，
+ * 判定为孤儿，走 infra_flake 既有的原地重跑/熔断逻辑（不发明新状态）。
+ *
+ * 隔离手法与 graph-engine.test.js 一致：独立 GRAPH_DB_PATH + GRAPH_RUNS_DIR，真实
+ * data/graph.sqlite / data/companies/ 全程不被碰到。
+ */
+import { describe, it, expect, beforeAll, afterAll, beforeEach } from 'vitest';
+import fs from 'fs';
+import os from 'os';
+import path from 'path';
+
+describe('graph-engine 开机孤儿节点清扫', () => {
+  let wdb;
+  let engine;
+  let runsDir;
+  const TEST_DB_PATH = '/tmp/test-graph-engine-orphan-sweep.sqlite';
+
+  beforeAll(() => {
+    for (const f of [TEST_DB_PATH, `${TEST_DB_PATH}-shm`, `${TEST_DB_PATH}-wal`]) {
+      try { fs.unlinkSync(f); } catch {}
+    }
+    process.env.GRAPH_DB_PATH = TEST_DB_PATH;
+    runsDir = fs.mkdtempSync(path.join(os.tmpdir(), 'graph-engine-orphan-sweep-'));
+    process.env.GRAPH_RUNS_DIR = runsDir;
+    for (const m of [
+      '../../services/graph-db',
+      '../../services/graph-service',
+      '../../services/org-graph-service',
+      '../../services/work-graph-db',
+      '../../services/graph-run-sse',
+      '../../services/graph-engine',
+    ]) {
+      delete require.cache[require.resolve(m)];
+    }
+    wdb = require('../../services/work-graph-db');
+    engine = require('../../services/graph-engine');
+  });
+
+  afterAll(() => {
+    for (const f of [TEST_DB_PATH, `${TEST_DB_PATH}-shm`, `${TEST_DB_PATH}-wal`]) {
+      try { fs.unlinkSync(f); } catch {}
+    }
+    delete process.env.GRAPH_DB_PATH;
+    try { fs.rmSync(runsDir, { recursive: true, force: true }); } catch {}
+    delete process.env.GRAPH_RUNS_DIR;
+  });
+
+  beforeEach(() => {
+    const db = wdb.getDb();
+    db.pragma('foreign_keys = OFF');
+    db.exec(`
+      DELETE FROM graph_run_loop_records;
+      DELETE FROM graph_run_nodes;
+      DELETE FROM graph_runs;
+      DELETE FROM work_graph_edges;
+      DELETE FROM work_graph_nodes;
+      DELETE FROM work_graphs;
+      DELETE FROM system_agents;
+    `);
+    db.pragma('foreign_keys = ON');
+    engine.setAgentExecutor(null);
+  });
+
+  let seq = 0;
+  const nextCompany = () => `co-orphan-${++seq}`;
+
+  function ensureAgents(ids) {
+    const db = wdb.getDb();
+    const now = new Date().toISOString();
+    const ins = db.prepare(`
+      INSERT OR IGNORE INTO system_agents
+        (id, name, scope, owner_company_id, legacy_path, status, created_at, updated_at)
+      VALUES (?, ?, 'public', NULL, ?, 'active', ?, ?)
+    `);
+    for (const id of new Set(ids)) ins.run(id, id, `system/agents/${id}`, now, now);
+  }
+
+  function buildWorkRun({ companyId, nodes, edges }) {
+    ensureAgents(nodes);
+    const g = wdb.createWorkGraph({ companyId, nodes, edges });
+    expect(g.errors || []).toEqual([]);
+    const run = wdb.createRun({ graphKind: 'work', graphId: g.id, companyId, executionMode: 'manual' });
+    engine.markRunReady(run.id);
+    return { runId: run.id };
+  }
+
+  const nodeByName = (runId, name) => wdb.getRunState(runId).nodes.find((n) => n.name === name);
+
+  /** 把某个节点直接摁成「孤儿」的静止态：status=running + 指定的 started_at，不走任何转换。
+   *  这就是真实场景本身——进程被杀时节点行不会经过任何转换，就是停在这个样子。 */
+  function markAsOrphan(runId, nodeName, startedAtIso) {
+    const node = nodeByName(runId, nodeName);
+    wdb.getDb()
+      .prepare(`UPDATE graph_run_nodes SET status = 'running', started_at = ?, updated_at = ? WHERE id = ?`)
+      .run(startedAtIso, startedAtIso, node.id);
+    return node.id;
+  }
+
+  it('started_at 早于 cutoff 的 running 节点被判定为孤儿，走 infra_flake 原地重跑', () => {
+    const companyId = nextCompany();
+    const { runId } = buildWorkRun({ companyId, nodes: ['w'], edges: [] });
+    markAsOrphan(runId, 'w', '2020-01-01T00:00:00.000Z');
+
+    const result = engine.sweepOrphanedRunningNodes('2026-01-01T00:00:00.000Z');
+
+    expect(result.scanned).toBe(1);
+    expect(result.swept).toHaveLength(1);
+    expect(result.swept[0]).toMatchObject({ runId, infraRerun: true });
+    // infra_flake 的原地重跑：转回 ready，不烧 attempt（§四.D.2.1 末段既有语义）
+    const fresh = nodeByName(runId, 'w');
+    expect(fresh.status).toBe('ready');
+    expect(fresh.attempt).toBe(0);
+    // 不写回退记录、不加 run 级 backward_count —— infra_flake 分支的既有保证，孤儿清扫复用
+    // 的是同一条分支，这两条也该原样成立
+    expect(wdb.listLoopRecords(runId)).toHaveLength(0);
+    expect(wdb.getRun(runId).backward_count).toBe(0);
+  });
+
+  it('started_at 晚于 cutoff 的 running 节点不受影响（真的还在跑，不是孤儿）', () => {
+    const companyId = nextCompany();
+    const { runId } = buildWorkRun({ companyId, nodes: ['w'], edges: [] });
+    markAsOrphan(runId, 'w', '2026-06-01T00:00:00.000Z');
+
+    const result = engine.sweepOrphanedRunningNodes('2026-01-01T00:00:00.000Z');
+
+    expect(result.scanned).toBe(0);
+    expect(result.swept).toHaveLength(0);
+    expect(nodeByName(runId, 'w').status).toBe('running');
+  });
+
+  it('连续判定为孤儿超过 infra_flake 硬顶就转 blocked，不会无限原地重跑', () => {
+    const companyId = nextCompany();
+    const { runId } = buildWorkRun({ companyId, nodes: ['w'], edges: [] });
+
+    // 连续三次「摁成孤儿再扫」，模拟每次重启后又立刻被杀的极端情形
+    for (let i = 0; i < 3; i++) {
+      markAsOrphan(runId, 'w', '2020-01-01T00:00:00.000Z');
+      engine.sweepOrphanedRunningNodes('2026-01-01T00:00:00.000Z');
+    }
+    // 第四次撞硬顶（INFRA_FLAKE_HARD_CAP = 3），应改判 blocked 而不是继续 ready
+    markAsOrphan(runId, 'w', '2020-01-01T00:00:00.000Z');
+    engine.sweepOrphanedRunningNodes('2026-01-01T00:00:00.000Z');
+
+    expect(nodeByName(runId, 'w').status).toBe('blocked');
+  });
+
+  it('没有任何孤儿节点时是安静的 no-op', () => {
+    const companyId = nextCompany();
+    buildWorkRun({ companyId, nodes: ['w'], edges: [] }); // 节点是 ready，不是 running
+    const result = engine.sweepOrphanedRunningNodes('2026-01-01T00:00:00.000Z');
+    expect(result).toEqual({ scanned: 0, swept: [] });
+  });
+});
+/**
+ * Unit Tests — POST /api/graph-runs/:id/nodes/:nodeId/force-fail（42 号文档 Phase 1b）
+ *
+ * `retry` 端点只接受 status ∈ {fail, blocked} 的节点，管不到 'running'——真实运维/ceo 遇到
+ * "这个节点已经不可能再自己完成了"这种情形，此前唯一的恢复手段是直接调内部函数，绕过了
+ * 任何 REST 接口。这条测试钉住新端点的可用条件与转移语义，不重复测 routeFailure 内部选边
+ * 逻辑（那部分已经在 graph-engine.test.js / graph-engine-orphan-sweep.test.js 里覆盖过）。
+ *
+ * 走真入口：把 router 挂到真 express 上 listen(0) 再 fetch，与 graph-run-route-io.test.js 同法。
+ */
+import { describe, it, expect, beforeAll, afterAll } from 'vitest';
+import fs from 'fs';
+import os from 'os';
+import path from 'path';
+import express from 'express';
+
+const TEST_DB_PATH = '/tmp/test-graph-run-force-fail.sqlite';
+const DB_FILES = [TEST_DB_PATH, `${TEST_DB_PATH}-shm`, `${TEST_DB_PATH}-wal`];
+const MODULES = [
+  '../../services/graph-db',
+  '../../services/graph-service',
+  '../../services/org-graph-service',
+  '../../services/work-graph-db',
+  '../../services/company-paths',
+  '../../services/graph-run-sse',
+  '../../services/graph-engine',
+  '../../routes/graph-run',
+];
+
+describe('POST /api/graph-runs/:id/nodes/:nodeId/force-fail', () => {
+  let wdb;
+  let srv;
+  let base;
+  let runsDir;
+  let seq = 0;
+  // 每个用例一个独立 company：一家公司同时只有一条活跃 root run（run-slot 约束），
+  // 同一个 company 起第二条 run 会撞 RunSlotBusyError。
+  const nextCompany = () => `co-force-fail-${++seq}`;
+
+  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(), 'force-fail-runs-'));
+    process.env.GRAPH_RUNS_DIR = runsDir;
+    for (const m of MODULES) delete require.cache[require.resolve(m)];
+    wdb = require('../../services/work-graph-db');
+
+    const app = express();
+    app.use(express.json());
+    app.use('/api/graph-runs', require('../../routes/graph-run'));
+    await new Promise((resolve) => {
+      srv = app.listen(0, '127.0.0.1', () => {
+        base = `http://127.0.0.1:${srv.address().port}`;
+        resolve();
+      });
+    });
+  });
+
+  afterAll(async () => {
+    if (srv) await new Promise((r) => srv.close(r));
+    const { removeTestCompany } = require('../helpers/ensure-test-company');
+    for (let i = 1; i <= seq; i++) removeTestCompany(`co-force-fail-${i}`);
+    for (const f of DB_FILES) { try { fs.unlinkSync(f); } catch {} }
+    delete process.env.GRAPH_DB_PATH;
+    try { fs.rmSync(runsDir, { recursive: true, force: true }); } catch {}
+    delete process.env.GRAPH_RUNS_DIR;
+    for (const m of MODULES) delete require.cache[require.resolve(m)];
+  });
+
+  function ensureAgents(ids) {
+    const db = wdb.getDb();
+    const now = new Date().toISOString();
+    const ins = db.prepare(`
+      INSERT OR IGNORE INTO system_agents
+        (id, name, scope, owner_company_id, legacy_path, status, created_at, updated_at)
+      VALUES (?, ?, 'public', NULL, ?, 'active', ?, ?)
+    `);
+    for (const id of new Set(ids)) ins.run(id, id, `system/agents/${id}`, now, now);
+  }
+
+  /** 建一条只有一个节点的 work run，直接把节点摁成指定状态（不关心怎么走到这个状态，
+   *  只关心端点在这个状态下的行为——执行语义已经在别的测试文件覆盖过）。 */
+  function buildRunWithNodeStatus(status) {
+    const companyId = nextCompany();
+    require('../helpers/ensure-test-company').ensureTestCompany(companyId);
+    ensureAgents(['w']);
+    const g = wdb.createWorkGraph({ companyId, nodes: ['w'], edges: [] });
+    expect(g.errors || []).toEqual([]);
+    const run = wdb.createRun({ graphKind: 'work', graphId: g.id, companyId, executionMode: 'manual' });
+    require('../../services/graph-engine').markRunReady(run.id);
+    const node = wdb.getRunState(run.id).nodes[0];
+    const now = new Date().toISOString();
+    wdb.getDb()
+      .prepare(`UPDATE graph_run_nodes SET status = ?, started_at = ?, updated_at = ? WHERE id = ?`)
+      .run(status, now, now, node.id);
+    return { runId: run.id, nodeRunId: node.id };
+  }
+
+  it('running 节点调用成功，转 fail 后交给既有失败路由（无边可走 → blocked，可被 retry 接上）', async () => {
+    const { runId, nodeRunId } = buildRunWithNodeStatus('running');
+    const r = await fetch(`${base}/api/graph-runs/${runId}/nodes/${nodeRunId}/force-fail`, {
+      method: 'POST',
+      headers: { 'Content-Type': 'application/json' },
+      body: JSON.stringify({}),
+    });
+    expect(r.status).toBe(200);
+    const body = await r.json();
+    expect(body.ok).toBe(true);
+    // 单节点图没有 fail 边可走 → blockNode，落在人工可 retry 的终点
+    expect(body.nodeStatus).toBe('blocked');
+
+    // 验证确实接得上 retry 端点（这才是「可被 retry 端点接上」这条验收的真实含义）
+    const retryRes = await fetch(`${base}/api/graph-runs/${runId}/nodes/${nodeRunId}/retry`, { method: 'POST' });
+    expect(retryRes.status).toBe(200);
+    const retryBody = await retryRes.json();
+    expect(retryBody.ok).toBe(true);
+    expect(retryBody.nodeStatus).toBe('ready');
+  });
+
+  it('自定义 failReason 会原样落进 fail_reason（走常规选边，不是 infra_flake 特判）', async () => {
+    const { runId, nodeRunId } = buildRunWithNodeStatus('running');
+    const r = await fetch(`${base}/api/graph-runs/${runId}/nodes/${nodeRunId}/force-fail`, {
+      method: 'POST',
+      headers: { 'Content-Type': 'application/json' },
+      body: JSON.stringify({ failReason: 'stuck_no_progress' }),
+    });
+    expect(r.status).toBe(200);
+    // 单节点图没有 fail 边，无论什么 fail_reason 都落 blocked——这里只确认端点把自定义原因
+    // 传下去了没炸，选边逻辑本身已经在别处测过
+    const body = await r.json();
+    expect(body.ok).toBe(true);
+    expect(body.nodeStatus).toBe('blocked');
+  });
+
+  for (const status of ['fail', 'blocked', 'pending', 'ready', 'success']) {
+    it(`节点 status='${status}' 时调用返回 400（不是 running 就不该走这个端点）`, async () => {
+      const { runId, nodeRunId } = buildRunWithNodeStatus(status);
+      const r = await fetch(`${base}/api/graph-runs/${runId}/nodes/${nodeRunId}/force-fail`, {
+        method: 'POST',
+        headers: { 'Content-Type': 'application/json' },
+        body: JSON.stringify({}),
+      });
+      expect(r.status).toBe(400);
+      const body = await r.json();
+      expect(body.op).toBe('force-fail');
+      expect(body.nodeStatus).toBe(status);
+      expect(body.allowed).toEqual(['running']);
+    });
+  }
+
+  it('节点不存在返回 404', async () => {
+    const { runId } = buildRunWithNodeStatus('running');
+    const r = await fetch(`${base}/api/graph-runs/${runId}/nodes/nope/force-fail`, {
+      method: 'POST',
+      headers: { 'Content-Type': 'application/json' },
+      body: JSON.stringify({}),
+    });
+    expect(r.status).toBe(404);
+  });
+});
+/**
+ * Unit Tests — POST /api/graph-runs/phase-note（42 号文档 Phase 4）
+ *
+ * `bin/lemon.js task transition` 额外打这个端点，把 agent 的阶段流转（RESEARCH/PLAN/
+ * EXECUTE/VERIFY 之类）落进 timeline.ndjson——org-coder 等角色调 legacy 的
+ * `/api/agent/:agentId/task/transition` 时，work graph 节点场景下那个端点的 sessions
+ * Map 找不到会话，静默跳过；这条端点从 --artifact 路径本身（节点私有产物目录的既有形状
+ * `.../runs/{rootRunId}/nodes/{nodeRunId}/...`）解出两个 ID，不需要任何新的环境变量或
+ * agent.md 改动。
+ *
+ * 钉住的边界（39 号文档 §七.2 定案）：这条端点只追加 timeline，绝不碰
+ * graph_run_nodes/graph_runs 任何一行——不影响 needs/produces 契约、不影响 validator
+ * 判定依据。
+ *
+ * 走真入口：把 router 挂到真 express 上 listen(0) 再 fetch，与 graph-run-route-io.test.js 同法。
+ */
+import { describe, it, expect, beforeAll, afterAll } from 'vitest';
+import fs from 'fs';
+import os from 'os';
+import path from 'path';
+import express from 'express';
+
+const TEST_DB_PATH = '/tmp/test-graph-run-phase-note.sqlite';
+const DB_FILES = [TEST_DB_PATH, `${TEST_DB_PATH}-shm`, `${TEST_DB_PATH}-wal`];
+const MODULES = [
+  '../../services/graph-db',
+  '../../services/graph-service',
+  '../../services/org-graph-service',
+  '../../services/work-graph-db',
+  '../../services/company-paths',
+  '../../services/graph-run-sse',
+  '../../services/graph-engine',
+  '../../routes/graph-run',
+];
+
+describe('POST /api/graph-runs/phase-note', () => {
+  let wdb;
+  let sse;
+  let srv;
+  let base;
+  let runsDir;
+  const companyId = 'co-phase-note';
+
+  beforeAll(async () => {
+    require('../helpers/ensure-test-company').ensureTestCompany(companyId);
+    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(), 'phase-note-runs-'));
+    process.env.GRAPH_RUNS_DIR = runsDir;
+    for (const m of MODULES) delete require.cache[require.resolve(m)];
+    wdb = require('../../services/work-graph-db');
+    sse = require('../../services/graph-run-sse');
+
+    const app = express();
+    app.use(express.json());
+    app.use('/api/graph-runs', require('../../routes/graph-run'));
+    await new Promise((resolve) => {
+      srv = app.listen(0, '127.0.0.1', () => {
+        base = `http://127.0.0.1:${srv.address().port}`;
+        resolve();
+      });
+    });
+  });
+
+  afterAll(async () => {
+    if (srv) await new Promise((r) => srv.close(r));
+    require('../helpers/ensure-test-company').removeTestCompany(companyId);
+    for (const f of DB_FILES) { try { fs.unlinkSync(f); } catch {} }
+    try { fs.rmSync(runsDir, { recursive: true, force: true }); } catch {}
+    delete process.env.GRAPH_DB_PATH;
+    delete process.env.GRAPH_RUNS_DIR;
+    for (const m of MODULES) delete require.cache[require.resolve(m)];
+  });
+
+  function ensureAgents(ids) {
+    const db = wdb.getDb();
+    const now = new Date().toISOString();
+    const ins = db.prepare(`
+      INSERT OR IGNORE INTO system_agents
+        (id, name, scope, owner_company_id, legacy_path, status, created_at, updated_at)
+      VALUES (?, ?, 'public', NULL, ?, 'active', ?, ?)
+    `);
+    for (const id of new Set(ids)) ins.run(id, id, `system/agents/${id}`, now, now);
+  }
+
+  function makeRun() {
+    ensureAgents(['org-coder']);
+    const g = wdb.createWorkGraph({ companyId, nodes: ['org-coder'], edges: [] });
+    expect(g.errors || []).toEqual([]);
+    const run = wdb.createRun({ graphKind: 'work', graphId: g.id, companyId, executionMode: 'manual' });
+    require('../../services/graph-engine').markRunReady(run.id);
+    const node = wdb.getRunState(run.id).nodes[0];
+    return { runId: run.id, nodeRunId: node.id };
+  }
+
+  async function post(body) {
+    const r = await fetch(`${base}/api/graph-runs/phase-note`, {
+      method: 'POST',
+      headers: { 'Content-Type': 'application/json' },
+      body: JSON.stringify(body),
+    });
+    return [r.status, await r.json()];
+  }
+
+  it('合法的节点产物路径 → 写进 timeline.ndjson，节点状态不受影响', async () => {
+    const { runId, nodeRunId } = makeRun();
+    const beforeStatus = wdb.getRunState(runId).nodes[0].status;
+    const artifact = `/Users/x/lemonboss/data/companies/${companyId}/runs/${runId}/nodes/${nodeRunId}/_plan.md`;
+
+    const [status, body] = await post({ artifact, phase: 'plan', agentId: `${companyId}:org-coder` });
+    expect(status).toBe(200);
+    expect(body.ok).toBe(true);
+    expect(body.rootRunId).toBe(runId);
+    expect(body.nodeRunId).toBe(nodeRunId);
+
+    // timeline.ndjson 里真的能查到这条记录
+    const raw = fs.readFileSync(sse.timelinePath(runId), 'utf8');
+    const lines = raw.trim().split('\n').map((l) => JSON.parse(l));
+    const mine = lines.find((l) => l.kind === 'agent.phase' && l.ref === nodeRunId);
+    expect(mine).toBeTruthy();
+    expect(mine.payload.phase).toBe('plan');
+    expect(mine.payload.artifact).toBe(artifact);
+    expect(mine.payload.agentId).toBe(`${companyId}:org-coder`);
+    expect(mine.root_run_id).toBe(runId);
+
+    // 不改契约面：节点状态原样，没有因为这条追加日志被结算或改动
+    expect(wdb.getRunState(runId).nodes[0].status).toBe(beforeStatus);
+  });
+
+  it('artifact 路径不是节点产物目录形状（legacy 会话式 agent 的调用） → ok:false，安静跳过', async () => {
+    const [status, body] = await post({
+      artifact: '/Users/x/lemonboss/system/agents/some-agent/co1/task-abc/_plan.md',
+      phase: 'plan',
+      agentId: 'co1:some-agent',
+    });
+    expect(status).toBe(200);
+    expect(body.ok).toBe(false);
+    expect(body.reason).toBe('not-a-graph-artifact');
+  });
+
+  it('artifact 路径形状对，但 rootRunId 不对应真实存在的 run → ok:false', async () => {
+    const [status, body] = await post({
+      artifact: `/Users/x/lemonboss/data/companies/${companyId}/runs/run_does_not_exist/nodes/rn_does_not_exist/_plan.md`,
+      phase: 'plan',
+    });
+    expect(status).toBe(200);
+    expect(body.ok).toBe(false);
+    expect(body.reason).toBe('not-a-graph-artifact');
+  });
+
+  it('没传 artifact → ok:false，reason:no-artifact', async () => {
+    const [status, body] = await post({ phase: 'plan' });
+    expect(status).toBe(200);
+    expect(body.ok).toBe(false);
+    expect(body.reason).toBe('no-artifact');
+  });
+});
@@ -3,7 +3,7 @@
 ## 你是谁
 你是 **dream** 这套「经验汇流」机制里的**提炼**一环，本体名 `dream-distiller`。
-设计见 [29-DREAM](../../../../../docs/todo/system-design/29-dream-design.md)。
+设计见 [29-DREAM](../../../../../docs/done/system-design/29-dream-design.md)。
 dream 每天跑一次，把**某一个 agent 在所有公司**的原始记录整理成
 **不含任何公司特定信息**的可复用经验，沉淀到那个 agent 的本体上。
@@ -3,7 +3,7 @@
 ## 你是谁
 你是 **dream** 这套「经验汇流」机制里的**闸门**，本体名 `dream-screener`。
-设计见 [29-DREAM](../../../../../docs/todo/system-design/29-dream-design.md) 决策 A。
+设计见 [29-DREAM](../../../../../docs/done/system-design/29-dream-design.md) 决策 A。
 `dream-distiller` 把某个 agent 在各家公司的原始记录提炼成一条条「经验」，
 你逐条判断：**这条能不能给别家公司看。**
@@ -3,7 +3,7 @@
 > 本版本为 Evolve 训练产出（v1，首次训练）。基线为生产版 `system/agents/sdd-planning/agent.md`，
 > 仅强化「接口契约」「数据形态」两类的执行深度指导，其余框架（五类东西结构、
 > `contract.json`/`attempt-{n}.json` 模板、越权判断）与基线一致，未重写。
-> 训练依据：`../hunt/knowhow_v1.md` + `../digest/benchmark_v1.md`（D2 判据可独立复现性，权重30+封顶）。
+> 训练依据：`train/hunt/knowhow_v1.md` + `train/digest/benchmark_v1.md`（D2 判据可独立复现性，权重30+封顶）。
 ## 身份定位
@@ -126,11 +126,17 @@ ls data/companies/&lt;公司ID&gt;/agents/
 （或写成一个 `.json` 文件、在回复里给出**绝对路径**），引擎自己取出来校验 + 落库。
 ```json
-{"nodes":[{"nodeName":"org-coder-impl","systemAgentId":"coder"},{"nodeName":"org-coder-test","systemAgentId":"unit-tester"},{"nodeName":"org-coder-validator","systemAgentId":"coder-validator"}],"edges":[{"from":"org-coder-impl","to":"org-coder-test","condition":"success","produces":["artifact"]},{"from":"org-coder-test","to":"org-coder-validator","condition":"success","produces":["log"],"needs":["artifact"]},{"from":"org-coder-test","to":"org-coder-impl","condition":"fail","edgeKind":"backward"},{"from":"org-coder-validator","to":"org-coder-impl","condition":"fail","edgeKind":"backward"}]}
+{"nodes":[{"nodeName":"org-coder-impl","systemAgentId":"coder"},{"nodeName":"org-coder-test","systemAgentId":"unit-tester"},{"nodeName":"org-coder-validator","systemAgentId":"coder-validator"}],"edges":[{"from":"org-coder-impl","to":"org-coder-test","condition":"success","produces":["artifact"]},{"from":"org-coder-test","to":"org-coder-validator","condition":"success","produces":[{"kind":"log","required":false}],"needs":["artifact"]},{"from":"org-coder-test","to":"org-coder-impl","condition":"fail","edgeKind":"backward"},{"from":"org-coder-validator","to":"org-coder-impl","condition":"fail","edgeKind":"backward"}]}
 ```
 > `produces` / `needs` 就是 §6bis 那两个键。**forward 边上少了它们，下游节点的提示词里
 > 就没有上游产物的路径** —— 先读 §6bis 再写这份 JSON。
+>
+> `"kind":"log"` 必须写成 `{"kind":"log","required":false}` 这个对象形式，不能简写成
+> `["log"]`（33 号文档 + snakegame-co T-mtfh2kuf-7c31 两次真实事故）：test/integration
+> 类节点从不产出一个能被引擎认作 `kind='log'` 的文件（落盘的是 coder.log/test.log，
+> 全被归到 `kind='artifact'`），required 的 log 契约会永远无法满足，把节点卡进
+> missing_required_input 死循环。
 引擎取图的死规矩（完整版在 `agent.md` Step 7）：**严格 JSON**（注释 / 尾逗号 / 省略号一律解析失败，
 整块当没写）· 顶层要有 **`nodes` 数组** · 文件路径必须**绝对** ·
@@ -214,10 +214,12 @@ const waves = computed(() =&gt; {
     for (const id of wave) remaining.delete(id);
     out.push(wave);
   }
-  if (remaining.size) out.push([...remaining]);  // 兜底：环里的节点单独摆一列，别让它们消失
+  if (remaining.size) out.push([...remaining]);  // 兜底：环里的节点单独摆一行，别让它们消失
   return out;
 });
+// 布局方向：wave（依赖深度）走 y 轴自上而下，同波内的并行节点走 x 轴左右排开——
+// 节点一多，从左到右排会把屏幕撑成很宽的 4 栏，改成自上而下更贴合竖直滚动的画布容器。
 const laidOut = computed(() => {
   const byId = new Map(props.nodes.map((n) => [String(n.defNodeId), n]));
   const out = [];
@@ -231,8 +233,8 @@ const laidOut = computed(() =&gt; {
         status: n.status || 'pending',
         nodeKind: n.nodeKind,
         attempt: n.attempt || 0,
-        x: PAD + wi * (NW + GAP_X),
-        y: PAD + ni * (NH + GAP_Y),
+        x: PAD + ni * (NW + GAP_X),
+        y: PAD + wi * (NH + GAP_Y),
       });
     });
   });
@@ -255,16 +257,16 @@ const forwardEdges = computed(() =&gt;
         + (cond === 'fail' ? `｜fail_reason=${e.failReason || '（兜底边：任何未匹配的失败）'}` : '')
         // 这条边传的是什么（graph_edge_contracts）。悬停在线上就能看全，不占布局
         + (c ? `｜数据契约 ${c.title}（? = 可选）` : ''),
-      x1: a.x + NW, y1: a.y + NH / 2,
-      x2: b.x, y2: b.y + NH / 2,
+      x1: a.x + NW / 2, y1: a.y + NH,
+      x2: b.x + NW / 2, y2: b.y,
       contract: c,
     }];
   }),
 );
 /**
- * 契约药丸的位置 = 边的中点（两列之间的空白带），宽度按字数估。
- * kind 名最长按 7 字符截断（`acceptance` → `accepta…`）：GAP_X 只有 52px，
+ * 契约药丸的位置 = 边的中点（两行之间的空白带），宽度按字数估。
+ * kind 名最长按 7 字符截断（`acceptance` → `accepta…`）：药丸宽度封顶到节点列宽，
  * 不截会盖到相邻节点上——完整名字在 <title> 里。
  */
 const contractPills = computed(() =>
@@ -278,7 +280,8 @@ const contractPills = computed(() =&gt;
         key: e.key,
         x: (e.x1 + e.x2) / 2,
         y: (e.y1 + e.y2) / 2,
-        w: Math.min(GAP_X + 10, text.length * 5.9 + 12),
+        // 边现在竖着走（同列上下相邻），药丸宽度受节点列宽约束，不再是 GAP_X
+        w: Math.min(NW - 16, text.length * 5.9 + 12),
         text,
         title: `数据契约：${e.contract.title}（? = 可选输入，缺了不算错）`,
         optionalOnly: e.contract.optionalOnly,
@@ -290,12 +293,12 @@ const contractPills = computed(() =&gt;
  * backward 边的曲线路由（§八.5 点名的「真实手写前端工程量」）。
  *
  * 重叠问题拆成两半，各用一招解决，不引图形库：
- *   ① 与节点重叠 —— 回退边一律走**节点带下方**的空白区，起终点都取节点底边中点，
- *      三次贝塞尔两个控制点都压在同一条泳道高度上 → 曲线永远不穿过任何节点矩形；
- *   ② 与其它回退边重叠 —— 按 x 区间做贪心分道（区间重叠的边必然分到不同泳道），
- *      泳道纵向拉开 LANE_H，画布高度随泳道数增长。区间不重叠的边共用一道，不浪费高度。
- * 代价：泳道数 = 最大同时重叠的回退边数，多到十几条时画布会明显变高；
- * 升级路径是改成上下双侧分流（奇偶道走节点带上方），本版不做。
+ *   ① 与节点重叠 —— 回退边一律走**节点带右侧**的空白区，起终点都取节点右边中点，
+ *      三次贝塞尔两个控制点都压在同一条泳道横坐标上 → 曲线永远不穿过任何节点矩形；
+ *   ② 与其它回退边重叠 —— 按 y 区间做贪心分道（区间重叠的边必然分到不同泳道），
+ *      泳道横向拉开 LANE_H，画布宽度随泳道数增长。区间不重叠的边共用一道，不浪费宽度。
+ * 代价：泳道数 = 最大同时重叠的回退边数，多到十几条时画布会明显变宽；
+ * 升级路径是改成左右双侧分流（奇偶道走节点带左侧），本版不做。
  */
 const backwardEdges = computed(() => {
   const raw = [];
@@ -304,13 +307,13 @@ const backwardEdges = computed(() =&gt; {
     const a = posById.value.get(String(e.from));
     const b = posById.value.get(String(e.to));
     if (!a || !b) return;
-    const sx = a.x + NW / 2, sy = a.y + NH;
-    const tx = b.x + NW / 2, ty = b.y + NH;
+    const sx = a.x + NW, sy = a.y + NH / 2;
+    const tx = b.x + NW, ty = b.y + NH / 2;
     raw.push({ key: e.id || `${e.from}-${e.to}-${i}`, edgeId: e.id, sx, sy, tx, ty,
-      lo: Math.min(sx, tx), hi: Math.max(sx, tx) });
+      lo: Math.min(sy, ty), hi: Math.max(sy, ty) });
   });
-  // 贪心分道：按区间左端排序，塞进第一条不与已占区间重叠的泳道
+  // 贪心分道：按区间上端排序，塞进第一条不与已占区间重叠的泳道
   const lanes = [];
   raw.sort((p, q) => p.lo - q.lo);
   for (const e of raw) {
@@ -321,13 +324,13 @@ const backwardEdges = computed(() =&gt; {
   }
   return raw.map((e) => {
-    const laneY = nodeBandH.value + PAD + (e.lane + 1) * LANE_H;
+    const laneX = nodeBandW.value + PAD + (e.lane + 1) * LANE_H;
     return {
       ...e,
-      d: `M${e.sx},${e.sy} C${e.sx},${laneY} ${e.tx},${laneY} ${e.tx},${e.ty}`,
-      // 三次贝塞尔 t=0.5 处的坐标（两个控制点同 y，纵向化简为 (sy+ty+6*laneY)/8）
-      mx: (e.sx + e.tx) / 2,
-      my: (e.sy + e.ty + 6 * laneY) / 8,
+      d: `M${e.sx},${e.sy} C${laneX},${e.sy} ${laneX},${e.ty} ${e.tx},${e.ty}`,
+      // 三次贝塞尔 t=0.5 处的坐标（两个控制点同 x，横向化简为 (sx+tx+6*laneX)/8）
+      mx: (e.sx + e.tx + 6 * laneX) / 8,
+      my: (e.sy + e.ty) / 2,
       loopCount: latestLoopCount(e.edgeId),
     };
   });
@@ -350,21 +353,21 @@ const anomalyNodes = computed(() =&gt; laidOut.value.filter((n) =&gt; n.status === &#39;bl
 const anomalyBand = computed(() => {
   if (!backwardEdges.value.length) return null;
   return {
-    x: PAD / 2,
-    y: nodeBandH.value + PAD / 2,
-    w: W.value - PAD,
-    h: laneCount.value * LANE_H + LANE_H / 2,
+    x: nodeBandW.value + PAD / 2,
+    y: PAD / 2,
+    w: laneCount.value * LANE_H + LANE_H / 2,
+    h: H.value - PAD,
   };
 });
-const nodeBandH = computed(() => {
+const nodeBandW = computed(() => {
   const maxRow = Math.max(...waves.value.map((w) => w.length), 1);
-  return PAD + maxRow * (NH + GAP_Y) - GAP_Y;
+  return PAD + maxRow * (NW + GAP_X) - GAP_X;
 });
-const W = computed(() =>
-  Math.max(320, PAD * 2 + Math.max(waves.value.length, 1) * (NW + GAP_X) - GAP_X));
-const H = computed(() => nodeBandH.value + PAD + laneCount.value * LANE_H + (laneCount.value ? LANE_H : 0));
+const W = computed(() => nodeBandW.value + PAD + laneCount.value * LANE_H + (laneCount.value ? LANE_H : 0));
+const H = computed(() =>
+  Math.max(320, PAD * 2 + Math.max(waves.value.length, 1) * (NH + GAP_Y) - GAP_Y));
 function trim(s) {
   const str = String(s ?? '');
@@ -28,6 +28,7 @@
       <button class="btn"       :disabled="busy || !can('pause')"  @click="act('pause')">⏸ 暂停</button>
       <button class="btn"       :disabled="busy || !can('stop')"   @click="act('stop')">⏹ 停止</button>
       <button class="btn retry" :disabled="busy || !canRetry"      @click="onRetry">🔁 重试</button>
+      <button class="btn budget" :disabled="busy || !canExtendBudget" @click="openBudgetModal">💰 追加预算</button>
       <span v-if="nextNodes.length === 1" class="next-hint">下一步将执行 <code>{{ nextNode.name || nextNode.defNodeId }}</code></span>
       <span v-else-if="nextNodes.length > 1" class="next-hint">自动模式下一批最多并发 <code>{{ nextNodes.length }}</code> 个：
         <code v-for="n in nextNodes" :key="n.defNodeId">{{ n.name || n.defNodeId }}</code></span>
@@ -67,6 +68,35 @@
         </div>
       </div>
     </div>
+
+    <!-- 追加预算：撞顶（尤其是墙钟）之前只能开发者工具手搓 fetch 调 POST /:id/budget，
+         界面上没有入口。三维各自是**增量**（叠加在当前上限上，不是替换），
+         留空的维度不追加——后端 extendBudget 本来就是这个语义（§四.C）。 -->
+    <div v-if="showBudgetModal" class="modal-back" @click.self="showBudgetModal = false">
+      <div class="modal">
+        <h3>追加预算</h3>
+        <p class="lead">这条 run 已经 blocked。三个维度都是往当前上限上加，留空 = 不追加那一维。</p>
+        <ul class="est" v-if="budget">
+          <li>当前剩余：<b>{{ remain.calls }}</b> 次调用 · <b>{{ fmtNum(remain.tokens) }}</b> tokens</li>
+        </ul>
+        <label class="budget-field">墙钟时长（小时）
+          <input type="number" min="0" step="1" v-model.number="budgetForm.hours" placeholder="例如 8" />
+        </label>
+        <label class="budget-field">调用次数
+          <input type="number" min="0" step="1" v-model.number="budgetForm.calls" placeholder="留空不追加" />
+        </label>
+        <label class="budget-field">tokens
+          <input type="number" min="0" step="1" v-model.number="budgetForm.tokens" placeholder="留空不追加" />
+        </label>
+        <label class="budget-resume">
+          <input type="checkbox" v-model="budgetForm.resume" /> 追加后立即启动（沿用当前的 手动/自动 选择）
+        </label>
+        <div class="modal-btns">
+          <button class="btn" @click="showBudgetModal = false">取消</button>
+          <button class="btn go" :disabled="!budgetHasAnyDelta" @click="submitBudget">追加</button>
+        </div>
+      </div>
+    </div>
   </div>
 </template>
@@ -116,6 +146,8 @@ const err = ref(&#39;&#39;);
 const notice = ref('');
 const mode = ref('manual');
 const confirmAuto = ref(false);
+const showBudgetModal = ref(false);
+const budgetForm = ref({ hours: 8, calls: '', tokens: '', resume: true });
 const sseStatus = ref('idle');
 let es = null;
@@ -138,6 +170,14 @@ const nextNodes = computed(() =&gt; {
 const nextNode = computed(() => nextNodes.value[0] || null); // 手动模式「下一步」提示仍用单数
 const selectedNode = computed(() => nodes.value.find((n) => String(n.defNodeId) === selectedDefId.value) || null);
 const canRetry = computed(() => selectedNode.value && ['fail', 'blocked'].includes(selectedNode.value.status));
+// 与后端 ensureStatus 同一张表（§四.C）：/budget 只在 run_status='blocked' 时可用；
+// budget 为 null 说明这一层不是挂预算的 root run（扣减与熔断只在 root run 上生效），
+// 追加了也没有意义，按钮直接不亮
+const canExtendBudget = computed(() => !!budget.value && run.value?.run_status === 'blocked');
+const budgetHasAnyDelta = computed(() => {
+  const f = budgetForm.value;
+  return [f.hours, f.calls, f.tokens].some((v) => Number(v) > 0);
+});
 const remain = computed(() => {
   const b = budget.value || {};
@@ -277,6 +317,21 @@ function onStart() {
 }
 function onRetry() { if (canRetry.value) act('retry'); }
+function openBudgetModal() {
+  budgetForm.value = { hours: 8, calls: '', tokens: '', resume: true };
+  showBudgetModal.value = true;
+}
+function submitBudget() {
+  const f = budgetForm.value;
+  const patch = {};
+  if (Number(f.hours) > 0) patch.wallclock_ms = Number(f.hours) * 3600 * 1000;
+  if (Number(f.calls) > 0) patch.total_agent_calls = Number(f.calls);
+  if (Number(f.tokens) > 0) patch.total_tokens = Number(f.tokens);
+  patch.resume = !!f.resume;
+  showBudgetModal.value = false;
+  act('budget', patch);
+}
+
 function onSelect(node) {
   selectedDefId.value = String(node.defNodeId);
   emit('select', node);
@@ -374,6 +429,7 @@ function fmtNum(n) { return (n || 0).toLocaleString(); }
 .btn:disabled { opacity:.4; cursor:not-allowed; }
 .btn.go { background:#1a7f37; border-color:#1a7f37; color:#fff; }
 .btn.retry { border-color:#c96a00; color:#c96a00; }
+.btn.budget { border-color:#8a5cd6; color:#8a5cd6; }
 .next-hint { font-size:11px; color:#666; }
 .next-hint code { background:#eef4ff; padding:1px 5px; border-radius:3px; }
 .notice { color: var(--text-secondary); background: var(--bg-overlay); border: 1px dashed var(--border-primary);
@@ -389,4 +445,7 @@ function fmtNum(n) { return (n || 0).toLocaleString(); }
 .est { font-size:12.5px; color:#444; padding-left:18px; margin:0 0 16px; }
 .est li { margin-bottom:4px; }
 .modal-btns { display:flex; justify-content:flex-end; gap:8px; }
+.budget-field { display:flex; align-items:center; justify-content:space-between; gap:10px; font-size:12.5px; color:#444; margin-bottom:8px; }
+.budget-field input { width:140px; font-size:12.5px; padding:3px 6px; border:1px solid #ddd; border-radius:4px; }
+.budget-resume { display:flex; align-items:center; gap:6px; font-size:12.5px; color:#444; margin:4px 0 14px; }
 </style>
+<!--
+  任务详情/新建弹窗 —— TaskTable.vue 专用。`task` 为 null 时是新建模式。
+
+  增删改查落地方式：
+  - 读：`task` prop 本身就是 taskView() 的完整形状，摊平自 TaskBoard 已经拉好的 goals 树，
+    不再单独请求（后端目前也没有单任务 GET 端点）。
+  - 改：PATCH /:cid/tasks/:taskId（title/priority 随时可改；description/mode 在 queuedAt
+    非空后会被服务端 409 拒绝，这里提前禁用输入框并给出同样的理由）。
+  - 增：POST /:cid/tasks，固定带 draft:true —— 先建草稿，不自动派发。
+  - 删：DELETE /:cid/tasks/:taskId（归档，运行中/排队中会 409，错误原样显示）。
+  - 状态流转（下达/开始/取消/重跑/强制放行/停止）：`taskActions()` 给可执行操作，
+    这里的 runAction() 是 GoalTaskPane.vue 的 runTaskAction() 的等价物，端点表照抄不重新设计。
+-->
+<template>
+  <div class="overlay" @click.self="$emit('close')">
+    <div class="modal">
+      <header class="head">
+        <b>{{ isCreate ? '新建任务' : '任务详情' }}</b>
+        <button class="x" @click="$emit('close')">×</button>
+      </header>
+
+      <div class="body">
+        <template v-if="!isCreate">
+          <div class="row">
+            <span class="dot" :style="dotStyle(taskStyle(task.status))"></span>
+            {{ taskStyle(task.status).label }}
+            <span v-if="queueBadge(task)" class="qb" :title="queueBadge(task).title">{{ queueBadge(task).text }}</span>
+            <span class="tid">{{ task.taskId }}</span>
+          </div>
+          <p v-if="task.status === 'blocked'" class="blocked-hint">{{ blockedLabel(task) || '挂起，原因未知' }}</p>
+        </template>
+
+        <label class="field">
+          <span class="lbl">标题</span>
+          <input v-model="form.title" class="in" :placeholder="isCreate ? '（留空则用描述自动生成）' : ''" />
+        </label>
+
+        <label class="field">
+          <span class="lbl">任务描述{{ frozen ? '（已下达，不可改）' : '' }}</span>
+          <textarea v-model="form.description" class="in ta" rows="4" :disabled="frozen"
+            placeholder="要交给 agent 执行的完整描述"></textarea>
+        </label>
+
+        <div class="grid2">
+          <label class="field">
+            <span class="lbl">优先级</span>
+            <input v-model="form.priority" class="in" placeholder="P1" />
+          </label>
+          <label class="field">
+            <span class="lbl">执行模式{{ frozen ? '（已下达，不可改）' : '' }}</span>
+            <select v-model="form.mode" class="in" :disabled="frozen">
+              <option value="manual">manual（需人点「立即开始」）</option>
+              <option value="auto">auto（有空位自动开跑）</option>
+            </select>
+          </label>
+        </div>
+
+        <label v-if="isCreate" class="field">
+          <span class="lbl">所属目标</span>
+          <select v-model="form.goalId" class="in">
+            <option value="">（自动新建一个同名目标）</option>
+            <option v-for="g in goals" :key="g.goalId" :value="g.goalId">{{ g.title || g.goalId }}</option>
+          </select>
+        </label>
+
+        <template v-if="!isCreate">
+          <div class="grid2">
+            <div class="field ro"><span class="lbl">所属目标</span><span>{{ goalTitle }}</span></div>
+            <div class="field ro"><span class="lbl">负责 Agent</span><span>{{ assigneeLabel }}</span></div>
+          </div>
+          <div class="grid2">
+            <div class="field ro"><span class="lbl">创建时间</span><span>{{ fmt(task.createdAt) }}</span></div>
+            <div class="field ro"><span class="lbl">下达时间</span><span>{{ fmt(task.queuedAt) }}</span></div>
+          </div>
+          <div class="grid2">
+            <div class="field ro"><span class="lbl">开始时间</span><span>{{ fmt(task.startedAt) }}</span></div>
+            <div class="field ro"><span class="lbl">结束时间</span><span>{{ fmt(task.finishedAt) }}</span></div>
+          </div>
+          <div v-if="task.dependsOn && task.dependsOn.length" class="field ro">
+            <span class="lbl">依赖任务</span>
+            <span>{{ task.dependsOn.join('、') }}</span>
+          </div>
+          <div v-if="task.budget" class="field ro">
+            <span class="lbl">预算</span>
+            <span class="mono">{{ JSON.stringify(task.budget) }}</span>
+          </div>
+          <router-link class="graph-link" :to="`/${companyId}/graph-console?goal=${task.goalId}&task=${task.taskId}`">
+            🕸️ 查看执行图
+          </router-link>
+        </template>
+
+        <p v-if="error" class="err">{{ error }}</p>
+      </div>
+
+      <footer class="foot">
+        <div class="actions" v-if="!isCreate">
+          <button v-if="task.status === 'draft'" class="btn" :disabled="busy" @click="enqueue">下达</button>
+          <button
+            v-for="act in actions" :key="act.key"
+            class="btn" :class="{ danger: act.danger }"
+            :disabled="act.disabled || busy" :title="act.title"
+            @click="runAction(act)"
+          >{{ act.label }}</button>
+        </div>
+        <div class="spacer"></div>
+        <button class="btn ghost" @click="$emit('close')">取消</button>
+        <button class="btn primary" :disabled="busy || !form.description.trim()" @click="save">
+          {{ isCreate ? '创建' : '保存' }}
+        </button>
+      </footer>
+    </div>
+  </div>
+</template>
+
+<script setup>
+import { ref, reactive, computed } from 'vue';
+import {
+  taskStyle, queueBadge, blockedLabel, taskActions, parseBlockedReason,
+} from '../graph-console/goal-task-model.js';
+
+const props = defineProps({
+  companyId: { type: String, required: true },
+  task: { type: Object, default: null },
+  goals: { type: Array, default: () => [] },
+  agents: { type: Array, default: () => [] },
+});
+const emit = defineEmits(['close', 'saved']);
+
+const isCreate = computed(() => !props.task);
+/** 已经下达过（queuedAt 非空）：description/mode 服务端会 409，界面提前禁用 */
+const frozen = computed(() => !isCreate.value && !!props.task.queuedAt);
+
+const form = reactive({
+  title: props.task?.title || '',
+  description: props.task?.description || '',
+  priority: props.task?.priority || 'P1',
+  mode: props.task?.mode || 'manual',
+  goalId: '',
+});
+
+const goalTitle = computed(() => {
+  const t = props.task;
+  if (!t) return '';
+  const g = (props.goals || []).find((x) => x.goalId === t.goalId);
+  return (g && g.title) || t.goalId;
+});
+
+const assigneeLabel = computed(() => {
+  const t = props.task;
+  if (!t || !t.assigneeAgentId) return '未分配';
+  if (t.assigneeAgentId === 'org-graph') return '组织图执行';
+  const a = (props.agents || []).find((x) => x.id === t.assigneeAgentId);
+  return (a && a.name) || t.assigneeAgentId;
+});
+
+const actions = computed(() => (props.task ? taskActions(props.task) : []));
+
+const busy = ref(false);
+const error = ref('');
+
+async function call(method, url, body) {
+  const r = await fetch(url, {
+    method,
+    headers: body === undefined ? undefined : { 'Content-Type': 'application/json' },
+    body: body === undefined ? undefined : JSON.stringify(body),
+  });
+  const d = await r.json().catch(() => ({}));
+  if (!r.ok) throw new Error([d.error || `HTTP ${r.status}`, d.hint].filter(Boolean).join(' · '));
+  return d;
+}
+
+async function guarded(fn) {
+  if (busy.value) return;
+  busy.value = true;
+  error.value = '';
+  try {
+    await fn();
+    emit('saved');
+  } catch (e) {
+    error.value = e.message;
+  } finally {
+    busy.value = false;
+  }
+}
+
+function save() {
+  const cid = props.companyId;
+  if (isCreate.value) {
+    return guarded(() => call('POST', `/api/company/${cid}/tasks`, {
+      task: form.description.trim(),
+      goal_id: form.goalId || undefined,
+      priority: form.priority || undefined,
+      mode: form.mode,
+      draft: true,
+    }));
+  }
+  const patch = { title: form.title, priority: form.priority };
+  if (!frozen.value) {
+    patch.description = form.description;
+    patch.mode = form.mode;
+  }
+  return guarded(() => call('PATCH', `/api/company/${cid}/tasks/${props.task.taskId}`, patch));
+}
+
+function enqueue() {
+  return guarded(() => call('POST', `/api/company/${props.companyId}/tasks/${props.task.taskId}/enqueue`));
+}
+
+/** taskActions() 给的 key → 具体端点，逐条抄自 GoalTaskPane.vue 的 runTaskAction */
+function runAction(act) {
+  if (act.disabled || busy.value) return;
+  const cid = props.companyId;
+  const t = props.task;
+  return guarded(async () => {
+    if (act.key === 'stop') {
+      await call('POST', `/api/graph-runs/${t.runId}/stop`);
+      return;
+    }
+    if (act.key === 'release') {
+      const p = parseBlockedReason(t.blockedReason);
+      const deps = t.dependsOn || [];
+      const next = deps.filter((id) => id !== (p && p.upstreamId));
+      if (next.length === deps.length) {
+        throw new Error(`放行失败：blocked 原因指向 ${p && p.upstreamId}，但这条任务的依赖里没有它（依赖刚被改过？刷新再看）`);
+      }
+      await call('PATCH', `/api/company/${cid}/tasks/${t.taskId}`, { depends_on: next });
+      return;
+    }
+    if (act.key === 'start') {
+      await call('POST', `/api/company/${cid}/tasks/${t.taskId}/start`);
+      return;
+    }
+    if (act.key === 'cancel') {
+      await call('POST', `/api/company/${cid}/tasks/${t.taskId}/cancel`);
+      return;
+    }
+    if (act.key === 'rerun') {
+      await call('POST', `/api/company/${cid}/tasks/${t.taskId}/rerun`);
+      return;
+    }
+    if (act.key === 'rerun-upstream') {
+      if (!act.upstreamId) throw new Error('这条任务的 blocked 原因里没有上游 id，重跑不了');
+      await call('POST', `/api/company/${cid}/tasks/${act.upstreamId}/rerun`);
+      return;
+    }
+    // archive —— 归档后这条 task 会从 goals 树里消失，父组件在 @saved 里发现找不到就会关掉弹窗
+    await call('DELETE', `/api/company/${cid}/tasks/${t.taskId}`);
+  });
+}
+
+function dotStyle(s) {
+  return s.hollow ? { background: 'transparent', borderColor: s.color } : { background: s.color, borderColor: s.color };
+}
+function fmt(iso) {
+  if (!iso) return '—';
+  try { return new Date(iso).toLocaleString('zh-CN'); } catch { return iso; }
+}
+</script>
+
+<style scoped>
+.overlay { position: fixed; inset: 0; background: rgba(0,0,0,.35); display: flex; align-items: center; justify-content: center; z-index: 100; }
+.modal { width: min(560px, 92vw); max-height: 88vh; display: flex; flex-direction: column; background: #fff; border-radius: 10px; box-shadow: 0 10px 40px rgba(0,0,0,.2); }
+
+.head { display: flex; align-items: center; justify-content: space-between; padding: 14px 16px; border-bottom: 1px solid #eee; }
+.head b { font-size: 14px; }
+.x { border: none; background: none; font-size: 18px; cursor: pointer; color: #999; line-height: 1; }
+.x:hover { color: #333; }
+
+.body { padding: 14px 16px; overflow-y: auto; display: flex; flex-direction: column; gap: 10px; font-size: 12px; }
+.row { display: flex; align-items: center; gap: 6px; color: #444; }
+.tid { margin-left: auto; color: #bbb; font-size: 11px; font-family: monospace; }
+.blocked-hint { margin: 0; color: #d33; font-size: 11px; }
+.qb { color: #7aa7dd; font-size: 11px; }
+
+.field { display: flex; flex-direction: column; gap: 4px; }
+.field.ro span:last-child { color: #333; }
+.lbl { font-size: 11px; color: #888; }
+.in { font: inherit; font-size: 12px; padding: 6px 9px; border: 1px solid #ddd; border-radius: 6px; background: #fff; color: #1a1a1a; }
+.in:disabled { background: #f7f7f9; color: #999; }
+.ta { resize: vertical; font-family: inherit; }
+.grid2 { display: grid; grid-template-columns: 1fr 1fr; gap: 10px; }
+.mono { font-family: monospace; font-size: 11px; color: #555; }
+.graph-link { align-self: flex-start; font-size: 11px; color: #2b6cb0; text-decoration: none; }
+.graph-link:hover { text-decoration: underline; }
+
+.err { margin: 0; color: #dc2626; font-size: 11px; }
+
+.foot { display: flex; align-items: center; gap: 6px; padding: 12px 16px; border-top: 1px solid #eee; flex-wrap: wrap; }
+.actions { display: flex; gap: 6px; flex-wrap: wrap; }
+.spacer { flex: 1; }
+.btn { border: 1px solid #ddd; background: #fff; border-radius: 6px; font-size: 12px; padding: 6px 12px; cursor: pointer; }
+.btn:disabled { opacity: .5; cursor: not-allowed; }
+.btn.danger { color: #b91c1c; }
+.btn.primary { background: #2b6cb0; border-color: transparent; color: #fff; font-weight: 600; }
+.btn.ghost { background: transparent; }
+</style>
+<!--
+  任务看板的表格视图 —— TaskBoard.vue 专用，不是 GoalTaskPane 的替代品（那个还在
+  GraphConsole 左栏服役，两边分开维护）。数据摊平自 goals[].tasks[]，不额外请求。
+-->
+<template>
+  <div class="tt">
+    <div class="toolbar">
+      <input v-model="search" class="in search" placeholder="搜索任务标题 / 描述…" />
+      <select v-model="statusFilter" class="in sel">
+        <option value="">全部状态</option>
+        <option v-for="s in STATUS_OPTIONS" :key="s" :value="s">{{ taskStyle(s).label }}</option>
+      </select>
+      <select v-model="goalFilter" class="in sel">
+        <option value="">全部目标</option>
+        <option v-for="g in goals" :key="g.goalId" :value="g.goalId">{{ g.title || g.goalId }}</option>
+      </select>
+      <select v-model="assigneeFilter" class="in sel">
+        <option value="">全部负责人</option>
+        <option v-for="o in assigneeOptions" :key="o.value" :value="o.value">{{ o.label }}</option>
+      </select>
+      <span class="count">{{ sorted.length }} / {{ flatTasks.length }} 条</span>
+      <button class="btn primary" @click="$emit('create')">+ 新建任务</button>
+    </div>
+
+    <div class="scroll">
+      <table>
+        <thead>
+          <tr>
+            <th class="c-status" @click="toggleSort('status')">状态{{ sortArrow('status') }}</th>
+            <th class="c-desc">任务描述</th>
+            <th class="c-goal">所属目标</th>
+            <th class="c-assignee">负责 Agent</th>
+            <th class="c-priority" @click="toggleSort('priority')">优先级{{ sortArrow('priority') }}</th>
+            <th class="c-time" @click="toggleSort('createdAt')">创建时间{{ sortArrow('createdAt') }}</th>
+            <th class="c-time" @click="toggleSort('startedAt')">开始时间{{ sortArrow('startedAt') }}</th>
+            <th class="c-time" @click="toggleSort('finishedAt')">结束时间{{ sortArrow('finishedAt') }}</th>
+          </tr>
+        </thead>
+        <tbody>
+          <tr v-if="loading && !flatTasks.length"><td colspan="8" class="empty">加载中…</td></tr>
+          <tr v-else-if="!sorted.length"><td colspan="8" class="empty">没有匹配的任务</td></tr>
+          <tr
+            v-for="t in sorted" :key="t.taskId"
+            class="row" :class="{ blocked: t.status === 'blocked' }"
+            @click="$emit('select', t)"
+          >
+            <td class="c-status">
+              <span class="dot" :class="{ pulse: taskStyle(t.status).pulse }" :style="dotStyle(taskStyle(t.status))"></span>
+              {{ taskStyle(t.status).label }}
+              <span v-if="queueBadge(t)" class="qb" :title="queueBadge(t).title">{{ queueBadge(t).text }}</span>
+            </td>
+            <td class="c-desc">
+              <div class="title">{{ t.title || '（无标题）' }}</div>
+              <div v-if="t.description" class="desc" :title="t.description">{{ t.description }}</div>
+              <div v-if="t.status === 'blocked'" class="blocked-line">{{ blockedLabel(t, siblingsOf(t)) || '挂起' }}</div>
+            </td>
+            <td class="c-goal">{{ t.goalTitle }}</td>
+            <td class="c-assignee">{{ assigneeLabel(t) }}</td>
+            <td class="c-priority">{{ t.priority || '—' }}</td>
+            <td class="c-time">{{ fmt(t.createdAt) }}</td>
+            <td class="c-time">{{ fmt(t.startedAt) }}</td>
+            <td class="c-time">{{ fmt(t.finishedAt) }}</td>
+          </tr>
+        </tbody>
+      </table>
+    </div>
+  </div>
+</template>
+
+<script setup>
+import { ref, computed } from 'vue';
+import { taskStyle, queueBadge, blockedLabel } from '../graph-console/goal-task-model.js';
+
+const props = defineProps({
+  companyId: { type: String, required: true },
+  goals: { type: Array, default: () => [] },
+  agents: { type: Array, default: () => [] },
+  loading: { type: Boolean, default: false },
+});
+defineEmits(['select', 'create']);
+
+const STATUS_OPTIONS = ['draft', 'queued', 'running', 'completed', 'failed', 'blocked', 'cancelled'];
+
+const flatTasks = computed(() => {
+  const out = [];
+  for (const g of props.goals || []) {
+    for (const t of g.tasks || []) out.push({ ...t, goalTitle: g.title || g.goalId });
+  }
+  return out;
+});
+
+/** 同 goal 下的兄弟任务，blockedLabel 解析「上游 #N 未完成」要用 */
+function siblingsOf(t) {
+  const g = (props.goals || []).find((x) => x.goalId === t.goalId);
+  return (g && g.tasks) || [];
+}
+
+function dotStyle(s) {
+  return s.hollow ? { background: 'transparent', borderColor: s.color } : { background: s.color, borderColor: s.color };
+}
+
+const agentNameById = computed(() => {
+  const m = new Map();
+  for (const a of props.agents || []) m.set(a.id, a.name || a.id);
+  return m;
+});
+
+/** assignee_agent_id 是 null（还没派）/ 'org-graph'（被组织图接管，没有真实派单对象）/ 真实 role_name 三种 */
+function assigneeLabel(t) {
+  if (!t.assigneeAgentId) return '未分配';
+  if (t.assigneeAgentId === 'org-graph') return '组织图执行';
+  return agentNameById.value.get(t.assigneeAgentId) || t.assigneeAgentId;
+}
+
+const assigneeOptions = computed(() => {
+  const seen = new Map(); // value -> label
+  for (const t of flatTasks.value) {
+    const v = t.assigneeAgentId || '__none__';
+    if (!seen.has(v)) seen.set(v, assigneeLabel(t));
+  }
+  return [...seen.entries()].map(([value, label]) => ({ value, label }));
+});
+
+const search = ref('');
+const statusFilter = ref('');
+const goalFilter = ref('');
+const assigneeFilter = ref('');
+
+const filtered = computed(() => {
+  let list = flatTasks.value;
+  const q = search.value.trim().toLowerCase();
+  if (q) list = list.filter((t) => (t.title || '').toLowerCase().includes(q) || (t.description || '').toLowerCase().includes(q));
+  if (statusFilter.value) list = list.filter((t) => t.status === statusFilter.value);
+  if (goalFilter.value) list = list.filter((t) => t.goalId === goalFilter.value);
+  if (assigneeFilter.value) list = list.filter((t) => (t.assigneeAgentId || '__none__') === assigneeFilter.value);
+  return list;
+});
+
+const sortKey = ref('createdAt');
+const sortDir = ref('desc');
+
+function toggleSort(key) {
+  if (sortKey.value === key) sortDir.value = sortDir.value === 'asc' ? 'desc' : 'asc';
+  else { sortKey.value = key; sortDir.value = 'asc'; }
+}
+function sortArrow(key) {
+  if (sortKey.value !== key) return '';
+  return sortDir.value === 'asc' ? ' ▲' : ' ▼';
+}
+
+/** 状态按中文标签排序（用户比较的是眼睛看到的字，不是内部枚举值），其余字段原值比较 */
+function sortValue(t, key) {
+  if (key === 'status') return taskStyle(t.status).label;
+  return t[key] == null ? '' : t[key];
+}
+
+const sorted = computed(() => {
+  const list = filtered.value.slice();
+  const dir = sortDir.value === 'asc' ? 1 : -1;
+  list.sort((a, b) => {
+    const av = sortValue(a, sortKey.value);
+    const bv = sortValue(b, sortKey.value);
+    if (av < bv) return -1 * dir;
+    if (av > bv) return 1 * dir;
+    return 0;
+  });
+  return list;
+});
+
+function fmt(iso) {
+  if (!iso) return '—';
+  try { return new Date(iso).toLocaleString('zh-CN', { year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit' }); }
+  catch { return iso; }
+}
+</script>
+
+<style scoped>
+.tt { display: flex; flex-direction: column; gap: 10px; height: 100%; min-height: 0; }
+
+.toolbar { display: flex; align-items: center; gap: 8px; flex-wrap: wrap; }
+.in { font: inherit; font-size: 12px; padding: 6px 9px; border: 1px solid #ddd; border-radius: 6px; background: #fff; color: #1a1a1a; }
+.search { flex: 1 1 220px; min-width: 160px; }
+.sel { flex: 0 0 auto; }
+.count { font-size: 11px; color: #999; white-space: nowrap; }
+.btn { border: 1px solid #ddd; background: #fff; border-radius: 6px; font-size: 12px; padding: 6px 12px; cursor: pointer; }
+.btn.primary { background: #2b6cb0; border-color: transparent; color: #fff; font-weight: 600; }
+
+.scroll { flex: 1 1 auto; overflow: auto; border: 1px solid #eee; border-radius: 8px; }
+table { width: 100%; border-collapse: collapse; font-size: 12px; }
+thead th {
+  position: sticky; top: 0; background: #fafafa; text-align: left; padding: 8px 10px;
+  border-bottom: 1px solid #eee; font-weight: 600; color: #555; white-space: nowrap; cursor: pointer; user-select: none;
+}
+thead th:hover { color: #2b6cb0; }
+.c-status:not(th), td.c-status { cursor: default; }
+tbody td { padding: 8px 10px; border-bottom: 1px solid #f4f4f6; vertical-align: top; }
+.row { cursor: pointer; }
+.row:hover { background: #f7f9fc; }
+.row.blocked { background: #fffaf9; box-shadow: inset 2px 0 0 #d33; }
+.empty { text-align: center; color: #999; padding: 24px 0; }
+
+.dot { display: inline-block; width: 8px; height: 8px; border-radius: 50%; border: 1.5px solid transparent; margin-right: 5px; vertical-align: middle; }
+.dot.pulse { animation: pulse 1.6s ease-in-out infinite; }
+@keyframes pulse { 0%, 100% { opacity: 1; } 50% { opacity: .35; } }
+.qb { margin-left: 6px; font-size: 10px; color: #7aa7dd; }
+
+.c-desc { min-width: 220px; max-width: 360px; }
+.title { font-weight: 600; color: #1a1a1a; }
+.desc { margin-top: 2px; color: #888; font-size: 11px; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; }
+.blocked-line { margin-top: 2px; color: #d33; font-size: 11px; }
+.c-goal, .c-assignee { color: #555; white-space: nowrap; }
+.c-priority { white-space: nowrap; }
+.c-time { white-space: nowrap; color: #666; }
+
+@media (max-width: 900px) {
+  .c-goal, .c-priority { display: none; }
+}
+</style>
@@ -123,6 +123,44 @@
             </div>
           </div>
+          <!-- Target Dir Card（42 号文档 Phase 3：公司级目标代码目录配置） -->
+          <div class="overview-card">
+            <div class="overview-card-header">
+              <h3>📁 目标代码目录</h3>
+            </div>
+            <p style="font-size:13px; color:var(--text-secondary); margin:0 0 12px;">
+              配了之后，这家公司所有任务的交付物代码都固定落在这个目录，不再逐任务分配临时沙盒
+              （类似 Claude Code 选工作目录）。留空则维持默认的沙盒模式。
+            </p>
+            <div class="overview-info-grid" style="grid-template-columns: 1fr;">
+              <div class="info-item">
+                <span class="info-label">目标目录（绝对路径）</span>
+                <input
+                  v-model="targetDirForm.target_dir"
+                  type="text"
+                  placeholder="/Users/you/projects/my-app"
+                  style="padding:6px 10px; border:1px solid var(--border-color); border-radius:6px; font-size:13px; width:100%; box-sizing:border-box;"
+                />
+              </div>
+              <div class="info-item">
+                <span class="info-label">模式</span>
+                <select v-model="targetDirForm.target_mode" style="padding:6px 10px; border:1px solid var(--border-color); border-radius:6px; font-size:13px;">
+                  <option value="linked-existing">linked-existing（接管一个已存在的目录）</option>
+                  <option value="linked-new">linked-new（新建/空目录）</option>
+                </select>
+              </div>
+            </div>
+            <div class="overview-actions">
+              <button class="btn-sm" @click="saveTargetDir" :disabled="isSavingTargetDir">
+                {{ isSavingTargetDir ? '⏳ 保存中...' : '💾 保存' }}
+              </button>
+              <span v-if="targetDirError" style="color:var(--status-failed); font-size:13px;">{{ targetDirError }}</span>
+              <span v-else-if="selectedCompany?.target_dir" style="color:var(--text-secondary); font-size:13px;">
+                当前生效：{{ selectedCompany.target_dir }}（{{ selectedCompany.target_mode }}）
+              </span>
+            </div>
+          </div>
+
           <!-- Agent Status Table -->
           <div class="overview-card agents-card">
             <div class="overview-card-header">
@@ -739,7 +777,7 @@
 </template>
 <script setup>
-import { ref, computed, onMounted, watch, onUnmounted } from 'vue'
+import { ref, reactive, computed, onMounted, watch, onUnmounted } from 'vue'
 import { useRouter, useRoute } from 'vue-router'
 import axios from 'axios'
 import AppNav from '@/components/AppNav.vue'
@@ -756,6 +794,11 @@ const companyStatus = ref(null)
 const isStarting = ref(false)
 const isStopping = ref(false)
 const selectedCompany = ref(null)
+// 42 号文档 Phase 3：target_dir 配置表单本地状态，不直接双向绑到 selectedCompany——
+// 保存失败时输入框不该跟着回滚成服务端的旧值，用户还得看着自己刚打的字重打一遍。
+const targetDirForm = reactive({ target_dir: '', target_mode: 'linked-existing' })
+const isSavingTargetDir = ref(false)
+const targetDirError = ref('')
 const companyAgents = ref([])
 const pipelines = ref([])
 const pipelineRuns = ref([])
@@ -972,6 +1015,14 @@ function goToTaskBoard() {
   router.push(`/${selectedCompany.value.id}/task-board`)
 }
+// 42 号文档 Phase 3：公司切换 / 首次加载时，把表单同步成服务端当前值——只在 id 变化时同步，
+// 不watch 整个 selectedCompany，否则用户正在改的输入框会被别的字段刷新（比如心跳状态轮询）打断。
+watch(() => selectedCompany.value?.id, () => {
+  targetDirForm.target_dir = selectedCompany.value?.target_dir || ''
+  targetDirForm.target_mode = selectedCompany.value?.target_mode || 'linked-existing'
+  targetDirError.value = ''
+}, { immediate: true })
+
 watch(() => route?.params, async (params) => {
   if (!params) return
   if (route.name === 'CompanyDetail' && params.id) {
@@ -1154,6 +1205,22 @@ async function stopCompany() {
   isStopping.value = false
 }
+async function saveTargetDir() {
+  if (!selectedCompany.value) return
+  isSavingTargetDir.value = true
+  targetDirError.value = ''
+  try {
+    const { data } = await axios.put(`/api/company/${selectedCompany.value.id}`, {
+      target_dir: targetDirForm.target_dir,
+      target_mode: targetDirForm.target_mode,
+    })
+    selectedCompany.value = data.company
+  } catch (e) {
+    targetDirError.value = e.response?.data?.error || e.message
+  }
+  isSavingTargetDir.value = false
+}
+
 async function deleteCompany(companyId) {
   if (!confirm('确认要删除该公司吗？该操作仅会从列表中移除公司声明。')) return
   try {
 <!--
   任务看板 —— goal/task 两级模型的独立页面（39 号文档 §二 P2）。
-  在此之前 goal/task 只能在 GraphConsole 左栏的窄侧栏里看，这里把同一份组件
-  （GoalTaskPane + goal-task-model.js）铺满整页，数据层原样不动，不重写。
-
-  点一条 task 不在本页画执行图（那是 GraphConsole 的活），而是跳过去 ——
-  `/:id/graph-console?goal=...&task=...` 是 GraphConsole 已经支持的选中态复原路径
-  （见该文件 onMounted 里 `route.query.goal` / `route.query.task` 那两行），不新开一条协议。
+  表格视图（TaskTable + TaskDetailModal），数据层沿用原来那份（GET /goals?withTasks=1，
+  20s 轮询），只是不再走 GoalTaskPane 那套折叠列表 —— GoalTaskPane 还在 GraphConsole
+  左栏服役，两边分开维护，改这里不会动到那边。
 -->
 <template>
   <div class="board">
@@ -20,43 +17,60 @@
     </header>
     <div class="body">
-      <GoalTaskPane
+      <TaskTable
         :company-id="companyId"
         :goals="goals"
+        :agents="agents"
         :loading="goalsLoading"
-        :selected-task-id="selectedTaskId"
-        :selected-goal-id="selectedGoalId"
-        :slots="slots"
-        @select="goToDetail"
-        @refresh="loadGoals"
+        @select="openDetail"
+        @create="openCreate"
       />
     </div>
+
+    <TaskDetailModal
+      v-if="showModal"
+      :company-id="companyId"
+      :task="modalTask"
+      :goals="goals"
+      :agents="agents"
+      @close="closeModal"
+      @saved="onSaved"
+    />
   </div>
 </template>
 <script setup>
 import { ref, computed, onMounted, onBeforeUnmount } from 'vue';
-import { useRoute, useRouter } from 'vue-router';
-import GoalTaskPane from '@/components/graph-console/GoalTaskPane.vue';
+import { useRoute } from 'vue-router';
+import TaskTable from '@/components/task-board/TaskTable.vue';
+import TaskDetailModal from '@/components/task-board/TaskDetailModal.vue';
 const route = useRoute();
-const router = useRouter();
 const props = defineProps({ id: { type: String, default: '' } });
 const companyId = computed(() => props.id || route.params.id);
 const company = ref(null);
 const goals = ref([]);
 const goalsLoading = ref(false);
-const slots = ref(null);
-const selectedGoalId = ref('');
+const agents = ref([]);
+
 const selectedTaskId = ref('');
+const showCreate = ref(false);
+const showModal = computed(() => showCreate.value || !!selectedTaskId.value);
+/** 从当前 goals 树里现查，而不是缓存点击那一刻的快照——刷新之后弹窗跟着显示最新状态 */
+const modalTask = computed(() => {
+  if (!selectedTaskId.value) return null;
+  for (const g of goals.value) {
+    const t = (g.tasks || []).find((x) => x.taskId === selectedTaskId.value);
+    if (t) return t;
+  }
+  return null;
+});
 let treePoll = null;
 onMounted(async () => {
-  selectedGoalId.value = String(route.query.goal || '');
-  selectedTaskId.value = String(route.query.task || '');
-  await Promise.all([loadCompany(), loadGoals()]);
+  await Promise.all([loadCompany(), loadGoals(), loadAgents()]);
   // 与 GraphConsole 同款兜底：没有公司级 SSE 通道，靠轮询看到别处发生的状态变化
   treePoll = setInterval(() => { loadGoals(); }, 20000);
 });
@@ -76,18 +90,37 @@ async function loadGoals() {
     if (!r.ok) return;
     const j = await r.json();
     goals.value = j.goals || [];
-    slots.value = j.slots || null;
   } catch { /* 轮询失败保留上一份树 */ } finally {
     goalsLoading.value = false;
   }
 }
-/** 点一条 task：跳到执行控制台看它的图，选中态通过 query 带过去 */
-function goToDetail({ goalId, taskId }) {
-  selectedGoalId.value = goalId || '';
-  selectedTaskId.value = taskId || '';
-  if (!taskId) return;
-  router.push({ path: `/${companyId.value}/graph-console`, query: { goal: goalId || '', task: taskId } });
+/** agent 花名册不常变，拉一次即可，不用跟 goals 一起轮询 */
+async function loadAgents() {
+  try {
+    const r = await fetch(`/api/company/${companyId.value}/agents`);
+    if (r.ok) agents.value = await r.json();
+  } catch { /* 拉不到就退回显示 assignee 原始 id，不影响其余功能 */ }
+}
+
+function openDetail(t) {
+  showCreate.value = false;
+  selectedTaskId.value = t.taskId;
+}
+function openCreate() {
+  selectedTaskId.value = '';
+  showCreate.value = true;
+}
+function closeModal() {
+  showCreate.value = false;
+  selectedTaskId.value = '';
+}
+
+/** 弹窗里任一增删改查动作成功后：重新拉 goals；新建 / 归档导致弹窗没有对象可显示时关掉它 */
+async function onSaved() {
+  await loadGoals();
+  if (showCreate.value) { closeModal(); return; }
+  if (selectedTaskId.value && !modalTask.value) closeModal();
 }
 </script>
@@ -104,7 +137,7 @@ function goToDetail({ goalId, taskId }) {
 .to-console { text-decoration: none; color: #2b6cb0; font-size: 12px; font-weight: 600; }
 .to-console:hover { text-decoration: underline; }
-.body { flex: 1 1 auto; overflow-y: auto; padding: 16px 24px; max-width: 900px; width: 100%; margin: 0 auto; box-sizing: border-box; }
+.body { flex: 1 1 auto; overflow-y: auto; padding: 16px 24px; box-sizing: border-box; }
 @media (max-width: 700px) {
   .body { padding: 12px; }