Files
danyang-match/docs/代码进度实测与差距评估_2026-09-15.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

138 lines
8.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 善缘丹阳 V1.1 代码进度实测与差距评估
日期:2026-09-15
分支:`workbuddy-ui-v11-fidelity`(HEAD `9d73087`,工作区干净,0 未提交)
方法:**以代码与构建产物为唯一证据**,不采信任何文档中的"已完成 / ✅ / 已部署"声明(依据 AGENTS.md 执行纪律)
---
## 一、结论先行
| 项 | 结论 |
|---|---|
| 整体状态 | **NO-GO**(距可验收仍有实质差距) |
| 代码资产真实完成度 | **约 55%**(显著高于文档自评的 35%,但低于模块覆盖率给人的直觉) |
| 最致命问题 | **后端 HEAD 源码无法编译**(`HomeApplicationService` 两处硬错误,且已提交入库) |
| 最危险的合规缺口 | **V1.1 四个新角色零实现** + 唯一失败的测试正是 `PermissionMatrixTest` |
| 文档可信度 | **严重失真**,且失真方向是*低估*代码、*高估*风险,导致计划与代码脱节 |
> 一句话:代码的"宽度"已铺开(模块几乎都有),但"深度"不足(推荐算法是壳、业务闭环断裂),且当前处于**构建断裂**状态。
---
## 二、三端实测数据
### 2.1 后端(Java / Spring Boot)
| 指标 | 实测值 | 证据 |
|---|---|---|
| Java 源文件 | 约 300 个(Controller 56 / Service 53 / Mapper 56 / DTO 35) | `src/main/java` 统计 |
| 领域包 | 37 个顶层包 | `com.danyang.match.platform/*` |
| Flyway 迁移 | **V001–V035** | 文档仅登记到 V027 |
| 测试类 | 59 个 | `src/test` |
| 上次成功测试结果 | **293 tests / 1 failure / 0 errors / 3 skipped** | `target/surefire-reports`(快照 2026-09-13) |
**V1.1 八大新增模块覆盖(源码级)**
| 模块 | 状态 | 说明 |
|---|---|---|
| banner | 有 | 仅运营端接口,缺 C 端读接口(靠 home 聚合兜底) |
| service_location | 有 | 未独立成包,并入 `service_appointment/` |
| appointment | 有 | 实际包名为 `service_appointment/` |
| counseling | 有(**双实现**) | `CounselingService`(167行,线上) 与 `CounselingServiceApp`(280行,仅测试引用) 并存 |
| content | 有 | 分类 + 文章 |
| service_program | 有 | — |
| local_eligibility | 有 | — |
| home | **有但编译失败** | `HomeApplicationService` 两处硬错误 |
**Phase 14–18 真实代码量(文档称"暂停",实际有码)**
`activity_mutual` 6 · `appeal` 8 · `risk` 14 · `analytics` 2 · `relationship` 12 · `referral` 2 · `verification` 6 · `review` 11
### 2.2 小程序端(63 页)
- 完整实现约 **50 页**,空壳 **3 页**(`bind-phone` 45B、`activity-register` 89B、`my-activities` 89B),写死假数据 **7 页**(`service-center`、`service-program`、`service-appointment`、`service-history`、`my-appointments`、`content-detail`、`anti-fraud`)
- **首页固定结构 10/10 全对**:顶部品牌 / 用户状态 / Banner / 8 核心入口(顺序与命名全对)/ 今日推荐 / 善缘公益服务 / 近期公益活动 / 善缘服务站 / 婚恋课堂 / 安全提醒,且调用真实 `GET /home`
- 服务层 13 个 + stores 9 个均为真实 HTTP,无 mock 分支
### 2.3 管理后台(Vue 3)
- 23 个 `.vue`,`src` 共 4858 行;业务模块(Banner/内容/服务站/预约/咨询/专项/审核/用户)**均存在且接真实接口**
- **架构层空心**:`src/components`、`src/pages`、`src/permissions`、`src/modules/recommendation` **均为空目录**
- UI 重构仅推广到 3/17 文件,14 个仍用旧内联样式;`theme` 变量与布局硬编码冲突(220px vs 208px)
---
## 三、与 V1.1 硬规则对账(最关键部分)
| 规则 | 要求 | 实测 | 判定 |
|---|---|---|---|
| #14/#15 #17 | 首页结构 + 8 入口顺序固定 | 小程序 10/10 符合 | ✅ 通过 |
| #26 | 入口由服务端 CapabilityService 决定 | `capability/` 包存在(Controller+Service,10 处引用) | ✅ 后端具备 |
| #16 | Banner 仅内部跳转 | 待验证 target_type 枚举约束 | ⚠️ 待测 |
| #18/#19/#20 | 活动互选二阶段同意 | `activity_mutual` 有 6 个文件 | ⚠️ 待测 |
| #22 Counselor 仅 Assigned | — | 有 `CounselingDataScopeTest` | ⚠️ 待测 |
| #23 ContentEditor 零用户数据 | — | 有 `ContentControllerPermissionContractTest` | ⚠️ 待测 |
| #24 服务站不可浏览全库 | — | 仅有 `ServiceAppointmentDataScopeTest` | ⚠️ 待测 |
| **#22–#25 四新角色** | `service_station_operator` / `counseling_manager` / `content_editor` / `counselor` | **管理端 3 个角色 0 次出现**,仅 `counselor` 存在于 `stores/auth.ts` 硬编码假数据 | ❌ **未实现** |
> **红线提示**:唯一失败的测试是 `invariants.PermissionMatrixTest`。权限矩阵不通过 + 四个角色未实现,对公益平台属合规级风险,应优先于一切 UI 工作。
---
## 四、文档 vs 代码的偏差(文档失真清单)
| # | 文档声明 | 代码事实 |
|---|---|---|
| 1 | "Phase 08 及以后仍暂停" | git 已有 `phase-08`~`phase-13A` 六个 feat 提交;Phase 14–18 相关包亦有代码 |
| 2 | "未检出独立 CapabilityService" | `capability/` 包存在(提交 `dd58ab6` 即为抽取 CapabilityService) |
| 3 | "Flyway V001–V027" | 实际 V001–**V035** |
| 4 | "工作区 55 个未提交改动" | 当前 **0 个**(已收口) |
| 5 | "277 tests → 4F / 8E / 3S" | 上次快照 **293 tests → 1F / 0E / 3S** |
| 6 | 自评完成度 35% | 代码资产约 55% |
**判断**:文档更新跟不上代码推进,且昨日的评估文档(2026-09-14)结论已有 3 条被证伪。继续执行前必须先重建文档基线,否则计划会持续建立在过期认知上。
---
## 五、差距清单(按严重度)
### P0 — 阻断(必须先修)
1. **后端编译断裂**:`HomeApplicationService.java` 第 114 行使用未声明的 `userIdentityMapper`;第 133 行使用未 import 的 `LocalEligibility`。已提交入库,`target/classes` 停留在 09-13 19:20,源码 09-14 11:34。首页聚合 API 当前不可用。
2. **权限矩阵测试失败**:`PermissionMatrixTest` 1 failure,须定位是不变量实现缺陷还是测试用例缺陷。
3. **V1.1 四个新角色未实现**:管理端角色表单无角色字段,硬规则 #22–#25 无法落地。
### P1 — 业务闭环断裂
4. **小程序服务站链路全断**:`service-center` → 预约 → 我的预约 → 服务记录,4 页全为写死数组,无后端调用。
5. **登录链路断**:`bind-phone` 为 45 字节空壳。
6. **活动报名闭环断**:`activity-register` / `my-activities` 为占位;`activity-detail` 渲染写死 `previewActivity`。
7. **推荐算法是壳**:`MatchEligibilityService` 8 处 TODO(候选池、评分、推荐理由未实现),`RecommendationEngineService` 占位。
### P2 — 架构与一致性
8. 平行重复包:`messaging/` 与 `chat/` 双套会话;`relationship/` 与 `match/` 双套匹配。
9. `counseling` 双 Service 实现,完整版未接入线上。
10. 管理端 6 个已注册路由无菜单入口(`/appeals`、`/audit`、`/banner`、`/service-appointment`、`/service-program`、`/matchmaker`)。
11. 管理端架构目录(components/permissions/recommendation)为空,无复用组件与权限指令。
12. banner / service_program / home 三个模块**零测试**。
---
## 六、建议的下一步(顺序不可颠倒)
1. **先修 P0-1**:补全 `userIdentityMapper` 声明与 `LocalEligibility` import,`mvn compile` 通过后再谈其他。
2. **修 P0-2**:定位 `PermissionMatrixTest` 失败原因并清零。
3. **重建文档基线**:将 V028–V035 迁移、Phase 08–13A 完成状态、CapabilityService 现状写回 `STATUS.md` / `JIRA_BACKLOG.md`,使文档与代码口径一致。
4. **补 P0-3 角色权限**:这是 V1.1 硬规则,也是公益平台合规底线,优先级高于 UI 打磨。
5. **再推进 UI 终验**:管理端第二批 + 小程序 C 组,按参考图逐页验收。
6. **最后补 P1 业务闭环**:服务站 / 登录 / 活动报名三条链路。
> 每步完成后暂停,输出完成报告并等待人工验收,不自动进入下一步。
---
## 附:本次核验方法说明
- 代码统计使用 `grep -rl` / Glob 工具(`find` 在本机中文路径下失效,返回 0,已排除该误判)
- 编译结论为静态分析(未声明变量 + 未 import 类型),并以 `target/classes` 与源码 mtime 差作为交叉验证
- 测试结论取自 `target/surefire-reports` 汇总,为 2026-09-13 快照,非当前源码状态