跨项目交付验收

验证业务结果，不只验证测试套件。严格区分实现完成、真实链路通过、环境验收通过和生产就绪。

项目规则始终优先。行动前完整读取适用的 AGENTS.md、CLAUDE.md、项目手册、数据库规范和仓库协作流程。

1. 确认规则、仓库和任务边界

1. 开发或测试前，在每个仓库执行：

   git status -sb
   git branch -vv
   git log --oneline --decorate -n 10
   git remote -v

2. 只识别协作环境，不主动改变：
   • 公司 GitLab：遵循项目的分支、Merge Request、CI、保护分支和凭据规则，不套用 GitHub 专用工具。
   • 个人 GitHub：遵循仓库的分支、Pull Request、Actions 和发布规则。
   • 纯本地仓库：除非用户明确授权，否则所有工作保持在本地。
3. 未经用户授权，不得推送、发布、合并、创建 MR/PR、执行生产迁移或删除共享数据。
4. 保留用户已有改动和已有测试证据。
5. 明确任务是“只验收”还是“包含实现”。只验收时记录缺陷和修复建议，不得为了得到通过结论而擅自改代码。

2. 测试前先理解产品目标

按以下顺序定位并完整读取：

1. PRD、产品说明或最终设计文档。
2. 接口契约和数据契约。
3. 实施计划和数据库迁移计划。
4. 当前代码和部署配置。
5. 历史测试报告，只能作为问题线索。

以 PRD/设计文档作为业务基线，以接口和数据契约作为可执行边界。文档互相冲突时，指出冲突及业务影响，不得默认以当前代码为正确答案。

没有设计文档时，根据用户需求、现有行为、契约和代码重建最低验收基线，并把缺少产品事实源列为风险。

执行测试前先建立验收矩阵：

3. 画出真实业务链路

使用业务语言画出预期端到端流程，包含触发输入、每次自动交接、持久化状态、异步任务、最终 API/页面/产物，以及明确绕过的环节。

每个节点只能标记为以下一种状态：

• 已通过：本轮真实执行且有可复核证据。
• 部分通过：主链路已执行，但替换或遗漏了真实依赖、必要变体。
• 失败：本轮结果不符合设计或验收规则。
• 未测试：本轮没有证据。

不得用若干孤立接口测试推断完整业务链路已经通过。

4. 数据库先行

遵循项目自己的迁移事实源，例如 Flyway、Alembic、Liquibase、Prisma、Rails Migration、版本化 SQL 或其他已声明机制。

• 数据库敏感行为使用真实数据库引擎的本地容器或明确隔离的测试环境。
• 同时涉及新安装和历史升级时，分别验证全新迁移和代表性旧版本增量迁移。
• 核对表结构、索引、约束、默认值、历史兼容、必要回填、preflight 和 postflight。
• 按用途区分发布迁移和单轮 fixture，不按 INSERT、UPDATE 等 SQL 动词区分。
• 每个测试数据库都要有清晰场景名并记录用途。
• 不创建大量无法解释的测试库，不静默重置旧证据库。

只有当被绕过的上游页面、上传或第三方入口明确不在范围内时，才允许直接写入上游数据库。必须声明绕过边界，只插入输入或必要前置数据，随后让下游同步、队列、Worker 和业务结果真实发生。禁止预填快照、任务、报告或成功状态后声称自动链路通过。

5. 分层执行测试

从小到大执行：

1. 迁移和 Schema 检查。
2. 改动范围单元测试和契约测试。
3. 使用真实数据库或 Broker 的仓库集成测试。
4. 启动实际服务并跨仓调用 HTTP/RPC。
5. 验证队列、调度器、Worker、Webhook 或事件处理。
6. 核对最终业务产物和各层持久化数据。
7. 按风险执行全仓回归。

每轮真实链路使用新的测试身份、runId、幂等键或 fixture 批次，并记录关键 ID 和时间。

Mock 可以扩大覆盖面，但不能证明真实集成。报告中必须分别列明：

• 真实服务和真实外部提供方；
• 本地确定性替身；
• Mock/Fake；
• 未测试依赖。

6. 优先验证业务高风险边界

优先检查可能丢数据或阻碍正常业务的问题：

• 重复请求和幂等；
• 并发首次写入和唯一性；
• 重试、延迟投递和乱序到达；
• 部分写入和事务边界；
• 旧版本、串版本和意外覆盖；
• 空数据、历史数据、部分数据、损坏数据和超长数据；
• 依赖超时、4xx/5xx、非法响应、Broker 故障和 Worker 崩溃；
• 错误任务路由和永久停在中间态；
• 降级时是否仍能保住主业务结果。

每个失败都记录复现方式、预期行为、实际行为、数据影响、用户影响、发布级别和边界清晰的修复方案。

7. 执行适量性能探测

性能只作为辅助证据，不能替代正确性。

• 记录机器和容器资源、副本数、进程数、线程/Worker、连接池、数据库拓扑和压测端位置。
• 依次执行冒烟、低/中并发和一次有边界的容量探测。
• 记录请求数、持续时间、RPS、P50/P95/P99、超时、预期冲突/降级和非预期错误率。
• 数据库关键接口检查执行计划和预期索引。
• 对照设计门槛或 SLO。
• 不把本地单进程结果直接外推到 test 或生产拓扑。
• 未确认时间、成本和环境权限前，不运行长时间稳定性或破坏性压测。

8. 保留可审计证据链

保留足够证据，让其他人可以确认测试确实执行过：

设计要求
→ 仓库 SHA 和测试环境
→ 输入 fixture 和业务键
→ 上游数据库行/API
→ 自动交接过程和任务 ID
→ 下游持久化状态
→ 最终响应/产物
→ 日志和性能结果

记录真实执行过的命令，包括失败尝试和修正过程，不得伪造整洁的测试过程。

人工验收数据、迁移历史、任务记录、日志和脱敏性能 JSON 默认保留。复测优先使用新 runId，不先清理旧证据。短生命周期 CI 只有在按项目规则导出可独立复核的证据后才能清理。

报告和受版本控制的 fixture 中不得写入真实密码、Token、生产连接串或敏感客户数据。

9. 输出业务优先的验收报告

使用可用的 Markdown 可视化 Skill，优先使用 $jc-markdown-visual-writer-latest。写报告前读取验收报告模板。验收报告以业务结论和证据充分性为主，不为了教学强制套用原始制品循环；只有解释复杂缺陷或链路时按需使用。

第一阅读路径必须回答：

1. 设计中的业务流程是否跑通？
2. 当前功能能运行到什么程度？
3. 还存在哪些 Bug 或未验证依赖？
4. 它们是否阻碍正常使用、test 部署或生产发布？

原始命令、SQL、日志、ID 和测试数量放入证据章节。它们用于支撑业务结论，不能代替业务结论。

10. 只能给出一个完成等级

• 代码已完成：已经实现，但没有本轮真实链路证据。
• 本地验证完成：相关真实业务链路及适用边界在本地或隔离依赖中通过。
• test 验证完成：部署拓扑、配置、网络和迁移已在 test 通过。
• 可生产发布：迁移演练、备份、回滚、容量、安全、负责人和发布顺序均已确认。
• 生产发布完成：生产变更已经执行，并完成受控冒烟。

不得因为历史报告通过、Mock 通过、失败属于旧问题或用户期待完成，就提高完成等级。只报告本轮新证据支持的最高等级。