Recetas con presupuesto y comparación de súpers

Contexto hondureño que condiciona el diseño

Alcance funcional

Arquitectura propuesta

Stack y por qué

Fuentes de datos y estrategia de integración ética

El principio operativo: la app compara precios para ayudar a comprar, no copia catálogos. Sólo se guarda lo que hace falta para las listas de los usuarios, siempre con enlace a la tienda y atribución de fuente. Cada conector es un módulo con una ficha de cumplimiento revisada antes de encenderse y un interruptor para apagarlo en un minuto si una cadena lo pide.

Tres niveles, en orden de preferencia

Estado de cada fuente al 9 de septiembre de 2026

Ficha de cumplimiento por conector

connectors/la-colonia/compliance.yaml
  host: www.lacolonia.com
  discovery: sitemap            # nunca búsqueda interna
  robots_checked_at: 2026-09-09
  disallowed_paths_respected: [/api, /busca, /quick-view, /account, /checkout]
  user_agent: "CucharadaBot/0.1 (+https://cucharada.hn/bot; contacto@cucharada.hn)"
  rate: { min_interval_s: 4, window: "01:00-05:00 America/Tegucigalpa" }
  max_pages_per_run: 1500
  cache_ttl_h: 24
  stores_full_catalog: false     # sólo productos ligados a ingredientes
  auto_pause_on: [429, 403, challenge_page, error_rate > 5%]
  legal_review: { by: "pendiente", date: null }
  contact_letter_sent: null
  kill_switch: env CONNECTOR_LA_COLONIA=off

Caché y actualización de precios

Cuatro capas, cada una con su vigencia. La regla es que un precio nunca aparece sin su edad, y una edad mayor a la vigencia de su categoría se marca visiblemente como «por confirmar».

Vigencia por categoría

Refresco por demanda

• Prioridad alta: productos presentes en listas activas (modificadas en los últimos 7 días). Se refrescan primero dentro de la ventana permitida.
• Prioridad media: productos ligados a recetas populares de la semana.
• Prioridad baja: el resto del catálogo ligado a ingredientes, en rotación.
• Detección de cambio: se guarda un hash del bloque de precio de cada página; si no cambió, no se crea observación nueva, sólo se actualiza last_seen_at. Reduce escritura y ruido.
• Presupuesto de ritmo: con 4 s entre peticiones y una ventana de 4 h, un conector lee unas 3,600 páginas por noche. Alcanza para un catálogo de ingredientes de 1,500 a 2,500 productos por cadena. Si no alcanza, se reduce alcance, nunca se acelera.

Sincronización con el cliente

1. Al abrir, el cliente pide /precios?ciudad=tgu&desde=<marca>. La respuesta trae sólo cambios y suele pesar menos de 10 KB.
2. Si el paquete completo de la ciudad tiene una versión nueva y el usuario está en Wi-Fi (o aceptó usar datos), se descarga entero y reemplaza la tabla local en una transacción.
3. Android con soporte usa Periodic Background Sync para hacer esto en segundo plano; iOS no lo permite, así que se hace al abrir y se muestra un aviso discreto de «precios de hace 2 días» mientras llega.
4. Los reportes de precio del usuario se encolan localmente y se envían con Background Sync donde exista, o en la siguiente apertura.

Modelo de datos

La separación clave es entre ingrediente (lo que pide una receta: «frijol rojo»), producto (algo con marca y contenido neto: «Frijol rojo Natura, bolsa 1 lb») y producto en tienda (ese producto en una cadena, con su SKU, URL y precio). Las recetas se ligan a ingredientes; los precios, a productos en tienda. El emparejador conecta ambos mundos.

En el cliente, Dexie replica ingredients, products, store_products, current_prices, reference_prices, unit_defs, substitutes y las recetas publicadas para la ciudad elegida, más las tablas propias del usuario. Cada tabla lleva updated_at para la sincronización delta.

Lógica de negocio

Conversión de unidades

Toda cantidad se normaliza a una unidad base por dimensión: gramos para masa, mililitros para volumen, piezas para unidades discretas. Cruzar de volumen a masa requiere la densidad del ingrediente; cruzar de piezas a masa requiere un peso típico por pieza (un huevo mediano, 50 g; un tomate, 120 g). Si falta el dato, la conversión se rechaza y el ítem se muestra en su unidad original con una nota, nunca con una cifra inventada.

Escalado de porciones

Factor f = porciones deseadas / porciones base. Se aplica por ingrediente según su modo:

• Lineal (la mayoría): qty × f.
• Sublineal (sal, especias, ajo, consomé, levadura): qty × f^0.85 cuando f > 1, lineal cuando f < 1. Al duplicar la receta la sal sube 80 %, no 100 %; es lo que hacen las cocineras con experiencia.
• Fijo (una hoja de laurel, una tapa de olla): no cambia, salvo que f supere 3, donde se duplica.

Después del cálculo entra el redondeo de cocina: volúmenes a fracciones de taza y cucharada (¼, ⅓, ½, ⅔, ¾), masas a múltiplos de 5 g bajo 100 g y de 25 g arriba, piezas al entero superior. La cantidad exacta queda guardada; sólo la presentación se redondea. Tiempos de cocción no escalan; se muestra una nota cuando f ≥ 2.5 («usá dos ollas o alargá el tiempo»).

Redondeo a empaques

Una lista pide 900 g de harina, pero la tienda vende bolsas de 1 lb y de 2 kg. El motor elige, por tienda, la combinación de empaques que cubre la necesidad al menor costo, con desempate por menor sobrante. La pantalla muestra las tres cifras: necesitás, comprás, te sobra. El sobrante alimenta la despensa si el usuario lo acepta.

Sustitutos

Se ofrecen en dos momentos: cuando el ingrediente no está disponible en la tienda evaluada y cuando el sustituto de calidad 1 o 2 cuesta al menos 15 % menos. El sustituto entra con su ratio (1.0 para queso duro por queso seco; 1.25 para margarina por mantequilla en repostería) y su contexto, para que nunca se proponga crema en lugar de mantequilla al hornear.

Comparación por tienda

Para cada tienda de la ciudad se calcula:

• Total de los ítems con precio y disponibilidad conocidas, ya redondeados a empaque.
• Cobertura: ítems con dato entre el total de ítems.
• Faltantes: lista de lo que no tiene o no se conoce, con sustituto si existe.
• Total comparable: total más los faltantes valorados a precio de referencia público, marcado como estimado. Sólo así se pueden ordenar tiendas con cobertura distinta sin favorecer a la que tiene menos datos.
• Diferencia contra la tienda más barata, en lempiras y porcentaje, y frescura mínima de los precios usados.

Repartir entre tiendas

Con hasta cinco tiendas por ciudad, la búsqueda exhaustiva es trivial: se evalúan los 31 subconjuntos no vacíos, en cada uno cada ítem va a la tienda más barata del subconjunto, y al total se suma un costo fijo por tienda extra (viaje, o envío mínimo si es en línea) que el usuario configura y por defecto vale L 15 por tienda adicional. Gana el subconjunto de menor costo total. La recomendación de dividir sólo aparece si el ahorro neto contra la mejor tienda única supera L 25 o 5 % del total, lo que sea mayor. Cuando la lista supera 60 ítems, o el usuario permite más de cinco tiendas, se cambia a asignación voraz por ítem con el mismo costo fijo, que en la práctica da el mismo resultado.

// Núcleo del reparto (TypeScript, corre en el cliente)
function repartir(items: Item[], tiendas: Tienda[], costoExtra: number, maxTiendas = 5) {
  let mejor = { costo: Infinity, tiendas: [] as Tienda[], asign: new Map() };
  for (const sub of subconjuntos(tiendas, maxTiendas)) {
    const asign = new Map();
    let costo = costoExtra * (sub.length - 1);
    for (const it of items) {
      const opciones = sub.map(t => ({ t, c: costoEnTienda(it, t) })).filter(o => o.c !== null);
      if (opciones.length === 0) { costo += precioReferencia(it); continue; } // faltante estimado
      const min = opciones.reduce((a, b) => (b.c! < a.c! ? b : a));
      asign.set(it, min.t); costo += min.c!;
    }
    if (costo < mejor.costo) mejor = { costo, tiendas: sub, asign };
  }
  return mejor;
}

Flujos de UI

Cinco pantallas cargan con el trabajo real; el resto son detalles. Lenguaje directo en segundo persona del voseo hondureño («elegí», «agregá»), cifras siempre en lempiras con dos decimales, y ninguna acción de dinero escondida detrás de un ícono. Tema claro en blanco y tema oscuro en negro, con el acento sólo en botones primarios, ahorros y estado de frescura.

Recorridos principales

Offline y rendimiento para Honduras

Presupuestos

Estrategias del Service Worker

iOS y Android, distinto por diseño

Rendimiento en el dispositivo

• Consultas a IndexedDB por índice compuesto [ingredient_id+store_id]; la comparación de una lista de 30 ítems contra 5 tiendas se resuelve en menos de 50 ms en un Android de gama baja.
• Listas largas con virtualización sólo cuando superan 100 filas; antes no vale el peso.
• Nada de mapas embebidos: la ubicación de tiendas se muestra como lista con distancia y un enlace externo a Google Maps.
• Fuentes del sistema como respaldo real: si Google Fonts no responde en 3 s, el texto ya está en pantalla con la fuente local.

Seguridad y privacidad

• Mínimo dato personal. La cuenta es una clave de dispositivo; correo sólo si el usuario quiere respaldar listas. No se pide teléfono ni ubicación precisa; la ciudad se elige a mano.
• Honduras no tiene aún una ley general de protección de datos vigente, así que se diseña como si la tuviera: propósito declarado, borrado a pedido desde la app, retención de reportes de precio anonimizada a los 90 días.
• Las fotos de reportes se recortan del lado del cliente al bloque de precio y se borran del servidor una vez validado el reporte.
• API con límite de ritmo por dispositivo, paquetes firmados para que un CDN o un proxy no puedan alterar precios, y sin secretos en el cliente.
• Marcas de las cadenas: se usan sus nombres como texto, no sus logotipos, hasta tener permiso escrito.
• Los conectores no guardan cookies, no usan credenciales y registran cada corrida, para poder demostrar ante cualquier cadena exactamente qué se leyó y cuándo.

Fases y riesgos

Riesgos abiertos

• Que ninguna cadena responda. La app sigue siendo útil con referencia pública y reportes, pero la promesa de «comparar súpers» se cumple a medias. Mitigación: fase 1 y 2 no dependen de ellas.
• Emparejamiento ingrediente–producto. Es el trabajo más manual y el que más errores visibles produce («queso seco» emparejado con queso crema). Mitigación: revisión humana de los 400 productos más frecuentes y botón «esto no es lo que pedí» en cada línea.
• Precios en línea distintos a los de sucursal. Algunas cadenas cobran distinto en línea. Mitigación: el canal se muestra siempre («precio en línea») y los reportes de góndola se guardan como canal aparte.
• Desgaste de conectores. Los sitios cambian su HTML sin aviso. Mitigación: pruebas de contrato por conector, alerta cuando una corrida produce cero cambios o más de 5 % de errores, y precios marcados «por confirmar» automáticamente al vencer su vigencia.
• Evacuación de datos en iOS. Un usuario que no instala la app puede perder su lista. Mitigación: respaldo opcional por correo y aviso claro de instalar.