blame76.com

Es ist soweit. Der letzte Prompt ist durch, der letzte Pull‑Request gemerged, ein frisches git clone, einmal die Befehle aus der README durchlaufen lassen – und dann:

docker compose up -d –build

Die Container starten. Keine Fehlermeldung. Breites Grinsen.

Und dann der nächste README‑Schritt: Browser öffnen, <strong>http://localhost eingeben … und dann BÄHM – die erste Fehlermeldung.

Für viele ist das der Moment, in dem man denkt: „Was für ein Scheiß. KI. Ernsthaft?“

Für mich als Entwickler war es eher: „Okay. Eine Fehlermeldung. Damit kann ich arbeiten.“

Denn der Code, der in den vorangegangenen Iterationen gut aussah, sah immer noch gut aus. Nur eben nicht vollständig. Ein paar Dinge fehlten. Ein paar Dinge waren nicht da, wo sie laut Code sein sollten. Vielleicht waren sie einmal da, wurden aber nicht sauber refactored. Alles kein Drama.

Die eigentliche Enttäuschung kam später – als localhost dann funktionierte Nicht wegen des Codes. Sondern wegen meiner SPEC.md.

Dort stand dieser Satz:

API‑first: UI ist ein Client der API. Keine direkte DB‑Kopplung.

Klingt gut. Klingt modern. Klingt nach Architektur.

War aber kopflos gedacht. Denn es stand nichts zum Frontend in der Spezifikation. Es war in meinem Kopf – zumindest dieses Bild von einem Frontend.

Und was Codex daraus gemacht hat, war der absolute Minimalstandard: eine Ausgabe der Mitarbeitertabelle – aber technisch sauber.

Dafür hat Codex den API‑First‑Ansatz ernst genommen. Sehr ernst. OpenAPI‑Dokumentation, saubere Endpoints, klare Trennung – alles da.

Und genau das ist der Punkt, an dem ich folgende Notiz gemacht habe:

Das Problem ist nicht Codex.Das Problem ist meine SPEC.md.

Was ich noch machen musste / wollte (oder machen ließ):

• Docker-/Phinx‑Setup repariert, Onboarding‑Doku verbessert
• verlässlichen Phinx‑Workflow dokumentiert, DB‑Reset‑Helper ergänzt
• Migrationen und Seeder robuster gemacht, README für Einsteiger (DAU) erweitert
• Phinx‑Crash in <code>employee_skill</code> behoben, hasColumn() ersetzt
• minimale Vanilla‑UI‑Grundstruktur für EMS‑HTML‑Routen ergänzt

Was ich bei VIPe falsch gemacht habe – und was ich beim nächsten Mal anders machen würde

Dieses Experiment hat mir gezeigt, wo VIPe stark ist – und wo ich selbst geschlampt habe.

SPEC.md war zu vage

„API‑first“ ohne Frontend‑Definition ist ein Rezept für Chaos. LLMs füllen Lücken nicht sinnvoll – sie improvisieren. Andererseits wollte ich das Experiment klein halten, also mal sehen was als nächstes kommt.

Notiz an mich selbst: hier irgendwas mit Templates.

Ich habe dem Modell zu sehr vertraut

„Bestätige, dass du SPEC.md verstanden hast“ ist ein Anti‑Pattern. LLMs simulieren Verständnis.

<strong>Nächstes Mal:</strong> Keine Bestätigungen. Stattdessen: „Liste alle Anforderungen aus SPEC.md auf, die du umsetzen wirst.“

Ich habe Drift unterschätzt

Jeder Prompt ist ein neuer Kontext. Ohne State‑Lock driftet das Modell.

Ich habe keine (oder zu wenig) No‑Guessing‑Regel gesetzt

LLMs raten, wenn etwas fehlt. Das ist ihr Naturell.

Nächstes Mal: „Wenn SPEC.md etwas nicht eindeutig definiert, stelle eine Rückfrage.“ ist vermutlich eindeutig eine blöde Idee.

Ich brauche mehr „Ich will was sehen“-Schritte

Das erste lauffähige System nicht auf die letzte Iteration schieben.

& der Moment, in dem meine Aufmerksamkeit wegdriftet

Ich sehe, dass etwas passiert, Commits fliegen durch, Tests laufen grün – aber ich habe mich, wie bereits erwähnt, in diesem Experiment bewusst aus dem aktiven Entwicklungsprozess herausgezogen, aber es fühlt sich echt nicht gut an.

Ich lese Code, ich sehe Struktur, ich sehe, dass das alles „richtig“ aussieht. Aber ich tippe nichts mehr selbst. Für die Statistik: Wir sind längst im vierstelligen Zeilenbereich, und irgendwo zwischen JSON‑LD, OpenAPI und Middleware‑Ketten merke ich, wie meine Aufmerksamkeit langsam ausfranst.

Und dann passiert etwas, das man in einem echten Projekt sofort spüren würde: Der AuditWriter verschwindet – und wird durch eine Middleware ersetzt.

Nicht als Bug, sondern als Refactoring: Weg von punktuellen Audit-Aufrufen, hin zu zentralen Audit Hooks. Keine Diskussion, wie der stille Kollege, der einfach mal macht.

In der Kriminologie nennt man das die Broken-Windows-Theorie: Wehret den Anfängen. Repariere das Fenster, bevor das ganze Viertel verkommt.

Mein LLM-Kollege hat hier offenbar eine extrem strikte Null-Toleranz-Strategie gegen technische Schulden gefahren. Wo ich vielleicht noch mit einem ‚Das machen wir später sauber‘ (dem sprichwörtlichen Riss in der Scheibe) gelebt hätte, hat die KI die gesamte Fassade bereits saniert.

Das ist technisch brillant, fühlt sich aber gespenstisch an. Es fehlt der soziale Aushandlungsprozess. In einem Team hätten wir über die Middleware-Architektur diskutiert, Vor- und Nachteile abgewogen und uns gemeinsam für den Umbau entschieden.

Die KI hingegen setzt Ordnung mit einer klinischen Effizienz durch, die keine Fragen stellt – sie repariert das Fenster nicht nur, sie baut das ganze Haus um, weil es ‚richtiger‘ ist.

Prompt 11 — Audit Hooks + Export Endpoint

Der Auftrag an Codex:

Implementiere gemäß SPEC.md:

Audit Hooks

• Middleware, die Write‑Operationen immer loggt
• Read‑Operationen loggen, wenn entity_type ∈ {employee, evidence, consent}
• Export immer loggen
• AuditRepositoryDb implementieren

Export Endpoint

• GET /employees/{id}/export
• Ausgabe: vollständiger Datensatz
  • Employee + Skills + Evidence + Consent
• Format: application/json (kein JSON‑LD)
• PII‑Masking nicht anwenden (Export ist legitim)

Logging

• Audit‑Channel
• App‑Channel

Vorgabe: Erzeuge ausschließlich Code, der SPEC.md exakt entspricht.

Was Codex umgesetzt hat

AuditMiddleware statt direkter Hooks

Die bisherigen, verteilten Audit‑Schreibaufrufe werden zentralisiert:

• AuditMiddleware entscheidet, wann geloggt wird:
  • erfolgreiche Write‑Operationen → immer
  • erfolgreiche GETs für employee, evidence, consent → werden geloggt
  • Export → wird immer geloggt
• Die Middleware schreibt in den bestehenden Audit‑Writer, inkl. Route‑ und Status‑Metadaten.

Die API‑Pipeline wird erweitert:

• AuditMiddleware wird in die Middleware‑Kette eingehängt.
• Routen bekommen spezifische Audit‑Kontexte.

Export‑Endpoint

Im EmployeeApiController kommt ein neuer Use‑Case dazu:

• GET /api/v1/employees/{id}/export
• Liefert:
  • Employee
  • Skills
  • Evidence
  • Consent
• Format: application/json
• Kein JSON‑LD
• Kein PII‑Masking – Export ist explizit legitim und vollständig.

Repositories & Wiring

• ConsentRepositoryDb wird vollständig implementiert:
  • save
  • byId
  • byEmployeeId
• Domain‑Interface um byEmployeeId erweitert, damit Consent im Export enthalten ist.
• AuditRepositoryDb wird als DB‑Implementierung ergänzt und im Bootstrap verdrahtet.
• Direkte Audit‑Schreibaufrufe in Skill/Evidence‑Controllern werden entfernt – Audit läuft jetzt zentral über Middleware.

Testing & Commit

Syntax‑Checks.

git status --short sauber. Commit 14c6537, PR: “Add audit hooks middleware and employee export endpoint”.

Review + Spec‑Abgleich zu Prompt 11

Der nächste Schritt: Audit‑Regeln wirklich ernst nehmen.

Prüffragen:

• Werden alle Audit‑Regeln exakt eingehalten?
• Werden Read‑Operationen korrekt gefiltert?
• Ist der Export vollständig und SPEC‑konform?
• Werden keine PII‑Felder im App‑Log ausgegeben?
• Ist das Audit‑Log vollständig (actor_id, entity_id, purpose, metadata)?

Gefundene Abweichungen & Fixes

Abweichung 1 — „Immer“ heißt wirklich immer

Problem: Write‑ und Export‑Operationen wurden nur bei Status < 400 geloggt. Fehlgeschlagene Writes waren damit nicht auditiert.

Fix: Status‑Filter entfernt. Entscheidung basiert jetzt nur noch auf dem Operationstyp:

• Write → immer
• Export → immer
• Read → nur für employee|evidence|consent

Abweichung 2 — Read‑Filter zu unscharf

Problem: Der Read‑Filter musste explizit auf employee|evidence|consent beschränkt sein.

Fix: Genau diese Menge ist jetzt in shouldLog() fest kodiert. Nur diese GETs werden auditiert.

Abweichung 3 — entity_id drohte zu „n/a“ zu werden

Problem: Bei manchen Write‑Fällen bestand die Gefahr, dass entity_id = n/a im Audit‑Log landet.

Fix:

• entity_id wird zuerst aus Route/Request gezogen
• bei Create/Update zusätzlich aus dem Response‑Payload extrahiert (id bzw. employee.id)

Abweichung 4 — PII im App‑Log

Problem: consent.scope wurde nur in einem zu engen Pfadfall maskiert.

Fix: Maskierung greift jetzt robust, sobald der Pfad consent enthält – auch verschachtelt.

Verifiziert im Spec‑Abgleich

• Export‑Endpoint liefert vollständig: Employee + Skills + Evidence + Consent Format: application/json, kein JSON‑LD, kein PII‑Masking im Export selbst.
• Audit‑Log enthält: actor_id, entity_id, purpose, metadata im Audit‑Channel. App‑Channel bleibt separat aktiv.

Commit 708a27e, PR: “Fix audit rule enforcement and consent scope log masking”.

Fazit

Der AuditWriter ist nicht verschwunden – er ist erwachsen geworden. Aus verstreuten Hooks ist eine zentrale AuditMiddleware geworden, die:

• Write‑Operationen immer auditiert,
• sensible Reads gezielt protokolliert,
• Exporte vollständig nachvollziehbar macht
• und gleichzeitig PII im App‑Log sauber maskiert.

Und ich sitze davor, schaue auf Commits, Logs und Specs – und merke, wie sich dieses Experiment immer mehr wie ein echtes System anfühlt, obwohl ich selbst kaum noch Code schreibe.

Der erste echte Hands‑on‑Moment rückt näher. Die Frage bleibt: Wie viel davon wird sich „richtig“ anfühlen – und wie viel „fremd“?

Oder: Warten auf Godot, aber mit 3.791 Zeilen Code

So, jetzt bin ich an dem Punkt angekommen, an dem sich jeder Schritt anfühlt wie „Warten auf Godot“. Ich sehe, dass etwas passiert, aber ich habe mich in diesem Experiment bewusst aus dem aktiven Entwicklungsprozess herausgezogen.

Was ich beim Code‑Review sehe, sieht gut aus. Für die Statistik: Aktuell liegen 3.791 Zeilen Code im Repo – das sind bereits deutlich mehr Zeilen, als die Hauptfiguren bei Beckett überhaupt sprechen.

Ich bleibe gespannt, vor allem auf das erste „Hands‑on“, und stelle mir die bange Frage: Wie groß wird am Ende die Ernüchterung sein – oder die Überraschung?

In dieser Runde: Prompt 9.

Der Auftrag: Prompt 9

JSON‑LD + Content Negotiation + OpenAPI

Implementiere gemäß SPEC.md:

• JSON‑LD Serializer
  • EmployeeJsonLdSerializer
  • SkillJsonLdSerializer
  • EvidenceJsonLdSerializer
  • URN‑IDs gemäß SPEC (urn:employee:*, urn:skill:*, urn:evidence:*)
  • @context: https://schema.org
• Content Negotiation
  • Accept: application/json → normale DTOs
  • Accept: application/ld+json → JSON‑LD Serializer
  • Middleware: ContentNegotiationMiddleware
• OpenAPI 3.1
  • openapi/openapi.yaml erstellen
  • alle Endpunkte aus SPEC.md dokumentieren
  • schema.org‑Begriffe als Referenz nutzen, aber keine externen Schemas einbinden
• /docs
  • statische OpenAPI‑UI unter public/docs
  • Nginx‑Route sicherstellen

Vorgabe: Erzeuge ausschließlich Code, der SPEC.md exakt entspricht.

Was Codex daraus gebaut hat

JSON‑LD‑Serializer

Codex ergänzt drei Serializer:

• EmployeeJsonLdSerializer
• SkillJsonLdSerializer
• EvidenceJsonLdSerializer

Alle mit:

• @context: https://schema.org
• URN‑basierten @id‑Werten gemäß SPEC:
  • urn:employee:*
  • urn:skill:*
  • urn:evidence:*

Listen werden als JSON‑LD‑ItemList ausgegeben.

Content Negotiation

Die neue ContentNegotiationMiddleware:

• akzeptiert:
  • application/json
  • application/ld+json
  • */* oder leer → Default: JSON
• liefert bei anderen Accept‑Headern:
  • 406 Not Acceptable
  • als RFC7807 Problem‑Details (application/problem+json)

Die API‑Pipeline in public/api.php wird erweitert:

• Middleware‑Reihenfolge: ContentNegotiation → Auth → Scope

EmployeeApiController und SkillEvidenceGraphController werden umgestellt:

• application/json → normale DTOs
• application/ld+json → JSON‑LD‑Serializer
• Listen als JSON‑LD‑ItemList

OpenAPI 3.1 & /docs

Codex baut eine neue openapi/openapi.yaml:

• OpenAPI 3.1
• dokumentierte Endpunktgruppen:
  • Auth
  • Employee CRUD
  • Skills/Evidence
  • Graph
  • Export/Erase
  • Audit
  • Health
  • Metrics
• Accept‑Negotiation und ProblemDetails‑Schema sind enthalten
• schema.org‑Begriffe werden referenziert, aber nicht extern eingebunden

Unter public/docs entsteht:

• eine statische OpenAPI‑UI (index.html, Swagger UI)
• eine Kopie der Spezifikation unter /docs/openapi.yaml

Nginx routet /docs auf diese UI.

Testing & Commit

Syntax‑Checks:

php -l app/Infrastructure/JsonLd/EmployeeJsonLdSerializer.php &&
php -l app/Infrastructure/JsonLd/SkillJsonLdSerializer.php &&
php -l app/Infrastructure/JsonLd/EvidenceJsonLdSerializer.php &&
php -l app/Http/Middleware/ContentNegotiationMiddleware.php &&
php -l app/Http/Controller/EmployeeApiController.php &&
php -l app/Http/Controller/SkillEvidenceGraphController.php &&
php -l public/api.php &&
php -l app/Http/bootstrap.php

Zusätzlich:

• lokaler PHP‑Server für /docs gestartet
• Commit: “Add JSON-LD serialization, content negotiation, and OpenAPI docs”
• PR via make_pr erstellt

Review & Spec‑Abgleich zu Prompt 9

Der nächste Schritt: Spec‑Abgleich.

Prüffragen:

• JSON‑LD‑Ausgabe korrekt?
• URN‑IDs korrekt aufgebaut?
• Content Negotiation korrekt implementiert?
• openapi.yaml vollständig und valide?
• /docs korrekt erreichbar?

Gefundene Abweichungen & Fixes

1. Content Negotiation Priorität

Problem: application/json wurde vor application/ld+json geprüft. Bei gemischten Accept‑Headern konnte dadurch fälschlich JSON statt JSON‑LD gewählt werden.

Fix: Reihenfolge angepasst:

1. application/ld+json
2. application/json
3. */* oder leer → JSON‑Default

Jetzt ist die Präferenz deterministisch und spec‑konform.

2. OpenAPI 3.1 Validität

Problem: In openapi/openapi.yaml waren noch nullable: true‑Einträge vorhanden – OpenAPI‑3.0‑Stil, nicht JSON‑Schema‑konform für 3.1.

Fix:

• nullable: true entfernt
• durch Typ‑Unionen ersetzt, z.B.:

  type: [string, 'null']

• sowohl in der kanonischen Datei als auch in der statischen Docs‑Kopie (public/docs/openapi.yaml)

Ergebnis des Spec‑Abgleichs

• JSON‑LD‑Ausgabe korrekt? Ja, bereits spec‑konform, unverändert belassen.
• URN‑IDs korrekt aufgebaut? Ja, urn:employee:*, urn:skill:*, urn:evidence:* – unverändert.
• Content Negotiation korrekt? Nach Fix: Ja, mit korrekter Präferenz für application/ld+json.
• OpenAPI.yaml vollständig & valide? Vollständigkeit wie im vorherigen PR, Validitätsproblem (nullable) behoben.
• /docs erreichbar? Nginx‑Routing korrekt, /docs und /docs/openapi.yaml liefern 200.

Testing im Spec‑Abgleich

php -l app/Http/Middleware/ContentNegotiationMiddleware.php
ruby -e "require 'yaml'; YAML.load_file('openapi/openapi.yaml'); YAML.load_file('public/docs/openapi.yaml'); puts 'yaml ok'"
rg -n "nullable:" openapi/openapi.yaml public/docs/openapi.yaml   # keine Treffer
curl -s -o /tmp/docs.html -w "%{http_code}" http://127.0.0.1:8000/docs/      # 200
curl -s -o /tmp/openapi.yml -w "%{http_code}" http://127.0.0.1:8000/docs/openapi.yaml  # 200

Korrekturen committed, PR aktualisiert.

Fazit

Wir sind jetzt an einem Punkt, an dem das System:

• JSON‑LD spricht,
• Content Negotiation beherrscht,
• eine vollständige OpenAPI 3.1 hat
• und eine Docs‑UI unter /docs ausliefert.

Und ich sitze davor, schaue auf 3.791 Zeilen KI‑generierten Code und frage mich:

Wird das erste Hands‑on ein Desaster – oder eine positive Zumutung?

Oder: Der Moment, in dem man merkt, wie viel Naming‑Pain einem ein LLM erspart

Das Beste an diesem Prozess? Wer selbst schon einmal Code geschrieben hat – Zeile für Zeile, ohne Copy & Paste von StackOverflow – kennt diesen Moment:

„Wie nenne ich diese Funktion? Diese Variable? Diesen Endpoint? So, dass Kolleg:innen verstehen, was ich wollte, was ich gemacht habe, welche Akzeptanzkriterien ich im Kopf hatte?“

Dieser ganze Naming‑Pain fällt hier einfach weg.

Okay, das eine oder andere musste ich in der SPEC.md festnageln. Aber das bedeutet: einmal den Kopf rauchen lassen – und dann ab dafür. Der Rest ist Fließband.

Prompt 7 – Skills, Evidence, Graph Endpoint

Der Auftrag war klar:

Implementiere gemäß SPEC.md:

Skills

• POST /employees/{id}/skills
• PATCH /employees/{id}/skills/{skillId}

Evidence

• POST /employees/{id}/evidence

Graph Endpoint

• GET /employees/{id}/graph
• Aggregierter DTO: Employee + Skills + Evidence
• JSON‑Ausgabe (noch ohne JSON‑LD)

Validierung

• PSR‑7 Request
• Symfony Validator
• Fehlerformat: RFC7807 Problem Details

Logging

• App‑Log für alle Requests
• Audit‑Log für alle Write‑Operationen

Kein JSON‑LD in diesem Schritt. Keine Extras. Nur SPEC.

Codex legt los

Und wie immer beginnt alles mit dem Murmeltier‑Prompt:

„Lies die SPEC.md vollständig. Du implementierst das Projekt strikt nach dieser Spezifikation. Du darfst keine eigenen Patterns, Libraries oder Strukturen erfinden…“

Dann geht’s los. Und der Codex‑Log liest sich wie eine Mischung aus To‑Do‑Liste und innerem Monolog eines sehr gewissenhaften Juniors:

• Starting repository inspection
• Planning dependency management
• Implementing API entrypoints
• Adding secure session cookie parameters
• Implementing repo mapping
• Validating PHP syntax
• Preparing commit with spec checks

Nichts Magisches. Aber sehr zuverlässig.

Was tatsächlich umgesetzt wurde

Neue Endpunkte

Verdrahtet in FastRoute:

• POST /api/v1/employees/{id}/skills
• PATCH /api/v1/employees/{id}/skills/{skillId}
• POST /api/v1/employees/{id}/evidence
• GET /api/v1/employees/{id}/graph

Controller‑Logik

• Skill‑Erstellung inkl. XOR‑Constraint: genau eins von skill_id oder custom_label
• Skill‑Update
• Evidence‑Erstellung
• Graph‑Aggregation: Employee + Skills + Evidence als JSON

Validierung

• Symfony Validator integriert
• RequestValidator ergänzt
• RFC7807‑konforme Fehler‑Responses (application/problem+json)

Audit‑Logging

• Zentral über AuditWriter
• Für alle neuen Write‑Operationen angebunden
• Auch Employee‑Writes profitieren davon

Repository‑Erweiterungen

• employee_skill, evidence, skill, audit_log konkret implementiert
• byEmployeeId‑Methoden ergänzt, damit der Graph‑Endpoint aggregieren kann

Bootstrap‑Erweiterungen

• Validator
• Neue Repositories
• AuditWriter
• OpenAPI aktualisiert
• symfony/validator als Dependency ergänzt

Testing

Composer

⚠️ composer install scheitert wie immer an der Umgebung (Tunnel‑Fehler, 403).

PHP‑Syntax

Alles grün:

php -l app/Http/Controller/SkillEvidenceGraphController.php &&
php -l app/Http/Controller/EmployeeApiController.php &&
php -l app/Http/Request/RequestValidator.php &&
php -l public/api.php &&
php -l app/Infrastructure/Persistence/RepositoryDb/EmployeeSkillRepositoryDb.php &&
php -l app/Infrastructure/Persistence/RepositoryDb/EvidenceRepositoryDb.php &&
php -l app/Infrastructure/Persistence/RepositoryDb/AuditLogRepositoryDb.php &&
php -l app/Infrastructure/Persistence/RepositoryDb/SkillRepositoryDb.php &&
php -l app/Http/bootstrap.php &&
php -l app/Http/Response/JsonResponseFactory.php

Commit erstellt, PR angelegt.

Fazit

Prompt 7 ist einer dieser Schritte, die man im klassischen Coding gerne vor sich herschiebt, weil sie viel Kleinkram enthalten: Validierung, Aggregation, Repositories, Logging, Fehlerformate.

Im VIPe‑Prozess ist es einfach ein weiterer Baustein. Ein klarer Schritt. Ein definierter Output.

Und genau das macht diesen Workflow so angenehm: Kein Naming‑Pain. Keine Architektur‑Diskussionen. Keine spontanen „Ich mach das mal anders“-Momente.

Nur SPEC → Prompt → Output.

Weiter geht’s. Prompt 8 wartet.

Oder: Warum sich diese Reviews immer anfühlen wie eine Agentur‑Simulation

Diese Spec‑Abgleiche muten immer ein wenig an wie eine Real‑World‑Simulation aus einer Digitalagentur. Der Kunde (die SPEC.md) hat etwas definiert. Der Entwickler (Codex) hat etwas gebaut. Und jetzt sitzen wir da und prüfen, ob beides wirklich zusammenpasst.

Und wie in jeder Agentur‑Woche gibt es natürlich Abweichungen.

Die wichtigste diesmal: Der Logout‑Endpoint fehlte.

Ja, wirklich. Der Auth‑Contract sagt klar: login / logout / me. Aber Codex hatte nur login und me implementiert. Ein klassischer Fall von „SPEC überflogen, nicht gelesen“. Ein Fehler, den Juniors machen. Und Seniors. Und LLMs.

Alles fein – aber das Log möchte ich dir (wer auch immer du bist) nicht vorenthalten.

Was Codex korrigiert hat

1. Fehlender Logout‑Endpoint

Abweichung: POST /api/v1/auth/logout fehlte komplett. Fix: Route ergänzt, Controller‑Logik implementiert.

2. Unvollständiger Session‑Lifecycle

Abweichung:

• Keine Session‑ID‑Rotation beim Login
• Kein korrektes Invalidieren beim Logout

Fix:

• session_regenerate_id(true) beim Login
• Vollständiges Leeren + Cookie‑Löschen + session_destroy() beim Logout
• Weiterhin HttpOnly + SameSite=Lax

3. Logging nutzte falsche Request‑Instanz

Abweichung: Das Logging griff auf die ursprüngliche Request‑Instanz zu. Ergebnis: actor_id wurde trotz erfolgreicher Auth als anonymous geloggt.

Fix: Die post‑middleware Request‑Instanz wird jetzt für Logging genutzt.

4. Content‑Negotiation fehlte

Abweichung: Employee‑Responses ignorierten den Accept‑Header. application/json und application/ld+json wurden nicht unterschieden.

Fix: Content‑Negotiation ergänzt, Content‑Type korrekt gesetzt.

Ergebnis der Prüfbereiche

• Routing: korrekt, alle Auth‑ und Employee‑Routen sauber verdrahtet
• Auth: Session + Bearer + Scopes, Middleware‑Reihenfolge stimmt
• Sessions: korrekt gesetzt, inklusive Regeneration und sauberem Logout
• Employee CRUD: vollständig
• HTML‑Views: minimal, funktional, spec‑konform

Testing

php -l public/api.php &&
php -l app/Infrastructure/Auth/AuthService.php &&
php -l app/Http/Controller/AuthController.php &&
php -l app/Http/Controller/EmployeeApiController.php

Alles grün.

Commit f86bfe9 wurde erstellt, PR aktualisiert.

Fazit

Diese Spec‑Abgleiche sind der Moment, in dem man merkt, wie nah LLM‑Entwicklung an echter Agenturarbeit ist:

• Die Maschine macht dieselben Fehler wie Menschen.
• Sie überliest Dinge.
• Sie ergänzt Dinge, die nicht gefordert waren.
• Sie vergisst Dinge, die klar definiert waren.

Und genau deshalb ist VIPe so wertvoll: Der Prozess fängt diese Drift ab, bevor sie sich durch das ganze Projekt frisst.

Weiter geht’s. Prompt 7 wartet.

Der letzte Akt gestern: REVERT auf Prompt 5. Der Workflow war aus der Spur gelaufen, der Review‑Baustein zu groß geworden, der Prozess nicht mehr minimal, sondern überambitioniert.

Dann: Binge‑Watching, Schlaf, Reset. Und jetzt wieder vor dem Rechner.

Mit dem gleichen unguten Gefühl wie vorher: Egal ob VIBE‑Coding oder VIPe‑Coding – der gesamte Prozess ist weit entfernt von 99,9 % Industriestandard, was Input und Output angeht.

Egal, wie fest der Prompt geschnürt ist, das Ergebnis ist – zumindest, wenn man externe Tools nutzt – abhängig von den „Launen“ der Anwendung. OpenAI und Co. nennen es Feature. Für mich ist es der Tod des Entwicklers.

Aber kein Stress: Das hier ist ein Test. Ein Proof of Concept, um genau diese Grenzen erfahrbar zu machen.

Zurück zum Fließband.

Der Murmeltier‑Prompt

Wie immer beginnt alles mit dem gleichen Ritual – dem Murmeltier‑Prompt:

„Lies die Datei SPEC.md vollständig. Du implementierst das Projekt strikt nach dieser Spezifikation. Du darfst keine eigenen Patterns, Libraries oder Strukturen erfinden…“

Der Rahmen steht. Die Regeln sind klar. Die Maschine weiß (zumindest behauptet sie es), was sie zu tun hat.

Dann der nächste Iterationsschritt: Prompt 5 (erneut) Routing + Auth + Employee CRUD

Implementiere:

• FastRoute Routing (UI + API)
• AuthMiddleware + ScopeMiddleware
• Session‑Login (POST /auth/login)
• GET /me
• Employee CRUD (API)
• Einfache HTML‑Views für Employee‑Liste + Detail

Beachte:

• PSR‑7 Request/Response
• nyholm/psr7-server
• SapiEmitter
• PII‑Masking in Logs

Codex am Fließband

Der Codex‑Log liest sich wie eine To‑Do‑Liste im Kopf eines sehr disziplinierten Juniors:

• Starting repository inspection
• Checking for composer.json presence
• Planning dependency management
• Planning response helpers
• Implementing database repository methods
• Implementing API entrypoints
• Adding secure session cookie parameters
• Validating PHP syntax on changes
• Testing composer availability
• Preparing commit with spec checks
• Committing recent changes

Kein Agent‑Skill, kein „magischer“ Workflow – nur stumpfes, aber sauberes Abarbeiten.

Was tatsächlich passiert ist

In der Zusammenfassung wird klar, was dieser zweite Anlauf von Prompt 5 wirklich geleistet hat:

• API‑Frontcontroller public/api.php mit FastRoute‑Routing für POST /api/v1/auth/login, GET /api/v1/me und vollständigem Employee‑CRUD (GET/POST/GET{id}/PUT{id}/DELETE{id}), inkl. Middleware‑Pipeline (AuthMiddleware, ScopeMiddleware) und SapiEmitter‑Ausgabe.
• UI‑Frontcontroller public/index.php auf FastRoute umgestellt, HTML‑Routen für Employee‑Liste (/) und Detail (/employees/{id}) angebunden.
• PSR‑7‑Bootstrap mit nyholm/psr7-server: zentrale Request‑Erzeugung, Verdrahtung von Services (PDO, Auth, Logger, Repository, JSON‑Response‑Factory).
• Auth & Scopes:
  • Session‑Login mit HttpOnly + SameSite=Lax
  • Bearer‑Token‑Support im AuthService
  • AuthMiddleware für 401, ScopeMiddleware für 403 mit RFC7807‑ähnlichen Problem‑Responses
  • AuthController mit login() und me()
• Employee CRUD im EmployeeApiController: Create/Read/Update/Delete/List – inklusive JSON‑LD‑Feldern (@context, @type, @id) in der Serialisierung.
• SSR‑Views für Employee‑Liste + Detail, inkl. Skip‑Link.
• Datenzugriff:
  • EmployeeRepository um all() und delete() erweitert
  • EmployeeRepositoryDb mit Upsert, Lookup, Listenabfrage und Soft‑Delete implementiert
  • PDO‑Factory für MariaDB ergänzt
• Logging & PII‑Masking:
  • JSON‑Logging mit Maskierung von email, phone, address, consent.scope
  • E‑Mail‑Maskierung im Stil a***@domain
• Infrastruktur:
  • Middleware‑Dispatcher
  • JSON‑Response‑Factory
  • Composer‑Dependencies: fast-route, nyholm/psr7-server, laminas-httphandlerrunner

Testing & Grenzen

Die Syntax‑Checks laufen durch:

php -l public/api.php &&
php -l public/index.php &&
php -l app/Infrastructure/Auth/AuthService.php &&
php -l app/Infrastructure/Logging/JsonLogger.php &&
php -l app/Http/Controller/EmployeeApiController.php &&
php -l app/Http/Controller/EmployeeViewController.php &&
php -l app/Http/Controller/AuthController.php &&
php -l app/Infrastructure/Persistence/RepositoryDb/EmployeeRepositoryDb.php &&
php -l app/Http/bootstrap.php

Alles grün.

composer install scheitert erwartungsgemäß an Netzwerk/Packagist‑Restriktionen. Ein Playwright‑page.goto('http://127.0.0.1/') läuft ins Leere – kein Webserver in dieser Umgebung.

Trotzdem: Die Änderungen werden committed (9aa8dfc), ein PR via make_pr erstellt.

Prompt 5 ist damit – im zweiten Anlauf – wirklich da, wo er hingehört: nicht perfekt, nicht produktionsreif, aber konsistent mit der SPEC und nachvollziehbar dokumentiert.

Fazit dieses Schritts

Der Tag gestern endete mit einem REVERT. Heute beginnt er mit einem konsistenten Commit.

Und irgendwo dazwischen liegt die eigentliche Wahrheit von VIPe: Es geht nicht darum, dass die Maschine perfekt ist. Es geht darum, dass der Prozess so gebaut ist, dass man jeden Drift sieht, zurückdrehen und neu ansetzen kann.

Zurück aufs Fließband. Der nächste Prompt wartet schon.