Der nächste Spec‑Abgleich. Und diesmal geht es um etwas, das man im Alltag oft erst dann vermisst, wenn es fehlt: Auditierbarkeit.

Ohne AuditWriter wüsste ich bei einer Datenänderung nur, dass etwas passiert ist — aber nicht durch wen. Und das ist der Unterschied zwischen „irgendwas hat jemand irgendwo geändert“ und „dieser Actor hat diese Änderung zu diesem Zeitpunkt vorgenommen“.

Natürlich muss ich mir das DSGVO‑Thema noch einmal genauer anschauen. Auch die Umsetzung. Aber insgesamt hat Codex das sauber aus der SPEC extrahiert — und ich beschwere mich nicht, das Codex mir einen geschrieben hat.

Ein kurzer Blick in die SPEC:

• DSGVO by design: Zweckbindung, Datenminimierung, Einwilligungen, Audit, Export, Löschung
• Observability: Health, strukturierte Logs, Audit Trails, Metriken
• KISS/YAGNI: Nur Employee, SkillGraph, Evidence, Consent, Audit

Und jetzt ist der Audit‑Teil davon tatsächlich implementiert.

Prompt 8 — Spec‑Abgleich (Audit‑Edition)

Der Spec‑Abgleich zu Prompt 7 war diesmal weniger „Fehler suchen“ und mehr „Audit‑Mechanik scharfstellen“. Und ja — es gab eine relevante Abweichung.

Was Codex gefunden und korrigiert hat

1. Skill‑Update nutzte die falsche ID

Abweichung: PATCH /api/v1/employees/{id}/skills/{skillId} behandelte {skillId} wie employee_skill.id. Das ist falsch — die Route sagt klar: Skill‑ID, nicht EmployeeSkill‑ID.

Fix: Neue Repository‑Methode: byEmployeeAndSkillId(EmployeeId, SkillId) Controller angepasst, Lookup korrigiert.

2. Audit‑Logging jetzt vollständig

Write‑Operationen werden jetzt korrekt auditiert:

• Employee create/update/delete
• Skill create/update
• Evidence create

Und zusätzlich im Audit‑Log‑Channel geschrieben. Damit ist der AuditWriter offiziell Teil der Anwendung — so wie die SPEC es verlangt.

3. RFC7807 sauber umgesetzt

Fehler kommen jetzt als:

• type
• title
• status
• detail
• errors (bei Validierung)

Ausgegeben als application/problem+json.

4. Validierung über Symfony Validator

PSR‑7 Payloads werden jetzt strukturiert geprüft. Feldfehler kommen sauber gesammelt zurück. Kein Wildwuchs, keine halbgaren Checks.

5. Graph‑Endpoint korrekt aggregiert

Employee + Skills + Evidence Reines JSON, kein JSON‑LD (noch nicht). Genau wie die SPEC es verlangt.

Gefundene Abweichung (Detail)

Problem: Skill‑Update interpretierte skillId inkonsistent.

Fix:

• Neues Repository‑Contract
• Neue DB‑Implementierung
• Controller‑Umstellung
• Lookup jetzt korrekt über (employee_id, skill_id)

Testing

Alles grün:

php -l app/Domain/Skill/EmployeeSkillRepository.php
php -l app/Infrastructure/Persistence/RepositoryDb/EmployeeSkillRepositoryDb.php
php -l app/Http/Controller/SkillEvidenceGraphController.php

Commit c332777 erstellt, PR aktualisiert.

Fazit

Ich habe jetzt einen AuditWriter. Nicht als Teil des Workflows — sondern als Teil der Anwendung.

Und damit ist das System offiziell in der Lage, nicht nur Daten zu verändern, sondern auch nachvollziehbar zu dokumentieren, wer diese Veränderung ausgelöst hat.

Das ist kein „BigBrother“. Das ist professionelle Softwareentwicklung.

Weiter geht’s. Prompt 9 wartet.

P.S. ich habe jetzt schon gefühlte 1000 mal Speck geschrieben.
Vielleicht ist es Zeit für eine kurze Pause – Frühstück + Speck.
Oder Zeit für ein wenig Speck weg und eine Runde mit dem Hund.