人怎么审

逐项审

上一节已开提案。review 下，在 /semantic 的 Proposals 页或审核地址，用本组织 developer 的网页登录逐项批准或拒绝。yolo 也接受有修改权限的开发者 Key，或主体在本体（Ontology）上是 Editor 或 Owner 的 Agent Key；合格贡献者可自动批准，检查通过后自动合并。

1. 读触发原因

   问题是真的吗？值得为它改本体吗？

2. 逐项对照定义

   每一项都能对照 main 上的定义和分支上的定义。改动对得上触发原因吗？名字对不对，有没有说明？

3. 看验证

   合并检查有没有失败；警告能不能接受；自测里没验证的部分记下来，合并后复核。

4. 看影响面和破坏性

   这些类型 30 天里谁在用，哪些应用登记了它们，有没有被标成破坏性。

任何一项被拒绝，整份提案都不能合并。智能体按备注改了分支，被改到的项回到待审。网页上可一次批准全部非破坏性项，破坏性项要逐项确认。示例工厂的 DeliveryPromise 提案两项都是新建，都不是破坏性，审完就能合并。

破坏性改动：确认影响

假设几周后，采购智能体要把 material.leadTimeDays 改名为 standardLeadTimeDays。改名涉及删旧属性、加新属性，是破坏性变更。先加新属性并迁移下游。旧属性须先改为 DEPRECATED 或 EXPERIMENTAL，落地后才能提交删除。

网页批准破坏性改动时，输入资源名 material。CLI 用 --confirm-breaking 确认。yolo 下，合格贡献者批准会自动确认破坏性改动，并记录高风险审计。确认前先核对影响面。

加Object Type、加属性、加同义词、加 Action 不需要这样确认。删类型、删属性、改属性类型、改主键，以及 Action 删参数或新增必填参数，才需要。

合并检查与合并

全部获有效批准后才能合并。平台会重跑合并检查。逐项核对实际结果，包括引用闭合、名字唯一、主键规则、可编译、无冲突、破坏性确认，以及数据源和状态检查。检查项不固定为六项。

review 由审核的人合并；yolo 检查通过后自动合并。提案记录（Changelog）逐步记下批准、拒绝、合并和语义版本。出了问题，可顺着记录核查。

main 变了怎么办：冲突与 rebase

分支开了几天，main 可能已经被别人改了。分支记着自己开出来时的版本，只有同一个资源两边都改过才算真冲突，别的改动会自动跟上。假设智能体在等审核时，又给分支补了一处：为 purchaseOrder 加了一句说明。而同一时间，同事在 main 上也改了 purchaseOrder 的说明：

aidc semantic branch conflicts delivery-promise
aidc semantic branch rebase delivery-promise --take-main purchaseOrder
# 或者保留分支上的版本：--keep purchaseOrder

--take-main 放弃分支上对这个资源的改动，采用 main 的；--keep 保留分支的。遇到真冲突，好的做法是智能体把两个版本和自己的建议写进提案说明，让审核的人拍板选哪一边。

别让分支闲着：35 天没有动静会转为不活跃，再过 7 天，分支上的改动被删除，打开着的提案也随之关闭。