internal/usage/storage.go: ReportStorageWrite/ReportStorageDelete sind
duenne Spezialisierungen von LIC-03s bereits atomarem Store.Increment auf
die feste Metrik "storage_bytes" — Loeschung nutzt einfach ein negatives
Delta desselben UPSERT-Mechanismus, kein zweiter Zaehl-Codepfad. Damit
uebernehmen Akzeptanzkriterium 2 (atomar, race-frei) und die zugehoerigen
LIC-03-Garantien direkt, ohne Duplikat.
CurrentStorageUsage ist ein einfaches Store.Get auf dieselbe Metrik —
LIC-03 kann denselben Wert ueber Store.Get(tenant, StorageBytesMetric)
abfragen (Akzeptanzkriterium 3, per Test TestCurrentStorageUsage_MatchesGenericStoreGet
belegt: kein zweiter, abweichender Zaehlmechanismus).
Die Objekt-Storage-Treiber der Module (DMS FDN-03, Mail ARC-01), die diese
Funktionen bei jedem Schreib-/Loeschvorgang aufrufen wuerden, existieren als
Code noch nicht (nur geplant in dms-kanban/mail-kanban) — diese Kachel
implementiert nur die Core-seitige Zaehl-Schnittstelle, analog zum
AUD-05/RetentionRegistrar-Muster.
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Paralleler Schreib-Test (viele gleichzeitige Uploads) ergibt korrekten
Endstand ohne verlorene Updates —
TestReportStorageWrite_ConcurrentUploadsSumCorrectly: 10 parallele
Schreibvorgaenge unterschiedlicher Groesse, Endstand exakt gleich der in
Go unabhaengig berechneten Summe. PASS.
2. Loeschvorgang dekrementiert korrekt — TestReportStorageDelete_Decrements. PASS.
3. Abfrage liefert konsistenten Wert mit unabhaengiger Kontrollzaehlung —
TestCurrentStorageUsage_MatchesIndependentTally (gemischte Schreib-/
Loeschfolge, in Go parallel mitgezaehlt) und
TestCurrentStorageUsage_MatchesGenericStoreGet. PASS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
internal/usage: Store.Increment aktualisiert Zaehlerstaende ueber ein
einziges atomares SQL-UPSERT (value = value + delta) statt Read-Modify-Write
in Go — haelt Zaehlerstaende bei parallelen Schreibzugriffen konsistent
(Akzeptanzkriterium 1), ganz ohne Anwendungs-Lock. Quotas sind Konfiguration
(usage_quotas-Tabelle je Tenant+Metrik), kein Hardcode.
Check/Enforce leiten aus Zaehlerstand + Quota eine definierte Reaktion ab
(StatusOK/Warning bei 80%/Exceeded, Akzeptanzkriterium 2) — Enforce ruft eine
uebergebene Reaction-Funktion auf, wenn der Status nicht OK ist; die
konkrete Sperr-/Benachrichtigungslogik bleibt beim Aufrufer (z.B. TEN-02 vor
Benutzeranlage), Enforce garantiert nur zuverlaessiges Ausloesen. Fehlende
Quota-Konfiguration bedeutet unbegrenzt (StatusOK), kein Fehler.
RunPeriodicAggregation ist das Aggregations-Grundgerüst (Akzeptanzkriterium 1:
"periodisch aggregiert") — dieselbe In-Prozess-Worker-Goroutine-Konvention
wie internal/tenant.Lifecycle.RunSweeper. Die konkrete Aggregationsquelle
(Zeilen zaehlen in Modul-Tabellen) haengt vom jeweiligen Modul ab und ist
nicht Teil dieser Kachel.
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Quota-Ueberschreitung automatisiert erkannt, definierte Reaktion
ausgeloest — TestEnforce_TriggersReactionOnExceeded: Reaction-Callback
wird mit StatusExceeded aufgerufen. PASS.
2. Aggregationsjob liefert bei parallelen Schreibzugriffen konsistente
Zaehlerstaende — TestIncrement_ConsistentUnderConcurrentWrites: 50
nebenlaeufige Increments, Endstand exakt 50 (kein Lost Update). PASS.
3. Zaehlerstand eines Tenants beeinflusst nicht den eines anderen —
TestIncrement_IsolatedBetweenTenants. PASS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
internal/license: Ed25519-signierte Lizenzschluessel (stdlib crypto/ed25519,
keine neue Abhaengigkeit). Issuer haelt den privaten Schluessel (lebt beim
Lizenzgeber), Validator nur den oeffentlichen (lebt im Core-Prozess) — klare
Trennung Ausstellung/Pruefung nach Unleash-Vorbild (Flag-Verwaltung vs.
Flag-Auswertung).
Store.Install prueft NUR die Signatur und persistiert den Lizenzumfang
(Plan, Modul-Liste, Laufzeit) in tenant_licenses (Registry-DB, 1:1 zu
tenants). Eine bereits abgelaufene, aber korrekt signierte Lizenz laesst
sich trotzdem einspielen — der Ablauf wird erst bei Store.RequireActive
bewertet (liefert ErrLicenseExpired statt Panic/Absturz), waehrend
Store.Status den Umfang unabhaengig vom Ablauf weiterhin liefert.
Neu: scripts/run-checks.sh buendelt reset-test-env.sh + go build/vet/test
(-p 1) zu einem Ein-Kommando-Check fuer den Testhost.
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Manipulierter Lizenzschluessel zuverlaessig erkannt —
TestParse_RejectsTamperedKey, TestParse_RejectsWrongKeyPair,
TestStore_InstallRejectsInvalidSignature. PASS.
2. Ablauf loest definierten eingeschraenkten Zustand aus, kein harter
Systemausfall — TestStore_RequireActive_DetectsExpiry (inkl. recover()-
Absicherung im Test, dass kein Panic auftritt), ErrLicenseExpired statt
Absturz; Status bleibt trotzdem abfragbar. PASS.
3. Signaturpruefung von zweiter Person gegen Dokumentation nachvollzogen —
NICHT durchgefuehrt (keine zweite Person in dieser Session verfuegbar).
Offen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Registry-DB (nur Tenant-Metadaten), Provisioning-Routine legt pro Mandant
eine physisch isolierte Postgres-DB an und registriert sie transaktional
(Rollback der DB bei fehlgeschlagener Registrierung). Schlanker HTTP-Handler
als Schnittstellen-Vorbereitung fuer API-01/TEN-02, kein eigenes REST-Grundgerüst.
Pruefungen:
1. Migration up/down geschrieben (0001_tenant_registry.{up,down}.sql) — nicht
gegen echte DB ausgefuehrt, da auf dieser Maschine kein Go/Postgres-Test-
Setup verfuegbar ist. Offen zur Ausfuehrung.
2. Integrationstest TestProvision_CreatesIsolatedDatabases geschrieben (zwei
Mandanten, prueft unterschiedliche db_name und current_database()) —
ebenfalls nicht ausgefuehrt, guarded per TEST_ADMIN_DSN env var. Offen.
3. Slug-Validierung (unit test TestValidateSlug) deckt SQL-Injection-Versuch
im Datenbanknamen ab — ebenfalls nicht lokal ausgefuehrt, da kein Go
Compiler auf dieser Maschine vorhanden ist. Offen.
Alle drei Pruefungen sind vorbereitet, aber NICHT durchgefuehrt worden —
zaehlen laut Vorgabe als offen bis auf einer Maschine mit Go+Postgres verifiziert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
