-
代码修复： - SessionPool 的 scope 参数从未真正从 graph-engine 传到 AgentManager，导致 fan-out 场景下同一 agent 的并发调用会撞会话键；补上生产接线（graph-engine.js/agent-manager.js） - advanceTree 改成 Promise.allSettled 并发推进兄弟子 run（原来只推最深的一个） - graph-real-chain-smoke.test.js 补齐多节点/回退边/双层熔断的真实链路覆盖 真实验证： - 27-P3B 最后一条验收（org 层回退边指向 subgraph 节点）用隔离 worktree 真实 Claude CLI 跑通并记录证据（§六quater） - 27-P3B 正文里 W5/W6/W7/W9 的"仍未验"备注核实后发现均已被此前的真跑验过，只是没回填； W8（重新规划组织按钮）此前确实没验过，本轮用隔离 worktree + 真实浏览器点击补验 文档收口： - 27-P3B、27-P4 两份文档功能与验收均已完整，移入 docs/done/，更新全部交叉引用 - T5（账户欠费门真实计费接口）按用户决定移入 docs/todo/future/，不阻塞收口 - 订正两处过期判断：graph_edge_contracts.role 列早已落库、CONVENTIONS.md 非 spec:extract 生成物 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JnCKUFSGvdz4SY7BvYWdMU
-
## 移进 done/ · 27-p3c-goal-task-model.md —— 五批实施完毕，§15.5 / §16.8 的后续项也全部收掉。 新增 **§十七**：欠账清单对账、边界守卫从「乱扣帽子」改成「留证据不判罚」、 测试污染生产图库（第四次踩同一族，但换了个方向进来）、那条卡了两天的 run， 以及 **§17.5 真跑验收** —— org-planner-sdd/benchmark/validator 全 success、 work run completed、父节点自动拉回、org-coder 起实现层子图、 org-coder-validator 判 fail 走回退边打回 impl（loopCount 1）。 **返工闭环第一次由真 agent（不是注入的假 executor）走通。** · 27-p3c-batch3-handover.md —— 四条复核结论全修完、§五 那条 run 已解开， §七 待办全部打勾。从待办转为**事故记录归档**：§六 那几条多会话协作规则是真踩出来的。 两份的相对链接都已重指（done/ ↔ todo/ 跨目录），no-dead-path-references 守卫通过。 ## 留在 todo/ 的，状态说清楚 · 27-graph-agent-architecture.md —— 状态行校准。那一行是别人判断「能不能搬 done」的依据。 · 27-p3b-real-run-runway.md —— 加状态行：验收 7 ⛔ 真跑不成立（readme-writer 混进 org graph，**未修**）、2/4/8/9 未在干净环境验。缺陷② 的**根因**今天修了， 但特意写明「**根因修了不等于验收点验了**」—— 不然下一个人会照着状态行当成验过。 · 27-p3-p4-work-graph-console.md —— 在索引里写明留 todo 的原因： §十 那笔「真实路径 smoke 进 CI」的欠账未还。 · 28-followups.md —— §3.3 标已修（含「GET /info 的 404 闸门仍没修，别当成修过」）； §五 守卫表加两行（graph-db-prod-guard / heartbeat-company-scoped）， 并补第七条的来历。 ## docs/README.md 索引补上新增的 done 条目与 P3B / 28-followups 行，主线说明改成 「当前未完成的是哪几件」——原来只说完成了什么，读的人得自己推。 全量：138 文件 / 1292 测试全绿。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
companyService.get 已经在读这个文件，零新增读路径；建表要多一张表、 一套读写、一次迁移，而目前公司级配置项只有这一个。涨到 3 个以上时 再考虑建表。 这是 P3C 最后一个开放问题，§十一 至此全部关闭。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
R-20.6： 1. 退役 /api/goals 与 /api/company/:cid/goals 两个 OKR 别名，确认执行 2. goal 级验收仍用 org-validator，在 goal 层再调一次同一个本体。 不复用 task 级结论 —— 两次验的是基数不同的东西：task 级问 「这一个 task 的 task-goal 达成没有」，goal 级问「N 个 task 合起来人要的东西做出来没有」。单 task 的 goal 跳过这次调用。 goal 状态机加 failed，判词落 goals.verdict 3. 预算先不考虑，不做 goal 级闸门；但 planning_tokens / validation_tokens 两个记账字段保留 —— 它们不是闸门，是让 goal 层那两次 agent 调用的花费可见 4. queued 开放改 depends_on。当初担心的「改完位次怎么算」不成立： queuePosition 只按 priority→seq→created_at 排，depends_on 决定 的是够不够格出队，两者正交 5. 两套任务体系统一到 tasks 表，新增 §十二（批 5） 定案 5 核实出一个反直觉的前提：两套不是并列的，新体系的回调链路 长在旧体系身上 —— reportRunOutcome 收敛后调的正是 /api/agent/task/report。所以「删掉另一套」= 删存储与会话反推 （system/tasklog + TaskService.getAggregatedTasks），不能删入口 与回调：/task/dispatch 的 URL 与请求体写在 tools-base.md 里， 改它等于同时改所有 agent 的提示词。 tasks 表为此吸收三个字段（executor / assignee_agent_id / parent_task_id）：agent 派单与 graph 执行的载体确实不同， 硬说成一回事是骗自己；调度器只管 executor='graph'。 顺带修好：派单去重从扫目录变一条 SQL，两套 T- id 合一。 开放问题 2/4/6/7 全部关闭，只剩 5（max_parallel 放哪）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
R-20.5 四条： 1. task-planning agent 提进 v1（原计划 v2 人手拆）。产出一律 draft 清单，人确认编辑后才下达 —— 那一步是唯一一道成本闸门， 拆出 5 条 task 就是 5 份 DEFAULT_TASK_BUDGET 2. 并行仍留批 4，v1 只排队（max_parallel_tasks=1，唯一索引不动） 3. manual 任务不参与自动出队：startRun(manual) 只点亮入口就停下等 /next，而 run 已经是 running 占着坑，自动拉起会堵死队头 4. 上游失败 → 下游自动推导为 blocked 并标红，给「重跑上游」和 「强制放行」两个出路。blocked 每次 tick 重算而不落死， 上游重跑成功后下游自己回 queued 定案 1 牵出一处新缺陷：task-planning 跑在 goal 层、任何 run 存在 之前，它烧的 token 没有预算池可扣 —— 正是 defaultPlanWorkGraph 注释里点名的「隐形的一半花费」在 goal 层的新实例。上一轮刚以 「零消费方」为由砍掉的 goal 级预算字段，以记账字段 planning_tokens 的形式回来（闸门仍不做）。 链路照抄 defaultPlanWorkGraph 不另造：调 agent → 校验 → errors 原样回喂，最多 3 轮；3 轮不过降级成 1 条同描述的 task，绝不能把 goal 卡在 planning。新本体必须与 _registry.json 登记同 commit， 否则 template-refs.test.js 当场把 CI 跑红（§八.21 有前科）。 验收 19-24 新增：拆分正常 / 失败降级 / 记账 / 不该花钱的路径不花钱 / 上游失败下游标红且可恢复。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
控制台走查暴露的「一个 company 只能有一个任务」，根因不是并发约束， 是「人类提的需求」和「机器执行的单元」被压在同一条 root graph_run 上。 三个实地核实的前提，让这次不是发明新概念： - 27-NAMING §四 早就定义了 goal 1 : task N 的基数 - graph_runs.goal_id / task_id 两列早就在，company.js 注释也写着 「三者基数不同不可混用」—— 但全仓库没有任何写入方，goal_id 是悬空外键 - G- 前缀已被 OKR 正名释放；/api/goals 与 /api/company/:cid/goals 这两个 OKR 向后兼容别名全仓库零调用方，可以退役后把路径要回来 设计要点： - goals / tasks 两张新表 + graph_runs 新增 run_status='queued' - queued 的唯一理由是把出队的并发临界区交给既有唯一索引兜底： idx_graph_runs_one_active_root 覆盖 ready/running/paused 而不覆盖 queued， 超发会被索引直接拒绝，不需要应用层的「先查后插」 - 排队推翻了 P3「拒绝而不排队」的定案，但那条定案的理由（没有出队 worker = 静默丢任务）今天仍成立，所以调度器的四个触发点是功能主体而非收尾 - 已下达的描述冻结：入队即写 task-goal.json 并被 describeTask 消费， 改库不改 artifact 会让两份对不上，两份都改等于篡改审计输入 - 现有 T-${Date.now().toString(36)} 在「一个 goal 批量建 N 个 task」下 同毫秒必撞，且 tasks.id 是主键 —— 改用仓库既有约定的 4hex 后缀 R-20 四条定案回记至 27-requirement.md。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
第四次真跑的断点：org-planner-prd 失败，它自己的归因原话是 「不是上游没产出，是它的产出**结构上到不了我手上**」。核实属实 —— 上游 brd.md / contract.json 落在**节点私有目录**，prd 的提示词只有它自己的私有目录 + 只读 artifacts/，而 brd--success-->prd 这条边**不携带任何文件引用**。 边一直只承载控制流（condition/edge_kind/fail_reason），R-4 要的「边的输入输出」 被落成了从 output_ref **推断**的 UI 展示、没有实体，而推断的那一端下游读不到。 ## 定案（27-REQ R-19） - 建 sqlite 表而不是 files.json：JSON 会重演 _registry.json 的并发重写与 git 冲突 （本轮刚被它咬过，W13 只能把 usedCount 挪去另一个被 ignore 的文件） - **两类数据流都要**：纯边绑定表达不了 R-9.3 的「planner 生成、validator 执行」—— org graph 是 planner→coder→validator，acceptance 跳过 coder，这两点之间没有边 - workspace 根**代码推导不入库**：存绝对路径会烂，W13 清的那 10 条 legacy_path 悬空行就是这个病。表里只存相对公司根的路径 - 路径走 tasks/{taskId}/，不走 workspace/：后者语义是「Agent 自治领地、框架不干预」 （06-沙盒自治），与「框架管着、可检索的交付物区」是两种所有权 - 契约(kind)与实例(path)分规划时/运行时两阶段 → 引擎可在节点跑之前校验 「你声明要吃 brd，但上游没人产 brd」，这类图结构错误此前只能等跑到那步才发现 ## 实现 work-graph-db：graph_files（实例）+ graph_edge_contracts（契约）两张表。 graph_files 的当前版本走**部分唯一索引** WHERE superseded_by IS NULL —— 与 idx_org_graph_nodes_company_role_active 同一模式：要「同键只有一个活的」 又要留历史，条件得写进索引而不是靠删行。API：recordFile / findFiles / declareEdgeContract / edgeContracts / inboundContracts / rebuildFilesFromNodes。 graph-engine 两侧都接： - 输入侧 describeInputs：按**入边声明的 kind** + **本 task 共享产物** 查实例， 把绝对路径拼进提示词。声明了却查不到的**明说缺哪个 kind**，不静默省略。 刻意不是「注入一句『索引在某文件，自己去检索』」—— 那仍靠 agent 自觉拼路径， 真跑已证明它拼不出来；引擎直接递到手上，不给它猜的机会 - 产出侧 indexNodeOutputs：节点 success 时登记落盘文件，kind 先看出边声明、 再按文件名兜底；attempt-*.json 是引擎自读的归因文件，不当产物登记 文档：27-REQ 新增 R-19（四条，含两段原话）；27-P4 §4.6 按定案重写 （原「公司根一个 files.json」作废）。 测试 788/788 全绿。后续（下一轮）：规划侧声明契约、goal-contract 路径归并、 前端「输入输出」tab 展示解析结果、真 CLI 复验 prd 能拿到输入。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
界面走查（真 server + HTTP + 真 AgentManager，底层 mock 协议）已把 manual 模式全流程点通：org 节点起子图 → 下钻 work graph → 单步 → 第 3 步触发回退（徽标 0/3→1/3、run 级 1/5 双层计数同时可见）→ 归因记录与 remediation_note 完整送达 → 收敛后父节点结算、左栏前移。 mock 侧补两处缺失接线（都是「四环漏一环」，非新功能） - ClaudeCliProtocol._sendMockPrompt 按 agent 类型查 fixture：图执行侧的 agent 名带公司前缀（resolveAgentName 返回 {cid}:{id}），fixture 不该 按公司复制一份。DevLoop 侧名字不含冒号，行为不变 - graph-engine.defaultAgentExecutor 接住 mock/files 事件：此前只有 DevLoop 的 loop-controller 接，图执行侧没接，于是 mock 下 readNodeProduct 永远找不到 attempt-{n}.json，validator 系节点恒 blocked。 写入限制在节点产物目录内，越界丢弃并留痕 新增 5 份 P3 fixture（workgraph-planning / prd-planning / sdd-planning / coder-validator / validator-triager），coder-validator 用 sequence 演示 一次回退。图必须放 chunks 不能只放 result——callAgent 的 output 来自 流式 chunks，session/result 的文本不进 output。 控制台入口：CompanyDashboard 加「🕸️ 执行控制台」按钮（路由早已注册， 此前无任何入口，只能手敲 URL）。 scripts/p3-demo-setup.js：手工测试准备脚本（雇人+写图+起 run），头部 写明它是两个已知缺口的绕行，缺口修好后第 1 步即可删。 _registry.json 补齐 6 条本体登记（brd/prd/sdd-planning、goal-benchmark、 benchmark/testdata-validator）——同轮新增的 template-refs 防线测试正是 因为缺这 6 条而变红，防线抓到了「交付与报告不符」。 文档 - 27-REQ R-18：招聘归 workgraph-planning（方案 a）、停用 mock 改真 CLI - 27-P3B 真实运行前置（新增）：11 个工作项分三批，含现状核实 10 条证据 （seedTemplates 无运行时调用方、10 条悬空 company_hired 行、 FAILING_VERDICTS 不含 "fail" 导致验收假放行等） 测试 719/719 全绿（66 文件）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> -
R-16（归因由专职 subagent 做，回退边多条）： - §四.D.2.2 归因改为 org-validator work graph 内的 validator-reflection 专职节点，与 DevLoop 的 Integrator/BugTriager 分工同构；给出四类 fail_reason 取值与 DevLoop 四分类的对照 - §四.D.0 子 run 收敛改为透传三值（success/fail + fail_reason + remediation_note），归因结论才能穿透子 run 边界供父层选边 - §四.D.2.1 熔断改为双层计数：单边 loop_count 防同路径死循环，新增 run 级 backward_count 防"换个借口继续退"——多条回退边各自计数会把 硬顶架空成 3xN；infra_flake 不烧任何计数 - §三.7 写入前校验新增第五项 fail-fallback-edge（强制兜底边） - schema：graph_runs 加 backward_count - 任务表加 T13/T14，验收标准加 9b/9c/9d - skill_defect 属 L4，v1 保留归因取值但动作降级为挂起等人工 base agent 四段式（新增 §九bis）： - 核实后原表述"已强制一套四段式生命周期"只对一半 - Context Flush / P0 事前阻断阀 / OKR 联动确实在跑 - Hot Swap 换技能包静默失效：system/skills/ 目录不存在， agent-chat.js:1908 的 existsSync 守卫使其空转且不报错 - 后果：EXECUTE 才拿破坏性权限只剩 prompt 话术约束，无机制保障 - phase 参数无取值/顺序校验，且被直接拼进文件路径 需求文档：补回 R-15.1 全文、R-15.4 后半、R-15.5、R-15.6 及速查表 对应行（此前被误回滚丢失），新增 R-16 条目。R-15.3 的命名表保留 NAMING §三 重写后的版本，未还原旧版。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
company-goal / task-goal 按作用域命名，subagent-goal 按执行者命名，轴不一致。 统一为 subtask-goal。 27-REQ R-13.1 的原话引用保留提出时的用词「subagent-goal」不改写——原文照搬 文档不参与批量替换（这是上一轮误改 R-10 原话引用留下的规矩）。新增 R-14 记录 本次定名及其与 R-13.1 的关系。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
起因：逐条比对 27-REQ 的原话与 P2 v0.4，发现四处偏离，其中两处是设计悄悄 改变了原意。本次修正并落定。 代码（P2 §五 T0）： - company.json 新增 goal 字段（company-goal），create({id,name,goal,description}) - POST /api/company/create 与 update() 同步支持 - 修的是一个实打实的遗漏：R-6 原话是"写入 company 的目标和描述"（两个字段）， 而 create() 一直只有 description。orggraph-planning 规划流水线的主依据本该是 company-goal，此前根本拿不到。 文档定案（R-13）： - R-13.1 goal 三层递归：company-goal / task-goal / subagent-goal，与"验收逐层 递归"对应。澄清 R-12 说的"唯一的那个 goal"其实是 task-goal；三个验收 agent 保持通用不按层级拆分。记录一处待定：subagent-goal 按执行者命名，与另两个的 作用域命名轴不一致（按轴应为 subtask-goal）。 - R-13.2 公司类型完全由 orggraph-planning 推断 —— 这条**推翻了我自己记的一个 缺陷**：审计时我把"不加 type 枚举字段"记为擅自偏离原话，实际那正是所需， 当前设计无需改动。 - R-13.3 新 agent 从 system/templates/base 元 agent 继承骨架（自动带四段式 RESEARCH→PLAN→EXECUTE→VERIFY）+ agent-creator 填充，而非直接走 needs_training 全量培养；新建一律 scope='company'；innovator 训练是可选后置步骤。 这是 R-9.2"所有 node agent 由元 agent 继承生成"在 P2 的落地点（新增 T5b）。 - R-13.4 org graph 强制单入口，原 open question 关闭。 顺带修掉 P2 的一处内部不一致：§六 承诺"提供手动触发 orggraph-planning 的端点" 给存量公司补图，但 §四.3 API 表和 §五 任务表都没有。已补 POST …/org-graph/replan。 另更正 R-11 中"代码层未执行"的过期表述——OKR 正名已于 74ea1ff 实施完毕。 回归：npm run test:unit 652 例全绿。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> -
改名：task-benchmark / task-test-data / task-test-script → goal-benchmark / goal-test-data / goal-test-script 理由（推翻此前"验收标准跟着一次 task 执行走"的论证）：关键区分是基数。 一个人类需求描述 = 1 个 goal，是验收的边界；而 goal 在图中会分解出 N 个 task （并行分支、下钻的 sub agent）。验收回答的是"人类想要的东西做到了没有"， 这是 goal 级判定；挂在 task 上会导致"以哪个 task 的验收为准"无法回答。 NAMING §一 作用域表补入 goal / task 两行及其基数定义；§四 重写选型理由； §六 增加与 §四 的辨析注（OKR 从 goal 解放后，goal 被重新赋予"人类需求"新义）。 连带： - acceptance.json 的键改为 goal_id - work_graphs schema 补 goal_id，与 okr_node_id / task_id 并列（三者基数不同， 分别是 1 / 长周期归属 / N，不能用单一字段表达） - 新增 27-REQ R-12 记录本次决策及其推翻关系 修复上一轮的一处失误：全局改名误改了 27-REQ 中的原话引用（R-10 一度被改成 "goal-benchmark 或者 goal-benchmark"）。原文照搬文档不得被批量替换触及，已还原。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
此前 27 系列全部是对用户需求的转述与结构化解读，原话一句都没留存 （搜 "judge-loop-jump"、"元 agent 架构来继承生成" 等关键短语均 0 命中）。 转述会漂移，出现"当初到底怎么说的"争议时缺少可回溯的依据。 格式与定位对齐仓库既有惯例 docs/prd/newfunction/_spec/requirement.md （DevLoop 的原始需求页："用户提出的需求原话照搬，再做结构化解析"）。 内容：11 条需求原话逐条照搬（R-1..R-11），含笔误一律保留 （validtor / syste agent / intergration / fin in / object-key result）， 每条标注落在哪份文档的哪一节，附"需求 → 设计落点"速查表。 同时记录三处关键推翻关系，便于回溯设计演变： - R-7 推翻了"benchmark/test data 是系统基础设施"的误读 - R-9.1 推翻了 P2 v0.1-v0.3 的静态汇报结构建模及 A/B/C 三个折中方案 - R-9.4 使跨公司污染风险及其三个缓解方案全部作废 另澄清 27-EXAMPLE 的「配图工厂」是为走查虚构的场景，非用户原始需求。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>