298 Commits

Author	SHA1	Message	Date
lhk229	c489c92084	修复澄清自由输入把整页打进 error boundary ... 澄清卡片的自由回答输入框在 setAnswers 的 updater 里读 event.currentTarget.value。React 在事件派发结束后会把 currentTarget 置空，而 updater 要等渲染阶段才跑，读到的就是 null，抛出 "Cannot read properties of null (reading 'value')"。异常出在渲染阶段， 被 AuthenticatedClient 的 error boundary 接住，整页被换成 "客户端页面加载失败"。 手动输入、以及先选中选项再删除填充文本，走的都是这一个 onChange。 改成在事件里先取出 value 再交给 updater。新增的回归测试在 StrictMode 下渲染卡片（与 main.tsx 一致），覆盖这两条路径。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-23 15:36:02 +00:00
lhk229	1335b64d6b	策划区合成一个面：阶段进度当标题栏，审批卡头去掉重复的状态与指纹 ... 阶段进度条和审批卡原本各带一圈边框叠在一起。「立项策划 / 待审批」在进度条和卡头 各画一遍，「v1」在进度条、卡片 meta 行和批准按钮上出现三次，卡头还露一截 12 位的 指纹——那是开发者核对用的，用户不需要。 新增 PlanGddSurface 做外壳：边框和圆角只画在它上面，进度条成为标题栏，审批卡成为 正文，卡头只剩游戏标题和一句话。meta 行整行删掉：版本在标题栏和按钮上都有，决定 数就是下面那张清单本身，指纹整条搬进「查看 GDD 正文」弹层底部做追溯。两个挂载点 改成只挂这一个组件，可见性判据抽成两个小函数供外壳和两块子件共用，不再各自拼装。 做游戏工作台原先给卡片设的高度上限和内部滚动挪到外壳为 flex 子件、卡片为可滚行， 行为不变。 新增一条 appSurface 用例（A/B：换回旧卡片即红）：状态与版本只在标题栏；卡内没有 「立项策划」「待审批」「版本 v1」「指纹」；弹层底部有完整版本与指纹。 styles.css 在基线就不符合 prettier，本次只改相关规则，不整文件重排。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-23 14:47:01 +00:00
lhk229	e57d81454f	合并 master：首页创作类型选择器接管做方案入口，startMode 改为派生 ... master 这 22 个提交里有一处和本分支正面撞车：它把首页那枚选择器做成了三类型 （做游戏 / 做素材 / 做方案，HomeCreationType），而本分支此前把同一枚控件砍成了 两项（做游戏 / 做方案）并直接用它当路由（ProjectStartMode）。做素材必须与 master 一致，所以取 master 的三类型控件，startMode 不再是独立状态，改为从 creationType 派生：doc → planning，其余 → direct-build。两个字段在 LauncherProjectContext 和 HomeDraft 里并存，creationType 记入口原始类型，startMode 记链路路由。 五处冲突的处理： - app/types.ts、useHomeProjectCreation.ts：creationType 与 startMode 并存，调用 顺序统一跟已自动合并好的函数签名走。 - view/home/index.tsx：选择器整段取 master，删掉本分支已无人引用的 HOME_START_MODES / HOME_START_MODE_ITEMS，startMode 就地派生。 - SupervisorChatOnlyView.tsx：master 新增的 directCodex 活动时间分支保留，内层 runtime 换成本分支的 projectedRuntime；master 那句 `!directCodex && synchronizingAcceptedRun` 是冗余的（合并后 synchronizingAcceptedRun 的定义里已经带了 !directCodex），它重复声明的 activeCollaboratingRuntimes 也丢掉——上面已经声明过一次。收束判据取本分支的 runtimeTerminal / descendantsStillActive。 - styles.css：master 的聊天气泡样式与本分支的审批卡高度上限互不相干，都留；补上 master 最后一条规则缺的闭合括号（它原本借用冲突块外那个共用的 }）。 两处测试跟着改： - appSurface/harness.ts：afterEach 补一次 useLauncherHomeDraftStore.reset()。 首页创作类型存在 module 级 zustand store 里，跨用例不会回到初始值；合并后建项 按钮的文案依赖它（做方案 → 进入立项策划），上一个选过做方案的用例会让下一个 找不到「开启创作」。合并前 startMode 是组件 useState，这个泄漏看不出来。 - appSurface/home.suite.ts：master 新增的用例在选中做方案后仍按「开启创作」找 按钮，改成「进入立项策划」——本分支有意在这一档改了文案，suite 里本分支自己的 用例也是按这个口径找的。 验证：npm run typecheck 干净；eslint 改动文件零告警；cargo check --all-targets 通过；appSurface 403/403。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-23 12:33:56 +00:00
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
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	a8f3793865	审批观察不再抢提交点的幂等键，做方案链路能收束了 ... project_generic_submit_runtime_observation_locked 把 currentAction 改写成 「Fast GDD 审批观察已落盘」，然后用 pending.action_id 调 append_game_creator_agent_runtime_task_projection_once。但那把幂等键是 (runId, actionId, phase)，提交点已经在 phase=completed 上用同一个 actionId 写过一条 currentAction=「Fast GDD v1 已完成 create-only 提交」。三项全同即判为 同一条投影，9 个比对字段里 currentAction 不同 —— 必然硬报错，不是偶发。 后果是撕裂写：报错发生在 standalone pending 已经被改成 observed-approved 之后， v4 batch 还停在 ready/executing。两个恢复锚点从此不一致，恢复扫描只认原始 executing 形状，把策划子 Run 打成 needs-reconciliation；而重放路径的 phase == "completed" 闸门又因此永远过不去，撕裂再也修不回来。做方案链路的审批 因此从来没有成功过一次。 改法是让审批投影沿用提交点的 currentAction。9 字段全同，helper 视为重放直接 返回 Ok，链路继续往下推进 batch、清锚点、唤醒。审批这件事由 gdd_decided 审计 记录和 plan.submit_gdd.observed 事件承载，本来就不需要再占一条 task 投影—— 全仓库另外 9 个调用点都是「一个 action 一条投影」，只有这里想写第二条。 同一处还补上诊断。project_receipt_locked 里 13 处失败原本全部塌缩成一个 recovery_pending bool，其中两处是显式 let _ = error; 丢掉错误原文。receipt 已经 是用户决策的线性化点，这些失败都不能报成命令错误，于是唯一逃出来的症状就是 recoveryPending=true —— 说不出是哪一步、为什么。真因就是这样被藏了整条链路。 现在每处先写一条 agent.runtime.plan.gdd_projection_gap 记录再置位，带 step 标签 和脱敏后的错误原文；记录是 best-effort 的，诊断不能把已提交的 receipt 变成失败。 真机验证（gpt-5.6-luna，未开 GUI）：turn outcome=settled、 reconciliationAgentCount=0，state/phase=approved、approvedGddRef.version=1、 recoveryPending=false、两个锚点残留 0/0、project-planning 终态 idle/completed、 gdd_projection_gap 0 条、game/fast_gdd.md 落盘。修前同一条链路 2/2 复现 needs-reconciliation。 顺带给 buildCargoCliArguments 加 --quiet，压掉每次 spawn 重印的 cargo 进度行。 注意它不压 rustc 警告，只在重新编译时才有区别。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 10:34:40 +00:00
lhk229	adfa6ed8d3	做方案链路补无头审批入口，不再只能靠 GUI 拍板 ... decide_game_creator_plan_gdd 此前只有 Tauri command 一个入口，无头跑 --plan 到审批卡就永远收不了尾。补两条 CLI： - --plan-gdd-status <项目路径>：只读投影 - --plan-gdd-decide <项目路径> <approve|revise|reject> [--response-id] [--stdin] 审批卡的 identity 由 CLI 自己 hydrate，不让调用方手拼 gddId/fingerprint—— 拼错的后果是 PLAN_STALE_APPROVAL，而不是一条能读懂的用法错误。hydrate 抽成 hydrate_game_creator_plan_gdd_state_for_path，GUI 与 CLI 共用同一道权限闸。 swarm 测试脚本的审批必须和 CLI 并发做：Run 停在审批位时状态是 waiting-for-user-input，而 swarm CLI 恰好把这个状态算作「本轮还在跑」，turn 永远不 settle、CLI 也就永远不退出。等 CLI 退出再审批那一步根本到不了，实测 是干等到超时。改成认「等待 Fast GDD 审批决定」这条投影文案触发。并发子进程 单独跟踪，不占 activeChild 槽位，否则 Ctrl-C 杀不到 CLI。 decide 回执带 recoveryPending 时补一次 --agent-resume：审批回执落盘和唤醒 后台任务是两件事，唤醒失败被降级成 recoveryPending，审批已生效而 Run 仍停在 等待位，实测只有补这一次恢复才会重新起 turn。 真机验证：影子机器人解谜需求跑通到 state=approved、approvedGddRef.version=1、 game/fast_gdd.md 落盘，全程未开 GUI。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 09:45:34 +00:00
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
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	276606fc70	修正无头应答器收 stdin 的时机 ... CLI 的 REPL 是「先打印提示符再读行」，所以第一个「你>」出现时本轮还没开始跑：它 就是用来读我们这条任务的。在那里收 stdin，等确认卡弹出来已经是 EOF，自动应答器 根本没机会回 approve，一轮真实跑就这样收在 pending-confirmation。改成按提示符计 数，投递之后的下一个提示符才收口。 同时补上原本缺的那条：总控可能判定直接回复而不起持久 Run，那条路径没有 turn 回 执，只等回执会一直干等到超时——实测白等了十分钟。提示符收口对两种情况都成立。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 08:49:40 +00:00
lhk229	af1fc63de2	无头立项策划默认按五分钟设计目标收口 ... --plan 之前吃 --task 那条 50 分钟的默认上限，那是做游戏链路的量级。立项策划 的设计目标是五分钟出方案，给一分钟余量；再久就是卡住，早失败比让 harness 空 等更有用。显式 --timeout-minutes 仍然压过默认值，做游戏链路不变。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 05:38:14 +00:00
lhk229	5100c18fba	新增立项策划链路的无头入口 ... `--swarm-chat` 加 `--plan`，把新根 Run 绑定到 project-supervisor-plan standard 档，和 GUI「做方案」按钮走同一条门禁；与 --autonomous-game-build / --game-chat-smoke 互斥，非总控父 Agent 拒绝。plan 与做游戏同为 standard 档， 只按 profile 匹配会串链，因此 plan 入口按 source 精确认领自己的 Run。plan 根 Run 不接受 steer，无头入口把 source 交给后端才能触发既有否决，其余入口维持 不带 source 的旧行为。 harness 侧 --plan 跳过游戏产物验收和试玩，改为报告策划产物落盘清单。立项策划 跑 standard 档，agent.delegate 这类动作按项目权限策略必须逐个确认，而确认只从 CLI stdin 读；自主构建档没有这一步，所以只给 --plan 加一个 stdin 应答器，确认 本身仍然走后端确认命令。做游戏链路不受影响。 真实无头跑已验证：plan 根 Run 正常起来，source=project-supervisor-plan、 runProfile=standard，两个 agent.delegate 确认卡自动批准并进入委派。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 04:39:54 +00: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
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
lhk229	c6a08ef98f	修复M1D前端文案回归断言 ... 同步立项入口与设计实现组展示文案的测试期望 恢复Frontend tests与Native shell tests中的前端测试覆盖	2026-08-18 09:35:28 +00:00
lhk229	bf2185fba0	完成M1D-2入口分流与阶段进度 ... 游戏新项目默认进入立项策划并保留直接开建路径 项目总控页面挂载GDD审批卡与阶段进度 同步策划展示名称、定向测试与开发日志	2026-08-18 09:11:38 +00:00
kdletters	1e9d74fa4a	增加登录服务器选择 ... - 登录页支持 release、dev 和 custom 服务器 - 持久化服务器选择并统一登录与平台会话请求地址 - 校验自定义服务器 origin 与 HTTPS 安全边界 - 补充前端、AppSurface 和 Rust 平台会话测试	2026-08-18 13:46:03 +08:00
kdletters	bdf7ed288a	放宽直连游戏验收并增加运行时素材证据 ... - 将固定四切片与固定 drawImage 降为推荐路径 - 在导航前注入 Canvas/WebGL 平台素材运行时观测 - 对缺少核心素材渲染证据的 desktop/mobile 视口回灌同一 Codex thread 整改 - 补充直连验收、浏览器脚本与真实 Chrome fixture 测试 - 同步 AGC 直连 Runtime 实施计划	2026-08-18 13:14:45 +08:00
kdletters	94200a3cdb	修复AGC直连聊天持久化与生成竞态 ... 持久化直连用户消息和最终安全回复，并在重开项目时恢复 补充直连聊天与工作台验收回归测试 直连美术生成和版本登记等待项目写锁，避免首轮生成被聊天保存阻断 同步直连 Runtime 实施计划	2026-08-17 20:11:22 +08:00
kdletters	286c402a4b	修复运行时设置弹窗背景与滚动 ... 设置弹窗打开时锁定页面滚动并在关闭后恢复原状态 将弹窗、提示条和底部状态区改为不透明实色背景 补充设置弹窗滚动锁定与恢复的界面回归测试	2026-08-17 19:03:50 +08:00
kdletters	f30e6e9f33	修复智能创作鉴权提示可读性 ... 分隔产品名称与直连运行时错误原因 同步更新直连错误投影测试	2026-08-17 15:35:13 +08:00
kdletters	7ecc9f4971	合并平台账号编辑器 API 分支 ... 登录态接入平台编辑器生成接口 普通用户隐藏外部编辑器高级配置 保留陶泥儿直连运行时生成反馈	2026-08-17 15:20:19 +08:00
kdletters	5ea453d5d1	收口AGC单窗口启动 ... 取消开发态自动打开 Agent 聊天窗口 统一客户端可见标题为陶泥儿 同步启动守卫、测试与技术文档	2026-08-17 14:32:13 +08:00
kdletters	08bca001a2	修复AGC直连创作反馈与资源预览 ... 直连运行时推送陶泥儿美术、代码与版本登记阶段进度 资源管理首屏预取可预览资源并补齐回归测试 同步直连运行时实施计划和团队决策记录	2026-08-17 13:17:14 +08:00
kdletters	81a35e0bff	让AGC登录后直接使用平台编辑器API ... 普通客户端使用陶泥儿登录态访问站内编辑器、素材与生成状态路由 隔离standalone高级模式的External URL与Developer API Key配置 同步GUI与Runner的平台会话、可信服务origin和鉴权代际 绑定生成账本owner并阻断登出或换号后的旧请求落盘 修正本地图片上传确认、项目资源登记和sourceReferenceId链路 区分401登录刷新与403权限不足并保留原幂等恢复语义 补充后端客户端幂等命名空间、稳定结果投影和图集请求头 更新AGC界面测试、Rust契约测试及项目技术文档	2026-08-17 10:43:08 +08:00
kdletters	647cf82cec	实现AGC直连运行时与陶泥儿美术闭环 ... 新增直连 Codex 项目聊天、会话恢复与可读错误反馈 接入陶泥儿规范图、背景、固定四切片并校验实际渲染 同步游戏代码资源分类、项目版本 revision 与外部编辑器契约	2026-08-17 09:57:31 +08:00
kdletters	f69d9a2e11	Merge remote-tracking branch 'origin/master' into codex/agc-runtime-generation-reliability ... # Conflicts: # apps/ai-game-creator-shell/src-tauri/src/project/manifest.rs # apps/ai-game-creator-shell/src/features/app-shell/useHomeProjectCreation.ts # apps/ai-game-creator-shell/tests/appSurface/project-development.suite.ts	2026-08-15 15:20:30 +08:00
kdletters	dedff81475	修复AGC无人值守生成阻断的交付收口与验收 ... - 可信 code-prototype 父 Run 认领并观察直属美术 delivery，普通失败立即收束，合法安全默认 marker 由 Runtime 确定性执行唯一同合同返工 - 补齐 suppressed 无 child 与父身份链丢失时的 completion 失败关闭边界 - 修复 Windows project.lock delete-pending 竞争并收紧 HTML 内联 JS 语法 fail-open - 同步技术方案、决策记录与实施计划，并完成确定性及真实 Provider 分层验证	2026-08-15 15:12:05 +08:00
lhk229	f45db359bd	合并最新 master 到 feat/five_min_design，并修复 master 的 Windows 构建中断 ... master 侧 5 个提交（8e78be766..9f5c84ee7）。仅一处冲突： src/view/home/index.tsx 的 react import——我们这侧对该文件只有 prettier 格式化 改动，master 新增的 useRef 在合并后正文里用了 2 次，取 master 那行。 修复 master 带来的 Windows 构建中断（E0658）： project/manifest.rs 的 #[cfg(windows)] 分支用了 std 未稳定 API `MetadataExt::number_of_links`（rust-lang#63010），而 rust-toolchain.toml 锁在 stable 1.96.0。该文件与 origin/master 逐字节相同，即 master 自身在 Windows 上就 构建不过——Linux CI 上 #[cfg(windows)] 整块不参与编译，所以 CI 全绿。 改为本仓库既有写法：自声明 ByHandleFileInformation 调 GetFileInformationByHandle （另见 runner/endpoint.rs、tool_plan_handoff/storage_windows.rs 等六处）。保留原 错误文案与 fail-closed 语义（取不到句柄信息与确实是硬链接同等拒绝），并按 endpoint.rs 先例一并拒绝 directory / reparse point。 该修复目前只在本分支，须回流 master，否则下次合并会再撞一次。踩坑记录见 pitfalls.md 2026-08-15 条。 验证： - cargo check --offline --all-targets 通过（修复前 E0658，修复后 Finished） - cargo fmt --check 通过 - 定向 Rust 测试 project::manifest / godot / static_delegate / collaboration::static_deliveries 65 passed / 0 failed - agc:typecheck 通过；check:encoding 通过（5376 files）；git diff --check 干净 - 前端 vitest apps/ai-game-creator-shell/tests：738 passed / 1 failed，唯一失败是 已知的 Windows symlink EPERM（agentSwarmTestEntry），非本次回归 两条既有环境失败，已核实与本次合并无关： - command_exec::tests 两条报「找不到受信任的 rg 可执行文件」，该文件相对合并基线 逐字节相同 - npm run check:native-shells 在合并前的 master worktree 上失败得一模一样 （spawnSync npm.cmd EINVAL，脚本 spawn npm.cmd 未带 shell: true） Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 05:37:00 +00:00
kdletters	9f5c84ee71	重构AGC项目管理界面 ... 参考成熟桌面项目管理器重构紧凑项目表、搜索和行尾菜单 支持Windows路径及Godot根目录和一层子目录工程识别与导入 修复1280×720页面溢出、列表滚动和末行菜单裁切 补充项目页回归测试、PRD、技术方案和项目记忆	2026-08-15 11:43:58 +08:00
kdletters	578f8019fc	优化AGC项目入口并识别Godot工作区 ... 项目页只保留打开项目和新建项目并统一原生目录选择 按根目录及一层子目录识别project.godot并记录相对Godot根 保持.agent位于用户选择的工作区根并补齐Windows构建门禁 补充响应式布局、测试、技术方案和共享项目记忆	2026-08-14 21:53:43 +08:00
lhk229	4d3f87cd39	修复完美像素无法识别自身产物的网格 (#169) ... 边缘 profile 用的是跨度 2 的中心差分，硬块边界落在列 b-1|b 之间时 profile[b-1] 与 profile[b] 逐位相等：两者跨的是同一条边，逐行被加数 相同、求和顺序相同。峰值判定两侧都用严格大于，会把这个 2 宽平台的 两端一起丢掉，于是最干净的输入反而 0 个峰、被判为未识别到网格—— 完美像素处理不了自己的输出。 estimate_step_size 左邻比较放宽为 >=，右邻保持严格 >：平台只保留 一个索引，且是右端，正好是左闭右开语义下的真实块边。两侧都放宽则 会把长度 K 的常数段整段判为峰。 walk 与 snap_uniform_cuts 的 argmax 同样改为 >=，取等值段的最后一 个索引。取第一个会让每条切线落在真实边界左边 1px，每个 cell 因此 混进 1/4 的邻块。实测在 266x253 的最近邻放大像素画上，切线命中真实 块边从 2.6% 升到 98.5%，左右镜像、上下翻转、180° 旋转下一致；龙图 内容区内 134/134 全中。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/169 Co-authored-by: Linghong <ink29535@proton.me> Co-committed-by: Linghong <ink29535@proton.me>	2026-08-14 20:42:58 +08:00