gda_expr_cli の設計

設計目標

frontend/gda_expr への薄くスクリプト可能なプロセスインターフェースを提供します。ファイルを読み込み、オプションを受け渡し、Python ツールがシャードをまたいで合算できるカウンタを出力し、判定を終了ステータスに符号化します。

数学的背景

実行は合成 $\text{files} \xrightarrow{\text{sort}} \text{documents} \xrightarrow{\text{filter, shard}} \text{rows} \xrightarrow{\text{execute}} \text{summary}$ です。行の選択とシャードに対するカウンタの加法性は gda_expr の設計と internal/conformance の設計で証明されています。このランナーが加えるのは、行の序数を well-defined にする決定的なファイル順序だけです。

設計上の判断

すべてのファイルで 1 回の実行

シャーディングはファイルごとではなく、全ファイルの連結・フィルタ済みの行に適用されます。したがってツールはすべてのシャードに同じファイルリストを渡すことができ、1 つのファイルがコーパスの大半を占める場合でも均衡したシャードが得られます。

プロセス境界での厳格さ

--strict-supported はここで評価されます。サマリに失敗した行がある場合、あるいは strict モードではレガシーまたは未対応の行がある場合に、終了ステータスは 1 になります。フロントエンドのサマリ自体は中立に保たれるため、プロセス内の呼び出し側は独自のポリシーを適用できます。

安定した JSON キー

JSON オブジェクトは固定の camelCase キーを使い、実行カウンタをシャードとともに入れ子の execution オブジェクトに入れます。これは tools/run_dectest_interpreter.py が集計する形に一致します。supportedCases は実行可能な行の数です。

最初の解析エラーで停止

コーパスは固定されており、完全に解析できることが前提です。解析エラーはテスト結果ではなくインフラの障害（終了コード 2）であり、その位置とともに報告されます。

正しさ／不変条件

• 終了コード 0 は failed_cases() == 0 を意味し、strict モードではさらにレガシーや未対応の行がないことも意味します。
• 引数ベクタとファイル内容を固定すれば、出力は決定的です。
• totalCases は 1 回の実行のどのシャードでも同じなので、集計の合計は和ではなくその共通の値です。

却下した代替案

• ファイルごとのシャード。 不均衡になります。1 つの大きなファイルが実行時間を律速してしまいます。
• すべての解析診断の報告。 コーパスの編集中には便利ですが、このランナーは固定されたコーパスを対象とします。それを必要とするツールのために、フロントエンドの API はすべての診断を返します。

境界

• コーパスのダウンロードやフェーズ計画は行いません（Python ツール）。
• サブディレクトリへの再帰はしません。
• decimal_gda による GDA の .decTest の意味論のみを扱います。IEEE 10 進のベクタは別のランナーを使います。