Codex
60eeb8aef5
## 背景 用户指令：「先将 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 个新文件名与全部引用一致
129 lines
11 KiB
Markdown
129 lines
11 KiB
Markdown
# 善缘丹阳 V1.1 当前进度评估与开发计划
|
||
|
||
日期：2026-09-14
|
||
分支：`workbuddy-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 并停止，等待用户确认。 |