release: freeze 2026-10-15 validated release baseline

docs/superpowers/plans/2026-10-12-matchmaker-dual-client-integration.md

@@ -0,0 +1,105 @@
+# 红娘双端最小联动闭环实施计划
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 打通红娘 Web 分配、小程序服务对象详情与服务记录、Web 查看结果的第一阶段闭环。
+
+**Architecture:** 复用现有 Spring Boot 红娘模块、Vue 管理端和微信小程序原生页面。以 `matchmaker_assignments` 作为数据范围事实来源，以服务端 API 作为状态事实来源，前端只负责展示和提交操作。
+
+**Tech Stack:** Java 21、Spring Boot 3.x、PostgreSQL、MyBatis-Plus、Vue 3、TypeScript、微信小程序原生 JavaScript/WXML/WXSS。
+
+**Spec:** `docs/superpowers/specs/2026-10-12-matchmaker-dual-client-integration-design.md`
+
+## Global Constraints
+
+- 普通红娘只能访问本人有效分配对象。
+- 红娘不能代替用户 Like、Pass、接受活动意向或确认开启聊天。
+- PostgreSQL 是 Source of Truth，前端缓存不能覆盖服务端状态。
+- 联系方式默认拒绝，未完成授权不得返回完整手机号、微信号和详细地址。
+- 不增加依赖，不新建微服务，不改动无关领域。
+- 所有新增业务逻辑先写失败测试，再写最小实现。
+
+### Task 1: 固化端点和数据范围测试
+
+**Files:**
+- Modify: `backend/src/test/java/com/danyang/match/platform/matchmaker/*` 现有红娘测试
+- Create: `backend/src/test/java/com/danyang/match/platform/matchmaker/MatchmakerServiceDetailScopeTest.java`
+- Create: `backend/src/test/java/com/danyang/match/platform/matchmaker/MatchmakerFollowupScopeTest.java`
+
+**Interfaces:**
+- Consumes: `ServiceAssignmentPolicy`、`MatchmakerServiceService`、现有 `MatchmakerAssignment` 测试夹具。
+- Produces: 可证明“本人有效分配允许、其他红娘/失效分配拒绝”的测试契约。
+
+- [ ] Step 1: 写测试：同一服务对象在有效分配给当前红娘时详情和跟进允许；换成其他红娘、撤销或过期时拒绝。
+- [ ] Step 2: 运行单测，确认因现有服务详情/跟进调用路径缺少或未覆盖断言而失败。
+- [ ] Step 3: 仅补齐服务层调用现有 `ServiceAssignmentPolicy` 的最小授权检查和统一错误映射。
+- [ ] Step 4: 重新运行新增测试及现有 `MatchmakerReferralPhase13Test`、`MatchmakerAssignmentPermissionTest`。
+- [ ] Step 5: 记录端点和数据范围结论到阶段报告。
+
+### Task 2: 补齐小程序服务对象详情页面
+
+**Files:**
+- Create: `miniapp/pages/matchmaker-service-detail/matchmaker-service-detail.js`
+- Create: `miniapp/pages/matchmaker-service-detail/matchmaker-service-detail.wxml`
+- Create: `miniapp/pages/matchmaker-service-detail/matchmaker-service-detail.wxss`
+- Create: `miniapp/pages/matchmaker-service-detail/matchmaker-service-detail.json`
+- Modify: `miniapp/app.json`
+- Modify: `miniapp/pages/matchmaker-workbench/matchmaker-workbench.js`
+
+**Interfaces:**
+- Consumes: `GET /operator/matchmaker/services/{id}`、`GET /operator/matchmaker/services/{id}/history`、`POST /operator/matchmaker/services/{id}/followup`。
+- Produces: 从工作台分配卡片进入详情、查看授权字段、查看历史和提交服务记录。
+
+- [ ] Step 1: 写页面契约测试或静态守卫，验证页面已注册、请求只使用服务 ID、没有联系方式和代操作按钮。
+- [ ] Step 2: 运行守卫确认当前页面目录缺失导致失败。
+- [ ] Step 3: 实现最小详情页：加载、空状态、失败、无权限、历史列表和记录表单。
+- [ ] Step 4: 记录提交成功后重新拉取详情和历史；失败保留表单输入；重复提交由提交锁阻止。
+- [ ] Step 5: 运行小程序现有页面守卫和 WXML/WXSS 编译检查。
+
+### Task 3: 统一 Web 服务详情和跟进查看
+
+**Files:**
+- Modify: `admin-web/src/modules/matchmaker/MatchmakerManagementView.vue`
+- Create or modify: `admin-web/src/api/*` only if现有 `get/post` 无法复用
+- Modify: `backend/src/main/java/com/danyang/match/platform/matchmaker/controller/MatchmakerOperatorController.java` only when Task 1 proves endpoint缺失
+
+**Interfaces:**
+- Consumes: Task 1 的详情、历史和范围契约。
+- Produces: Web 在本人授权范围内查看服务记录和最新服务状态。
+
+- [ ] Step 1: 写前端行为测试/契约守卫，验证列表点击详情时只传服务 ID，范围错误显示统一提示。
+- [ ] Step 2: 运行测试确认当前管理页没有服务详情和跟进查看入口。
+- [ ] Step 3: 增加最小抽屉或弹窗，显示服务状态、最近跟进和必要摘要。
+- [ ] Step 4: 分配、转交、撤销、结束后刷新当前 Tab，不保留旧对象状态。
+- [ ] Step 5: 运行 `admin-web` 类型检查和构建。
+
+### Task 4: 跨端刷新和权限失效处理
+
+**Files:**
+- Modify: `miniapp/pages/matchmaker-workbench/matchmaker-workbench.js`
+- Modify: `miniapp/pages/matchmaker-service-detail/matchmaker-service-detail.js`
+- Modify: `miniapp/utils/api.js`
+- Modify: `admin-web/src/api/client.ts` only if现有错误处理不能统一
+
+**Interfaces:**
+- Consumes: Task 1-3 的端点和错误契约。
+- Produces: 页面显示始终以最新服务端状态为准，权限失效时清理敏感缓存并返回工作台。
+
+- [ ] Step 1: 写请求层测试，验证 401/403/资源失效不会静默吞掉，并能被页面识别。
+- [ ] Step 2: 运行测试确认当前请求层行为不足。
+- [ ] Step 3: 增加最小的刷新、提交锁、权限失效跳转和非敏感缓存清理。
+- [ ] Step 4: 验证 Web 与小程序写操作后都重新读取服务端数据。
+- [ ] Step 5: 运行小程序请求层测试和 Web 构建。
+
+### Task 5: 第一阶段验收与文档
+
+**Files:**
+- Create: `docs/Phase-matchmaker-dual-client-Completion-Report-2026-10-12.md`
+- Modify: `docs/STATUS.md` only for已验证状态
+- Modify: `docs/governance/open-questions.md` only for未确认联系授权细节
+
+- [ ] Step 1: 运行后端红娘相关测试、前端构建和小程序静态/编译守卫。
+- [ ] Step 2: 以两个红娘账号和一个普通用户账号执行分配、查看、记录、撤销和越权场景。
+- [ ] Step 3: 将每项结果标记为 `PASS`、`PARTIAL`、`FAIL` 或 `NOT_VERIFIED`。
+- [ ] Step 4: 只有所有 P0 场景通过才将第一阶段标为 `PASS`，否则保留 `PARTIAL` 或 `FAIL`。
+- [ ] Step 5: 输出剩余风险和第二阶段依赖，不自动进入下一阶段。

docs/superpowers/plans/2026-10-13-demo-closeout-plan.md

@@ -0,0 +1,75 @@
+# 爱在丹阳三端演示收口执行计划
+
+> 执行方式：在当前会话按 executing-plans 逐项执行，每项记录证据；阶段结束输出 Completion Report。
+
+**Goal:** 使用现有运营演示数据，确认管理端、红娘小程序与用户小程序形成可重复演示的业务闭环。
+
+**Architecture:** 沿用现有 Vue 管理端、原生微信小程序和 Spring Boot 模块化单体。三端共享后端与 PostgreSQL，以实际请求和落库结果验证联动。
+
+**Tech Stack:** Vue 3、TypeScript、Vite、微信小程序、Java 21、Spring Boot、PostgreSQL、Docker Compose。
+
+**Spec:** `docs/superpowers/specs/2026-10-12-matchmaker-dual-client-integration-design.md` 与用户最新品牌、编号和审批导航指令。
+
+## 执行边界
+
+- 优先使用运营管理端已有演示数据；不清库、不重新生成整库演示数据。
+- 最新品牌为“爱在丹阳”，标语为“爱在丹阳 原来是你”；保留已确认字体。
+- 联系授权审批归入“红娘服务”，不单独新增一级导航。
+- 展示编号按最新指令核对：12 位字母与数字，红娘示例 HN2026101301；不因展示编号要求直接替换关联主键。
+- 不代用户 Like，不放宽 Required，不越权读取咨询正文或联系方式。
+- 历史 PASS 不替代本轮实测；无法执行的项记为 NOT_VERIFIED。
+- 只修复验收发现的问题；数据库变更、扩大产品范围等另行明确边界。
+
+## 任务 1：确认最新前端部署与品牌渲染
+
+涉及：`admin-web/public/brand/logo-mark.png`、`admin-web/src/layouts/MainLayout.vue`、`admin-web/src/views/LoginView.vue`；部署配置仅检查 `infrastructure/docker-compose*.yml`。
+
+- [x] 核对当前 Docker 容器、Compose 项目和运行端口，确认实际提供 /admin/ 的服务。
+- [x] 比对运行服务与本地最新构建的 Logo、CSS；发现旧镜像后重建并仅更新管理端服务。
+- [x] 检查 Logo 请求 HTTP 200、PNG 类型及透明通道；核对页面使用最新资源。
+- [ ] 在 1366×768 和 1920×1080 检查登录页、顶部栏、展开/折叠侧栏：无方形底色、主体完整、对齐正常（待用户在浏览器完成目视确认）。
+- [x] 保存请求、容器文件哈希和构建证据。既有背景 CSS 构建警告已记录，未影响本次 Logo 资源发布。
+
+验收：正在运行的页面呈现新 Logo 和品牌文案；不存在旧资源或渲染异常。
+
+## 任务 2：演示数据、编号与统计一致性
+
+涉及检查：`admin-web/src/modules/user/`、`admin-web/src/modules/matchmaker/`、`admin-web/src/layouts/MainLayout.vue`、`backend/src/main/java/com/danyang/match/platform/`；报告记录抽样结果。
+
+- [x] 从现有数据选定一名红娘、两名服务用户和一名审批操作员，使用脱敏编号建立验收记录。
+- [x] 对比管理端接口与红娘工作台接口的展示编号、姓名、服务状态和分配关系；`/operator/matchmaker/assignments/my` 已在代码中正确使用。
+- [x] 核对用户、红娘、管理员等对外展示编号的长度、格式、唯一性；当前演示账号和 12 个演示用户展示编号均为 12 位且唯一。
+- [x] 核对工作台顶部统计改为服务记录实时计算；当前管理范围实测为今日 2 单、待处理 3 单。
+- [x] 待审核资料改为审核统计接口 `pending + processing`，审核完成后从工作台同步减少；不再使用固定 Demo 数字。
+
+验收：同一对象三端一致，编号可读且唯一，统计可追溯到同一组演示数据。
+
+## 任务 3：逐条业务闭环复验
+
+涉及检查：红娘服务管理页面、`miniapp/pages/matchmaker-workbench/`、服务详情/转介/推荐页面和相应后端接口；复用 `tests/miniapp/matchmaker_*` 与现有后端测试。
+
+- [ ] 管理端分配服务 → 红娘端出现对象 → 查看详情 → 新增跟进 → 管理端记录回写。
+- [ ] 提交完成服务 → 按现有确认规则完成 → 管理端状态与统计更新；不跳过已确认的用户确认步骤。
+- [ ] 发起推荐 → 用户端查看并自行处理 → 红娘端推荐进展更新；不以推荐直接创建聊天。
+- [ ] 发起转介 → 有权接收人员处理 → 两端状态一致，非本人范围默认拒绝。
+- [ ] 红娘申请联系授权 → 管理端“红娘服务”内审批 → 用户单独确认 → 限时可用 → 撤销后拒绝披露。
+- [ ] 用另一名红娘或无权限操作员尝试访问上述对象，确认无越权及敏感字段泄露。
+- [ ] 每条记录操作前后状态、接口结果、脱敏对象编号和界面证据；重复操作不新增重复业务记录。
+
+验收：每条链路均有可复查结果；页面有入口、可操作、落库且另一端可看到变化。
+
+## 任务 4：回归、演示预案与阶段报告
+
+输出：`docs/Phase-demo-closeout-Completion-Report-2026-10-13.md`、`docs/DEMO-WALKTHROUGH-2026-10-13.md`；根据本轮证据更新 `docs/STATUS.md` 的当前结论，不删除历史。
+
+- [ ] 在 backend 执行 `mvn test`，记录总数、失败、错误、跳过数。
+- [ ] 在 admin-web 执行 `pnpm run type-check` 和 `pnpm run build`。
+- [ ] 按项目现有命令执行小程序类型检查、结构守卫及本阶段相关行为测试。
+- [ ] 对本次修改执行 `git diff --check`；不运行带 --fix 的全仓 lint。
+- [ ] 整理演示顺序、账号角色、入口、预期结果、必要截图和出错恢复办法，不在文档保存密码或密钥。
+- [ ] 验证演示数据保留且容器正常；只在明确服务范围和恢复方式后开展必要重启验证。
+- [ ] 出具逐项 PASS/PARTIAL/FAIL/NOT_VERIFIED 与演示 GO/CONDITIONAL GO/NO-GO；演示通过不等于生产上线通过。
+
+## 后续独立阶段
+
+演示验收结束后，再按既有 Phase 24～26 执行真实用户 UAT、运营素材替换和生产部署验收。真实微信环境、域名/HTTPS、备份恢复及正式上线检查不能用演示数据验证代替。本计划不包含未批准的死代码退役或全项目重构。

docs/superpowers/plans/2026-10-14-global-public-id-implementation.md

@@ -0,0 +1,214 @@
+# 全平台业务展示编号统一实施计划
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 让所有面向用户或跨角色展示的人员、任务、活动和业务记录 ID 使用 13 位稳定业务编号，并确保 Web、小程序和运营 API 的展示一致。
+
+**Architecture:** 保留 PostgreSQL UUID 主键、外键、权限与路由寻址；为公开展示实体持久化业务编号。以 PostgreSQL 原子计数器按前缀和上海日期分配编号，在实体创建事务中写入；后端 DTO 同时提供内部 ID 与公开展示字段，前端只渲染公开字段。
+
+**Tech Stack:** Java 21、Spring Boot、MyBatis-Plus、PostgreSQL、Flyway、Vue 3、TypeScript、微信原生小程序、Node.js 行为测试、Docker Compose。
+
+**Spec:** `docs/superpowers/specs/2026-10-14-global-public-id-design.md`
+
+## Global Constraints
+
+- 公开编号严格使用 `2 位大写字母前缀 + Asia/Shanghai YYYYMMDD + 3 位序号`，共 13 位。
+- 用户 `YH` 按注册日和性别分别排名，男性序号奇数、女性序号偶数；红娘 `HN`，其他工作人员 `GL`，任务 `RW`，活动 `HD`。
+- UUID 主键、外键、JWT subject、数据范围、权限校验、幂等语义和既有 UUID API 路由保持不变。
+- 推荐对象、被推荐人、被举报人和活动参与者统一展示用户 `YH` 编号。
+- 任意用户可见页面、弹窗、导出和小程序不得渲染原始 UUID；不可用中文占位掩盖接口漏字段，必须修 DTO/查询。
+- 不覆盖或回滚开始任务前工作区的任何修改；只提交本计划涉及的新改动。
+- 不添加第三方依赖；后端唯一编号由 PostgreSQL 并发安全地产生。
+
+---
+
+## 文件结构与责任
+
+- `backend/src/main/resources/db/migration/V060__add_global_public_display_ids.sql`：为业务实体增加公开编号列/计数器，并为现存数据确定性回填和建立唯一索引。
+- `backend/src/main/java/com/danyang/match/platform/shared/id/`：编号前缀、长度、日期与原子分配服务；只新增小型领域工具，不重构 UUID 基础设施。
+- 各领域 Entity、Mapper、Service、DTO：在创建事务中写入公开编号；查询以 JOIN 取关联用户/操作员的展示编号。
+- `backend/src/test/java/com/danyang/match/platform/shared/id/` 与领域测试：格式、奇偶、并发、迁移、DTO 白名单和越权行为测试。
+- `admin-web/src/modules/`：替换直接渲染 UUID 的列、详情、表单和导出；交互继续传内部 ID。
+- `miniapp/pages/` 与 `miniapp/services/`：只显示公开编号，动作请求继续用内部 ID。
+- `docs/DEMO-VALIDATION-2026-10-13.md`：追加编号回填与双端展示验收证据，不改写历史记录。
+
+## Task 1: 建立全仓公开 ID 展示清单与锁定测试
+
+2026-10-14 执行结果：模板/关键动态文案盘点与检查器已完成，清单见 `../specs/2026-10-14-global-public-id-display-inventory.md`。检查器 7 项自检 PASS；114 个模板发现 31 个审查候选，全局展示检查仍 FAIL。Java 响应行为覆盖测试移至 Task 3，避免仅断言源码字符串。预约 YY 前缀待用户确认后进入迁移实现。
+
+**Files:**
+- Create: `backend/src/test/java/com/danyang/match/platform/shared/id/PublicDisplayIdCoverageTest.java`
+- Create: `tests/public-id-display-coverage.cjs`
+- Inspect: `admin-web/src/modules/`、`miniapp/pages/`、各模块 Controller/DTO/Mapper、Flyway 迁移
+
+- [ ] **Step 1: 建立清单和失败测试**
+
+清单至少逐项记录：实体、UUID 列/关系、创建入口、API DTO、管理端页面、用户小程序页面、编号前缀、是否包含既有用户隐私权限。覆盖 `users`、`operators`、`activities`、`review_tasks`、`reports`、`matchmaker_services`、`matchmaker_recommendations`、`matchmaker_contact_authorizations`、`matchmaker_assignments`、`matchmaker_followups`、转介实体，以及搜索中发现的任何其他实际展示 UUID 的实体。
+
+守卫测试扫描已登记的 Web Vue 与小程序 WXML/TS/JS 文件，拒绝把 `operatorId`、`userId`、`targetUserId`、`activityId`、`serviceId`、`recommendationId` 等内部 UUID 直接插值到可见模板；允许它们用于事件、路由和 API 参数。测试对明确的 display 字段白名单断言。
+
+- [ ] **Step 2: 运行测试确认暴露当前差距**
+
+Run: `node tests/public-id-display-coverage.cjs`
+Expected: FAIL，报告仍直接显示 UUID 的具体文件与模板位置。
+
+- [ ] **Step 3: 固化清单与覆盖测试**
+
+将前置检查清单保存到 `docs/superpowers/specs/2026-10-14-global-public-id-display-inventory.md`；确认每个展示 ID 均映射到规格中已有前缀。若发现需新增前缀或改变既有 API 路由参数，暂停后续实现并修订规格等产品确认。
+
+- [ ] **Step 4: 运行测试**
+
+Run: `node tests/public-id-display-coverage.cjs`
+Expected: 检查器自检 PASS；展示扫描在遗留问题修复前保持 FAIL，不将已知问题豁免为全局 PASS。
+
+## Task 2: 编号分配器、字段迁移和历史回填
+
+**Files:**
+- Create: `backend/src/main/resources/db/migration/V060__add_global_public_display_ids.sql`
+- Create: `backend/src/main/java/com/danyang/match/platform/shared/id/PublicDisplayId.java`
+- Create: `backend/src/main/java/com/danyang/match/platform/shared/id/PublicDisplayIdAllocator.java`
+- Create: `backend/src/main/java/com/danyang/match/platform/shared/id/PublicDisplayIdMapper.java`
+- Modify: `backend/src/main/java/com/danyang/match/platform/user/UserDisplayNumber.java`
+- Modify: 相关 entity，至少 `User.java`、`Operator.java`、`Activity.java`、审核/举报/红娘相关 entity
+- Create: `backend/src/test/java/com/danyang/match/platform/shared/id/PublicDisplayIdTest.java`
+- Create: `backend/src/test/java/com/danyang/match/platform/shared/id/PublicDisplayIdAllocatorTest.java`
+- Modify: `backend/src/test/java/com/danyang/match/platform/deployment/MigrationValidationTest.java`
+- Modify: `backend/src/test/resources/schema-h2.sql`
+
+- [ ] **Step 1: 编写编号格式和分配器失败测试**
+
+测试 `YH20261014001`、`YH20261014002` 的用户奇偶规则，普通记录格式 `RW20261014001`；非法前缀、日期、序号、用户性别、序号越过 999 必须拒绝。PostgreSQL mapper 测试以并发任务申请同一前缀同一天的编号，断言数量一致且全部唯一；禁止使用 `COUNT(*) + 1`。
+
+- [ ] **Step 2: 运行定向测试确认失败**
+
+Run: `cd backend; mvn -Dtest=PublicDisplayIdTest,PublicDisplayIdAllocatorTest test`
+Expected: FAIL，因编号工具和 mapper 尚未实现。
+
+- [ ] **Step 3: 添加持久化编号字段与回填**
+
+新增迁移为清单内公开实体添加 `display_id`（用户沿用 `display_number`，工作人员沿用 `display_id`），建立 `public_display_id_counters(prefix, local_date, sequence_group, last_sequence)` 计数器表。迁移按 `Asia/Shanghai` 注册/创建日期及稳定次序回填：用户按实名性别分别排名并写入男奇女偶尾号；工作人员按角色决定 `HN/GL`；任务 `RW`；活动 `HD`；其余业务表按规格与覆盖清单中的前缀分表排名。回填完成后设置非空和部分唯一约束；软删除记录也保留其编号唯一性，不得复用。初始化计数器到每组已使用的最大序号。
+
+- [ ] **Step 4: 实现原子分配器**
+
+Mapper 使用 PostgreSQL 原子 UPSERT：普通编号按 `sequence_group=''` 每次加 1；用户编号按 `sequence_group=gender` 分别加 2，男性首值 1、女性首值 2。更新前检查生成值不超过 999；无返回值时抛明确容量异常。日期由 `Clock` 注入并按 `Asia/Shanghai` 转换。`UserDisplayNumber` 调整为接受已分配奇偶序号且支持三位尾号，避免自行计数。
+
+- [ ] **Step 5: 运行后端定向测试与迁移验证**
+
+Run: `cd backend; mvn -Dtest=PublicDisplayIdTest,PublicDisplayIdAllocatorTest,MigrationValidationTest test`
+Expected: PASS；并发下无重复编号，迁移在空 H2 测试结构与 PostgreSQL 演示数据库验证通过。
+
+## Task 3: 后端创建写入与展示 DTO 收口
+
+**Files:**
+- Modify: 各展示实体的 Mapper/Service/Controller/DTO，按 Task 1 清单逐项列出
+- Modify: `backend/src/main/java/com/danyang/match/platform/matchmaker/mapper/MatchmakerContactAuthorizationMapper.java`
+- Modify: `backend/src/main/java/com/danyang/match/platform/matchmaker/service/ContactAuthorizationService.java`
+- Modify: `backend/src/main/java/com/danyang/match/platform/matchmaker/service/MatchmakerManagementService.java`
+- Modify: 活动、审核、举报、审计、转介等清单中 Mapper 查询和响应 DTO
+- Create: `backend/src/test/java/com/danyang/match/platform/shared/id/PublicDisplayIdResponseTest.java`
+- Modify: 对应领域测试与 `backend/src/test/resources/schema-h2.sql`
+
+- [ ] **Step 1: 为创建流程写回归测试**
+
+对每类清单实体调用真实 Service 创建入口，断言同事务持久化 UUID 主键和正确前缀的公开编号；模拟编号分配失败，断言领域实体未写入。用户和工作人员 API 输出同时断言 `id` 仍为既有 UUID、`displayNumber/displayId` 是业务编号。
+
+- [ ] **Step 2: 运行测试确认失败**
+
+Run: `cd backend; mvn -Dtest=PublicDisplayIdResponseTest,MatchmakerContactAuthorizationTest,MatchmakerManagementReadTest test`
+Expected: 新增编号断言失败，既有权限测试保持可执行。
+
+- [ ] **Step 3: 接入创建事务与关联编号查询**
+
+对每个实体创建 Service，在已有 `@Transactional` 中先分配编号再 insert；操作员编号依实际角色用 `HN/GL`。Mapper 查询只额外 JOIN 公开编号字段；DTO 增加语义明确的 `displayId`/`displayNumber` 和关联对象 `operatorDisplayId`、`userDisplayNumber`、`targetUserDisplayNumber`。contact authorization 不再把底层 `operatorId/userId` 作为展示字段使用。
+
+推荐对象、被举报人、活动参与者和审核对象关联到 user profile 时，复用 `users.display_number`；查询必须保留现有数据范围、用户隐私白名单和防探测条件。列表只补展示字段，不扩大查询可见范围。
+
+- [ ] **Step 4: 检查未覆盖 API 和 UUID 响应泄漏**
+
+运行后端静态覆盖测试和针对 Controller JSON 的响应断言；确认审计记录实体引用只在有权限且可映射时返回业务编号，否则返回实体类型脱敏说明。搜索所有列表 DTO 对 UUID 的输出使用，逐项按清单修复，不修改内部写请求。
+
+- [ ] **Step 5: 运行相关后端回归**
+
+Run: `cd backend; mvn -Dtest=PublicDisplayId*,MatchmakerContactAuthorizationTest,MatchmakerAssignmentA1Test,MatchmakerManagementReadTest,Activity*,Review*,Report*,MigrationValidationTest test`
+Expected: PASS；既有权限、事务、隐藏/软删除与错误语义不变。
+
+## Task 4: 管理端只展示业务编号
+
+**Files:**
+- Modify: `admin-web/src/modules/matchmaker/MatchmakerManagementView.vue`
+- Modify: `admin-web/src/modules/activity/ActivityInterestView.vue`
+- Modify: `admin-web/src/modules/activity/ActivityCheckinView.vue`
+- Modify: `admin-web/src/modules/operator/OperatorManagementView.vue`
+- Modify: `admin-web/src/modules/audit/AuditLogView.vue`
+- Modify: Task 1 清单识别的用户、举报、安全、审核、报名、活动、联系授权、转介等视图
+- Modify: 对应 API 类型定义与 service adapter
+- Modify: `tests/public-id-display-coverage.cjs`
+
+- [ ] **Step 1: 为目标页面写展示行为测试**
+
+使用虚拟 API fixture 分别提供 UUID 与展示编号；渲染断言应见 `HN...`、`YH...`、`HD...`、`RW...` 等展示编号且不见 UUID，点击详情/审批/筛选后请求仍携带原内部 UUID。
+
+- [ ] **Step 2: 修复模板和交互控件**
+
+表格/详情使用 DTO 的公开编号字段；推荐对象输入改为可搜索用户选择器，按公开用户编号和允许公开的基础资料搜索，提交时仍传选中对象内部 UUID。若缺展示编号，展示“编号待生成”并在接口测试中判为缺陷，不允许回退 UUID。
+
+- [ ] **Step 3: 更新覆盖守卫并运行管理端检查**
+
+Run: `cd admin-web; pnpm run type-check; pnpm run build; cd ..; node tests/public-id-display-coverage.cjs`
+Expected: 类型检查、构建和 ID 展示守卫 PASS。
+
+## Task 5: 小程序只展示业务编号
+
+**Files:**
+- Modify: Task 1 清单中用户卡片、活动详情/报名/签到、红娘工作台/服务详情/推荐进展、举报与安全、个人资料/认证等页面
+- Modify: 必要的 `miniapp/services/*.js` response adapter
+- Modify: `miniapp/types/index.ts` 与 `miniapp/types/index.d.ts` 的展示字段
+- Create: `tests/miniapp/public_id_display_behavior_test.cjs`
+- Modify: `tests/public-id-display-coverage.cjs`
+
+- [ ] **Step 1: 写小程序字段展示失败测试**
+
+使用接口响应 fixture 注入 `id/userId/targetUserId` UUID 和对应 `displayId/displayNumber`，断言 WXML 页面绑定展示字段、服务跳转和 Like/Pass/报名/举报动作仍提交 UUID；无展示编号时不把 UUID 作为空态回退值。
+
+- [ ] **Step 2: 修正响应类型和页面绑定**
+
+更新 TS 声明和各页面 WXML/JS，让列表、详情、确认弹窗、活动页面和举报确认中的公开文本只用业务编号；保留内部 ID 用于请求和路由。
+
+- [ ] **Step 3: 运行小程序行为与结构检查**
+
+Run: `node tests/miniapp/public_id_display_behavior_test.cjs; node tests/public-id-display-coverage.cjs; pnpm --dir miniapp run type-check`
+Expected: PASS；另运行项目现有 WXML/WXSS 结构守卫和 matchmaker/活动相关测试。
+
+## Task 6: 全量迁移、运行验收和文档证据
+
+**Files:**
+- Modify: `docs/DEMO-VALIDATION-2026-10-13.md`
+- Modify: `docs/STATUS.md`
+- Inspect: `infrastructure/docker-compose.yml`、运行中的 danyang Docker 服务
+
+- [ ] **Step 1: 执行完整后端测试及迁移检查**
+
+Run: `cd backend; mvn test`
+Expected: 记录总数、失败、错误、跳过；全部失败/错误为 0。PostgreSQL 演示库迁移完成，检查每表编号无空值、无重复、长度正确，用户奇偶规则正确，计数器不小于已分配最大尾号。
+
+- [ ] **Step 2: 执行 Web、小程序回归**
+
+Run: `cd admin-web; pnpm run type-check; pnpm run build; cd ..; pnpm --dir miniapp run type-check; node tests/public-id-display-coverage.cjs`
+Expected: 全部 PASS；执行现有小程序结构与相关行为测试。
+
+- [ ] **Step 3: 演示环境 HTTP 和页面检查**
+
+以演示账号读取联系授权、红娘服务/推荐、用户、活动、审核、举报接口，逐类抽查 UUID 与业务编号关系；确认权限拒绝样本仍拒绝。检查浏览器常用视图及微信开发者工具小程序核心页，页面无 UUID 可见文本，动作正常。
+
+- [ ] **Step 4: 记录证据并完成阶段报告**
+
+在 `docs/DEMO-VALIDATION-2026-10-13.md` 追加编号格式、各类数量、重复检测、旧号映射、测试输出摘要和目视验收结果；在 `docs/STATUS.md` 仅追加当前结论，不覆盖历史状态。运行 `git diff --check`，最终报告逐项 `PASS/PARTIAL/FAIL/NOT_VERIFIED`。
+
+## 完成门禁
+
+- 六个任务均有实现与独立测试证据；不得因前端隐藏列而遗漏后端公开 DTO。
+- 演示 PostgreSQL 中公开编号检查 SQL 返回 0 空值（仅规格明确允许的未实名用户可空）、0 重复、0 格式错误。
+- 联系授权截图展示 `HN...` 与 `YH...`；跨模块推荐、举报和活动同一用户编号相同。
+- 所有 UUID 保留作内部键但不出现在面向用户的可见文本、导出或通知。
+- 若既有客户端依赖公开 UUID 字段作为用户输入，应提供公开编号解析适配并做兼容测试；权限判断仍基于解析后的 UUID。
+- 最终说明未执行的微信真机验收或不可执行测试，不将历史测试结果写成本轮证据。

docs/superpowers/plans/2026-10-15-next-phase-validation-roadmap.md

@@ -0,0 +1,131 @@
+# V1.1 下一阶段验证与发布准备计划
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 在现有微信真机、前端门禁和后端 916 项全量测试通过的基础上，补齐真实数据库并发、完整业务闭环、通知数据一致性和发布前冒烟验证。
+
+**Architecture:** 保持模块化单体和 PostgreSQL Source of Truth。测试分为 H2 单元/集成测试、Docker PostgreSQL 真实数据库测试、运行中服务冒烟和人工 UAT 四层，任何一层的结果独立记录，不互相替代。
+
+**Tech Stack:** Java 21、Spring Boot 3、Maven、PostgreSQL、Docker Compose、Vue 3、微信原生小程序、Edge。
+
+**Spec:** `docs/善缘丹阳 V1.1 客户需求基线增量开发与修复计划.md`、`docs/善缘丹阳 V1.1 数据库与API增量设计.md`、`docs/STATUS.md`。
+
+## Global Constraints
+
+- 不清理、回滚或覆盖现有未提交改动。
+- 不修改已通过真机验收的业务流程，除非新增验证复现出根因。
+- PostgreSQL 是 Source of Truth；H2 只用于快速测试，不能替代真实数据库证据。
+- Maven 测试容器继续使用阿里云镜像和 `--dns 223.5.5.5 --dns 114.114.114.114`，不关闭 TLS 校验。
+- 管理端页面验收使用已安装的 Edge，不安装 Chrome/Chromium。
+- 测试账号、密码和 Token 只通过环境变量注入，不写入仓库和日志。
+
+---
+
+### Task 1: 真实 PostgreSQL 并发测试
+
+**Files:**
+- Inspect: `backend/src/test/java/com/danyang/match/platform/concurrent.ConcurrentTests.java`
+- Modify: `backend/src/test/java/com/danyang/match/platform/concurrent.ConcurrentTests.java`
+- Modify: `backend/src/test/resources/application-test.yml`（仅在测试 profile 需要新增 PostgreSQL 开关时）
+- Test evidence: `.mimosa/postgres-concurrency-test.log`
+
+**Interfaces:**
+- Consumes: Docker Compose PostgreSQL、现有服务层接口和测试数据清理机制。
+- Produces: `CI=true` 下可执行的 Like 并发和活动容量竞争测试；成功数、重复 Match 数和超容量数有数据库查询断言。
+
+- [ ] **Step 1: 复核现有并发测试是否只是内存计数。**
+  - 确认测试使用真实 service/mapper、事务和 PostgreSQL 表，而不是 `AtomicInteger` 结果模拟。
+- [ ] **Step 2: 建立隔离测试数据。**
+  - 每个测试使用唯一 run id；结束时按 run id 删除关系、活动报名和 Match 数据。
+- [ ] **Step 3: 用 Docker PostgreSQL 执行并发测试。**
+  - 命令：`docker compose -f infrastructure/docker-compose.yml up -d postgres`
+  - 命令：`docker run --rm ... mvn -s /tmp/settings.xml -B -Dtest=ConcurrentTests -Denv=postgres test`
+- [ ] **Step 4: 验证边界。**
+  - 断言同一对用户最终最多一个 active Match；活动 approved 数不超过 capacity；失败操作有明确错误码。
+- [ ] **Step 5: 保存报告并更新 `docs/STATUS.md`。**
+
+### Task 2: 完整注册到牵手 E2E
+
+**Files:**
+- Inspect: `backend/src/test/java/com/danyang/match/platform/core/CoreE2ETest.java`
+- Modify: `backend/src/test/java/com/danyang/match/platform/core/CoreE2ETest.java`
+- Test evidence: `.mimosa/core-e2e-postgres-test.log`
+
+**Interfaces:**
+- Consumes: 微信登录模拟 provider、实名认证、资料审核、推荐、Like、双向 Match、聊天和成功牵手服务。
+- Produces: 一个真实 PostgreSQL 事务闭环测试，覆盖状态迁移和关键权限断言。
+
+- [ ] **Step 1: 将 `@Disabled` 占位测试拆成真实步骤。**
+- [ ] **Step 2: 每一步先断言数据库状态，再调用下一步。**
+- [ ] **Step 3: 增加负向断言。**
+  - 未审核资料不能进入推荐；未 Mutual 不能聊天；单方成功牵手确认不能完成。
+- [ ] **Step 4: 在 PostgreSQL profile 执行并保存日志。**
+- [ ] **Step 5: 仅在完整链路通过后移除 `@Disabled`，否则保留并将状态标记为 `NOT_VERIFIED`。**
+
+### Task 3: 通知数据转换告警治理
+
+**Files:**
+- Inspect: `backend/src/main/java/com/danyang/match/platform/notification/mapper/NotificationMapper.java`
+- Inspect: `backend/src/test/java/com/danyang/match/platform/notification/*`
+- Modify: 对应测试夹具或 schema 文件；只有复现业务根因时才修改生产代码。
+- Test evidence: `.mimosa/notification-fixture-test.log`
+
+**Interfaces:**
+- Consumes: `notifications.user_id` 的实际 PostgreSQL/H2 类型和通知 mapper 参数类型。
+- Produces: 不再出现 `u-notif-guard` 这类类型转换告警；通知幂等、落库和查询断言保持通过。
+
+- [ ] **Step 1: 对照 Flyway PostgreSQL schema 和 `schema-h2.sql` 的 user_id 类型。**
+- [ ] **Step 2: 定位夹具使用字符串 ID 的测试用例。**
+- [ ] **Step 3: 优先修正测试夹具为合法 UUID；若业务确实支持非 UUID，再修正 mapper 类型契约。**
+- [ ] **Step 4: 重跑通知相关测试和全量 Maven 测试。**
+- [ ] **Step 5: 在报告中区分“日志告警已消除”和“业务通知真实发送”两种结论。**
+
+### Task 4: 运行中服务发布前冒烟
+
+**Files:**
+- Use: `tests/public-id-web-live.cjs`
+- Use: `tests/admin-dashboard-behavior.cjs`
+- Use: `scripts/miniapp-compile-check.mjs`
+- Create: `.mimosa/release-smoke-20261015.log`
+- Update: `docs/STATUS.md`
+
+**Interfaces:**
+- Consumes: Docker 中运行的 backend、PostgreSQL、Redis、nginx、admin-web；Edge 浏览器。
+- Produces: 登录、首页统计、红娘服务、联系授权审批、公开编号、未登录 401、关键页面导航的可复现结果。
+
+- [ ] **Step 1: 备份演示库并记录 Flyway 版本。**
+- [ ] **Step 2: 重启整套 Docker 服务并检查健康端点。**
+- [ ] **Step 3: 用 Edge 执行管理端页面验收。**
+- [ ] **Step 4: 执行 API 冒烟并记录状态码、响应 success/code，不记录 Token。**
+- [ ] **Step 5: 验证服务重启后登录、编号查询和工作台统计仍可用。**
+
+### Task 5: 用户 UAT 与发布决策
+
+**Files:**
+- Use: `docs/STATUS.md`
+- Use: `docs/PENDING_DECISIONS.md`
+- Create: `docs/RELEASE-READINESS-2026-10-15.md`
+
+**Interfaces:**
+- Consumes: 微信真机复验、Edge 管理端冒烟、后端和前端测试报告。
+- Produces: `GO`、`CONDITIONAL GO` 或 `NO-GO` 决策，以及剩余 P0/P1 清单。
+
+- [ ] **Step 1: 由用户在微信开发者工具复验红娘登录、工作台、服务详情、跟进、完成服务、联系授权审批。**
+- [ ] **Step 2: 使用演示数据走一遍用户确认服务 → 管理端完成服务 → 统计回写闭环。**
+- [ ] **Step 3: 核对首页数字是否来自接口，而非静态展示。**
+- [ ] **Step 4: 记录未完成项：第三方开放、限流阈值、真实微信支付/实名服务等范围外能力继续保持 `NOT_IMPLEMENTED` 或 `NOT_VERIFIED`。**
+- [ ] **Step 5: 形成发布决策；没有真实 PostgreSQL 并发和完整 E2E 证据时不得给出正式生产 GO。**
+
+## 暂不执行的范围
+
+- 不实现第三方 API Key/OAuth、开放 OpenAPI、调用配额或新的支付能力；这些属于已登记的范围扩张决策。
+- 不安装 Chrome/Chromium，不用浏览器替代微信真机验收。
+- 不进行大规模重构、分支清理或未授权数据库数据改写。
+
+## 推荐执行顺序
+
+1. Task 3（先消除测试夹具告警）
+2. Task 1（真实 PostgreSQL 并发）
+3. Task 2（完整 E2E）
+4. Task 4（运行中服务冒烟）
+5. Task 5（用户 UAT 与发布决策）

docs/superpowers/plans/2026-10-15-release-readiness-execution.md

@@ -0,0 +1,124 @@
+# V1.1 可发布条件实施计划
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 在不扩大业务范围的前提下，完成丹阳公益婚恋平台 V1.1 的发布前验证，并输出可复现的 `GO`、`CONDITIONAL GO` 或 `NO-GO` 决策。
+
+**Architecture:** 保持模块化单体、PostgreSQL Source of Truth 和现有 Docker Compose。验证分为代码测试、真实 PostgreSQL、运行中服务、人工 UAT、运维发布五层；任一层的结果不替代其他层。
+
+**Tech Stack:** Java 21、Spring Boot 3、PostgreSQL 16、Redis、Docker Compose、Vue 3、微信原生小程序、Edge、Maven 阿里云镜像。
+
+**Spec:** `docs/superpowers/plans/2026-10-15-next-phase-validation-roadmap.md`、`docs/STATUS.md`、`AGENTS.md`。
+
+## Global Constraints
+
+- 不清理、回滚或覆盖现有未提交修改。
+- 不把 H2、内存模拟、Mock 微信或演示 Seed 结果写成生产验收证据。
+- 不安装 Chrome/Chromium；管理端使用 Edge。
+- 测试账号、密码、Token 只通过环境变量注入，不写入仓库或日志。
+- 不修改生产业务逻辑，除非真实验证复现出根因并完成回归测试。
+- 不执行不可逆数据库清理；所有演示数据操作前先备份。
+
+---
+
+### Task 1：发布基线与环境确认
+
+**Files:**
+- Inspect: `git status`、`infrastructure/docker-compose.yml`、`.env.example`、`docs/PENDING_DECISIONS.md`
+- Create: `.mimosa/release-baseline-20261015.log`
+- Modify: `docs/STATUS.md`
+
+**Interfaces:**
+- Produces：当前提交/工作区、Flyway 版本、容器健康状态、配置缺口清单。
+
+- [ ] 检查工作区，不修改既有未提交文件。
+- [ ] 检查 `.env` 必需变量是否存在，仅输出变量名，不输出值。
+- [ ] 启动或复用完整 Docker 演示栈，确认 PostgreSQL、Redis、后端、管理端、Nginx 健康。
+- [ ] 备份演示数据库并记录 Flyway 版本。
+- [ ] 将缺失项分为代码可执行项和必须由用户/运营提供的条件。
+
+验收：环境健康、备份文件存在、无敏感值进入日志。
+
+### Task 2：真实 PostgreSQL 并发门禁
+
+**Files:**
+- Inspect/Modify：`backend/src/test/java/com/danyang/match/platform/concurrent.ConcurrentTests.java`
+- Inspect/Modify：`backend/src/test/resources/application-test.yml`
+- Create：`.mimosa/postgres-concurrency-test.log`
+
+**Interfaces:**
+- Consumes：隔离 PostgreSQL 数据库、真实 Service/Mapper。
+- Produces：Like 并发无重复 active Match；活动报名/审核不超过容量；失败有明确业务错误。
+
+- [ ] 为每次测试生成唯一 run id 和隔离用户/活动数据。
+- [ ] 将内存 `AtomicInteger` 模拟替换为真实 Service/Mapper 调用。
+- [ ] 执行同一目标的并发 Like 和超容量活动报名/审核。
+- [ ] 查询 PostgreSQL 结果，断言重复 Match 为 0、approved 数不超过 capacity。
+- [ ] 清理本次 run id 数据并保留日志。
+
+验收：真实 PostgreSQL 测试通过；否则标记 `NOT_VERIFIED`，不得给正式生产 GO。
+
+### Task 3：完整业务闭环 E2E
+
+**Files:**
+- Inspect/Modify：`backend/src/test/java/com/danyang/match/platform/core/CoreE2ETest.java`
+- Create：`.mimosa/core-e2e-postgres-test.log`
+
+**Interfaces:**
+- Consumes：微信 Mock Provider、实名/资料审核、推荐、Like、双向 Match、聊天、牵手服务。
+- Produces：真实 PostgreSQL 下可复现的注册到牵手闭环和负向权限断言。
+
+- [ ] 拆解现有 `@Disabled` 占位测试。
+- [ ] 每个步骤先查询数据库状态，再进入下一步。
+- [ ] 增加未审核资料不能推荐、未 Mutual 不能聊天、单方确认不能完成的负向断言。
+- [ ] 在隔离 PostgreSQL 数据库执行并保存日志。
+- [ ] 只有完整链路通过才移除 `@Disabled`；否则保留并标记 `NOT_VERIFIED`。
+
+验收：主流程和负向流程均通过。
+
+### Task 4：运行中服务与前端发布冒烟
+
+**Files:**
+- Use：`tests/public-id-web-live.cjs`
+- Use：`tests/admin-dashboard-behavior.cjs`
+- Use：`scripts/miniapp-compile-check.mjs`
+- Create：`.mimosa/release-smoke-20261015.log`
+- Modify：`docs/STATUS.md`
+
+**Interfaces:**
+- Consumes：完整 Docker 栈、Edge、微信开发者工具。
+- Produces：登录、工作台、红娘服务、授权审批、公开编号、401、重启恢复证据。
+
+- [ ] 执行后端健康、管理端 `/admin/`、未登录 401 和公开编号 API 冒烟。
+- [ ] 用 Edge 验证管理端登录、工作台统计、红娘服务、服务详情、跟进、完成服务、联系授权审批。
+- [ ] 用演示数据走用户确认服务到管理端完成服务的闭环，核对统计回写。
+- [ ] 重启后端和前端服务，重复登录、工作台和编号查询。
+- [ ] 运行小程序编译检查并由用户在微信开发者工具/真机完成红娘端关键路径复验。
+
+验收：核心页面、接口和重启恢复均通过。
+
+### Task 5：生产配置、备份恢复和人工发布条件
+
+**Files:**
+- Inspect：`infrastructure/docker-compose.prod.yml`、`infrastructure/scripts/backup.sh`、`infrastructure/scripts/restore.sh`、`docs/legal/privacy-policy.md`、`docs/security/PIA.md`
+- Create：`docs/RELEASE-READINESS-2026-10-15.md`
+- Modify：`docs/STATUS.md`
+
+**Interfaces:**
+- Produces：发布条件矩阵、剩余 P0/P1、最终 `GO/CONDITIONAL GO/NO-GO`。
+
+- [ ] 验证生产配置关闭 Mock 微信、演示 Seed、Debug、Swagger，并使用注入密钥。
+- [ ] 执行加密备份和干净环境恢复演练，记录数据库校验结果。
+- [ ] 验证 HTTPS、域名、监控、日志、回滚目标和端口暴露。
+- [ ] 核对隐私政策法务确认、微信小程序审核、运营真实内容和待决策项。
+- [ ] 形成发布决策：全部 P0 通过才允许 `GO`；有人工条件未完成则 `CONDITIONAL GO`；真实数据库/E2E/安全门禁缺失则 `NO-GO`。
+
+验收：发布报告包含每项证据、负责人、阻塞原因和下一步。
+
+## 执行顺序
+
+1. Task 1：基线和环境
+2. Task 2：真实 PostgreSQL 并发
+3. Task 3：完整 PostgreSQL E2E
+4. Task 4：运行中服务和人工验收
+5. Task 5：生产门禁和发布决策