コンテンツにスキップ
Rigor

Rigor Roadmap

将来を見据えたコミットメント: 何が積極的に進行中で、次に何が計画されているか、何が意図的にスコープ外か。

このファイルは計画資料であり、リリースログではありません。「何が出荷されたか」の記録については、CHANGELOG.md（アクティブな0.1.xサイクル）とdocs/CHANGELOG-0.0.x.md（アーカイブ済み0.0.x）を参照してください。

このファイルがADRまたは仕様と矛盾する場合、ADR / 仕様が拘束力を持ち、このファイルは古くなっています。

リリース済みマイルストーン（ポインタのみ）

Section titled “リリース済みマイルストーン（ポインタのみ）”

完全なリリースノートはCHANGELOG.mdにあり;各カットを形作った計画エンベロープはgit履歴に保存されています（docs/MILESTONES.mdをROADMAP.mdにリネームしたコミットを参照）。

バージョンリリース日テーマ
v0.0.3 — v0.0.92026-05-02 → 2026-05-05型語彙、推論エンジン、永続キャッシュ。docs/CHANGELOG-0.0.x.mdを参照。
v0.1.02026-05-07最初のプラグイン契約（contract）（6スライス（slice））;7つの動作例。CHANGELOG.md § [0.1.0]を参照。
v0.1.12026-05-08リテラル文字列ナローイング（narrowing）の深化、クロスプラグインAPI、プラグイン作成DX。CHANGELOG.md § [0.1.1]を参照。
v0.1.22026-05-09プラグイン例の戻り型移行、エンジン深化フォローアップ。CHANGELOG.md § [0.1.2]を参照。
v0.1.42026-05-14ADR-10 / ADR-11 / ADR-13の延期キュー、ADR-14 rigor sig-genエンドツーエンド、Type::BoundMethodキャリア（carrier）、18の動作プラグイン例。（v0.1.3のコミットメントエンベロープがカット前に追加のトラックを吸収し、v0.1.4として出荷。）CHANGELOG.md § [0.1.4]を参照。
v0.1.52026-05-16ADR-15 Ractor移行エンドツーエンド（フェーズ1〜4c + 4b.x）、実世界Railsサーベイ（14プロジェクト、31,840ファイル）が本番改善を駆動（ベンダーgem RBS、ActiveSupport core_extオプトインバンドル、Bundler認識sigディスカバリー）、ADR-16マクロ / DSL展開基板（WD13フロアでO2をクローズ）、O4レイヤー3スライス1+2+3（Gemfile.lockパース + rbs_collection.lock.yaml認識 + 欠落gemの:info診断）、DEFAULT_LIBRARIESのstdlibカバレッジ拡張（1,273 → 1,427 RBSクラス）、is_a?(C)レキシカルネスティング定数解決、24の動作プラグイン例。CHANGELOG.md § [0.1.5]を参照。
v0.1.62026-05-19ADR-12 / ADR-17 / ADR-18フロア + 動作消費者;エディタモードv1 + 言語サーバーv1/v2;ADR-20軽量HKT;エコシステムプラグイン + rigor-railsメタgemスキャフォールド。CHANGELOG.md § [0.1.6]を参照。
v0.1.72026-05-20ADR-22ベースライン（baseline）メカニズム（スライス1+2） + プロジェクトオンボーディング基盤;サーベイ駆動のプラグイン / エンジン偽陽性修正;Pillar 2「あなたのspecが型である」スライス1+2+3。CHANGELOG.md § [0.1.7]を参照。
v0.1.82026-05-21Mastodonサーベイ偽陽性削減: ADR-15フォークベースのワーカープール（アクティブなworkers > 0バックエンド）、ADR-23 rigor triage診断トリアージサブコマンド、ADR-24暗黙的selfメソッド呼び出し解決。CHANGELOG.md § [0.1.8]を参照。
v0.1.92026-05-23指定の「最後のプレビューカット」: 外部ユーザーSKILLトリオ（rigor-project-init、rigor-baseline-reduce、ADR-22 WD8に基づく外部著者rigor-plugin-authorバリアント）;ADR-22ベースラインスライス5（rigor baseline regenerate + --baseline-strict CIゲート）;v0.1.7 / v0.1.8サーベイデータによる実証的デフォルトの引き締め。CHANGELOG.md § [0.1.9]を参照。
v0.1.102026-05-27rigor mcp --transport stdio（ADR-33、7つの読み取り専用ツール）;rigor sig-gen --params=observed attr_reader推論;rigor coverage精度ゲート;rigor check --treat-all-as-inline-rbs;rigor-rbs-inlineプラグイン（ADR-32）;ブラウザプレイグラウンド（ADR-29スライス1〜4）;rigor annotate戻り型アノテーション;ADR-28パススコープのプロトコル契約 + rigor-hanami;定数畳み込み（Date/DateTime/Time、Math、String/Integer/Float中優先度、Hashシェイプ（shape）ハンドラ）;return if @ivar.nil? ivarガードナローイング修正。CHANGELOG.md § [0.1.10]を参照。
v0.1.112026-05-27プラグインをrigortype gemにバンドル;ポータブルベースラインパス;rigor-rails-routesでkaigionrails conference-app + Mastodonトライアルに基づく5つの偽陽性ソースを解消（new_ / edit_プレフィックス順序、匿名getルート、scope as:プレフィックス + arity、draw(:name)部分的読み込み、concernボディnoop、末尾オプションハッシュ +1 arityルール）;rigor-rails-i18nコントローラー内のレイジー翻訳キー;Railsクイックスタートマニュアル。CHANGELOG.md § [0.1.11]を参照。
v0.1.122026-05-28Mastodon / Redmine / GitLab FOSSに対するOSSリアリズムサイクル: Mastodonapp + libエラー789 → 6（−99.2%）、Redmine163 → 79（−51%）、GitLab FOSS app/{controllers,mailers,workers,services}〜670 → 〜140。6つのflow.always-truthy / always-falsey FPパターンをクローズ（書き込み前読み取りnil、介在するメソッド呼び出し、retryエッジ、falsey-rvalue防御的初期化、極性認識ガード、ミューテーターの幅広げ）。新しいナローイングプリミティブ（`receiver[key]
v0.1.132026-05-29AI支援のオンボーディング + 単一ファイルスクリプト解析: 新しいrigor skillサブコマンド（mise use gem:rigortypeインストールから発見できるバンドル済みAgent Skills）;call.unresolved-toplevel診断（ADR-34） + pre_eval:プロジェクトモンキーパッチ事前評価（ADR-17）。CHANGELOG.md § [0.1.13]を参照。
v0.1.142026-05-29AIエージェント駆動のセットアップのための機械可読インストールガイド（docs/install.md、ADR-27）;rbs collection install後に環境を黙って壊していたRBS::DuplicatedDeclarationErrorを修正。CHANGELOG.md § [0.1.14]を参照。
v0.1.152026-05-29リスコフのオーバーライド互換性診断ファミリー（def.override-*、ADR-35）;rigor pluginソースブラウジングコマンド;実際には未インストールのプロジェクトモンキーパッチや生成されたDSLであるundefined-method診断に対する、より鋭い報告 + rigor triage認識器 + オンボーディングスキルのルーティング。CHANGELOG.md § [0.1.15]を参照。
v0.1.162026-06-03プラグインアーキテクチャの全面的見直しと内部メカニズムの再ドキュメント化。ADR-37/38/39/40が完全に着地: バンドルの診断発行プラグイン14個すべてをnode_rule（エンジン所有ウォーク、PHPStanスタイル）へ移行;dynamic_return / type_specifierのスライス（slice）2;rigor plugins --capabilities AI可読カタログ（スライス3）;additional_initializers:（ADR-38のdef形式）;config_schemaの宣言デフォルト（ADR-40、13プラグインを移行）;Source::Literalsグリッド完成 + 10プラグインを移行;実際のActiveSupport::Inflector上のPlugin::Inflector + 選択可能な分離戦略（デフォルトはprocess、Plugin::Isolation）。ADR-43のRBS完全な祖先解決（Plugin::Base許可リスト） + verifyとCIでのmake check-pluginsゲート。プラグイン契約（contract）の構造的ガード: 適合スペック、全プラグインロードスペック、デモ実行スペック、外部プラグインフィクスチャ（v0.2.0ゲート1の実行可能なエビデンス）。Plugin::Base + ManifestのRBSサーフェス（surface）完成。RBSロバストネス: 不正・陳腐化したプロジェクトのsignature_paths: sig向けの合成名前空間 + スタブ型。rigor-activerecordの欠落スキーマメモ化修正（Redmineメモリ−86%、ウォール時間−51%）。推論バジェットサーベイ + RIGOR_BUDGET_TRACE計装。CHANGELOG.md § [0.1.16]を参照。

リリース戦略 — v0.2.0への道

Section titled “リリース戦略 — v0.2.0への道”

0.1.xラインはプレビューラインです。0.2.xラインは評価ラインを開きます — まだフォーマル / GAリリースではないが、実プロダクトでの試験デプロイを意図した最初の公式発表バージョンです。

ライン役割
0.1.xプレビュー。v0.1.9は当初の指定「最後のプレビューカット」だったが、Mastodon / Redmine / tdiary / GitLab FOSSに対するトライアル作業が、実質的な偽陽性削減・オンボーディング・機能・アーキテクチャの各サイクルを経てラインをv0.1.16まで延長した。v0.1.12はMastodonapp + libを6件の無関係なエラーで残した;v0.1.13〜v0.1.15はAI支援のオンボーディング + リスコフのdef.override-*を追加;v0.1.16はプラグインのインターフェース分離 + エルゴノミクススイート（ADR-37/38/39/40/43）一式とv0.2.0ゲート1の実行可能なエビデンスを着地させた。v0.1.17（計画中）はv0.2.0カットの前に内部構造レビュー + パフォーマンスチューニングを完了させる。
v0.2.0最初の評価リリース。実プロダクトでの試験デプロイを意図した最初のバージョンとして公式に発表される;評価期間を開き、外部のフィードバックを募る。
0.2.x評価ライン。まだフォーマルバージョンではないが、目標はRactor並行性トラックを除くすべての計画された機能を高い完成度 / 本番品質に持っていくこと。

v0.1.16以降の状況

Section titled “v0.1.16以降の状況”

v0.1.9の「最後のプレビューカット」の意図は達成済み（SKILLトリオ、ADR-22スライス5、実証的デフォルトの引き締めが出荷）し、ラインは追加のトライアル駆動・アーキテクチャ駆動のパッチカット7件（v0.1.10〜v0.1.16）を経て延長された。プレビューラインはv0.2.0に向けた強いRCポスチャーに今ある:

  • 99.2%のMastodon FP削減が経験的に実証済み;Redmine 51%、GitLab FOSS〜80%（調査済みスコープ）;v0.1.16のrigor-activerecordメモ化修正後、Redmineのメモリフットプリントは−86%削減。
  • 全3件のフローフォールディングG2フォローアップ（retry、介在する呼び出し、書き込み前読み取りnil）がクローズ済み（v0.1.12）。
  • rigor plugins（有効化レディネス、v0.1.12）、rigor plugin（バンドルソースブラウジング、v0.1.15）、rigor plugins --capabilities（AI可読の拡張プロトコルカタログ、v0.1.16）サブコマンドが、プラグイン設定と発見のギャップをクローズする。
  • オンボーディングはセルフサーブ: rigor skill + docs/install.mdにより、AIエージェントが単一のプロンプトからRigorをインストール・設定できる（v0.1.13 / v0.1.14）。
  • pre_eval:メカニズム（ADR-17）、リスコフのdef.override-*ファミリー（ADR-35）、プラグインのインターフェース分離 + エルゴノミクススイート（ADR-37/38/39/40/43）がすべて出荷され、v0.1.16までで主要な残りのADRキューをクローズした。
  • v0.2.0ゲート1の実行可能なエビデンスが着地（v0.1.16）: 外部プラグインフィクスチャ + 適合スペック + 全プラグインロードスペック + デモ実行スペックが、パブリックなプラグイン契約がツリー外のrigor-* gemをサポートすることを証明する。残るステップは文書化された安定性コミットメント（ピン留めされた名前空間に対する「0.2.x内で壊さない」という言明）。

v0.2.0ゲートはその後3つから1つに削減された: SKILLトリオ（ゲート3）が出荷され、サブツリー分割／プラグインごとの公開ゲートは単一バンドルrigortype gem配布モデル（ADR-31 + コミット9769f5fa）によって置き換えられた。残る唯一の実質的なゲートは、外部プラグイン契約の文書化された安定性コミットメントである。

v0.1.17が計画中で、v0.2.0カットの前のさらなる内部構造レビューとパフォーマンスチューニングのサイクルとなる。ターゲット: ADR-24スライス4（解決済みのクローズドクラスselfコールに対するゲート付きundefined-method）、v0.1.16のインフラ作業で表面化したさらなるエンジン内部の精度向上、そして推論バジェットサーベイとRIGOR_BUDGET_TRACEの所見からのパフォーマンスフォローアップ。

v0.2.0 — 最初の評価リリース

Section titled “v0.2.0 — 最初の評価リリース”

実プロダクトでの試験デプロイを意図した最初の公式発表バージョン。v0.2.0は評価リリースであり、GA / フォーマルバージョンではない — 評価期間を開き、外部のフィードバックを募る。ゲート条件（このリリースが吸収するv0.1.xの「今日はスコープ外」リスト）:

  • ADR-2プラグイン契約サーフェス（surface）が、このモノレポ外の外部rigor-* gem（ADR-31 WD4に基づくgem "rigortype"に依存するサードパーティgem）をサポートできるほど安定化されており、外部著者向けのオンボーディングパスと、ツリー外プラグインがロードされ実行されるテストを伴う。実行可能なエビデンスが着地（v0.1.16）: 外部プラグインフィクスチャ、適合スペック、全プラグインロードスペック、デモ実行スペックがすべてCIにある。残るステップは文書化された安定性コミットメント — ピン留めされたプラグイン契約名前空間に対する「0.2.x内で壊さない」という言明（ドリフトスペックはすでにそれらをピン留めしている）。
  • subtree-split / RubyGems公開フローが少なくともrigor-railsファミリーに対して行使されている。 置き換えられた。配布モデルは単一バンドルrigortype gemに変わった——バンドルされたプラグインはすべてその中で出荷され（プラグインごとのgemspecは削除、コミット9769f5fa）、ADR-31はサブツリー分割をデフォルトパスから撤回した（WD5はサブツリーマージを稀な予約済みオプションとしてのみ残し、計画フローとしては残さない）。したがって行使すべきプラグインごとの公開フローはない;公開される成果物はrigortype自身のみ（既にリリースサイクルに乗っている）。このゲートの残りは最初の項目に畳み込まれる: 外部のサードパーティrigor-*パス（gem "rigortype"に依存する作者自身のリポジトリ + gemspec）。
  • SKILLトリオが出荷済み（v0.1.9）で、新参者がオンボーディングパスを持つ。

v0.2.x — 高完成度の評価ライン

Section titled “v0.2.x — 高完成度の評価ライン”

0.2.xシリーズ全体で、目標は計画された機能セットを高い完成度 / 本番品質に持っていくこと。下記§「将来のサイクル」の需要駆動バックログは、この計画の下では、オープンエンドのキューではなくv0.2.x完成ターゲットである — そこのすべての項目が0.2.xのスコープ内である、Ractor並行性トラックを除いて。

Ractorは意図的に除外されている。ADR-15のRactorワーカープールはRuby 4.0.x上で使用不可と判明した（Ruby Bug #22075に加え決定論的なRactor::IsolationError）;v0.1.8のフォークベースのプールがアクティブなバックエンドだ。RactorプールはRIGOR_POOL_BACKEND=ractorとADR-15 § OQ1の背後にパークされたまま;それを完成させることは0.2.xの目標ではないし、上流CRubyの修正を待つ。

将来のサイクル（特定のリリースにコミットされていない）

Section titled “将来のサイクル（特定のリリースにコミットされていない）”

v0.1.x作業を通じて浮かび上がった項目で、次の実装者がフルスレッドを再読することなく見ておくべきもの。

プラグイン契約——インターフェース分離 + エルゴノミクス（ADR-37/38/39/40）——SHIPPED v0.1.16

Section titled “プラグイン契約——インターフェース分離 + エルゴノミクス（ADR-37/38/39/40）——SHIPPED v0.1.16”

1.0前のプラグインメカニズムレビュー（docs/design/20260601-plugin-mechanism-pre-1.0-review.md）が、大規模なインターフェース分離作業を駆動した——エンジンがASTウォークを所有し各狭い拡張を宣言的にゲートする（PHPStanスタイル）、AI可読でインターフェースごとにテスト可能なプラグイン契約であり、古い太いフックは非推奨の脱出弁として残す。これはv0.1.16で出荷された: ADR-37/38/39/40がAcceptedであり、バンドルされた14個のウォーカープラグインすべてがnode_ruleへ移行され、ボイラープレート削減の作成者ヘルパー層が着地した。完全な詳細はCHANGELOG.md § [0.1.16]に;フェーズ別計画はdocs/design/20260602-plugin-boilerplate-reduction-plan.mdに。

残り（すべて非ゲート、需要駆動のエルゴノミクス;各々が独自の振る舞いを保存するスライス——着地前に各々を検証する）:

  1. dynamic_returnの一般化（オプションのmethods:ゲート／動的レシーバー述語）——脱出弁コンシューマー（rspecのletバインディング、sorbet、activerecord、activestorage）をflow_contribution_forから移行するためのパス。太いフックはサポートされた非推奨の弁であり、それらのコンシューマーは変更なく動作する;これは狭いサーフェスを広げるだけである。
  2. ADR-38ブロック形式のadditional_initializers（ivar書き込みがDefNodeではなく呼び出しブロック内に存在するrspecのbefore／let）——ivar書き込み収集器が宣言された呼び出しブロックへ降りていく必要がある。
  3. インターフェースごとのテストハーネス（NodeRuleTest / DynamicReturnTest）——プラグイン作成者が必要とするまで延期。
  4. ADR-39のフォローオン——スライス3（プロジェクト独自の語形変化のためのconfig/initializers/inflections.rbの静的取り込み;デフォルトのASルールセットが一般的なケースをカバー）、最大忠実度の正確なgemバージョンロード（ターゲットのGemfile.lockに固定されたprocess／ruby_boxワーカー）、rigor-rspec-railsのRackカタログをIsolation経由でルーティングすること、そして上流のRuby::Box VM segfaultが修正され次第のruby_boxの再有効化。
  5. Source::Literals採用の残り——assocキーの名前一致イディオム（el.key.is_a?(SymbolNode) && el.key.unescaped == "x"）は値抽出ではなくキー比較なので、4ヘルパーグリッドの外に位置する;専用のsymbol_named?(node, name)ヘルパーがそれを吸収できるが、独自のスライスである。

脱出弁コンシューマー（sorbet / activerecord / activestorage / rspec-let）、dry-rb/graphqlの純粋なFactProviderプラグイン（移行するものなし）、hanami/web（ADR-28 ProtocolContractChecker——別の共通ベース軸）は、node_rule／スライス2移行のスコープ外であり、現状のまま留まる。

型言語 / エンジン

Section titled “型言語 / エンジン”
  • O2 — マクロテンプレート / heredoc-Ruby展開（ADR-16）。需要駆動の残り項目: スライス5b（Tier Dエンジン統合 — マッチした外部ファイルに対してトップレベルのself_typeをナローイングしbound_ivarsを事前バインド）と合成メソッドティア向けの完全なADR-13リゾルバチェイン配線（パラメータ化形式Array[String] / Hash[K, V]とプラグイン提供のユーティリティ型名をリゾルバチェイン経由でルーティング）。基礎サーベイはdocs/notes/20260515-macro-expansion-library-survey.md。
  • 軽量HKT（ADR-20）。コアキャリア + パーサ + 条件文法 + 主要なMETHOD_RETURN_OVERRIDES（JSON.parse、YAML、Psych、CSV）はすべて着地;ハンドブック第12章も出荷済み。残り（需要駆動）: スライス4（dry-monadsのResult[T, E] / Maybe[T]、ADR-3修正が必要）、スライス5（糖衣構文typeエイリアス）、rigor-lisp-evalでのパターンバインディング抽出、追加のMETHOD_RETURN_OVERRIDES。ADR-20を参照。
  • rigor:v1:conforms-toディレクティブ。元々v0.1.1の「スコープ外」にキューされていた;まだオープン。メソッドパラメータが名前付き構造インターフェースを満たす任意の値を受け付けられるようにする。
  • Cache::StoreのLRU排出。ADR-6に従い、永続キャッシュは設計上「排出なし」でシャード化されている。設定 / 依存関係チャーンを伴う長寿命クローンは、make cache-cleanのみが解放する古いスロットを蓄積する。LRUはキュー、未コミット。
  • プロジェクト側のmonkey-patch事前評価（ADR-17）。pre_eval:設定はライブ。残りの需要駆動フォローアップ: スライス3b（ファイルごとのキャッシュディスクリプタ）、スライス5（フルプロジェクト2パス発見）、スライス6（プラグインAPIフック）。
  • オーバーライドシグネチャ互換性（ADR-35） — スライス1〜4ランディング済み。著作されたクラス/モジュール階層をまたいでリスコフのシグネチャ規則を強制するdef.override-*ルールファミリー: def.override-visibility-reduced（可視性public → protected/private）、def.override-return-widened（戻り値の共変性）、def.override-param-narrowed（パラメータの反変性）。それぞれは証明可能（:no）な違反でのみ発火し、両側著作のシグネチャにゲートされ（可視性ルールは両側観測可能 — 可視性はRBSとは独立にソースで表現される）、severity_profile:を通じてマップされる（lenient → off、balanced → :warning、strict → :error;加算的で、lenientプロジェクトは影響を受けない）。スライス4（Mastodonコーパスの偽陽性検証）はクロスファイル可視性の偽陽性クラスタを発見・修正し（160 → 35;残余はstrictの下でのみ顕在化する真の縮小）、保守的なマッピングを維持した — 書き起こしはdocs/notes/20260529-adr35-mastodon-fp-verification.md。残り（需要駆動、実装時期未定）: スライス5（親が著作 + 子が推論の共変性 — 子の推論された戻り値を著作された親の戻り値に対してチェック;より価値が高く、より偽陽性が高い、推論された戻り値の精度にゲートされる）; WD9の段階1のジェネリックインスタンス化を認識する比較（精度の向上であって偽陽性安全性の要件ではない — 未束縛ジェネリックはすでにDynamic[Top]へ退化する）;型ルールのためのRBSのみの祖先へのリーチ;そしてシングルトン（def self.）メソッドのカバレッジ。ADR-35を参照。
  • 合成メソッドティアのためのADR-13リゾルバチェイン配線（ADR-16フォローアップ）。ADR-13のPlugin::TypeNodeResolverチェインは%a{rigor:v1:…}ペイロード用に配線されているが、基板マニフェストのreturns:文字列用には配線されていない。合成メソッドティアをチェイン経由でルーティングすることが、ユーティリティ型形のTier C戻り値（Array[String]、Hash[K, V]、Pick<T, K>）をアンロックする。ユーティリティ型形の基板消費者からの需要に先送り。（注: クロスプラグインファクト（fact）経由の呼び出しサイトごとの戻り型ルックアップはv0.1.6でADR-18を介して出荷;上記のADR-13配線は直交する「パラメータ化形パーサ」拡張。）
  • Struct / Data値fold。docs/notes/20260523-struct-encoding-coverage.md（2026-05-23）の監査、type-coverage-upliftラインのPhase 5成果物。精密なStruct / Dataメンバーアクセスfold（Point = Struct.new(:x, :y); Point.new(1, 2).x → Constant[1]）はディスパッチティアのエントリーでは到達不能 — 新しいキャリアが2つ必要: 順序付きメンバー名リスト（+ keyword_init:フラグ）でパラメータ化されたstruct-classキャリアと、HashShapeの形をしたクラスタグ付きstruct-instanceキャリア。加えてStruct.newクラスボディブロックの劣化契約、位置指定vs keyword_init: struct、struct継承。ADR相当;不変なData.defineきょうだいがおそらくより良い最初のターゲット（凍結インスタンスが健全性（soundness）ストーリーを単純化する）。リリース未確定。Encoding値foldは同じ監査で恒久的除外として記録 — Constant[Encoding]キャリアがfoldできるのはごく小さなサーフェス（.name / .dummy?）のみ、実際のプログラムはEncodingを不透明タグとして使い、キャリア増加のコストは見合わない;Nominal[Encoding]が答えのまま。
  • カバレッジ認識の診断姿勢（将来のコンセプト — まだ設計されていない）。アイデア: spec / テストカバレッジによって診断の姿勢を変調する — コードがテストで実行される箇所では楽観的に解析し、そうでない箇所では保守的なまま（または注意をエスカレートする）。これはoverview.md §「偽陽性の規律」の価値（実行され、テストでカバーされたプログラムはそれ自身の正確性の証拠である）を、「動作している」ことを機械可読かつ局所的にすることで運用化する: カバレッジマップが、推論後の診断重要度を変調する新しいファクトソースになり、WD6パイプラインのseverity_profileの近くに位置する — 型推論自体は変わらない。柱2（spec → 型ファクト）とは別物;これはカバレッジ → 信頼度だ。これが設計可能になる前に解決すべき懸念:（1）カバレッジ ≠ 正確性 — 「実行された」は「型に関連するエッジケースが実行されアサートされた」ではないので、カバーされたコードに対する楽観的な姿勢は、テストが実行するがアサートしない実バグを抑制しうる;行カバレッジは特に弱く、分岐カバレッジはより良いが依然部分的だ。（2）2つの半分はリスクが非対称だ — 「未カバー → エスカレート」は再優先順位付けするだけで何も抑制しない（安全、純粋にアップサイドのみ）一方、「カバー済み → 抑制」は誤った安心のリスクを持つ;最初のスライスはおそらく未カバーの半分のみであるべき。（3）カバレッジアーティファクト（SimpleCovの.resultset.json / Coverage stdlibモジュール）はprovenance + 陳腐化処理を必要とする外部ファクトソースであり、不在または陳腐化時にフェイルソフトする。（4）ADR-22ベースラインとの可能なシナジー — カバレッジはどのベースラインバケットが「未テスト、ゆえに最初にレビューに値する」かをランク付けできる。ADRなし、スライスなし、コミット済みマイルストーンなし — 方向性としてここに記録。

プラグイン / エコシステム

Section titled “プラグイン / エコシステム”

ガバナンス: ADR-31はプロジェクト全体の貢献・サプライチェーンポリシーである。変更の大きさで貢献を整理する: 軽微で焦点の絞られた変更（バグ修正、ドキュメント改善、タイポ修正、スコープ化されたリファクタ、テスト、既存バンドルプラグインのバグ修正）は任意のパスへの直接PRとして歓迎される;広範な変更（アーキテクチャ的書き換え、コードスタイル一括変更、新規アナライザー機能、新規バンドルプラグイン、ADR / 仕様の撤回）はチームが著作した実装にCo-authored-by:属性を付けたうえで、issue先行の提案を経る。WD2〜WD5のプラグイン固有の想定パス:（1）gem "rigortype"に依存する著者自身のリポジトリ内のサードパーティrigor-<gem> gem（ADR-31 WD4 — MPL §3.3下のLarger Work、完全サポート、デフォルトの想定）;（2）ラップ対象gemがコミュニティ認知に達したときのCo-authored-by:属性付きissue経由のバンドル化昇格（ADR-31 WD2、判断基準はWD3に従って意図的に曖昧）;エンジン / 仕様 / リファクタの提案はWD3の採用エビデンス要件を除き、同じWD2のissue駆動の形に従う。実績あるサードパーティプラグインのsubtreeマージはオプションのパスとして留保される（ADR-31 WD5） — サードパーティ著者が前提とすべきパスではない。

  • rigor-graphql — 将来のスライス（需要駆動）: リゾルバメソッド型チェック、<Type>.array / <Type>!連鎖形、文字列形field :foo, "User"診断、Schema.execute(...)結果型付け。
  • dry-rbアダプタプラグイン（ADR-12）。残り: rigor-dry-schemaのeachを超えるスライス2+サーフェス（ADR-16 Tier C経由の型付きresult.to_h合成 / 行ごとの診断;需要駆動）、rigor-dry-validationスライス2（:dry_schema_table消費経由のparamsブロック型付け） + スライス3（json { ... }パリティ）;rigor-dry-monads（依然Result[T, E] / Maybe[T]キャリア決定が必要 — スライシング計画を参照）。基礎サーベイはdocs/design/20260509-dry-plugins-roadmap.md。
  • ADR-10 — gemソースからの呼び出しごとの戻り型精度。ウォーカーは現在(class_name, method_name) → kindの3つ組のみをカタログ化する。gemソースからメソッドごとの戻り型を推論すること（mode: :fullがDynamic[Top]より豊富に貢献できるように）は、具体的なユーザー需要が表面化するまで先送りされる、より大きなウォーカー拡張。
  • プラグイン提供のRBSシグネチャ。ADR-25が提案された（2026-05-21）: オプションのsignature_paths: Manifestフィールドにより、プラグインgemがRBSディレクトリを貢献でき、Plugin::Loaderによって解決されRBS環境にマージされる。今日RBSのみのバンドルgem（rigor-activesupport-core-ext）を非ポータブルなsignature_paths:パス経由で手配線することを強いるギャップをクローズする。3スライス（マニフェストフィールド + ローダー解決 + 環境マージ → rigor-activesupport-core-extを些細なプラグインに変換 → rigor-project-init SKILLのフォロースルー）;pre-1.0プラグイン契約に加法的、v0.1.x内で安全。コンパニオンフォローアップ（別個、より小さい）: Environment::BundleSigDiscoveryの自動検出をvendor/bundle / .bundle/configレイアウトを超えてデフォルトのbundle install gemパスに拡張する。
  • ADR-28パススコープのプロトコル契約 — オープンエコシステム項目。rigor-actioncableの#receive(data)パラメータ型提供: method_name: :receive, param_types: [{index: 0, type_name: "Hash"}]の契約により、すべてのチャネルのreceiveボディ内でdataがHashとして型付けされる。需要駆動。
  • インラインRBSコメント取り込み（ADR-32）— 着地済み。3スライスすべてとWD10 CLIキャリーオーバーがv0.1.xサイクルで出荷: スライス1（エンジンフック + バンドルrigor-rbs-inlineプラグイン） + スライス2（（コンテンツSHA、プラグインID + バージョン + config_hash）をキーとするファイルごとキャッシュ + envキャッシュ無効化 + 新しいPlugin::SourceRbsSynthesisReporter経由のsource-rbs-synthesis-failedインフォ診断） + スライス3（プラグインREADME + ハンドブック第7章 §「RubyソースへのインラインRBS」） + 単一ファイルアドホックCI用途向けrigor check --treat-all-as-inline-rbs CLIフラグ。WD9のトップレベルdefキャビアットはrbs-inline 0.14.0に対して確認済み（裸のトップレベルdefへの出力なし;エンゲージするにはクラスラップが必要）。残りの需要駆動フォローアップ: 新しいsource_rbs_synthesizer:フックを取り巻くLSPインクリメンタルフロー統合（ADR-19 LSPロードマップ下にキュー済み）。公開APIドリフトサーフェスの全リストはCHANGELOG.md § [Unreleased]を参照。
  • rigor-ffiプラグインファミリー（ADR-30）。コアのrigor-ffiはffi gemの共通機構（extend FFI::Library、attach_function、callback、typedef、enum、bitmask、FFI::Struct/Union/AutoPointer/MemoryPointer/Pointer/Function/Buffer）をカバーし、tenderloveのffx gemが同じDSLの厳密なサブセットを出荷しているため、ffx対象プロジェクトも追加コストなしでサポートする — さらにgemインストール時にffxが拒否する宣言を表面化する新しいffx.unsupported-*診断ファミリーも提供する。ライブラリごとのサブプラグイン（rigor-rbnacl、rigor-ethon、rigor-ffi-rzmq、rigor-sassc）はDSL認識器、オプションカタログ → セッター生成、高レベルAPIのRBSリファインメント（refinement、篩型とも）を貢献する。WD9: 実装は直接の需要よりも非ユーザーオーバーヘッドゼロ（サブプラグインは解決済み依存マッチ時のみアクティブ化）によって正当化される — 想定された4つの消費者すべてで需要は弱い（sassc-rubyはEOL、typhoeus/ethonとrbnaclは特化型、ffi-rzmqはニッチ）。WD10:「バニラ」FFI gem（リテラルなattach_function + 薄いRubyラッパークラス）にはコアで十分であり、プラグインは不要 — 依存を宣言するだけでよい。新しいSKILL .claude/skills/rigor-ffi-plugin-author/SKILL.mdは著者を最初にカバレッジ評価へ案内し（コアで十分なときは著者を著作から思いとどまらせるように設計）、残るケースをプロジェクト全体のADR-31貢献ポリシーへルーティングする。FFI固有の追加: プラグインのgemspecでラップ対象gemのバージョン範囲をピン留めする（孤立プラグインリスクはADR-31 WD4に従いプラグイン著者の責任）。スケッチされた6スライス: コアMVP → rigor-sassc（経験構築） → rigor-ethon → rigor-rbnacl + Plugin::FFI::BindingRecognizer拡張ポイント → ffx対象検出 + 診断 → rigor-ffi-rzmq（ADR-10呼び出しごとの戻り型精度にゲート）。基礎サーベイ: docs/notes/20260525-ffi-library-survey.md。姉妹のrigor-fiddleプラグイン（FiddleのDSLは別個の著作を必要とするほど分岐している）はADR-30のスコープ外と明示される。スライスはスケジュールされていない。

エディタ / IDE統合

Section titled “エディタ / IDE統合”
  • LSP — 並列マルチバッファpublishのためのRactorプール。LSP設計ドキュメントのスライス8は2つの関心事を列挙した: デバウンス（着地）AND Ractorプール統合。プール部分は需要駆動のまま — ワーカーをLSP initializeで1度事前ウォームしpublish全体で再利用できるよう、Analysis::Runnerが事前ビルドされた永続的Environmentを受け入れるリファクタが必要。ProjectContext（スライス7）はすでに読み取り専用Cache::Store経由でpublish + hoverにウォームEnvironmentの勝利を与える;ディスパッチ側並列性（コア全体のマルチバッファpublish）が残りのレバー。需要駆動。
  • LSP — textDocument/definition（設計ドキュメントのスライス9、先送り）。FILE:LINEでキー化されたReflection側のシンボルインデックスが必要。需要駆動。
  • LSP — インクリメンタルdidChange同期（設計ドキュメントのスライス10、先送り）。現在、サーバーはTextDocumentSyncKind::Full = 1をアドバタイズするため、各キーストロークがバッファ全体を再送信する。インクリメンタル（TextDocumentSyncKind::Incremental = 2）はUTF-16オフセット帳簿 + 編集ごとの適用が必要。帯域幅はローカルstdioなのでコストはワイヤではなくパースにある;需要駆動。
  • LSP — まだキューされた拡張機能（v2以降 + フォローアップ後 + ポリッシュ後）: textDocument/codeAction、textDocument/rename、textDocument/semanticTokens、textDocument/inlayHint、textDocument/definition（LSP v1設計のスライス9 — Reflectionシンボルインデックスが必要）、インクリメンタルdidChange同期（LSP v1設計のスライス10 — UTF-16オフセット帳簿）、並列マルチバッファpublishのためのRactorプールディスパッチ（LSP v1設計のスライス8後半 — Runnerリファクタ）、マルチルートワークスペース、TCP / Unixソケット輸送、スニペット展開、素の名前（暗黙のself）補完、シンボル補完、シグネチャ内ハイライトのためのParameterInformationオフセットタプルラベル、completionItem/resolve遅延ペイロード、プラグイン側の補完貢献。
  • エディタモードオプションB — ファイルごとの診断キャッシュ。今日のエディタモードはオプションA（単一ファイルスコープ）を出荷: バッファのみがファイルごとの診断を生成する。オプションB（PHPStan形: プロジェクト全体の解析と1つの代入されたファイル、「編集ファイル + ディペンデントのみ再解析」）にアップグレードするには、（ファイルダイジェスト、プロジェクトEnvironmentダイジェスト）でキー化されたファイルごとの診断キャッシュが必要。ADR-17スライス3bのファイルごとのキャッシュディスクリプタが最も近い既存のレバー。設計: docs/design/20260516-editor-mode.md §「スコープの選択」。需要駆動。
  • CLIエディタモード — ディスクバックProjectScanスナップショットキャッシュ。実装パスはdocs/design/20260518-cli-disk-snapshot-cache.mdに文書化。rigor check --tmp-file=X --instead-of=Yシェルアウトパスをターゲット: プロジェクトのプレパス出力（スキャナ + dep-sourceインデックス + プラグイン公開ファクト）を.rigor/cache/に永続化し、(config + plugin manifest + project file mtime+size + pre_eval mtime+size)でキー化することで、ウォームCLI呼び出しがプレパスをスキップできるようにする。期待される勝利: CLI呼び出しあたり-200 ms（小プロジェクト）から>-1.3秒（基板プラグインを持つ大規模モノレポ）。新しい不変条件: Plugin::FactStoreスナップショットAPI、プラグインファクトのMarshalフレンドリーさ。5フェーズ（Marshal可能なscan / キー導出 / キャッシュプロデューサー / Runner統合 / FactStoreスナップショットAPI）。需要駆動;LSPパスはすでにエディタケースのほとんどをpublishあたり≤5 msでカバーしているので、このスライスは具体的なCLIシェルアウトのエディタ拡張が約1秒の壁をUX問題として報告したときに着手される。
  • エディタモード — プレパス再利用のためのプロジェクトコンテキストスナップショットキャッシュ。LSPパスで着地（v0.1.6、CHANGELOG [Unreleased] § Added）。新しいRigor::Analysis::ProjectScan値オブジェクト + Runner#prepare_project_scanビルダー + Runner.new(prebuilt:)採用パス;LSPのProjectContextがスナップショットを遅延ビルドし、invalidate!でドロップする。CLIエディタモード（rigor check --tmp-file）はまだスナップショットを消費しない、各呼び出しが新鮮なプロセスのため — （plugin-manifestダイジェスト、プロジェクトファイルmtime + サイズリスト）でキー化されたディスクバックのスナップショットキャッシュが、ワンショットCLI呼び出しもプレパスをスキップできるようにする。需要駆動;LSP側の勝利が典型的なエディタ消費者。
  • エディタモード — --also=path,path呼び出し元宣言のディペンデント。エディタ拡張は現在、ディペンデントを更新するためにN個の単一ファイル呼び出しを発行する必要がある。--also付きの単一の呼び出しがそれらをバッチする。些細なCLI拡張;設計ノートはdocs/design/20260516-editor-mode.md。需要駆動。
  • マルチバッファエディタモード（--buffer A=B --buffer C=D）。LSP v1がほとんどのユースケースでこれを置き換える（LSP BufferTableはすでにNバッファを保持する）;非LSPバッチツーリングには引き続き関連。需要駆動。

パフォーマンス / スケーラビリティ

Section titled “パフォーマンス / スケーラビリティ”
  • O4レイヤー3 — Gemfile.lockパース + gem_rbs_collectionバージョンマッチング。v0.1.5のBundleSigDiscovery MVPの上に座る。MVPの自動スキップリスト（SKIPPED_GEMS_BY_DEFAULT）はバージョン管理された解決テーブルになる;rigorはBundler::LockfileParser出力を消費 + ruby/gem_rbs_collectionで最適マッチバージョンをクエリする。O7の失敗メモでアンブロック（競合は今ハングするのではなく警告する）。
  • rigor checkのフォークベースのファイルレベル並列性。ウォームrigor check libのStackprofは推論約50%、Marshal.load約22%、GC約17%を示す。フェーズ4bのRactorパスがv0.1.5の並列性ストーリー;フォークベースのパスは、Ractorが利用不可能なホスト、または事前ウォームされたEnvironmentブロブのCOW共有がRactorごとのenv構築より良い場合の並行（非排他的）オプションのまま。
  • Spec-suiteランタイムブレークダウン（2026-05-17調査;部分的に着地）。make verifyデフォルトが並列rspec（コミット086e507）に切り替わった: wall時間217秒 → 60秒（12コアで3.6×）。フォローオンサイクルが実際のボトルネックは各analyze(sig: …)での呼び出しごとのRBS env再構築であることを確認した: Cache::StoreはRbsDescriptor::FileEntryごとに(path, sha256)でenvをキーするため、各呼び出しの一意のDir.mktmpdirルートのsigパスが新鮮な約1.8秒のenv構築を強制した。ヘルパー側の修正が着地（spec/support/runner_helpers.rb）: コンテンツキー化sigディレクトリ + ソースのみの呼び出しに対する共有ワークスペース。runner_spec.rb 39.6秒 → 25.4秒孤立（-36%）、make verify並列65.6秒 → 52.6秒（-20%）、12コアで。元々キューされた2つのレバーは小さな残りのヘッドルームでオープンのまま:
    • (a) runner_spec.rbの例間でEnvironmentを共有、before(:context)またはlet_it_be形のヘルパー経由で。キャッシュキー修正が呼び出しごとのコストのsig関連コンポーネントをクリアしたので、残りの勝利はソースのみの高速パスを打つ約80%の例に対するEnvironment構築自体。例ごとのプラグイン変動は依然共有を複雑化する。需要駆動;ヘルパー側の修正がすでにほとんどのヘッドルームを吸収した。
    • （b）インメモリAnalysis::Runner.run_source(source:, path:, ...)エントリーポイント。各呼び出しでパス展開 + ワークスペースchdirをスキップ;埋め込み者（LSP / エディタモード）のための今日Runner.new(configuration:).run経由でルーティングされるクリーンなパブリックAPI。ヘルパー修正の上に小さなインクリメンタルなテストデルタ（約5%）だが、安定したパブリックサーフェスとして有用。需要駆動。
  • インメモリAnalysis::Runner.run_sourceエントリーポイント（パブリック + テスト専用）。上記の「Spec-suiteランタイムブレークダウン」フォローアップ（b）と同じ項目;レガシークロスリファレンスのためにここに保持。

Sig-gen（ADR-14）

Section titled “Sig-gen（ADR-14）”
  • --params=observed attr_reader / attr_writer / attr_accessorのinitialize観測からの推論 — 着地済み（コミットf2aa8de、v0.1.9サイクル）。rigor sig-gen --params=observed --writeは、def initializeの@ivar = param代入経由で観測された呼び出しサイト引数型をattr_reader / attr_accessorメソッドに伝播するようになり、:untyped_returnとしてスキップされる代わりに具体的なユニオン（union、合併型とも）戻り型を受け取る。実装: build_observed_ivar_map → collect_init_ivar_obs → ivar_obs_from_initialize（+ build_ivar_obs_type_map / collect_param_obs_types）。新しいロジックはすべてGeneratorに留まりScopeIndexerには触れない。TypeProfコンパチビリティスペック追加（spec/rigor/sig_gen/typeprof_compat_spec.rb）。
  • --params=observed後の残りギャップ（需要駆動フォローアップ）: initialize以外のソース（DB読み込み、設定、副作用）からivarが設定されるattr_readerは依然:untyped_returnにフォールバック;修正は手書きのsigアノテーション。untyped受信者への深いチェーンはrbs collection install / ADR-10が必要。動的メソッド（define_method、DSLマクロ）はプロジェクトプラグインが必要。
  • update_existingがまだ兄弟の親 / 子クラスブロックを畳み込まない。ギャップ（c）のツリービルダー修正はWriter#render_new_file（新規作成パス）に存在する。既存のターゲットファイルを更新する際、merge_classは依然として各候補のclass_nameを独立して解決する — フラット兄弟レイアウトはフラットなまま。既存のファイルをネスト型レイアウトに再フローするには既存の宣言ツリーをパースして書き換える必要があり、フォローアップ修正のスコープ外。正準のネスト型レイアウトを望むユーザーはゼロから再生成する（ターゲットsigファイルを削除して再実行）。

ブラウザプレイグラウンド（ADR-29）

Section titled “ブラウザプレイグラウンド（ADR-29）”

リアルタイム診断とannotateスタイルの型コメントを備えたCodeMirror 6エディタを持つブラウザベースのプレイグラウンド。Fly.io上の薄いRack/Puma APIとCloudflare Pagesの静的フロントエンドでバックアップされる。スライス1〜4がv0.1.xサイクルで着地済み: Tempfileper-request分離 + 64 KB上限 + CORSプリフライトを伴うバックエンド/checkエンドポイント（スライス1）;デバウンスされたlintマーカーを持つCodeMirror 6エディタ（スライス2）;/annotate-linesトグルビュー（スライス3）;CodeMirrorのhoverTooltip拡張経由の/type-ofホバー（スライス4）。スライス1のFly.ioデプロイ成果物（plugins/rigor-playground/Dockerfile + plugins/rigor-playground/fly.toml）とスライス2のCloudflare Pagesデプロイ設定（plugins/rigor-playground/frontend/_headers + _redirects + README）はコミット可能なconfigとして同梱される;実際のfly deploy / wrangler pages deployステップはクレデンシャルが必要で、いかなるランディングサイクルの一部でもない。スライス5（ruby.wasm移行）は需要駆動のまま、3つの外部条件にゲートされている（公式Ruby 4.0 WASMビルド + prism/rbsのWASMパッケージ + WASM下でのRigorテストスイートのパス）。

ADR-29 WD4修正（2026-05-25）が有効: バックエンドはrequire_magic_comment: falseでrigor-rbs-inlineを事前ロードする（ADR-32のWD10に従い）。# @rbs形コメントを持つスニペットは最初のリクエストからインラインRBSとして解析される。index.htmlのシードSAMPLEはADR-32 ascdescパターンでこれを紹介する。ADR-29を参照。

ADRにキューされたオープン研究質問

Section titled “ADRにキューされたオープン研究質問”
  • ADR-15 § OQ1 — RactorごとのCache::Store共有ファサード。今日各ワーカーはキャッシュから自身のRBS envを構築する;OQ1は共有可能なファサード経由でワーカー全体でインメモリenvを共有することを探る。プールのwall-clockがシーケンシャルを上回るクロスオーバー（現在は約1.3〜1.8Kファイル）を下げる。
  • ADR-13 §「オープンクエスチョン」 — 5つのコア関数（pick_of / omit_of / partial_of / required_of / readonly_of）を超えるシェイプ射影サーフェスの拡張。新しいマップ型語彙を追加するときに権威的。

ドキュメント — ユーザー向けドキュメントのオーバーホール（COMPLETE）

Section titled “ドキュメント — ユーザー向けドキュメントのオーバーホール（COMPLETE）”

ユーザー向けドキュメントに対するdoc-coauthoringユーザーフレンドリー化パスは完了しプッシュ済み: ハンドブック（全19ファイル）、マニュアル（全14章 + バンドルされた30個のチェッカープラグインすべてのプラグインごとのページ——「（ii）」分割: 公開マニュアルにコンシューマービュー、開発者／契約資料はスリム化されたplugins/<id>/README.mdに）、そしてdocs/types.mdに対し、章のオリエンテーション + ミニ目次、コールドリード検証済みのアンカー、コード検証済みのドキュメント正確性修正の一括（CHANGELOG.md § [0.1.16]のFixedに記録）。それが表面化させた2件のプラグインコードギャップ（rigor-dry-validationのRBSオーバーレイ配線、rigor-shoulda-matchersの二重プレフィックスのルールID）は修正され、v0.1.16に入っている。移行の手法は将来のプラグイン追加のためにdocs/notes/20260603-plugin-doc-migration-playbook.mdに保存されている。

Railsエコシステムプラグイン（v0.1.xコア作業に並行した実行トラック）

Section titled “Railsエコシステムプラグイン（v0.1.xコア作業に並行した実行トラック）”

フルロードマップはdocs/design/20260508-rails-plugins-roadmap.mdにあります。実行トラックのサマリー:

すでに着地（v0.1.4 → v0.1.6）:

Railsエコシステム以外（v0.1.9でランド済み）:

  • rigor-hanami — Hanami::ActionのためのADR-28 provide-and-check。プロトコル: app/actions/**/*.rb内での#handle(Hanami::Action::Request, Hanami::Action::Response) → void。カスタムスレイアウトのためのaction_path:で設定可能。

保留中のTier 3（特化型、具体的なユーザー需要があれば作成）:

  • rigor-graphqlスライス3+（リゾルバメソッド型チェック;ブラケット形を超える<Type>.array / <Type>!連鎖形;文字列形field :foo, "User"診断;Schema.execute(...)結果型付け）。
  • rigor-dry-schemaスライス2+（ADR-16 Tier C経由の型付きresult.to_h合成 / 行ごとの診断）、rigor-dry-validationスライス2+3（:dry_schema_table消費経由のparamsブロック型付け + jsonパリティ）、rigor-dry-monads（Result[T, E] / Maybe[T]キャリアのためのADR-3修正が必要 — スライシング計画 §「Open observation」のスライシングオプションを参照）。
  • rigor-actioncable #receive(data)パラメータ型提供強化（上記のADR-28エコシステムエントリーを参照;需要駆動）。

各プラグインはrigor-plugin-author SKILLの規律に従ってplugins/rigor-<id>/にステージされ、単一バンドルrigortype gemの中で出荷されます — ADR-31で決着した配布モデル（単一gem、プラグインごとのgemspecはコミット9769f5faで削除）。以前のgit subtree split + プラグインごと公開の計画は廃止された;バンドルされたプラグインは個別にインストール可能なgemではなく、git subtree mergeは実証済みのサードパーティプラグインを取り込むためのADR-31 WD5の稀な予約済みオプションとしてのみ残り、rigor-railsの公開パスとしては残らない。rigor-railsメタgemスキャフォールド（v0.1.6）は、個別公開マニフェストではなく、アクティベーショングルーピングのテンプレートとして機能するようになった（そのadd_dependency宣言はTier 1+2アンブレラを文書化する）。

ADR-9（クロスプラグインAPI）は:helper_table（rails-routes → actionpack）と:model_index（activerecord → actionpack + factorybot）の公開-消費サイクルを介してv0.1.4で着地。ADR-9 §「実装スライシング」に従ったスライシングが部分的なランディングを可能にする。

ADR-16（マクロ / DSL展開基板）はv0.1.5でリリース。3つの動作消費者が基板をエンドツーエンドで行使する — rigor-sinatra（Tier A）、rigor-dry-struct（Tier C）、rigor-devise（Tier B）。基板はWD13フロア + 一般的なケースの精度プロモーション（Tier Bのorigin-module RBSディスパッチ、Tier Cの素のクラス名nominal_for_name）で出荷;Tier Dエンジン統合 + ユーティリティ型戻り値のためのADR-13リゾルバチェイン配線は需要駆動のまま。

ADR-18（基板の呼び出しサイトごとの戻り型DSL）はv0.1.6に向けてmasterに蓄積中。Plugin::Macro::HeredocTemplate::Emit#returns_from_arg（+ lookup_via:クロスプラグインファクトチャネル）を追加;rigor-dry-struct v0.2.0は最初の動作消費者（rigor-dry-typesが公開する:dry_type_aliases経由でattribute :city, Types::StringをNominal[String]に解決）。スライス4（TraitRegistryパリティ） + 連鎖呼び出し引数抽出は需要駆動のまま。

© 2026 TypedDuck. Licensed under CC BY-SA 4.0.