Общ преглед

Този документ описва предназначението, структурата и архитектурните решения за платформата Lolly. Той отразява както визията за продукта, така и текущото състояние на кодовата база.

Статус: Lolly е вътрешен прототип в затворен пилот, който все още не е завършен. Двигателят е детерминиран и вътрешно съгласуван, но продуктът е в ранен етап - SUSE е клиент номер едно - и неговите криптографски и файлово-парсиращи двигатели в момента преминават през строгото инфраструктурно закаляване на SUSE, подготвяйки се за корпоративен мащаб (в това сме наистина добри). Чети архитектурата по-долу като проектно намерение в процес на тестване, а не като завършен, сертифициран продукт. Виж Приемане и управление за това как се провежда и измерва пилотът.

Как да четеш тази страница. Тя съдържа два вида материал, по ред. Първата половина е защо това съществува: проблемът, позиционирането и жизненият цикъл, през който преминава един актив. От Голямата картина нататък е как пасват слоевете: архитектурният документ за контрибутори, обхващащ разделянето engine/shell/pack, оформлението на хранилището, целите за доставка и ангажиментите, които ограничават всяка промяна в платформата. Ако си тук, за да промениш кодовата база, а не за да разбереш продукта, започни от голямата картина.

Два придружаващи документа навлизат по-надълбоко от тази страница. engine/README.md в хранилището е картата на двигателя модул по модул, с генерирана таблица за всеки модул и какво парсва или записва той. Модел на заплахите и граници на доверие е същата архитектура, прочетена като граници на доверие, и е правилната страница за всеки въпрос за това какво двигателят третира като недоверено.

Защо това съществува

Екипите се сблъскват с повтарящ се проблем: повтаряща се творческа и съдържателна работа, която е прекалено предвидима, за да оправдава ангажирането на опитни ръце всеки път, но прекалено чувствителна към качество, за да бъде прехвърлена без предпазни огради. Резултатът е или бавна пропускателна способност (тясно място около специалиста), или непоследователност (хора, които използват какъвто инструмент имат под ръка), или обвързаност с доставчик (SaaS DAM, който контролира шаблоните ти).

Тази платформа е прекият отговор на това:

Програмно творчество и съдържание в мащаб - генериране на активи без ръчен труд, с правила под централен контрол, за служители, доставчици и партньори.

Lolly не е мястото, където се изобретява дизайн система - той е мястото, където тя се произвежда. Мисли за него като за автомат за дизайн: правиш избор, получаваш резултат. Всеки път. Енджинът се стреми към най-високото качество, което всеки формат може да произведе на хардуера пред теб, и същият енджин прави същия файл на всяка платформа, на която се доставя.

Резултатът е изобилие: всяко събитие има правилни табели, всяко CVE предупреждение съответства на фирмения стил, всеки етикет се отпечатва чисто, всеки имейл подпис е актуален - всичко това без дизайнерска заявка. Платформата обработва повтарящото се, операционализирано творчество. Тя умишлено не е инструмент за индивидуален творчески дизайн - дизайнерите продължават да притежават флагманската работа.

Иновирай вероятностно, мащабирай детерминирано

Всеки спор за изкуствения интелект в творческия процес се заковава на един и същ въпрос: коя част от това е работа на машината? Това е стар въпрос с установен отговор. Писарите и илюминаторите отдавна са работили с два инструмента - свободната скица, където нищо не е фиксирано и всичко може да се пробва, и печатната преса, плашеща именно защото се обвързва. Скиците бяха мястото, където се раждаше изкуството. Пресата беше начинът, по който то достигаше до всеки. Никой не бъркаше двете, и двете продължаваха да напредват - нови мастила, нови шрифтове, нови преси - всяко подобрение вървеше в хармония с занаята и намерението, на което служеше.

Lolly прокарва същата линия. Изследвай вероятностно: модел, дизайнер, груба идея, промпт, който отива някъде, което никой не е планирал. После мащабирай детерминирано - това, което достига десет хиляди изхода, е инструмент, а инструментът се рендира по един и същ начин всеки път от входове, които можеш да прочетеш. Изследването остава свободно, защото нищо надолу по веригата не зависи от това дали ще се получи еднакво два пъти. Резултатът печели доверие, защото не е предположение. Превръщането на експериментирането с изкуствен интелект в предвидими, възпроизводими резултати не е нова дисциплина; това е същото разделение на труда, което направи печатната работа достойна за доверие още от самото начало.

Довери се на творческия процес, мащабирай с точност.

Спрямо алтернативите

Разликата е ясна: нищо, което се предлага днес, не ни дава изход, ориентиран първо към ограниченията, способен да работи офлайн, с ниски изисквания за умения и вътрешно достъпен. Lolly дори включва отворено платно - Design - където цветовете, шрифтовете и активите се съобразяват с глобалните настройки на марката, така че свободното подреждане остава ориентирано първо към ограниченията. Това, което не е, е неограничен дизайнерски пакет: дизайнерите продължават да използват Illustrator и Figma за индивидуална флагманска работа. Пермутации могат да бъдат съставени с този инструмент.

signed by Lollyvector SVG2026-08-24Провери самGet the signed file281 paths~38k nodes443 groups6 images2269 KBsigned by Lollyvector SVG2026-08-24Провери самGet the signed file281 paths~38k nodes443 groups6 images2270 KB

Използвай го за: Бързо генериране на операционализирани творчески активи - плочки за събития, баджове с имена, подписи, CVE предупреждения, QR кодове, социални карти, етикети за пратки, структурирани отчети.

Не го използвай за: Индивидуално флагманско съдържание.

Жизненият цикъл на една кампания

Най-ясният начин да видиш какво е Lolly не е списък с функции - а да проследиш един-единствен актив, докато минава от ръка на ръка. Наблюдавай как една локализирана карта за кампания преминава през организацията:

1. Творецът задава правилата. Дизайнер създава базовия шаблон в инструмента Design, вграждайки типографията и цветовите променливи на марката. Той не прави една карта - върши основната работа веднъж, за да не му се налага никога повече да я локализира ръчно.
2. Разработчикът я мащабира. Същият шаблон е включен в нощен процес чрез CLI, така че нова диаграма или нов езиков вариант се генерира автоматично - никой дизайнер не отваря отново файла.
3. Продуцентът просто го използва. Търговски представител, офлайн в самолет, отваря същия инструмент и генерира перфектно съобразена с марката презентация за среща с клиент. Без дизайнерски умения, без мрежа, без чакане.

„Новата диаграма" в стъпка две е рендиране като това тук, произведено от низ с данни и шепа параметри, без никой да отваря дизайнерски файл:

signed by Lollyvector SVG2026-08-24Провери самGet the signed file15 paths~1.3k nodes4 groups21 KBsigned by Lollyvector SVG2026-08-24Провери самGet the signed file15 paths~1.3k nodes4 groups21 KB

Смисълът не е, че Lolly е добър за дизайнери и добър за разработчици и добър за продажби, всеки във вакуум. Това е щафета: първоначалната работа на твореца се мащабира от разработчика, което на свой ред дава сила на продуцента. Безусилното изживяване за нетехническия представител в самолета е възможно само благодарение на точността, зададена от дизайнера и внедрена от разработчика.

Това е умножителят на сила. Lolly не е чекмедже с отделни инструменти за отделни роли - това е един детерминиран жизнен цикъл на активи, до който се докосва всяка роля, и всяка ръка, през която преминава, умножава стойността на предишната.

Едно одобрение, десет хиляди активи

Тъй като одобрението живее в инструмента, а не във файла (виж Как се сравнява Lolly), мащабът престава да е проблем на прегледа. Одобри инструмент за локализирана социална карта веднъж и после генерирай 10 000 активa на 12 езика от таблица - и нито един от тях не се нуждае от нова проверка за съответствие от правния отдел или марката, защото шаблонът, от който идват всички, вече е одобрен.

Един и същ детерминиран инструмент достига този мащаб по три начина, всички произвеждащи идентичен, предварително одобрен резултат:

• Човек, в приложението. Партидната мрежа /pro: постави или импортирай редовете, получи по един готов актив на ред, изтегли zip файла. Без дизайнерски умения, без заявка, без чакане.
• Разработчик, от командния ред. CLI пуска същия двигател и същия път на рендиране без графичен интерфейс, така че инструментът може да бъде последователно приложен върху всички 10 000 реда в скрипт или нощен процес. Извикване lolly <tool> --field=… в цикъл е цялата интеграция.
• Система или AI агент, чрез MCP. Същият инструмент, управляван програмно, със същата точност и дори по-голям мащаб - защото машината не се уморява, докато хиляди файлове се обработват.

signed by Lollyvector SVG2026-08-24Провери самGet the signed file348 paths~77k nodes537 groups7 images3100 KBsigned by Lollyvector SVG2026-08-24Провери самGet the signed file348 paths~77k nodes544 groups7 images3103 KB

Един набор от ограничения на марката, зададен веднъж от дизайнер; три пътя до идентичния предварително одобрен резултат - и машинният път се мащабира най-далеч от всички, защото никога не се уморява, докато файловете се обработват.

Голямата картина: как пасват слоевете

Всичко оттук нататък е архитектура. Диаграмата е цялата система в един изглед: инструментите са данни най-отгоре, двигателят по средата не знае нищо за никоя платформа, обвивките под него имплементират един договор, а каталозите доставят съдържанието.

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

Оформление на хранилището

Съдържанието е монтирано като пакети: community/, docs/, всеки shells/, двата services/ и brands/suse са всеки свое собствено хранилище, изтеглени като git подмодули на това. Родителят притежава engine/, schemas/, scripts/, tests/, api/, brands/lolly-start/ и profiles.json. Виж Ръководство за build » Получаване на кода за командата за изтегляне и работния процес между хранилищата.

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
│
├── tools/            # profile VIEW (gitignored) - data, not code. Merged from packs:
│                     #   community/ (public, brand-agnostic, MPL) + brands/<active>/tools (brand-owned).
│                     #   A SELECTION follows - the mounted set depends on the profile.
│   ├── qr-code/
│   ├── quotes/
│   ├── email-signature/
│   ├── snippet/
│   ├── countdown-timer/
│   ├── color-palette/
│   ├── color-block/           # typed/heterogeneous blocks (addMenu discriminator)
│   ├── dynamic-layout/
│   ├── tool-logo/         # "Logo" - auto-switching brand logo
│   ├── 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)
│   ├── brand-lockup/      # "Brand Lockup" - SUSE logo lockups; HarfBuzz text-to-path (wasm)
│   ├── chart-creator/     # 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
│   ├── digi-ad/           # "Animated Ad" - looping banner from scenes
│   ├── event-name-badge/  # conference badges - composes qr-code as an SVG
│   ├── 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
│   ├── logo-lockup-partner/ # SUSE + partner co-brand lockup
│   ├── icon/          # favicon .ico / png / svg from text + colours
│   ├── lottie-digi-ad/    # animated Lottie ad banners
│   └── pose-geeko/        # pose the SUSE Geeko mascot - print-ready stills
│
├── catalog/
│   ├── tools/index.json        # tool registry
│   └── assets/
│       ├── index.json          # asset registry
│       └── suse/...            # logo, palette, etc.
│
├── 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

Модел на доставка на платформата

Платформата работи на няколко повърхности - уеб PWA, Tauri настолна/мобилна версия, скриптируемия CLI и интерактивния TUI. Всички те използват един и същ двигател и едни и същи файлове с инструменти.

Уеб (PWA) - основно разпространение

Хостван на URL, контролиран от SUSE. Работи офлайн, след като service worker-ът е кеширал инструментите и активите. Тук повечето служители, доставчици и партньори ще използват платформата. Не се изисква акаунт - състоянието се съхранява в IndexedDB на всяко устройство.

Уеб обвивката е адаптивна от едно единствено оформление. На настолен компютър инструментът е странична лента с контроли с променлив размер до сцена за преглед с навигация на платното, родна за тракпад (Cmd/Ctrl-колело или щипване за мащабиране около курсора, Space- или средно провлачване за преместване, клавиши 0/1/+/− и HUD за Fit/%). На мобилно устройство (≤640px) контролите стават лист, закачен отгоре, с плъзгаща дръжка, която прещраква между peek/half/full (докосването превключва) над статичен преглед на цял екран, а плаващ бутон Render отваря контролите за Export в изскачащ лист отдолу. Докосването получава щипване за мащаб и провлачване за преместване върху прегледа. Пътят на рендиране и контролите за експортиране са идентични и в двата случая - само хромът се преподрежда.

signed by Lollyvector SVG2026-08-24Провери самGet the signed file5 paths989 nodes11 groups14 KBsigned by Lollyvector SVG2026-08-24Провери самGet the signed file5 paths989 nodes11 groups14 KB

Същият инструмент при ширина на телефон, без втори layout за поддръжка: контролите стават лист в горната част, прегледът заема целия екран, а хапчето за рендиране плава над него.

signed by Lollyvector SVG2026-08-23Провери самGet the signed file47 paths~1.9k nodes84 groups1 image212 KBsigned by Lollyvector SVG2026-08-23Провери самGet the signed file47 paths~1.9k nodes84 groups1 image211 KB

Режим Batch (/pro). Уеб обвивката предлага и таблична batch мрежа (shells/web/src/pro/), която рендира много редове наведнъж през един или няколко инструмента. Тя поддържа кръгова обработка на CSV/TSV плюс поставяне от таблица, шаблон/формат/размер/мерна единица/dpi за всеки ред, страничен панел с редактор на блокове с преглед на живо, свиваеми колони за експорт, лента с етикети „relevance“ за всеки ред, преподреждане на редове чрез плъзгане с ляв манипулатор, двустъпково потвърждение за изтриване, запазени batch сесии и изтегляне на .zip. Това е повърхността „едно към много“ зад позиционирането „масово генериране на съдържание“.

Tauri desktop / mobile

Опакован нативен app (малък отпечатък чрез Tauri). Осигурява пълна офлайн наличност, достъп до файловата система за инструменти, зависими от CLI (PDF Smasher, Font Outliner), и достъп до камерата. Планирано подобрение на инструментите за средата на 2026.

CLI

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

Потребителите на десктоп могат да извикват много инструменти от терминала. CLI обвивката зарежда същия engine, създава jsdom DOM, изпълнява същия render път и записва файла. URL режимът е транспортът - CLI не е отделна реализация. Това гарантира, че изходите на CLI и GUI са идентични.

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

npm run tui

Интерактивният аналог на CLI: терминален app на цял екран, ориентиран към клавиатурата (изграден върху Ink), за преглед на инструменти, попълване на входове, запазване на проекти и експортиране - всичко без GUI. Неговият host bridge преизползва реализацията на CLI за форматите без DOM (SVG/EMF/EPS/HTML + текст/данни) и добавя състояние на диска под ~/.lolly плюс изричен вграден преглед. Освен това има ниво за рендиране в браузър: обхванат headless Chromium (същият, който MCP сървърът инсталира), който произвежда растер/PDF/видео и заснемане на живи URL адреси при поискване - задвижвайки изградено копие на уеб обвивката, така че изходът е идентичен, и стартиращ само при първия ви експорт в такъв формат. Така url-shot (с изрязване + прецветяване + векторен PDF/SVG) и всеки растер/pdf инструмент работят и в терминала. Вижте ръководството за TUI.

На каквато и повърхност да сте, разделът Capabilities в таблото е пълната карта на това, което платформата декларира, че може да прави, групирана и четлива без да отваряте нито един инструмент.

Категории инструменти

Инструментите се маркират с category в манифеста си за групиране в галерията.

Редовете са изброени в реда на секциите в галерията. Секцията utility винаги се рендира последна в галерията (след всяка друга категория, включително бъдещи) - това е локалното (on-device) чекмедже „Offline Utilities“.

Тези клетки са примери, не пълен опис. Кои инструменти съществуват е свойство на профила, който сте монтирали, не на тази страница: пакет с марка добавя свои собствени и може да изключи инструмент от общността, който не желае да разпространява. catalog/tools/index.json - генериран от манифестите и регистърът, който галерията реално чете - е авторитетният списък; за да преброите какво монтира даден профил, преброете манифестите (ls community//tool.json brands//tools/*/tool.json), вместо да се доверявате на число, записано тук. (Идентификатор на инструмент, присъстващ в два пакета, се монтира само веднъж, от печелившия пакет.)

Инструментите се класифицират и по статус: official (одобрен от марката, без воден знак), community (принос от общността), experimental (експортите носят воден знак). По-голямата част от библиотеката е official; по-новите студиа и инструментите за заснемане обикновено се намират в community или experimental, докато се стабилизират. Всяка повърхност показва баджа, така че читателят знае какво получава, преди да го отвори - и, както при клетките с категории по-горе, принадлежността по статус се променя твърде бързо, за да бъде изброена тук. Проверете я в галерията или в генерирания индекс.

Design е първият инструмент, изграден върху режима на свободно платно render.layout: "editor" - повърхност без chrome, с директна манипулация, където плъзгате, преоразмерявате, завъртате и подравнявате чрез snap кутии с текст, форми и изображения, след което експортирате през същия render път като всеки друг инструмент.

Strip Hidden Data е първата локална (on-device) утилита (privacy: "on-device"): инструмент за трансформация на съдържание, който взима файл, предоставен от вас, обработва го изцяло в браузъра и връща чисто копие - никога не се качва, никога не се маркира с воден знак, не се подпечатва произход. Text Helper е вторият - работно място на устройството за ежедневни задачи от типа „постави в сайт“ (форматиране на JSON, декодиране на JWT, Base64, URL кодиране/декодиране, SHA хеширане). Compress PDF е третият - той свива PDF, като прекомпресира изображенията в него, отново изцяло на устройството. Маркерът и текстът на баджа му "Runs on your device - nothing is uploaded" вече покриват целия набор от трансформации: Strip Hidden Data, Text Helper, Compress PDF, Convert Image (HEIC/TIFF/AVIF → WebP/JPG/PNG), Convert Font, Redact (унищожава области от изображение, SVG или PDF), Prompt to Image и Rebrand a Deck (променя темата на .pptx на място), където профилът я монтира. Това е категория утилити за поверителност, която заменя предаването на поверителни файлове на сайтове с единствено предназначение.

signed by Lollyvector SVG2026-08-24Провери самGet the signed file154 paths~40k nodes234 groups802 KBsigned by Lollyvector SVG2026-08-24Провери самGet the signed file154 paths~40k nodes234 groups803 KB

Забележка: category и status се денормализират в catalog/tools/index.json (регистърът, който галерията чете) от всеки tool.json. Манифестът е източникът на истина - индексът е генериран от npm run build:catalog, а npm run validate:catalog проваля CI, ако включеният индекс се разминава с манифестите.

Архитектурни ангажименти

Тези решения са установени. Промяната на всяко от тях е мащабно начинание - те оформят всяко друго решение в кодовата база.

1. Декларативни инструменти, с императивен изход при нужда

Инструментът е манифест (tool.json) + шаблон (template.html) + по избор hooks.js.

Манифестът декларира входовете. Не шаблонът. Входовете не се извеждат от Handlebars токени. Манифестът е договорът; шаблонът консумира именувани променливи чрез {{id}}.

signed by Lollyvector SVG2026-08-24Провери самGet the signed file39 paths~3.4k nodes70 groups2 images50 KBsigned by Lollyvector SVG2026-08-24Провери самGet the signed file39 paths~3.4k nodes70 groups2 images50 KB

Hooks са по избор. Повечето инструменти са чисто декларативни - манифест + шаблон е достатъчно. Инструментите, нуждаещи се от изчислени стойности (QR кодиране, оформяне на данни за графики), предоставят hooks.js, който излага именувани функции от жизнения цикъл (onInit, onInput, onFrame - hook за всеки кадър при жива камера за реагиращи на движение инструменти - onLevel, beforeExport, afterExport, exportFile - пътят на трансформация файл-влиза/файл-излиза, използван от локални утилити като Strip Hidden Data - и exportStill, за инструмент, който притежава собствен дълбок растер). Host зарежда hooks чрез new Function('host', …), с инжектиран capability bridge като closure scope. Това е договор за преносимост, не защитна пясъчна кутия (sandbox): hooks все още се изпълняват в реалма на страницата и могат да достигнат до window/fetch/document в браузърна обвивка - host. е поддържаната, преносима повърхност, а не наложена граница. Резултатите от асинхронни hooks са ограничени във времето (onInit 5с, onInput 2с, beforeExport/afterExport 5с, exportFile/exportStill 10с), а закъснелите резултати се отхвърлят; неконтролируем синхронен* hook не може да бъде прекъснат. Затова изпълнението на недоверен hook код от трети страни не е безопасно, докато не се появи изолация чрез Worker.

Това има значение, защото: декларативните инструменти могат да се създават от хора без разработчически опит. Ако всеки инструмент беше уеб приложение, рисковата бележка „ограничени умения за създаване/поддръжка на работни шаблони“ се превръща в постоянно тясно място.

2. Инструментите и активите са данни, не пакетиран код

Уеб и Tauri приложенията извличат каталозите с инструменти и активи от известен URL адрес при стартиране, кешират ги локално и работят с каквото има там. Добавянето на нова плочка за събитие или сезонен актив не изисква release на приложението.

Байтовете на активите се контролно сумират с SHA-256, за да се предотврати CDN отравяне. id + version на актива задвижва обезсилването на кеша.

3. Capability Bridge е единственият API, който инструментите виждат

Инструментите никога не докосват DOM извън областта на своя шаблон, никога не викат fetch директно, никога не четат файловата система. Те викат версионирани методи host.*. Каноничната дефиниция на договора е packages/core/src/host-v1.ts - SDK за автори на инструменти @lolly-tools/core, така че трета страна може да разработва спрямо него без зависимост от engine; engine/src/bridge/host-v1.ts е type re-export на него, а кодът на engine/shell продължава да импортира от този път без промяна:

Опционалните, добавъчни повърхности се появяват само когато обвивка ги предоставя. Някои са обвързани с capability - изложени само когато инструментът декларира съответния флаг: host.compose (вгражда рендирането на друг инструмент - compose), host.capture (заснемане на страница за URL Screenshot - capture) и host.recorder (заснемане от микрофон/камера/екран за инструментите за запис - microphone / camera / screen). Останалите се откриват по функционалност - присъстват, когато обвивката може да ги предостави, като инструментът пази резервен вариант за обвивки, които не могат.

Няколко водещи повърхности, за да покажем какво покрива - Host API документира всяка от тях, а packages/core/src/host-v1.ts е самият договор:

Останалите следват същите правила и са документирани заедно с тях: pdf (1.8) и pptx (1.58) за локална хирургия на документи, audio (1.71) и speech (1.96) за анализ на клипове и локален TTS/транскрипция, viz (1.72) за договора-заместител на MilkDrop, codec (1.100) и layers (1.102) за изход с дълбок бит и слоести растерни изображения, upscale (1.101) и matte (1.103) за локалните модели, raster (1.105) за hooks, които вършат собствена пикселна работа, connectors (1.106) за безопасни за експорт стрелки и c2pa (1.85) за подписване на готови байтове. Броят расте; правилата - не.

Декларируемите capabilities са: network, filesystem, clipboard, camera, microphone, screen, ffmpeg, wasm, capture, compose. (screen, добавен в 1.54, е заснемане на екран чрез host.recorder - потребителят избира екран/прозорец/раздел в нативен за браузъра UI; отличава се от capture, който растеризира URL адрес, посочен от самия инструмент.)

Един и същ инструмент работи в браузър, Tauri и headless CLI, защото всяка обвивка имплементира този интерфейс - инструментът никога не знае в коя се намира.

Bridge-ът е версиониран. Добавянето на методи е минорна версия. Премахването или промяната на сигнатури е major версия. Когато излезе v2, v1 трябва да продължи да работи.

4. Идентификаторите на активи са завинаги

suse/logo/primary е договор. След публикуване:

• ID никога не се променя, никога не се преизползва.
• Промени в байтовете → повишете version в манифеста.
• Заменен от нов актив → задайте deprecated: true и по избор replacedBy.
• Съществуващите препратки винаги се разрешават.

Това прави запазените състояния на инструменти и споделените чрез URL връзки трайни през годините.

5. URL режимът е първокласен

Всеки вход трябва да може да се изрази като URL параметър:

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

signed by Lollyvector SVG2026-08-24Провери самGet the signed file17 paths~2.0k nodes39 groups24 KBsigned by Lollyvector SVG2026-08-24Провери самGet the signed file17 paths~2.0k nodes39 groups24 KB

Режимът CLI е URL режим под друг транспорт - CLI обвивката изгражда обект на URL състояние от argv и изпълнява същия engine pipeline. Има само един render път. CLI не може да се разминава с GUI, защото не е отделна реализация.

url-mode.ts управлява кръговата обработка (parse и serialize). Набор от резервирани параметри никога не се препращат към инструмента като входове: контролите за изхода (format, export, copy, filename, width/w, height/h, unit, dpi), регулаторите за печат и произход (bleed, marks, profile, password, c2pa, imprint, durable, meta, hdr, depth, cuts) и носителите на състояние (template, z - опакованият токен „Shortest link“ - и zx, същият, криптиран с парола). Наборът RESERVED в engine/src/url-mode.ts е авторитетният източник и е фиксиран с тест; URL Mode документира всеки от тях, включително няколкото, които не са изброени тук. Входовете от тип актив в URL режим се сериализират по своя id; runtime ги разрешава чрез host.assets.get() преди хидратация. width/height са стойности в unit (по подразбиране px, също mm/cm/in/pt/pc); при физическа единица dpi задава резолюцията за растер. Те задават размера на документа на платното и предварително попълват панела с размери за експорт.

Тъй като всеки вход пътува във връзката, промяна на параметър е различен готов актив. Цялата тази палитра е един начален цвят, хармония и брой стъпки:

signed by Lollyvector SVG2026-08-24Провери самGet the signed file10 groups24 KBsigned by Lollyvector SVG2026-08-24Провери самGet the signed file10 groups24 KB

6. Съхранението минава през моста, не директно

Уеб обвивка: IndexedDB. Tauri: файлова система. CLI: в паметта. Инструментите виждат само host.state.save(slot, data) и host.state.load(slot). localStorage не се използва - твърде малък е и не може да съхранява blob-ове.

Потребителите могат да записват няколко именувани слота за редакция на инструмент и да се връщат към всяка сесия по-късно. Не се изисква създаване на акаунт; състоянието е по устройство. Тъй като мостът е единствената точка на достъп, това състояние по устройство е и преносимо: shells/web/src/data-transfer.ts изчита всичко обратно през host.profile/host.state/host.assets в един zip lolly-backup, който се импортира на всяка друга инсталация - офлайн отговорът на "преминаване към ново устройство", без нужда от сървър (пълна спецификация: docs/data-transfer.md). Интеграцията със SUSE ID (синхронизация между устройства) е бъдещ етап върху тази основа.

7. Етикетите за зрялост отговарят на риска "одобрено от бранда" по дизайн

Всеки инструмент декларира status: official | community | experimental в манифеста си. Галерията сортира по статус. Експерименталните инструменти автоматично поставят воден знак на изнесеното съдържание - водният знак се прилага от host.export.render, не от инструмента, така че не може да бъде изключен от автор на неофициален инструмент.

Това е структурен отговор на риска от възприятие, че използването на който и да е инструмент означава одобрение от бранда. Процесни отговори (опашка за преглед, ограничение чрез SUSE ID) се надграждат отгоре.

8. Входовете на инструментите се типизират чрез манифеста, включително активите

Входовете декларират type: text, longtext, number, boolean, color, select, asset, date, time, datetime-local, url, blocks, vector, table и file. Хостът рендира генеричен контрол за всеки тип от манифеста - инструментите не пишат код за контроли. (Предварителното попълване от профила на потребителя не е тип - всеки вход може да носи bindToProfile.) Три от тях носят повече тежест от останалите:

• asset (с filter и allowUpload) е мостът към глобалната система за активи; allowUpload: false е лостът за налагане на бранда за неща като лога на спонсорски плочки, където се допускат само активи от библиотеката. Качванията от потребителя използват същата форма AssetRef като активите от библиотеката, така че инструментите ги обработват еднакво.
• blocks е повтарящa се група от полета - мини-таблица вътре в един вход, редактирана в странична панел, с типизирано/дискриминирано меню за добавяне и полета за активи по блок. Кликването върху рендиран блок в канваса фокусира съответния ред. Използва се от meeting-planner, chart-creator, event-name-badge, wayfinding-signage, color-block и digi-ad.
• vector групира фиксиран набор от числа (напр. трансформация) в един съставен контрол; file съхранява собствения файл на потребителя като байтове в паметта за инструменти за трансформация на устройството (напр. strip-data и compress-pdf).

9. Шаблоните са без логика (Handlebars, не EJS)

Handlebars е избран пред EJS съзнателно:

• Без логика. Шаблоните могат да се създават от хора, които не са разработчици.
• Безопасен по подразбиране. {{x}} escape-ва HTML; {{{x}}} е незадължителна суровина.
• Липсата на произволен JS в шаблоните означава липса на повърхност за одит на XSS за всеки шаблон.

Логиката живее в hooks.js, където е явна и подлежаща на преглед. Налични помощници на Handlebars: {{default}}, {{upper}}, {{lower}}, {{eq}}, {{markdown}}, {{asset ref}}, {{asset ref "property"}} (плюс помощници за формат на данни icsStamp/rfcText/csvCell, използвани от съседните шаблони .ics/.vcf/.csv).

10. Инструментите съставят инструменти

Инструмент може да вгради рендера на друг инструмент без импорти между инструментите - композицията се разрешава от двигателя, никога от кода на инструмента. Има две повърхности:

• Декларативен манифест - composes: [{ id, tool, inputs, format?, width?, height? }]. Двигателят рендира именувания дъщерен инструмент и поставя резултата в шаблона без логика като {{asset <id>}}. event-name-badge съставя qr-code като SVG днес.
• Преносим вграден URL - <img src="https://lolly.tools/tool/<id>.<ext>?<inputs>">. Обвивката рендира този дъщерен инструмент локално (плейсхолдър пиксел се показва, докато локалният рендер се разреши); нищо никога не се извлича от lolly.tools.

Съставяне на рендера на всеки инструмент: дъщерен SVG остава истински вектор, когато родителят изнася в SVG или PDF, и се растеризира чисто за PNG; дъщерни PNG/JPG/WEBP се вграждат като изображения. Изисква способността compose. Съставените дъщерни елементи са междинни - никога не носят воден знак или печат за произход - и композицията се деградира плавно: обвивка, която не може да рендира дъщерен елемент, просто пропуска слота, а родителят пак се рендира.

Какво съзнателно избрахме да не правим

• Без EJS / без произволен JS в шаблоните. Повърхността за XSS е нулева. Логиката живее в hooks.js.
• Без задължителна CMS за активи. Отделните хора внасят собствените си творчески файлове направо в каталога си вътре в приложението (изгледът Каталог и Brand Studio) - без сървър, без административна конзола. Работата се предава нататък като сесия: връзка за споделяне носи цялото състояние, а същата сесия пътува в резервно копие или през сесия за съвместна работа. Който контролира внедряването, може после да заключи споделена сесия като шаблон - отваря връзката, записва стойностите ѝ като запис на шаблон в директорията на този инструмент в пакета за бранда и прави commit - след което тя се появява в избирача „New from template“ на инструмента и може да се достига чрез директна връзка като ?template=<id>. Git е стъпката за заключване на собственика на внедряването, никога на автора. За споделен, управляван каталог, организация може да управлява директорията с активи по същия начин и да блокира актуализациите чрез PR преглед - наличен модел на управление, а не изискване на приложението.
• Без наложен RBAC. Отвореното приложение е публично достъпно по подразбиране; рискът за бранда се управлява с етикети за зрялост + водни знаци. Организация, която иска по-строг контрол, наслагва собствена автентикация и прегледания в git каталог по-горе.
• Без централна база данни. Цялото потребителско състояние е на всяко устройство поотделно. Интеграцията със SUSE ID е в пътната карта, но не е пречка за пускането.
• Без общ път на кода за инструменти/енджин. Енджинът е с отворен код, както и брандово-независимите инструменти в community/; пакет за бранд като частния brands/suse/ носи собствените си инструменти и каталог по свои собствени условия. И в двата случая разделянето е наложено (без кръстосани импорти от engine/ в съдържанието на инструментите), така че разделението остава чисто.

Жизненият цикъл, от начало до край

Потребител отваря lolly.tools/#/tool/qr-code?url=https://suse.com&ecl=H:

1. Зареждане. Уеб обвивката отваря IndexedDB, конструира моста от способности, синхронизира каталозите на инструменти и активи (или зарежда от кеш при офлайн).
2. Маршрутизация. URL хеш → изглед tool, с извлечени qr-code и URL параметри.
3. Зареждане. loadTool('qr-code', fetchFile) извлича tool.json, валидира спрямо JSON схема, извлича template.html, styles.css и изходния код на hooks.js.
4. Разбор на URL състоянието. parseUrlState превръща URL параметрите в начални стойности на входовете. Референции към активи (?logo=suse/logo/primary) се разбират като леки обекти { id, _unresolved: true }.
5. Изпълнение. createRuntime(tool, host, initialValues) изгражда модела на входовете (сливайки данни от профила, стойности по подразбиране и начални стойности), разрешава референции към активи чрез host.assets.get(), зарежда хуковете (с host в затворен обхват, не в пясъчник), извиква hooks.onInit.
6. Рендиране. Обвивката се абонира за изпълнението; при всяка промяна на състоянието получава { model, hydrated }. Тя рендира контролите за входовете от модела и записва хидратирания HTML на шаблона в #tool-canvas.
7. Взаимодействие. Потребителят пише в поле за вход → runtime.setInput(id, value) → прилагат се ограничения → извиква се hooks.onInput → повторна хидратация → повторно рендиране. Канвасът се обновява на живо.
8. Изнасяне. Потребителят кликва Download(PNG) → runtime.export(canvasNode, 'png') → host.export.render (растеризира чрез dom-to-image-more; SVG/PDF минават през специализирани векторизатори, обхождащи DOM) → blob → host.export.download. Диапазонът от формати, които инструмент може да избере, е широк, а изброяването render.formats в schemas/tool.schema.json е авторитетният източник за него - растери и плаващи растери, вектори и файлове за рязане, печат/CMYK, движение, редактируеми документи (pptx, docx, odt), палитра и изходи за данни/текст, аудио и файлове с шрифтове. URL режим назовава всеки идентификатор и какво произвежда. Аудиото е в това изброяване както всичко останало (wav, mp3, m4a, opus, декларирани от аудиограмата и инструментите за запис); отделно, режим render.capture на инструмент за запис задвижва host.recorder, чийто запис пристига като завършен Blob в контейнера, в който браузърът е записал. (Инструменти, които задават render.export: false - напр. Color Palette, Countdown Timer, Strip Hidden Data, Text Helper, Compress PDF - скриват контролите за изтегляне/формат/размери.) Физическите единици се преобразуват за всеки формат тук (PDF → истински пунктове на страницата, растер → пиксели при DPI с блок pHYs). Метаданните за авторство/произход (автор, инструмент, източник - изградени от engine/src/metadata.ts) се вграждат за всеки формат: PNG iTXt, JPEG EXIF, PDF info dict, SVG <metadata>, GIF коментар. Експерименталните инструменти получават воден знак, поставен от хоста, не от инструмента.

signed by Lollyvector SVG2026-08-24Провери самGet the signed file49 paths~3.3k nodes61 groups3 images74 KBsigned by Lollyvector SVG2026-08-24Провери самGet the signed file49 paths~3.3k nodes61 groups3 images74 KB

Същият жизнен цикъл в Tauri. Същият жизнен цикъл в CLI - jsdom осигурява безглав DOM; изходът отива във файл или stdout.

Статус на отворения код

Кодът е MPL-2.0. engine/, shells/, services/, schemas/ и docs/ са с отворен код под MPL-2.0 - платформа за скелетна структура (scaffolding), неутрална към доставчици, за брандови инструменти, като всяка доставяна единица е в собствено хранилище под github.com/lolly-tools.

Съдържанието на инструментите се доставя като пакети за бранд, всеки със собствени условия (виж NOTICE.md на пакета). community/ е публичното хранилище lolly-tools и неговите брандово-независими инструменти също са MPL-2.0. brands/suse/ е частният пакет suse-lolly: инструментите на SUSE и каталогът на SUSE, собственост на SUSE, включително лицензираната му музика PremiumBeat. brands/lolly-start/ е празният стартов бранд, притежаван от това хранилище. Шрифтовете се доставят вътре в пакет под SIL Open Font License 1.1 - пакетът на SUSE носи шрифтовете SUSE и SUSE Mono.

tools/ и catalog/ в корена на хранилището са игнорирани от git изгледи: профил ги събира от community/ плюс активния пакет за бранд, затова всеки скрипт и обвивка четат тези два пътя, а никога пакет директно.

Разделянето е наложено - няма кръстосани импорти от engine/ в съдържанието на инструментите - така границата между платформа и съдържание остава чиста.

Къде свършва двигателят и започва хостът

Ако можеш да го опишеш с чисти данни + Handlebars → двигател. Ако засяга DOM, файловата система, мрежата или API на браузър/ОС → хост.

Границата е рязка нарочно. Двигателят е частта с отворен код. Всичко, което знае за SUSE, конкретни платформи или среди на изпълнение, остава извън него.

За следващото ниво на детайл, engine/README.md изброява всеки модул на двигателя и за какво отговаря, а Модел на заплахите и граници на доверие документира къде тази същата граница едновременно служи като граница на доверие.