分支：安全地改

为什么要分支：不打断正在用的那一份

前五节管读写数据的权限，从这一节起讲另一半：怎样安全地改本体（Ontology）本身。本体是大家正在用的：应用读它，工作流读它，智能体读它。直接改 main，改到一半的定义就会被读到。示例工厂的 approve-purchase-order 每天都有采购主管在用，改它的定义时，主管不该看到改了一半的表单。

分支解决这个问题：在一份副本上改，试完再并回去，副本上怎么折腾，main 都不受影响。开分支时会记下一个基线，就是当时 main 的语义版本。之后 main 可能被别人改动，分支要跟上，就得变基。智能体作者直接改 main 会得到 409 branch_required，只能走分支。

在分支上改、看、跟上

下面这组命令走完一条分支的前半程。设了 AIDC_AGENT_ID，命令的作者就记为这个智能体：

export AIDC_AGENT_ID=procurement-agent
aidc semantic branch create add-approver --description "采购订单增加批准人"
aidc semantic branch modify add-approver ./ontology --dry-run
aidc semantic branch modify add-approver ./ontology --expected-version 3
aidc semantic objects purchaseOrder --branch add-approver --page-size 5
aidc semantic branch validate add-approver

• --dry-run 只校验、不写入，先看会发生什么。
• --expected-version 保证你改的是你读到的那一版：别人先改过，就返回冲突，让你重新读。
• --branch 让读命令看到叠上分支改动之后的模型，在这里验证「这个问题现在答得出来了」。
• branch validate 给出合并检查的当前结果。

在示例工厂里，采购主管希望采购订单带上批准人。智能体不会直接改 purchaseOrder：它开分支，加一个属性 approverId，改 approve-purchase-order 的提交条件，再在分支上读几张订单，确认这个问题现在答得出来，然后才交给人。预览读的仍是同一份数据，只是定义换成了叠上分支改动之后的样子，数据不会被复制一份。

modify 提交的是一整份增删改清单，写进分支的同时返回校验结果。校验里每一项，合并之前都要通过。

冲突与变基

你在分支上改 purchaseOrder，同事在 main 上也改了它，这就是冲突：同一个资源，两边都动过。改的是不同资源，变基时自动并入；同一个资源两边都动过，没有自动解法，你必须选一边。

aidc semantic branch conflicts add-approver
aidc semantic branch rebase add-approver --keep purchaseOrder --take-main supplier

--keep 保留分支上的版本；--take-main 采用 main 的，丢掉你在这个资源上的分支改动。冲突没选完，变基不会通过。所以先看清 main 改了什么，再选。一条经验：分支活得越久，冲突越多，所以一件事一条分支，改完尽快提案。

生命周期与安全

不活跃的分支还在，但已经在往清理走。要冻结一条分支，比如提案正在审核，就把它锁上，锁定后不能再修改；改错了，可以放弃全部或指定资源的改动：

aidc semantic branch lock add-approver
aidc semantic branch lock add-approver --unlock
aidc semantic branch discard add-approver purchaseOrder

分支本身也要保护。官方里，分支有自己的角色（Owner 才能建提案、关提案）和所属的组织，不在其中的人看不到它；分支名可能在组织范围之外被看到，所以别把敏感信息写进分支名。