admin/danyang-match
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
68 Commits 2 Branches 8 Tags
3244e02e7e7da5a74b283121eebf2d9427d4a6c4
Commit Graph
22 Commits
Author SHA1 Message Date
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 687a156350 fix(chat): 会话/消息响应契约对齐小程序，修复聊天页字段断链 
## 问题（三处真实断链）
后端 chat 模块字段名与小程序契约不一致，但自动化测试此前未覆盖，故一直未被发现：

1. 会话 DTO 用 otherUserId/otherDisplayName/otherAvatarUrl，
   而前端（types/index.d.ts + pages/chat/chat.ts + components/conversation-item）
   只读 targetUserId/targetDisplayName/targetAvatarUrl。
   → chat.ts 取不到对方 userId（无兜底，落到空串），
     导致"查看资料 / 拉黑 / 举报"点击后提示"暂无更多信息"并失效。
2. 消息响应只给 createdAt（ISO 字符串），前端读 Message.sentAt: number（epoch 毫秒）。
   → chat.ts 时间分隔 ts 恒为 0，消息时间分隔与时间文案不显示。
3. 会话对象缺 relationStatus，前端 conversation-item 依赖它做灰显与"已拉黑"提示。

## 裁决依据
按"以文件修改时间为准"的裁决统一到前端约定：
- 前端 types/index.d.ts 被 86 个页面引用，是声明式契约
- pages/chat/chat.ts（09-04）是最新的真实消费者
- targetUserId 已是项目内既有惯例（ActivityMatchItemDTO）
- admin-web 不消费 /conversations，无第二方受影响

## 变更
- ConversationDTO：字段改名 target*；新增 relationStatus；lastMessageAt 改 epoch 毫秒
- ChatService.toConversationDTO：同步映射；relationStatus 按 Block > unmatched > mutual_match > neutral 推导
- Constants：新增 RELATION_STATUS_NEUTRAL / MUTUAL_MATCH / UNMATCHED（不硬编码）
- MessageResponse：新增 sentAt（epoch 毫秒）
- miniapp/utils/datetime.js（新增）：收敛时间格式化，
  补上模板依赖但全仓从未计算的 lastMessageAtText
- messageStore：会话进入 store 时统一装饰 lastMessageAtText
- chat.ts：_formatTime 改为复用共享工具；移除已失效的 otherDisplayName 兜底

## 验证
- 新增 ChatContractJsonTest（4 例）锁定字段名、sentAt 数值类型、
  并断言 other*/status 旧字段名不再出现
- 后端 294 tests, 0 failures, 0 errors（原 290 + 新增 4）
- 小程序 tsc --noEmit 通过

遗留（未在本轮处理）：平台尚未实现头像 URL 解析（user_photos 只存 fileKey），
targetAvatarUrl 保持 null，前端 ui-avatar 回退昵称首字，不影响展示。
 2026-09-15 22:45:46 +08:00
Codex eaf8fdf195 refactor(backend): P0 阻断修复 + 按最新修改时间收敛重复模块与契约 
## P0 阻断修复
- 编译：修复实体类与服务类同名导致 Lombok 注解轮次中止的问题
  （MatchmakerService/CounselingService -> *Record），196 个编译错误归零
- 权限矩阵：platform_admin 按设计文档收紧为拒绝 5 项高危权限（不改测试阈值）
- 启动：修复 8 组 MyBatis-Plus 同名 bean 冲突（ConflictingBeanDefinition）
  与 URL 路由歧义（Ambiguous mapping），应用可正常启动

## 模块收敛（裁决规则：以文件修改时间为准）
- messaging 包整体删除，能力迁移至 chat 包
  * 会话列表/详情/未读端点、ConversationDTO、CursorPage
  * 消息游标分页统一为 { items, nextCursor }
- relationship 的 Match/UserRelation entity 与 mapper 合并进 match 包
- MatchmakerUserController 合并进 MatchmakerController，删除冗余 Controller
- 补齐 INV-004：chat sendText 增加双向 Block 校验，拉黑后禁止发送

## 契约对齐
- 红娘服务提交请求兼容前端 { requirement } 字段
- 消息与会话分页契约前后端统一

## 测试
- 迁移 6 个风控用例至 ChatSafetyServiceTest
- 清理 messaging 测试包遗留：6 个真实常量断言归位 chat 包，
  移除 2 个 assertTrue(true) 占位假测试（Block 真实行为已由
  P0FixVerificationTest / RelationshipBlockPriorityPhase08Test 覆盖）
- schema-h2.sql 对齐 PostgreSQL 真实表结构（matches 补列、
  conversation_members 改复合主键）

结果：290 tests, 0 failures, 0 errors, 3 skipped, BUILD SUCCESS
 2026-09-15 22:29:26 +08:00
Codex 918368159c feat(phase-13A): CounselingService — INV-012/013 + 婚恋咨询 + 婚前辅导 
Phase 13A Counseling — ADD new domain module per AGENTS.md rule #21/#22.

counseling module (5 files):
- Entity: CounselingService -> counseling_services
- Entity: CounselingFollowup -> counseling_followups
- Mapper: CounselingServiceMapper (findFull + findSanitized INV-013)
- Service: CounselingService
  INV-012: assertAssigned() guards schedule/complete
  INV-013: getDetail() returns sanitized for matchmaker/operator,
           full for user/assigned-counselor/manager
- Controller: 7 endpoints (user/apply/list/detail, counselor/assigned/schedule/complete, manager/assign)

Permission model (Service layer guarded):
  User(self) -> full detail
  Assigned Counselor -> full detail
  counseling_manager -> full detail
  Matchmaker/Operator -> sanitized only (no user_request_summary)

service_type: counseling(婚恋咨询) / premarital(婚前辅导)
 2026-09-14 14:51:25 +08:00
Codex 5cbd931fa2 feat(phase-13): MatchmakerService — referral + manual recommendation + user confirmation 
Phase 13 Matchmaker — EXTEND per JIRA. P13-V11-T01 through P13-V11-T05.

New matchmaker module (5 files):
- Entity: MatchmakerService (request), MatchmakerRecommendation (manual rec)
- Mapper: MatchmakerServiceMapper, MatchmakerRecommendationMapper
- Service: MatchmakerService
    T01 createReferral(type=counseling) — referral only, does NOT submit on behalf
    T02 createReferral(type=activity)
    T03 createReferral(type=service_station)
    T04 referral_source追溯: every referral carries operator_id + service_id + type
    T05 用户拥有最终决定权: acceptRecommendation() calls RelationService.like()
        as the USER, not the matchmaker. Matchmaker NEVER creates Match directly.
        If mutual, updates Match.source='matchmaker' for traceability.
- Controller: user endpoints (submit/list/pending-recommendations/accept/pass/viewed)

Core AGENTS.md #5 compliance:
- Matchmaker can only 'recommend', NEVER 'like on behalf of'
- User must actively accept recommendation (calls acceptRecommendation -> RelationService.like)
- createRecommendation creates pending_view record + notification, nothing else
- confirm mutual only when BOTH users independently Like (existing Like flow)

Status machines:
- matchmaker_services: submitted -> assigned -> processing -> completed
- matchmaker_recommendations: pending_view -> viewed -> liked/passed/confirmed_mutual
 2026-09-14 14:48:23 +08:00
Codex 0418856ce3 feat(phase-12): RelationshipStageService — home service suggestions 
Phase 12 Relationship — KEEP/EXTEND per JIRA. 不增加复杂状态.

New RelationshipStageService (match module):
  P12-V11-T01 Successful match -> premarital_suggestion
  P12-V11-T02 GettingToKnow match -> matchmaker + counseling
  P12-V11-T03 7-day silence in GettingToKnow -> counseling_recommendation

Rules are simple, based on existing Match.status + lastActivityAt:
- successful  -> 婚前辅导建议
- getting_to_know -> 红娘服务 + 婚恋咨询建议
- getting_to_know + 7d silence -> 婚恋咨询促活建议
- no Match    -> 默认红娘 + 婚恋课堂

Integration point: HomeApplicationService.buildRecommendations()
just inject RelationshipStageService and append suggestions to home DTO.
 2026-09-14 14:40:13 +08:00
Codex e2a8a8c85f feat(phase-11): NotificationService — 10 business templates + privacy-safe external copy 
Phase 11 Notification — EXTEND per JIRA. P11-V11-T01 through P11-V11-T11.

New notification module (4 files):
- Entity: Notification -> notifications (existing DB table)
- Mapper: findByUser/countUnread/markRead/markAllRead + findExisting(idempotent)
- Service: NotificationService with 10 business templates
  T01 appointmentSubmitted  T02 appointmentConfirmed  T03 appointmentChanged
  T04 counselingAssigned    T05 counselingScheduled   T06 counselingCompleted
  T07 premaritalScheduled   T08 leNeedEvidence        T09 leVerified
  T10 leRejected
  T11 buildPrivacySafeCopy -> external lock-screen copy NEVER reveals
  sensitive counseling type names (INV-010 compliance)
- Controller: GET list, GET unread, PUT markRead/{id}, PUT readAll

Design invariants:
- sendExternal() wrapped in try/catch -> failure does NOT rollback core service
- Idempotency via (user, type, business_type, business_id, content) dedup
- External copy uses neutral words '服务/预约' for counseling events, not '咨询'
 2026-09-14 14:33:37 +08:00
Codex cf3a84e725 feat(phase-10): Chat Safety — content scan + rate limit + RiskNotice 
Phase 10 Chat Safety — KEEP per JIRA. P10-V11-T01/P10-V11-T02.

New ChatSafetyService (chat module):
- scanContent(): HIGH_RISK keyword + CONTACT regex (phone/wechat/QQ/scan)
- checkRateLimit(): Redis counter + fail-open fallback, stricter for new Match (first 5 min)
- buildRiskNoticeBody(): system message JSON with anti-fraud targetPage

ChatService.sendText() integrated Phase 10:
  1. Redis rate limit check (newMatch-aware)
  2. Content scan -> risk_level on Message
  3. high/critical -> throw, block send
  4. warning -> peer gets RiskNotice system message (P10-V11-T01: anti-fraud entry)
                                        (P10-V11-T02: RiskNotice -> anti-fraud content page)
  5. Log enriched with risk_level

Constants already had RISK_LEVEL_* and MESSAGE_TYPE_SYSTEM — no new constants needed.
 2026-09-14 14:16:47 +08:00
Codex eda2ce19a8 feat(phase-09): Text Chat full backend + WebSocket 
Phase 09 Chat — KEEP per JIRA. P09-V11-T01 Activity Match source compatibility.

New chat module (11 files):
- Entity: Conversation, ConversationMember (复合主键), Message
- Mapper: ConversationMapper, ConversationMemberMapper, MessageMapper
- Service: ChatService (getOrCreateConversation/sendText/loadMessages/markAsRead/syncFromMatch)
- Controller: ConversationController (POST /from-match, GET /{id}, GET list)
              MessageController (POST send, GET load history, PUT mark read)
- WebSocket: WebSocketConfig + ChatWebSocketHandler (/ws/chat, JSON protocol)

Core invariants:
- INV-005: ChatService requires Match status active/getting_to_know
- Conversation.status sync with Match.status (syncFromMatch)
- Member.canSend + Conversation.status + sender membership all validated
- Client-side idempotency via client_message_id
- P09-V11-T01: Conversation binds only match_id — works identically for
  user_like / activity_mutual / matchmaker Match sources

WebSocket note: Memory-based session map; multi-node will need Redis Pub/Sub.
 2026-09-14 14:00:04 +08:00
Codex 8b62b5b5df feat(phase-08): Like / Match / Block full backend implementation 
Phase 08 Like/Match/Block — KEEP per JIRA, incremental P08-V11-T01.

New entities (match module):
- UserRelation -> user_relations (liked/passed/blocked)
- Match -> matches (source: user_like/activity_mutual/matchmaker, episode-aware)

New mappers:
- UserRelationMapper: findOne/countBlockedEitherWay/countReverseLike
- MatchMapper: findActiveBetween/findLatestBetween/findActiveByUser/findHistoryByUser

New services:
- RelationService: like/pass/block/unblock + mutual detection + capability guard
  - INV-004: Block priority highest (auto-unmatch, mutual block check)
  - INV-005: Like only creates Match on Mutual
- MatchService (static): createOrReuseMatch factory
  - AGENTS.md #19: existing active Match -> reuse
  - AGENTS.md #20: prior unmatched -> new Match with episode+1
  - source-aware: user_like / activity_mutual / matchmaker

New controllers:
- POST /api/v1/likes
- POST /api/v1/blocks, DELETE /api/v1/blocks/{target}
- GET /api/v1/matches, GET /api/v1/matches/{id}, POST /api/v1/matches/{id}/unmatch

Integrates with CapabilityService for base eligibility checks on Like.
 2026-09-14 12:15:27 +08:00
Codex dd58ab6eae feat(capability): extract CapabilityService — AGENTS.md rule #26 compliance 
New module backend/capability/:
- CapabilityService: getCapabilities(entry point for frontend),
  plus public helpers (isAccountNormal/isIdentityVerified/isProfileApproved/
  isSearching/isBaseEligible/hasLocalEligibility/entry builder)
- CapabilityController: GET /api/v1/capabilities endpoint

HomeApplicationService refactored:
- Injects CapabilityService, delegates buildCapabilities()
  and QuickEntry construction + recommendation eligibility checks
- Removes duplicated private methods (isSearching/isIdentityVerified/
  isProfileApproved/entry) — single source of truth now in CapabilityService

Contracts updated to check CapabilityService.java for capability-related
assertions (setDisabledReason/isIdentityVerified/ACCOUNT_STATUS_NORMAL)
 2026-09-14 11:38:30 +08:00
Codex ea2bb2439d chore: complete infrastructure config, contracts, reference images and ui redesign artifacts 2026-09-14 10:02:34 +08:00
Codex 63cbbff2de feat: implement miniapp C-group pages with real API calls and design tokens 2026-09-14 10:02:22 +08:00
Codex bb380d40f6 feat: enhance home aggregate, review atomicity, local eligibility and match engine (phase 04-07) 2026-09-14 10:02:07 +08:00
Codex 10887f40ed feat: add V034-V035 flyway migrations and phase 04-07 test classes 2026-09-14 10:01:50 +08:00
admin b8c33b9a0c chore: remove legacy build artifacts 2026-09-11 10:19:22 +08:00
admin ac2327b499 chore: checkpoint before switching to main 2026-09-11 09:07:41 +08:00
admin c20301ffff fix: restore miniapp public startup flows 2026-09-10 22:57:52 +08:00
admin d6f5f25c35 fix: repair admin page api contracts 2026-09-10 21:31:38 +08:00
admin 7994e081a6 fix: rebuild latest demo database 2026-09-10 20:28:29 +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