05 — Für Entwickler
SDK-Integration in sechs Sprachen
Vier Zeilen im eigenen Paket, in sechs Sprachen mit byte-identischer Ausgabe. Die öffentliche Oberfläche ist absichtlich winzig: initialisieren, Events abgeben, fertig. Der gesamte Egress-Flow liegt in einem opt-in-Modul — wer nur puffern will, zieht ihn nicht mit herein.
Integration
Die API in sechs Sprachen
Die Aufrufe ändern sich mit der Sprache, das Ergebnis nicht. Genau das prüft die sprachübergreifende Conformance-Suite gegen gemeinsame Vektoren. Das Beispiel unten ist JavaScript; mit aktiviertem Skript schaltet die Leiste darüber auf die anderen fünf um.
// @prometheus/sdk — Node 20+ and browser/ESM
import { init } from "@prometheus/sdk";
const sdk = init({ projectId: "pkg:npm/left-pad" });
sdk.emit("install");
sdk.emit("session-start");
sdk.emit("runtime-tick"); // every 5 min
sdk.emit("feature-flag", { flag: "v2-api" });project_id benennt
das gemessene Projekt, nicht die SDK-Sprache — deshalb trägt jedes
Beispiel den PURL seines Ökosystems. Das strikte Regime kennt derzeit fünf:
npm, pypi, maven, cargo und
golang. NuGet ist noch nicht darunter, weshalb das
.NET-Beispiel ein Paket aus einem der fünf meldet — das SDK misst dann fremde
Ökosysteme, nicht sich selbst.
Gerechnet über den Conformance-Vektor
src/proto/conformance/positive/01-mode-a-runtime-band.json — eine
vollständige Submission mit submitter_id, aggregates
und attestation. Alle sechs SDKs erzeugen daraus dieselben Bytes
und denselben Hash; ohne diese Eigenschaft wäre keine Signatur
sprachübergreifend prüfbar.
Laufzeit-Budget
Das Laufzeit-Budget des SDK
Das SDK soll im fremden Prozess nicht auffallen. Telemetrie, die spürbar Ressourcen kostet, wird zu Recht ausgebaut. Deshalb ist das Budget ein Akzeptanzkriterium, kein Richtwert — es blockiert die Veröffentlichung.
pro Stunde Laufzeit · gemessen im K7-Profiler
RSS-Delta · gemessen im K7-Profiler
Protokoll
Die verwendeten Standards
Durchgehend erprobte Standards statt Eigenentwicklung: An Crypto und Identity wird nichts selbst gebaut. Jede Abweichung davon braucht eine dokumentierte Architektur-Entscheidung.
RFC 8785 — JCS
Kanonische JSON-Serialisierung. Ohne sie gäbe es keine sprachübergreifend reproduzierbaren Bytes und damit keine prüfbare Signatur.
ed25519 — RFC 8032
Signatur über die kanonischen Body-Bytes direkt, ohne Prehash. Der
submission_hash ist davon getrennt und dient der Idempotenz.
did:key
Die Identität des Melders ist ein selbstbeschreibender Schlüssel — keine Registrierung, keine zentrale Vergabestelle.
PURL — Package URL
Projekt-Identität immer als PURL, nie als freier Text. Damit ist
pkg:npm/foo eindeutig von pkg:pypi/foo getrennt.
Beitragen
Der Review-Prozess für Beiträge
Die Hürden sind bewusst hoch — bei einem Projekt, dessen Kernversprechen Anonymität ist, wäre alles andere fahrlässig.
Vier-Augen-Review über vier Dimensionen
Korrektheit, Sicherheit, Performance und Fehlerbehandlung werden getrennt geprüft. Eine Verletzung der harten Grundsätze ist ein Auto-FAIL.
K3 bei jedem Release
Der PII-Negativtest läuft bei jedem Release und jedem Sprint-Abschluss — auch dann, wenn die Änderung den PII-Pfad scheinbar nicht berührt.
Coverage-Schwellen pro Workspace
Mindestens 80 % auf neuem Code, dazu Lint, strikte Typprüfung und Property-basierte Tests.
Gleichlauf von Code und Konzept
Weicht ein Diff von einer Aussage in der Konzept-Dokumentation ab, wird die Dokumentation in derselben Änderung nachgezogen.