admin/danyang-match
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
164 Commits 2 Branches 8 Tags
45e84722e1677574668b2960c58526966ff4400b
Commit Graph
164 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
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