Files
danyang-match/REMAINING_WORK.md
T
Codex 60eeb8aef5 docs(brand): 全仓库 Codex 署名统一为 WorkBuddy + 5 个文件重命名
## 背景
用户指令:「先将 codex 的任务一并改为 workbuddy 的任务」。
Codex 已不再运行,当前由 WorkBuddy 承担开发执行,文档署名需同步。

## 判定规则(用大小写精确区分)
| 类别 | 写法 | 处置 |
|---|---|---|
| 工具署名 | 大写 Codex | → WorkBuddy |
| 分支名 | codex/ui-v11-fidelity | → workbuddy-ui-v11-fidelity(去斜杠,规避本仓库 ref 清理) |
| 已删除文件的历史路径 | 小写 2026-09-11-codex-baseline-cleanup* | 保持原样(记录真实曾存在的文件名,改了即失真) |

结果:26 个文件、126 处署名替换。残留小写 codex 仅 8 处,全部是历史路径。

## 文件重命名(git mv,保留历史)
- Codex开发执行总指令、项目规则与任务拆解.md → WorkBuddy 同名
- Codex首轮启动提示词 + Phase 01~Phase 26 Jira级任务清单 + 每阶段验收条件.md → WorkBuddy 同名
- docs/善缘丹阳 V1.1 Codex 开发执行计划修订版.md → docs/善缘丹阳 V1.1 WorkBuddy 开发执行计划修订版.md
- docs/善缘丹阳 V1.1 Codex-Jira 最终开发任务增量清单.md → docs/善缘丹阳 V1.1 WorkBuddy-Jira 最终开发任务增量清单.md
- docs/善缘丹阳 V1.1 Codex最终主启动提示词(整合版).md → docs/善缘丹阳 V1.1 WorkBuddy最终主启动提示词(整合版).md

引用已同步:AGENTS.md 6 处、AGENTS_SUMMARY.md、以及 4 份计划/规格文档。

## AGENTS.md 两处特别处理
- 「git config user.name = Codex」一句改为不点名工具的表述
- 「feature/ fix/ codex/ ui/ 前缀」示例去掉 codex/

## 有意未改动
- ui-tests/ui-document-baseline-contracts.mjs 的废弃清单仍列 codex-baseline-cleanup*
  那是「必须不存在」的断言目标,改了会让哨兵失去意义
- 仓库 git config user.name 仍是 Codex —— 未擅自改动环境身份。
  如需彻底交接:git config user.name WorkBuddy && git config user.email workbuddy@local

验证:UI 契约门禁 13/13;AGENTS.md 零 Codex 残留;5 个新文件名与全部引用一致
2026-09-16 14:37:44 +08:00

323 lines
9.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 丹阳公益婚恋服务平台 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`
**问题**: 当前测试只是检查常量定义,不是真正的业务逻辑验证。
**需要实现**(每个不变量需要真实业务逻辑测试):
```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调用验证。
**需要实现**:
```java
@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*