Recursos

Recursos de trabajo

Esta página mantiene los documentos en bruto a mano dejando claro para qué sirven. El objetivo es que un equipo no pierda tiempo adivinando qué documento es de referencia, cuál guía la arquitectura y cuál sirve sobre todo para pruebas o pedagogía.

LICENSE.md

Licencia de la especificación para la documentación pública de EEV y el contrato canónico. También aclara que EEVC sigue siendo un canal certificado y que la verificación certificada corresponde a eevc.link.

eev-format.md

Especificación central del contrato público: filosofía del formato, variantes `.eev / .eevz`, estructuras `ENTRY` y `LIB`, reglas canónicas.

eev-implementation.md

Nota de arquitectura: lectura, escritura, integridad, separación de capas, matching y comportamiento real en ejecución.

eev-recording-guide.md

Guía de captura: cómo producir una huella útil, completa, bien anotada y coherente con el nivel de calidad buscado.

eev-v1-peak-tracks-roadmap.md

Hoja de ruta del producto sobre el enriquecimiento de `peak_tracks`, la lógica `eco -> standard -> high -> ultra` y los arbitrajes de estabilización.

fallback-matrix.md

Matriz de degradación controlada según navegador, móvil y Android WebView. Muy útil para cualquier producto que apunte a entornos de ejecución reales.

qa-regression-checklist.md

Checklist de validación antes de una difusión, un cambio de algoritmo o una publicación de build. Ayuda a evitar regresiones silenciosas.

Orden sugerido para un equipo

I+D / arquitectura: empezar por Formato y luego Implementación
ingeniería de producto: seguir con Captura y luego fallback
QA: revisar checklist QA + matriz de fallback
documentación / evangelización: usar después Glosario + Para principiantes

Tríptico más importante

Para implementar, el tríptico central es simple: Formato para el contrato canónico, Implementación para la estrategia de software y la Guía de captura para la calidad de la materia prima. Los demás documentos encuadran, prueban, enriquecen o explican.

Checklist antes de iniciar el desarrollo

decidir si solo necesitas soporte `ENTRY` o también `LIB`
separar las reglas del writer canónico de las de la lectura tolerante
elegir cómo validarás la integridad y los hashes opcionales
preparar material de prueba capturado en condiciones realistas