README:122 and FEATURE_MATRIX advertise a 'CI-tracked compile rate' over the spec suite that no job produces — and submodules are never checked out, so the directory is empty in CI

[avrabe]

Two user-facing documents advertise a CI-tracked compile rate over the official WebAssembly spec
suite. That number does not exist: no workflow runs the suite, and no workflow checks out the
submodule that holds it, so in CI the directory is empty.

Credit where it is due — ci.yml already records half of this, and I would not have looked
without it:

NOTE, recorded not fixed here: this target tree references tests/spec-testsuite ZERO times, so it is NOT the "CI-tracked compile rate" over the official suite that README.md:122 and FEATURE_MATRIX:122 advertise. That 257-file suite is checked out and entirely unrun.
— .github/workflows/ci.yml:742

What is not recorded is that the advertised claims were left standing, and that the gap is
structural rather than a missing job.

The claims, still live on v0.60.0 (4e7a179)

README.md:122

| WebAssembly spec test suite | CI-tracked compile rate | Compilation only — not executed on emulator |

docs/status/FEATURE_MATRIX.md

| WASM spec test suite | Compile-rate tracked by CI (tests/spec-testsuite); not executed on emulator |

The FEATURE_MATRIX row is the more specific of the two — it names the path — which makes it the
more misleading.

Verified independently, and it is worse than "unrun"

$ grep -rn -A4 'actions/checkout' .github/workflows/*.yml | grep -i submodule
   (no output — no workflow requests submodules)

$ grep -rln 'spec-testsuite|run_supported' .github/workflows/
   .github/workflows/ci.yml     # the comment above, and nothing else

tests/spec-testsuite is a submodule (.gitmodules -> WebAssembly/testsuite). Without
submodules: recursive on actions/checkout, it is empty on every CI runner. So this is not
"a job exists but selects nothing" — even adding a job today would measure an empty directory. Two
independent reasons the advertised number cannot exist.

For contrast, kiln does check out its suite (submodules: recursive in its wast-conformance
workflow) and gates on a baseline; that is the shape this claim describes.

Why file it rather than leave it to RQ-56-CONF

The ci.yml note defers wiring the gate, which is a reasonable scheduling call. But the claim is a
separate artifact from the gate, and it is the one a reader meets first. Until the gate exists,
the honest states are either:

• soften both rows to what is true — e.g. "vendored at a pinned commit; not yet run in CI" — or
• keep the claim and land the gate.

Leaving an advertised metric that no job produces is the same failure class this release is named
for, and the same one #1090 just fixed for two rivet artifacts ("pinned evidence that could not
fail on the failure they define").

Cheap, real gate if it helps

The suite is already vendored and tests/spec/run_supported.sh already drives it. Adding
submodules: recursive to the checkout plus a job that runs it and asserts a floor would make
the claim true and non-vacuous — the floor matters, since a run that compiles zero files would
otherwise report a clean "0/0". Measured locally on v0.60.0 for a starting point:

257 spec files, synth compile --cortex-m --all-exports (optimizer on):  1 panic (if.wast, #1093)
257 spec files, synth compile -b aarch64 --all-exports:                 0 panics

so a floor is comfortably achievable today.