El cambio de contexto mata el impulso. Cuando un asistente de IA se interrumpe a mitad de un proyecto, la siguiente sesión comienza de cero. Sin memoria de...

El cambio de contexto mata el impulso. Cuando un asistente de IA se interrumpe a mitad de un proyecto, la siguiente sesión comienza de cero. Sin memoria de la estructura del repositorio. Sin recuerdo de qué puertos están activos. Sin saber que el RPC de Monero estaba fallando ayer. Daniel Ioni construyó algo directo y útil: una guía técnica escrita específicamente para sistemas de IA, de modo que puedan reanudar el trabajo en el MyZubster Gateway sin necesidad de supervisión constante. Funciona como una memoria sintética persistente. En lugar de volcar código fuente bruto, le enseña a la máquina cómo operar el sistema, solucionar fallos y respetar la autoridad del operador antes de realizar cambios destructivos.

Lo que MyZubster construye realmente

MyZubster Gateway es un mercado descentralizado construido en torno a la tokenización de activos del mundo real. En términos sencillos, es una infraestructura que permite que los activos físicos o tradicionales se muevan on-chain con metadatos y reglas de propiedad definidos. La plataforma gestiona la tokenización de activos fungibles, lo que significa que los activos pueden dividirse, negociarse y rastrearse con metadatos estandarizados adjuntos a cada unidad.

La privacidad es el núcleo del diseño. Las transacciones se liquidan en Monero. Los activos programables y los NFTs funcionan sobre Tari. Toda la operación se protege tras un servicio Tor Onion, lo que hace que la pasarela sea resistente a la censura y al bloqueo geográfico. Una capa de seguridad se ejecuta en Kali Linux y utiliza bots de seguridad de DeepSeek AI, lo que sugiere detección de intrusiones automatizada o escaneo de anomalías en lugar de una simple rotación de logs. El depósito en garantía (escrow) y la resolución de disputas no son tareas manuales de back-office. Están automatizados, con la IA mediando cuando las condiciones comerciales desencadenan un conflicto.

Eso es solo la superficie. Debajo, el sistema es una red de endpoints RPC, bases de datos locales y procesos de Node.js que deben permanecer sincronizados o el mercado dejará de liquidar transacciones.

El stack técnico y por qué es importante

La pasarela escucha en el puerto 3002. Esa es la puerta de entrada. El RPC de la billetera de Monero se encuentra en localhost:18083, gestionando operaciones de billeteras privadas, consultas de saldo y transferencias salientes sin exponer los datos del usuario al análisis de la cadena pública. El RPC de Tari responde en localhost:12820, gestionando la capa de activos programables. Si alguno de estos endpoints se desvía o falla, el mercado se detiene por completo.

MongoDB funciona en segundo plano como el almacén de datos operativos. Node.js impulsa el propio servicio de la pasarela. El código del frontend reside en un directorio dedicado en ~/myzubster-frontend. Este es un stack descentralizado clásico: nodos de blockchain para la liquidación, una base de datos local para el estado y una capa web ligera para la interacción, todo envuelto en herramientas de privacidad. Nada aquí es decorativo. Cada puerto y ruta fue elegido para mantener el sistema autónomo y defendible.

Ejecución del sistema

Iniciar la pasarela es un único comando de systemd: systemctl start myzubster-gateway. Eso suena trivial hasta que el servicio falla silenciosamente tras un reinicio no supervisado. Entonces necesitarás journalctl -u myzubster-gateway -n 50 --no-pager para extraer las últimas cincuenta líneas de log sin el ruido de la paginación. Esas cincuenta líneas suelen contener la respuesta. Quizás el RPC de Monero rechazó la conexión. Quizás MongoDB nunca volvió a estar en línea tras una actualización del sistema.

El bot de seguridad se encuentra en /root/security_bot.py y se lanza con python3 /root/security_bot.py. Ejecutar un script de seguridad como root no es algo que se haga en un servidor de propósito general. Dentro de un entorno Kali endurecido dedicado al monitoreo y la respuesta automatizada, encaja en el modelo operativo. La integración de DeepSeek AI implica que el bot está haciendo más que escanear logs; es probable que esté evaluando el comportamiento de la red o los patrones de transacciones en busca de signos de compromiso.

Para el trabajo de frontend, la guía elimina por completo las conjeturas. La IA conoce el lugar exacto: cd ~/myzubster-frontend. Sin necesidad de buscar en /var/www, /opt o directorios de inicio dispersos. La guía impone la consistencia fijando estas rutas exactamente, lo cual es importante cuando múltiples sesiones o diferentes instancias de IA acceden al mismo servidor durante semanas.

Cuando algo falla

Cuando la pasarela deja de funcionar, el primer paso es el reconocimiento de procesos. Ejecuta ps aux | grep node para ver si el proceso de Node.js sigue vivo. Si ha desaparecido, revisa los logs. Si los logs muestran un error de conexión a la base de datos, MongoDB es el culpable. Levántalo con systemctl start mongod. Muchas aplicaciones descentralizadas tratan a los nodos de blockchain como el componente frágil, pero en la práctica, la instancia local de MongoDB suele ser lo primero que falla tras un apagado incorrecto o una actualización rutinaria de paquetes.

Monero RPC issues follow a different pattern. If balances stop updating or payout transactions hang in a pending state, the guide instructs checking monero-wallet-rpc status. That usually means verifying the wallet RPC process is running, confirming it synced to the correct daemon, and ensuring the authentication flags match what the gateway expects. Triage here is simple: blockchain settlement layer first, database second, application third. Ignore that order and you will chase ghosts in the Node.js logs when the real failure is a dead RPC port.

How the AI Should Use This Manual

The guide imposes four behavioral rules on the AI, and they reveal an understanding of how automated assistants fail in production environments.

First, reference specific sections. If the user is troubleshooting a payment failure, the AI should name the Monero RPC or escrow subsystem explicitly so the user knows exactly which pipe is leaking. Second, provide exact commands. Do not paraphrase flags or guess paths. Third, suggest the next logical step. Project recovery is a sequence; jumping randomly between port checks and security bots wastes minutes and risks making the problem worse. Fourth, ask for user confirmation before restarting services or deleting data. Autonomy is useful until it accidentally wipes a wallet cache or brings down the gateway during active trades.

A Living Document

This guide is explicitly designed to evolve. As the MyZubster project grows, the AI updates the document. That creates a feedback loop where operational experience becomes institutional memory. In a small team, or a solo project operating across time zones and sleep cycles, this replaces the watercooler knowledge that usually lives in senior engineers' heads. The document learns from every outage.

The Real Takeaway

AI project recovery guides like this one solve a specific, painful problem. They bridge the gap between raw documentation and contextual understanding. For MyZubster, that means the marketplace can survive context loss, reboots, and team transitions. The machine does not need to relearn the stack from scratch every time a new session starts. It just needs to read the manual, follow the exact commands, and know when to stop and ask.

Source: AI Technical Guide: MyZubster Project Recovery by Daniel Ioni

Optional learning community: GyaanSetu AI on Telegram