diff --git a/code/engine/skills/boas-praticas-oo.md b/.agents/skills/boas-praticas-oo/SKILL.md similarity index 100% rename from code/engine/skills/boas-praticas-oo.md rename to .agents/skills/boas-praticas-oo/SKILL.md diff --git a/.jhonny/analises.db b/.jhonny/analises.db new file mode 100644 index 0000000..6ffc55b Binary files /dev/null and b/.jhonny/analises.db differ diff --git a/.jhonny/analises.db-shm b/.jhonny/analises.db-shm new file mode 100644 index 0000000..fe9ac28 Binary files /dev/null and b/.jhonny/analises.db-shm differ diff --git a/.jhonny/analises.db-wal b/.jhonny/analises.db-wal new file mode 100644 index 0000000..e69de29 diff --git a/.retakes/retakes-12.json b/.retakes/retakes-12.json new file mode 100644 index 0000000..a6d6f1f --- /dev/null +++ b/.retakes/retakes-12.json @@ -0,0 +1,71 @@ +{ + "video_id": "12", + "versao_transcricao": "1", + "versao_regras": "regras:1.1", + "versao_modelo": "lexico", + "_hash": "ad361d6e7dc4", + "grupos_de_retakes": [ + { + "id": "retake_421fa7", + "video_id": "12", + "faixa_id": "1", + "tipo": "retake_confirmado", + "confianca": 0.95, + "tomadas": [ + { + "ordem": 0, + "fala_id": "101", + "segmento_id": "c1", + "inicio": 0.0, + "fim": 6.0, + "texto": "Hoje nós vamos mostrar como funciona o sistema.", + "similaridade_com_anterior": 0.0, + "confianca": 0.95 + }, + { + "ordem": 1, + "fala_id": "102", + "segmento_id": "c1", + "inicio": 9.0, + "fim": 15.0, + "texto": "Hoje nós vamos mostrar como funciona o sistema.", + "similaridade_com_anterior": 1.0, + "confianca": 0.95 + } + ], + "evidencias": [ + { + "tipo": "similaridade_textual", + "descricao": "As duas falas possuem 100% de palavras em comum e 100% de similaridade textual geral.", + "valor": 1.0 + }, + { + "tipo": "repeticao_do_inicio", + "descricao": "As duas falas começam com as mesmas palavras.", + "valor": 1.0 + }, + { + "tipo": "proximidade_temporal", + "descricao": "A segunda tentativa começa 3.0 segundos após a primeira.", + "valor": 0.75 + }, + { + "tipo": "reinicio", + "descricao": "pausa de 3.0 segundos", + "valor": 1.0 + }, + { + "tipo": "reinicio", + "descricao": "repetição das primeiras 8 palavras", + "valor": 1.0 + }, + { + "tipo": "classificacao", + "descricao": "É um retake provável. Confiança de 95%.", + "valor": 0.95 + } + ], + "criado_em": "2026-09-08T20:37:58.545824+00:00" + } + ] +} \ No newline at end of file diff --git a/AGENTS.md b/AGENTS.md index 435323b..abd3859 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -2,6 +2,21 @@ ## Project Skills +## Convenções obrigatórias de Python / OO + +Todo código Python em `code/engine/` deve seguir a skill **`code/engine/skills/boas-praticas-oo.md`** (boas práticas de programação orientada a objetos). Leia-a antes de criar, modificar, corrigir, revisar, refatorar ou ampliar qualquer sistema Python. + +Resumo das regras vinculantes: + +- **PT-BR obrigatório** em todos os identificadores internos (classes, métodos, variáveis, atributos, parâmetros, constantes, arquivos, pastas, módulos), docstrings, comentários, logs, mensagens de erro e documentação. Identificadores externos (bibliotecas, APIs, contratos) são preservados e isolados em adaptadores/integrações. +- **Nomenclatura**: classes `PascalCase`; métodos, funções, variáveis e arquivos `snake_case`; constantes `MAIÚSCULAS_COM_SUBLINHADO`. Evitar nomes genéricos (`Util`, `Helper`, `Manager`, `Data`). +- **Documentação obrigatória**: docstring no topo de todo módulo, classe e método público, mantida coerente com o comportamento real (documentação viva). +- **Arquitetura**: responsabilidade única, alta coesão, baixo acoplamento, composição antes de herança, herança só com especialização real, encapsulamento, interfaces pequenas, injeção de dependências, métodos pequenos e objetivos. +- **Domínio**: regras de negócio ficam no domínio/aplicação, nunca misturadas com interface, SQL, HTTP ou apresentação. Integrações externas isoladas em módulos próprios. +- **Erros e segurança**: tratar erros com exceções específicas (nunca `except Exception: pass`), validar toda entrada externa, não registrar credenciais, não duplicar regras, retornos previsíveis. +- **Testes**: toda funcionalidade relevante deve ter testes (unitário, integração, regressão); criar/atualizar teste ao corrigir bug. +- Seguir o **checklist obrigatório** (seção 41 da skill) antes de finalizar qualquer implementação. + ## Interface do painel Quando o usuário pedir uma implementação “na tela”, “no painel” ou “na interface do MCP”, use o painel CEP em `code/cep-plugin/`, identificado por **MCP for Adobe Premiere Pro** e pelas abas **Editar vídeo**, **Scanner**, **Conexão**, **Modelos** e **Ajustes**. Essa é a interface de produto; não criar fluxos de interface alternativos em `code/uxp-plugin/`. diff --git a/CODING_STANDARDS.md b/CODING_STANDARDS.md new file mode 100644 index 0000000..a3e9a82 --- /dev/null +++ b/CODING_STANDARDS.md @@ -0,0 +1,68 @@ +# Padrões de código + +Este documento consolida as convenções obrigatórias de código do projeto. Serve de fonte de verdade para revisões automáticas (eixo *Standards* do `/code-review`) e vale para qualquer agente que escreva ou altere código. + +A fonte completa das regras de orientação a objeto é a skill **`code/engine/skills/boas-praticas-oo.md`**. O que está abaixo é o resumo normativo; em caso de dúvida, leia a skill por inteiro. + +## Escopo + +As regras de PT-BR e OO aplicam-se a todo **Python em `code/engine/`**. Outras linguagens seguem as convenções existentes no repositório, mas os princípios de design (responsabilidade única, baixo acoplamento, injeção de dependência, módulos profundos) são universais. + +## Idioma — PT-BR obrigatório + +Todos os identificadores internos usam português brasileiro: + +- Classes, métodos, funções, variáveis, atributos, parâmetros, constantes, arquivos, pastas e módulos. +- Docstrings, comentários, logs, mensagens de erro e documentação. +- Nomes de testes, fixtures e exemplos. + +Identificadores **externos** (bibliotecas, APIs, endpoints, campos de contrato, variáveis de ambiente de terceiros, protocolos) são preservados no idioma oficial **somente quando exigidos**, e isolados em adaptadores/conversores/clientes/repositórios. Não espalhar nomes externos pelo sistema; converter na fronteira para o modelo interno em PT-BR e documentar a exceção. + +## Nomenclatura + +- Classes: `PascalCase` — ex. `GerenciadorDeArquivos`. +- Métodos, funções, variáveis, atributos, arquivos e pastas: `snake_case` — ex. `carregar_arquivo`, `nome_do_usuario`. +- Constantes: `MAIÚSCULAS_COM_SUBLINHADO` — ex. `TEMPO_LIMITE_DA_OPERACAO`. +- Evitar nomes genéricos: `Util`, `Helper`, `Manager`, `Processor`, `Data`, `Object`, `Thing`, `Temp`. + +## Documentação + +- Todo **módulo** tem docstring no topo: finalidade, problema que resolve, responsabilidade, o que não faz, componentes e dependências principais. +- Toda **classe** tem docstring: o que representa, responsabilidade, dependências, o que não deve fazer, efeitos colaterais quando aplicável. +- Todo **método/função público** tem docstring: o que faz, dados que recebe, retorno, erros possíveis, se altera estado, se realiza operações externas. +- **Documentação viva**: docstring/comentário deve descrever o comportamento atual. Proibido manter documentação de comportamento que não existe mais. + +## Design / orientação a objeto + +- **Responsabilidade única**: cada classe/função/módulo tem uma responsabilidade principal. +- **Alta coesão**: métodos da classe relacionam-se à sua responsabilidade. +- **Baixo acoplamento**: depender do mínimo; receber dependências, não criá-las internamente. +- **Composição antes de herança**; herança apenas com relação real de "é um". +- **Encapsulamento**: dados e regras protegidos, alterados por operações apropriadas. +- **Interfaces pequenas** e **injeção de dependências** explícita. +- **Métodos pequenos e objetivos**; retornos previsíveis e consistentes. +- **Módulos profundos**: muita funcionalidade atrás de interface pequena (ver skill `codebase-design`). + +## Domínio e integrações + +- Regras de negócio ficam no **domínio/aplicação**, nunca na interface, em controladores gigantes, scripts, SQL, HTTP ou camada de apresentação. +- Integrações externas (APIs, banco, arquivos, serviços) isoladas em módulos próprios; o resto do sistema usa contratos/classes internas. +- Não duplicar regras: centralizar em classe, função, validador, objeto de valor ou constante. +- Evitar dependências circulares; resolver com contratos, módulo comum, inversão ou injeção de dependência. + +## Erros e segurança + +- Tratar erros com **exceções específicas**; nunca `except Exception: pass`. +- Validar toda entrada externa (tipo, formato, limites, nulos, estrutura) antes de usar. +- Não registrar senhas, tokens, chaves ou dados sensíveis em logs. +- Configurações em componentes próprios, não espalhadas no código. + +## Testes + +- Toda funcionalidade relevante tem testes (unitário, integração, regressão). +- Cobrir: entradas válidas/inválidas, casos vazios/extremos, erros, retornos, efeitos colaterais, regras de negócio. +- Ao corrigir bug, criar/atualizar teste que impeça regressão. + +## Checklist antes de finalizar + +Antes de dar como concluída qualquer implementação Python em `code/engine/`, percorrer a seção 41 da skill `boas-praticas-oo.md`: requisitos, arquitetura, código, documentação e testes. \ No newline at end of file diff --git a/code/cep-plugin/index.html b/code/cep-plugin/index.html index 78a5b9b..7eefdc1 100755 --- a/code/cep-plugin/index.html +++ b/code/cep-plugin/index.html @@ -28,6 +28,9 @@ + @@ -226,9 +229,19 @@

Escolha o que será lido no arquivo original. O Scanner usa os tempos da timeline, mas não exporta frames pelo Premiere.

Amostragem e faixas

- - -

Use a amostragem precisa somente no trecho que será reenquadrado.

+ +
+ + 1 s/quadro +
+

Quanto menor, mais frames e mais detalhado (e mais lento). Valores maiores aceleram a análise, principalmente em clipes curtos.

+ + +

Reduzir a resolução acelera a extração e a leitura Vision sem perder precisão no rosto, pose ou objetos.

Abra a sequência desejada e detecte as faixas para selecioná-las.

Faixas de vídeo
Faixas de áudio
@@ -258,6 +271,68 @@
+ + + +