Overzicht

Dit document legt het doel, de structuur en de architectuurbeslissingen voor het Lolly-platform vast. Het weerspiegelt zowel de productvisie als de huidige staat van de codebase.

Status: Lolly is uitgebracht. Versie 1.0 verscheen op 30 augustus 2026 als open source onder MPL-2.0, en functies, standaardwaarden en de toolcatalogus veranderen nog tussen releases. De engine is deterministisch, met één renderpad achter elke shell. De beveiliging is nog niet onafhankelijk geaudit, en het bewijs voor adoptie is enkele maanden oud. Zie Adoptie & Governance voor de huidige stand van zaken en hoe adoptie wordt gemeten.

Hoe je deze pagina leest. Ze bevat twee soorten materiaal, in volgorde. De eerste helft gaat over waarom dit bestaat: het probleem, de positionering en de levenscyclus die één asset doorloopt. Vanaf Het grote plaatje gaat het over hoe de lagen passen: het architectuurdocument voor bijdragers, dat de engine/shell/pack-scheiding, de repository-indeling, de leverdoelen en de toezeggingen behandelt die elke wijziging aan het platform beperken. Als je hier bent om de codebase te wijzigen in plaats van het product te begrijpen, begin dan bij het grote plaatje.

Twee begeleidende documenten gaan dieper dan deze pagina. engine/README.md in de repository is de module-voor-module kaart van de engine, met een gegenereerde tabel van elke module en wat die parset of schrijft. Threat Model & Trust Boundaries is dezelfde architectuur gelezen als trust boundaries, en het is de juiste pagina voor elke vraag over wat de engine als niet-vertrouwd beschouwt.

Waarom dit bestaat

Herhaalbaar creatief werk is te voorspelbaar om steeds vaardige handen in te zetten, en te kwaliteitsgevoelig om zonder vangrails uit te besteden. Aan zijn lot overgelaten gaat het een van drie kanten op: traag, inconsistent of vastzittend aan de templates van een vendor.

Dit platform is het directe antwoord:

Programmatisch creatief en content op schaal - assets gegenereerd uit invoer, met de regels eenmalig vastgelegd, voor wie ze nodig heeft.

Lolly is niet waar een design system wordt bedacht - het is waar het wordt geproduceerd. Zie het als een verkoopautomaat voor ontwerp: maak een keuze, krijg een resultaat. Elke keer. De engine streeft naar de hoogste kwaliteit die elk formaat kan leveren op de hardware die voor je staat, en dezelfde engine maakt hetzelfde bestand op elk platform waarop hij wordt uitgebracht.

Het resultaat is overvloed: elk evenement heeft correcte bewegwijzering, elke CVE-melding past bij de huisstijl, elk label print schoon, elke e-mailhandtekening is actueel - allemaal vanuit tools die de regels al dragen. Het platform behandelt terugkerend, geoperationaliseerd creatief werk. Het is bewust geen tool voor maatwerkcreativiteit - ontwerpers blijven eigenaar van het vlaggenschipwerk.

Innoveer probabilistisch, schaal deterministisch

Elke discussie over AI in een creatieve pipeline loopt vast op dezelfde vraag: welk deel is het werk van de machine? Het is een oude vraag met een uitgemaakt antwoord. Schrijvers en verluchters werkten al met twee instrumenten - de losse schets, waarin niets vaststond en alles geprobeerd kon worden, en de drukpers, intimiderend juist omdat ze zich vastlegde. De schetsen waren waar de kunst gebeurde. De pers was hoe die bij iedereen terechtkwam. Niemand verwarde de twee, en beide bleven zich ontwikkelen - nieuwe inkten, nieuwe lettertypen, nieuwe persen - elk verbeterend in harmonie met het vakmanschap en de intentie die het diende.

Lolly trekt dezelfde lijn. Verken probabilistisch: een model, een ontwerper, een ruw idee, een prompt die ergens uitkomt dat niemand gepland had. Schaal daarna deterministisch - het ding dat veel outputs wordt is een tool, en een tool rendert elke keer op dezelfde manier vanuit inputs die je kunt lezen. De verkenning blijft vrij omdat niets stroomafwaarts ervan afhangt dat het twee keer hetzelfde uitpakt. De output verdient vertrouwen omdat het geen gok is. AI-experimenten omzetten in voorspelbare, reproduceerbare resultaten is geen nieuwe discipline; het is dezelfde arbeidsverdeling die gedrukt werk in de eerste plaats betrouwbaar maakte.

Vertrouw het creatieve proces, schaal met precisie.

Tegenover de alternatieven

De kloof is duidelijk: niets dat vandaag geleverd wordt, biedt output die constraints-first, offline-geschikt, laagdrempelig en intern toegankelijk is. Lolly bevat zelfs een open canvas - Design - waarin kleuren, typografie en assets zich houden aan de merk-globals, zodat vrije opmaak constraints-first blijft. Wat het niet is, is een onbeperkte ontwerpsuite: ontwerpers blijven Illustrator en Figma gebruiken voor maatwerk-vlaggenschipwerk. Permutaties kunnen met deze tool worden samengesteld.

signed by Lolly2026-10-21vector SVG367 paths~62k nodes773 groups3 images1.453 KBControleer het zelfDownload het ondertekende bestand signed by Lolly2026-10-21vector SVG367 paths~62k nodes776 groups3 images1.454 KBControleer het zelfDownload het ondertekende bestand

Gebruik het voor: Snelle generatie van geoperationaliseerde creatieve assets - eventtegels, naambadges, handtekeningen, CVE-meldingen, QR-codes, socialcards, zendingslabels, gestructureerde rapporten.

Gebruik het niet voor: Maatwerk hero-content.

De levenscyclus van een campagne

De duidelijkste manier om te zien wat Lolly is, is geen functielijst - het is één asset volgen terwijl die van hand tot hand gaat. Bekijk hoe één gelokaliseerde campagnekaart door de organisatie beweegt:

1. De ontwerper stelt de regels op. Een ontwerper maakt de basissjabloon in de Design-tool en legt de typografie- en kleurvariabelen van het merk vast. Ze maken niet één kaart - ze doen het fundamentele werk één keer, zodat ze het nooit meer handmatig hoeven te lokaliseren.
2. De developer schaalt het. Diezelfde sjabloon wordt via de CLI in een nachtelijke pipeline aangesloten, zodat een nieuwe grafiek of een nieuwe taalversie automatisch wordt gegenereerd - niemand hoeft het bestand opnieuw te openen.
3. De producer gebruikt het gewoon. Een verkoper, offline in een vliegtuig, opent dezelfde tool en genereert een volledig on-brand presentatie voor een klantafspraak. Geen ontwerpvaardigheid, geen netwerk, geen wachttijd.

De "nieuwe grafiek" in stap twee is een render zoals deze, gegenereerd uit een datastring en een handvol parameters zonder dat iemand een ontwerpbestand opent:

signed by Lolly2026-10-21vector SVG15 paths~1.3k nodes4 groups20 KBControleer het zelfDownload het ondertekende bestand signed by Lolly2026-10-21vector SVG15 paths~1.3k nodes4 groups20 KBControleer het zelfDownload het ondertekende bestand

Het punt is niet dat Lolly goed is voor ontwerpers en goed voor developers en goed voor sales, elk op zichzelf. Het is een estafette: het aanvankelijke werk van de ontwerper wordt door de developer geschaald, wat op zijn beurt de producer versterkt. De moeiteloze ervaring voor de niet-technische verkoper in het vliegtuig is alleen mogelijk dankzij de precisie die de ontwerper vastlegde en de developer implementeerde.

Dat is de krachtvermenigvuldiger. Lolly is geen lade met losse tools voor losse rollen - het is één deterministische asset-levenscyclus die elke rol aanraakt, en elke hand waar hij doorheen gaat vermenigvuldigt de waarde van de vorige.

Eén tool, veel outputs

De merkregels leven in de tool, niet in elk bestand dat hij maakt (zie Hoe Lolly zich verhoudt). Zet de tool één keer goed neer en elke output erft hetzelfde lettertype, dezelfde kleur en spatiëring, of dat nu één kaart is of een spreadsheet met rijen in een tiental talen. Hoe je je werk controleert, en wie dat doet, blijft aan jou; Lolly maakt het ding dat de moeite waard is om te controleren kleiner en de output sneller om te maken.

Dezelfde deterministische tool bereikt die schaal op drie manieren, die allemaal identieke output produceren:

• Een persoon, in de app. Het /pro-batchraster: plak of importeer de rijen, krijg één afgeronde asset per rij, download de zip. Geen ontwerpvaardigheid, geen wachttijd.
• Een developer, vanaf de command line. De CLI draait dezelfde engine en hetzelfde renderpad headless, zodat de tool over elke rij kan worden doorlopen in een script of een nachtelijke pipeline. Een lolly <tool> --field=…-aanroep in een lus is de hele integratie.
• Een systeem of een AI-agent, via MCP. Dezelfde tool programmatisch bediend, met dezelfde nauwkeurigheid, voor zoveel rijen als de taak heeft.

signed by Lolly2026-10-21vector SVG133 paths~15k nodes185 groups1 image195 KBControleer het zelfDownload het ondertekende bestand signed by Lolly2026-10-21vector SVG133 paths~15k nodes185 groups1 image195 KBControleer het zelfDownload het ondertekende bestand

Eén set merkregels, eenmalig vastgelegd door een ontwerper; drie routes naar identieke output.

Het grote plaatje: hoe de lagen samenkomen

Alles vanaf hier is architectuur. Het diagram is het hele systeem in één beeld: tools zijn data bovenaan, de engine in het midden weet niets van welk platform dan ook, de shells eronder implementeren één contract, en de catalogi leveren de content.

                ┌─────────────────────────────────────────────┐
                │              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-indeling

Lolly is een repository. engine/, schemas/, scripts/, tests/, api/, docs/, community/, brands/lolly-start/, elke shells/ en beide services/ zijn gewone mappen daarin. De enige uitzondering is brands/suse, een private git-submodule met het SUSE-toolpakket en de catalogus, optioneel en afwezig in een publieke kloon. Welke pakketten een gegeven build leest, is een content profile (profiles.json), per proces bepaald in plaats van globaal omgeschakeld. Zie Build Guide » Getting the source voor het kloon-commando en hoe een wijziging binnen het private pakket wordt gecommit.

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

Platformleveringsmodel

Het platform draait op meerdere oppervlakken - web-PWA, Tauri desktop/mobiel, de scriptbare CLI en de interactieve TUI. Ze gebruiken allemaal dezelfde engine en dezelfde toolbestanden.

Web (PWA) - primaire distributie

Gehost op een door SUSE beheerde URL. Werkt offline zodra de service worker tools en assets heeft gecachet. Dit is waar de meeste medewerkers, leveranciers en partners het platform zullen gebruiken. Geen account vereist - status wordt per apparaat opgeslagen in IndexedDB.

De webshell is responsive vanuit één layout. Op desktop is een tool een resizable bedieningszijbalk naast een previewvenster met trackpad-eigen canvasnavigatie (Cmd/Ctrl-scroll of pinch om rond de cursor te zoomen, Space- of middelklik-slepen om te pannen, 0/1/+/−-toetsen en een Fit/%-HUD). Op mobiel (≤640px) worden de bedieningselementen een bovenaan verankerd sheet met een sleepgreep die peek/half/full vastklikt (tikken schakelt), boven een statische fullscreen preview, en een zwevende Render-knop opent de Export-bediening in een bottom-sheet popup. Touch krijgt pinch-zoom en sleep-pan op de preview. Het renderpad en de exportbediening zijn identiek in beide gevallen - alleen de chrome herschikt zich.

signed by Lolly2026-10-21vector SVG131 paths~6.1k nodes158 groups1 image142 KBControleer het zelfDownload het ondertekende bestand

Dezelfde tool op telefoonbreedte, zonder tweede layout om te onderhouden: de bediening wordt een sheet bovenaan, de preview vult het hele scherm en de renderpil zweeft eroverheen.

signed by Lolly2026-10-21vector SVG97 paths~3.3k nodes113 groups99 KBControleer het zelfDownload het ondertekende bestand signed by Lolly2026-10-21vector SVG97 paths~3.3k nodes113 groups100 KBControleer het zelfDownload het ondertekende bestand

Batchmodus (/pro). De webshell levert ook een spreadsheet-achtig batchraster (shells/web/src/pro/) dat veel rijen tegelijk rendert over één of meerdere tools. Het doet CSV/TSV-round-trip plus spreadsheet-plakken, per-rij sjabloon/formaat/afmeting/eenheid/dpi, een blocks-editor zijpaneel met live preview, inklapbare exportkolommen, een per-rij "relevantie"-tagbalk, links een sleepgreep om rijen te herschikken, tweestaps verwijderbevestiging, opgeslagen batchsessies en een .zip-download. Dit is het one-to-many oppervlak achter de "massale contentgeneratie"-positionering.

Tauri desktop / mobiel

Verpakte native app (kleine footprint via Tauri). Biedt volledige offline beschikbaarheid, bestandssysteemtoegang voor CLI-afhankelijke tools (PDF Smasher, Font Outliner) en cameratoegang. Gepland voor tooling-verbetering medio 2026.

CLI

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

Desktopgebruikers kunnen veel tools vanaf de terminal aanroepen. De CLI-shell laadt dezelfde engine, maakt een jsdom-DOM aan, doorloopt hetzelfde renderpad en schrijft het bestand. URL-modus is het transport - CLI is geen aparte implementatie. Dit garandeert dat CLI- en GUI-output identiek zijn.

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

De interactieve tegenhanger van de CLI: een fullscreen, toetsenbord-eerst terminalapp (gebouwd op Ink) om tools te bladeren, invoer in te vullen, projecten op te slaan en te exporteren - allemaal zonder GUI. De hostbridge hergebruikt de implementatie van de CLI voor de DOM-vrije formaten (SVG/EMF/EPS/HTML + tekst/data), en voegt op-schijf status toe onder ~/.lolly plus een opt-in inline preview. Daarnaast heeft het een browser-rendertier: een scoped headless Chromium (dezelfde die de MCP-server installeert) die raster/PDF/video en live-URL-capture op aanvraag produceert - waarbij een gebouwde kopie van de webshell wordt aangestuurd zodat de output identiek is, en die alleen start wanneer je zo'n formaat voor het eerst exporteert. Zo draaien url-shot (met bijsnijden + herkleuren + vector-PDF/SVG) en elke raster/pdf-tool ook in de terminal. Zie de TUI-gids.

Op welk oppervlak je ook zit, het tabblad Capabilities van het dashboard is de volledige kaart van wat het platform verklaart te kunnen, gegroepeerd en leesbaar zonder ook maar één tool te openen.

Toolcategorieën

Tools worden in hun manifest getagd met een category voor groepering in de gallery.

Rijen staan in de volgorde van de gallerysecties. De sectie utility wordt altijd als laatste in de gallery weergegeven (na elke andere categorie, ook toekomstige) - dit is de on-device lade "Offline Utilities".

Die cellen zijn voorbeelden, geen inventarissen. Welke tools bestaan is een eigenschap van het profiel dat je hebt gemount, niet van deze pagina: een brandpack voegt zijn eigen tools toe en kan een communitytool uitsluiten die het liever niet meelevert. catalog/tools/index.json - gegenereerd uit de manifests, en het register dat de gallery daadwerkelijk leest - is de gezaghebbende lijst; om te tellen wat een profiel mount, tel je de manifests (ls community//tool.json brands//tools/*/tool.json) in plaats van te vertrouwen op een getal dat hier is opgeschreven. (Een tool-id dat in twee packs voorkomt, wordt eenmaal gemount, vanuit het winnende pack.)

Tools worden ook geclassificeerd naar status: official (goedgekeurd door het merk, geen watermerk), community (externe bijdrage), experimental (exports met watermerk). Het grootste deel van de bibliotheek is official; de nieuwere studio's en de capture-tools staan doorgaans op community of experimental terwijl ze zich settelen. Elk oppervlak toont de badge, zodat een lezer weet wat hij oppikt voordat hij het opent - en, net als de categoriecellen hierboven, verandert het lidmaatschap per status te snel om hier op te sommen. Lees het af van de gallery of de gegenereerde index.

Design is de eerste tool die is gebouwd op de vrije-canvasmodus render.layout: "editor" - een chromeloos oppervlak voor directe manipulatie waarop je vakken met tekst, vormen en afbeeldingen sleept, formaat wijzigt, roteert en uitlijnt, om vervolgens via hetzelfde renderpad als elke andere tool te exporteren.

Strip Hidden Data is de eerste on-device utility (privacy: "on-device"): een content-transformatietool die een bestand verwerkt dat jij aanlevert, volledig in de browser, en een schone kopie teruggeeft - nooit geüpload, nooit van watermerk voorzien, geen herkomst gestempeld. Text is de tweede - een on-device werkbank voor alledaagse plak-in-een-website-taken (JSON-formattering, JWT-decodering, Base64, URL-encoderen/decoderen, SHA-hashing). Compress PDF is de derde - het verkleint een PDF door de afbeeldingen erin opnieuw te comprimeren, ook weer volledig on-device. De markering en de badgetekst "Draait op jouw apparaat - er wordt niets geüpload" dekken nu de hele transformatieset: Strip Hidden Data, Text, Compress PDF, Convert Image (HEIC/TIFF/AVIF → WebP/JPG/PNG), Convert Font, Redact (delen van een afbeelding, SVG of PDF vernietigen), Prompt Card en Rebrand (een .pptx ter plekke van thema wisselen) waar het profiel deze meelevert. Dit is een privacy-utilitycategorie die vervangt dat vertrouwelijke bestanden naar single-purpose websites worden gestuurd.

signed by Lolly2026-10-21vector SVG124 paths~29k nodes324 groups395 KBControleer het zelfDownload het ondertekende bestand signed by Lolly2026-10-21vector SVG124 paths~29k nodes324 groups396 KBControleer het zelfDownload het ondertekende bestand

Opmerking: category en status worden gedenormaliseerd in catalog/tools/index.json (het register dat de gallery leest) vanuit elke tool.json. Het manifest is de bron van waarheid - de index wordt gegenereerd door pnpm run build:catalog en pnpm run validate:catalog faalt in CI als de gecommitte index afwijkt van de manifesten.

Architecturale toezeggingen

Deze beslissingen staan vast. Elke wijziging hierin is een grote onderneming - ze bepalen elke andere beslissing in de codebase.

1. Declaratieve tools, met een imperatief ontsnappingsluik

Een tool is een manifest (tool.json) + een template (template.html) + optionele hooks.js.

Het manifest declareert de inputs. Niet het template. Inputs worden niet afgeleid uit Handlebars-tokens. Het manifest is het contract; het template gebruikt benoemde variabelen via {{id}}.

signed by Lolly2026-10-21vector SVG39 paths~2.6k nodes54 groups2 images43 KBControleer het zelfDownload het ondertekende bestand signed by Lolly2026-10-21vector SVG39 paths~2.6k nodes54 groups2 images43 KBControleer het zelfDownload het ondertekende bestand

Hooks zijn optioneel. De meeste tools zijn zuiver declaratief - manifest + template is genoeg. Tools die berekende waarden nodig hebben (QR-codering, vormgeving van chartdata) leveren hooks.js met benoemde levenscyclusfuncties (onInit, onInput, onFrame - de per-frame live-camerahook voor bewegingsreactieve tools - onLevel, beforeExport, afterExport, exportFile - het file-in/file-out-transformatiepad dat on-device utilities zoals Strip Hidden Data gebruiken - en exportStill, voor een tool die zijn eigen deep raster beheert). De host laadt hooks via new Function('host', …) waarbij de capability bridge als closure-scope wordt geïnjecteerd. Dit is een portabiliteitscontract, geen beveiligingssandbox: hooks draaien nog steeds in het page realm en kunnen in een browsershell bij window/fetch/document - host. is het ondersteunde, portable oppervlak, geen afgedwongen grens. Asynchrone hookresultaten zijn tijdgebonden (onInit 5s, onInput 2s, beforeExport/afterExport 5s, exportFile/exportStill 10s) en late resultaten worden verworpen; een op hol geslagen synchrone* hook kan niet worden onderbroken. Onvertrouwde hookcode van derden is daarom niet veilig om uit te voeren totdat Worker-isolatie er is.

Dit is van belang omdat: declaratieve tools door niet-ontwikkelaars kunnen worden geschreven. Als elke tool een webapp zou zijn, wordt de risico-opmerking "beperkte vaardigheden om workhorse-templates te maken/onderhouden" een permanent knelpunt.

2. Tools en assets zijn data, geen gebundelde code

De web- en Tauri-apps halen tool- en assetcatalogi bij het opstarten op van een bekende URL, cachen ze lokaal en werken met wat daar staat. Het toevoegen van een nieuwe eventtegel of seizoensasset vereist geen app-release.

Assetbytes krijgen een SHA-256-checksum om CDN-poisoning te voorkomen. Asset-id + version stuurt cache-invalidatie aan.

3. De Capability Bridge is de enige API die tools zien

Tools raken nooit de DOM buiten hun templategebied aan, roepen nooit rechtstreeks fetch aan en lezen nooit het bestandssysteem. Ze roepen geversioneerde host.*-methoden aan. De canonieke definitie van het contract is packages/core/src/host-v1.ts - de tool-author-SDK @lolly-tools/core, zodat een derde partij ertegen kan bouwen zonder van de engine af te hangen; engine/src/bridge/host-v1.ts is daar een type-re-export van, en engine-/shellcode blijft ongewijzigd vanaf dat pad importeren:

Optionele, additieve oppervlakken verschijnen alleen wanneer een shell ze levert. Sommige zijn capability-gated - alleen beschikbaar wanneer de tool de bijbehorende flag declareert: host.compose (de render van een andere tool insluiten - compose), host.capture (paginacapture voor URL Screenshot - capture) en host.recorder (mic-/camera-/schermcapture voor de opnametools - microphone / camera / screen). De rest is feature-detected - aanwezig zodra de shell ze kan leveren, waarbij de tool een fallback behoudt voor shells die dat niet kunnen.

Een handvol kernoppervlakken, om te laten zien wat het bestrijkt - Host API documenteert ze allemaal, en packages/core/src/host-v1.ts is het contract zelf:

De rest volgt dezelfde regels en is er samen mee gedocumenteerd: pdf (1.8) en pptx (1.58) voor on-device documentchirurgie, audio (1.71) en speech (1.96) voor clipanalyse en on-device TTS/transcriptie, viz (1.72) voor het MilkDrop-placeholdercontract, codec (1.100) en layers (1.102) voor deep-bit- en layered-bitmap-output, upscale (1.101) en matte (1.103) voor de on-device modellen, raster (1.105) voor hooks die hun eigen pixelwerk doen, connectors (1.106) voor exportveilige pijlen en c2pa (1.85) voor het ondertekenen van afgeronde bytes. Het aantal groeit; de regels niet.

De declareerbare capabilities zijn: network, filesystem, clipboard, camera, microphone, screen, ffmpeg, wasm, capture, compose. (screen, toegevoegd in 1.54, is schermcapture via host.recorder - de gebruiker kiest een scherm/venster/tabblad in de browsereigen UI; dit is anders dan capture, dat een URL rasteriseert die de tool zelf noemt.)

Dezelfde tool draait in browser, Tauri en headless CLI omdat elke shell deze interface implementeert - de tool weet nooit in welke hij zit.

De bridge is geversioneerd. Het toevoegen van methoden is een minor version. Het verwijderen of wijzigen van signatures is een major version bump. Wanneer v2 uitkomt, moet v1 blijven werken.

4. Asset-ID's zijn voor altijd

suse/logo/primary is een contract. Eenmaal gepubliceerd:

• De ID verandert nooit, wordt nooit hergebruikt.
• Bytewijzigingen → verhoog version in het manifest.
• Vervangen door een nieuwe asset → zet deprecated: true en optioneel replacedBy.
• Bestaande referenties worden altijd opgelost.

Dit maakt opgeslagen tool-states en via URL gedeelde links jarenlang duurzaam.

5. URL-modus is first-class

Elke input moet uitdrukbaar zijn als een URL-parameter:

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

signed by Lolly2026-10-23vector SVG55 paths~2.6k nodes38 groups60 KBControleer het zelfDownload het ondertekende bestand signed by Lolly2026-10-23vector SVG55 paths~2.6k nodes38 groups61 KBControleer het zelfDownload het ondertekende bestand

CLI-modus is URL-modus onder een ander transport - de CLI-shell bouwt een URL-state-object op uit argv en draait dezelfde engine-pipeline. Er is één renderpad. De CLI kan niet afwijken van de GUI omdat het geen aparte implementatie is.

url-mode.ts verzorgt de round-trip (parsen en serialiseren). Een set gereserveerde parameters wordt nooit als inputs aan de tool doorgegeven: de outputbedieningen (format, export, copy, filename, width/w, height/h, unit, dpi), de print- en herkomstknoppen (bleed, marks, profile, password, c2pa, imprint, durable, meta, hdr, depth, cuts) en de state-dragers (template, z - het gepakte token voor "Shortest link" - en zx, hetzelfde maar versleuteld met een wachtwoord). De set RESERVED in engine/src/url-mode.ts is gezaghebbend en wordt door een test vastgepind; URL Mode documenteert ze allemaal, inclusief de handvol die hier niet staat vermeld. Asset-inputs in URL-modus worden geserialiseerd via hun id; de runtime lost ze op via host.assets.get() voordat hydratie plaatsvindt. width/height zijn waarden in unit (standaard px, ook mm/cm/in/pt/pc); bij een fysieke eenheid stelt dpi de rasterresolutie in. Ze bepalen het canvasdocumentformaat en vullen het exportafmetingenpaneel vooraf in.

Omdat elke input meereist in de link, is een parameterwijziging een andere afgeronde asset. Dit hele palet is één basiskleur, een harmonie en een stapaantal:

signed by Lolly2026-10-21vector SVG10 groups25 KBControleer het zelfDownload het ondertekende bestand signed by Lolly2026-10-21vector SVG10 groups25 KBControleer het zelfDownload het ondertekende bestand

6. Opslag loopt via de bridge, niet rechtstreeks

Web shell: IndexedDB. Tauri: bestandssysteem. CLI: in-memory. Tools zien alleen host.state.save(slot, data) en host.state.load(slot). localStorage wordt niet gebruikt - het is te klein en kan geen blobs bevatten.

Gebruikers kunnen meerdere genoemde bewerkingsslots per tool opslaan en later naar elke sessie terugkeren. Er is geen accountaanmaak nodig; status is per apparaat. Omdat de bridge de enige naad is, is die status per apparaat ook draagbaar: shells/web/src/data-transfer.ts leest alles terug via host.profile/host.state/host.assets in één lolly-backup-zip die op elke andere installatie importeert - het offline antwoord op "verhuizen naar een nieuw apparaat" waar geen server voor nodig is (volledige specificatie: docs/data-transfer.md). Synchronisatie tussen meerdere apparaten draait hier al bovenop, door dezelfde bundel te sturen naar de opslag die de persoon kiest (docs/sync.md).

7. Volwassenheidslabels tonen wat een tool is

Elke tool declareert status: official | community | experimental in zijn manifest. De galerij sorteert op status. Experimentele tools voorzien hun exports automatisch van een watermerk - het watermerk wordt toegepast door host.export.render, niet door de tool, dus een niet-officiële tool-auteur kan er niet voor uitschakelen.

Dit is een structureel antwoord op het perceptierisico dat elke tool in de gallery evenveel gewicht draagt. Welk proces een team ook rond de catalogus legt, dat zit er bovenop.

8. Tool-invoer is getypeerd via het manifest, inclusief assets

Invoervelden declareren een type: text, longtext, number, boolean, color, select, asset, date, time, datetime-local, url, blocks, vector, table en file. De host rendert een generieke besturing per type vanuit het manifest - tools schrijven nul regels besturingscode. (Vooraf invullen vanuit het profiel van de gebruiker is geen type - elke invoer kan bindToProfile dragen.) Drie wegen zwaarder dan de rest:

• asset (met filter en allowUpload) is de brug naar het globale assetsysteem; allowUpload: false is de hendel voor merkhandhaving voor dingen zoals sponsortegellogo's waar alleen bibliotheekassets toegestaan zijn. Gebruikersuploads gebruiken dezelfde AssetRef-vorm als bibliotheekassets, dus tools behandelen ze identiek.
• blocks is een herhalende veldgroep - een minitabel binnen één invoerveld, bewerkt in een zijpaneel, met een getypeerd/onderscheiden toevoegmenu en assetvelden per blok. Klikken op een gerenderd blok op het canvas focust de rij van dat blok. Gebruikt door meeting-planner, chart-creator, event-name-badge, wayfinding-signage, color-block en digi-ad.
• vector groepeert een vaste set getallen (bijvoorbeeld een transform) in één samengestelde besturing; file houdt het eigen bestand van de gebruiker als bytes in het geheugen voor on-device transformatie-utilities (bijvoorbeeld strip-data en compress-pdf).

9. Templates zijn logicaloos (Handlebars, geen EJS)

Handlebars is bewust boven EJS gekozen:

• Logicaloos. Templates kunnen door niet-developers worden opgesteld.
• Standaard veilig. {{x}} escapet HTML; {{{x}}} is optioneel rauw.
• Geen willekeurige JS in templates betekent geen XSS-auditoppervlak per template.

Logica leeft in hooks.js, waar die expliciet en beoordeelbaar is. Beschikbare Handlebars-helpers: {{default}}, {{upper}}, {{lower}}, {{eq}}, {{markdown}}, {{asset ref}}, {{asset ref "property"}} (plus dataformaathelpers icsStamp/rfcText/csvCell gebruikt door de bijbehorende .ics/.vcf/.csv-templates).

10. Tools stellen tools samen

Een tool kan de render van een andere tool embedden zonder tool-naar-tool imports - samenstelling wordt opgelost door de engine, nooit door tool-code. Er zijn twee oppervlakken:

• Declaratief manifest - composes: [{ id, tool, inputs, format?, width?, height? }]. De engine rendert het genoemde kind en plaatst het resultaat in de logicaloze template als {{asset <id>}}. event-name-badge stelt vandaag qr-code samen als SVG.
• Overdraagbare embed-URL - <img src="https://lolly.tools/tool/<id>.<ext>?<inputs>">. De shell rendert dat kind lokaal (een placeholderpixel toont zich tot de lokale render klaar is); er wordt nooit iets opgehaald bij lolly.tools.

Stel de render van elke tool samen: een SVG-kind blijft een echte vector wanneer het bovenliggende item naar SVG of PDF exporteert en rasteriseert scherp voor PNG; PNG/JPG/WEBP-kinderen worden als afbeeldingen ingesloten. Vereist de compose-capability. Samengestelde kinderen zijn tussenproducten - nooit voorzien van watermerk of herkomststempel - en samenstelling degradeert gracieus: een shell die een kind niet kan renderen laat de slot gewoon weg en het bovenliggende item rendert alsnog.

Wat we expliciet niet deden

• Geen EJS / geen willekeurige JS in templates. Het XSS-oppervlak is nul. Logica leeft in hooks.js.
• Geen verplicht asset-CMS. Individuen halen hun eigen creatieve bestanden rechtstreeks in de app binnen in Assets (Assets en de Brand Studio) - geen server, geen beheerconsole. Werk wordt doorgegeven als een sessie: een deellink draagt zijn invoer en instellingen mee (geüploade bestanden reizen mee in een .lolly), en dezelfde sessie reist mee in een back-up of via een samenwerkingssessie. Wie de deployment beheert, kan een gedeelde sessie dan vastzetten als een template - open de link, leg de waarden ervan vast als een template-item in de map van die tool in het brand pack, en commit - waarna het verschijnt in de "New from template"-kiezer van de tool en deep-linkbaar is als ?template=<id>. Git is de vastzetstap van de deploymenteigenaar, nooit die van de maker. Voor een gedeelde, gereguleerde catalogus kan een organisatie de assetmap op dezelfde manier beheren en updates laten verlopen via PR-review - een beschikbaar governancemodel, geen vereiste van de app.
• Geen opgelegde RBAC. De open app is standaard vrij toegankelijk; merkrisico wordt beheerd met volwassenheidslabels + watermerken. Een organisatie die strakkere controle wil, legt haar eigen authenticatie en de git-beoordeelde catalogus hierboven erop.
• Geen centrale database. Alle gebruikersstatus is per apparaat; de optionele synchronisatie kopieert die naar de opslag die de persoon kiest, nooit naar een Lolly-database.
• Geen gedeeld tools-/engine-codepad. De engine is open source, en dat zijn ook de merkonafhankelijke tools in community/; een brand pack zoals het private brands/suse/ draagt zijn eigen tools en catalogus onder zijn eigen voorwaarden. Hoe dan ook wordt de scheiding afgedwongen (geen cross-imports van engine/ naar toolinhoud), zodat de splitsing schoon blijft.

De levenscyclus van één render

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

1. Boot. De webshell opent IndexedDB, bouwt de capability bridge en synchroniseert de tool- en assetcatalogi (of laadt vanuit cache wanneer offline).
2. Route. URL-hash → tool-view, waarbij qr-code en URL-parameters worden geëxtraheerd.
3. Load. loadTool('qr-code', fetchFile) haalt tool.json op, valideert tegen het JSON Schema, en haalt de bronbestanden template.html, styles.css en hooks.js op.
4. Parse URL state. parseUrlState zet URL-parameters om in initiële inputwaarden. Assetreferenties (?logo=suse/logo/primary) worden geparsed als lichte { id, _unresolved: true }-objecten.
5. Runtime. createRuntime(tool, host, initialValues) bouwt het inputmodel (door profielgegevens, standaardwaarden en initiële waarden samen te voegen), lost assetreferenties op via host.assets.get(), laadt hooks (host in closure-scope, niet gesandboxed), en roept hooks.onInit aan.
6. Render. De shell abonneert zich op de runtime; bij elke statuswijziging ontvangt hij { model, hydrated }. Hij rendert inputbedieningselementen op basis van het model en schrijft de gehydrateerde template-HTML naar #tool-canvas.
7. Interact. De gebruiker typt in een invoerveld → runtime.setInput(id, value) → beperkingen worden toegepast → hooks.onInput wordt aangeroepen → opnieuw hydrateren → opnieuw renderen. Het canvas wordt live bijgewerkt.
8. Export. De gebruiker klikt op Download (PNG) → runtime.export(canvasNode, 'png') → host.export.render (rasteriseert via dom-to-image-more; SVG/PDF gaan via speciale DOM-doorlopende vectorisers) → blob → host.export.download. Het formaatbereik waarvoor een tool kan kiezen is breed, en de render.formats-enum in schemas/tool.schema.json is daarin gezaghebbend - rasters en float-rasters, vectoren en snijbestanden, print/CMYK, motion, bewerkbare documenten (pptx, docx, odt), paletten en data-/tekstuitvoer, audio- en lettertypebestanden. URL Mode noemt elke id en wat deze oplevert. Audio staat net als al het andere in die enum (wav, mp3, m4a, opus, gedeclareerd door de audiogram- en opnametools); daarnaast stuurt de render.capture-modus van een opnametool host.recorder aan, waarvan de opname aankomt als een afgeronde Blob in welke container de browser ook heeft opgenomen. (Tools die render.export: false instellen - bijvoorbeeld Color Palette, Countdown Timer, Strip Hidden Data, Text, Compress PDF - verbergen de download-/formaat-/afmetingbedieningen.) Fysieke eenheden worden hier per formaat omgerekend (PDF → echte paginapunten, raster → pixels bij DPI met een pHYs-chunk). Auteurschaps-/herkomstmetadata (auteur, tool, bron - opgebouwd door engine/src/metadata.ts) wordt per formaat ingebed: PNG iTXt, JPEG EXIF, PDF info dict, SVG <metadata>, GIF-commentaar. Experimentele tools krijgen een watermerk ingevoegd door de host, niet door de tool.

signed by Lolly2026-10-21vector SVG77 paths~6.0k nodes87 groups3 images88 KBControleer het zelfDownload het ondertekende bestand signed by Lolly2026-10-21vector SVG77 paths~6.0k nodes87 groups3 images88 KBControleer het zelfDownload het ondertekende bestand

Zelfde levenscyclus in Tauri. Zelfde levenscyclus in CLI - jsdom levert de headless DOM; de uitvoer gaat naar een bestand of stdout.

Opensourcestatus

Code is MPL-2.0. engine/, shells/, services/, schemas/ en docs/*.ts zijn open source onder MPL-2.0 - een vendor-neutraal scaffoldingplatform voor brandtooling, allemaal in één publieke repository, lolly-tools/lolly.

Toolcontent wordt uitgeleverd als brand packs, elk met eigen voorwaarden (zie het NOTICE.md-bestand van het pakket). community/ is een map van deze repository en de merkonafhankelijke tools daarin zijn ook MPL-2.0. brands/suse/ is het private suse-lolly-pakket, de enige submodule: de SUSE-tools en de SUSE-catalogus, eigendom van SUSE, inclusief de gelicentieerde PremiumBeat-muziek. brands/lolly-start/ is het lege startmerk dat deze repository zelf bezit. Lettertypen worden binnen een pakket uitgeleverd onder de SIL Open Font License 1.1 - het SUSE-pakket bevat de SUSE- en SUSE Mono-lettertypen.

Er is geen tools/- of catalog/-map op de repo-root. packages/node-shell/src/content-roots.ts beantwoordt "waar leeft tool <id>" en "waar is de catalogus" op basis van profiles.json op het moment van lezen, zodat een profiel een per-proces antwoord is en er niet eerst een boomstructuur hoeft te worden opgebouwd. Een echt tools/ + catalog/-paar wordt alleen weggeschreven in een build-output - dist/, een RPM-payload, een containerimage - omdat een browser die twee paden via HTTP ophaalt.

De scheiding wordt afgedwongen - er zijn geen cross-imports vanuit engine/ naar toolcontent - zodat de grens tussen platform en content schoon blijft.

Waar de engine eindigt en de host begint

Als je het kunt beschrijven in pure data + Handlebars → engine. Als het de DOM, het bestandssysteem, het netwerk of een browser-/OS-API raakt → host.

De lijn is bewust scherp. De engine is het opensource-deel. Alles wat iets weet over SUSE, specifieke platforms of runtime-omgevingen blijft eruit.

Voor het volgende detailniveau somt engine/README.md elke enginemodule op en waar die verantwoordelijk voor is, en Dreigingsmodel & vertrouwensgrenzen legt vast waar diezelfde lijn tevens een vertrouwensgrens is.