8 Commits

Include renames

Author	SHA1	Message	Date
WorkBuddy	3c2b967274	release: freeze 2026-10-15 validated release baseline	2026-10-15 09:47:31 +08:00
WorkBuddy	825fd41ee4	fix(auth): 修复刷新令牌链路三层断点，并把 121 处裸异常收敛为携带 HTTP 语义的异常 ... 用户在微信开发者工具里看到首页全站 401，追下去发现「刷新」这条路整条是断的， 且断在三个互不相干的地方 —— 每修好一层，下一层才显形： 1) 前端漏传 userId → /auth/refresh 直接 400（上一笔 63c18d8 已修） 2) 后端把 refresh token 交给 validateToken 校验，而那是用 access 密钥验签的， refresh token 由 refresh 密钥签发 → 必然失败。这是本次的核心修复。 3) 失败被抛成裸 RuntimeException → HTTP 500，客户端当作服务端故障重试。 4) 换发出来的新 refresh token 与旧 token **逐字节相同** —— JWT 的 iat 只有秒级精度、 且未设 jti，同一用户同一秒内签发的令牌完全一致，「刷新即轮换、旧令牌作废」 这条安全属性形同不存在（Redis 比对旧值自然相等）。三处签发补 UUID jti。 第 2 层此前被两层掩盖：前端漏传 userId 使请求先 400 走不到验签；且全仓 没有任何 /auth/refresh 用例。第 4 层则只在「同一秒内签发两次」时才暴露， 是新增 E2E 用例（换发后立刻用旧令牌再刷一次）把它逼出来的。 同时修复审计中发现的同族问题： - AnalyticsService 用的是 shared.exception.BusinessException，而全局处理器只映射 嵌套类 GlobalExceptionHandler.BusinessException —— 该异常无任何 handler，直落 500。 现让旧类继承被映射的类，从结构上杜绝「未映射的业务异常静默 500」。 - 小程序 authStore 读 result.needPhone，后端返回 isNewUser → `!undefined === true`， 每个用户一登录就被标记成已绑手机号。同族的第三个字段名不一致缺陷。 - 小程序 api.js 的 401 分支会无条件触发 onSessionExpired→refresh；后端把刷新失败 语义修正为 401 后，这条路径会自我递归。补 /auth/* 守卫。 - 登录页只认 instanceof Error，把服务端文案（如「账号已被封禁」）丢了。 后端异常收敛（121 处 → 0）： - 业务拒绝改抛 BusinessException + ApiResponseCode（404 不存在 / 403 无权与状态不允许 / 409 冲突重复 / 400 参数非法），文案一字未改，避免测试与前端文案契约漂移 - 真正的服务端故障（加解密、文件头、上传、签名、实名 Provider）改为显式 ServerErrorException：仍是 500，但意图明确、ERROR 记全栈、不向客户端泄露内部细节 - 用带显式映射表的脚本执行（fail-closed，遇未知文案即中止），不用启发式规则 守卫（先有判别力再谈全绿）： - 新增 JwtTokenServiceRefreshTokenTest：钉住「refresh 用 refresh 密钥验签」与 「两类令牌不得互相顶替」（含两把密钥被配成同值时的 type 声明兜底）， 以及「同一秒内签发的两个令牌必须逐字节不同」 - 新增 RuntimeExceptionThrowGuardTest：扫源码断言 main 零裸抛（无白名单副本） - GlobalExceptionHandlerTest 补三条：别名的实例必须按其业务码回 403 而非 500、 无法识别的字符串码 fail-closed 到 500（不得退化成无信息的 400）、 以及继承关系守卫（把别名类改回 RuntimeException 会静默恢复该缺陷，只有它能咬住） - 新增 tests/e2e/auth_refresh_test.py：唯一覆盖 /auth/refresh 的用例， 断言换发的 accessToken 真能过鉴权、旧令牌轮换失效、无效凭据 401 而非 500 - http_semantics_test.py 补「Service 层拒绝必须是 4xx 而非 5xx」 - miniapp-auth-contracts.mjs 补 isNewUser 映射（双向）与 /auth/* 401 不递归 验证： - 定向后端测试 9/9 - 全量后端测试 113 个测试类、0 失败、BUILD SUCCESS - 本机真实栈 E2E 72 passed（含 7 个新增刷新用例） - miniapp tsc 0 错误、UI 契约门控 18/18 - 负向注入两处精准变红（RuntimeExceptionThrowGuardTest 与 JwtTokenServiceRefreshTokenTest 各 1 例），BUILD FAILURE， 注入前后工作区 SHA256 逐字节一致（零污染）	2026-09-22 21:41:30 +08:00
WorkBuddy	63c18d89c2	fix(miniapp): 修复全站 401 —— 认证链字段名不一致 + 首页 onRetry 缺失 ... 根因（读码 + 本机后端实测坐实）： - 后端登录/刷新返回 accessToken，前端 authStore 却读 result.token → accessToken 从未落库 → 每个请求都不带 Authorization → 全站 401（首页无法加载）。 - /auth/refresh 少传 userId：后端以 userId 定位 Redis refresh token， 缺失即 BAD_REQUEST → HTTP 400（实测 {refreshToken} 体 → 400）。 - 首页 index.wxml 绑定 bind:retry="onRetry"（ui-error-state 触发 retry 事件）， 但 index.ts 无该方法 → 控制台报错、错误页「重新加载」失效。 - app.globalData.token 从未赋值，多页直读它拼 Authorization → Bearer undefined。 修复： - authStore：登录/刷新改用 result.accessToken；刷新传 this.state.userId。 - authService.refresh(userId)：发送 { userId, refreshToken }。 - pages/index：新增 onRetry；onLoad 订阅 authStore（expired → 回登录引导； 刷新成功且停在错误态 → 自动重载）；onUnload 退订。 - utils/api：saveToken/clearToken/getToken 同步 app.globalData.token，兼容旧页面。 守卫补强： - ui-tests/miniapp-auth-contracts.mjs 原仅覆盖 hydrate，对字段名缺陷零覆盖。 新增行为断言：登录后 storage.accessToken 必须等于后端 accessToken； 刷新请求体必须含 userId + refreshToken 并持久化新 accessToken。 已双向负向注入验证判别力（改回 result.token / 去掉 userId 均 exit 1）。 验证： - tsc --noEmit -p miniapp/tsconfig.json → exit 0，零错误。 - scripts/run-ui-contracts.mjs → 18/18 PASS。 - 本机 8085 /auth/refresh 三态实测：{} → 400；{refreshToken} → 400； {userId,refreshToken} → 500（进入服务校验，非 400）。 - 未验证：开发者工具内实际登录→首页链路（本机无法驱动 devtools，待用户复测）。	2026-09-22 19:08:16 +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
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
admin	c20301ffff	fix: restore miniapp public startup flows	2026-09-10 22:57:52 +08:00
admin	b46b48eb33	chore: establish V1.1 recovery baseline	2026-09-09 22:05:00 +08:00