# BrandLoop – Projekt-Übersicht (Knowledge Base)

**Stand:** 25. Juli 2026 · konsolidiert aus allen bisherigen Arbeitsdokumenten · **erweitert um Bild-Modus, Feed & Ordner (§15)**
**Zweck:** Ein Dokument, das den kompletten Projektstand hält – Basis für die nächsten Arbeitsschritte.

---

## 1. Was wir bauen (in einem Absatz)

Eine App, in der Brands einen Prompt eingeben und 3–6 KI-generierte Werbevideos bekommen – jedes von einem anderen Top-Videomodell. Der Owner wählt das beste, die Ad läuft, und jedes Ergebnis (Vote + echte Ad-Performance) fließt in eine wachsende **Brand Knowledge Base** zurück. Jedes weitere Video startet mit allem, was bisher funktioniert hat.

**Seit Juli 2026 daneben: ein zweiter, entkoppelter Bild-Modus mit Feed.** Bilder statt Videos, ein festes Bildmodell, kein Vote-Loop – dafür ein öffentlicher Feed, aus dem man fertige Rezepte kopiert und in eigene **Ordner** sortiert. Der Bild-Modus ist der günstige Einstieg und löst den Kaltstart; Video bleibt das Kernprodukt. Details: **`konzept-bilder-feed.md`**, Zusammenfassung in §15.

> **Sprachregelung – gilt für die gesamte Doku und den Code:**
> **„Modell"** (auch: Asset) = Person, Produkt, Kulisse oder Logo – das, was in einem Bild oder Video zu sehen ist. Tabelle `assets`.
> **„KI-Modell"** = Seedance, Veo, Sora, Wan, das Bildmodell. Immer ausgeschrieben, nie nur „Modell".
> Wo im Text unten noch „Modell" im Sinne von KI-Modell steht, ist das ein Altbestand aus der Zeit vor dem Bild-Modus – im Zweifel gilt diese Regel.

> **Pitch:** „Deine Ads lernen aus jedem ausgegebenen Euro. Generische Tools erstellen Videos – wir bauen ein Ad-Gedächtnis für deine Brand."

**Arbeitstitel:** BrandLoop (Platzhalter, noch nicht final)

**Zielgruppe:** ursprünglich D2C-Kosmetik-Brands. Mit dem Feed **branchenoffen** (Nischen-System) und über den Bild-Modus auch für Creator und Privatnutzer – siehe offene Punkte in §11.

---

## 2. Die drei tragenden Ideen

| Idee | Kern | Warum es der Moat ist |
|---|---|---|
| **Ad-Gedächtnis pro Brand** | Strukturierte Wissensdatenbank pro Kunde, wird bei jeder Generierung als Kontext injiziert | Konkurrenz generiert, wir lernen → Wechselkosten steigen mit der Nutzungsdauer |
| **Modellunabhängigkeit** | Kein Fine-Tuning eines Modells; Wissen liegt in Text/DB, nicht in Gewichten | Besseres Modell erscheint → wird eingetauscht, Knowledge Base bleibt |
| **Performance-Loop** | Meta/TikTok-Ads-Daten (CTR, Thumbstop, ROAS) gewichten das Scoring stärker als Bauchgefühl-Votes | Aus „schöne Videos" wird „Videos, die nachweislich verkaufen" |

**Wichtige Abgrenzung:** Wir trainieren **kein Modell neu**. Ausnahme ist nur die Konsistenz von Gesicht/Produkt (Character-Reference-Features bzw. LoRA auf Referenzbildern).

---

## 3. Der Produkt-Loop

**Runde 1 (Kaltstart):** Prompt → 3 Videos von 3 Modellen → Owner wählt → Vote = erstes Trainingssignal.
**Runde 2+:** Neuer Prompt → wird vor der Generierung automatisch mit Brand-Wissen angereichert → Videos starten nicht bei null → Vote + Ad-Performance aktualisieren die Knowledge Base.

Kostenlogik im Ablauf: Nutzer sieht erst das **Script** und bestätigt – erst danach wird generiert (Kosten entstehen nach Bestätigung; Script-Änderungen sind zusätzliches Lernsignal).

---

## 4. Brand Knowledge Base – Datenmodell-Logik

### Zwei Ebenen
- **Regeln** (kein Score, gelten immer): cleaner Hintergrund, „nur zeigen was verlangt ist", Logo-Schutz, „Referenzen nie 1:1 kopieren". Liegen im **Developer-Modus**, für den Nutzer unsichtbar → Betriebsgeheimnis.
- **Attribute** (mit Elo-Score, konkurrieren): location, licht, farben, kamera, voice, geraeusche, texte-hooks, handlungen.

### Weitere Objekte
- **Modelle / Assets** (Gesicht, Produkt, **Kulisse**, Logo): versioniert nach **Release-Prinzip** – Videos und Bilder nutzen immer eine *freigegebene* Version, kein schleichender Drift. *„Modell" meint in diesem Projekt durchgehend das Asset, nie das KI-Modell.*
- **Videos**: ein Eintrag pro generiertem Video (Prompt, Tags, verwendete Asset-Versionen, Vote, Performance).
- **Posts**: das Pendant im Bild-Modus – ein Slot-Rezept mit Bilderkette (§15).
- **Ordner**: privater Wissens-Scope. Attribut-Scores werden **je Ordner** geführt (§15).
- **Logs**: append-only, jeder Score-Change mit Grund **und Scope**.

### Drei Textebenen je Attribut
**Beschreibung** (was ist das) · **Was es ausmacht** (gelernte Essenz) · **Details** (Drehorte, Licht/Tageszeit, Farbwelt, Sound, fertige Prompt-Bausteine + Negativ-Prompts). Schreibt das System selbst; der Nutzer sieht davon nichts.

---

## 5. Scoring (Elo) – die Kernmechanik

**Problem:** Attribution. Gewinnt Video A (Kaiserslautern) gegen B (Köln), kann der Grund auch Licht, Stimme oder das Modell sein.

**Lösung – 5 Mechanismen:**
1. **Elo statt Fixpunkte** – Sieg gegen ein starkes Attribut bringt mehr. Skala 0–10.000.
2. **Verteilte Punkte** – alle Tags des Gewinner-Videos gewinnen anteilig, alle des Verlierers verlieren anteilig. Über viele Runden kristallisiert sich der echte Treiber heraus.
3. **Gezielte Fragen** – „Welche Stadt war besser?" wirkt isoliert auf ein Attribut → schnellstes sauberes Signal.
4. **System-Favorit mit Anchoring-Schutz** – Favorit wird markiert, aber: **Bestätigung ×0,3 · Abweichung ×1 · Ad-Performance ×2**. Übereinstimmungsrate Vorhersage↔Wahl ist die zentrale Qualitätsmetrik.
5. **LLM-Inhaltsvergleich** – nach jedem Vote wird analysiert, *was* besser war, und in beide Attribut-Dateien geschrieben. Ggf. entsteht ein **Unter-Attribut** (kaiserslautern → --stadion).

**Startwerte:** Neuer Eintrag startet beim **Kategorie-Durchschnitt** (nicht bei 5000), sonst gilt Ungetestetes automatisch als „schlechter als alles". Nur der allererste Eintrag einer Kategorie startet bei 5000. Unsicherheit steckt im **K-Faktor** (32 neu → 8 etabliert).

**Archivieren statt löschen** – ein schlechter Score ist auch Wissen.

---

## 6. UI / Funktionsumfang

Homescreen → **Feed** · **Erstellen** (Szene / Post / Modell) · **Ordner** · **Verbessern** (jederzeit auf jedes Modell) · **Knowledge Base** (Ansicht) · **Developer-Modus** (versteckt, intern).

| Bereich | Inhalt |
|---|---|
| **Feed** | Posts anderer Nutzer, gefiltert nach Nische, sortiert nach Feed-Score → Post-Detail → **Kopieren** (Slot-Chips) oder in einen Ordner speichern |
| **Erstellen → Szene** (Video) | Prompt → automatische Anreicherung → Script-Anzeige & Bestätigung → 3–6 Videos → Auswahl → optionale gezielte Frage → Upload/Veröffentlichung → Live-Performance |
| **Erstellen → Post** (Bild) | Ordner wählen → Format → Slots füllen → ein Bildmodell generiert die Bilderkette → privat behalten oder aktiv veröffentlichen |
| **Erstellen → Modell** | Person/Produkt/**Kulisse** beschreiben + Referenzbilder → Modell wird erstellt → direkt „Verbessern" möglich |
| **Ordner** | Sammlungen anlegen (Zweck + Startwerte), eigene und fremde Posts einsortieren, Reifegrad sehen |
| **Verbessern** | Asset wählen → Text-Feedback *oder* Referenz-Upload (**Pflichtfeld:** was soll übernommen werden) → 3–5 neue Versionen → Vorher/Nachher → beste wählen → neue freigegebene Version |
| **Developer-Modus** | Feste Regeln · Prompt-Einblick (was wirklich ans Modell ging) · Elo-Parameter |
| **Onboarding** | Tutorial-artig, erscheint beim ersten Klick auf „Erstellen"; 6 Pflichtfragen (<2 Min) + optionale Uploads |

**Scoring beim Verbessern:** Nur Merkmale, **in denen sich die Versionen unterschieden**, bekommen Punkte.

**Videoanzahl 3–6, Preis pro Video** – Deckel bei 6, weil es nur eine Handvoll Top-Modelle gibt und bei zu vielen Videos die Auswahlqualität (= Trainingssignal) sinkt.

### Onboarding-Fragen (Stufe 1, Pflicht)
1. Label-Name · 2. Was verkaufst du · **3. Nische (feste Branchenliste)** · 4. Zielgruppe · 5. Drei Brand-Worte · 6. Wie lange am Markt.
**Stufe 2 (optional):** Logo, Produktbilder (3+ Winkel), bisher beste Ads, Brand-Gesicht, **Kulisse**.
**Stufe 3 (Progressive Profiling, max. 1 Frage/Sitzung):** Farbwelt, Voice vs. Text-Overlay, No-Gos, Preissegment, Locations, **Ad-Konten verbinden** (wichtigster Moment – hier startet der Performance-Loop), **Social-Konto verbinden** (nach der ersten Post-Veröffentlichung), Wettbewerber.

---

## 7. Prompt-Architektur (22 Denk-Punkte, davon 19 neu zu schreiben)

**Bauprinzip aller Prompts:**
```
[STATISCHER KERN]  – ändert sich nie, liegt im Dev-Modus
[SLOT: REGELN]     [SLOT: ASSETS]     [SLOT: ATTRIBUTE]     [SLOT: USER-INPUT]
```

**Grundregel: Kein LLM, wo Code reicht.** Elo-Mathe, Archivierung, Performance-Mapping, Favorit-Berechnung sind deterministisch (⚙️).

| Phase | Prompts |
|---|---|
| Onboarding | P1 Upload-Analyst (Vision) · P2 Profil-Übersetzer |
| Szene erstellen | P3 Intent-Versteher · P4 Knowledge-Selector · P5 Script-Autor · P6 Script-Diff-Lerner · **P7 Bild-Prompt-Generator** ✅ · **P8 Video-Prompt-Generator** ✅ |
| Nach Generierung | **P9 Video-Analyst/Tagger** (Vision) · P10 Favorit ⚙️ · P11 Vote-Attributierer · P12 Vergleichs-Analyst · P13 Frage-Generator |
| KB-Pflege | P14 Details-Autor · P15 Kategorie-Wächter |
| Verbessern | P16 Referenz-Interpreter · P17 Versions-Chronist |
| Reporting | P18 Insight-Reporter (V2) |
| **Bild-Modus & Feed** | **P19 Slot-Analyst · P20 Ordner-Vorschlag · P21 Werbetext-Autor · P22 Bild-Tagger** (Vision) |

- **Kritischer MVP-Pfad Video:** P3, P4, P5, P8, P9, P11 – ohne die läuft der Loop nicht.
- **Kritischer MVP-Pfad Bild:** P7, P19, P21, P22 – ohne die funktioniert Kopieren nicht. P20 ist nachrüstbar.
- **P19 ist der heikelste neue Prompt:** zu wenig Abstraktion legt fremde Knowledge Bases offen, zu viel macht das Rezept unverständlich. Er verarbeitet fremden Text → **Anti-Injection-Satz zwingend**.
- **P7 & P8 existieren bereits**, müssen aber auf das Slot-System umgebaut werden; P8 zusätzlich pro Modell dialektisiert (ein Regie-Kern + 3–6 Adapter).
- **Teuerster Prompt:** P9 – läuft 1.000×/Monat bei 1.000 Videos.

---

## 8. Recherche-Ergebnisse: fertige Vorlagen (nichts von null bauen)

| Unser Prompt | Vorlage |
|---|---|
| P5/P8-Kern | **Offizieller Wan-Rewriter** (Alibaba, öffentlich auf GitHub) + „Master Prompt Architect"-Muster |
| P8-Adapter Seedance | Offizielle 6-Schritt-Formel, 60–100 Wörter |
| P8-Adapter Veo | 5-Teile-Formel (Kamera zuerst) + Timestamp-Prompting |
| P8-Adapter Sora | OpenAI-Cookbook-Template (Prosa + gelabelte Blöcke) |
| P7 | WearView-Rezept + Miraflow-Beauty-Templates |
| P9 | Microsoft-ISE-Pipeline (Enum-Zwang) + Gemini Structured Outputs |
| P16 | „Lock → Change → Scope"-Muster |

**Die wichtigsten übernehmbaren Details:**
- **Anti-Injection-Satz** aus dem Wan-Rewriter wörtlich übernehmen (schützt vor Manipulation durch User-Prompts).
- **Seedance:** nur EINE Kamerabewegung pro Shot; Rhythmus-Wörter statt Technik-Jargon; **Licht ist der größte Qualitätshebel**; „no music" explizit; Multi-Shot per „cut to"; echte Gesichter auf Fotos werden geblockt → stützt unsere KI-Gesichter-Regel.
- **Foto-Realismus:** Wörter wie „flawless", „perfect skin", sogar „ultra realistic" triggern den Beauty-Filter-Bias und **verschlechtern** das Ergebnis. Doppelte Negativliste (`wrinkles` UND `skin too perfect`). Flat-Licht versteckt Textur, gerichtetes Licht zeigt sie.
- **Konsistenz:** 4–6 Referenzbilder optimal (>7 = feature-averaging); **Identity-Lock am Anfang UND Ende** des Prompts; **Token-Locking** – Merkmale wörtlich speichern und wörtlich wiederverwenden (gehört als Regel in die Asset-Dateien).
- **P9-Tagging:** Enum-Zwang ist „the highest-leverage decision"; doppelte Absicherung (Prompt-Regel + Code-Validator). **Gemini ist gesetzt** – einziges Modell mit nativem Video-Input inkl. Audiospur; `media_resolution: low` + 1 FPS drückt die Kosten.

**Lücken (ehrlich):** ByteDances interner Seedance-Rewriter ist nicht öffentlich · kein offizieller Google-Director-Prompt · Lizenzen einiger GitHub-Repos unverifiziert → Strukturen als Inspiration, Texte selbst schreiben.

---

## 9. Technik & Datenbank

**Architektur:** Cloud (V1), Hetzner Deutschland, DSGVO-konform. App: Web + native aus einer Codebase; Zahlung möglichst über Web-App via Stripe (App-Store-Abgabe 15–30 % umgehen). **V2+:** eigener MCP-Server, über den Brands ihre Knowledge Base in eigene Tools einbinden.

| Baustein | Wahl |
|---|---|
| Hosting | Hetzner Cloud (MVP CX32 ~€7 → CX42 ~€16 ab ~25 Brands) |
| Video-Speicher | Hetzner Object Storage (S3-kompatibel) |
| Backend/DB | **Appwrite self-hosted** (Auth+Teams, TablesDB, Functions, Realtime, Storage mit S3-Adapter, Messaging) – €0 Lizenz |
| KI-Gateway | **OpenRouter** (eine API für LLM *und* Video) |
| LLM | Claude (Scripts, Tagging, Vergleiche) · Gemini für P9 |
| Videomodelle | Seedance 2.0 + Veo 3.1 + Sora 2 / Wan |
| Payment | Stripe (Abo + metered) |

**Kostenrechnung 25 Brands (~1.000 Videos/Monat):** ~€1.300 gesamt, davon **>90 % Videogenerierung** (~€1.200). ≈ €52/Brand/Monat → Abo ab €150–300/Brand lässt gesunde Marge. Genau deshalb funktioniert „Preis pro Video".

### Datenbank-Tabellen (Appwrite)
`brands` (inkl. `nische`) · `rules` 🔒 · `prompt_templates` 🔒 (P1–P22, **versioniert**, mit model_adapter) · `categories` (avg_score als Cache, je Ordner) · `attributes` (**nur noch die Definition**: 3 Markdown-Ebenen, prompt_bausteine, negativ_prompts, self-relation für Unter-Attribute) · **`attribute_scores`** (Herzstück: score, k_factor, start_value, wins/losses – **je Attribut je Ordner**) · **`folders`** (zweck, startwert_modus) · `score_events` (append-only, mit folder_id) · `assets`/„Modelle" + `asset_versions` (released_version_id, Einwilligungs-Datei, typ inkl. `kulisse`) · `scenes` (user_prompt + selected_context + script vs. script_final = P6-Signal) · `videos` (prompt_sent, tags, attribute_ids, asset_version_ids, is_system_favorite) · **`posts`** (Slot-Rezept, slot_summary, sichtbarkeit, feed_score) · **`post_images`** (Bilderkette) · **`post_folders`** (m:n) · **`post_metrics`** (Feed-Signale) · `video_metrics` (Zeitreihe) · `votes` · `questions` · `jobs` (mit prompt_template_key **+ version** → ohne das kein Prompt-Debugging; cost_usd) · `usage_records`.

**Buckets:** uploads · asset-references · generated-videos · **generated-images** · consents.
**Functions (deterministisch):** elo-update · favorit-berechnen · ads-metriken-holen (Cron) · kategorie-durchschnitt (Cron) · archivierung (Cron) · job-dispatcher · **ordner-initialisieren** · **feed-score-berechnen** (Cron) · **feed-import** · **social-reichweite-holen** (Cron).
**Rechte:** Brand = Appwrite-Team mit Row-Level-Permissions (Multi-Tenant ohne Extra-Code); internes Team exklusiv auf `rules`, `prompt_templates`, `jobs.prompt_sent` → **das App-Geheimnis liegt in den Rechten, nicht nur im UI**.

---

## 10. Rechtliches

- **AVV** mit Hetzner (Standard, kostenlos)
- **EU AI Act:** KI-generierte Werbevideos müssen gekennzeichnet werden
- **Gesichter echter Personen** nur mit dokumentierter Einwilligung (auch beim Brand Owner) → **rein KI-generierte Gesichter sind der sichere Standard**
- Referenzen fremder Inhalte: Merkmale beschreiben und lernen, **nie 1:1 kopieren**
- Impressum / AGB / Datenschutzerklärung
- **Meta/TikTok-App-Reviews früh beantragen** – die Freigabeprozesse dauern

---

## 11. Risiken & offene Punkte

| Risiko | Status / Gegenmaßnahme |
|---|---|
| Kosten pro Runde | Gelöst: Preis pro Video → aus Risiko wird Umsatzhebel |
| Kaltstart Runde 1 | **Weitgehend gelöst:** Onboarding-Uploads + **Import beim Kopieren** aus dem Feed (§15) – die KB ist gefüllt, bevor der erste Euro ausgegeben wurde |
| Anchoring durch Favoriten-Markierung | Vote-Gewichtung + Tracking; bei >90 % Bestätigungsrate Markierung testweise ausblenden |
| Wenig Datenpunkte für Elo | LLM-Inhaltsvergleich zieht schon aus einem einzigen Vergleich Erkenntnisse |
| Plattform-Anbindung | Meta/TikTok-API-Zugänge + Attributionsfenster technisch prüfen |
| **Neu: Konvergenz durch den Feed** | Wenn alle dieselben Top-Posts kopieren, wandert dasselbe Wissen in alle KBs, alle Ads sehen gleich aus und der Moat wird wertlos. **Gegenmaßnahme: Ordner** – Wissen wird segmentiert statt gemittelt (§15) |
| **Neu: Rich-get-richer im Feed** | Wer oben steht, bekommt Views und bleibt oben. Gegenmaßnahme: Zeit-Decay + fester Explorations-Slot für neue Posts |
| **Neu: Manipulation des Feed-Scores** | Globale Sichtbarkeit erzeugt Anreiz für Fake-Signale. Rate-Limits, Verifizierung, Ausreißer-Erkennung. Bei brand-internen Scores war das kein Thema |
| **Neu: Moderation & Minderjährigenschutz** | Öffentlicher Feed = nutzergenerierte Inhalte → DSA-Meldepflichten; breitere Nutzerbasis → Altersgrenzen klären |
| **Offen:** finaler Produktname | „BrandLoop" ist Platzhalter |
| **Offen:** konkrete Preisstufen | Richtwert €150–300/Brand/Monat + Preis pro Video. **Passt nicht mehr zur Creator-/Privatnutzer-Zielgruppe des Bild-Modus** – dort braucht es eine eigene, deutlich niedrigere Stufe oder Freemium |

---

## 12. Roadmap

Es gibt jetzt **zwei Stränge**, die parallel laufen können – der Bild-Strang ist billiger zu bauen und liefert früher Nutzer.

**Video-Strang (Kernprodukt)**

1. **MVP** – Prompt → 3 Videos (3 Modelle) → Auswahl → einfache KB (Tags + Elo) → Anreicherung ab Runde 2. *Prompts: P3, P4, P5, P8, P9, P11.*
2. **V2** – Gezielte Vergleichsfragen, LLM-Inhaltsvergleich, Unter-Attribute, Produkt-/Gesichts-Referenzen. *P12, P13, P14, P15, P16, P17.*
3. **V3** – Meta/TikTok-Ads-Anbindung, performance-gewichtetes Scoring, Reporting-Dashboard. *P18, MCP-Server.*

**Bild-Strang (Einstieg & Wachstum)**

1. **B1** – Modelle anlegen (Person, Produkt, Kulisse), Post als Slot-Rezept erstellen, Bilderkette, ein festes Bildmodell. *P7, P22.*
2. **B2** – Feed: veröffentlichen, browsen nach Nische, **Kopieren** mit Slot-Chips. *P19, P21.* Feed-Score zunächst nur aus In-App-Signalen.
3. **B3** – **Ordner** mit Scores pro Ordner, Import beim Kopieren, KI-Ordner-Vorschlag. *P20.* Ab hier greifen Bild- und Video-Strang ineinander.
4. **B4** – Social-Account-Anbindung (organische Reichweite), Feed-Score mit ×2-Gewichtung, Moderation.

> **Abhängigkeit:** B3 setzt die Auftrennung von `attributes` in `attribute_scores` voraus. Diese Änderung sollte **vor** dem Video-MVP passieren – nachträglich eine Scope-Dimension in eine gefüllte Score-Tabelle einzuziehen ist deutlich teurer.

---

## 13. Was bereits existiert (Arbeitsstand)

| Datei | Inhalt | Reife |
|---|---|---|
| `konzept-ki-video-ads.md` | Gesamtkonzept Video, 12 Kapitel | ✅ durchdacht, v1 |
| **`konzept-bilder-feed.md`** | **Bild-Modus, Feed, Kopieren, Ordner, Feed-Score** | ✅ **neu – Konzept steht, 8 offene Punkte markiert** |
| `datenbank-aufbau.md` | Appwrite-Schema, alle Tabellen | ✅ umsetzungsreif · **um Bild-Modus erweitert, `attributes` aufgetrennt** |
| `prompt-inventar.md` | 22 Denk-Punkte P1–P22 mit In/Out | ✅ vollständig kartiert · **P19–P22 neu** |
| `prompt-templates-research.md` | Deep Research, ~25 Quellen, Vorlagen-Mapping | ✅ Recherche abgeschlossen · **deckt P19–P22 noch nicht ab** |
| `fragenkatalog-onboarding.md` | 3-stufiges Onboarding | ✅ fertig · **Nische als 6. Pflichtfrage ergänzt** |
| `prototyp-app.html` | Klickbarer Textprototyp: alle Screens vom Onboarding bis Dev-Modus | ⚠️ **Video-Flow steht – Feed, Kopier-Screen und Ordner fehlen** |

**Noch nicht geschrieben:** die eigentlichen Prompt-Texte (P1–P22). Recherchierte Vorlagen liegen für **P5/P8, P7, P9 und P16** bereit (§8), für alle übrigen – inklusive P19–P22 – noch nicht. Ebenfalls offen: Code, UI-Design, Preismodell im Detail, Name, Prototyp-Screens für den Bild-Modus.

---

## 14. Naheliegende nächste Schritte

1. **P5/P8-Kern schreiben** (Wan-Rewriter-Struktur + unsere Slots) und die 3–4 Modell-Adapter daraus ableiten – das ist der Kern des Produktversprechens.
2. **P9 (Video-Tagger)** mit Enum-Schema + Code-Validator festlegen – ohne saubere Tags lernt die KB nichts.
3. **P7 auf Slot-System umbauen** (bestehender Prompt) – trägt jetzt doppelt, weil er auch der Generator des Bild-Modus ist.
4. **Appwrite aufsetzen** und das Schema aus `datenbank-aufbau.md` anlegen – **inklusive `attribute_scores`-Auftrennung von Anfang an** (siehe Abhängigkeit in §12).
5. **Elo-Function implementieren** (deterministisch, gut testbar – guter erster Code), scope-bewusst.
6. **Nischen- und Typ-Tag-Enums festlegen** – blockiert P19, P22 und die Kopier-Kompatibilität.
7. **Bildmodell auswählen** – Kriterium ist Multi-Referenz-Komposition (Person + Produkt + Kulisse konsistent), nicht reine Bildqualität.
8. **Prototyp erweitern:** Feed, Post-Detail, Kopier-Screen mit Slot-Chips, Ordner-Ansicht, Ordner anlegen (zwei Schalter).
9. Entscheidungen nachziehen: Name, Preisstufen **für beide Zielgruppen**, Ads- **und Social-**API-Anträge starten.

---

## 15. Bild-Modus, Feed & Ordner (Zusammenfassung)

**Vollständiges Konzept: `konzept-bilder-feed.md`.** Hier nur, was man kennen muss, um den Rest des Dokuments richtig zu lesen.

### Der Post

Ein Post ist **kein Freitext-Prompt, sondern ein Slot-Rezept** – nur deshalb ist er überhaupt kopierbar: `Format` (1:1 / 4:5 / 9:16) · `Kulisse` · `Modelle` (Person, Produkt) · `Licht / Kamera / Farbe` · `Werbetext` · `Nische`.

Dazu eine **Bilderkette**: mehrere Bilder, über die nur **Position und Winkel** variieren. Modelle, Kulisse, Licht, Farbe und Text bleiben konstant. Das **Text-Overlay ist ein eigenes Bild** in der Kette, keine Ebene auf dem Motiv – so lässt sich der Text tauschen, ohne die Motive neu zu generieren.

Veröffentlichen ist ein **aktiver Schritt**; Standard ist privat.

### Kopieren

Der Original-Prompt wird analysiert (P19) und als **vereinfachte Chips** dargestellt: „Kulisse: Badezimmer, Morgenlicht", „Modell: kleine Kerze". Der Kopierer ersetzt die **Modell-Chips durch eigene** – Pflicht, nie die fremden – und kann Kulisse, Licht, Kamera, Farbe übernehmen oder ändern. Der Werbetext wird von der KI neu geschrieben (P21).

**Die kritische Grenze:** Der Kopier-Screen zeigt die Abstraktion, **nie den Prompt im Wortlaut**. Sonst wandert die Knowledge Base fremder Brands nach außen – gegen §4 und §9.

**Modelle werden nie geteilt.** Produkt-Modelle bilden echte Markenprodukte ab (Marken-/Designrecht); geteilte Personen-Modelle entwerten die Konsistenz. Fremde Modelle erscheinen nur als Beschriftung.

### Ordner

Ein Ordner ist ein **privater Wissens-Scope**. Attribut-Scores werden **je Attribut je Ordner** geführt (`attribute_scores`). Beim Generieren zieht P4 nur die Attribute des gewählten Ordners – ein Ordner **überschreibt** die brand-weite Ebene vollständig, es wird nicht gemischt.

Er nimmt **eigene und fremde** Posts auf, ein Post darf in mehreren Ordnern liegen, und er wird **vor** der Generierung gewählt. Zwei Schalter beim Anlegen:

- **Zweck:** `sammlung` (nur kategorisieren) · `wissens_scope` (aus ihm heraus erstellen)
- **Startwerte:** `erben` (Kopie der brand-weiten Scores) · `aus_posts` (nur was in den gesammelten Posts steckt)

> **Warum das der wichtigste neue Baustein ist:** Der Feed erzeugt Konvergenz – alle kopieren dieselben Top-Posts, alle Ads sehen gleich aus. Der Ordner **segmentiert das Wissen, statt es zu mitteln**: statt eines Durchschnitts entstehen mehrere konkurrierende Wissensinseln. Damit kann man sich bewusst gegen einen Hype stellen, statt in ihm zu verschwinden.

### Feed-Score – nicht Elo

| | Elo (Knowledge Base) | Feed-Score |
|---|---|---|
| Rankt | Attribute | Posts **und** Modelle (getrennt) |
| Scope | pro Brand, **jetzt zusätzlich pro Ordner** | global, gefiltert nach Nische |
| Sichtbar | nein | ja |
| Mathematik | echtes Elo (Paarvergleich, K-Faktor) | gewichtete Summe + Zeit-Decay |
| Signale | Vote, gezielte Frage, Ad-Performance, LLM-Vergleich | Views ×0,1 · Likes ×0,5 · **Kopien ×1** · Social-Reichweite ×2 |

**Elo braucht Duelle; im Feed wird summiert.** Beides „Elo" zu nennen rächt sich im Code – deshalb getrennte Namen, Tabellen und Functions. Dazu drei Pflicht-Korrekturen: **Zeit-Decay**, **Explorations-Slot** für neue Posts, **Manipulationsschutz**.

### Kopplung zur Knowledge Base

1. **Import beim Kopieren:** Die Slots landen sofort als Attribute in der eigenen KB (Scope = gewählter Ordner). Das ist die Antwort auf den Kaltstart.
2. **Rückfluss nach Veröffentlichung:** Läuft ein Post gut, steigen die beteiligten Attribute – **×0,3**. Bewusst niedrig, weil Reichweite auch am Posting-Zeitpunkt liegen kann.

*Diese Kopplung ist noch nicht final bestätigt – siehe `konzept-bilder-feed.md` §10.*