admin/danyang-match
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
81 Commits 2 Branches 8 Tags
755a570849b316fc57c54988b595b5b3e9efeca1
Commit Graph
8 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
WorkBuddy 755a570849 fix(activity): close Phase 14 KEEP-VERIFY/EXTEND — 11 backend + 3 frontend-contract + 2 test-fidelity defects 
Phase 14 (multi-type public-welfare activities) verification closure.

Backend (D1-D11):
- D1 CRITICAL: ActivityMapper.countRemainingCapacity had no @Select and no XML
  -> activity detail / register / approve all threw Invalid bound statement.
  Removed the shell; unified on ActivityRegistrationMapper.
- D2 CRITICAL: register & approve were read-then-write -> oversold under
  concurrency. Replaced with single atomic SQL (insertIfCapacityAvailable /
  approveIfCapacityAvailable, affectedRows==0 => full).
- D3 HIGH: activityType / orgRole never validated against production
  chk_activity_type / chk_org_role -> 500 only on PostgreSQL.
- D4 HIGH: ActivityListItemDTO had no activityType -> miniapp category tabs
  always empty (Gate failure).
- D5: male/female counts were fabricated as approvedCount/2; now real
  aggregation over user_profiles.gender.
- D6: minAge/maxAge was a TODO no-op; added assertAgeInRange.
- D7: registration_policy write-only; per-type eligibility now enforced
  (identity / local eligibility / gender quota).
- D8: POST /operator/activities dropped type, multi-org and capacity groups
  and set organizer_org_id to the operator user id; now delegates to
  createActivityFromAdmin (single implementation).
- D9: three operator write endpoints were mounted on the user-side
  ActivityController (dual implementation, zero callers) -> moved.
- D10: NPE on soft-deleted activity in getMyActivities; NPE/500 on missing
  admin form fields (Instant.parse(null)); tolerant time parsing added.
- D11: DTO lacked registeredCount / status / coverFileId / description
  -> card always showed 0 registered, "view detail", no cover, no summary.

Frontend contract (F1-F3):
- F1: miniapp category code "classroom" is not in the production whitelist
  (should be relationship_education); three types had no tab at all.
- F2: ui-activity-card read 7 fields that do not exist on the backend;
  now reads only real DTO fields, plus per-type badge and eligibility hint.
- F3: admin-web had no activity management page at all; added
  ActivityManagementView.vue (type-driven dynamic form, multi-org,
  capacity groups, publish/cancel) + /activities route and nav entry.

Test fidelity (T1-T2):
- T1: deleted two assertTrue(true) placeholder tests (testNoOverbooking,
  testNoDuplicateRegistration) that covered the exact broken invariants.
- T2: test schema lacked V023 columns/constraints and three tables; the
  activity tables were only in the OPTIONAL set (zero coverage) -> schema
  completed and moved to REQUIRED_IN_TEST_SCHEMA.

Tests: ActivityPhase14Test (23 cases), ActivityConstraintGuardTest (9 cases,
parses real db/migration/V*.sql plus miniapp source). Two negative-verification
rounds proved both guard families actually turn red.

Regression: 450 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS
(baseline 420). admin-web vue-tsc 0 error, vite build OK.
 2026-09-17 14:02:00 +08:00
WorkBuddy 7a2693b239 fix(counseling): close Phase 13A KEEP-VERIFY/EXTEND — 9 real defects + 4 test-infra defects 
Phase 13A（婚恋咨询与婚前辅导）复验关闭。历史 ✅ 不可信：counseling 模块存在双实现，
线上权威 CounselingService（167 行）零测试，唯一被测的 CounselingServiceApp（280 行）
是孤儿类（无注入点、无 HTTP 端点可达，生产永不执行）→ 已合并并删除。

生产缺陷（D1~D9）：
- D1 Critical 生产故障 · INV-013 泄露：咨询正文 userRequestSummary 原文被写入 WARN 日志
  （同 Phase 10 D2 一族）→ 改为只记 serviceId + riskLevel，绝不记正文。
- D2 High 越权：申请 userId 取自请求体而非认证主体 → Controller 强制 principal.id()。
- D3 High 并发：分配用「先读后写」→ 两管理员并发分配静默覆盖；
  改 assignIfPending 条件更新（WHERE status='pending' AND assigned_operator_id IS NULL），
  affectedRows=0 明确报错。
- D4 High 越权读：counseling_manager 经 getDetail 可读 followups 正文 → INV-013 绕过通道；
  manager 只加回 userRequestSummary，不装配 followups。
- D5 Medium：无状态机 → 「已完成」可被再取消；新增 ALLOWED_TRANSITIONS + assertTransition。
- D6 Medium 生产故障：GET /counseling/services/intro 后端不存在（且被 /services/{id} 吞掉）
  → 小程序 intro 页 100% 无数据；补端点并声明在变量路径之前。
- D7 Medium 契约：Admin 调用 5 条不存在的 /services/operator/*（404）+ 缺四态
  → 后端补 8 个运营端端点（@PreAuthorize），前端整体重写 + 注册 /counseling 路由。
- D8 Medium 契约：小程序字段名错（userRequestSummary/preferredServiceMode）+ 无幂等
  + my-counseling 未检查 success（403 静默空列表）+ 跳转不存在的页 + WXML 内调用方法。
- D9 Medium 测试保真度：测试库 counseling 两表零 CHECK 约束，
  counseling_services 未列入 EntityMigrationParityTest 任何集合（= 零覆盖）。

测试基建缺陷（T1~T4，不修即恒真假绿）：
- T1 守卫找不到 DDL：surefire workingDirectory = ${project.basedir}/.. 使 CWD 为仓库根，
  且 backend/ 是子目录非祖先 → 改为候选后缀 + 逐级向上定位，失败大声抛异常。
- T2 全限定 @com.baomidou...TableField(exist=false) 漏解析（假漂移警报）→ 正则放宽 + 回归守卫。
- T3 OperatorEndpointPermissionCoverageTest 扫到私有辅助方法（假阳性）→ 只扫描真实端点 + 自检。
- T4 两处测试自身逻辑缺陷：陈旧内存快照比较、Instant 纳秒 vs DB 微秒精度。

迁移：新增 V039（counseling 幂等键 + 三个 CHECK 白名单显式固化），基线 38 → 39。

负向验证两轮（均已还原，grep -c NEG-VAL = 0）：
- ① DDL 常量守卫：从 V039 移除 'scheduled' → 常量守卫精准变红
  （证明解析的是真实 DDL 而非副本）。
- ② 行为守卫：注入「并发回退先读后写 / manager 读 followups / 状态机守卫失效」
  → 三个用例各自精准变红。

测试：新增 CounselingPhase13ATest（25）+ CounselingConstraintGuardTest（5，解析真实 DDL）；
删除孤儿类及其 3 个 DTO、删除测死代码的 CounselingDataScopeTest。
全量回归：Tests run: 420, Failures: 0, Errors: 0, Skipped: 3 / BUILD SUCCESS（4:49）。
基线 391 → 420（净 +29）。admin-web vue-tsc EXIT=0；miniapp tsc EXIT=0。

Tag: phase13a-recovery-2026-09-17
Report: docs/Phase-13A-V11-Recovery-Completion-Report-2026-09-17.md
 2026-09-17 01:25:12 +08:00
WorkBuddy 5b3bad326e fix(matchmaker,referral): close Phase 13 KEEP-VERIFY/EXTEND — 7 real defects 
KEEP-VERIFY/EXTEND 复验（历史 ✅ 不可信；测试覆盖函数 ≠ 覆盖运行时路径）。
逐条核对运行时路径与生产约束后修复 7 处缺陷，其中 3 处「只在真实 PostgreSQL 上炸」。

D1 (Critical, 生产故障)
  matchmaker_recommendations.status 代码写 liked/passed/confirmed_mutual，
  而 V009 chk_rec_status 只允许 pending_view/viewed/responded 且从未扩展
  → 真实 PG 上用户接受/跳过推荐必崩。测试库未复刻该 CHECK，故长期静默。

D2 (Critical, 生产故障)
  控制器缺省 serviceType="recommendation" 不在 chk_matchmaker_service_type
  白名单 → 提交红娘服务必崩。
  D1+D2 同修于新增 V038__align_matchmaker_status_constraints.sql
  （沿用 V018/V020/V025 的 DROP CONSTRAINT IF EXISTS + 重加白名单惯例）。

D3 (High, 越权写)
  MatchmakerServiceService.recommendPartner 无 assignedOperatorId 归属校验，
  且可把用户推荐给自己 → 补校验 + 禁止自我推荐。

D4 (High, 越权读)
  getServiceDetail 无归属校验且返回完整用户资料（userId/description/
  userProfile/followups）→ 签名加 requesterId，按调用者返回完整/脱敏视图。

D5 (High, 越权写)
  ReferralService 的 userId 取自请求体且零授权校验 → 新增
  assertMatchmakerServesUser，在 referToServiceStation/referToActivity 入口
  强制校验存在进行中的服务关系。

D6 (High, 生产故障)
  MatchmakerFollowupMapper.findByServiceId 只有声明无 @Select
  → Invalid bound statement (not found)，getServiceDetail 必崩。
  该缺陷由本轮新增测试首次暴露（历史测试从未调用该路径）→ 补 @Select。

D7 (Medium, 契约缺口)
  admin-web 5 处 API 缺口（4 条 404 + C 端端点被运营端误用）+ 小程序缺转介服务层
  → 后端补 GET /operator/matchmaker/recommendations 与
  GET /referrals/operator/history 两个运营端端点；前端改路径、
  assign 改 POST + body operatorId；新增 miniapp/services/referralService.js。

测试保真度
  - 测试库补 matchmaker_services/recommendations/followups 三表（此前该模块零真实覆盖），
    约束与 V038 对齐；EntityMigrationParityTest 三表移入 REQUIRED_IN_TEST_SCHEMA；
    MigrationValidationTest LATEST_MIGRATION 37 → 38。
  - 新增 MatchmakerReferralPhase13Test（17 用例，@SpringBootTest 走真实方法路径 + 真实落库）。
  - 重写 MatchmakerServiceTest（6 用例）：直接解析 db/migration/V*.sql，按文件名顺序应用
    DROP CONSTRAINT IF EXISTS + ADD CONSTRAINT 取"最终有效"白名单，并内置解析器自检。
    【关键】首版守卫硬编码白名单副本，注入 D1 后仍全绿（对漂移零反应）→ 必须解析真实 DDL。
  - 删除 3 处假测试占位（MatchmakerServiceTest.testMatchmakerCannotLike 的 assertTrue(true)；
    CoreInvariantsTest INV-007 断言的是状态常量、INV-010 亦为 assertTrue(true)），
    已如实改名并注明行为验证位置。

负向验证（两轮）
  注入 D1（回退 chk_rec_status 白名单）→ 行为守卫 DataIntegrityViolation
  + 常量守卫 Multiple Failures (3 failures) → Tests run: 23, Failures: 1, Errors: 2
  / BUILD FAILURE，守卫有效性得证。缺陷已还原。

全量回归（离线容器，实测）
  [WARNING] Tests run: 391, Failures: 0, Errors: 0, Skipped: 3
  [INFO] BUILD SUCCESS / Total time: 04:59 min
  Phase 12 基线 371 → 391（净 +20）。

报告：docs/Phase-13-V11-Recovery-Completion-Report-2026-09-16.md
Phase 13A 未自动进入，等待用户确认。
 2026-09-17 00:01:53 +08:00
WorkBuddy c607e87b45 fix(relationship): Phase 12 复验 —— 修复实体↔生产迁移系统性漂移（生产故障族）/ 双路径 episode 与 NPE / 测试库缺表致首页零覆盖 / 计划项 2 未实现 
KEEP-VERIFY 复验发现并修复 4 处真实缺陷：
- D1（Critical，生产故障·同一族系统性缺陷）实体与 db/migration 系统性漂移：23 表 50 列在生产
  迁移中不存在，而测试库 schema-h2.sql 手写补齐 → 全量绿=假绿。其中 11 表属"INSERT 必崩"级
  （缺 id/created_at/updated_at，被 AutoFillHandler 强制填充），含 matches.episode、user_preferences
  权重列、permissions/roles、consent_records、risk_events 等；真实 PG 上 Match 创建、择偶偏好保存、
  权限/角色写入、同意记录、风险事件全部失败。修复：新增 V037（幂等 ADD COLUMN IF NOT EXISTS
  + 存量 episode 回填）。
- D2（High）RelationshipService.createMatch 不写 episode/lastActivityAt，与 MatchService 双路径
  填充不一致；且 episode 为 null 时 m.getEpisode()+1 对 Integer 自动拆箱抛 NPE。修复：统一按
  AGENTS.md #20 推导 + null 兜底。
- D3（High）测试库缺 user_identities 等 7 表 → GET /api/v1/home 在测试环境 BadSqlGrammar，
  首页接口零回归覆盖。修复：schema-h2.sql 补齐 7 表。
- D4（Medium）Phase 12 计划项 2 实际未实现：getting_to_know 分支只产出 counseling。修复：
  HomeApplicationService 补 premarital 引导（与 counseling 并列）。

测试保真度：
- 新增永久守卫 EntityMigrationParityTest（5 用例）：把"实体字段 ⊆ 生产迁移累积列"与"测试库覆盖
  关键业务表"固化为自动不变量，区分"必崩级/潜伏级"；经两轮负向验证证明会变红（第一轮分级过窄
  已修正：episode 由"潜伏级"纠正为"必崩级"）。
- 新增 RelationshipProgressPhase12Test（14 用例，含 8 线程并发确认）与
  HomePremaritalGuidancePhase12Test（5 用例）。
- 删除 2 个假测试类中的 assertTrue(true) 占位（AGENTS.md 明令禁止），改走真实服务方法验证。

Gate：单方确认不改变最终关系 ✅ / 双确认后才 successful ✅ / 历史 Episode 可追踪 ✅ /
新 Episode 不恢复旧聊天权限（conversations.match_id UNIQUE）✅ / 非成员不可代确认 ✅

全量回归：371 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS（71 类，5m07s）
 2026-09-16 23:01:13 +08:00
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
WorkBuddy fd7195ecb0 fix(safety): Phase 10 复验 —— 修复图片上传魔数校验死代码（生产故障）/ 高风险词写入日志 
对 Phase 10（Image & Chat Safety）执行 KEEP-VERIFY 复验：不采信历史 ✅，逐条核对
图片私有访问、类型/大小/魔数校验、审核与水印、风险识别/举报/违规处理、日志脱敏。
Gate 判定通过，发现并修复 2 处缺陷，并推翻旧报告 2 项安全声明。

D1（Critical，生产故障）图片上传的类型与魔数校验整条是死代码
  - PhotoService.uploadAndSave 用 `header = new byte[Math.min(12, stream.available())]`
    仅分配零值缓冲，从不调用 stream.read(...) → validateMagicNumber 对任何文件都收到
    12 个 0x00 → 恒返回 false → 恒抛"无效的图片文件头"。
  - 影响链（已确认线上触发）：小程序 local-eligibility-supplement.ts 以
    photoType='local_eligibility' 调 POST /photos/upload → 本地资格佐证上传 100% 失败。
  - 次生问题：isAllowedMimeType（image-only 白名单）在 local_eligibility 分支之后
    无条件执行，即使魔数修好，application/pdf 仍被挡，而 FeatureFlagConfig
    的 localEvidenceAllowedTypes 明确允许 pdf；另有未 mark 的 stream.reset() 无效调用。
  - 测试为何没发现：PhotoServiceTest 只对 validateMagicNumber 传手写字节做单测，
    从不经过 uploadAndSave，该路径缺陷完全无覆盖。
  - 修复：改用 try(InputStream){ header = s.readNBytes(12); } 真正读取；
    MIME 校验按 photoType 分流（local_eligibility 走自己的白名单含 pdf）；
    魔数校验仅对图片执行、PDF 跳过；移除死 reset()；上传用全新流与校验流隔离；
    generateFileKey 重载按 Content-Type 推断扩展名，PDF 不再拿到误导性 .jpg key。

D2（Low）高风险词写入普通日志
  - ChatSafetyService.scanContent 把命中的高风险词原样写入 log.warn，
    与同文件 CONTACT 分支"只记 pattern 不记内容"矛盾，且违反本阶段 Gate。
  - 修复：改为 log.warn("Chat content matched HIGH_RISK keyword (blocked)")。

推翻的旧声明（docs/Phase-10-Completion-Report.md）
  - 「伪装恶意图片被拒（Magic Number校验）」不成立：该校验运行时恒失败，
    连合法图片也一律被拒（fail-closed 到不可用），安全属性并非由它提供。
  - 「EXIF清理预留（PhotoService.stripExif占位）」不存在：全仓库无该符号。
    且 getUploadToken 客户端直传路径服务端无法介入清理 EXIF。
  - 已在旧报告顶部加状态注记，指向本次复验报告。

测试
  - 新增 PhotoUploadValidationTest（6 用例），用 MockMultipartFile 真正走一遍
    uploadAndSave：合法 JPEG/PNG 通过且确实调用 putObject、伪造 Content-Type 被魔数挡、
    PDF 佐证不被 image-only 挡且 key 以 .pdf 结尾、非法 MIME 被拒、超大被拒。
  - 负向验证：临时把魔数守卫改为 if(false && ...) → 恰好 spoofedContentTypeRejectedByMagic
    一个用例变红，其余 5 个仍绿；随后还原并 grep 确认无 NEGATIVE-CHECK-TEMP 残留。
  - 全量回归（离线容器 danyang-match-backend-test，mvn -o test）：
    334 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS（基线 328，+6）。

登记 gap（不自动实现，待产品确认）
  - 图片水印：全仓库无实现；主计划未列硬需求，仅"开发执行计划修订版"提"高级动态水印"。
  - EXIF 清理：旧声明不存在；客户端直传路径服务端无法介入，需改为接收侧重编码。
  - 直传凭证路径（getUploadToken）无服务端内容校验且不落 DB 记录 → 后续 getSignedUrl
    归属校验会查不到 UserPhoto 行，属契约层缺口，超出本阶段安全 Gate 范围。
  - 违规自动升级：ChatSafetyService 注释明确属 Phase 17 范围，当前 high 仅拦截不落库。

文档：新增 Phase-10-V11-Recovery-Completion-Report-2026-09-16.md；
旧报告加状态注记；主计划 Phase 10 复选框置 ✅；STATUS / JIRA_BACKLOG 同步（334 tests）。

Phase 11 未启动，按计划每阶段出报告后停止等待确认。
 2026-09-16 21:00:52 +08:00
WorkBuddy 03a03c7c11 fix(chat): Phase 09 复验 —— 修复 WebSocket 下行死链路 / Unmatch 后可发消息 / Block 未落库 / 聊天 IDOR 
对 Phase 09（Text Chat）执行 KEEP-VERIFY/EXTEND 复验：不采信历史 ✅，逐条核对
REST 发送 + WebSocket 接收、幂等、重连、未读计数、非 active Match 禁聊、Unmatch/
Block 即时禁聊、活动双确认会话复用。共发现并修复 4 处真实缺陷 + 1 处规范不符。

D1（Critical）WebSocket 下行整条链路是死代码
  - 无 HandshakeInterceptor，无任一环节把 userId 写入 session attributes，
    extractUserId 恒返回 null；sendToUser/sendToConversation 全仓库零调用点。
  - 新增 ChatHandshakeInterceptor：从 ?token= 或 Authorization: Bearer 解析 JWT，
    校验通过后写 session attr userId；失败 fail-closed 拒绝握手；仅接受 type=access。
  - 重写 ChatWebSocketHandler：按规范 {event,data} 信封推送；未认证连接直接
    close(NOT_ACCEPTABLE)；同账号重连由新连接接管、旧连接 close(NORMAL)；
    上行仅支持 ping->pong，禁止客户端自订阅。
  - ChatService.sendText 落库+递增未读后推送 message.new；RiskNotice 同推。
  - 移除 WebSocketConfig 的 .withSockJS()（SockJS 改写端点致原生 WS 无法直连）。

D2（Critical）Unmatch 后仍可发消息
  - unmatch 只改 Match，不联动会话；sendText 仅校验 conv.status==active。
  - 新增 ChatService.assertMatchAlive(conv)：按 matchId 查 Match，状态非
    {active,getting_to_know} 抛 "匹配已解除，无法发送消息"。sendText 在 conv.status
    校验之后调用。
  - MatchController.unmatch 落库后调 chatService.syncFromMatch 推 conversation.closed。
  - syncFromMatch 重写：alive 恢复 active；非 alive 只推 conversation.closed，
    不改 status（会话仍以灰显态留在列表，属未授权产品决策，登记待决）。

D3（Critical）RelationService.block 调静态 MatchService.unmatch 只改内存态不落库
  - 结果：Block 后 matches.status 仍为 active。
  - 补 matchMapper.updateById(m) 持久化 + chatService.closeConversationForMatch(
    CONVERSATION_STATUS_BLOCKED) 通知对端。RelationshipService.block 同步补会话关闭通知。

D4（Critical 安全）聊天 4 个接口无成员校验 -> IDOR 越权读私聊
  - MessageController.load/markRead、ConversationController.detail/unread 补
    chatService.isMember(conversationId, userId) 校验；非成员返回
    ApiResponse.notFound()（body 级 success=false code=NOT_FOUND，HTTP 200，
    与 MatchController.authorizedMatch 同约定），不区分"不存在"与"无权"以防探测。

D5（Medium）上行订阅/信封不符规范
  - REST API 接口详细设计规范.md 第124-126章要求禁止客户端自订阅，事件名
    message.new/message.read/conversation.closed，信封 {event,data}。已对齐。

测试保真度 + 测试补齐
  - schema-h2.sql 新增 uk_message_client_id(sender_id, client_message_id)，
    对齐生产 V004:71；H2 不支持过滤索引故省略 WHERE（NULL 语义等价）。
    否则 service 的 SELECT-then-INSERT 竞态在测试中无 DB 兜底，形成测试盲区。
  - 新增 ChatPhase09IntegrationTest（13 用例）：幂等重试不重复投递、推送信封字段、
    未读增减清零、Match unmatched 拒发、Unmatch/Block 端点即时禁聊+收 closed 事件、
    活动双确认复用同一消息体系、未形成 Match 无法建会话、非成员读消息/详情/未读
    被拒且不泄露正文、DB 唯一索引兜底重复 clientMessageId、无幂等键系统消息可共存。
  - 新增 ChatWebSocketHandlerTest（7 用例）：userId 路由、信封格式、未认证关连、
    断开不推、重连替换旧连接、上行仅 ping。

验证证据
  - 全量回归（离线容器 danyang-match-backend-test，mvn -o test）：
    328 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS（基线 308，+20）。
  - 负向验证：临时注释 assertMatchAlive + 两处 isMember，恰好 3 个用例变红，
    证明守卫有效；随后还原并 grep 确认无残留。

文档
  - 新增 Phase-09-V11-Recovery-Completion-Report-2026-09-16.md（完整报告）。
  - Phase-09-V11-Completion-Report.md 顶部加状态注记，推翻其 4 条 WebSocket 结论。
  - 计划/STATUS/JIRA_BACKLOG 同步 Phase 09 完成态与测试总数（328）。

Phase 10 未启动，按计划每阶段出报告后停止等待确认。
 2026-09-16 16:42:48 +08:00
WorkBuddy 4e478ce6ba fix(invariants): Phase 08 复验 —— 修复 INV-004 搜索/详情绕过 Block + matches.source 取值越界 
复验（KEEP-VERIFY）在既有 Phase 08 实现中发现 3 处真实缺陷并修复：

D1（严重）DiscoverService.searchUsers 不含查看者身份，查询条件既无排除自己也无任何 Block 条件，被拉黑者仍可被搜到并点开 —— INV-004「搜索不可见」整体失效。改为接收 viewerUserId，排除自己，并用新增的 UserRelationMapper.findBlockedUserIdsBothWays（UNION 双向）一次取回后 notIn 批量排除，避免 N+1。

D2 详情路径（DiscoverService / UserProfileService）均无 Block 判断，知道 userId 即可读到被拉黑者资料。两条路径统一加双向判断并返回 null，由 Controller 转 404（不用「已隐藏」以免被用来探测存在）；UserProfileService 中该判断排在隐私设置之前，拉黑不能被对方「允许搜索可见」覆盖。

D3（潜伏，仅 PostgreSQL 暴露）RelationshipService.like() 把关系类型值 "liked" 当 match source 写入 matches.source，违反 V003:91 的 chk_match_source。测试库 schema-h2.sql 该列是裸 VARCHAR(32)、无约束，故长期静默通过。改传 MATCH_SOURCE_USER_LIKE。canonical 路径 RelationService.like 传值本就正确，线上未触发。

测试保真度对齐：schema-h2.sql 补 chk_match_source（与 V003 逐字对齐）与 user_profiles 表（此前测试库无此表，资料查询无法端到端测试）。

新增 DiscoverBlockInvisibilityIntegrationTest（9 用例，@SpringBootTest 真实 H2 + 真实 SQL），覆盖正向/反向拉黑、对称性、排除自己、详情 404 与查自己不受限。P0FixVerificationTest 补 source 回归守卫。DiscoverServiceTest 同步构造签名。

负向验证：临时还原 D3 修复后，4 个用例因 CHK_MATCH_SOURCE 约束违反报错，证明守卫有效。

证据：后端全量 308 tests / 0 failures / 0 errors / 3 skipped（基线 299）；UI 契约 13/13 GREEN。报告 docs/Phase-08-V11-Recovery-Completion-Report-2026-09-16.md。

同步 STATUS.md / JIRA_BACKLOG.md（EPIC-P08-V11 置 ✅）/ 客户需求基线计划 Phase 08 复选框；首轮报告加状态注记（其「Known Issues 无」已被推翻）。.gitignore 忽略 .workbuddy/。
 2026-09-16 15:11:38 +08:00