• test.yml
  • tests：定义矩阵策略，在不同的使用场景（编译不同的特性）中运行单元测试
  • heavy_integration: 验证 Agent 在多人同时使用时的两大能力：既能"高效处理"多个对话（调度），又能"准确隔离"不同用户的数据（作用域）。用Telegram作为代表进行检测。测试 Telegram 实际上是在测试 Ironclaw 核心的 Thread 调度与隔离机制。这些机制被所有 Channel 共用。选择 Telegram 是因为它的场景最复杂（多话题群组、私聊混合），能最大程度暴露潜在问题。其他 Channel 只要正确实现 thread_id 的提取逻辑，就能复用这些经过严格测试的核心组件。
  • telegram-tests: Telegram 测试在 PR 到 staging 时跳过，加速开发迭代；但在合并到 main 前或 push 时，必须完整运行。
  • windows-build: 确保代码在 Windows 上能编译通过，但不实际运行测试（节省时间和成本）
  • wasm-wit-compat: 确保 Ironclaw 的 WASM 扩展系统的基础契约（WIT 接口）始终有效。它构建所有扩展并验证 Host 能正确实例化它们，防止接口不匹配导致的运行时崩溃。
  • bench-compile: "廉价检查"，确保性能测试代码（benches/）始终保持可编译状态。它不实际运行性能测试（那样太耗时），只是验证代码语法和 API 兼容性。

  • docker-build: 验证项目的 Docker 化能力。它确保 Dockerfile 始终有效，代码变更不会破坏容器化构建。构建的镜像不保留，仅用于验证构建过程本身。docker-build 失败会在 Actions 中显示错误，并且会导致整个 test.yml 工作流失败（前提是它实际运行了）。如果 PR 到 staging 被跳过，则不会触发失败，但代码合并到 main 后一定会暴露问题。

  • version-check: 确保当开发者修改了 WASM 扩展的源码时，必须在 registry 中同步更新版本号。这是发布管理的关键检查，防止"代码变了但版本没变"的混乱情况。
  • run-tests：是分支保护的"单一检查点"，它汇总所有前置 Job 的结果：核心测试（tests/heavy-integration）必须永远成功；条件性任务（docker-build 等）如果实际运行则必须成功，如果被跳过（如 staging PR）则不影响结果。
• code_style.yml
  • format: 检查 Rust 代码是否符合 rustfmt 的格式化规范
  • deny-check:检查项目依赖是否符合项目安全/许可证策略,根据项目根目录的 deny.toml 配置进行检查。禁止的 crate、许可证合规性、安全漏洞、重复依赖等
  • clippy:  代码质量检查，Rust编码风格检查，使用矩阵策略在 Linux 上运行多种 feature 组合的静态分析
  • clippy-windows: 因为有条件编译，所以要检查在 Linux 上根本不存在的代码。
  • no-panics: 用于确保生产代码中不会引入可能导致程序崩溃的 panic 调用，只检查新增代码，且能区分测试/生产上下文