Spurwert

First module spec, written down to issue-ready detail. What's in it:

• 57 user stories — from the customer who books to the shop that blocks slots.
• Data model — tables, relations, required fields, deletion logic.
• Edge functions — which server endpoints need to exist and what they return.
• Acceptance criteria per story, so later it's clear when something is actually done.

Four separate reviewers took the PRD apart in parallel, each with their own lens:

• SaaS architecture — how do frontend, backend, and database hang together cleanly?
• Postgres schema — are the tables built so they still hold up at 50 shops?
• GDPR compliance — duties around data protection, deletion, access requests, processor agreements.
• Multi-tenant operations — how do you run this so one shop login never sees another shop's data?

From the four reviews, 12 hard blockers were consolidated (see next step).

Every load-bearing architecture decision filed as its own document, with context, alternatives considered, and consequences. The eight ADRs:

• Edge function as the single insert gate
• Multi-tenancy by design from day 1
• Multi-tenant ops foundation
• Customer identity normalized (no pseudo-duplicate swamp)
• Tenant resolution as its own module
• Per-service detail tables instead of one giant table
• Security-definer RPCs instead of a raw service-role key
• Tenant branding white-label by default ("Powered by Spurwert" only quietly in the footer)

The PRD was cut into 20 vertical tracer-bullet slices. Each issue runs from data model to frontend through every layer. The order is fixed:

• Foundation (#01–#03) — repo setup, database schema, tenant resolution.
• Core booking (#04–#09) — booking server endpoint, mail dispatch, availability module, vehicle ID, wizard frontend.
• Backend (#10–#13) — login, booking overview, manual appointment entry, blocked days.
• GDPR (#14–#15) — data export, anonymization.
• Polish (#16–#19) — master data, calendar sync, holidays, localStorage auto-expire.
• E2E + drill (#20) — smoke test and backup-restore drill.

Phase 1 skeleton fully live, all 20 vertical-slice issues shipped. Re-audit verdict on 2026-05-18: Phase 1 GO. In a wave session on 2026-05-18, 11 PRs were merged together:

Wave-session merges · 11 PRs

• #24 SMTP fix — denomailer → nodemailer (Edge-Streams crash fixed).
• #26 Polish wave — progress bar plus Mon–Fri mini calendar.
• #28 Glass-light state machine — MVP reactivated, decision table expanded.
• #30 Tenant-branding rendering — logo, colors, mail-from per tenant live.
• #32 Mobile touch targets — walkthrough findings M26.
• #33 Audit-v2 methodology + tooling — re-audit run 2026-05-18.
• #34 Backend UI polish — walkthrough findings B26.
• #42 Production hardening — 4 blockers plus 3 majors from the re-audit.
• #43 Polish walkthrough findings — P26.
• #44 Re-audit iter-2 — sub-task fixes plus skip-test reactivation.
• #45 Recovery markers and password-login toggle removed from Phase 1.

Also live

• Cloudflare Workers DDoS protection in front of the create-booking gate (IP bucket).
• Pre-launch audit methodology v2 — 6 mandatory steps (code, schema, GDPR, Playwright click test, performance, security).
• Design system with Spurwert override (indianred hue) prepared for token consolidation.

Only two small production tasks left (sync-calendar edge deploy, 2 migrations to commit as files). After that, test run with persona scripts A/B/C. Phase 1b: see step 16.

Issue #21 Wizard Glass-Light merged (PR #15 + #28). 9-step wizard live: damage description → damage-location sketch → insurance path with comprehensive type and coverage → slot selection. MVP state machine reactivated, decision table expanded, insurance step switched to comprehensive type. UX source: the archived 9-step variant from automuc.de.