docs: V2 拍板 R1/R4/R5，R2 留评审并备好 A/B 对比与待答问题清单
This commit is contained in:
yu
parent
b4aaba4dbe
commit
b14ad0b89b
@ -17,9 +17,12 @@
|
||||
4. **两条硬边界不变且加严**（用户红线）：
|
||||
- 所有带副作用的能力必须经 capability-gateway（授权→租约→幂等→执行→审计），**不得绕行**；
|
||||
- rpa-core **不得依赖 Electron 主进程**（当前仍有 5 处动态 import，是接入阻塞项）。
|
||||
5. **6 项 ADR 中最关键的 2 项已拍板（2026-11-06）**，其余 4 项带去对面对评审（见 §10）：
|
||||
- **✅ 已拍板 ADR-R3 桌面执行安全模型冲突**：RPA 驱动原为 spawn 任意 PowerShell 脚本，与对面"受信 C# 原生进程 + `*.exe` 白名单 + 明文约束不执行任意 PowerShell"正面冲突。决定：**接受 C# 路线**——把 RPA 五域执行逻辑移植进 windows-runner 原生进程（扩展 actuate 半边），PowerShell 通道仅限本 demo 使用。
|
||||
- **✅ 已拍板 ADR-R6 部署拓扑**：服务器没有鼠标/键盘/屏幕，桌面与视觉能力物理上无法在 backend 跑（对面 windows-runner 同样留宿主）。决定：**按能力域拆分部署**——纯 Node 域进 backend plugin-worker，桌面/视觉/弹窗域装进用户电脑的 Electron 宿主，同一份 rpa-core 按 PLATFORM_GROUPS 分组加载，不维护两份代码。
|
||||
5. **6 项 ADR 已拍板 5 项（2026-11-06）**，仅 R2（集成形态）带问题清单去对面对评审，详见 §10。已定基调：
|
||||
- **R3 桌面执行**：C# 路线——五域执行逻辑移植进 windows-runner 原生进程，PowerShell 通道仅限本 demo。
|
||||
- **R6 部署拓扑**：按能力域拆分——纯 Node 域进 backend plugin-worker，桌面/视觉/弹窗域装用户电脑 Electron 宿主，同一包按分组加载。
|
||||
- **R1 能力清单**：全局一份，权限隔离全交对面网关按租户管。
|
||||
- **R4 浏览器**：按场景分工——RPA 场景用咱们 CDP 接管（复用登录态/真实页面），对面 Playwright 留给 AI 智能体；白名单与证据共用对面一套。
|
||||
- **R5 消费方式**：源码 git subtree 并入对面仓库统一编译，Bun 锁 1.4.3。
|
||||
|
||||
---
|
||||
|
||||
@ -236,9 +239,9 @@
|
||||
- **AE 位置**：`browser-plugin`（PlaywrightBrowserRunner 已实现：白名单三重检、AbortSignal 透传、证据 SHA-256；定位 css/aria/text，无 xpath）。
|
||||
- **兼容性**：双实现并行，语义不同（Playwright 自管浏览器 vs RPA 接管用户已开浏览器/复用登录态）。
|
||||
- **问题**：重复投资；RPA CDP 链路自身有 P1 缺陷；对面定位器无 xpath（RPA 拾取器产出 xpath/css/aria/text 混合 selector）。
|
||||
- **改哪侧**：ADR-R4 决策后双向小改。
|
||||
- **方案**：**宿主动作默认走对面 browser-plugin**（复用底座原则）；RPA 浏览器能力作为**第二 Runner** 后迁，迁前先修 transport 超时 + 统一 resolveElement（一次修复覆盖 locate/click/type/getText）；若保留 RPA 路径，域名白名单必须接同一份 BrowserContextPolicy（不得自建白名单）。
|
||||
- **验收**：同一定位用例集（css/aria/text/[xpath 视决策]）在所选路径上全部通过；白名单拒绝 URL 时导航前即拦截；证据落 evidence-store。
|
||||
- **改哪侧**：ADR-R4 已拍板（按场景分工）：RPA 场景走咱们 CDP 接管（主力），对面 Playwright 留给 AI 智能体场景。
|
||||
- **方案**：①RPA 浏览器能力迁前先修 transport 单命令超时 + 统一 resolveElement（一次修复覆盖 locate/click/type/getText）；②CDP 接管路线接对面 BrowserContextPolicy 白名单与证据体系（不自建白名单）；③与对面确认 rpa.browser 插件清单承载咱们的 runner；④PlaywrightBrowserRunner 保持现状服务 AI 智能体场景，双方不重复投资。
|
||||
- **验收**：同一定位用例集（css/aria/text/xpath）在咱们 CDP 路径全部通过；白名单拒绝 URL 时导航前即拦截（走对面策略对象）；证据落 evidence-store。
|
||||
|
||||
### A8 平台适配（Windows / Linux / macOS）
|
||||
|
||||
@ -278,11 +281,11 @@
|
||||
|
||||
| 阶段 | 内容 | 前置 | 验收门 |
|
||||
|---|---|---|---|
|
||||
| **0 事实确认**（双侧，1 次评审会） | 过 §10 剩余 4 项 ADR（R3/R6 已拍板）+ 3 项 Q；对面确认 CapabilityDefinition 平台字段、utilityExtended 对应 scope；同步 R3/R6 结论给对面并预估 C# actuate 扩展量 | 无 | ADR 有书面结论 |
|
||||
| **0 事实确认**（双侧，1 次评审会） | 评审 R2（带方案 A/B 对比与三项待答问题）+ 3 项 Q；对面确认 CapabilityDefinition 平台字段、utilityExtended 对应 scope；同步已拍板 5 项结论（R1/R3/R4/R5/R6）给对面并预估 C# actuate 扩展量 | 无 | R2 与 Q 有书面结论 |
|
||||
| **1 RPA 侧收口**（本仓库） | A3 四件（取消贯通/状态映射/重试元数据/Graph Validator）+ A1 注入参数 + A9（Electron 残留、check-deps 升级、依赖闭包）+ A2 的 ADR 固化 + catalog 脏值清洗 + rpa-cli 重写（显式注册、经 engine 取 handler） | 无 | 审查报告 §7 第一/二阶段清单全绿；纯 Node 环境 Core 全量加载 |
|
||||
| **2 迁入与 adapter 骨架** | git subtree 迁包改名 @agent-worker/rpa-core；bun@1.4.3 test 冒烟（exceljs/pdf/PowerShell 编码）；新建 @agent-worker/rpa-adapter（CapabilityRunner + ref 映射 + 状态映射表）；demo 侧冻结 | 阶段 1 + ADR-R1/R2 | bun test 纯逻辑全绿；未经 gateway 不可达 handler；719 映射完整性测试 |
|
||||
| **3 垂直切片** | 一个文件能力 + 一个 HTTP 能力走通：workflow-engine create/start → gateway authorize → adapter → rpa-core handler → 事件/证据回传 → cancel 中途取消；方案 A（rpa.flow.execute 整体注册） | 阶段 2 | 取消/审批/审计全链有证据；对面 Run 终态与 RunResult 一致 |
|
||||
| **4 浏览器与桌面双 ADR 落地** | ADR-R4：宿主动作切 browser-plugin，RPA 浏览器能力修完 transport/resolver 后作为第二 runner 接入；ADR-R3：windows-runner C# 扩展 actuate（RPA 五域逻辑移植） | 阶段 3 | §7-A6/A7 验收条目 |
|
||||
| **4 浏览器与桌面双 ADR 落地** | ADR-R4（已拍板）：RPA 浏览器能力修完 transport/resolver，接对面白名单与证据体系后作为 RPA 场景主力 runner；ADR-R3：windows-runner C# 扩展 actuate（RPA 五域逻辑移植） | 阶段 3 | §7-A6/A7 验收条目 |
|
||||
| **5 能力规模化** | 34 域按风险分批：files/data/http/ftp → office/excel/word（COM 仅 win32）→ desktop/utility 高影响（末批+审批）；CapabilityDefinition 与权限映射随批生成 | 阶段 4 | 每批过 gateway 全量冒烟 + 审批矩阵抽查 |
|
||||
| **6 平台扩展** | V1 第三节三端计划原样生效（Linux/macOS 驱动按 ADR-R3 原生通道） | 阶段 5 | 三平台 CI 矩阵；产品按 platformTag 置灰 |
|
||||
|
||||
@ -299,7 +302,7 @@
|
||||
| R1 | ~~桌面安全模型冲突~~ → **已缓解（ADR-R3 拍板 C# 路线）**：残余风险转为 C# 移植工作量与工期 | 中 | 阶段 0 与对面确认 actuate 扩展量；RPA 五域逻辑先行整理成移植清单 |
|
||||
| R2 | ~~部署拓扑错配~~ → **已缓解（ADR-R6 拍板按域拆分）**：残余风险为宿主进程加载子集的工程实现 | 中 | 阶段 2 按 PLATFORM_GROUPS 分组做宿主子集加载验证 |
|
||||
| R3 | Registry 全局单例在多租户 backend 的隔离缺陷 | 高 | 短期按 ADR-R1 限定部署模型；长期 engine-scoped registry 列入 backlog |
|
||||
| R4 | 浏览器双路径重复投资 | 中 | ADR-R4 一票定路径；未选路径冻结不投入 |
|
||||
| R4 | 浏览器双路径重复投资 | 低（已缓解） | R4 已拍板按场景分工（RPA=CDP 接管，AI 智能体=Playwright），白名单与证据共用一套，无重复投资 |
|
||||
| R5 | 719 能力的治理映射与元数据补齐工作量失控 | 中 | 脚本从 catalog 生成初稿 + 人工只审高风险域；分批（阶段 5） |
|
||||
| R6 | Bun 与 Node 行为差异（exceljs/pdf-lib/PowerShell 编码） | 中 | 阶段 2 bun 冒烟前置，差异清单化 |
|
||||
| R7 | demo 侧与 backend 双活跃漂移 | 中 | git subtree + "迁移后 demo 冻结"纪律（V1 决策 3） |
|
||||
@ -328,20 +331,23 @@
|
||||
|
||||
| ADR | 问题 | 决定 |
|
||||
|---|---|---|
|
||||
| R1 | Registry 作用域：backend 是否多租户并存 | **全局一份能力清单**（菜单所有租户共用），权限隔离完全由 capability-gateway 按租户管；长期将清单挂到 engine 实例（已从对面源码确认 WorkflowIdentity 带 tenantId，但清单本身无需按租户复制） |
|
||||
| R3 | 桌面执行安全模型：RPA PowerShell 驱动 vs 对面"受信 C# 原生进程"红线 | **C# 扩展 actuate**：把 RPA 五域执行逻辑移植进 windows-runner 原生进程；PowerShell 通道仅限本 demo，不进宿主 |
|
||||
| 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 分组加载，不维护两份代码 |
|
||||
|
||||
### 待对面对评审确认（不猜测）
|
||||
|
||||
| ADR | 问题 | 建议倾向 |
|
||||
| ADR | 问题 | 评审要点 |
|
||||
|---|---|---|
|
||||
| R1 | Registry 作用域：backend 是否多租户/多权限域并存？ | 短期全局表 + 语义真实化；长期 engine-scoped |
|
||||
| R2 | 集成形态：RPA 流程=单个 capability（方案 A）还是节点=step 映射（方案 B）？ | 方案 A 起步 |
|
||||
| R4 | 浏览器双路径：Playwright（自管）vs RPA CDP（接管用户浏览器/登录态） | 宿主动作走 Playwright；RPA 路径作为接管场景第二 runner |
|
||||
| R5 | 包消费方式：确认 Bun 源码消费 + bun 版本矩阵（1.4.3？） | 源码消费（与对面现状一致） |
|
||||
| Q1 | CapabilityDefinition 是否需要 platform 字段（对面清单未见） | 待对面确认 |
|
||||
| Q2 | utilityExtended（命令执行）对应哪个 PermissionScope（13 项中无直接对应） | 待对面确认（可能需扩 scope） |
|
||||
| Q3 | human-dialog 弹窗宿主落点：desktop Electron 窗口 or 宿主网页？ | 待确认（倾向 Electron 桌面宿主） |
|
||||
| R2 | 集成形态：RPA 流程=单个 capability（方案 A）还是节点=step 映射（方案 B）？ | 本方需对面补充信息后定：①对面产品上是否要求逐步审批/逐步可见（决定 A 是否够用）；②对面 workflow-engine 的 step 粒度是否有上限或性能顾虑（719 能力×节点数映射成 step 的量级）；③对面对 RPA 执行中途取消/暂停的交互预期。方案对比：A=对面一个 step 跑完一条 RPA 流程（工作量小、状态映射简单、对面只见"开始/结束"+事件流）；B=每个节点一个 step（全程透明可逐步审批，工作量数倍、两套状态机对表复杂）。本方倾向 A 起步、协议预留节点级事件上报。 |
|
||||
|
||||
| Q# | 问题 | 评审要点 |
|
||||
|---|---|---|
|
||||
| Q1 | CapabilityDefinition 是否需要 platform 字段（对面清单未见） | 建议对面补字段或约定由 catalog platformTag 承载 |
|
||||
| Q2 | utilityExtended（命令执行）对应哪个 PermissionScope | 13 项中 desktop.process 是候选，需对面确认语义（backend 无桌面，进程执行属哪域） |
|
||||
| Q3 | human-dialog 弹窗宿主落点 | 已被 R6 顺带回答：用户电脑 Electron 宿主窗口；仅弹窗样式/交互细节与对面 UI 对齐 |
|
||||
|
||||
---
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user