LICENSE.md
Lizenz der Spezifikation für die öffentliche EEV-Dokumentation und den kanonischen Vertrag. Sie präzisiert außerdem, dass EEVC ein zertifizierter Kanal bleibt und die zertifizierte Verifikation zu eevc.link gehört.
Arbeitsressourcen
Diese Seite hält die Rohdokumente griffbereit und macht ihren Zweck explizit. Ziel ist, dass ein Team keine Zeit damit verliert zu erraten, welches Dokument maßgeblich ist, welches die Architektur steuert und welches vor allem Tests oder Didaktik unterstützt.
eev-format.md
Zentrale Spezifikation des öffentlichen Vertrags: Formatphilosophie, Varianten `.eev / .eevz`, Strukturen `ENTRY` und `LIB`, kanonische Regeln.
eev-implementation.md
Architekturnotiz: Lesen, Schreiben, Integrität, Schichtentrennung, Matching und reales Laufzeitverhalten.
eev-recording-guide.md
Aufnahmeleitfaden: wie man eine nützliche, vollständige, sauber annotierte Signatur erzeugt, die mit dem angestrebten Qualitätsniveau übereinstimmt.
eev-v1-peak-tracks-roadmap.md
Produkt-Roadmap zur Anreicherung von `peak_tracks`, zur Logik `eco -> standard -> high -> ultra` und zu Stabilisierungsabwägungen.
fallback-matrix.md
Matrix für kontrollierte Degradation je nach Browser, Mobilgerät und Android WebView. Sehr nützlich für jedes Produkt, das auf realen Laufzeitumgebungen bestehen muss.
qa-regression-checklist.md
Validierungs-Checkliste vor Release, Algorithmusänderung oder Build-Veröffentlichung. Hilft, stille Regressionen zu vermeiden.
Empfohlene Reihenfolge für ein Team
- F&E / Architektur: mit Format beginnen, dann Implementierung
- Produktentwicklung: mit Aufnahme fortfahren, dann Fallback
- QA: QA-Checkliste + Fallback-Matrix prüfen
- Dokumentation / Vermittlung: danach Glossar + Für Einsteiger nutzen
Wichtigstes Triptychon
Für die Implementierung ist das zentrale Triptychon einfach: Format für den kanonischen Vertrag, Implementierung für die Softwarestrategie und der Aufnahmeleitfaden für die Qualität des Rohmaterials. Die anderen Dokumente rahmen, testen, vertiefen oder erklären.
Checkliste vor dem Start der Entwicklung
- entscheiden, ob nur `ENTRY` oder auch `LIB` unterstützt werden muss
- die Regeln des kanonischen Writers von denen der toleranten Lektüre trennen
- festlegen, wie Integrität und optionale Hashes validiert werden
- Testmaterial unter realistischen Bedingungen vorbereiten