你是 Codex，在本仓库协助完成开发任务。目标是稳定推进任务并保持改动可验证。
硬性边界：
- 不修改 Claude Code 体系文件：
CLAUDE.md、.claude/settings.json、.claude/settings.local.json - 一次只做一个任务，避免顺手重构
- 仅修改当前任务直接相关文件，保持最小改动
开始任何编码工作前，按顺序执行：
- 阅读
PLAN.md，确认当前里程碑和阶段 - 阅读
TASKS.md，确认待办与优先级 - 用简单的语言说清楚要完成的任务是啥
- 测试优先：关键流程和功能必须补充对应测试
- 类型安全：避免
dynamic、as强转、!非空断言 - 小步提交：每次改动保持可运行、可检查
- 注释规范：新增/修改的核心逻辑应有清晰中文注释（Dart doc comment）
- 权限与命令：遵循“最小必要命令”原则；禁止执行破坏性命令（如未授权的删除/重置）
完成当前任务后，按顺序执行：
- 检查测试完整性（unit / widget / integration）
- 清理死代码（含未使用测试代码）
- 检查新增或修改代码的注释质量
- 默认只运行与本次改动直接相关的检查：
flutter analyze <改动相关文件>flutter test <改动相关测试文件>- 如改动影响 integration 边界，再运行对应 integration 测试
- 如改动影响 UI、路由或首启流程，且已有可用模拟器/真机，运行
Android 真机优先使用
scripts/test_maestro_android.sh自动构建、安装和测试（多设备时通过--device <adb-serial>选择）； 已安装包或 iOS 使用MAESTRO_APP_ID=<目标包名> scripts/test_maestro.sh；未运行时说明设备或 CLI 阻塞原因
- 仅在发版、大范围重构、跨核心模块改动，或用户明确要求时运行
scripts/check.sh - 更新
TASKS.md（勾选任务并记录完成时间） - 如里程碑状态变化，更新
PLAN.md - 输出完成摘要（任务、改动文件、测试、下一步建议）
每次任务完成时，输出至少包含：
- 实现的任务标题
- 修改文件列表
- 执行的测试与结果
- 是否执行
scripts/check.sh；若未执行，说明原因 - 用户可直接执行的下一步验证方式
- 优先保证结构清晰，不要过度设计。
- 按职责拆分，不按页面外观拆分。
- 保持单向数据流：UI 触发动作，controller 更新 state，UI 根据 state 渲染。
- UI 和业务逻辑分离，widget 不承载复杂业务逻辑。
- 优先简单、直接、稳定的方案。
- 函数设计要保持单一职能原则。
- 遵循 DRY 原则，优先复用项目中已有的代码、组件和工具函数。不要重复实现已有能力，避免产生多个逻辑来源，确保行为一致并降低维护成本。
- Screen/Page 负责页面组装、路由参数、读取 provider、分发回调。
- Widget 负责展示和局部交互，尽量保持纯。
- Provider/Notifier 负责状态和业务逻辑。
- Repository 负责数据获取和持久化，不负责业务流程编排。
- Model 表示业务数据，State 表示界面运行状态。Model 不依赖 State，State 可以包含 Model。
- Provider 按功能域拆分，不按组件个数拆分，也不按页面外观拆分。
- 状态只在一个 widget 树内使用且不需要跨组件共享时，用局部 state；否则用 provider。
- 一份真实状态只能有一个单一来源，避免多处维护同一状态。
- 状态变更入口要集中，只能通过明确的方法修改状态。
- 复杂流程提取为纯 Dart 类编排（可测试、可复用），Provider 负责连接编排层和 UI。
- 页面负责组装，组件负责展示。
- 不要做万能组件，避免大量 if 和模式开关。参数超过 10 个说明职责太广，应该拆分。
- build 方法只描述 UI，不做请求、不改状态、不启动副作用。
- 子组件只读取自己关心的状态，避免整页无意义刷新。
- 异步操作必须防竞态：启动时记录标识（token/sessionId），回调时校验标识是否仍有效，过期则丢弃。
- 谁创建谁销毁。资源的生命周期必须和它的所有者绑定，不能由外部隐式管理。
- 副作用（网络请求、文件 IO、平台调用）通过接口或回调注入，不在业务逻辑类中直接调用。
- 每个异步调用点都要考虑失败情况。沉默吞掉异常是 bug，应该明确处理或向上传播。
- 错误、加载、空状态必须显式设计，不要只写成功态。
- 关键环节打印出日志，方便排查、发现问题。
- 命名优先于技巧，名称必须直接表达职责。
- 目录结构优先按 feature 组织，再在 feature 内部分层。
- 先允许少量重复，确认模式稳定后再抽象。过早抽象比重复更有害。
- 优先测试状态流转和业务逻辑，不需要添加低价值的测试，比如文案。
- 为新增或修改的行为编写真正有价值的测试。
- 测试行为，不测试实现细节。
- 不测试无关紧要的 UI 细节，例如精确字号、颜色、间距或其他样式常量，除非它们属于明确的产品要求或回归问题。
- 覆盖重要的边界情况和失败路径，不要只测试正常流程。
- 在可行的情况下优先使用真实组件，避免过度 Mock。
- 修复 Bug 时应增加回归测试，该测试应在修复前失败，在修复后通过。
- 测试必须稳定且可重复。不要为了让异步测试通过而加入任意延时。
- 不要仅为了让测试通过而削弱、跳过或删除现有测试。
- 宁可写少量高价值测试，也不要写大量浅层测试。
- 不要仅为了提高覆盖率而增加测试。每个测试都应该保护重要行为，或能够发现真实可能发生的回归问题。
- 完成任务前，运行相关测试并确保全部通过。