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

fix(activity): close Phase 15 KEEP-VERIFY/EXTEND — 2 critical + 14 other defects, 3 test-fidelity fixes

Browse Source 
Phase 15 (activity registration / review / checkin) verification closure.

Two CRITICAL defects, both "production always had it, test schema never did":
- D1: generateCheckinToken wrote the token to Redis with value "used", while
  scanCheckin rejects any token marked "used" -> every freshly issued check-in
  code was dead on arrival, staff scanning failed 100% of the time.
  Issuing now writes "issued"; "used" is set only after a successful scan.
- D9: UNIQUE(activity_id, user_id) exists in production, but re-registering
  after cancel/reject went through INSERT -> users who cancelled once could
  never register for that activity again (duplicate key 500). The H2 test
  schema lacked the UNIQUE, so the path had zero coverage. Now the original
  row is reused via an atomic conditional UPDATE.

Checkin (D2-D8):
- D2: duplicate check-in was read-then-write; now atomic checkinIfNotCheckedIn
  and repeat scans are idempotent (alreadyCheckedIn) without duplicate audit.
- D3: no data scope at all -> added activity staff assignment (V040) and
  assertCheckinScope; INV-020 (org relation grants nothing).
- D4: manualCheckin did not validate activity existence/cancellation.
- D5: getCheckinStats NPE on missing activity; remainingCount was semantically
  "free seats" -> replaced with notCheckedInCount.
- D6: malformed timestamp caused 500 -> 400. D7: constant-time signature compare.

Registration / review / cancel (D10-D13):
- D10: backend registration list only queried status='approved' -> the review
  screen never saw pending rows (review unusable).
- D11: registration_start_at / registration_end_at were never enforced.
- D12: cancel had no audit log (the only write without one).
- D13: reject/cancel were read-then-full-update -> rejectIfPending/cancelIfActive.

Capacity groups (D14, plan item 2): groups were stored and read back but never
participated in capacity -> incrementIfAvailable / decrementIfPositive now make
approved_count real; activities without groups are unaffected.

Frontend contract (F1-F2):
- F1: admin-web had no check-in surface at all -> ActivityCheckinView.vue
  (paste/scan token, manual check-in, stats) + /activities/checkin route & nav.
- F2: miniapp had no cancel-registration wrapper although the endpoint existed.

Test fidelity (T1-T3):
- T1: test schema gained UNIQUE(activity_id,user_id) + chk_reg_status +
  chk_checkin_status; two new guards parse the real V010 DDL and compare.
- T2: 3 assertTrue(true) placeholders in CheckinServiceTest (covering duplicate
  check-in, expiry, no-sensitive-plaintext) replaced with 5 real guards that
  parse the real source and real production DDL.
- T3: activity_registrations + activity_staff_assignments moved into
  REQUIRED_IN_TEST_SCHEMA; MigrationValidationTest baseline 39 -> 40.

Note: ActivityStaffAssignment must NOT extend BaseEntity - the table is a
composite PK (activity_id, operator_id); BaseEntity would add id/updated_at/
deleted_at to every INSERT and break on PostgreSQL (caught by
EntityMigrationParityTest immediately).

Tests: ActivityPhase15Test (21), CheckinServiceTest (5), 2 new constraint
guards. Negative verification: 3 injected defects -> 8 assertions turned red,
all restored.

Regression: 474 tests / 0 failures / 0 errors / 3 skipped / BUILD SUCCESS
(baseline 450). admin-web vue-tsc 0 error, vite build OK.
This commit is contained in:
WorkBuddy
2026-09-17 15:07:52 +08:00
parent 755a570849
commit 29112eed6e
21 changed files with 1602 additions and 116 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/JIRA_BACKLOG.md
+10
View File
@@ -3,6 +3,15 @@
> V1.0 Phase 01~26 基础 + V1.1 增量任务合并基线
> 版本：v1.1.0-dev | 最后更新：2026-09-08
> **2026-09-17 Phase 15 复验关闭：** EPIC-P15 已完成。复验发现两处**必崩级**缺陷，均为「生产一直存在、
> 测试库从未约束」的同族根因：① **签到码一生成即作废** —— `generateCheckinToken` 把 token 写入 Redis
> 值 `"used"`，而 `scanCheckin` 见到 `"used"` 立即拒绝，扫码签到 **100% 失败**；
> ② **取消后永远无法再报名** —— 生产 `UNIQUE(activity_id, user_id)` 一直存在，而重报名走 `INSERT`，
> 测试库缺该唯一键故零覆盖。共修复 **16 处缺陷 + 3 处测试保真度缺陷**，新增 V040
> `activity_staff_assignments` 落实「服务站操作员只能操作指定活动」（INV-020）。
> 证据：`docs/Phase-15-V11-Recovery-Completion-Report-2026-09-17.md`。
> **Phase 16 需用户确认后启动。**
> **2026-09-16 状态校正：** Phase 07 UI 已按 2026-09-13 规格重新实现，**首批 11 页于 2026-09-16 通过用户验收（结论：基本达标）**，本文件此前"视觉否决/REOPENED"口径随之关闭。
>
> **2026-09-17 Phase 14 复验关闭：** EPIC-P14 已完成。复验发现 activity 模块存在**必崩级空壳**——
@@ -120,6 +129,7 @@
| Phase 13 公益红娘转介复验 | 已完成（2026-09-16） | 见 `Phase-13-V11-Recovery-Completion-Report-2026-09-16.md`；修复 7 处缺陷（**2 处生产故障级 CHECK 约束缺口致推荐接受/服务提交必崩**、推荐与转介三处越权、`getServiceDetail` 越权读、Mapper 缺 `@Select` 致必崩、前端 5 处契约缺口），测试库补 3 张 matchmaker 表，迁移基线 V038；新增 `MatchmakerReferralPhase13Test`（17 用例）+ 重写 `MatchmakerServiceTest`（6 用例，解析真实 DDL），删除 3 处假测试，后端 **391 tests 全绿**；**Phase 13A 尚未获准** |
| Phase 13A 婚恋咨询与婚前辅导复验 | 已完成（2026-09-17） | 见 `Phase-13A-V11-Recovery-Completion-Report-2026-09-17.md`；发现 counseling **双实现**（权威类零测试 / 孤儿类被单测），已合并删除孤儿类；修复 **9 处缺陷**（**D1 咨询正文写日志=INV-013 泄露**、D2 申请 userId 取请求体、**D3 分配先读后写并发静默覆盖**、D4 manager 可读 followups=INV-013 绕过、D5 无状态机、**D6 `/services/intro` 后端不存在致小程序 intro 页 100% 无数据**、D7 Admin 5 端点 404、D8 小程序字段名/幂等/静默失败、D9 测试库 counseling 零 CHECK 约束）+ **4 处测试基建缺陷**（守卫找不到 DDL 恒真假绿、全限定 `@TableField` 漏解析、权限守卫假阳性、测试自身逻辑缺陷）；迁移基线 V039；新增 `CounselingPhase13ATest`（25）+ `CounselingConstraintGuardTest`（5，解析真实 DDL），两轮负向验证证明守卫会红；后端 **420 tests 全绿**；**Phase 14 尚未获准** |
| Phase 14 多类型公益活动复验 | 已完成（2026-09-17） | 见 `Phase-14-V11-Recovery-Completion-Report-2026-09-17.md`；修复 **11 处后端缺陷**（**D1 `ActivityMapper.countRemainingCapacity` 无 SQL 空壳致详情/报名/审核必崩**、**D2 报名与审核先读后写并发超卖** → 改原子 SQL、D3 类型/角色未校验生产 CHECK 白名单、**D4 DTO 无 `activityType` 致小程序分类 Tabs 恒空**、D5 男女人数 `approvedCount/2` 编造、D6 年龄门槛空壳、D7 按类型资格策略为空、**D8 运营端建活动丢弃类型且把主办组织错设为操作者 userId**、D9 三个运营端点错挂用户端双实现、D10 软删活动/缺字段 NPE、D11 DTO 缺 4 字段）+ **3 处前端契约缺陷**（分类 code `classroom` 不在白名单、卡片读 7 个不存在字段、admin-web 无活动管理页）+ **2 处测试保真度缺陷**（2 条占位假绿、测试库缺 V023 列与三张表）；新增 `ActivityPhase14Test`（23）+ `ActivityConstraintGuardTest`（9，解析真实 DDL **与前端源码**），两轮负向验证证明守卫会红；admin-web `vue-tsc` 0 error + `vite build` 通过；后端 **450 tests 全绿**；**Phase 15 尚未获准** |
| 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 尚未获准** |
| 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 通过用户验收 |