99 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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]，两菜单可见。	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 与小程序生产域名	2026-09-30 12:10:00 +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
WorkBuddy	469d7194bd	fix(p16/p13a): Task 3.3 三项清偿 —— 互选超时接线、随访审计、随访风险检测（负向验证已证守卫有牙） ... P16-T13 互选超时接线： - 缺陷本体：expires_at 全仓无人写入（配置 48h 在、confirm 的过期过滤在，唯独创建不赋值） → (expires_at IS NULL OR expires_at > NOW()) 恒真，「截止后48小时」窗口形同虚设 - 修复：createMutualConsent 新建时写 expires_at = 活动结束时间 + ActivityConfig.mutualDeadlineHours （已确认口径「截止后48小时」），活动缺失/无结束时间回退创建时刻 - 守卫：ActivityMutualConsentServiceTest 新增 2 用例；负向验证（摘掉写入）恰 2 红、其余 7 绿 - 原测试 expiredConsentRejectsConfirm 手动补 expires_at 恰好掩盖了创建侧缺陷，如实记录 P13A-T31 随访审计： - assigned Counselor 读他人咨询正文/随访此前零审计 → getDetailForCounselor 接线 recordSensitiveAccess(counseling_followup)；本人读自己与 manager 摘要视图不审计 P13A-T33 随访风险检测： - detectCounselingRisk 此前只扫申请摘要 → addFollowup 正文接入同一检测（source=counseling）， INV-013 加固：不记录正文只记级别（同 apply 模式） - 守卫：CounselingFollowupAuditAndRiskGuardTest 4 用例（审计落库回查 ×2 + 风险事件落库回查 ×2），全绿	2026-09-19 19:10:25 +08:00
WorkBuddy	28cf25756a	test(e2e-recon): E2E 场景对账表（32 项：31 项有真实覆盖、1 项被裁定取代）+ 补 /me/status.localEligibilityStatus 零断言缺口 ... - 对账表写入收尾计划 Task 2.1 节：首页 11 / 本地资格 11 / 权限 10 逐项映射到 E2E 用例与后端集成测试；原始清单取自 commit ae1bd2b 占位文件头 - 发现并补齐 1 处缺口：/me/status 的 localEligibilityStatus/localEligibilityType 此前零断言（实现存在但从未被测）→ 新增 MeStatusLocalEligibilityGuardTest 2 用例 - 首页 #10（counselingEnabled flag 控制入口）登记为被 2026-09-19 产品裁定取代（死配置移除） - 实测：MeStatusLocalEligibilityGuardTest 2/2 绿（离线容器 3:19）	2026-09-19 18:58:07 +08:00
WorkBuddy	e9b99d020b	docs(status): 回写批 2/3 实况 —— 权威行升 09-19（E2E 65 passed / 678+ tests）、Flyway V048、rc.16、Phase 21 遗留行修正（隐私设置已关闭；红娘拦截「无表」判定已推翻）、JIRA 登记批 2/3 收尾、收尾计划 Task 3.1 隐私项勾选	2026-09-19 18:50:00 +08:00
WorkBuddy	0aa5a7b4e6	docs(status): Phase 22 遗留三项更新为 2026-09-19 已处置 ... T01-T05 死开关与 T07 私有桶配置已移除；PUT /feature-flags 已由 V048 做成 真持久化（含重启加载、DELETE 恢复默认、坏值 fail-fast），并如实记录 「多实例内存值不自动刷新」的已知边界。避免与计划文档自相矛盾。	2026-09-19 17:50:49 +08:00
WorkBuddy	d605c04707	feat(flags): PUT /operator/feature-flags 真持久化（V048） ... 此前 updateFlag 只改 FeatureFlagConfig 内存单例的字段：重启即回默认值、 多实例互不一致，表现为「后台显示已关闭，一次发布后功能又回来了」。 - V048 新建 feature_flag_overrides（flag_key 主键；值存字符串、回读按字段 声明类型解析；updated_by 记审计）。updated_by 必须建 uuid 而非 varchar， 否则 UUIDStringTypeHandler 以 uuid 发参数会在 PG 抛 operator does not exist: character varying = uuid（同 V046 的 actor_id）。 - FeatureFlagOverride/Mapper/Service：upsert 走「先 UPDATE、0 行再 INSERT」， 不用 PG 的 ON CONFLICT（H2 测试库不认，同 IdempotencyMapper 取舍）。 - FeatureFlagConfig.reloadFromPersistence() 挂 @PostConstruct：该时机晚于 @ConfigurationProperties 绑定，故 DB 覆盖压得住 yml 默认值。 - PUT 先改内存再落库（内存改动失败即 400，不写库）；新增 DELETE 恢复默认。 - 覆盖值无法解析时启动 fail-fast，不静默回退默认（否则「配了不生效」）。 守卫 FeatureFlagPersistenceGuardTest 11 例，核心是「另起实例重新加载后改动仍在」 （重启等价路径），并自检 @PostConstruct 未被摘掉。 负向验证：注入不落库 + 摘钩子 -> 恰好 5 例变红，其余不受影响；还原 md5 一致。 全量回归 700 / 0 / 0 / 3（起点 689，净 +11）；UI 契约门禁 18/18。	2026-09-19 17:47:16 +08:00
WorkBuddy	018626935a	chore(config): 移除 7 项从未被读取的死配置（5 个功能开关 + 2 个咨询附件桶） ... 产品裁定：确认移除对系统无影响即可移除。移除前的无影响论证（不是「看着没人用就删」）： 全仓搜索 5 个 getter，命中的只有 ① 本类定义处 ② getAllFlags() ③ FeatureFlagControllerTest 一处断言 —— 业务代码零调用点；前端 admin-web/src 与 miniapp 对 feature-flag 零调用（仅一个未使用的 storageKey 常量）。 ⚠️ 重要边界：FeatureFlagConfig **整体不能删** —— 同类的 isAppealEnabled（AppealService 4 处）、 isLocalEvidenceUploadEnabled（LocalEligibilityService）、getLocalEvidenceMaxFiles / getLocalEvidenceMaxFileSizeMB / getLocalEvidenceAllowedTypes（PhotoService）都是**真实生效的 gate**。 本次只删那 5 个死的：counselingEnabled / premaritalEnabled / contentEnabled / serviceLocationEnabled / localEligibilityEnabled，以及从未被读取的 counselingAttachmentsPrivate / counselingAttachmentsBucket（存储实走 object-storage.bucket-private）。 同步清理 application-docker.yml（application-dev.yml 被 .gitignore 排除，已在本地同步清理）： 否则会留下「配了但不生效」的新死配置 —— 正是本次要消除的问题本身。 getAllFlags() 键数 21 → 14；FeatureFlagControllerTest 布尔样例由 counselingEnabled 换成 referralEnabled。 docs(plan): Task 3.1 全闭 + Task 3.2 前两项已完；附 B 增第 14 项；基线 685→689 Task 3.1（隐私设置）两层均已关闭：① upsert ② 桩接通 + 键集以小程序为准。 Task 3.2 第三项「PUT /feature-flags 不持久化」**仍未处理** —— 改动涉及运维流程 （改的是运行时内存态，重启即失效），与「删死配置」风险不同，需确认做成真持久化还是标注只读后关端点。 附 B-14：新增迁移必须同步更新 MigrationValidationTest.LATEST_MIGRATION（本轮实测踩到）， 该守卫还断言「迁移文件总数 == 基线」即不允许缺号，属有效守卫。 全量回归 689 / 0 failures / 0 errors / 3 skipped；UI 契约门禁 18/18 绿。	2026-09-19 17:12:05 +08:00
WorkBuddy	d9c08d85f9	feat(privacy): 键集以小程序为准 —— V047 补列 + 接通 /account/privacy-settings 桩 ... 产品裁定：隐私设置键集**以小程序为准**，用迁移补齐后端缺失列。 V047 新增 allow_activity_invitation（默认 TRUE）与 show_last_online（默认 FALSE）。 默认值**不对称**，与小程序 data 初值严格一致 —— showLastOnline 写成 TRUE 等于默认公开用户在线状态。 既有 6 列保留不动：UserProfileService 的资料详情 DTO 仍在全量返回它们（第 74-79 行）， 那是仍在生效的独立读取出口。本迁移只做加法，不做替换。 AccountLifecycleService 的两个 TODO 桩改为委托 PrivacyService 真实读写。 这是**用户真正走的路径**（小程序调 /account/privacy-settings，而 /me/* 与 /profile/* 无人调用）， 此前「保存成功」只是回 {updated:true} 而从不落库。 入参校验：已知键类型错误必须显式抛错，未知键宽容忽略 —— 若静默丢弃，用户会看到「保存成功」而设置从未生效，这类缺陷最难排查。 另容错 Boolean 的字符串形式（"true"/"false"）。 test(privacy): PrivacySettingsUpsertGuardTest 扩至 8 用例，其中 2 个是契约守卫 契约守卫**直接解析小程序源文件**的 PUT payload 与 data 块得出权威键集/默认值， 不抄契约副本（沿用 EntityMigrationParityTest 的纪律）—— 小程序改键即变红。 ① 键集：后端返回键必须与小程序 PUT payload 键完全一致（不多不少） ② 默认值：后端默认值必须与小程序 data 初值一致（含 showLastOnline=false 这条不对称项） ③ 桩已接通：经 /account/privacy-settings 写入必须真落库且可读回 ④ 已知键传错类型必须报错，不得静默丢弃 其余 4 个为 upsert 行为守卫（连续两次更新不炸且不产生第二行 / 部分更新不重置 / 默认值 / 读取无副作用）。 负向注入：把桩退回「不落库」→ 恰 2 红（③ 与 ④），其余 6 个正确未红。已还原并复跑全绿。 test(deployment): MigrationValidationTest 基线 46 → 47 新增迁移必须同步更新 LATEST_MIGRATION，否则全量回归报「版本号超出当前基线」。 该守卫同时断言「迁移文件总数 == 基线」（不允许缺号），是有效守卫 —— 正确做法是更新常量，不要为了让测试变绿而改断言方式。	2026-09-19 17:11:46 +08:00
WorkBuddy	04b07b5821	fix(privacy): updatePrivacySettings 改 upsert —— 同一用户第二次更新不再撞 user_id 主键 ... user_privacy_settings 的主键自 V002 起就是 user_id，旧实现无论记录是否存在都无条件 insert， 导致同一用户第二次更新必然 DuplicateKeyException → 500，隐私设置从此再也改不动。 现改为「存在则按 user_id 更新，不存在才插入」。 更新条件刻意用 user_id 而非实体 id：id 是 V037 为「实体↔表对齐」后补的独立列， 不作为寻址依据 —— 否则历史行 id 缺失时更新会静默失效。 已知边界（未擅自处理）：findByUserId 带 deleted_at IS NULL，若将来引入软删路径， 已软删的行会让本方法走插入分支并撞主键。当前不存在任何软删隐私设置的路径，故不可达； 若将来新增软删，需同步改为 PG ON CONFLICT (user_id) DO UPDATE。已在代码注释中标注。 test(privacy): PrivacySettingsUpsertGuardTest —— 4 用例，全走真实落库（H2），不用 mock 断言调用次数 ① 连续更新两次：第二次不得抛异常 + 库中仍只有 1 行（防退化成重复插入， 那会让 findByUserId 的 Optional 返回值抛 TooManyResultsException） ② 部分更新不得把未提交字段重置回默认值 ③ 首次更新未提交字段取默认 true ④ 无记录时读取返回全 true 且不落库（固化既有契约） 负向注入已验证：退回无条件 insert → 恰 2 红，失败原因即 DuplicateKeyException； 另 2 个只更新一次的用例正确未红（走不到该分支）。已还原并复跑全绿。 docs(plan): Task 3.1 拆两层并记录进展；附 B 增第 13 项；基线 681→685 ⚠️ 关键发现（附 B-13）：隐私设置有两套实现，前端走的是桩那一套 —— 小程序 pages/privacy-settings 调 /account/privacy-settings（AccountLifecycleService 桩，不落库）， 管理端对隐私端点零调用。故本次修复位于「前端尚未触达」的路径：必要但当前用户不可感知。 真正的用户可见故障是「改隐私设置根本不保存」（桩），属 Task 3.1 上层，仍待契约裁定。 本次修复是该上层工作的必要前置 —— 桩一旦接到 PrivacyService 立刻会撞上此缺陷。 方法论：评估「某修复的价值」必须先确认前端实际调用哪条路径 —— 本项目同业务存在 /me/* 与 /account/* 多套并存端点，后端有真实实现 ≠ 用户能走到。	2026-09-19 15:49:54 +08:00
WorkBuddy	0242ea44e8	fix(mapper): 补 5 个「只有声明、无任何 SQL」的方法；新建 Mapper 绑定守卫持续挡住该类缺陷 ... 全仓无 mapper XML、无自定义 ISqlInjector，自定义方法只能靠注解提供 SQL。 这 5 个方法漏写注解，编译期无感知，调用必抛 Invalid bound statement： UserPrivacySettingsMapper.findByUserId —— 隐私设置读取 UserPreferenceMapper.findByUserId —— 推荐引擎 / 匹配资格共 6 处调用 ReviewReasonMapper.findAllEnabled —— 审核原因字典下拉 ReviewReasonMapper.findByCategory ReviewItemMapper.findByReviewTaskId 长期未被发现的原因：候选池为空（分支走不到）+ 测试库根本没有这 4 张表（双重不可达）。 补的 SQL 一律带 AND deleted_at IS NULL —— V037 之后这些表都有软删列， 只看 V002 建表会漏掉软删过滤，制造「读到已删数据」的新缺陷。 test(invariants): MapperBindingGuardTest —— 三用例 ① 绑定守卫：反射遍历 MapperRegistry 全部 Mapper 的声明方法，hasStatement 为假即失败； 按「实体有无主键」语义豁免复合主键实体的 selectById/updateById/deleteById 等 （MP 本就不为无主键实体注入，属正确行为；非类名白名单，故新增复合主键表同样适用）。 ② 探测自检：虚构 statementId 必须为假，防断言静默永真。 ③ 可执行性：插真实数据后真查一遍 —— 绑定存在 ≠ 能跑（本次即借此确认 JsonNode 映射无碍）。 负向注入已验证：移除 ReviewItemMapper 的 @Select → 守卫报恰 1 项缺失， 且可执行性用例抛真实 Invalid bound statement；还原后复跑全绿。 test(db): schema-h2.sql 补 4 张缺失表（user_privacy_settings / user_preferences / review_reasons / review_items），按 V002 + V037 之后的最终态建模（含 id、deleted_at 与 11 个匹配权重列），并保留 chk_item_type / chk_item_status / chk_pref_priority 约束。 docs(plan): 附 B 新增第 12 项；更正第 11 项中我自己上一轮的错误断言 —— 「表无 id 列导致 insert 必崩」不成立：V037 已补齐 id/deleted_at/权重列。 真实缺陷是 updatePrivacySettings 对已存在记录也走 insert（非 upsert）→ 第二次更新撞主键冲突。 方法论：判断表结构必须遍历全部迁移，只看 CREATE TABLE 会得出与生产相反的结论。	2026-09-19 15:26:35 +08:00
WorkBuddy	9466b2b636	docs(plan): 校正「跑测试命令」两处误判并补全必挂项；登记全量回归实测基线 678/0/0/3 ... 本轮自查中先后写下两条错误结论，均系命令/挂载所致而非代码问题，现如实留痕更正： ① 误判「mvn -o 不可用」—— 实为漏挂命名卷 danyang-m2-cache（镜像内置 /root/.m2 仅 132MB， 缺 surefire-junit-platform；命名卷 251MB 含 3.1.2）； ② 误判「35 failures + 54 errors 是回归」—— 实为只挂 backend/ 而非仓库根， 致 MigrationValidationTest / AnalyticsPermissionGrantTest / SecurityPathCoverageTest / PrincipalInjectionContractTest 等以相对仓库根路径读文件的测试集体 NoSuchFile。 正确命令下全量回归 BUILD SUCCESS：678 / 0 failures / 0 errors / 3 skipped（约 6 分钟）。 附 A 校正表扩至 9 行（含 2 处自身结论更正），Global Constraints 与附 B-9 同步补全两处必挂。	2026-09-19 14:16:19 +08:00
WorkBuddy	b834fa86a0	test(invariants): Phase 23 Task 2.2 —— INV-011 显式行为守卫（9 用例 + 两次负向注入验证） ... 产出 Inv011EvidenceAccessGuardTest：非领取人 / 跨用户佐证 / 非 local_eligibility 任务一律拒绝， 且 successful 与 denied 两条路径都断言 sensitive_access_logs 真实落库（不用 mock 断言）。 另含 3 个结构性守卫（用户侧端点无用户可控 userId 入参、佐证读取入口的双重权限约束、 佐证读取不暴露可伪造 operatorId）与 1 个守卫自检（参数名反射可读，防断言静默永真）。 前置修复：schema-h2.sql 补 sensitive_access_logs 表 —— 该表此前在测试库完全不存在， 而它是「访问留痕」命题的唯一落点，缺失导致该命题根本无法断言（表漂移盲区，与 Phase 12/15/19 同族）。 负向注入两次，均精确命中： ① 停用 requireClaimOwner → 恰 1 红（非领取人用例），其余 8 绿 ② 停用 catch 内 denied 审计 → 恰 2 红（非领取人 + 跨用户），第 3 条走 try 外的另一路径故正确未红 两次注入均已还原并复跑全绿（9/9）；V11InvariantsTest 12/12 绿；UI 契约门禁 18/18 绿。 文档：Task 2.2 闭环记录 + 附 A 扩至 7 处校正（含对本文档初稿「机构创建 500 归因」的自我更正， 实测为 chk_org_status 违约而非 id 为空）+ 附 B 扩至 11 项新发现 （5 个 Mapper 方法声明了却无实现、隐私设置三方契约冲突 + 表/实体主键错配、 测试镜像 mvn -o 不可用、本机全量回归会卡住）。	2026-09-19 14:02:52 +08:00
WorkBuddy	e666ee6f8a	feat(e2e): Phase 23 Task 2.1 —— 活动互选 8 场景 + 服务预约 8 场景真实实现（16 个真实用例） ... 背景：`tests/e2e/activity_mutual_consent_test.py` 与 `service_appointment_test.py` 此前是 **诚实占位**（仅 docstring、0 用例，指针指向 run_v11_tests.py），计划 Task 2.1 要求把 文件头保留的场景清单逐条实现为真实 HTTP 用例。本提交完成该任务。 ═══ 新增真实用例 16 个（本机活栈 pytest tests/e2e 49 → 65 passed）═══ activity_mutual_consent_test.py（8，覆盖 INV-014/015/006 + AGENTS.md #19/#20） 1 建立互选记录不建 Match（INV-014） 2 单方确认不建 Match（INV-015） 3 双方确认建 Match Episode 且双方可见 4 已有 active Match 时再次双确认必须复用（#19） 5 曾 Unmatch 后重新双确认开启新 Episode：episode +1（#20） 6 一方拒绝不建 Match，对方随后确认也不建 7 超时：已过期记录不得被推动成双确认（含「未过期必须生效」对照，防假绿） 8 单向意向不泄露（INV-006，含「B 确认后必须看到 accepted」反证） service_appointment_test.py（8） 1 提交预约；2 幂等键重放不得产生第二条；3 运营确认 submitted→confirmed（用户侧同态可见） 4 并发「用户取消 × 运营确认」不得 5xx、最终状态必须收敛；5 我的列表只含本人 6 待确认可取消；7 归属隔离（他人不可读详情/不可取消） 8 运营侧状态闸门：已完成预约不得再被取消 ═══ 两个幂等 seed（E2E 前置数据，本机与 CI 通用）═══ - seed_e2e_activity.sql：organization + 两个 activity。 必须建的原因是硬约束而非选择：`activity_mutual_connection_consents.activity_id` 有 **FK 到 activities(id)**（实测约束名 …_activity_id_fkey），而 activities.organizer_org_id 又 FK 到 organizations(id) 且 NOT NULL —— 全新库里三张表全空，互选无活动可挂。 - seed_e2e_service_station.sql：service_location + **站点-运营关联**。 关联必需：运营确认受数据范围约束（`assertOperatorScope` → `canAccessByOperator`）， super_admin **不豁免**，实测 e2e_admin 确认他站预约返回 403。 E2E 因此改用 seed 中该站点关联的 e2e_station。 两个 seed 由测试首用时幂等执行（docker exec psql），无需改 CI 步骤。 ═══ 负向注入（Task 2.1 Step 3）═══ ③ 撤销 service_station_operator 的 service_appointment.confirm → 恰 2 红（test_operator_can_confirm / test_operator_cannot_cancel_completed，403），其余 6 绿； ④ 触发器强制新建互选记录的对方侧 accepted → 3 红（both_confirm_creates_match_episode / timeout_handled / single_interest_not_leaked），其余 5 绿。 两处均已还原并复跑全绿（65 passed），确认无残留（无 e2e* 触发器、权限计数回到 1）。 **两次失败的注入（记录以免后人重复踩）**： - 删除站点→运营关联：**无效** —— 测试的 seed fixture 在用例前幂等重放 seed 会自愈该前置条件； - 改 user_b_status 列默认值：**无效** —— `createMutualConsent` 在 Java 侧显式写 pending， DB 默认值根本不参与（侧面证明写入路径的权威性）。 ═══ 计划文档校正（审阅产物）═══ 按实测推翻 4 处失实断言，登记 7 项新发现（详见计划文档「附 A / 附 B」）： - 推翻：matchmaker_services「无表/需扩权」（实为 V009 已建表且 mapper 齐备）； 门禁 14/14（实为 18/18）；「tests/e2e 现为占位」（实为仅 2 个文件）； E2E 基线 49（实为 65）。 - 新发现：① `POST /operator/organizations` 必然 500（createOrganization 不赋 id + IdType.INPUT + 无 DB 默认值；且未校验 chk_org_type）→ 连带「无法新建活动」； ② `createMutualConsent` 从不写 expires_at → 互选永不过期（即批 3 P16-T13，配置与 V041 部分索引空转）；③ 用户侧取消预约不校验状态（已确认/已完成也能自取消）， 与运营侧明确拒绝 completed 口径不一致 → 需产品裁定； ④ E2E 环境 organizations/activities/service_locations 均为空表（无迁移种子）； ⑤ 运营数据范围 super_admin 不豁免（预期行为，勿误判）； ⑥ 本机复跑会遇到 Redis 登录锁定键（auth:operator_login_lock:*）； ⑦ e2e_* 账号因 ON CONFLICT DO NOTHING 重跑 seed 不覆盖旧口令。 ═══ 验证 ═══ - `pytest tests/e2e` → **65 passed**（含新增 16）；`node scripts/run-ui-contracts.mjs` → **18/18 PASS**，退出 0； - 本机环境处置（不属代码改动）：把 6 个 e2e_* 账号口令对齐到 CI 口令、清除 Redis 登录锁定键。 - **未验证**：微信开发者工具、CI 上的首次 E2E 实测绿（Task 2.3 Step 3，本机无 Docker Hub 出口）。	2026-09-19 12:28:16 +08:00
WorkBuddy	2ae72aabe7	docs(governance): JIRA Epic 总览表补全状态列（P01~P07 补 ✅ / P23~P26 如实标注）；基线计划 Phase 22 合并重复口径澄清块 ... - Epic 表由 4 列改 5 列：P01~P07（此前漏标）补 ✅；P23 部分关闭、P24 待用户确认、P25 待运营、P26 Smoke 待手动 - UAT/RC/Production 当前执行项行更新：/me/* 已收敛，停在 Phase 24 门前 - 基线计划 Phase 22（Deployment/Ops）：合并两次编辑产生的重复口径澄清 blockquote，补回 Files 行	2026-09-19 11:45:27 +08:00
WorkBuddy	0da93008d0	test(miniapp): 行为契约的桩改为忠实模拟 wx 回调包装（异常不外逸，转 App.onError） ... 原桩直接同步调用 `opt.success(...)`，被测代码在回调内抛错时异常会**外逸到测试进程**， 于是「请求永不 settle」这一真实后果反而测不出来 —— 报出来的是注入的异常本身， 而不是「Promise 永久 pending」。 真实小程序里 `wx.request` 的回调是被 wx 包装的：回调内抛错**不会**打断请求链， 而是被捕获后走 `App.onError`（本轮控制台实测 `[App onError] MiniProgramError`）， 后果是 `resolve` 永不执行。桩必须保真这一点，否则判据会在错误的地方变红。 改动： - `respond()` 捕获回调内异常并记录，不外逸； - 成功路径新增断言：成功回调内**不得**抛出任何异常（附明确失败信息）。 负向自证（改前已实测）：在 `resolve(body.data)` 之前注入一行抛错 → 本契约输出 `Promise 在 1000ms 内未 settle —— 收尾逻辑又跑到了 resolve 之前` 并退出 1； 移除注入后 `git diff --exit-code` 为空（逐字节还原），全量门禁 **18/18 PASS**。	2026-09-19 11:43:13 +08:00
WorkBuddy	b67a56479e	fix(miniapp): 修 P0 请求层崩溃（一个下划线致所有请求卡死）+ 组件 WXSS 违规选择器，再补 3 项门禁 ... ═══ 缺陷 1（P0，运行期）：utils/api.js 成功回调调用不存在的方法 ═══ 控制台： TypeError: _this._releaseIdempotencyKey is not a function 根因：类中定义的是 `releaseIdempotencyKey()`，成功回调写成了 `this._releaseIdempotencyKey(...)`（**多一个下划线**）。 **为什么一个字符的笔误是 P0**：该调用位于 `wx.request` 的 success 回调内、 且在 `resolve()` **之前**。抛错 → `resolve` 永不执行 → 该 Promise **永不 settle** → 所有页面永远停在 loading，同时 App.onError 刷屏。 即「一次成功请求」本应推进流程，实际把前端整成不可用。 修复不只是改名，而是纠正结构： - **先 `resolve(body.data)`，再执行收尾动作** —— 收尾逻辑不允许挡在响应路径上； - 释放动作自带 try/catch + console.warn：释放失败最多是"下次操作没拿到新键"， 不得升级为业务失败。 - 语义未变（勿改）：成功→释放（下次同域操作是新的一次）；失败→刻意不释放 （重试复用同一把键，后端才能识别重复投递）。 ═══ 缺陷 2（编译期警告）：组件 wxss 用了标签选择器 ═══ Some selectors are not allowed in component wxss ... (components/recommend-card/index.wxss:1:1092) 实测违规 1 处（23 个组件样式文件全扫）：`.compact-like image` —— 组件 wxss 只允许类选择器。 改为 `.compact-like__icon` 并**同步在 WXML 补上类名** （只改 wxss 会让样式静默落空，是另一种"假成功"）。 ═══ 门禁：15 → 18（既有的全是源码内容断言，抓不到上述两类）═══ - 第15 `wxml-structure-contracts`（上一提交新增，本轮 MIN_GUARDS 基线顺带对齐） - 第16 `miniapp-self-method-contracts`：扫描 `this._x(` / `self._x(` 等私有调用， 要求同文件有定义（方法简写 / 类字段 / `this._x = 值` / prototype 四种形态）。 **判据先自证假阳性**：首版正则不允许 `.` 前缀，把 `this._unsub = store.bind(this)` 形式误报为未定义（3 个页面）；修正并加反向自检样例固化了该坑。 - 第17 `wxss-component-selector-contracts`：组件 wxss 禁标签/ID/属性选择器。 **作用域刻意只限 miniapp/components/**（page 的 wxss 允许标签选择器，套上去必有误报）。 - 第18 `miniapp-api-client-behavior`：**唯一的行为断言** —— 桩掉 `wx.request` 真跑 api.js， 验证成功 resolve / 失败 retain 键 / 成功 release 键 / 收尾抛错不影响响应路径 4 组。 含 1s settle 超时，直接编码"永不 settle"这一失败模式。 - 新增 `scripts/lib/wxss-selectors.mjs` + `scripts/check-wxss-component-selectors.mjs`（CLI）。 - `MIN_GUARDS` 15 → 18；执行器措辞改为「源码结构与关键行为断言」。 ═══ 验证 ═══ - `node scripts/run-ui-contracts.mjs` → **PASS 18 / 18**，退出 0； - 负向注入：未定义私有方法 / 标签+ID+属性选择器 / 多余闭合标签 → 均精准变红， 且**合法样例（`this._x = 值`、纯类选择器、属性内含 `>`）不被误报**； 行为守卫的负向自证见下一提交/记录；`UI_GUARDS_MIN=99` 拒绝报绿。 - 文档口径同步：AGENTS.md、STATUS.md（4 处当前口径 + 新增 1.1.0-rc.18 行）、ci.yml 注释。 - **未验证**：微信开发者工具真实编译与真机渲染（本机无该环境）。	2026-09-19 11:40:38 +08:00
WorkBuddy	d036c9b986	fix(miniapp): 修复 2 个页面 WXML 结构缺陷，并补第 15 项门禁（WXML 结构守卫） ... 现象：微信开发者工具报 [ WXML 文件编译错误] ./pages/service-history/service-history.wxml get tag end without start, near `</` 真实缺陷（实测 2 处，非 1 处）： - pages/service-history/service-history.wxml 多 1 个 </view> - pages/service-program/service-program.wxml 多 1 个 </view> （均为单行压缩写法，随更早提交入库；全仓另外 84 个 WXML 结构自洽） 根因不是这两个文件写错，而是**门禁覆盖盲区**： 既有 14 项 UI 契约全是「源码内容 / 清单断言」，没有任何一条会解析 WXML， 所以「14/14 全绿」与「小程序能不能编译」之间没有因果关系。 修复： 1. 删掉两处多余闭合标签 → 86 个 WXML 结构全部自洽。 2. 新增 scripts/lib/wxml-structure.mjs：按**引号状态机**逐字符扫描标签。 不能用懒惰正则 —— 属性值里可以合法出现 `>`（`subtitle="{{unreadTotal > 0 ? ...}}"`）， 正则会在引号内的 `>` 处提前收尾，把自闭合标签的 `/` 读掉，报出假阳性。 （首版实现即踩此坑，曾把合法的 messages.wxml 误判为坏文件；已复核排除。） 3. 新增 scripts/check-wxml-structure.mjs（CLI，退出码 0/1/2）。 4. 新增 ui-tests/wxml-structure-contracts.mjs：全量扫描 + **3 组内置自检样例** （正向样例故意在属性值内放 `>`，把「假阳性」这个坑钉进门禁）。 5. scripts/run-ui-contracts.mjs：MIN_GUARDS 14 → 15（守卫被删/改名仍会拒绝报绿）。 6. 文档口径同步：AGENTS.md、STATUS.md（4 处当前口径 + 新增 rc.17 版本行）； ci.yml ui-contracts job 注释 14 → 15。历史时点行保留原值。 负向验证（三项，全部通过）： - 注入「多余闭合 / 未闭合」→ 退出 1，且只报坏文件、合法的 `>` 属性文件未被误报； - UI_GUARDS_MIN=99 → 拒绝报绿（数量下限分支可自检）； - CLI 直扫坏目录 → 退出 1。 验证：node scripts/run-ui-contracts.mjs → PASS 15 / 15，0 失败，退出码 0。 未跑：微信开发者工具真实编译（本机无该环境），结论仅由结构判据支撑。	2026-09-19 11:25:05 +08:00
WorkBuddy	5715987049	fix(infra): 修复健康探针的 IPv4/IPv6 解析歧义（nginx 假 unhealthy） ... 问题：本地完整栈起齐后 nginx 容器报 unhealthy，但宿主 curl http://localhost:6688/nginx-health 返回 200 —— 探针与实际服务不一致。 根因（实证，非推断）： - nginx 的 `listen 80` 只绑 IPv4：容器内 netstat 显示 0.0.0.0:80，无 [::]:80； - /etc/hosts 中存在 `::1 localhost`，busybox wget 解析 localhost 时优先取 ::1； - 容器内实测：wget http://127.0.0.1/nginx-health → ok wget http://localhost/nginx-health → Connection refused。 即探针地址与服务的实际绑定族不一致，属「探针与被探对象脱钩」的假告警， 并会连带拖垮 depends_on: service_healthy 的下游等待。 （backend 之所以此前一直 healthy，是因为 Java 恰好双栈监听 :::8080 —— 属偶然，不应被依赖。） 修复： - infrastructure/docker-compose.yml：nginx 与 backend 探针改用 127.0.0.1，并各加注释写明理由； - infrastructure/docker-compose.staging.yml：backend 探针的同类写法一并改（staging 栈未起， 未经运行验证，仅保持写法同构）。 验证： - docker compose config 通过；nginx 重建后 State.Health = healthy（FailingStreak=0，探针 ExitCode=0）； - 链路回归：/admin/ 200（877B）、/admin/assets/index-CDxMNwaf.js 200（1,267,697B）、 /nginx-health 200、/api/v1/health/live 200；/admin 与根路径均 301 → /admin/； - 活栈 E2E 49 passed；UI 契约门禁 14/14 PASS。	2026-09-18 22:27:26 +08:00
WorkBuddy	6b2ff0f73e	docs: 二次修正 features 断言失实（5 处）—— 原判据「*.yml 无 features 块」被证伪 ... Phase 22 复验报告 D-22-D 的判据「backend/src/main/resources/*.yml 无 features: 块」是错的， 且被上一轮收尾照抄进 STATUS.md（P26-T06 行），属二次传播。 实测事实： - application.yml（基础） → 无 features 块 - application-dev.yml（默认激活 profile，自 63cbbff）→ 有，21 键 - application-docker.yml（自 730dddd / Phase 23B） → 有 硬证据：dev 的 chat-image-enabled: true 覆盖了 FeatureFlagConfig 的 Java 字段默认 false —— 若「仅 Java 字段默认值生效」成立，该值不可能为 true。 仍然成立的部分：T01~T05 模块开关与 T07 私有桶确实全仓零业务调用点（实测 12 个 flag 的 调用点计数全为 0），「死配置」结论正确；失实的只是来源（非 application.yml、非「仅 Java 默认值」）。 新发现 D-22-E：AppController#getConfig（GET /app/config）返回一份硬编码 features map （imageChatEnabled 恒 true，键名与后端 chatImageEnabled 不一致）→ 与 FeatureFlagConfig 双源， 前端读到的开关可能与实际配置相反（如 appealEnabled 实际默认 false）。不静默改契约，登记为遗留。 修正落点：STATUS.md（P26-T06 行 / Phase 22 段 / 历史声明块）、Phase-22 报告（表格行 + D-22-D + 新增 D-22-E）、JIRA_BACKLOG.md、Phase-V11-Deployment-Completion-Report.md、 治理报告新增第九节（含「同一文件并行 Edit 会随机丢失」的事故记录与纪律）。	2026-09-18 21:58:58 +08:00
WorkBuddy	f63e579a8d	ci(e2e): 落地「活栈供给方式」决策 — Compose in CI，并修掉 6 处真实缺陷 ... 决策：E2E 活栈在 runner 内用 docker compose 起全栈（postgres + redis + minio + backend）， 与本地验证路径完全一致；未采纳「service containers + runner 上 mvn package 后 java -jar」—— 那需要为后端另写一套 host 网络配置，等于制造第二条与本地不一致的路径。 本机实测（与 CI 同一序列）：中间件三项 healthcheck 全 Healthy（pg_isready / redis-cli ping / mc ready local）→ backend /api/v1/health/live 返回 200 → seed 幂等可执行（INSERT 0 0） → pytest tests/e2e → 49 passed。 （本机限制：Docker Hub 不可达且无 temurin 基础镜像，未复现 --build；改用本地既有镜像为底座、 挂载当日 16:24 构建的 jar，使被验证的代码版本与 CI 一致 —— 否则是拿 09-09 的旧代码验 09-18 的用例。） 修掉的 6 处缺陷： 1. minio/minio:latest 是滚动 tag → pin RELEASE.2025-09-07T16-13-09Z（否则 CI 拉到的镜像 与本地验证时不同，表现为不可复现的偶发失败） 2. up 未显式列出 minio（靠 depends_on 隐式拉起），而 minio 的 healthcheck 正是 backend 能否启动的前置条件 3. up --build 把构建与起栈耦合，失败日志混杂 → 拆为 build / up 两步 4. 就绪窗口 5min 偏紧（首次构建后仍需 Spring 启动 + Flyway 46 个迁移）→ 7.5min 5. 缺 down -v 前置清卷：seed 用 ON CONFLICT (username) DO NOTHING，残留卷会让账号口令 停留在上一轮 → 登录 401，并伪装成业务失败 6. job 无 timeout（GH Actions 默认 360 分钟）→ timeout-minutes: 30 另：pytest -v → pytest tests/e2e -v。原以为从仓库根收集会误收 tests/*_test.py （其在 import 期依赖 psycopg2 与 E2E_DB_PASSWORD），实测否定：pytest.ini 的 testpaths = tests/e2e 已限定范围，从根收集正是 49 个用例且无 error。显式传参作为兜底保留。 计划 Task 2.3 由「依赖基础设施决策」改为「已决策并落地」，仅余 Step 3（CI 上实测一次绿）。	2026-09-18 21:58:56 +08:00
WorkBuddy	70134dd62e	docs: STATUS 历史区收敛 951→783 行，修正两处残留假声明，同步治理报告与收尾计划 ... 治理报告「八、遗留」第 2 项（STATUS 后半历史区过长）至此关闭。 STATUS.md（951 → 783 行，净减 168）： - 折叠 2026-09-09 期快照：Phase 01~11 逐项任务表 → 索引表（指向权威结论位置）；旧 Phase 13 首轮表 → 指针；「V1.0 基线状态 + 历史状态记录」两块 → 一段带历史边界声明的治理痕迹。 - 收敛作废/重复块：两块已作废的 Phase 22 历史声明、已作废的 Phase 23「已完成」声明、 「整体进度总结」里重复的 Phase 24~26 摘要。 - 修正两处残留假声明（本轮新发现）： ① `P26-T06 初始化Feature Flags | ✅ (application.yml配置)` → 标「不成立」（依据 Phase 22 复验： 4 份 application*.yml 无 features 块，15 个 flag 实为 Java 字段默认且业务不读取）； ② `Phase 23（V1.1专项测试）— 已完成 ✅` → 标「已被 2026-09-18 复验推翻，实为部分关闭」。 - 口径更新：UI 契约测试行 13/13 → 14/14（统一执行器 + 已接入 CI），并注明阶段 4 的历史时点值。 - 三个门禁锚点全部保留并复验：UI REDESIGN ACCEPTED BY USER、Phase 07…已通过用户验收、 管理后台: http://localhost:13520/。 同步文档： - 治理报告：4.4 漏网文档改为「已处置」；悬空引用表最后一行为已关闭；第七节补 UI 门禁入 CI、 执行器负向验证、漏网文档处置三行，并改写 STATUS 收敛行；第八节改为「3 项遗留全部关闭」。 - 收尾计划：批 1 Task 1.1 标完成（Step 1~4 证据齐），并更正「15 个契约文件」为实测 14 个； 验收口径由逐文件执行改为 `node scripts/run-ui-contracts.mjs`。 验证：`node scripts/run-ui-contracts.mjs` → PASS 14/14、退出码 0（含文档基线契约门禁）。	2026-09-18 21:34:47 +08:00
WorkBuddy	b2ef60c04c	docs: 废止漏网报告 Phase-V11-Deployment-Completion-Report（原地重写）+ 修订两处引用 ... 治理报告 4.4 登记的「保留待决」项至此关闭（用户确认执行）。 - docs/Phase-V11-Deployment-Completion-Report.md：102 行 → 废止声明，含四要素 （①原文是什么 ②为何失效：16/16 E2E 与 Feature Flags 15 项均被 Phase 22/23 复验推翻 ③取代者：STATUS.md / OPS.md / V1_1_CHANGELOG.md ④为何保留而不删除）。 **未删除** —— 本机有「删文件会级联清空父目录」红线，且删除会制造悬空引用。 - docs/Phase-01-V11-Recovery-Completion-Report-2026-09-09.md：引用行标注「已于 2026-09-18 废止」， 并指明结论以 STATUS/OPS 为准，使引用有落点而非悬空。 - docs/Phase-13A-V11-Completion-Report.md：废止声明中「决定保留待决」改为「已同步原地重写为 废止声明」，与实况一致。 原文可从 Git 历史取回：git log --all -- docs/Phase-V11-Deployment-Completion-Report.md	2026-09-18 21:34:33 +08:00
WorkBuddy	d707fb1f60	ci(ui): 把 14 个 UI 契约门禁接入 CI，并新增统一执行器 ... Phase 23 收尾计划 批 1 Task 1.1 —— 此前 ui-tests/*.mjs 只在本地手工逐个执行，没有任何 CI 把关：改动破坏了源码结构契约也不会有任何信号。 - 新增 scripts/run-ui-contracts.mjs：逐个 spawn 子进程运行守卫 → 汇总 → 任一失败即非零退出， 并打印失败守卫的原始输出便于定位。零 npm 依赖（守卫只用 node 内建模块）。 - 两条防退化设计： ① 子进程 cwd 固定为仓库根 —— 守卫里 6 个用相对路径、8 个用 import.meta.dirname 自锚定， 不固定 cwd 会在 CI 上假红； ② 守卫数量下限校验（MIN_GUARDS=14，可用 UI_GUARDS_MIN 覆盖）—— 防止守卫被删除或改名后 依然报绿（Phase 19 教训：扫描清单本身会漏）。 - ci.yml 新增 ui-contracts job（checkout + setup-node + 跑执行器），与既有 test-shell-guard 同属「守门」类 job。 - 生产 compose 缺失的既有兜底确认可复用：ui-document-baseline-contracts.mjs 对不在版本控制内的 infrastructure/docker-compose.prod.yml 已做 existsSync 判定并显式打印跳过原因，CI 上不会假红。 验证： - 基线 node scripts/run-ui-contracts.mjs → PASS 14/14，退出码 0； - 负向注入（.workbuddy/tmp 下必然失败的守卫）→ FAIL、退出码 1，失败详情可见； - 数量下限分支以 UI_GUARDS_MIN=99 自检 → 正确拒绝报绿（退出码 1）； - .github/workflows/ci.yml 经 yaml.safe_load 解析通过，jobs 含 ui-contracts。	2026-09-18 21:30:15 +08:00
WorkBuddy	c061a55151	docs: 治理报告去掉 bundle 的写死 hash，改为现场可复核判据 ... 上一提交在 D7 行与第七节写上「list-heads → main = 4e18272」，但该 ref 指向会随每次 提交变化 —— 报告一旦入库就已经过期，读者复核必然看到不一致。改为只给判据不给值： - D7 行 / 第七节：删除固定 hash，改为「`git bundle list-heads <file>` 里的 `refs/heads/main` 必须等于 `git rev-parse HEAD`；引用时不要写死 hash」。 - 保留 f96dcb8 这一历史事实（restore-checkpoint 覆盖面不足的依据），它是稳定事实。 理由：这与本报告自身正在治的病同族 —— 把「随时间变化的量」写成常量，等于制造下一个 「文档与实况不符」的缺口。	2026-09-18 21:23:56 +08:00
WorkBuddy	75272a5c21	docs: 修正治理报告 D7（bundle 先虚后实）+ 补 9 项缺口补记与可复核证据 ... D7 是本轮唯一一处「先报完成、后被证伪」的项，如实修正并留证： - 原写「✅ 本轮重跑 git bundle create 覆盖至最新提交 | 根目录 *.bundle」， 实测磁盘上并不存在该文件；且当时唯一的 .workbuddy/tmp/restore-checkpoint-2026-09-18.bundle 其 main 停在 f96dcb8，早于 21:15 的三个治理提交 —— 等于治理成果当时无 bundle 保护。 - 已补建 .workbuddy/backup/docs-governance-2026-09-18.bundle（23.3MB，--all）， git bundle verify = complete history，list-heads → refs/heads/main = 4e18272。 - 新增补记：安全网类交付（bundle / tag / 门禁）必须用可验证命令复核 （list-heads 看 ref 指向的提交号、git tag -l、门禁退出码），不能以「命令已执行」为准； 与本项目此前「假成功」同族（生产 /admin/ 返回 200 欢迎页、E2E 只断言常量字符串）—— 共性为「验证信号与被验证对象解耦」。 - 第七节补 bundle 可复核证据行；第六节「安全网」行注明其覆盖面不足； 第八节执行纪律补 bundle 路径约定 .workbuddy/backup/<phase>-recovery-<date>.bundle 与 list-heads 校验步骤。	2026-09-18 21:23:19 +08:00
WorkBuddy	4e1827295d	docs: 新增 Phase 23 收尾与 UAT 就绪计划 + 2026-09-18 文档治理报告（方案任务四、五） ... - 新建 docs/superpowers/plans/2026-09-18-phase23-closeout-and-uat-readiness.md（superpowers 计划格式）， 五批：批 1 快速收尾（ui-tests 15 个契约接入 CI —— 目前**只在本地手工跑**，CI 无把关）/ 批 2 Phase 23 剩余（E2E 场景真实实现 + INV-011 显式守卫 + CI 串联 E2E【需基础设施决策】+ Phase 22 Deployment/Ops 口径复验）/ 批 3 代码级遗留清偿 / 批 4 UAT 就绪【需用户协作】/ 批 5 Phase 25-26 前置登记。STATUS.md 与客户需求基线计划均已引用（方案明确要求）。 - 新建 docs/文档治理报告-2026-09-18.md：五任务执行核对；本轮 9 项缺口（D1~D9）逐项处置； 删除/归档/头注/保留四张清单；悬空引用二分结论（naive 扫描 29 处，其中 **24 处是「已删除对象清单」 里的合法治理证据**，真实悬空 5 处）；**docs/ 目录被 safe-delete 钩子整体移除的事故记录与恢复过程**； 验证证据；4 项遗留。 验证：UI 契约门禁 **14/14 PASS**；ui-document-baseline-contracts 通过（锚点齐全）； database 文档 59 表 / 46 迁移与迁移文件实测一致。	2026-09-18 21:15:39 +08:00
WorkBuddy	ae2405f645	docs: 状态文件同步到 2026-09-18 实况（方案任务三） ... - STATUS.md：顶部权威行由 "PHASE 20 COMPLETE"（09-17）更新为 09-18 口径（Phase 01~22 关闭 / Phase 23 部分关闭 / 三轮横向加固 / 669 tests / 停在 Phase 24 门前）；版本演进表补 rc.11~rc.16； **合并三处重复的「V1.1 本地部署完成 (2026-09-09)」区块为一处**（996 行 → 946 行）并加 「历史记录边界」声明；清「Phase 04~05 ⏳ 待开发」等与实测矛盾项。契约锚点全部保住 （UI REDESIGN ACCEPTED BY USER / Phase 07 已通过用户验收 / 管理后台: http://localhost:13520/）。 - AGENTS.md + STATUS.md：UI 契约门禁口径 13/13 → **14/14**（历史时点行保留原值并注明， 不篡改史实）。 - JIRA_BACKLOG.md：Epic 总览表补 P14/P15/P19~P23 的 ✅（P23 标「部分关闭」）。 - 客户需求基线计划：Phase 07 标题去 "UI REOPENED"；Phase 10~15/19 补 ✅；Phase 20/21 勾选 checkbox 并注日期；**Phase 22 如实标「未复验」**（口径澄清：计划的 Deployment/Ops 与 STATUS 的 「部署运维配置扩展（Feature Flag）」是两份不同工作，后者复验结论不构成本节证据）； Phase 23 标「部分关闭」，第 3/5 项（E2E 场景实现、CI 串联）**不虚勾**。 - PENDING_DECISIONS.md：历史部署声明 10 项按各 Phase Recovery 报告证据回写处置结果 （9 项已关闭 / 1 项部分）；补登 HTTP 与幂等检修遗留的第三方开放待决策 7 项。 - REMAINING_WORK.md：整体重写 —— 原文称 CHANGELOG 3.3MB（实为 4234 字节）、P1-3 指向从未存在的 Phase-23-Completion-Report.md；改为「已关闭 / 仍未完成 / 原编号索引 / 验收标准」四段，保留原编号 以便对照历史引用。 - database 两份：TABLE_INVENTORY 40 表 → **59 表**（带「来源迁移」列）；MIGRATION_GUIDE V001~V011 → **V001~V046（46 个）**；两份均标注「以 backend/src/main/resources/db/migration/ 为准」。	2026-09-18 21:15:29 +08:00
WorkBuddy	4f37df3284	docs: 废止被取代的 Phase-13A 首轮报告与 V1.0 部署方案（原地重写，不用 git rm） ... - docs/Phase-13A-V11-Completion-Report.md：2026-09-08 首轮报告自报「✅ 核心链路已完成」， 已被 Phase-13A-V11-Recovery-Completion-Report-2026-09-17.md（CLOSED，Gate 全项通过）取代。 该文件因命名差异（`Phase-13A-` 带 13A、缺数字段）不匹配清理清单的 `Phase-XX-` 模式而漏删。 **原地重写为废止声明**而非 git rm —— 本机 safe-delete 钩子会把「删文件」放大为「删父目录」 （2026-09-18 实测：一次 git rm 导致整个 docs/ 被移除，已从 Git 完整恢复）。 - 部署架构、运维监控、备份恢复与升级方案.md：补 V1.1 取代头注（方案任务二点名要求，此前遗漏）。 另登记一份**不删**的：docs/Phase-V11-Deployment-Completion-Report.md（2026-09-09，含已被推翻的 「16/16 E2E 通过」）—— 它不在方案删除目标模式内，且被保留文档 Phase-01-V11-Recovery-Completion-Report-2026-09-09.md 援引，删除会制造悬空引用，保留待决。	2026-09-18 21:15:13 +08:00
WorkBuddy	f96dcb8aa6	fix(admin): 管理端入口收敛到 /admin/ 子路径，staging 端口 13521，修复生产 /admin/ 假成功 ... 承接 rc.15 的管理端端口收敛（3000 → 13520），本轮把「入口」也收敛到一处： - staging admin 发布端口 3001 → 13521（保持「生产 + 1」错开），同步 tests/uat/run-uat.sh 的默认 UAT_ADMIN_URL。 - 管理端产物改为 /admin/ 子路径部署：vite 构建 base=/admin/（dev 仍为 /，开发与 排查习惯不变）、router history base 跟随 import.meta.env.BASE_URL、三处容器化 入口（生产 nginx / 本地整套栈 nginx / admin-web 容器内 nginx）统一为「不剥离 前缀」转发，形态一致。 - 修复生产 nginx /admin/ 的假成功：原为 alias /usr/share/nginx/html/，而那正是 nginx:alpine 纯净镜像自带的默认页目录（管理端产物不在该容器内），访问返回 200 + nginx 欢迎页 —— 浏览器不报错、状态码正常，只是打开的不是管理端，比 404 更难发现。改为 upstream admin_web + proxy_pass，并以真实两跳容器实测： /admin/ → 200 且为管理端标题与 /admin/assets/*、/admin/dashboard → 200（SPA 兜底）、/admin/brand/logo-mark.png → 200、根路径 → 显式 404（用 location = / 钉住，不依赖「本配置恰好没有 server 级 root」这一偶然事实）。 - 品牌资源引用统一走新增的 src/brand.ts（public/ 资源不受 vite base 影响，原 5 处 写死根路径，子路径部署下会裂图）；favicon 由仓库内并不存在的 /favicon.svg 改为 存在的品牌标。 - 补全 tests/uat/run-uat.sh 被截断的尾部：原文件停在 `if [ -`，bash -n 不通过、 脚本根本无法运行；顺带把此前「定义了却无人消费」的 ADMIN_URL 接到管理端可达性 实测上，并补结果汇总与非零退出码。 - ui-tests：ui-document-baseline-contracts 新增两类一致性断言（staging 发布端口 ⇄ run-uat.sh 默认入口、子路径部署的五处约束）；admin-reference-contracts 的资产 断言适配 brand 模块（断言「组件经 brand 模块引用」+「brand 模块指向正式资产」）。 6 条新增断言全部经负向注入验证（注入对应缺陷 → 守卫变红且信息指向正确对象）。 验证：UI 门控 14/14 绿；vue-tsc EXIT=0；vite build EXIT=0 且产物资源均为 /admin/ 前缀；三份 nginx 配置 nginx -t 通过。 注：docs/STATUS.md 含此前的在途文档改动（非本次工作，且其中引用了已被删除的 plans 文件），故未纳入本提交；本轮的口径更新已写入该文件待一并处理。	2026-09-18 20:51:12 +08:00
WorkBuddy	16538d7af5	chore(docs): V1.0 前端设计文档归档至 docs/archive/design-v1.0；为仍被援引的 V1.0 总纲文档加取代头注 ... - git mv 4 份 UI 类文档（UIUX 视觉规范/组件库与 Design Token/高保真原型/页面级功能清单）入档， 附 README 说明取代关系：UI 域唯一基线为 docs/superpowers/specs/2026-09-13-* 规格 - 根目录两份 V1.0 WorkBuddy 提示词/总指令：加「已被 V1.1 整合版取代」头注，保留原位 （AGENTS_SUMMARY 与 Recovery 报告仍援引其行号） - REST API 规范：加「部分取代」头注（V1.1 增量以数据库与API增量设计为准；WebSocket 章节仍为协议出处） - 根 CHANGELOG.md：加指针指向 docs/V1_1_CHANGELOG.md - V1.0 业务设计 12 份与部署运维方案按用户决定保留原位不动	2026-09-18 20:25:58 +08:00
WorkBuddy	c77e6fcd63	chore(docs): 删除已被复验推翻或取代的失效历史文档（65 份） ... - V1.0 自报式 Phase-XX-Completion-Report 26 份（README 已声明其不可信） - V1.1 首轮 Phase-XX-V11-Completion-Report 21 份（已被对应 Recovery 版复验推翻/覆盖） - V1.0 时代审查/发布报告 13 份（CODE_REVIEW/FIX_PLAN/ISSUE_TRACKER/发布与 Go-NoGo/UAT/渗透测试/P0 指令/REAUDIT/两次评估） - 自declared被取代的旧计划 4 份（RECOVERY_PLAN_2026-09-09、当前进度校正、09-14 两份 superpowers 计划） - IDEA.md（一行备忘） 引用核查：代码/脚本/CI/配置零引用；STATUS.md 与 REMAINING_WORK.md 中两处现行引用随后续文档同步修正； Phase-10 Recovery 报告与 2026-09-13 UI spec 中的历史叙述引用按原文保留。 治理详情见 docs/文档治理报告-2026-09-18.md。	2026-09-18 20:23:43 +08:00
WorkBuddy	3ff0c0641a	chore(admin): 生产管理端端口 3000 → 13520；守卫扩至三处并容错 CI ... 生产 admin 容器发布端口原为 127.0.0.1:3000 —— 3000 是本机最易被其他项目 （videoos / ai-callcenter）抢用的端口，与新定的管理端端口 13520 不一致。 已改为 127.0.0.1:13520:80（仍绑定 loopback，对外访问走 nginx 80/443 + /admin/）。 ⚠️ 该实体改动无法进入本次提交：infrastructure/docker-compose.prod.yml 位于 .gitignore 的「Secrets and certificates」段，刻意不进版本控制（含按主机定制的 部署参数）。因此本次提交承载的是「决策记录 + 守卫」，端口改动只在部署机生效。 守卫 ui-tests/ui-document-baseline-contracts.mjs： - 由「两处一致」扩为「三处一致」：admin-web/vite.config.ts（权威声明）、 docs/STATUS.md（给人照做的）、docker-compose.prod.yml（生产发布端口）。 - 生产 compose 采取「存在才断言」：CI 全新克隆上该文件不存在，硬 read() 会抛 ENOENT 让门控假红。已实测——移走文件 → 打印 skip 且 EXIT=0；放回 → 断言恢复。 - 明确排除另外两处管理端入口并写清理由：本地整套栈的管理端经 nginx 6688 暴露 （6688 是 nginx 入口，不是纯管理端端口）；staging 的 3001 是为与生产同机共存 而按「生产 + 1」错开（5433/6380/8081/3001），且被 tests/uat/run-uat.sh 的 UAT_ADMIN_URL 默认值依赖 —— 改动它们要同步消费方，不该由本守卫断言等于 vite 端口。 docs/STATUS.md：新增「管理端端口口径」表，记录四种管理端入口的端口与取舍理由， 并显式标注生产 compose 不在版本控制内（否则后人会以为改了没生效）。 验证：ui-tests 门控 14/14；负向验证 prod compose 改回 3000 → 精准报 「docker-compose.prod.yml=3000，vite.config.ts=13520」；文件缺失 → skip 且不假红； 还原后 md5 逐字节一致（71a30653…）；docker compose config 解析出 published=13520 且 host_ip=127.0.0.1（loopback 绑定未丢失）。	2026-09-18 19:49:50 +08:00
WorkBuddy	9c26d4b7b2	chore(admin-web): 开发端口 3000 → 13520，并禁止端口静默漂移 ... 本机长期并行运行三个项目（videoos / ai-callcenter / 本项目），3000 属最易被 抢用的端口之一。按用户决定改为 13520。 - admin-web/vite.config.ts：server.port 3000 → 13520 - 同处新增 strictPort: true。vite 默认在端口被占用时静默 +1 退到下一个可用端口， 结果是「文档写 13520、实际跑在 13521」且全程不报错 —— 与本项目反复处理的 「声明与兑现失联」同族。加上后端口被占用会直接失败。 - docs/STATUS.md「当前运行状态」同步为 13520。 - ui-tests/ui-document-baseline-contracts.mjs：新增端口一致性守卫。 端口写在两处（vite.config.ts 是权威，STATUS.md 给人照做），只改一处不会让任何 测试变红，却会让照文档操作的人打不开页面。守卫断言的是「两处一致」而非写死 13520 —— 允许改端口，允许的是「一起改」，不是「只改一处」。 两处解析均用「解析失败即失败」写法，避免正则匹配不到时断言退化成与 undefined 比较而失去意义（本项目踩过的守卫静默失效坑）。 用 assert.equal 而非 assert.match：match 失败会把整份 STATUS.md（3000+ 行） 打进报错，噪声会盖掉真正的不一致信息 —— 负向验证时实测确认。 - .gitignore：忽略 admin-web/vite.config.ts.timestamp-*.mjs。 vite 在 dev server 被强杀（未优雅退出）时遗留该配置临时文件，本机已多次出现。 未改动（有意）： - CORS 不受影响。CorsConfig 默认拒绝所有跨域是刻意设计，且注释已写明「管理端走 Vite 代理（同源）」—— dev 端口变化不产生跨域。 - infrastructure/docker-compose.prod.yml 的 127.0.0.1:3000:80 是生产 admin 容器 的发布端口，与开发服务器无关，未动。 - releases/v1.0.0-RC.* 内的 3000 为历史发布快照，属冻结记录，不改写。 验证 - UI 契约门控 14/14 全绿（含新增守卫）；vue-tsc --noEmit EXIT=0。 - 负向验证：把 STATUS.md 改回 3000 → 守卫变红并精确报出 「管理后台端口不一致：STATUS.md=3000，vite.config.ts=13520」及行号；还原后复绿。 - 真实启停：dev server 实跑 http://localhost:13520/（HTTP 200），旧端口 3000 无监听。 - strictPort 负向验证：端口被占用时第二实例立即以 「Error: Port 13520 is already in use」退出，未漂移到 13521。 - vite build EXIT=0（19.35s）。 注：vite build 直接执行会失败，栈停在 emptyDir(dist) 且全部位于本机 node-safe-delete-shim（批量删除守卫）内，与本次改动无关；改用全新 outDir 复跑即 成功，据此排除「改动导致构建失败」。该现象此前无记录，已写入技能备查。	2026-09-18 19:36:07 +08:00
WorkBuddy	c561bf46af	docs(idempotency): 统一报告中的计数口径（25 处调用点 / 30 处声明）并补 CI E2E 缺陷到结论行	2026-09-18 16:40:09 +08:00
WorkBuddy	2766e53fe2	docs: 幂等键检修报告；勘误 API_INVENTORY 与 HTTP 报告；同步 STATUS/JIRA ... 新增 docs/幂等键检修报告-2026-09-18.md：记录双向断裂（后端零处读取该头、 前端 Date.now 每次生成新键）、五处审计发现、机制设计与五个取舍 （先占位后执行 / 重放 / 失败释放占位 / 孤儿占位接管 / 作用域含 actor_id）、 列类型不变量扫描、E2E 与守门证据、三处同形状问题的连带修复。 同轮勘误： - docs/HTTP语义检修报告-2026-09-18.md：其中「Idempotency-Key 已支持」一句 在写下时不成立（后端当时零处读取），已显式标注勘误并保留原文， 以免「结论先于核实」被当作既成事实继续引用。 - docs/api/API_INVENTORY.md：原记载 POST /activities/{id}/interests 「提交活动互选」，后端从未实现（Phase 16 已并入 /feedback 的 interestTargetUserIds），按真实端点重列并附勘误说明。 docs/STATUS.md：迁移范围更新为 V001~V046；回归行更新为 669 / 0 / 0 / 3； 新增「幂等键检修」章节；补登 HTTP 语义检修章节在两份文档中的缺失条目。 docs/JIRA_BACKLOG.md：补登 HTTP 语义检修与幂等键检修两行 （此前均未登记）。	2026-09-18 16:37:47 +08:00
WorkBuddy	af5412646b	test(e2e): 运营登录只用 seed 账号；补幂等 E2E 与两处机械守卫 ... 1) 修复一处从未暴露的 CI 缺陷 库中 operator 账号没有任何迁移种子，DemoDataSeeder 也不创建运营账号 （只统计数量），全新库唯一的账号来源是 seed_e2e_operators.sql。 而 conftest 的 admin_token 写死 username="admin" —— 那是某台开发机上 手工创建的遗留账号：本机有它所以本地一直跑绿，CI 全新库没有它 → 该 fixture 必然 401 → e2e job 从未真正通过过。 同一文件里「外加迁移 seed 的 admin」这句注释也是纯粹的虚构。 改用 seed 创建的 e2e_admin（已绑定 super_admin，语义等价）。 2) fixture_account_guard_test.py（2 用例） 机械拦住「fixture 依赖本机手工数据」：从 seed SQL 解析账号清单， 扫描 conftest 的所有登录用户名，任何一个不在 seed 内即变红； 另一条锁住推理前提（迁移里确实没有 operator 种子）。 两条都带「解析失败即失败」断言 —— 守卫自身静默失效是本项目反复踩过的坑。 3) idempotency_test.py（7 用例） 同键重放响应逐字节相同、同键重复提交只产生一条记录、body 字段幂等未回归、 不同键相互独立、同键作用域按 actor 隔离、5 线程并发同键业务恰好落库一次、 无键重复 Like 不得返回 500。 4) conftest.ApiClient.call 支持 headers 覆盖，供幂等用例携带自定义键。	2026-09-18 16:37:33 +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
WorkBuddy	69cf6a2cc7	feat(idempotency): 为 30 个写端点实现 Idempotency-Key ... 规范第八章要求 7 类写端点支持 Idempotency-Key，第 146 章验收口径为 「最终不能生成重复核心数据」。检修前的实际状态：后端零处读取该头， 小程序 25 处调用点发送全部石沉大海。 一处实现、零业务代码改动、逐端点声明： - V045 新建 idempotency_records + 唯一索引 uk_idempotency_scope - V046 修正 actor_id 列类型 VARCHAR -> uuid（见下） - IdempotencyInterceptor：先占位后执行 / 重放首次响应 / 处理中回 409 / 孤儿占位 300s 可接管 / 失败释放占位 - IdempotencyResponseCacheFilter：缓存响应体供逐字节重放 - WebMvcConfig：本项目第一个通用 WebMvcConfigurer - @Idempotent 声明 30 处（含补 CheckinController 手工签到的漏标） - GlobalExceptionHandler：IllegalStateException（30 处业务状态冲突）与 DuplicateKeyException（并发重复提交的最后防线）此前均无映射 → 落 500， 而 500 的语义是「可重试」，调用方于是重试并制造更多重复。现映射为 409； 刻意不映射父类 DataIntegrityViolationException（CHECK 违反应由 500 暴露）。 - schema-h2.sql 补 idempotency_records V046 的必要性：项目全局注册的 UUIDStringTypeHandler 对任何合法 UUID 形式的 String 参数以显式 uuid 类型发送，而 SQL 侧 stringtype=unspecified 只影响以 unknown 类型发送的参数，覆盖不到它。因此真正的不变量不是「JDBC 参数配好了」， 而是「列类型必须是 uuid」。V045 初版把 actor_id 建成 VARCHAR(64) 时， 带幂等键的请求在真实 PG 上全部 500。 全库扫描确认该不变量已收敛：所有 *_id VARCHAR 列中 actor_id 是唯一违规， client_message_id / provider_request_id 为外部 id， resource_id / source_id 在 Java 侧零处作查询条件。	2026-09-18 16:37:11 +08:00
WorkBuddy	ed725daccd	docs(status): record identity scope convergence and the PathPattern ** trap	2026-09-18 15:06:06 +08:00
WorkBuddy	cbb4f64fdc	fix(security): stop operator identity from reaching user endpoints; guard path rules ... Continues the HTTP-semantics work. Fixing 401/403 exposed a worse defect on the same axis: who is allowed to reach which endpoint. Root cause chain: - PlatformPrincipal has two implementations (OperatorPrincipal / UserPrincipal), chosen by JwtAuthFilter from the token type. - `@AuthenticationPrincipal UserPrincipal` against an OperatorPrincipal is a type mismatch, and Spring Security returns null (errorOnInvalidType defaults to false) instead of failing. - 244 uses of that annotation repo-wide; only 48 null-check. The rest NPE -> 500 when reached with an operator identity. - The fallback rule was `.authenticated()`, which an operator token satisfies, so such requests did reach user-facing controllers. Adding ~196 null checks would be mechanical, easy to miss, and does nothing to constrain future code. The mismatch is between identity type and endpoint, so it is fixed once, at the authentication layer: the fallback becomes `.hasRole("USER")` (operator -> ROLE_OPERATOR, user -> ROLE_USER, per JwtAuthFilter). Operator requests to user endpoints now get 403 before any controller runs. Trap worth recording: operator endpoints are not all under /operator/ — /counseling/services/operator/queue, /content/operator/articles, /activities/operator/checkin/scan, /service-appointments/operator/list and others sit deeper inside business paths. The first attempt covered them with `requestMatchers("/**/operator/**")`, which fails at runtime: PatternParseException: No more pattern data allowed after {*...} or ** pattern element Spring's PathPattern permits `**` only as the final element. Worse, the symptom is a 500 from the whole filter chain (Tomcat HTML error page, not our JSON), and E2E went from 37 passed to 33 failed — an error far removed from its cause. Now the nine prefixes are listed explicitly, each ending in /**. Because explicit enumeration can be forgotten as endpoints are added, and because the failure mode is "operators locked out of their own admin module" (invisible to user-side tests), SecurityPathCoverageTest parses the OPERATOR rule prefixes out of SecurityConfig source, walks every *Controller.java, joins class-level and method-level mapping paths, and asserts every path containing /operator/ is covered (/auth/operator/** excluded by design). Two things that would silently neuter it, both handled: it must parse only the .hasRole("OPERATOR") chain — pulling in the permitAll or fallback rules would mark everything covered — and the test working directory is the repo root, not the Maven module root. Verification: negatively validated by removing /content/operator/** -> exactly one test turns red listing the six affected ContentController endpoints; restored. E2E 40 passed (37 + 3 identity-isolation cases). Backend regression 664 / 0 failures / 0 errors / 3 skipped.	2026-09-18 15:05:41 +08:00
WorkBuddy	3a4e03a9f9	docs(status): record HTTP semantics remediation; note 3 test assertions that encoded old wrong behavior	2026-09-18 14:38:59 +08:00
WorkBuddy	7682abd85c	fix(api): give failures real HTTP semantics; fix 401/403 confusion and CORS default ... Phase 23B ended with an E2E assertion changed to expect "HTTP 200 + body.code == BAD_REQUEST", documented at the time as "this project's convention". That description was accurate about the code and wrong about the intent: it described a defect, and I made the test accommodate it instead of fixing it. Auditing it found the convention was already broken, not merely risky: - ~100 sites (105, across 30 controllers) do `return ApiResponse.error(...)` / `forbidden()` / `notFound()` with no exception and no `@ResponseStatus`, so the HTTP status is always 200. Gateways and APM cannot separate 4xx from 5xx; callers cannot tell "fix your request" (400) from "don't retry" (403) from "check state first" (409) from "retry later" (429). - miniapp/utils/api.js already had 401/403/429 branches that could never be reached, since the backend never returned those codes. The concrete damage: an expired token returned 403, so `onSessionExpired` never fired and users were stuck with no way back to the login flow. - SecurityConfig had no `authenticationEntryPoint`, so Spring's default `Http403ForbiddenEntryPoint` returned 403 for unauthenticated calls, with a framework body that has no `code` field at all. - CorsConfig defaulted `allowed-origins` to `*` together with `allowCredentials(true)`, while its comment claimed "localhost only by default". Comment contradicting code is worse than no comment: it reads as safe. - Only 4 files / 15 assertions in the whole backend suite touched HTTP status, which is how this survived. Approach: one definition, two applications, zero controller changes. - ApiResponseCode gains an `httpStatus` field — the single source of truth. The constructor requires it, so a new code cannot be added without one. - GlobalExceptionHandler reads status from the enum instead of hardcoding `@ResponseStatus` per handler. - New ApiResponseStatusAdvice (ResponseBodyAdvice) fills in the status just before the body is written, covering all ~100 direct-return sites without touching them. Two constraints, both noted in code: only downgrade when the current status is still 2xx (the advice also sees exception-handler results, and must not override an already-correct 401/403/409), and never alter the body. - SecurityConfig: entry point returns 401 with a uniform ApiResponse body; access denied handler returns 403 likewise. - CorsConfig: default changed to empty (deny). Both clients are same-origin anyway — nginx proxies /api/ and Vite proxies /api — so nothing depends on it. - miniapp api.js: 401/403/429/409 branches now prefer the server's `body.message`, otherwise "账号已被封禁" would be flattened to "无权限访问". Implementation trap worth remembering: `ServerHttpResponse` has `setStatusCode` but no getter, so reading the current status requires casting to `ServletServerHttpResponse`. Verification: 37 E2E passed (33 + 4 new contract cases), including a live-stack check that a controller's direct `notFound()` now yields 404 — that path throws no exception and never reaches the exception handler, so if the advice were inactive it would silently return 200 while the enum unit tests stayed green. Backend regression 662 / 0 failures / 0 errors / 3 skipped (+6 new guards). The first regression run had 3 failures, all tests asserting the old wrong behavior (anonymous access expected 403; outsiders reading a conversation expected 200). Fixed the assertions, not the implementation. Where 404 is used instead of 403 for "invisible", that is deliberate — it prevents probing whether another user's conversation exists — and the substantive assertions (e.g. that an unauthorized response must not leak message bodies) were kept. Not done, needs a product decision: third-party credential issuance, whether rate limiting is actually active, publishing OpenAPI externally, per-caller audit and quotas, pagination/idempotency coverage, desensitization boundaries.	2026-09-18 14:34:58 +08:00
WorkBuddy	730dddde30	test(e2e): Phase 23B — rebuild E2E infrastructure; fix 6 real prod defects it exposed ... Phase 23 closed as PARTIAL: fake coverage was gone, but the E2E layer itself was still empty — no conftest.py anywhere, ~15 fixtures that never existed, 6 files crashing at import on os.environ["E2E_PASSWORD"], and CI never ran E2E. STATUS's "10 E2E files / ~80+ cases ✅" described files that had never executed. Infrastructure delivered: - tests/e2e/conftest.py: ApiClient (trust_env=False — a host http_proxy turns localhost calls into 502), operator_token(username) / new_user / admin_token fixtures, and a session probe that calls pytest.exit(4) when the stack is unreachable. NOT skip: skip would launder "did not run" into "passed". - pytest.ini, tests/e2e/requirements.txt, and tests/e2e/sql/ seed_e2e_operators.sql — migrations contain NO operator seed at all, so a fresh database has zero logins; the seed creates 6 e2e accounts with role bindings, idempotent, password injected via `psql -v pwd`. - CI job `e2e`: compose up -> poll /health/live (timeout = fail) -> seed -> pytest -> always teardown. Gate D-23-D is now closed. - 8 E2E files migrated off import-time env reads; tautological assertions (`x == t or not x`), a counselor token standing in for content_editor, and a bare `status_code == 200` claiming to prove INV-020 were replaced with real permission/behavior assertions. Six real production defects found only by running against real PostgreSQL (H2 has zero coverage for all of them): - D-23B-A (Critical): stale V042__add_appointment_operator_register_permission.sql left in target/classes; src had replaced it with V042__add_service_location_ announcements.sql. Packing without clean put two V042 in the jar -> Flyway "Found more than one migration with version 042" -> app would not start. Guard added: testBuildOutputHasNoDuplicateMigrationVersions scans build output (src is clean, so only this catches it). - D-23B-B (High): non-UUID path variable reached the DB -> 500 + leaked `invalid input syntax for type uuid`. Now rejected at the controller. - D-23B-C (High): 6 E2E files raised KeyError at import -> never collected. - D-23B-E (Critical): permissions = 48, role_permissions for super_admin = 18, matchmaker = 0. V015's "grant all to super_admin" was a point-in-time snapshot; the 30 permissions added later were never granted. On a fresh stack an admin cannot create a service station and matchmakers can do nothing. V044 restores super_admin to its documented definition (not an expansion); the matchmaker permission set needs a product decision and is left as a residual. - D-23B-I (Medium): IllegalArgumentException (e.g. invalid activity type) was unmapped -> 500. Now BAD_REQUEST. - D-23B-J (High): `operator does not exist: uuid = character varying` — Java ids are String, columns are uuid, PostgreSQL does not implicitly cast in comparisons. Fixed at the source with JDBC `stringtype=unspecified` (docker profile); production datasource comes from deploy env and needs the same. One judgement retracted: an initial read suggested service_appointment.register was missing. It is not — the endpoint uses service.assisted_registration, seeded in V029, and the code deliberately avoids a duplicate permission. Nothing was changed on that basis. Verification: 33 E2E passed against a live stack; unreachable stack and a missing operator password both exit 4 (never skip/pass); backend regression 656 / 0 failures / 0 errors / 3 skipped (baseline 655, +1 guard, negatively validated by injecting a duplicate V042 -> exactly one test turned red).	2026-09-18 13:50:19 +08:00
WorkBuddy	ae1bd2b734	test(phase23): KEEP-VERIFY — remove 44 pass shells + fake INV tests, add shell guard ... Phase 23 "可信系统测试重建 (REFACTOR)" re-audit. STATUS claimed "10 E2E files / ~80+ cases" and "INV-011~020 ✅"; measurement showed the opposite. D-23-A (Critical): V11InvariantsTest's 14 cases asserted only Constants strings. INV-016 "Banner target types" actually asserted ARTICLE_STATUS_*; INV-017 "home 8 entries" declared local arrays then asserted firstRow.length == 4 (tautology, never called the home service); INV-018/019/020 used appointment/article/account status constants as stand-ins for permission and data-scope checks. Rewritten to 12 cases: 4 real service-behavior guards (INV-013 via real CounselingService.getDetail — Matchmaker sees null userRequestSummary, with an assigned-Counselor counter-proof so global sanitization cannot fake a pass; INV-016 reads the production ALLOWED_TARGET_TYPES whitelist and asserts no external/http/url/ web entry; INV-017 calls real getHome and pins all 8 codes + order; INV-019 asserts content_editor reads null), plus assertBehaviorTestExists turning "行为验证见 XxxTest" pointers into executable Class.forName contracts. D-23-B (High): 44 `pass` shells across 6 files in tests/e2e (4 files were 100% shells). Gate forbids skip/pass shells. Rewritten in place as honest placeholders with the full scenario lists preserved. D-23-C (High, residual): the pytest E2E suite is not executable at all — no conftest.py anywhere, ~15 fixtures (api_client/verified_user/ banner_factory/...) do not exist. Only run_v11_tests.py really runs (16 cases, needs a live stack + E2E_PASSWORD). D-23-D (High, residual, NOT fixed): CI does not chain E2E as the plan requires. Needs an infrastructure decision on how CI provisions a live stack; not implemented rather than written unverified. D-23-E (Medium): the CI migration job claimed to "验证 migration SQL 语法" but only checked file non-emptiness, while the real syntax/baseline checks live in MigrationValidationTest (already run by the backend job). Replaced with a real sequence check (naming / non-empty / unique versions / no gaps); verified by extracting the exact inline script and running it. New gate: scripts/check-no-empty-tests.py (AST scan, blocks pass-only and unconditionally skipped tests) + a CI test-shell-guard job. Verified both ways: 0 findings on the real tree, 2 precise findings on injected shells. Negative validation: 3 injected production defects (external_url in the banner whitelist, swapped home entry order, isMatchmaker returning the full record) turned exactly inv016/inv017/inv013 red, 9 others green, zero unrelated failures; md5sum -c confirmed byte-identical restore. Full regression: 655 tests / 652 passed / 0 failures / 0 errors / 3 skipped (baseline 657; -2 because 14 vacuous cases were merged into 12). The 3 skips carry explicit reasons (2x @EnabledIfEnvironmentVariable(CI=true), 1x @Disabled "需要完整数据库连接") — none is a shell. Phase 23 is PARTIALLY closed: fake coverage is gone, but the UAT gate requires the end-to-end chain to actually execute, so "失败为零可进入 UAT" is NOT claimed.	2026-09-18 11:49:18 +08:00
WorkBuddy	050d005c0a	docs(status): correct two stale duplicate Phase 22 ✅ tables disproved by KEEP-VERIFY ... STATUS.md contained two duplicate legacy Phase 22 blocks still claiming: - "application.yml 默认配置 ✅ (15个V1.1 flag)" / "application-dev.yml + application-docker.yml 配置 ✅" — verified false: all four yml files (application.yml / -dev / -docker / -production) contain neither a `features:` block nor any flag key; defaults are Java field defaults only. - "P22-T01..T05 ✅" and "P22-T07 ✅" — these are dead config: zero business call sites for the five module toggles, zero references for the private storage bucket flags. Both blocks now carry a "superseded by the 2026-09-18 authoritative section" notice with per-row measured verdicts (T06 remains ✅ as genuinely enforced). No code change; doc-only.	2026-09-18 11:08:12 +08:00
WorkBuddy	2fbdbc32d0	fix(feature-flags): close Phase 22 KEEP-VERIFY — 2 real defects + doc overclaims ... KEEP-VERIFY re-audit of the Feature Flag configuration extension (STATUS's "Phase 22 部署运维配置扩展"): marked ✅ but contained real code defects and overstated completion. Real defects fixed: - D-22-A (High): FeatureFlagController.updateFlag used reflection `getMethod("set"+cap, boolean.class)` and only supported boolean flags. 7 non-boolean flags (livenessProvider, localEvidenceAllowedTypes, counselingAttachmentsBucket, localEvidenceMaxFiles, localEvidenceMaxFileSizeMB, localEvidenceRetentionDays) failed to update via the API. Now dispatches by field type (boolean/int/String). - D-22-B (Medium): `body.getOrDefault("value", false)` silently set false when value was missing and crashed on non-boolean casts. Now returns 400 on missing value / type mismatch and leaves the original value unchanged. Doc overclaims corrected (no silent scope creep): - T01-T05 module-toggle flags (isCounselingEnabled etc.) have zero business call sites -> dead config (exposed but not gating). Left for each module's own phase to wire; documented as residual. - T07 private-storage bucket flags have zero references; storage already uses object-storage.bucket-private. Documented as residual. - STATUS claimed "application.yml defaults (15 flags)"; yml has no `features:` block, defaults are Java field defaults. Functionally fine, docs corrected. T06 upload policy verified actually enforced in LocalEligibilityService + PhotoService (kept ✅). Guard tests: new FeatureFlagControllerTest (7 cases: 21 keys exposed, boolean/ string/int update reflected, unknown flag / missing value / wrong type -> 400). Negative validation: reverting to boolean-only dispatch made exactly 2 update cases fail red, then green after restore — proves guards are real. Full regression: 657 tests / 0 failures / 0 errors / 3 skipped (baseline 650, +7).	2026-09-18 11:00:08 +08:00
WorkBuddy	0580da0c62	fix(account-lifecycle): close Phase 21 KEEP-VERIFY — 6 real defects + fake-green tests ... KEEP-VERIFY re-audit of account lifecycle (EXTEND): STATUS marked ✅ but contained hard Gate violations and dead code. Real defects fixed: - D-21-A: AuthService.checkAccountStatus did not reject CLOSED → closed account could still log in (Gate ❌→✅); added CLOSED branch before BANNED/SUSPENDED. - D-21-B: notifyActiveMatches was a TODO stub → active Matches/conversations not closed on withdrawal (Gate ❌→✅); now finds active matches, sets UNMATCHED + closes conversation via chatService.closeConversationForMatch. - D-21-C: cancelPendingActivityRegistrations was a TODO stub → future activity registrations not cancelled (Gate ❌→✅); now cancels pending/approved. - D-21-D: anonymizeServiceHistory existed but was never wired into closeAccount → personal identity + counseling text leaked (Gate ❌→✅); wired in, anonymizes id_number/real_name with placeholder, plus counseling_followups content. - D-21-E: closeAccount hard-threw on blockers → all cancelXxx unreachable (dead code contradiction); changed to informational log + continue cleanup. - D-21-F: 7× assertTrue(true) fake-green tests → replaced with 11 real DB integration tests + 3 login-guard tests (Redis-decoupled via ReflectionTestUtils). Cross-module defenses (RecommendationEngine/MatchEligibility/Capability reject non-NORMAL) confirmed effective. Remaining (no silent scope creep): matchmaker in-progress interception still hardcodes 0 (no table), data retention delete flow is a product decision, privacy-settings endpoint stub. Full regression: 650 tests / 0 failures / 0 errors / 3 skipped (baseline 648, +2).	2026-09-18 10:12:34 +08:00
WorkBuddy	22c778b111	fix(analytics): close Phase 20 KEEP-VERIFY — 20 defects (fake metric definitions, hardcoded zeros, systemic soft-delete leak, module-wide 403, fake-green tests); add MetricCatalog + unified calculator + V043 grants + 51 guard tests; full regression 648 green ... 口径造假： - D1 实名人数用 user_profiles.profile_status != 'rejected' 冒充 → in_progress/need_edit 被算成已实名 - D3 Chat Started 直接数会话行数 → system/risk_notice 系统通知计入 - D4 Match 不分来源 → 活动 10 对互选被当 10 对成功引用（Gate） - D6 Banner 曝光/点击硬编码 0 → 改返回 null + NOT_INSTRUMENTED 标记 死代码 / 占位： - D5 活动漏斗全部硬编码 0 + 一行把"用户数"当"活动数"的死代码 - D20 getDailySummary(days) 无边界校验 系统性软删缺陷（D12）： - BaseEntity.deletedAt 无 @TableLogic 且全局无逻辑删除配置 → selectCount 把软删数据全部计入统计且无任何报错 - 修复 45 处统计调用显式 deleted_at IS NULL（2 轮复验，首轮漏扫 5 处次级路径： 服务用户数分域明细 / 服务站统计 / 性别与年龄分布） 结构类： - D15 Dashboard/用户漏斗/专项页各实现一遍同名指标且互不相同 → 抽 AnalyticsMetricsCalculator 统一口径 权限（Gate ⑩）： - data_viewer 在 V001 定义却全仓从未授权（空壳角色） - platform_admin 的 V015 扩展条件 id >= '20000000-…' 漏掉 V1.0 老权限段 → 整个 Analytics 模块除 super_admin 外全员 403 - V043 授予两角色；刻意不授予 organization_admin（相关表无组织维度，无范围全量即越权） 假绿测试： - 删除 AnalyticsServiceTest（5× assertTrue(true)，零断言） 新增： - 指标字典 MetricCatalog（36 指标 × 12 字段）+ MetricStatus/MetricDefinition + docs/ANALYTICS_METRICS.md - 守卫 51 用例：MetricCatalogGuardTest(11) / AnalyticsMetricsPhase20IntegrationTest(21) / AnalyticsSoftDeleteGuardTest(4，结构性) / AnalyticsPermissionGrantTest(6) / LocalEligibilityStatusVocabularyGuardTest(9) 跨阶段修复（缺陷本体属账号生命周期模块，按"发现即修"处理）： - X1（Critical）注销写入 user_identities 状态域的 'failed' → 违反生产 V017 chk_elig_verify_status → 真实 PG 上 closeAccount 事务回滚、账号注销 100% 不可用（负向验证实测 DataIntegrityViolation） - X2 checkCanWithdraw 资格拦截用 submitted/pending（该表永不可能出现）→ 死代码 - X3 测试库补 chk_elig_type/chk_elig_verify_status，暴露 ActivityPhase14Test 夹具违规 验证： - 负向验证两轮共 7 处注入 → 7 个用例精准变红且无无关失败（一处被源码结构+运行时行为两层捕获） - 还原后 md5sum 逐字节一致，NEG-VAL 残留 0 - 后端全量 648 tests / 0 failures / 0 errors / BUILD SUCCESS；admin-web vue-tsc EXIT=0	2026-09-17 23:25:31 +08:00
WorkBuddy	ff22c0d06a	docs(phase19): cite the recovery tag instead of a moving commit sha	2026-09-17 22:25:10 +08:00
WorkBuddy	d74f0ea099	docs(phase19): record tag/bundle location + commit sha in the recovery report	2026-09-17 22:24:56 +08:00
WorkBuddy	72b4e9b846	fix(ops-backend/service-station): close Phase 19 KEEP-VERIFY — 25 defects (unreachable announcements + station write privilege escalation; banner 500 + soft-delete leak; content publish dead-end; program approval dead-end/draft leak/zero counts/missing withdraw; zero-coverage test schema) ; add V042 announcement chain + 34 guard tests; full regression 602 green ... Backend - Service Station: expose the 「临时公告」 chain end-to-end (V042 table/service existed but had ZERO endpoints -> both admin and miniapp could never reach it): 5 operator endpoints (list/create/update/publish/archive) + 1 user-facing read endpoint. - Fix privilege escalation: create/update were guarded only by the class-level service_location.view, making V015's service_location.manage a never-used dead permission -> read-only roles could edit stations. Permissions moved to method level. - Add ServiceLocationOperatorController to OperatorEndpointPermissionCoverageTest (it was NOT scanned, which is why the escalation stayed invisible). - Add create/update validation (address NOT NULL + status CHECK only blew up on PG). - Banner: validation failures threw bare RuntimeException -> 500; now VALIDATION_ERROR -> 400. Add deleted_at IS NULL to both home queries (soft-deleted banners stayed live). - Content: operator list/detail split (admin «publish» was a dead end because it reused the published-only public API); category deactivate/reactivate; article body on edit. - Service Program: operator member list now includes pending (approval reachable); active-only public visibility (draft leak); memberCount/pendingCount aggregation; withdraw/removeMember; reuse row on re-apply (UNIQUE(program_id,user_id) crash). - MeController: add the missing GET /me/service-history route. Schema / guards - schema-h2.sql: add service_location_announcements (+ chk_announcement_status) and content_categories (+ uk_content_category_code, chk_category_status); move both into REQUIRED_IN_TEST_SCHEMA. MigrationValidationTest baseline 41 -> 42. - V11PermissionMatrixContractTest now scans ALL migrations instead of hardcoding V015+V029. - New: ServiceLocationAnnouncementPhase19IntegrationTest (24), ServiceLocationControllerPermissionContractTest (5), ServiceLocationAnnouncementConstraintParityTest (5, prod DDL <-> test schema <-> backend whitelist <-> admin labels). Frontend - admin-web: ServiceStationView gains announcement management (statuses, create/edit, publish/archive with confirm, expiry); write buttons gated by service_location.manage. - miniapp: U50 renders the 临时公告 block via new serviceStationService; page no longer talks to utils/api directly; announcement failure degrades to [] instead of erroring. - ui-tests: U37 four-group + U50 announcement contracts; /home assertion retargeted to the service layer. Verification - Negative verification: 3 injected defects (drop soft-delete filter / drop test-schema CHECK / downgrade write endpoint to view) -> 4 named tests fail precisely, no collateral failures; restored, NEG-VAL residue = 0. - Backend full regression: 602 tests, 0 failures, 0 errors, 3 skipped (baseline 420). - admin-web: vue-tsc --noEmit EXIT=0, vite build EXIT=0. Miniapp: tsc --noEmit EXIT=0. - ui-tests 14/14 PASS.	2026-09-17 22:21:31 +08:00
WorkBuddy	3f60611a74	fix(appeal): close Phase 18 KEEP-VERIFY — 8 defects (zero-coverage appeals table + 6 fake-green tests; operator-notification FK crash; appealType CHECK; escalated dead-end; processAppeal race; soft-delete filters; hardcoded resolved; evidence contract); add AppealPhase18IntegrationTest (15); full regression 494 green	2026-09-17 21:07:25 +08:00
WorkBuddy	307c9efb36	fix(risk/report): close Phase 17 KEEP-VERIFY/EXTEND — 6 defects + 1 hidden compile defect (jakarta) + test-coverage blind zone (3 missing tables); add sensitive-access audit + ReportAndRiskPhase17IntegrationTest (7); full regression 488 green	2026-09-17 20:42:09 +08:00
WorkBuddy	556f95a562	fix(activity-mutual): close Phase 16 KEEP-VERIFY/EXTEND — 7 defects + 1 hidden compile defect (reopenEpisode) + 1 test-fidelity; unify dual-impl to confirmActivityInterest; INV-006 fix; +7 tests (481 green)	2026-09-17 16:47:10 +08:00
WorkBuddy	29112eed6e	fix(activity): close Phase 15 KEEP-VERIFY/EXTEND — 2 critical + 14 other defects, 3 test-fidelity fixes ... Phase 15 (activity registration / review / checkin) verification closure. Two CRITICAL defects, both "production always had it, test schema never did": - D1: generateCheckinToken wrote the token to Redis with value "used", while scanCheckin rejects any token marked "used" -> every freshly issued check-in code was dead on arrival, staff scanning failed 100% of the time. Issuing now writes "issued"; "used" is set only after a successful scan. - D9: UNIQUE(activity_id, user_id) exists in production, but re-registering after cancel/reject went through INSERT -> users who cancelled once could never register for that activity again (duplicate key 500). The H2 test schema lacked the UNIQUE, so the path had zero coverage. Now the original row is reused via an atomic conditional UPDATE. Checkin (D2-D8): - D2: duplicate check-in was read-then-write; now atomic checkinIfNotCheckedIn and repeat scans are idempotent (alreadyCheckedIn) without duplicate audit. - D3: no data scope at all -> added activity staff assignment (V040) and assertCheckinScope; INV-020 (org relation grants nothing). - D4: manualCheckin did not validate activity existence/cancellation. - D5: getCheckinStats NPE on missing activity; remainingCount was semantically "free seats" -> replaced with notCheckedInCount. - D6: malformed timestamp caused 500 -> 400. D7: constant-time signature compare. Registration / review / cancel (D10-D13): - D10: backend registration list only queried status='approved' -> the review screen never saw pending rows (review unusable). - D11: registration_start_at / registration_end_at were never enforced. - D12: cancel had no audit log (the only write without one). - D13: reject/cancel were read-then-full-update -> rejectIfPending/cancelIfActive. Capacity groups (D14, plan item 2): groups were stored and read back but never participated in capacity -> incrementIfAvailable / decrementIfPositive now make approved_count real; activities without groups are unaffected. Frontend contract (F1-F2): - F1: admin-web had no check-in surface at all -> ActivityCheckinView.vue (paste/scan token, manual check-in, stats) + /activities/checkin route & nav. - F2: miniapp had no cancel-registration wrapper although the endpoint existed. Test fidelity (T1-T3): - T1: test schema gained UNIQUE(activity_id,user_id) + chk_reg_status + chk_checkin_status; two new guards parse the real V010 DDL and compare. - T2: 3 assertTrue(true) placeholders in CheckinServiceTest (covering duplicate check-in, expiry, no-sensitive-plaintext) replaced with 5 real guards that parse the real source and real production DDL. - T3: activity_registrations + activity_staff_assignments moved into REQUIRED_IN_TEST_SCHEMA; MigrationValidationTest baseline 39 -> 40. Note: ActivityStaffAssignment must NOT extend BaseEntity - the table is a composite PK (activity_id, operator_id); BaseEntity would add id/updated_at/ deleted_at to every INSERT and break on PostgreSQL (caught by EntityMigrationParityTest immediately). Tests: ActivityPhase15Test (21), CheckinServiceTest (5), 2 new constraint guards. Negative verification: 3 injected defects -> 8 assertions turned red, all restored. Regression: 474 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS (baseline 450). admin-web vue-tsc 0 error, vite build OK.	2026-09-17 15:07:52 +08:00
WorkBuddy	755a570849	fix(activity): close Phase 14 KEEP-VERIFY/EXTEND — 11 backend + 3 frontend-contract + 2 test-fidelity defects ... Phase 14 (multi-type public-welfare activities) verification closure. Backend (D1-D11): - D1 CRITICAL: ActivityMapper.countRemainingCapacity had no @Select and no XML -> activity detail / register / approve all threw Invalid bound statement. Removed the shell; unified on ActivityRegistrationMapper. - D2 CRITICAL: register & approve were read-then-write -> oversold under concurrency. Replaced with single atomic SQL (insertIfCapacityAvailable / approveIfCapacityAvailable, affectedRows==0 => full). - D3 HIGH: activityType / orgRole never validated against production chk_activity_type / chk_org_role -> 500 only on PostgreSQL. - D4 HIGH: ActivityListItemDTO had no activityType -> miniapp category tabs always empty (Gate failure). - D5: male/female counts were fabricated as approvedCount/2; now real aggregation over user_profiles.gender. - D6: minAge/maxAge was a TODO no-op; added assertAgeInRange. - D7: registration_policy write-only; per-type eligibility now enforced (identity / local eligibility / gender quota). - D8: POST /operator/activities dropped type, multi-org and capacity groups and set organizer_org_id to the operator user id; now delegates to createActivityFromAdmin (single implementation). - D9: three operator write endpoints were mounted on the user-side ActivityController (dual implementation, zero callers) -> moved. - D10: NPE on soft-deleted activity in getMyActivities; NPE/500 on missing admin form fields (Instant.parse(null)); tolerant time parsing added. - D11: DTO lacked registeredCount / status / coverFileId / description -> card always showed 0 registered, "view detail", no cover, no summary. Frontend contract (F1-F3): - F1: miniapp category code "classroom" is not in the production whitelist (should be relationship_education); three types had no tab at all. - F2: ui-activity-card read 7 fields that do not exist on the backend; now reads only real DTO fields, plus per-type badge and eligibility hint. - F3: admin-web had no activity management page at all; added ActivityManagementView.vue (type-driven dynamic form, multi-org, capacity groups, publish/cancel) + /activities route and nav entry. Test fidelity (T1-T2): - T1: deleted two assertTrue(true) placeholder tests (testNoOverbooking, testNoDuplicateRegistration) that covered the exact broken invariants. - T2: test schema lacked V023 columns/constraints and three tables; the activity tables were only in the OPTIONAL set (zero coverage) -> schema completed and moved to REQUIRED_IN_TEST_SCHEMA. Tests: ActivityPhase14Test (23 cases), ActivityConstraintGuardTest (9 cases, parses real db/migration/V*.sql plus miniapp source). Two negative-verification rounds proved both guard families actually turn red. Regression: 450 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS (baseline 420). admin-web vue-tsc 0 error, vite build OK.	2026-09-17 14:02:00 +08:00
WorkBuddy	7a2693b239	fix(counseling): close Phase 13A KEEP-VERIFY/EXTEND — 9 real defects + 4 test-infra defects ... Phase 13A（婚恋咨询与婚前辅导）复验关闭。历史 ✅ 不可信：counseling 模块存在双实现， 线上权威 CounselingService（167 行）零测试，唯一被测的 CounselingServiceApp（280 行） 是孤儿类（无注入点、无 HTTP 端点可达，生产永不执行）→ 已合并并删除。 生产缺陷（D1~D9）： - D1 Critical 生产故障 · INV-013 泄露：咨询正文 userRequestSummary 原文被写入 WARN 日志 （同 Phase 10 D2 一族）→ 改为只记 serviceId + riskLevel，绝不记正文。 - D2 High 越权：申请 userId 取自请求体而非认证主体 → Controller 强制 principal.id()。 - D3 High 并发：分配用「先读后写」→ 两管理员并发分配静默覆盖； 改 assignIfPending 条件更新（WHERE status='pending' AND assigned_operator_id IS NULL）， affectedRows=0 明确报错。 - D4 High 越权读：counseling_manager 经 getDetail 可读 followups 正文 → INV-013 绕过通道； manager 只加回 userRequestSummary，不装配 followups。 - D5 Medium：无状态机 → 「已完成」可被再取消；新增 ALLOWED_TRANSITIONS + assertTransition。 - D6 Medium 生产故障：GET /counseling/services/intro 后端不存在（且被 /services/{id} 吞掉） → 小程序 intro 页 100% 无数据；补端点并声明在变量路径之前。 - D7 Medium 契约：Admin 调用 5 条不存在的 /services/operator/*（404）+ 缺四态 → 后端补 8 个运营端端点（@PreAuthorize），前端整体重写 + 注册 /counseling 路由。 - D8 Medium 契约：小程序字段名错（userRequestSummary/preferredServiceMode）+ 无幂等 + my-counseling 未检查 success（403 静默空列表）+ 跳转不存在的页 + WXML 内调用方法。 - D9 Medium 测试保真度：测试库 counseling 两表零 CHECK 约束， counseling_services 未列入 EntityMigrationParityTest 任何集合（= 零覆盖）。 测试基建缺陷（T1~T4，不修即恒真假绿）： - T1 守卫找不到 DDL：surefire workingDirectory = ${project.basedir}/.. 使 CWD 为仓库根， 且 backend/ 是子目录非祖先 → 改为候选后缀 + 逐级向上定位，失败大声抛异常。 - T2 全限定 @com.baomidou...TableField(exist=false) 漏解析（假漂移警报）→ 正则放宽 + 回归守卫。 - T3 OperatorEndpointPermissionCoverageTest 扫到私有辅助方法（假阳性）→ 只扫描真实端点 + 自检。 - T4 两处测试自身逻辑缺陷：陈旧内存快照比较、Instant 纳秒 vs DB 微秒精度。 迁移：新增 V039（counseling 幂等键 + 三个 CHECK 白名单显式固化），基线 38 → 39。 负向验证两轮（均已还原，grep -c NEG-VAL = 0）： - ① DDL 常量守卫：从 V039 移除 'scheduled' → 常量守卫精准变红 （证明解析的是真实 DDL 而非副本）。 - ② 行为守卫：注入「并发回退先读后写 / manager 读 followups / 状态机守卫失效」 → 三个用例各自精准变红。 测试：新增 CounselingPhase13ATest（25）+ CounselingConstraintGuardTest（5，解析真实 DDL）； 删除孤儿类及其 3 个 DTO、删除测死代码的 CounselingDataScopeTest。 全量回归：Tests run: 420, Failures: 0, Errors: 0, Skipped: 3 / BUILD SUCCESS（4:49）。 基线 391 → 420（净 +29）。admin-web vue-tsc EXIT=0；miniapp tsc EXIT=0。 Tag: phase13a-recovery-2026-09-17 Report: docs/Phase-13A-V11-Recovery-Completion-Report-2026-09-17.md	2026-09-17 01:25:12 +08:00
WorkBuddy	5b3bad326e	fix(matchmaker,referral): close Phase 13 KEEP-VERIFY/EXTEND — 7 real defects ... KEEP-VERIFY/EXTEND 复验（历史 ✅ 不可信；测试覆盖函数 ≠ 覆盖运行时路径）。 逐条核对运行时路径与生产约束后修复 7 处缺陷，其中 3 处「只在真实 PostgreSQL 上炸」。 D1 (Critical, 生产故障) matchmaker_recommendations.status 代码写 liked/passed/confirmed_mutual， 而 V009 chk_rec_status 只允许 pending_view/viewed/responded 且从未扩展 → 真实 PG 上用户接受/跳过推荐必崩。测试库未复刻该 CHECK，故长期静默。 D2 (Critical, 生产故障) 控制器缺省 serviceType="recommendation" 不在 chk_matchmaker_service_type 白名单 → 提交红娘服务必崩。 D1+D2 同修于新增 V038__align_matchmaker_status_constraints.sql （沿用 V018/V020/V025 的 DROP CONSTRAINT IF EXISTS + 重加白名单惯例）。 D3 (High, 越权写) MatchmakerServiceService.recommendPartner 无 assignedOperatorId 归属校验， 且可把用户推荐给自己 → 补校验 + 禁止自我推荐。 D4 (High, 越权读) getServiceDetail 无归属校验且返回完整用户资料（userId/description/ userProfile/followups）→ 签名加 requesterId，按调用者返回完整/脱敏视图。 D5 (High, 越权写) ReferralService 的 userId 取自请求体且零授权校验 → 新增 assertMatchmakerServesUser，在 referToServiceStation/referToActivity 入口 强制校验存在进行中的服务关系。 D6 (High, 生产故障) MatchmakerFollowupMapper.findByServiceId 只有声明无 @Select → Invalid bound statement (not found)，getServiceDetail 必崩。 该缺陷由本轮新增测试首次暴露（历史测试从未调用该路径）→ 补 @Select。 D7 (Medium, 契约缺口) admin-web 5 处 API 缺口（4 条 404 + C 端端点被运营端误用）+ 小程序缺转介服务层 → 后端补 GET /operator/matchmaker/recommendations 与 GET /referrals/operator/history 两个运营端端点；前端改路径、 assign 改 POST + body operatorId；新增 miniapp/services/referralService.js。 测试保真度 - 测试库补 matchmaker_services/recommendations/followups 三表（此前该模块零真实覆盖）， 约束与 V038 对齐；EntityMigrationParityTest 三表移入 REQUIRED_IN_TEST_SCHEMA； MigrationValidationTest LATEST_MIGRATION 37 → 38。 - 新增 MatchmakerReferralPhase13Test（17 用例，@SpringBootTest 走真实方法路径 + 真实落库）。 - 重写 MatchmakerServiceTest（6 用例）：直接解析 db/migration/V*.sql，按文件名顺序应用 DROP CONSTRAINT IF EXISTS + ADD CONSTRAINT 取"最终有效"白名单，并内置解析器自检。 【关键】首版守卫硬编码白名单副本，注入 D1 后仍全绿（对漂移零反应）→ 必须解析真实 DDL。 - 删除 3 处假测试占位（MatchmakerServiceTest.testMatchmakerCannotLike 的 assertTrue(true)； CoreInvariantsTest INV-007 断言的是状态常量、INV-010 亦为 assertTrue(true)）， 已如实改名并注明行为验证位置。 负向验证（两轮） 注入 D1（回退 chk_rec_status 白名单）→ 行为守卫 DataIntegrityViolation + 常量守卫 Multiple Failures (3 failures) → Tests run: 23, Failures: 1, Errors: 2 / BUILD FAILURE，守卫有效性得证。缺陷已还原。 全量回归（离线容器，实测） [WARNING] Tests run: 391, Failures: 0, Errors: 0, Skipped: 3 [INFO] BUILD SUCCESS / Total time: 04:59 min Phase 12 基线 371 → 391（净 +20）。 报告：docs/Phase-13-V11-Recovery-Completion-Report-2026-09-16.md Phase 13A 未自动进入，等待用户确认。	2026-09-17 00:01:53 +08:00
WorkBuddy	c607e87b45	fix(relationship): Phase 12 复验 —— 修复实体↔生产迁移系统性漂移（生产故障族）/ 双路径 episode 与 NPE / 测试库缺表致首页零覆盖 / 计划项 2 未实现 ... KEEP-VERIFY 复验发现并修复 4 处真实缺陷： - D1（Critical，生产故障·同一族系统性缺陷）实体与 db/migration 系统性漂移：23 表 50 列在生产 迁移中不存在，而测试库 schema-h2.sql 手写补齐 → 全量绿=假绿。其中 11 表属"INSERT 必崩"级 （缺 id/created_at/updated_at，被 AutoFillHandler 强制填充），含 matches.episode、user_preferences 权重列、permissions/roles、consent_records、risk_events 等；真实 PG 上 Match 创建、择偶偏好保存、 权限/角色写入、同意记录、风险事件全部失败。修复：新增 V037（幂等 ADD COLUMN IF NOT EXISTS + 存量 episode 回填）。 - D2（High）RelationshipService.createMatch 不写 episode/lastActivityAt，与 MatchService 双路径 填充不一致；且 episode 为 null 时 m.getEpisode()+1 对 Integer 自动拆箱抛 NPE。修复：统一按 AGENTS.md #20 推导 + null 兜底。 - D3（High）测试库缺 user_identities 等 7 表 → GET /api/v1/home 在测试环境 BadSqlGrammar， 首页接口零回归覆盖。修复：schema-h2.sql 补齐 7 表。 - D4（Medium）Phase 12 计划项 2 实际未实现：getting_to_know 分支只产出 counseling。修复： HomeApplicationService 补 premarital 引导（与 counseling 并列）。 测试保真度： - 新增永久守卫 EntityMigrationParityTest（5 用例）：把"实体字段 ⊆ 生产迁移累积列"与"测试库覆盖 关键业务表"固化为自动不变量，区分"必崩级/潜伏级"；经两轮负向验证证明会变红（第一轮分级过窄 已修正：episode 由"潜伏级"纠正为"必崩级"）。 - 新增 RelationshipProgressPhase12Test（14 用例，含 8 线程并发确认）与 HomePremaritalGuidancePhase12Test（5 用例）。 - 删除 2 个假测试类中的 assertTrue(true) 占位（AGENTS.md 明令禁止），改走真实服务方法验证。 Gate：单方确认不改变最终关系 ✅ / 双确认后才 successful ✅ / 历史 Episode 可追踪 ✅ / 新 Episode 不恢复旧聊天权限（conversations.match_id UNIQUE）✅ / 非成员不可代确认 ✅ 全量回归：371 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS（71 类，5m07s）	2026-09-16 23:01:13 +08:00
WorkBuddy	52e11a6c65	fix(notification): Phase 11 复验 —— 修复通知类型违反生产 CHECK 约束（生产故障）/ 幂等无库兜底 / 婚前辅导通知未接线 ... 复验模式：KEEP-VERIFY/EXTEND（不轻信历史 ✅，逐条核对运行时路径与生产约束）。 == D3（Critical · 生产故障）通知 type 全量违反生产 CHECK 约束 == NotificationService 的 10 个业务模板传入复合 type （appointment_submitted / counseling_assigned / le_verified / referral_created 等）， 而生产 V020__extend_notification_types.sql 的 chk_notification_type 白名单只允许 12 个短名。 真实 PostgreSQL 下这些通知全部落库失败；测试库 schema-h2.sql 未复刻该约束，故历史 334 测试全绿 → 假绿。 修复： - type 归一为白名单短名，业务细分交由 businessType/title 承担： appointment_submitted|_confirmed|_changed -> appointment counseling_assigned|_scheduled|_completed -> counseling premarital_scheduled -> premarital le_need_evidence|le_verified|le_rejected -> local_eligibility referral_created -> matchmaker - 重写 buildPrivacySafeCopy：原以复合 type 为 key 的 Map.ofEntries 归一后产生重复 key 会抛 IllegalArgumentException（运行期崩溃），改为按短名 switch。 - schema-h2.sql 补齐生产 CHECK 约束（测试保真度下沉）。 == D1（High）通知幂等仅 SELECT-then-INSERT，无 DB 兜底 == NotificationMapper.findExisting 为查后插，并发下可重复落库。 修复：新增 V036__add_notification_idempotency_index.sql，建 partial unique index uk_notification_business(user_id, type, business_type, business_id, content) WHERE business_id IS NOT NULL（先按 created_at ASC 去重存量数据）。 schema-h2.sql 同步唯一索引（H2 无 partial index，标准 UNIQUE 对 NULL 多行共存语义等价）。 == D2（Medium）婚前辅导通知未接线 == premaritalScheduled 零调用；CounselingServiceApp.scheduleCounseling（P13A-T22 管理端路径）完全不发通知。 修复：CounselingService.schedule 与 CounselingServiceApp.scheduleCounseling 均按 service_type 分流， premarital 走 premaritalScheduled，其余走 counselingScheduled； 管理端路径包 try/catch —— 通知失败不回滚排期事实。 == 测试（基线 334 → 346，+12） == - NotificationPhase11IntegrationTest（5）：回滚不发通知（Gate 前半）、提交后可见、 顺序重试幂等、绕过 findExisting 由唯一索引兜底抛异常且最终仅 1 条、business_id IS NULL 多行共存。 - NotificationPrivacyCopyTest（5）：反射校验 4 类隐私文案，咨询类不含「咨询」且标题为「服务通知」， 不泄露姓名/时间/证件类型；未知 type 安全回退；ALLOWED_TYPES 守卫。 - NotificationTemplateTypeGuardTest（2）：关键 —— 调用模板方法本身（而非直接传字面量 send）， 断言 10 个模板全部以白名单短名落库。 - MigrationValidationTest：LATEST_MIGRATION 35 -> 36，DDL 校验补 CREATE UNIQUE INDEX 识别。 == 负向验证（两轮，含第一轮失效教训） == 第一轮：注入复合 type 后 NotificationPhase11IntegrationTest 仍全绿 —— 因该测试直接 send(..., "appointment", ...) 传字面量，不经过模板方法，属无效守卫。 第二轮：改为 NotificationTemplateTypeGuardTest 调用模板本身，注入后精准抛 DataIntegrityViolation，守卫有效性得证。教训已写入报告：守卫必须经负向验证证明会变红。 == 证据 == 全量回归 346 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS （离线 Docker：danyang-match-backend-test:latest + 卷 danyang-m2-cache） 迁移校验 12/12；定向 19/19。 == Gate 判定 == 回滚事务不发通知 ✅ ｜ 通知失败不回滚核心事实 ✅ ｜ 隐私安全文案 INV-010 ✅ 已提交事务通知失败可重试且不产生重复业务记录 ✅（修复后成立） == 遗留 gap（登记不自动实现） == sendExternal 在事务内同步执行外部副作用，当前为占位实现；接入真实微信推送前必须改为 @TransactionalEventListener(AFTER_COMMIT) / REQUIRES_NEW —— 全仓当前无任何 afterCommit 机制。	2026-09-16 21:50:56 +08:00
WorkBuddy	fd7195ecb0	fix(safety): Phase 10 复验 —— 修复图片上传魔数校验死代码（生产故障）/ 高风险词写入日志 ... 对 Phase 10（Image & Chat Safety）执行 KEEP-VERIFY 复验：不采信历史 ✅，逐条核对 图片私有访问、类型/大小/魔数校验、审核与水印、风险识别/举报/违规处理、日志脱敏。 Gate 判定通过，发现并修复 2 处缺陷，并推翻旧报告 2 项安全声明。 D1（Critical，生产故障）图片上传的类型与魔数校验整条是死代码 - PhotoService.uploadAndSave 用 `header = new byte[Math.min(12, stream.available())]` 仅分配零值缓冲，从不调用 stream.read(...) → validateMagicNumber 对任何文件都收到 12 个 0x00 → 恒返回 false → 恒抛"无效的图片文件头"。 - 影响链（已确认线上触发）：小程序 local-eligibility-supplement.ts 以 photoType='local_eligibility' 调 POST /photos/upload → 本地资格佐证上传 100% 失败。 - 次生问题：isAllowedMimeType（image-only 白名单）在 local_eligibility 分支之后 无条件执行，即使魔数修好，application/pdf 仍被挡，而 FeatureFlagConfig 的 localEvidenceAllowedTypes 明确允许 pdf；另有未 mark 的 stream.reset() 无效调用。 - 测试为何没发现：PhotoServiceTest 只对 validateMagicNumber 传手写字节做单测， 从不经过 uploadAndSave，该路径缺陷完全无覆盖。 - 修复：改用 try(InputStream){ header = s.readNBytes(12); } 真正读取； MIME 校验按 photoType 分流（local_eligibility 走自己的白名单含 pdf）； 魔数校验仅对图片执行、PDF 跳过；移除死 reset()；上传用全新流与校验流隔离； generateFileKey 重载按 Content-Type 推断扩展名，PDF 不再拿到误导性 .jpg key。 D2（Low）高风险词写入普通日志 - ChatSafetyService.scanContent 把命中的高风险词原样写入 log.warn， 与同文件 CONTACT 分支"只记 pattern 不记内容"矛盾，且违反本阶段 Gate。 - 修复：改为 log.warn("Chat content matched HIGH_RISK keyword (blocked)")。 推翻的旧声明（docs/Phase-10-Completion-Report.md） - 「伪装恶意图片被拒（Magic Number校验）」不成立：该校验运行时恒失败， 连合法图片也一律被拒（fail-closed 到不可用），安全属性并非由它提供。 - 「EXIF清理预留（PhotoService.stripExif占位）」不存在：全仓库无该符号。 且 getUploadToken 客户端直传路径服务端无法介入清理 EXIF。 - 已在旧报告顶部加状态注记，指向本次复验报告。 测试 - 新增 PhotoUploadValidationTest（6 用例），用 MockMultipartFile 真正走一遍 uploadAndSave：合法 JPEG/PNG 通过且确实调用 putObject、伪造 Content-Type 被魔数挡、 PDF 佐证不被 image-only 挡且 key 以 .pdf 结尾、非法 MIME 被拒、超大被拒。 - 负向验证：临时把魔数守卫改为 if(false && ...) → 恰好 spoofedContentTypeRejectedByMagic 一个用例变红，其余 5 个仍绿；随后还原并 grep 确认无 NEGATIVE-CHECK-TEMP 残留。 - 全量回归（离线容器 danyang-match-backend-test，mvn -o test）： 334 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS（基线 328，+6）。 登记 gap（不自动实现，待产品确认） - 图片水印：全仓库无实现；主计划未列硬需求，仅"开发执行计划修订版"提"高级动态水印"。 - EXIF 清理：旧声明不存在；客户端直传路径服务端无法介入，需改为接收侧重编码。 - 直传凭证路径（getUploadToken）无服务端内容校验且不落 DB 记录 → 后续 getSignedUrl 归属校验会查不到 UserPhoto 行，属契约层缺口，超出本阶段安全 Gate 范围。 - 违规自动升级：ChatSafetyService 注释明确属 Phase 17 范围，当前 high 仅拦截不落库。 文档：新增 Phase-10-V11-Recovery-Completion-Report-2026-09-16.md； 旧报告加状态注记；主计划 Phase 10 复选框置 ✅；STATUS / JIRA_BACKLOG 同步（334 tests）。 Phase 11 未启动，按计划每阶段出报告后停止等待确认。	2026-09-16 21:00:52 +08:00
WorkBuddy	03a03c7c11	fix(chat): Phase 09 复验 —— 修复 WebSocket 下行死链路 / Unmatch 后可发消息 / Block 未落库 / 聊天 IDOR ... 对 Phase 09（Text Chat）执行 KEEP-VERIFY/EXTEND 复验：不采信历史 ✅，逐条核对 REST 发送 + WebSocket 接收、幂等、重连、未读计数、非 active Match 禁聊、Unmatch/ Block 即时禁聊、活动双确认会话复用。共发现并修复 4 处真实缺陷 + 1 处规范不符。 D1（Critical）WebSocket 下行整条链路是死代码 - 无 HandshakeInterceptor，无任一环节把 userId 写入 session attributes， extractUserId 恒返回 null；sendToUser/sendToConversation 全仓库零调用点。 - 新增 ChatHandshakeInterceptor：从 ?token= 或 Authorization: Bearer 解析 JWT， 校验通过后写 session attr userId；失败 fail-closed 拒绝握手；仅接受 type=access。 - 重写 ChatWebSocketHandler：按规范 {event,data} 信封推送；未认证连接直接 close(NOT_ACCEPTABLE)；同账号重连由新连接接管、旧连接 close(NORMAL)； 上行仅支持 ping->pong，禁止客户端自订阅。 - ChatService.sendText 落库+递增未读后推送 message.new；RiskNotice 同推。 - 移除 WebSocketConfig 的 .withSockJS()（SockJS 改写端点致原生 WS 无法直连）。 D2（Critical）Unmatch 后仍可发消息 - unmatch 只改 Match，不联动会话；sendText 仅校验 conv.status==active。 - 新增 ChatService.assertMatchAlive(conv)：按 matchId 查 Match，状态非 {active,getting_to_know} 抛 "匹配已解除，无法发送消息"。sendText 在 conv.status 校验之后调用。 - MatchController.unmatch 落库后调 chatService.syncFromMatch 推 conversation.closed。 - syncFromMatch 重写：alive 恢复 active；非 alive 只推 conversation.closed， 不改 status（会话仍以灰显态留在列表，属未授权产品决策，登记待决）。 D3（Critical）RelationService.block 调静态 MatchService.unmatch 只改内存态不落库 - 结果：Block 后 matches.status 仍为 active。 - 补 matchMapper.updateById(m) 持久化 + chatService.closeConversationForMatch( CONVERSATION_STATUS_BLOCKED) 通知对端。RelationshipService.block 同步补会话关闭通知。 D4（Critical 安全）聊天 4 个接口无成员校验 -> IDOR 越权读私聊 - MessageController.load/markRead、ConversationController.detail/unread 补 chatService.isMember(conversationId, userId) 校验；非成员返回 ApiResponse.notFound()（body 级 success=false code=NOT_FOUND，HTTP 200， 与 MatchController.authorizedMatch 同约定），不区分"不存在"与"无权"以防探测。 D5（Medium）上行订阅/信封不符规范 - REST API 接口详细设计规范.md 第124-126章要求禁止客户端自订阅，事件名 message.new/message.read/conversation.closed，信封 {event,data}。已对齐。 测试保真度 + 测试补齐 - schema-h2.sql 新增 uk_message_client_id(sender_id, client_message_id)， 对齐生产 V004:71；H2 不支持过滤索引故省略 WHERE（NULL 语义等价）。 否则 service 的 SELECT-then-INSERT 竞态在测试中无 DB 兜底，形成测试盲区。 - 新增 ChatPhase09IntegrationTest（13 用例）：幂等重试不重复投递、推送信封字段、 未读增减清零、Match unmatched 拒发、Unmatch/Block 端点即时禁聊+收 closed 事件、 活动双确认复用同一消息体系、未形成 Match 无法建会话、非成员读消息/详情/未读 被拒且不泄露正文、DB 唯一索引兜底重复 clientMessageId、无幂等键系统消息可共存。 - 新增 ChatWebSocketHandlerTest（7 用例）：userId 路由、信封格式、未认证关连、 断开不推、重连替换旧连接、上行仅 ping。 验证证据 - 全量回归（离线容器 danyang-match-backend-test，mvn -o test）： 328 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS（基线 308，+20）。 - 负向验证：临时注释 assertMatchAlive + 两处 isMember，恰好 3 个用例变红， 证明守卫有效；随后还原并 grep 确认无残留。 文档 - 新增 Phase-09-V11-Recovery-Completion-Report-2026-09-16.md（完整报告）。 - Phase-09-V11-Completion-Report.md 顶部加状态注记，推翻其 4 条 WebSocket 结论。 - 计划/STATUS/JIRA_BACKLOG 同步 Phase 09 完成态与测试总数（328）。 Phase 10 未启动，按计划每阶段出报告后停止等待确认。	2026-09-16 16:42:48 +08:00
WorkBuddy	4e478ce6ba	fix(invariants): Phase 08 复验 —— 修复 INV-004 搜索/详情绕过 Block + matches.source 取值越界 ... 复验（KEEP-VERIFY）在既有 Phase 08 实现中发现 3 处真实缺陷并修复： D1（严重）DiscoverService.searchUsers 不含查看者身份，查询条件既无排除自己也无任何 Block 条件，被拉黑者仍可被搜到并点开 —— INV-004「搜索不可见」整体失效。改为接收 viewerUserId，排除自己，并用新增的 UserRelationMapper.findBlockedUserIdsBothWays（UNION 双向）一次取回后 notIn 批量排除，避免 N+1。 D2 详情路径（DiscoverService / UserProfileService）均无 Block 判断，知道 userId 即可读到被拉黑者资料。两条路径统一加双向判断并返回 null，由 Controller 转 404（不用「已隐藏」以免被用来探测存在）；UserProfileService 中该判断排在隐私设置之前，拉黑不能被对方「允许搜索可见」覆盖。 D3（潜伏，仅 PostgreSQL 暴露）RelationshipService.like() 把关系类型值 "liked" 当 match source 写入 matches.source，违反 V003:91 的 chk_match_source。测试库 schema-h2.sql 该列是裸 VARCHAR(32)、无约束，故长期静默通过。改传 MATCH_SOURCE_USER_LIKE。canonical 路径 RelationService.like 传值本就正确，线上未触发。 测试保真度对齐：schema-h2.sql 补 chk_match_source（与 V003 逐字对齐）与 user_profiles 表（此前测试库无此表，资料查询无法端到端测试）。 新增 DiscoverBlockInvisibilityIntegrationTest（9 用例，@SpringBootTest 真实 H2 + 真实 SQL），覆盖正向/反向拉黑、对称性、排除自己、详情 404 与查自己不受限。P0FixVerificationTest 补 source 回归守卫。DiscoverServiceTest 同步构造签名。 负向验证：临时还原 D3 修复后，4 个用例因 CHK_MATCH_SOURCE 约束违反报错，证明守卫有效。 证据：后端全量 308 tests / 0 failures / 0 errors / 3 skipped（基线 299）；UI 契约 13/13 GREEN。报告 docs/Phase-08-V11-Recovery-Completion-Report-2026-09-16.md。 同步 STATUS.md / JIRA_BACKLOG.md（EPIC-P08-V11 置 ✅）/ 客户需求基线计划 Phase 08 复选框；首轮报告加状态注记（其「Known Issues 无」已被推翻）。.gitignore 忽略 .workbuddy/。	2026-09-16 15:11:38 +08:00