WorkBuddy 52e11a6c65 fix(notification): Phase 11 复验 —— 修复通知类型违反生产 CHECK 约束(生产故障)/ 幂等无库兜底 / 婚前辅导通知未接线
复验模式:KEEP-VERIFY/EXTEND(不轻信历史 ✅,逐条核对运行时路径与生产约束)。

== D3(Critical · 生产故障)通知 type 全量违反生产 CHECK 约束 ==
NotificationService 的 10 个业务模板传入复合 type
(appointment_submitted / counseling_assigned / le_verified / referral_created 等),
而生产 V020__extend_notification_types.sql 的 chk_notification_type 白名单只允许 12 个短名。
真实 PostgreSQL 下这些通知全部落库失败;测试库 schema-h2.sql 未复刻该约束,故历史 334 测试全绿 → 假绿。
修复:
- type 归一为白名单短名,业务细分交由 businessType/title 承担:
  appointment_submitted|_confirmed|_changed -> appointment
  counseling_assigned|_scheduled|_completed  -> counseling
  premarital_scheduled                       -> premarital
  le_need_evidence|le_verified|le_rejected   -> local_eligibility
  referral_created                           -> matchmaker
- 重写 buildPrivacySafeCopy:原以复合 type 为 key 的 Map.ofEntries 归一后产生重复 key 会抛
  IllegalArgumentException(运行期崩溃),改为按短名 switch。
- schema-h2.sql 补齐生产 CHECK 约束(测试保真度下沉)。

== D1(High)通知幂等仅 SELECT-then-INSERT,无 DB 兜底 ==
NotificationMapper.findExisting 为查后插,并发下可重复落库。
修复:新增 V036__add_notification_idempotency_index.sql,建 partial unique index
uk_notification_business(user_id, type, business_type, business_id, content)
WHERE business_id IS NOT NULL(先按 created_at ASC 去重存量数据)。
schema-h2.sql 同步唯一索引(H2 无 partial index,标准 UNIQUE 对 NULL 多行共存语义等价)。

== D2(Medium)婚前辅导通知未接线 ==
premaritalScheduled 零调用;CounselingServiceApp.scheduleCounseling(P13A-T22 管理端路径)完全不发通知。
修复:CounselingService.schedule 与 CounselingServiceApp.scheduleCounseling 均按 service_type 分流,
premarital 走 premaritalScheduled,其余走 counselingScheduled;
管理端路径包 try/catch —— 通知失败不回滚排期事实。

== 测试(基线 334 → 346,+12) ==
- NotificationPhase11IntegrationTest(5):回滚不发通知(Gate 前半)、提交后可见、
  顺序重试幂等、绕过 findExisting 由唯一索引兜底抛异常且最终仅 1 条、business_id IS NULL 多行共存。
- NotificationPrivacyCopyTest(5):反射校验 4 类隐私文案,咨询类不含「咨询」且标题为「服务通知」,
  不泄露姓名/时间/证件类型;未知 type 安全回退;ALLOWED_TYPES 守卫。
- NotificationTemplateTypeGuardTest(2):关键 —— 调用模板方法本身(而非直接传字面量 send),
  断言 10 个模板全部以白名单短名落库。
- MigrationValidationTest:LATEST_MIGRATION 35 -> 36,DDL 校验补 CREATE UNIQUE INDEX 识别。

== 负向验证(两轮,含第一轮失效教训) ==
第一轮:注入复合 type 后 NotificationPhase11IntegrationTest 仍全绿 ——
  因该测试直接 send(..., "appointment", ...) 传字面量,不经过模板方法,属无效守卫。
第二轮:改为 NotificationTemplateTypeGuardTest 调用模板本身,注入后精准抛
  DataIntegrityViolation,守卫有效性得证。教训已写入报告:守卫必须经负向验证证明会变红。

== 证据 ==
全量回归 346 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS
(离线 Docker:danyang-match-backend-test:latest + 卷 danyang-m2-cache)
迁移校验 12/12;定向 19/19。

== Gate 判定 ==
回滚事务不发通知 ✅ | 通知失败不回滚核心事实 ✅ | 隐私安全文案 INV-010 ✅
已提交事务通知失败可重试且不产生重复业务记录 ✅(修复后成立)

== 遗留 gap(登记不自动实现) ==
sendExternal 在事务内同步执行外部副作用,当前为占位实现;接入真实微信推送前必须改为
@TransactionalEventListener(AFTER_COMMIT) / REQUIRES_NEW —— 全仓当前无任何 afterCommit 机制。
2026-09-16 21:50:56 +08:00

善缘丹阳公益婚恋服务平台 V1.1 增量恢复中

面向丹阳市成年单身人士,由公益组织参与运营的实名制公益婚恋服务平台。

真实 · 公益 · 本地 · 安全 · 高效

当前基线: V1.0.0-RC.2 + V1.1 客户需求增量 · 状态:INCREMENTAL RECOVERY / NO-GO

当前代码包含 V1.1 部分实现,但尚未通过 Admin、Miniapp、权限和 E2E 发布门禁。请勿依据历史 Completion Report 或 Jira 勾选项判断已经上线。唯一执行计划见 docs/善缘丹阳 V1.1 客户需求基线增量开发与修复计划.md。


项目简介

本平台帮助丹阳本地单身人士通过实名认证、人工审核、智能匹配、双向喜欢、在线沟通、公益红娘和线下相亲活动,安全、高效、真实地寻找合适伴侣。

用户永久免费。


技术栈

组件 技术
后端 Java 21 + Spring Boot 3.x
数据库 PostgreSQL
缓存/Session Redis
对象存储 S3 兼容(MinIO / 国内云存储)
实时通信 WebSocket
数据库迁移 Flyway
小程序 微信原生 + TypeScript
管理后台 Vue 3 + TypeScript + Vite + Pinia + Element Plus
容器化 Docker + Docker Compose + Nginx
CI/CD GitHub Actions

项目结构

├── backend/          # Spring Boot 后端服务
├── miniapp/          # 微信小程序用户端
├── admin-web/        # 运营管理后台(Web)
├── infrastructure/   # Docker Compose 编排
├── scripts/          # 运维脚本
├── tests/            # 测试代码
│   ├── unit/
│   ├── integration/
│   ├── api/
│   ├── permission/
│   ├── concurrency/
│   ├── e2e/
│   └── invariants/   # 核心不变量测试(每次CI必跑)
├── docs/             # 项目文档
│   ├── product/
│   ├── architecture/
│   ├── api/
│   ├── database/
│   ├── security/
│   ├── testing/
│   ├── ops/
│   └── decisions/
├── AGENTS.md         # 项目最高执行规则摘要
├── CHANGELOG.md
└── README.md

快速开始(开发环境)

前置要求

  • Docker & Docker Compose
  • JDK 21
  • Node.js 18+
  • npm / pnpm

一键启动基础设施

# 进入基础设施目录
cd infrastructure

# 启动 PostgreSQL / Redis / MinIO
docker compose up -d

# 等待服务就绪(约30秒)
# 可运行:docker compose logs -f

启动后端

cd backend

# 复制环境变量
cp src/main/resources/application-dev.yml.example src/main/resources/application-dev.yml
# 编辑 application-dev.yml,设置数据库连接等

# 构建并启动
./mvnw spring-boot:run -Dspring-boot.run.profiles=dev

启动管理后台

cd admin-web

# 安装依赖
pnpm install

# 启动开发服务器
pnpm dev

启动小程序

使用微信开发者工具打开 miniapp/ 目录,配置 AppID 后即可预览。


环境变量

所有环境变量参见各模块的 .env.example 文件。

关键变量:

# 数据库
DB_HOST=localhost
DB_PORT=5432
DB_NAME=danyang_match
DB_USER=app_rw
DB_PASSWORD=<secret>

# Redis
REDIS_HOST=localhost
REDIS_PORT=6379

# 对象存储
MINIO_ENDPOINT=localhost:9000
MINIO_ACCESS_KEY=<secret>
MINIO_SECRET_KEY=<secret>
MINIO_BUCKET_PUBLIC=public
MINIO_BUCKET_PRIVATE=private

# 微信
WECHAT_APP_ID=<secret>
WECHAT_APP_SECRET=<secret>

Secret 不进 Git。


数据库迁移

cd backend
./mvnw flyway:migrate -Dflyway.url=jdbc:postgresql://localhost:5432/danyang_match

运行测试

Phase 01 一键基线检查

PowerShell:

.\scripts\verify-phase01.ps1

Bash:

./scripts/verify-phase01.sh

脚本依次检查 Git、Backend tests、Admin type-check/build、Miniapp TypeScript 和 V1.1 E2E。任一门禁失败时脚本返回非零退出码,并在结尾列出失败项。Windows 未安装 JDK/Maven 时,Backend 检查使用 Docker 中的 JDK 21 与仓库内 Maven 包;不会永久修改系统环境。

首次执行 Admin/Miniapp 检查前,在 admin-web 目录运行 npm ci。E2E 使用 python -m pytest,不要依赖全局 pytest 命令。

分项命令

# 后端单元测试
cd backend
./mvnw test

# 后端集成测试
./mvnw verify

# 管理后台构建检查
cd admin-web
pnpm build

# 小程序编译检查
cd miniapp
# 在微信开发者工具中查看编译结果

构建部署

# 构建后端镜像
docker build -t danyang-match-backend:latest ./backend

# 构建管理后台
cd admin-web && pnpm build

# 完整部署
cd infrastructure && docker compose up -d

核心业务闭环

微信登录 → 绑定手机 → 实名认证 → 填写资料 → 设置择偶 → 提交审核
    ↓
审核通过 → 系统推荐 → 用户Like → 双向Match → 安全聊天
    ↓
公益红娘辅助 / 参加线下活动 → 进一步了解 → 双方确认成功牵手

开发阶段

项目按 Phase 01~Phase 26 顺序推进。详见 docs/STATUS.md。


许可证

本项目为公益项目,服务于丹阳市单身人士婚恋匹配。

S
Description
善缘丹阳公益婚恋平台
Readme Unlicense
29 MiB
Languages
Java 53.1%
Vue 14.9%
JavaScript 12.5%
HTML 9.6%
TypeScript 3.8%
Other 6.1%