soulwise_persons
Wpisy z albumu. Indeksy na userId, status, deletedAt. Najpierw miękkie usuwanie; twarde usuwanie danych osobowych po 30 dniach.
Architektura Cosmic Story v2 — dogłębna analiza.
Dla inżynierów, PM-ów, dziennikarzy i osób poszukujących partnerstw. Pełny pipeline, cztery kolekcje MongoDB, zdarzenia EDA, rygor V-Model, cele wydajnościowe, bezpieczeństwo i dostępność — wszystko na jednej stronie.
- Soulwise-story to nowy moduł NestJS obok istniejącego modułu cosmic-story. Zero bezpośrednich importów między modułami funkcji.
- Cztery kolekcje MongoDB: soulwise_persons, soulwise_chapters, soulwise_journal_entries, soulwise_resonances. Treści szyfrowane algorytmem AES-256, indeksowane pod kątem zapytań, którym każda służy.
- Asynchroniczne generowanie przez kolejkę BullMQ z limitem czasu 28 s. Zdarzenia emitowane przez EventEmitter2 dopiero po zatwierdzeniu zapisu w bazie danych — żadnych widmowych pozycji w skrzynce.
- Specyfikacja w modelu V: 119 wymagań, zero luk. Docelowe pokrycie backendu 85% instrukcji w usługach; frontend 90% w magazynach Pinia.
Potok jeszcze raz, ze szczegółami inżynieryjnymi
Każdy krok ma swoją usługę, kontrakt i zdarzenie.
Wyzwalacz
Działanie użytkownika — „wygeneruj dzisiejszy rozdział dla Siostry” — albo zaplanowany cron, jak niedzielne podsumowanie o 9 rano czy odświeżanie pogody co 6 godzin.
Kolejka
Zadanie trafia do kolejki BullMQ o nazwie soulwise-chapter-generation, z twardym limitem 28 sekund. Długo trwające zadania są przerywane i zgłaszane użytkownikowi jako „spróbuj ponownie”.
Złożenie
ChapterGenerationService składa cztroczynnikowy prompt — kontekst osoby, astrologię, sygnał, rytm — w jedno wejście. Żadne surowe dane osobowe użytkownika nie trafiają do promptu dosłownie; wszystko jest najpierw oczyszczane.
Generuj
Dostawca AI jest wywoływany za pomocą tokena symbolu AI_GENERATION_ADAPTER — dostawcę można wymienić. Odpowiedź jest sprawdzana pod kątem długości, struktury i bezpieczeństwa, zanim proces ruszy dalej.
Przetwarzaj
Dzieją się cztery rzeczy: klasyfikator kryzysowy sprawdza, czy nie pojawia się język kryzysowy; ekstraktor chipów aspektów wyciąga od jednego do trzech chipów astrologicznych; filtr antyobietnicowy usuwa zakazane sformułowania; treść jest szyfrowana algorytmem AES-256 z kluczem zarządzanym przez platformę.
Zapisz
Artefakt jest zapisywany do odpowiedniej kolekcji MongoDB — rozdziały, wpisy do dziennika, rezonanse — z indeksami userId i personId dla szybkiego wyszukiwania. Najpierw miękkie usunięcie; trwałe usunięcie danych osobowych po 30 dniach.
Powiadom
Zdarzenie EventEmitter2 — CHAPTER_COMPLETED, JOURNAL_CREATED — uruchamia się po zatwierdzeniu zapisu w bazie danych. Moduł powiadomień je przechwytuje, tworzy element w skrzynce odbiorczej i opcjonalnie wysyła powiadomienie push (z limitem jednego dziennie i poszanowaniem godzin ciszy).
Pokaż
Frontend pobiera artefakt za pomocą uwierzytelnionego wywołania API. Hub renderuje się ponownie z nową treścią. Jeśli użytkownik był offline, pamięć podręczna serwuje wczorajszy widok, a nowy artefakt pojawia się po ponownym połączeniu.
Cztery kolekcje
Indeksowane pod kątem zapytań, na które każda odpowiada.
soulwise_chapters
Rozdziały napisane przez AI, treść szyfrowana. Indeksy na personId, userId, generatedAt. Plakietki aspektów przechowywane jako osobna tablica dla szybkiego filtrowania.
soulwise_journal_entries
Refleksje napisane przez użytkownika, treść szyfrowana. Indeksy na userId, personId, createdAt. Treść indeksowana tekstowo do wyszukiwania. Flaga przy każdym wpisie: „prywatne — nie przekazuj do Luminary”.
soulwise_resonances
Oceny w czterech wymiarach dla każdej więzi. Unikalny indeks na personId. Przeliczane przez wywołanie usługi po zapisie rozdziału lub wpisu w dzienniku.
Zdarzenia EDA
Ścisła zasada: zdarzenia są emitowane dopiero po zatwierdzeniu transakcji w bazie danych. Zależności między modułami realizowane przez tokeny wstrzykiwania typu Symbol, nigdy przez forwardRef. Żadnych bezpośrednich importów między usługami w modułach funkcjonalnych.
SoulwiseEvents.CHAPTER_COMPLETED— SoulwiseEvents.CHAPTER_COMPLETED — emitowane po zaszyfrowaniu i zapisaniu rozdziału. Nasłuchuje notifications-v2; tworzy element w skrzynce odbiorczej; opcjonalnie wysyła powiadomienie push.SoulwiseEvents.JOURNAL_CREATED— SoulwiseEvents.JOURNAL_CREATED — emitowane po zaszyfrowaniu i zapisaniu wpisu w dzienniku. Nasłuchuje usługa Resonance; wyzwala ponowne przeliczenie.SoulwiseEvents.PERSON_BIRTH_UPDATED— SoulwiseEvents.PERSON_BIRTH_UPDATED — emitowane po zmianie danych urodzeniowych osoby. Pamięć podręczna synastry zostaje unieważniona.SoulwiseEvents.PUSH_REQUESTED— SoulwiseEvents.PUSH_REQUESTED — zgodnie z kontraktem notifications-v2; respektuje budżet powiadomień push oraz godziny ciszy.
Rygor specyfikacji w modelu V
119 wymagań z pełną identyfikowalnością, zero luk. Każde wymaganie odwzorowuje się w przód na przypadek testowy (UTP, ITP, STP, E2E) i wstecz na historyjkę użytkownika. 20 historyjek użytkownika. 15 wymagań funkcjonalnych. 12 kategorii niefunkcjonalnych. 8 globalnych bramek akceptacji.
Kontrakt wydajnościowy
Generowanie rozdziału w 30 sekund lub szybciej dla 95% żądań, mierzone względem rozkładu czasu trwania zadań BullMQ. Opóźnienie API p99 dla GET na poziomie 500 ms lub lepszym przy 1,000 równoczesnych użytkownikach, mierzone testem obciążeniowym k6. Frontendowy TTI 3 sekund lub lepszy w symulowanej sieci 4G, mierzony przez Lighthouse CI.
Kontrakt bezpieczeństwa
Szyfrowanie AES-256 w spoczynku z kluczami zarządzanymi przez platformę dla treści dzienników i rozdziałów. TLS 1.2+ w transmisji; przekierowanie HTTP→HTTPS. Tokeny dostępowe JWT z czasem życia 1 godzin, tokeny odświeżające z czasem życia 30 dni, rotacja przy odświeżeniu. Miękkie usuwanie z oknem 30 dni przed trwałym usunięciem danych osobowych (PII).
Kontrakt dostępności
Ustawienie prefers-reduced-motion jest respektowane globalnie — animacje GSAP zmieniają się w samo wygaszanie przezroczystości. Etykiety VoiceOver i TalkBack na każdym interaktywnym elemencie. Ręcznie weryfikowane na iOS i Androidzie przed każdym wydaniem.
Dlaczego osobny moduł soulwise-story zamiast rozbudowy cosmic-story?
Ponieważ specyfikacja po stronie upstream przebudowuje funkcję, a przebudowa wewnątrz istniejącego modułu albo zepsułaby działanie wersji v1, albo wymusiła rozgałęzienie i późniejsze scalenie. Nowy moduł pozostawia v1 nietknięte, pozwala v2 się sprawdzić i umożliwia czystą migrację, gdy przyjdzie pora.
Dlaczego MongoDB, a nie Postgres?
Istniejący backend My Zodiac AI działa na MongoDB; zmiana oznaczałaby decyzję infrastrukturalną niezwiązaną z tą funkcją. Model dokumentowy dobrze pasuje też do rozdziałów i wpisów w dzienniku — zagnieżdżonych, o zmiennej długości, szyfrowanych jako blob.
Dlaczego wybór padł na kolejkę BullMQ?
BullMQ działa na Redisie, który jest już w stacku do obsługi sesji i limitowania żądań. Żadnej nowej infrastruktury. Wbudowane ponawianie, limity czasu i obserwowalność pokrywają potrzeby generowania rozdziałów bez dodatkowego oprzyrządowania.
Gdzie właściwie spisana jest specyfikacja po stronie upstream?
W wewnętrznym repozytorium. Liczby i kontrakty na tej stronie parafrazują artefakty V-Model po stronie upstream. Publiczne wpisy inżynierskie na blogu My Zodiac AI (oznaczone tagiem „cosmic-story-v2”) zagłębiają się w konkretne części tej budowy.
Wypróbuj My Zodiac AI już dziś
Gdy Soulwise dopiero rozwija swoje fale, nasza flagowa aplikacja astrologiczna jest już w twoich rękach.
Treści astrologiczne służą refleksji i rozrywce. Opisane tutaj funkcje Cosmic Story v2 są w przygotowaniu; ich dostępność może się zmienić bez powiadomienia.