1028 Commits

Author	SHA1	Message	Date
lhk229	6cbe2bd7d2	外部 API skill 文档同步 style 的提示词注入语义 ... requests-and-outputs.md 把 style 描述为只控制 deterministic post-processing， 缺了本分支加的另一半——pixelArt 会在发给 provider 的提示词末尾追加一行约束。 是文档漂移不是遗漏：OpenAPI 的两处 schema 一直是对的，连子句都写了；master 把 api-selection.md 拆成四篇时是从注入之前的版本重写的。我上轮合并只 grep 了 旧错误说法有没有复活，确认没有就收工——验证旧错误的缺席不等于验证新事实的在场。 改动限于三行，与 OpenAPI 对齐，不新造措辞。刻意不复制子句字面文本：Rust 常量 是真值源、OpenAPI 已复制一份，再抄第三份就是把同一事实摊到三处，这次漂移正是 这么发生的。文档改为指向 OpenAPI 并写明是刻意不复制。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 10:39:54 +00:00
lhk229	6b1fe0b829	到期清理复查：证伪一个假设并保留证伪它的用例 ... 怀疑长定时器挂在 dialogs 数组身份上会被无关变动不断重挂而永不触发，据此改挂到 期时刻并加 ref。为它写的回归用例（每秒一次无关变动持续到超窗）在改回数组依赖后 仍然通过——数组变化会让 effect 重跑，effect 体每次都重新判定到期，频繁变动带来 的是更频繁的判定；不变动时数组稳定，定时器正常存活。 假设不成立，撤回 useMemo + useRef 的间接层。用例保留，注释改写为它实际证明的 性质：判定必须留在 effect 体里，将来挪出去才会真的失效。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 10:26:05 +00:00
lhk229	cf41e5ae76	inline 占位补到期清理，收掉存活窗口引入的回归 ... 存活窗口把「立即刷新也能清掉孤儿占位」换掉了：剥离只在首次加载跑一次，窗口内 被保留的占位再没有东西会重新判定，页面开着就一直转。 复查发现缺的不是删除手段——requestRemoveCanvasGenerationDialog 已接入快捷键， 对 generating 会弹确认再删——而是「它已经死了」这个信号。 加一次性到期定时器，到点走与加载期完全一致的处置：移除 + 同一条文案。未采纳 标记 failed，那会被持久化且剥离只处理 generating，卡片跨刷新长期存在，与当初 选「刷新后占位消失」的用意相反。 三条实现约束：到期回调只推进 tick、判定在 effect 里用当前值重做；清理用底层 removeCanvasGenerationDialogById 而非 View 的版本（后者写历史、清选中、切工具， 是用户主动删除的语义）；本会话在途占位不靠推理豁免，靠重新判定兜住。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 10:21:11 +00:00
lhk229	c9db36b177	补齐完美像素第三处静默分支并区分两条结果文案 ... 链路复查发现两处。 遗留：成功路径拿到 result.project 后，本地占位已被删除时直接 return。不套用是 对的（删除意图胜出），但什么都不说。同一形状此前已修两处，这是第三处；既有用例 只断言「不套用」，没断言「要说话」，所以没挡住。 新引入：上次让「对账已收口 + 本地已删」沿用了「只在素材库」的文案。两种情况事实 不同——快照里没有 dialog 时服务端画布确实没有结果；dialog 已收口时服务端画布上 有结果，只是本地未同步，重新加载即可见。混用会让用户以为画布上没有而重做。 两条文案抽成常量按事实分派。 第一次回归验证只有 1 条变红，暴露出「对账已收口 + 本地已删」这条分支根本没有 用例；补上后再破坏，2 条同时变红。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 10:00:40 +00:00
lhk229	925238e221	完美像素对账改看 dialog 收口状态，网关合成响应归入未知结果 ... 对账原先用「同 ID dialog 是否还在权威快照里」判成败，而服务端成功回填时保留 该 dialog 并就地改写（置 status: idle、写 generatedLayerId），该行为另有服务端 测试钉住。判据因此反向：响应丢失但服务端已完成时，用户被告知「画布未收到结果」， 重做一遍就造出第二份，本地也看不到那个新图层。 逃过测试的原因是夹具写了 layers: []，服务端永远不会产生这个形状——测试不是漏了， 是主动为错误判据背书。修复顺序定为先改夹具、看它变红、再改判据。 判据改看 status / generatedLayerId，复用 projectHasUnresolvedGenerationDialog 的既有语义（提取为两个共享函数），不自创新判据。三态分别处置：dialog 不存在时 不再套用那份不含结果的快照。 第二处：Pingora 自造的 502/504 只有 code/message、没有 details，既不是 transport 异常也拿不到 resultPersistenceStarted，被当成确定失败跳过对账，而此时 api-server 可能已完成 OSS PUT。新增 isGatewayUnknownOutcomeError 放在 apiClient 层，只收上游 与代理三类；限流和体积拒绝仍算确定失败，否则退回反向谎报。 同时破坏两处修复后四条用例精确变红。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 09:44:38 +00:00
lhk229	cb27797a22	Merge remote-tracking branch 'web/master' into feat/pixel_art2	2026-08-03 08:18:36 +00:00
kdletters	205c47eb60	修复Runtime默认栈与任务图门禁 ... 为pending恢复和后续队列建立装箱的Tokio任务边界 同步三Director首波任务图的测试夹具 补齐Linux容器进程与Runtime栈边界文档 恢复Native shell完整默认栈测试门禁	2026-08-03 16:16:59 +08:00
lhk229	21da0c8380	Merge remote-tracking branch 'web/master' into feat/pixel_art2 ... # Conflicts: # .codex/skills/genarrative-external-editor-api/SKILL.md # .codex/skills/genarrative-external-editor-api/references/api-selection.md # docs/project-memory/shared-memory/decision-log.md	2026-08-03 07:47:17 +00:00
kdletters	04a6be5c3d	修复容器进程组清理误判 ... 区分Linux进程组中的可执行成员与僵尸进程 补齐容器PID 1不回收孤儿进程的回归测试 同步记录Tauri进程树清理的容器边界	2026-08-03 15:31:40 +08:00
lhk229	3f6a8e7a0c	补测完美像素并发闸竞争路径与 snapper 错误分档 ... 并发闸的三条竞争路径此前零测试，retry-after 在整个 crate 里只出现在生产代码 一处；snapper 四档状态码只有 GridNotDetected 被间接覆盖。 不去打满全局信号量或队列计数——两者都是进程级 static，填满会让并行跑的其他 用例连带失败，正是刚修掉的那类竞态。改为把三条路径的错误抽成构造函数直接断言 状态码、文案与 retry-after 头；路径与构造函数的对应由既有顺序守卫钉住，CAS 边界本来就有本地计数器用例覆盖。 这样覆盖的是错误形状与分档，不是端到端竞争行为；后者需要把限流器与队列计数 改成依赖注入，改动面超出补测本身，未做。 删掉 retry-after 或把 Decode 改判 500，两条新用例分别精确变红。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 07:28:07 +00:00
kdletters	53f06055a4	修复画布权威快照合并回归 ... 统一生成完成态与本地布局的生命周期合并 保留同项目权威刷新中的有效画布选择 同步生成集成夹具与真实后端完成契约 补齐画布持久化回归测试和项目记忆	2026-08-03 15:20:44 +08:00
kdletters	cf0864c956	合并远端master更新 ... 合并远端Issue 115、118、127和128修复 保留移动端创作工具门禁与本地既有提交 # Conflicts: # docs/project-memory/shared-memory/pitfalls.md	2026-08-03 15:14:31 +08:00
kdletters	d3eeaf979d	恢复移动端创作工具门禁 ... 移动端底部导航仅保留我的入口 移动端创作、项目与画布直达统一展示桌面端提示 补充移动端入口与画布阻断回归测试 纠正旧模板退役时越权扩大的移动端产品口径	2026-08-03 15:13:26 +08:00
lhk229	62c02f22ab	完美像素孤儿占位判据由结构不变式改为有界时间窗 ... 原判据依赖「活着的占位始终在内存里、永不经过 hydrate」，在单标签页下成立， 多标签页下是假的：B 标签会 hydrate 到 A 标签正在用的活占位，据此剥离，再由 B 下一次布局保存以当前 revision 合法写回把它删掉——CAS 挡不住，因为 B 不陈旧。 改为只有超过 180 秒才判定为孤儿。窗口由两侧封死：服务端最坏 30 + 60 = 90 秒 （timeout_at 强制），客户端整个 POST 被 120 秒封顶，之后必已 abort 并把占位 改成 failed 或移除。取 120 + 60 余量。 这个方案在持久化预算落地之前不成立——那时服务端最坏时长无界，任何时间窗都是 拍脑袋。时间戳复用 generationStartedAt，已自动打戳、已序列化、已 hydrate。 同时撤回此前多次记录的「加会话归属标识」方案：B 拿到不同的会话 id 推不出 A 是死是活，只能识别「不是我的」，不能识别「已经没人要了」。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 07:11:48 +00:00
lhk229	cf397644c7	完美像素持久化阶段纳入预算，服务端最坏时长收进客户端超时 ... 处理预算只覆盖到规整为止，持久化阶段无界，仅受 OSS 客户端每请求 120 秒约束， PUT 与 HEAD 各自独立计时，再加三次无超时 SpacetimeDB 调用，服务端最坏合法时长 超过 270 秒，远大于客户端 120 秒。客户端因此会在服务端仍在合法工作时 abort， 对账采样到仍在途的操作——占位还在、素材库还空，用户照提示核对什么也看不到， 重试就造出孤儿 OSS 对象。 给持久化整段套独立预算 60 秒，服务端最坏 30 + 60 = 90 秒，落在客户端 120 秒内 留 30 秒余量。独立起算而不与处理预算取 min：持久化已付出 OSS PUT 的代价，因 下载慢被砍预算、中途放弃只会留下孤儿，取 min 方向正好反了。 超时发生在 PUT 之后，对象可能已落盘，必须带 resultPersistenceStarted；handler 内该标记计数由 4 升为 5，由既有守卫自己报出。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 06:13:16 +00:00
kdletters	6fe646ba2b	修复开放Issue 115、118、127和128 ... 补齐Anthropic strict能力门控、传输schema、缓存usage和真实端点验收 隔离可选MCP服务目录失败并安全重定位局部schema引用 修复PowerShell 7环境下Windows私有ACL检查 统一角色与图标素材落库的用户prompt语义 合并权威画布快照与本地待保存或在途布局并补齐回归 同步更新技术文档、项目记忆和验证门禁	2026-08-03 14:03:20 +08:00
lhk229	cb5fdb5c94	完美像素补齐两处静默路径与缓存剥离的失败上报 ... A3-1906。对账分支发现权威快照里占位已被 completion 消费、本地占位也被用户 删除时直接静默 return。不应用快照是对的（删除意图胜出），但结论与相邻分支 一致——结果已落库，用户删掉的是占位不是素材，必须告诉他素材库多了一份。 同一形状的孪生分支在成功路径：!result.project 时提示被写在 if (hasCanvasGenerationDialogById(...)) 里面，占位不在就整段静默。改为无条件 提示、条件移除。 A4。会话缓存剥掉的占位数单独计，不并入提示计数——完美像素成功后缓存可能停留 在完成之前的版本，并入会报「上次处理未完成」的假告警。只在权威加载失败、没有 第二个来源纠正画面时才提示。已核实 isProjectReady 不挡画布渲染，该场景下用户 确实看得到一张静默少了占位的画布。 新增用例在去掉 1906 提示后失败。A4 无专用测试，理由记在 decision-log。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 05:47:01 +00:00
lhk229	c276810bff	完美像素审查第一批：补齐持久化标记、失败反馈与测试竞态 ... A1 持久化标记漏洞。snap_editor_image_to_pixel_art 对 persist_editor_generated_image_owned 用裸 ?，而该 helper 内部是 PUT → HEAD → confirm_asset_object。后两步失败时 OSS 对象已存在，错误却不带 resultPersistenceStarted，客户端 outcomeMayBePersisted 为假、对账不执行， 重试会用新 task_id 造出无从发现的孤儿对象。标记加在 helper 内部而非调用点， 边界取第一次 PUT：prepare_put_object 与 OSS 未配置都在 PUT 之前，标了是反向 谎报；PUT 自身要标，响应丢失时字节可能已落盘。 A3 失败反馈第三态。catch 尾部缺「有 dialogId 但占位已被删」分支，而删除生成中 占位是产品支持的流程。用户删完后请求才失败时 errorMessage 被整段丢弃，界面零 反馈，连对账得出的「请确认素材库」也一并丢失。 E1 测试并行竞态。对进程级队列深度做绝对断言，与相邻持有 guard 的用例并行时 随机变红，改为相对断言；同时更正该用例注释——它覆盖的是预算预检先于入队， 不是 guard 归还。 两条修复均先回退生产代码确认测试变红再恢复。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 05:33:09 +00:00
lhk229	5d86b91f14	Merge remote-tracking branch 'web/master' into feat/pixel_art2 ... # Conflicts: # docs/project-memory/shared-memory/decision-log.md	2026-08-03 04:11:18 +00:00
lhk229	a2b19773d3	完美像素刷新后的孤儿占位由归属标记收口 ... 完美像素在 POST 前把 generating 占位落库后走同步 HTTP。刷新页面会丢弃服务端 handler，画布回填不再发生；新页面 hydrate 原样还原 generating，加载期没有任何 对账，占位永久转圈且 Esc 与关闭按钮都消不掉。 写入侧无解：validate_editor_pixel_art_snap_placeholder_exists 要求占位必须已 落库，否则 409，POST 前那句 flush 正是为此存在。改为读取侧收口。 给 dialog 增加 requiresLiveSession，加载时剥离置位且仍为 generating 的占位。 判据是结构性不变量而非时间阈值：这类占位只能由创建它的会话收口，活着的那份始终 在内存里不经过 hydrate，所以从服务端读回来的必然属于已死会话。队列型链路一律不 置位——去除背景恒返回 queueState、图片生成默认入队，它们的 job 在服务端继续跑， 误清会诱发重复提交。 剥离只用于项目首次加载的两个调用点，不下沉进 hydrate：会话内 applyQueuedEditorGenerationProject 也会重新 GET 并套用，那时占位对应的操作正在 进行。提示只指路不断言，因为服务端持久化非事务，前几步可能已成功。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 04:06:19 +00:00
kdletters	d1a657b5d2	为未鉴权MCP返回接入引导 ... 保持401与Bearer挑战并提供机器可读的Key配置步骤 统一缺失格式错误和无效Key响应以避免凭据枚举 保留请求元信息并同步OpenAPI集成清单与架构文档 补充鉴权脱敏契约测试并完成本地dev栈验证	2026-08-03 12:03:50 +08:00
kdletters	6a02c7fb38	合并外部API MCP与异步生成能力 ... 基于最新master接入托管式Streamable HTTP MCP并复用External API Key鉴权 统一External v1生成任务的幂等异步提交与状态查询 同步完整Skill资源、OpenAPI契约、AI游戏客户端与Worker适配 保留game-chat生命周期与首轮调度约定并完成重基验证	2026-08-03 11:47:20 +08:00
kdletters	38c43b708a	优化游戏聊天生命周期与首轮调度 ... 新增受控 Tauri 开发启动器并在启动失败或终端退出时收束客户端进程树 修复 game-chat source hydration 与专业 Agent 已提交回复的持久可见性 统一正式任务图和 game-chat 首轮只激活策划美术程序三个 Director 限制显式首批协作合同提前激活底层 Agent 或 isolated child 同步六任务进度投影、共享契约、回归测试与项目文档	2026-08-03 11:41:59 +08:00
lhk229	80bd4b38a5	Merge remote-tracking branch 'web/master' into feat/pixel_art2 ... # Conflicts: # docs/project-memory/shared-memory/decision-log.md	2026-08-03 02:23:43 +00:00
kdletters	c00dd099e3	扩展MCP的完整Skill资源 ... 拆分外部编辑器Skill为四篇渐进式参考文档 MCP资源列表支持逐篇发现和读取Skill内容 Skill归档和manifest同步七文件清单及SHA校验 同步OpenAPI、架构文档和项目决策记录	2026-08-03 09:59:00 +08:00
kdletters	964b883466	强化game-chat五分钟首版与平台美术硬门 ... 将game-chat首版固定为美术、代码、静态检查和试玩四阶段并单轮收束。 由平台生成并登记art-spec图片，强制用于主要背景、玩家和目标的可达Canvas绘制。 为全部在途动作增加从根Run计时的300秒绝对截止和确定性失败清理。 修复代码revision归属判断，防止美术变更跳过唯一Provider写入。 将四阶段公开输出和final-reply逐条固化到聊天并更新进度投影。 补齐图片解码、路径、隐藏与不可达绕过、超时竞态及前端回归测试和文档。	2026-08-01 22:45:16 +08:00
lhk229	b91f57095d	对账文案不再断言素材库已刷新 ... 43a4e7ef7 的对账尾句写「素材库已刷新，如已生成派生图请勿重复执行」，但 refreshAssetLibrary 在 canAccessProtectedData 为 false 时直接 return，读取失败也 只在鉴权错误时弹登录框、其余一律吞掉，返回 Promise<void> 不带成败信号；它本身还是 可选 prop。三种情况下这句都是假话，而它旁边那句 Promise.resolve(...).catch() 也抓 不到任何东西——不是防御到位，是根本没有可抓的。 后果是用户读到「已刷新」却对着旧列表，判定「没有派生图，可以安全重试」，重新走回 这条修复本来要避免的重复创建，只是需要多一次失败才能到达。 改文案不改结构：刷新照旧调用（成功时用户白赚一份新列表），尾句从事实断言换成指令 「请确认素材库是否已生成派生图，再决定是否重试」，刷新失效时也成立。让 refreshAssetLibrary 返回成功标志是另一个选项，但那个 hook 多处共用，为一句文案改它 的契约不划算。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 13:09:27 +00:00
lhk229	43a4e7ef78	完美像素持久化阶段由服务端显式告知客户端 ... 上一版用 error instanceof ApiClientError 判定「结果已知」，即「服务端响应过就等于 没落库」。这个等式不成立：持久化非事务，complete_editor_canvas_generation 走 CAS 写入，冲突时经 map_editor_project_error 变成 409，403/404/400 同理。带响应的 4xx 同样可能发生在 OSS 对象、asset object、project resource 和账号素材全部落库之后。 完美像素要跑满 30 秒，用户在这期间改画布推进 revision 并不罕见。 否决了两个替代方案：所有 POST 后失败都当未知（每次常见校验失败多两次读取，且给 不可能产生素材的场景附上「请核对素材库」的不适用提示）；按状态码分类（409 确实只 来自写操作，但 403/404 和 5xx 在持久化前后都会出现，等于把猜测写进代码）。 改为服务端显式告知。AppError 新增 with_detail_field，在已有 details 上补字段而不是 整体替换，保留下游写入的 provider/message。snap_editor_image_to_pixel_art 在第一次 OSS PUT 之后的四条失败路径置 resultPersistenceStarted。客户端只对完全无响应和带该 标记的失败做对账。 配套：对账成功分支补上 hasCanvasGenerationDialogById 检查——权威快照里占位消失也 可能是用户删的，契约要求此时不应用快照不写历史，成功路径早有这道检查而对账路径漏了。 对账同时刷新素材库，否则只 GET 项目却让用户核对素材库，他看到的是旧列表。 服务端 guard 把标记钉为 4 处并要求只出现在 persist_editor_generated_image_owned 之后；客户端新增三条用例覆盖带标记对账、未带标记不对账、用户删除占位。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 12:51:12 +00:00
lhk229	adfe980110	收窄完美像素对账的触发条件与副作用 ... cc88564d4 的对账有两处考虑不周。 一、对账被套用到请求从未发出的失败上。占位创建、源图解析和 flushProjectPersistence 都在 POST 之前，它们抛的不是 ApiClientError，于是也走未知分支，用户看到「素材库 可能已存在派生图，请先确认」——请求压根没发出去，不可能有派生图。这是原谎报的 镜像版本。用 perfectPixelPostAttempted 标记划界，顺带省掉一次无意义的权威读取。 二、占位存活分支调用 applyProjectSnapshot(reconciled) 不传 action。传给该 hook 的 是 ImageCanvasEditorView 的 applyGeneratedProjectSnapshot，其 action 默认值是 generate-image，因此会写一条类型错误且受撤销保护的历史。而权威快照此刻与本地一致 （占位都在），套用它只会覆盖用户在请求期间的未保存编辑。改为不调用——这次 GET 的 用途是判定，不是同步。 顺带核实：素材库同步没有问题，applyGeneratedProjectSnapshot 内部已经 void refreshAssetLibrary()。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 11:53:36 +00:00
lhk229	cc88564d4a	完美像素未知结果先对账再定性 ... catch 此前对所有错误一视同仁：标 failed、finally 解锁、按钮恢复可点。transport 异常、abort 和 120 秒客户端超时因此被谎报成明确失败，而服务端此时很可能已经完成 OSS PUT、asset object、project resource、账号素材和画布回填，只是响应没回来。用户 按提示重试就再造一整份。这违反本功能自己立下的契约：结果未知时先 GET 权威快照， 由用户显式决定是否再次执行。 判别依据是 ApiClientError 只在拿到 Response 时由 buildApiClientError 构造， transport 异常、AbortError 和 TimeoutError 在重试判定后原样抛出。已知结果不发 对账 GET，避免每个 400 都多打一次权威读取。 未知结果先 loadEditorProject，再按占位是否存活分流：占位已被 completion 消费掉 说明这次其实成功，按快照收口并写入正常的 perfect-pixel 历史；占位仍在说明画布没 收到结果，同步快照但不写历史，文案要求先核对素材库再决定是否重试——持久化是非 事务的，对象和素材可能已落库而画布回填未完成。对账 GET 本身失败时给独立文案， 不退回谎报。 既有用例 keeps a failed perfect-pixel placeholder 原本用裸 Error 表达「服务端识别 不到网格」，语义不准且会误入对账路径，改为 ApiClientError。harness 新增 dialog-error 输出，否则对账文案不可观测。 刷新后停在 generating 的占位仍无自动收口，需要先给 dialog 增加「无 durable job 的 inline 链路」标记才能在 hydration 后对账，改动面大于本次，单独立项。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 11:44:57 +00:00
lhk229	483201b625	Merge remote-tracking branch 'web/master' into feat/pixel_art2 ... # Conflicts: # docs/project-memory/shared-memory/decision-log.md	2026-08-01 11:21:23 +00:00
lhk229	84f6d177dc	修正完美像素归属校验的 RPC 计数 ... e5fb51d1a 的提交说明与 decision-log 写「整段由 8 次降为 3 次（兜底 4 次）」， 实际是 8 → 4，兜底最多 5。漏数的是函数末尾恒定执行的 get_asset_object_by_location——它承担存储 taxonomy 的非静态门禁，成本与账号 规模无关，本来就明确保留，数总数时却被漏掉。 错因是把「全账号扫描削减 6 → 2」和「整段 RPC 总数」两个口径串了。改后按调用 逐条列出，不再只给一个需要口算的总数。 一并记下：兜底分支上同一个 objectKey 会被点查两次（ensure_editor_reference_ asset_object_owned 做归属校验一次、末尾存储门禁一次，参数相同），可合并但收益 远小于已削掉的全账号扫描，暂不处理。 计数错误不影响 deadline 修复、去重实现和测试守卫——守卫钉的是两处全账号扫描 各 1 次，该数正确。e5fb51d1a 的提交说明属不可变历史，未改写。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 11:14:31 +00:00
lhk229	e5fb51d1a7	完美像素归属校验单次取数并纳入处理预算 ... 合法 assetId 且不带 sourceResourceId 时，取得端点准入许可后到 OSS 下载之间会 顺序执行 8 次 SpacetimeDB 调用，全是裸 await，第一次真正应用 30 秒预算的是下载。 其中 list_editor_projects + get_editor_asset_library 这对全账号扫描重复了三轮： resolve_editor_reference_object_key_for_owner 内部两个子函数各扫一轮， resolve_editor_pixel_art_source_for_owner 再扫第三轮，拉的是同一份数据。 预算从 handler 入口「起算」不等于「覆盖」。deadline 是绝对时刻，早起算只让后续 余额更少；中间不检查就不会在该阶段返回 504，请求会一路走到下载才失败并返回下载 相关文案，误导排障，同时准入许可全程被这些无界调用占用，把并发闸自身变成瓶颈。 去重参照抠图入口 resolve_editor_background_removal_source 的既有范式：扫一次， 注册 ID 解析、归属校验和跨记录 assetKind 收集全部交给 _from_records 纯函数在内存 里完成。归属校验命中已登记记录即短路，只有两份记录都查不到才回落点查。老包装 resolve_editor_reference_object_key_for_owner 保持不动，它服务的是没有任何上下文 的调用方。全账号 RPC 由 6 次降为 2 次，整段由 8 次降为 3 次。 预算侧把 get_editor_project 到来源解析结束整体包进 timeout_at，超时返回 504 且 文案指向归属校验。不重复写 Instant::now() 预检——紧邻的 permit 获取已做过，且本块 首个 await 是网络 IO 不会立即就绪，不构成 timeout_at 先 poll 再判超时的陷阱。 参照 937378ab9 用 assert_function_occurrence_count 把两处全账号扫描各钉为 1 次， 并禁止该函数重新调用取数包装。后者断言调用形式而非裸函数名，否则会命中生产代码里 说明「老包装保持不动」的注释——该陷阱在编写时即由测试抓出。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 11:07:01 +00:00
lhk229	7b744840fe	修正 sanitizer 调用点计数 ... 5916b7d50 的提交说明与 decision-log 写「其余 13 个生产调用点」，静态计数实际是 14：editor_project.rs 13 处，external_editor_api.rs 1 处。原文括号里已点名 external_editor_api，数字却只算了 editor_project.rs 那一侧。 一并注明补上本端点后生产调用点为 15 个（另有 1 处在测试中，不计入）。 提交说明属不可变历史，未改写；此处只更正 decision-log。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 10:44:37 +00:00
lhk229	ad5b44b93c	完美像素按钮补齐素材类型保存门禁 ... 完美像素按钮自新增之日起未接入 isPersistingAssetKind，handler 也未复用 persistingAssetKindLayerIdsRef 同步守卫。把图层的非空 assetKind 改成另一个 非空值后，在异步资源保存完成前点击该按钮，请求会同时带上新 assetKind 和旧 sourceResourceId，后端 resolve_editor_pixel_art_snap_asset_kind 检出两者不一致 直接返回 400。 两道防护与相邻的拆分图集按钮在完美像素按钮加入前就已存在，属于新入口漏配既有 约定。disabled 只挡下一帧，同步 ref 才挡得住 setState 生效前的那一次点击，两者 缺一不可。 保存态的无障碍名称没有直接复用拆分图集的「素材类型保存中」：icon-spritesheet 图层会同时渲染两个按钮，撞名后读屏用户无法区分控件，既有的拆分测试也会因 getByRole 命中多个元素而失败。完美像素改用与「完美像素处理中」同构的 「完美像素等待素材类型保存」。 影响边界：400 发生在纯函数前置校验阶段，尚无 OSS PUT 与资源创建，不写坏数据； 用户可在资源保存完成后重试成功，代价是需要手动清理失败占位。仅当「非空类型改为 另一个非空类型」时触发。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 10:42:56 +00:00
kdletters	b7f8b31b36	优化game-chat首版生成与聊天输出 ... 将 game-chat 收束为三阶段五分钟首版快车道并补齐累计预算、恢复和完成门禁 将 Runtime 安全公开事件与专业 Agent 最终回复逐条幂等写入项目聊天 修复预览 revision 绑定、自动启动刷新、Runner 退出和 Windows 后台窗口收口 补充前后端回归测试、配置门禁和项目技术文档	2026-08-01 18:33:10 +08:00
lhk229	5916b7d509	完美像素端点补齐保留审计字段剥离 ... POST /api/editor/images/pixel-art-snaps 自新增之日起未调用 sanitize_editor_client_generation_inputs，只对 generationInputs 做了可序列化性 校验便原样写入 editor_project_resource 与 editor_asset。登录用户因此可以自行 声明 screenColorHex / mattingProvider / mattingModel，让后台 raw mapper 看到 伪造的处理元数据。 该 sanitizer 与其余 13 个生产调用点（普通图片、角色、图标图集、UI 设计、快速 编辑、抠图、上传，含 external_editor_api）在此端点加入前就已存在，属于新端点 漏配既有约定，不是设计取舍。 这三个字段是服务端产出的处理事实：screenColorHex 由背景色决策写入， mattingProvider / mattingModel 由 apply_editor_matting_metadata_to_generation_inputs 在 bgfilter 实际执行后写入。完美像素是纯几何规整、不抠图，任何 matting 元数据 出现在这类记录上本身就是伪造。 调用位置与其余入口一致：解析 payload 之后、任何 IO 之前。 影响边界：只能污染攻击者自己的记录（owner_user_id 取自 access token，不可控）， 不构成越权、信息泄露或计费漏洞，该端点 generation_cost_mud_points = 0。 sanitizer 单元测试已存在；端点接线由既有顺序断言钉住，sanitize 必须排在预算派生 及之后全部 IO 之前，被挪到 IO 之后会直接失败。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 10:31:40 +00:00
lhk229	94d5cb2f91	修正提交提示词留存条件与响应体字段的文档表述 ... d9b770e82 里两处仍然写错： 一、声称完整提交提示词「只出现在原图 OSS asset object 的元数据里」。实际 persist_editor_provider_source_image 写的是 actual_prompt.unwrap_or(prompt)： provider 未回 actualPrompt 时才存 submitted_prompt，回了就存 provider 改写后的 文本。也就是说 provider 回 actualPrompt 时，该次生成的 submitted_prompt 在系统 内一处都不落——外部 API 审计的 request_payload 只记 promptChars 字符数。原文里 「排障应按 object_key 查」这条指引因此可能指向一个不含约束句的值。 二、声称三条链路响应体都返回用户原文。图标图集返回的是 builder 构造并追加约束 句后的工程化 prompt，调用方（含外部 API v1）能直接看到绿幕子句、间距要求和本次 新增的像素约束；图标请求本身没有 prompt 字段，收的是 iconDescriptions，「返回 用户原文」对它连命题都不成立。 两处实现均与 web/master 逐行一致，本次只是让被回传的模板多了一行，无实现回归。 角色链路 submitted_prompt 可能完全不可追溯属既有可观测性缺口，已在 decision-log 记录，未改。 代码零改动。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 10:18:55 +00:00
lhk229	d9b770e829	修正像素约束句落库范围的文档表述 ... db6dbfaf9 把「约束句随 submitted_prompt 写入 editor_project_resource 的 prompt 列」写成了三条链路通用，实际只有普通图片成立。 角色形象链路的 output_prompt 在抠图成功后被无条件覆盖为「去除纯色背景」， 其原图 project resource 存的是 role_setting，因此约束句在角色的任何 project resource 里都不出现，只留在原图 OSS asset object 的元数据里。图标 图集只有原图 spritesheet resource 带约束句，透明结果和切片分别是「去除纯色 背景」与「自动拆分图集」。 错因是只读到 output_prompt 的初值赋值，没读到一百多行之后的覆盖。 同时记录：这些 prompt 列写入规则与 web/master 逐行一致，本次未改动一行。 该列同时被用户侧素材库搜索和后台素材查询页读取，却混着用户输入、工程化提示词 和派生步骤描述三种语义，由此产生的搜索污染与派生产物按源提示词搜不到均为存量 问题，需单独立项对齐，不在本次范围。 代码零改动。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 10:00:52 +00:00
lhk229	db6dbfaf94	生成风格 pixelArt 同时约束提示词 ... style="pixelArt" 此前只驱动 provider 回图后的确定性像素规整，完全不参与 提示词。但 snapper 是几何对齐器——先检测网格步长再按格重采样；provider 交 一张柔和渐变图时横纵两轴都测不到步长，生成路径用的 legacy profile 会退到 min(width,height)/64 统一网格兜底，产出的是马赛克而不是像素画。原语义等于 「随便生成什么，然后强行网格化」。 注入点固定在 generate_editor_image_for_owner 与 generate_editor_icon_spritesheet_for_owner 构造提交提示词的位置，包住既有 builder 的返回值，builder 签名和输出契约不变。登录态路由、外部 API v1、 异步 job worker 三个入口都汇聚到这两个函数，一处覆盖。 约束句按链路分三条，追加在末尾并独立成行：普通图片没有抠像底色，用 「画面为像素风格」；角色形象和图标图集生成后都要按纯色抠像，绿幕底必须保持 平整，分别用「角色主体为像素风格」和「每个图标素材均为像素风格」，都不出现 「画面」级别的像素化要求，否则与同一段提示词里既有的「纯色背景必须平整无 纹理、无渐变」互相拆台。 实测只提「像素风格」效果已可接受，因此不注入网格密度、色板色数和抗锯齿等 约束。source-guard 钉住注入排在 create_openai_ 之前——被挪到之后时产物看起来 仍然「成功」，只是静默退化成统一网格马赛克，普通测试抓不到。 约束句随 submitted_prompt 写入 editor_project_resource 的 prompt 列；响应体 返回的仍是用户原文，前端显示不变；不新增 OSS PUT、项目资源、素材记录或画布 图层。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 07:04:53 +00:00
kdletters	e1d031b86f	增加外部API的MCP与异步生成模式 ... 新增托管式Streamable HTTP MCP端点并复用外部API Key鉴权 统一图片视频音频等生成请求为幂等异步提交和状态查询 提供可发现的使用说明、OpenAPI资源及完整Skill下载包 同步更新OpenAPI契约并规定接口变更必须连带维护 适配AI游戏创作Shell的异步提交轮询与安全重试 补齐MCP方法映射、异步Worker和客户端回归测试	2026-07-31 19:48:28 +08:00
lhk229	ab7121449c	Merge remote-tracking branch 'web/master' into feat/pixel_art2 ... # Conflicts: # docs/project-memory/shared-memory/decision-log.md	2026-07-31 11:37:57 +00:00
kdletters	33ec7b2861	修复AI游戏创作长耗时与运行收口 ... 自主构建只执行正式清单任务图并移除重复静态委派 预览基础设施失败立即收口并绑定当前版本验证凭证 客户端退出前检查Runner持久任务状态并阻止忙碌关闭 修复上下文检查点恢复边界并补齐恢复测试 为全部Agent配置默认推理强度与实际重试状态展示 补齐配置、协作、预览、Runner及全量回归测试 同步技术方案、开发流程与长期决策记录	2026-07-31 18:26:35 +08:00
lhk229	6036c5664d	补记图集切片按需编码与批量持久化决策 ... 事后记录已落地的内存准入、延迟编码与累计裁剪像素上限 事后记录单事务批量确认、稳定切片标识与重放幂等边界 事后记录手动拆分改用已鉴权来源资源的三重归属断言 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 09:53:18 +00:00
lhk229	fb36a3b8d1	同步完美像素来源解析的免查路径文档 ... 补齐已鉴权来源资源直接取用 objectKey 的归属断言契约 说明跨记录扫描省略范围与保留的存储类型点查 提示前端带上来源资源 ID 以走免查路径 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 09:42:39 +00:00
kdletters	831181faec	优化 game-chat 单轮生成与聊天输出 ... 每条 Supervisor ready 输出按稳定身份固化到 game-chat 聊天框并修复 hydration 竞态。 新增 game-chat source 白名单，试玩完成后跳过发布任务并收紧完成门。 配置 External Editor API 时强制使用并引用 Canvas 美术图集，补齐前端、Rust、AppSurface 测试与协作文档。	2026-07-31 17:35:00 +08:00
k88936	386534a415	Feat/artagent 点击/右键功能 聚焦到画布上的素材 (#123) ... - 为避免prop drilling把原有的刷新画布集中到一个useContext中, 在此基础上实现画布聚焦, 并在画布agent中使用  Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/123 Co-authored-by: 王德宇 <kvtodev@outlook.com> Co-committed-by: 王德宇 <kvtodev@outlook.com>	2026-07-31 17:25:35 +08:00
lhk229	0d7a73b0b2	Merge remote-tracking branch 'web/master' into feat/pixel_art2 ... # Conflicts: # docs/project-memory/shared-memory/decision-log.md # docs/project-memory/shared-memory/pitfalls.md # docs/【后端架构】server-rs与SpacetimeDB数据契约-2026-05-15.md # server-rs/crates/api-server/src/editor_project.rs	2026-07-31 09:11:12 +00:00
lhk229	72acd0ec05	停止向用户泄露抠图模型 (#120) ... Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/120 Co-authored-by: Linghong <ink29535@proton.me> Co-committed-by: Linghong <ink29535@proton.me>	2026-07-31 16:40:43 +08:00
kdletters	9eae1a28c5	Merge remote-tracking branch 'origin/codex/ai-game-creator-app' into HEAD	2026-07-31 15:33:05 +08:00