129 lines
11 KiB
Markdown
129 lines
11 KiB
Markdown
# 善缘丹阳 V1.1 当前进度评估与开发计划
|
||||
|
|
|
|||
|
|
日期:2026-09-14
|
|||
|
|
分支:`codex/ui-v11-fidelity`
|
|||
|
|
性质:进度评估 + 近期可执行开发计划(规划文档,不替代既有正式 Phase 计划)
|
|||
|
|
|
|||
|
|
> 本文按用户要求编写:以 `docs/` 下最近修改的文件为最高优先级理解需求,结合只读代码核验评估当前真实进度,并生成下一步开发计划。本文不声称任何"已完成"为视觉验收结论;所有状态以 2026-09-13 参考图驱动 UI 重设计规格、客户需求基线增量开发与修复计划为唯一执行依据。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 一、需求理解(按最近修改优先)
|
|||
|
|
|
|||
|
|
`docs/` 下最近修改(2026-09-13)并构成当前唯一有效基线的是以下文件,其优先级自上而下:
|
|||
|
|
|
|||
|
|
| 优先级 | 文件 | 作用 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 1 | `docs/superpowers/specs/2026-09-13-reference-driven-dual-client-ui-redesign-design.md` | 当前唯一 UI 视觉/组件/响应式/前端验收基线(用户已确认) |
|
|||
|
|
| 2 | `docs/superpowers/plans/2026-09-13-reference-driven-dual-client-ui-redesign.md` | UI 重设计唯一总计划(清理→管理端→小程序→终验) |
|
|||
|
|
| 3 | `docs/善缘丹阳 V1.1 客户需求基线增量开发与修复计划.md` | V1.1 业务唯一开发执行计划 |
|
|||
|
|
| 4 | `docs/UI_CLEANUP_REPORT/INVENTORY_2026-09-13.md` | UI 旧代码与冲突文档治理结论 |
|
|||
|
|
| 5 | `docs/ADMIN_REFERENCE_UI_QA_2026-09-13.md` | 管理端参考图 UI 验收结论 |
|
|||
|
|
| 6 | `docs/STATUS.md` | 当前有效状态台账 |
|
|||
|
|
|
|||
|
|
核心约束(不可越过):
|
|||
|
|
- 两张参考图是**唯一视觉来源**;旧小程序暖白首页、浅色管理侧栏、通用 Element Plus 后台、旧 Phase 07 视觉验收结论、全量 63/64 页一次性重构全部不得覆盖本规格。
|
|||
|
|
- 内置业务不变量(用户免费、Required 不放宽、Mutual 后聊天、Block 最高优先、活动互选双确认、Counselor 仅 Assigned、ContentEditor 零用户数据、服务站不可浏览全库、前端入口由服务端 Capability 决定)。
|
|||
|
|
- 管理端第一批 = 全局框架 + 工作台;小程序第一批 = 11 个核心页(首页/找对象/消息/活动/我的/红娘/咨询/婚前/课堂/反诈/服务站),首页固定 8 入口两行四列。
|
|||
|
|
- 视觉重构不改后端/数据库/API,不打破权限与业务闭环;不使用虚构数据冒充接口成功。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 二、当前进度评估(只读核验后)
|
|||
|
|
|
|||
|
|
### 2.1 需求文档层的真实状态
|
|||
|
|
|
|||
|
|
- **UI 清理治理已完成**:删除 11 个冲突文档、13 个旧视觉产物、2 个旧测试、13 个页面重复源;唯一视觉事实源收敛到 2026-09-13 规格;`AGENTS.md`/`STATUS.md`/`JIRA_BACKLOG.md` 已按新基线修订。
|
|||
|
|
- **管理端框架与工作台已实施并通过参考图 QA**(`ADMIN_REFERENCE_UI_QA`):两档分辨率截图齐全,无 P0/P1/P2 阻断;真实后端联调本轮未重复验证。
|
|||
|
|
- **小程序 11 页代码已按参考图重构到 B 组**(提交历史:home → discovery/messages → activity/mine → public relationship services),C 组(课堂/反诈/服务站)在途未提交。
|
|||
|
|
|
|||
|
|
### 2.2 代码库核验与文档口径的偏差(关键发现)
|
|||
|
|
|
|||
|
|
| # | 发现 | 说明 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 1 | **代码实际超前于计划 checkbox** | Git 已提交管理端壳层/工作台、小程序 A/B 组重建;但 4 份计划文档 checkbox 全部为 `[ ]` 未勾。治理状态与代码不一致。 |
|
|||
|
|
| 2 | **工作区有 55 个未提交改动** | 覆盖 backend/admin-web/infrastructure/miniapp(含小程序 C 组 content/anti-fraud/service-station 共 12 个文件)。存在"未落提交"的在途工作。 |
|
|||
|
|
| 3 | **Flyway 迁移实际到 V035** | 文档/STATUS 声明 V001~V027;实际存在 V028~V035(服务站操作员范围、权限补齐、operator 软删、审计/消息/敏感访问字段对齐)。**文档基线过陈旧。** |
|
|||
|
|
| 4 | **CapabilityService 未作为独立服务存在** | Phase-07 报告称"Capability 按账户返回 Disabled 原因",但 `rg` 未检出独立 `capability/` 模块或 `CapabilityService` 类;能力逻辑疑似内嵌在 `HomeApplicationService`。与进度校正计划的"新建独立 CapabilityService"REFACTOR 项不符。 |
|
|||
|
|
| 5 | **小程序 C 组仍为 `.js`** | content/anti-fraud/service-station 以 `.js` 存在且有未提交改动,与"TypeScript 为唯一手写源"要求可能冲突;TS/JS 双轨未完全清零。 |
|
|||
|
|
| 6 | **管理端业务 Vue 均在 `src/modules/`** | Banner/Content/ServiceStation/Appointment/Program/Counseling/Referral/Analytics/Review/Risk/User 等 19 个 Vue 存在;只读探查曾只看 `src/views/` 误报缺失——**业务组件齐全**。 |
|
|||
|
|
|
|||
|
|
### 2.3 后端业务进度(KEEP,未在本轮范围外推进)
|
|||
|
|
|
|||
|
|
- Phase 01~07 已出具 Recovery Completion Report;HomeApplicationService/本地资格/咨询/内容/专项/预约/活动互选模块源码存在。
|
|||
|
|
- 后端全量回归非全绿:277 tests → 4 failures、8 errors、3 skips(登记为既有跨阶段债务)。
|
|||
|
|
- Phase 08 及以后(Like/Match/Block、Chat、Relationship、红娘转介、多类型活动、互选事务、风控、申诉、Analytics、Lifecycle、Deployment)仍**暂停**。
|
|||
|
|
|
|||
|
|
### 2.4 综合结论
|
|||
|
|
|
|||
|
|
- 可验证完成度维持官方口径约 35%;综合开发资产约 45%~55%(数据来自既有计划,非本次新估算)。
|
|||
|
|
- 当前**活跃工作流 = UI 重设计**(管理端框架/工作台 + 小程序 11 页),总体处于 **Stage 3~5 之间且代码超前、文档滞后、存在未提交在途改动**。
|
|||
|
|
- **整体仍 NO-GO**(UAT/RC/Production)。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 三、开发计划
|
|||
|
|
|
|||
|
|
### 目标
|
|||
|
|
在已有代码超前的现实上,把"未提交工作"收口为可验收基线,同步治理文档与代码口径,补齐缺失项,再按既定门禁推进管理端/小程序终验与后端业务收口。
|
|||
|
|
|
|||
|
|
### 阶段 0 — 在途工作收口(本轮优先)
|
|||
|
|
- [ ] 运行现有门禁命令,记录原始输出(backend test、admin type-check+build、miniapp type-check、UI 合同测试、dashboard 数据合同测试)。
|
|||
|
|
- [ ] 评估 55 个未提交文件与被清理的旧实现是否冲突;对仍在 `docs`/设计基线外的改动回退或分类。
|
|||
|
|
- [ ] 将确认无误的在途改动以独立 commit 提交,作为可恢复检查点(保留 Git 可追溯)。
|
|||
|
|
- 退出门禁:双端检查通过退化为可记录的真实结果;无未提交的存量改动悬空。
|
|||
|
|
|
|||
|
|
### 阶段 1 — 小程序第一批收口
|
|||
|
|
- [ ] 将 content / anti-fraud / service-station 迁移为唯一 TypeScript 源,清理剩余 TS/JS 双轨。
|
|||
|
|
- [ ] 运行 `miniapp-reference-contracts.mjs`、`phase03/04/06/07` 合同测试、`type-check`、微信开发者工具编译;修复 WXML/WXSS/组件路径/页面注册错误。
|
|||
|
|
- [ ] 补齐 11 页逐页截图与参考图对比;按 QA 报告格式登记每一页 C 组结论。
|
|||
|
|
- 退出门禁:11 页均接入 reference 主题、5 项 Tab 与 8 入口顺序正确、控制台无编译错误。
|
|||
|
|
|
|||
|
|
### 阶段 2 — 管理端终验
|
|||
|
|
- [ ] 复跑 `admin-reference-contracts.mjs` + `admin-dashboard-data-contracts.mjs` + type-check + build。
|
|||
|
|
- [ ] `1366×768` 与 `1920×1080` 截图人工比对;侧栏/顶部栏/搜索/通知/管理员菜单/退出登录/待办跳转/重试交互验证。
|
|||
|
|
- [ ] 权限与路由回归:七类后台角色只看到自己的工作,无越权菜单跳转/URL 访问。
|
|||
|
|
- 退出门禁:管理端框架+工作台通过人工视觉验收,路由权限无回归。
|
|||
|
|
|
|||
|
|
### 阶段 3 — 双端总验收(对应 Spec Stage 6)
|
|||
|
|
- [ ] 运行 7 个合同测试、管理端检查/构建、小程序类型检查、Docker 检查与受影响后端测试,全部退出码 0。
|
|||
|
|
- [ ] 执行无旧主题混用、无无响应入口、无业务不变量回归检查;输出剩余差异说明。
|
|||
|
|
- [ ] 同步更新 `STATUS.md`、`JIRA_BACKLOG.md`、总计划与两份批次计划 checkbox,使文档与代码一致。
|
|||
|
|
- 退出门禁:用户完成最终截图验收;文档与代码口径一致,无把开发引回旧视觉的入口。
|
|||
|
|
|
|||
|
|
### 阶段 4 — 缺口补齐(与 UI 并行/穿插)
|
|||
|
|
- [ ] 从 `HomeApplicationService` 抽出独立 `CapabilityService`,Home 只聚合不复制业务规则(对应进度校正 Phase 07 REFACTOR 未勾项)。
|
|||
|
|
- [ ] 将 V028~V035 迁移登记进 STATUS/数据库/API 设计与迁移清单,消除"V001~V027"陈旧口径。
|
|||
|
|
- [ ] 对 backend 277 tests 的 4 failures/8 errors/3 skips 登记责任人并逐项清零或挂 Blocked 记录。
|
|||
|
|
|
|||
|
|
### 阶段 5 — 后端业务收口(UI 验收后恢复 Phase 08+)
|
|||
|
|
> 不早于 UI 终验通过,按官方 Phase 顺序依次执行,每 Phase 输出 Completion Report 并停止:
|
|||
|
|
- [ ] Phase 08 Like/Match/Block 并发与 Block 全链路回归(INV-002/003/004/007)。
|
|||
|
|
- [ ] Phase 09 Text Chat、Phase 10 Image & Chat Safety、Phase 11 Notification 事务后发送。
|
|||
|
|
- [ ] Phase 12 Relationship、Phase 13 红娘转介、Phase 13A 咨询权限与状态机。
|
|||
|
|
- [ ] Phase 14~18 多类型活动、签到、活动互选双确认事务、风控、申诉。
|
|||
|
|
- [ ] Phase 19~21 统一运营后台、Analytics 真实口径、Account Lifecycle。
|
|||
|
|
- [ ] Phase 22 Deployment/Ops、Phase 23 可信系统测试重建(清除空 pass、真实 INV-001~020 行为测试)。
|
|||
|
|
- 退出门禁:零失败零错误零意外跳过,P0/P1 清零后才进入 Phase 24 UAT。
|
|||
|
|
|
|||
|
|
### 阶段 6 — 发布前序(UAT → RC → Production)
|
|||
|
|
- [ ] UAT 分角色闭环(含群众扫码→预约→到场→留痕线下链路)。
|
|||
|
|
- [ ] RC 真实内容、安全/隐私/无障碍/弱网复检、Go/No-Go 清单。
|
|||
|
|
- [ ] Production 备份/恢复演练、V027~V035 向前迁移、Smoke 与回滚手册。
|
|||
|
|
- 退出门禁:主启动提示词全部条件满足后,才允许定义为"善缘丹阳 V1.1 完成"。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 四、风险与建议
|
|||
|
|
|
|||
|
|
- **治理滞后是最大风险**:代码超前于计划 checkbox + 未提交在途 + V035 未登记,若不先收口,后续验收将再次陷入"文档说了算 vs 代码算数"的对立。本计划将阶段 0 列为最高优先。
|
|||
|
|
- **CapabilityService 缺失**是业务不变量 INV(入口由服务端能力决定)的软肋,须在 UI 收紧前补齐,避免前端自行拼状态。
|
|||
|
|
- **C 组 `.js`** 若不统一为 TS,会重蹈 13 页漂移覆辙,须在本轮彻底清零。
|
|||
|
|
- **不要以整目录覆盖/强制回滚/虚构数据**完成任何页面;每批删除/重构均需构建 + 合同测试 + Git 可恢复证据。
|
|||
|
|
- 每个阶段完成后暂停等待人工验收,不自动进入下一阶段。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 五、执行方式建议
|
|||
|
|
|
|||
|
|
本文为规划文档。若进入执行,建议按既有计划规范加载 `superpowers:executing-plans` 或 `superpowers:subagent-driven-development` 逐个 Phase/Step 落地,每个 Phase 完成后输出 Completion Report 并停止,等待用户确认。
|