Ressources

Ressources de travail

Cette page garde les documents bruts à portée de main tout en indiquant clairement à quoi ils servent. Le but est qu’une équipe ne perde pas de temps à deviner quel document fait autorité, lequel sert à l’architecture, et lequel doit surtout aider aux tests ou à la pédagogie.

LICENSE.md

Licence de la spécification pour la documentation publique EEV et le contrat canonique. Elle précise aussi que EEVC reste un canal certifié et que la vérification certifiée relève de eevc.link.

eev-format.md

Spécification centrale du contrat public pour EEV : philosophie du format, variantes `.eev / .eevz`, structures `ENTRY` et `LIB`, règles canoniques, avec notes de compatibilité en lecture pour des fichiers `.eevc` déjà émis.

eev-implementation.md

Note d’architecture : lecture, écriture, intégrité, séparation des couches, matching et comportement réel du runtime.

eev-recording-guide.md

Guide de capture : comment produire une empreinte utile, complète, annotée proprement et cohérente avec le niveau de qualité visé.

eev-v1-peak-tracks-roadmap.md

Feuille de route produit sur la montée en richesse des `peak_tracks`, la logique `eco -> standard -> high -> ultra` et les arbitrages de stabilisation.

fallback-matrix.md

Matrice de dégradation maîtrisée selon navigateur, mobile et Android WebView. Très utile pour tout produit qui vise des environnements d’exécution réels.

qa-regression-checklist.md

Checklist de validation avant diffusion, changement d’algorithme ou publication de build. Sert à éviter les régressions silencieuses.

Ordre de lecture conseillé pour une équipe

R&D / architecture : commencer par Format puis Implémentation
ingénierie produit : enchaîner avec Capture puis la matrice de fallback
QA : relire QA checklist + fallback matrix
documentation / adoption : utiliser ensuite Glossaire + Pour débutants

Triptyque le plus important

Pour coder, le triptyque central est simple : Format pour le contrat canonique, Implémentation pour la stratégie logicielle, Guide de capture pour la qualité de la matière première. Les autres documents servent à cadrer, tester, enrichir ou expliquer.

Checklist avant de lancer le développement

décider si vous avez besoin seulement de `ENTRY` ou aussi de `LIB`
séparer les règles du writer canonique de celles de la lecture tolérante
choisir comment vous validez l’intégrité et les hashes optionnels
préparer un jeu de tests capturé dans des conditions réalistes