Targets & Render-Backends

• Target-Profil = wofür — die Umgebung mit ihren Regeln: web.document (Website/Shop), web.application (App-Oberfläche), desktop.shell (tricoma-Desktop mit Fenstern), email.client (E-Mail-HTML), builder.preview.
• Render-Backend = womit — die Technik: php-html (serverseitig, produktiv), perspektivisch browser-dom und email-html.

Jede Definition erklärt in ihrem Manifest, welche Targets sie unterstützt. Ein Button existiert auf Website UND Desktop; eine Preistabelle hat im E-Mail-Client nichts verloren; component.window gibt es nur im Desktop.

Ein Profil (targets/<ordner>/profile.php) baut das HTML-Grundgerüst: <head> mit tokens.css und den benötigten Assets, data-target-Attribut, Runtime-Einbindung samt __INVISIBLE__-Konfiguration. Der Node-Baum wird hineingesetzt.

Ein Button im Desktop ist kompakter als auf der Website — aber es ist derselbe ui.button. Der Unterschied kommt aus der Target-Token-Schicht: [data-target="desktop.shell"] überschreibt ausschließlich semantische Tokens (Dichte, Radien, Fokusringe). Kein Baustein verzweigt im Code nach Target.

Website (web.document) und App/Desktop (web.application, desktop.shell) sind zwei getrennte Baukästen, die dieselbe Sprache sprechen (gleiche Tokens, gleiche Elements, gleiches Schema), aber differenzierte Komponenten haben: component.window, Toolbars und App-Shells existieren nur im Desktop-Baukasten — Marketing-Blocks, Hero und Pricing nur im Website-Baukasten. Geteilt wird, was wirklich beides kann — ein Button, eine Tabelle, ein Formular.

Zwei Konsequenzen: Eine Surface fürs Target X darf nur Definitionen enthalten, die X können (Publish-Gate). Und ein Builder zeigt IMMER nur den Baukasten des jeweiligen Targets — wer eine Website baut, sieht keine Desktop-Components, und umgekehrt.