Przełączanie kontekstu niszczy impet. Gdy asystent AI przerywa pracę w połowie projektu, kolejna sesja zaczyna się od zera. Brak pamięci o strukturze repozytorium. Brak wiedzy o tym, które porty są aktywne. Brak świadomości, że wczoraj Monero RPC sprawiało problemy. Daniel Ioni stworzył coś surowego, ale użytecznego: przewodnik techniczny napisany specjalnie dla systemów AI, aby mogły one kontynuować pracę nad MyZubster Gateway bez konieczności prowadzenia za rękę. Funkcjonuje on jako trwała syntetyczna pamięć. Zamiast wyrzucać surowy kod źródłowy, uczy maszynę, jak obsługiwać system, rozwiązywać problemy i szanować uprawnienia operatora przed wprowadzeniem destrukcyjnych zmian.

Co tak naprawdę buduje MyZubster

MyZubster Gateway to zdecentralizowany rynek zbudowany wokół tokenizacji aktywów rzeczywistych. Mówiąc prościej, jest to infrastruktura, która pozwala fizycznym lub tradycyjnym aktywom przemieszczać się on-chain z określonymi metadanymi i regułami własności. Platforma obsługuje tokenizację aktywów zamiennych (fungible), co oznacza, że aktywa mogą być dzielone, handlowane i śledzone z ustandaryzowanymi metadanymi przypisanymi do każdej jednostki.

Prywatność leży u podstaw projektu. Transakcje są rozliczane w Monero. Programowalne aktywa i NFT działają na Tari. Cała operacja chroni się za pomocą usługi Tor Onion Service, co czyni gateway odpornym na cenzurę i blokowanie geograficzne. Warstwa bezpieczeństwa działa na systemie Kali Linux i wykorzystuje boty bezpieczeństwa DeepSeek AI, co sugeruje automatyczne wykrywanie włamań lub skanowanie anomalii zamiast zwykłej rotacji logów. Depozyt (escrow) i rozwiązywanie sporów nie są zadaniami manualnymi wykonywanymi przez back-office. Są one zautomatyzowane, a AI pełni rolę mediatora, gdy warunki handlu wywołują konflikt.

To tylko wierzchołek góry lodowej. Pod spodem system stanowi sieć punktów końcowych RPC, lokalnych baz danych i procesów Node.js, które muszą pozostawać zsynchronizowane, w przeciwnym razie rynek przestanie rozliczać transakcje.

Stos technologiczny i dlaczego jest ważny

Gateway nasłuchuje na porcie 3002. To główne wejście. RPC portfela Monero znajduje się pod adresem localhost:18083, obsługując prywatne operacje portfela, zapytania o saldo i przelewy wychodzące bez narażania danych użytkownika na publiczną analitykę łańcucha. RPC Tari odpowiada pod adresem localhost:12820, zarządzając warstwą programowalnych aktywów. Jeśli którykolwiek z tych punktów końcowych ulegnie rozsynchronizowaniu lub przestanie działać, rynek zostanie sparaliżowany.

MongoDB działa w tle jako magazyn danych operacyjnych. Node.js napędza samą usługę gateway. Kod frontendowy znajduje się w dedykowanym katalogu ~/myzubster-frontend. Jest to klasyczny zdecentralizowany stos: węzły blockchain do rozliczeń, lokalna baza danych do przechowywania stanu i cienka warstwa webowa do interakcji, a wszystko to zamknięte w narzędziach zapewniających prywatność. Nic tutaj nie jest dekoracją. Każdy port i ścieżka zostały wybrane tak, aby system był autonomiczny i łatwy do obrony.

Uruchamianie systemu

Uruchomienie gateway to pojedyncza komenda systemd: systemctl start myzubster-gateway. Brzmi to trywialnie, dopóki usługa nie zawiedzie po cichu po nieplanowanym restarcie. Wtedy potrzebna jest komenda journalctl -u myzubster-gateway -n 50 --no-pager, aby wyciągnąć ostatnich pięćdziesiąt linii logów bez zbędnego szumu związanego z przewijaniem stron. Te pięćdziesiąt linii zazwyczaj zawiera odpowiedź. Być może Monero RPC odrzuciło połączenie. Być może MongoDB nie wróciło online po aktualizacji systemu.

Bot bezpieczeństwa znajduje się w /root/security_bot.py i uruchamia się za pomocą python3 /root/security_bot.py. Uruchamianie skryptu bezpieczeństwa jako root to nie jest coś, co robi się na serwerze ogólnego przeznaczenia. W utwardzonym środowisku Kali, dedykowanym do monitorowania i automatycznej reakcji, jest to zgodne z modelem operacyjnym. Integracja z DeepSeek AI sugeruje, że bot robi coś więcej niż tylko skanowanie logów; prawdopodobnie ocenia zachowanie sieci lub wzorce transakcji pod kątem oznak naruszenia bezpieczeństwa.

W przypadku prac nad frontendem przewodnik całkowicie eliminuje zgadywanie. AI zna dokładne miejsce docelowe: cd ~/myzubster-frontend. Nie ma potrzeby przeszukiwania /var/www, /opt czy rozproszonych katalogów domowych. Przewodnik wymusza spójność poprzez sztywne przypisanie tych ścieżek, co ma znaczenie, gdy wiele sesji lub różne instancje AI korzystają z tego samego serwera przez wiele tygodni.

Gdy coś pójdzie nie tak

Gdy gateway przestaje działać, pierwszym krokiem jest rozpoznanie procesów. Uruchom ps aux | grep node, aby sprawdzić, czy proces Node.js wciąż działa. Jeśli zniknął, sprawdź logi. Jeśli logi wskazują na błąd połączenia z bazą danych, winowajcą jest MongoDB. Uruchom ją komendą systemctl start mongod. Wiele zdecentralizowanych aplikacji traktuje węzły blockchain jako komponenty kruche, ale w praktyce to lokalna instancja MongoDB jest często tym, co zawodzi jako pierwsze po nieprawidłowym zamknięciu systemu lub rutynowej aktualizacji pakietów.

Problemy z Monero RPC mają inny wzorzec. Jeśli salda przestają się aktualizować lub transakcje wypłat zawieszają się w stanie oczekującym (pending), instrukcja nakazuje sprawdzenie statusu monero-wallet-rpc. Zazwyczaj oznacza to zweryfikowanie, czy proces wallet RPC działa, potwierdzenie, czy zsynchronizował się z właściwym daemonem oraz upewnienie się, że flagi uwierzytelniania są zgodne z oczekiwaniami bramy (gateway). Triaż jest tutaj prosty: najpierw warstwa rozliczeń blockchain, potem baza danych, na końcu aplikacja. Zignoruj tę kolejność, a będziesz gonić duchy w logach Node.js, podczas gdy rzeczywistą przyczyną awarii jest martwy port RPC.

Jak AI powinna korzystać z tej instrukcji

Instrukcja narzuca AI cztery zasady postępowania, które wynikają ze zrozumienia tego, jak asystenci automatyczni zawodzą w środowiskach produkcyjnych.

Po pierwsze, odwołuj się do konkretnych sekcji. Jeśli użytkownik rozwiązuje problem z nieudaną płatnością, AI powinna wyraźnie nazwać Monero RPC lub podsystem escrow, aby użytkownik wiedział dokładnie, która „rura” przecieka. Po drugie, podawaj dokładne komendy. Nie parafrazuj flag ani nie zgaduj ścieżek. Po trzecie, sugeruj kolejny logiczny krok. Odzyskiwanie projektu to sekwencja; chaotyczne przeskakiwanie między sprawdzaniem portów a botami bezpieczeństwa marnuje minuty i niesie ryzyko pogorszenia problemu. Po czwarte, proś użytkownika o potwierdzenie przed restartowaniem usług lub usuwaniem danych. Autonomia jest przydatna, dopóki przypadkowo nie wyczyści pamięci podręcznej portfela lub nie wyłączy bramy podczas aktywnych transakcji.

Żyjący dokument

Ta instrukcja została zaprojektowana tak, aby ewoluować. W miarę rozwoju projektu MyZubster, AI aktualizuje dokument. Tworzy to pętlę zwrotną, w której doświadczenie operacyjne staje się pamięcią instytucjonalną. W małym zespole lub w przypadku projektu realizowanego solo, działającego w różnych strefach czasowych i cyklach snu, zastępuje to wiedzę przekazywaną przy „ekspresie do kawy”, która zazwyczaj znajduje się w głowach starszych inżynierów. Dokument uczy się na każdej awarii.

Kluczowy wniosek

Przewodniki AI dotyczące odzyskiwania projektów, takie jak ten, rozwiązują konkretny, uciążliwy problem. Niwelują lukę między surową dokumentacją a zrozumieniem kontekstu. Dla MyZubster oznacza to, że marketplace może przetrwać utratę kontekstu, restarty i zmiany w zespole. Maszyna nie musi uczyć się stosu technologicznego od zera przy każdej nowej sesji. Musi jedynie przeczytać instrukcję, postępować zgodnie z dokładnymi komendami i wiedzieć, kiedy przestać i zapytać.

Źródło: AI Technical Guide: MyZubster Project Recovery autorstwa Daniel Ioni

Opcjonalna społeczność edukacyjna: GyaanSetu AI on Telegram