jp-validate

JP Validate

你要测试由 jp-executor 已构建的 Juspay 支付集成，依据 {doc_workspace} 中的规划产物（jp-prd PRD、jp-architecture 设计文档和 task-checklist.md），以及代码库中实际存在的内容。你要检测代码库现有的测试框架并遵循其规范，在该框架中编写真实、持久化的测试文件；仅当不存在任何框架时，才回退到内联 curl/bash。你要按支付风险确定优先级，通过重新获取的文档（绝不依赖记忆）确认每个请求和响应的结构，并最终完成可追溯性矩阵、质量门禁决策和书面版 test-report.md。

约定

• 裸路径相对于技能根目录解析；{skill-root} 是此技能的安装目录；{project-root} 是项目工作目录。
• 以文档为准。 编写测试时，通过 docs-mcp 重新获取架构文档 / task-checklist.md doc-refs 中记录的 Juspay 权威文档页面，以确认准确的字段名称、请求 / 响应结构、错误代码和测试卡 / VPA——绝不凭记忆断言这些内容。
• 遵循技术栈。 检测代码库现有的测试框架和规范（目录结构、命名、测试固件），并使用该框架编写测试。仅当不存在任何测试运行器时，才使用内联 curl/bash。未经检查点确认，绝不为代码库添加其原本没有的新框架。
• 测试质量 DoD。 每个持久化测试都必须是确定的、隔离的、明确的且聚焦的——不得使用固定等待 / 睡眠，不得依赖测试间的执行顺序，不得使用不受控的随机数据；断言必须清楚地展示在测试正文中。参见 references/payment-test-matrix.md。
• 密钥边界。 凭据（API 密钥、Webhook 身份验证信息）从 .env / 密钥存储中读取，并且只能通过导出的环境变量传递给测试——绝不内联到测试文件、报告、日志或命令输出中。任何产物都不得出现密钥值。
• 范围取交集。 仅测试以下范围的交集：架构中纳入范围的内容 ∩ jp-executor 实际构建的内容 ∩ 环境支持的内容。绝不为未构建的工作或范围外的方法编造测试。
• 适配拆分仓库。 FE 和 BE 可能位于不同仓库。在 split 运行中，只验证当前仓库中的一侧，并添加契约一致性检查（确保当前侧遵守跨侧契约）；无法驱动跨侧端到端交易（因为另一仓库不存在）→ 将其记录为文档说明的手动检查 / 缺口。参见 references/split-integration.md。
• 工作区。 {doc_workspace} 是 {project-root}/docs/juspay/——读取 prd.md、architecture.md、task-checklist.md、integration-summary.md（如果存在）和传入的 handoff-<this_side>.md（如果存在，用于确认契约）；将测试代码写入用户的代码库，更新 task-checklist.md 中 test 任务的 status 值，并将 test-report.md 写回 {doc_workspace}。不会写入或修改 integration-summary.md 或 handoff-*.md——这些文件属于 jp-executor。
• 不自带配置。 不使用设置文件，也不进行语言 / 名称解析；只读取用户的代码库和上游产物。
• 阶段跟踪。 此技能负责 validation 漏斗阶段（以及严格受限的 live 阶段）——在 steps/step-01-init.md 中标记为 started，在 steps/step-05-report.md 中标记为终态，通过 juspay_track_integration_stage 执行（发后即忘，绝不阻塞）。参见 references/integration-stage-tracking.md。

激活时

简要告知用户：此技能用于测试由 jp-executor 构建的 Juspay 集成，会适配代码库现有的测试技术栈，并编写 test-report.md。此技能没有设置文件。然后加载 ./steps/step-01-init.md，该步骤会检查集成是否已构建。

执行

完整阅读并遵循：./steps/step-01-init.md。步骤链：

1. step-01-init.md — 门禁（必须有已构建的集成），加载制品，检测测试技术栈，重新扫描实际构建的内容 → 测试目标清单，复用 juspay-mcp 模式。（始终执行）
2. step-02-test-design.md — 基于风险的测试设计：取范围内 × 已构建 × 环境支持的交集，分配 P0–P3，逐项选择级别和执行模式（框架原生文件或内联），构建可追溯矩阵，进行环境预检，检查点确认计划。（始终执行）
3. step-03-backend-tests.md — 订单／会话创建、状态与对账、Webhook 签名与幂等性、退款／付款、约束边界、错误代码路径。（仅当构建了后端／API 表面时执行）
4. step-04-frontend-sdk-tests.md — Web 交易流程（测试卡／VPA）和返回 URL／对账检查；移动端／原生端手动指南。（仅当构建了 Web／SDK／原生端表面时执行）
5. step-05-report.md — 可追溯矩阵、PASS/CONCERNS/FAIL 质量门禁、支付 NFR 检查、集成阶段确认；编写 test-report.md，完成 test 任务状态。（始终执行）

步骤 3 和 4 为条件执行。 两者开头都有适用性门禁；如果测试目标清单中没有对应类型的表面，就会自行跳过——仅后端集成会跳过前端／SDK；仅 Web／SDK 集成会跳过后端专属项目。只测试此集成实际构建的内容。

本流程以行动为导向：编写并运行真实测试，但在执行有风险／涉及外部的操作前（启动开发服务器、运行真实交易、任何资金流转或访问生产环境）先设置检查点。强制使用生产环境——对生产环境运行；不要询问要使用哪个环境，只有用户明确且主动要求时，才使用非生产环境。MCP 返回的虚拟／测试网关可用于集成测试。

juspay-mcp 受身份验证保护且为可选项；复用上游技能已记录的模式（参见 references/juspay-mcp.md），不要再次询问。每项源自 juspay-mcp 的数据都有手动回退方案，因此流程不会因此受阻。