実行レポート

コマンドラインインターフェース（CLI）の実行ごとに、結果の隣にレポートが書き出されます。印刷可能な HyperText Markup Language（HTML）ページの <scenario>.report.html と、同じ内容の機械可読な JavaScript Object Notation（JSON）ドキュメントの <scenario>.report.json です。レポートはあらゆるシナリオ種別とキャンペーンで機能します。

kshana scenarios/clock-holdover.toml
# wrote scenarios/clock-holdover.result.json, scenarios/clock-holdover.chart.svg,
#   scenarios/clock-holdover.report.html, and scenarios/clock-holdover.report.json

結果ドキュメントは、エンジンが何を計算したかに答えます。レポートは、それに基づいて行動する前に読者が必要とするもの、すなわち何が入力されたか、数値が何に基づいているか、何が除外されたか、同じバイト列を再び得る方法を加えます。レポートがこれらを創作することはありません。すべてのセクションは、エンジンがすでに保持している情報源から読み取られ、引用するものの隣にその情報源が示されます。

ビルダーは kshana::advanced_report（src/advanced_report.rs）です。これは、実行出力、シナリオファイルのバイト列、コマンドラインのみに依存する純粋関数であり、時計、ファイル、ネットワークのいずれも読まず、WebAssembly 向けにもビルドされます。

セクション#

列挙するものがないセクションは、その理由を一文で述べます（たとえば「No timed event: the scenario scripts no window or onset time and the result reports no event」）。空のまま何も言わないセクションはありません。

レポート内のラベルの意味#

検証ラベルは、マトリクスの行に記された機能を、マトリクスの記録どおりに格付けします。シナリオの設定を格付けするものではなく、VALIDATED の行があっても、実行の入力が測定値になるわけではありません。PARTNER の行は、その実行が依拠していて Kshana が提供しない領域（無線周波数の種別ではアンテナハードウェア、量子の種別では量子ペイロード、姿勢バジェットでは宇宙機バス）であり、レポートでは依拠するが提供はしないものとして示されます。

種別から行への対応表は、マトリクスの requirement 文字列の表です。ラベル、オラクル、エビデンスは、レポートの作成時にマトリクスから読み戻されるため、行を VALIDATED と MODELLED の間で動かすと、すべてのレポートがそれに従って動きます。キャンペーンは、そのモード（チェーン、スイープまたはモンテカルロ、コンポジション）の行に加え、実行したすべての構成種別のすべての行を持ちます。sweep-nd は、スイープした種別の行を持ちます。また、すべての実行は「Reproducibility & software assurance」の行も持ち、再現性の記録はこの行に基づいています。

種別の入力経路の一つのみを格付けする行は、実行がその経路を通った場合にのみ記載されます（advanced_report::PATH_GATED_CAPABILITIES）。orbit と ephemeris は、「Orbit propagation & determination」の行を tle がある場合にのみ持ちます（Simplified General Perturbations 4（SGP4）の経路。解析的な軌道は二体問題の伝搬です）。slot-timing は、測定記録の行を oscillator.record がある場合にのみ持ちます。同じ表は、spectrum のマルチバンドの行を、実行が [[panels]] を描く場合に限って有効にし、低軌道（LEO）の種別の行を、各実行が通った経路に応じて有効にします。leo-pass または leo-pnt-chain の降雨、建物侵入、低エネルギー、スプーファーの行は、シナリオがその項を設定した場合にのみ、シンチレーションの行は、シナリオがそれを無効にしない限り、leo-navmsg、leo-pvt、またはチェーンの精密単独測位の行は、結果が持つ解析またはモードの場合にのみ、LEO システムのプリセットの行は、名前付きのプリセットが使われた場合にのみ記載されます。Shuttle Radar Topography Mission（SRTM）リーダーの行は、どの種別も持ちません。terrain-nav と terrain-slam は合成のデジタル標高モデル（DEM）で動作し、SRTM タイルを読むシナリオのフィールドはありません。実行が触れていない VALIDATED の行は、実行にないエビデンスがあると主張することになってしまいます。

レポートからの実行の再現#

report.json → reproducibility に必要なものがすべて含まれています。

"command": "kshana clock-holdover.toml",
"argv": ["kshana", "clock-holdover.toml"],
"scenario_sha256": "430c364d…",
"result_sha256": "ee5ebb0a…",
"seed": 42,

1. シナリオファイルを scenario_sha256 と照合し、input_files 内のファイル（--eop 地球姿勢ファイル）をそれぞれのダイジェストと照合します。
2. 元の実行を開始したディレクトリから command を実行します。シナリオのパスと、シナリオ内の相対データパスは、そこを基準に解決されます。
3. 新しい result.json は result_sha256 にある SHA-256 を持ち、新しい report.json と report.html は古いものとバイト単位で同一です。

tests/advanced_report_cli.rs は、クロックシナリオ、チェーンキャンペーン、スイープキャンペーン、および --eop ファイルを使う軌道の実行について、まさにこれを行います。レポートからコマンドを読み出し、記録された入力だけを置いた新しいディレクトリで実行し、バイト列を比較します。

scenario_sha256 は、ファイルの正確なバイト列のダイジェストです。結果自身の scenario_hash は別のもので、種別がシナリオから作るフィンガープリント（多くは正準形のもの）であり、レポートは両方をラベル付きで表示します。

シード。シードはシナリオの seed で、なければ結果が示すものです。シードを取らない種別については、レポートがその旨と、シナリオファイルとエンジンのビルドだけで結果が決まることを述べます。

ソースコミット。エンジンは、コンパイル時に読み取られる環境変数 KSHANA_GIT_COMMIT を設定してビルドされた場合にのみ、コミットを記録します。

KSHANA_GIT_COMMIT=$(git rev-parse HEAD) cargo build --release

これを設定せずにビルドした場合、レポートはコミットを「記録なし」と報告し、エンジンのバージョンがリリースを特定します。推測は一切しません。

プラットフォーム。ビルドのオペレーティングシステム、アーキテクチャ、ファミリー。結果は同一のプラットフォーム上ではバイト単位で同一ですが、プラットフォームをまたぐと、浮動小数点の結果は末尾の桁で異なることがあります（REPRODUCIBILITY.md を参照）。

決定論と唯一のタイムスタンプ#

シナリオのバイト列、シード、エンジンのビルドが同じであれば、report.json と report.html はバイト単位で同一になります。レポートにタイムスタンプはありません。クレート全体で時計を読むのは、--study-name が行う一か所だけで、結果ドキュメントに meta.generated_utc を刻印します。レポートはその刻印を表示し、再現しても一致しない唯一のフィールドであると述べます。これを避けるには、--study-name なしで実行してください。tests/advanced_report.rs は、scenarios/ の下にあるすべてのシナリオファイル（スイートのマニフェストを除く）のレポートを二回ずつ作成し、六つのシナリオ（チェーン、スイープ、コンポーズの各モードのキャンペーンを一つずつ含む）を再実行して、これをエンドツーエンドで確認します。

PDF への印刷#

エンジンは Portable Document Format（PDF）ファイルを書き出しません。グラフを描画する PDF ライターは、新たに重い依存関係を持ち込むことになるため、--report pdf オプションはありません。代わりに、report.html には印刷用スタイルシートが含まれています。ブラウザーで開き、印刷して、「PDF として保存」を選んでください。

スタイルシートは A4 と US Letter の両方向けに書かれています。用紙サイズは指定せず（印刷ダイアログの選択が適用されます）、どちらの用紙にも合う 15 mm / 14 mm の余白を保ち、白地に黒に切り替え、すべてのページで表の見出しを繰り返し、表の行、図、カードがページをまたいで分割されないようにし、見出しを後続のテキストと同じページに保ち、入力、結果、検証ラベル、再現性の各セクションを新しいページから開始します。ナビゲーションバーは印刷時には非表示になります。

JSON ドキュメント#

report.json には report_schema = "kshana-report" と report_schema_version = "1.0" があり、続いて kind と title、さらにセクションごとに一つのキーがあります。executive_summary、inputs、results、aggregation（キャンペーンとスイープのみ）、events、capabilities、not_modelled、companions（セクション 3b：animation、exports、export_command）、reproducibility です。リストのセクションには items、omitted（ページの上限で省かれた行。結果ドキュメントにはすべての値があります）があり、items が空の場合はその理由を述べる statement があります。値は value に生の JSON 形式で保持され、ページに表示されるテキストは display に入ります。欠けている値は、value では null、display では「no value」となります。

限界を率直に述べます#

• 単位。フィールド単位スキーマにもフィールド名にも単位がない場合、レポートは推測せず「not stated」と表示します。キャンペーンの構成シナリオ内にネストされた入力は、キャンペーン自身の単位ブロックとフィールド名の接尾辞のみで解決されるため、単独の実行よりも「not stated」と表示されるものが多くなります。
• クロスウォークの判断。ある種別がどのマトリクスの行を用いるかは、選別された表であり、各エントリが既存の行をちょうど一つ指し、すべての組み込み種別を網羅していることがテストで確認されます。各対応が正しいかどうかは、マトリクス自身のオラクルの選択と同様に、人間の判断です。
• 上限。ページに記載されるのは、入力が最大 400 件、スカラー結果が 150 件、数値列が 60 列、イベントが 200 件までで、omitted が残りを数えます。シナリオ内の 24 行を超える表（取り込んだ系列）は、列ごとに要約されます。
• Suites. kshana --study <suite.toml> は、自身の <suite>.study.json と <suite>.study.html を保持し、このレポートは書き出しません。
• バインディング。Python と WebAssembly のバインディングは、一枚のスコアカードである RunOutput::html_report() を保持します。プレイグラウンドでダウンロードできるレポートは、それ自身のページです（web/studio/lib/report.mjs）。このレポートは CLI が書き出すもので、Rust の呼び出し側は kshana::advanced_report::build で作成できます。Model Context Protocol（MCP）サーバーは、これを report_scenario ツールから JSON または HTML ページとして返します。その再現コマンド内のシナリオファイル名は呼び出し側が渡したもの（既定は scenario.toml）で、サーバーは何も書き出さないため、付随ファイルは記載されません。