ADR-31 — 貢献およびサプライチェーンポリシー

ステータス: Accepted, 2026-05-25;発効中。

このポリシーはCONTRIBUTING.md、AGENTS.md、およびrigor-plugin-author / rigor-ffi-plugin-author SKILL（Phase 0.5ルーティング）に反映されている。プロジェクト全体の貢献ポリシーを変更の大きさで整理して記録する:

リポジトリ内のあらゆる場所での軽微で焦点の絞られた変更 — コード、ドキュメント、テスト、フィクスチャ、ツーリング — は通常レビューでの直接プルリクエストとして歓迎される。
広範な変更 — 再アーキテクチャ、コードスタイル一括変更、大規模リファクタ、新規アナライザー機能、新規バンドルプラグイン — はissue先行の提案ルートを経る。受け入れられた場合、Rigorチームが実装し、提案者は実装コミットのCo-authored-by:でクレジットされる。
著者自身のリポジトリ内の別個のrigor-* gemとしてのサードパーティプラグインは明示的に歓迎される（WD4）;実績あるサードパーティプラグインのモノレポへのsubtreeマージはオプションのパスとして留保される（WD5）。

プラグインは依然として最も活発に作業されるサブドメインである — WD2からWD5は、一般的なissue先行 / サードパーティ / subtreeマージのメカニズムのプラグイン固有のインスタンスを記録する。

背景

RigorはすべてのユーザーのCI / dev環境で実行される静的アナライザーである — xz-utils（2024）、ua-parser-js、event-stream、そして繰り返されるnpmエコシステムのインシデントに類似した、サプライチェーン攻撃の高いレバレッジ標的だ。外部プルリクエスト経由で挿入された悪意あるコミットは — 解析パス上のどこか、エンジン内部であれバンドルプラグインの認識器であれ — すべての下流ユーザーのコードのすべての解析中にrigorプロセス内で実行される。

サプライチェーンの議論は現実のものだが、コードレビューが確実にキャッチできるものに較正されている。小さく焦点の絞られたPRはマージ時に監査可能である — 差分は小さく、変更はスコープ化されており、悪意のあるパターンは注意深いレビュアーから見える。広範なPR（千行のリファクタ、プロジェクト全体のコードスタイル一括変更、アーキテクチャ的書き換え）はそうではない — 差分を読む認知負荷はマージ時レビューが提供できるものを超え、微妙な悪意ある、または挙動変化を伴う行が忍び込みうる。以下のポリシーはこの非対称性を貢献の形にマップする: 小さなPRは通常レビューで着地し、広範な変更はissue先行の提案を経てチームが意図に関与し実装を所有することで、サプライチェーン保証が他のチーム著作行と同じ強さを保つ。

プラグインは別個のカテゴリーだ。新規バンドルプラグインはエコシステムアイデンティティを定義し（plugins/rigor-foo/は「これがfooのための公式rigorプラグインである」という暗黙のシグナルを持つ）、これはPRごとのレビューを超えたプロジェクトガバナンスの懸念である。プラグイン固有のパス（WD2のissue経由の昇格、WD3の曖昧性、WD4のサードパーティルート、WD5のsubtreeマージ）は、いかなる単一のプラグイン提案の差分サイズに関わらずその境界を扱う。

このADRを書くトリガーはADR-30 WD10の初期ドラフトで、「OSS gemのPRは3つの条件付きで受け入れ」を提案していた。反復的なレビュー（このADRのgit履歴に記録）が「プラグインPRなし」 → 「出荷コードPRなし」 → 現在の変更の大きさによる定式化へと導いた。以前の「出荷コードへのPRなし」フレーミングは粗すぎた: OSSプロジェクトが依存する軽微PRの貢献フローを阻害していた。変更の大きさ軸は実際のリスク / 価値トレードオフを捉えている。

`rigortype`に出荷されるもの

参考のため（以下のポリシーは出荷されるものだけでなくすべてのパスに適用される — しかし何が出荷されるかを知ることは、異なる領域での変更の相対的なサプライチェーン重量を推論するのに役立つ）:

パス	`rigortype`に出荷？	解析中に実行？
`lib/rigor/`（エンジン）	はい	はい
`plugins/`（バンドルプラグイン）	はい	はい
`examples/`（ウォークスループラグイン）	はい	はい
`ext/`（ネイティブ拡張、もしあれば）	はい	はい
`exe/`（CLIエントリーポイント）	はい	はい
`sig/`（`lib/`のRBS）	はい	はい（アナライザーロード時）
Gemspec + 実行可能スクリプト	はい	はい
`spec/`（テストスイート）	いいえ — dev専用	いいえ
`docs/`（このコーパス）	いいえ	いいえ
`references/`（vendoredされた読み取り専用ソース）	いいえ	いいえ
`CONTRIBUTING.md` / `AGENTS.md` / `CLAUDE.md` / `README.md`	いいえ	いいえ
`.claude/` / `.github/`（ツーリング）	いいえ	いいえ

出荷コードへの変更はdocs / testsへの変更よりも差分行あたりのサプライチェーン重量が高いが、両方とも軽微または広範のいずれかでありうる — ポリシー軸はパスではなく大きさだ。lib/rigor/inference/の小さなバグ修正は直接PRとして歓迎される;docs/handbook/の大規模書き換えはissue先行だ。

ライセンスフレームワーク

RigorはMozilla Public License Version 2.0（MPL-2.0）の下でライセンスされている。MPLの語彙（§1、Definitions）は、このADRが著作権、コード由来、そしてバンドルrigortype gemとサードパーティ拡張の境界をどう語るかを形作る:

Covered Software（§1.4）はrigortype gemである — 上表で「スコープ内」として列挙されたすべてのパス（lib/rigor/、plugins/、examples/、ext/、exe/、sig/、gemspec）に加え、それらに対するModifications（§1.10）。
Contributor（§1.1）はCovered Softwareを作成、貢献、または所有する者。各Contributorは§2.1の権利を付与し、§2.5の表明を行う（その貢献は彼ら自身のオリジナル作品である、または付与されるライセンスを認める十分な権利を持つ）。
Contribution（§1.3）は特定のContributorのCovered Softwareだ。
Larger Work（§1.7）はCovered Softwareを他の素材と別個のファイルで結合した作品 — 著者自身のリポジトリ内でgem "rigortype"に依存するサードパーティrigor-<gem> gemが取る形。§3.3はLarger Workを著者選択の条件下で配布することを、非Covered-Software部分について許可する。

以下のポリシーはこれらの語彙に対して自然に読める: WD1はContributionを誰が行えるかを制限し（プラグインだけでなくCovered Software全体に対して）、WD2はContributor状態からの情報的な著作権クレジットを区別し、WD4はサードパーティプラグインを§3.3下のLarger Workとしてフレーミングし、WD5はsubtreeマージがimportされたファイルを§1.10下のModificationsとしてCovered Softwareに取り込むことを記す。

決定

変更の大きさで整理されたプロジェクト全体の貢献ポリシーを採用する。5つの作業決定を伴う:（a）大きさ軸自体 — 軽微PRは直接、広範変更はissue先行;（b）Co-authored-by:属性付きのissue先行提案ルート;（c）プラグイン昇格をゲートする意図的に曖昧な「広く使われている」基準;（d）歓迎されるサードパーティプラグインエコシステム;（e）サードパーティプラグインに留保されたsubtreeマージオプション。

作業決定

WD1 — 変更の大きさによるPR受容性

ポリシー軸は変更がどれほど大きく、どれほどスコープ化されているかであって、どのパスに着地するかではない。

直接プルリクエスト — 歓迎

軽微で焦点の絞られた変更のプルリクエストは、出荷コードを含むリポジトリ内の任意のパスに対して歓迎される。例:

明確なスコープのバグ修正（1〜数ファイル、1つの根本原因）。
ドキュメント改善: タイポ修正、明確化、リンク切れ修正、小規模セクション書き換え。
テスト追加 / フィクスチャ訂正。
ツーリング改善（.github/、.claude/、Makefile調整）。
ADRに記録されたアーキテクチャ的決定を変えない小規模リファクタ。
メンテナンス: プロジェクトポリシー（AGENTS.md）と一致する依存バージョンアップ、CI更新。

ヒューリスティック — WD3の「広く使われている」基準と同様、意図的に非公式 — は「注意深いレビュアーがこの差分を一席で監査でき、有害なものが隠れていないと自信を持てるか」である。そうなら: PRを送り、最初にmake verifyを実行し、CONTRIBUTING.mdに従う。マージ時レビューは実在する: チームは差分を注意深く読み、テストスイートを実行し、マージ前に質問する。

既存バンドルプラグイン（plugins/rigor-*）へのバグ修正はこのパスでカバーされる — 軽微、スコープ化、明確に価値がある。

Issue先行 — 広範な変更のため

以下の種類の変更は直接PRではなくissue先行の提案ルートを経る:

エンジンコードのアーキテクチャ的書き換えまたは非自明なリファクタ（Inference::またはAnalysis::モジュールの配線方法を変えるもの、docs/internal-spec/に記録された契約（contract）に触れるもの）。
新規アナライザー機能、新規診断ファミリー、新規推論パス。
多数のファイルにまたがるコードスタイル一括変更 / フォーマットリフロー。これらはしばしば論争的（スタイル嗜好は個人的）であり、いかなる個別の改善に対しても差分ノイズコストが高い;アラインメントが実装自体よりも重要だ。
新規バンドルプラグイン（plugins/rigor-<gem>/） — プラグイン固有のパスはWD2からWD5を参照。
既存の規範的決定を撤回または修正するspec / ADRコーパスへの変更（追加 / 明確化は軽微PRでありうる）。

これらについて: 提案と合理的な理由を伴うissueを提出する。チームが方向に同意するなら、チームが実装する;提案者はWD2に従って実装コミットのCo-authored-by:でクレジットされる。チームはサンプル実装を参考資料として受け入れることもできるが、直接マージはしない — 再著作がライセンスのクリーンさとサプライチェーン衛生の両方にとってなぜ重要かについてはWD2のノートを参照。

なぜこの非対称性か — 較正されたサプライチェーン重量

マージ時コードレビューは、小さな焦点の絞られた差分（変更全体がレビュアーの作業記憶に収まる）における悪意ある、または挙動変化を伴うパターンを確実にキャッチできる。千行のリファクタ（認知負荷がレビュー能力を超える;微妙な挙動ドリフトが正当に見えるコード移動の中に隠れる）ではそれを確実にキャッチできない。変更の大きさ軸はレビュー能力の非対称性に直接マップする: レビューが信頼できるところでは、直接PRで問題ない;レビューが信頼できないところでは、チームが実装を所有することで、サプライチェーン保証が他のチーム著作行と同じくらい強いままになる。

これはすべての成熟したOSSプロジェクトがナビゲートする同じ非対称性だ;このWDはケースバイケースのメンテナーの裁量に任せるのではなく、rigor固有のカットを明示的にする。

スコープのノート

「軽微」と「広範」の境界は判断であり、意図的にそうだ。確信がなければ、何をしたいかを記述したissueを先に提出する — チームがPRで問題ないか、実装前に設計を議論すべきかを伝える。「issueでわざわざ提出するには小さすぎる」という理由でPRが拒否されることはない;レビュー途中で広範になることが判明したPRは、issueとして再形成するよう求められうる。
すべてのPRはマージ時にMPL-2.0でライセンスされる、既存のCONTRIBUTING.mdノートに従って。貢献者は触れたファイルでMPL §1.1 Contributorになり、PRを提出することで§2.5の表明を行う。これは他のOSS貢献と同じライセンス姿勢だ。

却下された代替案

パスベーススコープ（このWDの以前のバージョン）。「lib/、plugins/、examples/、ext/、exe/、sig/、gemspecへのPRなし」。粗すぎる: OSSプロジェクトが健全なメンテナンスのために依存する軽微PRフローをブロックした。変更の大きさ軸が実際のレビュー能力 / リスクトレードオフを捉える。
どこにも外部PRなし。最大限のサプライチェーン保守性だが、コミュニティ参加のコストを払う。マージ時レビューはスコープ化された変更には十分;「PRなし」は限界増分保証のためにすべての正当な小規模貢献者に課す税だ。
すべてのPRを厳格なコードレビューで受け入れ。広範な差分はマージ時に確実に監査できない;軽微と広範の非対称性は実在し、そうでないふりをすることはissue先行パスが防ぐサプライチェーンリスクを招く。

WD2 — Issue先行提案のメカニクス + `Co-authored-by:`属性

WD1は貢献の形を直接PR（軽微）とissue先行（広範）に分割する。WD2はissue先行パスのメカニクスを記録する。同じメカニクスはあらゆる広範な提案に適用される — エンジンリファクタ、新規アナライザー機能、新規バンドルプラグイン — プラグイン固有のビットはWD3の採用エビデンス要件のみ（エンジン提案には構造的に適用不可）。

一般的な形（あらゆる広範な変更）。提案を記述するGitHub issueを提出する:

何を変えたいか、なぜか（WD1のissue先行スコーピングに従う「合理的な理由」のアラインメント）。
エンジン / リファクタ提案について: どのADR / specが影響を受けるか、考慮された設計の代替案。
オプション: チームが参考資料として読める動作するサンプル実装（自分のフォークまたはgist内）。

Rigorチームはaccept / decline / 「まず設計を反復しよう」で応答する。受け入れられたら、チームはこのリポジトリで変更を実装する。サンプル実装または実質的な分析が提供されたとき、実装コミットはGitHubのCo-authored-by:トレーラーで提案者をクレジットする — 貢献者ごとに1つのトレーラー:

Add foo subsystem

…subject and body…

Co-authored-by: Jane Doe <jane@example.com>

プラグイン固有のissueフィールド。実OSS gemのために公式にバンドルされたプラグインを望むひとは、以下を含むissueを提出する:

ラップされるgemのアイデンティティとホームページ。
コミュニティ採用のエビデンス（基準についてはWD3を参照）。
オプション: 動作するサンプル実装（提案者自身のリポジトリ内またはgistとして）。
オプション: ラップ対象gemのアップストリームメンテナーが並行rigorプラグインを著作していないことの確認。

プラグイン提案について、RigorチームはWD3（採用エビデンス）に対して評価し、accept / declineする（declineの場合は理由付きで）。受け入れられたら、チームはplugins/内でプラグインをスクラッチから再実装し、上記の一般メカニクスに従ってCo-authored-by:で提案者をクレジットする。

Co-authored-by:は情報的な属性であって、MPL Contributor状態の移転ではない。MPL Contribution（§1.3の意味で）は実装を著作するRigorチームメンバーによって行われる;そのチームメンバーは、コードが彼らのオリジナル作品であるという§2.5の表明も行う。提案者のサンプル実装はチームがインポートするテキストではなく、チームがインスピレーションを引き出す参考素材だ;提案者がサンプルを提出する場合、その提出により、それが彼らのオリジナル作品である、または共有する十分な権利を持つことを暗黙に表明する — §2.5の表明と同等だが拡張された礼儀だ。チームはサンプルのコード構造を逐語的に転写するのではなく書き換えるべき、ライセンスのクリーンさのためにも、再著作がissue先行パスの全体の点だから（WD1に従う）でもある。

却下された代替案。広範な変更のための「事前レビューPRそしてメンテナーのシグネチャでsquash-merge」: それでも外部コミットをgit履歴に取り込み、メンテナーが広範な差分のすべての行を著作したというサプライチェーン保証を弱める。再著作されたコミット上のCo-authored-by:が正しい形だ — メンテナーがコードを書き、提案者がそれを情報提供したという明示的なシグナル。

WD3 — 「広く使われている」基準は意図的に曖昧なまま

「この昇格リクエストを受け入れる」基準はコミュニティ認知であって、数値的閾値ではない。

そうではない downloads/day >= NまたはGitHub stars >= K。両メトリックともゲーム可能（ダウンロード操作は既知のエコシステム攻撃パターン;スターファームは存在する）であり、攻撃者が適格性を製造することを許す。
そう以下のようなシグナルに基づくメンテナーの判断: gemが実世界Rails / Rubyサーベイコーパスに現れる;複数の無関係なリクエスター;rigorがすでに解析するプロジェクトの依存として名指される;広く読まれるRubyエコシステムの書き物で引用される。

トレードオフ — 偽造不可能性のための主観性 — は許容可能だ。declineはgemのフットプリントが成長した場合いつでも再考できる。

却下された代替案。厳格な数値閾値: 決定を単純化するが、ゲーミングを招く、これはまさにサプライチェーンポリシーが抵抗しなければならない種類の敵対的圧力だ。

WD4 — サードパーティプラグインは明示的に歓迎される（MPL §3.3下のLarger Work）

rigor-<gem> gemを自分のリポジトリで、gem "rigortype"に依存して著作することは、Rigorチームが（まだ）バンドルしていないあらゆるプラグインに対する完全にサポートされたパスだ。サードパーティプラグインgemはMPL §1.7の意味でのLarger Workだ — Covered Software（require "rigor"経由でロードされるrigorのコード）をプラグイン著者自身のファイル（プラグインのlib/、sig/、gemspec、テスト）と結合する。MPL §3.3下、プラグイン著者はLarger Workを非Covered-Software部分について自分の選択するライセンス条件で配布する、彼らが再配布するCovered SoftwareについてMPLに従う限り。具体的に: プラグイン著者自身のファイルはMIT、BSD、Apache 2.0、MPL、または彼らが望む他の任意のライセンスでありうる;rigorのコードは下流ユーザーが両方をインストールするときMPLのままだ。

これは以下を含む:

プライベート / 社内企業gemラッパー（アップストリーム意図なし）。
（まだ）WD2経由で昇格されていないパブリックOSS gem。
新しいアナライザー形状を探る投機的 / 実験的プラグイン。

rigor-*命名規約はコミュニティ共有だ。プレフィックスを使用しても公式承認を意味しない;ユーザーはインストールするrigor-fooがバンドル済み（このリポジトリのplugins/下）かサードパーティ（他のリポジトリ）かをチェックすべきだ。

サードパーティプラグイン著者のための運用ノート:

ラップされたgemのバージョンピン留め。プラグインのgemspecでラップされたgemのバージョン範囲をピン留めする。ラップされたgemが新バージョンをリリースしFFI / RBSサーフェス（surface）を変えたとき、自分のリポジトリでプラグインを更新する。孤立プラグインリスク（ラップされたgemが進化し、プラグインが進化しない）はプラグイン著者の責任であって、Rigorのものではない。
ライセンス: §3.3に従って自由選択 — MPL-2.0（Rigorと一致）、MIT、BSD、Apache 2.0、またはラップされたgemのライセンスが許可する他の任意のライセンス。プラグインがいつかWD5 subtreeマージのためのモノレポへの候補になることを期待するなら、プラグインを初日からMPL-2.0でライセンスすることで、後の再ライセンスパスなしにそのオプションを開いたままにできる。
発見: Rigorチームは（別個に、このADRではなく）サードパーティプラグイン著者が自分の作品をリストできる情報的カタログ（Wikiページまたはピン留めされたフォーラムスレッド）をセットアップする。リスティングは承認ではない。

計画されたrigor-plugin-author外部ユーザー向けSKILLバリアント（既存のCLAUDE.mdに従いv0.2.0にキュー）がこのパスをエンドツーエンドでカバーする。

WD5 — サードパーティプラグインのsubtreeマージはオプションとして留保される

サードパーティプラグインが重要なコミュニティ採用を達成し、かつその著者がRigorチームへのメンテナンス移管に同意し、かつコードスタイルがRigorの規約に一致するという稀なケースでは、git subtree mergeがプラグインをモノレポに吸収するオプションとして利用可能だ。Subtreeマージは元の著者のコミットを含むgit履歴を保存する — §1.1 Contributor定義下での最も強い形の貢献者承認（importされた各コミットの著者はCovered SoftwareへのContributorになり、§2.5の表明がインポート時に付随する）。

4つの条件すべてが成立しなければならない:

重要な採用 — WD3の曖昧な基準に従う。
メンテナンス移管 — 元の著者がマージ後に進行中のメンテナンスがRigorチームに移ることに同意する（彼らはマージ後も他の誰とも同様にWD2経由で貢献できる）。
スタイルと契約の準拠 — プラグインはバンドル済みプラグインの形（Plugin::Base、signature_paths:、specレイアウト、demoフィクスチャ、CHANGELOG規律）に従う。
ライセンス互換性 — プラグインがMPL-2.0であるか、著者がマージ前にMPL-2.0に再ライセンスすることに同意する。この条件は重要だ: 一度subtreeマージされると、importされたファイルはCovered SoftwareへのModificationsになり（§1.10）、rigortypeの残りと並んでMPL下で出荷されなければならない。MIT / BSD / Apache 2.0 / ISC下のプラグインは標準方向で再ライセンス可能（元の著者がマージ前に自分のファイルをMPL-2.0で再公開する）;GPLファミリーのSecondary Licenses（§1.12）下のプラグインは、MPLがファイル結合レベルでそれらと明示的に互換性があるため適格だが、著者はその変更に同意しなければならない。

Subtreeマージはサードパーティ著者が前提とすべきパスではない。デフォルトの期待は「あなたのプラグインはあなたのリポジトリに無期限に留まる」だ。Subtreeマージは、よく形作られた既存実装と再実装が厳密に冗長になる場合のWD2昇格の時として適切な形だ。

却下された代替案。「subtreeマージをデフォルト昇格メカニズムとして」: WD1サプライチェーン保証が薄まる（サードパーティコミットがモノレポ履歴に入り、Contributorセットが無制限に成長する）。WD2の再実装デフォルトが正しいベースライン（baseline）;subtreeマージは例外だ。

帰結

軽微PRは典型的なOSS速度で着地する。リポジトリの任意のパスに対するバグ修正PRやドキュメント改善は通常レビューに従う — clone、修正、make verify、PRを開く、準備ができたらマージ。これが最も一般的な貢献の形であり、ポリシーはそれを明示的に招待する。
広範な変更は「PRは常に歓迎」規範の下よりも遅い、issue先行の迂回を取るため。カウンタバランス: 明示的な属性（Co-authored-by:） + 提案者が完全な実装を書く前にチームが方向を確認することによる作業投資保護。多くの提案者はとにかくissue先行を好む — チームが異なる方向に行ったであろうと知ってからコードに投資することを避けられる。
軽微 / 広範の境界は判断だ。WD1がこれを明示的にスコープする — 確信がなければ、issueを先に提出し、チームがルーティングする。期待よりも差分が大きくなったPRはレビュー途中でissueとして再形成するよう求められうる。
プラグイン昇格の作業負荷はWD3の「広く使われている」フィルタで制限される。受け入れられたプラグインあたりの再実装コストは現実だが、上限が決まっている — そして提案者のサードパーティプラグイン（提供されたとき）はそれを劇的に削減する（認識器の意図された挙動を文書化し、メンテナーがコードを再著作する）。
出荷コードはゆっくりと意図的に成長する。これは意図的だ — rigortypeに出荷されるすべての行はチームのメンテナンス負担であり、すべての下流ユーザーの信頼サーフェスだ。小さく高品質な出荷セット + 活発なサードパーティプラグインエコシステム + アクティブな軽微PR貢献者ベースが目標だ。
新参者フレンドリー性。ポリシーは全体で読むと歓迎的だ:「軽微PRは任意のパスに対して通常方法で着地する;広範な変更はCo-authored-by:属性付きでissue先行を経る;新規バンドルプラグインについて具体的には、まずサードパーティgemを構築し、採用されたら昇格を提案する」。これは「出荷コードへのPRなし」と読んだ場合のみ非歓迎的だ、これはこのADRの以前のバージョン（現在は廃止）が示唆していた。ドキュメントは軽微PRへの歓迎 + 広範な提案への属性約束 + サードパーティプラグイン歓迎を前景化すべきだ。

実装スライシング

このADRによってスケジュールされたスライス（slice）はない。ポリシーは受け入れ時に効力を発する;ドキュメントロールアウトは機械的だ:

スライス	スコープ
1	ADR-31が着地。ADR-30 WD10はADR-31への参照 + FFI固有ビットのみ（上記WD4に従うラップ済みgemのバージョンピン留め）に単純化する。
2	`rigor-plugin-author` SKILLが更新: 新しいPhase 0.5「このプラグインがどこに住むか」が新著者をWD2 / WD4にルーティング;モノレポ内パスはすでにバンドルされたプラグインのメンテナンスのためだけに保持される。
3	`rigor-ffi-plugin-author` SKILLが更新: Phase 2とPhase 6がADR-31を参照;Phase 3/4がラップ済みgemのバージョンピン留めノートを追加。
4	CLAUDE.mdのADR表がADR-31行を追加;ADR-30行が単純化;SKILL行が更新;既存の「v0.2.0キュー済み外部SKILL」ノートが新ポリシーと和解される。
5	`docs/ROADMAP.md`: プラグイン / エコシステムセクションがトップにADR-31ガバナンス参照を追加;FFIエントリーが単純化される。
6	（延期、スライス未スケジュール。）WD2フィールドを捕捉するプラグイン提案のためのGitHub issueテンプレート（ラップされたgemアイデンティティ、採用エビデンス、サンプル実装ポインタ、アップストリーム努力確認）。
7	（延期、スライス未スケジュール。）サードパーティプラグイン著者が自分の作品をリストする情報的カタログ（Wikiまたはピン留め討論）。

オープンクエスチョン

内部DSLプラグイン。組織内部DSLのためのプラグインはラップされるOSS gemも公的フットプリントもない — WD3の「広く使われている」基準は構造的に適用不可なので、WD2昇格はそれに対して閉ざされている。正直な答えは「これは永遠にサードパーティのまま」、それは問題ないが、著者が来ない昇格を待たないようSKILLに明示的に文書化されるべきだ。
部分的 / 非公式な貢献に対するCo-authored-by属性。提案者の貢献が「issueを提出し3つの明確化質問に答えた」（コードなし）の場合、属性は依然適用されるか？ Leanはyes — 閾値は「コード提供」ではなく「実質的な情報提供」 — だがSKILLで明確化する価値あり。
同じプラグインに対する複数の提案者。5人が時間をかけて独立してrigor-fooをリクエストした場合、5人全員が実装コミットのCo-authored-by:を取得するか、最初の / 最も実質的なものだけか？「実質的に作業を情報提供したすべての人」をleanし、合理的なコミットトレーラー長（〜10エントリー）で上限を決める。
発見カタログのホスティング。Wiki、ピン留めフォーラムスレッド、このリポジトリのdocs/third-party-plugins.md?それぞれが異なるキュレーション / スパム耐性プロパティを持つ。カタログが実際に必要になるまで（つまり非自明なサードパーティプラグイン人口が存在するとき）決定を延期。