Worker Session Protocol

Rigor::Analysis::WorkerSessionは、並列解析を可能にするワーカーごとの解析基盤です。このページはセッションが満たす契約（contract）――共有可能な入力、所有権の境界、そして並列出力を逐次出力と同一に保つ等価性保証――を確定させます。並行性の根拠、フェーズのロードマップ、そしてforkかRactorかの決定はADR-15にあります。このプロトコルが依存する値オブジェクトの共有可能性要件は plugin.mdにあります。

ステータス

出荷されている並列バックエンドはforkされた永続ワーカープールです（ADR-15の修正）。Ractorで隔離されたプールは先送りされた目標です。WorkerSession基盤（ADR-15 Phase 4a）は、入力がRactor.shareable?になるように作られています。forkバックエンドは今日これを使っており、同じセッションは将来のRactorプールがRactor.newでラップするものでもあります。

共有可能な入力

コンストラクタは、ワーカー境界を安全にまたぐ入力のみを受け付けます。

• configuration ── Rigor::Configuration（Ractor.shareable?）。
• cache_store ── Rigor::Cache::Store、またはキャッシュを無効化するnil。fork／Ractorワーカーは、Storeを渡される代わりに共有キャッシュルートディレクトリで自前のStoreを構築してもよい（MAY）。
• plugin_blueprints ── Array<Rigor::Plugin::Blueprint> （Ractor.shareable?）。ワーカーごとのプラグインインスタンスはこれらから具体化されます（plugin.mdを参照）。
• explain ── Boolean。
• synthetic_method_index / project_patched_methods ── 任意、デフォルトはnil。これらはRactor.shareable?ではありません。そのためRactorプールはこれらを未設定のままにします。forkバックエンド（親プロセスでfork前にセッションを構築する）はランナーのプロジェクトスキャン結果をここに通し、ファイルごとの推論が逐次パスと正確に一致するようにします。

所有権の境界

セッションは、実行が蓄積する可変な機構を所有し、決して共有しません。

• ワーカーごとのStoreに束縛されたRigor::Plugin::Services。
• ブループリントから具体化されたRigor::Plugin::Registry。すべてのプラグインインスタンスと、その可変な実行ごとのアキュムレータ（探索インデックス、到達可能性集合）を含む。
• RbsExtended::Reporterと、依存元のBoundaryCrossReporter（どちらもMutexを持ち、意図的にワーカーごと。ランナーはプール後に#drain_reportersでそれらのエントリーをマージする）。
• ワーカーごとのレポーターを通したRigor::Environment。これにより推論／ディスパッチからのレポーター書き込みがワーカー自身の状態に蓄積されます。

プラグインの#prepareは構築時に一度実行され、各ワーカーが最初の#analyze呼び出し前にウォームになるようにします。prepareからのraiseはすべて#prepare_diagnosticsに捕捉され、ワーカーを中断する代わりにランナーがファイルごとのストリームと並べて顕在化させます。

等価性契約

同一の(configuration, cache_store, plugin_blueprints)が与えられたとき、paths.flat_map { |p| session.analyze(p) }からのdiagnosticの多重集合に#prepare_diagnosticsと排出されたレポーターのエントリーを加えたものは、Rigor::Analysis::Runner#runの出力の対応する部分集合と等しくなければなりません（MUST）。ただし深刻度プロファイルの再スタンプは除きます。セッションはこれを意図的に呼び出し側に委ねます。なぜならそれは実行ごとの集約的な関心事だからです（深刻度解決を参照）。これは、rigor checkが報告する内容を変えることなく、ランナーがファイルをワーカー間でシャーディングできるようにする性質です。これはspecによって証明されています。