danyang-match/docs/善缘丹阳 V1.1 客户需求基线增量开发与修复计划.md

善缘丹阳 V1.1 客户需求基线增量开发与修复 Implementation Plan

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: 在保留已经验证正确的 V1.0 婚恋核心和 V1.1 数据资产的前提下，依据客户最新修订文档修复当前伪完成、权限越界、前端不可用和业务闭环缺失问题，交付可测试、可运营、可回滚的善缘丹阳 V1.1。

Architecture: 继续使用 Java 21 + Spring Boot 模块化单体、PostgreSQL、Redis、私有对象存储、Vue 3 统一运营后台和微信原生 TypeScript 小程序。V1.1 是 V1.0 的增量升级，不新建第二套系统；正确模块 KEEP，缺少能力 EXTEND/ADD，错误首页和活动互选逻辑 REPLACE/REFACTOR。

Tech Stack: Java 21、Spring Boot 3.x、Spring Security、MyBatis-Plus、Flyway、PostgreSQL、Redis、WebSocket、S3-Compatible Private Object Storage、Vue 3、TypeScript、Vite、Pinia、Element Plus、微信原生小程序、Docker Compose、Nginx。

Spec: docs/善缘丹阳 V1.1 Codex最终主启动提示词（整合版）.md、docs/善缘丹阳 V1.1 前端 UI-UX 高保真原型修订说明.md、docs/善缘丹阳 V1.1 数据库与API增量设计.md、docs/善缘丹阳 V1.1 页面级功能清单与交互流程修订版.md、docs/善缘丹阳 V1.1 Codex 开发执行计划修订版.md、docs/善缘丹阳 V1.1 Codex-Jira 最终开发任务增量清单.md。

Global Constraints

• 这六份客户修订文档共同构成 V1.1 需求基线，不能以其中一份覆盖其余文档的专业域要求。
• 主启动提示词负责执行纪律和不变量；页面清单负责功能与交互；UI/UX 文档负责视觉和状态；数据库/API 文档负责数据契约；执行计划和 Jira 增量清单负责 Phase、任务与依赖。
• 文档中的“✅、已完成、已部署、MVP完成”属于历史进度声明，不属于客户需求；必须由当前代码、自动化测试和人工流程重新证明。
• V1.0 正确核心按 KEEP 处理，不重新开发；但每个受影响 Phase 必须执行回归门禁。
• V001～V027 已应用迁移不得改写；数据结构修复只能新增向前迁移。
• 用户基础婚恋服务永久免费；不增加支付、会员、金币、礼物、付费曝光或商业广告。
• Required 不自动放宽；普通婚恋 Mutual 后才能聊天；Block 优先级最高；红娘不得替用户 Like 或确认。
• 活动互选必须经过双方分别确认开启沟通，再复用或创建 Match Episode 和 Conversation。
• 本地资格独立于实名认证；咨询独立于红娘；所有新业务复用统一 User、Operator、RBAC、DataScope、Audit、Notification、Risk 和 Object Storage。
• 首页结构、8 个核心入口及其顺序固定；底部导航固定为首页、找对象、消息、活动、我的。
• 用户端采用 #E96B6B 品牌 Token、#FAFAF8 暖白背景、16px 水平边距、44×44px 最小点击区；禁止页面散落硬编码颜色。
• 所有未确认参数配置化；Feature Flag 仅用于灰度和故障关闭，不能把已确认的 V1.1 正式范围降为“以后再做”。
• 单智能体执行时按 Phase 01、02、03……13、13A、14……26 顺序；每个 Phase 输出 Completion Report 后停止。

---

一、对上一版计划的纠正

上一版计划的主要错误不是发现的问题失实，而是处理策略失实：

1. 错误地把主启动提示词当成单一产品规格；正确做法是六份客户修订文档共同约束。
2. 错误地把 V1.0 Phase 01～26 当成全部需要重建；客户文档明确要求“保留主结构、增量修订、不重建全部 Backlog”。
3. 错误地把“未重新验证”统一判成“未完成”；正确做法是 KEEP 项快速回归，只有失败项才进入修复。
4. 错误地声称 U49～U64 全部缺失；实际 U55～U59、U62～U63 已有页面文件，但类型检查和运行链路尚未通过；明确缺失的是 U49～U54、U60、U61、U64。
5. 没有充分区分“数据库已建表”“后端有骨架”“前端可操作”“业务闭环可验收”四种进度。
6. 没有把 Jira/STATUS/PENDING_DECISIONS 中未经验证的 ✅ 当作待清理的项目治理问题。

本计划因此采用：增量恢复 + 纵向闭环 + 证据驱动状态，而不是全项目推倒重来。

二、当前真实进度基线

2.1 已有资产

• V001～V027 迁移文件及对应的 V1.1 表、字段、角色和种子数据已经存在。
• Backend 已有 home、local_eligibility、service_appointment、counseling、content、service_program、activity_mutual 等模块骨架。
• Miniapp 已有 U55～U59、U62～U63 及活动互选结果/等待页面文件。
• Admin Web 已有 Banner、Content、Service Station、Appointment、Program、Counseling、Referral 等 Vue 文件。
• V1.0 Auth、Profile、Review、Match、Like/Block、Messaging、Relationship、Matchmaker、Activity、Risk、Appeal 模块可作为 KEEP 候选。

2.2 不能算作完成的证据

• Admin Web npm run type-check 当前失败：CounselingView.vue 存在语法错误；路由文件未注册 counseling 页面。
• Miniapp TypeScript 当前有 20 余个错误，且 .ts/.js 双轨并存，不能证明运行的是客户修订版本。
• U49 公益服务中心、U50 服务站、U51 预约、U52 我的预约、U53 课堂、U54 内容详情、U60 反诈、U61 专项服务、U64 服务记录没有注册为可访问页面。
• /api/v1/operator/** 当前只统一检查 operator_login，不能满足 Permission + DataScope + Sensitive Permission。
• 用户预约创建仍可从请求体接受 userId，存在替他人创建/越权风险。
• Counseling 的 operator 接口位于 /counseling/services/operator/**，不受现有 /operator/** 过滤规则覆盖。
• Activity Mutual 代码只检测 active Match，没有形成“双方确认后复用/新建 Match Episode + Conversation”的完整事务。
• E2E 文件大量使用 pass，不能证明功能通过；Jira 中相应 ✅ 必须回退为待验证。
• docs/PENDING_DECISIONS.md 同时存在“待确认”与“已部署”矛盾，且包含测试默认账号和密码描述，需清理。

2.3 分层进度估算

层级	当前估算	说明
V1.0 核心资产	70%～85%	代码较完整，但需受影响回归
V1.1 数据模型/迁移	80%～90%	迁移齐全，仍需约束、权限和回滚验证
V1.1 后端业务闭环	35%～50%	多数有骨架，主体、权限、事务和真实聚合不足
V1.1 小程序页面闭环	25%～35%	部分页面存在，缺页、未注册、TS/JS 漂移明显
V1.1 运营后台闭环	20%～30%	文件存在但类型检查失败、路由/权限/交互不完整
自动化测试可信度	10%～20%	大量空壳、fixture 缺失，无法支撑完成声明
发布就绪度	10%～15%	无可信系统测试、UAT、备份恢复和回滚证据

综合开发资产约 45%～55%，可验收业务闭环约 30%～35%。后续进度只按“验收项通过数”计算，不再按文件数量计算。

三、修复策略与执行门禁

3.1 Phase 状态定义

• KEEP-VERIFY：不改业务设计，只跑回归；通过即可关闭。
• EXTEND：保留现有实现，补客户新增能力和测试。
• REFACTOR：保留数据资产，替换错误业务流程或权限边界。
• REPLACE：删除旧运行入口，只保留客户定稿实现。
• ADD：补齐不存在的页面、接口或运营闭环。

3.2 每 Phase 的统一完成证据

• 关联 Jira 任务状态与实际代码一致，禁止仅凭文件存在勾选 ✅。
• Backend 单元/集成测试通过；Admin type-check/build 通过；涉及 Miniapp 时 TypeScript 检查和开发者工具构建通过。
• 新增/修改 POST 的身份主体、幂等、并发和状态机测试通过。
• Permission、DataScope、Sensitive Access 负向用例返回 401/403/404，不能返回脱敏后的 200 冒充拒绝。
• 受影响业务至少完成一条真实 happy path 和一条失败路径人工验证。
• 更新 STATUS、JIRA_BACKLOG、API/数据库/UI 文档以及对应 Completion Report。
• 输出报告并停止，不自动进入下一 Phase。

四、按客户正式 Phase 的增量开发与修复计划

Phase 01：项目治理与可重复构建基线 — EXTEND

Files: AGENTS.md、docs/STATUS.md、docs/PENDING_DECISIONS.md、docs/JIRA_BACKLOG.md、docs/V1_0_TO_V1_1_GAP_ANALYSIS.md、docs/ARCHITECTURE_BASELINE_V1.1.md、README.md、backend/pom.xml、admin-web/package.json、miniapp/project.config.json。

• 将六份客户修订文档登记为共同需求基线，并按专业域定义冲突裁决规则。
• 把未经验证的“已完成/已部署”改为 待验证、部分完成 或 失败；保留历史说明，不伪造完成记录。
• 清除文档中的默认账号密码；测试账号改由本地 seed/环境变量生成且不进入交付文档。
• 建立 Windows PowerShell 与 Bash 两套一键检查入口，覆盖 backend test、admin type-check/build、miniapp type-check、E2E。
• 修复或重新初始化 Git 元数据问题；若无法恢复，记录仓库来源、当前文件清单和后续提交策略，不擅自覆盖用户文件。（当前无法恢复，已记录并等待用户决定）
• 生成 Phase 01 Completion Report 后停止。

Gate: 三端检查命令可重复启动并给出真实成功/失败；项目状态文件不再互相矛盾。

Phase 02：统一认证、RBAC、DataScope 与敏感访问 — REFACTOR

Files: backend/src/main/java/com/danyang/match/platform/shared/filter/PermissionFilter.java、permission/**、security/**、audit/**、V015 后续新迁移、admin-web/src/stores/auth.ts、admin-web/src/router/index.ts。

• 先写角色×资源×动作×数据范围矩阵测试，覆盖 counselor、counseling_manager、content_editor、service_station_operator。
• 用明确的用户 Principal 和 Operator Principal 替代各 Controller 自行解析 token/userId。
• 移除 /operator/** → operator_login 粗粒度授权，改为接口 Permission + Service DataScope 双重校验。
• 把当前不在 /operator/** 下的运营接口统一迁移或施加同等级方法权限。
• 验证 ContentEditor 无用户婚恋数据权限、Counselor 仅 Assigned、ServiceStationOperator 仅站点/任务范围、Organization 关系不继承权限。

Gate: 权限正向用例通过，四类越权负向用例全部被服务端拒绝并写审计；前端菜单隐藏仅作为体验，不作为安全控制。

Phase 03：实名认证增量预留 — EXTEND

Files: verification 模块、miniapp/pages/verification/**、FeatureFlag 配置。

• 验证 V1.0 实名、年龄、加密/hash 和状态流转回归。
• 保留 liveness/provider/verification_level 预留；人脸首发未确认前不实现自研识别、不保存 face embedding。
• 删除任何“官方婚姻状态认证、100%真实”的前端文案。

Gate: 实名状态来自数据库而非首页硬编码；人脸 Flag 关闭时流程可正常完成。

Phase 04：Profile、Preference 与本地资格 — EXTEND

Files: local_eligibility/**、profile/status/capability 服务、miniapp/pages/local-eligibility/**、miniapp/pages/local-eligibility-supplement/**。

• 保留 V1.0 Profile/Preference，补齐本地资格声明、按需补证、提交、状态查询和 /me/status。
• 用户 API 的 userId 只能来自认证主体；佐证文件进入私有存储，先鉴权再签名。
• 将本地资格佐证触发规则、数量、大小、类型和保留期限全部配置化。
• 把 U62/U63 接入首次准入与“我的”，并覆盖未提交、声明完成、待补充、审核中、已核验、未通过状态。

Gate: 本地资格与身份表独立；非本人和无特殊权限人员不能读取佐证。

Phase 05：统一审核扩展 — EXTEND

Files: review 模块、local eligibility service、admin-web/src/modules/review/ReviewView.vue。

• 复用现有 ReviewTask，增加 local_eligibility 类型，不建第二套审核引擎。
• 验证 Claim 原子性、Need Evidence、Approve、Reject 与本地资格状态联动。
• 每次查看敏感佐证记录 purpose、operator、target、timestamp、result。

Gate: 两名审核员不能同时 claim；审核通过/拒绝与前台状态一致。

Phase 06：Match Eligibility 增量 — KEEP/EXTEND

Files: match/service/MatchEligibilityService.java、RecommendationEngineService.java、对应测试。

• 先跑 V1.0 双向 Required、Block、Paused、Successful 和隐私回归，不重写正确算法。
• 仅在配置要求时把本地资格接入 eligibility；不得自动放宽 Required。
• 确认首页推荐仍调用正式 Match Engine，推荐数量、阈值、冷却均配置化。

Gate: 双方任一 Required 不满足时永不入选；前台不显示数字匹配率。

Phase 07：V1.1 首页唯一实现 + 找对象 — REPLACE

Files: home/**、banner 读取服务、miniapp/pages/index/**、miniapp/pages/discover/**、首页组件、miniapp/app.json、Design Token。

• 为 HomeApplicationService 写聚合契约测试，确保它调用正式 status、match、activity、location、content、capability 服务，不复制规则。
• 修复硬编码 verified、空 recommendations/articles、固定服务站和错误入口路由。
• 固定首页顺序：品牌、状态、Banner、8 入口、推荐、公益服务、活动、服务站、课堂、安全提醒。
• 固定 8 入口顺序并分别路由到真实页面；未开放时展示服务端 Capability 返回的 Disabled 原因。
• 统一 TypeScript 为唯一源，配置小程序 TypeScript 编译；移除同页手写 .ts/.js 逻辑漂移。
• 落实未登录、未实名、审核中、Searching、Paused、Successful、空数据、网络错误、Skeleton 状态矩阵。
• 迁移完成后删除旧首页运行逻辑，不保留 /home-old。

Gate: 首页 5 秒识别品牌和主要入口；Banner 仅内部目标；首页真实聚合数据可用；小程序 TS 检查和开发者工具构建通过。

Phase 08：Like / Match / Block — KEEP-VERIFY/EXTEND

Files: relationship 模块、discover/relationship 页面和对应测试。

• 验证 Like、Pass、普通 Mutual、Unmatch、Block 全链路。
• 增加 Activity Match Episode 兼容，不改变普通 Match 的双向 Like 规则。
• 验证 Block 后推荐排除、搜索不可见、聊天停止且无法由缓存绕过。

Gate: V1.0 核心回归通过；活动来源兼容不会创建第二套 Match 逻辑。

Phase 09：Text Chat — KEEP-VERIFY/EXTEND

Files: messaging/**、WebSocket 配置、Miniapp messages/chat 页面。

• 验证 REST send + WebSocket receive、消息幂等、重连和未读计数。
• 验证非 active Match 禁聊，Unmatch/Block 后即时禁聊。
• 让活动双确认产生的 Conversation 复用同一消息体系。

Gate: 未 Mutual 或活动未双确认时不能发消息；正常会话不重复投递。

Phase 10：Image & Chat Safety — KEEP-VERIFY

Files: photo 模块、message safety、对象存储配置和聊天页面。

• 验证图片私有访问、类型/大小校验、审核和水印。
• 验证风险识别、举报入口和违规内容处理。
• 检查日志不记录聊天正文、身份证、手机号或签名 URL。

Gate: 越权图片访问被拒绝，敏感内容不进入普通日志。

Phase 11：Notification — EXTEND

Files: notification/**、预约/咨询/资格/活动服务及通知页面。

• 新增预约、咨询、辅导、本地资格和活动双确认通知。
• 统一在业务事务提交后发送，发送失败不回滚核心事实。
• 锁屏和通知摘要使用隐私安全文案，不泄露咨询主题或单向意向。

Gate: 回滚事务不发通知；已提交事务通知失败可重试且不产生重复业务记录。

Phase 12：Relationship Progress — KEEP-VERIFY/EXTEND

Files: relationship 状态服务、Match Episode、relationship-status 页面。

• 验证成功关系双确认、恢复/退出、历史 Episode 和并发确认。
• 补充 getting_to_know 阶段的婚前辅导入口引导。
• 验证工作人员不能替用户确认成功关系。

Gate: 单方确认不改变最终关系；历史 Episode 可追踪但不会恢复旧聊天权限。

Phase 13：公益红娘转介 — EXTEND

Files: matchmaker/**、referral/**、Miniapp 红娘页面、Admin referral 页面。

• 保留红娘服务和人工推荐；验证任何工作人员不能替用户 Like。
• 补齐转介咨询、活动、服务站的用户同意、来源追踪和状态记录。
• 红娘只能看转介状态和必要摘要，不能读取 counseling followup 正文。

Gate: 转介形成可追踪记录但不越权；用户决定权测试通过。

Phase 13A：婚恋咨询与婚前辅导 — REFACTOR/EXTEND

Files: counseling/**、miniapp/pages/counseling-*、miniapp/pages/my-counseling/**、miniapp/pages/premarital-*、admin-web/src/modules/counseling/CounselingView.vue、router。

• 修复 Admin Vue 语法错误并注册 /counseling 路由，先使 type-check 失败转为通过。
• 用户申请接口从认证主体取 userId；补幂等、取消、详情 owner 校验和合法状态迁移。
• 分配操作使用条件更新/版本号解决并发；Counselor 只能读取和操作 Assigned Service。
• Counseling Manager 可分配和查看必要摘要；普通管理员、红娘、内容编辑不得读取咨询正文。
• 婚前辅导复用 counseling service type；邀请平台内伴侣必须由对方自主确认。
• U55～U59 修复类型错误、API 契约、Loading/Empty/Error/Permission 状态和非医疗化文案。

Gate: 申请→分配→预约→服务→完成→反馈真实闭环通过；所有隐私负向用例通过。

Phase 14：多类型公益活动 — REFACTOR/EXTEND

Files: activity 模块、Miniapp activity 页面、Admin activity 页面。

• 保留活动基础，完成 ActivityType 分类、按类型报名策略、capacity groups 和多组织关系。
• 完成小程序分类 Tabs、类型化卡片、动态资格提示和后台动态表单。
• 验证主办组织关系不自动授予用户库访问权限。

Gate: matchmaking 与课堂/反诈类活动显示和资格策略不同；容量按配置正确扣减。

Phase 15：活动报名、审核与签到 — KEEP-VERIFY/EXTEND

Files: activity registration、checkin 服务和 U29～U32 页面。

• 回归报名、审核、取消、签到码、重复签到和名额并发。
• 增加非 matchmaking 活动和 capacity group 场景测试。
• 服务站操作员只能操作指定活动或站点任务。

Gate: 重复请求和并发报名不超额；签到不可跨活动复用。

Phase 16：活动互选与双方开启沟通确认 — REFACTOR

Files: activity_mutual、relationship、messaging 模块及 activity-mutual 页面。

• 以 activity_user_interests + activity_mutual_connection_consents 为唯一逻辑，废弃 mutual 直接建 Match/Chat 的所有入口。
• 双方确认事务中：已有 active Match 则复用已有会话；历史 Unmatch 则创建新 Episode；无历史则创建 Match 和 Conversation。
• 补 decline、timeout、重复确认幂等、并发确认和单向意向保密测试。

Gate: A 单选 B 时 B 无感知；Mutual 但未双确认时无新 Chat；双确认后 exactly-once 形成正确 Match/Conversation。

Phase 17：举报与风控 — EXTEND

Files: risk、report、referral 模块和后台风险页面。

• 将 counseling、service_station、offline_activity 作为风险来源接入统一 RiskEvent。
• 后台显示必要来源上下文但不暴露无关咨询正文。
• 禁止公开黑名单；举报、处置、Block 与敏感访问继续审计。

Gate: 风险来源可追踪、正文最小可见，低权限人员不能扩大读取范围。

Phase 18：申诉 — KEEP-VERIFY

Files: appeal 模块、Miniapp appeal 页面和后台 AppealCenter。

• 回归 ban/suspend 申诉、幂等处理、审批和解除动作。
• 验证申诉不能绕过仍有效的其他风险处置。
• 是否首发继续由已确认 Feature Flag 控制。

Gate: 申诉通过只解除目标处置；拒绝后原处置保持有效。

Phase 19：统一运营后台 + 用户端公益服务页面 — ADD/REFACTOR

Files: Admin banner/content/service-station/service-appointment/service-program/counseling/referral 模块、MainLayout/router；Miniapp 新增 U49～U54、U60、U61、U64 页面；service API 文件。

• 先修复 Admin 全量 type-check 和角色路由，再实现“角色第一屏知道今天做什么”的待办型工作台。
• Banner 完成 CRUD、排期、排序、Audience、内部 target 校验和预览；禁止外链。
• Content 完成分类、文章编辑、发布/下架；用户端只做文章列表/详情，不做 Feed、评论和点赞。
• Service Station 完成万善公园站信息、开放时间、公告、服务项目和预约管理。
• 修复预约 IDOR：普通用户创建、详情、列表、取消只能操作本人；代登记使用独立 operator 接口和权限。
• Service Program 完成项目、申请、审批、退出和必要统计，禁止把项目成员身份变成用户价值标签。
• 新增并注册 U49 公益服务中心、U50 服务站、U51 预约、U52 我的预约、U53 课堂、U54 内容详情、U60 反诈、U61 专项服务、U64 公益服务记录。
• 重构 U37“我的”四组结构，接入上述新增页面；U64 只显示用户自己的服务时间线，不显示内部备注。
• 所有页面复用统一 Token 和组件，覆盖 Loading、Skeleton、Empty、Error、Permission、Disabled、Responsive。

Gate: 小程序 U01～U64 页面清单无缺页且路由可达；七类后台角色只看到自己的工作；后台 type-check/build 通过。

Phase 20：公益服务 Analytics — EXTEND

Files: analytics 模块、统计查询/事实表后续迁移、Admin Analytics 页面、docs/ANALYTICS_METRICS.md。

• 为每个指标登记名称、定义、分子分母、去重键、时间字段、时区、版本和负责人。
• 分离服务用户数与服务人次、活动 mutual/confirmed/match/chat/success、Banner impression/click。
• 有效交友匹配在口径未确认前标为 provisional，不能当正式成功或对外宣传。
• 所有统计接口应用 analytics.view 和组织/站点 DataScope，低权限账号返回 403。

Gate: 用固定测试数据人工复算一致；相同用户多次服务不会污染去重人数。

Phase 21：账户生命周期 — EXTEND

Files: account/service/AccountLifecycleService.java、预约/咨询/项目/资格服务、数据保留文档。

• 注销前检查进行中的预约、咨询、项目和本地资格审核。
• 注销事务关闭未来服务、退出项目、失效本地资格并匿名化允许保留的服务历史。
• 数据保留期限未确认的敏感材料采用配置和人工审核，不擅自永久保存或删除。

Gate: 注销后不能登录/推荐/聊天；统计留痕不反向暴露个人和咨询正文。

Phase 22：Deployment / Ops — EXTEND

Files: Dockerfiles、infrastructure/docker-compose*.yml、Nginx、backup/restore/deploy/gray-release scripts、OPS/DEPENDENCIES 文档。

• 删除 Backend 镜像跳过测试的发布路径；CI 构建必须先测试再打包。
• 生产关闭 Mock WeChat、默认密码、Debug、Swagger 和演示 Seed；Secret 全部由环境变量/Secret 文件注入。
• 建立 /api/v1、WebSocket、私有对象、6688 端口检测及国内依赖镜像说明。
• 备份加密并存放独立位置，执行一次 PostgreSQL + 对象存储实际恢复演练。
• Rollback 明确回到哪个稳定镜像/版本；Flyway 只向前修复，不破坏 V001～V027。

Gate: staging 部署、健康检查、恢复演练和版本回滚都有命令、日志与结果证据。

Phase 23：可信系统测试重建 — REFACTOR

Files: backend/src/test/**、tests/e2e/**、tests/invariants/**、测试 fixture/seed、CI scripts。

• 删除测试体中的空 pass，建立可隔离的用户、角色、组织、活动、咨询和预约 fixture。
• INV-001～020 必须测试真实服务行为，不能只断言常量字符串存在。
• E2E 覆盖首页聚合、Banner、资格、咨询、预约、内容、多类型活动、二阶段同意、组织隔离。
• 增加 appointment owner、Counselor Assigned、ContentEditor zero-user-data、station scope 等负向安全测试。
• CI 串联迁移、backend test、admin type-check/build、miniapp type-check 和 E2E，任何失败阻断发布。

Gate: 不允许 skip/pass 空壳；报告列出总数、通过、失败、跳过及原因，失败为零才进入 UAT。

Phase 24：UAT — EXTEND

• 按用户、Reviewer、Matchmaker、Counselor、Counseling Manager、Service Station Operator、Content Editor、Activity Manager、Risk Operator 分角色验收。
• 验收线上主路径、线下扫码路径、咨询路径、辅导路径、服务站路径、活动二阶段确认和反诈举报路径。
• UI 按 375px 小程序基准和 1440px 后台基准检查，并覆盖弱网、空态、错误态、权限态。

Gate: 所有 P0/P1 客户场景有签字结果；阻断缺陷为零。

Phase 25：RC — EXTEND

• 只使用客户确认的真实 Banner、站点、咨询、课堂、反诈、关于我们和组织信息；不 Seed 假用户/假 Match。
• 完成隐私政策、用户协议、敏感文案和“非官方婚姻状态核验”提示审核。
• 冻结 RC 镜像、数据库版本、配置清单、第三方依赖和回滚目标。

Gate: Go/No-Go 清单通过；所有未决事项有明确 Flag/配置行为和责任人。

Phase 26：Production — EXTEND

• 上线前备份，执行 V027 及后续向前迁移，验证角色权限和真实基础内容。
• 依次执行 Home、Quick Entries、Service Station、Counseling、Content、Activity Mutual、Chat、Block smoke。
• 首日监控错误率、延迟、登录、推荐、消息、预约、咨询和权限拒绝；异常按已验证 Rollback 操作。

Gate: 生产 smoke 全部通过且无数据泄露/权限越界；否则立即 NO-GO 或回滚。

五、第一轮执行范围

收到“开始修复”后，只执行 Phase 01：

1. 纠正文档状态与共同基线；
2. 建立三端可重复检查命令；
3. 明确 Git/版本基线；
4. 输出 Phase 01 Completion Report；
5. 停止并等待用户确认 Phase 02。

不得借 Phase 01 提前修改首页、咨询、活动或后台业务代码。

六、计划自检

• 客户修订范围：品牌、首页、Banner、8 入口、本地资格、服务站、预约、咨询、辅导、课堂、反诈、多类型活动、二阶段同意、专项服务、多组织、来源和 Analytics 均已映射。
• 页面范围：U01～U48 KEEP；U49～U64 按“已有修复/缺失新增”分别处理。
• 数据范围：V001～V027 保留，后续只向前迁移；身份、资格、咨询、预约和活动边界独立。
• 权限范围：RBAC、DataScope、Sensitive Permission、Audit 和客户端 Capability 分层明确。
• 发布范围：测试、UAT、真实内容、Secret、备份恢复、Rollback、Production Smoke 均有 Gate。
• 禁止范围：未加入微服务、独立 CMS/咨询服务、社区 Feed、支付、AI 代聊或其他 V1.1 外功能。