Skip to content

test(domain): 型付きモデル lowering と kernel ソース描画の乖離を検出するゲートが無い #664

Description

@rizumita

Problem

domain 意味論には 2 つの独立した lowering 実装があり、どちらも本番経路である。

実装 出力 使うコマンド
rust/fsl-core/src/domain_lowering.rs::lower_domain_surface 型付きモデル check / verifycompose.rs:68 経由)
rust/fsl-core/src/domain.rs::domain_kernel_source .fsl テキスト domain expand / check_domain / domain testgen / domain scaffold

対応する関数が並走している(lower_effect_actionsrender_effect_actions
lower_saga_actionsrender_saga_actions)。

両者が一致することを検査するテストが存在しない。

実測: 乖離は既存ゲートをすり抜ける

PR #661#640(a) 修正)を使った反転実験。モデル側の修正だけ残し、描画側だけ
HEAD~1 に戻した
状態で domain 関連スイートを実行した:

テスト群 結果
domain_expression_characterization(baseline + domain_monitor_and_symbolic_semantics_agree 3/3 緑
domain_codegen_contract(5 ターゲット golden + testgen digest) 3/3 緑
issue_515_domain_check_false_green 4/4 緑
既存スイート合計 10/10 緑 — 乖離を検出できない
PR #661 で追加した issue_640_saga_observation_correlation 3/3 FAILED

つまり「検証したモデル」と「生成されたソース」が食い違っても、既存のどの
ゲートも鳴らない。baseline.v1.json は描画側を 4 つの部分文字列でしか照合して
いない(domain_expression_characterization.rs:482-487)。

新規テストが落ちたのは、それが domain expand(描画経路)を回してから検証する形に
設計されていたためで、その 1 規則についてのみ乖離を検出できる。一般の保証はない。

変更増幅(実測)

#640(a) の 1 規則の修正で、同じ述語を 3 箇所に適用する必要があった:

  • domain_lowering.rs::lower_saga_actions(モデル)
  • domain.rs::render_saga_actions(描画)
  • fsl-tools/src/domain.rs::actionsgenerated_actions の名前再導出)

PR #661 で規則自体は fsl_core::domain_effect_owns_event の単一オーナーに統合したが、
適用箇所が 2 実装に分かれている構造は残っている

共変更履歴(直近 12 ヶ月): domain.rs 6 コミット / domain_lowering.rs 19 コミット /
共通 3。静的には別ファイルだが、意味変更のたびに揃って動く必要がある。

局所的合理性(現在も有効)

出力の型が違う。描画側はユーザーが読める .fsl を返す必要があり(domain expand
存在理由そのもの)、モデル側は型付き AST を返す。分けること自体は妥当である。

失効しているのは「分かれていてよい」ではなく「分かれたまま一致検査が無くてよい
の部分である。

反実仮想

内容 定常コスト 移行の谷
A 現状維持 2 実装のまま 変更ごとに 2 箇所 + 乖離が無検出 なし
B 一致テスト 1 本 build_model(parse(domain_kernel_source(d)))lower_domain(d) が一致することを corpus 全 domain spec で検査 ほぼゼロ ほぼゼロ
C 描画を pretty-printer に一本化 モデル → テキストの一方向にする 1 実装 大(domain.rs 1027 行の再設計、origin span の保持、golden 全再生成)

B が優位である。C の利益の大半(乖離の検出)を、C の移行コストなしに得られる。
C は B の測定結果を見てから判断すればよい。

未検証

  • B を実装したとき、現時点で既に乖離があるか(あれば別の欠陥として切り出す必要がある)
  • 一致の粒度: アクション名・ガード・代入まで見るか、Public Kernel 射影で比較するか
  • db / ai / causal など他ダイアレクトに同じ二重実装があるか

関連

Metadata

Metadata

Assignees

No one assigned

    Labels

    ai-discoveredIssues created from scoped follow-up discoveryenhancementNew feature or requesttrack:AトラックA 健全性残債の完済(最優先・期限 2026-08-28)

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions