3062 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
lhk229	e5fa6438ca	Merge branch 'feat/five_min_design' of ssh://genarrative-station:2222/GenarrativeAI/Genarrative into feat/five_min_design	2026-08-24 12:51:59 +00:00
kdletters	79e31d948e	Merge branch 'master' into feat/five_min_design	2026-08-24 20:51:36 +08:00
lhk229	c0f616427e	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-24 12:45:38 +00:00
lhk229	7d92076071	合并 master：资源画布与图片精修链路 ... 四处冲突的取舍： - view/project-development/index.tsx：master 把 UI 编辑器从顶层三元分支 挪进 workbench stage 内部，改用 `is-ui-editor` 类切单栏、运行与播放按钮 在编辑器打开时禁用，并去掉了 `!focusedResource` 守卫。取 master 的结构， 再把分支的 `is-conversation-only` 追加进同一个 className。 - styles.css：双方各加一条 `.game-workbench-layout` 规则 （分支 `is-conversation-only`，master `is-ui-editor`），两条都留。 - tests/appSurface/home.suite.ts：双方在同一位置各加一个用例 （分支的做方案根 run 路由、master 的直连美术实时刷新），两条都留。 - SupervisorChatOnlyView.tsx：master 在该文件只有 prettier 重排版，没有 逻辑改动，取分支的 projectedRuntime 与 descendantsStillActive 判据。 验证：agc:typecheck 通过；cargo check --all-targets 0 error；eslint、 prettier、cargo fmt、check:encoding 通过；AGC 前端 931 passed / 1 failed， 唯一失败是本机已知的 Windows symlink EPERM 基线。appSurface 从 425 增至 426，双方新增用例都在。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 12:43:53 +00:00
suzmii	532c6d51fd	完善 Game Agent 资源画布与图片精修生成事务 (#181) ... ## 背景 本合并请求整合 Game Agent 资源管理的栏目分页自由画布，以及图片持续精修、候选生成和本地恢复事务。 当前远端比较基线： - base：`master` @ `b00a3f80576949567bf3320f0c6c92b4ed0a649d` - head：`codex/game-agent-resource-section-pages` @ `5795d2f9b8797c342dcf2920ccefec2a3ff3f472` - 相对 base：28 commits、33 files（`+3746 / -1333`） ## 主要改动 ### 资源管理分页自由画布 - 固定展示“设计文档 → 美术资源 → 音乐音效 → 游戏代码 → 项目版本”五个栏目；空栏目仍可从悬浮 Dock 打开空画布。 - `按依赖` 与 `按类型` 共用栏目分页画布；每个“排序模式 + 栏目”组合独立保存 viewport。 - 普通滚轮使用有界意图队列切换栏目；Ctrl/Meta + 滚轮以指针为锚点缩放；空白拖拽可沿 x/y 无限平移，不以资源 extent 作为导航边界。 - 资源卡支持拖拽布局与一次 CAS 持久化；切页、排序切换和卸载会统一取消拖拽及 pointer capture。 - 资源详情为非模态独立卡片：打开、切换或关闭详情不卸载背景画布、资源卡或依赖连线，也不重置 viewport、搜索或排序状态。 - 顶部已移除“生成视频 / 生成音效 / 生成背景音乐 / 新增 UI 设计”的手动入口；保留播放、未完成编辑恢复、排序和画布复位，以及资源详情中的既有编辑动作。 ### 图片持续精修与生成事务 - 图片资源可进入唯一活动精修草稿，支持原生批量导入、图片下方快速编辑卡、候选图层、任务侧栏和“设为最终图”。 - 生成成功只合并候选图层和 generation 权威事实，不以全量 hydrate 覆盖生成期间的本地编辑。 - 候选媒体、图层和公开 generation 记录写入并回读成功后，才推进私有 `candidate-ready`。 - 候选确认接入 Surface 保存 FIFO 与重新打开 hydrate；revision-sensitive 操作等待确认屏障。 - 失败归档和正式图提交采用可恢复中间态，避免中断后出现幽灵任务、重复 revision 或不一致的正式资产。 ### 合同与文档 - `acknowledgeCandidateLayers`、`importLocalImages`、`archiveFailedGeneration` 为必选 Host Port；不支持的宿主返回结构化 `unsupported-capability`。 - 同步更新 TypeScript / Rust 合同、Tauri command 可达性、PRD、技术方案与项目共享记忆。 - 明确资源栏目无限画布合同：普通平移不夹取；资源 extent、图片测量、布局变更和 resize 不得重置用户 viewport；仅首次可测量布局与显式复位按真实卡片包围盒适配内容。 ## 验证 CI run [#1290](https://git.genarrative.world/git/GenarrativeAI/Genarrative/actions/runs/1290) 针对当前 head 已完成且四项均成功： - [x] Repository checks - [x] Frontend tests（235 test files、3166 tests passed；App Surface 410 tests） - [x] Backend tests - [x] Native shell tests 另有本地定向检查： - [x] `npm run agc:typecheck` - [x] 资源画布、App Surface、Asset Canvas 与资源实时集成定向回归 - [x] Rust 候选确认、候选中断恢复、失败归档与恢复定向测试 - [x] `cargo fmt --check` - [x] `npm run check:encoding` - [x] `git diff --check` ## 评审 provenance - review #247、#248、#252 都针对旧 head，当前在 Gitea 中均标记为 stale；不将其写作“已处理 #247”或当前 head 的评审结论。 - review #253 针对旧 `5456a1d…` head，提出 PRD 退役入口、共享 pitfalls 的 extent 旧合同和 PR 正文事实更新三项 P2；对应文档已在 `5795d2f…` head 修复并推送。 - 早期由 PR #176 引入的候选持久化、归档、Host Port 与快速编辑卡问题，当前已在 base/head 中具备对应修复，不作为本轮重复阻断项。 - 当前 head 仍需新的、针对最新提交的审批；历史 stale review 不能替代当前 head approval。 ## 影响范围 - 修改 AI 游戏创作 App 的资源管理、图片精修、Tauri 本地持久化与恢复语义，以及共享合同和权威文档。 - 会调整本地资源布局、精修 draft 和私有 generation ledger 的状态机。 - 不修改 SpacetimeDB schema，不新增或变更 `/api/external/v1` 路由。 --------- Co-authored-by: kdletters <kdletters@qq.com> Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/181 Co-authored-by: suzmii <suzmii@qq.com> Co-committed-by: suzmii <suzmii@qq.com>	2026-08-24 20:42:58 +08:00
lhk229	41adfea134	策划 hydrate 收窄到策划链路，并收口三处重复事实源 ... 审查四条： 1. GDD hydrate 原本挂在任意 run 的任意一次监工状态变化上，而后端 hydrate 要抢项目写锁、扫 authority、必要时修投影，等于让做游戏和 做素材两条链路的每一拍心跳都去抢一次写锁。加一道门收窄。 门不能只看 source：审批卡的可见性判据是 `displayGdd && (pendingApproval || recoveryPending)`，跟当前 run 的 source 无关，非策划分支的监工面板也要靠 pendingApproval 点亮等待 审批位。所以判据是「策划链路 或 策划状态尚未落定」。 判据取 source 标量而不是 runtime 本体，保住那条 effect 依赖里只放 标量的原设计；策划状态读 ref 不进依赖，否则 hydrate 触发 hydrate。 后端把能力位读取提到取锁之前——它读的是应用配置不是项目文件，跟锁 无关，而 load_game_creator_app_config 每次都遍历所有配置路径读盘。 返回值不变，只是少占一段写锁。 2. 删掉零调用方的 append_plan_provider_usage_fact_for_test，cargo 的 never used 告警随之消失。 3. 前端 'project-supervisor-plan' 从三处收到 app/constants 一处： AgentRuntimeState.source 只是裸 string，改名没有任何编译期提示。 Rust 侧 filesystem.rs 两个守卫统一走 PLAN_FAST_GDD_PATH，顺带修掉 其中一处大小写敏感、另一处不敏感的不一致（两者串联使用，原先没有 实际绕过）。跨语言没有共享常量通道，TSX 与 mjs 只能留交叉引用注释。 4. App.tsx 里 game-chat 终态判定的两个本地实现删除，6 处调用改用 gameChatRuntimeProjection 的出口。保留 App.tsx 冻结 manifest 快照 的那道闸门——它判实时 manifest 决定要不要冻快照，与 canArchiveGameChatStage 判已冻快照不是重复检查。 验证：cargo check --all-targets 无新告警；agc:typecheck、eslint、 cargo fmt、prettier、check:encoding 通过；appSurface.test.ts 425/425。 Rust plan 过滤 404 passed / 2 failed，两条均已逐条定性为非回归： planning_clarification_answer_prepared_recovery_releases_execution_before_project_wait 在纯基线上同样失败（既存红），tool_plan_handoff_repair_restart_replays_chain_without_network_request 单独跑通过（本机批量 flaky）。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 12:35:27 +00:00
kdletters	b00a3f8057	移除资源画布顶部手动生成入口 ... 删除资源画布顶部的生成视频、生成音效、生成背景音乐和新增 UI 设计按钮 移除仅服务于这些入口的前端 handler 与入口配置 保留 Agent 语义生成、已有资源编辑、生成动画和未完成任务恢复能力 补充顶部入口消失与画布级操作保留的定向回归测试 同步更新 AGC 配置白名单、技术方案与项目决策记录	2026-08-24 18:29:43 +08:00
lhk229	4c20e06a9a	子 run 卡在 needs-reconciliation 时把父 run 一起抬出回执等待 ... 现场：上游网关把流掐断在 response.created 之后，策划子 run 落到 needs-reconciliation，父 Supervisor 在 waiting-for-delegate-receipts 上静默 二十分钟，界面全程显示「正在启动处理」。前端认得 needs-reconciliation， 但它读的是父 run，而父 run 看上去一切正常。 成因是三件事叠起来： 1. 委派子 run 的其余每一条终态出口都会向父 run 发布结果—— finish_game_creator_agent_runtime_turn_at、fail_..._turn_at、 fail_..._budget_at 三条都调 publish_game_creator_agent_delegate_result_for_state ——唯独 needs-reconciliation 不发。它在 task_queue 的 outcome match 里从 `outcome => return outcome` 那条兜底臂返回，一个通知都没有。 2. delivery 于是永远停在 Dispatched，而 static_delegate_completion_barrier_at 无条件把 Dispatched 计入 waiting。 3. 父唤醒是一次性事件驱动的：drive_waiting_static_delegate_parent_wake_pass 一旦看到 has_waiting() 为真就永久 return，没有任何周期性复查。 那条出口拒绝**认领结果**是对的——Runtime 无法证明服务端副作用是否已经发生， 伪造一份 delivery 结果比卡住更糟。缺的是「这条委派不会再产生回执」这句话。 改法：在 outcome match 里给 NeedsReconciliation 补一条臂，把父 run 也标成 需要人工核对（复用既有的 mark_static_delegate_parent_wake_needs_reconciliation_at）， 不伪造任何 delivery 结果。该原语自带门槛——父 run 的 run_id 不匹配、或父 run 不在 waiting-for-delegate-receipts 时直接返回 Ok(())——所以重复调用与竞态安全。 只覆盖立项策划子 Agent。做游戏与做素材的委派子 run 逐字保持既有行为； 它们那条链路上同一个死锁仍然存在，解开需要另行评估各自的父 run 语义。 守卫的四个前提拿现场 gameagent-75a9be8d 的落盘数据逐条验过：子 run phase=needs-reconciliation、parentAgentId=project-supervisor、parentRunId 与 父 runId 逐字相同、父 phase=waiting-for-delegate-receipts。这个修复会在那次 事故上真的触发。 三条新测试：策划子 run 卡死必须把父 run 抬起来；重复通知无副作用； design-director 子 run 同样卡死时父 run 一个字节都不变。 需要说明的是，被测的是 notify 助手本身，outcome match 那一行接线没有被覆盖 ——驱动一次真实的 NeedsReconciliation 需要 Provider。 delegated_child_reconciliation_tests 3/3、delegation::tests 19/19、 tool_plan 93/93、user_input 21/21、prompt::tests 32/32、 plan_envelope_repair_tests 6/6。tests::collaboration 仍是本机既有的 4 条失败， 已 stash 做 A/B 确认失败集合逐条相同。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 09:36:52 +00:00
suzmii	15a524e6e0	Feat: 完善 Game Agent 资源画板与图片精修链路 (#176) ... ## 摘要 本 PR 将 Game Agent 资源管理页升级为真实自由画板，并打通图片资源的快速编辑、候选生成、导入、失败归档与正式图提交流程。 同时补齐图片精修的事务恢复、候选身份校验、生成中任务恢复、鉴权重试，以及“设为最终图”后游戏运行资源的稳定刷新链路。 ## 主要变更 ### 1. 资源管理页自由画板 - “按依赖”视图改为统一自由画板： - 支持指针拖拽平移 - 滚轮平移 - `Ctrl / Meta + wheel` 以指针为锚点缩放 - 支持复位和全量资源适配 - 增加隐藏导航边界： - 边界由全量资源世界范围加安全留白决定 - 搜索过滤不会缩小边界 - 用户不能把全部资源拖出可视区域 - 图片资源卡按真实宽高比展示： - 预览读取真实 `pixelWidth / pixelHeight` - 布局碰撞、世界范围、依赖连线共同消费同一资源矩形 - 非图片资源保持固定卡片尺寸 - 点击资源改为非模态详情卡： - 背景画板不卸载 - 顶部工具栏、搜索、排序、缩放状态不重置 - 图片详情不再进入全屏页 ### 2. 图片资源快速编辑与精修画布 - 点击图片资源后直接显示快速编辑卡。 - 图片精修顶栏收敛为紧凑操作： - 返回 - 导入 - 定位当前最终图 - 撤销 / 重做 - 删除、修改、设为最终图进入选中图片的上下文卡片。 - 快速编辑生成不再阻塞整张画布： - 立即创建生成占位卡 - 占位卡可拖动并持久化位置 - 右上任务列表显示排队 / 生成中 / 完成 / 失败状态 - 任务列表可折叠 - 生成失败只影响当前任务： - 保留失败占位 - 可显式归档失败任务 - `reconciliation-required` 任务不允许删除 - 原生多选图片导入： - 使用 Tauri 原生文件选择 - 后端批量安全读取 - 一次推进草稿 revision - 失败不留下半导入状态 ### 3. 候选图与正式图事务 - 生成成功只加入草稿私有候选层，不直接修改 manifest。 - “设为最终图”是唯一正式资源切换入口。 - refine 保持原 asset ID 和来源身份，不追加新的业务资产身份。 - 正式文件使用不可变路径： ```text assets/canvas/<name>--<commitId>.png --------- Co-authored-by: kdletters <kdletters@qq.com> Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/176 Co-authored-by: suzmii <suzmii@qq.com> Co-committed-by: suzmii <suzmii@qq.com>	2026-08-24 16:27:33 +08:00
lhk229	4a3a5beaf0	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-24 08:26:14 +00:00
lhk229	7057daeb82	清理立项策划运行时死代码 ... 删除未使用的 planning storage 加锁 wrapper 和未接入授权层 删除旧 provider binding 与 approval fingerprint 入口 修正测试 fixture 直接调用 _locked 核心实现 修复非 Unix 分支不可达返回	2026-08-24 08:23:04 +00:00
lhk229	1c6a95aa1a	GDD 批准后补上交付出口：标题栏给出本地路径、查看正文与外部打开 ... 批准之后审批卡按设计整张收掉，从那一刻起用户就再也够不到自己刚批的 GDD： approvedGddRef 前端没人读，渲染好的 game/fast_gdd.md 也没有任何入口。做方案链路 跑到头是没有交付物的。 不新增卡片——交付行挂在阶段进度条底下，只在 state 为 approved 且不在恢复态时出现： 一行绝对路径，两个按钮「查看 GDD 正文」「打开文件」。批准前后是同一个框，多一行， 视觉连续。恢复态不给出口：那时权威投影还没收敛，磁盘上那份未必是用户批的那版。 正文弹层从审批卡里抽成 GddDetailsDialog 两处共用，内容一字未改，于是批准前后看到 的是同一份正文。路径按项目路径自身的分隔符拼，Windows 下不会混出反斜杠与正斜杠 各半的怪路径。 后端新增 open_local_project_plan_gdd_markdown，走 opener 交给系统默认程序。路径不 由前端拼：命令自己用 resolve_local_project_path 在项目根下解析常量相对路径——那是 项目内路径的唯一安全入口（根校验、归一化、逐段拒绝符号链接），GDD 的渲染侧用的也 是同一个解析器，两边对「项目内的这个文件」必须是同一个判定。再加存在性与普通文件 检查，未渲染时给出明确原因而不是把不存在的路径丢给 shell。 顺带修一条我在 80200e6a3 调高度时漏跑全量而留下的红：project-development 里那条 断言把 clamp 的三个断点钉成了字面量。它要锁的不变量是「自带上限 + 自己滚」，数值 是随排版调整的设计取值；钉死只会让每次调高度都顺带改测试，却挡不住真正的回归。 改成不锁数值，并补一条策划窄条没退回去继承 240px 天花板的断言。 新增测试（前端三条都做过 A/B，关掉交付行即红）： - Rust：路径门四条（正常解析、未渲染、非项目目录、相对路径）。 - 前端：approved 态出现路径与两个按钮且没有批准/修改/退回；点「打开文件」用正确 参数 invoke；recoveryPending 时交付行不出现。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 07:40:01 +00:00
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