admin/danyang-match
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
78 Commits 2 Branches 8 Tags
c607e87b45db43ed7ea11be6868ca84bdadea0ef
Commit Graph
14 Commits
Author SHA1 Message Date
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
Codex 6ae08b89fb docs(agents): 新增「版本控制约定」强制节 + 修正 UI 验收口径 
## 背景：refs/heads 嵌套分支名被实时清理，导致 HEAD 悬空

提交 bc4531a 后，refs/heads/codex/ui-v11-fidelity 被某个常驻监听进程删除（连 codex/ 目录一起），
HEAD 悬空 → `git log` 报 does not have any commits yet，`git status` 把全仓库文件标成新增。
`git update-ref` 重建返回退出码 0，但 0.2 秒内文件又消失（假成功）。

定向实验（14:06~14:10）定位的真实规则，与最初判断完全不同：

| ref 位置                        | 结果                     |
|---------------------------------|--------------------------|
| refs/heads/<单段名>             | 存活（连续观测 30s 稳定）|
| refs/heads/<任意>/<子名>        | 0.2s 内删除（连父目录）  |
| refs/tags/<任意深度>            | 存活                     |
| .git 下非 refs 的普通子目录     | 存活                     |

→ 删除器只针对 refs/heads 的子目录，且是事件驱动（0.2s），不是定时轮询（schtasks 无匹配项）。
→ 推论：标准 Git Flow 的 feature/ fix/ codex/ ui/ 前缀在本仓库全部不可用。

## 更正一处此前的错误结论

refs/codex/turn-diffs/checkpoints/... 是 09-11 / 09-14 的存量 ref，不代表有活跃 Codex 进程；
且仓库 git config user.name 本来就是 Codex，故 reflog 中所有条目都署名 Codex
（包括非 Codex 工具产生的提交）→ **reflog 署名不能用来判断是否存在并发进程**。

## 仓库处置

- HEAD 由悬空的 refs/heads/codex/ui-v11-fidelity 改为有效的 refs/heads/main
  （symbolic-ref + reset -q，仅同步索引，未触碰任何工作区文件）
- main 由 b8c33b9（09-11）快进至 bc4531a —— 纯快进：main 是 bc4531a 的严格祖先，
  `git rev-list --left-right --count main...bc4531a` = 0 58，无分叉、零冲突、零文件变化
- 保留顶层分支 feat-ui-v11 与 tag ui-v11-accepted-and-me-routes 作为冗余锚点

## AGENTS.md 变更

- 新增「版本控制约定（本机环境强制，务必先读）」一节：
  分支命名约束（禁用斜杠）、提交后自保清单（tag + bundle + 回读验证）、悬空 HEAD 的恢复方式
- 修正 UI 口径：首批范围（小程序 11 页 + 管理端框架/工作台）已于 2026-09-16 通过用户验收
  （基本达标），关闭「视觉否决 / REOPENED」判定；管理端桌面端目视复验仍待用户执行
- 头部日期更新为 2026-09-16

## STATUS.md

- 分支引用由已不存在的 codex/ui-v11-fidelity 改为 main

验证：UI 契约门禁 13/13；工作区 vs bc4531a 差异 0 行
 2026-09-16 14:31:26 +08:00
Codex bc4531a734 feat(api): 补齐 /me/* 命名空间，恢复 17 个 404 调用 + 修 /me/status 过期桩 
背景：小程序 services/*.js 按 REST 规范（§16 / §22-§40 / §80 / §83-§84）统一调用
/me/*，但后端从未注册 /me 基路径，个人资料、照片、择偶条件、隐私设置、关系状态、
我的举报/申诉等约 17 个调用全部 404。

后端
- 新增 me/controller/MeController：把既有 service 能力暴露到规范路径（纯委托，不复制
  业务规则，AGENTS.md #26）。旧路径（/profile/*、/photos、/relationship/*、
  /account/privacy-settings、/risk/reports/my、/appeals/my）全部保留。
- 响应形状按小程序 JSDoc 适配（小程序被 86 页引用，是权威契约）：
  · /me/relationship-status 返回 status（旧 /relationship/status 返回 relationshipStatus，
    字段名不同，前端读的是 result.status）
  · /me/profile/review-status 返回 {status, items, submittedAt, reviewedAt}，时间统一 epoch 毫秒
  · /me/profile/submit-review 返回 {reviewStatus, submittedAt}
- 小程序三条历史写法一并兼容：/me/privacy-settings、/me/photos/{id}/main、/me/appeals

修复
- AuthService.getMeStatus：verified / profileStatus / reviewStatus 三项写死为
  false / not_started / not_submitted，注释标注"Phase 03/04/05 填充"，但那三个 Phase
  早已交付，导致 /me/status 长期返回错误的实名与审核状态。改为 capabilityService
  + userProfileMapper + reviewTaskMapper 的真实来源（与首页聚合同一判定）。
- PhotoController.deletePhoto：原用 ((Map<?,?>) p).get("id") 强转 UserPhoto 实体，
  必然抛 ClassCastException，删除照片恒定 500。改用实体主键比对。
- PhotoService.setMainAvatar（新增）：数据模型以 photo_type='avatar' 标识头像（见
  UserPhotoMapper#findAvatar），无 is_main 字段，故"设主图"= 换类型并保证至多一张。
  注意：插入该方法时曾把 deletePhoto 原有的 @Transactional 挤到新方法上，导致
  "Transactional is not a repeatable annotation" 并引发 Lombok 全面停摆（满屏
  找不到 getter/setter），已修正注解归属。

验证
- 后端全量：299 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS（+2 为新增契约测试）
- 新增 MeRouteContractTest（2 例）：同时断言 HTTP 方法，锁定 21 条 /me/* 与 13 条旧路径
- 小程序 tsc --noEmit 通过；UI 契约门禁 13/13

文档
- STATUS.md：/me/* 从"待裁决"改为"已完成"；核心待清债务 1 项 → 0 项
- API_INVENTORY.md：顶部"待收敛"警告改为"已收敛"，补全 /me/* 端点表
 2026-09-16 12:54:39 +08:00
Codex 3244e02e7e refactor(api): 关系/匹配域采用 2026-09-14 canonical 路径，消除三代并存 
## 问题：同一能力存在三代路径，前端指向的是已废止的一代

按 mtime 排查后发现"最新"并非上一轮以为的 /relations/*，而是 2026-09-14 的 match 模块：

| 代际 | 位置 | 日期 | 路径 |
|---|---|---|---|
| canonical | platform.match: Like/Block/MatchController | 09-14 12:13~12:14 | /likes /blocks /matches |
| 二代 | platform.relationship: Relationship(Status)Controller | 09-10 10:59 | /relations/* /relationship/* |
| 一代(规范) | REST API 接口详细设计规范.md | 08-28 | /relationships/*（多一个 hips） |
| 前端 | miniapp/services/matchService.js | 08-29 | 混用二代 + 一代 |

后果：缘分三榜、黑名单页、成功牵手流程全部 404；另有两份重复 success 实现 + 一份桩实现。

## 裁决：采用 2026-09-14 最新路径，前端与二代让位（用户指令）

### 补齐 canonical 模块缺口（此前只有 javadoc 声明或服务方法，无控制器）
- RelationService.unlike() + LikeController `DELETE /likes/{targetUserId}`
- 新增 PassController `POST /passes`（RelationService.pass 在 09-14 模块内却无控制器，补齐与 /likes、/blocks 对称）
- BlockController `GET /blocks`（javadoc 早声明"我的 Block 列表"但未实现，mapper findBlockedByUser 已就绪）
- MatchController `POST /matches/{id}/success/request|confirm|decline`（javadoc 标"Phase 12 预留"），
  委派真实实现 RelationshipStatusService；authorizedMatch 对"不存在"与"无权"统一回 404，避免探测他人 Match
- LikeResponse 对齐前端 LikeResult：{ relationStatus, mutualMatch, matchedConversationId, matchId }
  Mutual 时调 ChatService.getOrCreateConversation 取会话 id → "双向喜欢→跳聊天"链路真正打通
- LikeController/PassController/BlockController 补 targetUserId 空值校验

### 移除被取代的路由与桩实现
- RelationshipController 移除 like/cancelLike/pass/block/unblock/matches/unmatch/success，仅保留 /fate/*
- RelationshipStatusController 移除 /success/*（已由 /matches/{id}/success/* 取代），保留关系状态生命周期
- RelationshipService 删除 requestSuccess/confirmSuccess 桩 ——
  前者自述 "TODO: 查询 relationship_success_requests 表" 却返回硬编码 status="pending"，
  等于绕过 AGENTS 硬规则 6「成功牵手必须双确认」
- 注意：RelationshipService.like/block/pass 被 P0FixVerificationTest /
  RelationshipBlockPriorityPhase08Test 直接测试，方法体保留

### 列表信封统一
- CursorPage 从 chat.dto 提升到 shared.dto（消除 match 模块反向依赖 chat DTO）
- /relations/fate/mutual|liked|likers 与 GET /matches 改返回 { items, nextCursor }

### 前端对齐
- matchService.js 全部路径改到 canonical；补 declineSuccess
- matchStore 补 _decorateBlockedList，修复"模板渲染 blockedAtText 但全仓从未计算"的缺陷
  （与上一轮 lastMessageAtText 同源，同类字段一律在 store 装饰一次）

### 文档
- docs/api/API_INVENTORY.md 关系/缘分/匹配三节重写为 canonical 路径；
  顶部加 /me/* 路径族显式警告（小程序按规范写 /me/*，后端实为 /profile/*、/photos、/relationship/*，
  约 15 个端点会 404，收敛方向未裁决，防止后续照抄踩坑）
- docs/STATUS.md：Backend 回归债务由「待清（277 tests 4F/8E）」更新为「已清偿（297 tests 全绿）」

## 验证
- 新增 CanonicalRouteContractTest（3 例）：用 RequestMappingHandlerMapping 断言
  canonical 路径已注册、被取代的旧路径不再注册、关系状态生命周期保留 —— 路由再漂移即红
- 后端 297 tests, 0 failures, 0 errors, 3 skipped, BUILD SUCCESS
- 小程序 tsc --noEmit 通过
 2026-09-15 23:16:27 +08:00
Codex 984827f415 docs: phase 4 acceptance report + STATUS sync 
- STATUS.md updated: 阶段0-4全部完成, Ready for User Acceptance
- New acceptance report: 三端构建/13契约/源码健康度/债务清单
- CapabilityService independentized (AGENTS.md #26 compliance)
- discover 筛选完整重设计 (5 chip + 4 section + bottom sheet)
- miniapp C组 content/anti-fraud/service-station TS-only
- 三端构建全绿: miniapp tsc=0, admin-web vue-tsc=0, vite build OK
- 13/13 contracts all green
 2026-09-14 11:43:46 +08:00
Codex 93fc9b0d88 feat(miniapp): migrate C-group pages to TypeScript, update contracts 2026-09-14 10:14:05 +08:00
Codex e59038790c docs(status): sync with phase 0 gate results, V035 migration and clean git tree 2026-09-14 10:04:08 +08:00
Codex c66e42dd8a docs: retire conflicting UI baselines 2026-09-13 21:12:50 +08:00
admin 5b51d5b3f1 feat: complete phase 02 RBAC and data scope recovery 2026-09-10 10:58:43 +08:00
admin b46b48eb33 chore: establish V1.1 recovery baseline 2026-09-09 22:05:00 +08:00