Prompt 5, Take 2 – Zurück aufs Fließband

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.