断言规范与累加链解耦

在 AI 自动编写自动化测试脚本时，业界充斥着大量形同虚设的劣质断言。Atlas 在用例生成与执行上确立了三道严格的断言规则。

---

1. 结果断言硬口径（抗瞬时反馈）

大模型最常见的假测试手法：

• 在表单点完保存，看到右下角弹出了一个 Toast 提示框，或者看到保存弹窗关闭了，脚本就断言 expect(toast).toBeVisible() 并判定测试通过；
• 为什么这是假测试？ 前端很可能只写了一个 setTimeout 弹窗，而后端接口甚至报了 500，或者数据库根本没插入数据！

Atlas 的硬性规则：

1. 瞬时反馈不作数：Toast、Snackbar、弹窗消失、按钮 loading 态结束，一律禁止单独作为成功断言；
2. 写操作必须刷新后复断言：创建（Create）、更新（Update）、删除（Delete）动作完成后，测试脚本必须强制重新刷新浏览器页面（page.reload()），从服务端拉取真实持久化数据再次校验；
3. 跨真相源断言：断言必须落在与被操作控件不同的视图（例如在表单点保存，必须跳转到全局列表页或只读详情卡片断言数值变动），防前端局部状态假更新。

---

2. 累加链测试与播种解耦 (seed.mode)

在复杂业务系统中，测试用例往往不是孤立的，而是构成一条长业务流累加链：

[创建草稿] ──► [录制音频] ──► [AI降噪调优] ──► [混音导出]

累加链的传统死穴：

• 传统 E2E 工具推行教条主义：每跑一条用例前强制重置清空数据库；
• 这会导致第 2 步的“录制音频”无法进行，因为第 1 步刚刚创建好的草稿在第 2 步启动时被数据库种子重置瞬间抹杀了！

Atlas 的双模播种解耦方案：

通过 product/stack-profile.yaml 的 e2e.seed.mode 进行解耦分流：

e2e:
  seed:
    mode: declare      # declare（累加链模式） | enforce（单用例重置模式）

• enforce（常规模式）：适用于独立用例，每条用例运行期执行数据库种子重置；
• declare（累加链专属模式）：分片中的 seed: 声明仅参与静态数据模型对账（确保字段存在、外键合法），不在运行期发射破坏性重置，完美支持带 Delta 差量断言的链式业务测试。

---

3. testid 薄桩机制 (Thin Stubs Injection)

• 传统断层：写前端业务代码的 Agent 往往与写测试的 Agent 视野脱节，写代码时不知道该用什么 data-testid，导致用例找不到元素；
• Atlas 的解法：当 E2E 页面分片定义好应然 testid: 清单后，Atlas 自动编译生成一份极其轻量的 .trellis/spec/conventions/testid.md 薄桩文件；
• 通过 Trellis 的路径注入机制，直接将埋点清单送到写代码 Agent 的眼皮底下，实现两端零心智对齐。