diff --git a/docs/rpa-core-migration-guide-v2.md b/docs/rpa-core-migration-guide-v2.md
index 8d6f1b8..ea0b375 100644
--- a/docs/rpa-core-migration-guide-v2.md
+++ b/docs/rpa-core-migration-guide-v2.md
@@ -215,6 +215,8 @@
 - **改哪侧**：新建 adapter（AE 仓库内包）+ RPA 补元数据。
 - **方案**：①rpa-adapter 实现 CapabilityRunner：gateway.execute(lease, runner) → ref→componentId → 构造 RunContext（signal 直通）→ handler → 结果包装 ActionResult；②权限映射表按 34 域 × PermissionScope 初稿生成（files→filesystem.workspace、http→network.http、desktop/windowExtended→desktop.input/window、utilityExtended→独立高影响 scope【待确认：现表无 process 执行域对应，需对面确认】、message→messaging.send）；③高风险域标 highImpact 走审批（System_ExecuteCommand、键鼠、文件删除/覆盖、发消息）；④meta 增治理字段（与对面 CapabilityDefinition 字段对齐）。
 - **验收**：审批拒绝/租约过期/权限不在白名单时 handler **零调用**（gateway 已有测试语义，adapter 层加 719 全量冒烟：未经 authorize 不得触达 handler）；审计可关联 Agent/Run/Capability/审批结果。
+- **租约粒度拍板（2026-11-06 用户拍板：每个节点执行都要慎重）**：gateway 租约 TTL=60s（index.ts:124），而方案 A 整条流程可达数分钟——**解法定为"外层一个 step、内层每节点一次授权"**：流程内每个节点执行前由 adapter 单独走一次 authorize+execute（60s/节点绰绰有余），高危节点逐节点审批。与 A++ 检查点协议天配：事件负载的 `nodeId + idempotencyKey(runId:nodeId)` 正好构成 gateway 幂等键所需的作用域材料（workflow 来源要求 run+step+attempt，adapter 以 nodeId 充当 step 定位）。每节点授权同时天然实现"慎重"语义：任何节点执行前都过权限白名单+审批门，无绕行。
+- **版本管理设计提案（2026-11-06，adapter 层落地，不改引擎）**：对面版本约束为硬性三处——①每次调用必带 `capabilityVersion`，与注册表不符直接拒绝（gateway index.ts:171）；②幂等键含能力版本与配置版本；③插件 manifest 强制三段 semver（plugin-contract index.ts:277，`v1.0`/四段式均不通过）。我方现状：catalog 997/1016 项带上游四段版本（如 `App_Run@3.3.5.0`），但注册表无版本机制、包版本 0.1.0 从未随能力变化推进。提案：①对外能力 version = rpa-core 包 semver（0.1.0 起，仅对外行为变化才升版）；②catalog 四段版本归一化为三段后进 CapabilityDefinition（版本仅作标识，行为一致性由同包源码保证）；③configVersion 用 catalog+overrides 内容哈希（与幂等键 configVersion 段正好衔接）。**对迁包零影响**：catalog 版本字段原样迁移，归一化发生在 adapter 生成清单时。
 
 ### A5 Workflow Engine 执行契约
 
@@ -343,7 +345,8 @@
 | R4 | 浏览器双路径 | **按场景分工**：RPA 场景走咱们的 CDP 接管路线（复用用户登录态/真实页面——RPA 核心价值）；对面 PlaywrightBrowserRunner 留给 AI 智能体场景（无头自管浏览器）。约束：①咱们 CDP 路线必须接对面 BrowserContextPolicy 白名单与证据体系，不自建；②迁移前修完 transport 超时与定位器不统一两缺陷；③需对面在插件清单给咱们的 runner 备案（rpa.browser） |
 | R5 | 包消费方式 | **源码并入 + 锁版本**：git subtree 进对面仓库统一编译，Bun 锁 1.4.3（与对面全家 workspace:* 源码消费现状一致） |
 | R6 | 部署拓扑：rpa-core 各域跑在哪 | **按能力域拆分部署**：纯 Node 域→backend plugin-worker；桌面/视觉/弹窗域→用户电脑 Electron 宿主；同一包按 PLATFORM_GROUPS 分组加载，不维护两份代码。**补记（2026-11-06 用户拍板：双端并存+透明调度）**——同一能力本地/后端两驻地并存，SaaS 与本地部署两形态通用，用户无感知；防乱设计见下方专条 |
-| R2 | 集成形态：RPA 流程=单个 capability（方案 A）还是节点=step 映射（方案 B） | **方案 A + 两补丁**：RPA 流程=`rpa.flow.execute` 单能力，对面一个 step 一次租约一次结算；节点级事件走 event-bus 旁路（保透明、不进权威账本）；人审/高危节点照常升级对面审批。**不用 B 的理由**（记录在案）：双账本一致性（崩溃窗口两边分歧、破坏对面 recovery 的单账本假设）、控制流节点无副作用无法映射 CapabilityRef、审批/重试粒度与业务语义错位。**B 的触发条件**：对面产品确认需要"逐步控制 RPA"（单步执行/任意步回退）时局部启用，事件流已备好数据不返工。**A++ 补记（2026-11-06 二次拍板）**：方案 A 骨架不变，节点事件流从"透明度日志"升级为**检查点协议**（nodeId+状态+幂等键+可恢复标记），崩溃后 `rpa.flow.execute` 带 resumeToken 重入、从最近检查点续跑，权威账本仍为单 step、无双账本；B 的隐藏触发条件（长流程断点续跑，RPA 桌面场景高发）由此覆盖而无需节点=step。业界对照：UiPath Orchestrator=Job 黑盒+日志旁路（≈A）；Camunda/Zeebe External Task 的"单引擎假设"不适用于双引擎集成；AWS Step Functions callback≈补丁 2。两侧改动清单与落地节奏见 §7-A5 |
+| R2 | 集成形态：RPA 流程=单个 capability（方案 A）还是节点=step 映射（方案 B） | **方案 A + 两补丁**：RPA 流程=`rpa.flow.execute` 单能力，对面一个 step 一次租约一次结算；节点级事件走 event-bus 旁路（保透明、不进权威账本）；人审/高危节点照常升级对面审批。**不用 B 的理由**（记录在案）：双账本一致性（崩溃窗口两边分歧、破坏对面 recovery 的单账本假设）、控制流节点无副作用无法映射 CapabilityRef、审批/重试粒度与业务语义错位。**B 的触发条件**：对面产品确认需要"逐步控制 RPA"（单步执行/任意步回退）时局部启用，事件流已备好数据不返工。**A++ 补记（2026-11-06 二次拍板）**：方案 A 骨架不变，节点事件流从"透明度日志"升级为**检查点协议**（nodeId+状态+幂等键+可恢复标记），崩溃后 `rpa.flow.execute` 带 resumeToken 重入、从最近检查点续跑，权威账本仍为单 step、无双账本；B 的隐藏触发条件（长流程断点续跑，RPA 桌面场景高发）由此覆盖而无需节点=step。业界对照：UiPath Orchestrator=Job 黑盒+日志旁路（≈A）；Camunda/Zeebe External Task 的"单引擎假设"不适用于双引擎集成；AWS Step Functions callback≈补丁 2。两侧改动清单与落地节奏见 §7-A5。**租约粒度三次拍板（2026-11-06：每个节点执行都要慎重）**：外层单 step 不变，内层**每节点执行前单独 authorize+execute**（60s 租约/节点），高危节点逐节点审批——节点级治理粒度 + step 级账本粒度两全，实现方式见 §7-A4 |
+| V1 | 能力版本管理 | **adapter 层承接对面硬约束（2026-11-06 设计定稿）**：对面三处硬约束（调用必带 capabilityVersion 且不符即拒 / 幂等键含版本 / manifest 强制三段 semver）；我方 catalog 997 项带四段版本但注册表无版本机制。定案：对外能力 version=rpa-core 包 semver（仅对外行为变化才升版）；catalog 四段版本归一化三段；configVersion=catalog+overrides 内容哈希。详见 §7-A4；对迁包零影响 |
 
 ### 待对面对确认（仅剩小问题，不猜测）
 
@@ -351,6 +354,8 @@
 |---|---|---|
 | Q1 | CapabilityDefinition 是否需要 platform 字段（对面清单未见） | **本方设计提案（2026-11-06）**：对面 plugin-contract 增可选 `platforms?: readonly ("win32"\|"darwin"\|"linux")[]`，缺省=全平台（旧清单零破坏）；registry 的 `assertPluginManifest` 校验值域；plugin-worker 认领动作时按宿主 `process.platform` 过滤。RPA 侧清单由 rpa-adapter 从 catalog `platformTag` 自动生成，不手工维护第二份。与对面确认后照此实现 |
 | Q2 | utilityExtended（命令执行）对应哪个 PermissionScope | **本方设计提案（2026-11-06）**：utilityExtended 域在对面源码无同名物，属纯 RPA 侧概念。提案映射到 `desktop.process`——RPA 命令执行发生在用户电脑 Electron 宿主内，宿主即桌面进程，语义吻合；该域标 highImpact + idempotencyRequired 走审批。若对面认为 desktop.process 严格指"桌面进程管理"，备选新增 `desktop.command` scope。13 项 PermissionScope 其余映射维持 §7-A4 初稿 |
+| Q4 | 高危审批的"上游服务"成熟度 | gateway 只按 actionId 精确放行，注释明言"审批有效性判定（是否过期、是否本人审批）由上游负责"（capability-gateway index.ts:13-14），但该上游服务的实现与闭环未见。RPA 人审弹窗方案（human-dialog→requestApproval→绑定 actionId）依赖它，须确认其签发/过期/防代批机制现状 |
+| Q5 | 租户权限配置面 | 每租户/员工的 `allowedPermissions` 白名单由谁配置、走哪条链路（entitlement-contract / identity-store 成熟度），adapter 对接前须核一眼 |
 
 > 已回答：Q3（human-dialog 弹窗落点）已由 R6 回答——用户电脑 Electron 宿主窗口；仅样式/交互细节与对面 UI 对齐。