Перемикання контексту вбиває темп. Коли ШІ-асистент перериває роботу посеред проєкту, наступна сесія починається з нуля. Жодної пам'яті про структуру репозиторію. Жодного нагадування про те, які порти активні. Жодного розуміння того, що Monero RPC працював нестабільно вчора. Daniel Ioni створив щось просте й корисне: технічний посібник, написаний спеціально для ШІ-систем, щоб вони могли відновити роботу з MyZubster Gateway без сторонньої допомоги. Він функціонує як постійна синтетична пам'ять. Замість того, щоб просто скидати сирий вихідний код, він навчає машину керувати системою, усувати несправності та поважати повноваження оператора перед внесенням деструктивних змін.

Що насправді створює MyZubster

MyZubster Gateway — це децентралізований маркетплейс, побудований навколо токенізації реальних активів. Простими словами, це інфраструктура, яка дозволяє фізичним або традиційним активам переміщуватися в ончейні (on-chain) із визначеними метаданими та правилами власності. Платформа забезпечує токенізацію взаємозамінних активів, що означає, що активи можна розділяти, торгувати ними та відстежувати за допомогою стандартизованих метаданих, прикріплених до кожної одиниці.

Приватність лежить в основі дизайну. Розрахунки за транзакціями здійснюються в Monero. Програмовані активи та NFT працюють на Tari. Уся операція захищена за допомогою Tor Onion Service, що робить шлюз стійким до цензури та географічного блокування. Шар безпеки працює на Kali Linux і використовує ботів безпеки DeepSeek AI, що передбачає автоматичне виявлення вторгнень або сканування аномалій замість простого ротації логів. Ескроу та вирішення спорів не є ручними завданнями бек-офісу. Вони автоматизовані, а ШІ виступає посередником, коли умови торгівлі спричиняють конфлікт.

Це лише поверхня. Під нею система являє собою мережу RPC-ендпоінтів, локальних баз даних і процесів Node.js, які мають залишатися синхронізованими, інакше маркетплейс припинить проведення угод.

Технологічний стек і чому це важливо

Шлюз прослуховує порт 3002. Це "вхідні двері". Monero wallet RPC працює на localhost:18083, обробляючи операції з приватним гаманцем, запити балансу та вихідні перекази, не розкриваючи дані користувачів для публічної аналітики блокчейну. Tari RPC відповідає на localhost:12820, керуючи шаром програмованих активів. Якщо будь-який із цих ендпоінтів відхилиться від норми або перестане працювати, робота маркетплейсу зупиниться.

MongoDB працює у фоновому режимі як сховище оперативних даних. Node.js забезпечує роботу самого сервісу шлюзу. Код фронтенду знаходиться в окремій директорії ~/myzubster-frontend. Це класичний децентралізований стек: вузли блокчейну для розрахунків, локальна база даних для стану та тонкий веб-шар для взаємодії, і все це в обгортці інструментів приватності. Тут немає нічого декоративного. Кожен порт і шлях було обрано так, щоб система була автономною та захищеною.

Запуск системи

Запуск шлюзу — це одна команда systemd: systemctl start myzubster-gateway. Це звучить тривіально, поки сервіс тихо не вийде з ладу після неочікуваного перезавантаження. Тоді вам знадобиться journalctl -u myzubster-gateway -n 50 --no-pager, щоб отримати останні п'ятдесят рядків логів без зайвого шуму від пагінації. Ці п'ятдесят рядків зазвичай містять відповідь. Можливо, Monero RPC відхилив з'єднання. Можливо, MongoDB так і не повернулася в онлайн після оновлення системи.

Бот безпеки знаходиться за адресою /root/security_bot.py і запускається командою python3 /root/security_bot.py. Запуск скрипта безпеки від імені root — це не те, що роблять на серверах загального призначення. У посиленому середовищі Kali, призначеному для моніторингу та автоматизованого реагування, це відповідає операційній моделі. Інтеграція DeepSeek AI означає, що бот робить більше, ніж просто сканування логів; ймовірно, він оцінює поведінку мережі або патерни транзакцій на наявність ознак компрометації.

Для роботи з фронтендом посібник повністю усуває здогадки. ШІ знає точне місце призначення: cd ~/myzubster-frontend. Не потрібно шукати у /var/www, /opt або розкиданих домашніх директоріях. Посібник забезпечує узгодженість, чітко фіксуючи ці шляхи, що важливо, коли протягом тижнів кілька сесій або різні екземпляри ШІ працюють з одним і тим самим сервером.

Коли щось ламається

Коли шлюз зникає з мережі, першим кроком є розвідка процесів. Виконайте ps aux | grep node, щоб побачити, чи "дихає" ще процес Node.js. Якщо він зник — перевірте логи. Якщо логи показують помилку підключення до бази даних, винуватцем є MongoDB. Запустіть її за допомогою systemctl start mongod. Багато децентралізованих застосунків вважають вузли блокчейну найкрихкішим компонентом, але на практиці саме локальний екземпляр MongoDB часто дає збій першим після некоректного завершення роботи або планового оновлення пакетів.

Проблеми з Monero RPC мають іншу закономірність. Якщо баланси перестають оновлюватися або транзакції виплат зависають у стані очікування (pending), інструкція рекомендує перевірити статус monero-wallet-rpc. Зазвичай це означає перевірку того, чи запущено процес wallet RPC, підтвердження синхронізації з правильним демоном та переконання, що прапорці автентифікації відповідають очікуванням шлюзу (gateway). Сортування (triage) тут просте: спочатку рівень розрахунків блокчейну, потім база даних, і наприкінці — додаток. Ігноруйте цей порядок, і ви будете шукати «привидів» у логах Node.js, тоді як справжня причина — неактивний RPC-порт.

Як ШІ має використовувати цей посібник

Посібник встановлює чотири правила поведінки для ШІ, які демонструють розуміння того, як автоматизовані асистенти дають збої в робочих (production) середовищах.

По-перше, посилайтеся на конкретні розділи. Якщо користувач намагається усунути несправність при оплаті, ШІ має чітко назвати Monero RPC або підсистему ескроу (escrow), щоб користувач точно знав, де саме стався збій (яка «труба» протікає). По-друге, надавайте точні команди. Не перефразовуйте прапорці та не вгадуйте шляхи. По-третє, пропонуйте наступний логічний крок. Відновлення проєкту — це послідовність; хаотичне перемикання між перевіркою портів та ботами безпеки витрачає час і ризикує погіршити ситуацію. По-четверте, запитуйте підтвердження користувача перед перезапуском сервісів або видаленням даних. Автономність корисна доти, доки вона випадково не очистить кеш гаманця або не зупинить шлюз під час активної торгівлі.

Живий документ

Цей посібник спеціально розроблений для того, щоб еволюціонувати. У міру зростання проєкту MyZubster ШІ оновлює документ. Це створює петлю зворотного зв'язку, де операційний досвід стає інституційною пам'яттю. У невеликій команді або в індивідуальному проєкті, що працює в різних часових поясах і циклах сну, це замінює неформальні знання («біля кулера»), які зазвичай зберігаються в головах старших інженерів. Документ навчається на кожному збої.

Головний висновок

Посібники з відновлення проєктів за допомогою ШІ, подібні до цього, вирішують конкретну болючу проблему. Вони долають розрив між сирою документацією та контекстуальним розумінням. Для MyZubster це означає, що маркетплейс зможе пережити втрату контексту, перезавантаження та зміну команди. Машині не потрібно щоразу вивчати стек технологій з нуля при початку нової сесії. Їй просто потрібно прочитати інструкцію, виконувати точні команди та знати, коли варто зупинитися і запитати.

Джерело: AI Technical Guide: MyZubster Project Recovery автор Daniel Ioni

Додаткова спільнота для навчання: GyaanSetu AI on Telegram