videogen/planung/konzept-bilder-feed.md

# Bild-Modus, Feed & Ordner – Konzept

**Stand:** 25. Juli 2026
**Verhältnis zur bestehenden Doku:** Erweiterung von `projekt-uebersicht.md`. Der dort beschriebene Video-Loop bleibt **unverändert bestehen**. Dieses Dokument beschreibt einen **zweiten, entkoppelten Produktteil**, der daneben läuft und an genau drei definierten Stellen andockt (Ordner-Scope, KB-Import, gemeinsame Modelle).

---

## 1. Warum überhaupt ein zweiter Modus

Der Video-Loop hat zwei Probleme, die im Konzept offen stehen (`projekt-uebersicht.md` §11):

1. **Kaltstart.** Runde 1 startet ohne Wissen. Die Knowledge Base wird erst durch Votes und Ad-Performance nützlich – also nachdem Geld ausgegeben wurde.
2. **Einstiegshürde.** Video ist teuer (>90 % der Betriebskosten) und setzt eine Brand mit Ad-Budget voraus.

Bilder lösen beides: Sie sind um Größenordnungen billiger, brauchen keine große Knowledge Base und öffnen das Produkt für eine breitere Nutzergruppe (Creator, kleine Labels, Privatnutzer). Der Feed liefert zusätzlich fertige Rezepte – man startet nicht bei null, sondern bei etwas, das nachweislich funktioniert.

**Der Bild-Modus ist bewusst entkoppelt:** kein Wettbewerb mehrerer KI-Modelle, kein Vote-Loop, ein festes Bildmodell. Er ist der günstige Einstieg, nicht das Kernprodukt. Wer den Lern-Loop will, geht auf Video.

---

## 2. Anatomie eines Posts

Ein Post ist **kein Freitext-Prompt**, sondern ein **Slot-Rezept**. Das ist die zentrale Designentscheidung – nur weil ein Post aus benannten Slots besteht, ist er überhaupt kopierbar.

| Slot | Inhalt | Beim Kopieren |
|---|---|---|
| **Format** | 1:1 · 4:5 · 9:16 | deterministisch übernommen – kein LLM nötig |
| **Kulisse** | Umgebung als eigenes Modell (siehe §3) | eigenes Modell einsetzen |
| **Modelle** | Person und/oder Produkt | **immer eigene** – nie die des Erstellers |
| **Licht / Kamera / Farbe** | Attribute, wie im Video-Teil | übernehmen oder ändern |
| **Werbetext** | Text-Overlay | wird von der KI neu geschrieben (siehe §7) |
| **Nische** | Branche des Posts | bestimmt Kompatibilität (siehe §4) |

Zusätzlich gehört zum Post: die **Bilderkette** (§5) und – nach Veröffentlichung – der **Feed-Score** (§8).

### Warum Slots und nicht Freitext

Ein kopierter Freitext-Prompt wäre für den Kopierer eine Blackbox: Er sieht Wörter, weiß aber nicht, welches Wort welchen Bildteil steuert, und kann gezielt nichts austauschen. Slots machen das Rezept lesbar und teilbar, ohne dass der Original-Prompt offengelegt werden muss.

---

## 3. Modelle

**„Modell" bedeutet in diesem Projekt durchgehend das Asset (Person, Produkt, Kulisse) – nicht das KI-Modell** (Seedance, Veo, Sora). Diese Sprachregelung gilt für die gesamte Doku und den Code.

### Die Typen, einzeln tauschbar

| Typ | Was es ist | Beispiel |
|---|---|---|
| **Person** (DB: `gesicht`) | KI-generiertes Gesicht/Körper, konsistent über Posts | die Person, die das Produkt hält |
| **Produkt** | Das eigene Produkt, konsistent abgebildet | „kleine Kerze" |
| **Kulisse** | Umgebung/Location als eigenständiges Asset – **neu** | Badezimmer, Betonstudio, Strand |
| **Logo** | wie bisher, kein Post-Slot – wird über Regeln eingebunden | |

Die drei erstgenannten sind die **Post-Slots**. Das Logo bleibt wie im Video-Teil ein Asset ohne eigenen Slot.

Das System komponiert daraus ein Bild: *Person hält Produkt in Kulisse.* Jeder Teil ist einzeln austauschbar – das ist die Voraussetzung dafür, dass Kopieren funktioniert.

> **Technischer Hinweis:** Multi-Referenz-Komposition (drei Assets in einem Bild, alle konsistent) ist der anspruchsvollste Teil des Bild-Modus. Die Erkenntnisse aus `prompt-templates-research.md` gelten hier direkt: 4–6 Referenzbilder pro Asset, Identity-Lock am Anfang **und** Ende des Prompts, Token-Locking (Merkmale wörtlich speichern und wörtlich wiederverwenden).

### Modelle werden nie geteilt

Ein Kopierer bringt **immer seine eigenen Modelle mit**. Das ist keine Bequemlichkeitsfrage, sondern rechtlich zwingend:

- **Produkt-Modelle** bilden echte Markenprodukte ab. Ein fremdes Produkt-Modell zu übernehmen und damit zu werben ist Marken- und Designrecht – nicht nur eine Hausregel.
- **Personen-Modelle** sind zwar KI-generiert (Standard nach `projekt-uebersicht.md` §10), aber ein geteiltes Gesicht über viele Brands hinweg entwertet die Konsistenz, die das Feature erst wertvoll macht.
- Es passt außerdem zur bestehenden Regel **„Referenzen nie 1:1 kopieren"**.

Der Kopierer sieht die fremden Modelle nur als **Beschriftung** („Modell: kleine Kerze"), um zu verstehen, was das Rezept braucht – nicht als nutzbares Asset.

---

## 4. Nischen und Slot-Kompatibilität

Ein Autohaus will keine Werbung im Stil eines Kosmetikstudios. Deshalb sind Posts und Modelle zweifach kategorisiert:

- **Nische** – feste Branchenliste (Kosmetik, Auto, Gastro, Fitness, Mode, …), am Post und am Modell. Filtert den Feed.
- **Modell-Typ-Tags** – was das Modell konkret zeigt (Fahrzeug, Getränk, Tube, Person weiblich, Innenraum, …).

**Kompatibilitätsregel beim Kopieren:** Ein Slot akzeptiert nur Modelle mit passendem Typ-Tag. Ein Post, dessen Produkt-Slot ein Fahrzeug enthält, nimmt kein Lippenstift-Modell an – die Komposition (Größenverhältnis, Handhaltung, Perspektive) würde nicht funktionieren.

**Enum-Zwang.** Nischen und Typ-Tags sind feste Listen, keine freie KI-Vergabe. Das folgt derselben Logik wie beim Video-Tagger (`projekt-uebersicht.md` §8: Enum-Zwang ist „the highest-leverage decision", doppelte Absicherung durch Prompt-Regel **und** Code-Validator). Ohne feste Liste driften die Kategorien und die Kompatibilitätsprüfung wird wertlos.

---

## 5. Die Bilderkette

Ein Post besteht aus mehreren Bildern (Karussell). Über die Kette hinweg gilt:

- **Was variiert:** Position und Winkel des Motivs
- **Was konstant bleibt:** Modelle, Kulisse, Licht, Farbe, Werbetext

Das **Text-Overlay ist ein eigenes Bild** in der Kette – nicht eine Textebene auf einem Motivbild. Das hat einen praktischen Vorteil: Der Text lässt sich austauschen, ohne die Motive neu zu generieren.

Format gilt für die gesamte Kette, nicht pro Bild.

---

## 6. Post erstellen – Ablauf

```
Modell(e) vorhanden?
   nein → Modell anlegen (Person / Produkt / Kulisse)
   ja   ↓
Ordner wählen        ← bestimmt, welches Wissen injiziert wird (§9)
   ↓
Format wählen (1:1 / 4:5 / 9:16)
   ↓
Slots füllen (Kulisse, Modelle, Licht/Kamera/Farbe) + Werbetext
   ↓
Generierung (ein festes Bildmodell, keine Auswahlrunde)
   ↓
Bilderkette prüfen
   ↓
privat behalten  ODER  aktiv veröffentlichen → Feed
```

**Modell zuerst**, wenn noch keins existiert. Wer schon Modelle hat, steigt direkt beim Ordner ein.

**Veröffentlichen ist aktiv.** Standard ist privat. Nur wer bewusst „Teilen" drückt, landet im Feed. Das ist bei einer offenen Nutzerbasis (Creator und Privatnutzer, nicht nur zahlende Brands) auch datenschutzrechtlich die einzig vertretbare Voreinstellung.

---

## 7. Kopieren

Der Kern des Feeds. Ablauf:

1. Nutzer sieht einen Post und drückt **Kopieren**.
2. Das System analysiert den zugrundeliegenden Prompt und stellt ihn **vereinfacht als befüllte Chips** dar: `Kulisse: Badezimmer, Morgenlicht` · `Modell: kleine Kerze` · `Licht: weich von der Seite` · `Kamera: Nahaufnahme, leicht von oben` · `Format: 4:5`.
3. Der Nutzer ersetzt die **Modell-Chips durch eigene** (Pflicht, §3). Kulisse, Licht, Kamera, Farbe kann er übernehmen oder ändern.
4. Der **Werbetext wird von der KI neu geschrieben** – im Stil des Originals, aber auf Basis des eigenen Produkts. Der fremde Text wird nie übernommen; fremde Claims und Markennennungen kämen sonst ungeprüft in den eigenen Post.
5. Textliches Nachschärfen ist jederzeit möglich.
6. Generierung wie in §6.

**Was der Kopierer nie sieht:** den Original-Prompt im Wortlaut, die Attribut-Scores des Erstellers, dessen Regeln oder Dev-Modus-Inhalte. Die vereinfachte Slot-Darstellung ist eine **Abstraktion, keine Offenlegung** – damit bleibt das Betriebsgeheimnis aus `projekt-uebersicht.md` §4/§9 gewahrt.

**Kopieren erzeugt ein Signal:** Jede Kopie zahlt auf den Feed-Score des Originals ein (§8).

---

## 8. Feed-Score

> **Wichtig – begriffliche Abgrenzung:** Der Feed-Score ist **kein Elo**. Elo setzt Duelle voraus: zwei Kandidaten treten an, einer gewinnt, Punkte wandern vom Verlierer zum Gewinner. Im Feed duelliert nichts – Kopien, Likes und Reichweite sind aufsummierte Zähler. Beide Systeme „Elo" zu nennen rächt sich spätestens im Code. **Elo = brand-interne Attribute. Feed-Score = öffentliches Feed-Ranking.**

### Was gerankt wird

**Post und Modell getrennt.** Ein Post hat einen eigenen Score. Jedes darin verwendete Modell sammelt zusätzlich Punkte über alle seine Posts hinweg. Damit lassen sich Top-Posts **und** Top-Modelle browsen – „ich suche eine gute kleine Kerze" wird zu einer eigenen Sucherfahrung.

### Signale, gewichtet

| Quelle | Signal | Gewicht |
|---|---|---|
| In-App | Views | ×0,1 |
| In-App | Likes | ×0,5 |
| In-App | **Kopien** | ×1 |
| Verbundene Social-Accounts | echte Reichweite des veröffentlichten Posts | ×2 |

Das **Prinzip** entspricht der Gewichtung im Elo-System (`projekt-uebersicht.md` §5): schwache Signale sind sofort verfügbar, starke überschreiben sie später. Die **Zahlen sind bewusst andere** – ×0,1 und ×0,5 existieren im Elo-System nicht, weil es dort keine Views und Likes gibt. In-App-Signale starten das Ranking; verbundene Accounts korrigieren es mit echter Reichweite.

**Kopien wiegen mehr als Likes** – ein Like ist eine Meinung, eine Kopie ist eine Handlung mit Aufwand.

### Drei Korrekturen, ohne die das Ranking kippt

1. **Zeit-Decay.** Ohne Verfall gewinnt immer das Älteste, weil es am längsten sammeln konnte. Der Score verfällt exponentiell (Halbwertszeit als Parameter, Startwert 30 Tage).
2. **Explorations-Slot.** Ein fester Anteil der Feed-Positionen ist für neue Posts reserviert. Sonst bekommt nur, wer oben steht, Views – und wer Views bekommt, bleibt oben. Neue Posts kämen nie hoch.
3. **Manipulationsschutz.** Globale Sichtbarkeit erzeugt Anreiz für Fake-Signale. Mindestens: Rate-Limits pro Konto, Signale nur von verifizierten Konten voll gewichtet, Ausreißer-Erkennung. Bei den brand-internen Scores war das kein Thema – hier ist es eins.

---

## 9. Ordner

Das ist der wichtigste neue Baustein – und die Antwort auf ein Problem, das der Feed selbst erzeugt.

### Das Problem

Wenn alle die Top-Posts kopieren, wandern dieselben Attribute in alle Knowledge Bases. Alle Ergebnisse konvergieren, jede Werbung sieht gleich aus – und der Moat („dein Wissen ist einzigartig") wird wertlos.

### Die Lösung: Wissen segmentieren statt mitteln

Ein Ordner ist ein **Wissens-Scope**. Attribut-Scores werden **je Attribut je Ordner** geführt. Beim Generieren zieht der Knowledge-Selector nicht mehr die brand-weiten Top-Attribute, sondern **nur die des gewählten Ordners**. Der neue Post trägt damit den Vibe der Sammlung – nicht den Durchschnitt des Feeds.

„Warmes Abendlicht" kann im Ordner *Sommerkampagne* auf 6800 stehen und im Ordner *Dark Studio* gar nicht existieren. Statt eines Durchschnitts entstehen mehrere konkurrierende Wissensinseln nebeneinander.

### Eigenschaften

| | |
|---|---|
| **Sichtbarkeit** | privat pro Brand – Ordner sind kein soziales Objekt |
| **Inhalt** | eigene **und** fremde Posts aus dem Feed (wie ein Moodboard) |
| **Mehrfachablage** | ein Post darf in mehreren Ordnern liegen |
| **Wahl** | **vor** der Generierung – nur so kann das Theme-Wissen in den Prompt |
| **Einsortierung** | KI schlägt beim Speichern einen bestehenden Ordner vor oder bietet an, einen neuen mit passendem Theme anzulegen |

**Fremde Posts zählen voll.** Wissen entsteht damit durch *Sammeln*, nicht erst durch Ausgeben – der Ordner ist sofort nach dem Anlegen nützlich. Risiko, bewusst in Kauf genommen: Ein Ordner kann Attribute hoch bewerten, die für die eigene Zielgruppe nie getestet wurden. Die Korrektur passiert über eigene Ergebnisse mit der Zeit.

### Zwei Schalter beim Anlegen

**1. Zweck**

| Wert | Bedeutung |
|---|---|
| `sammlung` | reines Kategorisieren. Kein Score, kein Einfluss auf Generierung. |
| `wissens_scope` | aus dem Ordner heraus wird erstellt. Attribut-Scores werden geführt. |

**2. Startwerte** (nur bei `wissens_scope`)

| Wert | Bedeutung | Wann sinnvoll |
|---|---|---|
| `erben` | Ordner startet als Kopie der brand-weiten Scores und driftet mit jedem Signal davon weg | Der Ordner verfeinert die bestehende Ästhetik – z. B. „Sommerkampagne" innerhalb derselben Bildsprache |
| `aus_posts` | Nur was in den gesammelten Posts steckt, existiert im Ordner. Startwert = Kategorie-Ø **innerhalb des Ordners** | Der Ordner soll bewusst **anders** sein als das Bestehende |

> **Warum die Wahl wichtig ist:** Bei einem Ordner, der bewusst gegen die eigene Historie steht, arbeitet `erben` aktiv gegen den Zweck. Beispiel: brand-weit steht `warmes-abendlicht` auf 6800 und `hartes-direktlicht` auf 3100. Ein neuer Ordner „Dark Studio" mit vier gesammelten Posts würde bei `erben` trotzdem warmes Abendlicht injizieren – es bräuchte rund 15 Signale, um 6800 zu überholen. Bei `aus_posts` existiert warmes Abendlicht im Ordner gar nicht und der Vibe stimmt ab dem ersten Post.

### Ordner-Kaltstart

Ein frisch angelegter Ordner ist **sofort nutzbar** – keine Mindestanzahl an Posts. Ein Ordner entsteht genau in dem Moment, in dem jemand etwas Bestimmtes will; ihn dann zu sperren, bestraft die Absicht.

Die statistische Schwäche (bei vier Posts ist die *Rangfolge* innerhalb des Ordners kaum belastbar, auch wenn die *Richtung* stimmt) wird über den **K-Faktor** aufgefangen, nicht über eine Sperre: K bleibt hoch (32), solange der Ordner dünn ist, und sinkt Richtung 8, wenn genug Signale da sind. Das ist exakt die Regel aus `projekt-uebersicht.md` §5 – „Unsicherheit steckt im K-Faktor" – nur auf Ordner-Ebene angewandt.

Die UI zeigt den Reifegrad offen an: *„4 Posts – dieser Ordner lernt noch."*

### Zwei Wissensebenen

Die brand-weite Ebene bleibt bestehen und dient als Basis für Generierung **ohne** Ordner. Wird ein Ordner gewählt, **überschreibt** er sie vollständig – es wird nicht gemischt. Mischen würde genau die Abgrenzung verwässern, für die der Ordner existiert.

---

## 10. Kopplung Feed ↔ Knowledge Base

**Gewählt: Import + Rückfluss.**

1. **Import beim Kopieren.** Die Slots des kopierten Posts werden sofort als Attribute in der eigenen KB angelegt – Startwert nach Ordner-Regel (§9). Die KB ist damit nicht mehr leer, bevor der erste Euro ausgegeben wurde. Das ist die direkte Antwort auf das Kaltstart-Risiko aus `projekt-uebersicht.md` §11.
2. **Rückfluss nach Veröffentlichung.** Läuft ein Post gut, steigen die beteiligten Attribute in der eigenen KB – **gewichtet ×0,3**. Bewusst niedrig: Reichweite kann am Posting-Zeitpunkt, an Hashtags oder am Zufall liegen, nicht am Licht. Dieselbe Skepsis wie bei einer bestätigten Favoriten-Wahl (§5 der Übersicht).

Die Konvergenz-Gefahr, die der Import mit sich bringt, wird durch die Ordner-Segmentierung (§9) aufgefangen: Importiertes Wissen landet im Scope des jeweiligen Ordners, nicht in einem gemeinsamen Topf.

> **Zu prüfen:** Diese Kopplung ist im Gespräch als „gut" bewertet, aber nicht ausdrücklich gegen die Alternativen (nur Rückfluss / strikt getrennt) final bestätigt worden. Vor der Umsetzung noch einmal explizit entscheiden.

---

## 11. Die zwei Systeme im Überblick

| | **Elo (Knowledge Base)** | **Feed-Score** |
|---|---|---|
| Rankt | Attribute (licht, kamera, location …) | Posts und Modelle |
| Scope | pro Brand, jetzt zusätzlich **pro Ordner** | global über alle Nutzer, gefiltert nach Nische |
| Sichtbar für Nutzer | nein | ja – das ist der Zweck |
| Mathematik | echtes Elo (Paarvergleich, K-Faktor, Skala 0–10.000) | gewichtete Summe + Zeit-Decay |
| Signale | Vote, gezielte Frage, Ad-Performance, LLM-Vergleich | Views, Likes, Kopien, Social-Reichweite |
| Manipulationsrisiko | gering (intern) | hoch (global sichtbar) |
| Zweck | Prompts anreichern | Feed sortieren |

---

## 12. Rechtliches – was neu dazukommt

Ergänzend zu `projekt-uebersicht.md` §10:

- **Öffentlicher Feed = nutzergenerierte Inhalte.** Damit werden Melde- und Moderationspflichten relevant (DSA), die beim geschlossenen B2B-Produkt nicht galten.
- **Kennzeichnung KI-generierter Inhalte** (EU AI Act) gilt für Bilder genauso wie für Videos – im Feed sichtbar, nicht nur beim Export.
- **Modelle werden nie geteilt** (§3) – das entschärft Marken-, Design- und Persönlichkeitsrecht an der Wurzel, statt es über AGB weiterzureichen.
- **Breitere Nutzerbasis** (Creator, Privatnutzer) heißt: Minderjährigenschutz und Altersgrenzen müssen geklärt werden. Beim reinen B2B-Produkt war das kein Thema.
- **Social-Account-Anbindung** für organische Reichweite braucht eigene App-Reviews bei Meta/TikTok – zusätzlich zu den Ads-Berechtigungen. Laut Übersicht §10 früh beantragen, die Verfahren dauern.

---

## 13. Was sich in der bestehenden Doku ändert

| Datei | Änderung |
|---|---|
| `datenbank-aufbau.md` | `attributes` wird aufgetrennt (Scores wandern nach `attribute_scores`, je Ordner) · neue Tabellen `folders`, `posts`, `post_images`, `post_folders`, `post_metrics` · `assets.typ` um `kulisse`, neue Spalte `assets.typ_tags` · `score_events.folder_id` · Nischen-Felder · `prompt_templates.key` bis P22 · neue Functions · Bucket `generated-images` |
| `prompt-inventar.md` | vier neue Denk-Punkte P19–P22 |
| `projekt-uebersicht.md` | neues Kapitel, aktualisierte Risiken und Roadmap |
| `fragenkatalog-onboarding.md` | Nische als Pflichtfrage |
| `prototyp-app.html` | **noch nicht angefasst** – Feed, Post-Detail, Kopier-Screen, Ordner-Ansicht fehlen |

---

## 14. Offene Punkte

| # | Punkt | Warum es zählt |
|---|---|---|
| 1 | **Welches Bildmodell** | Multi-Referenz-Komposition (Person + Produkt + Kulisse konsistent) ist das entscheidende Auswahlkriterium, nicht die reine Bildqualität |
| 2 | **Preismodell** | €150–300/Brand/Monat passt nicht zu Creator- und Privatnutzern. Der Bild-Modus braucht eine eigene, deutlich niedrigere Stufe – oder ein Freemium-Modell mit Kontingent |
| 3 | **Nischen-Liste final** | Welche Branchen, wie granular, und was passiert bei Nutzern, die in keine passen |
| 4 | **Modell-Typ-Tags final** | Die Enum-Liste, gegen die die Slot-Kompatibilität geprüft wird |
| 5 | **Feed-Score-Parameter** | Halbwertszeit des Decay, Größe des Explorations-Slots, konkrete Gewichte |
| 6 | **Moderation** | Wer prüft veröffentlichte Posts, und wann – vorab oder auf Meldung |
| 7 | **Kopplung final bestätigen** | siehe §10 |
| 8 | **Prototyp** | Die neuen Screens sind noch nicht klickbar |