提案、评审与变更管理

提案：按资源分成任务

分支上的改动改完、验过，就开提案。它把改动按资源拆成任务，一个资源一个任务，每项单独批准或拒绝。review 交给人审；yolo 允许合格贡献者批准自己的改动。一个分支同一时间只有一个打开的提案。

规则很短，每一条都要紧：全部任务批准才能合并；任何一项被拒绝，整个提案就合并不了，要修改后重新审；提案打开之后，作者又改了某个资源，那一项回到待审。

aidc semantic branch propose add-approver \
  --title "采购订单增加批准人" \
  --trigger "采购主管要求批准前必须指定批准人，现有模型表达不出" \
  --self-test "分支上 purchaseOrder 已带批准人，approve-purchase-order 校验通过"
aidc semantic proposals --status OPEN
aidc semantic proposal <id>

提案尚未合并时，propose 打印审核地址。yolo 下合格作者的任务可自动批准，全部批准且检查通过就自动合并。平台附上改动、校验结果、影响面和破坏性改动。你填写触发原因与自测结果。

合并检查与破坏性确认

合并前平台校验定义、引用、主键、命名、数据源、webhook、安全、状态规则和冲突等。下面列出几个主要检查，不是完整清单：

1. 引用闭合

   改到的类型、属性、链接、Action 引用的东西都存在。

2. 名字唯一

   新名字不撞已有的。

3. 主键规则

   新的 Object Type 只有一个主键属性，且属性类型允许做主键。

4. 可编译

   定义能据此生成 Semantic 数据库里的视图。

5. 无冲突

   分支与 main 之间没有没解决的冲突。

6. 破坏性已确认

   破坏性任务已通过网页、CLI 或合格贡献者批准确认。

删类型或属性、改类型或主键、给 Action 删参数或加必填参数，都可能破坏下游应用。网页批准时输入资源名；CLI 用 aidc semantic proposal approve <id> --confirm-breaking。yolo 下合格贡献者的批准可以自动确认，并留下高风险审计记录。

确认之前，先问谁在用它。提案附上最近 30 天的读写次数、活跃用户和依赖应用。自动确认也不能代替影响分析，安全策略改动仍须满足相关 Markings。

批准与合并：review 与 yolo

review 是缺省策略，只接受本组织 developer 的网页登录；Key 不能审核或合并。yolo 还接受能改本体（Ontology）的开发者 Key，以及主体在本体上是 Editor 或 Owner 的非受限 Agent Key。受限 Agent Key 不能调用分支、提案接口。两种策略都不能跳过合并检查或 Markings。

review 下作者自己的批准不算数。yolo 下合格贡献者可批准自己改的资源；其他人改的任务仍待审核。安全策略任务还要满足改前、改后的相关 Markings。每次批准、驳回和合并都写审计。

合并之后：版本、迁移与清理

合并把分支上的改动落到 main，发一个新的语义版本，分支转为已合并，不能再恢复。语义版本只增不减，应用和日志里都带着它，出了问题能对上是哪一版。

破坏性改动最好分两步落地：先加新的，并行一段时间，等下游都改好，再在另一个提案里删旧的。官方的清理工具也是这个思路：先把不用的类型标为弃用并给出截止日期，让使用者有时间迁移，再删除，两步都和普通改动一样，可以交给提案评审。

aidc semantic branch modify retire-old-score ./ontology --archive oldSupplierScore
aidc semantic releases

active 构件不能直接归档。先改为 deprecated 或 experimental，定义或合并这次状态改动，再运行 --archive。归档是分支改动，经提案审核后才落到 main。review 要人审；yolo 接受合格 Key，破坏性改动仍需确认。releases 列出语义版本。