185 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
WorkBuddy	f73a116a10	feat(matchmaker): 受控联系审批分层落地（OQ-MATCHMAKER-009 裁决：组长主审+管理员兜底）+ enabled fail-safe 行为基线 ... - ContactAuthorizationService approve/reject 分层语义：matchmaker.assign 平台管理员=兜底岗（全量审批、不做组织校验）；approver-authorities 首段（默认 matchmaker.team.assign）=主审岗（assertTeamScope 组织范围，hasGlobalAssign 固定 false 防权限面双通道，NULL=NULL 平台直属可审）；两者皆无 403 deny 不变 - 真实缺口修复（OQ-010 引出）：request 入口原未查 matchmaker.contact.enabled，补 denyAsNotFound fail-safe（与 disclose 口径一致：最先、404 化、防探测） - 测试：MatchmakerContactAuthorizationTest 10→13（管理员跨组织兜底/组长他组织 403/组长审平台直属 NULL=NULL/双岗兜底全量，均 HTTP+审计双断言）；新增 MatchmakerContactDisabledTest（enabled=false 时 disclose/request 404 化、零 SensitiveAccessLog、零 contact 成功审计、fail-safe 先于 purpose 校验） - 负向注入：移除兜底分支 → 恰好 2 例分层用例判红（主审路径保持绿，判别力精准）→ 还原复绿 - 验证：主理人 Docker 独立实跑 20/20（授权 13+disabled 2+守卫 5）；全量 mvn verify 900/900(3 skip)；后端契约 234/CURATED 20；UI 24/24 - 裁决依据：OQ-MATCHMAKER-009（组长主审+管理员兜底）、LEGAL_VERIFY③ 7 天/④ 365 天/⑤ NULL=NULL 维持（登记于 governance）	2026-10-11 15:57:56 +08:00
WorkBuddy	21275ef770	docs(governance): 受控联系立项治理登记（OQ-003 转 IN_PROGRESS / OQ-009~010 新增 / DEC-MATCHMAKER-003-B1 落账） ... - config-register.md: matchmaker.contact.* 五 canonical key 登记（enabled fail-safe 缺省 false / approver-authorities 双岗并列 / consent-deadline-hours 72 / default-validity-days 7 / retention-days 365，均 DEFAULT+CONFIG 非 LOCKED 待产品+法务终审） - open-questions.md: OQ-MATCHMAKER-003 DEFERRED→IN_PROGRESS（V056 立项实现，双守卫翻转，5 项 LEGAL_VERIFY 逐项标注当前实现态与默认配置键）；新增 OQ-MATCHMAKER-009（审批双岗并列待收敛，OPEN）与 OQ-MATCHMAKER-010（enabled=false 行为用例待补，QA P2-2） - PENDING_DECISIONS.md: 受控联系行更新为已立项实现（DEC-MATCHMAKER-003-B1，V056，提交 d3735e3）；剩余决策=双岗收敛+LEGAL_VERIFY 终审 - decision-register.md: DEC-MATCHMAKER-003-B1（2026-10-11 LOCKED→已实现）登记，验证数字 mvn verify 895/895、UI 24/24、后端契约 228/CURATED 20、真编译 87 WXML、负向注入 5+2 v1.2.1	2026-10-11 13:11:52 +08:00
WorkBuddy	d3735e3afa	feat(matchmaker,contactauth): 受控联系授权机制立项落地（OQ-MATCHMAKER-003 / DEC-MATCHMAKER-003 B1 例外通道） ... 后端： - V056 matchmaker_contact_authorizations 表：channel CHECK(phone/offline_meeting/full_contact)、六态状态机(pending_approval→pending_consent→active→expired/revoked, →rejected)、部分唯一索引 uq_mm_contact_auth_active 防同红娘-同用户-同渠道多 ACTIVE、双态惰性收敛(active 过期 + pending_consent 超同意窗口) - ContactAuthorizationConfig 五 canonical key(matchmaker.contact.*)：enabled 代码缺省 false fail-safe(yml 显式 true)/approver-authorities 双岗并列/consent-deadline-hours 72/default-validity-days 7/retention-days 365，全部 DEFAULT+CONFIG 待产品+法务终审 - ContactAuthorizationPolicy.assertContactAllowed(404 化 deny 先审计后 404) + canContact 徽标查询 - ContactAuthorizationService：request(须有效分配+purpose 必填)/approve(权限码动态判定∈配置+组长组织范围)/consent(用户本人,仅 pending_consent)/decline/revoke(reason 必填)/disclose(唯一披露出口：enabled fail-safe→assertActiveAssignment→assertContactAllowed→仅返回 phone/disclosedAt/authorizationId 三键，每次落 SensitiveAccessLog user_phone_disclosure，phone 不落应用日志) - 双控制器：运营端 /operator/matchmaker/contact-authorizations + C 端 /contact-authorizations(UserPrincipal 归属校验,独立端点无预同意参数)，不碰 SecurityConfig 守卫翻转（机械锁强制复审机制按设计生效）： - MatchmakerContactGuardTest 由「锁不存在」翻转为「锁新契约」五条：回显白名单类收敛/端点前缀收敛(受治理三包)/到期语义/consent 独立性三端扫描(后端+miniapp+admin-web,修复原只扫后端的预同意参数逃逸缺口)/ReferralService 白名单与无 @Scheduled 保留 - run-backend-contracts CURATED 18→20 前端： - miniapp 新页 pages/contact-consent(目的/渠道/窗口明示+独立同意拒绝按钮无预勾选,app.json 第 64 页) + 红娘工作台申请/列表/撤销 - admin-web「联系授权审批」tab(审批岗队列+本人授权撤销,枚举码中文映射) 验证：mvn verify 895/895(3 skip)、UI 契约 24/24(64 页)、后端契约门禁 228/CURATED 20、小程序真编译 87 WXML 0 失败；负向注入 5(工程师)+2(QA 不同落点)判红→还原复绿；QA 抓 disclose 键数收敛断言缺口已补并回归；QA fresh eyes PASS 0 P0/P1	2026-10-11 13:08:02 +08:00
WorkBuddy	4248e9574e	chore(release): 版本号 1.1.0 -> 1.2.0（红娘角色权限专项 ZC-MM-001~007 落地固化） v1.2.0	2026-10-11 10:48:33 +08:00
WorkBuddy	6c2601950b	docs(governance): ZC-MM-007 同步治理文档——红娘专项 DEC-MATCHMAKER-001~006 收口 ... - decision-register.md: 登记 DEC-MATCHMAKER-001~006 全部 LOCKED（实施摘要 + 落地提交链 2d60f78/861c78e/5e484d0/3caf5f8/1be0d98 + 验证数字 mvn verify 884/884、UI 契约 24/24、后端契约 198、负向注入 7 处判红→还原） - open-questions.md: 新增 OQ-MATCHMAKER-003~008——003 受控联系开放前 5 项确认（①②LEGAL_VERIFY）+ ContactAuthorizationPolicy DEFERRED（MatchmakerContactGuardTest 机械锁强制复审）/ 004 NULL=NULL 平台直属规则 / 005 零缓存实时查库压测复议条件 / 006 写接口 404 化语义边界（RESOLVED）/ 007 purpose_code matchmaker.service.view 定义未使用口径漂移（QA P2①）/ 008 运营域 active 与用户域 normal 状态口径差（QA P2②） - PENDING_DECISIONS.md: 红娘专项六项决策标已落地；新增两项待产品确认——受控联系授权机制开放（OQ-003 引用）、C 端死代码退役 3 项（getCandidates/cancelService/getRecommendationsForUser，grep 零调用已核）专项治理批次 ZC-MM-001~007 全链路闭环（架构师落盘 + 主理人 grep 锚点终验：DEC-MATCHMAKER/DEFERRED/LEGAL_VERIFY/OQ-003~008 全命中，零代码变更）	2026-10-11 10:26:35 +08:00
WorkBuddy	1be0d98ebd	ZC-MM-006 审计与权限回收（阶段4） ... - T01: V055 audit_logs 扩展 4 字段(purpose_code/service_assignment_id/actor_role_snapshot/request_trace_id, 全可空幂等) + AuditLog/DataScopeGuard/AuthorizationAuditListener/MatchmakerServiceService 写入链路改造 + schema-h2 同步 + LATEST_MIGRATION 54→55 - T02: JwtAuthFilter 运营分支改实时查库权限回收(每请求查 operators.status + 权限, 停用即401/撤权即403, 零缓存, claims 权限降级只写不读), 不碰 SecurityConfig/JwtTokenService/用户端 - T03: getServiceDetail 持有人分支接入 SensitiveAccessLog(成功查看落行 dataType=matchmaker_service_detail, 拒绝路径只落 audit_logs DATA_SCOPE_DENIED, 双记录结构性互斥) - T04: 写接口 404 统一防探测(transfer/revoke/end/recommend/followup/complete/转介范围违规 404 化 deny, 先审计后 404, create/assign 无资源寻址维持 403, ReferralService 消灭裸 IllegalArgumentException) - T05: OperatorEndpointPermissionCoverageTest +3 守卫(类级 RequestMapping 前缀合成/缺类级则逐方法 PreAuthorize/matchmaker+referral 禁 PatchMapping) + run-backend-contracts CURATED 14→18 - 新增测试 4 类 20 用例: MatchmakerAuditFieldsTest / OperatorPermissionRevocationTest / MatchmakerSensitiveAccessAuditTest / MatchmakerWriteDenyUniformityTest - 验证: mvn verify 884/884(3 skip) + UI 契约 24/24 + 后端契约门禁 198 通过; 负向注入 5(工程师)+2(QA) 判红→还原复绿; QA fresh eyes 独立验收 PASS(0 P0/P1, 2 P2 观察项移交 ZC-MM-007) - ContactAuthorizationPolicy 维持 DEFERRED; C 端死代码退役评估 3 项留待 007/专项治理	2026-10-11 09:19:01 +08:00
WorkBuddy	5e484d0e74	test(matchmaker,referral): ZC-MM-003/004 纯护栏——B1 联系规则锁定 + 禁止代用户决定固化 ... 依据《善缘丹阳 V1.1 红娘角色权限正式决策与开发规则》DEC-MATCHMAKER-003（B1 平台内优先、授权例外）与 DEC-MATCHMAKER-004（红娘不得代替用户执行交友决策）。 本阶段生产代码零改动，交付物为护栏测试（MM-CONTACT-001~004、MM-ACTION-001~003 全部有自动化用例）。 MatchmakerContactGuardTest（4 用例，standalone 源码扫描，FieldPrivacyGuardTest 范式）： - MM-CONTACT-002：ReferralService 全部响应 put 键 ⊆ 16 键白名单（逐键对账吻合）， 禁词 {emergencycontact,phone,mobile,wechat,weixin,address,idnumber,id_card}—— 锁定红娘侧零联系方式回显（紧急联系人信息纯入口 write-only，连红娘本人都无读回面）； 含防清空自检（三关键键必须在场） - MM-CONTACT-003：红娘/转介 Controller 无 contact/call/phone/channel/offline 端点； 全仓无 ContactAuthorization 类、无 matchmaker_contact_authorizations 迁移表—— 锁定「无授权机制」；未来引入联系功能必须连同本守卫+治理同步更新 - MM-CONTACT-004：机制不存在 ⇒ 无授权到期场景（与 003 同源，未来引入同时变红） - 004 佐证：matchmaker/referral 包 @Scheduled=0（无批处理代决策面） MatchmakerActionGuardTest（6 用例，@SpringBootTest 行为锁定）： - MM-ACTION-001（3 例负向）：operator token 调用户决策端点 （/matchmaker/recommendations/{id}/accept、/pass、/referrals/{id}/confirm）→ 403 且业务状态零变化（403 来源于 SecurityConfig hasRole("USER") 身份类型防线， 与 PermissionService mock 无关，变异验证锚定真实） - MM-ACTION-002：operator token 开启会话端点 → 403 - MM-ACTION-003 must-confirm 语义锁定：红娘代建转介 → needsUserConfirmation=true/ userConfirmedAt=null/status=pending，后续 recommend/followup/complete 不改确认态 （「代填草稿、用户确认」灰色点永久锁定） - MM-CONTACT-001（正向）：红娘对本人分配对象创建推荐/转介 → 平台内服务通知落库， title/content 无手机号/微信模式，红娘 operatorId 不在通知收件面 负向注入自证： - 注入 A：ReferralService 临时加 emergencyContactPhoneEnc 回显 → 守卫三重命中判红 → 还原 - 注入 B：SecurityConfig hasRole("USER")→authenticated() → 4/4 负向用例判红 （403→401/500）→ 还原复绿 验证：定向 42/42、全量 861/861（3 预存 skip）、UI 契约 24/24。 003 方案 A（纯测试锁定）决策记录与五项 LEGAL_VERIFY open questions 随 ZC-MM-007 登记； ContactAuthorizationPolicy 桩 + matchmaker_contact_authorizations 表推迟至 ZC-MM-006 （仅当产品确认开放受控联系时立项）。	2026-10-10 14:46:53 +08:00
WorkBuddy	3caf5f8816	feat(matchmaker,referral): ZC-MM-005 统一数据范围与字段隐私（DEC-MATCHMAKER-005/§5.2 落地） ... 依据《善缘丹阳 V1.1 红娘角色权限正式决策与开发规则》DEC-MATCHMAKER-005 最小必要原则 与 §5.2 字段级隐私，ZC-MM-005 范围=「读接口行级数据范围统一接入判定器 + 字段白名单 + 组长团队脱敏统计」。承接 ZC-MM-002 落地的 matchmaker_assignments 事实源与 ServiceAssignmentPolicy 判定器。 E1 双轨切纯判定器（不留回退）： - assertServiceAccess 纯化（删 assigned_operator_id 回退分支），判定器成唯一事实源 - getServiceDetail 删 viewerIsOwner 双态与「非负责人脱敏详情」整段 E2 非负责人防探测 404： - ServiceAssignmentPolicy.assertActiveAssignmentOrNotFound：无生效分配→先落 DATA_SCOPE_DENIED 审计再抛 NOT_FOUND（响应 404），存在性不可枚举， 与「查无此单」响应体逐字段一致（MM-PRIVACY-001） E3 字段白名单显式化 + 用户隐私开关： - 抽取 assembleMatchmakerUserProfile：仅 7 键（displayName/gender/age 派生/regionName/ educationCode/occupationCode/maritalStatus），无 birthDate 原值/详细地址/手机号/微信/ 身份证；接 UserPrivacySettings.showOccupation（缺省全放行） E4 死端点清理： - 删除 GET /operator/matchmaker/my-services（operatorId 误当 user_id、恒空、前后端零调用）， 替代路径 /operator/matchmaker/assignments/my；C 端 /matchmaker/services 与 counseling myServices 保留 P1 残留收口（读/写路径仍信任废弃 assigned_operator_id 残留列，与 E1 同类洞）： - P1-1 运营端推荐列表：MatchmakerRecommendationMapper.findByOperatorId 改 join 生效分配（active+expires），撤/结后不再可见 - P1-2 dashboard 三计数：count*ByOperator 改 join 生效分配 + COUNT(DISTINCT) 防重， end/revoke 后不再计入（DEC-002 规则7） - P1-3 转介授权：ReferralService.assertMatchmakerServesUser 切 serviceAssignmentPolicy.assertActiveAssignment（DATA_SCOPE_DENIED 审计 + 403）， 删残留列查询 findActiveByOperatorAndUser 新端点（组长团队脱敏统计）： - GET /operator/matchmaker/team/statistics（@PreAuthorize matchmaker.team.assign）： 本组织 active 分配数/按红娘分组/在岗红娘数，纯计数无用户 PII；org 边界 IS NOT DISTINCT FROM（NULL=NULL 平台直属） P2-4 operatorName 脱敏决策：保留不脱敏（§5.2 字段分类：红娘姓名=团队范围内 工作人员标识非用户 PII；组长统计本团队工作量属管理职责），依据登记 docs/governance/open-questions.md OQ-MATCHMAKER-002（RESOLVED） 死代码清理：getOperatorServices（零调用）+ MatchmakerServiceMapper.findByOperatorId （残留列查询，调用清零）删除；C 端 MatchmakerService 遗留信任残留列按豁免未动（006/007 退役） 测试： - MatchmakerDataScope005Test（13 用例）：MM-PRIVACY-001/002、MM-AUTH-001/003 读侧、 MM-LIFECYCLE-001 读侧、P1-1/2/3 残留收口负向（撤/结后推荐不可见/计数归零/转介 403）、 防探测逐字段一致、showOccupation 三态 - MatchmakerFieldPrivacyGuardTest（3 用例）：字段白名单源码扫描 + 无导出端点锁定 - MatchmakerReferralPhase13Test 转介口径收紧（IllegalStateException→AccessDeniedException） - 负向注入自证（P1-3 残留列变异→判红→恢复复绿） 验证：定向 73/73；全量 851/851（3 预存 skip）；UI 契约 24/24。	2026-10-10 11:51:15 +08:00
WorkBuddy	861c78efb5	feat(matchmaker): ZC-MM-002 A1 服务对象分配建模（DEC-MATCHMAKER-002 LOCKED 落地） ... 数据库（V053/V054）： - 新表 matchmaker_assignments：独立分配关系（assigned_by/reason/scope/ expires_at/ended_at/end_reason），状态机 active/ended/revoked/transferred/ expired（CHECK 白名单），部分唯一索引防同用户多 ACTIVE 主责分配， 存量进行中服务单幂等回填 - 新角色 matchmaker_leader(014) + 新权限 matchmaker.team.assign(10000000-…-023)； 组长授 view/service/team.assign（不给平台级 matchmaker.assign） 后端： - ServiceAssignmentPolicy 有效分配判定器（读前惰性过期，失效分配即时拒绝） - 分配/转分配/撤销/结束四操作：状态机非法转换拒绝、理由必填、 同用户主责冲突拒绝；组织范围校验（team.assign 同组织，NULL=NULL 视为 平台直属，技术默认安全值待治理登记）；transfer 同时校验原持有人与新目标范围 - 全操作审计 MATCHMAKER_ASSIGNMENT_CREATE/TRANSFER/REVOKE/END， operatorId=当前操作者，afterData 仅记摘要（无敏感内容） - 删除认领端点 POST /services/{id}/claim（A1 禁止普通红娘认领，MM-AUTH-004=404） - GET /pending 收敛为分配权持有者（assign or team.assign）； dashboard today/completed 改本人口径，inProgress 口径修正 'processing'→'in_service' - recommend/followup/complete/detail 归属判定接入判定器，拒绝走 DataScopeGuard（自动 DATA_SCOPE_DENIED 审计），不再裸 IllegalStateException； assignService 与创建分配同事务联动；删除死查询 findAssignedTo 前端： - admin-web 分配弹窗去硬编码假数据（operator_wang/chen）→ assignable-matchmakers 真实接口（仅 id/name/organizationId，无联系方式）+ 理由必填； 队列 tab 按 assign/team.assign 显隐；新增「服务对象分配」tab（转分配/撤销/结束） - 小程序红娘工作台：删除接单入口，数据源切 GET /operator/matchmaker/assignments/my， 枚举码不上屏（中文映射），空 serviceId 不跳转 测试： - MatchmakerAssignmentA1Test 14 用例（MM-AUTH-001~004、MM-AUDIT-001、 MM-LIFECYCLE-001、组长跨组织拒绝、NULL=NULL 平台直属边界、transfer 原持有人 范围负向、/pending 403+审计），负向注入自证有效 - MatchmakerAssignmentPermissionTest 3 用例（端点权限契约 + claim 残留扫描） - MatchmakerServiceTest 补 assignment 状态/scope 白名单守卫；迁移基线 LATEST=54 - 验证：定向 38/38 全绿；UI 契约 24/24；小程序 wcc/wcsc 真编译 0 失败	2026-10-09 22:46:32 +08:00
WorkBuddy	6187ec69df	test(ui-guards): 导航契约守卫基线对齐后端真实权限码 ... - admin-role-navigation-contracts.mjs L40-41 原断言 referral.manage / matchmaker.service.view，但后端 permissions 表不存在这两个幽灵码—— v1.1.1 权限码对齐（4edb761）时漏更新守卫基线，导致该守卫自 v1.1.1 起恒红 - 修正为后端真实 authority 码：/referral→matchmaker.service、 /matchmaker→matchmaker.view（守卫内容修正，非删守卫，MIN_GUARDS 不变） - 实测 UI 契约 24/24 全绿	2026-10-09 22:46:32 +08:00
WorkBuddy	2d60f7899f	docs(audit): ZC-MM-001 红娘角色权限差距审计报告 ... - 基准：《善缘丹阳 V1.1 红娘角色权限正式决策与开发规则》（DEC-MATCHMAKER-001~006 全部 LOCKED，A1/B1 已确认） - 审计范围：backend matchmaker/referral/audit/security/auth、Flyway V001~V052、 admin-web 红娘页面、现有测试、治理文档；全部结论带文件:行号证据 - 核心结论：A1 分配关系未建模（分配=工单指派）、claim/followup/complete 无归属校验、 /pending 全局队列对全体红娘可见、无红娘组长角色、模块内越权拒绝不落审计 - P0×5 / P1×6 / P2×6 差距清单 + 可复用模块（CounselingService INV-012 范式、 DataScopeGuard、recordSensitiveAccess）+ ZC-MM-002~007 实施顺序建议 - 首次建立 docs/audits/ 目录	2026-10-09 22:46:32 +08:00
WorkBuddy	f76bda1efa	fix(miniapp): 开发态 API base URL 由 localhost 改为 127.0.0.1 ... - 规避模拟器 localhost→::1 的 IPv6 解析歧义导致的 ERR_CONNECTION_REFUSED （onLaunch 全量启动拉取 /app/config 失败后不自动重试，热重载不重跑） - 生产 base 不变；仅 env.ts/env.js 的 isDev 分支	2026-10-09 22:46:31 +08:00
WorkBuddy	4edb7619bc	fix(admin-web,db): 红娘菜单权限码对齐后端真实码 + 红娘角色授权 ... 前端菜单/路由守卫用 referral.manage、matchmaker.service.view，但后端 permissions 表不存在这两个码（referral 控制器要 matchmaker.service、红娘控制器要 matchmaker.view/service/assign）。visibleNavigation 据此把「公益红娘」「红娘服务」 两个菜单对**所有角色（含 super_admin）隐藏**。 - admin-web: MainLayout.vue（菜单 + 角色名判定）、router/index.ts（路由 meta）、 stores/auth.ts（DEV 预览角色）三处对齐为后端真实 authority 码。 - db: 新增 V052 迁移，将 matchmaker.view/service/assign 授予 matchmaker 角色 （005），修复「角色定义!=可用」同族缺陷；幂等 ON CONFLICT DO NOTHING。 - 重建 danyang-admin-web 镜像并重新部署；运行时验证 wanghongniang 登录返回 [matchmaker.assign, matchmaker.service, matchmaker.view]，两菜单可见。 v1.1.1	2026-10-09 19:33:40 +08:00
WorkBuddy	dfb74f3386	fix(backend): 修复审核决策请求体契约不一致导致的 400 ... 审核操作统一发送 {comment, reasonCodes[]}（数组），但 ReviewController 的 approve / need-evidence / approve-local-eligibility / reject-local-eligibility / evidences/{id}/access 将 @RequestBody 声明为 Map<String,String>，数组值无法反序列 化成 String，Jackson 抛 HttpMessageNotReadableException，经 GlobalExceptionHandler 映射为 400「请求体格式错误」。 - 5 处 @RequestBody Map<String,String> 改为 Map<String,Object>，comment/purpose 读取加 (String) 强转（与原本正确的 needEdit/reject 一致）。 - 新增回归守卫 ReviewControllerRequestBodyContractTest（standalone MockMvc + GlobalExceptionHandler + 自定义 @AuthenticationPrincipal 解析器），注入前端真实 载荷 {comment, reasonCodes:[]} 断言 200；直接 new 控制器测不到 HTTP/绑定层缺陷。 - 接入后端契约门禁 scripts/run-backend-contracts.mjs（CURATED 13 -> 14）。 - 负向注入已自证判别力：临时改回 Map<String,String> 精确判红 400，恢复后 5/5 绿。	2026-10-09 19:33:16 +08:00
WorkBuddy	9fc3385d6c	feat(ci): 新增后端契约门禁 scripts/run-backend-contracts.mjs 并接入 CI ... 与 scripts/run-ui-contracts.mjs 同级：固化一组关键后端回归/契约测试 （含 v1.1.0 修复的 3 个回归测试 + JwtAuthFilter Cookie 兜底 + 核心不变量）， 先校验测试源文件存在性下限（防改名/删除后门禁假绿），再用 mvn test -Dtest 真跑并解析 surefire 汇总。在 backend job 的 mvn verify 之后执行，复用已 编译产物与依赖缓存，开销极小。同步更新 CODE_REVIEW_STANDARDS.md 门禁说明。	2026-09-30 16:21:25 +08:00
WorkBuddy	c1c75edc55	fix(backend): 修复 v1.1.0 引入的 4 项后端测试失败 ... 上一轮 v1.1.0 修复从未真正运行过后端测试，本次接入后端契约门禁前 全量 mvn verify 暴露 4 处缺陷： 1. PhotoService.confirmDirectUpload：countActiveProfilePhotos 返回 long， 窄化赋值给 int sortOrder 导致整个后端编译失败（全量测试 0 跑）。 2. OperatorAuthController 直接引用 JwtTokenService 计算 Cookie max-age 并在 logout 解析 JWT，违反 PrincipalInjectionContractTest 契约（控制器不得 解析/引用 JWT 工具）。改为由 OperatorCookieWriter 持有 TTL、logout 从 SecurityContext 的 OperatorPrincipal 取 operatorId。 3-4. AuthServiceRefreshTtlTest 与 JwtAuthFilterTest 的 UnnecessaryStubbing： 移除未被调用的 getExpirationMs() / validateToken("bad-cookie") 桩。 全量 mvn verify：809 测试 0 失败 0 错误（3 跳过）。	2026-09-30 16:21:16 +08:00
WorkBuddy	47cccc9ca5	test: 补 v1.1.0 修复的回归测试 ... - RealIdentityVerificationProvider: 伪造证件校验位拦截、配置缺失 fail-fast、第三方 fail-closed - AuthService: 钉死刷新 Token Redis TTL 用 getRefreshExpirationMs（14 天）而非 access*2（4 小时） - PhotoService: 直传落库 + 归属/存在性护栏（修复「传了白传」） - JwtAuthFilter: 管理端 HttpOnly Cookie（dy_op_at）兜底鉴权 + 头优先于 Cookie - miniapp profileLabels: 枚举码→中文映射不退化（serviceTypeLabel / labelOf）	2026-09-30 14:05:48 +08:00
WorkBuddy	5c97c57c76	Merge branch 'main' of http://120.27.207.134:13000/admin/danyang-match ... # Conflicts: # README.md	2026-09-30 13:44:13 +08:00
WorkBuddy	ca0db57f24	chore(release): 冻结 v1.1.0 版本 ... - 同步版本号：VERSION / backend pom / admin-web / miniapp 均升至 1.1.0 - 合并本轮代码审查修复（详见 docs/CODE-REVIEW-2026-09-24.md）： - 后端：微信登录真实实现 RealWechatLoginProvider、实名核验真实实现 RealIdentityVerificationProvider（本地强校验 + 可配置第三方 + fail-closed/fail-fast） - 照片直传落库端点 POST /me/photos/confirm（fileKey 归属校验 + 对象存在性校验后 savePhoto） - 刷新 Token Redis TTL 修正（getExpirationMs()*2 的 4h → refreshExpirationMs 的 14 天） - 管理端 token 改为 HttpOnly Cookie + silent-refresh，移除 localStorage 明文存储与 30+ 处手工注入 - 小程序：红娘接单鉴权头错位修复、serviceType 中文映射、生产域名可配置 - 隔离本地产物（.workbuddy/、*.bundle、*.dump、secrets、application-dev.yml 等已被 .gitignore 覆盖） 未验证项（打标签 ≠ 生产发布）： - 后端编译 / 单测未在本环境执行（Maven 慢、Docker DNS 受限） - 管理端 登录→刷新→登出 端到端、小程序真机走查待人工验收 - 生产部署需注入 WECHAT_APP_ID / WECHAT_APP_SECRET、VERIFICATION_API_URL / VERIFICATION_API_KEY 与小程序生产域名 v1.1.0	2026-09-30 12:10:00 +08:00
admin	8335ef780c	Initial commit	2026-09-30 12:03:52 +08:00
WorkBuddy	1ad9793ea2	重构底部导航图标：照参考图重做形状与配色 ... - 5 个 Tab 图标形状改为参考图语言：房子(首页)/爱心(找对象)/对话气泡(消息)/日历加号(活动)/人物(我的) - 配色改为参考图方案：默认态藏青蓝 #47528C、选中态玫红 #F4005A（与导航栏品牌色同系） - 同步重生成 1x/2x/3x 共 30 张透明 RGBA PNG（Edge CDP 栅格化） - app.json tabBar.color/selectedColor 对齐新配色 - 守卫 tabbar-icons.mjs 增加两态颜色与 app.json 一致性断言 - 静态预览复刻 tabBar 配色同步更新；DESIGN.md 同步	2026-09-23 16:30:32 +08:00
WorkBuddy	45e84722e1	fix(miniapp): 修复底部 tabBar 图标全部消失（开发者工具误删 app.json 专属图标） ... 根因：微信开发者工具（>=1.05.2112301）的 ignoreDevUnusedFiles 会按 WXML/JS 依赖分析过滤 "无依赖"文件。tabBar 图标仅在 app.json 中声明，不属于任何页面 WXML/JS 依赖，被误判为无用 文件从开发包剥离，导致 5 个图标全部加载失败（渲染为破图占位）。 修复： - 在 project.config.json 与 miniapp/project.config.json 的 setting 中显式关闭 ignoreDevUnusedFiles / ignoreUploadUnusedFiles（false），阻止图标被过滤。 - 同步关闭本地 gitignore 的 project.private.config.json（DevTools 运行时实际读取项）。 - 预览通道 scripts/preview-miniapp.mjs：补全 /assets 绝对路径→相对路径重写，并手动复刻 原生 tabBar（原生 tabBar 不在任何页面 WXML 中，静态预览需自行复刻）。 - 回归守卫 ui-tests/tabbar-icons.mjs 扩充为 5 段，覆盖根因（配置开关）+ 预览复刻。 - miniapp/assets/tabbar/DESIGN.md 增加根因警示，防止后续被误开开关。 验证：UI 契约 23/23 全绿（tabbar-icons.mjs 位于 [19/23]）；CDP 渲染实测 127 张图 0 破图， 5 个 tabBar 图标 naturalW=81 全部加载，选中色 rgb(233,107,107)、未选 rgb(153,153,153)， 与 app.json selectedColor/color 一致。	2026-09-23 15:57:04 +08:00
WorkBuddy	f4e00b4d95	feat(miniapp): 首页 4×2 入口宫格图标改版为参考图 2 的渐变砖 + 白色图形 ... 参考图 2 的视觉语言是「高饱和渐变圆角砖 + 白色描画图形 + 主标题/副标题双层文字」， 原实现是「浅色底砖 + 彩色线性 PNG + 单行标题」，两者差异较大，本轮按参考图重做。 - app.wxss：新增 8 个 --gradient-entry-* 渐变 token 与 --mini-entry-shadow。 白图形的判据取**非文本图形 3:1**（WCAG 1.4.11）；渐变是斜向的、图形又跨在两色之间， 故以「较亮端」为准逐色实算（3.00~3.02:1，较暗端 3.54~4.08:1），实算值写在 token 注释里。 - index.wxss：.entry-icon 由 72rpx 浅色砖改为 96rpx 渐变砖（radius 28rpx + 落影）； 图形改用 data-uri SVG 背景层（几何图形统一 24×24 viewBox），砖面走 --gradient-entry-*； 新增 .entry-sub（12px muted 副标题）；删除已无用的 .entry-icon-image。 小屏 @media(≤340px) 同步收紧，副标题不降到 micro —— micro 在本项目是「仅角标/装饰」档位， 这行字承载语义，不属于装饰。 - index.wxml：宫格项去掉 <image>，图标改为纯 CSS 砖；补 aria-label 承接图形语义。 - index.ts：tone 名与色相语义对齐（rose/orange/violet/blue/purple/pink/green/amber）， 并补 subtitle；entry 不再持有 iconAsset（图标不再是图片资源）。 - preview-miniapp.mjs：首页 mock 同步 tone/subtitle，预览才能看到真实砖面与副标题。 渲染态实测（无头浏览器 + CDP，非真机渲染）： - 8 个 .entry-item 均渲染出 label + subtitle；.entry-icon 计算样式 48×48px / radius 14px / background-image 含 svg 且为两层（图形 26px + 渐变铺满）；label 14px/600；sub 12px #7D839B。 - 证据截图：artifacts/ui-redesign/miniapp/home-entries-page.png 与 home-entries-grid-zoom.png。 门禁：UI 契约 23/23；语种审计 0 命中；tsc --noEmit 通过；wcc/wcsc 真编译 88 WXSS + 86 WXML / 0 失败。 未改（需产品确认）：第 8 项业务名仍是「善缘服务站」（参考图 2 写作「万善缘地」）， 副标题自拟为「就在身边」；渐变整体比参考图略深，以保证白图形对比度达标。	2026-09-23 15:22:23 +08:00
WorkBuddy	e740cbf403	docs(phase26): 上线清单 ⛔ 结论更正为仅第 2/5 项阻塞（第 4/6 项已闭环）+ 覆盖率数字更新 ... commit 44f75ac 已闭环推荐恒空（第 6 项）与资料/择偶条件保存失败（第 4 项）， 但清单头部 ⛔ 结论仍写着「第 2/4/5/6 项为硬阻塞」，与当前代码事实不符 ——会直接把已修项误判为阻塞，或反之让人以为清单已过时而不读。 本次更正为「第 2、5 项仍为硬阻塞」，并把已闭环项与仍阻塞项分列，避免再次过时。 同时把自动化覆盖率数字更新为当前真实值： 后端 757 → 795、UI 契约 22/22 → 23/23（新增 ui-tests/miniapp-profile-contracts.mjs）。	2026-09-23 14:46:03 +08:00
WorkBuddy	44f75acebe	fix(uat): 闭环 UAT 4 项硬阻塞（推荐恒空/保存即失败/越权端点/文档不一致）+ 小程序字段契约 ... UAT 走查（docs/UAT-WALKTHROUGH-2026-09-23.md）发现 4 项硬阻塞，本次闭环其中 3 项 （#2 微信登录、#5 照片直传不在本轮范围），并顺带修掉走查中新发现的跨端字段契约缺陷。 后端 - #6 推荐恒空：新增 MatchScoringService 作为唯一评分事实源（复用 UserPreference 既有 10 维权重，零新造常量）；RecommendationEngineService.calculateScore/generateReasons 由 桩（return 50.0）改为委托；MatchEligibilityService 3 处桩全部去雷。此前 50 < 阈值 60 → GET /recommendations 恒返回空数组。 - #4 保存即失败：updateProfile / updateBasicProfile / savePreference 改为 「无则插入、有则更新」。注意 UserPreference 实体 @TableId=id 与库主键 user_id 不一致 （V037 后补的可空列），故按 user_id 定位更新而非 updateById（后者会静默不更新）。 gender / birth_date 为 NOT NULL 且向导不采集，缺失时从已通过实名认证的 user_identities 补齐，仍缺则抛 400 业务拒绝，不再让 DataIntegrityViolationException 渲染成 500。 GET /me/profile 的 preferences 补回 5 个此前未返回字段（regionPriority / maritalPriority / minEducationCode / educationPriority / childrenPriority）。 - #8 越权端点：POST /activities/{id}/interests/confirm 不再直调「建 Match 原语」 RelationshipService.confirmActivityInterest，改为与 /activities/{id}/mutual/* 同一条 二阶段同意链路（createMutualConsent + confirmConnection），单方调用不再可能建 Match （INV-014 / INV-015）。 - #10 文档不一致：MatchmakerController 类注释更正（operator 端点实际在 /operator/matchmaker）。 - 存量 500 家族：RuntimeExceptionThrowGuardTest 的正则只认 throw new RuntimeException(， 而 17 处裸抛写作 orElseThrow(() -> new RuntimeException(...))，整体绕过守卫（CI 全绿却 仍有 500 家族缺陷）→ 17 处全量改为 GlobalExceptionHandler.BusinessException； 守卫扩为「整段代码 + 该形态」，并加自检断言防止守卫退化成恒真空断言。 小程序（跨端字段名 / 取值契约） - 字段名对齐后端规范名：hasChildren→childrenStatus、occupationCategory→occupationCode、 workRegion→workRegionCode、ageMin/ageImportance→minAge/agePriority、 educationAccepted/maritalStatusAccepted→minEducationCode/maritalStatuses。 此前字段名对不上，后端读不到 → 字段被静默丢弃。 - 取值修 4 类违反 DB CHECK（写入直接 500）的项：has→yes；high_school→senior_high、 phd→doctor（chk_profile_edu）；occasional→sometimes（chk_profile_smoking/drinking）。 - 预填改读服务端真实字段：此前读 profile.hasChildren / occupationCategory / workRegion， 而服务端返回的是 childrenStatus / occupationCode / workRegionCode → 表单永远回填不上。 - profile-confirm 完成度改为直接采用服务端 profileCompletion（AGENTS 第 9 条：DB 是 Source of Truth），废弃原先 22 条「读服务端不存在字段」的本地猜测式断言。 - 择偶条件页新增「展示形态 ↔ 服务端规范形态」适配器（toApiPayload / fromApiPayload）。 测试与门禁 - 新增 MatchScoringServiceTest、RecommendationEngineServiceBehaviorTest、 ProfileSaveUpsertBehaviorTest、ActivityInterestConfirmConsentBehaviorTest 与 ui-tests/miniapp-profile-contracts.mjs（桩 stores，真跑三个页面的事件处理与 onNext， 断言提交负载用规范字段名与枚举码）。 - MIN_GUARDS 21→23（并修正上一轮漏改：该值当时仍为 21，与守卫数不符，使「数量下限」 保护形同虚设）。 - 负向注入实测：把 #6 评分改回桩 50.0、#4 改回恒 insert、#8 改回绕开二阶段、并注入 orElseThrow 形态裸异常 → 4 个守卫全部变红（含精确定位到 RecommendationEngineService.java:282）。 - 后端：795 tests / 0 failures / 3 skipped；UI 守卫 23/23；语种审计 0 命中；tsc 通过； wcc/wcsc 真编译 88 WXSS + 86 WXML / 0 失败。 仍未修（需产品/数据决策，见报告 8.3） - regionScope 需 GB/T 2260 单值区划码，而小程序选项含「镇江其他辖区」这类非单值项 → 不臆造区划码（该约束默认 preferred 软约束，不误过滤）； - occupationPreference 后端无对应列；settlementPreference 后端无取值字典。	2026-09-23 14:33:43 +08:00
WorkBuddy	0a100548a9	docs(phase26): 上线前准备 — 13 项手动验证清单 + 冒烟脚本骨架 + STATUS 文档矛盾清理 ... - 新增 docs/PHASE26-GO-LIVE-CHECKLIST.md：上线前 13 项人工验证清单 （部署栈存活 / 微信登录 / 运营登录越权隔离 / 资料择偶条件 / 照片 SeaweedFS 直传 / 推荐匹配 / 聊天 / 活动 / 咨询 / 红娘转介 / 内容 / 管理端口径 / 合规备份）， 每项含验证方式、通过标准、负责方、关联决策与配置旋钮；自动化子集见脚本。 - 加固 infrastructure/scripts/smoke-test.sh：健康检查 + 匿名鉴权守卫(401) + 安全接口；带 OPERATOR_TOKEN/USER_TOKEN 时展开需登录链路，未提供明确打印 「需人工验证」而非假绿（沿用项目「断言≠证据/不假绿」纪律）。修掉 curl -f 在 4xx 退出码会把 000 拼到状态码后的 bug。 - STATUS.md：修正「V1.1 待实现模块」表把本地资格声明与审核误标 ⏳ 待开发 的矛盾（实际 Phase 04/05 已于 2026-09-12 复验关闭，LocalEligibilityService 已实现），与全文一致。	2026-09-23 11:57:07 +08:00
WorkBuddy	c0298c27a5	fix(miniapp): 小程序界面全量中文化，消除英文/非中文枚举码上屏 ... - 新增 miniapp/constants/profileLabels.js 作为「枚举码→中文简体」唯一字典 （婚姻/子女/学历/职业/吸烟饮酒/择偶子女/红娘状态），覆盖表单值与种子 实际值两套并集，保证详情页无论后端返回哪种码都显示中文 - 修复「择偶条件-子女」下拉英文选项（any/accept/reject→不限/可接受/不接受）， 改用 value/label 数组 + range-key="label" - 修复 recommend-card / user-card / profile-detail / profile-confirm 直接渲染 后端枚举码（educationCode/maritalStatus/occupationCode…）的问题，改由 observers 派生中文 label 上屏 - 清理残留英文文案：Required 条件→必须符合的条件、喜欢TA/向Ta→喜欢对方/向对方、 U51 服务预约→服务预约、U64 公益服务记录→公益服务记录 - 修复 7 个英文窗口标题与 3 个英文占位页正文 - matchmaker 历史服务状态消除原始码兜底，统一走字典 - 加固 scripts/audit-miniapp-language.mjs（A 整行先剥离 mustache、B 排除 bind:action 处理器、F 窗口标题、JPG/PNG 入白名单） - 新增 ui-tests/miniapp-language-contracts.mjs 语种守卫（复用审计脚本，断言 0 命中）， UI 契约门禁 MIN_GUARDS 21→22；已做负向注入验证判别力	2026-09-23 11:19:17 +08:00
WorkBuddy	1fc34f1bcd	fix(miniapp): 修复导航页与微信胶囊重合，并把首页两个栏目卡缩到 1/3 ... 问题 1：五个导航页顶部与右上角胶囊按钮（··· ⊙）重合 - 根因：自定义导航用 env(safe-area-inset-top) 取的是设备物理安全区， 在 Android 上常为 0，完全不反映胶囊位置；且右对齐元素从未为胶囊让出宽度。 - 新增 miniapp/utils/nav-metrics.js 作为唯一事实源：以 wx.getMenuButtonBoundingClientRect() 实测胶囊矩形，反推并导出四个 CSS 变量 --nav-status / --nav-h / --nav-right / --nav-top，并提供无接口时的兜底值。 - nav-bar 组件改为自行获取导航度量（attached + observer 双触发）， 标题按胶囊垂直居中并收窄 max-width；外部传参降级为兜底。 - index / discover / messages / activity / mine 五页根结点注入同一组变量， WXSS 里的 env(safe-area-inset-top)、硬编码 88rpx 与右对齐 right:0 全量替换。 问题 2：首页「善缘公益服务」「善缘安全提醒」两个栏目过宽 - 根因：封面 <image> 只声明 width 未声明 height，小程序默认按 240px 计算， 实际把卡片撑到约 480rpx 高。 - 按「整体等比缩到 1/3」重构：两栏改为 mini-card 小卡，宽度 calc((100% - 2*gap)/3)、高度写死 168rpx，封面 height:100%； 公益服务一行三卡横向排布，安全提醒为「标题小卡 + 右侧文案条」， 长文案收进详情页，安全提示原文保留。 守卫与验证 - 新增 ui-tests/miniapp-capsule-safe-contracts.mjs： A 层多机型断言导航行与胶囊垂直居中、右对齐让位、navTop 与兜底值； B 层纯函数审计五个自带导航行页面（页面清单由文件系统推导，失配直接报红）； C 层断言首页小卡宽为 1/3 且显式声明高度，并钉住旧 service-/safety- 选择器回归。 审计前剥离注释，避免守卫被自身示例文本误伤。 - 新增 scripts/audit-image-height.mjs：按属性名精确比对，审计全仓 「有 width 无 height」的 <image>，当前 30 个类 0 命中。 - 负向注入 N1~N7（含 nav-safe 未接入、旧选择器回归、极小屏幕、无胶囊兜底等） 全部被守卫咬住并 exit 1，还原后复跑通过。 - 真编译（wcc/wcsc）：WXSS 88 / WXML 86，失败 0； tsc --noEmit 通过；UI 契约门控 21/21 PASS（新增第 21 个守卫并抬高 MIN_GUARDS）。 - 渲染探针实测：单卡 213rpx x 168rpx；五页右对齐元素右缘 423~528px， 均在胶囊右缘 365px 之外。 未纳入本次提交：miniapp/project.config.json（微信开发者工具自动改写， 仅追加若干布尔开关并删掉文件末换行）与生成的预览页 artifacts preview.html （约 7900 行生成产物），以免淹没代码评审视线。	2026-09-23 09:55:40 +08:00
WorkBuddy	2c325136ab	fix(miniapp): 修复 WXSS 通配符导致编译失败，并把 WXSS 校验升级为真编译 ... 问题 - v2 设计收敛在 app.wxss 新增 `.tap-gap > * + *`。WXSS 不支持通配符 `*`， wcc/wcsc 编译期直接报 `error at token '*'`，整个小程序编译不过。 - 更值得警惕的是当时 19 个 UI 契约守卫全绿：静态守卫刻意只扫 `miniapp/components/`（page 的 wxss 允许标签选择器，套用会误报）， app.wxss 落在扫描范围外，且判据里根本没有通配符这一项。 修复 - 移除 `.tap-gap > * + *`。复检 v2 新增的 .tap-min / .tap-gap / .focusable / .pressable 四个工具类全仓零引用（等价能力已各自写在组件样式内，如 button/index.wxss 直接用 `min-height: var(--tap-min)`），且 `.focusable:focus` / `.pressable:active` 在 view 上 不生效（小程序须用 hover-class），属"写了等于没写"，故整块移除，只保留 token。 - 修掉同块注释里的嵌套 `/* */`：内层结束标记会提前终止外层注释，其后的文字会被 当成真实样式解析。该约束已写进注释，防止后人再踩。 守卫加固 - scripts/lib/wxss-selectors.mjs * 新增 findUniversalSelectors（通配符判据，排除 `*=` 属性匹配符与注释内星号） * 新增 findNestedComments（注释嵌套判据） * 修 stripComments：原实现用等长空格替换，把注释内的换行也吃掉，导致报错行号 整体偏移（实测偏差 68 行）；现保留换行，并在定位时跳过选择器前的注释占位空白 - ui-tests/wxss-component-selector-contracts.mjs * 第 1 级：miniapp/components/（原判据，保留） * 第 2 级（新增）：全量 miniapp/**/*.wxss，覆盖 app.wxss 与 pages * 第 3 级（新增）：注释嵌套 * 三级各自带正/反自检样例 新增 - scripts/miniapp-compile-check.mjs：直接调用微信开发者工具内置的 wcc/wcsc 做真编译预检 （wcsc 单独调用不解析 @import 相对路径，脚本会先内联再编译）。 CI runner 无该工具时输出 SKIPPED 并退出 0；刻意不挂进 run-ui-contracts —— 一个在 CI 里 什么都不做的守卫被计入"全绿"，正是本项目反复强调的假绿。CI 拦截由上面的静态守卫承担。 验证（均实际执行） - node scripts/miniapp-compile-check.mjs → WXSS 88 个 + WXML 86 个，0 失败 - 负向注入：把 `.tap-gap > * + *` 改回去 → 预检 FAIL(exit 1)，报错与用户原始报错逐字一致 `app.wxss(364:12): error at token '*'`；已还原并复测通过 - node scripts/run-ui-contracts.mjs → 20 / 20 PASS	2026-09-23 08:25:11 +08:00
WorkBuddy	631e3000d3	管理端：设计系统 v2 收敛 + 修复漏斗卡恒为 0 的响应式缺陷 ... ## 一、设计系统收敛 - theme/index.css 重写为 token 底座：品牌三级、语义五组、文字四级、 边框/背景/圆角/阴影/动效/热区/排版刻度 - 修复 Element Plus 派生色阶残留：--el-color-*-light-N 是 SCSS 编译期静态生成， 只覆盖基色不会带动它们 —— 数据统计页实测 133 处元素仍在用 EP 默认调色板 （其中主色蓝 8 处）。已按 mix(#fff,base,N*10%) / mix(#000,base,20%) 补全全部档位 - 新增 src/theme/tokens.ts：模板里 :style 需拼 8 位 hex（color + '15'），用不了 var()， 故以 TS 常量镜像色值；守卫会双向校验它与 index.css 同名取值一致 - 24 个 .vue 收敛：硬编码色值 97 处/67 种 → 0；越界字号 88 处（最低 9px）→ 0； 非法字重 650×6 → 0；触摸目标 17 处 <44px → 全部 ≥44px - 对比度：text-tertiary 3.54:1、warning 2.33:1、coral 作文字 3.14:1 → 全部 ≥4.5:1 - 新增守卫 ui-tests/admin-design-tokens.mjs（含 WCAG 对比度实算） ## 二、修复既有功能性缺陷：数据统计页漏斗卡与安全卡恒显示 0 - 现象：同一张卡片里，上方漏斗数字全是 0，下方汇总表却是 12846/9217/8462/3812， 界面自相矛盾 - 根因：funnelStages / matchStages / safetyCards 是普通数组（const x = [...]）， loadFunnel() 直接改元素属性，模板读的却是同一个数组 —— 非响应式写入不触发重渲染。 同页凡走 ref 的值（汇总表、V11 区块）全部正常，规律清晰 - 修法（按根因）：三个集合改为 computed() 从既有 ref 派生，卡片与汇总表因此同源， 结构上不可能再出现「同一份数据的两处展示对不上」；另把 loadFunnel() 内遮蔽 颜色助手的局部变量 const token 改名 authToken - 该缺陷无 TS/lint/构建报错，前 18 个守卫全绿也抓不到 —— 只有真跑起来看渲染结果才暴露 - 新增守卫 ui-tests/admin-reactivity-contracts.mjs： ①非响应式状态（普通声明 + 被当状态写 + 出现在模板里；未被写过的静态常量清单合法） ②数据统计页同源契约 ③颜色助手遮蔽 ## 验证 - UI 契约门禁 20/20 PASS（MIN_GUARDS 18→20） - 负向注入 3 例全部 FAIL(exit 1)，还原后复跑 exit 0（证明守卫有判别力） - vue-tsc --noEmit exit 0 - vite build 成功（17.74s） - 渲染态实测（Edge 无头 + CDP 读渲染后 DOM，同一 mock、同一路由，只差代码）： 修复前漏斗卡/安全卡全 0、比率全 '-' → 修复后 12846/9217/8462/3812/ 48210/51236/7420/4380/1926/1284，安全卡 17/214/23/9 交付物：artifacts/admin-design-v2-preview.html	2026-09-23 01:06:57 +08:00
WorkBuddy	269adf1fed	小程序端：设计系统收敛与排版层级修复 ... 问题：88 个 wxss 里散落大量硬编码颜色/字号/字重，无法统一调整； 部分正文对比度不达 WCAG AA（4.5:1）；组件触摸目标偏小。 改动： - 硬编码颜色收敛到语义 token（颜色统一走 design token，不再散落字面值） - 修正全站字号阶梯：正文 ≥12px、角标 ≥11px；字重只用 400/500/600/700 - 组件触摸目标提升到 ≥44px，并补交互反馈 - 首页补氛围层次、强化排版层级 验证（本轮实测）： - UI 契约门禁 18/18 PASS（含 wxml 结构、wxss 组件选择器、token 显式值断言） - 声明级体检 88/88 通过（全部 wxss 声明合法） 交付物：artifacts/miniapp-design-v2-preview.html	2026-09-23 01:06:46 +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	2162612892	fix(service-appointment): 状态冲突/越权改为 4xx，修并发下 500 与弱断言漏判 ... CI E2E (live stack) 在 main@63c18d8 上失败：test_appointment_concurrent_safety 并发「用户取消」与「运营确认」得到 [200, 500]。根因是 ServiceAppointmentService 四处状态/权限守卫抛裸 RuntimeException，GlobalExceptionHandler 无对应映射， 只能兜底成 HTTP 500 —— 「预约不存在」「状态不允许」「越权」被报成服务端故障。 改动： - ServiceAppointmentService：四处守卫改用 BusinessException + ApiResponseCode （不存在→404 NOT_FOUND，越权→403 FORBIDDEN，状态冲突→409 REDUNDANT_OPERATION）。 - ReferralService.confirmReferral：同一家族的四条守卫同样收敛（预约/报名的 不存在、越权、非转介类型）。 - tests/e2e/service_appointment_test.py：把 3 处 `!= 200` 的弱断言收紧为 4xx。 弱断言会把 500 当成「越权被拒」放行 —— 这正是该缺陷长期未被发现的原因， 此前只有并发用例的 `< 500` 断言咬了它一口。 - ServiceAppointmentOwnerGuardTest：新增「终态不可再确认/取消」「预约不存在」 用例，并把越权断言从 RuntimeException 收紧到具体业务码（403）。 验证： - 定向后端测试 35 passed（ServiceAppointment* / MatchmakerReferralPhase13Test）。 - 本机真实栈（重建 backend 镜像）：service_appointment_test.py 8/8、全量 E2E 65 passed。 - 负向注入（把守卫改回裸 RuntimeException）：2 例精准变红，工作区哈希前后一致。	2026-09-22 19:36:59 +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	79ed89c89f	Merge seaweedfs-pilot: 对象存储从 MinIO 迁移到 SeaweedFS 4.47，并修复 presigned URL 直传 host 断链 ... - 对象存储后端由 MinIO 换成 SeaweedFS 4.47（path-style 寻址，filer 预建 public/private 桶） - 新增 storage-init 容器幂等建桶；三套 compose（dev/staging/prod）相应改造 - 修复 presigned URL：签发改用「对外可达 endpoint」的独立 AmazonS3 客户端，避免客户端直传被 403 断链 - 新增对象存储真实链路探针（判据，非 pytest 用例） PR #1，GitHub Actions 7/7 全绿（含真实栈 E2E 65 passed）。	2026-09-22 17:23:13 +08:00
WorkBuddy	dc0a62d4c5	fix(storage): presigned URL 改用对外可达 host，修复客户端直传断链 ... SeaweedFS 换存储后 MINIO_ENDPOINT 变为 seaweedfs:8333（容器名）， PhotoService 生成的 presigned URL 把该 host 直接下发给客户端， 客户端不在 docker 网络内无法解析 → 直传/直链全断。 - S3Config：新增 amazonS3Signer Bean，指向 object-storage.public-endpoint （缺省回退内网 endpoint，向后兼容）。独立签名端是因为 SigV4 签名覆盖 host 头，事后改 URL 字符串会让签名失效返 403；独立客户端让签名 host 与客户端实际命中的 host 天然一致。 - PhotoService：去掉 @RequiredArgsConstructor，改显式 @Qualifier 构造器； getUploadToken / getSignedUrl / getSignedUrlForAuthorizedReview 三处 presigned 生成改用 amazonS3Signer；putObject 服务端上传仍走内网 amazonS3。 - application-docker.yml / application-dev.yml：public-endpoint 读 MINIO_PUBLIC_ENDPOINT（缺省回退 MINIO_ENDPOINT）。 - 三套 compose：注入 MINIO_PUBLIC_ENDPOINT （dev localhost:8333 / staging localhost:8334 / prod 留作单一旋钮）。 - 测试：PhotoServiceTest 新增嵌套 PresignedUrlPublicHostTest，用真实 AmazonS3 客户端（仅本地签名不联网）断言下发 URL host 为对外地址、 不含 seaweedfs 容器名；同步补齐两处 5→6 参构造调用。 验证：本机 65 E2E 全绿 + storage_link_probe path-style 全通 + PhotoServiceTest/PhotoUploadValidationTest/PhotoLimitGuardTest 19 例单测全绿。 顺带：backend/maven-settings.xml 的 Central 兜底由投毒的 repo1.maven.org 改为可达的 repo.maven.apache.org，使本机镜像构建可走 aliyun 主源。	2026-09-22 17:10:40 +08:00
WorkBuddy	797b1c46cf	refactor(storage): 对象存储从 MinIO 换成 SeaweedFS（钉 4.47） ... 动机：MinIO 的 GitHub 仓库已于 2026-02 归档，不再产出安全补丁，已累积多个 CVE 且不修；本项目存身份证 / 实名材料 / 用户照片，无人修 CVE 才是真正驱动因素 （Docker Hub 下架只是表象，quay.io 仍在提供）。 变更： - 三套 compose（dev / staging / prod）的 minio 服务替换为 seaweedfs 4.47： 覆盖 entrypoint 渲染 -s3.config 注入 identity（S3 网关默认不鉴权，必须显式开启）， -volume.max=100 解除第二个 bucket 写入时的 InternalError。 - 新增一次性 storage-init 容器，经 filer 接口预建 public / private 桶 （SeaweedFS PutObject 到不存在的 bucket 直接失败；全仓库原无任何 createBucket）。 - S3Config 显式开启 path-style：AWS SDK v1 默认 virtual-host 会把 bucket 拼进 主机名，容器名在 DNS 中不存在必然失败（本机有 http_proxy 时易误判为 502 拒绝）。 - ci.yml：镜像校验与起栈步骤改为 seaweedfs + storage-init。 - 运维脚本 health-check.sh / run-uat.sh 的 MinIO 探针改为 SeaweedFS （S3 网关开启鉴权后匿名根请求返回 403，200/403 均算存活）。 注：path-style 与建桶属换存储的必要项；presigned URL 的 host 须对外可达这一 既有缺陷（原 minio:9000 直发客户端不可达）留待下一轮「改缺陷」处理。	2026-09-22 14:26:48 +08:00
WorkBuddy	aa1114338e	新增对象存储真实链路探针（判据，非 pytest 用例） ... 背景：E2E 全套 65 例对对象存储零覆盖，而 generatePresignedUrl 只是本地 签名、不访问存储，因此"签名接口返回 200"无法证明对象真能存进去。 实证（2026-09-22）：MinIO 的 /data 下只有 .minio.sys，无任何 bucket； mc cp 到 private 报 `Bucket 'private' does not exist`。全仓库零建桶代码、 零初始化脚本 —— 真实上传链路在当前配置下必然失败，而所有测试仍全绿。 本探针覆盖 PhotoService 的真实路径并要求字节级一致：服务端直传、 presigned PUT（客户端直传）、presigned GET，并同时验证 path / virtual-host 两种 addressing style。支持 --no-create-bucket 负向模式，用于证明判据 有判别力而非恒绿。 不在 CI 运行：依赖 boto3 + requests，不进 tests/e2e/requirements.txt。	2026-09-22 12:26:37 +08:00
WorkBuddy	7186a6b694	fix(infra): minio 镜像钉回确定版本（依据 CI 实测输出） ... 上一轮为让 CI 先跑通，minio 临时改用 quay.io 的 latest 滚动 tag，并在 e2e job 里 加了一步打印实际版本。该步骤的实测输出为： minio version RELEASE.2025-09-07T16-13-09Z (commit-id=07c3a429bfed…) 即 latest 当前正指向这个版本 —— 与本仓库原先在 Docker Hub 上钉的 tag 完全一致。 据此把三处 compose（本地 / staging / prod）统一钉死为 quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z，恢复「可复现」这一原则： 日后即使 quay 上的 latest 滚动到别的版本，本配置也不受影响。 保留 e2e 中「校验钉版镜像可拉取并打印版本」这一步 —— 镜像拉取失败在 compose up 里会埋进几十行输出，独立一步能在起栈前秒级暴露「上游镜像下架」这类外部依赖失效。 上一轮结果：7 个 job 全部 success，GitHub Actions 首次跑绿。	2026-09-22 11:16:37 +08:00
WorkBuddy	4c98170107	fix(infra): minio 镜像源从 Docker Hub 迁到 quay.io（上游已下架，本地/CI/生产均受影响） ... E2E job 日志： pull access denied for minio/minio, repository does not exist 问题不在 tag 本身，而在**整个仓库已从 Docker Hub 移除**：MinIO 自 2025-10 起停止 发布容器镜像（改为仅源码分发），其 GitHub 仓库于 2026-02 归档，Docker Hub 上 minio/minio 与 minio/mc 现均返回 404；quay.io/minio/minio 仍在提供镜像。 本机此前是用 quay.io 的镜像重打 tag 顶替才跑通的（见 known-risks KR-01）， 但那只是**本地绕过**、没有同步回仓库，于是「本地能起栈、CI 拉不到」。 现在三处 compose（本地 / staging / prod）统一改为 quay.io， 让本地、CI 与生产拉取同一个镜像。 这不只是 CI 问题：prod 与 staging 同样引用了已下架的仓库，是真实的部署阻塞 —— 也就是说现有配置下，新环境的生产部署根本起不来。 已知偏离：使用 latest 而非钉版。本机无法访问 quay 的 tag API 去核实某个具体 RELEASE tag 是否仍存在（quay 上的镜像已冻结，最后发布为 2025-09）。 e2e job 新增一步打印实际拉取到的版本，日后即可据此钉版、恢复可复现性。 长期风险：quay 上的 MinIO 镜像同样可能下架，届时需自建镜像或迁移到其他 S3 兼容存储 —— 「依赖第三方镜像」本身就是一条外部依赖风险。 上一轮修复已见效：backend / admin-web / ui-contracts / miniapp / test-shell-guard / migration 六个 job 均通过，本轮仅剩 E2E。	2026-09-22 11:04:01 +08:00
WorkBuddy	b624c43432	fix(ci): 依据 Actions 真实日志修复三处失败（runner 无 pnpm / 门禁缺依赖 / 生产配置未入库） ... 上一轮已把 CI 跑起来并读到真实结果：7 个 job 中 Mini Program 与 Test Shell Guard 通过，Admin Web、Backend、UI Contracts 三个失败，migration 与 e2e 因依赖 backend 被跳过。本轮全部依据 Actions 原始日志定位，而不是本地推测 —— 三者都不是业务代码问题。 1. Admin Web Build：runner 已不再预装 pnpm 日志：Unable to locate executable file: pnpm runner 镜像（ubuntu-24.04 / 2.337.0）的 PATH 里没有 pnpm，而 setup-node 的 cache: 'pnpm' 在 restore 阶段就需要调用 pnpm 可执行文件，于是 job 在第一步失败、 后续步骤全部 skipped。同批的 miniapp job 没配 cache 所以正常通过，正好反向印证。 改为先用 corepack 启用并钉住 pnpm@9.15.9，store 缓存改由 actions/cache 手动配置 （此时 pnpm 才存在于 PATH）。 2. UI Contracts：门禁依赖没装 日志：Cannot find module '.../miniapp/node_modules/typescript/lib/typescript.js' phase04 守卫会用 TypeScript 编译器 API 解析小程序源码，但本 job 此前不装依赖。 本地能跑通只因为工作区早已装过；CI 的每个 job 都在独立 runner 上， miniapp job 安装的依赖不会共享过来。补上 npm install，并修正 workflow 中 「零 npm 依赖、故无需装依赖」的错误注释 —— 与实际不符的声明本身就是缺陷来源。 3. Backend：断言了一个永远不会入库的文件 日志：DeploymentTests.testDockerComposeProdExists 期望 true 实际 false infrastructure/docker-compose.prod.yml 被 .gitignore 列在 「Secrets and certificates」段而排除出版本控制，但这是**误分类**： 该文件不含任何明文密钥，敏感值全部走 ${VAR} 注入、db 密码走 Docker secrets， 文件头注释本身也写着「敏感信息通过 .env 文件注入，不进 Git」。 后果是该测试「本地恒绿（文件在工作区）、CI 恒红（checkout 拿不到）」， 且从本地永远发现不了。现修正 .gitignore 把它纳入版本控制； 真正的密钥仍由 secrets/、certs/、backups/ 等规则挡住。 修复后，此前因 backend 失败而被跳过的 migration 与 e2e 两个 job 也会真正跑起来。	2026-09-22 10:54:24 +08:00
WorkBuddy	c6b48d5d91	fix(ci): 修复三处必致 CI 变红的工程缺陷 ... 排查 Phase 23 收尾项「 GitHub Actions 从未跑绿」时，逐个在本地复刻 CI 的每个 job， 发现三个与业务代码无关、但足以让流水线恒红的缺陷。 1. 依赖锁文件被排除出版本控制（admin-web job 必红） .gitignore 原先同时忽略 pnpm-lock.yaml 与 package-lock.json，导致 CI checkout 后 admin-web 根本拿不到 lockfile。pnpm install --frozen-lockfile 在缺 lockfile 时不是降级重试、而是直接报错，因此该 job 必然失败； miniapp 的 npm install 也因失去锁文件而版本浮动。 现在按包管理器逐一放行：admin-web 走 pnpm、miniapp 走 npm。 admin-web/package-lock.json 仍保持忽略 —— 同一目录并存两把锁会让两种包管理器 各按自己的锁安装，漂移时彼此看不出问题。 2. admin-web/pnpm-workspace.yaml 内容残缺（任何环境下都装不上依赖） 该文件原先只有两行 allowBuilds（esbuild / vue-demi），既无 packages 声明也未写取值。 pnpm 一旦检测到工作目录下存在 pnpm-workspace.yaml 就强制进入 workspace 模式， 随后因读不到 packages 而报 packages field missing or empty。 本仓库 admin-web 只有一个包，现显式声明单包 workspace，并补出 esbuild 与 vue-demi 的 build 白名单 —— 二者 postinstall 是必需步骤： esbuild 下载平台原生二进制、vue-demi 生成 Vue 版本桥接。 3. CI 使用 runner 预装的 pnpm，版本会漂移 pnpm 9 与 10 对「是否默认放行依赖 build 脚本」的语义相反，而上述 allowBuilds / onlyBuiltDependencies 恰好是版本敏感配置项。 runner 镜像升级后 会出现 install 能过、build 变红、且错误信息不指向真正原因的情况。 现钉住 pnpm@9.15.9，使 CI 语义不再随 runner 变化。 本轮同时在本地复刻了 CI 的其余 job： - migration job 的迁移序列校验：51 个迁移文件，版本 1 至 51 连续且唯一，通过。 - test-shell-guard：18 个 Python 文件未发现 skip / pass 空壳，通过。 - miniapp job 的 npm install 加 tsc --noEmit：通过。	2026-09-22 09:40:44 +08:00
WorkBuddy	8bd1ab804a	fix(organization): 修复创建机构审计缺操作人；补全机构修复的验证并部署 Docker 测试环境 ... 一、机构审计归属缺陷（本轮活栈验收中新发现） - 现象：audit_logs 中 CREATE_ORGANIZATION 的 operator_id 7/7 为 NULL， 而 DISABLE/ENABLE_ORGANIZATION 均正确记录操作人。审计不可归属 = 无效审计。 - 根因：OrganizationController.create 持有 @AuthenticationPrincipal OperatorPrincipal， 却只把 params 传给 Service，未透传 principal.id() → saveAuditLog(null, ...)。 - 修复：createOrganization(params, operatorId) 签名透传；新增测试断言 createOrganizationRecordsOperatorInAuditLog 长期守卫。 - 复验：新写入的 7 条 CREATE 审计全部带 operator_id，旧 14 条仍为 NULL（前后对照清晰）。 二、补全 rc.22 的验证缺口（此前记为「已修复待验证」） - 全量回归 757 / 0 / 0 / 3，BUILD SUCCESS，108 个测试类，6:44（基线 741 + 新增 16）。 - 负向注入：ORG_STATUS_ACTIVE 改回 "normal" → 16 例变 3 失败 + 7 错误 （守卫三条断言各自命中 + 服务侧 7 例被 H2 CHK_ORG_STATUS 拦下）。 注入采用「仓库只读挂载 + 容器内副本改写」，工作区哈希前后一致，源码零污染。 - 活栈实测（Docker 全栈）：创建/停用/启用均 2xx、非法输入 400、不存在 404、全程零 5xx（15/15）。 - 对已部署栈 pytest tests/e2e → 65 passed。 三、Docker 测试环境部署与工具链固化 - 测试镜像 danyang-match-backend-test 与命名卷 danyang-m2-cache 因 Docker Desktop 重装丢失， 构建定义此前是临时产物 → 落盘为仓库资产 infrastructure/test-toolchain/Dockerfile。 - 本地栈统一使用 docker compose -p danyang（原项目名 infra 与另一项目撞名， 其 --remove-orphans 会误删本项目容器；已确认邻项目数据无丢失，见 known-risks KR-09）。 四、UI 门禁脆弱性修复 - ui-document-baseline-contracts.mjs 解析 docker-compose.staging.yml 时报假红 （「守卫自身失效」）；真因是该文件为 CRLF 而守卫正则要求 \n 紧随 container_name 之后 （prod.yml 是 LF 所以此前能过）。解析改为行尾无关，真实断言未削弱。门禁 18/18。 五、文档 - STATUS.md 新增 rc.23 并将 rc.22 由「待验证」订正为「已验证关闭」。 - 实施计划附 B.1、PROGRESS-ASSESSMENT-2026-09-21.md 同步订正。 - known-risks.md：KR-07 解除（Docker 已恢复）、KR-01/KR-06 按复测订正， 新增 KR-08（Docker Hub 域名 DNS 被投毒，改用国内镜像源绕行）与 KR-09（compose 项目名撞名）。 验证状态：全量回归 757/0/0/3 全绿；UI 契约门禁 18/18；对已部署栈 E2E 65/65； 负向注入可变红；工作区哈希未被注入过程污染。 未验证：GitHub Actions 首次真绿（仍未推送，见 KR-06）。	2026-09-22 00:46:10 +08:00
WorkBuddy	c195133680	fix(organization): 机构三处写操作必崩 500 修复 + type 白名单 + 测试库约束补齐 ... 缺陷本体（实施计划附 B.1，2026-09-19 登记并实测复现，本轮处置）： OrganizationService 的 createOrganization / disableOrganization / enableOrganization 分别写入 Constants.ACCOUNT_STATUS_NORMAL("normal") 与 ACCOUNT_STATUS_SUSPENDED("suspended")。 那是 users.account_status 的取值，而 organizations.status 的 CHECK 白名单 （V001 chk_org_status）只有 ('active','inactive') → 三个写操作全部违约， 生产必崩 PSQLException violates check constraint "chk_org_status" → HTTP 500。 二阶影响：activities.organizer_org_id NOT NULL ⇒ 无机构即无法新建活动， 运营端「建机构 → 建活动 → 报名 → 互选」链路的第一环是断的。 修复： - Constants 新增 ORG_STATUS_ACTIVE / ORG_STATUS_INACTIVE（独立于 users.account_status， 附注释说明两者白名单不同，禁止互相复用） - 三处状态值改为 ORG_STATUS_ACTIVE / ORG_STATUS_INACTIVE - 新增 OrganizationService.ALLOWED_TYPES + type 白名单前置校验： 非法值返回 VALIDATION_ERROR(400)，不再打到 PostgreSQL 才 500 - 「机构不存在」由裸 RuntimeException(→500 SERVER_ERROR) 改为 NOT_FOUND(404) - 异常类型统一为 GlobalExceptionHandler.BusinessException —— 独立类 shared.exception.BusinessException 没有 @ExceptionHandler，抛它仍会退化成 500 根因第三重盲区（缺陷长期隐身的直接原因）： schema-h2.sql 的 organizations 表此前未复刻这两条 CHECK，H2 上写 'normal' 畅通无阻。 已补齐 chk_org_type / chk_org_status 及 NOT NULL / DEFAULT，与生产 DDL 逐值一致。 新增守卫： - OrganizationConstraintParityTest：生产迁移 DDL ↔ 测试库 schema ↔ 后端白名单 ↔ Constants 四方比对 + 解析器自检（虚构约束名必须解析失败，防断言静默永真）。 其中 status DEFAULT 的解析必须先把范围切到 organizations 建表块 —— 全文件搜索会 误命中 users.account_status（本轮自检脚本实测踩到并修正该缺陷）。 - OrganizationServiceTest：走真实 DB 的 H2 集成测试，9 用例覆盖创建/停用/启用/ 停启往返/六个合法 type/非法 type/名称空白/404 语义，断言落库值而非返回值。 ⚠️ 未在本机运行测试：本轮探测确认本机无 Docker、无 JDK，wsl.exe 被安全策略阻止 （与 known-risks.md 的 WSL/Docker 故障一致），mvn -o test 与负向注入均无法执行。 已用等价正则的独立脚本验证守卫判别力与两处 DDL 一致性（PASS，脚本留痕 .workbuddy/_verify_org_guard.py）。 补跑全量回归 + 负向注入前，本项记为「待验证」，不得计入已验收。	2026-09-21 20:34:30 +08:00
WorkBuddy	60c591fc68	V1.0.1 纠偏 DoD 补齐：canonical key 字面化（V051+KEY_ALIASES）+ 照片并发突破实测（锁用户行+锁后计数）+ AGENTS 规则27 + known-risks ... 按文档 DoD/约束逐条复查后补齐的差距（承接 438b38d 主体纠偏）： - CFG-001 字面化：FeatureFlagConfig.KEY_ALIASES（identity.liveness.enabled / 遗留 livenessVerification.enabled → 实现字段 livenessEnabled，读兼容）+ Controller PUT/DELETE 落库归一到 canonical 键 + V051 迁移（删遗留键、写入 identity.liveness.enabled=false）； MigrationValidationTest 基线 50→51。 - PHOTO-004 真实并发突破：新增 PhotoLimitConcurrencyGuardTest（3 线程 H2 并发冲顶）—— 实测咬住「锁照片行+读时计数」在 H2 MVCC 快照漏读、3/3 全成功突破上限的缺陷； 并发控制改为锁用户行（UserMapper.lockUserRow FOR UPDATE）+ 锁后新语句 COUNT， 0 张照片亦有锁可加（补首张并发缺口）；UserPhotoMapper 计数方法同步替换。 - FF-LIVENESS-003 + canonical 持久化：FeatureFlagPersistenceGuardTest +4 （canonical 加载 / 遗留别名读兼容 / PUT 落 canonical 键 / 切换即生效无旧缓存）、 FeatureFlagControllerTest +3（canonical/legacy/reset）。 - 文档同步：AGENTS.md 规则 27（配置治理纪律）；docs/governance/known-risks.md （7 项含本机 WSL/Docker 故障 KR-07）；config-register / open-questions 更新 canonical 口径； STATUS rc.21 行补 ⑥⑦⑧。 全量回归 741/0/0/3（基线 717 + 25 新增 − 1 删死测试，宿主机 JDK21+Maven 3.9.9 实测， 本机 WSL/Docker 引擎故障期间）；UI 契约门禁 18/18	2026-09-21 11:13:14 +08:00
WorkBuddy	438b38d121	V1.0.1 配置与规则纠偏：照片上限配置化+强校验 / 活体开关闭环 / 推荐阈值快照+规则版本化 / governance 三表+漂移审计 ... 根治三类工程治理问题（技术默认值≠产品规则、配置存在但未闭环、文档代码漂移）： - PROFILE-001：profile.photo.maxCount（默认6未确认）+ ProfilePolicy + 服务器端 FOR UPDATE 并发强校验（PHOTO_LIMIT_EXCEEDED，拒绝先于 S3 不留孤儿）+ 前端 mergeAppConfig 嵌套键修复 - CFG-001/IDENTITY-001：IdentityPolicy + GET /verification/liveness-status 真实判定点 （默认关不阻断，开则 enhancedVerified 变化，消除假开关）+ 删死 seed livenessVerification.enabled - MATCH-001：阈值60定为技术默认（消解 PENDING 矛盾）+ V050 recommendation_records.threshold_snapshot 规则版本化 + 删死重复配置类 MatchConfig - DOC-001：新增 docs/governance/（config-register/open-questions/decision-register/ hardcoded-rule-audit/config-drift-audit） - TEST-001：新增守卫 PhotoLimitGuardTest(8)/IdentityLivenessGuardTest(5)/ RecommendationThresholdSnapshotGuardTest(4)，均经负向注入可红 全量回归 733/0/0/3（基线717+17新增-1删死测试）；UI 契约门禁 18/18；STATUS 升 rc.21	2026-09-21 02:05:15 +08:00
WorkBuddy	b60c1ffb71	docs: 数据保留 36 个月政策定稿 + 09-20 收尾状态 —— STATUS 版本演进表重排至 rc.20，隐私政策 §3.3/PIA §8 修订，UAT V1.1 用例 46 条（9 角色×7 路径），E2E 65/65 本机模拟 CI 登记	2026-09-20 22:30:44 +08:00
WorkBuddy	6e76e2f2ea	feat(account): 数据保留流程落地（36 个月下限，V049）—— closed_at + 人工审核/幂等匿名化/审计 + 运营端点 + 守卫 5 用例；测试库补 user_photos，MyBatis null 更新修复	2026-09-20 22:30:29 +08:00
WorkBuddy	76a152bccf	docs(status): 批 2/3 收尾完成登记 —— 全量回归 712/0/0/3 实测、权威行升级（批 1~3 done, awaiting user go）、Phase 21 遗留行清偿状态、rc.16 定稿 ... - 后端基线 700 → 712：MeStatusLocalEligibilityGuardTest(2) + 互选 expires_at 接线守卫(+2, 负向恰 2 红) + 随访审计与风险守卫(4) + 红娘注销拦截守卫(4)，全部真实落库守卫 - 批 3 仅余：数据保留流程（待产品决策）、E2E 入 CI 的 GitHub Actions 实测绿 - UI 契约门禁 18/18；本机 E2E 65 passed	2026-09-19 19:39:02 +08:00
WorkBuddy	08b9cb2468	fix(p21-2e): 红娘服务拦截接线（blocker 首次生效 + 竞态兜底）；2d 确认 Onboarding 本地资格已实现；文档回写 ... P16 遗留 2e（红娘服务拦截）： - checkCanWithdraw 硬编码 0 → 接 MatchmakerServiceMapper.countActiveByUserId（非终态口径 submitted/assigned/in_service/waiting_user，与 findActiveByOperatorAndUser 一致），blocker 首次真正生效 - notifyMatchmaker TODO 空转 → terminateActiveMatchmakerServices 竞态兜底（残留非终态置 cancelled）； 不发通知：Phase 18 D2 的 notifications.user_id→users(id) FK 教训 - 守卫 MatchmakerWithdrawBlockerGuardTest 4 用例全绿；首跑暴露测试基建坑：@Transactional Service 是 CGLIB 代理，ReflectionTestUtils 直调私有方法拿到的是代理实例的 null 字段 → 须先 AopTestUtils.getTargetObject 解包（已在测试内注释说明） - 另发现历史遗留：countInProgressByOperator 使用白名单外的 'processing'（已登记） P04-T10：复核确认 Onboarding 本地资格步骤早已实现（onboarding 消息/动作 + 路由 + /me/status 字段）， JIRA ⏳ → ✅；清除首页语义错位的死状态 isVerified（miniapp tsc EXIT=0） 文档：JIRA 收尾行/计划文档 Task 3.1/3.3 勾选	2026-09-19 19:30:38 +08:00