docs(skill): alinhar editar-por-voz com a revisão humana da etapa 5

A skill decidia a edição sem saber que o JSON dela agora passa por uma tela
de revisão antes de virar FCPXML. Isso não é detalhe de fluxo: a etapa 5
traduz cada ação para o vocabulário dela, e sem conhecer essa tradução a
intenção da IA se perde no caminho — que é exatamente como uma decisão vira
"arbitrária" aos olhos de quem revisa.

Novo criterios/10-revisao-humana.md, com o que o app faz com cada ação:

- cut cobrindo >=60% da frase remove a linha; tocando só uma borda vira trim
  encaixado na fronteira de palavra. Corte de meia frase é ambíguo — passa
  do limiar e apaga a linha toda quando a intenção era aparar a hesitação.
- zoom ou text sobre uma frase marca ênfase, e ênfase significa DUAS coisas:
  zoom mais legenda dinâmica; as demais frases ficam com legenda comum. A
  escala vira o nível (1.15→leve, 1.3→média, 1.5→forte).
- sem ação, o nível é derivado do peak_emphasis; a decisão da IA sempre ganha.
- reason é exibido ao lado da frase na tela — é o que o editor lê antes de
  manter ou desfazer. Deixou de ser campo de log.

Consequência prática que faltava em 05-zoom.md: não espalhar zoom "por
segurança", porque cada um promove a frase em duas dimensões ao mesmo tempo.
Na dúvida, deixar sem — promover custa uma tecla, despromover custa mais.

Cada arquivo de critério ganhou cabeçalho de escopo (o que cobre, em que
fase), no mesmo padrão dos docs do Engine, para ler só o necessário.

Todas as afirmações numéricas do novo critério foram verificadas contra
fcpxml/phrase_review.py rodando, não assumidas.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.claude/skills/editar-por-voz/SKILL.md

@@ -28,6 +28,12 @@ minutos.
 `apply_voice_actions` aplica direto, mas é para **teste**. O produto do seu
 trabalho é a lista de decisões.
 
+**Para onde ela vai:** o usuário cola o seu JSON no app, e ele abre na etapa 5
+do Assistente — uma tela onde cada frase do roteiro aparece com a sua decisão
+já marcada, para ser revisada antes de gerar. Você é o **ponto de partida** da
+edição, não a palavra final; escreva decisões defensáveis e motivos legíveis.
+Como o app traduz cada ação sua: `criterios/10-revisao-humana.md`.
+
 ## Ordem de trabalho
 
 Siga nesta ordem. Pular a Fase 2 ou a 3 leva a decisões erradas.
@@ -44,6 +50,9 @@ Siga nesta ordem. Pular a Fase 2 ou a 3 leva a decisões erradas.
 | **7** | Cortar a lista pelo ritmo | `criterios/07-ritmo.md` |
 | **8** | Montar o JSON de saída | `criterios/08-formato-de-saida.md` |
 
+**Antes da Fase 5, leia `criterios/10-revisao-humana.md`.** Ele descreve o que
+o app faz com o seu JSON — e muda *como* escrever cortes e zooms, não só quais.
+
 ## As três armadilhas
 
 Cada uma já causou erro silencioso em material real:
@@ -69,10 +78,14 @@ disso e o efeito cai no frame errado — sem erro visível.
 
 ```
 build_voice_timeline → [você decide] → refine_voice_timeline → [você corta
-pelo ritmo] → apply_voice_actions → remove_media_silence →
-generate_dynamic_subtitles
+pelo ritmo] → [revisão humana na etapa 5 do app] → apply_voice_actions →
+remove_media_silence → generate_dynamic_subtitles
 ```
 
+A revisão humana entra entre a sua decisão e a aplicação. É por isso que o
+`reason` importa tanto: ele é lido ali, na hora de decidir se a sua escolha
+fica.
+
 Vícios de linguagem e lacunas longas entram na **sua** lista, num ripple só
 (`06-texto-corte-marcador.md`). Silêncio fino e legendas vêm depois.