catalog: add Qwen3.8-Flash-Next, and stamp its renderer on pull (#1192)

[gen16k]

What lands

qwen3.8-flash-next — 180B on disk, 6B active, 262,144 native context, one ollama-tag
variant at UD-Q2_K_XL. The entry the pin move in #1235 existed for.

Measured end to end on sv-evox2 (Ryzen AI Max+ 395, 127 GB unified) against the pinned
0.33.3, probe stamped 3bf816378e7c: agent-harness grade pass over 12 trials, and all
six request shapes accepted.

Why the tag alone was not enough

The tag as published accepts only three of the six. Its config carries no renderer, so ollama
renders prompts with the GGUF's embedded Jinja, whose line 110 is
raise_exception('System message must be at the beginning.') — and that is exactly
trailing-system, system-after-tool-roundtrip and developer-turn, the shapes a coding
agent sends.

I read the config blob of all 24 GGUF tags carrying this model, across six namespaces.
Not one declares a renderer. Every safetensors/MLX tag does. That is the packaging route, not
a publisher's oversight: ollama's convert path stamps the field and its GGUF create path does
not, so the next large community quantization lands in the same hole.

So the manifest names the renderer and the pull path stamps it onto the local copy.

	tag as pulled	after Puller.Stamp
renderer	''	qwen3.8
parser	''	qwen3.5
layers	projector, model, license, params	identical four
disk	—	0.00 GB

ollama create on the same tag name reports using existing layer for every blob, so the
projector and the license layer survive and every identifier downstream stays what it was.
Only the small config object is rewritten. With it:

shape	as pulled	stamped
trailing-system	rejected 500	accepted 200
system-after-tool-roundtrip	rejected 500	accepted 200
developer-turn	rejected 500	accepted 200

This is what ollama does for this model itself — its own library tag declares
renderer: qwen3.8 / parser: qwen3.5, and that renderer ships in the pin.
normalizeQwen38Messages (model/renderers/qwen35.go:136) folds every system and developer
turn into one leading system turn, the same operation the gateway does, with no branch inside
it that can refuse a shape. No engine bump was needed: v0.34.0-rc1 registers exactly the
same renderers as 0.33.3.

Decision 20260828/1930 is untouched. A model that cannot render the shapes a coding agent
sends is still one this project does not offer. This one renders them, so the gate is passed,
not exempted. My earlier suggestion that the decision might need revisiting is withdrawn.

The stamp does not survive a re-pull, so it lives inside Pull

Worth reading even if you skim the rest, because it changed the shape of the code. Measured on
the machine:

before re-pull   renderer='qwen3.8' parser='qwen3.5'
re-pull took 2s, disk delta 0.00 GB
after re-pull    renderer=''        parser=''
after re-stamp   renderer='qwen3.8' parser='qwen3.5'

ollama pull on a tag that is already present moves no weights and takes two seconds — and
rewrites the local manifest back to the published config, clearing the renderer. It is cheap
enough to happen on any update check, and the cleared state is not "unimproved": it is a model
that 500s on three of the six shapes while the store records them as accepted.

So stamping is not a public method a caller remembers to invoke after pulling. It is the tail
of Pull(ctx, tag, want, onProgress) and cannot be separated from it. A failed pull stamps
nothing; a repeated pull re-stamps. Both are tested.

The 122B drops to manual_only

Same generation swap as #823. The replacement is lighter on the same hosts — 55.1 GB resident
against 81.0 — and graded on real hardware rather than inherited. The 122B stays listed,
resolvable, pullable and servable; a host already holding those weights carries on unchanged.

Two things this surfaced that are worth reading

VariantSHA cannot carry the renderer. Its payload is frozen — widening it makes every
persisted measurement on every host stop matching at once — so a stamped and an unstamped
variant hash alike, and a manifest that quietly drops its renderer would leave the old "all six
accepted" record looking valid. The shapes store therefore records the renderer a measurement
was taken under and compares it against the manifest, next to engine_version, which is there
for the same reason. Caveat stated in the code: recording the manifest's value at import binds
the record to the manifest, so it catches a later edit, not a run measured before the stamp —
that needs the probe to report what it used, which it does not yet.

Two hostfit tests asserted on capacity-plus-roofline where they meant the recommendation
gate. They agreed for every catalog we had shipped, so nothing separated them. A 180B-A6B
entry does: 55 GB of weights against a 24 GB card, but only 6B read per token, so the roofline
is happy and the old rule reaches for it. The product default does not move — measured,
not assumed:

waired#942 host (big RAM, 24 GB card)     RTX 5080 16 GB
  bestByTier      = qwen3.8-flash-next      qwen3.8-flash-next
  bestRecommended = qwen3.6-35b-a3b         qwen3.5-9b     <- unchanged
  flash-next: Recommend=false reason="weights_spill"

Both tests now assert both sides, so the ladder cannot silently do the gate's job again.

Also here

• Quant ladder gains Q2_K, Q3_K_M, UD-Q2_K_XL. The UD row's bpw is measured (78.87 GB
  over 180e9 params), not modelled — dynamic quants have no a-priori table value, and folding
  one onto plain Q2_K under-estimates its weights by a quarter.
• New host class amd-unified-128gb: the only shape in the fleet with the addressable memory
  to hold these weights without spilling, and a spilling host grades itself, not the model.
• The catalog: a source that exists is not a source ollama can render (#1238) #1240 sources guard accepts a manifest-supplied renderer. It was written when the only
  fix was a different tag; that is no longer true, and it now says which of the two is missing.
• catalog-radar's licence rule said the catalog carries only Apache-2.0 and MIT. It now carries
  one Qwen Community License 1.0 entry, so the rule says what it is — the bar for what the
  radar may propose, not a precedent. The reasoning is recorded on the private side
  (waired-ai/waired#1325), per the workspace placement rule; nothing user-facing mentions it.
• Knowledge note 20260906/0400 gets a 補足: its "waiting on one upstream field" conclusion was
  wrong, and the correction is recorded rather than the note edited.

kv_bytes_per_token_fp16 is the derivable 24576, and waired-agent#1255 carries why that is
incomplete: the engine allocates a second, asymmetric KV cache the derivation has no term for,
so real KV is 33792 B/token and a budget built on the annotation under-counts by 38%. Not
fixed here — that is a scoring change touching every hybrid model, and this model is the
evidence, not the scope.

Verification

go run ./cmd/catalog-tool validate --all
go run ./cmd/catalog-tool agentgrade --check --require-pass
go run ./cmd/catalog-tool shapes --check --require-accepted
make catalog-docs && go run ./cmd/catalog-tool docs --check
go test ./... ./scripts/... -count=1          # and ./proto/... in its own module
go test -tags integration -count=1 ./internal/catalog/...
cd docs-site && npm run i18n:check

All green locally, including the catalog-sources integration leg against the live registry.

Evidence: ~/verify-20260906-l100/evox2/ — grade-stamped.json, grade-stamped.log, plus the
pre-stamp grade-unary.json for the before/after.

Fixes #1192
Refs waired-ai/waired#1312

🤖 Generated with Claude Code

https://claude.ai/code/session_0167iiPnKQz1qcuz2bhNBGep

[github-actions]

📘 Docs preview — the preview channel for this PR has been deleted now that it is closed.