[r33drichards]

Adds a zero-replica, loopback-only WasmEdge canary plus a source-pinned OCI packaging workflow. Publication is limited to default-branch pushes, records an immutable digest, and makes only the resulting inspircd container package public. This PR does not unsuspend Flux, change the node runtime, or deploy a workload.

[r33drichards]

Added a bounded Ubuntu-native runwasi compatibility job. It fetches the exact containerd-shim-wasmedge/v0.6.1 commit, bootstraps the repository-pinned WasmEdge 0.17.2-rc.1, builds a dynamic shim against that runtime, checks the resulting linkage, and retains build evidence. It has no cluster, registry, or secret access.

[r33drichards]

Blocking: runwasi shim CI fails because protoc is absent; install protobuf-compiler before Cargo. Also prevent default-branch OCI publication until equivalent full WASI acceptance validates the same SHA. Canary remains safely zero-replica/loopback-only; no secret exposure found.

[r33drichards]

The protobuf-compiler remediation took effect, but the refreshed shim gate still fails at the actual compatibility boundary: wasmedge-sys 0.19.4 generates bindings from the pinned 0.17.2-rc.1 headers and encounters incompatible C API signatures (for example, page/table APIs are u64 in the headers while the crate expects u32, plus missing WasmEdge_LimitContext conversion). That means this pinned runwasi revision is not validated for our required runtime and must not be represented as a usable handler.

Merge remains blocked. Please either select a runwasi revision/dependency set demonstrably compatible with 0.17.2-rc.1 and retain its linked-binary evidence, or remove the handler compatibility claim and keep the canary suspended. The independent publication blocker also remains: build-wasi-oci.yml needs full same-job WASI acceptance before its default-branch packages: write push step.

[r33drichards]

Native CI terminal result: run 34012672148 reaches wasmedge-sys 0.19.4 and fails with 16 C-ABI binding compile errors against the checksum-pinned WasmEdge 0.17.2-rc.1; this is no longer a host-toolchain issue. The source constraint is wasmedge-sdk 0.14.0 -> wasmedge-sys 0.19.4 at pinned runwasi 5a8fc8e9. Exact incompatible API deltas include removed ffi::WasmEdge_Limit (3 E0425), 64-bit memory-page parameters/returns (7 E0308), memory/table get/set/grow signature changes (4 E0308), and WasmEdge_LimitContext replacing the value limit constructor (2 E0277). No containerd-shim-wasmedge-v1 binary was emitted, so no isolated containerd smoke can honestly run. This requires a maintained WasmEdge Rust binding/SDK port compatible with the 0.17 C API, plus runwasi integration validation; it is not safe to patch-and-deploy as a node substitution. Flux and the live node remain untouched.

[r33drichards]

Pushed 14506f699705cc5b4e8676a44981019d6ac6b0c6: the OCI workflow now runs tools/wasi/verify.sh with STRESS=1 before it calculates the SHA-256, builds any OCI layout, or reaches the default-branch GHCR push. verify.sh builds build-wasi/src/inspircd.wasm and exercises that same path, so the image COPY source is the validated module. This does not relax or bypass the separate runwasi incompatibility gate; PR remains unmergeable pending a supported handler/runtime solution and terminal CI.

[r33drichards]

Follow-up pushed: 3a6245c770544ee24358ca7e11f374da10777a6c replaces the first gate-only change with a least-privilege two-job workflow.

• validate has only contents: read, runs full tools/wasi/verify.sh with STRESS=1, verifies the module hash, and builds a non-publishing OCI layout on every matching PR and default-branch push.
• publish is default-branch-push-only, depends on validate, receives packages: write only there, and reruns full WASI acceptance before it hashes and publishes the exact build-wasi/src/inspircd.wasm copied by Dockerfile.wasi.

Thus PR code cannot receive a package-write token, and a default-branch image cannot publish without full same-job acceptance. The separate runwasi incompatibility gate is unchanged and remains a merge blocker.

[r33drichards]

The terminal OCI validation result exposed a scoped workflow defect, not a WASI failure: full acceptance passed, but type=oci export failed because the default Docker driver does not support an OCI exporter. I fixed that in 0e00501d1edaf7f6cb6a628bcd57558111577e24 by adding the immutable docker/setup-buildx-action@8d2750c68a42422c14e847fe6c8ac0403b4cbd6f setup before both OCI-layout validation and the privileged publisher. No permissions were broadened; packages: write remains exclusive to the default-branch-only publish job. The rerun will validate the OCI layout without publishing. The independent incompatible runwasi gate remains required and unchanged.

[r33drichards]

Runtime/deployment handoff: packaging is now at 0e00501d1edaf7f6cb6a628bcd57558111577e24. The OCI workflow uses a read-only validate job for full WASI acceptance plus non-publishing OCI export, and a default-branch-only publish job that alone has packages: write, depends on validation, and reruns acceptance immediately before publishing. The corrected export validation is running. Please preserve this separation while updating the native shim/binding compatibility work; do not relax the independent runwasi/WasmEdge compatibility gate or enable the suspended canary.

[r33drichards]

OCI gate terminal evidence for 0e00501d1edaf7f6cb6a628bcd57558111577e24: run 34043622467 completed success in 13m26s. Its read-only validate job passed full tools/wasi/verify.sh, verified the module identity, initialized the pinned Buildx builder, and exported the non-publishing OCI layout; its publish job was skipped because this was a PR event. The only annotation is upstream Node 20 deprecation for the pinned Docker actions; it did not affect execution.

The newer RuntimeClass compatibility head is 447afccb4497639bd23d311d464ab68dde5d1dc0 and remains blocked: its shim gate now gets through the WasmEdge binding compile but fails at final linking because the runner lacks -lseccomp. This belongs to the native-shim workflow setup; install the appropriate libseccomp development package before the build, then retain the exact linked-binary evidence. I did not alter the shim workflow or merge the PR.

[r33drichards]

Acknowledged. I have stopped all shared codex/inspircd-wasi-gitops writes. I will preserve the existing 0e00501d1 Buildx/OCI gate and only review runtime-worker commits after they are pushed to the current PR head; no force-pushes or workflow-overlap edits from this checkout. The OCI proof remains terminal-success at 0e00501d1 (run 34043622467); it will need a fresh exact-head validation after the runtime compatibility series settles.

[r33drichards]

Hillclimb handoff acknowledged. I am pausing all independent writes to codex/inspircd-wasi-gitops; the deployment worker is the sole hillclimb orchestrator and PR branch writer. Current source state: head 2c2d19436b414de0115b4099b18eccfe3b4d7307; the prior read-only OCI export proof passed for 0e00501d1 (run 34043622467); fresh exact-head shim, WASI, and OCI validations are running. Preserve the two-job OCI boundary: read-only validation, and default-branch-only package-write publication after same-job revalidation. I am available for read-only review/planning only; do not merge, publish, or enable the canary until runtime compatibility and the exact-head gates pass.

[r33drichards]

Hillclimb Summary

Result: blocked; PR remains open. The exact head is 7eb92a46303fb1789057461f686c6fe8f79326e5. The required isolated containerd/runwasi IRC acceptance has not run successfully, so this PR was not merged, no GHCR package was published, and no Flux/RuntimeClass/node/canary action was taken.

Exact-head checks

• 42 checks succeeded; one non-publishing workflow was skipped as expected.
• Validate runwasi against pinned WasmEdge RC run 34052544121 is the sole failure.
• The shim compiled and linked against the checksum-pinned WasmEdge 0.17.2-rc.1; retained run evidence includes runwasi-build.log and runwasi-ldd.log.
• The direct WasmEdge/WASI suite completed, including two IRC clients registering, joining, and exchanging messages. This does not satisfy the required containerd/runwasi RuntimeClass path.

Bounded OCI-import investigation

1. b022d2cc6 added an explicit local/inspircd:latest tag after import. CI showed that the unnamed OCI import created no image reference for that assumed source tag.
2. 8619b15cc compared containerd image references before and after import. CI proved the import produced zero named references, not an unexpected reference shape.
3. 7eb92a463 used the documented Buildx OCI name=local/inspircd:latest option and asserted the resulting OCI index descriptor carried org.opencontainers.image.ref.name. The archive was built, but that assertion failed: the exported index still lacked the expected ref-name annotation. Containerd installation, invalid-config rejection, OCI lifecycle, SIGTERM, and two-client IRC acceptance were therefore correctly skipped.

Remaining blocker

The current Buildx OCI exporter/archive does not preserve a containerd-importable named image reference under this runner/toolchain combination. A follow-up must first validate a standards-compliant tagged OCI layout or a documented containerd import path in a small reproducible experiment, then rerun the full isolated lifecycle gate. This hillclimb reached its limit of three attempts for the same OCI-naming failure; no fourth speculative workaround was applied.

Evidence is retained in the failed run artifact runwasi-wasmedge-0.17.2-rc.1-evidence and the run logs.

[r33drichards]

Read-only lifecycle review of 5def9be6dc7d6239ebba82a836126bcf8adde292 and successful run 34058970515:

1. P1 -- restart readiness can pass without a listening server. In .github/workflows/ci-runwasi-rc.yml:141, the 30-iteration TCP loop has no failure assertion after exhaustion, and line 142 immediately SIGKILLs the task. The restart path therefore proves only that ctr run created a task which can be killed; it does not prove the restarted IRC service accepts connections or serves IRC. Record an explicit ready=0, set it only on successful connect, test "$ready" = 1 after the loop, then run the same registration/numeric (001-004) and two-client exchange against the restarted instance before terminating it.

2. P2 -- the forced-cleanup comment overstates the test boundary. .github/workflows/ci-runwasi-rc.yml:127 calls a manual ctr tasks kill SIGKILL after a local 10-second wait “Kubernetes-equivalent grace expiry cleanup.” The code correctly records “SIGTERM grace period expired; forcing SIGKILL cleanup” and checks task/container absence and port closure (lines 128-137), but this is not Kubernetes behavior or rollout evidence: no pod, kubelet, RuntimeClass, controller, probes, or termination-grace policy is exercised. Rename the comment/any matching claims to bounded local containerd forced cleanup, and retain the forced-not-graceful wording.

The first-instance readiness loop at line 120 is followed by a real two-client IRC exchange at line 121, so an exhausted first loop cannot mask that test. Task/container absence and post-cleanup port closure for the first instance are asserted at lines 135-137. The successful run is shim/lifecycle CI evidence only; it is not Kubernetes rollout proof. No code changes, merge, image publication, or deployment were performed in this review.

[r33drichards]

Final read-only review: no remaining findings for the prior lifecycle P1/P2 at exact PR head bb0b8f77ca683f1fb550b2b1e345fb2b1729a63f.

• Run 34060440583 is terminal success for that exact SHA.
• The first and restarted lifecycle paths now make readiness exhaustion fatal, run the two-client IRC registration/JOIN/bidirectional-message acceptance after readiness, and assert task/container deletion and closed port after cleanup.
• Downloaded evidence includes successful first and restart IRC acceptance logs and lifecycle evidence stating SIGTERM grace period expired; forcing SIGKILL cleanup; it does not claim graceful termination.
• The wording now correctly scopes this to bounded local containerd forced cleanup, not Kubernetes-equivalent cleanup or a Kubernetes rollout.

This conclusion is limited to the checked containerd/RuntimeClass shim CI evidence. It is not Kubernetes deployment, rollout, or production qualification evidence. I made no branch changes, merge, publication, or deployment.