• test.yml

  • tests: Defines a matrix strategy to run unit tests across different usage scenarios (compiling with different features).
  • heavy-integration: Verifies the Agent's two core capabilities when multiple users use it simultaneously: efficiently handling multiple conversations (scheduling) and accurately isolating different users' data (scoping). Uses Telegram as a representative for testing. Testing Telegram essentially tests Ironclaw's core Thread scheduling and isolation mechanisms, which are shared by all Channels. Telegram is chosen because its scenarios are the most complex (multi-topic groups, private chat mixed), maximizing the exposure of potential issues. Other Channels, as long as they correctly implement the extraction logic for thread_id, can reuse these thoroughly tested core components.
  • telegram-tests: Telegram tests are skipped when PR'ing to staging to speed up development iteration; however, they must run fully before merging to main or on push.
  • windows-build: Ensures the code compiles successfully on Windows, but doesn't actually run tests (saving time and cost).
  • wasm-wit-compat: Ensures the foundational contract (WIT interface) of Ironclaw's WASM extension system remains valid. It builds all extensions and verifies that the Host can instantiate them correctly, preventing runtime crashes caused by interface mismatches.
  • bench-compile: A "cheap check" to ensure the benchmark code (benches/) always remains compilable. It does not actually run performance tests (which would be too time-consuming), only validates code syntax and API compatibility.

  • docker-build: Validates the project's ability to be containerized via Docker. It ensures the Dockerfile remains valid and that code changes do not break containerized builds. The built image is not retained; only the build process itself is verified. A docker-build failure will show an error in Actions and cause the entire test.yml workflow to fail (provided it actually ran). If it is skipped on PR to staging, it won't trigger a failure, but the issue will surface when the code is merged to main.

  • version-check: Ensures that when a developer modifies the source code of a WASM extension, the version number in the registry must be updated in sync. This is a critical check for release management, preventing the confusion of "code changed but version unchanged."
  • run-tests: Serves as the single checkpoint for branch protection. It aggregates the results of all upstream jobs: core tests (tests/heavy-integration) must always succeed; conditional tasks (like docker-build) must succeed if they actually run, but if skipped (e.g., on staging PR), they do not affect the result.

• code_style.yml

  • format: Checks whether Rust code conforms to the formatting conventions of rustfmt.
  • deny-check: Checks whether project dependencies comply with the project's security/license policies, based on the deny.toml configuration in the project root. Includes banned crates, license compliance, security vulnerabilities, duplicate dependencies, etc.
  • clippy: Code quality check, Rust coding style check, using a matrix strategy to run static analysis across multiple feature combinations on Linux.
  • clippy-windows: Because of conditional compilation, code that doesn't exist on Linux must also be checked.
  • no-panics: Ensures that production code does not introduce panic calls that could cause program crashes. Only checks newly added code and can distinguish between test/production contexts.