JasonTM17/OpsMind_AI

# OpsMind AI OpsMind AI 是一个证据优先的 AI SRE/DevSecOps 平台。它旨在帮助运维人员调查事件、通过可追溯的证据解释假设，并在不授予 AI 模型直接基础设施权限的情况下执行经过严格审批的修复措施。 第一阶段（Phase 1）的运行边界和架构治理已完成。第二阶段（Phase 2）提供了固定版本的多语言工具链、跨平台命令接口、Compose 配置以及 PR 质量门禁。第三、四、五阶段（Phases 3, 4, 和 5）正在进行中：Platform API 现已具备本地“失败即拒绝”（fail-closed）的身份/租户/数据底层；第四阶段的 4A 检查点现已实现了嵌套式的事件创建/详情/状态转换/时间线账本。Provider、connector、evidence-object 生命周期、UI 和修复行为的实现仍由后续的检查点/阶段负责。第五阶段现已具备离线且与 Provider 无关的分析契约、DeepSeek adapter、委托式 capability/replay 防护、脱敏策略、预算防护以及流式 assembler；持久化的 PostgreSQL nonce/replay/调用记账现已包含增量 schema 和 adapter，但实时的 provider 出站流量仍处于禁用状态。 本地 PostgreSQL 证据现已涵盖连接池化的 RLS、基于单请求的 platform-user 配置撤销，以及 outbox/inbox 的崩溃时间窗口。Access-token 策略要求配置特定的 audience、MFA AMR 以及最长 `PT5M` 的生命周期。一个实时运行的本地 Windows Keycloak 26.7 参考实例已通过了非生产环境的 OIDC 一致性测试，但这并非生产环境的供应商决策或发布证明。远程 CI/Compose 及生产环境的身份一致性验证仍待解决。一个专用的、不可绕过的数据库身份和租户调度器现在负责 outbox 的 lease/ack；外部 dispatcher 循环在其所属的阶段到来前将保持禁用状态。 ## 产品目标 交付一个生产级的平台，该平台需满足： - 从授权的 metrics、logs、traces、变更记录、runbooks 和拓扑证据中调查事件； - 将观察结果、假设、置信度、建议和已执行的效果区分开来； - 通过可替换的 provider adapter 集成 DeepSeek V4 Flash； - 在进行检索、排序、生成或工具执行之前，强制执行租户隔离和授权； - 将每一次写入操作绑定到精确的预览、策略决策、审批、目标状态和审计记录上； - 衡量 RCA 质量、安全性、延迟、成本、校准度以及对运维人员的实用性； - 通过本地、CI、预发布和生产环境门禁进行部署，且不包含任何提交到代码库的 secrets； - 将测试、审计产出物、runbooks、恢复演练和评估证据作为发布的输入项。 ## 不可妥协的核心原则 1. 证据先于结论。系统绝不将未经支持的模型输出展示为已观察到的事实。 2. 模型不能直接访问基础设施凭证或广泛的租户数据。 3. 授权必须在检索和执行操作之前进行，而不仅仅是在用户界面上。 4. 只读调查是默认模式。写入操作需要策略、精确的操作审批、幂等性和可核对性。 5. 租户、操作者和作用域必须从已验证的平台 claims 中派生，而不是由调用方提供的 headers 决定。 6. 当磁盘容量或配置的存储根路径不安全时，繁重的本地计算任务将采取“失败即拒绝”（fail-closed）机制。 7. 严禁提交任何 API key、token、私钥、凭证或原始的敏感 prompt。 8. 只有当一个阶段声称的证据确实存在并通过其门禁时，该阶段才算完成。 ## 初始架构 ``` flowchart LR OP["Operator"] --> WEB["Operator Web - Next.js"] WEB --> API["Platform API - Spring modular monolith"] API --> DB["PostgreSQL + pgvector + forced RLS"] API --> OBJ["Evidence artifact port"] API --> AI["AI Runtime - FastAPI"] AI --> DSP["DeepSeek provider adapter"] API --> POL["Policy, approval and audit"] POL --> TG["Isolated Spring Tool Gateway"] TG --> OBS["Metrics, logs and infrastructure APIs"] API --> WF["Temporal - introduced after vertical-slice proof"] ``` 初步实现使用四个可部署组件：Operator Web、Platform API、AI Runtime 和 Tool Gateway。PostgreSQL 是事务状态的唯一事实来源。Redis 是可选的。事务性 outbox/inbox 的实现优先于 Kafka。Temporal 仅在确定性的调查状态机和评估基准得到验证后才会引入。 参见[系统架构](./docs/system-architecture.md)和 [ADR-0001](./docs/adr/ADR-0001-platform-topology.md)。 ## 存储安全优先 此工作站使用 `D:` 盘存放代码仓库和所有重型本地状态。在安装依赖、构建容器、下载模型、运行基准测试或启动训练之前，请运行： ``` powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\storage\check-capacity.ps1 powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\storage\assert-storage-roots.ps1 -CreateMissing ``` 便携式 Shell 命令： ``` ./scripts/storage/check-capacity.sh ./scripts/storage/assert-storage-roots.sh --create-missing ``` 默认的安全阈值是：`C:` 盘剩余 10 GB，`D:` 盘剩余 20 GB，并且每个包含工作区或已配置的缓存/产出物/数据/模型根目录的独立便携文件系统也需剩余 20 GB。检查失败将以非零状态码退出。容量检查在创建根目录之前运行；当默认的产出物根目录尚不存在时，它仅将证据信息输出到 stdout，随后根目录防护器可能会创建获批的、包含在代码仓库内的默认目录。如果缺失外部的根目录、文件系统根目录、仓库祖先路径，或者遇到 reparse/symlink 路径，检查将直接阻断，且不会为其生成默认证据。脚本绝不会执行删除、移动、清理或停止工作负载的操作。 存储契约如下： | 变量 | 用途 | 便携环境默认值 | |---|---|---| | `OPS_CACHE_ROOT` | 依赖和构建缓存 | `/.opsmind/cache` | | `OPS_ARTIFACT_ROOT` | 验证、评估、安全和灾难恢复 (DR) 证据 | `/artifacts` | | `OPS_DATA_ROOT` | 本地数据库和模拟器数据 | `/.opsmind/data` | | `OPS_MODEL_ROOT` | 模型权重和训练输出 | `/.opsmind/models` | 留空的存储变量将基于 checkout 路径进行相对路径解析，因此本工作站在 `D:` 盘上的 checkout 将保持在 D 盘上运行，而无需硬编码特定于机器的路径。 Windows 防护器会拒绝任何解析到 `C:` 盘的根目录。将 `.env.example` 复制到一个不受版本控制的 `.env` 文件中，仅用于配置白名单内的非机密本地设置。启动器不会解析 shell 语法，并会拒绝非空的机密字段。请通过进程环境变量或获批的 secret manager 提供机密信息。 ## 标准命令接口 Windows 和便携式启动器公开了相同的命令。除了 `down` 之外，每一个重型命令在执行工作前都会运行容量和存储根路径检查。 ``` Copy-Item .env.example .env .\scripts\dev\opsmind.ps1 setup .\scripts\dev\opsmind.ps1 test .\scripts\dev\opsmind.ps1 lint .\scripts\dev\opsmind.ps1 build .\scripts\dev\opsmind.ps1 security ``` ``` cp .env.example .env ./scripts/dev/opsmind.sh setup ./scripts/dev/opsmind.sh test ./scripts/dev/opsmind.sh lint ./scripts/dev/opsmind.sh build ./scripts/dev/opsmind.sh security ``` | 命令 | 当前行为 | |---|---| | `setup` | 将经过校验和验证的 actionlint 1.7.12、锁定的 pnpm workspace、锁定的 Python 环境以及 Maven 依赖项安装到配置的 D 盘缓存中。 | | `test`, `lint`, `build` | 运行代码仓库契约以及相关的 Next.js、Spring Boot 和 FastAPI 检查。 | | `dev`, `up`, `down` | 启动/停止 `application` Compose profile；`dev`/`up` 需要进程作用域的迁移和运行时数据库密码，以及显式的 Docker-storage 证明。 | | `security`, `security-scan` | 扫描仓库机密以及 Node、Python 和 Java 依赖项；Java CVSS 7+ 的漏洞会导致命令执行失败。 | | `migrate` | 打包 Platform API，并使用显式提供的 migration-role datasource 应用当前的 Flyway migrations。 | | `seed`, `evaluate` | 将以退出代码 3 显式失败，直到其所属阶段实现确定性的种子数据和评估契约。 | 对于同一个 checkout，重型命令是互斥的。`doctor` 会验证已声明的工具链，如果版本不匹配，则以状态码 6 退出。Compose 的构建/启动同样采取“失败即拒绝”（fail-closed）机制，直到操作者在验证 Docker/WSL 存储位于受监控的非系统卷后，提供 `OPS_DOCKER_STORAGE_VERIFIED=true` 环境变量。CI 在设置该标志之前会记录真实的 `docker info`/`df` 证明，并且每个语言任务都会在其独立的 runner 上重复进行容量预检。 pnpm 脚本命令在遇到问题时会直接报错，而不是悄无声息地重新安装过期的依赖项；请显式运行 `setup`，以便从冻结的 lockfile 中重新同步 `node_modules`。全局 virtual store 已被固定关闭，从而确保 setup、本地运行和 CI 都使用相同的项目本地依赖布局。 固定版本的输入包括 `.node-version` (Node 24.12.0)、`pnpm@11.15.0`、`.python-version` (Python 3.13)、`uv==0.11.29` 和 `.java-version` (Java 21)，同时 `.maven-version` 固定了 Maven 3.9.12。Bootstrap 脚本将 actionlint 1.7.12 固定到官方发布版本的 SHA-256 摘要，并在命中缓存时根据保留的发布归档文件重新进行验证。有关宿主机要求、缓存位置和失败行为，请参见[本地开发](./docs/local-development.md)。 ## 仓库导航 | 文档 | 用途 | |---|---| | [项目 PDR](./docs/project-overview-pdr.md) | 产品结果、范围、参与者、需求和验收模型 | | [系统架构](./docs/system-architecture.md) | 组件、信任边界、数据流和故障应对策略 | | [本地开发](./docs/local-development.md) | 适用于 Windows 和便携环境的安全宿主机工作流 | | [部署指南](./docs/deployment-guide.md) | 环境提升、配置、回滚和灾难恢复 (DR) 门禁 | | [测试策略](./docs/testing-strategy.md) | 测试层级和权威的发布证据 | | [评估策略](./docs/evaluation-strategy.md) | RCA、安全性、延迟、成本、校准度和人工基准 | | [数据集治理](./docs/dataset-governance.md) | 来源、同意、删除、血缘和模型撤回 | | [安全模型](./docs/security-model.md) | 资产、威胁边界、策略执行和事件响应 | | [代码标准](./docs/code-standards.md) | 仓库归属、命名、契约、错误、测试和迁移 | | [代码库摘要](./docs/codebase-summary.md) | 已验证的当前模块、入口点、契约和已实现的边界 | | [路线图](./docs/project-roadmap.md) | 十六个交付阶段及其门禁 | | [阻碍项](./docs/blockers.md) | 阻止下游工作的决策或条件 | | [进度](./docs/progress.md) | 有据可查的交付历史 | | [产品/生产契约](./docs/decisions/product-production-contract.md) | 第二阶段 (Phase 2) 的阻塞性 G0.5 决策 | | [A-Z 计划](./plans/260719-1747-opsmind-ai-production-platform/plan.md) | 详细的阶段、依赖关系、风险和完成定义 (Definition of Done) | ## 交付门禁 路线图包含十六个阶段。G0.5 记录了已批准的部署原型、目标环境、租户模型、IdP profile、DeepSeek 出站策略、首个活跃 connector、evidence store、负载/SLO/DR 边界、生命周期规则以及责任所有者。其严格的验证器已通过。第二阶段 (Phase 2) 的本地门禁和第三阶段 (Phase 3) 的信任基础切片正在独立推进。本地的 Keycloak 26.7 参考目标已于 2026-07-22 针对当前的 Platform API JAR 再次通过测试；但在更广泛的门禁关闭之前，仍需完成远程 CI、Compose smoke 测试以及授权的生产级 IdP profile。一次性的本地 PostgreSQL 18 矩阵现已证明了 migration-role 的分离、连接池化的 tenant-context 清理，以及 messaging 崩溃时间窗口的恢复能力。它还证明了对活跃 platform user 的接受，以及对未知或已撤销的 issuer/subject 映射的拒绝。web 角色可以追加 outbox 记录，但不能对其进行 lease 或确认；dispatcher 角色在获得授权的工作负载绑定之前无法看到租户。 第四阶段 (Phase 4) 的 4A 检查点增加了针对事件 CRUD 子集、幂等重放、防枚举授权、序列化的成员资格撤销、单赢家并发、原子回滚、不可变时间线、数据库计算的审计链以及全新/升级迁移路径的，绑定于源代码/JAR 的本地证明。完整的第四阶段、G2 和发布工作仍待解决。 已批准的初始 profile 为：内部使用、单一组织、新加坡区域，采用逻辑租户/项目隔离，并以托管型 Kubernetes 作为生产环境目标。 ## 证据布局 生成的证据均在本地保存并被 Git 忽略： ``` artifacts/ verification/phase-XX/ evaluation/ security/ dr/ ``` 本地的 Keycloak 记录了 schema/scenario 版本、运行时和配置摘要、命令、时间戳、`CodeRevision=UNBORN` 以及 `WorkspaceDirty=YES`。这是被忽略的本地证据，其范围为 `REFERENCE_CONFORMANCE_NOT_PRODUCTION`，并非不可变的发布证据。Linux 的 `identity-conformance` 任务配置在 `.github/workflows/pr-quality.yml` 中，但未有任何远程运行记录。缺少不可变且绑定到代码版本的产出物的本地命令成功运行，并不能作为发布的证明。 ## 当前验证 运行完整的第二阶段 (Phase 2) 本地检查，请使用： ``` .\scripts\dev\opsmind.ps1 test .\scripts\dev\opsmind.ps1 lint .\scripts\dev\opsmind.ps1 build .\scripts\dev\opsmind.ps1 security .\scripts\validation\validate-phase-02-foundation.ps1 ``` 在存储预检之后，重现本地的第三阶段 (Phase 3) 身份参考验证，请使用： ``` pwsh -NoProfile -File .\scripts\validation\run-phase-03-keycloak-conformance.ps1 pwsh -NoProfile -File .\scripts\validation\verify-phase-03-keycloak-evidence.ps1 ``` 通过的参考测试涵盖了 PKCE S256、MFA/TOTP 的负面测试路径、RP 发起的注销、refresh-token 撤销、JWKS 轮换刷新、对已禁用用户的新登录拒绝、对轮换后 refresh-token 重复使用的拒绝、用于撤销阳性对照的独立 refresh family，以及 Platform API token 拒绝。这并不能证明生产环境的部署、federation、浏览器/BFF 会话归属或上游禁用后的实时过期行为。该运行证明了在禁用后，预先签发的 JWT 仍会被立即接受，并断言其生命周期为 300 秒加上 30 秒的偏斜时间：即 330 秒的策略上限，而非测量得出的从“禁用到拒绝”的时间跨度。签入代码库的默认值使用 60 秒的偏斜时间，因此上限为 360 秒。 当前的 runner/verifier 契约使用 v2 版本的证据 schema，绑定了由 profile/源码输入组成的 manifest 摘要加上已打包的 Platform API JAR 摘要，并且仅在清理验证成功后才以原子方式发布记录。修正后的 schema 通过了耗时 124.694 秒的实时本地运行以及独立的摘要验证。如果运行失败，则只会在 `identity-delegation-failure.txt` 中输出有限的、经过净化的诊断信息；这无法满足成功验证器的要求。 在执行容量/根路径预检后，重现第四阶段 (Phase 4) 4A 检查点： ``` node .\scripts\validation\validate-phase-04-incident-contracts.mjs powershell.exe -NoProfile -File .\scripts\validation\run-phase-04-domain-tests.ps1 powershell.exe -NoProfile -File .\scripts\validation\run-phase-04-local-postgres-contract.ps1 ``` 位于 `artifacts/verification/phase-04/` 下的四个本地产出物涵盖了静态契约、25 项针对性的 domain/controller 测试、实时 PostgreSQL migrations/RLS/回滚/并发测试，以及审计链完整性。它们目前仅作为参考证据，因为此 checkout 处于 unborn/dirty 状态，且不存在远程不可变的 CI 运行记录。 离线验证第五阶段 (Phase 5) 与 Provider 无关的 runtime 检查点（无需 API key，也不会进行任何外部 provider 调用）： ``` node .\scripts\validation\validate-phase-05-ai-runtime.mjs $env:PYTHONPATH = 'services/ai-runtime/src' python -m pytest services/ai-runtime/tests -q ``` 该检查点目前涵盖了 149 个通过的离线测试，内容包括契约/fixture 验证、有界的 HTTP 入口、禁用/降级的配置、精确的出站主机和正向定价门禁、已签名的请求/TTL/重放强制执行、基于证据的分类/引用、累计的调用前/后 token 和成本上限、DeepSeek 无重试错误映射、严格的结构化响应验证、完整的流组装以及进程内重放兼容性。另外五项 PostgreSQL 测试涵盖了共享 nonce 重放、并发运行预留、租户 RLS、成功响应重放、过期租约全额计费、provider 超额时的 fail-closed 记账，以及只追加的 capability-probe 审计： ``` $env:OPS_DOCKER_STORAGE_VERIFIED = 'true' powershell.exe -NoProfile -File .\scripts\validation\run-phase-05-local-postgres-state.ps1 ``` 专用的数据库门禁目前已在 PostgreSQL 18.4 上本地通过，包含了 V004/V005，全部五项状态/审计测试均通过，且清理工作成功完成。由于此 checkout 处于 unborn/dirty 状态，其执行记录仍作为本地参考证据。实时的出站流量、Provider 条款/数据驻留审批以及 Provider 的冒烟测试证据仍属于后续阶段的门禁；跨服务的 RS256 capability 一致性已在本地得到证明。 第一阶段的治理套件和严格的 G0.5 契约仍然是先决条件。第二阶段验证涵盖了仓库所有权、Windows/便携式命令语义、lockfiles、Compose、工作流语法、机密扫描和 manifest 解析。第三阶段现在新增了 fail-closed 的 OIDC 边界、租户/RLS 迁移、强制性的 MFA AMR 和有界的 access-token 生命周期策略、基于单请求的配置撤销检查、委托契约、幂等性/乐观并发脚手架，以及 outbox/inbox 的 lease、重放、poison、精确字节和序列底层支持。事件写入账本仅存在于 4A 检查点中；在负责实施的阶段完成验证之前，不存在任何实时的 connector、模型调用、evidence-object 生命周期、完整的事件工作流、外部 dispatcher 或修复操作。 ## 安全提示 Provider 凭证是运行时机密。DeepSeek 的配置将通过 secret manager 或进程环境变量以及 provider adapter 进入系统；绝不会被嵌入到源代码、文档、fixtures、镜像层、日志、prompts 或客户端 bundle 中。任何在安全通道之外泄露的凭证，在生产环境使用前都必须进行轮换。 ## 仓库与发布治理 公开仓库的 About 面板信息是从 [`.github/repository-metadata.yml`](./.github/repository-metadata.yml) 同步而来的。请参考 [CONTRIBUTING.md](./CONTRIBUTING.md) 了解 CK 开发工作流，参考 [SECURITY.md](./SECURITY.md) 进行私下漏洞报告，参考 [SUPPORT.md](./SUPPORT.md) 获取问题解答与故障排除。最终发布必须向 Docker Hub 和 GHCR 发布相同的已签名多架构摘要，将 GHCR Package 链接到此仓库，并在发布证据中记录不可变的摘要、SBOM/provenance、扫描结果以及注册库一致性。 ## 未决问题 没有任何 G0.5 决策处于未决状态。后续阶段的一致性验证和发布门禁维护在[阻碍项](./docs/blockers.md)中。

标签：AIOps, DevSecOps, JS文件枚举, PostgreSQL, 上游代理, 事故响应, 大模型平台, 智能运维, 测试用例, 版权保护, 策略控制, 逆向工具