Fixed —
- A slider’s handles and its filter could disagree. syncSliders() passed the stored value into a slider whose bounds had just changed; a range input silently clamps to the new bounds on the step grid, and set() never fired onchange — so the handle showed one number while the filter used another, and the results followed the filter. Reachable with ordinary types: set a PV floor of 5 under Combat Vehicle (floor 2), switch to Fighter Craft (floor 14), and the slider reads 14 while everything from 5 up is still included. This had been shipping since the sliders existed. set() now returns what the DOM settled on and the caller reconciles state to it. Live.
- Battle Value and Point Value sliders could not exclude units with no recorded value. This is part of a larger problem that only good data will solve. 603 published units have neither value, and under some previous work they are exempt from the range rather than compared as zero — correct, but it left “show me a real PV band” inexpressible. Each slider now carries a three-state control: include (default, unchanged), exclude, or only those units. Measured live on Combat Vehicle × Clan Invasion: 416 shown · 396 hidden · 20 only — and 416 = 396 + 20, so the states partition the pool exactly. Live.
- A tonnage filter. There was none. Faceted like PV/BV, with the step derived from the data’s own granularity rather than a notch target — Battle Armor gets 0.1, BattleMech gets 1, no special cases. Absent where it would lie: BattleMech + Battle Armor spans 1,998 notches and Aerospace Craft 2,399,995, so the slider is withheld and state.ton cleared rather than left filtering invisibly. Aerospace Craft has no tonnage filter by decision — 5 to 2,400,000 tons across six sub-types is a distribution problem, the same one that made the generated Aerospace RATs fairly unusable, and no step setting fixes it. Future restructuring of Aerospace Craft and Advanced Support will likely include more useful filters for those types. Live.
Fixed — infrastructure
- Dynamic Cache was serving broken images, and the origin never failed once. The proxy answered validator-free GET requests with HTTP 304 and a zero-length body. A client that sent no If-None-Match has nothing to fall back on, so the image simply failed. Roughly 8–10% of unit art at any moment, recurring within ~15 minutes of a cache flush. Proven with curl (which sends no validators) via –resolve to the origin IP: the same file returned 304 / 0 bytes on its own URL and 200 / 183,352 bytes with a cache-buster, seconds apart on one connection. Fix: A specific path now emits Cache Rule taking over edge caching. Verified after deploy — x-proxy-cache: MISS on every request, cf-cache-status MISS → HIT, images intact. ⚠ The bug is avoided, not fixed. It’s on the long list of rundowns.