# Local assets

Pinned V2 commits browser libraries and IBM Plex font files. Builds copy them into reader output; ordinary reading does not depend on a third-party library/font CDN. This is separate from installing Node/npm dependencies, authoring remote media or packaging an offline application.

Keep the reviewed asset set together. Home without a diagram does not prove Mermaid can be removed. A styled page with broken search is not a fully checked reader.

# Asset map

Sources under installation static/ copy into output without that prefix. Stock resources include css/main.css, css/hljs-theme.css, js/app.js, js/search-core.js, js/mermaid-loader.js, svg/logo.svg and local vendor fonts. Template resources use the configured path prefix; authored Markdown URLs need their own reviewed root/subpath handling.

Builder Markdown rendering uses installed Node packages. Editor preview uses committed browser Markdown/highlight bundles. Reader code is already rendered into HTML, while Mermaid loads lazily for diagrams. Not every vendor library loads on every public page. Keep client bundles distinct from build dependencies.

# Pinned provenance

These manifest values describe the pinned release, not “latest” recommendations. Upgrade using the selected revision’s package, lockfile and assets together. Replacing one library from a CDN needs syntax/global/loader/license/compatibility review.

vendor/manifest.json has versions for installed lockfile package entries and sha256 for asset-relative file hashes. The bundler computes hashes before writing the manifest, so the manifest does not hash itself. The package list is wider than the browser-facing names above; it is not a list of downloads made by every reader.

A manifest is not a signature or automatic browser integrity enforcement. The stock template does not attach integrity attributes to every resource. An operator who can change assets can also change their manifest. Compare against a trusted selected release when integrity matters, rather than accepting a locally rewritten hash list as authority.

# Fonts and first paint

The bundler copies Sans weights 400, 500, 600, 700 and Mono weights 400, 500, 600 with the package’s CSS/subset references. It removes WOFF alternatives from generated CSS and copies selected WOFF2 files. Reader CSS has system font fallbacks.

The template adds the font stylesheet by script so it does not hold up initial paint, with a noscript stylesheet fallback. It applies theme, color-scheme and background early. That does not promise identical font metrics or instant rendering on every browser/network. Inspect long headings, tables and code after fonts load, in both themes.

# Licenses/notices

Retain vendor/NOTICES.txt and linked legal-comment files. Bundling collects license/copying/notice files from lockfile package directories, including transitive libraries. Project licensing does not erase these asset licenses. Read actual LICENSE/notices for distribution requirements; this page is not legal advice.

# Maintainer regeneration

npm ci
npm run assets:bundle
npm test
npm run build

Use this only in a separate maintainer checkout where changing engine assets is intended. The script deletes/recreates static/vendor/; it is not read-only verification or a required text-publishing step. Normal build/publication consumes committed bundles.

Development dependencies are required. Omitting them from install is not a supported regeneration recipe. Failure can leave a partial vendor tree, so preserve original revision before running. Review diffs/versions/notices, run tests/build, and inspect diagrams, editor preview, highlighted code, fonts, search and themes at desktop/phone widths.

Commit reviewed source/lockfile/bundle changes together through your project’s review process. Do not apply regeneration to the pinned public showcase engine, which stays unchanged. Content authors generally need only saved source, a build and a checked deployment.

# Network boundaries

Prepared local dependencies/output can support disconnected operation, but fresh clone/install is not an offline installer. A loaded page is not a service-worker/offline-app guarantee. Prepare the intended Node/dependency/artifact set through your approved supply-chain process and test a fresh session under actual network conditions.

Custom analytics, fonts, scripts, embeds and authored remote media change privacy/dependencies. Stock local resources do not prevent those additions. This showcase has no added analytics and uses a generic local GitHub header icon; that does not describe every customized site.

# Release checks and recovery

1. Review every static file’s audience, including downloads and image metadata.
2. Keep libraries, fonts, scripts, CSS, logo, notices and manifest together.
3. Confirm root/subpath and actual served resource URLs.
4. Check same-host library/font/index requests in browser network tools.
5. Open a real diagram, highlighted code sample and heading search; home alone is insufficient.
6. Inspect clean/existing browser contexts, both themes and phone widths.
7. If something fails, inspect requested bytes, version, path and cache before replacing a bundle.

Missing JS can break controls while prose remains visible. Missing fonts can silently fall back. Broken subpath resources can make local root preview misleading. Use Build and reader issues and Health and diagnostics to isolate that layer. Untested physical browsers, offline workflows and provider settings remain installation checks, not guarantees.