admin/danyang-match
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

fix(appeal): close Phase 18 KEEP-VERIFY — 8 defects (zero-coverage appeals table + 6 fake-green tests; operator-notification FK crash; appealType CHECK; escalated dead-end; processAppeal race; soft-delete filters; hardcoded resolved; evidence contract); add AppealPhase18IntegrationTest (15); full regression 494 green

Browse Source
This commit is contained in:
WorkBuddy
2026-09-17 21:07:25 +08:00
parent 307c9efb36
commit 3f60611a74
13 changed files with 661 additions and 151 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/JIRA_BACKLOG.md
+19 -9
View File
@@ -19,7 +19,10 @@
>
> **2026-09-17 Phase 17 复验关闭：** EPIC-P17-V11 已完成。复验发现风控/举报整条真实 DB 路径因测试库缺 `reports`/`risk_events`/`risk_actions` 三表而**零覆盖**，`ReportServiceTest` 全是 `assertTrue(true)` 假绿；且敏感访问（查看他人风险画像/举报）此前**无审计**（违反 AGENTS.md #8 默认拒绝 + 查看需审计）；另修复审计缺 `ip`/`userAgent`、`findByUserId` 未过滤软删、人工标记无审计，以及 `javax`→`jakarta` 隐藏编译缺陷与 `risk_events` 漏 `updated_at` 列。共修复 **6 处真实缺陷**，补齐三表并新增 `ReportAndRiskPhase17IntegrationTest`（7 例），负向验证证明守卫有牙。全量回归 **488 tests 全绿**。
> 证据：`docs/Phase-17-V11-Recovery-Completion-Report-2026-09-17.md`。
> **Phase 18 需用户确认后启动。**
>
> **2026-09-17 Phase 18 复验关闭：** EPIC-P18-V11 已完成。复验发现申诉整条真实 DB 路径因测试库缺 `appeals` 表而**零覆盖**，`AppealServiceTest` 9 例中 6 例是 `assertTrue(true)` 假绿（覆盖的恰是 Gate 四条不变量）；且 `escalateAppeal` 向 `operatorId` 发用户通知会撞 `notifications.user_id → users(id)` FK（operators 与 users 不同表）→ PG 上升级 100% 失败；`appealType` 未校验生产 `chk_appeal_type` 白名单。另修复 escalated 死胡同、`processAppeal` 先读后写并发竞态、三处查询漏软删过滤、硬编码 `resolved`、证据字段契约。共修复 **8 处真实缺陷**（含 1 处必崩级测试盲区、2 处「只在 PG 上炸」），补 `appeals` 表并新增 `AppealPhase18IntegrationTest`（15 例）、删除假绿 9 例，负向验证证明 Gate 守卫有牙。全量回归 **494 tests 全绿**；admin-web `vue-tsc` EXITCODE=0。
> 证据：`docs/Phase-18-V11-Recovery-Completion-Report-2026-09-17.md`。
> **Phase 19 需用户确认后启动。**
> **2026-09-16 状态校正：** Phase 07 UI 已按 2026-09-13 规格重新实现，**首批 11 页于 2026-09-16 通过用户验收（结论：基本达标）**，本文件此前"视觉否决/REOPENED"口径随之关闭。
>
@@ -141,6 +144,7 @@
| Phase 15 活动报名审核签到复验 | 已完成（2026-09-17） | 见 `Phase-15-V11-Recovery-Completion-Report-2026-09-17.md`；修复 **16 处缺陷**（**D1 签到码一生成即作废**：`generateCheckinToken` 把 token 写 `"used"` 而扫码端见 `"used"` 即拒 → 扫码 100% 失败；**D9 取消/拒绝后永远无法再报名**：撞生产 `UNIQUE(activity_id,user_id)`，测试库缺该约束故零覆盖 → 改复用记录；D2 重复签到竞态、D3 签到无数据范围、D4 手工签到无校验、D5 统计 NPE+语义错、D6 非法 token 500、D7 签名非恒定时间比较、D10 后台审核列表无 pending、D11 报名窗口不生效、D12 取消无审计、D13 审核/取消非原子、D14 容量分组不参与扣减）+ **2 处前端契约缺陷**（admin-web 无签到工作台、小程序无取消报名入口）；新增 V040 `activity_staff_assignments` 落实 INV-020 活动数据范围；**3 处测试保真度缺陷**（测试库缺 UNIQUE+2 CHECK、3 条 `assertTrue(true)` 假绿、表未入必选集合）；新增 `ActivityPhase15Test`（21），`CheckinServiceTest` 假绿改真实守卫（5），约束守卫 +2，迁移基线 39→40；一轮负向验证 3 处注入 → 8 条用例精准变红并还原；admin-web `vue-tsc` 0 error + `vite build` 通过；后端 **474 tests 全绿**；**Phase 16 尚未获准** |
| Phase 16 活动互选二阶段同意复验 | 已完成（2026-09-17） | 见 `Phase-16-V11-Recovery-Completion-Report-2026-09-17.md`；修复 **7 处缺陷 + 1 处隐藏编译缺陷 + 1 处测试保真度缺陷**（**D1 双确认后根本不建 Match/会话（Gate 缺陷·INV-014/015）**、**D3 Phase 15 提交态引用未定义 `reopenEpisode` 致整个模块不编译（"474 绿"为假象）**、D4 INV-006 单向意向泄露、D5 复用/新建 Match 后缺会话）；统一双实现到 `RelationshipService.confirmActivityInterest`；`MatchMapper` 补 `reopenEpisode`；测试库补 `activity_mutual_connection_consents` 表并移入必选集合，`MigrationValidationTest` 基线 40→41；新建 `ActivityMutualConsentServiceTest`（7 用例）；`ChatPhase09IntegrationTest:344` 断言对齐 AGENTS.md #20 复用语义；新增 V041 `expires_at`+`match_id`；负向验证 2 用例精准变红并还原；后端 **481 tests 全绿**；**Phase 17 尚未获准** |
| Phase 17 举报与风控复验 | 已完成（2026-09-17） | 见 `Phase-17-V11-Recovery-Completion-Report-2026-09-17.md`；修复 **6 处真实缺陷**（**D1（Critical，必崩级盲区）测试库缺 `reports`/`risk_events`/`risk_actions` 三表 → 风控/举报真实 DB 路径零覆盖，`ReportServiceTest` 全 `assertTrue(true)` 假绿**；**D3（High）敏感访问（查看他人风险画像/举报）无审计（违反 AGENTS.md #8）**；D4 审计缺 `ip`/`userAgent`；D5 `findByUserId` 未过滤软删；D2 人工标记无审计；**D6 `javax`→`jakarta` 隐藏编译缺陷 + `risk_events` 漏 `updated_at` 列**）；补齐三表并移出白名单入 `REQUIRED_IN_TEST_SCHEMA`；新增 `AuditLogService.recordSensitiveAccess` 并接线三端点；新增 `ReportAndRiskPhase17IntegrationTest`（7 用例）；负向验证（注释 getReportDetail 审计 → D3 守卫精准变红并还原）；后端 **488 tests 全绿**；**Phase 18 尚未获准** |
| Phase 18 申诉复验 | 已完成（2026-09-17） | 见 `Phase-18-V11-Recovery-Completion-Report-2026-09-17.md`；修复 **8 处真实缺陷**（**D1（Critical，必崩级盲区）测试库缺 `appeals` 表 + `AppealServiceTest` 9 例中 6 例 `assertTrue(true)` 假绿 → 申诉真实 DB 路径零覆盖**；**D2（High，只在 PG 上炸）`escalateAppeal` 向 `operatorId` 发用户通知撞 `notifications.user_id → users(id)` FK → 升级事务整体回滚**；**D3（High，只在 PG 上炸）`appealType` 未校验生产 `chk_appeal_type` 白名单**；D4 escalated 死胡同（前后端均无法再决策）；D5 `processAppeal` 先读后写并发竞态；D6 三处查询漏 `deleted_at` 过滤；D7 硬编码 `resolved`；D8 证据字段契约 `evidenceFileIds`）；补 `appeals` 表并移出白名单入 `REQUIRED_IN_TEST_SCHEMA`；新增原子认领 `markReviewingIfProcessable`；新增 `AppealPhase18IntegrationTest`（15 用例），删除假绿 `AppealServiceTest`（9 用例）；负向验证（误伤其他处置 → Gate 用例精准变红并还原）；后端 **494 tests 全绿**；admin-web `vue-tsc` EXITCODE=0；**Phase 19 尚未获准** |
| UI-CLEANUP-20260913 | 已完成 | 废弃 UI 代码、冲突规范、旧计划和无效验收证据已清理；`ui-document-baseline-contracts` 锁定唯一视觉入口 |
| UI-ADMIN-20260913 | 已完成（待桌面端目视复验） | 管理端全局框架与工作台已按规格交付；18 modules + 22 routes，vue-tsc 与 vite build 全绿 |
| UI-MINIAPP-20260913 | 已完成 | 小程序 11 个核心页面已重构；11/11 页 TS-only，2026-09-16 通过用户验收 |
@@ -180,7 +184,7 @@
| EPIC-P15-V11 | P15 | 活动签到回归测试 | P1 |
| EPIC-P16-V11 | P16 | 活动互选二阶段同意重构 | P0 | ✅
| EPIC-P17-V11 | P17 | 公益服务风险来源扩展 | P0 | ✅
| EPIC-P18-V11 | P18 | 申诉保持 | P1 |
| EPIC-P18-V11 | P18 | 申诉保持 | P1 | ✅
| EPIC-P19-V11 | P19 | 善缘丹阳综合运营后台 | P1 |
| EPIC-P20-V11 | P20 | 公益项目数据统计扩展 | P1 |
| EPIC-P21-V11 | P21 | 账户生命周期增量 | P1 |
@@ -507,16 +511,22 @@
- 证据：`docs/Phase-17-V11-Recovery-Completion-Report-2026-09-17.md`
---
## EPIC-P18-V11: 申诉保持 ✅ 已验证（V1.0基础保持不变）
## EPIC-P18-V11: 申诉保持 ✅ 已完成（2026-09-17 KEEP-VERIFY 复验关闭）
### Verification
- V013 appeals 表结构完整（ban_appeal / suspend_appeal）
- AppealService: FeatureFlag 控制 + 幂等性 + 可申诉限制（仅 ban/suspend）
### Verification（2026-09-17 复验后校正）
- V013 `appeals` 生产 DDL 完整（`chk_appeal_status` / `chk_appeal_type`）；但**测试库此前完全缺该表**（只在 parity 可选白名单里 = 无人测），已补入 `schema-h2.sql` 并移入 `REQUIRED_IN_TEST_SCHEMA`。
- AppealService: FeatureFlag 控制 + 幂等性 + 可申诉限制（仅 ban/suspend）——复验后补 `appealType` 白名单校验与处置类型一致性。
- AppealController: 用户端 account-status / submit / my
- AppealOperatorController: 后台端 pending / detail / process / stats
- Miniapp: appeal 页面已注册
- 申诉通过 → 自动解除对应 risk_action（status→revoked）
- 申诉被拒 → 维持原处置
- Miniapp: appeal 页面已注册（证据字段名 `evidenceFileIds` 已与后端 DTO 对齐）
- 申诉通过 → 自动解除**对应** risk_action（`status → resolved`，只解除目标处置；其他仍有效处置不受影响）。
⚠️ 旧注"status→revoked"**不实**：`Constants.RISK_ACTION_STATUS_REVOKED` 从无使用点，且不在生产 `chk_risk_action_status`（active/resolved/expired）白名单内；实现使用 `resolved`。
- 申诉被拒 → 维持原处置（`risk_action` 不变更）
### 2026-09-17 KEEP-VERIFY 复验结论
- 修复 **8 处真实缺陷**：D1 零覆盖（缺 `appeals` 表 + 6 处 `assertTrue(true)` 假绿）；**D2 `escalateAppeal` 向 operator 发用户通知撞 `notifications.user_id → users(id)` FK → PG 上升级 100% 失败**；**D3 `appealType` 未校验 `chk_appeal_type`**；D4 escalated 死胡同；D5 `processAppeal` 先读后写并发竞态；D6 三处查询漏软删过滤；D7 硬编码 `resolved`；D8 证据字段契约。
- 新增 `AppealPhase18IntegrationTest`（15 例），删除假绿 `AppealServiceTest`（9 例）；负向验证证明 Gate 守卫有牙；后端 **494 tests 全绿**；admin-web `vue-tsc` EXITCODE=0。
- 证据：`docs/Phase-18-V11-Recovery-Completion-Report-2026-09-17.md`
### 新增文件
- V025__extend_risk_sources.sql — 扩展 risk_events.event_type CHECK + risk_actions.action_type
docs/Phase-18-V11-Recovery-Completion-Report-2026-09-17.md
+102
View File
@@ -0,0 +1,102 @@
# Phase 18 — 申诉 KEEP-VERIFY 复验完成报告
**日期**：2026-09-17
**范围**：申诉（appeal 模块、Miniapp appeal 页面、后台 AppealCenter）
**纪律**：KEEP-VERIFY。历史 ✅ 不可信；测试覆盖 ≠ 运行时路径覆盖；逐条核对运行时路径与生产约束；发现真实缺陷即修；补测试保真度；守卫必须解析真实 DDL；离线容器真实编译+执行；每阶段出报告后停止等确认。
---
## 一、结论
**Gate 达成，复验关闭。**
| Gate | 结果 |
|---|---|
| 申诉通过只解除目标处置 | ✅ `approveAppeal` 只把 `relatedActionId` 指向的处置置 `resolved`；用户其他仍有效的处置保持 `active`（负向验证已证守卫有牙） |
| 拒绝后原处置保持有效 | ✅ `rejectAppeal` 不变更 `risk_action`，原处置维持 `active`，账号仍受限 |
| 首发由 Feature Flag 控制 | ✅ `features.appeal-enabled`（dev/docker 均 `false`）；关闭时 `submitAppeal` 抛"申诉功能暂未开放" |
**本轮修复真实缺陷 8 处（含 1 处必崩级测试盲区、2 处「只在 PG 上炸」的生产故障）**，新增集成测试 15 例，删除假绿测试 9 例。
- 全量回归：**494 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS**（约 4.4 分）
- 基线 488 → 494，**净 +6**（−9 假绿 `AppealServiceTest`，+15 `AppealPhase18IntegrationTest`）
- 负向验证：临时让 `approveAppeal` 误伤用户其他有效处置 → `approveResolvesOnlyTargetActionAndKeepsOthersActive` **精准变红**，已还原
- admin-web `vue-tsc --noEmit` **EXITCODE=0**
---
## 二、本轮最关键发现（必记）
### F1：申诉整条真实 DB 路径「零覆盖」盲区（必崩级）
`appeals` 表只列在 `EntityMigrationParityTest.TEST_SCHEMA_OPTIONAL_TABLES` 白名单里，而 H2 `schema-h2.sql` **根本没有该表** → `submitAppeal` / `processAppeal` / `approve` / `reject` / `escalate` 整条真实 DB 路径**零覆盖**。
更严重的是 `AppealServiceTest`：9 个用例中 **6 个是 `assertTrue(true)` 假绿**，而它们"覆盖"的恰好是 Gate 四条不变量（仅 ban/suspend 可申诉、幂等、通过解除、拒绝维持）；另有 1 个用 `@Mock` 断言 Mockito 默认值（`testFeatureFlagDefaultDisabled` 测的是 mock 不是真实默认值）。
**这是「白名单 = 无人测 + 占位假绿」模式的第八次复现。**
### F2：`escalate` 向 operator 发用户通知 → 撞 FK（只在 PG 上炸）
`escalateAppeal` 调用 `notificationService.send(operatorId, ...)`，但 `operators` 与 `users` 是**两张独立表**（V001），`notifications.user_id` 有 `FOREIGN KEY ... REFERENCES users(id)`（V004，从未移除）→ 在 PG 上必然 FK 违约，`@Transactional` 整体回滚 → **升级人工 100% 失败（500）**。测试库 notifications 无 FK，故零覆盖。
### F3：`appealType` 未校验白名单（只在 PG 上炸）
`submitAppeal` 直接透传 `dto.getAppealType()`，生产 `chk_appeal_type CHECK (appeal_type IN ('ban_appeal','suspend_appeal'))` 会拒绝非法值 → 500。测试库无 `appeals` 表故零覆盖。
---
## 三、真实缺陷清单（对应 Gate）
| 编号 | 类别 | 缺陷 | 修复 |
|---|---|---|---|
| D1 | 测试盲区/必崩级 | `appeals` 表缺失 + `AppealServiceTest` 6 处 `assertTrue(true)` 假绿 → 申诉真实 DB 路径零覆盖 | 补 `appeals` 表（对齐 V013，去外键留两 CHECK）；移出白名单入 `REQUIRED_IN_TEST_SCHEMA`；删除假绿测试，新建 `AppealPhase18IntegrationTest`（15 例） |
| D2 | 生产故障（PG） | `escalateAppeal` 向 `operatorId` 发用户通知 → 撞 `notifications.user_id → users(id)` FK → 升级事务回滚 | 移除非法通知，升级后进入后台待办队列由风控员决策 |
| D3 | 生产故障（PG） | `appealType` 未校验 `chk_appeal_type` 白名单；且未与处置类型一致性校验 | 校验白名单 + 必须与处置类型匹配；缺省按处置类型推导 |
| D4 | 功能死胡同 | `escalated` 状态无法再处理（`processAppeal` 仅接受 pending/reviewing）→ 升级后申诉永久滞留；前端 `AppealCenterView` 处理按钮也仅 `pending` | 后端原子认领放行 `escalated`；`getPendingAppeals` 返回 pending+escalated；前端放开处理入口 |
| D5 | 并发 | `processAppeal` 先读后写无原子守卫 → 两运营并发处理同一申诉可相互覆盖（approve/reject 竞态） | 新增 `markReviewingIfProcessable` 原子认领（`WHERE status IN ('pending','escalated')`），仅赢家继续 |
| D6 | 数据一致性 | `AppealMapper.findByUserId` / `findPending` / `findByStatusPaged` 未过滤 `deleted_at`（`countByStatus` 有） | 三处补 `deleted_at IS NULL` |
| D7 | 可维护性 | `approveAppeal` 硬编码 `"resolved"` | 改用 `Constants.RISK_ACTION_STATUS_RESOLVED` |
| D8 | 前后端契约 | miniapp 传 `evidenceFileIds`，后端只读 `evidence` → 证据字段名不匹配、永为 null | DTO 增 `evidenceFileIds`，服务层序列化映射进 `evidence` |
> 说明：`RISK_ACTION_STATUS_REVOKED`（`"revoked"`）在 `Constants` 中定义但**从无使用点**，且不在生产 `chk_risk_action_status`（`active/resolved/expired`）白名单内；`approveAppeal` 实际使用 `resolved`（正确）。JIRA 旧注"申诉通过 → status→revoked"与实现不符，已在文档中校正为 `resolved`。
---
## 四、负向验证（守卫有牙）
- 临时在 `approveAppeal` 中追加"把用户所有 active 处置一并置 resolved"（模拟"绕过其他处置"）→ 定向运行 `AppealPhase18IntegrationTest` → **恰好 1 条用例精准变红**：`approveResolvesOnlyTargetActionAndKeepsOthersActive` 报 `expected: <active> but was: <resolved>`（"其他仍有效的处置不得被解除（Gate）"）。已还原，`grep NEG-VAL` = 0。
---
## 五、证据（实测，非声明）
- **全量回归**：`494 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS`（离线容器 `danyang-match-backend-test` `mvn -B -o test`，约 4.4 分）。
- **定向编译验证**：`mvn -B -o test-compile` 通过（284 主源 + 78 测试源）。
- **前端类型检查**：admin-web `vue-tsc --noEmit` EXITCODE=0。
- **新增测试**：`backend/src/test/java/com/danyang/match/platform/appeal/AppealPhase18IntegrationTest.java`（15 例：真实落库/审计、仅 ban/suspend 可申诉、幂等、**Gate A 通过只解除目标处置**、**Gate B 拒绝维持原处置**、原子认领唯一赢家、二次处理被拒、escalate 后可再决策、appealType 白名单/一致性/缺省推导、证据字段映射、软删过滤、Feature Flag 关闭拦截）。
- **删除**：`backend/src/test/java/com/danyang/match/platform/appeal/AppealServiceTest.java`（6 假绿 + mock 默认值断言）。
---
## 六、改动文件清单
**主代码（src/main）**
- `appeal/service/AppealService.java` — 白名单校验、原子认领、escalate 去非法通知、常量替换、证据映射、软删过滤、escalated 可再决策。
- `appeal/mapper/AppealMapper.java` — 三处补 `deleted_at IS NULL`；新增 `findPendingOrEscalated` 与 `markReviewingIfProcessable`。
- `appeal/dto/AppealSubmitDTO.java` — 新增 `evidenceFileIds`（对齐 miniapp 契约）。
- `shared/constant/Constants.java` — 新增 `APPEAL_TYPE_BAN` / `APPEAL_TYPE_SUSPEND`。
**测试（src/test）**
- `appeal/AppealPhase18IntegrationTest.java` — 新增 15 例。
- `appeal/AppealServiceTest.java` — 删除（假绿）。
- `deployment/EntityMigrationParityTest.java` — `appeals` 移出白名单、入 `REQUIRED_IN_TEST_SCHEMA`（Phase 18 注释）。
- `resources/schema-h2.sql` — 补 `appeals` 表。
**前端**
- `admin-web/src/modules/appeal/AppealCenterView.vue` — escalated 申诉放开处理入口（列表按钮 + 详情决策表单）。
**文档**
- `docs/STATUS.md`、`docs/JIRA_BACKLOG.md`、`docs/善缘丹阳 V1.1 客户需求基线增量开发与修复计划.md` 的 Phase 18 段。
- `docs/Phase-18-V11-Recovery-Completion-Report-2026-09-17.md`（本报告）。
- 技能 `danyang-platform-verification` 同步更新。
---
## 七、下一步
**Phase 19（统一运营后台 + 用户端公益服务页面 — ADD/REFACTOR）未自动进入，等待用户确认后启动。** 是否继续？
docs/STATUS.md
+24 -3
View File
@@ -1,8 +1,8 @@
# 项目状态跟踪 — STATUS.md
> **2026-09-17 当前有效结论：`V1.1 INCREMENTAL RECOVERY PHASE 17 COMPLETE / GIT CLEAN`。**
> **2026-09-17 当前有效结论：`V1.1 INCREMENTAL RECOVERY PHASE 18 COMPLETE / GIT CLEAN`。**
>
> 阶段 0（在途收口）、阶段 1（小程序 C 组 + discover 筛选重设计）、阶段 2（管理端 Vue 新框架适配）、阶段 3（CapabilityService 独立化）、阶段 4（双端总验收）全部完成。三端构建通过、**13/13 契约全绿**、核心 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（举报与风控）复验已关闭**，十一轮共修复 77 处真实缺陷（含 2 处隐藏编译缺陷），并各自补齐测试保真度与守卫。**Phase 18 需用户确认后启动。**
> 阶段 0（在途收口）、阶段 1（小程序 C 组 + discover 筛选重设计）、阶段 2（管理端 Vue 新框架适配）、阶段 3（CapabilityService 独立化）、阶段 4（双端总验收）全部完成。三端构建通过、**13/13 契约全绿**、核心 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（申诉）复验已关闭**，十二轮共修复 85 处真实缺陷（含 2 处隐藏编译缺陷），并各自补齐测试保真度与守卫。**Phase 19 需用户确认后启动。**
最后更新: 2026-09-17 — 分支 `main`（`feat-ui-v11` 保留为冗余锚点）
@@ -22,7 +22,7 @@
| 阶段 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~V039 | V028~V038 已纳入 STATUS；V037 为 Phase 12 新增（实体列与生产迁移对齐，23 表 50 列）；V038 为 Phase 13 新增（`matchmaker_recommendations.status` + `matchmaker_services.service_type` 的 CHECK 白名单扩展）；V039 为 Phase 13A 新增（counseling 幂等键 + 三个 CHECK 白名单显式固化） |
| Backend 全量回归 | **已清偿**（2026-09-17） | 离线容器（`danyang-match-backend-test`）`mvn -o test` 实测：**488 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS**（约 4 分）；含 `CanonicalRouteContractTest`、`ChatContractJsonTest`、`MeRouteContractTest`、`DiscoverBlockInvisibilityIntegrationTest`、`ChatPhase09IntegrationTest`、`ChatWebSocketHandlerTest`、`PhotoUploadValidationTest`、`NotificationPhase11IntegrationTest`、`NotificationTemplateTypeGuardTest`、`NotificationPrivacyCopyTest`、`EntityMigrationParityTest`、`RelationshipProgressPhase12Test`、`HomePremaritalGuidancePhase12Test`、`MatchmakerReferralPhase13Test`、`MatchmakerServiceTest`、`ReportAndRiskPhase17IntegrationTest`（Phase 17 新增 7 例：举报写 reports+abuse_report 风险事件、三来源接入统一 RiskEvent、处置封禁写 risk_actions、人工标记审计、敏感访问审计、findByUserId 软删过滤、最小可见） |
| Backend 全量回归 | **已清偿**（2026-09-17） | 离线容器（`danyang-match-backend-test`）`mvn -o test` 实测：**494 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS**（约 4.4 分）；含 `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 关闭拦截） |
| 路由/字段契约收敛 | **已完成**（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 |
@@ -47,6 +47,7 @@
| 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 |
---
@@ -263,6 +264,26 @@
> 假绿掩盖盲区；且敏感访问（查看他人风险画像/举报）此前**无审计**（违反 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 复验通过）
| 任务 | 状态 |
|------|------|
docs/善缘丹阳 V1.1 客户需求基线增量开发与修复计划.md
+7 -5
View File
@@ -463,15 +463,17 @@ D2——`RelationshipService.createMatch` 不写 episode/lastActivityAt，与 `M
**复验结论：** 修复 6 处真实缺陷（D1 测试库缺三表必崩级盲区、D2 人工标记无审计、D3 敏感访问无审计、D4 审计缺 ip/ua、D5 findByUserId 未过滤软删、D6 jakarta 编译缺陷+risk_events 漏 updated_at）；新增集成测试 7 例；全量回归 488 全绿。
**报告：** `docs/Phase-17-V11-Recovery-Completion-Report-2026-09-17.md`。**Phase 18 需用户确认后启动。**
### Phase 18：申诉 — KEEP-VERIFY
### Phase 18：申诉 — KEEP-VERIFY ✅ 已完成（2026-09-17 KEEP-VERIFY 复验通过）
**Files:** appeal 模块、Miniapp appeal 页面和后台 AppealCenter。
- [ ] 回归 ban/suspend 申诉、幂等处理、审批和解除动作。
- [ ] 验证申诉不能绕过仍有效的其他风险处置。
- [ ] 是否首发继续由已确认 Feature Flag 控制。
- [x] 回归 ban/suspend 申诉、幂等处理、审批和解除动作。
- [x] 验证申诉不能绕过仍有效的其他风险处置（负向验证已证守卫有牙）。
- [x] 是否首发继续由已确认 Feature Flag 控制（`features.appeal-enabled`，dev/docker 均 false）。
**Gate:** 申诉通过只解除目标处置；拒绝后原处置保持有效。
**Gate:** 申诉通过只解除目标处置 ✅；拒绝后原处置保持有效 ✅。
**复验结论：** 修复 8 处真实缺陷（D1 测试库缺 `appeals` 表 + `AppealServiceTest` 6 处假绿 → 零覆盖；**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）；新增 `AppealPhase18IntegrationTest`（15 例），删除假绿 `AppealServiceTest`（9 例）；全量回归 494 全绿。
**报告：** `docs/Phase-18-V11-Recovery-Completion-Report-2026-09-17.md`。**Phase 19 需用户确认后启动。**
### Phase 19：统一运营后台 + 用户端公益服务页面 — ADD/REFACTOR