admin/danyang-match
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
71 Commits 2 Branches 8 Tags
6ae08b89fbdd8caa766ea0d8078cb81981e8be89
Commit Graph
25 Commits
Author SHA1 Message Date
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 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 0da82c9914 docs(gate): add phase 4 gate output artifacts 2026-09-14 11:44:02 +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 0518cda95c docs: add phase 04-06 recovery reports, gate outputs and execution plan 2026-09-14 10:01:41 +08:00
Codex 8b8972a77b test: verify admin reference UI fidelity 2026-09-13 22:09:15 +08:00
Codex 3a634b4ef2 docs: finalize UI cleanup report 2026-09-13 21:26:30 +08:00
Codex 61ca737e02 docs: record UI cleanup checkpoint 2026-09-13 21:24:54 +08:00
Codex c66e42dd8a docs: retire conflicting UI baselines 2026-09-13 21:12:50 +08:00
Codex 1deda1e943 chore: inventory obsolete UI files 2026-09-13 20:15:33 +08:00
Codex 56e8329b59 docs: plan reference-driven dual-client UI redesign 2026-09-13 20:07:43 +08:00
Codex 8b5d2b35f8 docs: define reference-driven dual-client UI redesign 2026-09-13 19:54:31 +08:00
admin aad666d1a0 test: freeze full UI redesign page matrix 2026-09-11 16:08:17 +08:00
admin 159772f615 docs: plan full dual-client UI redesign 2026-09-11 15:51:03 +08:00
admin 8550ab980d docs: define dual-client UI redesign 2026-09-11 15:09:44 +08:00
admin ff451d3185 docs: plan Codex baseline cleanup 2026-09-11 10:15:38 +08:00
admin 8432587b83 docs: define Codex baseline cleanup 2026-09-11 10:13:02 +08:00
admin ac2327b499 chore: checkpoint before switching to main 2026-09-11 09:07:41 +08:00
admin 45ca118453 feat: deliver V1.1 dual-client UI fidelity milestone 2026-09-10 16:06:11 +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