Se incorporó una primera versión de la herramienta de repricing para tiendas habilitadas por admin. Desde “Mi Catálogo” ahora se puede recalcular masivamente el precio de las cartas tomando como referencia principal Card Kingdom y, cuando no exista match, Scryfall como respaldo; la conversión a CLP usa el dólar configurado por la tienda. El proceso corre por lotes, muestra progreso en pantalla y deja un reporte persistente al terminar con cartas evaluadas, actualizadas, omitidas, errores y variación neta del catálogo en CLP. Además, mientras el repricing está activo se bloquea la importación y edición manual del catálogo, el acceso a “Agregar cartas” queda deshabilitado, se advierte antes de cerrar la pestaña y la herramienta sólo puede volver a ejecutarse cada 12 horas para evitar saturación de consultas.

Se incorporó una nueva experiencia de Mazos dentro del marketplace. Los vendedores ahora pueden importar una lista tipo Moxfield como mazo, editar su nombre, descripción, formato, precio publicado y carta portada, y publicarlo con URL propia dentro de la tienda. En público, el mazo se muestra como una publicación independiente con ahorro frente al valor por separado, mejor presentación visual de portada y una ficha interna con grilla de cartas, filtros y agrupación por tipo. Además, el carrito, checkout, resúmenes y correos principales ahora tratan el mazo como una sola unidad visual, mientras internamente el stock sigue resguardado por carta para mantener compatibilidad con el flujo transaccional existente.

Se corrigió el flujo de contrapropuesta cuando el vendedor no tiene stock completo. Mientras la contrapropuesta está pendiente, el pedido original ya no se muestra como si siguiera esperando aprobación del vendedor, sino como una espera de respuesta del comprador. Cuando el comprador acepta, el pedido original pasa a estado 'Reemplazado por compra parcial', deja de ser operable y las listas muestran el correlativo del pedido nuevo directamente en el botón inactivo (por ejemplo, 'Reemplazado (0364)'). Además, la landing pública del correo ahora responde al estado real del ajuste: si ya fue aceptado, deja de mostrar un rechazo falso y permite continuar al pago. El mismo ajuste ahora también puede resolverse directamente desde el detalle de la compra, donde el comprador ve los cambios propuestos y puede aceptar o rechazar la contrapropuesta sin depender sólo del correo. En paralelo, mientras exista una contrapropuesta pendiente, el vendedor ya no puede volver a rechazar o reajustar manualmente ese pedido desde el panel, y los mensajes del detalle dejan de sugerir erróneamente que todavía se está esperando una aprobación normal del vendedor.

Se incorporó un primer aviso simple de cookies en el frontend público, con aceptación persistente y enlace directo a la Política de privacidad, usando un diseño visual alineado al lenguaje de Scry. Además, se ajustó el buscador principal en mobile para mejorar la experiencia en iPhone: el campo ahora evita el zoom automático no deseado de Safari, se eliminó el botón lateral redundante de búsqueda y la navegación quedó enfocada en seleccionar sugerencias del autocomplete en lugar de dispararse con Enter.

Las antiguas “colecciones” ahora son “carpetas”: una forma de categorizar cartas sin moverlas de tu stock (una carta puede estar en varias carpetas). En la vista pública de la tienda se muestran como cards con imagen de portada, contador y símbolos de maná; y cada carpeta tiene una URL compartible del tipo `/{tienda}/carpeta/{slug}` donde los filtros operan sólo sobre el contenido de esa carpeta. En el catálogo del vendedor, al seleccionar cartas aparece “Agregar a carpeta”: un modal permite elegir carpetas y crear una nueva ahí mismo. Además, tras agregar cartas, el conteo de cada carpeta se actualiza inmediatamente en el sidebar.

Se ajustó el flujo de pedidos para que la entrega en persona deje una trazabilidad explícita del vendedor antes de mostrar el código al comprador. Desde ahora, el vendedor debe marcar el pedido como “listo para entrega en persona” y recién ahí comienza a correr el plazo automático. Además, cuando existe respaldo válido de entrega presencial o retiro en tienda y el comprador no retira dentro del plazo, el cierre automático deja de caer injustamente como “vendedor no envió” y pasa a resolverse a favor del vendedor.

Se ajustó la política de cookies de sesión para que los entornos HTTPS emitan `ci_session` con `Secure` y `SameSite=None`, evitando que el comprador pierda la sesión al regresar desde Flow después de pagar. Con esto, el retorno post-pago vuelve logueado correctamente en QA y queda alineado para producción, mientras localhost mantiene el comportamiento compatible con HTTP para desarrollo.

Se mejoró el resumen interno del detalle de ventas para vendedores: las imágenes de las cartas ahora se muestran más grandes, se pueden abrir en lightbox al hacer click y, cuando existe metadata localizada en cache local de Scryfall, se muestra también el nombre impreso de la carta bajo el nombre principal (por ejemplo, en español). Además, cada ítem del pedido incorpora un checkbox “La tengo” para que el vendedor pueda ir marcando visualmente las cartas encontradas; este estado se guarda localmente en su navegador por pedido y no altera la lógica transaccional del marketplace.

Se rediseñó la vista interna de /catalogo para vendedores, dándole mucho más protagonismo al inventario y menos peso visual al bloque de colecciones. El catálogo ahora incorpora un toolbar compacto con búsqueda, sets reales del catálogo, tipo de carta, acabado, color, rareza, condición, cantidad visible y rápidos de orden por nombre, precio y stock, todo conectado al flujo AJAX existente de Admin::carta_filtrar. Además, el contador total del catálogo se actualiza con cada filtro, las filas muestran metadata útil por carta (set, rareza, condición y foil/no foil) y la tarjeta lateral de colecciones fue reducida y compactada para quedar en un rol secundario sin perder su funcionalidad.

Se refinó la vista pública de filtrado de cartas para acercarla al lenguaje visual de los filtros de tienda y hacerla más práctica al explorar stock real. El panel fue reorganizado en una barra más compacta con controles principales arriba (edición, condición, acabado y precio), chips para color/identidad, rareza y tipo de carta, resumen visual de filtros activos y acciones explícitas para buscar o limpiar. Además, se normalizaron labels al español y se incorporó soporte público para Condición y Acabado (Foil / No foil), permitiendo búsquedas más precisas desde /filtros sin cambiar la semántica de los parámetros GET existentes.

Se rediseñó el toolbar de filtros dentro de las páginas de tienda para separar correctamente dos conceptos que antes estaban mezclados: las colecciones internas del vendedor y los sets reales de Magic disponibles en su catálogo. Desde ahora la barra permite combinar Colecciones, Sets, Tipo de carta, Acabado, Color, Rareza y cantidad visible por página, manteniendo además los rápidos de orden y condición. También se sincronizó el estado de los filtros con la URL, de modo que cada tienda pueda compartir vistas filtradas concretas mediante enlaces directos. Como parte del mismo ajuste se compactó visualmente el bloque para desktop/mobile y se ocultó el banner placeholder superior de tienda y single de carta.

Se corrigió un problema de metadata que podía dejar cartas claramente coloreadas clasificadas como incoloras dentro de algunas tiendas, especialmente después de importaciones por lista. El trabajo incluyó reforzar la importación vía Moxfield para guardar correctamente `colors`, `color_identity` y `type_line`, además de ejecutar una reparación progresiva de registros históricos en QA y producción usando Scryfall como fuente canónica. También se ajustó la semántica del filtro “Incolora” para que represente el color real de la carta (`colors`) y no exija identidad vacía, permitiendo clasificar correctamente cartas incoloras con identidad de color como Herigast o Territory Culler. Con esto el filtro dejó de arrastrar falsos positivos evidentes y el catálogo quedó mucho más consistente sin reactivar productos eliminados.

El Deck Builder sumó una nueva entrada opcional para pegar URLs compartidas de ManaBox: al cargar el link, la lista se convierte automáticamente en texto editable, se vuelca al textarea y se ejecuta la búsqueda al instante. Además, la vista de resultados ahora viene agrupada por tienda por defecto y los bloques de tienda fueron compactados para mostrar mejor señales de confianza y contexto comercial, incluyendo reputación, verificación, cobertura y ubicación disponible de cada vendedor.

Se amplió el flujo compartido del Deck Builder para vendedores. Ahora, además del link general de una búsqueda, cada tienda puede generar su propia vista enfocada con solo las cartas que sí tiene disponibles, eliminando distracciones y dejando el CTA principal centrado en agregar esas coincidencias al carro. Sobre esa misma vista, el vendedor también puede crear un link temporal con descuento para la selección de cartas de su tienda, definiendo tipo de rebaja y vigencia. Cuando el comprador entra por ese enlace, ve la oferta aplicada directamente en la landing y, si agrega las cartas al carrito, el precio promocional queda congelado durante una ventana corta para que pueda completar el checkout sin perder la condición ofrecida.

Se amplió el Deck Builder para que, al buscar una lista, se genere automáticamente un enlace temporal compartible con vigencia de 72 horas. Quien abra ese link vuelve a cargar la misma lista y ve la misma búsqueda sin tener que pegar el texto nuevamente. Además, cuando un vendedor está logueado, ahora aparece una pestaña contextual con las cartas de su propia tienda que coinciden con la lista buscada, incluyendo opción de agregar cartas individualmente o sumar todo lo disponible al carrito. Ese mismo contexto de tienda también puede compartirse con un enlace dedicado, de modo que el comprador abra directamente la vista de esa tienda sobre la lista consultada.

Se corrigió un problema que podía dejar bloqueada toda la cola de importaciones SM cuando un lote anterior fallaba durante el procesamiento. En este caso, imports más nuevos como el 424 (Manabox) quedaban en PENDIENTE sin haber comenzado realmente, porque el runner siempre intentaba primero los lotes más antiguos. Durante la revisión se detectó además una fragilidad en el procesamiento de cartas resueltas desde Scryfall: algunos registros podían venir sin `type_line`, lo que terminaba generando un `NULL` en `mps_cartas.tx_type_line` y provocando una caída completa del proceso. El ajuste contempla robustecer `proc_sm()` para no exigir `api_k` cuando se ejecuta por CLI, alinear correctamente el wrapper `cli_sm run` con el procesador real, y agregar fallback seguro para `type_line` (incluyendo `card_faces` cuando aplica), evitando que un registro incompleto vuelva a botar todo el lote. Como resultado, la cola pudo destrabarse, los imports posteriores volvieron a avanzar por tandas y el import de Manabox 424 retomó procesamiento normal.

Se reemplazó la maqueta temporal del bloque de vendedores destacados del home por un ranking real alimentado desde la base de datos de QA. La portada ahora muestra 8 vendedores en formato 4x2, priorizando la reputación real de compradores, complementada por ventas finalizadas y catálogo con stock activo. Para evitar rankings engañosos, la reputación se pondera por volumen de calificaciones, de modo que una sola reseña perfecta no supere a tiendas con mejor trayectoria comprobada. También se agregó al bloque la cantidad de calificaciones recibidas por cada tienda, se eliminó el fallback mock de desarrollo y se normalizaron las URLs de imágenes para que funcionen correctamente tanto en QA como en producción.

Se incorporó un nuevo canal opcional de notificación por WhatsApp para la wishlist. Desde ahora, cada usuario puede guardar su número en formato internacional y activar o desactivar las alertas desde la misma página de Wishlist, manteniendo el correo electrónico como canal base. La implementación contempla normalización del número, prerrelleno automático cuando el usuario ya tiene un teléfono asociado y una presentación más clara del sistema de notificaciones tanto para usuarios logueados como no logueados. El aviso por WhatsApp se envía únicamente cuando una carta de la wishlist pasa efectivamente de sin stock a con stock, evitando mensajes repetidos mientras la carta siga disponible. Además, se integró el envío mediante Twilio con template aprobado para WhatsApp y se ajustó la lógica de origen de las cartas agregadas desde el buscador para que también queden cubiertas por este nuevo canal.

Se agregó en el panel de detalle de tienda una nueva acción administrativa para eliminar una tienda por infracción, junto con sus cartas y relaciones operativas directas, mediante un flujo controlado y transaccional. La implementación incorpora validación de acceso solo para administradores, ejecución exclusiva por POST, confirmación previa en interfaz y bloqueo de eliminación total cuando la tienda tiene historial transaccional relevante, evitando romper trazabilidad o consistencia de datos. Además, se creó una tabla de soporte para bloquear permanentemente el correo asociado, impidiendo que el usuario vuelva a registrarse o iniciar sesión, incluyendo acceso con Google. También se integró el envío de un correo de notificación al usuario afectado y se actualizó la página de Términos y Condiciones para incluir expresamente la prohibición de nombres, slugs, descripciones o contenidos vulgares, ofensivos, sexualmente explícitos, discriminatorios, engañosos o inapropiados. Posteriormente, se ajustó la redacción del correo para dejar el motivo en términos genéricos, indicando únicamente que se detectó una infracción a los Términos y Condiciones, sin exponer una tipología específica de faltas.

Se incorporó un nuevo flujo post-pago para reducir la incertidumbre del comprador apenas se confirma el pago. Cada tienda ahora puede configurar un mensaje automático post-pago dentro de Configuración > Entregas, con límite de 300 caracteres, contador visible y sanitización backend para evitar emojis, tags HTML y caracteres problemáticos en base de datos. Al confirmarse el pago, Scry envía un nuevo correo al comprador indicando que el pago fue confirmado, que ya puede coordinar la entrega o el envío y que existe un canal activo asociado al pedido. Si la tienda configuró mensaje, ese mismo texto se muestra también en el correo dentro de un bloque destacado y se publica automáticamente en el chat del pedido; si la tienda no configuró mensaje, no se publica nada en el chat. Además, se eliminó el fallback genérico de Scry dentro del chat para que allí aparezca únicamente la voz de la tienda, y se agregó un alert contextual en la vista de ventas del vendedor cuando aún no tiene configurado su mensaje automático post-pago. También se ajustó la UI de Entregas para ordenar mejor el bloque nuevo y separar correctamente el botón Guardar entregas del textarea del mensaje.

Se integró un bloque visual de seguimiento de compra en los correos transaccionales del comprador, unificando el flujo en 4 pasos: Reserva, Aprobación y pago, Envío del vendedor, y Finalizar y dejar feedback. El componente fue adaptado para HTML email con foco en compatibilidad mobile, corrigiendo problemas de renderizado como círculos oblongados, labels montados y bordes innecesarios. Se aplicó en las plantillas de reserva, reserva aprobada, comprobante cargado, retiro en tienda despachado, compra finalizada del comprador y retiro exitoso en tienda. Además, se ajustaron los estados activos/completados según cada instancia del flujo y se reforzó sanitización básica en algunas plantillas para evitar errores de renderizado.

Se corrigió el flujo de pagos con Flow para que los intentos terminales no queden mal persistidos como pendientes en mps_pedido_pago. El retorno/validación del pago ahora prioriza el token de Flow y consulta el estado real del intento con información extendida; si Flow devuelve status 3 (rechazada) o 4 (anulada), el intento se cierra correctamente en base de datos y el pedido permanece disponible para generar un nuevo intento de pago sin rehacer la compra. Además, la actualización de pagos deja de hacerse de forma amplia por id_pedido y pasa a resolverse por intento específico, evitando inconsistencias cuando existen múltiples reintentos sobre un mismo pedido. También se robusteció la obtención del último pago para tomar siempre el intento más reciente y se evita bloquear al comprador con links ya muertos o no pagables.

Se corrigió el problema intermitente del login por correo y contraseña que devolvía 403 Forbidden / 'The action you have requested is not allowed' cuando el token CSRF del modal quedaba vencido o desalineado respecto de la cookie. Se agregó un endpoint liviano para refrescar CSRF, se expuso la configuración CSRF real al modal y el flujo JS ahora sincroniza el token antes de enviar credenciales. Si aun así el POST encuentra un 403 por CSRF, el frontend refresca el token y reintenta automáticamente una vez, evitando que el usuario vea el error genérico de 'Error de red o respuesta inválida del servidor'. El mismo enfoque quedó aplicado también al flujo de recuperación de contraseña para mantener consistencia.

Se revisaron manualmente en producción los pedidos mpsc-0326 y mpsc-0345, ambos asociados a intentos de pago Flow que habían sido creados correctamente pero terminaban en status 3 con lastError -6 ('Rechazo general'). Como el sistema aún dejaba esos intentos en estado pendiente, se cerraron manualmente en mps_pedido_pago como anulada/rechazada según correspondía, permitiendo regenerar nuevos links de pago sin recrear el pedido completo. La revisión confirmó que el problema original provenía del rechazo terminal de Flow sobre esos intentos y no de una falla general de la tienda Bowito ni de la creación de órdenes.

Se implementó un flujo de autorespuesta para mensajes entrantes en el canal de WhatsApp de Twilio. Cuando un usuario responde al bot, Marketplace Scry devuelve una respuesta automática que indica que el canal es automatizado y redirige a atención humana mediante un enlace wa.me con mensaje precargado. La respuesta se limita por remitente usando un TTL configurable para evitar spam repetido. Se agregó un endpoint dedicado para inbound, validación de firma de Twilio y exclusión CSRF puntual para el webhook. La funcionalidad fue validada en QA con Twilio WhatsApp Sandbox y quedó lista para activarse en producción apuntando el sender real a /twilio/whatsapp-inbound.

Se aplicó una ronda amplia de optimizaciones de rendimiento en Marketplace Scry enfocada en reducir TTFB, peso transferido y costo de render inicial del home. Se agregó cache del home para visitantes anónimos, se redujo la cantidad de vitrinas/cartas renderizadas en portada, y se limitó la carga anticipada de fondos de sets. Además, las imágenes de cartas del home ahora priorizan tamaños pequeños, usan lazy loading/async decoding y se sirven por same-origin reutilizando el proxy Img::scryfall con cache local, ETag, Last-Modified y respuestas 304. También se recortó la carga global de assets: DataTables quedó acotado a vistas donde realmente se usa, se eliminó carga duplicada de Popper, se reemplazó la dependencia externa de jquery-cookie por compatibilidad inline, GSAP salió del layout global con fallback vanilla JS, y socket/login dejaron de cargarse de entrada para público anónimo. Finalmente, se reforzó caché/compresión de archivos estáticos a nivel HTTP para CSS, JS, imágenes, fuentes y SVG.

Se corrigió el flujo de edición en /catalogo (vista admin “Mis Cartas”) que estaba fallando con 303 y no cargaba el modal. El botón “Editar” ahora apunta a la ruta pública correcta (/cargar_modal_edit) en lugar de /admin/carta_edit, evitando redirecciones del servidor y permitiendo que el editor se cargue vía AJAX de forma consistente. Se mantuvo el envío de cadena (hash) y headers XHR para preservar el comportamiento original del modal.

Se corrigió el catálogo interno en /catalogo (vista admin “Mis Cartas”) para que el buscador por nombre funcione sobre el total del catálogo y no sólo sobre la página visible. Se aisló la vista de colisiones con scripts globales renombrando IDs/handlers y se implementó búsqueda/paginación/‘mostrar N’ en modo server-side vía Admin::carta_filtrar (AJAX con X-Requested-With), garantizando que el botón “Editar” permanezca siempre en la 2da columna (después del checkbox) incluso tras interacciones. Además, se restauró el correcto funcionamiento de “Eliminar seleccionadas” durante búsquedas/filtros y se ocultó la paginación cuando no existe más de una página (ej. 33 cartas con vista 100).

Se ajustó el hero del home para mejorar jerarquía visual (CTA principal más grande), se implementó un bloque de testimonios tipo 'pills' con selección aleatoria server-side (10 posibles, se muestran 3 por carga), y se añadió una sección dedicada a POS para tiendas. Además, se incorporó una franja 'Partners' en el footer con logos en horizontal (180x60). Finalmente, se añadió al FAQ una entrada de '¿Cuánto cobramos de comisión?' con tablas de ejemplo para vendedor y comprador (incluye comisión/IVA y total por $10.000).

Se agregó un flujo de Ventas Presencial (POS) para que el vendedor pueda marcar cartas del catálogo como vendidas fuera de Scry, descontando stock y registrando la venta sin generar comisión ni entrar al flujo de pedidos. En “Mis ventas” se incorporaron dos pestañas (Pedidos online y Presencial (POS)), con acciones de ver/anular (anular reintegra stock y marca el registro como anulada). Además, se implementó exportación CSV por pestaña y un export consolidado que unifica pedidos online + ventas POS en un solo archivo. Se corrigieron rutas para evitar que la regla ventas/(:any) intercepte endpoints POS y exports.

Se integró el feed de precios de Card Kingdom (affiliate) como referencia principal en USD: ahora las páginas de carta muestran “Referencia Card Kingdom” (precio + stock) con link directo al producto y tracking partner=scrycl. Se creó cache local en BD con tablas mps_ck_item y mps_ck_item_market (mapeo por scryfall_id + is_foil) y se programó actualización automática en producción cada 6 horas (log en _tools/ck_import_prod.log). En el backoffice, la carga individual y la importación por lista priorizan CK para el precio sugerido; si no existe match, se usa Scryfall como fallback. La conversión a CLP usa el dólar configurado por la tienda y redondea siempre hacia arriba (ceil). Además, se corrigieron detalles de UX/técnicos: NM por defecto, el precio sugerido no depende de la condición, fix de CSRF en AJAX y normalización de collector_number para matchear el printing correcto.

Se corrigieron inconsistencias de cálculo/visualización entre BD, pricing y correos. Ahora los montos se muestran siempre sobre el subtotal de productos (mps_pedido.total_compra) y el neto del vendedor se calcula como total_compra − (comision − iva). Se ajustó el listado de ventas para mostrar “Recibes” correctamente. Además, el correo de notificación de pago ahora considera descuentos por cargos pendientes de reembolsos Flow (FIFO), mostrando el monto neto a depositar y el desglose de descuento/monto bruto; y si aplica, se agrega la línea de descuento también en el detalle del pedido.

Se reforzó el flujo de verificación de identidad de tiendas: los documentos ya no se exponen por rutas públicas, se guardan en un storage privado fuera del webroot y se sirven únicamente mediante endpoints autenticados. Se mejoró la validación de archivos (formatos/tamaño y verificación real de imagen), y se corrigió la entrega de headers para que los previews se rendericen correctamente. Además, al aprobar o rechazar una verificación, los documentos se eliminan automáticamente (retención mínima) y la UI del vendedor oculta el formulario de subida cuando la cuenta ya está verificada. Se ajustó la carga de foto de perfil de tienda para que use un storage público independiente y no se mezcle con la carpeta de verificación.

Se corrigió un caso donde los pedidos generados por el flujo de Propuesta de compra parcial (aceptación desde correo y pago vía Flow) se creaban sin conversación asociada, lo que impedía persistir mensajes en el chat. Ahora, al crear el pedido reformado, el sistema asegura la creación de la conversación (mps_conversacion) y el registro de integrantes (mps_usuarios_conversacion), habilitando el chat de forma consistente.

Si al vendedor le falta stock de uno o más ítems, ahora puede proponer una compra parcial desde el detalle de la venta. Se abre un modal para ajustar cantidades (incluye quitar ítems con cantidad 0) y el sistema notifica al comprador por correo con el resumen de cambios y nuevos totales. El comprador puede Aceptar y pagar o Rechazar directamente desde el correo.

Al aceptar una propuesta de compra parcial, el sistema crea un nuevo pedido (pedido reformado), recalcula totales y comisiones, y redirige directamente al checkout de Flow. El pedido original queda marcado como 'Reemplazado por compra parcial' para evitar doble pago y mantener trazabilidad.

Se agregaron los estados 'Rechazada por comprador' y 'Reemplazado por compra parcial' en listas y detalles de compras/ventas, evitando warnings y mostrando badges correctos en UI.

El correo de propuesta y las páginas de aceptar/rechazar fueron rediseñados para usar el look&feel del marketplace (logo, tipografía y layout), evitando pantallas off-brand.

Se mejoró la navegación del header: (1) se agregó estado activo en la barra superior para resaltar la sección actual (Home, /buscar, /deckbuilder, /wishlist, /tiendas, etc.) con estilo visible en fondo oscuro; (2) en mobile se corrigió el comportamiento del texto “Menú” (ya no enlaza a Home) y se rediseñó el trigger como un botón ancho completo, más compacto (16px), con “Menú” a la izquierda y el ícono hamburguesa a la derecha. Se mantiene el header sticky sin cambios estructurales adicionales.

Se implementó un carrito tipo sidebar que se abre desde el lado derecho sin salir de la página (ideal para Deck Builder). El panel permite ver ítems, eliminar cartas individualmente, vaciar el carrito completo y acceder a /checkout (botón deshabilitado si el carrito está vacío).

Se incorporó la página /deckbuilder para pegar una lista (formato Cantidad + Nombre, una carta por línea) y consultar disponibilidad. El endpoint de preview devuelve Disponibles / Sin stock / No encontradas, ordenando listings por precio ascendente y desempate por stock.

Se corrigió el query que intentaba leer t.tx_slug (columna inexistente) y se ajustó al slug real de la tienda (tx_nombre_slug), eliminando el 500 al consultar disponibilidad.

Se corrigió el error 'Illegal mix of collations' en el filtro por nombre de carta aplicando normalización/collation consistente en la comparación, evitando fallas en QA y local al ejecutar IN(...) con nombres de carta.

Se definió un índice compuesto para acelerar consultas del Deck Builder y búsquedas por nombre (tx_nombre_carta + estado + stock + precio). Como tx_nombre_carta es TEXT, el índice se crea con prefijo (191) para compatibilidad.

Se creó la página /buscar como punto dedicado para explorar el catálogo con filtros equivalentes al Home, manteniendo el mismo flujo de resultados.

Se ajustó la pestaña Filtrar en /buscar para que quede consistente con el Home (colores/opciones) y se dejó Filtrar como tab principal por defecto.

Se corrigió el dropdown de búsqueda por Commander/sinergia para que vuelva a funcionar en la vista /buscar.

Se mejoró el listado de tiendas para priorizar tiendas verificadas y permitir ordenamiento desde el header de la tabla, manteniendo un criterio consistente de desempate.

Se mejoró la página “Todas las tiendas” para priorizar tiendas verificadas y permitir ordenarlas desde el header. Ahora existe una columna “Verificada” (badge Sí/No) que habilita ordenar por verificadas; el criterio aplicado es Verificadas primero (DESC) y, como desempate, nombre alfabético (A→Z). Además, el orden por defecto del listado queda estable (verificadas primero y orden consistente dentro de grupos), manteniendo compatibilidad con DataTables y sin cambios de base de datos.

Se implementó Wishlist como evolución del sistema de Alerta de stock: ahora puedes guardar múltiples cartas y recibir correos cada vez que vuelvan a tener stock (0→1+). Se añadió la nueva página /wishlist con buscador por nombre exacto, listado de cartas guardadas (con estado Sin stock / Disponible ahora) y opción de quitar cartas para desuscribirse. El enlace del buscador “¿No encuentras tu carta?” ahora dirige a Wishlist. Además, en el detalle de cartas sin stock se incorporó un CTA para agregar a Wishlist (si no hay sesión abre el modal de login), y cuando una carta ya está guardada se muestra el estado “En wishlist”. En Wishlist, las cartas disponibles ahora linkean directamente al listing correspondiente.

Se habilitó la cancelación de ventas por parte del vendedor cuando el comprador ya pagó (estado “Esperando envío”). Al confirmar, el pedido pasa a “Vendedor no envió”, se crea el reembolso pendiente para el comprador y se envía un correo notificando el reembolso (incluye recordatorio de revisar datos bancarios en Configuración → Pagos).

Se corrigió la carga de la tabla en “Mis ventas” (DataTables/IDs y endpoint), se aseguró el orden por defecto de más reciente a más antiguo, se estabilizó el ruteo para evitar colisiones con el wildcard de detalle y se ajustó el detalle de compra para mostrar el botón de feedback cuando corresponde (incluyendo casos con reembolso por “Vendedor no envió”).

En el listado de Mis compras, la columna ID ahora muestra el código real del pedido (mpscry-XXXX) en lugar de un correlativo. Además, el nombre de la tienda del vendedor es clickeable y abre la tienda en una nueva pestaña para facilitar navegación y confianza (Agradecimientos Jaime Sierralta).

Se corrigió el orden por fecha en Mis compras para que el pedido más reciente aparezca primero. El problema ocurría porque la fecha formateada dd/mm/YYYY se ordenaba como texto en server-side. Ahora se usa un campo de fecha raw para ordenar correctamente sin afectar el formato visible.

En el detalle de la compra, el nombre de la tienda del vendedor ahora es un enlace que abre la tienda en una nueva pestaña, manteniendo consistencia con el listado y mejorando el acceso rápido al perfil del vendedor.

Al confirmar un pago de venta, el sistema ahora compensa automáticamente los cargos pendientes por tarifa de reembolso de Flow, aplicando criterio FIFO (se descuenta primero del pago más antiguo). Esto asegura que la deuda por reembolsos baje correctamente a 0 cuando corresponde y que el neto a transferir se calcule de forma consistente.

Se corrigió el selector de Región para Chile, incorporando las regiones faltantes (Arica y Parinacota, Los Ríos y Ñuble). Además, el endpoint de Select2 aumentó el límite de resultados para evitar recortes y las regiones ahora se ordenan alfabéticamente para una mejor selección.

Se mejoró la comunicación del cargo asociado a reembolsos (tarifa Flow) en el panel de ventas: el usuario puede ver el monto pendiente y entender que se compensa automáticamente con el próximo pago a recibir (FIFO).

El correo que recibe el vendedor al procesarse un depósito ahora incluye el detalle del descuento por tarifa de reembolso de Flow solo cuando el pago corresponde al FIFO que compensa la deuda. Los pagos posteriores (sin compensación) mantienen el formato normal.

Cuando una búsqueda no tiene resultados (o no es la carta exacta que buscas), ahora puedes activar una alerta de stock: seleccionas el nombre exacto de la carta, ingresas tu correo y confirmas vía email (double opt-in). Al confirmarlo, tu contacto se agrega automáticamente a la lista “Stock alerts” en Brevo (ID 10) y te notificaremos cuando vuelva a haber stock de esa carta.

Se ajustó la tabla de comisiones del registro eliminando la columna “Comisión base” (no aplica). El badge de “cartas indexadas” en registro ahora usa el mismo contador en vivo del home y el cálculo llega correctamente a la vista. Además, la tabla de comisiones para comprador dejó de mostrar decimales.

Los beneficios del registro dejaron de mostrarse como lista y pasaron a cards/cajas responsivas para mejorar lectura. Se optimizó el layout para desktop y mobile y se actualizó el copy eliminando el punto de “Próximamente”.

Se crearon páginas dedicadas de Acerca de, Política de privacidad y Términos y condiciones (Comercializadora Scry SpA, RUT 77.802.091-2), necesarias para validaciones de OAuth. Se reformó el footer para enlazarlas directamente (sin modal).

Los vendedores ahora pueden pausar temporalmente las ventas de su tienda: las cartas siguen visibles, pero el botón “Agregar al carro” queda deshabilitado y el backend bloquea intentos de agregar al carrito. La pausa puede ser indefinida o con reanudación automática usando fecha y hora.

La reanudación automática se simplificó a día + hora (sin minutos), se evita seleccionar fechas pasadas y se agregó feedback post-guardado indicando el estado de la suspensión (activa/activa hasta X/ventas activas).

Se corrigió el guardado de la suspensión desde la sección “Cuenta” para que no dispare validaciones de “Mi tienda” ni redireccione incorrectamente. Además, se robusteció el manejo de slug para evitar errores cuando el texto viene nulo.

Ahora puedes agregar cartas al carrito sin iniciar sesión (se guarda en sesión y el badge se actualiza). En checkout se solicita iniciar sesión para reservar y se abre el modal de login sin redirigir al registro. Se incorporó “Continuar con Google” en login y registro; al iniciar sesión se respeta la redirección de retorno (checkout/carrito) y se hace merge del carrito invitado con el carrito del usuario. Además, se reforzó seguridad validando email verificado en Google, sanitizando el parámetro de retorno para evitar redirecciones externas y bloqueando el acceso desde navegadores embebidos de Messenger o Facebook, con aviso para abrir el Marketplace de Scry en un navegador compatible.

Se agregó un bloque informativo que indica el día de pago (martes), muestra el monto pendiente por depositar (ventas finalizadas pendientes de pago) y recuerda mantener los datos de pago actualizados para evitar retrasos.

El buscador global ahora muestra mensajes de estado: “Sigue escribiendo…” cuando hay 1–2 caracteres y “Buscando…” mientras se cargan coincidencias (3+ caracteres), reemplazándose automáticamente por los resultados al llegar.

Si el vendedor sube el comprobante de envío y el comprador no confirma la recepción, el pedido se marca automáticamente como recibido conforme tras 10 días para permitir el procesamiento del pago.

Ahora puedes ver el historial de mejoras del Marketplace (fixes, features y optimizaciones).