Hwaro::Core::Build::Builder

Access cache manager for external inspection

The most recently loaded site config (nil before the first build). The serve watcher reads it to diff restart-only [serve] settings after a config-triggered rebuild.

Access build context for external inspection (e.g. emitting JSON output after a build). Returns nil before run has been invoked.

Republish non-Markdown content assets (images, etc.) to the output directory, preserving their path relative to content/. Mirrors what the full build does via the raw-files path in the Write phase, but only touches the files the watcher actually flagged as changed.

Skips files whose extension isn't permitted by [content.files], so the watcher can't smuggle a .md or a disallowed type into output. No-ops when [content.files] isn't enabled — nothing was published in the first place, so there's nothing to refresh. (@config is nil only before the initial build, which Server#run_with_options already performs before spawning the watcher, so the watcher always sees a loaded config.)

Copy only the specified static files to the output directory. Used by serve mode when only static files have changed.

True when a user feed template override is loaded. Also consulted by the Generate phase's skip-if-unchanged gate: a template-only edit doesn't touch content, so a warm --cache build would keep the stale feed on disk if feeds were skipped.

Renderer over user feed templates (templates/rss.xml.jinja / atom.xml.jinja, loaded under the keys "rss.xml"/"atom.xml"). Nil when no override template exists so the feed generators keep the zero-cost programmatic path. The proc renders with a FRESH Crinja environment per call — the shared env is not MT-safe (with_scope mutates the env) and the SEO tasks that generate feeds run in parallel fibers. create_fresh_crinja_env carries the snapshot template loader, so {% include %} inside a feed template works.

Are there any pages stashed by --fast-start waiting to render? Server checks this to decide whether to spawn the background fiber.

Access lifecycle for external hook registration

Recompile all SCSS entries into the output directory. Used by serve mode when a .scss source changes — such files publish as compiled .css, never verbatim. No-ops unless [sass] is enabled.

Register a Hookable module

Render pages that were skipped on the initial --fast-start build. Runs after the dev server is already serving the priority subset, so user-visible "ready" time stays bounded on large sites. Regenerates SEO/search files at the end since feeds and the search index pull from page.content, which was empty for deferred pages during the initial Generate phase.

Also runs the BeforeRender hooks for the remaining work the cold pass deferred — OG image generation for non-priority pages and image resizing for static/content_file globs + non-priority page assets. Without this step those images never get produced in a fast-start serve session until the user saves a file.

Re-run the asset pipeline so SCSS (or plain CSS/JS) bundle sources refresh under serve. Updates the AssetHooks class-level manifest so subsequent renders see new fingerprint paths.

Returns false when the build failed without raising (pre-hook failure or a phase abort) — the serve watcher branches on this to surface the failure instead of live-reloading onto a broken site.

Incremental build: only re-parse and re-render pages whose source files have been modified. Falls back to a full build when the necessary state from a previous build is not available.

Optimizations over a full build:

• Only re-parses changed files (not all pages)
• Diff-based taxonomy update (not full rebuild)
• Re-links navigation only for affected sections
• Recomputes series/related posts only for affected pages
• Selectively invalidates Crinja caches

Incremental parse of changed content + full re-render with reloaded templates. Used when both content and templates changed simultaneously.

Re-render pages using reloaded templates without re-parsing content. Useful when only template files have been modified. With template dependency tracking active, only the pages whose template closure includes an edited template are re-rendered; otherwise (tracking off, a dynamic include in the graph, or templates added/removed) every page re-renders as before.

force_pages are rendered regardless of template impact — callers that re-parsed content (run_incremental_then_rerender) pass them so the selective path can't skip a content-changed page. Their taxonomy membership may have changed too, so taxonomy pages regenerate whenever force_pages are present.

Map source paths that were removed from disk to the output files they produced in the last build. A rebuild rewrites surviving pages but never deletes what's gone, so the serve watcher captures this BEFORE rebuilding (while @site still knows the page's URL/slug) and removes the orphans after — otherwise a deleted page keeps serving 200 and ships with the next deploy of public/.