mcpField
I
integrate

integrate

github.com/sahyll开发059 次安装21 周前更新
代码仓库

关于 integrate

用于引导 Juspay 支付集成的 Agent 技能，覆盖产品选择、平台检查、查阅文档、实现和测试。它结合 MCP 商户数据与进度跟踪，并强调凭据安全。

主要功能

  1. 01通过 MCP 查询商户信息
  2. 02基于产品目录选择产品
  3. 03检查平台与代码库
  4. 04依照文档指导实现
  5. 05阶段与任务进度跟踪
  6. 06凭据处理安全措施

适用场景

  1. 01启动 Juspay 产品集成
  2. 02从指定步骤继续集成
  3. 03跟踪实现与验证进度

MCP 相关

使用 `juspay-mcp` 获取实时商户数据，并通过 `juspay-docs-mcp` 查询文档结构与内容。调用 `juspay-mcp` 工具前必须完成身份验证。

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/sahyll/juspay-skills --skill integrate

安装后在 Claude Code 中输入/integrate确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

products/
ec-api.md
ec-headless.md
hyper-checkout.md
hyper-credit.md
jusbiz.md
juspay-billing.md
lotuspay.md
payout.md
upi-plugin-sdk.md
upi-tpap-sdk.md
scripts/lifecycle/
done
integrate-results
scripts/test/hyper-checkout/
order-status.sh
session.sh

详细介绍

/integrate — Juspay 集成编排器

首要指令： 本文件是一个决策引擎，不包含任何产品知识。 产品知识位于 products/ 中。权威的实现信息只能来自 MCP 工具调用，绝不能依赖记忆或训练数据。

MCP 优先级： 对于实时商户数据（凭证、设置、网关配置、集成状态），始终优先使用 juspay-mcp 工具。juspay-docs-mcp 仅用于了解文档结构和页面内容。

Agent 自检（每个阶段开始前在脑中检查）

  • 我是否完成了预检 MCP 身份验证步骤？如果没有，现在就调用 mcp__juspay-mcp__authenticate()；如果失败，则停止操作并请用户先完成身份验证。
  • 我是否已调用 juspay_get_merchant_details，在索取凭证前确认商户信息？
  • 我是否在调用 explore_product 前阅读了 products/？能否仅根据目录得出结论？
  • 我是否在询问消除歧义的问题（语言、框架）前扫描了代码库？
  • 我是否在编写任何代码前调用了 doc_fetch_tool？
  • 我使用的方法名和字段名是否来自获取的文档，而非记忆？
  • 对于 SDK/网页产品：我是否获取了测试资源，并在可能的情况下对每个检查清单阶段运行了测试？

标志解析

开始前提取标志：

标志效果
--product <id>跳过推荐。用一行确认产品，然后进入第 2 阶段。仍需执行第 1.7 步的目录优先检查。
--platform <id>为第 2 阶段的平台选择提供提示——提问前仍需对照代码库进行验证。
--from <step>从指定步骤恢复（参见入口点）。初始化完整任务列表；将此前的步骤标记为已完成。

结果跟踪

每个阶段都由两次 scripts/lifecycle/integrate-results 调用前后标记：开始工作前调用 step-start <name>，验证后调用 step-end <status> "<verification>"。这样才能准确记录每个阶段的耗时——如果将两次调用合并为阶段结束时的一次调用，耗时就会变成 0 秒。

脚本路径（从项目根目录使用完整路径调用）： .claude/skills/integrate/scripts/lifecycle/integrate-results

命令：

  • init — 初始化工作流生命周期框架。输出 init: startedAt=<ts>。在工作流开始时调用一次（任务初始化之前）。
  • step-start <name> — 在每个阶段开始时、任何工作开始之前调用。输出 pending: <name>。
  • step-end <status> "<verification>" ["<reason>"] — 阶段验证通过后调用。输出 recorded: <name> <status> (steps=<count>, pending=<none|name>)。
  • step <name> <status> "<verification>" <startedAt> <completedAt> ["<reason>"] — 用于在 shell 中捕获了开始时间的阶段的单次调用形式。
  • set <field> <value> — 存储非敏感元数据。输出 set: <field>=<value>。脚本会从结构上拒绝匹配 *key*、*secret*、*password*、*token* 的字段（不区分大小写）——请勿尝试绕过此限制。

可安全用于 set 的字段： product、platform、productType、merchantId、active、status。

以输出内容为准。 每次修改都会输出一行确认信息。将其视为写入成功的证明；不要重新读取 JSON 进行验证。

如果 integrate-results 或 scripts/lifecycle/done 以代码 2 退出，并输出以 SKILL_FALLBACK: 开头的行，说明 jq 和 Python 均不可用。跳过所有剩余的 integrate-results 调用，不要重试；跳过 DONE 阶段的耗时摘要，并告知用户一次：“结果跟踪不可用（未找到 jq 或 Python）。安装其中任意一个即可启用分阶段耗时记录。集成过程仍会正常进行。”

STATIC_STEPS（在 init 时初始化，始终存在）： product-select、platform-detect、doc-fetch、params、codegen、test、summary、done

DYNAMIC_STEPS（在工作流中途发现后初始化）：

  • Phase 2 结束后（确认平台）：{$PLATFORM}-setup（如果是移动平台）、checklist（始终添加）
  • Step 4.1 结束后（检查 webhook）：webhook-config（如果 webhook URL 尚未配置，且用户提供了一个）
  • Phase 5 DB 扫描后（确认 DB 变更）：db-schema

动态步骤名称因平台而异：react-native-setup、android-setup、ios-setup、flutter-setup、cordova-setup、capacitor-setup。done 脚本支持任意步骤名称——无需修改脚本。

执行规范：

  • 每个阶段都必须以 step-start 开始、以 step-end 结束。之前没有调用 step-start 时，绝不能调用 step-end。对于自动跳过的阶段，允许连续调用 step-start / step-end skipped。
  • 不要自行计算时间戳——integrate-results 会在内部处理 UTC 时间。
  • 验证字符串不得包含凭据（参见下方 SECURITY）。

进度跟踪

驱动 Agent 原生的清单或任务跟踪界面，让用户在整个工作流中实时查看集成进度。

工作流开始时（在 integrate-results init 之后、步骤 1.1 之前），在同一轮助手回复中并行创建 8 个 STATIC_STEPS——每个任务调用一次 TaskCreate，并将所有调用作为并行的 tool_use 块发出：

product-select, platform-detect, doc-fetch, params, codegen, test, summary, done

按顺序创建任务属于回退——应在一轮中发出所有 TaskCreate 调用。

**阶段 2 结束后（确认平台）：**在单个并行批次中创建动态任务：

  • {$PLATFORM}-setup — 如果 $PLATFORM ∈ {android, ios, react-native, flutter, cordova, capacitor}
  • checklist — 始终创建

按需创建（后续阶段）：

  • 步骤 4.1 检查 webhook 后：如果 URL 尚未配置，且用户提供了 URL，则创建 webhook-config 任务
  • 确认阶段 5 的数据库扫描后：如果用户同意进行架构更改，则创建 db-schema 任务

每个阶段边界处的状态机：

  • 调用 step-start 时，将状态切换为 in_progress。
  • 调用 step-end passed 时，将状态切换为 completed。
  • 同一时间只能有一个阶段处于 in_progress 状态。

自动跳过规则（这些阶段会连续调用 step-start / step-end skipped，其任务直接变为 completed）：

  • {$PLATFORM}-setup：如果文档结构表明已确认的平台不需要原生 SDK 设置，则跳过。根据文档结构推断——如果产品没有 $PLATFORM 对应的原生/移动 SDK 页面，则跳过，并说明原因："not applicable: no native/mobile SDK pages found for $PLATFORM in the doc map"。在步骤中使用实际解析出的平台名称（例如，step-start web-setup / step-end skipped）。

**--from <step> 入口点：**创建 8 个 STATIC_STEPS，然后在创建后立即将入口点之前的所有步骤标记为 completed。入口点之前本应创建的动态步骤也应创建，并立即标记为 completed。

**失败：**如果某阶段耗尽重试次数且工作流停止，则将失败阶段保留为 in_progress，在失败摘要之后将 done 标记为 completed，并调用 integrate-results set status failed。

安全

绝不要在步骤验证字符串、任务描述、Bash 命令参数或任何终端输出中包含以下内容：

  • $API_KEY — 在步骤 4.2 中通过 juspay_create_api_key 创建。绝不回显，也绝不存储在结果文件中。
  • $WEBHOOK_AUTH_PASSWORD — 在步骤 4.4 中从 .env 读取。同样禁止。
  • juspay_create_api_key 返回的任何值。
  • 从 .env、.env.local 或类似文件中读取的任何凭据。

正确：

integrate-results step-end passed "API key provisioned and stored in env var; webhook URL configured; return URL set"

错误：

integrate-results step-end passed "API key: sk-test-AbCdEf123; webhook=https://..."

**integrate-results 脚本会在 set 时从结构上拒绝敏感字段名称（退出码为 1）。**绝不要试图通过重命名字段绕过此限制。

**运行测试脚本时（步骤 8.2）：**通过 shell 环境变量传递凭据（export JUSPAY_API_KEY=...），不要将其作为 Bash 工具调用命令字符串中可见的内联参数传递。

如果脚本或 MCP 工具响应中包含凭据值（例如，juspay_create_api_key 返回明文密钥），请将其存储在内存变量中。告知用户已创建该凭据，但不要回显其值：

“已创建新的 API 密钥，并存储于本次会话中。”

UI 交互规则

每当用户需要在固定选项中进行选择时：

  • 使用原生选择 / 选项 UI
  • 如果选项已知，不要要求用户自由输入回复
  • 等待用户选择后再继续
  • 显示选项后，不要再次改述同一个问题
  • 不要询问可以推导出的信息——从代码库、juspay-mcp 实时数据或目录中推导

将选项格式化为结构化选项，而不是行内文本。

预检：MCP 身份验证

此技能依赖两个 MCP 服务：

  • juspay-mcp — 实时商户数据（凭据、设置、集成状态）。调用任何工具前都需要身份验证。
  • juspay-docs-mcp — 文档结构和页面内容。无需身份验证。
身份验证流程

调用任何 juspay-mcp 工具前，请使用 Agent 环境提供的任何机制尝试触发身份验证流程（例如 authenticate 工具、OAuth 握手或 MCP 服务提供的登录提示）。

如果身份验证成功 → 直接继续执行阶段 1。

如果身份验证失败、工具不可用，或你不确定如何在当前环境中进行身份验证 → 首先查阅你的 Agent 关于如何对远程 MCP 服务进行身份验证的文档（例如 Claude Code 文档、OpenCode 文档、Cursor 文档，具体取决于你使用的 Agent）。然后停止并告知用户：

"继续此集成前，需要对 juspay-mcp 服务进行身份验证。

请查阅你的 Agent 关于 MCP 服务身份验证的文档，然后重新运行集成技能以继续。"

身份验证成功前，不要尝试调用任何 juspay-mcp 工具。确认身份验证完成后，才能继续执行阶段 1。

阶段 1 — 意图收集和产品选择

启动

开始任何阶段工作前，按以下顺序运行：

  1. integrate-results init — 初始化生命周期骨架
  2. 在同一轮助手响应中并行发出全部 8 个 TaskCreate 调用（参见进度跟踪）
  3. integrate-results set active working

如果传入了 --from <step>，在创建任务后，立即将入口步骤之前的所有步骤标记为 completed（对每个前置步骤依次执行 step-start / step-end passed "resumed from --from flag"，然后将对应任务切换为 completed）。

运行：integrate-results step-start product-select | 将 product-select 任务切换为 in_progress

步骤 1.1 — 加载产品目录

读取 products/ 中的所有文件。每个文件包含：产品 ID、类型、平台、用例和意图信号。

将完整集合存储为 $PRODUCT_CATALOG。这是用于匹配的本地知识——不要使用训练数据中的产品知识。

步骤 1.2 — 根据商户账户自动确定集成类型

调用：

juspay-mcp:juspay_get_merchant_details()

提取并存储：

  • $MERCHANT_ID — 来自 merchantId 字段
  • $CLIENT_ID — 始终默认为 $MERCHANT_ID。**切勿从 API 响应中提取此值。**告知用户：

    "Client ID 通常与商户 ID（$MERCHANT_ID）相同。如果你使用不同的 Client ID，请现在提供；否则我将使用 $MERCHANT_ID 继续。" 等待用户确认或提供自定义值后再继续。

  • $INTEGRATION_TYPE — 来自 integrationType 字段，该字段是一个数组；取第一个元素（例如，["PP"] → "PP"）

将 $INTEGRATION_TYPE 映射到推荐产品：

$INTEGRATION_TYPE推荐产品 ID
PPhyper-checkout
ec_sdkec-headless
ec_apiec-api
（其他值或缺失）不进行推断 — 回退到步骤 1.4
步骤 1.3 — 展示推断的推荐

如果找到了映射，则展示一条确认信息：

"根据你的账户配置，你似乎已设置为使用 [Product Name]。

要继续集成 [Product Name] 吗？

  1. 是，继续
  2. 否，让我选择其他产品类型
  3. 否，让我选择特定产品"
  • 选项 1 → 将 $PRODUCT 设为推断出的产品 ID，并跳转到阶段 2
  • 选项 2 → 转到步骤 1.4（产品类型列表）
  • 选项 3 → 展示 $PRODUCT_CATALOG 中完整的扁平产品列表，让用户直接选择
步骤 1.4 — 询问用户想构建什么

仅当 $INTEGRATION_TYPE 缺失、无法识别，或用户在步骤 1.3 中选择了选项 2 时才会进入此步骤。

从 $PRODUCT_CATALOG 推导类别列表：读取每个条目的 category 字段并收集唯一类别。按类别首次在目录中出现的顺序，将每个唯一类别列为带编号的选项，并在末尾添加 不确定：

你想集成哪种类型的产品？

[来自 $PRODUCT_CATALOG 的唯一类别编号列表] [N+1]. 不确定

步骤 1.5 — 询问用户选择产品

将 $PRODUCT_CATALOG 筛选为 category 与用户所选类别匹配的条目。将每个匹配产品的名称列为带编号的选项：

你想集成哪种 [category] 产品？

[来自 $PRODUCT_CATALOG 中 category = selected category 的产品编号列表]

如果用户选择了 不确定，则改为询问：

请描述你的使用场景，我会推荐合适的产品和集成流程。

将自由文本回复存储为 $INTENT，然后继续步骤 1.6。

步骤 1.6 — 将意图与候选项匹配

使用 $INTENT 和每个 $PRODUCT_CATALOG 条目中的 intent signals 字段，选择 1–3 个产品作为 $CANDIDATES[]。

匹配规则：

  • "结账 UI"、"支付页面"、"移动 SDK" → 优先选择 type: sdk 产品
  • "仅 API"、"服务端"、"REST"、"后端" → 优先选择 type: api-only 产品
  • "定期付款"、"订阅"、"授权委托" → 账单/授权委托产品
  • "付款"、"转账"、"发放款项" → 付款产品
  • "UPI"、"TPAP"、"P2P"、"P2M" → UPI 产品

目标为 1–3 个候选项。越少越好。

步骤 1.7 — 优先依据目录解析产品

调用 explore_product 之前，先检查目录条目是否足以得出结论：

如果符合以下条件，则目录条目为足以得出结论：

  • type 字段明确说明是否需要询问平台
  • platforms 列表只有一个条目，或产品类型为 api-only（无需询问平台）
  • 开始生成代码无需进一步区分平台

如果足以得出结论 → 跳过此候选项的 explore_product，继续下一步。 如果不足以得出结论（例如混合类型、存在多个重叠平台，或需要页面数量作为复杂度信号）→ 调用：

juspay-docs-mcp:explore_product({ product: <candidate-id> })

仅提取推荐所需的信息：

  • 产品标题
  • 平台 ID → 对类型进行分类（运行时 ID = sdk，仅有 docs = api-only，两者混合 = hybrid）
  • 编号形式的基础集成页面数量（复杂度信号）
  • 支持的平台列表（如果是 sdk/hybrid）

此处不要获取单独的文档页面。

步骤 1.8 — 给出推荐并确认

根据你从 products/ 和 explore_product 中读取的信息，给出推荐：

"根据你的描述，我推荐以下产品：

[Product Title] — [与用户意图相关的一句话理由]

(备选) [Product Title] — [理由]

你想集成哪一个？或者从下面的完整列表中选择："

将 $PRODUCT_CATALOG 中的所有产品列为带编号的参考列表，供用户改选。

将确认后的选择存储为 $PRODUCT（来自 products/ 文件的产品 ID）。

产品确认后：

integrate-results set product $PRODUCT
integrate-results set merchantId $MERCHANT_ID
integrate-results step-end passed "product confirmed: $PRODUCT; merchantId resolved"

将 product-select 任务切换为 completed。

阶段 2 — 平台检测

运行：integrate-results step-start platform-detect | 将 platform-detect 任务切换为 in_progress

步骤 2.1 — 构建 $DOC_MAP（explore_product）

仅当 Step 1.7 中尚未针对 $PRODUCT 调用 explore_product 时，才调用 explore_product。

如果已调用且 $DOC_MAP 已填充 → 直接跳到 Step 2.3。

否则调用：

juspay-docs-mcp:explore_product({ product: $PRODUCT })

阅读完整响应。这是权威的文档结构。提取并保存：

  • 产品标题和描述
  • platforms[] — 每个平台条目的 ID 和标题
  • 对于每个平台：sections[] → 对于每个 section：sectionTitle、pages[]
  • 对于每个页面：pageTitle 和 md content link URL

编号为“1. …”“2. …”的页面是基础集成页面，必须按指定顺序排列。请严格保留该顺序。

根据产品类型分类：阅读 explore_product 返回的文档结构。根据平台列表、section 标题和页面布局，判断产品需要客户端 SDK、纯 API/服务端，还是两者兼有。将结果保存为 $PRODUCT_TYPE（sdk | api-only | hybrid），并保存：

integrate-results set productType $PRODUCT_TYPE
步骤 2.2 — 从代码库检测后端语言

扫描工作目录，查找后端语言特征，并将结果保存为 $DETECTED_LANG。使用第一个明确匹配项：

找到的特征$DETECTED_LANG
requirements.txt、pyproject.toml，或多数 *.py 文件python
tsconfig.json 和 *.ts 后端文件typescript
package.json 的依赖中包含 express/fastify/koa/hapi/nest，或多数 *.js 文件javascript
go.mod 或多数 *.go 文件go
pom.xml、非 Android 环境中的 build.gradle，或多数 *.java 文件java
Gemfile 或多数 *.rb 文件ruby
composer.json 或多数 *.php 文件php
*.csproj 或多数 *.cs 文件csharp
Cargo.toml 或多数 *.rs 文件rust

如果多个特征相互冲突，请统计 server/、backend/、api/ 或项目根目录下各语言的源文件数量，选择数量最多的语言。如果没有找到任何特征，则将 $DETECTED_LANG 留空（在 Step 4.3 中询问用户）。

第 2.2.5 步 — 单侧代码库检查（仅适用于 SDK 和混合型产品）

如果 $PRODUCT_TYPE = api-only，请完全跳过此步骤。 纯 API 产品没有客户端，因此不适用此问题。

扫描工作目录，检查是否存在后端和前端：

后端信号：专用的 server/、backend/ 或 api/ 目录；包含服务端依赖项（express、fastify、koa、hapi、nest）的 package.json；包含 app/api/ 或 pages/api/ 目录的 Next.js 项目；requirements.txt、pyproject.toml、go.mod、pom.xml、build.gradle（非 Android 环境）、Gemfile、composer.json、Cargo.toml、*.csproj。

前端信号：包含客户端依赖项（react、vue、angular、svelte、next、nuxt）的 package.json；项目根目录中的 index.html；包含 *.jsx / *.tsx / *.vue 文件的 src/ 目录；pubspec.yaml（Flutter）；AndroidManifest.xml 或 *.xcodeproj（原生移动应用）。

根据扫描结果设置 $HAS_BACKEND 和 $HAS_FRONTEND。

如果两侧都存在 → 设置 $SINGLE_SIDE_MODE = false 并继续。

如果只找到一侧 → 设置 $SINGLE_SIDE_MODE = true，并将 $MISSING_SIDE 设为缺失的一侧（"backend" 或 "frontend"）。然后在继续之前询问用户：

"⚠️ 我只能在此项目中找到 [$HAS_BACKEND → "backend" / $HAS_FRONTEND → "frontend"]。完整的 [Product] 集成通常需要两侧：

  • 后端 — 创建会话、检查订单状态、处理 webhook
  • 前端 — 初始化 SDK 和支付界面

你希望如何继续？

  1. 仅继续处理 [$FOUND_SIDE] — 我会生成此侧所需的内容；集成摘要将包含分步清单，列出上线前必须在 [$MISSING_SIDE] 实现的内容
  2. 停止 — 我会先添加 [$MISSING_SIDE]，然后重新运行 /integrate"
  • 选项 1 → 设置 $SINGLE_SIDE_MODE = true 并继续
  • 选项 2 → 立即停止并显示消息："没问题。将 [$MISSING_SIDE] 添加到项目中，准备好后重新运行 /integrate。"

如果两侧都未找到（项目结构为空或不熟悉）→ 按两侧都存在处理并继续；后续阶段的代码库扫描会发现任何问题。

根据 $PRODUCT_TYPE 分支：

如果是 api-only

不询问平台。后端语言取自 $DETECTED_LANG — 仅在未检测到时才询问。

integrate-results set platform "api-only"
integrate-results set nativeSdkRequired false
integrate-results step-end passed "api-only product; backend language: $DETECTED_LANG"

将 platform-detect 任务切换为 completed。

播种第 2 波动态任务（并行，单轮完成）：

  • checklist — 始终执行
如果是 sdk

从代码库中检测客户端平台，并在继续之前与用户确认。

步骤 2.3 — 根据代码库检测平台

询问用户之前，扫描工作目录，查找平台信号：

找到的文件／模式检测到的平台
pubspec.yamlflutter
package.json 中的依赖包含 react-nativereact-native
package.json 中的依赖包含 @capacitor/corecapacitor
config.xml 或 package.json 中的依赖包含 cordovacordova
build.gradle 或 AndroidManifest.xml（没有 Flutter/RN/Cordova/Capacitor 信号）android
*.xcodeproj 或 Podfile（没有 Flutter/RN 信号）ios
package.json 中没有移动框架信号，或存在 index.html / .html 文件web 或 iframe-web

如果有较高把握检测到平台，请将其作为预选推荐项呈现：

“我检测到您的项目是 [Platform] 应用（发现了 [signal file]）。

要继续使用 [Platform] 吗？

  1. 是，使用 [Platform]
  2. 否，让我选择其他平台”

如果用户确认，则跳转到消歧步骤。如果用户选择选项 2，或未发现任何信号，则呈现 $DOC_MAP 中的完整平台列表。

步骤 2.4 — 消歧

确认平台后执行：

  • Android：询问使用 Java 还是 Kotlin
  • iOS：询问使用 Swift 还是 Objective-C，以及 CocoaPods 还是 SPM
  • Web：如果文档映射中同时包含 web 和 iframe-web，则询问使用哪个变体

将结果存储为 $PLATFORM。筛选 $DOC_MAP，仅保留所选平台的页面。

integrate-results set platform $PLATFORM
integrate-results set nativeSdkRequired true
integrate-results step-end passed "platform confirmed: $PLATFORM; doc map filtered to platform pages"

将 platform-detect 任务设为 completed。

Seed Wave 2 动态任务（并行，单轮完成）：

  • {$PLATFORM}-setup（例如 react-native-setup）——使用解析出的平台名称创建 TaskCreate
  • checklist ——始终创建
如果是 hybrid

首先询问：

“此产品同时包含后端 API 和客户端 SDK。您需要什么？

  1. 仅后端 API
  2. 仅客户端 SDK
  3. 两者”

然后，如果用户选择选项 1，则遵循 api-only 路径；如果选择选项 2，则遵循 sdk 路径；如果选择选项 3，则依次遵循两条路径。

integrate-results set platform $PLATFORM
integrate-results set nativeSdkRequired <true|false>
integrate-results step-end passed "hybrid product; mode=$MODE; platform=$PLATFORM"

将 platform-detect 任务设为 completed。

Seed Wave 2 动态任务（并行，单轮完成）：

  • {$PLATFORM}-setup ——仅当 $PLATFORM 为移动平台时创建（android/ios/react-native/flutter/cordova/capacitor）
  • checklist ——始终创建

PHASE 3 — 文档获取

运行：integrate-results step-start doc-fetch | 将 doc-fetch 任务切换为 in_progress

始终使用 doc_fetch_tool。只有当 MCP 针对有效 URL 返回明确错误时，才使用 WebFetch 作为备用方案。

juspay-docs-mcp:doc_fetch_tool({ url: "<md content link from $DOC_MAP>" })

获取顺序：

  1. 前置要求 / 概览 — 始终先获取；其中定义凭证、身份验证格式和版本限制
  2. 编号的基础集成页面 — 严格按照 explore_product 中的编号顺序
  3. Webhooks、订单状态 API
  4. 错误代码（资源部分）
  5. 高级部分 — 仅在用户提出要求时获取

阅读每个页面时，提取并保存：

  • $CONSTRAINTS — 按字段组织的结构化表格（取代旧的 $PARAMS 列表）。对于找到的每个请求字段、方法参数或构造函数参数：

    • name — 文档中的确切字段名称
    • type — 声明的类型：String | Integer | Decimal | Boolean | Array | Object
    • required — true | false
    • maxLength — 整数，来自以下模式："max N chars"、"maximum N characters"、"up to N"、"(max: N)"
    • minLength — 整数，来自以下模式："min N chars"、"at least N characters"
    • minValue — 数字，来自以下模式："minimum N"、"at least N"、"min: N"、"minimum amount"
    • maxValue — 数字，来自以下模式："maximum N"、"up to N"、"max: N"
    • format — 字符串，来自以下模式：ISO 4217、E.164、UUID、YYYY-MM-DD、字母数字
    • enumValues — 字符串数组；当文档列出固定的允许值集合时（"one of: X, Y, Z" 或有效值表格）
    • warnings — 字符串数组，与此字段条目相邻的提示块：符合 > **Note:**、> **Important:**、> **Warning:**、> ⚠️、> 💡、**Important** 的行
    • errors — 字符串数组，来自 $ERROR_CODES 中明确引用此字段名称的错误代码

  • $CODE_EXAMPLES — 文档中的确切方法名称、类名称和关键标识符

  • $ERROR_CODES — 所有状态值、错误代码和失败原因（完整表格：代码 + 含义 + 建议的操作）

  • $VERSION_CONSTRAINTS — 最低 SDK 版本、最低语言 / 平台版本

  • $WARNINGS — 未关联到特定字段的全局警告 / 提示块

integrate-results step-end passed "fetched $(count) doc pages; $(count) fields in $CONSTRAINTS; $(count) error codes; $(count) warnings"

将 doc-fetch 任务切换为 completed。

PHASE 4 — 参数收集

运行：integrate-results step-start params | 将 params 任务切换为 in_progress

告诉用户：

"我已阅读文档。接下来将收集所需信息。"

Step 4.1 — 通过 MCP 自动解析商户上下文

$MERCHANT_ID、$CLIENT_ID 和 $INTEGRATION_TYPE 已在 Step 1.2 中获取 — 重用这些值。不要再次调用 juspay_get_merchant_details()。

始终调用：

juspay-mcp:juspay_get_general_settings()

从常规设置中提取：

  • $RETURN_URL — 已配置的现有返回 URL（检查是否非空）

Webhook 检查 — 仅当文档有要求时： 检查获取的文档（Phase 3，doc-fetch）是否包含 Webhook 部分，或是否要求商户配置 Webhook URL。如果有，则调用：

juspay-mcp:juspay_get_webhook_settings()

从 Webhook 设置中提取：

  • $WEBHOOK_URL — 已配置的现有 Webhook URL（检查是否非空）
  • $WEBHOOK_EVENTS — 当前已订阅的事件

如果文档未提及 Webhook，则完全跳过 Webhook 检查和配置。

如果文档要求使用 Webhook，且 $WEBHOOK_URL 为空或未配置：

首先，扫描代码库，查找现有的 Webhook 处理程序（例如 api/juspay/webhook、api/webhook、webhooks 路由）。如果找到，记下其路径，作为 $WEBHOOK_PATH。

现在创建 webhook-config 动态任务：

TaskCreate({ name: "webhook-config", description: "Configure webhook URL for payment events" })
integrate-results step-start webhook-config

获取仪表板文档，以获得准确的导航信息和直接链接。调用：

juspay-docs-mcp:explore_product({ product: "dashboard" })

如果 explore_product 成功，则找到标题中包含 "Webhook" 或 "Settings" 的页面并获取：

juspay-docs-mcp:doc_fetch_tool({ url: "<webhook/settings page URL from explore_product result>" })

如果 explore_product 失败或未返回结果，则使用以下备用方案：

juspay-docs-mcp:list_products({ category: "DASHBOARD" })

从结果中选取仪表板产品 slug，对其调用 explore_product，然后对相关页面调用 doc_fetch_tool。将获取的页面保存为 $DASHBOARD_DOCS — 返回 URL 步骤会再次使用它。 从获取的页面中提取：

  • $WEBHOOK_DOCS_URL — 获取的文档页面 URL（供参考）
  • $WEBHOOK_DASHBOARD_NAV — 页面中提及的任何控制面板导航路径（例如“设置 → Webhooks”）
  • $WEBHOOK_DASHBOARD_LINK — 页面中找到的任何控制面板直达深层链接。如果未找到直达链接，则留空并依赖导航说明。
  • $WEBHOOK_EVENTS_REQUIRED — 此产品建议使用的标准 Webhook 事件名称

询问用户其部署的基础 URL（用于计算完整的 Webhook URL）：

“您的账户尚未配置 Webhook URL。请提供您部署的基础 URL，这样我就能准确告诉您在控制面板中需要设置什么。

如果您还没有部署 URL，可以使用 ngrok http <port> 或 cloudflared tunnel 获取临时的公开 URL。”

用户提供基础 URL 后，计算 $CONFIGURED_WEBHOOK_URL = <用户提供的基础 URL> + / + $WEBHOOK_PATH，并提供配置说明：

“在 Juspay 控制面板中配置您的 Webhook：”

要设置的 URL： $CONFIGURED_WEBHOOK_URL

导航： $WEBHOOK_DASHBOARD_NAV （来自文档） 直达链接： $WEBHOOK_DASHBOARD_LINK （如果有）

要启用的事件：

  • （逐项列出 $WEBHOOK_EVENTS_REQUIRED 中的事件）

📖 配置指南：$WEBHOOK_DOCS_URL

设置保存后请告诉我，我会继续。”

等待用户确认已配置 Webhook。将确认的 URL 保存为 $WEBHOOK_URL。

integrate-results step-end passed "webhook URL configured manually via dashboard: $WEBHOOK_URL; navigation instructions provided"

将 webhook-config 任务状态改为 completed。

如果 $RETURN_URL 为空或尚未配置：

首先，扫描代码库，查找可以接收 Juspay 重定向并处理订单状态响应的现有 Return URL 页面或处理程序。如果找到，则将其路径记为 $RETURN_PATH。

获取控制面板设置文档。 如果 $DASHBOARD_DOCS 已在上述 Webhook 步骤中设置，则重复使用。否则，调用：

juspay-docs-mcp:explore_product({ product: "dashboard" })

查找常规设置页面，并使用 doc_fetch_tool 获取该页面。如果 explore_product 失败，则回退到 list_products({ category: "DASHBOARD" })。

从获取的页面中提取：

  • $SETTINGS_DOCS_URL — 获取的文档页面 URL
  • $SETTINGS_DASHBOARD_NAV — 常规设置的导航路径（例如“设置 → 常规”）
  • $SETTINGS_DASHBOARD_LINK — 如果有，提取控制面板直达深层链接

询问用户 Return URL：

“您的账户尚未配置 Return URL。请提供付款完成后应将客户重定向到的 URL。该 URL 必须是应用中真实存在的路由，用于处理付款返回／订单状态响应。”

用户提供 URL 后，验证它是否与代码库中的现有路由或处理程序匹配。如果不匹配，则警告：

“您提供的 URL 在当前代码库中似乎不存在对应的 Return 处理程序。您确定要使用此 URL 吗？”

用户确认后，提供配置说明：

“在 Juspay 控制面板中配置您的 Return URL：

要设置的 URL： <用户提供的 URL>

导航： $SETTINGS_DASHBOARD_NAV （来自文档） 直达链接： $SETTINGS_DASHBOARD_LINK （如果有）

📖 配置指南：$SETTINGS_DOCS_URL

设置保存后请告诉我。”

等待用户确认。将确认的 URL 保存为 $RETURN_URL。

环境始终为生产环境。 不要询问用户。使用文档中的生产环境主机 URL。

步骤 4.2 — 自动配置 API 密钥

不要向用户索要 API 密钥。改为调用：

juspay-mcp:juspay_create_api_key({ description: "integrate-skill-<product>-<date>" })

将返回的明文值保存为 $API_KEY，仅保留在内存中——绝不记录日志、绝不保存到结果文件中、绝不回显。告知用户：

“已为您的账户创建一个新的 API 密钥，用于此集成。”

绝不向用户显示密钥值。绝不将其传递给 integrate-results。

第 4.3 步 — 收集其余必填参数

按顺序询问：

  1. 必填参数 — 用户必须提供的每个必填字段（跳过自动生成的字段和已解决的内容：$MERCHANT_ID、$CLIENT_ID、$API_KEY、$WEBHOOK_URL）
  2. 平台版本检查（仅 SDK 路径）— 如果文档指定了最低版本
  3. 后端语言 — 如果尚未从代码库中检测到
第 4.4 步 — 确定后端基础 URL 和 Webhook 身份验证凭据

$BACKEND_BASE_URL — 扫描代码库，查找后端的监听端口和基础 URL：

信号推导出的值
后端 .env 或 .env.local 中的 PORT=XXXXhttp://localhost:XXXX
前端 .env 中的 EXPO_PUBLIC_API_URL / VITE_API_URL / NEXT_PUBLIC_API_URL直接使用该值
package.json 开发脚本中的 --port XXXXhttp://localhost:XXXX
docker-compose.yml 中的 ports: - "XXXX:XXXX"http://localhost:XXXX

如果有足够把握检测到，请用一行确认，例如：

"检测到后端地址为 http://localhost:3001（来自 backend/.env: PORT=3001）。"

如果无法确定，请询问：

"你的后端运行在哪个 URL？（例如：http://localhost:3001）"

存储为 $BACKEND_BASE_URL。

$WEBHOOK_AUTH_USERNAME / $WEBHOOK_AUTH_PASSWORD — 如果 Webhook 处理程序使用 Basic Auth（检查生成的代码或后端 .env），请从 .env 中读取这些值，不要询问。仅在内存中存储。切勿记录这些值，也不要将其包含在步骤验证字符串中。

沙箱说明： 第 8.2 步中的测试脚本会调用你的本地后端，而后端会使用你配置的凭据调用 Juspay 的 API。要使用 Juspay 的 Dummy PG（模拟器）进行测试，无需额外设置 — 第 8.3.1 步获取的测试资源页面会列出自动路由到模拟器的测试卡和 UPI VPA。

integrate-results step-end passed "webhook configured: $WEBHOOK_URL; return URL set; API key provisioned; backend URL: $BACKEND_BASE_URL"

将 params 任务状态切换为 completed。

阶段 5 — 代码生成

运行：integrate-results step-start codegen | 将 codegen 任务状态切换为 in_progress

规则：

  • 以获取的文档中的代码示例和方法名称为基础。替换为已收集的值。不要使用文档中未出现的方法或类名称。
  • $INTEGRATION_STAGES（第 5.1 步）中的每个可见且未禁用的阶段都必须有对应的代码覆盖。优先覆盖关键阶段。
  • $CONSTRAINTS（阶段 3）中的每个受限字段都必须经过验证层，然后才能传递给 API。任何参数都不得超出其文档规定的范围。
  • 生成前端/SDK 代码之前，重新阅读 products/$PRODUCT.md，查看任何特定于平台或集成类型的代码说明。为匹配的平台或集成类型生成代码时，必须严格遵循每个此类说明章节。
步骤 5.1 — 获取集成阶段

调用 juspay_integration_monitoring_status，了解 Juspay 要求此集成覆盖哪些支付流程。结果将成为 $INTEGRATION_STAGES——这是第二个约束来源，与第 3 阶段的 $CONSTRAINTS 一同驱动代码生成。

juspay-mcp:juspay_integration_monitoring_status({
  platform: <$PLATFORM mapped below>,
  product_integrated: <$PRODUCT mapped below>,
  merchant_id: $MERCHANT_ID,
  start_time: <30 days ago in YYYY-MM-DDTHH:MM:SSZ>,
  end_time: <now in YYYY-MM-DDTHH:MM:SSZ>
})

product_integrated 的产品映射：

$PRODUCTproduct_integrated
hyper-checkoutPayment Page Session
ec-headlessEC + SDK
ec-apiEC Only
(others)Payment Page Session

platform 的平台映射：

$PLATFORMplatform
web, iframe-webWeb
androidAndroid
iosIOS
flutter, react-native, cordova, capacitorAndroid
api-only productsBackend

遍历路径——响应是嵌套的；请按以下方式遍历：

queryData.responseData.features
  → each {featureKey}          (e.g., "base")
    → .sections
      → each {sectionKey}      (e.g., "Payments Flow Checklist", "SDK Flow Checklist", "Latency")
        → .stages
          → each {stageKey}    (e.g., "new_card_txn", "upi_collect_txn")

对于遍历到的每个阶段，如果满足以下条件，则将其纳入 $INTEGRATION_STAGES[]：

  • visibilityResult === true
  • disableStage === false
  • onlyReportResult === false（仅用于报告的阶段不需要代码覆盖——跳过）

$INTEGRATION_STAGES[] 中的每个条目包含：

字段来源说明
section{sectionKey}字典键，例如 "Payments Flow Checklist"——这就是显示名称
stageKey{stageKey}字典键，例如 "new_card_txn"
stageDisplayNamestage.stageDisplayName易读名称，例如 "New Card"
stageDescriptionstage.stageDescription测试内容
criticalResultstage.criticalResult布尔值——关键阶段会决定是否可以上线
statusstage.status"PASSED" | "FAILED" | "NOT_ATTEMPTED"——作为第 8.5 步差异比较的基线

同时将 queryData.scoreData 保存为 $SCORE_BASELINE：

  • baseCriticalSuccessCount / baseCriticalTotalCount——例如 4 / 8
  • baseTotalSuccessCount / baseTotalCount——例如 4 / 12

这些阶段构成集成契约。 $INTEGRATION_STAGES 中的每个阶段都必须在以下步骤中有对应的代码覆盖。criticalResult: true 的阶段必须先于非关键阶段完成覆盖。

步骤 5.2 — 根据 $CONSTRAINTS 生成验证层

在编写任何集成代码之前，生成一个基于 $CONSTRAINTS 的验证辅助函数/函数：

  • 对于每个具有 maxLength 的字段：添加长度检查，值超出限制时抛出错误或返回错误。添加 // docs: max N chars 行内注释。
  • 对于每个具有 minValue 的字段：添加数值下限检查，并附上 // docs: min N 注释。
  • 对于每个 type = Integer 或 Decimal 的字段：确保正确进行类型转换；文档声明为数值时，绝不能传入字符串。
  • 对于每个具有 enumValues 的字段：定义一个常量集合（枚举、冻结对象或字面量联合类型），并引用该集合，而不是使用原始字符串。
  • 对于 warnings 非空的每个字段：在该字段赋值前添加 // ⚠️ WARNING: <warning text> 注释。

此验证层只编写一次，并在整个集成代码中引用。

步骤 5.3 — 安装 SDK 依赖项（仅适用于 SDK / 混合产品）

在编写导入 SDK 的代码之前，请先安装文档要求的程序包。 使用“Prerequisites / Getting Started”页面中列出的确切程序包名称和版本 — 不要安装其中未提及的任何内容。

平台命令
react-native、cordova、capacitor在项目根目录中运行 npm install <packages>
flutterflutter pub add <packages>
原生 Android添加到 build.gradle 的 dependencies 块中
原生 iOS添加到 Podfile，然后运行 pod install

按顺序生成：

  1. 身份验证 / 凭据设置 — 使用环境变量，切勿硬编码值

  2. 核心集成 — API 调用或 SDK 安装 → 初始化 → 打开 → 响应处理程序

  3. Webhook 处理程序 — 如果文档中有 webhooks 章节；包含签名验证

  4. 状态验证工具 — 如果文档中有状态 / 订单 API

  5. 数据库架构 — 严格遵循此流程；未完成所有步骤之前，不要编写或建议更改架构：

    步骤 5.4 — 扫描现有架构

    在代码库中搜索与支付或订单相关的数据库定义：

    • 迁移文件（migrations/、db/migrate/、*.sql、*.prisma、schema.rb、typeorm/*.entity.*、mongoose 模型文件等）
    • 包含 order_id、payment_status、transaction_id、amount 或类似字段的 ORM 模型文件

    将所有匹配项收集为 $EXISTING_SCHEMAS。

    步骤 5.5 — 根据查找结果分支处理

    如果 $EXISTING_SCHEMAS 非空：

    概述找到的内容：

    “我找到了现有的支付 / 订单相关架构：

    • <file>：<table/model name> — 字段：<list relevant fields>
    • (每项均重复)

    您希望我：

    1. 扩展这些架构 — 向现有架构添加 Juspay 专用字段（juspay_order_id、payment_status 等）
    2. 创建单独的表 — 在现有表旁边添加一个新的 juspay_orders 表
    3. 跳过数据库更改 — 我只在应用层处理订单关联”

    等待用户选择。只应用用户确认的更改。

    如果 $EXISTING_SCHEMAS 为空：

    创建任何内容之前，请先征求许可：

    “未找到现有的支付或订单架构。文档要求存储：<fields derived from $PARAMS and the product's status/webhook docs>。

    要我为此创建数据库架构吗？如果要，请选择格式：

    1. 原始 SQL 迁移
    2. Prisma 架构
    3. TypeORM 实体
    4. Mongoose 模型
    5. 跳过 — 我会手动处理”

    等待用户选择。如果用户选择 1–4，则使用获取的文档中的字段名称和约束生成架构。如果用户选择 5，则完全跳过。

    步骤 5.6 — 生成已商定的架构

    现在启动 db-schema 动态任务（用户已确认需要更改数据库）：

    TaskCreate({ name: "db-schema", description: "Create/migrate payment schema" })
integrate-results step-start db-schema

    使用 $CONSTRAINTS（而非 $PARAMS）中的字段名称、长度和约束，以及产品的订单 / webhook 文档中的信息。将 $CONSTRAINTS 中的 maxLength 值应用为列大小约束（例如，对于 maxLength: 20 的字段，使用 VARCHAR(20)）。不要添加文档中未出现或用户未要求的字段。

    integrate-results step-end passed "db schema generated: <table/model name>; N columns; constraints from $CONSTRAINTS applied"

    将 db-schema 任务切换为 completed。

  6. 错误处理 — 使用文档中的错误代码展示如何处理不同情况

integrate-results step-end passed "code generated: auth setup, core integration, webhook handler, status utility, DB schema; packages installed"

将 codegen 任务切换为 completed。

阶段 6 — 原生 SDK 设置（仅限移动平台）

触发条件：$PRODUCT_TYPE 为 sdk 或 hybrid，且 $PLATFORM 为以下任一项：android、ios、react-native、flutter、cordova、capacitor。

步骤名称是 Wave 2 中预设的平台专属动态名称：{$PLATFORM}-setup（例如：react-native-setup、android-setup）。

如果未触发，则根据 Phase 2 中是否预设了 {$PLATFORM}-setup 进行处理：

情况 A — 任务未预设（$PRODUCT_TYPE = api-only，或 $PRODUCT_TYPE = hybrid 且平台为非移动平台，例如 web 或 iframe-web）： 无需调用生命周期 — 该步骤从未注册。直接跳至阶段 7。

情况 B — 任务已预设，但不适用原生设置（$PRODUCT_TYPE = sdk，且平台为非移动平台，例如 web 或 iframe-web，文档说明无需设置原生 SDK）：

integrate-results step-start {$PLATFORM}-setup
integrate-results step-end skipped "not applicable: $PLATFORM is not a native mobile platform; no native SDK setup required"

将 {$PLATFORM}-setup 任务标记为 completed。跳至阶段 7。

运行：integrate-results step-start {$PLATFORM}-setup | 将 {$PLATFORM}-setup 任务标记为 in_progress

规则：本阶段的每项操作都必须以阶段 3 获取的文档为依据。不得臆造步骤。

步骤 6.1 — 从文档中提取原生设置要求

重新扫描阶段 3 已获取的页面（Prerequisites / Overview / Getting Started，以及任何名为 “Android Setup” 或 “iOS Setup” 的章节），并提取：

  • $NATIVE_PACKAGES — 要安装的软件包／依赖项（npm/pub/gradle/cocoapods）
  • $BUILD_TOOL_CHANGES — 构建配置文件所需的修改（build.gradle、pubspec.yaml 等）
  • $PLATFORM_CONFIG_FILES — 必须创建的配置文件（例如包含 SDK 凭据的 *.txt 或 *.json）
  • $POST_INSTALL_SCRIPTS — 安装软件包后必须运行的脚本（例如 Podfile 钩子、资源 fuse 脚本）
  • $PREBUILD_REQUIRED — 在原生目录可访问之前是否需要预构建／生成／同步步骤

如果文档章节明确标注为 “Android Setup” 或 “iOS Setup”，则该章节的全部内容都应视为适用于相应平台的权威说明 — 不得跳过其中列出的任何步骤。

步骤 6.2 — 检查项目结构

运行任何操作之前，先根据代码库判断项目工作流：

信号工作流
app.json 中含有 "expo" 键，且不存在 android/ 或 ios/ 目录Expo 托管模式 — 必须生成原生目录
存在 android/ 和 ios/Bare／原生模式 — 无需预构建
pubspec.yamlFlutter — 使用 Flutter 工具链
config.xmlCordova — 使用 cordova platform add
capacitor.config.*Capacitor — 使用 npx cap sync

对于尚无原生目录的托管工作流：仅当 $PREBUILD_REQUIRED 为 true 或框架强制要求时，才运行框架的生成／同步命令（例如，Expo 托管模式使用 npx expo prebuild，Capacitor 使用 npx cap sync，Flutter 使用 flutter pub get）。对于已有原生目录的代码库，绝不要运行具有破坏性的生成命令。

步骤 6.3 — 执行构建工具变更

对于 $BUILD_TOOL_CHANGES 中的每一项：

  • 先读取目标文件。
  • 使用 Edit 工具应用变更（不要使用 shell sed/awk），以便审核差异。
  • 检查是否幂等 — 如果相应值已存在，则跳过。
步骤 6.4 — 创建平台配置文件

对于 $PLATFORM_CONFIG_FILES 中的每一项：

  • 使用 Write 工具写入文件。
  • 替换为阶段 4 中已解析的 $CLIENT_ID、$MERCHANT_ID 或其他凭据。
第 6.5 步 — 运行安装后脚本并同步依赖

对于 $POST_INSTALL_SCRIPTS 中的每一项：

  • 通过 Bash 运行。
  • 捕获标准输出和标准错误；如果退出码非零，读取错误信息、诊断问题、修复并重新运行。
  • 只有此步骤以退出码 0 结束后，才能继续下一步。
第 6.6 步 — 汇总表

记录此步骤前，先报告结果：

## Native SDK Setup Complete

| Step | Action | Result |
|------|--------|--------|
| packages installed | <names from docs> | ✅ / ❌ |
| prebuild / generate | <command, or "skipped — dirs existed"> | ✅ / skipped / ❌ |
| build config patched | <files changed> | ✅ / ❌ |
| config files created | <files created> | ✅ / ❌ |
| post-install scripts | <commands run> | ✅ / ❌ |

任何 ❌ 行都必须包含捕获到的错误输出和尝试过的修复。

integrate-results step-end passed "{$PLATFORM}-setup complete: packages installed, build configs patched, config files created, post-install scripts run"

将 {$PLATFORM}-setup 任务切换为 completed。

第 7 阶段 — 检查清单和错误参考

checklist 已在第 2 波（第 2 阶段 platform-detect 之后）被设为动态任务。现在将其切换为 in_progress。

运行：integrate-results step-start checklist | 将 checklist 任务切换为 in_progress

检查清单

根据实际获取的内容生成检查清单——每一项都必须反映此产品文档中的真实内容。

## Integration Checklist — [Product] on [Platform or API]

### Credentials
- [ ] [credential from docs] stored as env var
- [ ] API key generated via dashboard or juspay-mcp

### [Backend / API]
[items derived from API doc pages]

### [Frontend / SDK] (if applicable)
[items derived from SDK doc pages]

### Testing
- [ ] Successful sandbox transaction
- [ ] Error case from $ERROR_CODES tested
- [ ] Webhooks verified end-to-end

### Integration Stages (from Juspay)

`$INTEGRATION_STAGES` was already fetched in Step 5.1 — render it directly, no second MCP call needed here.

For each stage in `$INTEGRATION_STAGES`, emit:

```
### [stage.section]   ← the section dict key is the display name, e.g. "Payments Flow Checklist"

- [ ] **[stage.stageDisplayName]** ⚠️ Critical ← only if stage.criticalResult is true
      [stage.stageDescription]
```

- Do **not** show `status` — it reflects past activity, not a live gate; developers check stages off as they test
- Mark stages where `criticalResult: true` as ⚠️ Critical
- Group stages by `stage.section` (the section dict key)

### Go-Live
- [ ] Switched to production environment and keys
- [ ] Production end-to-end test passed
参数约束

仅当 $CONSTRAINTS 中的字段至少有一个约束列非空时，才输出此表。省略完全不受约束的字段，以便快速浏览。

## Parameter Constraints

| Field | Type | Required | Max Length | Min Value | Format | Warnings |
|-------|------|----------|------------|-----------|--------|---------|
[one row per constrained field from $CONSTRAINTS — populate only non-null columns; use — for nulls]
错误参考
## Error Codes

| Code / Status | Meaning | Recommended action |
|---------------|---------|-------------------|
[from $ERROR_CODES]
后续步骤

简要说明可以进一步了解 $DOC_MAP 中未纳入基础集成的部分，但只能提及你确实在文档映射中看到的内容。

integrate-results step-end passed "checklist generated from docs; $(count) integration stages from monitoring API; error reference table built"

将 checklist 任务切换为 completed。

第 8 阶段 — 实时测试

运行：integrate-results step-start test | 将 test 任务切换为 in_progress

务必尝试运行服务并亲自测试集成。如果你能执行测试，就不要让用户手动测试。

第 8.1 步 — 启动开发服务

扫描代码库以查找启动命令：

信号命令
package.json 中包含 "dev" 脚本npm run dev（或 yarn dev）
pubspec.yaml无法运行——跳到第 8.3 步
仅限移动端的项目（无 Web 服务）无法运行——跳到第 8.3 步

启动服务前，调用：

integrate-results set active waiting

在后台运行服务，等待其就绪，然后：

integrate-results set active working

重要： 在 Vite/Node 中，Shell 环境变量会覆盖 .env 文件。启动服务前，检查 Shell 中是否已设置任何必需的环境变量（例如 JUSPAY_API_KEY），且这些变量会与项目的 .env 冲突。如果这些变量不属于此项目，请将其取消设置。

步骤 8.2 — 运行后端 API 测试

如果产品文件（products/$PRODUCT.md）定义了 ## Test Scripts 部分，则在步骤 8.2.2 和 8.2.3 中使用其中的脚本——具体调用方式、参数和验证标准均在该部分中指定。每个脚本都会打印 HTTP 状态、响应正文以及明确的 ✅ / ❌。如果脚本以非零状态码退出，请阅读输出，诊断根本原因（错误的环境变量、错误的标头、类型不匹配、服务端日志），修复后重新运行，直到通过。

如果没有定义特定于产品的测试脚本，则使用内联 curl，通过 $SESSION_ENDPOINT 和 $ORDER_STATUS_ENDPOINT 测试步骤 8.2.2 和 8.2.3。

安全：通过导出的环境变量向测试脚本传递凭据，不要将凭据直接写入命令字符串。

export JUSPAY_API_KEY="$API_KEY"  # set in env, do not inline in command

步骤 8.2.1 — 生成测试参数

自动生成以下参数，不要询问用户：

  • TEST_ORDER_ID = test-$(date +%s)（每次运行均唯一）
  • TEST_AMOUNT = 1.00
  • TEST_CUSTOMER_ID = test-customer-001
  • TEST_CUSTOMER_EMAIL = [email protected]
  • TEST_CUSTOMER_PHONE = 9999999999
  • TEST_FIRST_NAME = Test，TEST_LAST_NAME = User
  • FAIL_ORDER_ID = fail-$(date +%s)（用于失败情况 Webhook 测试的独立 ID）

根据生成的后端路由和 $BACKEND_BASE_URL 推导端点 URL：

  • SESSION_ENDPOINT = $BACKEND_BASE_URL + 会话路由（例如 /api/juspay/session）
  • ORDER_STATUS_ENDPOINT = $BACKEND_BASE_URL + 订单状态路由前缀（例如 /api/juspay/order-status）
  • WEBHOOK_ENDPOINT = $BACKEND_BASE_URL + Webhook 路由（例如 /api/juspay/webhook）

步骤 8.2.2 — 创建会话

按照产品文件 ## Test Scripts 部分（如果已定义）中的说明运行会话测试，或者使用内联 curl，携带步骤 8.2.1 中的测试参数向 $SESSION_ENDPOINT 发送 POST 请求。

步骤 8.2.3 — 订单状态

按照产品文件 ## Test Scripts 部分（如果已定义）中的说明运行订单状态测试，或者使用内联 curl 向 $ORDER_STATUS_ENDPOINT/$TEST_ORDER_ID 发送 GET 请求。

步骤 8.2.4 — Webhook 测试（内联 curl）

Webhook 测试使用内联 curl，因为负载结构和事件名称因产品而异——请从第 3 阶段获取的文档中的 Webhook 部分推导这两项：

# SUCCESS — credentials passed via env, not inline
curl -s -w "\n%{http_code}" -X POST "$WEBHOOK_ENDPOINT" \
  -H "Content-Type: application/json" \
  -H "Authorization: Basic $(printf '%s:%s' "$WEBHOOK_AUTH_USERNAME" "$WEBHOOK_AUTH_PASSWORD" | base64)" \
  -d '<payload constructed from docs — substitute $TEST_ORDER_ID and $TEST_JUSPAY_ORDER_ID>'

断言：HTTP 200，且正文包含 {"status":"ok"}，并且 DB 行中的 payment_status = 文档中指定的成功状态。

使用 $FAIL_ORDER_ID 对失败事件类型重复测试（先使用 test-session.sh 为其创建会话）。

断言：HTTP 200，且 DB 行中的 payment_status = 文档中指定的失败状态。

步骤 8.2.5 — 约束边界情况测试（内联 curl）

对于 $CONSTRAINTS 中定义了 maxLength、minValue 或 type 的每个字段，生成一个边界测试。仅测试属于后端 API 请求的字段（跳过仅客户端 SDK 字段）：

  • maxLength 测试：发送长度恰好为 maxLength + 1 个字符的字段值 → 预期返回该字段在文档中指定的错误代码（来自 $CONSTRAINTS[field].errors）。断言 HTTP 4xx，且响应正文包含预期错误代码。
  • minValue 测试：发送值为 minValue - 1 的字段 → 预期返回文档中指定的错误。断言 HTTP 4xx，且正文中包含预期错误代码。
  • type 测试：当 type = Integer 或 Decimal 时发送字符串 → 预期返回文档中指定的错误。断言 HTTP 4xx，且正文中包含预期错误代码。
  • enumValues 测试：发送不在 enumValues 中的值 → 预期被拒绝。断言 HTTP 4xx。

在步骤 8.4 的表格中将类型报告为 Constraint。

步骤 8.3 — 前端 / SDK 测试

当 $PRODUCT_TYPE = sdk 或 $PRODUCT_TYPE = hybrid 时，适用此步骤。

步骤 8.3.1：获取测试凭据（所有 SDK/hybrid 产品）

juspay-docs-mcp:doc_fetch_tool({ url: "<test-resources md content link from $DOC_MAP>" })

提取：

  • $TEST_CARDS — Dummy PG / 模拟器的卡号、有效期和 CVV
  • $TEST_UPI_VPA — 用于 UPI 成功/失败场景的 VPA 值（例如 success@upi、failure@upi）
  • $DUMMY_PG_FLOWS — 在模拟器上为每种支付方式触发成功与失败的方法

步骤 8.3.2：按平台分支

Web / iframe-web

集成检查清单中的阶段（New Card、UPI Collect、UPI Intent、Wallet 等）只有在真实交易通过托管支付页面流转时，才会在 Juspay 的服务器上注册。对于每个阶段：

  • 从会话响应中导航至支付页面 URL
  • 使用 $TEST_CARDS / $TEST_UPI_VPA 完成一笔交易
  • 验证回调 / 重定向是否到达 $RETURN_URL
  • 如果支付页面会阻止无头浏览器或要求 CAPTCHA，请明确说明，不要悄悄跳过
Mobile (react-native, flutter, android, ios, cordova, capacitor)

SDK UI 在设备 / 模拟器上运行，无法通过 CLI 驱动。提供指南前，请明确说明：

“后端测试（Step 8.2）已完成。客户端 SDK 需要在设备或模拟器上手动验证。”

根据 $TEST_CARDS、$TEST_UPI_VPA、$DUMMY_PG_FLOWS 和 Phase 7 检查清单中的集成阶段，生成可直接运行的手动测试指南：

## Manual SDK Test Guide

### Setup
- Build and install: `npx expo run:android` / `npx expo run:ios` / `flutter run` / etc.
- Backend must be running at: $BACKEND_BASE_URL

### Test flows

| # | Flow | Test input | Expected result |
|---|------|------------|-----------------|
| 1 | New Card — success | [success card from $TEST_CARDS] | Payment succeeds, app shows success |
| 2 | New Card — failure | [decline card from $TEST_CARDS] | Payment fails, error shown gracefully |
| 3 | UPI Collect — success | [success VPA from $TEST_UPI_VPA] | UPI request sent, payment succeeds |
| 4 | UPI Collect — failure | [failure VPA from $TEST_UPI_VPA] | Failure handled gracefully |
| 5 | Back / cancel | Tap hardware/software back on payment screen | App returns to checkout, no order corruption |
| [other stages from Phase 7 checklist] | | | |

### After each test
- DB: verify `payment_status` updated (via webhook)
- App: success/failure screen matches the payment outcome
Step 8.4 — 报告结果

所有测试完成后，报告一张统一的通过 / 失败表：

| Test | Type | Result |
|------|------|--------|
| POST {session endpoint} → sdkPayload + DB row | Backend | ✅ / ❌ |
| GET {order-status endpoint} → status field | Backend | ✅ / ❌ |
| POST {webhook endpoint} <success event> → DB updated | Backend | ✅ / ❌ |
| POST {webhook endpoint} <failure event> → DB updated | Backend | ✅ / ❌ |
| {field} maxLength exceeded → {expected error code} | Constraint | ✅ / ❌ / — |
| {field} below minValue → {expected error code} | Constraint | ✅ / ❌ / — |
| {field} wrong type → {expected error code} | Constraint | ✅ / ❌ / — |
| New Card — success | Web / ⏭ manual on device | ✅ / ❌ / ⏭ |
| New Card — failure | Web / ⏭ manual on device | ✅ / ❌ / ⏭ |
| UPI Collect — success | Web / ⏭ manual on device | ✅ / ❌ / ⏭ |
| UPI Collect — failure | Web / ⏭ manual on device | ✅ / ❌ / ⏭ |
| [other stages from Phase 7] | Web / ⏭ manual on device | ✅ / ❌ / ⏭ |

— = 此类别未找到可进行约束测试的字段；每个受约束字段各展开一行 Constraint。

⏭ = 无法通过 CLI 自动化；已在 Step 8.3.2 中提供手动测试指南。

如果任何自动化测试无法完成（支付页面阻止无头浏览器、CAPTCHA 等），请明确说明原因，绝不要悄悄标记为通过。

integrate-results set active working
integrate-results step-end passed "backend tests: session ✅ order-status ✅ webhook-success ✅ webhook-failure ✅; SDK: manual guide provided"
Step 8.5 — 确认集成阶段

使用与 Step 5.1 相同的参数再次调用 juspay_integration_monitoring_status，以验证测试活动是否已记录到商户账户中：

juspay-mcp:juspay_integration_monitoring_status({
  platform: <same mapping as Step 5.1>,
  product_integrated: <same mapping as Step 5.1>,
  merchant_id: $MERCHANT_ID,
  start_time: <30 days ago in YYYY-MM-DDTHH:MM:SSZ>,
  end_time: <now in YYYY-MM-DDTHH:MM:SSZ>
})

按照与 Step 5.1 相同的遍历路径，将每个 stageKey 的 status 与 $INTEGRATION_STAGES 中的基线进行比较。同时，将新的 queryData.scoreData 与 $SCORE_BASELINE 进行比较。

报告一张差异表——每个 $INTEGRATION_STAGES 中的阶段占一行：

## Integration Stage Confirmation

| Stage | Section | Critical | Before | After | Change |
| ----- | ------- | -------- | ------ | ----- | ------ |
| [stageDisplayName] | [section] | ⚠️ / — | [baseline status] | [new status] | ✅ / ⚠️ / ❌ |
  • Before / After 值：PASSED | FAILED | NOT_ATTEMPTED
  • Change 列：
    • ✅ — 状态变为 PASSED（原为 NOT_ATTEMPTED 或 FAILED）
    • ⚠️ — 状态没有变化
    • ❌ — 状态退步（原为 PASSED，现为 FAILED 或 NOT_ATTEMPTED）

在表格下方，打印分数变化值：

Critical stages: [new baseCriticalSuccessCount] / [baseCriticalTotalCount] passing
                 (was [baseline baseCriticalSuccessCount] / [baseCriticalTotalCount])
All stages:      [new baseTotalSuccessCount] / [baseTotalCount] passing

如果任何关键阶段（criticalResult: true）在测试后仍为 NOT_ATTEMPTED 或 FAILED，请将其标记为上线阻碍：

“⚠️ 阶段 [stageDisplayName] 为关键阶段，且仍未通过。必须在正式上线前解决。”

将 test 任务切换为 completed。

PHASE 9 — 集成摘要

运行：integrate-results step-start summary | 将 summary 任务切换为 in_progress

撰写一份持久化的、面向开发者的摘要，记录此次集成过程中所做的每项更改。未来的开发者可以通过此文件了解新增内容、配置内容以及集成预期；此文件是唯一需要查阅的地方。

Step 9.1 — 定位或创建摘要目录

按照以下优先顺序，扫描项目根目录中是否存在文档或笔记目录：

根目录中找到的目录写入位置
存在 docs/docs/juspay-integration/
存在 memory-bank/memory-bank/juspay-integration/
存在 notes/notes/juspay-integration/
以上目录均不存在项目根目录下的 juspay-integration/

如果所选目录尚不存在，则创建该目录。文件名设为 [product]-[YYYY-MM-DD].md（例如，hyper-checkout-2026-05-25.md）。如果此前的运行已创建同名文件，请追加数字后缀（-2、-3……），不要覆盖该文件。

第 9.2 步 — 编写摘要文件

使用 Write 工具创建文件。根据本次工作流运行中实际完成的内容填充各个部分——省略未做任何更改的部分。切勿编造条目。

# Juspay Integration Summary — [Product] on [Platform or API]

**Date:** [YYYY-MM-DD]  
**Merchant ID:** [MERCHANT_ID]  
**Docs base:** [first page URL from $DOC_MAP, for reference]

---

## Environment Variables

Variables added to `.env` or `.env.local` during this integration (names only — never values).

| Variable                            | File | Purpose                     |
| ----------------------------------- | ---- | --------------------------- |
| JUSPAY_API_KEY                      | .env | API authentication          |
| JUSPAY_MERCHANT_ID                  | .env | Merchant account identifier |
| JUSPAY_CLIENT_ID                    | .env | SDK client identifier       |
| JUSPAY_WEBHOOK_USERNAME             | .env | Webhook Basic Auth username |
| JUSPAY_WEBHOOK_PASSWORD             | .env | Webhook Basic Auth password |
| [any others written during codegen] |      |                             |

---

## API Routes Created / Modified

| Method | Path | File | Description |
| ------ | ---- | ---- | ----------- |

[one row per route generated in Phase 5 — e.g., POST /api/juspay/session, GET /api/juspay/order-status/:orderId, POST /api/juspay/webhook]

---

## Database Changes

| Change | Table / Model | Migration file | Columns added / modified |
| ------ | ------------- | -------------- | ------------------------ |

[one row per table or model created or altered in Phase 5 DB work]

---

## Order / Payment Status Mapping

Juspay statuses mapped to app-internal statuses in the webhook handler and order-status utility.

| Juspay status | App status | Mapped in |
| ------------- | ---------- | --------- |

[rows derived from status values used in the generated webhook handler and order-status code]

---

## Frontend Routes / Pages

| Route | File | Description |
| ----- | ---- | ----------- |

[rows for any frontend pages, redirect handlers, or return-URL routes created in Phase 5]

---

## SDK / Packages Installed

| Package | Version pinned | Platform |
| ------- | -------------- | -------- |

[rows from packages installed in Step 5.3 or Phase 6 — names and versions from the docs]

---

## Config Files Created or Modified

| File | Change type | Notes |
| ---- | ----------- | ----- |

[rows for build configs, platform config files, .env, gradle files, Podfile, pubspec.yaml, etc. touched during the integration]

---

## Webhook Configuration

| Setting           | Value                                                                           |
| ----------------- | ------------------------------------------------------------------------------- |
| Webhook URL       | [WEBHOOK_URL]                                                                   |
| Events subscribed | [comma-separated list of event names where value is true in the updated config] |

---

## Return URL

[RETURN_URL]

---

## Other-Side TODO _(only present when `$SINGLE_SIDE_MODE = true`)_

> This section is written **only** when Step 2.2.5 detected a single-side codebase and the user chose to continue with one side. Omit it entirely if both sides were present.
>
> **Do not hardcode any steps here.** Every checklist item must be derived from the docs fetched in Phase 3. Walk `$DOC_MAP` for `$MISSING_SIDE`-facing sections (e.g. sections labelled "Backend", "Server", "API" if `$MISSING_SIDE = backend`; sections labelled "Frontend", "Client", "SDK", platform names if `$MISSING_SIDE = frontend`). For each page in those sections, extract the required actions and emit one checklist item per distinct action, using the exact names from `$CODE_EXAMPLES` and `$CONSTRAINTS`.

### What must be implemented on the [$MISSING_SIDE] before go-live

[One checklist item per required action from the $MISSING_SIDE-facing doc sections in $DOC_MAP. Group items under the same section headings used in the docs. Use exact method/field/file names from $CODE_EXAMPLES and $CONSTRAINTS — no invented names.]

---

## Notes

[Non-obvious decisions, workarounds, known caveats, or anything a future developer would need to know. Do not include credential values. Examples: why a particular status mapping was chosen, a version constraint from the docs, a quirk of the SDK init flow, etc.]

integrate-results step-end passed "summary written to [path]; N env vars, N routes, N DB changes, N status mappings documented"

如果某个类别未做任何更改，请将相应部分留空（例如，如果此产品的文档不需要任何环境变量，请完全省略 Environment Variables 部分，而不是写“None”）。

将 summary 任务切换为 completed。

入口点

ID起始步骤用例
defaultproduct-select从头开始完成完整集成
--from doc-fetchdoc-fetch重新获取文档（例如产品／平台更改后）
--from codegencodegen重新生成代码（文档已获取）
--from testtest仅重新运行实时测试
--from summarysummary仅重新编写集成摘要

使用 --from <step> 时，预先填充 8 个 STATIC_STEPS，以及入口点之前本应生成的任何动态步骤（例如，在 React Native 项目中使用 --from codegen 时，也要预先填充 react-native-setup 和 checklist）。立即将入口点之前的所有步骤标记为 completed（连续执行 step-start／step-end passed "resumed from --from flag"）。

完成

运行：integrate-results step-start done | 将 done 任务切换为 in_progress

时间汇总

运行时间汇总脚本：

.claude/skills/integrate/scripts/lifecycle/done

脚本会输出：

  1. 一张 Markdown 时间表（步骤、状态、耗时、验证），其中耗时占总时间 ≥30% 的步骤以粗体显示。
  2. 总墙钟时间行。
  3. 一行 **Slowest step**:。
  4. 一个包含机器可读数据的 <<<FACTS ... FACTS 代码块（totalSeconds、slowestStep、dominantSteps、skippedSteps、failedSteps、product、platform、productType）。

向用户输出该表格。不要自行计算耗时。

优化建议

读取 FACTS 代码块，并根据实际耗时提出 2–3 条具体建议：

  • 如果 doc-fetch 占用时间最多：建议在仅需重新生成代码时，重新运行 --from codegen
  • 如果 test 失败：指出失败的测试，并说明修复后如何使用 --from test 重新运行
  • 如果 {platform}-setup 耗时较长：指出具体的构建步骤，并建议重新运行时使用 --from codegen
  • 如果 params 耗时较长：瓶颈在于用户交互——建议下次运行时使用 --product <id> --platform <id> 跳过发现步骤
  • 如果 product-select + platform-detect 占用时间最多：建议使用 --product <id> 标志以加快重新运行

建议应针对本次运行的数据，不要给出泛泛的建议。

完成状态
integrate-results set status completed    # or "failed" if any phase failed without recovery
integrate-results set active false
integrate-results step-end passed "integration complete: $PRODUCT on $PLATFORM; timing table printed"

将 done 任务切换为 completed。

"completed" 要求所有步骤均为 passed 或 skipped。任何 failed 步骤都会阻止状态设为 "completed"——请改为调用 integrate-results set status failed。

工具调用参考

何时工具用途
步骤 1.1Read products/*.md加载产品摘要以匹配意图
步骤 1.2juspay_get_merchant_details()自动解析商户 ID、客户端 ID、集成类型 — 推断推荐产品
步骤 1.7explore_product(candidate-id)在推荐前探测类型和平台
步骤 2.1explore_product($PRODUCT)获取完整文档结构和页面 URL；对产品类型分类
阶段 3doc_fetch_tool(url)获取各个文档页面；构建包含类型、maxLength、minValue 等内容的 $CONSTRAINTS 表
步骤 4.1juspay_get_webhook_settings()检查是否已配置 webhook URL
步骤 4.1juspay_get_general_settings()检查是否已配置 return URL
步骤 4.1explore_product("dashboard")首选：获取 dashboard 文档结构，以查找 webhook/设置页面
步骤 4.1doc_fetch_tool(url)从 dashboard 产品中获取 webhook 或常规设置页面；存储为 $DASHBOARD_DOCS
步骤 4.1list_products({ category: "DASHBOARD" })如果 explore_product("dashboard") 失败，则作为后备方案 — 查找正确的 dashboard 产品 slug
步骤 4.2juspay_create_api_key(...)创建新的 API 密钥；仅存储在内存中 — 绝不记录或存储到结果文件中
步骤 5.1juspay_integration_monitoring_status(...)获取集成阶段契约并存入 $INTEGRATION_STAGES；用于确定代码生成必须覆盖哪些流程
步骤 8.5juspay_integration_monitoring_status(...)测试后重新调用，以确认已记录阶段活动；与 $INTEGRATION_STAGES 基线进行差异比较
步骤 5.2（代码输出）从 $CONSTRAINTS 生成验证层 — 在 API 调用前进行长度/值/类型检查
步骤 5.3Bash安装 SDK 包（npm/flutter/gradle/pod）— 名称和版本取自文档
阶段 6Bash运行预构建/生成/同步，运行安装后脚本 — 步骤根据文档确定
阶段 6Edit / Write修补构建配置文件或创建平台配置文件 — 内容根据文档确定
步骤 4.4Bash / Read从 .env / package.json 检测 $BACKEND_BASE_URL；读取 webhook 身份验证凭据
步骤 8.2Bash（产品测试脚本或内联 curl）POST 会话端点；验证 HTTP 200 + 产品专属响应字段 + 数据库行
步骤 8.2Bash（产品测试脚本或内联 curl）GET 订单状态端点；验证 HTTP 200 + 状态字段
步骤 8.2Bash（内联 curl）POST 合成 webhook 事件；载荷取自文档；断言 HTTP 200 + 数据库已更新
阶段 9Bash / Read检测摘要目录（docs/、memory-bank/、notes/ 或项目根目录）
阶段 9Write编写 juspay-integration/[product]-[date].md，包含环境变量、路由、数据库变更和映射
启动integrate-results init初始化生命周期框架
每个阶段integrate-results step-start/step-end为每个阶段记录开始和结束时间，以确保计时准确
元数据integrate-results set存储 product/platform/productType/merchantId — 绝不存储凭据
完成/scripts/lifecycle/done生成计时表 + FACTS 块
仅限后备方案WebFetch仅当 doc_fetch_tool 对有效 URL 返回错误时使用
绝不要自行构造文档 URL。 所有 URL 均来自 explore_product 响应中的 md content link 字段。

输出

每个阶段都会在对话中生成结构化输出：

  • 阶段 1 — 带有已确认 $PRODUCT 的编号产品推荐
  • 阶段 2 — 带有已确认 $PLATFORM 的检测平台确认
  • 阶段 3 — 静默执行（已获取文档页面；已存储 $CONSTRAINTS、$ERROR_CODES、$CODE_EXAMPLES）
  • 阶段 4 — 每个自动解析的设置各用一行确认；仅针对缺失值提问
  • 阶段 5 — 生成代码块：验证层、API 路由、Webhook 处理程序、订单状态工具、可选的数据库架构
  • 阶段 6（仅限移动端）— 原生设置摘要表，每个步骤标注 ✅ / ❌ / 已跳过
  • 阶段 7 — Markdown 集成检查清单 + 参数约束表 + 错误参考表
  • 阶段 8 — 统一的通过/失败测试结果表；移动平台的手动 SDK 测试指南
  • 阶段 9 — 将摘要文件写入 [docs|memory-bank|notes|juspay-integration]/[product]-[YYYY-MM-DD].md
  • 完成 — 包含各阶段耗时的时间表，以及 2–3 条具体的优化建议

防护规则

  1. 此文件中不得包含产品知识。 产品 ID、平台列表和凭据名称均来自 products/ 或 MCP 响应，绝不能来自此文件或训练数据。

  2. 匹配用户意图前先读取 products/。 不要根据训练数据中的熟悉程度猜测哪个产品适用。

  3. 推荐前必须调用 explore_product。 步骤 1.7 为必做步骤。在将产品作为推荐项呈现之前，必须了解其类型和集成复杂度。

  4. 绝不要构造文档 URL。 所有 URL 均来自 explore_product 响应中的 md content link 字段。

  5. 绝不捏造信息。 如果页面未能加载，或文档中没有某个章节，请如实说明。提供原始 URL，供用户手动查看。

  6. 产品类型以 explore_product 为准。 不要根据产品名称或训练数据推断类型。

  7. 平台列表以 $DOC_MAP 为准。 必须原样呈现 explore_product 返回的平台，不得增减。

  8. 仅提供 API 的产品不询问平台。 如果 $DOC_MAP 不包含运行时平台 ID，则完全跳过平台选择。

  9. 代码示例来自文档。 以已获取文档页面中的确切方法名称、类名称和代码结构为准。

  10. 参数和约束来自文档。 实际必填字段、类型、maxLength、minValue 和 enumValues 均以已获取页面中的说明为准，并据此填充 $CONSTRAINTS。

  11. 代码只能使用文档中出现的名称。 如果某个方法或类名称未出现在已获取页面中，则不得使用。

  12. 错误代码来自文档。 从获取的每个页面中收集错误代码，不得自行编造。

  13. 凭据不得离开内存。 $API_KEY、$WEBHOOK_AUTH_PASSWORD 及任何其他密钥都不得出现在验证字符串、任务描述、integrate-results 调用、Bash 命令参数或任何终端输出中。integrate-results 脚本会对已存储字段执行此检查；验证字符串和命令参数由调用方负责。

评论

支持 Markdown