WorkBuddy
3c2b967274
5.9 KiB
爱在丹阳三端演示收口执行计划
执行方式：在当前会话按 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。
- 核对当前 Docker 容器、Compose 项目和运行端口，确认实际提供 /admin/ 的服务。
- 比对运行服务与本地最新构建的 Logo、CSS；发现旧镜像后重建并仅更新管理端服务。
- 检查 Logo 请求 HTTP 200、PNG 类型及透明通道；核对页面使用最新资源。
- 在 1366×768 和 1920×1080 检查登录页、顶部栏、展开/折叠侧栏：无方形底色、主体完整、对齐正常（待用户在浏览器完成目视确认）。
- 保存请求、容器文件哈希和构建证据。既有背景 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/；报告记录抽样结果。
- 从现有数据选定一名红娘、两名服务用户和一名审批操作员，使用脱敏编号建立验收记录。
- 对比管理端接口与红娘工作台接口的展示编号、姓名、服务状态和分配关系；
/operator/matchmaker/assignments/my已在代码中正确使用。 - 核对用户、红娘、管理员等对外展示编号的长度、格式、唯一性；当前演示账号和 12 个演示用户展示编号均为 12 位且唯一。
- 核对工作台顶部统计改为服务记录实时计算；当前管理范围实测为今日 2 单、待处理 3 单。
- 待审核资料改为审核统计接口
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、备份恢复及正式上线检查不能用演示数据验证代替。本计划不包含未批准的死代码退役或全项目重构。