\chapter{Considerações Finais}

Este trabalho partiu de uma lacuna identificada na interseção entre o
autorregistro de humor e o cotidiano de pessoas com Transtorno Afetivo Bipolar:
embora o \textit{Ecological Momentary Assessment} ofereça um caminho
consolidado para reduzir os vieses de memória e aproximar o registro do momento
em que a experiência ocorre, os aplicativos disponíveis frequentemente
fragmentam sono, humor, gatilhos e ações de cuidado em telas isoladas,
restringem a exportação dos dados e operam como soluções fechadas, com pouca
transparência sobre o uso das informações sensíveis que coletam.

Para responder a essa lacuna, foi desenvolvido o Nexo, uma aplicação móvel de
código aberto que integra esses registros em uma única linha do tempo e produz
indicadores destinados a auxiliar o usuário na percepção de padrões ao longo do
tempo. O sistema é composto por uma API REST e por um aplicativo móvel, ambos
escritos em TypeScript, com processamento de indicadores em segundo plano,
implantação automatizada e uma suíte de testes concentrada na API, conforme
descrito ao longo dos capítulos anteriores.

A pesquisa aplicada de natureza exploratória orientou as decisões de projeto. O
questionário aplicado a 48 potenciais usuários, apresentado no
Capítulo~\ref{chapter:methodologies}, e a análise de aplicativos similares
forneceram os insumos que sustentaram a definição dos requisitos, da identidade
visual e da organização do sistema, bem como a adoção do modelo incremental com
princípios ágeis e \textit{Kanban} no desenvolvimento.

Diante disso, conclui-se que os objetivos propostos foram alcançados: o
protótipo funcional entregue demonstra a viabilidade de uma solução de
autorregistro alinhada aos princípios de privacidade, transparência e autonomia
do usuário sobre os próprios dados.

O trabalho, contudo, apresenta limitações que devem ser explicitadas. A
verificação do aplicativo móvel permanece majoritariamente manual e com uma
suíte \textit{end-to-end} fina, de modo que regressões na interface podem ser
incorporadas ao código sem que nenhum teste acuse, como discutido no
Capítulo~\ref{cap:testes}. A amostra do questionário é, por conveniência, e não
pode ser generalizada; além disso, o protótipo ainda não foi submetido a uma
avaliação com usuários reais, o que deixa em aberto a confirmação de que as
escolhas de interface e de tom atendem, de fato, ao público-alvo. Por fim,
algumas decisões sensíveis --- como o rótulo de estabilidade apresentado nos
indicadores --- permanecem deliberadamente estáticas, aguardando embasamento
específico antes de se tornarem funcionais.

Os resultados obtidos abrem caminhos de continuidade que, na leitura deste
trabalho, merecem prioridade. O primeiro é a reaplicação da pesquisa junto a
usuários potenciais: repetir o questionário descrito no
Capítulo~\ref{chapter:methodologies} --- ou uma versão adaptada dele --- em uma
nova amostra, desta vez acompanhada de um teste do protótipo funcional,
permitiria comparar as expectativas registradas em 2025 com a percepção
concreta do aplicativo, avaliando usabilidade, tom de comunicação e interesse
pelas funcionalidades, e capturando ajustes antes de uma eventual implantação
mais ampla.

Uma segunda frente é a criptografia no lado do cliente para anotações e
registros de humor, de modo que o conteúdo sensível seja cifrado antes de
deixar o dispositivo e permaneça inacessível mesmo ao operador do servidor.
Essa medida responde diretamente à preocupação com privacidade registrada no
questionário, em que a maioria dos respondentes atribuiu nota máxima à
importância do controle sobre os próprios dados, e reforça o cenário de
auto-hospedagem descrito no Capítulo~\ref{sec:deploy-and-ci}.

A terceira frente é ampliar a testabilidade do aplicativo móvel, hoje
verificado de forma predominantemente manual (Seção~\ref{sec:test-mobile}).
Extrair a lógica de apresentação e de agregação em camadas testáveis, adotar
testes de componente e integrar \textit{lint}, verificação de tipos e a suíte
\textit{end-to-end} ao fluxo de integração contínua reduziria o risco de
regressões invisíveis e aproximaria o nível de confiança do \textit{frontend}
àquele já alcançado pela API.

Além dessas, as lacunas apontadas na Seção~\ref{sec:test-gaps} --- como a
maquinaria da fila fora do alcance dos testes e a duplicação manual dos dados
de teste --- sugerem ajustes de menor porte, porém de impacto relevante na
manutenibilidade do projeto a médio prazo.