Every CV diffable. Every PDF reproducible.

jsPDF/PDFKit (manuelle Layout-Primitive) oder React-PDF (parallele Layout-Engine, eigenes Flexbox-Subset, kein echtes CSS)

Der Browser ist die Layout-Engine, die ich für 12 Templates × Paletten ohnehin brauche — Flex, Grid, OpenType, Hyphenation, Print-CSS. Eine jsPDF-Route hätte bedeutet, CSS in JavaScript nachzubauen für jede Funktion, die ich schon habe. React-PDF kann das ein Stück weit, aber @page-Regeln, break-inside, OKLCH-Farben und Variable-Fonts sind Browser-Features. Der Preis ist Chromium im Deploy-Artifact (~300 MB), bewusst gezahlt. Web-Editor und CLI rendern dieselben Pixel, weil sie dieselbe Rendering-Engine fragen — kein Layout-Drift zwischen Preview und Export.

JSON Resume (JSON, single-locale, runtime-Locale-Switch) oder eine DB-Tabelle hinter einer SaaS-Auth

YAML ist greppbar, diffbar, kommentar-freundlich, copy-paste-freundlich — und der einzige Format-Choice, der ein git-natives Artifact ergibt. JSON Resume hat denselben Datengraph, aber ohne Kommentare und mit einer Multi-Locale-Story, die im eigenen Schema unbeholfen wird. Eine DB hinter SaaS-Auth ist die Anti-These der Story: der Nutzer übergibt seinen Lebenslauf an einen Anbieter, der morgen Preise erhöht oder das Produkt sunsetted. Zod als Vertrag zwischen YAML und Template heißt: ein fehlender Pflicht-Block wird beim Build gefangen, nicht beim PDF-Export. Locale aus dem Dateinamen ist ein kostenfreier Default — wer meta.locale explizit setzt, überschreibt es.

ein einziges Package mit src/cli, src/web, src/templates — alles in einem package.json

Die Renderer-Trennung ist keine Day-2-Aufräum-Aktion, sie ist die Architektur: cvmake-templates kann ohne CLI publiziert werden, das Schema kann von Dritt-Templates importiert werden, der Web-Editor baut auf demselben renderCV() wie das CLI auf — keine Layout-Drift möglich, weil es nur eine Render-Funktion gibt. Turbo cached pro Package; ein Template-Edit re-buildet nicht den ganzen Workspace. Der Preis ist die Initial-Bootstrap-Komplexität (workspace-Protokoll, pinned Versions, build-Order). Den Preis zahlt man einmal; Layout-Drift zwischen zwei Render- Pfaden zahlt man bei jedem Template-Edit.

@page { margin: 28mm 0 18mm 0 } und Chromium den Top-Spacer selbst rendern lassen

@page-Margin reserviert Platz auf jeder Seite inklusive Seite 1 — der Hero-Header verschiebt sich, das full-bleed Sidebar-Gradient bricht. Was ich brauche, ist Top-Breathing-Space ab Seite 2, nicht ab Seite 1. Chromium paginiert außerdem jeden CSS-Grid-Track separat: ein Spacer-Div im <main> drückt die Sidebar-Inhalte nicht mit nach unten, weil die Sidebar in einem eigenen Track-Container lebt. Lösung: Spacer-Injection misst getBoundingClientRect der Children pro Container, findet den ersten Child, der über die Page-Grenze rutschen würde, und schiebt einendiv.cv-page-spacer davor. MAX_PAGES=12 als Safety-Cap, damit ein degeneriertes Layout den Render-Loop nicht endlos heizen kann.

Puppeteer eine Base-URL übergeben und Templates auf relative Photo-Pfade ausrichten

page.setContent() hat per Default keine Base-URL, also würden relative Photo-Pfade ins Leere zeigen. Eine Base-URL zu setzen heißt: lokalen Dev-Server starten (CLI muss ein HTTP-Server werden), oder file://-Pfade jonglieren (CI-spezifisch, Permission-flaky). Die data-URL ist render-context-frei: derselbe HTML-String rendert in CLI, CI, Web-Preview, ohne dass irgendeine der drei Umgebungen eine Server-Annahme hat. Idempotenz: wer das Photo schon als data-URL übergibt (z.B. aus dem Web-Editor, der direkt encoded), bekommt es unverändert zurück — keine doppelte Base64-Schichtung.

git-clone-only bleiben (fork-or-nothing), oder den Editor auf eine Serverless-Plattform deployen

„Fork the repo" ist eine gute Contributor-Story und eine schwache First-PDF-Story — clone + install + build sind ~5 Minuten, npx ist ~30 Sekunden. Die drei Workspace-Deps des CLI erzwingen den Publish all-four-or-nothing — cvmake-cli allein würde nicht auflösen — also releasen die vier Packages im Lockstep auf einer gemeinsamen Version und der Cross-Dependency-Vertrag bleibt trivial. Der Editor kann nicht serverless: Puppeteer braucht einen echten Node-Prozess und ein ~300 MB Chromium, also ist es ein Container auf einer Box, keine Function. Und ein öffentlicher Editor kann nicht der local-first-Editor sein — er war gebaut, um cv.*.yaml auf disk zu lesen und zu schreiben, aber jeder Besucher würde dieselben Dateien überschreiben. NEXT_PUBLIC_DEMO_MODE rüstet eine stateless Posture nach — nur Example-CVs, kein Autosave, Photo-Crop komplett client-seitig, „Download YAML" statt disk. Die nicht-offensichtliche Falle: NEXT_PUBLIC_*-Vars werden zur Build-Zeit inlined, das Flag nur zur Container-Runtime zu setzen hat den Server (demo) gegen den Client (not-demo) split-brained — es muss vor next build gesetzt sein.