soulwise_persons
Entradas do álbum. Índices em userId, status, deletedAt. Soft-delete primeiro; hard-delete dos dados pessoais aos 30 dias.
Arquitetura do Cosmic Story v2 — uma análise aprofundada.
Para engenheiros, PMs, jornalistas e prospectores de parcerias. O pipeline completo, 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 módulos de funcionalidades.
- 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 — nada de 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; no frontend, 90% nas stores do 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 da manhã, ou a atualização do clima a cada 6 horas.
Fila
O job entra em uma fila BullMQ chamada soulwise-chapter-generation, com um timeout rígido de 28 segundos. Jobs que demoram demais são encerrados e reportados ao usuário como "tente novamente".
Compor
O ChapterGenerationService reúne o prompt de quatro fatores — contexto da pessoa, astrologia, sinal e cadência — em uma única entrada. Nenhum dado pessoal sensível (PII) do usuário entra no prompt de forma literal; tudo é higienizado 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 procura linguagem de crise; um extrator de chips de aspecto puxa de um a três chips astrológicos; um filtro anti-afirmação remove formulações proibidas; o corpo é criptografado com AES-256 usando uma chave gerenciada pela plataforma.
Persistir
O artefato é gravado na coleção MongoDB apropriada — capítulos, entradas de diário, ressonâncias — com índices userId e personId para uma busca rápida. Soft-delete primeiro; hard-delete dos dados pessoais em 30 dias.
Notificar
Um evento EventEmitter2 — CHAPTER_COMPLETED, JOURNAL_CREATED — é disparado após o commit no banco de dados. O módulo de notificações captura o evento, cria um item na caixa de entrada e, opcionalmente, envia um push (limitado a um por dia, com horários de silêncio respeitados).
Exibir
O frontend puxa 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 aspectos 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 à Luminara'.
soulwise_resonances
Pontuações em quatro dimensões por vínculo. Índice único em personId. Recalculadas por chamada de serviço após a escrita de um capítulo ou entrada do diário.
Eventos EDA
Regra rígida: os eventos são disparados somente após o commit no banco de dados. Dependências entre módulos via 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 de especificação no modelo V
119 requisitos rastreáveis, zero lacunas. Cada requisito mapeia para frente até um caso de teste (UTP, ITP, STP, E2E) e para trás até uma história de usuário. 20 histórias de usuário. 15 requisitos funcionais. 12 categorias não funcionais. 8 gates globais de aceitação.
Contrato de desempenho
Geração de capítulos em 30 segundos ou menos para 95% das requisições, medida pela distribuição de duração dos jobs do BullMQ. Latência de GET p99 da API de 500 ms ou menos com 1,000 usuários simultâneos, 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
Criptografia AES-256 em repouso com chaves gerenciadas pela plataforma para os corpos de diário e capítulos. TLS 1.2+ em trânsito; redirecionamento de HTTP→HTTPS. Tokens de acesso JWT com vida útil de 1 horas, tokens de atualização com vida útil de 30 dias, rotação na atualização. Exclusão suave com janela de 30 dias antes da exclusão definitiva de PII.
Contrato de acessibilidade
prefers-reduced-motion respeitado globalmente — as animações GSAP se tornam 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 ou quebraria a experiência v1 ou exigiria fazer um fork para depois mesclar. Um módulo novo 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; trocar significaria uma decisão de infraestrutura sem relação com este recurso. O modelo de documentos também combina bem com capítulos e entradas de diário — aninhados, de tamanho variável, criptografados como blob.
Por que a escolha de fila foi o BullMQ?
O BullMQ roda sobre o Redis, que já faz parte da stack para sessão e rate-limit. Nenhuma infraestrutura nova. Os recursos nativos de retry, timeout e observabilidade atendem às 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 V-Model upstream. Os posts públicos de engenharia no cluster de blog do My Zodiac AI (com a tag 'cosmic-story-v2') aprofundam 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 está sujeita a alterações sem aviso prévio.