JUSN
a6b3a42f2a
Hintergrund: Review aller 22 Prompt-Templates (P1-P18 + P8-Adapter) auf
Konsistenz. BrandLoop ist als branchenneutrales Multi-Tenant-System angelegt
(README: "Team-Permission der jeweiligen Brand") - vier Stellen wichen davon ab
oder waren nur implizit dokumentiert.
1. Branchen-Lock entfernt (P07-bild-prompt-generator.md, P08-video-kern.md)
Beide öffneten mit "... einer Werbe-Produktion fuer Kosmetik-Brands."
Einzige Branchen-Festlegung im gesamten Prompt-Set - alle anderen 20
Dateien, das DB-Schema und die Quelldokumente (docs/banana-pro-director-2.0.md)
sind branchenneutral. Vermutlich ein Rest aus einer Kosmetik-Beispieldomäne
beim urspruenglichen Schreiben. Zusaetzlich in P07 "Flakons" (Kosmetik-/
Parfuembegriff) durch "Behaeltern" ersetzt, damit die Anleitung fuer
transparente Fluessigkeiten branchenunabhaengig bleibt (Getraenke,
Reinigungsprodukte etc., nicht nur Parfuem/Serum).
2. Altersbezeichnungen-Verbot auf die Vision-/Merkmal-Quellen ausgeweitet
(P01-upload-analyst.md, P16-referenz-interpreter.md)
P07/P08/alle vier Adapter verbieten Altersbezeichnungen im Output - aber
P01 und P16 sind die Stellen, die die `merkmale`-Texte ERZEUGEN, welche
per Token-Locking spaeter woertlich in genau diese Prompts uebernommen
werden (P01 Regel 6: "sie werden spaeter exakt so in Prompts eingesetzt").
Ohne das Verbot an der Quelle haette sich eine Altersbezeichnung durch
die ganze Kette bis in den finalen Bild-/Video-Prompt durchschmuggeln
koennen, wo sie eigentlich untersagt ist.
3. Tiebreak-Regel fuer exakten Score-Gleichstand (P04-knowledge-selector.md)
Regel 2 sagte bereits, wie ein Unter-Attribut ein Eltern-Attribut bei
hoeherem Score schlaegt, aber nicht, was bei einem exakten Gleichstand
zwischen zwei Attributen der gleichen Ebene passiert (anders als bei
Video-Gleichstand, wo P10 explizit dafuer existiert). Ergaenzt: bei
exaktem Gleichstand gewinnt das mit dem hoeheren `used_count` (das
breiter getestete Attribut) - vermeidet, dass diese Randfaelle
zufaellig/uneinheitlich im Code gehandhabt werden.
4. Zwei bisher nur implizite Konzepte in prompts/README.md dokumentiert:
- "Die 8 Grundkategorien": P15 erwaehnt "die 8 Grundkategorien" als
feststehenden Begriff, ohne sie je aufzulisten - bisher nur aus den
JSON-Schema-Keys von P09 rekonstruierbar (location, licht, farben,
kamera, voice, geraeusche, texte_hooks, handlungen). Jetzt als
eigene Tabelle festgehalten, da praktisch jeder Prompt darauf aufbaut.
- "Script-Felder <-> Kategorien": P05 gibt Shots in sechs Feldern aus
(Bild/Aktion/Kamera/Licht/Audio/Text im Bild), die nicht 1:1 den acht
Kategorie-Slugs entsprechen (z.B. buendelt "Audio" voice+geraeusche,
"Bild" buendelt location+farben). Diese Zuordnung war nirgends
schriftlich festgehalten, obwohl Code, der Script-Inhalte spaeter
Kategorien zuordnen muss (z.B. fuer P6-Diffs), sie braucht.
Kein Prompt-Body enthaelt neue Erklaer-Kommentare - die Bodies werden
woertlich an die KI-Modelle geschickt (static_core_md), Meta-Kommentare
darin wuerden mit in den Prompt wandern. Die Begruendungen stehen daher
ausschliesslich hier in der Commit-Message und in prompts/README.md
(reine Doku, wird nicht geseedet).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
BrandLoop (videogen)
KI-Video-Generierung mit lernender Brand-Knowledge-Base (Elo-Scoring über Attribute).
- Prototyp: prototyp-app.html – statische Preview unter
videogen.project.webklar.com - Backend: selbst gehostetes Appwrite (
https://appwrite.webklar.com/v1), Projekt BrandLoop6a5cee34002bb8360c34, Datenbankbrandloop
Datenbank-Setup
Das komplette Schema (15 Tabellen, Indizes, 4 Storage-Buckets, internes Dev-Team) legt scripts/setup-appwrite.mjs an – idempotent, kann nach Plan-Erweiterungen jederzeit erneut laufen:
# API-Key liegt als BRANDLOOP_APPWRITE_API_KEY in /home/webklar/apps/.env, dann einfach:
node scripts/setup-appwrite.mjs
# oder explizit:
APPWRITE_API_KEY=... node scripts/setup-appwrite.mjs
Der API-Key braucht die Scopes Databases/Tables (read+write), Storage/Buckets (read+write), Teams (read+write).
Prompt-Templates (P1–P18)
Alle 18 Prompts des Prompt-Inventars liegen versioniert in prompts/ (Konventionen
und Slot-Registry: prompts/README.md) und werden mit
scripts/seed-prompts.mjs in die Tabelle prompt_templates
geseedet — idempotent: Inhaltsänderung ⇒ neue Zeile version+1, alte Zeilen aktiv=false.
P8 ist eine Familie (1× Regie-Kern + 4 Modell-Adapter seedance/veo/sora/wan) = 22 Zeilen.
Das Skript seedet außerdem die 4 globalen Brand-Regeln in rules.
node scripts/seed-prompts.mjs
Bewusste Abweichungen vom DB-Plan
- Referenzen als indizierte String-Spalten (size 64) statt Relationship-Spalten.
Appwrite-Relationships sind nicht filter-/indizierbar – der Top-N-Index auf
attributes(brand_id, category_id, status, score DESC) und alle Listen-Queries brauchen aber genau das. Many-to-many (videos.attribute_ids) ist ein String-Array (Query.contains). IDs mit 64 Zeichen, weil uuid4 = 36 Zeichen. created_at-Spalten entfallen – Appwrite pflegt$createdAtautomatisch (Indizes nutzen$createdAtdirekt, z. B.score_events,jobs).- Enum-Werte ohne Umlaute (
laeuftstattläuft). attributes.tags: Key-Index statt Volltext-Index – Appwrite verbietet Fulltext auf Array-Spalten; Tag-Suche läuft überQuery.contains.- S3/Hetzner-Backend für Storage ist eine instanzweite Appwrite-Einstellung
(
_APP_STORAGE_DEVICE) und betrifft alle Projekte auf dem Server – wird daher nicht vom Skript gesetzt, sondern muss bewusst am Server konfiguriert werden. Aktuell: lokales Storage.
Rechte-Modell
rules+prompt_templates: Tabellen-Rechte nur für Teaminternal(Dev-Modus) 🔒- Alle anderen Tabellen:
rowSecurityan, keine Tabellen-Rechte – Zeilen bekommen beim Anlegen die Team-Permission der jeweiligen Brand (Multi-Tenant). consents-Bucket: zusätzlich Lese-Recht für Teaminternal.- Append-only per Konvention (Server-Key schreibt):
score_events,video_metrics,jobs.
Noch offen (laut Plan)
- Appwrite Functions:
elo-update,favorit-berechnen,ads-metriken-holen,kategorie-durchschnitt,archivierung,job-dispatcher - Stripe-Anbindung (metered billing über
usage_records)