3044 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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
kdletters	042eb05b0e	提升AGC标准安装包patch版本 ... 同步Tauri、Cargo与Node版本到0.1.1 更新AGC配置检查门禁	2026-08-24 12:42:56 +08: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
kdletters	299b52d71b	Merge remote-tracking branch 'origin/master' ... # Conflicts: # apps/ai-game-creator-shell/src-tauri/src/project/resource_editor.rs	2026-08-24 12:21:29 +08:00
kdletters	46053832fd	补齐 Codex 语义媒体资源能力 ... 新增登记资源查询与媒体创建/派生工具 接入画布上下文、幂等账本与 warning 回放 更新客户端 Skill、技术方案与决策记录 补充资源生成与传输失败回归测试	2026-08-24 12:05:27 +08: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
kdletters	2449e77461	修复切换账号后画布资源不可编辑 (#182) ... ## 变更 - 新增按服务 origin、平台 userId / Developer Key 摘要和本地 projectId 分区的 External Editor 项目绑定 - 新增按当前 principal、远端项目、本地 assetId、源 SHA-256、媒体类型和 canonical kind 分区的资源绑定 - manifest 中的 canvasProjectId / resourceId / assetObjectId 仅保留来源信息，不再作为当前账号的可编辑授权 - 切换账号后从本地正式资源重新上传、confirm、登记；图片、视频、角色动画、素材画布参考、art-spec 派生和 Direct 恢复统一使用当前账号绑定 - prepared / accepted / running 账本继续冻结原 principal；账号变化或远端结果不确定时停止补偿并保留现场等待对账 - 同步技术方案、decision log 和 pitfalls ## Review 结论 - 两路独立代码 review 均未发现剩余 P0-P2 - Review 发现并关闭了 max-pass 测试误放宽问题，恢复为绑定最大轮次的强断言 - 首轮 CI 暴露两处本 PR import 排序错误，已在独立提交 09486f142 中修复并复核 ## 验证 - Rust 完整测试：2301 passed，0 failed，16 ignored - Rust 集成与构建测试：5 + 2 + 14 passed - repository-ci 本地同构门禁通过：lint、typecheck、139 表 SpacetimeDB schema guard、403 个 appSurface 测试、web/admin-web build - External Editor procedure 真实 smoke 通过：精确重放、冲突、删除 fail-close、并发和孤儿检查 - Encoding check：5594 files - git diff --check 通过 - Gitea Project CI run 1253：Repository checks、Frontend、Backend、Native shell tests 全部通过 - 当前 head a0b8415be 已合并 origin/master 44ee28c43，PR 无冲突 ## 后续依赖 PR #176 暴露了这一公共账号身份缺陷。该 PR 合并后，#176 需要 rebase，并删除或接入其局部 canonical cache，不能保留第二套账号绑定系统。 Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/182 Co-authored-by: kdletters <kdletters@qq.com> Co-committed-by: kdletters <kdletters@qq.com>	2026-08-24 11:33:37 +08: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
wuxiangwanzi	44ee28c43f	让运行视窗按内容自适应 (#180) ... 为本地预览注入只读尺寸桥并校验 iframe 消息来源 按可用区域等比缩放完整游戏画面并移除横纵滚动条 补充前端与 Rust 回归测试并同步运行视窗文档 --------- Co-authored-by: kdletters <kdletters@qq.com> Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/180 Co-authored-by: 五香丸子 <15518898337@163.com> Co-committed-by: 五香丸子 <15518898337@163.com>	2026-08-24 10:54:06 +08: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
kdletters	0b546c9e4c	完善AGC受控客户端能力 ... 补齐美术复用与显式重生成模式、稳定回合身份和幂等补偿恢复 收紧付费授权、四切片资源身份及告警投影边界 限制Direct Codex仅写真实game目录并接入受控联网搜索 持久化Direct用户与助手消息并修复同进程恢复竞争 同步审核Skill、技术文档、项目记忆和回归测试	2026-08-23 22:34:16 +08:00
wuxiangwanzi	e3b229ac78	调整 Agent 对话栏 Logo 与工作台布局 (#183) ... 放大 Agent 栏产品 Logo 并接入正式钱包入口 移除工作台外层卡片圆角与间距，改用区域底色和竖向分隔 将资源依赖/类型切换整理为联通分段按钮 --------- Co-authored-by: kdletters <kdletters@qq.com> Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/183 Co-authored-by: 五香丸子 <15518898337@163.com> Co-committed-by: 五香丸子 <15518898337@163.com>	2026-08-23 22:09:47 +08:00
Git Hooks Test	8fe439feba	修复AGC资源生成的序列帧持久化与画布完成上下文 ... - 本地manifest资产新增imageSequenceFrames和imageSequenceDurationMs，角色动画完成后随账本恢复并写回manifest - 新建视频、音效和背景音乐时创建或复用同名画板项目与素材库目录，并携带projectId、assetFolderId和canvasCompletion - 资源编辑请求指纹纳入generationMode，旧账本继续通过legacy指纹兼容 - 同步更新共享契约、前端资源投影、实施计划文档与定向测试	2026-08-23 21:37:27 +08:00
Git Hooks Test	e0319e80f0	补齐AGC资源生成能力并接入视频动画与音频生成 ... - 资源编辑命令新增create生成模式，支持无源视频、音效和背景音乐生成 - 图片聚焦态新增角色动画生成入口，提交角色动画接口并下载预览视频登记为本地媒体 - 资源页新增生成视频、生成音效、生成背景音乐入口 - 统一资源编辑面板按生成模式区分新建媒体资源与编辑现有资源 - 补充资源生成与角色动画定向测试，并更新AI游戏创作App实施计划文档	2026-08-23 21:37:27 +08: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
kdletters	1a909704aa	预览镜像同时内置本地环境配置 ... 预览 API 与 worker 通过 BuildKit secret 内置 .env.local 补齐预览控制面固定 .env.local 校验与文档 更新 Docker 构建边界测试	2026-08-23 14:29:46 +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	78ebe063f3	修复Jenkins Web构建npm版本漂移 ... 新增 Jenkins 用户级 npm 10.9.7 版本隔离引导 在 Web Build 各独立 shell 复用固定 npm 后执行 workspace 安装与门禁 收紧生产运维检查并同步 npm workspaces 文档与共享决策	2026-08-23 04:11:18 +08: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
kdletters	8cc1432b86	修复完整容器数据库内存上限 ... 将完整容器 SpacetimeDB 内存上限提升到 2 GiB 增加基础 Compose 内存门禁 同步容器运维文档与项目长期记忆	2026-08-22 16:22:55 +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