同步专题文档中已被推翻的完美像素契约

近五个提交连续翻转了多条前端契约，但只追加了 decision-log。专题文档是这些条目自己声明的「关联文档」，其中仍写着旧契约，按它做验收会把当前正确行为判成缺陷。更正：请求快照写入占位并 flush 布局 → 账本写本机、布局只留 marker；strict layout save 预算与 revision ACK 前 POST 为零 → 通道已删除，改 best-effort，并写明服务端要求占位此前已持久化否则 409、客户端无法证明只能提高概率；窗口从快照写入起算 → 从 POST 发出时刻起算；POST 前必须取得保存成功确认 → 保存失败不再让 POST 为零；未收口 operation 不可删除、durable operation 不得被普通删除路径清理 → 任何状态可删且不弹确认。新增不变式：标记与账本寿命必须对齐，收口态不写标记也不判无效；账本读不到时只有未收口占位收口成可删除失败态；恢复必须覆盖孤儿账本，孤儿走一次确定性的读、不按 reconcileUntil 短路。「普通按钮不得创建第二个 operation」保留为已知缺口而非静默删除：该保证只由 existingOperation 闸提供，而它只扫内存 dialog 列表，占位可删之后删掉再从源图发起会产生第二个 identity。文档如实描述现状并标注闭合方向，代码侧未修。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-05 08:51:27 +00:00
parent 4515bbcff6
commit ef1807e350
2 changed files with 13 additions and 4 deletions
@@ -6419,3 +6419,12 @@
 - 同步更新的文档：本文件上一条的错误声明已就地更正；`docs/technical/【前端架构】图片画布编辑器MVP接入方案-2026-06-11.md` 中「strict layout save 60 秒预算 / strict revision ACK 前 POST 为零」「未收口 operation 不可删除、不写 delete-generation-result 历史」「durable operation 不得被普通删除路径清理」等已被近几个提交推翻的条款一并修正。历史 commit message 只能靠重写 Git 历史才能改动，不为此改写历史，以本条追加说明为准。
 - 验证方式：两条受控时钟用例分别覆盖首次提交与 exact retry——让 pre-POST flush 期间时钟前进 90 秒（超过整个 75 秒窗口），断言 POST 那一刻账本里是刚建立的完整 75 秒窗口、`submittedAt` 等于 POST 时刻、账本仍只有一条、`taskId` 与 `request` 逐字节未变；retry 用例另断言 flush 期间 dialog 上挂的仍是旧 `submittedAt`，证明窗口没有被提前刷新。两条用例均已实证：回退修复后报 `expected 1800000000000 to be 1800000090000`。运行 `npx vitest run src/components/image-editor src/components/platform-entry`、`npm run typecheck`、`npm run lint:eslint`、`npm run check:encoding`。
 - 关联文档：`docs/technical/【前端架构】图片画布编辑器MVP接入方案-2026-06-11.md`。
+
+## 2026-08-05 专题文档补齐同步：账本位置、窗口锚点、删除权与孤儿对账
+
+- 背景：近五个提交连续翻转了完美像素的多条前端契约，但只追加了 decision-log。`docs/technical/【前端架构】图片画布编辑器MVP接入方案-2026-06-11.md` 是这些条目自己声明的「关联文档」，其中仍写着已被推翻的旧契约，实现与验收依据互相矛盾——按旧文档做验收会把当前正确行为判成缺陷。
+- 已更正的条款：①「请求快照写入占位并 flush 布局」→ 账本写本机 `perfectPixelOperationStore`，布局只留 `perfectPixelOperationId` 标记；②「strict layout save 60 秒预算 / strict revision ACK 前 POST 为零」→ 通道已删除，改为 best-effort flush，并写明服务端要求占位此前已持久化（否则 409）、客户端无法证明该前置只能提高概率；③「`submittedAt / reconcileUntil` 从快照写入起算」→ 从 POST 发出时刻起算，首次提交与人工重试同口径；④「POST 前必须取得布局保存成功确认，否则 POST 为零」→ 保存失败不再让 POST 为零；⑤「未收口 operation 不可删除、不写 `delete-generation-result` 伪历史」与「durable operation 不得被普通删除路径清理」→ 任何状态可删且不弹确认，确认只对计费生成成立；TTL 豁免（系统不替用户删）与用户主动删除是两回事。
+- 新增到文档的不变式：标记与账本寿命必须对齐——收口态占位不再写出标记，也不得因「有标记、没账本」被判无效；账本读不到时只有**未收口**占位收口成可删除失败态。恢复必须覆盖孤儿账本，孤儿走一次确定性的读而非轮询，不按 `reconcileUntil` 短路，三种结论的提示口径与清账本规则一并写明。
+- 保留为已知缺口而非静默修正：「普通按钮不得创建第二个 operation」原文是绝对断言，但该保证只由 `existingOperation` 闸提供，而它只扫描内存 dialog 列表；占位可删之后，删掉再从源图发起会产生第二个 identity。文档改为如实描述现状并标注缺口与闭合方向（让本机账本参与防重），代码侧不在本次范围。文档的职责是描述系统实际行为，写一条做不到的保证比留一个标注清楚的缺口更糟。
+- 影响范围：仅文档。不改代码、不改测试。
+- 验证方式：`npm run check:encoding`；核对文档中不再残留「布局保存成功确认」「strict revision ACK」「从快照写入起算」等已推翻表述。