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