デモ録画やスモーク実行を担う宣言的シナリオランナーには、expect 系のアサーションステップ（テキスト一致・要素可視・件数など）を足したくなるが、次の基準で原則スコープ外とする。

判断基準

1. 上位互換の存在: 正解値の検証は成熟した E2E テストフレームワーク（expect・retry・trace・CI 統合を持つ）が専用に担っている。自作 DSL に検証語彙を足すのは劣化コピーの育成になる。「値の正しさを機械検証したい」が要件になった時点で、ランナーの拡張ではなくテストフレームワーク側に書く。
2. 語彙の増殖コスト: アサーションは一度入れると text → visible → count → attribute → URL と要求が際限なく続く。ステップ語彙がスキーマ・ヘルプ・ドキュメント・エージェント向け説明の複数箇所と同期を要する設計では、増殖する語彙は保守コストの乗数になる。
3. 判定モデルの分離: ツールが機械的に保証するのは決定的シグナル（ステップ完走、console エラー・未捕捉例外・4xx/5xx・失敗リクエストの不在）に限定し、内容の正しさは証跡（動画・ステップ別スクリーンショット・構造化レポート）を読む人間または AI が判定する。証跡を読む AI は「正しい値が表示されているか」を柔軟に判定できるため、ツール内アサーションの多くは実は不要で、中途半端に入れると「どこまでツールが保証するのか」が曖昧になる。
4. 最低限の到達保証: 要素出現を待つ wait 系ステップが「期待した状態に到達した」という弱いアサーションを既に担っており、フロー進行の保証にはこれで足りる。

命名はコミット済みスコープに合わせる

この種のモードを「qa」と呼ぶと実態より強く聞こえ、「verify」は将来のアサーション拡張を見込む場合にだけ釣り合う。拡張をスコープ外と決めたなら「smoke」のような控えめで正直な名前が適切で、スコープ固定の宣言（蓋）としても機能する。逆に拡張予定があるなら最初から広い名前を選ぶ（公開 CLI の改名は二度やると高くつく）。

落とし穴

ランタイム異常ゼロ（ok 判定）はロジックバグの不在を意味しない。間違った値が表示されていてもエラーが出なければ通る。この限界をドキュメントで明示しないと、利用者・エージェントが「QA 済み」と過信する。

検証

アサーションステップを足したくなったら、(1) 証跡を読む判定者（レビューフローの AI や人間）がその確認を既にできるか、(2) 成熟したテストフレームワークがその検証を専用に担えるか、を先に問う。両方 yes なら足さない。