El problema
En casi cualquier empresa pequeña hay un sistema que solo una persona sabe usar. Mientras esa persona esté, no se nota. En cuanto se va de vacaciones o cambia de puesto, el proceso se va con ella.
La salida conocida es escribir el procedimiento, y ahí empieza el trabajo real: capturar cada pantalla, pegarla en un documento, numerarla, describir qué se hace en cada una, y repetirlo entero cuando la herramienta cambia un botón de sitio. Nadie quiere hacerlo dos veces, así que casi nunca se hace una.
ClipManual recorta ese camino. Subes las capturas en orden —o grabas un video corto de la pantalla y ClipManual extrae los pasos—, escribes qué enseña el proceso, y recibes un borrador con título, objetivo y pasos numerados, cada uno anclado a su captura.
Cómo está construido, y por qué así
Conviene empezar por lo que no tiene mérito: generar el texto de una guía a partir de unas capturas lo resuelve hoy cualquier modelo. Lo interesante está alrededor: dónde se procesa cada cosa, qué pasa cuando algo falla a mitad, y quién es el dueño de cada dato.
Sin cuentas, y lo que eso obliga
No hay registro ni usuarios que persistir. Eso elimina medio producto habitual —login, recuperación de contraseña, perfiles— y obliga a resolver dónde vive lo que hay que recordar. El trabajo en curso vive en el navegador; el estado que no puede vivir ahí —cuota, límite de peticiones, saldo de créditos y correlación de pagos— vive en Upstash Redis.
El navegador hace el trabajo pesado
El video no llega al servidor. El modelo recibe imágenes, no video, así que los fotogramas se extraen en el navegador: lo que viaja son las capturas, y el video entero se queda en el equipo. Se descodifica en un canvas y se detectan los cambios de escena comparando muestras reducidas. Lo que no es obvio es que hacen falta dos estrategias: un muestreo por posición para los MP4 y MOV indexados, y un respaldo que reproduce el video acelerado, porque los WebM de MediaRecorder no traen índice y la búsqueda devuelve siempre el mismo fotograma.
Ocultar datos sensibles es pixelado, no desenfoque. Un desenfoque se puede revertir parcialmente; un mosaico de bloques grandes destruye la información. La imagen pixelada sustituye a la original antes de generar, así que la zona tapada no llega ni al modelo ni al PDF.
El borrador vive en IndexedDB, no en localStorage. Las capturas son dataURLs de varios megas; localStorage se topa mucho antes.
La salida estructurada no se pide, se obliga
El modelo no devuelve texto libre para parsearlo después. Se le entrega una herramienta con el esquema exacto de la guía —título, objetivo, y cada paso con el índice de su captura— y se le fuerza a usarla: un JSON con la forma que se espera, en lugar de un texto que casi siempre tiene esa forma. Aun así la salida se sanea: que una respuesta esté bien tipada no significa que su contenido sea correcto.
El dinero: eliminar el estado ambiguo en vez de gestionarlo
El uso de pago se descuenta en créditos, y cobrar uno parece una resta. La primera versión eran tres viajes a Redis —comprobar la clave, decrementar, devolver el crédito si la generación fallaba— y eso deja un estado intermedio irresoluble: si el decremento se aplica y se pierde la respuesta, nadie sabe si se cobró. La versión que quedó es un script Lua atómico: o se aplicó y se sabe el saldo, o no se aplicó nada.
El reembolso es peor. INCR sobre una clave que no existe la crea con valor 1, y como la existencia de esa misma clave decide si una licencia es válida, un reembolso sobre una clave de licencia que nadie vendió no solo regalaba saldo: convertía esa clave en una licencia válida. Ahora también es atómico y solo incrementa si la clave ya existía.
Fallar abierto o cerrado se decide caso por caso. Si no se puede comprobar una clave de licencia, cobrar no es una opción y esa persona pasa al camino gratis. Pero comprobar si una licencia existe falla cerrado: abierto, cualquier clave inventada activaría una licencia en cuanto Redis parpadeara.
Un solo dueño por hecho. El precio llegó a estar escrito a mano en el checkout, coincidiendo con la fuente de verdad por casualidad: el modo de fallo es cambiarlo en la web, olvidar el checkout y anunciar un importe mientras se cobra otro, sin que nada se ponga rojo. La disponibilidad del cobro sigue el mismo principio: la decide el servidor con la misma función que produce el error del checkout, no una bandera aparte que dejaría a la interfaz prometer lo que el servidor no puede cumplir. Y si esa consulta falla, degrada a no disponible: un booleano ausente no se interpreta como un sí.
La compuerta que ninguna prueba veía
Un componente de cliente importaba, por una cadena de tres módulos, algo que acababa en node:crypto, y la aplicación no compilaba. Las pruebas estaban en verde y los tipos en cero errores, porque ninguno de los dos mira el empaquetado del navegador: eso solo lo ve el build. Ahora los módulos de servidor están marcados como tales, así que importarlos desde el cliente revienta el build nombrando la frontera cruzada, y el build es compuerta obligatoria y separada.
Qué hace y qué no hace
Hace: convierte capturas o un video corto de pantalla en una guía con título, objetivo y pasos numerados en español, deja editar cada texto, pixela zonas sensibles, conserva el borrador en el navegador y exporta un PDF con las capturas embebidas. Sin crear cuenta.
Lo que no hace:
- No captura sola. Las capturas las pones tú, o salen de un video que grabas tú: la herramienta no graba tu pantalla por su cuenta.
- No hay links compartibles. La guía termina en un PDF.
- No mantiene una biblioteca de procesos. No hay versiones, ni historial, ni aviso de que una guía se quedó vieja. Es la dirección que más valor añadiría, y hoy es dirección, no capacidad.
- No acredita que una guía sea correcta. La salida queda anclada a capturas reales y una persona puede revisarla y editarla, pero no existe un estado formal de aprobación ni firma.
Dónde está
clipmanual.com — funciona en el navegador, sin instalar nada.
