交互式 AUP 的首次呈现和后续更新不是同一件事。当前消息类型先发送完整 tree 的 render，随后用带 treeVersion 的 patch 增量更新。Web Device 的静态 HTML path 不需要把这个 interactive session pipeline 当作每个网页的前提。
当前 patch 的边界
一个 patch 由下列操作组成：
| 操作 | 作用 |
|---|---|
create | 在指定 parent 下创建 node |
update | 更新已有 node 的允许字段 |
remove | 移除 node |
reorder | 调整 children 顺序 |
当前 update 可改变 src、props、state、events、propBind 或 children。这解释了为何作者应使用稳定 id：patch 的目标是 node identity，而不是某段显示文本或渲染器的临时 DOM。
不要把这个列表当成所有 transport 细节永久不变的公共网络协议保证。本页把它作为 2.0.0-beta.25 的编写和调试模型；跨版本 client/server 组合时，仍须按实际 release compatibility 验证。
scene 与 capability 的职责
session 所在设备会在 handshake 报告能力和上下文。它影响同一语义 tree 是否以 native、webview、partial 或 fallback 的方式出现。AUP 的 shared degradation chain 只解决部分 primitive 的替换顺序；它不能代替场景、身份、AFS scope 或写权限的判断。
所以应把问题分开：
- “tree 是否更新到正确 node？”看 event 与 patch；
- “当前设备能否呈现该 primitive？”看
DeviceCaps与 degradation； - “这个操作是否有资格读取/写入路径？”看 caller identity 与 AFS scope；
- “网页是否得到静态 HTML？”看 Web Device 的 renderer/build 边界。
调试顺序
- 先用一个可见 node 的状态变化验证事件是否产生 patch。
- 在同一 session 验证页面导航仍使用
_root+set.page的当前形状。 - 再在第二个 target 上检查能力差异和 fallback。
- 单独运行静态 Web Device build，不把它的成功当成交互 session 的证明。