port(SPEC-DFLASH2): output_multiplier accepts any number, where upstream refuses a non-positive scale

Row: SPEC-DFLASH2 (.agents/engine-matrix.md:180, re-resolved by line number and checked for uniqueness — exactly one hit across the roadmap and every matrix)

Found by wave PORTQ-6 (#2718) re-deriving PORT-NOW entry [221], upstream b389ac2946 vllm#52816. Nothing was executed.

This entry was first published as ALREADY_SATISFIED and is corrected to REAL_GAP. A fresh review of #2741 caught that the report called this residual "not portable work" and then sized it at ~5 lines one sentence later, which cannot both be true. The reviewer was right; the label was wrong.

What upstream does

b389ac2946 adds, in vllm/model_executor/layers/logits_processor.py:

if self.scale <= 0.0 and self.scale != 1.0:
    raise ValueError(...)
...
if self.scale != 1.0:
    values = values * self.scale

A refusal on a non-positive scale, in the same commit that introduces the candidate selector this tree mirrors.

What is here

The three substantive halves of b389ac2946 are ported and the port cites this exact SHA in eight places, which is why the entry first read as satisfied. What is not ported is the guard.

• src/vllm/model_executor/models/qwen3_dflash_weights.cpp:507-509 accepts any JSON number as output_multiplier, with no range test.
• src/vllm/model_executor/models/qwen3_dflash2.cpp:82 applies it unconditionally via MulScalar.
• A search for any refusal on the value — output_multiplier intersected with throw, Refuse, invalid or <= 0 over src/ and include/ — returns 0.

Consequence, stated at the limit of what was established

A non-positive multiplier inverts candidate ordering after the top-k. Verification stays lossless, so no token gate can see it; only the acceptance rate falls. That is the argument for a refusal rather than a silent clamp.

No published DFlash2 checkpoint is known to declare such a value. That statement rests on the default constant and the spec's notes, not on having opened any checkpoint manifest, and nothing was run. So this is a guard against a malformed or adversarial draft config, not a live defect with a known trigger.

Size

~5 product lines in qwen3_dflash_weights.cpp mirroring upstream's condition and message, plus a red-first test asserting the refusal and one asserting 1.0 and ordinary positive values still load.

Start with src/vllm/model_executor/models/qwen3_dflash_weights.cpp:507-509 and src/vllm/model_executor/models/qwen3_dflash2.cpp:82, then inspect the existing DFlash2 test setup. Add regression coverage for rejecting non-positive output_multiplier values while preserving 1.0 and positive values; done means the tests pass and the guard mirrors the cited upstream behavior.