Admin rezervasyon cap'i yoktu — Cuma akşam 3 parti aynı masaya double-booked (PR #626 GGG F3)

Samsun Atakum Sahil Yolu nda 49 yaslarinda "Karadeniz Sofrasi" sahibi Necdet, 80-cover Karadeniz cuisine, 11 yil isletme. Cuma rezervasyon-driven (~%60 hafta sonu ciro). Gecen Cuma 19:30 Masa 12 (6-kisilik manzarali) icin **3 ayri parti aynı slot a geldi**: Yildirim ailesi (6 kisi), arkadaslari Aksoy (4 kisi), Beyaz sirketi is yemegi (8 kisi). Hepsi "19:30 Masa 12 rezervasyonum var" diyordu. Necdet admin panel inden 3 reservation entry pull etti — hepsini ayni gun ogleden sonra kendisi yaratmisti, ayni masa + ayni slot. "Ben 3 ayri parti yi double-book mu ettim?" Forensik: customer-side /api/reservations 3 katman cap (PR #539 MM max_party_size_per_reservation + PR #337 + PR #578 VV-C uq_resv_active_slot UNIQUE + per-restaurant daily 50 cap) ama admin-side /api/admin/reservations **hicbir cap ENFORCE ETMIYOR**. Niyet "operator manuel kontrol eder trust"; operator yorgun/dikkati dagiNK/hizli tiklama gercek dunyada bu trust yikilir. Admin handler INSERT raw (ON CONFLICT DO NOTHING bile yok). Necdet in 3 row 3 farkli internal table_id (frontend bug — table picker visually ayni masa farkli ID emit ediyor) UNIQUE constraint trigger olmamis. Wrong theory 1: "DB UNIQUE constraint var, kod tarafi niye?" — but DB UNIQUE (restaurant_id, table_id, reserved_at) farkli table_id de bypass eder. Doğru: customer-side enforced her cap admin-side EXPLICIT enforce edilmeli. Sweep 4 admin sibling cap-miss: /api/admin/reservations (3-cap), /api/admin/orders (items.length cap PR #570 UU F3), /api/admin/loyalty/adjust (phone canonicalization PR #626 GGG F5), /api/admin/promo/create (max_uses_per_customer PR #544 OO). **PR #626 batch GGG F3** 2-katmanli fix: **Layer 1 admin reservations cap enforce** 4 katman: (a) party-size cap customer parite, (b) table seat_capacity cross-check admin-only ekstra, (c) slot conflict UNIQUE + ON CONFLICT, (d) per-day cap. **Layer 2 sweep diger 3 admin sibling** ayni pattern. **Bonus UI** capacity-overflow confirmation prompt soft-cap: "Bu masa 6-kisilik, party 8 — Confirm?" hard-cap (party > 50) yine reject. Necdet next Cuma smooth: 1.st 4-Aksoy Masa 12, 2.nd 6-Yildirim ayni slot → 409 slot_already_taken Masa 7 onerdi onaylandi, 3.rd 8-Beyaz Masa 12 → party_size_exceeds_table Masa 4 (12-cap) onerdi onaylandi. 90-day platform-wide audit **23 restoran 47 double-booking** proactive apology + 3-ay Pro tier. Necdet 6-ay Pro tier + Hall of Fame "Helped harden admin endpoint parity." Pattern: **customer-side endpoint lerde enforce edilen her cap (party-size, per-day count, slot UNIQUE, per-customer use, length, format) admin-side sibling endpoint lerde de EXPLICIT enforce edilmeli. "Operator manuel kontrol eder" mentalitesi gercek dunyada her zaman yikilir — operator yorgun, dikkati dagiNK, hizli tiklama; manual data entry hata yapar.** Implementation checklist: (1) customer-side cap layer ler list/sweep; (2) admin-side EXPLICIT enforce (DB UNIQUE yetmez, route handler pre-INSERT); (3) UI soft-cap confirmation prompt operator override explicit consent; (4) hard-cap reject, soft-cap confirmation; (5) quarterly grep audit customer vs admin sibling diff; (6) penetration test admin bypass scenario; (7) production backfill cap-violation tespit + proactive apology. Tobias Munich Schwabing Schwabinger Stube version Bavarian dinner ayni flow.

İlgili makaleler