admin/danyang-match
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: 二次修正 features 断言失实（5 处）—— 原判据「*.yml 无 features 块」被证伪

Browse Source 
Phase 22 复验报告 D-22-D 的判据「backend/src/main/resources/*.yml 无 features: 块」是错的，
且被上一轮收尾照抄进 STATUS.md（P26-T06 行），属二次传播。

实测事实：
- application.yml（基础）            → 无 features 块
- application-dev.yml（默认激活 profile，自 63cbbff）→ 有，21 键
- application-docker.yml（自 730dddd / Phase 23B）  → 有
硬证据：dev 的 chat-image-enabled: true 覆盖了 FeatureFlagConfig 的 Java 字段默认 false ——
若「仅 Java 字段默认值生效」成立，该值不可能为 true。

仍然成立的部分：T01~T05 模块开关与 T07 私有桶确实全仓零业务调用点（实测 12 个 flag 的
调用点计数全为 0），「死配置」结论正确；失实的只是来源（非 application.yml、非「仅 Java 默认值」）。

新发现 D-22-E：AppController#getConfig（GET /app/config）返回一份硬编码 features map
（imageChatEnabled 恒 true，键名与后端 chatImageEnabled 不一致）→ 与 FeatureFlagConfig 双源，
前端读到的开关可能与实际配置相反（如 appealEnabled 实际默认 false）。不静默改契约，登记为遗留。

修正落点：STATUS.md（P26-T06 行 / Phase 22 段 / 历史声明块）、Phase-22 报告（表格行 + D-22-D +
新增 D-22-E）、JIRA_BACKLOG.md、Phase-V11-Deployment-Completion-Report.md、
治理报告新增第九节（含「同一文件并行 Edit 会随机丢失」的事故记录与纪律）。
This commit is contained in:
WorkBuddy
2026-09-18 21:58:58 +08:00
parent f63e579a8d
commit 6b2ff0f73e
5 changed files with 87 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/文档治理报告-2026-09-18.md
+73 -2
View File
@@ -170,13 +170,84 @@ naive 扫描得 **29 处**，其中 **24 处合法**（出现在「已删除对
**仍需处理（不属文档治理范围，需决策/另开一轮）**：
1. **Phase 24（UAT）启动需用户确认** —— 后端 669 全绿、UI 门禁 14/14，但 Phase 23 的 E2E 入 CI 仍受
「活栈供给方式」基础设施决策阻塞（见收尾计划批 2）。
1. **Phase 24（UAT）启动需用户确认** —— 后端 669 全绿、UI 门禁 14/14、**E2E 已在本机真实执行（49 passed）**；
「活栈供给方式」决策已于 2026-09-18 落地为 Compose in CI（见收尾计划 Task 2.3），仅余「在 GitHub Actions
上跑一次绿」需在有 Docker Hub 出口的环境完成。
2. **`Phase-V11-Deployment-Completion-Report.md` 路径仍在（内容已是废止声明）** —— 若后续确要真正移除，
须连同 `Phase-01` / `Phase-13A` 两处引用一并处理，并遵守本机删除红线（优先原地重写）。
**执行纪律**：删除类改动仍应分 3 个 commit（①删除 ②归档+头注 ③状态同步+计划+报告）+ 每 commit 后 `git tag`（**单段名**，分支名含 `/` 会被实时清理）+ `git bundle create .workbuddy/backup/<phase>-recovery-<date>.bundle --all`，**并且必须**用 `git bundle list-heads <file> | grep refs/heads/main` 确认指向的是最新提交（否则等于没有安全网，见 D7 补记）。
---
## 九、遗留清偿第二轮（2026-09-18 夜）—— 活栈供给决策 + features 失实二次修正
### 9.1 活栈供给方式：已决策（Compose in CI）
**决策**：CI 的 E2E 活栈在 runner 内用 `docker compose` 起全栈（postgres + redis + minio + backend）。
**备选（未采纳）**：service containers + runner 上 `mvn package` 后 `java -jar` —— 需为后端另写一套 host
网络配置，等于制造**第二条与本地不一致的路径**，且增加一份与生产无关的分歧。
**本机实测（与 CI 同一序列），2026-09-18**：
| 环节 | 结果 |
|---|---|
| 中间件 healthcheck | postgres / redis / minio **全 Healthy**（`pg_isready` / `redis-cli -a … ping` / `mc ready local`） |
| backend 就绪 | `GET /api/v1/health/live` → **200** |
| seed | 幂等可执行（`INSERT 0 0`；`pgcrypto` 已存在跳过） |
| E2E | **`pytest tests/e2e` → 49 passed in 9.31s** |
> 本机限制（如实记录）：Docker Hub 不可达（`auth.docker.io` Bad Gateway）且本地无 temurin 基础镜像 →
> **未复现 `--build`**；改用本地既有 `danyang-match-backend:latest`（2026-09-09 构建）为底座，挂载**当日
> 16:24 构建的 jar**，使被验证的**代码版本与 CI 一致**。若不换 jar，就是拿 09-09 的旧代码验 09-18 的用例，
> 结论无效（该镜像 `Created` 为 `2026-09-09T04:02Z`，已实测确认）。
**顺带修掉的 6 个 CI 真实缺陷**：① minio 滚动 tag（pin `RELEASE.2025-09-07T16-13-09Z`）；② `up` 未显式列出
minio（而其 healthcheck 是 backend 启动前置）；③ `up --build` 耦合构建与起栈、失败日志混杂；④ 就绪窗口 5min
偏紧（首次构建后仍需 Spring 启动 + Flyway 46 迁移）；⑤ **缺 `down -v` 前置清卷** —— seed 用
`ON CONFLICT (username) DO NOTHING`，残留卷会让口令停留在上一轮 → 401 且**伪装成业务失败**（本机复用旧库时
已实际踩到，须手工 `UPDATE` 密码才能跑）；⑥ job 无 timeout（默认 360 分钟）→ 加 `timeout-minutes: 30`。
**被实测否定的一个假设**：`pytest -v` 会从仓库根误收集 `tests/*_test.py`（其在 import 期依赖 `psycopg2`
与 `E2E_DB_PASSWORD`，会成 collection error）—— **不成立**：`pytest.ini` 的 `testpaths = tests/e2e` 已限定，
实测从根收集正是 49 个用例且无 error。仍显式写成 `pytest tests/e2e -v` 作为兜底。
### 9.2 features 断言失实：二次修正（5 处文档）
**背景**：本轮自查发现 Phase 22 复验报告 D-22-D 的判据「`backend/src/main/resources/*.yml` 无 `features:` 块」
**是错的**，而上一个收尾轮又把该错误结论照抄进了 `STATUS.md`（P26-T06 行）—— 属**二次传播**。
**实测事实（可复核）**：
| 文件 | 是否有 `features:` 块 | 依据 |
|---|---|---|
| `application.yml`（基础） | ❌ 无 | `grep -rn "^features:" backend/src/main/resources/` 只命中 dev / docker |
| `application-dev.yml` | ✅ 有（21 键） | 自 `63cbbff` 起；且 `spring.profiles.active: dev` → 它是**默认激活**的 profile |
| `application-docker.yml` | ✅ 有 | 自 `730dddd`（Phase 23B）起；compose 设 `SPRING_PROFILES_ACTIVE: docker` |
**硬证据**：`application-dev.yml` 的 `chat-image-enabled: true` **覆盖**了 `FeatureFlagConfig` 的 Java 字段
默认 `false` —— 若真如原判据所称「仅 Java 字段默认值生效」，该值不可能为 `true`。
**修正落点（5 处）**：`STATUS.md`（P26-T06 行 + Phase 22 段 + 历史声明块）、`Phase-22-…-Report.md`（表格行 + D-22-D）、
`JIRA_BACKLOG.md`、`Phase-V11-Deployment-Completion-Report.md`。
**仍然成立的部分**：T01–T05 模块开关与 T07 私有桶**确实**全仓零业务调用点（实测 12 个 flag 的调用点计数全为 0）
→ 「死配置」结论正确；原文失实的只是**来源**（非 `application.yml`、非「仅 Java 默认值」）。
**本轮新发现 D-22-E**：`AppController#getConfig`（`GET /app/config`）返回一份**硬编码** features map
（`imageChatEnabled` 恒 `true`，键名与后端 `chatImageEnabled` **不一致**）→ 与 `FeatureFlagConfig` **双源**，
前端读到的开关可能与实际配置相反（如 `appealEnabled` 实际默认 `false`）。不静默改契约，如实登记遗留。
### 9.3 操作事故：同一文件并行 Edit 会丢失改动
**现象**：对同一文件在一条消息里发起多个 Edit，**会随机丢失**其中若干处（读-改-写竞争）。
本轮实测：`STATUS.md` 3 处**丢 1 处**、`ci.yml` 3 处**丢 2 处**、`Phase-22-…-Report.md` 2 处**侥幸全中**。
每处都回报「Successfully edited」—— **成功回执不可作为落盘证据**。
**纪律**：① 同一文件的多处改动**必须串行**（一次一个 Edit，等结果返回）；
② 任何批量改动后**必须回读确认每一处都在**（本轮即靠回读发现 `timeout-minutes` 与 `pytest tests/e2e -v` 丢失）。
---
*报告生成: 2026-09-18 — 对应方案任务五；处置明细见 `docs/superpowers/plans/2026-09-18-phase23-closeout-and-uat-readiness.md`*