Spurwert

Das erste Modul-Spec, geschrieben bis zum Issue-fähigen Detailgrad. Was drin steht:

• 57 User-Stories — vom Kunden, der bucht, bis zur Werkstatt, die Termine sperrt.
• Datenmodell — Tabellen, Beziehungen, Pflicht-Felder, Lösch-Logik.
• Edge-Functions — welche Server-Endpoints es geben muss, was die zurückgeben.
• Akzeptanz-Kriterien pro Story — damit später klar ist, wann etwas wirklich fertig ist.

Vier eigenständige Reviewer haben das PRD parallel zerlegt — jeder mit eigener Brille:

• SaaS-Architektur — wie hängen Frontend, Backend, Datenbank sauber zusammen?
• Postgres-Schema — sind die Tabellen so gebaut, dass sie auch bei 50 Werkstätten noch funktionieren?
• DSGVO-Compliance — Datenschutz-Pflichten, Löschpflicht, Auskunftspflicht, Datenschutz-Vereinbarung.
• Multi-Tenant-Operations — wie betreibt man das Ding so, dass ein Werkstatt-Login nie Daten einer anderen Werkstatt sieht?

Aus den vier Reviews wurden 12 Hard-Blocker konsolidiert (siehe nächster Schritt).

Jede tragende Architektur-Entscheidung als eigenes Dokument abgelegt — mit Kontext, geprüften Alternativen und Konsequenzen. Die acht ADRs:

• Edge-Function als zentrale Insert-Schleuse
• Multi-Tenancy by Design ab Tag 1
• Multi-Tenant-Operations-Foundation
• Customer-Identity normalisiert (kein Pseudo-Duplikat-Sumpf)
• Tenant-Resolution als eigenes Modul
• Pro-Service-Detail-Tabellen statt einer riesigen Tabelle
• Security-Definer-RPCs statt blankem Service-Role-Key
• Tenant-Branding white-label by Default („Powered by Spurwert" nur dezent im Footer)

Aus dem PRD wurden 20 vertikale Tracer-Bullet-Slices geschnitten — jedes Issue schneidet vom Datenmodell bis zum Frontend durch alle Layer. Die Reihenfolge ist klar:

• Foundation (#01–#03) — Repo-Setup, Datenbank-Schema, Tenant-Resolution.
• Core-Booking (#04–#09) — Buchungs-Server-Endpoint, Mail-Versand, Verfügbarkeits-Modul, Fahrzeug-ID, Wizard-Frontend.
• Backend (#10–#13) — Login, Buchungs-Übersicht, Termine nachtragen, geblockte Tage.
• DSGVO (#14–#15) — Datenexport, Anonymisierung.
• Polish (#16–#19) — Stammdaten, Calendar-Sync, Feiertage, localStorage-Auto-Expire.
• E2E + Drill (#20) — Smoke-Test und Backup-Restore-Übung.

Phase-1-Skelett vollständig live, alle 20 Vertical-Slice-Issues durch. Re-Audit-Verdict am 2026-05-18: Phase 1 GO. In einer Wave-Session am 2026-05-18 wurden 11 PRs zusammen gemerged:

Wave-Session-Merges · 11 PRs

• #24 SMTP-Fix — denomailer → nodemailer (Edge-Streams-Crash behoben).
• #26 Polish-Wave — Progress-Bar plus Mo-Fr-Mini-Kalender.
• #28 Glas-Light-State-Machine — MVP reaktiviert, Decision-Table erweitert.
• #30 Tenant-Branding-Rendering — Logo, Farben, Mail-From pro Tenant live.
• #32 Mobile-Touch-Targets — Walkthrough-Findings M26.
• #33 Audit-v2-Methodik + Tooling — Re-Audit-Run 2026-05-18.
• #34 Backend-UI-Polish — Walkthrough-Findings B26.
• #42 Production-Hardening — 4 Blocker plus 3 Major aus Re-Audit.
• #43 Polish-Walkthrough-Findings — P26.
• #44 Re-Audit-Iter-2 — Sub-Task-Fixes plus Skip-Test-Reaktivierung.
• #45 Recovery-Marker und Passwort-Login-Toggle aus Phase 1 entfernt.

Zusätzlich live

• Cloudflare Workers DDoS-Schutz vor der create-booking-Schleuse (IP-Bucket).
• Pre-Launch-Audit-Methodik v2 — 6 Pflicht-Schritte (Code, Schema, DSGVO, Playwright-Klicktest, Performance, Security).
• Design-System mit Spurwert-Override (Indianred-Hue) vorbereitet für die Token-Konsolidierung.

Offen sind nur noch zwei kleine Production-Tasks (sync-calendar-Edge-Deploy, 2 Migrations als Files committen). Danach Test-Run mit Persona-Skript A/B/C. Phase 1b siehe Schritt 16.

Issue #21 Wizard Glas-Light gemerged (PR #15 + #28). 9-Step-Wizard live: Schadensbeschreibung → Damage-Location-Skizze → Versicherungs-Pfad mit KaskoArt und Coverage → Termin-Auswahl. MVP-State-Machine reaktiviert, Decision-Table erweitert, Insurance-Step auf Kasko-Art umgestellt. UX-Source: die archivierte 9-Step-Variante von automuc.de.