La idea clave
Genera diagramas HTML y SVG a partir de una estructura que puedes revisar. La clave es comprobar que cada componente y cada conexión existen.
Una aplicación funciona hasta que alguien pregunta cómo encajan sus piezas. Ahí suelen aparecer las cajas dibujadas deprisa y las flechas que nadie sabe justificar. Archify propone generar un mapa del sistema con ayuda de un agente y mantener una representación estructurada detrás del resultado.
Cómo pasa de una descripción al diagrama
El proyecto utiliza Node.js: el agente produce una estructura JSON tipada y Archify la convierte en HTML y SVG mediante renderizado y validación. Incluye diagramas de arquitectura, flujos, secuencias, datos y ciclos de vida. El código tiene licencia MIT.
También contempla comparar versiones de un diagrama. Su documentación distingue los cambios en lo representado de los efectos reales en producción. Esa separación evita interpretar una comprobación de estructura como una garantía de que el sistema funciona correctamente.
Un encargo mejor que «hazme un dibujo»
Supongamos que quieres explicar un sistema de reservas. Nuestro ejemplo de encargo sería: «Representa cómo una persona elige una fecha, cómo se comprueba la disponibilidad y dónde se guarda la reserva. Incluye el caso en que dos personas eligen la misma plaza. Marca lo que no puedas confirmar».
El caso de conflicto importa tanto como el recorrido normal. Obliga a aclarar dónde se toma una decisión y qué componente la controla. Para una primera revisión, tres relaciones confirmadas sirven más que veinte flechas inferidas.
Qué debería entregar un buen mapa
Encargo propuesto por Texploto
Representa el recorrido de una reserva: navegador, API y base de datos. Marca dónde se comprueba la disponibilidad y qué ocurre si otra persona reserva antes. Junto a cada relación, identifica el archivo o requisito que la respalda. Separa las suposiciones pendientes de confirmar.
El resultado sirve para una revisión si puedes seguir una reserva sin pedir una explicación adicional y localizar la evidencia de la comprobación de disponibilidad. Si solo muestra tres cajas conectadas, todavía falta la decisión más importante. Para gráficos centrados en explicar conceptos, consulta también Diagram Design.
Cómo empezar y revisar el resultado
El inicio guiado permite elegir el agente. Puedes partir de una descripción sin repositorio; si aportas código, delimita qué carpetas o componentes debe analizar. No hace falta entregar información que no aporte nada al mapa.
Después revisa nombres, dirección de las flechas y condiciones de cada bifurcación. Busca una relación cuyo origen conozcas y comprueba que el dibujo la explica correctamente. Si el agente inventa un servicio inexistente, corrige la estructura antes de ajustar colores o animaciones.
Dónde aporta más
Lo vemos especialmente interesante para incorporar a alguien a un proyecto o discutir una migración. El agente y su servicio pueden tener costes propios, aunque el código de Archify sea abierto. El resultado merece evaluarse por cuánto facilita una conversación técnica: si dos personas entienden igual dónde se guarda una reserva, el mapa está haciendo su trabajo.
Caso resuelto: dos personas quieren la última plaza
Este es un ejemplo didáctico original de Texploto, diseñado a mano. No es una salida de Archify ni el resultado de haber ejecutado el producto. Sirve como referencia para revisar un diagrama: puedes comparar sus decisiones con los requisitos, aunque uses otra herramienta para dibujarlo.
El sistema del ejemplo vende una sola plaza por sesión. Una persona puede consultar la disponibilidad y solicitarla, pero ver «libre» no bloquea la plaza. La reserva solo existe cuando queda guardada; una petición repetida debe devolver el mismo resultado, sin crear una segunda reserva.
Navegador
│ 1. Solicitar plaza + clave de petición
▼
API de reservas
│ 2. Intentar guardar, en una transacción
▼
Base de datos
├─ Plaza libre: guardar y confirmar
└─ Plaza ocupada: rechazar el conflicto
│ 3. Devolver resultado a la API
▼
API → Navegador: confirmación o conflictoQué demuestra cada flecha
| Relación | Requisito que respalda | Qué buscar en un proyecto real |
|---|---|---|
| Navegador → API | El cliente solicita, pero no decide quién consigue la plaza. | Ruta de creación de reservas, validación del usuario y clave que identifica la petición. |
| API → base de datos | Dos solicitudes no pueden confirmar la misma plaza. | Transacción y restricción única para la plaza de esa sesión, o mecanismo equivalente. |
| Base de datos → API | Solo se confirma una escritura que ha terminado correctamente. | Tratamiento del conflicto y del fallo de escritura, además del caso de éxito. |
| API → navegador | El lector distingue reserva confirmada, plaza agotada y error temporal. | Respuestas diferentes y una interfaz que no enseñe «confirmada» antes de recibir el resultado. |
El error que un dibujo bonito puede esconder
Una versión incorrecta separa «consultar si está libre» y «guardar la reserva» sin protección entre ambas operaciones. Ana consulta, después Bruno consulta, y los dos reciben «libre». Si el mapa termina ahí, parece válido, aunque permite prometer dos veces la misma plaza.
La corrección está en la decisión, no en añadir otra caja: ambos intentos de escritura deben competir bajo una regla que solo permita uno. En este ejemplo proponemos que la base de datos impida duplicar el par sesion_id, plaza_id. La API traduce el conflicto a una respuesta comprensible. No basta con volver a consultar justo antes de escribir.
| Paso del ejemplo | Ana | Bruno |
|---|---|---|
| Consulta inicial | Ve una plaza libre. | Ve la misma plaza libre. |
| Intento de reserva | Su escritura se confirma primero. | Su escritura encuentra la plaza ya ocupada. |
| Resultado | Recibe su identificador de reserva. | Recibe un conflicto; puede elegir otra sesión. |
La clave de petición resuelve un problema distinto: si Ana pierde la conexión después de que la reserva se guarde, reintentar no debería crear otra operación. El diagrama necesita mostrar dónde se reconoce ese reintento. Esta propiedad no se deduce de la restricción de plaza y debe justificarse por separado.
Para evaluar el mapa de tu proyecto, anota una evidencia por relación: un requisito, una ruta del código o una decisión de diseño confirmada. Donde falte, escribe «por confirmar». Pagos, cancelaciones, reservas de varias plazas y recuperación tras una caída quedan fuera de este ejemplo; añadirlos exigiría ampliar tanto el mapa como sus reglas.
Guía basada en la documentación consultada el 13 de septiembre de 2026; no hemos realizado una prueba funcional del proyecto. Consulta también los diez proyectos de esta edición semanal.
Revisar un cambio sin confundir el mapa con producción
La documentación consultada el 21/10/2026 ofrece diez tipos y una comparación Architecture Delta entre estados anteriores y posteriores. Las comprobaciones validan la representación; no deducen por sí solas el impacto real del cambio ni si puede fusionarse con seguridad. Las referencias a código pueden fijarse a un commit concreto cuando se solicita esa evidencia.
En nuestro ejemplo de reservas, una revisión útil conservaría dos versiones: la que consulta y guarda por separado, y la que impide duplicar la plaza al escribir. La tabla siguiente es un procedimiento editorial sobre ese caso ficticio, no una salida ejecutada de Archify.
| Dato del cambio | Evidencia que debe acompañarlo |
|---|---|
| Se añade una restricción única | Archivo de migración y campos que cubre |
| La API devuelve conflicto | Rama del código y respuesta prevista |
| Se conserva un reintento | Regla que relaciona la clave de petición con la reserva existente |
Si solo cambian colores o posiciones, la diferencia visual no acredita una corrección del sistema. Si cambia una regla, conserva el requisito, el commit y el dato aún pendiente. Para un gráfico final destinado a publicación, compara también el alcance de edición de Diagram Design.
Revisión documental del 21/10/2026: añadida esta ficha de versiones. El ejemplo de reservas continúa siendo didáctico y no se ha ejecutado Archify.
