soulwise_persons
Voci dell'album. Indici su userId, status, deletedAt. Prima soft-delete; hard-delete dei dati personali a 30 giorni.
Architettura di Cosmic Story v2 — un'analisi approfondita.
Per ingegneri, PM, giornalisti e talent scout per partnership. La pipeline completa, quattro collezioni MongoDB, eventi EDA, il rigore del V-Model, gli obiettivi di prestazione, la sicurezza e l'accessibilità — tutto in una sola pagina.
- Soulwise-story è un nuovo modulo NestJS affiancato al modulo cosmic-story esistente. Zero import diretti tra i moduli funzionali.
- Quattro collezioni MongoDB: soulwise_persons, soulwise_chapters, soulwise_journal_entries, soulwise_resonances. Corpi cifrati in AES-256, indicizzati per le query che ciascuna serve.
- Generazione asincrona tramite coda BullMQ con timeout di 28 s. Eventi emessi tramite EventEmitter2 solo dopo il commit sul database — niente voci fantasma nella inbox.
- Specifica V-Model: 119 requisiti, zero lacune. Obiettivo di copertura backend 85% sulle istruzioni dei servizi; frontend 90% sugli store Pinia.
La pipeline, di nuovo, con il dettaglio ingegneristico
Ogni passaggio ha un servizio, un contratto e un evento.
Attivazione
Un'azione dell'utente — «genera il capitolo di oggi per Sorella» — oppure un cron pianificato, come il riepilogo della domenica alle 9 del mattino, o l'aggiornamento del meteo ogni 6 ore.
Coda
Il lavoro finisce in una coda BullMQ chiamata soulwise-chapter-generation, con un timeout fisso di 28 secondi. I lavori troppo lunghi vengono interrotti e segnalati all'utente come «riprova».
Composizione
Il ChapterGenerationService assembla il prompt a quattro fattori — contesto della persona, astrologia, segnale, cadenza — in un unico input. Nel prompt non finiscono dati personali grezzi dell'utente alla lettera; tutto viene prima ripulito.
Genera
Un provider di AI viene richiamato tramite il token simbolico AI_GENERATION_ADAPTER — il provider è intercambiabile. La risposta viene controllata per lunghezza, forma e sicurezza prima di proseguire.
Elabora
Accadono quattro cose: un classificatore di crisi cerca segnali di linguaggio in crisi; un estrattore di chip aspettuali raccoglie da uno a tre chip astrologici; un filtro anti-affermazioni rimuove le formulazioni vietate; il corpo viene cifrato in AES-256 con una chiave gestita dalla piattaforma.
Conserva
L'artefatto viene scritto nella collezione MongoDB appropriata — capitoli, voci di diario, risonanze — con indici userId e personId per una ricerca rapida. Prima soft-delete; hard-delete dei dati personali a 30 giorni.
Notifica
Un evento EventEmitter2 — CHAPTER_COMPLETED, JOURNAL_CREATED — viene attivato dopo il commit sul database. Il modulo notifiche lo intercetta, crea un elemento nella posta in arrivo e, facoltativamente, invia una notifica push (con un limite di una al giorno, nel rispetto delle ore di silenzio).
Mostra
Il frontend recupera l'artefatto tramite una chiamata API autenticata. L'Hub si aggiorna con il nuovo contenuto. Se eri offline, la cache serve la vista di ieri e il nuovo artefatto compare alla riconnessione.
Le quattro collezioni
Indicizzate per le query a cui ciascuna risponde.
soulwise_chapters
Capitoli scritti dall'IA, corpo cifrato. Indici su personId, userId, generatedAt. Le chip degli aspetti sono memorizzate in un array separato per filtrare più velocemente.
soulwise_journal_entries
Riflessioni scritte dall'utente, corpo cifrato. Indici su userId, personId, createdAt. Corpo con indice di testo per la ricerca. Flag per singola voce 'privata — non fornire a Luminara'.
soulwise_resonances
Punteggi su quattro dimensioni per ogni legame. Indice univoco su personId. Ricalcolati tramite chiamata al servizio dopo la scrittura di un capitolo o del diario.
Eventi EDA
Regola rigorosa: gli eventi si attivano solo dopo il commit sul database. Dipendenze tra moduli tramite token di iniezione Symbol, mai tramite forwardRef. Nessuna importazione diretta tra servizi nei moduli funzionali.
SoulwiseEvents.CHAPTER_COMPLETED— SoulwiseEvents.CHAPTER_COMPLETED — attivato dopo che un capitolo è stato cifrato e reso persistente. Notifications-v2 è in ascolto; crea un elemento nella casella di posta; facoltativamente invia una notifica push.SoulwiseEvents.JOURNAL_CREATED— SoulwiseEvents.JOURNAL_CREATED — attivato dopo che una voce di diario è stata cifrata e resa persistente. Il servizio di risonanza è in ascolto; avvia il ricalcolo.SoulwiseEvents.PERSON_BIRTH_UPDATED— SoulwiseEvents.PERSON_BIRTH_UPDATED — attivato dopo la modifica dei dati di nascita di una persona. La cache della sinastria viene invalidata.SoulwiseEvents.PUSH_REQUESTED— SoulwiseEvents.PUSH_REQUESTED — secondo il contratto di notifications-v2; rispetta il budget delle notifiche push e gli orari di silenzio.
Rigore della specifica V-Model
119 requisiti tracciabili, zero lacune. Ogni requisito si collega in avanti a un caso di test (UTP, ITP, STP, E2E) e all'indietro a una user story. 20 user story. 15 requisiti funzionali. 12 categorie non funzionali. 8 gate di accettazione globali.
Contratto sulle prestazioni
Generazione di un capitolo in 30 secondi o meno per il 95% delle richieste, misurata sulla distribuzione della durata dei job BullMQ. Latenza GET p99 delle API di 500 ms o meno con 1,000 utenti simultanei, misurata con un test di carico k6. TTI del frontend di 3 secondi o meno su 4G simulato, misurato con Lighthouse CI.
Contratto sulla sicurezza
Cifratura AES-256 a riposo con chiavi gestite dalla piattaforma per i contenuti del diario e dei capitoli. TLS 1.2+ in transito; reindirizzamento da HTTP a HTTPS. Token di accesso JWT con durata di 1 ore, token di refresh con durata di 30 giorni, rotazione al refresh. Cancellazione soft con una finestra di 30 giorni prima della cancellazione definitiva dei dati personali.
Contratto sull'accessibilità
prefers-reduced-motion rispettato ovunque: le animazioni GSAP diventano semplici dissolvenze di opacità. Etichette VoiceOver e TalkBack su ogni elemento interattivo. Verificato manualmente su iOS e Android prima di ogni rilascio.
Perché un modulo soulwise-story separato invece di estendere cosmic-story?
Perché la specifica upstream ricostruisce la funzionalità, e ricostruirla dentro un modulo esistente comprometterebbe l'esperienza v1 oppure imporrebbe un fork seguito da un merge successivo. Un nuovo modulo lascia intatta la v1, permette alla v2 di dimostrare il proprio valore e consente una migrazione pulita al momento giusto.
Perché MongoDB e non Postgres?
Il backend attuale di My Zodiac AI è su MongoDB; cambiare significherebbe prendere una decisione infrastrutturale slegata da questa funzionalità. Inoltre il modello a documenti si adatta bene a capitoli e voci di diario: annidati, di lunghezza variabile, cifrati come blob.
Perché la scelta della coda è BullMQ?
BullMQ gira su Redis, già presente nello stack per sessioni e rate-limit. Nessuna nuova infrastruttura. Retry, timeout e osservabilità integrati coprono le esigenze di generazione dei capitoli senza dover costruire nulla a mano.
Dove è scritta davvero la specifica upstream?
Nel repository interno. I numeri e i contratti riportati in questa pagina parafrasano gli artefatti V-Model upstream. Gli articoli tecnici pubblici sul cluster blog di My Zodiac AI (con tag 'cosmic-story-v2') approfondiscono parti specifiche della realizzazione.
Prova My Zodiac AI oggi
Mentre Soulwise apre le sue onde, la nostra app di punta per l'astrologia è già nelle tue mani.
I contenuti astrologici servono alla riflessione e all'intrattenimento. Le funzioni di Cosmic Story v2 descritte qui sono in sviluppo; la disponibilità può cambiare senza preavviso.