spec 1.0 · 規範

適合性

段階的に導入できるよう設計されています。4 つのレベルがあり、それぞれが前のレベルを含みます。チームは自分たちのレベルをマニフェスト（conformance.claimedLevel）で宣言します。自己申告のみで、認証プログラムはありません。

適合性は、チェックを実行する場所に実体化されたコンテキストレイヤーに照らして評価されます。その写しが表している可能性のある、正典のレイヤーに照らして評価するのではありません。リポジトリを伴わずに取得した写しは、context-layer.md の縮退モードで読まれます。縮退した読み取りが正典の権威へ至る経路になることはありません。このような写しは検証されず、ツールは判断を保留せず、その事実を明示します。

チェックリストの大半の項目は機械で検証されます。リファレンスのツールがレイヤーに照らして確認し、成立しない宣言を失敗として扱います。報告される結果は 4 種類であり、意図的に互いを置き換えられないようになっています。

• fail: 証拠を収集した結果、要件が満たされていません。
• （プロセスとして申告）、manual として報告されるもの: チームの実践（レビューのゲート、CI のジョブ、外部の利用者）に関する項目で、ツールがリポジトリだけから確認できないため、チームが保証します。この形で報告されるのは、以下で**（プロセスとして申告）**と付された項目だけです。
• unknown: 機械で検証される項目のうち、その実行では証拠が得られなかったもの。たとえば、出典へのアクセスなしでのフェデレーションのピンの到達可能性のチェックや、比較すべき git の基準がない状態での追記のみの規律です。unknown がレベルを与えることは決してなく、証拠を伴う実行なら確認できたはずの宣言を否定することも決してありません。
• not applicable: このレイヤーには当てはまらない条件付きの機械項目。たとえば、マウントを宣言していないレイヤーにおけるフェデレーションのマウントの項目です。採点されず、どちらの方向の証拠にもなりません。

ツールが報告する verifiedLevel は、当てはまる機械で検証される項目がすべて通る最も高いレベルであり、そのレイヤーが宣言しているレベルを上回ることは決してありません。fail も unknown も、レベルの付与を妨げます。プロセスとして申告される項目と当てはまらない項目は採点されません。宣言による上限は意図的です。検証が答えるのは、その宣言が成り立つかどうかであって、そのレイヤーが何を宣言できたかではありません。ですから core を宣言しているレイヤーは、証拠上は governed に届くとしても core と報告され、報告されるレベルを上げる方法は、宣言を上げることです。verifiedLevel がプロセスとして申告される項目を主張することは決してないので、verifiedLevel が通っていることは、それらを含むレベルにとって必要条件ではあっても十分条件ではありません。以下の各項目は、**（プロセスとして申告）**と付されていないかぎり、機械で検証されます。

機械で検証される項目のうち 2 つは、縮退した写しにおいて異なる振る舞いをします。その違いは、それぞれが持つ証拠から導かれます。git の存在には答えが出ます。git リポジトリの中にない写しは、コンテキストレイヤーが git リポジトリの中にあるという core の要件を満たさないので、その項目は fail です。変更履歴の追記のみの規律には答えが出ません。ファイル自体は完全に整っているかもしれませんが、比較に必要な直前のコミット済みの状態に到達できないので、その項目は unknown であり、その写しからは indexed で検証されないというだけです。どちらも manual として報告されることはありません。それは、付されたプロセス申告の項目のために取ってあります。なお、鮮度についての読み手の規則（読み込んだ古いコンテキストを示し、期限切れの必須項目では停止するか尋ねること。governance.md に従います）は読み手の振る舞いであって、適合性のゲートではありません。リファレンスの leji route は、経路に載った各文書にレビューの期限と失効の有無を刻むので、エージェントはそれを適用できます。

3 つの項目は、現時点では述べられた意図ほど深くは検証されておらず、その隔たりは読者が自分で見つけるのではなく、ここで名指しされています。ブートプロファイルの項目は、宣言されたパスに存在すること、そして identity、loading、posture の見出しを備えていることとして検証されます（見出しが欠けていれば validate は毎回 boot-profile-sections の警告として報告しますが、ゲートにはなりません）。Identity 節が実質的なことを述べているかどうかは、任意で有効にする --content のリントに委ねられます。このリントは、プロファイルのどこに残っていてもプレースホルダーのテキストを指摘します。実在する決定の項目は、解決された記録の少なくとも 1 件にスキーマ上妥当なフロントマターがあることとして検証されます。本文の中身（雛形ではなく実際の決定であること）も同じく --content で検査されます。3 つ目が変更履歴の項目です。追記のみの規律は HEAD におけるファイルの状態に照らして確認されるので、ワーキングツリーにまだある書き換え、つまり pre-commit フックが存在する理由となっている場合を捕まえます。継続的インテグレーションのチェックアウトでは、ワーキングツリーが HEAD なので、すでにコミットされた状態で届いた書き換えはこのチェックからは見えず、それを覆うのは変更一式のレビューです。したがってこの項目が検証するのはワーキングツリーであって、履歴ではありません。この 3 つの項目に述べられた意図は、適合するコンテキストレイヤーが備えるものとして規範的であり続けます。機械によるチェックを深めることと、変更履歴を明示的な基準リビジョンに照らして比較することは、リファレンスのツールのロードマップにあります。federated の検証は、さらに、宣言された federation.mounts のエントリが少なくとも 1 件あることを必要とします。提供する側だけのコンテキストレイヤー（他のリポジトリから利用されてはいるが、自らはマウントを宣言していないもの）は governed で検証され、そのフェデレーションにおける立場は、プロセスとして申告される利用の項目に委ねられます。

レベル 1: core#

コンテキストレイヤーが存在し、人もエージェントもそこから仕事ができます。

• コンテキストレイヤーが git リポジトリの中にあり、それが説明する仕事と一緒にバージョン管理されている（context-layer.md の要件に従います）。
• リポジトリルートに leji.json があり、マニフェストのスキーマに照らして妥当である。
• 宣言されたパスにブートプロファイルがあり、identity、loading、posture を扱っている。
• 少なくとも domain か system が（そのインデックスファイルを通じて）割り当てられ、解決される意図の文書を少なくとも 1 件含んでいる（記録だけでは運用上のコンテキストにならないため）。加えて decisions に少なくとも 1 件の実在する決定記録がある。すなわち、具体的な status と、本文に実際の決定を持つ記録であって、空の雛形やプレースホルダーではないもの。
• 名前の分かる主たる所有者がいる。
• ベンダーのエントリポイントファイルは、存在する場合、ブートプロファイルへ誘導している。

レベル 2: indexed#

コンテキストレイヤーがツールから読めるようになっています。

• core のすべて。
• 生成されたコンテキストインデックスがあり、ツリーと一致している。
• 機械可読な変更履歴があり、コンテキストレイヤーの変更がエントリを追加している。

レベル 3: governed#

強制力が善意ではなく仕組みになっています。

• indexed のすべて。
• コンテキストレイヤーの変更がリポジトリのレビューのゲートを通り、人が承認している。（プロセスとして申告）
• エージェントプロファイル（少なくとも core のプロファイル）が、プロファイルのスキーマに照らして妥当である。
• CI がサーフェスを検証している。マニフェスト、ツリーと一致するインデックス、変更履歴の規律、プロファイルのフロントマター、宣言されたパスが解決されること。（プロセスとして申告）
• 鮮度の期限が宣言され、確認されている（報告だけでも構いません）。

レベル 4: federated#

コンテキストレイヤーが、複数リポジトリの組織にまたがっています。

• governed のすべて。
• コンテキストレイヤーが、少なくとも 1 つの他のリポジトリからピン留めされたマウントとして利用されており、ピンの更新がレビュー可能な変更一式として届いている。（プロセスとして申告）
• 古いピンの報告が用意されている。利用側が、自分のピンが証跡となる参照からどれだけ遅れているかを見られること。リファレンスの SDK の系譜を踏まえた報告は、宣言されたフェデレーションのマウントを扱います。それを超える利用側の報告はチームのものです。（プロセスとして申告）
• 兄弟のコンテキストレイヤーがあれば、distribution.md に従う完全なピン留めされたマウントとして宣言されている。正規化された source と、完全なコミットの pin があり、所有が保たれていること。どれか 1 台のマシンでの実体化の状態は、適合性の入力ではありません。
• 宣言された各マウントのピンが、その source の提示された参照（宣言された trackingRef、または出典の既定ブランチ）から到達可能である。このチェックには出典へのアクセスが必要です。それがなければ結果は unknown であり、unknown がレベルを与えることは決してありません。マシンごとのヒントを通じてのみ解決できるピンは可用性であって、適合性ではありません。
• 宣言された各マウントが経路のメタデータを持っている。少なくとも categories、加えて topics か requiredWhen。エージェントが兄弟を読まずに関連を判断できるようにするためです。
• ブートプロファイルがマウントされたすべての兄弟を示し、生成されたインデックスが mounts の経路の配列を持っている。エージェントがマニフェストを読まずに兄弟を見つけて読み込めるようにするためです（boot-profile.md、machine-readable-surface.md に従います）。

補足（非規範的）#

core は、コンテキストレイヤーを実体のあるものにするための最低限のレベルです。indexed では、ツールが読む生成済みサーフェスを追加します。governed は、コンテキストレイヤーの保守を誰かの規律に頼らなくなる段階です。federated は、独立性を保つ価値のあるコンテキストレイヤーを、すでに複数のチームが所有している組織向けです。たいていのチームは governed まで進み、そこで止めるべきです。federated はそのような組織のためのものであり、成熟度を示すバッジではありません。