# 9 — Melhorias sobre a especificação inicial

Revisão feita em cima de `docs/01` a `08` e dos quatro protótipos originais. Cada item traz o
que muda, por que, e o que foi descartado. Onde a mudança mexe no banco, o efeito está em
`sql/schema-v2.sql`; onde mexe na interface, está em `prototipos/v2/aprova.html`.

As três regras de `01-produto.md` continuam de pé — nenhuma melhoria aqui as contraria.

---

## M1 — Aprovação explícita por item · MUDA O BANCO

O produto se chama Aprova e não tinha estado de aprovação. O cliente comentava, e a ausência
de comentário era interpretada como concordância. Não é a mesma coisa: silêncio pode ser
"está bom" ou "ainda não olhei", e o estúdio não tinha como distinguir.

Cada versão de cada item passa a ter três estados do lado do cliente:

| estado | quem define | significa |
|---|---|---|
| `pendente` | padrão | ainda não foi olhado |
| `aprovada` | o cliente, com um clique | fechado, pode seguir |
| `ajustes` | automático ao primeiro comentário | tem pedido pendente |

`ajustes` nunca é escolhido à mão: comentar já diz o que precisa dizer. Um botão a menos.

Isso muda o painel inteiro. "11 de 14 aprovadas" é o número que o estúdio quer, e ele não
existia. A grade passa a ser um quadro de situação em vez de uma lista de arquivos.

**Descartado:** aprovação com assinatura ou aceite formal. Vira contrato, atrasa o clique, e o
registro em `eventos` já dá a prova de quem aprovou o quê e quando.

## M2 — Vídeo e animação entram na primeira versão · MUDA O BANCO

`01-produto.md` deixou vídeo fora de escopo. Estúdio de archviz entrega animação junto com a
imagem estática, na mesma rodada. Uma ferramenta de aprovação que aceita metade da entrega
manda o cliente de volta para o WhatsApp na outra metade — e aí o registro, que é o valor do
produto, fica pela metade também.

O comentário passa a guardar o instante do vídeo além do ponto na tela. Na linha do tempo os
comentários aparecem como marcadores; clicar num deles leva o vídeo para aquele segundo.
É o padrão que o mercado já ensinou ao cliente.

**Consequência técnica que não estava prevista.** `03-arquitetura.md` dimensionou disco e
tráfego para imagem. Vídeo muda a conta:

- O arquivo de entrega (ProRes, EXR em sequência) não é servível. Precisa de uma cópia de
  revisão em H.264 1080p, ~5 Mbit/s — cerca de 15 MB para 24 segundos.
- Hospedagem compartilhada não costuma ter `ffmpeg`. A conversão vai para a máquina do
  estúdio, exatamente como D5 já resolveu para a pirâmide.
- Servir vídeo exige atender `Range` no endpoint PHP, senão o cliente não consegue arrastar a
  linha do tempo sem baixar o arquivo inteiro. São umas trinta linhas, mas precisam existir.

**Descartado:** deixar para a fase 5. O custo de entrar agora é a coluna `tipo` e um player;
o custo de entrar depois é reabrir o modelo de dados com projeto rodando.

## M3 — Marcação de área e de seta, não só o pino

O pino resolve "aqui". Boa parte do retorno real não é pontual:

- *"essa parede inteira está texturizada"* — é uma região
- *"puxa esse vaso para junto da janela"* — é uma direção, tem origem e destino

Com só um ponto, o cliente escreve mais para compensar, e escrever mais é onde a ambiguidade
entra. Três ferramentas cobrem o que aparece na prática: ponto, área e seta.

No banco isso custa duas colunas. Área e seta são o mesmo dado — dois pares de coordenadas —
e só mudam no desenho. Pino usa um par e deixa o outro nulo.

## M4 — Conversa dentro do comentário · MUDA O BANCO

O modelo original tinha `resposta TEXT` no comentário: um campo, uma resposta, fim. Não
resolve o caso mais comum, que é o estúdio precisar perguntar de volta.

> — A cor das paredes deveria puxar mais para o bege.
> — Bege como o do lounge ou o do briefing? São diferentes.

Sem isso, essa pergunta vai para o WhatsApp e o registro se rompe justo no ponto que
interessa. Vira tabela `comentario_respostas`, com autor dos dois lados e ordem cronológica.

A resposta da equipe continua invisível para o cliente enquanto a rodada não fecha — mesma
lógica de fase, na direção contrária.

## M5 — Anexo no comentário · MUDA O BANCO

`04-modelo-de-dados.md` previu `ref_path` no espaço: uma referência de briefing por imagem.
Não cobre a referência que pertence a um pedido específico — a foto da cadeira, o print do
catálogo, o recorte da pedra. No caso 056, vários apontamentos eram literalmente "conferir
imagem de referência", e a imagem estava em outro lugar.

Tabela `anexos`, ligada ao comentário. O anexo é do pedido, não do ambiente. Os dois convivem.

**Três formas de anexar, porque as três acontecem:** escolher o arquivo, arrastar para cima
do campo, e **colar**. Colar é a mais usada e a mais esquecida — quem manda referência de
cadeira ou de pedra vem de um print, e obrigar essa pessoa a salvar o print em disco antes é
onde ela desiste e volta para o WhatsApp.

Clicar no anexo abre a imagem no painel lateral, o mesmo que exibe a referência do briefing.
Se o item tiver as duas, um botão alterna. Reaproveita o painel em vez de inventar uma janela.

## M6 — Importar o retorno que chegou por fora

`origem ENUM('plataforma','importado')` já existia no schema, sem tela. Vale virar recurso de
verdade, porque é o que faz a plataforma ser adotada em vez de abandonada na primeira rodada.

O cliente não muda de hábito porque o estúdio comprou uma ferramenta. Na rodada 1 ele ainda
manda por WhatsApp. A tela recebe o texto colado, quebra em itens por linha, e o estúdio
arrasta cada item para a imagem certa. O apontamento entra marcado como importado, com o
nome de quem falou.

Não é elegante. É a ponte, e sem ela a rodada 1 acontece fora da plataforma — o que significa
que a rodada 2 também.

## M7 — A trava da equipe passa a se explicar

A regra 1 é o que diferencia o produto. Na v1 ela aparecia como ausência: a equipe abria o
projeto e não havia nada. Ausência sem explicação é lida como defeito, e defeito percebido
vira chamado de suporte ou, pior, alguém pedindo para desligar a regra.

Duas correções:

**A equipe continua vendo as imagens.** O que fica escondido é o retorno do cliente, não o
trabalho dela. Esconder o projeto inteiro é mais do que a regra pede.

**A trava diz o motivo, no lugar onde ela acontece.** No lugar da lista vazia, uma frase:
enquanto a janela está aberta, um revisor ainda pode mudar de ideia ou contradizer o outro, e
corrigir agora costuma virar retrabalho.

Custo: um parágrafo. Efeito: a limitação passa a ser lida como método.

## M8 — Escuro neutro na revisão, claro na gestão

Os protótipos originais revisavam a imagem sobre `#f6f3ef` — bege claro. O entorno desloca a
cor percebida, e cor é exatamente o que está sendo aprovado. Discussão de tom de terracota
sobre fundo bege é discussão contaminada pela ferramenta.

O visualizador vai para cinza neutro sem tinta. A gestão continua clara e quente — ali não há
julgamento de cor e o claro lê melhor em texto e formulário.

Além disso, um seletor de entorno com quatro opções (preto, grafite, cinza médio, cinza
claro). Quem trabalha com imagem conhece esse controle do Photoshop e sente falta dele.

## M9 — O campo de escrever fica no ponto marcado

Marcar na imagem e escrever num painel do outro lado da tela quebra a ligação entre as duas
coisas — e é onde o comentário perde precisão, porque quem escreve já não está olhando o
ponto.

O campo abre ancorado na marcação, com o texto a poucos pixels do que ele descreve.

## M10 — Relatório da rodada sobe da fase 4 para a fase 2

Estava listado como último item da fase 4, junto com cobrança e notificações. É o argumento
de venda mais forte que o produto tem, e o mais barato de construir: é uma leitura da tabela
`eventos`, que já existe.

*"Três meses depois, ninguém prova o que foi pedido e quando"* é um dos quatro problemas de
`01-produto.md`. Os outros três já tinham resposta na fase 2; esse ficou para o fim.

Uma página com a linha do tempo, a situação de cada item e a lista de pedidos com autor e
horário. Imprimível.

## M11 — Atalhos de teclado

O estúdio percorre 14 imagens várias vezes por dia. Setas para navegar, `F` para ajustar,
`1` para resolução total, `C` para comparar, `R` para a referência, `A` para aprovar, espaço
para tocar o vídeo. `Esc` fecha, e fecha primeiro o comentário em edição.

Custo baixo, e é a diferença entre a ferramenta parecer profissional ou parecer um site.

## M12 — Progresso visível para o cliente

A falha mais comum de revisão não é o cliente discordar: é ele revisar seis das quatorze e
achar que terminou. Uma barra no topo — *"8 de 14 revisadas"* — e o botão de encerrar só
ganha peso quando o número fecha.

## M13 — Etapas de produção com check da equipe · MUDA O BANCO

A execução era uma lista de comentários com um campo de situação. Isso descreve o pedido do
cliente, não o trabalho do estúdio. São coisas diferentes: um comentário pode estar resolvido
sem que a imagem esteja pronta, porque ainda falta render e pós.

Cada projeto ganha um pipeline de etapas — modelagem, materiais, iluminação, render,
pós-produção, revisão interna. Vem de um modelo por estúdio, porque cada casa tem o seu, e é
copiado para o projeto quando ele nasce: projeto começado não pode mudar de forma porque
alguém editou o modelo depois.

Cada item em produção tem um estado por etapa: não começou, fazendo, feita, não se aplica.

**A interface é uma matriz item × etapa, não um kanban.** Kanban assume que o trabalho anda
peça por peça. Não é o que acontece em archviz: o artista faz a iluminação das seis imagens
de uma vez, depois manda todas para render. Na matriz dá para ler a coluna inteira e ver o
que falta naquela etapa — e marcar a coluna toda de uma vez.

Só entra na matriz o que o cliente pediu para ajustar. Item aprovado está fechado e não
aparece, o que mantém o quadro do tamanho do trabalho real.

O comentário pode apontar para uma etapa. É opcional, e é o que permite puxar "todos os
ajustes de iluminação de todas as imagens" numa lista só.

**O estúdio edita o pipeline.** Não existe pipeline universal de archviz, e um que não se
ajusta é abandonado na primeira semana. A tela de etapas permite renomear, reordenar,
adicionar e remover, em dois níveis:

| onde | vale para | quando aplica |
|---|---|---|
| Modelo do estúdio | projetos novos | na criação do próximo projeto |
| Etapas deste projeto | só ele | na hora |

Editar o modelo não mexe em projeto rodando. Projeto que já começou não muda de forma porque
alguém ajustou o padrão da casa depois — é a mesma razão pela qual `etapas` é uma cópia e não
uma referência a `etapas_modelo`.

**Cada etapa diz para que tipo ela vale:** imagem, vídeo, ou os dois. Sem isso, toda linha de
vídeo no quadro exigia marcar "não se aplica" à mão nas etapas que só existem para render
estático — trabalho manual para uma informação que o sistema já tem. Pós-produção sai só nas
imagens; montagem e trilha, só nos vídeos.

**Editar um projeto em andamento avisa o que vai acontecer.** As duas consequências são reais
e nenhuma é óbvia:

- Etapa nova entra como não iniciada em todo item, e o percentual que o cliente vê **cai**.
  A tela mostra o número antes e depois: *"vai de 39% para 33% — ele vai ver o número cair"*.
- Etapa removida leva junto a marcação já feita. A tela nomeia quais etapas têm trabalho
  registrado antes de deixar salvar.

Ferramenta que deixa o número do cliente cair sem avisar queima confiança uma vez só.

**Descartado:** prazo e horas por etapa. Vira controle de ponto, é o tipo de campo que o
artista deixa de preencher na segunda semana, e aí o quadro inteiro perde confiabilidade.

**Descartado:** arrastar para reordenar. Setas para cima e para baixo funcionam com teclado,
não quebram no toque e não custam biblioteca. Arrastar entra quando a lista passar de dez
etapas, se passar.

## M14 — O cliente acompanha a correção, se o estúdio quiser · MUDA O BANCO

Entre "comentei" e "chegou a v2" o cliente ficava no escuro por dias. Esse silêncio é a
origem da mensagem *"e aí, como está?"* — que chega no WhatsApp, fora da plataforma, e leva
junto o resto da conversa.

Depois que a janela fecha, a página do cliente ganha um painel: percentual concluído, data
prevista para a próxima versão, e a situação de cada item que ele pediu para ajustar.

**O cliente não vê a matriz.** Vê o rótulo público da etapa mais avançada de cada item —
*"Iluminação"*, *"Renderizando"*, *"Pronta para a próxima entrega"*. Cada etapa carrega uma
marca de pública ou interna: revisão interna, por exemplo, conta no percentual mas não
aparece. Vários nomes internos podem cair no mesmo rótulo público quando o estúdio preferir
dar andamento sem expor o método.

**E dá para desligar.** Interruptor por projeto, na tela de envio e no cabeçalho do quadro.
Há cliente e há contrato em que mostrar produção não ajuda — quem decide é o estúdio, não a
plataforma. Ligado por padrão, porque o ganho de confiança compensa na maioria dos casos.

A data prevista é o que o cliente realmente quer saber. Ela é digitada pelo estúdio, não
calculada: estimativa automática de entrega em produção criativa erra, e errar uma data que
a ferramenta prometeu é pior do que não prometer nada.

**Descartado:** notificar a cada etapa concluída. Seis etapas × quatorze itens é spam. O
cliente é avisado quando a versão sobe; o painel fica lá para quem quiser olhar antes.

## M15 — Lista de tarefas: a área interna do estúdio · MUDA O BANCO

> Primeira tentativa descartada. Ela era uma tabela de itens agrupada por situação do cliente
> — aprovado, com ajustes, sem retorno. Isso é relatório de situação, não organização de
> trabalho: reproduzia a visão do cliente numa tela que existe para a equipe. O eixo estava
> errado desde o começo.

**A linha é a tarefa, não o item.** E o eixo padrão é quem faz.

Tarefa é qualquer coisa a fazer num item, de duas procedências:

- **pedido do cliente** — o comentário que chegou pela janela de revisão
- **tarefa interna** — o que o estúdio se dá para fazer, e que o cliente não vê

No banco são a mesma linha de `comentarios`, com autor de lados diferentes: `revisor_id` para
o cliente, `usuario_id` para o estúdio. A coluna já existia no schema e nunca tinha sido usada.
O filtro do que o cliente enxerga é um único ponto no acesso a dados, não uma regra repetida
em cada tela — e, no servidor, precisa valer em toda rota.

Isso fecha um buraco que a especificação inteira tinha: **não havia como registrar trabalho
que não veio de reclamação do cliente.** "Trocar o HDRI, está estourando o vidro", "conferir a
câmera contra a planta", "render final em 5000 px" — nada disso é pedido de ninguém, e é a
maior parte do que o estúdio faz numa rodada.

**Colunas:** situação, tarefa, item, arquivo de origem, responsável, etapa.

O arquivo de origem é coluna porque é por ele que o artista se acha no explorador e no
3ds Max. O título é o que o cliente lê; o nome do arquivo é o que a equipe abre.

**Agrupar por responsável, etapa, item ou situação.** Por responsável responde "quem está com
o quê"; por etapa responde "o que falta na iluminação"; por item responde "o que ainda pega
nesta imagem". O balde **Sem responsável** vem sempre primeiro — é dele que o coordenador tira
o que ainda não repassou.

**"Só as minhas"** transforma a mesma tela na lista pessoal do artista. Gerente e artista usam
a mesma tela com filtro diferente, em vez de duas telas que divergem com o tempo.

**Criar tarefa dentro do grupo já herda o grupo.** Criada dentro de "Iluminação", nasce na
iluminação; dentro de "Pós-produção", nasce atribuída. Evita o segundo passo que faz a pessoa
desistir de registrar.

**A situação avança num clique na bolinha** — pendente, em execução, resolvido. É o gesto mais
repetido do dia; não pode custar abrir um menu.

**Descartado:** deixar o usuário montar as colunas. Seis cobrem o caso, e editor de colunas é
a porta de entrada para virar planilha — que é o que a plataforma existe para substituir.

**Descartado:** prazo por tarefa. O prazo que importa é o da rodada, e prazo por tarefa em
estúdio pequeno vira campo que ninguém preenche.

## M16 — Cada um edita o que escreveu · MUDA O BANCO

Faltava o óbvio: escrever errado e não poder corrigir. O cliente manda "parede bege" quando
queria dizer "terracota" e não tem como consertar — sobra mandar outro comentário desdizendo
o primeiro, e a equipe fica com dois pedidos contraditórios na fila.

| quem | edita | quando |
|---|---|---|
| revisor do cliente | os comentários que ele mesmo escreveu | enquanto a janela estiver aberta |
| pessoa do estúdio | as tarefas internas que ela mesma criou | na fase de execução |

**O estúdio não edita comentário do cliente. Nunca.** Registro que a outra parte pode
reescrever não serve de prova numa discussão de escopo — e essa prova é metade do valor do
produto. Se o pedido está confuso, o caminho é responder perguntando, não corrigir a boca do
outro.

Texto alterado ganha a marca **editado**. Quem apagar, apaga de vez: apagar comentário sem
resposta é diferente de apagar um que a equipe já respondeu, e o segundo caso pede confirmação.

A permissão é conferida **na ação**, não escondida na interface. É a mesma exigência que
`docs/05-telas.md` faz do servidor, e o protótipo segue a regra para não ensinar o contrário
a quem for implementar.

Colunas novas em `comentarios`: `editado_em`. A cadeia de quem editou o quê fica em `eventos`.

## M17 — Cronograma por etapas, compartilhado com o cliente · MUDA O BANCO

> Primeira tentativa descartada. Ela tinha uma linha por **lote de entrega** — "fachadas na
> quinta, áreas comuns na semana que vem". Funcionava, mas o eixo estava errado: quem coordena
> pensa em etapa do pipeline, não em pacote de arquivos, e o lote acabava sendo um segundo
> lugar para guardar data. As tabelas `entregas` e `entrega_itens` saíram.

**Uma faixa por etapa do pipeline**, com início e fim planejados.

Isso é plano de coordenação, não estimativa por tarefa — a distinção importa e é o que separa
um cronograma que se mantém de um que ninguém atualiza. "Iluminação de 18 a 20 de agosto" vale
para a rodada inteira; ninguém desenha uma barra por imagem. Barra por tarefa vira promessa,
promessa vira cobrança, e em duas semanas o cronograma só serve para provar atraso.

**Entrega não é linha própria: é o fim da última etapa.** Ter as duas coisas era ter a mesma
data em dois lugares para divergirem na terceira semana.

### Editável de dois jeitos

Arrastar a barra move a etapa inteira; puxar a borda estica de um lado só; e há dois campos de
data para quando a precisão importa mais que o gesto. Tudo encaixa no dia — meia-data não
existe num cronograma de produção.

**Reencadear** recoloca todas as etapas em sequência a partir do fim da janela. Preferido a
empurrar as seguintes automaticamente a cada arraste: automático parece mágica, quebra a
intenção de quem queria sobrepor duas etapas de propósito, e não dá para desfazer com clareza.

O percentual dentro da barra vem das etapas de M13 — o cronograma anda sozinho conforme a
equipe marca no quadro.

### O cliente vê o mesmo cronograma

É a parte que muda a relação. Ele abre o link e enxerga onde a produção está e, principalmente,
**quando será chamado de novo**:

- **Sua janela de aprovação** — a atual, com quantos dias faltam
- as etapas **públicas**, com o nome público de cada uma; etapa marcada como interna some da
  visão dele mas continua contando no percentual
- **Entrega da versão seguinte**
- **Sua próxima janela de aprovação** — projetada logo após a entrega, hachurada por ser
  previsão

Esse último item é o que ninguém dá ao cliente: a data em que ele vai precisar parar para
olhar de novo. É agenda dele, não do estúdio, e é o que faz a rodada seguinte não atrasar
por indisponibilidade.

**O cronograma aparece para ele em todas as fases**, não só durante a execução. Foi um erro
da primeira versão: era justamente com a janela aberta — quando ele está com a plataforma na
mão — que ele mais quer saber quando vai ser chamado de novo. Um atalho no topo leva até lá,
porque a página do cliente é longa e a informação estava no fim.

Tudo isso obedece ao interruptor de M14. Desligado, ele vê só a data de entrega.

### Detalhes de interação que custaram bug

**A alça de arraste sai da posição do clique, não de elementos fixos.** A primeira versão tinha
uma alça de 9 px em cada ponta da barra; numa etapa de um dia a barra inteira tem 11 px, então
as duas alças cobriam tudo e não havia como mover — só redimensionar. Agora a barra decide o
modo pela distância até a borda, e barra estreita é sempre "mover".

**O ícone da ferramenta de mover virou uma cruz.** Era uma mão desenhada num traço único cheio
de arcos, e a 16 px isso não lê como mão — lê como rabisco. Cruz de quatro setas é
geometricamente simples e não tem como sair errada.

**Duas checagens que uma agenda não faz:**

- etapa que **começa antes de a janela do cliente fechar** levanta aviso — é a regra 1 do
  produto desenhada na linha do tempo
- etapa vencida com item em aberto fica vermelha

**Descartado:** calcular as datas a partir do progresso. Estimativa automática erra, e errar
uma data que a ferramenta prometeu ao cliente é pior do que não prometer nada.

**Descartado:** caminho crítico e dependência entre etapas. É a segunda coisa que transforma
cronograma em ferramenta que ninguém mantém.

## M18 — Contas, convites e e-mails · MUDA O BANCO

Faltava a porta de entrada inteira: não havia cadastro, login, convite de equipe nem
redefinição de senha, e os e-mails eram uma lista de quatro nomes em `03-arquitetura.md`.

Telas e os oito modelos de e-mail estão no protótipo, no menu do avatar. As regras de servidor
— token, hash, expiração, limite de tentativa, SPF/DKIM/DMARC — estão em
`docs/11-contas-e-emails.md`, que é o documento a seguir na implementação.

**Um erro do schema v1 apareceu ao escrever isso:** `usuarios` tinha `UNIQUE (email)` global.
Contradiz D2 — a mesma pessoa pode ser terceirizada de dois estúdios, e o primeiro a cadastrar
trancaria o endereço para o outro. Virou `UNIQUE (estudio_id, email)`.

## M19 — Dois papéis do lado do cliente · MUDA O BANCO · **REVISA D8**

O modelo tratava todo mundo do lado do cliente como a mesma pessoa: um link por rodada, e a
página perguntava *"quem é você?"*. Duas coisas erradas nisso.

**A pergunta não se verifica.** Qualquer um com o link escolhia ser qualquer um e assinava
comentário no nome dele. Autoria que a própria pessoa declara não é autoria.

**E as pessoas não são iguais.** Quem coordena a revisão volta toda semana; quem revisa aparece
uma vez por rodada. A régua certa é a **frequência de uso**, não a hierarquia:

| papel | senha | como entra |
|---|---|---|
| **Gerente do cliente** | sim | e-mail e senha |
| **Revisor** | não | link pessoal por e-mail |

D8 dizia "se precisar criar conta, o estúdio não usa". Isso vale para o revisor — que não tem
nada em jogo e abandona no primeiro cadastro. Não vale para quem coordena: essa pessoa quer
voltar, quer 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, recebe um link de uso único de 30 minutos, entra, e
o aparelho fica reconhecido por 30 dias. A caixa de e-mail vira o fator, no mesmo nível do
"esqueci a senha" — que é por onde qualquer conta do mundo cai de qualquer jeito.

### O que muda além de ter conta

**Link por pessoa, não por rodada.** O comentário sai assinado sem perguntar nada, e tirar o
acesso de uma pessoa não derruba o das outras. A tela "quem é você?" foi removida.

**O gerente monta a própria lista.** Antes o estúdio perguntava por e-mail quem ia revisar,
digitava tudo, e refazia a cada troca de gente no escritório do cliente. Quem sabe quem revisa
é o cliente. O estúdio continua podendo incluir, para não travar a primeira rodada.

**O cliente virou entidade.** Era `projetos.cliente_nome`, um texto — não havia onde pendurar
as pessoas nem o histórico entre projetos, que é justamente o que dá ao gerente uma casa para
voltar.

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

**Descartado:** senha para o revisor. Seria coerente e mataria a adoção.

**Descartado:** deixar o gerente encerrar a janela sozinho. É P3 e continua em aberto — ele
pode declarar que terminou, mas quem fecha a rodada é o estúdio, que é quem responde pelo prazo.

---

## O que continua em aberto

`docs/07-pendencias.md` segue valendo. Duas atualizações:

**P1 — cobrança.** A recomendação de lá (por pessoa, com cota) continua certa, e M2 dá um
argumento a mais: vídeo consome disco e banda numa ordem de grandeza diferente de imagem, o
que reforça a cota de armazenamento como trava do plano em vez de eixo de preço. Uma escada
possível, a confirmar com clientes reais e não com planilha:

| plano | pessoas do estúdio | projetos ativos | armazenamento |
|---|---|---|---|
| Estúdio | 3 | 5 | 50 GB |
| Time | 10 | 20 | 250 GB |
| Sob medida | — | — | negociado |

Convidado do lado do cliente nunca conta como assento. É o que torna o produto vendável, e é
o que ReviewStudio já faz.

**P4 — prazo automático.** A recomendação de avisar em D-1, fechar no vencimento e permitir
reabrir com um clique está implementada no protótipo v2 como comportamento assumido.
Falta decidir de verdade.

**Novo — P7: retenção de vídeo.** O original de vídeo é ordens de grandeza maior que o de
imagem. Provavelmente não deve ficar no servidor: o estúdio sobe a cópia de revisão e guarda
o master. Falta decidir se a plataforma aceita o master e o que promete sobre ele.