WorkBuddy
8bd1ab804a
一、机构审计归属缺陷（本轮活栈验收中新发现） - 现象：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）。
23 lines
5.1 KiB
Markdown
23 lines
5.1 KiB
Markdown
# 已知风险 — known-risks.md
|
||
|
||
> **版本**：V1.0.1 配置与规则纠偏基线 · **生效**：2026-09-21 · **最后更新**：2026-09-22 · **owner**：WorkBuddy
|
||
> 登记「已知但本轮不处置」的风险与债务。每项注明触发条件、影响面、处置去向。
|
||
|
||
---
|
||
|
||
| # | 风险 / 债务 | 影响面 | 处置去向 |
|
||
|---|------------|--------|----------|
|
||
| KR-01 | **minio pin tag 拉取失败（2026-09-22 复测：仍未解决）**：`minio/minio:RELEASE.2025-09-07T16-13-09Z` 在本机从 Docker Hub 与 5 个国内镜像源（daocloud / 1panel / rat.dev / nju / sjtug / 1ms.run）**全部取不到该 tag**。本机 E2E 以「把本地 `quay.io/minio/minio:latest` 重打为钉版 tag」绕过 —— ⚠️ **这是对钉版基线的偏离**，仅限本地测试环境（机构接口验收不依赖对象存储）；CI（ubuntu runner）可达 Docker Hub，不受影响。 | 本机 E2E 全栈序列；生产部署镜像拉取 | 换 pin 版本或走可拉取的镜像源；上 CI 后实测。生产 compose 未改。 |
|
||
| KR-02 | **`system_configs` 死表**：V001 建表 + seed（match_rule_version/daily_recommendation_limit/match_score_threshold='60'/recommendation_cooldown_days）+ demo-seed 一批 flag 行，**0 个 Java 读取点**；与活键 `match.*` / `features.*` 各写一份（seed 与代码漂移） | 配置可信源混淆（运维改 system_configs 不生效） | 未来迁移裁定：整体退役（DROP 需专门迁移）或接成真实配置源。见 config-drift-audit §一。 |
|
||
| KR-03 | **`match_rule_configs` 死表**（V006，含 10 维权重 + minimum_score）+ `MatchRuleConfigMapper.findActive/findByVersion` 无调用方 | 规则版本化走轻量路线（rule_version + V050 threshold_snapshot），此表闲置 | 未来项：接成「规则版本唯一读取源」或删表。见 config-drift-audit §二。 |
|
||
| KR-04 | **打分占位未产品化**：`calculateScore` 恒 50.0、互选公式 0.6/0.4、level 分档 80/60 均硬编码（V1 占位） | 推荐分数无业务含义，不得对外包装「匹配成功率」 | 正式化时随 10 维权重一起配置化 + 记入规则版本（open-questions OQ-MATCH-001 关联项）。 |
|
||
| KR-05 | **本地资格佐证到期清理作业未实现**：`features.localEvidenceRetentionDays=365` 仅配置，无 @Scheduled 清理任务（文件本体交对象存储生命周期规则兜底） | 佐证文件可能超期留存 | Phase 22 运维任务（Phase-04 报告 :46 登记）。 |
|
||
| KR-06 | **GitHub Actions 实测未跑**：E2E 65/65 与回归 757 / 0 / 0 / 3 均为本机实测（2026-09-22 复跑）；CI 流水线仍未推过一次绿 | 「CI 绿」仍依赖一次推送。注意本机与 runner 的差异：**E2E 作业的 docker CLI 必须在 PATH 上** —— 本机实测该点会让 16 个依赖 `docker exec` 取库内 fixture 的用例报 `FileNotFoundError`（不是产品缺陷） | 批 3 遗留项（Phase 24 启动前）；一次 push 触发。 |
|
||
| KR-07 | ~~**本机 WSL/Docker 环境故障（2026-09-21）**~~ → **2026-09-22 已解除**：Docker Desktop 由用户启动后引擎正常（Server 29.8.0 / linux / 16 CPU / 8GB；CLI 位于 `D:\Data\Docker\DockerDesktop\resources\bin\docker.exe`，**不在 PATH**）。`wsl.exe` 仍被安全策略阻止（Program Blacklist，不可审批绕过），但本机容器路径已不依赖 WSL。 | 原生 docker 路径可用；本机全栈部署与 E2E 65/65 均已实跑 | 无（已闭环）。后续在本机跑容器需用 CLI 绝对路径，或自行把该 bin 加入 PATH。 |
|
||
| KR-08 | **Docker Hub 域名 DNS 被投毒（本机网络，2026-09-22 实测）**：`registry-1.docker.io` → `31.13.95.37`（Facebook 段）、`auth.docker.io` → `162.125.32.15`（Dropbox 段），**均为伪 IP** → `docker pull` 一律超时。宿主机对这两个域名的直连探测有正常响应（401/405），说明是**解析层**被污染而非出口被封；Maven Central 与 apk 源均正常可达。 | 本机所有需要拉取 Docker Hub 镜像的构建（temurin / node / nginx / postgres / redis / minio） | 绕行：从 `docker.m.daocloud.io` 等国内镜像源拉取后 retag 成本地名（本轮已实测可行）；Maven 侧改用阿里云源（实测 5337 vs 685 KB/s）。**未改 daemon DNS**，避免影响用户其他网络行为。 |
|
||
| KR-09 | **compose 项目名撞名（本机，2026-09-22 实测已造成实际破坏）**：本机另一项目 `AI智习室` 位于 `E:\develop\AI智习室\ai-study-room\infra`，**同样以 `-p infra` 为项目名**；其重新部署带 `--remove-orphans` 时，会把本项目以 `infra` 为项目名起的容器当作孤儿容器**删除**（本轮已实测发生：`danyang-match-postgres` / `-redis` 被清）。已确认邻项目 Postgres 卷未被重新初始化、**数据无丢失**。 | 本机多项目共用 `infra` 项目名时的容器互删 | 本项目本地栈统一改用 `docker compose -p danyang`；如需彻底隔离，各项目应使用互不相同的项目名。 |
|
||
|
||
---
|
||
|
||
*最后更新: 2026-09-22 — KR-07 解除（Docker 已恢复）；新增 KR-08（Docker Hub DNS 投毒）与 KR-09（compose 项目名撞名）；KR-01 / KR-06 按复测结果订正。*
|