danyang-match/REMAINING_WORK.md

丹阳公益婚恋服务平台 V1.0 — 上线前剩余工作

本文件为上线前必须完成的工作清单，按优先级排序。 交由 WorkBuddy 执行。

---

P0 — 上线前必须完成（阻塞性）

P0-1: 产品确认16项技术默认值

文件: docs/PENDING_DECISIONS.md

问题: 以下技术默认值已硬编码，但无产品最终确认：

决策项	当前技术默认值	需要确认
每日推荐数量	6 人	产品确认
推荐最低阈值分数	60 分	产品确认
Pass 冷却时间	180 天	产品确认
照片上限	6 张	产品确认
兴趣标签上限	8 个	产品确认
自我介绍长度上限	500 字符	产品确认
Privacy 默认值	全部 TRUE	产品确认
活动是否需要审核	TRUE	产品确认
活动互选最大人数	3 人	产品确认
活动互选截止时间	48 小时	产品确认
红娘是否允许电话联系	FALSE	产品确认
"正在了解"是否自动暂停推荐	用户选择	产品确认
RelationshipStatus 最终命名	searching/getting_to_know/paused/matched_successfully/service_exited	产品确认
Appeal 是否 V1.0 首发	否（Feature Flag 预留）	产品确认
每日推荐重置时间	00:00 Asia/Shanghai	产品确认

操作:

1. 产品负责人逐一确认以上16项
2. 确认后更新 application.yml 或对应配置类
3. 从 docs/PENDING_DECISIONS.md 移除已确认项
4. 更新 AGENTS.md 中的规则说明（如有影响）

---

P0-2: 隐私政策最终版本确认

问题: Go/No-Go 检查单标注"待确认"，为上线前绝对阻塞项。

操作:

1. 确认隐私政策文本（用户数据采集、存储、使用、共享、权利）
2. 确认用户协议文本
3. 将最终版本放入 docs/legal/ 目录
4. 更新小程序登录页和设置页的协议链接

---

P0-3: PIA（隐私影响评估）书面记录

问题: 9个场景需要书面记录，当前无记录。

操作:

1. 按以下场景撰写PIA记录：
   • 实名认证（身份证采集）
   • 照片存储与展示
   • 位置/地区信息
   • 聊天消息存储
   • 活动报名数据
   • 红娘服务数据
   • 举报与风控数据
   • 账号注销与数据删除
   • 跨组织数据访问
2. 保存到 docs/security/PIA.md

---

P0-4: 提交微信小程序审核

问题: 用户端核心入口，无审核通过的小程序无法服务用户。

操作:

1. 在微信公众平台提交小程序审核
2. 确保所有页面符合微信小程序审核规范
3. 配置好 app.json 中的类目和标签
4. 准备好隐私政策链接（见 P0-2）

---

P0-5: SSL证书申请与DNS配置

问题: 生产HTTPS必需。

操作:

1. 申请SSL证书（Let's Encrypt 或商业证书）
2. 配置生产域名 DNS 解析（match.danyang.gov.cn 或约定域名）
3. 将证书放入 infrastructure/certs/
4. 验证 nginx-production.conf 中的证书路径

---

P1 — 上线前应该完成（重要）

P1-1: CoreInvariantsTest 补充实质性测试

文件: backend/src/test/java/com/danyang/match/platform/invariants/CoreInvariantsTest.java

问题: 当前测试只是检查常量定义，不是真正的业务逻辑验证。

需要实现（每个不变量需要真实业务逻辑测试）:

// INV-001: Required不可自动放宽
@Test
void testRequiredConditionNotRelaxed() {
    // 创建用户A（要求对方学历=本科）和用户B（学历=专科）
    // B进入A的推荐池 → 应该被Required条件过滤
    // 验证B不在推荐结果中
}

// INV-002: 未Mutual不可聊天
@Test
void testCannotMessageWithoutMutual() {
    // 用户A Like用户B，但B未Like A
    // 调用发送消息接口 → 应返回403/禁止
}

// INV-003: Block优先级最高
@Test
void testBlockStopsAllInteractions() {
    // A Block B后
    // 验证B不在A的推荐中
    // 验证A Like B后自动取消
    // 验证A和B的Match自动解除
}

// INV-004: 双向并发Like只创建一个Match
@Test
void testConcurrentLikeCreatesOneMatch() {
    // 线程A: A Like B
    // 线程B: B Like A（并发）
    // 验证只创建1个Match记录
}

// INV-005: 活动名额不超卖
@Test
void testActivityCapacityNotOversold() {
    // 活动剩余1个名额
    // 线程A和线程B同时报名
    // 验证只有1人成功，1人被拒绝
}

// INV-006: 单向活动意向不泄露
@Test
void testActivityInterestNotDisclosed() {
    // A选择B，但B没选A
    // 验证B的查询结果中看不到A的选择
}

// INV-007: 红娘不能替用户Like
@Test
void testMatchmakerCannotLikeForUser() {
    // 红娘角色调用Like接口 → 应返回403
}

// INV-008: 非授权Operator不能读取身份证
@Test
void testUnauthorizedOperatorCannotViewIdCard() {
    // reviewer角色调用敏感身份查看接口 → 应返回403
}

// INV-009: 非案件上下文不能读取聊天
@Test
void testNoChatAccessOutsideCaseContext() {
    // risk_operator无案件授权调用聊天记录 → 应返回403
}

// INV-010: 跨Organization不能越权
@Test
void testCrossOrgCannotAccess() {
    // Organization A的用户，不能访问Organization B的数据
}

注意: 测试应使用真实数据库（集成测试模式），通过 @SpringBootTest + Testcontainers 或指定测试数据库。

---

P1-2: PermissionMatrixTest 补充自动化验证

文件: backend/src/test/java/com/danyang/match/platform/invariants/PermissionMatrixTest.java

问题: 当前只有权限矩阵定义，没有实际API调用验证。

需要实现:

@Test
void testPermissionMatrixAllRoles() {
    // 遍历9个角色 × 18个权限
    // 每个组合：
    //   有权限 → 调用对应API → 应返回2xx
    //   无权限 → 调用对应API → 应返回403
}

// 需要验证的角色：
// super_admin, platform_admin, organization_admin,
// reviewer, matchmaker, activity_manager,
// risk_operator, volunteer, data_viewer

// 需要验证的权限模块：
// user.view, user.sensitive.view, user.status.change,
// review.view, review.process,
// matchmaker.view, matchmaker.assign, matchmaker.service,
// activity.view, activity.create, activity.review_registration,
// risk.report.view, risk.report.process, risk.user.ban,
// organization.manage, permission.manage,
// analytics.view, data.export

验证方式: 通过 MockMvc 或 RestAssured 调用管理端API，使用不同角色的JWT Token认证。

---

P1-3: 补全 Phase 23 系统测试完成报告

文件: docs/Phase-23-Completion-Report.md

问题: Phase 23（系统测试）缺少完成报告。

需要包含:

• 执行的测试类型和数量
• 测试结果（通过/失败/阻塞）
• 安全测试结果（SQL注入/XSS/CSRF等）
• 并发测试结果
• 发现的问题和修复情况

---

P1-4: 清理 CHANGELOG.md 重复内容

文件: CHANGELOG.md

问题: 文件大小3.3MB，存在大量重复条目（同一个Phase变更被复制数十次）。

操作:

1. 去重，保留每项变更的唯一记录
2. 按版本（v1.0.0-rc.1, v1.0.0）组织
3. 文件压缩到合理大小（目标 < 100KB）

---

P2 — 建议完成（非阻塞）

P2-1: AccountLifecycle 注销联动完善

现状: 代码已实现，STATUS.md 标记为TODO。

验证: 确认注销后以下联动正确：

• 推荐停止
• 聊天停止（新消息禁止）
• 红娘服务停止
• 活动处理（未开始的按规则）
• 历史关系保留但标记为已注销

---

P2-2: PhotoService Presigned URL 实现

现状: 代码骨架存在，功能未完整实现。

需要完成:

• PhotoService 生成 MinIO Presigned URL
• 上传凭证接口 POST /me/photos/upload-token
• 下载凭证接口（私有图片访问）
• EXIF信息清理逻辑

---

P2-3: WebSocket 在线状态管理

现状: 骨架实现。

需要完善:

• 用户在线/离线状态跟踪
• 消息送达状态（已发送/已读）
• WebSocket 重连后的状态恢复
• 通知推送（notification.new 事件）

---

执行顺序建议

1. P0-1 (产品确认) → 产品负责人
2. P0-2 (隐私政策) → 产品/法务
3. P0-3 (PIA记录)  → 安全负责人
4. P1-1 (Invariants测试) → 研发
5. P1-2 (权限矩阵测试) → 研发
6. P1-3 (Phase23报告) → 研发
7. P1-4 (CHANGELOG) → 研发
8. P0-4 (微信审核) → 产品
9. P0-5 (SSL/DNS) → 运维
10. P2-1 ~ P2-3 → 研发（可并行）

---

验收标准

每项完成后应满足：

项目	验收条件
P0-1	16项全部产品确认，配置正确，文档更新
P0-2	隐私政策文本在 docs/legal/ 中，链接正确
P0-3	PIA.md 存在，覆盖全部9个场景
P1-1	CoreInvariantsTest 10个用例全部包含真实业务逻辑
P1-2	PermissionMatrixTest 9×18全部覆盖，实际调用验证
P1-3	Phase-23-Completion-Report.md 存在且内容完整
P1-4	CHANGELOG.md < 100KB，无重复条目
P0-4	微信审核提交并通过
P0-5	HTTPS正常，证书有效

---

最后更新: 2026-09-01