Lovable বা Bolt বাগ-ফিক্সের লুপে আটকে গেছে? কীভাবে আপনার MVP শেষ করবেন

আপনি বিল্ডারকে সাইন-ইন ঠিক করতে বললেন। সেটা কাজ করল, কিন্তু এখন ড্যাশবোর্ড খালি। আরেকটি প্রম্পট ড্যাশবোর্ড ফিরিয়ে আনল এবং আবার সাইন-ইন ভেঙে দিল। যদি Lovable বা Bolt একই বাগ বারবার ঠিক করতে গিয়ে আটকে থাকে, তবে পরবর্তী কাজের ধাপ হলো একটি ব্যর্থতার চারপাশের প্রমাণ উন্নত করা। বেশি পরিবর্তন মানেই স্বয়ংক্রিয়ভাবে বেশি অগ্রগতি নয়।

AI অ্যাপ কেন ফিক্স লুপে আটকে যায়?

ফিক্স লুপ তখন তৈরি হয় যখন পরিবর্তনগুলো মূল কারণ নির্ণয় ও পরীক্ষা না করে শুধু দৃশ্যমান উপসর্গ সামলায়। একাধিক ভিন্ন ত্রুটি একই স্ক্রিন তৈরি করতে পারে, তাই একটি বিস্তৃত অনুরোধ বিল্ডারকে পরিবর্তন করার মতো অনেক বেশি সম্ভাব্য জিনিস দিয়ে দেয়।

খালি ড্যাশবোর্ডের মানে হতে পারে একটি ব্যর্থ রিকোয়েস্ট, একটি পারমিশন পলিসি, ভুল ডেটাবেস, অথবা সত্যিই ডেটা নেই। কম্পোনেন্ট বদলালে বার্তাটি লুকিয়ে যেতে পারে, অথচ ব্যর্থ রিকোয়েস্টটি অপরিবর্তিত থেকে যায়। আপনার লক্ষ্য হলো কোন সীমানায় ব্যর্থতা ঘটেছে তা চিহ্নিত করা: ব্রাউজার, সার্ভার, অথেনটিকেশন প্রোভাইডার, ডেটাবেস, নাকি বাইরের কোনো ইন্টিগ্রেশন।

একটি ব্যবহারিক থামার নিয়ম ঠিক করুন: একটি নির্দিষ্ট রিপেয়ার চেষ্টার পরও যদি একই উপসর্গ ফিরে আসে, তবে প্রম্পট পুনরাবৃত্তি বন্ধ করুন এবং ভিন্ন ধরনের প্রমাণ সংগ্রহ করুন। এটি একটি কাজের অভ্যাস, কোনো নথিভুক্ত প্ল্যাটফর্ম সীমা নয়। এটি একটি ছোট প্রজেক্টকে এমন অবস্থা থেকে রক্ষা করে যেখানে অসম্পর্কিত পরিবর্তন জমতে থাকে অথচ কেউ ব্যাখ্যা করতে পারে না কী ব্যর্থ হচ্ছে।

বিল্ডার প্রিভিউ ভেঙেছে, নাকি আপনার অ্যাপ?

কোড নতুন করে লেখার আগে বিল্ডার পরিবেশটি আপনার অ্যাপ্লিকেশন থেকে আলাদাভাবে পরীক্ষা করুন। প্ল্যাটফর্মের কোনো ঘটনা বা প্রিভিউ সংযোগের সমস্যা এই প্রমাণ নয় যে আপনার প্রোডাক্টের আর্কিটেকচার বদলাতে হবে।

Bolt-এর বর্তমান প্রিভিউ ট্রাবলশুটিং গাইড সার্ভিস স্ট্যাটাস দেখা, ব্রাউজার-কনসোলের ত্রুটি সংগ্রহ করা, একটি প্রোডাকশন বিল্ড চেষ্টা করা এবং অনুপস্থিত এনভায়রনমেন্ট ভেরিয়েবল পর্যালোচনা করার পরামর্শ দেয়। এটি আরও ব্যাখ্যা করে যে প্রথম ব্যর্থ চেষ্টার পর একই প্রিভিউ-রিপেয়ার প্রম্পট বারবার জমা দিলে সাহায্য হওয়ার সম্ভাবনা কম।

এই টেবিলটি পরবর্তী অনুসন্ধান বেছে নিতে ব্যবহার করুন, রোগনির্ণয় ঘোষণা করতে নয়। একটি ব্যর্থ নেটওয়ার্ক রিকোয়েস্টের উৎস তবুও অ্যাপ্লিকেশন কোড হতে পারে, আর একটি ফাঁকা স্ক্রিনের একাধিক কারণ থাকতে পারে। পরের ব্যর্থতাগুলো চাপা দেওয়ার আগেই প্রথম অর্থবহ ত্রুটিটি ধরে রাখুন।

আরেকটি ফিক্স চেষ্টার আগে কী সংরক্ষণ করবেন?

সবচেয়ে সাম্প্রতিক কাজের কোড-অবস্থা সংরক্ষণ করুন এবং কোন ডেটা একটি রিপেয়ারে প্রভাবিত হতে পারে তা চিহ্নিত করুন। কোড হিস্টরি আর ডেটাবেস ব্যাকআপ ভিন্ন ভিন্ন পুনরুদ্ধার সমস্যার সমাধান করে।

Lovable-এর ভার্সন হিস্টরি ডকুমেন্টেশন কোড ভার্সন প্রিভিউ, বুকমার্ক ও রিভার্ট করার পদ্ধতি বর্ণনা করে। এতে স্পষ্টভাবে বলা আছে যে কোড রিভার্ট করলে ডেটাবেসের ডেটা ফিরে যায় না। কোনো ভার্সন রিস্টোর করার আগে দেখে নিন পরবর্তী কাজ রেকর্ড, পারমিশন বা সেই স্কিমা বদলেছে কি না, যা পুরোনো কোড প্রত্যাশা করে।

1. শেষ যে অবস্থায় মূল জার্নিটি কাজ করত, সেটির নাম দিন, টাইমস্ট্যাম্প বা কমিট আইডেন্টিফায়ারসহ।
2. বর্তমান ব্যর্থতাটি লিখে রাখুন এবং আপনার প্রজেক্টের সমর্থিত ওয়ার্কফ্লো দিয়ে কাজের যেকোনো আনকমিটেড পরিবর্তন সংরক্ষণ করুন।
3. ডেটা বা স্কিমা বদলায় এমন কাজের আগে একটি উপযুক্ত ডেটাবেস ব্যাকআপ বা নিরাপদ টেস্ট কপি তৈরি করুন।
4. কোন প্রজেক্ট ও এনভায়রনমেন্টে লাইভ ব্যবহারকারী আছে তা লিখে রাখুন, যাতে রিপেয়ারটি তাদের থেকে দূরে পরীক্ষা করা যায়।

একটি কাজের রিপেয়ার প্রম্পট দেখতে কেমন?

একটি কাজের রিপেয়ার প্রম্পট একটি পুনরুৎপাদনযোগ্য ব্যর্থতার নাম দেয়, প্রাসঙ্গিক প্রমাণ দেয় এবং প্রস্তাবিত পরিবর্তনকে সীমিত রাখে। যে ইমপ্লিমেন্টেশন আপনি মূল্যায়ন করতে পারবেন না, তা অনুমোদনের আগে কারণের ব্যাখ্যা চান।

Investigate one issue: a signed-in customer cannot save a booking.
Steps: create a fresh customer account, open /bookings/new, choose a date, and select Save.
Expected: one booking is saved and appears after refresh.
Actual: the request returns 403 and no booking is saved.
Evidence: [sanitized error, request path, and timestamp].
First explain the likely cause and the files or policies involved.
Do not change roles, remove access checks, redesign screens, or rewrite unrelated features.
Propose the smallest fix and how to test it with two ordinary accounts.

এই উদাহরণটি কাল্পনিক। এর বিবরণগুলো আপনি আসলে যা দেখেছেন তা দিয়ে বদলে নিন। একটি 403 রেসপন্স অ্যাক্সেস ব্যর্থতার একটি সূত্র; এটি অথরাইজেশন সরিয়ে দেওয়ার অনুমতি নয়। পাসওয়ার্ড, টোকেন, কানেকশন স্ট্রিং এবং গ্রাহকের রেকর্ড প্রম্পট ও স্ক্রিনশটের বাইরে রাখুন।

Lovable প্রজেক্টের ক্ষেত্রে, ব্যাকএন্ড লগ গাইড ব্যাখ্যা করে কীভাবে আপনার প্রজেক্টে উপলব্ধ সার্ভিসগুলো জুড়ে রিকোয়েস্ট ও ত্রুটি পরীক্ষা করবেন। ত্রুটিকে অ্যাকশনের সময় ও এনভায়রনমেন্টের সঙ্গে মিলিয়ে নিন। একটি বড়, ফিল্টার-না-করা লগ ডাম্পের চেয়ে একটি প্রাসঙ্গিক, সংবেদনশীল তথ্য-মুছে-ফেলা এন্ট্রি অনেক বেশি কাজের।

রিপেয়ার সত্যিই কাজ করেছে কি না কীভাবে বুঝবেন?

একটি রিপেয়ার তখনই কাজ করে যখন মূল ধাপগুলো প্রত্যাশিত ফল দেয় এবং গুরুত্বপূর্ণ আশেপাশের ফ্লোগুলো এখনও সঠিকভাবে চলে। শুধু সাময়িক সাফল্য-বার্তা নয়, রিফ্রেশের পর সংরক্ষিত অবস্থাও পরীক্ষা করুন।

1. একটি নতুন অ্যাকাউন্ট ও একই ইনপুট দিয়ে মূল ব্যর্থতাটি আবার করুন।
2. অ্যাপটি রিফ্রেশ করুন বা আবার খুলুন এবং নিশ্চিত করুন যে ফলাফল সঠিকভাবে সংরক্ষিত হয়েছে।
3. দ্বিতীয় একটি সাধারণ অ্যাকাউন্ট দিয়ে পুনরাবৃত্তি করুন এবং উদ্দিষ্ট মালিকানার সীমানা যাচাই করুন।
4. একটি নিরাপদ টেস্ট এনভায়রনমেন্টে একটি ব্যর্থতার কেস চেষ্টা করুন, যেমন অবৈধ ইনপুট বা বাধাগ্রস্ত রিকোয়েস্ট।
5. পরিবর্তিত কোড ব্যবহার করে এমন আশেপাশের ফ্লোগুলো পরীক্ষা করুন, তারপর প্রজেক্টের প্রাসঙ্গিক চেক ও প্রোডাকশন বিল্ড চালান।

কখন একজন ডেভেলপারকে আনবেন?

যখন কোনো গুরুত্বপূর্ণ পথের পরিবর্তন আপনি আত্মবিশ্বাসের সঙ্গে ব্যাখ্যা বা যাচাই করতে পারছেন না, অথবা একটি নির্দিষ্ট অনুসন্ধানের পরও কারণ আলাদা করা যাচ্ছে না, তখন একজন ডেভেলপার আনুন। পেমেন্ট অ্যাক্সেস, এক অ্যাকাউন্টের ডেটা অন্য অ্যাকাউন্টে উন্মুক্ত হওয়া এবং বারবার ডেটাবেস পরিবর্তনের ক্ষেত্রে বিশেষ সতর্কতা প্রয়োজন।

একটি সীমিত রিভিউ জানাতে পারে সমস্যাটি কনফিগারেশনের, ছোট কোনো ইমপ্লিমেন্টেশন ত্রুটির, নাকি বড় কোনো ডিজাইনগত সমস্যার। রোগনির্ণয়, যে ফাইল বা সার্ভিস বদলানোর প্রস্তাব, গ্রহণযোগ্যতা পরীক্ষা এবং রোলব্যাক পদ্ধতি চেয়ে নিন। রিবিল্ডে সম্মত হওয়ার আগেই আপনি এমন একটি রিভিউ করাতে পারেন।

একটি ভালো হ্যান্ডওভারে থাকে অ্যাপের URL, সমর্থিত প্রজেক্ট বা রিপোজিটরি অ্যাক্সেস, পুনরুৎপাদনের ধাপ, একটি ছোট স্ক্রিন রেকর্ডিং, সংবেদনশীল তথ্য-মুছে-ফেলা ত্রুটি এবং শেষ কাজ-করা ভার্সন। পরবর্তী গ্রাহক-মাইলস্টোন এবং যে ফিচারগুলো অক্ষত থাকতে হবে, সেগুলোও যোগ করুন। ক্রেডেনশিয়াল শুধু উপযুক্ত সিক্রেট-শেয়ারিং বা অ্যাকাউন্ট-অ্যাক্সেস প্রক্রিয়ার মাধ্যমেই শেয়ার করুন।

আপনার পরবর্তী রিলিজে কী থাকা উচিত?

আপনার পরবর্তী রিলিজে ভাঙা জার্নিগুলোর একটি ছোট, পরিমাপযোগ্য সেট বন্ধ করা উচিত। প্রকাশিত অ্যাপে ওই জার্নিগুলো পরীক্ষা না হওয়া পর্যন্ত ফিচার অনুরোধগুলো আলাদা রাখুন।

রিপেয়ারের পর আশেপাশের ঘাটতিগুলো চিহ্নিত করতে ১২-পয়েন্টের MVP লঞ্চ পরিকল্পনা ব্যবহার করুন। যদি অ্যাপ প্রিভিউতে কাজ করে কিন্তু Replit-এ প্রকাশ করলে ভেঙে যায়, তবে Replit ডেপ্লয়মেন্ট চেকলিস্ট ব্যবহার করুন। সরাসরি সহায়তার জন্য Lovable বা Bolt পেজে আপনার শুরুর জায়গা বেছে নিন এবং একটি কল বুক করুন। ব্যর্থ ফ্লোটি সঙ্গে আনুন; প্রথম আলোচনাটি একটি কাজের পরবর্তী ধাপ নির্ধারণে সাহায্য করবে।