Buen Día · Deck técnico para JP y los agentes
Lo que hay que averiguar, probar o decidir del lado técnico antes de comprometer alcance. Cada ítem dice quién lo mueve, qué desbloquea y de qué depende. Fuente de base: memo técnico y plan de rewards de Codex del 2026-09-13, verificados con documentación oficial de Shopify y Toast.
Actualización del 13-09, tarde: el research con fuentes oficiales está en research-2026-09-13.md. Lo que ya respondió, en una línea por ítem:
- A1 El acceso Standard viene incluido con Toast RMS Essentials en EE. UU., es sólo lectura y sí trae el webhook de órdenes. Falta confirmar que Buen Día tenga Essentials.
- A2 Toast Loyalty se exporta a mano desde Reports → Marketing → Rewards Accounts. Tener programa propio obliga a apagar Toast Loyalty.
- A4 Con Standard, los datos del cliente vienen sólo en pedidos Takeout o Delivery; en mostrador no hay identidad por API.
- A5 La API de loyalty identifica por teléfono, email, nombre, tarjeta física o código de barras. QR desde el teléfono con proveedor externo: sin fuente oficial; Incentivio dice que funciona.
- A6 Online Ordering no tiene deep links ni retorno de orden documentados. Integración propia exige acceso custom que pide el dueño a su rep.
- B1 y B3 No hay "merge" de tiendas: se migra con CSV o Matrixify (20 a 50 dólares por un mes). Se pierden códigos de descuento, gift cards emitidas y contraseñas.
- B4 y B5 Todo funciona en plan Basic: Markets, Checkout Kit 3.8.2, Apple Pay y Shop Pay, cuentas sin contraseña con PKCE. Sin Multipass.
- C1 Supabase Pro a 25 dólares por mes cubre 100.000 usuarios. Teléfono con Twilio Verify a 0,05 por verificación evita el registro 10DLC.
- C5 APNs directo desde una Edge Function, sin Firebase, con clave .p8.
- E1 Toast cobra 2,9 a 3,5 por ciento en online (cotizado por cliente), sin comisión por pedido desde 2023. Shopify Basic: 25 por mes y 2,9 más 30 centavos. Apple no cobra comisión por café ni merch.
- E2 Partner es para vendors multi cliente; un solo restaurante va por Custom. Plazo y costo no están publicados. Referencia de mercado: Craver a 99 dólares por mes.
Estados: Averiguar (pregunta al cliente o al proveedor) · Probar (con acceso real) · Decidir (JP, con alternativas explicadas) · Hacer (trabajo de agentes).
Quién: JP habla con Buen Día y con los proveedores. Codex valida capacidades con fuentes oficiales y corre las pruebas. Claude producto, diseño, Figma y lo que JP asigne. Delfi no aparece acá; lo suyo está en el deck de producto.
A · Toast, el nudo
| # | Pendiente | Estado | Quién | Desbloquea |
|---|---|---|---|---|
| A1 | Confirmar que Buen Día tiene Toast RMS Essentials (trae el acceso Standard, sólo lectura) y pedir el contacto de su rep para el acceso Custom. | Averiguar | JP | Todo lo de Toast |
| A2 | Si Toast Loyalty está activo en el café: cuántas cuentas, qué reglas, si hay exportación. | Averiguar | JP | Migración o convivencia de puntos viejos |
| A3 | Si usan KDS u Orders Hub y marcan "listo" de forma consistente. | Averiguar | JP | Pantalla de estado del pedido |
| A4 | Con acceso, probar leer una orden de mostrador y una de Online Ordering, y ver qué datos del cliente vienen con guest.pi:read. | Probar | Codex | Acreditar compras de café |
| A5 | Cómo asociar una compra de mostrador a un miembro de forma inequívoca. Candidatos: Loyalty Integration API (Toast llama a nuestro endpoint por teléfono o QR), o identificación manual del staff. | Probar | Codex | La pregunta abierta más grande del producto |
| A6 | Ruta de pedido de café en la V1: abrir el Online Ordering de Toast (sin traspaso de carrito ni retorno de orden documentados), o integración propia con Orders API (exige acceso de escritura, backend con carrito y reglas de precio). | Decidir | JP | Diseño de Order y pantalla puente |
| A7 | Menús: con Standard sólo V2. V3 exige integración de ordering. Confirmar cuál corresponde y qué está publicado. | Averiguar | Codex | Menú nativo |
| A8 | Webhooks disponibles para la location de Higuera St y para qué canal. | Averiguar | Codex | Estados en vivo y reconciliación |
Regla de este bloque: nada de lo de Toast se promete en producto hasta que A1 esté respondido y A4 o A5 probados.
B · Shopify
| # | Pendiente | Estado | Quién | Desbloquea |
|---|---|---|---|---|
| B1 | Qué rol cumple cada una de las dos tiendas, cuál tiene el catálogo real, si hay inventario duplicado, qué apps y canales tiene cada una. | Averiguar | JP + Codex | Consolidación |
| B2 | Auditoría completa de productos y variantes de las dos tiendas: talle, color, medidas de cuadros, tamaño de prints y stamps, stock, SKU, imágenes y su calidad. Entregar una matriz producto → variante → precio → stock → imagen → tienda. | Hacer | Codex | Diseño de selectores, estimación |
| B3 | Recomendación de consolidación con evidencia: qué tienda sobrevive, qué se migra, qué se pierde. La decisión es de JP con el cliente. | Decidir | JP | Una sola fuente en la app |
| B4 | Habilitar Storefront API en la tienda elegida y confirmar scopes y versión de customer accounts. | Hacer | Codex | Catálogo y carrito nativos |
| B5 | Checkout Kit para iOS con callback de compra completada, más accelerated checkout con Apple Pay y Shop Pay si Delfi lo pide. | Hacer | Codex | Checkout embebido |
| B6 | Webhooks de órdenes, pagos y devoluciones hacia nuestro backend. Recordar el límite de 60 días de historial por defecto. | Hacer | Codex | Puntos por merch |
| B7 | Probar vinculación de comprador autenticado e invitado con el miembro de Buen Día, y devoluciones parciales. | Probar | Codex | Adjudicar compras sin error |
C · Backend propio de Buen Día
| # | Pendiente | Estado | Quién | Desbloquea |
|---|---|---|---|---|
| C1 | Stack y hosting del backend: identidad, ledger de puntos, planes, notificaciones, panel de staff. Candidato natural: Supabase, que ya está conectado. | Decidir | JP | Todo lo propio |
| C2 | Modelo de datos del ledger: movimientos con origen, regla aplicada, comprobante; reservas de canje; ajustes por devolución. Sigue la propuesta de Codex. | Hacer | Codex + Claude | Rewards |
| C3 | Capa de identidad: cuenta por teléfono con vínculos explícitos a IDs de Shopify y Toast. Verificación por SMS o código. | Hacer | Codex | Adjudicación de compras |
| C4 | Panel de operación para el staff: publicar planes, confirmar asistencia, validar canjes, corregir con motivo y autor. Web simple. | Hacer | Claude o Codex | Actividades y canje en V1 |
| C5 | Notificaciones in-app confirmadas. Push pendiente de decisión de JP. Si va, APNs desde el backend. | Decidir | JP | Recordatorios de planes |
| C6 | Prevención de duplicados y reconciliación de eventos perdidos por canal. | Hacer | Codex | Confianza del saldo |
D · Reglas del programa
| # | Pendiente | Estado | Quién | Desbloquea |
|---|---|---|---|---|
| D1 | Importe elegible: con o sin impuestos, propinas, descuentos, gift cards. | Decidir | JP | Equivalencia de puntos |
| D2 | Equivalencias y costo de premios, calibradas con precios y márgenes del café. Meta de producto: tiempo al primer premio, la define Delfi con JP. | Decidir | JP | Rewards completo |
| D3 | Política de devoluciones cuando los puntos ya se gastaron. | Decidir | JP | Ajustes trazables |
| D4 | Canje de premios: en la V1 se valida en la app frente al staff, sin descuento aplicado en Toast ni Shopify. Integrar descuentos es fase posterior con validación propia. | Decidir | JP | Pantalla de canje |
E · Negocio y proveedores
| # | Pendiente | Estado | Quién | Desbloquea |
|---|---|---|---|---|
| E1 | Reducir fees e independizarse: es aspiración del cliente. Cuantificar qué paga hoy a Toast y Shopify y qué costaría reemplazar cada pieza, antes de discutirlo. | Hacer | Claude | Conversación honesta con el cliente |
| E2 | Costo y plazo de un acceso Custom de Toast, por escrito, con el rep de Buen Día. Partner queda descartado: es para vendors multi cliente. | Averiguar | JP | A6 |
F · Decisiones de JP que salieron del deck de Delfi
Mecanismos y alcance que tocan integración, operación o plata. Delfi diseña lo que se ve; esto lo decide JP con las alternativas explicadas.
| # | Pendiente | Estado | Quién | Desbloquea |
|---|---|---|---|---|
| F1 | Llave de identidad: teléfono verificado como cuenta principal, con email opcional. Alternativas: email, o Sign in with Apple. | Decidir | JP | C3, adjudicación de compras |
| F2 | Momento de identificarse: en la primera acción de cuenta (sumar puntos, canjear, anotarse a un plan), con una sola hoja reutilizable. | Decidir | JP | Diseño de la hoja de ingreso |
| F3 | Canje de premios en V1: se valida en la app frente al staff, sin descuento aplicado en Toast ni Shopify. Ya está como D4. | Decidir | JP | Pantalla de canje |
| F4 | Pase de miembro con QR para escanear en caja: se mantiene sólo si A5 prueba que Toast lo lee. Si no, identificación por teléfono con el staff. | Decidir | JP | Pantalla de pase |
| F5 | Cómo se confirma la asistencia a un plan: el staff u organizador marca desde un panel (recomendado), o QR en el lugar. | Decidir | JP | C4, puntos por actividades |
| F6 | Planes con entrada paga: recomendado no en V1; si los hay, se cobran en el café y la app sólo registra. | Decidir | JP | Alcance de Plans |
| F7 | Estado del pedido de café en vivo (preparando / listo): depende de A3 y A8. Delfi diseña dos versiones; JP elige cuando Toast responda. | Decidir | JP | Tarjeta de pedido en Home |
| F8 | Ruta del pedido de café: web de Toast dentro de la app con pantalla puente, o integración propia. Es A6; la pantalla puente se diseña después de decidir. | Decidir | JP | Diseño de Order |
| F9 | Checkout de merch como hoja embebida de Shopify (Checkout Kit) con confirmación propia. Es B5. | Decidir | JP | Diseño de checkout |
| F10 | "Mis pedidos" de merch con seguimiento de envío en V1: recomendado no, Shopify ya manda el mail con el tracking. | Decidir | JP | Alcance de Perfil |
| F11 | Notificaciones push además de las in-app: recomendado sí, sólo para recordatorio de plan y pedido listo. Es C5. | Decidir | JP | APNs en backend |
Orden sugerido
- A1, A2, A3, E2 son preguntas al cliente. Se hacen juntas, en una charla.
- B1 y B2 arrancan ya, no dependen de nadie.
- C1 se decide esta semana para poder empezar el ledger.
- Con A1 respondido, Codex corre A4 y A5. Ahí se decide A6.
- D1 a D4 se deciden cuando Delfi devuelva su deck y haya números del café.
Lo que se resuelva se carga en Supermemory con su fuente. Este archivo es la lista, no la verdad.