# 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 | **Zwei Anbieter, klar getrennt:** **OpenRouter** für LLM *und* Bild · **BytePlus ModelArk** für Video |
| LLM | Claude (Scripts, Vergleiche) · Gemini für P9 – **beides über OpenRouter**, Gemini dort mit nativem Video-Input |
| Bildmodelle | **noch offen** – Kandidaten für den Test vor E6: `google/gemini-3-pro-image`, `openai/gpt-5-image` (OpenRouter) und `seedream-5-0-260128` (Ark **eu-west**, DSGVO-nah) |
| Videomodelle | **Seedance-Familie über BytePlus ModelArk** – `dreamina-seedance-2-5` / `-2-0` / `-2-0-fast` / `-2-0-mini` · `seedance-1-5-pro` · `seedance-1-0-pro` / `-pro-fast` |
| Payment | Stripe (Abo + metered) |

> **Warum zwei Anbieter statt einem Gateway:** OpenRouter hat **kein** Modell mit Video-*Output* (geprüft am 14.08.2026 über `/api/v1/models`, 411 Modelle, keines mit `output_modalities: video`). Video-*Input* und Bild-*Output* kann OpenRouter dagegen sehr wohl – deshalb läuft dort alles außer der Videogenerierung.
>
> **Ark-Regionen – Keys sind regionsgebunden, jeder Key funktioniert nur in seiner eigenen Region** (geprüft am 14.08.2026):
>
> | Region | Endpoint | Modelle | Video? |
> |---|---|---|---|
> | **ap-southeast** (Singapur) | `https://ark.ap-southeast.bytepluses.com/api/v3` | 42 aktiv | **ja – einzige Region mit Seedance** |
> | **eu-west** | `https://ark.eu-west.bytepluses.com/api/v3` | 5 aktiv (1× Bild `seedream-5-0`, 4× VLM) | **nein** |
> | cn-beijing | `ark.cn-beijing.volces.com` | – | weist BytePlus-Keys mit `AuthenticationError` ab |
>
> **Entscheidung:** Videogenerierung läuft über **ap-southeast**, weil die EU-Region keine Videomodelle anbietet. Der EU-Key bleibt für den Bildmodell-Test und als spätere Migrationsoption bestehen – falls BytePlus Seedance in eu-west ausrollt, ist der Wechsel eine Endpoint- und Key-Änderung, sonst nichts. **Deshalb gehören Endpoint und Key in die Konfiguration, nicht in den Code.**
>
> **Folge für den Vote-Loop:** Die 3–6 konkurrierenden Videos kommen jetzt aus **einer Modellfamilie in verschiedenen Generationen**, nicht mehr von verschiedenen Anbietern. Für die Elo-Attribution (§5) ist das eher ein Vorteil – bei konstanter Modellfamilie stammt der Unterschied zwischen zwei Videos aus den Attributen, nicht aus dem Modell. Verloren geht die Absicherung, dass ein anderer Anbieter bestimmte Motive besser trifft. Die Adapter für Veo/Sora/Wan bleiben deshalb in `prompts/` liegen (siehe §7) – sie sind ungenutzt, aber nicht gelöscht.

**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)
- **Drittlandtransfer BytePlus (Singapur)** – die Videogenerierung läuft über `ap-southeast`, weil die EU-Region keine Videomodelle hat (§9). Damit verlassen Prompt, Referenzbilder und generiertes Video die EU. Zu klären: AVV mit BytePlus inklusive **Standardvertragsklauseln**, Nennung in der Datenschutzerklärung, Aufnahme ins Verarbeitungsverzeichnis. **Entschärfend:** nach der Regel unten gehen ohnehin nur KI-generierte Gesichter raus – überwiegend Geschäfts-, keine biometrischen Personendaten. Alles außerhalb der Videogenerierung bleibt in der EU bzw. bei OpenRouter.
- **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**~~ – ✅ **entschieden am 15.08.2026: `google/gemini-3-pro-image`** (über OpenRouter). Der Multi-Referenz-Test ist bestanden: Person, Produkt und Kulisse als getrennte Modelle angelegt, freigegeben und in **einer** Szene komponiert – alle drei im Ergebnis erkennbar. Rund 0,14 $ je Bild, dazu ~0,01 $ für den P7-Prompt.

   **Zwei bekannte Schwächen:** Das Modell ignoriert das angeforderte Seitenverhältnis und liefert 1408×768 – die Formatwahl (1:1 / 4:5 / 9:16) in der App hat damit noch keine Wirkung. Und die Identität driftet zwischen Modell-Referenz und fertiger Szene sichtbar, weil Referenzbilder bisher **nicht** als Bild-Eingabe mitgehen, sondern nur als Merkmalstext. Beides ist nachrüstbar, keins blockiert.

   **Seedream bleibt die DSGVO-nähere Option** – sobald der Model Service im Ark-Konto freigeschaltet ist, lohnt der Gegentest: bei gleichwertigem Ergebnis bliebe der gesamte Bild-Strang in der EU.
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.*
