Hwaro::Content::Processors::TemplateEngine

asset_integrity(name): the value is the integrity of what the name resolves to (see AssetHooks.integrity), wherever the output lives.

get_url/resize_image of a page.assets entry: the value is the URL it publishes at (Render#bundle_asset_urls), or none.

The wall clock, as a Time#to_s/date format: now() records its format, and the build records the one behind each current_* variable a template prints. The value is the clock formatted that way, so a page re-renders exactly when what it prints would differ.

A relative resize_image path naming one of the current page's bundle files (image = "cover.png" beside index.md) is published under the page's URL, as relative images in its body and its og:image (Page#social_image) are; rooting it at /cover.png found no variant and emitted a 404. nil for anything else.

Drop every memoized load_data() result. Called at the start of each build (Builder#run), so the memo only ever spans ONE build.

The mtime key alone is not a proof of identity: it is millisecond resolution, and a file rewritten inside one filesystem timestamp tick (ext4 stamps with the kernel's coarse clock, 1-10ms; FAT/HFS+ are coarser still) keeps the previous mtime, so a same-size, same-tick rewrite of data/team.csv was served from the memo — the previous file's rows — even though the data digest had already moved and forced the page to re-render. That is the flake in "re-renders when a data/*.csv changes": in-process, the two builds can land in the same tick. hwaro serve has the same exposure on every rebuild. A build must see the disk as it is when it starts, and within one build a data file cannot legitimately change, so the memo's whole purpose (parse once per build, not once per page) survives a per-build reset intact.

The URL a page.assets entry (content path) is published at, next to its page (Render#bundle_asset_urls); nil for anything else. Recorded as a render read, hit or miss: the answer moves with the owning page's slug/path and with the bundle's file list.

Record a file read by its project-relative path (the cache outlives the checkout path: CI restores it under a different directory). A path that escapes the project is not recorded — nothing reads it.

Everything recorded since the last call, and start a new record.

Run the block without recording its reads. For outputs every build renders again, cached or not (the 404 page, taxonomy pages, user feed templates): their reads key no cached page, and the cold build records the reads before it renders them. A serve pass recording them read as "moved during serve" (record_serve_cache_keys), so the next serve --cache start rendered every page. Nothing else renders while these run.