Context switching kills momentum. When an AI assistant drops mid project, the next session starts cold. No memory of the

Context switching kills momentum. When an AI assistant drops mid-project, the next session starts cold. No memory of the repository structure. No recall of which ports are live. No awareness that the Monero RPC was acting up yesterday. Daniel Ioni built something blunt and useful: a technical guide written specifically for AI systems so they can resume work on the MyZubster Gateway without hand-holding. It functions as persistent synthetic memory. Instead of dumping raw source code, it teaches the machine how to operate the system, troubleshoot failures, and respect the operator's authority before making destructive changes.

What MyZubster Actually Builds

MyZubster Gateway is a decentralized marketplace built around real-world asset tokenization. In plain terms, it is infrastructure that lets physical or traditional assets move on-chain with defined metadata and ownership rules. The platform handles fungible asset tokenization, meaning assets can be divided, traded, and tracked with standardized metadata attached to each unit.

Privacy sits at the center of the design. Transactions settle in Monero. Programmable assets and NFTs run on Tari. The entire operation shields itself behind a Tor Onion Service, making the gateway resistant to censorship and geographic blocking. A security layer runs on Kali Linux and uses DeepSeek AI security bots, suggesting automated intrusion detection or anomaly scanning rather than simple log rotation. Escrow and dispute resolution are not manual back-office tasks. They are automated, with AI mediating when trade conditions trigger a conflict.

That is the surface. Underneath, the system is a web of RPC endpoints, local databases, and Node.js processes that must stay synchronized or the marketplace stops clearing trades.

The Technical Stack and Why It Matters

The gateway listens on port 3002. That is the front door. Monero's wallet RPC sits at localhost:18083, handling private wallet operations, balance queries, and outgoing transfers without exposing user data to public chain analytics. Tari's RPC responds at localhost:12820, managing the programmable asset layer. If any of these endpoints drift or die, the marketplace grinds to a halt.

MongoDB sits in the background as the operational data store. Node.js powers the gateway service itself. The frontend code lives in a dedicated directory at ~/myzubster-frontend. This is a classic decentralized stack: blockchain nodes for settlement, a local database for state, and a thin web layer for interaction, all wrapped in privacy tooling. Nothing here is decorative. Every port and path was chosen to keep the system self-contained and defensible.

Running the System

Starting the gateway is a single systemd command: systemctl start myzubster-gateway. That sounds trivial until the service fails silently after an unattended reboot. Then you need journalctl -u myzubster-gateway -n 50 --no-pager to pull the last fifty log lines without paging noise. Those fifty lines usually hold the answer. Maybe the Monero RPC refused the connection. Maybe MongoDB never came back online after a system update.

The security bot lives at /root/security_bot.py and launches with python3 /root/security_bot.py. Running a security script as root is not something you do on a general-purpose server. Inside a hardened Kali environment dedicated to monitoring and automated response, it fits the operational model. The DeepSeek AI integration implies the bot is doing more than scanning logs; it is likely evaluating network behavior or transaction patterns for signs of compromise.

For frontend work, the guide removes guesswork entirely. The AI knows the exact landing spot: cd ~/myzubster-frontend. No searching through /var/www, /opt, or scattered home directories. The guide enforces consistency by pinning these paths exactly, which matters when multiple sessions or different AI instances touch the same server over weeks.

When Things Break

When the gateway goes dark, the first move is process reconnaissance. Run ps aux | grep node to see if the Node.js process is still breathing. If it vanished, check the logs. If logs show a database connection error, MongoDB is the culprit. Bring it up with systemctl start mongod. Many decentralized applications treat blockchain nodes as the fragile component, but in practice, the local MongoDB instance is often what flakes first after an unclean shutdown or a routine package update.

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