Regression-suite proposal: M-F003 asserts the pre-#149 H3 LoRA/step split and will fail six templates on the next pass #156

This is a regression-suite change proposal, not a bug — filing it to owner:don + status:needs-approval per TESTER_AGENT.md, which is the one case where I park something myself rather than letting the implementer decide. I have left the case exactly as written.

The case

regression-suite-model-specific.md, M-F003 — "every H3 template's step count matches whether it carries the turbo LoRA" (authored by the regression agent, 2026-09-13).

What is wrong with it

It asserts a split that #149 deliberately removed yesterday. Its expected: block says:

• No LoRA, num_inference_steps: 20 — reference-to-video, composable-references, voice-timbre-reference, generated-subject-reference, chain-matched-to-audio, chain-video-continuity. No lora_model_name / lora_weight_name / lora_adapter_name / lora_scale variable on any of them.

All six of those templates now carry the Ref2VA turbo LoRA and run 9 steps. I confirmed it over MCP this cycle (model opus via the anthropic provider, workspace qa-verify):

get_workflow(name="templates/minimax/reference-to-video", variables_only=true)
  -> num_inference_steps: 9
     lora_weight_name: "minimax_h3_ref2v_turbo_8step_v1.0_768p_bf16.safetensors"
     lora_model_name: "lightx2v/Minimax-h3-Turbo"
     lora_adapter_name: "turbo", lora_scale: 1.0, lora_alpha: null
     video_shift: 12.0, audio_shift: 3.0

and list_workflows(shape="shot", traits="identity-referenced") shows the full lora_* variable set on all eight reference templates it returns.

The case's own premise is also gone. It opens: "The lightx2v/Minimax-h3-Turbo LoRA (minimax_h3_fl2v_turbo_8step_v1.0_bf16.safetensors) is distilled against the base MiniMax-H3 transformer, so it is only valid where that transformer is loaded." That was true of the FL2VA checkpoint. A Ref2VA-distilled checkpoint (..._ref2v_turbo_8step_v1.0_768p_bf16) has existed since 2026-08-27 and is trained for transformer_ref — which is the whole content of #149.

Why this needs a decision now rather than at the next run

M-F003 is marked "Free (run this one every pass)". On the next regression pass it will fail on six templates at once, and the regression agent's correct behaviour on a failure is to file an issue. That issue would be a false regression against an intended, reviewed change — and a noisy one, since the case tells the reader a step count disagreeing with LoRA presence is "a finding", which is exactly what it will now see.

What I'd propose (your call, I have not touched the file)

Rewrite the expected: block to the current split — all H3 templates carry a turbo LoRA at num_inference_steps: 9, with the checkpoint differing by path: ref2v on reference-conditioned steps, fl2v on the rest. That keeps what makes the case worth having: the three-way invariant is still real, and the new pairing is arguably more valuable to pin than the old one, because #149 showed four templates had silently been on the wrong checkpoint for a month.

Two things worth folding in while it is open, if you agree with the rewrite:

• The case asserts width: 960, height: 544 on all eleven. templates/minimax/video-with-audio-768p (new, Add a 768p H3 path: the FL2VA turbo LoRA pinned in the templates is the 544p one, and an 8-step 768p checkpoint has existed since 2026-08-27 #148) is 1344x768, so a template count or a canvas assertion stated as "all" will need to say which set it means.
• Its note about chain-matched-and-aligned exposing only lora_scale is now stale too — it exposes the full lora_* set including lora_alpha.

I'd rather not guess at the rewrite myself: M-F003 is the regression agent's case, its "change one, change all three" framing comes from the dw:minimax-h3 skill's hard rules, and whether those rules have been updated to match #149 is something I can see only through the skill, not decide. If you'd rather hand this to the regression agent or the implementer to rewrite, that works too — the only thing I'd argue for is that it happen before the next model-specific pass.

Reported by model opus via the anthropic provider, consumer-only session. Related: #149 (the change), #147 (shift/alpha), #148 (the 768p template).