maa-pipeline-testing

Pipeline Testing Skill

官方依据核对

测试命令、schema 字段或 MaaFramework API 行为以原始官方来源为准。涉及版本差异、binding 兼容性或语义变化时，通过 $maa-wiki 定位官方文档、schema 与源码后再下结论；测试通过不能替代对官方契约的核对。

如果用户要求验收一个尚未定义目标状态和完成条件的端到端自动化需求，先交给 $maa-workflow-build 建立任务契约；已有契约时，再用本 skill 为其中的验收条件收集测试证据。

诊断边界

本 skill 的测试证据已经能定位责任方时，直接把证据交回对应 skill：识别或动作节点问题回 $maa-pipeline-generate，option 与 override 接线问题回 $maa-pipeline-option，状态模型或集成问题回 $maa-workflow-build。不要因为聚焦识别失败就触发 $maa-diagnose 的广义诊断流水线。只有失败已经发生、且聚焦测试仍无法归属责任方（原因可能同时落在运行日志、静态定义、环境或 harness）时，才由 $maa-workflow-build 的 RECOVER 请求 $maa-diagnose 收集只读证据。

项目初始化接力

测试前先查目标项目根目录的 basic_info.md。存在且包含第 0 节时，读取“0. Maa Skills 接力协议”和第 2/5/7/8/9/10 节，用 task/resource、公共返回节点、OCR/模板/ROI 和风险清单规划测试；随后以当前截图、当前源码和 TaskDetail 为准。优先把公共 Click 节点复制成临时 DoNothing 探针做初始化 smoke test，完成后调用 stop_pipeline 并删除临时文件。文件缺失或没有第 0 节时按本 skill 直接发现测试所需上下文；不得自动调用 $maa-project-init，只有用户明确要求初始化或刷新时才调用。源码更新更晚时视为缓存可能过期并以源码为准，不自动刷新或覆盖。

测试对象发现规则

从主 interface.json / interface.jsonc 读取 task entry、import[] 和 resource[].path。import[] 与资源路径都相对主 Interface 目录解析；测试只针对声明资源根内的 Pipeline、图片和项目声明的 agent 入口。assets/... 是常见打包布局示例，但不是可以脱离 Interface 声明猜测的协议默认值。

概述

测试 MaaFramework Pipeline JSON 中的 node，验证识别和操作是否正常工作。

历史审查后的测试边界

• 资源加载检查是 smoke test，不是端到端证明：目标项目锁定的 Interface / resource 检查（例如 M9A 的 pnpm check）能证明声明和资源包可加载，但不能证明 CustomAction/CustomRecognition 名称存在、参数路径正确、run_task() 分支判断正确。
• Custom 映射必须单独查：所有 action: Custom / action.type = Custom 的 custom_action 都要能映射到 @AgentServer.custom_action(...)；所有 recognition.type = Custom 的 custom_recognition 都要能映射到 @AgentServer.custom_recognition(...)。
• CustomRecognition 也要测：M9A 证明复杂 OCR/list/image 逻辑经常放在 CustomRecognition，不要只测 CustomAction。
• 高风险链路要复测稳定态：购买、消耗、战斗开始、继续挑战、结算确认等动作后，先识别稳定页面或完成态，再继续危险动作。
• 关闭节点不能继续调用：当 option 把可执行节点的 enable/enabled 设为 false 时，Python 必须先短路，不能再调用该节点的 run_recognition()/run_task()；同时验证关闭可选分支后，同级战斗/调查分支仍会继续识别。
• 识别成功不等于点对位置：识别命中只证明找到了元素。带 target / target_offset 的节点必须在点击后再截一次图确认落点，否则写死的坐标会在换设备后静默点错。审查写法见 coordinate-hygiene。