\chapter{Arquitetura e Funcionamento do Sistema}

Como delineado as tecnologias no capítulo anterior, aqui se apresenta a

arquitetura, demonstrando como todas as tecnologias apresentadas acima se

conectam e conversam entre si.

\begin{figure}[h]

\centering

\caption{Arquitetura e elementos do Sistema}

\label{fig:arch}

\includegraphics[width=0.9\linewidth]{arch-v2.png}

\source{Elaborado pelo autor (2026)}

\end{figure}

Três planos compõem a arquitetura representada na Figura~\ref{fig:arch} ---

cliente, \textit{back-end} e infraestrutura ---, lidos da esquerda para a

direita. O aplicativo móvel comunica-se exclusivamente com a API por

HTTPS/JSON e mantém no dispositivo apenas o estado efêmero da interface e um

cache local dos dados já consultados; validação, autorização e regras de

domínio ficam concentradas no servidor. A API é a única porta de entrada para

os dados: acessa o PostgreSQL por meio do Prisma, grava avatares no

armazenamento de objetos e delega o trabalho que não precisa bloquear a

resposta ao usuário a filas no Valkey, consumidas por \textit{workers}

independentes. São esses \textit{workers} que enviam e-mails e notificações e

recalculam os indicadores, mantendo a API livre de tarefas de longa duração.

Essa organização tem como principal força a separação de responsabilidades em

torno de um contrato único: como o cliente só conhece a API, mudanças internas

no banco, nas filas ou nos serviços externos não o afetam, e a autenticação por

JWT permite que a API permaneça sem estado, reiniciável sem perda de sessão. O

desacoplamento por filas também torna o registro de um humor uma operação

curta, independente do custo de recalcular indicadores ou disparar

notificações. Em contrapartida, a topologia é deliberadamente monolítica e

vertical: todos os componentes são implantados em um único servidor por meio do

Docker Compose, sem replicação horizontal da API ou separação física entre

banco, fila e \textit{workers}. Isso significa que o trabalho pesado dos

\textit{workers} compete por CPU e memória com o atendimento das requisições, e

que a disponibilidade do conjunto equivale à disponibilidade desse único

\textit{host}. Trata-se de um \textit{trade-off} coerente com o porte do

projeto, mas que delimita seu principal limite de escalabilidade.

Este capítulo detalha o funcionamento de algumas funcionalidades

desenvolvidas durante o projeto. Apenas algumas funcionalidades mais

chaves são abordadas neste capítulo, como o registro de humor, o vínculo

de um gatilho, os indicadores, o registro de atividades e, por fim, a

exportação de dados e a geração de relatórios.

\section{Processo de Login}

Logo ao abrir o aplicativo, o usuário é redirecionado para a tela de

login. A tela em si é relativamente simples, e contém os campos de

email e senha. Existe aqui um elemento proposital: uma forma de

garantir um certo nível de anonimato, em que o usuário não precisa se

identificar com um nome ou número de telefone, tampouco ativar a conta

através de uma plataforma de terceiro, como Google ou Facebook.

Isso se dá, em especial, por dois motivos. Primeiro, o uso de uma tecnologia de

autenticação, como por exemplo, \textit{OAuth} \cite{Hardt:2012} exigiria uma

conexão com plataformas de terceiro, que poderiam então rastrear quais usuários

têm acesso a qual aplicativo --- algo que é fartamente documentado na literatura

sobre os mecanismos usados por tais plataformas para rastrear e monitorar o

acesso a dados de usuários, com o fim de vender e monetizar essas informações.

Essa preocupação não é hipotética: um estudo que interceptou o tráfego de rede

de 36 dos aplicativos mais populares de saúde mental (depressão e cessação de

tabagismo) encontrou transmissão de dados a pelo menos um terceiro em 92\%

deles, sendo que 81\% enviavam dados especificamente a serviços operados por

Google ou Facebook --- e apenas 59\% desses casos declaravam esse

compartilhamento em política de privacidade \cite{Huckvale2019}.

Um estudo posterior, focado exclusivamente em 27 aplicativos de saúde

mental mais populares da Google Play Store, confirmou o mesmo padrão e

o caracterizou formalmente como uma ameaça:

\begin{quote}

  A maioria dos aplicativos representa ameaças relacionadas à rastreabilidade,

  à identificação e à detecção. Isso constitui um risco, pois  alguns terceiros

  podem rastrear, reidentificar e detectar as ações e os dados dos usuários. A

  falta de conscientização também está relacionada a essas ameaças, uma vez que

  os aplicativos não explicam (por exemplo, na política de privacidade) os

  riscos que a publicidade direcionada representa para pessoas com problemas

  mentais, bem como o risco de reidentificação e divulgação de condições de

  saúde mental (por exemplo, ansiedade, depressão).

  \cite[p.~3, tradução nossa]{Iwaya:22}

\end{quote}

Como os próprios autores resumem, a mera vinculação de um usuário a um

aplicativo de saúde mental já pode revelar que essa pessoa possui uma condição

psicológica --- seja ansiedade, depressão, ou, no caso de um aplicativo como o

Nexo, Transtorno Afetivo Bipolar ---, tornando usuários desses aplicativos

particularmente vulneráveis a esse tipo de exposição \cite{Iwaya:22}.

No caso do Nexo, essa cadeia de inferência é especialmente

sensível: a presença do aplicativo na lista de apps instalados de um usuário,

associada ao seu identificador publicitário, permitiria a uma plataforma como a

Meta inferir uma possível condição de saúde mental do usuário para fins de

segmentação de anúncios, sem que este tenha conhecimento ou consentimento

explícito disso.

Segundo, e retomando a proposta de oferecer ao usuário a possibilidade

de \textit{self-service}, aquele que decidisse manter uma instância

própria do aplicativo não precisaria de uma conta em uma plataforma de

terceiro, nem se cadastrar nelas.

\begin{figure}[H]

\centering

\caption{Tela de login}

\label{fig:screenshot-login}

\includegraphics[width=0.70\textwidth,height=0.60\textheight,keepaspectratio]{screenshot-login.jpeg}

\source{Elaborado pelo autor (2026)}

\end{figure}

Por fim, destaca-se aqui que, conforme mencionado anteriormente na

modelagem de casos de uso (figura \ref{fig:use-cases}), ao realizar o

login pela primeira vez é enviado um email com um código de

verificação, seguindo a lógica dos \textit{magic links}. Isso adiciona

uma camada extra de segurança, garantindo que apenas o usuário que

solicitou o login possa acessar a conta.

\section{Página de Consulta de Registros}

A tela inicial é a tela nomeada apenas como ``Novo''. A proposta aqui

é ser a tela de cadastro rápido de um humor, e também é a tela que

visualmente mais destoa das demais. O usuário é apresentado com três

seções distintas:

\begin{itemize}

    \item Cadastro rápido de um humor

    \item Entre ontem e hoje

    \item Registros recentes

\end{itemize}

Respectivamente: uma seção em que o usuário é convidado a ``escolher

um humor'' e iniciar o processo de registro de uma nova entrada; a

seção em que são apresentados os indicadores de nível de energia

acumulado entre o dia anterior e o dia atual, além da média de sono do

dia comparada com a do dia anterior; e, por fim, a listagem dos dez

últimos registros de humor cadastrados pelo usuário.

\begin{figure}[H]

\centering

\caption{Tela de Consulta de Registros}

\label{fig:screenshot-consulta-registros}

\includegraphics[width=0.70\textwidth,height=0.60\textheight,keepaspectratio]{screenshot-initial-page.jpeg}

\source{Elaborado pelo autor (2026)}

\end{figure}

Aqui já é introduzido ao usuário um padrão de organização e hierarquia:

todos os elementos centrais são organizados em \textit{cards}, exibidos

em no máximo duas colunas. Também é introduzido, caso o usuário já

possua registros de humor cadastrados, o padrão pelo qual esses

registros são resumidos em todas as seções do aplicativo: geralmente

um ícone, um título e alguma informação adicional em destaque.

\section{Criação de Registros de Humor}

Nesta seção, o usuário pode criar novos registros de humor, escolhendo

entre uma lista de opções pré-definidas. O humor selecionado na tela

anterior é mostrado aqui, e o usuário é convidado a julgar, em uma

escala de 1 a 10, como se sente em relação aos níveis de energia,

estresse e ansiedade, respectivamente.

\begin{figure}[H]

\centering

\caption{Criação de Registros de Humor}

\label{fig:screenshot-consulta-humor}

\includegraphics[width=0.70\textwidth,height=0.60\textheight,keepaspectratio]{screenshot-create-mood.jpeg}

\source{Elaborado pelo autor (2026)}

\end{figure}

Naturalmente, é uma questão difícil de responder --- e, como o próprio

aplicativo procura deixar claro, é importante que seja um momento

reflexivo, não necessariamente preciso.

O usuário pode adicionar uma anotação sobre aquele registro em

específico, padrão que se repete em outras telas do aplicativo.

Por fim, o usuário pode escolher o que compõe aquele registro, ou

seja, selecionar emoções e estados/sentimentos que sente naquele

momento. É apresentada uma listagem mista desses elementos, na qual o

usuário seleciona os que mais se aplicam a ele e atribui um nível de

intensidade para cada um. Aqui a escala é menor e mais simples, visando

facilitar a escolha e o julgamento do usuário, entre ``Leve'',

``Moderado'' e ``Intenso'', conforme a figura

\ref{fig:screenshot-add-components}.

\begin{figure}[H]

\centering

\caption{Adicionando sentimentos/emoções}

\label{fig:screenshot-add-components}

\includegraphics[width=0.70\textwidth,height=0.60\textheight,keepaspectratio]{screenshot-add-components.jpeg}

\source{Elaborado pelo autor (2026)}

\end{figure}

Ao concluir esse processo e salvar, é apresentada ao usuário uma tela

de confirmação, na qual ele pode, opcionalmente, vincular o registro a

um gatilho específico --- que pode ter ocorrido antes de ele salvar o

registro --- ou criar um novo gatilho. O projeto novamente se ancora no

EMA, enriquecendo o registro de humor com mais contexto sobre o que

aconteceu.

\begin{figure}[H]

\centering

\caption{Vinculando um humor com um gatilho}

\label{fig:screenshot-link-mood-trigger}

\includegraphics[width=0.70\textwidth,height=0.60\textheight,keepaspectratio]{screenshot-link-mood-with-trigger.jpeg}

\source{Elaborado pelo autor (2026)}

\end{figure}

Em seguida, o usuário pode indicar o impacto que aquele gatilho

exerceu sobre o registro de humor em questão. Novamente, trata-se de

uma estimativa subjetiva, sem pretensão de precisão.

\begin{figure}[H]

\centering

\caption{Avaliando o impacto de um gatilho no humor}

\label{fig:screenshot-assess-trigger-mood-impact}

\includegraphics[width=0.70\textwidth,height=0.60\textheight,keepaspectratio]{screenshot-link-mood-assess-impact.jpeg}

\source{Elaborado pelo autor (2026)}

\end{figure}

Por fim, vale mencionar que, após esse processo, é enfileirado

internamente um \textit{background job} que recalcula, sob demanda, o

indicador de energia daquele dia, apresentado na figura

\ref{fig:screenshot-consulta-registros}. Diferentemente deste, os

indicadores semanais --- como a correlação entre sono e energia,

descrita na seção \ref{sec:insights} --- não são recalculados a cada

registro individual, sendo processados apenas pelo job semanal

agendado (seção \ref{sec:insights}).

\section{Indicadores}\label{sec:insights}

Nessa tela é apresentado um conjunto de indicadores construídos a partir

dos registros de humor, sono e gatilho do usuário. Diferente das demais

telas do aplicativo, que operam sobre dados em tempo real, os indicadores

são artefatos pré-computados: um \textit{worker} assíncrono (\textit{BullMQ})

percorre semanalmente todos os usuários ativos e enfileira, para cada

um, um conjunto de \textit{jobs} --- um por tipo de indicador --- que

processam a janela dos últimos sete dias e persistem o resultado em uma

tabela dedicada. Vale notar que nem todos os indicadores seguem esse

fluxo agendado: os indicadores diários (energia e sono) são recalculados

sob demanda, no momento em que o usuário registra um novo humor ou

sessão de sono, enquanto os indicadores semanais dependem

exclusivamente do \textit{job} de \textit{fan-out} de segunda-feira.

O aplicativo móvel apenas consulta esse resultado já

calculado, o que evita repetir cálculos custosos a cada abertura da tela

e desacopla a lógica analítica do restante da API.

\begin{figure}[H]

\centering

\caption{Tela de indicadores}

\label{fig:screenshot-insights}

\includegraphics[width=0.70\textwidth,height=0.60\textheight,keepaspectratio]{screenshot-insights.jpeg}

\source{Elaborado pelo autor (2026)}

\end{figure}

% TODO: referenciar EMA / momentary assessment como justificativa da janela de 7 dias

São três os indicadores semanais exibidos: tendência de humor, correlação

entre sono e energia, e padrão de gatilhos.

\begin{itemize}

    \item \textbf{Tendência de humor}: compara a média de humor da

    primeira metade da semana com a da segunda metade, expressando a

    diferença como uma variação percentual. O resultado é classificado

    como melhora, piora ou estabilidade a partir de uma margem de $\pm10\%$.

    \item \textbf{Correlação entre sono e energia}: relaciona a duração

    do sono de uma noite com o nível de energia relatado na manhã

    seguinte, através do coeficiente de correlação de Pearson. Exige um

    mínimo de observações pareadas para ser calculado --- caso contrário,

    o indicador simplesmente não é exibido.

    \item \textbf{Padrão de gatilhos}: identifica a categoria de gatilho

    mais frequente na semana e expressa sua predominância como percentual

    do total de registros.

\end{itemize}

É intencional, na figura \ref{fig:screenshot-insights}, que o bloco de

``Energia'' apareça vazio: o cálculo da correlação depende da existência

simultânea de registros de sono \emph{e} de humor em quantidade mínima,

e no período retratado o usuário ainda não havia acumulado dados

suficientes de ambos os tipos. Optou-se por não exibir uma correlação

calculada com poucos pontos, preferindo comunicar a ausência de dado a

apresentar um número pouco confiável.

O bloco maior no topo da tela, o ``Resumo Semanal'', condensa os

indicadores mais centrais --- média de sono do período e um rótulo de

humor (``Estável'', no exemplo). Esse rótulo, no entanto, é o elemento

mais delicado de toda a funcionalidade. Embora exista uma fórmula capaz

de produzir uma classificação de estabilidade a partir da variância dos

registros de humor, atribuir esse tipo de afirmação a um usuário ---

especialmente em um aplicativo que é utilizado por pessoas com

Transtorno Afetivo Bipolar, para quem uma leitura equivocada de

``estabilidade'' pode mascarar justamente o início de um episódio ---

exige um embasamento mais cuidadoso do que uma regra estatística

simples. Por esse motivo, o rótulo apresentado nesta versão do

aplicativo é estático (não deriva de fato do cálculo de estabilidade) e

a funcionalidade pode ser inteiramente desabilitada pelo usuário nas

configurações. A decisão de manter ou não uma afirmação automatizada

desse tipo, e sob quais critérios, permanece um ponto em aberto que

mereceria revisão de literatura específica antes de ser tratado como

funcionalidade definitiva.

% TODO: literatura sobre riscos de auto-monitoramento automatizado de humor / mood-tracking apps e TAB

\section{Histórico}\label{sec:history-analysis}

Nessa tela é apresentado o histórico consolidado de registros de humor,

sono, gatilho e ações de cuidado (como sessões de terapia), organizados

cronologicamente e agrupados por dia, conforme a figura

\ref{fig:screenshot-history}. O usuário pode ainda filtrar a listagem por

categoria (``Humor'', ``Sono'', ``Gatilho'' e ``Ações de Cuidado''),

reduzindo o volume de informação exibida.

\begin{figure}[H]

\centering

\caption{Tela de Histórico}

\label{fig:screenshot-history}

\includegraphics[width=0.70\textwidth,height=0.60\textheight,keepaspectratio]{screenshot-history.jpeg}

\source{Elaborado pelo autor (2026)}

\end{figure}

Como os quatro tipos de dado residem em recursos distintos da API, a

tela consulta os respectivos \textit{endpoints} em paralelo e, em

seguida, processa o resultado no próprio aplicativo. Para isso, é

utilizado um pequeno serviço que atua como \textit{mapper}, transformando

os dados de cada \textit{endpoint} em um formato comum, apresentado no

código \ref{lst:history-card}.

\newpage

\begin{lstlisting}[caption={Formato comum da tela de histórico}, label={lst:history-card}]

export type HistoryCard = {

  id: string; // "<category>-<id>" to avoid collisions

  category: HistoryCategory;

  subtype?: CareActionSubtype; // only set when category === "care_action"

  timestamp: string; // ISO string -- used for sorting and display

  title: string;

  summary: string;

  badge?: HistoryBadge;

  raw: MoodEntry | SleepRecord | Trigger | CareAction;

};

\end{lstlisting}

Após a normalização, os quatro conjuntos de dados são combinados em uma

única lista ordenada pelo campo \texttt{timestamp} e reagrupados por dia

para exibição, conforme visto na figura \ref{fig:screenshot-history}, nos

cabeçalhos ``terça-feira, 14 de julho'' e ``segunda-feira, 13 de julho''.

Essa unificação é proposital: ao invés de apresentar quatro telas

separadas por tipo de dado, o histórico busca reconstruir uma narrativa

única do dia do usuário, aproximando-se do princípio de \textit{Ecological

Momentary Assessment} já mencionado anteriormente --- o contexto de um

registro de humor (por exemplo, o gatilho ``Interno'' registrado três

minutos antes, na mesma figura) fica visualmente próximo do evento que

possivelmente o motivou.

A propriedade \texttt{raw} armazena o dado original, permitindo que a

listagem redirecione o usuário para a tela de detalhe correta ao tocar em

um card, independentemente da categoria. Já a propriedade \texttt{badge}

reaproveita o mesmo mecanismo já descrito na seção de indicadores: para

um registro de sono, sinaliza se a duração foi insuficiente; para um

registro de humor, destaca a dimensão mais relevante daquele registro

(como ``Ansiedade alta'' na figura \ref{fig:screenshot-history}); para um

gatilho, indica sua categoria, e assim por diante.

\section{Exportação de Dados e Relatórios}\label{sec:export-report}

Além das telas de consulta e análise, o Nexo oferece duas formas de

levar os dados para fora do aplicativo: a exportação integral dos

registros, em formato aberto, e a geração de um relatório resumido em

PDF. Ambas materializam o princípio de soberania dos dados discutido nos

capítulos anteriores --- princípio reforçado pelo questionário, em que a

maioria dos respondentes atribuiu nota máxima à importância de ter

controle total sobre as próprias informações. A diferença entre as duas

reside no propósito: a exportação devolve a totalidade dos dados em um

formato legível e processável, enquanto o relatório condensa um período

específico em um documento pronto para ser guardado ou compartilhado com

um profissional de saúde.

A exportação é acionada na tela de configurações, na opção ``Exportar

Meus Dados''. Antes de disparar o processo, o aplicativo pede uma

confirmação e informa que o arquivo será enviado para o e-mail cadastrado

--- um lembrete explícito de que aquela operação retira dados do

dispositivo e os entrega por um canal externo.

% TODO: adicionar screenshot da tela de exportação (modal de confirmação)

Do ponto de vista técnico, a solicitação enfileira um \textit{job}

assíncrono na mesma infraestrutura de filas descrita na

seção~\ref{sec:insights}. O \textit{worker} percorre todas as entidades

associadas ao usuário --- perfil, humores e seus componentes, sono,

gatilhos e seus vínculos, ações de cuidado, medicamentos, consultas,

atividades e os indicadores já calculados --- e serializa cada uma em um

arquivo CSV próprio, com os rótulos traduzidos e os valores enumerados

convertidos para texto legível. Os arquivos são compactados em um único

\textit{zip}, acompanhados de um manifesto com a data de geração, e o

pacote é anexado a um e-mail enviado ao usuário; em caso de falha, um

e-mail de erro é disparado em seu lugar. O resultado é uma exportação

completa e portátil: nenhum campo é omitido ou agregado, de modo que o

usuário pode reimportar os dados em outra ferramenta ou auditá-los

diretamente --- alinhado à exigência de portabilidade levantada nos

requisitos não funcionais.

O relatório, por sua vez, é gerado sob demanda a partir da tela

``Relatório'', acessível também pelas configurações. O usuário escolhe um

período --- por meio de atalhos de 7, 30 ou 90 dias, ou um intervalo

personalizado limitado a 90 dias --- e aciona ``Gerar relatório''.

\begin{figure}[H]

\centering

\caption{Tela de geração de relatório}

\label{fig:screenshot-report}

\includegraphics[width=0.70\textwidth,height=0.60\textheight,keepaspectratio]{screenshot-report-initial.png}

\source{Elaborado pelo autor (2026)}

\end{figure}

O servidor reúne os registros de humor do período e os renderiza em um

PDF intitulado ``Relatório de Humor e Bem-Estar'', produzido com

\textit{@react-pdf/renderer} e devolvido ao aplicativo, que o oferece

pela folha de compartilhamento nativa do sistema --- permitindo salvá-lo

ou enviá-lo a um terapeuta. O documento é dividido em duas páginas: a

primeira traz uma visão geral (total de \textit{check-ins}, humor

predominante e dias rastreados), a distribuição percentual de cada humor

e um mapa de calor diário; a segunda lista os sentimentos e emoções mais

frequentes, com a intensidade média, e o registro detalhado dos

\textit{check-ins}, com os níveis de ansiedade, estresse e energia.

Cabe registrar, contudo, que o relatório desta versão cobre apenas os

dados de humor. A intenção original era incorporar também o sono, as

atividades e os padrões de gatilho --- inclusive a correlação entre sono

e energia já calculada nos indicadores ---, mas essa ampliação foi

adiada para uma versão futura. Como consequência, o relatório atual

complementa, mas não substitui, a exportação integral: para uma visão

completa de todos os tipos de dado, o usuário ainda recorre ao

\textit{zip} de CSV.

\FloatBarrier