299 Commits

Author	SHA1	Message	Date
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
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	1c6a95aa1a	GDD 批准后补上交付出口：标题栏给出本地路径、查看正文与外部打开 ... 批准之后审批卡按设计整张收掉，从那一刻起用户就再也够不到自己刚批的 GDD： approvedGddRef 前端没人读，渲染好的 game/fast_gdd.md 也没有任何入口。做方案链路 跑到头是没有交付物的。 不新增卡片——交付行挂在阶段进度条底下，只在 state 为 approved 且不在恢复态时出现： 一行绝对路径，两个按钮「查看 GDD 正文」「打开文件」。批准前后是同一个框，多一行， 视觉连续。恢复态不给出口：那时权威投影还没收敛，磁盘上那份未必是用户批的那版。 正文弹层从审批卡里抽成 GddDetailsDialog 两处共用，内容一字未改，于是批准前后看到 的是同一份正文。路径按项目路径自身的分隔符拼，Windows 下不会混出反斜杠与正斜杠 各半的怪路径。 后端新增 open_local_project_plan_gdd_markdown，走 opener 交给系统默认程序。路径不 由前端拼：命令自己用 resolve_local_project_path 在项目根下解析常量相对路径——那是 项目内路径的唯一安全入口（根校验、归一化、逐段拒绝符号链接），GDD 的渲染侧用的也 是同一个解析器，两边对「项目内的这个文件」必须是同一个判定。再加存在性与普通文件 检查，未渲染时给出明确原因而不是把不存在的路径丢给 shell。 顺带修一条我在 80200e6a3 调高度时漏跑全量而留下的红：project-development 里那条 断言把 clamp 的三个断点钉成了字面量。它要锁的不变量是「自带上限 + 自己滚」，数值 是随排版调整的设计取值；钉死只会让每次调高度都顺带改测试，却挡不住真正的回归。 改成不锁数值，并补一条策划窄条没退回去继承 240px 天花板的断言。 新增测试（前端三条都做过 A/B，关掉交付行即红）： - Rust：路径门四条（正常解析、未渲染、非项目目录、相对路径）。 - 前端：approved 态出现路径与两个按钮且没有批准/修改/退回；点「打开文件」用正确 参数 invoke；recoveryPending 时交付行不出现。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 07:40:01 +00:00
lhk229	6578bcf2ae	策划窄条不再吃调试面板的 240px 天花板，放宽到 52dvh/640px ... 截图里被压出内滚的是澄清卡所在的窄条：纯总控视图整个包在 game-workbench-chat 里，窄条带着 agent-runtime-status 类，继承了给做游戏链路常驻调试面板设的 clamp(120px, 24dvh, 240px)。窄条只在需要用户动手时出现，内容是要读完再回答的 题面，按审批卡同级放宽；小屏媒体查询里的 max-height: none 分支原样生效。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-24 06:38:27 +00:00
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	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
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	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
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
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
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	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
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	2a44169ddb	澄清卡不再叠一张通用确认卡，策划根委派免确认 ... 子 Agent 要提问时，Runtime 在 parent-wake 屏障处把问题包成 user.input_request pending（ensure_static_delegate_user_input_wait_at_locked），同一份问题再投影成 userInputRequest。这个 pending 只是问题的载体，user.input_request 也从来不在 GAME_CREATION_APP_COMMANDS 的 confirm 集合里，没有任何确认语义。但三个渲染面都 无条件把 pendingToolAction 也画成通用待确认卡，于是同一个请求出现两遍：上面是问答 卡，下面是拿 tool 名当标题、拿 questionCount/questionsSha256 这种取证摘要当副标题 的确认卡，还和问答卡在聊天视图里糊在一起。 加 agentRuntimePendingActionIsUserInputCarrier，在开发者 Runtime 面板、项目总控 概览卡和聊天视图三处统一把通用确认面判掉，只留问答卡。 立项策划根 Run 的 agent.delegate 同时改为免确认。plan 根的工具面按阶段收窄到「当前 唯一能推进链路的动作」，Delegate 阶段就只广告 agent.delegate 一个工具，让用户确认 「要不要执行唯一能做的那件事」没有决策含量，返工那一轮同理；这条链上真正由人把关的 关口是 §13.0 的 Fast GDD 审批卡，不动。source 只作弱判据，命中后必须过 validate_project_supervisor_plan_root_binding_at 强判据，否则做游戏那条根的委派确认 会被漂移或伪造的 binding 悄悄放开；绑定读盘只发生在本来就要确认的 agent.delegate 这一个组合上。 新增两条用例：Rust 侧一起断言 plan 根 delegate 免确认、plan 根上 agent.spawn_isolated 照旧确认、gui 根 delegate 照旧确认；前端侧断言载体 pending 只渲染问答卡，且 user.input_request 与 questionsSha256 都不出现在界面上。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 07:09:50 +00:00
lhk229	8e5e0a7fea	做方案入口改回两枚模式 chip ... 上一版把「做方案」做成输入框工具栏里的单个开关，默认不选中。问题是默认态没有 任何文字说明"现在会做游戏"，只有"做方案没被选中"——它读起来像筛选标签而不是 模式分叉，把默认态藏了起来；而且模式选择混进了附件/发送那排动作按钮里，层级也 是错的。 改成合并前的形态：输入框上方一排常驻 chip，做游戏（默认）与做方案两个都可见， 选中态填色。两个互斥选项都重要时分段控件才是标准解法，单开关只适用于"关是明显 默认且功能人尽皆知"；做方案是这条分支要暴露的新链路，最缺的就是可发现性，而且 点错起的是另一条 runtime 链（委派、澄清 pending、GDD 审批），不该藏在一次猜测 性的点击里。样式与容器沿用合并前已上线的类名。 做素材不加回来：master 已把它并进直连构建，与做游戏同链，再列一枚就是两个按钮 干同一件事。占位文案随模式变（做游戏／做方案各一句），副标题保持 master 的固定 问候语——合并前那版副标题与占位是同一句话，重复两遍。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 04:52:00 +00:00
lhk229	ab6070e8e3	首页加回做方案入口 ... master 的直连 Codex 改造把 HomeAgentMode 和「做游戏 / 做素材 / 做方案」模式栏 整个删了，合并后 startMode 在前端没有 planning 的来源，只能写死 direct-build。 立项策划链路的后端、prompt、澄清卡、审批卡都还在，但从首页够不着，CI 上 home.suite.ts 的两条 routes 做方案 用例也因此找不到按钮而挂。 不把三选一搬回来（那是 master 主动收掉的产品形态），只在输入框工具栏加一个 「做方案」开关：选中时 startMode 走 planning、提交按钮文案切成「进入立项策划」、 占位文案换成方案口径；不选中时与 master 的直连默认完全一致。 createHomeDraft / createHomeDraftAutomatically 改为由调用方传 startMode， 删掉 HOME_DRAFT_START_MODE 这个占位常量。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 04:31:52 +00:00
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
Git Hooks Test	2d99a12196	修正首页自动建项目后进入项目对话 ... 恢复首页自动项目创建并移除无项目对话入口 首条正文与附件在新项目工作台内交给直连 Codex 补充 Tauri 命令、配置门禁、AppSurface 测试与迁移计划	2026-08-21 17:48:01 +08: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	7e3adc38b9	完美像素产物会缩放到与原图相近的尺寸；提高识别小网格的倾向 (#172) ... Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/172 Co-authored-by: Linghong <ink29535@proton.me> Co-committed-by: Linghong <ink29535@proton.me>	2026-08-21 11:19:17 +08:00
Git Hooks Test	bacd7a9da7	完成 AGC 直连 Codex 与审核 Skill 工具链 ... 收口首页和项目聊天为唯一 Direct Codex thread 内置五项审核 Skill Pack 与受控 MCP、浏览器及美术工具桥 补齐 Codex Windows 侧车组件、Provider 代理和凭据幂等边界 同步客户端资源投影、交互测试及技术文档	2026-08-20 23:55:00 +08:00
lhk229	19f4b6276c	合并 master（0797410ee） ... 三处冲突： - decision-log.md / pitfalls.md：双方各自追加条目，两边都保留；决策记录是新在 前的日志，master 的 2026-08-20 条目排在本分支 2026-08-19 之前。 - panels.tsx：canRetrySupervisor 两侧逻辑逐字相同，只差续行缩进。实测本分支版本 过 prettier、master 版本不过，故取本分支缩进；顺带把 master 一并带进来的相邻 needsSupervisorReconciliation 块补成 prettier 输出。解析结果与合并前该文件逐字 一致，没有语义改动。 已逐项核对本分支 11 个提交的关键标记在合并后仍在树上。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 11:48:29 +00:00
k88936	0797410eef	Feat/UI自动识别和布局编辑器简化版 (#170) ... * 支持从项目, 本地电脑, 主站导入/引用素材. * 页面复杂, 需要足够空间, 作为资源打开时会占满右侧 * 编辑结果作为一种新的美术资源. * 新增素材按钮现在是空的实现, 临时在旁边加了一个新增UI设计的按钮 临时入口:  简化: * 组件实现了最基本的图片和文本 * 容器式布局未接入llm编辑 * 不同阶段统一维护一个状态State, 任何阶段都可以人工调整, 不设单独的步骤 * 多图的UI合并功能暂时不要求, 隐藏入口 * 因为生成工具尚未从主站迁移, 主站地图子画布未实现, 以tab栏的形式容纳素材的子画布需求搁置 * 未实现llm绑定字体功能 * 识别会替换现有UI树, 暂时不是增量的 Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/170 Co-authored-by: 王德宇 <kvtodev@outlook.com> Co-committed-by: 王德宇 <kvtodev@outlook.com>	2026-08-20 19:07:25 +08:00
lhk229	c2d5273873	重做 master 合并，找回上次合并丢失的分支工作 ... 上次合并 3d8abac33 把 24 个双边改动文件里的 7 个整份取了 master，另有数个 实质取了 master 版本，静默回滚了分支工作；其中 main_loop.rs 保留 master 的 调用点、provider_recovery.rs 保留分支的 cfg(test) 门，导致非测试构建编译失败。 本次从 ca6a3cd4c 对最新 master(341761ee3) 重做，逐个人工解析 38 处冲突： - 澄清等待态：保留分支的 lane 外 parent-wake 设计与锁守卫，套上 master 新增的 parent task 身份校验与 game-chat 安全默认返工；`_locked` 两种 false 语义在 delivery.rs 按 trusted_game_chat_autonomous_parent_chain_at 区分。 - decision-log：按日期把 master 三条插进分支条目之间，57 处 M1 记录全部保留。 - manifest.rs：采用 master 的 windows_sys 绑定，保留分支的目录/reparse point 拒绝。 - 做方案入口按 master 的提交重构改造：resolveProjectSupervisorRuntimeSubmission 新增 planningEntry，startMode 经 launcher context 传到 App；并把策划入口从 direct-codex 产品默认中摘出，做游戏与做素材保持 master 新默认。 - 首页两条入口用例按 master 已改的创建流程更新；非空目录确认用例因该流程 在首页入口不再可达而移除。 验证：cargo check --all-targets 通过；agc typecheck 通过；appSurface 395 passed。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 13:15:16 +00:00
lhk229	ca6a3cd4cd	修复M1策划链路可靠性 ... 阻止人工核对中的策划根写入审批回执 在投影恢复前校验项目身份并使用唯一项目ID 增加策划能力停用门禁与既有sidecar只读行为 拒绝非法plan与自主构建档位组合并收紧消费者 补齐前后端回归测试与M1技术决策记录	2026-08-19 09:13:43 +00:00
lhk229	6d5afd9f6d	修正M1首页立项入口 ... 仅让首页做方案进入立项策划 恢复做游戏和做素材的直接构建路径 同步入口合同与回归测试	2026-08-19 05:27:53 +00:00
kdletters	b8dc3fe1b1	修复AGC登录网络错误与构建门禁 ... - 登录页归一网络错误并避免暴露底层 transport 文本 - 补充拒绝连接提示与错误信息脱敏回归测试 - master 推送门禁增加 AGC AppSurface 验证	2026-08-18 22:15:49 +08:00
kdletters	fe69a49a9c	修正AGC主分支门禁 ... - 修正直连 Codex 烟测脚本导入排序 - 修正播放请求回调依赖并稳定调用最新动作	2026-08-18 21:18:39 +08:00
lhk229	d44f930d1f	收口design组展示名，改为设计实现Agent ... 分组字典、manifest默认名与分组头像字一并改掉 个体Agent名兜底跟进，玩法策划Agent与内部id不动 跟改16处由label派生的断言 第 18.2 节要求 design 组用户名称改为「设计实现组」，与新阶段「立项策划」区分。 bf2185fba 只改了 taskGroupLabels 一本字典，另两本同概念字典没动，于是同一个 design 组在开发者面板/文本汇总里叫「设计实现组」、在工作台状态栏里叫 「策划 Agent」——这个语义不一致是该提交引进来的。 先更正一条此前的判断：曾把这条的严重度建立在「新项目默认主路径上『立项策划』 与『策划 Agent』同屏共存」上。该说法未经验证且不成立——用 appSurface harness 实测策划路径，子 Agent 状态栏根本不渲染，策划 Agent 出现 0 次。结构上二者确在 launcherView === 'project-development' 分支的同一棵树里，但未能把用例驱动到该 分支，故不作为事实主张。若真会撞，也是批准后进入完整制作那一段，比原描述窄 得多。改这条的理由与撞不撞名无关，只是第 18.2 节的要求 + 上述不一致。 口径取最小方案：保持兄弟项的「X Agent」体系，design 取「设计实现 Agent」。 不把 taskGroupLabels 直接塞进 groupConfigs——两本字典命名体系不同（「X组」对 「X Agent」，且音乐组/音频 Agent、运营组/发布 Agent 连词都不一样），直接替换 会连带改掉另外五个分组名；消灭重复字典属视觉改版，单独立项。 改动：agentPresentation.ts 的 groupConfigs、view/project-development/index.tsx 的 summarizeAgent 默认名与同文件分组头像字（策→设）、model.ts 中 agentId.includes('design') 的个体名兜底（design-director 走这里）。 design-foundation 的「玩法策划 Agent」单列在前，不变；内部 agent id 与 design 分组键均未动。 测试量原估「3 处断言」严重低估，实跑发现 project-development.suite.ts 有 16 处 派生断言需跟改——「X 文本回执」由 App.tsx 的 `${candidate.label} 文本回执` 拼出、 「历史成果 · X」由 resourceProjectionModel.ts 拼出、dock 的 article accessible name 亦然。替换用后行否定守住「玩法策划 Agent」（它含「策划 Agent」子串）， 替换前后该串恒为 6 处。agentRuntimeModel.test.ts 与 projectResourceProjectionModel.test.ts 里剩余 4 处是测试自造的输入 fixture、 不由字典派生，保持不动。 验证：appSurface.test.ts 383 passed / 0 failed；agentRuntimeModel、 agentTraceSummary、projectResourceProjectionModel、projectResourceLiveUpdateModel 合计 39 passed；agc:typecheck、ESLint --max-warnings 0、check:encoding、 git diff --check 通过。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 12:20:01 +00:00
lhk229	7ca82ba7aa	修复M1D审查发现的锁错误脱敏与澄清轮次口径 ... 审批卡链路的三处项目锁错误改为脱敏后再进typed错误 阶段进度按等待状态显示真实轮次，不再透传0-indexed值 去掉reconcile错误的重复code拼接 补一条Rust脱敏回归与两条前端轮次回归 锁错误脱敏（方案 §18.3「返回值不包含绝对路径……或内部诊断」）： acquire_project_write_lock 的 Err 内嵌 .agent/project.lock 真实绝对路径。补 redact_agent_runtime_project_paths 的三处是前端审批卡真正会显示的那条链—— reconcile_plan_gdd_approval_projections_at（hydrate 在取自己的锁之前调它）、 hydrate 自己的锁、decide_plan_gdd_at（其错误与 hydrate 的错误渲染在同一个 错误区）。planning 另有 14 个取锁点沿用未脱敏写法，属 M1B/M1C 既有模式， 本次不扩面。脱敏不破坏「项目正在被其他写操作占用：」前缀，project_gates.rs 与 provider_recovery.rs 两处按前缀分类的判据不受影响。 澄清轮次口径：clarificationRound 与 awaitingAnswerFor.round 都由 static_delegate_lineage_counters 派生，该函数排除目标自身，是 0-indexed 的 「已答轮数」；后端判上限用的是 current_round + 1。原样渲染成「轮次 X/3」 整体差一格——问最后一轮时显示「轮次 2/3」，字面暗示还剩一轮。只改前端 文案、不动 DTO 语义：等待回答时显示「第 N+1 轮 / 共 3 轮」（此时 latestDelegationId 就是当前 delivery，+1 恰好等于后端校验用的轮次）， 其余状态退回「已完成 N/3 轮澄清」，不猜当前轮。 顺带：planning_hydrate.rs 里 reconcile 的错误原本用同一 code 把 to_string() 当 detail 重包一层，而 PlanningStorageError 的 Display 已是「{code}: {detail}」， 渲染出 CODE: CODE: detail；code 与 detail 均无变化，改为直接 ? 传播，并把 「不重复拼 code」钉进回归。 测试陷阱：写「占住项目锁」的 fixture 必须给锁 JSON 填真实 createdAt。失效锁 回收的年龄判定读的是该 JSON 字段而不是文件 mtime，填 0 会让锁显得约 1.7e9 秒 老、越过 600 秒阈值被当场回收删除，hydrate 反而成功。第一版 fixture 正是这样 自证失败的，注释已写明。 验证：Rust planning_ 组 155 passed / 0 failed（原 154 + 本次 1 条）； appSurface.test.ts 383 passed / 0 failed（378 原有 + 5 条新增）；三条新回归均经 变异验证，逆转对应修复即变红。cargo fmt --check、agc:typecheck、ESLint --max-warnings 0、check:encoding、git diff --check 通过。 撤回一条此前的审查发现：曾判定 hydrate 读 manifest 缺符号链接判定。复核后不 成立——read_manifest 自身在 is_symlink 处即拒，防护在另一层；.agent 目录本身 为符号链接的残差也无窗口，紧随其后的 resolve_planning_path 同样逐段判定。 未据此改动代码。 新记一条既有问题（非 M1D 引入）：seedManifest.projectId 是常量 local-project-draft，App 的 5 个 init/import 调用点全传它，因此本机所有项目 projectId 相同。§18.3 第 1 步依赖的 projectId 校验因此分辨不出任意两个项目， 该门当前近乎恒真，须单独立项。 仍未修：hydrate 身份校验排在落盘投影修复之后（修它须注意 reconcile 自取项目 锁、.agent/project.lock 不可重入，不能把检查直接挪到 hydrate 取锁之后）； design 组展示名剩两处硬编码，且与 taskGroupLabels 命名体系不同，需先定口径。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 11:50:43 +00:00
lhk229	abcc393fde	修复M1D审查发现的审批决定失败路径 ... 决定失败也重灌权威状态，顺序钉死为先hydrate后写错误 responseId复用键纳入comment，改写修改意见时换新ID 恢复期门控扩到已打开的评论弹层，保留已输入内容 补appSurface harness的策划command分发与三条变异验证过的回归 审查基线为 14c00017c..bf2185fba（技术方案第 13、18 节）。其后分支已前进到 c6a08ef98，4624fd795 与 c6a08ef98 都不动 src/**，审查结论不受影响。 三条缺陷： 1. decidePlanGdd 只在成功分支 hydrate。后端 decide_plan_gdd_at 有多条真实 PLAN_STALE_APPROVAL 分支（GDD 不在当前 lineage、identity 不符、版本被取代、 pending 丢失），命中后卡片停在已失效的 pending 身份上、三个决定按钮仍可点， 且 recoveryPending 永不翻真导致「重试恢复」入口不渲染，卡内没有恢复路径。 现按第 18.3 节在失败分支同样 hydrate——该句不区分成功与失败。两句顺序不能反： hydratePlanGddState 入口会 setPlanGddError(null)，先写错误再 hydrate 会把错误 擦掉；回归钉死了这个顺序。 2. responseId 复用键为 approvalRequestId:action，不含 comment，违反第 13.2 节 「改变 action/comment 必须生成新 responseId」。在第 14 节承认的「receipt 已提交 但 response 丢失」构造下，改写修改意见后重提会带旧 ID，命中后端「同 responseId 的审批意图不一致」硬拒，改写后的原因永远落不了盘。现按 approvalRequestId 存 {action, comment, responseId} 全量意图。判据方向为宁可多换不可少换：多换的最坏 后果是 replayed 降级成 already-decided（都是 Ok，且 already-decided 正是第 18.2 节要求的刷新态），少换是硬错误。 3. 第 18.2 节「recoveryPending 时不允许提交决定」原来只作用于三个触发按钮，而弹层 是打开之后才可能被后台 hydrate 翻掉资格的，其提交按钮只看 busy 与非空。现在 submitComment 与该按钮都判 canDecide。刻意不自动关弹层，否则会丢掉用户已经写好 的修改意见。 测试：harness 新增 hydrate_game_creator_plan_gdd_state 与 decide_game_creator_plan_gdd 分发分支及 createPlanGddStateView fixture；未配置策划 状态时 hydrate 与接入前一样抛出，既有 378 条行为不变。新增 plan-gdd.suite.ts 三条 回归并逐条变异验证——逆转对应修复后三条各自以自己的断言变红；修复二的变异是部分 逆转（保留新 Map 结构、只删 comment 比对），因此钉住的是 comment 这一维本身。 验证：appSurface.test.ts 381 passed / 0 failed；agentTraceSummary 与 rememberCommand （另两个 import src/App 的用例文件）13 passed；agc:typecheck 通过；6 个改动文件 ESLint --max-warnings 0 通过；check:encoding 5409 文件通过；git diff --check 干净。 不改 Rust——三条全在前端，后端语义已经正确。 文档：更正第 23.8 节 M1D-1 行误引的合入提交（5b11a0530 是 ESLint 修正，落地是 0052a80da），并补 M1D 审查修复快照。同时更正既有记录里「Shell typecheck / appSurface 受仓库依赖缺失阻断」的说法——在原分支主工作树上两道门都干净，实际是 bf2185fba 改名 taskGroupLabels.design 后自己把 8 个用例文件断言改红，由 c6a08ef98 补修。 未并入的四条审查发现：hydrate 身份校验排在落盘投影修复之后（第 18.3 节固定顺序， session.previous.json 提升+删除不可逆）；锁竞争错误回传项目绝对路径（第 18.3 节）； design 组展示名剩两处字典未改（第 18.2 节）；阶段进度轮次差一格。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 11:11:18 +00:00
kdletters	9070c0760b	修复登录服务器切换与本地资源请求 ... - 允许 release 客户端安全访问 custom HTTPS 与本机 loopback HTTP - 修复 Tauri WebView 请求传输与无效 URLPattern - 按服务器 origin 隔离本机 External Editor 凭据 - 保留登录请求底层错误并补充路由与凭据隔离测试	2026-08-18 18:32:49 +08:00