3053 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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
kdletters	e6105cdcf9	提升AGC标准安装包patch版本 ... 同步标准客户端版本到0.1.2 更新workspace与配置版本门禁	2026-08-24 15:34:57 +08:00
kdletters	c59b8d4a1e	接入 External v1 抠图工具 ... 将 agc_remove_background 切换到 External v1 异步契约 补齐稳定幂等身份、画布目录上下文与有界队列投影 同步 Skill、技术方案与项目决策记录	2026-08-24 15:16:02 +08:00
kdletters	03add97d30	Merge remote-tracking branch 'origin/master'	2026-08-24 15:04:12 +08:00
kdletters	275cab876c	开放受控抠图语义工具 ... 新增 agc_remove_background 工具目录与客户端桥接 绑定登录账号、画布目录、稳定任务身份与有界队列结果 同步 Skill、技术方案和项目决策记录 补充工具参数、队列投影与内容指纹测试	2026-08-24 15:03:37 +08: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
wuxiangwanzi	1334648246	优化客户端登录界面视觉 (#185) ... 登录检查、登录页和错误页统一使用陶泥儿产品形象与平台浅色主题。 优化登录卡片、输入控件、切换按钮及窄屏布局。 补充认证界面测试并同步更新客户端技术方案。 --------- Co-authored-by: 段舒康 <kdletters@qq.com> Co-authored-by: kdletters <kdletters@qq.com> Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/185 Co-authored-by: 五香丸子 <15518898337@163.com> Co-committed-by: 五香丸子 <15518898337@163.com>	2026-08-24 14:38:15 +08:00
suzmii	aa8e3507d1	新增 External v1 去背景生成链路 (#184) ... 新增外部去背景 API、MCP 工具与异步队列契约 补齐来源归属、媒体类型、幂等重放和画布原子持久化校验 修复 provenance 重建、assetKindOverride 门禁与 revision retry 竞态 同步 Python helper、Skill、OpenAPI 及项目文档 --------- Co-authored-by: kdletters <kdletters@qq.com> Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/184 Co-authored-by: suzmii <suzmii@foxmail.com> Co-committed-by: suzmii <suzmii@foxmail.com>	2026-08-24 14:37:32 +08: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