witness MC/DC: harness can't invoke async-lift stream exports (composed pipeline coverage is 0/2713)

[avrabe]

Summary

witness MC/DC on the composed flight-control stream pipeline (//:falcon-cascade-stream-coverage) instruments cleanly — 2713 branches found — but the run invokes nothing (witness-run.json: invoked: [], trace rows 0), so 0/2713 branches are exercised and the LCOV is empty.

Cause

The composed pipeline's only export is the async-lift stream function [async-lift]falcon:cascade-stream/cascade-stream@0.1.0#monitor. The witness WASI harness (host/witness-wasi-harness) discovers + invokes exports, but it can't drive an async-lift stream export (streams aren't simple call-return; the harness's --invoke-with-args / WITNESS_HARNESS_INVOKES syntax is for scalar args). The earlier "memory fault at 0x100000" traces were the harness failing to invoke it, not a buffer overflow (trace_health.overflow: false).

Progress already landed (v1.75, #201)

• The witness MC/DC on the real flight component (falcon_flight_component.wasm) #145 parse gap is closed for the stream path: the composed pipeline is ONE component (engines are Rust libs) → single cabi_realloc → witness parses it. (The sync falcon-cascade-fused fuses 6 components → duplicate cabi_realloc$N → still parse-blocked, witness MC/DC on the real flight component (falcon_flight_component.wasm) #145.)
• Fixed a stale macro: witness lcov moved to --run/--manifest flags.

The ask

Populated MC/DC on the stream pipeline needs either (a) witness/harness support to drive an async-lift stream export (feed a bounded input stream, collect the output), or (b) a sync entry point on the composed component (e.g. step(cascade-input) -> motor-pwm) the harness can invoke — but the harness also needs to supply the nested-record arg. Tracking here; cross-ref #145.

[avrabe]

Core gap closed in v1.80 (PR #213): the composed cascade's MC/DC branches are now exercised — 299/2006 branches across 58 functions, up from 0.

The async-lift monitor export still isn't directly call-return invokable (that part of the title stands), but the goal — populated MC/DC on the verified cascade — is met two ways:

1. Sync (p2) coverage sibling falcon:cascade-step exporting call-return step(10× f32) → f32 over the same verified engines, sharing the iekf→pos→att→rate→mixer wiring with the stream component via a new cascade-orch rust_library (no copied pipeline). The p3 bindgen lifts every export async (async: all), so a sync entry point can't live inside the stream component — hence a sibling.
2. Harness invoke-name fix: WITNESS_HARNESS_INVOKES split name:args on :, but WIT export names (namespace:package/iface@ver#func) always contain a colon → every scripted invoke hit "export not found". Separator is now =. This unblocks scripted MC/DC for any WIT component, not just the cascade.

SWREQ-RELAY-STREAM-P16 → FV-RELAY-STREAM-016, reproduced locally (bazel //:falcon-cascade-step-coverage, witness v0.22.0).

Remaining (narrowed) follow-up — leaving this open for:

• Raising the coverage percentage beyond the ~15% finite-input plateau (residual is libm range-reduction / panic-fmt / NaN-guard cold paths) with guard-targeted or white-box vectors.
• Optionally, true async-lift stream driving in the harness (feed a bounded input stream), which would cover the literal title and let the async component itself be measured.

[avrabe]

Upstream friction filed (report-tool-friction) for the two root limitations behind this issue, so the fixes can land at the source rather than only being worked around here:

• MC/DC harness can't drive async-lift (P3 stream) exports — they aren't call-return invokable witness#107 — the harness/invoke model is call-return only; it can't drive async-lift (P3 stream) exports (the actual cause of "2713 instrumented, 0 invoked"). The real fix is upstream: drive a bounded input stream + collect output. Also flags the :-separator colon-collision with WIT export names.
• p3 bindgen forces async: all — no per-function sync lift, blocking call-return access to a single export rules_wasm_component#526 — wasi_version="p3" forces async: all, so a sync-signature WIT func still lifts async — which is why v1.80 needed a separate sync sibling. Ask: a per-function async override (async: { only: [...] }).

v1.80's sync-sibling + harness =-separator fix remains the working relay-side path; these upstream issues track removing the need for the workaround.