検証

リポジトリは、高速な開発時チェックと、有限かつ再現可能な適合性の主張とを区別しています。コーパスに合格することが証明するのは、宣言された形式、演算、丸めモード、ターゲット、フィクスチャのリビジョンだけです。このガイドでは、各ゲート、公開された各主張が何を対象とするか、そして結果をどのように再現しトリアージするかを説明します。

検証のレイヤー

レイヤー	コマンド	目的
ドキュメント	just docs	tools/doc_quality.py（ページの網羅、API スナップショット、リンクとアンカー、バージョンと GDA に関する主張、パッケージの README.mbt.md ファイル）、続いて src/doc_examples のテスト
フォーマット	just fmt	MoonBit フォーマッタ
プルリクエスト	just pr [jobs]	フォーマットチェック、ドキュメント、--deny-warn 付きのネイティブのチェックとテスト、Python ツールのテスト、およびコミット済みの 4 つのスモークコーパス
IEEE 十進	just gate decimal [jobs]	ネイティブ、Wasm、Wasm-GC、JavaScript 上での、コミット済みの decimal32/64/128 DPD および BID ベクタ
GDA 十進	just gate decimal_gda [jobs]	パッケージとフロントエンドのテスト、続いて固定された official と official0 の .decTest コーパス
二進	just gate binary [jobs]	固定された TestFloat レベル 1 マトリクスと MPFR の証拠値
区間	just gate interval [jobs]	strict ITF1788 の全フェーズ
完全	just ci [jobs]	フォーマット、ドキュメント、4 つのターゲットすべてでの --deny-warn チェックとテスト、生成されたインターフェース、およびすべての適合性ゲート

まず関連する最も狭いチェックを実行し、リリース前に範囲を広げてください。翻訳カタログは lunadoc check によって別途チェックされ、Docs ワークフローが doc/ 以下のすべての変更に対してこれを実行します。

継続的インテグレーション

• ci.yml はすべてのプルリクエストと main へのすべての push で just pr を実行します。
• nightly.yml は quick、decimal、decimal_gda、binary、interval について just gate を並列ジョブとして毎晩およびオンデマンドで実行します。SHA-256 で固定された上流コーパスをマニフェストのハッシュでキャッシュし（ハッシュはダウンロード後にも検証されます）、各 summary.json を成果物としてアップロードするため、公開された結果はメンテナのマシン以外でも再現されます。
• docs.yml は組織の lunadoc check ワークフローを実行します。
• publish.yml はビルドし、ドキュメントゲート、フォーマットチェック、全ターゲットでの --deny-warn チェック、テストを実行した後、mooncakes に公開します。

共有の適合性ランナー

全 suite は一つの dispatcher を使います。

just conformance <build|run|smoke|plan|fetch> \
  <decimal|decimal_gda|binary|interval> [options]

decimal は独立した IEEE 十進コーパス、decimal_gda は GDA の .decTest コーパスです。binary は TestFloat と MPFR のソースを組み合わせ、interval は ITF1788 を使います。

smoke は何もダウンロードせずにコミット済みのフィクスチャを実行します。plan は決定的なタスクリストを出力します。fetch は無視対象のデータを .tmp/ 以下にインストールする前に、固定された出所を検証します。run は選択したスイートを実行します。バックエンド固有のフィルタ、フェーズ、ターゲット、strict モード、シャーディング、JSON 出力については testdata/bin_float/README.md、testdata/decimal/README.md、testdata/interval/README.md に記載されています。

公開された主張

• GDA。 144 ファイルからなる official コーパスの実行可能で正当なスカラー行 64,986 件すべてと、official0 の正当な行 16,124 件すべてが合格します。141 件の # プレースホルダ行または非スカラー行は診断上の除外であり、サポートされていない正当な挙動ではありません。
• 二進。 TestFloat レベル 1 マトリクス（シード 1）は、binary16/32/64/128 にわたる 468 タスクで 254,227,872 個のベクタを持ちます。内訳は、加算、減算、乗算、除算、平方根で 7,461,360 個、IEEE 演算の mulAdd（うち 245,329,920 個）、rem、roundToInt、32 ビットおよび 64 ビットの符号付き・符号なし整数への変換、比較 eq、le、lt、eq_signaling、le_quiet、lt_quiet で 246,766,512 個です。演算が丸め方向を用いる場合は 5 つの丸め方向で、算術演算と mulAdd では両方の極小性モードで、roundToInt と変換では exact と inexact の両方の変種で実行します。無効な整数変換はフラグのみで比較します。API が None を返す箇所で SoftFloat はプラットフォーム固有の番兵値を返すためです。MPFR の部分は、固定された平方根データの実行可能な 1,055 行と、6 つの BinaryRoundingMode 値すべての下で binary32/64/128 精度の 29 個の初等演算を網羅する、ハッシュで固定された 2,088 個の証拠値を追加します。
• IEEE 十進。 コミット済みの decimal32/64/128 DPD および BID フィクスチャは、ネイティブ、Wasm、Wasm-GC、JavaScript 上で、エンコーディング、特殊値、フラグ、コア算術、および 1,024 個すべての DPD declet を網羅します。LLVM はこのゲートの対象外です。コミット済みの初等関数オラクルは、8 つの十進丸めモードすべての下で 768 ビットの MPFR 包含区間から計算された 2,784 行を追加します。
• 区間。 strict ITF1788 の各フェーズは、選択された 4,656/4,656 件のケースに合格します：集合、関係、数値の観測、相殺、算術、初等関数コア、指数と対数、一般のべき乗、三角関数、双曲線関数、逆三角関数、atan2、FMA、整数べき、極値。逆演算は引き続きサポートされていません。

just pr が実行するコミット済みのスモークフィクスチャはこれらの部分集合です。たとえば二進のスモークは 2,451 行（TestFloat ベクタ 240 個、平方根の証拠値 3 個、整数べきの証拠値 120 個、初等関数の証拠値 2,088 個）です。

これらは有限の主張です。すべての IEEE 754 や IEEE 1788 の演算、任意のリソースサイズ、あらゆる NaN ペイロードのポリシー、将来のコーパスのリビジョンを含意するものではありません。パッケージごとの二進、IEEE 十進、GDA、区間の適合性ページに、正確なマトリクスとその除外事項が記載されています。

再現性

外部の成果物は、各コーパスのマニフェスト（testdata/*/corpora.json）でリビジョンと SHA-256 によって固定されています。ビルドはバックエンド名を付けた出力と分離されたターゲットディレクトリを使い、並列ジョブが互いに上書きしないようにしています。シャードは決定的なケースのインデックスを選択し、マージされたサマリは正確な合計と失敗した ID を保持します。大きな生成フィクスチャは複数のファイルに分割されており（IEEE 十進の公開 API フィクスチャは 1 ファイルあたり 400 テストで書き出されます）、どのツールチェーンでもコンパイルできるようになっています。

MoonBit のフロントエンドが数値の行をパースして実行します。Python はダウンロード、タスク計画、サブプロセス、ターゲット選択、集計を統括します。省略可能なオラクルが、より弱いものに黙って置き換えられることはありません。満たされない要件は明示的に報告されます。

性能の証拠はセマンティクスの適合性とは別物です。ベンチマークのマニフェストは、ベースラインのソース、依存関係、ツールチェーン、ターゲット、スケジュール、サンプル数、ばらつきの上限を固定しており、性能のしきい値が正しさを変えることはありません。性能監査とパッケージごとの性能ページを参照してください。

失敗のトリアージ

1. 失敗したバックエンドを、それを再現する最小のケース、ID フィルタ、フェーズ、シャードで再実行します。
2. パース時の診断、サポート外のケース、レガシーな分類、実行可能な不一致、インフラの障害を区別します。
3. 期待値、実際の値、フラグ、コンテキスト、ターゲット、コーパスのリビジョン、コマンドを記録します。
4. 対応するホワイトボックスのパッケージテストを実行し、欠陥がパース、算術、交換形式、集計のどこにあるかを判断します。
5. 修正後は、対象のケース、コミット済みのスモークフィクスチャ、バックエンドのゲートを実行し、最後に just pr または just ci を実行します。

Strict support を弱める、flags を捨てる、denominator を変えることで gate を通してはいけません。

リリースゲート

Publish 前に次を行います。

1. moon.mod、README.md、マニュアル、CHANGELOG.md の内容を揃える。
2. just docs と lunadoc check を実行し、生成されたインターフェースの差分を確認する。
3. 反復作業中は just pr を実行する。
4. リリース候補に対して just ci を実行する。
5. リポジトリの publish.yml GitHub Actions ワークフローを通じて公開する。

ローカルでの moon publish は Luna-Flow のリリース手順ではありません。組織の認証情報はワークフローによって提供されるためです。