Mit Prompt 5 fühlt sich das Projekt zum ersten Mal wie eine „richtige“ Anwendung an. Bis hierhin hatten wir Struktur, Migrations, Domain‑Layer. Jetzt kommen Routing, Auth, Sessions, CRUD und HTML‑Views dazu – also genau der Teil, den man später im Alltag ständig anfasst.
Der Auftrag war klar umrissen:
FastRoute für UI und API, AuthMiddleware, ScopeMiddleware, Session‑Login, GET /me, Employee‑CRUD und einfache HTML‑Views. Dazu die Vorgaben aus der SPEC: PSR‑7, nyholm/psr7-server, SapiEmitter, PII‑Masking im Logging.
Codex startet mit einem Blick auf die bestehende Struktur: public‑Files, Nginx‑Routing, vorhandene Ordner. Dann wird der Kern geplant: Frontcontroller, Kernel, Middleware‑Pipeline, Controller, Views. Es ist dieser typische Moment, in dem aus einem Haufen Dateien langsam eine Anwendung wird.
PSR‑7 Frontcontroller & Kernel
Zuerst setzt Codex die PSR‑7‑Frontcontroller für UI und API um. Requests werden über nyholm/psr7-server erzeugt, Responses über den SapiEmitter ausgegeben. Session‑Cookies werden mit HttpOnly und SameSite=Lax gesetzt – wie in der SPEC vorgesehen.
Darauf aufbauend entsteht ein zentraler Kernel mit FastRoute‑Routing für UI und API. Die API‑Routen folgen dem Schema /api/v1/..., inklusive:
POST /api/v1/auth/loginGET /api/v1/me/api/v1/employees(CRUD)
Für die UI werden /, /employees und /employees/{id} als SSR‑Views angebunden.
Auth, Scopes & Actor‑Auflösung
Die Middleware‑Pipeline wird um AuthMiddleware und ScopeMiddleware ergänzt. Routen bekommen Scopes wie employees.read und employees.write zugewiesen.
Der AuthController übernimmt Session‑Login und /me, während der Kernel Actor‑Informationen aus Session oder Bearer‑Token auflöst.
Employee CRUD & Views
Für Employee wird ein kompletter CRUD‑Flow auf der API‑Seite umgesetzt:
- Listen
- Finden
- Erstellen (mit UUIDv4)
- Aktualisieren
- Soft‑Delete
Der Datenzugriff läuft über PDO, passend zur bestehenden Infrastruktur.
Parallel dazu entstehen einfache SSR‑HTML‑Views für die Employee‑Liste und das Detail. Mit Skip‑Link, wie in der SPEC gefordert – kein Design‑Feuerwerk, aber funktional und zugänglich.
Responses, Logging & PII‑Masking
Codex ergänzt ein Response‑Helper‑Modul für JSON, HTML und RFC7807‑Problem‑Responses. Dazu kommt strukturiertes Logging mit PII‑Masking:
- E‑Mail
- Telefon
- Adresse
consent.scope
werden maskiert, E‑Mails im Stil a***@domain.
Die benötigten Composer‑Dependencies für FastRoute, PSR‑7 und den Emitter werden in composer.json ergänzt – auch wenn composer install in der Umgebung später scheitert.
Testing & Grenzen der Umgebung
Die PHP‑Syntax aller relevanten Dateien wird geprüft: Frontcontroller, Kernel, Controller, Middleware, Logging, Persistence, Repositories, Response‑Helper – alles grün.
composer install schlägt erwartungsgemäß fehl (Packagist nicht erreichbar), und ein kurzer Test mit dem PHP‑Built‑in‑Server endet in einem 500er, weil vendor/autoload.php fehlt. Technisch ist das Setup aber konsistent.
Commit 7196740 wird erstellt, ein PR via make_pr angelegt.
Prompt 5 markiert damit den Punkt, an dem das System nicht mehr nur wie ein Gerüst aussieht, sondern wie eine Anwendung, die kurz davor ist, wirklich zu laufen.