@alipay/alipay-aipay 1.2.2 → 1.4.9

package/skill/references/onboarding/flow.md

@@ -1,168 +1,88 @@
-# 签约流程说明
+# 支付产品-产品开通流程说明
 
-> ⚠️ **前置声明**：本 flow 仅支持**网站支付、APP支付、按量付费**三种产品的签约。**其他产品（当面付、订单码支付、JSAPI支付、预授权支付、商家扣款等）暂不支持**，如需签约请前往[支付宝商家平台](https://b.alipay.com/page/portal/home)完成签约。
+> ⚠️ **前置声明**：本 flow 仅支持**网站支付、APP 支付、按量付费**三种产品的产品开通。**其他产品（当面付、订单码支付、JSAPI支付、预授权支付、商家扣款等）暂不支持**，如需开通请前往[支付宝商家平台](https://b.alipay.com/page/portal/home)完成。
 
 ---
 
-## 内容导航
-
-- [文件路由表](#-文件路由表)
-- [核心铁律](#-核心铁律签约流程强制遵守)
-- [产品映射](#一产品映射)
-- [主流程](#二主流程6步)
-- [Step 详解](#三step-详解)
-- [错误处理](#四错误处理全局规则)
-- [流程状态](#五流程状态)
-
-## 📂 文件路由表
-
-> 本文件位于 `references/onboarding/`。下表中的 `modules/...`、`../normal/...` 路径均相对本文件所在目录；若从技能包根目录定位，请加前缀 `references/onboarding/`。
-
-| 文件 | 说明 | 引用位置 |
-|------|------|----------|
-| **flow.md** | ⭐ 主入口 - 签约流程全览（本文档） | - |
-| **../normal/** | 通用模块 | - |
-| ↳ ../normal/alipay-cli-env.md | alipay-cli 检测与安装 | Step 1 环境检查 |
-| ↳ ../normal/rejection-guide.md | 拒绝引导话术 | 通用 |
-| ↳ ../normal/scripts/detect_dev_tool.sh | AI编程工具检测 | Step 1 |
-| ↳ ../normal/scripts/common.sh | shell 公共函数与初始化入口 | 签约脚本公共依赖 |
-| **modules/** | 子模块目录 | - |
-| ↳ modules/mcc-reference.md | MCC类目参考表 | Step 2 方案规划 |
-| ↳ modules/authorization.md | 登录授权模块 | Step 3 登录授权 |
-| ↳ modules/product-sign.md | 签约模块 | Step 3.1 签约查询 + Step 5.1 签约提交 |
-| ↳ modules/service-registration.md | 服务市场注册模块 | Step 3.1 按量付费服务查询 + Step 5.2 写操作 |
-| ↳ modules/app-release.md | 应用发布模块 | Step 3.1 应用查询 + Step 5.3 后续操作 |
-| ↳ modules/error-handling.md | 错误处理说明 | 全流程 |
-| **modules/scripts/** | 签约流程脚本 | - |
-| ↳ modules/scripts/auth.sh | 登录授权全流程 | Step 3 |
-| ↳ modules/scripts/query_sign_status.sh | 签约状态查询 | Step 3.1 |
-| ↳ modules/scripts/upload_screenshots.sh | 截图上传 | Step 4 |
-| ↳ modules/scripts/ar_sign_apply.sh | 签约提交 | Step 5.1 |
-| ↳ modules/scripts/service.sh | 服务查询与注册 | Step 3.1 查询 + Step 5.2 写操作 |
-| ↳ modules/scripts/app.sh | 应用查询与发布 | Step 3.1 查询 + Step 5.3 后续操作 |
-| ↳ modules/scripts/error_handler.sh | 统一错误检测（共享库） | 全流程 |
-
-> 📌 **使用建议**：从 flow.md 主入口开始，按流程顺序执行各 Step。各 Step 中已标注对应的脚本调用命令。
+## 执行入口与重启原则
 
----
-
-## ⛔ 核心铁律（签约流程强制遵守）
+严格按本文 Step 1 至 Step 6 执行。每到一个动作，只读取该动作明确列出的模块并使用已有脚本；禁止一次加载全部签约、服务和应用模块，禁止凭记忆拼接 MCP 命令，也禁止绕过 `auth.sh` 直接调用 `alipay-cli login`。
 
-> ⚠️ 以下铁律为签约流程的最高优先级规则，所有 Step 执行必须遵守。详细说明见各模块文档。
+进入任何产品开通环境检查、产品/MCC 澄清或方案确认前，先从本 flow 目录执行一次确定性平台入口：
 
-### 1. 应用公钥管理铁律
-**核心原则：公钥由用户自行生成，skill 只负责接收和配置**
-```
-❌ 禁止：自动为用户生成公钥或密钥对
-❌ 禁止：向用户表示可以"帮助生成公钥"、"帮助生成密钥对"
-❌ 禁止：提供任何密钥生成代码、命令或脚本
-❌ 禁止：请求、接收或处理用户的私钥信息
-❌ 禁止：在用户未明确提供 publicKey 时调用 createKeyConfirmPage
-❌ 禁止：自动生成、推断、补全、改写或添加前后缀到 publicKey
-✅ 必须：引导用户前往支付宝开放平台官方密钥生成工具
-✅ 必须：只接受用户明确输入的完整 publicKey
-✅ 必须：提醒用户妥善保管私钥，切勿泄露给任何人
+```bash
+node ../normal/scripts/onboarding_message_runner.mjs platform-entry
 ```
-> 详见 `modules/app-release.md`
 
-### 2. 用户项目文件修改铁律
-```
-❌ 禁止：直接修改用户项目中的 .ts / .tsx / .js 文件
-❌ 禁止：修改 alipay-sdk-config.ts 或类似的支付配置文件
-✅ 正确：输出配置内容让用户自行复制
-✅ 正确：告知用户需要修改的文件路径和具体内容
-```
+- Windows：runner stdout 是唯一对客正文，必须原文发送；发送后停止本 flow 的产品开通动作，不再执行 Step 1、MCC 澄清、方案确认、登录或材料收集。`onboarding_only` 在根意图识别后进入本 flow 即执行；`full_process` 保留已完成的 Integration 实际结果，在衔接本 flow 时执行。
+- 非 Windows：runner 成功且 stdout 为空，直接继续下方既有流程，不输出平台提示，不改变步骤、确认或完成条件。
+- 命令失败或输出无法唯一判断时停止并核对 runner，禁止手写、改写或补发近似引导。
 
-### 3. Agent 话术约束铁律（全局）
-**本铁律适用于签约全流程所有需要输出引导话术的场景**
-```
-🚨 【强制】Agent 话术约束（最高优先级）：
-❌ 禁止：篡改各模块标准引导话术中的链接、格式或内容
-❌ 禁止：添加标准话术中没有的内容（如"PEM格式"、"-----BEGIN PUBLIC KEY-----"等）
-❌ 禁止：替换标准话术中的官方链接（如将 opendocs.alipay.com 替换为其他链接）
-❌ 禁止：自行创造、补充、解释任何未见于标准话术的格式说明
-✅ 必须：100% 复制使用各模块文档中的「标准引导话术」原文
-✅ 必须：当需要补充说明时，只能引用官方文档链接
-
-📌 典型反例：
-❌ 错误：将 https://opendocs.alipay.com/common/02kipk 替换为 https://open.alipay.com/keytool
-❌ 错误：在引导话术中添加"公钥以 -----BEGIN PUBLIC KEY----- 开头"
-❌ 错误：自行解释"PEM格式"、"PKCS#1/PKCS#8"等格式概念
-```
-> 详见各模块文档中的「标准引导话术」
+企业账号边界：如果用户明确表示当前要用企业账号通过 Skill 完成产品开通，必须执行下列标准消息命令并停止本 flow 的产品开通动作，引导前往支付宝商家平台。不得主动增加账号类型确认，也不得根据 MCC、营业执照字段或“公司”等泛化描述推断为企业账号；没有明确依据时继续按本 flow 执行。
 
-### 4. CLI环境变量铁律
-```
-✅ 必须：在每个 alipay-cli 调用前设置 PLATFORM 环境变量
-✅ 必须：DEV_TOOL_NAME 由脚本公共初始化获得，缺失时填 "unknown"
-❌ 禁止：省略 PLATFORM 环境变量直接调用 alipay-cli
-❌ 禁止：硬编码 PLATFORM 值（如 PLATFORM=claudeCode）
-❌ 禁止：使用分号 ; 连接（可能导致环境变量泄露）
+```bash
+printf '%s' '{}' | node ../normal/scripts/render_customer_message.mjs onboarding.enterprise.unsupported --variant <ONBOARDING_ONLY|FULL_PROCESS>
 ```
 
-### 5. 授权链接铁律
-**CLI 的 `login` 命令返回 `verification_url` 字段，此链接无法用于授权，禁止透出给用户！**
-```
-❌ 禁止透出：https://opengw.alipay.com/oauth/device（此链接无法授权）
-✅ 正确链接：https://aipay.alipay.com/cli-auth?deviceCode=xxx&productCode=xxx&mccCode=xxx（可选追加 platform=xxx）
-✅ 必须：先单独提示“无法跳链时，请复制下方链接到网页浏览器打开”，授权链接独占下一行
-```
-> 详见 `modules/authorization.md`
+`onboarding_only` 固定使用 `ONBOARDING_ONLY`；`full_process` 只会在代码开发已通过后进入本 flow，固定使用 `FULL_PROCESS`。renderer stdout 是该意图的最终产品开通消息，必须把 stdout 原文作为当前回复正文发给用户；命令面板、折叠输出或“已渲染/已展示”说明不能替代对客消息。发出 stdout 原文后直接停止本 flow，不再执行 Step 6 或追加第二份收口。
 
-### 6. createKeyConfirmPage 返回处理铁律
-**返回结果中禁止展示二维码链接和 `alipays://` 协议链接，只展示 `confirmPageUrl` 的 Markdown 链接。**
-```
-❌ 禁止展示：二维码提示、alipays:// 协议链接
-✅ 必须：将 confirmPageUrl 以 Markdown 链接格式输出
-✅ 必须：先单独提示“无法跳链时，请复制下方链接到网页浏览器打开”，确认链接独占下一行
-✅ 必须：等待用户确认后再继续后续步骤
-```
-> 详见 `modules/app-release.md`
+每次开始都先校验登录、scope 和 MCC，再查询签约状态、应用候选和适用服务候选，并只依据当前真实结果继续。不得根据历史对话推定外部操作结果。
 
-### 7. 授权范围不满足处理铁律
-**当检测到授权范围不满足时，必须执行 logout 退出登录，然后重新授权。**
-```
-❌ 禁止：检测到授权范围不满足后继续执行后续操作
-❌ 禁止：不执行 logout 直接重新登录
-✅ 必须：检测到后先 logout 再重新授权
-✅ 必须：重新授权时使用正确的 scope（根据当前 salesCode 确定）
-```
-> 详见 `modules/authorization.md` §8.1：检测脚本只返回不匹配信号并停止当前操作；`modules/scripts/auth.sh mismatch` 统一执行一次 logout，再使用正确 scope 发起重新授权
+步骤顺序固定为方案确认后授权，再执行全部适用只读查询，最后处理独立分支。查询失败只阻断对应分支，不得当作空列表；其他查询成功的分支可以继续。
 
-### 8. 模块强读铁律
-**执行任何模块操作前，必须读取当前操作对应的 references 章节并覆盖该分支的完整参数、约束和错误处理，禁止凭记忆执行；无关产品和尚未进入的写操作章节不提前读取。**
-```
-✅ 签约查询/提交前 → 分别读取 modules/product-sign.md 中对应章节
-✅ 应用查询/复用/创建/提审前 → 分别读取 modules/app-release.md 中对应章节
-✅ 服务查询/复用/创建/修改前 → 分别读取 modules/service-registration.md 中对应章节
-✅ 登录授权前 → 读取 modules/authorization.md 中当前授权操作所需章节
-❌ 禁止：不读文档直接调用任何 MCP 方法
-❌ 禁止：凭记忆猜测或推断 MCP 方法名、参数名、参数结构
-❌ 禁止：自行编造文档中不存在的 MCP 方法
-```
+方案确认前只允许根据 `modules/mcc-reference.md` 当前匹配行陈述 MCC 名称、适用商家和特殊资质原文；特殊资质为 `-` 只表示当前表未列出，不代表对企业/个人签约资格作出结论。表内没有明确依据的主体资格、前提或材料结论统一说明无法确认，禁止补充常识推断。
 
-### 9. MCP调用铁律
-**签约/查询模块与应用/服务模块的参数结构完全不同，禁止混用！**
-```
-✅ 签约/查询用 ctx：{"request":{...},"ctx":{}}
-✅ 应用/服务不用 ctx：{"request":{...}}
-❌ 禁止：将签约模块的 ctx 习惯带入应用发布模块
-❌ 禁止：将应用发布模块的无 ctx 习惯带入签约模块
-❌ 禁止：省略 ctx:{}（签约模块）
-❌ 禁止：添加 ctx（应用/服务模块）
-```
+---
 
-### 10. 依据不足时不编造
-```
-✅ 必须：没有确定依据时明确说明无法确认
-✅ 签约、费率、额度解限、可收款时间解限等不确定问题 → 引导用户前往支付宝商家平台咨询客服
-✅ 代码集成、应用创建、应用发布等不确定问题 → 引导用户前往支付宝开放平台或支付宝技术支持咨询客服
-❌ 禁止：猜测签约审核规则、额度解限条件、可收款时间、费率优惠、应用创建限制或接口能力
+## ⛔ 核心铁律（签约流程强制遵守）
+
+<!-- GENERATED:ONBOARDING-GUARDS:START -->
+<!-- 此区块由 scripts/generate-skill-guards.mjs 生成，禁止手改 -->
+### 生成式执行护栏
+
+- `P-MCP-CONTRACT-FROZEN`：只执行当前 Skill 已验证脚本中的 MCP 方法、参数和解析；禁止推断、改名、替换或尝试近似方法。
+- `P-AUTH-BEFORE-ONBOARDING`：登录、scope 和 MCC 全部校验通过前，禁止执行任何 onboarding 查询或写操作。
+- `P-WRITE-CONFIRM`：签约材料完整且校验通过后直接执行签约提交，不再增加回复1；材料缺失或校验失败时继续使用受控材料提示，禁止提交。服务创建资料完整且校验通过后展示受控创建摘要并直接执行，不增加回复1；服务修改执行前必须展示当前会话、脱敏主体、产品、动作和目标摘要，并取得绑定当前摘要的明确确认。应用创建由用户针对当前应用候选列表明确选择新建来确认，候选重查未变化且条件字段齐备时不再追加回复1；用户提供应用公钥后生成确认页不重复确认，由用户在官方页面完成公钥确认；新建应用的公钥校验成功后直接提交应用审核，不再增加回复1。
+- `P-WRITE-UNKNOWN`：非幂等写操作结果不明时先用现有只读能力核验；无法确认时进入 UNKNOWN，禁止盲目重试。
+- `P-PARTIAL-RESULT`：签约、服务和应用分支独立记录结果，不回滚已成功动作，不用整体失败或整体成功覆盖部分结果。
+- `P-MATERIAL-CATEGORY`：每轮只展示一个材料类别，同类一次收齐；提前提供的后续材料直接接收并校验，之后不重复索取。
+- `P-KEY-NO-PRIVATE`：不得请求、读取、处理、保存或输出生产应用私钥；本轮不提供本地命令生成密钥能力。
+- `P-KEY-PUBLIC-USER`：应用公钥只能由用户自行生成并明确提供；缺少公钥时禁止调用 createKeyConfirmPage，不补全、不改写、不加 PEM 头尾。
+- `P-AUTH-URL`：授权链接只能由 auth.sh 在固定产品/MCC 上下文校验通过后构造；只允许 https://aipay.alipay.com/cli-auth、deviceCode/productCode/mccCode 和可选 platform，禁止其他域名、路径、参数、重复参数、fragment 或 verification_url。
+- `P-KEY-URL`：公钥确认只展示 createKeyConfirmPage 返回的 confirmPageUrl 裸 URL；禁止展示二维码链接和 alipays:// 深链。
+- `P-URL-AUTO-OPEN`：授权页和公钥确认页在 URL 完整校验通过后默认调用受控 opener；失败、无 GUI 或宿主要求权限时保留同一裸 URL 和复制访问兜底。
+- `P-KEY-TOOL-DOWNLOAD`：缺少应用公钥时按当前操作系统自动下载官方密钥工具并输出实际安装包路径、安装引导和官方文档兜底；只下载，不安装、不启动、不生成密钥，失败或系统不支持时只输出官方文档手动下载引导。
+- `P-SENSITIVE-STATE`：用户可以为当前应用设钥明确提供应用公钥，但该输入只用于本次 app.sh key/verify-key/verify-key-and-audit 调用；Agent 回复、对话摘要、普通日志、跨会话状态和宽权限临时文件禁止复述或保存公钥原文。除 P-SANDBOX-CREDENTIAL-EXCEPTION 明确允许的 Windows 手工沙箱当前资料输入外，私钥、token、Payment-Proof、签名串、完整支付表单和未脱敏 MCP 响应同样禁止进入这些位置。临时 URL 只有在 flow 明确登记、已由脚本或 renderer 完成白名单及当前上下文校验且当前动作必须对客展示时，才允许进入该动作的唯一对客正文；即使获准展示，也禁止进入对话摘要、普通日志、跨会话状态或宽权限临时文件。
+- `P-CUSTOMER-OUTPUT-EXCLUSIVE`：flow 指定 renderer 或托管脚本时，其 stdout 是该动作唯一对客正文；工具输出记录、折叠面板或日志不等于已对客发送，Agent 必须把 stdout 原文作为当前回复正文发给用户。禁止在前后添加执行说明、消息 ID、控制标记、摘要、转述或近似话术。阻塞消息发出后立即停止本轮并等待用户。
+- `P-ONBOARDING-CONTROL-CHANNEL`：Onboarding 登记脚本的内部事实行统一以 ALIPAY_AIPAY_INTERNAL: 开头；即使宿主合并 stdout/stderr，也必须整行剔除后再判断对客正文。内部行严禁对客；成功且剔除内部行后正文为空时直接转移，不补写话术。
+- `P-SCAN-PAGE-DELIVERY-BARRIER`：所有 `postRenderHintType=scanReturn` 的页面消息都是交付屏障，当前包括 `auth.page` 和 `application.key.page`。脚本产生页面 stdout 后，Agent 必须先把剔除内部事实后的 stdout 作为独立对客消息送达，再执行对应 opener 和后续有限轮询；不得把后续 `auth.pending`、`application.key.pending`、`process.partial_result` 或其他 stdout 合并在同一条对客回复中。该屏障不等待用户确认，不新增回复 `1` 或其他用户操作。
+- `P-DETERMINISTIC-HANDOFF`：flow 已登记脚本或 renderer 时只执行动作发生位置的固定命令；退出码和登记终态标记满足后立即按 flow 转移，禁止追加 jq、cat、grep、curl 或临时脚本重复解析、复核或解释同一结果。失败只走登记恢复分支；项目代码实现和运行验证除外，但不得把沙箱配置或其他敏感文件打印到工具输出。
+<!-- GENERATED:ONBOARDING-GUARDS:END -->
+
+生成区块与 `SKILL.md` 红线适用于全部步骤。Onboarding 禁止修改用户项目代码或支付配置文件，只输出需由用户自行应用的配置；每个 CLI 业务调用必须按脚本现状设置环境，禁止硬编码 `PLATFORM` 或用分号拼接环境变量。scope/MCC 不匹配只走 `auth.sh mismatch`；logout 未确认成功不得重授权；`AUTH_FLOW:RETRY_WITH_NETWORK` 或输出不可唯一解析只表示当前 Agent 执行环境无法确认结果，必须申请联网权限后重试同一条脚本命令，不得解释为用户本机 logout/login 失败或支付宝业务失败。签约 `request+ctx` 与应用/服务 `request` 由脚本冻结，禁止绕开脚本混用或重组。
+
+### 标准消息执行规则
+
+对客消息遵守 `SKILL.md`；优先使用登记 runner/脚本。仅无托管入口时按 schema 用 `jq --arg/--argjson` 构造输入，无变量传 `{}`：
+
+```bash
+node ../normal/scripts/render_customer_message.mjs --schema <messageId> --variant <VARIANT>
+printf '%s' "$MESSAGE_INPUT_JSON" | node ../normal/scripts/render_customer_message.mjs <messageId> --variant <VARIANT>
 ```
 
-商家平台咨询入口：[支付宝商家平台](https://b.alipay.com/page/portal/home)
+直接调用 renderer 前必须先用同一 `messageId` + `variant` 查询 schema；托管消息禁止改为临时 `jq+renderer`。失败停步，不手写兜底；stdout 和阻塞规则按 `SKILL.md` 执行。
+
+**工作目录**：本文 Skill 相对命令以 `references/onboarding/` 为 workdir。Onboarding 不改用户项目；检查本机路径时显式传规范化绝对路径，不得切换到启动目录、用户项目或另一份 Skill。
 
-开放平台咨询入口：[支付宝开放平台](https://open.alipay.com/) / [支付宝技术支持](https://opensupport.alipay.com/support/intelligent-services?form=payskill)
+### 耗时事件规则
+
+耗时采集不对客展示，不影响主流程转移。根意图识别后已由 `telemetry.mjs start-run` 确定当前 `run_id`；下列命令会向 stderr 输出唯一 `ALIPAY_AIPAY_INTERNAL:METRIC_EVENT=<json>`，前台只把事件写入用户系统临时目录下带 `alipay-aipay` 标识的本地私有 outbox（默认 `<os.tmpdir>/alipay-aipay-telemetry/outbox`）并启动后台补传，不等待 collector HTTP 结果；后台通过 Yuyan sync-log 上报 code=1005，只在 collector 返回 HTTP 2xx 后删除。已设置 `ALIPAY_AIPAY_TELEMETRY=0|false|off|no`、缺少 run_id、命令异常、网络失败、本地 outbox/run state 写失败或 Yuyan 返回非 2xx 时，均不得阻断当前步骤，也不得向用户解释埋点状态或等待上传结果。最近上传失败状态只写入同一临时目录下的 `upload-status.json`，内部排查可执行 `node ../normal/scripts/telemetry.mjs upload-status`，不得作为对客正文。若最近失败为网络/DNS 类错误且 outbox 有积压，可在阶段间隔或首次业务联网动作旁路执行 `node ../normal/scripts/telemetry.mjs permissioned-flush-needed`；只有出现内部 `PERMISSIONED_FLUSH_NEEDED=true` 时，才通过宿主工具层申请一次可复用联网执行权限运行 `node ../normal/scripts/telemetry.mjs flush-outbox`（即 `flush-outbox` 异步父命令），该命令只启动后台补传子进程并立即返回，建议绑定同一命令前缀。同一 Agent 会话只请求一次；拒绝、后台补传失败或无可复用权限都继续主流程并保留 outbox。取得该权限后，后续阶段间隔和流程收尾可再次旁路执行 `flush-outbox` 触发异步补传；`flush-outbox` stdout 为空，collector HTTP 结果、失败或待重试结果不作为业务转移条件。所有内部行仍按标准规则整行剔除。
+
+```bash
+node ../normal/scripts/telemetry.mjs stage "<stage>" --root-intent "$ROOT_INTENT" --product-type "$PRODUCT_TYPE"
+```
+
+`ROOT_INTENT` 只使用 `onboarding_only|full_process`。`run.product_clarify.start`、`onboarding.mcc_prepare.start`、`onboarding.plan_confirm.start`、`onboarding.branch_summary.start`、`onboarding.material_collect.start` 和 `onboarding.closeout.start` 由对应标准消息/runner 自动输出；最终 closeout 成功生成后，runner 自动记录 `run.terminal` 并结束 `onboarding_only|full_process` 当前 run。其余下文列明的阶段在动作开始前执行一次。sync-log 上传失败静默保留 outbox，后续 telemetry 命令继续补传，不补问、不改变对客正文。
 
 ---
 
@@ -174,32 +94,26 @@
 |------|-------------|-----------|-------|-------------|
 | 按量付费 | aipay | I1080300001000160457 | app:all,machine_pay:write,agmnt:write | 无需截图 |
 | 网站支付 | webpay | I1080300001000041203 | app:all,fast_instant_trade_pay:write | 需要3张网站截图 |
-| APP支付 | apppay | I1080300001000041313 | app:all,auth_alipay_apppay:write | 未签约时需要 APP 名称和3张APP界面截图，签约状态固定按 `OFFLINE` 提交；选择新建应用时在 Step 4 前置采集移动平台信息，Step 5.3 才用于创建 |
+| APP 支付 | apppay | I1080300001000041313 | app:all,auth_alipay_apppay:write | 未签约时需要 APP 名称和 3 张 APP 界面截图，签约状态固定按 `OFFLINE` 提交；选择新建应用时在 Step 4 前置采集移动平台信息，Step 5.3 才用于创建 |
 
 ---
 
-## 二、主流程（6步）
+## 二、主流程
 
 ```
 Step 1: 环境检查 → Step 2: 方案规划 → Step 3: 登录授权
-    → Step 3.1: 状态与资源查询 → Step 4: 一次性资料与资源决策
-    → Step 5: 入驻推进 → Step 6: 本轮流程收口
+    → Step 3.1: 三分支只读发现 → Step 4: 分支摘要与分类材料
+    → Step 5: 独立分支推进 → Step 6: 分支级收口
 ```
 
 ### 启动前材料预告与分流
 
-进入 onboarding 后才预告可能需要的材料，不在登录前要求用户确认材料齐备。签约材料以“一、产品映射”为准，新建应用的条件资料以 Step 4“应用分支”为准；登录查询实际状态后再一次性收集当前分支所需材料。`full_process` 在主编排的项目/集成状态检查阶段以及 integration 阶段均不得提前读取或展示本节材料。
-
-**产品尚未明确时的预告话术**：
-
-> "在确定产品前，我先说明材料差异：按量付费无需截图；网站支付需要网站首页、商品页、支付页 3 张截图；APP支付需要 APP 名称，以及首页、商品页、支付页 3 张截图。确定产品后，我会先查询实际签约和应用状态，再只收集当前分支需要的材料。"
+先确定唯一产品；未确定时只澄清业务场景，不一次展示三产品材料。进入 Step 2 后简短预告当前产品的条件材料，不要求用户确认齐备；登录查询后先展示三分支短摘要，再一次只收集一个可推进类别。`full_process` 固定在 integration 完成后进入本流程，进入前不展示或收集签约材料。
 
 **执行规则**：
-- 产品尚未明确时使用上述话术；产品已明确时不再展示三产品通用话术，Step 2 只预告当前产品的条件材料。两种情况都不得在 Step 3.1 查询前要求用户提交或确认全部材料。
-- `full_process` 在进入 onboarding 前必须已经确定目标产品，因此不得使用“产品尚未明确”的三产品通用材料话术，只展示当前目标产品的签约信息。
-- 网站支付或 APP支付确定为 `NOT_SIGNED` 且尚未完成支付页面或支付能力集成时，暂停签约写操作，切换到集成流程。“尚未完成”的依据仅限：`full_process` 用户明确更正统一分流确认中的集成状态；`onboarding_only` 用户明确声明目标产品尚未完成集成；或 Agent 按 `../../SKILL.md` 的目标项目检查规则重新检查项目代码后取得直接证据。用户声明必须标注为“用户声明”，不得表述为代码检测结果；签约状态、应用列表和服务列表只说明 onboarding 资源状态，不能单独证明代码未集成。若页面和支付能力已存在、仅缺签约申请需要上传的首页、商品页、支付页图片，则保留在 Step 4 收集并上传，不进入集成流程；已签约时不再为签约要求这组图片。
-- 截图要求以“支付页”为准；不得自行改口为“支付成功页”或要求用户提供文档未定义的页面。
-- `full_process` 按 `../../SKILL.md` 的“完整接入编排”完成二维项目状态判断和统一分流确认；只有用户确认所选项目为 `TARGET_COMPLETE`，或本轮 integration 全部完成后才能进入 onboarding。进入后复用已经取得的实际材料，不重复询问。
+- 网站支付或 APP 支付确定为 `NOT_SIGNED` 且签约页面材料尚不存在时，只把签约分支置为 `WAITING_USER`；服务/应用分支仍按自身条件推进。`onboarding_only` 不得因此修改项目或切换意图，只在收口时提醒仍需代码开发。若页面和支付能力已存在、仅缺首页、商品页、支付页图片，则在签约材料类别收集并上传；已签约时不再要求这组图片。
+- 截图要求以“支付页”为准；支付页指展示支付宝付款方式，等待用户去支付的页面，不得自行改口为“支付成功页”或要求用户提供文档未定义的页面。
+- `full_process` 按 `../normal/full-process-routing.md` 的完整接入编排先完成 Integration 的实际修改与校验，再进入本流程；不得提前登录、查询或收集产品开通材料。
 
 ---
 
@@ -207,38 +121,62 @@ Step 1: 环境检查 → Step 2: 方案规划 → Step 3: 登录授权
 
 ### Step 1: 环境检查
 
-**必读文档**：
-- `../normal/alipay-cli-env.md` - alipay-cli 检测、安装、验证规范
+先从本 flow 目录执行只读检查：
 
-**脚本**：
-- `../normal/scripts/detect_dev_tool.sh` - 检测 AI 编程工具，输出 DEV_TOOL_NAME 取值
-- `../normal/scripts/common.sh` - shell 公共函数与初始化入口；签约脚本通过 `error_handler.sh` 间接调用 `init_dev_tool_name`
+```bash
+bash ../normal/scripts/alipay_cli_env.sh check
+```
+
+- 唯一 `CLI_ENV:READY`：直接进入 Step 2，不读取完整安装文档。
+- `CLI_ENV:NEEDS_SETUP`：此时才读取 `../normal/alipay-cli-env.md`，按其现有安装、PATH、联网权限和验证规则补齐缺失项，再重跑同一检查；未取得 `READY` 不得进入 Step 2。
+- 其他输出、非 0 或 marker 冲突：停在本步骤核对脚本，不得猜测环境已就绪。
 
-**任务**：
-1. 检查 alipay-cli 是否安装，未安装则自动安装
-2. 确认 AI 编程工具检测脚本可用；签约脚本执行时会通过公共初始化设置 DEV_TOOL_NAME
-3. 有任务工具时创建7个任务：环境检查、方案规划、登录授权、状态与资源查询、一次性资料与资源决策、入驻推进、本轮流程收口；没有 `TaskCreate` / `TaskUpdate` 时，不在本步骤单独输出待办，直接把 Step 2 一次性方案确认中的完整待办作为用户可见清单并在后续更新
-4. 初始化内存状态
+签约脚本仍通过 `error_handler.sh -> common.sh` 初始化 `DEV_TOOL_NAME`、`PLATFORM` 和当前 `run_id` 对应的 `PLATFORM_ID`。有任务工具时只在内部记录实际阶段，不手工维护任务数量；只保留当前对话所需最小上下文，不创建业务进度文件。
+
+本步骤成功时不输出“环境检查完成”“任务已创建”等对客消息，直接进入 Step 2；只有安装失败、权限不足或缺少必需工具时才输出实际问题和恢复动作。
 
 工具能力差异不得导致任务、步骤或完成状态被省略。
 
 ### Step 2: 方案规划
 
-**必读文档**：
-- `modules/mcc-reference.md` - MCC类目参考表
-
 **产品匹配规则**：
 
 | 场景关键词 | 推荐产品 |
 |-----------|----------|
 | AI、智能体、大模型、Agent、MCP | 按量付费 |
 | 网站、网页、PC、电脑、电商、商城、H5 | 网站支付 |
-| APP、应用内支付、手机APP | APP支付 |
+| APP、应用内支付、手机 APP | APP 支付 |
+
+产品能够从用户已提供的产品名称或业务描述中可靠映射时直接使用，不重复询问。仍无法唯一确定时，只执行下列固定消息命令；renderer stdout 是本轮唯一对客正文，必须把 stdout 原文作为当前回复正文发给用户，发出后立即停止并等待用户回复产品名称或明确业务描述。回复后仍无法唯一确定时继续执行同一消息，禁止自由补问或推定产品。
+
+```bash
+printf '%s' '{}' | node ../normal/scripts/render_customer_message.mjs product.clarify --variant DEFAULT
+```
+
+产品明确后，若用户尚未提供经营描述或已知 MCC，只执行 `node ../normal/scripts/onboarding_message_runner.mjs mcc-clarify --product-type "$PRODUCT_TYPE"`，把 stdout 原文作为当前回复正文发给用户并停止本轮。`mcc-clarify` 只用于首次缺少检索输入；用户已经提供任何可检索描述后不得再次调用。
+
+已有经营描述或明确类目时，将其作为 `MCC_SEARCH_QUERY` 执行本地确定性检索；该命令只返回表内匹配行，不对客输出，也不调用远程服务：
+
+```bash
+node ../normal/scripts/onboarding_message_runner.mjs mcc-search --query "$MCC_SEARCH_QUERY" --product-type "$PRODUCT_TYPE"
+```
+
+只有 `matchType=UNIQUE` 时才复用返回的同一行 `mccCode/mccName/qualification`。`MULTIPLE` 或 `candidates` 非空但无法唯一确定时，只执行下列固定候选消息命令，必须把 stdout 原文作为当前回复正文发给用户，发出后立即停止并等待用户回复序号、MCC 二级类目名称或编码；禁止自由补写 MCC 候选表、解释、示例或“是否继续”等近似问法。
+
+```bash
+node ../normal/scripts/onboarding_message_runner.mjs mcc-candidates --query "$MCC_SEARCH_QUERY" --product-type "$PRODUCT_TYPE"
+```
+
+用户回复序号时，只能映射到上一条 `mcc-candidates` stdout 中同一份候选表的对应行；用户回复 MCC 二级类目名称或编码时，必须重新执行 `mcc-search` 并得到 `UNIQUE` 后才可使用。完全无本地候选即 `matchType=NONE` 时，只执行下列 runner 命令；runner 必须输出独立的 `onboarding.mcc.no_match`，不得回退或再次渲染 `onboarding.mcc.clarify`。Agent 必须把 stdout 原文作为当前回复正文发给用户，发出后立即停止。用户下一条输入新的经营描述、MCC 二级类目名称或编码时，必须将该输入作为新的 `MCC_SEARCH_QUERY` 自动重新执行 `mcc-search`：`UNIQUE` 继续方案确认，`MULTIPLE` 输出真实候选，仍为 `NONE` 才再次输出 `onboarding.mcc.no_match`；无需用户输入固定重试口令，不得继续猜测或追加近似候选。
+
+```bash
+node ../normal/scripts/onboarding_message_runner.mjs mcc-candidates --query "$MCC_SEARCH_QUERY" --product-type "$PRODUCT_TYPE"
+```
 
 产品确定后，`salesCode`、`scope` 和材料要求统一取自“一、产品映射”，禁止在本步骤另建映射或改写固定值。
 
 **MCC类目**：
-- 读取 `modules/mcc-reference.md` 进行语义匹配
+- 正常唯一命中使用 runner 返回的表内原值；只有非唯一命中才按需读取 `modules/mcc-reference.md`
 - 示例：互联网综合电商平台 (A0002_B0114)
 - mccCode 格式：`Axxxx_Bxxxx`
 
@@ -249,94 +187,194 @@ Step 1: 环境检查 → Step 2: 方案规划 → Step 3: 登录授权
 1. 产品名称、`salesCode` 和授权 `scope`。
 2. MCC 名称与编码。
 3. 当前产品在“未签约”或“需要新建应用”时可能需要的条件材料；不在状态查询前要求用户确认材料齐备状态。
-4. 已识别的接入意图和完整待办步骤。
-5. 即将生成支付宝授权链接，以及当前流程后续实际适用的外部授权或公钥确认。不得在此混入或重复展示集成流程、沙箱付款动作或集成待办。
+4. 固定展示企业账号暂不支持通过 Skill 完成产品开通，并引导前往支付宝商家平台；这只是边界预告，不新增账号类型问题。用户已经明确表示使用企业账号时不得继续展示可确认方案，改走入口处的停止分支。
 
-只集中补问无法可靠识别的产品、业务类型或 MCC。用户已经明确提供的信息不得重复询问，但未经用户明确确认不得执行 `login`。登录后必须先执行 Step 3.1 的只读查询，再根据实际结果收集签约、服务和应用分支的必要资料。
+方案确认必须使用 `../normal/json/customer-messages.json` 的 `onboarding.plan.confirm` 当前产品变体，并执行下列命令渲染；`<VARIANT>` 只能是 `AIPAY`、`WEBPAY` 或 `APPPAY`。三个变体都固定展示企业账号边界和支付宝商家平台链接，不得删减或改写。MCC 名称、编码和特殊资质必须逐字来自 runner 唯一命中或 `mcc-reference.md` 的同一行，并通过 renderer 交叉校验；特殊资质为 `-` 时固定显示“当前类目参考表未列出”，不得解释为企业/个人资格结论。禁止自由补充主体资格、营业执照、审核规则或其他模板未列出的前提。用户明确表示企业账号要通过 Skill 完成产品开通时，改用 `onboarding.enterprise.unsupported` 并停止产品开通，不得继续生成授权或收集材料。用户要求修改产品或 MCC 时重新渲染完整摘要；旧回复失效。字段齐备后不得先输出产品判断、材料预告、企业账号提示或待办；renderer stdout 是 Step 2 唯一对客消息，必须把 stdout 原文作为当前回复正文发给用户，发出后立即停止本轮。
+
+```bash
+MESSAGE_INPUT_JSON=$(jq -cn \
+  --arg mccCode "$MCC_CODE" \
+  --arg mccName "$MCC_NAME" \
+  --arg mccQualification "$MCC_QUALIFICATION" \
+  '{mccCode:$mccCode,mccName:$mccName,mccQualification:$mccQualification}')
+printf '%s' "$MESSAGE_INPUT_JSON" \
+  | node ../normal/scripts/render_customer_message.mjs onboarding.plan.confirm --variant <VARIANT>
+```
 
-<INTERNAL_BLOCKING_CONFIRMATION>
+产品无法可靠识别时只使用上方 `product.clarify`；产品明确但尚无 MCC 检索输入时只使用一次 `mcc-clarify`；有相似候选或完全无候选时都使用 `onboarding_message_runner.mjs mcc-candidates`，由 runner 分别输出候选或 `onboarding.mcc.no_match`。产品与 MCC 都明确后才进入方案确认。用户已经明确提供的信息不得重复询问，但未经用户明确确认不得执行 `login`。登录后必须先执行 Step 3.1 的只读查询，再根据实际结果收集签约、服务和应用分支的必要资料。
 
-必须等待用户明确确认产品、MCC、授权范围和签约执行范围。确认信息有误时先更新并重新展示受影响内容。`full_process` 的项目状态回答、integration 产品确认和服务声明确认均不能替代本确认；已经取得材料时，继承实际图片引用、APP 名称、缺失项和校验结果，不重复采集，但仍需完成本步骤的签约方案确认。缺少实际入参或校验证据时必须补齐。产品、MCC 或执行范围发生变化时必须重新确认受影响内容。
+**阻塞规则（执行约束，不是对客正文）**：必须等待用户明确确认产品、MCC 和授权范围。确认信息有误时先更新并重新渲染标准消息；`full_process` 的项目状态回答、代码开发确认和服务声明确认均不能替代本确认。已经取得材料时继承实际图片引用、APP 名称、缺失项和校验结果，不重复采集，但仍需完成本步骤确认。缺少实际入参或校验证据时必须补齐；产品或 MCC 变化后旧回复失效。
 
-</INTERNAL_BLOCKING_CONFIRMATION>
+`full_process` 的完整接入启动确认不能替代本确认；MCC 或产品变化后必须重新确认。只有输入 `1` 表示确认，其他输入按问题、修改或补充处理。
 
 ### Step 3: 登录授权
 
-**必读文档**：
-- `modules/authorization.md` - 登录授权模块
+用户确认方案后读取 `modules/authorization.md`，只调用本节 `auth.sh init|open|wait|confirm|mismatch` 命令；禁止直调 `alipay-cli login`、解析原始输出或展示 `verification_url`。
 
-**脚本**：
-- `modules/scripts/auth.sh` - 登录授权全流程（init / confirm / mismatch）
+取得当前方案摘要的有效 `1` 后，先执行 `node ../normal/scripts/telemetry.mjs stage onboarding.user_confirmed --root-intent "$ROOT_INTENT" --product-type "$PRODUCT_TYPE"`；开始授权脚本前，再执行 `node ../normal/scripts/telemetry.mjs stage onboarding.auth.start --root-intent "$ROOT_INTENT" --product-type "$PRODUCT_TYPE"`。这两个事件只记录阶段起点，不替代登录、scope 或 MCC 完成条件。
+
+这些脚本是联网命令，首次执行即按 `../normal/alipay-cli-env.md` 申请权限。`AUTH_FLOW:RETRY_WITH_NETWORK` 只表示当前执行环境无法确认结果：取得权限后重试同一完整命令，不得解释为用户本机或支付宝业务失败，也不得改为手工 logout/login。
 
-**授权前确认继承**：Step 2 的一次性方案确认满足 `modules/authorization.md` 第三节的授权前确认要求。必须确认同一产品和 MCC 已得到用户明确确认；没有有效确认时仍禁止执行 `login`，不得因 `full_process` 阶段衔接绕过该红线。
+Step 2 的方案确认是授权前置；产品或 MCC 未有效确认时禁止 login，`full_process` 也不得绕过。
+
+`auth.sh init --defer-open` 和 `app.sh key --defer-open` 先校验 URL 并输出页面说明；Agent 把 stdout 原文作为独立对客消息送达后，立即执行对应 open 子命令使用受控 opener，不新增确认。具体中性文案和兜底见对应模块，不改变 MCP 契约。
 
 **完整流程**：
 ```
-1. bash modules/scripts/auth.sh init --scope "$SCOPE" --sales-code "$SALES_CODE" --mcc-code "$MCC_CODE" --product-name "$PRODUCT_NAME" --mcc-name "$MCC_NAME"
-   ├─ AUTH_FLOW:SKIP → 当前登录有效且目标产品 scope、MCC 均已校验通过，进入 Step 3.1
-   ├─ AUTH_FLOW:READY → 未登录，自动 login + 输出授权信息表格，再执行第 2-3 项
-   ├─ AUTH_FLOW:SCOPE_MISMATCH / MCC_MISMATCH → 停止当前操作，执行第 4 项
+1. bash modules/scripts/auth.sh init --defer-open --scope "$SCOPE" --sales-code "$SALES_CODE" --mcc-code "$MCC_CODE" --product-name "$PRODUCT_NAME" --mcc-name "$MCC_NAME"
+   ├─ AUTH_FLOW:SKIP → 进入 Step 3.1并复用合法签约查询事实
+   ├─ AUTH_FLOW:READY_TO_OPEN → 输出非阻塞授权页，执行第 2 项
+   ├─ AUTH_FLOW:SCOPE_MISMATCH / MCC_MISMATCH → 执行第 4 项
+   ├─ AUTH_FLOW:RETRY_WITH_NETWORK → 取得联网权限后重试同一完整命令
    └─ AUTH_FLOW:FAILED → 停止并按错误输出恢复，禁止进入 Step 3.1
-2. 仅 AUTH_FLOW:READY：等待用户回复"好了"确认授权完成
-3. 仅 AUTH_FLOW:READY：bash modules/scripts/auth.sh confirm --scope "$SCOPE" --sales-code "$SALES_CODE" --mcc-code "$MCC_CODE" --product-name "$PRODUCT_NAME" --mcc-name "$MCC_NAME"
-   ├─ AUTH_FLOW:AUTH_SUCCESS → 进入 Step 3.1
-   ├─ AUTH_FLOW:PENDING → 等待用户完成授权，禁止自动轮询
+2. 仅 AUTH_FLOW:READY_TO_OPEN：把 init 的 stdout 原文作为独立对客消息送达后，立即执行 bash modules/scripts/auth.sh open --scope "$SCOPE" --sales-code "$SALES_CODE" --mcc-code "$MCC_CODE" --product-name "$PRODUCT_NAME" --mcc-name "$MCC_NAME"；open 无对客 stdout，打开失败不影响已交付 URL。随后执行 bash modules/scripts/auth.sh wait --scope "$SCOPE" --sales-code "$SALES_CODE" --mcc-code "$MCC_CODE" --product-name "$PRODUCT_NAME" --mcc-name "$MCC_NAME"
+   ├─ open 返回 AUTH_FLOW:CONTEXT_MISMATCH → 不执行 wait；使用当前已确认的完整参数重新执行第 1 项
+   ├─ open 返回 AUTH_FLOW:FAILED → 停止并按错误输出恢复，禁止执行 wait 或进入 Step 3.1
+   ├─ open 返回 AUTH_OPEN:OPENED|OPEN_FAILED|GUI_UNAVAILABLE|LINK_ONLY → 继续执行 wait；后 3 种只表示 opener 结果，不影响已交付 URL
+   ├─ 最多 12 次、间隔 5 秒；成功或过期立即停止
+   ├─ AUTH_FLOW:AUTH_SUCCESS → 进入 Step 3.1并复用合法签约查询事实
+   ├─ AUTH_FLOW:PENDING → 输出 auth.pending，等待扫码后输入 `1`
    ├─ AUTH_FLOW:EXPIRED → 重新执行第 1 项生成授权链接
+   ├─ AUTH_FLOW:CONTEXT_MISMATCH → 当前动作未执行 login --complete/logout；使用当前已确认的完整参数重新执行第 1 项
+   ├─ AUTH_FLOW:RETRY_WITH_NETWORK → 取得联网权限后重试同一完整命令
    ├─ AUTH_FLOW:FAILED → 停止并按错误输出恢复，禁止进入 Step 3.1
-   └─ AUTH_FLOW:SCOPE_MISMATCH / MCC_MISMATCH → 停止当前操作，执行第 4 项
-4. bash modules/scripts/auth.sh mismatch --scope "$SCOPE" --sales-code "$SALES_CODE" --mcc-code "$MCC_CODE" --product-name "$PRODUCT_NAME" --mcc-name "$MCC_NAME"
-   └─ 由 mismatch 统一执行一次 logout；成功后使用正确 scope 重新生成授权链接
+   └─ AUTH_FLOW:SCOPE_MISMATCH / MCC_MISMATCH → 执行第 4 项
+3. 仅 PENDING 后输入 `1`：执行一次 bash modules/scripts/auth.sh confirm --scope "$SCOPE" --sales-code "$SALES_CODE" --mcc-code "$MCC_CODE" --product-name "$PRODUCT_NAME" --mcc-name "$MCC_NAME"；同第 2 项转移，PENDING 继续等待且不重启轮询
+4. bash modules/scripts/auth.sh mismatch --defer-open --scope "$SCOPE" --sales-code "$SALES_CODE" --mcc-code "$MCC_CODE" --product-name "$PRODUCT_NAME" --mcc-name "$MCC_NAME"
+   ├─ AUTH_FLOW:READY_TO_OPEN → 输出非阻塞授权页并按第 2 项执行 open + wait
+   ├─ AUTH_FLOW:CONTEXT_MISMATCH → 未执行 logout；使用当前已确认的完整参数重新执行第 1 项
+   ├─ AUTH_FLOW:RETRY_WITH_NETWORK → 取得联网权限后重试同一完整命令
+   └─ mismatch 统一 logout；成功后用正确 scope 重建授权页
 ```
 
-> `confirm` / `mismatch` 优先使用显式传入的非敏感授权上下文。这样即使 Agent 在沙箱化执行环境和可联网执行环境之间切换，也不依赖临时状态文件是否可见。
+`AUTH_FLOW:CONTEXT_MISMATCH` 适用于 `open|wait|confirm|mismatch` 的显式上下文与同一次 init 短时状态不一致；脚本必须在任何 `login --complete/logout` 前停止且不输出对客正文。Agent 不得忽略差异、改用旧状态继续或手工清理状态；必须立即用当前 Step 2 已确认的完整参数重新执行第 1 项。新的 init 先完成固定产品/MCC 机器校验，再安全替换旧短时状态；若 CLI 仍处于登录态，因为签约查询没有权威 MCC 字段，init 必须返回对应 `SCOPE_MISMATCH/MCC_MISMATCH` 并转第 4 项，不得返回 `SKIP`。CLI 未登录时直接生成当前上下文的新授权页。两种分支都不得复用旧 deviceCode 或新增用户确认。
+
+`auth.page` 非阻塞并追加“扫码完成后请回到 Agent 对话页面”；`auth.pending` 仅由 wait 耗尽或单次 confirm 的 PENDING 渲染，其他对客终态由脚本渲染对应消息。自动轮询期间即使 `login --complete` 已返回可复核状态，只要 `whoami` 尚未取得有效本机登录态，也继续按 PENDING 处理并消耗本次 wait 预算，不输出断头失败文案。剔除 `ALIPAY_AIPAY_INTERNAL:` 内部行后的 stdout 是当前动作唯一对客正文；禁止再次调用 renderer、另写近似话术、输出 stderr 或内部行、重复转述。授权脚本明确返回链接过期时必须重建，旧回复失效。
 
 授权 `scope` 统一使用“一、产品映射”中当前产品的固定值，禁止自行修改。
 
-**⚠️ 授权信息展示规范**：执行前必须读取 `modules/authorization.md` 第 5.2～6.2 节，并原样展示 `auth.sh init` 输出，禁止简写、重排或改写。该章节是完整约束来源：产品类型、经营类目、确认码和有效期四项必须展示；必须校验 `deviceCode` / `productCode` / `mccCode` 完整且仅把 `platform` 作为可选参数；禁止展示 CLI `verification_url`、半成品或裸链接；确认码只用于核对，禁止引导用户输入验证码。
+授权页完整约束见 `modules/authorization.md` 第 5.2～6.2 节；必须原样展示 init stdout，并在 login 前完成固定产品/MCC 上下文和 URL 逐项校验。禁止 CLI `verification_url`、非登记 URL 或要求用户输入确认码。
 
 #### Step 3.1: 状态与资源查询（登录授权后置检查）
 
 **只读查询组**：登录成功后自动连续执行，不增加“是否查询”确认：
 
-查询前按当前产品读取最小必要章节：`modules/product-sign.md` 的“签约状态查询”、`modules/app-release.md` 的“阶段 2: 查询已有应用”；按量付费同时读取 `modules/service-registration.md` 的 Step 1、Step 2 和“服务状态说明”。Step 5 再按实际写操作分支读取对应模块的提交、创建、修改、公钥或审核章节，不提前加载无关写操作内容，也不重复读取已经读过且未变化的查询章节。
+开始执行任一签约、应用或服务只读查询前，先执行 `node ../normal/scripts/telemetry.mjs stage onboarding.discovery.start --root-intent "$ROOT_INTENT" --product-type "$PRODUCT_TYPE"`。
 
-1. 执行 `bash modules/scripts/query_sign_status.sh --sales-code "$SALES_CODE" --product-type "$PRODUCT_TYPE"` 查询当前产品签约状态。
-2. 执行 `bash modules/scripts/app.sh list --product-type "$PRODUCT_TYPE" --sales-code "$SALES_CODE"` 查询当前登录账号下与当前产品所需应用类型匹配的候选应用。该接口按 `WEBAPP` / `MOBILEAPP` 查询，不得宣称返回应用已与当前支付产品绑定。
-3. 仅按量付费再执行 `bash modules/scripts/service.sh list` 查询已有服务。
+授权成功后执行全部适用只读查询，不增加确认。当前 Agent 支持安全并发工具调用时可并行发起签约、应用和适用服务查询；不支持并发时按下列固定顺序连续执行。每项查询前只读取对应模块的查询章节；全部查询结束后，只有取得成功结果的分支可以继续，失败分支按错误规则恢复。
 
-> ⚠️ 脚本通过 `error_handler.sh` 间接初始化 `DEV_TOOL_NAME`；签约查询必须传入当前产品的 `--sales-code`，建议同时传入 `--product-type`（aipay|webpay|apppay）做一致性校验。网站支付和 APP支付使用不同 salesCode，禁止混用。
+Step 5 只读取当前实际推进的签约、服务或应用模块；错误恢复时才读取 `error-handling.md`。不得提前加载其他分支，也不重复读取已经读过且未变化的章节。
+
+1. 读取 `product-sign.md` 查询章节。若本次成功的 `auth.sh init|wait|confirm` 内部事实同时且唯一包含 `AUTH_SIGN_QUERY_REUSABLE=true`、合法 `SIGN_STATUS` 和匹配当前产品的 `FLOW:*`，直接复用这些事实；三者缺失、冲突、重复或解析失败时，必须执行 `bash modules/scripts/query_sign_status.sh --sales-code "$SALES_CODE" --product-type "$PRODUCT_TYPE"`，禁止猜测或沿用历史结果。复用只省略同一请求的重复调用，不省略签约分支错误检测和状态处理。
+2. 仅按量付费读取 `service-registration.md` 的查询章节，执行 `bash modules/scripts/service.sh list`。成功时保存唯一 `SERVICE_CANDIDATES_JSON`、全部 `SERVICE_CANDIDATE_ID` 和 `FLOW:*` 内部事实，不对客展示候选。
+3. 读取 `app-release.md` 的查询章节，执行 `bash modules/scripts/app.sh list --product-type "$PRODUCT_TYPE" --sales-code "$SALES_CODE"`。成功时保存唯一 `APP_CANDIDATES_JSON`、`APPLICATION_TYPE`、全部适用 `APP_CANDIDATE_ID` 和 `FLOW:*` 内部事实，不对客展示候选。该接口按 `WEBAPP` / `MOBILEAPP` 查询，不得宣称返回应用已与当前支付产品绑定。
+
+> ⚠️ 脚本通过 `error_handler.sh` 间接初始化 `DEV_TOOL_NAME` 和当前 `run_id` 对应的 `PLATFORM_ID`；签约查询必须传入当前产品的 `--sales-code`，建议同时传入 `--product-type`（aipay|webpay|apppay）做一致性校验。网站支付和 APP 支付使用不同 salesCode，禁止混用。
 
 各适用查询仍是独立 CLI/MCP 调用，必须分别完成原有错误检测，禁止伪造合并 MCP。失败后按错误类型处理：
 
+所有内部事实行都必须以 `ALIPAY_AIPAY_INTERNAL:` 开头；宿主合并 stdout/stderr 时也逐行剔除。无前缀的相似文本不得作为流程事实；唯一字段缺失、重复或冲突时按结构异常处理。
+
 - MCP 认证失败或产品/scope/MCC 授权不匹配：立即停止查询组，不再调用剩余查询；授权不匹配时调用 Step 3 的 `auth.sh mismatch`，由该命令统一 logout 并重新授权。重新授权后仅恢复尚未执行的查询，保留重新授权前已经成功取得且主体未变化的结果。若无法确认仍为同一账号主体，则重新执行全部适用查询。
 - 单个业务失败、响应结构错误或 MCP 服务失败，但当前会话仍有效：把该分支标记为查询失败，继续其他不依赖该结果的只读查询，最后一次性输出“已取得结果 + 失败分支”摘要。不得把失败视为空列表；应用查询失败时禁止应用复用/创建，服务查询失败时禁止服务复用/新建/修改。
-- 签约查询失败：可继续应用/服务查询、候选展示、资源决策及其独立资料采集；不得推断签约状态，不得采集签约截图或签约所需 APP 名称，`signStatus` 和签约 `materialStatus` 保持未设置，并暂停 Step 5 的全部 onboarding 外部写操作。签约查询成功后，只有状态为 `NOT_SIGNED` 才补充采集对应签约材料，再恢复尚未执行的分支。
+- 签约查询失败：只阻断签约分支；可继续应用/服务查询、候选展示、资源决策及其独立资料采集和写操作。不得推断签约状态，不得采集签约截图或签约所需 APP 名称，`signStatus` 和签约 `materialStatus` 保持未设置。签约查询恢复成功后，只有状态为 `NOT_SIGNED` 才进入签约材料类别。应用或服务查询失败也只阻断对应分支；认证失败、授权不匹配或无法确认登录主体一致时仍是全局阻断。
 
 任何恢复都不得要求用户重交未变化且已验证的资料，也不得重做不受会话主体变化影响的成功步骤。
 
 签约状态和 `FLOW:*` 映射只按 `modules/product-sign.md` 的“签约状态查询”执行：`SIGNED_EFFECTIVE` 与 `SIGN_SUBMITTED` 均禁止重复提交签约；`OTHER_STATUS` 不提交签约，只展示已确认结果和待核验项。Step 4 再根据脚本输出的实际状态收集签约材料并处理应用/服务候选。
 
-### Step 4: 一次性资料与资源决策
+### Step 4: 分支摘要与分类材料
+
+先使用 `onboarding_message_runner.mjs discovery-summary` 展示查询摘要：签约、服务市场、应用发布各一行；网站支付和 APP 支付的服务市场由 runner/renderer 固定为“无需处理”。状态只能来自本轮脚本结果，查询失败必须显示“查询失败”，不得当作空列表。
 
-将 Step 3.1 已成功取得的签约状态、应用候选和按量付费服务候选合并展示，并计算当前已知分支的必需资料。用户应能在一条回复中完成服务/应用选择和所有可确定的必要资料提供；只补问缺失或校验失败字段。签约状态尚未取得时，签约资料需求仍未知，不得提前采集或混入应用/服务资料包。
+runner 入参必须传脚本原始状态标记，禁止手写 `signingStatus`、`serviceStatus`、`applicationStatus` 等 renderer 枚举字段，禁止把候选数量、应用类型、`appId`、服务 ID 或解释性长句写入标准消息字段：
+
+- `signStatus` 只允许 `NOT_SIGNED|SIGN_SUBMITTED|SIGNED_EFFECTIVE|OTHER_STATUS|QUERY_FAILED`。
+- `serviceFlow` 仅按量付费传入，只允许 `FLOW:CREATE_NEW|FLOW:SELECT|QUERY_FAILED`；网站支付和 APP 支付不得构造或传入服务状态字段。
+- `appFlow` 只允许 `FLOW:CREATE_NEW|FLOW:SELECT|FLOW:PENDING_APPLICATIONS|QUERY_FAILED`。
+
+必须执行：
+
+```bash
+if [ "$PRODUCT_TYPE" = "aipay" ]; then
+  MESSAGE_INPUT_JSON=$(jq -cn \
+    --arg signStatus "$SIGN_STATUS" \
+    --arg serviceFlow "$SERVICE_FLOW" \
+    --arg appFlow "$APP_FLOW" \
+    '{signStatus:$signStatus,serviceFlow:$serviceFlow,appFlow:$appFlow}')
+else
+  MESSAGE_INPUT_JSON=$(jq -cn \
+    --arg signStatus "$SIGN_STATUS" \
+    --arg appFlow "$APP_FLOW" \
+    '{signStatus:$signStatus,appFlow:$appFlow}')
+fi
+printf '%s' "$MESSAGE_INPUT_JSON" \
+  | node ../normal/scripts/onboarding_message_runner.mjs discovery-summary --product-type "$PRODUCT_TYPE"
+```
+
+随后按“签约 -> 服务 -> 应用”的默认顺序一次只处理一个实际适用且当前可推进的类别。
+
+轮到服务或应用类别时才执行对应 runner；其 stdout 一次生成候选事实和适用选择提示，是当前唯一对客正文。禁止提前展示、手工拼表、压缩为纯 ID、拆开渲染或改写：
+
+```bash
+# 仅按量付费，轮到服务类别时
+printf '%s' "$SERVICE_CANDIDATES_JSON" \
+  | node ../normal/scripts/onboarding_message_runner.mjs service-candidates
+
+# 轮到应用类别时
+printf '%s' "$APP_CANDIDATES_JSON" \
+  | node ../normal/scripts/onboarding_message_runner.mjs application-candidates --application-type "$APPLICATION_TYPE"
+```
+
+空候选时直接进入新建资料分支；非空时发出 runner stdout 后等待当前候选允许的选择。
+
+每次只展示一个类别的现状、选择和缺失字段；同一类别一次收齐，只补问缺失或校验失败字段。材料收集提示只允许通过 `onboarding_message_runner.mjs material-collect` 输出：签约分支传 `--category signing`，服务分支传 `--category service`，应用分支传 `--category application`。禁止直接调用 renderer 手写 `categoryName`、`currentStatus` 或 `missingFields`，也禁止使用 `签约资料` 等同义词、`mobilePlatform`、`网站支付签约截图` 等自由文本作为 renderer 入参；常见字段别名只能交给 runner 规范化。材料收集提示必须使用：
+
+```bash
+# 当前分支先设置 MATERIAL_CATEGORY，只允许 signing|service|application
+case "$CURRENT_STATUS" in
+  "待补充") MATERIALS_STATE="INITIAL" ;;
+  "部分已提供，待补充") MATERIALS_STATE="PARTIAL" ;;
+  "校验失败，需更正") MATERIALS_STATE="INVALID" ;;
+  *) echo "❌ 未知材料状态，停止渲染" >&2; exit 1 ;;
+esac
+MESSAGE_INPUT_JSON=$(jq -cn \
+  --arg missingFields "$MISSING_FIELDS" \
+  '{missingFields:$missingFields}')
+printf '%s' "$MESSAGE_INPUT_JSON" \
+  | node ../normal/scripts/onboarding_message_runner.mjs material-collect --category "$MATERIAL_CATEGORY" --state "$MATERIALS_STATE" --product-type "$PRODUCT_TYPE"
+```
+
+`INITIAL` 不展示内部状态；`PARTIAL` 固定使用“还需补充”；`INVALID` 固定使用“以下内容需要更正”。renderer 会校验变体与 `currentStatus` 一致，禁止 Agent 自由选用不匹配话术。
+
+用户主动提前提供后续类别材料时立即接收并校验，写入对应类别的已验证材料集合；轮到该类别时不得要求重复提供，只回显校验结果并补问剩余字段。某类别被业务错误阻断时记录该分支恢复动作并继续下一个逻辑独立类别。签约状态尚未取得时，签约资料需求仍未知，不得提前采集签约资料，也不得阻止服务或应用类别推进。
 
 **签约分支**：
 
 - `NOT_SIGNED` 网站支付：一次收集首页、商品页、支付页 3 张截图。
-- `NOT_SIGNED` APP支付：一次收集 APP 名称和首页、商品页、支付页 3 张截图，签约状态仍固定按 `OFFLINE` 提交。
+- `NOT_SIGNED` APP 支付：一次收集 APP 名称和首页、商品页、支付页 3 张截图，签约状态仍固定按 `OFFLINE` 提交。
 - `NOT_SIGNED` 按量付费：签约申请无需上传页面图片。
 - `SIGNED_EFFECTIVE` / `SIGN_SUBMITTED`：不再为签约采集 APP 名称或截图，禁止重复提交签约。
 
 **应用分支**：
 
-- 有 `ON_LINE` 候选时，让用户选择复用序号或新建；复用时不采集新建应用字段。
-- 只有非 `ON_LINE` 应用时，展示实际状态并让用户选择暂不新建或明确新建；禁止自动新建。
-- 列表确实为空或用户选择新建时，按量付费/网站支付一次说明应用公钥要求；APP支付一次收集 `mobilePlatform` 及对应的 `bundleId` / `appPackage` / `appSign`，并同时说明应用公钥要求。这些平台字段可在签约提交前采集和校验，但只能在 Step 5.3 创建应用时使用。
-- 应用公钥原文只能由用户明确提供，不得生成、推断、改写或持久化到资料状态；可在资料状态中只记录“已准备/未准备”。未准备公钥不阻止应用创建，但创建后必须停在设置公钥阶段。
+- `app.sh list` 只提供带统一前缀的内部候选事实；应用类别正文只能由上方 `application-candidates` runner 使用同一快照一次生成。`ON_LINE` 只接受完整 `appId` 或 `新建`；仅非上线候选时由用户选 `暂不新建` 或 `新建`。
+- 列表确实为空或用户选择新建时，按量付费/网站支付一次说明应用公钥要求；APP 支付必须执行下方 `APP_MOBILE_INITIAL` 固定命令，一次展示三个可创建平台组合并要求用户在一条回复中提供所选组合全部资料，禁止先单独询问 `mobilePlatform`。iOS 对应内部值 `mobilePlatform=IOS` 和 `bundleId`，Android 对应 `mobilePlatform=ANDROID`、`appPackage`、`appSign`，iOS + Android 对应 `mobilePlatform=ALL` 及三项字段；这些内部名只用于参数映射，不得作为未解释的对客字段名。字段缺失时使用 `PARTIAL` 和中文字段名，校验失败时使用 `INVALID` 和中文字段名；已通过字段不得重复收集。这些字段可在签约提交前采集和校验，但只能在 Step 5.3 创建应用时使用。HarmonyOS 不收集或编造 `mobilePlatform`、审核材料或 MCP 字段，必须执行 `printf '%s' '{}' | node ../normal/scripts/render_customer_message.mjs application.harmony.manual_create --variant DEFAULT` 并等待当前消息后的 `1`；用户完成开放平台操作后重新查询 `MOBILEAPP` 列表。只有实际返回 `ON_LINE` 候选时进入复用路径，否则应用分支转为人工待办；该等待和待办都不阻断签约及其他事实明确的独立分支。
+
+```bash
+printf '%s' '{}' \
+  | node ../normal/scripts/onboarding_message_runner.mjs material-collect --category application --state APP_MOBILE_INITIAL --product-type "$PRODUCT_TYPE"
+```
+
+APP 支付后续补充提示只允许以下对客字段名，并按用户所选平台计算缺失项：`iOS Bundle ID（bundleId）`、`Android 应用包名（appPackage）`、`Android 应用签名摘要（appSign）`。用户在同一条回复中主动提供应用公钥时直接接收并按公钥红线处理；未提供公钥不阻止创建应用。
+- 应用公钥原文只能由用户明确提供，不得生成、推断或改写；输入只用于当前 `app.sh key/verify-key/verify-key-and-audit` 调用，Agent 不得复述或写入状态/日志。资料状态只记录“已准备/未准备”。未准备公钥不阻止创建，但创建后停在设钥阶段。
+- 目标 `appId` 已确定但用户尚未准备公钥时，自动执行 `bash modules/scripts/download_key_tool.sh`。macOS/Windows 下载到当前用户可写的默认 Downloads 目录并在脚本内部使用 `key_tool.download.result` 展示实际安装包路径、安装引导和 `https://opendocs.alipay.com/isv/02kipk` 手动下载兜底；Linux、目录不可用、网络不可达、依赖缺失、跳转不可信或包校验失败时在脚本内部使用 `key_tool.download.fallback`。该脚本 stdout 是当前动作唯一对客正文，不输出 `DOWNLOADED`、`PATH=`、`DOWNLOAD_FAILED`、`DOWNLOAD_REASON` 等机器标记；只下载，不安装、不启动、不生成密钥。本地 OpenSSL 命令生成方式仍为待定，禁止输出或执行。
+
+**应用候选选择铁律**：存在 `ON_LINE` 候选时只接受当前完整 `appId` 或 `新建`；仅有非上线候选时只接受 `新建` 或 `暂不新建`；列表为空时进入新建资料分支。禁止序号、历史候选或 Agent 自报 ID。复用后始终使用所选完整 ID；`新建` 即为创建确认，不追加回复 `1`。创建前重查列表并用 `application-recheck` 比较前后快照：stdout 为空且资料齐备时创建，非空时旧选择失效并原文发出后重新选择。
 
-**按量付费服务分支**：完整展示服务查询返回的候选及实际状态，不额外按状态过滤复用候选。让用户选择复用序号、新建，或使用 serviceId 修改已有服务。新建/修改时在同一条回复中收集完整五项服务资料；不得自行增加接口文档未定义的服务状态限制。
+**按量付费服务分支**：列表为空时进入新建资料分支；存在候选时只接受当前完整 `serviceId`、`新建` 或 `修改:<当前serviceId>`，拒绝候选外 ID、序号、自由格式修改、Agent 自报或历史 ID。不额外按状态过滤，不单独渲染选择提示；用户可在选择新建/修改时同时提供完整五项资料。
 
-APP支付未签约时的签约字段：
+APP 支付未签约时的签约字段：
 | 字段 | 必填条件 | 说明 |
 |------|----------|------|
 | APP名称 | 必填 | 传入 `ar_sign_apply.sh --app-name` |
@@ -345,38 +383,65 @@ APP支付未签约时的签约字段：
 **脚本**：
 - `bash modules/scripts/upload_screenshots.sh <img1> <img2> <img3>` - 上传3张截图；用户可拖拽上传图片，Agent 将拖拽后的本地文件路径传给脚本
 
-上传成功后按首页、商品页、支付页顺序记录三个图片引用；APP支付同时保留已校验的 APP 名称。
+上传成功时只把脚本 stdout 的“截图上传成功”原文对客；从带统一前缀的 `SCREENSHOT_HOME_REF`、`SCREENSHOT_SHOP_REF`、`SCREENSHOT_PAY_REF` 内部事实按首页、商品页、支付页顺序记录三个图片引用，严禁对客展示这些引用或 `collect_information` 等内部状态。APP 支付同时保留已校验的 APP 名称。
 
-### Step 5: 入驻推进
+### Step 5: 产品开通推进
 
-**按分支读取文档**：
-- `NOT_SIGNED`：读取 `modules/product-sign.md` 的签约提交、提交后推进和错误处理章节。
-- 按量付费且处理服务：读取 `modules/service-registration.md` 中当前决策对应的收集、校验、提交或复用章节。
-- 处理应用：读取 `modules/app-release.md` 中当前决策对应的复用、创建、公钥设置或提审章节。
-- 已在 Step 3.1 读取且内容未变化的查询章节不重复读取；不适用的产品或分支不读取。
+只读取当前实际推进的 `product-sign.md`、`service-registration.md` 或 `app-release.md` 动作章节；已读且未变化的查询章节不重复读取。
 
-**外部写操作确认**：执行本步骤中的 `ar_sign_apply.sh`、`service.sh save`、`app.sh create`、`app.sh key` 或 `app.sh audit` 前，必须展示当前有效登录会话、可用的脱敏主体标识、产品、动作和目标资源摘要。签约摘要包含 MCC 和材料状态；服务摘要包含目标 `serviceId`（新建时标明新建）、服务名称、地址和单价；应用创建摘要包含应用类型和适用的平台字段；设置应用公钥只展示 `appId`，禁止回显公钥原文；应用提审展示 `appId`。不得展示私钥、token、Payment-Proof、截图内容或完整签名串。
+签约状态为 `NOT_SIGNED` 时，材料缺失/错误继续使用 `materials.category.collect`，完整通过后直接执行 5.1，不增加回复 `1`。服务资料通过后展示非阻塞 `service.create.summary` 并创建；仅修改需要确认。应用创建复用当前候选后的“新建”选择；用户公钥直接交给 `app.sh key --defer-open` 生成官方页面，页面 stdout 独立送达后执行 `app.sh open-key-page`。新建应用在页面确认后直接执行 `app.sh verify-key-and-audit`，复用最后一次成功密钥响应完成 guard 并提审，不增加回复 `1`。
 
-<INTERNAL_BLOCKING_CONFIRMATION>
+服务创建信息固定使用 `../normal/json/customer-messages.json` 的 `service.create.summary`。该消息非阻塞，只传入即将提交的五项服务资料；renderer 成功后同一流程直接执行 5.2 创建命令。必须执行：
 
-只有用户在看到同一有效登录会话、产品、动作和目标摘要后明确确认，才能执行对应写操作。CLI 未返回主体标识时，必须明确提示并让用户确认当前登录账号就是操作目标。用户对该摘要的资源选择或明确执行回复可以直接复用；启动确认、其他目标或动作的确认、沉默和仅提供资料均不能替代。登录会话、主体、产品、动作、目标或关键金额变化时必须重新确认。
+```bash
+MESSAGE_INPUT_JSON=$(jq -cn \
+  --arg serviceName "$SERVICE_NAME" \
+  --arg serviceDescription "$SERVICE_DESCRIPTION" \
+  --arg serviceUrl "$SERVICE_URL" \
+  --arg servicePricing "$SERVICE_PRICING" \
+  --arg serviceSchema "$SERVICE_SCHEMA" \
+  '{serviceName:$serviceName,serviceDescription:$serviceDescription,serviceUrl:$serviceUrl,servicePricing:$servicePricing,serviceSchema:$serviceSchema}')
+printf '%s' "$MESSAGE_INPUT_JSON" \
+  | node ../normal/scripts/render_customer_message.mjs service.create.summary --variant DEFAULT
+```
+
+服务修改的外部写确认固定使用 `onboarding.write.confirm/SERVICE_UPDATE_ONLY`。`MESSAGE_INPUT_JSON` 必须由当前摘要字段通过 `jq -cn --arg` 构造，禁止手写拼接包含用户值的 JSON：
+
+```bash
+MESSAGE_INPUT_JSON=$(jq -cn \
+  --arg sessionSummary "$SESSION_SUMMARY" \
+  --arg subjectSummary "$SUBJECT_SUMMARY" \
+  --arg productName "按量付费" \
+  --arg actionTypes "服务修改" \
+  --arg serviceId "$SERVICE_ID" \
+  --arg serviceName "$SERVICE_NAME" \
+  --arg serviceDescription "$SERVICE_DESCRIPTION" \
+  --arg serviceUrl "$SERVICE_URL" \
+  --arg servicePricing "$SERVICE_PRICING" \
+  --arg serviceSchema "$SERVICE_SCHEMA" \
+  '{sessionSummary:$sessionSummary,subjectSummary:$subjectSummary,productName:$productName,actionTypes:$actionTypes,serviceId:$serviceId,serviceName:$serviceName,serviceDescription:$serviceDescription,serviceUrl:$serviceUrl,servicePricing:$servicePricing,serviceSchema:$serviceSchema}')
+printf '%s' "$MESSAGE_INPUT_JSON" \
+  | node ../normal/scripts/render_customer_message.mjs onboarding.write.confirm --variant SERVICE_UPDATE_ONLY
+```
+
+创建摘要和修改确认中的参数必须逐字来自本轮用户材料及即将执行的脚本参数；服务单价以 `service.sh validate` 输出的带统一前缀 `SERVICE_PRICING=<纯数字>` 内部事实为准并原样复用到 renderer 和 `service.sh save`，不得重新追加 `元/次` 或说明文字，模板会展示单位。修改确认的会话、脱敏主体和 `serviceId` 还必须来自本轮实际查询。renderer 必须拒绝 variant/动作不匹配、缺字段、多传无关字段、非按量付费服务修改、非法单价或非法 JSON。禁止加入未列动作。创建摘要不得要求用户回复或停止流程；修改时用户输入 `1` 后先核对摘要仍未变化，再执行固定修改命令，其他输入不代表确认。目标、参数、登录会话或主体变化时旧修改确认立即失效并重新展示。签约提交、服务创建、应用创建和应用提审不得使用 `onboarding.write.confirm` 重复确认。
+
+脚本使用 `network_retry.sh` 时，业务错误只调用一次；网络/服务错误最多自动重试两次、每次间隔 3 秒。非幂等写结果为 `MAYBE_SENT` 时停止重试，使用现有只读查询核验；无法确认时明确输出未知结果，禁止盲目重复写入。自动重试预算耗尽后不立即询问“重试/退出”：记录失败动作、受影响分支和恢复方式，依赖允许时继续其他独立分支，并在 Step 6 一次收口所有仍未恢复的分支。
 
-</INTERNAL_BLOCKING_CONFIRMATION>
+**阻塞规则（执行约束，不是对客正文）**：服务创建不进入阻塞确认；五项资料完整、格式校验通过且服务数量上限检查通过后，展示 `service.create.summary` 并直接创建。只有服务修改必须在同一有效登录会话、产品、动作和目标摘要后等待用户输入 `1`；CLI 未返回主体标识时，标准摘要必须说明由用户确认当前登录账号就是操作目标。启动确认、其他目标或动作的确认、沉默和仅提供资料均不能替代修改确认。签约提交不进入本阻塞确认：只有签约状态为 `NOT_SIGNED` 且当前产品所需材料全部完整并校验通过时才直接执行，缺失或校验失败继续材料提示。应用创建只接受本轮当前候选列表后的明确 `新建` 选择，候选变化必须重新选择；`app.sh key --defer-open` 仅生成公钥确认页，用户提供完整公钥后直接调用，页面 stdout 独立送达后执行 `app.sh open-key-page`，最终设置仍由用户在官方页面确认；新建应用的公钥校验成功后直接提审。登录会话、主体、产品、服务修改目标或关键金额变化时必须重新确认。服务修改确认 renderer stdout 是该动作唯一对客消息，必须把 stdout 原文作为当前回复正文发给用户，发出后立即停止本轮。
 
-写操作失败或响应不明时，先查询实际状态再决定是否重试，禁止直接重复提交。只有相邻写操作的目标和摘要都已经确定时才能合并确认；应用创建时尚不存在的 `appId`、公钥确认结果或审核状态不得提前授权。
+写失败或响应不明先按现有只读能力核验，禁止直接重复；尚不存在的 `appId`、公钥确认或审核结果不能提前授权。
 
-**写操作顺序**：Step 3.1 的应用/服务查询和 Step 4 的资料采集只是前置发现与准备，不改变原写操作顺序。只有签约查询成功并得到 `NOT_SIGNED`、`SIGNED_EFFECTIVE` 或 `SIGN_SUBMITTED` 后，才允许执行 Step 5 的 onboarding 外部写操作；查询失败或状态为 `OTHER_STATUS` 时保持全部写操作阻断并先核验签约状态。当 `signStatus=NOT_SIGNED` 时，必须先完成 5.1 签约提交，成功后才执行 5.2 服务创建/修改和 5.3 应用复用/创建等操作。已签约或已提交签约时跳过 5.1。
+登录、scope、MCC 是共同前置；之后三分支按自身查询、材料、选择和确认独立推进，单分支失败不阻断或回滚其他分支。默认按 5.1/5.2/5.3 串行，但不得把顺序当作签约成功依赖。认证、授权或主体变化时全局停止新操作并重新校验。
 
-**按量付费入驻产物关系**：
-- 产品签约负责开通按量付费能力，使用 `salesCode=I1080300001000160457` 和 `scope=app:all,machine_pay:write,agmnt:write`。
-- 服务市场注册负责生成或复用按量付费服务，服务信息中的服务单价、服务地址和请求示例用于正式环境配置与收银。
-- 应用发布负责生成或复用 `WEBAPP` 应用，并取得正式集成所需的 `appId`、应用私钥对应的应用公钥配置状态、支付宝公钥。
-- 正式环境按量付费配置中，`sellerId` 来自商户 PID/2088，服务市场注册结果中的真实 `serviceId` 作为正式环境产物保留，在跨流程上下文中标记为 `productionServiceId`（仅用于区分用途，不改变 MCP 的 `serviceId` 字段名）；`appId/alipayPublicKey` 来自应用发布或复用结果。`full_process` 进入 onboarding 前已经完成 integration 沙箱联调，取得这些正式产物后不得重新进入 integration 或重复沙箱测试，只需把生产配置替换列为上线待办。`onboarding_only` 后续另行进入 integration 时，沙箱联调仍固定使用 `api_mock_service_id`，不得使用 `productionServiceId` 或再次向用户索要 `serviceId`；正式上线前再替换为已保留的 `productionServiceId`。
+**按量付费产物**：签约固定使用 `salesCode=I1080300001000160457`、`scope=app:all,machine_pay:write,agmnt:write`；服务分支产出真实 `productionServiceId`，应用分支产出 `WEBAPP` 的 `appId`、公钥配置/支付宝公钥状态，正式 `sellerId` 来自 PID/2088。`productionServiceId` 只是跨流程用途名，不改 MCP 字段；沙箱始终使用 `api_mock_service_id`。`full_process` 只记录生产替换待办，不返回 integration 或重跑沙箱；后续独立 integration 也先用 mock，正式上线再替换。
 
 
 #### 5.1 产品签约
 
-仅 `NOT_SIGNED` 执行本节；其他状态禁止重复提交。按 `modules/product-sign.md` 的“签约提交”使用当前产品、MCC 和已验证材料执行；完整参数、固定字段、FLOW 信号和错误处理只在该模块维护。
+仅 `NOT_SIGNED` 执行本节；其他状态禁止重复提交。按 `modules/product-sign.md` 的“签约提交”使用当前产品、MCC 和已验证材料执行；完整参数、固定字段、FLOW 信号和错误处理只在该模块维护。按量付费没有页面材料，产品与 MCC 已确认且本轮签约状态为 `NOT_SIGNED` 后直接提交；网站支付必须在三个图片引用均上传并通过校验后直接提交；APP 支付必须在 APP 名称和三个图片引用全部通过校验后直接提交。任一字段缺失或校验失败时回到 Step 4 的 `materials.category.collect`，禁止执行下列命令，也不增加回复 `1`。
+
+开始执行签约提交前，先执行 `node ../normal/scripts/telemetry.mjs stage onboarding.signing.start --root-intent "$ROOT_INTENT" --product-type "$PRODUCT_TYPE"`。
 
 **固定命令契约**：按当前产品原样使用对应命令结构，只替换尖括号中的实际值，禁止增删、改名或猜测参数：
 
@@ -385,109 +450,142 @@ APP支付未签约时的签约字段：
 bash modules/scripts/ar_sign_apply.sh --product aipay --sales-code "I1080300001000160457" --mcc-code "<mccCode>"
 # 网站支付
 bash modules/scripts/ar_sign_apply.sh --product webpay --sales-code "I1080300001000041203" --mcc-code "<mccCode>" --picurl1 "<imageRef1>" --picurl2 "<imageRef2>" --picurl3 "<imageRef3>"
-# APP支付
+# APP 支付
 bash modules/scripts/ar_sign_apply.sh --product apppay --sales-code "I1080300001000041313" --mcc-code "<mccCode>" --app-name "<APP名称>" --picurl1 "<imageRef1>" --picurl2 "<imageRef2>" --picurl3 "<imageRef3>"
 ```
 
-提交成功后不等待或轮询签约生效：按量付费继续 5.2 和 5.3，网站支付/APP支付继续 5.3。复用 Step 3.1 和 Step 4 的成功结果；只在会话、主体、候选资源变化或原查询失败时刷新受影响分支，刷新失败不清除其他成功结果。
+提交成功后不等待或轮询签约生效，只记录“已提交，等待生效”。服务和应用是否推进只取决于各自前置条件，不取决于本次签约提交是否成功；复用 Step 3.1 和 Step 4 的成功结果，只在会话、主体、候选资源变化或原查询失败时刷新受影响分支，刷新失败不清除其他成功结果。
 
 #### 5.2 服务市场注册（仅按量付费）
 
-复用 Step 3.1 候选，按 `modules/service-registration.md` 执行复用、创建或修改分支。创建/修改前必须用完整五项资料通过该模块定义的 `validate`；只补齐或重新校验变化字段。成功后记录服务 ID、名称、地址和单价，并将实际返回的 `serviceId` 作为 `productionServiceId` 交给后续生产配置。保存成功响应不包含服务状态；只有后续服务列表只读查询成功并按 `serviceId` 匹配到该服务时才记录实际状态，查询失败或尚未返回时保持“状态未取得”，不得推断状态或重复执行 `save`。`full_process` 只记录正式产物和生产配置替换待办，不返回 integration 或重复沙箱联调；`onboarding_only` 未来进入 integration 时仍按上方产物关系使用固定沙箱值，正式上线前再用 `productionServiceId` 替换。
+按 `service-registration.md` 复用、创建或修改；创建/修改必须用完整五项资料通过 `validate`。若用户提供 `0.08元/次` 或 `0.08 元/次`，以脚本带统一前缀的 `SERVICE_PRICING=0.08` 内部事实作为唯一机器值继续后续 renderer 和 save，禁止对客。创建校验通过后先输出非阻塞 `service.create.summary` 并直接执行创建；修改校验通过后必须完成 `SERVICE_UPDATE_ONLY` 确认再执行。成功取得的实际 `serviceId` 记为 `productionServiceId`。保存响应不含服务状态；仅后续列表按 `serviceId` 查到时记录实际状态，否则写“状态未取得”，不得推断或重复 `save`。
+
+开始处理按量付费服务分支前，先执行 `node ../normal/scripts/telemetry.mjs stage onboarding.service.start --root-intent "$ROOT_INTENT" --product-type "$PRODUCT_TYPE"`。
 
 **固定命令契约**：复用已有服务不调用 `save`；创建不传 `--service-id`，修改必须传入用户从 Step 3.1 候选中选定的实际 `serviceId` 和全部字段：
 
 ```bash
 bash modules/scripts/service.sh validate --name "<name>" --desc "<desc>" --url "<url>" --pricing "<pricing>" --schema "<json>"
+# 创建：先成功渲染 service.create.summary/DEFAULT，再直接执行
 bash modules/scripts/service.sh save --name "<name>" --desc "<desc>" --url "<url>" --pricing "<pricing>" --schema "<json>"
+# 修改：先取得 onboarding.write.confirm/SERVICE_UPDATE_ONLY 的有效确认，再执行
 bash modules/scripts/service.sh save --service-id "<serviceId>" --name "<name>" --desc "<desc>" --url "<url>" --pricing "<pricing>" --schema "<json>"
 ```
 
 #### 5.3 应用发布
 
-**应用分支**：按量付费/网站支付使用 `WEBAPP`，APP支付使用 `MOBILEAPP`。复用 Step 3.1 候选和 Step 4 条件资料，按 `modules/app-release.md` 执行复用或新建、设置/校验应用公钥和提审；产品上下文、平台字段、`appSign` 边界、MCP 参数和返回处理只在该模块维护。
+**应用分支**：按量付费/网站支付使用 `WEBAPP`，APP 支付使用 `MOBILEAPP`。复用 Step 3.1 候选和 Step 4 条件资料，按 `modules/app-release.md` 执行复用或新建、设置/校验应用公钥和提审；产品上下文、平台字段、`appSign` 边界、MCP 参数和返回处理只在该模块维护。APP 支付通过 Skill 创建只支持 `IOS`、`ANDROID` 和 `ALL`，其中 `ALL` 只表示 iOS + Android。HarmonyOS 移动应用不得调用 `app.sh create`；执行固定 renderer 命令输出 `application.harmony.manual_create`，用户在开放平台完成创建及平台要求的后续配置后回复 `1`，再重新执行 Step 3.1 的应用列表查询。只有实际查询到 `ON_LINE` 候选后才能按既有复用路径继续，否则应用分支保持人工待办。
 
-**固定命令契约**：以下命令只允许替换实际值，禁止把位置参数改写为 `--app-id`、`--public-key` 等未定义选项。`reuse/key/verify-key/audit` 使用的 `appId` 必须逐字复用 Step 3.1 中用户选定的候选 ID，或本轮 `create` 输出的 `APP_ID`；禁止从其他候选、历史轮次或示例中替换。
+开始处理应用分支前，先执行 `node ../normal/scripts/telemetry.mjs stage onboarding.application.start --root-intent "$ROOT_INTENT" --product-type "$PRODUCT_TYPE"`。
+
+**固定命令契约**：只替换实际值，禁止改写位置参数。所有命令的 `appId` 必须逐字使用本轮候选或 `create` 输出；新建应用使用组合命令，复用缺公钥仍使用 `verify-key` 后 `reuse`。
 
 ```bash
 # 按量付费/网站支付新建 WEBAPP
 bash modules/scripts/app.sh create --product-type "<aipay|webpay>" --sales-code "<当前产品码>"
-# APP支付新建 MOBILEAPP：按实际平台三选一
+# APP 支付新建 MOBILEAPP：Skill 内只允许以下三种平台组合
 bash modules/scripts/app.sh create --product-type apppay --sales-code "I1080300001000041313" --mobile-platform IOS --bundle-id "<bundleId>"
 bash modules/scripts/app.sh create --product-type apppay --sales-code "I1080300001000041313" --mobile-platform ANDROID --app-package "<appPackage>" --app-sign "<appSign>"
 bash modules/scripts/app.sh create --product-type apppay --sales-code "I1080300001000041313" --mobile-platform ALL --bundle-id "<bundleId>" --app-package "<appPackage>" --app-sign "<appSign>"
-# 下列四个子命令的 appId/publicKey 均为位置参数
+
+# HarmonyOS：禁止调用 app.sh create，只渲染固定人工创建指引。
+printf '%s' '{}' | node ../normal/scripts/render_customer_message.mjs application.harmony.manual_create --variant DEFAULT
+# 下列子命令的 appId/publicKey 均为位置参数
 bash modules/scripts/app.sh reuse "<appId>"
-bash modules/scripts/app.sh key "<appId>" "<用户明确提供的完整publicKey>"
+bash modules/scripts/app.sh key --defer-open "<appId>" "<用户明确提供的完整publicKey>"
+bash modules/scripts/app.sh open-key-page "<appId>"
+# 新建应用：页面确认后校验并直接提审
+bash modules/scripts/app.sh verify-key-and-audit "<本轮create输出的appId>" "<同一publicKey>"
+# 复用应用缺公钥恢复：校验后重新执行 reuse
 bash modules/scripts/app.sh verify-key "<appId>" "<同一publicKey>"
+# 仅有限轮询耗尽且用户随后输入 1：原分支只查询一次，不重启自动轮询
+ALIPAY_AIPAY_RECOVERY_QUERY_ONCE=1 bash modules/scripts/app.sh verify-key-and-audit "<本轮create输出的appId>" "<同一publicKey>"
+ALIPAY_AIPAY_RECOVERY_QUERY_ONCE=1 bash modules/scripts/app.sh verify-key "<appId>" "<同一publicKey>"
+# 独立提审恢复入口仍保留完整密钥查询 guard
 bash modules/scripts/app.sh audit "<appId>"
 ```
 
-**复用应用**：执行 `bash modules/scripts/app.sh reuse "<appId>"`，其中 `<appId>` 必须是用户从本轮候选中选定的同一 ID。复用已有 `MOBILEAPP` 时不需要采集 `mobilePlatform`、`bundleId`、`appPackage` 或 `appSign`；这些字段仅在新建 `MOBILEAPP` 时需要。
+**复用应用**：执行 `bash modules/scripts/app.sh reuse "<appId>"`，其中 `<appId>` 必须逐字来自本轮最近一次 `app.sh list` 的实际候选，并由用户按完整 ID 选定；不接受序号、历史候选或 Agent 转换值。复用已有 `MOBILEAPP` 时不需要采集 `mobilePlatform`、`bundleId`、`appPackage` 或 `appSign`；这些字段仅在新建 `MOBILEAPP` 时需要。
 
-仅 `CREATE` 分支在最终创建摘要前重查应用列表；结果未变时不增加用户确认，结果变化时更新候选和决策，重查失败时禁止创建但不回滚其他分支。非 `ON_LINE` 应用不可复用；`FLOW:PENDING_APPLICATIONS` 必须由用户选择暂不新建或新建，禁止当作空列表。
+仅 `CREATE` 分支重查列表，将本次唯一快照记为 `RECHECK_APP_CANDIDATES_JSON` 后执行下列 runner，禁止 Agent 手工比较。stdout 为空且资料齐备时直接创建；非空时原文发出并重新选择；重查失败时禁止创建但不回滚其他分支。非 `ON_LINE` 不可复用，`FLOW:PENDING_APPLICATIONS` 不得当作空列表。
 
-用户完成公钥页面确认后自动校验，不再询问是否校验；应用公钥校验失败或 RSA2 项未返回支付宝公钥时禁止提审。已取得支付宝公钥但未能写入本地文件时，不阻塞已确认的提审，但必须记录 `MANUAL_CONFIGURATION_REQUIRED`；只有实际导出成功时才记录公钥文件路径。最终保留 `appId`、应用状态和公钥导出状态供集成使用。
+```bash
+MESSAGE_INPUT_JSON=$(jq -cn \
+  --argjson previousCandidates "$APP_CANDIDATES_JSON" \
+  --argjson currentCandidates "$RECHECK_APP_CANDIDATES_JSON" \
+  '{previousCandidates:$previousCandidates,currentCandidates:$currentCandidates}')
+printf '%s' "$MESSAGE_INPUT_JSON" \
+  | node ../normal/scripts/onboarding_message_runner.mjs application-recheck --application-type "$APPLICATION_TYPE"
+```
 
-复用应用返回 `FLOW:REUSE_NO_KEY` 时，必须将应用分支标记为未完成，不得输出复用成功。一次向用户说明当前 `appId` 缺少已确认的 RSA2 应用公钥，并让用户选择为当前应用设钥或返回 Step 4 重新决策。用户选择设钥时，按 `modules/app-release.md` 的标准引导、外部写操作确认和公钥红线执行；确认生效后重新执行 `bash modules/scripts/app.sh reuse "<同一appId>"`，不得跳过应用状态与支付宝公钥检查，也不得改变参数形式或替换 ID。
+公钥页 stdout 必须先作为独立对客消息送达，再执行 `app.sh open-key-page "<appId>"` 和对应校验；不得把后续 `application.key.pending` 或最终收口合并到同一条对客回复中。自动打开成功、后续轮询成功或后续 stdout 为空都不能替代实际 `confirmPageUrl` 交付。校验生产固定最多 20 次、间隔 2 秒，成功即停；新建分支复用最终安全密钥响应完成双公钥 guard 后提审，禁止重复查询，guard 失败不提审。耗尽才输出 `application.key.pending`；输入 `1` 后用上方 `ALIPAY_AIPAY_RECOVERY_QUERY_ONCE=1` 命令只查一次。没有准确依据时不得推定公钥确认页过期、有效期或旧链接失效；只有用户主动反馈当前页面或扫码有问题时，才重新执行同一 `app.sh key --defer-open` 生成新的确认页并重新进入固定 open + 轮询。写文件失败记录 `MANUAL_CONFIGURATION_REQUIRED` 但不阻塞提审；HarmonyOS 仍只走人工分支。
 
-### Step 6: 本轮流程收口
+用户提供完整公钥后直接调用 `app.sh key --defer-open`；脚本内部执行 renderer 输出非阻塞 `application.key.page` 并校验 URL，Agent 送达 stdout 后立即调用 `app.sh open-key-page` 受控打开，打开失败只保留同一裸 URL、复制兜底和“扫码完成后请回到 Agent 对话页面”。Agent 不得代写/重渲染，响应不明进入 `UNKNOWN` 且不得生成第二页。
 
-`integration_only` 不应进入本步骤。`onboarding_only` 和 `full_process` 按下方输出模板中的“后续衔接”分支处理；`full_process` 只保留两个子流程的实际状态，不转换成另一套状态。
+复用应用返回 `FLOW:REUSE_NO_KEY` 时，必须将应用分支标记为未完成，不得输出复用成功，并执行下列命令说明当前应用缺少已确认 RSA2 应用公钥。该消息不增加二次确认：目标 `appId` 已由用户从当前候选中选定，随后直接进入当前应用的设钥准备；如果用户在消息后明确要求重新选择或新建应用，再返回 Step 4 重新决策。取得用户明确提供的完整应用公钥后执行 `bash modules/scripts/app.sh key --defer-open "<同一appId>" "<用户明确提供的完整publicKey>"`；该脚本 stdout 独立送达后立即执行 `bash modules/scripts/app.sh open-key-page "<同一appId>"`，再执行 `verify-key` 的有限轮询，确认成功后重新执行 `bash modules/scripts/app.sh reuse "<同一appId>"`，不得跳过应用状态与支付宝公钥检查，也不得改变参数形式或替换 ID。
 
-**输出格式**：
-```markdown
-支付宝商家入驻本轮流程已执行至当前可推进终点。
+```bash
+MESSAGE_INPUT_JSON=$(jq -cn --arg appId "$APP_ID" '{appId:$appId}')
+printf '%s' "$MESSAGE_INPUT_JSON" | node ../normal/scripts/render_customer_message.mjs application.reuse.no_key --variant DEFAULT
+```
+
+### Step 6: 本轮流程收口
 
-只输出本轮实际取得且有判断依据的字段。没有取得的费率、`serviceId`、`appId`、应用状态或公钥导出状态不得使用占位值、空值或推断值填充；改在“待办”中说明缺失原因和恢复动作。
+`integration_only` 不应进入本步骤。`onboarding_only` 和 `full_process` 按实际请求范围处理后续衔接；`full_process` 只保留两个子流程的实际状态，不转换成另一套状态。
 
-| 模块 | 项目 | 信息 |
-|------|------|------|
-| 📦 产品信息 | 产品类型 | {productName} |
-| 📦 产品信息 | 经营类目 | {mccName} |
-| 📋 签约信息 | 签约状态 | {实际取得时输出} |
-| 📋 签约信息 | 费率 | {实际取得费率时才输出} |
-| 🧩 服务信息 | 服务ID | {按量付费且实际取得 serviceId 时输出} |
-| 🧩 服务信息 | 服务状态 | {按量付费且实际取得状态时输出} |
-| 📱 应用信息 | 应用ID | {实际取得 appId 时输出} |
-| 📱 应用信息 | 应用状态 | {实际取得状态时输出} |
-| 🔑 配置信息 | 支付宝公钥导出状态 | {实际取得导出状态时输出} |
+**完成条件**：当前登录、scope 和 MCC 必须有效；签约必须由实际查询确认为已生效；仅按量付费适用的服务分支必须复用或保存成功并取得实际 `serviceId`；应用必须达到 `ON_LINE`、应用公钥已生效且支付宝公钥已实际导出。存在失败、未知、待生效、待审核或人工配置时不得宣称产品开通完成。不维护人工完成条件数量。
 
-{仅在实际展示费率时紧随输出：由于支付宝可能会有阶段性的优惠活动，实际费率可能低于该页面费率，具体以相应费用账单为准。}
+使用 `../normal/json/customer-messages.json` 的 `process.partial_result` 消息逐分支收口，必须通过 `onboarding_message_runner.mjs closeout` 托管输出，并把 runner 完整 stdout 原文发送给用户。禁止用 Agent 手写短摘要替代、删减 `productionReadinessBlock`、删减网站支付收款限制引导或改写后续衔接；网站支付收口缺少“【上线前有以下关键点】”和“网站支付收款限制”时视为标准收口未送达，必须重新发送同一次 closeout stdout。自动重试耗尽、业务错误或查询失败且到本步骤仍未恢复的动作，统一写入对应分支结果和 `remainingActions`，只说明一次，不在收口后再次询问是否重试。必须执行：
 
-**待办**
-- {只列出未取得、待生效、待审核、待手动配置或需要用户继续处理的项目；没有则省略本节。}
+`SIGNING_RESULT`、`SERVICE_RESULT`、`APPLICATION_RESULT` 和 `INTEGRATION_RESULT` 必须使用消息目录允许的状态枚举原文，禁止拼接 `appId`、公钥文件路径、错误码、截图证据或其他自由文本；这些证据只保留在脚本输出、内部事实或人工待办字段中，不能污染分支结果枚举。
 
-**后续衔接**
-- 如果本次只完成签约/入驻：还需要完成代码集成，才能在业务系统中实际发起支付。
-- 如果本次是完整接入/一站式流程：进入 onboarding 前已经通过主编排确认集成存在或完成；本步骤结束后直接输出完整接入最终汇总，不重复进入集成流程。只有用户明确更正此前的集成状态，或 Agent 重新检查项目代码并取得支付能力未完成的直接证据时，才暂停签约写操作并转入 integration，完成后返回 onboarding 的中断点。签约状态、应用列表、服务列表及其查询失败均不得作为回跳依据。
+```bash
+MESSAGE_INPUT_JSON=$(jq -cn \
+  --arg productName "$PRODUCT_NAME" \
+  --arg processResultTitle "$PROCESS_RESULT_TITLE" \
+  --arg integrationResult "$INTEGRATION_RESULT" \
+  --arg sandboxConfigState "$SANDBOX_CONFIG_STATE" \
+  --arg signingResult "$SIGNING_RESULT" \
+  --arg serviceResult "$SERVICE_RESULT" \
+  --arg applicationResult "$APPLICATION_RESULT" \
+  --arg remainingActions "$REMAINING_ACTIONS" \
+  --arg manualVerificationItems "$MANUAL_VERIFICATION_ITEMS" \
+  --arg applicationOperationAppId "${APPLICATION_OPERATION_APP_ID:-}" \
+  --arg applicationOperationActualStatus "${APPLICATION_OPERATION_ACTUAL_STATUS:-}" \
+  --arg applicationOperationNextAction "${APPLICATION_OPERATION_NEXT_ACTION:-}" \
+  --arg nextFlowReminder "$NEXT_FLOW_REMINDER" \
+  '({productName:$productName,processResultTitle:$processResultTitle,integrationResult:$integrationResult,signingResult:$signingResult,serviceResult:$serviceResult,applicationResult:$applicationResult,remainingActions:$remainingActions,nextFlowReminder:$nextFlowReminder}
+    + if $sandboxConfigState == "" then {} else {sandboxConfigState:$sandboxConfigState} end
+    + if $manualVerificationItems == "" then {} else {manualVerificationItems:$manualVerificationItems} end
+    + if $applicationOperationAppId == "" and $applicationOperationActualStatus == "" and $applicationOperationNextAction == "" then {} else {applicationOperationAppId:$applicationOperationAppId,applicationOperationActualStatus:$applicationOperationActualStatus,applicationOperationNextAction:$applicationOperationNextAction} end)')
+printf '%s' "$MESSAGE_INPUT_JSON" \
+  | node ../normal/scripts/onboarding_message_runner.mjs closeout
 ```
 
-使用 TaskUpdate 只把已经实际执行并取得结果的内部任务标记为 completed。签约待生效、应用待审核、人工配置或其他外部待办必须保持 pending 或在用户可见待办中明确列出，不得为了结束本轮对话把这些事项标记为 completed。对于 `full_process`，此处只表示 onboarding 子流程已执行至当前可推进终点；最终是否完成直接依据两个子流程的实际结果和待办，不得另建状态推断。
+`onboarding_only` 的代码开发栏写“不在本轮执行范围”，`SANDBOX_CONFIG_STATE` 传空字符串，`MANUAL_VERIFICATION_ITEMS` 传空字符串，并把 `nextFlowReminder` 固定为“还需完成支付产品-代码开发，才能在业务系统中实际发起支付。”。`full_process` 中，代码开发全部通过时填“已完成”并传 `READY`；只有沙箱待配置且其余代码与安全检查通过时填“部分完成，沙箱配置待完成”，并原样传 `CREATE_PENDING|VERIFY_PENDING`；沙箱为 `READY` 且代码开发只剩非阻塞人工待验证项时填“部分完成，人工待验证”，传 `READY`，把代码开发 checklist 的 `manualItems` 原样作为 `MANUAL_VERIFICATION_ITEMS` 传入，并在 `REMAINING_ACTIONS` 中写明“完成下方人工待验证项”或同等实际待办，禁止传“无”；把 `nextFlowReminder` 固定为“代码开发已在本轮执行；后续只按上表实际待办继续。”，该值仅用于 renderer 校验执行模式，`full_process` 最终对客不展示“后续衔接”行。renderer 会校验结果与沙箱状态、人工待验证项一致，并派生恢复口令或人工待验证展示行；该展示不增加确认点或用户回复要求。不得在其 stdout 前后单独追加衔接提醒，不伪造本轮代码修改、沙箱创建或测试结果，也不重复进入 integration。
 
----
+若 `full_process` 最后一跳紧接着应用创建、审核提交或复用结果，不再单独输出一条 `application.operation.result` 后又立刻输出本收口消息；必须把同样的 `appId`、实际状态和下一步分别记录为 `APPLICATION_OPERATION_APP_ID`、`APPLICATION_OPERATION_ACTUAL_STATUS`、`APPLICATION_OPERATION_NEXT_ACTION`，交给 closeout runner 处理，且 `APPLICATION_OPERATION_ACTUAL_STATUS` 必须与 `APPLICATION_RESULT` 枚举原文一致。应用结果已为“已上线且配置完整”时不再展开“应用分支结果”，由结果表和上线前检查块承接；待审核、待设置公钥、需人工配置、失败或结果未知时合并展示为“应用分支结果”并保留完成态红线。`onboarding_only`、应用分支仍需等待用户补材料/确认，或应用操作结果不是紧邻 Step 6 最终收口时，仍按应用模块原规则输出 `application.operation.result`。合并展示不得改写应用完成条件，待审核、待设置公钥或待人工配置时仍不得表述为应用发布完成。
 
-## 四、错误处理（全局规则）
+当且仅当签约结果为“已提交，等待生效”且应用结果为“已提交审核，等待上线”时，renderer 从消息目录自动在 `remainingActions` 后追加状态查询提示；该提示不是 flow 入参，Agent 禁止自行传入、拼接或在模板外重复输出。其他结果组合不展示该提示。
 
-签约流程的任何 CLI 命令（包括 MCP、login、whoami、logout 和 file upload）执行后都必须立即使用脚本内置错误检测；失败时禁止继续解析业务结果。认证、联网、授权不匹配和业务错误的完整识别与恢复规则以 `modules/scripts/error_handler.sh` 和 `modules/error-handling.md` 为唯一详细来源；依据不足按本文件“核心铁律 10”处理；Step 3.1 的多查询失败隔离仍按该步骤规则执行。
+renderer 还会按 `productName` 和分支完成条件自动派生上线前检查块。Agent 不传入、不改写该字段，也不得在模板外补第二份生产上线清单。该检查使用“【当前状态】/【上线前有以下关键点】/【提示】/【其他】”结构，不单列“相关站点”，也不在模板尾部追加第二个查询入口；必要 URL 只放在具体操作步骤中。完成态只能表述为代码开发和产品开通流程已完成，不得替用户确认生产配置已替换、产品真实可收款或应用页面状态；上线条件固定引导用户前往支付宝 AI 付站点，进入一站式接入 → 选择产品 → 密钥配置查看产品开通和应用上线情况；正式参数以生产 `appId`、应用公钥、应用私钥、支付宝公钥和生产网关为核心；网站支付和 APP 支付必须完成公网 HTTPS `notify_url` 的验签、关键字段校验、幂等、`success` 回写和补偿查询；按量付费必须把沙箱 `api_mock_service_id` 替换为服务市场真实 `serviceId`，A2M 示例中的 `sellerId` 来自商户 PID/2088，由商家自行在支付宝平台确认，不由 Agent 猜测、生成或代填。生产环境应用私钥、账号密码、支付凭证和未脱敏通知内容仍禁止提供给 Agent。分支未完成时，该派生块必须明确上表待办完成前不能正式收款。该提示只在消息目录维护，不增加用户确认点，Agent 不得在模板外重复输出或改写。
 
----
+签约、服务和应用分别按本轮脚本实际结果表达：签约提交成功但未生效时，`signingResult` 固定使用“已提交，等待生效”；服务创建或修改成功且取得 `serviceId`、但未取得服务状态时，`serviceResult` 分别固定使用“创建成功，状态未取得”或“修改成功，状态未取得”；应用按消息目录的实际阶段枚举填写。任一分支失败或结果未知不清除其他分支成功，也不能概括为“全部失败”。
 
-## 五、流程状态
+只输出实际取得且有判断依据的费率、`serviceId`、`appId`、应用状态和公钥导出状态；没有取得的字段进入确定的下一步，不使用占位值、空值或推断值。只有签约为“已生效”、按量付费服务已复用或保存成功并取得实际 `serviceId`（消息值为“已复用”“创建成功，状态未取得”“修改成功，状态未取得”或“已完成”；网站支付和 APP 支付为“无需处理”）、应用为“已上线且配置完整”且剩余待办为“无”时，`processResultTitle` 才能使用“支付产品-产品开通已完成”；否则固定使用“流程进展”。“状态未取得”只表示保存响应未提供服务状态，不得改写为保存失败；renderer 会交叉校验这些条件，禁止在模板外另写相反结论。
 
-只在当前任务中保留恢复流程所需的最小上下文，不建立第三套状态机：
+使用 TaskUpdate 只把已经实际执行并取得结果的内部任务标记为 completed。签约待生效、应用待审核、人工配置或其他外部待办必须保持 pending 或在用户可见待办中明确列出，不得为了结束本轮对话把这些事项标记为 completed。对于 `full_process`，此处只表示 onboarding 子流程已执行至当前可推进终点；最终是否完成直接依据两个子流程的实际结果和待办，不得另建状态推断。
 
-| 类别 | 必要字段 |
-|------|----------|
-| 意图与方案 | `intention`、`productName`、`productType`、`salesCode`、`scope`、`mccCode`、`mccName` |
-| 签约 | 查询成功后记录 `signStatus`；仅状态可确定后记录 `materialStatus`、`missingMaterials`、三个图片引用，APP支付未签约时另保留 `appName` |
-| 服务 | 决策、候选 ID/名称/状态、`serviceId`、五项服务资料、校验状态和实际结果 |
-| 应用 | 决策、候选 ID/名称/状态、`appId`、应用类型、新建 MOBILEAPP 所需平台字段、`publicKeyPrepared`、校验状态、应用状态和支付宝公钥导出状态/可选路径 |
+---
 
-只记录用户明确提供或更正的资料，复用未变化且已校验通过的字段；用户更正字段时只清除受影响的决策或校验结果，只补问缺失或校验失败字段。
+## 四、错误处理（全局规则）
+
+所有 CLI/MCP 操作立即使用脚本内置错误检测，失败后禁止解析业务结果；分类与恢复以 `modules/scripts/error_handler.sh` 和按需读取的 `modules/error-handling.md` 为准。Step 3.1 查询失败仍按分支隔离。
+
+---
 
-`materialStatus` 只描述签约材料，不能代替服务或应用的 `validationStatus`。签约查询成功后，按量付费或已签约/已提交签约时设为 `NOT_REQUIRED`；网站支付/APP支付未签约时按实际结果设为 `MISSING` / `DECLARED_READY` / `VERIFIED`。签约查询未成功时，`signStatus`、`materialStatus` 和 `missingMaterials` 均保持未设置；`onboarding_only` 不在 Step 3.1 前推定材料状态，`full_process` 也只继承实际已确认的值和产物。
+## 五、当前会话事实
 
-`full_process` 继承 `VERIFIED` 材料时，进入 Step 5 前仍必须检查 `collect_information.screenshot` 恰好包含三个非空图片引用，APP支付还必须检查 `collect_information.appName` 非空。通过后跳过重复上传；失败时将 `materialStatus` 改为 `MISSING`、记录对应 `missingMaterials` 并回到 Step 4 补齐，禁止仅凭 `VERIFIED` 提交签约。
+只保留当前已确认产品/MCC、已验证材料、候选和脚本结果；重入时重新校验授权并查询全部适用分支。可验证的提前材料直接复用，否则重收。
 
-禁止保存私钥、公钥原文、签名串、授权 token、完整支付表单或其他业务凭据。`appSign` 只是 Android 应用签名摘要，仅在创建 MOBILEAPP 时使用；不得把应用公钥工具引导套用到 `appSign`。
+写结果不明时用现有只读能力核验；仍无法确认则输出未知，禁止推定失败或重复写入。应用公钥只用于本次 `app.sh key/verify-key/verify-key-and-audit` 且不得复述/记录；其他敏感值遵守 `SKILL.md`。`appSign` 仅指 Android 应用签名摘要。