blueprint-docs

Every HTML document is a blueprint: a technical drawing, not a web page. Hairline rules, hatched separators, monospace annotation, nothing rounded, nothing glowing. The page looks measured — like it was drafted, not designed.

Do not improvise the visual system. Inline assets/blueprint.css verbatim into a <style> block and build on assets/skeleton.html. Output is always one self-contained .html file — no build step, no external CSS/JS, with exactly two allowed network dependencies: the Google Fonts @import already in the sheet, and the @pierre/diffs ESM import when the document contains a code diff (see Diffs).

Build mechanically, don't re-type. Generate documents by reading the two asset files and splicing programmatically (read blueprint.css into the <style> block; copy the skeleton's <script> blocks whole). Never paste the sheet or the scripts through a template language — the skeleton script is full of ${...} literals that collide with f-strings and template engines, and one mangled brace silently breaks the rail. To verify light mode, load the page with ?theme=light — the head script honors it; never ship a patched copy.

The layout is deliberately dense: a 13rem rail, a 56rem content column, and compact vertical rhythm (~1.4rem between blocks). Do not widen the gutters or pad things back out — the previous, airier version of this style was rejected as a pain to use. The width is for data, not prose: paragraphs and lists cap at 72ch (the sheet does this) so line length stays readable, while tables, charts, diffs, and pre take the full column. Don't remove that cap — full-width prose was rejected as unpleasant to read.

Invariants

Break one and the document stops reading as a blueprint.