No CI job exercises parakeet-mlx — the default macOS engine has zero runtime coverage

[ruzin]

Surfaced by #514. An unpinned mlx upgrade broke Parakeet — the default macOS transcription engine — and every check on every platform stayed green. That is the part worth fixing; the dependency was just what happened to trip it.

The gap

Every STENOAI_E2E_ENGINE in the repo today:

Job	OS	Engine	Exercises parakeet-mlx?
t2-pipeline-macos	macOS	whisper	no
t2-pipeline-windows	Windows	parakeet	no — onnx-asr, no MLX
T3 @long-meeting (nightly)	Windows	parakeet	no — onnx-asr, no MLX

So src/_parakeet_mlx.py — the path the majority of users actually run — is executed by no automated test anywhere.

Why it is this way

Deliberate, and still correct as far as it goes: GitHub-hosted macOS runners have no Metal device, so parakeet-mlx cannot load there. CLAUDE.md documents this and the macOS pipeline job selects whisper for exactly that reason. The gap is not an oversight — it is a hardware limitation that has never been worked around.

What #514 did about it in the meantime

Added a provenance check to scripts/verify_mlx_bundle.py: the bundled mlx version must equal the requirements.txt pin, so an unverified mlx cannot reach a build. That would have caught this specific regression, and it runs in both e2e.yml and build-release.yml.

It is explicitly not a substitute for running the thing. It proves which mlx shipped, not that mlx works.

Options

1. Self-hosted Apple Silicon runner — the only way to get real coverage. Highest cost, and the only option that actually loads Metal. Would also unblock the MLX-OOM long-meeting case already tracked as a follow-up in CLAUDE.md, and give mlx 0.32.x can't find its metallib inside the PyInstaller bundle (blocks unpinning mlx) #515 a place to verify a pin bump.
2. A pre-release manual gate — add stenoai spike-parakeet to the release checklist as a required human step on Apple Silicon. Cheap, honest, but relies on a person remembering.
3. Status quo plus the provenance guard — accept that behaviour is untested and defend the input instead. Works only while the pin holds.

Worth noting option 2 costs almost nothing and closes the specific hole that shipped here, so it is a reasonable stopgap regardless of whether 1 ever happens.

Related

• fix(deps): pin mlx, and guard the pin at build time #514 — the pin and the provenance guard
• mlx 0.32.x can't find its metallib inside the PyInstaller bundle (blocks unpinning mlx) #515 — why mlx 0.32.x fails in the bundle