Iteration 1 — Lieferumfang

Home-Bildschirm + Burger-Menü, Android-only. Produktionsreifer Android-Build mit allem unten gelisteten Scope. iOS und Web folgen in späteren Iterationen — die Design-System-Spezifikation ist plattform-unabhängig formuliert und dient als kanonische Referenz für diese späteren Iterationen.

Plattform
Android (Produktion)
Folge-Iterationen
iOS · Web (siehe Design System)
Komponenten in Scope
8 (siehe unten)
Branch
082-complete-the-3
Design-System-Referenz
design-system.html
Token-API
figma/resolved
Composition-API
/v1/page/home

Live-Composition-Payload (Stand jetzt)

Dies ist exakt, was https://page-api.beta.bibeltv.de/v1/page/home heute zurückliefert. Daraus leitet sich der Iteration-1-Scope ab — was die Payload nicht anfordert, muss in Iteration 1 nicht ausgeliefert werden, auch wenn die Komponente im Design-System-Vertrag spezifiziert ist.

5 Komponenten in dieser Reihenfolge:
  1. slider_hero mit 2 card_hero_media-Slides
  2. group_button mit 1 Button "Die Bibel erkunden" (Single-Item-AI-CTA-Modus)
  3. slider mit 3 card_poster_small-Karten
  4. slider mit 3 card_poster_medium-Karten
  5. slider mit 3 card_poster_small-Karten

Komponenten in Iteration 1

● voller Vertrag (alles im Design-System bauen) ◐ Teilumfang (nur bestimmte Modi/Zustände) ○ deferred (Platzhalter oder leer)

TopBar Voller Vertrag. Logo (SVG) + Cast-Icon + Konto-Icon. Scroll-Fade von transparent zu opak.
Design System →
HeroCarousel Voller Vertrag. Virtuelles Paging, Auto-Advance, Color-Emit. PageIndicator inkludiert.
Design System →
HeroVideoCard (card_hero_media) Voller Vertrag. Mobile (3:4 Portrait) + Tablet (~2.54:1 Landscape, 3-Schichten-Komposition). Dynamische Title-Schriftgröße, Badge, CTA "Jetzt ansehen".
Design System →
HeroBibleVerseCard Deferred auf nächste Iteration. Im aktuellen Home-Payload nicht enthalten. Im Karussell-Slider rotiert sie als Platzhalter, bis die volle Spezifikation nachgeliefert wird.
Design System →
ButtonGroupSection — nur Single-Item-AI-CTA-Modus Aktuelle Payload sendet nur 1 Button ("Die Bibel erkunden"). AI-Gradient + auto_awesome-Leading-Icon. Tap-Ziel: KI-Bibelaufschlag-Modal (existiert in Produktion, nicht neu bauen). Default-Modus + Overflow-Modus + gestyltes Dropdown sind im Design-System voll spezifiziert, werden in Iteration 1 aber nicht aktiviert.
Design System →
RowSection (nur mit CardPoster) Voller Vertrag für die POSTER_PORTRAIT-Variante. Horizontale LazyRow, ~1.5 Karten Mobile-Peek. Andere Karten-Varianten (Landscape, Top10, Avatar, Split, Overlay) im Design-System spezifiziert aber nicht im Scope.
Design System →
CardPoster (S / M / L) Voller Vertrag. Drei Größen-Tiers, optionaler Fortschrittsbalken (Vertrag: hide bei 0/null/100), Fallback bei fehlendem Bild.
Design System →
MenuDrawer (Burger-Menü) Voller Vertrag. 14 Nav-Zeilen (fest), Anmelden-CTA, Mobile-Vollbild-Overlay + Tablet-380dp-Seitenpanel. Halbtransparentes Panel mit Backdrop-Blur (siehe semantic.effect.backdropBlur). Prototyp-Toggles NICHT bauen — out of scope.
Design System →

Infrastruktur — Token-Sync (Android, bereits implementiert)

Was Iteration 1 ausliefert (nicht nur Komponenten): die Token-Sync-Pipeline ist auf Android bereits voll implementiert und Teil des Iteration-1-Builds. Pattern siehe Design System → Token-Sync-Verhalten.

  1. Single-Bundle-API: App ruft GET /api/v1/tokens einmal ab, erhält den vollständigen Layered-Payload (primitives + semantic + component + views).
  2. Lokale Persistenz: Payload wird in Android DataStore unter token_json gespeichert, ETag separat unter token_etag.
  3. Offline-First-Coldstart: beim App-Start werden die persistierten Tokens geladen und über bundled Defaults gelegt — App funktioniert vollständig ohne Netzwerk auf wiederholten Starts.
  4. Hintergrund-Sync: WorkManager-basiert (TokenSyncWorker.kt) plus In-Foreground-Sync direkt nach Coldstart. ETag-basiert: 304 = nichts tun, 200 = persistieren + StateFlow update + Compose rekomponiert.
  5. Graceful Degradation: Netzwerkfehler werden geloggt, nie crashen, nie Tokens clear-en — bestehende lokale Tokens bleiben aktiv.

iOS und Web in Folge-Iterationen müssen dieses Verhalten replizieren (ETag-Caching, Offline-First, Single-Bundle). Plattform-Idiome unterscheiden sich (UserDefaults / localStorage / Service Worker), aber der Vertrag ist identisch.

Explizit NICHT in Iteration 1

Komponenten, die im Code existieren oder im Design-System spezifiziert sind, aber in Iteration 1 NICHT angefordert werden:

Bekannte Implementierungs-Gaps (Android)

Punkte, die im Android-Quellcode noch nicht korrekt sind und vor Iteration-1-Launch geschlossen werden müssen. Diese sind keine Spezifikationslücken — der Vertrag im Design-System ist klar — sondern Implementierungs-Drift im Android-Code, die vor Produktion behoben werden muss. Späteren iOS/Web-Iterationen werden NICHT diesen Android-Code als Vorlage nehmen, sondern direkt das Design-System.

  1. AI-Button onClick — der AI-CTA-Button in ButtonGroupSection.kt:77 ruft generisch onNavigate(item.destination) auf. Vertrag: er MUSS die KI-Bibelaufschlag-Modal öffnen (die Modal existiert bereits in der Produktions-App). Vor Iteration-1-Launch verdrahten.

Querverweise

Design SystemVolle Komponentenspezifikation, alle Modi und Zustände, wachsend über Iterationen. Authoring-RegelnWie zukünftige Iterationen an diesem Doc arbeiten sollen. Live Composition PayloadWas die Produktions-API für die Home-View zurückgibt. Token APIDesign-Tokens für den Figma-Plugin-Pull.