spec 1.0 · 規範

ガバナンス

コンテキストレイヤーとウィキを分けるものが、ガバナンスです。その基本モデルは輪です。アクセスは平等でも、権限は平等ではありません。

輪を規範として述べる#

全員が読みます。コンテキストレイヤーにアクセスできるすべての参加者は、人もエージェントも同じく、その全体を読めなければなりません（MUST）。内部でロールによって読み取りを区切ったコンテキストレイヤーは、共有コンテキストレイヤーではありません。人によって読める資料が異なる場合、その資料は別々のコンテキストレイヤーに属します（下のアクセスの境界と distribution.md を参照）。
誰でも提案します。参加者は誰でも、人でもエージェントでも、コンテキストレイヤーへの変更を提案して構いません（MAY）。エージェントが書いた提案は一級です。作業中に足りないコンテキストや間違ったコンテキストを見つけたエージェントは、それを表に出した作業と同じ変更一式の中で修正を提案すべきです（SHOULD）。提案は、レビュアーがその意図と見込まれる効果を理解できるだけの理由を伴うべきです（SHOULD）。その理由が、人が承認するために最低限必要なものです。Leji 1.0 は、一般化された証拠のプロトコルを定義しません（1.0 の適用範囲を参照）。
承認するのは人です。コンテキストレイヤーへのすべての変更は、正典になる前に人によって承認されなければなりません（MUST）。承認は、リポジトリの既存のレビューの仕組み（プルリクエスト）に乗ります。Leji は別のプロセスを持ち込みません。参加はどのインターフェースを通じて行われても構いませんが（MAY）、正典の承認は、その仕組みの中の監査可能なレビュー記録でなければなりません（MUST）。承認した人に帰属し、レビュー対象の変更一式に結び付いたものです。外部の議論、チャット、チケットの状態、文書のコメントの中だけで表明された承認は、そうした記録になるまでは数えられず、それをコメントへ写しても同じです。人の関わり方を広げても、権限が記録される場所が動くことはありません。

要件#

著者ではなく所有者。マニフェストは主たる所有者（owners.primary）を名指ししなければならず（MUST）、継続性の所有者（owners.continuity）を名指ししても構いません（MAY）。後者は、主たる所有者が不在のときや離れたときに同じ説明責任を担う別の人です。支援を受けた導入では、外部の助けが去る前に継続性の所有者を名指しすべきです（SHOULD）。一人で運用するコンテキストレイヤーには、いなくても構いません（MAY）。それは、承継がないことを正直に示します。所有者は説明責任を負う人です。エージェントは提案しレビューしますが、所有することは決してなく、主たる所有者を継続性の所有者として再び挙げても何の備えにもなりません。所有者が説明責任を負うのは、コンテキストレイヤーの健全さです。それがいまのものであり続けること、古くなった内容や矛盾する内容が刈り取られること、そしてどの領域にも手入れをする人がいることです。所有者はキュレーターではありません。内容は、輪の全員が仕事をしながら書き、真であり続けさせるものです。それをひとりの番人に集めることこそ、このモデルが避けようとしているボトルネックです。
レビューの範囲。コンテキストレイヤーの変更は、影響を受ける内容にもっとも近い人たち、すなわち領域の所有者にレビューされるべきであり（SHOULD）、ひとりの門番に集約されるべきではありません。領域の所有は、リポジトリの既存の所有の対応表（CODEOWNERS ファイル、チームの慣習）であって、マニフェストの新しいフィールドではありません。Leji は、承認にプルリクエストを再利用するのと同じように、これを再利用します。すべての領域に所有者がいるようにする説明責任は、主たる所有者にあります。レビューが問うのは「これは真か」だけではありません。なぜこれがコンテキストレイヤーに属するのか、誰がこれを頼りにするのか、それが成り立つことを何が示すのか、いつ見直すべきか。これらに答えられない変更は、リンクかメモであって、正典のコンテキストではありません。あらゆる変更一式について常に立てるべき問いは、この変更はコンテキストを変えたかです。答えが「はい」なら、コンテキストの差分は同じ変更一式に属します。
収録と削除。提案は開かれていますが、収録はそうではありません。内容がコンテキストレイヤーに属するのは、それが今後の仕事のやり方を変える場合だけです。すなわち、制約を定める、決定を記す、インターフェースや所有の境界を定義する、繰り返される間違いを止める、のいずれかです。それ以外はリンクされるのであって、取り込まれません。コンテキストレイヤーは、承認の道筋と同じくらい意図的な削除の道筋を持たなければなりません（MUST）。古くなった内容、取って代わられた内容、重複した内容は、通常のレビューされた変更一式の中で刈り取られ、刈り取りは別立ての掃除プロジェクトではなく、各領域の所有者の務めの一部です。増えるだけのコンテキストレイヤーは、レビューを通りながら腐っていくものです。持続する指針は、二度実証のゲートを通るべきです（SHOULD。content-categories.md に従います）。一度きりの修正はマージして構いませんが、規範が正典になるのは、それが少なくとも 2 つの実際の作業で持ちこたえたあとです。望んでいることではなく、真であることを書き留めてください。
変更履歴の規律。 indexed 以上の適合性では、承認されたコンテキストレイヤーの変更ごとに、machine-readable-surface.md に従って機械可読な変更履歴のエントリを追加しなければなりません（MUST）。
鮮度。鮮度は意図のための仕組みです。意図の文書とエージェントプロファイルは、レビューの期限（インデックスエントリとプロファイルの freshness.reviewAfter）を持つべきであり（SHOULD）、記録は持ちません（その日付がいつ時点の記録かを示します。content-categories.md に従います。記録に宣言された期限は検証エラーです）。ツールは、期限の過ぎた意図の内容を報告すべきであり（SHOULD）、古くなった内容を黙っていまのものとして扱ってはなりません（MUST NOT）。作業のためにコンテキストを読み込む読み手は、読み込んだもののうちレビューの期限が過ぎているものを、その作業の出力の中で示さなければなりません（MUST）。古さが埋もれるのではなく、人に見えるようにするためです。運用上の系列において次に来るはずの記録が遅れているかどうかは、これとは別の概念（ストリームの新しさ）です。1.0 はそれに名前を与えるだけで、仕組みは定義しません。作業の必須のコンテキストとは、ブートプロファイルの無条件の読み込み集合と、有効なエージェントプロファイルの requiredRead と、Task routing のアルゴリズムがその作業のために選ぶ一部（経路に載った live の決定と、経路に載った統制された意図の文書、加えて作業のパスが直接選んだ記録。machine-readable-surface.md に従います）の和です。必須の項目の期限が切れているとき、読み手はそれに基づいて先へ進むのではなく、停止するか尋ねなければなりません（MUST）。レビュー期限を過ぎていると分かっているコンテキストに基づいて動くことは、この規則が防ごうとしている、静かな古さの失敗そのものです。必須でない古い項目は、その古さを注記したうえで使って構いません（MAY）。governed の適合性では、鮮度の期限は宣言され、確認されなければなりません（MUST。適合性のチェックリストに従い、報告だけの確認でも構いません）。そのチェックを CI で実行することが推奨されます。レビューの鮮度（上記）は、チェックアウトの現在性、すなわち読み手が持っている写しが正典のリポジトリと一致しているかどうかとは別のものです。読み手は、チェックアウトの現在性をバージョン管理システム（git）から確かめます。ワーキングツリーは、チェックアウトしたリビジョンの時点でのみいまのものであり、ツールが未検証の写しを黙っていまのものとして扱ってはなりません（MUST NOT）。アクセス可能な git のワーキングツリーもバージョンのメタデータもない、ただのファイル内容としてコンテキストレイヤーに到達した読み手（リポジトリを伴わずに別のインターフェースへアップロードまたは同期されたファイル内容）は、チェックアウトの現在性を、いまのものとしてではなく未知として扱わなければなりません（MUST）。
正典の内容はコンテキストレイヤーの中にあります。仕事のやり方を統制する知識が、ベンダーの設定ファイル、チャットのスレッド、個人のメモの中にだけ存在してはなりません（MUST NOT）。仕事を統制するのであれば、それはレビューの下、コンテキストレイヤーに属します。

アクセスの境界#

Leji は、自前のアクセス制御の仕組みを定義しません。コンテキストレイヤーへのアクセスは、バージョン管理システム（git）と、リポジトリが置かれているプラットフォームによって統制されます。すなわち、リポジトリホストの権限と、ワーキングツリーを見せているファイルシステムまたは共有ドライブです。アクセスの単位はコンテキストレイヤーです。

コンテキストレイヤーは、アクセス制御されたリポジトリに置かれても構いません（MAY）。Leji はそのアクセスを与えも、確認も、強制もしません。それを行うのはバージョン管理システムとそのホストです。
適合するコンテキストレイヤーは、その内部でロールによって区切られた読み取りを要求してはなりません（MUST NOT）。「全員が読む」の範囲は、そのコンテキストレイヤーの読み手に限られます。バージョン管理システムが受け入れた全員が、そのコンテキストレイヤーの全体を読みます。
より狭い読み手を必要とする内容（経営、財務、セキュリティ、インシデント対応の文脈）は、独自のリポジトリ、マニフェスト、所有者、レビューのゲートを持つ別のコンテキストレイヤーに置かれなければならず（MUST）、その権限はバージョン管理システムが与えます。制限された文脈は別のコンテキストレイヤーであって、共有されたレイヤーの中の制限された区画では決してありません。
制限されたレイヤーを別のチームのコンテキストに組み込むのはフェデレーションの場合であり、制限付きマウントについての追加の規則が distribution.md にあります。

保守のモデル（非規範的）#

コンテキストレイヤーは、日々の仕事に組み込まれ、差分ごとに保守されます。作業の中で不足や誤りのあるコンテキストが明らかになり、その修正が同じレビュー対象の変更一式に含まれ、変更履歴に記録されます。ドキュメント専用のスプリントは必要なく、今後も必要ありません。誤ったコンテキストは、その日のうちに誰かが問題を実感するような誤出力を生みます。これにレビューと、仕組みを確認する CI を加えたものが、強制の仕組みの全体です。

この速いフィードバックにより、誤った内容はすぐに検出されます。一方、時間をかけて蓄積する凡庸または冗長な内容は、上記の収録基準と削除の経路に基づき、各領域の所有者が見つけます。これはキュレーションであり、Leji では意図的に分散させています。一人のキュレーターに任せる方法は、品質を保つ安全策に見えて、実際には逆効果です。その人がシステム内で最も遅い経路となり、変更が滞留するか、その人を迂回するようになります。しかも、その人が持つコンテキストは領域の専門家より少ないものです。その結果、コンテキストレイヤーは停滞するか、分裂します。各領域の所有者が担当範囲を整理し、収録基準を守ることで、コンテキストレイヤー全体を小さく正確に保ち、ボトルネックを避けられます。所有者はシステムの健全性を管理し、輪の参加者は内容を管理します。