• 43 号文档补上 Phase 0-4 的实现记录,含一处架构订正(org-planner 在 org
    层永远是 subgraph,真跑数据核实后钩子改成扫子 run 全节点)。
    
    44 号文档是真实回归验证 43 号文档时意外发现的独立缺陷:goal-benchmark
    按设计把产物写进 root run 共享 artifacts/ 目录,产出闸门只查节点私有
    目录,writesArtifacts:true 这个字段全仓库零代码读取——这条契约在当前
    实现下结构性地打不过,不是偶发。很可能正是 snakegame-co 参考任务里
    goal-benchmark/planner-validator 显示 skipped 的真实原因。只记录诊断,
    未修复,留了两条候选修法。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01U7xYyvv3pzuV9diMVUH5QL
    yibo authored
     
    Browse Dir »
  • 回应"org-planner 出 brd/prd/sdd 后,任务看板能不能展示成 task/sub-task
    树,coder-validator 按清单逐条开发验收"。原话照搬 + 结构化复述 +
    现状调研(parent_task_id 只服务于 Agent Chat 派单流程、task-planning
    人设明确拒绝按检查项拆 task、org-planner 没有建任务工具)。
    
    三轮讨论定案:goal→task 流水线自建父子机制、先只拆验收(开发仍整体
    完成)、要不要拆交给 task-planning 判断、任一子任务 fail 父任务即
    fail、子任务复用 tasks.status 状态语义。
    
    技术实现计划 Phase 0-4 逐条核实代码形态,含两处订正(org-validator/
    coder-validator 是不同 agent;org-planner 产出的验收清单是 acceptance.md
    不是 acceptance.json)和一个待验证风险(acceptance.md 在真实回归里
    从未被用上,Phase 2 落地前需先确认可靠性)。尚未开工。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01U7xYyvv3pzuV9diMVUH5QL
    yibo authored
     
    Browse Dir »
  • 昨晚做完 42 号文档 Phase 2-4 之后忘了同步 docs/README.md 索引,还停在
    "Phase 1 已实现,Phase 2-4 待开工"。这次一并把两份文档从 todo/ 挪进
    done/(39 号 P1-P5、42 号 Phase 1-4 均已实现,符合仓库自己的归档约定),
    索引表挪到对应位置,两处过期描述改成完工状态。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
    yibo authored
     
    Browse Dir »

  • org-coder 等 9 个角色(含 _base 骨架模板)的四段式阶段流转靠调
    bin/lemon.js task transition,打到 agent-chat.js 的 /task/transition——
    这个端点靠自己的 sessions Map 找会话,work graph 节点场景下找不到,
    阶段流转静默跳过,中间产物不进任何跨节点共享的轨迹。
    
    调研确认范围后选了最保守的实现:不改 bin/lemon.js 的 CLI 签名、不碰
    agent-chat.js(当天正被另一个并行会话实时编辑,风险太高)。关键发现
    是 --artifact 参数本来就是 .../runs/{rootRunId}/nodes/{nodeRunId}/...
    形状的路径,两个 ID 已经现成编码在里面,不需要给子进程塞新环境变量,
    不需要改一个字的 agent.md 提示词。
    
    bin/lemon.js 在原有调用之外 best-effort 追加一次 POST
    /api/graph-runs/phase-note,新端点从 artifact 路径解出两个 ID,
    校验 run 真实存在后调 emitEvent() 追加 timeline 记录,只追加不碰
    graph_run_nodes/graph_runs 任何一行——不影响 needs/produces 契约。
    P0 拦截/OKR 更新两段旧逻辑维持原样,新端点是独立的第二条路径,不是
    迁移。
    
    新增测试 4 例,全量测试 1503/1506,零回归(剩余失败全部来自另一个
    并行会话进行中、还未提交的工作)。42 号文档 Phase 1-4 全部完工。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
    yibo authored
     
    Browse Dir »
  • 39 号文档 P5 落地的是"配了 company.json.target_dir 就生效"这一半,
    "人怎么把这两个字段填进去"此前只能手工编辑 company.json。
    
    复用已存在的 PUT /api/company/:companyId(companyService.update()),
    没有新建端点。新增 target_dir/target_mode 分支,校验直接调
    path-resolver.validateLinkedTarget(39 号文档 P5 抽出来的共享函数,
    和 graph-engine.js 运行时校验同一份判据):合法路径写入成功、敏感
    路径黑名单拒绝、linked-new 非空目录拒绝、linked-existing 不存在拒绝,
    校验失败路由层转 400;传空字符串清空配置;不传 target_mode 默认
    linked-existing,与 graph-engine.js 的 readCompanyTargetConfig 同口径。
    
    前端:CompanyDashboard.vue 概览 tab 加一张配置卡片,本地表单状态
    不直接双向绑定 selectedCompany,保存失败不会冲掉用户刚打的字。
    
    新增测试 8 例,npm run web:build 编译通过。**未做真实浏览器点击
    验证**——服务器上有其它并行会话真实在跑的 agent 进程,这次没有重启
    服务器(42 号文档 §二记过一次"重启杀掉别人真实进程"的教训),文档
    里标记了这个已知缺口。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
    yibo authored
     
    Browse Dir »
  • yibo authored
     
    Browse Dir »
  • 39 号文档 §四.4 拍板"ceo 全权自主 enqueue,但 max_parallel_tasks /
    DEFAULT_TASK_BUDGET / goal 级 org-validator 这几道闸门必须照样拦住
    它",落地时没补这条测试。这次补上,走 ceo 实际会用的通路(draft:true
    + created_by:'ceo' → /enqueue),不抄近道直接摆数据库行:
    
    1. 坑满时 ceo 建的任务排队,不插队。
    2. 预算给 0,checkBudget 照样判耗尽,created_by 不改变结果。
    3. ceo 建的两条 task 挂同一个 goal,全 completed 后 goal 级验收只调一次。
    
    全量测试 1486/1490,零回归。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
    yibo authored
     
    Browse Dir »
  • 冲突在 docs/README.md:并行会话在真实端到端测试里发现 boss agent(39 号文档)还有
    三个单测没覆盖的真问题,把 39 号重新留在 todo/ 并拆出 42 号跟进文档;与我这边把
    39 号挪进 done/ 的判断冲突——采纳对方判断(39 号文档物理路径挪回 todo/system-design/,
    докс/README.md 用对方更新的行 + 补 42 号一行),因为他们是基于更新的真实测试结果。
    
    顺带把 29-dream-design.md 这次会话移到 done/ 后遗漏的引用修掉:
    system/agents/{dream-distiller,dream-screener}/agent.md、
    server/{routes/dream.js,services/dream-service.js}、
    server/tests/unit/dream-routes.test.js 六处 docs/todo/system-design/29-dream-design.md
    路径改成 docs/done/system-design/29-dream-design.md(no-dead-path-references.test.js /
    agent-md-refs.test.js 两条守卫测试之前没扫到这几处,这次真跑测试才暴露)。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • 29-dream-design / 33-needs-gate-role-filter-bug / 35-validation-rigor-and-body-readiness-proposal /
    39-boss-agent-task-supervision / 40-agent-chat-streaming-interrupt 逐份核实状态确认已完成
    (后两份状态行本身滞后于代码,已在上一提交订正),按维护说明从 docs/todo/system-design/
    挪到 docs/done/system-design/,docs/README.md 的 todo/done 两张表同步更新。
    
    顺带修复 4 处指向这 5 份文档的相对路径引用(28-followups / 31-work-graph-fail-fallback-coverage /
    34-validator-scored-without-real-deliverable / 41-graph-vs-fde-reliability-discussion),
    文件搬家后原来的同目录相对链接会失效,改成 ../../done/system-design/ 的正确相对路径。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • 服务器重启会杀死正在跑的 graph 节点背后的真实进程,但 graph_run_nodes.
    status 永远停在 running(ceo 的两条唤醒路径都只认 blocked,对这个状态
    完全不可见)——39 号文档真跑复盘撞出来的坑,这次补上。
    
    1a:graph-engine.js 新增 sweepOrphanedRunningNodes(cutoffIso),复用
    routeFailure 的 infra_flake 分支(不发明新状态),server/index.js 在
    本次进程启动时刻挂一次开机扫描,排在其余「补一次全量扫描」钩子之前。
    
    1b:新增 forceFailNode() + POST /:id/nodes/:nodeId/force-fail,补上
    retry 端点管不到 running 节点这个缺口——人工/ceo 判定"这个真的救不
    回来了"时的手动出口,转 fail 后交给既有失败路由处理,不发明新路径。
    
    新增测试 12 例(graph-engine-orphan-sweep.test.js 4 例、
    graph-run-force-fail.test.js 8 例),全量测试 1483/1487,零回归。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
    yibo authored
     
    Browse Dir »
  • 上一条 commit 只带了纯改名(git rename detection),文件内标题、
    39 号文档的两处引用、docs/README.md 的索引更新都漏提交了(git add
    命令里混了一个已经改名走的旧路径,报错后整条 add 没生效)。这次补全。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
    yibo authored
     
    Browse Dir »
  • 两份文档文件名不同、内容不冲突,但编号巧合容易读混。改名 + 更新
    39 号文档里的两处引用 + 补 docs/README.md 索引(39 号状态同步成
    已实现,42 号补一条索引)。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
    yibo authored
     
    Browse Dir »
  • yibo authored
     
    Browse Dir »
  • P1-P5 落地后做了一次真实端到端测试(建公司→下 goal→ceo 监督→真实跑出
    一个 Playwright 验证 5/5 通过的贪吃蛇游戏)。1469 个单测全绿,这次真跑
    却测出至少三个单测没覆盖到的真问题:服务器重启会让 in-flight 节点变
    僵尸且无人能自动发现、graph-run.js 鉴权缺口(已在另一个 commit 修过)、
    规划/反思轨迹没有统一可追溯位置。
    
    39 号文档新增「七、真跑复盘」记录技术缺口和过程教训;41 号文档把复盘
    沉淀的待办拆成四个 phase 的开发计划(卡住恢复闭环 → 闸门穿透性回归
    测试 → target_dir 配置入口 → timeline 承接规划轨迹),按优先级排开工
    顺序。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
    yibo authored
     
    Browse Dir »
  • - writeGraph() 的乐观锁缺失此前误标"已修复",实际只是后续实验绕开没再撞它,改回开放
      TODO 并补上修法思路(CAS 式版本校验)。
    - company.js 的 requireAuthOrInternal 401 缺口、boss agent 巡检设计,均已被另一并行会话
      实际修复/实现(14cbaf5、39 号文档 P1-P5),核实代码后删掉这两条过期 TODO,指向正确出处。
    - 新增一条未拍板的可选项:org-hunt/digest/evolve 这套"元 agent 复刻成 graph 原生副本"的
      操作模式要不要沉淀进 org-graph-templates/README.md 供以后参考。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • 第 11 轮真跑:给 org-evolve 规划验收节点时,按名字语义匹配选了 benchmark-validator
    ("对评分结果做验收判决"),但该本体硬编码读 artifacts/goal-benchmark.json(只有
    planner.json 的 goal-benchmark 节点才产),Hunt→Digest→Evolve 链路里没有这个节点,
    两轮都判 blocked。benchmark-validator / testdata-validator / validator-triager 不是
    通用验收工具,是 validator.json 骨架专属、绑定任务级共享契约文件的本体。
    
    workgraph-planning/agent.md 加第三条硬规则:判据从"名字像不像"改成"这条链路里有没有
    节点产 goal-benchmark.json/acceptance.json"。deliverable.json 的 whenToUse 补上"自带
    自评分收敛逻辑的节点也不需要外部验收节点"例外条款并点名这次事故。
    
    第 12 轮真跑验证:org-evolve 的规划记录原文引用新条款选中 deliverable.json,
    backward_count=0,评分 83/行业均线 78 收敛,全流程干净跑完。41 号文档收尾——
    11 轮真跑挖出的 6 个独立缺陷全部修复并逐条验证生效。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • yibo authored
     
    Browse Dir »
  • 核心修复:indexNodeOutputs() 此前只扫节点私有目录,不扫项目根——但引擎自己的写入边界
    明确允许交付物写项目根,导致内容型交付物节点(产出写进项目根时)永远进不了 R-19 产物
    索引,下游 needs 声明永远查不到实例。新增 readDeclaredProduces():agent 可在
    contract.json 里显式声明 produces:{kind: 绝对路径},校验(绝对路径/落在项目根或私有目录内/
    文件真实存在)通过才登记,不满足就整个 kind 判「没产出」,不静默放过。全局提示词
    (describeArtifactContract)同步更新,所有 org/work 节点自动学到这个新字段。
    
    新增 org-hunt / org-digest / org-evolve 三个 graph 原生 agent(方法论抄
    innovator-hunt/digest/evolver,协议原生兼容 graph 引擎),配套新增 work-graph-templates
    的 deliverable.json(内容型交付物骨架,不引入验证 agent)。11 轮真实试跑挖出并修复 5 个
    独立缺陷(详见 41 号文档问题 7):建公司自动规划与手写图的竞态、work-graph 模板库缺内容型
    交付物骨架、验收节点任务描述范围溢出、两个规划 agent(orggraph-planning/workgraph-planning)
    的路径口径写错、以及上述 R-19 索引缺口。最终产出与原生 FDE 对比:内容骨架可迁移、质量不
    打折,但可靠性差距悬殊。
    
    补充说明:system/agents/{ceo,innovator-evolver,master,org-innovator}/{agent,soul}.md 是
    本会话开始前已存在的 dream 自编辑改动,随本次提交一并收进去,不属于本次改动范围。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • 39 号文档地基 0 当时只改了 company.js(goals/tasks 端点),graph-run.js
    (run 的 start/stop/retry/budget 控制端点)漏了同一处修复,还是纯
    requireAuth。真实端到端测试里 ceo 被唤醒后能读写 goal/task 板,但调
    /api/graph-runs/* 处理卡住的 run 时精确撞上 401——ceo 自己在对话记录里
    诊断出这一点并写出了人工需要跑的 curl 命令,间接验证了这条修复的必要性。
    
    两个挂载点(router + companyRouter)都改成 requireAuthOrInternal,两处
    :companyId/:id 的 param 中间件加了与 company.js 一致的 req.user?.internal
    旁路。route-auth-gate.test.js 同步更新断言。全量测试 1469/1473,零回归。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
    yibo authored
     
    Browse Dir »
  • yibo authored
     
    Browse Dir »
  • 排查「前端刷新不及时/没有打字机效果」发现现状已是 SSE,不需要换 WebSocket,
    真正缺的是三件独立的事:
    
    - 打字机平滑:后端把 ACP chunk 按 10 字符切片再发 SSE,前端用定时器队列
      (agentChatEvents.js 的 createTypewriterQueue)匀速吐出,抹平网络突发。
    - 打断并发送:执行中解锁输入框,新增 ⤴ 按钮与 ⏹ Stop 视觉区分;stop 端点
      改为轮询确认 agentChatLocks 真正释放(3 秒预算)再返回 cleaned 字段,
      前端据此决定直接发送还是走"强制发送"兜底。顺手修了一个真实并发漏洞:
      同一 agentId + 同一 convId 的并发请求过去完全没有闸门,只是一直靠前端
      textarea 的 disabled 属性侥幸没被触发。
    - 串台加固:把 handleEvent 分发逻辑抽成不依赖组件实例的纯函数
      (agentChatEvents.js),补上 9b1c3f1 那条不变式的回归测试。
    
    已用真实 Claude CLI 会话(非 mock)在浏览器里验证打字机效果、打断并发送
    全流程、以及纯 Stop 无回归。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01HDtmdnE6pay9BhwZDAKK6M
    yibo authored
     
    Browse Dir »
  • 按 39 号设计文档落地 ceo 常驻监督:company.js 的 goals/tasks 端点
    放行内部令牌自环调用,POST /tasks 支持 draft 模式(agent 自主提任务
    不再立刻烧预算),ceo 补雇进公司创建流程;task-settle 新增事件驱动
    唤醒 + 30 分钟兜底轮询;graph-engine 的回退熔断收敛时顺手回写一条
    draft task,形成"卡住 → 自动/ceo 判断 → 重新规划"闭环。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01BwG4b7Nq1NLR9eeE3M9Us9
    yibo authored
     
    Browse Dir »

  • 2026-08-28 把本地 mycompany/innovator-fde-trial 同步到生产时手搓合并脚本踩过两个坑:
    本地库和生产库同名字段的物理列序可能不同(SELECT * 位置对齐会静默写错列),以及
    graph_runs/graph_run_nodes 循环外键的回填 UPDATE 必须给关联子查询加表别名。
    
    把手搓版本整理成 scripts/sync-company-to-graph-db.js(按列名对齐 + 支持 --dry-run),
    并在 graph-db.js migrate() 和 production-deploy.md 里记下这两个坑,供下次同步复用。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01UpkWPa2CmuWJFJZksqvxWB
    yibo authored
     
    Browse Dir »


  • 跟已发布的 Artifact 页面同一份内容,存本地留档(docs/done/open-api-manual.md
    是内部真相来源,这份是排版过、可以直接发给外部团队的版本)。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • POST /api/open/agents/:agentId/invoke(h3-video-prompt 这类不挂公司的
    全局 Agent)跟公司级 invoke 是同一套请求体/轮询流程,只是端点和「查
    存在还是查雇佣」不同,补一段区分说明 + 示例。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • docs/README.md 索引条目同步从 todo/(当前主线)表格挪到 done/ 表格,路径改指
    done/system-design/。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • 验证阶段真查出一个 Phase 1/2 都没顾上的真实漏洞:agent-chat.js(/api/agent/*)一直靠
    :agentId 里的 "companyId:role" 命名空间前缀(locator.companyStateDir 解析)区分会话
    属于哪家公司,但这个文件从只挂了 requireAuthOrInternal(登录即可),没有归属校验。
    curl 验证:任意登录用户对 GET /api/agent/{别人的companyId}:{role}/conversations
    依然 200,能跨租户读别家公司的 agent 会话。
    
    修法跟 company.js 同一套思路:router.param('agentId', ...) 解析 : 前的 companyId 段,
    过 canAccessCompany。三个例外:①没有 : 前缀的全局 agent(master/org-innovator 等,
    落 _global)不做归属校验,本来就全系统共享;②内部自环调用(req.user.internal)直接
    放行,招聘/训练自动流水线要能打到任意公司名下;③admin 不受限制。
    
    新增 agent-chat-company-gate.test.js:直接拿 Express 暴露的 router.params.agentId[0]
    单测这个 param handler,覆盖同公司放行/跨公司404/admin不受限/公司不存在404/全局agent
    放行/内部自环放行六种情况。顺带修好一个连带失败的既有测试文件
    (agent-chat-tenant-isolation.test.js,zz-tenant-alpha/beta 同样是从没真正建过的
    虚构公司 id)。
    
    验证:curl 复测跨租户读会话从 200 变 404,owner/admin 依然 200,全局 agent 不受影响;
    真实浏览器用全新账号确认 CompanyDashboard.vue 对"没有可用公司"已有现成空状态,不需要
    新写前端代码。全量 vitest 1433 passed,3 个无关既有失败不受影响。
    
    至此 38 号文档 Phase 0/1/2/3 全部完成。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • company-service.js:company.json 加 ownerId(无 SQL 表,纯 JSON 字段);create() 接收
    ownerId;list({ user }) 按传入用户过滤,不传就不过滤(company-heartbeat-service.js 等
    系统内部巡检要看全部公司);新增 canAccessCompany(company, user) 作为全仓库唯一一份
    归属判据(admin 不过滤,判负一律 404 不是 403,不暴露"这个 id 存在只是不是你的")。
    
    company.js 用 router.param('companyId', ...) 统一收口(约 50 条路由,含 okrPath() 系列
    动态路由)。graph-run.js 的两个挂载点参数形状不一样,设计阶段的描述不准确,实现时才
    发现:companyRouter 唯一路由是 /:companyId/graph-runs 直接查;主 router 全部路由是
    /:id/...,:id 指的是 run 不是公司,改成先查 run 的 company_id 再判断,run 不存在或
    公司不是你的统一回"run 不存在"。devloop.js 用 :pid 反查 company_id;POST /projects
    单独校验 body 里的 company_id(放在基本字段校验之后,避免归属检查打乱输入校验的错误
    优先级);GET /projects 按归属过滤列表。
    
    okr.js 最终没有按原计划接入 companyId 归属校验——实现前查证发现 OkrDashboard.vue
    挂载的 /okr 页面全站没有任何导航入口指向它,是个孤儿页面,给访问不到的页面建"选公司"
    前端交互不划算,改成 requireAdmin(跟 dream.js 同款),先堵住直接拼 URL 看到跨公司
    聚合数据的口子。真正在用的公司级 OKR(company.js 的 /:id/okr)已随 company.js 一起隔离。
    
    存量数据迁移:scripts/backfill-company-owner.js(npm run backfill:company-owner),
    两家存量公司已划给种子账号,幂等验证过。
    
    8 个既有测试文件用的公司 id 都是从没真正建过的字符串标签,挂锁后集体 404——新增共享
    helper server/tests/helpers/ensure-test-company.js 修复;两处原有的"跳过已有
    company.json 的目录,那是真公司"防御逻辑,判据从"有没有 company.json"改成"ownerId
    是不是 -1 这个测试专用标记",否则新出现的测试夹具会被误判成真公司永远不清理。
    
    验证:真实 curl 走过(admin 看到全部存量公司、新用户看到空列表、新用户拼 URL 访问
    别人的公司 404、新建公司 ownerId 精确落在创建者、admin 和创建者都看得到其他人看不到);
    全量 vitest 1427 passed,3 个无关既有失败不受影响。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • 给此前完全零防护的 company.js/okr.js/tasks.js/devloop.js/graph-run.js(两个挂载点)/
    arena.js/config.js/evolution.js/whatsapp-auth.js 挂 requireAuth;dream.js 挂 requireAdmin
    (系统级经验汇流视图,只有 admin 能看)。open-api.js(自己一套 OPEN_API_KEYS)/auth.js
    自身/health 端点按计划排除。这一步只挡"没登录",公司归属过滤留到 Phase 2。
    
    agent-chat.js 不能直接挂 requireAuth:company.js(自动建公司/招聘后自动训练)、
    task-settle.js(goal 汇报回调)三处服务端自环调用会 fetch 自己的 /api/agent/* 端点,
    拿不到任何用户 cookie,直接挂锁会打断这几条核心自动化链路。新增 requireAuthOrInternal +
    jwt-auth.js 的进程内 INTERNAL_TOKEN(启动时随机生成,只活在内存里):自环调用带上
    x-internal-token 头放行,其余情况仍要求真实登录;三处调用点同步改造。
    
    17 个既有测试文件、67+ 处用例直接拿 supertest 打这些路由,从没设过登录 cookie(测的是
    业务逻辑不是鉴权)。没有逐个补登录态,改为 requireAuth/requireAdmin 在 NODE_ENV=test
    时默认放行,除非显式 FORCE_REAL_AUTH=1;新增 route-auth-gate.test.js 在放行关闭状态下
    做结构检查(router.stack 里中间件是否真的排在所有路由前面),确保"锁真的挂上了"这件事
    有测试兜底,不被业务测试的默认放行悄悄掩盖。
    
    验证:真实 curl 走过全部路由(无 cookie 401、admin 登录全通、非 admin 能看公司但
    dream.js 403);手工删过一行 requireAuth 确认守卫测试真的会红;全量 vitest 1427 passed,
    另 3 个失败与本次改动无关(stash 验证过改前改后一致,系仓库并发工作遗留)。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • 远程部署前置需求:登录鉴权 + 公司级多租户隔离。后端 auth.js/jwt-auth.js(注册/登录/
    JWT-cookie/OAuth)本来就已经可用,这次只是把它接到前端。
    
    - scripts/seed-admin-user.js(npm run seed:admin):幂等种子脚本,建出 admin/hex1234,
      role=admin。
    - web/src/composables/useAuth.js + views/Login.vue:登录态 + 登录页。
    - router/index.js 全局 beforeEach:未登录跳 /login?redirect=...,登录后带着原目标跳回。
    - main.js 全局 401 拦截器:cookie 中途过期同样兜住,不止页面切换那一刻。
    - AppNav.vue:显示用户名 + 退出登录。
    - 顺手修:App.vue 原来无条件渲染 MasterChatDrawer,登录页也会露出这个悬浮入口,
      改成登录且非登录页才显示。
    
    业务路由还没加锁(Phase 1 的事),登录后依然能看到现状全部数据,符合这一阶段的验收边界。
    真实浏览器走过一遍全部流程(跳转/登录/跳回/直接刷新受保护路由/退出),npm run build 通过。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • 现状 org graph 按 company_id 单例(27-P2 标题原文即"公司级"),塞不下 HR/财务/市场这类
    跟"交付流水线"无关的公司常设职能——system/agents/hr/("招·留·管·退")本体已存在却从没
    被装进任何图,全靠 fire-and-forget chat 招聘,没有图执行那一套断点续跑/审计轨迹。
    
    提议把作用域从 company_id 升级为 (company_id, department_id),一家公司可装配多张部门图,
    每张仍保持人工固定/慢变/可审计——不是把角色图变成动态生成,只是允许公司持有的图从 1 变成 N。
    
    全仓库调用点扫描(fork)结论:改造面是最初估算的 4 倍。真正的单点真相在
    work-graph-db.js:readDefGraph 的裸 SQL 不变式(graph_id === company_id,写进了 §四.A.2
    设计文档),坐在 graph-engine.js 执行引擎的热路径上,不在 org-graph-service.js 那层服务
    API;另外还有两个易混淆的服务文件(org-graph-service.js / graph-service.js)共同维护一份
    必须字节级一致的重复唯一索引、独立的 graph-seed-service.js 对账子系统(8 处裸 SQL)、
    company-hire-org-layer.test.js 专属测试套件、orggraph-planning/task-planning 两份 agent
    人设文档把"只有一张图"写进了自我认知——都需要一并改。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »

  • yibo authored
     
    Browse Dir »
  • 在 prd-planning/agent.md 加了「描述性语言扫描」+「内容深度下限」+「业务度量翻译」三段
    具体操作(对应 36 号文档训练出的 SKILL.md Step 4/5),soul.md 加一条对应工作原则。
    用同一个 e2e-demo 首页任务重新跑了一次端到端回归验证:新 PRD 把"大图/简洁大气"等形容词
    逐条翻译成量化规则,最终产出的 index.html/style.css 精确对应这些数值(视觉元素
    min-height:320px、区块间距 96px/56px 等),文案不再卡在"非空"这条线——训练效果在
    真实任务里得到验证。
    
    回归过程中发现一个新的、独立于本次改动的引擎缺陷:org-coder-test 被反向打回后产出
    「建议重跑 org-coder-validator」的诊断文件,引擎把诊断文件里的 infra_flake 标记当成
    了这个节点自己的执行结果,导致原地重跑但从不路由到诊断建议的目标节点,陷入没有熔断线
    的确定性死循环。记进 30 号文档,留待后续修复。
    
    Co-Authored-By: Claude Sonnet 5 <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 »

  • 补记 commit fadb6fa 的实现记录:证据闸门选了"拦截"不是"降级"(降级等于还是采信
    了分数,只是换个说法);goal-benchmark.json schema 完全不用改,evidence 早就是
    benchmark-validator/agent.md 教的既有字段,只是从没被 goal-contract.js run 读过,
    让 runBenchmark 多看一眼姊妹判词文件即可,没有发明新格式;C 的实现只更新了真正
    写分数/证据的 benchmark-validator,不是最初以为的 coder/unit-tester。
    
    §三推进顺序标注全部完成,并记录了样本量不足的遗留风险(只有一次真实回归验证过
    证据闸门,关键词表覆盖度与拦截后的连带影响都还没有大量数据支撑)。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • 补记 commit bab675c 的实现记录:按"第一版先做前者"落地(blocked 等人工,
    装配自愈留后续),以及中途把测试套件炸穿 75 个用例又收窄回来的完整过程——
    根因是 missingBodyDefinition 查真实文件系统,测试夹具的假 systemAgentId
    天然"缺失",改法是借用已有的 boundaryGuardApplicable 判据(只在真实执行器
    下生效),不是发明新判据。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • 用户问"任务结果差是 agent 能力、架构、还是 graph workflow 问题",这份文档是
    书面复盘:按发生顺序分四类——图/模板设计缺陷(31/33 号,已修)、招聘装配可靠性
    bug(32 号已知问题的新样本)、一个复盘时新发现的架构缺口(missingBodyDefinition
    完整性闸门只在招聘路径上调用,graph-engine.js 的执行核心路径 advanceOne 一次
    都没查,本体不完整时没有第二道防线,静默拿空提示词跑真实 LLM)、agent 能力
    (不是问题,两次订正过"没工具做不到"的误判,且有正面即兴发挥的例子)。
    
    结论:主要是架构问题 + 一个具体可靠性 bug,不是模型能力问题。
    
    提出两档改进方案供讨论:
      低成本(建议直接做)——把完整性闸门接进图执行前置检查(提案 A)、
        控制台展示验收证据可见性(提案 B,纯 UI 不改行为)
      大改动(建议先讨论优先级)——标准化视觉验收工具(提案 C)、
        引擎级证据闸门(提案 D)
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »
  • §5.1 原来断言"没有浏览器工具,物理上做不到",复盘时对照 p-bkhylu 的 org-coder
    (同样只有 bash/read_file/str_replace(+write_file),没有专门的浏览器工具)却
    真跑出了 Playwright + headless Chromium 测试,才发现这个判断错了:仓库自带
    playwright 依赖,bash 里 `node verify.mjs` 沿目录树能 require 到仓库根的
    node_modules,这条路今天的 coder/unit-tester 同样走得通。
    
    真正的差异不是工具权限,是 unit-tester 的 agent.md 从未填充过(32 号文档那类
    问题)、没有任何角色指导,而 org-coder/coder-validator 都是正常填充过的成熟
    本体。根因从"平台缺工具"改判为"这次没有指导 agent 主动想到",是一个不一样、
    也更能采取行动的结论。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse Dir »