治理
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。 |
當外部貢獻者能穩定地審查並落地變更時，維護者陣容就會擴大。沒有正式的投票流程 — 維護者承諾在合適的時機擴大陣容，並把那個時刻記錄下來。
變更如何進入專案
實作 bug／小型規範澄清
- 開一個議題或直接送 PR。
- 由維護者審查。
- 在 (a) 不改動規範性行為，或 (b) 是顯而易見的澄清時合併。
規範性變更（新行為、改既有行為）
規範變更走 ADR 流程：
- 發現 — 一個真實的邊界情境（使用上、撰寫測試案例時、或某個移植中）揭露規範未說明或有歧義。
- 議題 — 開一個
spec議題，描述落差、可考慮的方案、相關交叉引用。 - ADR 草稿 — 維護者（或貢獻者）依
spec/decisions/0000-template.md範本，在spec/decisions/中起草一份 ADR。內容包含 Context、Considered Options、Decision、Consequences、References。 - 審查 — 討論發生在引入 ADR 的 PR 上。接受門檻是：「論述足以讓第二位實作者在不讀實作原始碼的情況下得到相同決策」。
- 接受 — 當以下條件滿足時，將
status: accepted設定上去：- 至少有一個符合性測試案例展示新行為，且
- 參考實作的對應變更在同一個 PR 中（或在發佈前的後續 PR 中落地），且
- 維護者簽核。
- 發佈 — 下一個 minor 版本提升規範版本號：若變更為新增則 minor，破壞性則 major。
spec/decisions/ 內的 ADR 是本專案每項規範性決策與其理由的公開紀錄。
新增符合性測試案例
測試案例是讓 XTL 可執行 的關鍵。新增測試案例會擴大語料庫：
- 開議題或循「fixture proposal」議題範本提案。
- 依照
conformance/AUTHORING.md撰寫測試案例。 首要規則：預期輸出來自規範，而非執行參考實作的結果。 - 送 PR。
- 由維護者審查。比起 ADR 通常更快通過，因為測試案例的約束較小 — 它記錄既有規範規則，而非建立新規則。
向後相容承諾
| 介面 | 穩定性承諾 |
|---|---|
規範 XTL 1.0（切版後） | 破壞性變更需推 XTL 2.0 並附移轉指南 |
規範 XTL 0.x（當前） | 允許破壞性變更；提升 minor；變更時同步出貨測試案例更新 |
xl3 npm 1.x（切版後） | 公開 API 凍結在 src/__tests__/api-surface.test.ts 的快照。重新命名或移除需 major 升版 |
xl3 npm 0.x（當前） | 公開 API 仍可能調整；快照測試會抓到意外漂移 |
錯誤碼（xl3/<category>/<id>） | 僅新增。重新命名屬破壞性。移除需 major 升版 |
意見不一致時
技術上的不同意見是健康的。解決路徑如下：
- 在議題／PR 上以具體取捨討論。
- 若無共識，由維護者做判斷，並在 ADR 的 Consequences 章節寫下緣由。
- 未來的 ADR 可以重新檢視並取代舊的 ADR。ADR 不是永恆不變的；它記錄的是某個時刻的論述。當較新的 ADR 取代舊的 ADR 時，舊的會被標示為
status: superseded並附指標。
這是刻意採用低繁文縟節的流程。隨著貢獻者增加，本章節將需要擴充（投票、RFC 期、技術指導委員會等）。維護者承諾這項擴充會公開進行。
今天能如何影響專案
最有效影響 xl3 的方式：
- 在生產環境使用，並回報缺什麼。 真實採用是決定優先順序最強的訊號。
- 提出測試案例。 新測試案例會強迫規範比純文字描述更清楚。即使提案未被接受，通常也會觸發規範改善。
- 移植到第二種語言並執行符合性語料庫。 第二份獨立實作找出規範落差的速度比任何審查都快。詳見 PORTERS_GUIDE.md。
- 針對被延後的項目開一份 ADR 草稿。
spec/decisions/內被延後的項目（日期運算、語言環境排序、多重 join 等）都是未來 ADR 的候選 — 歡迎提出具體方案。
本文件如何演進
當維護者陣容擴大時，本文件會重寫以反映新狀態 — 包含採用的任何投票／RFC／TSC 流程。在那之前，這就是目前的工作描述。