wauxiliary-plugin-dev

# WAuxiliary 插件开发 以当前 WA 文档和运行时源码为准。同版本插件可以参考写法，但不能代替接口文档。涉及 Hook、广播或任务时，插件卸载后不能留下仍在运行的内容。 ## 执行流程 | 阶段 | 操作 | 检查标准 | |---|---|---| | 1. 明确需求 | 从需求和当前目录确定任务类型、插件根目录与目标 WA 版本；实现或调试时按 [workflow.md](references/workflow.md) 整理触发条件、适用会话、动作、配置、失败反馈和卸载行为。 | 得到可直接检查的完成标准。 | | 2. 核对接口 | 按 [repository-map.md](references/repository-map.md) 定位资料，从 [API 索引](references/api/INDEX.md) 读取本次实际涉及的回调、签名和字段。 | 每项 WA 调用都有来源，没有推测的接口。 | | 3. 设计 | 涉及脚本规则、生命周期、网络或联系人时读取 [runtime.md](references/runtime.md)；新建插件或调整模块划分时读取 [architecture.md](references/architecture.md)。 | 目录、加载顺序、失败处理和卸载责任明确。 | | 4. 执行 | 创建、修改、调试或迁移时按完成标准实施；审核时同时按 [review-checklist.md](references/review-checklist.md) 检查。 | 代码或审核发现均有文档或源码依据。 | | 5. 验证 | 检查完成标准、`info.prop`、`loadJava` 路径、回调、失败处理与卸载清理；能运行 WA 时再验证实际加载和交互。 | 交付改动文件、已验证项和真机待验证内容。 | ## 遇到不确定情况时 - 先查需求、目录、文档和源码。如果仍有多个 WA 版本或插件根目录可选，而且选择会影响实现，再询问用户；得到答复后重新核对接口。 - 公开接口不能满足需求而需要 Hook、反射或内部类型时，先说明版本风险并确认；用户不接受时保留公开接口范围或缩小功能。 - 迁移会删减功能或改变配置、数据格式时，先说明改动前后的差别。用户确认前，保留原有行为和格式。 - 资料冲突时按“当前工作区文档和源码 > 内置接口文档 > 同版本插件 > 用户示例”的顺序判断，并说明采用了哪份资料。仍查不到的签名或字段不要猜，只实现能够确认的部分。 - 没有真机环境时，完成静态检查和源码核对，列出还要在真机上检查什么，不要写成“已经运行通过”。 ## WA 开发规则 - `main.java` 采用 BeanShell 顶层脚本。功能较多、拆分后更容易阅读时，再用 `loadJava("相对路径.java")` 加载模块。路径以 `pluginDir` 为基准，先加载被其他代码使用的模块；`main.java` 只保留加载代码、需要共享的 Hook 或任务引用、WA 回调和模块调用。 - 必需文件只有 `info.prop` 和 `main.java`。`config.prop` 在首次写入配置时由 WA 生成；`readme.md` 仅在用户或仓库要求时添加，不创建空文件占位。 - 使用回调、全局变量、字段、方法或重载前核对文档。入站自动处理通常排除 `msgInfoBean.isSend()`；事件回复用 `msgInfoBean.getTalker()`，当前会话主动操作才用 `getTargetTalker()`。 - `get`、`post`、`download` 均为异步接口；请求前保存事件会话 ID，只在回调中使用可能为 `null` 的结果。 - 混合来源的选择项在收集时保留对象类型或明确类型标记；不能只保存 ID 丢失类型信息后，再根据字符串格式猜测类型。 - 菜单回调只负责添加菜单项，发消息或写配置放在点击 lambda 中。Hook、广播和定时任务等注册内容要在 `onUnload()` 中取消。 ## 结果要求 - 创建、修改或迁移：用户要求落地时直接编辑目标目录，逐项满足完成标准，交付必要文件和确有职责的模块。 - 调试：报告“现象或日志 → 根因与证据 → 最小修复 → 验证”，并检查所有已加载模块中的同类问题。 - 审核：问题优先，逐项给出严重程度、文件与行号、实际影响和依据；无问题时明确说明剩余验证风险。