itl_expr_cli の設計

設計目標

frontend/itl_expr を、すべてのケースを結果別に列挙する JSON レポートを出すプロセスとして公開します。これにより区間のツールは、フェーズに関する主張（「これらのファイル中のこれらの演算のすべてのケースが実行可能であり成功する」）を 1 回の呼び出しで検査できます。

数学的背景

フェーズは組（ファイル $F$、演算 $O$）です。ランナーは集合 $\{ c \in \operatorname{cases}(F) : O = \emptyset \vee \operatorname{op}(c) \in O \}$ を実行し、それを成功、失敗、未対応、診断のケースに分割したものを報告します（itl_expr の設計を参照）。フェーズの厳格な判定は「失敗、診断、未対応がいずれも空」です。

設計上の判断

独自の小さなオプションパーサ

このランナーは共有の parse_common_options を使いません。ITF1788 のファイルは小さく、ツールは代わりにフェーズを並列に実行するため、シャーディングもテキストモードも持たないからです。--strict-supported、繰り返し指定可能な --operation、パスを自前で解析し、それ以外のオプションはすべて拒否します。そのため、オプションの打ち間違いが黙ってフェーズを変えることはありません。

件数だけでなく JSON のリスト

レポートはカウンタに加えて、メッセージ付きの failedIds、unsupportedIds、diagnosticIds を列挙します。区間の失敗は通常少数であり、再現には正確なケースが必要です。それらを列挙することでレポートは自己完結します。

診断は常に失敗

フロントエンドの success() はすでに診断ケースで失敗とします。ランナーが加えるのは未対応ケースに対する厳格な検査だけです。固定されたコーパス内の読み取れないデータは、除外として決して許容されません。

正しさ／不変条件

• 終了コード 0 は失敗ケースも診断ケースもないことを意味し、strict モードではさらに未対応ケースがないことも意味します。
• totalCases = executableCases + unsupportedCases + diagnosticCases かつ executableCases = passedCases + failedCases。
• 列挙される id は、各クラスのケースを実行順にちょうど過不足なく並べたものです。

却下した代替案

• シャーディング。 数千ケース程度のコーパスには不要です。
• ディレクトリの展開。 フェーズはファイルを明示的に指定する（interpreter_stages.json）ため、主張が正確に保たれます。

境界

• 精度はフロントエンドの既定値（53 ビット）に固定されています。
• 逆演算、文字列変換、シグナルは扱いません（フロントエンドの境界が適用されます）。
• テキスト出力モードはありません。