danyang-match/docs/superpowers/plans/2026-10-15-next-phase-validation-roadmap.md

V1.1 下一阶段验证与发布准备计划

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: 在现有微信真机、前端门禁和后端 916 项全量测试通过的基础上，补齐真实数据库并发、完整业务闭环、通知数据一致性和发布前冒烟验证。

Architecture: 保持模块化单体和 PostgreSQL Source of Truth。测试分为 H2 单元/集成测试、Docker PostgreSQL 真实数据库测试、运行中服务冒烟和人工 UAT 四层，任何一层的结果独立记录，不互相替代。

Tech Stack: Java 21、Spring Boot 3、Maven、PostgreSQL、Docker Compose、Vue 3、微信原生小程序、Edge。

Spec: docs/善缘丹阳 V1.1 客户需求基线增量开发与修复计划.md、docs/善缘丹阳 V1.1 数据库与API增量设计.md、docs/STATUS.md。

Global Constraints

• 不清理、回滚或覆盖现有未提交改动。
• 不修改已通过真机验收的业务流程，除非新增验证复现出根因。
• PostgreSQL 是 Source of Truth；H2 只用于快速测试，不能替代真实数据库证据。
• Maven 测试容器继续使用阿里云镜像和 --dns 223.5.5.5 --dns 114.114.114.114，不关闭 TLS 校验。
• 管理端页面验收使用已安装的 Edge，不安装 Chrome/Chromium。
• 测试账号、密码和 Token 只通过环境变量注入，不写入仓库和日志。

---

Task 1: 真实 PostgreSQL 并发测试

Files:

• Inspect: backend/src/test/java/com/danyang/match/platform/concurrent.ConcurrentTests.java
• Modify: backend/src/test/java/com/danyang/match/platform/concurrent.ConcurrentTests.java
• Modify: backend/src/test/resources/application-test.yml（仅在测试 profile 需要新增 PostgreSQL 开关时）
• Test evidence: .mimosa/postgres-concurrency-test.log

Interfaces:

• Consumes: Docker Compose PostgreSQL、现有服务层接口和测试数据清理机制。

• Produces: CI=true 下可执行的 Like 并发和活动容量竞争测试；成功数、重复 Match 数和超容量数有数据库查询断言。

• Step 1: 复核现有并发测试是否只是内存计数。

  • 确认测试使用真实 service/mapper、事务和 PostgreSQL 表，而不是 AtomicInteger 结果模拟。

• Step 2: 建立隔离测试数据。

  • 每个测试使用唯一 run id；结束时按 run id 删除关系、活动报名和 Match 数据。

• Step 3: 用 Docker PostgreSQL 执行并发测试。

  • 命令：docker compose -f infrastructure/docker-compose.yml up -d postgres
  • 命令：docker run --rm ... mvn -s /tmp/settings.xml -B -Dtest=ConcurrentTests -Denv=postgres test

• Step 4: 验证边界。

  • 断言同一对用户最终最多一个 active Match；活动 approved 数不超过 capacity；失败操作有明确错误码。

• Step 5: 保存报告并更新 docs/STATUS.md。

Task 2: 完整注册到牵手 E2E

Files:

• Inspect: backend/src/test/java/com/danyang/match/platform/core/CoreE2ETest.java
• Modify: backend/src/test/java/com/danyang/match/platform/core/CoreE2ETest.java
• Test evidence: .mimosa/core-e2e-postgres-test.log

Interfaces:

• Consumes: 微信登录模拟 provider、实名认证、资料审核、推荐、Like、双向 Match、聊天和成功牵手服务。

• Produces: 一个真实 PostgreSQL 事务闭环测试，覆盖状态迁移和关键权限断言。

• Step 1: 将 @Disabled 占位测试拆成真实步骤。

• Step 2: 每一步先断言数据库状态，再调用下一步。

• Step 3: 增加负向断言。

  • 未审核资料不能进入推荐；未 Mutual 不能聊天；单方成功牵手确认不能完成。

• Step 4: 在 PostgreSQL profile 执行并保存日志。

• Step 5: 仅在完整链路通过后移除 @Disabled，否则保留并将状态标记为 NOT_VERIFIED。

Task 3: 通知数据转换告警治理

Files:

• Inspect: backend/src/main/java/com/danyang/match/platform/notification/mapper/NotificationMapper.java
• Inspect: backend/src/test/java/com/danyang/match/platform/notification/*
• Modify: 对应测试夹具或 schema 文件；只有复现业务根因时才修改生产代码。
• Test evidence: .mimosa/notification-fixture-test.log

Interfaces:

• Consumes: notifications.user_id 的实际 PostgreSQL/H2 类型和通知 mapper 参数类型。

• Produces: 不再出现 u-notif-guard 这类类型转换告警；通知幂等、落库和查询断言保持通过。

• Step 1: 对照 Flyway PostgreSQL schema 和 schema-h2.sql 的 user_id 类型。

• Step 2: 定位夹具使用字符串 ID 的测试用例。

• Step 3: 优先修正测试夹具为合法 UUID；若业务确实支持非 UUID，再修正 mapper 类型契约。

• Step 4: 重跑通知相关测试和全量 Maven 测试。

• Step 5: 在报告中区分“日志告警已消除”和“业务通知真实发送”两种结论。

Task 4: 运行中服务发布前冒烟

Files:

• Use: tests/public-id-web-live.cjs
• Use: tests/admin-dashboard-behavior.cjs
• Use: scripts/miniapp-compile-check.mjs
• Create: .mimosa/release-smoke-20261015.log
• Update: docs/STATUS.md

Interfaces:

• Consumes: Docker 中运行的 backend、PostgreSQL、Redis、nginx、admin-web；Edge 浏览器。

• Produces: 登录、首页统计、红娘服务、联系授权审批、公开编号、未登录 401、关键页面导航的可复现结果。

• Step 1: 备份演示库并记录 Flyway 版本。

• Step 2: 重启整套 Docker 服务并检查健康端点。

• Step 3: 用 Edge 执行管理端页面验收。

• Step 4: 执行 API 冒烟并记录状态码、响应 success/code，不记录 Token。

• Step 5: 验证服务重启后登录、编号查询和工作台统计仍可用。

Task 5: 用户 UAT 与发布决策

Files:

• Use: docs/STATUS.md
• Use: docs/PENDING_DECISIONS.md
• Create: docs/RELEASE-READINESS-2026-10-15.md

Interfaces:

• Consumes: 微信真机复验、Edge 管理端冒烟、后端和前端测试报告。

• Produces: GO、CONDITIONAL GO 或 NO-GO 决策，以及剩余 P0/P1 清单。

• Step 1: 由用户在微信开发者工具复验红娘登录、工作台、服务详情、跟进、完成服务、联系授权审批。

• Step 2: 使用演示数据走一遍用户确认服务 → 管理端完成服务 → 统计回写闭环。

• Step 3: 核对首页数字是否来自接口，而非静态展示。

• Step 4: 记录未完成项：第三方开放、限流阈值、真实微信支付/实名服务等范围外能力继续保持 NOT_IMPLEMENTED 或 NOT_VERIFIED。

• Step 5: 形成发布决策；没有真实 PostgreSQL 并发和完整 E2E 证据时不得给出正式生产 GO。

暂不执行的范围

• 不实现第三方 API Key/OAuth、开放 OpenAPI、调用配额或新的支付能力；这些属于已登记的范围扩张决策。
• 不安装 Chrome/Chromium，不用浏览器替代微信真机验收。
• 不进行大规模重构、分支清理或未授权数据库数据改写。

推荐执行顺序

1. Task 3（先消除测试夹具告警）
2. Task 1（真实 PostgreSQL 并发）
3. Task 2（完整 E2E）
4. Task 4（运行中服务冒烟）
5. Task 5（用户 UAT 与发布决策）