ガバナンス

XTL 仕様と xl3 リファレンス実装について、意思決定がどのように行われるかをまとめます。

本書は意図的に簡素です。プロジェクトの現状(単一メンテナ、形成期)と、採用が広がるにつれて多ステークホルダー型のガバナンスへ移行する経路を説明します。

現状

xl3 は 形成期 にあります。単一のメンテナが以下を兼任しています。

• src/ の著者(TypeScript リファレンス実装)
• spec/ の編集者(XTL 言語の定義)
• spec/decisions/ における ADR の承認者
• すべての PR のレビュアー

この段階のプロジェクトとしては通常の姿です。以下の構造は、決定がどのようにプロジェクトに入ってくるか、そしてコントリビューターが増えるにつれて何が変わるかを示します。

ロール

ロール	責任	誰が担うか
メンテナ	ADR と実装 PR の最終的な承認/却下。リリースの切り出し。	現状はプロジェクトの著者。
仕様エディター	ADR の起草、spec/language.md と spec/evaluation.md の編集。	当面はメンテナ。
ポート著者	XTL を別の言語で実装し、conformance/fixtures/ に対して適合性を測定する。	誰でも可。IMPLEMENTATIONS.md に掲載されます。
コントリビューター	イシューを立て、PR を送り、フィクスチャや ADR を提案する。	誰でも可。CONTRIBUTING.md を参照。

外部コントリビューターが継続的にレビューおよび変更の着地を担うようになれば、メンテナ集合は拡大します。正式な投票プロセスはありません — 適切なタイミングでメンテナ集合を広げ、その瞬間を文書化することをメンテナがコミットします。

プロジェクトに変更が入る経路

実装バグ / 小さな仕様の明確化

• イシューを立てるか、PR を直接送る。
• メンテナがレビュー。
• マージは (a) 規範的な仕様挙動を変えない場合、または (b) 自明に正しい明確化である場合に行われる。

規範的な仕様変更(新規挙動、既存挙動の変更)

仕様変更は ADR プロセス に従います。

1. 発見 — 実利用、フィクスチャ作成、または別実装の文脈で、仕様が沈黙していたり曖昧であったりするエッジケースが浮かぶ。
2. イシュー — そのギャップ、選択肢、関連参照を記述した spec ラベル付きのイシューを立てる。
3. ADR ドラフト — メンテナ(またはコントリビューター)が spec/decisions/0000-template.md のテンプレートに従って spec/decisions/ に ADR を起草する。Context、Considered Options、Decision、Consequences、References を含める。
4. レビュー — ADR を導入する PR 上で議論を行う。承認のバーは「実装ソースを読まずとも、別の実装者が同じ結論に至るに足る根拠が示されている」こと。
5. 承認 — 以下が揃った時点で status: accepted を設定する:
   • 新挙動を示す適合性フィクスチャが少なくとも 1 件存在し、かつ
   • リファレンス実装の変更が同じ PR(あるいはリリース前に着地する後続 PR)に含まれており、かつ
   • メンテナがサインオフしている。
6. リリース — 次のマイナーバージョンで仕様バージョンを上げる。追加的な変更ならマイナー、破壊的ならメジャー。

spec/decisions/ の ADR 群は、規範的な決定とその背後にある推論をすべて記録するプロジェクトの公開アーカイブです。

適合性フィクスチャの追加

フィクスチャは XTL を 実行可能 にする仕組みです。新規フィクスチャはコーパスを拡張します。

1. イシューを立てるか、フィクスチャ提案 のイシューテンプレートに従う。
2. conformance/AUTHORING.md に沿ってフィクスチャを作成する。基本ルール: 期待出力は、リファレンス実装を実行した結果ではなく、仕様から導く。
3. PR を送る。
4. メンテナがレビュー。ADR より承認は早い — フィクスチャは新たな制約を生むのではなく、既存の仕様ルールを文書化するためです。

後方互換性のコミットメント

表面	安定性の約束
仕様 XTL 1.0(リリース後)	破壊的変更は移行ガイドを伴った XTL 2.0 を要する
仕様 XTL 0.x(現在)	破壊的変更は許可。マイナーを上げ、変更と一緒にフィクスチャ更新を出荷する
xl3 npm 1.x(リリース後)	公開 API は src/__tests__/api-surface.test.ts のスナップショットで凍結。改名や削除はメジャー更新を要する
xl3 npm 0.x(現在)	公開 API は変動し得る。意図しないドリフトはスナップショットテストで検出する
エラーコード(xl3/<category>/<id>)	追加のみ。改名は破壊的変更。削除はメジャー更新を要する

意見の不一致

技術的な意見の相違は健全なものです。解決の道筋は以下のとおりです。

1. 具体的なトレードオフを伴ってイシュー/PR で議論する。
2. 合意に至らない場合は、メンテナが判断を下し、ADR の Consequences セクションにその判断を記録する。
3. 後の ADR が以前の ADR を見直し、上書きすることもあり得る。ADR は不変ではなく、ある時点での推論を記録するものです。後の ADR が以前のものを上書きする場合、以前のものには status: superseded をポインタ付きで設定します。

これは意図的に低い儀式性のプロセスです。コントリビューター数が増えれば、このセクションは拡張が必要になるでしょう(投票、RFC 期間、技術運営委員会など)。その拡張は公開のもとで行うことをメンテナがコミットします。

今日プロジェクトに影響を与える方法

xl3 に影響を与える最も効果的な方法は以下のとおりです。

1. 本番で使い、足りないものを報告する。 実際の採用が、優先順位を決める最も強いシグナルとなります。
2. フィクスチャを提案する。 新規フィクスチャは、散文だけでは曖昧な仕様を明確にすることを強制します。受理されない提案でも、たいてい仕様改善のきっかけになります。
3. 別言語に移植して適合性コーパスを実行する。 独立した第二実装はどんなレビューよりも素早く仕様のギャップを見つけます。PORTERS_GUIDE.md を参照。
4. 先送り項目について ADR ドラフトを開く。 spec/decisions/ で先送りされた項目(日付演算、ロケール照合、マルチ結合等)は将来の ADR 候補です — 具体的な提案を歓迎します。

本書の進化のしかた

メンテナ集合が広がった時点で、新しい状態を反映する形(投票 / RFC / TSC プロセス等の採用を含む)に本書を書き直します。それまでは、これが運用上の説明です。