• - system/agents/deep-research/: 新 Agent 本体(agent.md/prompt.md/soul.md/config.json)
      及 train/hunt 调研结论(knowhow_v1 + sources_v1.json,含 sha256 信源母本)
    - h3-video-prompt: train/digest、train/hunt、train/evolve 的 v2/v3/v4 全套训练产物,
      SKILL 升级 v0.5.0(习语甲/乙分轨 + prompt/block/clarify 三轨计分)
    - org-innovator: docs/ SKILL 模板库与 soul.md 更新(外网访问 SOP R1-R5、lark-cli 能力)
    - master / innovator-digest / innovator-evolver / innovator-hunt: 本体文件更新
    - packages/agent-core/base/common/tools-base.md: 收录 lark-cli 入口与「搜得到≠读得到」边界
    - bin/lark-cli: 飞书 CLI 入口脚本(wrapper)
    - .gitignore: 排除 .pnpm-store/、.env.bak*(防密钥入库)、train/hunt/sources_raw/
      与 train/evolve/_v*_artifacts/(中间产物沿用既有裁决,只留磁盘)
    
    Co-Authored-By: Claude <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »


  • 新建独立试验节点 prd-methodology-trial,走真实 Hunt→Digest→Evolve 训练 PRD 撰写方法论:
    2 轮 Small Loop 提前收敛(96/97 分,真实基线 50 分),用三个真实历史项目反推验证方法论
    有效,Deploy 范围限定在该独立节点,未触碰生产 prd-planning。结论:FDE 对方法论类角色
    确实管用,但收敛速度/验收严谨度依赖任务书里显式写明的自纠正要求,非免人工黑盒。
    
    过程中连带修复同一个 2026-08-16 改名批次(innovator→org-innovator 等)遗留的 5 处死链:
    company.js 两处硬编码调用、CompanyDashboard.vue「重新训练」按钮,以及四个本体各自
    config.json 内部 id 字段从未随目录改名同步更新,导致 /api/agent/list 展示层用假 id
    显示成死卡片。顺手修了 AgentScaffold 默认 tools.md 模板一处裸相对路径缺陷(对应
    agent-md-refs.test.js 里已登记多时的已知缺陷)。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »

  • 测试 786/786 全绿(76 文件,起点 760/72),未改任何既有断言。
    
    ## 本轮三件新东西,全部经真 CLI 验证
    
    W12 补完 · 失败原因四环打通
    - 引擎自判的失败(executor 抛异常、边界越界、子 run 无归因)现在也落
      graph_run_nodes.fail_reason,不再只有 agent 归因产出的才有值
    - 概览 tab 展示「[引擎判定] boundary_escape」+ 终端样式 excerpt,
      取不到 fail_reason 时回落 output_excerpt,并标明来源
    - 真跑实查:两行 fail_reason='boundary_escape' 都在库里,
      产生→传递→落库→读回四环在真 CLI 下走通
    
    W13 · 运行态文件根治(守卫误判的根因)
    - 17 个 todo.md / plan.md / scheduled_tasks.json git rm --cached + gitignore;
      源码(agent.md/config.json/soul.md/tools.md)一个未碰,模板本体仍跟踪
    - _registry.json 的 usedCount 挪进已忽略的 data/template-usage.json
    - 真跑验收:整轮(agent-creator、Master 各一次真 CLI、3 次 hire)结束时
      worktree git status 与基线逐字相同,_registry.json 零 diff
    
    单步进度感 · 真 CLI 一个节点 3-7 分钟
    - 画布卡片秒表 + 详情面板常驻条「运行中 2m40s · 最近事件 …(2m40s 前)」
    - 不做假进度条:引擎不知道 agent 还要多久
    - 顺手修 NodeDetailPanel 不跟 SSE 走(否则秒表也不会动)
    
    W9 失败上下文进提示词、W10 跨层地址两半、W11 Hot Swap 显式告警同批完成。
    
    ## 真跑结论:链路更长,但「work 节点 → success」仍未跑到
    
    走到:orggraph-planning 落图自雇 → agent-creator 补定义 → workgraph-planning
    真跑规划 + **先雇后提交**(W5/W6 再次成立)→ 子 run 起来 → work 节点 RUNNING
    → 7m19s 后 fail。两层原因叠加,都与 W1-W14 无关:
    
    1. **新缺陷**:agent-manager.js:324 把 idleTimeoutMs 硬编码 120s,
       readme-writer 通读源码静默超 2 分钟被掐死(动笔前就死了)。
       同进程 ClaudeCliProtocol 早把自己的 idle 上限放到 24h,
       stream-executor 的 JSDoc 默认值写的是 30 分钟 —— 这里把两者都压掉一个数量级;
       且 ...options 透传的 idleTimeoutMs 会被下一行覆盖,调用方无法覆写。
    2. **并行 agent 污染**:retrain-watchdog 每 5 分钟唤起的 Master 在同一工作树里
       改了两个源文件,被守卫 git status 差集算到该节点头上 → 额外署 boundary_escape。
       这是 W3「拦不住」第 5 条第一次真实发生。
    
    顺带记一笔:这一轮任务是 **LemonBoss 自己的 Master 自主下的单**,
    走的正是 POST /api/company/:id/tasks,它还自行诊断出了上面那个 idle timeout
    并动手改(引用了未定义的常量,是坏的)。
    
    ## 已知未修(下一轮)
    
    - idleTimeoutMs 硬编码 120s —— 「work 节点 → success」跑不通的唯一技术原因
    - W7 在**零边最小图**上失效:判据③要求存在 active org_graph_edges,
      零边图上三条判据全落空,work 层本体被写进 org_graph_nodes。
      服务层那 9 例测试造的都是有边的成型图,正好绕开这个形状
    - 前端 ACTIVE_RUN 含 blocked、后端 ACTIVE_ROOT_RUN_STATUS 不含:
      一家公司只要失败过一次,控制台上就再也下不了第二个任务(后端其实放行)
    - 真跑期间工作树里不能有第二个 agent 活动,否则守卫判罚不可信 —— 应写进真跑规程
    
    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »

  • 命名轴是「节点在哪一层图里」,把散落的老 agent 归到它实际所处的层级:
    
      innovator → org-innovator      type='cxo',是 org graph 层的节点
      hunter    → innovator-hunt     innovator work graph 第 1 阶段
      digester  → innovator-digest   第 2 阶段(输入是 hunt 产出)
      evolver   → innovator-evolver  第 3 阶段
    
    依据:retrain-pipeline.js 的 stepConfigs 就是按 hunter → digester → evolver 顺序
    跑的,行 231 明写 steps: ['re_hunt','re_digest','evolve'] —— 这三个本来就是
    innovator 的 work graph 三阶段,只是名字没体现出来。
    
    ■ 迁移(scripts/migrate-agent-naming.js,--dry-run + 幂等可重跑)
    - 8 个目录(system/agents/ + system/templates/),用 git mv 保留历史
    - system_agents 表 4 行的 id 与 legacy_path
    - 公司实例目录与 company.json.agents[](本次无公司雇过这四个,实际 0 条)
    
    ■ 代码引用点(5 处,手工改)
    - retrain-pipeline.js: stepConfigs 的 agent 字段 ×3、agentToStep 映射的 key ×3、
      call_sub_agent 的 evolver 判断
    - agent-chat.js: agent 列表过滤里的 innovator
    - company.js: 模板训练触发的 agentId
    
    ■ 刻意不动的三类同形异义(改了会坏)
    1. skill 内部子目录名 {skillDir}/hunter/knowhow.md —— 那是 hunt/digest/evolve
       三阶段的产物目录约定,与 agent 名同形但不同义。涉及 open-api.js:402、
       retrain-pipeline.js:148/374、evolution-loop.js:178、sync-skills.js 的 INTERNAL_DIRS
    2. skill 命名空间白名单 —— skill-dir-manager.js 的 CORE_SKILLS、
       migrate-trained-skills.js 的 SYSTEM_SKILLS,那里的 'innovator' 指同名 skill
    3. conversations/ 与 system/tasklog/ 下的历史记录 —— 运行态数据,不改写历史
    
    evolver-youtube-crawler 按 §3.4 列为待定,迁移脚本按精确目录名匹配,未误伤。
    
    这四个重命名顺带解决了 27 号文档 §七 挂了很久的 6 个命名冲突 id —— 重命名后
    system/agents/ 与 system/templates/ 下不再有同名目录(只剩 agent-creator 与
    evolver-youtube-crawler 两个,前者是基础设施角色按规则不改名)。
    
    验证:npm run test:unit 693 全绿(64 files);test-company-e2e 114/114;
    迁移脚本二次执行 dirs=0 dbRows=0 skipped=8(幂等)。
    
    未触碰另一进程正在进行的 P3 文件(graph-engine.js / graph-run-sse.js /
    work-graph-db.js / 27-p3-p4-work-graph-console.md / 27-requirement.md)。
    
    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »