The suite set `HF_HUB_DISABLE_XET=1` in the client environment. That is not
a configuration anyone runs: `hf_xet` installs as a `huggingface_hub`
dependency, so a real user's client is Xet-capable whether they asked for
it or not. Every conformance run so far has therefore been proving
something about a client with Xet switched off by the harness, and nothing
at all about the one rustingface has to work with.
That matters more than it sounds. Downstream Xet behaviour is half of spec
§8 and it is the half exposed to the Hub's migration: rustingface
implements no Xet, so the whole "point HF_ENDPOINT at it and everything
works" claim rests on a Xet-capable client *choosing* HTTP. That choice was
untested.
Stop disabling it, and add a check that asserts the choice from inside the
client rather than by inspecting our own headers -- the question is not
which headers we sent but what the client concluded from them. It refuses
to pass vacuously: if `hf_xet` is absent it fails loudly rather than
quietly proving nothing, which is how the harness's own opt-out was found.
The full suite passes with Xet enabled, 12 checks. So the posture in spec §8
holds against a real client, and now says so.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PqNtYNhov3fukx46KS9R7L
rob thijssen
32c8a3c2b5
