Rubric: asset resolution
Written by a person. Last read by a person on 2026-09-05, 23 days ago. Its facts were checked by the eval suite on 2026-09-28.
Enforced by check_asset_resolution.
The claim
Every local link in the built pages points to a file that is really there, under the folder the server hands out.
Observable evidence
- Each
hrefandsrcin every built HTML page. - The directory the server publishes as
/, which is not always the directory the pages were written into. - Whether the resolved target exists on disk, as a file or as a directory holding
index.html.
The pass bar
Every local reference resolves. External URLs, fragments, mailto: and data: are not
this rubric's to verify and are skipped.
Why this rubric exists
A stylesheet that 404s produces no error anything can see. The HTML is valid, the file was built, the server returns a page, and it renders unstyled, which looks like a plain design rather than a broken reference. Nobody files a bug against a page that looks deliberately austere.
This really happened. The design comparison built four versions into folders under one
server root. Every page still asked for /assets/… as if it sat at the top. All four came out
with no styling at all, so they looked alike rather than broken, and we shipped them that
way.
Ambiguous cases
An extensionless path is treated as a directory and passes on index.html inside it,
which is what a static server does with /help/.
A reference that resolves under the output tree but not under the served root is a
failure. That distinction is the entire point: the two are the same directory for _site
and different for the comparison, and only the served root is what a reader's browser uses.
A path that exists but is not readable is out of scope. This rubric checks that the build produced the file, not that the deploy configured it.