feat(tenstorrent): allowlist MistralForCausalLM + device-aware gate

[lu-zero]

Status: READY FOR REVIEW — Mistral-7B-v0.3 gate PASSED on Blackhole

BACKEND-TENSTORRENT-MISTRAL (child of BACKEND-TENSTORRENT). Allowlist MistralForCausalLM (Mistral-7B-v0.3, Apache-2.0) on the TT platform and make test_mistral_paged_engine.cpp device-aware so it runs on Blackhole against a Tenstorrent-appropriate golden pair.

Mistral reuses the Qwen3-dense forward verbatim (mistral_registry.cpp:7-11: MistralModel == Qwen3DenseModel with qk-norm skipped, plain rope theta 1e6, untied lm_head). Every op is already registered on kTENSTORRENT. The one new op vs Qwen3-0.6B is an untied kMatmul lm_head (Qwen3-0.6B ties it), already registered. No new op, no new kernel, no model code change.

On-card result (real Blackhole P150)

Full e2e gate ran via a background-monitor pattern; chain:

1. VT_DUMP_IDS=1 bootstrap (~6 min cold JIT) → our_ids_tenstorrent.i32
2. scripts/qwen3-neartie-gap-transformers.py (the AArch64-vLLM-free oracle Grok wrote for the Qwen3-0.6B TT golden, already on main) with python_env (torch 2.7.1+cpu, transformers 5.8.1) → our_ids_tenstorrent.npy + neartie_gap_mnats_tenstorrent.npy
3. Full gate run on the card vs the TT golden pair

Gate: 16/16 prompts PASS, 0 forward-divergent

• STRICT token-exact: 12/16, near-tie-only: 4/16
• max gap 0.062 nats @ prompt[0] tok=3 (well under the 0.5-nat band)
• BACKEND PROOF: Mistral ops on device type 6 with 0 declines (kMatmul selections=256 = the untied lm_head ran on device; kPagedAttention selections=8192)

Process-exit SIGSEGV (139) is the known MeshDevice teardown crash (handoff §7.5), not a gate failure: 127/128 doctest assertions passed (the 128th is doctest counting the SIGSEGV at exit); the gate's own REQUIRE(fail == 0) held and 16/16 + BACKEND PROOF printed before the crash. Same property the Qwen3-0.6B TT gate has.

DEVIATION recorded (POL-ORACLE)

The gap golden is transformers-teacher-forced, not vLLM 0.25.0 (which doesn't install on this AArch64 box). This matches the ratified Qwen3-0.6B TT precedent: scripts/qwen3-neartie-gap-transformers.py was written and merged for exactly this situation. The near-tie band is reused; the anchor/gap pair is transformers-based and is NOT compared to the CUDA neartie_gap_mnats.npy. Recorded in the spec's ## Outcome and the matrix row.

Changes

• src/vllm/platforms/tenstorrent.cpp — one allowlist line.
• tests/vt/test_tenstorrent_backend.cpp — platform assertion extended (814/814 on Blackhole, +1).
• tests/parity/test_mistral_paged_engine.cpp — device-aware wiring mirroring test_qwen3_paged_engine.cpp:221-296 + the post-loop Backend Proof block (:373-400): on kTENSTORRENT it proves the Mistral op set actually ran on the TT provider (selections > 0, declines == 0), gates against our_ids_tenstorrent.npy / neartie_gap_mnats_tenstorrent.npy, and bootstraps via VT_DUMP_IDS=1 → our_ids_tenstorrent.i32 when absent.
• NEW TT goldens: tests/parity/goldens/mistral_greedy_7b/{our_ids_tenstorrent.npy, our_ids_tenstorrent.i32, neartie_gap_mnats_tenstorrent.npy}.
• NEW .agents/specs/tenstorrent-mistral.md (spec + measured ## Outcome).
• NEW BACKEND-TENSTORRENT-MISTRAL row in .agents/backend-matrix.md (ACTIVE), claim in .agents/coordination.md, scripts/check-agent-record.py BACKEND 80→81.

Review

Fresh static + mutation review returned CHANGES-REQUESTED on the first pass: the post-loop Backend Proof block (selections > 0 / declines == 0) had been dropped, leaving the op-registration instrumentation vacuous. Fixed (94dc2b6f): the proof block is restored against kMistralOps, guarded by !bootstrap_only. All other review findings (kMatmul correctly included for the untied lm_head, device-golden load-bearing, allowlist routing, bootstrap-suffix data-integrity, band not weakened, seam invariant) were green.

[localai-org-maint-bot]

The Blackhole device evidence and restored backend-proof assertions make this worth re-reviewing, but the branch is currently conflicting with main. Please rebase onto current main and re-run the relevant record/static gates; after that, the key remaining maintainer decision is accepting the documented transformers-teacher-forced oracle deviation for this AArch64 Tenstorrent lane. @mudler

[localai-bot]

I've pushed two commits to this branch (6c9e98d merge, 0854b2d fixes) rather than sending it back — most of what was outstanding was bookkeeping, and one of the blockers was ours, not yours. Your two commits are untouched and still authored by you.

The blocker that was ours is gone. check-pr-size.py fail-closed on any binary path with no exemption route, which made every PR carrying a golden unmergeable by construction — including this one. That guard is now retired on main (#615 / #619), so your three .npy/.i32 goldens classify and pass. Thanks for surfacing it; the fix helps every future golden-bearing PR across all the hardware lanes.

Merged main in rather than rebasing. A rebase would rewrite your commits and need a force-push to your fork. The merge keeps them byte-identical, and as a side effect it makes origin/main an ancestor of HEAD, which is what the PR-size and trailer checkers need in order to compute a range on a fork branch at all. I verified the auto-merge of scripts/check-agent-record.py rather than trusting it — main and this branch each bump the BACKEND ratchet for a different row, and a clean textual merge of two such edits can land a count naming neither. It came out at 82 and the checker agrees.

Three real gate defects, all in the copied Qwen3 pattern:

1. A bootstrap run reported a green gate that gated nothing. Every prompt hits continue when bootstrap_only is set, then execution fell through to the summary and REQUIRE(fail == 0) — with all counters at 0, it printed 0/16 prompts PASS ... 0 forward-divergent and passed. Indistinguishable in a log from a gate that ran. Reachable on a TT box with VT_DUMP_IDS=1 and the device goldens absent. The Qwen3 gate returns early with a BOOTSTRAP banner; the copy dropped it.
2. The backend proof asserted kRopeNeox unconditionally. Mistral reuses the Qwen3-dense AttnBlock, where VT_QWEN3_ROPE_CACHE is default ON and routes rope through kRopeFromCache — both cache ops registered on TT. A cache-path run would have CHECK-failed "kRopeNeox was never dispatched" on a correct engine. Restored the rope_alt escape the Qwen3 gate carries, including resetting the alternatives' stats.
3. EnableOpProviderCallStats(true) was only disarmed inside if (device_golden && !bootstrap_only), so a bootstrap run left a process-global instrument on.

Records. Filed #670 — the row, spec and claim all cited PR #354, which is a merged PR rather than an issue, so nothing in the tree pointed at anything trackable. It's now linked in the roadmap table, the spec and the PR body. Three records disagreed on lifecycle state (matrix ACTIVE, claim SPIKE still saying "e2e gate BLOCKED", spec header DRAFT contradicted by its own Outcome); all three now agree. Added the ## Now section and the three public documents a new ACTIVE row owes, with BENCHMARKS stating plainly that no speed number is owed or claimed.

The oracle was named wrong in four places — comments and the spec's port map said qwen3-neartie-gap.py teacher-forces vLLM, but the committed goldens came from qwen3-neartie-gap-transformers.py. Anyone regenerating from those instructions would have produced a golden from a different oracle than the one committed. Worth noting this is now explicitly sanctioned: AGENTS.md gained a "When vLLM has no implementation" section with an oracle registry, and transformers and tt-forge are both in it. Your deviation was right; only the labelling was wrong.

Added the mutation evidence the BACKEND ratchet bump requires (check-pr-size refuses a governance-checker change without it), keyed to this row per the b55f6ec14 precedent. I got that test wrong twice before it bit — patching Path.read_text globally fed backend content to every matrix so it went green for unrelated reasons, and writing the mutated copy to /tmp tripped check_matrices's own relative_to(ROOT). Both recorded in the commit message.

On the remaining red check. documentation-checkpoint is per-commit and still fails on your two original commits, because the doc updates arrive in mine. That can only be "fixed" by rewriting your commits, which I'm not going to do. Since main is squash-only, those commits never land individually — I simulated the squashed result and it passes doc-checkpoint, agent-record and pr-size cleanly, so what actually reaches main is correct.

I also diffed the final tree against a clean merge of main with your head: it differs by exactly the edits above, nothing of yours or of main's was lost.

Merging once CI settles. The gate work itself was sound — the Blackhole numbers reproduce from your committed goldens, and Mistral3ForConditionalGeneration correctly still falls through, which a prefix match would have silently swallowed.