[Bug]: CI omits maintained runtime simulation and interoperability suites #31

Affected module or tool

GitHub Actions Go CI (.github/workflows/ci.yml), local runtime simulation, and KMS interoperability acceptance.

Version or commit

f57274e15274adbd96fc90ed9862398d6bf16f58 (main after PR #30).

Environment

GitHub-hosted Ubuntu 24.04; Go version from go.mod; CGO_ENABLED=0. Audit based on the workflow, its invoked scripts, and completed run https://github.com/rambow-cloud/powertools-lambda-go/actions/runs/37222506346. This report does not claim the Docker suites were rerun at this commit.

Minimal reproduction

1. Inspect the successful run above: its only Go CI job is Modules and Lambda artifacts.
2. Inspect tools/modules.py check: it runs packaged go test ./..., vet, tidy verification, and independent consumer builds for all 31 repository modules / 28 public modules.
3. Compare with the maintained simulation entry points:
   • integration/local/run.py builds both architectures, runs Lambda RIE with capture and Valkey containers, executes the actual TypeScript/Go idempotency cache bridge, and invokes integration/local/stream_run.py --reuse-builds.
   • integration/local/batch_report.py asserts Batch behavior from the current runtime's saved logs/spans.
   • tools/reference/generate-datamasking-kms.mjs --verify-go <executable> verifies current Go-generated ciphertext with the actual pinned TypeScript provider using the integration/kmsinterop executable.
4. None of those runtime/interoperability entry points appears in any current Actions workflow. Compiling integration main packages with go test does not invoke their handlers or Docker runners.

Expected behavior

Pull requests and main pushes should automatically execute the maintained local synthetic runtime and cross-language interoperability suites and fail when a runtime assertion, bridge assertion, or cleanup fails. Runtime evidence must belong to the tested commit.

Actual behavior

CI includes checked-in Go reference corpora, including the 56 UTF-8 cases added by PR #30 and the integration masking/Kafka Go tests. It does not include the Docker Lambda RIE suite, streaming suite, saved Batch acceptance, actual Valkey/TypeScript cache bridge, or Go-to-TypeScript KMS reverse bridge. The amd64/arm64 build steps target examples/basic, rather than rebuilding the full runtime fixtures for both architectures.

The latest documented local runtime milestone (2026-10-04, before this commit) records 904 RIE assertions, 95 streaming checks, and 14 Batch checks. The separately recorded KMS reverse bridge has 108 assertions. Existing success records are historical acceptance, not fresh CI results for the current commit. A green CI run therefore cannot detect failures specific to these omitted execution paths.

Acceptance criteria or proposed fix

• Add CI execution of the maintained synthetic runtime suites on PRs and main pushes, installing reference dependencies with the committed npm lockfile.
• Reuse the passed module checks and invoke integration/local/run.py --skip-module-checks to rebuild normal/streaming fixtures for Linux amd64 and arm64; execute the current supported amd64 Docker runtime. The runner already includes streaming and the live Valkey/TypeScript bridge.
• Run integration/local/batch_report.py against evidence from that same run.
• Build integration/kmsinterop and execute the existing Node --verify-go path, preserving its local synthetic KMS boundary and keeping generated reports as artifacts rather than committing CI output.
• Upload commit-associated runtime/streaming/Batch/KMS acceptance summaries and failure diagnostics; propagate assertion/cleanup failures into the job result.
• Keep CGO disabled, pinned containers, isolated local endpoints, synthetic credentials, and container/network cleanup. No AWS secrets, account/profile setup, or cloud resources are required.
• Document that checked-in reference corpora run as Go tests; fixture regeneration is a distinct operation and is not currently executed by CI. Do not claim exhaustive compatibility or live AWS-service acceptance.

Before submitting

• Searched existing issues; no duplicate runtime CI coverage issue found.
• Report contains only public commits, synthetic fixtures, and sanitized workflow evidence.