> 译文仅供阅读便利。具有规范效力的是英文原文。 # 变更流程 **元宇宙规范** **文档编号：** MU-V2-CONST-003 **标题：** 变更流程 **文档类别：** 规范性 **版本：** 2.0（草案） **状态：** 工作草案 **规范性引用：** 元宇宙宪章（MUC）、MMAS、MUFP **说明性引用：** Governance.md、Conformance.md **版权：** © Orkestron.AI **许可：** Apache-2.0 --- # 1. 目的 本文档规定元宇宙标准族演进所依据的规范性流程。 目标是在保持长期稳定性、互操作性与可追溯性的同时，实现持续改进。 --- # 2. 适用范围 本流程适用于元宇宙标准族内的所有规范性规范，包括： - 元宇宙宪章（MUC） - 元模型架构标准（MMAS） - 元宇宙联邦协议（MUFP） - 未来的规范性扩展 --- # 3. 指导原则 每一次变更都必须遵循以下原则： - 宪章先于实现。 - 显式优于隐式。 - 设计即可追溯。 - 在可行时保持向后兼容。 - 透明。 - 社区评审。 - 带版本的演进。 - 不做悄无声息的语义变更。 --- # 4. 变更生命周期 每一次变更都必须经过以下生命周期： 1. 提案 2. 讨论 3. 影响分析 4. 规范草案 5. 评审 6. 批准 7. 发布 8. 采用 9. 标记为废弃（可选） 10. 退役（可选） 对于规范性变更，任何阶段都不得被跳过。 --- # 5. 变更请求（CR） 每一项拟议修改都必须以变更请求（CR）的形式呈现。 变更请求应当包含： - 唯一标识符； - 标题； - 动机； - 受影响的文档； - 理由； - 预期收益； - 兼容性评估； - 迁移考量； - 对实现的影响； - 作者； - 日期。 --- # 6. 变更类别 变更应当归入以下类别之一： ### 编辑性 格式、措辞与澄清，不改变语义。 ### 纠正性 修正缺陷或歧义。 ### 演进性 保持兼容的新能力。 ### 破坏性 有意打破兼容的语义变更。 破坏性变更必须要求明确的论证。 --- # 6a. 语义变更分类 第 6 节中「编辑性 / 纠正性 / 演进性 / 破坏性」这条轴描述的是变更的**影响**。它应当由第二条轴来补充，用以描述变更的**语义对象**，也就是*哪一类含义受到影响*。这第二条轴就是**语义变更分类**。 对规范性规则库的变更还必须通过合并前的[策略一致性检查](../02-architecture/Policy-Consistency.md)：若某项变更会使规则集在逻辑上不可满足，则该变更不得被合并。 每一份变更请求都应当声明一种或多种语义变更类型： - **模型结构变更** - 改变元模型的结构（对象、关系、事件、定义的形态）。 - **含义/语义变更** - 改变既有概念的含义，而不一定改变其结构。 - **联邦规则变更** - 改变主权宇宙如何联邦、联邦档案的规则或协议保障。 - **契约变更** - 改变语义契约：目的、权限、责任或披露条件。 - **投影行为变更** - 改变对象在给定上下文中如何被投影。 - **合规要求变更** - 改变在任一级别上符合某项标准所需满足的条件。 两条轴彼此正交：一次变更同时带有一个影响类别和一种或多种语义变更类型（例如一次*演进性*/*模型结构变更*，或一次*破坏性*/*含义、语义变更*）。 明确声明语义类型，使人工智能代理能够就变更进行推理。代理应当能够读取一份变更请求，判定其语义变更类型，针对受影响文档评估由此产生的兼容性影响，并在兼容性无法保持时提出迁移步骤。因此，机器可读的分类把变更管理从纯人工评审变成了可分析、可半自动化的流程。 --- # 7. 兼容性评估 每一份变更请求都必须包含兼容性评估。 可能的结论包括： - 完全兼容 - 向后兼容 - 向前兼容 - 需要迁移 - 破坏性 --- # 8. 冻结规则 已批准的文档进入冻结状态。 冻结的文档： - 成为规范性引用； - 不得接受悄悄的修改； - 只能通过已发布的变更请求改动； - 必须保留完整的修订历史。 --- # 9. 版本管理 每一份已发布的规范都必须声明其版本。 新版本必须以发布的方式产生，而不是替换先前的规范性发布。 历史版本应当保持公开可得。 --- # 10. 废弃 功能可以在被移除之前先被标记为废弃。 废弃通知应当写明： - 受影响的功能； - 替代方案； - 标记废弃的版本； - 计划移除的版本。 任何破坏性移除之前，都应当先行标记废弃。 --- # 11. 迁移 每当兼容性无法保持时，新规范都必须附带迁移指引。 迁移指引应当包含： - 受影响的概念； - 所需的转换； - 兼容性策略； - 示例。 --- # 12. 发布 每一个已发布版本都必须包含： - 版本号； - 发布日期； - 状态； - 变更摘要； - 兼容性声明； - 规范性引用。 --- # 13. 可审计性 每一份规范性文档的演进都必须保持可审计。 必须能够确定： - 变更为何发生； - 由谁提出； - 何时被接受； - 由哪个版本引入。 --- # 未来方向 本文档确定的是语义变更分类的*宪法*形态：变更类型本身，以及必须声明它们这一要求。**详细模型**属于元模型架构标准（MMAS）：语义变更类型的形式化分类法、它们精确的兼容性规则，以及让人工智能代理得以计算兼容性影响并生成迁移的机器可读模式。未来的语义迁移标准（SMS）将在该分类法之上，规范迁移如何被表达与应用。宪章确立这条轴；MMAS 让它可以运转。 --- # 终极原则 元宇宙通过透明、带版本、可追溯的变更而演进。 稳定并非靠阻止演进来维持，而是靠让每一次演进都显式、可评审、可复现。