一、机构审计归属缺陷(本轮活栈验收中新发现) - 现象: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)。
5.1 KiB
5.1 KiB
已知风险 — 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 | 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 按复测结果订正。