Public API Stability Boundary

ステータス：アクティブ（v0.1.0契約は出荷済み;v0.2.0へ向けて安定化中）。プラグイン契約（contract）が設計される対象となるネームスペースをリストし、パブリックAPIドリフトスペックを通じてそれらを固定します。v0.1.0プラグイン契約は出荷され、0.1.xプレビューラインがサーフェスを拡張してきました（クロスプラグインファクト、signature_paths:、open_receivers:、protocol_contracts:、source_rbs_synthesizer:）;v0.2.0は、このサーフェスが外部のrigor-* gem向けに安定化される最初のラインです。（rigor <command> CLI自体 — mcp、triage、baseline、plugin、skillのような新しいサブコマンドを含む — は以下の除外リストに従って内部の配管にとどまります;そのユーザー向け契約はdocs/manual/にあります。）ドリフトスペックは偶発的なシグネチャ変更を検出するため、すべての変更は意図的でレビュー可能なままです。

なぜこの境界が存在するか

ADR-2はRigorをプラグインアーキテクチャにコミットさせており、gem作成者がケイパビリティ（capability）ロール・動的返却ファクト（fact）・型指定プラグイン・RBS::Extendedディレクティブを提供できるようにします。プラグイン作成者は少数の読み取り側サーフェスに対して書き込みを行います：

Rigor::Scope — ノードごとの解析状態（ローカル変数・インスタンス変数・ファクト・環境）。
Rigor::Type + Rigor::Type::Combinator — 型オブジェクトレイアウトとファクトリーエントリーポイント。
Rigor::Environment — プロジェクトレベルのRBS/クラスレジストリ/キャッシュストアハンドル。
Rigor::Reflection — 3つのリフレクションソース（ClassRegistry + RbsLoader + スコープで発見されたファクト）に対する統合された読み取り側ファサード。
Rigor::FlowContribution — プラグインが返すバンドル（v0.1.0貢献マージャーはバンドルを直接消費します）。
Rigor::Analysis::Diagnostic — プラグインが発行する診断の形状（source_family来歴を持つ）。Diagnostic.from_node／.from_locationコンストラクタ（およびPlugin::Base#diagnosticラッパー）は、1始まりのline／start_column + 1という位置指定の慣習を内部に取り込みます（ADR-37）。

このドキュメントは、それらのネームスペース上のどのメソッドがパブリック（プラグイン作成者が依存してよい）か、内部（予告なく変更される可能性がある）かを宣言します。v0.0.9のクラスタはネームスペースごとのドリフトスナップショットを増やしたため、将来のシグネチャ変更はサイレントな破壊ではなくテストの失敗として現れます。

現在ロックされているもの

spec/rigor/public_api_drift_spec.rbのドリフトスペックは以下のインスタンスおよびシングルトンメソッドセットを固定します：

Rigor::Scope — インスタンスメソッド + Scope.empty(environment:)ファクトリー。
Rigor::Environment — インスタンスメソッド + Environment.default / Environment.for_project(root:, libraries:, signature_paths:, cache_store:)。
Rigor::Type::Combinator — 推論エンジンが使用するすべてのファクトリー（top・bot・untyped・nominal_of・singleton_of・constant_of・integer_range・positive_int・non_empty_string・lowercase_string・literal_string・union・intersection・difference・refined・key_of・value_of・indexed_accessなど）。
Rigor::Reflection — すべてのclass_known?・class_ordering・class_type_param_names・constant_type_for・discovered_class?・discovered_method?・instance_definition・instance_method_definition・nominal_for_name・rbs_class_known?・singleton_definition・singleton_for_name・singleton_method_definition。
Rigor::Plugin — register・registered・registered_for・unregister!（テストヘルパー）。v0.1.0スライス（slice）1。
Rigor::Plugin::Base — クラスレベルのmanifest(**fields)・producer・node_rule・node_file_contextの各DSL・インスタンスレベルのservices / config / manifest・オーバーライドフック#init / #prepare / #diagnostics_for_file / #flow_contribution_for・エンジン所有ウォークのディスパッチャー#node_rule_diagnostics・#diagnostic(node, …)ビルダー。v0.1.0スライス1 + ADR-37。
Rigor::Plugin::Manifest — id・version・description・protocols・config_schema・validate_config(config)。
Rigor::Plugin::Services — reflection・type・configuration・cache_store・trust_policy・io_boundary_for(plugin_id)。
Rigor::Plugin::Registry — plugins・ids・find(id)・load_errors・empty?・any_load_errors?。
Rigor::Plugin::TrustPolicy — trusted_gems・allowed_read_roots・network_policy・allow_read?(path)・network_allowed?・gem_trusted?(name)・to_h。v0.1.0スライス2。
Rigor::Plugin::IoBoundary — policy・plugin_id・read_file(path)・open_url(url)・cache_descriptor。v0.1.0スライス2。
Rigor::Source::Literals — 引数リテラル抽出グリッドsymbol・symbol_name・symbol_or_string・symbol_or_string_name・symbol_arguments・symbol_arg。それ以外は内部のRigor::Source::*名前空間（後述）の中で意図的に公開された唯一のメンバー: プラグイン作成者が案内される共有DSLウォーカーヘルパーです（ボイラープレート削減プラン § 0a）。v0.1.x。

これらのメソッドのシグネチャが変更された場合は、同じコミットで対応するPublicApiDriftSnapshots::*定数を更新する必要があります。

意図的にまだロックされていないもの

Rigor::FlowContribution — v0.0.9（c48f05f）で出荷されたバンドル構造体；スライス3が#to_element_listを追加し、パブリックAPIドリフトスペックを通じてバンドル形状を固定しました。プラグイン作成者はパブリックリーダー/to_h形式を通じてバンドルを消費し、v0.1.0が確定するまでスロットごとの値形状（PredicateEffect・AssertEffectなど）を直接固定するのは避けてください。
Rigor::FlowContribution::Element / MergeResult / Conflict / Merger — スライス3のサーフェス；ドリフトスペックによって固定済み。平坦化とマージポリシーはflow-contribution-merger.mdに従って規範的です。
Rigor::Analysis::Diagnostic — source_familyとqualified_ruleはv0.0.8（ed9ae0a）で追加されましたが、v0.1.0プラグインの可観測性ストーリーが確定するにつれてルールごとの診断識別子はまだ流動的です。
Rigor::Cache::* — プロデューサー向けのStore#fetch_or_compute(producer_id:, params:, descriptor:, serialize:, deserialize:) APIは最も安定したレイヤーであり、プラグイン側キャッシュプロデューサーが使用するものです。ディスクリプタスキーマはADR-6とスライス分類設計ドキュメントによって固定されています；プラグイン作成者は新しいスロット種類ではなくPluginEntry行を追加すべきです。
Rigor::RbsExtendedディレクティブパーサ — パブリックリーダーメソッド（read_predicate_effects・read_assert_effects・read_return_type_override・read_param_type_overrides・read_flow_contribution）は現在安定した形状です；エフェクトごとのデータキャリア（carrier）（PredicateEffect・AssertEffect・ParamOverride）はFlowContributionと同じv0.1.0の精緻化の対象です。
Rigor::Plugin::* — 登録/ロードサーフェスはv0.1.0スライス1で到着しました。インスタンスレベルのRigor::Plugin::Base#initフックは現在安定しています；スライス3〜6で追加されるプロトコルフックはBaseのパブリックメソッドセットを精緻化するかもしれません。プラグイン作成者はv0.1.0の開発中は特定のRigorバージョンにgemを固定すべきです。

内部サーフェス（パブリックではない）

プラグイン作成者が以下に依存してはなりません（MUST NOT）：

Rigor::Inference::*モジュール（ScopeIndexer・ExpressionTyper・StatementEvaluator・MethodDispatcher・MethodParameterBinder・ClosureEscapeAnalyzer・CoverageScanner）。これらはエンジンの内部メカニズムです；推論サーフェスの進化に伴い形状が変わります。
Rigor::Analysis::FactStore・Analysis::Result・Analysis::CheckRules・Analysis::Runner。診断カタログとルール定義はプラグイン拡張サーフェスではありません——プラグインはv0.1.0プラグインプロトコルを通じて診断を発行し、CheckRulesに行を追加しません。
Rigor::AST::*仮想ノード。エンジンが内部で使用する合成ASTノードは安定したプラグインサーフェスではありません。
あらゆるRigor::Source::*（上でロックされたRigor::Source::Literalsを除く）・Rigor::CLI::*・Rigor::Configurationヘルパー。これらはCLI/ローダーの配管です。Source::Literalsは唯一の切り出し例外です: ドリフトピン留めされており、推奨されるプラグイン作成者向け引数抽出器です。

昇格パス

v0.1.0プラグイン契約が現在内部のサーフェスをパブリックにする必要がある場合：

関連するADRが修正されます（プラグイン拡張プロトコルはADR-2、型オブジェクト/推論エンジンの詳細はADR-3/4）。
クラスがメソッドセットのスナップショットと共にspec/rigor/public_api_drift_spec.rbに追加されます。そのコミット以降、偶発的なシグネチャ変更はドリフトスペックを壊します。
このドキュメントに新しいネームスペースの「v0.1.0で昇格」エントリーが追加されます。

プラグイン作成者のための読み順

docs/adr/2-extension-api.md — プラグイン契約（ケイパビリティロール・貢献マージ・診断来歴・登録・設定・キャッシュ・トラスト/I/O）。
docs/internal-spec/internal-type-api.md — すべてのRigor::Type::*キャリアが満たす型オブジェクトパブリック契約。
docs/internal-spec/inference-engine.md — Rigor::Scope#type_ofの純粋性・ファクトストア/エフェクトモデル・環境読み込み境界。
docs/internal-spec/reflection.md — Rigor::Reflection読み取り側ファサード。
docs/internal-spec/flow-contribution.md — Rigor::FlowContributionバンドル。
docs/internal-spec/cache.md — キャッシュレイヤーのパブリック読み取り形状；プラグイン側キャッシュプロデューサーがこのAPIを使用します。