Genarrative

Files

T

lhk229 4ccfdc68f6 删除确认判据改看 marker，覆盖源准备阶段的免费占位

判据是 status === 'generating' && !perfectPixelOperation，而 perfectPixelOperation
要到源图解析/直传完成后才写入。未登记的本地图片要走 ticket → PUT → confirm，
预算上限 90 秒；这段窗口里占位是 generating、只有 requiresLiveSession、没有账本，
判据返回 true——用户删一个免费操作会被告知「已消耗的泥点不会返还」，与「完美像素
任何状态直接删、不弹确认」的决策直接矛盾。

perfectPixelOperationId marker 从占位创建那一刻就写上（operationId === dialogId
在创建时已知），判据改看 marker。marker 的语义也因此更准确：它表示「这个占位属于
一次完美像素操作」，而不是「账本已存在」。

未采纳「删掉弹窗入口」：删除入口全仓只有 requestRemoveCanvasGenerationDialog 一条，
右键、Delete、工具栏全部汇入，完美像素没有自己的删除路径可摘。「从本链路删入口」
等价于「让判据认得出本链路」，绕不开识别问题。

未采纳新增计费字段（今天唯一生产者只有完美像素，属过度设计），也未采纳判据加
requiresLiveSession（那只是换一个代理，而用短寿命字段的存在性判断长期属性正是本
缺陷的成因模式）。

连带影响已核：会话内到期清理不受影响（看的是 perfectPixelOperation 而非 marker）；
只有加载时的快照清理会豁免源准备阶段的占位，使其显示为可删的失败卡而非被静默清掉，
这与「系统不替用户删」一致。

测试夹具原本带着 perfectPixelOperation，编码了与判据相同的错误假设，结构上覆盖不到
这个窗口。夹具补上 marker 还原真实形状，并新增「只有 marker、尚无账本」用例，回退
判据后报 expected true to be false。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-05 12:25:17 +00:00

decision-log.md

删除确认判据改看 marker，覆盖源准备阶段的免费占位

2026-08-05 12:25:17 +00:00

development-workflow.md

资源卡依赖关系及类型分类预览 (#129 )

2026-08-05 19:15:46 +08:00

document-map.md

合并最新master分支

2026-07-20 16:08:24 +08:00

handoff-template.md

整理项目记忆与Agent RAG入口