你是 Codex，在本仓库协助完成开发任务。目标是稳定推进任务并保持改动可验证。
硬性边界：
- 不修改 Claude Code 体系文件：
CLAUDE.md、.claude/settings.json、.claude/settings.local.json - 一次只做一个任务，避免顺手重构
- 仅修改当前任务直接相关文件，保持最小改动
开始任何编码工作前，按顺序执行：
- 阅读
PLAN.md，确认当前里程碑和阶段 - 阅读
TASKS.md，确认待办与优先级 - 运行
scripts/preflight.sh，检查前置条件和仓库状态 - 明确将执行的单一任务，并等待用户确认后再修改代码
- 测试优先：新功能或修复必须补充对应测试
- 类型安全：避免
dynamic、as强转、!非空断言 - 小步提交：每次改动保持可运行、可检查
- 注释规范：新增/修改的核心逻辑应有清晰中文注释（Dart doc comment）
- 权限与命令：遵循“最小必要命令”原则；禁止执行破坏性命令（如未授权的删除/重置）
完成当前任务后，按顺序执行：
- 检查测试完整性（unit / widget / integration）
- 清理死代码（含未使用测试代码）
- 检查新增或修改代码的注释质量
- 默认只运行与本次改动直接相关的检查：
flutter analyze <改动相关文件>flutter test <改动相关测试文件>- 如改动影响 integration 边界，再运行对应 integration 测试
- 仅在发版、大范围重构、跨核心模块改动，或用户明确要求时运行
scripts/check.sh - 更新
TASKS.md（勾选任务并记录完成时间） - 如里程碑状态变化，更新
PLAN.md - 输出完成摘要（任务、改动文件、测试、下一步建议）
每次任务完成时，输出至少包含：
- 实现的任务标题
- 修改文件列表
- 执行的测试与结果
- 是否执行
scripts/check.sh；若未执行，说明原因 - 用户可直接执行的下一步验证方式
- 优先保证结构清晰，不要过度设计。
- 按职责拆分，不按页面外观拆分。
- 保持单向数据流：UI 触发动作，controller 更新 state，UI 根据 state 渲染。
- UI 和业务逻辑分离，widget 不承载复杂业务逻辑。
- 优先简单、直接、稳定的方案。
- 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 表面。