backspace/docs/roadmap-resenha.md

Roadmap — fork Resenha

Plano de features próprias desta instância. Arquivo exclusivo do fork (nome com sufixo para não colidir com arquivos do upstream em merges).

Escrito em português por ser documento de planejamento do dono do fork; o código e os commits seguem em inglês, como o resto do repositório.

Entregue

Feature	Commit	Nota
Ir para a call clicando no nome do canal	c70b0095	Exigiu o voiceStore passar a guardar o espaço da call — antes ele não sabia onde a call estava assim que o usuário navegava para outro servidor
Botão de GIF redesenhado	20526e1b	Contorno vazado com letras cheias, no lugar do bloco sólido
Explorador de GIF no banner	20526e1b	Sem upload: banner já aceita URL absoluta no cliente e no servidor
Teste de microfone com retorno	bfe62d70	AudioManager.startMicTest/stopMicTest; devolve o microfone ao parar, com duas travas independentes
Bloco de atividade no perfil	d7da0ff2	ProfileActivity; inclui correção de validação de assets no servidor
Preview de perfil nos participantes da call	(ver git log)	O popout já existia e era aberto de 11 lugares; nenhum era de voz. Ligado nas linhas da lista de voz e no nome dos tiles da grade

Já existia no código (verificado, não construir de novo)

• Animação de digitação — TypingIndicator.tsx, três pontos animate-bounce escalonados em 0/150/300ms.
• Sons de call/stream — SoundController.tsx, montado no AppLayout: stream started/ended, alguém entra/sai da tela, entra/sai da call, câmera, mute, ringing. Os .ogg estão em web/public/sounds/.
• Preview de perfil ancorado — uiStore.openUserProfile(user, anchor, placement) guarda userProfilePopout; popout posicionado no desktop, tela cheia no mobile. Já era aberto por mensagens, menções, avatares, lista de membros, DMs e painel de atividade. O que faltava era só a voz — agora ligado. Continua faltando o bloco de atividade do print do Discord, que é a #8.

Se qualquer um dos dois não se manifestar em uso, o trabalho é depuração, não implementação.

Pendente — pedido original

Ordem sugerida: as pequenas primeiro, as grandes uma de cada vez.

#	Feature	Tamanho	Observação técnica
6	Favoritar GIFs + categorias	Grande	Precisa de tabela, migração drizzle e API para sincronizar entre dispositivos, como no Discord
8	Produtor de atividade do Spotify	Grande	O consumo está pronto (ProfileActivity + pipeline completo). Falta algo que gere a atividade com faixa e artista — ver abaixo
9	Registro de auditoria	Grande	Schema + ganchos em cada mutação do servidor + interface

Pendente — ideias aprovadas

Feature	Tamanho	Observação técnica
Soundboard	Média	AudioManager já carrega e toca .ogg sob demanda; falta upload por espaço, permissão e disparo na sala LiveKit
Estatísticas do grupo	Grande	Horas em call, quem mais falou, ranking. Depende do mesmo registro de eventos da auditoria (#9)
Watch party	Grande	O screen share do LiveKit já existe; falta sincronizar posição de reprodução entre participantes
Emojis e stickers do grupo	Média	UPLOAD_DIR e o pipeline de upload já existem; falta tabela por espaço e resolução no render de mensagem

O que falta para o Spotify (#8)

O caminho de consumo está inteiro: tipo, store, WebSocket, validação no servidor, relay de presença e agora o bloco no perfil. Falta um produtor.

Três opções, com custos bem diferentes:

1. Entrada no dicionário do detector (activityDetector.ts lê um JSON de processos, e listening já é um tipo válido). Custo quase zero, mas dá apenas "Listening to Spotify" — sem faixa nem artista — e só no app Electron.
2. Ler o título da janela do Spotify no processo main do Electron. O título é "Artista - Faixa", então preenche details e state. Ainda só desktop, e sem capa nem duração.
3. Spotify Web API com OAuth. É a única que cobre quem usa pelo navegador — que é a maioria do grupo — e a única que traz capa e progresso. Bloqueio: exige registrar um app no dashboard do Spotify e obter client id/secret. Isso é ação sua; eu não consigo fazer.

Regra de idioma (a partir de 2026-08-31)

Funcionalidade nova sai com interface em pt-BR, e a cada update um sistema existente é traduzido. Os dois idiomas coexistem. Código, comentários e commits seguem em inglês.

Pré-requisito não óbvio: o projeto não tem sistema de i18n algum — as strings estão fixas em inglês dentro dos componentes. Traduzir "um sistema por update" só é possível depois da fundação abaixo.

Ideias novas — a avaliar

Ordenadas por relação valor/custo para um servidor de grupo fechado.

Sistema	Tamanho	Por que faz sentido aqui
Fundação de i18n	Média	Bloqueia a regra de idioma acima. Dicionário por idioma + hook de tradução + seletor nas configurações; migração componente a componente, um por update
Fechar cadastro + convites	Pequena	A instância está com REGISTRATION_OPEN=true: qualquer um cria conta. O InviteModal já existe — é trocar cadastro aberto por convite
Backup fora da VPS	Pequena	Hoje app, banco, uploads, backups e as três cópias do repositório morrem no mesmo evento. Um envio periódico para fora resolve
Aniversários e lembretes	Pequena	Alto retorno afetivo, custo baixo: campo de data + verificação diária + mensagem no canal
Perfis por servidor	Média	Apelido e avatar diferentes por espaço, como no Discord. O modelo já tem membro por espaço
Eventos agendados com presença	Média	"Sexta 21h" com confirmação. Encaixa nas notificações e no PWA já instalado
Notificações push de verdade	Média	O vite-plugin-pwa e o service worker já estão lá; falta Web Push (VAPID) e o registro no servidor
Níveis e conquistas	Média	Gamificação por tempo em call e mensagens. Mesmo registro de eventos da auditoria e das estatísticas — três features, um mecanismo
Clipes de call	Grande	"Salvar os últimos 30 segundos" depois de alguém falar besteira. O LiveKit tem egress; exige buffer contínuo e armazenamento
Fila de música compartilhada	Grande	Um participante-robô publicando faixa de áudio na sala LiveKit. É o que mais muda o uso de um servidor de amigos, e o mais caro
Autenticação em duas etapas	Média	Só faz sentido depois de decidir o modelo de cadastro

Dependência que vale respeitar

Auditoria (#9) e Estatísticas compartilham o mesmo mecanismo: uma tabela de eventos append-only no servidor. Construir a auditoria primeiro e as estatísticas como leitura agregada dessa mesma tabela evita escrever dois sistemas de registro paralelos que divergem com o tempo.