minimal-agent 0.10.0 → 0.12.0

package/plugins/computer_use/app/wechat.md

@@ -0,0 +1,413 @@
+---
+schemaVersion: 2
+guideVersion: 4
+status: layout-verified
+platforms: [macOS, Windows]
+match:
+  bundleId: [com.tencent.xinWeChat]
+  processName: [WeChat, 微信, WeChat.exe, Weixin.exe]
+  displayName: [WeChat, 微信]
+irreversible:
+  critical:
+    - intent:payment-or-transfer
+    - intent:remove-contact
+    - intent:block-user
+    - intent:dissolve-group
+    - intent:leave-group-permanently
+    - intent:delete-account
+    - intent:clear-chat-history
+  normal:
+    - intent:send-message
+    - intent:send-file
+    - intent:send-media
+    - intent:create-group
+    - intent:add-friend
+    - intent:add-emoji
+    - intent:recall-message
+    - intent:set-mute
+    - intent:set-top
+    - intent:set-background
+    - intent:set-nickname
+    - intent:share-chat
+verifiedRange:
+  macOS: WeChat 4.x identity and main-window layout
+  windows: not-verified
+lastVerifiedAt: 2026-07-29
+
+# ---- schema v2 结构化部分 ----
+#
+# ⚠️ 微信是**自绘应用**：无障碍树几乎为空（本仓库实测确认）。所以这里刻意
+#    **不写 rect、不写 ax 锚点** —— 写了就是编的，而编出来的锚点比没有更糟：
+#    模型会拿它当事实去点。分区只声明"存在且大致在哪一侧"，真实坐标必须
+#    每次从当次观测里读。
+
+# 这个应用专属的「该叫人来」信号。内核只认识跨应用通用的那些（密码框、验证码、
+# 二维码登录…），微信的登录小窗**不暴露「扫码登录」四个字** —— AX 里只有
+# 「二维码」和「仅传输文件」两个控件，必须两个一起出现才算数：单独一个「二维码」
+# 很可能只是聊天里别人发的图，据此判定会把正常聊天误报成需要人工介入。
+# ⚠️ 这段以前是写死在内核 humanBoundary.ts 里的一段 bundleId 判断。通用内核里
+# 出现具体应用的 bundleId ＝ 多支持一个应用就要改一次内核，与「drop 一份说明书
+# 即扩展能力」的架构相反，因此搬到这里。
+humanBoundary:
+  - reason: qr_login
+    summary: 需要你扫码完成微信登录
+    allOf:
+      - 二维码
+      - 仅传输文件
+
+layout:
+  - id: nav_rail
+    desc: 最左侧**窄图标栏**（纯图标无文字：头像在最上，下面是聊天/通讯录/收藏等）
+    verified: true
+  - id: conversation_list
+    desc: 第二栏会话列表；顶部一行是搜索框 + 右侧「+」新建按钮，下方按最近活跃排序
+    verified: true
+  - id: chat_header
+    desc: 右侧聊天区顶部，显示当前聊天对象名称；群聊在名称后带括号成员数（如「童年 (7)」）
+    verified: true
+  - id: message_area
+    desc: 消息气泡区，全自绘、无控件信息，只能看图；自己发的在右、别人的在左带头像
+    verified: true
+  - id: compose_area
+    desc: 底部输入区；左下工具栏依次可见表情、扩展、文件夹、截图下拉与麦克风；⚠️ 注意：右下角的麦克风/语音图标不是发送按钮，微信 Mac 版默认无独立发送按钮，靠键盘 Enter 发送
+    verified: true
+  - id: chat_actions
+    desc: 聊天区右上角有消息/会话操作下拉、电话和更多菜单；具体图标会随单聊、群聊和版本变化
+    verified: true
+
+controls: []
+
+flows:
+  activate_wechat:
+    goal: 从其他应用切回微信主窗口
+    verified: false
+    steps:
+      - do: 优先用 activate_app 按 Bundle ID com.tencent.xinWeChat 激活微信
+      - do: observe 确认前台应用和三栏主窗口；若只出现登录、通话或小程序窗口，不继续操作聊天
+      - do: 仅在原生激活失败时，视觉定位 Dock 中绿色双气泡微信图标并单击，再重新 observe
+    pitfalls:
+      - Agent 操作期间宿主窗口必须隐藏且不可聚焦；若 KakadeAI、终端或其他用户窗口成为前台，立即暂停并交还用户，不能循环激活微信
+      - Dock 红色数字只是未读数量，不能用来确认当前打开了哪个会话
+      - Dock 图标下方黑点只表示应用正在运行，不表示主窗口已获得焦点
+      - Dock 可能自动隐藏、位于屏幕左侧或右侧，不能使用截图里的固定坐标
+
+  browse_conversations:
+    goal: 查看左侧会话列表，找到目标会话
+    verified: false
+    steps:
+      - do: 确认微信在前台且主窗口可见
+        precondition: foreground_app_is com.tencent.xinWeChat
+      - do: observe 一次，从截图里读出会话列表的实际位置与条目
+      - do: 需要下翻时在会话列表区域 scroll，每次翻动后重新 observe
+    pitfalls:
+      - 会话列表按活跃度实时重排，上一次观测的第 N 行下一秒可能已经是别人
+      - 未读红点与置顶会改变视觉顺序，不要用"第几个"来指代某个会话
+
+  search:
+    goal: 搜索联系人、群聊或聊天记录
+    verified: false
+    steps:
+      - do: 确认微信在前台
+        precondition: foreground_app_is com.tencent.xinWeChat
+      - do: 点击会话列表顶部的搜索框，observe 确认光标进去了
+      - do: |
+          按通用输入框规范，检查并清空残留内容后再输入关键词。
+          ⛔ **原样输入联系人的中文名，绝对不要转成拼音或英文。**
+          微信搜索是字面匹配 —— 搜「王磊」能找到，搜「wang lei」什么都搜不到。
+      - do: 输入关键词后 observe 看结果分组（联系人／群聊／聊天记录分开列出）
+      - do: 点选目标条目，再 observe 确认右侧聊天区标题变成了预期对象
+    pitfalls:
+      - 搜索结果混排联系人、群聊和聊天记录三类，点错类别会打开完全不同的东西
+      - 同名联系人与同名群极常见，只靠名字选中就是在赌 —— 但「唯一同名联系人 + 若干群/聊天记录」
+        **不是**歧义：只有联系人分区里出现两条以上完全同名才需要停下问用户
+      - ⛔ **中文名不要自己转拼音。** 实测事故：要搜「王磊」，模型在输入框里改成了
+        「wang lei」，结果零结果、整个任务卡死。中文由工具负责送达：系统装着输入法时
+        它会**自动整串走剪贴板粘贴**并还原你原来的剪贴板（回执会说明走了哪条路），
+        不需要你换写法去绕 —— 换写法只会把一个工具已经处理好的问题变成一个搜不到的问题
+
+  send_message:
+    goal: 给指定联系人或群发一条文字消息
+    verified: false
+    steps:
+      - do: |
+          ⛔ **必须在本次任务里亲自打开目标会话，不许沿用「打开着的那个」。**
+          即使微信当前已经停在某个会话上，也**必须**先走一遍 search 流程搜到目标联系人
+          并点开 —— 除非你在**本次任务的前几步里亲手点开的就是它**。
+          「界面上正开着一个聊天窗」不构成「它就是收件人」的任何证据。
+      - do: |
+          canonical observe，**逐字核对聊天区左上角的标题** = 目标联系人姓名。
+          截图与屏幕 1:1（引擎已把桌面切到 1920×1080，见 `ensure_model_friendly_resolution`），
+          姓名是可以看清的 —— 认真看，不要「觉得像」就算数：
+          「王鹏」和「王磊」只差一个字，发错无法挽回（真实事故）。
+          标题不是目标、或确实看不清 → 停下重新走 search，**绝对不许先打字**。
+          ⚠️ 窗口标题栏永远是「微信」，不含聊天对象名 —— 引擎的 precondition
+          校验不了收件人，这一步只能靠你看截图，它是发错人的**唯一**防线。
+        precondition: foreground_app_is com.tencent.xinWeChat
+      - do: |
+          判断目标是否唯一。**只有真歧义才停下问用户**：
+          · 唯一命中 → 「联系人」分区里**只有一条**姓名与目标完全相同 → 直接选它，不要问。
+            同时出现的**群聊**、以及「包含:xxx」这类聊天记录匹配，**不算**同名冲突 ——
+            它们是别的类别，不是另一个同名的人。
+          · 真歧义 → 「联系人」分区里有**两条或以上**姓名完全相同 → 这时才停下，
+            让用户提供头像、备注名、微信号或共同群等可区分信息。
+          ⚠️ 把「有个群名里含这个名字」当成同名冲突而停下，是实测发生过的事故：
+          搜「王磊」已经命中唯一联系人并高亮在「最常使用」第一条，模型却因为下面有个
+          「HOSSKY—AI+XR 包含:A 王磊」的群，判定无法确认对象，整个任务放弃。
+      - do: 点击底部输入区，observe 确认焦点已在输入框
+      - do: 按通用输入框规范，检查并清空残留内容（发新消息必须清空）
+      - do: 输入内容后 observe，逐字核对屏幕上显示的文字与要发的一致，确认输入法候选框已消失
+      - do: 确认当前用户设置采用哪个发送键；发送快捷键可被用户改，不能猜 Enter 或 Cmd+Enter；⚠️ macOS 微信 4.x 桌面版默认没有独立的发送按钮：输入框右下角是语音/麦克风图标不是发送按钮，默认按 Enter 发送，用户可改为 Cmd+Enter
+      - do: 发送
+        irreversible: true
+        # actionClass 是「这一步的前提该管哪次动作」的唯一桥梁：模型自报
+        # actionClass:intent:send-message 时，下面这条 precondition 才会被检查。
+        # 不写就等于这条前提永远不生效（见 manualSchema::unmetPreconditionsFor）。
+        actionClass: intent:send-message
+        precondition: foreground_app_is com.tencent.xinWeChat
+      - do: |
+          canonical observe：确认聊天标题仍是目标对象，且新消息出现在本人一侧（右侧气泡）。
+          ⛔ 报告结果时**只能写你在截图上真看到的那个标题**。没核对过就写「已发给 XX」＝
+          编造 —— 实测发生过（发给了王鹏，报告说发给了王磊）。无法确认时只报告状态，
+          禁止重复发送。
+    pitfalls:
+      - 发送快捷键可被用户改（Enter 或 Cmd+Enter），不能假定哪个是发送、哪个是换行
+      - ⚠️ macOS 微信 4.x 桌面版默认没有独立的发送按钮！输入框右下角是语音/麦克风图标，不是发送按钮，不要点击它！
+      - 输入法在合成中时按发送键只会上屏候选词，必须先确认候选框已消失
+      - 微信消息发出后 2 分钟内才可撤回，且对方仍会看到"撤回了一条消息"
+      - ⛔ **发错对象无法挽回（撤回只有 2 分钟，且对方仍看得到「撤回了一条消息」）。**
+        实测事故（真机 trace + 截图为证）：任务是「给王磊发多运动」，微信当时停在**王鹏**的
+        会话上，模型 observe 之后**没有搜索、没有核对标题**，直接 click 输入框 → type → 回车，
+        消息发给了王鹏；然后它向用户报告「已成功给联系人**王磊**发送消息」。
+        整条链只有 4 个动作，搜索联系人那一整步被跳过了。
+        ⚠️ 当时的根因是**物理上看不清**：桌面还是 4K，截图缩小约 3.7 倍，姓名只剩约 8 像素高，
+        裁出来放大 6 倍看第二个字完全糊成一团 —— 那张图里**不含**区分这两个字的信息。
+        现已根治：引擎在每次 observe 前把桌面切到 1920×1080 并 1:1 送图（见
+        `macos.rs::ensure_model_friendly_resolution`）。但**「不许沿用打开着的会话」这条依然成立** ——
+        看得清不等于看过，跳过搜索直接打字仍然是发错人的路。
+        两个教训：① 「屏幕上开着一个会话」≠「它是收件人」；
+        ② **没核对过就不许在完成报告里写收件人名字** —— 那是编的，不是观察到的
+      - 登录、二维码、风险提示、验证码或微信异常退出都属于人工介入边界；停止自动动作，不关闭提示、不重复启动、不尝试绕过
+
+  group_chat:
+    goal: 在群聊里交互（看成员、@ 某人、查看群公告）
+    verified: false
+    steps:
+      - do: 打开目标群会话并 observe 确认标题与成员数
+        precondition: foreground_app_is com.tencent.xinWeChat
+      - do: 需要看成员或群设置时，点聊天区右上角进入群信息面板，再 observe
+      - do: 需要 @ 某人时在输入区输入 @ 触发成员候选框，observe 后从列表里选
+    pitfalls:
+      - 输入 @ 会弹出成员候选浮层，此时直接按发送键会选中候选而不是发消息
+      - 群成员昵称可被本人改动，同一个人在不同群显示不同名字
+
+  create_group:
+    goal: 创建一个新群聊
+    verified: false
+    steps:
+      - do: 确认微信在前台
+        precondition: foreground_app_is com.tencent.xinWeChat
+      - do: 从会话列表顶部的新建入口发起群聊，observe 确认选人面板已打开
+      - do: 逐个搜索并勾选成员，每勾一个后 observe 核对已选列表
+      - do: 确认创建
+        irreversible: true
+        actionClass: intent:create-group
+        precondition: foreground_app_is com.tencent.xinWeChat
+    pitfalls:
+      - 建群会立刻给所有被选中的人发出通知，选错人就是打扰到了真人
+      - 三人及以上才成群；只选一个人会直接开成单聊而不是群
+
+  add_friend:
+    goal: 添加好友
+    verified: false
+    steps:
+      - do: 确认微信在前台
+        precondition: foreground_app_is com.tencent.xinWeChat
+      - do: 在搜索框输入微信号／手机号，observe 确认搜索结果确实是目标本人
+      - do: 打开其资料页，observe 核对头像、微信号、地区等可见信息
+      - do: 发送好友申请
+        irreversible: true
+        actionClass: intent:add-friend
+        precondition: foreground_app_is com.tencent.xinWeChat
+    pitfalls:
+      - 好友申请一旦发出无法撤回，对方会收到通知
+      - 搜索手机号会把该号码暴露给对方（对方能看到"通过手机号搜索添加"）
+      - 加错人属于隐私事故，不属于"重试一次"能解决的错误
+
+  read_chat_history:
+    goal: 向上翻阅当前会话的历史消息（只读）
+    verified: false
+    steps:
+      - do: 先用 search 流程打开目标会话，observe 核对聊天区顶部标题确实是目标对象
+        precondition: foreground_app_is com.tencent.xinWeChat
+      - do: 用 scroll 翻页，x/y 必须框在 **message_area 中心**（聊天气泡区中间，
+            大约屏幕横向 55%~75%、纵向 30%~60% 一带），direction 用 up。
+            系统会先把鼠标移到该点再滚轮，所以坐标必须落在消息区里面，
+            落在窗口边缘或别的应用上就滚错地方了。
+      - do: 每滚一次都重新 observe，对比气泡内容确认**真的往上翻了**；
+            回执里的变化率看的是「目标区域」，别拿全屏动静当数
+      - do: 若回执提示目标区域没有变化，改用键盘：先 click 一下 message_area 中心让它获得焦点，
+            再用 key 发 pageup（整页上翻）。键盘事件走焦点控件，不依赖鼠标位置，
+            在微信这种自绘应用上常常比滚轮更稳。需要一次到底可用 home。
+      - do: 读到足够条数或已到最早一条（顶部不再出现新内容）就停止，按屏幕可见内容如实汇总
+    pitfalls:
+      - ⛔ **绝对不要用 drag 拖滚动条，也不要去点右侧那条细边**。微信的滚动条是隐藏的、
+        只有几像素宽；拖偏或点偏就落在消息气泡上 —— 那不是滚动，是**框选文本**，
+        属于误操作，而且看起来还像"成功了"。要翻页只有两条路：scroll + 坐标，或 click + pageup。
+      - message_area 全自绘、无障碍树为空：翻没翻动**只能靠对比截图里的气泡内容**判断，
+        不能靠"动作返回成功"
+      - 滚轮事件投递给**鼠标所在**的视图。坐标给到左侧会话列表，滚的就是会话列表 ——
+        实测发生过：连滚多次，右侧聊天记录一行没动、左侧列表滚了一大截
+      - 历史很长时不要一次滚太多再 observe：跨度太大会跳过中间内容，宁可小步多滚
+      - 只读流程：全程不得点击输入区、发送键或任何会改动会话的入口
+
+  read_contact_profile:
+    goal: 读取好友资料
+    verified: false
+    steps:
+      - do: 用 search 流程找到该联系人，或从会话中点开对方头像
+        precondition: foreground_app_is com.tencent.xinWeChat
+      - do: observe 资料页，只读取屏幕上可见的信息
+    pitfalls:
+      - 资料页只读；不要点"设置备注和标签"之类会改动对方条目的入口
+      - 备注名与昵称是两个不同的东西，报告给用户时要说清读到的是哪个
+
+  transfer_files:
+    goal: 收发文件
+    verified: false
+    steps:
+      - do: 打开目标会话并核对标题
+        precondition: foreground_app_is com.tencent.xinWeChat
+      - do: 发送时用 file_drop 把文件送进输入区，observe 确认输入区出现了文件卡片
+      - do: 确认发送
+        irreversible: true
+        actionClass: intent:send-file
+        precondition: foreground_app_is com.tencent.xinWeChat
+      - do: 接收时点消息里的文件，observe 确认下载完成后再去读本地路径
+    pitfalls:
+      - file_drop 不是真拖拽（macOS 不允许合成），走剪贴板或文件面板；必须 observe 核实文件真的到了
+      - 大文件与受限类型会被拒绝，错误提示只出现在界面上，动作本身不会报错
+      - 文件发出后同样不可撤回
+
+verification:
+  environment: macOS / WeChat 4.x, 2048×1024 main-window screenshot plus macOS Dock screenshot
+  verifiedAt: 2026-07-31
+  # 只确认截图直接证明的分区、可见图标与相对位置，不含坐标和可点击性。
+  verifiedItems: [identity, layout, visible-controls, dock-appearance]
+  # ★ 流程步骤仍是公开帮助文档的转写，**没有一条实机跑过**。
+  #   引擎注入时会带"未实机验证"标注，别把它当成已验证的操作序列。
+  unverifiedItems: [accessibility-anchors, flows, windows-layout]
+---
+
+# 微信 / WeChat App Guide
+
+## 稳定身份
+
+### macOS
+
+- Bundle ID：`com.tencent.xinWeChat`
+- 进程名候选：`WeChat`、`微信`
+- 常见显示名：`WeChat`、`微信`
+
+### Windows
+
+- 可执行文件名候选：`WeChat.exe`、`Weixin.exe`
+- Windows 身份尚未实机验证，不能仅凭显示名判定版本或进程。
+
+## AX / UIA 可发现线索
+
+- **macOS AX 候选线索**：主窗口、搜索、会话列表、聊天标题、消息列表、输入区和工具栏应从当前 AX 快照确认。
+- **Windows UIA 候选线索**：主窗口、搜索、会话列表、消息区域、编辑区和附件入口应从当前 UIA 树确认。
+- **焦点通道可用层级**：macOS 与 Windows 均未实机验证。
+- 发送快捷键可由用户设置改变，因此不能把 Enter 或组合键固定声明为发送动作。
+
+## 常见自绘区
+
+- 消息气泡、表情/贴纸、图片与视频预览、语音消息、小程序、通话和二维码区域可能只有部分 Accessibility 信息，需视觉兜底；尚未实机验证。
+
+## 风险动作与不可逆动作
+
+- 发送文字、文件、图片、视频或名片。
+- 撤回消息、清空聊天记录、删除会话或移除联系人。
+- 发起付款、转账、红包或任何金融动作。
+- 对外发送前必须重新核对当前聊天对象和待发送内容；群名与联系人重名不能仅靠标题判断。
+
+## 弹窗与恢复
+
+| 弹窗或状态 | 可观察线索 | 安全恢复出口 |
+|---|---|---|
+| 扫码登录、验证码或设备确认 | 登录窗口、二维码或验证提示 | 交还用户完成，不读取或转发验证码 |
+| 文件过大、类型受限或上传失败 | 发送前/发送中的错误提示 | 保留原文件，不重复发送，报告失败状态 |
+| 联系人或群聊重名 | 搜索结果中出现多个同名项 | 停止选择，要求用户提供可区分身份 |
+| 更新、通话或小程序窗口抢占前台 | 新窗口、浮层或全屏内容出现 | 关闭或退出后重新确认主窗口与聊天对象 |
+| KakadeAI 或其他普通窗口抢占前台 | 前台 Bundle ID 不再是微信 | 自动接管并等待用户；不得由 Agent 循环激活微信 |
+| 用户真实鼠标或键盘输入 | Helper 报告 human_input_detected | 撤销输入租约，等待用户点击“完成并继续”，随后 canonical observe |
+| 风险提示或微信异常退出 | 安全提示、登录页、进程退出 | 立即停止本次自动化并保留现场，不自动重启或重试 |
+| 网络断开或消息未送达 | 连接状态、失败标记或重试提示 | 不自动重复发送，先确认服务恢复与消息状态 |
+
+## 可替代 API
+
+- 无已验证的个人微信桌面消息官方自动化 API。
+- 企业微信或组织系统应优先使用其正式开放接口，但不能把企业接口权限外推到个人微信。
+- 本机文件选择和内容校验优先使用文件工具；最终发送仍属于微信内的外部动作。
+
+## 界面布局
+
+主窗口是自左向右三段：**最左竖排功能栏 → 会话列表 → 聊天区**。聊天区自身
+再分三段：顶部标题（当前聊天对象）、中间消息气泡区、底部输入区。
+
+这三段的**存在与相对位置**是稳定的，**具体坐标不是** —— 窗口可拉伸、可全屏、
+可隐藏侧栏。所以 frontmatter 的 `layout` 只声明分区语义，不声明 rect：
+每次动手前的坐标只能来自当次 observe。
+
+聊天区顶部标题是发送前最可靠的对象核对点；左侧选中态只能作为辅助证据。
+截图中群聊标题采用“名称 (成员数)”形式，例如“童年 (7)”。发送前必须重新
+observe 核对标题，不能沿用上一个动作前的判断。
+
+## 截图确认的 macOS 4.x 控件
+
+- 会话列表顶部是搜索框，右侧是圆形“+”入口。
+- 聊天区右上角依次可见会话操作下拉、电话和更多菜单；单聊与群聊可能不同。
+- 输入区左下可见表情、扩展、文件夹、截图下拉和麦克风；右下有独立语音/播放图标。
+- 左侧功能栏与会话列表会显示未读红点；红点与列表顺序都不是联系人身份。
+- Dock 中微信是绿色双气泡图标，红色角标表示未读，图标下黑点表示正在运行。
+
+这些是视觉外观证据，不是稳定坐标或 AX 标识。窗口缩放、侧栏宽度、显示器比例、
+Dock 位置和微信升级都会改变坐标；每次操作仍应以当次 observe 为准。
+
+## 典型流程速查
+
+frontmatter 的 `flows` 是权威版本（引擎会直接注入给你，不必来这里读）。
+这一节只补充两条贯穿所有流程的原则：
+
+1. **每个动作之后 observe。** 微信没有可用的控件树，动作的退出码只说明
+   "事件发出去了"，说明不了界面变成了什么样。
+2. **不可逆动作前重新核对对象。** 从打开会话到按下发送之间，界面可能因为
+   新消息、来电弹窗、别的应用抢前台而变化。上一次核对的结论不能跨动作复用。
+
+## 实测记录
+
+> **这一节是 agent 的自我完善区。** 说明书与实况不符时（写着的分区找不到、
+> 流程步骤对不上、precondition 反复失败），把**观察到的事实**追加到这里，
+> 一条一行，带日期与应用版本。
+>
+> 只写观察到的，不写推测。确认稳定后由人提升进 frontmatter 并标
+> `verified: true` —— 单次观察不能直接升级为永久事实。
+
+- 2026-07-30 · WeChat 4.x / macOS 26.5.2 · 一次真实观测 + 一张屏幕截图：
+  - **AX 树整棵只有 19 个节点**（`axNodes:19`，且 `truncated:false` —— 不是被截断，
+    是微信真的只暴露这么点）。这坐实了头注那句「自绘应用 AX 基本是空的」：
+    `wait_for_element` / `textTarget` / `focused_role_is` 在微信上**都用不了**，
+    只有 `wait_for_window` 和看图可用。
+  - 布局确认为三栏：窄图标栏 → 会话列表（顶部搜索框 + 右侧「+」）→ 聊天区
+    （标题 / 气泡区 / 输入区）。群聊标题形如「童年 (7)」，括号内是成员数。
+  - 观测耗时 411ms，backend=native，`frames:1`（采样器刚起来时只有一帧）。
+  - ⚠️ 这次观测**没有走完任何一条 flow** —— 上面 `flows` 仍全部未验证。
+
+## 已验证范围
+
+- **验证环境**：macOS 26.5.2，WeChat 4.1.11。
+- **已验证**：应用包 Bundle ID 和版本元数据。
+- **仍需验证**：macOS AX 层级、Windows 身份/UIA、搜索、会话选择、发送、附件、登录和网络恢复。
+- **frontmatter 里的 `layout` 与 `flows` 全部未实机验证** —— 它们是把面向人的
+  帮助文档转写成面向 agent 的形式，不是跑出来的结论。
+- 不声明 Windows 版本或 WeChat 4.1.11 的交互流程已受支持。