page-flow-cleanup-auditlisted

# 页面流程清理审计 ## 原则 从第一性原则开始：确认页面目的、它依赖的事实，以及必须保持为真的业务不变量。不要从机械去重或删除 optional check 开始。 好的清理会移除多余 source of truth 和无意义分支，同时保留真实的 loading、empty、error、permission 和 lifecycle 状态。 当清理可能改变用户可见行为时使用本技能。它用于区分无意义防御代码和真实的生命周期、权限、错误、空态。 不要把注释当作清理目标。只有注释错误、因代码变更过期，或描述了已删除行为时才更新。 不要在清理一个组件或 helper 后停止。对于用户请求的页面或流程，必须追踪完整流程边界和影响面后再报告完成。 本技能属于三个清理技能之一： - 用 `page-flow-cleanup-audit` 处理用户可见流程、状态所有权和业务不变量。 - 用 `necessary-code-audit` 判断 wrapper、兼容、fallback、默认值和防御代码是否必要。 - 用 `unused-code-audit` 证明删除的 helper、export 和文件是否仍有消费者。 ## 工作流 ### 1. 定义流程边界 - 命名页面/文件/功能及其用户可见目的。 - 识别入口：用户入口、主组件或 handler、hook、query helper、mutation helper、store、dialog 和外部消费者。 - 区分主流程和相邻可复用业务面。不要因为 UI 看起来相似就合并。 - 如果请求包含“无需向后兼容”或“删除防御代码”，只应用到兼容层或不可能状态 guard，不应用到真实可空业务状态。 - 建立影响面图：route、共享包、store、query key、API client、analytics event、native/web 消费者、测试/脚本，以及被流程触达的下游 app/package。 深度要求：编辑前检查边界内每个文件；每个被修改的共享 helper/type/store/query，都要检查代表性下游消费者。不要依赖单个 grep 结果或一个明显调用点。 ### 2. 找到 Source Of Truth 按以下顺序追踪状态： 1. Server/API contract。 2. Query key 和 query function。 3. Mutation 后的 query cache invalidation。 4. Local store 或 component state。 5. 派生计算。 6. UI adapter 和 presentation。 危险信号： - 多个 query 获取同一个业务事实。 - store 和 React Query 同时宣称拥有同一个远程状态。 - mutation 在多个组件里直接 invalidate 原始 key。 - “轻量 query” 复制同一个 API 来源，制造第二份 cache。 - component-local count/status 来自过期或独立 source。 推荐形态： - 一个 query helper 拥有一个远程事实。 - mutation 调用一个共享 invalidation helper。 - 除非后端有真实 count endpoint，否则 count 和 label 从 canonical query 派生。 - response type 表达边界后的保证，