Übersicht

Dieses Dokument hält den Zweck, die Struktur und die architektonischen Entscheidungen für die Lolly-Plattform fest. Es spiegelt sowohl die Produktvision als auch den aktuellen Stand der Codebasis wider.

Status: Lolly ist veröffentlicht. Version 1.0 erschien am 30. August 2026 als Open Source unter MPL-2.0, und Funktionen, Voreinstellungen und der Werkzeugkatalog ändern sich zwischen den Versionen weiter. Die Engine ist deterministisch, mit einem einzigen Render-Pfad hinter jeder Shell. Ihre Sicherheit wurde noch nicht unabhängig geprüft, und die Belege zur Einführung sind einige Monate alt. Siehe Einführung & Governance für den aktuellen Stand und dafür, wie die Einführung gemessen wird.

Wie Sie diese Seite lesen. Sie enthält zwei Arten von Material, in dieser Reihenfolge. Die erste Hälfte ist warum es das gibt: das Problem, die Positionierung und der Lebenszyklus, den ein einzelnes Asset durchläuft. Ab Das große Ganze ist es wie die Schichten zusammenpassen: das Architekturdokument für Mitwirkende, das die Trennung von Engine/Shell/Pack, das Repository-Layout, die Auslieferungsziele und die Zusagen behandelt, die jede Änderung an der Plattform einschränken. Wenn Sie hier sind, um die Codebasis zu ändern, statt das Produkt zu verstehen, beginnen Sie beim großen Ganzen.

Zwei Begleitdokumente gehen tiefer als diese Seite. engine/README.md im Repository ist die modulweise Karte der Engine, mit einer generierten Tabelle jedes Moduls und was es parst oder schreibt. Bedrohungsmodell & Vertrauensgrenzen liest dieselbe Architektur als Vertrauensgrenzen, und es ist die richtige Seite für jede Frage dazu, was die Engine als nicht vertrauenswürdig behandelt.

Warum es das gibt

Wiederholbare Kreativarbeit ist zu vorhersehbar, um jedes Mal geschulte Hände zu rechtfertigen, und zu qualitätssensibel, um sie ohne Leitplanken abzugeben. Sich selbst überlassen geht sie einen von drei Wegen: langsam, uneinheitlich oder gefangen in den Vorlagen eines Anbieters.

Diese Plattform ist die direkte Antwort darauf:

Programmatische Kreativ- und Content-Erstellung im großen Maßstab - Assets, erzeugt aus Eingaben, mit einmal festgelegten Regeln, für alle, die sie brauchen.

Lolly ist nicht der Ort, an dem ein Designsystem erfunden wird - es ist der Ort, an dem es produziert wird. Denken Sie an einen Verkaufsautomaten für Design: Sie treffen eine Auswahl, Sie erhalten ein Ergebnis. Jedes Mal. Die Engine arbeitet auf die höchste Qualität hin, die jedes Format auf der Hardware vor Ihnen erzeugen kann, und dieselbe Engine erzeugt dieselbe Datei auf jeder Oberfläche, auf der sie ausgeliefert wird.

Das Ergebnis ist Fülle: jede Veranstaltung hat korrekte Beschilderung, jeder CVE-Alert entspricht dem Hausstil, jedes Etikett druckt sauber, jede E-Mail-Signatur ist aktuell - alles aus Tools, die die Regeln bereits mitbringen. Die Plattform übernimmt wiederkehrende, operationalisierte Kreativarbeit. Sie ist bewusst kein Tool für maßgeschneiderte Kreativarbeit - Designer verantworten weiterhin die Flaggschiff-Arbeit.

Probabilistisch innovieren, deterministisch skalieren

Jede Diskussion über KI in einer kreativen Pipeline bleibt an derselben Frage hängen: Welcher Teil davon ist Aufgabe der Maschine? Es ist eine alte Frage mit einer längst gefundenen Antwort. Schreiber und Buchmaler arbeiteten schon immer mit zwei Werkzeugen - der losen Skizze, in der nichts festgelegt war und alles ausprobiert werden konnte, und der Druckerpresse, gerade deshalb einschüchternd, weil sie sich festlegte. In den Skizzen entstand die Kunst. Die Presse war der Weg, auf dem sie jeden erreichte. Niemand verwechselte die beiden, und beide entwickelten sich weiter - neue Tinten, neue Schriften, neue Pressen - jede im Einklang mit dem Handwerk und der Absicht, der sie diente, verbessert.

Lolly zieht dieselbe Grenze. Probabilistisch erkunden: ein Modell, ein Designer, eine grobe Idee, ein Prompt, der irgendwohin führt, das niemand geplant hat. Dann deterministisch skalieren - das, was zu vielen Ausgaben wird, ist ein Tool, und ein Tool rendert aus lesbaren Eingaben jedes Mal auf dieselbe Weise. Das Erkunden bleibt frei, weil nichts Nachgelagertes davon abhängt, dass es zweimal gleich ausfällt. Die Ausgabe verdient Vertrauen, weil sie kein Ratespiel ist. KI-Experimente in vorhersagbare, reproduzierbare Ergebnisse zu überführen ist keine neue Disziplin; es ist dieselbe Arbeitsteilung, die gedrucktes Werk überhaupt erst vertrauenswürdig gemacht hat.

Dem kreativen Prozess vertrauen, mit Präzision skalieren.

Im Vergleich zu den Alternativen

Die Lücke ist offensichtlich: Nichts, was heute ausgeliefert wird, liefert constraints-first, offlinefähige, anspruchslos bedienbare, intern zugängliche Ausgaben. Lolly enthält sogar eine offene Zeichenfläche - Design - in der Farben, Schrift und Assets sich an die globalen Markenvorgaben halten, sodass freie Anordnung constraints-first bleibt. Was es nicht ist, ist eine uneingeschränkte Design-Suite: Designer nutzen für individuelle Flaggschiff-Arbeiten weiterhin Illustrator und Figma. Mit diesem Tool lassen sich Variationen zusammenstellen.

signed by Lolly2026-10-21vector SVG367 paths~62k nodes773 groups3 images1.453 KBPrüfen Sie es selbstSignierte Datei holen signed by Lolly2026-10-21vector SVG367 paths~62k nodes776 groups3 images1.454 KBPrüfen Sie es selbstSignierte Datei holen

Geeignet für: Die schnelle Erstellung operationalisierter Creative-Assets - Event-Kacheln, Namensschilder, Signaturen, CVE-Warnungen, QR-Codes, Social-Cards, Versandetiketten, strukturierte Berichte.

Nicht geeignet für: Individuellen Hero-Content.

Der Lebenszyklus einer Kampagne

Am klarsten wird deutlich, was Lolly ist, nicht anhand einer Funktionsliste - sondern indem man ein einzelnes Asset verfolgt, während es von Hand zu Hand weitergereicht wird. Sehen Sie, wie eine lokalisierte Kampagnenkarte die Organisation durchläuft:

1. Die Kreativabteilung legt die Regeln fest. Ein Designer erstellt die Basisvorlage im Design-Tool und kodiert die Typografie- und Farbvariablen der Marke fest. Sie erstellen nicht eine Karte - sie leisten die Grundlagenarbeit einmal, damit sie sie nie wieder von Hand lokalisieren müssen.
2. Die Entwicklung skaliert sie. Dieselbe Vorlage wird über die CLI in eine nächtliche Pipeline eingebunden, sodass ein neues Diagramm oder eine neue Sprachvariante automatisch erzeugt wird - kein Designer öffnet die Datei erneut.
3. Die Produktion nutzt sie einfach. Ein Vertriebsmitarbeiter, offline im Flugzeug, öffnet dasselbe Tool und erstellt für ein Kundengespräch eine perfekt markenkonforme Präsentation. Kein Design-Know-how, kein Netzwerk, keine Wartezeit.

Das „neue Diagramm" in Schritt zwei ist ein Render wie dieses, erzeugt aus einer Datenzeichenkette und einer Handvoll Parameter, ohne dass jemand eine Design-Datei öffnet:

signed by Lolly2026-10-21vector SVG15 paths~1.3k nodes4 groups20 KBPrüfen Sie es selbstSignierte Datei holen signed by Lolly2026-10-21vector SVG15 paths~1.3k nodes4 groups20 KBPrüfen Sie es selbstSignierte Datei holen

Der Punkt ist nicht, dass Lolly gut für Designer und gut für Entwickler und gut für den Vertrieb ist, jeweils für sich betrachtet. Es ist ein Staffellauf: Die ursprüngliche Arbeit der Kreativabteilung wird von der Entwicklung skaliert, was wiederum die Produktion befähigt. Das mühelose Erlebnis für den technisch unbedarften Mitarbeiter im Flugzeug ist nur möglich, weil der Designer die Präzision vorgegeben und die Entwicklung sie umgesetzt hat.

Das ist der Kraftmultiplikator. Lolly ist keine Schublade getrennter Tools für getrennte Rollen - es ist ein einziger deterministischer Asset-Lebenszyklus, den jede Rolle berührt, und jede Hand, durch die er geht, vervielfacht den Wert der vorherigen.

Ein Tool, viele Ausgaben

Die Markenregeln liegen im Tool, nicht in jeder Datei, die es erzeugt (siehe Wie Lolly sich einordnet). Richten Sie das Tool richtig ein, und jede Ausgabe erbt dieselbe Schrift, Farbe und denselben Abstand, ob das eine einzelne Karte ist oder eine Tabelle mit Zeilen in einem Dutzend Sprachen. Wie Sie Ihre Arbeit prüfen und wer das übernimmt, bleibt Ihre Sache; Lolly macht das, was es zu prüfen gibt, kleiner und die Ausgabe schneller machbar.

Dasselbe deterministische Tool erreicht diese Größenordnung auf drei Wegen, die alle identische Ausgaben erzeugen:

• Eine Person, in der App. Das /pro-Batch-Raster: Zeilen einfügen oder importieren, pro Zeile ein fertiges Asset erhalten, das Zip herunterladen. Kein Design-Know-how, keine Wartezeit.
• Ein Entwickler, über die Kommandozeile. Die CLI führt dieselbe Engine und denselben Render-Pfad headless aus, sodass das Tool über jede Zeile in einem Skript oder einer nächtlichen Pipeline durchlaufen werden kann. Ein lolly <tool> --field=…-Aufruf in einer Schleife ist die gesamte Integration.
• Ein System oder ein KI-Agent, über MCP. Dasselbe Tool programmgesteuert bedient, mit derselben Genauigkeit, für so viele Zeilen, wie der Auftrag hat.

signed by Lolly2026-10-21vector SVG133 paths~15k nodes185 groups1 image195 KBPrüfen Sie es selbstSignierte Datei holen signed by Lolly2026-10-21vector SVG133 paths~15k nodes185 groups1 image195 KBPrüfen Sie es selbstSignierte Datei holen

Ein Satz Markenvorgaben, einmal von einem Designer festgelegt; drei Wege zur identischen Ausgabe.

Das Gesamtbild: wie die Schichten zusammenpassen

Alles ab hier ist Architektur. Das Diagramm zeigt das gesamte System auf einen Blick: Tools sind oben Daten, die Engine in der Mitte kennt keine Plattform, die Shells darunter implementieren einen einzigen Vertrag, und die Kataloge liefern den Inhalt.

                ┌─────────────────────────────────────────────┐
                │              Tools (data, not code)         │
                │   tool.json + template.html + hooks.js?     │
                └─────────────────────────────────────────────┘
                                    ▲
                                    │ talks to via Capability Bridge v1
                                    ▼
                ┌─────────────────────────────────────────────┐
                │                  Engine                     │
                │   loader · validator · runtime · template   │
                │   inputs · url-mode                         │
                │   PLATFORM AGNOSTIC. Knows nothing of DOM,  │
                │   filesystem, or You.                       │
                └─────────────────────────────────────────────┘
                                    ▲
                                    │ implements HostV1
                                    ▼
        ┌──────────────┬──────────────┬──────────────┬──────────────┐
        │  Web Shell   │ Tauri Desktop│ Tauri Mobile │  CLI Shell   │
        │   (PWA)      │              │              │              │
        └──────────────┴──────────────┴──────────────┴──────────────┘
                                    ▲
                                    │ fetches from
                                    ▼
                ┌─────────────────────────────────────────────┐
                │              Catalogs                       │
                │   catalog/tools/index.json + tool dirs      │
                │   catalog/assets/index.json + asset files   │
                └─────────────────────────────────────────────┘

Repository-Layout

Lolly ist ein einziges Repository. engine/, schemas/, scripts/, tests/, api/, docs/, community/, brands/lolly-start/, jedes shells/ und beide services/ sind darin einfache Verzeichnisse. Die einzige Ausnahme ist brands/suse, ein privates Git-Submodul mit dem SUSE-Tool-Pack und -Katalog, optional und in einem öffentlichen Klon nicht vorhanden. Welche Packs ein bestimmter Build liest, bestimmt ein Content-Profil (profiles.json), das pro Prozess aufgelöst wird statt global umgeschaltet zu werden. Den Klon-Befehl und wie eine Änderung innerhalb des privaten Packs committet wird, finden Sie unter Build Guide » Getting the source.

lolly/
├── engine/           # Platform-agnostic core. Open source (MPL-2.0).
│   └── src/
│       ├── index.ts          # public surface - loader, runtime, template, inputs, url-mode
│       ├── loader.ts         # fetches and validates tool files
│       ├── runtime.ts        # orchestrates the 5-step lifecycle
│       ├── template.ts       # Handlebars hydration + annotateTemplate
│       ├── inputs.ts         # manifest → runtime input model
│       ├── url-mode.ts       # URL ↔ input state round-trip
│       ├── validate.ts       # JSON Schema validation of manifests
│       ├── compose.ts        # resolve nested tool renders (composes)
│       ├── embed.ts          # parse portable lolly.tools embed URLs
│       └── bridge/
│           └── host-v1.ts    # type re-export of the @lolly-tools/core contract
│
├── shells/
│   ├── web/          # PWA - hosted online; primary distribution
│   │   └── src/
│   │       ├── main.ts           # boot, routing
│   │       ├── theme.ts          # theme apply/persist (FOUC prevention)
│   │       ├── bridge/           # web implementations of HostV1 APIs
│   │       │   ├── index.ts      # compose all bridge pieces
│   │       │   ├── db.ts         # IndexedDB setup
│   │       │   ├── state.ts      # host.state - saved edits
│   │       │   ├── profile.ts    # host.profile - user details
│   │       │   ├── assets.ts     # host.assets - catalog + user uploads
│   │       │   ├── clipboard.ts  # host.clipboard
│   │       │   ├── export.ts     # host.export - rasterise/serialize
│   │       │   ├── net.ts        # host.net - allowlisted fetch
│   │       │   └── media.ts      # host.media - live camera frames (onFrame)
│   │       ├── catalog/
│   │       │   └── sync.ts       # boot-time catalog sync + offline cache
│   │       ├── styles/           # app-wide CSS (app.css, picker.css, tokens.css)
│   │       └── views/
│   │           ├── gallery.ts    # tool library listing + saved-state cards
│   │           ├── tool.ts       # mounts one tool (inputs + canvas + actions)
│   │           ├── picker.ts     # asset picker UI (invoked by host.assets)
│   │           ├── profile.ts    # user details editor
│   │           ├── projects.ts   # /p - folders of saved sessions (nested; folder/selection export)
│   │           └── free-canvas.ts # free-canvas editor overlay for render.layout:"editor" tools
│   │
│   ├── cli/          # Node.js CLI - same engine, headless jsdom
│   │   ├── bin/lolly.ts
│   │   └── src/
│   │       ├── run.ts    # loadTool → createRuntime → export → write file
│   │       └── bridge.ts # CLI implementation of HostV1
│   │
│   ├── tui/          # Interactive terminal shell (Ink) - reuses the CLI bridge
│   │   └── src/
│   │       ├── main.tsx  # full-screen app: Gallery / Projects / Profile / ToolView
│   │       └── bridge.ts # CLI bridge + on-disk state under ~/.lolly
│   │
│   ├── tauri-desktop/ # downloadable desktop app
│   └── tauri-mobile/  # iOS/Android app
│
├── community/        # the brand-agnostic tool pack - data, not code. Public (MPL-2.0).
│                     #   A SELECTION follows; a profile mounts these plus whatever
│                     #   tools the active brand pack carries of its own.
│   ├── qr-code/
│   ├── snippet/
│   ├── countdown-timer/
│   ├── color-palette/
│   ├── street-map/        # offline vector city-block maps
│   ├── url-shot/          # "URL Screenshot" (capture capability)
│   ├── strip-data/        # on-device metadata strip - JPEG/PNG/SVG/PDF (file in → clean file out)
│   ├── compress-pdf/      # on-device PDF compressor - recompresses images (file in → smaller file out)
│   ├── chart/             # SVG charts from structured data
│   ├── filter/            # photo effects in one tool - halftone/scanline/posterize/voronoi (vector), duotone/pixel-stretch/imperfections (raster)
│   ├── meeting-planner/   # global timezone meeting scheduler
│   ├── calendar-ics/      # event → .ics calendar file plus a card
│   ├── wayfinding-signage/ # event signage; directions blocks auto-fit label text
│   ├── text-helper/       # on-device text workbench (format/decode/hash/de-identify)
│   ├── design/     # "Design" - freeform WYSIWYG editor canvas (render.layout: editor)
│   ├── multi-page-pdf/    # multi-page PDF document - cover, flowing content blocks, back page
│   ├── diagram-builder/   # org / layercake / process / cycle / pyramid diagrams
│   ├── logo-wall/         # many logos → auto-packed grid
│   ├── icon/              # favicon .ico / png / svg from text + colours
│   └── lottie-digi-ad/    # animated Lottie ad banners
│
├── brands/            # brand packs - a catalog each, and optionally tools of their own
│   ├── lolly-start/   # the blank starter brand, owned here
│   │   └── catalog/
│   │       ├── tools/index.json    # tool registry, generated per brand
│   │       └── assets/
│   │           ├── index.json      # asset registry
│   │           └── lolly/...       # logo, palette, tokens
│   └── suse/          # PRIVATE submodule - the SUSE tools and the SUSE catalog
│
├── schemas/          # JSON Schema for tool.json, asset entries, AssetRef
├── scripts/          # build-catalog-index.ts, checksum-assets.ts, validate-catalog.ts
├── tests/            # engine tests
└── docs/             # this file + authoring guides + positioning

Plattform-Bereitstellungsmodell

Die Plattform läuft auf mehreren Oberflächen - Web-PWA, Tauri Desktop/Mobile, der skriptfähigen CLI und der interaktiven TUI. Alle nutzen dieselbe Engine und dieselben Tool-Dateien.

Web (PWA) - primäre Distribution

Gehostet unter einer von SUSE kontrollierten URL. Funktioniert offline, sobald der Service Worker Tools und Assets zwischengespeichert hat. Hier werden die meisten Mitarbeitenden, Anbieter und Partner die Plattform nutzen. Kein Konto erforderlich - der Zustand wird pro Gerät in IndexedDB gespeichert.

Die Web-Shell ist aus einem einzigen Layout heraus responsiv. Auf dem Desktop ist ein Tool eine größenveränderbare Steuerungs-Seitenleiste neben einer Vorschaufläche mit trackpad-nativer Canvas-Navigation (Cmd/Strg-Mausrad oder Zwei-Finger-Zoom um den Cursor, Leertaste- oder mittlerer Klick-Zug zum Verschieben, Tasten 0/1/+/− und ein Fit/%-HUD). Auf Mobilgeräten (≤640px) werden die Steuerelemente zu einem oben verankerten Sheet mit einem Ziehgriff, der zwischen Peek/Halb/Voll einrastet (Tippen schaltet um), über einer statischen Vollbild-Vorschau, und eine schwebende Schaltfläche Render öffnet die Export-Steuerelemente in einem Bottom-Sheet-Popup. Touch erhält Pinch-Zoom und Zieh-Schwenk auf der Vorschau. Der Render-Pfad und die Export-Steuerelemente sind in beiden Fällen identisch - nur die Bedienoberfläche passt sich neu an.

signed by Lolly2026-10-21vector SVG131 paths~6.1k nodes158 groups1 image142 KBPrüfen Sie es selbstSignierte Datei holen

Dasselbe Tool in Handybreite, ohne ein zweites Layout pflegen zu müssen: Die Steuerelemente werden oben zu einem Sheet, die Vorschau nimmt den gesamten Bildschirm ein, und die Render-Pille schwebt darüber.

signed by Lolly2026-10-21vector SVG97 paths~3.3k nodes113 groups99 KBPrüfen Sie es selbstSignierte Datei holen signed by Lolly2026-10-21vector SVG97 paths~3.3k nodes113 groups100 KBPrüfen Sie es selbstSignierte Datei holen

Batch-Modus (/pro). Die Web-Shell liefert außerdem ein tabellenartiges Batch-Raster (shells/web/src/pro/), das viele Zeilen gleichzeitig über ein oder mehrere Tools rendert. Es unterstützt CSV/TSV-Roundtrip plus Tabellen-Einfügen, Vorlage/Format/Größe/Einheit/DPI pro Zeile, ein Blocks-Editor-Seitenpanel mit Live-Vorschau, einklappbare Export-Spalten, eine „Relevanz"-Tag-Leiste pro Zeile, das Neuordnen von Zeilen per Zieh-Griff links, eine zweistufige Löschbestätigung, gespeicherte Batch-Sessions und einen .zip-Download. Das ist die 1:n-Oberfläche hinter der Positionierung „Massen-Content-Erstellung".

Tauri Desktop / Mobile

Verpackte native App (kleiner Footprint dank Tauri). Bietet vollständige Offline-Verfügbarkeit, Dateisystemzugriff für CLI-abhängige Tools (PDF Smasher, Font Outliner) und Kamerazugriff. Für Mitte 2026 ist ein Tooling-Ausbau geplant.

CLI

lolly <tool-id> [--input=value ...] --output=file.png

Desktop-Nutzer können viele Tools über das Terminal aufrufen. Die CLI-Shell lädt dieselbe Engine, erzeugt ein jsdom-DOM, durchläuft denselben Render-Pfad und schreibt die Datei. Der URL-Modus ist der Transport - die CLI ist keine eigenständige Implementierung. Das garantiert, dass CLI- und GUI-Ausgaben identisch sind.

lolly qr-code --url=https://suse.com --output=qr.svg
lolly quotes --quote="Ship it." --output=quote.png
lolly                        # lists available tools
lolly qr-code                # lists inputs for that tool

TUI

pnpm run tui

Das interaktive Gegenstück zur CLI: eine bildschirmfüllende, tastaturzentrierte Terminal-App (auf Basis von Ink) zum Durchsuchen von Tools, Ausfüllen von Eingaben, Speichern von Projekten und Exportieren - alles ohne GUI. Ihre Host-Bridge nutzt die Implementierung der CLI wieder für die DOM-freien Formate (SVG/EMF/EPS/HTML + Text/Daten) und ergänzt sie um einen Zustand auf der Festplatte unter ~/.lolly sowie eine optionale Inline-Vorschau. Darüber hinaus verfügt sie über eine Browser-Render-Ebene: ein abgegrenztes, headless Chromium (dasselbe, das der MCP-Server installiert), das auf Anfrage Raster/PDF/Video sowie Live-URL-Erfassung erzeugt - es steuert eine gebaute Kopie der Web-Shell an, sodass die Ausgabe identisch ist, und startet erst, wenn ein solches Format zum ersten Mal exportiert wird. So laufen auch url-shot (mit Zuschnitt + Neueinfärbung + vektoriellem PDF/SVG) und jedes Raster-/PDF-Tool im Terminal. Siehe den TUI-Guide.

Auf welcher Oberfläche Sie sich auch befinden, der Tab Capabilities im Dashboard zeigt die vollständige Übersicht dessen, was die Plattform zu leisten erklärt - gruppiert und lesbar, ohne ein einziges Tool zu öffnen.

Tool-Kategorien

Tools werden in ihrem Manifest mit einer category versehen, um sie in der Galerie zu gruppieren.

Die Zeilen erscheinen in der Reihenfolge der Galerie-Abschnitte. Der Abschnitt utility wird immer zuletzt in der Galerie angezeigt (nach jeder anderen Kategorie, auch künftigen) - er ist die geräteinterne Schublade "Offline Utilities".

Diese Zellen sind Beispiele, keine Inventarlisten. Welche Tools existieren, ist eine Eigenschaft des von Ihnen eingebundenen Profils, nicht dieser Seite: Ein Brand Pack fügt eigene hinzu und kann ein Community-Tool ausschließen, das es lieber nicht ausliefert. catalog/tools/index.json - aus den Manifesten generiert und das Register, das die Galerie tatsächlich liest - ist die maßgebliche Liste; um zu zählen, was ein Profil einbindet, zählen Sie die Manifeste (ls community//tool.json brands//tools/*/tool.json), statt sich auf eine hier notierte Zahl zu verlassen. (Eine Tool-ID, die in zwei Packs vorkommt, wird einmal eingebunden, aus dem gewinnenden Pack.)

Tools werden außerdem nach Status klassifiziert: official (von der Marke freigegeben, kein Wasserzeichen), community (externer Beitrag), experimental (Exporte mit Wasserzeichen). Der Großteil der Bibliothek ist official; die neueren Studios und die Aufnahme-Tools liegen tendenziell bei community oder experimental, während sie sich einpendeln. Jede Oberfläche zeigt das Badge, sodass Lesende wissen, was sie sich holen, bevor sie es öffnen - und wie bei den Kategorie-Zellen oben ändert sich die Zuordnung nach Status zu schnell, um sie hier aufzuzählen. Lesen Sie sie aus der Galerie oder dem generierten Index ab.

Design ist das erste Tool, das auf dem freien Canvas-Modus render.layout: "editor" aufbaut - eine chromlose Oberfläche zur direkten Bearbeitung, auf der Sie Boxen mit Text, Formen und Bildern ziehen, skalieren, drehen und einrasten lassen, und die dann über denselben Render-Pfad exportieren wie jedes andere Tool.

Strip Hidden Data ist das erste On-Device-Utility (privacy: "on-device"): ein Content-Transform-Tool, das eine von Ihnen bereitgestellte Datei entgegennimmt, sie vollständig im Browser verarbeitet und eine saubere Kopie zurückgibt - nie hochgeladen, nie mit Wasserzeichen versehen, keine Herkunftsangabe eingebettet. Text ist das zweite - eine On-Device-Werkbank für alltägliche Paste-in-eine-Website-Aufgaben (JSON-Formatierung, JWT-Dekodierung, Base64, URL-Encode/Decode, SHA-Hashing). Compress PDF ist das dritte - es verkleinert ein PDF, indem es dessen Bilder neu komprimiert, ebenfalls vollständig auf dem Gerät. Die Markierung und ihr Badge-Text "Runs on your device - nothing is uploaded" decken jetzt das gesamte Transform-Set ab: Strip Hidden Data, Text, Compress PDF, Convert Image (HEIC/TIFF/AVIF → WebP/JPG/PNG), Convert Font, Redact (Bereiche eines Bildes, SVG oder PDF unkenntlich machen), Prompt Card und Rebrand (ein .pptx direkt neu einfärben), sofern das Profil es einbindet. Dies ist eine Datenschutz-Utility-Kategorie, die das Weitergeben vertraulicher Dateien an Einzelzweck-Websites überflüssig macht.

signed by Lolly2026-10-21vector SVG124 paths~29k nodes324 groups395 KBPrüfen Sie es selbstSignierte Datei holen signed by Lolly2026-10-21vector SVG124 paths~29k nodes324 groups396 KBPrüfen Sie es selbstSignierte Datei holen

Hinweis: category und status werden aus jedem tool.json in catalog/tools/index.json (das Register, das die Galerie liest) denormalisiert. Das Manifest ist die Quelle der Wahrheit - der Index wird von pnpm run build:catalog generiert, und pnpm run validate:catalog lässt die CI fehlschlagen, wenn der committete Index von den Manifesten abweicht.

Architektonische Festlegungen

Diese Entscheidungen sind gesetzt. Jede davon zu ändern ist ein größeres Unterfangen - sie prägen jede andere Entscheidung in der Codebasis.

1. Deklarative Tools mit imperativer Notlösung

Ein Tool besteht aus einem Manifest (tool.json) + einer Vorlage (template.html) + optionalem hooks.js.

Das Manifest deklariert Inputs. Nicht die Vorlage. Inputs werden nicht aus Handlebars-Tokens abgeleitet. Das Manifest ist der Vertrag; die Vorlage nutzt benannte Variablen über {{id}}.

signed by Lolly2026-10-21vector SVG39 paths~2.6k nodes54 groups2 images43 KBPrüfen Sie es selbstSignierte Datei holen signed by Lolly2026-10-21vector SVG39 paths~2.6k nodes54 groups2 images43 KBPrüfen Sie es selbstSignierte Datei holen

Hooks sind optional. Die meisten Tools sind rein deklarativ - Manifest + Vorlage genügt. Tools, die berechnete Werte benötigen (QR-Kodierung, Aufbereitung von Chart-Daten), stellen hooks.js bereit, das benannte Lifecycle-Funktionen exponiert (onInit, onInput, onFrame - der Per-Frame-Hook für Live-Kamera bei bewegungsreaktiven Tools - onLevel, beforeExport, afterExport, exportFile - der Datei-rein/Datei-raus-Transformationspfad, den geräteinterne Utilities wie Strip Hidden Data nutzen - und exportStill für ein Tool, das sein eigenes tiefes Rastering besitzt). Der Host lädt Hooks über new Function('host', …) mit der Capability Bridge als Closure-Scope injiziert. Dies ist ein Portabilitätsvertrag, keine Sicherheits-Sandbox: Hooks laufen weiterhin im Realm der Seite und können in einer Browser-Shell auf window/fetch/document zugreifen - host. ist die unterstützte, portable Oberfläche, keine erzwungene Grenze. Asynchrone Hook-Ergebnisse sind zeitlich begrenzt (onInit 5s, onInput 2s, beforeExport/afterExport 5s, exportFile/exportStill 10s), und verspätete Ergebnisse werden verworfen; ein außer Kontrolle geratener synchroner* Hook kann nicht unterbrochen werden. Nicht vertrauenswürdiger Drittanbieter-Hook-Code ist daher erst sicher auszuführen, wenn die Worker-Isolation ausgeliefert ist.

Das ist wichtig, weil: deklarative Tools von Nicht-Entwicklern erstellt werden können. Wäre jedes Tool eine Web-App, würde der Risikohinweis "begrenzte Kompetenzen zum Erstellen/Pflegen von Arbeits-Templates" zu einem dauerhaften Engpass.

2. Tools und Assets sind Daten, kein gebündelter Code

Die Web- und Tauri-Apps holen Tool- und Asset-Kataloge beim Start von einer bekannten URL, cachen sie lokal und arbeiten mit dem, was vorhanden ist. Eine neue Event-Kachel oder ein saisonales Asset hinzuzufügen erfordert kein App-Release.

Asset-Bytes werden per SHA-256 geprüft, um CDN-Poisoning zu verhindern. Asset-id + version steuert die Cache-Invalidierung.

3. Die Capability Bridge ist die einzige API, die Tools sehen

Tools rühren nie das DOM außerhalb ihres Vorlagenbereichs an, rufen nie direkt fetch auf, lesen nie das Dateisystem. Sie rufen versionierte host.*-Methoden auf. Die kanonische Definition des Vertrags ist packages/core/src/host-v1.ts - das Tool-Autoren-SDK @lolly-tools/core, sodass Dritte dagegen entwickeln können, ohne von der Engine abhängig zu sein; engine/src/bridge/host-v1.ts ist ein Typ-Reexport davon, und Engine-/Shell-Code importiert weiterhin unverändert von diesem Pfad:

Optionale, additive Oberflächen erscheinen nur, wenn eine Shell sie bereitstellt. Manche sind Capability-gated - nur exponiert, wenn das Tool das passende Flag deklariert: host.compose (das Rendering eines anderen Tools einbetten - compose), host.capture (Seitenaufnahme für URL Screenshot - capture) und host.recorder (Mikrofon-/Kamera-/Bildschirmaufnahme für die Aufnahme-Tools - microphone / camera / screen). Der Rest ist Feature-detected - vorhanden, wann immer die Shell es bereitstellen kann, wobei das Tool einen Fallback für Shells behält, die es nicht können.

Eine Handvoll zentraler Oberflächen, um zu zeigen, was abgedeckt wird - Host API dokumentiert jede einzelne, und packages/core/src/host-v1.ts ist der Vertrag selbst:

Der Rest folgt denselben Regeln und ist gleich mitdokumentiert: pdf (1.8) und pptx (1.58) für geräteinterne Dokumentchirurgie, audio (1.71) und speech (1.96) für Clip-Analyse sowie geräteinternes TTS/Transkription, viz (1.72) für den MilkDrop-Platzhaltervertrag, codec (1.100) und layers (1.102) für Deep-Bit- und Layered-Bitmap-Ausgabe, upscale (1.101) und matte (1.103) für die geräteinternen Modelle, raster (1.105) für Hooks mit eigener Pixelarbeit, connectors (1.106) für exportsichere Pfeile und c2pa (1.85) für das Signieren fertiger Bytes. Die Zahl wächst; die Regeln nicht.

Die deklarierbaren Capabilities sind: network, filesystem, clipboard, camera, microphone, screen, ffmpeg, wasm, capture, compose. (screen, hinzugefügt in 1.54, ist Bildschirmaufnahme über host.recorder - der Nutzer wählt einen Bildschirm/ein Fenster/einen Tab in browsereigener UI; zu unterscheiden von capture, das eine vom Tool selbst benannte URL rastert.)

Dasselbe Tool läuft im Browser, in Tauri und in der Headless-CLI, weil jede Shell diese Schnittstelle implementiert - das Tool weiß nie, in welcher es sich befindet.

Die Bridge ist versioniert. Methoden hinzuzufügen ist eine Minor-Version. Signaturen zu entfernen oder zu ändern ist ein Major-Version-Sprung. Wenn v2 erscheint, muss v1 weiter funktionieren.

4. Asset-IDs gelten für immer

suse/logo/primary ist ein Vertrag. Einmal veröffentlicht:

• Die ID ändert sich nie, wird nie wiederverwendet.
• Byte-Änderungen → version im Manifest erhöhen.
• Durch ein neues Asset ersetzt → deprecated: true setzen und optional replacedBy.
• Bestehende Referenzen lösen sich immer auf.

Das macht gespeicherte Tool-Zustände und per URL geteilte Links über Jahre hinweg dauerhaft.

5. Der URL-Modus ist erstrangig

Jeder Input muss als URL-Parameter ausdrückbar sein:

lolly.tools/#/tool/qr-code?url=https://suse.com&ecl=H

signed by Lolly2026-10-23vector SVG55 paths~2.6k nodes38 groups60 KBPrüfen Sie es selbstSignierte Datei holen signed by Lolly2026-10-23vector SVG55 paths~2.6k nodes38 groups61 KBPrüfen Sie es selbstSignierte Datei holen

Der CLI-Modus ist der URL-Modus unter einem anderen Transport - die CLI-Shell baut aus argv ein URL-State-Objekt und führt dieselbe Engine-Pipeline aus. Es gibt einen einzigen Render-Pfad. Die CLI kann nicht von der GUI abweichen, weil sie keine separate Implementierung ist.

url-mode.ts übernimmt den Round-Trip (Parsen und Serialisieren). Ein Satz reservierter Parameter wird dem Tool nie als Input weitergegeben: die Ausgabesteuerungen (format, export, copy, filename, width/w, height/h, unit, dpi), die Druck- und Herkunftsregler (bleed, marks, profile, password, c2pa, imprint, durable, meta, hdr, depth, cuts) und die Zustandsträger (template, z - das gepackte "Kürzester Link"-Token - und zx, dasselbe mit Passwort verschlüsselt). Der Satz RESERVED in engine/src/url-mode.ts ist die maßgebliche Quelle und durch einen Test fixiert; URL Mode dokumentiert jeden einzelnen davon, einschließlich der wenigen hier nicht aufgeführten. Asset-Inputs im URL-Modus werden über ihre id serialisiert; die Runtime löst sie vor der Hydration über host.assets.get() auf. width/height sind Werte in unit (Standard px, auch mm/cm/in/pt/pc); bei einer physischen Einheit legt dpi die Rasterauflösung fest. Sie bestimmen die Dokumentgröße der Canvas und füllen das Export-Dimensionen-Panel vor.

Da jeder Input im Link mitreist, ist eine Parameteränderung ein anderes fertiges Asset. Diese ganze Palette ist eine Ausgangsfarbe, eine Harmonie und eine Stufenzahl:

signed by Lolly2026-10-21vector SVG10 groups25 KBPrüfen Sie es selbstSignierte Datei holen signed by Lolly2026-10-21vector SVG10 groups25 KBPrüfen Sie es selbstSignierte Datei holen

6. Speicherung läuft über die Bridge, nicht direkt

Web-Shell: IndexedDB. Tauri: Dateisystem. CLI: im Arbeitsspeicher. Tools sehen nur host.state.save(slot, data) und host.state.load(slot). localStorage wird nicht verwendet - er ist zu klein und kann keine Blobs speichern.

Nutzer können mehrere benannte Bearbeitungsstände pro Tool speichern und später zu jeder Sitzung zurückkehren. Es ist keine Kontoerstellung nötig; der Zustand ist gerätebezogen. Weil die Bridge die einzige Schnittstelle ist, ist dieser gerätebezogene Zustand auch portabel: shells/web/src/data-transfer.ts liest alles über host.profile/host.state/host.assets wieder aus in ein einziges lolly-backup-Zip, das sich auf jeder anderen Installation importieren lässt - die Offline-Antwort auf "auf ein neues Gerät umziehen", die keinen Server braucht (vollständige Spezifikation: docs/data-transfer.md). Die Mehrgeräte-Synchronisierung läuft bereits auf dieser Grundlage und sendet dasselbe Bundle an den vom Nutzer gewählten Speicherort (docs/sync.md).

7. Reifegrad-Tags sagen, was ein Tool ist

Jedes Tool gibt in seinem Manifest status: official | community | experimental an. Die Galerie sortiert nach Status. Experimentelle Tools versehen ihre Exporte automatisch mit einem Wasserzeichen - das Wasserzeichen wird von host.export.render angewendet, nicht vom Tool, sodass es von keinem nicht-offiziellen Tool-Autor abgeschaltet werden kann.

Das ist eine strukturelle Antwort auf das Wahrnehmungsrisiko, dass jedes Tool in der Galerie gleich viel Gewicht trägt. Welchen Prozess ein Team auch immer um den Katalog legt, er kommt obendrauf.

8. Tool-Eingaben sind über das Manifest typisiert, einschließlich Assets

Eingaben deklarieren einen type: text, longtext, number, boolean, color, select, asset, date, time, datetime-local, url, blocks, vector, table und file. Der Host rendert pro Typ ein generisches Steuerelement aus dem Manifest - Tools schreiben keinerlei Steuerelement-Code. (Das Vorausfüllen aus dem Nutzerprofil ist kein Typ - jede Eingabe kann bindToProfile tragen.) Drei davon haben mehr Gewicht als der Rest:

• asset (mit filter und allowUpload) ist die Brücke zum globalen Asset-System; allowUpload: false ist der Hebel zur Markendurchsetzung für Dinge wie Sponsoring-Kachel-Logos, bei denen nur Bibliotheks-Assets erlaubt sind. Nutzer-Uploads verwenden dieselbe AssetRef-Form wie Bibliotheks-Assets, sodass Tools sie identisch behandeln.
• blocks ist eine wiederholbare Feldgruppe - eine Mini-Tabelle innerhalb einer Eingabe, bearbeitet in einem Seitenpanel, mit einem typisierten/unterscheidenden Hinzufügen-Menü und Asset-Feldern pro Block. Ein Klick auf einen gerenderten Block auf der Canvas fokussiert die Zeile dieses Blocks. Verwendet von meeting-planner, chart-creator, event-name-badge, wayfinding-signage, color-block und digi-ad.
• vector gruppiert einen festen Satz von Zahlen (z. B. eine Transformation) zu einem zusammengesetzten Steuerelement; file hält die eigene Datei des Nutzers als Bytes im Arbeitsspeicher für On-Device-Transform-Werkzeuge (z. B. strip-data und compress-pdf).

9. Templates sind logikfrei (Handlebars, nicht EJS)

Handlebars wurde bewusst gegenüber EJS gewählt:

• Logikfrei. Templates können von Nicht-Entwicklern erstellt werden.
• Standardmäßig sicher. {{x}} escaped HTML; {{{x}}} ist optional roh.
• Kein beliebiges JS in Templates bedeutet keine Angriffsfläche für eine Prüfung pro Template auf XSS.

Logik lebt in hooks.js, wo sie explizit und überprüfbar ist. Verfügbare Handlebars-Helfer: {{default}}, {{upper}}, {{lower}}, {{eq}}, {{markdown}}, {{asset ref}}, {{asset ref "property"}} (dazu Datenformat-Helfer icsStamp/rfcText/csvCell, verwendet von begleitenden .ics/.vcf/.csv-Templates).

10. Tools setzen sich aus Tools zusammen

Ein Tool kann das Rendering eines anderen Tools einbetten, ohne Tool-zu-Tool-Importe - die Komposition wird von der Engine aufgelöst, niemals vom Tool-Code. Es gibt zwei Oberflächen:

• Deklaratives Manifest - composes: [{ id, tool, inputs, format?, width?, height? }]. Die Engine rendert das benannte Kind-Tool und platziert das Ergebnis im logikfreien Template als {{asset <id>}}. event-name-badge setzt sich heute aus qr-code als SVG zusammen.
• Portable Einbettungs-URL - <img src="https://lolly.tools/tool/<id>.<ext>?<inputs>">. Die Shell rendert dieses Kind lokal (bis das lokale Rendering abgeschlossen ist, wird ein Platzhalter-Pixel angezeigt); es wird nie etwas von lolly.tools abgerufen.

Das Rendering jedes beliebigen Tools lässt sich zusammensetzen: Ein SVG-Kind bleibt ein echter Vektor, wenn das Eltern-Tool nach SVG oder PDF exportiert, und rastert scharf für PNG; PNG/JPG/WEBP-Kinder werden als Bilder eingebettet. Erfordert die Fähigkeit compose. Zusammengesetzte Kinder sind Zwischenprodukte - nie mit Wasserzeichen versehen oder mit Provenienz gestempelt - und die Komposition degradiert grazil: Eine Shell, die ein Kind nicht rendern kann, lässt den Slot einfach aus, und das Eltern-Tool wird trotzdem gerendert.

Was wir bewusst nicht getan haben

• Kein EJS / kein beliebiges JS in Templates. Die XSS-Angriffsfläche ist null. Logik lebt in hooks.js.
• Kein verpflichtendes Asset-CMS. Einzelpersonen nehmen ihre eigenen Kreativdateien direkt in der App in Assets auf (die Ansicht Assets und das Brand Studio) - kein Server, keine Admin-Konsole. Arbeit wird als Sitzung weitergegeben: Ein Freigabelink trägt ihre Eingaben und Einstellungen (hochgeladene Dateien reisen in einer .lolly mit), und dieselbe Sitzung reist in einem Backup oder über eine Collab-Sitzung mit. Wer auch immer das Deployment kontrolliert, kann eine geteilte Sitzung dann als Template festschreiben - den Link öffnen, ihre Werte als Template-Eintrag im Verzeichnis dieses Tools im Brand-Pack festhalten und committen -, wonach sie in der "New from template"-Auswahl des Tools erscheint und als ?template=<id> direkt verlinkbar ist. Git ist der Festschreibungsschritt des Deployment-Betreibers, nie der der erstellenden Person. Für einen geteilten, geregelten Katalog kann eine Organisation das Asset-Verzeichnis auf dieselbe Weise verwalten und Aktualisierungen über PR-Review absichern - ein verfügbares Governance-Modell, keine Anforderung der App.
• Kein erzwungenes RBAC. Die offene App ist standardmäßig öffentlich zugänglich; Markenrisiko wird über Reifegrad-Kennzeichnungen und Wasserzeichen gesteuert. Eine Organisation, die strengere Kontrolle möchte, legt ihre eigene Authentifizierung und den oben beschriebenen git-geprüften Katalog darüber.
• Keine zentrale Datenbank. Aller Nutzerzustand liegt pro Gerät; die optionale Synchronisierung kopiert ihn an den vom Nutzer gewählten Speicherort, niemals in eine Lolly-Datenbank.
• Kein gemeinsamer Tools-/Engine-Codepfad. Die Engine ist Open Source, ebenso die markenneutralen Tools in community/; ein Brand-Pack wie das private brands/suse/ trägt seine eigenen Tools und seinen eigenen Katalog nach eigenen Bedingungen. So oder so wird die Trennung erzwungen (keine Cross-Imports von engine/ in Tool-Inhalte), damit die Aufteilung sauber bleibt.

Der Lebenszyklus eines Renders

Ein Nutzer öffnet lolly.tools/#/tool/qr-code?url=https://suse.com&ecl=H:

1. Boot. Die Web-Shell öffnet IndexedDB, erstellt die Capability-Bridge und synchronisiert die Tool- und Asset-Kataloge (oder lädt sie offline aus dem Cache).
2. Route. URL-Hash → tool-View, mit extrahiertem qr-code und URL-Parametern.
3. Load. loadTool('qr-code', fetchFile) lädt tool.json, validiert gegen das JSON Schema und lädt template.html, styles.css und den hooks.js-Quelltext.
4. Parse URL state. parseUrlState übersetzt URL-Parameter in anfängliche Eingabewerte. Asset-Referenzen (?logo=suse/logo/primary) werden als leichtgewichtige { id, _unresolved: true }-Objekte geparst.
5. Runtime. createRuntime(tool, host, initialValues) baut das Input-Modell auf (durch Zusammenführen von Profildaten, Standardwerten und Anfangswerten), löst Asset-Referenzen über host.assets.get() auf, lädt Hooks (Closure-gebundener host, nicht sandboxed) und ruft hooks.onInit auf.
6. Render. Die Shell abonniert die Runtime; bei jeder Zustandsänderung erhält sie { model, hydrated }. Sie rendert die Eingabesteuerungen aus dem Modell und schreibt das hydrierte Template-HTML in #tool-canvas.
7. Interact. Der Nutzer tippt in ein Eingabefeld → runtime.setInput(id, value) → Constraints werden angewendet → hooks.onInput wird aufgerufen → erneute Hydrierung → erneutes Rendern. Die Canvas aktualisiert sich live.
8. Export. Der Nutzer klickt auf Download(PNG) → runtime.export(canvasNode, 'png') → host.export.render (rastert über dom-to-image-more; SVG/PDF durchlaufen dedizierte DOM-durchlaufende Vektorisierer) → Blob → host.export.download. Der Formatumfang, den ein Tool nutzen kann, ist breit gefächert, und das render.formats-Enum in schemas/tool.schema.json ist dafür die maßgebliche Quelle - Raster und Float-Raster, Vektoren und Schnittdateien, Druck/CMYK, Bewegtbild, editierbare Dokumente (pptx, docx, odt), Paletten- sowie Daten-/Textausgaben, Audio- und Schriftdateien. URL Mode nennt jede Kennung und was sie erzeugt. Audio steht in diesem Enum wie alles andere (wav, mp3, m4a, opus, deklariert vom Audiogram und den Aufnahme-Tools); getrennt davon steuert der render.capture-Modus eines Aufnahme-Tools host.recorder, dessen Aufnahme als fertiger Blob in dem Container ankommt, den der Browser aufgezeichnet hat. (Tools, die render.export: false setzen - z. B. Color Palette, Countdown Timer, Strip Hidden Data, Text, Compress PDF - blenden die Download-/Format-/Dimensionssteuerungen aus.) Physikalische Einheiten werden hier pro Format umgerechnet (PDF → echte Seitenpunkte, Raster → Pixel bei DPI mit einem pHYs-Chunk). Autorschafts-/Herkunftsmetadaten (Autor, Tool, Quelle - erzeugt von engine/src/metadata.ts) werden pro Format eingebettet: PNG iTXt, JPEG EXIF, PDF-Info-Dictionary, SVG <metadata>, GIF-Kommentar. Experimentelle Tools erhalten ein Wasserzeichen, das vom Host eingefügt wird, nicht vom Tool.

signed by Lolly2026-10-21vector SVG77 paths~6.0k nodes87 groups3 images88 KBPrüfen Sie es selbstSignierte Datei holen signed by Lolly2026-10-21vector SVG77 paths~6.0k nodes87 groups3 images88 KBPrüfen Sie es selbstSignierte Datei holen

Derselbe Lebenszyklus in Tauri. Derselbe Lebenszyklus in der CLI - jsdom stellt das Headless-DOM bereit; die Ausgabe geht in eine Datei oder nach stdout.

Open-Source-Status

Code steht unter MPL-2.0. engine/, shells/, services/, schemas/ und docs/*.ts sind Open Source unter MPL-2.0 - eine anbieterneutrale Scaffolding-Plattform für Brand-Tooling, alles in einem einzigen öffentlichen Repository, lolly-tools/lolly.

Tool-Inhalte werden als Brand-Packs ausgeliefert, jedes mit eigenen Bedingungen (siehe die NOTICE.md des jeweiligen Packs). community/ ist ein Verzeichnis dieses Repositorys, und seine markenunabhängigen Tools stehen ebenfalls unter MPL-2.0. brands/suse/ ist das private Pack suse-lolly, das einzige Submodul: die SUSE-Tools und der SUSE-Katalog, proprietär für SUSE, einschließlich der lizenzierten PremiumBeat-Musik. brands/lolly-start/ ist die leere Starter-Marke, die diesem Repository gehört. Schriften werden innerhalb eines Packs unter der SIL Open Font License 1.1 ausgeliefert - das SUSE-Pack enthält die Schriftschnitte SUSE und SUSE Mono.

Es gibt kein tools/- oder catalog/-Verzeichnis im Repository-Root. packages/node-shell/src/content-roots.ts beantwortet zur Lesezeit aus profiles.json, wo Tool <id> liegt und wo sich der Katalog befindet - ein Profil ist also eine Antwort pro Prozess, und es muss vorher kein Baum zusammengestellt werden. Ein echtes Paar aus tools/ und catalog/ wird nur in ein Build-Ergebnis geschrieben - dist/, eine RPM-Payload, ein Container-Image - weil ein Browser diese beiden Pfade über HTTP abruft.

Die Trennung wird erzwungen - es gibt keine Cross-Imports von engine/ in Tool-Inhalte -, sodass die Grenze zwischen Plattform und Inhalt sauber bleibt.

Wo die Engine endet und der Host beginnt

Wenn es sich in reinen Daten + Handlebars beschreiben lässt → Engine. Wenn es das DOM, das Dateisystem, das Netzwerk oder eine beliebige Browser-/Betriebssystem-API berührt → Host.

Die Grenze ist bewusst scharf gezogen. Die Engine ist der Open-Source-Teil. Alles, was etwas über SUSE, bestimmte Plattformen oder Laufzeitumgebungen weiß, bleibt außen vor.

Für die nächste Detailebene zählt engine/README.md jedes Engine-Modul auf und beschreibt, wofür es zuständig ist, und Bedrohungsmodell & Vertrauensgrenzen hält fest, wo dieselbe Grenze zugleich als Vertrauensgrenze dient.