The symptom was a parser error
A converter expected structured data and received the opening tag of an HTML document. The browser error looked like a JSON problem, but the data itself was not malformed. The request had travelled to the wrong relative address and the host had politely supplied a fallback page.
Relative depth is part of the page contract
The site contains pages at different directory depths. A path that works from the home page can fail from a nested converter. The repair was not to hide the error or hard-code a brittle workaround; it was to calculate the correct path from the page location and retain the same deployable static structure.
One route is rarely the whole scope
Once a relative-depth defect appears, neighbouring tools deserve inspection. The Length and Treasure routes were checked alongside their shared data request, and the public asset was verified as JSON rather than merely present. That turns a local patch into a bounded systemic repair.
What the log records
This is exactly the kind of work a build log should preserve. It explains a later design constraint: converter pages must keep their data paths explicit, and release verification must include content type and browser behaviour. Readers who want the evidence model behind the data can start at the source register.