কনটেক্সট সুইচিং (Context switching) কাজের গতি কমিয়ে দেয়। যখন কোনো AI অ্যাসিস্ট্যান্ট প্রজেক্টের মাঝপথে কাজ ছেড়ে দেয়, পরবর্তী সেশনটি একদম শূন্য থেকে শুরু হয়। রিপোজিটরি স্ট্রাকচার সম্পর্কে কোনো স্মৃতি থাকে না। কোন পোর্টগুলো সচল তা মনে থাকে না। গতকাল Monero RPC সমস্যা করছিল, সে সম্পর্কেও কোনো ধারণা থাকে না। Daniel Ioni একটি অত্যন্ত কার্যকর এবং সরাসরি বিষয়ভিত্তিক কিছু তৈরি করেছেন: AI সিস্টেমগুলোর জন্য বিশেষভাবে লেখা একটি টেকনিক্যাল গাইড, যাতে তারা কোনো মানুষের সাহায্য ছাড়াই MyZubster Gateway-এর কাজ পুনরায় শুরু করতে পারে। এটি একটি স্থায়ী সিন্থেটিক মেমরি (persistent synthetic memory) হিসেবে কাজ করে। শুধু র (raw) সোর্স কোড না দিয়ে, এটি মেশিনকে শেখায় কীভাবে সিস্টেমটি পরিচালনা করতে হয়, ত্রুটি সমাধান (troubleshoot) করতে হয় এবং কোনো ধ্বংসাত্মক পরিবর্তন করার আগে অপারেটরের নির্দেশ মেনে চলতে হয়।
MyZubster আসলে কী তৈরি করে
MyZubster Gateway হলো রিয়েল-ওয়ার্ল্ড অ্যাসেট টোকেনাইজেশনের (real-world asset tokenization) ওপর ভিত্তি করে তৈরি একটি বিকেন্দ্রীভূত মার্কেটপ্লেস। সহজ কথায়, এটি এমন একটি অবকাঠামো যা ভৌত বা প্রথাগত সম্পদগুলোকে নির্দিষ্ট মেটাডেটা এবং মালিকানা বিধি মেনে অন-চেইন (on-chain) স্থানান্তর করতে সাহায্য করে। প্ল্যাটফর্মটি ফাঙ্গিবল অ্যাসেট টোকেনাইজেশন (fungible asset tokenization) পরিচালনা করে, যার অর্থ সম্পদগুলোকে ভাগ করা, লেনদেন করা এবং প্রতিটি ইউনিটের সাথে যুক্ত স্ট্যান্ডার্ড মেটাডেটা দিয়ে ট্র্যাক করা সম্ভব।
এর ডিজাইনের কেন্দ্রে রয়েছে গোপনীয়তা (Privacy)। লেনদেনগুলো Monero-তে সম্পন্ন হয়। প্রোগামবল অ্যাসেট এবং NFT চলে Tari-তে। পুরো কার্যক্রমটি একটি Tor Onion Service-এর আড়ালে সুরক্ষিত থাকে, যা গেটওয়েটিকে সেন্সরশিপ এবং ভৌগোলিক ব্লকিং থেকে রক্ষা করে। একটি সিকিউরিটি লেয়ার Kali Linux-এ চলে এবং DeepSeek AI সিকিউরিটি বট ব্যবহার করে, যা সাধারণ লগ রোটেশনের পরিবর্তে স্বয়ংক্রিয় অনুপ্রবেশ শনাক্তকরণ (intrusion detection) বা অ্যানোমালি স্ক্যানিংয়ের ইঙ্গিত দেয়। এসক্রো (Escrow) এবং বিরোধ নিষ্পত্তি কোনো ম্যানুয়াল ব্যাক-অফিস কাজ নয়। এগুলো স্বয়ংক্রিয়ভাবে সম্পন্ন হয়, যেখানে ট্রেড কন্ডিশন কোনো সংঘাত তৈরি করলে AI মধ্যস্থতা করে।
এটি কেবল উপরিভাগ। এর গভীরে সিস্টেমটি হলো RPC এন্ডপয়েন্ট, লোকাল ডেটাবেস এবং Node.js প্রসেসের একটি জাল, যা অবশ্যই সিনক্রোনাইজড থাকতে হবে, অন্যথায় মার্কেটপ্লেস লেনদেন সম্পন্ন করা বন্ধ করে দেবে।
টেকনিক্যাল স্ট্যাক এবং কেন এটি গুরুত্বপূর্ণ
গেটওয়েটি পোর্ট 3002-এ লিসেন (listen) করে। এটি হলো প্রধান প্রবেশদ্বার। Monero-এর ওয়ালেট RPC localhost:18083-এ থাকে, যা ব্যবহারকারীর ডেটা পাবলিক চেইন অ্যানালিটিক্সে প্রকাশ না করেই প্রাইভেট ওয়ালেট অপারেশন, ব্যালেন্স কুয়েরি এবং আউটগোয়িং ট্রান্সফার পরিচালনা করে। Tari-এর RPC localhost:12820-এ রেসপন্স করে, যা প্রোগামবল অ্যাসেট লেয়ার পরিচালনা করে। যদি এই এন্ডপয়েন্টগুলোর কোনোটি বিচ্যুত হয় বা বন্ধ হয়ে যায়, তবে মার্কেটপ্লেসটি অচল হয়ে পড়বে।
MongoDB ব্যাকগ্রাউন্ডে অপারেশনাল ডেটা স্টোর হিসেবে কাজ করে। Node.js গেটওয়ে সার্ভিসটি পরিচালনা করে। ফ্রন্টএন্ড কোডটি ~/myzubster-frontend ডিরেক্টরিতে থাকে। এটি একটি ক্লাসিক বিকেন্দ্রীভূত স্ট্যাক: সেটেলমেন্টের জন্য ব্লকচেইন নোড, স্টেট সংরক্ষণের জন্য লোকাল ডেটাবেস এবং ইন্টারঅ্যাকশনের জন্য একটি পাতলা ওয়েব লেয়ার—সবই প্রাইভেসি টুলের মাধ্যমে সুরক্ষিত। এখানে কিছুই সাজসজ্জার জন্য নয়। প্রতিটি পোর্ট এবং পাথ এমনভাবে বেছে নেওয়া হয়েছে যাতে সিস্টেমটি স্বয়ংসম্পূর্ণ এবং সুরক্ষিত থাকে।
সিস্টেম চালানো
গেটওয়ে শুরু করা একটি মাত্র systemd কমান্ডের কাজ: systemctl start myzubster-gateway। এটি শুনতে খুব সহজ মনে হতে পারে, যতক্ষণ না কোনো অনাকাঙ্ক্ষিত রিবুট (reboot)-এর পর সার্ভিসটি নিঃশব্দে কাজ করা বন্ধ করে দেয়। তখন পেজিং নয়েজ ছাড়াই শেষ পঞ্চাশটি লগ লাইন দেখার জন্য আপনার প্রয়োজন হবে journalctl -u myzubster-gateway -n 50 --no-pager। সেই পঞ্চাশটি লাইনেই সাধারণত উত্তর লুকিয়ে থাকে। হতে পারে Monero RPC কানেকশন প্রত্যাখ্যান করেছে। অথবা হতে পারে সিস্টেম আপডেটের পর MongoDB আর অনলাইন ফিরে আসেনি।
সিকিউরিটি বটটি /root/security_bot.py-এ থাকে এবং python3 /root/security_bot.py দিয়ে চালু করা হয়। একটি সাধারণ সার্ভারে রুট (root) হিসেবে সিকিউরিটি স্ক্রিপ্ট চালানো সাধারণ বিষয় নয়। মনিটরিং এবং স্বয়ংক্রিয় রেসপন্সের জন্য ডেডিকেটেড একটি হার্ডেনড (hardened) Kali এনভায়রনমেন্টের মধ্যে এটি অপারেশনাল মডেলের সাথে সামঞ্জস্যপূর্ণ। DeepSeek AI ইন্টিগ্রেশন নির্দেশ করে যে বটটি কেবল লগ স্ক্যান করছে না; এটি সম্ভবত নেটওয়ার্ক আচরণ বা লেনদেনের প্যাটার্ন বিশ্লেষণ করছে কোনো ধরনের সিস্টেম কম্প্রোমাইজ হওয়ার লক্ষণ আছে কি না তা দেখার জন্য।
ফ্রন্টএন্ড কাজের জন্য এই গাইডটি অনুমানের অবকাশ পুরোপুরি দূর করে দেয়। AI জানে ঠিক কোথায় যেতে হবে: cd ~/myzubster-frontend। /var/www, /opt, বা ছড়িয়ে ছিটিয়ে থাকা হোম ডিরেক্টরিগুলোতে খোঁজাখুঁজির প্রয়োজন নেই। গাইডটি এই পাথগুলোকে সুনির্দিষ্টভাবে নির্ধারণ করে কাজের ধারাবাহিকতা নিশ্চিত করে, যা অত্যন্ত গুরুত্বপূর্ণ যখন কয়েক সপ্তাহ ধরে একাধিক সেশন বা বিভিন্ন AI ইনস্ট্যান্স একই সার্ভারে কাজ করে।
যখন সমস্যা দেখা দেয়
যখন গেটওয়েটি অচল হয়ে যায়, প্রথম পদক্ষেপ হলো প্রসেস রিকনাইসেন্স (process reconnaissance)। Node.js প্রসেসটি এখনও সচল আছে কি না তা দেখতে ps aux | grep node কমান্ডটি চালান। যদি এটি হারিয়ে যায়, তবে লগ চেক করুন। যদি লগে ডেটাবেস কানেকশন এরর দেখায়, তবে MongoDB-ই এর কারণ। systemctl start mongod দিয়ে এটি চালু করুন। অনেক বিকেন্দ্রীভূত অ্যাপ্লিকেশন ব্লকচেইন নোডগুলোকে সবচেয়ে নাজুক অংশ মনে করে, কিন্তু বাস্তবে, একটি আনক্লিন শাটডাউন (unclean shutdown) বা রুটিন প্যাকেজ আপডেটের পর লোকাল MongoDB ইনস্ট্যান্সটিই প্রায়ই প্রথম অচল হয়ে পড়ে।
Monero RPC সমস্যাগুলো ভিন্ন ধরনের প্যাটার্ন অনুসরণ করে। যদি ব্যালেন্স আপডেট হওয়া বন্ধ হয়ে যায় বা পেমেন্ট ট্রানজ্যাকশনগুলো 'pending' অবস্থায় আটকে থাকে, তবে গাইডটি monero-wallet-rpc স্ট্যাটাস চেক করার নির্দেশ দেয়। এর মানে সাধারণত হলো ওয়ালেট RPC প্রসেসটি চলছে কি না তা যাচাই করা, এটি সঠিক ডেমনের (daemon) সাথে সিঙ্ক হয়েছে কি না তা নিশ্চিত করা এবং অথেন্টিকেশন ফ্ল্যাগগুলো গেটওয়ে যা প্রত্যাশা করে তার সাথে মিলছে কি না তা নিশ্চিত করা। এখানে ট্রায়াজ (Triage) পদ্ধতি সহজ: প্রথমে ব্লকচেইন সেটেলমেন্ট লেয়ার, দ্বিতীয়ত ডাটাবেস এবং তৃতীয়ত অ্যাপ্লিকেশন। এই ক্রমটি অবহেলা করলে আপনি Node.js লগগুলোতে অহেতুক সময় নষ্ট করবেন, যখন আসল সমস্যাটি আসলে একটি মৃত (dead) RPC পোর্ট।
AI কীভাবে এই ম্যানুয়ালটি ব্যবহার করবে
গাইডটি AI-এর জন্য চারটি আচরণগত নিয়ম আরোপ করে, যা প্রোডাকশন এনভায়রনমেন্টে স্বয়ংক্রিয় অ্যাসিস্ট্যান্টরা কীভাবে ব্যর্থ হয় সে সম্পর্কে একটি গভীর ধারণা প্রকাশ করে।
প্রথমত, নির্দিষ্ট সেকশনগুলো উল্লেখ করুন। যদি ব্যবহারকারী কোনো পেমেন্ট ফেইলিওর নিয়ে সমস্যার সমাধান করার চেষ্টা করেন, তবে AI-এর উচিত স্পষ্টভাবে Monero RPC বা escrow সাবসিস্টেমের নাম বলা, যাতে ব্যবহারকারী বুঝতে পারেন ঠিক কোন জায়গায় সমস্যা হচ্ছে। দ্বিতীয়ত, সঠিক কমান্ড প্রদান করুন। ফ্ল্যাগগুলোর প্যারাফ্রেজ করবেন না বা পাথ (path) অনুমান করবেন না। তৃতীয়ত, পরবর্তী যৌক্তিক পদক্ষেপটি সাজেস্ট করুন। প্রজেক্ট রিকভারি একটি ধারাবাহিক প্রক্রিয়া; পোর্ট চেক এবং সিকিউরিটি বটগুলোর মধ্যে এলোমেলোভাবে লাফিয়ে বেড়ানো মানে মূল্যবান সময় নষ্ট করা এবং সমস্যাটিকে আরও জটিল করে তোলার ঝুঁকি নেওয়া। চতুর্থত, সার্ভিস রিস্টার্ট করার বা ডেটা ডিলিট করার আগে ব্যবহারকারীর নিশ্চিতকরণ নিন। স্বায়ত্তশাসন বা Autonomy ততক্ষণ পর্যন্ত কার্যকর যতক্ষণ না এটি ভুলবশত কোনো ওয়ালেট ক্যাশ মুছে ফেলে বা সক্রিয় ট্রেডিং চলাকালীন গেটওয়ে ডাউন করে দেয়।
একটি জীবন্ত ডকুমেন্ট
এই গাইডটি বিশেষভাবে বিবর্তিত হওয়ার জন্য ডিজাইন করা হয়েছে। MyZubster প্রজেক্ট যত বড় হবে, AI ডকুমেন্টটি আপডেট করতে থাকবে। এটি একটি ফিডব্যাক লুপ তৈরি করে যেখানে অপারেশনাল অভিজ্ঞতা প্রাতিষ্ঠানিক স্মৃতিতে (institutional memory) পরিণত হয়। একটি ছোট টিম বা একক প্রজেক্টের ক্ষেত্রে, যা বিভিন্ন টাইম জোন এবং ঘুমের চক্রে কাজ করে, এটি সেই অনানুষ্ঠানিক জ্ঞানকে প্রতিস্থাপন করে যা সাধারণত সিনিয়র ইঞ্জিনিয়ারদের মাথায় থাকে। ডকুমেন্টটি প্রতিটি আউটটেজ (outage) থেকে শিক্ষা নেয়।
আসল সারমর্ম
এই ধরণের AI প্রজেক্ট রিকভারি গাইডগুলো একটি নির্দিষ্ট এবং যন্ত্রণাদায়ক সমস্যার সমাধান করে। এগুলো কাঁচা ডকুমেন্টেশন (raw documentation) এবং প্রাসঙ্গিক বোঝার (contextual understanding) মধ্যে ব্যবধান কমিয়ে আনে। MyZubster-এর জন্য এর অর্থ হলো মার্কেটপ্লেসটি কনটেক্সট লস, রিবুট এবং টিম পরিবর্তনের মধ্যেও টিকে থাকতে পারবে। প্রতিবার নতুন সেশন শুরু হওয়ার সময় মেশিনটিকে পুরো স্ট্যাক নতুন করে শিখতে হবে না। এর শুধু ম্যানুয়ালটি পড়তে হবে, সঠিক কমান্ডগুলো অনুসরণ করতে হবে এবং কখন থামতে হবে ও প্রশ্ন করতে হবে তা জানতে হবে।
উৎস: AI Technical Guide: MyZubster Project Recovery - Daniel Ioni
ঐচ্ছিক লার্নিং কমিউনিটি: GyaanSetu AI on Telegram