1078 Commits

Author	SHA1	Message	Date
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
wuxiangwanzi	b1ee6d816d	优化Agent对话用户消息气泡 (#179) ... 将用户消息改为右侧气泡显示。 统一项目对话、Agent聊天页和Agent对话弹窗样式。 补充消息宽度、换行、圆角和移动端友好布局。 --------- Co-authored-by: kdletters <kdletters@qq.com> Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/179 Co-authored-by: 五香丸子 <15518898337@163.com> Co-committed-by: 五香丸子 <15518898337@163.com>	2026-08-23 19:06:05 +08: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
wuxiangwanzi	814fc343e2	优化客户端主界面表现 (#177) ... 调整首页品牌区、创作类型按钮和输入框视觉比例。 重做最近项目横向信息卡并展示类型、更新时间和进度。 补充本地项目修改时间只读字段及首页回归测试。 同步更新 GameAgent 客户端实施文档。 --------- Co-authored-by: kdletters <kdletters@qq.com> Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/177 Co-authored-by: 五香丸子 <15518898337@163.com> Co-committed-by: 五香丸子 <15518898337@163.com>	2026-08-23 16:50:14 +08:00
Git Hooks Test	c98bf4a17a	新增AGC受控联网搜索工具 ... 在DirectProject的agc_tools MCP中按webSearchEnabled开关新增agc_web_search工具。 通过客户端loopback工具桥固定访问Bing RSS并返回有界公开HTTPS结果。 保持Codex原生webSearch禁用，并同步搜索开关到系统提示词与连接池隔离边界。 补充MCP目录、参数校验、结果过滤、真实搜索链路和配置回归测试，并更新技术文档。	2026-08-23 16:04:25 +08: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
kdletters	5c58539052	修复AGC配置脚本导入顺序 ... 按仓库 ESLint 规则整理 TypeScript 导入分组，解除 master 推送门禁	2026-08-23 01:59:21 +08:00
kdletters	d8a7e814f2	实现AGC直连增量进度反馈 ... 新增 direct turn update 事件与安全活动、正文增量、序号及终态生命周期 接入 Codex app-server 活动观察并限制高频活动通知 在 AGC 项目聊天渲染过程卡并保护项目与回合隔离、乱序门禁和自动跟随 补齐 direct 增量反馈的前端、Rust 回归测试与 Direct Interaction Event v1 文档	2026-08-23 01:54:28 +08:00
kdletters	01b10aafb2	修复素材画布生成恢复与模态交互 ... 素材生成凭据失败保留原幂等身份并支持登录后恢复 素材生成在远端提交、下载暂存和正式提交前复验会话与草稿状态 稳定 staging token 支持半提交修复并对冲突和文件系统异常失败关闭 素材画布三类模态框增加焦点圈闭、背景隔离和焦点恢复 Tauri 命令可达性改为 TypeScript AST 扫描并收紧 allowlist 补充生成恢复、取消态、staging 与模态交互回归及项目决策记录	2026-08-23 01:54:28 +08:00
Git Hooks Test	32da013545	修复AGC Skill跨平台指纹漂移 ... 统一以UTF-8 LF规范化内容计算Skill与清单指纹 安装隔离Skill时写入规范化文本避免Windows混合换行 增加LF与CRLF等价及安装结果回归测试 同步Skill Pack版本与实施文档、技术方案和踩坑记录	2026-08-23 01:20:28 +08: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
JenkenB	b7a6f853d5	修复 AGC 内置 Skill 内容指纹 (#175) ... ## 变更 - 重算并修正三项内置 AGC Skill 的内容指纹 - 将审核 Skill Pack 版本提升至 2026-08-22.2 - 补充指纹回归防范记录 ## 验证 - AGC Skill Pack Rust 单测 4/4 通过 - npm run check:encoding 通过 - git diff --check 通过 --------- Co-authored-by: 段舒康 <kdletters@qq.com> Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/175 Co-authored-by: 高物 <253518756@qq.com> Co-committed-by: 高物 <253518756@qq.com>	2026-08-22 16:53:36 +08: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
kdletters	27de28a487	迁移 npm workspaces 统一依赖边界 ... 根目录统一管理九个 workspace 与唯一 lockfile 迁移 CI、Jenkins 和容器的根目录单次 npm ci 补齐 hoist 兼容、版本校验与 workspace 门禁 同步依赖边界方案、运维文档和长期记忆	2026-08-22 13:17:26 +08: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
Git Hooks Test	00b78c9701	治理Rust构建缓存膨胀 ... 关闭测试 profile 的增量编译并对齐 AGC 开发调试配置 新增受控缓存审计和显式 incremental 清理命令 补齐安全测试、开发运维说明与团队踩坑记录	2026-08-22 11:52:14 +08:00
Git Hooks Test	d83551dd65	恢复AGC首页三类创作入口 ... 恢复做游戏、做素材、做方案的类型状态与分类提示 将受限 creationType 作为结构化首轮上下文传入项目内 Codex，保持用户原文不变 修正三项内置 Skill 指纹并补齐前端、Rust 与文档回归	2026-08-22 10:46:33 +08: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
Git Hooks Test	2d99a12196	修正首页自动建项目后进入项目对话 ... 恢复首页自动项目创建并移除无项目对话入口 首条正文与附件在新项目工作台内交给直连 Codex 补充 Tauri 命令、配置门禁、AppSurface 测试与迁移计划	2026-08-21 17:48:01 +08:00
kdletters	e8d9367df7	修复AGC依赖锁文件缺失 (#174) ... ## 问题 合并后的 `master` 连续暴露了三个既有的 AGC 原生构建 blocker： 1. `npm ci --prefix apps/ai-game-creator-shell` 因 lockfile 缺少 `@emnapi/core` / `@emnapi/runtime` 嵌套节点而失败。 2. 修复安装后，Linux Tauri build 又因通用配置无条件引用未生成的 Windows Codex 侧车而失败。 3. Native shell 全量测试继续暴露三项内置 Skill 指纹从初次提交起即与最终文件字节不一致，以及 Linux 会把 Windows 路径语法误判为普通相对路径。 这些问题都在画布优化合并前的 AGC 集成提交中已经存在；画布优化未修改 AGC manifest、lockfile、Tauri 配置或 Skill Pack。 ## 修复 - 使用子包 manifest 重新生成独立 package-lock 元数据 - 恢复 Tailwind oxide WASM bundled `@emnapi` 节点并保留 npm 元数据规范化 - 把 Codex Windows x64 侧车映射从通用配置迁到 `tauri.windows.conf.json` - 配置门禁同时约束通用配置无 Windows resource、Windows 配置保留完整白名单 - 重算三项内置 Skill 内容指纹并提升审核包版本 - Skill 引用路径按平台无关规则拒绝反斜杠、盘符、UNC、绝对路径和父目录段 - 补充 MCP 回归，并同步技术方案、迁移计划和长期排障记录 ## 验证 - npm 10.9.7 / npm 9.2.0：`npm ci --prefix apps/ai-game-creator-shell` 通过 - Linux：`npm run ai-game-creator-shell:build -- --no-bundle` 通过 - Skill 指纹 5/5 复算匹配；Skill / MCP 定向测试通过 - `npm run check:native-shells` 完整通过：AGC Rust `2159 passed / 0 failed / 15 ignored`，最终输出 `[check:native-shells] OK` - `npm run check:encoding`、`npm run check:rustfmt`、本次目标文件 Prettier、`git diff --check` 通过 - AGC、desktop、server-rs Cargo.lock 与两份 package-lock 均无漂移 Reviewed-on: #174 Co-authored-by: kdletters <kdletters@qq.com> Co-committed-by: kdletters <kdletters@qq.com>	2026-08-21 17:38:58 +08: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
Git Hooks Test	f25fb2a768	合并远端 master 更新 ... 保留远端 UI 编辑器与门禁清理改动 合入本地 AGC 直连 Codex 长任务修复 # Conflicts: # apps/ai-game-creator-shell/package-lock.json # apps/ai-game-creator-shell/src-tauri/Cargo.lock # apps/ai-game-creator-shell/src/view/project-development/index.tsx # apps/ai-game-creator-shell/tests/appSurface/home.suite.ts	2026-08-21 15:07:29 +08: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
Git Hooks Test	9d73f9a157	修复直连 Codex 长任务验收等待 ... 扩大 DirectProject 基础、MCP 与整回合有界等待并统一工具超时 明确禁用 shell 时使用文件快照和结构化试玩证据，避免误报能力阻断 同步真实陶泥儿生图、幂等复用与双视口浏览器验收记录	2026-08-21 13:30:06 +08: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