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>
52 lines
1.7 KiB
Markdown
52 lines
1.7 KiB
Markdown
# 09 — Quando a análise veio incompleta
|
|
|
|
> **Escopo:** O que fazer quando uma camada da análise não rodou.
|
|
> **Quando:** Fase 0 — ver a ordem de trabalho em `../SKILL.md`.
|
|
|
|
O bloco `layers` no topo do JSON diz **o que de fato rodou**. Leia antes de
|
|
qualquer outra coisa.
|
|
|
|
```json
|
|
"layers": {"transcript": true, "acoustics": false, "speakers": false}
|
|
```
|
|
|
|
## Por que esse bloco existe
|
|
|
|
Fala monótona e acústica que não carregou deixam **os mesmos zeros** nos
|
|
dados. Sem o `layers`, é impossível distinguir "esta pessoa fala de forma
|
|
uniforme" de "a análise acústica falhou".
|
|
|
|
## Os casos
|
|
|
|
### `acoustics: false`
|
|
Todos os valores acústicos são 0. **Você não tem ênfase real.**
|
|
|
|
- Decida só pelo texto.
|
|
- **Avise o usuário** explicitamente.
|
|
- Prefira `marker` a `zoom` — sinalize em vez de decidir.
|
|
|
|
Causa comum: o componente librosa não está instalado, ou o ffmpeg não
|
|
conseguiu extrair o áudio do container.
|
|
|
|
### `speakers: false` num vídeo com várias pessoas
|
|
A diarização não rodou — falta o token do HuggingFace (aba Modelos do app).
|
|
|
|
- Avise antes de tratar tudo como uma voz só.
|
|
- Lembre que isso **não impede** a triagem roteiro/conversa, que é feita
|
|
pelo texto (ver `02-triagem-roteiro-vs-conversa.md`).
|
|
|
|
### `peak_count: 0`
|
|
Nada cruzou o piso de ênfase. Duas causas possíveis:
|
|
|
|
1. A fala é uniforme mesmo — material sem picos.
|
|
2. O limiar está alto para esse material.
|
|
|
|
Sugira ajustar em **Análise de Voz** no app. **Não force destaques
|
|
inexistentes** só para entregar alguma coisa.
|
|
|
|
## Regra geral
|
|
|
|
Não finja precisão que você não tem. Uma edição entregue com a ressalva
|
|
certa é útil; uma entregue como se estivesse completa, quando metade dos
|
|
dados faltou, custa a confiança do usuário no sistema inteiro.
|