videogen/planung/projekt-uebersicht.md

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.