flutter-smoke-autolisted

# Flutter 全自动冒烟测试（Android / iOS / Web） 从 Flutter 源码推导业务主流程 → 改造可测性 → 生成用例（移动端 Maestro flow、 Web 端 Playwright spec，共用一份契约表）→ 执行 → 分诊自愈 → **修复功能缺陷并重跑 （本次会话开发的功能）** → 出报告。人工介入点只有一个：审阅最终报告。不需要录制脚本。 配合功能开发使用时（"开发 X 并测好"），这套流程是开发完成定义的一部分： 冒烟不全绿不算开发完，红灯自动进入 Phase 5.5 的修复闭环，而不是交给用户。 ## 第 0 步：先判断场景，走错通道比慢更糟 本 skill 有三种工作场景，通道和范围都不同，动手前先判断： | 场景 | 信号 | 通道与范围 | |---|---|---| | **开发伴随**（边改边看） | 功能正在写到一半；"看下效果 / 边改边看 / 刷新看看"；UI 微调 | `flutter run` 热重载 + 实时查看（Web 用 chrome-devtools MCP），见 `references/dev-loop.md`。不建 `.smoke`、不出报告 | | **定向验证**（改完某个功能要确认它没坏）——**日常默认** | "改了 XX 功能测一下"、"开发 XX ��测好"、修完 bug 要验证 | 只跑**受影响的用例 + 冷启动那条**（选法见下面「定向执行」），build+install 照常、闸门照过、结论可信，但几分钟内完事 | | **全量冒烟验收** | 用户明确说"全量 / 提测 / 发版 / 跑冒烟"、使用 `/smoke-*` 命令、CI | Phase 0–6 完整流程，所有用例所有端 | **改一个小功能 ≠ 全量冒烟。** 全量一轮十几分钟，把它当日常验证会让人不愿意再跑测试。 日常改动走定向验证；全量留给发版/提测节点和 `/smoke-*` 命令。 但有四类改动**必须升级为全量**——它们的影响面就是全局： 路由/导航结构、全局状态管理、主题/国际化、依赖升级或 Flutter 版本变更。 **判断不了就问，不要猜**，一句话二选一： 「你是想边改边看效果（秒级热重载预览），还是功能已完成、要做一轮正式冒烟验收（构建安装包全流程）？」 例外：用户通过 `/smoke-all`、`/smoke-android`、`/smoke-ios`、`/smoke-web` 命令进入时，命令本身就是答案——全量冒烟验收 + 指定端，跳过询问直接执行。 ### 定向执行的入口（改完小功能验证就用这个，不要跑全量） `run_smoke.sh` 自带两个定向参数，选用例的推导由 `scripts/select_flows.py` 自动做 （git diff → registry 的 file 字段 → 用到受影响 id 的用例，含 subflow 反查主 flow）， 结果永远附带冷启动锚点（最便宜的全局回归保险）： ```bash bash scripts/run_smoke.sh --platform android --changed # 日常默认：按 git 改动自动圈范围 bash scripts/run_smoke.sh --platform android --only login # 手动圈范围（web 同样支持） # 只看会选中哪些用例（不执行）：python3 scripts/select_flows.