PRESS2PIXEL
Docs de producto

Documentación

press2pixel convierte una web útil en activos de redes sociales listos para campaña. Esta página documenta la app real detrás de la landing: crawler, extracción de marca, agrupación con IA, renderizado de plantillas, exportación, persistencia y despliegue.

Reservar demo Abrir la app
Inicio

Quick start

Arranca la app, pega una URL y deja que el servidor construya un workspace reutilizable para el cliente. El primer crawl crea filas de base de datos, contexto de identidad corporativa, campañas y previews reales.

  • Instala dependencias con npm install y arranca el servidor Express con npm start.
  • Abre http://localhost:3000 o el host del reverse proxy configurado.
  • Pega un dominio. press2pixel resuelve redirecciones, extrae señales de marca, crawlea contenido, agrupa campañas y guarda el resultado.
  • Al refrescar se conservan cliente, plantillas elegidas, captions y ajustes de diseño mediante SQLite y localStorage.
npm install
npm start
# abrir http://localhost:3000
La aplicación vive en app.press2pixel.fun. La landing se sirve aparte en press2pixel.fun, por eso todos los assets de landing se copian a landing/dist.
Salida

Qué construye la app

El producto es un generador masivo de activos para redes sociales. Convierte posts, páginas, productos, eventos, listings y otros contenidos estructurados en sets visuales con marca y captions alineados.

  • Gráficos PNG listos para campaña en ratios sociales prácticos.
  • Captions IA lazy para Twitter/X, Instagram y LinkedIn, guardados por fila de contenido.
  • Exportaciones ZIP y playlists fullscreen para signage.
  • Plantillas universales y firmas bloqueadas por cliente que solo aparecen para hosts compatibles.
La app actual contiene 101 plantillas activas: 36 estilos universales y 65 firmas de marca bloqueadas por cliente.
Crawler

Pipeline de ingesta web

El crawling ocurre en el servidor para que el navegador sea solo presentacional y evite problemas CORS. El crawler intenta primero fuentes estructuradas y luego completa con extracción guiada por sitemap.

  • resolveCanonical sigue redirecciones http/https y normaliza el host del cliente.
  • extractCI recoge logo, color de marca, tipografías, idioma, imagen hero, perfiles sociales y señales de contacto.
  • WordPress REST y Shopify JSON se leen cuando están disponibles.
  • sitemap.xml, entradas Sitemap de robots, llms.txt, JSON-LD, Open Graph y HTML SPA renderizado completan las lagunas.
  • Los candidatos de imagen se puntúan para priorizar hero, cover e imágenes relacionadas con la página frente a iconos, thumbnails y logos genéricos.
POST /api/crawl/:customerUrl
  -> resolveCanonical()
  -> extractCI()
  -> wpScrape() / shopifyScrape()
  -> discoverUrls()
  -> extractFromPage()
  -> groupItems()
  -> persist
Las páginas pesadas en JavaScript pueden renderizarse con Playwright cuando el HTML estático parece una shell de hidratación vacía.
Backend

Superficie API

El frontend habla con una API Express compacta. Rutas de clientes, contenido, campañas, sync, auth, captions, estado de proveedores y config salen de la app Node.

  • POST /api/crawl/:customerUrl ejecuta el pipeline completo de sincronización.
  • GET /api/customers, /api/content/:customerUrl y /api/campaigns/:customerUrl hidratan el workspace.
  • POST /api/captions/generate escribe JSON de captions generados de vuelta en content.captions.
  • GET /api/events emite actualizaciones de sync con Server-Sent Events.
  • Las rutas auth están disponibles cuando AUTH_ENABLED es true.
GET  /api/customers
POST /api/crawl/:customerUrl
GET  /api/content/:customerUrl
GET  /api/campaigns/:customerUrl
POST /api/captions/generate
GET  /api/events
Datos

Modelo de contenido y almacenamiento

Cada item descubierto se normaliza antes de llegar a la UI. Una clave estable id_unique deduplica contenido entre sincronizaciones, mientras raw_json mantiene detalle suficiente para reparar medios y diagnosticar.

  • customers guarda URL, nombre visible, JSON de identidad corporativa, preset JSON, owner y último sync.
  • content guarda title, excerpt, imageUrl, date, type, source_url, raw_json, campaign_id y captions.
  • campaigns guarda grupos por cliente generados por IA o heurística.
  • crawl_cache mantiene páginas cacheadas con TTL de seis horas.
  • sync_log registra inicio, fin, estado, recuentos de items y errores.
content {
  id_unique,
  customer_url,
  type,
  title,
  excerpt,
  imageUrl,
  source_url,
  campaign_id,
  captions
}
IA

Routing IA, agrupación y captions

La IA corre mediante Ollama local o proveedores de línea de comandos, no con llamadas directas desde el navegador. Cada tarea tiene su cadena de proveedores, modelos, fallback y procedencia.

  • La agrupación de campañas es local-first con Ollama, con fallback determinista por taxonomía.
  • La generación de captions usa una ruta de servidor, guarda metadatos de proveedor/modelo y reutiliza captions guardados al exportar.
  • La generación de plantillas y visión puede usar Gemini, Claude, Codex, MLX u Ollama según la cadena configurada.
  • El estado de rate limit y el uso de tokens se registran para saltar proveedores temporalmente no disponibles.
CAPTION_PROVIDERS=claude,gemini
GROUPING_PROVIDERS=ollama,gemini,claude
OLLAMA_URL=http://localhost:11434
OLLAMA_MODEL=gemma4:26b
Las captions se generan en el mismo idioma del item fuente cuando el modelo puede inferirlo.
Renderer

Plantillas y controles de diseño

Las plantillas son archivos JSON renderizados por el frontend. La app separa markup de plantillas y lógica de aplicación, con un contrato estricto de tokens raíz para que cada diseño responda a los mismos controles.

  • Las nuevas plantillas viven en assets/json/templates y se activan mediante index.json.
  • Las variables cubren título, excerpt, imagen, colores de marca, tipografía, espaciado, sombras, superficies y comportamiento por ratio.
  • Los tamaños usan unidades em para que sliders separados de titular y texto escalen de forma fiable.
  • Image fit y posición se enlazan con object-fit y object-position.
  • Las plantillas de marca usan customerHosts y solo aparecen para el dominio de cliente correspondiente.
font-size:100%;--p2p-headline-mul:{{headlineScale}};--p2p-text-mul:{{textScale}}
El contrato compartido template-base.css mantiene consistencia en plantillas nuevas sin quitar libertad a las firmas de marca.
Persistencia

Base de datos, backups y sync

La app usa una pequeña fachada de base de datos. SQLite es el valor por defecto; MariaDB/MySQL se puede seleccionar con DB_DRIVER sin cambiar el resto del código.

  • scripts/db/index.js expone run, all, get y migrate para todos los módulos.
  • Las migraciones son idempotentes y crean el esquema del driver activo al arrancar.
  • npm run db:backup exporta snapshots JSONL de tablas y puede importarlos después.
  • npm run db:sync copia datos entre SQLite y MariaDB/MySQL.
  • node-cron ejecuta syncs en segundo plano cada hora y omite clientes sincronizados recientemente.
DB_DRIVER=sqlite
# o
DB_DRIVER=mariadb
DB_HOST=127.0.0.1
DB_NAME=press2pixel
Ops

Desplegar con Docker o reverse proxy

La app puede correr directamente con Node o mediante Docker Compose. En producción, el proxy debe enviar todas las rutas de app a Node porque el servidor posee las APIs y la composición de vistas.

  • docker compose up -d arranca la app y el sidecar de Ollama.
  • Los despliegues BYO Ollama pueden apuntar OLLAMA_URL al host u otro contenedor.
  • Los ejemplos Nginx y Apache proxian todas las rutas de app a http://127.0.0.1:3000.
  • La imagen de producción excluye intencionalmente Playwright/Chromium y CLIs cloud salvo que una imagen custom los añada.
  • La landing pública es un build estático y no depende del servidor de la app.
docker compose up -d
docker compose exec ollama ollama pull gemma4:26b
Seguridad

Auth, privacidad y notas de seguridad

La autenticación existe, pero en los docs actuales es opt-in. Cuando la app esté expuesta públicamente, auth, HTTPS, rate limits y límites de crawl deberían activarse juntos.

  • AUTH_ENABLED=true activa el login gate y rutas API protegidas por sesión.
  • Las contraseñas usan scrypt y las sesiones se guardan como tokens opacos en cookies HttpOnly.
  • Los botones OAuth aparecen solo cuando están configurados client IDs y secrets del proveedor.
  • El registro abierto debería cambiarse por aprobación o códigos de invitación antes de un lanzamiento amplio.
  • Un despliegue público debe forzar HTTPS y limitar rutas de crawl, IA, login y registro.
AUTH_ENABLED=true
ADMIN_EMAIL=info@example.com
ADMIN_PASSWORD=change-me
Roadmap

Quality gates y roadmap

La app ya tiene una auditoría estricta de plantillas y un backlog práctico para open source. El siguiente trabajo de calidad se centra en endurecimiento para despliegue público, tests, modularidad y pulido de marcas de alto volumen.

  • npm test ejecuta la auditoría de plantillas y valida JSON activo, tokens del renderer, controles de imagen, condicionales y cobertura de hosts.
  • Trabajo prioritario de despliegue: defaults de auth, rate limiting, HTTPS, headers seguros y limpieza de scripts legacy.
  • Roadmap de producto: desktop packaging, editor de plantillas, selector de imágenes por item, integración de stock photos y auditorías visuales en más ratios.
  • Roadmap UI: mejores estados vacíos, toasts, atajos, flujos bulk de clientes y verificación móvil.
npm run test:unit
npm run test:audit
npm test
La documentación de la landing resume los docs de la app; no los reemplaza. Los markdown del repo siguen siendo la fuente de implementación.