Architecture de Cosmic Story v2 — une plongée en profondeur.

Pour les ingénieurs, les chefs de produit, les journalistes et les éclaireurs de partenariats. L'ensemble du pipeline, quatre collections MongoDB, les événements EDA, la rigueur du V-Model, les objectifs de performance, la sécurité et l'accessibilité — le tout sur une seule page.

  • Soulwise-story est un nouveau module NestJS qui vient s'ajouter au module cosmic-story existant. Aucun import direct entre les modules fonctionnels.
  • Quatre collections MongoDB : soulwise_persons, soulwise_chapters, soulwise_journal_entries, soulwise_resonances. Corps chiffrés en AES-256, indexés selon les requêtes qu'ils servent.
  • Génération asynchrone via une file BullMQ avec un délai d'expiration de 28 s. Les événements sont émis par EventEmitter2 uniquement après validation en base de données — aucun élément fantôme dans la boîte de réception.
  • Spécification en V-Model : 119 exigences, zéro lacune. Objectif de couverture backend : 85% d'instructions sur les services ; frontend : 90% sur les stores Pinia.

Le pipeline, à nouveau, avec le détail technique

Chaque étape possède un service, un contrat et un événement.

  1. Déclenchement

    Une action de l'utilisateur — « générer le chapitre du jour pour Sœur » — ou une tâche cron planifiée, comme le récapitulatif du dimanche à 9 h, ou l'actualisation météo toutes les 6 heures.

  2. File d'attente

    La tâche atterrit sur une file d'attente BullMQ nommée soulwise-chapter-generation, avec un délai d'expiration strict de 28 secondes. Les tâches trop longues sont interrompues et signalées à l'utilisateur par un « réessayez ».

  3. Composition

    Le ChapterGenerationService assemble le prompt à quatre facteurs — contexte de la personne, astrologie, signal, rythme — en une seule entrée. Aucune donnée personnelle brute de l'utilisateur n'entre telle quelle dans le prompt ; tout est d'abord nettoyé.

  4. Générer

    Un fournisseur d'IA est appelé via le jeton symbole AI_GENERATION_ADAPTER — le fournisseur est interchangeable. La réponse est vérifiée quant à sa longueur, sa forme et sa sécurité avant de poursuivre.

  5. Post-traitement

    Quatre choses se produisent : un classificateur de crise détecte tout langage de crise ; un extracteur de chips d'aspect en tire une à trois chips astrologiques ; un filtre anti-affirmation supprime les formulations interdites ; le corps est chiffré en AES-256 avec une clé gérée par la plateforme.

  6. Conserver

    L'artefact est écrit dans la collection MongoDB appropriée — chapitres, entrées de journal, résonances — avec des index userId et personId pour une recherche rapide. Suppression douce d'abord ; suppression définitive des données personnelles à 30 jours.

  7. Notifier

    Un événement EventEmitter2 — CHAPTER_COMPLETED, JOURNAL_CREATED — se déclenche après la validation en base de données. Le module de notifications le capte, crée un élément dans la boîte de réception et envoie éventuellement une notification push (plafonnée à une par jour, les heures de silence étant respectées).

  8. Afficher

    Le frontend récupère l'artefact via un appel d'API authentifié. Le Hub se réaffiche avec le nouveau contenu. Si l'utilisateur était hors ligne, le cache propose la vue de la veille et le nouvel artefact apparaît à la reconnexion.

Sept étapes du déclenchement à l'affichage, chacune nommée d'après ce qu'elle accomplit réellement.

Les quatre collections

Indexées selon les requêtes auxquelles chacune répond.

soulwise_persons

Entrées d'album. Index sur userId, status, deletedAt. Suppression logique d'abord ; suppression définitive des données personnelles à 30 jours.

soulwise_chapters

Chapitres rédigés par l'IA, corps chiffré. Index sur personId, userId, generatedAt. Les puces d'aspects sont stockées dans un tableau distinct pour un filtrage rapide.

soulwise_journal_entries

Réflexions rédigées par l'utilisateur, corps chiffré. Index sur userId, personId, createdAt. Corps indexé en texte pour la recherche. Indicateur « privé — ne pas transmettre à Luminara » par entrée.

soulwise_resonances

Scores à quatre dimensions par lien. Index unique sur personId. Recalculés via un appel de service après l'écriture d'un chapitre ou d'un journal.

Événements EDA

Règle stricte : les événements ne se déclenchent qu'après le commit en base de données. Dépendances inter-modules via des jetons d'injection Symbol, jamais via forwardRef. Aucun import direct de service à service entre modules fonctionnels.

  • SoulwiseEvents.CHAPTER_COMPLETED — SoulwiseEvents.CHAPTER_COMPLETED — déclenché après le chiffrement et la persistance d'un chapitre. Notifications-v2 est à l'écoute ; crée un élément de boîte de réception ; envoie éventuellement une notification push.
  • SoulwiseEvents.JOURNAL_CREATED — SoulwiseEvents.JOURNAL_CREATED — déclenché après le chiffrement et la persistance d'une entrée de journal. Le service de résonance est à l'écoute ; déclenche un recalcul.
  • SoulwiseEvents.PERSON_BIRTH_UPDATED — SoulwiseEvents.PERSON_BIRTH_UPDATED — déclenché après la modification des données de naissance d'une personne. Le cache de synastrie est invalidé.
  • SoulwiseEvents.PUSH_REQUESTED — SoulwiseEvents.PUSH_REQUESTED — selon le contrat de notifications-v2 ; respecte le budget push et les heures de silence.

Rigueur des spécifications en V-Model

119 exigences traçables, aucune lacune. Chaque exigence se rattache en aval à un cas de test (UTP, ITP, STP, E2E) et en amont à un récit utilisateur. 20 récits utilisateur. 15 exigences fonctionnelles. 12 catégories non fonctionnelles. 8 jalons d'acceptation globaux.

Contrat de performance

Génération de chapitre en 30 secondes ou moins pour 95% des requêtes, mesurée par rapport à la distribution de durée des tâches BullMQ. Latence GET p99 de l'API de 500 ms ou moins avec 1,000 utilisateurs simultanés, mesurée via un test de charge k6. TTI frontend de 3 secondes ou moins en 4G simulée, mesuré via Lighthouse CI.

Contrat de sécurité

Chiffrement AES-256 au repos avec clés gérées par la plateforme pour les corps de journal et de chapitre. TLS 1.2+ en transit ; redirection HTTP→HTTPS. Jetons d'accès JWT d'une durée de vie de 1 heures, jetons de rafraîchissement d'une durée de vie de 30 jours, rotation au rafraîchissement. Suppression réversible avec une fenêtre de 30 jours avant la suppression définitive des données personnelles.

Contrat d'accessibilité

prefers-reduced-motion respecté de façon globale — les animations GSAP se réduisent à de simples fondus d'opacité. Des libellés VoiceOver et TalkBack sur chaque élément interactif. Vérification manuelle sur iOS et Android avant chaque version.

Pourquoi un module soulwise-story distinct plutôt qu'une extension de cosmic-story ?

Parce que la spécification en amont reconstruit la fonctionnalité, et reconstruire au sein d'un module existant casserait l'expérience v1 ou imposerait un fork suivi d'une fusion ultérieure. Un nouveau module laisse v1 intact, permet à v2 de faire ses preuves, et migre proprement le moment venu.

Pourquoi MongoDB et non Postgres ?

Le backend actuel de My Zodiac AI repose sur MongoDB ; changer reviendrait à prendre une décision d'infrastructure sans rapport avec cette fonctionnalité. Le modèle documentaire convient d'ailleurs très bien aux chapitres et aux entrées de journal — imbriqués, de longueur variable, chiffrés sous forme de blob.

Pourquoi avoir choisi BullMQ comme file d'attente ?

BullMQ s'appuie sur Redis, déjà présent dans la stack pour la session et la limitation de débit. Aucune nouvelle infrastructure. Les fonctions intégrées de relance, de délai d'expiration et d'observabilité couvrent les besoins de génération de chapitres sans tuyauterie sur mesure.

Où la spécification en amont est-elle réellement consignée ?

Dans le dépôt interne. Les chiffres et contrats de cette page paraphrasent les artefacts V-Model en amont. Des billets de blog technique destinés au public, sur le cluster de blog de My Zodiac AI (tagués « cosmic-story-v2 »), approfondissent certaines parties précises de la conception.

Essayez My Zodiac AI dès aujourd'hui

Tandis que Soulwise déploie ses premières ondes, notre application phare d'astrologie est déjà entre vos mains.

Le contenu astrologique est destiné à la réflexion et au divertissement. Les fonctionnalités de Cosmic Story v2 décrites ici sont en cours de développement ; leur disponibilité peut changer sans préavis.