删除的顺序本身就是契约

「我的」页极简改造：主屏只留头像、昵称和六行设置。这篇记的是第一批——先做「隐私与数据」二级页和它背后的共享删除流程。

之所以从这个"最不显眼"的部分开始，是因为它有一条硬约束：

本需求仅改变信息架构与界面位置，不以隐藏入口替代功能交付。新增二级页必须与主屏改造同批交付；二级页尚未可用时，不得先移除旧入口。

也就是说这个需求不能按"先删后补"做。任何一步先把主屏行删掉、把功能挪到一个还不存在的页面，都会留下"功能消失"的空窗——这恰好是信息架构改造最容易犯的错。顺序被固定为：先让二级页可用 → 再收敛主屏 → 最后补图标与自动检查。

删除不是一次 API 调用

全量删除是一条有先后关系、且每一步都可能失败需要重试的链路：

云端健康数据 → 公开资料与头像 → 本机对话同步 → 本机缓存 → 待重试媒体队列

这个顺序不能随便调整：

• 先删云端再清本机，因为本机缓存是"副本"。反过来会出现"本机看着已删、云端还留着"；
• 公开资料排在健康数据之后，因为它有自己的审核与文件清理逻辑，失败要单独重试；
• 清待重试媒体队列必须最后，因为它本身就是"失败队列"的清理动作。

于是把这套顺序抽成共享模块 delete-flow：模块负责顺序与失败判定，弹窗与提示通过 hooks 由页面注入。直接收益：入口从「我的」迁到「隐私与数据」时不会复制出第二套流程——新页面委托同一模块即可。

失败态不装作成功

删除最怕的不是失败，而是假装成功。本批把三类"没删干净"都显式化：

文案刻意写"云端已删、本机未同步"，而不是笼统的"删除失败"——用户需要知道哪一半完成了，否则会把已删除的数据又手动删一遍，或者以为云端还留着。

任何部分失败都不提示完成。这条写进了自检断言。

入口越浅，误触代价越大

全量删除从主屏列表行收进二级页，且必须再点一次确认面板才执行（面板里明确写"档案、记录、评估和周期将清空，不可恢复；账号仍可登录并重新开始"）。

列表行上不再直接触发全量删除——这是信息架构改造顺带修掉的一个隐患：入口深度和功能危险等级要匹配。

两个工程教训

git add docs/ 把未完成的文档一起提交了。 那次提交用了目录通配，把工作区里正在写、尚未打算提交的几份文档一起带进了提交并推送。内容没丢，但提交范围与提交说明不一致，属于"把别人未完成的改动替我下结论"。教训：提交前按文件精确 add，不要用目录通配——尤其协作者也可能在编辑的目录。

DeletableRecordType 不是 DeleteRecordType。 新模块里按直觉写了 DeleteRecordType，实际类型名是记录删除功能定义的 DeletableRecordType。差别很小，但类型检查立刻报错——这正是把删除范围类型化（而不是用裸字符串）的价值：新增一种记录类型时，编译器会提醒所有删除路径。

小结

• 删除链路的顺序是契约：副本在原件之后清，失败队列最后清；
• 流程与 UI 解耦：顺序和判定进共享模块，提示走 hooks，迁移入口不复制流程；
• 失败要具体：告诉用户"哪一半完成了"，任何部分失败都不宣称完成；
• 危险操作的入口深度要配得上它的代价；
• 信息架构改造不能"先删后补"，新路径可用之前旧路径不下线。