Files
danyang-match/docs/善缘丹阳 V1.1 当前进度校正与严格Phase修复计划.md
T
Codex 60eeb8aef5 docs(brand): 全仓库 Codex 署名统一为 WorkBuddy + 5 个文件重命名
## 背景
用户指令:「先将 codex 的任务一并改为 workbuddy 的任务」。
Codex 已不再运行,当前由 WorkBuddy 承担开发执行,文档署名需同步。

## 判定规则(用大小写精确区分)
| 类别 | 写法 | 处置 |
|---|---|---|
| 工具署名 | 大写 Codex | → WorkBuddy |
| 分支名 | codex/ui-v11-fidelity | → workbuddy-ui-v11-fidelity(去斜杠,规避本仓库 ref 清理) |
| 已删除文件的历史路径 | 小写 2026-09-11-codex-baseline-cleanup* | 保持原样(记录真实曾存在的文件名,改了即失真) |

结果:26 个文件、126 处署名替换。残留小写 codex 仅 8 处,全部是历史路径。

## 文件重命名(git mv,保留历史)
- Codex开发执行总指令、项目规则与任务拆解.md → WorkBuddy 同名
- Codex首轮启动提示词 + Phase 01~Phase 26 Jira级任务清单 + 每阶段验收条件.md → WorkBuddy 同名
- docs/善缘丹阳 V1.1 Codex 开发执行计划修订版.md → docs/善缘丹阳 V1.1 WorkBuddy 开发执行计划修订版.md
- docs/善缘丹阳 V1.1 Codex-Jira 最终开发任务增量清单.md → docs/善缘丹阳 V1.1 WorkBuddy-Jira 最终开发任务增量清单.md
- docs/善缘丹阳 V1.1 Codex最终主启动提示词(整合版).md → docs/善缘丹阳 V1.1 WorkBuddy最终主启动提示词(整合版).md

引用已同步:AGENTS.md 6 处、AGENTS_SUMMARY.md、以及 4 份计划/规格文档。

## AGENTS.md 两处特别处理
- 「git config user.name = Codex」一句改为不点名工具的表述
- 「feature/ fix/ codex/ ui/ 前缀」示例去掉 codex/

## 有意未改动
- ui-tests/ui-document-baseline-contracts.mjs 的废弃清单仍列 codex-baseline-cleanup*
  那是「必须不存在」的断言目标,改了会让哨兵失去意义
- 仓库 git config user.name 仍是 Codex —— 未擅自改动环境身份。
  如需彻底交接:git config user.name WorkBuddy && git config user.email workbuddy@local

验证:UI 契约门禁 13/13;AGENTS.md 零 Codex 残留;5 个新文件名与全部引用一致
2026-09-16 14:37:44 +08:00

31 KiB
Raw Blame History

善缘丹阳 V1.1 当前进度校正与严格 Phase 修复 Implementation Plan

2026-09-13 UI 状态覆盖: Phase 07 的业务专项证据保留,但旧视觉结果已被用户否决。当前 UI 唯一规格为 docs/superpowers/specs/2026-09-13-reference-driven-dual-client-ui-redesign-design.md,唯一总计划为 docs/superpowers/plans/2026-09-13-reference-driven-dual-client-ui-redesign.md;先完成清理门禁,不得从本文件恢复旧视觉实现。

已被纠正并取代(2026-09-09): 本文件错误地把客户修订文档解释为“全部 Phase 重开”,且对页面缺失范围判断不准确。当前唯一开发修复计划为 善缘丹阳 V1.1 客户需求基线增量开发与修复计划.md。本文件只保留审查历史,不再作为执行依据。

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.1 WorkBuddy最终主启动提示词(整合版)》为最高产品基线,保留可验证成果,严格按 Phase 01~26 顺序修复偏差并形成用户端、后台端、数据、权限、测试和运维完整闭环。

Architecture: 保持现有 Java 21 + Spring Boot 模块化单体、PostgreSQL、Redis、WebSocket、私有对象存储、Vue 3 管理后台和微信原生 TypeScript 小程序。V001~V027 已应用迁移不可改写,后续修复只使用向前兼容的新迁移;不增加微服务、消息队列或独立 CMS/咨询服务。

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

Spec: docs/善缘丹阳 V1.1 WorkBuddy最终主启动提示词(整合版).md(最高优先级);并结合 AGENTS.md、V1.1 专项修订文件、V1.0 未被修订的核心设计和 docs/V1.1_REAUDIT_REPORT_2026-09-09.md。

Global Constraints

  • 用户基础婚恋服务永久免费,禁止支付、会员、金币、礼物、付费曝光和付费聊天。
  • 微信登录、手机号、实名认证、本地资格、婚恋资料和人工审核是进入匹配服务的准入链路。
  • 实名不等于官方婚姻状态核验,禁止“100%真实、官方单身认证”等绝对承诺。
  • Required 是 Hard Constraint;系统、算法、后台和红娘均不得自动放宽。
  • 普通婚恋关系只有双向 Like 后才能 Match 和聊天;Block 优先级最高。
  • 活动 Mutual Interest 不直接创建 Match/Chat;双方分别确认后才创建或复用 Match Episode 与 Conversation。
  • 红娘、管理员和系统不得替用户 Like、确认成功或确认活动开启沟通。
  • 后台权限必须由 RBAC + Data Scope + Sensitive Permission 在服务端共同控制。
  • PostgreSQL 是业务事实源;Redis 只用于缓存、会话、限频、WebSocket 辅助和短期状态。
  • 首页和 8 个核心入口顺序固定;底部导航固定为首页、找对象、消息、活动、我的。
  • 默认简体中文、Asia/Shanghai、YYYY-MM-DD、人民币元、UTF-8,并优先适配 Windows 11、WSL2、Docker Desktop。
  • 每个 Phase 完成后必须输出规定格式的 Completion Report 并立即停止,未收到下一阶段指令不得继续。

一、主提示词审查结论

1. 文档优先级

本次修复采用以下唯一冲突处理顺序:

用户最新明确指令
> V1.1 最终主启动提示词
> V1.1 专项修订文件
> V1.0 未被修订的核心设计
> 旧代码
> 技术示例

现有代码、STATUS、JIRA 和 Completion Report 与主提示词冲突时,必须修复代码和状态,不得反向降低主提示词验收标准。

2. 上一版恢复计划需要纠正的地方

  • 用 R0~R8 重排了阶段,违反正式 Phase 01~26 固定顺序。
  • 把权限集中到一个恢复阶段,未体现 Phase 02 建底座、各业务 Phase 各自验证 DataScope 的要求。
  • 没有逐项覆盖 Phase 03~12 的 V1.0 核心回归。
  • 对通知必须在事务提交后发送、失败不回滚核心事实覆盖不足。
  • 对 Analytics 的服务用户数/服务人次、活动互选各状态分离、有效交友口径版本化覆盖不足。
  • 对新增依赖登记、生产禁 Debug、备份实际恢复、明确 Rollback 版本覆盖不足。
  • 对“我的”页面固定结构、Design Token、前端七类状态和线下扫码服务闭环覆盖不足。

历史上本文件曾取代 docs/V1.1_RECOVERY_DEVELOPMENT_PLAN_2026-09-09.md;该结论现已失效,以文件顶部的取代声明为准。


二、当前成果的处理分类

KEEP

  • Java 21 + Spring Boot 3.x 模块化单体、Vue 3 管理后台、微信原生小程序和 Docker Compose 技术路线。
  • PostgreSQL、Redis、MinIO、Nginx 的单体部署结构。
  • V001~V027 Flyway 迁移历史;数据库已确认全部应用成功。
  • 现有 Auth、Profile、Review、Match、Relationship、Messaging、Activity、Risk 等 V1.0 模块代码,进入逐 Phase 回归,不先推翻。
  • V1.1 已建立的表、实体和模块目录,作为修复基础。

EXTEND

  • FeatureFlagConfig:补齐与 CapabilityService 的真实联动和灰度降级。
  • Notification:改成事务提交后发送并补全失败隔离。
  • Analytics:补齐统计事实、口径版本和权限隔离。
  • Account Lifecycle:补齐引用完整性、匿名化和保留策略测试。
  • Ops:补齐生产配置、Secret、监控、备份恢复与 Rollback 证据。

REFACTOR

  • 后端认证 Principal、接口级 Permission、DataScope、SensitiveAccessLog。
  • Counseling、ServiceAppointment、Activity Mutual Consent 的权限和状态机。
  • HomeApplicationService 与独立 CapabilityService 的职责边界。
  • Admin Web 路由、工作台和角色菜单。
  • E2E fixture、隔离数据、断言和清理策略。

REPLACE

  • 运行中的旧小程序首页 .js,替换为主提示词规定的 V1.1 首页。
  • 同一小程序页面同时手写 .ts/.js 的双轨模式,替换为唯一 TypeScript 源。
  • 用常量存在证明不变量成立的 V11InvariantsTest。
  • 允许失败但只打印信息的 smoke/E2E 测试。
  • STATUS.md 中“核心功能 100% 完成、可上线”的错误基线。

ADD

  • 独立 CapabilityService、明确 Principal 类型和业务 DataScope 策略。
  • U49~U64 缺失页面与“我的”页面固定结构。
  • Banner 后台完整 CRUD、内部目标验证、排期、排序、受众和预览。
  • 咨询、服务站预约、活动互选、内容、专项服务的完整前后台闭环测试。
  • docs/DEPENDENCIES.md、安全复验、备份恢复演练和发布回滚材料。

三、当前实际进度校正

Phase 提示词目标 当前证据状态 校正状态 处理
01 基础架构 目录和容器存在;Git 不可识别,版本混乱,门禁失真 Partial 首先重开
02 Auth + Operator + RBAC 多角色表存在;后端仅检查 operator_login Critical Partial 重构
03 实名认证 基础模块存在;首页把实名硬编码为 true Partial 修复并复验
04 Profile + Preference + 本地资格 表/API/页面文件存在;佐证权限测试为空壳 Partial 修复并复验
05 审核 V1.0 审核存在;本地资格审核与审计证据不足 Partial 扩展并复验
06 Match Engine 现有规则代码存在;需重新证明双向 Required Unverified 回归后判定
07 V1.1 首页 + 找对象 WXML/TS/JS 漂移、空推荐、错误入口、缺课堂区 Failed 替换
08 Like / Match / Block V1.0 代码存在;需并发与 Block 全链路复验 Unverified 回归后判定
09 Text Chat REST/WS 文件存在;未验证主体与 Match 门槛 Unverified 回归后判定
10 Image & Chat Safety 接口存在;私有对象访问和风险处理证据不足 Partial 扩展并复验
11 Notification 方法存在;事务提交后发送未形成统一保证 Partial 重构
12 Relationship Progress 代码存在;双确认和 Episode 回归证据不足 Unverified 回归后判定
13 公益红娘 服务和转介存在;权限与用户自主权测试不足 Partial 修复并复验
13A 咨询与婚前辅导 后端骨架存在;权限、状态机和前端链路失败 Failed 重构
14 多类型活动 字段和表存在;用户端、后台表单和资格策略未闭环 Partial 扩展
15 活动签到 旧实现存在;多类型活动与站点数据范围未复验 Unverified 回归后判定
16 活动互选双确认 Consent 表存在;Match/Conversation 事务闭环缺失 Failed 重构
17 举报与风控 风险来源代码存在;权限、审计和 UI 不完整 Partial 扩展
18 申诉 旧实现存在;V1.1 风险来源上下文未完整验证 Unverified 回归后判定
19 统一后台及新增服务 多个 Vue 文件存在;咨询空白、接口错位、页面缺失 Failed 重构
20 Analytics API 返回成功;低权限可访问,统计口径未证实 Partial 重构并复验
21 Account Lifecycle 方法存在;事务与匿名化证据不足 Partial 扩展并复验
22 Deployment / Ops 本地容器运行;镜像跳过测试,备份恢复未证明 Partial 修复
23 System Testing 大量 pass、缺 fixture、15/16 smoke Failed 重建
24 UAT 没有有效系统测试前置条件 Not Started 阻断
25 RC 真实内容与安全验收未完成 Not Started 阻断
26 Production V027 Seed 已应用;生产 Smoke/恢复/Rollback 未完成 Not Started 阻断

综合可验证完成度继续采用约 35%;随着每个 Phase 重新通过 Definition of Done,再按真实验收项更新比例。


四、严格 Phase 修复计划

Phase 01:项目基础架构修复与基线重建

Current status: Partial,当前唯一允许执行的开发阶段。

Files:

  • Modify: docs/STATUS.md
  • Modify: docs/PENDING_DECISIONS.md
  • Modify: docs/JIRA_BACKLOG.md
  • Modify: CHANGELOG.md
  • Modify: VERSION
  • Modify: .github/workflows/ci.yml
  • Modify: backend/Dockerfile
  • Create: docs/DEPENDENCIES.md
  • Create: docs/Phase-01-Recovery-Completion-Report.md

Interfaces:

  • Consumes: 最新主启动提示词、现有 V001~V027 迁移、本次审查报告。

  • Produces: 唯一版本基线、可运行质量门禁、后续 Phase 的真实状态台账。

  • 恢复或定位正式 Git 仓库,保护当前目录并记录审计前快照。

  • 将全项目版本统一为 1.1.0-recovery,把历史 Completion Report 标记为需复验。

  • 按本文件的 26 行矩阵重写 STATUS Current Phase、Completed、Next Task、Known Issues、Test Results、Migration Version、Release State。

  • 将确认项从 PENDING 移出;保留主提示词第七十四部分规定的未决事项。

  • 将 JIRA 已完成状态改为 REOPENED_FOR_VERIFICATION、PARTIAL、BLOCKED 或 VERIFIED,禁止用文件存在标记 Done。

  • 修复 CI:Backend mvn verify -B;Admin type-check + lint(no-fix) + build;Miniapp type-check;Migration 在临时 PostgreSQL 实际执行。

  • 移除 Backend Dockerfile 的 maven.test.skip=true,镜像必须由已通过测试的构建产生。

  • 登记全部直接依赖的版本、License、维护状态、国内安装方式和安全检查结果。

  • 运行 Phase 01 全部检查并保存原始输出;无法运行的检查必须将环境原因列为 Blocked,不能写 Passed。

  • 更新 OpenAPI、Migration Inventory 和 CHANGELOG 中的真实基线说明。

  • 输出规定格式的 Phase 01 Recovery Completion Report,然后立即停止。

Acceptance commands:

git status --short --branch
Set-Location backend; mvn verify -B
Set-Location ..\admin-web; npm ci; npm run type-check; npm run lint:check; npm run build
Set-Location ..\miniapp; npm ci; npm run type-check
Set-Location ..; python -m pytest -q tests/invariants

Exit Gate: Git 可追溯、版本唯一、CI 会因现有已知错误失败、文档没有虚假完成结论。完成后不得自动进入 Phase 02。

Phase 02:Auth + Operator + RBAC 三层权限底座

Current status: Critical Partial。

Core files: JwtAuthFilter.java、PermissionFilter.java、SecurityConfig.java、PermissionService.java、V015 后续修复迁移、PermissionMatrixTest.java。

  • 区分 User Principal 与 Operator Principal,禁止 Operator Token 被普通用户接口当作用户身份。
  • 建立 API → Permission Code 明确映射,不再用 operator_login 保护全部后台接口。
  • 建立 DataScope 接口:platform、organization、assigned_service、service_location、self。
  • 建立 Sensitive Permission + Business Reason + SensitiveAccessLog 公共入口。
  • 验证一个 Operator 多 Role 的并集权限,同时确保组织关系不自动产生数据权限。
  • 真实测试 13 类角色最小权限和直接 URL/API 越权。

Exit Gate: RBAC、DataScope、Sensitive Permission 三层行为测试通过;低权限 API 越权全部返回 403/404。输出报告并停止。

Phase 03:实名认证状态修复

Current status: Partial。

  • 复验微信登录、手机号绑定、身份提交、状态查询和取消流程。
  • 用 UserIdentity 的真实状态替换首页 verified=true。
  • 保持本地资格独立建模,身份 DTO 不加入本地资格字段。
  • 人脸仅保留 Provider 接口、状态和 Feature Flag;不保存人脸模板或自研识别。
  • 验证日志、响应和截图中不存在身份证明文、Token 和默认密钥。

Exit Gate: 实名状态来自 PostgreSQL;文案不暗示婚姻状态官方核验。输出报告并停止。

Phase 04:Profile + Preference + 本地资格

Current status: Partial。

  • 复验 Profile、Preference、照片、兴趣、隐私设置与资料完成度。
  • 真实实现本地资格声明:户籍、工作、居住、其他;默认先声明,按策略请求佐证。
  • 佐证上传校验文件数、大小、类型、归属和私有对象存储。
  • /me/status 返回真实 localEligibilityStatus,但不暴露原始证明。
  • 复验 Required/Preferred 字段没有在 UI、API 或数据库默认值中混淆。

Exit Gate: 本地资格与实名完全分离,INV-011 的用户侧前置条件成立。输出报告并停止。

Phase 05:审核与敏感佐证访问

Current status: Partial。

  • 本地资格进入独立 review_type 队列,支持 claim、approve、need_evidence、reject。
  • 只有具备资格审核权限和业务理由的 Reviewer 可获取短期私有访问地址。
  • 每次访问记录 SensitiveAccessLog,内容不记录证明正文。
  • 审核状态变更与通知使用事务后事件。
  • 复验并发 claim 只能有一个工作人员成功。

Exit Gate: 未授权 Operator 无法看到证明;每次授权访问可审计。输出报告并停止。

Phase 06:Match Engine 双向 Hard Constraint

Current status: Unverified。

  • 复验 Eligibility → A Required → B Required → Directional Score → Mutual Score → Ranking → Reasons 全链路。
  • 为双向 Required、Block、本地资格、暂停寻找和账号状态建立参数化测试矩阵。
  • 禁止财富、房产、车辆、颜值、公司级别、职位、人气作为排序价值特征。
  • 前端只显示“很合适/比较合适/值得了解”和真实理由,不显示数字匹配率。

Exit Gate: INV-001 有真实正反例,任何一方 Required 不满足都不会进入推荐。输出报告并停止。

Phase 07:V1.1 首页 + 找对象整体替换(业务证据保留,UI 已重新打开)

Current status: Failed。

Core files: HomeApplicationService.java、HomeDTO.java、新增 CapabilityService.java、miniapp/pages/index/*、缺失的内容与服务站页面。

  • 新建服务端 CapabilityService,统一计算七项能力,Home 只聚合不复制业务规则。
  • 首页从真实身份、审核、本地资格、推荐、Banner、活动、服务站、Content 数据源聚合。
  • 精确实现固定顺序:品牌、用户状态、Banner、8 入口、推荐、公益服务、活动、服务站、婚恋课堂、安全提醒。
  • 8 入口精确顺序、目标路径和 Feature Flag/Capability 状态由自动化测试锁定。
  • 替换旧运行 .js 首页;TypeScript 成为唯一手写源,消除 13 个页面的 TS/JS 漂移。
  • 首页覆盖 onboarding、review-pending、searching、paused、successful 五种状态和 Loading/Skeleton/Empty/Error/Retry/Disabled Reason/Success Feedback。
  • 第一屏确保品牌、不过高 Banner 和 8 入口在常见手机尺寸清晰可见。

Exit Gate: INV-016、017 通过;5 秒信息认知目标经截图与人工走查验证。输出报告并停止。

Phase 08:Like / Match / Block

Current status: Unverified。

  • 复验单向 Like 不创建聊天、双向 Like 原子创建一个 Match Episode。
  • 并发 Like 只能生成一个 active Match 和一个 Conversation。
  • Block 立即影响聊天、推荐、搜索、红娘候选和关系互动。
  • Unblock 不恢复旧 Like、Match 或 Conversation。
  • 管理员和红娘均无代 Like/Pass 能力。

Exit Gate: INV-002、003、004、007 通过。输出报告并停止。

Phase 09:Text Chat

Current status: Unverified。

  • 复验 REST Send + WebSocket Receive、历史、未读、失败重试和系统消息。
  • 强制 senderId + clientMessageId 唯一,重复发送返回同一业务结果。
  • 只有 active Match 双方可读写 Conversation。
  • 不实现语音、视频、群聊、红包、转账、位置、文件、AI 代聊和公开已读回执。

Exit Gate: 未 Mutual、Unmatch、Block、越权用户均不能聊天。输出报告并停止。

Phase 10:Image & Chat Safety

Current status: Partial。

  • 图片上传只使用短期凭证和私有桶,读取 URL 校验 Conversation 成员关系。
  • 风险关键词、频率限制和首次安全提示不记录私人聊天正文。
  • 普通工作人员不能读取聊天;只有明确案件、权限、理由和审计时有限访问。
  • 验证对象 URL 过期、越权访问、Block 后发送和恶意文件类型。

Exit Gate: INV-009 与图片私有访问测试通过。输出报告并停止。

Phase 11:Notification 事务后发送

Current status: Partial。

  • 把 Match、审核、预约、咨询、活动互选通知统一改为事务提交后事件。
  • 通知失败只记录脱敏错误和重试状态,不回滚核心业务事实。
  • 单向活动意向和咨询敏感内容不得进入通知文案。
  • Feature Flag 关闭时不发送指向不可用功能的通知。

Exit Gate: 事务回滚不发送通知;通知故障不回滚 Match/服务记录。输出报告并停止。

Phase 12:Relationship Progress 与 Match Episode

Current status: Unverified。

  • 复验 searching、getting_to_know、paused、successful、exit 等状态迁移。
  • 成功牵手必须一方发起、另一方确认;工作人员不能代确认。
  • 一对用户允许在 prior unmatch 后建立新 Episode,保留历史且不串用 Conversation。
  • 首页公益服务建议只消费关系状态,不修改关系事实。

Exit Gate: 双确认、历史 Episode 和非法迁移测试通过。输出报告并停止。

Phase 13:公益红娘与用户自主权

Current status: Partial。

  • 红娘只能看 DataScope 内必要资料和系统候选,不读取私人聊天、完整身份证、手机号和咨询正文。
  • 红娘推荐不得绕过 Required,不得替用户 Like/Pass/确认成功。
  • 咨询、活动和服务站转介必须由用户确认后生效。
  • 服务申请、分配、推荐、跟进、完成形成完整留痕。

Exit Gate: INV-007、013 和转介用户确认测试通过。输出报告并停止。

Phase 13A:婚恋咨询与婚前辅导

Current status: Failed。

  • 将后台 API 置于受保护的 /api/v1/operator/counseling/**,用户 API 保持独立。
  • 实现 pending → assigned → scheduled → in_progress → completed/closed/cancelled 合法状态机。
  • Counselor 只能读取和操作 Assigned Service;Counseling Manager 才能查看队列和分配。
  • Matchmaker、普通管理员和其他 Counselor 看不到咨询正文和 followup。
  • 婚前辅导复用 CounselingService 类型,不建立重复系统。
  • 修复 Admin 空白页、路由和接口;完成 U55~U59 的申请、我的咨询、排期和结果状态。
  • 只记录必要摘要、服务结果和下一步,不记录逐字谈话,不建设咨询即时 IM。

Exit Gate: INV-012、013 及申请→分配→预约→服务→摘要→完成全链路通过。输出报告并停止。

Phase 14:多类型公益活动

Current status: Partial。

  • 六类活动使用明确枚举与中文展示。
  • registration_policy 按类型校验,反诈课堂不得被相亲联谊资格规则错误阻断。
  • 使用 total_capacity + 可选 capacity groups,不重新引入固定男女容量模型。
  • 用户端完成类型 Tabs、类型化卡片和动态报名资格提示。
  • Admin 完成类型、报名规则、多组织与容量组表单。

Exit Gate: 每类活动的准入、容量和前后台展示测试通过。输出报告并停止。

Phase 15:活动报名、审核与签到

Current status: Unverified。

  • 复验报名幂等、最后名额并发批准、取消和候补逻辑。
  • 非 matchmaking 活动不出现互选设置。
  • 扫码签到、人工签到、重复签到和签到统计完整留痕。
  • Service Station Operator 只能处理指定现场任务。

Exit Gate: INV-005 和多类型活动签到回归通过。输出报告并停止。

Phase 16:活动互选 + 双向沟通确认

Current status: Failed。

  • Mutual Interest 形成 consent pair,但不创建 Match/Conversation。
  • 双方分别确认后,在一个事务中锁定 pair 并幂等创建或复用关系。
  • 已有 active Match 复用聊天;prior unmatch 创建新 Match Episode 和 Conversation。
  • 一方拒绝、超时、重复提交、并发确认均有明确状态和隐私安全结果。
  • 用户端结果页覆盖本人确认、等待对方、双方完成、已有聊天、拒绝和超时。
  • Analytics 分开记录 Interest、Mutual Interest、Consent、Match、Two-Way Chat、Successful。

Exit Gate: INV-006、014、015 和并发事务测试通过。输出报告并停止。

Phase 17:举报与风控

Current status: Partial。

  • 风险来源覆盖 counseling、service_station、offline_activity,但不把咨询正文写入日志。
  • RiskAction 具备权限、理由、事务和审计;举报证据保持私有。
  • 普通用户不可看到公开黑名单或他人处罚信息。
  • Admin 工作台展示高风险和待处理任务,不显示无权内容。

Exit Gate: 风险越权、敏感日志和处置事务测试通过。输出报告并停止。

Phase 18:申诉

Current status: Unverified。

  • 根据 Confirmed/Pending 决议确认是否首发;若首发,保持现有 V1.0 模型并扩展 V1.1 风险上下文。
  • 只有允许申诉的有效处置可提交,提交与处理均幂等。
  • 通过后撤销对应 RiskAction,拒绝后保持原处置,全程审计。
  • 页面不泄露举报人、证据和内部风控规则。

Exit Gate: 用户申诉和后台处理闭环通过。输出报告并停止。

Phase 19:统一运营后台 + Banner + Content + 服务站 + ServiceProgram

Current status: Failed。

  • 修复 Admin type-check,注册全部路由并按角色对导航分组。
  • 工作台按角色展示:Reviewer 待审核、Matchmaker 待服务、Counselor 今日预约、Service Station 今日预约、Activity Manager 报名签到、Risk 高风险。
  • Banner 支持图片、标题、副标题、按钮、内部目标、起止时间、排序、受众、上下架和移动端预览。
  • Content 只实现分类、列表、详情、创建、编辑、发布、下架,不增加评论、点赞、投稿、Feed、热搜和排行榜。
  • 服务站实现详情、地址、开放时间、联系电话、地图导航、服务项目和预约后台处理。
  • ServiceProgram 支持公益项目与成员服务,不使用“高价值/低价值/困难匹配”标签。
  • 补齐 U49~U54、U60、U61、U64,并按固定结构重建“我的”页面。
  • 统一 Design Token,清理每页重复硬编码,补齐七类前端状态。

Exit Gate: 新增服务全部具备用户端、后台端、数据、权限和测试闭环。输出报告并停止。

Phase 20:Analytics 真实口径

Current status: Partial。

  • 统计服务站访问、预约、咨询申请/完成、婚前辅导、课堂、反诈、专项服务和用户来源。
  • 明确区分服务用户数与服务人次。
  • 分开统计 Activity Interest、Mutual Interest、Consent、Match、Two-Way Chat、Successful。
  • 有效交友指标使用版本化口径,运营未确认前标记 provisional,不永久固化。
  • Dashboard 不读取咨询正文,所有统计接口执行 Permission + DataScope。

Exit Gate: 用固定数据库样本验证每个指标分子、分母、去重规则和权限。输出报告并停止。

Phase 21:Account Lifecycle

Current status: Partial。

  • 注销/关闭账户处理未来预约、进行中咨询、项目成员、本地资格、Match 和 Conversation。
  • 历史服务记录按保留策略匿名化,不破坏外键和统计。
  • 注销、恢复、关闭的并发和失败回滚测试覆盖 V1.1 新表。
  • 账号关闭后不能发起新服务或继续互动。

Exit Gate: 生命周期跨模块一致性与匿名化测试通过。输出报告并停止。

Phase 22:Deployment / Ops

Current status: Partial。

  • 全部新增模块可由 Feature Flag 独立关闭,首页正确降级但不永久隐藏已确认功能。
  • Production 无 Mock 实名、测试 API、默认密码、公开管理 Swagger 和 Debug 日志。
  • Secret 只从环境或 Secret 文件注入,不进入源码、Git、日志和交付文档。
  • /health/live、/health/ready、/version 返回可监控且不泄密的信息。
  • 建立自动加密备份到独立存储,并在隔离环境实际恢复验证。
  • 明确上一个稳定版本和应用/数据库 Rollback 手册,Migration 保持向前兼容。
  • 提供 PowerShell 与 Bash 部署、检查、备份、恢复命令和国内镜像说明。

Exit Gate: 部署可复现、恢复演练成功、Rollback 可执行、生产安全配置检查通过。输出报告并停止。

Phase 23:System Testing 重建

Current status: Failed。

  • 建立 pytest fixture、隔离数据库、角色令牌、数据工厂和测试清理。
  • 清除所有空 pass,每个测试必须具备 Given/When/Then 与强断言。
  • 重写 INV-001~020 为真实行为测试,不用常量存在代替权限和业务验证。
  • 执行 Backend 单元/集成、Admin type-check/lint/test/build、Miniapp type-check/静态路由测试、API E2E、Migration Test。
  • 最高优先覆盖权限、隐私、数据一致性、Match、Block、Chat、本地资格、活动容量、互选同意和咨询权限。
  • 生成机器可读测试报告并在 CI 留存,不再用手工“25/25”文字作为证据。

Exit Gate: 所有自动化测试零失败、零错误、零意外跳过;P0/P1 缺陷清零。输出报告并停止。

Phase 24:UAT

Current status: Not Started。

  • 使用独立 UAT 环境和真实角色,不复用开发脏数据。
  • 完成婚恋核心、首页、本地资格、红娘、咨询、婚前辅导、多类型活动、活动确认、服务站预约、内容和专项服务场景。
  • 完成群众到万善公园→扫码→登录→预约/报名→后台处理→到场→完成→留痕的线上线下闭环。
  • 确认正式事实不依赖 Excel、个人微信或纸质临时台账。
  • 验证普通用户无需培训即可完成核心任务,重要页面一步一个任务。

Exit Gate: UAT 用例、问题清单、复测结果和业务负责人签字齐全。输出报告并停止。

Phase 25:RC

Current status: Not Started。

  • 审核真实 Banner、服务站地址/开放时间、咨询介绍、婚前辅导、反诈、课堂、关于、主办/执行信息。
  • 删除测试文案、默认账号、Mock 数据和开发入口。
  • 完成安全、隐私、无障碍、弱网、空状态、错误恢复、常见 Windows 浏览器与真机检查。
  • 复核所有文案无商业化标签和绝对安全承诺。
  • 建立 RC 文件清单、校验值、依赖清单、已知限制和 Go/No-Go 结论。

Exit Gate: 发布阻断项为零,RC 可在全新环境复现。输出报告并停止。

Phase 26:Production

Current status: Not Started;仅 V027 Seed 可 KEEP。

  • 上线前确认备份、恢复、Rollback、Secret、证书、监控和告警。
  • 应用已审核的初始化分类、活动类型、服务类型、角色权限、服务站和 Banner。
  • 执行 Home、Quick Entry、Service Station、Counseling、Content、Activity Consent、Match、Block、Chat、权限矩阵 Smoke。
  • 验证 PostgreSQL 是唯一事实源,生产无测试账号和默认密钥。
  • 记录部署版本、Migration Version、前一稳定版本、Smoke 结果和回滚窗口。

Exit Gate: 主提示词第九十七部分全部满足后,才允许将版本定义为“善缘丹阳 V1.1 完成”。输出 Production Completion Report 并停止。


五、统一 Definition of Done

每个 Story/Task 必须同时满足:代码完成、测试完成、Lint 通过、Build 通过、Migration 通过、权限验证通过、OpenAPI 更新、文档更新、Regression 通过。任何一项缺失,状态只能是 Partial 或 Blocked。

每个 Phase Completion Report 必须逐项回答:本次具体完成、实际测试与原始输出、代码和数据库变化、安全影响、未决事项、回归影响和下一 Phase;报告生成后立即停止。

六、计划自检

  • Spec coverage:已覆盖主提示词 100 个部分中的产品红线、首页、Banner、服务站、咨询、内容、活动、专项服务、多组织、架构、数据、算法、聊天、权限、页面、UI、阶段、DoD、不变量、事务、测试、Analytics、线下闭环、依赖、Secret、部署、备份、Rollback、Feature Flag、Pending、UAT、RC 与 Production。
  • Placeholder scan:每个 Phase 均有明确修复动作和 Exit Gate,没有以文件存在或空测试代替验收。
  • Type consistency:统一使用 User/Operator Principal、Permission + DataScope + Sensitive Permission、CapabilityService、Match Episode、Conversation 和事务后事件。
  • Scope check:坚持模块化单体和现有技术栈,不新增主提示词禁止的系统。

七、历史建议(已失效)

只执行 Phase 01。Phase 01 Completion Report 经用户审核并收到继续指令后,才允许进入 Phase 02。