soulwise_persons
Entradas do álbum. Índices em userId, status, deletedAt. Soft-delete primeiro; hard-delete dos PII aos 30 dias.
Arquitetura da Cosmic Story v2 — uma análise aprofundada.
Para engenheiros, PMs, jornalistas e exploradores de parcerias. O pipeline completo, quatro coleções MongoDB, eventos EDA, rigor do V-Model, metas de desempenho, segurança e acessibilidade — tudo numa só página.
- O Soulwise-story é um novo módulo NestJS a par do módulo cosmic-story já existente. Zero importações diretas entre módulos de funcionalidades.
- Quatro coleções MongoDB: soulwise_persons, soulwise_chapters, soulwise_journal_entries, soulwise_resonances. Corpos cifrados com AES-256, indexados para as consultas que cada uma serve.
- Geração assíncrona através de uma fila BullMQ com tempo limite de 28 s. Os eventos são emitidos via EventEmitter2 apenas após o commit na base de dados — sem itens fantasma na caixa de entrada.
- Especificação V-Model: 119 requisitos, zero lacunas. Meta de cobertura no backend de 85% de instruções nos serviços; no frontend, 90% nas stores Pinia.
O pipeline, mais uma vez, com detalhe de engenharia
Cada passo tem um serviço, um contrato e um evento.
Gatilho
Uma ação do utilizador — 'gerar o capítulo de hoje para a Irmã' — ou um cron agendado, como o resumo de domingo às 9 da manhã, ou a atualização meteorológica a cada 6 horas.
Fila
O trabalho chega a uma fila BullMQ chamada soulwise-chapter-generation, com um tempo-limite rígido de 28 segundos. Os trabalhos de longa duração são terminados e reportados ao utilizador como 'tenta de novo'.
Compor
O ChapterGenerationService reúne o prompt de quatro fatores — contexto da pessoa, astrologia, sinal, cadência — num único input. Nenhuma PII em bruto do utilizador entra no prompt de forma literal; tudo é depurado primeiro.
Gerar
Um fornecedor de IA é invocado através do token de símbolo AI_GENERATION_ADAPTER — o fornecedor é substituível. A resposta é verificada quanto ao comprimento, à forma e à segurança antes de prosseguir.
Pós-processar
Acontecem quatro coisas: um classificador de crise procura linguagem de crise; um extrator de chips de aspeto retira de um a três chips de astrologia; um filtro anti-alegações remove formulações proibidas; o corpo é encriptado em AES-256 com uma chave gerida pela plataforma.
Persistir
O artefacto é escrito na coleção MongoDB apropriada — capítulos, entradas de diário, ressonâncias — com índices userId e personId para uma consulta rápida. Primeiro a eliminação suave; eliminação definitiva dos dados pessoais aos 30 dias.
Notificar
Um evento EventEmitter2 — CHAPTER_COMPLETED, JOURNAL_CREATED — é disparado após o commit na base de dados. O módulo de notificações capta-o, cria um item na caixa de entrada e, opcionalmente, envia uma notificação push (limitada a uma por dia, respeitando as horas de silêncio).
Apresentar
O frontend obtém o artefacto através de uma chamada à API autenticada. O Hub volta a renderizar com o novo conteúdo. Se o utilizador estava offline, a cache mostra a vista de ontem e o novo artefacto surge ao reconectar.
As quatro coleções
Indexadas para as consultas que cada uma responde.
soulwise_chapters
Capítulos escritos por IA, corpo cifrado. Índices em personId, userId, generatedAt. Os chips de aspeto são guardados como um array separado para uma filtragem rápida.
soulwise_journal_entries
Reflexões escritas pelo utilizador, corpo cifrado. Índices em userId, personId, createdAt. Corpo indexado por texto para pesquisa. Sinalizador por entrada «privado — não fornecer à Luminara».
soulwise_resonances
Pontuações em quatro dimensões por vínculo. Índice único em personId. Recalculadas através de uma chamada ao serviço após a escrita de um capítulo ou de um diário.
Eventos EDA
Regra rígida: os eventos só disparam após o commit na base de dados. Dependências entre módulos através de tokens de injeção Symbol, nunca via forwardRef. Sem importações diretas de serviço para serviço entre módulos de funcionalidade.
SoulwiseEvents.CHAPTER_COMPLETED— SoulwiseEvents.CHAPTER_COMPLETED — disparado após um capítulo ser encriptado e persistido. O Notifications-v2 escuta; cria um item na caixa de entrada; opcionalmente envia push.SoulwiseEvents.JOURNAL_CREATED— SoulwiseEvents.JOURNAL_CREATED — disparado após uma entrada de diário ser encriptada e persistida. O serviço de ressonância escuta; aciona o recálculo.SoulwiseEvents.PERSON_BIRTH_UPDATED— SoulwiseEvents.PERSON_BIRTH_UPDATED — disparado após os dados de nascimento de uma pessoa mudarem. A cache de sinastria é invalidada.SoulwiseEvents.PUSH_REQUESTED— SoulwiseEvents.PUSH_REQUESTED — conforme o contrato do notifications-v2; respeita o orçamento de push e as horas de silêncio.
Rigor da especificação do modelo em V
119 requisitos rastreáveis, zero lacunas. Cada requisito mapeia, para a frente, um caso de teste (UTP, ITP, STP, E2E) e, para trás, uma user story. 20 user stories. 15 requisitos funcionais. 12 categorias não funcionais. 8 portas de aceitação globais.
Contrato de desempenho
Geração de capítulos em 30 segundos ou menos para 95% dos pedidos, medida face à distribuição de duração dos jobs do BullMQ. Latência da API p99 GET de 500 ms ou menos com 1,000 utilizadores em simultâneo, medida via teste de carga k6. TTI do frontend de 3 segundos ou menos em 4G simulado, medido via Lighthouse CI.
Contrato de segurança
Encriptação AES-256 em repouso, com chaves geridas pela plataforma para os corpos de diário e de capítulo. TLS 1.2+ em trânsito; redirecionamento HTTP→HTTPS. Tokens de acesso JWT com tempo de vida de 1 horas, tokens de atualização com tempo de vida de 30 dias, com rotação na atualização. Eliminação suave com janela de 30 dias antes da eliminação definitiva dos dados pessoais.
Contrato de acessibilidade
prefers-reduced-motion respeitado globalmente — as animações GSAP passam a ser apenas esbatimentos de opacidade. Etiquetas para VoiceOver e TalkBack em cada elemento interativo. Verificado manualmente em iOS e Android antes de cada lançamento.
Porquê um módulo soulwise-story separado em vez de estender o cosmic-story?
Porque a especificação a montante reconstrói a funcionalidade, e reconstruí-la dentro de um módulo existente iria quebrar a experiência da v1 ou obrigar a um fork seguido de merge mais tarde. Um novo módulo mantém a v1 intocada, deixa a v2 provar o seu valor e migra de forma limpa quando estiver pronta.
Porquê MongoDB e não Postgres?
O backend atual da My Zodiac AI assenta em MongoDB; mudar significaria uma decisão de infraestrutura sem relação com esta funcionalidade. O modelo de documentos também encaixa bem em capítulos e entradas de diário — aninhados, de comprimento variável, encriptados como blob.
Porque é o BullMQ a escolha de fila?
O BullMQ corre sobre Redis, que já faz parte da stack para sessões e limitação de taxa. Sem nova infraestrutura. As funcionalidades integradas de repetição, timeout e observabilidade cobrem as necessidades de geração de capítulos sem encanamentos à medida.
Onde está, afinal, escrita a especificação a montante?
Num repositório interno. Os números e contratos desta página parafraseiam os artefactos do Modelo em V a montante. As publicações de engenharia voltadas ao público no cluster de blog da My Zodiac AI (com a etiqueta 'cosmic-story-v2') aprofundam partes específicas da construção.
Experimenta hoje a My Zodiac AI
Enquanto a Soulwise abre as suas ondas, a nossa aplicação de astrologia de referência já está nas tuas mãos.
O conteúdo astrológico destina-se à reflexão e ao entretenimento. As funcionalidades da Cosmic Story v2 aqui descritas estão em desenvolvimento; a disponibilidade pode mudar sem aviso prévio.