Decisiones (Bloque B)

Decisiones (Bloque B)

Registro autoritativo de las 13 decisiones oficiales tomadas por Eric el 2026-07-11 que guiaron la reconciliación código ↔ esquema Supabase. Cualquier sesión futura sigue esto sin volver a preguntar.

Principio rector: el esquema desplegado en Supabase (rebuild) es la fuente de verdad del diseño. El código del pos-backend se adapta a él (no al revés). Lo desplegado en jsonb/consolidado gana sobre el modelo normalizado viejo del código.

Las 13 decisiones

#TemaElegidoRazón / detalle
A0orders/order_items/cash: código ↔ desplegadoAdaptar código al desplegadoLo desplegado (combos, KDS kds_*, modifiers jsonb, cash con analítica) es el diseño superior; no revertir.
A1Pagos: normalizado vs jsonbjsonb (orders.payment_details + cash_sessions.by_payment_method/total_tips)Reportes SQL por método no son requisito hoy; se agrega tabla payments después si hace falta.
A2Delivery / mesas divididasColumnas de orders (order_type, cc_*, parent_order_id, is_split)El desplegado ya las tiene. Split-bill fino por comensal = pieza futura.
A3Modificadores en la ordenorder_items.modifiers jsonbSnapshot inmutable del modificador al momento de ordenar (correcto para ticket histórico). El catálogo menu_item_modifier_* es la definición.
A4“86” / agotadosmenu_items.is_available + menu_86_log (auditoría)Flag simple desplegado; “porciones restantes” = futuro no bloqueante.
BStaff (3 vías)Retirar (pivote tras diagnóstico)La feature staff-legacy consultaba la tabla staff que nunca existió, sin frontend. Se retiró staff.ts + /api/staff; operators es la fuente de verdad única.
CAuth de plataformaSupabase AuthrequirePlatformAdmin reescrito (getUser + admin_users); platform.ts sin /login; admin-central usa signInWithPassword.
DModelo de sesión (3 → 1)Consolidar en active_sessionsdevice_tokens/token_blacklist/restaurant_sessions/join_tokensactive_sessions. password_reset_tokens → Supabase Auth nativo.
EAds (linaje)Supabase advertisers/campaigns (modelo QR/paquete)El SERIAL ad_* nunca existió (fantasma). 11 tareas: auth anunciantes → Supabase Auth, pagos Stripe endurecidos (idempotentes), ad_impressionsqr_scans.
F1CFDI de ventas (restaurantes)DiferirNo es requisito de MVP; es feature + integración PAC. cfdi.ts sigue huérfano (no montado).
F2CFDI de anunciantes / fiscalCrear fiscal_invoices + invoice_itemsFolio secuencial INV-YYYYMM-000NNN. invoices.ts repuntado. La invoices de anunciantes/Stripe queda intacta.
G-shiftsTurnos (shifts/shift_sessions)Borrar router muertoshifts.ts borrado (nadie lo montaba). La remoción de shift_session_id de cash.ts/mixed-payment.ts se hizo dentro de A0.
G-walletWallet AprovechoDiferir (no enterrar)Parte de la visión futura, fuera del MVP. No borrar sus tablas todavía.

Orden de implementación acordado

  1. Piezas chicas de bajo riesgo primero: C (auth plataforma) → G-shifts → A4 (86) → F2 (fiscal) → B (staff).
  2. Proyectos grandes (sesión dedicada): A0-A2 (núcleo orders/cash/pagos/delivery) · D (sesiones) · E (ads).
  3. Diferidos: F1 (CFDI ventas) · G-wallet (Aprovecho).

Fuente: MiMente/00-Inbox/2026-07-11-iFondita-bloque-B-decisiones.md (registro oficial).