问题描述
当前 VOM 主要基于 AX Tree、DOMSnapshot 和布局信息构建页面语义。Canvas 内的文字、表格和控件通常只以像素形式存在，不对应独立的 DOM 或 AX 节点，因此无法被 observation 读取。例如，Canvas 表格中可见的表头、行列、单元格内容和选中状态可能完全缺失，agent 也无法理解或准确操作这些区域。
该问题不能通过继续补充 AX/DOM 名称解析规则解决，因为相关语义在浏览器标准语义层中可能根本不存在。部分 Canvas 应用会在内部维护字段、记录、视图和单元格等结构化数据，但这些数据属于应用内部模型，需要通过隔离的应用语义 Provider 读取；不存在稳定模型入口时，只能退化为截图和视觉理解。
同时，Canvas 内容不应默认完整加入每次 observation。表格可能包含大量单元格，如果 agent 当前只需要操作页面上的普通按钮，自动读取 Canvas 会增加观察延迟和 token 消耗，并可能挤占更重要的页面内容。
预期解决方案
将 Canvas 建模为一种“可发现、按需展开的语义表面”：
-
默认 observe 只利用现有 DOMSnapshot 轻量识别可见且可能包含内容的 Canvas，不读取内部内容，也不增加逐节点 CDP 请求。VOM 仅输出简短提示，例如：
@e31 canvas "表格视图" [content collapsed; run: bsk observe --expand @e31]
-
扩展现有 observe，支持通过 bsk observe --expand @e31 显式读取目标 Canvas。多 Canvas 页面只展开指定目标，其他 Canvas 保持折叠，避免新增一套重复的 Canvas observation 和渲染机制。
-
定义可插拔的 Canvas Semantic Provider。Provider 负责将应用内部模型批量转换为标准的 grid、row、columnheader、gridcell 等语义节点，并使用稳定的应用节点 ID、当前可见数据和 Frame 局部 Geometry。具体站点适配与 VOM 核心隔离，不能在名称解析或语义图中硬编码站点私有数据结构。
-
Provider 输出作为独立的 application semantic contribution，在 AX/DOM 完成语义解析后、结构归一化前接入统一语义图。Canvas 语义不得伪装成 DOM 或 AX 节点，也不能影响普通页面和现有 iframe 的处理。
-
Provider 不可用时，不自动执行昂贵或不可靠的 OCR。应复用现有 bsk screenshot --ref @e31 获取 Canvas 区域截图，由 agent 按需进行视觉理解。未来如增加 OCR，应通过相同 Provider 接口接入，并标记来源与置信度。
Geometry 与操作
Provider 坐标统一使用所属 Frame 的 viewport-relative CSS 像素，再复用现有 Geometry 机制转换到顶层页面坐标，统一处理 iframe/OOPIF、缩放、Canvas scale、devicePixelRatio、滚动和裁剪。
Canvas 内部节点没有 backendDOMNodeId，因此后续操作需要将 ref 从单一 DOM 节点地址扩展为带能力的目标类型，例如 DOM 节点、可展开 Surface 和可点击 Region。只有具有可靠 Geometry、仍处于当前 revision 且实际可见的区域才能生成点击 ref；屏幕外或低置信度节点只能用于描述。fill、select 等不适用于 Canvas region 的操作应明确拒绝，不能隐式猜测。
性能与兼容性要求
- 默认 Canvas discovery 仅扫描已经采集的节点，保持线性复杂度，不新增模型读取、截图或逐 Canvas CDP 请求。
- 完整语义只在显式展开时读取，并限制为当前可见区域、少量 overscan 和既有 token/node 上限。
- Provider 必须单次批量读取、支持取消和超时，失败时只降级目标 Canvas，不能导致整个 observation 失败。
- 不得输出隐藏字段、隐藏记录或超出当前页面权限的数据。
snapshot 和 recorder 默认保持现有行为，不自动展开 Canvas。- 没有 Canvas 的普通页面 observation 应保持不变。
- 需要覆盖单 Canvas、多 Canvas、同进程 iframe、OOPIF、嵌套 iframe、虚拟滚动、大表格、Provider 失败和视觉降级等测试场景。
问题描述
当前 VOM 主要基于 AX Tree、DOMSnapshot 和布局信息构建页面语义。Canvas 内的文字、表格和控件通常只以像素形式存在，不对应独立的 DOM 或 AX 节点，因此无法被 observation 读取。例如，Canvas 表格中可见的表头、行列、单元格内容和选中状态可能完全缺失，agent 也无法理解或准确操作这些区域。
该问题不能通过继续补充 AX/DOM 名称解析规则解决，因为相关语义在浏览器标准语义层中可能根本不存在。部分 Canvas 应用会在内部维护字段、记录、视图和单元格等结构化数据，但这些数据属于应用内部模型，需要通过隔离的应用语义 Provider 读取；不存在稳定模型入口时，只能退化为截图和视觉理解。
同时，Canvas 内容不应默认完整加入每次 observation。表格可能包含大量单元格，如果 agent 当前只需要操作页面上的普通按钮，自动读取 Canvas 会增加观察延迟和 token 消耗，并可能挤占更重要的页面内容。
预期解决方案
将 Canvas 建模为一种“可发现、按需展开的语义表面”：
默认
observe只利用现有 DOMSnapshot 轻量识别可见且可能包含内容的 Canvas，不读取内部内容，也不增加逐节点 CDP 请求。VOM 仅输出简短提示，例如：扩展现有
observe，支持通过bsk observe --expand @e31显式读取目标 Canvas。多 Canvas 页面只展开指定目标，其他 Canvas 保持折叠，避免新增一套重复的 Canvas observation 和渲染机制。定义可插拔的 Canvas Semantic Provider。Provider 负责将应用内部模型批量转换为标准的
grid、row、columnheader、gridcell等语义节点，并使用稳定的应用节点 ID、当前可见数据和 Frame 局部 Geometry。具体站点适配与 VOM 核心隔离，不能在名称解析或语义图中硬编码站点私有数据结构。Provider 输出作为独立的 application semantic contribution，在 AX/DOM 完成语义解析后、结构归一化前接入统一语义图。Canvas 语义不得伪装成 DOM 或 AX 节点，也不能影响普通页面和现有 iframe 的处理。
Provider 不可用时，不自动执行昂贵或不可靠的 OCR。应复用现有
bsk screenshot --ref @e31获取 Canvas 区域截图，由 agent 按需进行视觉理解。未来如增加 OCR，应通过相同 Provider 接口接入，并标记来源与置信度。Geometry 与操作
Provider 坐标统一使用所属 Frame 的 viewport-relative CSS 像素，再复用现有 Geometry 机制转换到顶层页面坐标，统一处理 iframe/OOPIF、缩放、Canvas scale、
devicePixelRatio、滚动和裁剪。Canvas 内部节点没有
backendDOMNodeId，因此后续操作需要将 ref 从单一 DOM 节点地址扩展为带能力的目标类型，例如 DOM 节点、可展开 Surface 和可点击 Region。只有具有可靠 Geometry、仍处于当前 revision 且实际可见的区域才能生成点击 ref；屏幕外或低置信度节点只能用于描述。fill、select等不适用于 Canvas region 的操作应明确拒绝，不能隐式猜测。性能与兼容性要求
snapshot和 recorder 默认保持现有行为，不自动展开 Canvas。