Tags: wfzyx/von

device: auto-select OpenVINO CPU ahead of the PyTorch CPU fallback

With independent_options now traced, a CPU-only host on 'auto' should
land on the ~1.6x faster OpenVINO runtime instead of torch. Measured on
an i5-1135G7 with von-1.2 (18 public items): torch cpu 15.7 s/item,
openvino:cpu 7.4-9.6 s/item, openvino:gpu (Iris Xe) 2.1 s/item; all
picks identical.

release: von-sdk 1.2.2 - jevcompat server hardening + release automation

Version bump for the two prior commits (a4a2134 timing-safe auth +
off-event-loop inference, 946d4eb atomic calibration-file writes).

Also adds .github/workflows/cut-release.yml: a single workflow_dispatch
entry point that tags, creates a proper GitHub Release (a real Release
object with a rendered title/body -- a bare 'git tag && git push' only
leaves a lightweight tag, which GitHub renders as a small grey
commit-message blurb on the tags page, not a Release), and explicitly
dispatches publish-pypi.yml with dry_run=false.

That last step is deliberate, not automatic: a tag pushed with the
default GITHUB_TOKEN does not fire publish-pypi.yml's push:tags trigger
(GitHub blocks GITHUB_TOKEN-authored pushes from starting new workflow
runs to prevent infinite chains); workflow_dispatch is exempted from
that restriction, so this workflow calls publish-pypi.yml directly
instead of relying on the tag push to cascade into it.

release: von-sdk 1.2.1 - jevcompat conformance fixes

Patch release, no model weight changes (VON_VERSION stays 1.2, same
checkpoint). Ships the 3 jevcompat fixes from #16: structured
instructions, TypeSafe-formula confidence, empty-questions 422.

Also fixed src/von/server.py hardcoding its own version string
('1.1.0' FastAPI app version, '1.2.0' health-check version) instead of
reading von.__version__ -- the same drift class that caused pyproject.toml
and __init__.py to disagree before the 1.2 release.

release: Von 1.2 - order-invariant option scoring

Ships the independent_options architecture as the default model.
Retrained from the von-1.1 weights on the full corpus (290k universal +
40k long-context + 40k synthetic) under the new attention mask, 1 epoch.

JevBench public tiers vs 1.1: easy 93.8% -> 100.0%, standard 65.3% ->
63.9%, hard 38.7% -> 38.7%; answer flips under option reordering on the
hard tier (111 items x 4 orderings) 49.5% -> 0.0%. Calibration map refit
on all tiers (in-sample JevBench Calibration axis 77.4 vs 75.7; ECE
easy/standard/hard 0.109/0.045/0.089), best of 8 optimiser restarts.
Zero-shot noul prior refit: 85.1% on the held-out dev set (1.1: 81.7%).
jabr classifier-benchmark v2: 0.724 micro / 0.720 macro, unchanged.

VON_MODEL_ID -> von-1.2.0; 'von-1.1' stays an accepted alias so pinned
callers keep working. Tests assert on the model-id constant instead of a
literal. Model card and README updated.

fix(hub): rename to wfzyx/von, real model card, stop echoing stale mo…

…del ids

Hub repo renamed von-1.0 -> von now that model naming is version-based. The
Hub redirects the old id (verified: 307), and downloads and likes carried over,
so published installs keep resolving.

Model card: the sync workflow was uploading the project README, which has no
YAML frontmatter -- hence 'empty or missing yaml metadata in repo card'. There
is now a real card at hf/MODEL_CARD.md with license, base_model, pipeline_tag
and tags, plus the calibration numbers and an explicit in-sample disclosure.

Model id echo: the server reflected whatever model string it was sent, so a JS
SDK 1.0.1 client asking for 'von-1.0.0' got a response labelled von-1.0.0 while
actually being served by von-1.1. Von ships one model, so responses are now
always stamped with the version actually served. Old ids are accepted, never
reflected.

JS SDK: bumped to 1.1.0, defaults moved off the dead von-1.0.0 id and
centralised as an exported VON_MODEL constant.