grenadeandClaude Opus 5
32c8a3c2b5
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