Deployment is not the same as delivery
A corrected file can be present in the repository and still be absent from a visitor’s browser. Long-lived cache headers are useful for speed, but they turn a file name into a promise: if the name stays the same, a browser may keep using its stored copy. A successful push therefore proves only one stage of a release.
The smallest correct change
The site keeps its static assets cacheable and changes the query-string version on the HTML reference when an immutable JavaScript file changes. That gives the corrected asset a new address without weakening caching across the site. The change belongs in the source page and the mirrored release together.
Verification has a time dimension
Immediately checking a public route can still observe an edge cache in transition. The release procedure therefore includes a later request for the exact page and the exact versioned asset. This is not superstition; it is a test of the state a real visitor will receive.
Why it belongs in the public record
The lesson is portable: static sites are simple, not consequence-free. Their operational quality depends on pathing, caching, and parity as much as on the visible interface. The editorial standards explain the research side of the site; this entry makes the technical custody visible too.