soulwise_persons
Entradas do álbum. Índices em userId, status, deletedAt. Soft-delete primeiro; hard-delete dos dados pessoais (PII) em 30 dias.
Arquitetura do Cosmic Story v2 — uma análise aprofundada.
Para engenheiros, PMs, jornalistas e prospectores de parcerias. Todo o pipeline, quatro coleções MongoDB, eventos EDA, o rigor do V-Model, metas de desempenho, segurança e acessibilidade — tudo em uma única página.
- O Soulwise-story é um novo módulo NestJS ao lado do módulo cosmic-story já existente. Zero importações diretas entre os módulos de funcionalidade.
- Quatro coleções no MongoDB: soulwise_persons, soulwise_chapters, soulwise_journal_entries, soulwise_resonances. Corpos criptografados com AES-256, indexados para as consultas que cada uma atende.
- Geração assíncrona via fila BullMQ com timeout de 28 s. Eventos emitidos via EventEmitter2 apenas após o commit no banco de dados — sem itens fantasmas na caixa de entrada.
- Especificação V-Model: 119 requisitos, zero lacunas. Meta de cobertura no backend de 85% de statements nos serviços; frontend 90% nas stores Pinia.
O pipeline, mais uma vez, com detalhes de engenharia
Cada etapa tem um serviço, um contrato e um evento.
Gatilho
Uma ação do usuário — 'gerar o capítulo de hoje para a Irmã' — ou um cron agendado, como o resumo de domingo às 9 a.m., ou a atualização do clima a cada 6 horas.
Fila
O job chega a uma fila do BullMQ chamada soulwise-chapter-generation, com um timeout rígido de 28 segundos. Jobs muito demorados são encerrados e reportados como 'tente novamente' ao usuário.
Compor
O ChapterGenerationService reúne o prompt de quatro fatores — contexto da pessoa, astrologia, sinal, cadência — em uma única entrada. Nenhuma informação pessoal bruta do usuário entra no prompt de forma literal; tudo é limpo antes.
Gerar
Um provedor de IA é acionado pelo token de símbolo AI_GENERATION_ADAPTER — o provedor é intercambiável. A resposta é verificada quanto a tamanho, formato e segurança antes de continuar.
Pós-processar
Quatro coisas acontecem: um classificador de crise verifica se há linguagem de crise; um extrator de chips de aspecto identifica de um a três chips astrológicos; um filtro anti-afirmações remove formulações proibidas; o corpo é criptografado em AES-256 com uma chave gerenciada pela plataforma.
Persistir
O artefato é gravado na coleção apropriada do MongoDB — capítulos, entradas de diário, ressonâncias — com índices de userId e personId para busca rápida. Primeiro vem o soft-delete; o hard-delete de PII acontece em 30 dias.
Notificar
Um evento do EventEmitter2 — CHAPTER_COMPLETED, JOURNAL_CREATED — dispara após o commit no banco de dados. O módulo de notificações capta o evento, cria um item na caixa de entrada e, opcionalmente, envia um push (limitado a um por dia, respeitando os horários de silêncio).
Exibir
O frontend busca o artefato por meio de uma chamada de API autenticada. O Hub é renderizado novamente com o novo conteúdo. Se o usuário estava offline, o cache exibe a visualização de ontem e o novo artefato aparece ao reconectar.
As quatro coleções
Indexadas para as consultas que cada uma responde.
soulwise_chapters
Capítulos escritos por IA, corpo criptografado. Índices em personId, userId, generatedAt. Chips de aspecto armazenados em um array separado para filtragem rápida.
soulwise_journal_entries
Reflexões escritas pelo usuário, corpo criptografado. Índices em userId, personId, createdAt. Corpo com índice de texto para busca. Flag por entrada 'privado — não enviar para a Luminara'.
soulwise_resonances
Pontuações em quatro dimensões por vínculo. Índice único em personId. Recalculadas via chamada de serviço após a escrita de capítulo ou diário.
Eventos EDA
Regra rígida: os eventos só são disparados após o commit no banco de dados. Dependências entre módulos por meio de tokens de injeção Symbol, nunca via forwardRef. Sem imports diretos de serviço para serviço entre módulos de funcionalidade.
SoulwiseEvents.CHAPTER_COMPLETED— SoulwiseEvents.CHAPTER_COMPLETED — disparado depois que um capítulo é criptografado e persistido. O Notifications-v2 escuta; cria um item na caixa de entrada; opcionalmente envia push.SoulwiseEvents.JOURNAL_CREATED— SoulwiseEvents.JOURNAL_CREATED — disparado depois que uma entrada do diário é criptografada e persistida. O serviço de Ressonância escuta; aciona o recálculo.SoulwiseEvents.PERSON_BIRTH_UPDATED— SoulwiseEvents.PERSON_BIRTH_UPDATED — disparado depois que os dados de nascimento de uma pessoa mudam. O cache de sinastria é invalidado.SoulwiseEvents.PUSH_REQUESTED— SoulwiseEvents.PUSH_REQUESTED — conforme o contrato do notifications-v2; respeita o orçamento de push e os horários de silêncio.
Rigor da especificação do Modelo-V
119 requisitos rastreáveis, zero lacunas. Cada requisito se conecta para a frente a um caso de teste (UTP, ITP, STP, E2E) e para trás a uma user story. 20 user stories. 15 requisitos funcionais. 12 categorias não funcionais. 8 portões de aceitação globais.
Contrato de desempenho
Geração de capítulo em 30 segundos ou menos para 95% das requisições, medida pela distribuição de duração das jobs do BullMQ. Latência de GET da API p99 em 500 ms ou menos com 1,000 usuários simultâneos, medida via teste de carga k6. TTI do frontend em 3 segundos ou menos em 4G simulado, medido via Lighthouse CI.
Contrato de segurança
Criptografia AES-256 em repouso com chaves gerenciadas pela plataforma para os corpos do diário e dos capítulos. TLS 1.2+ em trânsito; redirecionamento HTTP→HTTPS. Tokens de acesso JWT com tempo de vida de 1 horas, tokens de refresh com tempo de vida de 30 dias, rotação no refresh. Soft-delete com janela de 30 dias antes da exclusão definitiva de PII.
Contrato de acessibilidade
prefers-reduced-motion respeitado globalmente — as animações do GSAP passam a ser apenas transições de opacidade. Rótulos de VoiceOver e TalkBack em cada elemento interativo. Verificado manualmente no iOS e no Android antes de cada lançamento.
Por que um módulo soulwise-story separado em vez de estender o cosmic-story?
Porque a especificação upstream reconstrói o recurso, e reconstruir dentro de um módulo já existente quebraria a experiência da v1 ou exigiria criar um fork para depois fazer o merge. Um novo módulo mantém a v1 intacta, deixa a v2 se provar e migra de forma limpa quando estiver pronta.
Por que MongoDB e não Postgres?
O backend atual do My Zodiac AI roda em MongoDB; mudar significaria uma decisão de infraestrutura sem relação com este recurso. O modelo de documentos também se encaixa bem com capítulos e entradas de diário — aninhados, de tamanho variável, criptografados como blob.
Por que o BullMQ foi a escolha de fila?
O BullMQ roda no Redis, que já está na stack para sessão e rate-limit. Nenhuma infraestrutura nova. Recursos nativos de retry, timeout e observabilidade cobrem as necessidades de geração de capítulos sem encanamento personalizado.
Onde a especificação upstream está realmente documentada?
No repositório interno. Os números e contratos desta página parafraseiam os artefatos do V-Model upstream. Os posts do blog de engenharia voltados ao público, no cluster de blog do My Zodiac AI (com a tag 'cosmic-story-v2'), se aprofundam em partes específicas da construção.
Experimente o My Zodiac AI hoje mesmo
Enquanto o Soulwise abre suas ondas, nosso app de astrologia carro-chefe já está nas suas mãos.
O conteúdo astrológico é para reflexão e entretenimento. Os recursos do Cosmic Story v2 descritos aqui estão em desenvolvimento; a disponibilidade pode mudar sem aviso prévio.