witness MC/DC on the real flight component (falcon_flight_component.wasm)

[avrabe]

Today's witness MC/DC evidence covers only the coverage_subjects/ fixtures (a hand-authored WAT module + the geofence_subject_rs mini-crate). Those are TOOL-CALIBRATION subjects — they prove witness measures MC/DC correctly against a known truth table; nothing hand-crafted flies. The honest gap: no MC/DC truth table exists for the ACTUAL flight code (deferred at v0.15.1). Now unblocked: the real core ships as falcon_flight_component.wasm (v1.26+, wasmtime-verified). Work: run witness on the real component (build via scripts/build-flight-component.sh), read the truth table not the percentage, add vectors to zero gap rows, cite from a new FV-FALCON-COV-00x, and relabel coverage_subjects/ as tool-qualification fixtures in BUILD.bazel comments. Until then coverage claims must say: tool-qualified on fixtures; flight-component MC/DC pending.

[avrabe]

Status: partial — honesty slice shipped (#158), substantive work blocked on tooling.

Shipped (no tool needed)

coverage_subjects/ are now explicitly labeled TOOL-QUALIFICATION FIXTURES — NOT flight code in BUILD.bazel, with the caveat "tool-qualified on fixtures; flight-component MC/DC pending."

Blocked: witness MC/DC on the real component

The real-component target already exists — //:falcon-cascade-coverage (tags=["manual"]). Not runnable here because (1) the witness instrumenter isn't on PATH (external tool, provided via the Bazel toolchain in CI), and (2) host/witness-wasi-harness isn't a Bazel rust_binary (its wasmtime/tokio dep tree needs crate-universe setup this workspace lacks — see BUILD.bazel ~L665 + FV-FALCON-COV-004). MC/DC is iterative with the tool (run → read truth table → add vectors → re-run); I won't fabricate a truth table.

Execution recipe (env with witness)

1. Build the real component (scripts/build-flight-component.sh or :falcon-cascade-fused).
2. bazel run //:falcon-cascade-coverage, or the cargo recipe in FV-FALCON-COV-004 (witness instrument → run --harness → lcov).
3. Read the truth table, not the %. Add a harness entry point per gap row (masking/unique-cause vector); re-run to zero gaps.
4. Land as FV-FALCON-COV-006; flip the dossier §10.4.3 row to cited.

Enabling slice others can pick up first: make host/witness-wasi-harness a Bazel rust_binary (crate-universe) so the WASI coverage flow runs in CI instead of tags=["manual"].

Keeping open — not done.

[avrabe]

Update — harness blocker CLOSED; real blocker found one layer deeper (CI-validated).

The research (we have crate_universe; the harness just wasn't wired into it) was right, and PR #162 implements + CI-validates it. The Bazel job builds //host/witness-wasi-harness end-to-end:

• ✅ @harness_crates crate_universe resolves wasmtime/tokio (the part feared to need annotations — it didn't)
• ✅ //host/witness-wasi-harness builds as a rust_binary
• ✅ the wasm_module_coverage_wasi pipeline wires up and invokes witness instrument
• ❌ witness instrument fails on the fused cascade: failed to parse export section

So the "harness isn't a Bazel rust_binary" blocker — the one that kept //:falcon-cascade-coverage on tags=["manual"] for ~10 versions — is resolved. The blocker has moved to the witness tool's binary-format support: the fused cascade is a Component-Model binary (meld_fuse output), but the bundled witness instrument expects a core module and chokes on the component-level export section.

Remaining (deeper) blocker — two ways forward:

1. Target the pre-fusion core module for coverage instead of the fused component (witness parses core modules fine — that's how the fixture subjects work). Find/expose the cascade's core .wasm before meld_fuse.
2. Bump the witness version in rules_wasm_component to one that parses Component-Model binaries (ties to the earlier finding that the published rules_wasm_component 1.0.0 predates the witness/coverage integration entirely — HEAD is 792 commits ahead).

PR #162 lands the validated harness + documents this inline; the coverage RUN stays manual until (1) or (2). This is genuine forward motion — the infrastructure blocker is gone, and the remaining one is now a specific, named tool-capability gap rather than "blocked."