Friction (dogfooding, hourly loop)
While verifying three agent-reported export findings (REQ-115/116/118 — absolute /<prefix>/artifacts/… links that 404 on a GitHub-Pages-style sub-directory deploy, fixed in #377), I hit a recurring gap:
There is no way to know whether a rivet export --format zola site actually builds, short of hand-scaffolding a Zola site and running zola build yourself.
- The existing export tests (
export_html.rs, the new export_zola.rs) assert on generated strings. They can't catch a whole class of bug where the export succeeds but produces output that is broken downstream — wrong link forms, a dangling internal link that aborts zola build, a missing shortcode template, a missing taxonomy.
- REQ-115/116/118 are exactly this class. The export exited 0 and looked fine; the breakage only appeared under a real build with a sub-directory
base_url.
rivet export --format zola prints guidance ("ensure your config.toml has a 'tags' taxonomy", "--shortcodes") but a user who follows it can still land on a site that fails zola build with a cryptic Tera/taxonomy error.
What I used / what finally helped
Verifying the finding required:
- Hand-writing a minimal
config.toml (with base_url set to a sub-path and a tags taxonomy) + templates/{index,section,page}.html.
rivet export --format zola --shortcodes --output <site>.zola build, then grepping the built HTML for links that dropped the sub-path.
Having zola installed locally (0.22.1) is what made the finding verifiable at all. Without it this stays a string-grep guess.
Suggested fix
- An optional CI smoke job (gated on
zola being available, like the Kani/Verus continue-on-error jobs): export the dogfood corpus, run zola build under a sub-directory base_url, fail if the build errors or if any generated link drops the sub-path. This would have caught REQ-115/116/118 before they shipped.
- A documented one-command repro recipe (or a
rivet export --format zola --scaffold that emits a minimal buildable config.toml + the required templates), so verifying export correctness doesn't require hand-rolling a Zola site.
Filing per the loud-fail-over-silent-success doctrine: "export succeeded" should imply "the output is usable," and today it doesn't for Zola. Will also dogfood the product half as a REQ artifact.
Context: fixes landed in #377.
Friction (dogfooding, hourly loop)
While verifying three agent-reported export findings (REQ-115/116/118 — absolute
/<prefix>/artifacts/…links that 404 on a GitHub-Pages-style sub-directory deploy, fixed in #377), I hit a recurring gap:There is no way to know whether a
rivet export --format zolasite actually builds, short of hand-scaffolding a Zola site and runningzola buildyourself.export_html.rs, the newexport_zola.rs) assert on generated strings. They can't catch a whole class of bug where the export succeeds but produces output that is broken downstream — wrong link forms, a dangling internal link that abortszola build, a missing shortcode template, a missing taxonomy.base_url.rivet export --format zolaprints guidance ("ensure your config.toml has a 'tags' taxonomy", "--shortcodes") but a user who follows it can still land on a site that failszola buildwith a cryptic Tera/taxonomy error.What I used / what finally helped
Verifying the finding required:
config.toml(withbase_urlset to a sub-path and atagstaxonomy) +templates/{index,section,page}.html.rivet export --format zola --shortcodes --output <site>.zola build, then grepping the built HTML for links that dropped the sub-path.Having
zolainstalled locally (0.22.1) is what made the finding verifiable at all. Without it this stays a string-grep guess.Suggested fix
zolabeing available, like the Kani/Verus continue-on-error jobs): export the dogfood corpus, runzola buildunder a sub-directorybase_url, fail if the build errors or if any generated link drops the sub-path. This would have caught REQ-115/116/118 before they shipped.rivet export --format zola --scaffoldthat emits a minimal buildableconfig.toml+ the required templates), so verifying export correctness doesn't require hand-rolling a Zola site.Filing per the loud-fail-over-silent-success doctrine: "export succeeded" should imply "the output is usable," and today it doesn't for Zola. Will also dogfood the product half as a REQ artifact.
Context: fixes landed in #377.