@alipay/alipay-aipay 1.2.2 → 1.5.0

package/skill/references/onboarding/modules/service-registration.md

@@ -1,337 +1,40 @@
-# 服务市场注册模块
+# 服务市场业务语义
 
-> 本文档定义按量付费产品的服务市场上架流程。**仅按量付费产品需要服务市场注册**。
-> 被引用文档：`onboarding/flow.md` → Step 3.1 服务查询 + Step 5.2 服务注册
-> 本文档位于 `references/onboarding/modules/`，文中的 `scripts/...` 路径相对本目录；从技能包根目录执行时对应 `references/onboarding/modules/scripts/...`。
+服务市场仅适用于 AI 按量付费。本模块解释候选、资料和保存边界；运行时命令以 `../flow.md` 为准，分页、校验、请求和解析由 `scripts/service.sh` 实现。
 
----
+`service.sh` 的全部 CLI 调用固定上报 `PRODUCT=AIPAY`，不把该上下文字段加入服务 MCP 请求 JSON。
 
-## 功能概述
+## 查询与候选
 
-将 MCP 服务上架到支付宝服务市场。**仅对"按量付费"产品需要**，网站支付和APP支付不需要服务注册。
+`a2a-pay-service.discoverBazaarServicesForMcp` 必须按 `offset/total` 完整分页。当前成功协议为 `code="10000"`、`data.items`、`data.pagination`，兼容旧 `success=true/resultObj.serviceList`；失败、异常或分页不完整不得输出空列表分支。
 
-**⚠️ 触发条件：**
-```
-✅ 按量付费（salesCode = I1080300001000160457）→ 需要服务注册
-❌ 网站支付（salesCode = I1080300001000041203）→ 不需要
-❌ APP支付（salesCode = I1080300001000041313）→ 不需要
-```
-
----
-
-## 服务注册完整流程（最高优先级）
-
-**⚠️ 必须严格按照以下流程执行，不可跳过任何步骤！**
-
-```
-┌─────────────────────────────────────────────────────────────────────┐
-│                     按量付费 服务注册流程                              │
-├─────────────────────────────────────────────────────────────────────┤
-│                                                                     │
-│  Step 1: 查询已有服务                                                │
-│    └─ 调用 discoverBazaarServicesForMcp                             │
-│                                                                     │
-│  Step 2: 判断服务列表                                                │
-│    ├─ data.items 为空 → 进入 Step 3 收集服务信息                       │
-│    └─ data.items 不为空 → 展示完整分页结果后进入 Step 3 决策           │
-│                                                                     │
-│  Step 3: 用户决策                                                    │
-│    ├─ 选择序号复用已有服务 → 跳过创建，完成                            │
-│    ├─ 选择"新建" → ⚠️ 检查服务数量，若 ≥ 20 则禁止创建                │
-│    │                 若 < 20，收集 5 项服务信息，进入 Step 4           │
-│    └─ 选择"修改" → 输入服务ID，收集所有服务信息，进入 Step 4          │
-│                                                                     │
-│  Step 4: 提交服务上架/修改                                           │
-│    ├─ 创建新服务：调用 saveBazaarServiceForMcp（不传 serviceId）       │
-│    │               ⚠️ 调用前必须确认服务数量 < 20                     │
-│    └─ 修改已有服务：调用 saveBazaarServiceForMcp（传入 serviceId）     │
-│                                                                     │
-│  Step 5: 处理结果                                                    │
-│    ├─ 成功 → 对客输出服务信息，继续应用发布流程                        │
-│    └─ 失败 → 展示错误，引导用户修正                                   │
-│                                                                     │
-└─────────────────────────────────────────────────────────────────────┘
-```
-
-**⚠️ 修改服务重要说明：**
-```
-修改已有服务时，必须传入 serviceId + 所有服务信息（不可只传部分字段）：
-✅ 正确：传入 serviceId + serviceName + serviceDesc + resourceUrl + pricing + schemaUrl
-❌ 错误：只传入 serviceId + 部分字段（会导致其他字段被清空）
-```
-
----
-
-## Step 1: 查询已有服务
-
----
-
-**执行 `scripts/service.sh list`。**
-
----
-
-## Step 2: 根据查询结果执行不同分支
-
-### 场景 A：服务列表为空（无已有服务）
-
-**此时必须进入 Step 3 收集服务信息并创建新服务。**
-
-> 📎 `scripts/service.sh list` 已内置该判断，返回 `FLOW:CREATE_NEW` 时直接进入 Step 3。
->
-> ⚠️ 注意：服务数量上限为 20 个，`service.sh save` 在创建前会校验。
-
-### 场景 B：服务列表不为空（有已有服务）
-
-**此时必须按接口返回结果展示服务及其实际状态，让用户选择复用、创建或修改。Skill 不额外按状态过滤复用候选。**
-
-**输出格式：**
-
-```markdown
-📋 发现您已有以下服务：
-
-| 序号 | 服务ID | 服务名称 | 描述 | 价格 | 实际状态 | 服务地址 |
-|------|--------|----------|------|------|----------|----------|
-| 1 | SVC001 | 天气查询 | 提供全球天气查询 | 0.01元/次 | 已上线 | https://api.example.com/weather |
-| 2 | SVC002 | AI助手 | 智能对话服务 | 0.05元/次 | 审核中 | https://api.example.com/ai |
-
-请选择：
-  • 输入序号（1/2）复用对应服务
-  • 输入"新建"创建新服务
-  • 输入"修改 + serviceId"修改已有服务
-```
-
-> 📎 表格渲染由 `scripts/service.sh list` 自动完成，无需手动拼接。Agent 直接展示脚本输出即可。
-
-**用户选择处理：**
-
-Agent 根据用户输入执行对应分支：
-
-| 用户输入 | 后续操作 |
-|----------|----------|
-| 数字序号（1-$SERVICE_COUNT） | 复用对应服务 → 跳过创建，直接进入应用发布 |
-| "新建" | 进入 Step 3 收集服务信息 → `bash scripts/service.sh save`（创建前自动校验数量 < 20） |
-| "修改 + serviceId" | 使用表格中展示的 serviceId → 进入 Step 3 收集**所有**字段 → `bash scripts/service.sh save --service-id <id>` |
-
-> ⚠️ 服务数量上限 20 个，由 `service.sh save` 在创建前自动校验。
-
-用户选择修改时可使用列表中展示的 `serviceId`。展示和记录接口返回的实际状态，不自行增加状态过滤、可用性结论或审核规则。
-
----
-
-## Step 3: 收集服务信息（创建或修改服务时执行）
-
-**⚠️ 在以下情况需执行此步骤：**
-```
-✅ 服务列表为空（无已有服务）→ 创建新服务
-✅ 用户选择"新建" → 创建新服务
-✅ 用户选择"修改" → 修改已有服务（提供表格中的 serviceId）
-```
-
-**⚠️ 修改服务特别注意：**
-```
-修改已有服务时，必须收集所有服务信息，不可只收集部分字段：
-✅ 正确：收集 serviceName + serviceDesc + resourceUrl + pricing + schemaUrl 全部字段
-❌ 错误：只收集需要修改的字段（会导致其他字段被清空）
-```
-
-**收集服务信息交互：**
-
-```
-📋 请提供服务注册信息：
-
-1. 服务名称（1-50 字符）：您的服务名称
-2. 服务描述（1-500 字符）：简要描述服务功能
-3. 服务地址（URL）：服务的 API 地址
-4. 服务单价（元，最低 0.01）：用户每次调用的费用
-5. 请求示例（JSON）：API 请求参数示例，提交时作为 `schemaUrl` 字符串传入
-
-请在一条回复中一次性提供以上全部信息。修改服务时请同时提供表格中的 serviceId，不再单独增加一轮询问。
-```
-
-只补问缺失或校验失败的字段。已经通过校验的字段必须保留，不要求用户重新提交；修改服务仍必须最终获得全部五项字段，禁止只提交局部字段。
-
-Agent 在当前任务中记录操作选择、serviceId 和五项服务资料。用户更正字段时只覆盖并重新校验该字段，其他未变化且已校验通过的字段继续复用；操作类型变化时清除不再适用的 serviceId 或创建资料。只补问缺失或校验失败字段，本模块的 `scripts/service.sh validate` 继续作为业务格式校验唯一来源。
-
-### 入参校验规则
+候选只取脚本唯一 `SERVICE_CANDIDATES_JSON`。轮到服务类别时，由 `onboarding_message_runner.mjs service-candidates` 一次输出事实表与选择提示；禁止提前展示、手工拼表或仅输出 ID。列表为空可以创建；存在候选时只接受登记的复用、创建或 `修改:<serviceId>` 选择。
 
-| 字段 | 说明 | 验证规则 | 错误提示 |
-|------|------|----------|----------|
-| `serviceName` | 服务名称 | 长度 1-50 字符 | 服务名称长度需在 1-50 字符之间 |
-| `serviceDesc` | 服务描述 | 长度 1-500 字符 | 服务描述长度需在 1-500 字符之间 |
-| `resourceUrl` | 服务地址 | 有效的 URL 格式（以 http:// 或 https:// 开头） | 请提供有效的 URL 地址 |
-| `pricing` | 服务单价 | 必须 >= 0.01 元 | 服务单价最低为 0.01 元 |
-| `schemaUrl` | 请求示例 | 有效的 JSON 格式；提交时序列化为字符串 | 请提供有效的 JSON 格式请求示例 |
+## 五项资料
 
-> `schemaUrl` 是 MCP 入参字段名，本流程中承载的是序列化后的 JSON 请求示例，不是 URL。用户提供原始 JSON，例如 `{}`；`scripts/service.sh` 校验 JSON 后将其作为字符串写入 `request.schemaUrl`。禁止因为字段名含 `Url` 而要求用户提供网页地址。
+创建和修改都需要：服务名称、服务描述、资源 URL、单次价格、序列化 JSON 请求示例。`schemaUrl` 当前承载 JSON 示例，不是网页 URL。
 
-### 校验脚本
-
-> 📎 已收口到脚本：`scripts/service.sh validate`
+资料由以下入口一次校验；缺失时仍由 flow 的材料 runner 收集：
 
 ```bash
-# 收集服务信息后，调用校验脚本
-bash scripts/service.sh validate   --name "$SERVICE_NAME"   --desc "$SERVICE_DESC"   --url "$RESOURCE_URL"   --pricing "$PRICING"   --schema "$SCHEMA_URL"
+node ../../normal/scripts/onboarding_message_runner.mjs material-collect --category service --state "$MATERIALS_STATE"
+bash scripts/service.sh validate --name "<name>" --desc "<desc>" --url "<url>" --pricing "<pricing>" --schema "<json>"
 ```
 
----
-
-## Step 4: 提交服务上架/修改
-
-### 场景 A：创建新服务（不传 serviceId）
-
-**⚠️ 调用前必须确认服务数量 < 20，否则禁止调用 saveBazaarServiceForMcp 接口！** 执行 `bash scripts/service.sh save --name <name> --desc <desc> --url <url> --pricing <pricing> --schema <json>`。
-
-
-### 场景 B：修改已有服务（必须传入 serviceId + 所有字段）
-
-执行 `bash scripts/service.sh save --service-id <id> --name <name> --desc <desc> --url <url> --pricing <pricing> --schema <json>`。
-
-
----
-
-## Step 5: 处理结果
-
-### 成功输出格式
-
-```markdown
-✅ 服务创建成功
-
-| 项目 | 信息 |
-|------|------|
-| 服务ID | API_xxx |
-| 服务名称 | 天气查询 |
-| 服务描述 | 提供全球天气查询服务 |
-| 服务地址 | https://api.example.com/weather |
-| 服务单价 | 0.01 元/次 |
-```
-
-`saveBazaarServiceForMcp` 的当前成功响应不包含服务状态。不得根据创建或修改成功推断为“审核中”“已上线”或其他状态。只有后续 `scripts/service.sh list` 只读查询成功并按 `serviceId` 匹配到该服务时，才能记录和展示实际状态；查询失败或尚未返回该服务时，将状态保留为“未取得”，不得因此重复执行 `save`。
-
-### 按量付费集成产物
-
-服务创建、修改或复用成功后，必须记录并向用户说明以下已取得字段：
-
-| 字段 | 用途 |
-|------|------|
-| `serviceId` | 按量付费 `Payment-Needed.method.service_id`，也是后续 402 收银联调识别服务的关键字段 |
-| 服务名称 | 用于核对收银台展示和用户识别 |
-| 服务地址 `resourceUrl` | 应与实际提供 402 服务的资源地址一致 |
-| 服务单价 `pricing` | 应与 `Payment-Needed.protocol.amount` 的业务定价保持一致 |
-| 服务状态 | 仅在只读查询实际取得时记录，用于正式上线判断和后续排查 |
-
-如果服务注册成功但未解析到 `serviceId`，不要继续宣称按量付费入驻完成；应提示用户重新查询服务列表或根据服务名称定位服务。
-
-### 失败处理
-
-> 📎 统一错误检测与处理见 `error-handling.md`。`scripts/service.sh save` 已内置错误检测。
-
----
-
-## MCP调用规范
-
-**MCP 服务名：`a2a-pay-service`**
-
-| 方法 | 用途 | 调用时机 |
-|------|------|----------|
-| `a2a-pay-service.discoverBazaarServicesForMcp` | 查询服务列表 / 根据 serviceId 查详情 | **进入服务注册模块时首先调用**（支持两种查询方式，见下表） |
-| `a2a-pay-service.saveBazaarServiceForMcp` | 创建新服务 / 修改已有服务 | 用户选择新建/修改时调用（修改须传 serviceId + 所有资料） |
+用户可输入纯数字、`0.08元`、`0.08 元`、`0.08元/次` 或 `0.08 元/次`。后续 renderer 和 save 只复用脚本内部事实 `SERVICE_PRICING=0.08` 的纯数字值，模板负责展示单位；不得再次追加“元/次”。
 
-**⚠️ discoverBazaarServicesForMcp 支持两种查询方式：**
+## 保存边界
 
-| 查询方式 | 参数 | 说明 |
-|----------|------|------|
-| 查询服务列表 | `{"request":{"limit":20,"offset":0}}` | 返回接口可见的服务列表；脚本按 `pagination.total` 自动翻页并完整展示实际状态，不按状态过滤候选 |
-| 根据 serviceId 查询详情 | `{"request":{"keyword":"API_xxx"}}` | 返回指定服务的详细信息 |
+- 创建：数量上限检查通过且五项资料有效后，展示非阻塞 `service.create.summary` 并直接保存；不传 `serviceId`，不再等待确认。
+- 修改：必须传当前候选完整 `serviceId` 和全部五项资料；保存前使用 `onboarding.write.confirm/SERVICE_UPDATE_ONLY` 绑定当前登录会话、脱敏主体、产品、动作、目标与参数，并等待当前摘要后的明确肯定回复；`1` 只是兼容快捷输入。
+- 任何目标、参数、主体或会话变化都使旧修改确认失效。创建不得进入修改确认。
 
-**查询返回处理：**
+保存写操作调用 `a2a-pay-service.saveBazaarServiceForMcp`。明确 `NOT_SENT` 才能自动重试；`MAYBE_SENT` 时用列表按 `serviceId` 和完整五项资料核验，不能靠同名服务猜测。创建结果未解析到实际 `serviceId` 时禁止宣称完成。
 
-- MCP 信封先通过共享 `unwrap_mcp` 解包 `content[0].text`。
-- 当前成功协议以 `code="10000"` 判断，服务数组读取 `data.items`，分页读取 `data.pagination.limit/offset/total`。
-- 当前服务状态字段读取 `serviceStatus`，兼容旧响应中的 `status`；`ACTIVE` 表示已上线，其他未定义映射的状态值原样展示，不推断业务含义。
-- 脚本兼容旧成功协议中的 `success=true` 与 `resultObj.serviceList`，但不得用旧结构覆盖或猜测当前字段。
-- 只有明确取得成功响应中的空数组，才能判定没有已有服务；业务失败、字段缺失、分页不完整或候选缺少 `serviceId` 均必须阻断，禁止输出 `FLOW:CREATE_NEW` 或 `FLOW:SELECT`。
-
-**⚠️ saveBazaarServiceForMcp 创建/修改服务参数说明：**
-
-| 场景 | 必传参数 | 说明 |
-|------|----------|------|
-| 创建新服务 | serviceName, serviceDesc, resourceUrl, pricing, schemaUrl | 无需传入 serviceId |
-| 修改已有服务 | **serviceId**, serviceName, serviceDesc, resourceUrl, pricing, schemaUrl | **必须传入 serviceId + 所有资料信息** |
-
-**写入返回处理：**
-
-- MCP 信封先通过共享 `unwrap_mcp` 解包 `content[0].text`。
-- 当前成功协议必须同时满足 `code="10000"` 和 `data.success=true`，服务 ID 读取 `data.serviceId`。
-- 脚本兼容旧成功协议中的 `success=true` 和 `resultObj.serviceId`；不得混用两套协议中的成功条件与服务 ID 路径。
-- 创建成功但未解析到 `serviceId` 时必须阻断后续流程；修改成功未返回新 ID 时，继续使用本次请求中已经确认的原 `serviceId`。
-- 业务失败优先展示 `data.subMsg` / `data.msg`，再读取顶层错误字段；响应结构不符合当前或兼容协议时不得宣称成功。
-- 当前保存成功响应不包含服务状态；不得从 `success=true` 推断审核或上线状态。
-
-其中 `schemaUrl` 按本模块约定传入序列化后的 JSON 请求示例。例如空请求示例的实际入参为：
-
-```json
-{
-  "request": {
-    "serviceName": "服务名称",
-    "serviceDesc": "服务描述",
-    "resourceUrl": "https://your-domain.com/callback",
-    "pricing": "0.6",
-    "schemaUrl": "{}"
-  }
-}
-```
-
-### 正确调用示例
-
-> 📎 所有 MCP 调用均有对应脚本：
-
-```bash
-# ✅ 查询服务列表 → scripts/service.sh list
-# ✅ 创建新服务 → scripts/service.sh save --name <name> --desc <desc> --url <url> --pricing <pricing> --schema <json>
-# ✅ 修改已有服务 → scripts/service.sh save --service-id <id> --name <name> --desc <desc> --url <url> --pricing <pricing> --schema <json>
-```
-
-### 禁止调用示例
+成功结果只用登记 renderer：
 
 ```bash
-# ❌ 错误：虚拟未定义的方法
-export PLATFORM=${DEV_TOOL_NAME} && alipay-cli mcp call a2a-pay-service.deleteService -d '...'
-
-# ❌ 错误：自行推断的方法名
-export PLATFORM=${DEV_TOOL_NAME} && alipay-cli mcp call a2a-pay-service.updateService -d '...'
-
-# ❌ 错误：省略 server 名称
-export PLATFORM=${DEV_TOOL_NAME} && alipay-cli mcp call discoverBazaarServicesForMcp -d '...'
-
-# ❌ 错误：未先查询已有服务直接创建
-export PLATFORM=${DEV_TOOL_NAME} && alipay-cli mcp call a2a-pay-service.saveBazaarServiceForMcp -d '...'
+node ../../normal/scripts/render_customer_message.mjs service.operation.result --variant DEFAULT
 ```
 
----
-
-## 服务状态说明
-
-当前列表响应优先读取 `serviceStatus`，旧响应兼容读取 `status`。下表以外的实际状态值必须原样展示；没有已验证依据时不得自行翻译、归类或推断是否可用。
-
-| 状态 | 说明 | 处理方式 |
-|------|------|----------|
-| `DRAFT` | 草稿 | 展示接口返回的实际状态，由用户决定后续操作 |
-| `PENDING` | 审核中 | 展示接口返回的实际状态，由用户决定后续操作 |
-| `ACTIVE` | 已上线 | 展示接口返回的实际状态，由用户决定后续操作 |
-| `REJECTED` | 审核拒绝 | 展示接口返回的实际状态，由用户决定后续操作 |
-
----
-
-## ⛔ 禁止行为（最高优先级）
-
-```
-❌ 禁止：未查询已有服务直接创建新服务
-❌ 禁止：未在 Step 3.1 成功查询已有服务就要求用户决定新建/修改或提供服务资料
-❌ 禁止：服务列表不为空时直接创建新服务（必须让用户选择）
-❌ 禁止：用户选择复用已有服务后仍创建新服务
-❌ 禁止：跳过服务信息校验直接提交
-❌ 禁止：使用虚拟或自行推断的 MCP 方法
-❌ 禁止：修改服务时只传入部分字段（必须传入 serviceId + 所有服务信息）
-❌ 禁止：用户选择"修改"后不收集完整服务信息直接提交
-❌ 禁止：服务数量 ≥ 20 时仍调用 saveBazaarServiceForMcp 创建新服务
-```
+脚本成功返回的服务状态如果未取得，只能写“状态未取得”；不得推定审核通过、可用或生产就绪。真实生产 `serviceId` 只能来自实际创建或复用结果，AI 按量付费沙箱固定 `api_mock_service_id` 不得用于生产。

package/skill/references/runtime-entry.md

@@ -0,0 +1,63 @@
+# 支付宝 AI 付 Skill
+## 支持范围
+
+仅支持 AI 按量付费、AI 网页应用收款、AI 移动应用收款。原有“按量付费”“网站支付”“APP 支付”等叫法继续作为触发别名和业务场景识别词，但所有对客产品名统一使用三个新名称。明确要求当面付、付款码、订单码支付、JSAPI 支付、预授权支付或商家扣款时不得改判；读取 `normal/rejection-guide.md` 输出受控拒绝消息。
+
+AI 网页应用收款覆盖 PC 网页与手机浏览器/H5，固定使用 `alipay.trade.page.pay`；签约固定 `productType=webpay`、`salesCode=I1080300001000041203`、`appType=PC_WEB`，不得把 `PC_WEB` 解释为仅 PC。
+
+## 执行红线
+
+1. **流程与确认**：按当前 flow 顺序执行。阻塞确认等待用户对当前摘要明确回复，禁止以工具超时、默认值或 Task 状态代替；不得增加未登记的操作、材料或确认。
+2. **事实与依据**：禁止编造配置、状态、结果或规则。无当前实现、实际返回或官方依据时明确无法确认；额度解限、可收款时间和产品开通问题引导至[支付宝商家平台](https://b.alipay.com/page/portal/home)，代码、应用创建和发布问题引导至[支付宝开放平台](https://open.alipay.com/)或[支付宝技术支持](https://opensupport.alipay.com/support/intelligent-services?form=payskill)。静态扫描或提交成功不代表最终完成。
+3. **CLI/MCP 契约**：优先执行动作处脚本；确需直调时，完整方法和 JSON 只能来自已读文档或 `alipay-cli mcp list <server> --json` 实时 schema。遇到 `Server not found`、`Method not found`、`Invalid params` 立即停下核对，禁止尝试近似名称。
+4. **联网权限**：`alipay-cli` 登录/MCP、文件上传、沙箱创建和下载按联网命令处理；环境支持显式授权时首次执行即申请，详见 `normal/alipay-cli-env.md`。
+5. **用户文件**：只修改已确认项目和范围；不得清空或删除既有项目。“新建/重做/换一个”不是删除授权；具体删除仍遵守 Integration flow 的清单、二次确认和禁删边界。
+6. **敏感信息**：应用公钥只能由用户生成并明确提供；禁止请求或处理生产私钥，禁止生成密钥对、补全/改写公钥或添加 PEM 头尾。敏感值、临时 URL 和沙箱资料严格遵守对应 flow/script 的白名单、权限与输出边界。
+7. **沙箱结论**：真实快速沙箱配置不得用占位值；唯一固定例外是 AI 按量付费沙箱 `service_id=api_mock_service_id`，生产禁用。`CREATE_PENDING|VERIFY_PENDING` 可继续代码实现，但阻止字段使用、摘要、后置校验、联调和付款体验。字段校验不等于支付测试；只有 AI 按量付费完整 402 链路满足 flow 条件才可称沙箱测试通过。
+8. **异步通知**：AI 网页应用收款/AI 移动应用收款必须实现通知处理。本地无公网 HTTPS `notify_url` 时可不传该字段并用交易查询验收，将公网通知联调列为人工待验证；生产上线前必须恢复公网通知并完成验签、幂等、关键字段校验、`success` 回写和补偿查询，未完成不得宣称生产就绪。
+9. **受控页面**：授权链接只由 `auth.sh` 在固定产品/MCC 上下文中生成，只允许 `https://aipay.alipay.com/cli-auth` 及登记参数；禁止使用 CLI `verification_url`。公钥确认页、自动打开和兜底同样只走登记脚本。
+10. **对客输出**：指定 renderer/脚本时，stdout 是唯一对客正文，必须原文回复且不加旁白；工具输出记录、折叠面板或日志不等于已对客发送。登记脚本的内部事实行统一以 `ALIPAY_AIPAY_INTERNAL:` 开头；唯一例外是 `self_update.mjs` 使用 `self-update.md` 登记的 `SELF_UPDATE:*` stderr 终态 marker。两类内部行即使被宿主合并展示也必须整行剔除，严禁对客。所有 `postRenderHintType=scanReturn` 的页面消息都是交付屏障，当前包括 `auth.page` 和 `application.key.page`：页面 stdout 必须先作为独立对客消息送达，再继续受控 opener 和有限轮询；不得把后续 `auth.pending`、`application.key.pending` 或收口消息合并进同一条对客回复。该屏障不要求用户确认，也不新增用户操作。阻塞正文后等待；成功且剔除内部行后正文为空时直接转移，不补写话术。
+11. **确定性转移**：固定脚本终态后立即转移；只执行动作处登记命令，禁止追加 `jq/cat/grep/curl` 或临时脚本重复解析同一结果。失败只走登记恢复分支；项目自检不得绕过 Skill 脚本或打印敏感配置。
+
+## 标准消息
+
+`normal/json/customer-messages.json` 是稳定对客正文唯一目录。Integration 启动使用 `integration_message_runner.mjs start-confirm`，收口使用 `integration_message_runner.mjs checklist-result`；Onboarding 的 MCC、发现、材料、候选和收口使用登记 runner，授权、公钥页、密钥工具和错误使用动作处脚本。`process.partial_result` 必须发送 closeout runner 完整 stdout；缺少 AI 网页应用收款上线关键点或收款限制引导即未正确送达。只有无托管入口时才直调 renderer：
+
+```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>
+```
+
+动态值只由动作处 `jq -cn --arg/--argjson` 构造，无变量传 `{}`；禁止字符串替换或 `eval`。renderer 返回 `MESSAGE_RENDER_ERROR` 时必须先复查同一 `messageId` + `variant` schema，禁止猜枚举；非 0 时停止，不手写兜底。
+
+所有已经展示登记摘要并等待确认的阻塞点，都把用户原始回复交给 `normal/scripts/interaction_reply.mjs confirm --reply "$USER_REPLY"`。只有唯一 `ALIPAY_AIPAY_INTERNAL:REPLY_DECISION=CONFIRMED` 才推进；`1`、`继续`、`继续推进`、`好了`、`已完成`、`确认`、`确定`、`同意`、`OK` 等登记的明确肯定表达语义等价。否定、疑问、取消、修改意见和无法唯一判断的回复不确认；确认仍只绑定当前消息的产品、项目、主体、候选和摘要，任一绑定事实变化后旧确认失效。该内部校验不新增用户操作点。
+
+`normal/...` 的 workdir 固定为当前 Skill 的 `references/`，不得使用 Skill 根；其他相对命令使用所在 Markdown 目录，项目命令使用 runner 确认的绝对项目根，三者不得混用。
+
+## 入口路由
+
+根 `SKILL.md` 启动器已经在读取本文件前确定本轮有效版本。运行时禁止再次执行自更新、读取 `normal/self-update.md` 或切换其他 Skill 副本；只识别原始用户请求的根意图并加载当前意图入口：
+
+| 意图 | 判定 | 入口 | 后续按需加载 |
+|---|---|---|---|
+| `integration_only` | 只要求代码开发、支付集成或集成排障，未同时要求产品开通 | 执行 `node normal/scripts/flow_loader.mjs integration entry` | 当前阶段、产品和语言的契约、示例与脚本 |
+| `onboarding_only` | 只要求签约、入驻或产品开通，未同时要求代码开发 | 执行 `node normal/scripts/flow_loader.mjs onboarding entry` | 当前阶段的授权、查询或写分支模块 |
+| `full_process` | 明确要求完整接入、一站式，或同一请求同时要求代码开发和产品开通 | `normal/full-process-routing.md` | 先 Integration，满足衔接条件后 Onboarding |
+
+进入 `onboarding_only`，或 `full_process` 从 Integration 衔接 Onboarding 时，必须先执行 Onboarding flow 登记的 `onboarding_message_runner.mjs platform-entry`。Windows 只发送 runner 登记的支付宝 AI 付站点引导并停止 Skill 内产品开通；非 Windows stdout 为空并继续既有流程。该门禁必须早于产品/MCC 澄清、方案确认和环境检查，不得手写或重复提示。
+
+识别根意图后立即执行 `node normal/scripts/telemetry.mjs start-run --root-intent <integration_only|onboarding_only|full_process>`；产品已唯一确定时追加 `--product-type <aipay|webpay|apppay>`。命令记录 `run.intent_detected` 并创建/复用 `run_id`：同一意图和产品继续复用，`UNKNOWN` 补全产品仍复用同一 `run_id`；明确换产品、换根意图或既有 run 已终态才重建，宿主项目 ID 可固定为 `run_id`。业务 stage 只由登记 runner/script 异步记录。
+
+遥测默认开启，`ALIPAY_AIPAY_TELEMETRY=0|false|off|no` 可关闭；落盘、网络、上传或 flush 失败静默且不改变业务、对客消息或确认，stdout 为空，stderr 内部行禁止对客。`integration_only` 由 checklist 最终消息结束 run，其他意图由 Onboarding closeout 结束。现有脚本继续把 `run_id` 作为 `PLATFORM_ID`；Agent 不手写环境前缀或改写 MCP payload。维护诊断、outbox、上传和 flush 细节只在 `normal/telemetry.md` 按需读取。
+
+三种入口均只在无法从已有产品名称或业务描述可靠确定唯一产品时执行 flow 登记的 `product.clarify` renderer；不得推定或手写澄清。产品明确但 MCC 尚无检索输入时使用 `mcc-clarify`；已有经营描述后统一使用 `mcc-resolve`，不得拆回 `mcc-search + mcc-candidates`。
+
+代码开发或完整接入缺少项目位置/技术栈时，执行 `integration.context.required` 或 `integration.project_path.required` 标准消息。新项目和复用项目先分流；`PROJECT_INPUT` 保留用户原始表达，明确“新建/创建”项目、网站、商城、应用或同类新产物时必须使用 `resolve-project --intent new`，不得因当前目录已有项目改写为现有项目。未知现有项目用 runner 轻量定位候选，所有路径再由 `resolve-project` 解析。未补齐前不得初始化、安装依赖或修改文件。
+
+每轮代码开发只渲染一次 `integration.start.confirm`，两种意图复用同一次检查器事实并覆盖 Integration 步骤 1 至步骤8：代码开发校验；`full_process` 确认前已完成步骤 1，确认后进入步骤 3。Onboarding 只保留方案确认和服务修改确认；签约材料完整后直接提交，服务创建摘要后直接创建，新建应用公钥校验成功后直接提审。
+
+扫码页非阻塞：授权最多查 12 次、间隔 5 秒，公钥最多查 20 次、间隔 2 秒，成功即推进；耗尽后按上方统一回复判定只查询一次，不重启轮询。
+
+`full_process` 确认前只准备项目、语言、系统分支环境和沙箱；Windows 未明确要求当前配置时记录 `VERIFY_PENDING`，不收集资料。确认后进入 Integration 步骤 3，满足衔接条件即自动进入 Onboarding；仅沙箱待配置，或沙箱 READY 且只剩非阻塞人工待验证项时可部分通过，其他缺口停在 Integration。最终收口保留全部待办。
+
+仅代码开发结束时提醒仍需产品开通；仅产品开通结束时提醒仍需代码开发。机器规则、消息目录、fixture 和测试不作为默认必读内容。