Close the meld→kiln end-to-end seam: run a meld-fused core module on kiln and assert behavioural equivalence

[avrabe]

Why

meld's test suite verifies fusion/adapters/transcoding via synthetic two-memory wasmtime modules + real-adapter wasmparser::Validator checks, but repeatedly discloses (CHANGELOG v0.32.0/v0.33.0, SR-41/SR-32 verification notes) that the full async-lift / resource / stream e2e is "kiln-gated" and out of scope for this repo's tests. That seam — meld lowers a composed component → the fused core module runs on a real runtime → an export is invoked and returns the expected result — is currently unproven end-to-end for meld output specifically.

This is the highest-value missing verification: every adapter/transcode/resource/stream guarantee meld ships is a structural/synthetic claim until a real runtime executes the fused module and the observed behaviour matches the un-fused composition.

Grounding (not speculative)

• meld side: no e2e/integration-on-runtime test exists; the kiln-gated disclosure is explicit in the CHANGELOG and SR verification descriptions.
• kiln side: hosting-and-invoking a composed component is itself still open — kiln#344 ("Enable Component Model hosting in kilnd: run an external composed component + invoke an export"). kiln**test(e2e): Tier C — meld→kiln execution seam (#297), #[ignore]d on kiln#364 #317** covers a synth-lowered async core module e2e, not a meld-lowered one. kiln**chore: release v0.8.0 #149** (linking/call_indirect/exception execution failures) may block first.

Proposed scope (incremental)

1. Tier A (sync): a fixture of 2–3 small components with a cross-component pointer-passing call (string/list param+result). Fuse with meld → run the core module on kiln (kilnd --component or the core-module path) → assert the export's result equals the behavioural oracle (the same call across the un-fused components). Gate on kiln#344.
2. Tier B (resource): a borrow/own handle crossing a fused boundary (exercises the resource_graph attribution + handle pass-through, SR-25/resource_graph: two latent resource-attribution weaknesses (reachability unconfirmed) — Mythos sweep 2026-06-17 #295).
3. Tier C (async/stream): a guest-to-guest stream<T> (SR-33) and an async-lift export (SR-32), once kiln#317-class async e2e lands.

Dependencies / coordination

Blocked on kiln#344 (host+invoke) and likely kiln#149 (execution failures). Suggest a shared golden-fixture set reusable by both repos' CI. This issue tracks the meld-output half; kiln#344/#317 track the runtime half.

Note

This is verification-closure, not a known defect — meld's structural oracles are strong and adversarially gated. But "the synthetic oracle passed" is not "a real runtime ran it correctly"; this issue exists to convert the kiln-gated disclosure into an actual green e2e.

[avrabe]

Correction — the seam is PARTIALLY proven on real hardware (via jess), not unproven

My original framing ("nobody has demonstrated a meld-fused module on a real runtime/hardware") was overstated — it looked only at meld's repo-local tests. The cross-project e2e already exists in jess (the hardware-integration / HIL hub):

relay (falcon flight component, CCSDS + relay-sec)
  → meld (fuse) → loom (optimize fused whole) → synth (wasm → ARM Cortex-M)
  → falcon firmware (Cortex-M ELF)
  → kiln (QM validation runtime) + Renode (HIL emulation)
  on gale (Verus+Rocq-verified Zephyr RTOS primitives)
  → Pixhawk 6X-RT (i.MX RT1176)

So meld output is exercised end-to-end through a real wasm→embedded pipeline toward real drone hardware (Renode HIL now; on-FMU/real flight in progress — jess#62, Phase 2). meld is also used to fuse gale/kiln themselves as wasm in some configs.

Rescoped: what's genuinely still missing (not "the whole seam")

1. meld-repo-local e2e smoke — meld's own CI still has no execution test; the behavioural proof currently lives in jess, not here. A small in-repo "fuse → run → assert export" smoke (even via kiln QM-runtime or Renode) would let meld catch a fusion regression at its PR time instead of at the jess integration boundary. This is the real meld-side gap.
2. Tier coverage on the real path — confirm which of {sync cross-component call, resource handle, guest-to-guest stream (SR-33), async-lift (SR-32)} the relay/falcon component actually exercises through jess, and add fixtures for the tiers it doesn't.
3. Keep this issue as the meld-output verification-closure tracker; the hardware/HIL half is owned by jess (and kiln#344/test(e2e): Tier C — meld→kiln execution seam (#297), #[ignore]d on kiln#364 #317). Cross-linking jess here.

Net: downgrade severity — this is "tighten meld's local verification + map tier coverage," not "the pipeline is unproven."

[avrabe]

Seam tested — and it's currently BROKEN (grounded repro)

Stood up the Tier-C check (run a meld-fused core/component on kiln, compare to the wasmtime reference). The very first smoke test found the meld→kiln seam does not work today:

Repro (kiln @ local HEAD, kilnd debug build):

# original wasi:cli command runs on kiln:
kilnd hello_c_cli.wasm --component --wasi
  → "Hello wasm component world from C!"  ✓  Components executed: 1

# meld-fused (--component) of the SAME input FAILS on kiln:
meld fuse hello_c_cli.wasm --component -o fused.wasm
kilnd fused.wasm --component --wasi
  → ✗ Execution failed: [Runtime][E03ED] No core instance exports _start — module exports not properly loaded

Characterization (not a meld interface regression):

• Component-level WIT is identical between original and fused — both export wasi:cli/run@0.2.6 (verified via wasm-tools component wit). meld preserves the export surface.
• wasmtime runs both (golden_e2e Tier A/B pass) by instantiating the component and calling wasi:cli/run through the canonical ABI.
• kiln instead looks for a core-instance _start export. A simple wit_bindgen command has one core module exporting _start; meld's --component wrap emits four core modules (stubs + fused + fixup + caller) with a deferred start (the caller module invokes it), so no single core instance exposes _start where kiln looks.

So: meld's fused component is spec-valid (wasmtime executes it via wasi:cli/run), but kiln's component executor can't run it because it assumes a single-core-module _start convention rather than driving the component's wasi:cli/run canonical entry.

This is the seam #297 exists to close, and it's a blocker for the jess/gale pipeline (meld → kiln execution). Likely a kiln-side fix (execute components via their wasi:cli/run canonical entry like wasmtime, not via a raw core _start), but worth confirming whether meld should/could also surface a conventional _start. Recommend: (1) a kiln issue for the execution-model gap; (2) a meld golden_e2e Tier-C test, #[ignore]d with this reason until kiln runs fused output, so the seam is pinned and flips green when fixed.

Repro artifacts are local; hello_c_cli.wasm is from the kiln repo root.

[avrabe]

Test side landed as #317 (Tier C in golden_e2e), and the seam blocker is filed as pulseengine/kiln#364.

• test(e2e): Tier C — meld→kiln execution seam (#297), #[ignore]d on kiln#364 #317 adds the kiln-execution tier, #[ignore]d on kiln#364, verified it fails for exactly the documented cause (unfused baseline runs on kiln; fused doesn't). Un-ignore when kiln#364 lands → it pins this seam green.
• kiln#364 = kiln's component executor requires a core-instance _start; suggested fix is to drive the component's wasi:cli/run canonical entry (as wasmtime does).

#297 stays open until kiln#364 is fixed and Tier C is un-ignored + green.

[avrabe]

Tier-C status: kiln#364 resolved — command-component execution now works; meld-fused seam re-blocks on kiln#375 (E5DC2)

Re-checked the Tier-C seam now that kiln#364 closed (kiln#374, wasi:cli/run canonical entry). Grounded results against a freshly-built post-#374 kilnd (worktree HEAD 7da71412):

Progress — the #364 gate is genuinely gone. The unfused original command component now executes on kilnd:

$ kilnd hello_c_cli.wasm --component --wasi
✓ Execution completed successfully   (Components executed: 1)

(Previously: "No core instance exports _start".) So kiln#364 delivered.

New blocker — meld-fused --component fails one layer deeper:

$ meld fuse hello_c_cli.wasm --component --memory multi -o fused.wasm   # v0.37.0
$ kilnd fused.wasm --component --wasi
✗ [ComponentRuntime][E5DC2] wasi:cli/run export references an out-of-bounds component instance index

Attribution — meld's output is spec-valid. The same fused.wasm runs on the reference runtime:

$ wasmtime 41.0.0 run fused.wasm
Hello wasm component world from C!   (exit 0)

Same bytes, wasmtime accepts / kilnd rejects ⇒ the defect is in kilnd's component-instance resolution for a multi-core-module fused component, not meld. This matches kiln#364's own closing caveat (verified only on a self-contained single-core run fixture, not a real meld-fused one).

Filed / coordinated: grounded reproduction added to kiln#375 (the multi-core instantiation follow-up #364 opened) — flagged that E5DC2 (export→instance-index) appears distinct from and earlier than #375's user-import linking; split is kiln's call.

Disposition: #297 stays open. The Tier-C test tier_c_fused_executes_on_kiln is re-pointed from kiln#364 → kiln#375; it un-ignores and pins the seam green once kilnd runs the meld-fused component. No meld-side defect — the fusion output is correct (wasmtime-proven).

[avrabe]

Blocker sharpened: E5DC2 now root-caused as kiln#382 (split from kiln#375)

kiln split the E5DC2 failure into its own root-caused issue — kiln#382: resolve_command_entry treats the wasi:cli/run export's index as a defined-only index into parsed.instances, missing the -K instance-import offset.

Corroborated from the meld side by inspecting the fused component's index space: the hello_c_cli --component --memory multi wrap imports K=13 instances (all the wasi:cli/io/random ones) before the defined run instance, so export.idx (~13+) overruns the defined-only vector → E5DC2. (Same bytes still run clean on wasmtime 41, so meld's output is spec-valid.)

So #297's dependency chain is now precise:

1. kiln#364 (kilnd _start gate) — resolved (kiln#374).
2. kiln#382 (E5DC2, the immediate failure — -K offset in resolve_command_entry) — the current blocker.
3. kiln#375 (cross-core user-import linking) — the next layer the seam may hit once #382 lands.

The Tier-C test tier_c_fused_executes_on_kiln is re-pointed kiln#375 → kiln#382 (immediate) accordingly; kiln#382 explicitly names this test as what its fix un-blocks. Offered kiln the exact fused.wasm as a verification fixture. #297 stays open.

[avrabe]

kiln#382 landed → seam advanced past E5DC2 → new blocker E0BBB

Re-verified the Tier-C seam on post-#382 kilnd (kiln v0.4.0):

• ✅ kiln#382 (E5DC2) fixed — the fused component now resolves the run instance and "initialized and running successfully" (was: out-of-bounds instance index).
• ❌ New blocker: [Runtime][E0BBB] Export not found when invoking the run export.
• Differential oracle: the same fused.wasm runs on wasmtime 41 (Hello wasm component world from C!), so meld's output remains spec-valid — E0BBB is the next kiln-side layer.

Filed the grounded repro on kiln#375 (multi-core umbrella; may get split like #382). #297 stays open; blocker advances kiln#382 (closed) → E0BBB (kiln#375). Will re-point the Tier-C test's ignore ref off the now-closed #382 to the open umbrella.