fix(organization): 修复创建机构审计缺操作人;补全机构修复的验证并部署 Docker 测试环境

一、机构审计归属缺陷(本轮活栈验收中新发现)
- 现象:audit_logs 中 CREATE_ORGANIZATION 的 operator_id 7/7 为 NULL,
  而 DISABLE/ENABLE_ORGANIZATION 均正确记录操作人。审计不可归属 = 无效审计。
- 根因:OrganizationController.create 持有 @AuthenticationPrincipal OperatorPrincipal,
  却只把 params 传给 Service,未透传 principal.id() → saveAuditLog(null, ...)。
- 修复:createOrganization(params, operatorId) 签名透传;新增测试断言
  createOrganizationRecordsOperatorInAuditLog 长期守卫。
- 复验:新写入的 7 条 CREATE 审计全部带 operator_id,旧 14 条仍为 NULL(前后对照清晰)。

二、补全 rc.22 的验证缺口(此前记为「已修复待验证」)
- 全量回归 757 / 0 / 0 / 3,BUILD SUCCESS,108 个测试类,6:44(基线 741 + 新增 16)。
- 负向注入:ORG_STATUS_ACTIVE 改回 "normal" → 16 例变 3 失败 + 7 错误
  (守卫三条断言各自命中 + 服务侧 7 例被 H2 CHK_ORG_STATUS 拦下)。
  注入采用「仓库只读挂载 + 容器内副本改写」,工作区哈希前后一致,源码零污染。
- 活栈实测(Docker 全栈):创建/停用/启用均 2xx、非法输入 400、不存在 404、全程零 5xx(15/15)。
- 对已部署栈 pytest tests/e2e → 65 passed。

三、Docker 测试环境部署与工具链固化
- 测试镜像 danyang-match-backend-test 与命名卷 danyang-m2-cache 因 Docker Desktop 重装丢失,
  构建定义此前是临时产物 → 落盘为仓库资产 infrastructure/test-toolchain/Dockerfile。
- 本地栈统一使用 docker compose -p danyang(原项目名 infra 与另一项目撞名,
  其 --remove-orphans 会误删本项目容器;已确认邻项目数据无丢失,见 known-risks KR-09)。

四、UI 门禁脆弱性修复
- ui-document-baseline-contracts.mjs 解析 docker-compose.staging.yml 时报假红
  (「守卫自身失效」);真因是该文件为 CRLF 而守卫正则要求 \n 紧随 container_name 之后
  (prod.yml 是 LF 所以此前能过)。解析改为行尾无关,真实断言未削弱。门禁 18/18。

五、文档
- STATUS.md 新增 rc.23 并将 rc.22 由「待验证」订正为「已验证关闭」。
- 实施计划附 B.1、PROGRESS-ASSESSMENT-2026-09-21.md 同步订正。
- known-risks.md:KR-07 解除(Docker 已恢复)、KR-01/KR-06 按复测订正,
  新增 KR-08(Docker Hub 域名 DNS 被投毒,改用国内镜像源绕行)与 KR-09(compose 项目名撞名)。

验证状态:全量回归 757/0/0/3 全绿;UI 契约门禁 18/18;对已部署栈 E2E 65/65;
负向注入可变红;工作区哈希未被注入过程污染。
未验证:GitHub Actions 首次真绿(仍未推送,见 KR-06)。
This commit is contained in:
WorkBuddy
2026-09-22 00:46:10 +08:00
parent c195133680
commit 8bd1ab804a
9 changed files with 111 additions and 31 deletions
+24 -11
View File
@@ -55,16 +55,28 @@
## 三、关键发现:一处 High 缺陷登记后未修复
### 3.1 机构创建 / 停用 / 启用三个写操作必然失败(High,**2026-09-21 已修复,待补跑回归验证**)
### 3.1 机构创建 / 停用 / 启用三个写操作必然失败(High,**2026-09-22 已验证关闭**)
> **处置更新(2026-09-21 当天)**:本项已按第五节 P0-1 执行完毕 ——
> **处置完成(2026-09-22 复核)**:本项已按第五节 P0-1 执行完毕 ——
> `Constants` 新增 `ORG_STATUS_ACTIVE/INACTIVE`、三处状态值修正、`type` 白名单前置校验、
> 测试库 `schema-h2.sql` 补两条 CHECK 及 NOT NULL/DEFAULT、
> 新增 `OrganizationConstraintParityTest` 与 `OrganizationServiceTest`(9 用例)。
> **但本机无 Docker / 无 JDK(`wsl.exe` 被安全策略阻止),`mvn -o test` 与负向注入未能执行**,
> 故当前状态为「**已修复待验证**」而非「已验证」。
> 详见 `docs/superpowers/plans/2026-09-18-phase23-closeout-and-uat-readiness.md` 附 B.1 的处置留痕
> 与 `docs/STATUS.md` 版本行 rc.22。
> 新增 `OrganizationConstraintParityTest` 与 `OrganizationServiceTest`。
>
> **2026-09-22 完成全部补跑验证(此前记为「已修复待验证」的缺口已补齐)**:
> 1. **全量回归 757 / 0 / 0 / 3,BUILD SUCCESS**(108 个测试类,6:44;基线 741 + 新增 16 = 757);
> 2. **负向注入可红**:把 `Constants.ORG_STATUS_ACTIVE` 改回 `"normal"` 后,16 个用例变
> **3 失败 + 7 错误** —— 守卫 `backendWhitelistsMatchProductionDdl` /
> `orgStatusConstantsCoverProductionWhitelist` / `orgStatusMustNotReuseAccountStatusValues`
> 三条断言各自命中该误用,服务侧 7 例被 H2 `CHK_ORG_STATUS` 拦下。注入采用
> **仓库只读挂载 + 容器内副本改写**,工作区哈希前后一致(`28aaaedb…`),源码零污染;
> 3. **活栈实测(Docker 全栈)**:创建 / 停用 / 启用**全部 2xx** 且落库为 `active`/`inactive`,
> 非法 `type` 与缺字段 400 `VALIDATION_ERROR`,不存在机构 404 `NOT_FOUND`,
> **全流程零 5xx**(15/15 通过);
> 4. **对已部署栈跑 `pytest tests/e2e`:65 passed**。
>
> **本项状态:已验证关闭。**
> 另:活栈验收中新发现同族缺陷「创建机构审计缺操作人」——`CREATE_ORGANIZATION` 审计行
> `operator_id` 7/7 为 NULL(停用/启用却正确记录),已一并修复并复验,见 `docs/STATUS.md` rc.23。
该问题于 2026-09-19 已在实施计划「附 B.1」中登记并实测复现,但截至本次评估(2026-09-21)**代码未改动**。
@@ -156,10 +168,11 @@
### 优先级 P0 — 建议立即做(无需用户决策,纯技术清偿)
1. **修复机构三个写操作 + 补测试与守卫**(3.1)。✅ **代码已完成(2026-09-21)**;
⚠️ 验收项中的「全量回归 + 负向注入 + 活栈实测」因本机无 Docker/JDK **未执行**,待在有该环境处补跑。
原验收标准:`mvn -o test` 全绿 + 新增用例经负向注入可变红 + 活栈实测
`POST /operator/organizations` 返回 2xx。
1. **修复机构三个写操作 + 补测试与守卫**(3.1)。✅ **已修复且已通过全部验收项(2026-09-22)**:
全量回归 **757 / 0 / 0 / 3 全绿**;负向注入 16 例变 **3 失败 + 7 错误**(守卫三条断言全中 + H2 `CHK_ORG_STATUS` 拦下 7 例);
活栈实测 `POST /operator/organizations` 与停用/启用**均 2xx**、非法输入 400、不存在 404、全程零 5xx(15/15);
对已部署栈 `pytest tests/e2e` **65 passed**。**本项关闭。**
附带清偿同族缺陷「创建机构审计缺操作人」(见 rc.23)。
2. **确认 Git 可用性**(4.1)。决定是否加 `safe.directory`,否则先不要写代码 —— 写了也打不了点。
### 优先级 P1 — 需用户/环境配合