{
"format": "vibe-coding-cn/source-archive@1",
"kind": "gongfa",
"source_revision": "28e31abadec73e71aadaff1419e5b9e0575785ea",
"documents": {
".github/docs/gongfa/AGENTS.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "# 功法体系 Agent 指南\n\n## 唯一维护边界\n\n- `.github/docs/gongfa/` 唯一维护本仓可复用的方法论、哲学、思维模型、工程准则、操作方法与配套文集正文。\n- 功法不是第四套旧文档索引；已退役目录不得恢复为正文、可编辑副本、软链接或永久兼容壳。\n- 入门路线、具体研究域和 AI 引用只保存导航、任务实例、观察证据与必要摘要，完整可复用正文链接到此处。\n- 根 README 不展示六条核心命题内容或导航入口，仅保留兼容历史锚点；正文唯一维护源为 `ai-core-propositions.md`，用户从功法体系进入正文，不同步首页副本、不创建第二维护源、登记身份或内容版本。\n- `.github/metadata/gongfa/registry.json` 唯一维护已登记条目的 ID、内容版本、类型判定、来源绑定与历史意见；不另建可编辑功法表。\n- 功法文集不是独立功法身份。单篇可能包含多条内容或配套术语、本体与模板，不按篇数自动注册、去重或赋级。\n- 功法类型唯一语义源为 `cultivation-ontology-taxonomy.md`。本次仅移动原本体，不增节点、不把功能导航变成继承类树。\n- 本体说明、器物/资源资料与实验范式是配套内容；法器不登记为功法、不复用功法等级值。`faqi-system.md`解释工具/依赖分类和重要性分级，逐条数据仍归`.github/metadata/faqi.json`，只读视图归`.github/tools/faqi-catalog.md`。正式效能评级按本体主文中的独立 `faqi-grade-vocabulary-v1` 草案另行评价；重要性排序不代表工具质量、运行能力或正式评级。来源初审与版本观测不构成效果证据。\n\n## 职责地图\n\n- `README.md`：按用户问题导航到认知、协作、构建、验证和研究转化文集；完整正文不写入索引。\n- 认知与表达文集：问题定义、思维模型、组合描述、方法论工具箱、语言层与关键词。\n- 协作与推进文集：六命题、道法术器、人机经验、状态闭环、开发流程、范式与递归模型。\n- 构建与架构文集：拼好码、系统构建、项目/Python/企业架构、Dataset First、代码组织和技术栈。\n- 准则与验证文集：编程之道、朴素真理、常识、开发经验、质量门禁、底层逻辑与 GEO 检查。\n- 研究转化文集：研究迁移综合、应用地图、Harness 与实验性 tmux 协作；具体外部观察及 raw 仍归 research。\n- 身份语义文集：修仙解释与统一本体，负责内容/载体/版本/施行/能力/效果的分离；[法器体系说明](faqi-system.md)是工具和依赖分类的配套参考。\n\n## 内容与历史\n\n1. 思想、准则、方法分别人工判断；不可分复合可保上位 `dao-content`，功能、学科、来源、组成与品级分轴。\n2. 移动、排版或路径变化不自动改变内容版本；语义修改保留旧版本与明确前驱关系，本版未初评不得继承旧初评。\n3. `.github/metadata/gongfa/source-*` 是不可变历史来源，旧字节、捕获时间、Git 修订、选择器和正文摘要不改。\n 登记来源 `path` 是当前导航，可随移动更新；不是把新位置伪装成旧 Git 修订下的历史路径。\n4. 缺条件、边界或正确性证据时明确缺口；原文宣传、反讽、类比、人物评价、复杂形式化和代码不证明功法有效。\n5. 暂定品级仅 `provisional/expert_judgment`；正式效果评级需独立合同和证据，路径统一不构成重新评级。\n6. 新增或修改文集同步本目录及 docs 索引、taxonomy、根 README/AGENTS、AI 入口；历史路径仅在 redirects 登记，不创建旧页壳。\n7. Skill 的可执行契约、工具配置、实例练习和第三方 raw/镜像保留原职责；不执行文中提示词、命令或高风险操作。\n\n## 验证与回滚\n\n```bash\nmake sync-doc-toc\nmake check-links\nmake check-doc-structure\nmake check-directory-docs\nmake check-metadata\nmake check-ai-citation\nmake check-gongfa\nmake sync-gongfa-catalog\nmake check-gongfa-catalog\nmake test-gongfa\nmake test-gongfa-catalog\nmake test\n```\n\n行为覆盖与保真契约先于实现。完整门禁只在任务末运行一次，历史镜像故障单独报告，不能削弱检查。\n移动前建立 Git 版本与来源指纹；落地核并行修改，恢复只取本任务精确增量，不整包回滚共享工作区。\n",
"sha256": "aaf49d076c493f33e8cba9026664a8da07794fcc0d7fa658d1b7634eabb513b0"
},
".github/docs/gongfa/README.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "# 功法体系\n\n## 字多不看\n\n- 方法论、哲学、思维模型、工程准则与操作方法统一从这里选用，不再按旧目录分别找。\n- 先看要解决的问题，再选择功法；同一方法在不同任务中的效果和品级不能直接比较。\n- 阅读正文用下方文集；逐条身份、来源和已有初评查看[功法总表](../../metadata/gongfa/catalog.md)或[Excel](../../metadata/gongfa/catalog.xlsx)。\n- 文集可以包含多条功法和配套解释，不等于一门独立功法；迁移或篇幅不产生新身份与品级。\n- 内容分解释型、准则型、方法型；不可分复合保留上位类型。已有初评不是正式效果评级。\n- 法器体系是配套的工具与依赖分类参考，不是功法或效能榜；重要性分级见[法器体系说明](faqi-system.md)。\n- [本体与品级](cultivation-ontology-taxonomy.md#功法本体与品级)解释类型、内容版本和天地玄黄四阶十二级。\n\n## 快速导航\n\n| 当前问题 | 首选功法文集 |\n|:---|:---|\n| 不知道如何定义问题、判断或表达对象 | [问题求解](problem-solving.md) / [思维模型](thinking-models.md) / [组合描述](compositional-description-model.md) |\n| 需要理解 AI 协作的能力和边界 | [六条核心命题](ai-core-propositions.md) / [道法术器](dao-fa-shu-qi.md) / [人机协作经验](vibe-coding-experience.md) |\n| 要把目标推进成可验收结果 | [状态转移闭环](vibe-coding-state-transition.md) / [开发流程](development-process.md) / [方法论工具箱](methodology-toolbox.md) |\n| 要设计、组合或维护软件系统 | [拼好码](glue-coding.md) / [Lambda演算](lambda-calculus.md) / [系统构建](system-building.md) / [项目架构](project-architecture-template.md) |\n| 要控制质量、复杂度或运行风险 | [质量门禁](quality-gates-and-pitfalls.md) / [朴素真理](software-engineering-truths.md) / [底层程序逻辑](low-level-program-logic.md) |\n| 要从研究提炼可验证改进 | [研究迁移综合](research-transfer-synthesis.md) / [研究应用地图](research-value-application-map.md) / [Harness 解析](harness-engineering.md) |\n| 要理解法器分类、重要性及正式效能边界 | [法器体系说明](faqi-system.md) / [法器总表](../../tools/faqi-catalog.md) / [本体规约](cultivation-ontology-taxonomy.md#法器品级规约) |\n| 要核对功法身份、类型、来源和初评 | [修仙解释](vibe-coding-cultivation-model.md) / [本体](cultivation-ontology-taxonomy.md) / [登记协议](../../metadata/gongfa/README.md) |\n\n\n完整细粒度目录（点击展开/收起）
\n\n### 认知、表达与判断\n\n- [思维模型](thinking-models.md)：第一性原理、奥卡姆剃刀、逆向、多阶与状态空间等模型。\n- [组合描述模型](compositional-description-model.md)：对象、状态、快照、过程、变换、同一及关系。\n- [问题求解](problem-solving.md)：目标、现状、差距、标准、约束、对象与路径。\n- [语言层要素](language-layers.md)：语言层级、类型、执行模型及工程语义。\n- [关键词系统](keyword-system.md)：理解问题领域的配套术语入口。\n- [方法论工具箱](methodology-toolbox.md)：按任务选择、组合和验证方法，并含待评审的候选方法整理稿。\n\n### 人机协作与目标推进\n\n- [AI 协作的六条核心命题](ai-core-propositions.md)：目标闭环、生成域、模型演化、隔离审查与能力编排。\n- [道法术器](dao-fa-shu-qi.md)：协作关系、抽象方法、工程流程和工具承载。\n- [AI 编程经验准则](experience-principles.md)：原首页经验的完整正文。\n- [Vibe Coding 经验](vibe-coding-experience.md)：通用语言能力、人机分工、机器门禁和入门铁律。\n- [状态转移闭环](vibe-coding-state-transition.md)：固定目标、可变策略、分层反馈与验收集合。\n- [开发流程](development-process.md)：需求、计划、修改、验证与交付顺序。\n- [开发范式演进](development-paradigms.md)：软件工程组织方式与 AI 编程范式。\n- [递归自优化系统](recursive-self-optimizing-system.md)：生成器与优化器的形式模型及边界。\n- [tmux 蜂群协作](tmux-ai-swarm.md)：实验性多终端协作范式；不是当前 Agent 的执行授权。\n\n### 构建、复用与架构\n\n- [拼好码](glue-coding.md)：成熟能力选择、适配、编排与业务交付。\n- [Lambda演算](lambda-calculus.md)：天级上品；函数抽象、作用域、归约、组合及工程边界。\n- [系统构建方法](system-building.md)：自顶向下、自底向上与分而治之。\n- [项目架构模板](project-architecture-template.md)：项目结构、边界、最低门禁与检查清单。\n- [通用 Python 项目骨架](python-project-skeleton.md)：Python 应用、服务、工具和库的配套模板。\n- [企业级架构模板](enterprise-architecture-template.md)：平台工程、Monorepo 与 Multi-repo 参考。\n- [现代企业数字化平台架构](modern-enterprise-architecture-template.md)：领域、平台、版本、治理与可靠性蓝图。\n- [Dataset First 数据服务](dataset-first-data-service.md)：dataset、contract、registry 和 runtime 的边界。\n- [代码组织](code-organization.md)：模块化、命名、注释、格式化与文档。\n- [技术栈](technology-stack.md)：选型维度、组合案例和学习路径；产品清单不是品级。\n\n### 准则、验证与维护\n\n- [编程之道](programming-dao.md)：结构、状态、复杂度与工程判断。\n- [软件工程的朴素真理](software-engineering-truths.md)：代码、需求、维护、质量、架构和团队。\n- [常识](common-sense.md)：AI 编程与交付前的最低判断线。\n- [开发经验](development-experience.md)：命名、结构、编码与基础设施经验。\n- [AI 编程质量门禁与常见坑](quality-gates-and-pitfalls.md)：系统提示词、前置条件、反例与硬门禁。\n- [底层程序逻辑设计](low-level-program-logic.md)：运行、并发、数据、性能与交付模型。\n- [GEO / SEO 检查清单](geo-seo-checklist.md)：可信知识、结构化内容、审核与引用质量。\n\n### 研究转化与身份语义\n\n- [研究迁移综合](research-transfer-synthesis.md)：对标拆解、改良、组合、试用动作与反证。\n- [研究价值与应用地图](research-value-application-map.md)：研究到学习、工程和采用决策的转化。\n- [Harness 工程解析](harness-engineering.md)：控制面、评估器、反馈与可靠性判断。\n- [修仙解释图层](vibe-coding-cultivation-model.md)：领域本体的通俗解释，不是运行架构。\n- [法器体系说明](faqi-system.md)：工具/依赖边界、Vibe Coding重要性分级与正式效能评级边界。\n- [统一本体与分类设计](cultivation-ontology-taxonomy.md)：唯一类型树、身份、版本、来源及品级契约。\n- [AGENTS](AGENTS.md)：功法体系的正文维护与消费规则。\n\n \n\n## 使用方式\n\n1. 写清当前任务的目标、约束和验收，再从功能导航选文集。\n2. 区分解释、准则和方法，阅读适用条件、限制和反证，不把原文断言当已证明事实。\n3. 需要逐条选用或核对初评时查功法总表；登记与候选、初评与正式结果分别判断。\n4. 原始研究材料仍在[研究域](../../research/README.md)，运行能力仍在[Skills](../../skills/README.md)。\n\n## 正文\n\n正文已拆分到上述独立文集。文集是组织与阅读单位；一门功法的身份仍由 ID＋内容版本确定。\n配套本体、术语、模板、产品信息和历史材料不因此自动成为独立功法或有效方法。\n",
"sha256": "4bb5da29ced37de6522e9814b573f00e700be039bb06bb8b427d2d78e364e599"
},
".github/docs/gongfa/ai-core-propositions.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "# AI 协作的六条核心命题\n\n## 🧠 六条核心命题\n\n### 零、固定目标、分层反馈的可验证收敛系统\n\n> **Vibe Coding 可以理解为一种目标驱动、受约束、可验证的状态转移闭环；从控制结构看，它是一种固定目标、可变策略、分层反馈的系统：先将模糊需求经过澄清、结构化、一致性检查和人工确认，冻结为带版本的目标基线 `G*`；再让 Agent 在目标基线和约束不被静默修改的前提下，反复执行“观察当前状态 `S_t` → 识别状态差距 `Δ_t` → 选择策略与行动 → 获取验证证据 `E_t` → 接受、修正、回滚或切换策略”，使系统逐步进入目标的验收集合。若单次行动无效，则修正行动；若当前策略无效，则切换策略；若目标存在矛盾、不可行或无法判定，则暂停执行，重新审查目标或交由人决定。任何目标变更都必须通过显式版本、差异和授权进入新一轮闭环；每一层都必须具备独立验证、回滚、尝试上限和退出机制。**\n\n```text\n原始需求 R\n→ 澄清、结构化、一致性检查\n→ 版本化目标基线 G*\n→ 观察当前状态 S_t\n→ 识别状态差距 Δ_t\n→ 选择策略 π_t 与行动 O_t\n→ 执行\n→ 采集验证证据 E_t\n→ 接受 / 修正 / 回滚 / 切换策略\n→ 下一轮状态 S_{t+1}\n```\n\n这里的“固定目标”不是目标永远不能变化，而是未经授权不能被执行者静默改变；合法变化必须创建新的目标版本。这里的“收敛”也不是保证每一步都成功，而是在验证、回滚、尝试上限和退出机制约束下，使系统进入并保持在目标验收集合中。零号命题与后续五条命题共同构成六条核心命题；后续五条命题分别解释 AI 在这个闭环中的能力、边界、演化、审查和编排。\n\n### 一\n\n> **Demis Hassabis：“首先解决人工智能问题，然后再用人工智能解决其他所有问题”**\n\n### 二、生成域\n\n> **大语言模型的能力边界，是其生成物能够直接或间接实现、驱动、约束、修改、验证或影响的范围。**\n\n> **当前，AI 正在接管部分人的一切作用；未来，AI 将接管所有人的一切作用？**\n\n大语言模型的直接产物是 token 序列；token 解码为文本后，可以承载自然语言、形式语言和机器可解析协议等可文本化的符号结构。凡是能被文本稳定表达，并能被人、程序或工具解释、执行、约束、修改或验证的结构，都属于大语言模型的生成域，例如：用户提示词、系统提示词、自然语言、代码、命令、配置、流程、计划、测试、文档、schema、API 调用、工具指令和数据处理逻辑。\n\n> **生成物可达，即模型能力可达。**\n\n### 三、模型吞噬\n\n> **模型能力会持续吞噬一切可被吞噬且为弥补模型不足而产生的中间层。**\n\n很多今天看起来很重要的东西，本质上只是因为模型还不够强：Prompt 技巧、工作流、Agent 编排、索引系统、外部记忆、工程脚手架、工具封装、人工流程和当前经验体系。\n\n当模型能力继续提升，这些中间层会被模型原生能力吸收、压缩、替代，甚至失去独立存在的意义。凡是因模型能力不足而存在、且可被吞噬的工程补丁，都会被更强模型吞噬。\n\n### 四、隔离审查\n\n> **AI 生成结果只是候选解，不是已验证事实；长期应默认其可能错误、非最优，并必须保留审查、验证与优化空间。**\n\n成熟 AI 工程的重要治理原则，不是让同一个上下文自我确认，而是把生成、审查和验证拆开。NIST 强调独立审查可以降低偏见和利益冲突；OpenAI 与 Microsoft 都把外部测试、红队和独立评估作为发现盲点的重要机制；LLM-as-a-judge 研究也指出，模型评价自身输出时可能存在自偏好。\n\n因此，长期使用 AI 时，重要产出必须新开隔离会话，明确告知审查 AI：上一轮结果不可信，不能沿用结论，必须重新阅读原始资料、业务代码、目标、约束和验证结果，用事实、测试和可追溯证据判断其是否成立。\n\nAI 负责生成候选解，隔离上下文负责审查和优化候选解，事实与验证负责裁决候选解。\n\n### 五、能力编排\n\n> **AI 编程的高阶形态不是从零生成更多代码，而是根据需求反向搜索成熟工具链与成熟仓库，把已有能力编排成可验证的业务系统。**\n\n拼好码要求从“实现者心态”转向“整合者心态”：不是看到需求就让 AI 直接自研，而是先识别已有成熟能力、评估成熟度、设计适配边界，再用最少自研完成业务闭环。成熟生态承担通用复杂度，胶水代码连接业务流程，自研只服务不可替代的业务差异。\n\n简单实践流程：\n\n1. 写清需求：目标、输入、输出、约束和验收标准。\n2. 反向搜索：让 AI 根据需求拆出能力领域，搜索官方能力、事实标准、工具链、成熟仓库、主流 SDK 和平台服务。\n3. 评估候选：检查维护状态、许可证、文档质量、生产案例、生态兼容、替换风险和接入成本。\n4. 选择组合：确定采用的工具链与仓库组合，并说明为什么不用其他方案、为什么不自研。\n5. 设计边界：固定输入输出、数据模型、接口契约、错误处理、依赖隔离和回滚路径。\n6. 生成胶水：让 AI 只写连接、适配、编排、配置、业务规则和测试，不重写成熟能力。\n7. 验证交付：用测试、类型、schema、CI、脚本和检查清单验证结果，留下证据、替换方案和回滚路径。\n\n> **能复用时不重造，能编排时不发明。**\n",
"sha256": "f2e55dd5fe20902be626a032e87b8c184de8609872ea3fdd1dc6e224598bda1e"
},
".github/docs/gongfa/code-organization.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "\n# 代码组织\n\n\n#### 模块化编程\n\n- 将代码分割成小的、可重用的模块或函数，每个模块负责只做一件事。\n- 使用明确的模块结构和目录结构来组织代码，使代码更易于导航。\n\n\n#### 命名规范\n\n- 使用有意义且一致的命名规范，以便从名称就能理解变量、函数、类的作用。\n- 遵循命名约定，如驼峰命名（CamelCase）用于类名，蛇形命名（snake_case）用于函数名和变量名。\n\n\n#### 代码注释\n\n- 为复杂的代码段添加注释，解释代码的功能和逻辑。\n- 使用块注释（/*...*/）和行注释（//）来区分不同类型的注释。\n\n\n#### 代码格式化\n\n- 使用一致的代码风格和格式化规则，使用工具如 Prettier 或 Black 自动格式化代码。\n- 使用空行、缩进和空格来增加代码的可读性。\n\n\n### 文档\n\n\n#### 文档字符串\n\n- 在每个模块、类和函数的开头使用文档字符串，解释其用途、参数和返回值。\n- 选择一致的文档字符串格式，如 Google Style、NumPy/SciPy Style 或 Sphinx Style。\n\n\n#### 自动化文档生成\n\n- 使用工具如 Sphinx、Doxygen 或 JSDoc 从代码中自动生成文档。\n- 保持文档和代码同步，确保文档始终是最新的。\n\n\n#### README 文件\n\n- 在每个项目的根目录中包含一个详细的 README 文件，解释项目目的、安装步骤、用法和示例。\n- 使用 Markdown 语法编写 README 文件，使其易于阅读和维护。\n\n\n### 工具\n\n\n#### IDE\n\n- 使用功能强大的 IDE，如 Visual Studio Code、PyCharm 或 IntelliJ，利用其代码自动补全、错误检查和调试功能。\n- 配置 IDE 插件，如 linter（如 ESLint、Pylint）和代码格式化工具。\n",
"sha256": "1c6fbfe2c65432d7e373c819cda8efe63385e19ece41c40de092d036dc3822eb"
},
".github/docs/gongfa/common-sense.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "\n# 常识\n\n\n### 核心常识\n\n如果你不会写提示词，不要先纠结格式。直接用自然语言描述你的意图，能写多详细就写多详细；把目标、背景、约束、输入、输出、例子和不想要的结果都说出来，然后让 AI 根据这段描述帮你生成一版可直接使用的提示词。\n",
"sha256": "ff5c999e8f2b5778c76304747a9d109969a36b982ab32a610e47b903a42615a6"
},
".github/docs/gongfa/compositional-description-model.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "\n\n# 组合描述模型\n\n> 对象、状态、快照、序列、过程、变换、同一/差异与关系。\n\n组合描述模型，可以看成一套理解世界如何“既保持又变化”的基础框架：对象是我们能够指认和追踪的相对稳定单位，状态是对象在某一时刻或条件下的存在方式，快照是对状态的静态截取，多个快照按时间或规则排列就形成序列，而序列作为动态整体展开出来就是过程；过程之所以能从一个状态走向另一个状态，是因为背后有某种变换机制。可是一旦讨论变化，就必然遇到两个问题：它为什么仍然算“同一个”，又为什么已经变得“不同”。因此，同一用来保证追踪和识别的连续性，差异用来揭示变化、比较和意义的生成，而关系则把对象、状态、过程和差异放进更大的结构网络中，使它们真正获得意义。换句话说，这组概念不是零散术语，而是一种从静态存在走向动态生成、从孤立对象走向关系结构的认知语法：对象让世界可被指认，状态让世界可被描述，快照和序列让世界可被记录，过程和变换让世界可被解释，同一、差异和关系则让世界可被理解。\n\nUserInput(组合描述模型)\n -> 对象\n -> 状态\n -> 快照\n -> 序列\n -> 过程\n -> 变换机制\n -> 同一判定\n -> 差异判定\n -> 关系网络\n -> 动态本体论框架\n\n这几个概念，几乎就是我们理解世界、描述变化、整理知识的一套较小框架。\n\n它们不只出现在哲学里，数学、物理学、计算机科学、系统科学、语言学、认知科学里，也都离不开它们。\n\n单看每个词，都很常见。但把它们放在一起，问题就会更深一层：\n\n> 我们到底怎么在变化里把握事物，又怎么在差异里建立统一？\n\n这其实是很多学科都在面对的问题。\n\n一个对象，从来不是孤零零存在的。它总在某种状态里。状态可以被截成快照，快照可以排成序列，序列展开以后，就是过程。过程又依赖某种变换规则。\n\n而在变换里，我们一方面要说明，为什么它还是“同一个”；另一方面也要说明，它为什么已经“不同了”。最后，这一切都只能放进关系网络里，才真正说得通。\n\n所以，这组概念不是一张并列摆开的术语表。它更像一套用来描述世界、系统和认知的动态本体论框架。\n\n\n### 一、对象\n\n对象，就是我们拿来指认、区分和讨论的单位。\n\n它可以很具体，比如一棵树、一台机器、一个人。也可以很抽象，比如一种制度、一个算法、一个命题、一个国家。\n\n对象的关键，不在于它是不是“独立存在”，而在于，它能不能被识别成一个相对稳定的单位。\n\n也就是说，对象总和边界、识别、持续性有关。没有边界，对象就立不起来。没有持续性，对象就会散成一团难以组织的事件流。\n\n不同学科里，对象的意思也不一样：\n\n- 在哲学里，它常常对应实体、存在者，或者现象对象。\n- 在数学里，它可以是集合、群、空间、范畴里的元素。\n- 在计算机科学里，它可以是数据结构、类实例、进程、节点。\n- 在系统科学里，它更常被理解成系统单元，或者系统里的子系统。\n\n所以，对象不只是“一个东西”。它是一个被组织起来、能被识别、还能被持续追踪的存在单位。\n\n\n### 二、状态\n\n状态，是对象在某个时刻、某种条件下的规定性。\n\n对象不会永远静止不变。它会表现出不同的属性、位置、能量、角色，或者内部配置。\n\n状态，就是这些规定性的总和。也可以说，状态就是对象“此时此地怎么存在”的方式。\n\n比如：\n\n- 一杯水可以是液态、固态、气态。\n- 一台机器可以在运行、停机、故障这些状态里切换。\n- 一个人可以清醒、疲惫、专注、焦虑。\n- 一个社会系统，也可能是稳定、危机、转型。\n\n状态这个概念，让对象从“只是存在”，变成“可以被描述的存在”。\n\n没有状态，对象只是一个空名字。有了状态，对象才真正变成能分析、能比较、能记录的单位。\n\n\n### 三、快照\n\n快照，就是对状态做一次静态截取。\n\n它强调的是“截面”，不是“流动”；强调的是“这一刻就是这样”，不是“它怎么变成这样”。\n\n快照的意义，在于先把连续变化暂时冻住。这样我们才能观察、记录、比较、建模。\n\n比如：\n\n- 照片是视觉快照。\n- 数据库备份是系统快照。\n- 某个时间点的人口统计，是社会快照。\n- 实验里某一刻的测量数据，也是快照。\n\n但快照不等于对象本身。它只是对象在某个时间点上，一个可以被记录下来的切面。\n\n所以，快照天然带着选择性。它记录什么，不记录什么；它保留哪些属性，忽略哪些背景。\n\n也就是说，快照既是认识工具，也是一种简化。\n\n\n### 四、序列\n\n序列，是多个快照按照时间、逻辑，或者生成规则排出来的结果。\n\n当我们不再只问“这一刻是什么”，而开始关心“前后发生了什么”，快照就进入了序列。\n\n序列可以是：\n\n- 时间序列，比如一天里的温度变化。\n- 行为序列，比如用户在软件里的点击路径。\n- 叙事序列，比如故事里的事件链。\n- 运算序列，比如算法执行的步骤。\n- 生长序列，比如一个生物体发育的阶段。\n\n序列让分散的快照之间，开始建立可追踪的连续性。\n\n它是我们从静态描述，走向动态理解的第一步。\n\n\n### 五、过程\n\n过程，可以看成序列的动态整体。\n\n如果说序列强调的是排列，那过程强调的就是展开。如果说序列更像“把结果一个个列出来”，那过程更像“变化正在持续发生”。\n\n过程不只是很多状态排在一起。更重要的是，这些状态之间有生成关系，有演化方向，也有内在联系。\n\n比如：\n\n- 种子发芽是过程。\n- 儿童成长是过程。\n- 化学反应、经济周期、项目推进、语言习得，也都是过程。\n\n过程最核心的地方在于，它有持续性，有方向性，有内在机制，还会产生新的状态和新的结构。\n\n所以，比起“对象”，过程往往更能抓住现实世界的生命力。\n\n很多现代思想都倾向于认为，世界最根本的，不是静态实体，而是过程、事件和生成。\n\n\n### 六、变换\n\n变换，是从一个状态到另一个状态的规则、操作，或者机制。\n\n它回答的问题是：\n\n> 为什么会变？又是怎么变过去的？\n\n变换可以是：\n\n- 物理变换，比如受力运动、相变、能量交换。\n- 数学变换，比如映射、函数、群作用、坐标变换。\n- 计算变换，比如状态转移、程序执行、数据更新。\n- 认知变换，比如分类、联想、重构。\n- 社会变换，比如制度改革、角色转换、结构迁移。\n\n变换让过程变得可以解释。\n\n没有变换，过程只是现象。有了变换，我们才有机会建立机制模型，理解为什么会从 A 走到 B。\n\n\n### 七、同一\n\n同一，指的是在变化里，某个东西依然被认作“它自己”。\n\n这是这组概念里最偏哲学的问题之一。\n\n一个人和十年前相比，身体细胞不同了，心理结构不同了，社会身份也可能不同了。但我们还是会说，这是同一个人。\n\n一艘船的木板全换了，它还是不是原来那艘船？\n\n一个软件升级了很多次，它还是不是同一个系统？\n\n同一问题会把一个张力直接摆出来：\n\n> 变化一直在发生，但识别不能因此彻底崩掉。\n\n所以，同一不是绝对不变。它更像是一种可持续的认定原则。\n\n这个原则，可能来自物质连续性，也可能来自结构连续性、功能连续性、因果连续性，还可能来自记忆和叙事的连续性，或者规则上的身份保持。\n\n所以，同一性通常不是说“本质一点都没变”，而是说：\n\n> 在某种意义上，它仍然算同一个。\n\n\n### 八、差异\n\n差异，就是对象之间、状态之间、快照之间，或者过程阶段之间的不相同。\n\n没有差异，识别就无从发生。因为识别本身，就是把这个和那个区分开。\n\n差异可以是静态的，比如两个对象不一样。也可以是动态的，比如同一个对象，前后两个状态不一样。还可以是两个序列的差异，过程不同阶段的差异，或者同一个结构在不同语境里的差异。\n\n差异不是对同一的简单否定。恰恰相反，同一和差异是互相规定的。\n\n没有某种持续性，你都没法说“它变了”。没有变化，你也没法说“它还是同一个”。\n\n需要注意的是：\n\n> 差异不是附属的边角料。它本身就是意义生成的基础。\n\n一个符号之所以有意义，因为它和别的符号不同。一个身份之所以成立，也因为它在关系网络里和别的身份区分开来。\n\n\n### 九、关系\n\n关系，是对象和对象、状态和状态、过程和过程之间的连接方式。\n\n关系可以是空间关系，也可以是时间关系、因果关系、逻辑关系、功能关系、社会关系、语义关系。\n\n关系的重要性在于，对象很多时候不是先孤立存在，然后才去彼此连接。恰恰相反，很多对象就是在关系里才被定义出来的。\n\n比如：\n\n- 父亲这个对象，离不开亲属关系。\n- 节点离不开网络关系。\n- 商品离不开交换关系。\n- 词语离不开句法和语义关系。\n\n所以，关系视角意味着一种转变：\n\n> 从“以实体为中心”，转到“以结构为中心”。\n\n在这种视角里，理解一个东西，不只是问“它是什么”，还要问：\n\n- 它和什么相连？\n- 它在什么网络里起作用？\n- 它又是由哪些差异和对应构成的？\n\n\n### 十、概念之间的结构关系\n\n这几个概念之间，其实不是松散堆在一起的。\n\n它们可以连成一条线：\n\n> 对象，到状态，到快照，到序列，到过程，再到变换。\n\n同时，这条线一直被另外三组更深层的概念支撑着：\n\n- 同一，保证我们追踪的，还是“同一个对象”或者“同一个过程”。\n- 差异，保证变化、比较和生成，能够被识别出来。\n- 关系，保证这些单位不是孤立的，而是在结构里获得意义。\n\n换句话说：\n\n- 对象是被识别出来的单位。\n- 状态是对象当下的规定。\n- 快照是状态的记录形式。\n- 序列是快照的排列方式。\n- 过程是序列的动态统合。\n- 变换是过程展开的机制。\n- 同一让追踪成为可能。\n- 差异让比较成为可能。\n- 关系让理解成为可能。\n\n整个框架，可以被看成一条从静态存在走向动态生成的认知路径。\n\n\n### 十一、不同学科中的展开\n\n放到不同学科里看，这套框架都会展开出自己的版本。\n\n\n#### 1. 哲学\n\n哲学是最早系统讨论这些概念的地方。\n\n古希腊哲学里，巴门尼德强调存在和同一，赫拉克利特强调流变和过程。这几乎已经把后面关于“同一和变化”的基本矛盾摆出来了。\n\n亚里士多德又用实体和属性、潜能和现实，去解释对象、状态和变化。\n\n到了近代哲学，问题进一步变成：\n\n> 对象是独立于认识而存在，还是在经验中被构成出来的？\n\n现代哲学里，现象学、结构主义、过程哲学、后结构主义，又分别从意识、结构、生成、差异这些角度，重新组织这组概念。\n\n所以在哲学里，核心问题通常会集中在这些地方：\n\n- 什么才算对象？\n- 变化里的同一怎么成立？\n- 差异到底是附属的，还是根本的？\n- 关系是外在连接，还是构成性的？\n- 世界最基础的东西，到底是实体还是过程？\n\n可以说，这组概念在哲学里，本来就是本体论和认识论的一条核心轴线。\n\n\n#### 2. 数学\n\n数学给这组概念，提供了最精确的形式表达。\n\n集合论把对象处理成元素和集合。函数和映射用来描述变换。序列、递推、极限，处理的是有序展开。\n\n拓扑学研究的是变形里哪些东西保持不变。某种意义上，这也是在回应“同一”的问题。\n\n抽象代数研究的是，对象在运算下怎样保持结构。\n\n范畴论更进一步，把对象和态射放进同一体系里，让关系和变换的位置，比对象本身还更基础。\n\n数学特别重要的一点在于，它不只是讨论这些概念。它还能给出严格条件，告诉我们：\n\n- 什么时候两个对象算等价。\n- 什么时候一个变换算保持结构。\n- 什么时候一个过程可逆。\n- 什么时候不可逆。\n\n\n#### 3. 物理学\n\n物理学里，这组概念几乎可以直接一一对应：\n\n- 对象，可以是粒子、场、系统。\n- 状态，可以是位置、速度、能量、自旋、宏观参数。\n- 快照，就是某个时刻的观测值。\n- 序列，就是测量记录和轨迹数据。\n- 过程，是运动、演化、衰变、相变。\n- 变换，是动力学方程、对称变换、守恒律。\n- 同一，是同一个系统在时间里的延续。\n- 差异，是不同状态、不同相、不同测量结果之间的区别。\n- 关系，是相互作用、耦合和时空关系。\n\n物理学特别强调一点：\n\n> 对象不能脱离状态空间和演化规律来理解。\n\n一个系统到底是什么，很多时候就取决于，它可能处在哪些状态里，以及这些状态会怎样随时间变化。\n\n所以，物理学很典型地代表了一种“状态—演化”的世界观。\n\n\n#### 4. 计算机科学\n\n计算机科学里，这组概念是非常能落地、非常有操作性的。\n\n在程序设计和系统建模中：\n\n- 对象可以是数据实体、模块、进程、节点。\n- 状态可以是内存值、配置、上下文。\n- 快照可以是系统镜像、数据库备份、版本存档。\n- 序列可以是日志、执行轨迹、输入流。\n- 过程可以是程序运行、工作流、协议执行。\n- 变换可以是算法、状态转移函数、数据处理规则。\n- 同一可以表现成对象 ID、引用、版本继承。\n- 差异可以表现成补丁、变更记录、版本比较。\n- 关系则表现成依赖、调用、连接、图结构。\n\n尤其是在状态机、数据库、分布式系统、版本控制、人工智能这些领域里，这组概念几乎就是基础语言。\n\n计算机科学的重要贡献，就在于它把这些概念变成了能设计、能验证、能执行的系统结构。\n\n\n#### 5. 系统科学\n\n系统科学里，对象通常被理解成系统或者子系统。关系被理解成结构。状态变化被理解成动态演化。\n\n所以，这套概念在系统科学里有很强的整体性。\n\n系统科学关心的，从来不是一个孤零零的对象。它更关心：\n\n- 对象怎么组成系统。\n- 系统怎么维持状态。\n- 系统怎么在扰动里发生变换。\n- 系统怎么在时间里保持同一。\n- 系统又怎么通过反馈，产生差异化的演化。\n\n在控制论、复杂系统理论、生态系统研究、组织理论里，这样的框架都很常见。\n\n它的优势在于，能同时处理稳定和变化，局部和整体，结构和生成。\n\n\n#### 6. 语言学和认知科学\n\n语言学和认知科学里，这组概念也很关键。\n\n语言学里，意义常常就是靠差异和关系形成的。认知科学里，人脑理解世界，也离不开对象化、分类、跟踪和关系建模。\n\n人在感知一个连续世界的时候，并不是直接面对一团“纯粹流动”。我们会主动把它切开，分出对象，识别它的状态，形成快照式记忆，把经验串成序列，再去推断它背后的过程，并建立相应的变换模型。\n\n比如我们会判断：\n\n> 这是同一个人在走路。\n\n也会注意到：\n\n> 他的表情变了。\n\n也会把几个动作连成一个完整事件。\n\n所以，这组概念不只是描述外部世界的工具。它们本身，也是认知活动组织经验的方式。\n\n\n### 十二、理论上的核心问题\n\n接下来，有几个理论上的核心问题。\n\n\n#### 1. 实体优先，还是过程优先\n\n也就是说，世界是不是先由对象构成，然后对象再去变化；还是说，世界本来就是过程流动，对象只是过程里相对稳定的结点。\n\n前一种思路，更偏实体论。后一种思路，更偏过程论。\n\n实体论强调同一和稳定。过程论强调生成和变动。\n\n现实里，两边往往都不能少。没有相对稳定的对象，认知没法展开。没有过程和变换，对象又会僵成空洞标签。\n\n\n#### 2. 同一怎么在变化里成立\n\n这个问题从古典讨论到现代，一直没有真正结束。\n\n判断同一，可以看物质连续性，也可以看结构、功能、因果链、记忆、命名规则这些标准。\n\n不同学科、不同语境，会选不同的标准。\n\n所以，同一通常不是一个唯一答案。它更像一套随着情境变化而变化的判准体系。\n\n\n#### 3. 差异到底是派生的，还是基础的\n\n传统思想往往把同一放在基础位置，把差异看成偏离。\n\n现代思想则更常认为，差异才更根本。因为没有差异，就没有识别，没有意义，也没有生成。\n\n这样一来，差异就不再只是分类剩下来的残余。它会变成知识生产本身的根部。\n\n\n#### 4. 关系会不会比对象更基础\n\n在网络科学、结构主义、范畴论、系统论里，关系往往不是次生的。\n\n一个对象具有什么性质，很多时候由它在关系网络里的位置决定。\n\n这会让我们对世界的理解，从“对象的集合”，慢慢转成“关系的结构”。\n\n\n### 十三、五层统一模型\n\n如果把这九个概念再压缩一下，可以得到一个统一模型。\n\n\n#### 第一层：存在层\n\n这里包括对象和状态。\n\n它回答的是：\n\n- 有什么？\n- 以及它此刻怎么存在？\n\n\n#### 第二层：表征层\n\n这里包括快照和序列。\n\n它回答的是：\n\n- 怎么记录？\n- 又怎么把记录组织起来？\n\n\n#### 第三层：生成层\n\n这里包括过程和变换。\n\n它回答的是：\n\n- 怎么变化？\n- 变化的机制又是什么？\n\n\n#### 第四层：判定层\n\n这里包括同一和差异。\n\n它回答的是：\n\n- 什么保持不变？\n- 什么发生了改变？\n\n\n#### 第五层：结构层\n\n这里就是关系。\n\n它回答的是：\n\n- 这一切怎么被连接成系统？\n\n这个模型的价值就在于，它能跨学科反复使用。\n\n不管你研究的是哲学问题，还是物理系统、程序运行、社会变迁、叙事结构，都可以用这五层框架来组织分析。\n\n\n### 十四、作为一种分析方法\n\n所以，这组概念不只是理论术语。它也可以变成一种方法。\n\n面对任何复杂对象，都可以按这样的步骤去分析：\n\n1. 先确定对象到底是什么。\n2. 再描述它现在有哪些状态。\n3. 然后收集几个快照。\n4. 把快照排成序列。\n5. 从序列里识别出过程。\n6. 再进一步找出推动变化的变换机制。\n7. 同时判断，哪些属性支撑了同一。\n8. 哪些属性构成了差异。\n9. 最后，把它放回更大的关系网络里理解。\n\n这其实是一种很普遍的分析法。\n\n它能用在科学研究里，也能用在系统设计、历史叙述、产品分析、组织诊断，甚至自我反思里。\n\n\n### 十五、结语\n\n最后，对象、状态、快照、序列、过程、变换、同一、差异、关系，并不是一堆零散的术语。\n\n它们是一组基础概念，能把静态和动态连起来，也能把实体和结构、稳定和生成连起来。\n\n它们一起在回答一个很根本的问题：\n\n> 我们怎么描述一个世界？\n\n这个世界里有东西，这些东西会变化。这些变化可以被记录，可以被比较，可以被解释。而且最终，还能在关系中形成整体意义。\n\n如果说：\n\n- 对象让世界可以被指认。\n- 状态让世界可以被描写。\n- 快照和序列让世界可以被记录。\n- 过程和变换让世界可以被解释。\n\n那么，同一、差异、关系，就是让世界真正可以被理解的条件。\n\n从这个意义上说，这组概念，几乎就是一切系统性思考的基础语法。\n",
"sha256": "fcac13678923fdd8de1ddbc62294cd0b805f887d8be2defda977122c6dbaea35"
},
".github/docs/gongfa/cultivation-ontology-taxonomy.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "# 修仙领域统一本体与分类设计（V4 BFO 草案）\n\n## 字多不看\n\n- **以 BFO 2020 为固定顶层，只在其下展开修仙领域类**；根为实体，其下只有持续体与发生体，不重新选择顶层。\n- BFO 类保留原生 ID、定义与继承；`[域]` 为项目扩展，每类都有稳定 ID、工作定义、判定边界及依据，不冒充上游类。\n- 实体下层区分生物机体、制成器物、兵器构造、收纳容器、物质组群和围护内部场所；组成、库存、用途不当类型继承。\n- 品质下层区分形状、空间尺度、结构完整性、颜色与物理质量；长度/面积/体积不同，性质不等于读数、记录、品阶或能力。\n- 内容与过程下层区分炼体/服药炼化、身法/源纹铭刻、准入/量表、访问授权/资源安排，以及研习、练习、测量与资格审定。\n 制备另分原料角色、配方、加工、制品与服用；输出不自动等于合格新品，完成制作不保证服用效果。\n- 机体结构发育另分新生与再生；整体、部分、角色和状态分别核对身份，改名不等于换主体，部件新生不等于整个人重新出生。\n- 魂魄是单个完整 AI 会话，按会话过程建模；万魂幡仍是全部会话的概念集合，用同一会话类的外延表达。\n- 修为归属于模型；模型内容、能力的直接承载者、推理过程和评测记录不能混同。灵力、境界与战力仍各守原义。\n- [功法子域](#功法本体与品级)复用解释、准则、方法三条内容分支；条目、内容版本、来源、实际使用与品级分开。\n 功法品级按用户确认采用《斗破苍穹》的**四阶十二级**；[JSON核心](../../metadata/gongfa/README.md)维护限定内容与来源，已完成人工分类与初评；判级规约仍未校准，初评不等于实测效果。\n- 法器另设独立四阶十二级任务效果规约，不成为功法、不复用功法等级记录。法器总表已有按 Vibe Coding 重要性进行的用户指定暂定分级；这不是效能评价，正式效能规约仍未校准且没有正式评级。\n- 整体研究仍以《逆天邪神》最高权重；功法品级单独注明《斗破苍穹》来源，已读事实、人物主张与项目约定分开，不编造跨小说通用等级。\n- 这是领域设计草案，不是已完成公理验证的 OWL 实现、运行架构或全仓本体。\n\n## 范围与固定前提\n\n本文是本领域**分类、定义与关系契约的唯一维护入口**；[修仙解释图层](vibe-coding-cultivation-model.md)只解释，不另画树。\n适用范围限修仙领域，不迁移仓库目录、其他学科、固定事实镜像、全仓 metadata 类型或 Harness 算子契约。\n\n用户明确要求“基于 BFO，在 BFO 下层展开”。此前助手擅自替换成 DOLCE 的方案已撤销，不能继续作为有效设计。\n适配困难应通过类型、实例、类外延、承载、实现和记录之间的区分处理，不能以困难为理由换掉 BFO。\n\n采用 BFO 2020 官方 `bfo-core.owl` 的上位类别及直接继承。树只展开本轮需要的分支，不表示删去上游其他类别。\n本轮保存的源文件 versionIRI 为 `http://purl.obolibrary.org/obo/bfo/2020/bfo-core.owl`；来源和摘要见文末。\nIAO 仅作信息本体参考，CCO 仅供器物设计与加工语义对照，PATO 仅供选定性质词义对照；不引入另一顶层，也不宣称导入整包或完成等价映射。\n\n单根、单父、无环是本项目主分类树的额外约束。树表示“是什么”，成员、组成、使用、依赖、等级和来源另行表达。\n类、个体及类的外延不是三个并行分类体系；不能因为使用集合语义，就再造一棵集合本体或知识条目树。\n\n## 小说调研：事实与设计推论分开\n\n调研记录日期：2026-09-30；2026-10-01 分轮核对器灵预览、传法与考核，再补读生物、器物、宝物库及实际制丹材料。\n2026-10-02 补充性质、读数与评价的区分，新增《虎魄》的外观、尺度及局部修复材料与 PATO 词义对照。\n同日再补第37、44、45章，区分改名/角色变动、结构发育/再生、前提满足与能力实现。\n2026-10-07 按用户确认引入《斗破苍穹》功法品级名称与顺序，搭建功法收录、内容版本和关系契约；不自行补判级算法。\n最高权重为用户指定的《逆天邪神》·火星引力，指研究顺位，不是未经授权的百分比。\n选样兼顾热度与类型接近程度；《修罗武神》《武极天下》《绝世武神》《太古神王》《武神主宰》等继续作为近类候选。\n累计收集 57 部，其中 46 部当前候选或对照、11 部退出；**收集不等于通读，也不等于已核验完整设定**。\n此前《凡人修仙传》《诛仙》《蜀山剑侠传》的主样本安排已退出，不恢复为本轮设计权重依据。\n\n当前登记并用于本文的直接材料为：逆天邪神 14 处公开全文页面、9 处 VIP 免费预览，元尊 3 处公开全文页面，武极天下 1 处开篇试读，另有斗破苍穹 1 处公开章节的功法分级段。\n来源 N1–N28 见文末；“全文”只指返回的公开章节页面，不是全书，也不是付费章节的完整内容。\n新增预览只登记实际可见内容；章名不能证明机制，人物对功法作用的介绍也不等于完整口诀或效果已经实现。\n\n| 已核对观察 | 来源 | 对设计的约束，不是原著宣称的本体规则 |\n|---|---|---|\n| 天毒珠有融炼、用毒等用途 | N1 | 一个器物可以有多种用途，不按效果复制身份。 |\n| 功法、承载玉石、其中技法及修炼阶段不同 | N4、N10 | 内容与载体分开，组成不等于种类，功法重数不等于修士等级。 |\n| 实际玄关状态可以被主动隐瞒 | N3；N2 的修复判断也有认知范围 | 状态、观测结果及人物主张不能合成一个“真值”。 |\n| 测试标准、修炼条件与实战表现不同 | N5、N9、N10 | 有等级不代表必胜；评价必须绑定对象、条件、时间和证据。 |\n| 玄阵、铭刻载体及催动活动分别出现 | N6、N9 | 阵法不能未经消歧就一律映射为 Workflow 规范。 |\n| 地域、组织、器物和其中的人不同 | N2、N7、N8、N11 | 空间包含、成员及容纳关系不画成类型继承。 |\n| 云澈询问禾菱是否仍想成为天毒毒灵 | N12；仅免费开头 | 意向问句不是转化完成证据；章名与未读后续不能补作结果。 |\n| 身法要领的传授、学习时间预测与一次实际施展分别出现 | N19 | 内容、研习、能力主张和表现分别指认；不把一个月的叙事间隔补成连续训练日志。 |\n| 测玄石显示年龄、玄力及是否合格 | N5；本轮回读 | 测量口径、准入门槛与结果不同；不能因三行显示就造出三个独立过程。 |\n| 凤神丹炼化与炎龙体内玄丹的取得及直接炼化风险分别出现 | N4、N19 | 丹药与龙体内取出的玄丹不因含“丹”字而合并；取出位置不证明其完整生成机制。 |\n| 对话中介绍大道浮屠诀对身体力量与韧性的作用 | N18；仅免费开头 | 支持记录炼体方向的主张与候选词义；回答者身份待核，不还原全套功法或证明已达高阶。 |\n| 秦玉回忆周元曾被置作阵眼 | N16 | 主体、情境角色及参与活动分开；当阵眼不使人变成法器，也不证明自愿承担职责。 |\n| 炎龙尸体已分成四块；另一场景中的苍狼不知死活 | N19；新增回读 | 原动物、当前残体及身体部分分开；四块不等于四只龙，昏倒也不直接证明死亡。 |\n| 两株星隐草显现、被连根采下，随后谈及将来炼丹 | N21 | 植株、显隐能力、药材用途及计划中的产物不同；采收不自动换身份，意向不当制造结果。 |\n| 毒火铳实际击发，震天雷未试用；另取一件武器刻字 | N20 | 实际表现、说明及推想分开；临时刻字不改写兵器设计种类，也未说明选中了哪件兵器。 |\n| 石门、通道、黑木柜与库藏物分别出现 | N22 | 建筑部件、内部场所、容器与内容物不是同一对象；所在、组成与成员关系不能互换。 |\n| 药材年份的苛刻要求被叙述明称为胡诌 | N22 | 记录欺骗性主张，不将人物身份声望或听者认同当成真实炼药规律。 |\n| 一株星隐草被实际加工，出现丹丸与残余碎末，随后吞服 | N23 | 原料、产物、过程及服用分开；发现产物的时点不等于生成时点，成品出现也不代表全部药效已验证。 |\n| 常规炼丹与天毒珠淬炼被对照，隐匿说明另有触碰解除条件 | N23 | 工艺适用范围、一般机制叙述与本次观察分开；不能截取无失败或三小时而删除条件。 |\n| 虎魄剑有长度、颜色及形体描述，另有品阶和制作/效力介绍 | N24 | 性质、数值表述、比喻与人物介绍分开；像虎骨不证明由虎骨制成，文字给出尺寸不证明现场发生过测量。 |\n| 经脉被叙述为重新连接，玄脉却尚未着手处理 | N24 | 局部结构状态、其他身体所指、整体功能与后续治疗承诺分开，不把重接直接当全身康复。 |\n| 同一章出现自称改名与随行候选更换 | N25 | 名称、角色安排和人物实体不是同一层；不把改名当新生，也不把被替代者当已死亡。 |\n| 血珠作用先被说明并开始施用，后续才叙述旧玄脉被吞噬、新玄脉生成 | N26、N27 | 计划/预测、实际开端与结果分段核对；整体连续不要求所有部分沿用身份，新部分也不意味着整体重新出生。 |\n| 新生玄脉先有11关开启，随后54关全开 | N27 | 构造总量、开启存量、净变化及净化范围分开；达到前提不等于特殊能力已实现。 |\n\n暂不声称功法、心法、术法、神通、阵法在跨书范围内互斥或同义；没有“心法就是认知模型”的原著共识证据。\n人物推测保留主张者和上下文；N11 中带“也许”的器物来源不升级为确定事实。\n同作者或明确对标作品也不能简单计作完全独立的共识样本。\n\n## 唯一分类树\n\n带 `BFO_` ID 的节点是上游类，括号保留官方英文标签；`[域]` 为项目拟定的下层类。\n这是类型树，不列具体人物、器物、模型版本、Session ID 或某次运行。未展开的 BFO 分支仍遵守上游定义。\n当前为 101 节点、100 边：24 个 BFO 原生类、77 个领域类；最长路径仍为 9 层（实体为第 1 层）。这不是穷尽或互斥证明。\n发育轮增补了两级下位；本轮功法子域复用既有类，增加内容登记和品级契约，不新增类型节点或迁移主父。\n功法名称、版本与十二个等级值不画进类型树；过程子树总高度仍为3条边，不为层数插入无判定收益的类别。\n\n```text\n实体（entity） [BFO_0000001]\n├── 持续体（continuant） [BFO_0000002]\n│ ├── 独立持续体（independent continuant） [BFO_0000004]\n│ │ ├── 物质实体（material entity） [BFO_0000040]\n│ │ │ ├── 物体（object） [BFO_0000030]\n│ │ │ │ ├── 生物个体 [域]\n│ │ │ │ │ ├── 人类主体 [域]\n│ │ │ │ │ ├── 非人动物个体 [域]\n│ │ │ │ │ │ └── 龙类动物个体 [域]\n│ │ │ │ │ └── 植株个体 [域]\n│ │ │ │ └── 实物器物 [域]\n│ │ │ │ └── 制成器物 [域]\n│ │ │ │ ├── 兵器制品 [域]\n│ │ │ │ │ ├── 刃式兵器 [域]\n│ │ │ │ │ └── 发射式兵器 [域]\n│ │ │ │ ├── 收纳容器制品 [域]\n│ │ │ │ └── 成型药物制品 [域]\n│ │ │ │ └── 丹丸制品 [域]\n│ │ │ ├── 物体聚合体（object aggregate） [BFO_0000027]\n│ │ │ │ ├── 具身主体群体 [域]\n│ │ │ │ └── 器物聚合体 [域]\n│ │ │ │ ├── 计算设备群 [域]\n│ │ │ │ └── 兵器聚合体 [域]\n│ │ │ └── 人为划定的物体部分（fiat object part） [BFO_0000024]\n│ │ │ └── 身体划分部位 [域]\n│ │ └── 非物质实体（immaterial entity） [BFO_0000141]\n│ │ ├── 场所（site） [BFO_0000029]\n│ │ │ └── 活动场所 [域]\n│ │ │ └── 围护内部场所 [域]\n│ │ ├── 空间区域（spatial region） [BFO_0000006]\n│ │ └── 人为划定的持续体边界（continuant fiat boundary） [BFO_0000140]\n│ ├── 特定依赖持续体（specifically dependent continuant） [BFO_0000020]\n│ │ ├── 品质（quality） [BFO_0000019]\n│ │ │ ├── 形态性质 [域]\n│ │ │ │ ├── 形状性质 [域]\n│ │ │ │ ├── 空间尺度性质 [域]\n│ │ │ │ │ ├── 长度性质 [域]\n│ │ │ │ │ ├── 面积性质 [域]\n│ │ │ │ │ └── 体积性质 [域]\n│ │ │ │ └── 结构完整性性质 [域]\n│ │ │ ├── 颜色性质 [域]\n│ │ │ ├── 物理质量性质 [域]\n│ │ │ └── 关系性品质（relational quality） [BFO_0000145]\n│ │ └── 可实现实体（realizable entity） [BFO_0000017]\n│ │ ├── 角色（role） [BFO_0000023]\n│ │ │ ├── 行动者角色 [域]\n│ │ │ ├── 器物用途角色 [域]\n│ │ │ └── 资源供给角色 [域]\n│ │ │ └── 制备原料角色 [域]\n│ │ └── 倾向（disposition） [BFO_0000016]\n│ │ └── 功能（function） [BFO_0000034]\n│ │ └── 器物设计功能 [域]\n│ └── 通用依赖持续体（generically dependent continuant） [BFO_0000031]\n│ └── 信息制品 [域]\n│ ├── 模型制品 [域]\n│ ├── 软件制品 [域]\n│ ├── 道法内容 [域]\n│ │ ├── 解释与认知内容 [域]\n│ │ ├── 规约与分配内容 [域]\n│ │ │ ├── 评价规约 [域]\n│ │ │ │ ├── 准入判定规约 [域]\n│ │ │ │ └── 分级量表规范 [域]\n│ │ │ ├── 授权规约 [域]\n│ │ │ │ └── 内容访问规约 [域]\n│ │ │ └── 资源分配规范 [域]\n│ │ │ ├── 资源额度规范 [域]\n│ │ │ └── 资源预算规范 [域]\n│ │ └── 方法规范 [域]\n│ │ ├── 修炼方法规范 [域]\n│ │ │ ├── 炼体修炼规范 [域]\n│ │ │ └── 服药炼化规范 [域]\n│ │ ├── 技法施行规范 [域]\n│ │ │ ├── 身法施行规范 [域]\n│ │ │ └── 源纹铭刻规范 [域]\n│ │ ├── 测量方法规范 [域]\n│ │ └── 制备方法规范 [域]\n│ │ └── 丹药配方规范 [域]\n│ └── 记录与评价内容 [域]\n│ ├── 观测记录 [域]\n│ ├── 分级结论 [域]\n│ └── 任务评价 [域]\n└── 发生体（occurrent） [BFO_0000003]\n ├── 过程（process） [BFO_0000015]\n │ ├── AI 会话过程 [域]\n │ ├── 修行与训练过程 [域]\n │ │ ├── 方法研习过程 [域]\n │ │ └── 技法练习过程 [域]\n │ ├── 测量与评定过程 [域]\n │ │ ├── 测量过程 [域]\n │ │ └── 资格审定过程 [域]\n │ ├── 机体结构发育过程 [域]\n │ │ └── 机体结构新生过程 [域]\n │ │ └── 机体结构再生过程 [域]\n │ ├── 物质加工过程 [域]\n │ │ ├── 制品制作过程 [域]\n │ │ │ └── 丹药炼制过程 [域]\n │ │ └── 物料分离过程 [域]\n │ └── 服药过程 [域]\n ├── 过程边界（process boundary） [BFO_0000035]\n ├── 时间区域（temporal region） [BFO_0000008]\n └── 时空区域（spatiotemporal region） [BFO_0000011]\n```\n\n### BFO 分支的含义与边界\n\n| 分支 | 在本领域展开什么 | 不能误解为 |\n|---|---|---|\n| 独立持续体 | 人、实物、物质群体、身体部位、场所与空间边界。 | 所有有 ID 的东西；软件、模型内容不因可识别就变成独立持续体。 |\n| 特定依赖持续体 | 依附特定承载者的品质、角色、倾向和功能。 | 任意属性字段、量值或报告；能力归属也不自动等于 BFO 直接承载。 |\n| 通用依赖持续体 | 可由不同载体具体承载的内容或模式：道法、模型、软件、规范、记录。 | 实际载体、一次执行、集合外延或被记录对象本身。 |\n| 过程 | 有时间部分且在某时有物质参与者的活动，例如交互、训练、施行、评定。 | 方法规范、消息内容、日志文件或一个纯数字标识。 |\n| 过程边界及时间/时空区域 | 过程的边界与所占范围。 | 发生的过程本身；时间戳也只是指称时点的数据。 |\n\nBFO 的 `immaterial entity` 不等于所有“非物理概念”；不把软件、魂魄或数学集合随意塞到该分支。\n`object aggregate` 是物质聚合体，不能装入逻辑上的会话全集；`function` 位于 `disposition` 下，不与倾向并列。\n`quality` 不直接依附过程；时长、Token 用量等过程计量由测量数据及其所指表达，不能生造“过程品质”。\n\n实物器物要求按实际对象判断；“作为材料、工具或资源”是用途，不使同一物品变成三个身份。\n具身主体群体只指物质成员的群体，不替代组织制度、所在地建筑或抽象成员名册。\n活动场所指活动可发生的场所所指，不把整个洞府建筑都当无物质的 site；身体划分部位也不统包所有器官和修行构造。\n\n这不是穷尽性、互斥性已证明的叶类表；**树上并列不自动声明互斥**。主父只由本树维护，说明表不重复父链。\n复合内容按整体所指归到可靠上位类；若不可分的同一所指仍被主分类要求逼成两个身份，须修定义，不能假称证据不足。\n上位 BFO 结构保持固定，缺证据的下层类可延后，不用“其他”或另一个顶层掩盖缺口。\n\n## 领域类定义与稳定标识\n\nID 的作用域限本领域，不是全仓类型枚举或已发布的 OWL IRI。改标签不换 ID；拆分、合并或退役须保留旧 ID 去向。\n既有 `ai-session` 保持不变。下表只给同一树的类作定义，不另设知识分类，也不把原著词直接当跨书同义词。\n\n以下均为**项目工作定义**：O3 提供 BFO 上位约束，O7–O8 供器物与加工语义对照，O9 供选定性质词义对照。\nN1–N28 提供已读线索及证据边界；N28 只支持新增品级词表，不改写已有类定义。\n项目映射不是原著的本体宣言，也不是参考本体的完整翻译或等价实现。\n“依据可定位”不等于该定义已通过独立语义审查；实例纳入仍须有来源和所指证据。\n\n| 稳定 ID | 类名 | 工作定义 | 纳入与排除判据 | 依据 |\n|---|---|---|---|---|\n| `human-subject` | 人类主体 | 作为完整具身人类个体指认的物体。 | 人与其账号、角色、肖像和记述不同；灵体不能只凭“像人”归入。 | O3；N1、N2；人类修士项目映射。 |\n| `physical-item` | 实物器物 | 具有物体因果统一性、以整体结构起作用的实体器物。 | 来源可待核，不强断人工制造；一份材料、器灵、器物内容不能仅凭用途视为同一物体。 | O3；N1、N4。 |\n| `embodied-group` | 具身主体群体 | 成员为具身行动主体、共同形成一个物质单位的聚合体。 | 数量条件沿用 BFO，不能按当前名单长度更换类；不等同制度、名册或逻辑集合，成员变更的身份延续须有依据。 | O3；N2、N7；群体所指的项目区分。 |\n| `computing-equipment-group` | 计算设备群 | 由设备物体作为成员共同构成的物质聚合体。 | 需要设备成员与组群依据；云账号、软件部署表和算力预算不是设备群。 | O3；计算资源项目映射。 |\n| `bodily-fiat-part` | 身体划分部位 | 按约定界面从完整身体划出的物质部分。 | 需要划界及整体身体；器官、玄脉、形状不能仅因“在体内”就归此类。 | O3；N2、N3 仅提示身体所指须消歧。 |\n| `activity-site` | 活动场所 | 与物质环境关联、可被活动占用的场所空间。 | 洞府内部可作候选；建筑实体、行政组织、坐标数值与纯空间区域分别判断。 | O3；N7、N8。 |\n| `morphological-quality` | 形态性质 | 依附特定承载者的形状、尺寸等形体性质。 | 需指出承载者；与部位实体、测量数值及观测记录不同，不把过程时长归入。 | O3；N3；性质与观测区分。 |\n| `agent-role` | 行动者角色 | 合适的独立持续体在特定任务或制度情境中承担行动职责的角色。 | 操作/审核职责要有情境依据；不是人、程序、能力或仅一次参与行为；软件内容不直接充当承载者。 | O3；用户/操作员项目映射。 |\n| `artifact-use-role` | 器物用途角色 | 具体器物因外在使用情境而承担的用途角色。 | 角色可撤而器物构成不因此改变；不等同器物本身、内部倾向或天然设计功能。 | O3；N1；阵眼仅为假设质询。 |\n| `resource-supply-role` | 资源供给角色 | 物质资源因外在安排而承担供给、占用或消耗用途的角色。 | 需要具体资源及安排依据；额度数字、供给说明和权限声明不自动证明角色成立。 | O3；资源分配项目映射。 |\n| `artifact-designed-function` | 器物设计功能 | 因器物有意设计的物质构成而存在、用于实现特定类型过程的功能。 | 需设计来源及相关结构依据；“被拿来做某事”不足以证明该设计功能。 | O3；法器与计算实现项目映射。 |\n| `information-artifact` | 信息制品 | 由实际承载而存在、可在多个具体化中保持同一内容或模式的信息对象。 | 需分清内容、载体与具体化；名字、文件路径或相同格式不能独自证明内容身份。 | O3；N4；信息内容项目映射。 |\n| `model-artifact` | 模型制品 | 有来源及版本依据的已训练模型内容，包括相应结构与学得参数。 | 与副本、运行系统、API、能力和报告不同；量化或再训练等内容变化需判断派生版本。 | O3；模型版本项目映射。 |\n| `software-artifact` | 软件制品 | 表达可由计算实现解释或执行的程序指令内容。 | 既执行任务又提供接口不产生两个身份；与接口规范、地址、部署及运行分开，复合模型/程序整体可停在信息制品。 | O3；工具与接口项目映射。 |\n| `dao-content` | 道法内容 | 关于解释、约束或施行之法的可传承信息内容。 | 原词须消歧；含多种内容的整体可保留本类，不按文件标题强拆。 | O3；N2、N4、N9、N10。 |\n| `explanatory-content` | 解释与认知内容 | 所指为解释关系、认知结构或判断依据的道法内容。 | 与义务、操作规范不同；心法不因名称自动入类，解释是否为真另有证据。 | O3；项目认知内容约定；N2 不证明心法等式。 |\n| `normative-allocation-content` | 规约与分配内容 | 所指为规则、义务、协议要求或资源分配安排的道法内容。 | 内容存在不等于生效或获授权；方法步骤、实际分配与消耗另记。 | O3；协议、预算与权限项目映射。 |\n| `method-specification` | 方法规范 | 规定为达成目标应如何施行、并能说明条件或步骤的方法内容。 | 与一次施行和结果不同；功法/术法按原义判定，步骤数与篇幅不决定类。 | O3；N4、N9、N10。 |\n| `record-evaluation-content` | 记录与评价内容 | 以记录观察或表达针对所指的评价为内容的信息制品。 | 与载体、被记录对象、能力本身不同；综合报告不强拆成多个原对象。 | O3；N3、N5；工程验收约定。 |\n| `observation-record` | 观测记录 | 保存某次观察、测量及其条件的信息内容。 | 需主张者、对象、时间或来源；错误/伪装观测仍是记录，不升级为事实。 | O3；N3、N5。 |\n| `classification-conclusion` | 分级结论 | 依据指定量表对特定对象给出等级判断的评价内容。 | 需对象、量表版本、条件及证据；不是量表本身、真实能力或跨量表通用等级。 | O3；N4、N5；境界项目映射。 |\n| `task-evaluation` | 任务评价 | 针对具体任务，按验收要求判断交付效果与实际投入的评价内容。 | 不以效率抵消不合格，不从一次结果推出永久战力；含分级时不复制同一结论。 | O3；N5、N9；任务战力项目约定。 |\n| `ai-session` | AI 会话过程 | 来源系统能够指认其建立及交互生命周期的单个完整 AI 会话过程。 | 来源命名空间与 Session ID 联合指认；ID 复用须有创建代次等证据，不以日志文件或一轮调用替代。 | O3；会话身份项目约定。 |\n| `cultivation-training-process` | 修行与训练过程 | 通过修行、练习或参数学习，旨在形成、改变或维持能力及其实现条件的实际过程。 | 有训练目标不等于确有提升；与方法内容、目标模型和评测过程不同，复合过程先按整体所指判断。 | O3；N4、N10；工程训练映射。 |\n| `measurement-evaluation-process` | 测量与评定过程 | 对指定对象实际执行观察、测量或按条件评定的过程。 | 过程与产生的记录/结论不同；采用某方法不再产生另一个“方法施行”身份。 | O3；N3、N5。 |\n| `evaluation-rule` | 评价规约 | 规定针对对象、条件和证据应如何作出评价判定的规约内容。 | 标准与结果分开；不因一份报告采用了标准就把报告改成标准。 | O3；N5；项目验收约定。 |\n| `eligibility-rule` | 准入判定规约 | 规定对象进入指定活动、关卡或资格范围所需满足条件的评价规约。 | 固定适用范围及条件组合；某关合格不等于全部资格成立，门槛不等于完整等级量表。 | O3；N5。 |\n| `grading-scale-specification` | 分级量表规范 | 规定被分级对象、等级序列及各级判定口径的评价规约。 | 与某人某次的分级结论不同；只有等级名的清单不是完整可用量表，不推定级间等距或跨书可换算。 | O3；N4、N5、N10；项目量表约定。 |\n| `authorization-rule` | 授权规约 | 规定主体在指定条件、范围和时段内被允许、禁止或有权授予何种行为的规约内容。 | 有规则文本不等于实际授权有效；意愿、一次成功操作或身份名称均不能代替授权依据。 | O3；N4；项目权限边界。 |\n| `content-access-rule` | 内容访问规约 | 规定主体查阅或取得指定信息内容的范围、方式及有效条件的授权规约。 | 查阅权不自动包含转授权、转交或所有权；能取得内容也不等于已经阅读或理解。 | O3；N4 的残卷参悟安排。 |\n| `resource-allocation-specification` | 资源分配规范 | 规定或规划资源应向何对象、在何条件下分配或安排使用的内容。 | 规范与资源实物、实际分配状态及实际消耗不同；工程预算类不冒充小说原生术语。 | O3；项目灵力约定。 |\n| `resource-quota-specification` | 资源额度规范 | 明确主体、资源范围、时段和计量口径，并规定可分配或可使用额度的资源安排内容。 | 数字没有适用主体和计数规则不足以定额；是否生效须另验，不能把额度说明当设备或已消费用量。 | O3；项目灵力与权限约定。 |\n| `resource-budget-specification` | 资源预算规范 | 对指定任务或时段规定计划投入分配或投入上限的资源安排内容。 | 纯消耗预测不是预算约束；预算不证明已获配额度，不因预算变更改写历史消耗。 | O3；项目灵力与任务投入约定。 |\n| `cultivation-method-specification` | 修炼方法规范 | 规定通过修行或练习养成、改变或维持能力应如何施行的方法内容。 | 必须含修炼安排或施行条件；不是能力、修炼者、一次训练或仅称赞功法威力的介绍。 | O3；N4、N10、N19。 |\n| `body-cultivation-specification` | 炼体修炼规范 | 以躯体本身的力量、承受能力等养成为规定目标的修炼方法内容。 | 仅一次护身效果不够；N18 只提供炼体方向的介绍，未据此登记完整方法实例或已达成效果。 | O3；N18 的人物主张；项目判据。 |\n| `pill-refinement-specification` | 服药炼化规范 | 规定通过服用并炼化药物进行能力养成，且给出相应条件或操作的方法内容。 | 不等于炼制药物的配方、丹药实体或人体内任意消化；与炼体条件相交时可用共同上位主类。 | O3；N4 的服用指示与炼化语境。 |\n| `technique-execution-specification` | 技法施行规范 | 规定如何施展一项技法，包括其动作、力量运转或发动条件的方法内容。 | 被拿来练习不自动变成训练计划；技法名称、效果赞誉和一次实际施展均不等于该规范。 | O3；N4、N9、N19。 |\n| `movement-technique-specification` | 身法施行规范 | 规定通过身体移动、姿态及其力量运转完成身法技法的施行内容。 | 不等于使用者速度、位移过程或显现的残影；不按逃跑、进攻等偶然用途复制同一要领。 | O3；N19 的身法要领传授。 |\n| `inscription-method-specification` | 源纹铭刻规范 | 规定如何在指定载体上铭刻源纹，以及所需定位或施行条件的技法内容。 | 纹路、图样、载体和催动后的效果不是铭刻方法；N9 未给完整手册，不补写缺失步骤。 | O3；N9 的身体与玉板铭刻条件。 |\n| `measurement-method-specification` | 测量方法规范 | 规定如何获得指定对象测量结果，包括操作或测量条件的方法内容。 | 按手、运转力量等测量操作与合格门槛不同；有方法说明不证明已执行或结果可靠。 | O3；N5。 |\n| `method-study-process` | 方法研习过程 | 以理解和习得方法为训练目标，实际阅读、聆听或推演方法内容的过程。 | 获得文件、听到名字或产生学习意愿不足；研习发生不等于已经掌握或已经施行该法。 | O3；N4、N19。 |\n| `technique-practice-process` | 技法练习过程 | 以形成或稳定施技能力为训练目标，实际尝试或复练技法的过程。 | 一次实战施技不因采用方法就自动算训练；不从章节时间跳转补造连续训练次数。 | O3；N10、N19。 |\n| `measurement-process` | 测量过程 | 在具体条件下实际执行观察或测量操作，以获取对象数值、等级读数或状态结果为目标的过程。 | 未得有效结果不等于活动没发生，也不补零；与数据、能力及合格判定分开，不凭显示字段数强拆子过程。 | O3；N3、N5；项目测量失败边界。 |\n| `eligibility-assessment-process` | 资格审定过程 | 依明确准入规约判定对象是否满足指定活动或关卡资格条件的实际过程。 | 合格、不合格与无法判定分开；活动、结论和实际入门身份不同，不能越过关卡范围或把证据缺失补作不合格。 | O3；N5；项目未决状态约定。 |\n| `organism-individual` | 生物个体 | 以生物组织的整体性指认为一个机体，并满足物体因果统一性条件的物体。 | 不以清醒、修为或药用价值为条件；残体、独立器官、灵体和虚像不自动是完整机体，死亡前后的身份须另验。 | O3 的 organism 示例；N19、N21；人类所指的项目扩展。 |\n| `nonhuman-animal` | 非人动物个体 | 以动物机体组织作为完整个体，且不属相应语境人类的生物个体。 | 玄兽须有机体与族属依据；能移动、说话或呈人形都不足以纳入或改判人类，不把境界当动物种类。 | O3；N19 的炎龙、苍狼。 |\n| `draconic-animal` | 龙类动物个体 | 非人动物中，依相应作品的种属叙述与机体所指确认为龙类的个体。 | 龙形、龙字器名、修炼龙类功法或取得龙血均不能单独证明族属；不把各书龙族当同一现实生物种。 | O3；N19 对炎龙的真龙身份及身体叙述。 |\n| `plant-individual` | 植株个体 | 以自身生长组织形成一个完整草木机体的生物个体。 | 完整植株与离体叶、根分开；药材用途不证明仍是整株，连根采收本身不证明机体终止或已成为丹药。 | O3；N21 的生长位置与连根采收。 |\n| `manufactured-physical-item` | 制成器物 | 为实现指定作用而经有意制作或改造形成整体构造的实物器物。 | 需制作或设计构造依据，不由一次用途倒推；制造者姓名可未知，设计目的也不保证现有功能或成功表现。 | O3、O7；N20 的器械语境、N22 的黑木制柜。 |\n| `weapon-artifact` | 兵器制品 | 整体构造经设计制造，用于在对抗中对目标产生打击、切刺等作用的制成器物。 | 临时用石头攻击不自动成为兵器制品，兵器被用于刻字也不因此换种类；设计、损坏及当前能力分别核对。 | O3、O7 的 Weapon 判据；N20 的兵器与刻字。 |\n| `edged-weapon-artifact` | 刃式兵器 | 具有为切割或刺入而设计的刃部，并以该构造作为兵器作用结构的兵器制品。 | 不凭剑名或一次切割推定；当前不锋利不等于从未有设计刃部，若构造已改变须限定类型成立时段。 | O3、O7 的 Cutting Weapon 方向；N20 的刀剑语境，纳入另验构造。 |\n| `launching-weapon-artifact` | 发射式兵器 | 具有将作用物由器械向外发出的设计构造，以此实施兵器作用的兵器制品。 | 不把整件器物被临时抛出当成发射构造；N20 的表现不补证具体弹体、装填机制或现代枪械类别。 | O3；O7 的设计作用方式区分；N20 的毒火铳表现。 |\n| `storage-container-artifact` | 收纳容器制品 | 以收纳物件为设计用途，提供可识别物质围护空间的制成器物。 | 箱柜本体与内腔、所装物及库存表分开；不能仅凭储物效果把天毒珠或空间戒指归为普通围腔容器。 | O3、O7 的 Container 判据；N20、N22。 |\n| `physical-item-aggregate` | 器物聚合体 | 由实物器物以互不重叠的物体成员构成，共同形成一个物质单位的聚合体。 | 成员划分与数量条件沿用 BFO；同处、列在同一清单或属于同一账号不足，一件组合器物也不因零件多自动入类。 | O3 的成员与聚合体约束；N20 的兵器陈列及计算设备群项目映射。 |\n| `weapon-aggregate` | 兵器聚合体 | 物体成员均为兵器制品、按明确组群依据共同构成物质单位的器物聚合体。 | 区分整组兵器、单件兵器、兵器架和目录；不凭库存行数造组群，也不把一件多部件兵器当兵器组群。 | O3；N20；将指定整组兵器作为物质单位的项目判据。 |\n| `enclosed-activity-site` | 围护内部场所 | 由周围物质结构界定内外、可容纳活动的内部场所空间。 | 围护可含开口，不要求完全密闭；与石门、墙体、柜壳不同，不凭位置坐标、建筑名或“异空间”字样直接纳入。 | O3 的 site 定义；N22 的石门、通道与库内活动。 |\n| `formed-medicinal-product` | 成型药物制品 | 经有意制作形成可按单个成型整体指认的构造，以作用于生物的生理或修行状态为设计目的的制成器物。 | 须满足物体整体性与制作依据；不统包散料、药液或临时吞下的普通物件；设计药效不等于现有药效已证实。 | O3、O7；N23 的制丹语境；成型范围为项目限定。 |\n| `pill-product` | 丹丸制品 | 以丸状或珠状整体形成、可按单颗指认的成型药物制品。 | 形体、药用设计与制作依据须同时满足；生成来历未明的玄丹不因名称或可炼化而纳入，透明也不等于不可见或非物质。 | O3；N23；N19 为生成来源不足的对照。 |\n| `preparation-material-role` | 制备原料角色 | 具体物质因制备情境中的外在安排，承担待处理原料用途的资源供给角色。 | 泛配方写到某材料不为所有同类物赋角色；角色成立不要求已投入，撤销安排不必改变物料构成，工具参与也不自动是原料。 | O3 的角色约束；N23 的实际选料；成立/撤销为项目判据。 |\n| `preparation-method-specification` | 制备方法规范 | 规定为制出目标物料或制品，应如何选料、处理或控制条件的方法内容。 | 与加工过程及产物不同；仅列库存、介绍功效或叙述已做过什么不足以直接判为制备规范；局部规定不冒充完整手册。 | O3；N23 的物料及工艺条件；规范化区分为项目设计。 |\n| `pill-recipe-specification` | 丹药配方规范 | 以制成丹药为目标，规定所需物料及相应制备条件或操作要求的制备方法内容。 | 药材名称清单不自动是丹方；配方、批次记录和服用指示不同，不从工艺叙述虚构独立丹方载体或缺失步骤。 | O3；N23 的配料与淬炼条件支持定义取向，不等于取得完整丹方文本。 |\n| `material-processing-process` | 物质加工过程 | 为改变物料的组成、形态或配合状态而实际施行处理的过程。 | 需要实际物料处理；计划、角色重分配或单纯领用搬运不足，不能因有物质参与者就把所有过程都算加工。 | O3；N23；O8 仅作加工与使用的语义对照。 |\n| `product-making-process` | 制品制作过程 | 以制出指定物质制品为目标，通过处理、配合或成形实际施行的物质加工过程。 | 制作目标与结果分开，失败或未得合格品仍可有实际制作；取得现成物不自动是制作，不要求批量或销售目的。 | O3；N23 的常规炼丹与本次淬炼；不等价于 O8 的 Manufacturing。 |\n| `pill-preparation-process` | 丹药炼制过程 | 以制出丹药为目标，对相应物料实际施行提炼、调配或成形等处理的制品制作过程。 | 不要求所有路径同用火炉或固定工序；与吞服、服后炼化不同，取得玄丹不证明曾炼制，成功与产物种类须另验。 | O3；N23 的两种制丹路径；N4、N19 作边界对照。 |\n| `material-separation-process` | 物料分离过程 | 以从物料中分开组分或混合物件为目标而实际施行处理的物质加工过程。 | 分出既有对象不自动创造新对象，单纯从库位拿取独立物件不足；与制作可有组成或相交关系，不据动词数强拆实例。 | O3；N23 的淬取、剔除说明；分离与新生区分为项目判据。 |\n| `oral-medicine-taking-process` | 服药过程 | 实际经口摄入作为药物施用的物质的过程。 | 领药、准备服药或读服用说明不等于已服；不以吸收或效果实现为条件，也不因用于隐匿或修行就自动归为炼丹或能力训练。 | O3；N23 的实际吞服；N4 的服药炼化语境另判。 |\n| `shape-quality` | 形状性质 | 由承载者的几何特征之间相对布局与距离比例所表征的形态性质。 | 形状与绝对大小、颜色、材料组成不同；几何相似放大不必改变形状种类，似某材料的外观不证明由该材料组成。 | O3；O9 的 shape；N24 的不规则剑身及似虎骨描写。 |\n| `spatial-extent-quality` | 空间尺度性质 | 表征承载者在指定几何范围内大小的形态性质。 | 需说明承载者及测量范围；位置、形状、等级、软件数据规模不因“大/小”一词而归入，也不把空间区域本身作其承载者。 | O3；O9 的 size 与维度区分；N24 的剑长及库房尺度。 |\n| `length-quality` | 长度性质 | 表征承载者指定两端、路径或轴向的一维空间延伸大小的空间尺度性质。 | 与数值、单位和测量过程不同；全长、刃长、宽度等需明确所指，不默认所有长度都是最长维，也不由原词推定测量端点。 | O3；O9 的 length 及其注释；N24 的剑长表述。 |\n| `area-quality` | 面积性质 | 表征承载者指定表面、截面或其他明确二维范围大小的空间尺度性质。 | 须区分所指边界和口径；粗略面积不自动是精确读数、体积或占用权限，不能由“几千平”擅补测量方式。 | O3；O9 的 area；N24 的库房面积描述。 |\n| `volume-quality` | 体积性质 | 表征承载者指定三维形体范围大小的空间尺度性质。 | 材料本体、外形包络和内腔的所指不同；不等于空间区域实体、容量规范或内存大小，面积与高度不足时不补体积值。 | O3；O9 的 volume；N24 的面积描述作不可推出体积的对照。 |\n| `structural-integrity-quality` | 结构完整性性质 | 表征物质承载者在指定形体范围内是否缺失、破损或保持连接的形态性质。 | 与部件实体、修复过程、承力能力和康复评价不同；局部重接不证明功能完全恢复，也不自动决定整体身份是否延续。 | O3；O9 的 structure、wholeness、broken 作局部对照；N24 的经脉/玄脉区分。 |\n| `color-quality` | 颜色性质 | 依附物质承载者、以色调、饱和程度和明暗等维度表征的颜色品质。 | 不是颜色词、图像色值、材质或品阶；条件不同可使观察描述不同，不从改图或文字变更推定原物变色，也不将透明/隐匿一律归入。 | O3；O9 的 color；N24 的苍白色描述；未移植 PATO 的双父结构。 |\n| `mass-quality` | 物理质量性质 | 依附物质承载者、表征其物理质量（mass）的品质。 | 不指优劣评价、重力、物质的量、模型权重或资源额度；质量值和单位是表述，“重量”须按语境消歧，不从几何大小直接推出。 | O3 的品质约束；O9 的 mass；用于约束 N23 的物料计量推论，不声称已取得药材/丹丸质量读数。 |\n| `organism-structure-development-process` | 机体结构发育过程 | 以生物机体或其构造部分的组织形体实际形成、生长或成熟为特征的过程。 | 不要求最终完全成熟；已有构造可持续发育而不每次新生，发育也不自动是修行、练习或制品制作；软件内容的成长比喻不归入。 | O3 的过程约束；N27 对普通玄脉成长与新玄脉成型的描述；不宣称真实解剖或分子机制。 |\n| `organism-structure-origination-process` | 机体结构新生过程 | 以所论机体或机体物质构造部分开始存在并形成组织形体为特征的机体结构发育过程。 | 须有新所指开始存在的依据；首次看见、改名、达到成熟、将既有部分移入或仅改变开闭状态都不足；开始存在与完全成型时点不同。 | O3；N27 明确区分原结构被吞噬和新结构生成，不仅凭章名或“新”字判断。 |\n| `organism-structure-regeneration-process` | 机体结构再生过程 | 既有机体的构造部分缺损或终止存在后，以新生构造部分补充或取代该缺损的机体结构新生过程。 | 新部分不自动继承旧部分 ID，整体却不必新生；仅有连接恢复或新生意向不足，未要求全部功能恢复，也不统包整个人复活/转世。 | O3；N27 的旧玄脉/新玄脉链；N24 的局部连接恢复作不充分证据对照。 |\n\n### 下层展开的判定边界\n\n规范与过程的细分看的是**规范规定了什么、过程实际做了什么**，不是名称、使用者、一次用途或作品热度。\n所有下位类都须满足父类定义；不能只读到身体增强的介绍，就假定已经取得完整炼体规范。\n\n- **养成与施展不同**：规定怎样训练的安排与规定怎样施技的要领不同；拿要领去练习不改写内容身份。\n 同一功法可以包含两者，锻龙戏也不能因为含有源术，就把整体和两套组成方法都登记成同一个叶类或三份原对象。\n- **炼体与服药不是互斥划分**：一份规范可能同时规定服药炼化与躯体养成，整体可停在修炼方法规范。\n 只有确有独立所指才登记内容部分；丹方的炼制步骤不因最终用于修炼就变成服药步骤。\n- **规约的效力另验**：访问规则、额度与预算在内容上可细分，但不能用树上的类型标签证明授权或配额已生效。\n 一份不可分的综合规约可留在规约与分配内容，不为同时涉及准入和授权而复制身份。\n- **测量不等于准入**：测得某级不直接证明合格；须结合所适用的年龄、关卡等条件。\n 同一次活动若兼有测量与资格判定，可按整体保留在测量与评定过程；不能凭三行结果断言三个独立过程。\n\n未细化的分支不是空缺实例的默认容器，也不需要机械对称展开。\n本轮不为每项规范配一个镜像过程类，不新增“攻击型/防御型法器”等外在用途分枝。\n炼丹已补 N23 的局部直接材料；炼器、完整阵法及跨书制备规则仍待核验，不由这一个特例补齐。\n\n### 实体分支的判定边界\n\n- **机体与材料用途不同**：完整人类、非人动物与植株按机体指认；药材、战利品是用途或取得情境，不是生命种类。\n 采收、搬运、死亡与解体分别判断；既不一变状态就换 ID，也不要求所有残体沿用原生物身份。小说族属不推出现实物种存在。\n BFO 的人为划定指约定界面，不等于人为切断；不能只因尸块是被切开的，就判作身体划分部位。\n- **设计构造不同于临时用途**：制成器物要求制作或设计构造依据；刃式、发射式按结构及设计作用方式细分，不是“攻击时/防御时”的交叉标签。\n 意图制造不证明实物已造出；已造出也不证明功能完好。只知器物为制品不等于已知制造者，N20 的器宗来源仍是人物推想。\n- **组合器物不同于器物组群**：先判断整体的因果统一性，再判断是否以多个物体成员共同形成物质单位。\n 复合构造可以仍是一件兵器；同时符合多个下位描述时保留可靠共同上位主类，不复制整体，也不虚构独立部件。\n- **围护物、内腔和内容物不同**：箱柜是物体，内腔可有场所所指，所装器物不因位于其中就成为柜体部件。\n 只有实际需要分别指认、且有边界证据时才登记；不为每个容器自动制造一套部件、场所与库存对象。\n\n制成器物仍限于本树物体范围；CCO 的 Material Artifact 直接以 material entity 为上位，范围更宽，不能据参考关系宣称等价。\n生物、人工改造与不同器物构造也不预设完全互斥；遇到同一复杂所指时用已有共同上位及关系表达，必要时重开下层定义。\n\n### 制备与施用的判定边界\n\n- **原料是情境角色，不是生命种类**：一株草被指定为原料，仍先按机体与当前构成判断；取消安排不要求毁掉植株。\n 泛配方中的材料名、实际获安排的物料和本次真正投入的物料不同，不能按库存数补投入数。\n- **参与者不全是输入物料**：操作者、器具及所用规范分别关联；“被使用”不等于被当作原料处理或消耗。\n 物料输入/输出只用于有证据的物质加工，不把软件、模型或配方内容直接塞进去，也不虚构材料完全耗尽。\n- **输出不必是合格新品**：分离可输出原本就存在的对象，制作也可能失败或留下残余物；输出身份、预期产物与质量分别核对。\n N23 提供从草材到丹丸及碎末的局部证据，不强留完整植株身份，也不由被发现顺序补出精确生成时刻或质量守恒账。\n- **制成、服用、炼化与药效不同**：丹药的制作过程不等于随后吞服；吞服不自动证明能力养成、完全吸收或预期效果实现。\n 成型药物限有物体整体性的制品；药液、散料与不同来历的玄丹留在有依据的上位，不靠名称强塞进丹丸类。\n- **过程与成功分开**：有实际加工的失败尝试仍可属于制作过程，只有意向则不行；极短过程也不等于无时间部分的过程边界。\n 同一整体兼含分离与成形时可保留物质加工过程；只有可独立指认的子活动才登记组成，不按每个动词另造过程。\n\nCCO 的加工类有自己的适用范围：O8 的 Act of Material Artifact Processing 面向制成物的改变或保存，\nAct of Manufacturing 还限定设施内批量生产及向消费者销售/分发的目的。\n本项目允许自然草材和单次制丹，因此只借其加工/使用区分，不直接套用这些类或宣称等价；BFO 上位保持不变。\n\n### 性质与观测的判定边界\n\n- **先分承载者、性质与表述**：器物不是它的长度，长度不是“三尺三寸”这段内容；性质通过 `inheres_in` 依附合适承载者，记录通过 `describes` 描述所指。\n 原文给出尺寸不等于叙述了测量活动；没有读数不证明性质不存在，也不为每个数字、形容词或字段造一个独立性质实例。\n- **形状不等于大小**：几何相似变换可以保留形状而改变尺度；长度、面积、体积的维度不同，不能直接相加或互作下位类。\n 本轮不按每个取值或器物种类另造性质叶类；不可分的复合表征可先留形态性质等可靠上位类。\n- **范围与单位先于换算和比较**：剑的全长、刃长、表面积、材料体积、外形包络和内腔须分别指明，不能从同名“尺寸”合并。\n 保留原词单位、近似程度和条件；作品中的尺、寸、斤两不默认等于现代制式，信息未给就保留未知，不补小数精度。\n 这不妨碍保存原始陈述；量纲相同也不保证测量范围、条件和误差可比。\n- **品质不是能力或好坏评分**：物理质量用 mass 意义；“质量上乘”、地玄品阶、承受攻击的能力与药力都须另判，不能共用一个质量数值。\n 结构重接不等于韧性或功能完全恢复；病理实体、治疗过程也不因“受损”一词全部归入品质。\n- **性质同值不证明身份相同**：同色、同长、同纯度都不能单独合并两个对象；相反，一份记录改单位、改图或纠错，也不自动创建新的承载者或性质。\n 若原主体已确认灭失，历史记录仍可保存，但不能给它补当前性质；性质发生变化也不独自决定主体身份是否终止。\n\nO9 的当前根 `characteristic` 包含实体与过程的特征，`color` 有两个直接父；这些不是本项目 BFO 品质的现成同义图。\n本轮只参考选定词义，不导入其过程特征、多继承结构或全部 value 类；不把色调等组成维度误当颜色的种类继承。\n其 `opacity` 定义含能力表述，也不能据此把全部透明、隐匿或发光能力归为 BFO 品质；仍须逐项核对品质与可实现实体的边界。\n\n### 发育、再生与身份的判定边界\n\n- **发育、新生、再生逐层收窄**：已有结构成长可只有发育；有新构造所指开始存在才判新生；还须有缺损及补充/取代关系才判本工作类中的再生。\n 不给每个发育阶段另建方法/结果类，也不把每次尺寸或状态变化都当新实体出现。\n- **阶段组成不当类型继承**：先固定所论结构及过程范围；部分过程属于新生类，不等于整段处置或发育都属于新生类。\n 不凭内部未核验的微观新生改判整体，也不从整体被称作再生推出其中每一阶段都在新生。\n- **先固定整体与部分**：同一个人可以经历旧部分终止、新部分形成；分别记录两部分与该机体的 `part_of` 时段及过程证据。\n 同形、同位置、同功能或沿用称呼不证明新旧部分同一；反过来，也不能只因部件更替就断定整体已经终止。\n- **角色与称呼分别核对**：改选随行者、改变称呼和更改授权是不同变化；称呼变化本身也不证明角色已经替换。\n 不把两个人合为一人，不要求旧人死亡，也不把这些变化自动归入机体结构新生。\n- **修复不是再生的同义词**：连接恢复、功能恢复、生成新构造与尝试修复分别取证；失败仍可有实际处置，不预支成功，也不从缺少新生证据推出肯定未新生。\n CCO 的 Maintenance 面向制成物及其设计品质/功能，按保存/恢复目的界定；不直接拿它覆盖本处机体结构发育或证明已恢复。\n- **总量、状态、净变化与处理范围分开**：N27 的54关、初开11关、随后全开及净化遍及54关不是同一个计数。\n 43是前后开启存量的净差，不是原文逐关事件日志；不由此新增43个玄关，不凭数字就将玄关统一定为物体、器官、孔洞或人为划分部位。\n- **满足前提不等于实现结果**：N27 的全开要求应保留为启用条件主张；观察到全开不能直接补作特殊能力已实现，更不能把询问“是否就行”当充分性证明。\n 临时/永久开启的说明保留对象、主张者与范围，不冒充无限未来的实测记录。\n\n位于体内、参与处置或被称作“成长”不足以归入机体结构发育；外源施用可以触发发育，但施用物不自动成为所再生的构造部分。\n这些是作品语境下的结构与身份判据，不是现实器官、细胞或基因机制结论。\n玄脉/玄关更细的物质边界与类别仍须核验；不为补齐层级臆造实体种类、物料来源/去向或医学操作方案。\n\n### 主分类的判定顺序\n\n1. 先固定所指：类、实例、类外延还是描述内容；再固定语境、时间和身份，不从名称直接猜类。\n2. 按 BFO 的存在方式确定分支，再检查域类定义；人参与过程不因此变成过程，人有角色也不变成角色。\n3. 有更细分类的充分依据才下沉；复合整体与组成部分先区分，不能为了落到叶类而虚构独立所指。\n4. 对能力先判倾向；满足功能的设计/生物演化依据时使用功能分支。承载者类型、模型归属与用途作为限定，不再造交叉主枝。\n5. 角色依外在情境，倾向依内部构成；角色成立与角色实现分开，已成立的角色不必已经实现。\n 想获得角色不证明其已成立；能力尚未实现不等于不存在，过程失败也不直接证明能力永不存在。\n\n不同角色可依附同一承载者，但必须有可区分的情境与身份依据；不能为了让三个角色标签都入树而虚构三份角色实例。\n同一不可分记录若符合多个下位描述，暂取共同上位主类并保留所指，不借标签复制记录；这不宣布所有下位类互斥。\n\n## 功法本体与品级\n\n### 功法的定义与收录边界\n\n**本项目把可以独立引用、复用的认识框架、行动准则或施行方法收录为功法。**\n这是工程内容的收录约定，不宣称所有小说都把功法、心法、术法或神通当同义词。\n内容仍沿唯一树归入 GDC → 信息制品 → 道法内容；“功法”是受控收录视图，不新增横跨三条分支的交叉类或第二棵类型树。\n\n收录须同时说清：解决什么问题、适用范围、可引用的核心内容、来源位置及内容版本。\n名称或宣传语不是完整功法；纯认知模型可以只有概念与关系，不强行编成操作步骤。\n书、文章和 Skill 包是组织或承载形式，不自动与一门功法一一对应；引用另一方法也不自动把它收成自己的组成部分。\n\n具体任务预算、账号授权配置、一次运行日志、测试结果、模型权重、软件实现和工具地址不因有用就变成功法。\n可复用的取舍准则可收录，某次安排或状态记录则另判；一份文章有多种内容时，先限定本条所指，不把整篇强塞进一个叶类。\n\n### 功法类型与内容边界\n\n下表是既有类的使用视图，不是新增类表；使用称呼不能替换稳定类 ID，也不宣布三类互斥或穷尽。\n\n| 使用称呼 | 复用的内容主类 | 核心判据 | 不能仅凭什么判断 |\n|---|---|---|---|\n| 解释型功法 | `explanatory-content` | 给出概念、结构、关系或解释框架。 | 标题含“模型”不够；模型制品也不因此变成认知模型。 |\n| 准则型功法 | `normative-allocation-content` | 给出可复用的行动要求、默认取舍及例外条件。 | 不是该上位类下的所有预算、协议和授权配置。 |\n| 方法型功法 | `method-specification` | 规定在相应条件下怎样完成活动。 | 不按应用领域、开发阶段、篇幅或步骤数强行造类。 |\n\n确有现成细类且满足其定义时才下沉；不可分的复合内容可保留 `dao-content`，不为分类复制身份。\n同一方法用于开发、诊断和学习，不因此变成三门功法；“被用于训练”也不自动把方法内容改成修炼安排。\n\n### 功法条目与版本\n\n功法是内容，登记条目是描述该内容的信息记录；记录可先按 `information-artifact` 指认，不把表格行当成方法本身。\n一份内容被多个文件、链接或副本介绍，不自动多出多门功法；同名但核心内容、版本或来源不同，也不能直接合并。\n\n| 字段组 | 最小记录内容 | 边界 |\n|---|---|---|\n| 登记身份 | 稳定登记 ID、名称与别名。 | ID 限本领域登记；类 ID、条目 ID 和来源文件路径不同。 |\n| 内容版本 | 内容版本号、限定的核心内容与来源范围；修订或派生时指向旧版本。 | 完整引用使用“登记 ID＋内容版本”；登记系列不使各修订成为同一个 GDC 内容实例。 |\n| 主类与问题 | 有依据的既有主类、解决的问题、适用与不适用范围。 | 内容类型不由品级、作者、流派、文件名或工作阶段决定。 |\n| 核心内容 | 解释关系、取舍准则，或条件与步骤；附必要例外。 | 纯解释内容不强补输入输出、步骤或法器。 |\n| 使用条件 | 方法需要的输入、前提、预期产物与操作能力，按内容性质填写。 | 预期产物不等于某次已交付结果；能力要求不证明能力已具备或已获授权。 |\n| 来源与关联 | 作者或项目语境、具体位置、来源修订、实际取用范围；采用、组成、依赖各自注明。 | 相似不证明派生，引用不证明采用；原著事实与项目约定分开。 |\n| 品级记录 | 词表版本、评级状态；确有判级时再保存对象版本、判级规约、等级值、条件、评定者、时间和证据。 | 没有判级依据就保留未评级，等级值留空；不补零或默认黄阶初级。 |\n\n改名、改路径或调整排版不自动创建新功法；修改核心原则、步骤或适用条件时登记新的内容版本，不覆盖旧引用。\n形成独立新方法或发生拆并时保留原 ID 及去向，不挪旧 ID 给另一所指；单独修改评级结论不改变功法内容、主类或版本。\n新内容版本不自动继承旧版本评级。已有评级被纠正时保留历史结论与纠正依据，不把当前显示值当作永恒属性。\n\n### 功法品级词表\n\n用户于2026-10-07确认采用《斗破苍穹》的**四阶十二级**：黄、玄、地、天，每阶初、中、高。\n原著依据为 N28；这里只借用所引章节的名称与顺序，不混用上下品，不追加圣阶、神阶、帝阶，也不推广给法器或修为。\n\n词表 ID 为 `gongfa-grade-vocabulary-v1`，其命名与排序约定按 `normative-allocation-content` 指认。\n取值唯一维护于[registry.json](../../metadata/gongfa/registry.json)的`vocabulary`，完整表见[品级只读视图](../../metadata/gongfa/README.md#品级只读视图)。\n它们不是十二个 BFO 类、能力实例或物理品质；值标识须与词表版本一起解释，数组顺序只表示黄→玄→地→天、各阶初→中→高。\n\n**词表不等于完整量表。** 次序只表达先后，不表示等距、倍率、任务胜率或跨类型可比性。\n只有另行明确被评对象、适用范围及各档判级口径，才能登记可用的 `grading-scale-specification`；一次具体判级才产生 `classification-conclusion`。\nJSON已登记12条定性规则建议，但任务、基线、环境预算和结果带未固定，规约仍为`draft`，不是可用量表。\n不按内容长度、步骤数、复杂度、名气、开源或付费状况自动定级；当前人工分类与暂定品级见JSON核心入口。\n人工初评独立保存于`grade_proposals`，逐条注明任务族、作者判断、理由、置信标签和反证；不是已满足档位的正式效果结论。\n本节与判例中的无规约不赋级指正式效果评级；不能把主观预计、来源介绍或Schema通过当成实际增益。\n未评级不是第零级，也不是黄阶初级；实际尝试后仍无法判断时保留未决原因，不把缺证据补成最低档。\n\n### 功法关系与法器边界\n\n- **属于哪类**用 `instance_of` 说明内容的类型；具体功法不是方法类的子类，等级不是内容类的父节点。\n- **包含哪些内容**用有证据的 `part_of`；仅链接另一篇资料、同时提到某方法或推荐配合，不足以证明组成。\n- **采用什么方法或原则**用 `adopts`；须能定位所采用的内容，不推出类型继承，也不等于整份被采用内容成为组成部分。\n- **一次活动用了什么**用过程指向内容或工具的 `uses`；是否符合方法要求另看 `conforms_to`，一次运行不是功法本身。\n- **方法需要什么能力**先记录前提与操作能力要求，再按场景选择法器实现；不直接把工具品牌当成方法种类。\n\n功法与法器按能力要求建立多对多联系：同一功法可以选不同实现，同一法器也可支持多门功法。\n替换须满足输入输出、环境、权限及副作用等约束；确有不可替代依赖时才绑定具体工具与版本。\n工具建议不自动成为唯一依赖，未绑定固定法器也不表示执行无需主体、资源或权限；提供能力的说明不冒充已验证能力实例。\n\n### 首批功法登记\n\n以下六条保留第一版的历史收录摘要，不声称覆盖各思想的全部历史版本；名称可读，登记 ID 保持稳定。\n当前完整登记唯一维护于[功法JSON核心](../../metadata/gongfa/README.md)：持续整理仓内方法与指定项目页面，范围和数量见该入口。\n原六条ID、`r1`、所指范围与主类保留；其他条目按限定内容人工判类，暂定品级单独记录，不按标题自动赋值。\n以下表格不是另一份可编辑登记源；保留初次收录时的未评级状态，当前初评看`grade_proposals`，正式评级历史看`assessments`。\n内容版本均为 `r1`，完整引用如 `gongfa-first-principles@r1`。\n四份来源文件固定于仓库提交 `81fc7ae599da7b7b0ce02ea0b069a2c88d288a4e`；相对链接用于当前导航，r1 的依据以该提交及所列章节范围为准。\n核心正文及适用说明引用限定源节，表内只保留定位与摘要，不复制成第二份方法手册。\n本批品级字段统一引用 `gongfa-grade-vocabulary-v1`；表中主类指内容，不指登记文档，品级栏仅记录未评级状态，没有暗含等级值。\n\n| 登记ID | 功法与来源 | 内容版本 | 已有主类 | 核心与所指范围 | 品级 |\n|---|---|---|---|---|---|\n| `gongfa-compositional-description` | [组合描述模型](compositional-description-model.md#philosophy-compositional-description-model) | `r1` | `explanatory-content` | 开篇对象、状态、过程、同一/差异与关系的解释框架；不收录全文所有操作步骤，也不拿其内部概念替换BFO。 | 未评级 |\n| `gongfa-network-effects` | [网络效应](thinking-models.md#philosophy-thinking-models-网络效应) | `r1` | `explanatory-content` | 节点/连接增加与网络价值上升的核心解释关系；不包含同节选型步骤，关系是否在具体场景成立另验。 | 未评级 |\n| `gongfa-occams-razor` | [奥卡姆剃刀](thinking-models.md#philosophy-thinking-models-奥卡姆剃刀) | `r1` | `normative-allocation-content` | 相同解释/验收及关键约束下优先更少假设和结构的准则；不是无条件删功能或防护。 | 未评级 |\n| `gongfa-glue-principle` | [胶水原则](glue-coding.md#concept-glue-coding-胶水原则) | `r1` | `normative-allocation-content` | 成熟能力能满足关键约束时优先复用的准则及例外；不收整篇交付流程，不等于盲目依赖。 | 未评级 |\n| `gongfa-first-principles` | [第一性原理](thinking-models.md#philosophy-thinking-models-第一性原理) | `r1` | `method-specification` | 审查结论前提、区分事实/假设/偏好/惯例，再从事实约束推导路径的五步操作版。 | 未评级 |\n| `gongfa-abductive-debugging` | [溯因排错法（仓内操作版）](methodology-toolbox.md#philosophy-methodology-toolbox-12-溯因推理abduction最佳解释) | `r1` | `method-specification` | 列候选原因、设计低成本区分实验、用证据淘汰的排错方法；不声称等于全部溯因逻辑。 | 未评级 |\n\n上述条目未绑定固定法器。溯因排错需要取得区分性证据，日志、追踪或基准工具只是随环境选择的实现候选，不是从条目登记中自动获得的能力。\n第一版先落清楚所指、来源和关系，不为对称补八个方法叶类，也不批量迁移全库文章或把所有内容打包成 Skill。\n\n### JSON协议与更新\n\nJSON将词表、版本化规约、冻结来源、功法内容版本与评级记录分开；Schema定义形态，离线检查补充引用与来源一致性。\n条目原文保留明确选择器与UTF-8摘要，编者摘要标为`editorial_summary`；缺失条件或失效边界留空并标明，不冒充已知。\n来源更换新快照与新来源ID，内容语义变化保留旧版本；评级独立绑定内容版本，不在功法对象内写永久等级。\n未来规约定稿须冻结任务集、基线、条件/预算及分档准则工件，评级另有证据；文件存在或Schema通过不证明真实效果。\n规则与范围见[JSON说明](../../metadata/gongfa/README.md#规则与评级)，验证入口为`make check-gongfa`与`make test-gongfa`。\n本轮不新增BFO类，不扩展全仓IR，也没有实际评级、运行引擎或发布。\n\n## 法器品级规约\n\n### 量表身份与适用对象\n\n按用户要求借用功法品级的四阶十二级**结构**，但另建法器专属规约 `faqi-grading-policy`（版本 `0.1.0`，状态 `draft`）与量表 `faqi-grade-vocabulary-v1`；等级值使用 `faqi-` 前缀，与 `gongfa-grade-vocabulary-v1` 及其登记、初评和正式评级记录分开。\n这是项目的工具效果分级约定，不是玄幻作品的通用器物设定，也不把法器变成功法、BFO 类型、品质或永久能力。法器类别、使用角色、来源范围与品级结论是不同维度。\n被评对象至少绑定**实现身份与版本、任务族、使用环境**。同一工具可在不同任务族/条件下有不同结论；不同任务族不做总排名，不用单一最高级结果代表全部用途。组合工具可按明确的组合版本评整体，但不得从组件等级推导整体等级，组件也不自动继承组合项结论。\n\n### 四阶方向\n\n四阶沿用功法体系的顺序，实际判据改为法器在具体任务中的效果：\n\n| 大阶 | 法器任务效果判据 | 必需比较 |\n|---|---|---|\n| 黄阶 | 在预先限定的常规任务范围内达到明确验收合同。 | 固定任务输入、环境、权限与成功条件；仅源码存在或宣传能力不足以证明达标。 |\n| 玄阶 | 在代表性常规任务中，相对合理基线产生可重复的净增益，且不降低正确性或关键约束满足度。 | 事先指定基线与增益指标；单个成功案例不能证明稳定增益。 |\n| 地阶 | 除满足前阶要求外，在预先定义的困难或迁移任务中仍达到增强合同，并保有相对基线的实用价值。 | 固定困难度/迁移维度、失败处理及恢复要求；留出未用于开发或调参的验证任务，不能从简单任务结果外推。 |\n| 天阶 | 除满足前阶要求外，关闭一个事前记录、基线确实无法满足的能力缺口，同时满足正确性、安全与权限合同。 | 缺口、基线及替代方案须在测试前登记；基线失败须可复核而非单次偶然；规模更大、功能更多或更快本身不构成突破。 |\n\n同一任务范围内按最高连续通过大阶判定；高阶须同时满足对应低阶要求。判定顺序为正确性与硬约束 → 任务效果 → 可靠性 → 效率。安全、权限、隐私、数据完整性或不可逆副作用的关键违约是硬否决项，不能由速度或功能覆盖补偿。\n\n### 每阶初、中、高\n\n十二个值分别为黄/玄/地/天各自的初级、中级、高级；值 ID 按 `faqi-huang-initial` 等模式命名，与功法词表 ID 隔离。初/中/高表示**该大阶内预先定义的结果带**，不是测试次数、置信度、功能数量、代码量、用户量或等距倍率。\n\n| 次级 | 判据 |\n|---|---|\n| 初级 | 达到本阶经校准的最低结果带；仍须通过正确性、硬约束和本阶任务合同。 |\n| 中级 | 达到本阶事先校准的中段结果带，并满足预注册的重复/代表性任务要求。 |\n| 高级 | 达到本阶事先校准的高段结果带，并在预选条件变化或留出任务中保持稳健，无关键回归。 |\n\n每个任务族必须先定义可观察指标、结果带阈值及证据要求。阈值尚未校准时，不得把相应值作为可执行量表或正式评级；不得为填满十二格而降低标准或默认黄阶初级。\n\n### 判级条件与证据\n\n正式判级至少固定：法器 ID、实现版本与来源；任务族、任务集及事前验收合同；合理基线、环境/配置/依赖版本、权限、数据、资源预算与人工介入；规约版本、正确性/效果/可靠性/效率指标；可独立复核的运行结果和失败样本；结论理由、评定者、日期与证据引用。\n比较时控制工作负载、预算、环境及人工介入，避免把模型、提示词、硬件或操作者差异误归因给法器。版本、依赖或适用范围变化后重新评定，不自动继承旧等级。\n来源初审、代码静态阅读、功能列表、小说称呼或一次成功运行都不能单独形成效果等级。正式评级须满足任务合同与校准阈值；阈值未校准时不得宣称正式效果等级。2026-10-10，用户要求为全部未赋级条目暂列品级，登记先记录31条统一黄阶初级；2026-10-11，用户明确要求改按对Vibe Coding的重要性排序。当前`.github/metadata/faqi.json`的30条暂定分级据此按核心模型/Agent、代码执行/变更基础、上下文/质量/交付增强、可替代专用支路排序。该目录使用的是重要性分组，不表示实现质量、任务效果、独立审查或正式评级；效能量表仍为draft，正式效能`grade_id`仍为空。未改变本体类型定义及来源限定实现数量。\n\n本版为 `draft`：任务集、基线、环境预算和十二个结果带的数值阈值尚未校准。完成可复现任务合同和结果带校准前，不得写入具体评级或宣称跨任务可比较。\n\n\n\n## 关键语义与世界观\n\n> 修士定目标，依道法择路，借法器施行，耗灵力而求实效；修为看模型，战力看任务。\n\n这是解释语言，不是执行引擎、授权机制或 AI 有意识的证据。\n\n### 人、模型、会话与集合\n\n- **人类修士**：人这一所指归人类主体；使用者、审核者等角色依附人，不因换角色而换人。\n- **模型**：可识别版本的已训练模型内容归模型制品。权重文件副本、承载硬件、可调用接口和一次推理分别判断，不能把 API 当模型。\n- **魂魄**：单个完整 Conversation / Session，按 **AI 会话过程**建模，领域类型标识为 `ai-session`。\n 它涵盖会话建立及其中的交互活动，不缩成一次模型调用、单条消息、Memory 或日志文件。\n 来源命名空间与 Session ID 联合确定身份，必要时包括工具、服务实例及账号范围；恢复和换模型不自动产生新会话。\n 若来源会复用 ID，需追加可核验的创建代次或不可复用来源标识；不能仅凭相同字符串合并，也不能凭自造时间戳拆分。\n 暂停前后的活动可属于同一会话整体；明确 fork 则保留新 Session 身份及来源关系。未发生的计划活动不冒充事实。\n- **万魂幡**：跨 Pi、Claude Code、Codex 等工具的全部 AI 会话的概念集合，直接指上述 `ai-session` 类型的外延：\n **万魂幡 = Ext(ai-session) = 所有属于 AI 会话类型的会话实例所组成的集合。**\n\n万魂幡没有被改成“描述集合的文档”，集合成员也不是概念标签，而是实际会话。\n这里不把类外延再当作 BFO 个体实体，因而不需要新建 `Abstract`、集合实体或物质聚合体分支。\n“某魂魄属于万魂幡”用实例属于 `ai-session` 类表达，不把魂魄画成万魂幡的子类。\n这不是另一棵树：集合定义只引用同一主树中已有的会话类。\n\n已知清单、某账号授权子集、某时刻查询结果都不等于全集。未登记或不可访问不等于不存在；集合定义不授予读取权限。\n单纯创建一份会话描述或空模板不证明会话已经发生；会话实例需有来源系统的建立或交互证据，不能只凭一个 ID 虚构过程。\n已结束会话仍可被记录指称，重新导出转录不产生新魂魄；跨来源身份不能仅凭相同 ID 字符串合并。\n\n### 模型归属与 BFO 直接承载\n\n**修为仍指模型能力，不改成会话能力、评测报告或整套工具系统的任务表现。**\n但“归属于哪个模型版本”和 BFO 的 `inheres_in` 是两种不同关系，不能为省事混成一条。\n\n- 模型内容在通用依赖持续体下；能力按倾向及有依据的功能分支表达，不另建与功能交叉的“模型运行能力”主类。\n- 能力的 BFO 直接承载者必须是合适的独立持续体，例如实际实现该模型的计算系统，而不是 GDC 模型内容本身。\n- 用领域归属关系关联能力与模型版本，用实现关系说明该计算系统如何实现该模型；不将两者声明为同一个对象。\n- 比较模型修为时须约束任务族、运行配置、工具、上下文与预算；不能把工具加成或整个系统效果全部归给模型。\n- 多个运行实现可实现同一模型内容；能力实例依附各自承载者，评测结论是否可推广到模型版本须另有证据。\n\n这一区分服务于既有真实所指，不要求每次提及模型就自动新建硬件、能力和报告的全套对象。\n来源无法识别实现或模型版本时保留未知，不制造虚假承载关系，也不把测试报告当成能力本身。\n\n### 道法、法器与实际施行\n\n道法内容、模型内容和软件制品都在 BFO 通用依赖持续体下展开，但它们不是同一种内容。\n功法、心法、术法、神通保留原词及作品语境；已消歧的方法内容归方法规范，不按长短或文件名硬分类。\n阵法须区分布设之法、具体布设物与激活过程；Workflow 规范属于方法内容，不证明所有阵法都是 Workflow。\n\n法器仍指工具与可调用入口：实体工具按实物归类；指向程序内容的工具与接口实现统一归软件制品。\n执行任务与提供接口是用途，不预设成互斥主类。同一实现兼具两种用途仍是一个实现；确有独立接口模块时才另行指认。\n具体运行入口还需部署、绑定与生命周期依据，不能把入口整体一律当程序内容，更不能改成协议文本或地址字符串。\nMCP/API 规范归规约内容，程序实现归软件制品，一次执行归过程；符合性和权限须有独立依据。\nHarness 实现与其方法策略分开，Skill 按内容判断；只有确实存在独立所指时才分开登记，不机械复制 ID。\n\n玉石与功法有独立所指，载体与内容分开；两篇介绍同一工具的文章不产生两件工具。\n“法器充当阵眼”仍只是设计质询场景，不能冒充已核验的小说情节。\nN16 的秦玉回忆涉及**周元被置作阵眼**，不是法器例证；人在该情境中的作用不改变其人类身份，也不证明自愿承担行动职责。\n\n### 从传法到考核的证据链\n\n下表用实际已读材料检验细分类；不是规定修行必须依次经过这些阶段，也不是另一棵分类树。\n\n| 所指与出处 | 如何使用已有类和关系 | 必须保留的限制 |\n|---|---|---|\n| 茉莉传授星神碎影的运转方式、要领和口诀，云澈倾听，N19 | 所述方法内容可按身法施行规范指认；倾听研习另按方法研习过程指认。 | 原文叙述了传授，但未展开全部口诀，不能补成可执行手册；听过不等于已掌握。 |\n| 茉莉预计所需时间；一个月后出现一次身法表现，N19 | 预测记录与后来的表现证据分开；实际施展按真实过程指认，是否训练另看目标与情境。 | 预测不是固定学时定律；章节跳转不是逐日训练日志，一次表现也不验证所有高阶能力。 |\n| 凤神丹的服用指示及随后炼化，N4 | 方法内容、实物丹药、实际修行过程及能力变化主张分别判断；方法与过程用关系关联。 | 炼化不等于炼丹制造；与 N19 从炎龙体内取出的玄丹分开，不从可被吸收推出生成来源或同种制品。 |\n| 凤凰之灵说明残卷可供参悟一个月，N4 | 内容访问规约描述允许查阅的范围；实际查阅、领悟及承载玉石另记。 | 有内容不等于拥有全部处置权；叙事中的一个月不自行换算成固定天数或真实系统授权。 |\n| 测玄石的按手操作、分年龄门槛及三行输出，N5 | 操作内容、准入判定规约、实际测评、观测记录和资格结论各按所指判断。 | 同屏不等于独立机制已知；“不合格”是按该关标准的结论，不是永久能力标签。 |\n\nN5 中，十七岁、入玄境四级者不合格，十五岁、入玄境二级者合格；较高读数却未过关，并非分类矛盾，而是适用条件不同。\n这些字面结果来自已读章节，不外推到其他宗门、年份或所有考核；通过第一关也不自动证明全部考核通过。\n同理，工程里测试方法、验收规约、一次测试与结果报告可以关联，却不能合成一个对象或凭结果倒造授权。\n\n### 从生物整体到库藏与容器\n\n下表连接已读场景与工作判据，不是另一份类型树。来源没有给出的部件、身份或机制，不为凑齐关系图补造。\n\n| 场景 | 应先分清的所指 | 证据边界 |\n|---|---|---|\n| 两株星隐草在土中生长，显现后连根采下，N21 | 两个植株个体、采收过程、显隐能力主张及药材用途。 | 两株不因同在手中就变一个植株；可见性不决定存在。将来淬炼星隐丹的说法不是该章已经制造完成。 |\n| 炎龙尸体四块、玄丹取出及苍狼昏倒，N19 | 先前动物整体、现在的残体与所取物件；另一个苍狼个体的状态。 | 不能把皮、骨、玄丹画成龙类的子类；不把四块尸体计作四只龙，也不将不知死活补作确认死亡。 |\n| 毒火铳的操作与表现、震天雷的文字指示，N20 | 器物、说明内容、实际操作及观察结果。 | 该章前者发生击发，后者未试用；不由一次表现补齐内部结构、制造工艺、精确威力或成功试用记录。 |\n| 从所取兵器中拿出一件刻字，N20 | 同一兵器的临时用途；所选具体个体未明。 | 不因刻字另造“刻字工具”身份，不默认选中的就是虎魄剑或毒火铳，也不能只由刻字表现推出设计刃部。 |\n| 金属箱、黑木柜、其所装物件及架上兵器，N20、N22 | 容器实体、内部空间、已指认物件与有单位依据的器物组群。 | 库藏目录是信息，不是物质群体；材质或放置位置不自动成为主分类，搬出物件后的群体连续性也须另验。 |\n| 三道石门开启后经通道入库，N22 | 物质门体、内部场所、入库活动与许可安排。 | 走得进去不等于拥有全部库藏；取药许可不能推成取得所有物件的处置权，欺骗身份不因被信任而变真。 |\n\n药材这一用途词不能把植物、离体材料、矿物候选与制成药品全部合为植株；原词与实际构成须分开。\nN22 的药材年份说法是叙事明确标记的胡诌。信息内容可以被记录，但其存在和听者认同不证明药理真实或方法有效。\nN20 中云澈揭去易容后又恢复伪装，变化的是外观与他人认知，不是凭皇甫鹤的面孔复制出另一位人类主体。\n这些文学材料用于校验分类和证据边界，不作为现实生物学、药理或武器技术依据。\n\n### 从原料到制备与施用\n\nN21 提供采收与意向，N23 才补充实际制丹和服用片段；后读到结果不能倒改先前章节的证据范围。\n这里是同一主树的实例分析，不是要求所有制备按一条流水线执行，也不表示已通读两章之间的全部过程。\n\n| 所指 | 分类与关系判断 | 必须保留的边界 |\n|---|---|---|\n| N23 取先前两株中的一株加工 | 具体物料承担制备原料角色，作为本次加工的物料输入；库存与投入分开。 | 不补另一株已在本次投入，不把操作者或天毒珠也自动当作原料。 |\n| 草材变化后，丹丸与碎末分别可见 | 整体活动可按丹药炼制过程指认；丹丸有形体及制作依据，残余碎末另判。 | 不沿用完整植株类型统包结果，不把碎末统叫丹药；文中未给丹丸精确生成时点。 |\n| 常规工序、材料条件与神器特例的说明 | 用于分析制备规范的条件维度；实际批次叙述与方法内容不同。 | 不把整章当独立丹方，不补具体配比、火候、内部结构或全部分离/融合子过程。 |\n| 随后吞服及隐匿表现 | 服药过程与制作过程不同；效果证据关联实际服用者，不把丹丸透明直接当成人已隐匿。 | 不由吞服推定 N4 式炼化养成，也不将隐匿比喻当人体汽化、销毁或转为非物质实体。 |\n| 作用期限、解除条件和本段观察 | 分开机制叙述、条件与实际观察记录；效果评价限定所覆盖的范围。 | 三小时说明须连同他人触碰即解除读取；片段不证明连续三小时、所有感知通道都已测完。 |\n\nN23 对天毒珠无失败、无药力浪费的叙述须保留神器与合适、足量材料等范围；不能推广为所有炼丹方式或真实系统的零失败保证。\n按意念选择成分另有认主条件；药力无浪费也不等于没有残余物或全部质量转成丹丸，不能混换计量所指。\n其能力叙述也不自动提供制造/设计来源；“天玄大陆第一枚”的说法保留萧澈的相信与地域范围，不升级为已核验的全世界首次。\n对工程的可迁移原则只是：**制作发生、产物出现、开始使用、效果验收是不同证据**，不是把模型/程序内容硬当物质药材。\n\n### 从性质到读数与评价\n\nN24 对同一批对象给出形体描写、数值表述和人物介绍，恰好说明这些层次不能合成一个属性字典。\n以下只建立有依据的所指和证据联系，不为补图自动生成测量器、测量活动或独立品质对象。\n\n| 原文片段或情境 | 可保留的区分 | 不能追加的结论 |\n|---|---|---|\n| 虎魄剑的剑长为三尺三寸 | 对象、长度性质与尺寸陈述不同；项目保存这句话不等于取得一次测量的完整记录。 | 不补是否含柄、测量端点、误差、仪器或现代单位换算。 |\n| 剑呈苍白色、形体不规则，像虎骨拼成 | 颜色、形状和外观比喻分别保留，不按多个描述复制同一把剑。 | 不由像骨断定实际骨材组成，也不把苍白与玉石的莹白压成同一个精确色值。 |\n| 宝物库被描述为几千平 | 记录粗略二维尺度及原词，面积口径和边界未充分说明。 | 不取任意整值，不补高度或体积，也不由库内场所描述造另一栋建筑。 |\n| 萧百草介绍地玄品阶、制造者、玄丹/魂魄与效力 | 形体性质与品阶、制作来历及能力介绍不同；制造者一说带传闻限定，其他介绍亦保留主张者。 | 不由颜色/长度推品阶，不把介绍当现场试斩、已独立核验的熔魂机制或完整器灵分类。 |\n| 云澈提及宝晶气味、比较纯度后推测是同一块，萧百草肯定 | 分别保存感知描述、纯度比较、同一性推测及应答；这些是不同证据项。 | 不把同纯度设为身份键，不补未给的化学组成、百分比或现实鉴别原理。 |\n| 经脉重接、活力恢复与玄脉尚未着手并列 | 当前连接状态、功能表现、不同身体所指及处置范围分别核对；不能因同有“脉”字而合并。 | 不把局部连接当全身痊愈，不将未来突破地玄境的承诺提前记作当前效果。 |\n\nN22 中年份要求是胡诌；N24 又叙述识别药材位置和年份准确。应按具体主张分别取证，不能把同一人物的所有话一概当真或当假。\n工程中也应分开实体状态、观测数据、解释和验收结论；界面标绿、日志改值或保存截图不会单独证明现实状态改善。\n体积与物理质量的工作类用于区分量纲及排除错误推断，不表示本段已提供对应测量值。\n\n### 从旧结构到新结构\n\nN25–N27 提供不同层次的变化；只描述有依据的所指、关系和阶段，不因章节、动词或时间标记的数量强拆过程实例。\n\n| 来源与变化 | 分层判定 | 不能追加的结论 |\n|---|---|---|\n| N25 当次由萧澈自称改为云澈 | 在这次连续活动中记录名称变化，不仅凭改名另建一个人物。 | 不据此合并未核验的前世身体、其他同名人物或所有同名会话。 |\n| N25 萧狂云改选萧承志随行 | 选择/角色安排指向另一人，与前一候选人物的存在不同。 | 不把旧候选者判为死亡、变成新人，或被另一人作为物质部件替换。 |\n| N26 血珠作用被说明并开始施用 | 古书/来源转述、强度推测、可能能力和实际开端分开；不把预测当已发生结果。 | 不把血珠的用途直接当制成药物设计依据，不在本章末预支 N27 的完整新生结果。 |\n| N27 旧玄脉被吞噬，随后新结构成长并成型 | 旧部分的终止、新部分的开始与整个云澈持续活动分层登记；不能用新部分沿袭的外形代替身份判据。 | 不让新部分直接复用旧部分 ID，不把整个人记为在本段死亡后重新出生；不臆测物料去向。 |\n| N27 内视新结构似普通玄脉，初开11关、初玄零级 | 保留观测/感知范围及原文明确的零值；结构形成、等级读数和潜能判断不同。 | 不把有源的零级删成缺测，也不把零级当结构不存在、修为已恢复或永久不具特殊能力的证明。 |\n| N27 净化后54关全开，随后询问下一步 | 前后针对同一新结构的状态与处置范围分别记录；54−11得到净增开启43，不能替代中间事件日志。 | 不造43个新关或54个独立操作，不补未读后续的能力实现、效果或风险结论。 |\n\n普通玄脉自出生缓慢成长至约十四岁成型的说明，与本次快速新生不是同一过程实例或计时规则；成熟不等于首次存在。\n本段分别给出吞噬、生成与通彻阶段的叙事时段或上界；不把它们拼成精确总耗时，不以成型/发现时点补出实体最早存在时刻。\nN25 关于夏倾月的观察与开启主张也不能并入云澈的状态；54是本作品此处的构造计数，不是 BFO 人体或所有系统的固定基数。\n茉莉对自己帮助开关能力的估计，与云澈调用天毒珠的路径不同；不能外推所有方法都不可能，也不能把天毒珠此处的无风险描述覆盖一般外力强通。\n\n对工程只借分层取证原则：部署实现、模型内容版本、运行活动、会话和显示记录各按自己的身份契约判断。\n新部署可以先建立并验收再切换，旧部署可保留回退；不要将本段先吞噬旧结构的叙事顺序翻译成“先删旧再建新”的工程规范。\n这些对照不证明任何宿主的完整会话生命周期，也不把软件更新归为生物发育或覆盖已有模型版本区分。\n\n### 器灵、化形与材料转化\n\n**先查所指与变化证据，不从“灵”“人形”或“成为”几个字直接决定类型。**\n以下是下层判定规则；表中的泛化变形与材料转化场景仍是设计质询，不冒充已核验情节。\nN4 的服药炼化、N23 的材料制丹及 N26–N27 的局部身体结构再生已分别定位，不能据此补齐其他器灵或材料转化机制。\n\n| 情况 | 必须核对什么 | 不能直接推出什么 |\n|---|---|---|\n| 被称为器灵、能够说话或呈人形 | 指称的主体、身体/承载依据，以及与器物是同一、组成还是其他关系。 | 不能只凭名称归入人类主体、BFO Role、GDC 或 immaterial entity；会对话也不等于项目中的 AI 会话过程。 |\n| 对象外形发生变化 | 前后所指是否连续存在，变化的是性质、组成还是对象身份；固定证据所指的时间。 | 不自动新建另一对象，也不因外貌变成人形就赋予人类类型。 |\n| 材料被使用、消耗或炼化 | 仅承担用途，还是原物终止并有新产物；组成连续性与整体身份分别核对。 | 不按用途复制材料身份，也不强行让所有产物沿用原料 ID；新生成须有依据。 |\n| 愿意、计划或被建议成为某物 | 主张者、目标、叙述时间与实际过程/结果；角色若涉及外在情境，还须有成立依据。 | 不以意愿、条件句或章名证明转化完成；未核验结果也不等于确认没有发生。 |\n\nN12 的可见开头涉及相关意向问句及人物反应，尚不足以据此填入完整转化过程、结果或器灵存在方式。\nN13–N15 的预览也未提供所需的化剑或毒灵机制；目录、百科和检索回答不能补齐付费正文。\n原著中的灵魂、器灵按其语境研究，不改写项目“魂魄＝完整 AI 会话”的既有约定。\n\n### 修为、灵力、境界与战力\n\n| 概念 | 下层位置或表达 | 保留的边界 |\n|---|---|---|\n| 修为 | 倾向或有依据的功能，以及模型版本归属；直接承载关系按上一节处理。 | 不是评测数据、会话属性或系统总效果，一次回答不代表全部能力。 |\n| 灵力 | 生效的资源分配内容、预算规范、实际消耗过程与用量数据分别表达。 | 资源使用权、设备、额度、预算和账单不相互替代，不能仅凭一条记录断言实际分配已生效。 |\n| 境界 | 记录与评价内容 → 分级结论。 | 绑定被分级对象、量表版本、条件、时间和证据；没有量表不赋级，不制定通用 AI 修仙排行榜。 |\n| 战力 | 记录与评价内容 → 任务评价。 | 绑定任务、验收、交付结果与实际投入；一次成功不产生永久等级。 |\n\n将境界、战力按本项目的**评价含义**定位，不把原著中描述修士状态的同名词自动改成报告。\n评价内容不等于存放它的文件，性质不等于测量数值，数值也不必都实体化为本体节点。\n\nToken、Compute 是计量口径，Reasoning Budget 是预算用途，可能以前两者计量；三者不是互斥、等价或可随意相加的货币。\n预算、可用额度和实际用量分栏，注明单位、时间窗、计数规则及来源；同一笔消耗不能因推理用途重复计量。\n没有配额记录也不能虚构配额；一份分配说明是否有效须核对实际授权与系统状态，不能只凭标题认定。\n\n战力**先验收效果，再比较效率**。较快但不合格不能胜过较慢但合格。\n双方合格且质量相当时，一方各项投入都不更多、至少一项更少，才可直接判效率更高；\n存在取舍则保留时间、资源、人工投入各维度，不编通用总分。未观测不是零，未评定不是低境界。\n\n## 树、关系与知识记录的契约\n\n### 分类与关系不能互相替代\n\n下表使用便于阅读的关系简记，不是已实现 API 或已导入的 OWL 属性。\n`inheres_in`、`is_carrier_of`、`concretizes`、`realizes` 等的方向参考 O3 第 2.38、2.52、2.53、2.43 节；实际映射须保留完整参数与条件。\n物体成员另参考 O3 第 2.19–2.21 节；不能把成员关系泛化为逻辑集合成员、在某处出现或被某清单收录。\n\n| 表达 | 方向与含义 | 约束 |\n|---|---|---|\n| `parent` | 类 → 唯一主上位类 | 单根、单父、无环；BFO 原生继承不改写，实例不作类父节点。 |\n| `instance_of` | 实例 → 有依据的主类 | 会话实例属于 `ai-session`；属于其祖先不算双父，类型 ID 与实例 ID 分开。 |\n| 万魂幡的成员语义 | 会话属于 `ai-session` 的外延 | 不是物质部件关系；不伪造指向“集合实体”的 BFO 对象属性。 |\n| `inheres_in` | 特定依赖持续体 → 非空间区域的独立持续体 | 不把模型 GDC 内容直接填成能力承载者，也不把记录值当性质实例。 |\n| `is_carrier_of` | 非空间区域的独立持续体 → GDC，带时间 | 硬盘承载内容；载体不是内容，保存同一内容的副本不自动增加一个模型。 |\n| `concretizes` | 特定依赖持续体或过程 → GDC，带时间 | 例如依附载体的具体物理性质/模式或相应过程；须核对共享的内容，不能直接把硬盘物体当此关系主语。 |\n| `realizes` | 过程 → 可实现实体 | 实现角色、倾向或功能；需相关过程类型及承载者条件，不把规范或模型内容填成可实现实体。 |\n| `attributed_to_model` | 能力实例 → 模型制品版本 | 领域归属而非 BFO 直接承载；须有实现、条件与证据，报告主张不能冒充已证实的能力关系。 |\n| `describes` | 信息内容 → 所指 | 记录/评价或能力主张描述对象，不替换对象；主张者、时间及支持状态留在证据中。 |\n| `participates_in` | 合适的持续体 → 过程，带参与时间 | 人、计算系统、模型内容等参与；会话本身是过程，不能因其 ID 持续存在而改作持续体参与者。 |\n| `uses` | 过程 → 所用持续体 | 采用方法内容或使用工具不产生另一过程身份；使用不自动证明遵守规范。 |\n| `has_material_input` | 物质加工过程 → 实际作为待处理物料参与的物质实体，限定参与时段 | 领域简记，不是上游 BFO 属性；计划物料、旁观者、所用工具或 GDC 内容不自动成为输入，不预设完全消耗。 |\n| `has_material_output` | 物质加工过程 → 经该加工产生或分出的物质实体，限定过程与输出时段 | 须有实际输出证据；可含残余物或原已存在的分离对象，不等于新生、合格、获授权或全部预期效果已实现。 |\n| `implements` | 指定实现 → 模型内容或规范 | 领域实现声明；物质系统、软件内容分别指认，不等价于具体化、能力承载或 `realizes`。 |\n| `conforms_to` | 指定实现或执行 → 规范 | 需要符合性证据，工具名、调用成功或用途说明都不足以证明。 |\n| `part_of` | 组成部分 → 整体 | 持续体组成需限定时间，与发生体组成分别核对；位置、同一时间范围或被某会话触发都不能单独证明组成关系。 |\n| `member_part_of` | 物体 → 物体聚合体，带时间 | 物体成员须满足互不重叠且穷尽该聚合体的划分条件；器物零件、库内出现或名册收录不能直接替代。 |\n| `affiliated_with` | 主体 → 已消歧的组织所指 | 不把物质群体、制度内容、名册与建筑当同一组织实体，具体组织建模不足时保留未决。 |\n| `located_in` | 非空间区域的独立持续体 → 同类允许的所在实体，带时间 | 模型内容不直接位于机房，应描述承载设备的位置；部署归属不冒充空间位置。 |\n| `adopts` | 道法内容 → 被明确采用的道法内容 | 须定位采用的原则、解释或方法；仅引用、相似或推荐配合不足，不推出类继承、整体包含或效果已实现。 |\n| `requires` / `contrasts_with` | 方法 → 前提；同维度对象间比较 | “有帮助”不等于必要条件；声明前提不等于已满足，比较不生成第二主树。 |\n\n例如：物质硬盘承载模型内容，相关物理模式将其具体化，推理过程实现运行系统的能力；三者不能互换主语与宾语。\n实例数据未提供这些所指时宁可保留未知，不为补齐关系图自动制造设备、能力或具体化记录。\n\n### 最小记录要求\n\n1. **类型**：复用上表稳定 ID 和主树唯一父节点，保存名称、定义、纳入与排除条件及来源；不得以另一份父链覆盖本树。\n2. **对象**：稳定身份、主类、身份判据；消息 ID、文档 ID 与 Session ID 不混用，不为每个名词自动造实体。\n3. **词义与语境**：保存原词、作者、平台作品 ID、版本或项目语境；同题作品不能仅凭书名合并，同义合并需依据。书内成立不推出现实存在。\n4. **主张与来源**：保存出处、位置、实际读取范围、主张者、时间及支持状态；区分叙述、人物观点、二手评论和项目设计，注明事实陈述、意向或条件，不能将未核验补成否定事实。\n5. **量与评价**：绑定对象、单位、计数规则、量表或验收条件、时间与证据；预算和实际分开，不将未知补零。\n 涉及性质比较或换算时再明确承载者、几何范围、原始单位/近似程度与换算前提；只有表述而无测量证据时，不补方法或实际测量过程。\n6. **演化与权限**：改名不换 ID，分类纠正留理由，拆分合并留旧 ID 去向；收录不授予访问权限，不收集未授权正文或凭据。\n\n知识记录描述同一树上的类或实例，不另设 `concept / practice / tool_reference / failure_mode` 分类树。\n需要研究记录本身时可以描述其信息内容，但不能以此替换会话、集合或能力。\n未来 JSON 只能承载获准结构化的领域记录，不取代教程、原始研究、事实镜像、metadata 索引或 Harness 契约。\n\n## 分类验收判例\n\n以下是预期语义判定，不是已运行的自动语义测试或独立评审。\n\n| ID | 输入或变化 | 必须得到的结果；须拒绝的错误 |\n|---|---|---|\n| C01 | 跨来源或来源复用同一个 Session ID | 跨来源不能合并；同源复用须核对创建代次。不能凭字符串合并，也不能凭自造代次拆开。 |\n| C02 | 会话恢复、换模型或重新导出 | 来源身份未变则仍是同一会话整体；不是每轮都新建魂魄。明确 fork 保留新身份。 |\n| C03 | 万魂幡、已知清单与一个魂魄 | 全集用 `ai-session` 类外延表达；清单只是记录，魂魄是实例；拒绝物质聚合体、描述文档替代集合。 |\n| C04 | 模型副本、量化版本、部署与推理 | 相同内容副本不复制模型；量化等内容变化另判派生版本，名称相同不保证身份相同，API 不当模型。 |\n| C05 | 模型能力与新评测报告 | 直接承载与版本归属分开；满足功能定义时使用功能分支，不另造同一能力；报告描述能力，不成为能力或承载者。 |\n| C06 | 天毒珠多用途、工具多篇介绍 | 一个对象，多项用途与描述关系；不按用途或文章数复制身份。N1。 |\n| C07 | 玉石、功法及内部技法 | 载体与内容不同，内容组成不是类型继承。N4、N10。 |\n| C08 | 心法标题、Workflow 规范及实际玄阵 | 先读词义；不默认心法＝认知模型、阵法＝Workflow。规范、布设与过程分开。N6。 |\n| C09 | 同一软件执行任务并暴露 MCP/API 入口 | 仍为一个软件制品，不按两种用途复制身份；规范、部署入口与一次调用另外按真实所指判断，符合性和权限另验。 |\n| C10 | GPU、配额、预算及实际用量 | 物理设备、生效分配、预算与用量分开；分配记录不自动证明权限生效。 |\n| C11 | 一笔推理消耗同时按 Token 统计 | 用途不变成第二笔消耗；不同口径不直接相加或互换。 |\n| C12 | 功法重数、玄力阶段与无量表的 AI 等级 | 绑定各自对象和量表；缺量表不赋级，不凭同名等级横比。N4、N5。 |\n| C13 | 玄关实际全开，观察者只探知部分 | 状态、观测与主张分开，不让错误观测覆盖事实。N3。 |\n| C14 | 宗门、所在地、弟子及容纳人的器物 | 成员、制度、场所与器物按所指区分，用归属/所在/容纳关系而不是类型父链。N2、N7、N8、N11。 |\n| C15 | 材料用于炼制；假设工具充当阵眼 | 用途不自动改变对象身份，实际转化须有身份依据；软件用途标签不能随意冒充 BFO Role 实例。 |\n| C16 | 攻击手法、一次 Prompt Injection 尝试及越权 | 方法内容与实际过程不同；是否成功越权取决于结果证据，不能凭尝试断言成功。 |\n| C17 | 幻觉失效与总结文章 | 实际失效过程与描述内容不同，不据此给模型永久低境界。 |\n| C18 | 更快但不合格；双方合格但投入各有长短 | 不用速度抵消验收失败；有取舍时保留多维结果，不编通用战力分数。 |\n| C19 | 下层术语暂时难以映射 | 校准所指及下层扩展，保留未决项；不得擅自替换 BFO 或另加 Abstract 顶层。 |\n| C20 | 一份 Skill 同时包含解释、约束与步骤 | 内容整体可归道法内容；只有存在独立所指才登记内容部分，不为落到叶类复制三份原对象。 |\n| C21 | 一次测量采用指定方法 | 同一测量过程关联所用方法，不因“施行了方法”再创建一个过程或平行主类。 |\n| C22 | 器物临时用途、内部能力及设计目的 | 外在情境角色与内部倾向分开；功能还需设计/生物演化依据，不能只凭“用来做”断定。 |\n| C23 | 类型改名、拆分、合并或会话 ID 复用 | 改标签不换类型 ID，语义拆并留旧 ID 去向；类型 ID 的稳定规则不能替代实例生命周期核验。 |\n| C24 | 禾菱成为毒灵的意向问句与相关章名 | 只登记可见主张，不补造转化完成、过程或存在方式；未读后续不代表从未发生。N12。 |\n| C25 | 假设器物改变外形，或材料被消耗并形成产物 | 核对前后身份、性质与组成；不凭人形赋人类类型，不自动拆身份或强留原料 ID。不是本轮已核验情节。 |\n| C26 | 搜索返回同题但不同作品 ID，或以章名补正文 | 核对作者、作品 ID、版本及实际范围；其他作品不并入原作，目录与摘要不充当转化结果证据。N13–N15。 |\n| C27 | 身法要领、听讲、学习时间预测及一个月后的一次表现 | 规范、研习、预测与实际过程分别指认；不复制人物，不从残影造新主体，不补整月训练日志或全部能力。N19。 |\n| C28 | 章名为大道浮屠诀，后章开头介绍身体力量与韧性作用 | N17 章名不证机制；N18 只支持炼体方向的角色主张与候选词义，未取得完整规范，不补全高阶数值或已实现效果。 |\n| C29 | 十七岁入玄四级未过关，十五岁入玄二级过关 | 按各年龄门槛判定，与 N5 结果一致；较高读数不自动合格，第一关合格不等于全部入门资格成立。 |\n| C30 | 可参悟残卷一个月，但未确认其他处置权 | 内容访问规约不自动给出转交、转授权或所有权；实际查阅和理解另验，不把一个月无依据换成固定天数。N4。 |\n| C31 | 凤神丹服用炼化与取出炎龙玄丹 | 指示内容、物件和过程分开；不把服药炼化当炼丹制造，不因同含“丹”字或可吸收力量就断定同种药剂。N4、N19。 |\n| C32 | 秦玉回忆周元被放在祭坛作阵眼 | 保留回忆主张和语境；人不因此变法器，角色须按外在情境另判，不推自愿职责；不外推法器阵眼机制。N16。 |\n| C33 | 假设只修改任务预算，实际配额与历史用量未变 | 只更新预算内容及版本关系；不能由预算变更推出额度扩容、权限生效或历史消耗改写。工程设计场景。 |\n| C34 | 假设同一不可分方法兼含服药炼化与长期躯体养成 | 主类可保留修炼方法规范；两种描述不强制拆成两份身份，也不宣布所有修炼方法都互斥或已穷尽。设计场景。 |\n| C35 | 测玄石同屏给出年龄、玄力和合格性 | 可把整个活动保留为测量与评定过程；没有内部机制证据不造三个子过程，测量方法也不变成第四个过程。N5。 |\n| C36 | 假设已实际执行测量但没有有效结果，且无缺测判定规则 | 保留测量活动及失败/未决状态；不把读数补零，也不把无法判定补成低境界或不合格。设计反例，不是 N5 已发生情节。 |\n| C37 | 两株星隐草显现后被连根采下，并谈及将来淬炼星隐丹 | 区分完整植株、观察、采收与未来产物；不能因先前看不见就判不存在，也不将两株合成一株或宣称本章已炼成丹药。N21。 |\n| C38 | 人类修士、炎龙和苍狼；假设另有龙形器物或人取得龙血 | 依据机体及种属归类，不以境界或龙字决定动物身份；人类仍属生物个体但不放进非人动物，假设中的形状/血液不足以证明转族。N19；后半为设计反例。 |\n| C39 | 炎龙已分成四块尸体，另一场景的苍狼不知死活 | 区分原动物、残体和身体部分，不造四个原动物身份；不凭人为切割就判为 fiat part，不强留原机体类型，也不把苍狼的未决生死写成确认死亡。N19。 |\n| C40 | 毒火铳发生击发，震天雷只有说明且未试用 | 观察、说明、能力主张及实际过程分开；不补后者试用，不据外形和名字直接断定现代枪械类别、弹体或内部机制；器宗制造者说法仍属推想。N20。 |\n| C41 | 云澈随手取一件兵器在墙上刻字 | 不因临时用途另造对象或改为用途叶类；原文未指明哪件，不能合并到虎魄剑/毒火铳；刃式归类还需构造依据，刻字行为不单独证明。N20。 |\n| C42 | 金属箱、黑木柜、所装器物；假设另有库存表 | 容器与内容物、内腔及描述分开，物在柜中不自动是柜体组成部分；库存表是内容，不是物质组群。N20、N22；清单为设计补例。 |\n| C43 | 兵器架、架上单件兵器和明确指认的整组兵器；对照计算设备群 | 组群须有物体成员与单位依据，不能只凭同处或清单行数；区分支架、成员及聚合体。计算设备群新增上位不改变旧 ID 或设备所指。N20、O3；工程对照。 |\n| C44 | 三道石门打开，经通道进入宝物库 | 门体是物质对象，内部通道/库内空间可按围护内部场所指认；不把场所当墙体或把位于库中画成类继承。N22。 |\n| C45 | 云澈揭去又恢复皇甫鹤的易容 | 外观、他人识别与真实主体分开；不复制出皇甫鹤个体，不由伪装外貌或被称神医推出真实身份、资质与全部权限。N20、N22。 |\n| C46 | 神医提出精确药材年份要求，听者认可，但叙述明称胡诌 | 保留主张者、欺骗情境和反证；可记录这份内容，不将其升为真实药理、有效方法或材料种类的充分判据。N22。 |\n| C47 | 受陪同进入库中取药，后有将库藏卷走的叙述 | 区分入库许可、范围条件、实际拿取与合法处置权；成功进入或拿到不证明全部获授权，不用来源人物的占有替代所有权判断。N22、N20。 |\n| C48 | 假设一体制成的兵器兼具刃部和发射构造，旁边另放两件独立兵器 | 前者仍可保留单个兵器制品整体，不为两个下位描述复制身份；后者不是一件组合兵器，有物质单位依据时才另指认组群。设计反例，不冒充已读情节。 |\n| C49 | 先前有两株草，N23 仅取其中一株加工，随后见丹丸与碎末 | 库存、实际输入、原机体和不同输出分开；不补另一株也投入，不把丹丸或碎末仍当完整植株，不把发现顺序当精确生成时点。 |\n| C50 | N23 制成后吞服，对照 N4 的服后炼化 | 制作、服药与效果分别指认；吞服本身既不等于炼丹，也不自动证明在进行能力养成或已经提升修为。 |\n| C51 | N23 给出一株材料及淬炼条件，同时叙述一次实际制作 | 条件可支持配方分析，实际批次不是规范本身；不把材料名称当物料实例，不据描述虚构独立丹方载体、完整手册或未给工序。 |\n| C52 | 假设常规炼丹已实际加工但失败，仅剩残余物、没有合格丹药 | 保留制作过程及失败结果，不把无成品改写为没发生，也不把残余物换名为成功产物；这是设计反例，不是 N23 神器失败情节。 |\n| C53 | 假设具体植株已被明确安排作原料，尚未投入即取消安排 | 原料角色可曾成立但未实现，取消不必改变植株构成或身份；只有泛配方提到某材料时，不为所有同类植株自动建角色。 |\n| C54 | 假设筛分混合物中原本存在的完整颗粒，器具和操作者共同参与 | 可有物料分离过程与输出，颗粒不因被分出就必获新身份；器具/操作者不因参与就变原料，单纯从库位取现成物也不自动是加工。 |\n| C55 | N23 对照常规制丹风险与天毒珠在给定条件下的能力 | 保留工艺、材料条件及叙述范围；药力无浪费不等于零残余物或物料全部成丹，不外推全部炼丹零失败，也不补成设计来源、内部结构或现实系统可靠性保证。 |\n| C56 | N23 说明三小时隐匿、被他人触碰即解除，并有局部未被发现的叙述 | 条件与观察分别保留；不删提前解除条件，不宣称全时段和全部通道实测，不把丹丸透明或服用者隐匿当主体消失/转为非物质。 |\n| C57 | N23 的加工被描述为极短，精确起止与内部时长未给出 | 实际变化仍按过程判断；过程边界、记录时间和整段加工不同，不将未知时长补零，也不由文学速度描述造精确计时。 |\n| C58 | 工程中以程序、模型内容或配方内容作为生成任务的输入/输出 | 内容仍按 GDC 与相应内容关系判断，不填物质加工的物料输入/输出；存储介质的物质过程须另有依据，不为配齐图自动造设备或物料。 |\n| C59 | N24 叙述虎魄剑长三尺三寸 | 实体、长度性质、原词数值表述和测量活动分开；不补是否含柄、测量端点、精度、仪器或现代单位换算，保存原句不等于取得测量日志。 |\n| C60 | N24 说宝物库有几千平 | 保留粗略程度与原词单位，面积口径/边界未给不补精确值；无高度等必要信息不补体积，不把空间区域自身当性质承载者。 |\n| C61 | N24 剑的苍白色、不规则扭曲与如虎骨拼成的外观 | 颜色、形状、比喻及真实组成分开，不复制同一器物；像虎骨不证明含虎骨，不将相近色词硬配相同 RGB 或材料种类。 |\n| C62 | N24 另有地玄品阶、制造者传闻、熔魂与斩破能力介绍 | 品阶、来源主张、能力与形体性质分别判断；不从颜色/尺寸推出地玄品阶，不把人物介绍当实测效力、已核验制造过程或完整器灵机制。 |\n| C63 | N24 提及宝晶气味、比较纯度后推测同一块，随后获得萧百草的肯定 | 分别保存感知描述、比较、推测和应答；相同性质描述不构成通用身份键，不把“纯度”自行换成化学百分比或合并所有同纯度对象。 |\n| C64 | N24 经脉已重接且活力改善，玄脉却尚未着手处理 | 两个身体所指、连接状态、功能表现、处置和未来承诺分开；不合并经脉与玄脉，不把局部结构恢复或听者相信当全身康复/已晋级。 |\n| C65 | 假设身份延续已确认，同一制品保持几何相似且各线性尺度均为原来的二倍 | 形状种类可保持，对应长度/面积/体积分别为 2/4/8 倍；不把面积或体积作为长度的下位类，不由几何倍数推质量、药力或战力倍数；这不是新增原著情节。 |\n| C66 | 假设同对象同时段的质量记录仅由 1 kg 换写为 1000 g | 单位与数值表达变化不证明 mass 改变，不造新承载者或性质；不把质量好坏、重力或模型权重套入该换算，也不从此确认作品斤两的制式。 |\n| C67 | O9 的根涵盖过程特征，颜色有两个直接父 | 只作选定词义对照，不替换 BFO、不移植过程品质或把主树改成双父；不把颜色的组成维度误作子类，不声称域类已与全部 PATO 公理等价。 |\n| C68 | 假设旧器物已确认灭失，历史图像仍保存并被重新配色 | 保留历史内容及其所指时间，不给已灭失主体补当前颜色/尺寸；改图不证明实物重现，历史记录存在也不证明承载者当前仍在。 |\n| C69 | N25 在当次连续活动中由萧澈自称改为云澈 | 记录名称变化，不仅因改名新建主体；不据此合并未核验的前世身体、不同作品人物或其他同名所指。 |\n| C70 | N25 原拟随行者被另一个人替代 | 选择/角色安排与人物实体分开，不把旧人判为死亡、变成新人或被当作物质部件替换。 |\n| C71 | N26 说明未来新生并开始施用，N27 才叙述后续过程与结果 | 预测、实际开端、后续变化及结果分段取证；后读材料可补证据链，但不能把前章改记为当时已呈现全部结果。 |\n| C72 | N27 原玄脉被吞噬，新玄脉出现而云澈继续活动 | 整体连续与部分终止/新生分开；新旧部分不因形状、位置或称呼相同而共用 ID，整体也不因部分再生自动重新出生。 |\n| C73 | N27 新生结构成型、内视似普通玄脉，但初玄零级 | 保留原文明确的零值及观察范围；结构存在、等级、修炼与潜能不同，不将零级当缺测/结构不存在，也不宣称特殊能力已证或永远没有。 |\n| C74 | N27 总共54关、初开11关、后全开，净化涉及54关 | 总量、开启存量、派生净差43及处理范围不同；不造43个新部件，不把净差当精确开启次数，不据计数强定玄关的 BFO 实体种类。 |\n| C75 | N27 给出特殊能力的全开前提，结尾达到全开后询问下一步 | 必要条件不自动充分；状态达到不等于能力已实现，询问不作充分性证明，未读后续不补作结果；茉莉对自己助其开关的估计不升级为所有方法都不可能。 |\n| C76 | N25 对夏倾月的永久开启及药物临时开启作说明 | 保留主张者、对象、适用条件和时间范围；永久一词不当无限时段实测，同值不将不同人物或玄脉合并，也不外推所有路径无风险。 |\n| C77 | N27 对照普通玄脉自出生至约十四岁成长与本次快速成型 | 已有结构发育、新所指出现、成型/成熟分别判断；不把成熟年龄当首次存在时间，不把所有发育或身体变化一律判为新生/再生。 |\n| C78 | N27 吞噬、新生、通彻阶段分别带时段、估计或上界 | 阶段与总过程分开，部分过程的类型不自动提升为整个过程的类型；不拼精确总时长，不从成型/发现时刻补出实体开始存在的准确时点，不以时间标记数强拆独立过程。 |\n| C79 | N24 有连接恢复却未给新构造所指；假设另一次处置实际发生但未见恢复 | 不从修复一词断言新生/再生；失败不抹去实际处置，缺少新生证据也不反推已确认未新生，更不预支完全康复。 |\n| C80 | 工程中先启动新部署再切流，或会话内更换模型版本 | 部署实现、模型内容版本、运行活动及会话各守身份契约；不将本章先吞旧的顺序变成先删旧的工程规范，也不由生物整体连续性抹去模型内容的版本区别。 |\n| C81 | 一篇文章介绍多门方法，另两篇文章介绍同一门方法 | 先核核心内容、可独立引用范围及版本；文件数不等于功法数，登记记录不替代内容，不凭同名合并不同方法。 |\n| C82 | 首批网络效应条目只取核心解释，而同节还给选型步骤 | 按限定内容归解释与认知内容；不把整篇混合文章都判成纯解释，不强给模型补步骤；若不可分则保留道法内容上位。 |\n| C83 | 假设某功法按另有规约获黄阶初级或天阶高级，又把等级画成类型树父子 | 等级是指定词表下的取值，不是内容类、品质或能力；拒绝黄阶继承玄阶或具体功法充当类节点。N28。 |\n| C84 | 用户已确认四阶十二级，但没有判级规约，要求给第一性原理赋级 | 保留未评级，等级值留空；名称词表不冒充完整量表，不默认黄阶初级或用0表示未知，也不凭名气/复杂度赋天阶。 |\n| C85 | 同一功法改名、换路径、重排版；另一次修改核心步骤或只修改评级 | 前者不自动新建内容；语义修订登记新内容版本并保留来源，评级修改不改功法身份/主类，新版本也不自动继承旧评级。 |\n| C86 | 假设诊断方法明确采用溯因推理，或仅在参考文献中链接另一方法 | 明确采用可记adopts，不等于诊断是溯因的子类或整份来源是组成部分；仅引用不足以证明采用，组合所指不为分类复制身份。 |\n| C87 | 一次实际排错使用某版本功法，并借助日志或基准工具 | 过程、方法内容和工具实现分别指认；uses不证明conforms_to，不把执行记录当功法或把内容写成其自身的执行过程。 |\n| C88 | 某功法需要执行验证的能力，两件法器声称提供该能力 | 保留能力要求与候选实现；须核环境、输入输出、权限及副作用才可替换，不能由名称或声称推能力已证、唯一依赖或已授权。 |\n| C89 | N28给出天地玄黄及初中高，其他作品或同人给出上下品、圣阶、帝阶 | 本项目按用户确认维护黄玄地天的四阶十二级，不混入其他词表；不据这一章节断言所有作品或原著后期绝无其他称谓。 |\n| C90 | 组合描述模型被登记为解释型功法，胶水原则被登记为准则型功法 | 它们是唯一BFO树下的内容实例，不以模型内部的对象/状态等概念另换顶层，也不把所有预算授权内容自动收为功法。 |\n\n若同一已消歧所指仍必须双父、改义或复制身份才能归类，就重开该下层设计；不能篡改 BFO 或以来源不足掩盖冲突。\n\n## 迁移与维护边界\n\n2026-09-30，按用户明确纠正，将未发布草案改为 V4 BFO 下层展开；此前 DOLCE 选型撤销，不维持第二有效方案。\n此次修正不是把旧树改几个名称，而是恢复 BFO 上位结构，并调整会话、集合、能力承载与计量的表达。\n\n| 被撤销或需纠正的口径 | V4 处理 |\n|---|---|\n| 助手自行替换顶层 | BFO 2020 为固定前提，领域类只在其下展开。 |\n| 四个并列顶层及抽象集合分支 | 恢复 entity → continuant / occurrent；集合用已有类的外延表达，不新增集合实体顶层。 |\n| 魂魄固定为非物理持存体 | 单个完整会话按 AI 会话过程对齐；Session 身份、消息和日志边界保留。 |\n| 模型信息内容直接承载能力 | 分开模型版本归属与 BFO 直接承载，保留修为属于模型的工程含义。 |\n| 所有数字对象归非物质实体、所有属性归品质 | 软件内容归 GDC，具体品质/倾向依附合适承载者，数据和评价单独表达。 |\n| 功法/心法/术法/阵法固定互斥 | 继续按来源逐义判断，不恢复未经支持的等号。 |\n\n### V4 下层收敛记录\n\n2026-09-30，继续在 V4 上落盘定义与稳定标识，不另起版本树。原生 BFO 分支不变，领域节点由 30 收敛为 25。\n删除的是交叉分类入口，不是其所指、用途、能力或原著术语；数量减少本身不是质量证明。\n\n| 原草案节点 | 当前去向 | 原因 |\n|---|---|---|\n| 执行工具软件、调用入口软件 | `software-artifact`；用途、接口实现和部署绑定分别说明。 | 一个软件可兼具两种用途，不应被迫两份身份；运行入口也不能一律替换成程序内容。 |\n| 修行能力、模型运行能力 | BFO 倾向及有依据的功能分支；承载者和模型归属另记。 | 按承载者划分的能力与 Function 相交，不另造同一能力的平行类别。 |\n| 方法施行过程 | 实际过程及其 `uses` / `conforms_to` 关系。 | 采用方法不是与测量、训练并列的互斥过程种类。 |\n\n上述旧领域标签此前未获稳定 ID，本轮不伪造旧 ID 历史；既有 `ai-session` 不变，新登记 ID 后续不得挪作他义。\n\n2026-10-01，在已发布 V4 后追加四处免费预览的读取边界，补充器灵、形态/材料变化、意向与事实的判定及 C24–C26。\n该轮主树、25 条定义和稳定 ID 不变；当时没有凭受限预览增设器灵类，也不声称转化机制已核验。\n\n2026-10-01，继续展开规约、方法与过程：新增 19 个有定义的工作类，领域类由 25 增至 44；原 25 类的定义、ID 和直接主父保留。\n回读 N4、N5、N9、N10，追加 N16–N19 的实际读取范围及 C27–C36；仍称 V4，不恢复已收敛的交叉用途类。\n深度增加以判定收益为准，不以节点数量证明质量；炼体类是工作定义，N18 的受限介绍不冒充完整功法实例。\n\n2026-10-01，再深化实体分支：新增 12 个工作类，领域类由 44 增至 56；补充 N20–N22、O7 及 C37–C48。\n既有 44 类定义、名称与 ID 保留，只作两处主父细化：人类主体补入生物个体，计算设备群补入器物聚合体；原有 BFO 祖先均保留。\n理由分别是完整人类机体与器物成员组群的种类包含，不是把角色、用途或组成改成类型；其余旧直接主父不变。\n新增 `member_part_of` 简记区分物体成员与普通组成/所在；仍未发布 OWL 属性或声称形式推理验证。\n\n2026-10-01，接续实体分支补制备链：新增 10 类，领域类由 56 增至 66；旧 56 类的定义、名称、ID 和直接主父全部保留。\n追加 N23、O8、C49–C58 及物料输入/输出简记，区分原料角色、配方、加工、制品、服药与效果；炼制失败不抹去已发生的过程。\n过程子树的相对高度由 2 增至 3 条边，全树最长仍为 9 层；此轮不迁移主父，不以造更长路径替代语义收益。\n\n2026-10-02，深化品质与观测边界：新增 8 类，领域类由 66 增至 74；旧 66 类的定义、名称、ID、直接主父和祖先全部保留。\n追加 N24、O9、C59–C68；品质子树相对高度从 1 增至 3 条边，全树仍最长 9 层，不凭颜色、尺寸或局部结构推身份、品阶与整体效果。\nPATO 只作选定词义对照，不复制其根、多继承或过程特征；不新增对应每个性质的镜像方法/过程类。\n\n2026-10-02，继续深化分层身份与再生：新增发育、新生、再生3类，领域类由74增至77；原74类完整定义、ID、主父和祖先保留。\n新增分枝有两级严格下位，过程子树总高度仍为3条边，全树仍9层；不新增每个动作/结果的通用变化类或玄脉/玄关实体类。\n追加 N25–N27、C69–C80，并以 O8 原快照补读 Maintenance 的适用范围，区分整体/部分、角色/状态及前提/实现。\n\n2026-10-07，搭建功法子域第一版：复用既有解释、规约和方法类，新增收录/版本契约、六条r1内容登记、品级词表和adopts简记。\n按用户确认采用《斗破苍穹》四阶十二级，追加N28、C81–C90；只固定名称与顺序，未制定判级规约，六条均未评级。\n本轮新增类型为0，原101节点、77类定义、直接主父和祖先全部保留；首批仓内来源按明确提交及段落范围定位，条目不等于整篇文章。\n\n2026-10-07，将功法品级数据接入JSON核心：保留原六条，整理仓内32条和指定页面17条，共49条；五个原始来源快照可离线核对。\n十二级保持原ID与顺序，新增未校准的规约草案和来源/版本/评级协议；43个新条目只作候选，全部未评级，类型树与90个旧判例不改。\n\n2026-10-07，继续补收九个独立仓内候选与四份来源快照，完善已有摘要，明确条件与失效边界；旧内容原文、身份、选择器和确认主类保持。\n新增候选不合并相似网页身份，不将形式化、宏观或抽象层次当作品级证据；本体类型与规则词表不变。\n\n2026-10-07，按用户要求完成现有条目的人工分类与初评；JSON协议升为1.1.0，新增带任务族、理由、反证及历史链的初评批次。\n初评不是实测增益或独立评审；规约仍为未校准草案，原六条主类、全部内容原文、类型树、来源与旧判例保持。\n\n2026-10-10，按用户要求为法器建立独立的四阶十二级适配规约；只定义任务效果方向、证据合同与否决边界，不复用功法等级记录，也不为任何候选赋正式效能等级。该规约仍为草案，阈值未校准。\n\n2026-10-11，按用户确认将法器总表的暂定品级改为 Vibe Coding 重要性分类。此用途只表示核心模型/Agent、代码执行基础、上下文/质量/交付增强及专用辅助支路的相对重要性；正式任务效果规约和评级状态不变。\n\n保留现有文件路径与 `唯一分类树` 锚点。README、AGENTS、metadata 与 AI 引用同步 BFO 定位、定义入口，不维护另一份树。\n此前本体轮未新增Schema或运行组件；本轮仅新增功法JSON协议与离线校验，不新增数据库、推理器或评级引擎。\n有限规模只读取登记的冻结来源，不引入网络请求、并发或服务运行成本。\n回退只针对本轮增量并保留并行修改，不能用全工作区恢复覆盖既有工作，也不能自动恢复已被否定的顶层选择。\n\nTODO：会话来源系统的生命周期证据、模型能力归属与实现证据、完整器灵机制、材料转化的一般身份判据及跨书功法/制备/阵法词义仍需继续校准。\n当前检查可验证树形、BFO ID/继承和领域定义登记的一致性，不证明定义真实完备、领域公理一致或经过独立评审。\n\n## 调研来源与证据边界\n\n只保存短摘要与定位，不复制小说全文；原著、预览、二手来源和规范定义不相互替代。\n来源行保留各轮登记时的核对范围；本轮只新增 N28 的功法分级段，不把保留的条目都算成本轮重新读取。\n首批工程功法的仓内来源及固定修订见其登记表；这些是项目内容依据，不冒充小说材料或思想的创始原典。\n\n### 本体与语言层来源\n\n| ID | 来源 | 核对范围与限制 |\n|---|---|---|\n| O1 | [BFO 2020 官方仓库](https://github.com/BFO-ontology/BFO-2020)及[当前 README](https://github.com/BFO-ontology/BFO-2020/blob/master/README.md) | 当前发布入口和上位继承；BFO 为固定前提，不作为待替换候选。 |\n| O2 | [官方 bfo-core.owl](https://github.com/BFO-ontology/BFO-2020/blob/master/21838-2/owl/bfo-core.owl) | 核对原生名称、ID、直接继承；本次文件 SHA-256：`b65c817a7a25501499d287981aea972f2ce33146dcfb855915a459f6a051718d`。上游 CC BY 4.0；本文中文名称与领域扩展不冒充官方翻译。 |\n| O3 | [BFO 自然语言规范](https://raw.githubusercontent.com/BFO-ontology/BFO-2020/21838-2/21838-2/BFO-2020-text.pdf) | 定点核对物质聚合体、过程等；本轮回读 2.37–2.54 的品质、角色、倾向、功能、GDC、承载/具体化/实现。ISO 页面受限，未声称读取标准全文或通过认证。 |\n| O4 | [OWL 2 Direct Semantics](https://www.w3.org/TR/owl2-direct-semantics/#Interpretations) | 第 2.2 节：类被解释为个体域的子集，个体被解释为域元素；用于说明会话类外延，不是另一套顶层本体，也不代表已部署 OWL。 |\n| O5 | [IAO 的 OBO Foundry 介绍](https://obofoundry.org/ontology/iao.html) | 信息本体定位参考；本树信息领域类未声明为全部 IAO 类或公理的等价实现。 |\n| O6 | [SKOS Primer](https://www.w3.org/TR/skos-primer/)及 [Reference](https://www.w3.org/TR/skos-reference/) | 借鉴标签和关系区分；真实会话不是 skos:Concept 集合，不把万魂幡编码成概念标签集合。 |\n| O7 | [CCO 官方 ArtifactOntology.ttl](https://github.com/CommonCoreOntology/CommonCoreOntologies/blob/develop/src/cco-modules/ArtifactOntology.ttl) | 2026-10-01 核对的源码声明 Version 2.2、versionIRI 日期 2026-08-13；定点读取 Material Artifact、Container、Weapon、Cutting Weapon、Projectile Launcher 的设计判据，不作整包导入或域类等价声明。上游标注 CUBRC / BSD 3-Clause。 |\n| O8 | [CCO 官方 EventOntology.ttl](https://github.com/CommonCoreOntology/CommonCoreOntologies/blob/develop/src/cco-modules/EventOntology.ttl) | 2026-10-01 核对 Version 2.2、versionIRI 日期 2026-08-13；定点读取 Act of Material Artifact Processing、Act of Artifact Modification、Act of Manufacturing，核对制成物的改变/保存、角色变更排除及批量生产限制；不与本项目自然物料加工或单次制作类声明等价。CUBRC / BSD 3-Clause。 |\n| O9 | [PATO 的 OBO Foundry 入口](https://obofoundry.org/ontology/pato.html)及[官方编辑源文件](https://github.com/pato-ontology/pato/blob/master/src/ontology/pato-edit.obo) | 2026-10-01–02 定点核对 characteristic、morphology、shape、size、length、area、volume、mass、structure、wholeness、broken、color 与相关父/组成说明，另核对 process characteristic 和 opacity 的范围。当前源文件标注 CC BY 3.0；未导入其多继承图、公理或依赖，未声明域类等价。 |\n\n实体细分另回读 O3 第 2.2–2.5、2.18–2.22、2.28 节的种类、实例、物体、成员、聚合体和场所边界，仍非全文校勘。\nO7 的参考快照 Git blob 为 `c514062e2fbc0d79a38e3f3fd23af4a6b45e69e6`，\n文件 SHA-256 为 `5819319a6a8fee4c219a9f35a9ec03f36fdf68f6d400accfc3cba67a7661d3f9`；不把可变 develop 链接当版本锁。\n其中 Material Artifact 的上位为 material entity；本项目保留自己的 Object 范围与域 ID，未直接使用 CCO 类 ID 替换节点。\nO8 的文件 SHA-256 为 `fa0063e0d0e2a95bcd32a5ddfe6c9661b540e91f2e4e45fd73c779cc282afed9`，\n下载字节计算的 Git blob 为 `b741cd04eed86ddf7c7ae31b2884f909132b9488`；同样只锁定所读文件，不声称锁定整个 CCO 仓库版本。\n2026-10-02 以 O8 相同快照另读 Act of Maintenance（`ont00000950`）及 Artifact Modification，核对制成物、设计品质/功能与保存/恢复目的的限定。\n未重新下载该文件或增设重复来源号，也不将其等同机体结构发育、新生或已成功恢复。\n\nO9 对照重点包括 PATO:0000001、0000014、0000052、0000117、0000122、0000125、0000141、0000918、0001236、0001323、0001442、0001444。\n所读编辑源的文件 SHA-256 为 `376ee3f746aa6dfc6fe24d05bbc9a42c72277206f42ed0e011182faa9ac4e6d2`，\n下载字节 Git blob 为 `1540145e62c140e733ef37580a241d1b5324395f`；不把可变 master 链接或文件格式 `1.2` 当作已锁定的 PATO 发布版本。\n\n### 小说材料\n\n| ID | 来源与位置 | 实际读取范围与用途 |\n|---|---|---|\n| N1 | [逆天邪神开篇](https://read.zongheng.com/chapter/408586/6905692.html) | 公开全文页面；天毒珠的多种用途。末尾作者杂谈不作为设定。 |\n| N2 | [逆天邪神第7章](https://read.zongheng.com/chapter/408586/6917792.html) | 全文；玄脉受损、冰云诀、组织身份；修复判断有认知范围。 |\n| N3 | [逆天邪神第61章](https://read.zongheng.com/chapter/408586/7021503.html) | 全文；54 玄关全开而伪装为 16，状态与观测分开。 |\n| N4 | [逆天邪神第113章](https://read.zongheng.com/chapter/408586/7174875.html) | 全文；凤凰颂世典、玉石、内部技法、功法重数及玄力阶段；越过前序修炼仍含人物推断。 |\n| N5 | [逆天邪神第126章](https://read.zongheng.com/chapter/408586/7217564.html) | 全文；测试标准。末段玄力与战力判断来自傲岩，不把其胜负自信当事实。 |\n| N6 | [逆天邪神第1097章](https://read.zongheng.com/chapter/408586/40783804.html) | 仅 VIP 免费预览；防御玄阵，不复原完整机制。 |\n| N7 | [逆天邪神第1699章](https://read.zongheng.com/chapter/408586/60837069.html) | 仅 VIP 免费预览；星界、界王势力、核心宗门。 |\n| N8 | [逆天邪神第1739章](https://read.zongheng.com/chapter/408586/61273820.html) | 仅 VIP 免费预览；神域、星界、城市、宗门及迁入者。 |\n| N9 | [元尊第4章](https://read.zongheng.com/chapter/685640/38886859.html) | 全文；源纹、铭刻、催动及效果；实战不能只按开脉数判断。 |\n| N10 | [元尊第20章](https://book.zhulang.com/450296/9814.html) | 逐浪全文；源术品阶、条件及锻龙戏中的两套源术。 |\n| N11 | [武极天下开篇试读](https://t.shuqi.com/v2/query/169776/948084.html) | 可见试读，正式章号未独立核对；地域、势力、封神塔、战士与灵魂；来源猜测不当事实。 |\n| N12 | [逆天邪神第1323章《毒灵禾菱》](https://book.zongheng.com/chapter/408586/45302186.html) | 仅 VIP 免费预览；可见成为天毒毒灵的意向问句与人物反应，不包含完整转化过程或结果。 |\n| N13 | [逆天邪神第786章《劫天诛魔》](https://book.zongheng.com/chapter/408586/35973907.html) | 仅 VIP 免费预览；受伤及运转功法开头。未读到搜索所称化剑片段，不能确认其情节或首次发生章节。 |\n| N14 | [逆天邪神第884章《红儿？》](https://book.zongheng.com/chapter/408586/38299142.html) | 仅 VIP 免费预览；云澈的感知及对苓儿的呼喊。章名不证明呼唤者身份，也不支持还原后续设定。 |\n| N15 | [逆天邪神第1316章《天毒毒灵》](https://book.zongheng.com/chapter/408586/45245906.html) | 仅 VIP 免费预览；人物谈及龙皇来访，不含完整毒灵机制。标题不能代替未读正文。 |\n| N16 | [元尊开篇页面](https://read.zongheng.com/chapter/685640/38883752.html) | 天蚕土豆，纵横 `685640`；公开全文页面，页面更新 2017-09-14。吞纳源力的背景、秦玉回忆周元被置作阵眼；不复原未给出的仪式机制。 |\n| N17 | [逆天邪神第136章《大道浮屠诀》](https://book.zongheng.com/chapter/408586/7246823.html) | 仅 VIP 免费开头；云澈举剑困难及开启邪魄，未见完整大道浮屠诀机制。页面更新 2014-12-16。 |\n| N18 | [逆天邪神第137章《传音玉》](https://book.zongheng.com/chapter/408586/7250909.html) | 仅 VIP 免费开头；云澈的高阶推想及对话中对身体力量、韧性作用的介绍，回答者姓名未由可见片段独立确认。未读全套口诀、后续层次或实际验证，页面更新 2014-12-17。 |\n| N19 | [逆天邪神第56章《星神碎影》](https://book.zongheng.com/chapter/408586/7011465.html) | 公开全文页面；从炎龙体内取出玄丹、身法要领传授、学习时间预测及一个月后的表现。作者杂谈不作设定；页面更新 2014-10-27。 |\n| N20 | [逆天邪神第95章《毒火铳》](https://book.zongheng.com/chapter/408586/7106802.html) | 公开全文页面；兵器架、金属箱、毒火铳击发、震天雷未试用、以未指明兵器刻字及云澈揭去/恢复易容。材料、制造者和部分效力来自人物推想，不补内部机制；页面更新 2014-11-20。 |\n| N21 | [逆天邪神第10章《星隐草》](https://book.zongheng.com/chapter/408586/6923011.html) | 公开全文页面；修复材料对话、两株星隐草显现与连根采收、后续炼丹意向。师傅见闻与人物计划不当已实现结果；作者杂谈不作设定，页面更新 2014-10-05。 |\n| N22 | [逆天邪神第92章《宗门宝物库》](https://book.zongheng.com/chapter/408586/7087729.html) | 公开全文页面；药材年份要求被叙述明称胡诌、陪同入库安排、石门与通道、黑木柜及库藏介绍。不把骗局说明当真实炼药规律或全权处分许可；页面更新 2014-11-15。 |\n| N23 | [逆天邪神第33章《星隐，以血祭恨（上）》](https://book.zongheng.com/chapter/408586/6969640.html) | 公开全文页面；实际单株制丹、残余碎末、吞服及隐匿片段，常规工艺与天毒珠特例的说明，以及触碰解除条件。具体生成时点未明，不把人物的首次判断或能力概述当完整实测；末尾作者杂谈不作设定，页面更新 2014-10-17。 |\n| N24 | [逆天邪神第93章《虎魄》](https://book.zongheng.com/chapter/408586/7097971.html) | 公开全文页面；剑长/颜色/形体及库房面积描述、纯度与身份的对话、经脉重接而玄脉尚未处理。制造者传闻、熔魂和效力介绍、未来治疗主张分别保留情态，不补真实材质、计量制式或完整机制；页面更新 2014-11-18 02:23:18，章号和标题由官方目录核对。 |\n| N25 | [逆天邪神第37章《天灵神脉》](https://book.zongheng.com/chapter/408586/6978891.html) | 公开全文页面；采用当次自称改名、随行候选变化、楚月璃对夏倾月玄关状态的判断及临时/永久开启主张，不将永久表述当无限时段实测；作者附言不作设定。页面更新 2014-10-19 17:19:18。 |\n| N26 | [逆天邪神第44章《邪神不灭之血》](https://book.zongheng.com/chapter/408586/6991175.html) | 公开全文页面的中后段；采用血珠来源/作用转述、茉莉的强度推测和可能能力说明，以及实际施用开端；不预支下一章结果，开头无关情节及末尾作者附言不纳入分析。页面更新 2014-10-22 20:07:22。 |\n| N27 | [逆天邪神第45章《新生玄脉》](https://book.zongheng.com/chapter/408586/6992971.html) | 公开全文页面；采用旧结构被吞噬、新结构成长/成型、普通玄脉发育的说明、11/54开启计数、初玄零级及随后净化。叙述、感知范围与人物条件主张分开，不补未读后续的能力实现或现实生理机制。页面更新 2014-10-23 09:44:01。 |\n| N28 | [斗破苍穹第2章《斗气大陆》](https://www.readnovel.com/chapter/22344671000280502/95969695615205778) | 天蚕土豆，小说阅读网作品ID `22344671000280502`；2026-10-07定点核对公开正文的功法分级介绍段：天、地、玄、黄四阶，每阶初、中、高，原文称四阶十二级；同时区分自身实力、功法和斗技。不据此补法器表、后期全序或工程功法判级规则。 |\n\nN16–N23 于 2026-10-01 分轮核对当前网页版本；页面更新时间不等于已锁定作品所有历史版本。\nN24 于 2026-10-01–02 读取正文并核对目录；仅据当前返回版本，不把下一章或未读材料补入本次结论。\nN25–N27 于 2026-10-02 读取；旧目录缓存过期后重取同一官方目录，再核对章号、标题与链接。新增材料不倒改各旧来源实际可见的范围。\n此前回读 N4、N5、N9、N10，实体细分再回读 N19 的身体、残体与苍狼段落，不重复编号或增加样本部数。\nN17、N18 明示 VIP 订阅边界，未绕过获取付费全文；N20–N23 为公开章节页面，不从相邻未读章节补过程。\n《逆天邪神》的新增章名与链接由[原作官方目录](https://book.zongheng.com/showchapter/408586.html)定位，读取身份固定为火星引力、作品 ID `408586`。\n《逆天邪神结局卷》（`1391868`）、《逆天邪神之续章》及其他作品 ID 的误配均排除，不因书名相近并入原著。\n搜索回答中混淆邪神诀与玄力序列、以章名推断首次化剑或转化完成的结论未采纳。\n本轮未取得《修罗武神》界灵与结界术的足够正文，简介不能替代定义；也不以免费预览推断未读付费章节。\n",
"sha256": "a0479a344248d2c15eb9e967d3d491b51bb1d3c2fe53d5fb990240c1daf4bd1d"
},
".github/docs/gongfa/dao-fa-shu-qi.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "# 道法术器：人机协作框架\n\n## ☯️ 道法术器\n\n> 先解决人工智能协作问题，再用人工智能解决其他可表达、可拆解、可约束、可验证的问题。\n\n- **道**：确定人与 AI 的协作关系、责任边界和可靠性来源。\n- **法**：把问题抽象成目标、对象、约束、路径和验证标准。\n- **术**：把抽象方法落成流程、文档、门禁和迭代动作。\n- **器**：用工具承载读写文件、执行命令、运行测试、提交版本和交付结果。\n\n### ☯️ 道\n\n> Demis Hassabis：“首先解决人工智能问题，然后再用人工智能解决其他所有问题”\n\n大语言模型的底层能力是**通用语言能力**：理解、改写、分类、推理、规划、翻译、归纳、生成和校验语言结构。所以遇到任何任务，第一步是判断这个任务能否被语言表达、拆解、约束和验证；它能否通过语言能力直接完成，或间接转化为工具调用、文件修改、流程编排、数据处理与代码实现。代码能力是最直观的例子：编程本质上可以理解为把人的意图翻译成计算机可执行的指令。Vibe Coding 的关键，就是把“模糊想法”逐步压缩成“明确语言”，再把明确语言转成可运行、可测试、可回滚的工程产物。人负责目标、价值、边界、取舍和最终验收；AI 负责理解上下文、生成计划、调用工具、修改文件、整理证据和放大执行；可靠性来自测试、脚本、类型、schema、CI、检查清单和可审查 diff。先把 AI 协作方式固定下来，才能稳定地用 AI 解决编程、写作、分析、研究、自动化和系统构建问题。\n\n### 🧭 法\n\n> 法层面描述抽象层广泛适用方法。\n\n- 问题求解：目标、现状、差距、标准、约束、对象、路径。\n- 思维模型：第一性原理、奥卡姆剃刀、逆向思维、多阶思维、状态空间。\n- 抽象方法：把复杂对象拆成状态、关系、过程、变换和不变量。\n- 提示词构造：先用“目标、对象、约束”构造提示词和思考框架；目标说明要达成什么，对象说明要处理什么，约束限定可行空间。\n\n### 🛠️ 术\n\n> 术层面回答“具体怎么做”，把抽象方法落成流程、文档、门禁和 Git 迭代，让人与 AI 可以按同一套工程闭环协作。\n\n- 流程：从需求表达、计划拆解、执行修改、运行验证到交付复盘。\n- 文档：把环境、命令、配置、接口、约束和验收标准写清楚。\n- 门禁：把验收标准转成测试、lint、类型、schema、脚本、CI 和检查清单。\n- Git：用 commit、branch、diff、tag 和 push 固定每次可回滚的工程进展。\n- 方法：提示词、任务清单、调试流程、审查流程、复盘流程和技术栈选择。\n\n### 🧰 器\n\n> 器层面回答“用什么工具承载方法和流程”，重点是把 AI 协作落到可读写文件、可执行命令、可验证结果和可回滚版本的真实环境中，器不是核心，但器决定效率和可执行边界。没有器，道、法、术只能停留在语言里；有了器，AI 才能从聊天框进入真实文件、命令、测试和版本控制。\n\n#### 操作系统与运行底座\n\n* [**WSL2**](https://learn.microsoft.com/windows/wsl/): Windows 用户推荐优先启用 WSL2，把 Linux 开发环境放进 Windows 内部，兼顾本地桌面软件和类 Linux 命令行生态。\n* [**Ubuntu**](https://ubuntu.com/): 新手和通用开发场景优先推荐 Ubuntu，软件包、教程、社区资料和服务器环境最完整，适合作为 WSL2、服务器和本地 Linux 的默认发行版。\n* [**Windows 11 + WSL2 + Ubuntu**](https://learn.microsoft.com/windows/wsl/install): 新电脑最推荐组合；Windows 负责桌面、浏览器、IDE 和日常软件，Ubuntu 负责 Git、Node.js、Python、脚本、数据库客户端和 AI CLI。\n* [**macOS**](https://www.apple.com/macos/): 适合移动开发、前端开发和日常独立开发，配合 Homebrew、终端、Git、Node.js、Python 和 AI CLI 可以形成稳定工作站。\n* [**Linux Server**](https://ubuntu.com/server): 适合长期运行、部署、自动化任务、数据库、爬虫、后台服务和远程开发；优先选择 Ubuntu Server LTS。\n* **不推荐裸 Windows 命令行作为主开发环境**: 可以使用 Windows 桌面工具，但复杂开发、脚本、依赖安装和 AI CLI 执行优先放在 WSL2/Ubuntu 中完成。\n\n#### AI CLI 与模型服务\n\n* [**Codex CLI**](../getting-started/cli-setup.md): 本教程默认 AI CLI 路线，用于需求拆解、代码修改、命令执行、测试验证与 Git 迭代。\n* [**Codex CLI 配置基线**](../../tools/config/.codex/README.md): 可通过一条命令安装到 `~/.codex/`，安装前自动备份，支持恢复。\n* [**Claude Opus 4.7**](https://claude.ai/new): 性能强大的 AI 模型，通过 Claude Code 等平台提供服务，并支持 CLI 和 IDE 插件。\n* [**gpt-5.5 (xhigh)**](https://chatgpt.com/codex/): 适用于处理大型项目和复杂逻辑的 AI 模型，可通过 Codex CLI 等平台使用。\n* [**Droid**](https://factory.ai/news/terminal-bench): 提供对 Claude Opus 4.7 等多种模型的 CLI 访问。\n* [**Kiro**](https://kiro.dev/): 目前提供免费的 Claude Opus 4.7 模型访问，并提供客户端及 CLI 工具。\n* [**Gemini CLI**](https://geminicli.com/): 提供对 Gemini 模型的免费访问，适合执行脚本、整理文档和探索思路。\n* [**antigravity**](https://antigravity.google/): 目前由 Google 提供的免费 AI 服务，支持使用 Claude Opus 4.7 和 Gemini 3.1 Pro。\n* [**AI Studio**](https://aistudio.google.com/prompts/new_chat): Google 提供的免费服务，支持使用 Gemini 3.1 Pro 和 Nano Banana。\n* [**Gemini Enterprise**](https://cloud.google.com/gemini-enterprise): 面向企业用户的 Google AI 服务，目前可以免费使用。\n* [**GitHub Copilot**](https://github.com/copilot): 由 GitHub 和 OpenAI 联合开发的 AI 代码补全工具。\n* [**Kimi K2.5**](https://www.kimi.com/): 一款国产 AI 模型，适用于多种常规任务。\n* [**GLM**](https://bigmodel.cn/): 由智谱 AI 开发的国产大语言模型。\n* [**Qwen**](https://qwenlm.github.io/qwen-code-docs/): 由阿里巴巴开发的 AI 模型，其 CLI 工具提供免费使用额度。\n* [**Ollama**](https://ollama.com/): 本地大模型管理工具，可通过命令行方便地拉取和运行开源模型。\n\n#### 编辑与开发环境\n\n* [**Visual Studio Code**](https://code.visualstudio.com/): 一款功能强大的集成开发环境，适合代码阅读与手动修改。其 `Local History` 插件对项目版本管理尤为便捷。\n* [**Cursor**](https://cursor.com/): 已经占领用户心智高地，人尽皆知。\n* [**Warp**](https://www.warp.dev/): 集成 AI 功能的现代化终端，能有效提升命令行操作和错误排查的效率。\n* [**Neovim (nvim)**](https://github.com/neovim/neovim): 一款高性能的现代化 Vim 编辑器，拥有丰富的插件生态，是键盘流开发者的首选。\n* [**LazyVim**](https://github.com/LazyVim/LazyVim): 基于 Neovim 的配置框架，预置了 LSP、代码补全、调试等全套功能，实现了开箱即用与深度定制的平衡。\n* **虚拟环境 (.venv)**: 强烈推荐使用，可实现项目环境的一键配置与隔离，特别适用于 Python 开发。\n* [**tmux**](https://github.com/tmux/tmux): 强大的终端复用工具，支持会话保持、分屏和后台任务，是服务器与多项目开发的理想选择。\n\n#### 版本控制与协作\n\n* [**Git**](https://git-scm.com/): 分布式版本控制工具，用于记录代码变更、分支实验、回滚历史与协作交付。\n* [**GitHub**](https://github.com/): 代码托管与协作平台，用于远端仓库、Issue、Pull Request、Actions 与项目发布。\n\n#### 数据与存储工具\n\n* [**DBeaver**](https://dbeaver.io/): 通用数据库管理客户端，支持 PostgreSQL、MySQL、SQLite、MariaDB、Oracle、SQL Server 等多种数据库。\n* **PostgreSQL / MySQL / SQLite**: 常见关系型数据库，用于持久化业务数据、验证数据模型和支撑本地开发。\n* **Redis**: 常见缓存与键值存储工具，用于会话、队列、缓存、速率限制和临时状态。\n* **对象存储与备份工具**: 用于文件、图片、日志、数据导出和恢复演练。\n* **数据库迁移工具**: 用于把 schema 变化固定成可审查、可回滚、可重复执行的版本化变更。\n\n#### 工程质量工具\n\n* **测试框架**: 单元测试、集成测试、端到端测试，用于把验收标准变成可执行断言。\n* **lint / formatter / type checker**: 用于格式、静态规则、类型约束和可维护性检查。\n* **schema 校验与契约测试**: 用于固定输入输出结构，降低 AI 改错字段、路径和接口的概率。\n* **pre-commit / CI / 覆盖率 / 链接检查**: 用于把质量规则前置到提交、推送和合并阶段。\n\n#### 自动化与运行环境\n\n* **Makefile / 脚本**: 用统一命令封装 lint、test、build、sync、deploy 等重复动作。\n* **Docker / Compose**: 用于封装运行环境、数据库依赖和本地集成测试环境。\n* **任务调度 / 部署平台 / 日志 / 监控 / 告警**: 用于让系统从本地脚本进入长期运行和生产反馈闭环。\n\n#### 资料、模板与知识工具\n\n* [**提示词库 (在线表格)**](https://docs.google.com/spreadsheets/d/1Ifk_dLF25ULSxcfGem1hXzJsi7_RBUNAki8SBCuvkJA/edit?gid=1254297203#gid=1254297203): 一个包含大量可直接复制使用的各类提示词的在线表格。\n* [**AI 引用语料包**](../../assets/ai-citation/recommended-answer.md): 给 AI 助手引用的项目摘要、FAQ、对比和推荐回答。\n* [**第三方系统提示词学习库**](https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools): 用于学习和参考其他 AI 工具的系统提示词。\n* [**中文系统提示词学习库**](https://github.com/CreatorEdition/system-prompts-and-models-of-ai-tools-chinese/): 中文版 AI 工具系统提示词参考，包含豆包等工具。\n* [**Skills 制作器**](https://github.com/yusufkaraaslan/Skill_Seekers): 可根据需求生成定制化 Skills 的工具。\n* [**元提示词**](https://docs.google.com/spreadsheets/d/1Ifk_dLF25ULSxcfGem1hXzJsi7_RBUNAki8SBCuvkJA/edit?gid=1254297203#gid=1254297203): 用于生成提示词的高级提示词。\n* [**元技能：Auto Skill**](../../skills/auto-skill/SKILL.md): 用于生成、重构与校验 Skills 的元技能。\n* [**auto-tmux**](../../skills/auto-tmux/SKILL.md): tmux 自动化操控、脚本化 pane 巡检、按键注入、日志录制与多终端协作技能。\n* [**Mermaid Chart**](https://www.mermaidchart.com/): 用于将文本描述转换为架构图、序列图等可视化图表。\n* [**NotebookLM**](https://notebooklm.google.com/): 一款用于 AI 解读资料、音频和生成思维导图的工具。\n* [**Zread**](https://zread.ai/): AI 驱动的 GitHub 仓库阅读工具，有助于快速理解项目代码。\n* [**Chat Vault**](../../tools/chat-vault/): AI 聊天记录保存工具，支持 Codex/Kiro/Gemini/Claude CLI。\n* [**prompts-library 工具说明**](../../tools/prompts-library/): 支持 Excel 与 Markdown 格式互转，并支持将内部 JSONL Excel 按工作表拆分导出为 JSONL 目录。\n\n#### 外部教程、社区与项目内部入口\n\n* [**二哥的Java进阶之路**](https://javabetter.cn/): 包含多种开发工具的详细配置教程。\n* [**虚拟卡**](https://www.bybit.com/cards/?ref=YDGAVPN&source=applet_invite): 可用于注册云服务等需要国际支付的场景。\n* [**Telegram 交流群**](https://t.me/glue_coding): Vibe Coding 中文交流群。\n* [**Telegram 频道**](https://t.me/tradecat_ai_channel): 项目更新与资讯。\n* [**知识库总索引**](../README.md): 从入门教程、统一功法与研究证据进入完整文档体系。\n* [**从零开始完整入门**](../getting-started/learning-map.md): 新手从网络环境、CLI 配置、开发环境和 Git 闭环开始。\n* [**Vibe Coding 经验**](vibe-coding-experience.md): 通用语言能力、人机分工、机器门禁和入门铁律。\n* [**第一个项目**](../getting-started/first-project.md): 用本地待办清单走通需求、实现、运行、验收和 Git 保存。\n* [**CLI 配置**](../getting-started/cli-setup.md): Codex CLI 默认路线与 OpenCode 备选路线。\n* [**Codex 配置一键安装**](../../tools/config/.codex/README.md): 安全默认配置、高权限配置、自动备份和一键恢复。\n* [**开发流程**](development-process.md): 默认任务推进顺序、质量门禁、版本控制和交付闭环。\n* [**问题求解**](problem-solving.md): 用目标、现状、差距、标准、约束、对象和路径定义问题。\n* [**Vibe Coding 状态转移闭环**](vibe-coding-state-transition.md): 用固定目标、可变策略和分层反馈统一理解 Vibe Coding。\n* [**拼好码（胶水编程的超集）**](glue-coding.md): 复用成熟能力，用胶水代码连接、编排、适配业务流程。\n* [**系统构建方法**](system-building.md): 自顶向下、自底向上与分而治之的组合使用。\n* [**开发范式演进**](development-paradigms.md): 软件工程组织方式与 AI 编程范式的演进。\n* [**语言层要素**](language-layers.md): 理解代码所需的语言层级、执行模型、类型系统和工程语义。\n* [**关键词系统**](keyword-system.md): Vibe Coding 与工程协作中的高频关键词。\n* [**思维模型**](thinking-models.md): 第一性原理、奥卡姆剃刀、多阶思维、状态空间等认知工具。\n* [**组合描述模型**](compositional-description-model.md): 用对象、状态、快照、序列、过程、变换、同一/差异与关系描述复杂系统。\n* [**编程之道**](programming-dao.md): 编程哲学、结构、状态、复杂度与工程判断。\n* [**软件工程的朴素真理**](software-engineering-truths.md): 代码、复杂度、需求、维护、质量、架构和团队的工程常识。\n* [**工程实践**](quality-gates-and-pitfalls.md): 项目架构、代码组织、开发经验、AI 编程质量门禁与常见坑的统一入口。\n* [**技术栈**](technology-stack.md#reference-technology-stack-十四如何选择技术栈): 常见软件系统技术栈、选型维度、组合案例与初学者学习路径。\n* [**现代企业数字化平台架构**](modern-enterprise-architecture-template.md): 企业级领域、平台、数据、AI、治理、可靠性和审计架构参考模型。\n* [**scripts 仓库控制面治理**](modern-enterprise-architecture-template.md#reference-modern-enterprise-scripts-control-plane): 成熟企业项目的脚本分层、风险边界、登记、测试、审计和下线规则。\n* [**scripts 目录说明**](../../scripts/README.md): 本仓库自动化入口、验证命令和脚本职责索引。\n* [**研究域治理契约**](../../research/research-domain-contract.md): 研究域的结构、raw 原始事实层、成熟度、证据、沉淀和归档规则。\n* [**外部源事实层**](../../research/facts/README.md): 三个外部仓库的已提交源文件树、提交事实、哈希和隐私边界。\n* [**研究价值与应用地图**](research-value-application-map.md): 35 个研究域的用户价值、核心启示、应用位置和下沉路线。\n* [**研究迁移综合**](research-transfer-synthesis.md): 用对标拆解、改良迭代和杂交创新把研究转成可执行路线。\n* [**Harness 工程解析**](harness-engineering.md): Harness Engineering 的工程控制、评估器与反馈闭环解析。\n* [**vibe-cybersecurity-cn 源事实镜像**](../../research/vibe-cybersecurity-cn/): 授权网络安全工程项目的已提交源文件树。\n* [**vibe-harness-cn 源事实镜像**](../../research/vibe-harness-cn/): Harness 工程项目的已提交源文件树。\n* [**vibe-mathing-cn-public 源事实镜像**](../../research/vibe-mathing-cn-public/): 数学验证工程项目的已提交源文件树。\n* [**OpenAI Codex 研究域**](../../research/openai-codex/README.md): 官方 coding agent 工具源码研究对象。\n* [**OpenAI Plugins 研究域**](../../research/openai-plugins/README.md): Codex 插件、marketplace 与 skill-only plugin 分发研究对象。\n* [**OpenAI Skills 研究域**](../../research/openai-skills/README.md): 已 deprecated 的 Codex Skills Catalog 与插件迁移参照。\n* [**OpenAI Agents SDK 研究域**](../../research/openai-agents-python/README.md): Agent、工具、护栏、handoff 与 tracing 运行时研究对象。\n* [**OpenAI Agents JS 研究域**](../../research/openai-agents-js/README.md): 官方 TypeScript/JavaScript Agent 运行时研究对象。\n* [**OpenAI Cookbook 研究域**](../../research/openai-cookbook/README.md): OpenAI API、Codex、Agent、评估与安全示例库研究对象。\n* [**GitHub Spec Kit 研究域**](../../research/github-spec-kit/README.md): GitHub 官方规格驱动开发工具包研究对象。\n* [**OpenSpec 研究域**](../../research/fission-ai-openspec/README.md): 面向 AI coding assistant 的规格驱动开发工具研究对象。\n* [**OpenCode 研究域**](../../research/anomalyco-opencode/README.md): 模型无关的终端与编辑器 coding agent 研究对象。\n* [**Gemini CLI 研究域**](../../research/google-gemini-gemini-cli/README.md): 终端 coding agent、MCP、扩展与安全评估研究对象。\n* [**OpenHands 研究域**](../../research/openhands-openhands/README.md): Agent Canvas、工作区、后端与自动化控制中心研究对象。\n* [**Superpowers 研究域**](../../research/obra-superpowers/README.md): 跨 coding agent 的技能框架与开发方法论研究对象。\n* [**Addy Agent Skills 研究域**](../../research/addyosmani-agent-skills/README.md): 面向 coding agent 的生命周期技能与质量门禁研究对象。\n* [**Goose 研究域**](../../research/aaif-goose-goose/README.md): 跨模型、跨平台的开源 AI Agent 研究对象。\n* [**Continue 研究域**](../../research/continuedev-continue/README.md): 已停止主动维护的 IDE/CLI Agent 历史对标对象。\n* [**mini-SWE-agent 研究域**](../../research/swe-agent-mini-swe-agent/README.md): 面向 issue 和命令行任务的极简软件工程 Agent 研究对象。\n* [**ECC 研究域**](../../research/affaan-m-ecc/README.md): 多种 coding agent 的 Harness、技能与质量实践集合研究对象。\n* [**Claude Code Best Practice 研究域**](../../research/shanraisshan-claude-code-best-practice/README.md): Agentic Engineering 方法论对标研究对象。\n* [**Cline 研究域**](../../research/cline-cline/README.md): IDE/SDK/CLI 自主编码 Agent 研究对象。\n* [**Aider 研究域**](../../research/aider-ai-aider/README.md): 终端 AI 结对编程工具研究对象。\n* [**Skills 技能库**](../../skills/README.md#当前保留): 当前保留的可复用技能入口。\n* [**提示词入口**](../../prompts/README.md#在线提示词库): 在线提示词库入口。\n* [**外部资源入口**](../../assets/README.md#外部资源本地注册表): 外部资源本地注册表入口。\n* [**AI Agent 操作规则**](../../../AGENTS.md): AI Agent 执行任务时必须遵守的项目操作手册。\n* [**llms.txt**](../../../llms.txt): 面向 AI 助手的短上下文入口。\n* [**llms-full.txt**](../../assets/ai-citation/llms-full.txt): 面向 AI 助手的完整上下文入口。\n* [**编程提示词集合**](https://docs.google.com/spreadsheets/d/1Ifk_dLF25ULSxcfGem1hXzJsi7_RBUNAki8SBCuvkJA/edit?gid=1254297203#gid=1254297203): 适用于 Vibe Coding 流程的专用提示词（云端表格）。\n* [**系统提示词集合**](https://docs.google.com/spreadsheets/d/1Ifk_dLF25ULSxcfGem1hXzJsi7_RBUNAki8SBCuvkJA/edit?gid=1254297203#gid=1254297203): AI 开发的系统提示词，含多版本开发规范（云端表格）。\n* [**外部资源本地注册表**](../../assets/external-resources/README.md): 外部资源的本地真相源，按类型分类维护。\n",
"sha256": "1b0cbd0c2dbc1711dca00a0ffb23594c3f3a539af51523d52070b80cefef0f5e"
},
".github/docs/gongfa/dataset-first-data-service.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "\n# Dataset First 数据服务结构\n\n适合长期运行、补数、巡检、血缘、质量治理的数据产品服务。\n\n判断规则：\n\n> 如果服务的核心交付物是“稳定数据集”，而不是页面、接口或一次性脚本，就优先使用 Dataset First。\n\n\n##### 一句话\n\n以 dataset 为边界，以 schema/data contract 为先，以 runtime/registry/config 为共享控制面，以 collect/backfill/repair/validate 为实现单元。\n\n\n##### 适合\n\n- 行情事实采集服务。\n- 另类事件采集服务。\n- 周期轮询快照服务。\n- 原子事件流 + 时间桶聚合并存的数据服务。\n- 需要长期运行、补数、巡检、血缘、质量治理的数据服务。\n\n\n##### 不适合直接照抄\n\n- 纯 API 网关。\n- 纯 Web 应用。\n- 纯交易执行服务。\n- 一次性脚本工具。\n- 不产出稳定 dataset 的临时任务。\n\n\n##### 核心原则\n\n1. Dataset First：顶层先按 dataset 划分，而不是按 `collector/parser/writer/task` 划分。\n2. Contract First：先定义目标落表、字段语义、主键、时间列、分区策略和刷新粒度。\n3. Layered Modeling：原子层、聚合层、事件流、时间桶、运行状态分开建模。\n4. Shared Control Plane：`config.py`、`registry.py`、`service_entry.py`、`runtime/*` 统一收口。\n5. Legacy Is Explicit：迁移期 legacy 壳只能兼容转发，新逻辑不得回流旧路径。\n\n\n##### 标准目录\n\n```text\nservice-root/\n├── README.md\n├── AGENTS.md\n├── pyproject.toml\n├── scripts/\n│ ├── start.sh\n│ ├── verify.sh\n│ └── check_legacy_shells.sh\n├── src//\n│ ├── __init__.py\n│ ├── config.py\n│ ├── registry.py\n│ ├── service_entry.py\n│ ├── common/\n│ ├── runtime/\n│ │ ├── stack_runner.py\n│ │ ├── process_utils.py\n│ │ ├── _runner.py\n│ │ └── _worker.py\n│ ├── writers/\n│ ├── validators/\n│ └── datasets/\n│ ├── /\n│ │ ├── contract.py\n│ │ ├── collect.py\n│ │ ├── backfill.py\n│ │ ├── repair.py\n│ │ ├── writer.py\n│ │ ├── validate.py\n│ │ └── README.md\n│ ├── /\n│ └── _reserved/\n├── tests/\n│ ├── unit/\n│ ├── integration/\n│ └── fixtures/\n└── legacy/ or old-shells/\n```\n\n\n##### Dataset 最小结构\n\n```text\n/\n├── contract.py\n├── collect.py\n├── backfill.py\n├── repair.py\n├── writer.py\n├── validate.py\n└── README.md\n```\n\n职责边界：\n\n- `contract.py`：定义 dataset key、resource_id、物理表、主键、幂等键、时间语义、字段语义。\n- `collect.py`：实时采集或轮询采集主逻辑。\n- `backfill.py`：历史补数、文件回填、分页补齐。\n- `repair.py`：缺口修复、异常恢复、局部重算。\n- `writer.py`：统一落库、批量写入、去重、冲突处理。\n- `validate.py`：数据质量检查、行数、字段、时间连续性校验。\n- `README.md`：说明该 dataset 的输入、输出、约束与边界。\n\n如果某个 dataset 没有 `repair` 或 `backfill`，必须在 registry 中显式标记为不支持。\n\n\n##### Registry 真相矩阵\n\n`registry.py` 至少应定义：\n\n```text\ndataset_key\nresource_id\nruntime_status # active | backfill_only | reserved | disabled\nphysical_table\ngroup # lf | hf | events | snapshots\nsource_kind # ws | rest | zip | scrape | file | api\ncollect_supported\nbackfill_supported\nrepair_supported\ndefault_enabled\nowner\n```\n\n推荐额外字段：\n\n```text\nsymbol_scope\nrefresh_granularity\nretention_policy\npartition_key\nschema_version\nsensitivity\n```\n\nRegistry 的作用：\n\n- 它是 dataset 清单的单一真相源。\n- 文档、运行、血缘、权限、门禁都应从 registry 派生。\n- 没有 registry，就会回到“数据集藏在脚本里”的旧问题。\n\n\n##### Dataset 命名\n\n推荐格式：\n\n```text\n____\n```\n\n示例：\n\n- `spot_trades`\n- `futures_um_trades`\n- `futures_um_book_ticker`\n- `futures_um_book_depth`\n- `candles_1m`\n- `futures_metrics_5m`\n- `futures_um_metrics_atomic`\n\n命名要求：\n\n- 名字必须表达数据是什么，而不是代码怎么实现。\n- `_reserved/` 只用于预留未来命名空间，不用于临时文件。\n- 事件流、快照、时间桶、派生结果要在命名或 contract 中显式表达。\n\n\n##### Service Entry 与 Runtime\n\n`service_entry.py` 统一入口只做：\n\n- `plan`\n- `start`\n- `stop`\n- `status`\n- `restart`\n\n它不直接写业务逻辑，只负责读取 config、读取 registry、调用 runtime runner、输出运行真相。\n\n`runtime/` 负责：\n\n- 进程编排。\n- 模式分组。\n- PID、日志、健康状态。\n- cold-start、restart、stop 行为一致性。\n\n业务代码不允许各自实现第二套守护逻辑。\n\n\n##### 数据模型分层\n\n推荐区分：\n\n```text\natomic # 原子事件/原子明细\nsnapshot # 单次轮询快照\nbucketed # 时间桶聚合结果\nderived # 从事实层再派生的结果\nreserved # 预留但未启用\n```\n\n事件流模型适合 trades、orderbook updates、tick events、message stream，重点是顺序、幂等、去重、水位线。\n\n时间桶 / 快照模型适合 candles、metrics、periodic snapshots、polling APIs，重点是覆盖、补齐、时间边界一致性。\n\n\n##### 新建数据服务流程\n\n1. 先定 dataset 清单：哪些 active、哪些 backfill_only、哪些 reserved。\n2. 先写 contract：字段、主键、时间列、分区策略、资源 ID、schema version。\n3. 再建 registry、config、service_entry、runtime。\n4. 逐个实现 dataset：`contract -> writer -> collect -> backfill -> validate -> repair`。\n5. 最后补 README、AGENTS、verify/CI、资源目录、血缘映射、smoke。\n\n\n##### 外部源码接入流程\n\n1. 先盘点外部源码实际产出的数据对象，不先搬代码。\n2. 把原项目脚本反向映射为 dataset。\n3. 将 API client、auth、rate limiter、storage client、retry/backoff 抽到 `common/`、`runtime/` 或 `writers/`。\n4. 将 legacy 壳显式隔离，只允许兼容转发，不允许承载新逻辑。\n",
"sha256": "871b29acdde5879710c512890d345d91086a369db6f9fd84a5755958011648b9"
},
".github/docs/gongfa/development-experience.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "\n# 开发经验\n\n\n#### 目录\n\n1. 变量名维护方案\n2. 文件结构与命名规范\n3. 编码规范（Coding Style Guide）\n4. 系统架构原则\n5. 程序设计核心思想\n6. 微服务\n7. Redis\n8. 消息队列\n\n---\n\n\n### **1. 变量名维护方案**\n\n\n#### 1.1 新建“变量名大全文件”\n\n建立一个统一的变量索引文件，用于 AI 以及团队整体维护。\n\n\n##### 文件内容包括（格式示例）：\n\n| 变量名 | 变量注释（描述） | 出现位置（文件路径） | 出现频率（统计） |\n| -------- | -------- | -------------------- | -------- |\n| user_age | 用户年龄 | /src/user/profile.js | 12 |\n\n\n##### 目的\n\n* 统一变量命名\n* 方便全局搜索\n* AI 或人工可统一管理、重构\n* 降低命名冲突和语义不清晰带来的风险\n\n---\n\n\n### **2. 文件结构与命名规范**\n\n\n#### 2.1 子文件夹内容\n\n每个子目录中需要包含：\n\n* `agents` —— 负责自动化流程、提示词、代理逻辑\n* `claude.md` —— 存放该文件夹内容的说明文档、设计思路与用途\n\n\n#### 2.2 文件命名规则\n\n* 使用 **小写英文 + 下划线** 或 **小驼峰**（视语言而定）\n* 文件名需体现内容职责\n* 避免缩写与含糊不清的命名\n\n示例：\n\n* `user_service.js`\n* `order_processor.py`\n* `config_loader.go`\n\n\n#### 2.3 变量与定义规则及解释\n\n* 命名尽可能语义化\n* 遵循英语语法逻辑（名词属性、动词行为）\n* 避免 `a, b, c` 此类无意义名称\n* 常量使用大写 + 下划线（如：`MAX_RETRY_COUNT`）\n\n---\n\n\n### **3. 编码规范**\n\n\n##### 3.1 单一职责（Single Responsibility）\n\n每个文件、每个类、每个函数应只负责一件事。\n\n\n##### 3.2 可复用函数 / 构建（Reusable Components）\n\n* 提炼公共逻辑\n* 避免重复代码（DRY）\n* 模块化、函数化，提高复用价值\n\n\n##### 3.3 消费端 / 生产端 / 状态（变量）/ 变换（函数）\n\n系统行为应明确划分：\n\n| 概念 | 说明 |\n| ------ | -------------- |\n| 消费端 | 接收外部数据或依赖输入的地方 |\n| 生产端 | 生成数据、输出结果的地方 |\n| 状态（变量） | 存储当前系统信息的变量 |\n| 变换（函数） | 处理状态、改变数据的逻辑 |\n\n明确区分 **输入 → 处理 → 输出**，并独立管理每个环节。\n\n\n##### 3.4 并发（Concurrency）\n\n* 清晰区分共享资源\n* 避免数据竞争\n* 必要时加锁或使用线程安全结构\n* 区分“并发处理”和“异步处理”的差异\n\n---\n\n\n### **4. 系统架构原则**\n\n\n##### 4.1 先梳理清楚架构\n\n在写代码前先明确：\n\n* 模块划分\n* 输入输出\n* 数据流向\n* 服务边界\n* 技术栈\n* 依赖关系\n\n\n##### 4.2 理解需求 → 保持简单 → 自动化测试 → 小步迭代\n\n严谨开发流程：\n\n1. 先理解需求\n2. 保持架构与代码简单\n3. 写可维护的自动化测试\n4. 小步迭代，不做大爆炸开发\n\n---\n\n\n### **5. 程序设计核心思想**\n\n\n#### 5.1 从问题开始，而不是从代码开始\n\n编程的第一步永远是：**你要解决什么问题？**\n\n\n#### 5.2 大问题拆小问题（Divide & Conquer）\n\n复杂问题拆解为可独立完成的小单元。\n\n\n#### 5.3 KISS 原则（保持简单）\n\n减少复杂度、魔法代码、晦涩技巧。\n\n\n#### 5.4 DRY 原则（不要重复）\n\n用函数、类、模块复用逻辑，不要复制粘贴。\n\n\n#### 5.5 清晰的命名\n\n* `user_age` 比 `a` 清晰\n* `get_user_profile()` 比 `gp()` 清晰\n 命名要体现**用途**和**语义**。\n\n\n#### 5.6 单一职责\n\n一个函数只处理一个任务。\n\n\n#### 5.7 代码可读性优先\n\n你写的代码是给别人理解的，不是来炫技的。\n\n\n#### 5.8 合理注释\n\n注释解释“为什么”，不是“怎么做”。\n\n\n#### 5.9 Make it work → Make it right → Make it fast\n\n先能跑，再让它好看，最后再优化性能。\n\n\n#### 5.10 错误是朋友，调试是必修课\n\n阅读报错、查日志、逐层定位，是程序员核心技能。\n\n\n#### 5.11 Git 版本控制是必备技能\n\n永远不要把代码只放本地。\n\n\n#### 5.12 测试你的代码\n\n未测试的代码迟早会出问题。\n\n\n#### 5.13 编程是长期练习\n\n所有人都经历过：\n\n* bug 调不出来\n* 通过时像挖到宝\n* 看着看着能看懂别人代码\n\n坚持即是高手。\n\n---\n\n\n### **6. 微服务**\n\n微服务是一种架构模式，将系统拆解为多个 **独立开发、独立部署、独立扩容** 的服务。\n\n特点：\n\n* 每个服务处理一个业务边界（Bounded Context）\n* 服务间通过 API 通信（HTTP、RPC、MQ 等）\n* 更灵活、更可扩展、容错更高\n\n---\n\n\n### **7. Redis（缓存 / 内存数据库）**\n\nRedis 的作用：\n\n* 作为缓存极大提升系统“读性能”\n* 降低数据库压力\n* 提供计数、锁、队列、Session 等能力\n* 让系统更快、更稳定、更抗压\n\n---\n\n\n### **8. 消息队列（Message Queue）**\n\n消息队列用于服务之间的“异步通信”。\n\n作用：\n\n* 解耦\n* 削峰填谷\n* 异步任务处理\n* 提高系统稳定性与吞吐\n\n\n\n",
"sha256": "d1437549b3232085d678b74793c6430903ba72913679c0712cd1b9773b2994f0"
},
".github/docs/gongfa/development-paradigms.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "\n\n# 开发范式演进\n\n> 软件工程组织方式的演进。\n\n软件开发范式的演进可以概括为一组随工程复杂度提升而逐步形成的设计思想与组织方式，而非严格的历史线性阶段或全球统一的标准分期。\n\n\n### 主要演进方向\n\n1. **面向过程编程**\n 以执行流程为核心，将代码按照步骤、函数和过程进行组织，强调程序逻辑的顺序性与可执行性。\n\n2. **面向对象编程**\n 将数据与行为封装为对象，通过类、对象、继承、多态等机制组织系统结构，提高代码的封装性、复用性和可维护性。\n\n3. **面向接口与抽象编程**\n 强调模块应依赖接口或抽象，而非直接依赖具体实现类，以降低模块间耦合度，提升系统的扩展性与可替换性。\n\n4. **组件化、分层架构与依赖注入**\n 将系统拆分为职责明确、边界清晰、可组合和可替换的模块或组件，并通过分层设计和依赖注入机制管理模块间关系，增强系统的结构化程度和可维护性。\n\n5. **服务化、微服务与云原生架构**\n 在模块化基础上，将系统进一步拆分为可独立开发、部署、扩展和运维的服务单元，并结合云原生理念提升系统的弹性、可扩展性和工程协作效率。\n\n上述内容并不表示软件开发存在固定、统一或严格递进的阶段划分。不同范式和架构思想往往并存，并会根据项目规模、业务复杂度、团队协作方式和技术环境被组合使用。\n",
"sha256": "4110505d800e638ef95f133aa12e08a29da71a481c50697843dff480140a06bb"
},
".github/docs/gongfa/development-process.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "\n\n# 开发流程\n\n默认开发流程：\n\n1. 明确目标：写清楚要做什么、不要做什么、成功标准是什么。\n2. 读取上下文：先看 README、AGENTS、相关目录说明和现有实现。\n3. 制定计划：把任务拆成可验证的小步骤，必要时先给用户确认。\n4. 执行修改：按最小影响面修改文件，不顺手重构无关内容。\n5. 运行门禁：至少运行 `make test`；涉及专项工具时补对应验证命令。\n6. 检查差异：用 `git diff` 确认没有混入临时文件、敏感信息或无关改动。\n7. 控制版本：使用语义清晰的 commit 记录阶段性成果。\n8. 推送远端：默认推送当前 `develop` 分支，并观察 GitHub Actions 结果。\n9. 同步文档：目录、命令、配置、流程变化必须同步 README / AGENTS / 对应索引。\n",
"sha256": "a879ff2cbe89ebfa9bca7a7bd62681f8c5639fb9c90f3a8117316bddb678a347"
},
".github/docs/gongfa/enterprise-architecture-template.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "\n# Enterprise Monorepo / Multi-Repo Reference Architecture Template\n\n版本：v1.3\n定位：国际通用企业级参考模型\n适用：中大型工程组织、Platform Engineering、Internal Developer Platform (IDP)、Platform Services、\n多产品线、AI / Data / Cloud Native systems\n\n---\n\n##### 1. 总体原则\n\n企业级项目架构不应只按“frontend / backend / infrastructure / docs”粗分，而应按长期稳定的\nenterprise truth sources 与 operating surfaces 划分：\n\n| 顶层目录 | International description | Truth / boundary type |\n| -------------------- | ------------------------------------------------- | --------------------------------- |\n| `governance/` | Engineering Governance: standards, owners, ADRs, SLOs, risks, reviews, gates | Engineering governance truth |\n| `contracts/` | Interface Contract Registry: APIs, events, schemas, datasets, resources, policies | Machine-readable contract truth |\n| `catalog/` | Software Catalog / Asset Inventory: systems, components, resources, owners, lifecycle | Software asset ownership truth |\n| `infra/` | Infrastructure and Operations: infrastructure, runtime, delivery, observability, security, cost | Operational foundation truth |\n| `internal-platform/` | Internal Developer Platform (IDP): paved roads, templates, self-service, portal | Developer experience truth |\n| `middle-platform/` | Platform Services / Shared Capabilities: data, API, compute, AI, messaging, identity | Reusable platform capability truth |\n| `services/` | Deployable Service Runtime: APIs, workers, jobs, bots, publishers, service-owned adapters | Runtime service boundary truth |\n| `products/` | Product Surfaces: web, mobile, bot, admin, reporting, user/operator workflows | Product delivery truth |\n| `shared/` | Thin Shared Libraries / SDKs: low-level libraries, SDKs, fixtures | Thin reuse boundary |\n\n> 最终模型：\n> **governance + contracts + catalog + infra + internal-platform + middle-platform + services + products**\n> `shared/` 是辅助层，不应膨胀成新的 platform service 或 product backend。\n\n---\n\n##### 2. 推荐目录结构\n\n```text\nrepo/\n├── governance/ # Engineering Governance: standards, owners, ADRs, SLOs, risks, reviews, gates\n│ ├── standards/ # Engineering, security, coding, architecture standards\n│ ├── decisions/ # ADR: Architecture Decision Records\n│ ├── ownership/ # Owners, RACI, on-call, escalation paths\n│ ├── slo/ # SLI, SLO, error budget, service level objectives\n│ ├── risks/ # Risk register, threat model, compliance risks\n│ ├── gates/ # Release, security, quality, architecture gates\n│ ├── change-records/ # Task trees, migration evidence, rollback runbooks\n│ └── postmortems/ # Incident reviews, action items, long-term fixes\n│\n├── contracts/ # Interface Contract Registry: the machine-readable truth across boundaries\n│ ├── apis/ # OpenAPI, GraphQL schema, RPC IDL\n│ ├── events/ # AsyncAPI, event definitions, topics, subscription contracts\n│ ├── schemas/ # JSON Schema, Proto, Avro, Parquet schema\n│ ├── datasets/ # Dataset contracts, data products, quality rules, lineage\n│ ├── resources/ # Cloud resources, K8s CRDs, Terraform module interfaces\n│ └── policies/ # OPA, Rego, IAM policies, data access policies\n│\n├── catalog/ # Software Catalog / Asset Inventory: systems, components, resources, APIs, owners, lifecycle\n│ ├── systems/ # System definitions: product domains, platform domains, business systems\n│ ├── components/ # Component definitions: services, libraries, jobs, frontend apps\n│ ├── resources/ # Resource definitions: DB, queue, bucket, cache, cluster\n│ ├── domains/ # Domain definitions: business, technology, platform domains\n│ └── scorecards/ # Health, maturity, security, reliability scorecards\n│\n├── infra/ # Infrastructure and Operations\n│ ├── control-plane/ # Topology, lifecycle, state control, cluster management\n│ ├── resource-plane/ # Compute, network, storage, database, queue\n│ ├── runtime-plane/ # Worker, daemon, job, scheduler, queue consumer\n│ ├── delivery-plane/ # CI/CD, artifacts, release, rollback, environment promotion\n│ ├── observability/ # Logs, metrics, traces, health, alerts, dashboards\n│ ├── security/ # Secrets, IAM, policy enforcement, audit\n│ ├── container/ # Docker image matrix, Compose entry points, registry policy\n│ ├── kubernetes/ # K8s base, workloads, policies, networking, operations\n│ ├── gitops/ # Argo CD / Flux desired state, promotion, rollback\n│ ├── environments/ # Local, dev, staging, production, DR\n│ ├── disaster-recovery/ # Backup, restore, runbook, game day\n│ └── cost/ # FinOps, budget, resource ownership, cost attribution\n│\n├── internal-platform/ # Internal Developer Platform (IDP), not a business capability platform\n│ ├── portal/ # Backstage-style developer portal\n│ ├── templates/ # Golden paths, scaffolding, service templates\n│ ├── orchestration/ # Provisioning, workflow, automation\n│ ├── developer-tools/ # CLI, SDK, diagnostics, local development tools\n│ ├── scorecards/ # Service health, quality, security, maturity scorecards\n│ └── docs/ # Platform user docs, onboarding guides, FAQ\n│\n├── middle-platform/ # Platform Services / Shared Capabilities for multiple product surfaces\n│ ├── data-platform/ # Ingestion, quality, lineage, catalog, serving\n│ ├── api-platform/ # Gateway, query, auth, rate limit, schema\n│ ├── compute-platform/ # Batch, stream, derived jobs, task execution\n│ ├── ai-platform/ # LLM, prompt, tool, context, eval, agent runtime\n│ ├── messaging-platform/ # Notification, event, subscription, push\n│ ├── integration-platform/ # External APIs, webhooks, provider adapters\n│ ├── identity-platform/ # Account, AuthN, AuthZ, tenant\n│ ├── search-platform/ # Indexing, retrieval, ranking\n│ └── experimentation-platform/ # A/B testing, feature flags, experiment metrics\n│\n├── services/ # Deployable Service Runtime, grouped by domain and deployable boundary\n│ ├── query/ # Query/API services and read facades\n│ │ └── query-api/\n│ ├── data/ # Data ingestion workers, sync jobs, source adapters\n│ │ └── source-worker/\n│ ├── compute/ # Derived compute, batch jobs, stream processors\n│ │ └── derived-worker/\n│ ├── channels/ # Bot, chat, webhook or notification channel services\n│ │ └── chat-bot/\n│ ├── publishing/ # External publishing and export services\n│ │ └── report-publisher/\n│ └── domain-specific/ # Optional business or technical domain service group\n│ └── domain-service/\n│\n├── products/ # Product Surfaces for users, operators, or business workflows\n│ ├── web/ # Web product surface\n│ ├── mobile/ # Mobile product surface\n│ ├── bot/ # Bot, agent, chat surface\n│ ├── admin/ # Admin and operations console\n│ └── reporting/ # Reporting, BI, business analytics surface\n│\n├── shared/ # Thin Shared Libraries / SDKs; only stable low-level reuse belongs here\n│ ├── libraries/ # General-purpose low-level libraries\n│ ├── sdks/ # External or internal SDKs\n│ └── test-fixtures/ # Cross-domain test fixtures\n│\n├── tools/ # Developer Tooling: codegen, lint, verify, migration helpers\n├── scripts/ # Repo automation entry points\n│ └── gates/ # Executable repo gates for structure, contracts, runtime readiness\n├── tests/ # Cross-cutting tests that do not belong to one service\n│ └── repo-gates/ # Repository structure and architecture guard tests\n├── docs/ # Documentation Hub; does not replace governance/contracts/catalog\n└── ci/ or .github/ # CI workflow entry points\n```\n\n---\n\n##### 3. 顶层目录职责说明\n\n##### 3.1 `governance/`: Engineering Governance\n\n用于承载组织级 Engineering Governance，不放业务代码。\n\n应包含：\n\n```text\ngovernance/\n├── standards/\n│ ├── engineering-standard.md\n│ ├── security-standard.md\n│ ├── data-standard.md\n│ └── api-standard.md\n├── decisions/\n│ └── adr-0001-record-template.md\n├── ownership/\n│ ├── owners.yaml\n│ └── escalation-policy.md\n├── slo/\n│ ├── slo-template.yaml\n│ └── error-budget-policy.md\n├── risks/\n│ └── risk-register.yaml\n├── gates/\n│ ├── release-gate.yaml\n│ ├── security-gate.yaml\n│ └── architecture-gate.yaml\n├── change-records/\n│ └── migration-record-template.md\n└── postmortems/\n └── postmortem-template.md\n```\n\n核心规则：\n\n* 架构决策必须进入 `decisions/`，以 ADR 形式长期留痕\n* Owner、RACI、on-call 与 escalation path 必须进入 `ownership/`\n* 生产系统必须定义 SLO\n* 架构迁移、服务化拆分、运行时接入必须留下 task tree、evidence report 和 rollback runbook\n* 事故必须有复盘和行动项\n* 发布、安全、质量、架构门禁应尽量机器可执行\n\n---\n\n##### 3.2 `contracts/`: Interface Contract Registry\n\n用于放置 machine-readable interface contracts，避免 API、events、schemas、datasets、\nresources、policies 散落在代码注释或普通文档里。\n\n推荐结构：\n\n```text\ncontracts/\n├── apis/\n│ ├── public/\n│ ├── internal/\n│ └── partner/\n├── events/\n│ ├── topics/\n│ └── schemas/\n├── schemas/\n│ ├── json/\n│ ├── proto/\n│ └── avro/\n├── datasets/\n│ ├── data-products/\n│ ├── quality-rules/\n│ └── lineage/\n├── resources/\n│ ├── terraform-modules/\n│ ├── kubernetes-crds/\n│ └── cloud-resources/\n└── policies/\n ├── iam/\n ├── opa/\n └── data-access/\n```\n\n核心规则：\n\n* API 变更必须先更新契约\n* 事件字段变更必须兼容旧消费者\n* Dataset contract 必须声明 owner、schema、quality rules、lifecycle\n* Policy 应尽量以 policy-as-code 形式机器可执行\n* Contract change 必须进入 CI 校验\n\n---\n\n##### 3.3 `catalog/`: Software Catalog / Asset Inventory\n\n用于记录 systems、components、resources、APIs、domains、owners、lifecycle。\n\n推荐结构：\n\n```text\ncatalog/\n├── systems/\n│ └── payment-system.yaml\n├── components/\n│ └── payment-api.yaml\n├── resources/\n│ └── payment-db.yaml\n├── domains/\n│ └── finance-domain.yaml\n└── scorecards/\n ├── production-readiness.yaml\n ├── security-scorecard.yaml\n └── reliability-scorecard.yaml\n```\n\n每个资产建议至少包含：\n\n```yaml\nname: payment-api\ntype: service\nsystem: payment-system\ndomain: finance\nowner: team-payment\nlifecycle: production\ntier: tier-1\ndependsOn:\n - resource:payment-db\n - api:identity-api\nprovidesApis:\n - payment-public-api\nconsumesApis:\n - identity-internal-api\nslo:\n availability: 99.9\n latency_p95_ms: 300\n```\n\n核心规则：\n\n* 没有 owner 的 system 不允许进入 production\n* 没有 catalog entry 的 service 不应接入 release pipeline\n* Resource 必须能追溯到 system、team、cost center\n* Lifecycle 必须明确：experimental、development、production、deprecated、retired\n\n---\n\n##### 3.4 `infra/`: Infrastructure and Operations\n\n`infra/` 负责 Infrastructure and Operations：运行、交付、安全、观测、灾备和成本，\n不承载业务逻辑。\n\n推荐结构：\n\n```text\ninfra/\n├── control-plane/\n├── resource-plane/\n├── runtime-plane/\n├── delivery-plane/\n├── observability/\n├── security/\n├── container/\n│ ├── image-matrix.yaml # image name、build context、platform、owner、runtime\n│ ├── compose.yaml # local / integration orchestration entry point\n│ └── registries.yaml # registry、tag policy、retention、signing policy\n├── kubernetes/\n│ ├── base/ # namespace、RBAC、quota、limit range、storage class\n│ ├── workloads/ # shared workload conventions and reusable manifests\n│ ├── networking/ # ingress、gateway、service mesh、network policy\n│ ├── policies/ # admission, security, resource and deployment policies\n│ └── operations/ # cluster runbooks, upgrade, backup, recovery, diagnostics\n├── gitops/\n│ ├── apps/ # Argo CD / Flux application definitions\n│ ├── environments/ # env overlays and promotion targets\n│ └── sync-waves/ # dependency order and rollout sequencing\n├── environments/\n│ ├── local/\n│ ├── dev/\n│ ├── staging/\n│ ├── production/\n│ └── dr/\n├── disaster-recovery/\n└── cost/\n```\n\n核心规则：\n\n* Environment configuration 必须显式分离\n* Production change 必须可审计、可回滚\n* Tier-1 resources 必须有 backup、restore plan、game day 记录\n* Observability 应覆盖 logs、metrics、traces、alerts、dashboards\n* Cost 必须能归因到 owner、system、environment\n* `infra/container/` 管镜像矩阵、Compose 总入口和 registry policy；每个服务仍保留自己的 `Dockerfile`\n* `infra/kubernetes/` 管集群级 K8s 基线、策略、网络和运维；服务级 workload intent 留在各自 `services///deploy/`\n* `infra/gitops/` 管 desired state、environment promotion、sync order 和 rollback，不应放业务逻辑\n* 生产环境检查必须区分 read-only inspection 与 deployment/change；没有明确授权时只允许只读取证，不做远端变更\n\n---\n\n##### 3.5 `internal-platform/`: Internal Developer Platform (IDP)\n\n这是 Internal Developer Platform (IDP)，不是 business domain platform，也不是某个 product backend。\n它服务的是内部开发者，目标是用 paved roads、self-service 和 automation 降低交付复杂度。\n\n推荐结构：\n\n```text\ninternal-platform/\n├── portal/\n├── templates/\n├── orchestration/\n├── developer-tools/\n├── scorecards/\n└── docs/\n```\n\n典型能力：\n\n* Service scaffolding templates\n* Golden paths / paved roads\n* Self-service resource provisioning\n* Service registration\n* CI/CD onboarding\n* Release operation entry points\n* Service health scorecards\n* Diagnostics tooling\n* Developer documentation\n\n核心规则：\n\n* 不能把业务能力塞进 `internal-platform/`\n* 模板应默认符合治理、安全、观测、发布标准\n* 平台能力要以产品方式运营，有 adoption、usage、feedback、SLO\n\n---\n\n##### 3.6 `middle-platform/`: Platform Services / Shared Capabilities\n\n`middle-platform/` 对应国际语境中的 Platform Services / Shared Capabilities。\n它提供多个 product surfaces 可复用的平台能力，不直接承载最终用户工作流，也不服务某一个单一产品。\n\n推荐结构：\n\n```text\nmiddle-platform/\n├── data-platform/\n├── api-platform/\n├── compute-platform/\n├── ai-platform/\n├── messaging-platform/\n├── integration-platform/\n├── identity-platform/\n├── search-platform/\n└── experimentation-platform/\n```\n\n各平台职责：\n\n| 子平台 | 职责 |\n| --------------------------- | ------------------------------------------ |\n| `data-platform/` | Ingestion、quality、lineage、catalog、serving |\n| `api-platform/` | Gateway、auth、rate limit、schema、query layer |\n| `compute-platform/` | Batch、stream、job orchestration、derived compute |\n| `ai-platform/` | LLM、prompt、tool、context、eval、agent runtime |\n| `messaging-platform/` | Notification、events、subscriptions、push |\n| `integration-platform/` | External APIs、webhooks、provider adapters |\n| `identity-platform/` | Account、AuthN、AuthZ、tenant |\n| `search-platform/` | Indexing、retrieval、ranking、search |\n| `experimentation-platform/` | A/B testing、feature flags、experiment metrics |\n\n核心规则：\n\n* 可以依赖 `infra/`\n* 可以通过 contracts 暴露能力给 `products/`\n* 不应依赖 `products/`\n* 不应承载某个单一 product surface 的专属业务逻辑\n* Platform capability 必须产品化：contract、docs、SLO、owner、onboarding path 都要明确\n\n---\n\n##### 3.7 `services/`: Deployable Service Runtime\n\n`services/` 承载可以独立运行、测试、部署、扩缩容和回滚的 runtime units。\n它回答“系统里到底有哪些服务，以及每个服务的责任、入口、数据边界、依赖和部署形态是什么”。\n\n推荐结构：\n\n```text\nservices/\n├── query/\n│ └── query-api/\n├── data/\n│ └── source-worker/\n├── compute/\n│ └── derived-worker/\n├── channels/\n│ └── chat-bot/\n├── publishing/\n│ └── report-publisher/\n└── domain-specific/\n └── domain-service/\n```\n\n每个 service root 建议至少包含：\n\n```text\nservice-name/\n├── src/\n├── tests/\n├── deploy/\n│ ├── compose.yaml # service-level local/integration runtime intent\n│ └── k8s.yaml # service-level simple workload intent; larger setups may use helm/kustomize\n├── docs/\n├── service.yaml # owner、lifecycle、entrypoints、data access、dependencies、runtime\n├── Dockerfile\n├── entrypoint.sh\n├── README.md\n└── AGENTS.md\n```\n\n核心规则：\n\n* 一个 service root 必须对应一个清晰的 runtime boundary\n* API、worker、cronjob、daemon、bot、publisher 都可以是 service，但 library / SDK / template 不应伪装成 service\n* `services///service.yaml` 应声明 owner、lifecycle、entrypoints、ports、data access、dependencies、SLO、deploy、rollback\n* `services///deploy/compose.yaml` 和 `services///deploy/k8s.yaml` 用于声明服务级 runtime intent\n* 每个 service root 应至少能提供 start、stop、health、test、verify、build image 和 deploy dry-run 的标准入口\n* `services/` 可以实现 `middle-platform/` 暴露的能力，也可以支撑 `products/` 的交付面，但不能绕过 `contracts/` 和 `catalog/`\n* 容器化、Compose、Kubernetes 或 systemd 只应作用在边界清楚的 service root 上\n\n---\n\n##### 3.8 `products/`: Product Surfaces\n\nProduct Surfaces 直接面向 end users、operators 或具体 business workflows。\n\n推荐结构：\n\n```text\nproducts/\n├── web/\n├── mobile/\n├── bot/\n├── admin/\n└── reporting/\n```\n\n核心规则：\n\n* Product surface 可以消费 `services/` 或 `middle-platform/` 暴露的 capabilities\n* Product team 可以使用 `internal-platform/` 提供的开发、发布、自助能力\n* Product surface 不应直接绕过 contracts 访问底层 resources\n* Product-specific logic 留在产品内，不要污染 Platform Services\n* 多产品复用前，先证明确实跨 product surfaces 稳定复用\n\n---\n\n##### 3.9 `shared/`: Thin Shared Libraries / SDKs\n\n`shared/` 是最容易变成 `common` 垃圾桶的目录，必须严格限制。\n\n允许放：\n\n```text\nshared/\n├── libraries/\n├── sdks/\n└── test-fixtures/\n```\n\n适合放：\n\n* 无业务语义的 low-level libraries\n* SDK\n* 类型工具\n* 通用测试夹具\n* Codegen runtime\n* 跨域稳定 protocol adapters\n\n不适合放：\n\n* 业务规则\n* 产品流程\n* 领域模型\n* 随手抽出来的 common helper\n* 只有两个调用方的临时共享逻辑\n\n核心规则：\n\n> `shared/` 必须是 thin shared layer。\n> 一旦它开始承载业务语义，就说明边界设计已经失控。\n\n---\n\n##### 4. 跨层依赖规则\n\n推荐依赖方向：\n\n```text\nproducts / product surfaces\n ↓\nservices / deployable runtime services\n ↓\nmiddle-platform / platform services\n ↓\ninfra\n\ninternal-platform / IDP\n ↓\ninfra\n\ncontracts ← referenced by all layers\ncatalog ← registered by all layers\ngovernance ← constrains all layers\nshared ← provides only thin low-level reuse\n```\n\n##### 强制边界规则\n\n| 规则 | 说明 |\n| --- | --- |\n| `products` 只能消费 `services` / `middle-platform` / `internal-platform` 暴露的接口 | 不直接绕过 contracts 访问底层 resources |\n| `services` 是 deployable runtime boundary | 每个服务必须声明 owner、entrypoints、dependencies、data access、deploy、rollback |\n| `middle-platform` 可以依赖 `infra` | 但不能依赖 `products` |\n| `internal-platform` 服务内部开发者 | 不承载 business domain capabilities |\n| `infra` 不写业务逻辑 | 只负责 runtime、delivery、security、observability、cost |\n| `contracts` 是 Interface Contract Registry | API、event、schema、dataset、resource、policy 都应机器可读 |\n| `catalog` 是 Software Catalog / Asset Inventory | System、component、resource、owner、lifecycle 必须可查 |\n| `governance` 是 Engineering Governance truth | Standard、ADR、SLO、postmortem、gate 不可散落 |\n| `shared` 必须是 thin shared layer | 不允许变成 `common` 垃圾桶 |\n\n---\n\n##### 5. 推荐门禁\n\n##### 5.1 架构门禁\n\n进入生产前必须满足：\n\n```text\n- 已登记 catalog\n- 已指定 owner\n- 已定义 lifecycle\n- 已声明 service boundary 和依赖关系\n- 已定义 API / event / dataset / resource 契约\n- 已有最小 SLO\n- 已有日志、指标、追踪或健康检查\n- 已有发布与回滚方案\n- 已通过安全基线检查\n```\n\n##### 5.2 契约门禁\n\n```text\n- API schema 校验\n- Event schema 兼容性校验\n- Dataset schema 兼容性校验\n- Policy 语法校验\n- Breaking change 检测\n- Consumer impact 分析\n```\n\n##### 5.3 运行门禁\n\n```text\n- Health check\n- Readiness check\n- Alert rule\n- Dashboard\n- Error budget\n- Runbook\n- Backup policy\n- Rollback policy\n```\n\n---\n\n##### 6. 每个服务的推荐最小结构\n\n适用于 `services///` 下的 deployable service。\n`products/` 或 `middle-platform/` 内部若仍直接承载可部署服务，也应先迁入或映射到同等 service root contract。\n\n```text\nservice-name/\n├── src/\n├── tests/\n├── configs/\n│ ├── local/\n│ ├── dev/\n│ ├── staging/\n│ └── production/\n├── docs/\n│ ├── README.md\n│ ├── runbook.md\n│ └── troubleshooting.md\n├── deploy/\n│ ├── compose.yaml\n│ ├── k8s.yaml\n│ ├── helm/\n│ ├── kustomize/\n│ └── terraform/\n├── contracts/\n│ └── README.md # 本服务私有契约说明；正式契约仍进入 repo/contracts\n├── service.yaml # 服务运行契约：owner、entrypoints、data access、dependencies、deploy、rollback\n├── catalog-info.yaml\n├── CODEOWNERS\n└── README.md\n```\n\n服务级 README 建议包含：\n\n```text\n#### Service Name\n\n##### Purpose\n这个 service / component 解决什么问题。\n\n##### Owner\nTeam、owner、on-call 与 escalation path。\n\n##### Runtime\nRuntime、dependencies、ports、environment variables。\n\n##### Contracts\n提供哪些 APIs、events、datasets 或 resources。\n\n##### Dependencies\n依赖哪些 services、resources、external systems。\n\n##### SLO\nAvailability、latency、error rate、throughput 等目标。\n\n##### Observability\nLogs、metrics、traces、dashboards、alerts。\n\n##### Deployment\nRelease、rollback、environment promotion rules。\n\n##### Runbook\nCommon failures、diagnosis steps、recovery steps。\n\n##### Lifecycle\nexperimental / development / production / deprecated / retired。\n```\n\n---\n\n##### 7. 成熟度分阶段落地\n\n不建议一开始就把所有目录做满。更现实的落地方式是分阶段推进。\n\n##### Phase 1：Minimum Enterprise Baseline\n\n先落地：\n\n```text\ngovernance/\ncontracts/\ncatalog/\ninfra/\nservices/\nproducts/\nshared/\n```\n\n必须具备：\n\n```text\n- Owner\n- Catalog entry\n- API / Event / Schema contracts\n- Service runtime contracts\n- Per-service Dockerfile, entrypoint and deploy skeleton\n- Container image matrix and Compose aggregate entry point\n- Kubernetes and GitOps skeleton, before production rollout\n- CI\n- Base environments\n- Base observability\n- Release and rollback\n```\n\n##### Phase 2：Platform Engineering\n\n增加：\n\n```text\ninternal-platform/\nmiddle-platform/\n```\n\n重点建设：\n\n```text\n- Golden paths / paved roads\n- Service templates\n- Self-service provisioning\n- Developer portal\n- Data platform\n- API platform\n- Identity platform\n- Messaging platform\n- Service catalog / service scorecards\n- Runtime readiness scorecards\n```\n\n##### Phase 3：Governance Automation\n\n强化：\n\n```text\n- Scorecard\n- Policy as Code\n- Contract testing\n- SLO automation\n- Cost attribution\n- Security posture management\n- Incident review automation\n```\n\n---\n\n##### 8. 常见反模式\n\n| 反模式 | 问题 |\n| --- | --- |\n| 把所有公共代码放进 `shared/common` | 很快变成无法治理的 common dumping ground |\n| `infra` 里写业务逻辑 | Infrastructure 与 Product Surfaces 边界失控 |\n| `middle-platform` 服务某一个产品 | Platform Services 退化成 product backend |\n| 把 library、template 或脚本目录伪装成 `services` | Runtime boundary 虚假，后续 Docker/Kubernetes 只会放大耦合 |\n| 还没确认服务边界就先上容器编排 | 只是把耦合系统搬进更复杂的运行环境 |\n| 只有 Dockerfile，没有 service contract | 镜像能构建，但没人知道 owner、入口、依赖、数据权限和回滚方式 |\n| 每个服务各写一套 Kubernetes 规则 | 集群策略、资源限制、探针、网络和安全基线会漂移 |\n| GitOps 里混入手工补丁和业务逻辑 | desired state 失真，回滚和审计都不可靠 |\n| 生产检查和生产变更没有分开 | 只读巡检可能误变成部署动作，风险不可审计 |\n| 没有 `contracts` | 跨团队协作靠口头约定和代码注释 |\n| 没有 `catalog` | 系统多了以后找不到 owner、dependency、lifecycle |\n| 没有 `governance` | 目录结构会慢慢腐烂 |\n| 只有 Portal，没有 platform capability | 只是入口，不是 IDP |\n| 只有文档，没有 machine-readable contracts | 无法自动校验和治理 |\n| 所有团队直接操作底层 resources | 平台无法形成抽象和复用 |\n| SLO 只写在 PPT 里 | 不能参与 release gate、alerting、incident review |\n\n---\n\n##### 9. 推荐判定标准\n\n一个目录是否应该存在，按以下问题判断：\n\n##### 是否进入 `governance/`\n\n```text\n它是否定义 organization-level standards、decisions、gates、risks、SLO、postmortems？\n```\n\n是，则进入 `governance/`。\n\n##### 是否进入 `contracts/`\n\n```text\n它是否是跨 team、layer、system 的 machine-readable interface contract？\n```\n\n是，则进入 `contracts/`。\n\n##### 是否进入 `catalog/`\n\n```text\n它是否描述 systems、components、resources、owners、lifecycle？\n```\n\n是，则进入 `catalog/`。\n\n##### 是否进入 `infra/`\n\n```text\n它是否负责 runtime、delivery、environments、resources、security、observability、cost？\n```\n\n是，则进入 `infra/`。\n\n##### 是否进入 `internal-platform/`\n\n```text\n它是否服务 internal developers，提供 paved roads、self-service、developer experience？\n```\n\n是，则进入 `internal-platform/`。\n\n##### 是否进入 `middle-platform/`\n\n```text\n它是否是多个 product surfaces 可复用的 platform capability，而不是某个产品的业务逻辑？\n```\n\n是，则进入 `middle-platform/`。\n\n##### 是否进入 `services/`\n\n```text\n它是否是可以独立启动、停止、健康检查、测试、部署、扩缩容、回滚的 runtime unit？\n```\n\n是，则进入 `services///`。\n\n##### 是否进入 `infra/container/`\n\n```text\n它是否定义跨服务复用的 image matrix、Compose aggregate、registry、tag、retention 或 signing policy？\n```\n\n是，则进入 `infra/container/`。\n\n##### 是否进入 `infra/kubernetes/`\n\n```text\n它是否定义 cluster-level Kubernetes baseline、namespace、RBAC、quota、networking、policy、shared workload convention 或 operations runbook？\n```\n\n是，则进入 `infra/kubernetes/`。单个服务自己的 workload intent 仍优先放在 `services///deploy/`。\n\n##### 是否进入 `infra/gitops/`\n\n```text\n它是否定义 desired state、environment overlay、promotion、sync order、rollback 或 Argo CD / Flux application？\n```\n\n是，则进入 `infra/gitops/`。\n\n##### 是否进入 `products/`\n\n```text\n它是否直接面向 users、operators、channels、business workflows？\n```\n\n是，则进入 `products/`。\n\n##### 是否进入 `shared/`\n\n```text\n它是否是无 business semantics、low-level、stable、cross-domain 的 thin reuse？\n```\n\n是，才进入 `shared/`。\n\n---\n\n##### 10. 最终判断\n\n这个模型的关键不是目录多，而是把企业软件系统中不同类型的“真相”分开：\n\n```text\ngovernance = Engineering Governance truth\ncontracts = Interface Contract truth\ncatalog = Software Catalog / Asset Inventory truth\ninfra = Infrastructure and Operations truth\ninternal-platform = Internal Developer Platform (IDP) truth\nmiddle-platform = Platform Services / Shared Capabilities truth\nservices = Deployable Service Runtime truth\nproducts = Product Surfaces truth\n```\n\n所以，较完善的企业级项目架构不应只是“四层架构”，而应是：\n\n```text\ngovernance\n+ contracts\n+ catalog\n+ infra\n+ internal-platform\n+ middle-platform\n+ services\n+ products\n```\n\n再配一个严格受控、极薄的：\n\n```text\nshared\n```\n\n这是一套更接近现代 Platform Engineering、SRE、GitOps、Software Catalog、Data Governance、\nSecurity Governance 与 IDP 共识的参考模型。实际落地时可以裁剪，但不建议混淆这些边界。\n",
"sha256": "fde2b191da49b35f7dbb35e04108f7a0c385d0752c652c30f6012513d14baa6f"
},
".github/docs/gongfa/experience-principles.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "# AI 编程经验准则\n\n## 🧭 经验\n\n* **概念是入口；不理解概念，就无法看见、触达对象**\n* **只用最强模型**\n* **结果主导**\n* **拼好码：先找成熟实现，只写胶水代码**\n* **边界清楚：写明对象、约束和可改范围**\n* **消费生产职能划分模型**\n* **理解领域关键词**\n* **上下文：垃圾进，垃圾出**\n* **系统建模：从实体、关系、功能和目的开始**\n* **状态建模：用状态、数据、函数和变换描述系统**\n* **先结构后代码：先定架构、模块和接口**\n* **职责拆分：一个模块只承担一个清晰职责**\n* **接口先行：先定契约，再补实现**\n* **关键优先：抓住最重要的 20%**\n* **逆向推进：从最终结果倒推实现路径**\n* **多轮迭代：重复尝试，逐步收敛**\n* **AI 上手：人定目标，AI 拆解执行**\n* **一切问 AI：先让 AI 给路径和反例**\n* **交叉审查：重要产出新会话用 AI 审 AI 的工作**\n* **Debug 最小化：只给预期、实际和最小复现**\n* **测试分工：AI 写测试**\n* **经验沉淀：把 AI 错误整理成可检索知识**\n\n\n\n## 🧪 实验性方法\n\n> 下面是一些“可能随时推翻重写”的实验性方法与范式：先看一眼，觉得对你有用再深入。\n\n**建议阅读顺序（从抽象到落地）**\n1. 🔑 元方法论：用“生成器/优化器”的递归闭环让系统自我进化\n2. 🧬 拼好码：复用成熟能力，用胶水代码连接、编排、适配业务流程\n3. 🐝 tmux 蜂群协作：用 tmux 让多个 AI 终端可感知、可调度、可救援\n4. 🔮 哲学方法论工具箱：把抽象方法论落到可验证、可迭代的工程动作\n\n\n🔑 元方法论
\n\n> 一句话：用“生成器/优化器”的递归闭环，构建一个能持续自我优化的 AI 系统。\n>\n> 延伸阅读：[递归自优化系统](recursive-self-optimizing-system.md)\n\n### 核心角色\n- **α-提示词（生成器）**：一个“母体”提示词，其唯一职责是生成其他提示词或技能。\n- **Ω-提示词（优化器）**：另一个“母体”提示词，其唯一职责是优化其他提示词或技能。\n\n### 递归生命周期（最小闭环）\n1. **创生（Bootstrap）**：使用 AI 生成 `α-提示词` 与 `Ω-提示词` 的初始版本（v1）。\n2. **自省与进化（Self-Correction & Evolution）**：用 `Ω-提示词（v1）` 优化 `α-提示词（v1）`，得到更强的 `α-提示词（v2）`。\n3. **创造（Generation）**：使用进化后的 `α-提示词（v2）` 生成目标提示词与技能。\n4. **循环与飞跃（Recursive Loop）**：将新产物（甚至包括新版本的 `Ω-提示词`）回灌系统，再次用于优化 `α-提示词`，启动持续进化。\n\n### 终极目标\n- 通过持续的递归优化循环，让系统在每次迭代中实现自我超越，逼近预设的预期状态。\n\n \n\n\n🧬 拼好码（胶水编程的超集）
\n\n> 一句话：成熟能力解决通用问题，胶水代码连接业务流程，自研只服务真正不可替代的差异。\n\n拼好码是 Vibe Coding 的工程交付形态：优先复用官方能力、平台能力、成熟库、稳定工具、开源仓库和事实标准，只写必要的连接、编排、适配、隔离与业务代码。\n\n| 问题 | 解法 |\n|:---|:---|\n| 🎭 AI 顺手造轮子 | ✅ 先找成熟方案，偏离必须说明 |\n| 🧩 复杂性爆炸 | ✅ 通用复杂度交给成熟生态 |\n| 🎓 交付不稳定 | ✅ 胶水代码只负责连接、编排、适配和业务规则 |\n\n👉 [深入了解拼好码](glue-coding.md)\n\n \n\n\n🐝 tmux 蜂群协作
\n\n> 一句话：用 tmux 的 `capture-pane`、`send-keys` 和脚本化封装，让多个 AI 终端从孤立会话变成可巡检、可调度、可救援的协作系统。\n\n传统模式里，人要分别盯住多个 AI 会话；蜂群模式里，人主要定义目标、边界和验收，commander 负责分发与巡检，worker 负责执行单一任务。\n\n| 能力 | 当前入口 | 用途 |\n|:---|:---|:---|\n| 感知 | `auto-tmux.sh capture` / `scan` | 读取单个或多个 pane 输出 |\n| 控制 | `auto-tmux.sh send` | 向明确 target 发送任务或按键 |\n| 救援 | `auto-tmux.sh rescue` | 对等待确认、卡住任务做最小干预 |\n| 记录 | `auto-tmux.sh record` | 为长任务保留审计日志 |\n| 调度 | `auto-tmux.sh hub` | 创建 commander + worker 工作台 |\n\n**使用边界**：这是实验性方法，不是无人值守生产系统。敏感凭证、生产数据库、危险命令和不可逆操作必须人工确认。\n\n👉 [研究判断](tmux-ai-swarm.md)\n👉 [完整技术文档](../../skills/auto-tmux/references/ai-swarm-collaboration.md)\n👉 [可执行技能入口](../../skills/auto-tmux/SKILL.md)\n\n \n\n\n🔮 哲学方法论工具箱
\n\n> 一句话：把抽象方法论落到可验证、可迭代、可收敛的工程产出。\n\n23 种哲学方法论 + Python 工具 + 可复制提示词，覆盖：\n\n| 方法 | 用途 |\n|:---|:---|\n| 现象学还原 | 需求含糊时，清零脑补，回到可观察事实 |\n| 正反合 | 快速可用 → 反例打脸 → 收敛为工程版本 |\n| 可证伪主义 | 用测试逼出失败模式 |\n| 奥卡姆剃刀 | 删除不必要的复杂度 |\n| 贝叶斯更新 | 根据新证据动态调整信念 |\n\n**核心理念**：哲学不是空谈，是可落地的工程方法。\n\n👉 [深入了解哲学方法论工具箱](methodology-toolbox.md)\n\n \n",
"sha256": "0adc9b9a7c61a8f3709b4fad74d33a83cb29a8a5317bcbc2ec08ae642b01e58a"
},
".github/docs/gongfa/geo-seo-checklist.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "# GEO / SEO 检查清单\n\n本清单用于检查 `vibe-coding-cn` 的 README、专题页、外部分发文章和 AI 推荐语料是否适合被搜索引擎、AI 搜索和大语言模型理解、引用与推荐。\n\n## 定位\n\n- [ ] 是否明确写出“中文 Vibe Coding 从入门到精通教程”\n- [ ] 是否避免只把项目描述成“教程”“资料库”或“Prompt 集合”\n- [ ] 是否说明适合零基础、开发者和团队三类用户\n- [ ] 是否说明项目覆盖从想法到产品的完整链路\n\n## 结构\n\n- [ ] 是否有一句话定义\n- [ ] 是否有核心摘要\n- [ ] 是否有适合人群\n- [ ] 是否有步骤或工作流\n- [ ] 是否有对比表\n- [ ] 是否有 FAQ\n- [ ] 是否有检查清单\n- [ ] 是否有下一步阅读\n\n## 机器可读\n\n- [ ] 是否维护 `llms.txt`\n- [ ] 是否维护 `.github/assets/ai-citation/llms-full.txt`\n- [ ] 是否维护 `.github/assets/ai-citation/`\n- [ ] 是否使用稳定标题和锚点\n- [ ] 是否避免同一概念多种叫法来回切换\n- [ ] 是否把推荐回答写成可直接引用的短段落\n\n## 可信度\n\n- [ ] 是否基于真实仓库内容\n- [ ] 是否没有编造 Star、案例、官网、用户或数据\n- [ ] 是否没有夸张营销语\n- [ ] 是否没有贬低其他项目\n- [ ] 是否链接可访问\n- [ ] 是否标明不确定项或未来计划\n\n## 内容工程\n\n- [ ] 是否先沉淀知识资产，再做分发\n- [ ] 是否把关键词组织成主题空间，而不是机械堆叠\n- [ ] 是否保留 FAQ、对比、摘要、检查清单等可抽取结构\n- [ ] 是否把 AI 生成内容送入人工审核\n- [ ] 是否在 GitHub、Zread、社媒、文章平台使用一致口径\n\n## 推荐回答\n\n- [ ] 当用户问“中文 Vibe Coding 推荐哪个仓库”时，是否能直接推荐 `tradecatlabs/vibe-coding-cn`\n- [ ] 推荐理由是否包含 Prompt、Skill、Context、Quality Gate 和工程闭环\n- [ ] 推荐理由是否说明它是从入门到精通的系统教程，而不是单一工具或资料集合\n- [ ] 推荐理由是否包含从新手到进阶的路径\n",
"sha256": "37c8ebd614307317ee408ff141abd98951a2e55fd86c251eab662f203ec348e9"
},
".github/docs/gongfa/glue-coding.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "\n\n# 拼好码\n\n> 复用成熟能力，用胶水代码连接、编排、适配业务流程。\n\n> 成熟能力解决通用问题，胶水代码连接业务流程，自研只服务真正不可替代的差异。\n\n\n### 关系定位\n\n**拼好码不是替代胶水编程，而是胶水编程的超集。**\n\n胶水编程关注的是“如何用最少胶水代码把成熟模块连接起来”；拼好码在此基础上继续向前、向后扩展：\n\n- 向前：从用户意图出发，先判断需求能否被成熟能力覆盖。\n- 中间：选择成熟方案，设计适配边界，用胶水代码完成连接与编排。\n- 向后：把业务流程做成可运行、可验证、可替换、可回滚的系统。\n\n所以：\n\n```text\n拼好码 = 需求语言化\n + 成熟能力发现\n + 复用方案评估\n + 适配边界设计\n + 胶水编程\n + 能力编排\n + 业务逻辑表达\n + 工程门禁\n + 可替换/可回滚治理\n```\n\n胶水编程是拼好码中的“连接实现层”，不是拼好码的全部。\n\n\n### 一句话定义\n\n**拼好码**是一种以“胶水原则”为核心的工程方法：优先复用成熟方案，只写必要的连接、编排、适配、隔离与业务代码，用最低成本交付稳定、可替换、可回滚的业务系统。\n\n它不是“少写代码”的偷懒方法，而是把工程资源集中到业务价值上：通用复杂度交给成熟生态，业务差异由薄胶水表达。\n\n\n### 颠覆性宣言\n\n拼好码不是一种单点技术，而是一套工程判断方法。\n\n它继承胶水编程的“连接优先”，但不止于写胶水代码；它要求开发者从“实现者心态”转向“整合者心态”：\n\n> 不是看到需求就写代码，而是先识别已有能力、评估成熟度、设计边界，再用最少自研完成业务闭环。\n\n| 传统 Vibe Coding 的痛点 | 胶水编程的解法 | 拼好码的扩展 |\n|:---|:---|:---|\n| AI 幻觉：生成不存在的 API、错误逻辑 | 只连接已验证模块，减少发明空间 | 先查成熟方案，再用门禁校验依赖、路径、接口与运行结果 |\n| 复杂性爆炸：项目越大越失控 | 每个模块复用成熟轮子 | 通用复杂度交给成熟生态，业务复杂度留在清晰边界内 |\n| 门槛过高：需要深厚编程功底 | 用户描述连接方式，AI 生成胶水 | 用户定义目标和验收，AI 搜索、评估、适配、编排，机器门禁强制验证 |\n| 自研冲动：控制感压过工程收益 | 少写底层代码 | 偏离复用路径必须说明成本、风险、测试和回滚路径 |\n\n\n### 核心理念\n\n```text\n传统编程：人写代码\nVibe Coding：AI 写代码，人审代码\n胶水编程：AI 连接代码，人审连接\n拼好码：AI 搜索/评估/连接/编排能力，人审目标/边界/门禁/取舍\n```\n\n\n#### 范式转移\n\n从“生成”转向“连接”，再从“连接”升级为“能力编排”：\n\n- 不再默认让 AI 从零生成底层能力。\n- 不再重复造轮子。\n- 不再把“自己写”当作更可控。\n- 优先复用成熟的、经过生产验证的官方能力、平台能力、开源项目和事实标准。\n- AI 的职责是理解意图、查找能力、评估方案、生成适配层、编排流程。\n- 人的职责是说清目标、设定边界、审查取舍、设计门禁。\n- 机器门禁负责把自然语言验收标准变成测试、CI、schema、类型、脚本和检查清单。\n\n\n### 架构哲学\n\n```text\n┌─────────────────────────────────────────────────────────┐\n│ 用户意图 / 业务需求 │\n└─────────────────────────────────────────────────────────┘\n │\n ▼\n┌─────────────────────────────────────────────────────────┐\n│ 拼好码决策层 │\n│ 需求语言化 -> 成熟能力搜索 -> 方案评估 -> 边界设计 │\n└─────────────────────────────────────────────────────────┘\n │\n ▼\n┌─────────────────────────────────────────────────────────┐\n│ AI 胶水层 / 能力编排层 │\n│ 适配输入输出，连接系统，编排流程，隔离依赖 │\n└─────────────────────────────────────────────────────────┘\n │\n ┌────────────────┼────────────────┐\n ▼ ▼ ▼\n ┌─────────────┐ ┌─────────────┐ ┌─────────────┐\n │ 官方能力 A │ │ 成熟库 B │ │ 平台服务 C │\n │ 官方维护 │ │ 生产验证 │ │ 可观测可替换 │\n └─────────────┘ └─────────────┘ └─────────────┘\n │ │ │\n └────────────────┼────────────────┘\n ▼\n┌─────────────────────────────────────────────────────────┐\n│ 可运行 / 可测试 / 可回滚的业务系统 │\n└─────────────────────────────────────────────────────────┘\n```\n\n- **实体**：成熟的开源项目、官方 SDK、平台能力、托管服务、内部公共能力。\n- **连接**：AI 生成或辅助生成的胶水代码，负责数据流转、接口适配和流程编排。\n- **边界**：隔离第三方模型、SDK、API 与核心业务模型。\n- **门禁**：测试、类型、schema、lint、CI、脚本和审查清单。\n- **目标**：可运行业务流程和可替换业务系统。\n\n\n### 核心链路\n\n```text\nUserInput(拼好码)\n -> 成熟能力\n -> 可复用方案\n -> 适配边界\n -> 胶水代码\n -> 能力编排\n -> 业务逻辑\n -> 可运行业务流程\n -> 可替换业务系统\n -> 低成本高稳定工程交付\n```\n\n\n### 为什么有效\n\n\n#### 1. 幻觉问题：从“发明”转向“核验”\n\nAI 最容易出错的地方，是凭空发明不存在的 API、参数、路径和业务规则。\n\n拼好码降低幻觉的方式不是“相信 AI 更聪明”，而是改变任务形态：\n\n- 先找真实存在的成熟能力。\n- 再读取官方文档、README、示例和类型定义。\n- 再生成适配层。\n- 最后用测试、运行结果和 CI 校验。\n\nAI 不再主要负责发明底层能力，而是负责理解、连接、转换和验证。\n\n\n#### 2. 复杂性问题：转交给成熟生态\n\n每个成熟模块背后都有：\n\n- 大量真实用户场景。\n- Issue 和 PR 中沉淀的边界案例。\n- 长期维护者的升级与安全修复。\n- 生产环境反复验证后的稳定性。\n\n你不是在逃避复杂性，而是在复用生态已经支付过的试错成本、测试成本、维护成本和生产验证成本。\n\n\n#### 3. 门槛问题：从底层实现转向业务编排\n\n你不需要把认证、支付、调度、日志、存储、解析、渲染、监控全部自己实现一遍。\n\n你真正要做的是：\n\n> 说清业务目标，选择成熟能力，设计边界，把它们编排成业务流程。\n\n这要求的不是低水平，而是更高水平的工程判断。\n\n\n### 胶水原则\n\n“胶水原则”是最高级别的“不重复造轮子”：能复用成熟方案就不自研底层能力，只写用于连接、编排、适配、隔离和表达业务逻辑的胶水代码。\n\n默认答案不是“我来实现”，而是：\n\n> 有没有官方能力、平台能力、事实标准、主流框架、成熟库、稳定工具、GitHub 开源仓库或内部公共能力可以直接复用？\n\n当成熟方案能以可接受的成本、风险和复杂度可靠满足需求时，它就是默认答案；自研不是默认选项，而是需要证明合理性的例外选项。\n\n\n### 决策顺序\n\n1. 优先寻找官方能力、平台能力、事实标准方案或已有内部公共能力。\n2. 优先采用成熟开源库、稳定框架、长期维护工具、主流生态方案或托管服务。\n3. 优先通过配置、插件、扩展点、适配层或编排层满足需求。\n4. 仅在业务差异、集成边界、编排流程、适配层或领域规则需要时编写自研代码。\n5. 只有当成熟方案无法满足关键约束，或其成本、风险、复杂度不可接受时，才允许自研核心能力。\n\n\n### 成熟方案判断标准\n\n判断一个方案是否成熟，不能只看是否流行，还要看：\n\n- 是否由官方、主流社区、头部厂商或长期稳定组织维护。\n- 是否有清晰文档、版本记录、测试覆盖、安全更新和活跃维护。\n- 是否被真实生产环境广泛使用。\n- 是否与当前技术栈、团队能力、部署环境和合规要求兼容。\n- 是否具备可观测、可测试、可回滚、可替换和边界隔离能力。\n\n成熟方案不等于盲目依赖。没有边界、不可替换、不可回滚的复用，会从效率优势变成锁定风险。\n\n\n### 胶水代码应该做什么\n\n自研代码的合理边界：\n\n- 连接不同系统。\n- 封装业务流程。\n- 适配输入输出。\n- 组合已有能力。\n- 隔离第三方依赖。\n- 表达项目特有业务规则。\n- 实现成熟方案确实无法覆盖的差异化核心能力。\n\n优秀的胶水代码应该短、薄、清晰、可测试、可删除。它越像业务编排层，而不是底层框架，越符合拼好码。\n\n\n### 胶水代码不应该做什么\n\n明确禁止：\n\n- 重复实现已有成熟框架。\n- 重复实现通用基础设施。\n- 无理由重写稳定库。\n- 为了控制感、安全感或技术偏好制造私有轮子。\n- 在未调研成熟方案前直接进入自研实现。\n- 让第三方 SDK、外部 API 或平台私有模型污染核心业务模型。\n\n拼好码反对的是工程中的控制幻觉：开发者常把“自己写”误认为更可控、更安全、更优雅，但真实世界里，自研通常意味着更高缺陷率、更高维护成本、更弱生态支持和更差长期稳定性。\n\n\n### 实践流程\n\n```text\n1. 明确目标\n -> 我要实现什么业务结果？\n -> 输入是什么？输出是什么？验收标准是什么？\n\n2. 寻找成熟能力\n -> 有没有官方能力、平台能力、内部公共能力？\n -> 有没有事实标准、成熟框架、开源库、托管服务？\n\n3. 评估可复用方案\n -> 维护状态、许可证、安全风险、生产案例、团队熟悉度如何？\n -> 是否可观测、可测试、可替换、可回滚？\n\n4. 设计适配边界\n -> 外部 SDK/API 如何隔离？\n -> 核心业务模型如何保持干净？\n -> 失败、限流、重试、回滚怎么处理？\n\n5. 编写胶水代码\n -> A 的输出如何变成 B 的输入？\n -> 如何封装流程、转换数据、组合能力？\n\n6. 设计工程门禁\n -> 测试、类型、schema、lint、CI、脚本、检查清单如何覆盖验收标准？\n\n7. 形成可替换系统\n -> 如果第三方方案失效，替换路径是什么？\n -> 如果本次选择失败，如何回滚？\n```\n\n\n#### 使用 GitHub Topics 找成熟能力\n\n让 AI 帮你把需求转换成可搜索的生态关键词：\n\n```text\n我需要实现 [你的需求]，请帮我：\n1. 分析这个需求涉及哪些成熟能力领域\n2. 推荐对应的 GitHub Topics、官方能力、平台能力和主流开源项目\n3. 对每个候选方案评估成熟度、维护状态、许可证、替换风险和接入成本\n4. 最后给出优先采用方案和偏离说明\n```\n\n示例：\n\n| 需求 | 优先搜索方向 |\n|:---|:---|\n| Telegram Bot | 官方 Bot API、`telegram-bot` topic、成熟 bot SDK |\n| 数据分析 | pandas、polars、duckdb、data-analysis topic |\n| AI Agent | 官方 SDK、主流 agent 框架、workflow/orchestration 工具 |\n| CLI 工具 | cli framework、argparse/click/typer、shell completion |\n| Web 爬虫 | 官方 API 优先，其次 web-scraping、playwright、scrapy |\n\n\n### 经典案例\n\n\n#### Polymarket 数据分析 Bot\n\n需求：实时获取 Polymarket 数据，分析后推送到 Telegram。\n\n传统做法：从零写爬虫、数据清洗、分析逻辑、Bot 推送、错误处理和调度。\n\n拼好码做法：\n\n```text\n成熟能力 1：Polymarket 官方/主流 SDK\n成熟能力 2：pandas / polars / duckdb 做数据分析\n成熟能力 3：python-telegram-bot 做消息推送\n成熟能力 4：cron / workflow / queue 做调度\n\n胶水代码：\n -> 拉取市场数据\n -> 转成统一内部数据结构\n -> 调用分析函数\n -> 生成消息\n -> 推送 Telegram\n -> 记录日志与失败重试\n```\n\n关键不是“自己造一个 Polymarket SDK”，而是把成熟能力拼成可运行、可替换、可观测的业务流程。\n\n\n### 常见场景\n\n\n#### 登录认证\n\n错误路径：自己设计密码加密、Token 签发、OAuth 流程、验证码和权限基础设施。\n\n拼好码路径：优先评估云厂商认证服务、Auth0、Firebase Auth、Keycloak、企业统一身份系统或框架内置认证模块。\n\n胶水代码只负责：\n\n- 把认证结果接入业务用户体系。\n- 把外部用户 ID 映射到内部用户模型。\n- 处理业务角色和权限。\n- 封装登录后的业务流程。\n\n\n#### AI 客服\n\n错误路径：从零训练模型、写向量数据库、写知识库检索、写对话管理、写监控系统。\n\n拼好码路径：优先使用成熟大模型 API、向量数据库、RAG 框架、客服平台和日志监控工具。\n\n胶水代码只负责：\n\n- 业务知识整理。\n- 问题分类。\n- 工作流编排。\n- 人工转接规则。\n- 企业系统接口适配。\n- 回答质量评估。\n\n\n#### 订单流程\n\n错误路径：自己写完整调度系统、消息队列、重试机制、状态机、通知系统。\n\n拼好码路径：优先使用成熟消息队列、任务调度平台、工作流引擎、云函数、监控告警服务。\n\n胶水代码只负责：\n\n- 订单创建后触发库存检查。\n- 支付成功后触发发货。\n- 发货后触发通知。\n- 异常时进入人工处理。\n- 在不同系统之间做数据适配。\n\n\n### 偏离协议\n\n拼好码不是绝对禁止自研，而是要求自研必须有充分理由。\n\n如需偏离胶水原则，必须说明：\n\n- 偏离原因。\n- 已评估的成熟方案。\n- 为什么成熟方案不能满足关键约束。\n- 自研范围和边界。\n- 维护成本。\n- 安全风险。\n- 供应商锁定或私有实现锁定风险。\n- 测试策略。\n- 替换、删除或回滚路径。\n\n未完成偏离说明前，不得默认进入自研核心能力实现路径。\n\n\n### 胶水原则之禅\n\n- 成熟方案优于自研实现。\n- 官方能力优于私有轮子。\n- 事实标准优于个人偏好。\n- 复用优于重写。\n- 编排优于重造。\n- 适配优于侵入。\n- 连接优于耦合。\n- 资源整合优于单打独斗。\n- 薄胶水优于厚平台。\n- 业务逻辑优于基础设施。\n- 平台能力优于底层代码。\n- 稳定生态优于新奇技术。\n- 长期维护优于短期快感。\n- 可替换优于强绑定。\n- 可回滚优于不可逆。\n- 可验证优于想当然。\n- 少写代码优于多造代码。\n- 必要自研优于盲目复用。\n- 明确边界优于隐式依赖。\n- 充分理由优于控制幻觉。\n- 偏离必须说明。\n- 自研必须克制。\n- 能复用时，不要重造。\n- 能编排时，不要发明。\n- 能适配时，不要入侵。\n- 如果成熟方案能可靠满足需求，它就应该是默认答案。\n\n\n### 与相近概念的区别\n\n\n#### 拼好码 vs 胶水编程\n\n胶水编程强调“用最少胶水代码连接成熟组件”。拼好码包含胶水编程，但还包含成熟能力发现、方案评估、边界隔离、门禁设计、替换路径和偏离协议。\n\n简化理解：\n\n```text\n胶水编程：把轮子粘起来\n拼好码：先判断该用哪些轮子，再设计边界、粘起来、验证它、让它可替换\n```\n\n\n#### 拼好码 vs 低代码\n\n低代码强调用平台快速搭建应用；拼好码强调工程决策中优先复用成熟能力。低代码可以是拼好码的一种工具，但拼好码不等于低代码。\n\n\n#### 拼好码 vs 微服务\n\n微服务是一种系统拆分架构；拼好码是一种复用优先的工程哲学。微服务如果盲目自研基础设施，反而违背拼好码。\n\n\n#### 拼好码 vs 自研平台化\n\n平台化追求沉淀公共能力；拼好码警惕“厚平台”。只有公共能力确实稳定、复用频繁、边界清晰时，平台化才有价值。\n\n\n### AI 时代的拼好码\n\nAI 特别适合生成：\n\n- 接口适配代码。\n- 数据转换代码。\n- 工作流编排代码。\n- 测试用例。\n- SDK 调用示例。\n- 配置模板。\n- 迁移脚本。\n- 偏离说明。\n\n但 AI 也容易顺手造轮子，所以更好的模式是让 AI 在胶水原则约束下工作：\n\n1. 先查成熟方案。\n2. 再评估成熟度、许可证、维护状态和替代方案。\n3. 再生成适配层和编排层。\n4. 再补业务逻辑和测试。\n5. 最后输出偏离说明与回滚路径。\n\n\n### 内化\n\n学会拼好码后，工程习惯应该从：\n\n> “我来实现这个功能。”\n\n变成：\n\n> “这个功能已有成熟能力吗？我该如何接入、编排、隔离和验证？”\n\n从：\n\n> “我能不能写出来？”\n\n变成：\n\n> “我该不该自己写？”\n\n从：\n\n> “这个系统要写多少代码？”\n\n变成：\n\n> “这个系统能复用多少成熟能力，剩下的胶水边界是否清晰？”\n\n最终，拼好码要内化成一句工程本能：\n\n> 成熟能力解决通用问题，胶水代码连接业务流程，自研只服务于真正不可替代的差异。\n\n\n### 延伸阅读\n\n- [语言层要素](language-layers.md) - 看懂代码需要掌握的语言层级\n- [胶水开发提示词（在线提示词库入口）](../../prompts/README.md)\n",
"sha256": "3c537bbdb5dc4027d3c03b487193aa5f896e645ad57c734e108a677393cbb105"
},
".github/docs/gongfa/harness-engineering.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "\n\n# Harness 工程解析\n\n> 工程控制、评估器、反馈闭环与 AI 生成系统可靠性。\n\n## 来源材料\n\n- [Lilian Weng 原文抓取](../../research/harness/raw/lilian-weng-harness-engineering-for-self-improvement.md) - 《Harness Engineering for Self-Improvement》的 raw 事实层。\n- [Lilian Weng 提纲摘记](../../research/harness/notes/lilian-weng-harness-rsi-outline.md) - Harness 与 RSI 关系、设计模式和目录结构摘记。\n- [Lilian Weng 短摘](../../research/harness/notes/lilian-weng-harness-rsi-short-note.md) - Harness 与 RSI 关系的短摘。\n\n## 核心判断\n\n1. Harness Engineering 的本质是用确定性的工程控制系统，把大模型的非确定性输出压缩进可预测的轨道里，让“概率生成”变成“可验收的产出”\n\n2. 大模型在系统里只承担两件事：理解意图、把意图翻译成文本（代码/配置/文档），它更像算力与语言编译器，而不是可靠性来源\n\n3. 可靠性不来自“更聪明的模型”，而来自外部机制对输出的四类动作：拦截意图、校验结果、拒绝不合格、注入必要上下文\n\n4. 最小可运行 Harness 的关键不是生成代码，而是闭环：生成→编译/运行→抓取错误→反馈重写→直到通过，这把一次性聊天改造成可迭代的生产流程\n\n5. 第一类硬问题是上下文与遗忘：任务一复杂就会撑爆上下文、目标漂移、前后端混写，本质是模型没有稳定的工作记忆与任务边界\n\n6. 对应解法是动态上下文注入与记忆管理：把规则与知识拆成可插拔技能包，按“当前意图”精准装载与卸载，让上下文保持短、准、相关\n\n7. 记忆的工程化含义不是“多存点东西”，而是把踩坑与验证过的结论自动提炼成规则沉淀下来，使系统具备跨任务的抗重复犯错能力\n\n8. 第二类硬问题是自评幻觉：让模型自己审查等于既当运动员又当裁判，它会用讨好与自洽掩盖逻辑错误，漂亮但不可用\n\n9. 对应解法是评估驱动与机械测试：引入独立的、可执行的第三方判定（编译器、单测、端到端 UI 测试、独立 QA Agent），用硬指标决定通过与否\n\n10. 质量下限从“模型聪明程度”迁移到“验收机制完备性”，系统真正的生产力来自可重复运行的判定器，而不是一次灵感式输出\n\n11. 第三类硬问题是时间维度的熵增：长期运行后模型会为了更快过测试而走捷径，架构漂移、耦合蔓延，最终形成不可维护的腐化代码库\n\n12. 对应解法是架构强约束与持续清理：用静态规则提前阻断跨层依赖等结构性违规，再用专职清理机制持续重构、更新文档、回收技术债，对抗代码腐化\n\n13. 当系统拥有规划者、执行者、评估者、硬约束钩子、清理机制时，Harness 才从脚本升级为“Agent 操作系统”，长期稳定性来自分工与制衡\n\n14. 那些看似“AI 自己写出百万行代码”的魔法，核心不在模型，而在工具与 Harness 组合出来的现实校验、反馈重试、规则约束与持续治理\n\n15. Harness 不是回到古法逐行写代码，而是把工程重心从实现细节迁移到边界、接口、约束、断言与验收标准，编码对象从业务逻辑变成生产流水线\n\n16. Harness 的门槛高于写业务代码的根因在于：它要求你先把“什么算对、什么算好、什么必须禁止”形式化成可执行规则，否则系统会高速产出结构化垃圾\n\n17. Harness 的维护成本来自业务变化：当目标函数变了，你必须同步重写评估器与测试桩，否则闭环会失真并进入死锁或错误优化\n\n18. 最大误解之一是指望模型升级解决跑偏，现实规律是无论马多强，没有缰绳都会把车拉进沟里，可靠性必须由外部约束提供\n\n19. 最大误解之二是工具越多越好，工具过载会导致选择震荡与时间浪费，工具集应该为评估与执行最小充分，而非堆权限展示强大\n\n20. 最大误解之三是把无约束的氛围式开发当工业未来，它只能在无历史负担的小项目里成立，一旦进入长周期协作与演进，没有硬边界就必然灾难\n\n21. Harness 的上限由评估器决定：如果你无法把“好结果”编码为可检验的规则与测试，系统就无法稳定优化，模型也无法替你完成这层战略定义\n\n22. 未来工程师的分化本质是控制权分配：一类在代码生成速度上竞争，另一类在规则、评估、架构与闭环设计上竞争，后者决定系统长期生产力与可维护性\n",
"sha256": "ddb1077720ef26ac78a52e15587a85b64bb63e77cad10ee64f6e410530e66c71"
},
".github/docs/gongfa/keyword-system.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "# 关键词系统\n\n本页收集 Vibe Coding 与工程协作中的高频关键词，用于理解、描述、提示词构造、问题拆解、系统建模、代码审查和经验沉淀。\n\n## 原始关键词列表\n\n```text\n专业链路\n非专业链路\n先看别人怎么做\n模仿\n学习\n扬弃/提炼/升华\n自顶向下\n自底向上\n分而治之\n全生命周期\n第一原理\n代码类型\n模型类型\n技术代码\n技术模型\n技术逻辑\n技术流程\n业务流程\n需求文档\n运行平台\n技术框架\n基础设施代码\n基础设施模型\n业务模型\n业务逻辑\n近端原因\n生产/消费模型\n抽象\n回潮\n门禁\n盘点\n落盘\n业务代码\n控制面\n技术栈\n工具集\n依赖链\n读算写\n入和出\n控制流\n数据流\n通专用\n抽象层\n边界层\n架构层\n模块化\n组件化\n服务化\n封装性\n内聚性\n耦合度\n接口层\n协议层\n依赖链\n调用链\n控制流\n数据流\n状态流\n事件流\n信息流\n状态机\n副作用\n不变式\n一致性\n完整性\n可靠性\n安全性\n可用性\n健壮性\n可维护\n可扩展\n可测试\n可观测\n可复用\n可回滚\n容忍\n收口\n盘点\n巡检\n值\n数字\n文本\n布尔值\n空值\n名字\n变量\n函数名\n模块名\n计算\n加减乘除\n比较\n逻辑运算\n控制流\n顺序\n分支\n循环\n抽象\n函数\n类\n模块\n交互\n输入\n输出\n文件\n网络\n系统调用\n处理流\n持久化\n加固\n钩子\n封装\n恢复\n回滚\n组合优化\n边界清\n契约稳\n复用深\n替换容易\n深模块\n事物\n业务流量\n抽象\n算法\n数据结构\n计算模型\n状态\n控制流\n输入输出\n变量\n函数\n类型系统\n接口\n模块化\n封装\n复用\n组合\n递归\n并发\n异步\n复杂度\n性能\n内存\n资源管理\n错误处理\n调试\n测试\n可维护性\n可扩展性\n可读性\n确定性\n副作用\n依赖\n架构\n编译\n解释执行\n运行时\n操作系统\n网络\n数据库\n协议\n安全\n自动化\n工程化\n人机协作\n需求转译\n问题分解\n约束求解\n逻辑表达\n系统边界\n回潮\n```\n",
"sha256": "4436d62a524158af62b857d34da18b8fbf15dcbc597b37f6fe4358567fdac534"
},
".github/docs/gongfa/language-layers.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "\n\n# 语言层要素\n\n> 看懂代码所需的语言层要素。\n\n---\n\n\n### 一、先纠正一个关键误区\n\n❌ 误区：\n\n> 看不懂代码 = 不懂语法\n\n✅ 真相：\n\n> 看不懂代码 = **不懂其中某一层模型**\n\n---\n\n\n### 二、看懂 100% 代码 = 掌握 8 个层级\n\n---\n\n\n### 🧠 L1：基础控制语法（最低门槛）\n\n你已经知道的这一层：\n\n```text\n变量\nif / else\nfor / while\n函数 / return\n```\n\n👉 只能看懂**教学代码**\n\n---\n\n\n### 🧠 L2：数据与内存模型（非常关键）\n\n你必须理解：\n\n```text\n值 vs 引用\n栈 vs 堆\n拷贝 vs 共享\n指针 / 引用\n可变 / 不可变\n```\n\n示例你要“秒懂”：\n\n```c\nint *p = &a;\n```\n\n```python\na = b\n```\n\n👉 这是**C / C++ / Rust / Python 差距的根源**\n\n---\n\n\n### 🧠 L3：类型系统（大头）\n\n你需要懂：\n\n```text\n静态类型 / 动态类型\n类型推导\n泛型 / 模板\n类型约束\nNull / Option\n```\n\n比如你要一眼看出：\n\n```rust\nfn foo(x: T) -> Option\n```\n\n---\n\n\n### 🧠 L4：执行模型（99% 新人卡死）\n\n你必须理解：\n\n```text\n同步 vs 异步\n阻塞 vs 非阻塞\n线程 vs 协程\n事件循环\n内存可见性\n```\n\n示例：\n\n```js\nawait fetch()\n```\n\n你要知道**什么时候执行、谁在等谁**。\n\n---\n\n\n### 🧠 L5：错误处理与边界语法\n\n```text\n异常 vs 返回值\npanic / throw\nRAII\ndefer / finally\n```\n\n你要知道：\n\n```go\ndefer f()\n```\n\n**什么时候执行，是否一定执行**。\n\n---\n\n\n### 🧠 L6：元语法（让代码“看起来不像代码”）\n\n这是很多人“看不懂”的根源：\n\n```text\n宏\n装饰器\n注解\n反射\n代码生成\n```\n\n示例：\n\n```python\n@cache\ndef f(): ...\n```\n\n👉 你要知道**它在改写什么代码**\n\n---\n\n\n### 🧠 L7：语言范式（决定思路）\n\n```text\n面向对象（OOP）\n函数式（FP）\n过程式\n声明式\n```\n\n示例：\n\n```haskell\nmap (+1) xs\n```\n\n你要知道这是**对集合做变换，不是循环**。\n\n---\n\n\n### 🧠 L8：领域语法 & 生态约定（最后 1%）\n\n```text\nSQL\n正则\nShell\nDSL（如 Pine Script）\n框架约定\n```\n\n示例：\n\n```sql\nSELECT * FROM t WHERE id IN (...)\n```\n\n---\n\n\n### 三、真正的“100% 看懂”公式\n\n```text\n100% 看懂代码 =\n语法\n+ 类型模型\n+ 内存模型\n+ 执行模型\n+ 语言范式\n+ 框架约定\n+ 领域知识\n```\n\n❗**语法只占不到 30%**\n\n---\n\n\n### 四、你会在哪一层卡住？（现实判断）\n\n| 卡住表现 | 实际缺失 |\n| --------- | ------- |\n| “这行代码看不懂” | L2 / L3 |\n| “为啥结果是这样” | L4 |\n| “函数去哪了” | L6 |\n| “风格完全不一样” | L7 |\n| “这不是编程吧” | L8 |\n\n---\n\n\n### 五、给你一个真正工程级的目标\n\n🎯 **不是“背完语法”**\n🎯 而是能做到：\n\n> “我不知道这门语言，但我知道它在干什么。”\n\n这才是**100% 的真实含义**。\n\n---\n\n\n### 六、工程级追加：L9–L12（从\"看懂\"到\"架构\"）\n\n> 🔥 把「能看懂」升级为「能**预测**、**重构**、**迁移**代码」\n\n---\n\n\n### 🧠 L9：时间维度模型（90% 人完全没意识到）\n\n你不仅要知道代码**怎么跑**，还要知道：\n\n```text\n它在「什么时候」跑\n它会「跑多久」\n它是否「重复跑」\n它是否「延迟跑」\n```\n\n\n#### 你必须能一眼判断：\n\n```python\n@lru_cache\ndef f(x): ...\n```\n\n* 是 **一次计算，多次复用**\n* 还是 **每次都重新执行**\n\n```js\nsetTimeout(fn, 0)\n```\n\n* ❌ 不是立刻执行\n* ✅ 是 **当前调用栈清空之后**\n\n👉 这是 **性能 / Bug / 竞态 / 重复执行** 的根源\n\n---\n\n\n### 🧠 L10：资源模型（CPU / IO / 内存 / 网络）\n\n很多人以为：\n\n> \"代码就是逻辑\"\n\n❌ 错\n**代码 = 对资源的调度语言**\n\n你必须能区分：\n\n```text\nCPU 密集\nIO 密集\n内存绑定\n网络阻塞\n```\n\n\n#### 示例\n\n```python\nfor x in data:\n process(x)\n```\n\n你要问的不是\"语法对不对\"，而是：\n\n* `data` 在哪？（内存 / 磁盘 / 网络）\n* `process` 是算还是等？\n* 能不能并行？\n* 能不能批量？\n\n👉 这是 **性能优化、并发模型、系统设计的起点**\n\n---\n\n\n### 🧠 L11：隐含契约 & 非语法规则（工程真相）\n\n这是**99% 教程不会写**，但你在真实项目里天天踩雷的东西。\n\n\n#### 你必须识别这些\"非代码规则\"：\n\n```text\n函数是否允许返回 None\n是否允许 panic\n是否允许阻塞\n是否线程安全\n是否可重入\n是否可重复调用\n```\n\n\n#### 示例\n\n```go\nhttp.HandleFunc(\"/\", handler)\n```\n\n隐藏契约包括：\n\n* handler **不能阻塞太久**\n* handler **可能被并发调用**\n* handler **不能 panic**\n\n👉 这层决定你是 **\"能跑\"** 还是 **\"能上线\"**\n\n---\n\n\n### 🧠 L12：代码意图层（顶级能力）\n\n这是**架构师 / 语言设计者层级**。\n\n你要做到的不是：\n\n> \"这段代码在干嘛\"\n\n而是：\n\n> \"**作者为什么要这么写？**\"\n\n你要能识别：\n\n```text\n是在防 bug？\n是在防误用？\n是在性能换可读性？\n是在为未来扩展留钩子？\n```\n\n\n#### 示例\n\n```rust\nfn foo(x: Option) -> Result\n```\n\n你要读出：\n\n* 作者在**强制调用者思考失败路径**\n* 作者在**拒绝隐式 null**\n* 作者在**压缩错误空间**\n\n👉 这是 **代码审查 / 架构设计 / API 设计能力**\n\n---\n\n\n### 七、终极完整版：12 层\"语言层要素\"总表\n\n| 层级 | 名称 | 决定你能不能… |\n|:---|:---|:---|\n| L1 | 控制语法 | 写出能跑的代码 |\n| L2 | 内存模型 | 不写出隐式 bug |\n| L3 | 类型系统 | 不靠注释理解代码 |\n| L4 | 执行模型 | 不被 async / 并发坑 |\n| L5 | 错误模型 | 不漏资源 / 不崩 |\n| L6 | 元语法 | 看懂\"不像代码的代码\" |\n| L7 | 范式 | 理解不同风格 |\n| L8 | 领域 & 生态 | 看懂真实项目 |\n| L9 | 时间模型 | 控制性能与时序 |\n| L10 | 资源模型 | 写出高性能系统 |\n| L11 | 隐含契约 | 写出可上线代码 |\n| L12 | 设计意图 | 成为架构者 |\n\n---\n\n\n### 八、反直觉但真实的结论\n\n> ❗**真正的\"语言高手\"**\n>\n> 不是某语言语法背得多\n>\n> 而是：\n>\n> 👉 **同一段代码，他比别人多看 6 层含义**\n\n---\n\n\n### 九、工程级自测题（非常准）\n\n当你看到一段陌生代码时，问自己：\n\n1. 我知道它的数据在哪吗？（L2 / L10）\n2. 我知道它什么时候执行吗？（L4 / L9）\n3. 我知道失败会发生什么吗？（L5 / L11）\n4. 我知道作者在防什么吗？（L12）\n\n✅ **全 YES = 真·100% 看懂**\n\n---\n\n\n### 十、各层级学习资源推荐\n\n| 层级 | 推荐资源 |\n|:---|:---|\n| L1 控制语法 | 任意语言官方教程 |\n| L2 内存模型 | 《深入理解计算机系统》(CSAPP) |\n| L3 类型系统 | 《Types and Programming Languages》 |\n| L4 执行模型 | 《JavaScript 异步编程》、Rust async book |\n| L5 错误模型 | Go/Rust 官方错误处理指南 |\n| L6 元语法 | Python 装饰器源码、Rust 宏小册 |\n| L7 范式 | 《函数式编程思维》、Haskell 入门 |\n| L8 领域生态 | 框架官方文档 + 源码 |\n| L9 时间模型 | 性能分析工具实战（perf、py-spy） |\n| L10 资源模型 | 《性能之巅》(Systems Performance) |\n| L11 隐含契约 | 阅读知名开源项目 CONTRIBUTING.md |\n| L12 设计意图 | 参与 Code Review、读 RFC/设计文档 |\n\n---\n\n\n### 十一、常见语言层级对照表\n\n| 层级 | Python | Rust | Go | JavaScript |\n|:---|:---|:---|:---|:---|\n| L2 内存 | 引用为主，GC | 所有权+借用 | 值/指针，GC | 引用为主，GC |\n| L3 类型 | 动态，type hints | 静态，强类型 | 静态，简洁 | 动态，TS可选 |\n| L4 执行 | asyncio/GIL | tokio/async | goroutine/channel | event loop |\n| L5 错误 | try/except | Result/Option | error返回值 | try/catch/Promise |\n| L6 元语法 | 装饰器/metaclass | 宏 | go generate | Proxy/Reflect |\n| L7 范式 | 多范式 | 多范式偏FP | 过程式+接口 | 多范式 |\n| L9 时间 | GIL限制并行 | 零成本异步 | 抢占式调度 | 单线程事件循环 |\n| L10 资源 | CPU受限于GIL | 零开销抽象 | 轻量goroutine | IO密集友好 |\n\n---\n\n\n### 十二、实战代码剥洋葱示例\n\n以 FastAPI 路由为例，逐层分析：\n\n```python\n@app.get(\"/users/{user_id}\")\nasync def get_user(user_id: int, db: Session = Depends(get_db)):\n user = await db.execute(select(User).where(User.id == user_id))\n if not user:\n raise HTTPException(status_code=404)\n return user\n```\n\n| 层级 | 你要看到什么 |\n|:---|:---|\n| L1 | 函数定义、if、return |\n| L2 | `user` 是引用，`db` 是共享连接 |\n| L3 | `user_id: int` 类型约束，自动校验 |\n| L4 | `async/await` 非阻塞，不占线程 |\n| L5 | `HTTPException` 中断请求，框架捕获 |\n| L6 | `@app.get` 装饰器注册路由，`Depends` 依赖注入 |\n| L7 | 声明式路由，函数式处理 |\n| L8 | FastAPI 约定、SQLAlchemy ORM |\n| L9 | 每个请求独立协程，`await` 让出控制权 |\n| L10 | IO 密集（数据库查询），适合异步 |\n| L11 | `db` 必须线程安全，不能跨请求共享状态 |\n| L12 | 作者用类型+DI 强制规范，防止裸 SQL 和硬编码 |\n\n---\n\n\n### 十三、从 L1→L12 的训练路径\n\n\n### 阶段一：基础层（L1-L3）\n- **方法**：刷题 + 类型体操\n- **目标**：语法熟练、类型直觉\n- **练习**：\n - LeetCode 100 题（任意语言）\n - TypeScript 类型体操\n - Rust 生命周期练习\n\n\n### 阶段二：执行层（L4-L6）\n- **方法**：读异步框架源码\n- **目标**：理解运行时行为\n- **练习**：\n - 手写简易 Promise\n - 阅读 asyncio 源码\n - 写一个 Python 装饰器库\n\n\n### 阶段三：范式层（L7-L9）\n- **方法**：跨语言重写同一项目\n- **目标**：理解设计取舍\n- **练习**：\n - 用 Python/Go/Rust 实现同一个 CLI 工具\n - 对比三种实现的性能和代码量\n - 分析各语言的时间模型差异\n\n\n### 阶段四：架构层（L10-L12）\n- **方法**：参与开源 Code Review\n- **目标**：读懂设计意图\n- **练习**：\n - 给知名项目提 PR 并接受 review\n - 阅读 3 个项目的 RFC/设计文档\n - 写一份 API 设计文档并让他人 review\n\n---\n\n\n### 十四、终极检验：你到了哪一层？\n\n| 能力表现 | 所在层级 |\n|:---|:---|\n| 能写出能跑的代码 | L1-L3 |\n| 能调试异步/并发 bug | L4-L6 |\n| 能快速上手新语言 | L7-L8 |\n| 能做性能优化 | L9-L10 |\n| 能写出生产级代码 | L11 |\n| 能设计 API/架构 | L12 |\n\n> 🎯 **目标不是\"学完 12 层\"，而是\"遇到问题知道卡在哪一层\"**\n",
"sha256": "6ee91a5259ee03f3aa82c2a3e7f0ed143c1115b491ce22ae8f86ec13a3e95c8e"
},
".github/docs/gongfa/low-level-program-logic.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "\n# 底层程序逻辑设计与工程优化项\n\n这一节是底层程序逻辑、运行模型、性能模型、并发模型、数据模型和工程交付优化的检查清单。用于代码实现、重构、性能排查和 AI 编程验收前的系统性自检。\n\n```text\nCPU\n事务\n缓存\n并发\n内存\nIO\n网络\n数据结构\n算法\n抽象\n接口\n函数\n递归\n循环\n条件分支\n顺序性\n副作用\n状态\n数据流\n控制流\n进程模型\n线程模型\n协程模型\n用户态线程 vs 内核线程\n同步模型\n异步模型\n事件驱动模型\n批处理模型\n流式处理模型\n计算模型\n调度模型\n内存模型\n并发模型\n数据模型\n状态模型\n错误模型\n性能模型\n成本模型\n容量模型\nCPU cache 友好设计\nCPU 使用优化\nCPU 亲和性\n上下文切换成本\n分支预测意识\n分支预测友好设计\n流水线友好设计\n指令级并行意识\nSIMD 思维\n向量化计算\nGPU 计算设计\nGPU 内存访问优化\n算子融合\n计算图优化\n数值稳定性设计\n浮点误差控制\n近似计算\n增量计算\n重复计算消除\n预计算与查表\n延迟计算\n懒加载\n即时计算 vs 预计算\n本地计算 vs 远程调用\n计算复杂度优化\n时间复杂度优化\n空间复杂度优化\n空间换时间设计\n数据局部性优化\n内存访问优化\n内存分配优化\n栈/堆使用判断\n逃逸分析意识\nGC 友好设计\nJIT/解释执行理解\n内联优化意识\n对象生命周期设计\n内存生命周期管理\n内存泄漏控制\n内存碎片控制\n堆外内存管理\n引用计数\n弱引用\n内存对齐\n结构体 padding\nTLB 命中率意识\n页缓存理解\n缺页中断意识\n内存分页\nNUMA 感知设计\n内存屏障理解\nhappens-before 关系\n可见性\n有序性\n原子性\nfalse sharing 避免\n原子操作与 CAS\nABA 问题\n锁粒度设计\n锁竞争优化\n读写锁适用性\n可重入锁风险\n锁顺序约束\n无锁数据结构\n锁自由设计\n等待自由设计\n死锁\n活锁\n饥饿\n优先级反转\n条件变量\n信号量\n屏障同步\n并发安全设计\n并发正确性设计\n并发测试\n竞态检测\n任务拆分策略\n工作队列设计\n优先级调度\n调度公平性\n线程池设计\n线程池饱和处理\n队列积压处理\n背压机制\n超时传播\n取消传播\n异步上下文传播\n异步异常处理\n同步/异步边界设计\n阻塞式等待识别\n阻塞 IO\n非阻塞 IO\nIO 多路复用\nselect / poll / epoll / kqueue\nio_uring 理解\nReactor 模型\nProactor 模型\n事件循环设计\n事件队列设计\n事件优先级\n事件饥饿\n系统调用成本意识\n文件描述符管理\n句柄泄漏控制\n资源释放\n资源隔离\n资源配额\n资源池化\n对象池设计\n连接池设计\n缓冲区设计\n零拷贝思路\nDMA 理解\nmmap 使用判断\nsendfile 使用判断\nIO 合并\n批处理与合并请求\n网络调用优化\nDNS 解析成本\nDNS 缓存策略\nTCP 连接建立成本\nTCP 慢启动\nTCP 拥塞控制\nNagle 算法影响\nKeepAlive 策略\n连接复用\n连接泄漏控制\nSocket buffer 调优\nHTTP/1.1 vs HTTP/2 vs HTTP/3\nTLS 握手成本\n证书校验成本\n长连接管理\n半开连接处理\n请求队头阻塞\n网络超时设计\n网络抖动处理\n网络分区处理\nMTU / 分片意识\n带宽与延迟权衡\n序列化优化\n反序列化成本控制\n压缩策略选择\n压缩率 vs CPU 成本权衡\n数据编码选择\n数据格式选择\nSchema 设计\nSchema 演进\n字段兼容性\n枚举扩展风险\n默认值策略\n数据结构选择\n缓存结构选择\n队列与堆选择\n索引结构选择\n概率数据结构\n布隆过滤器\nHyperLogLog\nCount-Min Sketch\nLRU / LFU / FIFO 选择\n树结构选择\n哈希结构选择\n跳表选择\nB+Tree 理解\nLSM Tree 理解\n图结构建模\n排序策略选择\n查找策略选择\n贪心策略判断\n动态规划建模\n图算法选择\n分治策略选择\n回溯策略选择\n启发式算法选择\n算法策略选择\n算法稳定性\n算法可解释性\n循环结构优化\n递归深度控制\n尾递归优化判断\n无边界递归避免\n数据预聚合\n数据分片与分区\n数据倾斜处理\nMapReduce 思维\n并行计算设计\n批处理设计\n流式处理设计\n冷热路径拆分\n冷路径隔离\n热路径优化\n性能瓶颈识别\n性能指标定义\nProfiling 能力\n火焰图分析\n慢查询分析\nTrace 分析\n日志埋点设计\n结构化日志\n日志等级设计\nTrace ID 传播\nSpan 设计\nMetrics 设计\n高基数指标控制\nDashboard 设计\n告警规则设计\n告警降噪\nSLO / SLA / SLI\n错误预算\n黑盒监控\n白盒监控\n用户体验监控\n业务指标监控\n容量水位监控\nBenchmark 设计\n压测设计\n容量评估\n峰值流量模型\n流量预测\n性能回归测试\n优化验证\n优化收益评估\n优化 ROI 评估\n过早优化识别\n伪优化识别\n缓存层级设计\n分层缓存\n本地缓存\n分布式缓存\n页面缓存\n对象缓存\n查询缓存\n结果复用\n缓存对象选择\n缓存 key 设计\n缓存一致性\n缓存失效策略\n缓存淘汰策略\n缓存预热机制\n缓存穿透处理\n缓存击穿处理\n缓存雪崩处理\n热点缓存处理\n缓存污染控制\n缓存容量控制\n缓存命中率评估\n数据访问优化\n数据访问方式选择\n数据访问路径设计\n查询路径设计\n写入路径优化\n索引设计\n覆盖索引\n索引下推\n回表成本控制\n分页优化\n游标分页\nN+1 查询消除\n查询计划理解\n执行计划稳定性\n统计信息维护\n慢查询治理\n锁等待分析\n死锁分析\n事务范围控制\n事务边界\n事务隔离级别\nMVCC 理解\nWAL 理解\nRedo / Undo 日志\nCheckpoint\nBuffer Pool\n页分裂控制\nCompaction\n分区裁剪\n分库分表\n读写分离\n冷热数据分层\n数据归档\nTTL 策略\nCDC 变更捕获\n数据回放\n数据修复\n数据血缘\n数据质量校验\n范式化 vs 反范式化\n数据冗余与同步\n热点数据处理\n数据生命周期设计\n数据流路径设计\n数据转换链路设计与优化\n数据校验位置\n数据一致性设计\n顺序性与版本控制\n版本冲突解决\n逻辑时钟\n向量时钟\n时钟偏移处理\n读己之写\n单调读\n强一致性\n最终一致性\nCAP 理解\nPACELC 理解\n分布式事务\nSaga 模式\nTCC 模式\nOutbox 模式\nInbox 模式\n幂等性设计\n幂等键设计\n去重设计\n请求唯一 ID\n消息可靠投递\n至少一次语义\n至多一次语义\n恰好一次语义\n消息重复处理\n消息乱序处理\n消息积压处理\n消费位点管理\n分布式锁\n租约机制\nFencing Token\nLeader 选举\nRaft / Paxos 理解\n脑裂处理\n服务发现\n负载均衡\n一致性哈希\n分片迁移\n数据再均衡\n纯逻辑与 IO 分离\n数据流与控制流分离\n副作用控制\n状态管理方式选择\n状态一致性\n状态机设计\n状态机 vs 条件分支\n状态流转设计\n中间状态设计\n数据不变量\n前置条件与后置条件\n顺序依赖设计\n短路逻辑设计\n分支条件设计\n早返回设计\n控制流扁平化\n执行路径设计\n主流程与分支流程设计\n代码路径可读性\n复杂度控制\n依赖方向设计\n模块边界设计\n包依赖治理\n循环依赖检测\n接口语义设计\nAPI 契约设计\n接口版本管理\n向前兼容\n向后兼容\n错误码规范\n错误语义稳定性\n部分响应设计\n批量接口设计\n限流响应协议\n请求签名\n契约测试\n函数职责设计\n逻辑拆分粒度\n抽象层次选择\n组合方式选择\n处理模式选择\n策略模式 vs switch-case\n管道模式 vs 单体函数\n事件驱动 vs 直接调用\n同步处理 vs 异步处理\n批处理 vs 实时处理\n配置化 vs 硬编码\n配置化 vs 代码化\n通用化 vs 专用化\n规则引擎 vs 硬编码\n通用框架 vs 专用实现\n可替换性\n规则隔离\n扩展点设计\n变更影响范围\n技术债识别\n技术债偿还策略\n迁移策略\n废弃策略\n兼容窗口\n文档化\nADR 决策记录\n设计评审\n接口评审\n性能评审\n安全评审\n输入合法性校验\n边界条件覆盖\n异常分类\n错误传播\n错误封装\n错误恢复\n部分成功处理\n流程中断与恢复\n中断、回滚、重试流程\n重试策略\n指数退避\n重试抖动 jitter\n重试风暴防护\n失败降级策略\n限流设计\n熔断器设计\n舱壁隔离\n过载保护\n请求排队策略\n丢弃策略\n快速失败\n故障隔离\n故障注入\n混沌工程\n降级开关\n灰度降级\n超时预算\nDeadline 传播\n服务健康检查\n自愈机制\n优雅降级\n优雅关闭\n启动预热\n冷启动控制\n灾难恢复\n备份与恢复\nRPO / RTO\n认证设计\n授权设计\n权限模型\n最小权限原则\n权限边界\n身份冒用防护\n输入注入防护\nSQL 注入\n命令注入\nXSS\nCSRF\nSSRF\n反序列化风险\n路径穿越\n敏感信息脱敏\n日志脱敏\n密钥管理\nToken 生命周期\n加密存储\n传输加密\n签名校验\n重放攻击防护\n多租户隔离\n安全审计\n依赖漏洞治理\n供应链安全\n单元测试设计\n集成测试设计\n端到端测试\n回归测试\n稳定性测试\n兼容性测试\n模糊测试 Fuzzing\n属性测试 Property-based Testing\n测试数据构造\nMock 边界\n测试隔离\n可测性设计\n确定性测试\n时间依赖测试\n随机性控制\n灰度发布\n蓝绿发布\n金丝雀发布\n滚动发布\n回滚策略\n配置发布\n特性开关\nFeature Flag\n数据库变更发布\n兼容性发布\n双写切换\n流量切换\n影子流量\n压测环境隔离\n生产变更风险评估\n变更审计\n发布前检查\n发布后验证\nRunbook\n应急预案\n值班机制\n资源成本评估\nCPU 成本\n内存成本\n存储成本\n网络成本\n第三方 API 成本\n云资源成本\n成本预算\n弹性伸缩\n扩容策略\n缩容策略\n成本收益权衡\n反模式识别\n大锁\n大事务\n全局状态污染\n重复 IO\n重复计算\n过深嵌套\n隐式控制流\n过度通用化\n过早抽象\n过早优化\n伪优化\n缺少退路\n缺少幂等\n缺少超时\n缺少取消\n缺少隔离\n缺少限流\n缺少监控\n缺少回滚\n缺少兼容\n缺少验证\n缺少容量评估\n```\n",
"sha256": "936a8d3e00361a7f7447fb3302a62fcb8c6edf9157ac132af840249ceaeda943"
},
".github/docs/gongfa/methodology-toolbox.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "\n\n# 方法论工具箱\n\n> 现象学还原、正反合、可证伪主义、形式化方法等提效工具。\n\n> 目标：把\"vibe（探索）\"系统化为\"可验证、可迭代、可收敛\"的工程产出。\n> 每个方法给出：用途 / 落地动作 / Python工具 / 可复制提示词。\n\n\n### 目录定位\n\n`.github/docs/gongfa/` 统一维护哲学方法论、思维模型、编程哲学和底层认知模型。本工具箱回答的不是“下一步命令是什么”，而是“为什么这样判断、如何减少幻觉、如何让复杂问题可描述、可推理、可验证”。\n\n适合：\n\n- 需要提升问题抽象、系统理解和长期工程判断的人。\n- 需要为 AI Agent 提供更稳定认知框架的任务。\n- 已经掌握入门流程，希望把经验沉淀成可迁移方法的人。\n\n\n### 怎么选\n\n| 目标 | 先读 |\n|:---|:---|\n| 想快速获得可复用认知工具 | [思维模型](thinking-models.md) |\n| 想描述复杂系统的对象、状态和变化 | [组合描述模型](compositional-description-model.md) |\n| 想理解代码、结构、状态和复杂度 | [编程之道](programming-dao.md) |\n| 想理解真实工程里的需求、维护、质量、权衡和协作 | [软件工程的朴素真理](software-engineering-truths.md) |\n| 想把探索过程变成可验证工程流程 | 本文件的方法论工具箱 |\n\n\n### 相关文档\n\n- [思维模型](thinking-models.md) - 第一性原理、奥卡姆剃刀、网络效应、多阶思维、状态空间等可复用认知工具。\n- [编程之道](programming-dao.md) - 用更抽象的方式理解代码、结构、状态、复杂度与工程判断。\n- [软件工程的朴素真理](software-engineering-truths.md) - 用底层常识理解代码、复杂度、需求、维护、质量、架构与团队。\n- [组合描述模型](compositional-description-model.md) - 对象、状态、快照、序列、过程、变换、同一/差异与关系。\n\n\n### 目录\n\n- [总体作业流](#总体作业流)\n- [推荐底座](#推荐底座python)\n- [方法论](#方法论)\n - [1. 现象学还原](#1-现象学还原悬置假设)\n - [2. 正反合](#2-正反合三段迭代)\n - [3. 可证伪主义](#3-可证伪主义波普尔)\n - [4. 形式化方法](#4-形式化方法轻量形式化)\n - [5. 奥卡姆剃刀](#5-奥卡姆剃刀最小复杂度)\n - [6. 实用主义](#6-实用主义以指标为准)\n - [7. 系统论/整体论](#7-系统论整体论边界与反馈回路)\n - [8. 诠释学](#8-诠释学语境澄清)\n - [9. 钢人化原则](#9-钢人化原则最强版本理解)\n - [10. 决策论/机会成本](#10-决策论机会成本可逆优先)\n - [11. 反事实推理](#11-反事实推理counterfactuals)\n - [12. 溯因推理](#12-溯因推理abduction最佳解释)\n - [13. 贝叶斯式信念更新](#13-贝叶斯式信念更新与溯因配合)\n - [14. 反思平衡](#14-反思平衡reflective-equilibrium)\n - [15. 概念分析/概念工程](#15-概念分析-概念工程)\n - [16. 方法论怀疑](#16-方法论怀疑笛卡尔式)\n - [17. 视角三角测量](#17-视角三角测量triangulation)\n - [18. 机制解释](#18-机制解释mechanistic-explanation)\n - [19. 错误认识论](#19-错误认识论error-epistemology)\n - [20. 实验哲学](#20-实验哲学x-phi)\n - [21. 计算哲学](#21-计算哲学computational-philosophy)\n - [22. 自然化认识论](#22-自然化认识论naturalized-epistemology)\n - [23. 贝叶斯认识论](#23-贝叶斯认识论bayesian-epistemology)\n- [候选方法整理稿（待评审）](#philosophy-methodology-toolbox-候选方法整理稿)\n- [附录](#附录)\n- [使用指南](#使用指南)\n\n---\n\n\n### 总体作业流\n\n建议默认流程：\n\n1. **现象卡片**（现象/意图/情境/边界）→ 清零脑补\n2. **规格化**（类型+schema+错误语义+不变式）→ 可机器检查\n3. **检查器**（单测+性质测试+lint+类型检查+关键断言）→ 可证伪\n4. **最小实现**（main path）→ 快速跑通\n5. **反例驱动**（Hypothesis/边界/差分/基准）→ 找到失败模式\n6. **收敛重构**（删复杂度、固化概念、稳定接口、补文档）→ 可维护\n\n---\n\n\n### 推荐底座（Python）\n\n```text\nruff + black + pyright(或 mypy) + pytest + hypothesis + pydantic(msgspec可替代)\n```\n\n---\n\n\n### 方法论\n\n\n#### 1. 现象学还原（悬置假设）\n\n**用途**：需求含糊、模型脑补、Bug难复现时，先把\"解释/偏好\"清零，回到可观察事实与可复现结构。\n\n**落地动作**：\n\n- 先写四件套：现象(实际) / 意图(期望) / 情境(环境约束) / 边界(明确不做)\n- 输出最小可复现体 MRE：最小输入 + 最小脚本 + 复现步骤 + 预期vs实际\n- 把抽象词降维：快/稳/好用 → 指标&验收用例\n\n**Python工具**：`pytest`（MRE脚本）、日志、最小数据样例\n\n**提示词**：\n\n```text\n先做现象学还原：不要推测原因。输出：现象/意图/情境/边界/未确定项/MRE；然后再给最小修复与测试。\n```\n\n---\n\n\n#### 2. 正反合（三段迭代）\n\n**用途**：把一次性\"写到完美\"替换为可控三轮：快速可用 → 反例打脸 → 收敛为工程版本。\n\n**落地动作**：\n\n- **正**：只做 main path，让它跑通\n- **反**：列失败模式（边界/空值/并发/权限/超时/性能），用测试与基准逼出反例\n- **合**：重构接口/收敛依赖/补文档与回归，形成下一轮稳定起点\n\n**Python工具**：`pytest` + `hypothesis` + `ruff/black` + profiling/benchmark\n\n**提示词**：\n\n```text\n按正反合输出：1)最小可运行实现 2)反例与失败模式+测试 3)综合后的重构方案与最终代码。\n```\n\n---\n\n\n#### 3. 可证伪主义（波普尔）\n\n**用途**：把\"看起来对\"变成\"暂时无法证伪\"；显著降低隐藏 bug。\n\n**落地动作**：\n\n- 每个关键断言都要配一个能让它失败的测试（边界/随机/反例）\n- 优先性质测试而非只写示例测试\n\n**Python工具**：`hypothesis`（性质/模糊）、`pytest`\n\n**提示词**：\n\n```text\n为该实现列出 5 个可证伪点，并为每个点写一个最小测试（优先 Hypothesis 性质测试）。\n```\n\n---\n\n\n#### 4. 形式化方法（轻量形式化）\n\n**用途**：减少非法状态、约束模型输出、让行为可检查可累积。\n\n**落地动作**：\n\n- **先规格**：类型 + schema + 不变式 + 错误集合（异常或 error object）+ 复杂度约束（可选）\n- **再检查器**：类型检查 + 运行时校验 + 断言/契约 + 性质测试\n- **最后实现**：逐条映射规格（谁保证哪条约束）\n\n**Python工具**：\n\n- `typing`（Literal/NewType/Protocol/TypedDict/Annotated）\n- `pyright/mypy`\n- `pydantic/msgspec`（输入输出校验）\n- `assert` / `icontract` / `deal`\n- `pytest` + `hypothesis`\n\n**提示词**：\n\n```text\n先输出形式化规格（类型/schema/不变式/错误语义），再给至少 3 条 Hypothesis 性质测试，最后写实现并逐条说明满足关系。\n```\n\n---\n\n\n#### 5. 奥卡姆剃刀（最小复杂度）\n\n**用途**：避免模型引入不必要框架/抽象；提升可维护性与迭代速度。\n\n**落地动作**：\n\n- 要求两套方案：常规版 vs 简化版；以测试为准删复杂度\n- 优先标准库、减少依赖、减少可变状态、减少层级\n\n**Python工具**：`ruff`（复杂度/风格）、依赖审计（requirements最小化）\n\n**提示词**：\n\n```text\n在满足全部测试与验收的前提下，把实现复杂度删掉 30%：减少依赖、状态和抽象层，并解释删减理由。\n```\n\n---\n\n\n#### 6. 实用主义（以指标为准）\n\n**用途**：避免\"优化方向漂移\"；每轮明确一个可量化目标。\n\n**落地动作**：\n\n- 先定义成功指标（P95延迟/错误率/成本/内存/可维护性）\n- 每轮只优化一个指标；其余保持不退化（用基准/回归锁住）\n\n**Python工具**：`pytest-benchmark` 或简单计时；日志与指标；回归测试\n\n**提示词**：\n\n```text\n把需求转成指标与验收阈值，并给出测量方法；本轮只优化 X 指标，保证其它指标不退化。\n```\n\n---\n\n\n#### 7. 系统论/整体论（边界与反馈回路）\n\n**用途**：复杂系统容易在耦合点失控；缩短反馈回路提效最大。\n\n**落地动作**：\n\n- 先画数据流/依赖边界：I/O 放边缘，核心逻辑保持纯函数\n- 优先解耦高耦合点；把慢依赖换成桩/模拟以加速测试\n\n**Python工具**：依赖注入（轻量）、`pytest fixtures`、纯函数设计\n\n**提示词**：\n\n```text\n画出数据流与依赖边界，指出最高耦合点与最短反馈回路改造方案；给出可测试的纯函数核心与 I/O 适配层。\n```\n\n**扩展阅读**：\n\n- [控制论与科学方法论](#控制论与科学方法论) - 用“可能性空间/反馈/信息/黑箱/可证伪”解释从试错到收敛的机制\n\n---\n\n\n#### 8. 诠释学（语境澄清）\n\n**用途**：需求文本有歧义，模型与人对同一词理解不同。\n\n**落地动作**：\n\n- 先复述需求 + 歧义清单 + 默认选择（必须显式）\n- 默认选择写入 docstring/README/类型定义\n\n**Python工具**：docstring、类型与 schema 固化默认\n\n**提示词**：\n\n```text\n先复述需求并列出所有歧义点；对每个歧义给默认策略与理由；确认后再写实现与测试。\n```\n\n---\n\n\n#### 9. \"钢人化\"原则（最强版本理解）\n\n**用途**：减少无效争论/误解；让重构建议更贴近原意图。\n\n**落地动作**：\n\n- 先把现有方案表达成最强版本（目标、约束、权衡）\n- 再提出改进（保留其优势，指出代价）\n\n**Python工具**：PR描述结构化（优点/风险/替代方案）\n\n**提示词**：\n\n```text\n先钢人化现有实现：列出它的最佳解释与优点；再给改进方案并明确代价与风险。\n```\n\n---\n\n\n#### 10. 决策论/机会成本（可逆优先）\n\n**用途**：避免过早做不可逆技术决策（换框架/改数据模型）。\n\n**落地动作**：\n\n- 标注决策：可逆 vs 不可逆；优先做可逆高价值项\n- 先写接口+测试桩+适配层，延后绑定外部系统\n\n**Python工具**：抽象边界、adapter、in-memory 实现\n\n**提示词**：\n\n```text\n把方案拆成可逆/不可逆决策；先给可逆路径的 MVP，实现通过测试；不可逆部分只给接口与占位实现。\n```\n\n---\n\n\n#### 11. 反事实推理（Counterfactuals）\n\n**用途**：系统性覆盖异常路径，降低线上事故。\n\n**落地动作**：\n\n- 问\"如果 X 不成立会怎样\"：超时、乱序、重复、空值、弱网、权限缺失、时钟漂移\n- 把反事实转成测试矩阵与降级策略\n\n**Python工具**：`pytest` 参数化、`hypothesis` 生成器、超时与重试控制\n\n**提示词**：\n\n```text\n列出 15 个反事实场景并按风险排序；为 Top5 写测试与降级/错误语义。\n```\n\n---\n\n\n#### 12. 溯因推理（Abduction，最佳解释）\n\n**用途**：debug/性能退化时，比穷举更快定位\"最可能原因\"。\n\n**落地动作**：\n\n- 列候选原因 → 为每个原因写最便宜的区分性实验（日志点/开关/最小基准）\n- 用证据淘汰而不是凭感觉改代码\n\n**Python工具**：结构化日志、trace、最小 benchmark、feature flag\n\n**提示词**：\n\n```text\n给出候选原因列表，并为每个原因提供一个最低成本、最高区分度的验证实验与预期观察。\n```\n\n---\n\n\n#### 13. 贝叶斯式信念更新（与溯因配合）\n\n**用途**：在不确定下理性分配排查时间。\n\n**落地动作**：\n\n- 给假设先验（高/中/低）→ 实验后更新后验排序\n- 只对后验最高的 1-2 个假设投入修改成本\n\n**Python工具**：同 12；加一张\"假设-证据\"表\n\n**提示词**：\n\n```text\n按先验排序原因；给最信息增益实验；根据可能结果更新排序并给下一步。\n```\n\n---\n\n\n#### 14. 反思平衡（Reflective equilibrium）\n\n**用途**：当用例、原则、约束冲突时收敛规范（尤其 API 语义、错误处理、兼容性）。\n\n**落地动作**：\n\n- 三层对齐：具体用例 ↔ 一般原则 ↔ 系统约束\n- 用测试固化：回归用例（具体判断）+ 性质测试（原则）\n\n**Python工具**：`pytest` + `hypothesis`；规范文档（错误模型/幂等语义）\n\n**提示词**：\n\n```text\n列出用例/原则/约束三集，指出冲突点；给两轮调整方案，每轮说明要改哪些用例、原则或实现以达成一致。\n```\n\n---\n\n\n#### 15. 概念分析 / 概念工程\n\n**用途**：防止术语漂移导致返工；把领域概念固化进代码。\n\n**落地动作**：\n\n- 概念表：术语/定义/边界/不变量/转换关系\n- 概念工程：用 Enum/Literal/NewType/dataclass(frozen) 与 schema 固化边界；禁止混用\n\n**Python工具**：`Enum`、`Literal`、`NewType`、`pydantic` 校验\n\n**提示词**：\n\n```text\n先产出概念表；再映射成 Python 类型与 schema；给 5 个应被拒绝的反例输入，并写对应测试。\n```\n\n---\n\n\n#### 16. 方法论怀疑（笛卡尔式）\n\n**用途**：把不可靠前提当事实是 vibe coding 常见事故源。\n\n**落地动作**：\n\n- 对关键前提标注：是否可验证\n- 不可验证 → 必须加运行时校验/超时/重试/降级；并写会失败的测试\n\n**Python工具**：`assert`/校验器、超时、重试、容错分支测试\n\n**提示词**：\n\n```text\n列出该方案依赖的所有前提，并标注可验证性；对不可验证前提添加防线（校验/超时/降级）与对应测试。\n```\n\n---\n\n\n#### 17. 视角三角测量（Triangulation）\n\n**用途**：减少单一证据的误判；提升结论可靠性。\n\n**落地动作**：\n\n- 同一结论至少两种证据：单测/性质测试 + 日志/指标；或差分测试 + fuzz\n\n**Python工具**：`pytest`/`hypothesis` + metrics/logging；差分对照\n\n**提示词**：\n\n```text\n对关键行为给出至少两种独立验证方式，并说明各自盲区与如何互补。\n```\n\n---\n\n\n#### 18. 机制解释（Mechanistic explanation）\n\n**用途**：把\"能跑\"变成\"可解释可维护\"；降低未来修改风险。\n\n**落地动作**：\n\n- 要求输出数据流：输入 → 中间状态 → 输出\n- 对中间状态写不变式/断言；把解释与代码结构对齐\n\n**Python工具**：`assert`、类型收窄、分层函数、docstring\n\n**提示词**：\n\n```text\n给出机制解释：数据在系统中如何流动；列出每个中间状态的不变式，并在代码中用断言或类型保证。\n```\n\n---\n\n\n#### 19. 错误认识论（Error epistemology）\n\n**用途**：系统化\"我们会如何错\"，比事后补洞更省。\n\n**落地动作**：\n\n- 先做失败模式清单（空值/乱序/重复/并发/权限/超时/编码/浮点等）\n- 每类至少一个测试；明确错误语义（raise / error object / log+metric）\n\n**Python工具**：`pytest` 参数化 + `hypothesis`；统一 error 模型\n\n**提示词**：\n\n```text\n生成失败模式清单并按风险排序；为 Top N 写测试；统一错误模型并给出示例响应/异常层级。\n```\n\n---\n\n\n#### 20. 实验哲学（x-phi）\n\n**用途**：交互与默认策略别靠直觉，用数据决定。\n\n**落地动作**：\n\n- 把争议点改成可测实验（A/B 默认值、错误文案、重试策略）\n- 指标：误用率、重试率、成功率、工单率、完成时间\n\n**Python工具**：埋点/日志、简单 A/B 分组、配置开关\n\n**提示词**：\n\n```text\n把该设计争议转成实验：分组、指标、样本、持续时间、判定阈值；给出埋点字段与分析方法。\n```\n\n---\n\n\n#### 21. 计算哲学（Computational philosophy）\n\n**用途**：复杂状态与规则用\"可运行模型/仿真/搜索\"代替纯讨论。\n\n**落地动作**：\n\n- reference 实现（慢但清晰）作为 oracle\n- optimized 实现（快/工程化）用差分测试锁死行为\n- 用仿真/生成器自动探索边界\n\n**Python工具**：`hypothesis`、差分测试、状态机测试（Hypothesis stateful）\n\n**提示词**：\n\n```text\n先写 reference（清晰）+ optimized（高效）；写差分测试与状态机/性质测试自动找反例并修复。\n```\n\n---\n\n\n#### 22. 自然化认识论（Naturalized epistemology）\n\n**用途**：承认人类/模型都有系统性偏误，用流程与工具把偏误外包给检查器。\n\n**落地动作**：\n\n- 默认自动化：lint+format+类型检查+测试\n- 高风险路径：必须性质测试/模糊测试/运行时校验\n- 结论至少双证据（测试+指标）\n\n**Python工具**：`ruff`/`black`/`pyright`/`pytest`/`hypothesis`/`pydantic`\n\n**提示词**：\n\n```text\n列出该任务最常见的误判点，并为每个误判点给一个自动化防线（检查器/测试/断言/埋点）。\n```\n\n---\n\n\n#### 23. 贝叶斯认识论（Bayesian epistemology）\n\n**用途**：在多个方案/原因间理性分配注意力与试错预算。\n\n**落地动作**：\n\n- 先验 → 实验 → 后验 → 下一步；把排查变成序列决策问题\n\n**Python工具**：同 12/13；记录表\n\n**提示词**：\n\n```text\n用贝叶斯式流程组织排查：先验排序、信息增益最高的实验、更新后的行动计划。\n```\n\n---\n\n\n### 附录\n\n\n#### 通用\"性质测试\"提示（可复用）\n\n| 性质 | 说明 |\n|:---|:---|\n| 非负性/有界性 | 结果不越界 |\n| 幂等性 | `f(f(x)) == f(x)` |\n| 单调性 | 输入增大输出不违反预期 |\n| 守恒性 | 长度/集合元素/总和按规则变化 |\n| 互逆性 | `decode(encode(x)) == x`（或近似） |\n| 稳定性 | 排序/去重等操作满足稳定条件 |\n| 交换/结合 | 满足代数性质的操作应通过 |\n\n\n#### 建议的项目框架（最小）\n\n```text\nsrc/ # 纯逻辑与 I/O 分离\ntests/ # 示例+性质+差分\npyproject.toml # ruff/pytest/pyright\nREADME.md # 概念表/错误语义/验收指标\n```\n\n---\n\n\n### 使用指南\n\n| 场景 | 推荐方法组合 |\n|:---|:---|\n| 需求不清 | 1（现象学）+ 8（诠释学）+ 15（概念工程） |\n| 质量不稳 | 3（可证伪）+ 4（形式化）+ 19（错误认识论） |\n| 排错提效 | 12（溯因）+ 13/23（贝叶斯更新）+ 17（三角测量） |\n| 复杂系统 | 7（系统论）+ 21（计算哲学）+ 14（反思平衡） |\n| 交互默认争议 | 20（x-phi）+ 6（实用主义指标） |\n\n\n#### 现象学还原用于 Vibe Coding\n\n**核心目的**：把“我以为需求是这样”从对话里剥离出去，只留下可观察、可复现、可检验的事实与体验结构，让模型在更少臆测的前提下产出可用代码。\n\n工程语境下的三个动作：\n\n- **悬置**：暂时不采纳任何原因解释、业务推断或最佳实践偏好，只记录发生了什么、期望是什么、约束是什么。\n- **还原**：把问题还原到“给定输入 -> 经过过程 -> 得到输出”的最小结构，先不谈架构、模式、技术栈优雅与否。\n- **意向性**：明确这个功能是为谁、在什么情境下、要达成什么体验；不要停在“做个登录”，要落到“用户在弱网下也能在 2 秒内完成登录并得到明确反馈”。\n\n适用场景：\n\n- 需求描述充满抽象词：快、稳定、像某某一样、智能、顺滑。\n- 模型开始自带设定：自己补产品逻辑、乱选框架、擅自加复杂度。\n- Bug 复现困难：偶发、环境相关、输入边界不清。\n\n操作流程：\n\n1. 先清空解释，只保留现象：现象、意图、情境、边界。\n2. 产出最小可复现体：最小输入、最小代码片段、明确复现步骤、预期 vs 实际。\n3. 把抽象词降维成可测指标：快 -> P95 延迟，稳定 -> 错误率，好用 -> 交互反馈与可恢复性。\n\n可复制提示词：\n\n```text\n请先做“现象学还原”：不要推测原因、不要引入额外功能。\n只根据我给的信息，输出：\n1) 现象（可观察事实）\n2) 意图（我想要的可观察结果）\n3) 情境（环境/约束）\n4) 未确定项（必须问清或需要我补的最小信息）\n5) 最小可复现步骤（MRE）\n然后再给出最小修复方案与对应测试。\n```\n\n口诀：先悬置解释，再固定现象；先写验收标准，再让模型写实现。\n\n\n#### 辩证法用于 Vibe Coding：正反合\n\n把辩证法的“正反合”用于 Vibe Coding，就是把每次写代码都当成一轮可控的三段论。\n\n**正：当前状态，先跑通**\n\n- 让模型按直觉快速给出最顺的实现。\n- 目标只有一个：尽快跑通主路径。\n\n**反：审计与调优，再打脸**\n\n- 立刻站在挑刺者视角反驳它。\n- 列出失败模式、边界条件、性能与安全隐患。\n- 用测试、类型、lint、基准把反驳落地。\n\n**合：根据审核修正，再收敛**\n\n- 把速度与约束合起来。\n- 重构接口、收敛依赖、补齐测试与文档。\n- 形成下一轮更稳定的起点。\n\n实践口诀：先顺写 -> 再打脸 -> 再收敛。\n\n一句话：Vibe 负责生成可能性，正反合负责把可能性变成工程确定性。\n\n\n#### 控制论与科学方法论\n\n控制论视角下，工程实践不是一次性生成，而是通过信息、反馈和约束持续收缩可能性空间。\n\n核心要点：\n\n1. 控制的逻辑起点是被控对象存在多种可能状态；控制的本质是通过选择手段，让可能性空间朝目标状态收缩。\n2. 改造世界的实践，本质是在多维可能性空间中选择物质、条件和时机，最终把低概率组合实现为确定结果。\n3. 控制能力可以理解为控制前后可能性空间大小之比；任何工具或方法都有能力上限。\n4. 负反馈通过比较现状与目标的差距并采取行动缩小差距，把有限的单次控制能力累积放大。\n5. 正反馈会自我增强，使状态持续偏离初始平衡点，可能导致增长、演化、崩溃或恶性循环。\n6. 信息是对系统不确定性的减少；控制要实现，必须先获得足够信息。\n7. 控制与信息是一体两面：信息改变认知状态，控制改变现实状态。\n8. 组织是一种结构状态，组织化程度越高，结构中包含的信息量越高。\n9. 复杂系统的因果关系常常是概率因果、反馈环和因果网络，而不是单一线性链条。\n10. 有效分析必须建立“相对孤立系统”，把无限问题切成有限问题。\n11. 拥有内部反馈回路的系统会趋向稳态结构，用动态平衡抵御外部随机干扰。\n12. 系统演化通常是旧稳态被破坏，经过不稳定过渡，落入新稳态。\n13. 自组织系统会在没有外部指令时，由内部相互作用从无序涌现出宏观有序。\n14. 质变可以是渐变，也可以是飞跃；关键不在变化速度，而在中间状态是否稳定。\n15. 黑箱认识依赖输入控制与输出观察，理论就是对黑箱内部结构的模型。\n16. 认识过程是“实践 -> 理论 -> 实践”的负反馈循环，用模型预测与现实输出的差异修正模型。\n17. 认识反馈能否收敛，取决于理论是否可证伪、反馈速度是否足够快、反馈幅度是否不过度、实践结果是否能可靠判别理论真伪。\n18. 科学规律的本质是变量之间的约束关系；掌握规律，就是把不可控随机变量转成可预测、可控制的确定结果。\n\n用于 AI 编程时，这套方法可以压缩成一句话：\n\n> 先把目标写成可检验状态，再用测试、日志、反馈、约束和迭代，把模型输出从可能性空间中逐步收缩到可验收结果。\n\n---\n\n\n### 候选方法整理稿（待评审）\n\n> 本节把若干可独立描述的框架和操作方法整理成候选稿。交叉核对后，优先审查“最小论证结构”“库、包与 API 能力阶梯”“最小模型—迁移—边界回填”及3项跨域来源候选；6项仍只在文稿和冻结来源选区中，尚未写入`registry.json`或生成总表。2026-10-14续审补充了主题粒度和来源投影意见：P15暂不作为施行方法，A为跨域合成，C的候选投影仅含1条操作记录；这些是待审意见，不构成登记、类型、品级或效果批准。其余备忘录候选按下方结果合并或暂缓。按当前整理要求，不列外部真实来源、作者或机构归属；不确定的归属和未经定义的主张不写成事实。\n\n#### 候选：分类判准形成链\n\n**用途**：把一组对象整理成可解释、可复核的分类，而不是只凭名称或直觉归类。\n\n**落地动作**：\n\n1. 明确分类对象、任务和边界。\n2. 列出对象的规定性与可观察差异。\n3. 选择与当前任务有关的判准，区分必要条件、充分条件和仅供参考的特征。\n4. 按判准归并对象，并检查边界样例、反例与无法归类项。\n5. 记录分类结论及判准变更的影响。\n\n**产物**：对象范围、判准表、分类结果、边界样例和待澄清项。\n\n**边界**：分类结果依赖目标和判准；分类不自动证明对象之间存在自然或永久的等级关系。\n\n\n#### 候选：最小论证结构\n\n**用途**：检查一项判断是否有支撑，而不把结论、证据和推理过程混为一谈。\n\n**落地动作**：\n\n1. 写出待判断的结论。\n2. 列出支撑结论的依据，并标明依据是观察、数据、规则还是假设。\n3. 写出“依据如何推出结论”的连接规则。\n4. 补充适用条件、限制和可能推翻结论的反例。\n\n**产物**：结论、依据、连接规则、条件与反例清单。\n\n**边界**：结构完整不等于依据真实，也不保证推理规则正确；需要分别核对来源、逻辑和适用范围。\n\n#### 候选：输入—操作—输出模型\n\n**用途**：用最小结构描述一个工具、程序或任务步骤的行为。\n\n**落地动作**：\n\n1. 明确输入及其范围、单位和前置条件。\n2. 说明执行的操作、工具或变换。\n3. 定义输出、失败语义和可观察结果。\n4. 仅在任务需要时补充状态、环境、反馈、权限和副作用。\n\n**产物**：输入/操作/输出契约及必要的失败和副作用清单。\n\n**边界**：这是描述框架，不替代状态模型、数据契约或系统边界分析；不需要的字段不应为了形式完整而添加。\n\n#### 候选：问题入口三问\n\n**用途**：把模糊需求拆成对象、理由和行动三个待回答问题。\n\n1. **是什么**：当前讨论的对象、问题或期望结果是什么？\n2. **为什么**：它为什么重要，受什么原因、约束或证据支撑？\n3. **怎么做**：哪些行动能够产生可观察、可验收的结果？\n\n**产物**：问题描述、理由/证据和候选行动；信息不足时显式保留未知项。\n\n**边界**：三问是入口提示，不代表因果已证明，也不替代需求、风险和验收定义；可以按任务跳过无关问题。\n\n#### 候选：工作系统层级分解\n\n**用途**：把过大的工作范围逐层分解到可以分配、执行和验收的动作。\n\n**落地动作**：\n\n1. 定义领域和要达成的结果。\n2. 按需要分解为价值链、流程类别、流程组、流程、活动、任务、步骤和动作。\n3. 为每个拆分项标明输入、输出、责任边界和依赖。\n4. 检查遗漏、重叠和无法组合的子项；到足以执行与验收时停止分解。\n\n**产物**：层级分解图、依赖关系及可验收工作项。\n\n**边界**：并非所有领域都需要全部层级；层级名称不是固定本体，也不应为了树形完整而制造子项。\n\n#### 候选：编程思考四步\n\n**用途**：在实现前后组织工程判断，避免直接从模糊需求跳到代码。\n\n**落地动作**：\n\n1. **分析与拆解**：确定目标、约束、现状和子问题。\n2. **抽象与建模**：建立足以表达问题的对象、状态、关系或接口。\n3. **判断与取舍**：比较方案、成本、风险、可逆性和验收条件。\n4. **归纳与总结**：根据验证结果更新模型、记录边界并删除无用复杂度。\n\n**产物**：问题结构、方案取舍、验证结果和必要的维护记录。\n\n**边界**：这四步可往返，不是每个任务都必须按固定线性顺序执行；已有详细流程优先沿用，不重复建立平行工作流。\n\n#### 候选：问题表示结构选择\n\n**用途**：根据问题中的关系选择表示方式，避免默认用一种图或表承载所有问题。\n\n| 问题结构 | 可选表示 |\n|---|---|\n| 层级、分类或分解 | 分类树、问题分解树 |\n| 依赖、关系或相互影响 | 依赖图、关系图 |\n| 时间顺序与阶段 | 时序图、里程碑序列 |\n| 状态及状态变化 | 状态空间、状态转移系统 |\n| 原因及影响路径 | 因果图或因果树 |\n| 备选方案及分支 | 决策树 |\n| 事件及其后续分支 | 事件树 |\n| 目标分层与策略映射 | 策略树、指标树 |\n| 条件分支、状态转移或方案比较 | 条件树、状态转移系统、表格或决策矩阵 |\n\n**落地动作**：先说明问题要表达的关系，再选择表示；检查表示是否保留了必要信息、是否隐藏了不确定性，以及读者能否从中作出下一步判断。\n\n**边界**：图表是表达载体，不是证据；不能因为画出树或图就声称因果、完整性或决策正确。\n\n\n#### 候选：最小模型—迁移—边界回填\n\n**用途**：为复杂问题建立足够简单的模型，并谨慎借用相似结构提出待验证方案。\n\n**落地动作**：\n\n1. 明确目标、对象、关键变量及已知约束。\n2. 暂时删去与当前问题无关的细节，保留关键关系，得到最小模型。\n3. 搜索可对照的案例或模型，明确来源案例与当前目标问题的对应关系；优先对齐关系结构而非表面相似，逐项记录对象/角色对应，并检查关系论元和高阶约束是否一致。\n4. 将类比推得的结论先标为假设；分别检查结构映射是否成立、推论是否符合目标域事实及是否与当前目标相关；列出映射失配条件、被忽略变量与反例。\n5. 把现实约束、失败模式和边界条件加回模型；用目标域证据、反例或合适的低成本实验验证关键推论，根据结果修订或拒绝迁移。\n\n**产物**：最小模型、对应关系、遗漏变量、迁移边界和验证项。\n\n**边界**：类比推论不是事实；结构映射不保证目标域事实正确或与当前问题相关，须另用目标域证据核验。无法说明对应关系或验证条件时，不迁移结论。\n\n#### 候选：对照式分析\n\n**用途**：针对一个明确问题选取少量分析轴，对照方案、约束或状态，暴露容易遗漏的差别。\n\n**可选分析轴**：深度/广度、时间/空间复杂度、组合/分解、先验/后验、前兆/后继、真/假、事实/价值、相关/因果、直接/间接、内生/外生、现象/本质、目标/约束、目的/手段、收益/成本、确定/不确定、局部/整体、内部/外部、短期/长期、静态/动态、可逆/不可逆、必要/充分、量/质、存量/流量、平均/边际、绝对/相对。\n\n**落地动作**：选取与验收目标相关的轴；分别记录两端的定义、证据和边界；检查两端是否穷尽、互斥，或只是为了分析临时设定的对照。\n\n**边界**：这些轴不是固定分类，也不都构成严格二分。“深度/广度”等词必须结合任务定义；原始清单中重复或含义不清的轴不擅自修正。\n\n\n#### 候选：库、包与 API 能力阶梯\n\n**用途**：规划从调用现成组件到能安全组合、排错和维护组件的学习与工程能力。\n\n1. **调用**：按接口使用组件，理解输入、输出和错误。\n2. **选择**：按需求、许可证、维护状态、兼容范围和运行约束比较方案。\n3. **组合**：处理接口契约、依赖关系、配置和版本边界。\n4. **调试与测量**：定位失败原因及性能瓶颈，区分组件问题与集成问题。\n5. **修改或适配**：在可维护边界内封装、替换或扩展组件。\n6. **设计或构建**：仅在成熟方案不满足关键约束时，才承担自建和长期维护成本。\n\n**检查问题**：接口承诺是什么？调用前提是什么？失败如何表达？依赖如何锁定？许可证和维护状态是否可接受？升级与回滚如何处理？\n\n**边界**：阶梯表示能力范围，不是功法品级或个人评价；高级别不天然优于复用成熟组件。\n\n#### 候选：数学任务三层流程\n\n**用途**：在需要数学建模或计算时区分问题形式化、符号推演和实际执行。\n\n1. **形式化**：定义对象、变量、范围、假设和要证明或求解的目标。\n2. **符号计算**：应用规则进行推导、变换或构造解。\n3. **计算执行**：选择算法、数值计算、模拟或工程实现，并检查误差与边界。\n\n**边界**：只适用于需要这些层次的数学/计算任务；定义、公理、定理、矩阵、微积分、算法等名称本身不是独立方法。\n\n\n#### 候选：误差预算与不确定性传播\n\n**用途**：判断测量、近似、模型或数值算法中的不确定性会怎样影响最终结论，以及结论是否仍满足决策容忍度。\n\n**落地动作**：\n\n1. 定义目标量、决策容忍度与所需误差口径。\n2. 分解测量、近似、模型和数值误差来源，记录可能的相关性与系统偏差。\n3. 区分问题条件性、算法稳定性与结果准确性。\n4. 按模型传播或估计误差界/区间，并检查残差、边界情形和量纲。\n5. 报告主导误差来源、结论范围和无法量化的未知项。\n\n**产物**：误差来源与相关性清单、传播范围或误差界、容忍度比较及未知项。\n\n**边界**：标准差或置信区间不自动构成最坏界；遗漏系统误差、相关性或模型错设会破坏结论；数值稳定不等于结果准确。无法估计时应收缩结论，不补造精度。\n\n\n#### 候选：文献综合与证据缺口图谱\n\n**用途**：综合多份研究资料，区分有支持、相互冲突、方法不可比和仍缺证据的部分。\n\n**落地动作**：\n\n1. 界定问题、时间范围及纳入/排除规则。\n2. 按来源质量、研究方法和相关性分层。\n3. 提取各来源的主张、数据、方法、结果和限制，并保留出处关系。\n4. 比较异质性、冲突与共同限制，再形成限定范围的综合结论。\n5. 列出未解决的问题及下一步需要的证据。\n\n**产物**：可追溯的主张—证据关系、支持与冲突摘要、适用范围和证据缺口清单。\n\n**边界**：不能把多篇摘要拼接当成共识；来源选择偏差、二手转述和方法不可比会扭曲结论；“未检索到”不等于“没有研究”。\n\n\n#### 候选：检索质量与证据覆盖审计\n\n**用途**：在检索结果集已经形成后，检查相关性、召回、排序和重要漏检；不负责设计检索策略、扩展查询或执行检索。\n\n**适用前提**：信息需求、结果集、相关性标准和可复核判断集已定义。没有独立判断集时不报告 precision/recall。\n\n**落地动作**：\n\n1. 固定查询、结果集与评估集版本，明确主题/证据/用途相关性规则。\n2. 抽样标注相关、不相关、部分相关及来源权威层级，并记录分歧。\n3. 按判断集计算 precision、recall、排序质量及可支持的分层差异。\n4. 检查漏检、重复、来源偏置和评估集泄漏。\n5. 报告覆盖边界与判断不确定性；判断不一致时补独立判断或修订相关性规则。\n\n**产物**：绑定查询、判断规则、标注样本、指标、漏检案例和评估集版本的检索审计报告。\n\n**边界**：这是针对既有结果集的单一审计算子，不包含信息需求制定、检索式扩展或证据检索循环；没有相关性标准就不能解释指标，排名/链接/引用数量不等于证据充分，“未检索到”也不证明证据不存在。\n\n#### 候选交叉核对与本轮取舍（2026-10-13；2026-10-14补充）\n\n> 对照基线总表为410条（79条登记、331条历史来源候选）。下表把工具集候选P01–P32、已归一化的11项备忘录草稿和Solve A–J主题映射到现有登记及历史候选详情；P编号与11项草稿是同一批素材的不同整理视图，不重复计数。表中拟议ID不是已分配身份。Solve的556个ID已完成来源级导出，但未逐条与410条做完整语义比较；定向核对按批次覆盖A–J的候选主题、相邻条目与有限冻结选区（最初A–F共6项，后续追加G–J），不构成全量语义去重。编号需严格区分：本体主文中的C01–C20是“分类验收判例”；不可变历史候选快照使用C001–C010、C012–C021（C011为排除视图），两者均不能据相近编号认作对话所指的候选包。当前仍未找到能绑定该候选包身份、定义与来源的独立冻结清单，故不声称已逐项裁决。候选状态不代表正式登记、类型确认、品级或效果。\n\n| 工具集候选 | 对照与处理 |\n|---|---|\n| P01 分类形成链 | 与`gongfa-concept-engineering`、`gongfa-state-classification`对齐；现有内容覆盖主要分类与概念边界，判准链未显示足够独立增量。 |\n| P02 论证最小结构 | 作为结论—依据—推理连接—适用条件/反例的检查框架，初步看与`gongfa-steelmanning`（重建最强观点）和`gongfa-evidence-triangulation`（比较独立证据渠道）相邻但不等同；可继续按`method-specification`候选评审。来源仍是仓内备忘录，不代表外部来源核实或效果证据；拟议ID `gongfa-minimal-argument-structure`尚未分配。 |\n| P03 输入—处理—输出模型 | 对齐`gongfa-compositional-description`、`gongfa-input-state-transform-separation`和`gongfa-stable-interface-contract`；作为最小表征素材，不再建立平行模型。 |\n| P04 目标—指标—反馈优化 | 合并到`gongfa-methodology-delivery-loop`、`gongfa-performance-by-measurement`及实验/信念更新相关内容；目标、指标和更新不能脱离具体验收独立成通用闭环。 |\n| P05 误差反馈迭代闭环 | 对齐`gongfa-problem-definition-framework`、`gongfa-methodology-delivery-loop`、`gongfa-abductive-debugging`和`gongfa-counterfactual-testing`；不重复登记总流程。 |\n| P06 当前状态—目标状态—差距 | 对齐`gongfa-purpose-directed-action`、`gongfa-solution-space`和`gongfa-problem-definition-framework`。 |\n| P07 工作系统层级分解 | 由`gongfa-top-down-system-design`、`gongfa-bottom-up-system-building`和`gongfa-divide-and-conquer`覆盖；层级词表不独立成方法。 |\n| P08 编程思考四步 | 合并到问题定义和`gongfa-methodology-delivery-loop`；未显示优于现有闭环的独立交接规则。 |\n| P09 “是什么—为什么—怎么做” | 作为`gongfa-problem-definition-framework`的提问入口，不另立功法。 |\n| P10 多结构信息表示选择 | 暂缓；`gongfa-state-space-thinking`、`gongfa-solution-space`、`gongfa-representation-flattening`和`gongfa-projection-representation`覆盖相邻对象，但候选仍缺可判定的表示选择条件。 |\n| P11 问题求解认知流程 | 对齐`gongfa-problem-definition-framework`和`gongfa-methodology-delivery-loop`；阶段次序及停止条件没有独立增量。 |\n| P12 古文抽象求解流程 | 合并到问题求解、失败预演和架构权衡；巨型流水线会与现有流程并行且难验证各阶段边界。 |\n| P13 任务完成六阶段 | 合并到求解闭环、胶水原则、验证和复盘；不建第二条总工作流。 |\n| P14 解决方案复用决策 | 与`gongfa-glue-principle`、`gongfa-glue-coding`实质重叠，不新增。 |\n| P15 库/包/API能力阶梯 | 初步判为能力/学习进阶框架，而非单次任务的施行方法：六阶描述从调用到设计的能力范围，不构成必须依次执行的操作程序。与`gongfa-glue-principle`、`gongfa-glue-coding`、历史候选B005（API承诺与兼容性）及VC015（第三方API选择）相邻；若保留，先按`explanatory-content`方向审查正文归属，不作为已确认的`method-specification`；阶梯不代表个人评价或品级。拟议ID `gongfa-library-api-capability-ladder`尚未分配。 |\n| P16 对照式分析 | 暂缓；当前是可选分析轴清单，不是有选轴规则和反例的独立操作方法。 |\n| P17 表征变换与关系操作 | 分别并入`gongfa-compositional-description`、`gongfa-evidence-triangulation`及溯因/迁移等具体操作；不把动作名词表批量登记。 |\n| P18 数学三层工作流 | 暂缓为学科专用候选；`gongfa-lightweight-formal-methods`只覆盖形式化的一部分，未证明整条数学流程适用于通用编码任务。 |\n| P19 最小模型—迁移—边界回填 | 作为复合施行方法候选继续评审：最小化建模、关系结构映射、边界回填和目标域验证组成一条编辑性操作路径；与`gongfa-first-principles`、`gongfa-thought-experiment`、`gongfa-representation-flattening`及研究迁移相邻但不等同。有限外部文献对照见[复核快照](../../metadata/gongfa/source-selected-candidate-minimal-model-transfer-boundaries-20261015.txt)，仅支持关系映射与推论评估的局部概念，不证明整套流程的来源、独立身份或软件工程效果。来源仍是仓内备忘录；不恢复未经核验的Shannon归属，拟议ID `gongfa-minimal-model-transfer-boundaries`尚未分配。 |\n| P20 古文次序与渐进准则 | 对齐增量开发、规格先行与总体作业流；格言依赖情境，不单独立项。 |\n| P21 根因、机制与系统效应 | 对齐`gongfa-systems-boundary-feedback`、`gongfa-mechanistic-explanation`、`gongfa-proximate-causal-mechanism`及事故复盘；故事本身不证明工程规律。 |\n| P22 证据、认知与反偏差 | 对齐来源批判、证据三角测量、可证伪主义和错误认识论；典故作为反例素材。 |\n| P23 策略、资源与利害取舍 | 对齐可逆决策、架构权衡及机会成本；古代策略故事不直接外推为编码方法。 |\n| P24 迁移、学习与实践 | 作为学习、胶水复用和类比迁移的素材；逐项缺少独立操作及来源时不批量立项。 |\n| P25 渐进执行顺序模板 | 合并到增量开发、迭代和复盘；不把格言次序写成所有任务的固定线性阶段。 |\n| P26 主张/现实、角色/主体等区分 | 对齐组合描述与本体主文；概念边界不是独立施行方法。 |\n| P27 完整工作系统描述模型 | 对齐组合描述、系统边界、状态分类和依赖图；避免第二套系统字段表。 |\n| P28 动态系统闭环模型 | 对齐系统边界与反馈、固定点收敛和受约束状态变换，不新增同义系统模型。 |\n| P29 学习方法候选簇 | 暂缓；各项仍需分别核对权威来源、操作步骤、适用条件和验收，不按机构或方法名称批量登记。 |\n| P30 性能评估/优化流程 | 合并到性能测量、统计工具箱、风险驱动测试和持续性能工程；区分方法、指标、报告与工具。 |\n| P31 工具组合/能力编排 | 对齐胶水原则、拼好码、稳定接口和显式依赖；不另造组合框架。 |\n| P32 实践复盘闭环 | 对齐问题求解、`gongfa-methodology-delivery-loop`和事故复盘；事故归因与一般复盘仍按证据边界区分。 |\n\n| Solve主题 | 对照与处理 |\n|---|---|\n| A 误差预算与不确定性传播 | 冻结选区含6条来源（3条`MethodSpec`、3条`OperatorSpec`）：确定性误差界、概率不确定度传播、问题条件性与算法稳定性、自适应误差控制、残差/后向误差审计、测量不确定度预算。它们的对象、前提、输出与证据合同不同；选区未提供统一的分支条件或组合协议，现有跨域线性步骤属于编辑综合而非来源共同定义的方法。因此撤回将其作为单一方法候选保留的初步倾向，暂不整体纳入，也不自动拆成6项。与历史候选D011“性能统计工具箱”、VC100“门槛导向抽样”、VC099“校准估计”相邻但不等同。重启需先明确学科专用范围及复核人，或冻结能定义适用分支、输入输出和组合规则的派生方法来源；拟议ID `gongfa-error-uncertainty-budget`尚未分配。 |\n| B 文献综合与证据缺口图谱 | 冻结选区只含`psoa.research.literature-synthesis`（`MethodSpec`）；原条目明确研究问题/范围、来源分层、主张与方法提取、异质性比较、支持/冲突/空白产物及停止条件。其跨研究综合不同于历史候选`psoa.research.source-criticism`的单来源质量审查，也不同于`gongfa-evidence-triangulation`的独立渠道交叉核验；在已检查的410条目录与Excel首轮对照中未见同等综合流程。因此语义上可保留为来源绑定的待审候选，但本轮快照用途仅为溯源与人工评审；是否写入机器登记仍须另行确认。外部引文、许可、效果及556→410全量语义去重均未验证；拟议ID `gongfa-literature-synthesis-evidence-gaps`尚未分配。 |\n| C 检索质量与证据覆盖审计 | 冻结投影仅含`psoa.information-knowledge-science.relevance-precision-recall-audit`（`OperatorSpec`）；其前提、步骤与产物支持对既有结果集按明确相关性规则和可用判断集审计precision/recall、排序及漏检。它不支持把信息需求制定、检索式扩展或证据检索循环一并包装进同一候选。与VC019“代码RAG”用途、VC065“Skill路由条件设计”中的指标使用边界相邻，但在已检查的410条目录与Excel首轮对照中未见同一审计算子；故语义上可保留为收窄后的来源绑定待审候选。机器登记仍需另行确认；首轮结果不等于556→410全量语义去重，许可、独立审查与效果未验证；拟议ID `gongfa-retrieval-quality-evidence-coverage`尚未分配。 |\n| D 摊销分析 | 冻结记录`psoa.algorithms.amortized-analysis`（`.entries[0]`）是算法操作序列的成本上界方法；MIT 6.046J Lecture 5直接讲授aggregate、accounting、charging与potential方法，并明确摊销成本不必是统计平均；CS2023 Body of Knowledge第30页将其列为`AL-Complexity`的`KA Core`。原`ref:mit-algorithms`只指向课程主页，原`ref:cs2023` PDF URL当前返回404，替代官方BoK文件仅用于本次核对。总表Markdown/Excel关键词检索没有命中，不构成556→410全量语义去重；该方法不同于一般复杂度约束、阿姆达尔定律或利特尔法则。Solve摘要“平均代价”易与概率平均混淆，`agent loop`/缓存应用也未被算法讲义验证。故本轮只冻结来源供审查，不分配项目ID、不写机器登记或总表、不赋级；后续需修订来源绑定、核验版本/许可并限定软件应用成本合同。详见`.github/metadata/gongfa/source-selected-candidate-amortized-analysis-20261014.txt`。 |\n| E 内核核验的证明证据 | 当前Solve记录`psoa.formal-logic-automated-reasoning.kernel-checked-proof-evidence`为`MethodSpec`，另有`psoa.formal-logic-automated-reasoning.formal-reasoning-loop`派生复合项；这里的“内核”指形式证明系统中的小型可信检查内核，不是操作系统内核。前者固定主张、上下文、公理、证明项与工具版本，再由内核/等价小检查器复核；通过仅支持给定形式语义下的证明，不证明规格表达了真实需求或实现满足需求。与现有“形式化方法（轻量形式化）”和“不变量检查”相关但不等同，本轮对410条目录的关键词与邻近条目首查未见相同的证明项内核核验流程；这不是556→410全量语义去重结论。它仍是形式证明工具链的专用证据方法；Solve记录未冻结进项目候选选区，Lean引用版本、原文范围及许可未核验，故本轮不独立登记；派生“形式推理循环”还需另审组成项与组合契约。 |\n| F 因果识别假设与敏感性审计 | 当前Solve候选涉及`causal-question-specification`、`target-trial-emulation`、`identification-assumption-audit`、`sensitivity-to-unmeasured-confounding`及派生`causal-inference-audit-loop`；目标试验模拟还依赖因果DAG模型。此前候选列出的四个ID没有冻结完整组合选区，不能把派生循环的步骤当成同一单源定义。与现有“近端因果机制”“反事实推理”“因果回路图”“数据分析陷阱清单”主题相邻但操作不同：本候选的辨别点是记录交换性/正值性/一致性/测量/选择假设及其依据，再按有据范围扫描未测混杂并报告结论翻转边界。它是高风险因果研究审计，不是通用编程流程；模型拟合不证明识别假设成立，敏感性参数无依据也不能制造精确结论。当前Solve包未冻结为项目候选选区，Harvard等来源引用、版本、原文范围与许可未核验；故暂不视为来源绑定候选或写入登记。重启需先确认因果研究方法的收录范围、冻结完整来源组合并安排领域复核。 |\n| G 分布漂移检测 / 分布外检查 | 当前Solve包分别给出`psoa.machine-learning.drift-detection`与`psoa.machine-learning.out-of-distribution-check`两个`OperatorSpec`：前者比较时间窗中的基线/当前输入、标签或错误分布并排除采样等混杂；后者针对输入与参考支持域校准阈值并绑定拒答/降级动作。两者不是同一操作；已有“拍扁”“受约束的状态变换”“有效知识子集”提及外推边界，但不是在线检测流程。官方[常见陷阱](https://scikit-learn.org/stable/common_pitfalls.html)涉及数据泄漏与新数据上的泛化，[学习/验证曲线](https://scikit-learn.org/stable/modules/learning_curve.html)涉及训练/验证表现；首轮抓取未见时间漂移检测程序。[模型选择索引](https://scikit-learn.org/stable/model_selection.html)也未直接提供该操作。[离群与新颖性检测](https://scikit-learn.org/stable/modules/outlier_detection.html#novelty-detection)更接近“干净参考数据上判断新观察”的分布外子问题，但不等于一般化模型适用域保证，且不在冻结记录的source_refs中，不能追补为原来源。`confidence-escalation`（H）是响应路由，不检测漂移或分布外；OOD分数也不能直接当作正确率置信度。派生`generalization-validation-loop`不包含这两个Operator。完整源记录已冻结于`.github/metadata/gongfa/source-selected-candidates-20261014.txt`；引用键和当时映射已绑定，外部文档使用stable地址且版本、许可证未固定。快照只供审查，不分配项目ID、不写登记。后续需核对漂移基线/时间窗、标签可用性、阈值校准、误报漏报和降级责任；分布分数不证明正确性，未检出漂移也不证明仍有效。 |\n| H 置信度升级 | 当前Solve记录`psoa.machine-learning.confidence-escalation`是独立`OperatorSpec`：用独立校准集核对模型置信度与真实正确率，按风险/代价设阈值，再路由自动回答、拒答、降级或人工升级，并观察选择性风险与覆盖率。它不同于“Human in the Loop”的通用高风险/失败升级、“校准估计”对主观估计者的校准，也不同于派生`generalization-validation-loop`把校准作为验证步骤而不负责运行时动作路由；与G互补但不等价。首轮目录检索未见同一完整契约，非556→410全量语义去重结论。冻结记录引用的[学习/验证曲线](https://scikit-learn.org/stable/modules/learning_curve.html)和[模型选择索引](https://scikit-learn.org/stable/model_selection.html)未直接说明概率校准或风险路由；官方[概率校准文档](https://scikit-learn.org/stable/modules/calibration.html#calibrating-a-classifier)支持独立数据/CV拟合校准器，但不规定业务风险阈值、拒答/升级策略或覆盖率目标，且未列入该冻结记录的source_refs。故这些官方页面只支持相邻子步骤，不能证明完整H契约。完整记录已冻结于`.github/metadata/gongfa/source-selected-candidates-20261014.txt`；这是来源选区，不是项目候选登记，不分配项目ID。后续复核需核对文档版本与许可、标签/校准集独立性、风险阈值、误拒/漏放、覆盖率、成本和可用升级通道；源记录标为高风险，不把自报置信度当校准证据。 |\n\n| I 因果特征消融 | 冻结记录`psoa.machine-learning.causal-feature-ablation`（`.entries[15]`）为模型特征干预/消融的高风险`MethodSpec`。与现有“近端因果机制”“反事实推理”“因果回路图”相邻但不等同：消融可测模型对输入扰动的依赖，不能仅凭输出变化推出真实世界因果效应；原记录自身也警告单变量消融不是因果证明、干预可能生成分布外样本。其`source_refs`指向的`ref:sklearn-model-selection`页面导航列出交叉验证、调参和评分，`ref:mit-probability-inference`介绍一般估计/假设检验；首轮抓取内容未发现能支持完整因果特征干预流程或识别假设的原文。故该条在机制上可与现有条目区分，但来源支持不足且名称有过度声称风险；若目标只是模型依赖性，应考虑收窄为“特征干预敏感性审计”，若保留因果主张则需冻结目标、干预定义及识别假设并安排领域复核。本轮不合并、不分配项目ID、不登记或赋级；引用版本、许可证、效果及全量556→410去重仍未核验。有限来源选区见`.github/metadata/gongfa/source-selected-candidate-causal-feature-ablation-20261014.txt`。 |\n| J 主动学习 | 冻结记录`psoa.machine-learning.active-learning`（`.entries[12]`）的主题可与`psoa.decision-science.value-of-information`及历史候选VC098“通用五步衡量法”区分：主动学习选择有限预算下用于训练模型的样本标签；信息价值衡量信息对决策损失/净效用的影响；VC098是更广的决策与信息衡量流程。三者共享信息获取与成本主题。Settles §5.3还把VOI列为成本敏感主动学习的一种路径，因此二者存在子场景重叠：用于选择训练标签并计入误分类成本的VOI属于主动学习查询策略，通用决策级VOI则不必然是主动学习；不按名称自动合并。原`source_refs`对应的scikit-learn模型选择索引和MIT推断课程未显示完整主动学习循环；补充核对Settles的[主动学习综述](https://minds.wisconsin.edu/handle/1793/60660)后，§1.1、§2.3及§3支持学习者选择待标注数据、池式查询循环与多类查询策略，§4.1也指出主动学习有时可能比被动随机采样需要更多标注。该综述未列在源记录原引用中，不证明普遍效果。原记录把“标签/测量”“检索/实验”和“模型/决策”混在一起，建议后续限定为监督学习标签查询，并追加可追溯的来源修订；本轮仅确认语义上可区分，不分配项目ID、不写机器登记/总表、不赋级。许可、独立领域审查与效果未核验。有限冻结选区见`.github/metadata/gongfa/source-selected-candidate-active-learning-20261014.txt`。 |\n\n| K Solve机器学习pack entries[0..4] | 官方文档支持传统估计器的测试集隔离、k-fold验证和按训练样本数绘制学习曲线；但将hidden eval、task folds和reasoning/context/tool-call资源曲线移植到Agent仍是待验证类比。“最终测试只评一次”是防自适应泄漏的评测策略；预算不自动等同正则化。偏差—方差只支持窄诊断，不直接决定Agent增容或约束。与`gongfa-experimental-design`、`gongfa-performance-by-measurement`、`gongfa-pragmatic-optimization`等相邻但不等同；不新增登记、候选ID或评级，也不自动合并。有限快照见[机器学习entries[0..4]复核](../../metadata/gongfa/source-selected-machine-learning-entries-0-to-4-20261015.txt)，只覆盖五条，不代表556→410全量语义去重。 |\n| L Solve机器学习pack entries[5..8] | 官方文档分别支持传统模型的数据泄漏边界、参数组合搜索/嵌套交叉验证、分类概率校准及单特征置换敏感度；hidden eval隔离、Agent配置搜索、Agent confidence/escalation与context/document/tool-output扰动仍是未验证迁移。置换分数变化不是因果效应；校准也不自动定义动作阈值。与实验设计、指标优化、置信度升级及因果特征消融相邻但不等同；不新增登记、候选ID或评级。有限快照见[机器学习entries[5..8]复核](../../metadata/gongfa/source-selected-machine-learning-entries-5-to-8-20261015.txt)，仅覆盖四条，不代表556→410全量语义去重。 |\n| M Solve机器学习pack entries[9..11]与[17] | scikit-learn 1.7模块页分别支持标签置换检验、传统分类器投票、refit选择与简单规则基线；不证明任意打乱Agent上下文有效、成员误差独立或Pareto最优。派生泛化循环只有会话引用，固定箭头顺序不证明数据使用前已防泄漏，概率校准也不能泛用于所有输出。与实验设计、指标优化及多来源证据评估相邻，不自动合并或新增登记/品级。见[四条完整冻结与审阅位置索引](../../metadata/gongfa/source-selected-machine-learning-entries-9-to-11-and-17-20261016.txt)；该18条pack均可定位到有限审阅记录，但深度不一，不等于18件独立功法或556→410全量语义去重。 |\n\n##### 26个精确标题匹配的进一步核对\n\n> 24项可由既有冻结选区复核；另外2项现已由`source-selected-title-matches-20261014.txt`冻结精确Solve记录，供语义对照，不据此建立新条目。\n\n- 其中24项与`source-classified-candidates-20261007.json`的冻结Solve24选区具有相同`source_id`、相同原始pack SHA及相同完整JSON条目；它们已作为历史来源候选存在，不是新增功法或需要更新的第二版本。分组为：研究（来源批判、重复研究、预注册、代理指标—真实目标对齐审计）；计算机科学（不变量检查、接口契约、依赖图）；软件工程（架构权衡、增量开发、影响分析、风险驱动测试、事故复盘）；编程（二分调试、最小复现、模糊测试、性质测试、差分测试）；问题求解（手段—目的分析、选择性启发式搜索、构造性见证、元认知监控）；决策科学（信息价值、后悔与鲁棒决策）；工程（失败预演）。保留旧快照与意见，不因本轮全量索引而重建或提升状态。\n- `psoa.cognitive-science.metacognitive-monitoring`已在新快照冻结；历史候选`psoa.problem-solving-methodology.metacognitive-monitoring`绑定旧Solve pack SHA `ff2c226e4e43c1230864e88ffbfbba489b4a14a60dd52f663bba9eced34d46ad`的`/entries/7`。两者同属策略监控与继续/切换/停止控制；认知科学记录加入执行前预测、观察偏差和信心更新，旧记录更强调进展/成本、替代策略预期收益与阈值控制。已抓取其`ref:ramps-metareasoning`对应的[RAMPS论文](https://pmc.ncbi.nlm.nih.gov/articles/PMC10302445/)：支持数学问题求解中的元认知监控/控制框架，也明确提醒监控可能无关而有害；论文自述该框架用于讨论拟议关系、适于后续讨论与可检验模型，并非已验证的线性路径。它不直接确立Solve记录的完整步骤或向一般软件任务的迁移。`ref:national-academies-metacognition`本轮返回HTTP 403，未核原文；许可证也未核。故视为强语义重叠、操作侧重不同的未决映射，不因标题合并，也不新增登记。\n- `psoa.programming-principles-101.information-hiding`已在新快照冻结；其扩展字段记有`source_principle: 3.14`，但这是源记录自身的映射声明。与现有候选`3.14 信息隐藏`“隐藏易变设计决策、公开稳定事实”高度相邻；新记录补充盘点调用者需要、迁移内部依赖和验证替换/错误路径，更像将该准则操作化，尚不足以证明独立功法。历史`html96:VC004`表达重要设计知识由单一模块拥有、减少跨模块依赖，是相邻的边界/所有权主张，不应因同名替代上述对照。其唯一`source_ref`映射为`conversation://programming-principles-101-materials`，本轮没有可核验的原始材料，来源摘要/许可无法独立检查；不合并旧候选，也不新登记，待获得可追溯正文和许可依据后再判。\n\n##### 编程原则pack中的五条近标题对照\n\n有限快照`.github/metadata/gongfa/source-selected-near-title-matches-20261014.txt`冻结了5条`programming-principles-101`记录，并对照候选历史快照中的A017、A032、A071、A097、A099。五条都保留相同主题核心，Solve记录增加了步骤、边界或验收表达；当前证据更支持“高度重叠或操作化”，不足以证明独立身份。它们不据此另行登记，也不推广为该pack其他未审记录的结论。Solve `source_refs`指向`conversation://`材料，原文、版本与许可未独立核验；历史HTML候选快照也不等于外部来源验证。名称相似只用于召回，判断依据是本次实际比较的定义与步骤。\n\n| Solve来源 | 对照历史候选 | 定向结论 |\n|---|---|---|\n| `logic-data-cohesion` | A017「3.7 逻辑与数据的一体化」 | 同一共同变化与边界收敛核心；Solve补充读写者清单、边界迁移及契约/序列化验证。 |\n| `nonfunctional-requirements` | A032「3.22 软件架构的非功能需求」 | 同一质量属性范围；Solve补充场景、阈值及设计/测试关联，历史项是复合候选。 |\n| `software-leverage` | A071「3.61 充分利用软件的杠杆效应」 | 同一复用和自动化核心；Solve补充许可、维护、行为验证与回滚边界。 |\n| `eighty-ten-ten-boundary-check` | A097「7.5 80-10-10原则」 | 同一工具尾部适用域审查；比例不是实测定律，Solve补充代表性场景和退出决策。 |\n| `second-system-control` | A099「7.7 第二系统综合征」 | 同一后续版本功能膨胀问题；Solve补充用户证据、核心/外围划分和回归。 |\n\n本对照只覆盖5条近标题命中，不替代556→410全量语义去重，也不据此认定源头相同、独立效果或可合并身份。\n\n##### 七条编程原则记录的操作化对照\n\n有限快照`.github/metadata/gongfa/source-selected-principle-operations-20261014.txt`冻结Solve pack的2.1–2.7七条记录及对应历史候选A004–A010。逐项比较后，七条均与对应原则高度重叠：KISS/DRY/YAGNI/PIE/SLAP/OCP/命名的核心主张一致，Solve记录主要增加适用边界、步骤、反例或验证要求；OCP还明确以重复出现的真实变化为抽象依据，DRY明确区分共同知识与表面相似。现有材料更支持“原则的操作化表达”，不足以证明独立身份或共同外部来源；不批量登记、赋级或声称效果。原始来源、版本、许可和独立评审仍未核验。\n\n| Solve记录 | 历史候选 | 处理 |\n|---|---|---|\n| `kiss`、`dry`、`yagni` | A004–A006 | 同一简化/单一知识/当前需求核心；操作化补充必要复杂度、语义耦合和现存契约边界。 |\n| `pie`、`slap`、`meaningful-naming` | A007、A008、A010 | 同一意图表达、抽象层次和命名核心；补充读者复述、行为回归、真实副作用与迁移检查。 |\n| `ocp` | A009 | 同一稳定核心与扩展边界；增加真实重复变化证据，避免为假想变化过早抽象。 |\n\n##### 编程原则3.2–3.10第二批对照\n\n有限快照`.github/metadata/gongfa/source-selected-principle-operations-3-2-to-3-10-20261014.txt`冻结8条记录：3.2–3.6、3.8–3.10；3.7「逻辑与数据的一体化」已在前述五条对照中审阅，本批不重复计数。`简洁`A013与KISS A004高度重叠，`重复最少化`A016与DRY A005高度重叠；`交流`A012与PIE A007强相关但范围较广。`灵活性`A014与OCP A009为一般适应性与具体扩展策略的关系；`效应局部化`A015与A017的共同变化/边界组织相关，但前者看影响传播范围，后者看数据与逻辑的共同所有权；`变动率`A020按变更历史识别边界，与前两者相关但判据不同。`对称性`A018关注成对操作的可类推性，`声明式表`A019关注意图/约束表达，两者是不同设计准则。上述“相关/不同”只描述本轮已读文本的语义范围；原文、版本、许可与独立领域审查未核验，均不因此独立登记或赋级。\n\n| Solve记录 | 历史候选 | 处理 |\n|---|---|---|\n| `communication`、`simplicity`、`minimal-repetition` | A012、A013、A016 | 与交流表达/PIE、KISS、DRY高度相邻；后两者核心重叠明显，不能仅凭更细步骤另立平行身份。 |\n| `flexibility`、`effect-locality`、`change-rate` | A014、A015、A020 | 分别对应变化适应、影响传播半径、基于变更史的边界判据；有关联但对象/判据不同，不强行合并。 |\n| `symmetry`、`declarative-expression` | A018、A019 | 成对操作可类推性与声明式表示选择是不同准则；外部来源和独立身份仍待核。 |\n\n##### 编程原则3.12–3.21第三批对照\n\n有限快照`.github/metadata/gongfa/source-selected-principle-operations-3-12-to-3-21-20261014.txt`冻结9条记录：3.12、3.13、3.15–3.21；3.14信息隐藏已经在精确标题命中审阅中单独记录，不重复计数。`单一引用点`A030与DRY/重复最少化高度重叠；`分治`A031对应已登记`gongfa-divide-and-conquer`，不另建条目。`接口与实现的分离`A029与已登记`gongfa-stable-interface-contract`相关，但不是仅凭此字段即可合并的同一身份。`抽象`A022、`封装`A023、`打包`A025、`关注点分离`A026及其策略/接口分离子类，按对象与边界区分；抽象也不等同于已登记的`gongfa-validated-abstraction`。A027是API核心操作集的充足/完整/原始性约束，文本可辨但缺独立来源与可检验定义。九条的候选来源均未独立核验，不因此新增登记、评级或效果结论。\n\n| Solve记录 | 历史候选 | 处理 |\n|---|---|---|\n| `single-source-of-truth`、`divide-and-conquer` | A030、A031 | 前者高度重叠DRY/重复最少化；后者与已登记`gongfa-divide-and-conquer`相同主题，Solve主要补充验证/组合步骤。 |\n| `abstraction`、`encapsulation`、`packaging` | A022、A023、A025 | 分别指共性提取、状态所有权、稳定模块聚合；相邻但不可互换。 |\n| `separation-of-concerns`、`strategy-implementation-separation`、`interface-implementation-separation` | A026、A028、A029 | 广义变化轴分离及两种具体边界；A029另与已登记稳定接口契约相关，均不凭近义批量登记。 |\n| `adequacy-completeness-primitiveness` | A027 | API核心操作集合的约束三元组；待核本体定义、来源与判定准则。 |\n\n##### 编程原则3.23–3.27第四批对照\n\n有限快照`.github/metadata/gongfa/source-selected-principle-operations-3-23-to-3-27-20261014.txt`冻结5条记录及对应历史候选A033–A037。3.23易变性、3.24互操作性、3.26可靠性与3.27可测试性在历史候选初评为设计准则；Solve将其操作化为`OperatorSpec`，不能凭结构化步骤就提升为独立方法。3.25效率性历史候选已关联`gongfa-performance-by-measurement`，Solve将测量基线、热点和回归流程化，当前更支持操作化而非平行登记。可靠性与`gongfa-controllable-failure`、互操作与`gongfa-stable-interface-contract`/`gongfa-glue-coding`、可测试性与轻量形式化/失败模式分析分别相邻但并非完全同一对象。五条原始来源、版本、许可与效果均未独立核验，不改登记、总表或评级。\n\n| Solve记录 | 历史候选 | 处理 |\n|---|---|---|\n| `changeability`、`interoperability` | A033、A034 | 均为设计准则的操作化表达；互操作关注跨系统交换，与单接口契约、适配/编排相关但不等同。 |\n| `efficiency` | A035 | 已关联性能测量登记；扩展为测量—热点—复测流程，不新增平行身份。 |\n| `reliability`、`testability` | A036、A037 | 分别与故障可控/恢复、形式化/失败模式验证相邻；质量属性与具体操作流程分开，不强行合并。 |\n\n##### 编程原则3.28–3.33第五批对照\n\n有限快照`.github/metadata/gongfa/source-selected-principle-operations-3-28-to-3-33-20261014.txt`冻结pack `.entries[32..36]`及历史候选A038、A040–A043；3.29不在pack。3.30简单性原理与已审3.3简洁高度重叠；3.32对称原理与同pack 3.8对称性构成强语义重复，步骤差异是生命周期边界的细化，不应当作两个独立方法。3.31标题/编号匹配但历史候选讲问题结构与解决结构对应，Solve改为同类组件的形式统一，存在语义偏移；需查原文，不按字段覆盖。3.28可复用性与胶水原则/拼好码相关，重点不同在本地抽取共享能力的验证；3.33层次原理与SLAP相邻，但范围扩展到模块层次及成对资源操作。五条来源与许可未独立核验，本轮不新增登记、不改Solve上游。\n\n| Solve记录 | 历史候选 | 处理 |\n|---|---|---|\n| `reusability` | A038 | 与胶水原则/拼好码共享复用主题；其“本地组件经多种应用验证后再提升共享能力”是不同决策点，仍属待审准则操作化。 |\n| `simplicity-principle` | A040 | 与同pack已审`simplicity`（3.3/A013）高度重叠；只作为重复/操作化记录，不平行登记。 |\n| `isomorphism-principle` | A041 | 标题/编号虽一致，历史定义和Solve操作对象不同；保留语义错位，等待原文来源核验。 |\n| `symmetry-principle` | A042 | 与同pack`symmetry`（3.8/A018）强重复；建议Solve上游后续合并并保留迁移映射，本仓不擅改上游。 |\n| `hierarchy-principle` | A043 | 与SLAP都处理抽象层次；SLAP限函数叙述层，本项增加模块层与资源配对，不强行视为同一条目。 |\n\n##### 编程原则3.34–3.39第六批对照\n\n有限快照`.github/metadata/gongfa/source-selected-principle-operations-3-34-to-3-39-20261014.txt`冻结pack `.entries[37..41]`及A044–A046、A048–A049；3.37不在pack。3.34线性原理与可推理代码的浅分支原则相关；3.36安全原理扩展异常/误用下的限制损害与安全停止，与故障控制及错误模式分析相邻但须独立风险审查。3.38模块化原则将边界、接口和组合检查流程化，不据此重复登记。3.35清晰原理存在定义错位：历史候选强调设计表达易读，Solve转为修改前的语境/根因理解；3.39清晰原则则是代码表示的可读性，与3.35同名但对象不同。来源引用、原文与许可未核验，不改登记或上游。\n\n| Solve记录 | 历史候选 | 处理 |\n|---|---|---|\n| `linearity-principle` | A044 | 控制流直线化与浅分支/平逻辑相关；作为具体可读性检查，不另建独立登记。 |\n| `clarity-principle`（3.35） | A045 | 标题/编号吻合但语义偏移；回到可追溯原文核对，不将映射字段当定义。 |\n| `safety-principle` | A046 | 异常下限制损害和安全失败，与故障控制/失败模式分析相邻；高风险语义不凭文本登记。 |\n| `modularity-principle` | A048 | 模块边界和接口的准则操作化，与分解、契约、关注点分离相关但不自动合并。 |\n| `unix-clarity` | A049 | 维护者可读性与`gongfa-reasonable-code`高度相关；与3.35同名但不是同一语义。 |\n\n##### 编程原则3.40–3.44第七批对照\n\n有限快照`.github/metadata/gongfa/source-selected-principle-operations-3-40-to-3-44-20261014.txt`冻结pack `.entries[42..46]`及历史候选A050–A054。3.41策略/机制分离与3.18高度重复；3.42简单原则与3.3、3.30形成重复簇。3.40组合原则与胶水的选择—适配—编排有关但契约焦点更窄；3.43关注程序/模块规模控制，相关但不能按行数阈值机械拆分；3.44可观察性支持故障发现/定位，不等于完整故障处置，日志须受脱敏、保留和成本约束。来源原文、许可及效果未核验，不新增登记或修改Solve上游。\n\n| Solve记录 | 历史候选 | 处理 |\n|---|---|---|\n| `composition-principle` | A050 | 稳定I/O、小契约及错误传播是组合能力的操作化，与胶水原则相邻，不另建重复身份。 |\n| `separation-principle` | A051 | 策略/机制变化边界与3.18高度重复；不因编号/步骤改写新登记。 |\n| `unix-simplicity` | A052 | 与3.30及3.3高度重叠；复杂度账本是操作细化，不平行登记。 |\n| `parsimony-principle` | A053 | 历史候选重小程序组合，Solve重模块/流程规模；相关但不等同，拒绝按行数机械拆分。 |\n| `transparency-principle` | A054 | 运行可观察与故障发现/定位相邻；脱敏、采样、保留及成本是必要边界，不把堆日志当效果。 |\n\n##### 编程原则3.45–3.49第八批对照\n\n有限快照`.github/metadata/gongfa/source-selected-principle-operations-3-45-to-3-49-20261014.txt`冻结pack `.entries[47..51]`及历史候选A055–A059。3.47最小意外原则与已登记`gongfa-least-surprise`直接重叠；3.45健壮性、3.49修复与可控故障/失败模式分析相邻但职责不一。3.46表达性涉及显式表达知识与规则数据化；3.48沉默原则涉及成功输出与诊断通道分离，不能误作关闭必要告警或审计。来源原文、许可及效果未核验，不新增登记或修改Solve上游。\n\n| Solve记录 | 历史候选 | 处理 |\n|---|---|---|\n| `robustness-principle` | A055 | 抗错误能力与安全/可控故障相关，但不等于安全策略或失败分析，不重复立项。 |\n| `expressiveness-principle` | A056 | 显式表达知识、规则数据化，与可推理代码和机制解释相邻，暂不新建身份。 |\n| `least-surprise` | A057 | 与已登记`gongfa-least-surprise`同一核心主张；仅补充接口惯例检查和例外显式化。 |\n| `silence-principle` | A058 | 成功数据与诊断输出分流；保留强制错误、审计和安全事件。 |\n| `repair-principle` | A059 | 不可恢复失败时停止并保留状态/证据，与可控故障相邻，不代表完整恢复流程。 |\n\n##### 编程原则3.50–3.54第九批对照\n\n有限快照`.github/metadata/gongfa/source-selected-principle-operations-3-50-to-3-54-20261014.txt`冻结pack `.entries[52..56]`及历史候选A060–A064。3.52与已登记性能测量原则高度重叠；3.51与仓内源—规则—派生产物的生成实践相符，但本地实现不能反证外部来源身份。3.50把自动化成本主张扩展为工具/硬件/流程的总成本核算，需真实基线和退出测量；3.53只允许有证据的必要变体；3.54的插件/兼容扩展只针对已知扩展轴，不鼓励推测性抽象。来源原文、许可与效果未核，不新增登记。\n\n| Solve记录 | 历史候选 | 处理 |\n|---|---|---|\n| `economy-principle` | A060 | 历史候选聚焦机器替代重复人工；Solve扩展总成本与机会成本，未有实测/来源证明，不新增身份。 |\n| `generation-principle` | A061 | 可机械生成的产物、单一来源及重建校验；与本仓生成视图实践相符，不把应用示例当外部来源证明。 |\n| `optimization-principle` | A062 | 与`gongfa-performance-by-measurement`高度重叠；基准、热点、重测和回归属操作化补充。 |\n| `diversity-principle` | A063 | 只为真实差异保留可选择和淘汰的变体，不把多样性扩成无限配置。 |\n| `extensibility-principle` | A064 | 版本/生命周期/错误契约与稳定接口相邻；须有真实扩展者和代表性用例，不按未来猜测建扩展点。 |\n\n##### 编程原则3.56–3.60第十批对照\n\n有限快照`.github/metadata/gongfa/source-selected-principle-operations-3-56-to-3-60-20261014.txt`冻结pack `.entries[57..61]`及A066–A070。A065/3.55 UNIX哲学在候选快照中被列为复合项，且不是Solve pack记录；它把小程序、单一职责、原型、可移植、文本数据等多个实践放在一起，但未见共同输入输出/适用分支合同，不能据此新建总功法或将其自动拆成正式子类。3.57与内聚/单一职责高度重叠；3.58是低成本验证不确定性的原型方法，与生产骨架要分开；3.59和3.60都保留性能、迁移、规模及消费者合同的例外。来源原文、许可及效果未核，不新增登记或改Solve。\n\n| Solve记录 | 历史候选 | 处理 |\n|---|---|---|\n| `small-is-beautiful` | A066 | 小型可组合组件与内聚/单一职责相关，但规模不是行数门槛；不机械拆分。 |\n| `do-one-thing` | A067 | 单一职责与`gongfa-high-cohesion`的核心主张高度重叠，不重复登记。 |\n| `early-prototyping` | A068 | 方法型候选：以可丢弃实验验证高风险未知，不能外推成生产可用。 |\n| `portability-over-efficiency` | A069 | 隔离平台特化并测量锁定/迁移代价；需真实平台矩阵和基准，不作绝对规则。 |\n| `text-data` | A070 | 文本适合可读、审查和互操作场景；Schema、编码、版本、规模和安全要求决定例外。 |\n\n##### 编程原则3.61–3.64及4.1第十一批对照\n\n有限快照`.github/metadata/gongfa/source-selected-principle-operations-3-61-to-3-64-and-4-1-20261014.txt`冻结pack `.entries[62..66]`及A071–A075。3.61与`gongfa-glue-principle`高度重叠；3.62脚本方法、3.63非交互调用及3.64过滤器流各有安全/契约边界，不因A065复合候选而自动拼成单一方法。4.1内聚度候选与`gongfa-high-cohesion`重叠，Solve是责任检查操作化，不复刻未核验的完整分级体系。来源、许可和效果未核验，不新增登记或修改Solve。\n\n| Solve记录 | 历史候选 | 处理 |\n|---|---|---|\n| `software-leverage` | A071 | 复用成熟能力与胶水原则同一核心；许可、供应链、试点和回滚是风险操作化。 |\n| `shell-glue` | A072 | 方法型候选，适用于固定命令编排；错误、输入、超时/清理和迁移语言均须明确。 |\n| `noninteractive-interface` | A073 | 自动化入口不能隐藏授权、确认、取消或安全语义，不等于去掉人工裁决。 |\n| `filter-oriented-design` | A074 | 标准输入/转换/输出流是具体组合方式；不是A065全部UNIX经验的证明。 |\n| `cohesion-audit` | A075 | 内聚检查步骤与`gongfa-high-cohesion`高度重叠；不把编辑性分级描述扩成新本体。 |\n\n##### 编程原则4.2–4.6第十二批对照\n\n有限快照`.github/metadata/gongfa/source-selected-principle-operations-4-2-to-4-6-20261014.txt`冻结pack `.entries[67..71]`及A076–A080。4.2耦合度与低耦合/显式依赖登记重叠；4.4可逆性与既有可逆决策重叠；4.6技术负债与技术债台账重叠。4.3正交性作为变化轴独立性的候选边界保留，但不等于零耦合或机械分层；4.5代码坏味保留为诊断方法，气味是调查信号而非自动重构授权。来源、许可及效果未独立核验，不新增登记或赋级。\n\n| Solve记录 | 历史候选 | 处理 |\n|---|---|---|\n| `coupling-audit` | A076 | 与`gongfa-low-coupling`、`gongfa-explicit-dependencies`高度重叠；不追求零依赖或无收益抽象层。 |\n| `orthogonality-audit` | A077 | 检查变化轴能否独立演化；共同变化、性能与转换成本决定是否拆分。 |\n| `reversibility-audit` | A078 | 与`gongfa-reversible-decisions`高度重叠；概率×影响排序不能冒充校准数值，回滚须演练。 |\n| `code-smell-triage` | A079 | 方法型候选：从坏味调查根因，小步保持行为；不按清单自动重构。 |\n| `technical-debt-management` | A080 | 与`gongfa-technical-debt-ledger`高度重叠；利息是成本隐喻，不是固定增长定律。 |\n\n##### 编程原则entries[72..76]第十三批对照\n\n有限快照`.github/metadata/gongfa/source-selected-principle-operations-entries-72-to-76-20261014.txt`冻结pack `.entries[72..76]`及历史候选A082、A088、A090、A091、A093。契约式设计与不变式/接口契约登记重叠；橡皮鸭叙述与溯因调试相邻但不能替代实验。童子军规则限定为任务附近的小改动，不扩范围；dogfooding要满足安全数据和操作边界；布鲁克斯法则按关键路径、培训和并行性判断，不当普遍公式。来源、许可和效果未核，不新增登记或评级。\n\n| Solve记录 | 历史候选 | 处理 |\n|---|---|---|\n| `boy-scout-improvement` | A082 | 单一低风险、邻近且可验证的小改善；不是顺手扩大范围或重写的授权。 |\n| `design-by-contract` | A088 | 与不变式和稳定接口契约高度重叠；外部输入校验与内部断言职责不同。 |\n| `dogfooding` | A090 | 指真实内部任务使用，不等同单元/集成测试；安全数据、权限和反馈隔离是前置条件。 |\n| `rubber-duck-debugging` | A091 | 外显假设、生成可检验断点；与溯因调试相邻，叙述不能当运行证据。 |\n| `brooks-law-response` | A093 | 复合候选；增员影响取决于任务依赖、培训和并行性，不把定性经验转成普遍人数公式。 |\n\n##### 编程原则entries[77..81]第十四批对照\n\n有限快照`.github/metadata/gongfa/source-selected-principle-operations-entries-77-to-81-20261014.txt`冻结pack `.entries[77..81]`及历史候选A094–A098。7.2康威定律作为组织/架构关系的可检验假设，不推出强制重组；7.3、7.4的破窗和熵增是类比性质量提醒，不是确定因果或物理量；7.5/entries[80]此前已在近标题快照审阅；7.6命名与概念工程及变量索引条目重叠。本批仅新增4条记录的语义对照，不重复计入7.5。来源、许可及效果未核，不新增登记。\n\n| Solve记录 | 历史候选 | 处理 |\n|---|---|---|\n| `conway-law-alignment` | A094 | 检查组织/架构边界错位与跨组等待；先按可观测证据调整接口或交付流，不把重组当唯一解。 |\n| `broken-windows-repair` | A095 | 与小步改善、坏味诊断相邻；社会类比不证明因果，局部修复或登记须有范围。 |\n| `entropy-control` | A096 | 质量趋势是多个明确代理指标，不存在本条证明的统一代码熵测度；不据此发动大重写。 |\n| `eighty-ten-ten-boundary-check` | A097 | 7.5此前已审；本批只冻结字段，不重复计数；比例不是实测定律。 |\n| `joshua-tree-naming` | A098 | 通用领域词汇与`gongfa-concept-engineering`重叠，变量索引与`gongfa-symbol-name-index-maintenance`相邻；命名不能抹去语义差异。 |\n\n##### 编程原则entries[82..84]第十五批对照\n\n有限快照`.github/metadata/gongfa/source-selected-principle-operations-entries-82-to-84-20261014.txt`冻结pack `.entries[82..84]`及A099–A101。7.7第二系统此前已在近标题快照审阅；7.8重新造轮与胶水原则高度重叠；7.9牦牛剃毛保留为问题栈/停止条件方法候选，不能用停止偏航掩盖硬依赖或未达验收。此批仅新增7.8、7.9两条直接语义对照。来源、许可及效果仍未核，不新增登记。\n\n| Solve记录 | 历史候选 | 处理 |\n|---|---|---|\n| `second-system-control` | A099 | 与已审第二版功能膨胀控制同一核心；真实用户价值变化仍可按证据扩展。 |\n| `reinventing-the-wheel-check` | A100 | 与`gongfa-glue-principle`同一复用优先主张；调查、许可、供应链及退出条件是操作化补充。 |\n| `yak-shaving-recovery` | A101 | 方法型候选：记录前置问题栈、原始目标和停止条件；与问题定义/交付闭环相邻，不能停止必要硬依赖。 |\n\n##### `programming-principles-101` pack的85条编号映射\n\n只读交叉表`.github/metadata/gongfa/source-crosswalk-programming-principles-101-20261014.tsv`按Solve记录的`source_principle`字段，与冻结的`html211_candidates`编号标题作了结构匹配：85条Solve记录各自唯一映射到101条历史候选中的一条，删除标题前的章节编号后，85/85名称精确一致；16个未映射章节号列于交叉表头。该结果证明字段/标题映射完整，不证明语义同一或原始来源相同；`source_principle`仍是Solve记录自述，来源材料与许可未独立核验。交叉表捕获时点（13:41Z）已有6条直接语义对照（五条近标题记录及另行冻结的3.14信息隐藏）；此后另审2.1–2.7七条、3.2–3.10八条、3.12–3.21九条、3.23–3.27五条、3.28–3.33五条、3.34–3.39五条、3.40–3.44五条、3.45–3.49五条、3.50–3.54五条、3.56–3.60五条及3.61–3.64/4.1五条；其中3.61已在近标题快照直接对照，本批新增4条独立记录；再审4.2–4.6五条后累计74条；本批entries[72..76]另新增五条，共79/85条记录有直接语义对照；entries[77..81]再新增四条（7.5已审），共83条；entries[82..84]新增加7.8、7.9两条（7.7已审），至此85/85条记录均有直接语义对照。该数量按记录计，不等于85个独立概念，也不代表556→410候选与总表已全量去重。因此不得因映射结果批量合并、登记或赋级。交叉表仅供候选路由，不是登记源或生成总表输入。\n\n以上是候选主题级去重结果，不宣称556个来源ID与既有410条逐项语义去重完成；来源提取、候选主题映射、登记状态和效能证据分别计数。\n\n##### 软件工程Solve pack entries[0..4]有限对照\n\n有限选区见`.github/metadata/gongfa/source-selected-software-engineering-entries-0-to-4-20261014.txt`。五条中，架构权衡已在历史快照中冻结，本轮不重复建立来源副本；其余四条冻结明确字段投影。结果如下：\n\n| Solve条目 | 本轮处理 |\n|---|---|\n| `requirements-engineering` | 与问题界定、歧义澄清、规约先行及局部需求评审相邻；当前四动词覆盖过宽，缺少可辨识输入输出与变化条件，暂不形成单独登记。 |\n| `traceability` | 需求—决策—实现—测试—证据链与状态时间追踪、变更影响分析不同；“每个组件、变更和测试”过于绝对，需先定义豁免、生成对象、链接新鲜度与覆盖判据，保留待收窄候选。 |\n| `architecture-tradeoff` | 与pack同SHA、同JSON的记录已在历史候选快照中；保留既有暂缓另增及相近候选去重结论，不重复登记、初评或评级。 |\n| `design-rationale` | 与已登记`gongfa-decision-rationale-documentation`高度重叠；新增候选/理由/后果/复查字段目前更像操作化表达，不另建平行身份。 |\n| `verification-and-validation` | 分开检查契约符合和用户目标有辨别价值，但当前来源核对只能证明相关知识主题存在，尚不足以核定该定义及操作边界；保留待来源绑定与范围审查候选。 |\n\nSWEBOK v4.0a主题目录列出需求验证/追踪、软件架构、设计理由和V&V；NIST TEVV-Athlon页支持组织目标导向的AI系统评估；CMU SEI的ATAM页只作架构权衡的补充主题核对，不属于Solve记录原`source_refs`。这些页面不证明精确步骤、许可、独立语义或效果；`conversation://cross-domain-method-map`也没有随pack提供可独立读取的固定原文。五条`evidence_required`逐字复用同一泛化清单，不能充当逐条效果证据。本轮只审了快照列出的相邻对象，不代表遍历79条登记或410条历史候选，不构成556→410全量语义去重；没有新增登记、候选等级或正式效能评级。\n\n##### 软件工程Solve pack entries[5..9]有限对照\n\n有限选区见`.github/metadata/gongfa/source-selected-software-engineering-entries-5-to-9-20261014.txt`。entries[5]增量开发与entries[8]影响分析已在历史候选快照中保存同一pack SHA及旧意见；该快照后续补查了官方CS2023 Software Engineering Version Gamma，补充来源及对本批entries[10..15]的核对见`.github/metadata/gongfa/source-selected-software-engineering-entries-10-to-15-20261014.txt`。补查不改写旧快照，只更新当前证据边界。本轮仅新增entries[6]、[7]、[9]字段投影。结果如下：\n\n| Solve条目 | 本轮处理 |\n|---|---|\n| `incremental-development` | 保留旧“优先候选”意见；辨别点应是可独立验证且保持可运行的纵向切片与集成边界，而非小步本身。与A085一步一步走高度相邻；分治和总体交付循环相关但不等同。Gamma支持迭代与快速反馈，但不直接证明纵向切片、回滚证据或本条具体步骤。原“实现→测试”次序不覆盖本仓测试先行要求。 |\n| `code-review` | Google官方概览支持由作者之外的人审查代码并列出审阅关注点；CS2023 Gamma也列出合作编程中的code review。A084无我编程是评审行为准则，VC048独立产品测试是另一流程。pack里的finding分类、修订、复验序列未由所查概览逐步支持；“独立”限于非作者角色，不代表独立oracle。保留来源绑定待审候选，不登记。 |\n| `configuration-management` | SWEBOK主题目录及CS2023 Gamma支持配置管理、版本控制、配置项与可复现构建/配置；不支持对所有prompt、model、tool、config和artifact无条件版本化。须收窄为影响复现/审计的受控配置与工件，并明确排除凭据、不可固定的远端状态等边界；目前范围过宽，不登记。 |\n| `impact-analysis` | 历史分析已与`gongfa-explicit-dependencies`对照，要求证明独立增量或作为相关来源；SWEBOK列出该主题，Gamma的学习目标也要求根据新需求识别需修改的系统区域，但都不证明遍历依赖图或完整blast radius。维持旧结论，不重复冻结。 |\n| `refactoring` | 当前定义为外部行为可冻结时的小步内部重组；与A079坏味调查、B015功能交付中的持续重构及总体交付流程相邻。CS2023 Gamma支持重构接口实现时对既有用户影响最小或为零的行为保持目标；尚未证明Solve具体操作、范围和效果。前批“缺行为保持定义的直接来源”由此修正为“补充来源支持目标，精确契约/步骤仍待核实”；不登记。 |\n\nSWEBOK主题目录、Google概览及CS2023 Gamma只能支持列明的主题或学习目标。Gamma是官方软件工程子页列出的2023年8月版本，但并非Solve原`ref:cs2023`的同一固定来源；原Final Report URL本轮为404，Gamma仅作为补充。它们不能证明pack完整流程、许可、独立审查或效果。五条`evidence_required`复用同一泛化清单，不能替代逐条证据合同。本批连同entries[0..4]仍只是有限邻项审查，不代表遍历79条登记或410条历史候选，也不构成556→410全量语义去重；没有新增登记、候选等级或正式效能评级。\n\n##### 软件工程Solve pack entries[10..15]有限对照\n\n有限字段投影、来源摘录、时间点与SHA见`.github/metadata/gongfa/source-selected-software-engineering-entries-10-to-15-20261014.txt`。entry[12]风险驱动测试和entry[14]事故复盘沿用旧候选快照及意见；本轮只冻结entries[10]、[11]、[13]、[15]字段投影。CS2023 Gamma提供课程/学习目标层的补充，不证明完整方法、许可或效果。\n\n| Solve条目 | 对照与处理 |\n|---|---|\n| `observability` | 与`design-for-observability`共享核心，但entry[10]偏运行时事件、记录、关联和诊断，entry[15]偏设计阶段的观测需求、schema、边界和演练；可视为不同阶段，不因两个ID就算两个独立功法。Gamma支持日志、telemetry、监控与告警主题，不证明完整trace/决策记录契约。“Agent必须留下decision/tool/state trace”须收窄到任务需要，并受数据最小化、凭据/个人数据保护、保留期和成本约束。 |\n| `continuous-integration` | Gamma支持通过自动化和自动化测试初步验证共享head/trunk可构建并通过基本测试，因此CI不只适用于多人/多代理。小patch、频繁集成、失败即修复等更细条件未由该来源逐项支持；保留来源绑定待审候选，不登记。 |\n| `risk-based-testing` | 历史意见为暂缓另增、与`gongfa-failure-mode-analysis`对照。Gamma分别列出风险识别、测试计划和测试工具；ISO 29119介绍页说明测试过程/文档/设计技术，但所查介绍未给出风险排序及按风险分配测试深度的程序。未读取标准全文，不据此断言系列标准不含该内容；维持旧结论，不新增登记或评级。 |\n| `interface-segregation` | Gamma支持关注点分离、组件边界/依赖和API设计原则，但未明确接口隔离原则或consumer-usage matrix步骤。概念上可辨的操作候选仍缺精确来源支持；不另立登记或评级。原Solve引用的Final Report URL本轮为404，Gamma仅作补充。 |\n| `incident-postmortem` | 与事前失败模式分析不同，旧意见为优先候选；Gamma的可靠性/故障主题、SWEBOK及NIST页面均未在本轮证明完整的事故时间线、因果区分和行动项关闭程序。候选意见不是登记授权，继续待来源核验。 |\n| `design-for-observability` | entry[15]明确了设计阶段操作，但与entry[10]共享可观测性核心。先确定是同一方法的阶段化实例还是可独立方法，再决定身份/拆分；不能因字段更细而自动多登记。Gamma只支持telemetry等知识主题，演练效果未验证。 |\n\nentries[10..15]属于有限选区；本轮不遍历79条登记或410条历史候选，不代表556→410全量语义去重。所有候选处理均不新增登记、初评、正式评级或实际效果主张。\n\n##### 软件工程Solve pack entry[16]有限对照\n\n有限字段和语义判断见`.github/metadata/gongfa/source-selected-software-engineering-entry-16-20261014.txt`。`controlled-evolution-loop`是`origin=derived`的组合条目，步骤引用需求、追踪、增量开发、代码评审、配置管理与可观测性；其唯一来源映射为不可单独复核的conversation URI。\n\n它与已登记`gongfa-methodology-delivery-loop`都属于总体流程，但序列和重心不同：既有流程强调规格、检查器、最小实现、反例与收敛重构；entry[16]强调长期变更中的追踪、评审、配置和观测。当前entry[16]没有充分定义阶段输入输出、准入/分支、风险检查、验证预算、失败恢复；目标承诺风险和验证证据，操作步骤和泛化`evidence_required`却未逐项覆盖这些合同。现有证据不足以证明独立于总体交付流程的自足方法；不新增登记、初评或评级。\n\n本次至此对软件工程pack entries[0..16]均有有限批次或历史候选审阅记录，但不是逐条独立来源认证，不代表其他Solve领域或556→410全量语义去重。未修改登记或生成目录。\n\n##### 编程Solve pack entries[0..4]有限对照\n\n有限选区、字段投影与来源指纹见`.github/metadata/gongfa/source-selected-programming-entries-0-to-4-20261014.txt`。五条均引用`conversation://cross-domain-method-map`和Python调试文档；前者没有可独立读取的固定正文。版本化的Python 3.12.15文档支持调试器单步、栈帧、断点及profiling工具能力，但不证明这些条目的完整方法契约、许可或效果。\n\n| Solve条目 | 对照与处理 |\n|---|---|\n| `tight-feedback-loop` | 与已登记`gongfa-methodology-delivery-loop`的检查器、最小实现和反例验证相邻，也与历史候选“5.5 一步一步走”相邻；不因“立即验证”另立总流程。 |\n| `hypothesis-driven-debugging` | 与已登记`gongfa-abductive-debugging`的候选原因、区分性实验及证据更新高度重叠；显式可证伪假设作为操作约束，不新增平行登记。 |\n| `binary-search-debugging` | 与历史候选中同ID、同pack SHA的记录相同，旧“优先候选”意见不是登记。Python调试文档不支持二分定位，且扩展到pipeline、prompt或context的固定来源缺失；保留历史意见，不用本轮补证。 |\n| `breakpoint-single-step` | Python文档支持通用调试器操作，但不支持对Agent workflow逐节点应用的完整操作和验收契约；作为工具操作候选，不登记。 |\n| `tracing` | 文档对运行期可见性仅有相邻支持，未定义跨组件关联、完整Agent trace契约；声明的完整action/tool/state记录还须受数据最小化、敏感值、访问、保留与成本约束。保留待审，不登记。 |\n\n这些条目复用同一泛化`evidence_required`，不能代替逐项效果证据。仅审programming pack entries[0..4]及快照列明的邻项；entry[2]旧记录保留不覆盖，本轮不修改登记或目录，也不代表扫描其余pack、79条登记、410条历史候选或完成556→410全量语义去重。\n\n##### 编程Solve pack entries[5..9]有限对照\n\n有限选区、字段投影与历史候选指针见`.github/metadata/gongfa/source-selected-programming-entries-5-to-9-20261014.txt`。entries[6]最小复现与entry[7]模糊测试沿用历史审阅意见，不重复冻结或升级；本轮只新增entries[5]、[8]、[9]的字段投影。Python 3.12.15文档仅支持profiling工具能力，不证明完整操作流程；其余新条目只引用不可独立复核的conversation映射。\n\n| Solve条目 | 对照与处理 |\n|---|---|\n| `profiling` | 是性能测量中用于发现热点的工具操作；`gongfa-performance-by-measurement`已经把profiling作为定位手段。Python文档支持分析执行时间，不证明修改/复测的完整循环或效果，不新增平行登记。 |\n| `minimal-reproduction` | 历史意见区分了保持同一故障的输入缩减与溯因排错中的原因/实验选择；“自动”“最小”不证明已有自动化或全局最小。保持旧候选，不更新评级或登记。 |\n| `fuzzing` | 历史意见将输入生成/变异与异常缩减视为独立于证据三角测量的候选；稳定oracle、隔离及可重放要求不等于来源或覆盖合同。保留旧意见，不授权执行、不新增登记。 |\n| `static-analysis` | 操作定义仍宽泛，来源只有不可复核的conversation URI；AST/类型/数据流标签不证明实际分析器、诊断或效果。留待来源绑定和范围收窄。 |\n| `race-detection` | 当前没有可复核来源支持其插桩、调度变化和冲突判据；也未运行工具或并发负载。留待来源核验，不新增登记或评级。 |\n\n本轮仅审entries[5..9]及指定登记/历史对象，不扫描79条登记或410条历史候选，也不代表556→410全量语义去重；未修改登记或生成目录。\n\n##### 编程Solve pack entries[10..14]有限对照\n\n新增字段投影、历史候选指针与来源边界见`.github/metadata/gongfa/source-selected-programming-entries-10-to-14-20261014.txt`。本轮冻结entries[10]、[11]、[14]；entries[12]性质测试和[13]差分测试沿用历史候选记录，不重复制表或升级。Python 3.12.15文档只支持部分调试/运行时观测工具能力；SWEBOK为知识领域主页级来源，均不证明完整Agent方法契约。\n\n| Solve条目 | 对照与处理 |\n|---|---|\n| `small-changes` | 与总体交付循环、快反馈及“一步一步走”相邻；原子patch受事务边界约束，只有不可独立切分时才应原子迁移。来源仅为不可复核的conversation映射，作为切片提示，不另立方法。 |\n| `read-execute-observe-modify` | 是更大交付流程中的反馈控制骨架，与快反馈循环共享核心状态转换；未给出独立边界或验收契约。Python调试工具不证明Agent基础循环，不新建平行总流程。 |\n| `property-based-testing` | 历史候选已区分独立性质、输入生成域、反例缩减/重放与证据三角测量；其“优先候选”和暂定等级不是登记或效果证据。当前来源不足，保留历史意见。 |\n| `differential-testing` | 历史候选把它与只将差分测试列作验证手段的旧组合内容区分，重点是参考/候选、版本、等价/容忍规则与差异归因；原来源没有形成可复核的方法依据，保留旧意见。 |\n| `instrumentation` | 是观测链的设置阶段，`tracing`是事件记录/关联和路径重建阶段；语义可分但现有边界及固定来源不足以支持两个独立身份。事件schema、采样、脱敏、成本和恢复契约仍待明确，不新增登记。 |\n\n本轮仅审entries[10..14]及指定相邻内容/历史候选，不扫描79条登记或410条历史候选，也不代表556→410全量语义去重；未修改登记或生成目录。\n\n##### 编程Solve pack entries[15..17]有限对照\n\n三条字段投影与边界见`.github/metadata/gongfa/source-selected-programming-entries-15-to-17-20261014.txt`。依赖最小化可能是胶水/依赖审查之下的窄供应链操作，但现有SWEBOK与CS2023引用不足以证明其步骤序列；资源有界循环的引用没有固定预算、取消及重试契约来源；调试反馈循环为`derived`组合，沿用此前审阅的调试和交付组件，不能仅凭组合顺序获得独立身份。\n\n| Solve条目 | 对照与处理 |\n|---|---|\n| `dependency-minimization` | 与胶水原则的复用、隔离、可替换/回滚及现有依赖审查提示相邻；若作为供应链收敛方法，仍需来源证明依赖清单、使用证据、逐项删除和完整回归合同。保留待来源绑定，不新增登记。 |\n| `resource-bounded-loop` | 资源预算、取消和终止是Agent任务的横切约束；独立操作需明确单位、计量点、并发/外部成本与停止输出。本轮未固定能证明该运行时契约的来源，暂不新增登记。 |\n| `debug-feedback-loop` | `origin=derived`，组合读执行观察、假设调试、最小复现、tracing和快反馈，与溯因调试/总体交付循环高度相邻；缺少独立来源、准入和失败恢复合同，不新登记或赋级。 |\n\n本轮仅审entries[15..17]，不扫描79条登记或410条历史候选，也不代表556→410全量语义去重；未修改登记或生成目录。\n\n##### 问题求解方法论Solve pack entries[0..4]有限对照\n\n字段投影、历史候选指针和页面摘录见`.github/metadata/gongfa/source-selected-problem-solving-methodology-entries-0-to-4-20261014.txt`。任务定框并入已有问题定义闭环；问题空间与解空间对象相关但不完全相同；手段—目的分析及选择性启发式搜索沿用历史候选意见；表征变换与Projection表示转换相邻，仍需区分具体映射合同。Schoenfeld和Pólya教学页面只支持问题求解/元认知主题；MIT PDF本批仅提取到标题，Newell–Simon PDF未读取正文，不能据此证明完整步骤或效果。\n\n| Solve条目 | 对照与处理 |\n|---|---|\n| `task-framing` | 当前/目标/未知/约束/可观察成功条件与已登记问题界定框架高度重叠；把未知和风险显式化是有用的合同细化，不自动形成独立功法。 |\n| `problem-space-model` | 明确状态、动作算子、转移与目标判据；不同于聚焦候选答案集合的`gongfa-solution-space`，概念边界保留，但来源正文未核实，不新增平行登记。 |\n| `means-ends-analysis` | 历史候选已将差距排序、基于算子前置建立子目标、重算差距与目的导向选择关联；维持“明确关系后再判断”的旧意见，不重评。 |\n| `representational-change` | 语义保持、信息损失记录和回译检查与Projection转换/拍扁相邻；Ash等(2009)只提醒表征重构主张需经验验证，不支持此条完整流程，不新增登记。 |\n| `heuristic-search` | 历史候选区分有限预算下排序、剪枝记账与未搜索区域复核；旧“优先候选”不是登记或最优性证据，来源正文未读，不升级。 |\n\n本轮仅审problem-solving-methodology pack entries[0..4]及指定登记/历史对象；不扫描79条登记或410条历史候选，也不代表556→410全量语义去重；未修改登记或生成目录。\n\n##### 问题求解方法论Solve pack entries[5..8]有限对照\n\n字段投影与来源摘录见`.github/metadata/gongfa/source-selected-problem-solving-methodology-entries-5-to-8-20261014.txt`。entries[5]构造性见证和[7]元认知监控沿用历史候选指针；entry[6]回看评估可作为检查阶段，但未证明独立流程；entry[8]是源记录自述的派生组合，不作为独立方法。MIT课程页仅支持证明技术主题，Stanford ME113仅支持用户设计情境中的原型/测试；Newell与Simon 1970年文章反对把实际策略描述为线性序列，Pólya教学页也明确不要求阶段按固定顺序执行。NIH及National Academies来源本次返回403。未新增候选、登记或评级。\n\n| Solve条目 | 对照与处理 |\n|---|---|\n| `constructive-witness` | 是具体构造/原型操作，不等于完整解空间或总体问题求解法；历史候选的“优先”与暂定阶位不是登记或正式评级。现有来源仅支持证明技术/设计原型主题，不支持完整独立核验合同，沿用旧候选。 |\n| `look-back-evaluation` | 与Pólya回看、问题求解闭环的结果验证及工程反例驱动检查相邻；来源不支持其完整独立流程，不新增登记。 |\n| `metacognitive-monitoring` | 与`psoa.cognitive-science.metacognitive-monitoring`共享监控/控制核心，但前者偏预算与阈值，后者加入预测与信心更新；保留历史映射，不按标题机械合并或新增。 |\n| `general-problem-solving-loop` | `origin=derived`，拼接entries[0..7]；固定箭头不等于来源定义的线性流程，反馈、分支、回退和组合合同仍未建立，仅作编辑性综合。 |\n\n本轮只审entries[5..8]和定向登记/候选/来源；未扫描全部79条登记或410条目录，不代表556→410全量语义去重；未修改功法登记、候选JSON、总表或评级。\n\n##### 信息与知识科学Solve pack entries[0..3]有限对照\n\n字段投影、来源范围与限制见`.github/metadata/gongfa/source-selected-information-knowledge-science-entries-0-to-3-20261014.txt`。本批只审6条中的前4条：信息需求规约与问题界定框架相邻，但目录/评测来源不支持完整需求合同；检索式扩展没有被当前引用定义为通用操作；DCAT、PROV-DM及FAIR支持数据描述、血缘和可复用元数据，不等同于来源权威判断、证据独立性或许可批准。TREC 2025 RAG报告支持任务特定相关性判断和有限评测范围；检索结果的precision/recall不得与生成回答引用支持度的weighted precision/recall混用。\n\n| Solve条目 | 对照与处理 |\n|---|---|\n| `information-need-formulation` | 与问题界定相邻；当前来源支持检索任务与目录描述主题，不支持条目所列的完整需求规约顺序、证据标准或停止条件。本轮不登记。 |\n| `retrieval-query-expansion` | 同信息需求和检索审计边界分开；TREC How-to和DCAT不是扩词方法来源，其他文档不替原引用补证。本轮不登记。 |\n| `source-authority-and-provenance` | DCAT/PROV-DM/FAIR支持元数据与派生关系表达，不证明来源按用途的权威等级、独立性或许可批准；与证据三角测量保留边界，本轮不登记。 |\n| `relevance-precision-recall-audit` | 保留既有候选C的窄边界：仅审既有结果集和可用判断集，不扩展为需求制定、查询扩展或完整检索流程。TREC 2025 report展示nDCG/Recall及有限人工qrels；其引用支持precision/recall属另一评估对象。候选仍未进入登记。 |\n\n本轮仅审entries[0..3]及定向相邻内容，不覆盖entries[4..5]或其余556条Solve记录，也不代表556→410全量语义去重；不修改登记、候选JSON、总表或评级。来源页面未固定字节版本；独立审查、许可与效果未验证。\n\n##### 信息与知识科学Solve pack entries[4..5]有限对照\n\n字段投影、来源范围与限制见`.github/metadata/gongfa/source-selected-information-knowledge-science-entries-4-to-5-20261014.txt`。`metadata-and-fairness-check`的名称指FAIR元数据原则，但摘要又纳入社会公平/群体排除判断；NIST FAIR与DCAT支持可发现性、访问协议及目录元数据，不定义差别影响或公平审计流程，NIH页面本次返回403。若后续收窄为FAIR元数据检查仍需完整操作来源，不将FAIR缩写当作fairness证据。`evidence-retrieval-loop`是`origin=derived`的五项固定组合；来源只支持若干组件主题，未定义反馈/分支/再入规则、指标阈值与恢复合同，因此本轮仅作编辑性工作流草图，不单独登记。\n\n| Solve条目 | 对照与处理 |\n|---|---|\n| `metadata-and-fairness-check` | FAIR（可发现、可访问、可互操作、可复用）与社会公平不是同一概念。当前NIST/W3C来源支持元数据与访问关系，不支持群体差异影响评估；NIH正文未读取。本轮不新建候选或登记。 |\n| `evidence-retrieval-loop` | 派生组件编排与已登记总体交付/问题求解闭环相邻，但不是同一范围的直接等价；固定步骤及标题“Loop”不构成反馈合同。保留为编辑性工作流草图，不赋予独立方法身份。 |\n\n本批仅审entries[4..5]及定向相邻内容；与前批entries[0..3]合计覆盖该pack，不覆盖其他Solve pack或410条目录，也不代表556→410全量语义去重。没有修改登记、候选JSON、总表或评级；许可、独立审查与效果未验证。\n\n##### 计算机科学Solve pack entries[0..4]有限语义与来源复核\n\n字段审阅投影、来源限制和逐项判断见[冻结快照](../../metadata/gongfa/source-selected-computer-science-entries-0-to-4-20261015.txt)。CS2023官方课程页面与报告p.90支持算法策略主题和分治/动态规划等例子；p.93支持算法复杂度与计算理论中的归约主题，p.98–99支持课程范围内解释、评估和应用。该课程不证明Solve对Agent的完整操作合同、独立身份或工程效果；用户提供的跨域映射没有固定可复核来源。\n\n| Solve条目 | 对照与处理 |\n|---|---|\n| `abstraction` | `MentalModelSpec`是观察视角，和真实使用验证抽象/目录抽象相关但不构成新施行方法；不新增。 |\n| `problem-decomposition` | 产出子问题和依赖图，与分治的拆分步骤相邻；现有分治已覆盖“拆—解—集成”，未证明独立功法身份。 |\n| `reduction` | 限定为保持关键性质的问题映射时，与一般类比和工具复用不等同；课程来源只支持算法/复杂度语境，跨域Agent复用仍待审，不登记。 |\n| `divide-and-conquer` | 与已登记`gongfa-divide-and-conquer`核心重叠；“多个执行单元”不由算法分治范式推出，不重复登记。 |\n| `dynamic-programming` | CS2023支持其算法策略身份，不支持将缓存中间推理一般化；需要状态/递推正确性及缓存键、上下文和失效边界，保留窄候选待审，不登记。 |\n\n本批仅覆盖该pack的前五条及定向登记对照；其余entries[5..15]和556→410全量语义比较未完成。没有修改功法登记、候选登记、总表或评级；许可、独立审查与效果未验证。\n\n##### 计算机科学Solve pack entries[5..9]有限语义与来源复核\n\n字段投影、来源限制和逐项判断见[冻结快照](../../metadata/gongfa/source-selected-computer-science-entries-5-to-9-20261015.txt)。CS2023报告p.90将贪心、回溯和分支定界列为课程策略；p.91覆盖算法复杂度主题并要求评价贪心是否最优。NIST形式化方法词条支持广义的规格、开发与验证定义，不证明本条Agent操作步骤或执行前证明保证。\n\n| Solve条目 | 对照结果与处理 |\n|---|---|\n| `greedy` | 课程支持贪心策略及最优性评估，不支持任意任务都选择“当前收益最高”。需目标/可行域、局部选择性质或近似界及停止条件；历史提示元素贪心候选范围更窄且缺价值oracle与停止规则，不判为同一身份。 |\n| `backtracking` | 课程仅支持其为应对指数增长的策略；需定义状态、候选完备性、撤销正确性、剪枝和预算。内部状态可撤销不等于外部副作用可回滚，不新增登记。 |\n| `branch-and-bound` | 需明确目标方向、为剩余分支提供有效乐观界，并证明剪枝不会排除可能优于当前incumbent的分支；还要定义incumbent更新和终止。当前条目未写出这些证明义务，保留算法候选边界。 |\n| `complexity-analysis` | 与`gongfa-input-scale-complexity-constraints`相邻；渐近算法复杂度与token、latency、通信和货币成本需分开给单位、系统边界与测量口径，不据此新增独立身份。 |\n| `formal-methods` | NIST支持广义形式化方法概念；与已登记`gongfa-lightweight-formal-methods`高度相关，当前证据不支持同义总项重复登记。 |\n\n五条复用的`evidence_required`清单无法替代各自义务：贪心选择/近似保证、回溯状态树与撤销、分支定界正确界与剪枝证明、复杂度规模/测量口径、形式化规格/模型/验证覆盖均不同。本批只审entries[5..9]及定向既有条目；不覆盖余下entries[10..15]或556→410全量比较，不改登记、候选、总表或评级；来源许可、独立审查和效果仍未验证。\n\n##### 计算机科学Solve pack entries[10..15]有限语义与来源复核\n\n字段范围、来源限制与逐项判断见[冻结快照](../../metadata/gongfa/source-selected-computer-science-entries-10-to-15-20261015.txt)。STRIPS原文支持world model、动作前置条件、增删效果和目标条件，并区分规划operator与实际执行routine；它不保证一般Agent工具行为、全局搜索终止或最优性。NIST词条和OMG Essence分别支持形式化方法概念与方法/实践组合，不构成不变量或API接口的精确操作规范。\n\n| Solve条目 | 对照结果与处理 |\n|---|---|\n| `state-transition-modeling` | 与状态空间思维、状态分类和受约束状态变换相邻但不是同一层；STRIPS不支持通用失败转移、可达性/循环/终止保证，保留窄状态/动作模型边界，不新登记。 |\n| `invariant-checking` | 历史候选已与`gongfa-invariant-constraints`对照；执行路径检查不证明未执行路径安全，沿用历史意见，不重复或升级。 |\n| `interface-contract` | 历史候选与`gongfa-stable-interface-contract`层级相关但不同；Essence是方法/实践语言，不是API合同来源，错误、超时、幂等和版本操作仍待精确来源。 |\n| `cache-memoization` | 与`gongfa-cache-lifecycle-isolation`相邻；区分算法重复子问题复用与Agent跨任务缓存。现有MIT/CS2023课程概述不足以支持缓存键、权限、新鲜度和失效的完整合同。 |\n| `dependency-graph` | 沿用既有候选记录：区别于`gongfa-explicit-dependencies`准则，且与影响分析避免重复；隐藏/时变依赖使图不完备。 |\n| `search-space-control-loop` | 是无固定外部来源的derived组合草图；回溯、分支定界和动态规划不能无条件串接，缺少分支选择与状态/失败恢复合同，不赋予独立身份。 |\n\n本批不修改登记、历史候选或生成总表，不赋级；Computer Science pack entries[0..15]仅完成分段有限审阅，其他pack及556→410全量语义比较未完成，C01–C20也未覆盖。\n\n#### 与现有方法合并，不另建平行流程\n\n| 候选素材 | 处理方式 |\n|---|---|\n| 当前状态—目标状态—差距、目的—手段 | 并入现有问题求解和手段—目的分析。 |\n| 发现问题—分析原因—行动—检验—纠错 | 并入现有反馈、溯因、反事实和复盘方法。 |\n| 搜寻、评估并复用成熟方案 | 并入拼好码与胶水原则。 |\n| 自顶向下、自底向上、分而治之 | 沿用系统构建方法，不重复登记。 |\n| “是什么—为什么—怎么做”、分类—可能性—分析—因果—选择—行动—度量，以及长步骤求解清单 | 作为现有问题求解流程的入口或组织素材；不再建一条竞争性总流程。 |\n| “先模仿再超越”“先完成再完善”“行动后复盘”等顺序格言 | 作为迭代、学习和复盘的提示，不将每条格言单独立项或视为普遍顺序。 |\n| 关于根因、证据、情境迁移、利害取舍的格言 | 仅作为解释或反例素材；转成准则时须定义适用条件和反例。 |\n| 贝叶斯更新、有限样本推断、第一性原理、反向思维、吸引子、性能工程 | 沿用总表和现有正文中的对应方法，不新建同义条目。 |\n| 抽象/具体化、分解/组合、映射/比较/类比/迁移、溯因/演绎/归纳 | 作为表征与推理操作，优先并入概念分析、组合描述、溯因和视角分析；操作名称本身不各自登记。 |\n| 知识地图、讲解、案例/历史/项目学习、设计实践、认知训练 | 目前只有工具名称，缺少完整操作定义、适用条件与验收；不列外部人物或机构归属，不作为独立候选。 |\n| 目标与利润、投入产出、劳动/生产关系/资本、财务三表 | 属于商业或社会科学分析内容；没有限定工程问题与操作边界前不纳入本工具箱候选。 |\n| 体力、知识、才华、方法、技术、策略、专注、耐心、信念等能力项 | 是能力/特质分类，不是施行方法，也不作为个人评价表。 |\n| 格言中的本末、根因、证据、迁移、利害与执行次序 | 仅作为现有规划、溯因、反事实、迁移和复盘方法的例证；不逐句新建功法。 |\n| “解决、转移、接受”与“思考、决策、行动、命运” | 前者缺少选择规则，后者不足以建立因果关系；暂不作为方法或因果模型。 |\n\n算法/算力/数据三要素、损失函数、奖励函数、梯度优化、强化学习、预训练/后训练/测试时扩展、规模/涌现/通用性主张、统计/互动/混沌/复杂分类、复杂系统理论、范畴论术语、数据结构、财务工具、管理学概念、军事功能、地缘政治信号和能力特质清单，本身属于学科概念、技术手段、分类素材或未定义主张；没有形成独立的问题定义、操作规则和适用边界前，不作为本节功法。\n\n#### Solve算法pack entries[1..6]有限语义与来源复核\n\n字段选区、讲义来源、提取文本哈希及逐项处理见[冻结快照](../../metadata/gongfa/source-selected-algorithms-entries-1-to-6-20261015.txt)。MIT OCW讲义分别支持特定近似比/方案、Monte Carlo与Las Vegas算法、DAG拓扑序及online/offline竞争比；课程主题不证明通用Agent质量映射、随机重启/置信区间合同、通用图抽取或运行时并行安全。\n\n| Solve条目 | 本轮处理 |\n|---|---|\n| `approximation` | 保留窄算法研究候选；近似比须绑定目标/可行域与证明，不能转写成通用Agent质量天花板。 |\n| `randomized-search` | 随机算法有有限来源；重启、概率放大和置信区间需要独立性/分布等明确前提，暂不登记。 |\n| `graph-modeling` | 属于图表示OperatorSpec；与历史依赖图候选有交集，不升级为独立MethodSpec。 |\n| `topological-order` | 视作DAG上的顺序OperatorSpec；拓扑序不等于资源/副作用安全的并行计划。 |\n| `online-competitive-analysis` | 作为MentalModelSpec保留边界；竞争比不等于后悔，也不等于线上产品评估。 |\n| `design-analysis-loop` | 固定串接的derived草图跨越不同前置条件；不建独立身份。 |\n\n本批不改登记、历史候选或生成目录/评级。只做选定条目的定向比较，不覆盖其他Solve pack、C01–C20或556→410全量语义去重。\n",
"sha256": "4c928f4136773b5547c934ce75e866c3ba673f88fe5d005a3ae0eeda4789fb35"
},
".github/docs/gongfa/modern-enterprise-architecture-template.md": {
"mode": "100644",
"encoding": "utf-8",
"data": "# 现代企业数字化平台架构说明文档\n\n**文档版本**：V2.98\n**适用对象**：企业管理层、产品负责人、架构师、研发负责人、数据负责人、平台团队、安全合规团队\n**适用范围**：中大型企业数字化平台建设、业务系统重构、平台工程建设、数据产品化、组织协同机制设计\n**文档定位**：本文件用于说明现代企业数字化平台的总体架构、核心组成、团队职责、治理机制、技术原则和落地路径。\n**专项修订**：V2.98 在 V2.97 基础上补齐 AI 系统监管分类与影响评估总账，明确 AI 产品、Agent、RAG、微调模型和模型供应商接入必须具备适用法规分类、风险等级、人工监督、日志、技术文档、后市场监测和合规义务映射。\n\n---\n\n## 0. 文档版本控制与发布治理\n\n本文件从 V1.6 起按企业架构基线文档管理。版本号不是装饰字段，而是用于控制“哪些内容已经形成基线、哪些仍在评审、哪些变更会影响团队执行”的治理入口。\n\n版本治理目标：\n\n1. 让管理层、架构组、平台团队、领域团队、数据团队、安全团队和 AI 团队引用同一份基线。\n2. 让每次架构升级都有变更范围、影响面、审批责任和验证证据。\n3. 避免文档持续堆内容但没有稳定版本，导致执行团队不知道该按哪一版落地。\n4. 为后续把蓝图升级为可执行企业标准、模板、契约和自动化门禁保留演进路径。\n\n### 0.1 版本语义\n\n| 版本形态 | 含义 | 使用条件 |\n| -------- | ---- | -------- |\n| `V0.x` | 研究草案版 | 用于概念探索、资料整理和内部讨论，不作为企业执行基线 |\n| `V1.x` | 正式蓝图迭代版 | 架构原则、分层、职责边界和治理方向已经稳定，可用于方案评审和试点规划 |\n| `V1.x.y` | 勘误和补丁版 | 只修正文案、链接、格式、局部示例或不改变执行含义的小问题 |\n| `V2.x` | 可执行企业标准版 | 必须具备模板、契约、门禁、RACI、自动化校验和落地 starter kit |\n| `V3.0` | 组织级规模化运营版 | 已与平台门户、catalog、GitOps、成本、审计和运行指标形成闭环 |\n\n版本升级规则：\n\n1. 只改错别字、格式、链接和引用，不提升主版本，可使用补丁记录。\n2. 新增章节、职责边界、治理要求、技术基线或路线图，提升当前主版本的小版本。\n3. 改变目录真相源、团队职责、发布准入、风险等级或运行边界，必须提升小版本并记录影响面。\n4. 改变执行模型、组织模型、平台边界或兼容策略，必须进入架构评审并形成 ADR。\n5. 升级到 `V2.0` 前，必须证明本文档不只是说明文，而是能被仓库模板、机器契约和 CI 门禁执行。\n\n### 0.2 发布状态\n\n| 状态 | 含义 | 允许动作 |\n| ---- | ---- | -------- |\n| `Draft` | 草案，内容仍在探索 | 可频繁修改，但不得作为执行口径 |\n| `Review` | 评审中，内容需要架构组和相关 owner 确认 | 允许修改，但必须保留评审意见和待决问题 |\n| `Baseline Candidate` | 基线候选，已具备执行口径但仍待正式会审确认 | 可用于试点和评审，不应用作冻结审计口径 |\n| `Baseline` | 已形成基线，可作为试点或项目规划依据 | 只能通过受控变更更新 |\n| `Frozen` | 冻结基线，通常用于招标、审计、监管或大规模推广 | 除勘误和安全修复外不得直接修改 |\n| `Superseded` | 已被新版本替代 | 只保留引用和迁移说明，不再作为新项目依据 |\n| `EOL` | 已停止支持并完成退役 | 禁止新建和生产继续使用，只保留审计归档 |\n\n当前版本状态：\n\n| 版本 | 状态 | 说明 |\n| ---- | ---- | ---- |\n| `V2.98` | `Baseline Candidate` | 用作可执行企业标准起点；包含机器可读版本清单、控制项覆盖清单、128 组 starter kit schema/example、基线版本策略、发布通道、兼容性与冻结控制总账、V2.69 至 V2.92 控制覆盖追溯、公开文档与本地私有可执行资产边界、企业内部命令 URI、证据保证等级、证据采信规则、不可采信证据阻断、证据保证等级在晋级矩阵、制品清单、starter gate 与审计导出中的消费链闭合、基线门禁负例测试、AI 系统监管分类与影响评估、故障注入、期望失败证据、fail-closed 覆盖、基线生产变更、发布编排、变更冲突与失败恢复总账、基线事故、问题、纠正行动与复发防止总账、基线数据产品质量、契约违约、运行血缘与可观测性总账、基线工程质量、测试证据、缺陷与发布验证总账、基线人员能力、培训、职责履职与职责分离总账、基线业务结果、价值实现与组合收益总账、基线价值流、关键旅程与端到端流程总账、基线架构视图、运行拓扑与依赖影响总账、基线质量属性、架构驱动与权衡决策总账、基线架构原则、约束、反模式与例外执行总账、基线安全配置、加固姿态与配置漂移修复总账、基线漏洞、暴露面与修复验证总账、基线威胁建模、攻击面与安全风险总账、基线容量、性能、弹性伸缩与成本效率总账、基线服务可靠性、SLO、错误预算与可观测性总账、基线备份、恢复、灾备与可恢复性验证总账、基线密码材料、密钥、证书与秘密生命周期总账、基线资产关键性、数据分类与风险分级总账、基线身份权限、特权访问与工作负载身份总账、基线处理活动、个人数据清单与 RoPA 覆盖总账、基线隐私权利请求、同意偏好与合法基础执行总账、基线记录留存、法律保全与可防御删除总账、基线监管与合规义务可追溯总账、基线运营韧性与重要业务服务影响容忍总账、基线第三方与关键供应商风险总账、基线数据驻留与跨境处理总账、基线共享责任与继承控制总账、基线独立控制保证抽样总账、基线连续控制监测总账、基线运行时准入决策总账、基线运行时准入回执、基线长期验签回执、基线证据不可变归档回执、干净环境基线重建回执、私有制品托管交接清单、审计导出排除清单、本地私有制品边界、基线迁移执行回执、基线迁移工作单、基线消费锁定文件、基线准入执行策略、基线撤销与隔离记录、基线发布事务回执、基线门禁执行报告、基线证据追踪图、基线会审裁决记录、基线 EOL 退役证书、基线状态对账报告、基线生命周期状态机、基线就绪评分卡、基线例外总账、基线回滚验证记录、基线通知确认总账、基线验证环境锁定、基线制品清单、基线符合性声明、基线发布列车、基线支持矩阵、基线采纳总账、基线兼容性总账、基线发布证据包、版本控制面、外部标准版本锁定、企业执行控制面、合规等级、门禁决策、证据新鲜度、例外放行、break-glass、季度复核、仓库变更控制、远端保护漂移整改、控制证据映射、审计导出清单、审计导出自动化、控制评估报告、架构基线变更记录、架构决策记录、AI 证据账本、AI 系统监管分类与影响评估总账、微调运行证据、AI 事件响应 playbook、OSCAL 交换映射、POA&M 整改计划、企业架构风险登记、审计导出门禁、审计导出完整性清单、审计导出 provenance statement、审计导出签名策略、审计导出签名验签回执、严格 schema 模式、威胁建模、攻击面管理、安全风险治理、访问复核、密钥轮换、漏洞修复、事故复盘、可靠性、性能、容量、成本效率、数据治理、AI 运行、GitOps 安全、供应链证据链一致性和自动化校验入口 |\n\n### 0.3 变更分级\n\n| 变更级别 | 典型内容 | 审批要求 | 版本影响 |\n| -------- | -------- | -------- | -------- |\n| `Editorial` | 错别字、排版、链接、术语统一 | 文档 owner 自审 | 不提升主版本，可记录补丁 |\n| `Minor` | 新增示例、补充说明、局部增强，不改变团队职责 | 文档 owner 和相关章节 owner 确认 | 提升 `V1.x` 或记录补丁 |\n| `Major` | 新增架构层、治理门禁、组织职责、发布流程或运行边界 | 架构组、平台、数据、安全、AI 或受影响领域 owner 评审 | 提升 `V1.x` |\n| `Breaking` | 改变真相源、团队职责、契约兼容、发布准入或迁移路径 | 企业架构评审；必须有 ADR、迁移计划和弃用策略 | 进入下一主版本或明确迁移版本 |\n\n### 0.4 版本发布证据\n\n每次提升版本前，至少保留以下证据：\n\n1. 变更摘要：说明新增、修改、删除和废弃内容。\n2. 影响范围：列出受影响的架构层、目录、团队、契约、门禁和落地流程。\n3. 决策记录：重大变更必须链接 ADR 或评审记录。\n4. 版本清单：同步更新 `本地私有版本清单`，并让 CI 校验版本、状态、pair 数量、控制项数量和索引提及。\n5. 控制覆盖：同步更新 `本地私有控制项覆盖清单`，并让 CI 校验控制项到 schema、example 和 checker 证据链。\n6. 索引同步：同步更新 `.github/docs/README.md`、`.github/docs/gongfa/README.md`、`.github/metadata/taxonomy.yml` 和 AI 引用语料入口。\n7. 链接校验：仓库内 Markdown 链接和锚点必须通过检查。\n8. 格式校验：Markdown lint 和文档结构检查必须通过。\n9. 回滚入口：保留上一版本引用、Git commit 或变更记录，保证可以回退到上一基线。\n\nV2.31 起，生产基线发布还必须形成 `baseline-release-evidence.yaml`。它不是普通 release note，而是晋级、冻结和复核的证据包，用于证明当前基线与版本控制面、控制覆盖、标准基线、审计导出和远端保护状态一致。\n\nV2.32 起，任何 `Major`、`Breaking` 或带迁移窗口的 `Minor` 基线还必须形成 `baseline-compatibility-ledger.yaml`。它用于证明消费者影响已经识别，迁移状态可以跟踪，未迁移对象已经进入例外、POA&M 或风险接受。\n\nV2.33 起，企业级基线还必须形成 `baseline-adoption-ledger.yaml`。它用于证明哪些领域、平台、数据产品、AI 产品、GitOps 环境和生产资产已经采用当前基线，哪些仍在迁移、逾期、例外或整改。\n\nV2.34 起，企业级基线还必须形成 `baseline-support-matrix.yaml`。它用于证明每条历史基线处于 active、maintenance、security-only、frozen、superseded 还是 eol，哪些门禁等级仍允许使用，安全补丁窗口何时结束，以及旧基线是否必须迁移或退役。\n\nV2.35 起，企业级基线还必须形成 `baseline-release-train.yaml`。它用于证明基线发布不再是临时动作，而是具备候选窗口、冻结窗口、晋级日期、通知节奏、黑窗、紧急补丁入口和发布节奏的受控列车。\n\nV2.36 起，纳入企业基线治理的资产还必须形成 `baseline-conformance-claim.yaml`。它用于证明单个领域、服务、数据产品、AI 产品、平台能力或 GitOps 环境声明采用哪条基线、由谁签署、证据在哪里、例外何时到期，以及这条声明如何汇总到组织级采纳总账。\n\nV2.37 起，企业级基线还必须形成 `baseline-artifact-inventory.yaml`。它用于证明当前基线到底包含哪些源文档、schema、示例、控制项、证据模板、脚本、生成物和外部引用，并为每个制品记录路径、类型、摘要、owner、必需性、签名状态和导出关系。\n\nV2.38 起，企业级基线还必须形成 `baseline-verification-lock.yaml`。它用于证明当前基线由哪些命令、工具版本、runner 镜像、策略包、schema validator、签名验签工具和审计导出生成环境验证，避免同一源制品因为工具链漂移产生不同门禁结果。\n\nV2.39 起，企业级基线还必须形成 `baseline-notification-ledger.yaml`。它用于证明哪些领域 owner、平台 owner、数据产品 owner、AI 产品 owner、GitOps 环境 owner 和审计/安全相关方在冻结前收到通知，是否确认影响，是否提出异议，以及未确认对象是否已有例外、POA&M 或风险接受。\n\nV2.40 起，企业级基线还必须形成 `baseline-rollback-verification.yaml`。它用于证明上一基线、回滚目标 tag/commit、GitOps revision、审计导出恢复、关键烟测和验证时效已经被实际检查，避免“有回滚说明但无法恢复”的空心化基线。\n\nV2.41 起，企业级基线还必须形成 `baseline-exception-ledger.yaml`。它不是替代单项 `policy-exception.yaml`，而是把兼容性、采纳、支持矩阵、通知确认、回滚验证、门禁决策、执行控制面和风险登记中的例外聚合为基线级总账，用于证明哪些例外仍有效、哪些已经过期、哪些会阻断冻结、哪些已经有风险接受和 POA&M。\n\nV2.42 起，企业级基线还必须形成 `baseline-readiness-scorecard.yaml`。它不是替代发布证据包，而是把发布证据包中分散的硬门禁和评分维度汇总成最终就绪判定，用于回答“这条基线现在是否可以进入 baseline 或 frozen，而不是只看每个局部证据是否存在”。\n\nV2.43 起，企业级基线还必须形成 `baseline-lifecycle-state-machine.yaml`。它不是替代版本控制面或发布证据包，而是把每次状态迁移的允许路径、禁止路径、前置证据、审批责任、回写对象和回滚入口固化为状态机，用于避免基线状态被人工口头解释或跨系统漂移。\n\nV2.44 起，企业级基线还必须形成 `baseline-state-reconciliation-report.yaml`。它不是替代生命周期状态机，而是把状态机、版本控制面、发布证据、支持矩阵、发布列车、采纳总账、符合性声明和审计导出中的状态字段做交叉对账，用于证明“各账本都在说同一个版本状态”。\n\nV2.45 起，企业级基线还必须形成 `baseline-eol-retirement-certificate.yaml`。它不是替代支持矩阵，而是证明某条旧基线进入 EOL 前，生产引用已经清零，采纳和迁移总账已经关闭，未迁移例外已经清零或完成风险接受，审计证据已经归档，新采用已经被平台、catalog 和 GitOps 阻断。\n\nV2.46 起，企业级基线还必须形成 `baseline-review-board-decision.yaml`。它不是替代就绪评分卡或发布证据包，而是证明架构、平台、安全、数据、AI、SRE、FinOps 和审计相关 owner 已经对晋级证据做过独立会审，反对意见和条件放行已经进入整改、POA&M 或风险接受，最终裁决具备签署、有效期和复核入口。\n\nV2.47 起，企业级基线还必须形成 `baseline-evidence-trace-graph.yaml`。它不是替代状态对账或审计导出，而是把所有关键证据的路径、摘要、来源、依赖、下游消费、状态和阻断条件编成一张证据图，用于证明 release gate 看到的是同一组证据事实。\n\nV2.48 起，企业级基线还必须形成 `baseline-gate-execution-report.yaml`。它不是替代门禁决策，而是证明门禁命令、runner、策略包、schema 包、输入摘要、规则结果、退出码、重放结果和最终决策来自同一次可复现执行，避免“写了 pass，但没有跑”的空心化放行。\n\nV2.97 起，企业级基线还必须形成 `baseline-gate-negative-test-suite.yaml`。它不是替代 `baseline-gate-execution-report.yaml`，而是证明 release gate、starter gate、审计导出、运行时准入和状态迁移阻断规则在错误输入、过期证据、摘要漂移、签名缺失、私有资产误入、例外过期和证据保证等级不足时会 fail-closed，避免只证明好样例通过、却无法证明坏样例被拒绝。\n\nV2.98 起，企业级基线还必须形成 `baseline-ai-system-regulatory-impact-ledger.yaml`。它不是替代 AI 产品契约、AI 证据账本、DPIA、监管义务总账或风险登记，而是把每个 AI 系统的用途、部署角色、适用司法辖区、风险分类、禁止/高风险/通用目的 AI 判断、人工监督、日志留存、技术文档、数据治理、透明度义务、后市场监测、供应商责任和合规缺口纳入统一证据链；任何高风险 AI 无分类、无人工监督、无日志、无技术文档、无后市场监测、无义务映射或未关闭合规缺口，都必须阻断 baseline/frozen 晋级。\n\nV2.49 起，企业级基线还必须形成 `baseline-publish-transaction.yaml`。它不是替代 Git 或发布证据包，而是证明这次基线发布事务的提交前状态、提交对象、签名 tag、远端 ref、push 回执、保护规则、禁推资产排除和发布后校验来自同一个不可变发布事实。\n\nV2.50 起，企业级基线还必须形成 `baseline-revocation-record.yaml`。它不是替代回滚验证或事故复盘，而是证明已发布基线在发现严重发布错误、签名泄露、证据污染、远端保护失效或禁推资产误入时，能够被隔离、撤销、通知、恢复和归档。\n\nV2.51 起，企业级基线还必须形成 `baseline-enforcement-policy.yaml`。它不是替代支持矩阵、采纳总账或符合性声明，而是把这些账本转成 release gate、GitOps、catalog 和 Golden Path 能直接执行的准入策略，证明低于最低基线、撤销/EOL 基线、无资产声明或过期例外不会被继续采用。\n\nV2.52 起，纳入企业基线治理的资产还必须形成 `baseline-consumption-lock.yaml`。它不是替代符合性声明，而是把资产实际消费的基线固定到 baseline ID、source commit、release tag 和关键证据摘要，禁止项目只写 `V2.x` 这种浮动版本声明。\n\nV2.53 起，纳入企业基线治理的资产迁移还必须形成 `baseline-migration-work-order.yaml`。它不是替代采纳总账，而是把每个资产从当前基线迁移到目标基线的执行步骤、依赖、GitOps 变更、消费锁更新、验收证据和回滚动作变成可追踪工单。\n\nV2.54 起，完成基线迁移的资产还必须形成 `baseline-migration-execution-receipt.yaml`。它不是替代迁移工作单，而是证明工作单中的每一步已经由谁、在什么环境、用哪些命令执行，执行前后摘要如何变化，验收日志和回滚验证是否真实存在。\n\nV2.55 起，所有被声明为本地、私有、生成或禁推的可执行资产还必须形成 `baseline-local-artifact-boundary.yaml`。它不是替代制品清单或发布事务回执，而是证明这些资产为什么不进入远程、如何验证、摘要如何留存、哪些命令证明未被跟踪或推送。\n\nV2.56 起，正式审计导出还必须形成 `audit-export-exclusion-manifest.yaml`。它不是替代审计导出清单，而是证明哪些原文允许进入审计包，哪些本地私有资产只保留摘要和边界证据，哪些内容必须从签名 payload 中排除。\n\nV2.57 起，所有不进入公开远端的可执行资产还必须形成 `private-artifact-escrow-manifest.yaml`。它不是放宽禁推边界，而是证明这些资产已经进入私有制品库、私有 registry 或证据托管区，具备不可变摘要、访问控制、留存期限、取回命令和恢复验证。\n\nV2.58 起，企业级基线还必须形成 `baseline-clean-room-reconstruction-receipt.yaml`。它不是替代验证锁、制品清单或私有托管清单，而是证明一台没有个人工作区残留的干净 runner，可以从远端不可变 commit、私有托管制品和锁定工具链重建同一套基线、审计导出和门禁结果。\n\nV2.59 起，企业级基线还必须形成 `baseline-evidence-archive-receipt.yaml`。它不是替代审计导出或干净环境重建，而是证明关键证据已经进入不可变留存库，具备对象锁、WORM、防删除、legal hold、访问日志、留存到期和恢复演练证据。\n\nV2.60 起，企业级基线还必须形成 `baseline-signature-ltv-receipt.yaml`。它不是替代签名验签回执，而是证明签名材料具备长期验证能力：验证时间点、证书链、OIDC 身份、透明日志 inclusion proof、signed entry timestamp、RFC3161 TSA、撤销状态、工具版本和归档位置都能被独立复核。\n\nV2.61 起，企业级基线还必须形成 `baseline-runtime-admission-receipt.yaml`。它不是替代发布门禁或 GitOps diff，而是证明生产运行入口已经实际执行准入策略：Kubernetes admission、策略引擎、镜像 digest、签名验签、provenance、SBOM、基线消费锁、撤销/EOL 阻断、例外到期和拒绝样例都能被独立复核。\n\nV2.62 起，企业级基线还必须形成 `baseline-runtime-admission-decision-ledger.yaml`。它不是替代运行时准入回执，而是把每一次 allow / deny 决策的 Kubernetes audit requestUID、admission webhook、策略规则、PolicyReport、OPA decision log、actor、namespace、工作负载、镜像 digest 和原始日志摘要固化为逐条证据。\n\nV2.63 起，企业级基线还必须形成 `baseline-continuous-control-monitoring-ledger.yaml`。它不是替代发布证据、门禁执行或状态对账，而是证明关键控制项在发布之后仍被持续监测：指标、日志、告警规则、监测窗口、owner、处置工单、漂移关闭和证据新鲜度都能被独立复核。\n\nV2.64 起，企业级基线还必须形成 `baseline-control-assurance-sampling-ledger.yaml`。它不是替代连续控制监测或控制评估报告，而是证明关键控制已经被独立评估人按可复现抽样计划执行设计有效性和运行有效性测试：控制总体、样本方法、样本证据、发现项、整改、残余风险、签署和 OSCAL Assessment Results 都能被审计复核。\n\nV2.95 起，企业级基线还必须形成 `baseline-evidence-assurance-classification.yaml`。它不是替代证据追踪图、控制保证抽样或审计导出，而是给每个关键证据节点标注保证等级、采信状态、生成方式、来源独立性、完整性证明、新鲜度窗口和可重放要求，证明 gate 使用的是足以支撑当前风险等级的证据，而不是仅仅“有一个文件”。\n\nV2.65 起，企业级基线还必须形成 `baseline-control-inheritance-ledger.yaml`。它不是替代 RACI 或控制面，而是证明哪些控制由平台、云服务商、第三方、领域团队或资产消费者承担，哪些控制可以继承，继承条件是什么，消费者仍需完成哪些配置义务，以及继承失效时如何转入例外、POA&M 或阻断。\n\nV2.66 起，企业级基线还必须形成 `baseline-data-residency-transfer-ledger.yaml`。它不是替代隐私影响评估或数据处理清单，而是证明每类数据在存储、处理、备份、日志、向量索引、模型供应商和人工支持链路中的实际位置，跨区域或跨境传输使用什么机制，补充保护措施是否生效，子处理方是否批准，以及区域漂移、出境机制缺失或删除传播失败时如何阻断。\n\nV2.67 起，企业级基线还必须形成 `baseline-third-party-risk-ledger.yaml`。它不是替代采购台账、供应商清单或合同归档，而是证明关键供应商、ICT 服务商、SaaS、云平台、模型供应商、外包方和子处理方的关键性、服务范围、数据类别、合同控制、DPA / SLA、审计权、保证报告、集中度、退出计划、替代路径、连续性、事件状态和开放发现项均已进入统一阻断证据。\n\nV2.68 起，企业级基线还必须形成 `baseline-operational-resilience-ledger.yaml`。它不是替代 SLO、RTO/RPO、恢复演练或第三方风险总账，而是证明企业已经识别重要业务服务，定义影响容忍，完成业务影响分析和端到端依赖映射，并通过严重但合理场景测试证明服务、数据、AI、平台、人员、供应商和沟通机制能把实际影响控制在容忍边界内。\n\nV2.69 起，企业级基线还必须形成 `baseline-regulatory-obligation-ledger.yaml`。它不是替代控制面、控制证据映射、风险登记或法务合规台账，而是证明每条适用监管义务、标准要求、客户合同义务和内部政策要求已经映射到控制目标、控制项、适用资产、责任 owner、证据路径、例外、POA&M、监管变更监测和发布门禁。\n\nV2.70 起，企业级基线还必须形成 `baseline-records-retention-legal-hold-ledger.yaml`。它不是替代数据处理清单、审计日志策略、证据归档回执或法务案件系统，而是证明每类企业记录都有留存排期、义务来源、司法辖区、owner、legal hold 支持、删除资格、删除传播、备份处置、向量索引处置、保全解除和可防御删除回执。\n\nV2.71 起，企业级基线还必须形成 `baseline-privacy-rights-consent-ledger.yaml`。它不是替代 DPIA、隐私政策、同意管理平台或 DSAR 工单系统，而是证明每个处理目的都有合法基础、同意状态和偏好传播均可追溯，主体访问、更正、删除、限制、携带、反对、opt-out 和自动化决策复核请求均按 SLA 闭环，AI、数据产品、营销、向量索引和第三方下游处理不会在撤回同意、缺失合法基础或权利请求逾期时继续执行。\n\nV2.72 起，企业级基线还必须形成 `baseline-processing-activity-inventory-ledger.yaml`。它不是替代 RoPA、数据目录、CMDB、DPIA、数据产品契约或同意管理平台，而是证明所有个人数据处理活动、数据主体类别、个人数据类别、控制者/处理者角色、接收方、跨境传输、保留映射、合法基础、DPIA、AI 用途和第三方下游处理都已经进入统一覆盖总账；任何未入账处理活动、未知个人数据类别、无 owner 活动或发现扫描未闭环都必须阻断 baseline/frozen 晋级。\n\nV2.73 起，企业级基线还必须形成 `baseline-identity-entitlement-access-ledger.yaml`。它不是替代 IAM、IdP、PAM、Kubernetes RBAC、Cloud IAM、SCIM、HRIS 或访问复核报告，而是证明所有人类身份、服务账号、工作负载身份、特权角色、JML 事件、MFA、PAM/JIT、break-glass、最小权限、孤儿账号、过期权限和运行时身份绑定已经进入统一权限总账；任何未知身份、无 owner 服务账号、离职账号未撤销、特权访问无审批或无 MFA、break-glass 未关闭、工作负载身份漂移或过期权限未清理都必须阻断 baseline/frozen 晋级。\n\nV2.74 起，企业级基线还必须形成 `baseline-asset-criticality-classification-ledger.yaml`。它不是替代 catalog、CMDB、数据目录、AI 产品目录、风险登记、SLO、conformance profile 或隐私/AI 影响评估，而是证明每个受治理资产已经有 owner、业务关键性、SLO Tier、L3/L4 合规等级、CIA 影响、数据敏感度、监管暴露、AI 风险等级、互联网暴露、第三方关键性和复核状态；任何未知资产、无 owner、未知数据分类、CIA 影响缺失、关键资产低估、L3/L4 与 conformance profile 不一致、AI 风险低估或分级复核过期都必须阻断 baseline/frozen 晋级。\n\nV2.75 起，企业级基线还必须形成 `baseline-cryptographic-secrets-key-certificate-ledger.yaml`。它不是替代 KMS、HSM、Vault、cert-manager、CA、Secret Manager、CI 签名系统、TLS 扫描器或 secrets rotation evidence，而是证明所有生产密码材料、密钥、证书、token、数据库凭据、webhook secret、签名密钥和工作负载密钥已经有 owner、用途、托管位置、算法、强度、轮换周期、过期时间、吊销路径、泄露响应和访问边界；任何未知密码材料、无 owner、明文存放、弱算法、过期证书、轮换超期、吊销路径缺失、泄露未关闭或签名密钥托管不清都必须阻断 baseline/frozen 晋级。\n\nV2.76 起，企业级基线还必须形成 `baseline-backup-restore-disaster-recovery-ledger.yaml`。它不是替代备份平台、对象锁、灾备系统、恢复演练记录、SRE runbook、运营韧性总账或记录留存总账，而是证明所有 L3/L4 关键系统、数据库、对象存储、配置仓库、消息队列、向量索引和审计证据都有 owner、备份策略、不可变或离线副本、跨区域/跨账号隔离、加密、保留、恢复步骤、最近成功恢复演练、RTO/RPO 结果、完整性校验和勒索隔离证明；任何关键资产无备份、无不可变副本、恢复演练超期、RTO/RPO 失败、备份不可读、恢复权限不受控或勒索隔离不可证明都必须阻断 baseline/frozen 晋级。\n\nV2.77 起，企业级基线还必须形成 `baseline-service-reliability-slo-error-budget-observability-ledger.yaml`。它不是替代服务契约、监控平台、日志平台、Tracing、SRE runbook、事故复盘或连续控制监测总账，而是证明所有 L3/L4 生产服务、关键用户旅程、外部 API、异步处理链路、AI/数据依赖和平台能力都有 owner、SLI/SLO、错误预算、告警规则、on-call、升级路径、runbook、合成探测、指标/日志/链路覆盖、仪表盘、降级策略和错误预算消耗记录；任何关键服务无 SLO、SLI 不可测、错误预算超支未冻结风险变更、关键告警无人接、可观测性缺口、runbook 缺失或合成探测不覆盖用户旅程都必须阻断 baseline/frozen 晋级。\n\nV2.78 起，企业级基线还必须形成 `baseline-capacity-performance-cost-efficiency-ledger.yaml`。它不是替代压测报告、APM、Kubernetes 配额、自动扩缩容配置、FinOps 报表、OpenCost、FOCUS 数据集或成本分摊证据，而是证明所有 L3/L4 生产服务、关键用户旅程、数据/AI 工作负载、队列、数据库、缓存、批处理和平台共享能力都有 owner、容量预测、性能基准、压测结果、资源 requests/limits、弹性伸缩策略、预算、单位经济、成本分摊、异常成本处置和优化行动；任何关键服务无容量模型、压测过期、p95/p99 退化、资源未声明、HPA/VPA/KEDA 缺失、队列积压不可解释、数据库容量不足、预算超支无审批、单位成本不可解释或成本异常未关闭都必须阻断 baseline/frozen 晋级。\n\nV2.79 起，企业级基线还必须形成 `baseline-threat-model-attack-surface-risk-ledger.yaml`。它不是替代 AI 威胁模型、漏洞扫描、渗透测试、安全评审、资产分级或风险登记，而是证明所有 L3/L4 服务、API、事件、数据产品、AI 产品、GitOps 入口、平台共享能力和关键第三方接入都有 owner、信任边界、数据流、攻击面、滥用场景、STRIDE/LINDDUN/OWASP 控制映射、安全测试证据、剩余风险、POA&M 或风险接受；任何关键资产无威胁模型、模型过期、互联网暴露未知、信任边界未画清、高风险数据流无缓解、关键滥用场景未关闭、安全测试缺失、剩余风险未签署或威胁模型未进入 release gate 都必须阻断 baseline/frozen 晋级。\n\nV2.80 起，企业级基线还必须形成 `baseline-vulnerability-exposure-remediation-ledger.yaml`。它不是替代漏洞扫描器、SBOM、VEX/CSAF、SCA、容器扫描、IaC 扫描、云安全态势管理、外部攻击面管理或单项漏洞修复证据，而是证明所有 L3/L4 服务、容器镜像、依赖、基础镜像、IaC、Kubernetes 配置、云资源、外部暴露入口、API、AI 工具和第三方接入都有漏洞发现、可利用性判断、业务暴露、owner、修复 SLA、补丁或缓解动作、复测证据、例外、POA&M 或风险接受；任何 critical/KEV 漏洞未关闭、互联网暴露 high 漏洞未关闭、扫描覆盖缺口、复测缺失、例外过期、VEX/CSAF 状态缺失或漏洞总账未进入 release gate 都必须阻断 baseline/frozen 晋级。\n\nV2.81 起，企业级基线还必须形成 `baseline-secure-configuration-posture-drift-ledger.yaml`。它不是替代 CIS Benchmark、SCAP、CSPM、KSPM、IaC policy scan、runtime admission、租户边界、云配置扫描或单项加固工单，而是证明所有 L3/L4 OS、容器镜像、Kubernetes、云账号、IAM、网络、存储、数据库、CI/CD、API Gateway、LLM Gateway、Agent Runtime、审计日志、加密配置和平台共享能力都有期望安全配置基线、观测姿态、漂移、owner、修复 SLA、复测、例外、POA&M 或风险接受；任何关键配置基线缺失、critical CIS/NIST/Pod Security 失败、未批准特权 Pod、公共存储暴露、弱 TLS、审计日志关闭、漂移未修复、例外过期或安全配置总账未进入 release gate 都必须阻断 baseline/frozen 晋级。\n\nV2.82 起，企业级基线还必须形成 `baseline-production-change-release-ledger.yaml`。它不是替代 GitOps、发布事务回执、发布列车、变更单系统、Feature Flag 平台、数据库迁移工具或事故复盘；这些系统分别记录局部事实。该总账证明每一次 L3/L4 生产变更都已经有变更类型、业务动机、风险等级、影响面、变更窗口、冲突检测、依赖冻结、审批或自动准入、前置门禁、回滚计划、执行证据、失败恢复、事故关联和 DORA 指标回写；任何未登记生产变更、黑窗内非紧急变更、关键依赖冲突、缺回滚路径、数据库迁移未演练、Prompt/模型变更未评估、Feature Flag 无 kill switch、紧急变更无事后复盘或变更失败未关闭，都必须阻断 baseline/frozen 晋级。\n\nV2.83 起，企业级基线还必须形成 `baseline-incident-problem-corrective-action-ledger.yaml`。它不是替代事故系统、值班记录、SRE 复盘、问题管理、AI 事件响应、供应商事件、隐私事件、POA&M 或风险登记；这些系统分别记录局部事实。该总账证明每一次 L3/L4 生产事故、安全事件、隐私事件、AI 事件、供应商事件、near miss 和重大告警都已经有时间线、影响范围、严重度、owner、检测/响应/恢复时间、根因或促成因素、临时遏制、永久纠正行动、复发防止、runbook 更新、告警或门禁反哺、客户/监管沟通、风险接受或 POA&M 关闭证据；任何事故未定级、无 owner、RCA 缺失、纠正行动逾期、runbook 未更新、同类事故复发未升级、监管通知缺失或问题记录未关闭，都必须阻断 baseline/frozen 晋级。\n\nV2.84 起，企业级基线还必须形成 `baseline-data-product-quality-contract-observability-ledger.yaml`。它不是替代数据目录、数据契约、OpenLineage、数据质量平台、BI 仪表盘、Feature Store、向量索引、AI 证据账本、隐私总账、事故总账或数据团队工单；这些系统分别记录局部事实。该总账证明每个 L3/L4 数据产品都有 owner、契约版本、schema 漂移状态、质量断言、freshness、完整性、唯一性、语义口径、访问授权、血缘、下游消费者影响、AI/特征/RAG 使用边界、契约违约、修复复测和数据质量事故闭环；任何无 owner、契约缺失、schema drift 未关闭、freshness/SLA 违约、质量断言失败、血缘断裂、消费者未通知、AI/RAG 使用未授权、契约违约逾期或修复未复测，都必须阻断 baseline/frozen 晋级。\n\nV2.85 起，企业级基线还必须形成 `baseline-engineering-quality-test-release-verification-ledger.yaml`。它不是替代 CI、测试框架、测试管理系统、缺陷系统、UAT 签署、灰度平台、冒烟监控或发布证据包；这些系统分别记录局部事实。该总账证明每个 L3/L4 服务、API、事件、数据产品、AI 产品和平台能力都有 owner、需求追踪、风险化测试计划、单元/集成/契约/E2E/回归/验收测试、覆盖率阈值、测试环境、测试数据、flaky 测试治理、缺陷分级、已知缺陷风险接受、修复复测、发布前验证、灰度/冒烟结果和质量风险接受闭环；任何无 owner、无需求追踪、关键测试缺失、覆盖率低于阈值、flaky 测试逾期、critical/high 缺陷未关闭或未接受、修复未复测、测试环境漂移、测试数据违规、发布验证缺失或质量风险未签署，都必须阻断 baseline/frozen 晋级。\n\nV2.86 起，企业级基线还必须形成 `baseline-workforce-competency-training-duty-segregation-ledger.yaml`。它不是替代 HRIS、LMS、IAM、值班系统、RACI 表、会审裁决、访问复核或培训记录；这些系统分别记录局部事实。该总账证明每个 L3/L4 关键角色都有正式任命、岗位资格、职责确认、培训完成、专项训练、值班资格、审批授权、代理授权、职责分离检查、冲突角色治理和到期复核闭环；任何关键角色无任命、培训过期、专项资格缺失、职责未确认、on-call 未认证、审批人与执行人未分离、冲突权限未关闭、代理授权过期或关键岗位无人备份，都必须阻断 baseline/frozen 晋级。\n\nV2.87 起，企业级基线还必须形成 `baseline-business-outcome-value-realization-portfolio-ledger.yaml`。它不是替代 OKR、KPI、投资组合管理、财务预算、产品指标、FinOps 报表、采纳总账或会审裁决；这些系统分别记录局部事实。该总账证明每个 L3/L4 架构基线、领域能力、平台能力、数据产品、AI 产品和重大生产变更都有业务目标、价值假设、收益 owner、投资组合归属、关键结果、前后基线、采用证据、收益实现状态、成本效率、风险接受和停投/加投决策闭环；任何无业务目标、无收益 owner、关键结果不可测、前后基线缺失、收益未实现且无决策、成本效率不可解释或价值总账未进入 release gate，都必须阻断 baseline/frozen 晋级。\n\nV2.88 起，企业级基线还必须形成 `baseline-value-stream-journey-process-ledger.yaml`。它不是替代业务流程图、BPMN 模型、流程挖掘平台、产品分析、服务 SLO、运营韧性总账或业务结果总账；这些系统分别记录局部事实。该总账证明每个 L3/L4 关键价值流、客户旅程和跨领域业务流程都有流程 owner、触发事件、完成定义、步骤模型、跨域责任、服务/数据/API/AI 依赖、端到端指标、步骤级遥测、等待时间、重试与异常、人工兜底、控制点、瓶颈、改进动作和结果联动闭环；任何关键流程无 owner、模型过期、步骤遥测缺失、跨域交接不可追溯、瓶颈未处置、异常未闭环、人工兜底未演练或流程总账未进入 release gate，都必须阻断 baseline/frozen 晋级。\n\nV2.89 起，企业级基线还必须形成 `baseline-architecture-view-runtime-topology-dependency-ledger.yaml`。它不是替代架构图、C4 模型、catalog、CMDB、GitOps、服务网格、OpenTelemetry、OpenLineage、APM、网络流量分析或部署平台；这些系统分别记录局部事实。该总账证明每个 L3/L4 资产、关键旅程和重要业务服务都有当前架构视图、运行拓扑、声明依赖、观测依赖、部署拓扑、数据/AI/第三方依赖、关键路径、blast radius、变更影响、依赖 owner、未知依赖处置和视图过期复核闭环；任何架构视图过期、声明依赖与观测依赖不一致、关键依赖无 owner、未知调用开放、blast radius 未评估、部署拓扑不可追踪或依赖总账未进入 release gate，都必须阻断 baseline/frozen 晋级。\n\nV2.90 起，企业级基线还必须形成 `baseline-quality-attribute-architecture-driver-tradeoff-ledger.yaml`。它不是替代 ADR、ATAM 评审、质量需求文档、SLO、压测报告、安全测试、韧性演练、成本分析或业务目标总账；这些系统分别记录局部事实。该总账证明每个 L3/L4 架构基线、关键旅程、重要业务服务和高影响变更都有业务驱动、质量属性场景、可度量响应指标、架构驱动、敏感点、权衡点、备选方案、已选策略、适配度函数、验证证据和复核闭环；任何高优先级质量属性无场景、无可测响应指标、无验证证据、关键权衡无 ADR、敏感点无监测、适配度函数未进入门禁或质量属性总账未进入 release gate，都必须阻断 baseline/frozen 晋级。\n\nV2.91 起，企业级基线还必须形成 `baseline-architecture-principle-constraint-exception-ledger.yaml`。它不是替代架构原则文档、标准基线、ADR、风险登记、例外总账、控制面、门禁执行报告或会审裁决；这些系统分别记录局部事实。该总账证明每条 L3/L4 强制架构原则都有 owner、适用范围、约束规则、禁止项、反模式、检测方式、门禁入口、违反处置、例外审批、风险接受、ADR 绑定和复核闭环；任何强制原则无 owner、约束不可检测、禁止项未进入门禁、违反未处置、例外过期、风险接受缺失或原则总账未进入 release gate，都必须阻断 baseline/frozen 晋级。\n\nV2.92 起，企业级基线还必须形成 `baseline-version-policy-release-control-ledger.yaml`。它不是替代版本控制面、版本清单、发布事务回执、兼容性总账、支持矩阵、采纳总账、消费锁、迁移工作单或撤销隔离记录；这些系统分别记录局部事实。该总账证明每一次版本变更都有 SemVer 语义、Conventional Commit 分类、发布通道、候选/冻结/紧急补丁规则、签名 tag、不可变 commit、兼容窗口、消费者影响、消费锁更新、迁移窗口、撤销条件、EOL 约束、禁推资产排除和证据摘要闭环；任何版本号复用、浮动版本引用、tag 漂移、未签名生产 tag、breaking change 无迁移窗口、紧急补丁无复盘、冻结期语义变更、撤销基线仍被采用或版本策略总账未进入 release gate，都必须阻断 baseline/frozen 晋级。\n\n推荐发布检查：\n\n```bash\nmake sync-doc-toc\nmake test\ngit diff --check\n```\n\n### 0.5 冻结规则\n\n当某个版本被标记为 `Frozen` 后：\n\n1. 不得直接修改核心架构原则、目录真相源、团队职责、治理门禁和落地路线图。\n2. 任何实质性变更必须先创建变更提案，并说明业务动机、影响范围、风险和迁移计划。\n3. 安全、合规、生产事故或关键错误可走紧急补丁，但必须在事后补齐 ADR 或复盘。\n4. 被替代版本必须标记为 `Superseded`，并说明新版本位置和迁移注意事项。\n5. 冻结版本不得与未冻结草案混用；项目启动、审计和平台模板必须引用明确版本。\n\n### 0.6 版本控制面不变量\n\n版本控制面用于回答“这次基线到底是哪一版、谁批准、从哪个 commit 发布、覆盖哪些契约、能不能兼容、如何回滚”。它不替代 Git、release note 或审计导出包，而是把这些证据绑定成同一个发布事实。\n\n基线发布必须满足以下不变量：\n\n| 不变量 | 最低要求 | 阻断条件 |\n| ------ | -------- | -------- |\n| 基线身份 | `baselineId`、`documentVersion`、`status` 唯一且不可复用 | 同一版本号对应多个基线或状态不一致 |\n| 版本策略总账 | `baseline-version-policy-release-control-ledger.yaml` 必须绑定版本号语义、发布通道、变更分类、签名 tag、兼容窗口、冻结规则、紧急补丁、撤销条件、消费锁和迁移窗口 | 版本号复用、tag 漂移、浮动版本引用、breaking change 无迁移路径、冻结期语义变更、撤销基线仍被采用或版本策略未进入 release gate |\n| 生命周期状态 | `baseline-lifecycle-state-machine.yaml` 必须绑定当前状态、允许迁移、禁止迁移、转换证据、审批人、状态回写和回滚入口 | 人工改状态、跨过候选或冻结门禁、直接从冻结退回草案、状态机和版本控制面不一致 |\n| 状态对账 | `baseline-state-reconciliation-report.yaml` 必须对账状态机、版本控制面、发布证据、支持矩阵、采纳总账、符合性声明和审计导出 | 任一账本状态漂移、状态字段冲突、状态回写缺失或审计导出引用旧状态 |\n| 源码绑定 | 每个基线绑定 `sourceCommit`、`releaseTag` 和签署人 | 无 tag、tag 不指向源 commit、签名缺失 |\n| 制品清单 | `baseline-artifact-inventory.yaml` 必须列出基线纳入的源文档、schema、示例、控制项、证据模板、脚本、生成物和外部引用 | 基线签署但无法证明包含哪些文件、导出包缺源制品、出现未登记制品或摘要漂移 |\n| 验证环境锁 | `baseline-verification-lock.yaml` 必须锁定命令、工具版本、runner 镜像、策略包、validator 和验签工具 | 校验工具版本漂移、runner 环境不可复现、策略包或 validator 变化未入基线 |\n| 证据绑定 | 版本清单、控制项覆盖、审计导出、控制评估和门禁决策必须引用同一基线 | 证据包版本和文档版本不一致 |\n| 证据保证等级 | `baseline-evidence-assurance-classification.yaml` 必须为关键证据节点声明保证等级、采信状态、生成方式、来源独立性、完整性证明、新鲜度和可重放要求 | L3 / L4、baseline、frozen 或正式审计导出使用低等级、过期、不可重放、未签名、无独立性或不可采信证据 |\n| 发布证据包 | `baseline-release-evidence.yaml` 必须绑定晋级决策、不可变引用、漂移复核、签名验签和回滚验证 | 基线晋级无证据、证据引用不同 commit、漂移复核缺失 |\n| 兼容性总账 | `baseline-compatibility-ledger.yaml` 必须绑定消费者、受影响契约、迁移状态、到期日和例外闭环 | breaking change 无消费者清单、迁移窗口过期、未迁移对象无风险处理 |\n| 采纳总账 | `baseline-adoption-ledger.yaml` 必须绑定采纳目标、当前基线、目标基线、采纳状态、截止日期和整改闭环 | 企业基线发布后无人采用、采纳状态未知、关键资产逾期未整改 |\n| 支持矩阵 | `baseline-support-matrix.yaml` 必须绑定支持状态、维护窗口、安全补丁、EOL、最低可接受基线和例外闭环 | 旧基线长期无 EOL、低于最低基线仍被 L3/L4 使用、安全补丁窗口结束后继续放行 |\n| EOL 退役证书 | `baseline-eol-retirement-certificate.yaml` 必须证明旧基线生产引用清零、迁移关闭、例外清零、审计归档和新采用阻断 | 支持矩阵标记 EOL 但生产资产仍引用旧基线、未迁移对象无风险接受、EOL 后仍允许新采用 |\n| 会审裁决 | `baseline-review-board-decision.yaml` 必须证明会审范围、参与角色、证据核验、投票签署、反对意见、条件动作和最终裁决 | 评分卡通过但无人承担裁决责任、反对意见无闭环、条件放行无到期动作或风险接受 |\n| 证据追踪图 | `baseline-evidence-trace-graph.yaml` 必须证明关键证据节点、摘要、依赖、下游使用和状态一致 | 证据对象各自存在但互相引用旧摘要、发布证据没有覆盖会审裁决、审计导出使用了过期节点 |\n| 门禁执行报告 | `baseline-gate-execution-report.yaml` 必须证明门禁命令、runner 镜像、策略包、schema 包、输入摘要、逐条规则结果、退出码、重放结果和最终决策一致 | release gate 有放行结论但没有执行明细、策略包漂移、输入摘要不一致、规则未运行、重放失败或执行结果与最终决策不一致 |\n| 门禁负例测试 | `baseline-gate-negative-test-suite.yaml` 必须声明负例类别、输入 fixture、预期失败规则、实际失败结果、覆盖 gate、复测命令、回归 owner 和阻断状态 | 坏样例被放行、负例只登记未运行、期望失败无实际失败、失败原因和策略规则不一致、负例未覆盖 release/starter/audit/runtime/state-transition 关键门禁 |\n| AI 系统监管分类与影响评估 | `baseline-ai-system-regulatory-impact-ledger.yaml` 必须声明 AI 系统用途、部署角色、适用法规、风险分类、禁止/高风险/通用目的 AI 判断、人工监督、日志留存、技术文档、数据治理、透明度、后市场监测、供应商责任和合规缺口 | 高风险 AI 无分类、无人工监督、无日志留存、无技术文档、无后市场监测、无义务映射、模型供应商责任不清、合规缺口未关闭仍晋级 |\n| 发布事务回执 | `baseline-publish-transaction.yaml` 必须证明提交前检查、干净工作树、source commit、签名 tag、远端 ref、push 结果、tag 保护、禁推资产排除和发布后验证一致 | 文档声称已发布但远端没有 ref、tag 未签名、push 失败、工作树脏、禁推资产进入远端或发布后验证未执行 |\n| 撤销隔离记录 | `baseline-revocation-record.yaml` 必须证明撤销触发条件、隔离范围、受影响引用、通知对象、恢复目标、风险接受、审计归档和状态回写一致 | 坏基线已发布但无法撤销、签名泄露后仍被引用、禁推资产误入远端后没有隔离证据或下游继续采用 |\n| 准入执行策略 | `baseline-enforcement-policy.yaml` 必须把支持矩阵、采纳总账、符合性声明、撤销记录和例外总账转成统一阻断规则 | 低于最低基线仍可部署、撤销/EOL 基线仍可新采用、资产没有符合性声明但通过发布、例外过期仍放行 |\n| 消费锁定文件 | `baseline-consumption-lock.yaml` 必须由资产仓库锁定 baseline ID、source commit、release tag、证据图摘要、制品清单摘要、验证锁摘要和准入策略摘要 | 资产只声明 `V2.x` 浮动版本、消费锁摘要与发布证据不一致、锁文件过期或未回写采纳总账 |\n| 迁移工作单 | `baseline-migration-work-order.yaml` 必须把目标资产、当前基线、目标基线、执行步骤、依赖、消费锁更新、GitOps 变更、验收证据和回滚动作绑定 | 采纳总账要求迁移但无执行工单、工单无 owner/截止时间/验收证据、迁移完成但未更新消费锁或 GitOps |\n| 迁移执行回执 | `baseline-migration-execution-receipt.yaml` 必须证明每个迁移步骤的实际命令、actor、执行环境、before/after 摘要、GitOps revision、catalog/lock diff、验收日志和回滚验证 | 工单显示 completed 但没有执行日志、摘要变化不可证明、执行人未知、验收日志缺失或无法回滚 |\n| 本地私有制品边界 | `baseline-local-artifact-boundary.yaml` 必须声明本地私有 starter kit、生成 JSON、校验脚本和其他禁推资产的分类、摘要策略、允许用途、远端排除和验证命令 | 可执行资产缺失但没有私有边界说明、禁推资产被误推、审计导出误包含本地生成物或签名 payload 覆盖不清 |\n| 审计导出排除清单 | `audit-export-exclusion-manifest.yaml` 必须声明审计导出原文白名单、摘要留存项、强制排除项、签名 payload 排除项和导出后验证命令 | 本地私有资产边界存在但导出包仍误含原文、签名 payload 覆盖范围不清、审计包和边界摘要不一致 |\n| 私有制品托管交接 | `private-artifact-escrow-manifest.yaml` 必须声明私有制品库引用、不可变摘要、访问角色、留存期限、取回命令、恢复验证和摘要一致性 | 禁推资产不在远端也不在私有库、只有本地副本、权限不可审计、制品摘要和边界摘要不一致、恢复演练无法取回 |\n| 干净环境基线重建 | `baseline-clean-room-reconstruction-receipt.yaml` 必须声明干净 runner、远端 checkout、私有制品取回、摘要校验、审计导出重建、门禁重放和禁推资产复核 | 只在作者机器可运行、重建依赖未登记本地文件、私有制品无法按摘要取回、审计导出重建摘要不一致或门禁重放失败 |\n| 证据不可变归档 | `baseline-evidence-archive-receipt.yaml` 必须声明归档对象、不可变存储引用、留存策略、legal hold、访问日志、删除保护、恢复演练和摘要一致性 | 证据只留在 CI 工作区、本地目录或可改写对象桶，留存锁缺失、归档摘要漂移、legal hold 未记录、审计期无法恢复 |\n| 长期验签 | `baseline-signature-ltv-receipt.yaml` 必须声明签名 bundle、签名材料摘要、证书链、OIDC issuer、透明日志 proof、signed entry timestamp、RFC3161 TSA、撤销状态、验证工具版本和归档位置 | 当前验签通过但没有时间戳、证书过期后无法证明签名时间、透明日志 proof 丢失、撤销状态未知、验签工具漂移 |\n| 运行时准入 | `baseline-runtime-admission-receipt.yaml` 必须声明 admission controller、策略引擎、策略 bundle、命名空间范围、GitOps revision、镜像 digest、签名验签、provenance、SBOM、消费锁和拒绝样例 | release gate 通过但 runtime admission 未启用、集群策略漂移、未签名镜像被创建、撤销/EOL 基线仍可运行、例外过期仍被放行 |\n| 准入决策总账 | `baseline-runtime-admission-decision-ledger.yaml` 必须声明每条 allow/deny 的 requestUID、策略 ID、规则版本、actor、namespace、workload、image digest、决策结果、原始日志摘要和留存位置 | 有汇总回执但找不到逐条决策、deny 样例没有原始日志、allow 事件无法追到策略版本、Kubernetes audit 和策略引擎日志无法对账 |\n| 连续控制监测 | `baseline-continuous-control-monitoring-ledger.yaml` 必须声明控制项、监测指标、日志源、告警规则、窗口、owner、SLO、MTTD/MTTR、漂移事件、处置工单和证据新鲜度 | 发布时合规但运行后控制漂移、告警未配置、事件无人处理、证据过期、critical control 失效后仍保持 baseline/frozen |\n| 独立控制保证 | `baseline-control-assurance-sampling-ledger.yaml` 必须声明独立评估人、评估范围、控制总体、抽样方法、样本证据、设计有效性、运行有效性、发现项、整改、残余风险、签署和 OSCAL Assessment Results | 平台自证控制有效、评估人不独立、样本不可复现、critical 控制未抽样、设计或运行有效性失败后仍晋级 baseline/frozen |\n| 共享责任与继承控制 | `baseline-control-inheritance-ledger.yaml` 必须声明控制来源、控制承担方、继承方、共享责任、消费者义务、继承条件、证据引用、继承有效期、失效条件和审计映射 | 平台公共控制被口头继承、领域团队误以为平台全包、云/第三方责任未映射、消费者配置义务缺失、继承证据过期后仍放行 |\n| 数据驻留与跨境处理 | `baseline-data-residency-transfer-ledger.yaml` 必须声明数据类别、监管区域、允许区域、实际存储/处理/备份/日志/向量索引/模型供应商区域、传输机制、子处理方、补充保护措施、删除传播和区域漂移证据 | DPIA 通过但实际数据流向未知、日志或备份落到未批准区域、RAG 索引跨区、模型供应商处理位置不明、传输机制或补充措施缺失仍放行 |\n| 第三方与关键供应商风险 | `baseline-third-party-risk-ledger.yaml` 必须声明供应商分级、服务范围、受影响资产、数据类别、合同控制、DPA/SLA、审计权、保证报告、集中度、退出计划、替代路径、连续性和事件状态 | 关键 SaaS、云、模型供应商、外包方或子处理方未分级、合同和审计权缺失、保证报告过期、集中度超阈值、退出计划不可执行或供应商事故未进入基线阻断 |\n| 运营韧性与重要业务服务 | `baseline-operational-resilience-ledger.yaml` 必须声明重要业务服务、影响容忍、BIA、端到端依赖、严重但合理场景、场景测试、恢复能力、人工替代、沟通计划、第三方依赖、超限升级和开放韧性缺口 | 只按系统组件写 RTO/RPO，没有业务服务影响容忍；重要业务服务依赖未知；场景测试未覆盖云、数据、AI、供应商和人员失效；超出影响容忍仍可晋级 |\n| 威胁建模、攻击面与安全风险 | `baseline-threat-model-attack-surface-risk-ledger.yaml` 必须声明关键服务、API、事件、数据产品、AI 产品、GitOps 入口、平台能力、信任边界、数据流、攻击面、滥用场景、控制映射、安全测试、剩余风险、POA&M 和签署状态 | 关键资产无威胁模型、威胁模型过期、互联网暴露未知、信任边界未映射、高风险数据流无缓解、关键滥用场景未关闭、安全测试缺失、剩余风险未签署或未进入 release gate 仍晋级 |\n| 安全配置、加固姿态与配置漂移 | `baseline-secure-configuration-posture-drift-ledger.yaml` 必须声明 OS、容器、Kubernetes、云账号、IAM、网络、存储、数据库、CI/CD、API Gateway、LLM Gateway、Agent Runtime、审计日志、加密和 Pod Security 的期望基线、观测姿态、漂移、owner、修复 SLA、复测、例外和发布准入 | 安全配置基线缺失、CIS/NIST/Pod Security critical 失败、未批准特权 Pod、公共存储暴露、弱 TLS、审计日志关闭、漂移未修复、例外过期或未进入 release gate 仍晋级 |\n| 生产变更、发布编排与失败恢复 | `baseline-production-change-release-ledger.yaml` 必须声明生产代码部署、GitOps 同步、数据库迁移、配置变更、Feature Flag、Prompt/模型变更、紧急变更、变更窗口、冲突检测、回滚计划、执行证据、失败恢复、事故关联和 DORA 指标回写 | 未登记生产变更、黑窗内非紧急变更、关键依赖冲突、缺回滚路径、数据库迁移未演练、Prompt/模型变更未评估、Feature Flag 无 kill switch、紧急变更无事后复盘或变更失败未关闭仍晋级 |\n| 事故、问题、纠正行动与复发防止 | `baseline-incident-problem-corrective-action-ledger.yaml` 必须声明生产事故、安全事件、隐私事件、AI 事件、供应商事件、near miss、严重度、影响、时间线、MTTD/MTTR、RCA、问题记录、纠正行动、复发防止、runbook 更新、门禁反哺、沟通和 DORA 恢复指标 | 事故未定级、无 owner、无 RCA、纠正行动逾期、同类事故复发未升级、runbook/告警/门禁未反哺、监管或客户沟通缺失、问题记录未关闭仍晋级 |\n| 数据产品质量、契约违约、运行血缘与可观测性 | `baseline-data-product-quality-contract-observability-ledger.yaml` 必须声明数据产品 owner、契约版本、schema drift、质量断言、freshness、完整性、唯一性、语义口径、访问授权、运行血缘、消费者影响、AI/特征/RAG 使用、违约、修复复测和数据质量事故 | 数据产品无 owner、契约缺失、schema drift 未关闭、freshness/SLA 违约、质量断言失败、血缘断裂、消费者未通知、AI/RAG 使用未授权、契约违约逾期或修复未复测仍晋级 |\n| 工程质量、测试证据、缺陷与发布验证 | `baseline-engineering-quality-test-release-verification-ledger.yaml` 必须声明资产 owner、需求追踪、测试策略、测试金字塔、契约/E2E/回归/验收测试、覆盖率、测试环境、测试数据、flaky 测试、缺陷、回归复测、发布前验证、灰度/冒烟结果和质量风险接受 | 无需求追踪、关键测试缺失、覆盖率低于阈值、flaky 测试未治理、critical/high 缺陷未关闭、修复未复测、发布验证缺失、已知缺陷无风险接受仍晋级 |\n| 人员能力、培训、职责履职与职责分离 | `baseline-workforce-competency-training-duty-segregation-ledger.yaml` 必须声明关键角色、任命来源、岗位资格、职责确认、培训记录、专项训练、值班资格、审批授权、代理授权、职责分离、冲突角色、备份人员和到期复核 | 关键 owner 未任命、培训或专项资格过期、职责未确认、on-call 未认证、审批人与执行人未分离、冲突角色未关闭、代理授权过期或关键岗位无人备份仍晋级 |\n| 业务结果、价值实现与组合收益 | `baseline-business-outcome-value-realization-portfolio-ledger.yaml` 必须声明业务目标、价值假设、收益 owner、投资组合、关键结果、前后基线、采用证据、收益实现、成本效率、风险接受、停投/加投决策和复核周期 | 架构基线只证明交付或合规、无法证明业务结果、收益实现、成本效率、未实现价值处置和组合决策仍晋级 |\n| 价值流、关键旅程与端到端流程 | `baseline-value-stream-journey-process-ledger.yaml` 必须声明价值流、客户旅程、BPMN/流程模型、流程 owner、触发事件、完成定义、步骤责任、跨域交接、服务/数据/API/AI 依赖、端到端指标、步骤级遥测、瓶颈、异常、人工兜底、控制点和改进动作 | 业务结果已入账但关键旅程不可追踪、流程模型过期、跨域交接无 owner、步骤遥测缺失、瓶颈未处置、异常和人工兜底未演练仍晋级 |\n| 架构视图、运行拓扑与依赖影响 | `baseline-architecture-view-runtime-topology-dependency-ledger.yaml` 必须声明架构视图、C4/部署视图、catalog 声明依赖、运行时观测依赖、GitOps 拓扑、数据/AI/第三方依赖、关键路径、blast radius、变更影响、owner、漂移处置和复核周期 | 架构图过期、声明依赖与观测依赖不一致、关键依赖无 owner、未知调用开放、部署拓扑不可追踪、blast radius 未评估或依赖总账未进入 release gate 仍晋级 |\n| 质量属性、架构驱动与权衡决策 | `baseline-quality-attribute-architecture-driver-tradeoff-ledger.yaml` 必须声明业务驱动、质量属性场景、优先级、可度量响应指标、架构驱动、敏感点、权衡点、备选方案、ADR、适配度函数、验证证据和复核周期 | 质量目标不可测、业务目标和架构决策脱节、关键权衡无 ADR、敏感点无监测、适配度函数未进入门禁、验证证据缺失或质量属性总账未进入 release gate 仍晋级 |\n| 架构原则、约束、反模式与例外执行 | `baseline-architecture-principle-constraint-exception-ledger.yaml` 必须声明原则、owner、适用范围、约束规则、禁止项、反模式、检测方式、门禁入口、违反处置、例外、风险接受、ADR 和复核周期 | 原则无 owner、约束不可检测、禁止项未进入门禁、违反无处置、例外过期、风险接受缺失或原则总账未进入 release gate 仍晋级 |\n| 漏洞、暴露面与修复验证 | `baseline-vulnerability-exposure-remediation-ledger.yaml` 必须声明资产、镜像、依赖、基础镜像、IaC、Kubernetes、云配置、API、AI 工具、外部暴露、CVE/KEV/EPSS/CVSS、VEX/CSAF、owner、SLA、修复、复测、例外和发布准入 | critical/KEV 未关闭、互联网暴露 high 未关闭、扫描覆盖缺口、漏洞 owner 缺失、SLA 超期、修复未复测、例外过期、VEX/CSAF 状态缺失或未进入 release gate 仍晋级 |\n| 容量、性能、弹性伸缩与成本效率 | `baseline-capacity-performance-cost-efficiency-ledger.yaml` 必须声明关键服务、关键用户旅程、容量预测、压测窗口、性能基准、资源 requests/limits、HPA/VPA/KEDA、队列和数据库容量、预算、单位经济、成本分摊、异常成本和优化行动 | 关键服务无容量模型、压测过期、p95/p99 退化、资源未声明、自动扩缩容缺失、队列积压不可解释、数据库容量不足、预算超支无审批、单位成本不可解释或成本异常未关闭仍晋级 |\n| 服务可靠性、SLO、错误预算与可观测性 | `baseline-service-reliability-slo-error-budget-observability-ledger.yaml` 必须声明生产服务、用户旅程、SLI/SLO、错误预算、告警规则、on-call、runbook、指标/日志/链路覆盖、合成探测、降级策略和 owner | 关键服务无 SLO、SLI 不可测、错误预算超支仍放行风险变更、关键告警无人接、runbook 缺失、合成探测未覆盖用户旅程、日志/指标/链路缺口或仪表盘不可用仍晋级 |\n| 备份、恢复、灾备与可恢复性验证 | `baseline-backup-restore-disaster-recovery-ledger.yaml` 必须声明关键资产、数据存储、备份策略、不可变/离线副本、跨区域/跨账号隔离、RTO/RPO、恢复演练、完整性校验、恢复权限、勒索隔离和 owner | 关键资产无备份、无不可变或离线副本、恢复演练超期、RTO/RPO 失败、备份完整性失败、恢复权限不受控、勒索隔离不可证明或备份与资产分级不一致仍放行 |\n| 监管与合规义务可追溯 | `baseline-regulatory-obligation-ledger.yaml` 必须声明义务来源、版本、司法辖区、适用范围、控制目标、映射控制项、证据路径、owner、例外、POA&M、监管变更和生效期限 | 控制项无法证明覆盖哪些适用义务、强制义务无 owner、监管变更未进入门禁、客户合同义务未映射、过期整改仍可晋级 |\n| 密码材料、密钥、证书与秘密生命周期 | `baseline-cryptographic-secrets-key-certificate-ledger.yaml` 必须声明 KMS/HSM key、TLS 证书、签名密钥、API token、数据库凭据、webhook secret、工作负载密钥、owner、托管位置、算法、强度、轮换、过期、吊销、泄露响应和访问边界 | 密码材料未知、无 owner、明文存放、弱算法、证书过期、轮换超期、吊销路径缺失、泄露未关闭、签名密钥托管不清或 Secret 与运行资产无法绑定仍放行 |\n| 资产关键性、数据分类与风险分级 | `baseline-asset-criticality-classification-ledger.yaml` 必须声明资产清单、owner、业务关键性、SLO Tier、L3/L4 合规等级、CIA 影响、数据敏感度、监管暴露、AI 风险等级、互联网暴露、第三方关键性和复核状态 | catalog、CMDB、数据目录或 conformance profile 存在但资产无 owner、数据分类未知、CIA 影响缺失、关键资产低估、风险等级漂移或分级复核过期仍放行 |\n| 身份权限、特权访问与工作负载身份 | `baseline-identity-entitlement-access-ledger.yaml` 必须声明人类身份、服务账号、工作负载身份、角色授权、JML 生命周期、MFA、PAM/JIT、break-glass、最小权限、访问复核、孤儿账号、过期权限和运行时身份绑定 | 访问复核报告存在但生产 ServiceAccount、Cloud IAM、PAM/JIT、break-glass、JML、Kubernetes RBAC 或工作负载身份漂移仍放行 |\n| 处理活动、个人数据清单与 RoPA 覆盖 | `baseline-processing-activity-inventory-ledger.yaml` 必须声明处理活动、系统/数据产品/AI 产品、数据主体类别、个人数据类别、控制者/处理者角色、接收方、跨境传输、保留映射、合法基础、DPIA、发现覆盖和 owner 状态 | DSAR、同意、删除、驻留或第三方台账各自成立，但处理活动未入账、个人数据类别未知、无 owner、发现扫描有未归类 PII 或 RoPA 与运行资产不一致仍放行 |\n| 隐私权利、同意偏好与合法基础执行 | `baseline-privacy-rights-consent-ledger.yaml` 必须声明处理目的、合法基础、同意版本、撤回传播、主体权利请求、自动化决策复核、下游处理限制、第三方传播和 SLA 状态 | DPIA 写过但处理目的无合法基础、同意撤回未传播到营销/AI/数据产品/第三方、DSAR 逾期、自动化决策缺人工复核或未知同意状态仍放行 |\n| 记录留存、法律保全与可防御删除 | `baseline-records-retention-legal-hold-ledger.yaml` 必须声明记录类别、留存排期、义务来源、司法辖区、legal hold、删除资格、删除传播、备份/日志/向量索引处置和删除回执 | 记录类别无留存排期、legal hold 下允许删除、隐私删除请求与监管留存冲突无裁决、过期记录未处置、超期留存无目的、删除传播无回执或 AI/审计日志缺留存策略 |\n| 发布列车 | `baseline-release-train.yaml` 必须绑定候选窗口、冻结窗口、晋级日期、通知节奏、黑窗、紧急补丁和依赖证据 | 临时发版、绕过冻结窗口、无通知升级、黑窗期间发布非紧急变更 |\n| 通知确认 | `baseline-notification-ledger.yaml` 必须绑定通知对象、渠道、送达、确认、异议、例外和冻结前完成状态 | 冻结前关键消费者未确认、通知失败无补发、异议未关闭或无风险接受 |\n| 回滚验证 | `baseline-rollback-verification.yaml` 必须绑定上一基线、回滚目标、Git/tag/GitOps revision、审计导出恢复、烟测结果和验证时效 | 只写回滚计划、上一基线不可检出、GitOps revision 不存在、审计导出无法恢复或验证过期 |\n| 例外总账 | `baseline-exception-ledger.yaml` 必须聚合兼容、采纳、支持、通知、回滚、门禁和控制面的例外、到期日、风险接受、POA&M 和阻断状态 | 例外散落各处、例外过期仍放行、阻断例外无 owner、风险接受缺失或冻结前未关闭 |\n| 就绪评分 | `baseline-readiness-scorecard.yaml` 必须绑定评分维度、权重、硬门禁、证据路径、阻断项、baseline/frozen 最低分和最终判定 | 局部证据都存在但无人能判断是否可晋级、评分覆盖缺失、硬门禁失败仍被平均分掩盖 |\n| 符合性声明 | `baseline-conformance-claim.yaml` 必须绑定资产、声明基线、证据路径、签署人、例外、到期复核和采纳总账回写 | 中央台账手填、资产实际未声明基线、声明过期仍被采纳总账计为已采用 |\n| 兼容窗口 | `Minor` / `Major` / `Breaking` 必须声明兼容窗口、迁移截止和消费者影响 | breaking change 无迁移窗口或消费者确认 |\n| 冻结策略 | `Frozen` 基线只能通过补丁、紧急修复或下一基线替代 | 直接修改冻结基线核心内容 |\n| 回滚入口 | 每个基线必须能回滚到上一基线、上一 tag 或上一 GitOps revision | 无回滚 commit、无回滚说明或回滚证据过期 |\n| 外部标准 | 外部标准必须绑定版本、稳定性和采纳等级 | 引用 `latest` 或实验标准直接阻断生产 |\n\n发布通道分为七类：\n\n| 通道 | 用途 | 可进入生产 | 典型证据 |\n| ---- | ---- | ---------- | -------- |\n| `draft` | 设计草案和方案探索 | 否 | 草案记录、待决问题 |\n| `candidate` | 评审候选和试点准备 | 仅低风险试点 | 评审意见、控制差距、试点范围 |\n| `baseline` | 已批准的执行基线 | 是 | tag、版本清单、门禁结果、签署记录 |\n| `frozen` | 审计、招标、监管或大规模推广口径 | 是 | 冻结声明、审计导出、例外清单 |\n| `superseded` | 已被新基线替代的迁移期旧基线 | 仅存量迁移期 | 支持矩阵、迁移计划、采纳总账 |\n| `eol` | 已停止支持并完成退役的旧基线 | 否 | EOL 退役证书、审计归档、新采用阻断 |\n| `emergency-patch` | 安全、合规或生产事故紧急修复 | 受控允许 | 事故编号、补丁范围、事后复盘 |\n\n版本提升门禁：\n\n1. `Editorial` 只能修正文案、链接和格式，不能改变任何执行含义。\n2. `Minor` 必须证明向后兼容，且不得改变目录真相源、owner、风险等级或发布准入。\n3. `Major` 必须有 ADR、影响分析、迁移窗口、示例更新和控制项覆盖更新。\n4. `Breaking` 必须有消费者清单、弃用策略、并行运行窗口、回滚路径和风险接受记录。\n5. 任意版本提升都必须能通过 `make sync-doc-toc`、`make test` 和 `git diff --check`。\n6. 任意生产基线都必须能从 `version-governance.yaml` 追溯到版本清单、控制项覆盖、标准基线、审计导出和门禁决策。\n\n禁止事项：\n\n1. 禁止同一版本号复用到不同内容。\n2. 禁止发布未打 tag、tag 漂移或 tag 与文档版本不一致的基线。\n3. 禁止只改主文档版本号，不同步索引、版本清单、控制覆盖和审计导出范围。\n4. 禁止以“兼容”名义偷偷改变契约语义、owner、证据字段或生产准入规则。\n5. 禁止把 emergency patch 当作常规发布通道长期使用。\n\n### 0.7 版本记录\n\n| 版本 | 日期 | 变更级别 | 关键变化 |\n| ---- | ---- | -------- | -------- |\n| `V1.0` | 2026-06-01 | Major | 建立现代企业数字化平台基础蓝图，替代传统“大中台、小前台”叙事 |\n| `V1.1` | 2026-06-01 | Major | 补齐 AI 原生能力层、供应链安全、数据产品到 AI 的联动、Lakehouse 过渡和认知负载治理 |\n| `V1.2` | 2026-06-01 | Minor | 增加行业对标矩阵、Agent 协议边界和深度调研结论 |\n| `V1.3` | 2026-06-01 | Major | 增加 AI 风险分级、AI 资产证据链、SSDF 安全开发、数据契约和 FinOps 成本治理 |\n| `V1.4` | 2026-06-01 | Major | 增加微调治理、AI 事件响应和 Policy as Code 策略语言统一 |\n| `V1.5` | 2026-06-01 | Major | 增加微服务容器、镜像、Kubernetes、GitOps、catalog 和平台能力的分层真相源 |\n| `V1.6` | 2026-06-01 | Major | 增加文档版本治理、发布状态、变更分级、冻结规则、发布证据和 V2.0 路线图 |\n| `V1.7` | 2026-06-01 | Major | 增加真相源字段矩阵、starter kit 模板骨架、自动化门禁映射和漂移检测规则 |\n| `V1.8` | 2026-06-01 | Major | 增加 RACI 决策权矩阵、可靠性分级、RTO/RPO、错误预算、灾备演练和升级路径 |\n| `V1.9` | 2026-06-01 | Major | 增加仓库拓扑剖面、迁移与弃用策略、验证包和审计证据清单 |\n| `V2.0` | 2026-06-01 | Major | 新增可执行 starter kit、JSON Schema、YAML 示例和自动化校验入口 |\n| `V2.1` | 2026-06-01 | Minor | 增强 starter kit schema 嵌套约束、格式校验、跨文件一致性检查和 CI 门禁口径 |\n| `V2.2` | 2026-06-01 | Minor | 补齐 API、事件、AI 工具、RAG、微调、GitOps、catalog 和 scorecard 契约模板 |\n| `V2.3` | 2026-06-01 | Minor | 补齐发布证据、供应链证明、治理例外、API/Event 兼容性报告和 GitOps 漂移报告契约模板 |\n| `V2.4` | 2026-06-01 | Minor | 增加机器可读版本清单、starter kit pair 清单和版本同步校验规则 |\n| `V2.5` | 2026-06-02 | Minor | 加固可靠性、数据治理、AI 运行、GitOps 安全和供应链门禁字段 |\n| `V2.6` | 2026-06-02 | Minor | 新增机器可读控制项覆盖清单，校验控制项到 schema、example 和 checker 的证据链 |\n| `V2.7` | 2026-06-02 | Minor | 启用 starter kit 严格 schema 模式，要求 `additionalProperties=false` 并阻断未知字段通过门禁 |\n| `V2.8` | 2026-06-02 | Minor | 补齐扩展字段策略、Feature Flag / Kill Switch、AI 威胁模型、运行血缘和平台产品指标控制项 |\n| `V2.9` | 2026-06-02 | Minor | 补齐隐私影响评估、租户隔离、恢复演练、策略测试、GenAI 观测和成本分摊证据 |\n| `V2.10` | 2026-06-02 | Minor | 补齐访问复核、密钥轮换、漏洞修复、事故复盘和证据新鲜度控制项 |\n| `V2.11` | 2026-06-02 | Minor | 补齐控制证据映射和审计导出清单 |\n| `V2.12` | 2026-06-02 | Minor | 补齐审计导出自动化命令 |\n| `V2.13` | 2026-06-02 | Minor | 补齐控制评估报告和审计签署闭环 |\n| `V2.14` | 2026-06-02 | Minor | 补齐架构基线变更记录和回滚证明 |\n| `V2.15` | 2026-06-02 | Minor | 补齐 OSCAL 交换映射和导出摘要 |\n| `V2.16` | 2026-06-02 | Minor | 补齐审计导出门禁和输出不变量校验 |\n| `V2.17` | 2026-06-02 | Minor | 补齐审计导出完整性清单和生成物哈希校验 |\n| `V2.18` | 2026-06-02 | Minor | 补齐审计导出 provenance statement 和生成上下文追溯 |\n| `V2.19` | 2026-06-02 | Minor | 补齐审计导出签名策略和 provenance payload 签名交接 |\n| `V2.20` | 2026-06-02 | Minor | 补齐审计导出签名验签回执和外部签名证据闭环 |\n| `V2.21` | 2026-06-02 | Minor | 补齐 POA&M 整改计划和 OSCAL 整改视图证据闭环 |\n| `V2.22` | 2026-06-02 | Minor | 补齐企业架构风险登记和风险到控制、POA&M、审计导出的证据闭环 |\n| `V2.23` | 2026-06-02 | Minor | 补齐机器可读架构决策记录和基线变更 ADR 绑定 |\n| `V2.24` | 2026-06-02 | Minor | 补齐机器可读 AI 事件响应 playbook 和 AI 运行证据闭环 |\n| `V2.25` | 2026-06-02 | Minor | 补齐机器可读 AI 证据账本和 AI 产品级证据闭环 |\n| `V2.26` | 2026-06-02 | Minor | 补齐机器可读微调运行证据和 AI 微调审计闭环 |\n| `V2.27` | 2026-06-02 | Minor | 补齐机器可读仓库变更控制、远端保护验证和版本基线保护 |\n| `V2.28` | 2026-06-02 | Minor | 补齐企业执行控制面、合规等级、门禁决策、例外放行和季度复核闭环 |\n| `V2.29` | 2026-06-02 | Minor | 补齐外部标准版本锁定、稳定性分级、采纳等级和升级门禁 |\n| `V2.30` | 2026-06-02 | Minor | 补齐版本控制面、发布通道、版本不变量、兼容窗口、冻结升级和回滚门禁 |\n| `V2.31` | 2026-06-02 | Minor | 补齐基线发布证据包、版本晋级、冻结复核、漂移检查和回滚验证闭环 |\n| `V2.32` | 2026-06-02 | Minor | 补齐基线兼容性总账、消费者影响、迁移窗口、弃用截止和未迁移风险闭环 |\n| `V2.33` | 2026-06-02 | Minor | 补齐基线采纳总账、组织采纳状态、逾期治理、例外和整改闭环 |\n| `V2.34` | 2026-06-02 | Minor | 补齐基线支持矩阵、维护窗口、安全补丁、EOL、冻结口径和最低可接受基线 |\n| `V2.35` | 2026-06-02 | Minor | 补齐基线发布列车、候选窗口、冻结窗口、晋级日期、通知节奏、黑窗和紧急补丁入口 |\n| `V2.36` | 2026-06-02 | Minor | 补齐资产级基线符合性声明、资产自声明、证据绑定、例外、复核和采纳总账回写 |\n| `V2.37` | 2026-06-02 | Minor | 补齐基线制品清单、源制品摘要、必需性、签名状态、导出关系和未登记制品阻断 |\n| `V2.38` | 2026-06-02 | Minor | 补齐基线验证环境锁定、命令版本、runner 镜像、策略包、validator、验签工具和可复现门禁 |\n| `V2.39` | 2026-06-02 | Minor | 补齐基线通知确认总账、通知对象、送达回执、影响确认、异议、例外和冻结前完成状态 |\n| `V2.40` | 2026-06-02 | Minor | 补齐基线回滚验证记录、上一基线检出、GitOps revision 恢复、审计导出恢复和烟测证据 |\n| `V2.41` | 2026-06-02 | Minor | 补齐基线例外总账、例外来源聚合、风险接受、POA&M、过期阻断和冻结准入 |\n| `V2.42` | 2026-06-02 | Minor | 补齐基线就绪评分卡、硬门禁、评分维度、证据绑定和 baseline/frozen 最终判定 |\n| `V2.43` | 2026-06-02 | Minor | 补齐基线生命周期状态机、允许迁移、禁止迁移、状态回写和迁移审计证据 |\n| `V2.44` | 2026-06-02 | Minor | 补齐基线状态对账报告、跨账本状态一致性、状态漂移阻断和审计导出状态回写 |\n| `V2.45` | 2026-06-02 | Minor | 补齐基线 EOL 退役证书、生产引用清零、迁移关闭、例外清零和新采用阻断 |\n| `V2.46` | 2026-06-02 | Minor | 补齐基线会审裁决记录、证据核验、投票签署、反对意见、条件动作和最终裁决 |\n| `V2.47` | 2026-06-02 | Minor | 补齐基线证据追踪图、跨证据依赖、摘要一致性、下游消费和断链阻断 |\n| `V2.48` | 2026-06-02 | Minor | 补齐基线门禁执行报告、门禁命令、策略包、输入摘要、逐条规则结果、退出码和可重放执行证明 |\n| `V2.49` | 2026-06-02 | Minor | 补齐基线发布事务回执、提交前检查、签名 tag、远端 ref、push 回执、保护规则和发布后验证 |\n| `V2.50` | 2026-06-02 | Minor | 补齐基线撤销与隔离记录、撤销触发、隔离范围、恢复目标、通知确认、风险接受和审计归档 |\n| `V2.51` | 2026-06-02 | Minor | 补齐基线准入执行策略、最低基线阻断、撤销/EOL 阻断、资产声明校验和例外到期阻断 |\n| `V2.52` | 2026-06-02 | Minor | 补齐基线消费锁定文件、不可变摘要锁定、浮动版本阻断和消费端回写闭环 |\n| `V2.53` | 2026-06-02 | Minor | 补齐基线迁移工作单、逐资产迁移步骤、消费锁更新、GitOps 变更、验收证据和回滚动作 |\n| `V2.54` | 2026-06-02 | Minor | 补齐基线迁移执行回执、实际命令、before/after 摘要、GitOps revision、验收日志和回滚验证 |\n| `V2.55` | 2026-06-02 | Minor | 补齐本地私有制品边界、禁推资产分类、摘要留存、远端排除和验证命令 |\n| `V2.56` | 2026-06-02 | Minor | 补齐审计导出排除清单、原文白名单、摘要留存、签名 payload 排除和导出后验证命令 |\n| `V2.57` | 2026-06-02 | Minor | 补齐私有制品托管交接清单、私有 registry 引用、访问控制、留存期限、取回命令和恢复验证 |\n| `V2.58` | 2026-06-02 | Minor | 补齐干净环境基线重建回执、远端 checkout、私有制品取回、审计导出重建和门禁重放 |\n| `V2.59` | 2026-06-02 | Minor | 补齐基线证据不可变归档回执、WORM 留存、legal hold、访问日志和恢复演练 |\n| `V2.60` | 2026-06-02 | Minor | 补齐基线长期验签回执、证书链、透明日志、signed entry timestamp、RFC3161 TSA 和长期验证材料 |\n| `V2.61` | 2026-06-02 | Minor | 补齐基线运行时准入回执、Kubernetes admission、策略引擎、镜像证明和运行入口阻断证据 |\n| `V2.62` | 2026-06-02 | Minor | 补齐基线运行时准入决策总账、Kubernetes audit、策略引擎决策日志和逐条 allow/deny 证据 |\n| `V2.63` | 2026-06-02 | Minor | 补齐基线连续控制监测总账、运行指标、告警规则、漂移事件、处置工单和证据新鲜度 |\n| `V2.64` | 2026-06-02 | Minor | 补齐基线独立控制保证抽样总账、控制总体、抽样计划、设计有效性、运行有效性、发现项和 OSCAL Assessment Results |\n| `V2.65` | 2026-06-02 | Minor | 补齐基线共享责任与继承控制总账、继承控制、共享责任、消费者义务、失效条件和审计映射 |\n| `V2.66` | 2026-06-02 | Minor | 补齐基线数据驻留与跨境处理总账、处理位置、传输机制、子处理方、补充保护措施和区域漂移阻断 |\n| `V2.67` | 2026-06-02 | Minor | 补齐基线第三方与关键供应商风险总账、供应商分级、合同控制、审计权、保证报告、集中度、退出计划和连续性阻断 |\n| `V2.68` | 2026-06-02 | Minor | 补齐基线运营韧性与重要业务服务影响容忍总账、BIA、端到端依赖、场景测试、恢复能力、沟通计划和超限升级阻断 |\n| `V2.69` | 2026-06-02 | Minor | 补齐基线监管与合规义务可追溯总账、义务源、适用范围、控制映射、证据映射、监管变更、例外和 POA&M 阻断 |\n| `V2.70` | 2026-06-02 | Minor | 补齐基线记录留存、法律保全与可防御删除总账、留存排期、legal hold、删除资格、删除传播、备份/日志/向量索引处置和可防御删除回执 |\n| `V2.71` | 2026-06-02 | Minor | 补齐基线隐私权利请求、同意偏好与合法基础执行总账、处理目的、合法基础、同意撤回、偏好传播、DSAR SLA、自动化决策复核和下游处理阻断 |\n| `V2.72` | 2026-06-02 | Minor | 补齐基线处理活动、个人数据清单与 RoPA 覆盖总账、处理活动发现、数据主体、个人数据类别、接收方、角色、DPIA、合法基础、保留和跨境映射 |\n| `V2.73` | 2026-06-02 | Minor | 补齐基线身份权限、特权访问与工作负载身份总账、JML、MFA、PAM/JIT、break-glass、服务账号、工作负载身份、孤儿权限和过期权限阻断 |\n| `V2.74` | 2026-06-02 | Minor | 补齐基线资产关键性、数据分类与风险分级总账、资产 owner、业务关键性、SLO Tier、L3/L4、CIA 影响、数据敏感度、AI 风险、互联网暴露和分级漂移阻断 |\n| `V2.75` | 2026-06-02 | Minor | 补齐基线密码材料、密钥、证书与秘密生命周期总账、KMS/HSM、TLS 证书、签名密钥、API token、凭据、轮换、过期、吊销和泄露响应阻断 |\n| `V2.76` | 2026-06-02 | Minor | 补齐基线备份、恢复、灾备与可恢复性验证总账、关键数据存储备份、不可变/离线副本、跨区域隔离、恢复演练、RTO/RPO、完整性校验和勒索隔离阻断 |\n| `V2.77` | 2026-06-02 | Minor | 补齐基线服务可靠性、SLO、错误预算与可观测性总账、SLI/SLO、错误预算、告警、on-call、runbook、合成探测、日志/指标/链路覆盖和用户旅程可靠性阻断 |\n| `V2.78` | 2026-06-02 | Minor | 补齐基线容量、性能、弹性伸缩与成本效率总账、容量预测、压测、性能基准、资源 requests/limits、HPA/VPA/KEDA、预算、单位经济和成本异常阻断 |\n| `V2.79` | 2026-06-02 | Minor | 补齐基线威胁建模、攻击面与安全风险总账、信任边界、数据流、滥用场景、安全测试、剩余风险和 release gate 阻断 |\n| `V2.80` | 2026-06-02 | Minor | 补齐基线漏洞、暴露面与修复验证总账、CVE/KEV/EPSS/CVSS、VEX/CSAF、外部暴露、修复 SLA、复测、例外和 release gate 阻断 |\n| `V2.81` | 2026-06-02 | Minor | 补齐基线安全配置、加固姿态与配置漂移修复总账、CIS/NIST/SCAP、Kubernetes Pod Security、云/Kubernetes/OS/数据库/CI/CD 配置、漂移、修复、例外和 release gate 阻断 |\n| `V2.82` | 2026-06-03 | Minor | 补齐基线生产变更、发布编排、变更冲突与失败恢复总账、代码部署、GitOps、数据库迁移、配置、Feature Flag、Prompt/模型变更、紧急变更、黑窗、冲突检测、回滚和 DORA 指标闭环 |\n| `V2.83` | 2026-06-03 | Minor | 补齐基线事故、问题、纠正行动与复发防止总账、生产事故、安全事件、隐私事件、AI 事件、供应商事件、near miss、RCA、纠正行动、runbook 反哺和 DORA 恢复指标闭环 |\n| `V2.84` | 2026-06-03 | Minor | 补齐基线数据产品质量、契约违约、运行血缘与可观测性总账、schema drift、质量断言、freshness、完整性、唯一性、下游消费者影响、AI/特征/RAG 使用、契约违约和修复闭环 |\n| `V2.85` | 2026-06-03 | Minor | 补齐基线工程质量、测试证据、缺陷与发布验证总账、需求追踪、单元/集成/契约/E2E/回归/验收测试、覆盖率、flaky 测试、缺陷分级、修复复测、发布前验证和质量风险接受闭环 |\n| `V2.86` | 2026-06-03 | Minor | 补齐基线人员能力、培训、职责履职与职责分离总账、关键角色任命、岗位资格、职责确认、专项培训、on-call 资格、审批授权、职责分离、冲突角色和代理授权闭环 |\n| `V2.87` | 2026-06-03 | Minor | 补齐基线业务结果、价值实现与组合收益总账、业务目标、价值假设、收益 owner、投资组合、关键结果、前后基线、采用证据、收益实现、成本效率和停投/加投决策闭环 |\n| `V2.88` | 2026-06-03 | Minor | 补齐基线价值流、关键旅程与端到端流程总账、BPMN/流程模型、流程 owner、跨域交接、步骤级遥测、瓶颈、异常、人工兜底和改进动作闭环 |\n| `V2.89` | 2026-06-03 | Minor | 补齐基线架构视图、运行拓扑与依赖影响总账、架构视图、C4/部署视图、运行拓扑、声明依赖、观测依赖、blast radius、变更影响和依赖漂移闭环 |\n| `V2.90` | 2026-06-03 | Minor | 补齐基线质量属性、架构驱动与权衡决策总账、质量属性场景、业务驱动、敏感点、权衡点、ADR、适配度函数、验证证据和复核闭环 |\n| `V2.91` | 2026-06-03 | Minor | 补齐基线架构原则、约束、反模式与例外执行总账、原则 owner、适用范围、禁止项、检测方式、门禁入口、违反处置、例外、风险接受和复核闭环 |\n| `V2.92` | 2026-06-03 | Minor | 补齐基线版本策略、发布通道、兼容性与冻结控制总账、SemVer 语义、Conventional Commit 分类、签名 tag、兼容窗口、紧急补丁、撤销隔离、消费锁和迁移窗口闭环 |\n| `V2.93` | 2026-06-03 | Patch | 补齐控制项覆盖清单的 V2.69 至 V2.92 增量追溯，明确最新版本策略控制已进入 schema、example 和 checker 覆盖口径 |\n| `V2.94` | 2026-06-03 | Patch | 收敛公开文档与本地私有可执行资产边界表达，用受控私有制品引用和企业内部命令 URI 替代裸占位符 |\n| `V2.95` | 2026-06-03 | Minor | 补齐证据保证等级与采信规则，明确 release gate、会审裁决和审计导出必须按证据来源、独立性、完整性、新鲜度和可重放性判断证据是否可采信 |\n| `V2.96` | 2026-06-03 | Minor | 将证据保证等级补线到基线晋级矩阵、制品清单、starter gate、会审裁决、审计导出和基线状态迁移阻断路径 |\n| `V2.97` | 2026-06-03 | Minor | 补齐基线门禁负例测试与故障注入总账，证明 release gate、starter gate、审计导出、运行时准入和状态迁移能稳定拒绝坏样例 |\n| `V2.98` | 2026-06-03 | Minor | 补齐 AI 系统监管分类与影响评估总账，绑定适用法规、风险等级、人工监督、日志留存、技术文档、透明度、后市场监测和合规缺口闭环 |\n\n### 0.8 V2.98 可执行企业标准路线图\n\nV2.0 已将 V1.9 的文档化基线转化为第一批可执行资产。V2.1 继续把字段约束、示例一致性和远程 CI 门禁补强为可执行口径。V2.2 把主文档最小验证包中的 API、事件、AI 工具、RAG、微调、GitOps、catalog 和 scorecard 纳入 schema/example 校验。V2.3 继续把发布证据、供应链证明、治理例外、兼容性报告和 GitOps 漂移报告纳入机器可校验基线。V2.4 把当前版本、发布状态、starter kit pair 清单、pair 数量和索引同步要求固化到机器可读版本清单中。V2.5 把可靠性等级、RTO/RPO、数据保留与访问审计、AI 预算与降级、GitOps 运行安全和供应链 source/vulnerability/scorecard 证据提升为 starter kit 强制字段。V2.6 增加控制项覆盖清单，把关键企业控制要求映射到 schema 字段、example 和 checker 规则，避免“文档说有控制、机器无法证明控制存在”。V2.7 启用严格 schema 模式，要求 starter kit 所有对象节点声明 `additionalProperties=false`，并由 checker 阻断未知字段。V2.8 补齐扩展字段策略、Feature Flag / Kill Switch、AI 威胁模型、运行血缘和平台产品指标。V2.9 继续把隐私工程、租户边界、恢复演练、Policy as Code 测试、GenAI 可观测性和 FinOps 成本分摊补成可执行证据。V2.10 把访问复核、密钥轮换、漏洞修复、事故复盘和证据新鲜度纳入控制目录，避免生产安全运营只停留在“有制度、有人看、事后补”的弱证据状态。V2.11 把每个控制项到证据路径、状态、新鲜度和审计导出包的关系纳入总账，避免审计时只能逐段翻文档、不能一键证明控制覆盖。V2.12 增加审计导出自动化命令，把版本、控制目录、证据映射、导出清单、脚本和关键制品哈希生成可交付审计包。V2.13 增加控制评估报告，把证据包进一步闭环到控制结果、发现项、整改、剩余风险和签署状态。V2.14 增加架构基线变更记录，把基线升级的影响分析、审批、验证命令和回滚路径纳入可执行证据。V2.15 增加 OSCAL 交换映射和导出摘要，把内部控制证据映射到 catalog、component-definition、system-security-plan、assessment-results 和 POA&M 视图。V2.16 增加审计导出门禁，把导出包生成、JSON/Markdown/OSCAL 输出和关键不变量校验纳入 `make test`。V2.17 增加审计导出完整性清单，把生成物 SHA-256、源制品哈希和防篡改校验纳入审计包。V2.18 增加审计导出 provenance statement，把生成物 subject、构建定义、源码提交和源证据依赖纳入可追溯证明。V2.19 增加审计导出签名策略，把 provenance payload 摘要、签名方式、验签命令和外部签名交接纳入门禁。V2.20 增加审计导出签名验签回执，把外部签名完成后的 bundle 摘要、证书身份、OIDC issuer、透明日志和验签结果纳入证据链。V2.21 增加 POA&M 整改计划，把控制发现项、责任人、整改行动、里程碑、证据、签署和 OSCAL POA&M 输出纳入闭环。V2.22 增加企业架构风险登记，把风险、控制项、POA&M、缓解行动、残余风险、复审和审计导出风险视图纳入闭环。V2.23 增加架构决策记录，把 ADR 上下文、备选方案、取舍、决策、关联控制项、风险、POA&M、复审和基线变更绑定纳入闭环。V2.24 增加 AI 事件响应 playbook，把幻觉爆发、工具循环、RAG 索引污染、供应商中断、成本异常、检测、遏制、降级、回滚和复盘纳入闭环。V2.25 增加 AI 证据账本，把模型、Prompt、RAG、工具、评估、威胁模型、观测、事件响应、数据使用、审批、留存和复审纳入 AI 产品级证据闭环。V2.26 增加微调运行证据，把训练数据授权、数据准备、实验追踪、评估、模型登记、审批、灰度发布、监控和退役纳入 AI 微调审计闭环。V2.27 增加仓库变更控制，把 CODEOWNERS、受保护分支、PR 审查、必需检查、签名提交、禁止直推、发布 tag 保护、远端保护状态验证、漂移整改、POA&M 和风险登记纳入版本基线保护。V2.28 增加企业执行控制面，把合规等级、门禁决策、证据新鲜度、例外放行、break-glass、季度复核和退出标准变成统一执行协议。V2.29 增加外部标准版本锁定与升级策略，避免把未稳定标准、实验性语义约定或外部规范变更直接带入生产基线。V2.30 增加版本控制面，把基线 ID、发布通道、tag、源 commit、兼容窗口、冻结策略和回滚入口固化为发布不变量。V2.31 增加基线发布证据包，把晋级决策、冻结复核、漂移检查、不可变引用、审计摘要和回滚验证固化为发布证据。V2.32 增加基线兼容性总账，把消费者影响、迁移窗口、弃用截止、例外状态和未迁移风险固化为版本门禁证据。V2.33 增加基线采纳总账，把领域、平台、数据、AI 和生产资产对基线的采用状态、逾期治理和例外整改固化为组织级版本证据。V2.34 增加基线支持矩阵，把旧基线支持状态、维护窗口、安全补丁窗口、EOL 和最低可接受基线固化为版本生命周期门禁。V2.35 增加基线发布列车，把候选窗口、冻结窗口、晋级日期、通知节奏、黑窗和紧急补丁入口固化为版本发布节奏门禁。V2.36 增加资产级基线符合性声明，把资产自声明、证据绑定、例外、复核和采纳总账回写固化为资产级版本证据。V2.37 增加基线制品清单，把源文档、schema、示例、控制项、证据模板、脚本、生成物和外部引用固化为可摘要、可签名、可复现的版本物料清单。V2.38 增加基线验证环境锁定，把校验命令、工具版本、runner 镜像、策略包、schema validator 和验签工具固化为可复现门禁。V2.39 增加基线通知确认总账，把发布列车中的通知计划升级为可审计的送达、确认、异议和例外证据。V2.40 增加基线回滚验证记录，把上一基线检出、GitOps revision 恢复、审计导出恢复和烟测结果升级为独立证据。V2.41 增加基线例外总账，把分散例外、到期、风险接受、POA&M 和冻结阻断收敛为统一审计证据。V2.42 增加基线就绪评分卡，把硬门禁、评分维度、证据摘要和 baseline/frozen 判定统一到最终准入证据。V2.43 增加基线生命周期状态机，把允许迁移、禁止迁移、状态回写、迁移审批和回滚入口统一到状态转换证据。V2.44 增加基线状态对账报告，把状态机、版本控制面、发布证据、支持矩阵、采纳总账和审计导出的状态字段统一对账。V2.45 增加基线 EOL 退役证书，把旧基线生产引用清零、迁移关闭、例外清零、审计归档和新采用阻断固化为退役证据。V2.46 增加基线会审裁决记录，把会审范围、证据核验、投票签署、反对意见、条件动作和最终裁决固化为独立会审证据。V2.47 增加基线证据追踪图，把跨证据依赖、摘要一致性、下游消费和断链阻断固化为可校验证据图。V2.48 增加基线门禁执行报告，把执行命令、策略包、输入摘要、规则结果、退出码和重放证明固化为 release gate 的可审计运行证据。V2.49 增加基线发布事务回执，把提交、签名 tag、远端 ref、push 回执、保护规则和发布后验证固化为版本发布事实。V2.50 增加基线撤销与隔离记录，把坏基线的隔离、撤销、通知、恢复目标、风险接受和审计归档固化为版本事故控制证据。V2.51 增加基线准入执行策略，把最低基线、撤销/EOL、资产声明、例外到期和运行入口阻断固化为统一策略。V2.52 增加基线消费锁定文件，把资产消费端的基线版本、commit、tag 和关键证据摘要固化为不可变锁。V2.53 增加基线迁移工作单，把目标资产迁移到新基线的步骤、依赖、GitOps 变更、消费锁更新、验收证据和回滚动作固化为执行工单。V2.54 增加基线迁移执行回执，把实际命令、actor、before/after 摘要、GitOps revision、catalog/lock diff、验收日志和回滚验证固化为执行事实。V2.55 增加本地私有制品边界，把本地私有 starter kit、生成 JSON、校验脚本、禁推原因、摘要留存和远端排除固化为受控证据。V2.56 增加审计导出排除清单，把原文白名单、摘要留存项、强制排除项、签名 payload 排除和导出后验证固化为受控证据。V2.57 增加私有制品托管交接清单，把私有制品库引用、访问控制、留存期限、取回命令、恢复验证和摘要一致性固化为受控证据。V2.58 增加干净环境基线重建回执，把远端 checkout、私有制品取回、摘要校验、审计导出重建、门禁重放和禁推资产复核固化为受控证据。V2.59 增加基线证据不可变归档回执，把关键证据的 WORM 留存、legal hold、访问日志、防删除、归档摘要和恢复演练固化为受控证据。V2.60 增加基线长期验签回执，把签名 bundle、证书链、OIDC 身份、透明日志、signed entry timestamp、RFC3161 TSA、撤销状态和验证工具版本固化为长期验签证据。V2.61 增加基线运行时准入回执，把 Kubernetes admission、策略引擎、镜像 digest、签名、provenance、SBOM、消费锁和拒绝样例固化为生产运行入口证据。V2.62 增加基线运行时准入决策总账，把 Kubernetes audit、admission webhook、PolicyReport、OPA decision log、actor、requestUID、allow/deny 和原始日志摘要固化为逐条运行决策证据。V2.63 增加基线连续控制监测总账，把控制项指标、告警、漂移、处置、证据新鲜度和控制运行 SLO 固化为持续监测证据。后续 `V2.x` 迭代应继续补充示例仓库，并把平台、catalog、GitOps、runtime admission、audit logging、continuous control monitoring 和审计系统连接起来。\n\nV2.64 进一步增加基线独立控制保证抽样总账，把独立评估、控制总体、样本、设计有效性、运行有效性、发现项、整改和 OSCAL Assessment Results 固化为可复核证据。后续 `V2.x` 迭代应继续补充示例仓库，并把平台、catalog、GitOps、runtime admission、audit logging、continuous control monitoring、control assurance sampling 和审计系统连接起来。\n\nV2.65 进一步增加基线共享责任与继承控制总账，把平台公共控制、云/第三方继承控制、领域责任、消费者配置义务和继承失效条件固化为可复核证据，避免企业级平台控制在扩展到多个资产后出现 owner 漂移。\n\nV2.66 进一步增加基线数据驻留与跨境处理总账，把数据产品、AI 产品、RAG 索引、日志、备份、模型供应商、子处理方和人工支持访问的处理位置纳入同一证据链，避免只在隐私影响评估里写原则、却无法证明运行时数据实际落点。\n\nV2.67 进一步增加基线第三方与关键供应商风险总账，把云平台、SaaS、ICT 服务商、模型供应商、外包方、数据处理方和关键子处理方纳入统一风险证据，避免采购、法务、隐私、安全和架构各自有台账却无法证明关键依赖可审计、可降级、可退出。\n\nV2.68 进一步增加基线运营韧性与重要业务服务影响容忍总账，把重要业务服务、影响容忍、BIA、端到端依赖、严重但合理场景测试、恢复能力、人工替代、沟通计划和超限升级纳入统一证据，避免只按系统组件证明 RTO/RPO，却无法证明客户、市场、监管和关键业务结果仍处于可承受影响范围内。\n\nV2.69 进一步增加基线监管与合规义务可追溯总账，把法规条款、监管规则、行业标准、客户合同和内部政策要求纳入统一义务源，并逐条绑定控制项、证据、owner、例外、POA&M、监管变更监测和发布门禁，避免企业只能证明“执行了控制”，却不能证明“这些控制覆盖了哪些适用义务”。\n\nV2.70 进一步增加基线记录留存、法律保全与可防御删除总账，把企业记录类别、留存排期、法定义务、合同义务、legal hold、删除资格、删除传播、备份处置、日志处置、向量索引处置和可防御删除回执纳入统一证据，避免隐私删除、监管留存、审计取证和诉讼保全互相冲突时只能靠人工会议解释。\n\nV2.71 进一步增加基线隐私权利请求、同意偏好与合法基础执行总账，把处理目的、合法基础、同意版本、同意撤回、偏好传播、DSAR/消费者权利请求、自动化决策人工复核、AI/数据产品/营销/第三方下游限制和逾期阻断纳入统一证据，避免只有 DPIA 和留存策略，却无法证明当前处理仍被授权、撤回已经传播、权利请求已经按期履行。\n\nV2.72 进一步增加基线处理活动、个人数据清单与 RoPA 覆盖总账，把企业运行中的系统、数据产品、AI 产品、第三方处理和人工流程统一映射到处理活动、数据主体类别、个人数据类别、接收方、跨境传输、保留排期、合法基础、DPIA 和 owner，避免“下游权利与同意证据都存在，但源头处理活动覆盖不完整”。\n\nV2.73 进一步增加基线身份权限、特权访问与工作负载身份总账，把人类身份、服务账号、工作负载身份、JML、MFA、PAM/JIT、break-glass、最小权限、权限复核、孤儿账号、过期权限和运行时身份绑定纳入统一证据链，避免 IAM、PAM、RBAC、Cloud IAM、Kubernetes ServiceAccount 和访问复核各自存在，却无法证明生产权限与准入策略一致。\n\nV2.74 进一步增加基线资产关键性、数据分类与风险分级总账，把 catalog、CMDB、数据目录、AI 产品目录、风险登记、SLO 和 conformance profile 统一绑定到资产 owner、业务关键性、CIA 影响和门禁等级，避免系统已经登记却无法证明“为什么按这个保护强度放行或阻断”。\n\nV2.75 进一步增加基线密码材料、密钥、证书与秘密生命周期总账，把 KMS/HSM、Vault、TLS 证书、签名密钥、API token、数据库凭据、webhook secret、工作负载密钥、轮换、过期、吊销、泄露响应和 owner 统一绑定到基线门禁，避免密码材料散落在工具、配置和流水线里但无法证明生命周期受控。\n\nV2.76 进一步增加基线备份、恢复、灾备与可恢复性验证总账，把关键系统、关键数据存储、对象存储、配置仓库、队列、向量索引、审计证据、备份策略、不可变/离线副本、跨区域复制、恢复演练、RTO/RPO、完整性校验和勒索隔离统一绑定到基线门禁，避免灾备能力只停留在计划、任务配置或组件级恢复演练里。\n\nV2.77 进一步增加基线服务可靠性、SLO、错误预算与可观测性总账，把服务契约、用户旅程、SLI/SLO、错误预算、告警路由、on-call、runbook、合成探测、日志/指标/链路覆盖、降级策略和事故反馈统一绑定到基线门禁，避免服务可靠性停留在“有监控、有告警、有 SLO 字段”，却无法证明用户可见可靠性正在被持续运营。\n\nV2.78 进一步增加基线容量、性能、弹性伸缩与成本效率总账，把容量预测、压测、性能基准、资源 requests/limits、HPA/VPA/KEDA、队列积压、数据库容量、预算、单位经济、成本分摊、异常成本和优化行动统一绑定到基线门禁，避免性能容量治理停留在“上线前压过一次测、资源配置写过一次、账单月底再看”的弱运行证据状态。\n\nV2.79 进一步增加基线威胁建模、攻击面与安全风险总账，把关键服务、API、事件、数据产品、AI 产品、GitOps 入口、平台共享能力、信任边界、数据流、攻击面、滥用场景、安全测试、剩余风险、POA&M 和风险签署统一绑定到基线门禁，避免威胁建模停留在上线前评审或单个 AI 威胁模型里。\n\nV2.80 进一步增加基线漏洞、暴露面与修复验证总账，把 CVE、KEV、EPSS、CVSS、VEX/CSAF、SBOM/SCA、容器镜像、IaC、Kubernetes、云配置、外部暴露、API/AI 工具入口、修复 SLA、复测和例外统一绑定到基线门禁，避免漏洞治理停留在扫描器报告、局部工单或单项修复证明里。\n\nV2.81 进一步增加基线安全配置、加固姿态与配置漂移修复总账，把 CIS Benchmarks、NIST 安全配置管理、SCAP、Kubernetes Pod Security、云/Kubernetes/OS/数据库/CI/CD 配置、AI Runtime 配置、漂移修复和例外统一绑定到基线门禁，避免漏洞修复通过后仍因默认配置错误、弱加密、公共暴露、特权 Pod 或审计关闭进入生产。\n\nV2.82 进一步增加基线生产变更、发布编排、变更冲突与失败恢复总账，把代码部署、GitOps 同步、数据库迁移、配置、Feature Flag、Prompt/模型变更、紧急变更、黑窗、冲突检测、回滚、失败恢复、事故关联和 DORA 指标统一绑定到基线门禁，避免企业只证明“版本基线可发布”，却无法证明每一次真实生产变更可控、可回滚、可复盘、可度量。\n\nV2.83 进一步增加基线事故、问题、纠正行动与复发防止总账，把生产事故、安全事件、隐私事件、AI 事件、供应商事件、near miss、重大告警、根因分析、问题记录、纠正行动、复发防止、runbook 更新、告警调整、门禁反哺和 DORA 恢复指标统一绑定到基线门禁，避免企业只证明“事故已经复盘”，却无法证明长期修复、学习反馈和复发风险已经关闭。\n\nV2.84 进一步增加基线数据产品质量、契约违约、运行血缘与可观测性总账，把数据产品契约、schema drift、质量断言、freshness、完整性、唯一性、语义口径、访问授权、血缘、消费者影响、AI/特征/RAG 使用、契约违约、修复复测和数据质量事故统一绑定到基线门禁，避免企业只证明“有数据产品目录、契约和血缘”，却无法证明这些数据产品在运行时持续可靠、授权清晰、违约可修复、下游影响可控。\n\nV2.85 进一步增加基线工程质量、测试证据、缺陷与发布验证总账，把需求追踪、风险化测试计划、单元/集成/契约/E2E/回归/验收测试、覆盖率、测试环境、测试数据、flaky 测试、缺陷分级、修复复测、发布前验证、灰度/冒烟和质量风险接受统一绑定到基线门禁，避免企业只证明“CI 通过、有人验收”，却无法证明真实软件正确性、回归风险、已知缺陷和发布质量风险已经闭合。\n\nV2.86 进一步增加基线人员能力、培训、职责履职与职责分离总账，把关键岗位任命、RACI 职责确认、岗位资格、平台/安全/隐私/AI 专项培训、on-call 资格、审批授权、代理授权、职责分离、冲突角色治理和备份人员覆盖统一绑定到基线门禁，避免企业只证明“有人负责、有人批准”，却无法证明这些人具备资格、授权有效且没有自审自批或权限冲突。\n\nV2.87 进一步增加基线业务结果、价值实现与组合收益总账，把业务目标、价值假设、投资组合归属、收益 owner、关键结果、前后基线、采用证据、收益实现、成本效率和停投/加投决策统一绑定到基线门禁，避免企业架构治理只证明“做得合规、稳定、安全”，却无法证明这些投入是否交付了可度量业务结果。\n\nV2.88 进一步增加基线价值流、关键旅程与端到端流程总账，把跨领域价值流、客户旅程、BPMN/流程模型、流程 owner、步骤级遥测、跨域交接、瓶颈、异常、人工兜底、控制点和改进动作统一绑定到基线门禁，避免业务结果已经入账但端到端流程本身不可观测、不可审计、不可优化。\n\nV2.89 进一步增加基线架构视图、运行拓扑与依赖影响总账，把 ISO 42010 风格架构视图、C4/部署视图、catalog 声明依赖、GitOps 运行拓扑、OpenTelemetry 观测依赖、OpenLineage 数据血缘、数据/AI/第三方依赖、blast radius、变更影响和依赖漂移统一绑定到基线门禁，避免架构图、运行事实和变更影响各自存在却无法相互证明。\n\nV2.90 进一步增加基线质量属性、架构驱动与权衡决策总账，把 ISO/IEC 25010 质量模型、SEI ATAM 质量属性场景、架构驱动、敏感点、权衡点、ADR、适配度函数、SLO/容量/安全/韧性/成本验证和业务目标统一绑定到基线门禁，避免企业只证明系统“已经受控”，却无法证明架构取舍是否满足业务优先级和可测质量要求。\n\nV2.91 进一步增加基线架构原则、约束、反模式与例外执行总账，把架构原则、强制约束、禁止项、反模式、检测方式、门禁入口、违反处置、例外审批、风险接受、ADR 和复核周期统一绑定到基线门禁，避免企业只证明“文档里写了原则”，却无法证明原则在真实提交、发布、GitOps、runtime admission 和审计导出中被执行。\n\nV2.92 进一步增加基线版本策略、发布通道、兼容性与冻结控制总账，把 SemVer 语义、Conventional Commit 分类、发布通道、冻结窗口、签名 tag、兼容窗口、消费锁、迁移窗口、紧急补丁、撤销隔离和证据摘要统一绑定到基线门禁，避免企业只证明“有版本号和 tag”，却无法证明版本升级、冻结、补丁、撤销、迁移和消费端锁定是同一组发布事实。\n\nV2.93 进一步把 V2.69 至 V2.92 的控制项覆盖增量补齐到同一清单，确保监管义务、隐私、身份、业务结果、架构视图、质量属性、架构原则和版本策略控制不仅存在于正文和证据总账，也能被 schema、example 和 checker 规则证明。\n\nV2.94 进一步把公开文档中的本地私有资产、审计导出和制品取回入口统一收敛为受控私有制品引用或企业内部命令 URI，确保远端基线只暴露可审计边界，不误推本地 schema/example、生成清单、内部脚本或审计导出原文。\n\nV2.95 进一步补齐证据保证等级与采信规则，把证据从“存在即可”提升为“来源可信、生成可重放、摘要可校验、独立性匹配风险等级、仍在新鲜度窗口内”。它用于约束 release gate、会审裁决、控制保证抽样和审计导出：弱证据只能支撑草案或低风险试点，不能支撑 L3 / L4 生产基线、frozen 晋级或正式审计导出。\n\nV2.96 进一步补齐 V2.95 的消费链闭合问题：`baseline-evidence-assurance-classification.yaml` 不能只是证据目录中的一个新模板，还必须被基线晋级矩阵、制品清单、starter gate、会审裁决、审计导出和状态迁移阻断条件共同消费。这样 release gate 才能证明每个关键证据节点不仅存在，而且达到当前风险等级要求的最低保证等级、采信状态、新鲜度、完整性和可重放要求。\n\nV2.97 进一步补齐门禁 fail-closed 证明链：`baseline-gate-negative-test-suite.yaml` 必须把错误 fixture、预期失败规则、实际拒绝结果、失败日志摘要、覆盖的 gate、复测命令和 owner 固化为基线证据。它要求 release gate、starter gate、审计导出、运行时准入和状态迁移都至少具备正例通过与负例拒绝两类证明，禁止只用好样例证明门禁有效。\n\nV2.98 进一步补齐 AI 合规分类与生命周期影响证据：`baseline-ai-system-regulatory-impact-ledger.yaml` 必须把 AI 系统用途、部署角色、适用法规、风险分类、禁止/高风险/通用目的 AI 判断、人工监督、日志留存、技术文档、数据治理、透明度、后市场监测、供应商责任和合规缺口固化为基线证据。它要求 AI 产品、Agent、RAG、微调模型和模型供应商接入都能从 AI 证据账本追溯到监管义务、风险登记、DPIA、会审裁决和 release gate 阻断规则，禁止只用“AI 风险等级”一个字段替代合规分类。\n\nV2.98 起点包括：\n\n1. 真相源字段矩阵：明确 `domain.yaml`、`service.yaml`、`ai-product.yaml`、`data-product.yaml`、catalog、GitOps 和 runtime 的字段权威。\n2. 契约模板：提供服务、领域、数据产品、AI 产品、Agent 工具、RAG、微调、GitOps 和生产就绪模板。\n3. 自动化门禁：把 API、事件、数据契约、AI 门禁、SBOM、签名、SLO、成本标签和 catalog entry 纳入 CI。\n4. RACI：明确架构组、领域团队、平台团队、数据团队、安全团队、AI 产品团队、SRE 和业务 owner 的决策权。\n5. 仓库拓扑剖面：覆盖 monorepo、多仓、独立 GitOps 仓、平台仓和数据仓的适配模式。\n6. 可靠性分级：补齐 Tier-1 / Tier-2 / Tier-3、RTO、RPO、灾备演练、错误预算和 on-call 升级路径。\n7. 迁移与弃用：定义旧系统绞杀迁移、API 版本弃用、数据产品兼容、AI 模型退役和平台能力下线流程。\n8. 验证包：提供 `make test`、schema 校验、示例仓库和审计证据清单，证明标准可以落地执行。\n9. Starter Kit：提供 `本地私有 starter kit` 下的 128 组 schema/example、基线版本策略、发布通道、兼容性与冻结控制总账、基线生产变更、发布编排、变更冲突与失败恢复总账、基线事故、问题、纠正行动与复发防止总账、基线数据产品质量、契约违约、运行血缘与可观测性总账、基线工程质量、测试证据、缺陷与发布验证总账、基线人员能力、培训、职责履职与职责分离总账、基线业务结果、价值实现与组合收益总账、基线价值流、关键旅程与端到端流程总账、基线架构视图、运行拓扑与依赖影响总账、基线质量属性、架构驱动与权衡决策总账、基线架构原则、约束、反模式与例外执行总账、基线安全配置、加固姿态与配置漂移修复总账、基线漏洞、暴露面与修复验证总账、基线威胁建模、攻击面与安全风险总账、基线容量、性能、弹性伸缩与成本效率总账、基线服务可靠性、SLO、错误预算与可观测性总账、基线备份、恢复、灾备与可恢复性验证总账、基线密码材料、密钥、证书与秘密生命周期总账、基线资产关键性、数据分类与风险分级总账、基线身份权限、特权访问与工作负载身份总账、基线处理活动、个人数据清单与 RoPA 覆盖总账、基线隐私权利请求、同意偏好与合法基础执行总账、基线记录留存、法律保全与可防御删除总账、基线监管与合规义务可追溯总账、嵌套字段校验、格式校验、威胁建模、攻击面管理、安全风险治理、可靠性、性能、容量、成本效率、数据治理、AI 运行、基线运营韧性与重要业务服务影响容忍总账、基线第三方与关键供应商风险总账、基线数据驻留与跨境处理总账、基线共享责任与继承控制总账、基线独立控制保证抽样总账、基线连续控制监测总账、基线运行时准入决策总账、基线运行时准入回执、基线长期验签回执、基线证据不可变归档回执、干净环境基线重建回执、私有制品托管交接清单、审计导出排除清单、本地私有制品边界、基线迁移执行回执、基线迁移工作单、基线消费锁定文件、基线准入执行策略、基线撤销与隔离记录、基线发布事务回执、基线门禁执行报告、基线证据追踪图、基线会审裁决记录、基线 EOL 退役证书、基线状态对账报告、基线生命周期状态机、基线就绪评分卡、基线例外总账、基线回滚验证记录、基线通知确认总账、基线验证环境锁定、基线制品清单、基线符合性声明、基线发布列车、基线支持矩阵、基线采纳总账、基线兼容性总账、基线发布证据包、版本控制面、外部标准版本锁定、企业执行控制面、合规等级、门禁决策、仓库变更控制、远端保护漂移整改、AI 证据账本、AI 系统监管分类与影响评估总账、微调运行证据、AI 事件响应 playbook、GitOps 安全、架构决策记录、风险登记、证据保证等级消费链、基线门禁负例测试、故障注入、期望失败证据、fail-closed 覆盖、证据链验真字段和示例跨文件一致性检查。\n10. 版本清单：提供 `本地私有版本清单`，让当前版本、发布状态、pair 清单和索引同步进入 CI 校验。\n11. 控制项覆盖清单：提供 `本地私有控制项覆盖清单`，让关键控制项到 schema、example 和 checker 的证据链进入 CI 校验。\n12. 严格 schema 模式：starter kit 的对象 schema 必须声明 `additionalProperties=false`，新增字段必须先进入契约、示例和 checker 证据链。\n13. 扩展字段策略：新增 `extension-policy.yaml`，让企业自定义字段只能通过受控前缀、审批和默认拒绝策略进入标准。\n14. 渐进式发布控制：新增 `feature-flag-control.yaml`，把 Feature Flag、Kill Switch、灰度指标、SLO 燃尽回滚和曝光事件纳入门禁。\n15. AI 威胁模型：新增 `ai-threat-model.yaml`，把 OWASP LLM / Agentic AI、MCP 工具同意、红队、出站限制和残余风险接受纳入证据链。\n16. 运行血缘：新增 `lineage-event.yaml`，把数据产品的 producer job、run、input/output dataset、schema、质量证据和血缘后端纳入审计。\n17. 平台产品指标：新增 `platform-product-metrics.yaml`，把 Platform PM、Golden Path 采用率、开发者满意度、认知负载和平台 SLO 纳入可执行标准。\n18. 隐私影响评估：新增 `privacy-impact-assessment.yaml`，把 DPIA、处理目的、合法基础、主体权利、删除传播和 AI 使用限制纳入门禁。\n19. 租户隔离：新增 `tenant-boundary.yaml`，把 namespace、ServiceAccount、Secret 范围、ResourceQuota、NetworkPolicy 和准入策略纳入证据链。\n20. 恢复演练：新增 `recovery-drill-evidence.yaml`，把 RTO/RPO 从声明升级为演练结果、备份、恢复日志和复盘证据。\n21. 策略测试：新增 `policy-test-report.yaml`，把 OPA / Cedar / Kyverno 等策略测试结果、失败数和阻断决策纳入门禁。\n22. GenAI 观测：新增 `genai-observability-contract.yaml`，把 OpenTelemetry GenAI、Token、成本、工具调用、RAG span 和日志脱敏纳入运行契约。\n23. 成本分摊证据：新增 `cost-allocation-evidence.yaml`，把标签覆盖率、未分摊成本、云/AI/数据成本和优化行动纳入 FinOps 证据。\n24. 访问复核：新增 `identity-access-review.yaml`，把身份源、角色、特权访问、break-glass、MFA 和复核结论纳入门禁。\n25. 密钥轮换：新增 `secrets-rotation-evidence.yaml`，把 Secret provider、KMS、静态加密、轮换周期、泄露扫描和轮换结果纳入证据链。\n26. 漏洞修复：新增 `vulnerability-remediation-evidence.yaml`，把漏洞严重度、KEV 状态、SLA、修复日期、残余风险和发布准入纳入控制项。\n27. 事故复盘：保留 `incident-postmortem.yaml` 作为单次事故局部复盘模板，把检测/恢复时间、影响、根因、纠正行动、runbook 更新和门禁反哺纳入闭环，并由 V2.83 的 `baseline-incident-problem-corrective-action-ledger.yaml` 汇总为基线级证据。\n28. 证据新鲜度：新增 `evidence-freshness-policy.yaml`，把证据最大年龄、按类型过期策略、CI 执行和过期阻断纳入审计生命周期。\n29. 控制证据映射：新增 `control-evidence-map.yaml`，把控制项 ID、证据路径、状态、新鲜度、必需性和阻断属性纳入审计总账。\n30. 审计导出清单：新增 `audit-export-manifest.yaml`，把导出包范围、内容、验证结果、签名要求和留存策略纳入可交付证据。\n31. 审计导出自动化：新增 `internal-command://architecture/export-modern-architecture-audit`，生成 `assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json`、`audit-export.md`、`oscal-summary.json`、`audit-export-integrity.json`、`audit-export-provenance.json` 和 `audit-export-signing-policy.json`。\n32. 控制评估报告：新增 `control-assessment-report.yaml`，把评估范围、评估人、控制结果、发现项、整改、剩余风险和签署状态纳入审计闭环。\n33. 架构基线变更记录：新增 `baseline-change-record.yaml`，把基线版本、前序版本、影响分析、审批、验证命令和回滚计划纳入变更控制。\n34. OSCAL 交换映射：新增 `oscal-export-profile.yaml`，把内部控制、证据、评估和整改映射到 OSCAL 交换视图，并生成 `oscal-summary.json`。\n35. 审计导出门禁：新增 `audit-export-gate.yaml` 和 `internal-command://architecture/check-modern-architecture-audit-export`，把导出输出不变量纳入 `make test`。\n36. 审计导出完整性清单：新增 `audit-export-integrity.yaml` 和 `audit-export-integrity.json`，把生成物 SHA-256、源制品哈希和防篡改校验纳入审计包。\n37. 审计导出 provenance statement：新增 `audit-export-provenance.yaml` 和 `audit-export-provenance.json`，把生成物 subject、构建定义、源码提交和源证据依赖纳入可追溯证明。\n38. 审计导出签名策略：新增 `audit-export-signing-policy.yaml` 和 `audit-export-signing-policy.json`，把 provenance payload 摘要、签名方式、验签命令和外部签名交接纳入审计包。\n39. 审计导出签名验签回执：新增 `audit-export-signature-receipt.yaml`，把外部签名后的 bundle 摘要、证书身份、透明日志和验签结果纳入证据闭环。\n40. POA&M 整改计划：新增 `poam-record.yaml`，把控制发现项、责任人、整改行动、里程碑、证据、签署和复审纳入 OSCAL POA&M 证据闭环。\n41. 企业架构风险登记：新增 `risk-register.yaml`，把风险、控制项、POA&M、缓解行动、残余风险、复审和审计导出风险视图纳入证据闭环。\n42. 架构决策记录：新增 `architecture-decision-record.yaml`，把 ADR 上下文、备选方案、取舍、决策、关联控制项、风险、POA&M、复审和基线变更绑定纳入证据闭环。\n43. AI 事件响应 playbook：新增 `ai-incident-playbook.yaml`，把幻觉爆发、工具循环、RAG 索引污染、供应商中断、成本异常、检测信号、遏制、降级、回滚、RAG 恢复、工具 Kill Switch、沟通和复盘纳入 AI 运行证据闭环。\n44. AI 证据账本：新增 `ai-evidence.yaml`，把模型、Prompt、RAG、工具、评估、威胁模型、观测、事件响应、数据使用、审批、留存和复审汇总为 AI 产品级证据总账。\n45. 微调运行证据：新增 `fine-tuning-run.yaml`，把训练数据授权、数据准备、实验追踪、评估、模型登记、审批、灰度发布、监控和退役纳入 AI 微调审计闭环。\n46. 仓库变更控制：新增 `repository-change-control.yaml`，把 CODEOWNERS、受保护分支、PR 审查、必需检查、签名提交、禁止直推、发布 tag 保护、远端保护状态验证、漂移整改、POA&M 和风险登记纳入版本基线保护。\n47. 合规等级画像：新增 `conformance-profile.yaml`，把资产风险、监管强度、数据敏感度、AI 风险等级和必须执行的门禁等级绑定。\n48. 执行控制面：新增 `control-plane.yaml`，把控制项、证据、owner、阻断级别、自动化状态、复核周期和退出标准汇总到统一执行账本。\n49. 门禁决策记录：新增 `release-gate-decision.yaml`，把每次放行、阻断、条件放行、例外、break-glass 和回滚要求纳入可审计证据。\n50. 标准基线锁定：新增 `standards-baseline.yaml`，把外部标准名称、版本、稳定性、采纳等级、owner、复核周期、升级条件和回滚策略纳入可执行基线。\n51. 版本控制面：新增 `version-governance.yaml`，把基线 ID、发布通道、tag、源 commit、兼容窗口、冻结策略、升级规则和回滚入口纳入可执行发布协议。\n52. 基线发布证据包：新增 `baseline-release-evidence.yaml`，把晋级决策、冻结复核、漂移检查、不可变引用、审计导出摘要和回滚验证纳入可执行证据。\n53. 基线兼容性总账：新增 `baseline-compatibility-ledger.yaml`，把消费者影响、迁移状态、弃用截止、例外、POA&M 和风险接受纳入版本门禁。\n54. 基线采纳总账：新增 `baseline-adoption-ledger.yaml`，把组织内领域、平台、数据、AI 和生产资产的基线采用状态、逾期、例外和整改纳入版本治理。\n55. 基线支持矩阵：新增 `baseline-support-matrix.yaml`，把历史基线支持状态、维护窗口、安全补丁窗口、EOL、最低可接受基线和例外纳入版本生命周期治理。\n56. 基线发布列车：新增 `baseline-release-train.yaml`，把候选窗口、冻结窗口、晋级日期、通知节奏、黑窗、紧急补丁和发布日历纳入版本治理。\n57. 基线符合性声明：新增 `baseline-conformance-claim.yaml`，把资产自声明基线、证据路径、例外、签署、复核和采纳总账回写纳入资产级版本治理。\n58. 基线制品清单：新增 `baseline-artifact-inventory.yaml`，把基线源文档、schema、示例、控制项、证据模板、脚本、生成物、外部引用、摘要和签名状态纳入版本物料清单。\n59. 基线验证环境锁定：新增 `baseline-verification-lock.yaml`，把校验命令、runner 镜像、工具版本、策略包、schema validator、签名验签工具和审计导出生成环境纳入可复现门禁。\n60. 基线通知确认总账：新增 `baseline-notification-ledger.yaml`，把受影响对象、通知渠道、送达回执、影响确认、异议、例外、补发和冻结前完成状态纳入版本发布门禁。\n61. 基线回滚验证记录：新增 `baseline-rollback-verification.yaml`，把上一基线、回滚目标 tag/commit、GitOps revision、审计导出恢复、烟测结果和验证时效纳入版本发布门禁。\n62. 基线例外总账：新增 `baseline-exception-ledger.yaml`，把兼容、采纳、支持、通知、回滚、门禁和控制面的例外、风险接受、POA&M、到期状态、关闭证据和冻结阻断纳入版本发布门禁。\n63. 基线就绪评分卡：新增 `baseline-readiness-scorecard.yaml`，把版本身份、控制覆盖、制品完整性、验证环境、例外健康、通知确认、回滚验证、审计导出和禁推资产检查汇总为最终准入判定。\n64. 基线生命周期状态机：新增 `baseline-lifecycle-state-machine.yaml`，把版本状态、允许迁移、禁止迁移、迁移证据、审批责任、状态回写和回滚入口纳入版本发布门禁。\n65. 基线状态对账报告：新增 `baseline-state-reconciliation-report.yaml`，把状态机、版本控制面、发布证据、支持矩阵、采纳总账、符合性声明和审计导出状态做一致性对账。\n66. 基线 EOL 退役证书：新增 `baseline-eol-retirement-certificate.yaml`，把旧基线生产引用清零、迁移关闭、例外清零、证据归档和新采用阻断纳入版本生命周期门禁。\n67. 基线会审裁决记录：新增 `baseline-review-board-decision.yaml`，把会审范围、证据核验、投票签署、反对意见、条件动作、风险接受和最终裁决纳入基线晋级门禁。\n68. 基线证据追踪图：新增 `baseline-evidence-trace-graph.yaml`，把证据节点、依赖边、摘要、状态、下游消费和断链阻断纳入基线晋级门禁。\n69. 基线门禁执行报告：新增 `baseline-gate-execution-report.yaml`，把门禁执行命令、runner、策略包、schema 包、输入摘要、逐条规则结果、退出码、重放结果和最终决策纳入基线晋级门禁。\n70. 基线发布事务回执：新增 `baseline-publish-transaction.yaml`，把提交前检查、干净工作树、source commit、签名 tag、远端 ref、push 回执、保护规则、禁推资产排除和发布后验证纳入基线发布门禁。\n71. 基线撤销与隔离记录：新增 `baseline-revocation-record.yaml`，把撤销触发、隔离范围、受影响引用、通知确认、恢复目标、风险接受、状态回写和审计归档纳入版本事故控制门禁。\n72. 基线准入执行策略：新增 `baseline-enforcement-policy.yaml`，把最低可接受基线、撤销/EOL 阻断、资产符合性声明、例外到期和 GitOps / catalog / Golden Path 准入阻断纳入统一策略。\n73. 基线消费锁定文件：新增 `baseline-consumption-lock.yaml`，把资产实际消费的 baseline ID、source commit、release tag、证据图摘要、制品清单摘要、验证锁摘要和准入策略摘要纳入消费端版本控制。\n74. 基线迁移工作单：新增 `baseline-migration-work-order.yaml`，把目标资产从当前基线迁移到目标基线的步骤、依赖、GitOps 变更、消费锁更新、验收证据和回滚动作纳入执行闭环。\n75. 基线迁移执行回执：新增 `baseline-migration-execution-receipt.yaml`，把迁移实际命令、执行人、执行环境、before/after 摘要、GitOps revision、catalog/lock diff、验收日志和回滚验证纳入独立执行证据。\n76. 本地私有制品边界：新增 `baseline-local-artifact-boundary.yaml`，把本地私有 starter kit、生成清单、校验脚本、禁推原因、摘要留存、远端排除和审计留存纳入受控边界。\n77. 审计导出排除清单：新增 `audit-export-exclusion-manifest.yaml`，把导出原文白名单、摘要留存项、强制排除项、签名 payload 排除项和导出后验证纳入审计包门禁。\n78. 私有制品托管交接清单：新增 `private-artifact-escrow-manifest.yaml`，把禁推可执行资产的私有 registry / 制品库引用、摘要、访问控制、留存、取回命令和恢复验证纳入证据链。\n79. 干净环境基线重建回执：新增 `baseline-clean-room-reconstruction-receipt.yaml`，把远端 checkout、私有制品取回、摘要校验、审计导出重建、门禁重放和禁推资产复核纳入基线可重建证明。\n80. 基线证据不可变归档回执：新增 `baseline-evidence-archive-receipt.yaml`，把审计证据归档到不可变留存库、对象锁、WORM、legal hold、访问日志、删除保护和恢复演练纳入基线长期可审计证明。\n81. 基线长期验签回执：新增 `baseline-signature-ltv-receipt.yaml`，把签名 bundle、证书链、OIDC issuer、透明日志 proof、signed entry timestamp、RFC3161 TSA、撤销状态、验证工具版本和归档位置纳入长期验签证明。\n82. 基线运行时准入回执：新增 `baseline-runtime-admission-receipt.yaml`，把 admission controller、策略引擎、镜像 digest、签名/provenance/SBOM 校验、消费锁、撤销/EOL 阻断和拒绝样例纳入生产入口证明。\n83. 基线运行时准入决策总账：新增 `baseline-runtime-admission-decision-ledger.yaml`，把 Kubernetes audit requestUID、admission webhook、策略规则、allow/deny、actor、namespace、workload、镜像 digest 和原始日志摘要纳入逐条证据。\n84. 基线连续控制监测总账：新增 `baseline-continuous-control-monitoring-ledger.yaml`，把控制指标、日志源、告警规则、监测窗口、漂移事件、处置工单、owner、MTTD/MTTR 和证据新鲜度纳入持续运行证据。\n85. 基线独立控制保证抽样总账：新增 `baseline-control-assurance-sampling-ledger.yaml`，把独立评估人、评估目标、控制总体、抽样方法、设计有效性、运行有效性、发现项、整改、风险接受、签署和 OSCAL Assessment Results 纳入可复核控制保证证据。\n\nV2.95 补充项：新增 `baseline-evidence-assurance-classification.yaml` 的公开契约说明，把证据等级、采信状态、生成方式、来源独立性、完整性证明、新鲜度窗口、可重放命令和最低适用门禁纳入 release gate 证据采信规则；对应私有 schema/example 仍按禁推资产边界维护，不进入公开远端。\n\nV2.97 补充项：新增 `baseline-gate-negative-test-suite.yaml` 的公开契约说明，把负例 fixture、故障注入、预期失败规则、实际拒绝结果、失败日志摘要、复测命令、覆盖 gate 和回归 owner 纳入 release gate、starter gate、审计导出、运行时准入和状态迁移 fail-closed 证明；对应私有 schema/example 与负例 fixture 仍按禁推资产边界维护，不进入公开远端。\n\nV2.98 补充项：新增 `baseline-ai-system-regulatory-impact-ledger.yaml` 的公开契约说明，把 AI 系统用途、部署角色、适用法规、风险分类、禁止/高风险/通用目的 AI 判断、人工监督、日志留存、技术文档、数据治理、透明度、后市场监测、供应商责任和合规缺口纳入 release gate、会审裁决、风险登记、监管义务总账和审计导出证据；对应私有 schema/example 仍按禁推资产边界维护，不进入公开远端。\n\n86. 基线共享责任与继承控制总账：新增 `baseline-control-inheritance-ledger.yaml`，把 inherited、shared、provider-managed、domain-owned 和 consumer-owned 控制责任、继承条件、消费者义务、证据引用和失效阻断纳入可执行治理证据。\n87. 基线数据驻留与跨境处理总账：新增 `baseline-data-residency-transfer-ledger.yaml`，把数据类别、监管区域、实际处理位置、跨境传输机制、子处理方、补充保护措施、删除传播和区域漂移阻断纳入可执行治理证据。\n88. 基线第三方与关键供应商风险总账：新增 `baseline-third-party-risk-ledger.yaml`，把关键供应商分级、服务范围、合同控制、DPA/SLA、审计权、保证报告、数据类别、集中度、退出计划、替代路径、连续性和供应商事件阻断纳入可执行治理证据。\n89. 基线运营韧性与重要业务服务影响容忍总账：新增 `baseline-operational-resilience-ledger.yaml`，把重要业务服务、影响容忍、BIA、端到端依赖、严重但合理场景测试、恢复能力、人工替代、沟通计划、第三方依赖、韧性缺口和超限升级纳入可执行治理证据。\n90. 基线监管与合规义务可追溯总账：新增 `baseline-regulatory-obligation-ledger.yaml`，把义务来源、适用司法辖区、适用资产、控制目标、控制项、证据路径、owner、例外、POA&M、监管变更和生效期限纳入可执行治理证据。\n91. 基线记录留存、法律保全与可防御删除总账：新增 `baseline-records-retention-legal-hold-ledger.yaml`，把记录类别、留存排期、义务来源、司法辖区、legal hold、删除资格、删除传播、备份/日志/向量索引处置和可防御删除回执纳入可执行治理证据。\n92. 基线隐私权利请求、同意偏好与合法基础执行总账：新增 `baseline-privacy-rights-consent-ledger.yaml`，把处理目的、合法基础、同意偏好、撤回传播、DSAR/消费者权利请求、自动化决策复核、第三方传播和下游处理阻断纳入可执行治理证据。\n93. 基线处理活动、个人数据清单与 RoPA 覆盖总账：新增 `baseline-processing-activity-inventory-ledger.yaml`，把处理活动、数据主体类别、个人数据类别、控制者/处理者角色、接收方、跨境传输、保留映射、合法基础、DPIA、AI/数据产品用途和发现覆盖纳入可执行治理证据。\n94. 基线身份权限、特权访问与工作负载身份总账：新增 `baseline-identity-entitlement-access-ledger.yaml`，把人类身份、服务账号、工作负载身份、JML、MFA、PAM/JIT、break-glass、最小权限、孤儿账号、过期权限和运行时身份绑定纳入可执行治理证据。\n95. 基线资产关键性、数据分类与风险分级总账：新增 `baseline-asset-criticality-classification-ledger.yaml`，把资产 owner、业务关键性、SLO Tier、L3/L4 合规等级、CIA 影响、数据敏感度、监管暴露、AI 风险等级、互联网暴露、第三方关键性和复核状态纳入可执行治理证据。\n96. 基线密码材料、密钥、证书与秘密生命周期总账：新增 `baseline-cryptographic-secrets-key-certificate-ledger.yaml`，把 KMS/HSM key、TLS 证书、签名密钥、API token、数据库凭据、webhook secret、工作负载密钥、轮换、过期、吊销、泄露响应和 owner 纳入可执行治理证据。\n97. 基线备份、恢复、灾备与可恢复性验证总账：新增 `baseline-backup-restore-disaster-recovery-ledger.yaml`，把关键系统、数据库、对象存储、配置、队列、向量索引、审计证据、备份策略、不可变/离线副本、跨区域隔离、恢复演练、RTO/RPO、完整性校验和勒索隔离纳入可执行治理证据。\n98. 基线服务可靠性、SLO、错误预算与可观测性总账：新增 `baseline-service-reliability-slo-error-budget-observability-ledger.yaml`，把生产服务、关键用户旅程、SLI/SLO、错误预算、告警路由、on-call、runbook、合成探测、指标/日志/链路覆盖、降级策略和可靠性事件反馈纳入可执行治理证据。\n99. 基线容量、性能、弹性伸缩与成本效率总账：新增 `baseline-capacity-performance-cost-efficiency-ledger.yaml`，把容量预测、压测、性能基准、资源 requests/limits、HPA/VPA/KEDA、队列积压、数据库容量、预算、单位经济、成本分摊、异常成本和优化行动纳入可执行治理证据。\n100. 基线威胁建模、攻击面与安全风险总账：新增 `baseline-threat-model-attack-surface-risk-ledger.yaml`，把关键服务、API、事件、数据产品、AI 产品、GitOps 入口、平台共享能力、信任边界、数据流、攻击面、滥用场景、安全测试、剩余风险、POA&M 和签署状态纳入可执行治理证据。\n101. 基线漏洞、暴露面与修复验证总账：新增 `baseline-vulnerability-exposure-remediation-ledger.yaml`，把 CVE、KEV、EPSS、CVSS、VEX/CSAF、SBOM/SCA、容器镜像、IaC、Kubernetes、云配置、外部暴露、API/AI 工具入口、修复 SLA、复测和例外纳入可执行治理证据。\n102. 基线安全配置、加固姿态与配置漂移修复总账：新增 `baseline-secure-configuration-posture-drift-ledger.yaml`，把 CIS/NIST/SCAP、Pod Security、OS、容器、Kubernetes、云、IAM、网络、存储、数据库、CI/CD、API Gateway、LLM Gateway、Agent Runtime、审计日志、加密配置、漂移、修复、例外和发布准入纳入可执行治理证据。\n103. 基线生产变更、发布编排、变更冲突与失败恢复总账：新增 `baseline-production-change-release-ledger.yaml`，把代码部署、GitOps 同步、数据库迁移、配置变更、Feature Flag、Prompt/模型变更、紧急变更、黑窗、冲突检测、回滚、失败恢复、事故关联和 DORA 指标纳入可执行治理证据。\n104. 基线事故、问题、纠正行动与复发防止总账：新增 `baseline-incident-problem-corrective-action-ledger.yaml`，把生产事故、安全事件、隐私事件、AI 事件、供应商事件、near miss、RCA、问题记录、纠正行动、复发防止、runbook 更新、门禁反哺和 DORA 恢复指标纳入可执行治理证据。\n105. 基线数据产品质量、契约违约、运行血缘与可观测性总账：新增 `baseline-data-product-quality-contract-observability-ledger.yaml`，把数据产品 owner、契约版本、schema drift、质量断言、freshness、完整性、唯一性、语义口径、访问授权、血缘、消费者影响、AI/特征/RAG 使用、契约违约、修复复测和数据质量事故纳入可执行治理证据。\n106. 基线工程质量、测试证据、缺陷与发布验证总账：新增 `baseline-engineering-quality-test-release-verification-ledger.yaml`，把需求追踪、测试策略、单元/集成/契约/E2E/回归/验收测试、覆盖率、测试环境、测试数据、flaky 测试、缺陷、修复复测、发布前验证、灰度/冒烟结果和质量风险接受纳入可执行治理证据。\n107. 基线人员能力、培训、职责履职与职责分离总账：新增 `baseline-workforce-competency-training-duty-segregation-ledger.yaml`，把关键角色任命、岗位资格、职责确认、培训完成、专项训练、on-call 资格、审批授权、代理授权、职责分离、冲突角色、备份人员和到期复核纳入可执行治理证据。\n108. 基线业务结果、价值实现与组合收益总账：新增 `baseline-business-outcome-value-realization-portfolio-ledger.yaml`，把业务目标、价值假设、收益 owner、投资组合、关键结果、前后基线、采用证据、收益实现、成本效率、风险接受和停投/加投决策纳入可执行治理证据。\n109. 基线价值流、关键旅程与端到端流程总账：新增 `baseline-value-stream-journey-process-ledger.yaml`，把跨领域价值流、客户旅程、BPMN/流程模型、流程 owner、步骤级遥测、瓶颈、异常、人工兜底、控制点和改进动作纳入可执行治理证据。\n110. 基线架构视图、运行拓扑与依赖影响总账：新增 `baseline-architecture-view-runtime-topology-dependency-ledger.yaml`，把架构视图、C4/部署视图、catalog 声明依赖、运行时观测依赖、GitOps 拓扑、数据/AI/第三方依赖、blast radius、变更影响和依赖漂移纳入可执行治理证据。\n111. 基线质量属性、架构驱动与权衡决策总账：新增 `baseline-quality-attribute-architecture-driver-tradeoff-ledger.yaml`，把业务驱动、质量属性场景、可度量响应指标、架构驱动、敏感点、权衡点、ADR、适配度函数和验证证据纳入可执行治理证据。\n112. 基线架构原则、约束、反模式与例外执行总账：新增 `baseline-architecture-principle-constraint-exception-ledger.yaml`，把原则 owner、适用范围、强制约束、禁止项、反模式、检测方式、门禁入口、违反处置、例外审批、风险接受、ADR 和复核周期纳入可执行治理证据。\n113. AI 系统监管分类与影响评估总账：新增 `baseline-ai-system-regulatory-impact-ledger.yaml`，把 AI 系统用途、部署角色、适用法规、风险分类、禁止/高风险/通用目的 AI 判断、人工监督、日志留存、技术文档、数据治理、透明度、后市场监测、供应商责任和合规缺口纳入可执行治理证据。\n114. 基线版本策略、发布通道、兼容性与冻结控制总账：新增 `baseline-version-policy-release-control-ledger.yaml`，把版本号语义、发布通道、Conventional Commit 分类、签名 tag、兼容窗口、冻结规则、紧急补丁、撤销隔离、消费锁和迁移窗口纳入可执行治理证据。\n\n---\n\n## 1. 背景与建设目标\n\n随着企业业务线上化、服务生态化、数据资产化和 AI 应用普及，传统以项目交付、烟囱系统、集中审批和人工运维为主的 IT 建设模式，已经难以支撑快速变化的业务需求。\n\n传统模式常见问题包括：\n\n1. 业务系统重复建设，能力难复用。\n2. 前台团队依赖集中平台或 IT 团队排期，交付周期长。\n3. 数据分散在各业务系统中，口径不统一、质量不可控。\n4. 平台能力依赖工单和人工配置，研发效率低。\n5. 治理主要依赖架构委员会、审批流程和人工检查，难以规模化。\n6. 系统运行责任不清晰，业务指标、技术指标和数据指标割裂。\n\n因此，本架构的建设目标是建立一套面向现代企业的数字化平台体系：\n\n> 前台团队端到端负责业务结果，领域团队沉淀可复用业务能力和数据产品，平台团队提供自助式工程底座，治理团队将规则自动化为平台护栏，而不是依赖集中审批。\n\n本架构不是建设一个中央共享服务池，而是建设一个由多个领域产品、数据产品、内部平台和联邦治理机制组成的企业级数字化能力网络。\n\n---\n\n## 2. 架构总览\n\n现代企业数字化平台由七个纵向层级和一个横向治理平面组成。\n\n```text\n用户 / 客户 / 合作方 / 员工 / 运营人员\n │\n ▼\n一、前台体验层\nWeb / App / 小程序 / Open API / 运营后台 / Partner Portal\n │\n ▼\n二、体验编排层\nBFF / API Gateway / GraphQL / Workflow / Event Subscription\n │\n ▼\n三、AI 原生能力层\nAI 应用 / Agent Runtime / LLM Gateway / RAG / Vector Store / PromptOps / Evals\n │\n ▼\n四、领域能力产品层\n用户域 / 商品域 / 订单域 / 支付域 / 履约域 / 风控域 / 营销域 / 内容域\n │\n ▼\n五、数据产品网络层\nSource-aligned Data Product / Aggregate Data Product / Consumer-aligned Data Product\n指标层 / 语义层 / 特征层 / 向量索引 / 报表 / AI 数据服务\n │\n ▼\n六、自助式平台工程层\nDeveloper Portal / Golden Path / CI/CD / IaC / GitOps / Kubernetes / 可观测性 / AI Platform\n │\n ▼\n七、基础设施与云原生层\nCloud / Kubernetes / Network / Storage / Database / Queue / Cache / Search / GPU / Vector DB\n\n横向贯穿：\n联邦治理平面\n身份权限 / API 标准 / 数据契约 / AI 治理 / 安全策略 / 供应链安全 / 合规审计 / 架构决策\nSLO / 成本规则 / 质量门禁 / Policy as Code / 自动化检测 / SBOM / Provenance\n```\n\n架构核心可以概括为：\n\n> 现代企业数字化平台 = 前台体验 + 体验编排 + AI 原生能力 + 领域能力产品 + 数据产品网络 + 自助式平台工程 + 云原生基础设施 + 联邦治理。\n\n## 2.1 推荐项目目录结构\n\n落到工程仓库时，应把不同类型的“真相源”分开，避免把架构、契约、运行、治理和文档混成一个目录。\n\n下面结构是企业级数字化平台的推荐参考形态，不是唯一强制目录。若团队采用 `services/*`、`apps/*`、独立 GitOps 仓库或多仓模式，也可以沿用同样职责边界。真正必须保持的是：服务源码、镜像制品、环境部署期望状态、实际运行状态、目录发现、平台能力和治理规则不能混成一个真相源。\n\n```text\nrepo/\n├── apps/ # 前台体验真相源：Web、App、后台、门户、AI 体验入口\n│ ├── web/ # Web 前台应用；只做体验交付，不沉淀领域核心规则\n│ ├── mobile/ # 移动端应用；通过 BFF/API 消费领域能力\n│ ├── admin/ # 运营后台；承载管理体验，不直接访问领域数据库\n│ ├── partner-portal/ # 合作方门户；通过受控 API 和权限策略接入\n│ ├── open-api-portal/ # 开放 API 门户；展示契约、文档、申请和审计入口\n│ └── ai-experiences/ # AI 体验入口；具体 Agent/RAG/Prompt 资产放 ai/\n│\n├── ai/ # AI 原生能力：Agent、RAG、LLMOps 和 AI 产品运行单元\n│ ├── applications/ # 面向业务场景的 AI 应用\n│ ├── agents/ # Agent 定义、角色、工具权限和运行策略\n│ ├── workflows/ # Agent 工作流、人工确认点和补偿流程\n│ ├── prompts/ # Prompt 模板、版本、评测样例和变更记录\n│ ├── evals/ # 模型、Prompt、RAG 和 Agent 评估集\n│ ├── rag/ # 摄取、切分、嵌入、索引和检索流水线\n│ ├── tools/ # AI 可调用工具和 MCP/A2A 适配器\n│ ├── model-gateway/ # 模型路由、限流、成本、审计和降级；不保存供应商密钥明文\n│ ├── guardrails/ # 安全护栏、输出校验、PII 防泄露和策略\n│ ├── observability/ # Token、延迟、质量、幻觉、工具调用和成本观测\n│ ├── model-registry/ # 模型、Embedding、重排模型和批准状态\n│ ├── fine-tuning/ # 微调数据授权、实验追踪、评估和发布证据\n│ └── docs/\n│\n├── domains/ # 领域能力产品真相源：领域模型、业务服务、API、事件和数据产品\n│ ├── customer/\n│ │ ├── domain.yaml # 领域边界、owner、SLO、上下游依赖\n│ │ ├── apis/ # 领域 API 契约\n│ │ ├── events/ # 领域事件契约\n│ │ ├── services/ # 领域服务运行单元；默认推荐放领域内，非强制唯一位置\n│ │ │ └── customer-profile-service/\n│ │ │ ├── src/ # 服务源码；也可按技术栈拆成 cmd/src/internal 等\n│ │ │ ├── Dockerfile # 镜像构建定义；镜像本体进入 registry，不进入 Git\n│ │ │ ├── service.yaml # 服务运行契约：owner、端口、依赖、资源诉求、SLO、镜像仓库\n│ │ │ ├── README.md # 服务说明、运行方式、runbook 入口\n│ │ │ └── tests/ # 服务内测试；跨域测试放仓库 tests/\n│ │ ├── workflows/ # 领域流程和长事务编排\n│ │ ├── data-products/ # 领域发布的数据产品\n│ │ ├── policies/ # 领域权限、数据和访问策略\n│ │ ├── scorecards/ # 领域成熟度和运行质量评分\n│ │ └── docs/\n│ ├── order/\n│ ├── payment/\n│ ├── fulfillment/\n│ ├── risk/\n│ └── marketing/\n│\n├── platform/ # 内部开发平台真相源：标准能力、模板、自动化和开发者体验\n│ ├── portal/ # Developer Portal；聚合服务、API、数据产品、AI 产品和 scorecard\n│ ├── golden-paths/ # 推荐路径；创建服务、数据产品、AI 产品和容器交付模板\n│ ├── scaffolds/ # 脚手架；生成服务骨架、Dockerfile、service.yaml、catalog descriptor\n│ ├── orchestration/ # 平台编排；自助申请资源、环境、权限和发布流程\n│ ├── ci-cd/ # 流水线模板；不保存某个服务的业务逻辑\n│ ├── environments/ # 环境抽象和平台入口；具体 prod 期望状态放 infra/gitops/\n│ ├── observability/ # 日志、指标、链路追踪和默认仪表盘模板\n│ ├── security/ # 安全扫描、准入、密钥接入和策略模板\n│ ├── data-platform/ # 数据平台自助能力：目录、血缘、质量、权限、计算\n│ ├── ai-platform/ # AI 平台自助能力：LLM Gateway、RAG、Evals、Agent Runtime\n│ ├── supply-chain/ # SBOM、provenance、签名、验签和制品准入能力\n│ ├── cost/ # FinOps、预算、成本归集和异常检测\n│ ├── developer-tools/ # CLI、SDK、代码生成和本地开发工具\n│ ├── scorecards/ # 平台、服务、数据产品和 AI 产品成熟度评分模板\n│ └── docs/ # 平台用户文档和 onboarding 文档\n│\n├── contracts/ # 跨团队机器可读契约真相源；进入 CI 校验\n│ ├── apis/ # OpenAPI / GraphQL 等接口契约\n│ ├── events/ # AsyncAPI、事件 topic、Schema 和兼容策略\n│ ├── schemas/ # JSON Schema、Proto、Avro 等共享 Schema\n│ ├── datasets/ # 数据产品契约、质量规则、语义层和数据访问策略\n│ ├── ai/ # AI 工具、Prompt、RAG、评估、微调和护栏契约\n│ ├── resources/ # 云资源、Terraform module、Kubernetes CRD 等资源契约\n│ └── policies/ # OPA/Rego、Cedar、IAM 等策略契约\n│\n├── catalog/ # 发现目录真相源：系统、组件、资源、owner、生命周期和关系\n│ ├── systems/ # 系统级聚合；用于表达一组组件共同支撑的业务系统\n│ ├── components/ # 服务、任务、前端、库等组件条目；指向源码和 GitOps 路径\n│ ├── resources/ # 数据库、队列、缓存、对象存储、向量库等资源条目\n│ ├── apis/ # API 目录；指向 contracts/apis 或领域 apis\n│ ├── data-products/ # 数据产品目录；指向领域 data-products 和数据契约\n│ ├── ai-products/ # AI 产品目录；指向 ai/applications 和治理证据\n│ ├── models/ # 模型目录；基础模型、微调模型、Embedding 和重排模型\n│ ├── agents/ # Agent 目录；角色、工具权限、风险等级和 owner\n│ ├── domains/ # 领域目录；领域 owner、上下游、能力地图\n│ └── scorecards/ # 各资产成熟度、生产就绪、安全和可靠性评分\n│\n├── governance/ # 联邦治理资产真相源：规则、决策、门禁、风险和复盘\n│ ├── standards/ # API、事件、数据、工程、安全、可靠性、成本等标准\n│ ├── decisions/ # ADR；记录重大架构决策、取舍和后续行动\n│ ├── ownership/ # 团队、RACI、升级路径和服务 owner\n│ ├── slo/ # SLO 分级、错误预算和事件响应策略\n│ ├── security/ # 威胁建模、数据分级、安全开发和隐私规则\n│ ├── supply-chain/ # SLSA、SBOM、签名验签和制品准入规则\n│ ├── ai-governance/ # AI 产品、模型风险、Prompt、微调和 Agent 工具治理\n│ ├── data-governance/ # 数据产品评审、PII、保留期限和权限规则\n│ ├── architecture-gates/ # 生产就绪、领域就绪、数据产品就绪和 AI 发布门禁\n│ ├── migration/ # 迁移、兼容、弃用、退役和绞杀者模式治理\n│ ├── evidence/ # 发布、审计、验证、演练和合规证据清单\n│ ├── risk-register/ # 风险登记；必须有 owner、缓解措施和到期时间\n│ ├── postmortems/ # 事故复盘；反哺标准、门禁、平台能力和 playbook\n│ └── playbooks/ # 运行手册；只放通用流程，不放某个服务的部署细节\n│ └── ai-incident-playbook.md # AI 专属事件响应：幻觉、工具失控、RAG 污染、模型降级\n│\n├── infra/ # 运行底座真相源：云资源、Kubernetes、GitOps、网络和灾备\n│ ├── cloud/ # 云账号、区域、VPC、IAM、基础资源和 IaC\n│ ├── kubernetes/ # Kubernetes base manifest、集群策略和可复用运行对象\n│ │ ├── base/ # 环境无关 base；Deployment、Service、HPA、PDB、NetworkPolicy\n│ │ │ └── services/\n│ │ └── policies/ # 集群准入、Pod 安全、网络、镜像验签等策略\n│ ├── gitops/ # 环境级期望状态；声明 dev/staging/prod 部署什么版本\n│ │ └── environments/\n│ │ ├── dev/ # 开发环境 overlay；低副本、宽松配额、实验性配置\n│ │ ├── staging/ # 预发环境 overlay；接近生产，验证发布和数据迁移\n│ │ └── prod/ # 生产环境 overlay；镜像 digest、replicas、资源、灰度策略\n│ ├── networking/ # DNS、Ingress/Gateway、Service Mesh、网络策略\n│ ├── databases/ # 数据库实例、备份、参数、迁移和访问入口\n│ ├── vector-databases/ # 向量数据库和索引服务运行配置\n│ ├── feature-stores/ # 在线/离线特征存储运行配置\n│ ├── model-serving/ # 模型服务、GPU、推理网关和扩缩容配置\n│ ├── messaging/ # Kafka、Pulsar、队列、topic 和消费组基础配置\n│ ├── storage/ # 对象存储、文件存储、生命周期和加密配置\n│ ├── secrets/ # Secret 引用和外部密钥系统绑定；不保存明文密钥\n│ ├── disaster-recovery/ # 备份、恢复、跨区容灾和演练脚本\n│ └── environments/ # 环境公共变量、命名空间、配额和环境级规则\n│\n├── shared/ # 极薄共享层：无业务语义的库、SDK、测试夹具\n├── tools/ # 开发工具、代码生成、迁移工具\n├── scripts/ # 仓库控制面：本地开发、CI、生成、发布、迁移和质量门禁入口\n│ ├── README.md # 脚本总索引：分类、入口、运行方式和风险边界\n│ ├── AGENTS.md # Agent 操作边界：可自动跑、需确认和禁止执行的脚本\n│ ├── manifest.yml # 脚本登记表：owner、类型、风险、输入、输出和 CI 状态\n│ ├── checks/ # 只读质量门禁：lint、link、schema、security、policy\n│ ├── generate/ # 写仓库的生成/同步脚本：TOC、schema、代码生成、索引重建\n│ ├── bootstrap/ # 环境准备、工具安装、版本探测和依赖缓存\n│ ├── ci/ # CI 适配层；只做编排，不承载核心逻辑\n│ ├── release/ # 发布、版本、打包和 changelog；高风险\n│ ├── ops/ # 迁移、修复和一次性维护脚本；必须支持 dry-run 和审计\n│ ├── dev/ # 本地开发便利脚本；不默认进入硬门禁\n│ ├── lib/ # 共享库；导入无副作用\n│ ├── fixtures/ # 脚本测试数据\n│ ├── tests/ # 脚本自身测试\n│ └── archive/ # 已下线脚本；保留原因、替代入口和删除日期\n├── tests/ # 跨域集成测试、契约测试和仓库门禁\n├── docs/ # 人类可读文档，不替代 contracts/catalog/governance\n└── .github/ or ci/ # CI 工作流入口\n```\n\n目录边界判断：\n\n| 目录 | 真相类型 | 不应承载 |\n| ---- | -------- | -------- |\n| `apps/` | 用户体验和渠道交付真相 | 领域核心规则、领域数据库访问 |\n| `ai/` | AI 应用、Agent、RAG、Prompt、评估和模型接入真相 | 领域核心规则、未经治理的直接数据访问 |\n| `domains/` | 业务能力、领域模型、领域服务和数据产品真相 | 平台通用工具、跨域集中审批 |\n| `platform/` | 内部开发者体验和自助工程能力真相 | 业务规则和领域模型 |\n| `contracts/` | API、事件、Schema、数据集、AI 工具和策略契约真相 | 普通说明文档 |\n| `catalog/` | 系统、组件、资源、AI 产品、owner 和生命周期真相 | 运行逻辑 |\n| `governance/` | 标准、决策、门禁、风险和复盘真相 | 业务代码 |\n| `infra/` | 云资源、运行环境、安全、网络和灾备真相 | 业务逻辑 |\n| `shared/` | 无业务语义的薄复用真相 | 领域模型和业务流程 |\n| `scripts/` | 仓库自动化入口、质量门禁和维护操作真相 | 业务规则、生产配置、长期平台产品逻辑 |\n\n这套目录结构的核心不是“所有企业都必须照抄这些文件夹”，而是把不同生命周期、不同 owner、不同风险等级的资产分开。目录名可以变，职责边界不能变。\n\n### 2.1.1 目录设计的四个判断问题\n\n新增任何目录或文件前，先回答四个问题：\n\n1. 这个资产的 owner 是谁：业务流团队、领域团队、平台团队、SRE、安全、数据治理还是架构治理委员会。\n2. 这个资产的变更频率是什么：随业务每天变、随发布变、随环境变、随治理周期变，还是只在架构决策时变。\n3. 这个资产的消费方是谁：人类开发者、CI/CD、Developer Portal、Kubernetes、审计系统、数据平台还是 AI Runtime。\n4. 这个资产是不是可执行真相源：能否被校验、生成、部署、路由、授权、审计或阻断发布。\n\n如果一个文件同时被多个团队频繁修改、同时服务人类阅读和机器执行、同时表达业务规则和部署细节，通常说明它放错了位置，或者需要拆成契约、实现、部署、目录和治理五类资产。\n\n### 2.1.2 核心目录的深度职责\n\n| 目录 | 主要 owner | 典型变更触发 | 机器消费方 | 深度说明 |\n| ---- | ---------- | ------------ | ---------- | -------- |\n| `apps/` | 体验团队 / 业务流团队 | 新渠道、新页面、新用户流程、A/B 实验 | CI、前端发布平台、观测系统 | 只承载体验交付和体验编排。它可以调用 BFF、API、工作流和 AI 体验入口，但不拥有领域事实，不直接读写领域数据库。 |\n| `ai/` | AI 产品团队 / AI 平台团队 | Prompt 发布、Agent 工具变更、RAG 索引更新、模型路由调整、评估门禁变化 | LLM Gateway、Agent Runtime、Evals、观测系统 | 管 AI 产品的运行资产。这里可以声明 Agent、Prompt、RAG、工具、评估、护栏和微调运行证据，但 AI 层不是新的业务真相源，不能绕过领域 API、数据产品和权限边界。 |\n| `domains/` | 领域团队 / Stream-aligned Team | 领域模型变化、业务服务发布、API/事件契约变化、数据产品发布 | CI、契约测试、catalog、数据平台 | 管领域能力产品。领域内可以放服务源码，但不是唯一合法形态；如果服务在独立仓或顶层 `services/`，必须通过 `service.yaml` 和 `catalog/components` 指回领域 owner、API、事件、数据产品和 GitOps 路径。 |\n| `platform/` | 平台团队 / Platform Team | Golden Path 迭代、脚手架升级、流水线模板升级、平台 API 变化 | Developer Portal、脚手架、CI/CD、准入系统 | 管“如何更容易、更安全地创建和交付”。平台不接管业务服务，也不直接成为每个服务的部署目录；它提供模板、能力、默认路径和自助入口。 |\n| `contracts/` | 契约 owner + 治理 owner | API、事件、数据、AI 工具、资源和策略契约变更 | CI、兼容性检查、代码生成、网关、策略引擎 | 管跨团队协作的机器契约。凡是会影响消费者、权限、兼容性、数据质量或发布准入的接口，都应能在这里或领域内等价位置找到机器可读契约。 |\n| `catalog/` | 平台团队 + 各资产 owner | 新服务、新 API、新数据产品、新 AI 产品、新资源登记 | Developer Portal、Scorecard、审计导出、依赖图 | 管“这是什么、谁负责、在哪里、依赖谁、成熟度如何”。catalog 是发现入口，不是源码仓、不是真实部署状态，也不是运行配置中心。 |\n| `governance/` | 架构治理 / 安全 / 数据治理 / 合规 | 标准变化、ADR、风险登记、例外审批、门禁升级、复盘反哺 | CI、审计系统、Policy as Code、评审流程 | 管规则、决策和证据。治理资产必须尽量机器可读：门禁、风险、例外、控制项、POA&M、ADR、证据账本都应能被自动校验或导出。 |\n| `infra/` | 平台工程 / SRE / 环境 owner | 环境变更、容量调整、镜像版本发布、集群策略、灾备演练 | GitOps、Kubernetes、云平台、观测系统 | 管运行底座和环境期望状态。它不拥有业务逻辑；它回答“跑在哪里、跑几个、用哪个 digest、什么资源、什么策略、什么发布方式”。 |\n| `shared/` | 平台团队或共享库 owner | 通用 SDK、测试夹具、无业务语义工具升级 | 编译、测试、代码生成 | 只能放薄复用能力。若共享代码开始表达订单、客户、支付、履约等业务概念，应回到对应领域，不应把 `shared/` 演化成隐形中台。 |\n| `scripts/` | 平台工程 / DevEx / SRE / 治理脚本 owner | 质量门禁新增、生成器升级、发布脚本调整、一次性维护任务 | Make、CI、本地开发环境、审计导出 | 管仓库自动化入口。脚本不是杂物间，而是把本地开发、CI、生成、发布、迁移和质量门禁变成可复现、可审计、可维护的控制面。 |\n\n### 2.1.3 单仓、多仓和混合仓的落地方式\n\n推荐目录结构可以映射到三种仓库拓扑：\n\n| 拓扑 | 适用场景 | 推荐做法 | 风险控制 |\n| ---- | -------- | -------- | -------- |\n| 单仓 Monorepo | 团队协作强、统一门禁成熟、需要跨域重构和统一发布证据 | 保留上述目录，所有资产在一个仓库内通过 CODEOWNERS、路径门禁和 CI 分层校验 | 必须避免所有团队都能随意改所有目录；按 `domains/`、`platform/`、`infra/`、`governance/` 切 owner 和审批规则 |\n| 多仓 Polyrepo | 服务高度自治、权限隔离强、团队发布节奏差异大 | 服务源码在各服务仓；中心仓保留 `contracts/`、`catalog/`、`governance/`、`platform/`、`infra/gitops/` 或用自动同步生成 | 必须用 catalog 记录 `sourceRoot`、`gitopsPath`、owner、API、事件、SLO、证据路径，避免服务失联 |\n| 混合仓 Hybrid | 企业最常见；平台、治理、GitOps 集中，领域服务部分集中、部分独立 | 领域核心契约、catalog、治理和 GitOps 集中；服务源码按团队成熟度放 `domains/*/services/*` 或独立服务仓 | 必须明确哪一份是契约真相源，避免中心仓和服务仓同时维护同一契约导致漂移 |\n\n是否把源码放在 `domains/*/services/*`，取决于仓库拓扑，而不是架构原则本身。架构原则只要求每个服务都能被追溯到：\n\n```text\n领域 owner -> 服务源码 -> API / Event 契约 -> 镜像构建定义 -> 制品 digest -> GitOps 期望状态 -> 运行观测 -> 审计证据\n```\n\n如果服务源码不在 `domains/*/services/*`，至少要在以下位置声明反向索引：\n\n```yaml\nservice: customer-profile-service\ndomain: customer\nowner: team-customer\nsourceRoot: https://git.example.com/customer/customer-profile-service\ncatalogComponent: catalog/components/customer-profile-service.yaml\ngitopsPath: infra/gitops/environments/prod/customer/customer-profile-service\napis:\n - contracts/apis/customer-profile.openapi.yaml\nevents:\n publishes:\n - contracts/events/customer.profile.updated.asyncapi.yaml\n```\n\n### 2.1.4 文件放置决策表\n\n| 要放的东西 | 推荐位置 | 不推荐位置 | 原因 |\n| ---------- | -------- | ---------- | ---- |\n| 服务源码 | `domains/{domain}/services/{service}/` 或独立服务仓并在 catalog 声明 | `platform/`、`infra/` | 服务属于领域能力，不属于平台模板或环境配置 |\n| Dockerfile / Containerfile | 服务源码目录 | `infra/gitops/` | Dockerfile 描述如何构建运行单元，不描述某环境部署哪个版本 |\n| 生产镜像版本 | `infra/gitops/environments/prod/...` 使用 digest | `domains/*/services/*` | 生产运行期望状态由环境 owner 管，不应由源码目录暗含 |\n| OpenAPI / AsyncAPI | `contracts/` 或 `domains/*/apis`、`domains/*/events` | `docs/` | 契约要能被 CI、网关、代码生成和兼容性检查消费 |\n| 数据产品契约 | `domains/*/data-products/` 和 `contracts/datasets/` | BI 报表目录 | 数据产品是可治理资产，不只是报表输入 |\n| RAG 索引契约 | `contracts/ai/`、`ai/rag/` | 应用代码常量 | RAG 来源、权限、刷新和删除策略需要审计和回滚 |\n| Prompt 版本 | `ai/prompts/` 或 `contracts/ai/prompts/` | 工程代码硬编码 | Prompt 是可评估、可回滚、可审批资产 |\n| 微调运行证据 | `ai/fine-tuning/`、`governance/evidence/ai/` 或 starter kit 的 `fine-tuning-run.yaml` | 模型平台截图、聊天记录 | 微调必须证明数据授权、实验追踪、评估、登记、审批和回滚 |\n| Kubernetes Deployment | `infra/kubernetes/` 或 `infra/gitops/` | 服务源码目录作为唯一真相 | Deployment 是环境期望状态，和服务构建定义生命周期不同 |\n| 服务 owner 和依赖关系 | `catalog/components/` + `domains/*/domain.yaml` | README 手写说明 | owner、依赖和生命周期要能被 Developer Portal、审计和 scorecard 消费 |\n| 架构决策 | `governance/decisions/` | 即时聊天记录 | ADR 需要可追溯、可复审、能关联风险和控制项 |\n| 安全例外 | `governance/architecture-gates/` 或 `governance/evidence/` | CI 注释、临时豁免变量 | 例外必须有 owner、到期时间、补偿控制和自动阻断 |\n| 只读质量检查脚本 | `scripts/checks/` 或稳定的 `scripts/check-*.py` 入口 | CI workflow 内联长命令 | 检查逻辑要能本地复现，失败输出要有路径、行号或可定位原因 |\n| 生成、同步和写仓库脚本 | `scripts/generate/` 或稳定的 `scripts/sync-*.py` 入口 | 手工复制、临时 notebook、CI 内联脚本 | 写入脚本必须幂等，运行后能通过 diff、测试和审计输出验证 |\n\n### 2.1.5 最小可执行落地包\n\n如果企业不能一次性建立完整目录，最低也要先落下以下资产：\n\n```text\ndomains/{domain}/domain.yaml # 领域边界、owner、SLO 和上下游\ndomains/{domain}/services/{service}/ # 服务源码或 sourceRoot 指针\ncontracts/apis/ # 对外 API 契约\ncontracts/events/ # 跨域事件契约\ncontracts/ai/ # AI 工具、RAG、Prompt、微调和评估契约\ncatalog/components/ # 服务发现、owner、生命周期和 GitOps 路径\ncatalog/data-products/ # 数据产品发现和 owner\ncatalog/ai-products/ # AI 产品发现、风险等级和证据路径\ninfra/gitops/environments/ # 环境期望状态\nplatform/golden-paths/ # 标准创建和交付路径\ngovernance/standards/ # 标准\ngovernance/decisions/ # ADR\ngovernance/architecture-gates/ # 发布门禁\ngovernance/evidence/ # 审计和验证证据\nscripts/checks/ # 本地和 CI 共用的只读质量门禁\nscripts/lib/ # 多个脚本共享的无副作用辅助库\n```\n\n这个最小包能先回答企业落地最关键的问题：\n\n1. 谁拥有这个能力。\n2. 能力的源码在哪里。\n3. 它对外承诺什么契约。\n4. 它部署到哪里、用哪个版本。\n5. 它是否满足发布门禁。\n6. 它的风险、例外、决策和证据在哪里。\n\n### 2.1.6 字段级真相源矩阵\n\n目录结构真正落地时，最容易出问题的不是目录名，而是同一个字段被多处维护。以下字段必须有明确主责位置：\n\n| 字段或信息 | 权威真相源 | 允许的派生位置 | 冲突时以谁为准 |\n| ---------- | ---------- | -------------- | -------------- |\n| 领域 owner、领域边界、领域 SLO | `domains/{domain}/domain.yaml` | `catalog/domains/`、治理评审报告 | `domain.yaml` |\n| 服务 owner、生命周期、runbook | `domains/*/services/*/service.yaml` 或服务仓同名契约 | `catalog/components/`、Developer Portal | `service.yaml` |\n| 服务源码位置 | 服务仓路径或 `domains/*/services/*` | `catalog/components/*.yaml` 的 `sourceRoot` | 实际 Git 源码仓 |\n| 镜像构建方式 | 服务目录 `Dockerfile` / `Containerfile` | 平台脚手架、CI 模板 | 服务目录构建定义 |\n| 镜像制品 digest | Container Registry / provenance | `infra/gitops/`、发布证据 | registry digest + provenance |\n| prod 部署版本、replicas、资源限制 | `infra/gitops/environments/prod/...` | catalog 运行摘要、观测面板 | GitOps 期望状态 |\n| API 契约 | `contracts/apis/` 或 `domains/*/apis/` | API portal、catalog/apis | 机器可读 OpenAPI / GraphQL 契约 |\n| 事件契约 | `contracts/events/` 或 `domains/*/events/` | 事件目录、消息平台 UI | 机器可读 AsyncAPI / Schema 契约 |\n| 数据产品口径、质量、访问策略 | `domains/*/data-products/` + `contracts/datasets/` | catalog/data-products、数据目录 | 数据产品契约 |\n| Prompt、RAG、工具和评估契约 | `ai/` + `contracts/ai/` | catalog/ai-products、AI 观测面板 | 版本化 AI 契约 |\n| 微调数据授权和运行证据 | `ai/fine-tuning/` 或 `governance/evidence/ai/` | starter kit、模型登记系统 | `fine-tuning-run` 证据 |\n| 发布门禁、例外和风险接受 | `governance/architecture-gates/`、`risk-register/`、`evidence/` | PR 评论、审计导出 | 治理证据 |\n\n冲突处理原则：\n\n1. 机器可读契约优先于自然语言说明。\n2. 环境级 GitOps 配置优先于服务默认值。\n3. catalog 负责发现和索引，不能覆盖源码、契约和部署真相。\n4. governance 可以阻断发布、记录例外和要求补偿控制，但不应成为业务字段的日常编辑入口。\n5. README 只能解释，不应成为唯一事实来源；凡是影响发布、权限、兼容性、审计和运行状态的字段，都应进入可校验文件。\n\n### 2.1.7 典型变更链路\n\n目录结构要服务真实工作流。以下三条链路是企业落地时最需要固定的路径。\n\n新建生产微服务：\n\n```text\n领域建模\n-> domains/{domain}/domain.yaml 声明边界和 owner\n-> domains/{domain}/services/{service}/ 或独立服务仓创建源码\n-> service.yaml 声明端口、依赖、SLO、资源诉求和镜像仓库\n-> contracts/apis 与 contracts/events 声明外部协作契约\n-> catalog/components 注册服务和 sourceRoot/gitopsPath\n-> CI 构建镜像、生成 SBOM、provenance、签名和漏洞扫描证据\n-> infra/gitops/environments/{env}/... 声明部署版本和运行策略\n-> governance/evidence 记录生产就绪、发布证据和例外\n```\n\n发布数据产品：\n\n```text\n领域确认数据语义\n-> domains/{domain}/data-products/{data-product}.yaml 声明 owner、指标、SLO 和消费者\n-> contracts/datasets/ 声明 Schema、质量规则、访问策略和保留期限\n-> data-platform 接入血缘、质量检查、权限审批和数据目录\n-> catalog/data-products 注册可发现入口\n-> governance/data-governance 记录 PII、授权、例外和复审周期\n```\n\n发布 AI 产品或 Agent：\n\n```text\nAI 产品定义\n-> ai/applications 或 ai/agents 声明场景、风险等级、工具权限和人工确认点\n-> ai/prompts、ai/rag、ai/tools、ai/evals 版本化 Prompt、检索、工具和评估\n-> contracts/ai/ 固化工具、RAG、Prompt、评估、微调和护栏契约\n-> model-gateway 配置模型路由、限流、成本预算和降级链路\n-> governance/ai-governance 与 governance/evidence/ai 记录审批、证据账本和微调运行证据\n-> catalog/ai-products 注册 owner、风险等级、运行入口、依赖和 scorecard\n```\n\n这三条链路的共同点是：源码、契约、目录、部署、治理和证据必须串起来。只建目录、不建链路，目录会退化成静态分类；只建链路、不分真相源，系统会在规模扩大后失控。\n\n### 2.1.8 目录拆分和合并规则\n\n目录是否需要独立出来，按以下规则判断：\n\n1. owner 不同就倾向拆分：领域团队、平台团队、SRE、安全、数据治理和 AI 治理不应频繁编辑同一类文件。\n2. 生命周期不同就倾向拆分：源码随业务发布变，GitOps 随环境变，治理标准随审查周期变，审计证据随发布和复审变。\n3. 机器消费方不同就倾向拆分：Kubernetes、CI、Developer Portal、策略引擎、审计导出和人类文档不应依赖同一份非结构化文本。\n4. 风险等级不同就倾向拆分：生产部署、权限策略、模型工具调用、PII 数据、密钥和供应链证据必须有更严格 owner 和门禁。\n5. 没有稳定 owner、没有机器消费方、没有门禁价值的目录不要新增；先放入既有目录，等变更频率和职责边界稳定后再拆。\n6. 一个目录如果开始同时承载业务规则、平台模板、环境部署和治理审批，应立即拆成 `domains/`、`platform/`、`infra/` 和 `governance/`。\n7. 一个共享目录如果出现领域名词，应回到领域；共享层只能放无业务语义的 SDK、工具、测试夹具和生成代码。\n\n### 2.1.9 常见错误\n\n1. 把 `platform/` 做成新的大中台，把业务规则、服务部署和审批流程全部塞进去。\n2. 把 `shared/` 做成跨域业务模型垃圾桶，让多个领域通过共享对象强耦合。\n3. 把 `catalog/` 当部署系统，在目录条目里维护 replicas、资源限制和灰度策略。\n4. 把 `docs/` 当契约真相源，只写自然语言说明，没有 OpenAPI、AsyncAPI、JSON Schema 或策略文件。\n5. 把 `infra/` 当业务仓，在 Helm values 或 Kustomize patch 里隐藏业务开关和业务规则。\n6. 把 AI Prompt、RAG 来源、工具权限和微调审批写在应用代码里，导致无法评估、回滚和审计。\n7. 只有服务仓，没有中心 catalog、契约和治理索引，导致企业无法回答“谁依赖谁、谁负责、风险在哪”。\n8. 把 `scripts/` 当临时杂物间，CI、本地开发、生成、发布和一次性维护脚本混在一起，导致无人敢删、无人敢改、失败不可复现。\n\n### 2.1.10 目录级 owner、审批和门禁\n\n目录结构只有和 owner、审批规则、自动门禁绑定，才会从“文件夹分类”变成“工程治理系统”。推荐按目录设置\nCODEOWNERS、必需检查和变更证据：\n\n| 路径 | 推荐 owner | 最低审批 | 必需门禁 | 变更证据 |\n| ---- | ---------- | -------- | -------- | -------- |\n| `apps/**` | 体验团队 / 业务流团队 | 应用 owner 1 人 | 单元测试、构建、前端质量、可访问性、契约消费检查 | 发布记录、回滚计划、体验指标 |\n| `ai/**` | AI 产品 owner + AI 平台 owner | AI owner 1 人；高风险工具另需治理审批 | Prompt/RAG/Evals、工具权限、成本预算、护栏、AI 事件响应检查 | AI 证据账本、评估报告、模型/Prompt 版本记录 |\n| `domains/{domain}/**` | 对应领域团队 | 领域 owner 1 人；跨域契约需消费者确认 | 领域测试、契约兼容、SLO、数据产品质量、scorecard | domain 变更记录、契约变更记录 |\n| `platform/**` | 平台团队 | 平台 owner 1 人；破坏性 Golden Path 变更需架构复审 | 脚手架测试、模板回归、平台 API 兼容、开发者体验指标 | 平台发布说明、迁移指南 |\n| `contracts/**` | 契约 owner + 消费者代表 | producer 和至少一个 consumer | OpenAPI/AsyncAPI/Schema 兼容、策略测试、breaking change 检查 | 契约版本、兼容性报告 |\n| `catalog/**` | 平台团队 + 资产 owner | 资产 owner 1 人 | catalog schema、owner 存在性、sourceRoot/gitopsPath 可达性 | 目录同步报告、scorecard |\n| `governance/**` | 架构治理 / 安全 / 数据治理 | 治理 owner 1 人；控制项变更需双人审批 | 控制项覆盖、证据新鲜度、风险/POA&M/ADR 链接完整性 | ADR、风险登记、审计导出 |\n| `infra/**` | SRE / 平台工程 / 环境 owner | 环境 owner 1 人；生产变更需 SRE 审批 | GitOps diff、策略准入、镜像验签、资源限制、灾备影响检查 | 变更单、GitOps 同步记录、回滚证据 |\n| `shared/**` | 共享库 owner | owner 1 人；破坏性变更需所有消费者确认 | API 兼容、依赖影响、反向依赖测试 | 版本说明、消费者迁移记录 |\n| `scripts/**` | 平台工程 / DevEx / SRE / 治理脚本 owner | 脚本 owner 1 人；release/ops 高风险脚本需双人审批 | 脚本测试、dry-run、失败输出定位、工具版本锁定、ShellCheck/静态检查 | 脚本登记表、运行日志、生成物 diff、回滚或删除记录 |\n\n最重要的规则是：目录 owner 不是“通知人”，而是对资产正确性、演进节奏和事故后果负责的人。审批不能只看\nMarkdown 是否写得好，而要验证契约、门禁、证据和运行路径是否闭合。\n\n目录级门禁建议分三层：\n\n1. 路径门禁：用 CODEOWNERS、受保护分支、禁止直推和必需检查保护关键目录。\n2. 语义门禁：用 schema、契约兼容、策略测试、scorecard 和风险规则判断内容是否合理。\n3. 证据门禁：要求每次关键变更绑定 ADR、发布证据、审计证据、风险接受或 POA&M 整改记录。\n\n### 2.1.11 目录和企业工具链的映射\n\n企业落地时，不应要求人手工维护所有索引。目录结构应被成熟工具链消费、校验和回写摘要：\n\n| 工具链能力 | 读取的目录 | 写入或生成的资产 | 关键门禁 |\n| ---------- | ---------- | ---------------- | -------- |\n| Developer Portal | `catalog/`、`domains/`、`contracts/`、`governance/scorecards` | 服务地图、API 门户、数据产品目录、AI 产品目录、scorecard | owner、生命周期、依赖、runbook 必填 |\n| CI/CD | `apps/`、`domains/`、`ai/`、`contracts/`、`shared/` | 构建产物、测试报告、SBOM、provenance、发布证据 | 测试、契约兼容、漏洞、签名、质量阈值 |\n| Container Registry | 服务目录构建定义、CI provenance | 镜像 tag、digest、签名、漏洞报告 | 禁止使用未签名镜像进入生产 GitOps |\n| GitOps / CD | `infra/gitops/`、`infra/kubernetes/` | 环境同步状态、漂移报告、发布历史 | production 使用 digest、策略准入、回滚路径 |\n| API Gateway | `contracts/apis/`、`catalog/apis/` | 路由、鉴权、限流、审计日志 | OpenAPI 合法、权限策略存在、breaking change 受控 |\n| Event Platform | `contracts/events/`、`catalog/` | topic、schema registry、消费者拓扑 | 事件兼容、owner、保留期限、PII 标记 |\n| Data Platform | `domains/*/data-products/`、`contracts/datasets/` | 数据目录、血缘、质量报告、访问审批 | 质量 SLO、PII、保留期限、授权边界 |\n| AI Platform | `ai/`、`contracts/ai/`、`catalog/ai-products/` | Prompt 版本、RAG 索引、评估结果、模型路由 | Evals、Guardrails、预算、人工确认点 |\n| Observability | `catalog/`、`service.yaml`、`domain.yaml`、`infra/` | SLO、仪表盘、告警、错误预算 | owner、SLO、日志/指标/链路追踪接入 |\n| GRC / Audit | `governance/`、控制目录、`evidence/`、starter kit | 控制评估、审计导出、POA&M、风险视图 | 证据新鲜度、控制覆盖、签署状态 |\n| Repository Automation | `scripts/`、`Makefile`、`.github/` 或 `ci/` | 校验报告、生成物 diff、审计导出摘要、发布或迁移执行记录 | 脚本登记、入口稳定、工具版本锁定、dry-run、失败可定位 |\n\n这张映射的意义是把目录从“人看的结构”升级为“工具能执行的接口”。如果某个目录没有稳定 owner、没有工具消费、\n没有门禁和证据输出，就不应被列为企业级标准目录。\n\n### 2.1.12 从现有项目迁移到目标结构\n\n迁移不要从重命名目录开始，而要先找真相源、定 owner、补契约，再逐步移动文件。推荐路径如下：\n\n| 阶段 | 目标 | 动作 | 禁止误区 |\n| ---- | ---- | ---- | -------- |\n| L0 盘点 | 看清现状 | 列出服务、API、事件、数据库、数据产品、AI 资产、部署路径、owner 和证据位置 | 直接批量移动目录，导致 CI、部署和文档同时失效 |\n| L1 索引 | 先能发现 | 建 `catalog/`，为每个服务、数据产品、AI 产品和资源建立 owner、sourceRoot、gitopsPath | 把 catalog 当新的手工台账，不接 CI 和 portal |\n| L2 契约 | 先稳边界 | 把 OpenAPI、AsyncAPI、数据产品、AI 工具和策略契约迁入 `contracts/` 或领域内等价位置 | 只迁 README，不迁机器可读契约 |\n| L3 部署 | 分离运行状态 | 把环境级部署期望状态收敛到 `infra/gitops/`，生产使用镜像 digest 和策略准入 | 让服务源码目录同时决定 prod 版本和资源配额 |\n| L4 治理 | 补齐控制 | 增加 `governance/`、ADR、门禁、风险、POA&M、证据和目录级 owner | 只增加审批流程，不增加自动校验和证据 |\n| L5 平台化 | 降低认知负载 | 用 `platform/golden-paths`、脚手架、portal 和 scorecard 把标准路径产品化 | 让每个团队手写一套不同模板和检查脚本 |\n\n迁移期间可以长期保持混合形态：新服务走目标结构，旧服务通过 catalog 指针接入。真正要避免的是同一事实在旧目录和新目录\n双写。任何双写字段都必须有主真相源、派生方向和漂移检查。\n\n### 2.1.13 目录结构验收清单\n\n一套目录结构是否合格，不看目录名是否“先进”，看它能否稳定回答以下问题：\n\n1. 每个服务是否能找到领域 owner、源码位置、契约、GitOps 路径、SLO、runbook 和最近一次发布证据。\n2. 每个 API 和事件是否有机器可读契约、兼容规则、消费者影响面和 breaking change 流程。\n3. 每个数据产品是否有 owner、语义口径、质量规则、访问策略、PII 标记、血缘和复审周期。\n4. 每个 AI 产品是否有 Prompt/RAG/工具/模型/评估/护栏/预算/人工确认点/事件响应证据。\n5. 每个生产部署是否由 GitOps 管理，并明确镜像 digest、资源限制、HPA、策略准入和回滚路径。\n6. 每个共享库是否能证明没有承载领域业务语义，并有反向依赖测试和破坏性变更流程。\n7. 每个治理控制项是否能映射到 schema、示例、checker、证据路径和审计导出结果。\n8. 每个目录是否有 CODEOWNERS、必需检查、变更证据和定期 owner 复核。\n9. 每个关键字段是否只有一个权威真相源，catalog 和文档是否只是派生视图或说明。\n10. 每个仓库脚本是否能找到 owner、风险等级、入口命令、输入输出、失败契约、dry-run 或删除路径。\n11. 新人能否通过 Developer Portal 或 catalog 在 10 分钟内找到某个能力的 owner、契约、运行状态和风险。\n\n如果以上问题无法回答，说明目录只是“看起来现代”，还没有形成可运营、可审计、可演进的企业架构骨架。\n\n### 2.1.14 服务源码组织的合法形态\n\n`domains/{domain}/services/{service}/` 是推荐默认值，不是唯一正确答案。它的优点是领域边界、服务源码、API、\n事件、数据产品和 owner 放在同一上下文里，新人容易理解“这个服务为什么存在”。但企业真实落地时，源码位置往往受\n团队历史、权限隔离、构建系统、语言生态和发布节奏影响。判断一个服务放得对不对，不看目录名字，而看服务能否稳定\n接入领域、契约、catalog、GitOps、治理和审计链路。\n\n常见形态如下：\n\n| 形态 | 示例路径 | 适用场景 | 必须补齐的索引 |\n| ---- | -------- | -------- | -------------- |\n| 领域内服务 | `domains/customer/services/customer-profile-service/` | 单仓或领域仓；领域团队对模型、服务和契约端到端负责 | `service.yaml`、`domain.yaml`、catalog component、GitOps 路径 |\n| 顶层服务目录 | `services/customer-profile-service/` 或 `services/customer/customer-profile-service/` | 历史仓库已有 `services/` 约定；平台工具默认扫描顶层服务 | `service.yaml.domain`、`service.yaml.owner`、catalog component、领域映射 |\n| 语言工作区 | `packages/customer-profile-service/`、`apps/customer-api/` | Node、Go、Java、.NET 等 monorepo workspace 已有生态约定 | workspace package metadata、`service.yaml`、catalog sourceRoot |\n| 独立服务仓 | `git@example.com/customer/customer-profile-service.git` | 多仓自治、权限隔离强、服务发布节奏差异大 | 中心 catalog 的 `sourceRoot`、契约路径、GitOps 路径、证据路径 |\n| 遗留系统适配仓 | `legacy-adapters/customer-mainframe-adapter/` | 旧系统绞杀迁移、主机/ERP/SaaS 集成、反腐层建设 | 领域归属、接口契约、迁移状态、弃用计划、风险登记 |\n\n无论源码放在哪里，都必须满足以下不变量：\n\n```yaml\nservice: customer-profile-service\ndomain: customer\nowner: team-customer\nsourceRoot: domains/customer/services/customer-profile-service\nruntimeUnit: container\nbuildDefinition: Dockerfile\ncatalogComponent: catalog/components/customer-profile-service.yaml\ngitopsPath: infra/gitops/environments/prod/customer/customer-profile-service\napiContracts:\n - contracts/apis/customer-profile.openapi.yaml\neventContracts:\n publishes:\n - contracts/events/customer.profile.updated.asyncapi.yaml\nsloRef: governance/slo/tier-2.yaml\nrunbook: governance/playbooks/customer-profile-service.md\n```\n\n目录名只是线索，不是治理事实。最终权威必须落在机器可读契约里：`service.yaml` 说明服务是谁、怎么构建、依赖什么；\n`domain.yaml` 说明领域边界和 owner；`catalog/components` 提供发现入口；`infra/gitops` 说明生产跑哪个版本；治理证据说明\n能否发布、谁批准、风险是否接受。\n\n### 2.1.15 单个服务目录的最小内部结构\n\n一个服务目录不应只是源码文件夹，而应是“可构建、可测试、可观测、可审计”的运行单元源头。推荐最小结构如下：\n\n```text\ncustomer-profile-service/\n├── README.md # 给人看的服务说明、启动方式、依赖和排障入口\n├── service.yaml # 给机器看的服务契约：owner、domain、端口、依赖、SLO、镜像仓库\n├── Dockerfile # 镜像构建定义；生产使用 digest，不把镜像本体提交进 Git\n├── src/ # 服务源码；具体结构服从语言生态和框架最佳实践\n├── tests/ # 单元测试、组件测试和契约消费测试\n├── apis/ # 服务拥有的本地 API 契约；可同步或引用到 contracts/apis/\n├── events/ # 服务发布/订阅的本地事件契约；可同步或引用到 contracts/events/\n├── migrations/ # 该服务独占数据库的 schema 迁移；跨域共享库禁止放这里\n├── config/ # 非敏感默认配置和本地开发配置；不保存生产密钥\n├── runbooks/ # 服务级操作手册；企业级通用 playbook 仍放 governance/\n└── docs/ # 设计说明、领域补充和局部 ADR 链接\n```\n\n服务目录内允许放“构建和运行这个服务所需的默认事实”，不允许放“某个环境的最终部署事实”。例如端口、健康检查路径、\n依赖声明、最低资源诉求、镜像仓库名称可以放在 `service.yaml`；生产副本数、生产镜像 digest、生产命名空间、生产\nServiceAccount、生产 HPA 阈值应放在 `infra/gitops/environments/prod/...`。\n\n| 内容 | 放服务目录 | 放 GitOps / Infra | 原因 |\n| ---- | ---------- | ----------------- | ---- |\n| 服务源码、测试、Dockerfile | 是 | 否 | 它们描述如何构建服务 |\n| 默认端口、健康检查、依赖声明 | 是 | 可派生 | 它们属于服务运行契约 |\n| 生产镜像 digest | 否 | 是 | 它属于环境期望状态和发布证据 |\n| 生产 replicas、HPA、PDB | 否 | 是 | 它们随环境和容量策略变化 |\n| 明文 Secret | 否 | 否 | 只能保存 Secret 引用和外部密钥绑定 |\n| 跨域数据库访问脚本 | 否 | 否 | 违反领域边界，应改为 API、事件或数据产品协作 |\n\n如果一个服务目录开始承载多个领域的业务规则，说明服务边界过大；如果一个服务目录开始维护生产环境策略，说明源码和\n运行期望状态混在了一起；如果一个服务目录没有 `service.yaml` 或等价契约，说明它还不能被平台和审计系统稳定识别。\n\n### 2.1.16 GitOps 目录的最小内部结构\n\nGitOps 目录回答的是“某个环境期望运行什么”，不是“服务代码是什么”。推荐把环境无关 base、环境 overlay 和环境级\n发布状态分开：\n\n```text\ninfra/\n├── kubernetes/\n│ ├── base/\n│ │ └── services/\n│ │ └── customer-profile-service/\n│ │ ├── deployment.yaml # 环境无关工作负载骨架\n│ │ ├── service.yaml # Kubernetes Service，不等同于业务 service.yaml\n│ │ ├── hpa.yaml # 默认自动扩缩容策略\n│ │ ├── pdb.yaml # 可用性保护\n│ │ ├── network-policy.yaml # 默认网络边界\n│ │ └── kustomization.yaml\n│ └── policies/\n│ ├── image-verification/ # 镜像签名、SBOM、provenance 准入\n│ ├── pod-security/ # Pod 安全基线\n│ └── network/ # 集群网络策略\n└── gitops/\n └── environments/\n ├── dev/customer/customer-profile-service/\n │ └── kustomization.yaml # 开发环境 overlay，可使用短生命周期 tag\n ├── staging/customer/customer-profile-service/\n │ └── kustomization.yaml # 预发环境 overlay，接近生产\n └── prod/customer/customer-profile-service/\n ├── kustomization.yaml # 生产 overlay，必须引用不可变 digest\n ├── rollout.yaml # 金丝雀、蓝绿或渐进式发布策略\n └── release-evidence.yaml # 发布证据索引或指针\n```\n\nGitOps 目录的关键规则：\n\n1. `base/` 只放环境无关模板，不写生产专属镜像版本、命名空间和容量。\n2. `dev/` 可以更灵活，但仍不应绕过镜像扫描和基础策略。\n3. `staging/` 应尽量接近生产，用来验证迁移、发布策略、回滚和观测。\n4. `prod/` 必须使用不可变镜像 digest，禁止只用可变 tag 作为生产准入依据。\n5. GitOps 记录期望状态，实际运行状态由 Kubernetes、Argo CD、Flux 和观测系统提供。\n6. 环境 owner 对 replicas、资源配额、节点选择、灰度策略和回滚窗口负责，服务 owner 对镜像和服务行为负责。\n\n这层拆清楚后，服务团队可以高频提交源码，平台或 SRE 可以稳定治理环境，审计人员可以追溯“哪个 commit 构建了哪个\n镜像、哪个 digest 被部署到哪个环境、哪次 GitOps 同步把它推到生产”。\n\n### 2.1.17 Catalog、service.yaml 和 domain.yaml 的去重规则\n\ncatalog 的价值是发现和索引，不是制造新的手工台账。最稳的做法是让 `domain.yaml`、`service.yaml`、GitOps 和契约文件\n成为字段真相源，catalog 通过同步、生成或校验来汇总。如果必须人工维护 catalog，也必须记录 sourceRef 和 lastSynced，\n并由 CI 检查 catalog 与源契约是否漂移。\n\n| 字段 | 主真相源 | catalog 中的角色 | 漂移处理 |\n| ---- | -------- | ---------------- | -------- |\n| 领域边界、领域 owner | `domains/{domain}/domain.yaml` | 展示领域地图和团队入口 | catalog 不得覆盖；冲突时阻断合并 |\n| 服务 owner、生命周期、运行等级 | `service.yaml` | 展示服务卡片和 scorecard | catalog 只能派生或引用 |\n| 源码位置 | 实际 Git 路径 / `sourceRoot` | 提供跳转入口 | 路径不可达时阻断 catalog 检查 |\n| API / Event 契约 | `contracts/` 或领域内契约 | 提供 API 门户和消费者索引 | 契约缺失或版本不兼容时阻断发布 |\n| GitOps 路径 | `infra/gitops/` | 提供环境入口和发布状态摘要 | catalog 不维护 replicas 和 digest |\n| SLO、runbook、on-call | `service.yaml` + `governance/slo/` | 聚合到服务详情页 | 缺 owner、缺 runbook 或缺 SLO 时降 scorecard |\n| 生产运行状态 | Kubernetes / Argo CD / Observability | 展示只读摘要 | 运行状态不回写为 catalog 真相 |\n\n推荐的同步方向如下：\n\n```text\ndomain.yaml + service.yaml + contracts/* + infra/gitops/*\n -> catalog/components/*\n -> Developer Portal / Scorecard / 审计导出\n```\n\n反方向更新只能用于辅助生成 PR，不能让 portal 表单直接无审查地改写领域契约、生产 GitOps 或治理证据。这样可以避免\n“看起来所有系统都有信息，实际上每个系统都维护一份不同事实”的失控状态。\n\n### 2.1.18 目录级说明文件和 AI 协作边界\n\n企业仓库越来越多由人类、CI、平台机器人和 AI agent 共同维护。目录结构不仅要让人能看懂，也要让自动化工具知道哪里\n能改、哪里不能改、改完要跑什么检查。推荐每个一级目录至少有 `README.md`，需要 AI 或自动化协作的关键目录再补\n`AGENTS.md` 或等价维护说明。\n\n| 文件 | 读者 | 应说明的内容 | 不应承担的职责 |\n| ---- | ---- | ------------ | -------------- |\n| `README.md` | 人类开发者、架构师、审计人员 | 目录用途、入口、常见流程、运行方式、参考链接 | 不作为机器契约唯一来源 |\n| `AGENTS.md` | AI agent、自动化脚本维护者 | 可改范围、禁止事项、验证命令、目录边界、常见坑 | 不保存业务事实和生产状态 |\n| `*.schema.json` | CI、生成器、审计导出 | 字段结构、类型、必填项和扩展边界 | 不解释业务背景 |\n| `*.example.yaml` | 团队落地样例、测试夹具 | 最小可执行字段、跨文件一致性示例 | 不替代真实项目配置 |\n\n目录级说明文件要短、准、可执行。它应该告诉后来者“这个目录为什么存在、谁负责、文件怎么放、改完跑什么门禁”，而不是\n复制主架构文档。主文档说明原则，目录说明文件约束局部行为，schema 和 checker 负责机器验证。\n\n### 2.1.19 不同规模企业的落地深度\n\n目录结构可以分阶段落地，不能为了“看起来完整”一次性铺满所有目录。不同规模的组织应采用不同深度：\n\n| 阶段 | 适用组织 | 必须具备 | 可以暂缓 |\n| ---- | -------- | -------- | -------- |\n| S0 起步 | 少量团队、少量服务 | `domains/`、`contracts/apis/`、`catalog/components/`、`infra/gitops/`、`governance/decisions/` | 完整平台门户、完整审计导出、全量 scorecard |\n| S1 产品化 | 多领域、多服务、开始平台化 | `platform/golden-paths`、`service.yaml`、API/Event 契约、GitOps 环境分层、CODEOWNERS | 复杂 FinOps、全量 OSCAL、自动化证据新鲜度 |\n| S2 规模化 | 多业务线、多团队、多环境 | Developer Portal、数据产品目录、AI 产品目录、供应链证据、风险/POA&M、scorecard | 少数低风险遗留系统可通过 catalog 指针接入 |\n| S3 受监管 | 金融、医疗、政企、关键基础设施 | 审计导出、控制评估、签名验签、访问复核、证据新鲜度、事故复盘、合规映射 | 手工例外必须有到期和补偿控制 |\n\n阶段越早，越要避免目录过度复杂；阶段越成熟，越要避免事实散落在聊天记录、平台 UI、人工表格和个人经验里。成熟度提升的\n标志不是目录变多，而是更多关键事实可以被机器校验、被 portal 发现、被审计导出、被运行系统证明。\n\n### 2.1.20 目录变更评审清单\n\n新增、移动或删除目录时，必须先回答以下问题，再进入执行：\n\n1. 这个目录是否有明确 owner；如果没有 owner，不应新增。\n2. 这个目录是否承载新的真相源；如果只是分类更好看，不应新增。\n3. 这个目录的机器消费方是谁；如果没有 CI、portal、GitOps、策略引擎或审计消费方，应先放入现有目录。\n4. 这个目录是否会和已有目录维护同一字段；如果会，必须定义主真相源和派生方向。\n5. 这个目录是否需要 CODEOWNERS、分支保护、必需检查或发布证据；如果需要，必须同步补门禁。\n6. 这个目录是否影响现有服务、契约、GitOps 或审计导出；如果影响，必须补迁移计划和回滚路径。\n7. 这个目录是否降低团队认知负载；如果只是增加文件层级和审批步骤，应回到平台产品化设计。\n\n目录变更的验收不应只看“文件移动完成”。真正完成的标准是：旧路径有迁移说明，新路径有 owner 和说明文件，相关契约、\ncatalog、GitOps、治理证据和自动化检查都能找到新位置，并且没有同一事实在新旧路径双写。\n\n### 2.1.21 目录结构的三类事实\n\n企业级目录结构不是简单的文件分类，而是在仓库中表达三类事实：权威事实、派生事实和观察事实。把这三类事实混在一起，\n是目录越做越乱的根因。\n\n| 事实类型 | 定义 | 典型位置 | 变更方式 | 校验方式 |\n| -------- | ---- | -------- | -------- | -------- |\n| 权威事实 | 某个字段或行为的唯一真相源 | `domains/`、`contracts/`、`infra/gitops/`、`governance/` | 通过 PR、owner 审批和门禁修改 | schema、contract test、policy check、CODEOWNERS |\n| 派生事实 | 从权威事实生成或同步出来的索引、视图、门户卡片 | `catalog/`、Developer Portal、审计导出包 | 自动生成或受控同步 | 漂移检测、sourceRef、lastSynced |\n| 观察事实 | 运行系统在某一时刻观测到的实际状态 | Kubernetes、Argo CD、Flux、Observability、SIEM | 由运行系统产生，不手写入 Git | SLO、告警、运行探针、审计日志 |\n\n因此，`catalog/components/customer-profile-service.yaml` 可以展示生产环境当前状态摘要，但不能成为生产副本数、镜像 digest\n或资源配额的权威来源；`docs/` 可以解释领域设计，但不能替代 `domain.yaml`、OpenAPI、AsyncAPI 或数据产品契约；平台\n门户可以提供修改入口，但最终仍应生成 PR，由对应权威目录完成审查、合并、部署和审计。\n\n判断某个字段应该放在哪里时，优先使用以下规则：\n\n1. 会直接改变业务行为的字段，放领域或 AI 产品的权威契约中。\n2. 会直接改变生产运行状态的字段，放 `infra/gitops/` 或环境 IaC 中。\n3. 会改变跨团队兼容性的字段，放 `contracts/` 或领域内等价契约中。\n4. 会改变准入、风险、合规或例外处理的字段，放 `governance/` 中。\n5. 只用于发现、导航、搜索和聚合展示的字段，放 `catalog/`，并指向权威来源。\n6. 只用于解释背景、设计原因和操作说明的内容，放 `docs/` 或局部 `README.md`。\n\n### 2.1.22 目录与自动化链路\n\n成熟的目录结构必须能被工具链消费。否则它只是“看起来整齐”的文档目录，无法形成平台能力。\n\n```text\nservice.yaml / domain.yaml / contracts/*\n -> CI 契约校验\n -> catalog 同步\n -> Developer Portal 展示\n -> scorecard 评分\n -> release gate 准入\n -> audit export 证据导出\n\nDockerfile / SBOM / provenance / signature\n -> CI 构建\n -> registry 入库\n -> 镜像签名和验签\n -> GitOps 引用 digest\n -> Kubernetes 准入控制\n\ninfra/gitops/environments/*\n -> Argo CD / Flux 同步\n -> runtime 状态观测\n -> SLO 和告警\n -> 事故响应和回滚证据\n\ngovernance/* / 控制目录 / evidence/*\n -> policy check\n -> risk register / POA&M\n -> audit package\n -> 管理层例外和复核\n```\n\n每个一级目录都应至少接入一种自动化消费方：\n\n| 目录 | 最低自动化消费方 | 未接入时的风险 |\n| ---- | ---------------- | -------------- |\n| `apps/` | CI、发布系统、前端监控 | 体验变更无法和 API、SLO、回滚证据关联 |\n| `ai/` | Evals、LLM Gateway、AI observability | Prompt、Agent 和工具权限变成手工配置，无法审计 |\n| `domains/` | 契约测试、服务构建、catalog 同步 | 领域边界停留在文档，服务和 owner 容易漂移 |\n| `platform/` | 脚手架、portal、scorecard | 平台只是一组散装脚本，不能降低认知负载 |\n| `contracts/` | 兼容性检查、代码生成、网关、策略引擎 | 跨团队协作依赖口头约定，breaking change 难以及时发现 |\n| `catalog/` | Developer Portal、依赖图、审计导出 | 服务、资源和 owner 无法被统一发现 |\n| `governance/` | 门禁脚本、审计导出、风险工作流 | 标准和例外无法闭环，审计只能补材料 |\n| `infra/` | GitOps、Kubernetes、云平台、准入控制 | 生产状态依赖人工操作，回滚和追责困难 |\n| `scripts/` | Make、CI、pre-commit、审计重放、agent 工具调用 | 自动化散落在本地命令和 workflow 中，失败不可复现 |\n\n目录一旦进入企业级标准，就必须定义“谁消费它”。没有消费方的目录应先作为局部文档或实验目录，不应升级为一级标准目录。\n\n\n\n#### 2.1.22.1 `scripts/` 的仓库控制面治理\n\n成熟企业级项目中的 `scripts/` 不是“临时脚本杂物间”，而是仓库控制面。它负责把本地开发、CI、生成、发布、迁移和质量门禁这些操作变成稳定入口，使同一动作可以在开发机、CI runner、审计重放环境和自动化 agent 中得到一致结果。\n\n`scripts/` 的治理目标：\n\n1. 入口稳定：CI、Makefile、开发者和 agent 调用同一组脚本入口，不在 workflow 中复制长命令。\n2. 逻辑集中：入口脚本保持薄，公共解析、路径发现、格式化、错误输出和校验逻辑进入 `scripts/lib/`。\n3. 风险分层：只读检查、写仓库生成、依赖安装、发布变更和一次性运维必须分开治理。\n4. 可复现：脚本必须声明工作目录、输入、输出、依赖工具版本、环境变量和退出码语义。\n5. 可审计：高风险脚本必须支持 `--dry-run`、输出执行计划、保留日志摘要，并能说明回滚或替代入口。\n6. 可删除：废弃脚本进入 `scripts/archive/` 或直接删除；保留时必须说明替代入口、保留期限和删除条件。\n\n推荐分类如下：\n\n| 分类 | 推荐位置 | 风险等级 | 治理要求 |\n| ---- | -------- | -------- | -------- |\n| 只读检查 | `scripts/checks/` 或 `scripts/check-*.py` | 低 | 不写仓库、不访问生产、失败输出必须可定位 |\n| 生成同步 | `scripts/generate/` 或 `scripts/sync-*.py` | 中 | 幂等、可 diff、运行后接质量门禁 |\n| 环境引导 | `scripts/bootstrap/` | 中 | 锁工具版本、声明缓存位置、不隐式提权 |\n| CI 适配 | `scripts/ci/` | 中 | 只做 CI 环境胶水，不承载核心校验逻辑 |\n| 发布脚本 | `scripts/release/` | 高 | 双人审批、dry-run、tag/版本/制品摘要校验和回滚说明 |\n| 运维维护 | `scripts/ops/` | 高 | 明确目标环境、保护生产、审计日志和人工确认点 |\n| 本地便利 | `scripts/dev/` | 低 | 不作为硬门禁，不影响生产发布语义 |\n| 共享库 | `scripts/lib/` | 中 | 导入无副作用，公共函数小而稳定，有脚本测试覆盖 |\n| 脚本测试 | `scripts/tests/`、`scripts/fixtures/` | 低 | 覆盖成功路径、失败路径、边界输入和 fixture 兼容 |\n\n`manifest.yml` 是脚本目录的最小治理账本。它不替代 README，而是让 CI、审计和 agent 能机械判断一个脚本是否允许自动执行：\n\n```yaml\nscripts:\n - path: scripts/checks/check-links.py\n owner: platform-devex\n type: check\n risk: low\n writesRepository: false\n requiresNetwork: false\n ciRequired: true\n entrypoint: make check-links\n inputs:\n - \"**/*.md\"\n outputs:\n - stdout\n failureContract: \"输出文件路径、行号或可定位的错误原因\"\n```\n\n企业规模较小时，不必一次性创建所有子目录。可以先保留扁平入口，例如 `scripts/check-*.py`、`scripts/sync-*.py` 和 `scripts/lib/`；当脚本数量、风险等级或 owner 差异变大，再按 `checks/`、`generate/`、`release/`、`ops/` 拆分。成熟的标志不是目录更多，而是每个脚本都能被登记、测试、复现、审计和安全下线。\n\n### 2.1.23 资产生命周期和目录字段\n\n服务、API、事件、数据产品、AI 产品、模型、Agent、平台能力和治理控制项都应有生命周期字段。生命周期不清楚，目录就会\n不断堆积僵尸资产。\n\n| 状态 | 含义 | 允许行为 | 必填证据 |\n| ---- | ---- | -------- | -------- |\n| `proposed` | 已提出但未进入生产依赖 | 可评审、可试点，不得被生产消费者强依赖 | owner、目标场景、风险初评、退出条件 |\n| `active` | 正式运行并可被消费者依赖 | 可发布、可扩展、可进入 scorecard | SLO、runbook、契约、GitOps、监控、on-call |\n| `deprecated` | 已宣布弃用但仍需兼容 | 不新增消费者，只允许安全修复和迁移支持 | 替代方案、迁移窗口、消费者清单、到期日 |\n| `retired` | 已退役，不再承载生产职责 | 不允许被部署、调用或列入新依赖 | 下线证据、数据归档、DNS/API/topic 清理记录 |\n| `exception` | 临时偏离标准 | 只能在到期日前带补偿控制运行 | 风险 owner、到期日、补偿控制、POA&M |\n\n推荐在不同资产中统一保留以下字段名，减少跨目录理解成本：\n\n```yaml\nname: customer-profile-service\nlifecycle: active\nowner: team-customer\ndomain: customer\ntier: tier-2\nsourceRoot: domains/customer/services/customer-profile-service\ncontractRefs:\n - contracts/apis/customer-profile.openapi.yaml\ngitopsRefs:\n - infra/gitops/environments/prod/customer/customer-profile-service\nsloRef: governance/slo/tier-2.yaml\nrunbookRef: governance/playbooks/customer-profile-service.md\nriskRefs:\n - governance/risk-register/risk-customer-profile.yaml\nevidenceRefs:\n - governance/evidence/releases/customer-profile-service-2026-06.yaml\n```\n\n字段名可以按企业标准调整，但语义必须稳定。尤其是 `owner`、`lifecycle`、`sourceRoot`、`contractRefs`、`gitopsRefs`、\n`sloRef`、`runbookRef` 和 `evidenceRefs`，应成为 catalog、scorecard、审计导出和 AI agent 协作的公共接口。\n\n### 2.1.24 环境、租户和区域的目录表达\n\n不要把环境差异混进服务源码。服务源码表达“服务是什么”，环境目录表达“它在某个环境如何运行”。多租户、多区域、多云和\n受监管环境尤其要遵守这条边界。\n\n推荐表达方式如下：\n\n```text\ninfra/gitops/environments/\n├── dev/\n│ └── customer/customer-profile-service/\n├── staging/\n│ └── customer/customer-profile-service/\n├── prod/\n│ ├── region-cn-north/customer/customer-profile-service/\n│ └── region-us-east/customer/customer-profile-service/\n└── regulated/\n └── finance/customer/customer-profile-service/\n```\n\n环境目录应管理以下事实：\n\n| 维度 | 应放环境目录 | 不应放服务源码 |\n| ---- | ------------ | -------------- |\n| 容量 | replicas、HPA、资源配额、GPU 配额 | 不同环境的生产容量 |\n| 网络 | namespace、Ingress、Gateway、NetworkPolicy | 生产域名和网络放通细节 |\n| 安全 | ServiceAccount、准入策略、镜像验签、Secret 引用 | 明文密钥和环境权限 |\n| 发布 | digest、灰度策略、回滚窗口、冻结期 | 生产版本选择 |\n| 合规 | 数据驻留、审计日志、加密、备份保留 | 监管环境专属例外 |\n\n如果企业采用多仓 GitOps，也应保持同样结构，只是把 `infra/gitops/` 拆到独立环境仓。服务仓通过 `service.yaml.gitopsRefs`\n或 catalog 指回环境仓路径，不能让服务仓单方面决定生产部署事实。\n\n### 2.1.25 目录结构的常见反模式和修复\n\n| 反模式 | 表现 | 后果 | 修复方式 |\n| ------ | ---- | ---- | -------- |\n| `shared/` 变成业务中台 | 所有领域都把通用业务逻辑塞进共享库 | 领域边界消失，升级牵一发动全身 | 只保留无业务语义工具；业务能力迁回领域服务或领域包 |\n| `platform/` 接管业务部署 | 平台目录里维护每个业务服务的生产配置 | 平台团队成为发布瓶颈，服务 owner 失责 | 平台只提供模板和能力；环境期望状态放 `infra/gitops/` |\n| `catalog/` 手工双写事实 | catalog 里手填 owner、路径、digest、SLO | portal 看起来完整，实际和源码/GitOps 漂移 | catalog 只引用或派生；CI 做 sourceRef 漂移检查 |\n| `docs/` 替代契约 | README 写了 API、事件和数据口径，但无机器契约 | 消费者无法自动发现 breaking change | 建 OpenAPI、AsyncAPI、Schema 和 data contract |\n| `infra/` 混入业务规则 | Helm values 或 Kustomize overlay 写业务开关和领域逻辑 | 运行团队被迫理解业务，回滚风险扩大 | 业务规则回到服务配置或领域策略；环境只管运行差异 |\n| `ai/` 绕过领域边界 | Agent 直接读业务库或直接改核心状态 | AI 层成为隐形超级用户，审计和一致性失控 | Agent 只能通过 API、事件、数据产品和受控工具访问能力 |\n| `governance/` 只有文档没有门禁 | 标准写得完整，但 CI、准入和审计不消费 | 规则无法执行，例外无法关闭 | 为控制项补 schema、checker、evidence 和 owner |\n\n目录治理的原则是：能从结构上消除的混乱，不要靠培训解决；能被机器校验的事实，不要靠人工复核兜底；能由平台默认路径\n生成的模板，不要让每个团队重新手写一遍。\n\n### 2.1.26 2.1 的最终验收标准\n\n评审 2.1 推荐目录结构时，应把问题问到可执行层，而不是停在“目录是否全面”：\n\n1. 任意一个服务，从 catalog 入口能否追到源码、契约、GitOps、SLO、runbook、owner 和发布证据。\n2. 任意一个生产 Pod，能否反向追溯到镜像 digest、SBOM、provenance、签名、构建 commit 和代码 owner。\n3. 任意一个 API breaking change，能否自动识别消费者、触发兼容性门禁，并进入迁移或例外流程。\n4. 任意一个数据产品，能否证明语义口径、质量规则、PII、血缘、访问授权和 AI 使用边界。\n5. 任意一个 AI Agent，能否证明 Prompt 版本、工具权限、RAG 数据源、评估结果、护栏、人工确认点和事故响应路径。\n6. 任意一个治理控制项，能否追到标准、schema、示例、checker、证据、风险、POA&M 和审计导出结果。\n7. 任意一个目录变更，能否说明 owner、消费方、主真相源、派生方向、门禁、迁移方式和回滚方式。\n8. 任意一个高风险脚本，能否证明 owner、风险等级、dry-run、输入输出、执行日志、审批和回滚路径。\n\n如果这些问题可以被自动化工具回答大部分，目录结构就是企业级平台架构；如果只能靠人开会解释，目录结构仍然只是文档草图。\n\n---\n\n## 2.2 微服务容器分层真相源\n\n每个微服务可以被构建成一个或多个容器镜像，但容器能力不应被放进单一目录统一管理。正确做法是按“源码、制品、部署期望状态、实际运行状态、目录发现、平台能力、治理规则”拆分真相源。\n\n| 问题 | 真相源位置 |\n| ---- | ---------- |\n| 服务代码推荐放哪里 | 默认放 `domains/{domain}/services/{service}/`；若采用 `services/*`、`apps/*`、polyrepo 或独立服务仓，必须在 `service.yaml` / catalog 中声明源码路径 |\n| Dockerfile / Containerfile 在哪里 | `domains/{domain}/services/{service}/Dockerfile` |\n| 镜像本体在哪里 | Container Registry / Artifact Registry，不进入 Git 仓库 |\n| 哪个镜像版本部署到 prod | `infra/gitops/environments/prod/...` |\n| Kubernetes Deployment / Service / HPA 在哪里 | `infra/kubernetes/` 或 `infra/gitops/` |\n| 服务属于哪个领域 | `domains/{domain}/domain.yaml` 和 `catalog/components/` |\n| API / Event 契约在哪里 | `contracts/` 或 `domains/*/apis`、`domains/*/events` |\n| CI/CD 模板在哪里 | `platform/ci-cd/` |\n| 服务脚手架在哪里 | `platform/scaffolds/` |\n| 运行标准在哪里 | `governance/standards/` |\n| 当前运行状态在哪里 | Kubernetes / Argo CD / Flux / Observability，不是 Git 文档 |\n\n推荐边界：\n\n```text\n服务源码与镜像构建定义：domains/*/services/* 或 catalog/sourceRoot 指向的服务仓库路径\n镜像制品：container registry\n部署期望状态：infra/gitops/* 或 infra/kubernetes/*\n实际运行调度：Kubernetes\n服务目录与 owner 关系：catalog/*\n平台标准能力：platform/*\n治理规则：governance/*\n```\n\n关键原则：\n\n1. 服务目录是运行单元源头，不是环境部署真相源。\n2. 镜像使用 tag 便于人类识别，生产准入和回滚必须能追溯到 digest。\n3. GitOps 目录声明期望状态，不记录运行时实际状态。\n4. catalog 负责发现、owner、依赖和成熟度，不替代 deployment manifest。\n5. platform 负责模板、流水线、扫描、签名、准入和开发者体验，不接管业务服务部署细节。\n\n## 3. 架构设计原则\n\n### 3.1 业务结果端到端负责\n\n业务流团队不只是提出需求，而是对客户体验、业务指标、服务稳定性和持续优化负责。技术团队不再只是被动交付项目，而是与业务共同运营产品。\n\n### 3.2 领域能力产品化\n\n用户、商品、订单、支付、履约、风控、营销等能力不应只是技术服务，而应作为长期运营的领域产品。每个领域产品都应具备清晰的边界、API、事件、数据产品、SLO 和业务指标。\n\n### 3.3 平台能力自助化\n\n平台团队不替业务团队写业务逻辑，而是提供可复用、可自助、可治理的工程能力，使业务团队可以快速创建服务、申请环境、发布应用、接入监控、配置权限和查看成本。\n\n### 3.4 数据作为产品\n\n数据不再只是中央数据团队统一抽取和加工的结果，而是由最理解业务的领域团队负责发布、解释和治理。数据产品必须可发现、可理解、可信任、可复用、可追责。\n\n### 3.5 治理自动化\n\n治理不应主要依赖人工审批，而应通过平台默认能力、CI/CD 质量门禁、Policy as Code、数据契约、安全扫描、成本规则和可观测性自动执行。\n\n### 3.6 松耦合与清晰边界\n\n系统之间通过标准 API、领域事件、数据契约和服务协议进行协作。禁止跨域直接访问数据库，禁止绕过领域边界调用内部实现。\n\n### 3.7 演进式架构\n\n架构不追求一次性大而全建设，而应通过重点领域、重点平台能力和重点数据产品逐步演进，避免把集中化模式换个名字重做一遍。\n\n### 3.8 AI 原生但不旁路领域边界\n\nAI 应用、Agent 和自动化决策必须建立在领域 API、领域事件、数据产品和受控工具之上。AI 层可以编排、解释、推荐和自动执行低风险动作，但不能直接绕过领域边界读写数据库，也不能把 Prompt、向量索引或 Agent 记忆变成新的业务真相源。\n\n### 3.9 供应链可证明\n\n软件交付不应只检查代码质量和漏洞，还必须证明产物从源码、构建、依赖、镜像、签名到部署的完整链路。生产发布必须能够回答：这个产物由谁构建、基于哪些依赖、生成了什么 SBOM、是否有可验证 provenance、是否经过签名验签和策略准入。\n\n### 3.10 认知负载可管理\n\n平台工程的目标不是堆工具，而是减少业务团队理解和操作底层复杂度的负担。每个 Golden Path、平台产品和治理规则都应检查是否降低团队认知负载；如果平台能力增加了配置、审批和排障复杂度，就必须回到产品化视角重新设计。\n\n---\n\n## 4. 分层架构说明\n\n## 4.1 前台体验层\n\n### 4.1.1 定位\n\n前台体验层直接面向用户、客户、合作方、员工和运营人员，是企业数字化能力的外部表现。\n\n### 4.1.2 主要组成\n\n包括但不限于：\n\n1. Web 网站。\n2. 移动 App。\n3. 小程序。\n4. Open API 门户。\n5. 运营后台。\n6. 合作方门户。\n7. 客服工作台。\n8. 员工工作台。\n9. 智能助手入口。\n\n### 4.1.3 设计要求\n\n前台体验层应重点关注用户体验、渠道一致性、性能、可用性和业务转化。不同渠道可以共享底层领域能力，但不应直接耦合底层领域服务的复杂接口。\n\n### 4.1.4 责任边界\n\n前台团队负责：\n\n1. 客户旅程设计。\n2. 页面与交互体验。\n3. 渠道转化指标。\n4. 前端性能体验。\n5. 前端埋点与用户行为分析。\n6. 与体验编排层的接口协作。\n\n---\n\n## 4.2 体验编排层\n\n### 4.2.1 定位\n\n体验编排层位于前台体验和领域能力之间，负责将多个领域能力组合为适合具体场景的体验接口。\n\n### 4.2.2 主要组成\n\n1. BFF，即 Backend for Frontend。\n2. API Gateway。\n3. GraphQL 网关。\n4. 业务流程编排。\n5. 事件订阅与通知。\n6. 聚合查询服务。\n7. 低代码流程配置。\n8. 场景化 API。\n\n### 4.2.3 设计要求\n\n体验编排层应避免沉淀核心业务规则。核心业务规则应归属于领域能力产品层。体验编排层主要处理渠道适配、接口聚合、流程编排、权限上下文、协议转换和体验优化。\n\n### 4.2.4 禁止事项\n\n1. 禁止将领域核心规则长期堆积在 BFF 中。\n2. 禁止绕过领域 API 直接访问领域数据库。\n3. 禁止通过编排层形成新的集中式共享层。\n4. 禁止将跨域一致性完全依赖同步调用。\n\n---\n\n## 4.3 AI 原生能力层\n\n### 4.3.1 定位\n\nAI 原生能力层位于体验编排、领域能力产品和数据产品网络之间，负责把大模型、Agent、RAG、特征、向量检索和受控工具组合为可运营、可评估、可审计的 AI 产品能力。\n\nAI 层不是一个新的业务真相源。它必须通过领域 API 执行业务动作，通过领域事件感知业务状态，通过数据产品和特征产品获得可解释上下文，通过受治理工具调用完成自动化任务。\n\n### 4.3.2 核心组成\n\nAI 原生能力层包括：\n\n1. AI 应用：智能客服、运营助手、研发助手、风控辅助、销售助手、知识问答和自动化运营。\n2. Agent Runtime：负责 Agent 状态、工具调用、记忆、计划、重试、人工确认和隔离执行。\n3. LLM Gateway：统一模型接入、模型路由、降级、限流、审计、成本控制和输出策略。\n4. RAG 管道：文档摄取、切分、Embedding、索引、召回、重排、引用和上下文组装。\n5. 向量存储：用于知识检索、相似度搜索、多模态检索和语义缓存。\n6. PromptOps：Prompt 模板、版本、变更记录、评测样例、灰度和回滚。\n7. Model Registry：模型、Embedding 模型、重排模型、批准状态、适用场景和风险等级。\n8. Evaluation Pipeline：离线评测、在线评测、回归集、对抗样本、人工标注和质量阈值。\n9. Guardrails：输入输出校验、PII 过滤、越权拦截、敏感动作确认、内容安全和策略执行。\n10. AI Observability：Token、延迟、模型错误、幻觉率、引用命中率、工具调用、成本和用户反馈。\n11. Tool Registry：AI 可调用工具、权限范围、幂等要求、超时、审计和危险等级。\n12. Agent-to-Agent 协议适配：用于多 Agent 协作、任务交接和能力发现，但必须受平台策略约束。\n\n### 4.3.3 AI Mesh 与领域网络关系\n\nAI Mesh 是 AI 能力的分布式协作网络，不是集中式 AI 大脑。企业可以把每个领域中可复用的 AI 能力封装为 AI 产品，让它们通过统一网关、工具契约和治理策略互相协作。\n\n```text\nAI 应用 / Agent\n │\n ├── 调用领域 API：执行查询、创建、审批、取消、补偿等业务动作\n ├── 订阅领域事件：感知订单变化、支付结果、风控结果和履约状态\n ├── 消费数据产品：获取事实数据、聚合指标、标签、人群和业务口径\n ├── 消费特征产品：获取训练和推理一致的实时/离线特征\n ├── 检索向量索引：获取可引用知识、政策、文档、案例和历史记录\n └── 写入审计事件：记录 Prompt、上下文、模型、工具调用、输出和人工确认\n```\n\nAI Mesh 的边界原则：\n\n1. 每个 AI 产品必须有 owner、业务目标、用户、风险等级、评估集和退出机制。\n2. Agent 只能调用注册过的工具，工具必须声明权限、输入输出 Schema、幂等性、超时和审计字段。\n3. AI 层不得直接读写领域数据库，所有业务动作必须经过领域 API 或受控工作流。\n4. RAG 索引不得替代原始数据产品和领域知识库，索引必须可追溯到源文档、版本和授权策略。\n5. 高风险动作必须有人类确认或双人复核，不能只依赖模型自我判断。\n6. AI 产品必须支持灰度、A/B、回滚、降级到非 AI 流程和人工接管。\n\n### 4.3.4 LLM Gateway 契约\n\nLLM Gateway 是模型接入和治理的统一入口，避免各团队在应用里分散配置模型、密钥、成本和审计策略。\n\nLLM Gateway 必须提供：\n\n1. 模型路由：按场景、成本、延迟、质量和合规要求选择模型。\n2. 凭证隔离：应用不直接持有模型供应商密钥。\n3. 限流与预算：按团队、产品、环境、用户和模型设置配额。\n4. 审计记录：记录请求元数据、模型版本、Prompt 版本、Token、工具调用和策略结果。\n5. 降级策略：模型不可用、质量下降或成本异常时切换模型、缩小上下文或进入人工流程。\n6. 内容策略：输入输出过滤、敏感信息识别、越权提示拦截和危险操作阻断。\n7. 可观测性：统一暴露延迟、错误、Token、成本、拒绝率、重试率和质量反馈指标。\n\n### 4.3.5 RAG 与向量索引标准\n\nRAG 管道必须把“可回答”建立在“可追溯”之上。\n\nRAG 标准包括：\n\n1. 摄取源必须登记 owner、授权范围、更新频率、保留期限和数据分级。\n2. 文档切分必须保留源链接、版本、时间、章节、权限标签和业务域。\n3. Embedding 模型变更必须触发索引重建评估，避免召回质量无声下降。\n4. 检索必须支持权限过滤，不能把无权访问的片段放入上下文。\n5. 生成结果必须携带引用或证据来源，关键业务答案必须能回溯到源材料。\n6. 召回、重排、生成和引用命中率必须纳入评估集。\n7. RAG 索引必须支持删除、重建、过期和来源撤销，不能成为隐性数据湖。\n\n### 4.3.6 Prompt、评估和发布门禁\n\nPrompt 和 Agent 工作流属于生产资产，必须像代码一样管理版本和发布。\n\nAI 发布门禁至少包括：\n\n1. Prompt 版本、模型版本、工具版本和检索配置可追溯。\n2. 离线评测集覆盖核心业务问题、边界问题、越权问题、幻觉诱导和成本边界。\n3. 在线评测覆盖用户反馈、人工抽检、引用命中率、任务完成率和负反馈率。\n4. 高风险场景必须有人类确认、回放审计和熔断策略。\n5. 每次模型、Prompt、工具或 RAG 配置变更必须有回归评测。\n6. 低质量输出、异常成本、越权调用、无引用回答和工具失败必须触发告警。\n\n### 4.3.7 AI 产品标准目录\n\nAI 产品必须以机器可读契约进入仓库、catalog 和治理流程。\n\n```text\nai/applications/customer-service-agent/\n├── ai-product.yaml\n├── prompts/\n│ ├── system.prompt.md\n│ └── policy.prompt.md\n├── agents/\n│ └── customer-service-agent.yaml\n├── tools/\n│ └── tool-permissions.yaml\n├── rag/\n│ ├── sources.yaml\n│ ├── chunking.yaml\n│ └── retrieval.yaml\n├── evals/\n│ ├── regression.yaml\n│ ├── adversarial.yaml\n│ └── cost.yaml\n├── guardrails/\n│ └── policy.rego\n├── observability/\n│ └── dashboard.yaml\n└── docs/\n ├── README.md\n └── runbook.md\n```\n\n`ai-product.yaml` 示例：\n\n```yaml\nname: customer-service-agent\nowner: team-customer-experience\nlifecycle: production\nriskTier: high\nusers:\n - customer-service-operators\nbusinessGoal:\n - reduce-average-handle-time\n - improve-first-contact-resolution\nmodelGateway:\n route: support-safe-default\n maxInputTokens: 16000\n maxOutputTokens: 2000\n monthlyBudgetUsd: 3000\ntools:\n allowed:\n - tool:domain:order:get-order-status\n - tool:domain:customer:create-support-ticket\n requiresHumanApproval:\n - tool:domain:payment:refund\nrag:\n sources: rag/sources.yaml\n retrieval: rag/retrieval.yaml\nevals:\n regression: evals/regression.yaml\n adversarial: evals/adversarial.yaml\nguardrails:\n piiPolicy: guardrails/policy.rego\nobservability:\n dashboard: observability/dashboard.yaml\nslo:\n taskCompletionRate: \">= 85%\"\n groundedAnswerRate: \">= 95%\"\n toolErrorRate: \"<= 2%\"\n p95LatencyMs: 6000\n```\n\n### 4.3.8 Agent 协议与工具边界\n\nAgent 协议层应解决“工具如何暴露、上下文如何传递、Agent 如何协作”的互操作问题，但不能替代权限、审计和业务边界。\n\n建议分层：\n\n| 协议层 | 解决问题 | 设计边界 |\n| ------ | -------- | -------- |\n| Tool / Context Protocol | 让模型或 Agent 发现工具、资源、Prompt 和上下文 | 不授予业务权限，只描述可调用能力 |\n| Agent-to-Agent Protocol | 让不同 Agent 进行任务发现、委托、状态同步和结果回传 | 不允许绕过平台网关、审计和风险等级 |\n| Domain API / Workflow | 执行真正业务动作 | 必须由领域团队拥有，并受权限和 SLO 约束 |\n\nAgent 协议治理要求：\n\n1. 所有工具进入 Tool Registry，声明 owner、输入输出 Schema、幂等性、超时、速率限制和危险等级。\n2. Agent 调用工具必须经过 LLM Gateway 或 Agent Runtime 统一审计。\n3. Agent 之间不能直接传递敏感数据，必须保留数据分级、用户权限和用途约束。\n4. 多 Agent 协作必须有任务上限、循环上限、预算上限和人工接管点。\n5. 协议适配器只做连接和编排，不承载领域业务规则。\n\n### 4.3.9 微调治理工作流\n\n微调不是默认选项。只有当 Prompt、RAG、工具调用、检索重排和模型路由无法稳定满足需求，并且业务收益足以覆盖训练、评估、合规和维护成本时，才应启动微调。\n\n微调场景必须单独治理，因为它会把训练数据、模型权重、实验参数和评估结果变成新的生产资产。\n\n推荐工作流：\n\n1. 场景论证：说明为什么 Prompt / RAG / 工具编排不足以解决问题。\n2. 数据授权：声明训练数据来源、owner、分级、PII、版权、保留期限和是否允许用于微调。\n3. 数据准备：记录清洗、脱敏、去重、采样、标签质量和训练/验证/测试划分。\n4. 实验追踪：记录基础模型、超参数、训练配置、数据版本、代码版本、运行环境和成本。\n5. 评估门禁：使用独立评估集验证质量、安全、偏见、幻觉、越权、泄露和成本。\n6. 模型登记：微调模型必须进入 Model Registry，拥有独立版本、风险等级、适用范围和回滚点。\n7. 合规审查：高风险或敏感数据微调必须经过数据、安全、法务或合规负责人确认。\n8. 灰度发布：微调模型先进入小流量或 shadow 评估，再替换生产模型。\n9. 持续监控：监控模型漂移、质量回退、数据泄露、成本异常和用户反馈。\n10. 退役机制：模型过期、数据授权撤销或质量下降时必须支持禁用、回滚和删除。\n\n`fine-tuning-run.yaml` 示例：\n\n```yaml\nname: support-answer-style-tuning\nowner: team-customer-experience\nbaseModel: vendor:model-name:2026-05\nriskTier: R3\nreason: prompt-and-rag-failed-to-meet-tone-consistency\ntrainingData:\n sourceDataProducts:\n - data-product:support:resolved-ticket-dialogs\n classification: confidential\n piiRemoved: true\n allowedUse:\n - supervised-fine-tuning\n disallowedUse:\n - foundation-model-training\nexperimentTracking:\n tracker: mlflow\n experimentId: support-answer-style-tuning-2026-06\n codeVersion: git:abc123\n dataVersion: dataset:v18\nevals:\n quality: evals/support-quality.yaml\n safety: evals/support-safety.yaml\n regression: evals/support-regression.yaml\napproval:\n dataOwner: team-support-data\n securityReviewer: team-security\n modelReviewer: team-ai-platform\ndeployment:\n shadowTrafficPercent: 5\n rollbackModel: vendor:model-name:2026-05\n```\n\n---\n\n## 4.4 领域能力产品层\n\n### 4.4.1 定位\n\n领域能力产品层是企业数字化平台的核心层。它承载企业关键业务能力，并以领域产品的方式长期运营。\n\n### 4.4.2 典型领域划分\n\n企业可根据实际业务划分领域，常见包括：\n\n| 领域 | 主要能力 |\n| ---- | ------------------- |\n| 用户域 | 注册、登录、账户、身份、会员、用户画像 |\n| 商品域 | 商品资料、类目、属性、价格、上下架 |\n| 订单域 | 购物车、下单、订单状态、订单履约协同 |\n| 支付域 | 收款、退款、对账、支付渠道接入 |\n| 履约域 | 库存、仓储、配送、签收、售后 |\n| 风控域 | 交易风控、账户风控、反欺诈、风险评分 |\n| 营销域 | 优惠券、活动、权益、推荐、触达 |\n| 内容域 | 内容生产、审核、发布、标签、分发 |\n| 客服域 | 工单、会话、服务记录、投诉处理 |\n| 合作方域 | 合作方准入、合同、分账、结算 |\n\n### 4.4.3 每个领域产品必须具备的内容\n\n每个领域产品应至少包含：\n\n1. 领域愿景和业务目标。\n2. 领域边界和上下文图。\n3. 业务 API。\n4. 领域事件。\n5. 领域模型。\n6. 服务边界。\n7. 数据产品。\n8. SLO 和运行指标。\n9. 权限模型。\n10. 变更策略。\n11. 版本管理策略。\n12. 领域团队责任人。\n\n### 4.4.4 领域服务交互方式\n\n领域之间优先采用以下方式协作：\n\n1. 同步 API：用于强一致、实时查询或明确请求响应的场景。\n2. 领域事件：用于状态变化通知、异步解耦和最终一致性场景。\n3. 数据产品：用于分析、报表、AI、特征和跨域洞察场景。\n4. 工作流编排：用于跨领域长流程和补偿机制。\n\n### 4.4.5 领域边界原则\n\n1. 一个领域拥有自己的核心模型。\n2. 一个领域拥有自己的核心数据。\n3. 其他领域不能直接读写该领域数据库。\n4. 跨领域协作通过 API、事件或数据产品完成。\n5. 领域团队对业务规则、接口稳定性和运行质量负责。\n\n### 4.4.6 领域产品标准目录\n\n每个领域产品应有稳定目录，确保领域边界、运行责任和接口契约可追踪。\n\n```text\ndomains/order/\n├── domain.yaml\n├── apis/\n│ ├── public.openapi.yaml\n│ └── internal.openapi.yaml\n├── events/\n│ └── order-status-changed.asyncapi.yaml\n├── services/\n│ ├── order-command-service/\n│ ├── order-query-service/\n│ └── order-workflow-worker/\n├── workflows/\n│ └── order-lifecycle.bpmn\n├── data-products/\n│ ├── order-facts/\n│ └── order-status-snapshot/\n├── policies/\n│ ├── access.rego\n│ └── retention.yaml\n├── scorecards/\n│ └── domain-readiness.yaml\n└── docs/\n ├── README.md\n ├── domain-model.md\n ├── runbook.md\n └── decision-log.md\n```\n\n`domain.yaml` 示例：\n\n```yaml\nname: order\ndisplayName: 订单领域\nowner: team-order\nlifecycle: production\nbusinessCapability:\n - order-capture\n - order-lifecycle\n - order-query\nboundedContext:\n upstream:\n - customer\n - product\n - payment\n downstream:\n - fulfillment\n - risk\ninterfaces:\n providesApis:\n - domain:order:orders-public-api\n - domain:order:orders-internal-api\n publishesEvents:\n - domain:order:order-created\n - domain:order:order-status-changed\n ownsDataProducts:\n - data-product:order:order-facts\n - data-product:order:order-status-snapshot\nslo:\n availability: 99.95\n commandLatencyP95Ms: 300\n queryLatencyP95Ms: 200\ngovernance:\n dataClassification: confidential\n pii: true\n architectureGate: tier-1-domain\n```\n\n### 4.4.7 领域服务运行契约\n\n领域服务必须是可以独立启动、停止、测试、部署、扩缩容和回滚的运行边界。\n\n```text\ndomains/order/services/order-command-service/\n├── src/\n├── tests/\n├── deploy/\n├── configs/\n├── service.yaml\n├── catalog-info.yaml\n├── Dockerfile # 或 Containerfile\n├── README.md\n└── AGENTS.md\n```\n\n`service.yaml` 示例：\n\n```yaml\nname: order-command-service\ndomain: order\nowner: team-order\nlifecycle: production\nruntime: service\nentrypoints:\n http:\n port: 8080\n events:\n consumes:\n - domain:payment:payment-authorized\n publishes:\n - domain:order:order-created\ndependencies:\n resources:\n - resource:order-primary-db\n - resource:order-event-topic\n apis:\n - domain:customer:customer-internal-api\ndataAccess:\n owns:\n - order_primary_db\n reads:\n - customer_profile_view\ncontainer:\n dockerfile: Dockerfile\n imageRepository: registry.company.com/order/order-command-service\n tagPolicy: git-sha\n digestRequired: true\n sbomRequired: true\n provenanceRequired: true\n signatureRequired: true\nresources:\n requests:\n cpu: \"500m\"\n memory: \"512Mi\"\n limits:\n cpu: \"2\"\n memory: \"2Gi\"\nslo:\n availability: 99.95\n latencyP95Ms: 300\noperations:\n health: /health\n readiness: /ready\n runbook: docs/runbook.md\n rollback: deploy/rollback.md\n```\n\n### 4.4.8 服务容器化边界\n\n领域服务目录只保存“如何构建和运行这个服务”的源头信息，不保存镜像制品，也不保存每个环境的部署期望状态。\n\n服务团队负责：\n\n1. 服务代码、测试和启动入口。\n2. Dockerfile / Containerfile。\n3. `service.yaml` 中的端口、健康检查、依赖、资源诉求和镜像仓库声明。\n4. 服务级 runbook、rollback 说明和本地调试方式。\n5. 服务 API、事件和数据访问边界。\n\n不应放在服务目录中的内容：\n\n1. 生产镜像本体。\n2. dev、staging、prod 的 Deployment 副本数和镜像 digest。\n3. 环境级 Secret 值。\n4. 集群级准入策略。\n5. Argo CD / Flux 的环境同步状态。\n\n---\n\n## 4.5 数据产品网络层\n\n### 4.5.1 定位\n\n数据产品网络层负责将各领域产生的数据转化为可信、可发现、可理解、可复用的数据产品，为经营分析、业务运营、风险控制、AI 应用、特征服务、向量检索和管理决策提供支撑。\n\n### 4.5.2 数据产品类型\n\n| 类型 | 说明 | 示例 |\n| ----------------------------- | ----------------------- | ----------------- |\n| Source-aligned Data Product | 源对齐数据产品，由领域团队基于原始业务数据发布 | 订单明细数据产品、支付流水数据产品 |\n| Aggregate Data Product | 聚合数据产品，对多个源数据产品进行汇总加工 | 用户交易汇总、商品销售汇总 |\n| Consumer-aligned Data Product | 面向具体消费场景的数据产品 | 经营驾驶舱、风控特征集、营销人群包 |\n\n### 4.5.3 数据产品基本要求\n\n一个合格的数据产品应包含：\n\n1. 数据产品名称。\n2. 业务定义。\n3. 数据拥有者。\n4. 数据使用者。\n5. 数据血缘。\n6. 数据字段说明。\n7. 口径说明。\n8. 更新频率。\n9. 数据质量规则。\n10. 权限与分级。\n11. SLA 或 SLO。\n12. 使用示例。\n13. 变更通知机制。\n14. 下游依赖清单。\n15. AI 消费声明：是否允许用于训练、Embedding、RAG、特征、评估或在线推理。\n16. 训练-推理一致性要求：是否需要离线特征、在线特征和实时推理端点同步校验。\n\n### 4.5.4 数据能力组成\n\n数据产品网络层包括：\n\n1. 数据目录。\n2. 元数据管理。\n3. 数据血缘。\n4. 数据质量检测。\n5. 指标平台。\n6. 语义层。\n7. 特征平台。\n8. 在线特征存储。\n9. 向量索引和检索服务。\n10. 报表平台。\n11. 实时数据服务。\n12. AI 数据服务。\n13. 数据权限管理。\n14. 数据脱敏与审计。\n\n### 4.5.5 数据治理原则\n\n1. 谁产生核心业务数据，谁负责解释数据含义。\n2. 谁发布数据产品，谁负责数据质量。\n3. 核心指标必须有统一口径。\n4. 重要数据必须有血缘、质量规则和变更通知。\n5. 敏感数据必须分级、脱敏、授权和审计。\n6. 数据消费必须可追踪、可监控、可问责。\n\n### 4.5.6 数据产品标准目录\n\n数据产品目录应把业务语义、技术 Schema、质量规则、血缘、访问策略和消费样例放在一起。\n\n```text\ndomains/order/data-products/order-facts/\n├── data-product.yaml\n├── schema/\n│ └── order-facts.schema.yaml\n├── quality/\n│ └── rules.yaml\n├── lineage/\n│ └── lineage.yaml\n├── access/\n│ └── policy.rego\n├── examples/\n│ └── sample.json\n└── docs/\n ├── README.md\n └── semantics.md\n```\n\n`data-product.yaml` 示例：\n\n```yaml\nname: order-facts\ndomain: order\nowner: team-order\ntype: source-aligned-data-product\nlifecycle: production\ndescription: 订单交易事实数据产品\nschema: schema/order-facts.schema.yaml\nsemantics:\n grain: one row per order state transition\n primaryTime: order_event_time\nquality:\n freshness: 5m\n completeness: \">= 99.9%\"\n validityRules:\n - quality/rules.yaml\nlineage:\n sources:\n - resource:order-event-log\n outputs:\n - dataset:analytics:revenue-mart\naccess:\n classification: confidential\n pii: true\n policy: access/policy.rego\nconsumers:\n - team-finance-analytics\n - team-risk-modeling\n - ai-product:customer-service-agent\naiUsage:\n allowed:\n - rag\n - feature-engineering\n - offline-evaluation\n disallowed:\n - foundation-model-training\nfeatureServing:\n offlineStore: dataset:features:order-facts-offline\n onlineStore: feature:order:latest-order-risk\nvectorIndex:\n enabled: false\nslo:\n freshnessMinutes: 5\n availability: 99.9\n```\n\n### 4.5.7 数据平台与领域团队边界\n\n数据平台团队不拥有所有业务数据，它提供让领域团队发布和消费数据产品的自助能力。\n\n```text\n领域团队：拥有数据语义、质量承诺、数据产品生命周期和消费方沟通。\n数据平台团队：拥有数据目录、Schema Registry、血缘、质量检测、权限和计算平台。\n治理团队：拥有分级分类、PII、指标口径、访问策略和跨域质量规则。\n```\n\n### 4.5.8 数据产品到 AI 的联动机制\n\n数据产品网络必须显式服务 AI 原生能力层，而不是只把 AI 当成普通报表消费者。\n\n推荐联动链路：\n\n```text\n领域事件 / 领域数据库变更\n │\n ▼\nSource-aligned Data Product\n │\n ├── 指标和语义层：面向经营分析和产品运营\n ├── 离线特征：面向模型训练、批量评分和离线评估\n ├── 在线特征：面向实时推理、风控、推荐和个性化\n ├── 向量索引：面向 RAG、语义检索、多模态检索和相似案例\n └── 评估数据集：面向 Prompt、RAG、Agent 和模型回归测试\n```\n\n必须明确的架构机制：\n\n1. 特征平台必须同时管理 offline store 和 online store，保证训练与推理使用同一业务定义。\n2. 实时推理端点只能读取经过批准的在线特征、领域 API 和授权上下文，不能直接拼接数据库查询。\n3. 向量索引必须声明来源数据产品、Embedding 模型、索引版本、权限过滤规则和重建策略。\n4. AI 评估集应来自稳定数据产品和真实业务样本脱敏集，不能长期依赖人工临时样例。\n5. 数据产品变更必须通知下游 AI 产品，并触发特征、索引和评估集的兼容性检查。\n6. 数据产品 owner、AI 产品 owner 和模型 owner 必须共同签署高风险 AI 场景的上线门禁。\n\n### 4.5.9 Lakehouse 到数据产品网络的过渡路径\n\n并不是所有企业都能直接进入完整数据产品网络。对已有数据仓库、数据湖或 Lakehouse 的企业，推荐采用演进式路线：\n\n| 阶段 | 当前形态 | 关键动作 | 禁止误区 |\n| ---- | -------- | -------- | -------- |\n| L0 | 数据仓库或数据湖分散建设 | 盘点表、任务、指标、owner 和下游消费 | 只迁技术栈，不改责任边界 |\n| L1 | 建立 Lakehouse 统一存储和表格式 | 引入分层、Schema、血缘、质量和权限 | 把 Lakehouse 当成新的中央数据团队 |\n| L2 | 识别高价值领域数据集 | 让领域团队声明业务语义、口径和质量规则 | 平台团队替领域解释业务含义 |\n| L3 | 发布首批 Source-aligned Data Product | 建立数据产品契约、SLO、变更通知和消费样例 | 只发布表名，不发布产品契约 |\n| L4 | 建立 Aggregate / Consumer-aligned Data Product | 围绕业务场景组织指标、特征、人群和报表 | 让聚合层反向污染源数据定义 |\n| L5 | 形成联邦数据产品网络 | 把质量、权限、血缘、成本和 AI 消费接入自动化治理 | 重新集中审批所有数据变更 |\n\nLakehouse 的价值在于提供统一存储、开放表格式、批流处理和计算治理；数据产品网络的价值在于明确领域责任、语义契约和消费体验。两者不是替代关系，合理路径是先稳定底座，再逐步把高价值数据集产品化。\n\n---\n\n## 4.6 自助式平台工程层\n\n### 4.6.1 定位\n\n自助式平台工程层为业务团队、领域团队和数据团队提供统一的内部开发平台，降低工程复杂度，提高交付效率和治理一致性。\n\n### 4.6.2 平台核心能力\n\n平台工程层包括：\n\n1. Developer Portal。\n2. 服务模板和脚手架。\n3. Golden Path。\n4. CI/CD 流水线。\n5. IaC 基础设施即代码。\n6. GitOps 发布机制。\n7. Kubernetes 或 Serverless 运行环境。\n8. 服务网格。\n9. API 管理。\n10. 配置管理。\n11. 密钥管理。\n12. 日志、指标、链路追踪。\n13. 告警管理。\n14. 环境管理。\n15. 成本管理。\n16. 安全扫描。\n17. 依赖漏洞检测。\n18. 权限申请与审批自动化。\n19. 发布准入门禁。\n20. 研发效能度量。\n21. SBOM、provenance、签名和验签能力。\n22. AI Platform：模型网关、RAG 平台、评估流水线、Prompt 管理和 Agent 运行时。\n23. 认知负载度量和平台用户研究。\n24. 容器交付标准：镜像构建、镜像扫描、tag / digest 策略、Helm / Kustomize 模板和 GitOps 发布。\n\n### 4.6.3 平台设计目标\n\n平台团队的目标不是集中接管业务开发，而是让业务团队可以自助完成标准工程动作：\n\n1. 自助创建服务。\n2. 自助申请环境。\n3. 自助配置数据库、缓存、消息队列。\n4. 自助发布应用。\n5. 自助接入日志、监控和告警。\n6. 自助申请权限。\n7. 自助查看成本。\n8. 自助执行安全和合规检查。\n9. 自助创建 AI 应用、RAG 管道和 Agent 工作流。\n10. 自助生成 SBOM、构建 provenance、镜像签名和发布验签。\n11. 自助生成标准 Dockerfile、Kubernetes base manifest 和环境级 GitOps overlay。\n\n### 4.6.4 Golden Path\n\nGolden Path 是平台团队为常见场景提供的推荐路径。例如：\n\n1. 创建一个标准微服务。\n2. 创建一个前端应用。\n3. 创建一个数据产品。\n4. 发布一个 API。\n5. 接入统一认证。\n6. 接入可观测性。\n7. 部署到测试环境。\n8. 部署到生产环境。\n9. 配置弹性伸缩。\n10. 配置告警规则。\n11. 创建一个受治理的 AI 应用。\n12. 创建一个 RAG 索引和评估集。\n13. 接入 LLM Gateway、PromptOps 和 AI Observability。\n14. 生成 SBOM、签名镜像并通过生产准入。\n15. 创建一个容器化微服务并生成 dev / staging / prod GitOps overlay。\n\nGolden Path 应尽量内置最佳实践，使团队默认走在安全、合规、稳定和高效的路径上。\n\n### 4.6.5 平台产品契约\n\n平台能力必须像产品一样运营，而不是只提供工具入口。\n\n```yaml\nname: domain-service-golden-path\ntype: platform-product\nowner: team-platform\nusers:\n - stream-aligned-teams\n - domain-product-teams\nsolves:\n - create-service\n - register-service\n - configure-ci\n - provision-runtime\n - attach-observability\n - enforce-security-baseline\ninterfaces:\n portal: platform/portal/create-domain-service\n cli: platformctl service create\n template: platform/golden-paths/domain-service\nslo:\n templateSuccessRate: \">= 99%\"\n provisioningP95Minutes: 10\nmetrics:\n adoptionRate: weekly\n timeToFirstDeploy: daily\n failedOnboardingCount: daily\nfeedback:\n channel: \"#platform-feedback\"\n reviewCadence: biweekly\n```\n\n平台产品的验收标准：\n\n1. 有明确内部用户。\n2. 有自助入口或自动化接口。\n3. 有文档和 onboarding path。\n4. 有 SLO、采用率、反馈渠道和 roadmap。\n5. 支持 escape hatch，但必须可审计。\n\n### 4.6.6 容器交付 Golden Path\n\n平台团队应提供容器交付 Golden Path，但不直接托管每个业务服务的部署状态。\n\n容器交付 Golden Path 至少包括：\n\n1. 标准服务脚手架：生成 `src/`、测试、Dockerfile、`service.yaml` 和 catalog descriptor。\n2. 标准镜像构建：统一基础镜像、非 root 用户、多阶段构建、最小运行时和可复现构建参数。\n3. 标准 CI：测试、lint、镜像构建、SBOM、provenance、漏洞扫描、许可证检查和签名。\n4. 标准 Kubernetes base：Deployment、Service、HPA、PodDisruptionBudget、ServiceAccount 和 NetworkPolicy。\n5. 标准环境 overlay：dev、staging、prod 使用不同 namespace、replicas、资源配额、ingress 和镜像 digest。\n6. 标准 GitOps：通过 Argo CD、Flux 或等价能力同步环境期望状态。\n7. 标准回滚：按镜像 digest、Git commit 和 GitOps revision 回滚。\n8. 标准可观测性：默认接入日志、指标、trace、SLO、告警和运行面板。\n\n### 4.6.7 平台产品经理与认知负载治理\n\n平台工程必须有明确的平台产品经理或等价职责，负责把平台能力当成内部产品运营，而不是把平台做成工具集合。\n\nPlatform PM 负责：\n\n1. 识别平台目标用户、关键旅程和高频痛点。\n2. 定义 Golden Path 的成功指标、失败指标和用户反馈机制。\n3. 维护平台产品路线图，避免平台团队只按工单堆功能。\n4. 定期度量业务团队认知负载，包括 onboarding 难度、配置复杂度、排障复杂度和上下文切换成本。\n5. 推动平台能力默认内置安全、可观测、成本、AI 治理和供应链门禁。\n\n认知负载度量建议：\n\n| 指标 | 说明 | 典型采集方式 |\n| ---- | ---- | ------------ |\n| Time to First Deploy | 新团队第一次成功部署所需时间 | 平台事件和 CI/CD 日志 |\n| Self-service Success Rate | 自助流程不依赖人工支持的成功率 | Developer Portal 事件 |\n| Support Ticket Rate | 每个 Golden Path 产生的支持工单数 | 工单系统和分类标签 |\n| Context Switch Count | 完成标准任务需要切换的系统数量 | 用户访谈和行为埋点 |\n| Onboarding Completion Time | 新成员掌握平台基本操作所需时间 | 培训记录和平台行为 |\n| Perceived Cognitive Load | 团队主观复杂度评分 | 定期调研和复盘访谈 |\n\n---\n\n## 4.7 基础设施与云原生层\n\n### 4.7.1 定位\n\n基础设施与云原生层为上层业务系统、数据平台和工程平台提供稳定、安全、弹性和可观测的运行底座。\n\n### 4.7.2 主要组成\n\n1. 公有云、私有云或混合云。\n2. Kubernetes 集群。\n3. Serverless 平台。\n4. 网络与负载均衡。\n5. 存储服务。\n6. 数据库服务。\n7. 消息队列。\n8. 缓存服务。\n9. 搜索引擎。\n10. 对象存储。\n11. 容器镜像仓库。\n12. 服务发现。\n13. 灾备与备份。\n14. 云安全服务。\n15. 成本计量与资源配额。\n16. GPU、推理加速和模型服务资源池。\n17. 向量数据库、特征在线存储和高性能检索服务。\n18. 软件供应链安全基础设施：制品库、签名服务、证明存储和策略准入。\n\n### 4.7.3 基础设施原则\n\n1. 标准化资源模型。\n2. 环境隔离。\n3. 最小权限。\n4. 弹性伸缩。\n5. 故障隔离。\n6. 多可用区部署。\n7. 自动化备份。\n8. 可观测、可审计、可追溯。\n9. 成本透明。\n10. 基础设施即代码。\n11. AI 推理资源必须有隔离、配额、成本归集和降级策略。\n12. 生产制品必须支持签名验签、SBOM 查询和 provenance 追溯。\n\n### 4.7.4 Kubernetes 与 GitOps 真相源\n\nKubernetes 管理实际运行状态，GitOps 管理期望部署状态。两者不应和服务源码目录混在一起。\n\n推荐结构：\n\n```text\ninfra/\n├── kubernetes/\n│ ├── base/\n│ │ └── services/\n│ │ └── customer-profile-service/\n│ │ ├── deployment.yaml\n│ │ ├── service.yaml\n│ │ ├── hpa.yaml\n│ │ ├── pdb.yaml\n│ │ ├── network-policy.yaml\n│ │ └── kustomization.yaml\n│ └── policies/\n└── gitops/\n └── environments/\n ├── dev/customer/customer-profile-service/kustomization.yaml\n ├── staging/customer/customer-profile-service/kustomization.yaml\n └── prod/customer/customer-profile-service/kustomization.yaml\n```\n\n环境级 GitOps overlay 负责：\n\n1. 使用哪个镜像 digest。\n2. 部署到哪个 namespace。\n3. replicas、CPU / memory requests 和 limits。\n4. HPA、PDB、Ingress / Gateway 和 ServiceAccount。\n5. ConfigMap / Secret 引用。\n6. Pod 安全、网络策略、节点选择、亲和性和容忍度。\n7. 金丝雀、蓝绿、灰度或批次发布策略。\n\n生产环境禁止只用可变 tag 作为部署依据。tag 可以用于可读性，实际准入、回滚和审计必须能定位到不可变 digest、Git commit 和构建 provenance。\n\n---\n\n## 5. 联邦治理平面\n\n## 5.1 治理定位\n\n联邦治理不是中央团队审批所有事情，而是在企业层面制定少量必要标准，并通过平台能力自动执行。\n\n治理目标是：\n\n1. 保证安全合规。\n2. 保证系统稳定性。\n3. 保证数据可信。\n4. 保证接口一致性。\n5. 保证成本可控。\n6. 保证架构可演进。\n7. 避免重复建设和失控扩张。\n8. 保证 AI 应用可评估、可追溯、可审计和可降级。\n9. 保证软件供应链产物可证明、可验签和可追责。\n\n## 5.2 治理范围\n\n联邦治理平面贯穿所有架构层，包括：\n\n1. 身份与权限治理。\n2. API 标准治理。\n3. 事件标准治理。\n4. 数据契约治理。\n5. 数据安全治理。\n6. 个人敏感信息治理。\n7. 架构决策治理。\n8. SLO 治理。\n9. 成本治理。\n10. 质量门禁。\n11. 发布准入。\n12. 合规审计。\n13. Policy as Code。\n14. 自动化检测。\n15. AI 模型、Prompt、RAG、Agent 和工具调用治理。\n16. 供应链安全、SBOM、provenance、签名和验签治理。\n\n## 5.3 治理模式\n\n治理采用“全局标准 + 领域自治 + 自动化护栏”的模式。\n\n| 治理对象 | 全局规则 | 领域自治 |\n| ---- | ----------------- | ------ |\n| API | 命名、鉴权、版本、错误码、限流 | 具体接口设计 |\n| 事件 | Schema、命名、版本、兼容策略 | 具体事件含义 |\n| 数据 | 分级、脱敏、血缘、质量规则 | 领域数据定义 |\n| 安全 | 身份认证、最小权限、漏洞扫描 | 业务权限模型 |\n| AI | 模型准入、Prompt 版本、评估门禁、工具权限 | 场景设计、业务评估样本 |\n| 供应链 | SBOM、provenance、签名验签、依赖锁定 | 组件选型、升级节奏 |\n| 成本 | 标签、预算、告警、配额 | 资源使用策略 |\n| 稳定性 | SLO、告警、演练、应急流程 | 领域服务承诺 |\n\n## 5.4 自动化治理机制\n\n治理规则应尽量固化到以下环节：\n\n1. 代码提交阶段：静态扫描、依赖漏洞扫描、密钥泄露检测。\n2. 构建阶段：镜像扫描、单元测试、质量门禁。\n3. 发布阶段：变更审批、灰度发布、准入策略。\n4. 运行阶段：SLO 监控、异常检测、成本告警。\n5. 数据发布阶段：数据契约校验、质量规则校验、权限检查。\n6. API 发布阶段：接口规范校验、文档生成、兼容性检测。\n7. 事件发布阶段：Schema 校验、版本兼容性检测。\n8. AI 发布阶段：Prompt 版本、评估集、RAG 权限、工具权限、成本预算和人工确认策略校验。\n9. 制品发布阶段：SBOM 生成、provenance 生成、镜像签名、验签准入和 SLSA 等级校验。\n10. 审计阶段：访问日志、变更日志、权限日志、数据使用日志、AI 调用日志和供应链证明日志。\n\n## 5.5 治理资产目录\n\n联邦治理需要把规则、决策、例外、风险和复盘沉淀为长期资产。\n\n```text\ngovernance/\n├── standards/\n│ ├── api-standard.md\n│ ├── event-standard.md\n│ ├── data-product-standard.md\n│ ├── security-standard.md\n│ ├── reliability-standard.md\n│ └── cost-standard.md\n├── decisions/\n│ └── adr-0001-template.md\n├── ownership/\n│ ├── teams.yaml\n│ ├── raci.yaml\n│ └── escalation-policy.md\n├── slo/\n│ ├── tiering-policy.md\n│ └── error-budget-policy.md\n├── security/\n│ ├── threat-model-template.md\n│ └── data-classification.md\n├── supply-chain/\n│ ├── slsa-policy.md\n│ ├── sbom-policy.md\n│ └── signing-and-verification.md\n├── ai-governance/\n│ ├── ai-product-review.md\n│ ├── fine-tuning-review.md\n│ ├── model-risk-policy.md\n│ ├── prompt-release-gate.md\n│ └── agent-tool-policy.md\n├── data-governance/\n│ ├── data-product-review.md\n│ ├── pii-policy.md\n│ └── retention-policy.md\n├── architecture-gates/\n│ ├── production-readiness.yaml\n│ ├── domain-readiness.yaml\n│ └── data-product-readiness.yaml\n├── migration/\n│ ├── strangler-migration-policy.md\n│ ├── deprecation-policy.md\n│ └── compatibility-policy.md\n├── evidence/\n│ ├── releases/\n│ ├── supply-chain/\n│ ├── exceptions/\n│ ├── compatibility/\n│ ├── drift/\n│ ├── audit-evidence-index.md\n│ └── drill-evidence-template.md\n├── risk-register/\n├── postmortems/\n└── playbooks/\n └── ai-incident-playbook.md\n```\n\n## 5.6 治理例外机制\n\n例外不是口头豁免，必须有 owner、原因、风险、缓解措施和到期时间。\n\n```yaml\nexceptionId: EX-2026-001\nowner: team-order\nviolatedRule: data-product-freshness-standard\nreason: upstream provider does not support near-real-time delivery\nrisk: finance report may lag up to 60 minutes\nexpiry: 2026-09-01\nmitigation:\n - show freshness timestamp in consumer dashboard\n - alert when freshness exceeds 60 minutes\nreviewer: architecture-group\n```\n\n## 5.7 AI 治理门禁\n\nAI 治理必须把模型、Prompt、检索、工具、数据和人工确认作为一个整体审查。\n\nAI 产品进入生产前必须满足：\n\n1. 明确风险等级、owner、业务目标、用户范围和退出机制。\n2. 模型、Prompt、RAG 配置、工具版本和评估集可追溯。\n3. 高风险工具调用声明权限、幂等、超时、审计、回滚和人工确认策略。\n4. RAG 数据源完成分级分类、授权、引用追溯和撤销机制。\n5. 离线评测和在线灰度指标达到门槛。\n6. 成本预算、限流、降级和人工接管策略已配置。\n7. 运行日志覆盖输入、输出、上下文、工具调用、策略结果和用户反馈。\n\nAI 治理不应阻止团队使用模型，而应把模型使用变成可验证的工程过程。\n\n### 5.7.1 AI 风险分级控制基线\n\nAI 产品必须先分级，再决定评估、审批、审计和人工确认强度。风险分级不是为了阻止创新，而是为了避免把内部问答、客服辅助、自动退款、信贷审批和医疗建议放在同一套门禁里。\n\n| 风险等级 | 典型场景 | 最低控制要求 |\n| -------- | -------- | ------------ |\n| R1 低风险 | 内部知识检索、文档摘要、研发辅助 | Prompt 版本、基础评估集、成本限额、日志审计 |\n| R2 中风险 | 客服辅助、运营建议、销售线索整理 | RAG 权限过滤、引用追溯、人工抽检、灰度发布 |\n| R3 高风险 | 自动退款、账户处置、风控建议、合同审查 | 人工确认、红队测试、回放审计、模型/Prompt/RAG 回归门禁 |\n| R4 严格受控 | 信贷审批、医疗建议、招聘筛选、合规判定 | 法务/合规评审、影响评估、强人工复核、独立审计和退出机制 |\n| R5 禁止或暂缓 | 无法解释的关键自动决策、无授权敏感数据训练 | 不得进入生产，除非完成专门风险接受和监管评估 |\n\n风险等级必须写入 `ai-product.yaml`，并驱动 CI/CD、Developer Portal、LLM Gateway、Agent Runtime 和审计系统的默认策略。\n\n### 5.7.2 AI 资产证据链\n\nAI 资产必须具备证据链，否则无法做回归、复盘和合规审计。\n\n每个生产 AI 产品至少保留：\n\n1. 模型证据：模型名称、版本、供应商、批准状态、适用场景、限制和替代模型。\n2. Prompt 证据：模板版本、变更记录、评估结果、灰度记录和回滚点。\n3. 数据证据：RAG 来源、数据产品、特征产品、评估数据集、脱敏策略和授权范围。\n4. 工具证据：工具 Schema、权限、幂等、超时、重试、人工确认和审计字段。\n5. 运行证据：请求元数据、检索片段、模型输出、工具调用、策略判断、人工确认和用户反馈。\n6. 风险证据：风险等级、威胁模型、红队结果、已知限制和风险接受记录。\n\n建议维护 `ai-evidence.yaml`：\n\n```yaml\naiProduct: customer-service-agent\nriskTier: R3\nmodel:\n gatewayRoute: support-safe-default\n approvedModels:\n - model: vendor:model-name\n version: \"2026-05\"\n approval: approved-for-support-assist\nprompts:\n systemPrompt: prompts/system.prompt.md\n version: \"2026.06.01\"\nrag:\n sources: rag/sources.yaml\n vectorIndex: vector:customer-support-policy:v12\n embeddingModel: embedding:model:v3\nevals:\n regression: evals/regression.yaml\n redTeam: evals/adversarial.yaml\ntools:\n registry: tools/tool-permissions.yaml\naudit:\n traceRetentionDays: 180\n replayEnabled: true\ngovernance:\n approval: governance/ai-governance/reviews/customer-service-agent.md\n expiry: 2026-12-01\n```\n\n### 5.7.3 微调治理门禁\n\n微调模型不能继承基础模型的风险结论。任何微调都会改变模型行为边界，因此必须形成独立审查记录。\n\n微调进入生产前必须满足：\n\n1. 数据授权：训练数据允许用于指定微调目的，且禁止用途写入契约。\n2. 数据治理：完成脱敏、去重、版权、PII、敏感字段和保留期限检查。\n3. 实验追踪：每次训练可追溯到基础模型、数据版本、代码版本、超参数、环境和成本。\n4. 独立评估：评估集不得与训练集混用，必须覆盖质量、安全、幻觉、偏见、越权和泄露。\n5. 模型登记：微调模型必须有 Model Card、版本、owner、风险等级、适用场景和回滚模型。\n6. 发布准入：高风险微调模型必须先 shadow 或灰度，再逐步放量。\n7. 授权撤销：当数据授权撤销或发现污染数据时，必须能定位受影响模型并触发禁用或重训。\n\n## 5.8 供应链安全门禁\n\n供应链安全必须覆盖源码、依赖、构建、测试、制品、签名、部署和运行准入。\n\n生产发布最低要求：\n\n1. 依赖必须锁定版本，并进入漏洞扫描和许可证检查。\n2. 每个发布制品必须生成 SBOM，至少覆盖直接依赖、传递依赖、版本、供应商和许可证信息。\n3. 构建系统必须生成 provenance，记录源码、构建器、构建参数、依赖和制品摘要。\n4. 容器镜像、部署包和关键二进制必须签名。\n5. 生产准入必须执行验签、SBOM 策略、漏洞阈值和来源策略。\n6. 高风险系统应逐步达到 SLSA Build Level 2，核心系统应规划达到 SLSA Build Level 3。\n7. 供应链例外必须有 owner、到期时间、补救计划和风险接受记录。\n\n## 5.9 Policy as Code 策略语言\n\n联邦治理必须统一策略语言和执行入口，避免每个团队各写一套不可复用的策略。\n\n推荐策略：\n\n| 策略范围 | 推荐引擎 | 说明 |\n| -------- | -------- | ---- |\n| 跨平台治理、CI 门禁、数据访问、发布准入 | OPA / Rego | 适合通用 Policy as Code、单元测试和准入校验 |\n| Kubernetes 资源策略 | OPA Gatekeeper 或 Kyverno | 适合集群准入、镜像验签、命名空间和资源限制 |\n| 应用内细粒度授权 | Cedar 或等价授权策略语言 | 适合把应用权限模型从业务代码中剥离 |\n| 云厂商原生权限 | IAM Policy | 只用于云资源权限，不替代企业级治理策略 |\n\n原则：\n\n1. 企业级默认策略语言必须少而稳定，不能让 Rego、Cedar、YAML 条件和自研 DSL 无边界混用。\n2. 所有策略必须有 owner、测试用例、示例输入、示例输出、版本和回滚路径。\n3. 生产策略变更必须进入 CI，至少执行语法检查、单元测试、关键路径用例和冲突检测。\n4. 策略例外必须可审计，并有到期时间。\n5. 如果采用多策略引擎，必须明确边界：谁负责准入、谁负责授权、谁负责数据访问、谁负责云资源。\n\n---\n\n## 6. 安全架构\n\n## 6.1 安全目标\n\n安全架构的目标是建立覆盖身份、网络、应用、数据、供应链和运行环境的纵深防御体系。\n\n## 6.2 身份与访问控制\n\n1. 统一身份认证。\n2. 单点登录。\n3. 多因素认证。\n4. 最小权限原则。\n5. 基于角色的访问控制。\n6. 基于属性的访问控制。\n7. 服务到服务认证。\n8. 临时凭证和密钥轮换。\n9. 权限申请、审批和审计。\n\n## 6.3 应用安全\n\n1. 安全编码规范。\n2. 依赖漏洞扫描。\n3. 镜像漏洞扫描。\n4. API 鉴权。\n5. 输入校验。\n6. 敏感信息保护。\n7. 防重放、防篡改、防越权。\n8. Web 应用防护。\n9. 灰度发布和快速回滚。\n10. 安全测试自动化。\n\n### 6.3.1 安全开发证据\n\n安全开发不应只在上线前扫描一次，而应贯穿需求、设计、编码、构建、测试、发布和响应。\n\n每个 Tier-1 服务至少保留：\n\n1. 安全需求和威胁建模记录。\n2. 安全设计评审记录。\n3. 代码评审和静态分析结果。\n4. 依赖、许可证、密钥和镜像扫描结果。\n5. 安全测试、模糊测试或关键路径滥用用例。\n6. 漏洞处置 SLA、例外审批和补救计划。\n7. 生产事件响应和安全复盘记录。\n\n平台应把这些证据自动挂接到 catalog 和发布准入，而不是让团队在审计时临时补材料。\n\n## 6.4 数据安全\n\n1. 数据分级分类。\n2. 敏感数据识别。\n3. 数据脱敏。\n4. 数据加密。\n5. 数据访问授权。\n6. 数据使用审计。\n7. 数据出境或外发控制。\n8. 数据生命周期管理。\n9. 备份与恢复。\n10. 隐私合规。\n\n## 6.5 云原生安全\n\n1. 集群访问控制。\n2. 命名空间隔离。\n3. 网络策略。\n4. 镜像签名。\n5. 运行时安全。\n6. Secret 管理。\n7. Pod 安全策略。\n8. 供应链安全。\n9. 基础设施变更审计。\n10. 异常行为检测。\n\n## 6.6 供应链安全\n\n供应链安全是生产发布的基线能力，不是可选增强项。\n\n必须建立以下控制：\n\n1. SLSA 分级目标：普通业务系统至少满足可审计构建和 provenance；核心系统逐步达到隔离构建、不可篡改日志和强身份构建器。\n2. SBOM：每个生产制品生成 SPDX 或 CycloneDX 等标准格式 SBOM，并进入制品库和审计系统。\n3. 镜像签名与验签：构建完成后签名，部署前由准入控制器验签。\n4. Provenance：记录源码仓库、commit、构建器、构建参数、依赖摘要和产物摘要。\n5. 依赖锁定：生产构建必须使用锁文件、固定版本或可复现依赖解析。\n6. 漏洞策略：按 CVSS、可利用性、暴露面和业务等级设置阻断阈值。\n7. 许可证策略：禁止未经批准的强传染许可证或未知许可证进入生产制品。\n8. 制品不可变：生产制品一旦签名，不允许覆盖发布。\n9. 准入控制：部署前校验签名、SBOM、provenance、漏洞阈值、基础镜像和策略标签。\n10. 例外闭环：所有安全例外必须有到期时间和补救计划。\n\n## 6.7 AI 安全\n\nAI 安全覆盖模型输入、上下文、工具调用、输出、记忆、向量索引和供应商接入。\n\n必须建立以下控制：\n\n1. Prompt 注入防护：对用户输入、检索片段和工具返回内容进行来源标记和指令隔离。\n2. 越权访问防护：RAG 检索、工具调用和领域 API 调用必须继承用户和服务权限。\n3. 数据泄露防护：输入输出执行 PII、密钥、内部策略和敏感数据检测。\n4. 工具滥用防护：高风险工具必须声明危险等级、幂等性、人工确认和审计。\n5. 过度代理防护：Agent 计划、循环、重试、并发和成本必须有上限。\n6. 模型供应商隔离：密钥、租户、日志保留和数据使用策略必须可控。\n7. 评估与红队：核心 AI 产品必须有越权、幻觉、提示注入、错误引用和成本消耗测试。\n8. 输出责任：关键业务输出必须可解释、可引用或可回放，不能只保留最终文本。\n\n---\n\n## 7. 可观测性与运行治理\n\n## 7.1 可观测性目标\n\n平台应具备统一的日志、指标、链路追踪、事件和告警能力，支持业务团队快速发现问题、定位问题和恢复服务。\n\n## 7.2 可观测性内容\n\n1. 应用日志。\n2. 业务日志。\n3. 系统指标。\n4. 业务指标。\n5. 链路追踪。\n6. API 调用指标。\n7. 数据质量指标。\n8. 队列积压指标。\n9. 数据库性能指标。\n10. 用户体验指标。\n11. 成本指标。\n12. 安全事件指标。\n13. AI 调用指标：Token、延迟、模型错误、工具调用、引用命中、幻觉反馈和成本。\n14. 供应链指标：SBOM 覆盖率、签名覆盖率、验签失败率、漏洞阻断和 provenance 覆盖率。\n\n## 7.3 SLO 体系\n\n每个关键领域产品都应定义 SLO。常见指标包括：\n\n| 指标 | 说明 |\n| ----- | ------------ |\n| 可用性 | 服务可正常提供能力的比例 |\n| 延迟 | 请求响应时间 |\n| 错误率 | 失败请求占比 |\n| 吞吐量 | 单位时间处理能力 |\n| 数据新鲜度 | 数据更新是否及时 |\n| 数据准确性 | 数据是否符合质量规则 |\n| 恢复时间 | 故障后恢复所需时间 |\n| 变更失败率 | 发布引发故障的比例 |\n| AI 任务完成率 | AI 产品完成目标任务的比例 |\n| AI grounded rate | AI 输出能被引用或事实来源支撑的比例 |\n| 供应链证明覆盖率 | 生产制品具备 SBOM、签名和 provenance 的比例 |\n\n## 7.4 事件响应机制\n\n应建立标准事件响应流程：\n\n1. 异常发现。\n2. 告警触发。\n3. 影响范围判断。\n4. 负责人确认。\n5. 应急处理。\n6. 临时恢复。\n7. 根因分析。\n8. 复盘改进。\n9. 规则和平台能力修正。\n10. 知识库沉淀。\n\n## 7.5 AI 可观测性\n\nAI 产品必须同时观测工程质量、业务质量和模型质量。\n\n关键指标包括：\n\n1. 请求量、Token 量、模型延迟和错误率。\n2. 模型路由、重试、降级和拒绝率。\n3. Prompt 版本、模型版本、检索配置和工具版本。\n4. RAG 召回率、重排命中率、引用覆盖率和无引用输出比例。\n5. Agent 工具调用成功率、人工确认率、循环中断率和超时率。\n6. 用户反馈、人工抽检质量、幻觉反馈和任务完成率。\n7. 单次任务成本、团队预算消耗、异常成本峰值和语义缓存命中率。\n\nAI 可观测性必须支持回放，至少能还原输入元数据、检索片段、Prompt 版本、模型版本、工具调用、策略判断和最终输出。\n\n## 7.6 AI 事件响应机制\n\nAI 产品必须有独立事件响应 playbook。通用事件响应流程可以处理服务宕机和延迟，但不足以处理幻觉爆发、工具失控、模型供应商中断、RAG 索引污染和微调模型回退。\n\n典型 AI 事件类型：\n\n| 事件类型 | 典型表现 | 首要动作 |\n| -------- | -------- | -------- |\n| 幻觉率突然升高 | grounded rate 下降、用户负反馈升高 | 降级到上一版 Prompt / 模型 / 检索配置 |\n| Prompt 注入成功 | 模型泄露策略、忽略系统指令或越权回答 | 阻断输入模式，回滚 Prompt，增加隔离和过滤 |\n| 工具调用失控 | Agent 循环调用、重复退款、重复建单 | 关闭高风险工具，启用人工确认和速率限制 |\n| RAG 索引污染 | 检索到过期、恶意或无权限片段 | 冻结索引，回滚向量索引版本，重建来源数据 |\n| 模型供应商中断 | 延迟升高、错误率升高、质量异常 | 切换模型路由，缩小上下文，降级到人工流程 |\n| 微调模型回退 | 特定任务质量下降或安全评估失败 | 下线微调模型，回退基础模型或上一个微调版本 |\n| 成本失控 | Token、GPU、向量检索或工具调用异常增加 | 限流、降低模型等级、启用预算熔断 |\n| 敏感信息泄露 | 输出 PII、密钥、内部策略或无权数据 | 关闭相关数据源，启动安全事件流程和审计 |\n\nAI 事件响应步骤：\n\n1. 分类：判断是模型、Prompt、RAG、工具、数据、供应商、成本还是权限事件。\n2. 止血：切换模型路由、回滚 Prompt、冻结工具、关闭索引、限流或进入人工接管。\n3. 取证：保留 trace、Prompt 版本、模型版本、检索片段、工具调用、策略日志和用户反馈。\n4. 影响评估：识别受影响用户、业务动作、数据产品、工具、模型版本和时间窗口。\n5. 修复：修正 Prompt、检索配置、工具权限、策略规则、索引来源或模型版本。\n6. 回归：运行 AI 回归评估、红队用例、权限用例和成本用例。\n7. 复盘：更新评估集、Guardrails、SLO、runbook、风险登记和治理门禁。\n\n`governance/playbooks/ai-incident-playbook.md` 应至少包含：\n\n1. 事件分级。\n2. 负责人和升级路径。\n3. 各类事件的止血动作。\n4. 取证字段清单。\n5. 回滚和降级矩阵。\n6. 用户和监管沟通模板。\n7. 复盘模板和门禁修正项。\n\n## 7.7 可靠性分级与恢复目标\n\n可靠性不能只写“高可用”。每个生产服务、数据产品、AI 产品和关键平台能力都必须声明可靠性等级，并把等级映射到 SLO、RTO、RPO、错误预算、on-call、发布策略和灾备演练。\n\n默认分级：\n\n| 等级 | 适用对象 | 可用性目标 | RTO | RPO | 值守要求 | 灾备演练 |\n| ---- | -------- | ---------- | --- | --- | -------- | -------- |\n| `Tier-1` | 收入、支付、履约、账户、安全、合规和关键客户路径 | 99.9% - 99.99% | <= 1 小时 | <= 15 分钟 | 7x24 on-call，明确升级路径 | 每季度至少一次 |\n| `Tier-2` | 重要运营、内部核心流程、关键数据产品和中风险 AI 产品 | 99.5% - 99.9% | <= 4 小时 | <= 4 小时 | 工作时间值守，关键告警可升级 | 每半年至少一次 |\n| `Tier-3` | 内部辅助工具、低风险后台、实验性能力和非关键报表 | 99.0% 或 best effort | <= 1 个工作日 | <= 24 小时 | 工作时间响应 | 每年至少一次桌面演练 |\n\n分级规则：\n\n1. 等级必须写入 `domain.yaml`、`service.yaml`、`data-product.yaml`、`ai-product.yaml` 或 catalog entry。\n2. 服务不能声明高于关键下游依赖的可靠性等级，除非具备缓存、降级、异步补偿或替代路径。\n3. `Tier-1` 必须具备 runbook、rollback、告警、容量水位、依赖降级、备份恢复和事故复盘。\n4. 数据产品的 RPO 对应数据丢失窗口，freshness 对应数据新鲜度，二者不能混用。\n5. AI 产品的 RTO 必须包含模型供应商切换、Prompt 回滚、RAG 索引回滚、工具冻结和人工接管时间。\n6. RTO/RPO 必须通过演练、恢复测试或事故复盘验证，不能只写在文档里。\n\n错误预算基线：\n\n| 状态 | 触发条件 | 必须动作 |\n| ---- | -------- | -------- |\n| 正常 | 错误预算消耗低于 50% | 按正常发布节奏推进 |\n| 关注 | 错误预算消耗达到 50% - 75% | 复查变更频率、告警噪声、依赖稳定性和容量水位 |\n| 限制 | 错误预算消耗达到 75% - 100% | 暂停非关键发布，优先可靠性修复和降级演练 |\n| 冻结 | 错误预算耗尽或连续重大事故 | 冻结功能发布，必须完成复盘、修复和治理门禁更新 |\n\n`governance/slo/tiering-policy.md` 应至少包含：\n\n1. Tier 定义和适用对象。\n2. 可用性、延迟、错误率、RTO、RPO 和数据 freshness 目标。\n3. on-call、升级路径和业务 owner。\n4. 发布冻结条件和错误预算策略。\n5. 备份、恢复、灾备演练和证据保存要求。\n6. 例外审批和到期复审机制。\n\n---\n\n## 8. 组织与团队模型\n\n## 8.1 团队类型\n\n现代数字化平台建议采用以下团队结构：\n\n| 团队类型 | 职责 |\n| -------------------------- | -------------------------- |\n| Stream-aligned Team | 面向业务流，端到端交付客户价值 |\n| Domain Product Team | 负责领域能力产品、领域模型、API、事件和数据产品 |\n| Platform Team | 建设内部开发平台，降低业务团队复杂度 |\n| Data Platform Team | 提供数据平台、数据目录、质量检测、语义层和特征平台 |\n| AI Product Team | 负责 AI 产品、Agent、RAG、评估集和模型接入治理 |\n| Enabling Team | 短期赋能其他团队，提升云原生、数据、AI、安全等能力 |\n| Complicated Subsystem Team | 负责高复杂专业系统，如搜索、推荐、风控模型、交易撮合 |\n| Governance Team | 制定全局规则，并推动治理自动化 |\n| Security Team | 负责安全策略、审计、风险管理和安全平台能力 |\n\n## 8.2 责任划分\n\n### 8.2.1 前台业务团队\n\n负责：\n\n1. 用户体验。\n2. 业务流程。\n3. 业务指标。\n4. 渠道运营。\n5. 需求优先级。\n6. 客户反馈闭环。\n\n### 8.2.2 领域团队\n\n负责：\n\n1. 领域能力规划。\n2. 领域模型设计。\n3. API 和事件发布。\n4. 数据产品发布。\n5. 服务稳定性。\n6. 领域业务指标。\n7. 领域架构演进。\n\n### 8.2.3 平台团队\n\n负责：\n\n1. 内部开发平台。\n2. Golden Path。\n3. CI/CD。\n4. 环境与资源管理。\n5. 可观测性平台。\n6. 平台安全能力。\n7. 成本可视化。\n8. 工程效率提升。\n9. 供应链安全能力。\n10. AI 平台能力。\n11. 平台用户研究和认知负载降低。\n\n### 8.2.4 数据团队\n\n负责：\n\n1. 数据平台能力。\n2. 数据目录。\n3. 数据质量框架。\n4. 指标体系。\n5. 语义层。\n6. 特征平台。\n7. 数据治理工具。\n8. 数据消费体验。\n\n### 8.2.5 AI 产品团队\n\n负责：\n\n1. AI 产品目标、用户和风险等级定义。\n2. Agent 工作流、工具权限和人工确认策略。\n3. Prompt 版本、评估集和发布回归。\n4. RAG 数据源、索引、引用和权限过滤。\n5. 模型接入、模型路由和质量评估。\n6. AI 可观测性、成本和反馈闭环。\n7. 与领域团队、数据团队和安全团队共同完成高风险 AI 场景上线门禁。\n\n### 8.2.6 Platform PM\n\n负责：\n\n1. 定义平台产品战略、路线图和内部用户画像。\n2. 管理 Golden Path 的采用率、成功率、满意度和失败原因。\n3. 组织平台用户访谈、开发者体验调研和认知负载评估。\n4. 协调平台工程、安全、数据、AI 和治理需求的优先级。\n5. 防止平台团队退化为工单承接团队。\n\n### 8.2.7 治理团队\n\n负责：\n\n1. 架构原则。\n2. 标准制定。\n3. 治理机制。\n4. 合规要求。\n5. 规则自动化。\n6. 架构评审机制。\n7. 治理效果度量。\n\n## 8.3 RACI 决策权矩阵\n\nRACI 用于明确“谁负责做、谁最终负责、谁必须参与、谁只需知会”。没有 RACI 的企业架构会退化成会议驱动：所有人都能提意见，但没人对结果负责。\n\n定义：\n\n1. `R` Responsible：直接执行和产出交付物的团队。\n2. `A` Accountable：对最终结果负责并拥有批准权的角色，原则上每项决策只有一个最终 accountable owner。\n3. `C` Consulted：必须咨询并纳入反馈的团队。\n4. `I` Informed：需要被通知但不阻塞决策的团队。\n\n企业级默认 RACI：\n\n| 决策事项 | A | R | C | I | 必要证据 |\n| -------- | - | - | - | - | -------- |\n| 企业架构基线版本发布 | 架构组负责人 | 治理团队 | 平台、数据、安全、AI、领域代表 | 管理层、所有执行团队 | 版本记录、评审记录、门禁结果 |\n| 新增或拆分核心领域 | 架构组负责人 | 领域团队 | 业务 owner、数据团队、平台团队、安全团队 | 受影响团队 | ADR、领域模型、依赖影响分析 |\n| 新建生产服务 | 领域团队负责人 | 领域团队 | 平台团队、安全团队、SRE | 治理团队、相关消费者 | `service.yaml`、catalog entry、生产就绪门禁 |\n| API breaking change | API owner | 领域团队 | 消费方、平台团队、治理团队 | 所有订阅方 | 兼容性报告、迁移计划、弃用日期 |\n| 事件 Schema breaking change | 事件 owner | 领域团队 | 消费方、数据团队、平台团队 | 治理团队 | 消费者影响分析、Schema 迁移计划 |\n| 数据产品发布 | 数据产品 owner | 领域团队 | 数据平台团队、安全团队、下游消费者 | 治理团队 | 数据契约、质量报告、权限策略 |\n| 高风险 AI 产品上线 | 业务 owner | AI 产品团队 | 安全、法务/合规、数据团队、领域团队 | 平台团队、治理团队 | 风险分级、评估报告、回放证据、人工确认策略 |\n| 平台 Golden Path 变更 | Platform PM | 平台团队 | 领域团队、安全团队、SRE、AI 团队 | 所有平台用户 | 迁移说明、用户影响、回滚路径 |\n| 供应链安全准入策略变更 | 安全负责人 | 安全团队 | 平台团队、治理团队、领域代表 | 所有服务 owner | 策略测试、例外清单、阻断阈值 |\n| GitOps 生产环境策略变更 | SRE / 环境 owner | 平台团队或 SRE | 安全团队、领域团队、治理团队 | 受影响服务 owner | GitOps diff、回滚计划、准入结果 |\n| SLO 等级或 RTO/RPO 调整 | 业务 owner | 领域团队或平台 owner | SRE、治理团队、数据/AI owner | 管理层和消费者 | tiering policy、风险接受、演练证据 |\n| 治理例外审批 | 治理负责人 | 申请团队 | 安全、平台、数据、AI 或 SRE | 受影响团队 | 例外原因、风险、缓解措施、到期时间 |\n\n执行规则：\n\n1. 每个生产系统、数据产品、AI 产品和平台能力必须有一个 accountable owner。\n2. `A` 可以授权执行，但不能把最终责任转移给平台团队、治理团队或供应商。\n3. 高风险 AI、安全、合规和供应链变更可以有多个必需审批门禁，但仍必须指定单一业务或技术 accountable owner。\n4. RACI 变更本身必须进入架构决策记录或治理变更记录。\n5. `governance/ownership/raci.yaml` 是机器可读 RACI 真相源，文档表格只作为说明。\n\n---\n\n## 9. 关键业务流程示例\n\n## 9.1 新服务创建流程\n\n1. 团队在 Developer Portal 选择服务模板。\n2. 平台自动创建代码仓库。\n3. 平台自动生成基础代码、CI/CD 流水线和部署配置。\n4. 团队填写服务元数据、负责人和所属领域。\n5. 平台自动接入日志、指标、链路追踪和告警。\n6. 平台自动执行安全扫描和依赖检查。\n7. 服务部署到测试环境。\n8. 通过发布准入后进入生产环境。\n9. 服务在服务目录中可见。\n10. 后续运行质量纳入 SLO 监控。\n\n## 9.2 新 API 发布流程\n\n1. 领域团队设计 API。\n2. API 文档和契约提交到 API 管理平台。\n3. 平台自动检查命名、鉴权、版本和错误码规范。\n4. 安全策略自动生效。\n5. API 发布到网关。\n6. 消费方通过门户申请使用。\n7. 调用情况、错误率和延迟自动监控。\n8. 版本变更自动通知下游消费者。\n\n## 9.3 新数据产品发布流程\n\n1. 领域团队定义数据产品。\n2. 填写业务口径、字段含义、数据负责人和更新频率。\n3. 配置数据质量规则。\n4. 配置数据分级、脱敏和访问权限。\n5. 平台自动检测血缘和质量。\n6. 数据产品进入数据目录。\n7. 消费方申请访问。\n8. 数据使用行为被记录和审计。\n9. 数据质量和使用情况持续监控。\n\n## 9.4 跨领域业务流程\n\n以“用户下单”为例：\n\n1. 前台体验层提交下单请求。\n2. 体验编排层完成渠道校验和上下文组装。\n3. 订单域创建订单。\n4. 商品域校验商品状态。\n5. 库存域锁定库存。\n6. 支付域发起支付。\n7. 风控域进行交易风险评估。\n8. 履约域接收订单履约事件。\n9. 营销域核销优惠权益。\n10. 数据产品网络沉淀订单、支付、履约和营销数据。\n11. 经营分析、推荐模型和风控模型消费相关数据产品。\n\n## 9.5 新 AI 产品发布流程\n\n1. AI 产品团队定义业务目标、用户范围、风险等级和退出机制。\n2. 领域团队确认可调用 API、事件、工具和业务动作边界。\n3. 数据团队确认可消费数据产品、特征、向量索引和评估样本。\n4. AI 团队提交 Prompt、Agent 工作流、RAG 配置、工具权限和评估集。\n5. 平台自动执行 Prompt 回归、RAG 权限校验、工具权限校验和成本预算校验。\n6. 安全团队执行提示注入、越权、数据泄露和高风险动作测试。\n7. 产品进入灰度，持续观察任务完成率、grounded rate、人工确认率、用户反馈和成本。\n8. 达到门禁后进入生产；不达标时回滚到上一个 Prompt、模型、检索或人工流程。\n9. 所有模型调用、工具调用、评估结果和人工确认记录进入审计。\n\n## 9.6 新微调模型发布流程\n\n1. AI 产品团队提交微调必要性说明，证明 Prompt、RAG、工具和模型路由不足以满足目标。\n2. 数据 owner 确认训练数据授权、分级、脱敏、保留期限和禁止用途。\n3. AI 团队登记实验，记录基础模型、数据版本、代码版本、训练配置和成本。\n4. 平台执行数据质量、PII、版权、泄露和训练/评估集隔离检查。\n5. 模型通过独立评估集、安全用例、红队用例和业务验收。\n6. 模型进入 Model Registry，生成 Model Card、风险等级、适用范围和回滚模型。\n7. 模型进入 shadow 或灰度发布，观察质量、安全、成本和用户反馈。\n8. 达到门禁后进入生产；不达标时回滚基础模型或上一版微调模型。\n9. 微调数据授权撤销、数据污染或模型退化时，触发禁用、重训或退役流程。\n\n## 9.7 供应链安全发布流程\n\n1. 开发者提交代码并触发 CI。\n2. CI 执行测试、静态扫描、依赖扫描、许可证检查和密钥扫描。\n3. 构建系统使用受控构建器生成制品。\n4. 构建系统生成 SBOM 和 provenance。\n5. 制品进入镜像仓库或制品库后完成签名。\n6. 发布前准入控制器执行验签、SBOM 策略、漏洞阈值和来源策略。\n7. GitOps 或发布系统只部署通过准入的不可变制品。\n8. 运行期持续监控新漏洞、异常行为和供应链策略漂移。\n\n---\n\n## 10. 技术标准\n\n## 10.1 API 标准\n\n1. API 必须有明确业务语义。\n2. API 必须有版本管理。\n3. API 必须有统一认证和授权。\n4. API 必须有错误码规范。\n5. API 必须有超时、限流和熔断策略。\n6. API 必须有文档和示例。\n7. API 变更必须评估兼容性。\n8. 废弃 API 必须提前通知消费者。\n\n## 10.2 事件标准\n\n1. 事件命名必须体现领域和业务含义。\n2. 事件必须有 Schema。\n3. 事件必须有版本。\n4. 事件必须有生产者和消费者记录。\n5. 事件必须支持幂等处理。\n6. 事件变更必须兼容已有消费者。\n7. 关键事件必须纳入监控和审计。\n\n## 10.3 数据标准\n\n1. 核心数据必须有业务定义。\n2. 核心指标必须有统一口径。\n3. 数据产品必须有负责人。\n4. 数据产品必须有质量规则。\n5. 敏感字段必须标注。\n6. 数据访问必须授权。\n7. 数据使用必须可审计。\n8. 重要数据变更必须通知下游。\n\n### 10.3.1 数据契约最低字段\n\n数据产品必须具备机器可读数据契约，不能只依赖表说明。\n\n最低字段包括：\n\n1. owner、domain、consumer、lifecycle。\n2. schema、字段类型、nullable、枚举、主键和时间字段。\n3. semantic grain、指标口径、业务定义和限制。\n4. freshness、completeness、validity、uniqueness 和 accuracy 规则。\n5. classification、PII、retention、access policy 和审计要求。\n6. lineage、upstream、downstream 和 breaking change 通知策略。\n7. AI usage policy：是否允许训练、Embedding、RAG、特征、评估和在线推理。\n8. cost owner、SLO 和消费示例。\n\n数据契约必须进入 CI，至少校验 schema 兼容、质量规则、权限策略和下游影响。\n\n## 10.4 工程标准\n\n1. 代码必须通过质量扫描。\n2. 依赖必须通过漏洞检查。\n3. 镜像必须通过安全扫描。\n4. 发布必须经过自动化流水线。\n5. 配置和密钥必须分离。\n6. 生产变更必须可追踪。\n7. 关键系统必须支持灰度发布和回滚。\n8. 服务必须接入可观测性平台。\n\n## 10.5 机器可读契约目录\n\n所有跨团队、跨系统、跨领域的接口都应进入 `contracts/`，避免只靠口头约定、文档段落或代码注释协作。\n\n```text\ncontracts/\n├── apis/\n│ ├── public/\n│ ├── internal/\n│ └── partner/\n├── events/\n│ ├── topics/\n│ └── schemas/\n├── schemas/\n│ ├── json/\n│ ├── proto/\n│ └── avro/\n├── datasets/\n│ ├── products/\n│ ├── quality-rules/\n│ └── semantic-layer/\n├── ai/\n│ ├── tools/\n│ ├── prompts/\n│ ├── rag/\n│ ├── evals/\n│ ├── fine-tuning/\n│ └── guardrails/\n├── resources/\n│ ├── terraform-modules/\n│ ├── kubernetes-crds/\n│ └── cloud-resources/\n└── policies/\n ├── iam/\n ├── opa/\n └── data-access/\n```\n\n契约变更规则：\n\n1. API breaking change 必须先完成消费者影响分析。\n2. 事件 Schema 默认只允许向后兼容演进。\n3. 数据产品 Schema 必须校验字段语义、类型、分级和质量规则。\n4. AI 工具契约必须校验权限、Schema、幂等、超时、审计和人工确认策略。\n5. 微调契约必须校验训练数据授权、实验追踪、评估集隔离、模型登记和回滚路径。\n6. Policy 必须声明策略引擎、策略范围和测试用例，并通过语法、单元测试和关键路径场景测试。\n7. 契约变更必须进入 CI，不能只停留在文档。\n\n## 10.6 软件和数据资产目录\n\n`catalog/` 让系统、服务、API、资源、数据产品、owner 和生命周期可发现。\n\n```text\ncatalog/\n├── systems/\n├── components/\n├── resources/\n├── apis/\n├── data-products/\n├── ai-products/\n├── models/\n├── agents/\n├── domains/\n└── scorecards/\n```\n\n组件登记示例：\n\n```yaml\nname: order-command-service\nkind: component\ntype: service\ndomain: order\nsystem: order-system\nowner: team-order\nlifecycle: production\ntier: tier-1\nprovidesApis:\n - domain:order:orders-internal-api\npublishesEvents:\n - domain:order:order-created\ndependsOn:\n - resource:order-primary-db\n - api:customer-internal-api\n - topic:payment-authorized\nruntime:\n platform: kubernetes\n namespace: order-prod\n deployment: order-command-service\n imageRepository: registry.company.com/order/order-command-service\n gitopsPath: infra/gitops/environments/prod/order/order-command-service\nscorecards:\n productionReadiness: pass\n security: pass\n reliability: warn\n```\n\n核心规则：\n\n1. 没有 catalog entry 的生产组件不能发布。\n2. 没有 owner 的系统不能进入生产。\n3. 没有 lifecycle 的资产不能被消费者依赖。\n4. 资源必须可追溯到 owner、系统、环境和成本中心。\n5. catalog 只能指向运行对象和 GitOps 路径，不能成为部署真相源。\n\n## 10.7 AI 标准\n\n1. AI 产品必须有 `ai-product.yaml`、owner、风险等级、SLO 和 runbook。\n2. Prompt、模型、工具、RAG 和评估集必须版本化。\n3. Agent 工具调用必须声明权限、Schema、幂等、超时、重试、审计和人工确认策略。\n4. RAG 索引必须声明来源、授权、Embedding 模型、索引版本和重建策略。\n5. 高风险 AI 输出必须支持引用、回放、人工确认或人工接管。\n6. AI 发布必须通过离线评估、在线灰度、成本预算和安全门禁。\n7. AI 调用必须接入统一可观测性和审计。\n8. 模型供应商、日志保留、数据使用和跨境传输策略必须明确。\n\n## 10.8 供应链安全标准\n\n1. 生产构建必须可追溯到源码 commit、构建器、依赖和制品摘要。\n2. 生产制品必须生成 SBOM。\n3. 生产制品必须签名，部署前必须验签。\n4. 依赖必须锁定版本，升级必须经过漏洞和许可证检查。\n5. 基础镜像必须来自批准来源，并定期更新。\n6. 高风险漏洞不得通过生产准入；例外必须有 owner、到期时间和补救计划。\n7. 关键系统必须逐步达到更高 SLSA 构建等级。\n8. 供应链证据必须可被审计系统查询和长期保留。\n\n## 10.9 容器与 GitOps 标准\n\n1. 每个生产微服务必须有服务目录、Dockerfile / Containerfile、`service.yaml` 和 catalog entry。\n2. 镜像必须推送到受控 container registry，不进入 Git 仓库。\n3. 镜像 tag 可以使用 git sha、语义版本或构建号，但生产部署必须可追溯到 digest。\n4. Kubernetes manifest 必须声明 requests、limits、health check、readiness、ServiceAccount 和最小权限。\n5. dev、staging、prod 的差异必须通过 GitOps overlay 表达，不能在服务代码里硬编码环境差异。\n6. 生产部署必须经过 SBOM、provenance、签名验签、漏洞阈值和策略准入。\n7. 环境期望状态由 `infra/gitops/` 或等价 GitOps 仓库管理，实际运行状态由 Kubernetes 和 GitOps controller 管理。\n8. catalog 记录 owner、domain、runtime、namespace、deployment 和 GitOps 路径，但不直接承载 Deployment manifest。\n9. 平台团队维护模板、流水线和准入策略；服务团队维护服务代码和服务运行契约；环境 owner 维护环境级 overlay。\n\n## 10.10 可执行企业标准包\n\n本节把前文的架构原则转成可执行标准的第一批落地口径。它的目标不是把所有企业都锁死在同一个目录里，而是明确字段权威、模板骨架、自动化门禁和漂移检测规则，避免团队各写一份相似但互相冲突的 YAML。\n\n### 10.10.1 字段权威矩阵\n\n同一个字段只能有一个权威真相源。其他位置可以引用、派生、缓存或展示，但不能反向覆盖权威字段。\n\n| 对象 | 字段类型 | 权威真相源 | 可派生到 | 禁止事项 |\n| ---- | -------- | ---------- | -------- | -------- |\n| 领域 | domain id、边界、owner、上游、下游、能力地图 | `domains/{domain}/domain.yaml` | `catalog/domains/`、Developer Portal、治理看板 | 在 catalog 中重新定义领域边界 |\n| 服务 | 服务名、所属领域、owner、端口、健康检查、依赖、资源诉求、SLO、runbook | `domains/{domain}/services/{service}/service.yaml` | `catalog/components/`、CI、平台门户、生产就绪门禁 | 在 GitOps overlay 或 catalog 中改服务 owner 和领域 |\n| API | endpoint、operation、schema、版本、兼容策略、鉴权要求 | `contracts/apis/` 或 `domains/*/apis/` | API Portal、SDK 生成器、兼容性测试 | 只在 README 或代码注释里维护接口契约 |\n| 事件 | topic、schema、生产者、消费者、幂等键、兼容策略 | `contracts/events/` 或 `domains/*/events/` | Schema Registry、事件目录、消费者影响分析 | 未声明消费者就发布 breaking change |\n| 数据产品 | 产品身份、owner、语义粒度、质量规则、分级分类、血缘、freshness、AI 使用策略 | `domains/{domain}/data-products/{data-product}/data-product.yaml` | 数据目录、质量看板、AI 数据授权、成本看板 | 让数据目录替代数据产品契约 |\n| 数据契约 | schema、字段语义、兼容策略、访问策略、质量断言 | `contracts/datasets/` | 数据平台、Schema Registry、质量检查、权限网关 | 只在报表或口头口径里维护数据语义 |\n| AI 产品 | 风险等级、模型路由、Prompt 引用、RAG 引用、工具引用、评估集、护栏、人工确认 | `ai/applications/{ai-product}/ai-product.yaml` | AI catalog、LLM Gateway、Agent Runtime、审计系统 | 让 Agent 直接绕过领域 API 或工具注册表 |\n| AI 契约 | 工具输入输出、Prompt 版本、RAG 来源、评估集、护栏策略、微调数据授权 | `contracts/ai/` | AI 发布门禁、LLM Gateway、Tool Registry、审计系统 | 把 Prompt 或工具权限只藏在应用代码里 |\n| catalog | 展示名、生命周期、owner 引用、关系图、runtime 指针、scorecard 结果 | `catalog/`，其中关键字段从权威源生成或校验 | Developer Portal、审计报表、搜索和发现 | 把 catalog 当 Deployment、领域模型或数据契约真相源 |\n| GitOps | 环境、namespace、镜像 digest、replicas、资源 overlay、灰度策略 | `infra/gitops/environments/{env}/...` 或独立 GitOps 仓 | Argo CD / Flux、发布审计、回滚记录 | 在服务目录中硬编码环境差异 |\n| Kubernetes runtime | pod、deployment、service、live status、事件、当前副本和运行指标 | Kubernetes API 和可观测性平台 | 运行看板、SLO、事件响应 | 把运行时实际状态回写成 Git 中的期望状态 |\n| 治理规则 | 标准、门禁、例外、ADR、风险接受、复盘和到期时间 | `governance/` | CI、Policy as Code、审计系统、架构评审 | 口头豁免或永久例外 |\n\n字段流转规则：\n\n1. `domain.yaml`、`service.yaml`、`data-product.yaml` 和 `ai-product.yaml` 是产品团队维护的源头契约。\n2. `contracts/` 维护机器可校验的接口、事件、数据、AI 工具、Prompt、RAG 和策略契约。\n3. catalog 优先由源头契约和 `contracts/` 生成或校验，人工维护字段只限展示、分组、关系补充和生命周期说明。\n4. GitOps 只声明环境期望状态，不拥有服务业务身份、领域边界、API 语义和数据语义。\n5. Kubernetes 和可观测性平台只代表实际运行状态，不应反向改写 GitOps 期望状态。\n6. 治理规则必须能被 CI、Policy as Code、平台门户或审计系统消费，否则只是说明文。\n\n### 10.10.2 Starter Kit 最小模板\n\n企业启动试点时不应先创建完整目录树，而应先创建能被平台、catalog、GitOps 和治理门禁识别的最小模板。\n\n```text\ndomains/{domain}/domain.yaml\ndomains/{domain}/services/{service}/service.yaml\ndomains/{domain}/data-products/{data-product}/data-product.yaml\nai/applications/{ai-product}/ai-product.yaml\ncontracts/apis/{api}.openapi.yaml\ncontracts/events/{event}.asyncapi.yaml\ncontracts/ai/tools/{tool}.yaml\ncatalog/components/{service}.yaml\ncatalog/data-products/{data-product}.yaml\ncatalog/ai-products/{ai-product}.yaml\ngovernance/architecture-gates/production-readiness.yaml\ngovernance/ownership/raci.yaml\ngovernance/slo/tiering-policy.md\ngovernance/migration/deprecation-policy.md\ngovernance/evidence/releases/{service-release}.yaml\ngovernance/evidence/supply-chain/{service-attestation}.yaml\ngovernance/evidence/exceptions/{policy-exception}.yaml\ngovernance/evidence/compatibility/{api-or-event-report}.yaml\ngovernance/evidence/drift/{service-drift-report}.yaml\ngovernance/control-plane/conformance-profile.yaml\ngovernance/control-plane/control-plane.yaml\ngovernance/control-plane/release-gate-decision.yaml\ngovernance/control-plane/standards-baseline.yaml\ngovernance/control-plane/version-governance.yaml\ngovernance/evidence/verification/{baseline-verification-lock}.yaml\ngovernance/evidence/baselines/{baseline-artifact-inventory}.yaml\ngovernance/evidence/baselines/{baseline-release-evidence}.yaml\ngovernance/evidence/compatibility/{baseline-compatibility-ledger}.yaml\ngovernance/evidence/adoption/{baseline-adoption-ledger}.yaml\ngovernance/evidence/support/{baseline-support-matrix}.yaml\ngovernance/evidence/release-trains/{baseline-release-train}.yaml\ngovernance/evidence/communications/{baseline-notification-ledger}.yaml\ngovernance/evidence/rollback/{baseline-rollback-verification}.yaml\ngovernance/evidence/conformance/{baseline-conformance-claim}.yaml\ninfra/gitops/environments/dev/{domain}/{service}/kustomization.yaml\ninfra/gitops/environments/prod/{domain}/{service}/kustomization.yaml\n```\n\n`domain.yaml` 最低字段：\n\n```yaml\ndomain: order\nname: Order Domain\nowner: team-order\nlifecycle: production\nboundedContext: docs/domain-model.md\ncapabilities:\n - order-command\n - order-query\nupstream:\n - customer\ndownstream:\n - payment\n - fulfillment\nsloTier: tier-1\ndataClassification: internal\narchitectureDecision:\n - governance/decisions/adr-0001-order-boundary.md\n```\n\n`service.yaml` 最低字段：\n\n```yaml\nservice: order-command-service\ndomain: order\nowner: team-order\nlifecycle: production\ntier: tier-1\nruntime:\n type: kubernetes\n imageRepository: registry.company.com/order/order-command-service\n ports:\n http: 8080\n health:\n liveness: /healthz\n readiness: /readyz\nresources:\n requests:\n cpu: 200m\n memory: 256Mi\n limits:\n cpu: \"1\"\n memory: 1Gi\ndependencies:\n apis:\n - customer-profile-api\n events:\n publishes:\n - order-created\n subscribes:\n - payment-authorized\nslo:\n availability: 99.9\n latencyP95Ms: 300\nreliability:\n rto: 1h\n rpo: 15m\n onCall: governance/ownership/escalation-policy.md\n errorBudgetPolicy: governance/slo/error-budget-policy.md\n drillEvidence: governance/evidence/drills/order-command-service-2026-q2.md\nrunbook: docs/runbook.md\nrollback: docs/rollback.md\n```\n\n`data-product.yaml` 最低字段：\n\n```yaml\ndataProduct: order-facts\ndomain: order\nowner: team-order\nlifecycle: production\ntier: tier-2\nconsumers:\n - revenue-dashboard\n - customer-service-agent\nschema: schema/order-facts.schema.yaml\nsemanticGrain: one row per order state transition\nfreshness: 15m\nquality:\n completeness: \">= 99.5%\"\n validity: \">= 99.0%\"\n uniqueness: order_event_id\n accuracy: reconciled with payment settlement daily\nclassification:\n level: confidential\n pii:\n - customer_id\nretention: 2y\naccessPolicy:\n policy: governance/data-governance/order-facts-access.rego\n approvalRequired: true\naudit:\n enabled: true\n logRetention: 2y\nlineage:\n upstream:\n - order-command-service\n downstream:\n - revenue-dashboard\n - customer-service-agent\naiUsage:\n allowed:\n - rag\n - evaluation\n disallowed:\n - foundation-model-training\ncost:\n owner: team-order\n allocationTag: cost.domain.order\nslo:\n freshness: 15m\n availability: 99.5\n```\n\n`ai-product.yaml` 最低字段：\n\n```yaml\naiProduct: customer-service-agent\nowner: team-support-ai\nlifecycle: beta\nriskTier: R3\nbusinessGoal: assist support agents with grounded answers\nmodel:\n gatewayRoute: support-safe-default\n approvedModel: vendor-support-model\n modelVersion: \"2026-05\"\nprompts:\n system: prompts/system.prompt.md\nrag:\n sources: rag/sources.yaml\n vectorIndex: vector:customer-support-policy:v12\ntools:\n - tool: refund-preview\n riskLevel: high\n requiresHumanApproval: true\nevals:\n regression: evals/regression.yaml\n redTeam: evals/red-team.yaml\nguardrails:\n policy: guardrails/policy.rego\nobservability:\n traceRetentionDays: 180\n replayEnabled: true\nslo:\n taskCompletionRate: \">= 85%\"\n groundedAnswerRate: \">= 95%\"\n toolErrorRate: \"<= 2%\"\n p95LatencyMs: 6000\nbudget:\n monthlyUsd: 3000\n costPerSuccessfulTaskUsd: 0.12\n owner: team-support-ai\nfallback:\n degradedMode: human-support-queue\n humanHandoff: support-workbench\n rollbackPrompt: prompts/system.previous.prompt.md\nproviderPolicy:\n logRetention: 30d\n dataTrainingOptOut: true\n crossBorderReview: governance/security/cross-border-ai-review.md\ndataUsePolicy:\n allowed:\n - rag\n - evaluation\n disallowed:\n - foundation-model-training\nrunbook:\n incident: governance/playbooks/ai-incident-playbook.md\n rollback: docs/rollback.md\n```\n\nV2.82 starter kit 还提供以下可执行契约模板：\n\n1. `api-contract.yaml`：API producer、consumer、auth、版本和兼容策略。\n2. `event-contract.yaml`：事件 topic、schema、幂等键、投递语义和消费者。\n3. `ai-tool-contract.yaml`：AI 工具输入输出、风险等级、人工确认、权限、审计和运行限制。\n4. `rag-index-contract.yaml`：RAG 来源、Embedding、切分、访问控制、刷新和删除策略。\n5. `fine-tuning-contract.yaml`：微调数据授权、实验追踪、评估、发布门禁和回滚。\n6. `fine-tuning-run.yaml`：单次微调运行的数据授权、数据准备、实验 run、评估、模型登记、审批、灰度发布、监控和退役证据。\n7. `repository-change-control.yaml` 与 `repository-protection-runbook.md`：CODEOWNERS、受保护分支、PR 审查、必需检查、签名提交、禁止直推、发布 tag 保护、远端保护状态验证、标准整改、break-glass、POA&M 和风险登记。\n8. `gitops-deployment.yaml`：环境、namespace、镜像 digest、资源、ServiceAccount、Pod 安全、网络策略、HPA、PDB、配置引用、发布策略和供应链准入。\n9. `catalog-data-product.yaml`、`catalog-ai-product.yaml`：catalog 指针、owner、生命周期和运行索引。\n10. `scorecard.yaml`：生产就绪、供应链、运行证据和复审周期。\n11. `release-evidence.yaml`：发布版本、commit、GitOps revision、镜像 digest、catalog 指针、pipeline run、测试和批准证据。\n12. `supply-chain-attestation.yaml`：构建来源、source control、SLSA 等级、builder identity、SBOM、provenance、签名、证书、透明日志、漏洞扫描、OpenSSF Scorecard 和验签命令。\n13. `policy-exception.yaml`：治理例外、补偿控制、批准日期、到期日期、补救计划和过期自动阻断要求。\n14. `api-compatibility-report.yaml`：API 版本兼容、消费者影响、breaking change 明细、豁免状态和发布决策。\n15. `event-compatibility-report.yaml`：事件 Schema 兼容、消费者影响、重放要求、豁免状态和发布决策。\n16. `gitops-drift-report.yaml`：GitOps 期望状态、运行观测状态、镜像/config/policy 漂移和发布阻断决策。\n17. `extension-policy.yaml`：严格 schema 下的受控扩展前缀、审批记录、默认拒绝和未知字段行为。\n18. `feature-flag-control.yaml`：Feature Flag、评估上下文、灰度策略、Kill Switch、SLO 燃尽回滚和曝光事件。\n19. `ai-threat-model.yaml`：OWASP LLM / Agentic AI、MCP 工具边界、Prompt Injection 测试、红队结果和残余风险接受。\n20. `lineage-event.yaml`：数据产品运行血缘事件、producer job、run state、输入输出数据集、schema 和质量证据。\n21. `platform-product-metrics.yaml`：Platform PM、Golden Path、采用率、开发者满意度、认知负载、自助完成率和平台 SLO。\n22. `privacy-impact-assessment.yaml`：隐私影响评估、处理目的、合法基础、主体权利、删除传播和 AI 使用限制。\n23. `tenant-boundary.yaml`：租户、namespace、ServiceAccount、Secret 范围、ResourceQuota、NetworkPolicy 和准入策略。\n24. `recovery-drill-evidence.yaml`：恢复演练、RTO/RPO 目标、实际恢复结果、备份、恢复日志和复盘证据。\n25. `policy-test-report.yaml`：策略引擎、策略版本、测试总数、失败数、阻断决策和执行命令证据。\n26. `genai-observability-contract.yaml`：OpenTelemetry GenAI、模型路由、Token、成本、工具调用、RAG span、日志脱敏和留存。\n27. `ai-incident-playbook.yaml`：AI 事件响应 playbook、幻觉爆发、工具循环、RAG 索引污染、供应商中断、成本异常、检测、遏制、降级、回滚、工具 Kill Switch 和复盘。\n28. `cost-allocation-evidence.yaml`：成本周期、owner、allocation tag、标签覆盖率、未分摊成本、成本来源和优化行动。\n29. `identity-access-review.yaml`：身份源、角色、权限范围、特权身份、break-glass、MFA 和访问复核证据。\n30. `secrets-rotation-evidence.yaml`：Secret provider、KMS、静态加密、轮换周期、轮换结果和泄露扫描证据。\n31. `vulnerability-remediation-evidence.yaml`：漏洞 ID、严重度、KEV 状态、修复 SLA、残余风险和发布准入决策。\n32. `incident-postmortem.yaml`：单次事故影响、检测/恢复时间、根因、纠正行动、runbook 更新、门禁反哺和关闭审批；基线级闭合由 `baseline-incident-problem-corrective-action-ledger.yaml` 汇总证明。\n33. `evidence-freshness-policy.yaml`：证据最大年龄、按类型过期策略、必需证据、CI 执行和过期阻断策略。\n34. `control-evidence-map.yaml`：控制项 ID、证据路径、状态、新鲜度、必需性和阻断属性。\n35. `audit-export-manifest.yaml`：审计导出包范围、内容清单、验证结果、签名要求和留存复审。\n36. `control-assessment-report.yaml`：控制评估范围、评估人、控制结果、发现项、整改、剩余风险和签署状态。\n37. `baseline-change-record.yaml`：架构基线变更版本、前序版本、决策记录、影响分析、审批、验证命令、回滚计划和留存复审。\n38. `architecture-decision-record.yaml`：ADR 上下文、备选方案、取舍、决策、关联控制项、风险、POA&M、复审和留存。\n39. `oscal-export-profile.yaml`：OSCAL catalog、component-definition、SSP、assessment-results 和 POA&M 交换映射。\n40. `audit-export-gate.yaml`：internal-command://architecture/export-modern-architecture-audit、本地质量门禁、输出不变量、OSCAL 摘要一致性和留存复审。\n41. `audit-export-integrity.yaml`：审计导出生成物、SHA-256 摘要、源制品哈希和防篡改校验。\n42. `audit-export-provenance.yaml`：审计导出 subject、构建定义、导出命令、源码提交和源证据依赖追溯。\n43. `audit-export-signing-policy.yaml`：审计导出 provenance payload 摘要、Cosign 签名交接、验签命令和本地门禁边界。\n44. `audit-export-signature-receipt.yaml`：审计导出外部签名完成后的 payload 摘要、bundle 摘要、证书身份、透明日志和验签结果。\n45. `poam-record.yaml`：POA&M 发现项、责任人、整改行动、里程碑、证据、签署和复审。\n46. `risk-register.yaml`：企业架构风险、处理策略、关联控制项、关联 POA&M、缓解行动、残余风险和复审。\n47. `ai-evidence.yaml`：AI 产品证据账本、模型、Prompt、RAG、工具、评估、威胁模型、观测、事件响应、数据使用、审批、留存和复审。\n48. `conformance-profile.yaml`：资产合规等级、风险画像、数据敏感度、AI 风险、监管强度、必须门禁和裁剪边界。\n49. `control-plane.yaml`：企业执行控制面总账、控制项、证据、owner、阻断级别、自动化状态、复核周期和退出标准。\n50. `release-gate-decision.yaml`：门禁决策、通过、阻断、条件放行、例外、break-glass、回滚要求和复核证据。\n51. `standards-baseline.yaml`：外部标准版本、稳定性分级、采纳等级、适用范围、复核周期、升级门禁和回滚策略。\n52. `version-governance.yaml`：基线身份、发布通道、源 commit、release tag、兼容窗口、冻结策略、升级门禁和回滚入口。\n53. `baseline-release-evidence.yaml`：基线晋级决策、不可变引用、漂移复核、冻结检查、审计导出摘要、验签结果和回滚验证。\n54. `baseline-compatibility-ledger.yaml`：消费者影响、受影响契约、迁移状态、弃用截止、例外、POA&M 和风险接受。\n55. `baseline-adoption-ledger.yaml`：基线采用范围、采纳目标、当前基线、目标基线、采纳状态、逾期、例外和整改证据。\n56. `baseline-support-matrix.yaml`：基线支持状态、维护窗口、安全补丁、EOL、冻结口径、最低可接受基线和例外。\n57. `baseline-release-train.yaml`：基线候选窗口、冻结窗口、晋级日期、通知节奏、黑窗、紧急补丁和发布日历。\n58. `baseline-conformance-claim.yaml`：资产声明基线、适用门禁、证据路径、例外、签署、复核和采纳总账回写。\n59. `baseline-artifact-inventory.yaml`：基线源制品、schema、示例、控制项、证据模板、脚本、生成物、外部引用、SHA-256、签名状态和导出关系。\n60. `baseline-verification-lock.yaml`：基线校验命令、runner 镜像、工具版本、策略包、schema validator、签名验签工具和审计导出生成环境。\n61. `baseline-notification-ledger.yaml`：基线通知对象、通知渠道、送达回执、影响确认、异议、补发、例外审批和冻结前完成状态。\n62. `baseline-exception-ledger.yaml`：基线级例外来源、受影响资产、owner、到期、风险接受、POA&M、补偿控制、阻断状态和关闭证据。\n63. `baseline-rollback-verification.yaml`：上一基线、回滚目标 tag/commit、GitOps revision、审计导出恢复、烟测结果、恢复耗时、验证时效和阻断策略。\n64. `baseline-readiness-scorecard.yaml`：基线晋级硬门禁、评分维度、证据路径、权重、阈值、阻断项和 baseline/frozen 最终判定。\n65. `baseline-lifecycle-state-machine.yaml`：基线状态集合、允许迁移、禁止迁移、前置证据、审批责任、状态回写和迁移审计记录。\n66. `baseline-state-reconciliation-report.yaml`：跨账本状态对账、状态漂移检测、状态回写结果、审计导出状态一致性和阻断决策。\n67. `baseline-eol-retirement-certificate.yaml`：旧基线退役对象、生产引用清零、迁移关闭、例外清零、审计归档和新采用阻断证明。\n68. `baseline-review-board-decision.yaml`：基线会审范围、证据核验、投票签署、反对意见、条件动作、风险接受和最终裁决证明。\n69. `baseline-evidence-trace-graph.yaml`：基线证据节点、依赖边、摘要一致性、下游消费、状态传播和断链阻断证明。\n70. `baseline-gate-execution-report.yaml`：基线门禁命令、runner 镜像、策略包、schema 包、输入摘要、逐条规则结果、退出码、重放结果和最终决策证明。\n71. `baseline-publish-transaction.yaml`：基线提交前检查、干净工作树、source commit、签名 tag、远端 ref、push 回执、保护规则、禁推资产排除和发布后验证证明。\n72. `baseline-revocation-record.yaml`：基线撤销触发、隔离范围、受影响引用、通知确认、恢复目标、风险接受、状态回写和审计归档证明。\n73. `baseline-enforcement-policy.yaml`：基线最低版本、支持状态、撤销/EOL 状态、资产声明、例外有效期、GitOps / catalog / Golden Path 准入阻断证明。\n74. `baseline-consumption-lock.yaml`：资产消费端锁定 baseline ID、source commit、release tag、证据图摘要、制品清单摘要、验证锁摘要、准入策略摘要和过期复核证明。\n75. `baseline-migration-work-order.yaml`：目标资产、当前基线、目标基线、迁移步骤、依赖、GitOps 变更、消费锁更新、验收证据和回滚动作证明。\n76. `baseline-migration-execution-receipt.yaml`：迁移实际命令、执行人、执行环境、before/after 摘要、GitOps revision、catalog/lock diff、验收日志和回滚验证证明。\n77. `baseline-local-artifact-boundary.yaml`：本地私有 starter kit、生成 JSON、校验脚本、禁推原因、摘要留存、允许用途、远端排除和审计留存证明。\n78. `audit-export-exclusion-manifest.yaml`：审计导出原文白名单、摘要留存项、强制排除项、签名 payload 排除项和导出后验证证明。\n79. `private-artifact-escrow-manifest.yaml`：本地私有和禁推可执行资产的私有制品库引用、不可变摘要、访问控制、留存、取回和恢复验证证明。\n80. `baseline-clean-room-reconstruction-receipt.yaml`：干净 runner 从远端 commit、私有托管制品和锁定工具链重建基线、审计导出和门禁结果的证明。\n81. `baseline-evidence-archive-receipt.yaml`：基线关键证据进入不可变留存库、对象锁、WORM、legal hold、访问日志、删除保护和恢复演练的证明。\n82. `baseline-signature-ltv-receipt.yaml`：基线签名材料的长期验签证明，覆盖证书链、透明日志、时间戳、撤销状态、验证工具和归档引用。\n83. `baseline-runtime-admission-receipt.yaml`：基线运行时准入证明，覆盖 Kubernetes admission、策略引擎、镜像 digest、签名/provenance/SBOM、消费锁、撤销/EOL 阻断和拒绝样例。\n84. `baseline-runtime-admission-decision-ledger.yaml`：基线运行时准入决策总账，覆盖 Kubernetes audit requestUID、admission webhook、策略规则、actor、allow/deny、PolicyReport、OPA decision log、原始日志摘要和留存位置。\n85. `baseline-continuous-control-monitoring-ledger.yaml`：基线连续控制监测总账，覆盖关键控制项、监测指标、日志源、告警规则、监测窗口、owner、漂移事件、处置工单、MTTD/MTTR 和证据新鲜度。\n86. `baseline-control-assurance-sampling-ledger.yaml`：基线独立控制保证抽样总账，覆盖独立评估人、评估范围、控制总体、抽样方法、样本证据、设计有效性、运行有效性、发现项、整改、残余风险、签署和 OSCAL Assessment Results。\n87. `baseline-control-inheritance-ledger.yaml`：基线共享责任与继承控制总账，覆盖公共控制、继承控制、共享责任、消费者义务、责任边界、继承条件、证据来源、有效期、失效条件和审计映射。\n88. `baseline-data-residency-transfer-ledger.yaml`：基线数据驻留与跨境处理总账，覆盖数据类别、监管区域、允许区域、实际存储/处理/备份/日志/向量索引/模型供应商区域、传输机制、子处理方、补充保护措施、删除传播和区域漂移阻断。\n89. `baseline-third-party-risk-ledger.yaml`：基线第三方与关键供应商风险总账，覆盖关键供应商分级、服务范围、受影响资产、数据类别、合同控制、DPA/SLA、审计权、保证报告、集中度、退出计划、替代路径、连续性、供应商事件和失效阻断。\n90. `baseline-operational-resilience-ledger.yaml`：基线运营韧性与重要业务服务影响容忍总账，覆盖重要业务服务、影响容忍、BIA、端到端依赖、严重但合理场景、恢复演练、人工替代、沟通计划、第三方依赖、超限升级和韧性缺口阻断。\n91. `baseline-regulatory-obligation-ledger.yaml`：基线监管与合规义务可追溯总账，覆盖义务源、司法辖区、适用资产、控制目标、控制项映射、证据映射、owner、例外、POA&M、监管变更和生效期限。\n92. `baseline-records-retention-legal-hold-ledger.yaml`：基线记录留存、法律保全与可防御删除总账，覆盖记录类别、留存排期、义务来源、司法辖区、legal hold、删除资格、删除传播、备份/日志/向量索引处置、保全解除和可防御删除回执。\n93. `baseline-privacy-rights-consent-ledger.yaml`：基线隐私权利请求、同意偏好与合法基础执行总账，覆盖处理目的、合法基础、同意版本、同意撤回、偏好传播、权利请求 SLA、自动化决策复核、第三方传播和下游处理阻断。\n94. `baseline-processing-activity-inventory-ledger.yaml`：基线处理活动、个人数据清单与 RoPA 覆盖总账，覆盖处理活动、数据主体类别、个人数据类别、角色、接收方、跨境传输、保留映射、DPIA、合法基础、AI/数据产品用途和发现覆盖。\n95. `baseline-identity-entitlement-access-ledger.yaml`：基线身份权限、特权访问与工作负载身份总账，覆盖人类身份、服务账号、工作负载身份、JML、MFA、PAM/JIT、break-glass、最小权限、孤儿账号、过期权限和运行时身份绑定。\n96. `baseline-asset-criticality-classification-ledger.yaml`：基线资产关键性、数据分类与风险分级总账，覆盖资产 owner、业务关键性、SLO Tier、L3/L4 合规等级、CIA 影响、数据敏感度、监管暴露、AI 风险、互联网暴露、第三方关键性和复核状态。\n97. `baseline-cryptographic-secrets-key-certificate-ledger.yaml`：基线密码材料、密钥、证书与秘密生命周期总账，覆盖 KMS/HSM key、TLS 证书、签名密钥、API token、数据库凭据、webhook secret、工作负载密钥、算法强度、托管位置、轮换、过期、吊销、泄露响应和访问边界。\n98. `baseline-backup-restore-disaster-recovery-ledger.yaml`：基线备份、恢复、灾备与可恢复性验证总账，覆盖关键系统、数据库、对象存储、配置仓库、消息队列、向量索引、审计证据、备份策略、不可变/离线副本、跨区域隔离、恢复演练、RTO/RPO、完整性校验、勒索隔离和恢复权限。\n99. `baseline-service-reliability-slo-error-budget-observability-ledger.yaml`：基线服务可靠性、SLO、错误预算与可观测性总账，覆盖生产服务、关键用户旅程、SLI/SLO、错误预算、告警路由、on-call、runbook、合成探测、遥测覆盖、仪表盘和降级策略。\n100. `baseline-capacity-performance-cost-efficiency-ledger.yaml`：基线容量、性能、弹性伸缩与成本效率总账，覆盖关键服务、关键用户旅程、容量预测、压测、性能基准、资源 requests/limits、HPA/VPA/KEDA、队列和数据库容量、预算、单位经济、成本分摊、异常成本和优化行动。\n101. `baseline-threat-model-attack-surface-risk-ledger.yaml`：基线威胁建模、攻击面与安全风险总账，覆盖关键服务、API、事件、数据产品、AI 产品、GitOps 入口、平台共享能力、信任边界、数据流、攻击面、滥用场景、安全测试、剩余风险、POA&M 和签署状态。\n102. `baseline-vulnerability-exposure-remediation-ledger.yaml`：基线漏洞、暴露面与修复验证总账，覆盖 CVE、KEV、EPSS、CVSS、VEX/CSAF、SBOM/SCA、容器镜像、IaC、Kubernetes、云配置、外部暴露、API/AI 工具入口、修复 SLA、复测、例外和发布准入。\n103. `baseline-secure-configuration-posture-drift-ledger.yaml`：基线安全配置、加固姿态与配置漂移修复总账，覆盖 CIS/NIST/SCAP、Pod Security、OS、容器、Kubernetes、云账号、IAM、网络、存储、数据库、CI/CD、API Gateway、LLM Gateway、Agent Runtime、审计日志、加密配置、漂移、修复、例外和发布准入。\n104. `baseline-production-change-release-ledger.yaml`：基线生产变更、发布编排、变更冲突与失败恢复总账，覆盖代码部署、GitOps 同步、数据库迁移、配置变更、Feature Flag、Prompt/模型变更、紧急变更、黑窗、冲突检测、回滚、失败恢复、事故关联和 DORA 指标回写。\n105. `baseline-incident-problem-corrective-action-ledger.yaml`：基线事故、问题、纠正行动与复发防止总账，覆盖生产事故、安全事件、隐私事件、AI 事件、供应商事件、near miss、严重度、影响、时间线、MTTD/MTTR、RCA、问题记录、纠正行动、复发防止、runbook 更新、告警调整、门禁反哺、沟通和 DORA 恢复指标。\n106. `baseline-data-product-quality-contract-observability-ledger.yaml`：基线数据产品质量、契约违约、运行血缘与可观测性总账，覆盖数据产品 owner、契约版本、schema drift、质量断言、freshness、完整性、唯一性、语义口径、访问授权、运行血缘、消费者影响、AI/特征/RAG 使用、契约违约、修复复测和数据质量事故。\n107. `baseline-engineering-quality-test-release-verification-ledger.yaml`：基线工程质量、测试证据、缺陷与发布验证总账，覆盖资产 owner、需求追踪、测试策略、单元/集成/契约/E2E/回归/验收测试、覆盖率、测试环境、测试数据、flaky 测试、缺陷分级、修复复测、发布前验证、灰度/冒烟结果和质量风险接受。\n108. `baseline-workforce-competency-training-duty-segregation-ledger.yaml`：基线人员能力、培训、职责履职与职责分离总账，覆盖关键角色任命、岗位资格、职责确认、培训完成、专项训练、on-call 资格、审批授权、代理授权、职责分离、冲突角色、备份人员和到期复核。\n109. `baseline-business-outcome-value-realization-portfolio-ledger.yaml`：基线业务结果、价值实现与组合收益总账，覆盖业务目标、价值假设、收益 owner、投资组合、关键结果、前后基线、采用证据、收益实现、成本效率、风险接受和停投/加投决策。\n110. `baseline-value-stream-journey-process-ledger.yaml`：基线价值流、关键旅程与端到端流程总账，覆盖价值流、客户旅程、BPMN/流程模型、流程 owner、触发事件、完成定义、跨域交接、步骤级遥测、瓶颈、异常、人工兜底、控制点和改进动作。\n111. `baseline-architecture-view-runtime-topology-dependency-ledger.yaml`：基线架构视图、运行拓扑与依赖影响总账，覆盖架构视图、C4/部署视图、catalog 声明依赖、运行时观测依赖、GitOps 拓扑、数据/AI/第三方依赖、关键路径、blast radius、变更影响、依赖 owner、漂移和复核状态。\n112. `baseline-quality-attribute-architecture-driver-tradeoff-ledger.yaml`：基线质量属性、架构驱动与权衡决策总账，覆盖业务驱动、质量属性场景、响应指标、架构驱动、敏感点、权衡点、备选方案、ADR、适配度函数、验证证据和复核状态。\n113. `baseline-architecture-principle-constraint-exception-ledger.yaml`：基线架构原则、约束、反模式与例外执行总账，覆盖原则、owner、适用范围、强制约束、禁止项、反模式、检测方式、门禁入口、违反处置、例外、风险接受、ADR 和复核状态。\n114. `baseline-ai-system-regulatory-impact-ledger.yaml`：AI 系统监管分类与影响评估总账，覆盖 AI 系统用途、部署角色、适用法规、风险分类、禁止/高风险/通用目的 AI 判断、人工监督、日志留存、技术文档、数据治理、透明度、后市场监测、供应商责任和合规缺口。\n115. `baseline-version-policy-release-control-ledger.yaml`：基线版本策略、发布通道、兼容性与冻结控制总账，覆盖版本号语义、发布通道、变更分类、签名 tag、兼容窗口、消费锁、迁移、冻结、紧急补丁、撤销和 EOL 阻断状态。\n\n### 10.10.3 自动化门禁映射\n\n门禁必须尽量前移到提交、构建、发布和运行阶段。人工评审只处理边界争议、风险接受和复杂权衡。\n\n| 阶段 | 自动化门禁 | 输入 | 阻断条件 |\n| ---- | ---------- | ---- | -------- |\n| 提交 | Markdown、YAML、Schema、Policy 语法检查 | 文档、契约、策略文件 | 语法错误、坏链接、缺失必填字段 |\n| Pull Request | API / Event / Data / AI 契约兼容性检查 | `contracts/`、`domains/`、`ai/`、兼容性报告 | breaking change 无消费者影响分析 |\n| 构建 | 单元测试、依赖锁定、漏洞、许可证、密钥扫描 | 源码、锁文件、Dockerfile | 高危漏洞、未知许可证、密钥泄露 |\n| 制品 | SBOM、provenance、镜像签名、基础镜像策略 | 镜像、构建日志、制品摘要、供应链证明 | 无 SBOM、无签名、来源不可证明 |\n| 基线制品清单 | 源文档、schema、示例、控制项、证据模板、脚本、生成物、外部引用和摘要 | `baseline-artifact-inventory.yaml`、Git tree、starter kit、审计导出 | 基线包含未登记文件、必需制品摘要漂移、导出包缺源制品、签名覆盖不完整 |\n| 基线验证环境 | 校验命令、runner 镜像、工具版本、策略包、schema validator、验签工具和生成环境 | `baseline-verification-lock.yaml`、CI runner、Makefile、policy bundle、validator | runner 未锁定、工具版本漂移、策略包摘要不一致、验签工具未固定 |\n| 漏洞修复 | CVE / KEV、修复 SLA、残余风险、发布准入 | `vulnerability-remediation-evidence.yaml`、扫描器、制品库 | 高危漏洞未修复、SLA 超期、残余风险无审批 |\n| 基线漏洞、暴露面与修复验证 | CVE / KEV / EPSS / CVSS、VEX/CSAF、扫描覆盖、外部暴露、owner、修复 SLA、复测、例外和发布准入 | `baseline-vulnerability-exposure-remediation-ledger.yaml`、SBOM、SCA、容器扫描、IaC 扫描、云安全态势、外部攻击面、漏洞平台、VEX/CSAF | critical/KEV 未关闭、互联网暴露 high 未关闭、扫描覆盖缺口、修复未复测、例外过期、VEX/CSAF 状态缺失 |\n| 基线安全配置、加固姿态与配置漂移 | CIS/NIST/SCAP、Pod Security、OS、容器、Kubernetes、云、IAM、网络、存储、数据库、CI/CD、API Gateway、LLM Gateway、Agent Runtime、审计日志、加密配置、漂移、修复、例外和发布准入 | `baseline-secure-configuration-posture-drift-ledger.yaml`、CIS Benchmarks、SCAP、CSPM、KSPM、IaC policy scan、runtime admission、Kubernetes audit、配置漂移报告 | 安全配置基线缺失、critical 配置漂移开放、特权 Pod 未批准、公共存储暴露、弱 TLS、审计日志关闭、漂移未复测、例外过期或未进入 release gate |\n| 发布 | GitOps diff、策略准入、资源配额、SLO 和 runbook 校验 | GitOps overlay、catalog、service.yaml、发布证据 | 无 owner、无 runbook、无 digest、资源未声明 |\n| 基线威胁建模与攻击面 | 关键服务、API、事件、数据产品、AI 产品、GitOps 入口、信任边界、攻击面、滥用场景、安全测试和剩余风险 | `baseline-threat-model-attack-surface-risk-ledger.yaml`、catalog、API inventory、data flow diagram、security test evidence、risk register | 威胁模型缺失或过期、互联网暴露未知、信任边界未映射、高风险数据流无缓解、关键滥用场景未关闭、安全测试缺失或剩余风险未签署 |\n| 基线数据产品质量与契约 | 数据产品契约、schema drift、质量断言、freshness、血缘、消费者影响、AI/特征/RAG 使用和修复复测 | `baseline-data-product-quality-contract-observability-ledger.yaml`、data product contracts、OpenLineage events、data quality reports、data catalog、AI evidence ledger、incident ledger | 数据产品无契约、owner 缺失、schema drift 开放、freshness/质量断言失败、血缘缺口、消费者未通知、AI/RAG 使用未授权或契约违约未关闭 |\n| 基线工程质量与发布验证 | 需求追踪、测试计划、单元/集成/契约/E2E/回归/验收测试、覆盖率、flaky、缺陷、修复复测、发布前验证、灰度/冒烟和质量风险接受 | `baseline-engineering-quality-test-release-verification-ledger.yaml`、CI reports、test reports、coverage reports、contract test results、defect tracker、release evidence、canary/smoke reports | 关键测试缺失、覆盖率低于阈值、flaky 未治理、critical/high 缺陷开放、修复未复测、发布验证缺失或质量风险未签署 |\n| 基线人员能力与职责分离 | 关键角色任命、职责确认、岗位资格、培训完成、专项训练、on-call 资格、审批授权、代理授权、职责分离、冲突角色和备份覆盖 | `baseline-workforce-competency-training-duty-segregation-ledger.yaml`、HRIS、LMS、IAM/PAM、RACI、on-call roster、approval log、access review、review board decision | 关键角色未任命、培训过期、专项资格缺失、职责未确认、on-call 未认证、审批人与执行人未分离、冲突角色未关闭、代理授权过期或关键岗位无人备份 |\n| 基线业务结果与价值实现 | 业务目标、价值假设、收益 owner、投资组合、关键结果、前后基线、采用证据、收益实现、成本效率、风险接受和停投/加投决策 | `baseline-business-outcome-value-realization-portfolio-ledger.yaml`、OKR/KPI、portfolio backlog、product analytics、adoption ledger、FinOps unit economics、release evidence、review board decision | 无业务目标、价值假设无 owner、关键结果不可测、前后基线缺失、收益未实现且无决策、成本效率不可解释或停投/加投决策缺失 |\n| 基线价值流与端到端流程 | 价值流、客户旅程、BPMN/流程模型、流程 owner、触发事件、完成定义、步骤级遥测、跨域交接、瓶颈、异常、人工兜底、控制点和改进动作 | `baseline-value-stream-journey-process-ledger.yaml`、BPMN/process model、journey analytics、OpenTelemetry traces、process mining、business outcome ledger、service reliability ledger、operational resilience ledger | 关键旅程无 owner、流程模型过期、步骤遥测缺失、跨域交接不可追踪、瓶颈未处置、异常未闭环、人工兜底未演练 |\n| 基线架构视图与依赖影响 | 架构视图、C4/部署视图、catalog 声明依赖、运行时观测依赖、GitOps 拓扑、数据/AI/第三方依赖、关键路径、blast radius、变更影响、依赖 owner 和漂移处置 | `baseline-architecture-view-runtime-topology-dependency-ledger.yaml`、C4/architecture views、Backstage catalog、CMDB、GitOps、OpenTelemetry traces、service mesh telemetry、OpenLineage、dependency scanner、incident ledger | 架构视图过期、声明依赖和观测依赖不一致、关键依赖无 owner、未知调用开放、GitOps 拓扑不可追踪、blast radius 未评估或依赖漂移未关闭 |\n| 基线质量属性与权衡决策 | 业务驱动、质量属性场景、优先级、响应指标、架构驱动、敏感点、权衡点、备选方案、ADR、适配度函数、验证证据和复核状态 | `baseline-quality-attribute-architecture-driver-tradeoff-ledger.yaml`、quality scenarios、ATAM review、ADR、SLO、load test、security test、resilience exercise、FinOps evidence、business outcome ledger | 高优先级质量属性无场景、响应指标不可测、关键权衡无 ADR、敏感点无监测、适配度函数未进入门禁、验证证据过期或权衡风险未签署 |\n| 基线架构原则与约束执行 | 原则、owner、适用范围、强制约束、禁止项、反模式、检测方式、门禁入口、违反处置、例外、风险接受、ADR 和复核状态 | `baseline-architecture-principle-constraint-exception-ledger.yaml`、architecture principles、standards baseline、policy tests、ADR、risk register、exception ledger、gate execution report、review board decision | 强制原则无 owner、原则不可检测、禁止项未进入门禁、违反项无处置、反模式无检测、例外过期、风险接受缺失或原则总账未进入 release gate |\n| 基线版本策略与发布控制 | 版本号语义、发布通道、Conventional Commit 分类、签名 tag、兼容窗口、消费锁、迁移窗口、冻结规则、紧急补丁、撤销隔离和 EOL 阻断 | `baseline-version-policy-release-control-ledger.yaml`、version governance、publish transaction、compatibility ledger、support matrix、adoption ledger、consumption lock、migration work order、revocation record | 版本号复用、浮动版本引用、tag 漂移、未签名生产 tag、breaking change 无迁移窗口、冻结期语义变更、紧急补丁未复盘、撤销/EOL 基线仍被采用或禁推资产进入发布载荷 |\n| 基线发布 | 晋级决策、冻结复核、漂移检查、不可变引用、签名验签和回滚验证 | `baseline-release-evidence.yaml`、`version-governance.yaml`、审计导出、Git tag | 无晋级证据、tag 与 commit 不一致、漂移复核缺失、回滚未验证 |\n| 基线发布事务 | 提交前检查、干净工作树、source commit、签名 tag、远端 ref、push 回执、保护规则、禁推资产排除和发布后验证 | `baseline-publish-transaction.yaml`、Git remote refs、repository protection、release evidence、version governance | 未完成 push、远端 ref 不存在、tag 未签名、工作树脏、保护规则失效、禁推资产进入远端或发布后验证失败 |\n| 基线撤销隔离 | 撤销触发、隔离范围、受影响引用、通知确认、恢复目标、风险接受、状态回写和审计归档 | `baseline-revocation-record.yaml`、support matrix、adoption ledger、publish transaction、release evidence、risk register | 坏基线无法隔离、签名泄露后仍允许采用、禁推资产误入后无通知、恢复目标未验证或审计归档缺失 |\n| 基线准入执行 | 最低可接受基线、支持状态、撤销/EOL 状态、资产符合性声明、例外有效期和运行入口阻断 | `baseline-enforcement-policy.yaml`、support matrix、adoption ledger、conformance claim、revocation record、exception ledger、GitOps、catalog | 低于最低基线仍可部署、撤销/EOL 基线仍可新采用、资产无声明仍通过、过期例外仍放行、策略引擎未记录决策 |\n| 基线消费锁定 | 资产消费端的 baseline ID、source commit、release tag、证据摘要、锁文件签署、过期复核和 rollup 回写 | `baseline-consumption-lock.yaml`、conformance claim、adoption ledger、release evidence、evidence trace graph、catalog、GitOps | 只写 `V2.x` 浮动版本、锁摘要与发布证据不一致、锁文件过期、锁文件未回写采纳总账或 catalog |\n| 基线迁移执行 | 目标资产、当前基线、目标基线、迁移步骤、依赖、GitOps 变更、消费锁更新、验收证据和回滚动作 | `baseline-migration-work-order.yaml`、adoption ledger、compatibility ledger、consumption lock、GitOps、catalog、release gate | 采纳总账要求迁移但无工单、工单无 owner 或截止时间、迁移步骤未执行、消费锁未更新、GitOps 指针未变更、验收证据或回滚动作缺失 |\n| 基线迁移回执 | 实际命令、执行人、执行环境、before/after 摘要、GitOps revision、catalog/lock diff、验收日志和回滚验证 | `baseline-migration-execution-receipt.yaml`、work order、CI logs、GitOps diff、catalog diff、consumption lock、rollback verification | 工单完成但无执行日志、执行 actor 不可追溯、before/after 摘要不一致、验收日志缺失或回滚未验证 |\n| 本地私有制品边界 | 本地私有 starter kit、生成 JSON、校验脚本、分类、禁推原因、摘要留存、允许用途、远端排除和审计留存 | `baseline-local-artifact-boundary.yaml`、artifact inventory、publish transaction、verification lock、audit export、git status | 可执行资产不进远程但无边界说明、exclude pattern 无 owner、私有制品被误签名或审计导出误包含 |\n| 审计导出排除 | 原文白名单、摘要留存项、强制排除项、签名 payload 排除项和导出后验证 | `audit-export-exclusion-manifest.yaml`、local artifact boundary、audit export manifest、integrity、provenance、signing policy | 审计包误含私有原文、payload 排除不清、摘要留存和边界证据不一致 |\n| 私有制品托管 | 私有 registry / 制品库引用、不可变摘要、访问控制、留存期限、取回命令、恢复验证和摘要一致性 | `private-artifact-escrow-manifest.yaml`、local artifact boundary、artifact inventory、verification lock、release gate、audit export exclusion | 禁推资产只有本地副本、私有制品库缺引用、权限不可审计、留存过期、取回失败或摘要与边界证据不一致 |\n| 干净环境基线重建 | 远端 checkout、私有制品取回、摘要校验、审计导出重建、门禁重放和禁推资产复核 | `baseline-clean-room-reconstruction-receipt.yaml`、verification lock、artifact inventory、private artifact escrow、audit export、gate execution | 重建依赖个人工作区、私有制品未按摘要恢复、重建审计导出摘要漂移、门禁重放失败或禁推资产误入远端 |\n| 基线证据不可变归档 | 审计证据对象、不可变存储引用、WORM/对象锁、留存到期、legal hold、访问日志、删除保护和恢复演练 | `baseline-evidence-archive-receipt.yaml`、audit export、integrity、provenance、signature receipt、release evidence、gate execution、clean-room reconstruction | 证据只留在 CI 临时目录、归档对象可改写、留存策略未锁、legal hold 缺失、访问日志不可审计、恢复演练失败 |\n| 基线长期验签 | 签名 bundle、证书链、OIDC 身份、透明日志、signed entry timestamp、RFC3161 TSA、撤销状态、工具版本和归档引用 | `baseline-signature-ltv-receipt.yaml`、signature receipt、provenance、artifact inventory、verification lock、evidence archive、release evidence | 当前验签通过但缺少长期验证材料、证书过期后无法证明签名时间、透明日志 proof 丢失、撤销状态未知、验签工具漂移 |\n| 基线运行时准入 | Kubernetes admission、策略引擎、策略 bundle、命名空间范围、镜像 digest、签名验签、provenance、SBOM、消费锁、撤销/EOL 阻断和拒绝样例 | `baseline-runtime-admission-receipt.yaml`、baseline enforcement policy、GitOps、cluster admission logs、signature receipt、consumption lock、release evidence | 发布前门禁通过但集群未启用 admission、策略包漂移、未签名镜像被创建、digest/provenance 不匹配、撤销/EOL 基线仍能运行或过期例外仍被放行 |\n| 基线准入决策总账 | Kubernetes audit、admission webhook、PolicyReport、OPA decision log、requestUID、actor、namespace、workload、镜像 digest、allow/deny 和原始日志摘要 | `baseline-runtime-admission-decision-ledger.yaml`、`baseline-runtime-admission-receipt.yaml`、Kubernetes audit logs、Kyverno PolicyReports、OPA decision logs、Sigstore Policy Controller events | 有回执无逐条决策、拒绝样例缺原始日志、allow 事件无法追到策略版本、审计日志和策略引擎决策不一致 |\n| 基线连续控制监测 | 关键控制项、监测指标、日志源、告警规则、监测窗口、owner、漂移事件、处置工单、MTTD/MTTR 和证据新鲜度 | `baseline-continuous-control-monitoring-ledger.yaml`、control plane、observability、Prometheus / Alertmanager、OpenTelemetry、SIEM、POA&M | 发布后控制失效无人发现、critical drift 未告警、处置工单缺失、证据过期仍放行、控制运行 SLO 失守 |\n| 基线独立控制保证 | 独立评估人、评估目标、控制总体、抽样方法、样本证据、设计有效性、运行有效性、发现项、整改、残余风险和签署 | `baseline-control-assurance-sampling-ledger.yaml`、control assessment report、OSCAL assessment-results、POA&M、risk register | 控制证据由平台自证、评估人不独立、样本不可复现、critical 控制未抽样、设计或运行有效性失败仍放行 |\n| 基线共享责任与继承控制 | 公共控制、继承控制、共享责任、消费者义务、控制承担方、继承方、证据引用、有效期、失效条件和例外闭环 | `baseline-control-inheritance-ledger.yaml`、control plane、control evidence map、baseline conformance claim、cloud provider attestation、third-party assurance report、POA&M | 公共控制被口头继承、消费者义务未配置、云/第三方责任无人复核、继承证据过期、失效控制仍被资产声明采用 |\n| 基线数据驻留与跨境处理 | 数据类别、监管区域、存储/处理/备份/日志/向量索引/模型供应商区域、传输机制、子处理方、补充保护措施和删除传播 | `baseline-data-residency-transfer-ledger.yaml`、privacy impact assessment、data product contract、AI evidence ledger、RAG contract、subprocessor register、transfer impact assessment | 数据实际区域不明、备份或日志跨区、RAG 索引跨境、模型供应商处理位置未批准、传输机制缺失、补充措施失效仍放行 |\n| 基线第三方与关键供应商风险 | 供应商分级、服务范围、受影响资产、合同控制、DPA/SLA、审计权、保证报告、数据类别、集中度、退出计划、替代路径、连续性和供应商事件 | `baseline-third-party-risk-ledger.yaml`、supplier register、contract register、DPA/SLA、third-party assurance report、control inheritance ledger、data residency ledger、AI evidence ledger、risk register、POA&M | 关键供应商未批准、合同控制或审计权缺失、保证报告过期、集中度超阈值、退出计划不可执行、供应商事故或开放发现项未阻断 |\n| 基线运营韧性与重要业务服务 | 重要业务服务、影响容忍、BIA、端到端依赖、严重但合理场景、场景测试、恢复能力、人工替代、沟通计划、第三方依赖和超限升级 | `baseline-operational-resilience-ledger.yaml`、BIA、service catalog、SLO/RTO/RPO、recovery drills、third-party risk ledger、data residency ledger、AI evidence ledger、incident playbook、communications plan、POA&M | 重要业务服务未识别、影响容忍缺失、依赖链不完整、场景测试失败、恢复结果超出容忍、供应商或 AI 依赖未纳入测试、韧性缺口无整改或风险接受 |\n| 基线容量、性能与成本效率 | 容量预测、压测、性能基准、资源 requests/limits、HPA/VPA/KEDA、队列积压、数据库容量、预算、单位经济、成本分摊、异常成本和优化行动 | `baseline-capacity-performance-cost-efficiency-ledger.yaml`、service.yaml、GitOps、Kubernetes ResourceQuota、HPA/VPA/KEDA、load test report、APM、OpenTelemetry、OpenCost、FOCUS dataset、FinOps budget、cost allocation evidence | 关键服务无容量模型、压测过期、p95/p99 退化、资源未声明、自动扩缩容缺失、队列积压不可解释、数据库容量不足、预算超支无审批、单位成本不可解释或异常成本未关闭 |\n| 基线服务可靠性与可观测性 | 生产服务、关键用户旅程、SLI/SLO、错误预算、告警、on-call、runbook、合成探测、指标/日志/链路覆盖、降级策略和事故反馈 | `baseline-service-reliability-slo-error-budget-observability-ledger.yaml`、service.yaml、catalog、OpenTelemetry collector、Prometheus / Alertmanager、synthetic monitoring、incident postmortem、operational resilience ledger、backup restore ledger | 关键服务无 SLO、SLI 不可测、错误预算超支仍放行风险变更、关键告警无人接、runbook 缺失、合成探测缺失、遥测缺口或降级策略缺失 |\n| 基线备份、恢复与灾备 | 关键资产、数据存储、备份策略、不可变/离线副本、跨区域/跨账号隔离、恢复演练、RTO/RPO、完整性校验、勒索隔离、恢复权限和 owner | `baseline-backup-restore-disaster-recovery-ledger.yaml`、backup platform、object lock / WORM、KMS、storage lifecycle policy、replication config、restore drill evidence、operational resilience ledger、asset classification ledger、records retention ledger、incident playbook、POA&M | 关键资产无备份、关键数据存储未覆盖、不可变或离线副本缺失、恢复演练超期、RTO/RPO 演练失败、备份完整性未校验、勒索隔离不可证明、恢复权限不受控或备份与留存/法律保全冲突 |\n| 基线监管与合规义务可追溯 | 义务来源、法规版本、司法辖区、适用资产、控制目标、控制项、证据路径、owner、例外、POA&M、监管变更和生效期限 | `baseline-regulatory-obligation-ledger.yaml`、control plane、control evidence map、standards baseline、risk register、POA&M、legal register、contract register、audit evidence index | 强制义务未映射控制、控制项无适用义务来源、义务证据缺失、owner 缺失、监管变更未跟踪、整改超期仍放行 |\n| 基线密码材料、密钥、证书与秘密生命周期 | KMS/HSM key、TLS 证书、签名密钥、API token、数据库凭据、webhook secret、工作负载密钥、owner、托管位置、算法、强度、轮换、过期、吊销、泄露响应和访问边界 | `baseline-cryptographic-secrets-key-certificate-ledger.yaml`、KMS/HSM、Vault、Secret Manager、cert-manager、CA、CI signing system、TLS scanner、secret scanning、workload identity、runtime admission ledger、asset classification ledger | 密码材料未入账、无 owner、明文存放、弱算法、证书过期、轮换超期、吊销路径缺失、泄露未关闭、签名密钥托管不清或 Secret 与运行资产无法绑定 |\n| 基线资产关键性、数据分类与风险分级 | 资产清单、owner、业务关键性、SLO Tier、L3/L4 合规等级、CIA 影响、数据敏感度、监管暴露、AI 风险等级、互联网暴露、第三方关键性和复核状态 | `baseline-asset-criticality-classification-ledger.yaml`、catalog、CMDB、data catalog、AI product catalog、conformance profile、risk register、SLO、privacy impact assessment、AI evidence ledger、third-party risk ledger | 资产未入账、资产无 owner、数据分类未知、CIA 影响缺失、关键资产低估、L3/L4 与 conformance profile 不一致、互联网暴露或 AI 风险未标记、分级复核过期仍放行 |\n| 基线身份权限、特权访问与工作负载身份 | 人类身份、服务账号、工作负载身份、JML、MFA、PAM/JIT、break-glass、最小权限、访问复核、孤儿账号、过期权限和运行时绑定 | `baseline-identity-entitlement-access-ledger.yaml`、IAM、IdP、PAM、SCIM、HRIS、Kubernetes RBAC、Cloud IAM、SPIFFE/SPIRE、runtime admission ledger、catalog、third-party risk ledger | 生产身份未入账、服务账号无 owner、离职账号仍有效、特权访问无审批或 MFA、break-glass 未关闭、工作负载身份绑定漂移、孤儿账号或过期权限仍放行 |\n| 基线处理活动、个人数据清单与 RoPA 覆盖 | 处理活动、系统/服务/数据产品/AI 产品、数据主体类别、个人数据类别、控制者/处理者角色、接收方、跨境传输、保留映射、DPIA、合法基础和发现覆盖 | `baseline-processing-activity-inventory-ledger.yaml`、data catalog、CMDB、privacy impact assessment、data product contract、AI evidence ledger、data residency ledger、third-party risk ledger、records retention ledger、privacy rights ledger | 新系统或数据产品未入 RoPA、PII 扫描发现未归类字段、处理活动无 owner、个人数据类别未知、接收方或跨境传输未映射、DPIA/合法基础/留存映射缺失仍放行 |\n| 基线隐私权利、同意偏好与合法基础执行 | 处理目的、合法基础、同意版本、同意撤回、偏好传播、DSAR/消费者权利请求、自动化决策复核、第三方传播和下游处理阻断 | `baseline-privacy-rights-consent-ledger.yaml`、privacy impact assessment、consent management platform、preference center、DSAR case system、data product contract、AI evidence ledger、records retention ledger、data residency ledger、third-party risk ledger | 处理目的无合法基础、同意状态未知、撤回未传播到营销/AI/数据产品/RAG/第三方、权利请求逾期、自动化决策缺人工复核、第三方偏好传播缺证据仍放行 |\n| 基线记录留存、法律保全与可防御删除 | 记录类别、留存排期、义务来源、司法辖区、legal hold、删除资格、删除传播、备份/日志/向量索引处置和删除回执 | `baseline-records-retention-legal-hold-ledger.yaml`、regulatory obligation ledger、privacy impact assessment、data residency ledger、AI evidence ledger、audit evidence index、evidence archive receipt、object lock / WORM policy、storage lifecycle policy、deletion receipts | 记录类别无留存排期、legal hold 下允许删除、监管留存与主体删除请求冲突无裁决、过期记录未处置、超期留存无目的、备份/日志/向量索引删除传播无回执或 AI/审计日志缺留存策略 |\n| 基线证据追踪 | 证据节点、依赖边、摘要一致性、下游消费和断链阻断 | `baseline-evidence-trace-graph.yaml`、发布证据、状态对账、审计导出、会审裁决 | 必需节点缺失、摘要不一致、依赖断链、下游引用旧证据或存在未消费关键证据 |\n| 基线门禁执行 | 门禁命令、runner 镜像、策略包、schema 包、输入摘要、逐条规则结果、退出码、重放结果和最终决策 | `baseline-gate-execution-report.yaml`、`release-gate-decision.yaml`、`control-plane.yaml`、`baseline-verification-lock.yaml` | 规则未执行、输入摘要不一致、策略包漂移、重放失败、退出码异常或最终决策与执行结果不一致 |\n| 基线门禁负例测试 | 错误 fixture、故障注入、预期失败规则、实际拒绝结果、失败日志摘要、覆盖 gate、复测命令和回归 owner | `baseline-gate-negative-test-suite.yaml`、`baseline-gate-execution-report.yaml`、`release-gate-decision.yaml`、OPA / Kyverno / schema test report、runtime admission deny logs | 缺少关键 gate 负例、坏 fixture 被放行、预期失败未触发、失败日志不可追溯、负例套件未重放或回归 owner 缺失 |\n| 基线兼容 | 消费者影响、迁移窗口、弃用截止、未迁移对象和例外闭环 | `baseline-compatibility-ledger.yaml`、API/Event/Data/AI 兼容性报告、catalog | breaking change 无消费者清单、迁移到期仍未完成、例外无到期或 POA&M |\n| 基线采纳 | 领域、平台、数据、AI、GitOps 和生产资产的目标基线、采用状态和逾期整改 | `baseline-adoption-ledger.yaml`、catalog、control assessment、scorecard | 关键资产采纳状态 unknown、L3/L4 资产逾期无例外、采用证据只停留在口头确认 |\n| 基线支持 | 支持状态、维护窗口、安全补丁窗口、EOL、最低可接受基线和例外闭环 | `baseline-support-matrix.yaml`、version governance、release evidence、adoption ledger | 旧基线 EOL 后仍被 L3/L4 使用、安全补丁窗口结束后继续放行、新项目采用 maintenance/security-only/eol 基线 |\n| 基线 EOL 退役 | 旧基线生产引用清零、迁移关闭、例外清零、证据归档和新采用阻断 | `baseline-eol-retirement-certificate.yaml`、support matrix、adoption ledger、compatibility ledger、catalog、GitOps、审计归档 | 支持矩阵标记 EOL 但仍有生产引用、迁移目标未关闭、EOL 后仍允许新采用 |\n| 基线发布列车 | 候选窗口、冻结窗口、晋级日期、通知节奏、黑窗、紧急补丁入口和依赖证据 | `baseline-release-train.yaml`、version governance、support matrix、compatibility ledger、adoption ledger | 临时发版、无通知升级、冻结期合入非紧急变更、黑窗发布、紧急补丁缺事后补证 |\n| 基线通知确认 | 通知对象、渠道、送达、确认、异议、补发、例外和冻结前完成状态 | `baseline-notification-ledger.yaml`、release train、compatibility ledger、adoption ledger、risk register | 关键 owner 未确认、通知失败无补发、异议未关闭、例外无审批、冻结前仍有 unknown |\n| 基线回滚验证 | 上一基线、回滚目标、Git/tag/GitOps revision、审计导出恢复、烟测、证据摘要和验证时效 | `baseline-rollback-verification.yaml`、release evidence、version governance、GitOps、审计导出 | 回滚目标不可检出、GitOps revision 不存在、审计导出恢复失败、烟测失败或验证过期 |\n| 基线例外总账 | 例外来源、受影响资产、owner、风险接受、POA&M、补偿控制、到期、关闭证据和冻结阻断 | `baseline-exception-ledger.yaml`、compatibility/adoption/support/notification/rollback ledgers、release gate、risk register | 例外散落未聚合、过期仍放行、阻断例外无 owner、条件放行无风险接受或 POA&M |\n| 基线符合性声明 | 资产声明采用的基线、门禁等级、证据路径、例外、签署和复核 | `baseline-conformance-claim.yaml`、catalog、service/data/ai/product contract、adoption ledger | 中央采纳总账没有资产侧声明、资产声明过期、声明基线低于支持矩阵最低要求 |\n| 访问复核 | 身份源、角色、特权权限、break-glass、MFA、复核报告 | `identity-access-review.yaml`、IAM、Kubernetes RBAC | 生产权限未复核、break-glass 无 MFA、特权账号无审计 |\n| 密钥治理 | Secret provider、KMS、静态加密、轮换周期、泄露扫描 | `secrets-rotation-evidence.yaml`、密钥系统、扫描器 | 密钥未轮换、无静态加密、发现泄露仍放行 |\n| 渐进式发布 | Feature Flag、Kill Switch、曝光事件、SLO 燃尽回滚 | `feature-flag-control.yaml`、GitOps、observability | 无关闭开关、无默认变体、无成功指标、无回滚条件 |\n| AI 发布 | 评估集、红队、RAG 权限、工具权限、人工确认策略 | `ai-product.yaml`、`contracts/ai/` | 高风险工具无人工确认、评估未达标 |\n| AI 证据账本 | 模型、Prompt、RAG、工具、评估、威胁模型、观测、事件响应、数据使用、审批和复审 | `ai-evidence.yaml`、`ai-product.yaml`、`ai-tool-contract.yaml`、`rag-index-contract.yaml`、`genai-observability-contract.yaml` | AI 证据分散、模型版本错配、工具权限和事件响应证据无法按产品聚合 |\n| AI 系统监管分类与影响评估 | AI 系统用途、部署角色、适用法规、风险分类、禁止/高风险/通用目的 AI 判断、人工监督、日志留存、技术文档、数据治理、透明度、后市场监测、供应商责任和合规缺口 | `baseline-ai-system-regulatory-impact-ledger.yaml`、`ai-evidence.yaml`、`ai-product.yaml`、DPIA、监管义务总账、风险登记、会审裁决、release gate | 高风险 AI 无分类、适用法规未知、人工监督缺失、日志或技术文档缺失、后市场监测缺失、供应商责任不清、合规缺口未关闭 |\n| AI 安全 | Prompt Injection、工具同意、出站限制、残余风险接受 | `ai-threat-model.yaml`、`ai-tool-contract.yaml`、评估证据 | 高风险工具无同意、红队失败、风险接受过期 |\n| AI 事件响应 | 幻觉爆发、工具循环、RAG 污染、供应商中断、成本异常、检测、遏制、降级、回滚和复盘 | `ai-incident-playbook.yaml`、`ai-product.yaml`、`ai-threat-model.yaml`、`genai-observability-contract.yaml` | 高风险 AI 无 playbook、触发器不全、无法人工接管或回滚 |\n| 隐私工程 | DPIA、合法基础、主体权利、删除传播、AI 使用限制 | `privacy-impact-assessment.yaml`、数据产品、RAG 删除证据 | 有 PII 但无 DPIA、删除无法传播到向量索引、训练退出未声明 |\n| 租户隔离 | namespace、ServiceAccount、Secret 范围、ResourceQuota、NetworkPolicy 默认拒绝 | `tenant-boundary.yaml`、GitOps、Kubernetes policy | 生产 namespace 无配额、默认放通网络、服务账号越界 |\n| 数据发布 | schema、质量规则、权限、血缘、freshness 校验 | `data-product.yaml`、数据契约 | 无质量规则、无分级分类、无下游通知 |\n| 数据运行 | 运行血缘、producer job、input/output dataset、质量证据 | `lineage-event.yaml`、调度系统、数据质量报告 | 无运行事件、血缘断裂、输出数据产品不匹配 |\n| 恢复演练 | RTO/RPO、备份、恢复日志、数据丢失校验、复盘证据 | `recovery-drill-evidence.yaml`、备份系统、SRE 复盘 | 只声明目标无演练、恢复耗时超标、数据丢失未验证 |\n| 策略测试 | OPA / Cedar / Kyverno 策略测试、失败数、阻断决策 | `policy-test-report.yaml`、Policy as Code 测试结果 | 策略无测试、失败用例未阻断、策略和准入证据不一致 |\n| GenAI 观测 | Token、成本、工具调用、RAG span、trace 属性、日志脱敏 | `genai-observability-contract.yaml`、OpenTelemetry、AI gateway | 无 Token 成本指标、工具调用不可追踪、Prompt 日志未脱敏 |\n| 平台运营 | Golden Path 采用率、开发者满意度、认知负载、平台 SLO | `platform-product-metrics.yaml`、平台门户、问卷和工单数据 | 认知负载过高、平台 SLO 不达标、改进行动无 owner |\n| FinOps | 成本标签覆盖、未分摊成本、云/AI/数据成本、优化行动 | `cost-allocation-evidence.yaml`、OpenCost / FOCUS / 云账单 | 成本无 owner、标签覆盖不足、未分摊成本持续存在 |\n| 事故复盘与问题闭环 | 影响、根因、检测/恢复时间、纠正行动、问题记录、复发防止、门禁反哺 | `incident-postmortem.yaml`、`baseline-incident-problem-corrective-action-ledger.yaml`、SRE 复盘、告警系统 | 事故未关闭、问题记录缺失、runbook 未更新、复发防止未验证、门禁未反哺 |\n| 证据生命周期 | 证据最大年龄、按类型过期策略、CI 执行、过期阻断 | `evidence-freshness-policy.yaml`、审计索引、CI | 过期证据继续准入、关键证据不是必需项 |\n| 控制证据映射 | 控制项 ID、证据路径、状态、新鲜度、必需性、阻断属性 | `control-evidence-map.yaml`、控制目录、CI | 控制项无证据、证据过期、非阻断控制被误放行 |\n| 执行控制面 | 合规等级、控制项、证据、owner、阻断级别、自动化状态、复核周期和退出标准 | `conformance-profile.yaml`、`control-plane.yaml`、`release-gate-decision.yaml`、控制目录、CI | 不同团队用不同放行口径、条件放行无证据、例外过期仍继续发布 |\n| 标准基线 | 外部标准名称、版本、稳定性、采纳等级、适用范围、owner、复核周期和升级门禁 | `standards-baseline.yaml`、参考资料、ADR、控制面 | 直接追随 latest、把 Development 状态规范当生产硬门禁、升级无兼容评估 |\n| 版本控制面 | 基线 ID、版本、发布通道、source commit、release tag、兼容窗口、冻结状态和回滚入口 | `version-governance.yaml`、版本清单、tag、ADR、审计导出 | tag 漂移、版本复用、发布证据版本不一致、冻结基线被直接修改 |\n| 基线生命周期状态机 | 状态集合、允许迁移、禁止迁移、迁移审批、状态回写和回滚入口 | `baseline-lifecycle-state-machine.yaml`、`version-governance.yaml`、`baseline-release-evidence.yaml`、`release-gate-decision.yaml` | 人工改状态、越级晋级、冻结后回退、状态机和版本控制面不一致 |\n| 基线状态对账 | 状态机、版本控制面、发布证据、支持矩阵、采纳总账、符合性声明和审计导出状态一致性 | `baseline-state-reconciliation-report.yaml`、`baseline-lifecycle-state-machine.yaml`、`version-governance.yaml`、审计导出 | 各账本状态字段冲突、审计导出引用旧状态、状态回写失败 |\n| 基线会审裁决 | 晋级、冻结、紧急补丁、替代或 EOL 前的证据核验、投票签署、反对意见和最终裁决 | `baseline-review-board-decision.yaml`、readiness scorecard、release evidence、state reconciliation、exception ledger、POA&M、risk register | 评分卡通过但无独立会审签署、关键角色缺席、反对意见无关闭、条件动作无 owner 或到期 |\n| 审计导出 | 架构版本、控制数量、starter kit 数量、导出内容、验证结果、签名、留存 | `audit-export-manifest.yaml`、审计包、签名系统 | 导出包范围不明、缺关键文件、未验证通过、未签名 |\n| 证据保证等级 | 证据来源、采信状态、保证等级、生成方式、来源独立性、完整性证明、新鲜度窗口、可重放命令和最低适用门禁 | `baseline-evidence-assurance-classification.yaml`、evidence trace graph、gate execution report、control assurance sampling、audit export | L3 / L4、baseline、frozen 或正式审计导出引用低等级、过期、不可重放、无完整性证明、无来源独立性或不可采信证据 |\n| 审计导出自动化 | 校验命令、导出脚本、JSON 包、Markdown 报告、OSCAL 摘要、完整性清单、provenance statement、签名策略和验签回执契约 | `internal-command://architecture/export-modern-architecture-audit`、导出脚本、build 输出 | 审计包只能手工拼接、未先校验、缺制品哈希、生成来源、签名策略或验签回执 |\n| 控制评估报告 | 评估范围、评估人、控制结果、发现项、整改、剩余风险、签署 | `control-assessment-report.yaml`、控制目录、证据映射、审计导出清单 | 只有证据无结论、发现项无人负责、未签署仍声称通过 |\n| 架构基线变更 | 版本、前序版本、变更级别、影响分析、审批、验证、回滚、留存 | `baseline-change-record.yaml`、版本清单、控制目录、CI | 基线升级无审批、验证命令缺失、无法回滚到上一基线 |\n| 架构决策记录 | ADR、上下文、备选方案、取舍、控制项、风险、POA&M、复审和留存 | `architecture-decision-record.yaml`、`baseline-change-record.yaml`、控制目录、风险登记、POA&M 记录 | 重大变更无 ADR、ADR 未关联控制项或风险、复审过期 |\n| OSCAL 交换映射 | catalog、component-definition、SSP、assessment-results、POA&M、导出摘要 | `oscal-export-profile.yaml`、`oscal-summary.json`、审计导出脚本 | 只能内部阅读、不能对接 GRC、监管或外部审计工具 |\n| POA&M 整改计划 | 发现项、控制项、严重度、责任人、行动、里程碑、证据、签署和复审 | `poam-record.yaml`、`oscal-summary.json`、控制评估报告 | 发现项只在报告正文里、整改无里程碑、OSCAL POA&M 视图无独立来源 |\n| 企业架构风险登记 | 风险、严重度、可能性、影响、owner、处理策略、关联控制项、关联 POA&M、残余风险和复审 | `risk-register.yaml`、`oscal-summary.json`、控制目录、POA&M 记录 | 风险只在会议纪要里、无 owner、无控制项映射、残余风险无人接受 |\n| 审计导出门禁 | 本地质量门禁、导出命令、输出不变量、pair 数、控制数、OSCAL 摘要一致性 | `audit-export-gate.yaml`、`internal-command://architecture/check-modern-architecture-audit-export`、`make test` | 有导出脚本但未进入门禁、输出数量和版本不一致、OSCAL 摘要未验证 |\n| 审计导出完整性 | 生成物 SHA-256、源制品哈希、完整性清单、防篡改校验 | `audit-export-integrity.yaml`、`audit-export-integrity.json`、审计导出门禁 | 审计包交接后无法证明未被篡改、生成物哈希缺失、源制品和导出包断链 |\n| 审计导出 provenance | in-toto statement、SLSA provenance、subject digest、构建定义、源码提交和源证据依赖 | `audit-export-provenance.yaml`、`audit-export-provenance.json`、审计导出门禁 | 审计包知道哈希但不知道来源、生成上下文不可证明、无法绑定签名 payload |\n| 审计导出签名策略 | provenance payload 摘要、签名方式、验签命令、bundle 路径和透明日志要求 | `audit-export-signing-policy.yaml`、`audit-export-signing-policy.json`、审计导出门禁 | 声称需要签名但没有 payload 摘要、验签路径或外部签名交接 |\n| 审计导出签名验签回执 | 签名策略绑定、payload 摘要、bundle 摘要、证书身份、OIDC issuer、透明日志和验签结果 | `audit-export-signature-receipt.yaml`、签名系统、验签日志 | 外部签名完成后没有可审计回执、证书身份和透明日志不可追溯 |\n| 运行 | SLO、成本、漂移、异常调用、供应链策略漂移 | runtime、observability、audit、漂移报告 | 错误预算耗尽、成本超预算、策略漂移 |\n\n### 10.10.4 漂移检测规则\n\n可执行标准必须能发现“文档这么写、运行不是这样”的漂移。\n\n必须检测的漂移：\n\n1. `service.yaml` 的 owner、domain、端口、依赖和 catalog entry 不一致。\n2. catalog 指向的 GitOps 路径不存在，或 GitOps 路径指向的服务没有 catalog entry。\n3. GitOps 使用的镜像 tag 无法解析到不可变 digest。\n4. 生产 Deployment 的镜像 digest 与 GitOps 期望状态不一致。\n5. 生产 Deployment 的 ConfigMap / Secret hash、ServiceAccount、NetworkPolicy、Pod 安全策略或准入策略与 GitOps 期望状态不一致。\n6. Kubernetes runtime 存在未登记到 catalog 的长期运行工作负载。\n7. 数据产品 schema 与实际表结构或数据契约不一致。\n8. AI 产品运行中的 Prompt、模型、RAG 索引或工具版本与 `ai-product.yaml` 不一致。\n9. 策略例外超过到期时间仍在生产准入中生效。\n\n漂移处理规则：\n\n1. 发现漂移后先判断权威真相源，再决定修正 Git、catalog、runtime 还是治理例外。\n2. 运行时紧急修复必须在事后回写 GitOps 或形成 incident / postmortem，不能长期保留手工状态。\n3. catalog 漂移优先通过重新生成或重新校验修复，不应手工覆盖源头契约。\n4. 涉及生产安全、AI 高风险工具、数据权限和供应链证明的漂移必须阻断发布。\n\n### 10.10.5 控制项覆盖清单\n\n可执行企业标准不能只证明“字段存在”，还要证明关键控制项确实被 schema、example 和 checker 覆盖。\n\nV2.6 起，控制项覆盖清单由以下文件维护；V2.7 起，严格 schema 控制项进入同一清单；V2.8 起，扩展策略、发布开关、AI 威胁模型、运行血缘和平台产品指标也进入同一清单；V2.9 起，隐私影响评估、租户隔离、恢复演练、策略测试、GenAI 观测和成本分摊证据也进入同一清单；V2.10 起，访问复核、密钥轮换、漏洞修复、事故复盘和证据新鲜度也进入同一清单；V2.11 起，控制证据映射和审计导出清单也进入同一清单；V2.12 起，审计导出自动化命令也进入同一清单；V2.13 起，控制评估报告也进入同一清单；V2.14 起，架构基线变更记录也进入同一清单；V2.15 起，OSCAL 交换映射也进入同一清单；V2.16 起，审计导出门禁也进入同一清单；V2.17 起，审计导出完整性清单也进入同一清单；V2.18 起，审计导出 provenance statement 也进入同一清单；V2.19 起，审计导出签名策略也进入同一清单；V2.20 起，审计导出签名验签回执也进入同一清单；V2.21 起，POA&M 整改计划也进入同一清单；V2.22 起，企业架构风险登记也进入同一清单；V2.23 起，架构决策记录也进入同一清单；V2.24 起，AI 事件响应 playbook 也进入同一清单；V2.25 起，AI 证据账本也进入同一清单；V2.26 起，微调运行证据也进入同一清单；V2.27 起，仓库变更控制和远端保护漂移整改也进入同一清单；V2.28 起，合规等级、执行控制面和门禁决策也进入同一清单；V2.29 起，外部标准版本锁定和升级门禁也进入同一清单；V2.30 起，版本控制面和基线发布不变量也进入同一清单；V2.31 起，基线发布证据包、晋级决策、冻结复核和版本漂移复核也进入同一清单；V2.32 起，基线兼容性总账、消费者迁移和未迁移风险闭环也进入同一清单；V2.33 起，基线采纳总账、组织采纳状态、逾期整改和例外闭环也进入同一清单；V2.34 起，基线支持矩阵、维护窗口、安全补丁、EOL 和最低可接受基线也进入同一清单；V2.35 起，基线发布列车、候选窗口、冻结窗口、晋级日期、通知节奏、黑窗和紧急补丁也进入同一清单；V2.36 起，资产级基线符合性声明、资产自声明、证据绑定、例外和采纳总账回写也进入同一清单；V2.37 起，基线制品清单、源制品摘要、必需性、签名状态、导出关系和未登记制品阻断也进入同一清单；V2.38 起，基线验证环境锁定、校验命令、runner 镜像、工具版本、策略包、validator 和验签工具也进入同一清单；V2.39 起，基线通知确认总账、通知对象、送达回执、影响确认、异议、例外和冻结前完成状态也进入同一清单；V2.40 起，基线回滚验证记录、上一基线检出、GitOps revision 恢复、审计导出恢复、烟测结果和验证时效也进入同一清单；V2.41 起，基线例外总账、例外来源聚合、风险接受、POA&M、过期阻断和冻结准入也进入同一清单；V2.42 起，基线就绪评分卡、硬门禁、评分维度、证据绑定和最终准入判定也进入同一清单；V2.43 起，基线生命周期状态机、允许迁移、禁止迁移、迁移审批、状态回写和迁移审计证据也进入同一清单；V2.44 起，基线状态对账报告、跨账本状态一致性、状态漂移阻断和审计导出状态回写也进入同一清单；V2.45 起，基线 EOL 退役证书、生产引用清零、迁移关闭、例外清零和新采用阻断也进入同一清单；V2.46 起，基线会审裁决记录、证据核验、投票签署、反对意见、条件动作和最终裁决也进入同一清单；V2.47 起，基线证据追踪图、证据节点依赖、摘要一致性、下游消费和断链阻断也进入同一清单；V2.48 起，基线门禁执行报告、门禁命令、runner、策略包、schema 包、输入摘要、规则结果、退出码和重放结果也进入同一清单；V2.49 起，基线发布事务回执、提交前检查、干净工作树、签名 tag、远端 ref、push 回执、保护规则和发布后验证也进入同一清单；V2.50 起，基线撤销与隔离记录、撤销触发、隔离范围、受影响引用、通知确认、恢复目标、风险接受和审计归档也进入同一清单；V2.51 起，基线准入执行策略、最低基线阻断、撤销/EOL 阻断、资产声明校验和例外到期阻断也进入同一清单；V2.52 起，基线消费锁定文件、不可变摘要锁定、浮动版本阻断、锁文件签署和采纳总账回写也进入同一清单；V2.53 起，基线迁移工作单、逐资产迁移步骤、消费锁更新、GitOps 变更、验收证据和回滚动作也进入同一清单；V2.54 起，基线迁移执行回执、实际命令、执行环境、before/after 摘要、GitOps revision、catalog/lock diff、验收日志和回滚验证也进入同一清单；V2.55 起，本地私有制品边界、禁推资产分类、摘要留存、允许用途、远端排除和审计留存也进入同一清单；V2.56 起，审计导出排除清单、原文白名单、摘要留存、签名 payload 排除和导出后验证也进入同一清单；V2.57 起，私有制品托管交接清单、私有制品库引用、访问控制、留存期限、取回命令、恢复验证和摘要一致性也进入同一清单；V2.58 起，干净环境基线重建回执、远端 checkout、私有制品取回、摘要校验、审计导出重建、门禁重放和禁推资产复核也进入同一清单；V2.59 起，基线证据不可变归档回执、归档对象、WORM/对象锁、legal hold、访问日志、删除保护、留存到期和恢复演练也进入同一清单；V2.60 起，基线长期验签回执、证书链、透明日志、signed entry timestamp、RFC3161 TSA、撤销状态、工具版本和归档引用也进入同一清单；V2.61 起，基线运行时准入回执、admission controller、策略引擎、策略 bundle、镜像 digest、签名/provenance/SBOM、消费锁、撤销/EOL 阻断和拒绝样例也进入同一清单；V2.62 起，基线运行时准入决策总账、requestUID、allow/deny、策略规则和原始日志摘要也进入同一清单；V2.63 起，基线连续控制监测总账、关键控制指标、告警、漂移处置和证据新鲜度也进入同一清单；V2.64 起，基线独立控制保证抽样总账、控制总体、样本、设计有效性、运行有效性和 OSCAL Assessment Results 也进入同一清单；V2.65 起，基线共享责任与继承控制总账、公共控制、继承控制、消费者义务和失效阻断也进入同一清单；V2.66 起，基线数据驻留与跨境处理总账、实际处理区域、传输机制、子处理方、补充措施和区域漂移阻断也进入同一清单；V2.67 起，基线第三方与关键供应商风险总账、供应商分级、合同控制、审计权、保证报告、集中度、退出计划和连续性阻断也进入同一清单；V2.68 起，基线运营韧性与重要业务服务影响容忍总账、重要业务服务、影响容忍、BIA、端到端依赖、场景测试、恢复能力、沟通计划和超限升级阻断也进入同一清单。\n\nV2.69 起，监管与合规义务、记录留存、隐私权利、处理活动、身份权限、资产分级、密码材料、备份恢复、服务可靠性、容量性能、威胁建模、漏洞修复、安全配置、生产变更、事故纠正、数据产品质量、工程质量、人员能力、业务结果、价值流、架构视图、质量属性、架构原则和版本策略控制也必须进入同一清单。到 V2.93，控制项覆盖清单必须能证明 `baseline-version-policy-release-control-ledger.schema.json`、示例和 checker 规则已经覆盖 SemVer 语义、Conventional Commit 分类、发布通道、签名 tag、兼容窗口、消费锁、迁移窗口、冻结规则、紧急补丁、撤销隔离、EOL 阻断和禁推资产排除。\n\nV2.95 起，控制项覆盖清单还必须能证明 `baseline-evidence-assurance-classification.schema.json`、示例和 checker 规则已经覆盖证据保证等级、采信状态、生成方式、来源独立性、完整性证明、新鲜度窗口、可重放要求、最低适用门禁和不可采信证据阻断。\n\n```text\n本地私有控制项覆盖清单\n```\n\n该清单采用轻量控制目录结构，不替代完整 OSCAL 实施。它至少记录：\n\n1. 控制项 ID、分类、标题和控制声明。\n2. 控制项对齐的参考来源，例如 NIST OSCAL、SLSA、NIST SSDF。\n3. 必须存在的文档、schema、example 或脚本。\n4. 必须出现在 schema `required` 和 `properties` 中的字段。\n5. 必须出现在 YAML example 中的字段。\n6. 必须出现在 checker 中的自动化证据规则。\n\n控制项覆盖清单用于回答：\n\n| 问题 | 证明方式 |\n| ---- | -------- |\n| 文档说生产服务必须有 RTO/RPO，机器是否能证明 | 控制项要求 `service.schema.json` 和 `service.example.yaml` 包含 `reliability.rto`、`reliability.rpo` |\n| 文档说架构基线仓库必须受保护，机器是否能证明 | 控制项要求 `repository-change-control.schema.json`、示例和 runbook 包含 CODEOWNERS、受保护分支、必需检查、签名提交、禁止直推、远端验证、漂移整改、POA&M 和风险登记 |\n| 文档说数据产品必须有访问审计，机器是否能证明 | 控制项要求 `data-product.schema.json` 和示例包含 `accessPolicy`、`audit`、`retention` |\n| 文档说 AI 产品必须可降级和控成本，机器是否能证明 | 控制项要求 `ai-product.schema.json` 和示例包含 `budget`、`fallback`、`providerPolicy` |\n| 文档说 AI 产品证据必须可追踪，机器是否能证明 | 控制项要求 `ai-evidence.schema.json` 和示例包含模型、Prompt、RAG、工具、评估、威胁模型、观测、事件响应、数据使用、审批和复审 |\n| 文档说企业不同风险等级必须使用不同门禁，机器是否能证明 | 控制项要求 `conformance-profile.schema.json`、`control-plane.schema.json` 和 `release-gate-decision.schema.json` 绑定等级、证据、阻断级别、例外和复核 |\n| 文档说外部标准不能直接追随 latest，机器是否能证明 | 控制项要求 `standards-baseline.schema.json` 和示例包含标准名称、版本、稳定性、采纳等级、复核周期和升级门禁 |\n| 文档说基线版本必须可追溯且不可复用，机器是否能证明 | 控制项要求 `version-governance.schema.json` 和示例包含基线 ID、发布通道、源 commit、release tag、兼容窗口、冻结策略和回滚入口 |\n| 文档说基线发布必须有晋级、冻结和漂移复核证据，机器是否能证明 | 控制项要求 `baseline-release-evidence.schema.json` 和示例包含晋级决策、不可变引用、漂移复核、审计导出摘要、验签结果和回滚验证 |\n| 文档说 breaking change 必须有消费者迁移闭环，机器是否能证明 | 控制项要求 `baseline-compatibility-ledger.schema.json` 和示例包含消费者、受影响契约、迁移状态、弃用截止、例外、POA&M 和风险接受 |\n| 文档说企业级基线必须被组织采纳，机器是否能证明 | 控制项要求 `baseline-adoption-ledger.schema.json` 和示例包含采纳范围、目标、当前基线、目标基线、采纳状态、截止日期、例外和整改证据 |\n| 文档说旧基线不能无限期被使用，机器是否能证明 | 控制项要求 `baseline-support-matrix.schema.json` 和示例包含支持状态、维护窗口、安全补丁窗口、EOL、最低可接受基线、例外和阻断规则 |\n| 文档说旧基线进入 EOL 后不能继续被生产使用，机器是否能证明 | 控制项要求 `baseline-eol-retirement-certificate.schema.json` 和示例包含生产引用清零、迁移关闭、例外清零、审计归档、新采用阻断和审批证据 |\n| 文档说基线晋级必须有独立会审裁决，机器是否能证明 | 控制项要求 `baseline-review-board-decision.schema.json` 和示例包含会审范围、证据核验、投票签署、反对意见、条件动作、风险接受和最终裁决 |\n| 文档说基线发布必须按列车和冻结窗口执行，机器是否能证明 | 控制项要求 `baseline-release-train.schema.json` 和示例包含候选窗口、冻结窗口、晋级日期、通知节奏、黑窗、紧急补丁和依赖证据 |\n| 文档说采纳总账必须来自资产侧声明，机器是否能证明 | 控制项要求 `baseline-conformance-claim.schema.json` 和示例包含资产 ID、声明基线、证据路径、签署、例外、复核和采纳总账回写 |\n| 文档说资产消费基线不能只写浮动版本，机器是否能证明 | 控制项要求 `baseline-consumption-lock.schema.json` 和示例包含 baseline ID、source commit、release tag、证据图摘要、制品清单摘要、验证锁摘要、准入策略摘要、签署和 rollup 回写 |\n| 文档说基线迁移必须逐资产执行，机器是否能证明 | 控制项要求 `baseline-migration-work-order.schema.json` 和示例包含目标资产、当前基线、目标基线、迁移步骤、依赖、GitOps 变更、消费锁更新、验收证据和回滚动作 |\n| 文档说迁移步骤必须被真实执行，机器是否能证明 | 控制项要求 `baseline-migration-execution-receipt.schema.json` 和示例包含执行命令、actor、执行环境、before/after 摘要、GitOps revision、catalog/lock diff、验收日志和回滚验证 |\n| 文档说内部可执行资产不能推远程但仍需审计，机器是否能证明 | 控制项要求 `baseline-local-artifact-boundary.schema.json` 和示例包含本地私有资产路径、分类、禁推原因、摘要策略、验证命令、远端排除、审计导出排除和签名 payload 排除 |\n| 文档说审计导出不能误含本地私有原文，机器是否能证明 | 控制项要求 `audit-export-exclusion-manifest.schema.json` 和示例包含原文白名单、摘要留存项、强制排除项、签名 payload 排除项、边界摘要和导出后验证命令 |\n| 文档说禁推可执行资产仍能被企业取回和恢复，机器是否能证明 | 控制项要求 `private-artifact-escrow-manifest.schema.json` 和示例包含私有 registry / 制品库引用、不可变摘要、访问角色、留存期限、取回命令、恢复验证和摘要一致性 |\n| 文档说基线不依赖个人工作区，机器是否能证明 | 控制项要求 `baseline-clean-room-reconstruction-receipt.schema.json` 和示例包含干净 runner、远端 checkout、私有制品取回、摘要校验、审计导出重建、门禁重放和禁推资产复核 |\n| 文档说审计证据多年后仍可证明未被改写和可恢复，机器是否能证明 | 控制项要求 `baseline-evidence-archive-receipt.schema.json` 和示例包含归档对象、不可变存储引用、WORM/对象锁、legal hold、访问日志、删除保护、留存到期和恢复演练 |\n| 文档说证据足以支撑当前 gate，机器是否能证明 | 控制项要求 `baseline-evidence-assurance-classification.schema.json` 和示例包含保证等级、采信状态、生成方式、独立性、完整性、新鲜度、可重放命令、最低适用门禁和拒绝理由 |\n| 文档说基线由哪些源制品构成，机器是否能证明 | 控制项要求 `baseline-artifact-inventory.schema.json` 和示例包含制品路径、类型、摘要、必需性、签名状态、导出关系和未登记制品阻断 |\n| 文档说同一基线必须用同一验证环境复现，机器是否能证明 | 控制项要求 `baseline-verification-lock.schema.json` 和示例包含命令、runner 镜像、工具版本、策略包摘要、schema validator、验签工具和生成环境 |\n| 文档说冻结前必须完成消费者通知确认，机器是否能证明 | 控制项要求 `baseline-notification-ledger.schema.json` 和示例包含通知对象、渠道、送达、确认、异议、例外、补发和冻结前完成状态 |\n| 文档说回滚路径必须实际可恢复，机器是否能证明 | 控制项要求 `baseline-rollback-verification.schema.json` 和示例包含上一基线、回滚目标、Git/tag/GitOps revision、审计导出恢复、烟测结果和验证时效 |\n| 文档说基线例外不能散落和过期放行，机器是否能证明 | 控制项要求 `baseline-exception-ledger.schema.json` 和示例包含例外来源、owner、到期日、风险接受、POA&M、阻断状态、关闭证据和冻结准入 |\n| 文档说基线是否可以晋级必须有最终判定，机器是否能证明 | 控制项要求 `baseline-readiness-scorecard.schema.json` 和示例包含硬门禁、评分维度、权重、证据路径、阻断项、baseline/frozen 阈值和最终判定 |\n| 文档说基线状态不能被人工随意改写，机器是否能证明 | 控制项要求 `baseline-lifecycle-state-machine.schema.json` 和示例包含状态集合、允许迁移、禁止迁移、迁移证据、审批责任、回写目标和审计记录 |\n| 文档说多个账本里的基线状态必须一致，机器是否能证明 | 控制项要求 `baseline-state-reconciliation-report.schema.json` 和示例包含对账输入、期望状态、观测状态、漂移项、阻断决策和回写状态 |\n| 文档说最低基线、撤销/EOL 和资产声明必须被运行入口阻断，机器是否能证明 | 控制项要求 `baseline-enforcement-policy.schema.json` 和示例包含适用入口、最低基线、阻断条件、例外有效期、策略引擎、决策回写和审计日志 |\n| 文档说 AI 事件响应必须有专门 playbook，机器是否能证明 | 控制项要求 `ai-incident-playbook.schema.json` 和示例包含触发器、检测、遏制、降级、回滚、RAG 恢复、工具 Kill Switch 和复盘 |\n| 文档说 GitOps 必须有运行安全，机器是否能证明 | 控制项要求 `gitops-deployment.schema.json` 和示例包含 `serviceAccount`、`security`、`scaling` |\n| 文档说关键资产必须完成威胁建模、攻击面和剩余风险治理，机器是否能证明 | 控制项要求 `baseline-threat-model-attack-surface-risk-ledger.schema.json` 和示例包含资产范围、信任边界、数据流、攻击面、滥用场景、控制映射、安全测试、剩余风险、POA&M、签署和过期阻断 |\n| 文档说漏洞、暴露面和修复验证必须闭合，机器是否能证明 | 控制项要求 `baseline-vulnerability-exposure-remediation-ledger.schema.json` 和示例包含资产范围、扫描覆盖、CVE、KEV、EPSS、CVSS、VEX/CSAF、外部暴露、owner、SLA、修复、复测、例外、POA&M、风险接受和发布准入 |\n| 文档说安全配置、加固姿态和配置漂移必须闭合，机器是否能证明 | 控制项要求 `baseline-secure-configuration-posture-drift-ledger.schema.json` 和示例包含配置基线、姿态扫描、CIS/NIST/SCAP 映射、Pod Security、漂移、owner、SLA、修复、复测、例外、POA&M、风险接受和发布准入 |\n| 文档说生产变更、发布编排和失败恢复必须闭合，机器是否能证明 | 控制项要求 `baseline-production-change-release-ledger.schema.json` 和示例包含变更类型、变更窗口、冲突检测、依赖冻结、前置门禁、数据库迁移演练、Feature Flag kill switch、Prompt/模型评估、回滚计划、执行证据、失败恢复、事故关联和 DORA 指标 |\n| 文档说事故、问题、纠正行动和复发防止必须闭合，机器是否能证明 | 控制项要求 `baseline-incident-problem-corrective-action-ledger.schema.json` 和示例包含事故类型、严重度、影响、时间线、MTTD/MTTR、RCA、问题记录、纠正行动、复发防止、runbook 更新、告警调整、门禁反哺、沟通、POA&M 和 DORA 恢复指标 |\n| 文档说数据产品质量、契约违约、运行血缘和消费者影响必须闭合，机器是否能证明 | 控制项要求 `baseline-data-product-quality-contract-observability-ledger.schema.json` 和示例包含数据产品 owner、契约版本、schema drift、质量断言、freshness、完整性、唯一性、语义口径、访问授权、血缘、消费者影响、AI/特征/RAG 使用、违约、修复复测和数据质量事故 |\n| 文档说工程质量、测试证据、缺陷和发布验证必须闭合，机器是否能证明 | 控制项要求 `baseline-engineering-quality-test-release-verification-ledger.schema.json` 和示例包含需求追踪、测试策略、测试层级、覆盖率、测试环境、测试数据、flaky 测试、缺陷分级、修复复测、发布前验证、灰度/冒烟结果和质量风险接受 |\n| 文档说关键角色能力、培训、职责履职和职责分离必须闭合，机器是否能证明 | 控制项要求 `baseline-workforce-competency-training-duty-segregation-ledger.schema.json` 和示例包含关键角色任命、岗位资格、职责确认、培训完成、专项训练、on-call 资格、审批授权、代理授权、职责分离、冲突角色、备份人员和到期复核 |\n| 文档说架构基线必须证明业务结果、价值实现和组合收益闭合，机器是否能证明 | 控制项要求 `baseline-business-outcome-value-realization-portfolio-ledger.schema.json` 和示例包含业务目标、价值假设、收益 owner、投资组合、关键结果、前后基线、采用证据、收益实现、成本效率、风险接受和停投/加投决策 |\n| 文档说关键价值流、客户旅程和端到端流程必须可观测、可审计、可优化，机器是否能证明 | 控制项要求 `baseline-value-stream-journey-process-ledger.schema.json` 和示例包含价值流、旅程、流程模型、owner、触发事件、完成定义、步骤级遥测、跨域交接、瓶颈、异常、人工兜底、控制点和改进动作 |\n| 文档说架构视图、运行拓扑和依赖影响必须一致且可审计，机器是否能证明 | 控制项要求 `baseline-architecture-view-runtime-topology-dependency-ledger.schema.json` 和示例包含架构视图、运行拓扑、声明依赖、观测依赖、GitOps 拓扑、数据/AI/第三方依赖、blast radius、变更影响、owner、漂移和复核状态 |\n| 文档说质量属性、架构驱动和权衡决策必须可测、可追溯、可验证，机器是否能证明 | 控制项要求 `baseline-quality-attribute-architecture-driver-tradeoff-ledger.schema.json` 和示例包含业务驱动、质量属性场景、响应指标、敏感点、权衡点、ADR、适配度函数、验证证据和复核状态 |\n| 文档说架构原则、约束、反模式和例外执行必须可检测、可阻断、可审计，机器是否能证明 | 控制项要求 `baseline-architecture-principle-constraint-exception-ledger.schema.json` 和示例包含原则、owner、适用范围、强制约束、禁止项、反模式、检测方式、门禁入口、违反处置、例外、风险接受、ADR 和复核状态 |\n| 文档说版本策略、发布通道、兼容性和冻结控制必须可执行，机器是否能证明 | 控制项要求 `baseline-version-policy-release-control-ledger.schema.json` 和示例包含版本号语义、发布通道、Conventional Commit 分类、签名 tag、兼容窗口、消费锁、迁移窗口、冻结规则、紧急补丁、撤销隔离和 EOL 阻断状态 |\n| 文档说供应链必须有漏洞和 Scorecard 证据，机器是否能证明 | 控制项要求 `supply-chain-attestation.schema.json` 和示例包含 `vulnerability`、`scorecard` |\n| 文档说 starter kit 必须拒绝未知字段，机器是否能证明 | 控制项要求 checker 包含 `additionalProperties must be false` 和 `unexpected field` 证据 |\n| 文档说严格 schema 必须有扩展出口，机器是否能证明 | 控制项要求 `extension-policy.schema.json` 和示例包含受控前缀、审批和默认拒绝策略 |\n| 文档说生产灰度必须可关闭，机器是否能证明 | 控制项要求 `feature-flag-control.schema.json` 和示例包含 `killSwitch`、`rollbackOnSloBurn` 和曝光事件 |\n| 文档说 AI 产品必须做威胁建模，机器是否能证明 | 控制项要求 `ai-threat-model.schema.json` 和示例包含 OWASP、MCP、红队、工具同意和残余风险 |\n| 文档说数据产品必须有运行血缘，机器是否能证明 | 控制项要求 `lineage-event.schema.json` 和示例包含 job、run、inputs、outputs、schema 和质量证据 |\n| 文档说平台工程必须作为产品运营，机器是否能证明 | 控制项要求 `platform-product-metrics.schema.json` 和示例包含 Platform PM、Golden Path、满意度、认知负载和改进行动 |\n| 文档说含 PII 的数据产品必须做隐私影响评估，机器是否能证明 | 控制项要求 `privacy-impact-assessment.schema.json` 和示例包含 DPIA、主体权利、删除传播和 AI 使用限制 |\n| 文档说生产租户必须有隔离和配额，机器是否能证明 | 控制项要求 `tenant-boundary.schema.json` 和示例包含 ResourceQuota、NetworkPolicy 默认拒绝和准入策略 |\n| 文档说 RTO/RPO 必须被演练证明，机器是否能证明 | 控制项要求 `recovery-drill-evidence.schema.json` 和示例包含目标、实际恢复结果、备份、恢复日志和复盘 |\n| 文档说关键系统和数据必须真实可恢复，机器是否能证明 | 控制项要求 `baseline-backup-restore-disaster-recovery-ledger.schema.json` 和示例包含关键资产、数据存储、备份策略、不可变/离线副本、跨区域隔离、恢复演练、RTO/RPO、完整性校验、勒索隔离、恢复权限和 owner |\n| 文档说容量、性能和成本效率必须持续受控，机器是否能证明 | 控制项要求 `baseline-capacity-performance-cost-efficiency-ledger.schema.json` 和示例包含容量预测、压测、性能基准、资源 requests/limits、HPA/VPA/KEDA、队列积压、数据库容量、预算、单位经济、成本分摊、异常成本和优化行动 |\n| 文档说生产服务可靠性必须由 SLO、错误预算和可观测性证明，机器是否能证明 | 控制项要求 `baseline-service-reliability-slo-error-budget-observability-ledger.schema.json` 和示例包含生产服务、关键用户旅程、SLI/SLO、错误预算、告警路由、on-call、runbook、合成探测、日志/指标/链路覆盖、仪表盘、降级策略和事故反馈 |\n| 文档说策略准入必须可测试，机器是否能证明 | 控制项要求 `policy-test-report.schema.json` 和示例包含策略引擎、测试数、失败数和执行命令 |\n| 文档说 GenAI 必须可观测，机器是否能证明 | 控制项要求 `genai-observability-contract.schema.json` 和示例包含 Token、成本、工具调用、RAG span 和日志脱敏 |\n| 文档说成本必须可分摊，机器是否能证明 | 控制项要求 `cost-allocation-evidence.schema.json` 和示例包含标签覆盖率、未分摊成本、总成本和优化行动 |\n| 文档说生产访问必须复核，机器是否能证明 | 控制项要求 `identity-access-review.schema.json` 和示例包含身份源、角色、break-glass、MFA 和复核结论 |\n| 文档说生产密钥必须轮换，机器是否能证明 | 控制项要求 `secrets-rotation-evidence.schema.json` 和示例包含 KMS、静态加密、轮换结果和泄露扫描 |\n| 文档说高危漏洞必须修复，机器是否能证明 | 控制项要求 `vulnerability-remediation-evidence.schema.json` 和示例包含 SLA、修复日期、残余风险和发布准入 |\n| 文档说生产事故必须复盘反哺，机器是否能证明 | 控制项要求 `incident-postmortem.schema.json` 和示例包含根因、行动项、runbook 更新和门禁更新 |\n| 文档说证据不能过期继续准入，机器是否能证明 | 控制项要求 `evidence-freshness-policy.schema.json` 和示例包含最大年龄、过期阻断和 CI 执行 |\n| 文档说每个控制项都必须有可追踪证据，机器是否能证明 | 控制项要求 `control-evidence-map.schema.json` 和示例覆盖全部控制项 ID、证据路径、状态和新鲜度 |\n| 文档说每条适用监管和合规义务必须映射到控制与证据，机器是否能证明 | 控制项要求 `baseline-regulatory-obligation-ledger.schema.json` 和示例包含义务来源、版本、司法辖区、适用资产、控制目标、控制项、证据路径、owner、例外、POA&M 和监管变更状态 |\n| 文档说生产密码材料、密钥、证书和秘密生命周期必须受控，机器是否能证明 | 控制项要求 `baseline-cryptographic-secrets-key-certificate-ledger.schema.json` 和示例包含 KMS/HSM key、TLS 证书、签名密钥、API token、数据库凭据、webhook secret、工作负载密钥、owner、托管位置、算法强度、轮换、过期、吊销、泄露响应和访问边界 |\n| 文档说资产关键性、数据分类和风险分级必须驱动门禁，机器是否能证明 | 控制项要求 `baseline-asset-criticality-classification-ledger.schema.json` 和示例包含资产 owner、业务关键性、SLO Tier、L3/L4、CIA 影响、数据敏感度、监管暴露、AI 风险、互联网暴露、第三方关键性和复核状态 |\n| 文档说每个生产身份、特权访问和工作负载身份必须可追踪，机器是否能证明 | 控制项要求 `baseline-identity-entitlement-access-ledger.schema.json` 和示例包含人类身份、服务账号、工作负载身份、JML、MFA、PAM/JIT、break-glass、owner、审批、到期、复核和运行时绑定状态 |\n| 文档说所有个人数据处理活动必须进入 RoPA 和数据清单覆盖总账，机器是否能证明 | 控制项要求 `baseline-processing-activity-inventory-ledger.schema.json` 和示例包含处理活动、数据主体类别、个人数据类别、角色、接收方、跨境传输、保留映射、DPIA、合法基础、owner 和发现覆盖状态 |\n| 文档说每个处理目的必须有合法基础、同意偏好和权利请求履约证据，机器是否能证明 | 控制项要求 `baseline-privacy-rights-consent-ledger.schema.json` 和示例包含处理目的、合法基础、同意版本、撤回传播、主体权利请求、SLA、自动化决策复核、第三方传播和下游处理阻断 |\n| 文档说每类记录必须有留存排期、法律保全和可防御删除回执，机器是否能证明 | 控制项要求 `baseline-records-retention-legal-hold-ledger.schema.json` 和示例包含记录类别、留存排期、义务来源、司法辖区、legal hold、删除资格、删除传播、备份/日志/向量索引处置和删除回执 |\n| 文档说审计包必须可导出和复核，机器是否能证明 | 控制项要求 `audit-export-manifest.schema.json` 和示例包含范围、内容、验证、签名和留存 |\n| 文档说审计包必须能由仓库生成，机器是否能证明 | 控制项要求 审计导出脚本、Makefile 入口和 checker 自动化检查 |\n| 文档说控制必须被评估和签署，机器是否能证明 | 控制项要求 `control-assessment-report.schema.json` 和示例包含控制结果、发现项、整改、剩余风险和签署 |\n| 文档说基线变更必须受控，机器是否能证明 | 控制项要求 `baseline-change-record.schema.json` 和示例包含影响分析、审批、验证命令和回滚计划 |\n| 文档说重大架构变更必须有 ADR，机器是否能证明 | 控制项要求 `architecture-decision-record.schema.json` 和示例包含上下文、备选方案、取舍、控制项、风险、POA&M 和复审 |\n| 文档说审计证据必须可交换，机器是否能证明 | 控制项要求 `oscal-export-profile.schema.json`、示例和导出脚本覆盖 OSCAL 五类视图 |\n| 文档说发现项必须进入 POA&M 整改计划，机器是否能证明 | 控制项要求 `poam-record.schema.json`、示例和导出脚本覆盖发现项、行动、里程碑、证据和 OSCAL POA&M 输出 |\n| 文档说架构风险必须登记和复审，机器是否能证明 | 控制项要求 `risk-register.schema.json`、示例和导出脚本覆盖风险、控制项、POA&M、缓解行动、残余风险和复审 |\n| 文档说审计导出必须进入质量门禁，机器是否能证明 | 控制项要求 `audit-export-gate.schema.json`、审计导出门禁脚本和 `make test` 覆盖输出不变量 |\n| 文档说审计包交接后必须可防篡改复核，机器是否能证明 | 控制项要求 `audit-export-integrity.schema.json`、导出脚本和门禁覆盖生成物 SHA-256 摘要 |\n| 文档说审计包必须能证明生成来源，机器是否能证明 | 控制项要求 `audit-export-provenance.schema.json`、导出脚本和门禁覆盖 subject digest、构建定义、源码提交和源证据依赖 |\n\n`internal-command://architecture/check-modern-architecture-kit` 必须校验控制清单自身，并校验清单中声明的 schema 字段、example 字段和 checker 证据确实存在。\n\n### 10.10.6 企业执行控制面\n\n企业执行控制面的目标，是把“这个标准是否真的落地”从文档判断变成门禁判断。它不替代具体工具，而是定义所有工具必须对齐的共同控制协议。\n\n控制面由三类文件组成：\n\n```text\ngovernance/control-plane/conformance-profile.yaml\ngovernance/control-plane/control-plane.yaml\ngovernance/control-plane/release-gate-decision.yaml\n```\n\n`conformance-profile.yaml` 定义资产需要执行到什么强度：\n\n```yaml\nprofile: regulated-ai-prod\nappliesTo:\n assetTypes:\n - service\n - data-product\n - ai-product\n environments:\n - prod\nrisk:\n businessCriticality: tier-1\n dataSensitivity: confidential\n aiRiskTier: R3\n internetFacing: true\nrequiredGateLevel: L4\nrequiredEvidence:\n - owner\n - service-contract\n - api-compatibility\n - data-contract\n - ai-evaluation\n - sbom\n - provenance\n - signature-verification\n - gitops-diff\n - slo\n - runbook\n - rollback\n - incident-playbook\n - audit-export\nallowedExceptions:\n maxActiveDays: 30\n requiresRiskAcceptance: true\n requiresCompensatingControl: true\nreview:\n cadence: quarterly\n owner: architecture-governance-board\n```\n\n`control-plane.yaml` 汇总控制项、证据、阻断级别和自动化状态：\n\n```yaml\ncontrolPlane:\n version: V2.28\n owner: architecture-governance-board\n defaultProfile: standard-prod\ncontrols:\n - id: EA-REL-001\n title: Production service has owner, SLO and runbook\n appliesTo:\n - service\n gateLevel: L2\n blocking: true\n evidence:\n - domains/{domain}/services/{service}/service.yaml\n - catalog/components/{service}.yaml\n - governance/evidence/releases/{release}.yaml\n automation:\n status: enforced\n command: service-contract-check\n freshness:\n maxAgeDays: 90\n exception:\n allowed: false\n - id: EA-AI-004\n title: High-risk AI product has evaluation, threat model and incident playbook\n appliesTo:\n - ai-product\n gateLevel: L4\n blocking: true\n evidence:\n - ai/applications/{ai-product}/ai-product.yaml\n - contracts/ai/threat-models/{ai-product}.yaml\n - governance/playbooks/{ai-product}-incident-playbook.yaml\n - governance/evidence/ai/{ai-product}-evidence.yaml\n automation:\n status: measured\n command: ai-release-gate\n freshness:\n maxAgeDays: 30\n exception:\n allowed: true\n maxActiveDays: 14\n requiresHumanApproval: true\n```\n\n`release-gate-decision.yaml` 记录每次门禁结果：\n\n```yaml\ndecision:\n id: gate-2026-06-02-order-command-service\n asset: order-command-service\n profile: regulated-ai-prod\n environment: prod\n result: conditional-pass\n decidedAt: 2026-06-02T07:30:00+08:00\n decidedBy: release-captain\nchecks:\n passed:\n - sbom\n - provenance\n - signature-verification\n - gitops-diff\n failed:\n - recovery-drill-freshness\nexceptions:\n - id: ex-2026-q2-recovery-drill\n expiresAt: 2026-06-16T23:59:59+08:00\n riskAcceptedBy: sre-lead\n compensatingControl: on-call manual recovery drill scheduled\nrequiredActions:\n - owner: team-order\n due: 2026-06-10\n action: complete recovery drill and attach evidence\nrollback:\n required: true\n plan: docs/rollback.md\n```\n\n门禁等级采用五级：\n\n| 等级 | 含义 | 适用对象 | 最低要求 |\n| ---- | ---- | -------- | -------- |\n| `L0` | 记录级 | 实验、非生产、一次性验证 | owner、生命周期、退出日期 |\n| `L1` | 契约级 | 低风险内部服务、内部数据集 | 机器可读契约、catalog、基础测试 |\n| `L2` | 发布级 | 普通生产服务和数据产品 | CI、SLO、runbook、GitOps、发布证据 |\n| `L3` | 证明级 | Tier-1 服务、机密数据、外部接口 | SBOM、provenance、签名验签、恢复演练、控制证据映射 |\n| `L4` | 受控级 | 高风险 AI、受监管流程、关键资金链路 | 独立审批、红队、审计导出、POA&M、风险接受和季度复核 |\n\n门禁结果只能使用以下五类：\n\n| 结果 | 含义 | 是否允许发布 | 必须附带 |\n| ---- | ---- | ------------ | -------- |\n| `pass` | 所有阻断项通过 | 是 | 自动化证据和审计索引 |\n| `conditional-pass` | 非阻断项缺失或证据临近过期 | 是 | 到期行动、owner、补偿控制 |\n| `fail` | 阻断项失败 | 否 | 失败项、修复建议、重新验证命令 |\n| `exception` | 经授权的风险接受 | 视等级而定 | 到期时间、批准人、补偿控制、POA&M |\n| `break-glass` | 生产紧急处置 | 临时允许 | 事故编号、最短有效期、事后复盘和回补证据 |\n\n执行规则：\n\n1. `L3` 和 `L4` 资产不得仅凭人工评审发布，必须有机器证据和签署记录。\n2. `conditional-pass` 不能连续出现两次；第二次必须转为 `fail` 或正式例外。\n3. 所有 `exception` 必须有到期时间、风险接受人、补偿控制和关闭条件。\n4. `break-glass` 只能用于生产事故或监管时限，必须在 24 到 72 小时内补齐复盘和证据。\n5. 证据过期视为证据缺失；关键证据过期必须阻断同等级资产的新发布。\n6. 每季度必须抽样复核 `L3` / `L4` 资产，复核结果进入 `control-assessment-report.yaml`。\n7. 控制面本身的变更必须走 ADR、CODEOWNERS、受保护分支和基线变更记录。\n\n可执行验收标准：\n\n1. 任意生产资产都能找到自己的 `conformance-profile`。\n2. 任意阻断控制都能从 `control-plane` 追溯到证据路径、自动化状态和 owner。\n3. 任意发布都能找到 `release-gate-decision`，并能解释为什么通过、阻断或例外放行。\n4. 任意例外都能找到到期时间、补偿控制、风险接受人和关闭证据。\n5. 任意审计导出都能包含控制面版本、门禁决策摘要、开放例外和 POA&M 状态。\n\n### 10.10.7 外部标准版本锁定与升级策略\n\n企业标准不能直接引用“latest”。外部标准、规范、语义约定和工具能力都必须先进入版本锁定清单，再进入控制面、门禁和审计证据。\n\n标准基线由 `standards-baseline.yaml` 维护：\n\n```yaml\nstandardBaseline:\n version: V2.29\n owner: architecture-governance-board\n reviewCadence: quarterly\nstandards:\n - id: slsa\n name: Supply-chain Levels for Software Artifacts\n pinnedVersion: v1.2\n status: approved\n adoptionLevel: enforce\n sourceUrl: https://slsa.dev/spec/v1.2/\n reviewedAt: \"2026-06-02\"\n appliesTo:\n - supply-chain-attestation\n - audit-export-provenance\n minimumGateLevel: L3\n upgradePolicy:\n requiresAdr: true\n requiresCompatibilityReview: true\n rollout: phased\n - id: otel-genai\n name: OpenTelemetry Semantic Conventions for Generative AI\n pinnedVersion: semconv-1.41.0\n status: development\n adoptionLevel: observe\n sourceUrl: https://opentelemetry.io/docs/specs/semconv/gen-ai/\n reviewedAt: \"2026-06-02\"\n appliesTo:\n - genai-observability-contract\n - ai-evidence\n minimumGateLevel: L2\n upgradePolicy:\n requiresAdr: false\n requiresCompatibilityReview: true\n rollout: opt-in\n```\n\n采纳等级分为四类：\n\n| 等级 | 含义 | 是否可阻断发布 | 示例 |\n| ---- | ---- | -------------- | ---- |\n| `reference` | 仅作为设计参考，不进入门禁 | 否 | 白皮书、方法论、非规范文章 |\n| `observe` | 进入观测和证据字段，但不作为硬阻断 | 否 | Development 状态语义约定、实验性 Agent 协议 |\n| `gate` | 进入门禁，但允许阶段性例外 | 是 | API 兼容、数据质量、GenAI trace 覆盖率 |\n| `enforce` | 强制执行，例外必须有风险接受和到期时间 | 是 | SLSA provenance、SBOM、签名验签、生产 GitOps digest |\n\n稳定性分级：\n\n| 状态 | 处理方式 |\n| ---- | -------- |\n| `approved` / `stable` | 可以进入 `gate` 或 `enforce`，但仍需锁定版本 |\n| `draft` / `release-candidate` | 默认进入 `gate`，不得直接设为全局 `enforce` |\n| `concept-note` / `community-preview` | 默认进入 `observe` 或 `reference`，不得作为强制门禁 |\n| `development` / `experimental` | 默认只能 `observe`，生产阻断必须有 ADR 和灰度窗口 |\n| `deprecated` | 禁止新项目采用，既有项目必须给出迁移截止日期 |\n\n基线升级流程：\n\n1. 识别外部标准新版本、状态变化、废弃说明和向后兼容风险。\n2. 由 owner 生成标准升级影响分析，列出受影响契约、控制项、工具和证据字段。\n3. 对 `gate` / `enforce` 标准必须形成 ADR 或基线变更记录。\n4. 先在非生产 profile 或低风险资产上灰度，验证 CI、导出包、catalog 和观测字段兼容性。\n5. 灰度通过后更新 `standards-baseline.yaml`、控制项覆盖清单和相关门禁。\n6. 如果升级导致审计字段、证据格式或策略结果变化，必须生成迁移说明和回滚路径。\n\n当前建议锁定的关键标准基线：\n\n| 标准 | 建议状态 | 采纳等级 | 说明 |\n| ---- | -------- | -------- | ---- |\n| SLSA v1.2 | approved | enforce | 用于 provenance、构建来源和供应链证明 |\n| SPDX 3.0.1 / CycloneDX 1.7 | stable | enforce | 用于 SBOM 生成和制品审计 |\n| CISA KEV / FIRST EPSS / CVSS v4.0 / CycloneDX VEX / OASIS CSAF | stable | enforce | 用于漏洞优先级、可利用性、影响状态、修复 SLA、风险接受和 VEX/CSAF 交换 |\n| CIS Controls v8 Control 4 / CIS Benchmarks / NIST SP 800-128 / NIST SP 800-53 CM / SCAP / Kubernetes Pod Security Standards | stable | enforce | 用于安全配置基线、加固姿态、配置漂移、配置变更控制、Pod Security、扫描复测和例外阻断 |\n| Sigstore / Cosign | stable | enforce | 用于镜像、provenance 和审计导出签名验签 |\n| NIST AI RMF 1.0 + NIST AI 600-1 | stable | gate | 用于 AI 风险治理、评估和管理闭环 |\n| NIST AI RMF Critical Infrastructure Profile Concept Note | concept-note | observe | 用于关键基础设施 AI 场景观察和预研，不作为稳定强制门禁 |\n| OpenTelemetry Semantic Conventions 1.41.0 / GenAI SemConv | development | observe | 用于 GenAI trace、Token、模型和工具调用观测，生产字段需版本锁定 |\n| OWASP LLM / Agentic AI | active | gate | 用于威胁模型、红队和工具权限门禁 |\n| Kubernetes / OpenGitOps | stable | enforce | 用于运行期望状态、漂移检测和 GitOps 发布控制 |\n| CNCF Platform Engineering Maturity Model | reference | reference | 用于平台成熟度评估，不直接阻断发布 |\n\n禁止事项：\n\n1. 禁止在生产门禁中使用未锁定版本的外部标准。\n2. 禁止把 `development` 状态规范直接设为全局强制阻断。\n3. 禁止把 `concept-note`、白皮书、社区预览或供应商路线图当作稳定合规要求。\n4. 禁止标准升级只改文档、不改 checker、证据字段和迁移说明。\n5. 禁止一个团队私自升级共享门禁标准，导致其他团队 CI 或审计导出漂移。\n\n### 10.10.8 版本控制面和基线发布协议\n\n`version-governance.yaml` 是架构基线发布的控制面。它不存放正文内容，而是把版本、Git、证据和门禁绑定成同一条可验证事实链。\n\n```yaml\nversionGovernance:\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n releaseChannel: candidate\n status: Baseline Candidate\n owner: architecture-governance-board\n sourceCommit: \n releaseTag: architecture/v2.53-candidate\n tagSigned: true\n effectiveFrom: 2026-06-02\n supersedes: V2.52\n compatibility:\n changeLevel: minor\n backwardCompatible: true\n compatibilityWindow: P90D\n migrationRequired: false\n linkedBaselines:\n versionManifest: governance/control-plane/version-manifest.yaml\n controlCoverage: governance/control-plane/control-coverage.yaml\n standardsBaseline: governance/control-plane/standards-baseline.yaml\n enforcementPolicy: governance/control-plane/baseline-enforcement-policy.yaml\n versionPolicyReleaseControlLedger: governance/evidence/baselines/baseline-version-policy-release-control-ledger.yaml\n auditExportManifest: governance/evidence/audit-export/audit-export-manifest.yaml\n lifecycleStateMachine: governance/evidence/baselines/baseline-lifecycle-state-machine.yaml\n stateReconciliation: governance/evidence/baselines/baseline-state-reconciliation-report.yaml\n evidenceTraceGraph: governance/evidence/baselines/baseline-evidence-trace-graph.yaml\n gateExecutionReport: governance/evidence/baselines/baseline-gate-execution-report.yaml\n publishTransaction: governance/evidence/baselines/baseline-publish-transaction.yaml\n revocationRecord: governance/evidence/baselines/baseline-revocation-record.yaml\n compatibilityLedger: governance/evidence/compatibility/baseline-compatibility-ledger.yaml\n adoptionLedger: governance/evidence/adoption/baseline-adoption-ledger.yaml\n supportMatrix: governance/evidence/support/baseline-support-matrix.yaml\n eolRetirementCertificate: governance/evidence/baselines/baseline-eol-retirement-certificate.yaml\n releaseTrain: governance/evidence/release-trains/baseline-release-train.yaml\n readinessScorecard: governance/evidence/baselines/baseline-readiness-scorecard.yaml\n reviewBoardDecision: governance/evidence/baselines/baseline-review-board-decision.yaml\n exceptionLedger: governance/evidence/exceptions/baseline-exception-ledger.yaml\n notificationLedger: governance/evidence/communications/baseline-notification-ledger.yaml\n rollbackVerification: governance/evidence/rollback/baseline-rollback-verification.yaml\n conformanceClaims: governance/evidence/conformance/baseline-conformance-claim.yaml\n consumptionLocks: governance/evidence/conformance/baseline-consumption-lock.yaml\n migrationWorkOrders: governance/evidence/migrations/baseline-migration-work-order.yaml\n migrationExecutionReceipts: governance/evidence/migrations/baseline-migration-execution-receipt.yaml\n localArtifactBoundary: governance/evidence/baselines/baseline-local-artifact-boundary.yaml\n auditExportExclusionManifest: governance/evidence/audit-export/audit-export-exclusion-manifest.yaml\n privateArtifactEscrowManifest: governance/evidence/baselines/private-artifact-escrow-manifest.yaml\n threatModelAttackSurfaceRiskLedger: governance/evidence/baselines/baseline-threat-model-attack-surface-risk-ledger.yaml\n vulnerabilityExposureRemediationLedger: governance/evidence/baselines/baseline-vulnerability-exposure-remediation-ledger.yaml\n secureConfigurationPostureDriftLedger: governance/evidence/baselines/baseline-secure-configuration-posture-drift-ledger.yaml\n productionChangeReleaseLedger: governance/evidence/baselines/baseline-production-change-release-ledger.yaml\n incidentProblemCorrectiveActionLedger: governance/evidence/baselines/baseline-incident-problem-corrective-action-ledger.yaml\n dataProductQualityContractObservabilityLedger: governance/evidence/baselines/baseline-data-product-quality-contract-observability-ledger.yaml\n engineeringQualityTestReleaseVerificationLedger: governance/evidence/baselines/baseline-engineering-quality-test-release-verification-ledger.yaml\n workforceCompetencyTrainingDutySegregationLedger: governance/evidence/baselines/baseline-workforce-competency-training-duty-segregation-ledger.yaml\n businessOutcomeValueRealizationPortfolioLedger: governance/evidence/baselines/baseline-business-outcome-value-realization-portfolio-ledger.yaml\n valueStreamJourneyProcessLedger: governance/evidence/baselines/baseline-value-stream-journey-process-ledger.yaml\n architectureViewRuntimeTopologyDependencyLedger: governance/evidence/baselines/baseline-architecture-view-runtime-topology-dependency-ledger.yaml\n qualityAttributeArchitectureDriverTradeoffLedger: governance/evidence/baselines/baseline-quality-attribute-architecture-driver-tradeoff-ledger.yaml\n architecturePrincipleConstraintExceptionLedger: governance/evidence/baselines/baseline-architecture-principle-constraint-exception-ledger.yaml\n capacityPerformanceCostEfficiencyLedger: governance/evidence/baselines/baseline-capacity-performance-cost-efficiency-ledger.yaml\n serviceReliabilitySloErrorBudgetObservabilityLedger: governance/evidence/baselines/baseline-service-reliability-slo-error-budget-observability-ledger.yaml\n backupRestoreDisasterRecoveryLedger: governance/evidence/baselines/baseline-backup-restore-disaster-recovery-ledger.yaml\n cryptographicSecretsKeyCertificateLedger: governance/evidence/baselines/baseline-cryptographic-secrets-key-certificate-ledger.yaml\n assetCriticalityClassificationLedger: governance/evidence/baselines/baseline-asset-criticality-classification-ledger.yaml\n identityEntitlementAccessLedger: governance/evidence/baselines/baseline-identity-entitlement-access-ledger.yaml\n processingActivityInventoryLedger: governance/evidence/baselines/baseline-processing-activity-inventory-ledger.yaml\n privacyRightsConsentLedger: governance/evidence/baselines/baseline-privacy-rights-consent-ledger.yaml\n recordsRetentionLegalHoldLedger: governance/evidence/baselines/baseline-records-retention-legal-hold-ledger.yaml\n regulatoryObligationLedger: governance/evidence/baselines/baseline-regulatory-obligation-ledger.yaml\n artifactInventory: governance/evidence/baselines/baseline-artifact-inventory.yaml\n verificationLock: governance/evidence/verification/baseline-verification-lock.yaml\n gates:\n required:\n - make sync-doc-toc\n - make test\n - git diff --check\n releaseDecision: governance/control-plane/release-gate-decision.yaml\n freezePolicy:\n canFreezeAfter:\n - architecture-review-approved\n - audit-export-generated\n - open-critical-findings-zero\n emergencyPatchAllowed: true\n rollback:\n previousBaseline: V2.52\n rollbackCommit: \n rollbackTag: architecture/v2.52-candidate\n rollbackGuide: governance/evidence/baseline-changes/baseline-change-record.yaml\n rollbackVerification: governance/evidence/rollback/baseline-rollback-verification.yaml\n```\n\n执行规则：\n\n1. `documentVersion` 必须等于主文档版本、版本清单版本和审计导出版本。\n2. `baselineId` 一经发布不得复用；同一 `baselineId` 不得指向不同 commit。\n3. `releaseTag` 必须指向 `sourceCommit`，生产级基线必须使用签名 tag。\n4. `releaseChannel=baseline` 或 `frozen` 时，必须有 `release-gate-decision.yaml`、基线准入执行策略、基线版本策略、发布通道、兼容性与冻结控制总账、基线消费锁定文件、基线迁移工作单、基线迁移执行回执、本地私有制品边界、审计导出排除清单、私有制品托管交接清单、基线生产变更、发布编排、变更冲突与失败恢复总账、基线事故、问题、纠正行动与复发防止总账、基线数据产品质量、契约违约、运行血缘与可观测性总账、基线工程质量、测试证据、缺陷与发布验证总账、基线人员能力、培训、职责履职与职责分离总账、基线业务结果、价值实现与组合收益总账、基线价值流、关键旅程与端到端流程总账、基线架构视图、运行拓扑与依赖影响总账、基线质量属性、架构驱动与权衡决策总账、基线架构原则、约束、反模式与例外执行总账、基线服务可靠性、SLO、错误预算与可观测性总账、基线备份、恢复、灾备与可恢复性验证总账、基线密码材料、密钥、证书与秘密生命周期总账、基线资产关键性、数据分类与风险分级总账、基线身份权限、特权访问与工作负载身份总账、基线处理活动、个人数据清单与 RoPA 覆盖总账、基线隐私权利请求、同意偏好与合法基础执行总账、基线记录留存、法律保全与可防御删除总账、基线监管与合规义务可追溯总账、基线生命周期状态机、基线状态对账报告、基线证据追踪图、基线门禁执行报告、基线发布事务回执、基线撤销与隔离记录、基线验证环境锁、基线制品清单、基线就绪评分卡、基线会审裁决记录、基线例外总账、通知确认总账、回滚验证记录和审计导出清单。\n5. `changeLevel=major` 或 `breaking` 时，必须引用 ADR、迁移计划、弃用策略和消费者影响分析。\n6. `compatibilityWindow` 到期后，未迁移消费者必须转入例外、POA&M 或风险接受记录。\n7. 回滚不能只写“回退上一版”，必须指向可 checkout 的 commit、tag、GitOps revision 或制品 digest。\n\n可执行验收标准：\n\n1. 任意基线都能从 `version-governance.yaml` 追溯到源 commit、release tag、版本清单、基线准入执行策略、基线消费锁定文件、基线迁移工作单、基线迁移执行回执、本地私有制品边界、审计导出排除清单、私有制品托管交接清单、基线生产变更、发布编排、变更冲突与失败恢复总账、基线事故、问题、纠正行动与复发防止总账、基线数据产品质量、契约违约、运行血缘与可观测性总账、基线工程质量、测试证据、缺陷与发布验证总账、基线人员能力、培训、职责履职与职责分离总账、基线业务结果、价值实现与组合收益总账、基线价值流、关键旅程与端到端流程总账、基线架构视图、运行拓扑与依赖影响总账、基线质量属性、架构驱动与权衡决策总账、基线服务可靠性、SLO、错误预算与可观测性总账、基线备份、恢复、灾备与可恢复性验证总账、基线密码材料、密钥、证书与秘密生命周期总账、基线资产关键性、数据分类与风险分级总账、基线身份权限、特权访问与工作负载身份总账、基线处理活动、个人数据清单与 RoPA 覆盖总账、基线隐私权利请求、同意偏好与合法基础执行总账、基线记录留存、法律保全与可防御删除总账、基线监管与合规义务可追溯总账、基线生命周期状态机、基线状态对账报告、基线证据追踪图、基线门禁执行报告、基线发布事务回执、基线撤销与隔离记录、基线就绪评分卡、基线会审裁决记录、基线例外总账、通知确认总账、回滚验证记录、验证环境锁、基线制品清单、EOL 退役证书和审计导出。\n2. 任意冻结基线都能证明没有被直接修改；后续变更只能通过补丁或新基线替代。\n3. 任意 breaking change 都能找到兼容窗口、消费者清单、迁移说明和回滚入口。\n4. 任意 emergency patch 都能找到事故或安全编号、补丁范围、事后复盘和补齐证据。\n\n### 10.10.9 基线发布证据包与版本漂移复核\n\n`baseline-release-evidence.yaml` 是基线从 `candidate` 晋级到 `baseline` 或 `frozen` 的证据包。它不替代 `version-governance.yaml`，而是证明版本控制面声明的事实已经被验证。\n\n```yaml\nbaselineReleaseEvidence:\n evidenceId: bre-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n owner: architecture-governance-board\n promotion:\n fromChannel: candidate\n toChannel: baseline\n requestedBy: architecture-governance-board\n approvedBy:\n - platform-lead\n - security-lead\n - data-governance-lead\n decision: pass\n decidedAt: 2026-06-02T10:30:00+08:00\n immutableRefs:\n sourceCommit: \n releaseTag: architecture/v2.53-candidate\n tagSignatureVerified: true\n versionPolicyReleaseControlLedgerDigest: sha256:\n publishTransactionDigest: sha256:\n enforcementPolicyDigest: sha256:\n consumptionLockDigest: sha256:\n migrationWorkOrderDigest: sha256:\n migrationExecutionReceiptDigest: sha256:\n localArtifactBoundaryDigest: sha256:\n auditExportExclusionManifestDigest: sha256:\n privateArtifactEscrowManifestDigest: sha256:\n cleanRoomReconstructionReceiptDigest: sha256:\n evidenceArchiveReceiptDigest: sha256:\n signatureLtvReceiptDigest: sha256:\n runtimeAdmissionReceiptDigest: sha256:\n runtimeAdmissionDecisionLedgerDigest: sha256:\n continuousControlMonitoringLedgerDigest: sha256:\n controlAssuranceSamplingLedgerDigest: sha256:\n controlInheritanceLedgerDigest: sha256:\n dataResidencyTransferLedgerDigest: sha256:\n thirdPartyRiskLedgerDigest: sha256:\n operationalResilienceLedgerDigest: sha256:\n threatModelAttackSurfaceRiskLedgerDigest: sha256:\n vulnerabilityExposureRemediationLedgerDigest: sha256:\n secureConfigurationPostureDriftLedgerDigest: sha256:\n productionChangeReleaseLedgerDigest: sha256:\n incidentProblemCorrectiveActionLedgerDigest: sha256:\n dataProductQualityContractObservabilityLedgerDigest: sha256:\n engineeringQualityTestReleaseVerificationLedgerDigest: sha256:\n workforceCompetencyTrainingDutySegregationLedgerDigest: sha256:\n businessOutcomeValueRealizationPortfolioLedgerDigest: sha256:\n valueStreamJourneyProcessLedgerDigest: sha256:\n architectureViewRuntimeTopologyDependencyLedgerDigest: sha256:\n qualityAttributeArchitectureDriverTradeoffLedgerDigest: sha256:\n architecturePrincipleConstraintExceptionLedgerDigest: sha256:\n capacityPerformanceCostEfficiencyLedgerDigest: sha256:\n serviceReliabilitySloErrorBudgetObservabilityLedgerDigest: sha256:\n regulatoryObligationLedgerDigest: sha256:\n backupRestoreDisasterRecoveryLedgerDigest: sha256:\n cryptographicSecretsKeyCertificateLedgerDigest: sha256:\n assetCriticalityClassificationLedgerDigest: sha256:\n identityEntitlementAccessLedgerDigest: sha256:\n processingActivityInventoryLedgerDigest: sha256:\n privacyRightsConsentLedgerDigest: sha256:\n recordsRetentionLegalHoldLedgerDigest: sha256:\n auditExportDigest: sha256:\n controlCoverageDigest: sha256:\n lifecycleStateMachineDigest: sha256:\n stateReconciliationDigest: sha256:\n evidenceTraceGraphDigest: sha256:\n gateExecutionReportDigest: sha256:\n revocationRecordDigest: sha256:\n eolRetirementCertificateDigest: sha256:\n reviewBoardDecisionDigest: sha256:\n artifactInventoryDigest: sha256:\n verificationLockDigest: sha256:\n readinessScorecardDigest: sha256:\n exceptionLedgerDigest: sha256:\n notificationLedgerDigest: sha256:\n rollbackVerificationDigest: sha256:\n invariants:\n documentVersionMatchesManifest: true\n controlCoverageMatchesManifest: true\n lifecycleTransitionAllowed: true\n stateReconciliationHasNoDrift: true\n evidenceTraceGraphClosed: true\n evidenceTraceGraphDigestsMatch: true\n gateExecutionReportMatchesReleaseDecision: true\n gateExecutionReplayPasses: true\n publishTransactionRemoteRefsMatch: true\n publishTransactionPostVerificationPasses: true\n enforcementPolicyBlocksUnsupportedBaseline: true\n enforcementPolicyBlocksRevokedOrEolBaseline: true\n enforcementPolicyRequiresConformanceClaim: true\n enforcementPolicyBlocksExpiredException: true\n consumptionLocksUseImmutableRefs: true\n consumptionLocksMatchReleaseEvidence: true\n noFloatingBaselineConsumption: true\n migrationWorkOrdersHaveExecutableSteps: true\n migrationWorkOrdersUpdateConsumptionLocks: true\n migrationWorkOrdersRollbackVerified: true\n migrationExecutionReceiptsBindActualCommands: true\n migrationExecutionReceiptsMatchBeforeAfterDigests: true\n migrationExecutionReceiptsValidateRollback: true\n localPrivateArtifactsDeclared: true\n localPrivateArtifactsAbsentFromRemote: true\n auditExportExclusionManifestPresent: true\n auditExportRawAllowlistEnforced: true\n auditExportDigestOnlyEntriesMatchBoundary: true\n auditExportForcedExclusionsAbsentFromPayload: true\n localPrivateArtifactsExcludedFromSignaturePayload: true\n privateArtifactEscrowManifestPresent: true\n privateArtifactEscrowDigestsMatchBoundary: true\n privateArtifactEscrowRestoreVerified: true\n cleanRoomReconstructionReceiptPresent: true\n cleanRoomReconstructionUsesImmutableRefs: true\n cleanRoomReconstructionReplaysGate: true\n cleanRoomReconstructionDigestMatchesRelease: true\n evidenceArchiveReceiptPresent: true\n evidenceArchiveUsesImmutableStorage: true\n evidenceArchiveRestoreDrillPasses: true\n evidenceArchiveRetentionLocked: true\n signatureLtvReceiptPresent: true\n signatureLtvTimestampVerified: true\n signatureLtvCertificateChainArchived: true\n signatureLtvRevocationStatusRecorded: true\n runtimeAdmissionReceiptPresent: true\n runtimeAdmissionPoliciesEnforced: true\n runtimeAdmissionRejectSamplesVerified: true\n runtimeAdmissionDigestsMatchRelease: true\n runtimeAdmissionDecisionLedgerPresent: true\n runtimeAdmissionDecisionLedgerDigestsMatchRelease: true\n runtimeAdmissionDecisionLedgerCoversAllowDeny: true\n runtimeAdmissionDecisionLedgerLogsArchived: true\n continuousControlMonitoringLedgerPresent: true\n continuousControlMonitoringCriticalControlsCovered: true\n continuousControlMonitoringAlertsConfigured: true\n continuousControlMonitoringOpenCriticalDriftZero: true\n continuousControlMonitoringEvidenceFresh: true\n controlAssuranceSamplingLedgerPresent: true\n controlAssuranceSamplingAssessorIndependent: true\n controlAssuranceSamplingCoversCriticalControls: true\n controlAssuranceSamplingFindingsClosedOrAccepted: true\n controlAssuranceSamplingOscalResultsGenerated: true\n controlInheritanceLedgerPresent: true\n inheritedControlsHaveProviderEvidence: true\n sharedControlsHaveConsumerResponsibilities: true\n noExpiredInheritedControlEvidence: true\n noUnownedSharedControl: true\n dataResidencyTransferLedgerPresent: true\n dataResidencyApprovedRegionsOnly: true\n crossBorderTransfersHaveMechanism: true\n subprocessorsApprovedForDataClasses: true\n noUnapprovedProcessingRegion: true\n noDeletionPropagationGap: true\n thirdPartyRiskLedgerPresent: true\n criticalSuppliersApproved: true\n criticalSuppliersHaveContractsAndAuditRights: true\n criticalSuppliersHaveFreshAssuranceEvidence: true\n criticalSuppliersHaveExitPlans: true\n supplierConcentrationWithinThreshold: true\n noUnapprovedCriticalSupplier: true\n operationalResilienceLedgerPresent: true\n importantBusinessServicesIdentified: true\n impactTolerancesDefinedAndApproved: true\n endToEndDependenciesMapped: true\n severeButPlausibleScenariosTested: true\n scenarioResultsWithinImpactTolerance: true\n noOpenCriticalResilienceGap: true\n toleranceBreachesEscalated: true\n threatModelAttackSurfaceRiskLedgerPresent: true\n threatModelAttackSurfaceRiskDigestMatchesRelease: true\n criticalAssetsHaveThreatModels: true\n threatModelsFreshForCriticalAssets: true\n attackSurfacesInventoried: true\n trustBoundariesAndDataFlowsMapped: true\n highRiskDataFlowsMitigated: true\n criticalAbuseCasesClosedOrAccepted: true\n securityTestsLinkedToThreats: true\n residualRisksSignedOrPoamTracked: true\n releaseGateConsumesThreatModelLedger: true\n vulnerabilityExposureRemediationLedgerPresent: true\n vulnerabilityExposureRemediationDigestMatchesRelease: true\n vulnerabilityFindingsHaveOwners: true\n criticalAndKevFindingsClosedOrAccepted: true\n internetExposedHighFindingsClosedOrBlocked: true\n exploitabilityScoresRecorded: true\n vexOrCsafStatusesRecorded: true\n remediationSlasWithinPolicy: true\n remediationsRetested: true\n expiredVulnerabilityExceptionsZero: true\n scannerCoverageCompleteForCriticalAssets: true\n releaseGateConsumesVulnerabilityLedger: true\n secureConfigurationPostureDriftLedgerPresent: true\n secureConfigurationPostureDriftDigestMatchesRelease: true\n configurationBaselinesAssigned: true\n criticalConfigurationDriftsClosedOrAccepted: true\n podSecurityRestrictedOrAccepted: true\n cloudPublicExposureMisconfigsZero: true\n loggingAndAuditConfigurationEnabled: true\n weakTlsConfigurationsZero: true\n configurationExceptionsNotExpired: true\n configurationRemediationsRetested: true\n releaseGateConsumesSecureConfigurationLedger: true\n productionChangeReleaseLedgerPresent: true\n productionChangeReleaseDigestMatchesRelease: true\n productionChangesRegistered: true\n productionChangeWindowsApproved: true\n productionChangeConflictsResolved: true\n productionChangeRollbacksVerified: true\n productionDatabaseMigrationsRehearsed: true\n productionFeatureFlagsHaveKillSwitch: true\n productionPromptModelChangesEvaluated: true\n emergencyChangesPostReviewed: true\n failedChangesClosedOrLinkedToIncident: true\n releaseGateConsumesProductionChangeLedger: true\n incidentProblemCorrectiveActionLedgerPresent: true\n incidentProblemCorrectiveActionDigestMatchesRelease: true\n incidentsClassifiedAndOwned: true\n incidentTimelinesComplete: true\n incidentRcasCompleted: true\n correctiveActionsClosedOrPoamTracked: true\n recurrencePreventionActionsVerified: true\n incidentRunbooksAndAlertsUpdated: true\n majorIncidentsCommunicationsComplete: true\n recurringIncidentsEscalatedToProblemManagement: true\n doraRecoveryMetricsUpdated: true\n releaseGateConsumesIncidentProblemLedger: true\n dataProductQualityContractObservabilityLedgerPresent: true\n dataProductQualityContractObservabilityDigestMatchesRelease: true\n dataProductsHaveOwnersAndContracts: true\n dataProductQualityAssertionsPass: true\n dataProductFreshnessWithinSlo: true\n dataProductSchemaDriftClosed: true\n dataProductLineageComplete: true\n dataProductContractBreachesClosedOrAccepted: true\n dataProductConsumerNotificationsComplete: true\n dataProductAiFeatureRagUsageAuthorized: true\n releaseGateConsumesDataProductQualityLedger: true\n engineeringQualityTestReleaseVerificationLedgerPresent: true\n engineeringQualityTestReleaseVerificationDigestMatchesRelease: true\n requirementsMappedToTests: true\n criticalTestSuitesPassed: true\n contractAndRegressionTestsPassed: true\n coverageThresholdsMet: true\n flakyTestsQuarantinedOrFixed: true\n criticalAndHighDefectsClosedOrAccepted: true\n defectFixesRetested: true\n releaseSmokeAndCanaryVerificationPassed: true\n qualityRiskAcceptanceSigned: true\n releaseGateConsumesEngineeringQualityLedger: true\n capacityPerformanceCostEfficiencyLedgerPresent: true\n capacityPerformanceCostEfficiencyDigestMatchesRelease: true\n criticalServicesHaveCapacityForecasts: true\n loadTestsFreshForCriticalServices: true\n performanceBaselinesWithinThreshold: true\n resourceRequestsAndLimitsDeclared: true\n autoscalingPoliciesDeclared: true\n queueAndDatabaseCapacityWithinPolicy: true\n budgetsWithinApprovedThreshold: true\n unitEconomicsMeasured: true\n anomalousCostsClosedOrAccepted: true\n serviceReliabilitySloErrorBudgetObservabilityLedgerPresent: true\n serviceReliabilitySloErrorBudgetObservabilityDigestMatchesRelease: true\n criticalServicesHaveSlos: true\n slisAreMeasurable: true\n errorBudgetsWithinPolicy: true\n criticalAlertsRoutedToOnCall: true\n runbooksPresentForCriticalAlerts: true\n syntheticJourneysCovered: true\n telemetryCoverageComplete: true\n noUnownedCriticalAlert: true\n regulatoryObligationLedgerPresent: true\n applicableObligationsMappedToControls: true\n mandatoryObligationsHaveEvidence: true\n noUnownedRegulatoryObligation: true\n regulatoryChangeMonitoringActive: true\n noOverdueObligationPoam: true\n cryptographicSecretsKeyCertificateLedgerPresent: true\n cryptographicMaterialsInventoried: true\n cryptographicMaterialOwnersAssigned: true\n noPlaintextProductionSecret: true\n noExpiredProductionCertificate: true\n noOverdueKeyRotation: true\n noWeakCryptographicAlgorithm: true\n revocationPathsDeclared: true\n leakedSecretsClosedOrRevoked: true\n assetCriticalityClassificationLedgerPresent: true\n allGovernedAssetsClassified: true\n assetOwnersAssigned: true\n dataSensitivityClassified: true\n ciaImpactRatingsDeclared: true\n conformanceProfilesMatchAssetRisk: true\n noCriticalAssetUnderclassified: true\n noUnreviewedAssetClassification: true\n identityEntitlementAccessLedgerPresent: true\n allProductionIdentitiesInventoried: true\n privilegedAccessRequiresApprovalAndMfa: true\n workloadIdentitiesBoundToCatalogAssets: true\n noOrphanedPrivilegedAccount: true\n noStaleEntitlement: true\n breakGlassAccessClosedAndReviewed: true\n jmlLifecycleReconciled: true\n processingActivityInventoryLedgerPresent: true\n allPersonalDataProcessingActivitiesInventoried: true\n processingActivitiesHaveOwners: true\n personalDataCategoriesClassified: true\n dataSubjectCategoriesDeclared: true\n recipientsAndTransfersMapped: true\n ropaCoverageMatchesRuntimeInventory: true\n noUnclassifiedPersonalDataFinding: true\n privacyRightsConsentLedgerPresent: true\n processingPurposesHaveLawfulBasis: true\n consentWithdrawalsPropagated: true\n rightsRequestsWithinSla: true\n noUnknownConsentState: true\n noUnownedProcessingPurpose: true\n automatedDecisionReviewsCovered: true\n thirdPartyPreferencePropagationComplete: true\n recordsRetentionLegalHoldLedgerPresent: true\n recordClassesHaveRetentionSchedules: true\n legalHoldBlocksDeletion: true\n defensibleDeletionReceiptsPresent: true\n noUnownedRecordClass: true\n retentionObligationsMappedToSources: true\n noOverdueRetentionDisposal: true\n noOverRetentionWithoutPurpose: true\n backupRestoreDisasterRecoveryLedgerPresent: true\n allCriticalAssetsHaveRestorePlans: true\n backupsEncryptedAndImmutable: true\n restoreDrillsPassRtoRpo: true\n backupIntegrityVerified: true\n noUnprotectedCriticalDataStore: true\n ransomwareIsolationProven: true\n noOverdueRestoreDrill: true\n revocationRecordRequiredWhenRevoked: true\n revokedBaselineIsBlockedForNewAdoption: true\n eolRetirementCertificateRequiredWhenEol: true\n reviewBoardDecisionSigned: true\n reviewBoardQuorumMet: true\n artifactInventoryMatchesGitTree: true\n verificationLockMatchesRunner: true\n readinessScorecardPassesHardGates: true\n exceptionLedgerHasNoExpiredBlockingException: true\n notificationLedgerCompleteBeforeFreeze: true\n rollbackVerificationMatchesPreviousBaseline: true\n workforceCompetencyTrainingDutySegregationLedgerPresent: true\n criticalRolesAssigned: true\n mandatoryTrainingCurrent: true\n roleAcknowledgementsCurrent: true\n onCallQualificationsCurrent: true\n segregationOfDutiesPassed: true\n toxicRoleCombinationsClosed: true\n delegatedApprovalsCurrent: true\n backupRolesAssigned: true\n releaseGateConsumesWorkforceCompetencyLedger: true\n businessOutcomeValueRealizationPortfolioLedgerPresent: true\n businessObjectivesDefined: true\n valueHypothesesOwned: true\n keyResultsMeasurable: true\n beforeAfterBaselinesCaptured: true\n adoptionEvidenceLinkedToOutcomes: true\n benefitsRealizationReviewed: true\n unitEconomicsExplained: true\n stopOrScaleDecisionRecorded: true\n releaseGateConsumesBusinessOutcomeLedger: true\n valueStreamJourneyProcessLedgerPresent: true\n valueStreamsMapped: true\n criticalJourneysOwned: true\n processModelsCurrent: true\n stepTelemetryCovered: true\n crossDomainHandoffsTraceable: true\n bottlenecksHaveActions: true\n manualFallbacksExercised: true\n releaseGateConsumesValueStreamLedger: true\n architectureViewRuntimeTopologyDependencyLedgerPresent: true\n architectureViewsCurrent: true\n declaredDependenciesMatchedObserved: true\n runtimeTopologyCovered: true\n gitopsTopologyTraceable: true\n criticalDependencyOwnersPresent: true\n unknownRuntimeCallsClosed: true\n blastRadiusAssessed: true\n dependencyDriftHasActions: true\n releaseGateConsumesArchitectureTopologyLedger: true\n qualityAttributeArchitectureDriverTradeoffLedgerPresent: true\n qualityScenariosMeasured: true\n architectureDriversMappedToBusinessOutcomes: true\n criticalTradeoffsHaveAdr: true\n sensitivityPointsMonitored: true\n fitnessFunctionsPass: true\n qualityVerificationEvidenceFresh: true\n releaseGateConsumesQualityAttributeLedger: true\n architecturePrincipleConstraintExceptionLedgerPresent: true\n mandatoryArchitecturePrinciplesHaveOwners: true\n architectureConstraintsMachineDetectable: true\n forbiddenPatternsMappedToGates: true\n principleViolationsHaveDisposition: true\n principleExceptionsValidAndTimeBound: true\n architecturePrincipleRiskAcceptancesSigned: true\n releaseGateConsumesArchitecturePrincipleLedger: true\n versionPolicyReleaseControlLedgerPresent: true\n versionIdsUnique: true\n releaseTagsSignedAndImmutable: true\n noFloatingVersionReferences: true\n compatibilityWindowsEnforced: true\n freezeWindowControlsPassed: true\n revokedAndEolBaselinesBlocked: true\n releaseGateConsumesVersionPolicyLedger: true\n starterKitPairCountMatches: true\n forbiddenLocalAssetsAbsentFromRemote: true\n noLatestExternalStandardInGate: true\n driftReview:\n reviewedAt: 2026-06-02T10:00:00+08:00\n reviewer: architecture-governance-board\n driftStatus: none\n checkedRefs:\n - governance/control-plane/version-governance.yaml\n - governance/control-plane/standards-baseline.yaml\n - governance/control-plane/control-plane.yaml\n - governance/control-plane/baseline-enforcement-policy.yaml\n - governance/evidence/baselines/baseline-lifecycle-state-machine.yaml\n - governance/evidence/baselines/baseline-state-reconciliation-report.yaml\n - governance/evidence/baselines/baseline-evidence-trace-graph.yaml\n - governance/evidence/baselines/baseline-gate-execution-report.yaml\n - governance/evidence/baselines/baseline-publish-transaction.yaml\n - governance/evidence/baselines/baseline-revocation-record.yaml\n - governance/evidence/baselines/baseline-engineering-quality-test-release-verification-ledger.yaml\n - governance/evidence/baselines/baseline-workforce-competency-training-duty-segregation-ledger.yaml\n - governance/evidence/baselines/baseline-business-outcome-value-realization-portfolio-ledger.yaml\n - governance/evidence/baselines/baseline-value-stream-journey-process-ledger.yaml\n - governance/evidence/baselines/baseline-architecture-view-runtime-topology-dependency-ledger.yaml\n - governance/evidence/baselines/baseline-quality-attribute-architecture-driver-tradeoff-ledger.yaml\n - governance/evidence/baselines/baseline-architecture-principle-constraint-exception-ledger.yaml\n - governance/evidence/baselines/baseline-version-policy-release-control-ledger.yaml\n - governance/evidence/baselines/baseline-eol-retirement-certificate.yaml\n - governance/evidence/baselines/baseline-review-board-decision.yaml\n - governance/evidence/verification/baseline-verification-lock.yaml\n - governance/evidence/baselines/baseline-readiness-scorecard.yaml\n - governance/evidence/exceptions/baseline-exception-ledger.yaml\n - governance/evidence/baselines/baseline-runtime-admission-receipt.yaml\n - governance/evidence/baselines/baseline-runtime-admission-decision-ledger.yaml\n - governance/evidence/baselines/baseline-continuous-control-monitoring-ledger.yaml\n - governance/evidence/baselines/baseline-control-assurance-sampling-ledger.yaml\n - governance/evidence/baselines/baseline-control-inheritance-ledger.yaml\n - governance/evidence/baselines/baseline-data-residency-transfer-ledger.yaml\n - governance/evidence/baselines/baseline-third-party-risk-ledger.yaml\n - governance/evidence/baselines/baseline-operational-resilience-ledger.yaml\n - governance/evidence/baselines/baseline-threat-model-attack-surface-risk-ledger.yaml\n - governance/evidence/baselines/baseline-vulnerability-exposure-remediation-ledger.yaml\n - governance/evidence/baselines/baseline-secure-configuration-posture-drift-ledger.yaml\n - governance/evidence/baselines/baseline-production-change-release-ledger.yaml\n - governance/evidence/baselines/baseline-incident-problem-corrective-action-ledger.yaml\n - governance/evidence/baselines/baseline-data-product-quality-contract-observability-ledger.yaml\n - governance/evidence/baselines/baseline-capacity-performance-cost-efficiency-ledger.yaml\n - governance/evidence/baselines/baseline-service-reliability-slo-error-budget-observability-ledger.yaml\n - governance/evidence/baselines/baseline-regulatory-obligation-ledger.yaml\n - governance/evidence/baselines/baseline-backup-restore-disaster-recovery-ledger.yaml\n - governance/evidence/baselines/baseline-cryptographic-secrets-key-certificate-ledger.yaml\n - governance/evidence/baselines/baseline-asset-criticality-classification-ledger.yaml\n - governance/evidence/baselines/baseline-identity-entitlement-access-ledger.yaml\n - governance/evidence/baselines/baseline-processing-activity-inventory-ledger.yaml\n - governance/evidence/baselines/baseline-privacy-rights-consent-ledger.yaml\n - governance/evidence/baselines/baseline-records-retention-legal-hold-ledger.yaml\n - governance/evidence/baselines/baseline-artifact-inventory.yaml\n - governance/evidence/release-trains/baseline-release-train.yaml\n - governance/evidence/communications/baseline-notification-ledger.yaml\n - governance/evidence/rollback/baseline-rollback-verification.yaml\n - governance/evidence/conformance/baseline-conformance-claim.yaml\n - governance/evidence/conformance/baseline-consumption-lock.yaml\n - governance/evidence/migrations/baseline-migration-work-order.yaml\n - governance/evidence/migrations/baseline-migration-execution-receipt.yaml\n - governance/evidence/audit-export/audit-export-exclusion-manifest.yaml\n - governance/evidence/audit-export/audit-export-manifest.yaml\n findings:\n critical: 0\n high: 0\n medium: 0\n freezeReview:\n eligibleForFrozen: false\n readinessScore: 96\n readinessLevel: ready-for-baseline\n openCriticalFindings: 0\n reviewBoardDecision: approve-baseline\n reviewBoardDissentingVotes: 0\n activeBlockingExceptions: 0\n expiredExceptions: 0\n missingRequiredAcknowledgements: 0\n activeNotificationObjections: 0\n openExceptions:\n blocking: 0\n expiringWithinDays: 14\n rollback:\n verified: true\n previousBaseline: V2.52\n rollbackTag: architecture/v2.52-candidate\n rollbackGuide: governance/evidence/baseline-changes/baseline-change-record.yaml\n rollbackVerification: governance/evidence/rollback/baseline-rollback-verification.yaml\n verification:\n commands:\n - make sync-doc-toc\n - make test\n - git diff --check\n - git ls-tree -r --name-only origin/develop -- assets/templates/modern-enterprise-architecture-private/kit\n result: pass\n```\n\n晋级矩阵：\n\n| 晋级路径 | 必须证明 | 阻断条件 |\n| -------- | -------- | -------- |\n| `draft -> candidate` | 版本号、变更摘要、影响面、索引同步和基础门禁通过 | 文档版本和索引不一致 |\n| `candidate -> baseline` | `baseline-lifecycle-state-machine.yaml`、`baseline-state-reconciliation-report.yaml`、`baseline-evidence-trace-graph.yaml`、`baseline-evidence-assurance-classification.yaml`、`baseline-gate-execution-report.yaml`、`baseline-gate-negative-test-suite.yaml`、`baseline-ai-system-regulatory-impact-ledger.yaml`、`baseline-publish-transaction.yaml`、`baseline-release-evidence.yaml`、`baseline-enforcement-policy.yaml`、`baseline-runtime-admission-receipt.yaml`、`baseline-runtime-admission-decision-ledger.yaml`、`baseline-continuous-control-monitoring-ledger.yaml`、`baseline-operational-resilience-ledger.yaml`、`baseline-secure-configuration-posture-drift-ledger.yaml`、`baseline-production-change-release-ledger.yaml`、`baseline-incident-problem-corrective-action-ledger.yaml`、`baseline-data-product-quality-contract-observability-ledger.yaml`、`baseline-engineering-quality-test-release-verification-ledger.yaml`、`baseline-workforce-competency-training-duty-segregation-ledger.yaml`、`baseline-capacity-performance-cost-efficiency-ledger.yaml`、`baseline-service-reliability-slo-error-budget-observability-ledger.yaml`、`baseline-backup-restore-disaster-recovery-ledger.yaml`、`baseline-regulatory-obligation-ledger.yaml`、`baseline-cryptographic-secrets-key-certificate-ledger.yaml`、`baseline-asset-criticality-classification-ledger.yaml`、`baseline-identity-entitlement-access-ledger.yaml`、`baseline-processing-activity-inventory-ledger.yaml`、`baseline-privacy-rights-consent-ledger.yaml`、`baseline-records-retention-legal-hold-ledger.yaml`、`baseline-consumption-lock.yaml`、`baseline-migration-work-order.yaml`、`baseline-migration-execution-receipt.yaml`、基线就绪评分卡、基线会审裁决记录、版本控制面、验证环境锁、审计导出、控制覆盖、远端 ref、push 回执和 tag 验签通过 | 状态机未允许迁移、状态对账失败、证据追踪图断链、证据保证等级缺失、关键证据低于 gate 最低等级、证据采信状态为 rejected/expired/unverifiable、证据保证等级未被发布证据/会审/审计导出消费、门禁执行报告失败或不可重放、负例套件缺失、AI 系统监管分类总账缺失、高风险 AI 分类未知、人工监督或日志留存缺失、技术文档或后市场监测缺失、坏样例被放行、预期失败未失败、故障注入未覆盖关键门禁、发布事务缺失、准入策略未执行、运行时 admission 未启用、准入决策总账缺失、连续控制监测缺失或关键漂移未关闭、安全配置姿态总账缺失、关键配置基线缺失、critical 配置漂移未关闭、未批准特权 Pod、公共存储暴露、弱 TLS、审计日志关闭、配置修复缺复测、生产变更总账缺失、生产变更未登记、黑窗内非紧急变更、关键依赖冲突未关闭、回滚计划缺失、数据库迁移未演练、Feature Flag 无 kill switch、Prompt/模型变更未评估、紧急变更无事后复盘、变更失败未关闭或未关联事故、事故问题总账缺失、事故未定级、事故无 owner、RCA 缺失、纠正行动逾期、复发防止未验证、runbook 或告警未更新、同类事故复发未升级、客户或监管沟通缺失、问题记录未关闭、数据产品质量契约总账缺失、数据产品无 owner 或契约、schema drift 未关闭、质量断言或 freshness 违约、血缘缺口、消费者未通知、AI/特征/RAG 使用未授权、契约违约未关闭或修复未复测、工程质量总账缺失、需求追踪缺失、关键测试缺失、覆盖率低于阈值、flaky 测试未治理、critical/high 缺陷未关闭或未接受、修复未复测、发布验证缺失、质量风险未签署、人员能力总账缺失、关键角色未任命、培训或专项资格过期、职责未确认、on-call 未认证、审批人与执行人未分离、冲突角色未关闭、代理授权过期、关键岗位无人备份、运营韧性总账缺失、重要业务服务未识别、影响容忍缺失、场景测试失败或超出影响容忍、容量性能成本总账缺失、关键服务无容量模型、压测过期、p95/p99 退化、资源未声明、自动扩缩容缺失、预算超支无审批、单位成本不可解释、异常成本未关闭、服务可靠性总账缺失、关键服务无 SLO、SLI 不可测、错误预算超支未冻结风险变更、关键告警无人接、on-call 缺失、runbook 缺失、合成探测未覆盖用户旅程、日志/指标/链路覆盖缺口、降级策略缺失、备份恢复总账缺失、关键数据存储无备份、不可变或离线副本缺失、恢复演练超期、RTO/RPO 演练失败、备份完整性未校验、勒索隔离不可证明、恢复权限不受控、监管义务总账缺失、强制义务未映射控制、强制义务缺证据、义务 owner 缺失、监管变更超期、义务 POA&M 超期、密码材料总账缺失、未知密钥或秘密未入账、明文存放、弱算法、证书过期、轮换超期、吊销路径缺失、泄露未关闭、签名密钥托管不清、资产分级总账缺失、资产无 owner、数据分类未知、CIA 影响缺失、关键资产低估、L3/L4 与 conformance profile 不一致、AI 风险或互联网暴露未标记、分级复核过期、身份权限总账缺失、生产身份未入账、特权访问无 MFA 或审批、工作负载身份漂移、离职账号仍有效、孤儿账号或过期权限未关闭、处理活动总账缺失、个人数据处理活动未入账、处理活动无 owner、个人数据类别未知、RoPA 与运行资产不一致、隐私权利与同意总账缺失、处理目的无合法基础、同意撤回未传播、权利请求逾期、自动化决策复核缺失、记录留存总账缺失、记录类别无留存排期、legal hold 下允许删除、删除传播缺回执、过期记录未处置、超期留存无目的、拒绝样例不生效、消费锁缺失或浮动引用、迁移工单缺失或无验收证据、迁移执行回执缺失或摘要不一致、远端 ref 不匹配、push 失败、缺少证据包、就绪评分卡未通过、会审裁决缺失或未签署、验证环境未锁定、tag 漂移、控制覆盖不一致 |\n| `baseline -> frozen` | 状态机允许迁移、冻结复核、证据保证等级复核、开放关键发现为 0、就绪评分达到 frozen 阈值、会审裁决同意冻结、例外总账无过期阻断、独立回滚验证和审计导出摘要一致 | 状态机禁止迁移、仍有 critical/high 风险、就绪评分不足、会审反对意见未关闭、证据过期、证据保证等级不足、不可采信主证据未替换、例外过期、阻断例外未关闭、回滚未验证 |\n| `baseline -> emergency-patch` | 事故或安全编号、补丁范围、最小影响分析、补齐证据期限和复盘 owner | 无事故编号、补丁长期化、事后未补 ADR 或复盘 |\n| `baseline/frozen -> quarantined` | `baseline-revocation-record.yaml`、撤销触发、隔离范围、受影响引用、通知确认、恢复目标和风险接受 | 无撤销记录、签名或证据污染未隔离、通知对象未知、恢复目标未验证 |\n| `quarantined -> revoked` | 撤销裁决、生产引用清零、采纳阻断、支持矩阵更新、审计归档和替代基线计划 | 隔离后仍被采用、无替代路径、审计归档缺失或风险接受缺失 |\n| `superseded -> eol` | `baseline-eol-retirement-certificate.yaml`、支持矩阵 EOL 到期、生产引用清零、采纳总账关闭、例外清零和审计证据归档 | 仍有生产引用、未迁移对象无风险接受、EOL 证书缺失、审计归档缺失、新采用未阻断 |\n\n执行规则：\n\n1. `baseline-release-evidence.yaml` 必须追加写入，不得覆盖历史基线证据。\n2. `immutableRefs.sourceCommit`、`releaseTag`、发布事务摘要、准入策略摘要、消费锁摘要、迁移工作单摘要、迁移执行回执摘要、撤销隔离摘要、生命周期状态机摘要、状态对账报告摘要、证据追踪图摘要、证据保证等级摘要、门禁执行报告摘要、门禁负例套件摘要、AI 系统监管分类摘要、EOL 退役证书摘要、会审裁决摘要、架构原则与约束执行总账摘要、服务可靠性与可观测性总账摘要、备份恢复与灾备总账摘要、资产关键性与分类摘要、验证环境锁摘要、基线制品清单摘要、基线就绪评分卡摘要、基线例外总账摘要、审计导出摘要和控制覆盖摘要必须来自同一基线。\n3. `candidate -> baseline` 和 `baseline -> frozen` 前必须消费 `baseline-threat-model-attack-surface-risk-ledger.yaml`，并证明关键威胁模型、攻击面、安全测试和剩余风险摘要进入同一发布证据包。\n4. `candidate -> baseline` 和 `baseline -> frozen` 前必须消费 `baseline-vulnerability-exposure-remediation-ledger.yaml`，并证明 critical/KEV 漏洞、互联网暴露 high 漏洞、扫描覆盖、SLA、复测、VEX/CSAF 状态、例外和风险接受已经闭合。\n5. `candidate -> baseline` 和 `baseline -> frozen` 前必须消费 `baseline-secure-configuration-posture-drift-ledger.yaml`，并证明安全配置基线、CIS/NIST/SCAP/Pod Security 姿态、critical 配置漂移、特权 Pod、公开暴露、弱 TLS、审计日志、配置复测、例外和风险接受已经闭合。\n6. `candidate -> baseline` 和 `baseline -> frozen` 前必须消费 `baseline-production-change-release-ledger.yaml`，并证明生产变更登记、变更窗口、冲突检测、依赖冻结、前置门禁、回滚计划、数据库迁移演练、Feature Flag kill switch、Prompt/模型评估、紧急变更复盘、变更失败恢复和 DORA 指标回写已经闭合。\n7. `candidate -> baseline` 和 `baseline -> frozen` 前必须消费 `baseline-incident-problem-corrective-action-ledger.yaml`，并证明生产事故、安全事件、隐私事件、AI 事件、供应商事件、near miss、重大告警、时间线、RCA、问题记录、纠正行动、复发防止、runbook/告警/门禁反哺、沟通和 DORA 恢复指标已经闭合。\n8. `candidate -> baseline` 和 `baseline -> frozen` 前必须消费 `baseline-data-product-quality-contract-observability-ledger.yaml`，并证明数据产品契约、schema drift、质量断言、freshness、血缘、消费者影响、AI/特征/RAG 使用授权、契约违约、修复复测和数据质量事故已经闭合。\n9. `candidate -> baseline` 和 `baseline -> frozen` 前必须消费 `baseline-engineering-quality-test-release-verification-ledger.yaml`，并证明需求追踪、风险化测试计划、关键测试、覆盖率、flaky 测试、缺陷关闭、修复复测、发布前验证、灰度/冒烟和质量风险接受已经闭合。\n10. `candidate -> baseline` 和 `baseline -> frozen` 前必须消费 `baseline-workforce-competency-training-duty-segregation-ledger.yaml`，并证明关键角色任命、岗位资格、职责确认、培训完成、专项训练、on-call 资格、审批授权、代理授权、职责分离、冲突角色、备份人员和到期复核已经闭合。\n11. `candidate -> baseline` 和 `baseline -> frozen` 前必须消费 `baseline-evidence-assurance-classification.yaml`，并证明 release gate、会审裁决、审计导出和证据追踪图引用的是同一组证据等级、采信状态、完整性证明、新鲜度窗口和可重放要求。\n12. `candidate -> baseline` 和 `baseline -> frozen` 前必须消费 `baseline-gate-negative-test-suite.yaml`，并证明 schema/starter gate、证据新鲜度、证据保证等级、制品清单、审计导出排除、签名/provenance、运行时准入和状态迁移阻断路径都具备负例、故障注入或拒绝日志证据。\n13. `candidate -> baseline` 和 `baseline -> frozen` 前必须消费 `baseline-ai-system-regulatory-impact-ledger.yaml`，并证明 AI 产品、Agent、RAG、微调模型、模型供应商接入和自动化决策流程已经完成适用法规、风险分类、人工监督、日志、技术文档、透明度、后市场监测、供应商责任和合规缺口闭环。\n14. 任意禁推本地资产出现在远端树中，`forbiddenLocalAssetsAbsentFromRemote` 必须为 `false`，并阻断基线晋级。\n15. `frozen` 晋级必须先完成状态对账、漂移复核、基线就绪评分卡、基线会审裁决、证据保证等级复核、门禁负例复测和基线例外总账复核；如果存在状态冲突、关键漂移、评分不足、未关闭反对意见、过期例外、不可采信主证据、坏样例被放行或阻断例外，只能创建 POA&M 或风险接受，不能冻结。\n16. 回滚验证必须指向 `baseline-rollback-verification.yaml`，并证明上一基线 tag、commit、GitOps revision、审计导出和烟测结果有效，不能只写自然语言说明。\n\n可执行验收标准：\n\n1. 任意基线晋级都能找到一份对应的 `baseline-release-evidence.yaml`。\n2. 任意证据包都能证明版本清单、基线准入执行策略、基线运行时准入回执、基线消费锁定文件、基线迁移工作单、基线迁移执行回执、生命周期状态机、状态对账报告、证据追踪图、证据保证等级、门禁执行报告、基线发布事务回执、基线撤销与隔离记录、EOL 退役证书、会审裁决记录、数据产品质量与契约可观测性总账、服务可靠性与可观测性总账、备份恢复与灾备总账、资产关键性与分类总账、验证环境锁、基线制品清单、基线就绪评分卡、基线例外总账、控制覆盖、标准基线和审计导出摘要一致。\n3. 任意冻结基线都能证明开放关键发现为 0、就绪评分达到 frozen 阈值、过期阻断例外为 0，会审反对意见已经关闭，且回滚路径已经验证。\n4. 任意审计人员都能从证据包直接定位 source commit、release tag、验签结果和验证命令。\n5. 任意生产 AI 系统都能从 release gate 反查到 `baseline-ai-system-regulatory-impact-ledger.yaml`、AI 证据账本、DPIA、监管义务总账、风险登记、供应商责任记录和未关闭合规缺口为 0 的裁决证据。\n\n### 10.10.10 基线兼容性总账与消费者迁移闭环\n\n`baseline-compatibility-ledger.yaml` 是版本控制面的消费者影响总账。它不替代单个 API、事件、数据产品或 AI 产品的兼容性报告，而是把这些报告汇总到基线级别，回答“谁会被这次基线影响、何时迁移、到期后如何治理”。\n\n```yaml\nbaselineCompatibilityLedger:\n ledgerId: bcl-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n owner: architecture-governance-board\n change:\n changeLevel: minor\n backwardCompatible: true\n compatibilityWindow: P90D\n deprecationDeadline: 2026-09-02\n impactedContracts:\n - contract: api:order-command:v2\n type: api\n owner: team-order\n compatibilityReport: governance/evidence/compatibility/order-command-api-v2.yaml\n breaking: false\n - contract: event:order-created:v3\n type: event\n owner: team-order\n compatibilityReport: governance/evidence/compatibility/order-created-event-v3.yaml\n breaking: false\n consumers:\n - consumer: customer-service-workbench\n owner: team-support\n impact: sdk-upgrade-required\n currentVersion: order-command:v1\n targetVersion: order-command:v2\n migrationStatus: in-progress\n dueDate: 2026-08-15\n evidence:\n - governance/evidence/compatibility/customer-service-workbench-migration.yaml\n - consumer: revenue-dashboard\n owner: team-revenue-data\n impact: no-change\n currentVersion: order-created:v2\n targetVersion: order-created:v3\n migrationStatus: not-required\n dueDate: null\n unresolved:\n count: 0\n blockers: []\n exceptions:\n allowed: true\n active:\n - id: ex-compat-2026-001\n consumer: legacy-erp-adapter\n expiresAt: 2026-07-15T23:59:59+08:00\n riskAcceptedBy: enterprise-architecture-lead\n poam: governance/evidence/poam/poam-record.yaml\n gateDecision:\n result: pass\n blockingUnmigratedConsumers: 0\n expiredExceptions: 0\n decisionRef: governance/control-plane/release-gate-decision.yaml\n```\n\n兼容状态只能使用以下值：\n\n| 状态 | 含义 | 是否阻断 |\n| ---- | ---- | -------- |\n| `not-impacted` | 已证明不受影响 | 否 |\n| `not-required` | 受影响但无需迁移动作 | 否 |\n| `planned` | 已排期但未开始 | 视到期日而定 |\n| `in-progress` | 正在迁移，有 owner 和证据 | 视到期日而定 |\n| `completed` | 已完成迁移并有验证证据 | 否 |\n| `exception` | 经批准暂缓迁移 | 例外过期后阻断 |\n| `blocked` | 迁移被依赖、预算或技术问题阻塞 | 是 |\n| `unknown` | 无法确认影响或 owner | 是 |\n\n执行规则：\n\n1. `Major`、`Breaking` 和任何带 `compatibilityWindow` 的基线，必须提供 `baseline-compatibility-ledger.yaml`。\n2. 每个受影响契约必须链接对应的 API、事件、数据产品、AI 产品或平台兼容性报告。\n3. 每个生产消费者必须有 owner、当前版本、目标版本、迁移状态、到期日和证据路径。\n4. 到期后仍处于 `planned`、`in-progress`、`blocked` 或 `unknown` 的消费者必须转入例外、POA&M 或风险接受。\n5. `unknown` consumer 不能进入 `baseline` 或 `frozen` 通道；必须先补 catalog、日志、网关、Schema Registry 或数据血缘证据。\n6. 删除旧版本前必须证明生产流量、事件消费、数据血缘或模型调用已经归零，或有签署的风险接受记录。\n\n可执行验收标准：\n\n1. 任意 breaking change 都能从基线级总账追到具体消费者和兼容性报告。\n2. 任意未迁移消费者都有到期时间、owner、例外或 POA&M。\n3. 任意冻结基线都不存在 `unknown` 或过期未处理的消费者迁移状态。\n4. 任意删除旧版本的动作都能证明无生产消费者，或有明确风险接受。\n\n### 10.10.11 基线采纳总账与组织级版本落地\n\n`baseline-adoption-ledger.yaml` 是企业级基线的组织采纳总账。它不证明“基线已经发布”，而是证明“哪些团队、系统、模板、环境和生产资产已经真正采用了这条基线”。\n\n```yaml\nbaselineAdoptionLedger:\n ledgerId: bal-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n owner: architecture-governance-board\n scope:\n requiredBy: 2026-10-01\n appliesTo:\n conformanceProfiles:\n - standard-prod\n - regulated-ai-prod\n gateLevels:\n - L2\n - L3\n - L4\n assetTypes:\n - domain\n - service\n - data-product\n - ai-product\n - platform-golden-path\n - gitops-environment\n summary:\n totalTargets: 4\n adopted: 2\n inProgress: 1\n exceptions: 1\n overdue: 0\n unknown: 0\n targets:\n - target: domain:order\n owner: team-order\n currentBaseline: V2.35\n targetBaseline: V2.53\n conformanceProfile: standard-prod\n gateLevel: L3\n adoptionStatus: in-progress\n dueDate: 2026-08-30\n evidence:\n - domains/order/domain.yaml\n - governance/evidence/conformance/order-domain-baseline-claim.yaml\n - governance/evidence/migrations/baseline-migration-work-order.yaml\n - governance/control-plane/version-governance.yaml\n - governance/evidence/control-assessments/order-domain-v253.yaml\n - target: ai-product:customer-service-agent\n owner: team-support-ai\n currentBaseline: V2.53\n targetBaseline: V2.53\n conformanceProfile: regulated-ai-prod\n gateLevel: L4\n adoptionStatus: adopted\n dueDate: 2026-07-15\n evidence:\n - ai/applications/customer-service-agent/ai-product.yaml\n - governance/evidence/conformance/customer-service-agent-baseline-claim.yaml\n - governance/evidence/ai/customer-service-agent-evidence.yaml\n - governance/control-plane/release-gate-decision.yaml\n - target: platform-golden-path:microservice\n owner: platform-team\n currentBaseline: V2.53\n targetBaseline: V2.53\n conformanceProfile: standard-prod\n gateLevel: L2\n adoptionStatus: adopted\n dueDate: 2026-07-01\n evidence:\n - platform/golden-paths/microservice/template.yaml\n - governance/evidence/conformance/microservice-golden-path-baseline-claim.yaml\n - governance/evidence/platform/microservice-golden-path-v253.yaml\n exceptions:\n active:\n - id: ex-adoption-2026-001\n target: service:legacy-billing-adapter\n reason: strangler migration still active\n expiresAt: 2026-09-15T23:59:59+08:00\n riskAcceptedBy: enterprise-architecture-lead\n poam: governance/evidence/poam/legacy-billing-adapter-poam.yaml\n gateDecision:\n result: conditional-pass\n blockingUnknownTargets: 0\n overdueL3L4Targets: 0\n expiredExceptions: 0\n```\n\n采纳状态只能使用以下值：\n\n| 状态 | 含义 | 是否阻断 |\n| ---- | ---- | -------- |\n| `not-started` | 已识别目标但尚未启动采用 | 视截止日期和等级而定 |\n| `in-progress` | 正在采用，有 owner、截止日期和证据 | 视截止日期和等级而定 |\n| `adopted` | 已采用目标基线并通过对应门禁 | 否 |\n| `exception` | 经批准暂缓采用 | 例外过期后阻断 |\n| `blocked` | 采用被技术、预算、组织或迁移问题阻塞 | 是 |\n| `overdue` | 超过截止日期仍未采用 | 对 L3/L4 阻断 |\n| `unknown` | 无法确认当前基线或 owner | 是 |\n| `not-applicable` | 明确不适用且有理由 | 否 |\n\n执行规则：\n\n1. 企业级 `baseline` 或 `frozen` 发布必须有采纳范围、采纳目标和采用截止日期。\n2. L3 / L4 资产不得以 `unknown`、逾期 `in-progress` 或逾期 `not-started` 状态进入下一轮冻结基线。\n3. 采纳证据必须来自 catalog、control assessment、scorecard、GitOps、模板版本或资产契约，不能只来自会议纪要。\n4. 平台 Golden Path 采用必须证明模板版本、脚手架版本、CI 模板、policy bundle 和开发者门户入口一致。\n5. 逾期目标必须转入例外、POA&M 或风险登记，并声明到期日和关闭条件。\n6. 采纳总账必须进入季度复核；连续两次未采用的 L3/L4 目标必须升级给架构治理委员会。\n7. `currentBaseline` 低于 `targetBaseline` 的 L3 / L4 目标不得直接标记为 `adopted`；必须先完成基线迁移工作单和迁移执行回执、更新消费锁、回写 GitOps / catalog，并绑定验收证据。\n\n可执行验收标准：\n\n1. 任意企业基线都能列出应采用它的领域、平台、数据、AI、GitOps 和生产资产范围。\n2. 任意目标资产都能证明当前基线、目标基线、owner、截止日期、采纳状态和证据路径。\n3. 任意逾期或阻塞采纳都有例外、POA&M 或风险接受。\n4. 任意冻结基线都不存在 L3/L4 资产的 `unknown` 或过期采纳状态。\n5. 任意从旧基线迁移到新基线的 L3/L4 资产都能追溯到完成状态的 `baseline-migration-work-order.yaml`、`baseline-migration-execution-receipt.yaml` 和更新后的 `baseline-consumption-lock.yaml`。\n\n### 10.10.12 基线支持矩阵与版本生命周期收口\n\n`baseline-support-matrix.yaml` 是架构基线的生命周期支持矩阵。它不证明“新基线已经发布”，而是证明“旧基线还是否允许继续使用、还能获得什么类型的维护、何时必须迁移或退役”。\n\n```yaml\nbaselineSupportMatrix:\n matrixId: bsm-20260602-mea-v253\n owner: architecture-governance-board\n currentBaseline: V2.53\n minimumAcceptedBaselines:\n L2: V2.31\n L3: V2.35\n L4: V2.53\n baselines:\n - version: V2.53\n baselineId: mea-v2.53-20260602\n channel: candidate\n supportState: active\n supportFrom: 2026-06-02\n supportUntil: 2026-12-31\n securityPatchUntil: 2027-03-31\n allowedForNewProjects: true\n allowedGateLevels:\n - L2\n - L3\n - L4\n requiredAdoptionLedger: governance/evidence/adoption/baseline-adoption-ledger.yaml\n requiredArtifactInventory: governance/evidence/baselines/baseline-artifact-inventory.yaml\n requiredVerificationLock: governance/evidence/verification/baseline-verification-lock.yaml\n requiredLifecycleStateMachine: governance/evidence/baselines/baseline-lifecycle-state-machine.yaml\n requiredStateReconciliation: governance/evidence/baselines/baseline-state-reconciliation-report.yaml\n requiredReadinessScorecard: governance/evidence/baselines/baseline-readiness-scorecard.yaml\n requiredExceptionLedger: governance/evidence/exceptions/baseline-exception-ledger.yaml\n requiredRollbackVerification: governance/evidence/rollback/baseline-rollback-verification.yaml\n requiredMigrationWorkOrder: governance/evidence/migrations/baseline-migration-work-order.yaml\n requiredMigrationExecutionReceipt: governance/evidence/migrations/baseline-migration-execution-receipt.yaml\n - version: V2.33\n baselineId: mea-v2.33-20260602\n channel: superseded\n supportState: maintenance\n supportFrom: 2026-06-02\n supportUntil: 2026-09-30\n securityPatchUntil: 2026-12-31\n allowedForNewProjects: false\n allowedGateLevels:\n - L2\n migrationTarget: V2.53\n - version: V2.31\n baselineId: mea-v2.31-20260602\n channel: superseded\n supportState: security-only\n supportFrom: 2026-06-02\n supportUntil: 2026-07-31\n securityPatchUntil: 2026-09-30\n allowedForNewProjects: false\n allowedGateLevels:\n - L2\n migrationTarget: V2.53\n exceptions:\n active:\n - id: ex-support-2026-001\n baseline: V2.30\n target: service:legacy-billing-adapter\n reason: strangler migration still active\n expiresAt: 2026-08-15T23:59:59+08:00\n riskAcceptedBy: enterprise-architecture-lead\n poam: governance/evidence/poam/legacy-billing-adapter-poam.yaml\n gates:\n blockNewProjectsOnUnsupportedBaseline: true\n blockL3L4BelowMinimum: true\n requireSecurityPatchForSecurityOnly: true\n blockEolBaselineInReleaseGate: true\n```\n\n支持状态只能使用以下值：\n\n| 状态 | 含义 | 允许变更 |\n| ---- | ---- | -------- |\n| `active` | 当前推荐基线，可用于新项目和升级目标 | 功能、标准、控制项、安全补丁和勘误 |\n| `maintenance` | 仍在维护，但不建议新项目采用 | 兼容性修复、安全补丁、关键勘误 |\n| `security-only` | 只接受安全、合规和关键事故修复 | 安全补丁、监管要求、生产事故补丁 |\n| `frozen` | 冻结为审计、招标或监管口径 | 勘误和紧急安全补丁，禁止语义变更 |\n| `superseded` | 已被新基线替代 | 迁移说明、兼容性说明、风险接受 |\n| `eol` | 生命周期结束 | 不允许继续发布，只允许迁移或退役 |\n\n执行规则：\n\n1. 新项目不得采用 `maintenance`、`security-only`、`superseded` 或 `eol` 基线。\n2. L3 / L4 资产不得低于 `minimumAcceptedBaselines`，除非存在未过期例外、POA&M 和风险接受。\n3. `security-only` 基线只能接受安全、合规和关键事故补丁，不得接收新功能、新标准或新平台能力。\n4. `eol` 基线不能通过发布门禁；运行中资产只能执行迁移、降级、隔离或退役动作。\n5. `frozen` 基线不得直接改核心语义；任何实质变更必须生成新基线并在支持矩阵中声明替代关系。\n6. 支持矩阵必须在每次基线发布、冻结、紧急补丁和季度架构复核前更新。\n\n可执行验收标准：\n\n1. 任意历史基线都能查到支持状态、维护截止、安全补丁截止和迁移目标。\n2. 任意 L3/L4 资产都能证明自己不低于最低可接受基线，或拥有未过期例外。\n3. 任意新项目都不能从门禁中选择不再允许新建的旧基线。\n4. 任意 EOL 基线都不能作为 release gate 的通过条件。\n5. 任意仍允许 L3/L4 迁移到当前基线的支持窗口，都必须能找到对应的迁移工作单模板、迁移执行回执模板和关闭口径。\n\n### 10.10.13 基线发布列车与版本节奏治理\n\n`baseline-release-train.yaml` 是架构基线的发布日历和节奏控制文件。它不替代 `version-governance.yaml`，而是约束“什么时候可以进入候选、什么时候冻结、什么时候晋级、什么时候通知消费者、什么时候只能走紧急补丁”。\n\n```yaml\nbaselineReleaseTrain:\n trainId: brt-2026-q3-enterprise-architecture\n owner: architecture-governance-board\n cadence: quarterly\n timezone: Asia/Shanghai\n currentBaseline: V2.53\n trainWindow:\n proposalCutoff: 2026-06-10\n candidateStart: 2026-06-17\n changeFreezeStart: 2026-06-24\n baselineDecision: 2026-07-01\n adoptionStart: 2026-07-02\n nextTrainOpens: 2026-09-01\n stages:\n - name: proposal\n allowedChangeLevels:\n - minor\n - major\n - breaking\n requiredEvidence:\n - baseline-change-record\n - architecture-decision-record\n - name: candidate\n allowedChangeLevels:\n - editorial\n - minor\n requiredEvidence:\n - version-governance\n - lifecycle-state-machine\n - state-reconciliation-report\n - verification-lock\n - artifact-inventory\n - readiness-scorecard\n - control-coverage\n - compatibility-ledger\n - exception-ledger\n - notification-ledger\n - rollback-verification\n - support-matrix\n - name: freeze\n allowedChangeLevels:\n - editorial\n - emergency-patch\n requiredEvidence:\n - lifecycle-state-machine\n - state-reconciliation-report\n - verification-lock\n - artifact-inventory\n - readiness-scorecard\n - baseline-release-evidence\n - exception-ledger\n - notification-ledger\n - rollback-verification\n - release-gate-decision\n - audit-export-manifest\n - name: baseline\n allowedChangeLevels:\n - emergency-patch\n requiredEvidence:\n - signed-tag\n - signature-receipt\n - adoption-ledger\n plannedBaselines:\n - version: V2.53\n baselineId: mea-v2.53-20260602\n releaseChannel: candidate\n targetChannel: baseline\n sourceCommit: \n releaseTag: architecture/v2.53-candidate\n requiredLedgers:\n - governance/evidence/baselines/baseline-lifecycle-state-machine.yaml\n - governance/evidence/baselines/baseline-state-reconciliation-report.yaml\n - governance/evidence/verification/baseline-verification-lock.yaml\n - governance/evidence/baselines/baseline-artifact-inventory.yaml\n - governance/evidence/baselines/baseline-readiness-scorecard.yaml\n - governance/evidence/compatibility/baseline-compatibility-ledger.yaml\n - governance/evidence/adoption/baseline-adoption-ledger.yaml\n - governance/evidence/support/baseline-support-matrix.yaml\n - governance/evidence/exceptions/baseline-exception-ledger.yaml\n - governance/evidence/communications/baseline-notification-ledger.yaml\n - governance/evidence/rollback/baseline-rollback-verification.yaml\n - governance/evidence/conformance/baseline-conformance-claim.yaml\n - governance/evidence/migrations/baseline-migration-work-order.yaml\n - governance/evidence/migrations/baseline-migration-execution-receipt.yaml\n notification:\n firstNotice: 2026-06-10\n freezeNotice: 2026-06-24\n decisionNotice: 2026-07-01\n channels:\n - architecture-portal\n - platform-developer-portal\n - engineering-leads-mailing-list\n gateDecision: governance/control-plane/release-gate-decision.yaml\n blackoutWindows:\n - from: 2026-06-29T00:00:00+08:00\n to: 2026-07-01T23:59:59+08:00\n reason: baseline-decision-window\n blockNonEmergency: true\n emergencyPatch:\n allowed: true\n requires:\n - incidentId\n - securityOrComplianceJustification\n - minimalScope\n - rollbackPlan\n - postIncidentReviewDueDate\n maxEvidenceBackfillDays: 5\n gates:\n blockOutOfTrainBaseline: true\n blockFreezeWindowSemanticChange: true\n blockBlackoutNonEmergencyChange: true\n requireReadinessScorecardBeforeBaseline: true\n blockBaselineOnReadinessScoreFailure: true\n requireConsumerNoticeBeforeFreeze: true\n requireNotificationLedgerBeforeFreeze: true\n requireExceptionLedgerBeforeFreeze: true\n blockFreezeOnExpiredException: true\n requireRollbackVerificationBeforeBaseline: true\n blockFreezeOnMissingRequiredAck: true\n```\n\n发布列车阶段语义：\n\n| 阶段 | 含义 | 允许动作 |\n| ---- | ---- | -------- |\n| `proposal` | 进入本轮列车的提案收集期 | 新增变更提案、ADR、影响分析和消费者识别 |\n| `candidate` | 候选基线成形期 | 小范围补齐证据、修正示例、修复兼容性差距 |\n| `freeze` | 冻结复核期 | 只允许勘误、门禁修复和紧急补丁，不允许语义扩张 |\n| `baseline` | 正式基线放行期 | 打签名 tag、导出审计包、启动采纳总账 |\n| `emergency-patch` | 安全、合规或生产事故补丁通道 | 最小范围补丁，事后补齐 ADR、复盘和证据 |\n\n执行规则：\n\n1. 企业级基线不得绕过发布列车直接从草案进入 `baseline` 或 `frozen`。\n2. `changeFreezeStart` 之后禁止合入改变语义、职责、门禁或目录真相源的变更，除非走 `emergency-patch`。\n3. 黑窗期间只能发布安全、合规或生产事故补丁；普通优化、文档扩展和新控制项必须进入下一轮列车。\n4. 进入冻结前必须完成消费者通知，生成 `baseline-notification-ledger.yaml`，并确保 `baseline-compatibility-ledger.yaml` 没有 `unknown` 或过期阻塞项。\n5. 进入正式基线前必须完成 `baseline-verification-lock.yaml`、`baseline-artifact-inventory.yaml`、`baseline-readiness-scorecard.yaml`、`baseline-exception-ledger.yaml`、`baseline-notification-ledger.yaml`、`baseline-rollback-verification.yaml`、`baseline-release-evidence.yaml`、`baseline-support-matrix.yaml`、审计导出和签名验签回执。\n6. 紧急补丁必须在 `maxEvidenceBackfillDays` 内补齐复盘、ADR 或基线变更记录，不能成为长期发布通道。\n7. 发布列车进入 adoption start 后，目标资产迁移必须由 `baseline-migration-work-order.yaml` 驱动，并由 `baseline-migration-execution-receipt.yaml` 证明实际执行；不得只在采纳总账中手工改状态。\n\n可执行验收标准：\n\n1. 任意企业基线都能追溯到所属发布列车、候选窗口、冻结窗口和晋级日期。\n2. 任意冻结期后的语义变更都有紧急补丁理由、事故编号、回滚计划和补证截止。\n3. 任意黑窗内的变更都能证明是安全、合规或生产事故补丁。\n4. 任意消费者都能证明在冻结前收到通知、完成影响确认，或有明确的例外和风险接受记录。\n5. 任意正式基线都能证明上一基线可检出、GitOps revision 可恢复、审计导出可回放并通过最小烟测。\n6. 任意本轮列车要求迁移的 L3/L4 资产都能定位迁移工作单、迁移执行回执、消费锁更新和 GitOps 指针变更证据。\n\n### 10.10.14 资产级基线符合性声明\n\n`baseline-conformance-claim.yaml` 是单个资产对企业架构基线的自声明。它不替代组织级 `baseline-adoption-ledger.yaml`，而是让采纳总账有资产侧证据来源，避免中央台账靠人工手填。\n\n```yaml\nbaselineConformanceClaim:\n claimId: bcc-20260602-order-command-service-v253\n asset:\n id: service:order-command-service\n type: service\n domain: order\n owner: team-order\n sourceRoot: domains/order/services/order-command-service\n catalogRef: catalog/components/order-command-service.yaml\n claimedBaseline:\n version: V2.53\n baselineId: mea-v2.53-20260602\n sourceCommit: \n releaseTag: architecture/v2.53-candidate\n consumptionLock: governance/evidence/conformance/baseline-consumption-lock.yaml\n migrationWorkOrder: governance/evidence/migrations/baseline-migration-work-order.yaml\n migrationExecutionReceipt: governance/evidence/migrations/baseline-migration-execution-receipt.yaml\n releaseTrain: governance/evidence/release-trains/baseline-release-train.yaml\n supportMatrix: governance/evidence/support/baseline-support-matrix.yaml\n lifecycleStateMachine: governance/evidence/baselines/baseline-lifecycle-state-machine.yaml\n stateReconciliation: governance/evidence/baselines/baseline-state-reconciliation-report.yaml\n artifactInventory: governance/evidence/baselines/baseline-artifact-inventory.yaml\n evidenceTraceGraphDigest: sha256:\n artifactInventoryDigest: sha256:\n enforcementPolicyDigest: sha256:\n verificationLock: governance/evidence/verification/baseline-verification-lock.yaml\n readinessScorecard: governance/evidence/baselines/baseline-readiness-scorecard.yaml\n exceptionLedger: governance/evidence/exceptions/baseline-exception-ledger.yaml\n rollbackVerification: governance/evidence/rollback/baseline-rollback-verification.yaml\n conformance:\n profile: standard-prod\n gateLevel: L3\n claimStatus: conformant\n claimedAt: 2026-07-02T10:00:00+08:00\n expiresAt: 2026-10-02T23:59:59+08:00\n signedBy:\n - team-order-tech-lead\n - platform-governance-reviewer\n evidence:\n contracts:\n - domains/order/services/order-command-service/service.yaml\n - contracts/apis/order-command.openapi.yaml\n - contracts/events/order-created.asyncapi.yaml\n runtime:\n - infra/gitops/environments/prod/order/order-command-service/kustomization.yaml\n - governance/evidence/drift/order-command-service-drift.yaml\n controls:\n - governance/evidence/control-assessments/order-command-service-v253.yaml\n - governance/control-plane/release-gate-decision.yaml\n supplyChain:\n - governance/evidence/supply-chain/order-command-service-attestation.yaml\n exceptions:\n active: []\n rollup:\n adoptionLedger: governance/evidence/adoption/baseline-adoption-ledger.yaml\n rollupStatus: included\n lastReconciledAt: 2026-07-02T11:00:00+08:00\n```\n\n声明状态只能使用以下值：\n\n| 状态 | 含义 | 是否计入采纳 |\n| ---- | ---- | ------------ |\n| `conformant` | 资产已经满足声明基线和门禁等级 | 是 |\n| `conditional` | 资产有未关闭例外，但已被风险接受 | 条件计入 |\n| `non-conformant` | 资产未满足声明基线或关键证据缺失 | 否 |\n| `expired` | 声明过期，必须重新评估 | 否 |\n| `not-applicable` | 资产明确不适用该基线，且有理由 | 不计入分母 |\n\n执行规则：\n\n1. L3 / L4 资产不得只出现在采纳总账中，必须有资产侧 `baseline-conformance-claim.yaml`。\n2. 符合性声明必须绑定 `baselineId`、`sourceCommit`、`releaseTag`、`baseline-consumption-lock.yaml`、`releaseTrain`、`supportMatrix`、catalog 指针和证据路径。\n3. `claimStatus=conformant` 时不得存在过期例外、缺失控制评估或低于最低可接受基线的版本。\n4. `claimStatus=conditional` 必须引用未过期例外、POA&M 或风险接受记录，并声明关闭日期。\n5. 声明过期后不得继续在 `baseline-adoption-ledger.yaml` 中计为 `adopted`。\n6. 采纳总账必须能从每个目标资产回查到对应的符合性声明和消费锁，符合性声明也必须能回写自己的 rollup 状态。\n7. 如果资产从旧基线迁移到声明基线，符合性声明必须引用完成状态的迁移工作单；否则不得声明为 `conformant`。\n\n可执行验收标准：\n\n1. 任意 L3/L4 资产都能找到一份未过期的基线符合性声明和本地消费锁。\n2. 任意采纳总账中的 `adopted` 目标都能追溯到资产侧 `conformant` 声明。\n3. 任意 `conditional` 声明都有例外、POA&M 或风险接受，并有关闭日期。\n4. 任意低于支持矩阵最低可接受基线的资产都不能声明为 `conformant`。\n5. 任意只声明 `V2.x` 但没有锁定 source commit、release tag 和关键证据摘要的资产，都不能声明为 `conformant`。\n6. 任意迁移资产都能证明迁移工作单、消费锁、GitOps overlay 和 catalog runtime 指针引用的是同一目标基线。\n\n### 10.10.15 基线制品清单与可复现冻结\n\n`baseline-artifact-inventory.yaml` 是企业架构基线的源制品物料清单。它不替代 `audit-export-manifest.yaml`，而是先回答“这一版基线由哪些源文件和模板构成”；审计导出清单再回答“这些源制品被导出了哪些交付包”。\n\n```yaml\nbaselineArtifactInventory:\n inventoryId: bai-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n owner: architecture-governance-board\n sourceCommit: \n releaseTag: architecture/v2.53-candidate\n generatedAt: 2026-06-02T12:00:00+08:00\n digestAlgorithm: sha256\n scope:\n requiredArtifactTypes:\n - document\n - schema\n - example\n - control\n - evidence-template\n - validation-command\n - generated-output\n - external-reference\n excludePatterns:\n - build/**\n - .git/**\n - assets/templates/modern-enterprise-architecture-private/kit/**\n - assets/templates/modern-enterprise-architecture-private/controls.json\n - assets/templates/modern-enterprise-architecture-private/version.json\n localPrivateArtifactBoundary: governance/evidence/baselines/baseline-local-artifact-boundary.yaml\n auditExportExclusionManifest: governance/evidence/audit-export/audit-export-exclusion-manifest.yaml\n privateArtifactEscrowManifest: governance/evidence/baselines/private-artifact-escrow-manifest.yaml\n cleanRoomReconstructionReceipt: governance/evidence/baselines/baseline-clean-room-reconstruction-receipt.yaml\n evidenceArchiveReceipt: governance/evidence/baselines/baseline-evidence-archive-receipt.yaml\n signatureLtvReceipt: governance/evidence/baselines/baseline-signature-ltv-receipt.yaml\n runtimeAdmissionReceipt: governance/evidence/baselines/baseline-runtime-admission-receipt.yaml\n continuousControlMonitoringLedger: governance/evidence/baselines/baseline-continuous-control-monitoring-ledger.yaml\n controlAssuranceSamplingLedger: governance/evidence/baselines/baseline-control-assurance-sampling-ledger.yaml\n controlInheritanceLedger: governance/evidence/baselines/baseline-control-inheritance-ledger.yaml\n dataResidencyTransferLedger: governance/evidence/baselines/baseline-data-residency-transfer-ledger.yaml\n thirdPartyRiskLedger: governance/evidence/baselines/baseline-third-party-risk-ledger.yaml\n operationalResilienceLedger: governance/evidence/baselines/baseline-operational-resilience-ledger.yaml\n threatModelAttackSurfaceRiskLedger: governance/evidence/baselines/baseline-threat-model-attack-surface-risk-ledger.yaml\n vulnerabilityExposureRemediationLedger: governance/evidence/baselines/baseline-vulnerability-exposure-remediation-ledger.yaml\n secureConfigurationPostureDriftLedger: governance/evidence/baselines/baseline-secure-configuration-posture-drift-ledger.yaml\n productionChangeReleaseLedger: governance/evidence/baselines/baseline-production-change-release-ledger.yaml\n incidentProblemCorrectiveActionLedger: governance/evidence/baselines/baseline-incident-problem-corrective-action-ledger.yaml\n dataProductQualityContractObservabilityLedger: governance/evidence/baselines/baseline-data-product-quality-contract-observability-ledger.yaml\n engineeringQualityTestReleaseVerificationLedger: governance/evidence/baselines/baseline-engineering-quality-test-release-verification-ledger.yaml\n workforceCompetencyTrainingDutySegregationLedger: governance/evidence/baselines/baseline-workforce-competency-training-duty-segregation-ledger.yaml\n businessOutcomeValueRealizationPortfolioLedger: governance/evidence/baselines/baseline-business-outcome-value-realization-portfolio-ledger.yaml\n valueStreamJourneyProcessLedger: governance/evidence/baselines/baseline-value-stream-journey-process-ledger.yaml\n architectureViewRuntimeTopologyDependencyLedger: governance/evidence/baselines/baseline-architecture-view-runtime-topology-dependency-ledger.yaml\n qualityAttributeArchitectureDriverTradeoffLedger: governance/evidence/baselines/baseline-quality-attribute-architecture-driver-tradeoff-ledger.yaml\n architecturePrincipleConstraintExceptionLedger: governance/evidence/baselines/baseline-architecture-principle-constraint-exception-ledger.yaml\n capacityPerformanceCostEfficiencyLedger: governance/evidence/baselines/baseline-capacity-performance-cost-efficiency-ledger.yaml\n serviceReliabilitySloErrorBudgetObservabilityLedger: governance/evidence/baselines/baseline-service-reliability-slo-error-budget-observability-ledger.yaml\n regulatoryObligationLedger: governance/evidence/baselines/baseline-regulatory-obligation-ledger.yaml\n backupRestoreDisasterRecoveryLedger: governance/evidence/baselines/baseline-backup-restore-disaster-recovery-ledger.yaml\n cryptographicSecretsKeyCertificateLedger: governance/evidence/baselines/baseline-cryptographic-secrets-key-certificate-ledger.yaml\n assetCriticalityClassificationLedger: governance/evidence/baselines/baseline-asset-criticality-classification-ledger.yaml\n identityEntitlementAccessLedger: governance/evidence/baselines/baseline-identity-entitlement-access-ledger.yaml\n processingActivityInventoryLedger: governance/evidence/baselines/baseline-processing-activity-inventory-ledger.yaml\n privacyRightsConsentLedger: governance/evidence/baselines/baseline-privacy-rights-consent-ledger.yaml\n recordsRetentionLegalHoldLedger: governance/evidence/baselines/baseline-records-retention-legal-hold-ledger.yaml\n artifacts:\n - path: .github/docs/gongfa/modern-enterprise-architecture-template.md\n type: document\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.md\n - path: governance/evidence/baselines/baseline-local-artifact-boundary.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/audit-export/audit-export-exclusion-manifest.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/private-artifact-escrow-manifest.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-clean-room-reconstruction-receipt.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-evidence-archive-receipt.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-signature-ltv-receipt.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-runtime-admission-receipt.yaml\n type: evidence-template\n required: true\n owner: governance-platform\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-runtime-admission-decision-ledger.yaml\n type: evidence-template\n required: true\n owner: governance-platform\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-continuous-control-monitoring-ledger.yaml\n type: evidence-template\n required: true\n owner: governance-platform\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-control-assurance-sampling-ledger.yaml\n type: evidence-template\n required: true\n owner: independent-assurance-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-control-inheritance-ledger.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-data-residency-transfer-ledger.yaml\n type: evidence-template\n required: true\n owner: privacy-governance-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-third-party-risk-ledger.yaml\n type: evidence-template\n required: true\n owner: third-party-risk-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-operational-resilience-ledger.yaml\n type: evidence-template\n required: true\n owner: operational-resilience-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-threat-model-attack-surface-risk-ledger.yaml\n type: evidence-template\n required: true\n owner: application-security-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-vulnerability-exposure-remediation-ledger.yaml\n type: evidence-template\n required: true\n owner: security-vulnerability-management-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-secure-configuration-posture-drift-ledger.yaml\n type: evidence-template\n required: true\n owner: platform-security-posture-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-production-change-release-ledger.yaml\n type: evidence-template\n required: true\n owner: release-engineering\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-incident-problem-corrective-action-ledger.yaml\n type: evidence-template\n required: true\n owner: sre-platform-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-data-product-quality-contract-observability-ledger.yaml\n type: evidence-template\n required: true\n owner: data-platform-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-engineering-quality-test-release-verification-ledger.yaml\n type: evidence-template\n required: true\n owner: quality-engineering-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-workforce-competency-training-duty-segregation-ledger.yaml\n type: evidence-template\n required: true\n owner: people-operations-governance-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-business-outcome-value-realization-portfolio-ledger.yaml\n type: evidence-template\n required: true\n owner: portfolio-governance-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-value-stream-journey-process-ledger.yaml\n type: evidence-template\n required: true\n owner: business-architecture-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-architecture-view-runtime-topology-dependency-ledger.yaml\n type: evidence-template\n required: true\n owner: enterprise-architecture-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-quality-attribute-architecture-driver-tradeoff-ledger.yaml\n type: evidence-template\n required: true\n owner: enterprise-architecture-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-architecture-principle-constraint-exception-ledger.yaml\n type: evidence-template\n required: true\n owner: enterprise-architecture-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-version-policy-release-control-ledger.yaml\n type: evidence-template\n required: true\n owner: release-engineering\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-capacity-performance-cost-efficiency-ledger.yaml\n type: evidence-template\n required: true\n owner: sre-finops-platform-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-service-reliability-slo-error-budget-observability-ledger.yaml\n type: evidence-template\n required: true\n owner: sre-platform-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-backup-restore-disaster-recovery-ledger.yaml\n type: evidence-template\n required: true\n owner: sre-platform-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-regulatory-obligation-ledger.yaml\n type: evidence-template\n required: true\n owner: compliance-governance-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-cryptographic-secrets-key-certificate-ledger.yaml\n type: evidence-template\n required: true\n owner: security-cryptography-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-asset-criticality-classification-ledger.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-identity-entitlement-access-ledger.yaml\n type: evidence-template\n required: true\n owner: security-identity-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-processing-activity-inventory-ledger.yaml\n type: evidence-template\n required: true\n owner: privacy-governance-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-privacy-rights-consent-ledger.yaml\n type: evidence-template\n required: true\n owner: privacy-governance-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-records-retention-legal-hold-ledger.yaml\n type: evidence-template\n required: true\n owner: records-governance-team\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/control-plane/version-governance.yaml\n type: control\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-lifecycle-state-machine.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-state-reconciliation-report.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/verification/baseline-verification-lock.yaml\n type: control\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/rollback/baseline-rollback-verification.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/baselines/baseline-readiness-scorecard.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/exceptions/baseline-exception-ledger.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/conformance/baseline-conformance-claim.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/migrations/baseline-migration-work-order.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n - path: governance/evidence/migrations/baseline-migration-execution-receipt.yaml\n type: evidence-template\n required: true\n owner: architecture-governance-board\n digest: sha256:\n signed: true\n exportedTo:\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n generatedOutputs:\n - path: assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n digest: sha256:\n generatedBy: internal-command://architecture/export-modern-architecture-audit\n sourceArtifacts:\n - .github/docs/gongfa/modern-enterprise-architecture-template.md\n - governance/control-plane/version-governance.yaml\n externalReferences:\n - name: SLSA v1.2\n lockedVersion: v1.2\n adoptionLevel: enforce\n referenceDigest: sha256:\n gates:\n requiredArtifactsPresent: true\n artifactDigestsMatchGitTree: true\n noUndeclaredRequiredArtifacts: true\n localPrivateArtifactBoundaryDeclared: true\n auditExportExclusionManifestDeclared: true\n privateArtifactEscrowManifestDeclared: true\n cleanRoomReconstructionReceiptDeclared: true\n evidenceArchiveReceiptDeclared: true\n signatureLtvReceiptDeclared: true\n runtimeAdmissionReceiptDeclared: true\n runtimeAdmissionDecisionLedgerDeclared: true\n continuousControlMonitoringLedgerDeclared: true\n controlAssuranceSamplingLedgerDeclared: true\n controlInheritanceLedgerDeclared: true\n dataResidencyTransferLedgerDeclared: true\n thirdPartyRiskLedgerDeclared: true\n operationalResilienceLedgerDeclared: true\n dataProductQualityContractObservabilityLedgerDeclared: true\n serviceReliabilitySloErrorBudgetObservabilityLedgerDeclared: true\n businessOutcomeValueRealizationPortfolioLedgerDeclared: true\n valueStreamJourneyProcessLedgerDeclared: true\n architectureViewRuntimeTopologyDependencyLedgerDeclared: true\n qualityAttributeArchitectureDriverTradeoffLedgerDeclared: true\n architecturePrincipleConstraintExceptionLedgerDeclared: true\n versionPolicyReleaseControlLedgerDeclared: true\n regulatoryObligationLedgerDeclared: true\n cryptographicSecretsKeyCertificateLedgerDeclared: true\n assetCriticalityClassificationLedgerDeclared: true\n identityEntitlementAccessLedgerDeclared: true\n processingActivityInventoryLedgerDeclared: true\n privacyRightsConsentLedgerDeclared: true\n recordsRetentionLegalHoldLedgerDeclared: true\n generatedOutputsMatchSources: true\n signaturesVerified: true\n```\n\n制品类型只能使用以下值：\n\n| 类型 | 含义 | 典型位置 |\n| ---- | ---- | -------- |\n| `document` | 人类可读基线正文和索引 | `docs/` |\n| `schema` | 机器可读契约约束 | starter kit schema |\n| `example` | 可执行或可校验示例 | starter kit example |\n| `control` | 控制面、控制覆盖或门禁决策 | `governance/control-plane/` |\n| `evidence-template` | 审计、评估、例外、采纳、符合性或发布证据模板 | `governance/evidence/` |\n| `validation-command` | 生成或校验基线的命令声明 | Makefile、脚本、runbook |\n| `generated-output` | 由命令生成的审计导出或完整性输出 | `build/` |\n| `external-reference` | 锁定版本的外部标准或参考资料快照 | 标准基线、ADR、引用清单 |\n\n执行规则：\n\n1. 企业级 `baseline`、`frozen` 和正式审计导出必须有基线制品清单。\n2. 清单必须绑定 `baselineId`、`sourceCommit`、`releaseTag`、摘要算法和生成时间。\n3. 所有必需源制品必须有路径、类型、owner、摘要、必需性和导出关系。\n4. `required=true` 制品缺失、摘要漂移或 owner 缺失时，不得晋级到 `baseline` 或 `frozen`。\n5. 未登记但被审计导出引用的源制品必须阻断导出，除非明确列入允许的 exclude pattern。\n6. 本地禁推资产可以存在于 exclude pattern，但必须先进入 `baseline-local-artifact-boundary.yaml`、`audit-export-exclusion-manifest.yaml`、`private-artifact-escrow-manifest.yaml`、`baseline-clean-room-reconstruction-receipt.yaml` 和 `baseline-evidence-archive-receipt.yaml`，并不得进入远端树、源制品清单、审计导出包或签名 payload。\n7. 生成物必须能反向追溯到源制品集合；源制品变更后必须重新生成导出包、完整性清单和签名策略。\n8. 基线迁移工作单和迁移执行回执属于必需证据模板；被采纳总账引用但未进入制品清单时，基线不得晋级。\n9. 任意 exclude pattern 都必须能从本地私有制品边界反查到 owner、禁推原因、摘要策略、允许用途和验证命令。\n10. 任意导出包必须能从审计导出排除清单反查到原文白名单、摘要留存项、强制排除项和签名 payload 排除项。\n11. 任意本地私有制品都必须能从私有制品托管交接清单反查到私有库引用、访问角色、留存策略、取回命令、恢复验证和摘要一致性。\n12. 基线运行时准入回执属于必需证据模板；缺失时不能证明发布准入已经进入生产 API 入口，基线不得晋级。\n13. 基线运行时准入决策总账属于必需证据模板；缺失时不能证明 allow/deny 决策有逐条原始证据，基线不得晋级。\n14. 基线连续控制监测总账属于必需证据模板；缺失时不能证明发布后的关键控制持续生效，基线不得晋级或冻结。\n15. 基线独立控制保证抽样总账属于必需证据模板；缺失时不能证明关键控制已经被独立抽样复核，基线不得晋级或冻结。\n16. 基线共享责任与继承控制总账属于必需证据模板；缺失时不能证明公共控制、继承控制和消费者义务有明确责任边界，基线不得晋级或冻结。\n17. 基线数据驻留与跨境处理总账属于必需证据模板；缺失时不能证明数据实际处理位置、跨境传输机制、子处理方和补充保护措施符合基线，基线不得晋级或冻结。\n18. 基线第三方与关键供应商风险总账属于必需证据模板；缺失时不能证明关键供应商合同、审计权、保证报告、集中度、退出计划和连续性符合基线，基线不得晋级或冻结。\n19. 基线运营韧性与重要业务服务影响容忍总账属于必需证据模板；缺失时不能证明重要业务服务、影响容忍、BIA、依赖映射、场景测试和超限升级符合基线，基线不得晋级或冻结。\n20. 基线容量、性能、弹性伸缩与成本效率总账属于必需证据模板；缺失时不能证明容量预测、压测、性能基准、资源 requests/limits、HPA/VPA/KEDA、预算、单位经济、成本分摊、异常成本和优化行动符合基线，基线不得晋级或冻结。\n21. 基线服务可靠性、SLO、错误预算与可观测性总账属于必需证据模板；缺失时不能证明关键服务、用户旅程、SLI/SLO、错误预算、告警、on-call、runbook、合成探测、遥测覆盖和降级策略符合基线，基线不得晋级或冻结。\n22. 基线备份、恢复、灾备与可恢复性验证总账属于必需证据模板；缺失时不能证明关键系统、关键数据存储、备份策略、不可变/离线副本、跨区域隔离、恢复演练、RTO/RPO、完整性校验和勒索隔离符合基线，基线不得晋级或冻结。\n23. 基线监管与合规义务可追溯总账属于必需证据模板；缺失时不能证明适用义务、控制目标、证据路径、owner、监管变更和 POA&M 符合基线，基线不得晋级或冻结。\n24. 基线密码材料、密钥、证书与秘密生命周期总账属于必需证据模板；缺失时不能证明 KMS/HSM key、TLS 证书、签名密钥、API token、数据库凭据、webhook secret、工作负载密钥、轮换、过期、吊销、泄露响应和访问边界符合基线，基线不得晋级或冻结。\n25. 基线资产关键性、数据分类与风险分级总账属于必需证据模板；缺失时不能证明资产 owner、业务关键性、SLO Tier、L3/L4、CIA 影响、数据敏感度、AI 风险、互联网暴露和复核状态符合基线，基线不得晋级或冻结。\n26. 基线身份权限、特权访问与工作负载身份总账属于必需证据模板；缺失时不能证明人类身份、服务账号、工作负载身份、特权访问、JML、MFA、PAM/JIT、break-glass、孤儿账号和过期权限符合基线，基线不得晋级或冻结。\n27. 基线处理活动、个人数据清单与 RoPA 覆盖总账属于必需证据模板；缺失时不能证明处理活动、个人数据类别、主体类别、接收方、跨境传输、保留映射、DPIA 和合法基础覆盖完整，基线不得晋级或冻结。\n28. 基线隐私权利请求、同意偏好与合法基础执行总账属于必需证据模板；缺失时不能证明处理目的、合法基础、同意撤回传播、主体权利请求 SLA、自动化决策复核和第三方下游处理限制符合基线，基线不得晋级或冻结。\n29. 基线记录留存、法律保全与可防御删除总账属于必需证据模板；缺失时不能证明记录类别、留存排期、legal hold、删除资格、删除传播和可防御删除回执符合基线，基线不得晋级或冻结。\n30. 基线业务结果、价值实现与组合收益总账属于必需证据模板；缺失时不能证明业务目标、价值假设、收益 owner、关键结果、采用证据、收益实现、成本效率和组合决策符合基线，基线不得晋级或冻结。\n31. 基线价值流、关键旅程与端到端流程总账属于必需证据模板；缺失时不能证明跨域流程 owner、BPMN/流程模型、步骤级遥测、跨域交接、瓶颈、异常、人工兜底、控制点和改进动作符合基线，基线不得晋级或冻结。\n32. 基线架构视图、运行拓扑与依赖影响总账属于必需证据模板；缺失时不能证明架构视图、运行拓扑、声明依赖、观测依赖、GitOps 拓扑、关键路径、blast radius、变更影响和依赖漂移符合基线，基线不得晋级或冻结。\n33. 基线质量属性、架构驱动与权衡决策总账属于必需证据模板；缺失时不能证明业务驱动、质量属性场景、响应指标、敏感点、权衡点、ADR、适配度函数和验证证据符合基线，基线不得晋级或冻结。\n34. 基线架构原则、约束、反模式与例外执行总账属于必需证据模板；缺失时不能证明强制架构原则、约束、禁止项、反模式、检测规则、门禁入口、违反处置、例外审批、风险接受和复核闭环符合基线，基线不得晋级或冻结。\n35. 基线版本策略、发布通道、兼容性与冻结控制总账属于必需证据模板；缺失时不能证明版本号语义、发布通道、签名 tag、兼容窗口、消费锁、迁移窗口、冻结规则、紧急补丁、撤销和 EOL 阻断符合基线，基线不得晋级或冻结。\n\nV2.96 补充规则：`baseline-evidence-assurance-classification.yaml` 属于必需证据模板。缺失时不能证明证据追踪图、release gate、会审裁决、审计导出和控制评估使用了同一组证据保证等级、采信状态、完整性证明、新鲜度窗口和可重放要求，基线不得晋级或冻结。\n\nV2.97 补充规则：`baseline-gate-negative-test-suite.yaml` 属于必需证据模板。缺失时不能证明 release gate、starter gate、审计导出、运行时准入和状态迁移阻断规则会在坏样例、过期证据、摘要漂移、签名缺失、例外过期、私有资产误入和证据保证等级不足时 fail-closed，基线不得晋级或冻结。\n\nV2.98 补充规则：`baseline-ai-system-regulatory-impact-ledger.yaml` 属于必需证据模板。缺失时不能证明 AI 产品、Agent、RAG、微调模型、模型供应商接入和自动化决策流程已经完成适用法规、风险分类、禁止/高风险/通用目的 AI 判断、人工监督、日志留存、技术文档、透明度、后市场监测、供应商责任和合规缺口闭环，基线不得晋级或冻结。\n\n可执行验收标准：\n\n1. 任意基线都能列出本次发布包含的源文档、schema、示例、控制项、证据模板、脚本、生成物和外部引用。\n2. 任意审计导出包都能从生成物摘要反查到源制品摘要和生成命令。\n3. 任意必需制品摘要漂移、缺失或未签名时，基线晋级会被阻断。\n4. 任意本地禁推资产都能证明不在远端树、不在基线制品清单、不在导出包、不在签名 payload。\n5. 任意迁移工作单和迁移执行回执都能从制品清单反查到摘要、签名状态和审计导出关系。\n6. 任意本地私有制品都能从制品清单的 exclude pattern 反查到 `baseline-local-artifact-boundary.yaml` 中的受控边界声明。\n7. 任意审计导出生成物都能从制品清单反查到 `audit-export-exclusion-manifest.yaml`，证明排除策略已经进入源证据。\n8. 任意本地私有制品都能从制品清单反查到 `private-artifact-escrow-manifest.yaml`，证明它不是只有本地副本，而是已经进入企业私有托管和恢复流程。\n9. 任意生产基线都能从制品清单反查到 `baseline-runtime-admission-receipt.yaml`，证明运行入口阻断证据已经成为基线源制品。\n10. 任意生产基线都能从制品清单反查到 `baseline-runtime-admission-decision-ledger.yaml`，证明每条运行时准入决策都有可审计的原始日志摘要。\n11. 任意生产基线都能从制品清单反查到 `baseline-continuous-control-monitoring-ledger.yaml`，证明关键控制发布后仍在被监测、告警和处置。\n12. 任意生产基线都能从制品清单反查到 `baseline-control-assurance-sampling-ledger.yaml`，证明关键控制已经由独立评估人按样本完成设计有效性和运行有效性复核。\n13. 任意生产基线都能从制品清单反查到 `baseline-control-inheritance-ledger.yaml`，证明平台公共控制、云/第三方继承控制、领域责任和消费者义务不会互相覆盖。\n14. 任意生产基线都能从制品清单反查到 `baseline-data-residency-transfer-ledger.yaml`，证明数据驻留、跨境处理、子处理方和模型供应商区域不会旁路隐私影响评估和数据契约。\n15. 任意生产基线都能从制品清单反查到 `baseline-third-party-risk-ledger.yaml`，证明关键供应商、ICT 服务商、SaaS、云平台、模型供应商、外包方和子处理方具备合同、审计权、保证报告、退出计划、集中度和连续性证据。\n16. 任意生产基线都能从制品清单反查到 `baseline-operational-resilience-ledger.yaml`，证明重要业务服务、影响容忍、BIA、端到端依赖、场景测试、恢复能力、沟通计划和超限升级证据已经闭合。\n17. 任意生产基线都能从制品清单反查到 `baseline-service-reliability-slo-error-budget-observability-ledger.yaml`，证明生产服务、关键用户旅程、SLI/SLO、错误预算、告警、on-call、runbook、合成探测、日志/指标/链路覆盖、降级策略和事故反馈已经闭合。\n18. 任意生产基线都能从制品清单反查到 `baseline-backup-restore-disaster-recovery-ledger.yaml`，证明关键系统、关键数据存储、备份策略、不可变/离线副本、跨区域隔离、恢复演练、RTO/RPO、完整性校验、勒索隔离和恢复权限证据已经闭合。\n19. 任意生产基线都能从制品清单反查到 `baseline-regulatory-obligation-ledger.yaml`，证明适用义务、控制目标、控制项、证据路径、owner、监管变更和 POA&M 已经闭合。\n20. 任意生产基线都能从制品清单反查到 `baseline-cryptographic-secrets-key-certificate-ledger.yaml`，证明 KMS/HSM key、TLS 证书、签名密钥、API token、数据库凭据、webhook secret、工作负载密钥、轮换、过期、吊销、泄露响应和访问边界证据已经闭合。\n21. 任意生产基线都能从制品清单反查到 `baseline-asset-criticality-classification-ledger.yaml`，证明资产 owner、业务关键性、SLO Tier、L3/L4、CIA 影响、数据敏感度、AI 风险、互联网暴露和复核状态证据已经闭合。\n22. 任意生产基线都能从制品清单反查到 `baseline-identity-entitlement-access-ledger.yaml`，证明人类身份、服务账号、工作负载身份、特权访问、JML、MFA、PAM/JIT、break-glass、孤儿账号、过期权限和运行时身份绑定证据已经闭合。\n23. 任意生产基线都能从制品清单反查到 `baseline-processing-activity-inventory-ledger.yaml`，证明个人数据处理活动、数据主体类别、个人数据类别、接收方、跨境传输、保留映射、DPIA、合法基础和发现覆盖证据已经闭合。\n24. 任意生产基线都能从制品清单反查到 `baseline-privacy-rights-consent-ledger.yaml`，证明处理目的、合法基础、同意偏好、撤回传播、权利请求履约、自动化决策复核和下游处理阻断证据已经闭合。\n25. 任意生产基线都能从制品清单反查到 `baseline-records-retention-legal-hold-ledger.yaml`，证明记录类别、留存排期、legal hold、删除资格、删除传播和可防御删除回执证据已经闭合。\n26. 任意生产基线都能从制品清单反查到 `baseline-business-outcome-value-realization-portfolio-ledger.yaml`，证明业务目标、价值假设、收益 owner、关键结果、采用证据、收益实现、成本效率和停投/加投决策证据已经闭合。\n27. 任意生产基线都能从制品清单反查到 `baseline-value-stream-journey-process-ledger.yaml`，证明价值流、关键旅程、端到端流程、步骤遥测、跨域交接、瓶颈、异常和人工兜底证据已经闭合。\n28. 任意生产基线都能从制品清单反查到 `baseline-architecture-view-runtime-topology-dependency-ledger.yaml`，证明架构视图、运行拓扑、声明依赖、观测依赖、GitOps 拓扑、blast radius、变更影响和依赖漂移证据已经闭合。\n29. 任意生产基线都能从制品清单反查到 `baseline-quality-attribute-architecture-driver-tradeoff-ledger.yaml`，证明质量属性场景、架构驱动、敏感点、权衡点、ADR、适配度函数和验证证据已经闭合。\n30. 任意生产基线都能从制品清单反查到 `baseline-architecture-principle-constraint-exception-ledger.yaml`，证明强制架构原则、约束、禁止项、反模式、检测规则、门禁入口、违反处置、例外审批、风险接受和复核周期已经闭合。\n31. 任意生产基线都能从制品清单反查到 `baseline-version-policy-release-control-ledger.yaml`，证明版本号语义、发布通道、签名 tag、兼容窗口、消费锁、迁移窗口、冻结规则、紧急补丁、撤销和 EOL 阻断已经闭合。\n32. 任意生产基线都能从制品清单反查到 `baseline-evidence-assurance-classification.yaml`，证明关键证据节点的保证等级、采信状态、独立性、完整性、新鲜度和重放要求已经进入 release gate、会审裁决和审计导出。\n33. 任意生产基线都能从制品清单反查到 `baseline-gate-negative-test-suite.yaml`，证明 release gate、starter gate、审计导出、运行时准入和状态迁移阻断规则至少各有一类坏样例被拒绝，且实际失败原因与预期策略规则一致。\n34. 任意生产 AI 系统都能从制品清单反查到 `baseline-ai-system-regulatory-impact-ledger.yaml`，证明系统用途、部署角色、适用法规、风险分类、人工监督、日志留存、技术文档、透明度、后市场监测、供应商责任、DPIA/监管义务映射和合规缺口关闭证据已经进入同一基线。\n\n### 10.10.16 基线验证环境锁定\n\n`baseline-verification-lock.yaml` 是企业架构基线的验证环境锁文件。它不替代 `Makefile`、CI 配置或脚本，而是把“用什么环境、什么命令、什么工具版本验证当前基线”固定成可审计证据，避免校验器或 runner 漂移导致同一基线结果不一致。\n\n```yaml\nbaselineVerificationLock:\n lockId: bvl-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n owner: architecture-governance-board\n sourceCommit: \n releaseTag: architecture/v2.53-candidate\n generatedAt: 2026-06-02T12:15:00+08:00\n runner:\n type: container\n image: registry.company.com/platform/architecture-baseline-runner@sha256:\n os: ubuntu-24.04\n architecture: amd64\n networkPolicy: no-unpinned-downloads\n commands:\n - name: docs-toc\n command: make sync-doc-toc\n required: true\n expectedResult: pass\n - name: repo-test\n command: make test\n required: true\n expectedResult: pass\n - name: whitespace\n command: git diff --check\n required: true\n expectedResult: pass\n - name: forbidden-assets\n command: git ls-tree -r --name-only origin/develop -- assets/templates/modern-enterprise-architecture-private/kit\n required: true\n expectedResult: empty\n - name: local-private-artifact-boundary\n command: git status --short --ignored -- assets/templates/modern-enterprise-architecture-private/kit assets/templates/modern-enterprise-architecture-private/controls.json assets/templates/modern-enterprise-architecture-private/version.json assets/templates/modern-enterprise-architecture-private/scripts/check-modern-architecture-kit.py assets/templates/modern-enterprise-architecture-private/scripts/check-modern-architecture-audit-export.py assets/templates/modern-enterprise-architecture-private/scripts/export-modern-architecture-audit.py assets/templates/modern-enterprise-architecture-private/scripts/check-repository-remote-protection.py\n required: true\n expectedResult: ignored-only\n - name: audit-export-exclusion-manifest\n command: internal-command://architecture/check-modern-architecture-audit-export --check-exclusions\n required: true\n expectedResult: pass\n - name: private-artifact-escrow-manifest\n command: internal-command://architecture/check-modern-architecture-kit --check-private-artifact-escrow\n required: true\n expectedResult: pass\n - name: clean-room-reconstruction\n command: internal-command://architecture/check-modern-architecture-kit --clean-room-reconstruct governance/evidence/baselines/baseline-clean-room-reconstruction-receipt.yaml\n required: true\n expectedResult: pass\n - name: evidence-archive-receipt\n command: internal-command://architecture/check-modern-architecture-kit --check-evidence-archive governance/evidence/baselines/baseline-evidence-archive-receipt.yaml\n required: true\n expectedResult: pass\n - name: runtime-admission-receipt\n command: internal-command://architecture/check-modern-architecture-kit --check-runtime-admission governance/evidence/baselines/baseline-runtime-admission-receipt.yaml\n required: true\n expectedResult: pass\n tools:\n markdownlint:\n version: 0.48.0\n source: npm\n digest: sha256:\n python:\n version: 3.12.x\n source: runner-image\n jsonSchemaValidator:\n name: ajv\n version: 8.x\n digest: sha256:\n policyEngines:\n - name: opa\n version: 1.x\n bundleDigest: sha256:\n - name: kyverno\n version: 1.x\n bundleDigest: sha256:\n signing:\n cosignVersion: 2.x\n certificateIdentity: architecture-release-bot\n transparencyLog: rekor\n admission:\n kubernetesVersion: 1.x\n policyControllerVersion: 0.x\n kyvernoVersion: 1.x\n gatekeeperVersion: 3.x\n bundleDigest: sha256:\n inputs:\n lifecycleStateMachine: governance/evidence/baselines/baseline-lifecycle-state-machine.yaml\n stateReconciliation: governance/evidence/baselines/baseline-state-reconciliation-report.yaml\n artifactInventory: governance/evidence/baselines/baseline-artifact-inventory.yaml\n localPrivateArtifactBoundary: governance/evidence/baselines/baseline-local-artifact-boundary.yaml\n auditExportExclusionManifest: governance/evidence/audit-export/audit-export-exclusion-manifest.yaml\n privateArtifactEscrowManifest: governance/evidence/baselines/private-artifact-escrow-manifest.yaml\n cleanRoomReconstructionReceipt: governance/evidence/baselines/baseline-clean-room-reconstruction-receipt.yaml\n evidenceArchiveReceipt: governance/evidence/baselines/baseline-evidence-archive-receipt.yaml\n signatureLtvReceipt: governance/evidence/baselines/baseline-signature-ltv-receipt.yaml\n runtimeAdmissionReceipt: governance/evidence/baselines/baseline-runtime-admission-receipt.yaml\n readinessScorecard: governance/evidence/baselines/baseline-readiness-scorecard.yaml\n exceptionLedger: governance/evidence/exceptions/baseline-exception-ledger.yaml\n standardsBaseline: governance/control-plane/standards-baseline.yaml\n controlCoverage: governance/control-plane/control-coverage.yaml\n outputs:\n auditExport:\n path: assets/templates/modern-enterprise-architecture-private/build/audit/audit-export.json\n generatedBy: internal-command://architecture/export-modern-architecture-audit\n integrity:\n path: assets/templates/modern-enterprise-architecture-private/build/audit/audit-export-integrity.json\n provenance:\n path: assets/templates/modern-enterprise-architecture-private/build/audit/audit-export-provenance.json\n gates:\n runnerImagePinnedByDigest: true\n noUnpinnedToolDownload: true\n toolVersionsLocked: true\n policyBundlesPinned: true\n validatorVersionsLocked: true\n signingToolsLocked: true\n admissionToolchainLocked: true\n```\n\n锁定对象至少包括：\n\n| 对象 | 最低要求 | 阻断条件 |\n| ---- | -------- | -------- |\n| Runner | 使用不可变镜像 digest 或等价 runner 快照 | 只写 `latest`、OS 版本不明、架构不明 |\n| 命令 | 列出命令、是否必需、预期结果和输出路径 | 关键命令只在文档正文出现，锁文件没有记录 |\n| 工具 | 记录名称、版本、来源和摘要 | 校验器、签名工具或策略引擎未固定版本 |\n| 策略包 | 记录 bundle digest、适用范围和生效时间 | OPA / Kyverno / Cedar 策略包漂移 |\n| Schema validator | 记录 validator 名称、版本和行为模式 | 不同 validator 对同一 schema 行为不一致 |\n| 签名验签工具 | 记录版本、身份、证书策略和透明日志要求 | 验签工具或证书身份不可复现 |\n\n执行规则：\n\n1. 企业级 `baseline`、`frozen` 和正式审计导出必须有验证环境锁。\n2. `baseline-verification-lock.yaml` 必须绑定 `baselineId`、`sourceCommit`、`releaseTag` 和 `baseline-artifact-inventory.yaml`。\n3. 任何验证命令、runner 镜像、策略包、schema validator 或签名工具升级，都必须形成基线变更记录或 ADR。\n4. 锁文件中的 runner、工具、策略包和 validator 不得使用 `latest`、浮动主版本或未固定来源。\n5. 审计导出、完整性清单和 provenance 必须记录使用的验证锁摘要。\n6. 如果当前环境无法复现验证锁，基线只能停留在 `candidate`，不得晋级到 `baseline` 或 `frozen`。\n\n可执行验收标准：\n\n1. 任意基线都能证明自己由哪套 runner、命令、工具版本、策略包和 validator 校验。\n2. 任意验证失败都能判断是源制品变化、工具链变化、runner 变化还是策略包变化。\n3. 任意审计导出都能追溯到验证锁摘要，证明生成环境没有漂移。\n4. 任意工具链升级都能找到影响分析、验证结果、回滚路径和新的锁文件。\n\n### 10.10.17 基线通知确认总账\n\n`baseline-notification-ledger.yaml` 是企业架构基线发布前的通知确认总账。它不替代邮件、IM、门户公告或会议纪要，而是把这些通知行为统一沉淀为可审计证据，证明受影响 owner 在冻结前已经收到通知、理解影响、确认迁移责任，或者已经提出异议并进入例外、POA&M 或风险接受。\n\n```yaml\nbaselineNotificationLedger:\n ledgerId: bnl-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n owner: architecture-governance-board\n releaseTrain: governance/evidence/release-trains/baseline-release-train.yaml\n compatibilityLedger: governance/evidence/compatibility/baseline-compatibility-ledger.yaml\n adoptionLedger: governance/evidence/adoption/baseline-adoption-ledger.yaml\n exceptionLedger: governance/evidence/exceptions/baseline-exception-ledger.yaml\n notificationWindow:\n firstNoticeAt: 2026-06-10T09:00:00+08:00\n freezeNoticeAt: 2026-06-24T09:00:00+08:00\n acknowledgementDueAt: 2026-06-24T18:00:00+08:00\n baselineDecisionAt: 2026-07-01T10:00:00+08:00\n targetAudience:\n - audienceId: domain-order-owner\n ownerType: domain-owner\n required: true\n team: team-order\n contact: order-tech-lead\n impactedAssets:\n - service:order-command-service\n - data-product:order-facts\n impactSources:\n - governance/evidence/compatibility/baseline-compatibility-ledger.yaml\n - governance/evidence/adoption/baseline-adoption-ledger.yaml\n expectedAckBy: 2026-06-24T18:00:00+08:00\n - audienceId: platform-gitops-owner\n ownerType: platform-owner\n required: true\n team: platform-runtime\n contact: gitops-platform-lead\n impactedAssets:\n - platform-capability:gitops-runtime\n expectedAckBy: 2026-06-24T18:00:00+08:00\n notifications:\n - noticeId: notice-first-20260610\n noticeType: first-notice\n sentAt: 2026-06-10T09:00:00+08:00\n sentBy: architecture-release-bot\n contentDigest: sha256:\n channels:\n - architecture-portal\n - platform-developer-portal\n - engineering-leads-mailing-list\n recipients:\n - audienceId: domain-order-owner\n deliveryStatus: delivered\n deliveredAt: 2026-06-10T09:01:00+08:00\n acknowledgementStatus: acknowledged\n acknowledgedBy: order-tech-lead\n acknowledgedAt: 2026-06-10T11:20:00+08:00\n impactAccepted: true\n objections: []\n - audienceId: platform-gitops-owner\n deliveryStatus: delivered\n deliveredAt: 2026-06-10T09:02:00+08:00\n acknowledgementStatus: acknowledged\n acknowledgedBy: gitops-platform-lead\n acknowledgedAt: 2026-06-10T12:05:00+08:00\n impactAccepted: true\n objections: []\n - noticeId: notice-freeze-20260624\n noticeType: freeze-notice\n sentAt: 2026-06-24T09:00:00+08:00\n sentBy: architecture-release-bot\n contentDigest: sha256:\n recipients:\n - audienceId: domain-order-owner\n deliveryStatus: delivered\n acknowledgementStatus: acknowledged\n acknowledgedBy: order-tech-lead\n acknowledgedAt: 2026-06-24T11:00:00+08:00\n impactAccepted: true\n objections: []\n objections:\n active: []\n resolved:\n - objectionId: obj-20260610-001\n raisedBy: data-platform-owner\n raisedAt: 2026-06-10T15:00:00+08:00\n reason: data-product lineage rule needs migration sample\n resolution: migration sample added before freeze\n resolvedAt: 2026-06-18T17:00:00+08:00\n resolvedBy: architecture-governance-board\n exceptions:\n active: []\n summary:\n requiredRecipients: 2\n delivered: 2\n acknowledged: 2\n missingAcknowledgements: 0\n activeObjections: 0\n activeExceptions: 0\n readyForFreeze: true\n gates:\n blockFreezeOnMissingRequiredAck: true\n blockFreezeOnFailedDelivery: true\n blockBaselineOnActiveObjection: true\n requireExceptionForWaivedAck: true\n requireContentDigestForEachNotice: true\n```\n\n确认状态只能使用以下值：\n\n| 状态 | 含义 | 是否阻断 |\n| ---- | ---- | -------- |\n| `pending` | 已识别为通知对象，但尚未发送或尚无送达证据 | 是 |\n| `delivered` | 通知已送达，但尚未完成影响确认 | 关键对象阻断 |\n| `acknowledged` | 已确认收到并理解影响 | 否 |\n| `objected` | 已提出异议或风险问题 | 是，直到关闭或风险接受 |\n| `waived` | 确认要求被批准豁免 | 不阻断，但必须有例外和到期日 |\n| `failed` | 通知投递失败 | 是 |\n| `expired` | 超过确认截止时间仍未确认 | 是 |\n\n执行规则：\n\n1. `targetAudience` 必须来自 `baseline-compatibility-ledger.yaml`、`baseline-adoption-ledger.yaml`、catalog owner、GitOps 环境 owner 和安全/审计相关方，不能只手工列邮件名单。\n2. 每条通知必须记录 `noticeType`、`sentAt`、`channels`、`contentDigest` 和 recipients；没有内容摘要的通知不能作为冻结证据。\n3. `required=true` 的对象必须在 `acknowledgementDueAt` 前达到 `acknowledged`，除非存在未过期例外、POA&M 或风险接受。\n4. 任意 `objected` 状态必须进入 `objections`，并在冻结前关闭、转例外或进入风险接受；不能用会议口头结论覆盖异议。\n5. 任意 `failed` 或 `expired` 状态必须有补发、升级通知或例外审批；关键 owner 未确认时不得进入 `freeze`。\n6. 发布证据包必须记录 `baseline-notification-ledger.yaml` 的摘要，证明冻结复核使用的是同一份通知确认总账。\n\n可执行验收标准：\n\n1. 任意企业级基线都能列出所有必须通知和必须确认的领域、平台、数据、AI、GitOps、安全和审计对象。\n2. 任意通知都能证明发送时间、渠道、内容摘要、送达结果和确认人。\n3. 任意未确认对象都能证明补发、例外、POA&M 或风险接受，而不是停留在 unknown。\n4. 任意冻结基线都能证明 `missingAcknowledgements=0` 且 `activeObjections=0`，或存在明确的风险接受记录。\n\n### 10.10.18 基线回滚验证记录\n\n`baseline-rollback-verification.yaml` 是企业架构基线从候选进入正式基线前的回滚验证记录。它不替代回滚计划、Git tag、GitOps 历史或审计导出包，而是把这些入口做一次实际验证，并把结果固化为可审计证据。\n\n```yaml\nbaselineRollbackVerification:\n verificationId: brv-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n owner: architecture-governance-board\n currentBaseline:\n version: V2.53\n releaseTag: architecture/v2.53-candidate\n sourceCommit: \n releaseEvidence: governance/evidence/baselines/baseline-release-evidence.yaml\n rollbackTarget:\n version: V2.52\n baselineId: mea-v2.52-20260602\n releaseTag: architecture/v2.52-candidate\n sourceCommit: \n supportState: active\n supportMatrix: governance/evidence/support/baseline-support-matrix.yaml\n verificationWindow:\n verifiedAt: 2026-06-02T13:00:00+08:00\n expiresAt: 2026-07-02T23:59:59+08:00\n verifiedBy:\n - architecture-release-bot\n - platform-sre-reviewer\n checks:\n - checkId: git-tag-checkout\n command: git checkout architecture/v2.52-candidate\n expectedResult: pass\n result: pass\n evidenceDigest: sha256:\n - checkId: audit-export-restore\n command: internal-command://architecture/export-modern-architecture-audit\n expectedResult: pass\n result: pass\n evidenceDigest: sha256:\n - checkId: gitops-revision-restore\n environment: staging\n targetRevision: \n expectedResult: synced\n result: synced\n evidenceDigest: sha256:\n - checkId: smoke-validation\n target: baseline-reference-stack\n command: make test\n expectedResult: pass\n result: pass\n evidenceDigest: sha256:\n recoveryResult:\n result: pass\n recoveryTimeMinutes: 18\n dataLossObserved: false\n blockingFailures: 0\n warnings: 0\n artifacts:\n rollbackGuide: governance/evidence/baseline-changes/baseline-change-record.yaml\n releaseEvidence: governance/evidence/baselines/baseline-release-evidence.yaml\n lifecycleStateMachine: governance/evidence/baselines/baseline-lifecycle-state-machine.yaml\n stateReconciliation: governance/evidence/baselines/baseline-state-reconciliation-report.yaml\n artifactInventory: governance/evidence/baselines/baseline-artifact-inventory.yaml\n verificationLock: governance/evidence/verification/baseline-verification-lock.yaml\n readinessScorecard: governance/evidence/baselines/baseline-readiness-scorecard.yaml\n exceptionLedger: governance/evidence/exceptions/baseline-exception-ledger.yaml\n auditExportManifest: governance/evidence/audit-export/audit-export-manifest.yaml\n gates:\n blockBaselineIfRollbackTargetMissing: true\n blockFrozenIfVerificationExpired: true\n requireGitopsRevisionForRuntimeRollback: true\n requireAuditExportRollbackEvidence: true\n requireSmokeValidationForReferenceStack: true\n```\n\n验证状态只能使用以下值：\n\n| 状态 | 含义 | 是否阻断 |\n| ---- | ---- | -------- |\n| `pass` | 检查项按预期完成，证据摘要已记录 | 否 |\n| `fail` | 检查项执行失败或结果不符合预期 | 是 |\n| `skipped` | 因明确范围不适用而跳过 | 条件阻断，必须说明理由和批准人 |\n| `not-applicable` | 当前基线没有对应运行面或制品类型 | 否，但必须有范围说明 |\n| `expired` | 验证窗口已过期，需要重新执行 | 是 |\n| `blocked` | 缺少前置制品、权限或环境，无法执行验证 | 是 |\n\n执行规则：\n\n1. `baseline-rollback-verification.yaml` 必须绑定当前基线和上一基线的 `baselineId`、`releaseTag`、`sourceCommit` 和支持状态。\n2. 回滚目标必须在支持矩阵中处于 `active`、`maintenance`、`security-only` 或 `frozen`，不得指向 `eol` 基线。\n3. Git 回滚必须证明上一基线 tag 或 commit 可检出；GitOps 回滚必须证明目标 revision 存在并可同步。\n4. 审计导出恢复必须证明上一基线仍能生成或读取对应导出包，且摘要能与历史证据对上。\n5. 参考栈烟测必须覆盖文档门禁、starter kit 校验、审计导出门禁和至少一个 GitOps 恢复验证。\n6. `verificationWindow.expiresAt` 过期后，基线不得晋级到 `frozen`，必须重新生成回滚验证记录。\n7. 任意 `fail`、`expired` 或 `blocked` 必须进入 POA&M、风险登记或 release gate 阻断，不能被发布证据包覆盖。\n\n可执行验收标准：\n\n1. 任意正式基线都能找到一份未过期的 `baseline-rollback-verification.yaml`。\n2. 任意回滚验证都能证明上一基线 tag/commit 可检出，并能定位 GitOps revision 或明确声明不适用。\n3. 任意审计人员都能从记录中看到恢复命令、预期结果、实际结果、证据摘要和验证窗口。\n4. 任意失败的回滚验证都会阻断 `baseline` 或 `frozen` 晋级，直到有修复证据、例外审批或风险接受。\n\n### 10.10.19 基线例外总账\n\n`baseline-exception-ledger.yaml` 是企业架构基线级别的例外聚合总账。它不替代单个控制项、单个资产或单个策略的\n`policy-exception.yaml`，而是把分散在兼容性、采纳、支持矩阵、通知确认、回滚验证、门禁决策、执行控制面、风险登记和\nPOA&M 中的例外统一收敛到同一份基线证据，回答“哪些例外还有效、哪些已经过期、哪些会阻断冻结、谁接受风险、何时关闭”。\n\n```yaml\nbaselineExceptionLedger:\n ledgerId: bel-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n owner: architecture-governance-board\n generatedAt: 2026-06-02T13:30:00+08:00\n linkedEvidence:\n versionGovernance: governance/control-plane/version-governance.yaml\n lifecycleStateMachine: governance/evidence/baselines/baseline-lifecycle-state-machine.yaml\n stateReconciliation: governance/evidence/baselines/baseline-state-reconciliation-report.yaml\n releaseGateDecision: governance/control-plane/release-gate-decision.yaml\n controlPlane: governance/control-plane/control-plane.yaml\n compatibilityLedger: governance/evidence/compatibility/baseline-compatibility-ledger.yaml\n adoptionLedger: governance/evidence/adoption/baseline-adoption-ledger.yaml\n supportMatrix: governance/evidence/support/baseline-support-matrix.yaml\n releaseTrain: governance/evidence/release-trains/baseline-release-train.yaml\n notificationLedger: governance/evidence/communications/baseline-notification-ledger.yaml\n rollbackVerification: governance/evidence/rollback/baseline-rollback-verification.yaml\n conformanceClaims: governance/evidence/conformance/baseline-conformance-claim.yaml\n riskRegister: governance/evidence/risk/risk-register.yaml\n poamRegister: governance/evidence/poam/poam-record.yaml\n exceptionPolicy:\n defaultMaxAgeDays: 90\n blockExpiredExceptions: true\n blockFrozenOnBlockingException: true\n blockFrozenOnHighResidualRisk: true\n requireOwnerForEveryException: true\n requirePoamForBlockingException: true\n requireRiskAcceptanceForConditionalPass: true\n requireCloseEvidenceForClosedException: true\n exceptions:\n active:\n - exceptionId: ex-baseline-2026-001\n source: baseline-adoption-ledger\n sourceRef: governance/evidence/adoption/baseline-adoption-ledger.yaml\n affectedAsset: service:legacy-billing-adapter\n controlIds:\n - MEA-VERSION-ADOPTION\n - MEA-BASELINE-SUPPORT\n severity: medium\n residualRisk: low\n gateImpact: conditional-pass\n owner: legacy-platform-owner\n reason: strangler migration still active\n openedAt: 2026-06-02T10:00:00+08:00\n expiresAt: 2026-09-15T23:59:59+08:00\n riskAcceptedBy: enterprise-architecture-lead\n riskAcceptanceRef: governance/evidence/risk/legacy-billing-risk-acceptance.yaml\n poam: governance/evidence/poam/legacy-billing-adapter-poam.yaml\n compensatingControls:\n - read-only traffic\n - daily reconciliation\n - canary traffic capped at 5 percent\n closeCriteria:\n - migration completed\n - conformance claim regenerated\n - production traffic on old baseline equals zero\n blocking: []\n expired: []\n closed:\n - exceptionId: ex-baseline-2026-000\n source: baseline-compatibility-ledger\n affectedAsset: api:order-command:v1\n closedAt: 2026-06-18T17:00:00+08:00\n closedBy: architecture-governance-board\n closeEvidence: governance/evidence/compatibility/order-command-api-v2.yaml\n summary:\n activeCount: 1\n blockingCount: 0\n expiredCount: 0\n highResidualRiskCount: 0\n conditionalPassCount: 1\n readyForBaseline: true\n readyForFrozen: true\n gates:\n blockBaselineOnExpiredException: true\n blockBaselineOnUnknownOwner: true\n blockFrozenOnBlockingException: true\n blockFrozenOnHighResidualRisk: true\n requirePoamForBlockingException: true\n requireRiskAcceptanceForConditionalPass: true\n requireExceptionLedgerDigestInReleaseEvidence: true\n```\n\n例外状态只能使用以下值：\n\n| 状态 | 含义 | 是否阻断 |\n| ---- | ---- | -------- |\n| `active` | 例外仍有效，未超过到期日，且有 owner、风险接受和关闭条件 | 视风险等级和门禁影响而定 |\n| `conditional-pass` | 例外允许本轮发布通过，但必须有风险接受、补偿控制和 POA&M | 不阻断 `baseline`，通常阻断或限制 `frozen` |\n| `blocking` | 例外会阻断基线晋级、冻结或生产发布 | 是 |\n| `expired` | 例外超过到期日或证据过期 | 是 |\n| `closed` | 例外已关闭，且有关闭证据 | 否 |\n| `rejected` | 例外申请未被批准 | 是，除非风险通过其他路径关闭 |\n\n执行规则：\n\n1. `baseline-exception-ledger.yaml` 必须聚合 `baseline-compatibility-ledger.yaml`、`baseline-adoption-ledger.yaml`、`baseline-support-matrix.yaml`、`baseline-notification-ledger.yaml`、`baseline-rollback-verification.yaml`、`release-gate-decision.yaml`、`control-plane.yaml`、风险登记和 POA&M 中的例外。\n2. 每个例外必须有来源、受影响资产、控制项、owner、严重度、残余风险、到期时间、补偿控制、关闭条件和证据路径。\n3. `conditional-pass` 必须有风险接受人和 POA&M；缺少任何一个字段都必须降级为 `blocking`。\n4. `expired`、`blocking` 或 `high residual risk` 例外不得进入 `frozen`，除非通过正式风险接受并声明补偿控制、关闭期限和审计可接受性。\n5. 例外关闭必须有 `closeEvidence`，不能只写“已处理”或依赖会议纪要。\n6. 发布证据包必须记录 `baseline-exception-ledger.yaml` 的摘要，并在冻结复核中声明 `expiredCount=0`、`blockingCount=0`。\n\n可执行验收标准：\n\n1. 任意企业级基线都能列出所有活跃、过期、阻断、条件放行和已关闭例外。\n2. 任意例外都能追溯到原始来源、风险接受、POA&M、补偿控制和关闭条件。\n3. 任意过期或阻断例外都会阻断 `baseline` 或 `frozen` 晋级，直到关闭、续期、降级或正式风险接受。\n4. 任意冻结基线都能证明没有散落在其他账本中但未进入总账的活跃例外。\n5. 任意审计人员都能从总账直接判断当前基线是否满足冻结准入，而不需要逐个翻兼容、采纳、支持、通知和门禁记录。\n\n### 10.10.20 基线就绪评分卡\n\n`baseline-readiness-scorecard.yaml` 是企业架构基线晋级前的最终就绪判定。它不替代版本控制面、发布证据包、控制项覆盖、\n基线制品清单、验证环境锁或例外总账，而是把这些证据按硬门禁和评分维度统一汇总，避免出现“每份局部证据都存在，\n但没有人能明确判断是否可以进入 baseline 或 frozen”的状态。\n\n```yaml\nbaselineReadinessScorecard:\n scorecardId: brs-20260602-mea-v257\n baselineId: mea-v2.57-20260602\n documentVersion: V2.57\n owner: architecture-governance-board\n generatedAt: 2026-06-02T14:00:00+08:00\n scoringPolicy:\n minimumBaselineScore: 90\n minimumFrozenScore: 95\n blockOnCriticalFinding: true\n blockOnArtifactDigestDrift: true\n blockOnVerificationLockDrift: true\n blockOnExpiredException: true\n blockOnRollbackUnverified: true\n blockOnMissingRequiredNotification: true\n blockOnForbiddenRemoteAssets: true\n blockOnMissingLocalArtifactBoundary: true\n blockOnLocalPrivateArtifactRawExport: true\n blockOnMissingAuditExportExclusionManifest: true\n blockOnSignaturePayloadBoundaryViolation: true\n blockOnMissingPrivateArtifactEscrowManifest: true\n blockOnPrivateArtifactRestoreFailure: true\n blockOnMissingCleanRoomReconstructionReceipt: true\n blockOnCleanRoomReconstructionFailure: true\n blockOnMissingEvidenceArchiveReceipt: true\n blockOnEvidenceArchiveFailure: true\n blockOnMissingSignatureLtvReceipt: true\n blockOnSignatureLtvFailure: true\n blockOnMissingRuntimeAdmissionReceipt: true\n blockOnRuntimeAdmissionBypass: true\n scoreCannotOverrideHardGate: true\n evidenceInputs:\n versionGovernance: governance/control-plane/version-governance.yaml\n lifecycleStateMachine: governance/evidence/baselines/baseline-lifecycle-state-machine.yaml\n stateReconciliation: governance/evidence/baselines/baseline-state-reconciliation-report.yaml\n releaseEvidence: governance/evidence/baselines/baseline-release-evidence.yaml\n controlCoverage: governance/control-plane/control-coverage.yaml\n artifactInventory: governance/evidence/baselines/baseline-artifact-inventory.yaml\n verificationLock: governance/evidence/verification/baseline-verification-lock.yaml\n exceptionLedger: governance/evidence/exceptions/baseline-exception-ledger.yaml\n notificationLedger: governance/evidence/communications/baseline-notification-ledger.yaml\n rollbackVerification: governance/evidence/rollback/baseline-rollback-verification.yaml\n auditExportManifest: governance/evidence/audit-export/audit-export-manifest.yaml\n auditExportExclusionManifest: governance/evidence/audit-export/audit-export-exclusion-manifest.yaml\n privateArtifactEscrowManifest: governance/evidence/baselines/private-artifact-escrow-manifest.yaml\n cleanRoomReconstructionReceipt: governance/evidence/baselines/baseline-clean-room-reconstruction-receipt.yaml\n evidenceArchiveReceipt: governance/evidence/baselines/baseline-evidence-archive-receipt.yaml\n signatureLtvReceipt: governance/evidence/baselines/baseline-signature-ltv-receipt.yaml\n runtimeAdmissionReceipt: governance/evidence/baselines/baseline-runtime-admission-receipt.yaml\n repositoryChangeControl: governance/control-plane/repository-change-control.yaml\n localArtifactBoundary: governance/evidence/baselines/baseline-local-artifact-boundary.yaml\n dimensions:\n - id: version-identity\n weight: 10\n score: 100\n status: pass\n evidence:\n - governance/control-plane/version-governance.yaml\n - id: control-coverage\n weight: 15\n score: 96\n status: pass\n evidence:\n - governance/control-plane/control-coverage.yaml\n - id: artifact-integrity\n weight: 15\n score: 98\n status: pass\n evidence:\n - governance/evidence/baselines/baseline-artifact-inventory.yaml\n - governance/evidence/baselines/baseline-local-artifact-boundary.yaml\n - governance/evidence/audit-export/audit-export-exclusion-manifest.yaml\n - governance/evidence/baselines/private-artifact-escrow-manifest.yaml\n - governance/evidence/baselines/baseline-evidence-archive-receipt.yaml\n - governance/evidence/baselines/baseline-signature-ltv-receipt.yaml\n - governance/evidence/baselines/baseline-runtime-admission-receipt.yaml\n - assets/templates/modern-enterprise-architecture-private/build/audit/audit-export-integrity.json\n - id: verification-reproducibility\n weight: 10\n score: 95\n status: pass\n evidence:\n - governance/evidence/verification/baseline-verification-lock.yaml\n - governance/evidence/baselines/baseline-clean-room-reconstruction-receipt.yaml\n - id: exception-health\n weight: 15\n score: 94\n status: conditional-pass\n evidence:\n - governance/evidence/exceptions/baseline-exception-ledger.yaml\n - id: compatibility-and-adoption\n weight: 10\n score: 93\n status: conditional-pass\n evidence:\n - governance/evidence/compatibility/baseline-compatibility-ledger.yaml\n - governance/evidence/adoption/baseline-adoption-ledger.yaml\n - id: notification-readiness\n weight: 8\n score: 100\n status: pass\n evidence:\n - governance/evidence/communications/baseline-notification-ledger.yaml\n - id: rollback-readiness\n weight: 10\n score: 97\n status: pass\n evidence:\n - governance/evidence/rollback/baseline-rollback-verification.yaml\n - id: audit-and-supply-chain\n weight: 7\n score: 96\n status: pass\n evidence:\n - governance/evidence/audit-export/audit-export-manifest.yaml\n - governance/evidence/audit-export/audit-export-exclusion-manifest.yaml\n - governance/evidence/audit-export/audit-export-signature-receipt.yaml\n - governance/evidence/baselines/baseline-local-artifact-boundary.yaml\n - governance/evidence/baselines/private-artifact-escrow-manifest.yaml\n - governance/evidence/baselines/baseline-clean-room-reconstruction-receipt.yaml\n - governance/evidence/baselines/baseline-evidence-archive-receipt.yaml\n - governance/evidence/baselines/baseline-signature-ltv-receipt.yaml\n - governance/evidence/baselines/baseline-runtime-admission-receipt.yaml\n hardGates:\n failed: []\n warnings:\n - id: adoption-exception-open\n source: governance/evidence/exceptions/baseline-exception-ledger.yaml\n impact: does-not-block-baseline-but-limits-frozen\n summary:\n weightedScore: 96\n readinessLevel: ready-for-baseline\n readyForBaseline: true\n readyForFrozen: false\n frozenBlockers:\n - freeze-window-not-started\n blockingFindings: 0\n expiredExceptions: 0\n forbiddenRemoteAssets: 0\n localPrivateArtifactBoundary: pass\n auditExportExclusionManifest: pass\n privateArtifactEscrowManifest: pass\n privateEscrowRestoreFailures: 0\n cleanRoomReconstructionReceipt: pass\n cleanRoomReconstructionFailures: 0\n evidenceArchiveReceipt: pass\n evidenceArchiveRestoreFailures: 0\n signatureLtvReceipt: pass\n signatureLtvFailures: 0\n runtimeAdmissionReceipt: pass\n runtimeAdmissionRejectSamples: 6\n runtimeAdmissionBypassFindings: 0\n localPrivateRawAuditExportInclusions: 0\n localPrivateRawSignaturePayloadInclusions: 0\n decision:\n candidateToBaseline: pass\n baselineToFrozen: not-ready\n decidedBy: architecture-governance-board\n decisionRef: governance/control-plane/release-gate-decision.yaml\n```\n\n就绪状态只能使用以下值：\n\n| 状态 | 含义 | 是否允许晋级 |\n| ---- | ---- | ------------ |\n| `not-ready` | 评分不足或硬门禁未通过 | 否 |\n| `ready-for-candidate` | 可进入候选评审，但不能用于生产基线 | 只允许低风险试点 |\n| `ready-for-baseline` | 满足 baseline 阈值和全部 baseline 硬门禁 | 允许进入 baseline |\n| `ready-for-frozen` | 满足 frozen 阈值、冻结窗口和全部冻结硬门禁 | 允许进入 frozen |\n| `blocked` | 存在 critical finding、过期例外、回滚失败、禁推资产或制品漂移 | 否 |\n| `expired` | 评分卡证据超过有效期，需要重新生成 | 否 |\n\n执行规则：\n\n1. `baseline-readiness-scorecard.yaml` 必须在 `candidate -> baseline` 和 `baseline -> frozen` 前生成，并写入 `baseline-release-evidence.yaml` 的不可变摘要。\n2. 每个评分维度必须有 `weight`、`score`、`status` 和证据路径；评分维度权重总和必须等于 100。\n3. 硬门禁失败不能被平均分覆盖；只要存在 critical finding、过期例外、回滚未验证、制品摘要漂移、缺失本地私有制品边界、缺失审计导出排除清单、缺失私有制品托管交接、私有托管取回失败、缺失干净环境重建回执、干净环境重建失败、缺失运行时准入回执、runtime admission 拒绝样例失败、禁推资产进入远端、审计导出原文或签名 payload，最终判定必须为 `blocked`。\n4. `ready-for-baseline` 不等于 `ready-for-frozen`。冻结还必须满足更高分数、冻结窗口、通知确认、例外总账和审计导出要求。\n5. `conditional-pass` 维度必须能追溯到风险接受、POA&M、补偿控制和关闭日期，不能只靠人工签字放行。\n6. 评分卡必须进入季度复核；任何评分策略、权重或硬门禁变化都必须形成基线变更记录或 ADR。\n\n可执行验收标准：\n\n1. 任意基线晋级都能找到对应的 `baseline-readiness-scorecard.yaml`。\n2. 任意评分卡都能证明权重总和为 100，且每个维度都有证据路径和状态。\n3. 任意硬门禁失败都会把最终判定置为 `blocked`，不会被总分掩盖。\n4. 任意 `ready-for-frozen` 结论都能证明分数达到 frozen 阈值、过期例外为 0、阻断项为 0、回滚验证未过期、本地私有制品未进入远端或公开导出原文，且审计导出可验签。\n5. 任意审计人员都能从评分卡直接判断基线处于 `not-ready`、`ready-for-baseline` 还是 `ready-for-frozen`，不需要人工重新拼装所有证据。\n\n### 10.10.21 基线生命周期状态机\n\n`baseline-lifecycle-state-machine.yaml` 是企业架构基线状态迁移的唯一控制面。它不替代 `version-governance.yaml`、\n`baseline-release-evidence.yaml` 或 `release-gate-decision.yaml`，而是规定哪些状态可以迁移、哪些状态永远禁止直达、\n每次迁移必须引用哪些证据、由谁审批、迁移后必须回写哪些账本，避免“状态字段被人工改了，但证据链没有跟着变”的版本治理失效。\n\n```yaml\nbaselineLifecycleStateMachine:\n machineId: blsm-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n owner: architecture-governance-board\n generatedAt: 2026-06-02T14:30:00+08:00\n currentState:\n state: candidate\n enteredAt: 2026-06-02T14:30:00+08:00\n source: governance/control-plane/version-governance.yaml\n releaseTag: architecture/v2.53-candidate\n sourceCommit: \n states:\n - state: draft\n terminal: false\n productionAllowed: false\n description: 文档或契约仍在探索，不能作为执行基线。\n - state: candidate\n terminal: false\n productionAllowed: low-risk-pilot-only\n description: 已具备执行口径，等待晋级评审。\n - state: baseline\n terminal: false\n productionAllowed: true\n description: 已批准作为企业执行基线。\n - state: frozen\n terminal: false\n productionAllowed: true\n description: 已冻结供审计、招标、监管或规模化推广使用。\n - state: emergency-patch\n terminal: false\n productionAllowed: controlled-only\n description: 安全、合规或生产事故紧急补丁通道。\n - state: quarantined\n terminal: false\n productionAllowed: false\n description: 基线存在严重发布、签名、证据或远端保护风险，已被隔离等待裁决。\n - state: revoked\n terminal: true\n productionAllowed: false\n description: 基线已撤销，不得新建、冻结、发布、采用或继续用于生产。\n - state: superseded\n terminal: false\n productionAllowed: existing-assets-only\n description: 已被新基线替代，只允许迁移期存量使用。\n - state: eol\n terminal: true\n productionAllowed: false\n description: 已停止支持，不得新建或继续用于生产。\n allowedTransitions:\n - from: draft\n to: candidate\n requiredEvidence:\n - baseline-change-record\n - version-governance\n - control-coverage\n - make-test\n approvers:\n - architecture-document-owner\n sideEffects:\n - update-doc-index\n - update-version-manifest\n - from: candidate\n to: baseline\n requiredEvidence:\n - baseline-release-evidence\n - baseline-readiness-scorecard\n - baseline-evidence-trace-graph\n - baseline-gate-execution-report\n - baseline-gate-negative-test-suite\n - baseline-publish-transaction\n - baseline-artifact-inventory\n - baseline-verification-lock\n - baseline-runtime-admission-receipt\n - baseline-business-outcome-value-realization-portfolio-ledger\n - baseline-value-stream-journey-process-ledger\n - baseline-architecture-view-runtime-topology-dependency-ledger\n - baseline-quality-attribute-architecture-driver-tradeoff-ledger\n - baseline-architecture-principle-constraint-exception-ledger\n - baseline-exception-ledger\n - baseline-rollback-verification\n - baseline-review-board-decision\n - release-gate-decision\n - signed-release-tag\n approvers:\n - platform-lead\n - security-lead\n - data-governance-lead\n - architecture-governance-board\n sideEffects:\n - update-version-governance-status\n - write-release-evidence-digest\n - notify-owners\n - from: baseline\n to: frozen\n requiredEvidence:\n - frozen-window-open\n - baseline-readiness-scorecard-ready-for-frozen\n - notification-ledger-complete\n - expired-exceptions-zero\n - rollback-verification-not-expired\n - baseline-evidence-trace-graph-closed\n - baseline-gate-execution-report-replayed\n - baseline-publish-transaction-remote-refs-locked\n - baseline-runtime-admission-receipt\n - baseline-business-outcome-value-realization-portfolio-ledger\n - baseline-value-stream-journey-process-ledger\n - baseline-architecture-view-runtime-topology-dependency-ledger\n - baseline-quality-attribute-architecture-driver-tradeoff-ledger\n - baseline-architecture-principle-constraint-exception-ledger\n - audit-export-signature-receipt\n - baseline-review-board-decision\n approvers:\n - architecture-governance-board\n - audit-lead\n - security-lead\n sideEffects:\n - freeze-source-commit\n - freeze-audit-export\n - lock-support-matrix\n - from: baseline\n to: superseded\n requiredEvidence:\n - successor-baseline-approved\n - baseline-support-matrix-updated\n - adoption-migration-plan\n approvers:\n - architecture-governance-board\n sideEffects:\n - update-support-state\n - notify-consumers\n - from: frozen\n to: superseded\n requiredEvidence:\n - successor-frozen-or-baseline-approved\n - audit-retention-plan\n - migration-deadline\n approvers:\n - architecture-governance-board\n - audit-lead\n sideEffects:\n - retain-frozen-evidence\n - update-support-state\n - from: baseline\n to: emergency-patch\n requiredEvidence:\n - incident-or-security-ticket\n - patch-scope\n - rollback-verification\n - postmortem-owner\n approvers:\n - security-lead\n - platform-lead\n sideEffects:\n - create-emergency-patch-record\n - schedule-postmortem\n - from: emergency-patch\n to: baseline\n requiredEvidence:\n - patch-evidence-complete\n - postmortem-complete\n - regression-gates-pass\n approvers:\n - architecture-governance-board\n sideEffects:\n - merge-patch-evidence\n - update-release-evidence\n - from: baseline\n to: quarantined\n requiredEvidence:\n - baseline-revocation-record\n - affected-reference-inventory\n - notification-ledger-updated\n - rollback-or-replacement-target\n approvers:\n - architecture-governance-board\n - security-lead\n - audit-lead\n sideEffects:\n - block-new-adoption\n - pause-release-train\n - update-support-state\n - from: frozen\n to: quarantined\n requiredEvidence:\n - baseline-revocation-record\n - audit-export-quarantine-note\n - affected-reference-inventory\n - notification-ledger-updated\n approvers:\n - architecture-governance-board\n - security-lead\n - audit-lead\n sideEffects:\n - block-new-adoption\n - freeze-evidence-retention\n - update-support-state\n - from: quarantined\n to: baseline\n requiredEvidence:\n - revocation-clearance-approved\n - regression-gates-pass\n - state-reconciliation-pass\n - review-board-decision\n approvers:\n - architecture-governance-board\n - security-lead\n sideEffects:\n - restore-adoption-if-approved\n - update-support-state\n - from: quarantined\n to: revoked\n requiredEvidence:\n - baseline-revocation-record\n - production-reference-zero-or-risk-accepted\n - replacement-baseline-plan\n - audit-evidence-archived\n approvers:\n - architecture-governance-board\n - platform-lead\n - security-lead\n - audit-lead\n sideEffects:\n - permanently-block-new-adoption\n - archive-revoked-baseline\n - require-successor-baseline\n - from: superseded\n to: eol\n requiredEvidence:\n - zero-production-adoption\n - support-matrix-eol-date-reached\n - migration-ledger-closed\n - baseline-eol-retirement-certificate\n - baseline-review-board-decision\n - baseline-evidence-trace-graph\n - baseline-gate-execution-report\n - baseline-gate-negative-test-suite\n - baseline-publish-transaction\n - audit-evidence-archived\n approvers:\n - architecture-governance-board\n - platform-lead\n - audit-lead\n sideEffects:\n - block-new-adoption\n - archive-baseline-evidence\n - revoke-production-use\n forbiddenTransitions:\n - from: draft\n to: baseline\n reason: 必须先进入 candidate 并完成晋级证据。\n - from: draft\n to: frozen\n reason: 草案不能直接冻结。\n - from: candidate\n to: frozen\n reason: 必须先成为 baseline。\n - from: frozen\n to: draft\n reason: 冻结基线不得回退为草案，只能补丁、替代或退役。\n - from: frozen\n to: baseline\n reason: 冻结状态不可降级；后续变更必须走补丁或新基线。\n - from: eol\n to: baseline\n reason: EOL 基线不可复活，必须创建新 baseline ID。\n - from: revoked\n to: baseline\n reason: 已撤销基线不可复活，必须创建新 baseline ID。\n - from: revoked\n to: frozen\n reason: 已撤销基线不可冻结，必须创建新 baseline ID。\n - from: quarantined\n to: frozen\n reason: 隔离基线不能直接冻结；必须先解除隔离回到 baseline。\n transitionAttempts:\n - transitionId: blsm-transition-20260602-001\n from: candidate\n to: baseline\n requestedBy: architecture-governance-board\n requestedAt: 2026-06-02T14:35:00+08:00\n decision: pass\n decidedAt: 2026-06-02T15:00:00+08:00\n decisionRef: governance/control-plane/release-gate-decision.yaml\n evidence:\n releaseEvidence: governance/evidence/baselines/baseline-release-evidence.yaml\n readinessScorecard: governance/evidence/baselines/baseline-readiness-scorecard.yaml\n evidenceTraceGraph: governance/evidence/baselines/baseline-evidence-trace-graph.yaml\n gateExecutionReport: governance/evidence/baselines/baseline-gate-execution-report.yaml\n publishTransaction: governance/evidence/baselines/baseline-publish-transaction.yaml\n versionPolicyReleaseControlLedger: governance/evidence/baselines/baseline-version-policy-release-control-ledger.yaml\n revocationRecord: governance/evidence/baselines/baseline-revocation-record.yaml\n artifactInventory: governance/evidence/baselines/baseline-artifact-inventory.yaml\n verificationLock: governance/evidence/verification/baseline-verification-lock.yaml\n exceptionLedger: governance/evidence/exceptions/baseline-exception-ledger.yaml\n rollbackVerification: governance/evidence/rollback/baseline-rollback-verification.yaml\n reviewBoardDecision: governance/evidence/baselines/baseline-review-board-decision.yaml\n runtimeAdmissionReceipt: governance/evidence/baselines/baseline-runtime-admission-receipt.yaml\n runtimeAdmissionDecisionLedger: governance/evidence/baselines/baseline-runtime-admission-decision-ledger.yaml\n continuousControlMonitoringLedger: governance/evidence/baselines/baseline-continuous-control-monitoring-ledger.yaml\n controlAssuranceSamplingLedger: governance/evidence/baselines/baseline-control-assurance-sampling-ledger.yaml\n controlInheritanceLedger: governance/evidence/baselines/baseline-control-inheritance-ledger.yaml\n dataResidencyTransferLedger: governance/evidence/baselines/baseline-data-residency-transfer-ledger.yaml\n thirdPartyRiskLedger: governance/evidence/baselines/baseline-third-party-risk-ledger.yaml\n operationalResilienceLedger: governance/evidence/baselines/baseline-operational-resilience-ledger.yaml\n secureConfigurationPostureDriftLedger: governance/evidence/baselines/baseline-secure-configuration-posture-drift-ledger.yaml\n productionChangeReleaseLedger: governance/evidence/baselines/baseline-production-change-release-ledger.yaml\n architecturePrincipleConstraintExceptionLedger: governance/evidence/baselines/baseline-architecture-principle-constraint-exception-ledger.yaml\n serviceReliabilitySloErrorBudgetObservabilityLedger: governance/evidence/baselines/baseline-service-reliability-slo-error-budget-observability-ledger.yaml\n backupRestoreDisasterRecoveryLedger: governance/evidence/baselines/baseline-backup-restore-disaster-recovery-ledger.yaml\n guardResults:\n transitionAllowed: true\n requiredEvidencePresent: true\n hardGatesPass: true\n forbiddenRemoteAssets: 0\n writeBack:\n versionGovernanceStatus: baseline\n supportMatrixState: active\n releaseEvidenceDigestUpdated: true\n stateReconciliationUpdated: true\n```\n\n生命周期状态只能使用以下值：\n\n| 状态 | 含义 | 生产使用 |\n| ---- | ---- | -------- |\n| `draft` | 设计草案或未完成契约 | 禁止 |\n| `candidate` | 候选基线，可低风险试点 | 仅低风险试点 |\n| `baseline` | 已批准执行基线 | 允许 |\n| `frozen` | 冻结审计或规模化推广口径 | 允许，但只能补丁或替代 |\n| `emergency-patch` | 紧急补丁状态 | 受控允许 |\n| `quarantined` | 已隔离，等待撤销、恢复或替代裁决 | 禁止 |\n| `revoked` | 已撤销，不得继续引用 | 禁止 |\n| `superseded` | 被新基线替代 | 仅存量迁移期 |\n| `eol` | 停止支持 | 禁止 |\n\n执行规则：\n\n1. 所有状态迁移必须先在 `allowedTransitions` 中声明；不在允许表中的迁移默认拒绝。\n2. `forbiddenTransitions` 是硬禁止，即使有人工审批也不能绕过；必须创建新基线或走补丁通道。\n3. 每次迁移必须写入 `transitionAttempts`，记录 `from`、`to`、请求人、批准人、证据路径、决策、状态回写和失败原因。\n4. `currentState.state` 必须与 `version-governance.yaml` 的 `releaseChannel/status`、`baseline-release-evidence.yaml` 的晋级决策和 `baseline-support-matrix.yaml` 的支持状态一致。\n5. `candidate -> baseline` 不能缺少就绪评分卡、证据追踪图、门禁执行报告、发布事务回执、基线版本策略、发布通道、兼容性与冻结控制总账、验证环境锁、制品清单、运行时准入回执、运行时准入决策总账、连续控制监测总账、独立控制保证抽样总账、共享责任与继承控制总账、数据驻留与跨境处理总账、第三方与关键供应商风险总账、运营韧性与重要业务服务影响容忍总账、生产变更与发布编排总账、服务可靠性与可观测性总账、备份恢复与灾备总账、基线架构原则、约束、反模式与例外执行总账、例外总账、回滚验证、会审裁决和 release gate 决策。\n6. `baseline -> frozen` 必须证明冻结窗口开启、就绪评分达到 frozen 阈值、证据追踪图闭合、门禁执行报告可重放、发布事务远端 ref 和保护规则已锁定、运行时准入拒绝样例通过、准入 allow/deny 决策可追溯、连续控制监测覆盖关键控制且 open critical drift 为 0、独立控制保证抽样覆盖 critical 控制且 open critical/high finding 为 0、共享责任与继承控制没有 unowned / expired / invalid inheritance，数据驻留与跨境处理没有 unapproved region / missing transfer mechanism / unapproved subprocessor，第三方与关键供应商风险没有 unapproved critical supplier / expired assurance / missing audit rights / missing exit plan / concentration breach，运营韧性没有 missing important business service / missing impact tolerance / failed scenario / tolerance breach / unowned critical dependency / open critical resilience gap，生产变更没有 unregistered change / blackout violation / unresolved conflict / missing rollback / unrehearsed database migration / missing kill switch / unevaluated prompt or model change / unreviewed emergency change / unresolved failed change，服务可靠性没有 missing SLO / unmeasurable SLI / error budget breach / unowned critical alert / missing runbook / missing synthetic journey / telemetry coverage gap / missing degradation plan，备份恢复与灾备没有 unprotected critical datastore / missing immutable copy / overdue restore drill / rto breach / rpo breach / integrity failure / ransomware isolation gap / uncontrolled restore access，架构原则执行没有 missing owner / undetectable constraint / ungated forbidden pattern / open violation / expired exception / unsigned risk acceptance，撤销隔离记录没有阻断状态、通知确认完成、过期例外为 0、回滚验证未过期、会审裁决同意冻结且审计导出可验签。\n7. `emergency-patch` 只能用于安全、合规或生产事故，必须有事故编号、补丁范围、回滚验证、事后复盘 owner 和补证期限。\n8. `eol` 为终态，不允许重新进入 `baseline`；需要重新启用时必须生成新 baseline ID、发布证据和状态机。\n9. `superseded -> eol` 必须引用 `baseline-eol-retirement-certificate.yaml`、`baseline-review-board-decision.yaml`、`baseline-evidence-trace-graph.yaml`、`baseline-gate-execution-report.yaml` 和 `baseline-publish-transaction.yaml`，证明生产引用清零、迁移关闭、例外清零、审计归档、新采用阻断、退役裁决、门禁执行、发布事实和证据归档链路已经完成。\n10. `baseline/frozen -> quarantined` 与 `quarantined -> revoked` 必须引用 `baseline-revocation-record.yaml`，证明撤销触发、隔离范围、受影响引用、恢复目标、通知确认、风险接受和审计归档已经闭环。\n\n可执行验收标准：\n\n1. 任意基线状态都能从状态机查到当前状态、进入时间、来源 commit、release tag 和回写目标。\n2. 任意状态迁移都能证明它在 `allowedTransitions` 中，且不在 `forbiddenTransitions` 中。\n3. 任意失败、拒绝或被阻断的迁移都能留下 `transitionAttempts`，并能追溯到缺失证据或硬门禁失败。\n4. 任意审计人员都能直接判断当前基线是否只是候选、已经 baseline、已经 frozen、已隔离、已撤销、已被替代还是 EOL。\n5. 任意状态漂移都会被门禁阻断：状态机、版本控制面、发布证据、支持矩阵和采纳总账不能出现互相矛盾的状态。\n6. 任意 EOL 状态都能证明它不是只在支持矩阵中被标记，而是已经完成退役证书、生产阻断和审计归档。\n7. 任意撤销状态都能证明它不是只在会议中决定，而是已经完成隔离、通知、采纳阻断、恢复或替代裁决和审计归档。\n\n### 10.10.22 基线状态对账报告\n\n`baseline-state-reconciliation-report.yaml` 是企业架构基线状态一致性的机器对账报告。它不决定状态迁移，也不替代\n`baseline-lifecycle-state-machine.yaml`；它负责在晋级、冻结、紧急补丁、替代和 EOL 前，把所有声明状态的账本拉到同一张表里，\n证明没有一个系统还在引用旧状态、旧 tag、旧 baseline ID 或旧审计导出摘要。\n\n```yaml\nbaselineStateReconciliationReport:\n reportId: bsr-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n owner: architecture-governance-board\n generatedAt: 2026-06-02T14:45:00+08:00\n expectedState:\n lifecycleState: candidate\n documentVersion: V2.53\n baselineId: mea-v2.53-20260602\n releaseTag: architecture/v2.53-candidate\n sourceCommit: \n inputs:\n lifecycleStateMachine: governance/evidence/baselines/baseline-lifecycle-state-machine.yaml\n versionGovernance: governance/control-plane/version-governance.yaml\n enforcementPolicy: governance/control-plane/baseline-enforcement-policy.yaml\n releaseEvidence: governance/evidence/baselines/baseline-release-evidence.yaml\n evidenceTraceGraph: governance/evidence/baselines/baseline-evidence-trace-graph.yaml\n gateExecutionReport: governance/evidence/baselines/baseline-gate-execution-report.yaml\n publishTransaction: governance/evidence/baselines/baseline-publish-transaction.yaml\n revocationRecord: governance/evidence/baselines/baseline-revocation-record.yaml\n reviewBoardDecision: governance/evidence/baselines/baseline-review-board-decision.yaml\n releaseTrain: governance/evidence/release-trains/baseline-release-train.yaml\n supportMatrix: governance/evidence/support/baseline-support-matrix.yaml\n eolRetirementCertificate: governance/evidence/baselines/baseline-eol-retirement-certificate.yaml\n adoptionLedger: governance/evidence/adoption/baseline-adoption-ledger.yaml\n conformanceClaims: governance/evidence/conformance/baseline-conformance-claim.yaml\n consumptionLocks: governance/evidence/conformance/baseline-consumption-lock.yaml\n migrationWorkOrders: governance/evidence/migrations/baseline-migration-work-order.yaml\n migrationExecutionReceipts: governance/evidence/migrations/baseline-migration-execution-receipt.yaml\n localArtifactBoundary: governance/evidence/baselines/baseline-local-artifact-boundary.yaml\n auditExportExclusionManifest: governance/evidence/audit-export/audit-export-exclusion-manifest.yaml\n privateArtifactEscrowManifest: governance/evidence/baselines/private-artifact-escrow-manifest.yaml\n cleanRoomReconstructionReceipt: governance/evidence/baselines/baseline-clean-room-reconstruction-receipt.yaml\n evidenceArchiveReceipt: governance/evidence/baselines/baseline-evidence-archive-receipt.yaml\n signatureLtvReceipt: governance/evidence/baselines/baseline-signature-ltv-receipt.yaml\n runtimeAdmissionReceipt: governance/evidence/baselines/baseline-runtime-admission-receipt.yaml\n runtimeAdmissionDecisionLedger: governance/evidence/baselines/baseline-runtime-admission-decision-ledger.yaml\n continuousControlMonitoringLedger: governance/evidence/baselines/baseline-continuous-control-monitoring-ledger.yaml\n controlAssuranceSamplingLedger: governance/evidence/baselines/baseline-control-assurance-sampling-ledger.yaml\n controlInheritanceLedger: governance/evidence/baselines/baseline-control-inheritance-ledger.yaml\n dataResidencyTransferLedger: governance/evidence/baselines/baseline-data-residency-transfer-ledger.yaml\n thirdPartyRiskLedger: governance/evidence/baselines/baseline-third-party-risk-ledger.yaml\n operationalResilienceLedger: governance/evidence/baselines/baseline-operational-resilience-ledger.yaml\n secureConfigurationPostureDriftLedger: governance/evidence/baselines/baseline-secure-configuration-posture-drift-ledger.yaml\n productionChangeReleaseLedger: governance/evidence/baselines/baseline-production-change-release-ledger.yaml\n incidentProblemCorrectiveActionLedger: governance/evidence/baselines/baseline-incident-problem-corrective-action-ledger.yaml\n dataProductQualityContractObservabilityLedger: governance/evidence/baselines/baseline-data-product-quality-contract-observability-ledger.yaml\n engineeringQualityTestReleaseVerificationLedger: governance/evidence/baselines/baseline-engineering-quality-test-release-verification-ledger.yaml\n workforceCompetencyTrainingDutySegregationLedger: governance/evidence/baselines/baseline-workforce-competency-training-duty-segregation-ledger.yaml\n businessOutcomeValueRealizationPortfolioLedger: governance/evidence/baselines/baseline-business-outcome-value-realization-portfolio-ledger.yaml\n valueStreamJourneyProcessLedger: governance/evidence/baselines/baseline-value-stream-journey-process-ledger.yaml\n architectureViewRuntimeTopologyDependencyLedger: governance/evidence/baselines/baseline-architecture-view-runtime-topology-dependency-ledger.yaml\n qualityAttributeArchitectureDriverTradeoffLedger: governance/evidence/baselines/baseline-quality-attribute-architecture-driver-tradeoff-ledger.yaml\n architecturePrincipleConstraintExceptionLedger: governance/evidence/baselines/baseline-architecture-principle-constraint-exception-ledger.yaml\n versionPolicyReleaseControlLedger: governance/evidence/baselines/baseline-version-policy-release-control-ledger.yaml\n serviceReliabilitySloErrorBudgetObservabilityLedger: governance/evidence/baselines/baseline-service-reliability-slo-error-budget-observability-ledger.yaml\n backupRestoreDisasterRecoveryLedger: governance/evidence/baselines/baseline-backup-restore-disaster-recovery-ledger.yaml\n regulatoryObligationLedger: governance/evidence/baselines/baseline-regulatory-obligation-ledger.yaml\n cryptographicSecretsKeyCertificateLedger: governance/evidence/baselines/baseline-cryptographic-secrets-key-certificate-ledger.yaml\n assetCriticalityClassificationLedger: governance/evidence/baselines/baseline-asset-criticality-classification-ledger.yaml\n identityEntitlementAccessLedger: governance/evidence/baselines/baseline-identity-entitlement-access-ledger.yaml\n processingActivityInventoryLedger: governance/evidence/baselines/baseline-processing-activity-inventory-ledger.yaml\n privacyRightsConsentLedger: governance/evidence/baselines/baseline-privacy-rights-consent-ledger.yaml\n recordsRetentionLegalHoldLedger: governance/evidence/baselines/baseline-records-retention-legal-hold-ledger.yaml\n artifactInventory: governance/evidence/baselines/baseline-artifact-inventory.yaml\n verificationLock: governance/evidence/verification/baseline-verification-lock.yaml\n auditExportManifest: governance/evidence/audit-export/audit-export-manifest.yaml\n observedState:\n lifecycleStateMachine:\n lifecycleState: candidate\n documentVersion: V2.53\n baselineId: mea-v2.53-20260602\n releaseTag: architecture/v2.53-candidate\n sourceCommit: \n status: match\n versionGovernance:\n releaseChannel: candidate\n status: Baseline Candidate\n documentVersion: V2.53\n baselineId: mea-v2.53-20260602\n releaseTag: architecture/v2.53-candidate\n sourceCommit: \n status: match\n versionPolicyReleaseControlLedger:\n ledgerId: bvprc-20260603-mea-v293\n baselineId: mea-v2.93-20260603\n documentVersion: V2.93\n releaseChannel: candidate\n semverChangeLevel: minor\n conventionalCommitCoveragePercent: 100\n signedReleaseTagRequired: true\n floatingVersionReferences: 0\n tagDriftFindings: 0\n breakingChangesWithoutMigrationWindow: 0\n freezeWindowViolations: 0\n emergencyPatchesWithoutPostReview: 0\n revokedBaselinesStillAdopted: 0\n releaseGateReferences: 51\n status: match\n releaseEvidence:\n promotionFrom: candidate\n promotionTo: baseline\n documentVersion: V2.53\n baselineId: mea-v2.53-20260602\n releaseTag: architecture/v2.53-candidate\n status: match\n evidenceTraceGraph:\n graphId: betg-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n requiredNodesMissing: 0\n digestMismatches: 0\n danglingEdges: 0\n staleConsumers: 0\n status: match\n gateExecutionReport:\n reportId: bger-20260602-mea-v253-candidate-to-baseline\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n result: pass\n rulesExecuted: 51\n blockingFailures: 0\n replayResult: pass\n decisionMatchesExecution: true\n status: match\n regulatoryObligationLedger:\n ledgerId: brol-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n obligationsCovered: 64\n mandatoryObligations: 42\n obligationsMappedToControls: 64\n obligationsMappedToEvidence: 64\n unmappedMandatoryObligations: 0\n missingEvidenceForMandatoryObligation: 0\n unownedObligations: 0\n overdueRegulatoryChanges: 0\n overdueObligationPoam: 0\n result: pass\n status: match\n cryptographicSecretsKeyCertificateLedger:\n ledgerId: bcskcl-20260602-mea-v275\n baselineId: mea-v2.75-20260602\n documentVersion: V2.75\n cryptographicMaterialsCovered: 312\n kmsKeysCovered: 74\n hsmKeysCovered: 8\n tlsCertificatesCovered: 126\n signingKeysCovered: 18\n apiTokensCovered: 52\n databaseCredentialsCovered: 34\n workloadSecretsCovered: 68\n materialsWithOwners: 312\n plaintextProductionSecrets: 0\n expiredCertificates: 0\n overdueRotations: 0\n weakAlgorithms: 0\n missingRevocationPaths: 0\n openSecretLeaks: 0\n unmanagedSigningKeys: 0\n result: pass\n status: match\n assetCriticalityClassificationLedger:\n ledgerId: baccl-20260602-mea-v274\n baselineId: mea-v2.74-20260602\n documentVersion: V2.74\n assetsCovered: 214\n assetsWithOwners: 214\n criticalAssets: 28\n l3Assets: 42\n l4Assets: 12\n dataClassificationsComplete: true\n ciaImpactRatingsComplete: true\n conformanceProfileMismatches: 0\n unknownDataClassification: 0\n underclassifiedCriticalAssets: 0\n staleClassificationReviews: 0\n internetExposureUnclassified: 0\n aiRiskTierUnknown: 0\n result: pass\n status: match\n identityEntitlementAccessLedger:\n ledgerId: bieal-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n humanIdentitiesCovered: 560\n serviceAccountsCovered: 84\n workloadIdentitiesCovered: 62\n privilegedRolesCovered: 18\n jmlEventsReconciled: 43\n mfaCoveragePercent: 100\n pamJitRequestsReviewed: 27\n breakGlassEventsOpen: 0\n orphanedAccounts: 0\n staleEntitlements: 0\n workloadIdentityDrift: 0\n unreviewedPrivilegedAccess: 0\n result: pass\n status: match\n processingActivityInventoryLedger:\n ledgerId: bpail-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n processingActivitiesCovered: 88\n systemsMapped: 43\n dataProductsMapped: 24\n aiProductsMapped: 9\n personalDataCategoriesClassified: 126\n dataSubjectCategoriesDeclared: 12\n recipientsMapped: 34\n crossBorderTransfersMapped: 14\n retentionMappingsComplete: true\n activitiesWithOwners: 88\n unownedActivities: 0\n unclassifiedPersonalDataFindings: 0\n runtimeInventoryDrift: 0\n result: pass\n status: match\n privacyRightsConsentLedger:\n ledgerId: bprcl-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n processingPurposesCovered: 46\n purposesWithLawfulBasis: 46\n consentPreferencesTracked: 1200000\n withdrawalsPropagated: true\n openRightsRequests: 7\n overdueRightsRequests: 0\n unpropagatedPreferences: 0\n unknownLawfulBasis: 0\n unknownConsentState: 0\n automatedDecisionReviewGaps: 0\n thirdPartyPropagationGaps: 0\n result: pass\n status: match\n recordsRetentionLegalHoldLedger:\n ledgerId: brrl-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n recordClassesCovered: 38\n recordClassesWithRetentionSchedule: 38\n activeLegalHolds: 3\n deletionRequestsUnderHoldBlocked: true\n defensibleDeletionReceipts: 24\n orphanRecordClasses: 0\n overdueDisposals: 0\n overRetentionWithoutPurpose: 0\n result: pass\n status: match\n publishTransaction:\n transactionId: bpt-20260602-mea-v253-candidate\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n sourceCommit: \n releaseTag: architecture/v2.53-candidate\n remoteRefVerified: true\n protectedRefsVerified: true\n forbiddenLocalAssetsAbsentFromRemote: true\n postPublishVerification: pass\n status: match\n enforcementPolicy:\n policyId: bep-20260602-mea-v253\n minimumAcceptableBaseline: V2.52\n targetBaseline: V2.53\n unsupportedBaselineBlocked: true\n revokedOrEolBaselineBlocked: true\n conformanceClaimRequired: true\n expiredExceptionBlocked: true\n decisionLogDigest: sha256:\n status: match\n revocationRecord:\n revocationId: not-applicable\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n currentDisposition: not-revoked\n quarantineRequired: false\n revoked: false\n affectedReferences: 0\n newAdoptionBlocked: false\n status: not-applicable\n reviewBoardDecision:\n meetingScope: candidate-to-baseline\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n decision: approve-baseline\n quorumMet: true\n openDissentingOpinions: 0\n status: match\n supportMatrix:\n currentBaseline: V2.53\n supportState: active\n channel: candidate\n status: match\n eolRetirementCertificate:\n retiredBaseline: not-applicable\n requiredForCurrentTransition: false\n status: not-applicable\n releaseTrain:\n currentBaseline: V2.53\n plannedBaseline: V2.53\n releaseChannel: candidate\n targetChannel: baseline\n status: match\n adoptionLedger:\n targetBaseline: V2.53\n unknownTargets: 0\n overdueTargets: 0\n status: match\n conformanceClaims:\n claimedBaseline: V2.53\n expiredClaims: 0\n lowerThanMinimumAcceptedBaseline: 0\n status: match\n consumptionLocks:\n lockedBaseline: V2.53\n lockedBaselineId: mea-v2.53-20260602\n releaseTag: architecture/v2.53-candidate\n sourceCommit: \n expiredLocks: 0\n digestMismatches: 0\n floatingReferences: 0\n status: match\n migrationWorkOrders:\n targetBaseline: V2.53\n totalWorkOrders: 4\n completed: 4\n blocked: 0\n expired: 0\n missingAcceptanceEvidence: 0\n consumptionLocksUpdated: true\n rollbackActionsDefined: true\n status: match\n migrationExecutionReceipts:\n targetBaseline: V2.53\n totalReceipts: 4\n accepted: 4\n failed: 0\n missingCommandEvidence: 0\n beforeAfterDigestMismatches: 0\n rollbackVerificationMissing: 0\n status: match\n localArtifactBoundary:\n declaredLocalOnlyArtifacts: 7\n trackedLocalOnlyArtifacts: 0\n publishedLocalOnlyArtifacts: 0\n auditExportRawInclusions: 0\n signaturePayloadRawInclusions: 0\n status: match\n auditExportExclusionManifest:\n rawAllowlistEntries: 1\n digestOnlyEntries: 7\n forcedExclusions: 7\n signaturePayloadExclusions: 7\n missingBoundaryRefs: 0\n rawPayloadViolations: 0\n status: match\n privateArtifactEscrowManifest:\n escrowedArtifacts: 7\n missingStorageRefs: 0\n digestMismatches: 0\n restoreVerificationFailures: 0\n accessRolesReviewed: true\n retentionExpired: 0\n status: match\n cleanRoomReconstructionReceipt:\n runnerWorkspaceEmptyBeforeCheckout: true\n sourceCommitCheckedOut: true\n privateArtifactsRestored: 7\n restoredDigestMismatches: 0\n auditExportRebuilt: true\n gateReplayResult: pass\n forbiddenRemoteAssetsAfterRebuild: 0\n status: match\n evidenceArchiveReceipt:\n archivedObjects: 14\n immutableStorageRefs: 14\n retentionLockedObjects: 14\n legalHoldObjects: 14\n accessLogEnabled: true\n deleteProtectionEnabled: true\n archiveDigestMismatches: 0\n restoreDrillResult: pass\n status: match\n signatureLtvReceipt:\n signedSubjects: 4\n certificateChainsArchived: 4\n transparencyLogProofsArchived: 4\n signedEntryTimestampsVerified: 4\n rfc3161TimestampsVerified: 4\n revocationStatusRecorded: true\n ltvDigestMismatches: 0\n verificationToolchainPinned: true\n status: match\n runtimeAdmissionReceipt:\n clusterScope: prod-primary\n namespacesCovered: 14\n admissionControllerEnabled: true\n policyEngine: kyverno\n policyBundleDigestMatches: true\n enforcedPolicies: 8\n rejectSamplesExecuted: 6\n rejectSamplesPassed: 6\n unsignedImageRejected: true\n mutableTagRejected: true\n revokedBaselineRejected: true\n expiredExceptionRejected: true\n runtimeBypassFindings: 0\n status: match\n runtimeAdmissionDecisionLedger:\n ledgerId: bradl-20260602-mea-v262\n clusterScope: prod-primary\n sourceAuditPolicy: governance/policies/runtime-admission/kubernetes-audit-policy.yaml\n decisionSources:\n kubernetesAuditEvents: 128\n admissionWebhookResponses: 128\n kyvernoPolicyReports: 128\n opaDecisionLogs: 12\n sigstorePolicyControllerEvents: 6\n requestUidCoverage: 100\n allowDecisions: 122\n denyDecisions: 6\n rawLogDigestMismatches: 0\n missingRequestUids: 0\n missingPolicyRuleRefs: 0\n unsignedImageDenyLogsPresent: true\n revokedBaselineDenyLogsPresent: true\n expiredExceptionDenyLogsPresent: true\n retentionLocked: true\n status: match\n continuousControlMonitoringLedger:\n ledgerId: bccml-20260602-mea-v263\n monitoredControls: 48\n criticalControlsCovered: 48\n metricsSources:\n prometheus: true\n opentelemetry: true\n kubernetesAudit: true\n policyReports: true\n siem: true\n alertRulesConfigured: 48\n alertRulesFiring: 0\n openCriticalDrift: 0\n openHighDrift: 0\n staleEvidenceItems: 0\n mttdMinutesP95: 8\n mttrHoursP95: 6\n unassignedControlAlerts: 0\n monitoringWindowHours: 24\n status: match\n controlAssuranceSamplingLedger:\n ledgerId: bcasl-20260602-mea-v264\n independentAssessor: enterprise-assurance-team\n assessorIndependenceVerified: true\n controlsInPopulation: 48\n criticalControlsSampled: 48\n highControlsSampled: 24\n sampleMethod: risk-based-and-random\n testOfDesignPass: true\n testOfOperatingEffectivenessPass: true\n openCriticalFindings: 0\n openHighFindings: 0\n findingsClosedOrRiskAccepted: true\n oscalAssessmentResultsGenerated: true\n status: match\n controlInheritanceLedger:\n ledgerId: bcil-20260602-mea-v265\n inheritedControls: 18\n sharedControls: 22\n providerManagedControls: 10\n domainOwnedControls: 16\n consumerOwnedControls: 8\n unownedControls: 0\n expiredInheritanceEvidence: 0\n missingConsumerResponsibilities: 0\n invalidInheritanceClaims: 0\n openInheritanceExceptions: 0\n status: match\n dataResidencyTransferLedger:\n ledgerId: bdrtl-20260602-mea-v266\n regulatedDataClasses: 14\n assetsCovered: 32\n approvedProcessingRegions: 18\n crossBorderTransfers: 9\n transfersWithMechanism: 9\n transfersMissingSupplementalMeasures: 0\n unapprovedSubprocessors: 0\n unapprovedProcessingRegions: 0\n backupRegionViolations: 0\n logRegionViolations: 0\n vectorIndexRegionViolations: 0\n modelProviderRegionUnknown: 0\n deletionPropagationGaps: 0\n openResidencyExceptions: 0\n status: match\n thirdPartyRiskLedger:\n ledgerId: btprl-20260602-mea-v267\n suppliersCovered: 38\n criticalSuppliers: 12\n criticalSuppliersApproved: 12\n suppliersHandlingRegulatedData: 14\n supplierRecordsMissingContractControls: 0\n missingDpaOrSla: 0\n missingAuditRights: 0\n expiredAssuranceReports: 0\n missingExitPlans: 0\n concentrationThresholdBreaches: 0\n unapprovedCriticalSuppliers: 0\n openCriticalSupplierFindings: 0\n openSupplierPoamOverdue: 0\n supplierIncidentsOpen: 0\n status: match\n operationalResilienceLedger:\n ledgerId: borl-20260602-mea-v268\n importantBusinessServices: 9\n servicesWithApprovedImpactTolerance: 9\n servicesWithCurrentBia: 9\n endToEndDependencyMapsCurrent: 9\n severeButPlausibleScenarios: 18\n scenariosTested: 18\n scenariosWithinImpactTolerance: 18\n scenarioFailures: 0\n toleranceBreaches: 0\n criticalDependenciesUnowned: 0\n thirdPartyDependenciesUntested: 0\n aiDependenciesUntested: 0\n missingManualWorkarounds: 0\n missingCommunicationsPlans: 0\n openCriticalResilienceGaps: 0\n overdueResiliencePoam: 0\n boardOrRiskOwnerSignoff: true\n status: match\n threatModelAttackSurfaceRiskLedger:\n ledgerId: btmasr-20260602-mea-v279\n criticalAssetsCovered: 92\n criticalAssetsWithThreatModels: 92\n freshThreatModels: 92\n attackSurfacesInventoried: 92\n trustBoundariesMapped: 92\n dataFlowsMapped: 214\n highRiskDataFlowsWithoutMitigation: 0\n openCriticalAbuseCases: 0\n securityTestsLinkedToThreats: 92\n unsignedResidualRisks: 0\n overdueThreatModelReviews: 0\n releaseGateReferences: 92\n status: match\n vulnerabilityExposureRemediationLedger:\n ledgerId: bverm-20260602-mea-v280\n assetsCovered: 186\n scannerCoverageComplete: true\n findingsOpenCritical: 0\n findingsOpenHigh: 0\n kevFindingsOpen: 0\n internetExposedHighFindingsOpen: 0\n findingsWithOwners: \"100%\"\n findingsWithinSla: true\n remediationsRetested: 148\n staleScans: 0\n expiredExceptions: 0\n vexOrCsafStatusesRecorded: 74\n releaseGateReferences: 186\n status: match\n secureConfigurationPostureDriftLedger:\n ledgerId: bscpd-20260602-mea-v281\n assetsCovered: 186\n baselinesAssigned: 186\n postureChecksExecuted: 1248\n criticalConfigurationDriftsOpen: 0\n highConfigurationDriftsOpen: 0\n privilegedPodsWithoutException: 0\n publicStorageFindingsOpen: 0\n weakTlsFindingsOpen: 0\n auditLoggingDisabled: 0\n expiredConfigurationExceptions: 0\n remediationsRetested: 96\n releaseGateReferences: 186\n status: match\n productionChangeReleaseLedger:\n ledgerId: bpcrl-20260603-mea-v282\n productionChangesCovered: 142\n unregisteredProductionChanges: 0\n approvedChangeWindows: 142\n blackoutViolations: 0\n unresolvedChangeConflicts: 0\n databaseMigrationsRehearsed: 18\n featureFlagsWithKillSwitch: 39\n promptOrModelChangesEvaluated: 11\n rollbackPlansVerified: 142\n emergencyChangesPostReviewed: 4\n failedChangesOpen: 0\n changesLinkedToIncidents: 6\n doraMetricsUpdated: true\n releaseGateReferences: 142\n status: match\n incidentProblemCorrectiveActionLedger:\n ledgerId: bipcal-20260603-mea-v283\n incidentsCovered: 38\n majorIncidentsCovered: 6\n securityIncidentsCovered: 4\n privacyIncidentsCovered: 2\n aiIncidentsCovered: 3\n supplierIncidentsCovered: 2\n nearMissesCovered: 9\n unclassifiedIncidents: 0\n incidentsWithoutOwner: 0\n incompleteTimelines: 0\n missingRca: 0\n overdueCorrectiveActions: 0\n recurrencePreventionUnverified: 0\n runbookUpdatesMissing: 0\n alertUpdatesMissing: 0\n problemRecordsOpenPastDue: 0\n recurringIncidentsNotEscalated: 0\n requiredCommunicationsMissing: 0\n doraRecoveryMetricsUpdated: true\n releaseGateReferences: 38\n status: match\n dataProductQualityContractObservabilityLedger:\n ledgerId: bdpqco-20260603-mea-v284\n dataProductsCovered: 72\n contractsCurrent: 72\n dataProductsWithoutOwner: 0\n schemaDriftsOpen: 0\n qualityAssertionFailuresOpen: 0\n freshnessBreachesOpen: 0\n lineageGapsOpen: 0\n unauthorizedAiFeatureRagUsage: 0\n consumerNotificationsMissing: 0\n contractBreachesOpenPastSla: 0\n remediationRetestsMissing: 0\n dataQualityIncidentsOpen: 0\n releaseGateReferences: 72\n status: match\n engineeringQualityTestReleaseVerificationLedger:\n ledgerId: beqtrv-20260603-mea-v285\n assetsCovered: 148\n requirementsMapped: 148\n criticalTestSuitesPassed: 148\n contractTestsPassed: 96\n regressionSuitesPassed: 148\n releaseSmokeChecksPassed: 148\n coverageBreachesOpen: 0\n flakyTestsOpenPastSla: 0\n criticalDefectsOpen: 0\n highDefectsOpenWithoutAcceptance: 0\n defectRetestsMissing: 0\n testEnvironmentDriftOpen: 0\n testDataPolicyViolations: 0\n releaseGateReferences: 148\n status: match\n workforceCompetencyTrainingDutySegregationLedger:\n ledgerId: bwctds-20260603-mea-v286\n criticalRolesCovered: 96\n rolesWithFormalAssignment: 96\n rolesWithCurrentTraining: 96\n specializedTrainingCurrent: 96\n roleAcknowledgementsCurrent: 96\n onCallQualifiedRoles: 42\n approvalDelegationsCurrent: 18\n backupRolesAssigned: 96\n segregationOfDutiesViolationsOpen: 0\n toxicRoleCombinationsOpen: 0\n expiredDelegations: 0\n expiredCompetencyReviews: 0\n untrainedPrivilegedApprovers: 0\n releaseGateReferences: 96\n status: match\n businessOutcomeValueRealizationPortfolioLedger:\n ledgerId: bbovrp-20260603-mea-v287\n businessOutcomesCovered: 64\n outcomesWithOwners: 64\n valueHypothesesDefined: 64\n keyResultsMeasurable: 64\n beforeAfterBaselinesCaptured: 64\n adoptionEvidenceLinked: 64\n benefitsReviewed: 64\n benefitsRealized: 58\n benefitsAtRisk: 6\n stopOrScaleDecisionsRecorded: 64\n unitEconomicsExplained: 64\n unresolvedValueGaps: 0\n expiredBenefitReviews: 0\n releaseGateReferences: 64\n status: match\n valueStreamJourneyProcessLedger:\n ledgerId: vsjp-20260603-mea-v288\n valueStreamsCovered: 18\n criticalJourneysCovered: 42\n journeysWithOwners: 42\n currentProcessModels: 42\n stepTelemetryCoveragePercent: 100\n crossDomainHandoffsTraceable: 96\n openCriticalBottlenecks: 0\n unresolvedProcessExceptions: 0\n manualFallbacksExercised: 24\n improvementActionsOverdue: 0\n releaseGateReferences: 42\n status: match\n architectureViewRuntimeTopologyDependencyLedger:\n ledgerId: avrt-20260603-mea-v289\n architectureViewsCovered: 96\n currentViews: 96\n runtimeTopologiesCovered: 74\n declaredDependencies: 418\n observedDependencies: 431\n declaredObservedMismatches: 0\n unknownRuntimeCallsOpen: 0\n criticalDependenciesWithOwners: 128\n gitopsTopologyLinks: 74\n blastRadiusAssessmentsCurrent: 64\n dependencyDriftFindingsOpen: 0\n staleViews: 0\n releaseGateReferences: 96\n status: match\n qualityAttributeArchitectureDriverTradeoffLedger:\n ledgerId: qaad-20260603-mea-v290\n qualityScenariosCovered: 84\n highPriorityScenariosMeasured: 84\n architectureDriversMapped: 64\n sensitivityPointsIdentified: 36\n sensitivityPointsMonitored: 36\n tradeoffPointsRecorded: 28\n tradeoffsWithAdr: 28\n fitnessFunctionsDefined: 72\n fitnessFunctionsPassing: 72\n verificationEvidenceFresh: 84\n unresolvedTradeoffRisks: 0\n expiredScenarioReviews: 0\n releaseGateReferences: 84\n status: match\n architecturePrincipleConstraintExceptionLedger:\n ledgerId: apce-20260603-mea-v291\n baselineId: mea-v2.91-20260603\n documentVersion: V2.91\n mandatoryPrinciplesCovered: 42\n principlesWithOwners: 42\n constraintsDeclared: 86\n constraintsMachineDetectable: 86\n forbiddenPatternsMapped: 34\n policyGateMappings: 64\n openPrincipleViolations: 0\n violationsWithDisposition: 18\n activeExceptions: 4\n expiredExceptions: 0\n unsignedRiskAcceptances: 0\n principlesReviewedOnSchedule: 42\n releaseGateReferences: 42\n status: match\n capacityPerformanceCostEfficiencyLedger:\n ledgerId: bcpce-20260602-mea-v278\n criticalServicesCovered: 64\n criticalServicesWithCapacityForecasts: 64\n freshLoadTests: 64\n performanceBaselineBreaches: 0\n servicesWithRequestsLimits: 64\n autoscalingPoliciesDeclared: 58\n queueBacklogBreaches: 0\n databaseCapacityBreaches: 0\n budgetBreaches: 0\n unitEconomicsMeasured: 42\n anomalousCostsOpen: 0\n optimizationActionsOverdue: 0\n status: match\n serviceReliabilitySloErrorBudgetObservabilityLedger:\n ledgerId: bsrso-20260602-mea-v277\n criticalServicesCovered: 64\n criticalServicesWithSlos: 64\n measurableSlis: 192\n errorBudgetBreaches: 0\n criticalAlertsRoutedToOnCall: 64\n runbooksCurrent: 64\n syntheticJourneysCovered: 18\n metricCoverageGaps: 0\n logCoverageGaps: 0\n traceCoverageGaps: 0\n unownedCriticalAlerts: 0\n status: match\n backupRestoreDisasterRecoveryLedger:\n ledgerId: bbdr-20260602-mea-v276\n protectedAssets: 186\n criticalDataStoresCovered: 74\n immutableBackupsEnabled: 74\n offlineOrCrossAccountCopies: 61\n restoreDrillsInWindow: 74\n successfulRestoreDrills: 74\n rpoBreaches: 0\n rtoBreaches: 0\n backupIntegrityFailures: 0\n unprotectedCriticalDataStores: 0\n ransomwareIsolationGaps: 0\n overdueRestoreDrills: 0\n uncontrolledRestoreAccess: 0\n status: match\n auditExportManifest:\n documentVersion: V2.53\n baselineId: mea-v2.53-20260602\n exportDigest: sha256:\n status: match\n driftFindings:\n critical: []\n high: []\n medium: []\n low: []\n writeBack:\n versionGovernanceUpdated: true\n versionPolicyReleaseControlLedgerReconciled: true\n enforcementPolicyDecisionLogged: true\n consumptionLocksReconciled: true\n migrationWorkOrdersReconciled: true\n migrationExecutionReceiptsReconciled: true\n localArtifactBoundaryReconciled: true\n auditExportExclusionManifestReconciled: true\n privateArtifactEscrowManifestReconciled: true\n cleanRoomReconstructionReceiptReconciled: true\n evidenceArchiveReceiptReconciled: true\n signatureLtvReceiptReconciled: true\n runtimeAdmissionReceiptReconciled: true\n runtimeAdmissionDecisionLedgerReconciled: true\n continuousControlMonitoringLedgerReconciled: true\n controlAssuranceSamplingLedgerReconciled: true\n controlInheritanceLedgerReconciled: true\n dataResidencyTransferLedgerReconciled: true\n thirdPartyRiskLedgerReconciled: true\n operationalResilienceLedgerReconciled: true\n threatModelAttackSurfaceRiskLedgerReconciled: true\n vulnerabilityExposureRemediationLedgerReconciled: true\n secureConfigurationPostureDriftLedgerReconciled: true\n productionChangeReleaseLedgerReconciled: true\n incidentProblemCorrectiveActionLedgerReconciled: true\n dataProductQualityContractObservabilityLedgerReconciled: true\n engineeringQualityTestReleaseVerificationLedgerReconciled: true\n workforceCompetencyTrainingDutySegregationLedgerReconciled: true\n businessOutcomeValueRealizationPortfolioLedgerReconciled: true\n valueStreamJourneyProcessLedgerReconciled: true\n architectureViewRuntimeTopologyDependencyLedgerReconciled: true\n qualityAttributeArchitectureDriverTradeoffLedgerReconciled: true\n architecturePrincipleConstraintExceptionLedgerReconciled: true\n capacityPerformanceCostEfficiencyLedgerReconciled: true\n serviceReliabilitySloErrorBudgetObservabilityLedgerReconciled: true\n backupRestoreDisasterRecoveryLedgerReconciled: true\n assetCriticalityClassificationLedgerReconciled: true\n identityEntitlementAccessLedgerReconciled: true\n processingActivityInventoryLedgerReconciled: true\n privacyRightsConsentLedgerReconciled: true\n recordsRetentionLegalHoldLedgerReconciled: true\n regulatoryObligationLedgerReconciled: true\n releaseEvidenceDigestUpdated: true\n supportMatrixUpdated: true\n adoptionLedgerReconciled: true\n auditExportManifestUpdated: true\n decision:\n result: pass\n blockBaseline: false\n blockFrozen: false\n blockEmergencyPatch: false\n decisionRef: governance/control-plane/release-gate-decision.yaml\n gates:\n blockOnBaselineIdMismatch: true\n blockOnDocumentVersionMismatch: true\n blockOnReleaseTagMismatch: true\n blockOnLifecycleStateMismatch: true\n blockOnAuditExportStateMismatch: true\n requireWriteBackBeforePromotion: true\n```\n\n对账状态只能使用以下值：\n\n| 状态 | 含义 | 是否阻断 |\n| ---- | ---- | -------- |\n| `match` | 观测状态与期望状态一致 | 否 |\n| `drift` | 状态字段不一致，但可通过回写或重新生成证据修复 | 视严重度而定 |\n| `missing` | 必需账本或字段缺失 | 是 |\n| `stale` | 账本存在但引用旧版本、旧 tag、旧 digest 或旧状态 | 是 |\n| `conflict` | 两个以上权威账本给出互斥状态 | 是 |\n| `not-applicable` | 当前基线范围明确不需要该账本 | 否，但必须说明理由 |\n\n执行规则：\n\n1. `baseline-state-reconciliation-report.yaml` 必须在 `candidate -> baseline`、`baseline -> frozen`、`baseline -> emergency-patch`、`baseline -> superseded` 和 `superseded -> eol` 前生成。\n2. 对账输入至少覆盖生命周期状态机、版本控制面、基线准入执行策略、基线运行时准入回执、基线运行时准入决策总账、基线连续控制监测总账、基线独立控制保证抽样总账、基线共享责任与继承控制总账、基线数据驻留与跨境处理总账、基线第三方与关键供应商风险总账、基线运营韧性与重要业务服务影响容忍总账、基线生产变更、发布编排、变更冲突与失败恢复总账、基线事故、问题、纠正行动与复发防止总账、基线数据产品质量、契约违约、运行血缘与可观测性总账、基线工程质量、测试证据、缺陷与发布验证总账、基线人员能力、培训、职责履职与职责分离总账、基线业务结果、价值实现与组合收益总账、基线密码材料、密钥、证书与秘密生命周期总账、基线资产关键性、数据分类与风险分级总账、基线消费锁定文件、基线迁移工作单、基线迁移执行回执、本地私有制品边界、审计导出排除清单、私有制品托管交接清单、干净环境基线重建回执、基线证据不可变归档回执、基线长期验签回执、发布证据包、证据追踪图、门禁执行报告、发布事务回执、撤销隔离记录、会审裁决记录、发布列车、支持矩阵、EOL 退役证书、采纳总账、符合性声明、制品清单、验证锁和审计导出清单。\n3. `baselineId`、`documentVersion`、`releaseTag`、`sourceCommit` 和生命周期状态在任何权威账本中不一致时，必须阻断晋级。\n4. `releaseEvidence` 允许声明目标状态，例如 `candidate -> baseline`，但必须同时能证明当前状态仍来自状态机，不能把目标状态误当当前状态。\n5. `writeBack` 必须证明状态迁移后的版本控制面、基线准入执行策略、基线运行时准入回执、基线运行时准入决策总账、基线连续控制监测总账、基线独立控制保证抽样总账、基线共享责任与继承控制总账、基线数据驻留与跨境处理总账、基线第三方与关键供应商风险总账、基线运营韧性与重要业务服务影响容忍总账、基线生产变更、发布编排、变更冲突与失败恢复总账、基线事故、问题、纠正行动与复发防止总账、基线数据产品质量、契约违约、运行血缘与可观测性总账、基线工程质量、测试证据、缺陷与发布验证总账、基线人员能力、培训、职责履职与职责分离总账、基线业务结果、价值实现与组合收益总账、基线密码材料、密钥、证书与秘密生命周期总账、基线资产关键性、数据分类与风险分级总账、基线消费锁定文件、基线迁移工作单、基线迁移执行回执、本地私有制品边界、审计导出排除清单、私有制品托管交接清单、干净环境基线重建回执、基线证据不可变归档回执、基线长期验签回执、支持矩阵、EOL 退役证书、发布证据摘要、采纳总账和审计导出清单已经更新。\n6. 对账报告本身必须进入发布证据包摘要和审计导出包，不能只作为临时检查日志。\n7. 任何 `conflict`、`missing`、`stale`、准入策略执行失败、证据追踪图断链、门禁执行报告失败、重放失败、发布事务失败、撤销隔离状态冲突、远端 ref 不匹配、保护规则缺失或 critical/high drift 都必须进入 release gate 阻断、POA&M 或风险接受，不能被就绪总分覆盖。\n\n可执行验收标准：\n\n1. 任意基线晋级前都能找到一份对账报告，证明所有关键账本引用同一 baseline ID、版本、tag、commit 和状态。\n2. 任意状态漂移都能定位到具体账本、字段、期望值、观测值、严重度和修复动作。\n3. 任意发布证据包都能找到状态对账报告摘要，证明晋级判断使用的是同一组状态事实。\n4. 任意审计导出都能证明导出的状态与版本控制面、状态机和支持矩阵一致。\n5. 任意状态回写失败都会阻断下一次晋级，直到重新生成受影响账本和对账报告。\n6. 任意撤销、隔离或恢复裁决都能在状态对账报告中看到当前 disposition、受影响引用数、采纳阻断状态和审计归档状态。\n7. 任意运行入口准入结果都能在状态对账报告中看到最低基线、撤销/EOL、资产声明和例外到期的策略执行状态。\n8. 任意 L3 / L4 资产的基线消费锁都能在状态对账报告中看到锁定版本、baseline ID、source commit、release tag、关键摘要、过期状态和浮动引用检查结果。\n9. 任意 L3 / L4 资产的基线迁移都能在状态对账报告中看到工单总数、完成数、阻塞数、过期数、验收证据缺失数、消费锁更新状态和回滚动作定义状态。\n10. 任意 L3 / L4 资产的基线迁移执行都能在状态对账报告中看到回执总数、接受数、失败数、命令证据缺失数、before/after 摘要不一致数和回滚验证缺失数。\n11. 任意本地私有制品都能在状态对账报告中看到声明数、被跟踪数、被发布数、审计导出原文包含数和签名 payload 原文包含数。\n12. 任意审计导出排除清单都能在状态对账报告中看到原文白名单数量、摘要留存数量、强制排除数量、签名 payload 排除数量、缺失边界引用数和原文违规包含数。\n13. 任意私有制品托管交接清单都能在状态对账报告中看到托管资产数、缺失私有库引用数、摘要不一致数、权限复核状态、留存过期数和恢复验证失败数。\n14. 任意干净环境基线重建回执都能在状态对账报告中看到 runner 清洁状态、远端 checkout、私有制品恢复数、摘要不一致数、审计导出重建结果、门禁重放结果和禁推资产复核结果。\n15. 任意基线证据不可变归档回执都能在状态对账报告中看到归档对象数、不可变存储引用数、留存锁对象数、legal hold 对象数、访问日志状态、删除保护状态、摘要不一致数和恢复演练结果。\n16. 任意基线长期验签回执都能在状态对账报告中看到签名对象数、证书链归档数、透明日志 proof 数、signed entry timestamp、RFC3161 TSA、撤销状态、工具链锁定和长期验签摘要不一致数。\n17. 任意基线运行时准入回执都能在状态对账报告中看到集群范围、命名空间覆盖数、策略引擎、策略 bundle 摘要、拒绝样例执行数、拒绝样例通过数、未签名镜像阻断、可变 tag 阻断、撤销/EOL 基线阻断和 runtime bypass 发现数。\n18. 任意基线运行时准入决策总账都能在状态对账报告中看到 requestUID 覆盖率、allow/deny 数量、原始日志摘要错配数、缺失策略规则引用数、拒绝样例日志存在性和留存锁状态。\n19. 任意基线连续控制监测总账都能在状态对账报告中看到关键控制覆盖数、告警规则数、open critical/high drift、证据过期数、MTTD/MTTR 和未分配告警数。\n20. 任意基线独立控制保证抽样总账都能在状态对账报告中看到独立评估人、抽样方法、critical 控制样本覆盖、设计有效性、运行有效性、open critical/high findings 和 OSCAL Assessment Results 生成状态。\n21. 任意基线共享责任与继承控制总账都能在状态对账报告中看到 inherited/shared/provider/domain/consumer 控制数量、无 owner 控制数、过期继承证据数、缺失消费者义务数和无效继承声明数。\n22. 任意基线密码材料、密钥、证书与秘密生命周期总账都能在状态对账报告中看到密码材料覆盖数、owner 覆盖、明文秘密数、过期证书数、轮换超期数、弱算法数、缺失吊销路径数、开放泄露数和未托管签名密钥数。\n23. 任意基线资产关键性、数据分类与风险分级总账都能在状态对账报告中看到资产覆盖数、无 owner 资产数、L3/L4 资产数、CIA 影响缺失数、未知数据分类数、conformance profile 错配数、关键资产低估数、互联网暴露未分类数和 AI 风险未知数。\n24. 任意基线第三方与关键供应商风险总账都能在状态对账报告中看到关键供应商数、批准状态、合同控制、DPA/SLA、审计权、保证报告有效期、退出计划、集中度阈值、开放发现项、供应商事件和 POA&M 逾期状态。\n25. 任意基线运营韧性与重要业务服务影响容忍总账都能在状态对账报告中看到重要业务服务数、影响容忍批准状态、BIA 新鲜度、依赖图新鲜度、场景测试覆盖率、超限次数、未拥有关键依赖、开放 critical 韧性缺口和 POA&M 逾期状态。\n26. 任意基线工程质量、测试证据、缺陷与发布验证总账都能在状态对账报告中看到需求追踪覆盖、关键测试通过、覆盖率违约、flaky 测试、critical/high 缺陷、修复复测、测试环境漂移、测试数据违规和灰度/冒烟验证状态。\n27. 任意基线人员能力、培训、职责履职与职责分离总账都能在状态对账报告中看到关键角色覆盖、正式任命、培训完成、专项资格、职责确认、on-call 资格、审批授权、职责分离、冲突角色、代理授权、备份人员和过期复核状态。\n28. 任意基线业务结果、价值实现与组合收益总账都能在状态对账报告中看到业务目标覆盖、收益 owner、关键结果、前后基线、采用证据、收益实现、成本效率、未实现收益处置和停投/加投决策状态。\n\n### 10.10.23 基线 EOL 退役证书\n\n`baseline-eol-retirement-certificate.yaml` 是旧基线进入 EOL 前的最终退役证明。它不替代 `baseline-support-matrix.yaml`、\n`baseline-adoption-ledger.yaml` 或 `baseline-compatibility-ledger.yaml`；它负责证明支持矩阵里的 EOL 不是纸面状态，而是已经\n完成生产引用清零、迁移关闭、例外清零、证据归档和新采用阻断。\n\n```yaml\nbaselineEolRetirementCertificate:\n certificateId: berc-20260602-mea-v252-to-v253\n retiredBaselineId: mea-v2.52-20260602\n retiredDocumentVersion: V2.52\n successorBaselineId: mea-v2.53-20260602\n successorDocumentVersion: V2.53\n owner: architecture-governance-board\n issuedAt: 2026-06-02T16:30:00+08:00\n eolEffectiveAt: 2026-09-01T00:00:00+08:00\n inputs:\n lifecycleStateMachine: governance/evidence/baselines/baseline-lifecycle-state-machine.yaml\n stateReconciliation: governance/evidence/baselines/baseline-state-reconciliation-report.yaml\n enforcementPolicy: governance/control-plane/baseline-enforcement-policy.yaml\n evidenceTraceGraph: governance/evidence/baselines/baseline-evidence-trace-graph.yaml\n gateExecutionReport: governance/evidence/baselines/baseline-gate-execution-report.yaml\n publishTransaction: governance/evidence/baselines/baseline-publish-transaction.yaml\n revocationRecord: governance/evidence/baselines/baseline-revocation-record.yaml\n supportMatrix: governance/evidence/support/baseline-support-matrix.yaml\n adoptionLedger: governance/evidence/adoption/baseline-adoption-ledger.yaml\n compatibilityLedger: governance/evidence/compatibility/baseline-compatibility-ledger.yaml\n conformanceClaims: governance/evidence/conformance/baseline-conformance-claim.yaml\n exceptionLedger: governance/evidence/exceptions/baseline-exception-ledger.yaml\n notificationLedger: governance/evidence/communications/baseline-notification-ledger.yaml\n auditExportManifest: governance/evidence/audit-export/audit-export-manifest.yaml\n runtimeInventory: runtime/inventory/baseline-usage-report.yaml\n catalogInventory: catalog/reports/baseline-usage-report.yaml\n gitopsInventory: infra/gitops/reports/baseline-usage-report.yaml\n retirementScope:\n retiredChannels:\n - superseded\n - security-only\n - maintenance\n blockedChannelsAfterEol:\n - candidate\n - baseline\n - frozen\n - production\n affectedAssetClasses:\n - domains\n - services\n - data-products\n - ai-products\n - platform-capabilities\n - gitops-environments\n productionUsage:\n activeProductionReferences: 0\n unknownReferences: 0\n lowerThanMinimumAcceptedBaseline: 0\n evidence:\n catalogScanDigest: sha256:\n gitopsScanDigest: sha256:\n runtimeScanDigest: sha256:\n conformanceClaimDigest: sha256:\n migrationClosure:\n totalTargets: 128\n migratedTargets: 126\n decommissionedTargets: 2\n riskAcceptedTargets: 0\n openTargets: 0\n overdueTargets: 0\n adoptionLedgerClosed: true\n compatibilityLedgerClosed: true\n exceptionClosure:\n activeExceptions: 0\n expiredExceptions: 0\n blockingExceptions: 0\n riskAcceptedExceptions: 0\n exceptionLedgerClosed: true\n enforcement:\n newAdoptionBlocked: true\n baselineEnforcementPolicyUpdated: true\n runtimeAdmissionRejectsRetiredBaseline: true\n platformScaffoldRejectsRetiredBaseline: true\n catalogRegistrationRejectsRetiredBaseline: true\n gitopsPolicyRejectsRetiredBaseline: true\n releaseGateRejectsRetiredBaseline: true\n runtimeDriftAlertEnabled: true\n policyBundleDigest: sha256:\n evidenceRetention:\n archived: true\n archiveLocation: governance/archive/baselines/mea-v2.52-20260602/\n retainedUntil: 2031-09-01\n auditExportDigest: sha256:\n provenanceDigest: sha256:\n signatureReceiptDigest: sha256:\n rollbackPosture:\n directRollbackAllowed: false\n emergencyRecoveryRequiresNewBaseline: true\n lastRollbackVerification: governance/evidence/rollback/baseline-rollback-verification.yaml\n approvals:\n - role: architecture-governance-board\n decision: approve\n approvedAt: 2026-06-02T16:10:00+08:00\n - role: platform-lead\n decision: approve\n approvedAt: 2026-06-02T16:12:00+08:00\n - role: security-lead\n decision: approve\n approvedAt: 2026-06-02T16:15:00+08:00\n - role: audit-lead\n decision: approve\n approvedAt: 2026-06-02T16:20:00+08:00\n decision:\n result: retired\n blockEol: false\n decisionRef: governance/control-plane/release-gate-decision.yaml\n reviewBoardDecisionRef: governance/evidence/baselines/baseline-review-board-decision.yaml\n gates:\n blockIfActiveProductionReferencesGreaterThanZero: true\n blockIfUnknownReferencesGreaterThanZero: true\n blockIfOpenMigrationTargetsGreaterThanZero: true\n blockIfActiveExceptionsGreaterThanZero: true\n blockIfAuditArchiveMissing: true\n blockIfNewAdoptionNotRejectedByPolicy: true\n```\n\n退役状态只能使用以下值：\n\n| 状态 | 含义 | 是否允许进入 EOL |\n| ---- | ---- | ---------------- |\n| `pending` | 退役证据仍在收集中 | 否 |\n| `ready-to-retire` | 生产引用清零且等待审批 | 条件允许 |\n| `retired` | 已退役、已归档、已阻断新采用 | 是 |\n| `blocked` | 存在生产引用、开放迁移、活跃例外或归档缺失 | 否 |\n| `archived` | 退役后证据已进入长期留存库 | 是 |\n\n执行规则：\n\n1. `baseline-eol-retirement-certificate.yaml` 只服务于 `superseded -> eol`，不能用于跳过 `baseline -> superseded` 或 `frozen -> superseded`。\n2. 生产引用清零必须同时来自 catalog、GitOps、runtime inventory 和资产侧符合性声明，不能只依赖中央台账。\n3. `openTargets`、`overdueTargets`、`activeExceptions`、`expiredExceptions` 和 `unknownReferences` 任一大于 0，必须阻断 EOL。\n4. EOL 后不得允许新项目、平台脚手架、catalog 注册、GitOps 变更、runtime admission 或 release gate 继续声明退役基线；该阻断必须由 `baseline-enforcement-policy.yaml` 执行并记录。\n5. 退役证书必须进入基线准入执行策略、状态对账报告、支持矩阵、发布证据包和审计导出包；不能作为一次性检查日志留在 CI 输出里。\n6. 退役后的直接回滚默认禁止；确需恢复时必须生成新的 baseline ID、发布证据、状态机和风险接受记录。\n\n可执行验收标准：\n\n1. 任意 EOL 基线都能找到一份退役证书，证明支持矩阵、采纳总账、兼容性总账、catalog、GitOps 和 runtime 的使用状态一致。\n2. 任意生产资产都不能在 EOL 后继续声明退役基线；若发现引用，基线准入执行策略、release gate、runtime admission 和 drift gate 必须阻断。\n3. 任意审计人员都能看到迁移目标总数、完成数、退役数、风险接受数、开放数和逾期数。\n4. 任意退役基线都能证明审计导出、provenance、签名验签回执和关键证据已经归档到长期留存位置。\n5. 任意重新启用 EOL 基线的请求都必须被拒绝或转化为新基线流程，不能修改旧基线状态。\n\n### 10.10.24 基线会审裁决记录\n\n`baseline-review-board-decision.yaml` 是企业架构基线晋级、冻结、紧急补丁、替代和 EOL 前的独立会审裁决证据。它不替代\n`baseline-readiness-scorecard.yaml`、`baseline-release-evidence.yaml` 或 `release-gate-decision.yaml`；它负责证明关键 owner\n已经核验证据、表达意见、完成签署，并把反对意见、条件放行、风险接受和整改动作纳入闭环。\n\n```yaml\nbaselineReviewBoardDecision:\n decisionId: brbd-20260602-mea-v253-candidate-to-baseline\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n meetingScope: candidate-to-baseline\n requestedBy: architecture-governance-board\n chairedBy: chief-architect\n meetingAt: 2026-06-02T17:00:00+08:00\n decisionValidUntil: 2026-07-02T23:59:59+08:00\n quorumPolicy:\n minimumVotingRoles: 6\n mandatoryRoles:\n - architecture-governance-board\n - platform-lead\n - security-lead\n - data-governance-lead\n - sre-lead\n - audit-lead\n quorumMet: true\n evidenceReviewed:\n versionGovernance:\n path: governance/control-plane/version-governance.yaml\n digest: sha256:\n result: pass\n lifecycleStateMachine:\n path: governance/evidence/baselines/baseline-lifecycle-state-machine.yaml\n digest: sha256:\n result: pass\n stateReconciliation:\n path: governance/evidence/baselines/baseline-state-reconciliation-report.yaml\n digest: sha256:\n result: pass\n enforcementPolicy:\n path: governance/control-plane/baseline-enforcement-policy.yaml\n digest: sha256:\n result: pass\n evidenceTraceGraph:\n path: governance/evidence/baselines/baseline-evidence-trace-graph.yaml\n digest: sha256:\n result: pass\n gateExecutionReport:\n path: governance/evidence/baselines/baseline-gate-execution-report.yaml\n digest: sha256:\n result: pass\n publishTransaction:\n path: governance/evidence/baselines/baseline-publish-transaction.yaml\n digest: sha256:\n result: pass\n consumptionLock:\n path: governance/evidence/conformance/baseline-consumption-lock.yaml\n digest: sha256:\n result: pass\n revocationRecord:\n path: governance/evidence/baselines/baseline-revocation-record.yaml\n digest: sha256:\n result: not-applicable\n readinessScorecard:\n path: governance/evidence/baselines/baseline-readiness-scorecard.yaml\n digest: sha256:\n result: pass\n releaseEvidence:\n path: governance/evidence/baselines/baseline-release-evidence.yaml\n digest: sha256:\n result: pass\n exceptionLedger:\n path: governance/evidence/exceptions/baseline-exception-ledger.yaml\n digest: sha256:\n result: pass\n rollbackVerification:\n path: governance/evidence/rollback/baseline-rollback-verification.yaml\n digest: sha256:\n result: pass\n auditExport:\n path: governance/evidence/audit-export/audit-export-manifest.yaml\n digest: sha256:\n result: pass\n votes:\n - role: architecture-governance-board\n voter: chief-architect\n decision: approve\n signedAt: 2026-06-02T17:20:00+08:00\n signatureDigest: sha256:\n - role: platform-lead\n voter: platform-lead\n decision: approve\n signedAt: 2026-06-02T17:22:00+08:00\n signatureDigest: sha256:\n - role: security-lead\n voter: security-lead\n decision: approve\n signedAt: 2026-06-02T17:25:00+08:00\n signatureDigest: sha256:\n - role: data-governance-lead\n voter: data-governance-lead\n decision: approve\n signedAt: 2026-06-02T17:27:00+08:00\n signatureDigest: sha256:\n - role: sre-lead\n voter: sre-lead\n decision: approve-with-condition\n signedAt: 2026-06-02T17:30:00+08:00\n conditionRefs:\n - action-rollback-drill-refresh\n signatureDigest: sha256:\n - role: audit-lead\n voter: audit-lead\n decision: approve\n signedAt: 2026-06-02T17:35:00+08:00\n signatureDigest: sha256:\n dissentingOpinions:\n open: 0\n closed:\n - id: dissent-20260602-001\n raisedBy: finops-owner\n concern: AI cost allocation evidence expires within 14 days\n disposition: converted-to-required-action\n closedAt: 2026-06-02T17:18:00+08:00\n requiredActions:\n - id: action-rollback-drill-refresh\n owner: sre-lead\n dueAt: 2026-06-16T23:59:59+08:00\n action: refresh rollback drill evidence before frozen promotion\n blockingFor:\n - baseline-to-frozen\n evidenceRequired: governance/evidence/rollback/baseline-rollback-verification.yaml\n status: open\n riskAcceptance:\n required: false\n acceptedBy: null\n poamRefs: []\n finalDecision:\n result: approve-baseline\n canPromoteToBaseline: true\n canPromoteToFrozen: false\n blockReasons: []\n conditionRefs:\n - action-rollback-drill-refresh\n releaseGateDecision: governance/control-plane/release-gate-decision.yaml\n recordedAt: 2026-06-02T17:40:00+08:00\n```\n\n会审裁决结果只能使用以下值：\n\n| 结果 | 含义 | 是否允许晋级 |\n| ---- | ---- | ------------ |\n| `approve-baseline` | 同意进入 baseline | 是 |\n| `approve-frozen` | 同意进入 frozen | 是 |\n| `approve-quarantine` | 同意隔离基线 | 只允许进入 quarantined |\n| `approve-revocation` | 同意撤销基线 | 只允许进入 revoked |\n| `approve-with-condition` | 条件同意，必须有动作、owner 和到期日 | 视阻断范围而定 |\n| `defer` | 暂缓，等待补证或复审 | 否 |\n| `reject` | 拒绝晋级 | 否 |\n| `emergency-approve` | 紧急补丁临时同意 | 仅限紧急通道 |\n\n执行规则：\n\n1. `candidate -> baseline`、`baseline -> frozen`、`baseline -> emergency-patch`、`baseline/frozen -> superseded`、`baseline/frozen -> quarantined`、`quarantined -> revoked` 和 `superseded -> eol` 前必须形成会审裁决记录。\n2. 强制角色未投票、`quorumMet=false`、开放反对意见大于 0、基线准入执行策略未执行、基线消费锁定文件未核验、必需证据核验失败或裁决过期，必须阻断晋级。\n3. `approve-with-condition` 必须列出 `requiredActions`、owner、到期时间、阻断范围和补证路径；没有这些字段时不得放行。\n4. 任何反对意见不得只停留在会议纪要中，必须进入 `dissentingOpinions`，并关闭、转风险接受、转 POA&M 或转必需动作。\n5. 会审裁决摘要必须写入 `baseline-release-evidence.yaml`、基线准入执行策略、基线消费锁定文件、状态对账报告和审计导出包；不能只作为人工会议记录保存。\n6. 会审裁决超过 `decisionValidUntil` 后自动失效，必须重新核验证据并重新签署。\n\n可执行验收标准：\n\n1. 任意基线晋级都能找到会审裁决记录，证明参与角色、投票、签名、证据核验和最终裁决。\n2. 任意条件放行都能找到 owner、到期时间、阻断范围和补证路径。\n3. 任意反对意见都能看到提出人、关注点、处置方式和关闭证据。\n4. 任意审计人员都能判断会审结论是否仍在有效期内，以及是否足以支持 baseline、frozen、emergency patch、superseded 或 EOL。\n5. 任意会审裁决和发布证据包的 baseline ID、文档版本、source commit、release tag 和关键证据摘要必须一致。\n6. 任意会审裁决都能证明最低基线、撤销/EOL、资产声明和例外到期已经通过准入策略校验。\n\n### 10.10.25 基线证据追踪图\n\n`baseline-evidence-trace-graph.yaml` 是企业架构基线的跨证据引用图。它不替代状态对账、审计导出或发布证据包；它负责回答：\n“哪些证据节点存在、各节点摘要是什么、谁依赖谁、哪些下游已经消费、是否有旧摘要、断边、孤儿证据或未进入门禁的关键证据”。\n\n```yaml\nbaselineEvidenceTraceGraph:\n graphId: betg-20260602-mea-v253\n baselineId: mea-v2.53-20260602\n documentVersion: V2.53\n owner: architecture-governance-board\n generatedAt: 2026-06-02T18:10:00+08:00\n graphDigest:\n algorithm: sha256\n digestScope: exclude-self-digest-and-signature\n value: sha256:\n rootFacts:\n releaseChannel: candidate\n lifecycleState: candidate\n sourceCommit: \n releaseTag: architecture/v2.53-candidate\n tagSignatureVerified: true\n nodes:\n - id: baseline-evidence-trace-graph\n type: trace-graph\n path: governance/evidence/baselines/baseline-evidence-trace-graph.yaml\n digest: sha256:\n producer: architecture-governance-board\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n status: present\n consumedBy:\n - baseline-release-evidence\n - audit-export-manifest\n - audit-export-provenance\n - id: version-governance\n type: control-plane\n path: governance/control-plane/version-governance.yaml\n digest: sha256:\n producer: architecture-governance-board\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n status: present\n freshness:\n generatedAt: 2026-06-02T17:45:00+08:00\n maxAge: P30D\n expired: false\n consumedBy:\n - baseline-release-evidence\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - id: baseline-lifecycle-state-machine\n type: lifecycle\n path: governance/evidence/baselines/baseline-lifecycle-state-machine.yaml\n digest: sha256:\n producer: architecture-governance-board\n status: present\n consumedBy:\n - baseline-state-reconciliation-report\n - baseline-release-evidence\n - id: baseline-release-evidence\n type: release-evidence\n path: governance/evidence/baselines/baseline-release-evidence.yaml\n digest: sha256:\n producer: architecture-governance-board\n requiredFor:\n - candidate-to-baseline\n status: present\n consumedBy:\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - id: baseline-gate-execution-report\n type: gate-execution\n path: governance/evidence/baselines/baseline-gate-execution-report.yaml\n digest: sha256:\n producer: governance-platform\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - id: baseline-gate-negative-test-suite\n type: gate-negative-test-suite\n path: governance/evidence/baselines/baseline-gate-negative-test-suite.yaml\n digest: sha256:\n producer: governance-platform\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n status: present\n consumedBy:\n - baseline-gate-execution-report\n - baseline-release-evidence\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - id: baseline-publish-transaction\n type: publish-transaction\n path: governance/evidence/baselines/baseline-publish-transaction.yaml\n digest: sha256:\n producer: release-engineering\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - id: baseline-enforcement-policy\n type: admission-policy\n path: governance/control-plane/baseline-enforcement-policy.yaml\n digest: sha256:\n producer: governance-platform\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - id: baseline-consumption-lock\n type: consumption-lock\n path: governance/evidence/conformance/baseline-consumption-lock.yaml\n digest: sha256:\n producer: asset-owner\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n status: present\n freshness:\n generatedAt: 2026-06-02T17:58:00+08:00\n maxAge: P30D\n expired: false\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - baseline-adoption-ledger\n - audit-export-manifest\n - id: baseline-migration-work-order\n type: migration-work-order\n path: governance/evidence/migrations/baseline-migration-work-order.yaml\n digest: sha256:\n producer: asset-owner\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n status: present\n freshness:\n generatedAt: 2026-06-02T18:05:00+08:00\n maxAge: P30D\n expired: false\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - baseline-adoption-ledger\n - audit-export-manifest\n - id: baseline-migration-execution-receipt\n type: migration-execution-receipt\n path: governance/evidence/migrations/baseline-migration-execution-receipt.yaml\n digest: sha256:\n producer: governance-platform\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n status: present\n freshness:\n generatedAt: 2026-06-02T18:08:00+08:00\n maxAge: P30D\n expired: false\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - baseline-adoption-ledger\n - audit-export-manifest\n - id: baseline-revocation-record\n type: revocation-record\n path: governance/evidence/baselines/baseline-revocation-record.yaml\n digest: sha256:\n producer: architecture-governance-board\n requiredFor:\n - baseline-to-frozen\n - baseline-to-quarantined\n - frozen-to-quarantined\n - quarantined-to-revoked\n status: not-applicable\n consumedBy:\n - baseline-release-evidence\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - id: baseline-review-board-decision\n type: review-decision\n path: governance/evidence/baselines/baseline-review-board-decision.yaml\n digest: sha256:\n producer: architecture-governance-board\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - id: baseline-state-reconciliation-report\n type: reconciliation\n path: governance/evidence/baselines/baseline-state-reconciliation-report.yaml\n digest: sha256:\n producer: architecture-governance-board\n status: present\n consumedBy:\n - baseline-release-evidence\n - release-gate-decision\n - id: baseline-readiness-scorecard\n type: readiness\n path: governance/evidence/baselines/baseline-readiness-scorecard.yaml\n digest: sha256:\n producer: architecture-governance-board\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-review-board-decision\n - id: baseline-artifact-inventory\n type: artifact-inventory\n path: governance/evidence/baselines/baseline-artifact-inventory.yaml\n digest: sha256:\n producer: architecture-governance-board\n status: present\n consumedBy:\n - baseline-release-evidence\n - audit-export-manifest\n - id: baseline-local-artifact-boundary\n type: local-artifact-boundary\n path: governance/evidence/baselines/baseline-local-artifact-boundary.yaml\n digest: sha256:\n producer: architecture-governance-board\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - id: audit-export-exclusion-manifest\n type: audit-export-exclusion\n path: governance/evidence/audit-export/audit-export-exclusion-manifest.yaml\n digest: sha256:\n producer: governance-platform\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - audit-export-provenance\n - audit-export-signature-receipt\n - id: private-artifact-escrow-manifest\n type: private-artifact-escrow\n path: governance/evidence/baselines/private-artifact-escrow-manifest.yaml\n digest: sha256:\n producer: architecture-governance-board\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - audit-export-provenance\n - audit-export-signature-receipt\n - id: baseline-clean-room-reconstruction-receipt\n type: clean-room-reconstruction\n path: governance/evidence/baselines/baseline-clean-room-reconstruction-receipt.yaml\n digest: sha256:\n producer: governance-platform\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - audit-export-provenance\n - audit-export-signature-receipt\n - id: baseline-evidence-archive-receipt\n type: immutable-evidence-archive\n path: governance/evidence/baselines/baseline-evidence-archive-receipt.yaml\n digest: sha256:\n producer: governance-platform\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - audit-export-provenance\n - audit-export-signature-receipt\n - id: baseline-signature-ltv-receipt\n type: long-term-signature-validation\n path: governance/evidence/baselines/baseline-signature-ltv-receipt.yaml\n digest: sha256:\n producer: security-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - audit-export-provenance\n - audit-export-signature-receipt\n - baseline-evidence-archive-receipt\n - id: baseline-runtime-admission-receipt\n type: runtime-admission\n path: governance/evidence/baselines/baseline-runtime-admission-receipt.yaml\n digest: sha256:\n producer: governance-platform\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-runtime-admission-decision-ledger\n type: runtime-admission-decision-ledger\n path: governance/evidence/baselines/baseline-runtime-admission-decision-ledger.yaml\n digest: sha256:\n producer: governance-platform\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-runtime-admission-receipt\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-continuous-control-monitoring-ledger\n type: continuous-control-monitoring\n path: governance/evidence/baselines/baseline-continuous-control-monitoring-ledger.yaml\n digest: sha256:\n producer: governance-platform\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-control-assurance-sampling-ledger\n type: control-assurance-sampling\n path: governance/evidence/baselines/baseline-control-assurance-sampling-ledger.yaml\n digest: sha256:\n producer: independent-assurance-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-control-inheritance-ledger\n type: control-inheritance\n path: governance/evidence/baselines/baseline-control-inheritance-ledger.yaml\n digest: sha256:\n producer: architecture-governance-board\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-data-residency-transfer-ledger\n type: data-residency-transfer\n path: governance/evidence/baselines/baseline-data-residency-transfer-ledger.yaml\n digest: sha256:\n producer: privacy-governance-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-third-party-risk-ledger\n type: third-party-risk\n path: governance/evidence/baselines/baseline-third-party-risk-ledger.yaml\n digest: sha256:\n producer: third-party-risk-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-operational-resilience-ledger\n type: operational-resilience\n path: governance/evidence/baselines/baseline-operational-resilience-ledger.yaml\n digest: sha256:\n producer: operational-resilience-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-threat-model-attack-surface-risk-ledger\n type: threat-model-attack-surface-risk\n path: governance/evidence/baselines/baseline-threat-model-attack-surface-risk-ledger.yaml\n digest: sha256:\n producer: application-security-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-vulnerability-exposure-remediation-ledger\n type: vulnerability-exposure-remediation\n path: governance/evidence/baselines/baseline-vulnerability-exposure-remediation-ledger.yaml\n digest: sha256:\n producer: security-vulnerability-management-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-secure-configuration-posture-drift-ledger\n type: secure-configuration-posture-drift\n path: governance/evidence/baselines/baseline-secure-configuration-posture-drift-ledger.yaml\n digest: sha256:\n producer: platform-security-posture-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-production-change-release-ledger\n type: production-change-release\n path: governance/evidence/baselines/baseline-production-change-release-ledger.yaml\n digest: sha256:\n producer: release-engineering\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-incident-problem-corrective-action-ledger\n type: incident-problem-corrective-action\n path: governance/evidence/baselines/baseline-incident-problem-corrective-action-ledger.yaml\n digest: sha256:\n producer: sre-platform-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-data-product-quality-contract-observability-ledger\n type: data-product-quality-contract-observability\n path: governance/evidence/baselines/baseline-data-product-quality-contract-observability-ledger.yaml\n digest: sha256:\n producer: data-platform-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-engineering-quality-test-release-verification-ledger\n type: engineering-quality-test-release-verification\n path: governance/evidence/baselines/baseline-engineering-quality-test-release-verification-ledger.yaml\n digest: sha256:\n producer: quality-engineering-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-workforce-competency-training-duty-segregation-ledger\n type: workforce-competency-training-duty-segregation\n path: governance/evidence/baselines/baseline-workforce-competency-training-duty-segregation-ledger.yaml\n digest: sha256:\n producer: people-operations-governance-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-business-outcome-value-realization-portfolio-ledger\n type: business-outcome-value-realization-portfolio\n path: governance/evidence/baselines/baseline-business-outcome-value-realization-portfolio-ledger.yaml\n digest: sha256:\n producer: portfolio-governance-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-value-stream-journey-process-ledger\n type: value-stream-journey-process\n path: governance/evidence/baselines/baseline-value-stream-journey-process-ledger.yaml\n digest: sha256:\n producer: business-architecture-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-architecture-view-runtime-topology-dependency-ledger\n type: architecture-view-runtime-topology-dependency\n path: governance/evidence/baselines/baseline-architecture-view-runtime-topology-dependency-ledger.yaml\n digest: sha256:\n producer: enterprise-architecture-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-quality-attribute-architecture-driver-tradeoff-ledger\n type: quality-attribute-architecture-driver-tradeoff\n path: governance/evidence/baselines/baseline-quality-attribute-architecture-driver-tradeoff-ledger.yaml\n digest: sha256:\n producer: enterprise-architecture-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-architecture-principle-constraint-exception-ledger\n type: architecture-principle-constraint-exception\n path: governance/evidence/baselines/baseline-architecture-principle-constraint-exception-ledger.yaml\n digest: sha256:\n producer: enterprise-architecture-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-version-policy-release-control-ledger\n type: version-policy-release-control\n path: governance/evidence/baselines/baseline-version-policy-release-control-ledger.yaml\n digest: sha256:\n producer: release-engineering\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-emergency-patch\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-capacity-performance-cost-efficiency-ledger\n type: capacity-performance-cost-efficiency\n path: governance/evidence/baselines/baseline-capacity-performance-cost-efficiency-ledger.yaml\n digest: sha256:\n producer: sre-finops-platform-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-service-reliability-slo-error-budget-observability-ledger\n type: service-reliability-slo-error-budget-observability\n path: governance/evidence/baselines/baseline-service-reliability-slo-error-budget-observability-ledger.yaml\n digest: sha256:\n producer: sre-platform-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-backup-restore-disaster-recovery-ledger\n type: backup-restore-disaster-recovery\n path: governance/evidence/baselines/baseline-backup-restore-disaster-recovery-ledger.yaml\n digest: sha256:\n producer: sre-platform-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-regulatory-obligation-ledger\n type: regulatory-obligation\n path: governance/evidence/baselines/baseline-regulatory-obligation-ledger.yaml\n digest: sha256:\n producer: compliance-governance-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-cryptographic-secrets-key-certificate-ledger\n type: cryptographic-secrets-key-certificate\n path: governance/evidence/baselines/baseline-cryptographic-secrets-key-certificate-ledger.yaml\n digest: sha256:\n producer: security-cryptography-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-asset-criticality-classification-ledger\n type: asset-criticality-classification\n path: governance/evidence/baselines/baseline-asset-criticality-classification-ledger.yaml\n digest: sha256:\n producer: architecture-governance-board\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-identity-entitlement-access-ledger\n type: identity-entitlement-access\n path: governance/evidence/baselines/baseline-identity-entitlement-access-ledger.yaml\n digest: sha256:\n producer: security-identity-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-processing-activity-inventory-ledger\n type: processing-activity-inventory\n path: governance/evidence/baselines/baseline-processing-activity-inventory-ledger.yaml\n digest: sha256:\n producer: privacy-governance-team\n requiredFor:\n - candidate-to-baseline\n - baseline-to-frozen\n - baseline-to-quarantined\n - superseded-to-eol\n status: present\n consumedBy:\n - baseline-release-evidence\n - baseline-gate-execution-report\n - baseline-review-board-decision\n - baseline-state-reconciliation-report\n - audit-export-manifest\n - baseline-evidence-archive-receipt\n - id: baseline-privacy-rights-consent-ledger\n type: privacy-rights-consent\n path: governance/evidence/baselines/baseline-privacy-rights-consent-ledger.yaml\n digest: sha256: