spec 1.0 · 规范性

一致性

规范有意允许部分接入。四个级别逐级累加，每一级都包含前一级；团队在清单中声明自己的级别（conformance.claimedLevel）。一致性完全由团队自我声明，不设认证计划。

一致性是针对检查执行的位置上实际物化出来的那个上下文层来评估的，而不是针对某份副本可能代表的那个权威层。脱离仓库拿到的副本，按 context-layer.md 的降级模式读取，而降级读取绝不是通往权威性的路径：这样的副本无法通过验证，工具会明确这么说，而不是把问题悬着。

检查清单中的多数条目是机器验证的：参考工具对照该层检查它们，并在不成立时判定声明失败。报告有四种结果，它们刻意不可互换：

• fail：证据已经取得，而该要求未被满足。
• （流程担保），报告为 manual：该条目描述的是团队实践（一道评审关卡、一个 CI 任务、一个外部消费方），任何工具都无法仅凭仓库确认，因此由团队为它背书。只有下文标注了**（流程担保）**的条目才会以这种方式报告。
• unknown：一个机器条目，但本次运行无法取得其证据，例如没有 source 访问权时的联邦固定版本可达性检查，或者没有 git 基线可比时的仅可追加纪律。unknown 绝不授予级别，也绝不推翻一次有证据的运行本可确认的声明。
• not applicable：一个有条件的机器条目，对本层不适用，例如在未声明任何挂载的层上的联邦挂载条目。它不计分，在任何方向上也都不构成证据。

工具报告的 verifiedLevel，是其适用的机器验证条目全部通过的最高级别，且绝不高于该层所声明的级别；fail 与 unknown 都会阻止授予，而流程担保或不适用的条目不计分。对声明设上限是刻意的：验证回答的是这个声明是否成立，而不是这个层本可以声明什么，因此一个声明 core 的层即便证据足以支撑到 governed，报告的依然是 core，而提高所报告级别的办法是提高声明。verifiedLevel 绝不为流程担保的条目背书，因此对携带这类条目的级别而言，verifiedLevel 通过是必要条件而非充分条件。除非标注**（流程担保）**，下文每个条目都是机器验证的。

有两个机器验证条目在降级副本中表现不同，其差别源于各自拥有什么证据。git 存在性是有答案的：不在 git 仓库中的副本不满足 core 对“上下文层存放在 git 仓库中”的要求，因此该条目判为 fail。变更日志的仅可追加纪律则没有答案：文件本身可能完全格式正确，而用来比较的先前提交状态却不可达，因此该条目为 unknown，该层从那份副本出发就是无法在 indexed 上通过验证。两者都不会报告为 manual，那是为标注了流程担保的条目保留的。另外，时效性的读取者规则（呈现已加载的过期上下文，并在必需条目过期时停下或发问，见 governance.md）是读取者的行为规则，不是一致性关卡：参考实现的 leji route 会为每份被路由的文档标注复核期限与是否过期，供智能体据以执行。

有三个条目今天的验证深度低于它们所陈述的意图，这里把差距点明，而不是留给读者自己去发现。引导配置那一条，验证的是它在所声明路径上的存在性，以及它是否带有身份、加载与姿态这三个标题（每次 validate 都会把缺失的标题以 boot-profile-sections 告警的形式报告出来，不设关卡）；而身份那一节是否真的写了实质内容，则由可选开启的 --content 检查负责，这项检查也会指出引导配置里任何位置的占位文本。“真实决策”那一条，验证的是至少一份被解析到的记录具有 schema 合法的 frontmatter；正文是否有实质内容（一个真实的决策，而非空壳）同样依赖 --content。变更日志那一条是第三个：仅可追加纪律是对照文件在 HEAD 处的状态检查的，这能抓住仍在工作树中的改写，也正是 pre-commit 钩子存在的那种情形。在持续集成的工作副本中，工作树就是 HEAD，因此一次已经提交进来的改写对该检查不可见，此时是变更集的评审来兜住它。所以这一条验证的是工作树，不是历史。这三条各自陈述的意图，对于一个符合规范的上下文层应当携带什么，仍然具有规范性；加深机器检查，以及对照一个明确的基线版本比较变更日志，都在参考工具的路线图上。此外，federated 的验证还要求至少有一条已声明的 federation.mounts 条目：只作为提供方的上下文层（被其他仓库消费、但自身不声明任何挂载）验证到 governed，它的联邦地位依托于那些流程担保的被消费条目。

级别 1：core#

上下文层已经存在，人和智能体都能基于它工作。

• 上下文层存放在一个 git 仓库中，并与它所描述的工作一起纳入版本管理（见 context-layer.md 的“要求”）。
• 仓库根目录有 leji.json，且对清单 schema 有效。
• 在所声明的路径上有一份引导配置，涵盖身份、加载与姿态。
• 至少映射了 domain 或 system（经由其索引文件）并已填充至少一份被解析到的意图文档（只有记录不承载任何运作上下文），外加 decisions 且至少有一份真实的决策记录：一份携带具体 status、正文中有真实决策的记录，不是空壳或占位内容。
• 有一位具名的主负责人。
• 厂商入口文件若存在，重定向到引导配置。

级别 2：indexed#

上下文层对工具可读。

• core 的全部内容。
• 一份生成的上下文索引，与代码树保持一致。
• 一份机器可读的变更日志；上下文层的变更会追加条目。

级别 3：governed#

强制手段是机制性的，而不是靠善意。

• indexed 的全部内容。
• 上下文层的变更搭载仓库的评审关卡；由人来批准。（流程担保）
• 智能体配置（至少一份 core 配置）对配置 schema 有效。
• CI 校验这个接口：清单、索引与代码树一致、变更日志纪律、配置 frontmatter、所声明的路径可解析。（流程担保）
• 复核期限已声明并被检查（仅报告式即可接受）。

级别 4：federated#

上下文层跨越一个多仓库组织。

• governed 的全部内容。
• 该上下文层被至少一个其他仓库作为固定版本挂载消费，且固定版本的更新以可评审的变更集形式到来。（流程担保）
• 过期固定版本的报告已经就位：消费方能看到自己的固定版本落后见证 ref 多少。参考 SDK 那份知晓祖先关系的报告覆盖了已声明的联邦挂载；此外消费侧的报告由团队自理。（流程担保）
• 任何同级上下文层都按 distribution.md 声明为完整的固定版本挂载：一个归一化的 source 与一个完整的提交 pin，且归属完好。任何单台机器上的物化状态都不是一致性的输入。
• 每个已声明挂载的固定版本，都能从其 source 所公布的某个 ref 到达（所声明的 trackingRef，或 source 的默认分支）。这项检查需要 source 访问权：没有它则结果为 unknown，而 unknown 绝不授予该级别。只能通过机器本地提示解析到的固定版本，属于可用性，不属于一致性。
• 每个已声明的挂载都携带路由元数据：至少 categories，加上 topics 或 requiredWhen，使智能体无需读取同级层即可判断相关性。
• 引导配置呈现每一个已挂载的同级层，且生成的索引携带 mounts 路由数组，使智能体无需读取清单即可发现并加载同级层（见 boot-profile.md、machine-readable-surface.md）。

注记（非规范性）#

core 是上下文层成立的最低要求；indexed 增加了供工具读取的、自动生成的机器可读接口；达到 governed 后，上下文层不再依赖个人自律；federated 则面向这样的组织：其中已有多个团队，各自拥有值得完整保留的上下文层。多数团队达到 governed 即可；federated 专为上述组织设计，并不是成熟度徽章。