Changing a runtime behavior

When an MR changes what a generated Go or Rust assembly does, or how a runtime test checks it, update the docs in the same MR.

1. Change the rules in the feature’s contract doc, for example the HTTP adapter contract. If the feature has no contract doc yet and the rules aren’t obvious, add one under docs/design/.
2. Add or update the test in both runtime scripts. Put a shared assertion in tests/runtime-checks.sh only when both runtimes share the expectation, and keep runtime-specific setup in that runtime’s script. List the cases in the contract doc’s tests section.
3. Update the runtime support row only when the feature’s status, known differences, or checking assertion changes. A new feature gets a new row. When an in-flight feature ships, move it from “In flight” to “Features”.
4. If support or a test is intentionally missing in one runtime, mark it ⚠️ or ❌ and link an assigned follow-up with completion criteria. Owner, schedule, and progress live in the follow-up. When it’s fixed, update the row and close the follow-up.

Running the runtime tests

From the root of a trusted checkout, with mise activated in your shell:

mise install
./tests/integration-go.sh
./tests/integration-rust.sh

You’ll need Rust and Cargo, Go, copier, curl, protoc, and network access. The native path doesn’t need Docker.

In .gitlab-ci.yml, the test:runtime job runs both native scripts on every MR pipeline and blocks merge.

The --release jobs add cross-compilation, OCI packaging, and container runs. They run on the default branch, schedules, and every MR pipeline, and also block merge. See each script’s header for its prerequisites: tests/integration-go.sh and tests/integration-rust.sh.