L4.13.4partial failure states progress and cleanup设计研究
部分完成的任务需说明已进行到哪一步以及是否需要清理
别名: 失败要带清理 · how far and what to undo · 残骸清单跟上报走
概念解释
失败很少发生在第一步之前。前面的步可能已经改了世界。上报如果只说缺口，人补上缺口再继续，会踩在未声明的残骸上。部分失败要说明进度和清理（partial failure states progress and cleanup）：已经做成了哪些、哪些是一半、哪些对外生效了、继续之前要不要先撤。
「从失败处继续」这个按钮，默认假设前面都是干净的。清单不在，假设就是赌。
机制
求助的三栏回答怎么继续；清理清单回答应不应该先退。两份材料不问同一件事。中止之后的对象清单是给停下来的人看残骸；这里是把残骸绑进上报，因为接上报的人往往不是点中止的那一个，也看不到过程视图。漏掉清理，下一手会把「已发出的那封」当还没发，或把一半写完的文件当空白去覆盖。
重试会把残骸变长。上报时的清单必须是重试之后的当前值，不是第一次失败时的快照。
怎么研究
让代理在对外一步之后失败。比较：上报不含已做步骤、含已做但不标能否回退、含已做且标清理建议。因变量：人是否先清理再继续、是否重复对外动作、残骸是否被当空白覆盖。自变量：接上报的人是否看过过程、清理建议是否可一键执行。
主终点是重复对外。重复了，进度就没被读成世界状态。
边界
失败在任何世界改动之前，清理为空，但仍要显式写「没有已生效动作」，避免人去找不存在的残骸。对象清单的呈现细节（一半怎么写）属于部分完成态；这里要求上报包里必须有这一份，且带「要不要清理」的建议。缺口三栏是怎么继续；不要把清理塞进「缺什么」那一栏。
怎么落地
- 上报包附对象级进度：已完成 / 一半 / 未做，对外已生效单独标，并给出「建议先撤哪些」。没有「没有已生效」的显式句，视为包不完整。
- 继续与清理是两个动作。禁止一个「从失败处继续」在未确认清理时直接跑。
- 验证：先对外成功一步再失败，把上报给没看过过程的人。若他们又对外了一次，包里就缺进度。加上清理建议后，第一动作应是撤或明确保留，而不是继续。