Risorse

Risorse di lavoro

Questa pagina tiene a portata di mano i documenti grezzi chiarendo a cosa servono. L’obiettivo è evitare che un team perda tempo a indovinare quale documento sia autorevole, quale guidi l’architettura e quale serva soprattutto a test o pedagogia.

LICENSE.md

Licenza della specifica per la documentazione pubblica EEV e il contratto canonico. Chiarisce anche che EEVC resta un canale certificato e che la verifica certificata appartiene a eevc.link.

eev-format.md

Specifica centrale del contratto pubblico: filosofia del formato, varianti `.eev / .eevz`, strutture `ENTRY` e `LIB`, regole canoniche.

eev-implementation.md

Nota di architettura: lettura, scrittura, integrità, separazione dei livelli, matching e comportamento reale a runtime.

eev-recording-guide.md

Guida di acquisizione: come produrre un’impronta utile, completa, annotata correttamente e coerente con il livello di qualità desiderato.

eev-v1-peak-tracks-roadmap.md

Roadmap di prodotto sull’arricchimento dei `peak_tracks`, sulla logica `eco -> standard -> high -> ultra` e sui compromessi di stabilizzazione.

fallback-matrix.md

Matrice di degradazione controllata per browser, mobile e Android WebView. Molto utile per ogni prodotto che debba funzionare in runtime reali.

qa-regression-checklist.md

Checklist di validazione prima del rilascio, di cambi algoritmici o della pubblicazione di una build. Aiuta a evitare regressioni silenziose.

Ordine consigliato per un team

R&D / architettura: iniziare da Formato e poi Implementazione
ingegneria di prodotto: proseguire con Acquisizione e poi fallback
QA: rivedere checklist QA + matrice fallback
documentazione / evangelizzazione: usare poi Glossario + Per iniziare

Triade più importante

Per implementare, la triade centrale è semplice: Formato per il contratto canonico, Implementazione per la strategia software e la Guida di acquisizione per la qualità della materia prima. Gli altri documenti servono a inquadrare, testare, arricchire o spiegare.

Checklist prima di avviare lo sviluppo

decidere se serve solo il supporto `ENTRY` o anche `LIB`
separare le regole del writer canonico da quelle della lettura tollerante
scegliere come validare l’integrità e gli hash opzionali
preparare materiale di test catturato in condizioni realistiche