# 2 — Decisões

Cada item traz o que foi decidido, o porquê, e o que foi descartado. Contrariar qualquer uma
delas é possível, mas exige justificativa — várias custaram medição.

---

## D1 — Construir em vez de comprar

Existem ferramentas maduras de aprovação: ReviewStudio (US$ 12–15 por usuário/mês, convidados
grátis), Filestage (plano grátis com 10 membros e 2 GB, pago a partir de US$ 199/mês), Picflow.
Todas resolvem comentário com pino e versionamento.

Nenhuma faz a regra 1 do produto: esconder o comentário do cliente da equipe interna até o
prazo fechar. Elas assumem o fluxo inverso.

Além disso, o objetivo declarado é **vender a plataforma para outros estúdios**, não só usar
internamente. Isso descarta comprar assento de terceiro por definição.

## D2 — Multi-inquilino desde a primeira linha

Cada estúdio é um inquilino isolado. Toda tabela de negócio carrega `estudio_id`, e toda
consulta filtra por ele.

É barato agora e caríssimo depois — enfiar isolamento em um schema pronto é reescrever o
banco e auditar cada query. Como o produto nasce para ser vendido, não existe versão
"só nossa" que depois vira multi-inquilino.

## D3 — Hostinger compartilhado para começar

O plano Unlimited já está contratado. Os limites reais medidos contra a carga prevista:

| recurso | plano | uso por rodada de 14 imagens |
|---|---|---|
| Inodes | 600.000 | 1.475 |
| Disco NVMe | 50 GB | 776 MB |
| PHP workers | 60 | 2 a 3 simultâneos |
| RAM | 3 GB | ~64 MB por request |
| Bancos MySQL | 150 | 1 |
| Banda | não medida | — |

O gargalo é disco, não inode: 64 rodadas guardando o original de cada imagem, ou mais de mil
guardando só as pirâmides. Banda não medida importa muito aqui — imagem pesada em provedor
que cobra egress vira o maior custo da operação.

Descartado por ora: Cloudflare Pages + R2 + Supabase. Tecnicamente melhor (CDN na borda,
egress grátis no R2), mas adiciona duas contas, e o free do Supabase pausa o projeto após
uma semana sem uso — inviável para uso em rajadas. Vira a escolha certa quando o volume
justificar sair do compartilhado.

## D4 — PHP + MySQL, sem framework pesado, sem etapa de build

Hospedagem compartilhada entrega PHP e MySQL. Node em compartilhado é limitado.

Frontend em HTML, CSS e JS puro: os protótipos já estão assim, deploy é copiar arquivo, e não
há pipeline de build para quebrar. Se depois entrar um framework, que seja por necessidade
comprovada.

## D5 — Processamento de imagem fora do servidor web

Gerar pirâmide de um PNG de 128 MB estoura memória e tempo de execução em PHP compartilhado.

O upload entra por um endpoint que só grava o arquivo. O processamento roda separado — um
worker acionado por cron, ou a máquina do estúdio antes de enviar. O servidor web nunca abre
um PNG grande.

## D6 — Pirâmide de tiles WebP q95, com o original preservado

Medido no arquivo real `5500 × 3094`, PNG de 92,8 MB:

| formato, resolução total | tamanho | PSNR |
|---|---|---|
| PNG original | 92,8 MB | referência |
| WebP sem perdas | ~13,8 MB | idêntico |
| **WebP q95** | **~2,5 MB** | **44,8 dB** |
| JPEG q95 4:4:4 | ~4,6 MB | 46,6 dB |
| JPEG q82 | ~1,6 MB | 42,1 dB |

Acima de 44 dB não se distingue na tela. A pirâmide completa em WebP q92 deu 3,08 MB contra
92,8 MB do PNG — o peso está no container, não nos pixels.

Ver a imagem inteira custa ~0,05 MB de tráfego; inspecionar um trecho em 1:1 custa mais
~0,3 MB. O original fica guardado para download sob demanda.

Tile de 512 px. Método e números em `docs/06-medicoes.md`; gerador em `scripts/`.

## D7 — Normalizar cor e remover alfa na entrada

Nos 14 arquivos do caso real: 11 sem perfil de cor embutido, 3 com sRGB. Arquivo com e sem
perfil renderiza diferente no navegador e no Photoshop — vira discussão de cor com o cliente
durante a aprovação.

Todos os PNGs vieram em RGBA. Em 4 o alfa era opaco (inútil, ~25% de peso à toa) e em 6 havia
transparência real — todos exports `_interactive_lightmix`, ou seja, padrão do setup de
exportação, não acaso.

A entrada crava sRGB IEC61966-2.1 e remove o alfa opaco. Transparência real levanta aviso e
não bloqueia.

## D8 — Cliente entra por link, sem conta · **REVISADO**

> **Texto original.** Token opaco por rodada, na URL. Sem cadastro, sem senha. Regenerável, e
> regenerar invalida o anterior na hora. Exigir cadastro do cliente é o principal motivo de
> estúdio abandonar esse tipo de ferramenta. O risco de link vazado é aceitável e mitigável
> por regeneração e prazo.

O argumento estava certo e a conclusão era larga demais: **tratava todo mundo do lado do
cliente como a mesma pessoa.** Não são. Separando por frequência de uso, a decisão se resolve
sozinha:

| quem | com que frequência usa | como entra |
|---|---|---|
| **Gerente do cliente** | toda semana, o ano inteiro | e-mail e **senha** |
| **Revisor** | uma vez por rodada | **só e-mail**, por link pessoal |

O medo do D8 — "se precisar criar conta, o estúdio não usa" — vale para o revisor, que aparece
uma vez, não tem nada em jogo e abandona no primeiro cadastro. Não vale para quem coordena a
revisão: essa pessoa quer voltar, quer ver o histórico e, principalmente, **quer organizar
quem revisa sem depender do estúdio**. Para ela, senha é serviço, não atrito.

**"Só e-mail" não é digitar o e-mail e entrar.** Isso deixaria qualquer um ler o projeto
sabendo um endereço. É link mágico: digita o e-mail, recebe um link de uso único, entra, e o
aparelho fica reconhecido por 30 dias. Da parte dele continua sendo "sem senha". A caixa de
e-mail vira o fator de autenticação — o mesmo nível do "esqueci a senha", que é como
todo mundo entra em tudo de qualquer jeito.

**O que se ganha além da conta:** link por pessoa em vez de link por rodada. O comentário sai
assinado sem precisar perguntar quem é você, e tirar o acesso de uma pessoa não derruba o das
outras.

**O link aberto continua existindo**, desligado por padrão, por projeto. É a saída para o
cliente que se recusa a abrir e-mail — o caso que motivou o D8 original. Ligado, o comentário
de convidado não tem autor confiável, e a interface diz isso na hora de ligar.

Detalhe em `docs/11-contas-e-emails.md`; modelo de dados em `sql/schema-v2.sql`.

## D9 — Interface sem jargão

O usuário não deve encontrar "pirâmide", "tile", "sRGB", "canal alfa" ou "inode" em lugar
nenhum da interface. Enquanto processa, diz "preparando". O que o sistema conserta sozinho,
conserta calado.

Só interrompe o que exige decisão humana. No caso comum não há nada a decidir.

## D10 — Criar projeto pede dois campos

Nome do projeto e nome do cliente. Uma versão anterior pedia código, padrão de nome de
arquivo, lista de ambientes e pasta de referência. Nada disso é necessário para funcionar, e
campo a mais no cadastro é abandono.

Título da imagem sai do nome do arquivo, limpo, e é editável clicando.