`Rigor::Analysis::Diagnostic` shape
記述的であり、まだ確定していません。これはdiagnosticキャリア(carrier)の現在のシェイプ(shape)を記録するもので、コンシューマー(トリアージ、ベースライン(baseline)、JSONストリームを読むプラグイン)が文書化された契約(contract)に依存できるようにします。これはサーフェス(surface)を確定させるものではありません。public-api.mdのとおり、ルールごとの識別子と構造化フィールドの集合はv0.1.0でロックされるまでまだ変わりうるため、Rigor::Analysis::Diagnosticは意図的に公開APIドリフト仕様から外されています。識別子の分類体系、深刻度解決、抑制のセマンティクスは
diagnostic-policy.mdで規範的に定められています。このページはオブジェクトのフィールドシェイプについてのみ扱います。
Rigor::Analysis::Diagnosticは次を保持します。
| フィールド | 型 | 意味 |
|---|---|---|
path | String | diagnosticが報告される対象の解析対象ファイル。 |
line | Integer | 1始まりのソース行。 |
column | Integer | 1始まりのカラム(Prismのカラムは0始まり。コンストラクタが1を加える)。 |
message | String | 人間可読のテキスト。 |
severity | Symbol | プロファイルによる再スタンプ前の作成時の深刻度(:error / :warning / :info)(深刻度解決)。 |
rule | String? | 安定したkebab-caseのルールID(call.undefined-method)。CheckRulesが生成しないdiagnostic(パースエラー、パスエラー、内部アナライザーエラー)ではnil。nilルールのdiagnosticは抑制不能。 |
source_family | Symbol | ルールの生成元。デフォルトは:builtin。非デフォルトのファミリーは由来情報を保持する("plugin.<id>"、:rbs_extended、:generated)。 |
receiver_type | String? | 構造化フィールド ── 呼び出し関連ルールのレンダリング済みレシーバー型。それ以外はnil。 |
method_name | String? | 構造化フィールド ── 呼び出し関連ルールの呼び出し先メソッド名。それ以外はnil。 |
project_definition_site | String? | "path:line"。プロジェクト自身が呼び出し先メソッドを解析対象集合内の別の場所で定義しているとき(ディスパッチャーがファイル横断では適用しない再オープンされたクラス)、call.undefined-methodが設定する。他のすべてのdiagnosticではnil。 |
receiver_type / method_nameが存在するのは、rigor triageの認識器
(ADR-23)がメッセージをパースする代わりにこの構造化ペアを読むためです。これらがnilであるとわかったコンシューマーはメッセージパースにフォールバックします。project_definition_siteの存在は、トリアージがpre_eval:を推奨するための足がかりとする、確度の高い「バグではなくプロジェクトのモンキーパッチ」シグナルです(ADR-17)。
構築と位置の規約
Section titled “構築と位置の規約”2つのファクトリーが負荷を担う位置の規約を内部化しており、呼び出し側がそれを再導出しなくて済むようにしています。
Diagnostic.from_node(node, path:, message:, …)──nodeの位置で、line = node.location.start_line、column = node.location.start_column + 1。Diagnostic.from_location(location, path:, message:, …)── 明示的なPrismのlocationから同じ規約を用い、サブロケーション(多くは呼び出しのmessage_loc、すなわちレシーバーをまたぐノード全体ではなくマッチャー/メソッド名)を指すために使う。from_nodeはfrom_location(node.location, …)の糖衣構文。
プラグイン作者は(これらをラップする)Plugin::Base#diagnosticを呼び出し、source_familyを設定してはならない(MUST NOT)。ランナーがプラグインの由来情報をスタンプします。コアルールやその他の生成元はファクトリーを直接呼び出してもかまいません。
qualified_ruleの導出と由来
Section titled “qualified_ruleの導出と由来”#qualified_ruleは、コンシューマーが足がかりとする識別子です(抑制、ベースラインバケット、--format json)。これは次でなければなりません(MUST)。
ruleがnilのときはnil。source_familyがデフォルトの:builtinのときはruleそのまま。- それ以外のときは
"<source_family>.<rule>"。これにより、プラグインルールはplugin.<id>.<rule>として、RBS::Extendedルールはrbs_extended.<rule>として、生成シグネチャルールはgenerated.<provider>.<rule>として現れる(ADR-2 § “Plugin Diagnostic Provenance”)。
#to_s(rigor checkのテキスト行path:line:column: severity: message)は、source_familyが非デフォルトのときにのみ[<qualified_rule>]を末尾に付けます。これにより、組み込みルールのレイアウトを変えることなく由来が見えるようになります。
© 2026 TypedDuck. Licensed under CC BY-SA 4.0.