posts/rules.md

Post-Generator — Regeln & Konventionen

Arbeitsgrundlage für alles, was in diesem Repo an Social-Grafiken entsteht. Stand: 31.07.2026

Der Generator läuft lokal: ./serve.sh → http://127.0.0.1:4321/post1.html (Post 1, Carousel) bzw. /index.html (Post 2, Statement).

---

1. Wo die Wahrheit steht

Alle Marken-Werte stammen aus der Website, nicht aus diesem Repo. Bei Zweifel dort nachschauen, nicht hier raten:

Was	Quelle
Farben, Radien, Abstände	HiveGrid-Website/app/globals.css (:root)
Chamfer-Form	HiveGrid-Website/lib/chamfer.ts
Schrift	HiveGrid-Website/app/layout.tsx
Badge-Styling	HiveGrid-Website/components/sections/ScreenshotAccordion.tsx
Feature-Texte	HiveGrid-Website/app/playground/PlaygroundClient.tsx → solutionModules

Die Werte sind hier gespiegelt, weil der Export keine Tailwind-/oklch-Farben verträgt (siehe §7). Ändert sich die Website, müssen sie hier nachgezogen werden — das passiert nicht automatisch.

---

2. Farben

Marke

Token	Wert	Verwendung
--accent-yellow	#F1B729	Primärer Akzent, Marker, G-Marke
--accent-yellow-light	#FFE082	Badge-Hintergrund
--accent-yellow-dark	#3E2C0A	Badge-Text
--accent-teal	#0D6E6E	Sekundär, aktuell ungenutzt
--dark-bg	#30313D	Dunkle Variante + Formen-Ebene

Flächen & Text

Token	Wert
--surface	#FFFFFF
--bg-primary	#FAFAFA
--text-primary	#1A1A1A
--text-secondary	#555555
--text-on-dark	#C8D0DC

Pro Variante

Hell (Grund #FFFFFF)

--head-color    #1A1A1A      --frame-bg      #E8EBF0
--body-color    #555555      --shape-fill    #30313D   (deckend!)
--accent-on     #C8901A      --shape-line    rgba(48,49,61,.13)
--marker        #F1B729      --shape-accent  #F1B729
--pat-color     #30313D      --gmark-color   rgba(48,49,61,.16)

Dunkel (Grund #30313D)

--head-color    #FFFFFF      --frame-bg      rgba(255,255,255,.11)
--body-color    #B9BDC9      --shape-fill    #414252
--accent-on     #F1B729      --shape-line    rgba(255,255,255,.10)
--marker        #F1B729      --shape-accent  #F1B729
--pat-color     #FFFFFF      --gmark-color   rgba(255,255,255,.13)

--accent-on ist nicht #F1B729, sondern #C8901A auf Hell. Reines Markengelb trägt auf Weiß bei kleinem Text nicht. Der abgedunkelte Ton ist Absicht, kein Fehler.

Der Block oben rechts ist auf Hell deckendes #30313D. Das ist derselbe Wert wie die dunkle Story-Sektion der Website. Er darf nicht über die Intensitätsstufe aufgehellt werden, sonst ist es nicht mehr die Markenfarbe (siehe §5).

---

3. Geometrie

Chamfer

Die Marken-Form: abgeschnittene Ecken, Echo der Honigwabe. Auf der Website 16 px, hier hochskaliert, weil die Fläche viermal so groß ist.

clip-path: polygon(
  Xpx 0, calc(100% - Xpx) 0, 100% Xpx, 100% calc(100% - Xpx),
  calc(100% - Xpx) 100%, Xpx 100%, 0 calc(100% - Xpx), 0 Xpx
);

Element	X
Badge	11 px
Mockup-Rahmen außen	22 px
Mockup-Rahmen innen	14 px

Drei Fallstricke (stehen auch in chamfer.ts):

• clip-path beschneidet auch den Schatten → Tiefe über filter: drop-shadow(), nie box-shadow
• clip-path beschneidet auch den Rahmen → Rand über eine Hintergrundfläche lösen, nicht über border
• Kinder, die aus der Box ragen (Popups, Tooltips), werden abgeschnitten → solche Elemente nicht chamfern

Hexagon

Flat-Top, also flache Ober- und Unterkante mit Spitzen links und rechts:

clip-path: polygon(25% 0%, 75% 0%, 100% 50%, 75% 100%, 25% 100%, 0% 50%);

Seitenverhältnis 384,5 : 332,9 = 1,155 (= 2/√3). Aus der Logomarke abgeleitet, nicht geschätzt. Wer davon abweicht, staucht das Sechseck.

G-Marke

Ein einziges Polygon, aus logo.svg extrahiert (dort die einzige Fläche mit class="st3"), auf 0,0 normalisiert:

384.5,166.5 336.4,83.2 192.2,166.5 288.3,166.5 240.3,249.7 144.2,249.7
96.1,166.5 144.2,83.2 336.4,83.2 298,16.8 288.3,0 96.1,0 0,166.5
96.1,332.9 288.3,332.9

Immer inline als SVG einsetzen, nie als <img> — nur so lässt sie sich per currentColor pro Variante umfärben, und nur so überlebt sie den Export zuverlässig (§7).

Wabenraster

Nahtlose Kachel aus derselben G-Form. Bei Flat-Top-Hexagonen springen die Spalten um ¾ der Breite, benachbarte Spalten sitzen eine halbe Reihe versetzt. Eine Kachel = zwei Spalten breit, eine Reihe hoch. Die über den Kachelrand hinausragenden Kopien sind Pflicht — ohne sie sieht man die Nähte.

---

4. Typografie

Die Schrift

Manrope — dieselbe wie auf der Website. Bewusst nicht Inter: Der Kommentar in app/layout.tsx nennt Inter „the default AI/website-builder font"; Manrope ist eine Spur wärmer und geometrischer.

font-family: 'Manrope', system-ui, sans-serif;

Schnitte	400, 500, 600, 700, 800
Ablage	assets/fonts/manrope.css + 6 .woff2
Subsets	latin, latin-ext, cyrillic, cyrillic-ext, greek, vietnamese
Herkunft	Google Fonts, einmalig heruntergeladen

Warum lokal und nicht per CDN: Der Export darf zur Laufzeit an keiner fremden Origin hängen. Ein Font von fonts.gstatic.com wäre cross-origin, würde den Export vom Netz abhängig machen und im Zweifel den Canvas verunreinigen. Die URLs in manrope.css sind deshalb auf relative Pfade umgeschrieben.

Vor jedem Export auf document.fonts.ready warten. Sonst rendert der erste Durchgang still in einer System-Fallback-Schrift, und man sieht es erst in der fertigen Datei. Der Download-Button bleibt bis dahin deaktiviert.

Größen

Element	Größe	Weight	Sonstiges
Headline	74 px	800	line-height: 1.06, letter-spacing: -0.03em
Titel-Tagline	74 px	800	identisch zur Headline, bewusst
Fließtext	30 px	500	line-height: 1.48, max-width: 830px
Badge	26 px	600	letter-spacing: 0.1em
Claim (Titel)	31 px	500	line-height: 1.44

Akzent-Wörter

Zwei Behandlungen, nie beide im selben Textblock:

• Marker — handgezeichneter SVG-Strich als background-image, wellige Kanten, angeschrägtes linkes Ende. Für Headlines und Payoffs. Ein CSS-Verlauf ist hier verboten: er kann geometrisch nur ein perfektes Rechteck erzeugen und sieht gedruckt statt gemalt aus.
• Farbe (--accent-on) — für kleinere Zeilen.

Pro Slide höchstens ein markiertes Wort. Zwei Marker in einem Block waren schon zweimal zu viel.

Sprache

• Alles Sichtbare auf Deutsch, Code-Kommentare auf Englisch
• Keine Em-Dashes (—) in sichtbaren Texten. Komma, Punkt oder ·
• Feature-Texte wortgleich von der Website. Headlines dürfen gekürzt und umgestellt werden, aber keine neuen Wörter erfinden

---

5. Aufbau der Slides

Formate

1080 × 1350 px (4:5) — das hochkantigste offiziell unterstützte Feed-Format. Belegt: Instagram unterstützt 1.91:1 bis 4:5, Breiten 320–1080 behalten die Originalauflösung, alles außerhalb wird beschnitten.

• Alle Slides eines Carousels müssen dasselbe Seitenverhältnis haben — die erste Slide setzt es, der Rest wird hart darauf beschnitten
• Safe Zone: nichts Lesbares näher als ~92 px an den Rand
• Der Profil-Grid zeigt seit 2025 Hochformat und beschneidet auf 3:4 — im Grid fehlen links und rechts je ~33 px. Für die drei angepinnten Cover relevant, im Feed nicht

Layout-Template: Tag, Überschrift, Beschreibung, Bild

Jede Feature-Slide besteht aus denselben vier Bausteinen in derselben Reihenfolge. Das ist keine Geschmacksfrage — Wiedererkennung über fünf Slides entsteht genau dadurch, dass sich das Gerüst nicht bewegt.

 92 ┌──────────────────────────────────────┐
    │  ▌ TAG                               │  ← ausgerückt (siehe unten)
    │                                      │
    │  Überschrift, zwei Zeilen            │  ← dominiert die Slide
    │  mit einem markierten Wort           │
    │                                      │
    │  Beschreibung, zwei bis drei         │  ← kürzer als man denkt
    │  Zeilen Fließtext                    │
    │                                      │
    │  ┌────────────────────────────────── │
    │  │  Bild                             │  ← ein dominanter Blickfang
    │  │                                   │
    └──┴───────────────────────────────────┘

Größenverhältnisse. Die Hierarchie muss ohne Nachdenken lesbar sein — was zuerst, was zweitens, was drittens. Bei uns: Überschrift 74 px, Fließtext 30 px, Tag 26 px. Das Verhältnis Überschrift zu Fließtext liegt bei rund 2,5 : 1; gängige Empfehlungen für Carousels nennen Überschrift 48–72 pt gegen Fließtext 24–36 pt, also dieselbe Größenordnung. Weniger Abstand als Faktor 2 und die Hierarchie kippt.

Ein Blickfang pro Slide. Genau ein Element, auf das das Auge sofort springt — bei uns die Überschrift, danach das Bild. Zwei gleich starke Elemente lassen den Betrachter raten und wegwischen.

Weißraum ist kein verschenkter Platz, sondern das, was die Blöcke trennt. Der Abstand zwischen Tag und Überschrift ist deshalb größer als der zwischen Überschrift und Beschreibung: getrennte Gedanken brauchen mehr Luft als zusammengehörige.

Das Tag wird ausgerückt

Der Tag hat 20 px Innenabstand. Steht sein Kasten bündig zur Inhaltskante, beginnt sein Text 20 px weiter rechts als die Überschrift — und genau das sieht man:

vorher                      nachher
 92 │▌ WORKFLOW-ENGINE       72 │▌ WORKFLOW-ENGINE
 92 │Wenn-dann               92 │Wenn-dann
    └ Kasten bündig,            └ Text bündig,
      Text 20 px versetzt         Kasten ragt aus

Gelöst über margin-left: -20px, also genau den Innenabstand. Das ist dasselbe Prinzip wie hängende Interpunktion im Satz: Ausgerichtet wird nach der wahrgenommenen Kante, nicht nach der geometrischen. Der Kasten steht dann bei x 72 — immer noch weit innerhalb der Safe Zone.

Wer die Innenabstände des Tags ändert, muss das negative Margin mitziehen. Die beiden Werte gehören zusammen.

Ebenen (von hinten nach vorn)

z-index	Ebene
0	Hintergrund: Formen, Wabenraster, Punkte, Raster, G-Marke
1	Mockup
2	Inhalt: Badge, Headline, Fließtext
3	Swipe-Hinweis

Was global gilt und was pro Slide

Einstellung	Geltung	Warum
Variante (Hell/Dunkel)	global	gemischt fällt das Carousel auseinander
Mockup-Perspektive	global	dito
Renderqualität	global	Exportstufe, kein Gestaltungsmittel (§7)
Layout	pro Slide	jede Slide hat einen eigenen Katalog
Muster	pro Slide
Intensität	pro Slide

Durchgehendes Carousel (Panorama)

Der Post ist dann kein Stapel von fünf Bildern mehr, sondern ein einziges Blatt von 5400 × 1350 px, das in fünf 1080er Fenster geschnitten wird. Wer swipet, sieht Elemente über die Kante hinauslaufen und auf der nächsten Slide weitergehen.

   Slide 1  │  Slide 2  │  Slide 3  │  Slide 4  │  Slide 5
0 ─────── 1080 ────── 2160 ────── 3240 ────── 4320 ────── 5400
             ↑           ↑           ↑           ↑
                    die vier Nähte

Technisch: Eine Ebene von 5400 px Breite liegt in jeder Slide, verschoben um index × -1080 px. Jede Slide zeigt dadurch ihr Fenster desselben Blatts. Kein Zuschneiden von Hand, kein Splitter-Tool — die Slides sind die Schnitte.

Regeln, die dabei zählen:

1. Slide 1 muss allein funktionieren. Sie ist das Cover im Profil-Grid. Sie darf nicht wie „das linke Fünftel von etwas" wirken
2. Die Naht ist nie unsichtbar. Instagram zeigt beim Swipen ein paar Pixel Abstand zwischen den Slides. Das lässt sich nicht abstellen und ist auch nicht schlimm — der Effekt trägt trotzdem
3. Nichts Wichtiges auf die Naht legen. Keine Schrift, kein Gesicht, kein Logo. Der Schnitt gehört in ruhige Zonen
4. Aber etwas Auffälliges über die Naht laufen lassen. Eine halbierte Form zieht das Auge weiter und lenkt vom Spalt ab. Genau dafür sitzen unsere Sechsecke mittig auf 1080 / 2160 / 3240 / 4320 — je zur Hälfte links und rechts der Naht
5. Nur Standbilder. Ein Video mitten im Carousel bricht den Fluss

Was bei uns auf dem Blatt liegt: vier Sechsecke auf den vier Nähten (abwechselnd massiv und Kontur, unterschiedliche Höhen), die G-Marke auf der Naht 2|3, und ein durchgehendes Band über die volle Breite als Klammer.

Das ist ein globaler Schalter, kein Muster pro Slide — er wirkt naturgemäß auf alle fünf. Die Muster pro Slide bleiben zusätzlich verfügbar; für den reinen Panorama-Look überall auf „Aus" stellen.

Gängige Empfehlung sind 2–4 Slides fürs Panorama. Wir haben fünf. Das funktioniert, verlangt aber eine ruhigere Gestaltung — bei fünf Fenstern wird jede zusätzliche Form schnell unruhig.

Intensität

Die Stufe „Dezent" (Faktor 0,55) wirkt nur auf Nebenelemente — Hexagon-Kontur, Waben, Punkt- und Linienraster, G-Marke. Der große Block oben rechts bleibt immer deckend, sonst wäre er nicht mehr exakt #30313D.

---

6. Mockups

Kein fotorealistischer Laptop-Rahmen für die Feature-Slides: Die Website rahmt jeden Screenshot mit dem Chamfer (.screenshot-frame in globals.css). Das ist die markeneigene Mockup-Form und verbindet die Posts mit der Seite.

Der Laptop auf der Titel-Slide ist die Ausnahme und bewusst ein Blickfang.

Geometrie pro Slide

Breite, Seitenverhältnis und Position sind CSS-Variablen mit Defaults:

--mock-w     1090px   (ragt ~100 px über die rechte Kante)
--mock-ar    1.6      (16:10)
--mock-left  92px

Regel: Das Format des Rahmens folgt dem Inhalt des Screenshots, nicht umgekehrt. Der Form Builder ist eine schmale, zentrierte Spalte mit breiten leeren Rändern — in einem 16:10-Rahmen zeigt er vor allem Leere. Er bekommt deshalb 540 × 720 (3:4), mittig gesetzt, und einen Zoom von 3,8 direkt auf die Spalte.

Screenshots zuschneiden

Quellen sind ~2000 px breit und im Vollbild unlesbar. Jeder Screen wird auf seinen aussagekräftigen Bereich gezoomt. Die Werte sind gerechnet, nicht geraten:

Rahmenbreite = 1 Einheit,  Bild bei scale 1 = 1 Einheit breit
Bildhöhe     = 1/BildAR    Rahmenhöhe = 1/RahmenAR

Punkt fx horizontal mittig:   tx = 0.5/s − fx
Punkt fy vertikal mittig:     ty = (RahmenH/2)/(s · BildH) − fy

Mindest-Zoom zum Füllen: RahmenH / BildH. Darunter entstehen Lücken.

Ausnahme Titel-Slide: Der Laptop zeigt den Screen 1:1, ohne Zoom. Dort soll ein Bildschirm zeigen, was ein Bildschirm zeigt. Die Displayfläche misst 739 × 489 (AR 1,511), workflow.png hat 1,504 — passt praktisch deckungsgleich.

Neue Geräte-Mockups einbauen

1. Braucht echte Transparenz. Ein Screenshot eines transparenten PNGs ist keine Transparenz — das Karomuster steckt dann als Pixel drin und lässt sich nicht sauber entfernen (einmal versucht, Ergebnis unbrauchbar)
2. Ist die Displayfläche deckend, muss sie ausgeknockt werden, damit der Screenshot dahinter liegen kann. Nur so bleiben Notch und Rundungen oben
3. Displayfläche ausmessen und als Prozentwerte eintragen — sie hängt am konkreten Bild
4. Schatten über filter: drop-shadow() auf dem Container, nicht im PNG

---

7. Export & Bildqualität

Die zwei Regeln, aus denen alles folgt

1. Genau 1080 px breit hochladen. Instagram behält bei Breiten von 320 bis 1080 die Originalauflösung. Alles darüber wird von Instagram selbst verkleinert und danach neu komprimiert — Qualitätsverlust in zwei Runden statt einer. Ein 4000-px-Upload ist deshalb schlechter als ein 1080-px-Upload, nicht besser.

2. Trotzdem größer rendern. Wir rastern intern bei 2× (2160 × 2700) und skalieren selbst auf exakt 1080 × 1350 herunter. Das ist kein Widerspruch zu Regel 1, sondern der eigentliche Trick: Wir kontrollieren das Downsampling, statt es Instagram zu überlassen.

2160 × 2700  →  Halbierung  →  1080 × 1350  →  Upload
   render                        exakt

Warum das Supersampling hier hilft

Nicht wegen des Textes — den rastert der Browser bei nativer Größe ohnehin sauber, teils sogar schärfer als supersampled. Der Gewinn liegt woanders:

• Transformationen — der gekippte Laptop, gedrehte Formen, Chamfer-Kanten und Hexagon-Clips werden bei doppelter Auflösung gerastert und danach gemittelt. Das ist echtes Anti-Aliasing statt Treppenkanten
• Screenshots — unsere Quellen sind ~2000 px breit und werden auf ~1090 px gezeigt. Bei 2× zeichnet der Browser sie näher an ihrer nativen Auflösung, das anschließende Downsampling ist unser eigenes und damit besser
• Marker und Wabenraster — SVG-Kanten profitieren identisch

Bei reinen Textslides ohne Mockup ist der Unterschied gering bis null. Deshalb ist die Stufe umschaltbar (1× / 2× / 3×), nicht fest verdrahtet. 2× ist der Standard, 3× kostet spürbar Zeit und Speicher bei kaum sichtbarem Gewinn.

Warum stufenweises Halbieren

Browser skalieren Canvas standardmäßig schnell statt gut: Pixel werden direkt übernommen, Nachbarinformationen gehen verloren, das Ergebnis rauscht. Zwei Gegenmaßnahmen, beide nötig:

ctx.imageSmoothingEnabled = true;
ctx.imageSmoothingQuality = "high";   // Default ist "low"

Und: in Halbierungsschritten verkleinern statt in einem Sprung. Ein direkter Sprung von 3240 auf 1080 überspringt Zwischenpixel; zweimal halbieren mittelt jeweils über 2 × 2 und kommt einer echten Flächenmittelung nahe.

createImageBitmap() mit resizeQuality wäre der elegantere Weg, ist aber in Browsern uneinheitlich umgesetzt — teils wird die Option ignoriert. drawImage mit imageSmoothingQuality ist der verlässliche Pfad.

Format

PNG, nicht JPEG. Instagram konvertiert am Ende ohnehin zu JPEG — aber unsere Slides sind Text, flache Flächen und UI-Screenshots mit harten Kanten. Genau die zerlegt JPEG-Kompression zuerst. Wer als PNG hochlädt, gibt Instagram ein verlustfreies Original und zahlt nur einmal Kompression statt zweimal.

Für Fotoinhalte wäre JPEG bei 85–95 % die bessere Wahl. Haben wir hier nicht.

Farbraum

sRGB, ausschließlich. Instagram wirft andere Profile weg und konvertiert nach sRGB. Wer in Adobe RGB oder P3 exportiert, bekommt Farbverschiebungen bei dieser Konvertierung. Canvas-Exporte aus dem Browser sind standardmäßig sRGB — also nichts zu tun, solange niemand ein Farbprofil anfasst.

Weiteres

• Auf document.fonts.ready warten, sonst rendert der erste Export in einer Fallback-Schrift
• Dateinamen mit 01-…05- präfixen: Instagram übernimmt beim Hochladen die Dateisortierung
• Dateigröße im Auge behalten. Für JPEG gilt die Faustregel „unter 1 MB", sonst komprimiert Instagram härter. Für unsere PNGs mit Screenshots ist das nicht zu halten und auch nicht nötig
• Vom Desktop hochladen, wenn möglich — gilt als schonender als der mobile Upload

Quellenlage, ehrlich

Von Meta dokumentiert: die unterstützten Seitenverhältnisse (1.91:1 bis 4:5), die Auflösungsgrenze 320–1080, der Beschnitt außerhalb, und dass alle Carousel-Slides auf die erste beschnitten werden.

Community-Konsens, nicht offiziell: die konkreten Kompressionsprozente, die 1-MB-Faustregel, Desktop-vs-Mobile, und PNG-vs-JPEG-Empfehlungen. Plausibel und breit reproduziert, aber von Meta nirgends bestätigt. Im Zweifel selbst gegentesten: dieselbe Slide in zwei Varianten hochladen und vergleichen.

Vier Dinge, die den Export brechen

1. Tailwind- und oklch()-Farben. Die Export-Bibliothek kann sie nicht serialisieren. Der Slide-Baum benutzt deshalb ausschließlich Hex und rgba().

2. PNGs im foreignObject. Der Export serialisiert die Slide in eine data:image/svg+xml-URL und malt sie als ein Bild. Raster-Kinder dekodieren asynchron und verpassen diesen Paint regelmäßig — der Screenshot fehlt dann, während der Rest stimmt. SVGs dekodieren synchron und sind immer da.

Deshalb ist der Export verifiziert statt gehofft: Jede Screenshot-Fläche wird nach dem Rendern abgetastet. Eine solche Fläche ist nie glatt, sie trägt UI und Farbe. Liegt die Luminanz-Spanne unter 12, fehlt das Bild und es wird neu gerendert, bis zu fünf Versuche.

3. Browser-Downloads. data:-URLs öffneten einen leeren Tab, blob:-URLs das Bild im Tab — das download-Attribut wurde beide Male ignoriert. Der Generator schickt die Bytes deshalb per POST an /save, und serve.py schreibt direkt nach ~/Downloads.

4. Stille Skriptfehler. Ein Fehler auf oberster Ebene (Syntax, Temporal Dead Zone) tötet das ganze Skript: Das Panel rendert aus statischem HTML weiter, aber nichts wird gebaut. Beide Seiten haben einen globalen error-Listener, der so etwas ins Statusfeld schreibt. Nicht entfernen.

---

8. Fallen, in die wir schon getappt sind

Symptom	Ursache
Logo unsichtbar auf Weiß	Sichtbarkeitsregel vertauscht — auf Hell wurde logo-white.svg gezeigt
Logo bildschirmbreit statt zentriert	.laptop-screen img galt auch fürs Logo und hat es überschrieben. Solche Regeln immer auf eine Klasse eingrenzen
Element eine Zeile zu tief	max-width erzwang einen zusätzlichen Umbruch. Bei gesetzten <br> gehört white-space: nowrap dazu
Farbe „stimmt nicht"	Deckkraft der Ebene lag darüber. Eine Farbe ist nur exakt, wenn nichts sie multipliziert
Muster wirkt zufällig hingeworfen	Formen liefen quer durch den Text. Dekoration bleibt in den Rändern, verankert und angeschnitten
Nichts lädt, Bühne leer	Konstante vor ihrer Deklaration benutzt (TDZ)

---

9. Ordner

posts/
├── serve.py / serve.sh   Statischer Server + /save-Endpunkt (Port 4321)
├── post1.html            Post 1 · Lösung (Carousel, 5 Slides)
├── index.html            Post 2 · Statement (Einzelbild)
├── rules.md              diese Datei
├── assets/
│   ├── logo.svg, logo-white.svg, cta-honeycomb.svg
│   ├── laptop.png        Mockup, Display ausgeknockt
│   ├── fonts/            Manrope, lokal
│   └── screens/          Software-Screenshots
└── vendor/               html-to-image, JSZip (lokal, kein CDN)

Alles läuft offline. Keine CDN-Verweise, keine Google-Fonts zur Laufzeit — sonst hängt der Export an einer Netzwerkverbindung und an fremden Origins.