danyang-match/docs/善缘丹阳 V1.1 客户需求基线增量开发与修复计划.md

善缘丹阳 V1.1 客户需求基线增量开发与修复 Implementation Plan

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: 在保留已经验证正确的 V1.0 婚恋核心和 V1.1 数据资产的前提下，依据客户最新修订文档修复当前伪完成、权限越界、前端不可用和业务闭环缺失问题，交付可测试、可运营、可回滚的善缘丹阳 V1.1。

Architecture: 继续使用 Java 21 + Spring Boot 模块化单体、PostgreSQL、Redis、私有对象存储、Vue 3 统一运营后台和微信原生 TypeScript 小程序。V1.1 是 V1.0 的增量升级，不新建第二套系统；正确模块 KEEP，缺少能力 EXTEND/ADD，错误首页和活动互选逻辑 REPLACE/REFACTOR。

Tech Stack: Java 21、Spring Boot 3.x、Spring Security、MyBatis-Plus、Flyway、PostgreSQL、Redis、WebSocket、S3-Compatible Private Object Storage、Vue 3、TypeScript、Vite、Pinia、Element Plus、微信原生小程序、Docker Compose、Nginx。

Spec: docs/善缘丹阳 V1.1 WorkBuddy最终主启动提示词（整合版）.md、docs/superpowers/specs/2026-09-13-reference-driven-dual-client-ui-redesign-design.md、docs/善缘丹阳 V1.1 数据库与API增量设计.md、docs/善缘丹阳 V1.1 页面级功能清单与交互流程修订版.md、docs/善缘丹阳 V1.1 WorkBuddy 开发执行计划修订版.md、docs/善缘丹阳 V1.1 WorkBuddy-Jira 最终开发任务增量清单.md。

Global Constraints

• 这六份客户修订文档共同构成 V1.1 需求基线，不能以其中一份覆盖其余文档的专业域要求。
• 主启动提示词负责执行纪律和不变量；页面清单负责功能与交互；2026-09-13 参考图重设计规格是唯一视觉和状态基线；数据库/API 文档负责数据契约；执行计划和 Jira 增量清单负责 Phase、任务与依赖。
• 文档中的“✅、已完成、已部署、MVP完成”属于历史进度声明，不属于客户需求；必须由当前代码、自动化测试和人工流程重新证明。
• V1.0 正确核心按 KEEP 处理，不重新开发；但每个受影响 Phase 必须执行回归门禁。
• V001～V027 已应用迁移不得改写；数据结构修复只能新增向前迁移。
• 用户基础婚恋服务永久免费；不增加支付、会员、金币、礼物、付费曝光或商业广告。
• Required 不自动放宽；普通婚恋 Mutual 后才能聊天；Block 优先级最高；红娘不得替用户 Like 或确认。
• 活动互选必须经过双方分别确认开启沟通，再复用或创建 Match Episode 和 Conversation。
• 本地资格独立于实名认证；咨询独立于红娘；所有新业务复用统一 User、Operator、RBAC、DataScope、Audit、Notification、Risk 和 Object Storage。
• 首页结构、8 个核心入口及其顺序固定；底部导航固定为首页、找对象、消息、活动、我的。
• 用户端采用 #E96B6B 品牌 Token、#FAFAF8 暖白背景、16px 水平边距、44×44px 最小点击区；禁止页面散落硬编码颜色。
• 所有未确认参数配置化；Feature Flag 仅用于灰度和故障关闭，不能把已确认的 V1.1 正式范围降为“以后再做”。
• 单智能体执行时按 Phase 01、02、03……13、13A、14……26 顺序；每个 Phase 输出 Completion Report 后停止。

---

一、对上一版计划的纠正

上一版计划的主要错误不是发现的问题失实，而是处理策略失实：

1. 错误地把主启动提示词当成单一产品规格；正确做法是六份客户修订文档共同约束。
2. 错误地把 V1.0 Phase 01～26 当成全部需要重建；客户文档明确要求“保留主结构、增量修订、不重建全部 Backlog”。
3. 错误地把“未重新验证”统一判成“未完成”；正确做法是 KEEP 项快速回归，只有失败项才进入修复。
4. 错误地声称 U49～U64 全部缺失；实际 U55～U59、U62～U63 已有页面文件，但类型检查和运行链路尚未通过；明确缺失的是 U49～U54、U60、U61、U64。
5. 没有充分区分“数据库已建表”“后端有骨架”“前端可操作”“业务闭环可验收”四种进度。
6. 没有把 Jira/STATUS/PENDING_DECISIONS 中未经验证的 ✅ 当作待清理的项目治理问题。

本计划因此采用：增量恢复 + 纵向闭环 + 证据驱动状态，而不是全项目推倒重来。

二、当前真实进度基线

2.1 已有资产

• V001～V027 迁移文件及对应的 V1.1 表、字段、角色和种子数据已经存在。
• Backend 已有 home、local_eligibility、service_appointment、counseling、content、service_program、activity_mutual 等模块骨架。
• Miniapp 已有 U55～U59、U62～U63 及活动互选结果/等待页面文件。
• Admin Web 已有 Banner、Content、Service Station、Appointment、Program、Counseling、Referral 等 Vue 文件。
• V1.0 Auth、Profile、Review、Match、Like/Block、Messaging、Relationship、Matchmaker、Activity、Risk、Appeal 模块可作为 KEEP 候选。

2.2 不能算作完成的证据

• Admin Web npm run type-check 当前失败：CounselingView.vue 存在语法错误；路由文件未注册 counseling 页面。
• Miniapp TypeScript 当前有 20 余个错误，且 .ts/.js 双轨并存，不能证明运行的是客户修订版本。
• U49 公益服务中心、U50 服务站、U51 预约、U52 我的预约、U53 课堂、U54 内容详情、U60 反诈、U61 专项服务、U64 服务记录没有注册为可访问页面。
• /api/v1/operator/** 当前只统一检查 operator_login，不能满足 Permission + DataScope + Sensitive Permission。
• 用户预约创建仍可从请求体接受 userId，存在替他人创建/越权风险。
• Counseling 的 operator 接口位于 /counseling/services/operator/**，不受现有 /operator/** 过滤规则覆盖。
• Activity Mutual 代码只检测 active Match，没有形成“双方确认后复用/新建 Match Episode + Conversation”的完整事务。
• E2E 文件大量使用 pass，不能证明功能通过；Jira 中相应 ✅ 必须回退为待验证。
• docs/PENDING_DECISIONS.md 同时存在“待确认”与“已部署”矛盾，且包含测试默认账号和密码描述，需清理。

2.3 分层进度估算

层级	当前估算	说明
V1.0 核心资产	70%～85%	代码较完整，但需受影响回归
V1.1 数据模型/迁移	80%～90%	迁移齐全，仍需约束、权限和回滚验证
V1.1 后端业务闭环	35%～50%	多数有骨架，主体、权限、事务和真实聚合不足
V1.1 小程序页面闭环	25%～35%	部分页面存在，缺页、未注册、TS/JS 漂移明显
V1.1 运营后台闭环	20%～30%	文件存在但类型检查失败、路由/权限/交互不完整
自动化测试可信度	10%～20%	大量空壳、fixture 缺失，无法支撑完成声明
发布就绪度	10%～15%	无可信系统测试、UAT、备份恢复和回滚证据

综合开发资产约 45%～55%，可验收业务闭环约 30%～35%。后续进度只按“验收项通过数”计算，不再按文件数量计算。

三、修复策略与执行门禁

3.1 Phase 状态定义

• KEEP-VERIFY：不改业务设计，只跑回归；通过即可关闭。
• EXTEND：保留现有实现，补客户新增能力和测试。
• REFACTOR：保留数据资产，替换错误业务流程或权限边界。
• REPLACE：删除旧运行入口，只保留客户定稿实现。
• ADD：补齐不存在的页面、接口或运营闭环。

3.2 每 Phase 的统一完成证据

• 关联 Jira 任务状态与实际代码一致，禁止仅凭文件存在勾选 ✅。
• Backend 单元/集成测试通过；Admin type-check/build 通过；涉及 Miniapp 时 TypeScript 检查和开发者工具构建通过。
• 新增/修改 POST 的身份主体、幂等、并发和状态机测试通过。
• Permission、DataScope、Sensitive Access 负向用例返回 401/403/404，不能返回脱敏后的 200 冒充拒绝。
• 受影响业务至少完成一条真实 happy path 和一条失败路径人工验证。
• 更新 STATUS、JIRA_BACKLOG、API/数据库/UI 文档以及对应 Completion Report。
• 输出报告并停止，不自动进入下一 Phase。

四、按客户正式 Phase 的增量开发与修复计划

Phase 01：项目治理与可重复构建基线 — EXTEND

Files: AGENTS.md、docs/STATUS.md、docs/PENDING_DECISIONS.md、docs/JIRA_BACKLOG.md、docs/V1_0_TO_V1_1_GAP_ANALYSIS.md、docs/ARCHITECTURE_BASELINE_V1.1.md、README.md、backend/pom.xml、admin-web/package.json、miniapp/project.config.json。

• 将六份客户修订文档登记为共同需求基线，并按专业域定义冲突裁决规则。
• 把未经验证的“已完成/已部署”改为 待验证、部分完成 或 失败；保留历史说明，不伪造完成记录。
• 清除文档中的默认账号密码；测试账号改由本地 seed/环境变量生成且不进入交付文档。
• 建立 Windows PowerShell 与 Bash 两套一键检查入口，覆盖 backend test、admin type-check/build、miniapp type-check、E2E。
• 修复或重新初始化 Git 元数据问题；若无法恢复，记录仓库来源、当前文件清单和后续提交策略，不擅自覆盖用户文件。（当前无法恢复，已记录并等待用户决定）
• 生成 Phase 01 Completion Report 后停止。

Gate: 三端检查命令可重复启动并给出真实成功/失败；项目状态文件不再互相矛盾。

Phase 02：统一认证、RBAC、DataScope 与敏感访问 — REFACTOR

Files: backend/src/main/java/com/danyang/match/platform/shared/filter/PermissionFilter.java、permission/**、security/**、audit/**、V015 后续新迁移、admin-web/src/stores/auth.ts、admin-web/src/router/index.ts。

• 先写角色×资源×动作×数据范围矩阵测试，覆盖 counselor、counseling_manager、content_editor、service_station_operator。
• 用明确的用户 Principal 和 Operator Principal 替代各 Controller 自行解析 token/userId。
• 移除 /operator/** → operator_login 粗粒度授权，改为接口 Permission + Service DataScope 双重校验。
• 把当前不在 /operator/** 下的运营接口统一迁移或施加同等级方法权限。
• 验证 ContentEditor 无用户婚恋数据权限、Counselor 仅 Assigned、ServiceStationOperator 仅站点/任务范围、Organization 关系不继承权限。

Gate: 权限正向用例通过，四类越权负向用例全部被服务端拒绝并写审计；前端菜单隐藏仅作为体验，不作为安全控制。

Phase 03：实名认证增量预留 — EXTEND

Files: verification 模块、miniapp/pages/verification/**、FeatureFlag 配置。

• 验证 V1.0 实名、年龄、加密/hash 和状态流转回归。
• 保留 liveness/provider/verification_level 预留；人脸首发未确认前不实现自研识别、不保存 face embedding。
• 删除任何“官方婚姻状态认证、100%真实”的前端文案。

Gate: 实名状态来自数据库而非首页硬编码；人脸 Flag 关闭时流程可正常完成。

Phase 04：Profile、Preference 与本地资格 — EXTEND

Files: local_eligibility/**、profile/status/capability 服务、miniapp/pages/local-eligibility/**、miniapp/pages/local-eligibility-supplement/**。

• 保留 V1.0 Profile/Preference，补齐本地资格声明、按需补证、提交、状态查询和 /me/status。
• 用户 API 的 userId 只能来自认证主体；佐证文件进入私有存储，先鉴权再签名。
• 将本地资格佐证触发规则、数量、大小、类型和保留期限全部配置化。
• 把 U62/U63 接入首次准入与“我的”，并覆盖未提交、声明完成、待补充、审核中、已核验、未通过状态。

Gate: 本地资格与身份表独立；非本人和无特殊权限人员不能读取佐证。

Phase 05：统一审核扩展 — EXTEND（2026-09-12 已完成）

Files: review 模块、local eligibility service、admin-web/src/modules/review/ReviewView.vue。

• 复用现有 ReviewTask，增加 local_eligibility 类型，不建第二套审核引擎。
• 验证 Claim 原子性、Need Evidence、Approve、Reject 与本地资格状态联动。
• 每次查看敏感佐证记录 purpose、operator、target、timestamp、result。

Gate: 两名审核员不能同时 claim；审核通过/拒绝与前台状态一致。

Phase 06：Match Eligibility 增量 — KEEP/EXTEND（2026-09-12 已完成）

Files: match/service/MatchEligibilityService.java、RecommendationEngineService.java、对应测试。

• 先跑 V1.0 双向 Required、Block、Paused、Successful 和隐私回归，不重写正确算法。
• 仅在配置要求时把本地资格接入 eligibility；不得自动放宽 Required。
• 确认首页推荐仍调用正式 Match Engine，推荐数量、阈值、冷却均配置化。

Gate: 双方任一 Required 不满足时永不入选；前台不显示数字匹配率。

Phase 07：V1.1 首页唯一实现 + 找对象 — 业务证据保留，UI REOPENED（2026-09-13）

后端聚合、Capability、8 入口及推荐规则的专项证据保留；旧页面视觉已被用户否决。当前 UI 实施入口仅为 docs/superpowers/plans/2026-09-13-reference-driven-dual-client-ui-redesign.md，不得按本节历史完成标记恢复旧设计。

Files: home/**、banner 读取服务、miniapp/pages/index/**、miniapp/pages/discover/**、首页组件、miniapp/app.json、Design Token。

• 为 HomeApplicationService 写聚合契约测试，确保它调用正式 status、match、activity、location、content、capability 服务，不复制规则。
• 修复硬编码 verified、空 recommendations/articles、固定服务站和错误入口路由。
• 固定首页顺序：品牌、状态、Banner、8 入口、推荐、公益服务、活动、服务站、课堂、安全提醒。
• 固定 8 入口顺序并分别路由到真实页面；未开放时展示服务端 Capability 返回的 Disabled 原因。
• 统一 TypeScript 为唯一源，配置小程序 TypeScript 编译；移除同页手写 .ts/.js 逻辑漂移。
• 落实未登录、未实名、审核中、Searching、Paused、Successful、空数据、网络错误、Skeleton 状态矩阵。
• 迁移完成后删除旧首页运行逻辑，不保留 /home-old。

Gate: 首页 5 秒识别品牌和主要入口；Banner 仅内部目标；首页真实聚合数据可用；小程序 TS 检查和开发者工具构建通过。

Phase 08：Like / Match / Block — KEEP-VERIFY/EXTEND（2026-09-16 已完成）

复验中发现并修复 3 处真实缺陷：搜索完全绕过 Block（INV-004「搜索不可见」整体失效）、 详情页对双向拉黑者仍可见、matches.source 取值越界（实测 Mapper 传 "liked"，违反 V003 的 chk_match_source， 仅在 H2 测试库无该约束时才静默通过）。详见 docs/Phase-08-V11-Recovery-Completion-Report-2026-09-16.md。

Files: relationship 模块、discover/relationship 页面和对应测试。

• 验证 Like、Pass、普通 Mutual、Unmatch、Block 全链路。
• 增加 Activity Match Episode 兼容，不改变普通 Match 的双向 Like 规则。
• 验证 Block 后推荐排除、搜索不可见、聊天停止且无法由缓存绕过。

Gate: V1.0 核心回归通过；活动来源兼容不会创建第二套 Match 逻辑。

Phase 09：Text Chat — KEEP-VERIFY/EXTEND（2026-09-16 已完成）

复验中发现并修复 4 处真实缺陷：① WebSocket 下行整条链路是死代码（无握手鉴权、无 userId 写入、 sendToUser 零调用点）；② Unmatch 只改 Match 不联动会话，且发消息只校验会话状态 → 解除匹配后仍可发消息； ③ RelationService.block 调用静态 MatchService.unmatch（只改内存态）→ Block 后 Match 未落库； ④ 聊天四个读/写接口无会话成员校验 → 任意登录用户可读他人私聊（IDOR）。 详见 docs/Phase-09-V11-Recovery-Completion-Report-2026-09-16.md。

Files: messaging/**、WebSocket 配置、Miniapp messages/chat 页面。

• 验证 REST send + WebSocket receive、消息幂等、重连和未读计数。
• 验证非 active Match 禁聊，Unmatch/Block 后即时禁聊。
• 让活动双确认产生的 Conversation 复用同一消息体系。

Gate: 未 Mutual 或活动未双确认时不能发消息；正常会话不重复投递。

Phase 10：Image & Chat Safety — KEEP-VERIFY

Files: photo 模块、message safety、对象存储配置和聊天页面。

• 验证图片私有访问、类型/大小校验、审核和水印。
• 验证风险识别、举报入口和违规内容处理。
• 检查日志不记录聊天正文、身份证、手机号或签名 URL。

Gate: 越权图片访问被拒绝，敏感内容不进入普通日志。 （2026-09-16 复验通过：修复 D1 图片上传魔数校验死代码——本地资格佐证上传曾 100% 失败；D2 高风险词写入普通日志。水印未实现，登记 gap。）

Phase 11：Notification — EXTEND

Files: notification/**、预约/咨询/资格/活动服务及通知页面。

• 新增预约、咨询、辅导、本地资格和活动双确认通知。
• 统一在业务事务提交后发送，发送失败不回滚核心事实。
• 锁屏和通知摘要使用隐私安全文案，不泄露咨询主题或单向意向。

Gate: 回滚事务不发通知；已提交事务通知失败可重试且不产生重复业务记录。 （2026-09-16 复验：修复 D3——10 种通知 type 违反生产 CHECK 约束致全部落库失败；D1——补通知幂等唯一索引 V036；D2——接线婚前辅导及管理端排期通知。sendExternal 在事务内执行的缺口已登记，接入真实微信 API 前须 改为提交后发送。真机文案 INV-010 达标。）

Phase 12：Relationship Progress — KEEP-VERIFY/EXTEND

Files: relationship 状态服务、Match Episode、relationship-status 页面。

• 验证成功关系双确认、恢复/退出、历史 Episode 和并发确认。
• 补充 getting_to_know 阶段的婚前辅导入口引导。
• 验证工作人员不能替用户确认成功关系。

Gate: 单方确认不改变最终关系；历史 Episode 可追踪但不会恢复旧聊天权限。 （2026-09-16 复验：修复 D1——实体与生产迁移系统性漂移，23 表 50 列缺失，其中 matches.episode 等 11 张表属"INSERT 必崩"级生产故障，真实 PG 上 Match 创建 / 偏好保存 / 权限写入等全部失败； D2——RelationshipService.createMatch 不写 episode/lastActivityAt，与 MatchService 双路径字段不一致， 且 episode 为 null 时 getEpisode() + 1 自动拆箱 NPE；D3——测试库缺 user_identities 等 7 张表， 致 GET /home 在测试环境直接 BadSqlGrammar，首页零回归覆盖；D4——Phase 12 计划项 2 实际未实现 （getting_to_know 只给 counseling，无婚前辅导入口）。新增 EntityMigrationParityTest 把 「实体字段 ⊆ 生产迁移列」「测试库覆盖关键表」固化为自动守卫，并经负向验证证明会变红。 真机行为：双确认/并发确认/历史 Episode 不恢复旧聊天/非成员不可代确认 —— 14 项全绿。）

Phase 13：公益红娘转介 — EXTEND

Files: matchmaker/**、referral/**、Miniapp 红娘页面、Admin referral 页面。

• 保留红娘服务和人工推荐；验证任何工作人员不能替用户 Like。
• 补齐转介咨询、活动、服务站的用户同意、来源追踪和状态记录。
• 红娘只能看转介状态和必要摘要，不能读取 counseling followup 正文。

Gate: 转介形成可追踪记录但不越权；用户决定权测试通过。

2026-09-16 复验结论（KEEP-VERIFY/EXTEND）：历史 ✅ 不可信。全仓库唯一的"INV-005 红娘不可代用户操作" 证据是 MatchmakerServiceTest#testMatchmakerCannotLike 的 assertTrue(true) 占位，以及 CoreInvariantsTest#testMatchmakerCannotLike（断言的是 MATCHMAKER_STATUS_* 状态常量字符串， 与 Like 无关）—— 两者均为名不副实的假测试；且测试库 schema-h2.sql 完全缺失 matchmaker_* 三表， 该模块零真实行为覆盖。逐条核对运行时路径后修复 7 处缺陷：

• D1（Critical，生产故障） matchmaker_recommendations.status：代码写 liked/passed/confirmed_mutual，而 V009 chk_rec_status 只允许 pending_view/viewed/responded，且从未被后续迁移扩展 → 真实 PostgreSQL 上 用户"接受/跳过"红娘推荐必然 500，P13 主流程不可用。
• D2（Critical，生产故障） MatchmakerController.submit 在请求未带 serviceType 时兜底写 "recommendation"，而 V009 chk_matchmaker_service_type 白名单只含 recommend_partner 等 7 个值 → 真实 PG 上提交红娘服务必然 500。（MatchmakerService 注释声明的 referral_counseling/referral_activity/referral_station 同样越界。）
• D3（High） MatchmakerServiceService.recommendPartner 缺 assigned_operator_id 归属校验 → 任何持 matchmaker.service 权限的 operator 可对任意 serviceId 创建推荐（越权）。
• D4（High） getServiceDetail 无任何归属校验，任何 matchmaker.view 持有者可读任意服务的 完整用户资料（displayName/gender/age/region/education/occupation/maritalStatus）→ 越权读。
• D5（High） ReferralService.referToActivity / referToServiceStation 的 userId 直接取自 请求体且无任何授权校验（连 MatchmakerServiceMapper 都没注入）→ 任意红娘可把任意用户 转介到任意活动/服务站，并顺带为该用户创建报名/预约（越权代操作）。
• D6（High，生产故障） MatchmakerFollowupMapper.findByServiceId 只有方法声明、没有 @Select → MyBatis 运行时抛 Invalid bound statement (not found)，getServiceDetail 必然 500， 红娘工作台"查看服务详情"完全不可用。此前不可见：测试库缺 matchmaker_followups 表。
• D7（Medium） Admin referral 页面契约缺口：/referrals/my-history（C 端 UserPrincipal 端点） 被运营端调用；/matchmaker/services/operator/queue、/matchmaker/recommendations/operator、 PUT /matchmaker/services/{id}/assign、POST /matchmaker/services/{id}/recommendation 四条路径在后端均不存在（404）。 修复：新增 V038__align_matchmaker_status_constraints.sql（沿用 V018/V020/V025 的 DROP CONSTRAINT IF EXISTS + 重加白名单惯例）；测试库补 matchmaker_* 三表（约束对齐 V038）； D3/D4/D5 补归属校验与转介授权；D6 补 @Select；D7 补两个运营端端点并修正前端调用。 新增守卫 MatchmakerReferralPhase13Test（17 用例，走真实服务方法 + 真实落库）替换假测试； MatchmakerServiceTest 重写为直接解析迁移 SQL 的口径守卫（第一轮负向验证暴露"抄副本"守卫 对漂移无反应，已修正）；CoreInvariantsTest 的 INV-007/INV-010 假断言已如实改名并指向真实验证。 两轮负向验证：注入 D1（回退 chk_rec_status 白名单）→ 行为守卫抛 DataIntegrityViolation、 常量守卫报 3 处 failure，守卫有效性得证。

全量回归实测：[WARNING] Tests run: 391, Failures: 0, Errors: 0, Skipped: 3 / BUILD SUCCESS（4 分 59 秒）。 Phase 12 基线 371 → 391（净 +20）。Phase 13 已关闭。Phase 13A 未自动进入，等待用户确认。 报告：docs/Phase-13-V11-Recovery-Completion-Report-2026-09-16.md

Phase 13A：婚恋咨询与婚前辅导 — REFACTOR/EXTEND

Files: counseling/**、miniapp/pages/counseling-*、miniapp/pages/my-counseling/**、miniapp/pages/premarital-*、admin-web/src/modules/counseling/CounselingView.vue、router。

• 修复 Admin Vue 语法错误并注册 /counseling 路由，先使 type-check 失败转为通过。
• 用户申请接口从认证主体取 userId；补幂等、取消、详情 owner 校验和合法状态迁移。
• 分配操作使用条件更新/版本号解决并发；Counselor 只能读取和操作 Assigned Service。
• Counseling Manager 可分配和查看必要摘要；普通管理员、红娘、内容编辑不得读取咨询正文。
• 婚前辅导复用 counseling service type；邀请平台内伴侣必须由对方自主确认。
• U55～U59 修复类型错误、API 契约、Loading/Empty/Error/Permission 状态和非医疗化文案。

Gate: 申请→分配→预约→服务→完成→反馈真实闭环通过；所有隐私负向用例通过。

复验完成（2026-09-17） — Tag：phase13a-recovery-2026-09-17

复验发现 counseling 模块存在双实现：线上权威 CounselingService（167 行） 零测试，唯一被测的 CounselingServiceApp（280 行）是孤儿类 （无注入点、无端点可达，生产永不执行）。已合并并删除孤儿类。

9 处缺陷（D1~D9）：

• D1 Critical 生产故障 / INV-013 泄露：咨询正文原文被写入 WARN 日志（同 Phase 10 D2 一族）。
• D2 High 越权：申请 userId 取自请求体而非认证主体。
• D3 High 并发：分配「先读后写」→ 并发静默覆盖；改 assignIfPending 条件更新。
• D4 High 越权读：manager 经 getDetail 可读 followups 正文（INV-013 绕过通道）。
• D5 Medium：无状态机 → 「已完成」可被再取消。
• D6 Medium 生产故障：GET /services/intro 后端不存在，小程序 intro 页 100% 无数据 （且被 /services/{id} 吞掉）→ 已补端点并置于变量路径之前。
• D7 Medium：Admin 调用 5 条不存在的运营端端点（404）+ 缺四态。
• D8 Medium：小程序字段名不匹配 + 无幂等 + 未检查 success（403 静默空列表）+ 跳转不存在的页。
• D9 Medium 测试保真度：测试库 counseling 两表零 CHECK 约束，counseling_services 零覆盖。

另修 4 处测试基建缺陷（T1~T4）：守卫因 surefire workingDirectory 指向仓库根而 找不到 DDL（恒真假绿）；全限定 @TableField(exist=false) 漏解析（假警报）； 权限守卫扫到私有辅助方法（假阳性）；两处测试自身逻辑缺陷。

负向验证两轮：① DDL 常量守卫 —— 从 V039 移除 scheduled → 守卫精准变红 （证明解析的是真实 DDL 而非副本）；② 行为守卫 —— 注入并发/INV-013/状态机 三个缺陷 → 三个用例精准变红。均已还原。

全量回归实测：[WARNING] Tests run: 420, Failures: 0, Errors: 0, Skipped: 3 / BUILD SUCCESS（4 分 49 秒）。Phase 13 基线 391 → 420（净 +29）。 Phase 13A 已关闭。Phase 14 未自动进入，等待用户确认。 报告：docs/Phase-13A-V11-Recovery-Completion-Report-2026-09-17.md

Phase 14：多类型公益活动 — REFACTOR/EXTEND

Files: activity 模块、Miniapp activity 页面、Admin activity 页面。

• 保留活动基础，完成 ActivityType 分类、按类型报名策略、capacity groups 和多组织关系。
• 完成小程序分类 Tabs、类型化卡片、动态资格提示和后台动态表单。
• 验证主办组织关系不自动授予用户库访问权限。

Gate: matchmaking 与课堂/反诈类活动显示和资格策略不同；容量按配置正确扣减。

复验完成（2026-09-17） — Tag：phase14-recovery-2026-09-17

11 处后端缺陷（D1~D11）：

• D1 Critical 生产故障：ActivityMapper.countRemainingCapacity 无 @Select 无 XML → 活动详情/报名/审核三条路径必抛 Invalid bound statement。
• D2 Critical 并发：报名与审核均为「先读后写」→ 并发超卖；改 insertIfCapacityAvailable / approveIfCapacityAvailable 单条原子 SQL。
• D3 High 生产故障：activityType / orgRole 未校验生产 chk_activity_type / chk_org_role 白名单（"只在 PG 上炸"）。
• D4 High 契约：ActivityListItemDTO 无 activityType → 小程序分类 Tabs 恒无数据。
• D5 Medium：男女人数为 approvedCount/2 编造 → 改按 user_profiles.gender 真实统计。
• D6 Medium：年龄门槛为 TODO 空壳，完全不生效。
• D7 Medium：registration_policy 只写不读，按类型资格策略为空（Gate 未落地）。
• D8 Medium：POST /operator/activities 丢弃类型/多组织/容量分组，且把 organizer_org_id 错设为操作者 userId → 后台动态表单无法创建带类型活动。
• D9 Medium：三个运营写入端点错挂在用户端 ActivityController（双实现、零调用方）。
• D10 Medium NPE：软删活动致 getMyActivities NPE；后台漏填字段致创建活动 500。
• D11 Medium 契约：DTO 缺 registeredCount/status/coverFileId/description → 卡片报名人数恒 0、按钮恒"查看详情"、封面与摘要恒不显示。

3 处前端契约缺陷（F1~F3）：小程序分类 code classroom 不在生产白名单 （应为 relationship_education）且缺三类入口；卡片读取 7 个后端根本不存在的字段； admin-web 完全没有活动管理页（已新增 ActivityManagementView.vue 类型驱动动态表单）。

2 处测试保真度缺陷（T1~T2）：testNoOverbooking / testNoDuplicateRegistration 为 assertTrue(true) 占位假绿（已删除）； 测试库缺 V023 列与三张表，且 activity 五表在 EntityMigrationParityTest 只属"可选白名单"（零覆盖）→ 已补齐并移入必选集合。

负向验证两轮：① 后端 —— 从 V023 删 anti_fraud + 报名退化为无容量检查 → 3 条用例精准变红；② 前端契约 —— 分类 code 改回 classroom + 卡片加回 activity.suitableFor → 3 条守卫精准变红。均已还原。

全量回归实测：[WARNING] Tests run: 450, Failures: 0, Errors: 0, Skipped: 3 / BUILD SUCCESS（4 分 52 秒）。Phase 13A 基线 420 → 450（净 +30）。 admin-web vue-tsc --noEmit 0 error、vite build 通过。 Phase 14 已关闭。Phase 15 未自动进入，等待用户确认。 报告：docs/Phase-14-V11-Recovery-Completion-Report-2026-09-17.md

Phase 15：活动报名、审核与签到 — KEEP-VERIFY/EXTEND

Files: activity registration、checkin 服务和 U29～U32 页面。

• 回归报名、审核、取消、签到码、重复签到和名额并发。
• 增加非 matchmaking 活动和 capacity group 场景测试。
• 服务站操作员只能操作指定活动或站点任务。

Gate: 重复请求和并发报名不超额；签到不可跨活动复用。

2026-09-17 复验关闭：修复 16 处缺陷（8 处签到 + 5 处报名/审核/取消 + 1 处容量分组 + 2 处前端契约）

• 3 处测试保真度缺陷。两处必崩：D1 签到码一生成即作废（generateCheckinToken 写 "used"， 扫码 100% 失败）、D9 取消后永远无法再报名（撞生产 UNIQUE(activity_id,user_id)， 测试库缺该约束故零覆盖）。新增 V040 activity_staff_assignments 落实签到数据范围（INV-020）。 一轮负向验证：3 处注入 → 8 条用例精准变红并还原。全量回归 474 tests 全绿（基线 450）。 报告：docs/Phase-15-V11-Recovery-Completion-Report-2026-09-17.md Phase 16 未自动进入，等待用户确认。

Phase 16：活动互选与双方开启沟通确认 — REFACTOR ✅ 已完成（2026-09-17 KEEP-VERIFY/EXTEND 复验关闭）

Files: activity_mutual、relationship、messaging 模块及 activity-mutual 页面。

• 以 activity_mutual_connection_consents 为唯一逻辑，双实现统一到 RelationshipService.confirmActivityInterest。
• 双方确认事务中：已有 active Match 则复用已有会话；历史 Unmatch 则复用同一行（episode 递增 + reopen）；无历史则创建 Match 和 Conversation。
• 补 decline、expires_at 超时、重复确认幂等、并发确认（exactly-once）和单向意向保密（INV-006）测试。

Gate: A 单选 B 时 B 无感知；Mutual 但未双确认时无新 Chat；双确认后 exactly-once 形成正确 Match/Conversation。

2026-09-17 复验结论（KEEP-VERIFY/EXTEND）： 历史 ✅ 不可信，逐条核对运行时路径后发现活动互选核心 Gate 缺陷—— 新路径 ActivityMutualConsentController.confirmConnection 双确认后根本不建 Match/会话（违反 INV-014/015），而旧路径 ActivityInterest.confirmInterest→confirmActivityInterest 建 Match 却缺会话；两条路径分裂。已统一到 RelationshipService.confirmActivityInterest 单实现。修复 7 处缺陷 + 1 处隐藏编译缺陷 + 1 处测试保真度缺陷：

• D1（Critical，Gate 缺陷 · INV-014/015） 双确认后不建 Match/会话 → 重写为 confirmConnection 走 confirmActivityInterest，由原子 confirmSideIfPending 保证 exactly-once（both_confirmed_at NULL→非NULL 仅一方赢家建 Match+会话并 bindMatch 溯源）；单方确认不建 Match。
• D2（High，双实现分裂） 旧/新路径各自为政 → 统一到 RelationshipService.confirmActivityInterest（返回 matchId + priorUnmatch）。
• D3（High，隐藏编译缺陷 · 必崩级） Phase 15 提交态引用 matchMapper.reopenEpisode 但该方法从未定义 → 整个 activity_mutual / relationship 模块根本不编译，"474 绿"基线从未真实存在。修复：在 MatchMapper 补 @Update reopenEpisode （WHERE status='unmatched' AND deleted_at IS NULL）。这是本轮最严重发现：Phase 15 的提交态从未通过编译。
• D4（High，INV-006 泄露） getMyConsentStatus 本侧未确认即回显对方确认状态 → 改为 partnerAccepted = myAccepted && partnerSideAccepted（本侧未确认则对方确认态不回显）。
• D5（Medium，缺会话） 复用/新建 Match 后未显式开启会话 → confirmActivityInterest 现在显式调用 chatService.getOrCreateConversation 并返回 conversationAutoCreated=true。
• D6（Medium，测试库零覆盖） schema-h2.sql 缺 activity_mutual_connection_consents 表 → 补表 （含 deleted_at/expires_at/match_id 与 chk_consent_status CHECK、UNIQUE(activity_id,user_a_id,user_b_id)），与 V024+V037+V041 对齐； EntityMigrationParityTest 将其从 TEST_SCHEMA_OPTIONAL_TABLES 移入 REQUIRED_IN_TEST_SCHEMA；MigrationValidationTest 基线 40 → 41。
• D7（Medium，无互选测试） 新建 ActivityMutualConsentServiceTest（7 用例：双确认建 Match+会话+溯源、INV-006 单向不暴露、 decline 阻止、幂等重确认不重复建、expires_at 超时拒绝、软删过滤、复用 active Match），@SpringBootTest 走真实方法路径。
• D8（Medium，断言与 #20 冲突） ChatPhase09IntegrationTest:344 假设"每次活动互选新建独立会话"，与 AGENTS.md #20 "同对用户 Unmatch 后重连复用同一 Match 行、会话随之复用"冲突 → 改为 assertEquals（认可复用），保留 sendText/WebSocket/未读主断言以验证"复用同一消息管线"。
• 负向验证：临时注释 createMatchAndConversation(consent) 调用 → ActivityMutualConsentServiceTest 中 doubleConfirm + idempotent 两条依赖 Match 的用例精准变红（Tests run: 7, Failures: 2）→ 证明守卫有牙 → 已还原（grep -c "NEG-VAL" = 0）。
• 新增迁移 V041__extend_mutual_consent_expiry.sql（expires_at + match_id + 索引）。
• 全量回归 481 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS（约 5 分）。基线 474 → 481（净 +7）。
• 报告：docs/Phase-16-V11-Recovery-Completion-Report-2026-09-17.md。Phase 17 需用户确认后启动。

Phase 17：举报与风控 — EXTEND

Files: risk、report、referral 模块和后台风险页面。

• 将 counseling、service_station、offline_activity 作为风险来源接入统一 RiskEvent。
• 后台显示必要来源上下文但不暴露无关咨询正文。
• 禁止公开黑名单；举报、处置、Block 与敏感访问继续审计。

Gate: 风险来源可追踪、正文最小可见，低权限人员不能扩大读取范围。

Phase 18：申诉 — KEEP-VERIFY

Files: appeal 模块、Miniapp appeal 页面和后台 AppealCenter。

• 回归 ban/suspend 申诉、幂等处理、审批和解除动作。
• 验证申诉不能绕过仍有效的其他风险处置。
• 是否首发继续由已确认 Feature Flag 控制。

Gate: 申诉通过只解除目标处置；拒绝后原处置保持有效。

Phase 19：统一运营后台 + 用户端公益服务页面 — ADD/REFACTOR

Files: Admin banner/content/service-station/service-appointment/service-program/counseling/referral 模块、MainLayout/router；Miniapp 新增 U49～U54、U60、U61、U64 页面；service API 文件。

• 先修复 Admin 全量 type-check 和角色路由，再实现“角色第一屏知道今天做什么”的待办型工作台。
• Banner 完成 CRUD、排期、排序、Audience、内部 target 校验和预览；禁止外链。
• Content 完成分类、文章编辑、发布/下架；用户端只做文章列表/详情，不做 Feed、评论和点赞。
• Service Station 完成万善公园站信息、开放时间、公告、服务项目和预约管理。
• 修复预约 IDOR：普通用户创建、详情、列表、取消只能操作本人；代登记使用独立 operator 接口和权限。
• Service Program 完成项目、申请、审批、退出和必要统计，禁止把项目成员身份变成用户价值标签。
• 新增并注册 U49 公益服务中心、U50 服务站、U51 预约、U52 我的预约、U53 课堂、U54 内容详情、U60 反诈、U61 专项服务、U64 公益服务记录。
• 重构 U37“我的”四组结构，接入上述新增页面；U64 只显示用户自己的服务时间线，不显示内部备注。
• 所有页面复用统一 Token 和组件，覆盖 Loading、Skeleton、Empty、Error、Permission、Disabled、Responsive。

Gate: 小程序 U01～U64 页面清单无缺页且路由可达；七类后台角色只看到自己的工作；后台 type-check/build 通过。

Phase 20：公益服务 Analytics — EXTEND

Files: analytics 模块、统计查询/事实表后续迁移、Admin Analytics 页面、docs/ANALYTICS_METRICS.md。

• 为每个指标登记名称、定义、分子分母、去重键、时间字段、时区、版本和负责人。
• 分离服务用户数与服务人次、活动 mutual/confirmed/match/chat/success、Banner impression/click。
• 有效交友匹配在口径未确认前标为 provisional，不能当正式成功或对外宣传。
• 所有统计接口应用 analytics.view 和组织/站点 DataScope，低权限账号返回 403。

Gate: 用固定测试数据人工复算一致；相同用户多次服务不会污染去重人数。

Phase 21：账户生命周期 — EXTEND

Files: account/service/AccountLifecycleService.java、预约/咨询/项目/资格服务、数据保留文档。

• 注销前检查进行中的预约、咨询、项目和本地资格审核。
• 注销事务关闭未来服务、退出项目、失效本地资格并匿名化允许保留的服务历史。
• 数据保留期限未确认的敏感材料采用配置和人工审核，不擅自永久保存或删除。

Gate: 注销后不能登录/推荐/聊天；统计留痕不反向暴露个人和咨询正文。

Phase 22：Deployment / Ops — EXTEND

Files: Dockerfiles、infrastructure/docker-compose*.yml、Nginx、backup/restore/deploy/gray-release scripts、OPS/DEPENDENCIES 文档。

• 删除 Backend 镜像跳过测试的发布路径；CI 构建必须先测试再打包。
• 生产关闭 Mock WeChat、默认密码、Debug、Swagger 和演示 Seed；Secret 全部由环境变量/Secret 文件注入。
• 建立 /api/v1、WebSocket、私有对象、6688 端口检测及国内依赖镜像说明。
• 备份加密并存放独立位置，执行一次 PostgreSQL + 对象存储实际恢复演练。
• Rollback 明确回到哪个稳定镜像/版本；Flyway 只向前修复，不破坏 V001～V027。

Gate: staging 部署、健康检查、恢复演练和版本回滚都有命令、日志与结果证据。

Phase 23：可信系统测试重建 — REFACTOR

Files: backend/src/test/**、tests/e2e/**、tests/invariants/**、测试 fixture/seed、CI scripts。

• 删除测试体中的空 pass，建立可隔离的用户、角色、组织、活动、咨询和预约 fixture。
• INV-001～020 必须测试真实服务行为，不能只断言常量字符串存在。
• E2E 覆盖首页聚合、Banner、资格、咨询、预约、内容、多类型活动、二阶段同意、组织隔离。
• 增加 appointment owner、Counselor Assigned、ContentEditor zero-user-data、station scope 等负向安全测试。
• CI 串联迁移、backend test、admin type-check/build、miniapp type-check 和 E2E，任何失败阻断发布。

Gate: 不允许 skip/pass 空壳；报告列出总数、通过、失败、跳过及原因，失败为零才进入 UAT。

Phase 24：UAT — EXTEND

• 按用户、Reviewer、Matchmaker、Counselor、Counseling Manager、Service Station Operator、Content Editor、Activity Manager、Risk Operator 分角色验收。
• 验收线上主路径、线下扫码路径、咨询路径、辅导路径、服务站路径、活动二阶段确认和反诈举报路径。
• UI 按 375px 小程序基准和 1440px 后台基准检查，并覆盖弱网、空态、错误态、权限态。

Gate: 所有 P0/P1 客户场景有签字结果；阻断缺陷为零。

Phase 25：RC — EXTEND

• 只使用客户确认的真实 Banner、站点、咨询、课堂、反诈、关于我们和组织信息；不 Seed 假用户/假 Match。
• 完成隐私政策、用户协议、敏感文案和“非官方婚姻状态核验”提示审核。
• 冻结 RC 镜像、数据库版本、配置清单、第三方依赖和回滚目标。

Gate: Go/No-Go 清单通过；所有未决事项有明确 Flag/配置行为和责任人。

Phase 26：Production — EXTEND

• 上线前备份，执行 V027 及后续向前迁移，验证角色权限和真实基础内容。
• 依次执行 Home、Quick Entries、Service Station、Counseling、Content、Activity Mutual、Chat、Block smoke。
• 首日监控错误率、延迟、登录、推荐、消息、预约、咨询和权限拒绝；异常按已验证 Rollback 操作。

Gate: 生产 smoke 全部通过且无数据泄露/权限越界；否则立即 NO-GO 或回滚。

五、第一轮执行范围

收到“开始修复”后，只执行 Phase 01：

1. 纠正文档状态与共同基线；
2. 建立三端可重复检查命令；
3. 明确 Git/版本基线；
4. 输出 Phase 01 Completion Report；
5. 停止并等待用户确认 Phase 02。

不得借 Phase 01 提前修改首页、咨询、活动或后台业务代码。

六、计划自检

• 客户修订范围：品牌、首页、Banner、8 入口、本地资格、服务站、预约、咨询、辅导、课堂、反诈、多类型活动、二阶段同意、专项服务、多组织、来源和 Analytics 均已映射。
• 页面范围：U01～U48 KEEP；U49～U64 按“已有修复/缺失新增”分别处理。
• 数据范围：V001～V027 保留，后续只向前迁移；身份、资格、咨询、预约和活动边界独立。
• 权限范围：RBAC、DataScope、Sensitive Permission、Audit 和客户端 Capability 分层明确。
• 发布范围：测试、UAT、真实内容、Secret、备份恢复、Rollback、Production Smoke 均有 Gate。
• 禁止范围：未加入微服务、独立 CMS/咨询服务、社区 Feed、支付、AI 代聊或其他 V1.1 外功能。