Una corrida diaria graba las respuestas públicas de cuatro catálogos, las reprocesa sin red para cruzar productos equivalentes y deja un único data.json. Publicarlo es un acto manual con comparación previa. El visitante recibe una página estática. Cuatro vistas: contenedores, flujos, despliegue y decisiones. Haz clic en cualquier caja; reproduce un flujo para ver el recorrido.
Cada caja es una pieza que corre por separado: la tarea programada, el orquestador, un catálogo externo, una carpeta de archivos o el navegador de quien visita. Las líneas son llamadas reales: protocolo y qué viaja.
Cada respuesta HTTP se guarda comprimida antes de que nadie la interprete. El procesado lee ese archivo, no el sitio: se puede depurar un cruce equivocado sin volver a pedir nada a las cadenas, y la misma corrida produce los mismos bytes en otra máquina.
La corrida solo escribe en una carpeta de staging. Lo que ve el público cambia cuando alguien ejecuta el publicador, lee el resumen y escribe la palabra de confirmación. Si desaparece más de una quinta parte de los productos, el publicador se niega.
Los precios son un archivo JSON y el navegador hace los cálculos. No hay API que mantener ni costo variable. La política de contenido solo permite recursos propios, así que la página no puede llamar a terceros.
La parte pública es solo archivos, así que se puede mover sin tocar código. La parte frágil es la tarea diaria: depende de que el PC esté encendido y con la sesión abierta.
Si el PC está apagado o la sesión cerrada a esa hora, ese día no hay corrida. No hay integración continua en el repo.
Qué gana: corridas que no dependen de una sesión abierta. Qué no cambia: la publicación seguiría siendo manual, por diseño.
| Decisión | Por qué | Descartado |
|---|---|---|
| Grabar el crudo y procesar siempre desde él | Depurar contra el archivo y no contra el sitio; la misma corrida da los mismos bytes en otra máquina. La prueba de reproceso lo verifica sin red | Parsear en vivo mientras se descarga: cualquier cambio del matcher obligaría a volver a pedir todo |
| Staging separado y publicación manual | La corrida nunca toca lo que ve el público. Alguien lee el resumen y confirma por escrito | Publicar al terminar cada corrida: una corrida rota llegaría al público sin que nadie la viera |
| Tope de desaparecidos del 20 % | Si de golpe falta una quinta parte del catálogo, casi seguro falló la captura, no el mercado | Publicar siempre; sin tope, un fallo de una cadena vacía la página |
| Validar antes de exportar | Un 401 o 403, o un snapshot sin filas de la cadena base, aborta sin pisar el histórico; si no, mañana todo saldría como nuevo y se perderían las flechas de cambio | Exportar lo que haya y marcarlo: el histórico quedaría contaminado |
| rclone copy, nunca sync | La copia en la nube es un archivo histórico: no debe borrar nada allí. Si falla, la copia de mañana sube lo que falte | Sincronizar en espejo: un error local se propagaría al archivo |
| Un falso positivo pesa más que un guion | Mostrar dos productos distintos como iguales es peor que no cruzarlos. Reglas duras, marca exigida en la zona gris y reparto uno a uno por fuerza de evidencia | Bajar el umbral de texto para cruzar más: más cobertura con cruces dudosos |
| Foto como tercera señal | Una huella de imagen confirma coincidencias dudosas y puede vetar un texto casi idéntico con foto claramente distinta | Decidir solo por texto: variantes de una misma línea se confunden |
| Web estática, cálculo en el cliente y CSP estricta | Cero costo variable y nada que mantener encendido. El script del tutorial pasó a un archivo propio para permitir la política sin excepciones | Una API propia o scripts en línea: una pieza más que vigilar y una CSP más débil |
| Solo datos públicos de catálogo | Pausas por dominio, reintentos con espera ante 429 y 503, sin sesión, sin carrito. La captura debe ser cortés con los sitios | Capturar más rápido o con sesión: más datos a cambio de riesgo para los sitios y para el proyecto |