mobile-redesign-app

mobile-redesign-app：分阶段重设计整个应用

方法文件，请先完整阅读：../_shared/references/redesign-protocol.md、 ../_shared/references/review-rubric.md、../_shared/references/tells.md，以及 ../_shared/references/navigation.md（用于导航审查）。

流程

1. 全面审查

先识别技术栈，再按照完整的审查标准（静态审查 + 可访问时进行实时审查），检查路由树中的每个屏幕，另外还要：

• **导航审查：**将当前路由树与 navigation.md 中的机械检查项（标签页数量/逻辑、容器选择、返回行为、深层链接）进行对照。以 Nav Read 格式输出当前路由树，以便问题能以与修复相同的格式清晰呈现。
• **设计令牌审查：**确定设计系统的位置，或确认它不存在。
• 阅读应用实际构建出的设计基调；检查平台定位的一致性。
• 编写 design-baseline.json——重设计将以此为衡量基准。

2. 模式 + 范围确认

确认保留还是全面改造（只询问一次）。然后将计划按阶段列出，每个阶段都将 redesign-protocol.md 中的一项改进应用到整个应用：

Phase 1  Tokens + type/spacing     (touches theme files + every screen mechanically)
Phase 2  Color onto semantic tokens; dark mode
Phase 3  States (skeleton/empty/error/offline/refresh) per data screen
Phase 4  Press feedback + motion layer
Phase 5  Screen recomposition (worst screens first, from the findings)
Phase 6  Navigation restructure    (ONLY if the nav audit demands it - see below)

每个阶段都要说明：已解决的发现、涉及的文件、不会改变的内容。计划只需批准一次；之后在每个阶段的节点提供检查点（简短摘要 + 前后对比），而不是重新询问。

3. 重构导航（需批准的阶段）

此技能可以提出导航更改——以当前与提议的 Nav Read 差异形式呈现，并标记每项不得悄然更改的内容（路由名称、深层链接、标签页顺序、已形成习惯的手势），附上迁移说明（重命名深层链接的重定向、状态迁移）。只有在明确批准该差异后，才能发布更改。如果导航没有问题，就说明这一点并跳过此阶段；大多数重设计都应该如此。

4. 执行

按照 redesign-protocol 的修复循环逐阶段执行：原子提交、前后对比、解决基线中的发现、在应用规模上设置风险控制（超过 20% 就停止，每次运行最多修复 40 项——大型应用需要多次运行，这是设计如此，并非限制）。运行中不得更改阶段顺序；在第 2 阶段发现一个很诱人的第 5 阶段重组方案，应记录为一项发现，而不是临时改道。

5. 收尾

重新运行审查标准 → 与起始基线进行差异对照表（这是重设计有效的证明）、列出剩余发现、更新 MOBILE-DESIGN.md（设计基调、刻度盘、设计令牌位置、Nav Read），让后续会话能沿用新系统。

硬性边界

• 全面改造模式会改变视觉语言，但未经需批准的差异，不得改变内容或信息架构。
• 对审查发现的无障碍体验改进必须进行回归测试，不能想当然。
• 每个阶段的所有屏幕都必须通过移动端审美第 14 节的预检，该阶段检查点才能算完成。