5分钟策划agent #159

Merged

kdletters merged 187 commits from feat/five_min_design into master 2026-08-24 21:44:45 +08:00

Conversation 2 Commits 187 Files Changed 173

+50484 -1704

187 Commits

Author	SHA1	Message	Date
lhk229	9e4b2b1dc1	交付行被裁掉：策划面不再参与 flex 压缩 ... 批准后 GUI 里看不到路径和「查看 GDD 正文」「打开文件」两个按钮。不是没渲染，是被 切了：`.plan-gdd-surface` 为了画圆角带 `overflow: hidden`，而工作台那条又给它 `flex: 0 1 auto` + `min-height: 0`。聊天列纵向吃紧时 flex 把这个面压到内容高度以 下，裁掉的正是最底下那行。标题和轮次在上面，所以还看得见——症状就是「那一栏太小」。 批准前 strip 只有两行、从不需要压缩，所以直到加了第三行才暴露。 它也不需要可压缩：标题栏是固定几行，审批卡自己有 max-height 和内滚，高度天然有界。 改成 `flex: 0 0 auto`。另外「标题栏定高 + 正文占余下」的两行轨道只在审批卡在场时 成立，批准后面里只剩标题栏，把它挪到 `--with-card` 修饰类下。 补一条 A/B 过的断言（改回可压缩即红）：这个面必须 `flex: 0 0 auto` 且不带 grid-template-rows，两行轨道只出现在 `--with-card` 上。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 13:28:05 +00:00
lhk229	e5fa6438ca	Merge branch 'feat/five_min_design' of ssh://genarrative-station:2222/GenarrativeAI/Genarrative into feat/five_min_design	2026-08-24 12:51:59 +00:00
kdletters	79e31d948e	Merge branch 'master' into feat/five_min_design	2026-08-24 20:51:36 +08:00
lhk229	c0f616427e	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-24 12:45:38 +00:00
lhk229	7d92076071	合并 master：资源画布与图片精修链路 ... 四处冲突的取舍： - view/project-development/index.tsx：master 把 UI 编辑器从顶层三元分支 挪进 workbench stage 内部，改用 `is-ui-editor` 类切单栏、运行与播放按钮 在编辑器打开时禁用，并去掉了 `!focusedResource` 守卫。取 master 的结构， 再把分支的 `is-conversation-only` 追加进同一个 className。 - styles.css：双方各加一条 `.game-workbench-layout` 规则 （分支 `is-conversation-only`，master `is-ui-editor`），两条都留。 - tests/appSurface/home.suite.ts：双方在同一位置各加一个用例 （分支的做方案根 run 路由、master 的直连美术实时刷新），两条都留。 - SupervisorChatOnlyView.tsx：master 在该文件只有 prettier 重排版，没有 逻辑改动，取分支的 projectedRuntime 与 descendantsStillActive 判据。 验证：agc:typecheck 通过；cargo check --all-targets 0 error；eslint、 prettier、cargo fmt、check:encoding 通过；AGC 前端 931 passed / 1 failed， 唯一失败是本机已知的 Windows symlink EPERM 基线。appSurface 从 425 增至 426，双方新增用例都在。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 12:43:53 +00:00
lhk229	41adfea134	策划 hydrate 收窄到策划链路，并收口三处重复事实源 ... 审查四条： 1. GDD hydrate 原本挂在任意 run 的任意一次监工状态变化上，而后端 hydrate 要抢项目写锁、扫 authority、必要时修投影，等于让做游戏和 做素材两条链路的每一拍心跳都去抢一次写锁。加一道门收窄。 门不能只看 source：审批卡的可见性判据是 `displayGdd && (pendingApproval || recoveryPending)`，跟当前 run 的 source 无关，非策划分支的监工面板也要靠 pendingApproval 点亮等待 审批位。所以判据是「策划链路 或 策划状态尚未落定」。 判据取 source 标量而不是 runtime 本体，保住那条 effect 依赖里只放 标量的原设计；策划状态读 ref 不进依赖，否则 hydrate 触发 hydrate。 后端把能力位读取提到取锁之前——它读的是应用配置不是项目文件，跟锁 无关，而 load_game_creator_app_config 每次都遍历所有配置路径读盘。 返回值不变，只是少占一段写锁。 2. 删掉零调用方的 append_plan_provider_usage_fact_for_test，cargo 的 never used 告警随之消失。 3. 前端 'project-supervisor-plan' 从三处收到 app/constants 一处： AgentRuntimeState.source 只是裸 string，改名没有任何编译期提示。 Rust 侧 filesystem.rs 两个守卫统一走 PLAN_FAST_GDD_PATH，顺带修掉 其中一处大小写敏感、另一处不敏感的不一致（两者串联使用，原先没有 实际绕过）。跨语言没有共享常量通道，TSX 与 mjs 只能留交叉引用注释。 4. App.tsx 里 game-chat 终态判定的两个本地实现删除，6 处调用改用 gameChatRuntimeProjection 的出口。保留 App.tsx 冻结 manifest 快照 的那道闸门——它判实时 manifest 决定要不要冻快照，与 canArchiveGameChatStage 判已冻快照不是重复检查。 验证：cargo check --all-targets 无新告警；agc:typecheck、eslint、 cargo fmt、prettier、check:encoding 通过；appSurface.test.ts 425/425。 Rust plan 过滤 404 passed / 2 failed，两条均已逐条定性为非回归： planning_clarification_answer_prepared_recovery_releases_execution_before_project_wait 在纯基线上同样失败（既存红），tool_plan_handoff_repair_restart_replays_chain_without_network_request 单独跑通过（本机批量 flaky）。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 12:35:27 +00:00
lhk229	4c20e06a9a	子 run 卡在 needs-reconciliation 时把父 run 一起抬出回执等待 ... 现场：上游网关把流掐断在 response.created 之后，策划子 run 落到 needs-reconciliation，父 Supervisor 在 waiting-for-delegate-receipts 上静默 二十分钟，界面全程显示「正在启动处理」。前端认得 needs-reconciliation， 但它读的是父 run，而父 run 看上去一切正常。 成因是三件事叠起来： 1. 委派子 run 的其余每一条终态出口都会向父 run 发布结果—— finish_game_creator_agent_runtime_turn_at、fail_..._turn_at、 fail_..._budget_at 三条都调 publish_game_creator_agent_delegate_result_for_state ——唯独 needs-reconciliation 不发。它在 task_queue 的 outcome match 里从 `outcome => return outcome` 那条兜底臂返回，一个通知都没有。 2. delivery 于是永远停在 Dispatched，而 static_delegate_completion_barrier_at 无条件把 Dispatched 计入 waiting。 3. 父唤醒是一次性事件驱动的：drive_waiting_static_delegate_parent_wake_pass 一旦看到 has_waiting() 为真就永久 return，没有任何周期性复查。 那条出口拒绝**认领结果**是对的——Runtime 无法证明服务端副作用是否已经发生， 伪造一份 delivery 结果比卡住更糟。缺的是「这条委派不会再产生回执」这句话。 改法：在 outcome match 里给 NeedsReconciliation 补一条臂，把父 run 也标成 需要人工核对（复用既有的 mark_static_delegate_parent_wake_needs_reconciliation_at）， 不伪造任何 delivery 结果。该原语自带门槛——父 run 的 run_id 不匹配、或父 run 不在 waiting-for-delegate-receipts 时直接返回 Ok(())——所以重复调用与竞态安全。 只覆盖立项策划子 Agent。做游戏与做素材的委派子 run 逐字保持既有行为； 它们那条链路上同一个死锁仍然存在，解开需要另行评估各自的父 run 语义。 守卫的四个前提拿现场 gameagent-75a9be8d 的落盘数据逐条验过：子 run phase=needs-reconciliation、parentAgentId=project-supervisor、parentRunId 与 父 runId 逐字相同、父 phase=waiting-for-delegate-receipts。这个修复会在那次 事故上真的触发。 三条新测试：策划子 run 卡死必须把父 run 抬起来；重复通知无副作用； design-director 子 run 同样卡死时父 run 一个字节都不变。 需要说明的是，被测的是 notify 助手本身，outcome match 那一行接线没有被覆盖 ——驱动一次真实的 NeedsReconciliation 需要 Provider。 delegated_child_reconciliation_tests 3/3、delegation::tests 19/19、 tool_plan 93/93、user_input 21/21、prompt::tests 32/32、 plan_envelope_repair_tests 6/6。tests::collaboration 仍是本机既有的 4 条失败， 已 stash 做 A/B 确认失败集合逐条相同。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 09:36:52 +00:00
lhk229	4a3a5beaf0	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-24 08:26:14 +00:00
lhk229	7057daeb82	清理立项策划运行时死代码 ... 删除未使用的 planning storage 加锁 wrapper 和未接入授权层 删除旧 provider binding 与 approval fingerprint 入口 修正测试 fixture 直接调用 _locked 核心实现 修复非 Unix 分支不可达返回	2026-08-24 08:23:04 +00:00
lhk229	1c6a95aa1a	GDD 批准后补上交付出口：标题栏给出本地路径、查看正文与外部打开 ... 批准之后审批卡按设计整张收掉，从那一刻起用户就再也够不到自己刚批的 GDD： approvedGddRef 前端没人读，渲染好的 game/fast_gdd.md 也没有任何入口。做方案链路 跑到头是没有交付物的。 不新增卡片——交付行挂在阶段进度条底下，只在 state 为 approved 且不在恢复态时出现： 一行绝对路径，两个按钮「查看 GDD 正文」「打开文件」。批准前后是同一个框，多一行， 视觉连续。恢复态不给出口：那时权威投影还没收敛，磁盘上那份未必是用户批的那版。 正文弹层从审批卡里抽成 GddDetailsDialog 两处共用，内容一字未改，于是批准前后看到 的是同一份正文。路径按项目路径自身的分隔符拼，Windows 下不会混出反斜杠与正斜杠 各半的怪路径。 后端新增 open_local_project_plan_gdd_markdown，走 opener 交给系统默认程序。路径不 由前端拼：命令自己用 resolve_local_project_path 在项目根下解析常量相对路径——那是 项目内路径的唯一安全入口（根校验、归一化、逐段拒绝符号链接），GDD 的渲染侧用的也 是同一个解析器，两边对「项目内的这个文件」必须是同一个判定。再加存在性与普通文件 检查，未渲染时给出明确原因而不是把不存在的路径丢给 shell。 顺带修一条我在 80200e6a3 调高度时漏跑全量而留下的红：project-development 里那条 断言把 clamp 的三个断点钉成了字面量。它要锁的不变量是「自带上限 + 自己滚」，数值 是随排版调整的设计取值；钉死只会让每次调高度都顺带改测试，却挡不住真正的回归。 改成不锁数值，并补一条策划窄条没退回去继承 240px 天花板的断言。 新增测试（前端三条都做过 A/B，关掉交付行即红）： - Rust：路径门四条（正常解析、未渲染、非项目目录、相对路径）。 - 前端：approved 态出现路径与两个按钮且没有批准/修改/退回；点「打开文件」用正确 参数 invoke；recoveryPending 时交付行不出现。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 07:40:01 +00:00
lhk229	6578bcf2ae	策划窄条不再吃调试面板的 240px 天花板，放宽到 52dvh/640px ... 截图里被压出内滚的是澄清卡所在的窄条：纯总控视图整个包在 game-workbench-chat 里，窄条带着 agent-runtime-status 类，继承了给做游戏链路常驻调试面板设的 clamp(120px, 24dvh, 240px)。窄条只在需要用户动手时出现，内容是要读完再回答的 题面，按审批卡同级放宽；小屏媒体查询里的 max-height: none 分支原样生效。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 06:38:27 +00:00
lhk229	80200e6a33	做游戏工作台里策划审批卡的高度上限从 34dvh/380px 提到 52dvh/640px ... 底部运行面板在策划链路下已收成窄条，让出来的纵向空间还给审批卡：决定项清单 多数情况下不再需要内滚就能看全。仍保留上限与内部滚动，防止极长 GDD 把消息列 表挤出可视区。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 06:22:49 +00:00
lhk229	dc51e6efda	修掉 Repository checks 拦下的行尾空白与 rustfmt 漂移 ... CI #4304 挂在 trailing whitespace 检查（exit 2），其余全绿（appSurface 421/421、web 与 admin-web 两个 build 都过）。 cli.rs:2203/2210 —— reads_plan_gdd_approval_comment_from_stdin 用多行字符串 字面量喂 stdin fixture，「前后带空格的正文」和「纯空白行」这两个待测输入的 空格正好落在源码行尾，被 git diff --check 判掉。改成 \n 转义写成单行： 字符串字节一个都没变（仍是 " 把核心循环写具体 \n" 和 " \n"），只是不再 把空格摆在行尾。测试照旧通过。 顺带 cargo fmt。四处漂移全是我这几个提交带进来的（provider_tool_plan、 main_loop、agent_db 三处新增代码，加上 cli.rs 这次改动让 rustfmt 可以把 Cursor::new 收成一行），本仓库其余部分没有既有 fmt 漂移，所以整包 fmt 是 安全的。 delegation::tests 19/19、plan_envelope_repair_tests 6/6、 tool_plan_audit_finish_reason 2/2、cli 那条 1/1。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 06:04:40 +00:00
lhk229	01f855a50c	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-24 05:04:00 +00:00
lhk229	aebdb7a948	坏信封在工具计划直出那一发就拦下，重取回路终于进得去 ... 上一版重取回路装在 final-reply 请求路径上，而策划子 Agent 的澄清信封根本 不走那条路：main_loop.rs 里 stream=false 且 plan.response 非空时直接 `final_reply = Some(response)`，随后 `if let Some(reply) = final_reply` 整块跳过 else 分支——重取回路就在那个 else 里面。所以它是死代码。 证据在 response-streams：27 个历史 run 的 68 条信封全部落在 final-reply-loop-N 记录上且 finishReason 一律为 null（短路路径没有 provider 响应对象，标记无从填），而真正发过 final-reply 请求的那几条写着 "completed"。 7 条坏信封无一例外走的是短路。之前那个 mock harness 怎么调都不触发， 原因就是这个，不是 Ready(None) 的 outcome 分支。 改法：短路处不再无条件认领最终回复。策划子 Agent 且信封解析失败时，把解析 原因作为 observation 回灌，不设 final_reply，让流程落回真正的 final-reply 请求——重取回路在那边生效，总计 1 发初始 + 2 次重取，与原型 MAX_WASTED_TURNS=3 同口径。 两个注入点合用同一条整改正文（提取成 plan_envelope_repair_observation）， 只有阶段名不同，否则模型会把它读成两种不同的失败。converged 仍为 true： 这一轮确实收束了，只是不认这条信封当交付。 作用域由 game_creator_agent_runtime_plan_envelope_parse_error 把住——非策划 Agent 一律返回 None，做游戏与做素材逐字保持既有行为。 plan_envelope_repair_tests 6/6（含一条现场退化尾巴不再烧重取额度）。 回归对照：tests::provider 143/143；tests::collaboration 与 tests::runtime_actions 改动前后失败集合逐条相同（4 条 / 1 条本机基线）。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 04:59:11 +00:00
lhk229	caf021e556	tool-plan 审计记下上游终态标记，预算切断不再无声 ... tool-plan 这条链路此前把 finish_reason 整个丢掉了：provider_tool_plan.rs 全文没有一处引用它。platform-llm 只在**存在工具调用**且上游明确给出未完成 终态时才拒收（reject_incomplete_tool_calls），其余情形按「可用的降级结果」 放行；而这一层既不看也不记，审计里没有任何东西能把「上游说这一轮没写完」 和「模型自己写歪了」分开。 信封退化的排查就卡在这个盲点上：我一度据此判定上游根本不发 status，实际 response-streams 里的 final-reply 记录明明写着 "completed"——只是 tool-plan 那一发的标记从来没落过盘，而策划子 Agent 的信封恰恰产在 tool-plan 那一发 （stream=false 时 plan.response 直接充当 final reply，不再发 final-reply 请求）。 只记录，不改判。是否因未完成终态拒收仍旧由 platform-llm 决定，做游戏与 做素材逐字保持既有行为。 字段按固定字符集夹紧后落库：兼容网关会在这里发自定义值甚至整段文案，审计 不是转发通道，越界字符丢弃、长度夹到 32、夹空记 null。agent_db 侧同步进 PROTOCOL_FIELDS 白名单并复核夹紧结果——那张白名单是精确长度匹配，写入侧 加字段而不同步读取侧会直接把审计写失败。 tool_plan 过滤器 93/93。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 04:30:50 +00:00
lhk229	8e3dae3446	澄清信封按括号配平定界，退化尾巴不再判死整条委派 ... serde 的 from_str 要求整段输入就是一个值，尾部多一个字节就整包拒收。 而模型在长嵌套 JSON 字符串的尾部会退化：27 个历史 run 的 68 条真实澄清 信封里，有 2 条把信封写完整之后继续在同一个字符串里吐垃圾—— 「 马会」、「સwerhu рҭ. 北京赛车? тру. [ ]」。信封本体一个字节都没坏， 函数调用的 arguments JSON 也一次成型（repairAttempt 全为 0），却和真正 写坏的信封一样停在 needs-repair。 这不是截断：坏信封 445–520 字符，好信封 439–529 字符，分布完全重叠， 全场最长的那条解析正常。撞上 max_output_tokens 会把 arguments 本身切断， 那会留下格式修复痕迹，实测一次都没有。 改成从标记后第一个 `{` 起做括号配平扫描（跳过字符串与转义），只把配平的 那个对象喂给 serde，与原型 design_agent.py 的 parse_envelope 一致。信封是 终态协议载荷，配平对象之后不存在协议内容。长度上限随之改按切片计算： 退化尾巴既然不进解析器，也不该替一条合法信封把通道撑爆。 少写闭合符的那一类（同批 5 条，结尾 `}]}` 而非 `}]}]}`）仍然失败—— 那是模型真没写完，补括号只是替它猜一个没表达出来的形状，交给 run 内重取。 三条新测试用的是现场原样抓来的载荷：两条退化尾巴必须解析成功，一条缺 闭合符必须继续失败，外加一条正文里含括号字符的信封验证定界只认字符串外的 括号。delegation::tests 19/19，user_input 过滤器 21/21。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 04:22:30 +00:00
lhk229	bc6c1e57a0	合并 master：resume 入口与 ProjectDevelopmentView 各留双方新增 ... 两处冲突都是双方各自新增、互不相干： - recovery_scan.rs：master 在 resume 入口加了 recover_direct_taonier_regeneration_workflow_at（硬 `?`），分支加了策划 GDD 审批投影恢复（分三路容错、不硬传播）。都留；master 那句放前面， 保持它原有语义不受分支块影响。 - WorkspaceLauncher.tsx：master 的 walletEntry 与分支的 planningStartMode 是同一个 JSX 元素上两个独立 prop，都留。 typecheck 干净，eslint rc=0，cargo check --all-targets 通过， appSurface 421/421，分支自有过滤器（plan_envelope_repair_tests 4、 native_agent_delegate 9、prompt::tests 32）全绿。clarification 仍是本机 既有的 1 条锁超时基线失败。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 03:56:17 +00:00
lhk229	dc0a168ef1	坏信封在 run 内就地重取，不再逃逸成一条委派 ... 按原型（local-scripts/deisgn_agent）的口径：信封解析失败是「本回合没推进 流程」，注入原因后在同一个 run 里重来，而不是终止 run 让它落成一条 needs-repair delivery。 接入点在 final reply 返回处。解析失败时把原因作为 observation 回灌，用带 后缀的 request slot 重取 final reply，上限 2 次（对齐原型 MAX_WASTED_TURNS=3：前两次注入重试，第三次放行）。用尽后按既有路径落盘， 此时「连写三次都不合法」确实是质量问题，按普通质量返工计费与返工深度、 澄清轮次、session 段落三套不变量全部自洽，不需要放松任何一道。 只覆盖 project-planning。做游戏 / 做素材的静态委派子 Agent 逐字保持既有 行为，它们的坏信封仍按原路落成 needs-repair。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 03:22:41 +00:00
lhk229	b7bc4c4442	回滚坏信封的谱系计费改动，改走原型口径的 run 内重试 ... Revert f38ce456d 和 f7644ff5c。 对照原型（local-scripts/deisgn_agent）后确认这两个提交修错了层。原型把 信封解析失败当成「本回合没推进流程」，在**同一个 child run 内**注入错误重来， 与「超轮次仍提问」「纯自由文本」共用一份 MAX_WASTED_TURNS=3 的预算；坏信封 根本不会变成一条 delivery，委派谱系、澄清轮次、返工深度、session 投影一个 都碰不到。 生产是让坏信封逃逸成 needs-repair delivery，于是牵动三套编码了同一条假设 （新委派 = 新段落）的不变量。逐道放松的代价已经现形：改完谱系计数撞上 session 投影的 quality-repair 分支，改完那支又撞上 PLAN_IDENTITY_CONFLICT「非 UserRevisionRequested 父边不能保留 appliedAnswers」。 正确做法是在 final reply 返回处就地解析信封、失败则有界重取，不让它逃逸。 届时「重试 3 次仍写不出合法信封」确实是质量问题，按普通质量返工计费与三道 守卫全部自洽，不需要 userInputEnvelopeUnparsable 字段，也不需要 EnvelopeRetry 那支跳类型文案。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 03:15:26 +00:00
lhk229	9ad22bf4ae	广告 schema 也得允许两个数组传 null，否则继承分支走不到 ... 上一提交让 Runtime 在返工/续跑时继承 acceptanceCriteria 与 expectedArtifacts， 但广告给模型的 agent.delegate schema 把它们写死成 `"type": "array"` + minItems 1。模型根本没法传 null，只能继续手抄，继承分支一次都没走到。 无头验证实测：改动前后每条 continuation 都固定先失败 2 次 （verify-farm-2 共 4 次，verify-farm-3 共 6 次），完全没有变化。我上一轮 汇报「0 次」是错的——当时截断了 inspect 输出，没看到那一段就下了结论。 两个字段的 type 改成 ["array", "null"]，各自带上说明；工具描述补一句 「返工与澄清续跑一起传 null 由 Runtime 继承」。测试同时钉住描述文案和 schema 的 null 可空性。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 02:50:50 +00:00
lhk229	f7644ff5c5	坏信封重投不得重置澄清轮次，额度按连续次数算 ... 无头验证抓到的回归。上一版把坏信封的免费额度做成整条谱系一个总额，超出后 落回质量返工分支——而那一支会把 round 归零。 实测复现的链：坏信封 → 第1轮 → 第2轮 → 坏信封 → 目标。第二次截断超出总额， round 被清零，planning_coordinator 于是按 current_round + 1 要求 「第1轮·关键决定」，子 Agent 按真实轮号写的 header 被拒，父 run 卡进 needs-reconciliation： PLAN_INVALID_CLARIFICATION: plan question header 必须精确等于 第1轮·关键决定 两处都改： - 坏信封跳**永远不重置** round。一次输出被截断既没有推进也没有否定任何已 确认的决定，凭什么把用户已经答过的两轮作废。 - 额度按**连续**次数算，不是整条谱系一个总额。分散在链上的多次截断各自独立； 连续多次才说明子 Agent 真的不会写这个契约，那时才计返工深度。 跳类型文案跟着改：新增 static_delegate_next_hop_is_free_envelope_retry， 只在本跳确实免费时才说「不消耗返工深度」，否则退回质量返工文案——否则文案 在超额那一跳上是假的。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 02:42:29 +00:00
lhk229	58d9e9a5d4	返工委派的两个数组也改由 Runtime 继承 ... acceptanceCriteria 与 expectedArtifacts 必须逐字继承原委派， validate_static_delegate_repair_request_at 会逐项比对。但这两个值 Runtime 从 repairOfDelegationId 指向的 delivery 直接读得到——它就是拿这份权威值去 比对的——要求 Supervisor 手抄一遍不带来任何信息增益。 上一次无头验证实测：一个两轮澄清的 plan run 里， 「静态委派返工必须完整继承原 acceptanceCriteria 和 expectedArtifacts」 出现 4 次，每建一条 continuation 都要先白跑两轮工具调用才抄对。出问题的 那次生产 run 也有同一条。 现在带 repairOfDelegationId 时这两个数组可以整体传 null，由 Runtime 从原 delivery 补齐；只省一半仍然按原样交给既有比对报错，初次委派仍须自己写。 和上一批指纹改动同源，形状一致。 plan playbook 同步：第 4 步四个字段一起传 null；第 6 步不再要求先用 agent.run_status 取回合同再手抄，省掉一次往返。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 01:35:13 +00:00
lhk229	f38ce456d1	坏信封重投不再吃掉唯一的返工额度 ... 子 Agent 终态首行是 AGC_NEEDS_USER_INPUT_V1 但信封 JSON 解析不了时， Runtime 把它降级成 needs-repair，于是下一跳按质量返工计费，吃掉整条委派 唯一的 repair_depth。 生产实测这不是质量问题：农场经营项目里被截断那次的正文与重投那次逐字节 相同（445 vs 447 字符，前者是后者的严格前缀），只少了收尾的 `]}`， 报错是 EOF while parsing a list at line 1 column 904。一次字节级截断把 返工额度用光，之后真出现方案质量问题时已经没有返工可用。 structured result 新增可持久化标记 userInputEnvelopeUnparsable（旧记录 反序列化为 false，按原样当质量返工处理）。谱系计数遇到带这个标记的父节点 时既不加 repair_depth 也不重置 clarification_round，额度上限 1：连续第二次 落回返工分支，由既有的 repair_depth <= 1 兜住，不会无限重投。 任务正文同步加 EnvelopeRetry 一支。原来那句「唯一返工轮」对重投跳既是 假天花板，又是做游戏链路三个视觉角色 replaceExisting=true 的授权信号， 不能复用。Repair 分支逐字不变。 顺带把 cargo fmt 对前两个提交里新增代码的重排一并带上。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-23 17:05:30 +00:00
lhk229	998ebbf0e7	澄清回灌带上问题原文和选项标签，止住两轮问同一件事 ... plan 根 playbook 规定的回灌格式是 `[已确认] {header} → 用户答：{原文}`。 {header} 按信封契约恒为「第N轮·关键决定」，零信息量；而 project-planning 每轮都是全新 run（observations 为空），除了委派任务正文什么都看不到。 于是第 2 轮的子 Agent 拿到的是「[已确认] 第1轮·关键决定 → 用户答：类似B， 无关卡设计，可自由安排……」——B 指哪个选项它无从得知，问题原文和 A/B 选项全被丢掉了。 生产实测的农场经营项目里，第 1 轮问「季节订单冲刺 vs 自主农场成长」， 用户答 B；第 2 轮又拿「短周期经营目标 vs 沙盒里程碑成长」问同一条轴， 而且 B 选项几乎是用户原话的复述。一轮预算白烧。 回灌格式改成带问题原文和三个选项标签，并写明为什么不能省。压缩优先级 同步调整：长度吃紧时先压自己的说明文字和选项描述，问题原文与选项标签 和用户答案一样不许压。 子 Agent 侧加一条兜底：已确认决定关掉的轴不得重问，本轮问题必须落在 另一条还没关闭的轴上，全关闭时按出稿触发器③直接出稿。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-23 16:52:18 +00:00
lhk229	af6c044851	plan playbook 同步：澄清指纹传 null，别再从 observation 抄 ... 上一提交把两个指纹改成 Runtime 从原 delivery 补齐，但 plan 根 Supervisor 的 playbook 第 4 步还写着「并提交 observation 给出的 questionsSha256、 answersSha256」——正是这条指令让它去手抄 128 个十六进制字符。改成明确 传 null 并说明由 Runtime 补齐，加一条断言钉住。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-23 16:48:11 +00:00
lhk229	535eef8b58	澄清续跑的两个指纹改由 Runtime 补齐，不再让 Supervisor 手抄 ... agent.delegate 的澄清 continuation 要求 Supervisor 在输入里填 questionsSha256/answersSha256 两个 64 位十六进制串。实测这会打死整个 plan 根 run：Supervisor 先抄成上一轮的指纹（校验不一致），再抄成非 hex 格式，工具计划格式修复两次仍失败后整轮判 failed，用户已提交的两轮澄清 回答全部作废。 这两个值原 delivery 已经唯一确定：resolve 时本来就从 delivery 读出 权威值来算 continuation identity，输入侧那份只被拿来比对，不参与任何 计算。手抄 128 个十六进制字符没有信息增益，只增加失败面。 现在指纹可以整体省略，由 Runtime 从 repairOfDelegationId 指向的原 delivery 补齐；填了仍然逐字校验。锚点 continuationOfDelegationId 保持 必填。三个字段一律按 JSON null 等同缺省处理，与既有可空字段一致。 Runtime 注入的澄清任务正文同步改成明确告知不要自己填写指纹。 共享 helper 上加了等价断言：省略指纹推导出的 continuation identity 必须 与手填时逐字相同，所有澄清 continuation 用例顺带覆盖。 本机 planning_clarification_answer_prepared_recovery_releases_execution_ before_project_wait 在改动前后同样失败（同一条断言），是既有环境失败。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-23 16:44:48 +00:00
lhk229	c489c92084	修复澄清自由输入把整页打进 error boundary ... 澄清卡片的自由回答输入框在 setAnswers 的 updater 里读 event.currentTarget.value。React 在事件派发结束后会把 currentTarget 置空，而 updater 要等渲染阶段才跑，读到的就是 null，抛出 "Cannot read properties of null (reading 'value')"。异常出在渲染阶段， 被 AuthenticatedClient 的 error boundary 接住，整页被换成 "客户端页面加载失败"。 手动输入、以及先选中选项再删除填充文本，走的都是这一个 onChange。 改成在事件里先取出 value 再交给 updater。新增的回归测试在 StrictMode 下渲染卡片（与 main.tsx 一致），覆盖这两条路径。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-23 15:36:02 +00:00
lhk229	1335b64d6b	策划区合成一个面：阶段进度当标题栏，审批卡头去掉重复的状态与指纹 ... 阶段进度条和审批卡原本各带一圈边框叠在一起。「立项策划 / 待审批」在进度条和卡头 各画一遍，「v1」在进度条、卡片 meta 行和批准按钮上出现三次，卡头还露一截 12 位的 指纹——那是开发者核对用的，用户不需要。 新增 PlanGddSurface 做外壳：边框和圆角只画在它上面，进度条成为标题栏，审批卡成为 正文，卡头只剩游戏标题和一句话。meta 行整行删掉：版本在标题栏和按钮上都有，决定 数就是下面那张清单本身，指纹整条搬进「查看 GDD 正文」弹层底部做追溯。两个挂载点 改成只挂这一个组件，可见性判据抽成两个小函数供外壳和两块子件共用，不再各自拼装。 做游戏工作台原先给卡片设的高度上限和内部滚动挪到外壳为 flex 子件、卡片为可滚行， 行为不变。 新增一条 appSurface 用例（A/B：换回旧卡片即红）：状态与版本只在标题栏；卡内没有 「立项策划」「待审批」「版本 v1」「指纹」；弹层底部有完整版本与指纹。 styles.css 在基线就不符合 prettier，本次只改相关规则，不整文件重排。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-23 14:47:01 +00:00
lhk229	e57d81454f	合并 master：首页创作类型选择器接管做方案入口，startMode 改为派生 ... master 这 22 个提交里有一处和本分支正面撞车：它把首页那枚选择器做成了三类型 （做游戏 / 做素材 / 做方案，HomeCreationType），而本分支此前把同一枚控件砍成了 两项（做游戏 / 做方案）并直接用它当路由（ProjectStartMode）。做素材必须与 master 一致，所以取 master 的三类型控件，startMode 不再是独立状态，改为从 creationType 派生：doc → planning，其余 → direct-build。两个字段在 LauncherProjectContext 和 HomeDraft 里并存，creationType 记入口原始类型，startMode 记链路路由。 五处冲突的处理： - app/types.ts、useHomeProjectCreation.ts：creationType 与 startMode 并存，调用 顺序统一跟已自动合并好的函数签名走。 - view/home/index.tsx：选择器整段取 master，删掉本分支已无人引用的 HOME_START_MODES / HOME_START_MODE_ITEMS，startMode 就地派生。 - SupervisorChatOnlyView.tsx：master 新增的 directCodex 活动时间分支保留，内层 runtime 换成本分支的 projectedRuntime；master 那句 `!directCodex && synchronizingAcceptedRun` 是冗余的（合并后 synchronizingAcceptedRun 的定义里已经带了 !directCodex），它重复声明的 activeCollaboratingRuntimes 也丢掉——上面已经声明过一次。收束判据取本分支的 runtimeTerminal / descendantsStillActive。 - styles.css：master 的聊天气泡样式与本分支的审批卡高度上限互不相干，都留；补上 master 最后一条规则缺的闭合括号（它原本借用冲突块外那个共用的 }）。 两处测试跟着改： - appSurface/harness.ts：afterEach 补一次 useLauncherHomeDraftStore.reset()。 首页创作类型存在 module 级 zustand store 里，跨用例不会回到初始值；合并后建项 按钮的文案依赖它（做方案 → 进入立项策划），上一个选过做方案的用例会让下一个 找不到「开启创作」。合并前 startMode 是组件 useState，这个泄漏看不出来。 - appSurface/home.suite.ts：master 新增的用例在选中做方案后仍按「开启创作」找 按钮，改成「进入立项策划」——本分支有意在这一档改了文案，suite 里本分支自己的 用例也是按这个口径找的。 验证：npm run typecheck 干净；eslint 改动文件零告警；cargo check --all-targets 通过；appSurface 403/403。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-23 12:33:56 +00:00
lhk229	e5f537c807	提问预算收回给策划子 Agent，Supervisor 不再自撰提问门槛 ... 首轮委派 task 由 Supervisor 自由撰写，实测它每次都把提问条件写成一个高门槛： 「若确有缺少且会实质改变结果的用户事实……否则直接创建并提交完整 GDD」。本机 13 个生产 project 里 8 个是 0 轮直出，CLI 同参基线 8 个 run 也有 3 个 0 轮、 均值 0.75 轮、无一顶满 3 轮预算。 病根是提问门槛这件事同时写在两个地方而且口径相反：plan/common.md 告诉 Supervisor「专业 Agent 若缺少会实质改变结果的用户事实才提问」，Supervisor 照抄 进 task；而子 Agent 的 role brief 只写了 3 轮上限，没写默认姿态、没有判断该不该 问的程序、也没有它自己两次引用的那份「默认建议」清单到底是什么。 按原型的做法收口——两边各一份闭集白名单，不给「可以无视 task」的授权： - roles/project-planning.md：出稿触发器收成四个（任务正文出现「直接出稿」四个字 / 已完成第 3 轮 / 剩余空白能被默认建议覆盖且不影响首个可玩闭环 / Runtime 超时 提示），任务正文能改变流程的只有第一条。Supervisor 写的门槛不在其中，自然不是 触发器，不需要授权无视。补上字段差距检测（逐项对照 plan-submit-gdd-input.v1 的 game 字段三分类，提问名额只花在空白项）和那份缺席的默认建议清单。 - plan/supervisor-playbook.md：本轮指令三选一（继续澄清 / 直接出稿 / 按意见修订）， 不得自撰提问条件。独立成段，因为 both_playbooks_carry_the_same_anti_pre_deciding_contract 要求共享段在两条 lane 逐字相同，并进去就得改做游戏 lane。plan/common.md 那句病根改不动（planCommon 受逐字子集断言约束，且通用 common.md 的口径对其它专业 Agent 是对的），只能覆盖。 默认建议按本仓库的 GDD schema 重排，没有照抄原型：原型的「缺成长 / 缺探索 / 缺构建」三条落到 plan-submit-gdd-input.v1 上全在 pillars 与 coreLoop，而那两个字段 就是首个可玩闭环本身，给它们配默认值等于把最该花提问预算的两项默认掉，和 「提问顺序：核心行为与本局目标 → 重玩动力」的前两顺位直接打架。故清单只覆盖 genre.fusion / artStyle / targetUsers / outOfScope，并明写 pillars 与 coreLoop 没有默认建议。 实测（8 vs 8，同一句开场白、同一条 --swarm-chat --plan、同一个模型、决策卡一律 选 A）：轮数均值 0.75 → 2.62，0 轮 3/8 → 0/8，顶满 3 轮 0/8 → 6/8；Supervisor 在 首轮 task 里写提问门槛 8/8 → 0/8。这会让用户明显感到问得多了，是有意的产品取舍。 补一条断言：这份 role brief 此前两次要求「按默认建议填写」却从未写出清单，就是 因为没有任何测试看着它。新断言钉住清单在场、按 schema 字段名写、pillars 与 coreLoop 被排除、出稿触发器是闭集。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-23 11:31:23 +00:00
lhk229	85823eb732	澄清续跑不再被当成唯一返工轮，做游戏链路的返工文案原样保留 ... master 只有一道平坦的 depth<=1 门，任何第二跳都拒，所以委派 task 末尾那句 「这是对已认领委派 X 的唯一返工轮」对澄清跳也是真的。本分支改成按谱系分类 （澄清跳不吃 repair_depth、上限 3）之后没同步这句话，它就变成了假天花板。 本机 13 个生产 project 的委派账本：4 次澄清续跑 4 次命中这句话，命中后全部 直接出稿，没有任何一个 run 走到第 2 轮。 三处一起收口： 1. render_static_delegate_task_contract 的入参从 Option<repairOf> 换成显式的 StaticDelegateHopNote。Repair 分支逐字保留原文——design-foundation / art-director / art-asset-plan 的角色提示词把「任务正文明确标识这是带 repairOfDelegationId 的唯一返工轮」当作 replaceExisting=true 的唯一授权 信号，改一个字就会让返工轮拿不到许可。新增的 PlanClarification 分支写明 已用轮次与上限；预算用尽时改为要求收稿，因为出卡侧本来就会拒掉第四张卡。 2. 同一句里写明本轮 header 该用第几轮。planning_coordinator 出卡时要求 header 精确等于「第N轮·关键决定」，N 由 Runtime 从谱系派生，而此前没有 任何地方告诉子 Agent 当前轮号——修完第 1 条后第 2 轮信封会栽在这里。 轮次与上限都用 static_delegate_lineage_counters / *_round_limit_at 现算， 和出卡校验器同源。 3. plan/common.md 对 Supervisor 说子 Agent 返回「1-3 个结构化问题」，而 plan 链路的校验器只收恰好 1 题，Supervisor 照抄进了委派 task。修正放 plan/supervisor-playbook.md：prompt.rs 有断言钉死 planCommon 必须是 common.md 的逐字子集，而通用 common.md 的 1-3 对其它专业 Agent 是对的。 判据用 clarification_continuation_identity.is_some() 加 target 是 project-planning：后者由 validate_project_planning_child_binding_at 强制挂在 project-supervisor-plan 根下，所以做游戏 / 做素材 / game-chat 的澄清续跑与 全部质量返工仍走 Repair 分支，渲染结果与 master 逐字相同。 实测（9 个 --swarm-chat --plan run）：6 次澄清续跑全部拿到新句、0 次误用返工 文案；2 次真正的质量返工仍拿到原文；有 1 个 run 走到第 2 轮并被出卡侧接受， 最终提交 GDD。0 轮直出那一档基本没动——决定要不要开口问的是首轮委派 task 由 Supervisor 自由撰写，那是另一件事，本次不动。 这个 renderer 此前零直接测试覆盖，补一条钉住两支文案、轮号和预算用尽。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-23 09:39:27 +00:00
lhk229	0638c1b5b9	立项策划链路底部改成窄条，只留澄清卡和失败恢复，做游戏链路面板原样保留 ... 做方案链路的底部挂的是 ProjectSupervisorRuntimePanel——一块为做游戏链路设计的 面板：十几个专业 Agent、多步计划、逐 Agent 重试。套到策划链路上，子 Agent 永远只 有 project-planning 一个，计划永远一两步，「专业 Agent 协作：1」永远是 1。它把 D11 的「总控 + 委派子 Run」拓扑整个漏给了用户：currentAction 原文（「等待 project-planning 提交 GDD」）、计划 1/2 进度条、五段式紧凑进度、一张把策划子 Run 当成「专业 Agent」的卡，外加同一个状态在顶部 strip / overview / 子 Agent 卡三处各 画一遍。用户的心智模型是在跟一个策划聊天，不是看总控调度。 新组件 PlanningLaneRuntimeStrip 只画真正需要用户动手的两样：澄清问答卡（复用 AgentRuntimeUserInputCard，零改动）和失败 / 待核对后的恢复入口（逻辑照搬原面板， 文案改成「重新启动策划」）。App 层操作错误那一行保留，那是原面板里唯一面向用户 的文字。其余时候返回 null，不占一行——状态由顶部的 PlanGddStageProgress 承担。 原面板在 waiting-for-user-input 却读不到 userInputRequest 时画的「待回答问题未能 读取」一句不搬：策划链路里这个组合出现在子 Run 退出到父 Run 醒来之间的瞬时窗口， 以及审批等待本身，两种都不是读取失败。 切换判据是 run 的 source === 'project-supervisor-plan'，抽成 isPlanningLaneRuntime 放到独立模块（react-refresh 不让组件文件导出函数），两个挂载点 ProjectSupervisorView / ProjectWorkspaceChatPane 和顶部 strip 的 active 判定统一 用它。判据故意不看 planGddState：做游戏链路在策划批准后照样带着一份 approved 状 态，但它的总控 run 是 autonomous 源，必须继续拿完整面板。source 非 plan 时面板一 行未动，既有的「keeps Project Supervisor plan progress compact」用例仍在守门。 新增三条 appSurface 用例，都做过 A/B（强制回旧面板即三条全红）： - 策划进行中：底部不存在面板、overview、紧凑进度、子 Agent 列表，且 currentAction 原文与「计划 N/M」都不出现。 - 澄清等待：问答卡仍在窄条里。 - run 失败：窄条给出「重新启动策划」，错误文字保留。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-23 05:37:45 +00:00
lhk229	1337ce03e1	策划审批的两个 GUI 入口等过项目锁瞬时争用，不再把成功的审批画成失败 ... 线上症状：点「批准」后卡里弹出 `项目正在被其他写操作占用`，但 agent.db 显示 `plan.gdd_decided action=approve` 已落盘、approvals/v1.json 已写、index 里 approvedVersion=1、run 随后正常收束，且没有任何 gdd_projection_gap —— 审批本身是成功的，报错来自它之后那一次刷新。 成因是决定放行 run 续跑，而 GUI 在 decide 返回后紧接着 hydrate： `decide → await hydratePlanGddState()` 与 runner 的 `agent.schedule_ready`、 会话写入、planning 投影同时伸手拿 `.agent/project.lock`。hydrate 那一支是 一次性取锁、不重试，撞上就返回 PLAN_STORAGE_IO，前端原样贴进审批卡。 仓库里本来就有这个约定：project_gates 的 `..._with_wait` 只认 `项目正在被其他写操作占用：` 这一个前缀并退避重试，运行时侧 18 个点都在用。 策划的两个 GUI 入口是漏网的。按「丢了这一次要付什么代价」分档接上： - planning.gdd-decision 是一次性用户意图，丢了用户得重新找到卡片 → 等满窗口。 - planning.hydrate 是轮询刷新，下一拍还会来 → 只等 1 秒（新增 short wait 档）， 免得为一次刷新把面板卡住整个窗口。 前端再兜一层：hydrate 撞上这条错误时保留上一份状态、不写错误位。后端等过短 窗口仍拿不到，只说明此刻运行时正在写盘；这条 effect 每次监工状态变化都会重跑。 用 includes 而不是 startsWith，因为 hydrate 的错误带 `PLAN_STORAGE_IO: ` 前缀。 两条新测试都做过 A/B（换回一次性取锁即失败）： - decision_rides_out_a_briefly_held_project_lock - hydrate_rides_out_a_briefly_held_project_lock 锁由后台线程持有 120ms 再释放；pid 与 createdAt 都写真值，否则会被失效锁回收 顺手删掉、根本占不住。 hydrate 原有的争用用例（考脱敏与错误码形状）保持红，只更新了那条已失效的 「这一支不重试」注释。 做游戏链路未触及：改的两个函数都是策划专属入口，共用的 `acquire_project_write_lock` 语义一行未动。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-23 05:13:11 +00:00
lhk229	07ab58d2b9	立项策划链路关掉循环窗口记账，做游戏链路原样保留 ... 窗口机制的用途是长 run 的进度 checkpoint 与停滞检测。立项策划链路两样都够不着： 策划子 Run 最多五轮左右，窗口是 AGENT_RUNTIME_BACKGROUND_LOOP_LIMIT，边界一次都 不会越过，checkpoint 和停滞判定永远不产出。它在这条链路上唯一还能产出的是失败—— windowCompletedLoops 跨暂停由 continuation 携带，nextLoopIndex 却从 pending 重读， 澄清应答恢复时两者分岔，context bundle 校验器把这个分岔变成整根 run 硬失败 （线上symptom：windowCompletedLoops=6 max=5）。一个在某条链路上无法产出收益的机制， 也不该有能力向它收费。 做法是给 tracker 加 window_disabled，构造时按 agent_runtime_context_window_applies 判定：source 为 project-supervisor-plan 的策划根、agentId 为 project-planning 的 策划子，两者关掉。complete_loop 命中标志即返回 Continue，计数恒为 0，于是持久化 bundle 在任何 nextLoopIndex 下都落在校验器的允许区间内，分岔不再有落点。 from_continuation 增加 &AgentRuntimeState 参数，让编译器强制 5 个生产构造点和 4 个 测试构造点都显式表态，而不是靠默认值静默选边。字段默认 false，未标记的 tracker 保持完整记账。 做游戏链路是这套机制真正的受益方（run 跨几十轮），一行不改：window_disabled 为 false 时 complete_loop 逐字未变。autonomous 相关 309 条测试全绿。 新增两条测试，都做过 A/B： - 窗口分档：做游戏链路仍在窗口边界产出 checkpoint；策划根与策划子跑满两个窗口 长度也只返回 Continue。 - 恢复偏移：continuation 逐轮接力，复现「计数携带、序号重读」的真实形状，断言每个 nextLoopIndex 下 bundle 都能通过窗口校验。撤掉修复后此测试报 「窗口轮次无效：windowCompletedLoops=1 max=0」，与线上同一条校验。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 11:33:17 +00:00
lhk229	d86ea61a68	审批消费测试改用生产写法收口策划子 Run，补上幂等键冲突的覆盖 ... approval_receipt_consumes_submit_batch_and_folds_final_provider_usage_once 本该覆盖上一个提交修掉的那条链路，却一直是绿的。原因在夹具：它手搓 child_completed 再用 append_game_creator_agent_runtime_task 写终态，而这个入口 不往记录里写 actionId。生产侧走的是 ensure_project_planning_submit_child_completion_at，它用 append_game_creator_agent_runtime_task_projection_once 把 actionId 一起盖进去。 差别正好落在被测的那把幂等键上。磁盘上没有 (runId, actionId, phase=completed) 这一行，receipt 消费时的投影就找不到冲突对象，顺利追加——于是一条 100% 必现的 线上故障在单测里完全看不见。 改成调用生产入口本身，并按它的前置补齐 durable delivery（沿用同模块 2400 行 一带的既有写法，结果文案与生产的 last_response 一致，避免 publish 时身份不符）。 A/B 验证过测试确实抓得住：临时撤掉上一个提交的修复，此测试报 assertion failed: !first.recovery_pending，正是线上症状；装回修复即通过。 同批 planning_submit 并发跑有 6 条失败，逐条单跑全过，是本机 agent.db 文件锁 竞争，与本改动无关。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 10:46:39 +00:00
lhk229	a8f3793865	审批观察不再抢提交点的幂等键，做方案链路能收束了 ... project_generic_submit_runtime_observation_locked 把 currentAction 改写成 「Fast GDD 审批观察已落盘」，然后用 pending.action_id 调 append_game_creator_agent_runtime_task_projection_once。但那把幂等键是 (runId, actionId, phase)，提交点已经在 phase=completed 上用同一个 actionId 写过一条 currentAction=「Fast GDD v1 已完成 create-only 提交」。三项全同即判为 同一条投影，9 个比对字段里 currentAction 不同 —— 必然硬报错，不是偶发。 后果是撕裂写：报错发生在 standalone pending 已经被改成 observed-approved 之后， v4 batch 还停在 ready/executing。两个恢复锚点从此不一致，恢复扫描只认原始 executing 形状，把策划子 Run 打成 needs-reconciliation；而重放路径的 phase == "completed" 闸门又因此永远过不去，撕裂再也修不回来。做方案链路的审批 因此从来没有成功过一次。 改法是让审批投影沿用提交点的 currentAction。9 字段全同，helper 视为重放直接 返回 Ok，链路继续往下推进 batch、清锚点、唤醒。审批这件事由 gdd_decided 审计 记录和 plan.submit_gdd.observed 事件承载，本来就不需要再占一条 task 投影—— 全仓库另外 9 个调用点都是「一个 action 一条投影」，只有这里想写第二条。 同一处还补上诊断。project_receipt_locked 里 13 处失败原本全部塌缩成一个 recovery_pending bool，其中两处是显式 let _ = error; 丢掉错误原文。receipt 已经 是用户决策的线性化点，这些失败都不能报成命令错误，于是唯一逃出来的症状就是 recoveryPending=true —— 说不出是哪一步、为什么。真因就是这样被藏了整条链路。 现在每处先写一条 agent.runtime.plan.gdd_projection_gap 记录再置位，带 step 标签 和脱敏后的错误原文；记录是 best-effort 的，诊断不能把已提交的 receipt 变成失败。 真机验证（gpt-5.6-luna，未开 GUI）：turn outcome=settled、 reconciliationAgentCount=0，state/phase=approved、approvedGddRef.version=1、 recoveryPending=false、两个锚点残留 0/0、project-planning 终态 idle/completed、 gdd_projection_gap 0 条、game/fast_gdd.md 落盘。修前同一条链路 2/2 复现 needs-reconciliation。 顺带给 buildCargoCliArguments 加 --quiet，压掉每次 spawn 重印的 cargo 进度行。 注意它不压 rustc 警告，只在重新编译时才有区别。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 10:34:40 +00:00
lhk229	adfa6ed8d3	做方案链路补无头审批入口，不再只能靠 GUI 拍板 ... decide_game_creator_plan_gdd 此前只有 Tauri command 一个入口，无头跑 --plan 到审批卡就永远收不了尾。补两条 CLI： - --plan-gdd-status <项目路径>：只读投影 - --plan-gdd-decide <项目路径> <approve|revise|reject> [--response-id] [--stdin] 审批卡的 identity 由 CLI 自己 hydrate，不让调用方手拼 gddId/fingerprint—— 拼错的后果是 PLAN_STALE_APPROVAL，而不是一条能读懂的用法错误。hydrate 抽成 hydrate_game_creator_plan_gdd_state_for_path，GUI 与 CLI 共用同一道权限闸。 swarm 测试脚本的审批必须和 CLI 并发做：Run 停在审批位时状态是 waiting-for-user-input，而 swarm CLI 恰好把这个状态算作「本轮还在跑」，turn 永远不 settle、CLI 也就永远不退出。等 CLI 退出再审批那一步根本到不了，实测 是干等到超时。改成认「等待 Fast GDD 审批决定」这条投影文案触发。并发子进程 单独跟踪，不占 activeChild 槽位，否则 Ctrl-C 杀不到 CLI。 decide 回执带 recoveryPending 时补一次 --agent-resume：审批回执落盘和唤醒 后台任务是两件事，唤醒失败被降级成 recoveryPending，审批已生效而 Run 仍停在 等待位，实测只有补这一次恢复才会重新起 turn。 真机验证：影子机器人解谜需求跑通到 state=approved、approvedGddRef.version=1、 game/fast_gdd.md 落盘，全程未开 GUI。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 09:45:34 +00:00
lhk229	0482d08a69	策划阶段收掉空资源画布，对话列改成非位置相关的弹性列 ... 做方案在拿到第一个产物之前，左边的资源画布是空的（文档 0 项、项目版本 0 项），而澄清 问答、决定卡和 GDD 审批全挤在右边 360px 那一列里，屏幕上七成面积空着。 planningStartMode && resources.length === 0 时给工作台加 is-conversation-only，收成单栏。 画布是 display: none 不是不渲染——页签、缩放和选中状态都留着，出现第一个已登记资源后自动 恢复双栏。planningStartMode 只影响这一处布局，不参与任何 runtime 分流。 同时修重叠。.project-supervisor-conversation 的成员数量随链路变化：做游戏时 PlanGddStageProgress 与 GddApprovalCard 都返回 null，做方案时它们出现，pendingCommand / pendingConfirmation 也各自条件渲染，最多能到八个。原先按位置分配五条轨道，只对做游戏那几 个成员成立——做方案一进来整列后移两格：可伸缩的轨道被阶段进度条占走，审批卡落到能被压到 0 的 minmax(0, auto) 上，末尾成员溢出到隐式行再被容器的 overflow: hidden 裁掉，界面上就是 审批卡截在半句话、消息列表和运行时面板糊在一起。这也是为什么只有做方案会重叠。 改成弹性列后「谁伸缩」由类名决定而不是由出现顺序决定，加减成员不再移位。审批卡另外加了 自己的天花板与内部滚动：它是这一列里唯一没有上限的成员，Fast GDD 的决定项越多它越高，能 把消息列表和运行时面板一起挤出可视区。 原契约用例钉死了旧的轨道字符串，改成断言新的不变量：flex 列、不再出现 grid-template-rows、 消息列表是伸缩的那个、审批卡有上限。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 08:15:38 +00:00
lhk229	c1a8ca6481	GDD 审批卡不再被两张伪卡压住 ... 立项策划提交 Fast GDD 后，界面上同时冒出三样东西：一句「待回答问题未能读取，请稍后 重试」、一张 plan.submit_gdd 的拒绝/确认卡，以及被压在下面的 GddApprovalCard。前两样 都是伪的。 plan.submit_gdd 的 pending 是审批卡的载体，不是等待批准的动作——planning/pending.json 的 submission.pendingActionId 指向的正是它，交互面是审批卡的批准/修改/退回。它和 user.input_request 是同一性质，而且运行时策略明确拒绝把它转成通用确认 pending （「Runtime-owned create-only 提交」），那个确认按钮点下去必然失败。所以把载体判据从只认 user.input_request 扩成两个工具都认，并改名 agentRuntimePendingActionHasDedicatedCard。 同时补上第四个渲染面：协作 Agent 列表也无条件把 pendingToolAction 画成通用确认卡，上一次 只改了开发者面板、总控概览卡和聊天视图三处。 「待回答问题未能读取」则是另一回事：审批等待复用了 waiting-for-user-input 这个 phase，但 它没有 userInputRequest，只看 phase 就会把一次正常的等待报成读取失败。给 ProjectSupervisorRuntimePanel 加一个 planGddAwaitingDecision 入参，由两个调用处按 planGddState.pendingApproval 传下来，等审批时不再报这句错。 新增用例同时断言三条：审批未决时不出现「待回答问题未能读取」、不出现 plan.submit_gdd 确认卡、审批卡的批准按钮在位。两条判据都做过 A/B——各自关掉后对应的伪卡都会冒出来。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 07:53:15 +00:00
lhk229	65c3d172b2	澄清转述那一轮的 context bundle 不再被判身份不匹配 ... 走过一轮澄清的立项策划必挂：策划子 Agent 完成、父 run 醒来认领委派回执时，整轮报 「恢复 Agent Runtime context bundle 失败：身份与当前任务不匹配」，用户答案已落盘却 无法继续。 bundle.task 存的是写出这份 bundle 的那一轮的任务，跟 run 的持久 task 是两个独立参数 （build_game_creator_agent_runtime_context_bundle 的 task 形参）。用户答完澄清后整条 run 改跑在转述任务上（run_recovered_game_creator_context_on_fresh_task 传的就是 pending.task），那一轮写出的 bundle 因此带着转述文本，而 task record 与 current_task 始终是用户原始请求。实测项目里两侧身份字段全等，只有 task 一项分叉。 validate_agent_runtime_pending_context 早就为 pending 入口豁免过同一条文本相等断言， 并留了注释说明转述是唯一一处 task 不等于本 run 任务的场景；bundle 这个入口漏了。这里 补上同一个豁免，只放开文本相等一条——project/agent/task_id/session/run/source/profile/ 绑定指纹与 verification_gate 三项照旧全等，转述文本也只能由 Runtime 在本 run 内生成， 不放开任何跨 run 或跨身份的重放面。 新增用例同时断言两侧：转述 bundle 必须能读回，其它文本分叉照旧 fail closed。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 07:32:25 +00:00
lhk229	2a44169ddb	澄清卡不再叠一张通用确认卡，策划根委派免确认 ... 子 Agent 要提问时，Runtime 在 parent-wake 屏障处把问题包成 user.input_request pending（ensure_static_delegate_user_input_wait_at_locked），同一份问题再投影成 userInputRequest。这个 pending 只是问题的载体，user.input_request 也从来不在 GAME_CREATION_APP_COMMANDS 的 confirm 集合里，没有任何确认语义。但三个渲染面都 无条件把 pendingToolAction 也画成通用待确认卡，于是同一个请求出现两遍：上面是问答 卡，下面是拿 tool 名当标题、拿 questionCount/questionsSha256 这种取证摘要当副标题 的确认卡，还和问答卡在聊天视图里糊在一起。 加 agentRuntimePendingActionIsUserInputCarrier，在开发者 Runtime 面板、项目总控 概览卡和聊天视图三处统一把通用确认面判掉，只留问答卡。 立项策划根 Run 的 agent.delegate 同时改为免确认。plan 根的工具面按阶段收窄到「当前 唯一能推进链路的动作」，Delegate 阶段就只广告 agent.delegate 一个工具，让用户确认 「要不要执行唯一能做的那件事」没有决策含量，返工那一轮同理；这条链上真正由人把关的 关口是 §13.0 的 Fast GDD 审批卡，不动。source 只作弱判据，命中后必须过 validate_project_supervisor_plan_root_binding_at 强判据，否则做游戏那条根的委派确认 会被漂移或伪造的 binding 悄悄放开；绑定读盘只发生在本来就要确认的 agent.delegate 这一个组合上。 新增两条用例：Rust 侧一起断言 plan 根 delegate 免确认、plan 根上 agent.spawn_isolated 照旧确认、gui 根 delegate 照旧确认；前端侧断言载体 pending 只渲染问答卡，且 user.input_request 与 questionsSha256 都不出现在界面上。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 07:09:50 +00:00
lhk229	8e5e0a7fea	做方案入口改回两枚模式 chip ... 上一版把「做方案」做成输入框工具栏里的单个开关，默认不选中。问题是默认态没有 任何文字说明"现在会做游戏"，只有"做方案没被选中"——它读起来像筛选标签而不是 模式分叉，把默认态藏了起来；而且模式选择混进了附件/发送那排动作按钮里，层级也 是错的。 改成合并前的形态：输入框上方一排常驻 chip，做游戏（默认）与做方案两个都可见， 选中态填色。两个互斥选项都重要时分段控件才是标准解法，单开关只适用于"关是明显 默认且功能人尽皆知"；做方案是这条分支要暴露的新链路，最缺的就是可发现性，而且 点错起的是另一条 runtime 链（委派、澄清 pending、GDD 审批），不该藏在一次猜测 性的点击里。样式与容器沿用合并前已上线的类名。 做素材不加回来：master 已把它并进直连构建，与做游戏同链，再列一枚就是两个按钮 干同一件事。占位文案随模式变（做游戏／做方案各一句），副标题保持 master 的固定 问候语——合并前那版副标题与占位是同一句话，重复两遍。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 04:52:00 +00:00
lhk229	ab6070e8e3	首页加回做方案入口 ... master 的直连 Codex 改造把 HomeAgentMode 和「做游戏 / 做素材 / 做方案」模式栏 整个删了，合并后 startMode 在前端没有 planning 的来源，只能写死 direct-build。 立项策划链路的后端、prompt、澄清卡、审批卡都还在，但从首页够不着，CI 上 home.suite.ts 的两条 routes 做方案 用例也因此找不到按钮而挂。 不把三选一搬回来（那是 master 主动收掉的产品形态），只在输入框工具栏加一个 「做方案」开关：选中时 startMode 走 planning、提交按钮文案切成「进入立项策划」、 占位文案换成方案口径；不选中时与 master 的直连默认完全一致。 createHomeDraft / createHomeDraftAutomatically 改为由调用方传 startMode， 删掉 HOME_DRAFT_START_MODE 这个占位常量。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 04:31:52 +00:00
lhk229	bfa112094c	合并远端 master（直连 Codex 改造） ... 冲突 19 处 / 6 个文件，逐处判定归属而不是二选一： · commands.rs —— 保留本分支的 hydrate_game_creator_plan_gdd_state 输入解析， 丢掉与 master 重复的项目根定义（master 把它挪到了后面）。 · types.ts / useHomeProjectCreation.ts —— 取 master 把 mode/prompt/attachments 重构成 HomeDraft 的形状，保留本分支新增的 startMode。 · App.tsx —— directGameChatRuntime（master）与 !planningStartMode（本分支）是两个 互不相干的条件，合并保留；refreshDirectProjectSurface 在 merge base 里就带预览 逻辑，是 master 主动删掉并改名成 refreshDirectProjectManifest 的，取 master； capturePendingGameChatStageManifestBeforeNextRun 是分支新增且仍被调用，保留。 · SupervisorChatOnlyView.tsx —— master 的 directCodex 短路与本分支的 projectedRuntime / descendantsStillActive 正交，逐处合成。 · project-development.suite.ts —— 那段专业 Agent 断言 base 里就有、master 主动 删除（直连 Codex 之后不再适用），取 master。 两处语义缺口一并补上：master 新增的 codex_app_server 构造 AgentRuntimeProviderRequestSnapshot 时缺本分支新增的 planning_session_binding 字段（首页直连对话不属于任何立项 session，填 None）；首页提交按钮的 aria-label 还引用着已被删除的 homeAgentMode，取 master 的固定文案。 **做方案 UI 入口暂时缺失，待定。** master 在 bacd7a9da 里把 HomeAgentMode 整个删了， 首页的「做游戏 / 做素材 / 做方案」模式选择不再存在，而 startMode 在前端只有那一个 来源（homeDraftStartMode(mode)）。立项策划链路的代码全部保留——后端、prompt、 澄清卡、审批卡、E2E 都在——但首页现在统一按 direct-build 进入 （HOME_DRAFT_START_MODE 常量，已在原处留注释）。入口放哪由产品侧决定后另做一笔。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 13:49:37 +00:00
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
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
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
lhk229	c497a221fd	移除无关流程图脚本 ... 删除未被本分支使用的 draw-agent-loop-flow 脚本	2026-08-19 06:32:55 +00: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
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
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
lhk229	c6a08ef98f	修复M1D前端文案回归断言 ... 同步立项入口与设计实现组展示文案的测试期望 恢复Frontend tests与Native shell tests中的前端测试覆盖	2026-08-18 09:35:28 +00:00
lhk229	4624fd7953	同步M1D合入状态记录 ... 更新M1D-1与M1D-2的合入提交和自审结论 保留M1E端到端与故障注入后续范围	2026-08-18 09:21:58 +00:00
lhk229	bf2185fba0	完成M1D-2入口分流与阶段进度 ... 游戏新项目默认进入立项策划并保留直接开建路径 项目总控页面挂载GDD审批卡与阶段进度 同步策划展示名称、定向测试与开发日志	2026-08-18 09:11:38 +00:00
lhk229	9bad7121b5	修复 Native shell tests 既存红：委派用例改调 _at_locked ... CI task 3784 的 Native shell tests 报 2121 passed / 3 failed，三条同因： agent.delegate -> failed, "无法取得一致项目快照" 项目正在被其他写操作占用：$PROJECT_ROOT/.agent/project.lock - autonomous_direct_child_collaboration_mutations_require_the_current_root - autonomous_delegate_descendant_inherits_and_enforces_the_current_root_guard - standard_delegate_collaboration_mutations_remain_compatible 根因是又一次「把动作挪到调用链更前面，改变的不是严格度而是作用范围」。 bc1fe7d8f 写这几个用例时，观察点是「测试先持项目写锁、再调 observe_agent_runtime_agent_delegate」，当时无害：老薄壳压根不碰项目锁，它调的 start_..._with_link_at 只对 planning 身份取锁，其余身份走 ..._with_project_lock_at(..., None)。 152cc40c7（完成 M1C-2b 策划澄清与预算接线）为了让 planning 子 session 的投影按 project -> session 取锁，把锁的所有权上提，拆出 observe_agent_runtime_agent_delegate_at_locked，并让同名薄壳在入口无条件取项目写锁。 而 .agent/project.lock 是 create_new(true) 的文件锁、不可重入：调用方已持锁再进薄壳 就死等满 2000x5ms 预算再失败。确定性红，不是抖动——本机复现逐字一致。 这不是生产漏洞。生产侧调 agent.delegate 的只有 action_execution.rs:436 和 pending_recovery.rs:162，两处都持锁后调 _at_locked；取锁的薄壳如今零生产调用方， 只剩测试在用（main_loop_tests、autonomous_completion_contract_tests 那些都不持锁， 所以一直是绿的）。所以改测试面，生产代码零行改动。 - delegation.rs 四处（2515/2584/2678/2740）改调 _at_locked 并传入已持有的 &project_lock。这不是迁就实现：_at_locked 才是生产唯一的调用形状，改完这三个用例 覆盖的是真实路径。首处留注释说明为何必须绕开同名薄壳——否则下次「顺手统一」回去 会复发，而症状是 10s 静默卡顿，很难往锁不可重入上想 - runtime_tools.rs 补一条 #[cfg(test)] pub(crate) 再导出。生产侧靠 pub(in crate::agent) 的 glob 即可见，测试模块在 crate::agent 之外需单独放行； 沿用旁边 #[cfg(test)] pub(crate) use delivery::{...} 的既有写法，不动生产可见面 验证：tests::collaboration::delegation 改前 22 passed / 3 failed（18.68s），改后 25 passed / 0 failed（5.54s）。少掉的 13 秒正是三条各自空等 10s 锁预算的量——那三次 等待没再发生，不是断言被放宽。cargo fmt --check 干净。 另记一条前提更正：AGC shell crate 是有 CI 的。project-ci.yml 的 native-shell-tests job 跑 npm run check:native-shells，本次覆盖 2124 条。此前「这个 crate 在 CI 里从不 编译也不测试」的判断是错的。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 08:35:27 +00:00
lhk229	5b11a05303	修复 M1D-1 带进的 eslint 红：import 排序与 hook 依赖判据 ... CI task 3777 的 Repository checks 停在 lint:eslint，前面的 encoding / git-hooks / rustfmt / spacetime schema / production-ops / preview-deployer / maintenance-page 全绿。三条问题全在 0052a80da 自己动的两个前端文件里。 - simple-import-sort：新加的 PlanGddDecisionAction / PlanGddStateViewV1 插在了 PendingCommand 前面（ASCII 序 Pending < PlanGdd），ProjectWorkspaceChatPane 里 GddApprovalCard 也落在同目录组末尾。autofix 修正 - react-hooks/exhaustive-deps 是 warning，但 lint 脚本带 --max-warnings 0，一样退 1。 这条不能靠补依赖解决：该 effect 的依赖只挖 phase/status/updatedAt 三个标量，正是 为了避开轮询每轮新建对象的身份变化；把 projectSupervisorRuntime 本体写进依赖会让 每个 tick 都触发一次 hydrate。改的是判据侧——存在性从整个对象换成必选字段 status（AgentRuntimeState.status: string 必选，为 undefined 当且仅当 runtime 为 null），语义等价且不再引用裸对象 本地 npm run lint:eslint（全仓，--max-warnings 0）、npm run typecheck、 npm run check:encoding 均通过。typecheck 是 CI 未走到的下一步。 另记一笔：.husky/pre-commit -> lint-staged -> scripts/lint-staged-eslint.mjs 会拦这 两类（自动修 import，且 errorCount 或 warningCount 非零即置退出码），本 worktree 的 core.hooksPath 也确实指向 .husky/_。这三条能进库说明 0052a80da 绕过了钩子。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 08:08:57 +00:00
lhk229	0052a80dad	完成M1D-1策划状态与审批卡 ... 新增严格输入的策划状态 hydrate command 与 plan-gdd-state-view.v1 read model 接入 GDD 审批卡、正文详情弹层、决定幂等与恢复重试 补充 M1D-1 开发日志和技术方案状态	2026-08-18 07:56:20 +00:00
lhk229	14c00017c6	同步M1C-2c合并状态 ... 更新项目决策日志中的合并提交信息 同步技术方案的M1C-2c完成状态	2026-08-18 06:20:49 +00:00
lhk229	c85452795d	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-18 06:16:47 +00:00
lhk229	0abdc41c3c	M1C-2c 收口：分隔符集合补全角冒号，并钉住 label 与回答的同尺比对 ... 分隔符集合原本只有 `·`/`:`/`-`。prompt 全中文、实测用的是 DeepSeek 系模型，在中文 语境下写 `A：方案名` 是高频输出；漏掉全角冒号的后果不是判错，而是合法信封被判形状 错误、回灌重试，白吃一个未推进回合预算——而第 23.9 节自己就记着无界重试把单次 prompt 撑到 15 万 token 的实测。 - PLAN_OPTION_LABEL_DELIMITERS 补 `：`；prompt 的 label 说明与技术方案 §5.1、§5.2、 §23.9 三处分隔符合同同步改口，避免两侧各写一份 - 回归 planning_clarification_accepts_fullwidth_colon_option_labels。变异验证： 去掉 `：` 后该用例立刻红 另外收回一条误报。此前判断「答案走 normalize_plan_text 被 trim、label 是信封原文没 trim，模型吐带尾随空白的 label 会让用户点选 A/B 掉进自由填写分支、台账记成 user_freeform」。写完测试做变异验证时把改动回退，用例照样绿；查下去发现 user_input.rs 的 normalize_single_line_user_input_text 在信封严格解析时就已经 trim 过 label（并拒掉含换行的 label）。两边本来就是同一把尺子，不对称不存在。 - 生产侧只把比较抽成具名函数并在原地写清它依赖的是解析侧那条 trim，不做多余的重复 规范化——那会把一个不存在的风险写进代码 - 保留 planning_clarification_option_pick_survives_untrimmed_label，它钉的是上游那条 不变量：解析侧哪天不 trim 了，这条会红 - 测试脚手架加 *_with_labels 变体，让用例能注入自定义 label；原有 helper 转为薄包装 planning_clarification_ 16/0、plan_ 160/0、recovery 107/0，fmt 干净。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 06:15:25 +00:00
lhk229	6234b420fc	修复 HEAD 既存红：策划恢复门用例改建可达状态 ... planning_recovery_contains_session_identity_conflict_before_provider 自 M1C-2b （152cc40c7）写下起一天都没绿过：它伪造一个 source=agent-background-task、且没有 Run Profile 绑定的策划任务，而 agent_runtime_tool_policy_snapshot_for_run_at 早在 M1A-2（09c7d7af8，152cc40c7 的祖先，已核对该门在 152cc40c7 当时就一模一样）就按 agent 身份挡死了这种 run。被告造不出来，庭开不了。当时的定向门禁过滤器 planning_clarification_* 恰好匹配不到它的名字，加上本 crate 不在 CI 里编译，两层 网都没接住。 那道创建门不能放宽：放宽后伪造的策划 run 就能拿到默认宽工具面，正是 M1A-2 关掉的 洞。所以改测试而不是改生产代码。 也不删：该用例第四条断言「身份门必须早于任何 Provider lifecycle」是全 crate 唯一 一处该不变量的否定断言（AGENT_RUNTIME_PROVIDER_REQUEST_LIFECYCLE_RECORD_TYPE 共 22 处引用，否定断言仅此一处），且 plan_session_recovery_gate_tests 模块只有这一条 用例，删掉等于整个门失去覆盖。 先试了更贴现实的「事后删父绑定」，实测走不到本门：entrypoints 的 tool policy 收容 （currentAction=Run Profile 工具策略需要人工核对）先把 run 打成 failed， read_recoverable_... 随即不再认它，审计里只有 agent.runtime.turn。也就是说绑定层的 破坏到不了 session 门；能到这里的只有「绑定完好、task record 自身不满足 D11 契约」 这一类持久不一致——这正是本门存在的理由。 - 改成：supervisor plan 根与 planning child 绑定都合法（创建门放行），但裸 start 不带 task link，task record 上没有 parentAgentId/delegationId - 四条断言原样保留：resume 必须 Ok（收容不外溢）、该 run failed/needs-reconciliation 且 error 含 PLAN_SOURCE_PROFILE_MISMATCH、审计有 plan.session_recovery. needs_reconciliation、且没有任何 Provider lifecycle 记录 - 断言失败信息带上实际审计记录类型与 currentAction，下次判因不用再加探针 - 变异验证：把 exact_plan_child_identity_at 的策划识别翻成直接 Ok(None)，用例报出 "PLAN_NEEDS_RECONCILIATION: project-planning 恢复任务未命中 planning session 协调器" ——证明它确实在考这道门，而不是碰巧绿 - recovery 107/0、planning_ 151/0、session 88/0、plan_ 160/0、approval 11/0 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 06:02:33 +00:00
lhk229	73816bd512	修复 HEAD 既存红：planning session 恢复块给双锚缺失诊断让路 ... committed_plan_submit_without_either_anchor_is_publicly_recoverable_and_fails_closed 在 HEAD 上确定性失败（Windows 与 WSL 干净基线一致，与本轮审查修复无关）： phase 确实是 needs-reconciliation，但 error 不是「恢复锚点同时缺失」。 M1C-2b 把 planning session 恢复块插进了同一个循环，位置在 reconcile_missing_plan_submit_anchors_at 之前。该 fixture 用裸 start_game_creator_agent_runtime_task_at 建策划任务，task record 上没有 parentAgentId/delegationId，于是 exact_plan_child_identity_at 判定身份不符、 返回类型化 Err，session 块随即落 needs-reconciliation 并 continue，更具体的双锚 缺失诊断永远轮不到跑。两条都写 needs-reconciliation，谁先写谁赢，而先写的恰恰是 信息量更少的那条。 不是判错，是插在前面的门改变了哪条诊断胜出——与 M1C-1 那五条 CI 失败、与 P4 同一形状。 - session 恢复块加让路条件：该 run 是双锚缺失候选时跳过。本块只服务「将要继续」的 continuation，而双锚缺失的 run 根本不会继续，修投影没有意义 - 选让路而不是调换两块顺序：调换会让锚点探测对所有 Agent 提前，正是「前移改作用域」 那个坑本身。探测器只对 project-planning + agent-delegate + standard 返回 Some， 且对已按双锚缺失收敛过的状态返回 None，因此这道让路既窄又幂等 - recovery 族 105 passed/2 failed -> 106 passed/1 failed，planning_ 150/1、 session 87/1；剩下的唯一红是 planning_recovery_contains_session_identity_conflict _before_provider（另一条既存红，下一个提交处理） Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 06:02:05 +00:00
lhk229	c1a70cb37d	审查发现2：验收前置门先识别 Fast GDD 再走绑定父链 ... ensure_plan_gdd_approval_pending_after_acceptance_locked 先用会遍历并校验整条 祖先链的 read_..._run_profile_binding 读绑定，再检查 binding.source 是否为 project-supervisor-plan。顺序反了：任何祖先绑定的毛病都抢先变成 Err，连「这根本 不是策划根」都来不及说，于是别人的坏链变成了这道门的失败。 这正是 P4（cb5af31e7）在同文件 plan_root_completion_identity_at 修过的形状，当时 漏了这个姊妹函数。而它比完成门更容易被踩到：agent.run_status 每次 status observation 都会重跑本门（见 runtime_tools/run_status.rs 的 「Re-run the locked gate on every plan-root status observation」），那条路径上没有 任何上游守卫先把带父链的 run 挡掉，适用性完全交给门自己判。 - 识别改用 _once，只看 run 自己那条绑定记录；确认是策划根之后才走完整父链， 严格度一点没降，只是不再作用到别人身上 - 回归 broken_ancestor_binding_must_not_fail_the_acceptance_gate_for_a_non_plan_supervisor_run： 复用 P4 的构造（supervisor 的 isolated-join 子 run，删掉父绑定），断言门只能判 NotApplicable。变异验证：换回链走优先后该用例报出 Err("Agent Runtime Run Profile 父绑定缺失") Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 05:33:52 +00:00
lhk229	7e3fd411a1	审查发现1：澄清恢复的锁序重排改为让出本轮，不再掐掉整批 resume ... M1C-2b 为澄清 pending 新增的「drop 执行锁 -> 取项目锁 -> 重取执行锁」重排块， 两次取锁都用裸 `?`。执行锁的重取只等 25 x 10ms，而用户刚提交澄清回答时那把锁 会被 move 进后台续跑任务、持有整个 Provider 回合，稳超等待上限；错误经 recovery_scan 的裸 `?` 上抛，掐掉 for agent_id 循环里整批 Agent 的恢复，并把一次 纯瞬时的锁竞争直接返回给前端。 锁被占恰恰说明别处正在推进，是最不该判失败的时候。同一个 commit 里的姊妹代码 （planning session 恢复窗口）已经写对：项目锁按 transient 判据 continue，执行锁 用非阻塞 try_acquire 拿不到就 continue。 - AgentRuntimePendingActionResume 新增不带锁的 Deferred，表示两把锁都已释放、 本轮让出；批量扫描的三处 match 一律 continue - 项目锁改为 transient 判据让路，其余错误仍带上下文上抛 - 执行锁改用 try_..._with_wait：等待宽限不变，超时是「本轮没轮到」而非「恢复失败」 - Runner 定向续跑不是批量扫描，Deferred 仍如实报错，文案沿用执行锁自己的措辞 - 回归 planning_clarification_recovery_defers_when_execution_lane_is_still_held： 按住项目锁把恢复卡在重排窗口，抢走执行锁后放开项目锁，断言必须 Deferred。 变异验证：回退成阻塞版 `?` 后该用例报出 "Agent Runtime 正在执行该 Agent 的其他任务：project-supervisor" Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 05:33:36 +00:00
lhk229	6e4bd97039	收口M1C-2c决策卡A/B语义 ... 更新策划决策卡的A/B平行方案与原型验证合同 收紧Runtime选项校验和决定状态映射并保留用户原文 补充必要的自由填写与非法信封回归 同步更新提示词、技术方案与项目决策日志	2026-08-18 04:27:54 +00:00
lhk229	0199fb6e4c	决策卡 A/B 修订改回恒定三项，标注 M1C-2b 已合回、M1C-2c 可开工 ... - 技术方案 §5.2 指向注 / §23.8 M1C-2c 行 / §23.9：第 3 项「需要原型验证」每张卡固定给出， description 须给出可执行的验证方式；信封形状校验改为恰好三项 - §23.9 与 decision-log 条目：M1C-2b 已快进合回并把固定三选项的校验与映射冻结在 planning coordinator，映射翻转/形状校验/prompt 文案由 M1C-2c 承接，现在即可开工 - decision-log：补 M1C-2b 条目与本条之间缺失的空行 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-18 03:25:56 +00:00
lhk229	95facd9150	补充 M1C-2c 决策卡文档 ... 更新共享决策日志，记录 A/B 平行方案、改口转述规则与提问纪律。 更新 Fast GDD 技术方案的阶段状态、工作包矩阵和 M1C-2c 设计说明。	2026-08-18 02:58:52 +00:00
lhk229	152cc40c7b	完成 M1C-2b 策划澄清与预算接线 ... 接入三轮澄清中转、确定性 continuation/session 投影及恢复锁序 记录并幂等折叠 planning Provider 活跃时间与末次提交 usage 补齐审批后用户修订谱系校验和质量返工失败关闭 补充并发、恢复、重放、usage 回归并同步技术方案与决策日志	2026-08-17 15:01:33 +00:00
lhk229	9f12d84678	合并原分支最新修复 ... 合入 P4 的 Fast GDD 识别顺序修复。 合入 P5 的委派栅栏 detail 等价性锁定。	2026-08-17 07:31:55 +00:00
lhk229	a8215a5997	P5：把委派栅栏 detail 的「拼串→再解析」锁成等价关系 ... M1C-1 把 userRevisionPending 同时加进了 StaticDelegateCompletionBarrier::detail() 的输出和 project_gates 的解析门，两边靠一个字段名字符串隔空对齐，中间没有共享 schema。 当时生产侧只有 delegation.rs 一条 detail().contains("userRevisionPending=1")，解析侧 一条测试都没有，两者之间也没有任何东西相连：字段名一改，生产侧那条照过，而三个门静默 返回 false，父 run 就会越过用户修订边界收束。 已核实这条路径是「单一生产者 → 四个解析点」：static_delegate_completion_blocker_at 原样使用 detail: Some(barrier.detail())，main_loop 的四处解析都以 tool == "runtime.delegate_receipts" 为前提。 新增用例锁的是等价关系而不是拼写：对七个计数的全部 128 种 0/1 组合，断言三个门的判定 与 barrier 自己的语义谓词逐一相等；另加多位数计数与「键之间互不为前缀」两条护栏——后者 是 strip_prefix 读对值的隐含前提，等价关系测试抓不到这层前提何时被打破。 鉴别力已用变异验证：把解析器的 userRevisionPending 改名为 userRevisionRequested， 或往 has_waiting() 里加一个解析器不认的计数，两个漂移方向都会被抓住。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 07:24:55 +00:00
lhk229	cb5af31e79	P4：先识别 Fast GDD 再走绑定父链，别让祖先坏掉误伤非策划 run ... plan_root_completion_identity_at 读绑定用的是会遍历并校验整条祖先链的入口， 而识别 Fast GDD 只看 run 自己那条记录的 source/profile。链走排在识别前面，于是 任何祖先绑定的毛病都先变成 Err，再被完成门统一翻成 needs-reconciliation——扣在一个 下一行本来就会被判「不是策划根」的 run 头上，让它再也收束不了。 可达：task_start 里 requires_public_start_status 明确把 agent-delegate-receipt 与 agent-isolated-join 排除在「无父的公开启动」之外，带父链的 supervisor run 在生产中 确实存在。新增复现用例在修复前报 Some(NeedsReconciliation)。 改动安全的两条依据： - 两个入口对同一个 (agent, run) 返回的绑定值完全相同（链走版本最后返回的就是 run 自己那条记录），链走纯属校验副作用，识别判据一字未变。 - 策划根的严格度一点没降：validate_project_supervisor_plan_root_binding_at 内部读的 就是链走版本，且强制 parent 必须为空。被移除的只是即将判定「不是策划根」那条路径上 的链走，顺带消掉同一条绑定被连着走两遍父链。 另外把 PLAN_GDD_APPROVAL_SOURCE 与 AGENT_RUNTIME_SUPERVISOR_PLAN_SOURCE 必须同值钉成 编译期断言：识别用前者、复核用后者，两者分处不同模块各自定义，一旦分叉每个策划根都会 先通过识别再被复核拒掉，全部塌成 needs-reconciliation，而且没有测试会指向这个原因。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 07:08:47 +00:00
lhk229	23b6f3a7ca	合并原分支的 M1C-1 审查修复	2026-08-17 05:51:30 +00:00
lhk229	f8568f77db	P3：审批路径统一走 resolve_planning_path，并修正瞬时失败的处理 ... planning_storage 里 M1C-1 新增的六处审批路径绕过了 `resolve_planning_path`， 直接用通用解析器。通用解析器只认 `is_symlink()` 且把结果一律映射成 PLAN_INVALID_PATH；规划解析器认的是 FILE_ATTRIBUTE_REPARSE_POINT 全量重解析 标记，并如实报 PLAN_UNTRUSTED_PATH。审批回执是 GDD 完成门的判据，它的路径 分类必须和 GDD/session 一致。改完后 resolve_local_project_path 在本模块只剩 resolve_planning_path 内部一处调用，成为单一入口。 新增用例用 junction 而不是 symlink_dir 建链接：后者要开发者模式/管理员权限， 普通开发机上建不起来，用例会静默跳过成永远通过的空壳。 delivery.rs 里 user_revision_pending 那条分支是死代码——has_waiting() 已经 把它计入等待，上一道门必然先返回。删掉分支，把语义与跨文件依赖用 debug_assert 钉在使用现场，避免 has_waiting() 日后改动时静默跨过用户修订决策边界。 同时修正上一提交留下的问题：投影恢复失败必须分三路而不是两路。此前把「瞬时」 和「归属不到 run」并成同一个 false，导致瞬时锁争用走了全局上抛，让 resume 这 个可反复调用的恢复入口整轮失败——而锁被占恰恰说明别处正在推进。现在瞬时争用 只跳过本轮投影恢复，其余恢复照常，下一轮重试。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 05:40:00 +00:00
lhk229	34bcd61824	补齐 M1C-1 漏掉的 agent_db 守恒断言，并让审批投影恢复区分瞬时错误 ... M1C-1 给 agent_db 新增了 planning 决策预留车道并从普通追加额度里扣除，但 ordinary_append_soft_limit_preserves_action_receipt_record_slots 仍断言两车道的守恒 律，差额恰好是新车道的 2_097_280 字节；记录额度同样少算 128 条。master 没有这个常量， 所以 master CI 绿而本分支必红。断言补到三车道，记录额度改为 999_680。 审批投影恢复的收敛此前不分错误性质：`.agent/project.lock` 正被占用这类瞬时错误也会 把策划根 run 永久标成 needs-reconciliation——比收敛出现之前的强传播更糟。现在先过 static_delegate_parent_wake_error_is_transient（复用委派唤醒的既有判据，避免两处分类 漂移），瞬时错误照旧上抛，由调用方转成 recovery_pending 下一轮重试；只有持久不一致 才收敛到那个 run。新增回归覆盖这条分支。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 04:55:38 +00:00
lhk229	a60f95b554	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-17 04:30:42 +00:00
lhk229	8d5338ce82	P2：reject 不是死路，锁住真正的约束 ... 原判定「reject 后同一 session 无法再次提交，因为 CAS 门只放行 collecting / revision_requested」不成立。提交门在 phase 判据之前先要求 session 的 activeRunId 等于 当前策划子 run，而 schema 不变量禁止 rejected / revision_requested / approved / awaiting_* / recovery_required 保留 activeRunId——两者互斥，终态 phase 根本到不了那条 phase 判据。把 rejected 加进允许集只会多一个不可达分支，续跑仍然起不来；连既有的 revision_requested 也已经是不可达的。 真正决定 reject 能否重做的是 M1C-2b 的 continuation 起点 writer：技术方案 §8.6 要求它 「以新 activeRunId 写 revision+1 successor」，而唯一能同时带 activeRunId 又过提交门的 phase 只有 collecting。本提交不改行为，只把这条因果写进门旁注释，并加一条回归锁住它： 终态 session 挂 activeRunId 在指纹阶段就被 PLAN_INVALID_SCHEMA 拒绝，而落回 collecting 的 continuation 能过提交门。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 04:28:49 +00:00
lhk229	1fa56a7aee	修复 M1C-1 打破的两条用户修订委派测试 ... M1C-1 让 UserRevisionRequested 与 EvidenceReady 共用同一套客观证据要求 （terminal completed、无缺失产物、验证已满足）。这两条测试仍沿用 M1C-0 时期的模拟 方式：拿一条 needs-repair 的 structuredResult 直接翻 contract_status，落盘时被判成 「evidence-ready/user-revision-requested 与客观证据冲突」——构造本身自相矛盾，不是 代码回归。改成先让 expected_artifacts 真实落盘、再按真实证据重建 structuredResult， 语义也更准：用户是在已交付的产物上要求修订。 已确认为既有破坏：两条在 A+B 之前的 c89a13e68 上以相同行号 panic。M1C-1 的验证范围 只写了 planning_submit/planning_storage 定向测试与 cargo check，delegation.rs 改了 +254 行却没跑，破坏就发生在那次改动里。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 04:16:09 +00:00
lhk229	a40080d525	P1：窄投影恢复失败不再掐掉整轮 resume，plan_gdd blocker 改类型化判别 ... A. reconcile_plan_gdd_approval_projections_at 挂在 resume 的第一行却用 `?` 强传播， 一次 Fast GDD 投影失败会掐掉全项目所有 Agent 的恢复；而它本身正是 receipt 投影失败 后的重试入口，掐掉它等于连兜底一起废掉。改成把 fail-closed 收敛到策划根 Supervisor 这个 run，其余 Agent 照常恢复；无法归属时才退回全局上抛。 B. main_loop 原来用 contains("approvalPending=awaiting_decision") 区分 plan_gdd blocker 的子状态，而三个 blocked 里只有一个含这个子串——尚未提交（下一步是 agent.delegate）和 receipt 锚点收尾都会掉进 else 被打成 needs-reconciliation，把最 正常的推进态当成故障停掉。改由构造方给出 PlanGddCompletionBlockerKind，消费方穷尽 match，判不出 kind 时保持 fail-closed。这两个推进态不再产生等待态，和 runtime.plan_update 一样让本轮循环继续。 映射抽成纯函数并建起 main_loop 至今没有的 mod tests：四个 kind × 两条映射全覆盖。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 04:02:54 +00:00
lhk229	c89a13e682	把 Fast GDD 审批等待的可恢复判据钉成不变量 ... 判据在 task record 的 status 而不是 phase：审批等待只改 phase、保留 status=running，恢复扫描仍会拉起；真正的澄清等待才会把 status 一并写成 waiting-for-user-input。一旦有人把审批等待也写成后者，审批命令的通用 wake 会静默变成 no-op，用户点完批准/修改/退回不会有任何东西继续跑，且无报错。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 03:28:24 +00:00
lhk229	360cedf4c0	合并隔离分支的M1C-1与M1C-2a改动	2026-08-17 03:10:18 +00:00
lhk229	4498c15f90	完成 M1C-2a验收前置门 ... 固定 plan 根 Goal Contract 与唯一 Fast GDD 验收节点。 记录并校验 Supervisor 根 Run 的完整分页 file.read 证据。 接通认领后三态审批前置门、幂等 pending 恢复与完成门。 修复审批后 session 校验及 pending/receipt 优先级边界。 补齐恢复、finalization、身份冲突和工作包边界回归。 同步 Fast GDD 技术方案与项目决策日志。	2026-08-17 02:40:11 +00:00
lhk229	d96fa7b755	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-15 12:03:01 +00:00
lhk229	f45e90e36b	M1C-1：落地 Fast GDD 审批闭环与完成门 ... 新增 plan-gdd approval receipt、pending、审批命令及三动作幂等投影。 接入 receipt 恢复、generic submit 锚点精确消费与 terminal observation 完整性校验。 接入 exact plan-root completion blocker，并补充 pending、recovery、作用域和 identity 回归。 同步 Fast GDD 技术方案与项目决策记录。	2026-08-15 12:00:57 +00:00
lhk229	23559b1b1c	修复 CI 五条失败：三处校验的位置错误放大了作用域 ... 撤回 M1B-2 对 tool-plan 交接判据的跨 loop 上提并补正向回归 恢复扫描的锚点探测器不再对不可读 state 强读，交还下游 fail-closed 兜底 planning 存储把链接路径统一分类为 PLAN_UNTRUSTED_PATH Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 09:45:44 +00:00
lhk229	ecfc6f1a2a	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-15 08:12:43 +00:00
lhk229	f93103760a	M1C-0b：合并原分支最新修复 ... 合入 Agent 主循环栈溢出修复 保留 M1C-0b 静态委派状态前向兼容实现	2026-08-15 08:08:01 +00:00
lhk229	53f2ba30c3	修复 Agent 主循环栈溢出：专用 worker 判据从枚举入口改为不变量 ... CI 上 background_agent_runtime_recovers_stale_running_before_pending_task 在 tokio-rt-worker 栈溢出。根因是 recovery_scan.rs 手写 tauri::async_runtime::spawn 直接 跑 drain_game_creator_agent_background_tasks——正是仓库规定必须上 16 MiB 专用 worker 的那个 future。pitfalls 2026-08-03 按入口枚举了三个（普通后台任务、静态委派子任务、 manifest ready-task 首次执行），恢复重启是第四个，从未被列进去；漏掉一个入口不会产生 任何信号，故判据改写为不变量：所有会进入 Agent 主循环的 future 必须在 agent-runtime-worker-* 专用线程上轮询。 改动： - 统一常量 AGENT_RUNTIME_BACKGROUND_WORKER_STACK_BYTES - spawn_next_*_with_lock 改用专用线程；签名保持 -> ()，8 个调用点不动。该入口是 best-effort 幂等语义（拿不到锁即返回、后续 wake 重试），建线程失败只需记录并随闭包 释放锁，无需交还锁、也就不需要握手 - recovery_scan.rs 两处手写 spawn 收敛为 helper 调用。恢复重启顺带补上首轮轮询握手： 原写法把执行锁 move 进一个无人保证会被轮询的 future，运行时关停时 run 会永远停在 running 且无主 回归钉不变量而非钉余量：drain 入口在 cfg(test) 下记录线程名，用例断言必须以 agent-runtime-worker- 开头。变异验证——改回手写 spawn 且 RUST_MIN_STACK=16MiB（因而不 溢出）时，用例仍以 ["tokio-rt-worker", "tokio-rt-worker"] 失败。 实测（同机、二分 RUST_MIN_STACK，默认栈 2048 KiB）： - started 变体：master 需 1536-1792 KiB，修复前 HEAD 需 2048-2176 KiB - 队列 drain：master 需 1280-1536 KiB，修复前 HEAD 需 1792-1856 KiB，余量已不足 256 KiB - 修复后两条用例在 1024 KiB（半个默认栈）下通过 同过滤器 A/B（runtime_actions + collaboration，同一 skip）： - 修复前 HEAD：19 failed，且在 planning_strategy 处栈溢出 abort - 修复后：289 passed / 0 failed 修复前分支实际有三处溢出点（recovery、response_stream::provider_handoff_*、 planning_strategy::tool_planning::*），CI 只报了最先撞上的那个；三处修复后均通过。 共享 tokio pool 不再被长时间占用，mock LLM 超时类失败同时大幅减少。 需回流 master：master 同样存在恢复重启走默认栈与 drain_next_* 余量偏低，只是尚未触发。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 08:04:06 +00:00
lhk229	89bbfd135a	M1C-0b：补齐静态委派状态前向兼容 ... - 未知 contractStatus 保留为 Unknown(raw) 并接入完成屏障、等待、返工与谱系门禁 - 补齐 planning Provider、自治 liveness 与终态扫描的 fail-closed 消费路径及回归 - 保持已知状态和损坏 sidecar 行为不变，更新技术方案与共享决策记录	2026-08-15 07:04:40 +00:00
lhk229	deae1e08ce	立项策划：裁决 M1C-1 三条开工前置，前向兼容粒度另拆 M1C-0b ... 对 2026-08-14「M1C-0 合入复核」留下的三条前置逐条读实代码后定稿： ① barrier：补，且必须是独立的第六个计数 user_revision_pending_count。 不能并进 repair_required_count——它带 repair_of_delegation_id.is_none() 只算原始委派，而用户第 2 次修订的父节点自身就是 repair 节点，并进去会让 第 2 次及以后的修订全部不阻塞。判据形状照 user_input_required_count。 另有四处逐字段读 barrier 的调用点不走 is_clear()，加字段不会自动传播。 ② 正向一致性：复用 EvidenceReady 的三条客观证据约束，并把该处 if/else-if 链改成穷尽 match；但不得更严——该函数在每次读取时都跑，过严会把写入方的 一个 bug 变成 delivery 永久读不出来。同时订正：这不是既有漏洞，唯一派生点 产不出该变体，约束的是 M1C-1 引入的第二个写入方。 ③ 前向兼容粒度：订正 08-14 自己写的「二选一」——「单条跳过并告警」不安全， barrier 是计数，跳过一条损坏的 Dispatched 记录会让 Supervisor 在仍有未完成 委派时收束，把可用性故障换成正确性故障。改走第三条路（损坏仍整体锁死， 前向不兼容解析进显式 Unknown 并最大化阻塞），并另开 M1C-0b 承接——该改动 触及 master 已发布机制的所有读路径，不得塞进 M1C-1 的 diff。 另记两条比 08-14 更糟的事实：锁死半径是整个项目目录而非单个 run； .json.previous 备份只在 primary NotFound 时回退，损坏但存在的 primary 不回退。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 05:57:12 +00:00
lhk229	f45db359bd	合并最新 master 到 feat/five_min_design，并修复 master 的 Windows 构建中断 ... master 侧 5 个提交（8e78be766..9f5c84ee7）。仅一处冲突： src/view/home/index.tsx 的 react import——我们这侧对该文件只有 prettier 格式化 改动，master 新增的 useRef 在合并后正文里用了 2 次，取 master 那行。 修复 master 带来的 Windows 构建中断（E0658）： project/manifest.rs 的 #[cfg(windows)] 分支用了 std 未稳定 API `MetadataExt::number_of_links`（rust-lang#63010），而 rust-toolchain.toml 锁在 stable 1.96.0。该文件与 origin/master 逐字节相同，即 master 自身在 Windows 上就 构建不过——Linux CI 上 #[cfg(windows)] 整块不参与编译，所以 CI 全绿。 改为本仓库既有写法：自声明 ByHandleFileInformation 调 GetFileInformationByHandle （另见 runner/endpoint.rs、tool_plan_handoff/storage_windows.rs 等六处）。保留原 错误文案与 fail-closed 语义（取不到句柄信息与确实是硬链接同等拒绝），并按 endpoint.rs 先例一并拒绝 directory / reparse point。 该修复目前只在本分支，须回流 master，否则下次合并会再撞一次。踩坑记录见 pitfalls.md 2026-08-15 条。 验证： - cargo check --offline --all-targets 通过（修复前 E0658，修复后 Finished） - cargo fmt --check 通过 - 定向 Rust 测试 project::manifest / godot / static_delegate / collaboration::static_deliveries 65 passed / 0 failed - agc:typecheck 通过；check:encoding 通过（5376 files）；git diff --check 干净 - 前端 vitest apps/ai-game-creator-shell/tests：738 passed / 1 failed，唯一失败是 已知的 Windows symlink EPERM（agentSwarmTestEntry），非本次回归 两条既有环境失败，已核实与本次合并无关： - command_exec::tests 两条报「找不到受信任的 rg 可执行文件」，该文件相对合并基线 逐字节相同 - npm run check:native-shells 在合并前的 master worktree 上失败得一模一样 （spawnSync npm.cmd EINVAL，脚本 spawn npm.cmd 未带 shell: true） Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 05:37:00 +00:00
lhk229	1d4d77ef3d	立项策划：落地 M1C-0 合入复核结论，三条 M1C-1 前置与一条哨兵订正 ... 生产代码零改动（delegation.rs 三个 hunk 全在 mod tests 内），本次只补回归与文档。 复核确认「今天行为零变化」成立且可证：contract_status 生产赋值点只有两处且都从 客观事实派生；StaticDelegateClaimRecord 全仓库唯一构造点是运行时构造，不是 agent 提交的 JSON；durable sidecar 在 .agent/runtime/** 下被 file_ops 与 filesystem 各 三处拒写；前端无 contractStatus 消费者。lineage 三个 fail-closed 出口全部返回 (u32::MAX, u32::MAX)，新分支的哨兵检查接得住。 三条 M1C-1 前置写进技术方案第 23.7、23.8 节与 decision-log： ① UserRevisionRequested 不进 repair_required_count / user_input_required_count 任一 barrier，写入方落地即意味着 Supervisor run 可在用户修订未派出时完成； ② validate_static_delegate_structured_result 对该变体只有否定约束，缺正向一致性 分支，UserRevisionRequested + failed + 缺产物 能通过校验落盘； ③ 前向兼容失败粒度是整个子系统——list_static_delegate_deliveries_at 逐条 ? 上抛， 一条解析失败即整个目录枚举失败。bump schema version 救不了（版本校验在 parse 之后）。 文档订正：STATIC_DELEGATE_LINEAGE_MAX_HOPS = 32 限的是链上节点数不是跳数 （判据排在入链之前），真实跳数上限 31，第 23.7 节原写 32 跳已订正。 测试： - static_delegate_user_revision_preserves_existing_clarification_round 名不副实， 它把 UserRevisionRequested 放在目标位置，而计数循环只遍历父节点集合，新分支 从未被执行。改名为 ..._parent_hop_preserves_depth_and_clarification_round，补 一跳真正以用户修订为父的续跑并加反证；原断言留作对照组并注明性质。 - 新增 concurrent_user_revision_dispatch_creates_exactly_one_delivery，父节点为 UserRevisionRequested 且 depth 已为 1，两侧同时钉住并发下恰好放行一条。 - user_revision_continuation_... 补兄弟检查断言（depth 门对用户修订失效后，它是 该路径上唯一剩下的扇出约束）。 变异测试：摘掉 counters 分支 4 条变红（含新增反证 left (2,0) / right (1,1)）； 摘掉 gate 分支 3 条变红（并发用例 left 0 / right 1）。两处守卫各自有回归覆盖。 验证：定向 41 passed / 0 failed；npm run check:encoding 通过（5374 files）； git diff --check 干净。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 05:17:39 +00:00
lhk229	8c4acaaad5	文档：记录 M1B-2 已合入原分支 ... 更新 Fast GDD 技术方案与 decision-log 的工作包状态和验收快照	2026-08-15 04:42:21 +00:00
lhk229	27c3eb847a	立项策划：完成 M1B-2 GDD 提交与恢复 ... 接入 plan.submit_gdd 原生工具及 exact planning Provider 绑定与结构化注入 实现 create-only GDD 提交点、索引 Markdown session 恢复与策划子 run 收口 补齐定向门禁与阶段文档记录，审批 receipt UI 和构建准入留待后续	2026-08-14 14:23:58 +00:00
lhk229	a17f725834	立项策划：合入 M1C-0 用户修订 lineage 分类 ... M1C-0 在隔离 worktree 上以 09c7d7af8（M1A-2 收口）为基线开发，缺 M1A-4、 M1A 残余收口、M1A-2 回归修复与 M1B-1 共六个提交，故走 merge 而非 fast-forward。 代码零冲突：本包改顶层 src-tauri/src/delegation.rs，M1A-4 改 src-tauri/src/agent/runtime_tools/delegation.rs，同名不同文件； tests/collaboration/static_deliveries.rs 两侧各自追加测试，自动合并。 两处文档状态句冲突，按「原分支事实优先」解决：保留 M1A-4 与 M1B-1 的已落地 事实，删去本包基线上「.agent/planning 存储仍未实现」「M1B-1 及之后仍未开始」 两句已被 M1B-1 推翻的表述；顺带把状态句和第 23.6 节第五行遗漏的 M1A-4 补回。 decision-log 的 M1C-0 条补一段合入说明，并订正其关联行里自指的 M1C-0 为 M1C-1。 合入后验证：cargo check --offline --all-targets 通过，npm run check:encoding 通过（5373 files），git diff --check 干净。定向测试与逐项复核另行跟进。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-14 07:10:02 +00:00
lhk229	ad3c460a28	文档：补齐 M1B-1 验收表提交状态 ... - 将 M1B-1 工作包表格同步为已提交于隔离分支 f453c2ca2。 - 保留待合回原分支及 M1B-2 后续边界。	2026-08-14 06:50:56 +00:00
lhk229	56e0a73ca4	文档：记录 M1B-1 隔离分支提交状态 ... - 将 M1B-1 的验收记录更新为已提交于隔离分支 f453c2ca2。 - 明确原分支仍待后续合回，保留 plan.submit_gdd 与审批闭环的后续边界。	2026-08-14 06:49:20 +00:00
lhk229	f453c2ca27	立项策划：落地 M1B-1 planning storage 与写入隔离 ... - 新增 plan GDD、index、session 与提交输入的 strict schema、canonical JSON 和 typed 指纹。 - 落地 GDD 连续版本链、index 权威对账与锁内 recovery、session CAS/原子替换/受限恢复。 - 封锁 planning sidecar 与 fast_gdd 投影的通用写入、patch、删除和 checkpoint restore，并校验专用 writer 身份。 - 同步 Fast GDD 技术方案、决策记录与排障记忆。	2026-08-14 06:47:14 +00:00
lhk229	323db581fa	修复 M1A-2 引入的回归：未知工具名不是身份违规 ... background_agent_runtime_persists_receipts_for_rejected_actions 在本分支 恒失败（3/3），master 通过。首个 tool-plan 请求能收到，动作被拒绝后第二次 Provider follow-up 不再发出，测试等待超时。不是已知的 mock-LLM 本机 flake。 根因是 M1A-2 给主循环加身份门时用了 agent_runtime_tool_allowed_for_agent， 而该函数对非 project-planning 的 Agent 退化成「这个工具名是否已知」。于是 普通 Agent 调用一个不存在的工具（模型编名字，常见协议错误）被判成身份违规， main_loop 直接 mark_needs_reconciliation 并返回 NeedsReconciliation，整个 run 中断。现役语义是未知工具产出一条 rejected observation、run 继续、由下 一轮 tool-plan 收束。 两类必须分开：身份禁止某个已知工具是安全边界，命中即硬拒；工具名根本不存在 是可恢复的协议错误，不得升级成中断整个 run。 新增 agent_runtime_tool_rejected_by_agent_identity，只在「该 Agent 带 exact allowlist 且工具不在其中」时为真。三个命中即中断或整体拒绝的调用点改用它： main_loop（本次回归直接原因）、provider_action_batch 的 identity_block（原会 把普通 Agent 的未知工具从 rejected 误判成 blocked）、runtime_tools/policy （原本就正确限定 planning，改为复用同一判据以免再次分叉）。parallel_ledger 内部批次资格判定不变，其下一行的 command_id 检查本就拦得住。 planning 侧约束未放松，两条单测分别钉死普通 Agent 与 planning 两侧。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-14 06:35:45 +00:00
lhk229	5fa662be30	立项策划：收口 M1A 复核残余，retry 强判据前置且身份哨兵改为编译期约束 ... retry 强判据必须排在全部分支之前。plan 分支原先排在 delegated 与 autonomous-game-build 之后，两支都能绕开 reject_supervisor_plan_root_retry_without_identity： 一是 plan source 配伪造 parent 会落 delegated 支，直接返回 agent-delegate-retry，强判据根本不执行。二是 binding.source 是 plan 配 autonomous profile 会落 autonomous 支，因 plan 在可信集合内而被原样取回， 复活启动路径 reject_supervisor_plan_autonomous_profile 明令禁止的组合。 两者都要 durable 状态先畸变才可达，但强判据存在的意义正是对畸变状态 fail closed。守卫提到函数开头无条件执行，合法 plan 根 run 对它恒真； plan 分支不再重复读 durable 状态。autonomous 支另加一次 reject_supervisor_plan_autonomous_profile，兜住顶部守卫按 task.source 判定所挡不住的那一种。回归已用变异测试确认去掉任一守卫即变红。 __all_agents__ 身份哨兵改为编译期约束。四个不带 agentId 的 wrapper 会以 哨兵跳过按身份的工具面收窄与原始工具 identity 复核，M1A-2 之后调用点只剩 测试，但将来新增生产调用点漏改是静默拿全量目录而非编译失败。四个 wrapper 与对应 re-export 一并加 cfg(test)。该哨兵已扩散到两个文件，是正在复制的 模式而非单点遗留。 订正 M1A-3 决策条里「agent-background-task 唯一构造点」的错误结论： task_start 与 recovery_scan 各还有一处同形状的空 source 兜底，且 recovery_scan 那条不经过 plan 根强判据。经复核有意不改，理由随条记录。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-14 05:20:18 +00:00
lhk229	c22b929080	立项策划：落地 M1A-4，plan 根 run 只能委派策划子 Agent ... 补 M1A-2 的反方向。原先只做了「目标是 project-planning 时要求父是 plan 根」，反过来「父是 plan 根时目标必须是 project-planning」没做， 也没记为 deferred。后果是 plan 根 run 可以委派任意专业 Agent，而被 委派者拿常规 standard 工具面（能写文件、跑命令），第 24 节「策划全程 零构建」当时只由 Prompt 兜底。 执行层：observe_agent_runtime_agent_delegate 补对称分支； observe_agent_runtime_agent_spawn_isolated 对 plan 根 run 一律拒——它是 第二条造子 Agent 的通道，只堵 delegate 等于留后门。两条共用 typed kind=plan-root-child-target-unsupported。 强弱判据分工与 M1A-3 一致：弱判据从 task journal 读 source 决定是否 管辖，强判据 validate_project_supervisor_plan_root_binding_at 决定是否 合法，其 Err 永远落进拒绝分支。不可写成 is_ok() 当作「不是 plan 根」， 那会在 binding 损坏时放行任意子 Agent 创建。 上下文层：plan source 下不拼 supervisorIntro 与 $visualContract。不改 .md 内容，不新增 composition key。 三条有意保留的取舍已冻结进 decision-log，非待办： $isolatedAgentTemplates 仍列出专业角色名（被执行层硬拒后的死文本， 上下文层收窄边界到此为止）；task journal 读取失败对所有 source fail closed（改成放行是新的 fail-open）；plan 根 prompt 断言偏弱 （执行层是该场景唯一保障）。 同步方案 §22 证据表、§23.8 PR 表、§24 不变量，并订正 M1A-2 决策条里 含糊的「Supervisor 根 run 继续使用现役工具面」。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-14 05:02:46 +00:00
lhk229	7db5118e27	立项策划：落地 M1C-0 用户修订 lineage 分类 ... 新增 UserRevisionRequested durable 状态并保持未知状态 serde fail-closed 区分用户修订、澄清 continuation 与质量返工的 lineage 计数及深度门 补充连续修订、真实 agent.delegate、32-hop 和历史兼容回归 同步 Fast GDD、Runtime 文档与 M1C-0 决策记录	2026-08-14 04:02:53 +00:00
lhk229	09c7d7af8d	立项策划：收口 M1A-2 工具面与角色提示 ... 收紧 planning 子 Agent 原生工具目录与 MCP/web search 边界 增加静态委派父根身份与 fail-closed 执行校验 补齐 planning Prompt Bundle、final-reply 终态约束与解析层拒绝 保留项目权限 deny/confirm 并同步恢复归一化策略 同步技术方案与项目决策记录	2026-08-14 02:58:18 +00:00
lhk229	84f6e6ec20	合入原分支最新改动	2026-08-13 14:16:25 +00:00
lhk229	17f7152f70	立项策划：落地 M1A-3，plan 根 run retry 保源且身份失败不降级 ... 新增 plan 根 run 强判据，核 durable binding 而非只看内存 source retry 在 generic 兜底前保留 project-supervisor-plan 身份校验失败返回 plan-root-retry-identity-unsupported gui 与 delegate 对照回归保持现役兜底 同步 Fast GDD 方案、decision-log 与 pitfalls	2026-08-13 14:11:34 +00:00
lhk229	fa42d4e490	文档：订正 M1A-1 的 retry 复核结论，plan 根 run 保源单列为 M1A-3 ... M1A-1 把 resolve_game_creator_agent_runtime_retry_configuration_at 判成 「已被 profile 挡住、本包不改函数」。该结论只对了一半：它确实不会让 plan 误得 autonomous 语义，但复核模板只问了「plan 进 matcher 后会不会误得不该 有的语义」，没问「plan 落到通用兜底后会不会丢掉该有的语义」。这个调用点 既是判据也是 run 构造器，两个方向都要问。 缺陷：plan 根 run 是 standard + 顶层无 parent，两个特例分支都不命中，落 agent-background-task 兜底。run_profile 由 agent_runtime_run_profile_identity_at 原样返回，实际只丢 source——第 22 节证据表原写「保留 source/profile」会 误导实现者去修一个没坏的东西，一并订正。 降级无声：retry 走 start_game_creator_agent_background_task_with_link_in_ session_lane_at，该路径对 source 无门禁；validate_agent_runtime_run_profile_ binding_record 也只在 autonomous-game-build 档要求可信 source。于是造出一个 正规启动路径造不出来的状态。 后果分两类。放行类：reject_supervisor_plan_root_steer 只认精确 source， 重试后不再命中，steer 重新放开，违反第 4.1 / 23.1 节裁决。死路类： root_control_authority 转 false 后广告层删掉 agent.goal_contract 与 agent.acceptance_update，validate_goal_contract_record 也拒绝建约，重试后 的根 run 建不出 Goal Contract，第 13.0 节审批前置门的取证永远收敛不了。 agent.delegate 不受该权限影响、委派照发，所以故障要到审批那一步才暴露。 处置：不回改已合入的 M1A-1，第 23.8 节新列 M1A-3，一并交付第 4.1 节要求的 强判据函数与 generic fallback 前的 exact plan root 分支；M1C-2a 依赖随之改为 M1C-1、M1A-3。修法边界写死：gui/cli 根 run 的现役降级行为不在范围，只能在 兜底之前插分支、不得改兜底默认值。 decision-log 原条目对应半句加删除线并挂指针，避免后续 PR 沿用旧结论。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 13:50:24 +00:00
lhk229	65f471210f	立项策划：落地 M1A-1，plan source 进可信 matcher 且 steer 独立否决 ... 新增 project-supervisor-plan 常量并加入可信 matcher 启动路径拒绝 plan 与 autonomous-game-build 的组合 steer 用独立于 matcher 的显式否决 补消费点复核与定向回归 同步 Fast GDD 方案、decision-log 与 pitfalls	2026-08-13 13:22:37 +00:00
lhk229	91888bfd9e	文档：传导拆包与广告层更正，修四处自相矛盾 ... 均为上一轮拆包与第 19 节改写后未传导到位所致。 第 23.7 节：原写「变体、判据、receipt 写入必须同一个 PR」，与第 23.8 节 拆出 M1C-0 矛盾。改为判据在 M1C-0（惰性、无写入方、行为零变化）， 写入方与 receipt 在 M1C-1 同进同退；这样拆全程不产生半状态。 第 24 节第 8 条：不变量摘要仍写「广告层仍可见」，而第 19 节第 2 条已改为 目标态两层都拒。第 24 节是终态合同，留旧目标态会把 M1A-2 带偏。 第 23.8 节：审批前置门的门禁原挂在 M1C-1，但取证顺序是协议时序问题， 归 M1C-2a；M1C-1 只做 receipt。门禁随之对调。 第 12 节：原写 submit 分支「随后把顶层 run 投影为 waiting-for-user-input」， 与第 13.0 节冲突。这是 D9/D10 单 run 拓扑残留——D11 下调用 submit 的是 策划子 run，提交完即终态结束；审批等待属 Supervisor 根 run 且必须等 取证通过后才创建。提交分支现只负责校验、定版、写 GDD、追加 index、渲染。 第 4.3 节与 D10 作废条目的「广告层仍放行」保留但标注为 M1A-2 之前的现状。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 12:46:50 +00:00
lhk229	9605f31440	文档：对齐 M1 开工前的四处口径，并把 PR 结构冻结进方案 ... 第 19 节第 2 条改写：原文要求回归钉死「执行层拒绝」与「广告层仍放行」 两半，与第 4.3 节「allowlist 的作用是让它在广告层就消失」直接冲突， 且两节互相引用却结论相反。更正为：那段描述的是 M1 之前的现状不是目标态； 目标态两层都拒，回归第二半从「仍放行」翻为「不再出现」，纵深防御纪律保留。 第 23.8 节新增 M1 的 PR 结构与合入门禁：11 个 PR、依赖顺序与各自门禁。 PR 划分属工程流程契约，须团队可见——PR 描述不得引用个人工作稿， 原第 23.6 步骤五只有一句「未开始」，并行开工时无可引用的 DAG。 其中 M1C-0 与 M1C-1 拆开，因两者风险类别不同：前者改 master 已发布的 静态委派机制，后者是新增功能；合并会让「做游戏返工额度未被误放宽」 这条关键回归淹没在审批闭环 diff 里。M1C-2 拆 a/b，因失败模式无关。 第 23.6 步骤三订正：身份登记的代码已于 2026-08-13 合入， 原文仍写「代码落地属 M1」，进度过期。 第 23.1 订正：steer 资格判据在 goal_contract_root_steer_task_at (steering.rs:747，判据 763 行)，原文误记为同文件 714 行的 goal_contract_root_steer_replacement_run_id——行号对但函数名错。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 12:38:58 +00:00
lhk229	10af1fc377	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-13 12:17:26 +00:00
lhk229	eebe511a25	文档：裁决 Supervisor 自行提问维持 Prompt 兜底，不做成机制约束 ... 第 23.6 节待执行项中该条关闭。理由：本链路上 Supervisor 是自家 Prompt 驱动的受控角色而非外部输入，失效后果（问题被改写、答案转述失真）属产出 质量问题，由用户在审批卡上兜底，不是安全边界被突破；为它单独接一道 等价校验的成本落在 standard 全链路，与收益不成比例。 同时写明本裁决的纪律：第 4.3 与 5.2 节现有的如实记录必须原样保留， 不得因已裁决就改写成「已保证」——它记的是事实（standard 下 static_delegate_clarification_pending_matches_delivery_at 不触发）， 事实没变；M1 回归也不得断言「Supervisor 无法自行提问」。 并记录重新裁决的触发条件：若未来允许非自家 Prompt 驱动的 Supervisor。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 12:16:26 +00:00
lhk229	8a349c633e	文档：补审批前置门与用户修订不计返工两处空白 ... 第 13.0 节（新增）审批前置门：原文只规定「取证必须在 GDD 落盘之后」， 未规定相对用户审批的先后，第 13.3 节投影顺序里也没有验收图。 反序会产生无回退路径的死角——用户已批、receipt 不可回滚、根 run 却因 验收图未收敛完不成，GDD 状态是 approved 但流程卡死。 固定为：取证通过才允许暴露审批卡；未通过则不建审批卡，改发返工委派。 并列出三道门各自的失败路径：schema 不过不分配版本号、验收不过走返工 不惊动用户、用户不满意走修订。第 1.1 与 23.1 节的第 3 条约束同步补全。 第 23.7 节（新增）用户修订不计入 repair_depth：给 StaticDelegateContractStatus 增加第四个变体 UserRevisionRequested。 repair_depth 防的是 runaway agent，而用户点修改每轮都由人触发、 人本身就是循环边界，两者不应共用计数。本裁决不推翻 WP1 的 depth<=1，也不需要按 source 分流——做游戏链路不会出现该变体。 如实记录「无限修订」兑现不了：链上推断有 32 跳硬上限、版本链 128 上限， 产品阈值定 16 次软提示。反序列化须 fail closed，不得降级为 NeedsRepair。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 12:06:39 +00:00
lhk229	fa86b23248	文档：M0A-3 四之余收口，schema 与 golden vector 按 D11 重算 ... 第 5.2 节后半整段重写：决策卡改由 AGC_NEEDS_USER_INPUT_V1 终态信封承载， 线性化点由 session CAS 改为答案绑回 delivery，删除 Runtime 直投状态机。 第 8.3/8.4/8.6/12 节 identity 块补 agentId/rootAgentId/rootRunId/delegationId； source 按层区分：提交侧 agent-delegate，审批侧 project-supervisor-plan。 第 8.6 节删除 activeQuestion、roundsUsed 与 supersededCheckpointHandoffs， appliedAnswers 收窄并改挂 delegationId/continuationDelegationId。 第 9 节删除 checkpoint domain 与 supersededCheckpointProviderRequestIds。 第 9.1 节 golden vector 由代码重新生成：3857 bytes、a59856de7e…； 生成前先用旧 3707 bytes 重算得到旧值 d85c85dae3…，证明方法本身成立。 第 12 节重写消费证明三项与 stale 状态机，删除 checkpoint 整段。 第 14 节删除十行 checkpoint/activeQuestion 恢复语义，另立四行 D11 语义， 并把随之丢失的通用 handoff 安全边界单列一行保留。 第 6 节 Prompt 权威稿改为策划子 Agent 角色 brief 基线，提问改终态信封。 第 18.3 节 hydrate read model 改为 clarificationRound/repairDepth/awaitingAnswerFor。 第 21 节补六类 D11 必测项，含交替链与转述保真。 第 23.4/23.6 节状态更新：M0A-3 收口，M0 全部完成。 订正此前判断：四之余并非必须等 M1 strict schema。字段声明顺序本就由 第 8.3 节冻结、canonical bytes 本就在第 9.1 节，改字段等于改字节再重算。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 10:49:02 +00:00
lhk229	89b7a65171	文档：清除第 3.1 节一处行尾空白 ... Repository checks 的 git diff --check 门禁失败：文档第 260 行是一条只含两个空格 的空行。改为真正的空行。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 08:54:00 +00:00
lhk229	e5bc593afc	文档：更新 M1 计划中已过时的内容 ... 第 22 节「当前代码证据与 M1 接入点」逐行核过，改九处： - trusted source / matcher 消费者：plan source 进 matcher 已裁决，硬门解除； 但落地前须逐点复核 19 处消费点，steer 门须实现为独立于该 matcher 的显式拒绝 - Prompt Bundle：supervisorPlanChat / SupervisorPlanChat 随 D6 作废，不新增 composition 也不新增编译期 source kind；实际改动是 agentCatalog 新增 planning 平级条目，已落地 - Prompt 请求/收尾：D11 下不按 source 分流 composition - Supervisor collaboration：原「plan 跳过强制委派」方向反转，Supervisor 的主动作 就是委派 - user.input_request / decision checkpoint：后半段的 checkpoint turn 与 handoff 随 D10 作废 - completion blocker：收窄为只对策划子 Agent 不适用，根 run 不再整体豁免 - standard 路径 owner 产物验证：范围收窄，存在性证据已被静态委派 expectedArtifacts 覆盖，缺的是语义级校验，且内容正确性本就归 plan.submit_gdd 的 strict schema - Goal Contract：M1 待裁决项已全部关闭 新增一行记录已落地的 project-planning 身份登记。 第 21 节测试矩阵挂作废横幅：schema / session / Provider binding 三行中涉及 decision checkpoint、activeQuestion、checkpoint handoff、superseded 数组的必测项 随 D10 作废，不再是 M1 的测试义务；并列出 D11 新增的五项必测。 第 23.4 节同步：M1 入口前置决策已归零。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 08:49:41 +00:00
lhk229	fd61486525	Merge remote-tracking branch 'web/master' into feat/five_min_design ... 冲突两处，均为两侧独立新增： - provider_tool_plan.rs：本分支的 force_autonomous_owner_artifact_delivery 与 master 的 force_root_goal_contract 是各自独立的 let 绑定，两者都保留。 - provider_request_builders.rs：本分支新增测试 full_dag_pre_code_owner_requests_do_not_advertise_manual_verification， master 把紧随其后的 trusted_root_supervisor_receives_dynamic_goal_control_tools 改名为 trusted_root_supervisor_first_turn_only_receives_goal_contract_tool。 保留本分支新增的测试，共享的那个测试采用 master 的新名（其函数体已随 master 自动合并）。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 08:28:21 +00:00
lhk229	680bb200a8	文档：checkpoint handoff 私有持久化随 D10 作废，M1 入口前置决策归零 ... 该待裁决项待的是 plan-decision-checkpoint 专用请求 kind 的 handoff 契约，而该 kind 是 D10「Runtime 直投」的组成部分。D11 下策划子 Agent 以终态信封退出来提问、 run 随即结束，解释与下一步由 continuation 子 Agent 的第一个普通 tool-plan turn 完成，专用 kind 不存在，其专用 handoff 也不需要。 两条核实依据：现役 tool_plan_handoff::lookup_at 按 (agentId, runId) 寻址、与 agent 身份无关，已覆盖任何 Agent 的普通 tool-plan 响应；第 8.6 节预留的 supersededCheckpointHandoffs 全仓库零代码引用，作废无迁移成本。 通用 handoff 安全边界不受影响，策划链路照用现役机制。 M1 入口前置决策至此归零，剩余全部为待执行项。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 08:22:42 +00:00
lhk229	ff9c2f8242	文档：裁决 plan source 进可信 matcher，验收图取自固定 Fast GDD 合格标准 ... 裁决一：project-supervisor-plan 进 agent_runtime_supervisor_source_is_trusted， 做方案链路正常参与 Goal Contract 协议。原阻塞理由（策划 Agent 无证据工具、 必然留下永不 passed 的节点）写于 D6/D9 拓扑，D11 拆两层后失效：策划子 Agent 的 allowlist 含 file.read/file.list，且 validate_acceptance_evidence_identity_at 只要求 证据属于同一根任务树、不要求是根 Agent 自己的回执。原「依赖 plan source 可信身份 的 M1 代码不得合入」硬门解除。落地前须逐点复核该 matcher 约 19 处消费点。 裁决二：验收图取自固定的 Fast GDD 合格标准，不由 Supervisor 每轮自由发挥。 GDD 是否合格与它描述的是什么游戏无关，因此「验收标准须在产物不存在的 turn 1 冻结且不可改」不构成矛盾。plan.submit_gdd 的 strict schema 承担字段与约束硬校验； Goal Contract 验收图承担「产物确实服务了本次意图」。Goal Contract 中按项目变化的 只有 outcome/nonNegotiables/forbiddenAssumptions/openQuestions 四项。 不改变 D1（支柱 2～4 条按项目生成）与 D8（不含引擎字段）已冻结的口径。 同批更正第 4.3 节一处失真：此前称「Supervisor 不得自行提问」靠机制保证，实为 不成立——该校验唯一生产调用点外层套着 run_profile == autonomous-game-build， 做方案链路跑 standard，不触发。改为如实记录为产品约束、缺机制兜底。 M1 入口前置决策至此剩 checkpoint handoff 私有持久化一项。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 08:16:55 +00:00
lhk229	4d0f3e358c	文档：裁决 plan 根 run 不允许 steer ... 理由不是交互未验证，而是确定性的能力损失：D11 把问询轮次预算挂在委派链上， clarification_round 沿 repair_of_delegation_id 上溯且每跳强制 parent_run_id 等于 当前根 run；steer 换根后旧链 continuation 会被跨 run 隔离判据拒绝，该策划链路 剩余轮次全部作废、已回答内容无法续接。 实现约束：steering.rs:763 的资格判据 agent_runtime_supervisor_source_is_trusted 同时是 Goal Contract 创建权限的判据，因此不得靠「不把 project-supervisor-plan 加进该 matcher」来实现本裁决，必须是独立于可信 source 判定的显式否决，回归须 覆盖该 source 在/不在 matcher 内两种情形。 M1 入口前置决策至此剩两项。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 07:32:26 +00:00
lhk229	ba04293204	登记立项策划子 Agent 身份，并堵住登记带来的三处静默错分 ... D11 要求策划 Agent 由 Supervisor 通过 agent.delegate 静态委派，因此它必须是 agentCatalog 合法成员。登记方式照 agentCatalog.supervisor：与 supervisor 平级、 不进 groups——build.rs 的 validate_seed_task_catalog 只比对 groups[].roles[] 派生的 specialist_nodes，因此种子 DAG、new_game_creation_app_seed_tasks() 与 build.rs 三者一行不动，「做游戏链路不动」得以成立。 编译期：manifest.json 新增 planning 条目；AgentCatalog 加字段、validate_agent_catalog 纳入校验、render_agent_catalog 生成 PROJECT_PLANNING_* 静态。 运行时修复的是「非 supervisor 即专业组成员」这个二分假设的四个受害点： - prompt.rs 的 game_creator_agent_role_definition 返回 None，而两个调用方都用 .ok_or_else(...)? 转成硬错误——委派第一轮构建 Provider 上下文即中断（blocking） - pass_artifacts.rs 的内存路径解析报「未知 Agent 任务」 - task_start.rs 的 agent 枚举漏收，重启/steer/兜底对账后委派变孤儿任务 - task_ops.rs 的 task.create 在无 group 参数时静默兜底成 Design 组，污染任务审计。 此处只对 project-planning 要求显式传 group，不动 project-supervisor 同样吃这个 兜底的现役行为。 另排除 project-planning 出 agent.spawn_isolated 的合法模板集：它一旦进 catalog 就 天然满足「非 child- 前缀、非 Supervisor 本体」的放行条件，会让任何持该工具的 Agent 都能动态孵生它，属登记带来的隐性扩权。 新增 project_planning_is_a_delegatable_identity_outside_the_seed_dag 钉住四点，其中 「不在任何专业组且不在种子 DAG」直接断言 new_game_creation_app_seed_tasks()。 runtime_adapter 既有 catalog 目录测试同步更新期望集合。 本包只让身份跑通。exact allowlist 工具面、plan.submit_gdd 与 brief 正文属后续块。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 06:53:06 +00:00
lhk229	0eca4c215f	文档：M0A-3 批二拓扑与工具面部分按 D11 重写 ... 已完成部分： - 第 3 节注册表：策划子 Agent durable source 由 agent-ready-task-scheduler 改为 agent-delegate；删除随 D10 作废的 plan.request_decision；Prompt composition 由 冻结值 projectPlanning 改为「不新增、复用现役」，消解与第 3.1 节的自相矛盾； run profile 成立理由改为委派父子继承；新增问询载体行。 - 第 4 节拓扑图重画为 D11 的委派 + #165 中转链路。 - 第 4.1 节整节重写为「Supervisor 根 run + 策划子 run」两层身份，并给出 「同一条策划链路」必须沿 delegation 链判定、不能只看 agentId 的理由。 - 第 4.2 节整节重写，supervisorPlanChat / SupervisorPlanChat 一并作废。 - 第 4.3 节整节按两层工具面重写。此处修正了一个方向性冲突：原文「明确禁止 agent.delegate」「跳过 collaboration 强制委派」，而 D11 下 Supervisor 在做方案 链路的主动作恰恰就是委派。 - 第 5.1 节对话循环四条按 D11 重写：问题落 delivery 而非 activeQuestion，线性化点 是答案绑定而非新 session primary，解释与下一步由 continuation 子 Agent 的第一个 普通 turn 完成，plan-decision-checkpoint 请求 kind 不再需要。 - 第 18.1 节前端入口 source、第 22 节 Prompt 行更正。 未完成部分（第 5.2 节后半与第 8.3～8.6 / 9.1 / 12 / 13 / 14 节）：这些与 golden vector 强耦合，改 schema 必须同步重算第 9.1 节 typed 指纹，而指纹必须由代码生成、 不得手写，M1 strict schema 尚未实现。逐段修补会产生「schema 已改、vector 未换」的 中间态，比暂时保留旧文更危险。已加作废横幅说明其只作为 D10 时代历史记录、不得作为 实现依据，并在第 23.6 节把它拆成独立的「四之余」步骤登记。 仅文档改动，无任何代码变更。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 05:58:12 +00:00
lhk229	62fc86e7db	文档：D11 条目同步 WP1 已落地，旧上限改为改造前对照 ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 05:44:12 +00:00
lhk229	8c4b64c259	文档：执行计划入档，并修正 WP1/WP2 已完成后的过时陈述 ... 新增第 23.5 节记录 WP1/WP2（静态委派澄清轮次与返工深度拆分）的问题陈述、 定稿语义、门禁与完成状态；新增第 23.6 节记录五步执行计划、M1 开工前必须 处置的两类事项，以及四项明确后置、不阻塞任何一步的工作。 修正两处已过时的表述：文首状态行与第 1.1 节第 5 条在 WP1/WP2 已合入本分支后， 仍写着「WP1 落地前问询上限仍是 1 轮」「正在另一个 worktree 并行实现」。 第 1.1 节另补记批一执行状态，M0A-3 的剩余工作只有批二。 此前会话中一度使用过的 WP0/WP3/WP4/WP5 编号从未落进仓库，本次不引入， 其余内容按性质归入第 23.6 节的两类清单，避免出现两套不一致的工作包编号。 仅文档改动，无任何代码变更。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 05:20:09 +00:00
lhk229	146b7a215f	文档：对抗性复核修正 project-planning 登记机制记录 ... 复核结论：build.rs/specialist_nodes/validate_agent_catalog 等核心机制主张 逐行核对代码原文，全部准确（含所有 file:line 引用）。修正两处问题： 1. decision-log.md 声称 provider_request_builders.rs:536-539 与 prompt.rs:416-417 报同一错误字符串「未知 Agent 模板：project-planning」， 逐行核对后两处错误文案实际不同（后者是「未知 Agent：project-planning」， 没有「模板」二字）。已改为分别引用真实文案。 2. 独立扫描 GAME_CREATOR_AGENT_GROUP_DEFINITIONS 遍历模式，发现一个 R1 调研遗漏的 needs_change：task_start.rs 的 collect_game_creator_agent_runtime_agent_ids 与 game_creator_agent_role_definition 是同构的二分硬编码，是核心恢复驱动 read_game_creator_agent_runtimes_at 与三处安全网（崩溃恢复扫描、steer 级联取消、委派回执兜底对账）的枚举来源，project-planning 登记后不会 被这三处发现。已追踪 agent.delegate 派发路径确认委派首轮任务同步起跑、 不受影响，故定级 needs_change 而非 blocking。同时补记 runtime_adapter.rs 里断言 catalog 精确集合的既有测试需要同步更新。 git diff 核对确认本轮及此前一轮均未改动任何 .rs 或 manifest.json。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 05:08:25 +00:00
lhk229	d3d0ae95e5	文档：定稿 project-planning 的 agentCatalog 登记机制（与 supervisor 平级、不进 groups） ... 在技术方案第 3 节新增 3.1 小节：project-planning 登记为 agentCatalog 下与 supervisor 平级、不属于任何 group 的独立条目，使 specialist_nodes（只读 groups[].roles[]）、build.rs 的 validate_seed_task_catalog 与 16 任务种子 DAG 均不需要改动；给出 descriptor 元数据取值（groupId 自引用、不设 groupLabel、toolId 走 agent.runtime.* 命名族、capabilityAuthority 沿用 现有常量）与编译链路要改的确切位置清单。同时如实记录调研发现的新缺口： 仅做 catalog 登记不足以让 D11 静态委派可执行——prompt.rs 的 game_creator_agent_role_definition 硬编码「非 supervisor 即 group 角色」 二分，需 M1 补一个平行分支；另有 task_ops.rs 误分类兜底、 delegation.rs 的 agent.spawn_isolated 放行面扩权两处 needs_change。 同步更新第 23.1 节待裁决项（登记方式已定稿，代码留给 M1，真正的前置 是 prompt.rs 角色身份合成缺口）、第 1.1/2 节里因此过时的「待裁决」措辞 （避免与新结论自相矛盾），并在 decision-log.md 顶部补记本次定稿与 「做游戏链路一行不动」的机制依据。本轮仅涉及文档，不改任何 manifest.json 或 .rs 源码，注册代码留给 M1。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 04:56:13 +00:00
lhk229	d09307fd64	Merge branch 'feat/clarification-round-split' into feat/five_min_design	2026-08-13 04:26:39 +00:00
lhk229	13ee128114	测试：钉死静态委派返工深度与澄清轮次的链上推断语义 ... 反转 clarification_continuation_chain_supports_multiple_rounds 的第 3 轮断言： D2 -> D3 从"必须被拒绝"改为"必须成功"，并断言 D3 的澄清轮次推导为 2——这是 WP1 把返工深度与澄清轮次拆成两个独立链上推断维度后的有意行为变更，不是回归。 新增 7 条用例，全部走真实 observe_agent_runtime_agent_delegate 生产路径： - 澄清轮次上限边界（第 4 轮必须被拒绝，且文案是澄清轮次专用文案，不串扰返工深度门） - 交替链钉子测试：返工(depth=1) -> 澄清(depth 仍为 1, round=1) -> 再返工必须被拒绝， 同时证伪"R1 误清零 depth"和"R2 漏加 1"两种失误 - 返工重置澄清轮次预算，重置后 3 轮澄清全部放行 - 验证澄清 continuation 校验器（要求携带匹配的澄清字段）本身就保证了同一原始 delivery 不存在"既澄清又质量返工"的可达状态，并证明澄清跳不会连带占用它 产出的下一节点自己的返工配额 - 历史记录分类：手工构造 #165 之前风格的旧 delivery，验证链上推断把它正确 分类为非澄清、返工正确计入深度 - 跨 run 隔离：换 parent_run_id 引用旧链节点的返工请求必须被拒绝 - source 区分：game-chat source 下澄清上限为 1，非 game-chat 上限为 3 delegation.rs 仅放宽三个既有私有函数（static_delegate_lineage_counters / list_static_delegate_deliveries_at / write_static_delegate_delivery_at）为 pub(crate)，供测试直接断言链上推导出的 (depth, round) 数值；不改变任何行为、 不新增持久字段。 回归防线复核：project_supervisor_static_delegate_repair_is_single_bounded_wave （含"返工的返工必须被拒绝"）、project_supervisor_concurrent_repair_dispatch_ creates_exactly_one_delivery、claimed_needs_user_input_delivery_becomes_one_ supervisor_wait 及其邻近用例均保持通过。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 04:14:19 +00:00
lhk229	2f3dd86fb3	静态委派：返工深度与澄清轮次改为链上推断，不新增持久字段 ... WP1（本轮只改生产代码，测试由下一工作包处理）： - 新增 static_delegate_lineage_counters：沿 repair_of_delegation_id 反向重放整条 delivery 链，现算目标节点的 (repair_depth, clarification_round)。二者都是运行时 派生值，故意不落盘——若给 StaticDelegateDeliveryRecord 加 repair_depth 字段并用 #[serde(default)] 兜底，磁盘上已有的返工记录会读出 0，深度门失效，等于让 “返工的返工”漏洞原样复活（fail-open，不可接受）。链上推断对历史记录反而是精确 的：#165 之前不存在 NeedsUserInput，老记录天然被正确分类为“非澄清”。 传播规则：R3 根节点 depth=0/round=0；R1 澄清跳 round=parent.round+1、depth 不变 （不重置深度，否则可插一次澄清洗掉返工深度变成无限返工）；R2 返工跳 depth=parent.depth+1、round 重置为 0（返工后重新开工，不能吃掉澄清轮次预算）。 反向重放遇到重复 id、缺失节点或跳数超过 STATIC_DELEGATE_LINEAGE_MAX_HOPS 时 fail closed，返回 (u32::MAX, u32::MAX) 使调用方的门必然拒绝。 - 抽出 static_delegate_original_is_awaiting_clarification 作为“这一跳是否续接自 澄清”的唯一权威判据源，validate_static_delegate_repair_request_at 与 validate_static_delegate_clarification_continuation_at 共用，避免两处口径漂移。 - 重写 validate_static_delegate_repair_request_at 里原先无差别拒绝返工深度>=1 的 门：先用共享判据分类候选是澄清续接还是质量返工；返工路径按链上 depth 校验， 错误文案原样保留“静态委派返工深度最多为 1”（现有测试已断言该字符串）；澄清 路径改为按链上 round 校验，用新文案“静态委派澄清轮次已达上限”。函数签名不变。 - 澄清轮次上限按 source 区分：新增 static_delegate_clarification_round_limit_at， 通过 read_game_creator_agent_runtime_run_profile_binding 读取 binding.source， AGENT_RUNTIME_SUPERVISOR_GAME_CHAT_SOURCE 取 1，其余取 3——game-chat 单主路径 定位零打扰，#165 从未承诺给它 3 轮预算。 验证：cargo check --all-targets 通过。cargo test 里 tests::collaboration::static_deliveries::clarification_continuation_chain_supports_multiple_rounds 按预期失败——它断言的是旧的“D2->D3 必被返工深度门拒绝”行为，新逻辑下 D2->D3 是 合法的第 2 轮澄清续接，测试留给下一工作包更新。project_supervisor_concurrent_repair_dispatch_creates_exactly_one_delivery 偶发失败，经对比 20 次 vs 20 次基线（约 10%-15% 失败率两边相当）确认是本机既有的 并发计时 flaky 测试，非本次改动引入的回归。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 03:38:17 +00:00
lhk229	0ca52d85f0	文档：补记 D11 新拓扑与静态委派澄清轮次/返工深度拆分（WP1）决策 ... 新增 2026-08-13 决策记录条目： - D9 二次作废、D10 作废，立项策划改为 Project Supervisor 静态委派子 Agent（D11），复用 PR #165 澄清中转链路，命名裁决冻结（agentId=project-planning，source=project-supervisor-plan）。 - WP1：clarification_round 与 repair_depth 两个运行时派生维度拆分定稿——分类判据、传播规则（澄清跳不重置 depth、返工跳重置 round）、上限按 source 区分（game-chat 取 1，其余取 3）、总跳数上界 1+(1+1)x3=7 跳/8 条 delivery 记录的推导（并说明常见漏算为 6 的原因）、以及不得新增持久字段（fail-open 风险）与最脆弱回归点（返工跳漏掉 depth+1）。 - 推翻 2026-08-12"子 Agent 澄清回执由 Supervisor 中转（Issue #163）"条中"随后最多创建一次 continuation"的结论。 - 记录新增待裁决项：project-planning 的编译期 agentCatalog 登记方式与 build.rs 一致性校验。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 03:32:04 +00:00
lhk229	8d701e750c	文档：D9 二次作废、D10 作废，立项策划改为 Supervisor 静态委派子 Agent（D11） ... - 第 2 节决定表：D9 标注二次作废（保留原文，说明哪些结论被 D11 继承、哪些被推翻）；D10 一并作废（其存在前提"ready-task 节点无 parent、Runtime 拦不住"在新拓扑下不成立）；新增 D11，表头改为 D1～D11。 - 第 1.1 节新增"D11 新拓扑"小节：立项策划节点改为 Project Supervisor 通过 agent.delegate 发起的静态委派子 Agent（agentId=project-planning），问询复用 PR #165 中转链路；列出六条已验证支撑事实（均带 file:line），并注明 D11 依赖 WP1（澄清轮次/返工深度拆分）为强制前置。同步标注旧"新拓扑（替代 D6）"小节已被取代，更新"分两批执行"：命名裁决已完成，批二改由 build.rs agentCatalog 一致性裁决阻塞。 - 第 19 节第 2 条、第 24 节第 8 条：改写为"执行层由 Runtime 兜底拒绝、广告层仍可见"的准确表述，替换失效的"排除是产品自律"旧表述。 - 第 4.3 节：修正与第 19 节第 2 条矛盾的 plan source 四工具清单（其中列着 user.input_request）。 - 第 23.1 节：策划节点命名裁决标记已冻结；新增 project-planning 的 build.rs 一致性待裁决项；plan run steer 待裁决项按 D11 拓扑更新。 - 文首状态行、第 1 节开篇段同步更新为 D11 现状。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 03:31:49 +00:00
lhk229	c0d1890b49	Merge remote-tracking branch 'web/master' into feat/five_min_design ... 冲突解法： - 实施计划.md：master 改 Provider 故障展示、本分支改跨轮阶段记录，各取各自较新的一条 - decision-log.md：两侧新增条目不重叠（master 2 条 / 本分支 7 条），全部保留 - agentPresentation.ts、agentRuntimeModel.test.ts：import 取并集 - project-development.suite.ts：保留 master 新增用例，用例标题用本分支 M0B-2 改后的语义 - SupervisorChatOnlyView.tsx：合成两侧。isAgentRuntimeTerminalState 本身已含 needs-reconciliation，master 单独那两行对其自身是冗余的；但本分支的 `|| descendantsStillActive` 会让 needs-reconciliation 的 run 因子 Agent 未收束 而重新判为运行中，正好绕过 master 这次要立的规矩。故保留本分支的 lineage 口径 （projectedRuntime）并补显式 needs-reconciliation 短路。 验证：前端 typecheck 干净；appSurface.test.ts 377 passed；agentRuntimeModel 27 passed； cargo check --all-targets 通过；static delegate 定向 9 passed；clarification 定向 4 passed。 response_stream / runtime_state 有失败，经对照确认不是回归：在纯 web/master 的独立 worktree 上跑同一批为 10 failed，本分支为 6 failed 且是其真子集，两次运行成员还不同。 失败模式统一为 Windows 下 .agent/agent.db 被占用（Os code 32），属本机既有基线。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 03:01:56 +00:00
lhk229	7754a2f820	测试：实证静态委派澄清 continuation 只能走一跳 ... 新增 clarification_continuation_chain_supports_multiple_rounds，走真实 observe_agent_runtime_agent_delegate 生产路径验证 #165 澄清中转的链长边界： - D1 -> D2 第一跳成功，D2 落盘且 repair_of_delegation_id == Some(D1) - D2 -> D3 第二跳被 delegation.rs:1119 的「静态委派返工深度最多为 1」拒绝 - D3 从未落盘 澄清 continuation 与质量返工共用 repair_of_delegation_id 字段和同一道深度门， 因此一次澄清会同时耗尽该链路唯一一次质量返工额度。本用例把当前行为钉死， 作为后续拆分两个维度时的对照基线。 仅新增测试，未改动任何生产代码。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 02:27:06 +00:00
lhk229	93d8d0c1cf	Merge remote-tracking branch 'web/master' into feat/five_min_design ... # Conflicts: # apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/provider_request_builders.rs # apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/main_loop_tests.rs # docs/project-memory/shared-memory/decision-log.md # docs/project-memory/shared-memory/pitfalls.md	2026-08-12 12:38:03 +00:00
lhk229	331441534d	文档：冻结策划节点身份常量并更正提问权限判据 ... 裁定策划节点 agentId 为 project-planning、Supervisor 做方案入口 source 为 project-supervisor-plan（旧预留值 project-supervisor-plan-chat 作废， 避免字面未变而语义已改导致接错代码路径）。据此更新第 3 节注册表与第 4 节 拓扑图。 更正一处此前判断错误：standard 的 ready-task 调度器 start_game_creator_agent_background_task_with_source_at 向 _with_link_at 传 task_link = None，节点无 parent，source 也不在黑名单，因此 validate_user_input_action_owner 会放行它调用 user.input_request。 只有 autonomous 那个调度器才显式写 parent。所以策划节点不得直接提问是 产品约束的自律要求（否则问答会落进它自己的会话、Supervisor 上下文里 没有内容），必须由 exact allowlist 主动排除并以回归钉死，不能指望 Runtime 兜底。第 1.1 节、D10 与第 19 节第 2 条同步更正。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 12:29:16 +00:00
lhk229	6119060dc0	文档：作废 D6，立项策划改为 Supervisor 下游工作流节点 ... 产品侧确定「做方案」入口独立成链后复核代码，D6 的前提逐条不成立： autonomous-game-build 对 user.input_request 的禁令按 run profile 生效、 父子皆不可提问；硬闯会把 runtime.status 写成 failed，而根活跃判定不认 failed，导致整条 16 节点工作流永久瘫痪；子 Run 又不能切换父 Run 的 profile；作为下游的策划节点带 parent，也不能自己提问。 新增 D9 / D10 取代 D6：策划是独立 agentId 的下游工作流节点，父子同为 standard；问询走 Runtime 直投——策划节点提交结构化决策字段，Runtime 创建 owner 为 Supervisor 的 pending。这不是新造机制，现役 AgentRuntimeUserInputRecord 本就两路投影（会话消息 + observation）， 直投只是让两路分别落到 Supervisor 与策划节点，从而满足「用户侧只有一个 对话对象」与「对话内容必须物理存在于 Supervisor 会话」两条产品约束。 新增第 1.1 节承载变更说明与 M0 修订计划（工作包 M0A-3），按是否被 agentId/source 命名裁决阻塞分两批。三个代码工作包零回退——无一行按 D6 编写；但 M0A-2 的 owner 验证四重绑死且要求 parent，standard 路径必须 另建物理独立实现，不可扩展。 Goal Contract 四方案随之作废，替换为三条实测约束，其中「验收 evidence 锚 game/fast_gdd.md、不得指向 .agent/planning」是为了避开 reject_agent_runtime_private_control_path 不区分读写的陷阱。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 12:13:04 +00:00
lhk229	be1bb8d5a1	文档：排除「改用 deny-list」并更正方案 C 代价 ... 方案 C 原写作「两道门都自然满足」，实际只解除入口门。 validate_goal_contract_acceptance_graph 强制合同至少一个 required 验收节点、每个 required 节点至少一项 requiredEvidence，且 evidence 必须命中 agent_runtime_acceptance_evidence_tools() 的 18 项；出口门 再要求每个 required 节点有当前 revision 下的真实成功动作回执。这 18 项全是项目读写/命令/预览/生成类工具，策划 Agent 按设计一项都 不该有，.agent/planning/** 又由 Runtime 写、不产生 Agent 回执， 因此合同必然带一个永不 passed 的节点。判定不可行。 「改用 deny-list」不是独立方案，等价于 C；且策略按 agent_id 取， plan 与构建、game-chat Supervisor 共用 project-supervisor， per-agent deny-list 区分不了它们。两者实质差别只剩失败方向。 据此明确真正的分岔是「策划 run 是否应当是 root project-supervisor run」，方案 D 与 B 是仅存的两条路。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 05:36:50 +00:00
lhk229	b6899619f0	文档：补全 M1 Goal Contract 死锁的第二道门与方案 D ... 复核发现原表述只覆盖了完成门。实际卡在两道互相独立的门： - 入口门 validate_root_goal_contract_control_plan_at 位于通用 tool-plan 解析路径，判据只有 agent_id 是 project-supervisor、 binding 的 root 是自己、存在 run profile binding，既不看 source 也不看 Run Profile。合同不存在时强制本轮恰好一个 agent.goal_contract 动作且无 plan/plan_update/response。 - 出口门 goal_contract_acceptance_completion_blocker_at_locked 判据含可信 source。 因此原方案 A「plan source 不进可信集合」只解除出口门，入口门照卡， 表中代价已更正。新增方案 D「plan root 改用独立 agentId」——三处 判据的共同项只有 agent_id == project-supervisor，这是唯一一次性 解耦的做法，代价是推翻第 4.1 节已冻结的 agentId。 同时记录冲突根源：现行是 deny-list 工具模型，可信 root Supervisor 默认持有 agent.goal_contract，两道门对现役 Agent 是照着做；plan source 是首个 allow-list 模型的 source，前提对它不成立。第 4.1 节 原三分 matcher 方案随之标注为不足。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 05:24:31 +00:00
lhk229	fe4c35e918	文档：标记 M0 完成并按动态目标验收图收敛 M2/M3 ... M0-1～M0-4 四个工作包全部通过门禁并合入 M0 集成分支，标记 M0 全部完成，并说明此处「合入」指集成分支而非 master。 M0 期间合入的上游动态目标验收图对所有可信 root Supervisor 生效 且不看 Run Profile，与本方案多条前提冲突，一并收敛： - M3 第 17 节：game-chat 根 Supervisor 现在必须先冻结 Goal Contract 才能路由，intentSummary 语义随之改变。裁定已批准 GDD 只能作为上下文进入目标理解，不得由 Runtime 直接物化成合同； GDD 身份也不是验收图的合法证据取值。 - M2 第 16.1 节：steer 替换会另起 replacement root run，该 run 必须重新冻结同一 approvedGddRef，不换稿不降级。 - M2 第 16.2 节：确定性收束与 Runtime 内部产物验证都不产生 Provider 回执，因此不构成验收证据；不得为此暴露内部验证工具。 - 第 22 节：trusted matcher 消费者从 2 个文件更正为 10 个文件 18 处调用，并新增 Goal Contract / Acceptance Graph 证据行。 M1 的 plan source 与 Goal Contract 协议关系保留为待裁决项，与 checkpoint handoff 私有持久化决策并列为 M1 入口前置；裁决冻结前 依赖 plan source 可信身份的 M1 代码不得合入。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 04:37:58 +00:00
lhk229	d5be71569c	合并 master 的自主构建测试锁竞态修复 ... 冲突在 game_chat_pure_continue_inherits_failed_root_semantics_and_manifest_progress： 两侧是同一竞态的互斥策略。M0A-2 持有 code-prototype 的 lane 锁让 child 起不来，再释放；master 改为让 child 跑到终态并等待其持久 manifest 投影， 为此把用例改成 tokio::test。 取 master 方案并移除本侧 lane 锁：两者并存会自相矛盾——锁着 lane 时 child 到不了终态，等待必然空转。且如 master 注释所述，lane 释放本身可能早于迟到 的 manifest 投影，仅靠 lane 锁并不能保证投影已落地。 验证：game_chat_pure_continue_inherits_failed_root_semantics_and_manifest_progress 与 agent_runtime_reject_revalidates_pending_action_after_lock_wait 均通过， 后者正是本次 master 修复针对的 CI 失败用例。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 03:54:20 +00:00
lhk229	0dc24a4c43	合并最新 master 到 M0 分支 ... 冲突解决： - provider_request_builders：M0A-2 的固定 owner 收束边界与 master 新增的 动态目标验收图改在同一段 prompt 构建。保留 owner 分支（固定 owner 仍不 广告 project.verify / command.run_limited），把 master 的动态目标分支提到 owner 判断之外对两条路径生效（固定 owner 属 goal_contract_participant， 本就该收到禁止调用 agent.goal_contract 的边界声明），git 提交协议改为仅 非 owner 路径追加以维持 M0A-2 边界。工具裁剪三个块并列保留，双方新增 测试全部保留。 - SupervisorChatOnlyView：保留 M0B-2 的谱系分支，采纳 master 的 projectWorkspaceStatusForDisplay 包装，避免该 import 变成死引用。 - runtime_actions：两侧各加一个导出，取并集。 - main_loop_tests：保留 M0B-1 需要的项目预初始化与 runtime lane。 - decision-log / pitfalls：双方条目都保留，各自维持原序。 验证：cargo check --all-targets 通过；前端 typecheck 干净； provider_request_builders / game_chat 委派 / goal-control 共 17 条 Rust 用例通过；agentRuntimeModel 与 appSurface 共 391 条前端用例通过。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 03:48:19 +00:00
lhk229	521b0b2ad4	文档：收敛立项策划方案里的 manifest 权威性挂起项 ... §19 增补 manifest 非轮次身份权威源的安全不变量：双侧契约都不含 run/root 字段且跨轮复用单例文件，因此只能作为 lineage 判定通过后的 补充信号；归档快照全部写入点须校验被归档 root 仍是当前 root；本阶段 不补身份字段，补则必须同时覆盖 set_task_status 旁路。 §22 接入点表新增一行，并点明 D4 关于 approvedGddRef 是否进 manifest 的 M2 决策需一并考虑该约束。 §23.3 记录 M0B-2 挂起项的处置与明确保留的残余风险，说明三条候选机制 各自为何不可安全落地；该挂起项不再阻塞 M0-4 收口。 §24 补一条通用不变量。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 03:28:02 +00:00
lhk229	c4669a06a7	修复：收敛 game-chat 阶段归档的 manifest 捕获身份 ... manifest 是项目级单例、不带 root/run 身份，跨轮复用同一份文件。 终态会话同步里的异步 manifest 捕获是四处快照写入点中唯一没有校验 "被归档 root 是否仍是当前 root"的一处；该读取若在下一轮接管后才 resolve，可能把掺入新轮活动的清单冻结成旧轮归档快照。 补齐与另外三处一致的 runId 校验。跳过不会饿死归档：开下一轮前的 capturePendingGameChatStageManifestBeforeNextRun 是阻塞门，快照 未冻结时直接报错要求重试。 同时把"main 未终态前 manifest 不参与裁定"这条既有但零覆盖的边界 用回归钉住，并显式记录残余风险：main 终态后 manifest 仍被逐字采信， 跨轮残留可被当作本轮结论。该断言即裁决锚点，改动它意味着重新裁决。 决策记录补 manifest 非轮次身份权威源一条；陷阱记录补新鲜度门控的 时间戳单位错配与 set_task_status 旁路两个坑。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 03:24:10 +00:00
lhk229	e5118d11b3	修复 CI 前端 lint 门禁 ... 整理 AI 游戏创作壳 import 顺序 为 Runtime 订阅 effect 补充有意的依赖豁免说明 保留未跟踪的绘图脚本不纳入本次提交	2026-08-12 02:49:25 +00:00
lhk229	851db37bdc	修复：收紧 game-chat 阶段投影与归档竞态 ... 严格校验 game-chat root、单主和嵌套美术 lineage，并同步 Launcher 摘要与终态后代状态。 禁用声称 game-chat 动态美术谱系的通用重试控件，保留完整 DAG 直属美术重试。 冻结终态轮次的 Runtime 与 manifest 快照，覆盖延迟刷新期间快速开始下一轮的持久归档路径。 补齐纯函数、AppSurface 回归与 M0 状态文档。	2026-08-11 17:42:49 +00:00
lhk229	8afac9c843	修复：统一 game-chat 单主阶段投影 ... 新增精确绑定 root、main 与动态美术 child 的 game-chat 谱系投影。 统一单主进度、可玩 revision、终态归档与跨轮恢复界面语义。 收紧 final-reply、通用 retry 与异常根身份的失败关闭边界。 补齐普通 DAG 回归、谱系冲突及事件证据契约测试。 同步技术方案、架构裁决与已知陷阱文档。	2026-08-11 16:23:58 +00:00
lhk229	133cd1fa3b	修复：非委派美术来源不再误入 game-chat 谱系门 ... M0A-2 将美术写入边界统一到严格谱系判定后，缺失 Run Profile 绑定从 "视为普通美术 run"（master 语义）变成 Err 失败关闭，且发生在只读工具 豁免之前：scheduler 直启与后台来源的 art run 全部工具被拦，恢复扫描 重执行 canvas.asset_generate 也因此永远发不出外部轮询请求。 在 retry 谱系判定之后、严格谓词之前增加 source 预筛：非 agent-delegate 来源直接判 Unrestricted，交由 autonomous owner 与路径策略管辖； agent-delegate 缺绑定与 agent-delegate-retry 的失败关闭语义不变。 治愈 CI 回归 recovery_scan_resumes_accepted_generation_on_default_worker_stack 与 command_output_read_allows_same_agent_history_and_rejects_cross_agent_action_id， 新增 non_delegated_art_sources_stay_out_of_game_chat_art_gate 钉住契约。 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-11 13:43:35 +00:00
lhk229	d22cf19cb0	修复：明确 game-chat 美术重试跨轮恢复 ... typed retry 与 mutation 阻断提示改为继续对话并由下一轮 main 重新审计 保留同 run 每缺口最多一次并补 failed/cancelled 跨轮新 delivery 契约测试 同步决策记录、踩坑记录与两份 tracked 技术方案	2026-08-11 12:11:22 +00:00
lhk229	203ebba9b4	修复：收紧 game-chat 美术重试结构判定 ... 入口结构身份改用不可变 binding 链，避免 task journal 缺失漏过 typed retry 守卫 无法完整证明的 retry-source 美术候选保持 mutation 失败关闭，同时保留完整 DAG 语义 补齐缺失 journal、无完整 binding、公开错误 kind 与全链非回归测试	2026-08-11 11:22:20 +00:00
lhk229	4d0c8e40b3	修复：封闭 game-chat 美术重试写入边界 ... 在 successor durable 写入前类型化拒绝动态美术 child 通用 retry 将遗留 retry-source 美术 run 收敛为只读并阻断全部 mutation 补齐终态零副作用、工具矩阵及 DAG/非美术 retry 非回归测试 同步技术方案、决策记录与踩坑说明	2026-08-11 10:40:12 +00:00
lhk229	e613b07fb5	合并最新master到M0A-2开发分支 ... 同步 origin/master 至 3c457feb4c 保留 M0 固定 owner 验证、本人 smoke、试玩执行者与动态 Canvas 谱系合同 通过 114 项完成合同回归、动态 Canvas 精确回归及格式编码检查	2026-08-11 09:12:10 +00:00
lhk229	9a7a799512	统一M0固定产物验证与可玩验收边界 ... 新增四个固定 owner 的 Runtime 内部产物验证、身份校验与恢复约束 收紧 code-prototype 静态检查、试玩执行者与动态 Canvas 委派谱系 补齐项目锁竞争、完成门、路径策略和失败关闭回归测试 同步 M0A-2 决策、技术方案与项目记忆	2026-08-11 09:02:00 +00:00
lhk229	da62f6bc01	文档：记录立项策划 Agent M0A-1 设计基线 ... 新增 Fast GDD 阶段技术方案与后续实现边界 同步文档入口、文档地图和项目决策记录 记录 M0A-1 非交付检查状态与 M1 前置决策	2026-08-11 02:41:42 +00:00