2026-09-21 当前有效结论：V1.1 RECOVERY PHASE 01~22 CLOSED / PHASE 23 CLOSEOUT FULLY DONE (BATCH 1-3 CLEARED, DATA RETENTION FLOW LANDED) / HORIZONTAL HARDENING DONE / UI REDESIGN ACCEPTED BY USER / REMAINING: CI GREEN RUN (needs GitHub Actions) + BATCH 4 (USER) / PHASE 24 (UAT) AWAITING USER GO。 V1.0.1 配置与规则纠偏已完成（照片上限配置化 + 服务器端强校验 / 活体开关闭环 / 推荐阈值纠偏 + 规则版本化快照 / governance 五表 + 漂移审计）：canonical key 字面化（V051 收敛 identity.liveness.enabled 为 feature_flag_overrides 唯一正式键 + KEY_ALIASES 读兼容遗留键）、PHOTO-004 真实并发突破实测（H2 MVCC 快照漏读缺陷被新测试咬住 → 并发控制改为「锁用户行 + 锁后计数」，3 线程并发冲顶恰 1 成功不突破上限）、AGENTS.md 规则 27（配置治理纪律）+ docs/governance/known-risks.md（7 项已知风险含本机 WSL/Docker 故障）。全量回归 741 / 0 / 0 / 3（基线 717 + 25 新增 − 1 删死测试），UI 契约门禁 18/18。

阶段 0（在途收口）、阶段 1（小程序 C 组 + discover 筛选重设计）、阶段 2（管理端 Vue 新框架适配）、阶段 3（CapabilityService 独立化）、阶段 4（双端总验收）全部完成。三端构建通过、13/13 契约全绿（阶段 4 验收时点值；当前 UI 契约门禁为 18/18）、核心 11 页面全部 TS-only（11/11）。UI 重设计首批 11 页已于 2026-09-16 通过用户验收（结论：基本达标）；/me/* 前后端契约同轮收敛，17 个 404 调用已恢复。Phase 08（Like / Match / Block）、Phase 09（Text Chat）、Phase 10（Image & Chat Safety）、Phase 11（Notification）、Phase 12（Relationship Progress）、Phase 13（公益红娘转介）、Phase 13A（婚恋咨询与婚前辅导）、Phase 14（多类型公益活动）、Phase 15（活动报名、审核与签到）、Phase 16（活动互选与双方开启沟通确认）、Phase 17（举报与风控）、Phase 18（申诉）、Phase 19（统一运营后台 + 用户端公益服务页面）、Phase 20（Analytics 数据统计与管理驾驶舱）复验已关闭，十四轮共修复 130+ 处真实缺陷（含 3 处隐藏编译缺陷），并各自补齐测试保真度与守卫。Phase 21、22 复验已关闭（2026-09-18）；Phase 23 为「部分关闭」（2026-09-18） —— 已清除 44 个 pass 空壳与 14 个只断言常量的假不变量测试，新增 4 个经负向注入验证的真实行为守卫与空壳阻断闸门，后端回归 655 全绿；但 E2E 进入 CI 因需「活栈供给方式」基础设施决策而列为遗留，故不宣布「失败为零可进入 UAT」。Phase 23B（E2E 测试基建重建，33→49 passed）、HTTP 语义检修（失败响应携带真实状态码）、幂等键检修（Idempotency-Key 30 端点落地，V045/V046）均已于 2026-09-18 完成，后端全量回归 669 / 0 failures / 0 errors / 3 skipped。管理端入口已收敛到 /admin/ 子路径（vite base + router base + 三处 nginx 接线），staging 端口 13521；UI 契约门禁 18/18 全绿（第 15~18 项为 2026-09-19 新增）。Phase 24（UAT）启动需用户确认。 2026-09-19 收尾推进（批 2/3，已全部完成）：Phase 23 Task 2.1（互选 8 + 预约 8 场景真实实现，本机 E2E 65 passed，负向注入 2 轮精准变红）与 Task 2.2（INV-011 显式行为守卫 9 用例）完成；批 3 处置 Phase 21/22 遗留——隐私设置接真实落库（V047 补列 + upsert 修复，守卫 8 用例含解析小程序源码的契约守卫）、5 个死开关 + 2 个私有桶死配置移除（产品裁定）、PUT /feature-flags 真持久化（V048，守卫 11 用例）、补 5 个「只有声明无 SQL」的 Mapper 方法并新增绑定守卫；Task 3.3 四项 + 红娘服务拦截接线完成（P16-T13 expires_at 写入接线、P13A-T31 随访审计、P13A-T33 随访正文风险检测、P04-T10 确认 Onboarding 本地资格早已实现、checkCanWithdraw 红娘 blocker 首次生效 + 注销竞态兜底），各项均带真实落库守卫并经负向注入验证。全量回归 712 / 0 failures / 0 errors / 3 skipped（BUILD SUCCESS，2026-09-19 实测）→ 717（2026-09-20 实测，数据保留流程 +5）；UI 契约门禁 18/18；E2E 本机模拟 CI 序列实测 65/65 全绿（2026-09-20，宿主机 Python 3.11 + 活栈，GitHub Actions 流水线实测仍待一次推送）。批 3 仅余：E2E 入 CI 的 GitHub Actions 实测绿（数据保留流程已于 2026-09-19/20 落地，见 V049 行）。

最后更新: 2026-09-21 — 分支 main（V1.0.1 配置与规则纠偏全项落地：V050 阈值快照 / V051 活体键归一 / 并发强校验改锁用户行 / AGENTS 规则 27 / governance 六表；回归 741；feat-ui-v11 保留为冗余锚点）

当前唯一有效状态

当前有效项	状态	证据
Phase 01~06 Recovery	已完成	各 Phase Completion Report；38+9+3+4+21 后端专项通过
Phase 07 V1.1 首页业务与找对象	业务+UI 已通过用户验收（2026-09-16）	HomeApplicationService 真实聚合；CapabilityService 独立化；discover 筛选完整重设计（5 chip + 4 section + 底部抽屉 + 滚动定位高亮）；UI 按 2026-09-13 规格重新实现，11 页经用户验收通过
Phase 08 V1.1 Like / Match / Block	已完成（2026-09-16）	KEEP-VERIFY 复验。修复 3 处真实缺陷：① `DiscoverService.searchUsers` 无查看者身份 → INV-004「搜索不可见」整体失效；② 详情路径无 Block 判断；③ `RelationshipService.like()` 把 `"liked"` 当 match source 写库 → 违反 `V003 chk_match_source`（H2 测试库无该约束故长期静默）。新增 `DiscoverBlockInvisibilityIntegrationTest`（9 用例，含反向拉黑）；`schema-h2.sql` 补齐生产约束与 `user_profiles`；负向验证确认守卫会红。报告：`docs/Phase-08-V11-Recovery-Completion-Report-2026-09-16.md`
Phase 09 V1.1 Text Chat	已完成（2026-09-16）	KEEP-VERIFY 复验。修复 4 处真实缺陷：① WebSocket 下行整条链路是死代码（无握手鉴权/无 userId 写入/`sendToUser` 零调用点）→ 新增 `ChatHandshakeInterceptor` + 落库后推 `message.new`；② Unmatch 不联动会话 + 发消息只校验会话状态 → 解除后仍可发消息 → 新增 `assertMatchAlive` + `MatchController.unmatch` 联动；③ `RelationService.block` 调静态 `MatchService.unmatch`（只改内存态）→ Block 后 Match 未落库；④ 聊天四个接口无成员校验 → IDOR。新增 `ChatPhase09IntegrationTest`（11 用例）+ `ChatWebSocketHandlerTest`（7 用例）；负向验证 3 处守卫精准变红。报告：`docs/Phase-09-V11-Recovery-Completion-Report-2026-09-16.md`
Phase 10 V1.1 Image & Chat Safety	已完成（2026-09-16）	KEEP-VERIFY 复验。Gate 通过。修复 2 处缺陷：① D1（Critical，生产故障） `PhotoService.uploadAndSave` 魔数校验因 `new byte[n]` 从不读取流而恒失败 → 本地资格佐证上传 100% 失败；且 image-only MIME 在 local_eligibility 后无条件执行致 PDF 被挡 → 改为 `readNBytes` 真读取 + MIME 按 photoType 分流 + PDF 跳过图片魔数；② D2（Low） `ChatSafetyService` 把命中的高风险词写入 warn 日志 → 改为不记具体词汇。推翻旧报告「伪装恶意图片被拒（Magic Number校验）」与「EXIF清理预留（stripExif占位，符号不存在）」两声明。新增 `PhotoUploadValidationTest`（6 用例，`MockMultipartFile` 真走校验链路）+ 负向验证精准变红。报告：`docs/Phase-10-V11-Recovery-Completion-Report-2026-09-16.md`
Phase 11 V1.1 Notification	已完成（2026-09-16）	KEEP-VERIFY 复验。Gate 部分通过。修复 3 处缺陷：① D3（Critical，生产故障） `NotificationService` 全部 10 种通知传入复合 type（`appointment_submitted`/`counseling_assigned`/`le_verified` 等），违反生产 `chk_notification_type`（仅允许短名）→ 真实 PG 上全部落库失败，Phase 11 核心交付不可用；测试库未复刻该约束故长期静默 → type 归一为白名单短名 + 测试库补约束；② D1（High）幂等仅靠 SELECT-then-INSERT 无 DB 兜底 → 新增 `V036__add_notification_idempotency_index.sql`（partial unique index）；③ D2（Medium）婚前辅导排期通知零调用 + 管理端排期路径完全不发通知 → 接线并按 service_type 分流。新增测试 12 用例（含真实调用模板方法的 type 守卫）。报告：`docs/Phase-11-V11-Recovery-Completion-Report-2026-09-16.md`
阶段 0 在途收口	已完成	56 个改动分类提交为 7 个 commit；Git 清零；Flyway 实际 V036 已登记
阶段 1 小程序 C 组 + discover	已完成	C 组 content/anti-fraud/service-station 迁 TS 唯一源；discover 筛选从参数到 UI 完整重写
阶段 2 管理端 Vue 适配	已完成	18 modules + 22 routes + vue-tsc 全绿 + vite build 11.68s
阶段 3 CapabilityService 独立化	已完成	New `capability` 模块：CapabilityService（getCapabilities + 公共判断方法）+ CapabilityController（GET /api/v1/capabilities）；HomeApplicationService 完全委托
阶段 4 双端总验收	已完成（2026-09-14）	三端构建全绿 + 13/13 契约全绿 + 源码健康检查通过；验收报告见 docs/superpowers/plans/2026-09-14-phase4-acceptance-report.md
Flyway 迁移	V001~V049	V028~V049 已纳入 STATUS；V037 为 Phase 12 新增（实体列与生产迁移对齐，23 表 50 列）；V038 为 Phase 13 新增（`matchmaker_recommendations.status` + `matchmaker_services.service_type` 的 CHECK 白名单扩展）；V039 为 Phase 13A 新增（counseling 幂等键 + 三个 CHECK 白名单显式固化）；V042 为 Phase 19 新增（`service_location_announcements` 服务站临时公告表）；V043 为 Phase 20 新增（授予 `data_viewer` / `platform_admin` 的 `analytics.view`）；V045 为幂等键检修新增（`idempotency_records` 通用幂等表 + 唯一索引 `uk_idempotency_scope`）；V046 修正其 `actor_id` 列类型（VARCHAR → uuid）；V047 隐私设置补列；V048 Flag 持久化（`feature_flag_overrides`）；V049 数据保留（`users.closed_at` + `account.retention.purge` 权限，产品 2026-09-19 确认保留期下限 36 个月）
Backend 全量回归	已清偿（最新实测：2026-09-20 717 / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS；基线 712 → 数据保留流程 +5：`DataRetentionGuardTest`（下限不可提前 ×2、到期处置 PII 断开 + 审计 + 幂等 ×3））	离线容器（`danyang-match-backend-test`）`mvn -o test` 实测（必须挂仓库根——守卫测试按根相对路径读文件，只挂 backend/ 会集体 NoSuchFile，B-9 已记教训）；2026-09-18 幂等键检修订正后为 669（HTTP 语义检修 664 → 幂等检修 +5：`GlobalExceptionHandlerTest` 3→6、新增 `IdempotencyDeclarationGuardTest` 2）。历史：2026-09-17 Phase 20 为 648；含 `CanonicalRouteContractTest`、`ChatContractJsonTest`、`MeRouteContractTest`、`DiscoverBlockInvisibilityIntegrationTest`、`ChatPhase09IntegrationTest`、`ChatWebSocketHandlerTest`、`PhotoUploadValidationTest`、`NotificationPhase11IntegrationTest`、`NotificationTemplateTypeGuardTest`、`NotificationPrivacyCopyTest`、`EntityMigrationParityTest`、`RelationshipProgressPhase12Test`、`HomePremaritalGuidancePhase12Test`、`MatchmakerReferralPhase13Test`、`MatchmakerServiceTest`、`ReportAndRiskPhase17IntegrationTest`、`AppealPhase18IntegrationTest`（Phase 18 新增 15 例：申诉真实落库+审计、仅 ban/suspend 可申诉、幂等、Gate A 通过只解除目标处置、Gate B 拒绝维持原处置、原子认领唯一赢家、二次处理被拒、escalate 后可再决策、appealType 白名单/一致性/缺省推导、证据字段映射、软删过滤、Feature Flag 关闭拦截）、`MetricCatalogGuardTest`(11)、`AnalyticsMetricsPhase20IntegrationTest`(21)、`AnalyticsSoftDeleteGuardTest`(4)、`AnalyticsPermissionGrantTest`(6)、`LocalEligibilityStatusVocabularyGuardTest`(9)、`ApiResponseCodeHttpStatusTest`(6)、`SecurityPathCoverageTest`(2)、`IdempotencyDeclarationGuardTest`(2)
路由/字段契约收敛	已完成（2026-09-15）	字段：会话 `target` + `sentAt` + `relationStatus`（commit `687a156`）；路径：采用 2026-09-14 canonical（`/likes` `/passes` `/blocks` `/matches`，缘分保留 `/relations/fate/`），旧路径与 `success` 桩实现已移除；裁决由 `CanonicalRouteContractTest` 锁定
`/me/*` 路径族	已完成（2026-09-16）	小程序按 REST 规范（§16 / §22-§40 / §80 / §83-§84）调用 `/me/`，后端此前无 `/me` 基路径*致 17 个调用 404。新增 `MeController` 委托既有 service 暴露规范路径，旧路径全部保留，小程序三条历史写法（`/me/privacy-settings`、`/me/photos/{id}/main`、`/me/appeals`）一并兼容；由 `MeRouteContractTest` 锁定
Admin Web	验证通过	2026-09-14 阶段 4：vue-tsc ✅、vite build ✅ 11.68s；18 modules 齐全；壳层+工作台通过参考图 QA
Miniapp	验证通过	2026-09-16：tsc ✅；11 核心页全部 TS-only（11/11）；首批 11 页于 2026-09-16 通过用户验收；discover 筛选重设计已通过 DevTools 验证
UI 契约测试	18/18 通过（2026-09-19）	统一执行器 `scripts/run-ui-contracts.mjs`，已接入 CI（job `ui-contracts`）；历史：2026-09-16 为 13 项，此后新增端口一致性与 `/admin/` 子路径守卫（14 项）；2026-09-19 连补 4 项（15~18）—— WXML 结构（两页多 `</view>` 实际编译失败）、私有方法调用（`this._x()` 无定义致所有请求 Promise 永不 settle）、组件 WXSS 违规选择器、api.js 请求层行为契约
Git 工作区	已清零	阶段 0~4 共 24+ commit 可追溯；`git status --porcelain` 0 行
核心待清债务	0 项	已全部清偿：3 页 JS→TS 迁移、backend 全量回归（420 tests）、DevTools 真机截图留档（2026-09-14）、`/me/*` 路径族收敛（2026-09-16）、实体↔生产迁移漂移修复（V037/V038/V039，2026-09-16/17）
UAT / RC / Production	Phase 01~~22 复验关闭；Phase 23 收尾批 1~~3 完成（含数据保留流程 V049）；停在 Phase 24（UAT）门前	后端 717 / 0 failures / 0 errors / 3 skipped；E2E 本机活栈 65 passed（2026-09-20 模拟 CI 序列实测）；UI 契约门禁 18/18；管理端入口收敛至 `/admin/` 子路径（staging 13521）。Phase 24 启动需用户确认

下一阶段计划（唯一）：docs/superpowers/plans/2026-09-18-phase23-closeout-and-uat-readiness.md —— 批 1 快速收尾（ui-tests 接入 CI）/ 批 2 Phase 23 剩余（E2E 实现 + CI 串联，需基础设施决策）/ 批 3 代码级遗留清偿 / 批 4 UAT 就绪（需用户协作）/ 批 5 Phase 25-26 前置登记。

版本演进

版本	日期	说明
1.0.0-RC.2	2026-09-01	V1.0 核心功能冻结
1.1.0-dev	2026-09-08	V1.1 基线搭建启动（Phase 01 进行中）
1.1.0-rc.3	2026-09-16	Phase 08~12 复验关闭；新增 V037 对齐实体↔生产迁移；全量回归 371 tests 全绿
1.1.0-rc.4	2026-09-16	Phase 13 复验关闭（公益红娘转介，修复 7 处缺陷）；新增 V038 扩展 matchmaker CHECK 白名单；全量回归 391 tests 全绿
1.1.0-rc.5	2026-09-17	Phase 13A 复验关闭（婚恋咨询与婚前辅导，9 处缺陷 + 4 处测试基建缺陷）；新增 V039；全量回归 420 tests 全绿
1.1.0-rc.6	2026-09-17	Phase 14 复验关闭（多类型公益活动，11 处后端缺陷 + 3 处前端契约缺陷 + 2 处测试保真度缺陷）；新增 `ActivityManagementView` 动态表单；全量回归 450 tests 全绿
1.1.0-rc.7	2026-09-17	Phase 15 复验关闭（活动报名/审核/签到，16 处缺陷：含签到码一生成即作废、取消后永远无法再报名两处必崩；3 处测试保真度）；新增 V040 `activity_staff_assignments` 与 `ActivityCheckinView` 签到工作台；全量回归 474 tests 全绿
1.1.0-rc.8	2026-09-17	Phase 16 复验关闭（活动互选与双方开启沟通确认，7 处缺陷 + 1 处隐藏编译缺陷 + 1 处测试保真度：含双确认后根本不建 Match/会话（Gate 缺陷）、Phase 15 提交态引用未定义 `reopenEpisode` 致模块不编译（"474 绿"为假象）、INV-006 单向意向泄露、复用/新建 Match 后缺会话；统一双实现到 `RelationshipService.confirmActivityInterest`；新增 V041 `expires_at`+`match_id`；新建 `ActivityMutualConsentServiceTest`（7 用例）；全量回归 481 tests 全绿
1.1.0-rc.9	2026-09-17	Phase 17 复验关闭（举报与风控，6 处真实缺陷：含D1 测试库缺 reports/risk_events/risk_actions 三表致风控/举报真实 DB 路径零覆盖（必崩级盲区）+ ReportServiceTest 假绿、D3 敏感访问（查看他人风险画像/举报）无审计（AGENTS.md #8）、D4 审计缺 ip/userAgent、D5 findByUserId 未过滤软删、D2 人工标记无审计、D6 javax→jakarta 隐藏编译缺陷 + risk_events 漏 updated_at）；补齐三表并移出白名单入 REQUIRED_IN_TEST_SCHEMA；新增 `AuditLogService.recordSensitiveAccess` 并接线三端点；新增 `ReportAndRiskPhase17IntegrationTest`（7 用例）；全量回归 488 tests 全绿
1.1.0-rc.10	2026-09-17	Phase 18 复验关闭（申诉，8 处真实缺陷：含D1 测试库缺 appeals 表 + AppealServiceTest 6 处 assertTrue(true) 假绿 → 申诉真实 DB 路径零覆盖、D2 escalate 向 operator 发用户通知撞 notifications.user_id→users(id) FK → PG 上升级 100% 失败、D3 appealType 未校验生产 chk_appeal_type、D4 escalated 死胡同、D5 processAppeal 先读后写并发竞态、D6 三处查询漏软删过滤、D7 硬编码 resolved、D8 证据字段契约 evidenceFileIds）；补 appeals 表并移出白名单入 REQUIRED_IN_TEST_SCHEMA；新增原子认领 `markReviewingIfProcessable`；新增 `AppealPhase18IntegrationTest`（15 用例），删除假绿 `AppealServiceTest`（9 用例）；全量回归 494 tests 全绿；admin-web `vue-tsc` EXITCODE=0
1.1.0-rc.11	2026-09-17	Phase 19 复验关闭（统一运营后台 + 用户端公益服务页面，修复 25 处真实缺陷：服务站公告整条不可达、服务站越权写、Banner 500、Content 发布死路、ServiceProgram 审批死路等）；新增 V042 `service_location_announcements`；全量回归 602 tests 全绿
1.1.0-rc.12	2026-09-17	Phase 20 复验关闭（Analytics，口径造假 / 死代码 / 系统性软删缺陷 D12 修复 45 处 / 权限授予脱节）；新增 V043 `analytics.view` 授权；指标字典 `docs/ANALYTICS_METRICS.md` + `MetricCatalogGuardTest`；全量回归 648 tests 全绿
1.1.0-rc.13	2026-09-18	Phase 21 复验关闭（账户生命周期，6 处缺陷：CLOSED 可登录、注销 TODO 桩 ×2、匿名化死代码等）+ Phase 22 复验关闭（Feature Flag，D-22-A/B 修复；T01~T05 死配置如实登记）；全量回归 657 tests 全绿
1.1.0-rc.14	2026-09-18	Phase 23 部分关闭（44 个 `pass` 空壳清除、4 个真实 INV 行为守卫、空壳阻断闸门）；Phase 23B E2E 基建重建（conftest + seed + CI e2e job，本机活栈 33 passed）；全量回归 655 tests 全绿
1.1.0-rc.15	2026-09-18	HTTP 语义检修（105 处错误响应携带真实状态码，回归 664）→ 身份收敛（运营身份禁入用户端 + PathPattern 守卫）→ 幂等键检修（`Idempotency-Key` 30 端点落地，V045/V046，前端 25 处调用点修正，E2E 49 passed）；admin 端口收敛 13520（vite / 文档 / 生产 compose 三处一致）；全量回归 669 / 0 / 0 / 3 全绿
1.1.0-rc.16	2026-09-18	管理端入口收敛（承接 rc.15 的端口收敛）：staging admin 端口 3001 → 13521（保持「生产 + 1」，同步 `run-uat.sh` 默认入口）；管理端产物改为 `/admin/` 子路径部署（vite 构建 base + router history base + 三处 nginx 接线统一为「不剥离前缀」转发）；修复生产 nginx `/admin/` 的假成功——原 `alias` 指向 `nginx:alpine` 自带默认页目录，访问返回 200 + nginx 欢迎页（比 404 更难发现），已改为 `upstream admin_web` + `proxy_pass` 并以真实两跳容器实测；补修 `run-uat.sh` 被截断的尾部（原文件语法不完整、无法运行）并把 `ADMIN_URL` 接到管理端可达性实测；品牌资源引用统一走 `src/brand.ts` 的 `BASE_URL` 拼接（原 5 处写死根路径，子路径下会裂图），favicon 由不存在的 `/favicon.svg` 改为存在的品牌标；UI 门控 14/14 绿，新增端口/入口断言 6 条（全部经负向注入验证）
1.1.0-rc.17	2026-09-19	小程序 WXML 结构缺陷修复 + 补第 15 项门禁：微信开发者工具报 `service-history.wxml` `get tag end without start`，实测 2 个页面各多一个 `</view>`（`service-history` / `service-program`，单行压缩写法，已随更早提交入库）→ 修复后 86 个 WXML 结构全部自洽。根因是门禁覆盖盲区：既有 14 项全是「源码内容/清单断言」，没有一条会解析 WXML，故 14 绿与「小程序能不能编译」无关。新增 `scripts/lib/wxml-structure.mjs`（引号状态机扫描器）+ `scripts/check-wxml-structure.mjs`（CLI）+ `ui-tests/wxml-structure-contracts.mjs`（守卫，含 3 组内置自检样例，其中正向样例故意在属性值内放 `>` —— 早期用懒惰正则实现时此处是假阳性来源）。`MIN_GUARDS` 14 → 15。负向验证三项：注入「多余闭合 / 未闭合」→ 退出 1 且只报坏文件；`UI_GUARDS_MIN=99` → 正确拒绝报绿；CLI 直扫坏目录 → 退出 1。基线 PASS 15/15。未跑：微信开发者工具真实编译（本机无该环境），仅以结构判据断言
1.1.0-rc.18	2026-09-19	小程序两处运行期/编译期缺陷 + 再补 3 项门禁（15 → 18）。① P0 运行期崩溃：`utils/api.js` 成功回调把 `releaseIdempotencyKey` 误写成 `this._releaseIdempotencyKey`（多一个下划线），且调用位于 `resolve()` 之前 → 抛错使每一个成功请求的 Promise 永不 settle → 所有页面永远停在 loading + `App.onError` 刷屏。修复方式不仅是改名：改为先 `resolve` 再释放且释放自身 try/catch 兜底 —— 收尾动作不允许挡在响应路径上。② 组件 `recommend-card/index.wxss` 使用标签选择器 `.compact-like image`（组件 wxss 只允许类选择器）→ 改为 `.compact-like__icon` 并同步 WXML 类名。③ 新增门禁：`wxml-structure-contracts`（第 15）、`miniapp-self-method-contracts`（第 16，判据先自证假阳性 —— 首版正则漏认 `this._x = 值` 形式误报 3 个页面）、`wxss-component-selector-contracts`（第 17）、`miniapp-api-client-behavior`（第 18，桩掉 `wx.request` 真跑 api.js 的成功/失败/幂等键释放/收尾容错 4 组行为断言）。负向验证：注入「未定义私有方法」「标签选择器」「多余闭合标签」均精准变红且合法样例不被误报；`UI_GUARDS_MIN=99` 拒绝报绿。基线 PASS 18/18。未验证：微信开发者工具真实编译与真机渲染（本机无该环境）
1.1.0-rc.19	2026-09-19	批 2/3 收尾完成：E2E 互选 8 + 预约 8 场景真实实现（本机活栈 65 passed，负向注入 2 轮）+ INV-011 显式守卫（9 用例）；隐私设置接真实落库（V047）+ 5 死开关/2 死配置移除（产品裁定）+ `PUT /feature-flags` 真持久化（V048）+ 5 个无 SQL Mapper 方法补齐；Task 3.3 四项 + 红娘服务拦截接线（互选 `expires_at`、随访审计、随访风险检测、Onboarding 确认、注销 blocker 接线 + 竞态兜底）；UI 契约门禁 14→18（WXML 结构 / WXSS 选择器 / api.js 行为 / miniapp 请求层，并修复小程序 P0 请求层崩溃）；全量回归 712 / 0 / 0 / 3 全绿（B-9 命令实测）
1.1.0-rc.20	2026-09-20	数据保留流程落地（产品 2026-09-19 确认：注销后数据保留不得低于 36 个月）：V049 `users.closed_at` + `account.retention.purge` 权限（仅 super_admin）+ `AccountConfig.dataRetentionMonths`（36，配置化）+ `DataRetentionService`（人工审核：到期清单 + 幂等匿名化清除 + 审计；保留期内服务端拒绝）+ `DataRetentionGuardTest` 5 用例（负向注入摘掉下限判断恰 1 红）；顺带清偿测试库缺 `user_photos` 表（照片软删路径 BadSqlGrammar 盲区，补表 + 移出 ParityTest 可选白名单）与 MyBatis-Plus `updateById` null 不进 SQL 陷阱（改 `LambdaUpdateWrapper.set(null)`）；隐私政策 §3.3 / PIA §8 「30 天删除」修订为 36 个月；迁移基线 48→49。全量回归 717 / 0 / 0 / 3 全绿；E2E 本机模拟 CI 序列 65/65 全绿（宿主机 Python 3.11）；UAT 用例 V1.1 版 46 用例（9 角色 × 7 路径）编写完成
1.1.0-rc.21	2026-09-21	V1.0.1 配置与规则纠偏（根治「技术默认值被误当产品规则 / 配置存在但未闭环 / 文档代码漂移」）：① 照片上限配置化 `profile.photo.maxCount`（默认 6 未产品确认）+ `ProfilePolicy` + 服务器端并发强校验（新增 `PHOTO_LIMIT_EXCEEDED` 码，拒绝先于对象存储上传不留孤儿）+ 前端 `mergeAppConfig` 嵌套键修复（服务端值真正下发）；② 活体开关闭环 `IdentityPolicy` + `GET /verification/liveness-status` 真实判定点（默认关不阻断实名主流程，开则 `enhancedVerified` 变化，消除假开关）+ 删死 seed `livenessVerification.enabled`；③ 推荐阈值纠偏（60 为技术默认非产品确认）+ 规则版本化 V050 `recommendation_records.threshold_snapshot` + 删死重复配置类 `MatchConfig`；④ 新增 `docs/governance/`（config-register / open-questions / decision-register / hardcoded-rule-audit / config-drift-audit / known-risks）并消解 PENDING 阈值/照片矛盾；⑤ 守卫 `PhotoLimitGuardTest` 8 + `IdentityLivenessGuardTest` 5 + `RecommendationThresholdSnapshotGuardTest` 4（均经负向注入可红）；⑥ canonical key 字面化：`FeatureFlagConfig.KEY_ALIASES`（`identity.liveness.enabled` / 遗留 `livenessVerification.enabled` → 实现字段 `livenessEnabled` 读兼容）+ Controller PUT/DELETE 落库归一 canonical 键 + V051 清理遗留键并写入 canonical 行；⑦ PHOTO-004 真实并发突破实测 `PhotoLimitConcurrencyGuardTest`（3 线程 H2 并发冲顶）——实测咬住「锁照片行+读时计数」在 H2 MVCC 下快照漏读、3/3 全成功突破上限的缺陷，并发控制改为锁用户行（`UserMapper.lockUserRow` FOR UPDATE）+ 锁后新语句计数（0 张照片亦有锁可加，补齐「首张并发」缺口），改后恰 1 成功；⑧ `AGENTS.md` 规则 27（配置与规则治理纪律：技术默认值≠产品确认规则 + canonical key 唯一 + 并发上限必须服务器强校验+并发突破测试）。全量回归 741 / 0 / 0 / 3 全绿（基线 717 + 25 新增 − 1 删死测试）；UI 契约门禁 18/18
1.1.0-rc.22	2026-09-21	运营端机构管理三处写操作 500 修复（清偿计划附 B.1 遗留，2026-09-19 登记、本轮处置）：`OrganizationService` 创建/停用/启用分别写入 `ACCOUNT_STATUS_NORMAL`("normal") 与 `ACCOUNT_STATUS_SUSPENDED`("suspended") —— 那是 `users.account_status` 的取值，而 `organizations.status` 的 CHECK 白名单（V001 `chk_org_status`）只有 `('active','inactive')` → 三个写操作全部违约必崩；二阶影响为 `activities.organizer_org_id` NOT NULL ⇒ 无机构即无法建活动（运营端链路级阻塞）。修复：`Constants` 新增 `ORG_STATUS_ACTIVE/INACTIVE`（独立于账号状态）；三处改用 `active`/`inactive`；`OrganizationService.ALLOWED_TYPES` 补 `type` 白名单前置校验（非法值 400 取代撞 `chk_org_type` 的 500）；「机构不存在」由裸 `RuntimeException`（→500）改为 `NOT_FOUND`(404)；异常统一为实际被 `@ExceptionHandler` 捕获的 `GlobalExceptionHandler.BusinessException`（独立类 `shared.exception.BusinessException` 无 handler，抛它仍会 500 —— 全仓仅 `AnalyticsService` 一处既存误用）。根因第三重盲区同步补齐：`schema-h2.sql` 的 `organizations` 此前未复刻这两条 CHECK，故 H2 上写 `'normal'` 畅通无阻 —— 已补 CHECK ×2 + NOT NULL + DEFAULT。新增守卫 `OrganizationConstraintParityTest`（生产 DDL ↔ 测试库 ↔ 后端白名单 ↔ Constants 四方比对 + 解析器自检）与 `OrganizationServiceTest`（真实 DB，10 用例）。✅ 2026-09-22 补跑验证全部通过（此前记为「待验证」）：全量回归 757 / 0 / 0 / 3 全绿（BUILD SUCCESS，108 个测试类，6:44；基线 741 + 新增 16 = 757）；负向注入 16 例变 3 失败 + 7 错误（守卫三条断言全中 + H2 `CHK_ORG_STATUS` 拦下 7 例；注入采用仓库只读挂载 + 容器内副本改写，源码零污染）；活栈实测创建/停用/启用均 2xx、非法 type 与缺字段 400、不存在 404、全程零 5xx（15/15）；对已部署栈 `pytest tests/e2e` 65 passed。本项已验证关闭。
1.1.0-rc.23	2026-09-22	机构审计归属修复 + 测试环境 Docker 化部署与全链验证。① 活栈验收中新发现并修复：复核 `audit_logs` 见 `CREATE_ORGANIZATION` 的 `operator_id` 7/7 为 NULL（而 `DISABLE/ENABLE_ORGANIZATION` 均正确记录）—— 控制器持有 `@AuthenticationPrincipal` 却未向 Service 透传，审计不可归属等于没有审计；`createOrganization(params, operatorId)` 改为透传 `principal.id()`，并新增断言 `createOrganizationRecordsOperatorInAuditLog` 长期守卫。修后复验：新写入的 7 条 CREATE 审计全带操作人，旧 14 条仍为 NULL（前后对照清晰）。② Docker 测试环境部署成功：`docker compose -p danyang` 起全栈 6 容器（postgres 5434 / redis 6381 / minio 9003-9004 / backend 8085 / admin-web / nginx 6688），51 个 Flyway 迁移全部成功、`GET /admin/` 200、`pytest tests/e2e` 65 passed。③ 测试工具链重建并固化为仓库资产：测试镜像 `danyang-match-backend-test` 与命名卷 `danyang-m2-cache` 因 Docker Desktop 重装一并丢失 → 构建定义落盘 `infrastructure/test-toolchain/Dockerfile`（此前它是临时产物所以才会丢）；卷由 108.5MB 不完整快照补全（原缺 `spring-boot-starter-parent`，故离线跑必失败）。④ 环境坑（已同步 known-risks）：Docker Hub 域名 DNS 被投毒（`registry-1.docker.io`→31.13.95.37、`auth.docker.io`→162.125.32.15，均非真实 IP）→ 改由 `docker.m.daocloud.io` 拉取后 retag；Maven 走阿里云（实测 5337 vs 685 KB/s，快 8 倍）；compose 项目名原用 `infra`，与另一项目 `AI智习室`（workdir `E:\develop\AI智习室\ai-study-room\infra`）撞名，其 `--remove-orphans` 会把本项目的容器当孤儿删掉 → 改用 `-p danyang`。⑤ UI 门禁脆弱性修复：第 16 项 `ui-document-baseline-contracts.mjs` 报假红（`未能解析出端口映射（守卫自身失效）`），真因是 `docker-compose.staging.yml` 是 CRLF 而守卫正则要求 `\n` 紧随 `container_name` 之后（`prod.yml` 是 LF 所以此前能过）→ 解析改为行尾无关，真实断言未削弱。全量回归 757 / 0 / 0 / 3 全绿；UI 契约门禁 18/18；E2E 65/65。验证脚本留痕 `.workbuddy/run-regression.sh`、`negative-injection.sh`、`org-live-acceptance.py`

历史基线快照（2026-09-09 及更早，仅供追溯）

历史记录边界：以下为 2026-09-09 重新审查前的开发日志快照，仅用于追溯，不代表当前验收状态；其中的 ✅ / 已完成 / 已部署 / 测试数量 / 运行地址均不可作为验收证据，须以对应 Phase 的 Completion Report 与本文顶部「当前唯一有效状态」为准。

保留为治理痕迹（已被后续 14 轮 KEEP-VERIFY 复验整体推翻）：当时自述 Git 基线「无 .git」、 Admin Web type-check 3 错误、Miniapp TS 27 错误、Backend「未验证」、V1.1 E2E「1 passed / 26 failed / 48 errors」、UAT/RC/Production「NO-GO」，以及一张「P01~P26 全部完成 ✅ / 不变量 23/23 ✅ / API 16/16 ✅」的自评表。

原文可从 Git 历史取回：git log --all -- docs/STATUS.md。

V1.1 当前进度

Phase 01~11 — V1.1 首轮实现（2026-09-09 快照）

⚠️ 本段原为 2026-09-09 期的逐项任务表，其中的 ✅ 是当时的自评，不构成验收证据；已收敛为索引，结论一律以本文顶部表与「当前 Phase」各节为准。

Phase	名称	权威结论位置
01	V1.1 基线搭建	`docs/Phase-01-V11-Recovery-Completion-Report-2026-09-09.md`
02	Auth + Operator + RBAC 扩展	顶部「当前唯一有效状态」
03	实名认证扩展（人脸核验预留）	同上
04	Profile + Preference + 本地资格	同上（含本地资格声明与审核）
05	审核模块扩展（本地资格）	同上
06	Match Engine 扩展（本地资格 Eligibility）	同上
07	V1.1 首页重构 + 找对象	2026-09-16 通过用户验收（顶部表 + `Phase-07-…-2026-09-13.md`）
08	Like / Match / Block	2026-09-16 KEEP-VERIFY 复验关闭
09	Text Chat	2026-09-16 KEEP-VERIFY 复验关闭
10	Image & Chat Safety	2026-09-16 KEEP-VERIFY 复验关闭
11	公益服务通知扩展	2026-09-16 KEEP-VERIFY 复验关闭

Phase 14 — 多类型公益活动 ✅ 已完成（2026-09-17 KEEP-VERIFY/EXTEND 复验通过）

任务	状态
ActivityType 分类 + 按类型报名策略（实名/本地资格/性别名额）	✅
容量原子扣减（`insertIfCapacityAvailable` / `approveIfCapacityAvailable`）	✅ 新增
`activityType` / `orgRole` 生产 CHECK 白名单校验（D3）	✅ 新增
多组织关系 + 容量分组落库与回读	✅
运营端：`/operator/activities` 建活动改走 V1.1；组织/分组 4 端点；列表补 `activityType`	✅
用户端：删除 3 个错挂的运营写入端点（双实现）	✅
Miniapp：分类 Tabs code 对齐生产白名单（6 类）+ 类型化卡片 + 差异化资格提示	✅
Admin：`ActivityManagementView.vue` 类型驱动动态表单 + `/activities` 路由与导航	✅ 新增
INV-020：组织接口零用户字段；报名列表仅运营端且要求 `activity.view`	✅
测试库补齐 V023 列/约束 + 三张缺失表；activity 五表移入必选集合	✅
测试：`ActivityPhase14Test`（23）+ `ActivityConstraintGuardTest`（9，解析真实 DDL 与前端源码）	✅ 新增
全量回归 450 tests 全绿	✅

Phase 15 — 活动报名、审核与签到 ✅ 已完成（2026-09-17 KEEP-VERIFY/EXTEND 复验通过）

任务	状态
D1 必崩：签到码一生成即作废（`generate` 写 `"used"` → 扫码 100% 失败）→ 改为 `issued`	✅
重复签到：原子条件更新 `checkinIfNotCheckedIn` + 幂等返回 `alreadyCheckedIn`	✅ 新增
D9 必崩：取消/拒绝后重报名撞 `UNIQUE(activity_id,user_id)` → 复用记录 `reuseIfCapacityAvailable`	✅
审核/取消原子化：`rejectIfPending` / `cancelIfActive`；取消补审计日志	✅
后台报名列表含 pending（原只查 approved，审核页无待审项）	✅
报名窗口 `registration_start_at` / `registration_end_at` 生效	✅ 新增
容量分组真正参与扣减（`incrementIfAvailable` / `decrementIfPositive`）	✅ 新增
计划项③：V040 `activity_staff_assignments` + 签到/审核数据范围校验（INV-020）	✅ 新增
Admin：`ActivityCheckinView.vue` 签到工作台 + `/activities/checkin` 路由与导航	✅ 新增
Miniapp：`cancelRegistration` 封装（后端端点存在但前端无入口）	✅
测试库补齐报名表 UNIQUE + 两个 CHECK；两表移入必选集合；迁移基线 39→40	✅
测试：`ActivityPhase15Test`（21）+ `CheckinServiceTest` 假绿改真实守卫（5）+ 约束守卫（2）	✅ 新增
全量回归 474 tests 全绿	✅

Phase 16 — 活动互选与双方开启沟通确认 ✅ 已完成（2026-09-17 KEEP-VERIFY/EXTEND 复验通过）

任务	状态
D1（Critical，Gate 缺陷 · INV-014/015）双确认后不建 Match/会话	✅ 重写 `confirmConnection` 走 `confirmActivityInterest`，exactly-once（`both_confirmed_at` NULL→非NULL 仅一方赢家建 Match+会话并 `bindMatch`）
D2（High，双实现分裂）旧/新路径各自为政	✅ 统一到 `RelationshipService.confirmActivityInterest`（返回 `matchId` + `priorUnmatch`）
D3（High，隐藏编译缺陷 · 必崩级） Phase 15 引用未定义 `matchMapper.reopenEpisode`	✅ `MatchMapper` 补 `@Update reopenEpisode`（`WHERE status='unmatched' AND deleted_at IS NULL`）；Phase 15 提交态从未真正编译通过
D4（High，INV-006 泄露）本侧未确认即回显对方确认态	✅ `getMyConsentStatus` 改 `partnerAccepted = myAccepted && partnerSideAccepted`
D5（Medium，缺会话）复用/新建 Match 后未显式开启会话	✅ `confirmActivityInterest` 显式 `getOrCreateConversation` 并返回 `conversationAutoCreated=true`
D6（Medium，测试库零覆盖）缺 `activity_mutual_connection_consents` 表	✅ `schema-h2.sql` 补表（对齐 V024+V037+V041）；`EntityMigrationParityTest` 移入 `REQUIRED_IN_TEST_SCHEMA`；`MigrationValidationTest` 基线 40→41
D7（Medium，无互选测试）	✅ 新建 `ActivityMutualConsentServiceTest`（7 用例，走真实方法路径）
D8（Medium，断言与 #20 冲突） `ChatPhase09IntegrationTest:344` 假设每次新建独立会话	✅ 改为 `assertEquals`（认可 AGENTS.md #20 复用语义），保留"复用同一消息管线"主断言
负向验证（注释 createMatchAndConversation → 2 用例精准变红并还原）	✅ 守卫有牙
新增 V041 `expires_at`+`match_id` 迁移	✅
全量回归 481 tests 全绿	✅

2026-09-17 复验结论（KEEP-VERIFY/EXTEND）：历史 ✅ 不可信。活动互选存在核心 Gate 缺陷——双确认后根本不建 Match/会话（INV-014/015）；且 Phase 15 提交态引用未定义的 reopenEpisode，整个模块从未编译通过，"474 绿"是假象。已统一双实现到 RelationshipService.confirmActivityInterest，修复 7 处缺陷 + 1 处隐藏编译缺陷 + 1 处测试保真度缺陷，新建 7 用例互选测试，并经负向验证证明守卫有牙。报告：docs/Phase-16-V11-Recovery-Completion-Report-2026-09-17.md

Phase 17 — 举报与风控 ✅ 已完成（2026-09-17 KEEP-VERIFY/EXTEND 复验通过）

任务	状态
D1（Critical，必崩级测试盲区） `reports`/`risk_events`/`risk_actions` 三表在 H2 缺失 → 风控/举报真实 DB 路径零覆盖；`ReportServiceTest` 全是 `assertTrue(true)` 假绿	✅ `schema-h2.sql` 补齐三表（对齐 V012，去外键留 CHECK）；`EntityMigrationParityTest` 移出 `TEST_SCHEMA_OPTIONAL_TABLES` 入 `REQUIRED_IN_TEST_SCHEMA`
D3（High，敏感访问无审计 · AGENTS.md #8）查看他人风险画像/举报详情不记录审计	✅ 新增 `AuditLogService.recordSensitiveAccess`；`getReportDetail`/`getUserRiskProfile`/`RiskController.getRiskEvents` 三端点接线
D4（Medium，审计完整性） `saveAuditLog` 未填 `ip`/`userAgent`	✅ 增强补全（与 `AuthorizationAuditListener` 同模式取 `RequestContextHolder`）
D5（Medium，数据一致性） `findByUserId` 未过滤 `deleted_at`	✅ 补 `deleted_at IS NULL`（与 `sumScoreByUserId` 一致）
D2（Medium，审计缺失） `manualFlagRisk` 人工标记无审计	✅ 注入 `AuditLogMapper`，写 `MANUAL_FLAG_RISK`
D6（隐藏编译缺陷） `javax.servlet` → Spring Boot 3.x 已迁移 `jakarta.servlet`；`risk_events` 漏 `updated_at` 列	✅ 三处 import 改 jakarta；`risk_events` 补 `updated_at`
来源接入代码层（detectCounselingRisk/detectAppointmentRisk/detectActivityRisk）运行时已被调用，非假绿	✅ 确认（不重写来源逻辑）
最小可见（INV-006 同族）：后台风险页不暴露无关咨询正文	✅ 延续既有约束
负向验证（注释 getReportDetail 敏感访问审计 → D3 守卫精准变红并还原）	✅ 守卫有牙
新增 `ReportAndRiskPhase17IntegrationTest`（7 用例）	✅
全量回归 488 tests 全绿	✅

2026-09-17 复验结论（KEEP-VERIFY/EXTEND）：历史 ✅ 不可信。风控/举报整条真实 DB 路径因测试库缺三表而零覆盖，ReportServiceTest 假绿掩盖盲区；且敏感访问（查看他人风险画像/举报）此前无审计（违反 AGENTS.md #8 默认拒绝 + 查看需审计）。已修复 6 处真实缺陷（含 1 处必崩级测试盲区、1 处隐藏 jakarta 编译缺陷），补齐三表并新增 7 例集成测试，负向验证证明守卫有牙。报告：docs/Phase-17-V11-Recovery-Completion-Report-2026-09-17.md

Phase 18 — 申诉 ✅ 已完成（2026-09-17 KEEP-VERIFY 复验通过）

任务	状态
D1（Critical，必崩级测试盲区） `appeals` 表缺失 + `AppealServiceTest` 9 例中 6 例 `assertTrue(true)` 假绿 → 申诉真实 DB 路径零覆盖	✅ 补 `appeals` 表（对齐 V013，去外键留 `chk_appeal_status`/`chk_appeal_type`）；移出白名单入 `REQUIRED_IN_TEST_SCHEMA`；删除假绿测试，新建 `AppealPhase18IntegrationTest`（15 例）
D2（High，生产故障 · 只在 PG 上炸） `escalateAppeal` 向 `operatorId` 发用户通知 → 撞 `notifications.user_id → users(id)` FK（operators 与 users 不同表）→ 升级事务整体回滚	✅ 移除非法通知；升级后进入后台待办队列由风控员决策
D3（High，生产故障 · 只在 PG 上炸） `appealType` 未校验 `chk_appeal_type` 白名单	✅ 校验白名单 + 必须与处置类型一致；缺省按处置类型推导
D4（Medium，功能死胡同） `escalated` 无法再处理（后端只收 pending/reviewing；前端按钮仅 pending）	✅ 后端原子认领放行 escalated；`getPendingAppeals` 返回 pending+escalated；前端放开处理入口
D5（Medium，并发） `processAppeal` 先读后写无原子守卫 → 并发双处理相互覆盖	✅ 新增 `markReviewingIfProcessable` 原子认领，仅赢家继续
D6（Low，一致性） `findByUserId`/`findPending`/`findByStatusPaged` 未过滤 `deleted_at`	✅ 三处补 `deleted_at IS NULL`
D7（Low） `approveAppeal` 硬编码 `"resolved"`	✅ 改用 `Constants.RISK_ACTION_STATUS_RESOLVED`
D8（Low，前后端契约） miniapp 传 `evidenceFileIds`、后端只读 `evidence`	✅ DTO 增 `evidenceFileIds`，服务层序列化映射进 `evidence`
负向验证（误伤其他处置 → Gate 用例精准变红并还原）	✅ 守卫有牙
admin-web `vue-tsc --noEmit` EXITCODE=0	✅
全量回归 494 tests 全绿	✅

2026-09-17 复验结论（KEEP-VERIFY）：历史 ✅ 不可信。申诉整条真实 DB 路径因测试库缺 appeals 表而零覆盖，AppealServiceTest 的 6 处 assertTrue(true) 假绿恰好掩盖 Gate 四条不变量；且 escalate 向 operator 发用户通知会撞 notifications.user_id → users(id) FK （PG 上升级 100% 失败）、appealType 未校验生产 CHECK 白名单。已修复 8 处真实缺陷（含 1 处必崩级测试盲区、2 处「只在 PG 上炸」的生产故障），补齐 appeals 表并新增 15 例集成测试、删除 9 例假绿，负向验证证明 Gate 守卫有牙。报告：docs/Phase-18-V11-Recovery-Completion-Report-2026-09-17.md

Phase 13A — 公益婚恋咨询与婚前辅导（核心链路）✅ 已完成（2026-09-17 KEEP-VERIFY/EXTEND 复验通过）

任务	状态
V022 counseling_services + counseling_followups 迁移	✅
V039 Phase 13A 迁移（counseling 幂等键 + 三个 CHECK 白名单显式固化）	✅ 新增
`CounselingService`（权威实现，合并孤儿类 `CounselingServiceApp` 后删除）	✅ 重写
用户端 API：intro / create / list / detail / cancel / companion-confirm	✅
后台 API：queue / assigned / detail / assign / schedule / start / followup / complete	✅ 8 端点
INV-012 Counselor assigned scope 实现（`assignIfPending` 条件更新防并发覆盖）	✅
INV-013 正文保护（脱敏分层：user/assigned=全文；matchmaker/operator=脱敏；manager=摘要无 followups）	✅
INV-005 伴侣须本人确认	✅
合法状态机 `ALLOWED_TRANSITIONS` + `assertTransition`	✅ 新增
幂等（`idempotencyKey` + `uk_counseling_idem` 唯一索引）	✅ 新增
Miniapp U55-U59 页面（咨询介绍/申请/我的/婚前辅导），字段名对齐后端 + 检查 `success`	✅
Admin `CounselingView.vue` 重写（四态 + 二次确认）+ `/counseling` 路由注册	✅
测试：`CounselingPhase13ATest`（25）+ `CounselingConstraintGuardTest`（5）	✅ 新增
全量回归 420 tests 全绿	✅

Phase 13 — 公益红娘服务转介（2026-09-09 快照）

⚠️ 该首轮任务表（✅ 为当时自评）已被下方「Phase 13 — 公益红娘转介 ✅ 已完成（2026-09-16 KEEP-VERIFY/EXTEND 复验通过）」取代 —— 后者记录了复验修复的真实缺陷与永久守卫，以那节为准。

Phase 12 — 关系状态轻量扩展 ✅ 已完成（2026-09-16 KEEP-VERIFY 复验通过）

任务	状态
Successful首页服务建议（婚前辅导引导）	✅
GettingToKnow服务建议规则	✅
Counseling recommendation rules	✅
成功关系双确认 / 恢复 / 退出 / 历史 Episode / 并发确认	✅ 行为测试 14 项
getting_to_know 阶段婚前辅导入口引导（计划项 2）	✅ 已接线 `HomeApplicationService.buildServiceRecommendations`
工作人员不能替用户确认成功关系（INV-005）	✅ 非成员路径断言抛业务异常

2026-09-16 复验结论（KEEP-VERIFY/EXTEND）：历史 ✅ 不可信，逐条核对运行时路径后修复 4 处缺陷：

D1（Critical，生产故障 · 同一族系统性缺陷） 实体与生产迁移系统性漂移：23 张表、50 个列在 db/migration 中根本不存在，而测试库 schema-h2.sql 手写了它们 → 全量测试绿 = 假绿。其中 11 张表属"INSERT 必崩"级（缺 id/created_at/updated_at，被 AutoFillHandler 强制填充，每次写入必进 SQL）：matches（缺 episode/source_id/last_activity_at/unmatched_by/deleted_at）、 user_preferences（缺 id + 11 个权重列）、permissions、roles、consent_records、risk_events、 review_reasons、match_rule_configs、matchmaker_followups、matchmaker_recommendations、 user_privacy_settings。真实 PG 上 Match 创建、择偶偏好保存、权限/角色写入、同意记录、风险事件全部失败。修复：新增 V037__align_entity_columns_with_migrations.sql（幂等 ADD COLUMN IF NOT EXISTS，含存量数据 episode 回填与 id 补发）。

D2（High） RelationshipService.createMatch 不写 episode/lastActivityAt，与 MatchService.createOrReuseMatch 形成双路径字段填充不一致；且 episode 为 null 时 MatchService 的 m.getEpisode() + 1 对 Integer 自动拆箱抛 NPE。修复：两条路径统一按 AGENTS.md #20 推导 episode，并做 null 兜底。

D3（High） 测试库缺 user_identities 等 7 张表 → GET /api/v1/home 在测试环境直接 BadSqlGrammar("Table USER_IDENTITIES not found")，首页接口零回归覆盖。修复：补齐 user_identities/review_tasks/local_eligibility_evidences/home_banners/service_locations/ content_articles/activities 七张表（列对齐生产迁移）。

D4（Medium） Phase 12 计划项 2 实际未实现：getting_to_know 分支只产出 counseling，婚前辅导入口仅在 matched_successfully 才出现。修复：HomeApplicationService.buildServiceRecommendations 的 getting_to_know 分支补 premarital 引导（与 counseling 并列，不互相挤占）。

新增永久守卫 EntityMigrationParityTest（5 用例）：把「实体字段 ⊆ 生产迁移累积列」与「测试库覆盖关键业务表」固化为编译后自动可验证的不变量，并区分「必崩级 / 潜伏级」。经 两轮负向验证证明会变红（第一轮分级过窄已修正：episode 由"潜伏级"纠正为"必崩级"）。

删除假测试：RelationshipStatusServiceTest 与 RelationshipStatusServiceDoubleConfirmTest 原含 assertTrue(true); // 占位测试，对 INV-005 零覆盖（AGENTS.md 明令禁止）→ 已删除占位断言，行为验证移至走真实服务方法的 RelationshipProgressPhase12Test（14 用例，含并发确认）。

报告：docs/Phase-12-V11-Recovery-Completion-Report-2026-09-16.md

Phase 13 — 公益红娘转介 ✅ 已完成（2026-09-16 KEEP-VERIFY/EXTEND 复验通过）

任务	状态
保留红娘服务和人工推荐；任何工作人员不能替用户 Like（INV-005）	✅ 行为测试 4 项
补齐转介咨询、活动、服务站的用户同意、来源追踪和状态记录	✅ 行为测试 6 项
红娘只能看转介状态和必要摘要，不能读取 counseling followup 正文（INV-013）	✅ 行为测试 3 项
红娘归属校验（推荐/转介不得越权代操作）	✅ 负向测试 4 项

2026-09-16 复验结论（KEEP-VERIFY/EXTEND）：历史 ✅ 不可信，逐条核对运行时路径与生产约束后修复 7 处缺陷：

D1（Critical，生产故障） matchmaker_recommendations.status 代码写入 liked/passed/confirmed_mutual，而生产 V009 chk_rec_status 只允许 pending_view/viewed/responded 且从未扩展 → 真实 PG 上用户接受/跳过推荐必崩（DataIntegrityViolation）。测试库 schema-h2.sql 未复刻该 CHECK，故长期静默。修复： V038__align_matchmaker_status_constraints.sql 以 DROP CONSTRAINT IF EXISTS + ADD CONSTRAINT 扩展白名单。

D2（Critical，生产故障） MatchmakerController 缺省 serviceType="recommendation" 不在 chk_matchmaker_service_type 白名单 → 提交红娘服务必崩。修复：同 V038 扩展（原 7 值 + recommendation/referral_counseling/referral_activity/referral_station）。

D3（High，越权） MatchmakerServiceService.recommendPartner 无 assignedOperatorId 归属校验 → 任意红娘可替非本人负责的服务发起推荐（并可推荐给自己）。修复：补归属校验 + 禁止自我推荐。

D4（High，越权读） getServiceDetail 无归属校验且返回完整用户资料（userId/description/userProfile/ followups）→ 任意红娘可读任意用户敏感详情。修复：签名加 requesterId，负责人得完整视图，非负责人得脱敏视图（去 userProfile/userId/followups，仅 followupCount + viewerIsOwner=false）。

D5（High，越权写） ReferralService 的 userId 取自请求体且零授权校验 → 任意持 matchmaker.service 权限者可替任意用户发起转介。修复：新增 assertMatchmakerServesUser，在 referToServiceStation/referToActivity 入口强制校验"存在进行中的服务关系"。

D6（High，生产故障） MatchmakerFollowupMapper.findByServiceId 只声明方法、无 @Select → 运行时 Invalid bound statement (not found)，getServiceDetail 必崩。该缺陷由本轮新增测试首次暴露 （历史测试从未调用该路径）。修复：补 @Select。

D7（Medium，契约缺口） admin-web 5 处 API 缺口：/matchmaker/services/operator/queue、 /matchmaker/recommendations/operator、PUT /matchmaker/services/{id}/assign、 POST /matchmaker/services/{id}/recommendation、/referrals/my-history（C 端端点被运营端误用）。修复：后端补 GET /operator/matchmaker/recommendations 与 GET /referrals/operator/history 两个运营端端点（含 MatchmakerServiceMapper.findActiveByOperatorAndUser、 MatchmakerRecommendationMapper.findByOperatorId、ReferralService.getReferralHistoryByOperator），前端改路径、assign 改 POST + body operatorId；小程序新增 miniapp/services/referralService.js。

测试库盲区修复：schema-h2.sql 补 matchmaker_services/matchmaker_recommendations/ matchmaker_followups 三表（约束与 V038 对齐）；EntityMigrationParityTest 的 3 张 matchmaker 表从 TEST_SCHEMA_OPTIONAL_TABLES 移入 REQUIRED_IN_TEST_SCHEMA；MigrationValidationTest 基线 37 → 38。

新增永久守卫 MatchmakerReferralPhase13Test（17 用例，@SpringBootTest 走真实方法路径）+ 重写 MatchmakerServiceTest（6 用例）。关键教训：首版常量守卫硬编码白名单副本，注入 D1 缺陷后 仍全绿（对漂移零反应）→ 重写为直接解析 db/migration/V*.sql，按文件名顺序应用 DROP CONSTRAINT IF EXISTS + ADD CONSTRAINT 取"最终有效"白名单，并内置解析器自检用例。修正后经第二轮负向验证证明会红（Tests run: 23, Failures: 1, Errors: 2 / BUILD FAILURE）。

删除假测试：MatchmakerServiceTest.testMatchmakerCannotLike 原为 assertTrue(true)； CoreInvariantsTest 的 INV-007 断言的是 MATCHMAKER_STATUS_* 常量（名不副实）、INV-010 亦为 assertTrue(true) → 已删除占位、如实改名并注明行为验证位置。

报告：docs/Phase-13-V11-Recovery-Completion-Report-2026-09-16.md

Phase 13A — 婚恋咨询与婚前辅导 ✅ 已完成（2026-09-17 KEEP-VERIFY/EXTEND 复验通过）

计划项	状态
计划项 1 Admin Vue 修复 + `/counseling` 路由注册	✅ `vue-tsc` EXIT=0
计划项 2 认证主体 userId + 幂等 + 取消 + owner 校验 + 状态迁移	✅ 8 用例
计划项 3 条件更新解决并发 + Assigned Service 边界	✅ `assignIfPending` + 4 用例
计划项 4 Manager 可摘要不可读正文	✅ 7 用例
计划项 5 婚前辅导复用 service type + 伴侣自主确认	✅ 4 用例
计划项 6 U55~U59 类型/契约/四态/非医疗化文案	✅ 双端 type-check EXIT=0

2026-09-17 复验结论（KEEP-VERIFY/EXTEND）：历史 ✅ 不可信。counseling 模块存在 双实现——线上权威 CounselingService（167 行）零测试，唯一被测的 CounselingServiceApp（280 行）是孤儿类（无注入点、无端点可达，生产永不执行）。已将其流程合并入 CounselingService 并删除孤儿类及仅其使用的 3 个 DTO 与测死代码的测试。修复 9 处缺陷：

D1（Critical，生产故障 · INV-013 泄露） 咨询正文 userRequestSummary 原文被写入 WARN 日志 （CounselingServiceApp:81，同 Phase 10 D2 一族）。修复：合并后只记 serviceId + riskLevel。

D2（High，越权） 申请 userId 取自请求体而非认证主体 → 可替他人提交申请。修复：Controller 强制 principal.id()。

D3（High，并发） assignCounselor 用「先读后写」→ 两管理员并发分配静默覆盖。修复：assignIfPending 条件更新（WHERE status='pending' AND assigned_operator_id IS NULL）， affectedRows=0 明确报错。

D4（High，越权读） counseling_manager 经 getDetail 可读 followups 正文 → INV-013 绕过通道。修复：manager 只加回 userRequestSummary，不装配 followups。

D5（Medium） 无状态机 → 「已完成」可被再取消。修复：ALLOWED_TRANSITIONS + assertTransition。

D6（Medium，生产故障） GET /counseling/services/intro 后端不存在，小程序 intro 页 100% 无数据（且被 /services/{id} 吞掉）。修复：补端点并声明在变量路径之前。

D7（Medium，契约） Admin 调用 5 条不存在的 /services/operator/*（404）+ 缺四态。修复：后端补 8 个运营端端点（@PreAuthorize），前端整体重写。

D8（Medium，契约） 小程序字段名错（userRequestSummary/preferredServiceMode）+ 无幂等

my-counseling 未检查 success（403 静默空列表）+ 跳转不存在的页 + WXML 内调用方法（非法）。

D9（Medium，测试保真度） 测试库 counseling 两表零 CHECK 约束，counseling_services 未列入 EntityMigrationParityTest 任何集合（= 零覆盖）。修复：补 3 个 CHECK + 建 counseling_followups + 两表移入 REQUIRED_IN_TEST_SCHEMA。

另修 4 处测试基建缺陷（T1~T4）：① 守卫因 surefire <workingDirectory>${project.basedir}/.. 指向仓库根而找不到 DDL（且 backend/ 是子目录非祖先，回溯也找不到）→ 恒真假绿； ② 全限定 @com.baomidou...TableField(exist=false) 漏解析 → 假漂移警报； ③ OperatorEndpointPermissionCoverageTest 扫到私有辅助方法（假阳性）； ④ 两处测试自身逻辑缺陷（陈旧内存快照比较、Instant 纳秒 vs DB 微秒精度）。

负向验证两轮：① 从 V039 移除 scheduled → 常量守卫精准变红 （证明其解析的是真实 DDL 而非副本）；② 注入「并发回退先读后写 / manager 读 followups / 状态机守卫失效」→ 三个用例各自精准变红。均已还原（grep -c "NEG-VAL" = 0）。

全量回归：Tests run: 420, Failures: 0, Errors: 0, Skipped: 3 / BUILD SUCCESS（4:49）。基线 391 → 420（净 +29）。

报告：docs/Phase-13A-V11-Recovery-Completion-Report-2026-09-17.md

V1.1 待实现模块（按 Phase 顺序）

模块	对应 Phase	状态
Home Aggregate API + V1.1首页	Phase 07	✅ 已完成
Banner 管理（后端+前端）	Phase 19	✅ 已完成（2026-09-17 复验关闭）
本地资格声明与审核	Phase 04~05	✅ 已完成（2026-09-12 复验关闭；`LocalEligibilityService` 已实现、测试库 `local_eligibility_*` 表就位；仅「触发策略 / 文件保留期限」属产品待确认，见 `PENDING_DECISIONS.md`）
公益红娘服务转介	Phase 13	✅ 已完成
婚恋咨询 + 婚前辅导（Phase 13A）	Phase 13A	✅ 已完成（2026-09-17 复验关闭）
内容管理（婚恋课堂/反诈）	Phase 19	✅ 已完成（2026-09-17 复验关闭）
专项公益服务项目	Phase 19	✅ 已完成（2026-09-17 复验关闭）
善缘服务站 + 用户端公益服务页面（U37/U49~U54/U60/U61/U64）	Phase 19	✅ 已完成（含 V042 临时公告）
V1.1新增不变量测试（INV-011~020）	Phase 23	⚠️ 部分完成（2026-09-18）：原 14 个用例全为常量断言（INV-016 断言文章状态、INV-017 为自造字面量重言式）；已重写为 12 个，其中 4 个为真实服务行为（INV-013/016/017/019），已过负向注入验证。详见 `docs/Phase-23-V11-Recovery-Completion-Report-2026-09-18.md`

当前运行状态

管理后台: http://localhost:13520/  (凭证由本地环境变量或安全 Seed 提供)
API 网关: http://localhost:8085/api/v1/
PostgreSQL: localhost:5434 (danyang_match)
Redis: localhost:6381
MinIO: localhost:9003 (凭证由本地环境变量提供)

管理端端口口径（2026-09-18 对齐为 13520）：

形态	端口	说明
admin-web 本地开发（vite）	13520	权威声明在 `admin-web/vite.config.ts`；`strictPort: true`，被占用直接失败而非静默漂移到 13521
生产 admin 容器发布	13520	声明在 `infrastructure/docker-compose.prod.yml`——该文件位于 `.gitignore` 的「Secrets and certificates」段，刻意不进版本控制，故此改动仅在部署机生效；仍绑定 `127.0.0.1`，对外访问走 nginx 80/443 + `/admin/`
本地整套栈的管理端入口	6688	admin 容器不发布端口，与 `/api` 同由 nginx 的 6688 暴露（6688 是 nginx 入口，不是纯管理端端口）
staging admin 容器发布	3001	为与生产同机共存，staging 全部端口按「生产 + 1」错开（5433/6380/8081/3001）；`tests/uat/run-uat.sh` 的 `UAT_ADMIN_URL` 默认指向它

ui-tests/ui-document-baseline-contracts.mjs 钉住「本地开发 / 本文档 / 生产 compose」三者端口一致：前两处为硬断言；生产 compose 因不在版本控制内，采取「存在才断言」——CI 上该文件不存在，显式打印 skip 而非假红。

当前 Phase

Phase 14 — 多类型公益活动（核心链路）✅ 已完成

任务	状态
V023 activity_type/registration_policy/target_group/industry_scope 字段扩展	✅
activity_organizations 多组织关联表	✅
activity_capacity_groups 容量分组表	✅
Activity Java实体扩展（6个新字段）	✅
ActivityOrganization + ActivityCapacityGroup 实体/Mapper	✅
ActivityService 新增4个V1.1方法	✅
ActivityController 新增6个API端点	✅
Constants 新增 ACTIVITY_TYPE_* + ORG_ROLE_* 常量	✅

Phase 13A（公益婚恋咨询与婚前辅导）— 已完成 ✅

Phase 19 — 统一运营后台 + 用户端公益服务页面 ✅ 已完成（2026-09-17 复验关闭）

复验报告：docs/Phase-19-V11-Recovery-Completion-Report-2026-09-17.md 后端全量回归：Tests run: 602, Failures: 0, Errors: 0, Skipped: 3 / BUILD SUCCESS admin-web：vue-tsc --noEmit EXIT=0、vite build EXIT=0；小程序：tsc --noEmit EXIT=0；ui-tests 14/14 PASS

任务	状态
V026 内容+专项项目+组织关系表	✅
V042 善缘服务站「临时公告」表（本轮新建）	✅
ContentService（分类/文章 CRUD + publish/offline）	✅
Content 运营端接口分离（修「发布死路」/「分类停用不可恢复」）	✅
ServiceProgramService（项目CRUD + 成员审批 + 退出/移除/统计）	✅
Banner 运营端（白名单校验 400 而非 500 + 软删过滤 + 禁外链 + 预览）	✅
善缘服务站运营端（信息维护 + 公告五端点 + 权限下沉方法级）	✅
预约 IDOR 修复（principal.id() + 归属校验 + DataScopeGuard）	✅
Admin Web 前端（Banner / 内容 / 服务项目 / 服务站公告）	✅
用户端 U37 四组重构 + U49~U54/U60/U61/U64 页面	✅

本轮复验修复 25 处真实缺陷，其中高价值项：服务站公告能力整条不可达（Service + 表都在、零端点）；服务站 create/update 越权写（写端点只受 service_location.view 保护，manage 是从未使用的死权限）且该控制器未纳入权限覆盖守卫；Banner 校验抛 500；Content 发布死路；ServiceProgram 审批死路 / 草稿泄露 / 成员数恒 0 / 退出未实现；测试库缺 content_categories 与 service_location_announcements（对应路径零覆盖）。新增守卫：ServiceLocationAnnouncementPhase19IntegrationTest(24) / ServiceLocationControllerPermissionContractTest(5) / ServiceLocationAnnouncementConstraintParityTest(5)。负向验证 3 处注入 → 4 个用例精准变红并还原（NEG-VAL 残留 0）。

Phase 20 — Analytics 数据统计与管理驾驶舱 ✅ 已完成（2026-09-17 复验关闭）

复验报告：docs/Phase-20-V11-Recovery-Completion-Report-2026-09-17.md 指标字典：docs/ANALYTICS_METRICS.md（与 MetricCatalog 逐条对应）后端全量回归：Tests run: 648, Failures: 0, Errors: 0, Skipped: 3 / BUILD SUCCESS admin-web：vue-tsc --noEmit EXIT=0；负向验证 2 轮 7 处注入 → 7 用例精准变红，还原后 0 残留

任务	状态
P20-T01 指标字典（`MetricCatalog` 36 指标 × 12 字段 + 文档 + 守卫）	✅
P20-T02~T09 User / Review / Recommendation / Match / Chat Started / Matchmaker / Activity / Risk Metrics	✅
P20-T10 Daily Summary（补 days 1~365 边界校验）	✅
P20-T11/T12 Platform Dashboard（统一口径层 `AnalyticsMetricsCalculator`）	✅
P20-T13 Organization Dashboard	✅（受 `analytics.view` + DataScope；`organization_admin` 待组织维度建模）
P20-T14 Analytics 权限（V043 打通 `data_viewer` / `platform_admin`）	✅
`GET /operator/analytics/v11-dashboard` 综合接口	✅

本轮复验修复的真实缺陷（高价值项）：

口径造假：实名人数用 profile_status != 'rejected' 冒充（把"资料还在填"算成已实名）； Chat Started 直接数会话行数（系统通知计入）；Match 不分来源（10 对互选被当 10 对成功引用）； Banner 曝光/点击硬编码 0（被读成"投了没人点"，实为无埋点）。
死代码：活动漏斗全部硬编码 0（不是没数据，是根本没有查询）+ 一行把"用户数"当"活动数"的死代码。
系统性软删缺陷（D12）：BaseEntity.deletedAt 无 @TableLogic、全局无逻辑删除配置 → selectCount 把软删数据全部计入统计且无任何报错。修复 45 处统计调用（2 轮复验，首轮漏扫 5 处次级路径）。
权限授予脱节（Gate ⑩）：data_viewer 角色被定义却从未授权（空壳角色）； platform_admin 因 id >= '20000000-…' 条件漏掉 V1.0 老权限段 → 整个模块除 super_admin 外全员 403。
假绿测试：AnalyticsServiceTest = 5×assertTrue(true)（零断言），已删除并替换为 21 用例真实 DB 集成测试。

跨阶段发现（缺陷本体属 Phase 21，本轮已修 X1~X3）： AccountLifecycleService 注销时把 user_identities 状态域的 'failed' 写入本地资格表 → 违反生产 V017 chk_elig_verify_status → 真实 PG 上 closeAccount 事务回滚、账号注销 100% 不可用； checkCanWithdraw 的资格拦截用 submitted/pending（该表永不可能出现的值）→ 死代码。测试库补齐 chk_elig_type / chk_elig_verify_status 后立即暴露 ActivityPhase14Test 夹具违规。新增 LocalEligibilityStatusVocabularyGuardTest(9)。

Phase 21 — 账户生命周期增量 ✅（KEEP-VERIFY 复验关闭，2026-09-18）

项	复验结论
P21-T01~T05 + checkCanWithdraw（原声明「✅」）	主体实现存在，但复验发现并修复 6 处真实缺陷
Gate：注销后不能登录	❌→✅ `AuthService.checkAccountStatus` 原不拒 `CLOSED` → 已修复
Gate：注销后不能聊天	❌→✅ `notifyActiveMatches` 原是 TODO 桩 → 已实现关闭 Match + 通知对方
Gate：关闭未来服务（活动报名）	❌→✅ `cancelPendingActivityRegistrations` 原是 TODO 桩 → 已实现
Gate：不暴露个人/咨询正文	❌→✅ `anonymizeServiceHistory` 已实现却从未被调用（死代码） → 已接线；身份证脱敏原是 TODO → 已覆盖占位符；并脱敏 `counseling_followups` 正文
死代码矛盾	❌→✅ `closeAccount` 在 blockers 处硬抛异常，使 `cancelXxx` 永远不可达 → 改为信息性日志 + 继续清理
测试保真度	删除 7×`assertTrue(true)` 假绿 → 替换为 11 用例真实 DB 集成测试 + 3 用例登录守卫
跨模块防线（既有）	✅ 推荐引擎 / 匹配资格 / Capability 已拒绝非 `NORMAL`（含 `CLOSED`）
后端全量回归	650 tests / 0 failures（起点 648，净 +2）
报告	`docs/Phase-21-V11-Recovery-Completion-Report-2026-09-18.md`
遗留（2026-09-20 更新）	① 红娘服务进行中拦截：~~原「数据模型无 `matchmaker_services` 表」判定~~（已被实测推翻，表由 V009 创建）→ 已接线清偿：`checkCanWithdraw` 接真实计数（blocker 首次生效）+ `terminateActiveMatchmakerServices` 竞态兜底（不发通知，规避 notifications→users FK），守卫 4 用例；② ~~数据保留"配置+人工审核"删除流程属产品决策未实现~~ 已落地（2026-09-19 产品确认保留期下限 36 个月）：V049 `users.closed_at` + `AccountConfig.dataRetentionMonths` + `DataRetentionService`（人工审核：到期清单 + `purgeExpired` 匿名化清除，`account.retention.purge` 仅授 super_admin，幂等 + 审计），`DataRetentionGuardTest` 5 用例（负向验证摘掉下限判断恰 1 红）；隐私政策 §3.3 / PIA §8 已同步修订；③ ~~隐私设置接口仍为 TODO 桩~~ 已关闭（2026-09-19）：V047 补列 + upsert 修复 + 桩改委托 `PrivacyService` 真实读写，守卫 8 用例

Phase 22 — 部署运维配置扩展（Feature Flag）✅（KEEP-VERIFY 复验关闭，2026-09-18）

项	复验结论
范围	STATUS 遗留区「Phase 22 部署运维配置扩展」= 7 个 V1.1 Feature Flag + `FeatureFlagController` + 默认值（计划文件 Phase 22 实为 Deployment/Ops 基础设施，另属一块任务，未纳入本 Phase）
D-22-A（High）	`updateFlag` 仅支持布尔 flag（反射 `getMethod("set"+cap, boolean.class)`）→ 7 个非布尔 flag 经 API 更新必失败；已改为按字段类型分派 boolean/int/String
D-22-B（Medium）	`body.getOrDefault("value", false)` 缺 value 静默置 false + 非布尔转型崩；已改为缺 value/类型错→400 且不改原值
T01–T05 模块开关	复验发现 `isCounselingEnabled` / `isPremaritalEnabled` / `isContentEnabled` / `isServiceLocationEnabled` / `isLocalEligibilityEnabled`（模块级）全仓无业务调用点 → 死配置（暴露但未 gate）；不静默扩权，留交各模块 Phase 接线
T06 上传策略	实测已在 `LocalEligibilityService`（启用开关 + 数量上限）+ `PhotoService`（大小 + 类型）真强制 ✅
T07 私有存储桶	`counselingAttachmentsPrivate` / `Bucket` 全仓零引用 → 死配置（存储本就走 `object-storage.bucket-private`）；可选增强，遗留
yml 声明夸大	STATUS 称「application.yml 默认配置(15 flag)」——来源表述错误（features 不在基础 `application.yml`），但内容本身属实：`application-dev.yml`（`spring.profiles.active: dev`，默认激活）与 `application-docker.yml`（compose 设 `SPRING_PROFILES_ACTIVE: docker`）均有 `features:` 块且实际生效（硬证据：dev 的 `chat-image-enabled: true` 覆盖了 Java 字段默认 `false`）。原复验「4 份 yml 无 `features:` 块 / 默认值仅来自 Java 字段默认」为误判，已于 2026-09-18 二次修正；功能不受影响
守卫测试	新增 `FeatureFlagControllerTest`（7 用例：21 键全暴露 / 布尔·字符串·整数更新生效 / 未知 flag·缺 value·类型错→400）；负向验证（仅布尔缺陷版）恰 2 用例精准变红，还原全绿
全量回归	657 tests / 0 failures / 0 errors / 3 skipped（起点 650，净 +7）
报告	`docs/Phase-22-V11-Recovery-Completion-Report-2026-09-18.md`
遗留（未静默扩权）	① T01–T05 模块开关死配置（2026-09-19 已移除，见下）；② T07 私有桶死配置（2026-09-19 已移除）；③ PUT 不持久化（2026-09-19 已做成真持久化，见下）；④ 计划 Phase 22 Deployment/Ops 基础设施尚未复验
2026-09-19 追加	T01–T05 五个从未被业务读取的开关 + T07 两项私有桶配置已移除（前提：逐个 grep 论证零业务调用点 + 前端零引用）；`getAllFlags()` 键数 21 → 14
2026-09-19 追加	PUT /feature-flags 已真持久化：V048 新建 `feature_flag_overrides`；`FeatureFlagConfig.reloadFromPersistence()` 挂 `@PostConstruct`（晚于 `@ConfigurationProperties` 绑定，故 DB 覆盖压得住 yml 默认）；新增 `DELETE /{flagName}` 恢复默认；坏值启动 fail-fast。守卫 `FeatureFlagPersistenceGuardTest` 11 例，核心是「另起实例重新加载后改动仍在」（重启等价路径）。负向验证（注入不落库 + 摘启动钩子）恰 5 例变红。已知边界：多实例下其他实例内存值不自动刷新，需各自重启

Phase 20（Analytics数据统计扩展）— 已完成 ✅

Phase 22 — 历史声明块（已作废）

⚠️ 此处原有两块 2026-09-09 期的历史声明（自称「application.yml 默认配置 ✅（15 个 V1.1 flag）／ application-dev、docker.yml 配置 ✅／T01–T05、T07 ✅」），已被 2026-09-18 的 Phase 22 复验整体推翻： ① 原文所称 features: 块确实存在且生效，但不在基础 application.yml，而在 application-dev.yml / application-docker.yml（两 profile 均实际生效）—— 复验初判「4 份 yml 无 features: 块」为误判，已于 2026-09-18 二次修正；② T01–T05 模块开关与 T07 私有桶确实全仓零业务调用点（死配置），此结论成立。 ③ 另发现 AppController#getConfig 返回硬编码 features（第二来源），见 Phase 22 报告 D-22-E。 唯一有效结论见上方「Phase 22 — 部署运维配置扩展（Feature Flag）✅（KEEP-VERIFY 复验关闭，2026-09-18）」。 原文可从 git log --all -- docs/STATUS.md 取回。

Phase 23 — 可信系统测试重建（REFACTOR）⚠️ 部分关闭（KEEP-VERIFY 复验，2026-09-18）

下方「Phase 23 — V1.1专项测试 ✅ 已完成」为历史声明，经实测部分不成立，以本节为准。

项	结论
报告	`docs/Phase-23-V11-Recovery-Completion-Report-2026-09-18.md`
回归	655 tests / 通过 652 / 失败 0 / 错误 0 / 跳过 3（起点 657，净 −2：原 14 个空转用例合并为 12 个）
跳过原因	`ConcurrentTests` ×2（`@EnabledIfEnvironmentVariable(CI=true)`，「本地并发测试跳过」）；`CoreE2ETest` ×1（`@Disabled`「需要完整数据库连接」）—— 均有显式声明，非空壳
D-23-A（Critical）	`V11InvariantsTest` 原 14 个用例全为常量断言：INV-016 断言文章状态常量（跑错域）、INV-017 是自造字面量的重言式（从未调用首页服务）、INV-018/019/020 用无关状态常量冒充权限验证 → 已重写，新增 4 个真实行为守卫（INV-013 脱敏、INV-016 白名单禁外链、INV-017 首页 8 入口顺序、INV-019 内容编辑员零数据）+ `assertBehaviorTestExists` 指针契约
D-23-B（High）	`tests/e2e/` 44 个 `pass` 空壳（4 个文件 100% 为空壳）→ 已移除，改为诚实占位并保留场景清单
D-23-C（High）	pytest E2E 套件整体不可执行：全仓无 `conftest.py`，约 15 个 fixture 不存在；唯一可执行的 `run_v11_tests.py`（16 用例）需活栈
D-23-D（High，遗留）	CI 未串联 E2E（计划明确要求）→ 需先决定 CI 活栈供给方式，未在本轮实施
D-23-E（Medium）	CI `migration` job 注释称「验证 SQL 语法」但只查文件非空 → 改为真实序列校验（命名/非空/版本号唯一/无缺号），已本地实跑通过
新增闸门	`scripts/check-no-empty-tests.py`（AST 扫描，阻断 `pass` 空壳与无条件 `skip`）+ CI `test-shell-guard` job
遗留	① E2E 进入 CI 待基础设施决策；② pytest fixture 体系缺失；③ INV-011 无显式守卫（结构性满足）；④ E2E 场景清单待实现（已保留在占位文件头）
结论	部分关闭：假覆盖已归零，但 UAT 前 Gate 要求的端到端链路仍未真实执行，不宜据此宣布可进入 UAT

Phase 23 — 专项测试（历史声明块，已作废）

⚠️ 本节原自称「✅ 已完成」，已被 2026-09-18 复验推翻：原用例中 44 个为 pass 空壳、 14 个「不变量测试」只断言常量字符串。唯一有效结论见上方「Phase 23 — 可信系统测试重建（REFACTOR） ⚠️ 部分关闭」与「Phase 23B — E2E 测试基建重建 ✅ 已关闭」。

Phase 23B — E2E 测试基建重建（2026-09-18）✅ 已关闭

本轮补齐的是 Phase 23 的两条遗留（D-23-C「E2E 整体不可执行」、D-23-D「CI 未串联 E2E」），与下方 「Phase 24 — UAT增量」是不同工作，不要混为一谈。

交付	说明
`tests/e2e/conftest.py`	fixture 体系：ApiClient、`operator_token(username)`、`new_user`、栈探活
`pytest.ini` / `tests/e2e/requirements.txt`	收集范围与依赖
`tests/e2e/sql/seed_e2e_operators.sql`	运营账号自举（迁移里没有任何 operator 种子，全新库无账号可登录）
CI job `e2e`	起真实栈 → 等就绪 → seed → pytest → 失败阻断 → 清理
8 个 E2E 文件改造	消除 import 期 `KeyError`；替换恒真 / 名不副实的断言

核心设计：栈不可达时 pytest.exit(4)，不是 skip —— skip 会把"未执行"伪装成"通过"。

验证：本机真实活栈 33 passed；后端全量回归见本节末。

本轮暴露并修复的真实生产缺陷（H2 测试库全部零覆盖，只有真 PostgreSQL 才现形）：

编号	真相
D-23B-A	构建产物残留重复迁移版本号 042 → Flyway 报错 → 应用起不来
D-23B-B	非 UUID path 参数 → 500 且泄漏数据库异常
D-23B-C	6 个 E2E 文件 import 期崩溃 → 从未被执行过
D-23B-E	权限 seed 缺口：`super_admin` 仅 18/48 条、`matchmaker` 0 条（matchmaker 部分列为遗留）
D-23B-I	非法枚举参数 `IllegalArgumentException` 未映射 → 500（应 BAD_REQUEST）
D-23B-J	`operator does not exist: uuid = character varying` → JDBC 增加 `stringtype=unspecified`

详见 docs/Phase-23B-V11-E2E-Infrastructure-Completion-Report-2026-09-18.md。

HTTP 语义检修 — 失败响应携带真实 HTTP 状态码（2026-09-18）✅ 已关闭

起因：Phase 23B 收尾时质疑「HTTP 200 + body.code 这套约定，开放第三方还守得住吗」。审计后确认当时就已经是断的，不是未来风险。

发现	说明
105 处 / 30 个 Controller	`return ApiResponse.error(...)` 不抛异常、不带 `@ResponseStatus` → HTTP 恒为 200
前后端契约已断	小程序 `api.js` 的 401/403/429 分支永远走不到；token 过期回 403 → 不触发 `onSessionExpired` → 用户卡死
未认证回 403	`SecurityConfig` 未配 `authenticationEntryPoint`，body 连 `code` 都没有
CORS 默认 `*` + `allowCredentials(true)`	注释却写「默认只允许 localhost」——注释与代码不符
测试覆盖	全量测试仅 4 文件 / 15 处断言触及状态码

修法：一处定义、两处应用、业务代码零改动 —— 响应码枚举新增 httpStatus（单一真相源）、异常处理器从枚举读状态、新增 ResponseBodyAdvice 覆盖全部直返路径。

验证：E2E 37 passed（+4 契约用例）；后端回归 662 / 0 / 0 / 3；活栈实测 404 / 400 / 401 正确。回归首轮 3 处失败经判定均为测试断言了旧的错误行为，改断言而非改回实现。

遗留（第三方开放，属范围扩张，需产品决策）：第三方凭据机制、限流是否真实生效、 OpenAPI 对外发布、调用审计与配额、分页幂等覆盖、脱敏边界。

同日续做：身份类型与路径规则收敛

发现	说明
运营身份可打进用户端	兜底规则是 `authenticated()`，运营 token 完全满足；而 `@AuthenticationPrincipal UserPrincipal` 遇 `OperatorPrincipal` 类型不匹配返回 null（Spring 默认 `errorOnInvalidType=false`），全仓 244 处使用、仅 48 处做 null 检查 → 其余 NPE → 500
PathPattern 陷阱	嵌套运营端点（`/counseling/services/operator/` 等）不能用 `//operator/` 覆盖——`` 只允许在末尾，写了会抛 `PatternParseException` 且整个过滤器链 500（实测 E2E 由 37 passed 直落 33 failed）
修法	兜底收紧为 `hasRole("USER")`（196 处潜在 NPE 在认证层消解，不补 null 检查）+ 显式枚举 9 个运营前缀 + 新增 `SecurityPathCoverageTest` 机械守卫（防将来新增端点漏配）

验证：E2E 40 passed（+3 身份隔离用例）；后端回归 664 / 0 / 0 / 3。守卫经负向验证（摘掉 /content/operator/** → 恰好 1 用例变红并列出受影响的 6 个端点）。

详见 docs/HTTP语义检修报告-2026-09-18.md。

幂等键检修 — `Idempotency-Key` 从「声明」到「兑现」（2026-09-18）✅ 已关闭

起因：HTTP 语义检修收尾时我写下「Idempotency-Key 已支持」，随后核对推翻了自己的结论—— 后端当时零处读取该头。

发现	说明
声明与实现彻底失联	规范第八章要求 7 类端点支持幂等键；前端 25 处调用点（8 service + 2 TS 页面）发送该头，后端 0 处读取
前端那一侧也是坏的	原写法 `idempotencyKey: \`like:${Date.now()}``——`Date.now()` 每次调用都变，就算后端实现了也永远命中不了。互补的两半，谁也不起作用
唯一真幂等的端点走的不是 header	只有 counseling 申请靠 body 字段 `idempotencyKey`（V039 `uk_counseling_idem`）
两道兜底双双落 500	`DuplicateKeyException`（并发重复提交的最后防线）与 30 处 `IllegalStateException`（业务状态冲突）均无映射 → 500；而 500 语义是"可重试"，调用方于是重试，制造更多重复
一个错误的安全假设	上轮 `D-23B-J` 判定 `stringtype=unspecified` 是"一处解决全局"。本轮 V045 的 `actor_id VARCHAR` 在同样开着该参数的 docker profile 下依然抛 `character varying = uuid` → 该参数覆盖不到经类型处理器显式指定类型的参数。真正的不变量是"列类型必须是 uuid"

修法：一处实现、零业务代码改动、逐端点声明 —— V045 建表（idempotency_records + 唯一索引 uk_idempotency_scope）、V046 修正列类型、IdempotencyInterceptor（先占位后执行／重放／409）、 IdempotencyResponseCacheFilter（缓存响应体供逐字节重放）、@Idempotent 声明 30 处、异常处理器两处新映射（IllegalStateException / DuplicateKeyException → 409，且刻意不映射其父类 DataIntegrityViolationException，因后者含 CHECK 违反应由 500 暴露）。

四个关键设计：先占位后执行（靠唯一索引让并发只有一个赢家，不用 SELECT-then-INSERT）、 失败释放占位（否则一次瞬时故障把用户永久卡在 409）、孤儿占位可接管（进程中断不留死键）、 作用域含 actor_id（同键不同用户互不干扰）。

前端键改为"一次未成功的逻辑操作内复用同一把键，成功才释放"，25 处 Date.now() 写法全部替换（残留 0）。

验证：E2E 49 passed（含 tests/e2e/idempotency_test.py 7 用例：重放逐字节相同、同键只产生一条记录、作用域隔离、5 线程并发同键业务恰好落库一次、无键重复 Like 不得 500）；后端全量 669 / 0 / 0 / 3（首轮 664/1 failure 为有意设计的迁移基线守卫，已按流程抬基线至 46）；小程序 tsc --noEmit EXIT=0；UI 契约门控 14/14。

列类型不变量全库扫描：所有 *_id VARCHAR 列中，actor_id 是唯一违规（已修）； client_message_id / provider_request_id 为外部 id、resource_id / source_id 在 Java 侧零处作查询条件 （已 grep 确认）→ 不存在第二处同类隐患。

新增机械守卫 IdempotencyDeclarationGuardTest（2 用例，经注入变异负向验证，各自精确报出行号）：规范第八章 7 类端点族 + Phase 16 互选链路必须声明 @Idempotent；@Idempotent 后必须紧跟 @PostMapping。同时修正一处假绿：GlobalExceptionHandlerTest 原 3 条断言只测 DTO、一次都没进过处理器。

同轮清掉三处同形状问题（均属"一处声明、另一处不兑现"的复发）：

补 CheckinController 手工签到的 @Idempotent —— 第 146 章"扫码两次"场景的同类漏标；
CI 上的 E2E 从未真正通过过（本轮活栈复跑暴露）：迁移里没有任何 operator 种子、 DemoDataSeeder 也不建运营账号，conftest.admin_token 却写死 username="admin" —— 那是某台开发机手工创建的遗留账号，本机有它所以本地一直绿，CI 全新库没有 → fixture 必然 401。已改用 seed 创建的 e2e_admin（绑 super_admin），并新增 tests/e2e/fixture_account_guard_test.py 机械拦住"fixture 只准用 seed 账号"（含"解析失败即失败"断言，防守卫自身静默失效）；
POST /activities/{id}/interests 契约漂移：API_INVENTORY 记载该端点、前端按此实现，但后端从未实现（Phase 16 已把表达意向合并进 /activities/{id}/feedback 的 interestTargetUserIds） → 调用必然 404。已更正 API_INVENTORY 并按真实端点重列，删除前端死代码链（activityService.submitInterests + activityStore.submitInterests，全仓确认无页面调用方），各留注释说明删除原因与恢复条件。若产品确认需要独立端点，应先定义语义并补后端实现。

详见 docs/幂等键检修报告-2026-09-18.md。

Phase 24 — UAT增量 ✅ 已就绪（测试数据支持）

任务	状态
P24-T01 Service Station Operator UAT	✅ 测试数据已就位（stationop账号）
P24-T02 Counselor UAT	✅ 测试数据已就位（counselor01账号）
P24-T03 Counseling Manager UAT	✅ 角色权限已配置
P24-T04 Content Editor UAT	✅ 角色权限已配置
P24-T05 服务站扫码→预约→到场	✅ API链路完整
P24-T06 咨询申请→服务完成	✅ API链路完整
P24-T07 婚前辅导申请	✅ Miniapp页面U58/U59完整
P24-T08 活动双方互选→双方确认→Chat	✅ API+Miniapp完整

备注：UAT需要人工操作验证，后端API和数据模型已全部就绪。

⚠️ 本行原称「Phase 23（V1.1专项测试）— 已完成」，已被 2026-09-18 复验推翻：Phase 23 实为部分关闭（假覆盖已清除、E2E 入 CI 待基础设施决策），唯一有效结论见上方「Phase 23 — 可信系统测试重建（REFACTOR）」节。

Phase 25 — RC内容检查 ✅ 可执行

任务	状态
P25-T01~T09 真实素材填充	⏳ 待运营提供内容
Banner真实素材	⏳ 等待运营
服务站真实地址/开放时间	✅ 已初始化万善公园站
咨询服务介绍	✅ API已就绪
婚前辅导介绍	✅ API已就绪
婚恋反诈首批内容	⏳ 待运营提供
婚恋课堂首批内容	⏳ 待运营提供
关于善缘丹阳	⏳ 待运营提供
主办/执行信息	⏳ 待运营提供

Phase 26 — Production初始化 ✅ 已完成

任务	状态
P26-T01 Seed Content Categories	✅ (V027)
P26-T02 Seed Activity Types	✅ (CHECK约束已定义)
P26-T03 Seed Service Types	✅ (CHECK约束已定义)
P26-T04 创建万善公园服务站	✅ (V027)
P26-T05 初始化Banner	✅ (V027)
P26-T06 初始化Feature Flags	⚠️ 来源纠错 + 部分成立（2026-09-18 二次修正）：`features:` 块实际存在于 `application-dev.yml` / `application-docker.yml`（不在基础 `application.yml`）且实际生效（dev 的 `chat-image-enabled: true` 覆盖 Java 默认 `false`）—— 原「4 份 yml 无 features 块」为误判；但 10 个模块级 flag（T01–T05 及同类）全仓零业务调用点，运维无法经开关关闭对应模块（死配置）
P26-T07 初始化新增Roles/Permissions	✅ (V015已覆盖)
P26-T08~T13 Smoke tests	⏳ 上线前手动验证

V027 生产种子数据迁移已创建，包含：

4个内容分类（婚恋课堂/反诈/婚前辅导/婚俗新风）
万善公园服务站基础数据
3条首页Banner

Phase 24（UAT增量）— 已就绪 ✅

整体进度总结

Phase范围	状态
Phase 01~12 (V1.0基线)	✅ 已完成
Phase 13~22 (V1.1核心增量)	✅ 已完成
Phase 23 (V1.1专项测试)	⚠️ 部分关闭（2026-09-18）：假覆盖已清除 + 4 个真实守卫；E2E 入 CI 待决策
Phase 24~26 (UAT/RC/Production)	⏳ 运营/上线阶段

Phase 24~26 — 明细见上方（本段为重复摘要，已收敛）

Phase 24 / 25 / 26 的逐条任务表见上方「当前 Phase」中的同名小节；本段原为它们的简化重复版，已收敛以免同一事实出现两套口径。

Admin Web V1.1 模块扩展 ✅ 已完成

模块	文件	说明
Banner管理	BannerManagementView.vue	CRUD + 上架/下架
内容管理	ContentManagementView.vue	分类+文章CRUD + 发布/下架
善缘服务站	ServiceStationView.vue	站点信息编辑
服务预约	ServiceAppointmentView.vue	确认/完成/取消
专项项目	ServiceProgramView.vue	CRUD + 成员审批
婚恋咨询	CounselingView.vue	分配/排期/跟进/完成
转介记录	ReferralManagementView.vue	转介历史查询
路由扩展	router/index.ts	7个新菜单+路由

V1.1 整体进度总结

类别	状态
数据库迁移 (V001~V027)	✅ 27个文件
后端 Java API	✅ 100% 完成
Miniapp 页面 (U55~U61)	✅ 7个新页面
E2E 测试 (12个文件)	✅ 80+用例
Invariant 测试 (INV-011~020)	✅ 10个用例
Feature Flag 配置	✅ 15个V1.1开关
Admin Web V1.1 模块	✅ 7个新页面
Admin Web 前端开发	⏳ 需完善样式和联调

V1.1 核心功能 100% 完成，可进入 UAT 验收和上线准备阶段

已知限制

限制	说明
人脸核验	Feature Flag 预留，Provider 未确认
本地资格佐证触发规则	待运营确认
微信公众号审核	需人工操作
SSL证书	需人工申请
有效交友匹配报送口径	待运营确认

版本基线: 1.1.0-dev（2026-09-08）— V1.0 核心 100% 就绪，V1.1 增量开发中

V1.1 本地部署完成（2026-09-09，历史记录）

⚠️ 历史记录边界：本节为 2026-09-09 的部署时点记录，其中的测试声明（11/11、25/25、16/16） 已在后续重新审查中被推翻，不作为验收证据。当前有效状态见文首「当前有效结论」。本区块在原文件中重复出现三次（内容高度雷同），2026-09-18 文档治理合并为一处。

修复的关键问题

CounselingServiceApp 通知 FK 约束 — operator 用户不在 users 表，改为检查后再发送通知
HomeController 路径重复 — @RequestMapping("/api/v1/home") → "/home"
LocalEligibilityController 路径重复 — 同上修复
数据库 updated_at 列缺失 — 为 18 个 V1.1 表补充 ALTER COLUMN
前端 — CounselingView / ContentManagementView 截断、路由缺失、侧边栏菜单缺失

为什么这些声明被推翻（保留为治理证据）

E2E 的「16/16」记录不可复现，测试文件存在大量空 pass —— 这是 Phase 23「可信系统测试重建」的直接起因。
API 人工测试未证明 Permission、DataScope 和业务闭环，不能作为上线依据。
「25/25 PASS」「11/11 PASS」均为当时自报，未附可复现命令与失败处理。

运营阶段遗留（至今不变）

Phase 24: UAT — 需真实用户参与并确认启动
Phase 25: RC 内容检查 — 需运营团队填充真实内容
Phase 26: Production Smoke Tests — 13 项手动验证

2026-10-14：13 位公开编号统一前置盘点

用户确认择偶条件“下一步”在微信开发者工具重新编译后目视复验通过。
全平台编号 Task 1：覆盖清单与静态检查工具已新增；7 项工具自检 PASS，114 个模板发现 31 个待审查位置，展示门禁仍 FAIL（尚未实施字段与页面修复）。
预约编号前缀 YY 尚待确认；转介存在预约/报名及非持久化 record 两条路径，后续需逐一覆盖。当前未修改数据库或重启服务。

2026-10-14 全平台公开编号验收补充

V060 已在演示 PostgreSQL 成功执行，Flyway 当前版本 060；迁移前备份保留在 .mimosa/before-public-id-20261014.dump。
演示库检查：404 个用户中 12 个已实名用户有 YH 编号，12 个运营人员均有唯一 HN/GL 编号，活动编号全部生成；未实名用户按规则允许暂空。
修复 PublicIdMapper 查询 text = uuid 类型错误，重建后端并通过登录、用户、运营人员、活动、红娘服务接口验证；匿名管理接口返回 401。
Web 类型检查、构建、小程序类型检查、公开编号静态守卫和小程序行为测试通过；浏览器 Playwright 因本机缺少 Chromium 未执行。

2026-10-14 后端全量测试与仓库网络复验

用户已确认微信真机验收通过；本次未重复人工真机操作。
容器默认 DNS 出现 HTTPS 解析超时；仅为测试容器指定 --dns 223.5.5.5 --dns 114.114.114.114 后，使用现有 backend/maven-settings.xml 正常从阿里云下载依赖，未降低 TLS 校验、未修改系统或 Docker 全局网络设置。
首次仅挂载 backend，导致 Surefire 的 ${project.basedir}/.. 工作目录缺少仓库源码。修正为挂载整个仓库后重新执行完整套件；首次失败结果不作为有效验收结果。
最新命令（PowerShell）：

docker run --rm --dns 223.5.5.5 --dns 114.114.114.114 `
  -v 'E:\develop\公益婚恋服务平台:/workspace' `
  -v 'E:\develop\公益婚恋服务平台\backend\maven-settings.xml:/tmp/settings.xml:ro' `
  -w /workspace/backend maven:3.9-eclipse-temurin-21 `
  mvn -s /tmp/settings.xml -B test

结果：BUILD SUCCESS，退出码 0；916 项测试，失败 0、错误 0、跳过 3，即实际执行 913 项。Surefire XML 汇总与 Maven 日志一致。
证据：.mimosa/public-id-full-mvn-test.log、backend/target/surefire-reports/TEST-*.xml。
跳过：ConcurrentTests.testSimultaneousLikeRaceCondition、testActivityCapacityRace（CI 条件未启用）；CoreE2ETest.fullFlowRegistrationToSuccess（既有 @Disabled）。前两项仅模拟线程/计数，后一项为占位断言，因此不能据此声称真实数据库并发或完整注册到牵手 E2E 已验证。
注意：通过的套件中仍有通知夹具 u-notif-guard 的 H2 数据转换告警；本轮不改变业务代码或已有测试断言。测试成功不等于所有异步通知均成功，也不代表生产验收完成。

2026-10-14 前端全量校验补充

管理端 pnpm type-check：通过。
管理端 pnpm build：通过；Vite 仍提示 url(var(--v...)) 的 CSS 压缩警告和大 chunk 提示，不影响构建退出码。
小程序 npm run type-check（在 miniapp 目录执行）：通过。
小程序 WXML/WXSS 真编译预检：90 个 WXML、92 个 WXSS，失败 0。
UI 契约门禁：24/24 通过。
本轮修正了 1 个用户可见英文占位符（改为中文日期示例），同步更新了新增红娘页面后的 67 页断言、品牌名称断言和变量化 nginx 代理断言；管理端顶部装饰样式补齐设计 token 与最小字号。

2026-10-15 Task 3：通知测试夹具告警治理

修复 NotificationTemplateTypeGuardTest 与 NotificationPhase11IntegrationTest 的测试用户夹具：由非 UUID 字符串改为合法 UUID，与生产 users.id 类型保持一致。
仅修改测试夹具，未修改生产通知逻辑、数据库结构或接口契约。
通知专项测试：NotificationTemplateTypeGuardTest 共 2 项，失败 0、错误 0，BUILD SUCCESS。
后端全量回归：916 项，失败 0、错误 0、跳过 3（实际执行 913 项），BUILD SUCCESS。
对最新全量日志扫描，未再出现 Data conversion error converting、u-notif-* 或 Async notification failed 告警。
证据：.mimosa/notification-fixture-full-mvn-test.log、backend/target/surefire-reports/TEST-*.xml。

2026-10-15 Task 1：真实 PostgreSQL 并发验证（部分完成）

已启动并复用现有 danyang-match-postgres 容器，未删除或重置数据。
执行 node tests/public-id-postgres.cjs，真实 PostgreSQL 完成 20 路并发公开编号分配、男女奇偶序号、999 边界、非法参数和事务回滚校验，输出 PASS。
证据：.mimosa/postgres-concurrency-test.log。
当前 backend/src/test/java/com/danyang/match/platform/concurrent.ConcurrentTests.java 仍是内存计数模拟，且 Like/活动容量两个用例依赖 CI=true 才运行；本轮未将其伪装成真实 PostgreSQL 证据，故 Task 1 的 Like/活动容量门禁仍为 NOT_VERIFIED。
下一步需建立隔离 PostgreSQL 测试数据并把这两个用例接入真实 Service/Mapper 后再执行，不修改演示数据。

2026-10-15 发布准备 Task 1：基线与环境确认

完整演示栈已恢复运行：PostgreSQL、Redis、SeaweedFS、Backend、Admin Web、Nginx 均为 healthy。
健康检查：GET http://localhost:8085/api/v1/health/live 返回 200；GET http://localhost:6688/api/v1/health/live 返回 200；GET http://localhost:6688/admin/ 返回 200。
Flyway 当前版本：V060。
演示数据库已备份：.mimosa/release-baseline-20261015-083145.dump。
Compose 配置解析通过；环境变量仅检查键名，未写入敏感值。
当前工作区存在大量既有未提交改动，本次未清理、回滚或覆盖。
公开编号 Web 实时脚本因要求通过环境变量注入演示账号密码而停止，未写入账号或 Token。

2026-10-15 发布准备执行补充

CI=true mvn -Dtest=ConcurrentTests test：7/7 通过，但用例仍为 AtomicInteger/常量模拟，不能作为真实 PostgreSQL Like/活动容量证据。
小程序 WXML/WXSS 编译预检：92 个 WXSS、90 个 WXML，失败 0。
管理端工作台行为契约：通过，覆盖审核计数回写、红娘待办和跟进刷新。
public-id-web-live.cjs 尚未执行：脚本要求通过环境变量提供演示运营账号密码；本轮未写入或猜测凭据。

2026-10-15 发布准备 Edge 冒烟

使用当前进程环境变量注入演示账号执行 tests/public-id-web-live.cjs，未写入账号密码或 Token。
Edge 启动正常，但登录未通过：后端查询 operators.username = user 返回 0 条，页面停留在登录页，未进入工作台。
当前数据库存在的运营用户名已核对，但未输出密码；本轮未擅自创建账号或修改现有账号密码。
发布门禁：Edge 管理端全流程 NOT_VERIFIED，需要提供当前数据库有效运营账号，或明确授权创建/重置演示账号。
证据日志：.mimosa/release-smoke-20261015.log。

2026-10-15 发布准备 Edge 实时验收

使用当前进程环境变量注入运营账号 admin，执行 tests/public-id-web-live.cjs，凭据未写入文件或日志。
结果：PASS；10 类真实接口均返回 200，检查 55 个公开编号字段，10 个页面/区域通过，匿名访问返回 401，页面运行错误 0。
截图与结果：.mimosa/public-id-page-evidence/，包括红娘服务和联系授权审批 1366/1920 视图。
管理端 Edge 实时发布冒烟门禁：PASS。
完整 E2E 尚未执行：现有 pytest fixture 要求 e2e_admin 账号密码，当前仅确认 admin 账号可用。

2026-10-15 发布准备活栈 E2E

已授权将 admin 纳入本机 E2E：tests/e2e/conftest.py 新增 E2E_OPERATOR_USERNAME 环境变量，默认仍为 e2e_admin，不影响 CI seed 账号。
在隔离 Python 测试容器执行活栈 E2E，使用 admin + 当前授权密码。
结果：43 passed，21 failed，8 errors。失败/错误主要来自 e2e_station、e2e_counselor、e2e_matchmaker、e2e_content 角色账号密码不匹配；连续错误登录触发部分账号临时锁定。
该结果不能作为完整 E2E 通过证据，也不能直接归因于业务代码；需要各角色测试账号的有效密码或一次性测试账号初始化方案。
证据：.mimosa/core-e2e-postgres-test.log。

2026-10-15 E2E 测试账号初始化与镜像重建

已备份演示数据库：.mimosa/before-e2e-password-reset-20261015-085035.dump。
已按授权为 6 个 E2E 角色账号设置统一初始密码：E2e@Danyang2026!；未修改角色和权限。账号：e2e_admin、e2e_platform、e2e_counselor、e2e_station、e2e_matchmaker、e2e_content。
tests/e2e/conftest.py 支持 E2E_OPERATOR_USERNAME 与 E2E_ADMIN_PASSWORD，CI 默认账号不变，本机可使用 admin。
后端镜像已按当前源码重建成功；健康检查通过，未认证通知接口返回 401。
活栈 E2E 最新结果：55 passed；剩余 8 errors 为测试容器缺少 Docker CLI，另有活动互选测试依赖容器内 docker exec，不能计为完整 E2E 通过。
证据：.mimosa/core-e2e-postgres-test.log。

101 KiB Raw Permalink Blame History Unescape Escape

项目状态跟踪 — STATUS.md