spec 1.0 · 规范性

治理

治理是上下文层区别于 wiki 的关键。其核心语义就是圆环：平等的是访问权，而不是决定权。

圆环的规范表述#

所有人都读取。所有参与者，无论是人还是智能体，只要能访问某个上下文层，就必须能够读取它的全部内容。一个在其内部按角色限制阅读的上下文层不是共享上下文层；当不同的人只能读到不同的材料时，那些材料就应当分属不同的上下文层（见下文的访问边界以及 distribution.md）。
任何参与者都可以提议。任何参与者，无论是人还是智能体，都可以提议对上下文层的变更。智能体撰写的提议是一等的：智能体在工作中发现上下文缺失或有误时，应当在引出该问题的同一个变更集中提议修复。提议应当携带足以让评审者理解其意图与预期效果的理据；那份理据是一个人做出批准所需的最低限度。Leji 1.0 没有定义通用化的证据协议（见 1.0 的范围）。
由人来批准。对上下文层的每一次变更，在成为权威内容之前必须经过一个人的批准。批准搭载仓库既有的评审机制（拉取请求）；Leji 不引入单独的流程。参与可以通过任何界面发生，但权威的批准必须是该机制中一条可审计的评审记录：可归属到批准人，并绑定在被评审的变更集上。仅存在于外部讨论、聊天、工单状态或文档评论中的批准，在它成为这样一条记录之前不算数；把它复述进一条评论也不算。拓宽人们的参与方式，绝不改变批准权记录在哪里。

要求#

归属，而非署名。清单必须指名一位主负责人（owners.primary），并可以指名一位延续负责人（owners.continuity）：另一个人，在主负责人不在或离开时承担同样的责任。有外部协助的接入应当在外部协助撤离之前指名延续负责人；单人维护的上下文层可以没有，这诚实地表明它没有继任安排。负责人是承担责任的人：智能体可以提议与评审，但绝不承担归属，而把主负责人再写一遍充作延续负责人等于没写。负责人对上下文层的健康度负责：它保持最新，过期或自相矛盾的内容被裁剪，每个领域都有人照看。负责人不是内容策展人。内容由整个圆环在工作过程中书写并保持真实；把这件事集中到一个看守者身上，正是这套模型要避免的瓶颈。
评审范围。上下文层的变更应当由最贴近受影响内容的人来评审，也就是领域负责人，而不是汇集到单一把关人手中。领域归属沿用仓库既有的归属映射（CODEOWNERS 文件、团队约定），不是清单里新增的字段；Leji 复用它，正如它复用拉取请求来完成批准。主负责人负责确保每个领域都有人。评审要问的不止“这是不是真的”：为什么它属于上下文层、谁会依赖它、什么证明它成立、以及什么时候该重新审视它。回答不了这些的变更是一条链接或一则笔记，不是权威上下文。任何变更集都要面对的常设问题是这次变更是否改变了上下文？；如果是，上下文的增量就应当在同一个变更集里。
纳入与移除。提议是开放的；纳入不是。内容只有在会改变未来工作的做法时才属于上下文层：它设定约束、编码决策、定义接口或归属边界，或者终止某个反复出现的错误。其余的只做链接，不做吸收。上下文层必须拥有一条与其批准路径同样审慎的移除路径：过期的、被取代的与重复的内容，在日常的、经过评审的变更集中被裁剪，而裁剪是每位领域负责人的职责，不是一个单独的清理项目。一个只增不减的上下文层，会一边通过评审一边腐烂。持久性的指引应当通过“两次验证”门槛（见 content-categories.md）：一次性的修复可以合并，但一条规范只有在至少两项真实任务中都成立之后才成为权威。沉淀真实成立的东西，而不是期望成立的东西。
变更日志纪律。在 indexed 及以上一致性级别，每一次被批准的上下文层变更必须按 machine-readable-surface.md 追加一条机器可读的变更日志条目。
时效性。时效性是意图的机制：意图文档与智能体配置应当携带复核期限（索引条目与配置中的 freshness.reviewAfter），而记录不携带（它的日期本身就是它的时效，见 content-categories.md；在记录上声明期限是校验错误）。工具应当报告期限已过的意图内容，并不得把过期内容悄悄当作当前有效。为某项任务加载上下文的读取者，必须在该任务的输出中呈现任何复核期限已过的已加载条目，使陈旧对人可见，而不是被埋没。运营序列中下一份应有的记录是否逾期，是另一个概念（流式新近度）；1.0 只是点出它，并未为它定义机制。一项任务的必需上下文，是引导配置无条件加载集合、当前生效智能体配置的 requiredRead，以及任务路由算法为该任务选出的那一片（它路由到的 live 决策与受治理意图文档，加上任务路径直接选中的任何记录，见 machine-readable-surface.md）三者的并集。当某个必需条目的期限已过期时，读取者必须停下或发问，而不是照此推进；明知上下文已过复核期仍据以行动，正是这条规则要防止的“无声陈旧”失败。并非必需的过期条目可以在标注其陈旧状态后使用。在 governed 一致性级别，复核期限必须被声明并被检查（按一致性检查清单，仅报告式的检查即可接受）；推荐在 CI 中运行该检查。复核时效（上文）与工作副本时效是两回事：后者指读取者手上的副本是否与权威仓库一致。读取者从版本控制系统（git）确定工作副本时效；工作树只对所检出的那个版本是当前的，工具不得把未经验证的副本悄悄当作当前有效。以普通文件内容接触上下文层、且没有可用的 git 工作树或版本元数据的读取者（文件内容被上传或同步到另一个界面，而仓库并未随行），必须把工作副本时效视为未知，而不是当前有效。
权威内容存放在上下文层里。治理工作方式的知识不得只存在于某个厂商配置文件、某段聊天记录或某个人的笔记中。若它治理工作，它就属于上下文层，并接受评审。

访问边界#

Leji 自身没有定义任何访问控制机制。对上下文层的访问由版本控制系统（git）与仓库所在的平台治理：仓库托管平台的权限，以及暴露工作树的文件系统或共享盘。访问的单位就是上下文层。

上下文层可以存放在受访问控制的仓库中。Leji 不授予、不检查、也不强制执行那种访问权；版本控制系统与它的托管平台才做这件事。
符合规范的上下文层不得在其内部要求按角色限制阅读。“所有人都读取”的范围是一个上下文层的受众：凡版本控制系统准许进入的人，都读取该上下文层的全部内容。
需要更窄受众的内容（高管、财务、安全或事故响应类的上下文）必须存放在一个单独的上下文层里，拥有自己的仓库、清单、负责人与评审关卡，并由版本控制系统授权。受限的上下文是一个单独的上下文层，绝不是共享上下文层中的一块受限区域。
把一个受限层组合进另一个团队的上下文，属于联邦的情形，并适用 distribution.md 中针对受限挂载的附加规则。

维护模型（非规范性）#

上下文层以小步增量的方式维护，并融入原本就在进行的工作：任务暴露出缺失或错误的上下文，修复随同一个经评审的变更集提交，再由变更日志记录。无需专门安排文档冲刺。错误的上下文会产生错误结果，而且通常当天就会被察觉；这种反馈与评审、CI 自动检查共同构成完整的强制机制。

快速反馈可以及时发现错误的内容。至于缓慢积累的平庸或冗余内容，则由各领域负责人依照上文的纳入门槛和移除路径处理。这属于内容策展，而 Leji 有意将其分散。由单一策展人把关看似稳妥，实际上会让其成为系统中最慢的环节：变更要么排队等待，要么绕过把关人，而单一策展人掌握的上下文通常也不及各领域专家。最终，上下文层不是停滞，就是分裂。由每位领域负责人分别裁剪和把关自己负责的部分，才能让整个上下文层保持精简、真实，并避免形成瓶颈。负责人维护系统的健康度，圆环中的参与者维护内容。