Reported: the postcode check reads "69 m away — inside the September 2026 cut-off of 0.17 miles."
Both numbers are correct and the sentence is still useless — checking it means converting one of them.
Cause
A readability rule of mine in formatCutoffDistance: below 100 m it swapped to metres, on the grounds that "0.04 miles" carries less for a reader than "69 m".
Taken one figure at a time, that holds. Taken in a sentence containing two figures it guarantees a mismatch whenever they fall either side of the threshold — and a 270 m cut-off with a nearby home does exactly that. I optimised the legibility of a single number and lost the coherence of the pair.
Fix — miles throughout
Miles is the unit UK school admissions actually runs on: councils publish cut-offs in miles (90% of the collected source rows), and it is what a parent has already been quoted in their booklet and offer letter.
before 69 m away — inside the September 2026 cut-off of 0.17 miles.
after 0.04 miles away — inside the September 2026 cut-off of 0.17 miles.
The metric figure survives only as support beside the miles figure on the Admissions tile (0.17 miles / 270 m), where it converts the same value rather than presenting a second one to compare against.
Below 0.01 miles the decimal places run out rather than the unit being wrong, so a very short distance is described — "under 0.01 miles" — instead of rounding to a flat 0.00 miles, which would read as no distance at all.
Both figures in the verdict now go through one formatter, and the old ?? "${Math.round(m)} m" fallbacks on that line are gone — they were a second, quieter route to the same defect.
Tests
The one-case fix is easy; the class of fault is what needed pinning. A sweep over 60 home/cut-off combinations spanning the old switch point (0, 5, 27, 69, 99, 100, 260, 800, 1609, 5000 m against 30, 69, 100, 270, 1000, 3500 m) asserts that no verdict contains a metric reading and that exactly two miles figures appear. Plus the reported case pinned verbatim, and an e2e guard on the rendered verdict so a future readability tweak to one figure cannot quietly reintroduce the mismatch in the other.
The old test asserting formatCutoffDistance(27) === { primary: '27 m' } is replaced rather than deleted — it now documents why the swap went, so nobody reinstates it as an improvement.
Verification
tsc clean; next build green
207 frontend tests, 54 backend
Rendered against the real compiled CSS and swept the live DOM: two verdict headlines, zero containing a metric reading; the tile still carries 0.17 miles + 270 m as a labelled conversion
Reported: the postcode check reads **"69 m away — inside the September 2026 cut-off of 0.17 miles."**
Both numbers are correct and the sentence is still useless — checking it means converting one of them.
## Cause
A readability rule of mine in `formatCutoffDistance`: below 100 m it swapped to metres, on the grounds that "0.04 miles" carries less for a reader than "69 m".
Taken one figure at a time, that holds. Taken in a sentence containing **two** figures it guarantees a mismatch whenever they fall either side of the threshold — and a 270 m cut-off with a nearby home does exactly that. I optimised the legibility of a single number and lost the coherence of the pair.
## Fix — miles throughout
Miles is the unit UK school admissions actually runs on: councils publish cut-offs in miles (**90% of the collected source rows**), and it is what a parent has already been quoted in their booklet and offer letter.
```
before 69 m away — inside the September 2026 cut-off of 0.17 miles.
after 0.04 miles away — inside the September 2026 cut-off of 0.17 miles.
```
The metric figure survives only as **support** beside the miles figure on the Admissions tile (`0.17 miles` / `270 m`), where it converts the same value rather than presenting a second one to compare against.
Below 0.01 miles the decimal places run out rather than the unit being wrong, so a very short distance is described — **"under 0.01 miles"** — instead of rounding to a flat `0.00 miles`, which would read as no distance at all.
Both figures in the verdict now go through one formatter, and the old `?? "${Math.round(m)} m"` fallbacks on that line are gone — they were a second, quieter route to the same defect.
## Tests
The one-case fix is easy; the class of fault is what needed pinning. A sweep over **60 home/cut-off combinations** spanning the old switch point (0, 5, 27, 69, 99, 100, 260, 800, 1609, 5000 m against 30, 69, 100, 270, 1000, 3500 m) asserts that no verdict contains a metric reading and that exactly two miles figures appear. Plus the reported case pinned verbatim, and an e2e guard on the rendered verdict so a future readability tweak to one figure cannot quietly reintroduce the mismatch in the other.
The old test asserting `formatCutoffDistance(27) === { primary: '27 m' }` is replaced rather than deleted — it now documents why the swap went, so nobody reinstates it as an improvement.
## Verification
- `tsc` clean; `next build` green
- **207 frontend tests**, **54 backend**
- Rendered against the real compiled CSS and swept the live DOM: two verdict headlines, zero containing a metric reading; the tile still carries `0.17 miles` + `270 m` as a labelled conversion
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01WDvkyqqHABm4bmth2kjAxE
The postcode check read "69 m away — inside the September 2026 cut-off of
0.17 miles". Both numbers are right and the sentence is still useless: the
reader has to convert one of them to check a comparison we had already made
for them.
The cause was a readability rule of mine in formatCutoffDistance, which swapped
to metres below 100m on the grounds that "0.04 miles" carries less than "69 m".
Taken one figure at a time that holds. Taken in a sentence containing two
figures it guarantees a mismatch whenever they fall either side of the
threshold — and a 270m cut-off with a nearby home does exactly that.
Miles now lead everywhere. It is the unit UK school admissions runs on:
councils publish cut-offs in miles (90% of the collected source rows), and it
is what a parent has already been quoted in their booklet and offer letter.
The metric figure survives only as support beside the miles figure on the
Admissions tile, where it converts the same value rather than presenting a
second one to compare.
Below 0.01 miles the decimal places run out rather than the unit being wrong,
so a very short distance is described — "under 0.01 miles" — instead of
rounding to a flat "0.00 miles", which would read as no distance at all.
Both figures in the verdict now go through one formatter with no fallback that
could reach for another unit. The old `?? "N m"` fallbacks on that line were a
second route to the same defect and are gone.
Covered by a sweep over sixty home/cut-off combinations spanning the old
switch point, asserting no verdict contains a metric reading and that exactly
two miles figures appear; plus the reported case pinned verbatim, and an e2e
guard on the rendered verdict.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WDvkyqqHABm4bmth2kjAxE
This PR fixes a UX bug where the 'would we have got in?' distance comparison mixed units (e.g. '69 m away — inside the cut-off of 0.17 miles'), by introducing a single formatMiles helper and routing both the home distance and cut-off figures through it so they always render in the same unit. The change is small, self-contained to the Next.js frontend, and thoroughly covered by new unit tests (including an exhaustive sweep across the old metres/miles swap threshold) and an e2e regression test.
✅ No issues found.
## 🤖 AI Code Review (Claude Code)
This PR fixes a UX bug where the 'would we have got in?' distance comparison mixed units (e.g. '69 m away — inside the cut-off of 0.17 miles'), by introducing a single `formatMiles` helper and routing both the home distance and cut-off figures through it so they always render in the same unit. The change is small, self-contained to the Next.js frontend, and thoroughly covered by new unit tests (including an exhaustive sweep across the old metres/miles swap threshold) and an e2e regression test.
✅ No issues found.
tudor
merged commit 228eb214f5 into main2026-08-20 19:39:19 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Reported: the postcode check reads "69 m away — inside the September 2026 cut-off of 0.17 miles."
Both numbers are correct and the sentence is still useless — checking it means converting one of them.
Cause
A readability rule of mine in
formatCutoffDistance: below 100 m it swapped to metres, on the grounds that "0.04 miles" carries less for a reader than "69 m".Taken one figure at a time, that holds. Taken in a sentence containing two figures it guarantees a mismatch whenever they fall either side of the threshold — and a 270 m cut-off with a nearby home does exactly that. I optimised the legibility of a single number and lost the coherence of the pair.
Fix — miles throughout
Miles is the unit UK school admissions actually runs on: councils publish cut-offs in miles (90% of the collected source rows), and it is what a parent has already been quoted in their booklet and offer letter.
The metric figure survives only as support beside the miles figure on the Admissions tile (
0.17 miles/270 m), where it converts the same value rather than presenting a second one to compare against.Below 0.01 miles the decimal places run out rather than the unit being wrong, so a very short distance is described — "under 0.01 miles" — instead of rounding to a flat
0.00 miles, which would read as no distance at all.Both figures in the verdict now go through one formatter, and the old
?? "${Math.round(m)} m"fallbacks on that line are gone — they were a second, quieter route to the same defect.Tests
The one-case fix is easy; the class of fault is what needed pinning. A sweep over 60 home/cut-off combinations spanning the old switch point (0, 5, 27, 69, 99, 100, 260, 800, 1609, 5000 m against 30, 69, 100, 270, 1000, 3500 m) asserts that no verdict contains a metric reading and that exactly two miles figures appear. Plus the reported case pinned verbatim, and an e2e guard on the rendered verdict so a future readability tweak to one figure cannot quietly reintroduce the mismatch in the other.
The old test asserting
formatCutoffDistance(27) === { primary: '27 m' }is replaced rather than deleted — it now documents why the swap went, so nobody reinstates it as an improvement.Verification
tscclean;next buildgreen0.17 miles+270 mas a labelled conversion🤖 Generated with Claude Code
https://claude.ai/code/session_01WDvkyqqHABm4bmth2kjAxE
🤖 AI Code Review (Claude Code)
This PR fixes a UX bug where the 'would we have got in?' distance comparison mixed units (e.g. '69 m away — inside the cut-off of 0.17 miles'), by introducing a single
formatMileshelper and routing both the home distance and cut-off figures through it so they always render in the same unit. The change is small, self-contained to the Next.js frontend, and thoroughly covered by new unit tests (including an exhaustive sweep across the old metres/miles swap threshold) and an e2e regression test.✅ No issues found.