ai-test

AI Test — XMind 驱动的 Midscene 用例执行

用户的输入: $ARGUMENTS

本 skill 从 QA XMind 抽取用例，并按用例维度独立执行 Midscene 视觉定位测试。QA XMind 是唯一用例来源，结果按 XMind topic id 回写到结果 XMind。

Step 1: 收集并校验输入

必须先明确以下信息：

1. 完整测试链接 targetUrl，必须由用户直接提供，不接受其他形式代替。
2. 测试 uid，用于把测试链接中的 u 查询参数替换为目标账号；链接没有 u 时追加。
3. QA XMind 输入：本地文件路径或可直接下载的 HTTP/HTTPS CDN 链接。

缺少任一必要参数时，立即向用户索要全部缺失参数并停止本次执行。参数校验通过前，不得同步或安装 server-act-cli、创建输出目录、安装 runtime 依赖、下载 XMind，也不得执行后续任何步骤。

可选输入：

• activityName：用于结果标题和输出目录名；未提供时使用测试链接中的 act_id 生成 act-{act_id}。
• pageType：已注册页面 Profile，例如 recharge-page、main-page、store-page；未提供时优先从完整测试链接的页面目录判断，再按 QA 层级和页面用途兜底。

测试链接处理规则：

1. 将用户提供的完整 targetUrl 作为唯一页面入口。使用结构化 URL API 替换或追加 u={UID}，保留原域名、路径、hash 和其他全部查询参数。
2. 从链接查询参数读取 act_id 和 region，用于活动上下文和页面 Profile。缺少任一参数时要求用户提供包含该参数的完整测试链接，不读取源码或其他配置补全。
3. 不从代码、目录名、分支或本地配置生成、补全或替换测试链接。

Step 2: 同步 server-act-cli

Step 1 参数校验通过后，每次 AI Test 会话同步一次 @wepie/server-act-cli 和当前版本配套 Skills：

act-cli --version
act-cli update --skills
act-cli --version

• 第一次 act-cli --version 正常：执行 act-cli update --skills，再读取更新后的版本。

• 命令不存在：安装并同步当前版本配套 Skills：

  npm install -g @wepie/server-act-cli --registry=http://maven.17zjh.com/repository/group-npm
  act-cli update --skills
  

• 安装 @wepie/server-act-cli 时必须在命令中显式指定 --registry=http://maven.17zjh.com/repository/group-npm，不依赖机器当前的 npm registry 配置。

• 安装失败：向用户回显上面的完整安装命令并停止流程，不要改用公网 npm 源。

• act-cli update --skills 失败：提示当前 Skills 同步失败并停止流程，不要把安装成功误报为同步成功。

• 安装成功：提示用户“server-act-cli 安装完成，已自动继续执行”，无需再次确认。

• 出现登录提示：提示用户执行 act-cli login 完成飞书 SSO 登录，再重新触发当前指令。

• 同一次 AI Test 会话后续阶段不再更新 act-cli；能力判断直接使用本次同步后的 CLI、act Skills 和业务查询结果。

同步阶段只更新 CLI 和 Skills，不执行账号状态修改。

Step 3: 准备输出目录和 runtime

路径约定

执行本 skill 时确定以下路径：

• {SKILL_DIR}：当前 ai-test skill 根目录，即本 SKILL.md 所在目录。
• {CWD}：触发本次 AI Test 时的当前工作目录，不自动切换目录或分支。
• {OUTPUT_DIR}：按本步骤的环境规则创建的本次测试独立产物目录。

所有 skill 自带脚本、runtime、references 都从 {SKILL_DIR} 解析。本地 QA XMind 相对路径从 {CWD} 解析；CDN XMind 按 Step 4 下载到 {OUTPUT_DIR}。测试页面只使用用户提供的完整链接，不读取活动源码或切换代码分支。不要把 .claude/skills/ai-test 写死到命令里。

运行时依赖隔离

AI Test 的 Midscene 依赖只安装在本 skill 内：

pnpm --dir "{SKILL_DIR}/runtime" install

• {SKILL_DIR} 表示当前 ai-test skill 的根目录，也就是本 SKILL.md 所在目录。
• 不要假设 skill 一定安装在项目根的 .claude/skills/ai-test/；服务器、个人环境或下载后的目录都可能不同。
• 不修改项目根 package.json / pnpm-lock.yaml。
• Midscene 版本由 runtime/package.json 和 runtime/pnpm-lock.yaml 管理；需要升级时只改 runtime 依赖。
• 若安装因为网络或 registry 失败，按当前执行环境申请网络权限或提示用户配置可访问 npm 源。

Midscene 的非敏感默认配置维护在 runtime/src/runner.ts 的 MIDSCENE_ENV_DEFAULTS 中。运行时先读取进程环境变量，只对缺失或空值的同名配置补代码默认值，因此服务器显式配置优先。API Key、鉴权 Token 等未登记在默认表中的敏感配置不得写入代码，始终从服务器环境变量或本地可选 .env 读取；Skill 分发和执行不依赖 .env 文件存在。

准备步骤

1. 从当前上下文查找 user_id，只用它判断运行环境，无需询问运行目录策略：
   • 存在 user_id：视为云端服务器或飞书机器人环境。优先使用服务器上的 /tmp/fe-AI-test/；不可用时改用 ${TMPDIR}/fe-AI-test/、/var/tmp/fe-AI-test/ 或当前运行环境提供的其他可写临时目录。
   • 不存在 user_id：视为本地环境，使用 {CWD}/docs/ai-test/。
2. 生成本轮目录名 {ACTIVITY_SLUG}-{YYYYMMDD-HHmmss}：
   • {ACTIVITY_SLUG} 优先取用户提供的 activityName；未提供时取 act-{act_id}。
   • 保留中文、英文字母、数字、点、下划线和连字符；空格及其他路径分隔字符统一替换为 -。
   • 时间使用执行环境当前本地时间，精确到秒；目录已存在时追加短序号，不覆盖旧产物。
3. 将环境根目录与本轮目录名拼成绝对路径 {OUTPUT_DIR} 并创建。服务器示例：/tmp/fe-AI-test/甜心梦工坊-20260715-103000；本地示例：{CWD}/docs/ai-test/甜心梦工坊-20260715-103000。
4. 若 {SKILL_DIR}/runtime/node_modules/@midscene/web 不存在，执行 runtime 安装。
5. 运行前设置：

export MIDSCENE_RUN_DIR="{OUTPUT_DIR}/midscene_run"

Step 4: 从 XMind 抽取用例

先把用户输入统一解析为本地文件 {QA_XMIND_LOCAL}：

1. 输入不是 http:// 或 https:// 开头时，按本地文件处理。相对路径基于 {CWD} 解析，绝对路径直接使用；文件不存在时停止并提示用户。
2. 输入是 HTTP/HTTPS CDN 链接时：
   • 创建 {OUTPUT_DIR}/_input/。
   • 使用完整原始 URL 下载，保留签名、查询参数和 fragment 之前的所有 URL 内容；不要根据 URL 路径推断本地文件名，也不要求链接以 .xmind 结尾。
   • 跟随 HTTP 重定向，HTTP 4xx/5xx、连接失败或下载失败时停止并提示链接可能已失效或无下载权限。
   • 固定保存为 {OUTPUT_DIR}/_input/qa-source.xmind，并设置 {QA_XMIND_LOCAL} 为该绝对路径。

下载命令：

mkdir -p "{OUTPUT_DIR}/_input"
curl --fail --show-error --silent --location \
  --retry 2 \
  --connect-timeout 15 \
  --output "{OUTPUT_DIR}/_input/qa-source.xmind" \
  "{QA_XMIND_CDN_URL}"

然后统一执行：

python3 "{SKILL_DIR}/scripts/xmind_cases.py" extract \
  "{QA_XMIND_LOCAL}" \
  "{OUTPUT_DIR}/qa-raw-cases.json"

抽取失败时，如果输入来自 CDN，提示用户下载内容可能不是有效 XMind、链接返回了登录页或链接已过期；不得把 HTML/JSON 错误响应当作 XMind 继续处理。抽取结果中的每条 case 保留原 XMind topic id。不要改 id。

XMind 用例事件支持两种结构，并由抽取脚本统一按节点顺序扁平化：

1. 旧结构：步骤与预期直接作为用例节点下的同级节点。
2. 新结构：步骤直接位于用例节点下，预期作为对应步骤的子节点。

两种结构都必须保留原始事件顺序，生成完整的 rawSteps、steps 和 expects。带预期子节点的步骤仍然只是步骤，不能被误识别为嵌套子用例；同一 XMind 可以混用两种结构。

Step 4.5: 解析页面 Profile

读取 references/page-types/index.md，按其中的识别条件、优先级和加载顺序确定页面类型与区服 Profile。用户未提供 pageType 时，先用结构化 URL API 解析 targetUrl.pathname：页面目录为 recharge 或 recharge-* 时选择 recharge-page，main 或 main-* 时选择 main-page，store 或 store-* 时选择 store-page；不读取查询参数、活动源码或路由文件推断页面类型。链接路径无法唯一判断时再使用 QA 层级和页面用途，仍无法确定才在规范化前向用户确认。Profile 只应用到命中的具体用例，加载结果写入 run-config.pageProfile。

Step 5: 规范化用例描述

读取 references/normalization-rules.md 和 Step 4.5 选定的页面 Profile，把 qa-raw-cases.json 中的 QA 原文改写为标准化自然语言用例，输出：

• {OUTPUT_DIR}/qa-normalized-cases.json
• {OUTPUT_DIR}/qa-normalized.md，由 qa-normalized-cases.json 固定渲染生成

本阶段只做语言整理与语义结构化，所有具体规则以 normalization-rules.md 和当前页面 Profile 为准。必须保留 topic id、QA 原文和来源字段，输出可人工审阅的规范化步骤、预期、事件顺序、非视觉事实与场景候选；不得生成 flow、选择 action、读取源码或补充 QA 未提供的业务事实。无法消除的歧义写入 normalizationNotes。

生成或修改 qa-normalized-cases.json 后，先运行固定 sanitizer，再用固定 renderer 生成阅读版 Markdown。sanitizer 不得修改 title、path、rawSteps、expects、source 等原始审计字段：

python3 "{SKILL_DIR}/scripts/sanitize_case_text.py" \
  normalized \
  "{OUTPUT_DIR}/qa-normalized-cases.json"

python3 "{SKILL_DIR}/scripts/render_cases_md.py" \
  "{OUTPUT_DIR}/qa-normalized-cases.json" \
  "{OUTPUT_DIR}/qa-normalized.md" \
  normalized \
  "{活动描述} AI Test 规范化用例"

Step 5.5: 规范化产物自查

生成 qa-normalized-cases.json / qa-normalized.md 后，必须按 references/artifact-review.md 的 qa-normalized-cases 自查 自查一次；自查是流程环节，不是脚本 gate。发现问题时，只修正 qa-normalized-cases.json，再重新渲染 qa-normalized.md，不得手工改 Markdown，也不得进入编译或测试。

Step 6: 编译 qa-cases.json

读取 references/case-schema.md、references/execution-eligibility.md、references/scenario-setup.md 和 references/compilation-rules/index.md，以 qa-normalized-cases.json 为唯一编译输入生成 qa-cases.json。逐条匹配 compilation rule；使用页面专属规则时应用已加载 Profile；存在可明确匹配的参考图时再读取 references/reference-images.md。

不得新增或合并 QA 用例。每个 case/variant 无论是否带 【构造状态】 都必须先完成前置状态语义判断，再对 scenarioDraft.required = true 的项按 scenario-setup.md 完成通用状态载体发现和候选读写组合检查。可执行项必须生成与规范化事件顺序一致的完整 flow；不可执行项必须按 reference 写明状态和具体原因，不得用固定 case id 列表、玩法名称白名单、批量 skip 或泛化的“act-cli 无相关能力”代替动态能力判断。不得通过重新引入已被规范化移除的 raw 内容来补 flow。

正式流程中每条可执行 case 都必须生成 flow。runner 保留的 rawSteps 自动降级只用于旧产物兼容或显式调试，不作为全流程产物；发现 flow 为空时，必须回到编译阶段补全后再跑测试。

生成或修改 qa-cases.json 后，先运行固定 sanitizer，再用固定 renderer 生成阅读版 Markdown：

python3 "{SKILL_DIR}/scripts/sanitize_case_text.py" \
  compiled \
  "{OUTPUT_DIR}/qa-cases.json"

python3 "{SKILL_DIR}/scripts/render_cases_md.py" \
  "{OUTPUT_DIR}/qa-cases.json" \
  "{OUTPUT_DIR}/qa-cases.md" \
  cases \
  "{活动描述} AI Test 可执行用例"

Step 6.5: Flow 产物自查

生成 qa-cases.json / qa-cases.md 后，必须按 references/artifact-review.md 的 qa-cases / flow 自查 自查一次；自查是流程环节，不是脚本 gate。除 flow 与 normalizedSteps 冲突、重新带回 raw 上下文步骤或上下文顺序错误外，发现 scenarioDraft.required = true 却没有完成状态载体发现、使用泛化不可构造原因、或同类状态能力结论无依据漂移时，也必须先修正 qa-cases.json，再重新渲染 qa-cases.md，不得手工改 Markdown，也不得进入测试。

Step 7: setup.agent 执行准备

当本轮包含 setup.type = "agent" 或 variants 时，读取 references/scenario-setup.md，并在 Step 9 使用编排脚本生成和执行 manifest。场景能力、payload、构造边界与串行要求均以该 reference 为准。

Step 8: 写入 run-config.json

生成 {OUTPUT_DIR}/run-config.json，写入本轮 runner 所需配置：

• targetUrl：用户提供的完整链接，只替换或追加 u。
• outputDir：本轮 {OUTPUT_DIR} 绝对路径。
• casesPath：本轮 {OUTPUT_DIR}/qa-cases.json 绝对路径。
• midsceneRunDir：本轮 {OUTPUT_DIR}/midscene_run 绝对路径。
• activityDesc：活动名称；未提供时使用 act-{act_id}。
• workers：普通用例并发数，默认 4，至少为 1 且不超过本次用例数。
• pageReadyWaitMs：页面基础加载后的稳定等待时间，默认 5000。
• caseTimeoutMs：单条用例默认超时，默认 240000。
• pageProfile：使用页面专属规则时，记录当前 id、pageType、regionProfile 和实际加载的 profileFiles。

调试用的 filter 只在用户明确要求运行部分用例时写入，全量测试不得沿用旧值。生成后按 references/artifact-review.md 的 run-config 自查进入 runner 前校验。

Step 9: 运行测试

运行方式：后台启动 + 前台循环监听到结束（强约束）

本步骤中每一次执行 pnpm --dir "{SKILL_DIR}/runtime" run test，无论是直接批量运行、普通 case 批量、单条 variant 还是场景构造单条运行，都必须使用本节方式启动并监听。prepare_scenario_runs.py、merge-results 等短时准备或合并脚本仍可直接前台执行，不需要转为后台任务。

全量测试可能运行十几分钟，超过单次前台命令的等待上限。因此既不要用单次前台命令一直等待，也不要把进程 detached 到后台后结束当前任务。每一次 runner 调用都按下面方式执行，并在同一轮任务中连续完成：

1. 后台启动一次：使用当前宿主提供的后台任务或持久终端会话能力启动对应 runner 命令，保存返回的任务 ID 或会话 ID。不得因轮询超时而重复启动同一批测试。
2. 前台循环监听并查看进度：使用当前宿主提供的阻塞等待或会话轮询能力检查后台进程、读取新增日志；每次最多等待 5 分钟。
   • 进程已经退出：跳出当前监听循环。
   • 进程仍在运行：根据日志确认当前用例、已完成用例或阶段进度；有进度变化时向用户提供简短更新，然后立即发起下一次最长 5 分钟的等待。
   • 一次等待超时或暂时没有新日志不表示运行结束；只要进程仍存在，就继续轮询，不能结束当前任务、重复启动测试或向用户宣称测试未启动。
   • 最多连续监听约 24 次（约 120 分钟）；达到上限仍未退出时才判定为运行异常，停止继续等待并向用户报告已有日志、进程状态和产物情况。
3. 退出后立即继续后处理：确认进程退出，并检查该次运行预期的 test-result.json 和 midscene_run/ 是否落盘。存在后续 manifest 条目时继续执行下一条；全部运行完成后继续合并结果并进入 Step 10，不得在 runner 退出后提前收尾。

不同宿主可以使用不同工具实现上述语义：例如后台 Bash 任务配合任务输出轮询，或持久终端会话配合会话轮询。工具名称不是约束，后台只启动一次、前台持续轮询进度、结束后继续后处理才是强约束。这样既能避免长时间前台命令被平台强制终止，也能避免服务器或飞书机器人把“后台命令已发出”误判为整项测试已经结束。

如果本轮 case 全部不包含 setup.type = "agent"，且全部不包含 variants，可以在当前工作目录直接执行：

AI_TEST_CONFIG="{OUTPUT_DIR}/run-config.json" \
MIDSCENE_RUN_DIR="{OUTPUT_DIR}/midscene_run" \
pnpm --dir "{SKILL_DIR}/runtime" run test

如果本轮存在任意 setup.type = "agent" 或 variants，先执行下面的运行编排。

场景构造用例的执行编排

读取 references/scenario-setup.md，再生成外层编排清单：

python3 "{SKILL_DIR}/scripts/prepare_scenario_runs.py" \
  "{OUTPUT_DIR}/run-config.json"

按 _runtime/run-manifest.json 执行：先完整执行普通 case 的 batch；再根据 scheduling 执行场景与 variant。非集合页保持 global-serial。集合页使用 collection-module-lanes：相同 laneKey 按 laneOrder 串行，parallelEligible = true 的不同泳道最多按 workerLimit 并发；标记为 false 的兜底泳道必须单独串行。

集合页启动并发泳道前，先按 references/scenario-setup.md 动态确认当前 run 的实际状态载体，并把资源锁键登记到 manifest 与 setup payload 的 resourceKeys，将 resourceKeysResolved 设为 true。资源锁从构造开始一直持有到该 runner 退出并写入结果；不同泳道的资源键有交集时等待，不得并发。账号级或活动级公共状态、无法确认资源载体、缺少稳定 XMind 模块 topic id 时使用 global 锁降级串行。这样并发只发生在模块和底层状态都相互独立的用例之间。

并发时每个泳道最多只有一个活动 runner；同一父 case 的互斥 variants 仍按所在泳道串行。前台对所有活动会话轮询，任一会话退出后立即检查产物、释放其资源锁并启动该泳道下一条；不能因为另一泳道仍在执行而停止监听。每次 runner 调用仍必须遵守本步骤的后台启动与前台循环监听要求。

普通批量执行：

AI_TEST_CONFIG="{OUTPUT_DIR}/_runtime/batch/run-config.json" \
MIDSCENE_RUN_DIR="{OUTPUT_DIR}/midscene_run" \
pnpm --dir "{SKILL_DIR}/runtime" run test

单条场景或 variant 执行时，使用 manifest 当前条目的 configPath：

AI_TEST_CONFIG="{MANIFEST_CONFIG_PATH}" \
MIDSCENE_RUN_DIR="{OUTPUT_DIR}/midscene_run" \
pnpm --dir "{SKILL_DIR}/runtime" run test

所有条目完成后，按 manifest 的 merge.inputPaths 合并结果：

python3 "{SKILL_DIR}/scripts/xmind_cases.py" merge-results \
  "{OUTPUT_DIR}/test-result.json" \
  "{INPUT_PATH_1}" \
  "{INPUT_PATH_2}"

{INPUT_PATH_N} 表示 manifest merge.inputPaths 中的实际路径；必须把全部条目作为独立参数传入，不得照抄占位符。

合并后的 {OUTPUT_DIR}/test-result.json 再进入 Step 10 自查。

Step 10: 自查测试中间结果

测试完成后，必须按 references/artifact-review.md 的 test-result 自查 自查一次；确认结果 caseId 可对齐、没有非预期缺失结果、失败/跳过/需端内测试原因可读，且关键失败用例存在可上传的 Midscene 报告。自查通过后继续 Step 11。

此时 test-result.json 和 midscene_run/ 仍是中间产物。不要提前生成最终 Markdown 或 XMind，因为逐用例报告 CDN 只有在发布阶段上传 HTML 后才能确定。

Step 11: 发布测试结果

读取 references/result-publishing.md，严格按“上传 HTML → 生成并上传 fe-test-result.md / fe-test-result.xmind → 生成并上传精简包 → 调用飞书 webhook → 校验并清理本轮本地 HTML”的顺序完成发布。只有全部文件上传和 webhook 成功后才允许清理 HTML；任一发布环节失败时必须保留 HTML 供补传。最终根据 publish-result.json 向用户汇报发布与清理结果；失败时说明失败阶段与原因。

最终 XMind 由发布阶段执行：

python3 "{SKILL_DIR}/scripts/xmind_cases.py" annotate \
  "{QA_XMIND_LOCAL}" \
  "{OUTPUT_DIR}/test-result.json" \
  "{OUTPUT_DIR}/midscene_run/report/report-links.json" \
  "{OUTPUT_DIR}/fe-test-result.xmind" \
  "{活动描述} AI Test 结果"

最终汇报时读取 fe-test-result.md 和 publish-result.json，向用户展示汇总数字、失败/跳过清单、Markdown/XMind CDN、HTML 报告独立上传汇总、精简打包产物 CDN、Midscene 报告目录和 htmlCleanup 清理结果。

按需参考文件

文件	何时读取
references/index.md	首次了解 references 结构或判断规则入口时必读
references/normalization-rules.md	把 XMind 抽取结果规范化为自然语言用例时必读
references/artifact-review.md	各阶段产物进入下一步前自查时必读；覆盖 normalized、flow、config 和 result
references/case-schema.md	编译或修正 qa-cases.json 时必读
references/execution-eligibility.md	编译每条 case/variant 前必读；判定执行、跳过或需端内测试
references/compilation-rules/index.md	编译或修正 qa-cases.json 时必读；按用例场景路由条件编译规则
references/compilation-rules/*.md	被 compilation-rules/index.md 命中时才读取
references/scenario-setup.md	编译或执行需要业务态构造的用例时必读；定义外层 Agent 场景构造流程
references/reference-images.md	页面提供原型截图或 docs/assets/ 存在图片时必读；定义参考图绑定与降级
references/result-publishing.md	测试完成后上传 HTML、生成核心产物、精简结果包并登记飞书时必读
references/page-types/index.md	规范化前解析页面类型和区服结构差异时必读
scripts/xmind_cases.py	XMind 抽取、结果合并、最终 Markdown 渲染和结果 XMind 回写
scripts/sanitize_case_text.py	清理规范化及可执行用例中的模型侧派生文本，保留原始审计字段
scripts/prepare_scenario_runs.py	根据 run-config.json 拆分普通批量运行和场景构造单用例运行
runtime/src/runner.ts	需要了解执行行为、调试 runner 时读取

执行约束

1. 禁止修改项目根依赖文件来升级 Midscene。
2. QA XMind 是唯一用例来源；不得自行新增用例。
3. 每条 case 独立打开页面执行，避免跨 case 状态污染。
4. 结果回写必须按 XMind topic id 对齐，不能靠用例顺序猜。
5. 当前场景构造 provider 只有 act-cli；未来新增 provider 时必须先在 scenario-setup.md 补充能力来源、判断约束和执行要求，再加入候选范围。

输出产物

每次测试使用独立的 {OUTPUT_DIR}，目录规则见 Step 3：

只有 fe-test-result.md 和 fe-test-result.xmind 是核心最终产物；下表其他文件与目录仍会正常生成，但统一视为中间产物或发布过程记录。精简压缩包继续保留这些中间产物，只排除已单独上传的 Midscene HTML。

文件	说明
_input/qa-source.xmind	输入为 CDN 链接时下载的原始 QA XMind 本地副本
qa-raw-cases.json	从 QA XMind 直接抽取的原始用例，保留 XMind topic id
qa-normalized-cases.json	按规范化规则改写后的自然语言用例，用于人工质检，不是 runner 可执行文件
qa-normalized.md	规范化用例的人类可读版本
qa-cases.json	从规范化用例编译出的可执行结构化用例，保留 XMind topic id
qa-cases.md	可执行用例的人类可读版本
run-config.json	runner 配置，包含 URL、页面 Profile、用例文件和并发数
fe-test-result.md	核心最终产物；汇总与明细，逐用例报告使用上传后的 CDN URL
fe-test-result.xmind	核心最终产物；在原 QA 层级基础上标注状态、原因与报告 CDN
test-result.json	中间产物；runner 结果，按 caseId 对齐 XMind topic id
midscene_run/	中间产物；运行时保存 Midscene HTML 与缓存；完整发布成功后删除其中的 HTML，保留其他证据
midscene_run/report/report-links.json	中间产物；每个 HTML 报告的用例信息、上传 URL 和上传结果汇总
_runtime/	中间产物；仅存在场景编排时生成的清单、临时配置和场景运行结果
publish-upload-context.json	中间产物；本轮全部上传共用的时间戳和随机 run hash
publish-manifest.json	中间产物；压缩前写入活动 ID、区服、测试结果概览和整体执行分析
publish-result.json	中间产物；Markdown、XMind、HTML、精简包地址、webhook 结果及本地 HTML 清理记录