ADR-43 — RBS-complete ancestor resolution (allow-list inherited-method dispatch)

Status: Accepted — fully landed (WD1–WD6), 2026-06-03. rigor checkが、Rubyソースのサブクラスの継承されたメソッド呼び出しを、 アローリスト化されたRBSのみの祖先に対して解決できるようにする。これによりエンジンはその祖先の契約（contract）サーフェス（surface）の誤用を警告できる。動機となったケースはRigor::Plugin::Baseプラグイン契約そのものである。アローリスト解決（WD1–WD3）、そのscopeスレッディング（WD2）、そしてFP計測（WD5）は実装・検証済みである。バンドル済みプラグインのlibツリーでは、manifest.rbsを完成させたあとこの変更による正味の診断（diagnostic）追加はゼロになる（解決が最初に表面化させた26件のFPはすべてManifest#id／#protocol_contractsであり、 Manifest自身のRBSにあった真の欠落だった。いまは塞がれており、Layer 1が IoBoundaryで踏んだのと同じパターンである）。WD6は完了：プラグインlibツリーが抱えていた16件の既存の診断──本ADRとは無関係（Analysis::DiagnosticシングルトンファクトリーとPlugin::AccessDeniedErrorの< StandardErrorの不完全なRBS、加えて rigor-rspecのPrism::Node#blockフローナローイングの欠落1件で、明示的な is_a?(Prism::CallNode)ナローイングで修正）──は片付けられ、make check-plugins ターゲット（make verifyに連結され、CIではコールドセルフチェックのバリアントでゲートされる）がプラグインlibツリーをクリーンに保つ。いまやバンドル済みプラグインのいずれかで契約を誤用するとビルドがcall.undefined-methodで失敗し、これはエンドツーエンドで検証済みである（manifest.bogusを注入→非ゼロ終了）。決定、偽陽性の境界、そして却下された代替案を以下に記録する。

根拠: docs/notes/20260603-plugin-contract-self-typing-spike.md （完全なスパイク：なぜSteepはプラグインごとのRBSなしにプラグイン契約を強制できないのか、この欠落を特定したdump_typeプローブ、そしてcall.undefined-methodの効力と FP安全性に関する知見）。

Context

The question

「私たちはlibをSteepとrigor checkで型検査している。プラグインファイルが Plugin::Base契約を誤用したとき──たとえば契約が定義していないメソッドを呼んだり、裏でリネームされてしまったメソッドを呼んだり──Rigor自身が（スタンドアロンで、 Steepなしで）警告できるか？」

sig/rigor/plugin/base.rbs（the plugin-contract RBS、着地済み）の完成と、オーバーライドアリティの適合性スペック（spec/integration/plugin_contract_conformance_spec.rb、ADR-37のフォローアップ、着地済み）が2つの側面をカバーする。本ADRは3つ目について扱う：プラグイン内部からの型付き契約サーフェスの静的な誤用──manifest.bogus、io_boundary.bogus、リネームされたヘルパーの呼び出しなど。

What the spike settled

dump_typeベースのスパイク（ノートの§「Can Rigor warn instead of Steep」）が 3つの事実を確立した:

call.undefined-methodルールには効力があり、プラグイン自身のメソッドに対して FP安全である。直接構築されたRigor::Plugin::Manifest.new(...)は Nominal[Manifest]に解決され、m.totally_bogus_methodは call.undefined-method（error）を発火する。Steep──selfを素のRBS Baseとして型付けるため、プラグイン自身のRBS未記述ヘルパーへのあらゆる呼び出しで偽陽性になる（ノートの§「Option A」）──とは異なり、Rigorはプラグインのdefをソースから読み取り、selfをサブクラスとして型付け（dump_type(self) → Rigor::Plugin::ProbeDump）、自身のヘルパー呼び出しを正しく解決する。Rigorはこの点でSteepより構造的に適している。
しかしRBS祖先から継承された呼び出しはDynamic[top]に解決される。 self.manifest、io_boundary、signature_paths──いずれもRBSでBase上に宣言され、いずれもサブクラスとして型付けされたself上で呼ばれる──は、そのRBSの戻り型ではなくDynamic[top]に解決される。そのため契約サーフェスはエンジンから不可視になり、誤用を捕捉できない。レシーバーがDynamicであり、call.undefined-methodは定義上それを対象外とするからである。
これはプラグイン固有ではなく一般的な挙動である。 class MyHash < Hashも self.keys（コアのHash RBSから継承）をDynamic[top]に解決する。RBSのみのクラスのRubyソースサブクラスは、継承されたRBSメソッドに対して盲目である。

Why the gap exists, and why it is load-bearing

場所は rbs_dispatch.rb lookup_method （~L270）：Nominal[Sub]レシーバー上のディスパッチは instance_method_definition("Sub", …)を呼ぶが、Rubyソースのサブクラス名がRBS環境の class_declsに存在しない（rbs_loader.rb ~L968）ため即座に失敗する。祖先ウォークは走らない──RBSのDefinitionBuilderは到達すれば祖先をウォークするが、その前にクラス存在チェックがショートサーキットする。ディスパッチは以降のあらゆるティアをすり抜け（user_class_fallbackもクラスがRBS既知であることを要求する）、 Dynamic[top]にデフォルトする。

継承エッジは既知である：class Sub < BaseはScope#discovered_superclasses （ADR-24 Slice 2）に記録されており、すでにファイルをまたぐユーザーメソッド解決のためにExpressionTyper#resolve_user_def_through_ancestorsが利用している。それが単にRBS祖先に到達するためにRbsDispatchから参照されていないだけである。

Dynamic[top]フォールバックが意識的な決定であったか否かにかかわらず、その効果は偽陽性保護であり、これをグローバルに取り除くのは安全でない。 class MyController < ActionController::Baseがparams、render、head、…を 部分的なgem RBSに対して呼ぶと、RBSが省いている継承メソッドのすべてが、動作しているコード上のcall.undefined-method偽陽性に変わってしまう。精度の向上（継承された戻り型の解決）とリスク（継承呼び出しでのundefined-method発火）は同一の解決パスを通る ──一方だけを得ることはできない。これが設計が尊重しなければならない核心であり、一律な修正が却下され（WD-rejected-A）、スコープ付き・アローリスト化されたものが提案される理由である。

これはADR-26のopen_receivers:の隣に位置し、それは逆向きのつまみである。ADR-26はレシーバーをopenとしてマークし、実サーフェスがRBSを超えるクラス（ActiveRecord リレーション）上の診断を抑制する。本ADRは少数の祖先をclosed／RBS-completeとしてマークし、サブクラス上の診断を有効化する。両者は双対であり、ともにエンジンが安全に主張できる精度を最大化しつつ偽陽性をゼロに保つために存在する。

Decision

スコープ付き継承メソッド解決を追加する：Nominal[Sub]レシーバー上のディスパッチが SubをRBS既知でないと判断したとき、Subの発見済みスーパークラスチェーンを参照する。祖先がRBS-completeアローリスト上にあれば、メソッドをその祖先のRBS定義（戻り型＋アリティ＋可視性）に対して解決し、通常のcall.undefined-method／call.wrong-arity／オーバーライドルールが継承された契約呼び出しに適用されるようにする。アローリスト上にない祖先はすべて、現状のDynamic[top]フォールバックを変更せず維持する。

アローリストのメンバーシップ基準は「このクラスのRBSは権威的かつ完全である──それが宣言しない呼び出しは正真正銘の誤りである」である。これはRigor::Plugin::Baseについては真であり（構成上、契約がRBSそのものである。本リポジトリが両方を所有する）、 ActionController::Base、Hash、そして実質的にRBSが省くメソッドにオブジェクトが日常的に応答するあらゆるサードパーティ／コアクラスについては偽である。

Working decisions

WD1 — アローリストのシード＝{ "Rigor::Plugin::Base" }。ドッグフードの対象であり、私たちが現時点でRBS-completeだと知っている唯一のクラスである（コードと base.rbsの両方を私たちが著作しており、適合性スペック＋rigor check libが両者を同期させている）。このリストはv1では定数である（WD4でソーシングを再検討する）。
WD2 — 注入点＝RbsDispatch.lookup_method（rbs_dispatch.rb ~L270）。直接の instance_method_definitionルックアップがnilを返したあと、すり抜ける前に、レシーバクラスがRBS既知でなければScope#discovered_superclassesからそのスーパークラスを読み、そのスーパークラスが（推移的に、WD3）アローリスト化されていれば instance_method_definition(ancestor, method_name)を返す。シングルトン呼び出しは対称なsingleton_method_definitionパスを取る。この変更は加算的である：アローリスト化された祖先を持たないクラスは今日とまったく同じ挙動になる。
WD3 — 発見済みスーパークラスチェーン全体をウォークし、最初のアローリスト化された祖先で停止する。今日プラグインは常にPlugin::Baseの直接サブクラスなので、シードには直近の親で十分だが、チェーンをウォークしても追加コストはなく、より深い階層に備えられる。インクルードされたモジュールはv1のスコープ外である（プラグインは契約をミックスインしない。ユースケースが現れたら再検討する）。ウォークはADR-24の既存のdiscovered_superclassesマップを再利用する──新たな簿記は不要である。
WD4 — アローリストのソーシング：いまは定数、のちにプラグインマニフェスト。 v1は定数をハードコードする。将来のイテレーションでは、プラグインがマニフェストを通じて「私の契約baseはRBS-completeである」と宣言できるようにしてもよい（MAY）（ADR-37／ ADR-40の宣言的ルート）。これにより、ツリー外のプラグインgemがエンジンを編集せずに自身のBase的クラスをオプトインできる。シードにそれが不要であり、マニフェストサーフェスが実際の設計コストを伴うため延期する。定数が終着点ではなくプレースホルダーとして理解されるよう記録しておく。
WD5 — フラグオン前の計測ゲート。精度とundefined-method発火が結合している（Context）ため、この変更は断言ではなく計測でクリーンなバーの背後で出荷される：（a）完全なrigor check libがグリーンを維持する；（b）rigor check下のバンドル済みプラグインツリー（plugins/*、examples/*）が真の契約誤用のみを表面化させ、適合するプラグインにはFPゼロである；（c）実プロジェクトのスイープ（Redmine／Mastodonの app + lib、reference_survey_external_projectsプロトコルに従う）が新規診断ゼロを示し、アローリストのスコープ付けがオープンな階層を手つかずのまま残すことを確認する。（b）／（c）でのいかなるFPもマージをブロックする──偽陽性の規律が機能より優先される。
WD6 — プラグインツリーをチェックゲートに配線する（DONE）。専用の make check-pluginsがrigor check plugins/*/lib examples/*/libを実行する（libディレクトリのみ──demo/ツリーは意図的にモデル化されていないフレームワークDSLを動かすものであり、クリーンな対象ではない）。これはmake verifyに連結され、CIではコールドセルフチェックのバリアントで「Run plugin-contract check」ステップとしてゲートされる。これによりバンドル済みプラグインファイルのすべてに契約が自己強制される──strictな Steepターゲットには実現できなかったこと（ノートの§「Option A」）を、SteepのFPの壁なしに実現する。グリーンなツリーに到達するには、解決そのものとは無関係な16件の既存診断を片付ける必要があった：RBSにおけるAnalysis::Diagnosticのシングルトンファクトリー（from_node／from_location）とPlugin::AccessDeniedErrorの< StandardErrorの完成、そしてrigor-rspecのlet_scope_indexにおけるPrism::Node#blockフローナローイングの欠落1件（カスタムのdescribe_call?述語は実行時にCallNodeを保証するが、アナライザーのPrism::Nodeビューをナローイングしない──# rigor:disableではなく明示的な is_a?(Prism::CallNode)の再記述で修正したので、ナローイングは本物である）。効力を検証済み：プラグインに注入されたmanifest.bogusはmake check-pluginsを call.undefined-methodで非ゼロ終了させる。

Rejected / deferred alternatives

（却下）一律な継承RBS祖先解決。アローリストではなくすべてのRBS祖先について継承メソッドを解決する。却下：Railsコントローラーの偽陽性の壁（Context）を再導入する ──部分的なgem RBSは、省かれた継承メソッドのすべてを、動作しているコード上の call.undefined-method FPに変える。プロジェクトの最上位の偽陽性の規律に違反する。
（却下）plugins/*上でのstrictなSteepターゲット（ノートの§「Option A」）。 Steepはselfを素のRBS Baseとして型付けるため、プラグイン自身のRBS未記述ヘルパーへのあらゆる呼び出しで偽陽性になる（計測値：rigor-deprecations単独で3件のFP）。これを成立させるには37個すべてのプラグインに対するプラグインごとのRBSが必要であり ──規模と、sig-gen優先／手書きRBS回避ポリシー（AGENTS.md §「RBS Authorship」）により却下される。Rigorのソース読み取りディスパッチにはこの壁がなく、それこそが本ADRがエンジンルートを選好する全理由である。
（延期）rigor sig-genによるプラグインごとのRBS。プラグインツリー上のsig-genがプラグインごとのRBSを安価かつ正確にするなら、Steepと一律解決のRigorの両方がアローリストなしに効力を得るだろう。延期：sig-genはまだプラグインツリーを対象としておらず、アローリストはより少ないサーフェスでいま目標に到達する。sig-genのカバレッジが着地したら再検討する。
（延期）プラグインマニフェストで宣言されるアローリスト──WD4に畳み込まれた。

Relationship to other ADRs

ADR-24（self型メソッド呼び出し解決）──本ADRが消費する discovered_superclassesエッジを供給する。これは同じ「self型／継承呼び出しを解決する」アークの自然な次のステップであり、ユーザーメソッドの祖先からRBS-completeな祖先へと拡張したものである。
ADR-26（open_receivers:）──逆向きのつまみ（open-to-suppress対 closed-to-enable）。両者は偽陽性ゼロという目標を共有する。
ADR-34（トップレベルの未解決self型呼び出し）──本ADRがスコープ付き例外を切り出す対象である、同じDynamic[top]-as-safetyデフォルト。
ADR-35（オーバーライドシグネチャ互換性）──そのルールは両側著作ゲートである。プラグインの継承フックが本ADRを通じて解決されると、オーバーライドルールは作用する第2のサーフェス、すなわちRBS祖先対Rubyオーバーライドを得る（フォローアップになりうる。v1のスコープではない）。
ADR-37／ADR-40──WD4が委ねる宣言的マニフェストルート。