4 Commits

Include renames

Author	SHA1	Message	Date
WorkBuddy	8b505d9133	feat: disable user messaging and retain公益 service guidance	2026-10-15 13:38:17 +08:00
WorkBuddy	8dee67040c	fix(miniapp): 幂等键改为按操作稳定；删除指向 404 的互选死代码 ... 1) 幂等键（配合后端机制） 原写法把 Date.now() 拼进幂等键，每次调用都生成新键，即使后端实现了幂等 也永远不会命中 —— 声明端与实现端各自都坏。 api.idempotencyKey(scope, subject)：键缓存在 _pendingIdempotency（TTL 10min）， 同一逻辑操作在成功之前复用同一把键，收到 200+success 才释放；失败（含网络错误） 不释放，下次重试沿用同一把键。25 处调用点（8 个 service + 2 个 TS 页面）全部替换， Date.now 幂等键写法残留经 grep 为 0。 2) 删除死代码 submitInterests 它请求 POST /activities/{id}/interests —— 后端从未实现该端点 （Phase 16 已把表达意向合并进 /activities/{id}/feedback 的 interestTargetUserIds）。全仓确认无任何页面/组件调用方。 两个文件各留注释说明删除原因与恢复条件：若产品确认需要独立的 「提交互选」端点，应先定义语义并补后端实现，再恢复前端方法。 store 头部关于 AGENTS 第 6 条（单向意向保密）的注释同步改为引用 submitFeedback 返回的 newMutuals。	2026-09-18 16:37:33 +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
admin	b46b48eb33	chore: establish V1.1 recovery baseline	2026-09-09 22:05:00 +08:00