任务模板：整理或重构状态

适用场景

• 页面状态过于分散
• 同一功能出现重复状态源
• 需要把局部状态收敛到当前模块既有状态容器
• 明确批准的小范围状态整理

开始前先确认

1. 这是普通需求里的顺手整理，还是明确批准的状态改造
2. 当前模块已经使用哪种状态方案
3. 改动后是否会影响多个页面、多个 tab 或全局行为

先读哪些文档

1. docs/01-architecture/state-management-matrix.md
2. docs/06-decisions/ADR-0001-状态管理收敛策略.md
3. docs/06-decisions/ADR-0002-新增功能默认状态方案.md
4. 对应功能文档

执行步骤

1. 画清楚当前状态的拥有者和消费者
2. 找出重复状态源和不必要的跨层传递
3. 限制整理范围，只处理目标模块
4. 保持外部行为不变
5. 回归该模块的主要交互链路

是否允许执行

可以直接做：

• 将页面内重复局部 state 收敛到当前页面已有状态结构
• 在同一模块内消除明显重复状态源
• 把散落在多个子 widget 的功能局部状态收回到该模块已有 provider 或局部状态容器

需要先补 ADR 再做：

• 将整个功能域从 Provider 迁移到 Riverpod
• 将 Redux 的登录/用户主链路挪到别的状态方案
• 修改 lib/app.dart 中的全局状态接线方式

禁止事项

• 不要把“状态整理”变成大规模架构迁移
• 不要在没有验证的情况下改动共享状态边界
• 不要同时调整状态方案和功能行为，除非任务明确要求
• 未经明确允许，不得把模块从既有框架/状态实现切换到另一套实现，即使你认为新实现更稳定或更容易修

最低验证

• 目标功能的基础回归用例
• 涉及共享状态时，额外抽查一个相邻功能
• 若动到根装配或全局共享状态，回归启动、登录态、主题/语言

输出要求

至少说明：

• 旧状态结构的问题是什么
• 为什么这次整理不属于架构迁移
• 改动后状态归属是否更清晰
• 跑了哪些回归

收尾步骤

状态整理类改动默认必须经过新的 reviewer subagent 审查后，才能对外宣告完成。 这是高 author 偏见风险任务，不允许用 author 自己的上下文直接给自己通过。