# Sem cadastro

Este sistema **não guarda ninguém**. Não há tela de inscrição, não há lista de e-mails, não
há tabela de gente. Quem quer saber se tem desastre por perto informa um CEP, vê a resposta
na tela, e nada fica.

Chegar a isso levou duas remoções, e as duas estão medidas abaixo. É a decisão de arquitetura
mais consequente do projeto, e a que mais código apagou.

## A primeira remoção: três fatias viram uma

O projeto original tinha `cliente`, `contato` e `endereco` — três fatias verticais, cinco
tabelas mais duas de ligação, três telas de CRUD completas.

Aquilo modelava **gestão de clientes**. Este sistema não gerencia clientes: ele avisa gente
sobre desastre. Uma inscrição bastava — quem é, onde está, por onde avisar.

```
commit 22f5035  "de PostgreSQL para SQLite; cliente/contato/endereco viram `inscrito`"
  151 arquivos    +2.718    -8.944
  a fatia `inscrito` que entrou no lugar:  25 arquivos, 1.952 linhas
```

**O que funcionava foi preservado**, movido com `git mv` para o histórico sobreviver: a busca
de CEP (BrasilAPI e ViaCEP em cadeia), a geocodificação pelo Nominatim e a validação de
e-mail. Todos três seguem em uso hoje, na consulta de alerta. Só o CRUD morreu.

## A segunda remoção: a inscrição também sai

```
commit a79308e
  26 arquivos    -2.130
  migração V002  DROP TABLE alerta_enviado;  DROP TABLE inscrito;
```

Três motivos, e nenhum deles é técnico:

1. **Uma lista de e-mails é um alvo.** O repositório é público e a aplicação fica numa VPS
   que divide máquina com outros nove serviços. O valor de invadir isto era exatamente o
   tamanho da lista — e agora é zero, porque não há lista.
2. **Dado pessoal traz obrigação.** Guardar nome, e-mail e CEP de terceiros cria dever de
   guarda, de exclusão a pedido e de aviso em caso de vazamento. Uma vitrine de portfólio não
   tem por que assumir isso.
3. **Formulário público que escreve no banco é abusado.** Sem cadastro, o caminho de abuso
   não existe: não há o que inserir. É a diferença entre *limitar* a escrita e *não ter*
   escrita.

O terceiro é o que dispensou um limitador de taxa, uma fila de moderação e uma rotina de
expurgo — três peças que precisariam existir, funcionar e ser testadas.

## O que ficou no lugar

A consulta de alerta, sem estado. Está descrita em [Alerta](/documentacao/fatia-alerta), e a
forma é:

- **`POST`, não `GET`**, mesmo sem escrever nada — o e-mail vai no corpo. Num `GET` ele iria
  na URL, que fica no log de acesso, no histórico do navegador e no `Referer`. *Idempotência
  não é o critério; onde o dado sensível trafega é.*
- **O e-mail é opcional na API.** Na tela ele serve para a pessoa ver a mensagem endereçada a
  ela; numa integração não tem uso, e exigi-lo forçaria quem integra a inventar um endereço —
  que é pior que não ter.
- **`guardado: false` está no contrato da resposta.** Não é enfeite: quem integra precisa
  poder afirmar, pelo próprio contrato, que nada foi persistido.

## Como a decisão fica travada

Uma decisão de não guardar dado pessoal é fácil de reverter por acidente: basta alguém
acrescentar uma tabela numa migração futura, e o sistema volta a guardar **em silêncio**,
porque nada mais reclamaria.

O que impede:

| trava | onde | o que ela pega |
|---|---|---|
| `naoGuardaGente` | `FluxoDeAlertaTest` | reprova se `inscrito` ou `alerta_enviado` voltarem a existir |
| `naoGuardaGente` | `EsquemaDoBancoTest` | o mesmo, mais `cliente`, `contato` e `endereco` |
| guarda de fronteira | `FronteiraArquiteturaTest` | a lista de fatias é declarada; fatia nova sem registro reprova |

As duas primeiras consultam `sqlite_master` diretamente. É de propósito: uma checagem
baseada nas classes Java passaria com a tabela existindo no banco e nenhuma entidade mapeada
— que é exatamente o estado intermediário de quem está reintroduzindo cadastro.

## Por que a V002 é uma migração nova, e não uma correção da V001

Migração aplicada é **imutável**. Reescrever a V001 para nunca ter criado as tabelas faria o
banco de quem já rodou a V001 divergir do banco de quem rodou só a versão corrigida — e as
duas se chamariam "V001". O aplicador confere o que já rodou; um `checksum` diferente para o
mesmo nome é falha de arranque, não um detalhe.

A V002 também **não é reversível**, e isso está escrito nela: ela apaga dado. Um `DOWN` que
recriasse as tabelas devolveria a estrutura vazia, o que é pior que não ter `DOWN` nenhum —
pareceria uma reversão bem-sucedida.

A ordem dos `DROP` importa: `alerta_enviado` primeiro, `inscrito` depois. A chave estrangeira
aponta naquele sentido, e a ordem inversa falha com o banco cheio e passa com o banco vazio —
o pior tipo de migração, a que só quebra em produção.