soulwise_persons
Entrées d'album. Index sur userId, status, deletedAt. Suppression logique d'abord ; suppression définitive des données personnelles à 30 jours.
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.
Chaque étape possède un service, un contrat et un événement.
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.
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 ».
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é.
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.
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.
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.
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).
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.
Indexées selon les requêtes auxquelles chacune répond.
Entrées d'album. Index sur userId, status, deletedAt. Suppression logique d'abord ; suppression définitive des données personnelles à 30 jours.
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.
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.
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.
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.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.
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.
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.
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.
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.
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.
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.
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.
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.