本书定义 100_body 与 200_lab 两个项目材料区的职责、对象类型、依赖方向、更新规则、交叉引用规则和评判标准。

100_body 是当前正文主区。该区存放当前有效、当前成立、可被后继对象依赖的 body objects。200_lab 是研究与治理区。该区存放开放问题、候选术语、方案比较、提案、变更计划、审核包、状态台账和关闭记录。

本书的核心断言是：当前承重对象与治理过程对象必须分区。100_body 承担项目知识基础设施的存在支撑；200_lab 承担项目自身演化的研究、评价、执行、审核和追溯。200_lab 可以依赖 100_body 发起和约束治理活动；100_body 的核心对象不得依赖 200_lab 的草稿、账本或过程记录来成立。

本书服务材料体系作者、项目书籍维护者、实例作者和审核者。读者使用本书判断内容应进入 body 还是 lab，判断 lab 结果是否具备进入 body 的资格，判断实例材料是否存在层位混淆、引用方向错误、状态记录污染或术语漂移。

本书不定义某个具体软件项目，不提供 AsciiDoc 语法教程，不记录材料体系的形成过程。具体项目应当形成自己的 100_body 与 200_lab，并在自己的材料空间中独立成立。

本书的规则面向书籍化项目材料。书籍化项目材料可以由 AsciiDoc book 承载，也可以由具备稳定目录、交叉引用、版本记录和构建检查能力的同类载体承载。本书使用 100_body 与 200_lab 作为物理分区名称，是为了固定承重正文与治理过程的依赖方向，不是为了替代 specification、proposal、work package、review package、baseline 等既有工程对象。

项目当前事实也可以由代码、测试、配置、用户文档、样例和发布材料共同表达。本书不把这些事实承载物全部归入 100_body 或 200_lab；本书定义书籍化材料区如何为这些事实承载物提供当前对象入口、治理入口、证据记录和归档位置。

本书使用中文叙事。body、lab、body object、lab object、specification、proposal、work package、baseline、review package、status ledger 等术语在正文中保留英文形式或中英并列形式，以保持对象边界和公共工程坐标的稳定。

长期项目不会只由代码承载。项目对象、公共入口、协议、实现、测试、用户文档、提案、审核记录、发布记录和历史归档共同构成项目材料体系。不同材料承担不同职责。把这些材料只按文件格式、目录位置或篇幅划分，会遮蔽它们在项目中的存在作用。

项目材料首先按职责分化。部分材料定义当前对象，承担后继对象可以依赖的正文支撑；部分材料记录问题、候选、比较、变更、审核和关闭，承担项目自身演化的治理支撑。前者面向当前理解和后继依赖，后者面向协作过程和历史追溯。

材料职责决定物理位置。物理分区不是排版选择，也不是按页数切割。一个区可以包含多本书，一本书也可以包含多个 part 和 chapter。物理分区成立的原因，是材料的消费动作、依赖方向、生命周期和更新语义不同。

材料职责先于材料名称。名为 specification、reference、proposal、plan 或 ledger 的材料，只有在承担相应职责时才取得对应身份。一个名为 specification 的文件如果只记录未关闭讨论，它仍属于治理对象；一个名为 plan 的文件如果定义当前公共契约，它已经越过计划职责并占用了正文定义位置。

项目材料体系把项目视为一个封闭的协作世界。该世界中的“当前事实”不是现实世界中所有真实发生的事情，而是项目材料在当前版本下承认并允许后继对象依赖的事实。治理记录也是真实发生的事实，但它们只说明项目如何演化，不自动成为当前承重事实。

事实承载物是表达、实现、验证或发布项目当前事实的材料。代码、测试、配置、用户文档、样例、发布说明和书籍正文都可以成为事实承载物。

事实承载物不因文件类型取得承重资格。代码可以实现当前契约，但代码本身不自动说明对象边界、术语和验收事实；测试可以验证当前契约，但测试本身不自动成为当前对象定义；用户文档可以表达当前公共行为，但用户文档不应承担内部设计规格的全部职责。

100_body 是事实承载物中的当前正文入口。它用对象语言定义当前对象、边界、契约、术语和验收事实。代码、测试、配置、用户文档、样例和发布材料围绕 current body 形成实现表面、验证表面、使用表面和发布表面。

200_lab 管理事实承载物的受控变更。一个 lab object 可以修改 body 文件、代码、测试、配置、用户文档、样例和自身治理记录；这些文件一旦进入变更范围，就必须进入工作包边界、审核证据和关闭记录。

事实承载物之间发生冲突时，不能让读者在材料之间自行推断当前事实。冲突应进入 200_lab，由 proposal、evaluation、implementation plan、review package 或 closure record 处理；处理完成后，受影响的 current body、实现表面、验证表面和使用表面应重新收敛到同一当前事实。

当前承重对象是项目当前承认、当前有效、可以被后继对象依赖的对象。它们定义项目是什么、对象边界在哪里、公共契约如何成立、术语如何使用、验收事实如何判断。

治理对象是项目演化过程中产生的对象。它们记录开放问题、候选术语、方案比较、提案、实现计划、迁移计划、审核包、状态台账和关闭记录。治理对象可以解释某个当前事实的形成过程，但它们不承担当前正文对象的存在性。

承重对象与治理对象都可以记录事实。差异不在真假，而在职责。承重对象记录当前可依赖事实；治理对象记录研究、决策、执行、审核和关闭事实。治理事实不能替代当前承重事实。

承重对象的消费者可以把对象内容作为当前依据使用。治理对象的消费者只能把对象内容作为过程依据、审核依据或追溯依据使用。一个治理对象即使记录了已经发生的命令、提交和审核结论，也不能因此定义当前 API、当前协议或当前术语。

把治理对象放入正文承重区，会让当前读者必须阅读过程材料才能理解当前对象。迁移计划、未关闭提案、旧输出快照、允许失败集合和审核返工记录如果占据正文核心位置，后继对象会依赖尚未承担承重资格的过程材料。

把承重对象放入治理区，会让稳定对象失去可依赖位置。公共契约、当前规格、术语定义和验收事实如果只存在于提案、计划或审核记录中，后继实现、测试和文档无法判断哪个材料是当前事实来源。

误置还会破坏审核。审核者无法判断某个变更是在修改当前对象，还是只是在记录研究过程；执行者也容易把计划语言写成对象定义，或者把对象定义隐藏在状态记录里。材料分区的作用，是让当前对象和治理过程分别承担自己的成本。

误置会扩散到后继材料。后继测试、实现、文档或实例如果依赖治理对象中的未关闭内容，项目会把候选状态当作当前状态继续传播。后继材料如果找不到承重对象，只能从提案、计划或审核包中推断当前事实，项目知识基础设施就失去单一承重点。

事实承载物之间的误置还会制造沉默冲突。代码实现一个行为、测试验证另一个行为、body 描述第三个行为时，项目没有稳定 current body，也没有可审查的变更路径。此类冲突必须按 变更控制 处理，而不能靠材料读取顺序决定胜负。

100_body 是正文主区。这里存放的对象都是当前有效、当前成立、能够被后继对象依赖的 body objects。body object 与代码、测试、配置、用户文档、样例等事实承载物的关系见 事实承载物。

100_body 承担以下职责：

100_body 是承重区。它不得依赖 200_lab 中的提案、草稿、状态台账、审核记录或关闭记录来成立。200_lab 可以解释某个 body object 的形成过程，但该解释不是 body object 当前成立的必要前提。

100_body 的编号表达材料体系中的承重优先级。编号不表示 body 在时间上先于所有 lab 活动完成，也不表示 body 永远不变。编号只规定依赖方向：治理区可以围绕正文对象开展工作，正文核心对象不能以治理区对象作为成立前提。

200_lab 是研究与治理区。这里存放的对象不承担正文存在性，但承担项目演化的研究、评价、执行、审核和关闭治理。

200_lab 承担以下职责：

200_lab 依赖 100_body。它可以引用 body object 发起问题、约束提案、界定变更范围和判断完成状态。200_lab 不反向支撑 100_body 的成立。lab 结果进入 body 的条件由 进入条件 定义。

200_lab 可以包含已经完成的治理对象。完成状态不改变对象所属分区。一个已关闭 migration plan、一个已通过 review package 或一个已归档 proposal，仍然是 lab object；它们解释项目演化，不变成 body object。

200_lab 到 100_body 的引用是治理依赖。一个 issue 可以引用 body 中的对象边界；一个 proposal 可以引用 body 中的当前契约；一个 implementation plan 可以引用 body 中的目标规格；一个 review package 可以引用 body 中的验收事实。

100_body 核心章节不得依赖 200_lab 才能被理解。当前规格不得要求读者阅读某个迁移计划才知道当前字段含义；当前术语不得要求读者阅读某个候选讨论才知道所指；当前验收事实不得要求读者阅读审核包才知道对象是否成立。

200_lab 的结果进入 100_body 之前，只是治理结果。提案被接受、变更被审核、迁移被关闭以后，其结论可以通过受控更新进入 100_body。进入以后，100_body 写当前对象事实，不保留治理过程作为核心定义。

依赖方向不禁止追溯。body 可以在历史索引、版本索引或参考坐标中指向 lab object，但这种引用只服务历史定位。当前对象定义不得要求读者沿追溯引用才能理解对象本体。

100_body 面向当前读者、维护者、实现者、测试作者、后继对象作者和当前项目消费者。读者进入 100_body，是为了知道项目当前是什么、能依赖什么、如何判断当前对象。

200_lab 面向当前协作者、执行者、审核者、协调者和历史追溯者。读者进入 200_lab，是为了知道哪些问题打开、哪些方案被比较、哪些变更正在执行、哪些提交通过审核、哪些对象已经关闭。

消费面按动作区分，不按身份固定。同一个人维护当前对象时读取 100_body，执行迁移时读取 200_lab，追溯历史时读取归档 lab object。

消费动作决定入口。读者要判断当前对象、当前术语或当前公共契约时，入口是 100_body。读者要判断某个变更为何发生、如何执行、是否通过审核或为何关闭时，入口是 200_lab。

入口语义定义读者进入材料时能够执行的动作。入口不是目录链接的同义词；入口必须说明材料当前承担的对象职责。

Current body entry 是当前对象入口。它指向当前有效的 body object，使读者能够判断项目当前是什么、哪些契约可以依赖、哪些验收事实成立。

Active lab entry 是当前治理入口。它指向仍在打开、评估、执行、待审核或打回状态的 lab object，使执行者和审核者能够定位当前治理动作。

Archive entry 是追溯入口。它指向旧版本 body、关闭的 proposal、完成的 implementation plan、migration plan、review package、status ledger 和 closure record，使追溯者能够理解历史过程。

同一书架可以同时存在三类入口。Current body entry 不应被关闭的 lab object 抢占；active lab entry 不应伪装成当前对象入口；archive entry 不应以当前入口语义呈现旧版本或关闭过程。

100_body 随项目版本演化。任一当前版本下，body object 应当描述当前有效事实。旧版本 body 可以作为历史版本保留，当前主线 body 不应承载旧版本迁移过程。

200_lab 具有治理状态。lab object 可以处于打开、评估、执行、待审核、打回、通过、关闭或归档状态。关闭后的 lab object 保留历史价值，但不成为当前 body 的核心入口。

生命周期不同是物理分区的依据。当前正文对象应保持可依赖；治理对象应保留过程证据并允许关闭。

同一项目可以经历多轮治理。每轮治理可以产生新的 lab object，也可以修改 body object。治理结束后，更新后的 body 成为当前入口；已完成的 lab object 保留为过程证据。下一轮治理以当时的 current body 为依据，而不是复用上一轮 lab 的过程文本作为当前定义。

body object 是进入 100_body 的承重对象。一个 body object 必须具备当前有效性、对象边界、依赖关系、术语稳定性和验收方式。

当前有效性表示该对象描述的是项目当前承认的对象事实。对象边界表示该对象说明自己负责什么、不负责什么。依赖关系表示该对象说明哪些后继对象可以依赖它，以及它依赖哪些同区或上游 body object。术语稳定性表示该对象使用的关键术语具有明确所指。验收方式表示该对象能够说明如何判断自身被满足、被实现或被破坏。

body object 还应说明自身与相关事实承载物的关系。一个 API contract 应说明哪些实现表面和测试表面受它约束；一个 acceptance facts 章节应说明哪些验证表面观察它；一个 user-facing current documentation 应说明它表达哪个公共契约。无法说明关联表面的 body object，会让后继实现、测试和文档只能凭经验推断当前事实。

body object 可以被更新、替换或废弃，但这些动作必须通过治理过程进入。body object 不能把未关闭争议、候选方案或执行状态写成当前对象事实。

body object 的成立还要求读者动作明确。一个 body object 应说明谁可以依赖它、依赖它完成什么判断、哪些后继对象受它约束。不能说明消费动作的正文材料，不能仅凭排版位置取得承重资格。

常见 body object 包括 specification、reference、standard、current design、protocol definition、API contract、terminology、acceptance facts 和 user-facing current documentation。

Specification 定义对象规则和公共契约。Reference 提供当前可依赖的查询入口。Standard 规定跨实现或跨协作者必须遵守的规范。Current design 描述当前设计结构。Terminology 稳定术语所指。Acceptance facts 定义对象满足条件。User-facing current documentation 面向使用者表达当前公共行为。

实现代码、测试用例和配置通常不是 body book 内部章节，但它们可以是 current body 约束下的事实承载物。代码承担实现表面，测试承担验证表面，配置承担运行约束表面。它们与 body 不一致时，应按 变更控制 发起修正。

这些类型不是必备清单。一个项目是否需要某类 body object，由项目对象复杂度、消费动作和后继依赖决定。类型名称不能替代对象边界；名为 specification 的材料如果只记录未关闭提案，仍然不是 body object。

同一 body object 可以同时承担多个类型职责。一个 protocol definition 可以同时是 specification 和 reference；一个 terminology 章节可以同时支撑 API contract 和 acceptance facts。类型重叠不改变进入条件：材料仍必须表达当前有效对象事实。

100_body 使用对象语言。对象语言描述当前对象是什么、边界在哪里、关系如何成立、公共契约如何被依赖。

body 核心定义不得叙述作者过程。设计来源、讨论路径、打回过程、迁移步骤和临时状态只有在它们本身被定义为当前对象时，才进入 body；否则留在 200_lab 或历史归档。

body 中的例子不能替代规则。例子只作为规则的投影出现。排除语句只在阻止高成本误读时出现；排除不能替代正面定义。

body 中的术语一经定义，应在同一对象范围内稳定使用。一个术语不能在当前契约、历史过程和候选方案之间滑动。

body 中的兼容性说明必须表达当前可依赖规则。兼容性说明可以写当前版本仍接受哪些旧输入、旧字段或旧入口；不能把历史迁移过程写成兼容性规则。读者应能从兼容性说明中判断当前行为，而不是重建历史。

body 中的引用必须服务当前对象。引用公共坐标时，应说明该坐标稳定哪个对象；引用同区对象时，应表达当前依赖关系。引用不能用于装饰，也不能把未关闭 lab 讨论带入核心定义。引用方向规则见 交叉引用方向。

一本 body book 可以很大。part、chapter、appendix、xref 和 include 用于组织同一承重对象的不同方面。物理分书不由页数决定，而由对象职责、消费面、依赖方向和生命周期决定。分书判断见 物理分书规则。

同一 body book 内部可以包含对象边界、输入契约、结构模型、公共出口、验收事实、术语表和参考坐标。这些章节共同支撑同一个当前对象时，应留在同一 body。

当材料服务不同当前对象，或一个材料是当前正文，另一个材料是治理过程，物理分书才成立。章节结构不能把治理对象伪装成正文对象。

Body book 的 appendix 也属于 body 的公共表面。附录可以承载术语表、索引、参考坐标、验收清单或版本索引；附录不能借由位置靠后而容纳未关闭提案、状态台账或审核返工记录。治理材料进入 appendix 仍然是误置。

body 可以更新。更新后的 body 应呈现当前对象语言，而不是保留变更过程作为核心定义。

更新 body 的动作由 200_lab 治理。proposal、migration plan、review package 和 status ledger 可以记录为什么更新、如何更新、哪些提交完成更新。更新完成后，body 核心章节只表达更新后的当前事实。

body object 不必在每个章节重复通用更新流程。材料体系级规则可以定义通用进入条件、变更控制和审核要求；具体 body object 只在存在特殊变更入口、额外审核条件或特殊兼容性约束时定义自身更新规则。

历史解释可以通过版本记录、归档 lab object 或专门历史材料保存。历史解释不得成为当前对象定义的必要路径。

更新 body 的提交应能被审查为正文更新。审核者应检查更新后的 body 是否保留当前对象语言，是否移除了临时过程词，是否同步更新相关术语、引用、验收事实和后继依赖。只修改正文片段而不检查依赖面的更新，不构成完整 body 更新。

body 更新还应检查相关事实承载物。正文更新如果改变公共契约，应检查代码、测试、用户文档、配置和样例是否受影响；如果判断不受影响，review package 应记录该判断。未检查关联表面的正文更新，会留下 current body 与实现表面或验证表面的潜在冲突。

lab object 是进入 200_lab 的治理对象。一个 lab object 必须说明它治理的问题、依赖的 body 事实、当前状态、预期产物和关闭条件。

治理的问题可以是开放议题、术语候选、方案比较、设计提案、实现计划、迁移计划、审核事项或状态记录。依赖的 body 事实用于限定问题范围。当前状态用于表达该 lab object 处于打开、评估、执行、待审核、打回、通过、关闭或归档中的哪一位置。

lab object 不承担 body 当前存在性。它可以改变 body 的候选未来，可以记录 body 变更证据，但不能在未进入 body 前成为当前对象事实。

lab object 必须保留自身身份。一个 proposal 不因内容成熟而自动成为 body；一个 plan 不因执行完成而自动成为 body；一个 review package 不因结论通过而自动成为 body。对象身份改变只能通过进入 body 的受控动作发生。

常见 lab object 包括 open issue、open question、term candidate、proposal、spike report、ADR、comparison、evaluation、implementation plan、migration plan、work package、review package、status ledger 和 closure record。

Open issue 记录尚未关闭的问题。Term candidate 记录术语收口前的候选。Proposal 提出可进入 body 的变更。Spike report 记录探索证据。ADR 记录已接受的设计决策及其上下文。Comparison 和 evaluation 比较候选方案。Implementation plan 和 migration plan 组织受控变更。Review package 记录审核证据。Status ledger 投影过程状态。Closure record 记录治理对象的关闭结果。

ADR 的默认职责是记录决策上下文、候选、取舍和后果。ADR 的接受结论如果约束当前对象，应通过 进入动作 写入 body 的 current design、architecture reference 或相关 specification。若某项目把 accepted ADR 作为当前设计入口，该 ADR 必须满足 body object 的成立条件；否则它仍是 lab 或历史记录。ADR 这一公共坐标用于锁定设计决策记录与当前设计之间的关系，见 [adr]。

这些对象可以在同一个 lab book 内按 part 或 appendix 组织。它们共同服务同一治理过程时，不需要因类型不同而物理拆书。

Lab object 类型决定读者动作。Open issue 用于判断问题是否仍需处理；proposal 用于判断候选变更是否可接受；implementation plan 用于判断工作如何执行；review package 用于判断状态转移是否有证据；status ledger 用于定位当前治理状态。类型名称和读者动作不一致时，应优先修正对象边界，而不是保留名称。

Proposal 是进入 body 的候选变更，不是当前 body。Proposal 必须说明它修改哪个 body object、解决哪个问题、引入什么新事实、排除什么旧事实、需要什么验收。RFC 和 PEP 作为公共坐标，用于锁定 proposal、acceptance 与 current specification 之间的分层关系，见 [rfc] 与 [pep]。

评价材料比较 proposal 或候选方案。评价可以记录优点、缺点、风险、成本、证据和未决问题。评价没有自动进入 body 的资格。只有被接受的结论，经过受控更新，才能成为 body 当前事实。

未接受的 proposal、被拒绝的 proposal 和被替代的 proposal 应保留关闭状态。它们保留历史价值，但不应继续占据当前 body。

Proposal 不应同时承担 implementation plan 职责。Proposal 可以提出目标 body 变更和验收方向，但不安排提交顺序、文件边界和批次状态。执行安排进入 implementation plan 或 migration plan。

Implementation plan 和 migration plan 是 lab object。它们定义受控变更如何执行，不定义目标对象本身。

变更计划必须说明源状态、目标 body 依据、工作包边界、文件边界、验证命令、提交规则、审核规则和打回条件。目标对象来自 body 或已接受 proposal；变更计划不能凭空发明目标对象。

变更计划可以管理 body 文件、代码、测试、用户文档、配置和自身过程记录的修改。被管理的文件进入工作包边界；变更计划本身不因此成为 body。

变更计划启动前应具备可审查目标。目标可以来自 current body，也可以来自已接受 proposal。尚未形成目标的探索活动应留在 spike report、evaluation 或 proposal 中。变更计划不能把探索过程和持久材料修改放入同一工作包。

Work package 是受控变更的工作单元。一个 work package 必须有明确目标、上游门槛、输入事实、文件边界、实施任务、测试任务、验收标准、验证命令、提交规则、审核规则和打回条件。Work package 的边界、交付物和验收职责由工作分解结构中的工作包坐标锁定，见 [wbs]。

Work package 不是时间段，也不是随手任务。它的完成必须能通过证据判断。一个工作包完成以后，应产生可追踪提交、实际命令结果和审核结论。

工作包可以按 batch 命名。Batch 编号表达治理顺序或依赖关系，不表达对象本体。阶段安排不能替代对象定义。

工作包边界应覆盖所有被修改的事实承载物。代码、测试、body 文件、用户文档、配置、样例和 lab 记录只要进入本批修改，就必须进入文件边界和审核范围。工作包不得把文档更新、测试更新或台账更新视为附带动作而省略。

工作包可以发现缺口，但不能私自扩大目标。执行中发现目标事实不足、影响面遗漏或验收条件错误时，应记录打回、拆分或补充 proposal。继续在同一工作包中即兴定义新目标，会破坏审核边界。

Review package 是工作包状态转移的证据记录。它记录批次编号、提交 hash、修改文件、完成范围、未处理对象、已运行命令、命令结果、检查清单和审核结论。

审核包不是进度汇报。它只记录实际发生的证据。计划运行但未运行的命令不能写成通过；失败命令必须记录失败状态、失败范围和是否属于已授权的非阻塞对象。

审核包使审核者能够把书面声明、Git diff、验证命令和审核决定连接起来。

审核包应区分完成范围和未处理对象。完成范围只列本工作包已经实现并由证据覆盖的对象事实；未处理对象必须指向后续 lab object、明确非目标或关闭理由。未处理对象不能以“后续再说”的形式悬空。

Status ledger 是治理状态的投影。它记录 lab object 或 work package 的当前状态、提交 hash、审核记录和关闭位置。

状态台账只记录治理事实。愿望、估计、口头进度、情绪判断和未发生动作不得进入台账核心字段。台账可以记录 打开、评估中、执行中、待审核、打回、通过、关闭、归档 等受控状态。

状态台账服务当前协作者快速定位过程状态。它不定义项目当前对象。

状态台账字段应受控。状态字段、提交 hash、审核记录、关闭位置和备注各自承担不同职责。备注可以说明已发生的打回、返工或受审例外；备注不能写入预测、承诺、情绪判断或未授权目标。

状态词表定义 status ledger 可以使用的受控状态。状态词不是自然语言备注；每个状态必须表达可审查的治理位置。

打开 表示治理对象已经登记但尚未形成结论。评估中 表示治理对象正在比较候选、收集证据或形成提案。执行中 表示已接受目标正在由 work package 执行。待审核 表示工作包或 lab 结果已经提交审核。打回 表示审核结论要求补充事实、拆分范围或修正实现。通过 表示提案、决策或工作包已经获得进入下一动作的审核结论。关闭 表示治理对象已经结束并记录结果去向。归档 表示关闭对象不再承担当前入口，只保留追溯价值。

项目可以定义本地状态词，但本地状态词必须说明与上述治理位置的关系。状态词不得表达预测、愿望、情绪判断或未授权目标。

Closure record 记录 lab object 的结束方式。结束方式可以是接受、拒绝、替代、废弃、完成或归档。

关闭记录应说明关闭对象、关闭理由、结果去向和后续入口。被接受的结果应指向进入 body 的位置或变更提交；被拒绝或废弃的对象应说明不再承担当前治理职责。

关闭不是删除。关闭后的 lab object 保留追溯价值，但不继续占据当前执行入口。

关闭记录应阻止治理对象继续漂移。一个关闭的 proposal 不再继续收集候选；一个关闭的 migration plan 不再继续接收新工作包；一个关闭的 review package 不再改变审核结论。需要追加变更时，应开启新的 lab object 并引用旧对象作为历史依据。

lab 结果进入 body 之前，必须具备进入条件。进入条件包括对象边界明确、术语稳定、影响面已测量、验收方式明确、冲突已处理、审核结论存在。进入条件依赖 body object 的成立条件 与 lab object 的成立条件。

对象边界明确，表示该结果说明自己修改哪个 body object、增加什么当前事实、移除什么当前事实、排除哪些相邻对象。术语稳定，表示关键词已经具备明确所指。影响面已测量，表示相关 body 文件、代码、测试、用户文档、配置和样例已经被识别。验收方式明确，表示进入 body 后可以被检查。冲突已处理，表示相关提案、旧契约和相邻对象不会继续争夺同一位置。审核结论存在，表示该结果经过治理区的判断。

未满足进入条件的 lab 结果不得进入 body。它可以继续留在 proposal、evaluation、spike report 或 open issue 中。

进入条件必须由 lab 记录证明。只有口头确认、单个执行者判断或未审查草稿时，进入条件不成立。进入条件的证据可以来自已接受 proposal、review package、evaluation 结论、测试结果、构建结果或明确关闭记录。

进入条件不要求所有未来问题被穷尽。它要求当前进入 body 的对象边界、影响面和验收方式足够明确。未知对象应保留为风险、非目标、后续 proposal 或相邻 lab object，不能随正文事实一起进入 body。

进入 body 不是复制 lab 文本。进入动作是把已经接受的对象事实写入 body 的当前对象语言。

Proposal 中的动机、候选比较、否决路径、执行顺序和讨论过程留在 lab。进入 body 的内容只保留当前成立的对象定义、边界、契约、术语和验收事实。

进入动作必须保持 body 的承重能力。读者阅读更新后的 body，应能直接理解当前对象，而不需要回到 proposal、迁移计划或审核包才能知道对象是什么。

进入动作应同步更新相关 body 表面。一个对象事实进入 body 时，相关术语、索引、交叉引用、验收事实、公共契约和后继依赖都应被检查。只把结论写入一个段落而不更新关联 body 表面，会留下不一致的当前事实。

进入动作还应同步检查非书籍事实承载物。若进入 body 的事实改变代码行为、测试观察面、配置语义、用户文档、样例或发布说明，变更控制必须把这些材料纳入影响面。若某一表面不需要修改，审核记录应说明不受影响的依据。

进入动作不得复制 lab 的状态语言。执行中、待审核、打回、允许失败、临时保留 等治理状态词只能在它们定义当前兼容性契约时进入 body。否则它们保留在 lab。

修改 body 的动作由 lab 治理。变更控制材料应说明源基线、目标 body 依据、修改文件、验证命令、提交规则、审核规则和打回条件。源基线、目标基线、change control 和 traceability 由配置管理坐标锁定，见 [cm]。

源基线是变更开始前的可引用项目状态。目标 body 依据是变更完成后应成立的 body object 或已接受 proposal。修改文件包括 body 文件、代码、测试、用户文档、配置、样例和必要的 lab 记录。

变更控制不替代对象定义。它只说明如何把已具备资格的目标事实落实到项目材料中。

变更控制应覆盖事实承载物的同步关系。Body 文件、代码、测试、用户文档、配置和样例如果共同表达同一当前事实，变更计划必须说明这些材料如何在同一目标下收敛。只更新实现而不更新 body，或只更新 body 而不更新验收材料，都会产生事实集合不一致。

变更控制可以分批执行。分批不改变目标事实的边界。每个工作包只承担目标事实的一部分时，状态台账和审核包必须说明该部分与整体目标的关系，并说明未处理部分的去向。

变更控制应区分设计准入与实现兑现。目标事实尚未接受时，应先停留在 proposal、evaluation、spike report 或 ADR 中；目标事实已经接受后，implementation plan 或 migration plan 才能组织持久材料修改。把探索和持久材料修改放入同一工作包，会使审核者无法判断是在审查目标，还是在审查目标兑现。

进入条件不满足时，审核者应打回 lab 结果。打回记录留在 lab，说明打回对象、打回依据、需要补充的事实或需要拆分的范围。

已经进入 body 的内容如果被发现错误，应通过新的 lab object 处理。新的 lab object 可以提出修正、回退、替代或废弃。直接在 body 中保留混乱过程，会削弱 body 的当前承重能力。

回退不是删除历史。被回退的变更仍然通过 Git、审核包、状态台账和关闭记录保留追溯路径。

回退后的 body 应恢复为可依赖的当前对象语言。回退原因和失败过程保留在 lab；body 核心章节只表达回退后的当前事实。若回退导致旧版本事实重新成立，相关术语、验收事实和公共文档也应同步检查。

迁移完成后，body 应呈现迁移后的当前对象。迁移计划、旧输出快照、允许失败集合、分批解除记录、打回记录和最终门禁证据保留在 lab 或归档材料中。

当前 body 不应长期保留“迁移期间”“旧实现曾经”“本阶段暂时”这类过程语言，除非这些表达本身定义当前兼容性契约。兼容性契约必须说明当前读者可以依赖什么，而不是叙述历史。

迁移清理的目标，是让当前维护者通过 body 理解当前项目，通过 lab 追溯变更过程。

迁移清理应检查当前入口。目录、索引、README、catalog、书架首页或发布说明如果仍把迁移 lab 作为当前理解入口，会误导读者。完成后的入口应指向 current body；迁移 lab 保留为历史或治理入口。

迁移清理不抹除证据。旧版本 body、迁移 lab、审核包、状态台账、release note 和 Git 历史共同保留追溯路径。清理动作只移除当前 body 中的过程污染，不删除治理证据。

交叉引用表达对象依赖。200_lab 可以引用 100_body，用于限定问题、提出变更、约束计划和判断验收。100_body 核心章节不得依赖 200_lab 才能成立。依赖方向由 依赖方向 定义。

body 内部引用应连接当前对象之间的依赖关系。lab 内部引用应连接议题、提案、计划、审核包、状态台账和关闭记录之间的治理关系。

历史 lab object 可以被 body 的历史索引或版本索引引用，但 body 当前对象定义不应要求读者沿该引用才能理解对象本体。

交叉引用应具有可说明的关系。引用目标可以是对象依赖、治理依赖、历史索引、证据定位或术语坐标。不能说明关系的引用会增加解释空间，应从核心正文移除。

Body 到 lab 的引用只允许出现在历史索引、版本索引、参考坐标或明确的追溯表面。该引用不得成为理解当前对象字段、当前接口、当前规则或当前术语的必要路径。

物理分书由对象职责决定，不由篇幅决定。同一承重对象的多个方面，可以在一本 body book 中使用 part 和 chapter 组织。同一治理过程的多个工作包、审核包和台账，可以在一本 lab book 中组织。分书判断应同时检查 消费面、入口语义 和 生命周期。

出现以下任一情况，应考虑物理分书：

物理分书不能代替对象边界。拆成不同书以后，每本书仍必须说明自身对象、消费面和依赖关系。

不应因为材料类型多而自动分书。同一 body 对象下的 specification、reference、terminology 和 acceptance facts 可以由一本 body book 的不同 part 承载。同一 lab 过程下的 proposal、work package、review package 和 status ledger 可以由一本 lab book 的不同 part 或 appendix 承载。

应分书的判断依据是对象职责冲突。一个材料需要长期作为当前入口，另一个材料完成后应关闭或归档；一个材料定义当前对象，另一个材料记录治理过程；一个材料服务使用者，另一个材料服务审核者。出现这些冲突时，物理分书保护消费面和依赖方向。

body 可以按版本演化。某一版本的 body 描述该版本下当前有效的对象事实。旧版本 body 可以归档；当前主线 body 描述当前版本事实。

版本变化过程由 lab 记录。迁移计划、提案、审核包和关闭记录说明从一个版本事实到另一个版本事实的过程。当前版本 body 不把该过程作为核心对象定义。

版本索引可以指向旧版本 body、迁移 lab 和 release note。索引服务追溯，不替代当前 body。

版本号不替代 body 内容。一个 body 标记为某个版本，只说明该版本下的当前事实集合；版本号本身不能说明对象边界、公共契约或验收事实。读者仍应在 body 中找到当前对象定义。

大版本迁移通常需要 lab 承载迁移过程。迁移 lab 可以引用旧版本 body 和目标版本 body，记录从一个版本事实到另一个版本事实的变更、审核和关闭。迁移完成后，目标版本 body 成为当前入口。

归档保存已关闭或已过期的治理对象。归档材料包括关闭的 issue、被拒绝 proposal、完成的 implementation plan、migration plan、review package、status ledger 和旧版本 body。

归档不是删除。归档对象不再承担当前执行入口，但保留解释、审计和复盘价值。归档入口应让追溯者找到历史对象，同时不让当前读者误认其为当前 body。

归档材料应保留关闭状态和结果去向。没有关闭状态的归档，会使历史对象继续占用当前判断空间。

归档入口应可定位但不抢占当前入口。书架目录、catalog 或索引可以列出归档材料；归档材料的标题、状态或位置应使读者知道它服务追溯。归档材料不应与 current body 使用同一入口语义。

旧版本 body 属于归档材料时，仍然是该历史版本的 body。它不再定义当前主线事实，但可以定义历史版本事实。迁移 lab 引用旧版本 body 时，应按历史版本事实使用，不能把旧版本事实当作当前事实。

Git 提供变更证据层。提交 hash、diff、路径列表和提交时间把治理声明绑定到实际文件变化。Commit、diff 和 history 的证据职责由 Git 坐标锁定，见 [git]。

Review package 把 Git 证据、验证命令和审核结论连接起来。Status ledger 把 review package 投影为当前治理状态。变更计划把 review package 和 work package 放入同一执行结构。

Git 不能替代 body 或 lab。Diff 能显示文件如何变化，但不能单独说明对象边界、进入条件、审核依据和关闭状态。书籍材料提供对象关系和治理语义，Git 提供可追溯变更事实。

Git 证据应进入 review package 或 closure record 的可审查表面。只在未归档沟通、临时笔记或未归档终端输出中保留命令结果，会切断治理证据。提交 hash、实际命令、结果摘要和审核结论应能在 lab 中定位。

Git diff 是审核输入，不是审核结论。审核者需要基于 diff、body 依据、工作包边界、验证命令和打回条件作出判断。Diff 显示修改发生；review package 记录修改是否具备进入下一状态的资格。

术语的职责是稳定指向对象。术语选择不是风格选择。一个术语应减少歧义、限定对象边界、支持交叉引用和降低解释成本。Signifier 与 signified 的区分用于标记术语表面和对象所指之间的关系，见 [saussure]。

术语不稳定时，协作者会在不同对象上使用同一个词，或用多个词指向同一个对象。术语漂移会使 body 与 lab 的边界失效，也会使审核者无法判断材料层位。

术语进入正文前，应具备所指。没有稳定所指的词，不进入核心定义。已有公共坐标能够准确指代对象时，应优先使用公共坐标。

术语评价以所指稳定性为标准。一个术语如果能让协作者定位同一对象、同一职责和同一依赖方向，它就是合格术语；一个术语如果扩大解释空间或遮蔽已有公共坐标，即使表达顺畅，也不进入核心定义。

术语可以保留英文形式。英文形式在本书中承担坐标职责：它把对象连接到已有工程共同体中的稳定所指。英文术语不能用于装饰，也不能替代本书对本地对象的定义。

本书使用以下本地术语：

这些术语在本书中按上述所指使用。不得把 body 用作普通正文同义词，也不得把 lab 用作任意临时草稿目录的同义词。

body 和 lab 是分区术语，不是质量评价词。一个材料进入 100_body 并不表示它写得优秀；它表示该材料承担当前承重职责。一个材料进入 200_lab 并不表示它不重要；它表示该材料承担治理职责。

公共工程术语用于锁定已有对象，不用于装饰表达。

Specification 指定义对象规则和公共契约的材料。Reference 指当前可查询、可依赖的对象说明。Proposal 指尚未进入当前 body 的候选变更。RFC 与 PEP 指 proposal、acceptance 和 current specification 之间的分层传统。ADR 指设计决策记录及其上下文。Work package 指有边界、有交付物、有验收的工作单元。Baseline 指可引用的项目状态。Change control 指受控变更治理。Review package 指审核证据包。Status ledger 指状态台账。Audit trail 指可追溯证据链。Commit、diff 和 history 指 Git 提供的变更证据层。Signifier 与 signified 指术语表面和对象所指之间的区分。

公共坐标只有在减少歧义时使用。一个外部术语如果不能稳定当前对象，或会引入不必要的理论负担，应保留本地定义。

公共坐标不得覆盖本地分区。Specification、proposal、work package、baseline、review package 和 audit trail 都是对象类型或工程坐标；它们不能替代 100_body 与 200_lab 的物理分区规则。一个 specification 通常属于 body；一个 proposal 通常属于 lab；所属分区仍由职责和依赖方向决定。

引用公共坐标时，应说明该坐标在当前句子中锁定的对象。只列出名称而不参与对象判断的引用，不进入正文核心。

术语漂移包括以下形态：

发现术语漂移时，应回到对象所指。能用已有公共坐标稳定的对象，使用公共坐标；需要本地术语的对象，先定义所指，再稳定使用。

术语修正应更新相关表面。正文定义、术语表、检查清单、交叉引用标题和实例评判标准如果使用同一术语，应同步检查。只修改一个章节的术语，会留下新的漂移源。

评判一个 body 材料时，检查以下事实：

任一核心 body 章节如果要求读者阅读 proposal、迁移计划、审核包或状态台账才能理解当前对象，该章节不满足 body 承重要求。

评判 body 时还应检查入口。目录、catalog、README 或书架首页如果把归档 lab、迁移计划或未关闭 proposal 放在当前对象入口位置，即使 body 内容本身正确，材料体系仍然会误导读者。

Body 评判应覆盖关联面。术语表、附录、验收事实、交叉引用和用户文档如果与核心章节不一致，body 没有形成稳定当前事实。

Body 评判还应覆盖事实承载物关系。Body 声明的公共契约如果由代码实现、测试验证、配置约束或用户文档表达，这些事实承载物应能回到同一 current body。关联表面之间存在冲突时，材料体系必须提供 lab 入口处理冲突。

评判一个 lab 材料时，检查以下事实：

Lab 可以记录过程、争议、打回和失败。记录这些对象时，应说明状态和结果去向。

Lab 评判应检查 lab object 是否具备关闭路径。没有关闭条件的 issue、proposal、plan 或 review package 会持续占据治理空间，使协作者无法判断它是开放对象、废弃对象还是已完成对象。

Lab 评判还应检查目标来源。Plan、work package 或 review package 如果声明目标，但不能指向 body 或已接受 proposal，该 lab object 越过治理职责。

Lab 评判还应检查状态词。Status ledger 使用的状态词必须具有受控语义；本地状态词如果不能说明治理位置，会削弱协作者对当前过程的判断。

评判交叉引用时，检查以下事实：

断裂引用会破坏材料体系的坐标能力。错误方向的引用会破坏 body/lab 的依赖关系。

引用评判不只检查链接是否可构建。可构建但关系错误的引用仍然是缺陷。Body 核心章节引用 lab 来解释当前字段含义，或 lab 引用无关 body 作为装饰，都破坏对象坐标。

评判一个 work package 或变更计划时，检查以下事实：

变更计划如果定义目标对象而不引用 body 或已接受 proposal，该计划越过自身职责。审核包如果只写结论而不写证据，该审核包不能支持状态转移。

变更评判应检查事实承载物同步。一个变更如果修改代码但不修改对应 body、测试或用户文档，审核者应确认这些材料不受影响；不能默认未改就是一致。一个变更如果修改 body 但不修改验收材料，也应说明验收为何仍成立。

受审例外必须显式记录。工作包修改了文件边界外对象时，审核包应说明例外路径、例外理由、风险和审核结论。未记录例外会削弱文件边界。

最小合格实例材料集合用于评判一个实例项目是否具备可依赖的 body/lab 结构。该集合定义材料职责，不定义具体业务内容。

一个实例项目至少应具备 current body entry。该入口应指向当前有效的 body object，并使读者能够判断对象边界、消费动作、公共契约、术语和验收事实。

存在受控变更时，实例项目应具备 active lab entry。该入口应指向当前打开、评估、执行、待审核或打回的 lab object，并使执行者和审核者能够定位目标来源、工作包、审核证据、状态台账和关闭条件。

实例项目应说明事实承载物关系。代码、测试、配置、用户文档、样例和发布材料如果表达同一当前事实，应能回到 current body；如果它们被某个 work package 修改，应进入 lab 的文件边界、验证命令、review package 和 closure record。

实例项目应具备 archive entry。旧版本 body、关闭的 proposal、完成的 implementation plan、migration plan、review package 和 status ledger 应保留追溯入口，同时不抢占 current body entry 或 active lab entry。

最小合格集合不要求所有材料都物理分成不同书。物理分书仍由对象职责、消费面、依赖方向和生命周期决定。一个实例只有在当前对象、治理过程和历史追溯具有可区分入口时，才具备可审查的材料结构。

常见失效形态包括：

失效判断应回到本书定义的对象职责和依赖方向。评判不依赖个人偏好。

失效修复应回到对象层位。Body 污染通过迁移过程清理、正文重写或引用修正处理；lab 缺证通过补充 review package、status ledger 或 closure record 处理；术语漂移通过重定义所指并同步相关表面处理。修复动作本身应进入相应 lab。