Recursos

Recursos de trabalho

Esta página mantém os documentos brutos por perto e explicita a utilidade de cada um. O objetivo é que uma equipa não perca tempo a adivinhar qual documento é de referência, qual orienta a arquitetura e qual serve sobretudo para testes ou pedagogia.

LICENSE.md

Licença da especificação para a documentação pública do EEV e o contrato canónico. Esclarece também que o EEVC continua a ser um canal certificado e que a verificação certificada pertence a eevc.link.

eev-format.md

Especificação central do contrato público: filosofia do formato, variantes `.eev / .eevz`, estruturas `ENTRY` e `LIB`, regras canónicas.

eev-implementation.md

Nota de arquitetura: leitura, escrita, integridade, separação de camadas, matching e comportamento real em execução.

eev-recording-guide.md

Guia de captação: como produzir uma impressão útil, completa, bem anotada e coerente com o nível de qualidade pretendido.

eev-v1-peak-tracks-roadmap.md

Roadmap de produto sobre o enriquecimento de `peak_tracks`, a lógica `eco -> standard -> high -> ultra` e os compromissos de estabilização.

fallback-matrix.md

Matriz de degradação controlada por navegador, móvel e Android WebView. Muito útil para qualquer produto que tenha de funcionar em ambientes reais.

qa-regression-checklist.md

Checklist de validação antes de lançamento, mudança de algoritmo ou publicação de build. Ajuda a evitar regressões silenciosas.

Ordem sugerida para uma equipa

I&D / arquitetura: começar por Formato e depois Implementação
engenharia de produto: continuar com Captação e depois fallback
QA: rever checklist QA + matriz de fallback
documentação / evangelização: usar depois Glossário + Para iniciantes

Tríptico mais importante

Para implementar, o tríptico central é simples: Formato para o contrato canónico, Implementação para a estratégia de software e o Guia de captação para a qualidade da matéria-prima. Os outros documentos enquadram, testam, enriquecem ou explicam.

Checklist antes de iniciar o desenvolvimento

decidir se precisas apenas de suporte `ENTRY` ou também `LIB`
separar as regras do writer canónico das da leitura tolerante
escolher como validar a integridade e os hashes opcionais
preparar material de teste captado em condições realistas