soulwise_persons
Albumeinträge. Indizes auf userId, status, deletedAt. Zuerst Soft-Delete; endgültige Löschung der personenbezogenen Daten nach 30 Tagen.
Cosmic Story v2 – die Architektur im Detail.
Für Ingenieure, PMs, Journalisten und Partnerschafts-Scouts. Die vollständige Pipeline, vier MongoDB-Collections, EDA-Events, die Strenge des V-Modells, Performance-Ziele, Sicherheit und Barrierefreiheit – alles auf einer Seite.
- Soulwise-story ist ein neues NestJS-Modul neben dem bestehenden cosmic-story-Modul. Keinerlei direkte Importe zwischen den Feature-Modulen.
- Vier MongoDB-Collections: soulwise_persons, soulwise_chapters, soulwise_journal_entries, soulwise_resonances. AES-256-verschlüsselte Inhalte, indexiert für die jeweils zugehörigen Abfragen.
- Asynchrone Generierung über eine BullMQ-Queue mit 28 s Timeout. Ereignisse werden über EventEmitter2 erst nach dem Datenbank-Commit ausgelöst — keine Phantom-Posteingangseinträge.
- V-Modell-Spezifikation: 119 Anforderungen, keine Lücken. Backend-Abdeckungsziel 85% Statement-Coverage auf Services; Frontend 90% auf Pinia-Stores.
Die Pipeline, noch einmal, mit technischem Detail
Jeder Schritt hat einen Service, einen Vertrag und ein Ereignis.
Auslöser
Eine Nutzeraktion – „heutiges Kapitel für Schwester erstellen“ – oder ein geplanter Cron-Job, etwa der Sonntags-Rückblick um 9 Uhr morgens oder die alle 6 Stunden erfolgende Wetteraktualisierung.
Warteschlange
Der Auftrag landet in einer BullMQ-Warteschlange namens soulwise-chapter-generation mit einem festen Timeout von 28 Sekunden. Lang laufende Aufträge werden abgebrochen und dem Nutzer als „erneut versuchen“ gemeldet.
Zusammenstellen
Der ChapterGenerationService fügt den Vier-Faktoren-Prompt – Personenkontext, Astrologie, Signal, Rhythmus – zu einer einzigen Eingabe zusammen. Keine rohen personenbezogenen Daten gelangen wörtlich in den Prompt; alles wird zuvor bereinigt.
Generieren
Ein KI-Anbieter wird über das Symbol-Token AI_GENERATION_ADAPTER aufgerufen — der Anbieter ist austauschbar. Die Antwort wird auf Länge, Form und Sicherheit geprüft, bevor es weitergeht.
Nachbearbeiten
Vier Dinge geschehen: Ein Krisen-Klassifikator prüft auf krisenbezogene Sprache; ein Aspekt-Chip-Extraktor zieht ein bis drei Astrologie-Chips heraus; ein Anti-Behauptungs-Filter entfernt unzulässige Formulierungen; der Inhalt wird mit AES-256 und einem plattformverwalteten Schlüssel verschlüsselt.
Speichern
Das Artefakt wird in die passende MongoDB-Collection geschrieben — Kapitel, Journaleinträge, Resonanzen — mit userId- und personId-Indizes für schnelles Auffinden. Zunächst Soft-Delete; endgültiges Löschen der personenbezogenen Daten nach 30 Tagen.
Benachrichtigen
Ein EventEmitter2-Ereignis — CHAPTER_COMPLETED, JOURNAL_CREATED — wird nach dem Datenbank-Commit ausgelöst. Das Benachrichtigungsmodul nimmt es auf, erstellt einen Posteingangseintrag und sendet optional eine Push-Nachricht (begrenzt auf eine pro Tag, Ruhezeiten werden berücksichtigt).
Anzeigen
Das Frontend ruft das Artefakt über einen authentifizierten API-Aufruf ab. Der Hub wird mit dem neuen Inhalt neu gerendert. War die Nutzerin oder der Nutzer offline, liefert der Cache die gestrige Ansicht, und das neue Artefakt erscheint bei der erneuten Verbindung.
Die vier Collections
Indexiert für die Abfragen, die jede einzelne beantwortet.
soulwise_chapters
KI-verfasste Kapitel, verschlüsselter Inhalt. Indizes auf personId, userId, generatedAt. Aspekt-Chips werden als separates Array gespeichert, um schnell zu filtern.
soulwise_journal_entries
Nutzergeschriebene Reflexionen, verschlüsselter Inhalt. Indizes auf userId, personId, createdAt. Textindexierter Inhalt für die Suche. Markierung pro Eintrag: „privat — nicht an Luminara weitergeben“.
soulwise_resonances
Vierdimensionale Werte pro Verbindung. Eindeutiger Index auf personId. Wird nach jedem Kapitel- oder Journalschreibvorgang per Service-Aufruf neu berechnet.
EDA-Ereignisse
Strikte Regel: Ereignisse werden erst nach dem Datenbank-Commit ausgelöst. Modulübergreifende Abhängigkeiten über Symbol-Injection-Tokens, niemals über forwardRef. Keine direkten Service-zu-Service-Importe zwischen Feature-Modulen.
SoulwiseEvents.CHAPTER_COMPLETED— SoulwiseEvents.CHAPTER_COMPLETED — wird ausgelöst, nachdem ein Kapitel verschlüsselt und gespeichert wurde. Notifications-v2 hört mit; erstellt einen Posteingangseintrag; sendet optional eine Push-Benachrichtigung.SoulwiseEvents.JOURNAL_CREATED— SoulwiseEvents.JOURNAL_CREATED — wird ausgelöst, nachdem ein Journaleintrag verschlüsselt und gespeichert wurde. Der Resonanz-Dienst hört mit; löst eine Neuberechnung aus.SoulwiseEvents.PERSON_BIRTH_UPDATED— SoulwiseEvents.PERSON_BIRTH_UPDATED — wird ausgelöst, nachdem sich die Geburtsdaten einer Person geändert haben. Der Synastrie-Cache wird invalidiert.SoulwiseEvents.PUSH_REQUESTED— SoulwiseEvents.PUSH_REQUESTED — gemäß Notifications-v2-Kontrakt; berücksichtigt das Push-Budget und Ruhezeiten.
Strenge V-Modell-Spezifikation
119 rückverfolgbare Anforderungen, keine Lücken. Jede Anforderung verweist vorwärts auf einen Testfall (UTP, ITP, STP, E2E) und rückwärts auf eine User Story. 20 User Stories. 15 funktionale Anforderungen. 12 nicht-funktionale Kategorien. 8 globale Abnahme-Gates.
Performance-Kontrakt
Kapitelgenerierung in 30 Sekunden oder schneller bei 95% der Anfragen, gemessen an der Verteilung der BullMQ-Job-Dauer. API-p99-GET-Latenz von 500 ms oder besser bei 1,000 gleichzeitigen Nutzern, gemessen per k6-Lasttest. Frontend-TTI von 3 Sekunden oder besser bei simuliertem 4G, gemessen per Lighthouse CI.
Sicherheits-Kontrakt
AES-256-Verschlüsselung im Ruhezustand mit plattformverwalteten Schlüsseln für Journal- und Kapitelinhalte. TLS 1.2+ bei der Übertragung; HTTP→HTTPS-Weiterleitung. JWT-Zugriffstokens mit 1-stündiger Lebensdauer, Refresh-Tokens mit 30-tägiger Lebensdauer, Rotation beim Refresh. Soft-Delete mit einem Zeitfenster von 30 Tagen vor dem Hard-Delete personenbezogener Daten.
Barrierefreiheits-Kontrakt
prefers-reduced-motion wird global respektiert — GSAP-Animationen werden zu reinen Opazitäts-Überblendungen. VoiceOver- und TalkBack-Beschriftungen an jedem interaktiven Element. Vor jeder Veröffentlichung manuell unter iOS und Android verifiziert.
Warum ein separates soulwise-story-Modul, statt cosmic-story zu erweitern?
Weil die übergeordnete Spezifikation das Feature neu aufbaut, und ein Neuaufbau innerhalb eines bestehenden Moduls entweder die v1-Erfahrung beschädigen oder ein späteres Fork-then-Merge erzwingen würde. Ein neues Modul lässt v1 unangetastet, ermöglicht es v2, sich zu bewähren, und migriert sauber, sobald alles bereit ist.
Warum MongoDB und nicht Postgres?
Das bestehende Backend von My Zodiac AI läuft auf MongoDB; ein Wechsel würde eine Infrastrukturentscheidung bedeuten, die nichts mit diesem Feature zu tun hat. Das Dokumentenmodell passt zudem gut zu Kapiteln und Tagebucheinträgen — verschachtelt, von variabler Länge, als Blob verschlüsselt.
Warum fiel die Wahl der Queue auf BullMQ?
BullMQ läuft auf Redis, das für Sitzungen und Rate-Limits bereits Teil des Stacks ist. Keine neue Infrastruktur. Eingebaute Wiederholungs-, Timeout- und Observability-Funktionen decken die Anforderungen der Kapitelerzeugung ab, ohne dass eigene Verdrahtung nötig ist.
Wo ist die übergeordnete Spezifikation eigentlich festgehalten?
Im internen Repository. Die Zahlen und Verträge auf dieser Seite paraphrasieren die übergeordneten V-Modell-Artefakte. Öffentlich zugängliche Engineering-Blogbeiträge im Blog-Cluster von My Zodiac AI (mit dem Tag 'cosmic-story-v2') gehen tiefer auf bestimmte Teile des Aufbaus ein.
Testen Sie My Zodiac AI noch heute
Während Soulwise seine Wellen öffnet, halten Sie unsere führende Astrologie-App bereits in Händen.
Astrologische Inhalte dienen der Reflexion und Unterhaltung. Die hier beschriebenen Funktionen von Cosmic Story v2 befinden sich in Entwicklung; die Verfügbarkeit kann sich ohne Vorankündigung ändern.