1035 Commits

Author	SHA1	Message	Date
lhk229	397e9dc3fc	evidence 引用整份下发，拒绝理由报全三元组 ... run 23 那次 agent.acceptance_update 被拒的真实理由是 「Acceptance Graph evidence 缺少持久动作回执：action-2976e1b70fc2b12177c8f2d4」—— 而同一个 actionId 下一轮就通过了，回执也早在 9 秒前落盘。 原因是 evidence 引用是 {agentId, runId, actionId} 三元组， acceptance_evidence_tools_at 按三元组整体做 key 查回执，三者任一对不上都落空。 observation 只给了 sourceActionId 一个碎片，另外两个字段要模型自己回忆，它第一次 回忆错了。而错误信息只打印 identity.2，把「runId 写错」报成「这个 actionId 没有 回执」——模型据此得出"我的读取没落盘"，排查的人也会先去查时序和落盘顺序。 两处都改： 1. file.read 的 observation summary 给出整份三元组 （sourceAgentId / sourceRunId / sourceActionId）。反正 validate_fast_gdd_evidence_identity 只接受当前根 run 的回执，合法取值唯一， 本来就不该让模型猜。 2. 缺回执与回执未成功两条错误都报全 agentId / runId / actionId。 取证指令与 playbook 第 5 步同步改成「三个字段原样照抄，不要自己回忆 agentId 或 runId」。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 09:50:59 +00:00
lhk229	9be673513e	修回归：sourceActionId 必须写在 summary 上，detail 到不了模型手里 ... 上一笔把 sourceActionId 追加进 file.read 的 observation detail，同时砍掉了 agent.action_history。但 file.read 的 detail 在投影给模型和事件流之前会被换成 durable receipt 的 safe_detail（只有 path / contentSha256 / lines 三个字段）， 追加的字段根本到不了模型手里。 于是 run 22 变成：模型照着新指令满世界找 sourceActionId，一次也没看到； agent.action_history 又已经被拿掉，它没有任何途径取得 actionId，只能猜；猜错被 acceptance_update 拒，然后判断"此前回执中的读取动作未被验收持久层接受"，重读全文 再猜。29 轮里 28 次 file.read（全是同一页 1-132）、5 次 acceptance_update、3 次拒绝。 summary 是原样保留到模型和事件流的（日志里 `|` 左边那句就是 observe_agent_runtime_file 构造的原文），也没有任何解析方依赖它的形状。改成写在 summary 末尾。用例同步改成断言 summary 带 id、detail 保持原样。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 09:24:20 +00:00
lhk229	95d6068860	取证覆盖校验先折叠重复分页，并让 Fast GDD 尽量一页读完 ... run 21 的 GDD 是 133 行，而 file.read 的默认 maxLines 是 120，于是被迫分成 1-120 / 121-133 两页。模型把第二页读了两遍，把三个 actionId 全提交上去， validate_fast_gdd_file_read_coverage 排序后严格走 `start_line == next_line`： 1-120 → next_line = 121 ✓ 121-133 → next_line = 134 ✓ 121-133 → 121 != 134 ✗「必须从第 1 行无缺口、无重叠地覆盖到文件末尾」 连吃三次 agent.acceptance_update 拒绝，第四次才猜对该交哪两个 id。 同一页读两遍不削弱证据，不该判成重叠。覆盖检查前先按完全相同的 (startLine, endLine, contentSha256) 折叠——内容 SHA 在上一步已经要求全体一致， 折叠掉的确实是同一页的重复回执。真缺口与部分重叠照旧拒绝，有用例钉住。 顺带把取证指令和 playbook 第 5 步改成「每次都传 maxLines=240（上限），尽量一页 读完；确实需要第二页时从上一页的下一行开始，不要重复读同一段」，让典型 GDD 根本 不进分页逻辑。 另记一笔本次排查暴露的可观测性缺口（未修）：agent.acceptance_update 的拒绝理由只 回灌给模型，durable receipt 是 detailUnavailable=true / safeDetail=null，事后在 日志和 agent.db 里都查不到，这类拒绝无法复盘。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 09:10:16 +00:00
lhk229	0ab887c157	file.read observation 自带 sourceActionId，plan 根砍掉 agent.action_history ... run 20 已经把裸计划更新那 5 轮清零（14 → 10 轮），但 agent.action_history 连调 四次：不带筛选拿到 4 条，带 tool=file.read 筛选拿到 1 条，然后又查全量、又筛一次。 GDD 只有 134 行、一页读完，本来就只有一个 actionId，它反复确认了四遍。 查过了，这些结果一直在它上下文里：观察逐轮累积进 prompt，agent.action_history 的 detail 还有 8000 字符的专属额度（context_window.rs 的 sanitize 分支），run 20 全程 compaction=0、上下文从 30507 涨到 33820。所以它不是失明，是对"全部分页"这个词较真 ——拿到 1 条怀疑漏了分页，拿到全量又怀疑混进别的工具。这种"不敢信"加 prompt 约束 没用，得把取 id 这件事从工具变成事实。 command.exec 早就是这么做的：durable observation 直接返回可复用的 sourceActionId， 合同里明写「不要为取得它额外查询动作历史」。这里把同一条路铺给 file.read——成功读 取时在 detail 首行末尾追加 sourceActionId，然后把 agent.action_history 从 plan 根的 工具面整个拿掉。 追加是安全的：agent_runtime_action_receipt_safe_detail 解析 file.read 时只取前三个 `·` 字段（path / sha256 / lines），多出来的字段不参与，durable receipt 与 §13.0 的 取证解析都不受影响。 plan 根现在是五个工具：agent.goal_contract / agent.delegate / file.read / agent.acceptance_update / agent.run_status，其中 run_status 只在 Delegated 阶段开放， 供审批返工时按原 delegationId 取回权威委派合同。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 08:54:14 +00:00
lhk229	2bdf6a732b	plan 根不再维护结构化计划，砍掉 update_agent_plan ... run 19 跑通全链路用了 14 轮，其中只有 5 轮在干活：goal_contract、delegate、 file.read、action_history、acceptance_update。浪费的 9 轮里有 5 轮是纯 plan_update.explanation_only——Runtime 明确标了这个事件——每轮 blocked、每轮烧一次 Provider 调用。 plan 根的流程形状是固定的四步（冻结 → 委派 → 取证 → 交审批），Runtime 自己就知道， 模型维护一份结构化计划不产生任何信息，却提供了一个「看起来像动作、实际什么都不 推进」的合法输出。本地原型没有这个概念，它的工具全是推进动作，也就没有这种输出。 移除不会卡住收束：structured_plan_completion_blocker 第一行就是 agent_runtime_has_structured_plan（plan_revision > 0），从不调用就恒为假，那道门 不参与；plan 根的收束本来就由 runtime.plan_gdd 的审批门管。前端 planSteps 为空时 不渲染步骤条，plan 根的进度改由 current_action / waiting_on / next_step 呈现。 既有的空转自愈本来就会在连续空转后把这个函数摘掉（provider_request_builders 的 idle repair），run 19 第 12 轮那次 acceptance_update 正是被它救回来的。这次只是把 「出事后补救」提前成「从头就不给」。 一并清掉两段已经失效的合同文字：plan/common.md 里的 user.input_request 协议段 （该工具上一笔已从 plan 根移除），以及 update_agent_plan 的用法段。prompt 头部 改成说明「本 run 不维护结构化计划，流程形状固定，每轮只做当前阶段该做的那件事」。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 08:33:10 +00:00
lhk229	a021f18b98	plan 根工具面按阶段开放，只读调用不再清零空转计数 ... run 18：Supervisor 冻结目标合同后一次也没委派，改成反复调 agent.run_status 去查 一个根本不存在的委派，24 轮里 58 次 agent.run_status、0 次 agent.delegate，烧到 超时。两道防线各自失效： · 空转闸门（AGENT_RUNTIME_PLAN_UPDATE_IDLE_LIMIT=4）只在裸 update_agent_plan 且 步骤没变化时累加，而任意非空 actions 都清零。于是「裸计划更新被 blocked → 调一次只读工具 → 计数归零」是一个结构上永远关不上的闸。 · Runtime 其实有一条精准提示「调用 agent.delegate 派出策划子 Agent」，但它在 plan.actions.is_empty() 分支里——模型一调 run_status 就有了动作，提示不再出现， 取而代之的是一份看起来像进展的「已读取 11 个 Agent 状态」。 本地原型没有这个问题，不是因为阈值，是因为它的 Supervisor 只有四个工具且每一个都 推进链路：「调了工具」和「推进了链路」在那边是同一件事，按前者计数就是准的。生产 把两者拆开了却还在按前者计数，工具也是全程可见。 三处改动： 1. 工具面按 durable 阶段开放。合同未冻结 → 只有 agent.goal_contract；合同已冻结 但本根 run 尚无委派 → 只有 agent.delegate；已有委派 → 取证/返工/审批那几个。 run 18 卡死的正是第二档，那一档模型连 run_status 都调不出来。阶段只按 durable 事实判定，不看 Provider 说了什么。 2. 砍掉 user.input_request。这条链路上它是死的：子 Agent 以信封退出后，Runtime 在 parent-wake 屏障处自己按信封原文构造 pending 且不恢复父 run，Supervisor 永远收不 到 needs-user-input observation。广告出去只会让它在别的时点调一次，撞上 Runtime 已装好的那份 pending 而硬失败。playbook 第 4 步与转达提问那条一并改写。 3. 空转判据改成看「本轮有没有能推进 durable 状态的动作」，只读工具不清零。纯只读 调查不受影响——不发裸计划更新就根本不会累加。这条对做游戏那条链路同样有效。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 08:11:12 +00:00
lhk229	9a3b9dce15	0 轮直出可以标原型验证项；坏信封降级成可返工而不是判死委派 ... 两条都是 run 17（571 字完整需求走生产链路）实测撞出来的，都在既有代码里， 都比刚修的台账约束更早触发。 N1 —— round=0 决定被钉死成 default_pending。用户一次把需求说全时全部决定都是 round=0，于是没有任何决定可能成为 prototype_pending；而 validate_decisions 的双射 又要求 prototypeValidationItems 逐项对应 prototype_pending 决定，结果首次 plan.submit_gdd 必被预检拒收，这份稿子也永远不可能带上原型验证项。实测子 Agent 读懂了拒绝理由，代价是把「触控手感」「30 回合是不是真的 8-12 分钟」这类没人验证过 的假设一律标成「默认，待确认」——那是在说谎，它们不是默认值。 round=0 真正要守的是「从未提问过的决定不得声称任何用户权威」，即 answerSource 必须是 default，而不是把状态钉死。改成允许 default_pending 与 prototype_pending 两种，answerSource 仍强制 default，confirmed 照旧拒。双射保持 严格不动——Agent 现在有合法途径同时给出决定和验证项。 N2 —— AGC_NEEDS_USER_INPUT_V1 的解析在 build_static_delegate_structured_result_at 里 `?` 往外传，而这个函数跑在投递回执时，子 run 已经 idle/completed，没有任何一轮 可以把解析错误回灌回去。实测一次 option 多写 `id` 字段就让整条委派 result_failed、 父 Supervisor 直接 needs-reconciliation 停下等人。不是预算设成 0，是结构上没地方 重试；对照原型，它在 run 循环内解析、坏了注入 INJ_ENVELOPE_REJECTED 重试 3 次。 信封格式属于「本次 Provider 输出写错」，与 plan.submit_gdd 的业务拒绝同类，不是 durable 权威损坏。降级成 needs-repair，并把解析失败在哪当返工理由带上（而不是把 那段无法解析的原文照抄回去，那对子 Agent 没有可操作信息）。Supervisor 用既有的一次 返工额度即可自愈。 role brief 补上 prototypeValidationItems：schema 把它列为 required，brief 此前 一个字没提它、也没提双射，模型只能靠撞。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 07:37:28 +00:00
lhk229	853a0147f2	立项策划决定台账改为 Runtime 覆盖，不再要求子 Agent 逐字回抄 ... plan.submit_gdd 此前要求提交的 decisions[] 前缀与 session.decisionsSummary 六个字段逐项相等，prototypeValidationItems 整体相等。那六个字段没有一个由策划子 Agent 生产：id、topic、state、answerSource、round、answerSummary 全部是 Runtime 在用户答题时从问题与答案投影出来的。子 Agent 只能从 Supervisor 转述的委派 task 里 回抄，而权威台账从不注入它的上下文，拒绝 observation 也只有一句"未逐项匹配"、不含 差异。于是这个零信息量的回抄成了唯一的提交前提：用户只要自由填写过一次，逐字复现 就依赖一条没有机制保证的 LLM 转述链，抄歪即在 5 次盲重试后 run failed。 同一条相等约束还顺带禁掉了纠错。答非所问的自由填写被投影成 confirmed 之后 （planning_coordinator.rs 的 else 分支对任何非选项答案一律断言 confirmed）， 子 Agent 即便看出绑定错了也不能改——改一个字就过不了相等校验。 现在只守真正要守的那一条：不能声称用户确认过他没确认的东西。 - submit_decisions_respect_session_authority 取代逐项相等，只校验三点： 不得凭空造出没有 session 支撑的 confirmed；不得丢弃用户已作出的决定； 用户亲选的 prototype_pending 不得被改判。 - apply_plan_session_authority_to_submit_input 把 answerSummary、answerSource、 round 直接覆盖进 input，覆盖发生在 durable action identity 重放比对之前， 且只读跨 submit successor 原样保留的 decisionsSummary/prototypeValidationItems， 所以同一 actionId 重放结果稳定。 - topic 与 state 归子 Agent：可按答案真实内容重命名决定，可把 confirmed 降级为 default_pending。这是纠正错误绑定的唯一出口，方向单向。 顺带修掉开场需求长度的三方不一致：入口不设限，AGENT_RUNTIME_TASK_MAX_CHARS 截断到 4000（超长再补一个省略号），而 plan session 的 initial request 硬拒 400。 401～4001 字的需求会让根 run、Goal Contract 与首跳委派全部正常建立，直到策划子 Agent 的 task-start 才炸在 planning-session-projection-failed，且 session 从未 创建、同一根 task 重试必然复现。PLAN_INITIAL_REQUEST_MAX_CHARS 直接绑定上游常量。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 07:09:58 +00:00
lhk229	98abcf4f0d	澄清任务的身份豁免按任务判而不是按工具判 ... 上一笔把豁免收窄成「工具必须是 user.input_request」，只覆盖了转述动作本身。 实际上用户答完后 pending_execution 调的是 run_recovered_game_creator_context_on_fresh_task(root, agent_id, pending.task.clone(), ...)：整条 run 从此改跑在转述任务上，同一 run 后续的 agent.run_status、agent.delegate 全都带着它，而 runtime.current_task 仍是用户 原始请求。 于是 run 15 过了转述那一关，却在续跑第一步就挂：Supervisor 按 supervisorRepair 的要求调 agent.run_status 重读权威合同，动作在等到项目锁之后被 validate_agent_runtime_pending_context 判成「pending action 身份已变化」，仍是 needs-reconciliation。 pending.tool = agent.run_status pending.task = 子 Agent 需要用户澄清后才能继续。delegationId=delegation-4216f572… runtime.currentTask = 做个横版像素解谜小游戏，主角是个能操控自己影子的小机器人。 判据改成只看 task 是不是 Runtime 生成的转述指令。同一个 || 链里的 validate_agent_runtime_pending_action_after_lock 不比较 task，所以豁免面仍然只 有这一条文本相等；agent/task_id/session/run/source 与轮次检查照旧全走。 回归测试补上 run 15 实测的那个形状：同一 run、同一转述任务、工具是 agent.run_status 的续跑动作必须通过，而 task 被改写的同形状动作必须照旧被拒。 三向变异验证：恢复严格比较、整条删掉、把判据换成恒真替身，都会红。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 05:33:48 +00:00
lhk229	ddb8eaec37	澄清转述 pending 不再被自己的任务身份校验判成 needs-reconciliation ... D11 里 Runtime 代 Supervisor 汇总子 Agent 澄清问题时，pending 动作的 task 字段 存的不是本 run 的任务，而是一段 Runtime 生成的转述指令（provider_recovery.rs 的「子 Agent 需要用户澄清后才能继续。delegationId=…」），delegationId 就编码在 前缀之后，另有四处按这个前缀反解绑定关系。 但 validate_agent_runtime_pending_context 会拿 pending.task 与 runtime .current_task 做相等比较，而落等待态的 persist_game_creator_agent_user_input_ wait 只改 status/phase/waiting_on，从不同步 current_task。其余五个 pending 创建 点传的都是 run 的真实 task，相等断言对它们成立；转述这一处永不可能成立。 后果是必现而非抖动：用户答完问题、观察已落盘（status=observed-approved）后， resume 立刻被判 needs-reconciliation，整条立项策划链在第一次澄清就断。 实测证据（run 14）： runtime.currentTask = 做个横版像素解谜小游戏，主角是个能操控自己影子的小机器人。（29 字符） pending.task = 子 Agent 需要用户澄清后才能继续。delegationId=delegation-ec059abd…（355 字符） 任务日志 27 条全部是前者；plan 根没有 autonomous completion contract， autonomous_effective_root_task_at 两侧都走 fallback，比较退化成裸文本相等。 这条路径此前从未执行过——澄清信封在 run 11/12/13 一次都没触发，缺陷因此一直 藏在 0 轮问询后面。 只豁免文本相等这一条。agent/task_id/session/run/source 五项身份检查在它之前已 全部通过，轮次检查在它之后继续执行，转述 pending 本身也只能由 Runtime 在本 run 内生成，所以不放开任何跨 run 或跨身份的重放面。没有选择改 pending 的持久格式： task 字段被当载荷用是既成事实，四处反解加在途 pending 迁移，风险与收益不成比例。 顺带把散落五处的同一段 strip_prefix 链收成 user_input.rs 的一个共用判据。抄本 之间一旦漂移，转述路径会静默失去与原 delivery 的绑定，那是比本次更难查的故障。 回归测试双向变异验证：恢复严格比较则转述被拒（红），整条删掉则被改写 task 的 pending 不再被拒（红）。受影响测试组单线程 124 passed / 0 failed。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 05:19:34 +00:00
lhk229	7a01f944dd	立项策划根 run 改用专用 Supervisor prompt，不再是通用合同的差集 ... 原型系统几分钟就能跑完同一条链路且全程有澄清问答，生产链路 run 11/12/13 三次 澄清轮数都是 0。拓扑不是差异来源——两边都是 D11。差的是 Supervisor 读到的 东西：原型给它一份 1.4k 的专用提示词，明写「你不生产策划内容」和固定动作序列； 生产给它的是 13.5k 的通用总控合同，预设手里有 43 个工具、六个专业组、isolated child、正式任务图和视觉产物合同，而 plan 根一个都没有。 此前的做法是在通用合同上逐段做减法（$visualContract、supervisorIntro、 isolatedTemplateCatalogIntro、$isolatedAgentTemplates 四个 `if plan_root` 分支）。这个形状本身在漏：模板目录那一段就是漏到第三轮才发现的，而每漏一段 都是一次已实测的偏航。现在整份换成 manifest 里的 supervisorPlan composition， plan 根的段落清单一眼可读，不再散落在两个函数的四个否定分支里。 保留的三段各有硬理由： - isolatedAgentContract —— expectedArtifacts 合同，agent.delegate 同样要用。 - supervisorRepair —— 返工必须用原 delegationId 重读 claimedDelegateContract 并逐字继承 acceptanceCriteria/expectedArtifacts。run 12 连撞两次的就是这条。 - planCommon —— common.md 的子集副本，见下。 替换的两段： - planSupervisorIdentity 取代 supervisorIdentityContract。后者的「用验收标准和 预期产物把边界清晰的任务委派给合适的专业 Agent」正是替用户预先裁定的压力源， 且 plan 根只有一个可委派目标；末句的黑板与 Agent 记忆在收窄后的工具面上是 死文本。 - planSupervisorPlaybook 取代 supervisorPlaybook。后者首段讲 spawn_isolated 批次与 manifest DAG、末段要求「manifest 正式任务图已完成」，在本链路都不可 执行。新段落照原型形状写死六步动作顺序，并补上生产此前完全没有的转述保真 规则：`[已确认] {header} → 用户答：{原文}` 逐条列出，任务接近长度上限时压缩 自己的说明而不是压缩用户答案。 删掉的三段： - common.md 有 43% 是 plan 根执行不了的内容（改码流程、git 提交、联网检索、 整段「作为被委派的专业 Agent 时」的身份错位），其中「最后一次修改后必须成功 执行 project.verify 才能 respond_to_user」还是一道 plan 根永远满足不了的假 门禁。但同一段压着这条链路唯一的原创性红线、user.input_request 协议和静态 委派协议——D11 的协议正文在这里，不在 playbook。所以 planCommon 逐字复制这 三段，并用 tripwire 断言反向钉住：planCommon 的每段都必须能在 common.md 里 逐字找到。 - supervisorClaimGate 讲 minIsolatedGroupsBeforeClaim，无 isolated group 时恒 不触发。 - $platform 整段是 command.start/exec/poll/stdin/terminate 的用法合同，plan 根 一个 command 工具都没有。GDD 里的平台事实由 Runtime 另行注入，与这段无关。 提示词头部改用上一笔提交的 allowlist 拼工具清单，与 Provider 请求实际广告的 函数目录共用同一份事实。两边各自维护一份就会退回「合同说有 43 个、请求里只有 9 个」的自相矛盾，而那正是收窄工具面本身要消灭的东西；这一致性单独钉了一条 断言。 supervisor/playbook.md 里的反预先裁定段落保留。执行层只单向拦住 plan 根， agent.delegate 的 agentId 是自由字符串，gui/cli Supervisor 委派 project-planning 并未被禁，那段在通用 lane 不是死文本。两份逐字相同，另有一条 tripwire 钉住。 plan 根实际拼到的提示词从 13531 字节降到 9049 字节，但重点不是体积——是被删的 全部执行不了、补上的固定动作序列此前完全缺失。 已变异验证四条新断言。全量 2238 passed / 10 failed，逐条单线程复跑后 7 条转绿 （并行噪声），剩余 3 条是本机缺 rg 与 CRLF，与本次改动无关。 尚未验证的是这些文字是否真的改变模型行为——单测只能证明它进了提示词。判据是 下一次 E2E 能否触发 AGC_NEEDS_USER_INPUT_V1 信封。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 04:50:37 +00:00
lhk229	2e6c0e7ac2	立项策划根 run 的工具面收窄成 7 个原生工具的 exact allowlist ... plan 根 Supervisor 此前拿到的是未按身份收窄的全量注册表：43 个原生工具外加 项目 MCP 目录。其中约 36 个在这条链路上根本执行不了——写入、补丁、删除、 命令、预览、画布、任务图、记忆、黑板、agent.spawn_isolated、 agent.route_manifest、agent.schedule_ready 都会被执行层拒绝。 广告一个执行不了的工具不是中性的。M1A-4 已经实测到同类后果：上下文里残留的 专业角色目录让 Supervisor 照着发起 agent.delegate，被拒后再没能自行改回 project-planning，整个 run 空转到预算耗尽。工具面同理——本链路的策划内容全部 由 project-planning 子 Agent 生产，Supervisor 手里多一个写文件或跑命令的入口， 就多一条它自己下场干活的诱导路径。 allowlist 定为 user.input_request、file.read、agent.delegate、 agent.goal_contract、agent.acceptance_update、agent.action_history、 agent.run_status，加上两个协议控制函数。后三个原生工具只为 §13.0 的审批前置 取证门存在（分页读 game/fast_gdd.md 并列出全部分页 actionId）；file.list 一并 砍掉，取证路径是固定的，不需要列目录。 实现沿用 restrict_plan_root_goal_contract_schema 已有的后置收窄形状，而不是给 build_agent_runtime_native_function_tools_for_agent 加参数：两处调用点本来就在 `if plan_root` 里，改动面更小，也不会波及其它 lane 的目录构建。 收窄写成交集而非断言。协议修复路径会先整份重建目录再按场景收窄，其中 restrict_agent_runtime_supervisor_collaboration_repair_tools 硬要求目录里存在 agent.spawn_isolated；plan 根这一遍必须排在所有分支收窄之后取交集，早于分支 会让那条检查失败，晚于分支才能保证任何修复轮都不把被裁掉的 36 个工具重新广告 回去。 回归断言写成精确集合而不是「不包含某几个」，将来往注册表加工具不会静默漏进 plan 根；同时断言 MCP 前缀工具不残留、收窄确实裁掉了东西（否则测试是空跑）。 已变异验证。 本次只改广告目录。提示词头部仍按全量注册表拼工具清单，二者的一致性由紧随其后 的 prompt 提交收口——单独看这一笔存在「合同说有、请求里没有」的过渡态。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 04:49:48 +00:00
lhk229	4f2136c919	立项策划 brief 补回被工具面收窄连带切掉的原创性红线 ... common.md 的原创性条款（2026-07-27 `427a8c151` 为做游戏链路引入， 2026-08-03 `e2b5056af` 抽进 common.md，两者都早于本分支）随 $base 分发给 每个专业 Agent。策划子 Agent 在 M1A-2 改成 exact allowlist 后走专用小 prompt、不拼 $base，该条款随之丢失。 不拼 $base 是对的——common.md 大量内容讲写文件、跑命令、起预览、再委派， 策划子 Agent 一个都没有，塞进去会让广告工具面与文字合同打架（理由已记在 game_creator_project_planning_tool_plan_system_prompt 的注释里）。但原创性 不属于工具面，是内容约束，跟着一起被切是连带损伤。 后果是缺口而非退化：GDD 是整条产线的上游，策划稿里落进受保护名称，下游做 游戏的 Agent 即便个个守规也已经晚了。实测中原创性由用户需求原文自带，产品 侧没有任何一层兜底。 补进 roles/project-planning.md，措辞按本 Agent 实际产出收敛（GDD 正文、决定 台账、原型验证项、targetUsers.referenceGames），不涉及它无权写的代码与图片。 回归断言的是「策划子 Agent 实际收到的完整 prompt」而非某一层，将来若把 common.md 拆成工具面与内容红线两段再正常合成同样成立；并以 common.md 原文 作对照基线，那边被改写时一并报警。已变异验证。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 03:10:34 +00:00
lhk229	db740d8ae6	台账逐项比对失败改判为可回灌的输入错误 ... plan.submit_gdd 的 session_decisions_match_input 校验此前与三条真 CAS 判据 （sessionRevision 溢出、session 已被其它动作推进、Runtime source revision/fingerprint 无效）共用 PLAN_SESSION_CAS_CONFLICT，因此被 plan_submit_error_is_business_rejection 漏掉，一次不匹配就 needs-reconciliation 硬阻断整个策划子 Agent。 两者性质不同：真 CAS 说明 durable 权威已变或已坏，重交同一份 input 不可能成功； 台账不匹配时权威完好，错的是本次 Provider input——子 Agent 把决策摘要抄漏、抄错， 或多追加了一条非 default_pending 决定。按第 12 节自己的判据，后者属于「本次 Provider input」，该走 rejected observation 回灌并受既有 5 次预算约束。 拆出 PLAN_SESSION_DECISIONS_MISMATCH 并纳入 business rejection，真 CAS 三支 原样保留 reconciliation。不变量未放松：不匹配照样拒、照样不产生任何事实， 伪造用户确认仍然不可行，只是拒绝的后果从叫人变成让它改稿。 实测触发：子 Agent 连撞三次形状层（PLAN_INVALID_REQUEST），每次都按回灌理由 改对一部分，机制运转正常；第四次形状合法后随即撞上台账比对，直接阻断， 整条链路零产物。即越接近提交成功越容易撞上不给重试的门。 覆盖：改写既有决定正文 → 新码；同一份 input 只改陈旧 revision → 仍是 CAS； 追加伪造 confirmed 决定 → 新码且不落任何事实；分类器两向断言。分类器一条 已变异验证。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 02:45:37 +00:00
lhk229	d284639903	立项策划根 run 的上下文层不再列出专业角色目录 ... 共享 runtime 合同里的「agent.spawn_isolated 合法 templateAgentId」静态模板目录 会把 design-director 等全部专业角色名拼进 plan 根 Supervisor 的 system prompt。 plan 根的 agent.spawn_isolated 已被 M1A-4 无条件拒绝，这份目录因此没有任何可执行 语义，此前按「死文本」处理。 实测证伪了这个判断：目录第一个名字就是 design-director，Supervisor 首轮据此发起 agent.delegate，被执行层以 plan-root-child-target-unsupported 拒绝后未能自行改回 project-planning，整个 run 空转到 loop 预算耗尽、零产物。漏掉的推理是目录虽为 spawn 而设，模型会把里面的名字挪去当 delegate 目标。 改为在上下文层删掉目录本身，即第 19 节第 2 条要求的第二层，不替代执行层硬拒。 只删 spawn_isolated 专属的两段；isolatedAgentContract 讲的是 expectedArtifacts 与 writeScopes，agent.delegate 同样要用，逐字保留。 覆盖：plan 根 prompt 遍历 GAME_CREATOR_AGENT_GROUP_DEFINITIONS 断言不含任何角色 task_id（新增角色自动进覆盖范围）；非 plan source 与其余 agent 逐字等于未收窄的 合成结果且目录完整。前者已变异验证。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 17:33:43 +00:00
lhk229	938b7ce654	手动提交：修复CI失败	2026-08-20 13:40:30 +00:00
lhk229	c1dba09049	让 static-smoke 夹具满足收紧后的入口合同 ... 9a7a79951 给 finish_agent_runtime_project_verification_locked 加了一道复核：记录 game.static_smoke 通过时，按当前磁盘内容重跑 validate_game_html_smoke。五个夹具 仍停在收紧前的形状——它们各自只为视觉门、模块可达性或 owner 产物判据构造入口页， 没有目标说明、主循环或输入监听，于是伪造的 smoke 通过一律被拒，用例从未绿过。 生产代码不动：draft_validation.rs 与 master 逐字一致，project_gates.rs 里那段复核 逻辑也和 master 相同。只把夹具补到合同要求的形状： - 数值常量作用域、内联/外部模块图集三处改用仓库已有的 with_static_smoke_contract 包一层，被探测的常量引用与模块结构原样保留； - 终态投影用例的入口页原本只有一个空实现回调，空回调本身触发另一条判据，去掉后 同样包上合同层，写入次数不变、revision 断言不受影响； - owner 产物用例是真实新项目，入口是无画布占位页。它在断言过「占位页过不了真实 smoke」之后才需要一份过期 smoke 凭证，故在 owner 产物之前先落一份合规入口， verified_revision 仍取最后一次 owner 产物； - 自主 manifest 用例只写了 package.json，直接用普通文件写入落一份合规入口，不触碰 revision 记账。 顺带修一处仿造 gate：清 static_smoke_verified_revision 时必须同时清入口摘要， 两者是一对，否则 gate 自身的一致性校验会先于被测行为拒收。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 13:00:09 +00:00
lhk229	e54ebb8227	补齐 master 带入代码的 rustfmt 输出 ... 合并 master 后 cargo fmt --check 在 ui_editor/layout/node.rs 报差异（枚举变体的 行尾注释未对齐）。只是 rustfmt 的既定输出，无语义变化。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 12:29:26 +00:00
lhk229	0bd41112b4	瞬态重试恢复不再被策划用量折叠边界判成自杀 ... 策划子 Run 第一次 tool-plan 请求撞上 HTTP 524，通用重试机制留下 retry sidecar 并 唤醒同一个 run；该 run 重新走到新请求边界时，fold_plan_provider_usage_before_new_request 把「本 run 自己那条未收口的 exchange」判成 PLAN_PROVIDER_USAGE_DEFERRED 硬失败。 于是子 Run 直接 failed，回执退化为 needs-repair，逼总控走完整的查状态→认领→返工 委派流程，一轮实测白烧四轮 Provider 请求。等于策划子 Run 撞上任何一次 502/524 都必定自杀。 延期判据本身没错——它的第一条就是「该 run 存在 retry sidecar」，而这恰恰是重试 恢复的必经状态。折叠是记账动作：exchange 没收口时本来就不该计入 session，跳过一 次是正确的，收口后的下一个边界会补上；真正裁决重放还是重发的是下游 retry / handoff 身份比对，它本来就预期 sidecar 还在。 边界函数改为接收本次请求所属的 run，只豁免「延期完全由该 run 自己造成」这一种。 三个 runtime_actions 边界传当前身份；planning_coordinator 三处在派生后继 session， 子 Run 的在途 exchange 对它们仍是硬阻塞，传 None，行为不变。内部折叠额外返回延期 来源，公开枚举与既有调用方签名不动。 用例覆盖四个方向：本 run 放行、别的 run 仍硬失败、None 调用方行为不变，以及收口 后用量仍如数折叠进 session（豁免是延后记账，不是丢账）。已实测关掉豁免后该用例 复现线上原话。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 12:29:11 +00:00
lhk229	19f4b6276c	合并 master（0797410ee） ... 三处冲突： - decision-log.md / pitfalls.md：双方各自追加条目，两边都保留；决策记录是新在 前的日志，master 的 2026-08-20 条目排在本分支 2026-08-19 之前。 - panels.tsx：canRetrySupervisor 两侧逻辑逐字相同，只差续行缩进。实测本分支版本 过 prettier、master 版本不过，故取本分支缩进；顺带把 master 一并带进来的相邻 needsSupervisorReconciliation 块补成 prettier 输出。解析结果与合并前该文件逐字 一致，没有语义改动。 已逐项核对本分支 11 个提交的关键标记在合并后仍在树上。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 11:48:29 +00:00
lhk229	802f06d59d	全局异步 runtime 的 worker 用上 Runtime 自己的栈预算 ... Agent Runner 在父 run 认领委派回执那一刻整进程消失，调用方只看到 connect 超时， runner 日志里两行 stderr 又被日志泵按「非诊断输出」抹掉。放开原始 stderr 后拿到 真相：thread 'tokio-rt-worker' has overflowed its stack。 Runtime 的 agent turn 调用链本来就深，task_queue 早就给自己起的后台线程配了 AGENT_RUNTIME_BACKGROUND_WORKER_STACK_BYTES；但静态委派的父 run 唤醒走的是 tauri::async_runtime::spawn，落在 Tauri 全局 runtime 的 worker 上——那个 runtime 由 TokioRuntime::new() 建出，worker 吃 tokio 默认栈（tokio 1.52 起该线程名就叫 tokio-rt-worker）。同一段代码在自家 16 MiB 线程上天天跑完整轮次，换到默认栈就爆， 所以不是无限递归，是那条链从来没被这个线程池的尺寸覆盖过。 进程入口在任何异步派发之前用同一个常量建 runtime 并 async_runtime::set 装上； handle 要求底层 Runtime 常驻，故刻意泄漏。这样十余处 async_runtime::spawn 一次 性都拿到同一份栈预算，而不是逐个改调用点。 回归用例在自建 runtime 上 spawn 一条 3 MiB 深的调用链。注意它的失败形态是整个 测试进程被 abort 而不是断言失败——已实测拿掉 thread_stack_size 后复现的正是线上 那行 tokio-rt-worker has overflowed its stack。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 11:41:20 +00:00
lhk229	5c2d722b12	立项策划 role brief 按解析器真实线格描述澄清信封 ... brief 只写「下一行给出严格 JSON 的单题问题」，模型据此输出裸的单题对象，还自创 了一个 answerFormat 字段： {"header":...,"prompt":...,"options":[...],"answerFormat":"回复 A、B..."} 解析器要的是 {"questions":[{id,header,question,options}]} 且 deny_unknown_fields， 于是父 run 收到 unknown field `answerFormat`, expected `questions`。此时子 Run 已经终止，信封没有修复通道，整条委派直接停在 needs-reconciliation。模型其余部分 （第N轮·关键决定、A/B/需要原型验证 三项合同）都严格照 brief 执行，说明它跟的就是 brief——两份 prompt 描述了两种形状时，模型跟更具体的那份。 brief 改为逐字给出外壳、四个允许字段、id 的 snake_case 规则和各字段字符上限，并 点名 answerFormat 这个真实踩过的坑。上限数字全部来自 schema 常量，新增用例用 format! 把两边钉在一起，任一边先改都会红；为此把相关常量放宽到 pub(crate)。 这一条只改立项策划自己的 role brief，其它 Agent 的 overlay 不受影响。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 11:08:44 +00:00
k88936	0797410eef	Feat/UI自动识别和布局编辑器简化版 (#170) ... * 支持从项目, 本地电脑, 主站导入/引用素材. * 页面复杂, 需要足够空间, 作为资源打开时会占满右侧 * 编辑结果作为一种新的美术资源. * 新增素材按钮现在是空的实现, 临时在旁边加了一个新增UI设计的按钮 临时入口:  简化: * 组件实现了最基本的图片和文本 * 容器式布局未接入llm编辑 * 不同阶段统一维护一个状态State, 任何阶段都可以人工调整, 不设单独的步骤 * 多图的UI合并功能暂时不要求, 隐藏入口 * 因为生成工具尚未从主站迁移, 主站地图子画布未实现, 以tab栏的形式容纳素材的子画布需求搁置 * 未实现llm绑定字体功能 * 识别会替换现有UI树, 暂时不是增量的 Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/170 Co-authored-by: 王德宇 <kvtodev@outlook.com> Co-committed-by: 王德宇 <kvtodev@outlook.com>	2026-08-20 19:07:25 +08:00
lhk229	3bae4cdbb0	澄清信封在整条回执通道上不再按自由文本盲切 ... 上一轮只堵了通道末端，父 run 仍然停在 needs-reconciliation：子 Agent 输出 518 字符的合法问询，在源头 last_response 处就被切成 501 字符，剥掉信封首行后 正好 1120 字节，父 run 解析时在字符串中途 EOF。 信封是结构化协议载荷，只是恰好借用了「子 Agent 自由回复」这条文本通道。定界 本身要保的三件事——状态快照与只增审计日志不被自由文本撑爆、子 Agent 文本不无 限量灌进父 Agent 上下文、摘要行只占一行——对信封都已由问询 schema 逐字段硬性 校验保住，再叠一层盲切只会砍断 JSON。 改为共有一条上限规则 static_delegate_result_detail_max_chars：字面以信封首行 开头时取 schema 推导的上限，否则原样走各自的 500/600/240。通道上四处定界全部 接上——last_response、terminal_detail、回执发布、复用既有终态时的摘要，其中 后者把「给人看的摘要」和「给解析的明细」拆成两个值，不再让一行摘要的长度决定 结构化载荷能不能被解析。last_response 与 terminal_detail 必须同源，两者逐字 相等是 finalization 幂等校验的不变式。 非信封文本走的分支与改动前完全一致，做游戏链路（含 codex）不产出该信封，行为 不变。 回归用例覆盖源头与通道两端，并钉住「普通自由回复仍被截到 500 字符」。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 09:55:56 +00:00
lhk229	276606fc70	修正无头应答器收 stdin 的时机 ... CLI 的 REPL 是「先打印提示符再读行」，所以第一个「你>」出现时本轮还没开始跑：它 就是用来读我们这条任务的。在那里收 stdin，等确认卡弹出来已经是 EOF，自动应答器 根本没机会回 approve，一轮真实跑就这样收在 pending-confirmation。改成按提示符计 数，投递之后的下一个提示符才收口。 同时补上原本缺的那条：总控可能判定直接回复而不起持久 Run，那条路径没有 turn 回 执，只等回执会一直干等到超时——实测白等了十分钟。提示符收口对两种情况都成立。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 08:49:40 +00:00
lhk229	e45c6760b6	做方案无头入口不再把起 Run 的判定交给模型 ... GUI 的「做方案」是一个按钮：直接起 plan 根 Run，没有「直接回复还是调用持久能力」 这一步。而 swarm CLI 有个交互内核会让模型自己判定 reply / execute，无头入口原样 复用了它，于是同一句需求有时起 Run、有时只回一段口头建议——交付物落不了盘，还得 靠用户在措辞里补一句"产出 Fast GDD"把模型推向 execute。判定权不该交给措辞。 plan source 直接短路交互内核，与 GUI 按钮同构。做游戏与做素材继续走交互内核，用 例对这两种 source 断言的是"与原函数返回值相等"，等于把"不许顺手改这两条链路"也 锁进测试。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 08:49:37 +00:00
lhk229	7df033fcde	修复澄清回执通道容不下一次正常问询 ... 子 Agent 的澄清信封走的是 error 文本通道，两处把它当普通错误消息处理： 一是中转通道的字符上限写死 500，而它承载的问询 schema 允许 3 个问题、每题 400 字符、每题 2-3 个选项（label 60 + description 240）——单个 schema 合法的问题光内 容就有 1376 字符，通道连一个满格的合法问题都装不下。现场一问三选的正常中文问询 501 字符，正好被拒收。改成由 schema 自己的上限推导，推导常量放在 schema 所在的 user_input.rs；顺带把内联的 options.len() < 2 || > 3 换成具名常量，让推导有据。 二是父 run 认领回执时按错误消息截到 500 字符再补省略号。现场子 Agent 的真实输出 521 字符，截断后 501 字符，JSON 拦腰断在末尾，父 run 解析失败停在 needs-reconciliation。只放宽上限治不了这一处：载荷在到达解析器之前就已经被切了。 识别信封前缀时按信封通道上限放行，其余错误消息仍是 500。 两处都得对，少一处这条链路就断。上限是沿用 master 的（82957fe1d，2026-08-12）， 本分支没改过；做游戏链路的专业 Agent 很少提带选项的澄清，所以此前没暴露，而 M1 策划把"先问清楚再出 GDD"做成了必经步骤。 放宽上限不会让原本通过的载荷失败，逐字段复核仍在 parse_game_creator_agent_user_input_questions。新增三条用例：schema 允许的最大合法 问询必须能过通道、现场那条普通中文问询必须能过、同一条信封被截断后必然解析失败。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 08:49:12 +00:00
lhk229	7ca7e9704b	修复立项策划子 Run 持锁自锁导致的静默停摆 ... Provider 请求启动路径持有项目写锁时会追加 lifecycle "started"，其中策划专属分支 要重新校验冻结的 planning session；而那道校验走的是不持锁版本，会自己再去抢同一 把项目写锁。持锁上下文里必然抢不到，错误又被包成 RECONCILIATION 前缀，主循环见 到该前缀直接静默返回：不写失败态、不发事件、不置 error。结果是策划子 Run 永远停 在 running/planning，父 Run 等一个永远不会来的委派回执。 打点实测整段 prelude 只花 300 毫秒，卡点就在这一行，锁本身 1 毫秒就能拿到——不是 锁竞争，是同一路径自锁。只有做方案会中招：只有 planning 请求带 session binding， 做游戏与做素材进不了这条分支。codex 与 provider 两种模式表现一致，因为这段在模式 分发之前。 按仓内既有 `_at_locked` 惯例补上持锁变体，校验体抽成私有函数供两者共用；生产里唯 一持锁调用点改用新变体。既有用例都在 append 之前就 drop 了锁，持锁形态从来没有被 覆盖过，而且断言的是 error.contains("reconciliation")——真踩了自锁也会因错误恰好 带这个前缀而"通过"。新增用例先断言不持锁版本在持锁上下文里必然失败且带该前缀，把 bug 的形状写进测试，再断言持锁版本成功并真的落了 lifecycle 记录。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 08:48:41 +00:00
kdletters	4bf6c50a56	修复AGC开发者凭据目录权限初始化 ... 允许客户端自动收紧当前用户持有目录的继承 ACL 保留 foreign owner 与异常路径的失败关闭边界 补充 Windows 回归测试并同步实施决策文档	2026-08-20 14:11:59 +08:00
lhk229	af1fc63de2	无头立项策划默认按五分钟设计目标收口 ... --plan 之前吃 --task 那条 50 分钟的默认上限，那是做游戏链路的量级。立项策划 的设计目标是五分钟出方案，给一分钟余量；再久就是卡住，早失败比让 harness 空 等更有用。显式 --timeout-minutes 仍然压过默认值，做游戏链路不变。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 05:38:14 +00:00
lhk229	998b9e6c57	掐断结构化计划空转活锁 ... apply_agent_runtime_plan_update 把计划解释算进「有变化」判据里，模型每轮重写 一遍解释就返回「计划有进展」，Runtime 还发一个新 planRevision 替它背书。观察 detail 里那句「只有步骤或状态真实变化时才调用 update_agent_plan」是 prompt， 不是门禁，于是总控可以只改解释、不落地任何动作地无限循环，每轮烧一次 Provider 请求。现场实测四分钟走了八轮，planRevision 到 4 而步骤状态一格没动。 判据拆成三态：解释照旧落盘，但只改解释既不算进展也不再 bump planRevision， 事件改发 plan_update.explanation_only。计数落在持久 Runtime state 上（照 plan_submit_gdd_rejection_count 的先例），进程重启不能把一次活锁洗成新的无限 开销；只在「本轮没有任何动作、且未完成原因就是计划自己」这一支累加——等委派 回执、等 provider 批次、等用户问询走的是别的 blocker 类型，不会被误判成空转。 连续 2 轮把 update_agent_plan 从工具目录里摘掉逼模型自愈，只摘这一个工具，其 余工具面原样保留；连续 4 轮以 plan-update-idle-rounds-exhausted 收束。摘工具 的阈值严格小于收束限额，由单测守住，否则 run 会在从没被逼过一次真动作的情况 下直接失败。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 05:36:01 +00:00
lhk229	5100c18fba	新增立项策划链路的无头入口 ... `--swarm-chat` 加 `--plan`，把新根 Run 绑定到 project-supervisor-plan standard 档，和 GUI「做方案」按钮走同一条门禁；与 --autonomous-game-build / --game-chat-smoke 互斥，非总控父 Agent 拒绝。plan 与做游戏同为 standard 档， 只按 profile 匹配会串链，因此 plan 入口按 source 精确认领自己的 Run。plan 根 Run 不接受 steer，无头入口把 source 交给后端才能触发既有否决，其余入口维持 不带 source 的旧行为。 harness 侧 --plan 跳过游戏产物验收和试玩，改为报告策划产物落盘清单。立项策划 跑 standard 档，agent.delegate 这类动作按项目权限策略必须逐个确认，而确认只从 CLI stdin 读；自主构建档没有这一步，所以只给 --plan 加一个 stdin 应答器，确认 本身仍然走后端确认命令。做游戏链路不受影响。 真实无头跑已验证：plan 根 Run 正常起来，source=project-supervisor-plan、 runProfile=standard，两个 agent.delegate 确认卡自动批准并进入委派。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 04:39:54 +00:00
lhk229	400595756b	修复普通 action 批次带 plan update 时预检自相矛盾 ... 批次预检对每个成员要求 provider_batch_plan_update 等于 batch.plan.plan_update， 而同一函数的另一条规则又要求非 planning 批次成员不得携带该字段；创建侧只为 plan.submit_gdd 填值，其余动作保持 None。于是「同一轮既调 update_agent_plan 又调工具」的普通批次同时踩中两条互斥规则，报「批次成员身份或顺序不匹配」。 该字段随 M1B-2 引入，master 无此标识符，做游戏路径同样中招。 预检期望值改为按批次类型分叉：planning v4 保持相等（:241 已对 actions[0] 校验过一次），非 planning 期望 None。创建侧与非 planning 分支语义本自洽，不动。 补一条走完 prepare 到读回的回归用例；去掉修复后可复现线上同一条错误串。 顺带 cargo fmt 掉上次 master 合并带进来的一处未格式化代码，并补一份第三方 Provider 兼容性缺陷说明。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 03:47:14 +00:00
lhk229	c2d5273873	重做 master 合并，找回上次合并丢失的分支工作 ... 上次合并 3d8abac33 把 24 个双边改动文件里的 7 个整份取了 master，另有数个 实质取了 master 版本，静默回滚了分支工作；其中 main_loop.rs 保留 master 的 调用点、provider_recovery.rs 保留分支的 cfg(test) 门，导致非测试构建编译失败。 本次从 ca6a3cd4c 对最新 master(341761ee3) 重做，逐个人工解析 38 处冲突： - 澄清等待态：保留分支的 lane 外 parent-wake 设计与锁守卫，套上 master 新增的 parent task 身份校验与 game-chat 安全默认返工；`_locked` 两种 false 语义在 delivery.rs 按 trusted_game_chat_autonomous_parent_chain_at 区分。 - decision-log：按日期把 master 三条插进分支条目之间，57 处 M1 记录全部保留。 - manifest.rs：采用 master 的 windows_sys 绑定，保留分支的目录/reparse point 拒绝。 - 做方案入口按 master 的提交重构改造：resolveProjectSupervisorRuntimeSubmission 新增 planningEntry，startMode 经 launcher context 传到 App；并把策划入口从 direct-codex 产品默认中摘出，做游戏与做素材保持 master 新默认。 - 首页两条入口用例按 master 已改的创建流程更新；非空目录确认用例因该流程 在首页入口不再可达而移除。 验证：cargo check --all-targets 通过；agc typecheck 通过；appSurface 395 passed。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 13:15:16 +00:00
lhk229	ca6a3cd4cd	修复M1策划链路可靠性 ... 阻止人工核对中的策划根写入审批回执 在投影恢复前校验项目身份并使用唯一项目ID 增加策划能力停用门禁与既有sidecar只读行为 拒绝非法plan与自主构建档位组合并收紧消费者 补齐前后端回归测试与M1技术决策记录	2026-08-19 09:13:43 +00:00
kdletters	925aefd934	修复AGC Native测试夹具 ... 固定普通 JSON Provider mock 为非流式 为平台账号画布与视觉门禁测试安装隔离会话 同步现役路由、默认配置与提示词断言	2026-08-19 14:42:41 +08:00
lhk229	e0dc87b21c	修复M0A-2给做游戏路径引入的两处收束死路 ... design-foundation 在非 scheduler 路径上恢复 command.run_limited。内部产物验证只在 agent-ready-task-scheduler + Supervisor parent + gui/cli 根的可信 DAG 上发放，而 policy.rs 按 agent_id 单判就拒掉手动验证，委派路径两头落空、无从收束；master 的 白名单含该工具且自身用例断言不拦。判据只对 design-foundation 读绑定，其余三个固定 owner 的委派路径未经核实，维持现状不一并放宽。 game-chat 美术回执去掉本人 canvas.asset_generate 证据等三条必要条件。提示词要求 已有有效同路径资产时不得重复生成，而缺口判据只看非返工那一轮，合法的幂等复用会被 判成尚未交付。 测试恢复 master 断言并删去分支追加的钉桩段，未新增用例。policy 143、 design_foundation 6 全通过，cargo fmt --check 干净。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 06:31:21 +00:00
lhk229	6d5afd9f6d	修正M1首页立项入口 ... 仅让首页做方案进入立项策划 恢复做游戏和做素材的直接构建路径 同步入口合同与回归测试	2026-08-19 05:27:53 +00:00
kdletters	9fe800da80	修复AGC Native测试认证与阻断 ... - 为画布与资源编辑 loopback fixture 增加 task-local External Editor 凭据 - 为平台账号语义测试安装隔离会话并修正资源编辑错误分类断言 - 为 Windows mock listener 增加有界 accept 与 blocking stream 恢复 - 同步 autonomous main-loop、completion fixture 与项目决策记录	2026-08-19 03:24:29 +08:00
lhk229	7eee259cea	Merge branch 'feat/five_min_design' into codex/genarrative-isolated	2026-08-18 14:22:00 +00:00
lhk229	e3d318bf45	完成M1E提交拒绝有界收束 ... 为 Fast GDD 提交拒绝新增持久化次数上限与恢复收束。 将既有权威事实的超限和版本边界转入 reconciliation。 同步 M1E 技术方案与项目决策记录。	2026-08-18 14:20:23 +00:00
kdletters	b8dc3fe1b1	修复AGC登录网络错误与构建门禁 ... - 登录页归一网络错误并避免暴露底层 transport 文本 - 补充拒绝连接提示与错误信息脱敏回归测试 - master 推送门禁增加 AGC AppSurface 验证	2026-08-18 22:15:49 +08:00
kdletters	fe69a49a9c	修正AGC主分支门禁 ... - 修正直连 Codex 烟测脚本导入排序 - 修正播放请求回调依赖并稳定调用最新动作	2026-08-18 21:18:39 +08:00
kdletters	f9ee0d5ac7	恢复直连已有游戏意图分流 ... - 已有游戏默认进入同一 Codex thread 编辑与试玩链路 - 仅明确新建或重做美术请求触发平台素材准备 - 补充已有游戏编辑与外部美术生成意图分流测试	2026-08-18 20:53:13 +08:00
lhk229	4687807dc1	在hydrate调用点写明投影修复先于身份校验的前提 ... 裁决为不修，并把改动前提与非重入锁陷阱留在代码旁 第 18.3 节要求身份校验（第 3 步）先于 session 前滚（第 5 步）与 index/pending 重建（第 6 步），而 hydrate 的实际顺序相反。本次裁决为不修，理由与前提写进注释： 现在没有后果，是因为那道比对恒过——App 的全部 init/import 调用点都传同一个常量 seedManifest.projectId（local-project-draft），本机每个项目的 manifest 写的都是它， projectId 分辨不出任意两个项目。该常量不属本工作包管辖。 触发后的后果也已复核为可忽略：命令仍正确返回 PLAN_PROJECT_ID_MISMATCH，前端拿不 到错数据；报错前写入的 pending/session/index 均为幂等或可重建投影，usage fold 有 按 fact 比对的幂等守卫，session.previous.json 是改名而非删除且只在 primary 缺失时 发生（即本来就该做的恢复）。 一旦 projectId 改成每项目唯一，这道校验才真正开始工作，届时顺序必须一起改，否则 hydrate 会先对一棵属于别的项目的 planning 树做完投影修复才发现认错人。注释里连同 陷阱一并写明：不能把 reconcile 直接挪到 hydrate 取锁之后——它自取项目锁，而 .agent/project.lock 是 create_new(true) 非重入的，调用方持锁再进去会死等满重试预算 然后失败；可行路径是锁外 projectId 预检，或把 reconcile 拆成薄壳 + _at_locked 由 hydrate 在自己的锁内调用（同型拆法见 observe_agent_runtime_agent_delegate）。 把提醒放在代码旁而不是只留在 decision-log，是因为真正会改 projectId 方案的人不在 本领域，不会来读这份文档。 cargo fmt --check、check:encoding 通过；纯注释与文档，无行为改动。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 12:45:46 +00:00
lhk229	d44f930d1f	收口design组展示名，改为设计实现Agent ... 分组字典、manifest默认名与分组头像字一并改掉 个体Agent名兜底跟进，玩法策划Agent与内部id不动 跟改16处由label派生的断言 第 18.2 节要求 design 组用户名称改为「设计实现组」，与新阶段「立项策划」区分。 bf2185fba 只改了 taskGroupLabels 一本字典，另两本同概念字典没动，于是同一个 design 组在开发者面板/文本汇总里叫「设计实现组」、在工作台状态栏里叫 「策划 Agent」——这个语义不一致是该提交引进来的。 先更正一条此前的判断：曾把这条的严重度建立在「新项目默认主路径上『立项策划』 与『策划 Agent』同屏共存」上。该说法未经验证且不成立——用 appSurface harness 实测策划路径，子 Agent 状态栏根本不渲染，策划 Agent 出现 0 次。结构上二者确在 launcherView === 'project-development' 分支的同一棵树里，但未能把用例驱动到该 分支，故不作为事实主张。若真会撞，也是批准后进入完整制作那一段，比原描述窄 得多。改这条的理由与撞不撞名无关，只是第 18.2 节的要求 + 上述不一致。 口径取最小方案：保持兄弟项的「X Agent」体系，design 取「设计实现 Agent」。 不把 taskGroupLabels 直接塞进 groupConfigs——两本字典命名体系不同（「X组」对 「X Agent」，且音乐组/音频 Agent、运营组/发布 Agent 连词都不一样），直接替换 会连带改掉另外五个分组名；消灭重复字典属视觉改版，单独立项。 改动：agentPresentation.ts 的 groupConfigs、view/project-development/index.tsx 的 summarizeAgent 默认名与同文件分组头像字（策→设）、model.ts 中 agentId.includes('design') 的个体名兜底（design-director 走这里）。 design-foundation 的「玩法策划 Agent」单列在前，不变；内部 agent id 与 design 分组键均未动。 测试量原估「3 处断言」严重低估，实跑发现 project-development.suite.ts 有 16 处 派生断言需跟改——「X 文本回执」由 App.tsx 的 `${candidate.label} 文本回执` 拼出、 「历史成果 · X」由 resourceProjectionModel.ts 拼出、dock 的 article accessible name 亦然。替换用后行否定守住「玩法策划 Agent」（它含「策划 Agent」子串）， 替换前后该串恒为 6 处。agentRuntimeModel.test.ts 与 projectResourceProjectionModel.test.ts 里剩余 4 处是测试自造的输入 fixture、 不由字典派生，保持不动。 验证：appSurface.test.ts 383 passed / 0 failed；agentRuntimeModel、 agentTraceSummary、projectResourceProjectionModel、projectResourceLiveUpdateModel 合计 39 passed；agc:typecheck、ESLint --max-warnings 0、check:encoding、 git diff --check 通过。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 12:20:01 +00:00
lhk229	7ca82ba7aa	修复M1D审查发现的锁错误脱敏与澄清轮次口径 ... 审批卡链路的三处项目锁错误改为脱敏后再进typed错误 阶段进度按等待状态显示真实轮次，不再透传0-indexed值 去掉reconcile错误的重复code拼接 补一条Rust脱敏回归与两条前端轮次回归 锁错误脱敏（方案 §18.3「返回值不包含绝对路径……或内部诊断」）： acquire_project_write_lock 的 Err 内嵌 .agent/project.lock 真实绝对路径。补 redact_agent_runtime_project_paths 的三处是前端审批卡真正会显示的那条链—— reconcile_plan_gdd_approval_projections_at（hydrate 在取自己的锁之前调它）、 hydrate 自己的锁、decide_plan_gdd_at（其错误与 hydrate 的错误渲染在同一个 错误区）。planning 另有 14 个取锁点沿用未脱敏写法，属 M1B/M1C 既有模式， 本次不扩面。脱敏不破坏「项目正在被其他写操作占用：」前缀，project_gates.rs 与 provider_recovery.rs 两处按前缀分类的判据不受影响。 澄清轮次口径：clarificationRound 与 awaitingAnswerFor.round 都由 static_delegate_lineage_counters 派生，该函数排除目标自身，是 0-indexed 的 「已答轮数」；后端判上限用的是 current_round + 1。原样渲染成「轮次 X/3」 整体差一格——问最后一轮时显示「轮次 2/3」，字面暗示还剩一轮。只改前端 文案、不动 DTO 语义：等待回答时显示「第 N+1 轮 / 共 3 轮」（此时 latestDelegationId 就是当前 delivery，+1 恰好等于后端校验用的轮次）， 其余状态退回「已完成 N/3 轮澄清」，不猜当前轮。 顺带：planning_hydrate.rs 里 reconcile 的错误原本用同一 code 把 to_string() 当 detail 重包一层，而 PlanningStorageError 的 Display 已是「{code}: {detail}」， 渲染出 CODE: CODE: detail；code 与 detail 均无变化，改为直接 ? 传播，并把 「不重复拼 code」钉进回归。 测试陷阱：写「占住项目锁」的 fixture 必须给锁 JSON 填真实 createdAt。失效锁 回收的年龄判定读的是该 JSON 字段而不是文件 mtime，填 0 会让锁显得约 1.7e9 秒 老、越过 600 秒阈值被当场回收删除，hydrate 反而成功。第一版 fixture 正是这样 自证失败的，注释已写明。 验证：Rust planning_ 组 155 passed / 0 failed（原 154 + 本次 1 条）； appSurface.test.ts 383 passed / 0 failed（378 原有 + 5 条新增）；三条新回归均经 变异验证，逆转对应修复即变红。cargo fmt --check、agc:typecheck、ESLint --max-warnings 0、check:encoding、git diff --check 通过。 撤回一条此前的审查发现：曾判定 hydrate 读 manifest 缺符号链接判定。复核后不 成立——read_manifest 自身在 is_symlink 处即拒，防护在另一层；.agent 目录本身 为符号链接的残差也无窗口，紧随其后的 resolve_planning_path 同样逐段判定。 未据此改动代码。 新记一条既有问题（非 M1D 引入）：seedManifest.projectId 是常量 local-project-draft，App 的 5 个 init/import 调用点全传它，因此本机所有项目 projectId 相同。§18.3 第 1 步依赖的 projectId 校验因此分辨不出任意两个项目， 该门当前近乎恒真，须单独立项。 仍未修：hydrate 身份校验排在落盘投影修复之后（修它须注意 reconcile 自取项目 锁、.agent/project.lock 不可重入，不能把检查直接挪到 hydrate 取锁之后）； design 组展示名剩两处硬编码，且与 taskGroupLabels 命名体系不同，需先定口径。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 11:50:43 +00:00
lhk229	abcc393fde	修复M1D审查发现的审批决定失败路径 ... 决定失败也重灌权威状态，顺序钉死为先hydrate后写错误 responseId复用键纳入comment，改写修改意见时换新ID 恢复期门控扩到已打开的评论弹层，保留已输入内容 补appSurface harness的策划command分发与三条变异验证过的回归 审查基线为 14c00017c..bf2185fba（技术方案第 13、18 节）。其后分支已前进到 c6a08ef98，4624fd795 与 c6a08ef98 都不动 src/**，审查结论不受影响。 三条缺陷： 1. decidePlanGdd 只在成功分支 hydrate。后端 decide_plan_gdd_at 有多条真实 PLAN_STALE_APPROVAL 分支（GDD 不在当前 lineage、identity 不符、版本被取代、 pending 丢失），命中后卡片停在已失效的 pending 身份上、三个决定按钮仍可点， 且 recoveryPending 永不翻真导致「重试恢复」入口不渲染，卡内没有恢复路径。 现按第 18.3 节在失败分支同样 hydrate——该句不区分成功与失败。两句顺序不能反： hydratePlanGddState 入口会 setPlanGddError(null)，先写错误再 hydrate 会把错误 擦掉；回归钉死了这个顺序。 2. responseId 复用键为 approvalRequestId:action，不含 comment，违反第 13.2 节 「改变 action/comment 必须生成新 responseId」。在第 14 节承认的「receipt 已提交 但 response 丢失」构造下，改写修改意见后重提会带旧 ID，命中后端「同 responseId 的审批意图不一致」硬拒，改写后的原因永远落不了盘。现按 approvalRequestId 存 {action, comment, responseId} 全量意图。判据方向为宁可多换不可少换：多换的最坏 后果是 replayed 降级成 already-decided（都是 Ok，且 already-decided 正是第 18.2 节要求的刷新态），少换是硬错误。 3. 第 18.2 节「recoveryPending 时不允许提交决定」原来只作用于三个触发按钮，而弹层 是打开之后才可能被后台 hydrate 翻掉资格的，其提交按钮只看 busy 与非空。现在 submitComment 与该按钮都判 canDecide。刻意不自动关弹层，否则会丢掉用户已经写好 的修改意见。 测试：harness 新增 hydrate_game_creator_plan_gdd_state 与 decide_game_creator_plan_gdd 分发分支及 createPlanGddStateView fixture；未配置策划 状态时 hydrate 与接入前一样抛出，既有 378 条行为不变。新增 plan-gdd.suite.ts 三条 回归并逐条变异验证——逆转对应修复后三条各自以自己的断言变红；修复二的变异是部分 逆转（保留新 Map 结构、只删 comment 比对），因此钉住的是 comment 这一维本身。 验证：appSurface.test.ts 381 passed / 0 failed；agentTraceSummary 与 rememberCommand （另两个 import src/App 的用例文件）13 passed；agc:typecheck 通过；6 个改动文件 ESLint --max-warnings 0 通过；check:encoding 5409 文件通过；git diff --check 干净。 不改 Rust——三条全在前端，后端语义已经正确。 文档：更正第 23.8 节 M1D-1 行误引的合入提交（5b11a0530 是 ESLint 修正，落地是 0052a80da），并补 M1D 审查修复快照。同时更正既有记录里「Shell typecheck / appSurface 受仓库依赖缺失阻断」的说法——在原分支主工作树上两道门都干净，实际是 bf2185fba 改名 taskGroupLabels.design 后自己把 8 个用例文件断言改红，由 c6a08ef98 补修。 未并入的四条审查发现：hydrate 身份校验排在落盘投影修复之后（第 18.3 节固定顺序， session.previous.json 提升+删除不可逆）；锁竞争错误回传项目绝对路径（第 18.3 节）； design 组展示名剩两处字典未改（第 18.2 节）；阶段进度轮次差一格。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 11:11:18 +00:00
kdletters	9070c0760b	修复登录服务器切换与本地资源请求 ... - 允许 release 客户端安全访问 custom HTTPS 与本机 loopback HTTP - 修复 Tauri WebView 请求传输与无效 URLPattern - 按服务器 origin 隔离本机 External Editor 凭据 - 保留登录请求底层错误并补充路由与凭据隔离测试	2026-08-18 18:32:49 +08:00
lhk229	c6a08ef98f	修复M1D前端文案回归断言 ... 同步立项入口与设计实现组展示文案的测试期望 恢复Frontend tests与Native shell tests中的前端测试覆盖	2026-08-18 09:35:28 +00:00