১৪ অক্টো, ২০২৫·6 মিনিট
এআই উন্নয়নে সময় বাঁচায় এমন মানব রিভিউ চেকপয়েন্ট
এআই উন্নয়নে মানব রিভিউ চেকপয়েন্ট: স্কিমা, অথ, বিনাশকারী কাজ এবং ডিপ্লয় সেটিংস দ্রুত ৫-মিনিট চেক করে বড় সমস্যার হাত থেকে বাঁচান।
এআই উন্নয়নে মানব রিভিউ চেকপয়েন্ট: স্কিমা, অথ, বিনাশকারী কাজ এবং ডিপ্লয় সেটিংস দ্রুত ৫-মিনিট চেক করে বড় সমস্যার হাত থেকে বাঁচান।
AI-সহায়তায় তৈরি করা দ্রুত মনে হতে পারে। আপনি একটি ফিচার বর্ণনা করেন, একটি কাজ করা স্ক্রিন পান, এবং অ্যাপটি শেষ মনে হয়। কিন্তু ছোট বৃত্তান্তগুলো প্রায়ই এজ কেসে ব্যর্থ হয়: বাস্তব ডেটা, বাস্তব অনুমতি, বাস্তব প্রোডাকশন সেটিংস। সেই "ছোট" ত্রুটিগুলোই হিট করলেই এক সপ্তাহের ক্লিনআপে পরিণত হয়।
একটি চেকপয়েন্ট হলো আপনি কোনো পরিবর্তন গ্রহণ বা শিপ করার আগে সংক্ষিপ্ত মানব বিরতি। এটা কোনো মিটিং নয় এবং না কোনো দীর্ঘ QA সাইকেল। এটা একটি ইচ্ছাকৃত ৫-মিনিট স্ক্যান যেখানে আপনি জিজ্ঞেস করেন: যদি এটা ভুল হয়, সবচেয়ে কষ্টদায়ক কী ভেঙে পড়বে?
সবচেয়ে যন্ত্রণা দেয় এমন ক্লিনআপগুলো চারটি উচ্চ-আনুমানিক এলাকায় আসে:
একটি দ্রুত বিরতি সাহায্য করে কারণ এই সমস্যাগুলো ক্রস-কাটিং। একটি ছোট স্কিমা ভুল API, স্ক্রিন, রিপোর্ট এবং মাইগ্রেশনে ঢেউ তোলে। একটি পারমিশন ভুল সিকিউরিটি ইনসিডেন্টে পরিণত হতে পারে। একটি খারাপ ডিপ্লয় সেটিং ডাউনটাইম ঘটাতে পারে।
আপনি হাতে লিখে কোড করুন বা Koder.ai-এর মতো ভাইব-কোডিং টুল ব্যবহার করুন, নিয়ম একই: দ্রুত অগ্রসর হন, কিন্তু যেখানে ক্ষতি বড় সেখানে ছোট গার্ডরেইল যোগ করুন।
চেকপয়েন্টগুলো সবচেয়ে ভাল কাজ করে যখন সেগুলো নিয়মিত। সবকিছু রিভিউ করবেন না। কেবল সেই জিনিসগুলো রিভিউ করুন যা উল্টো পাল্টা করা ব্যয়বহুল।
ট্রিগার মুহূর্তগুলো বেছে নিন: একটি ফিচার শেষ করার পরে, ডিপ্লয় করার ঠিক আগে, এবং এমন কোনো রিফ্যাক্টরের ঠিক পরে যা ডেটা, অথ, বিলিং বা প্রোডাকশন-ফেসিং কিছুটা স্পর্শ করেছে।
টাইমার ৫ মিনিট সেট করুন। সময় শেষ হলে থামুন। যদি আপনি বাস্তব ঝুঁকি পান, একটি বড়ো অনুসরণ সূচি নির্ধারণ করুন। না হলে আত্মবিশ্বাস নিয়ে শিপ করুন।
একজন রিভিউয়ার ভূমিকা নিয়োগ করুন, এমনকি যদি সেটা "ভবিষ্যতের আপনি" হয়। এমন ভেবে কাজ করুন যেন আপনি এটি একটি সহকর্মীর কাছে অনুমোদন করছেন যাকে আপনি পরে বির্য করতে পারবেন না।
একটি ছোট টেমপ্লেট আপনাকে ধারাবাহিক থাকতে সাহায্য করবে:
Change:
Risky areas touched:
1 quick test to run:
Decision (proceed / adjust prompt / rollback):
আপনি যদি Koder.ai-এ নির্মাণ করছেন, উদ্দেশ্যটা শেষ ধাপে সহজ রাখুন। স্ন্যাপশট এবং রোলব্যাক "আমি নিশ্চিত নই" কে একটি নিরাপদ সিদ্ধান্তে পরিণত করে।
দিন হারানোর দ্রুততম উপায় হলো এমন একটি ডাটাবেস স্কিমা মেনে নেওয়া যা কেবল "মোটামুটি" আপনার ইচ্ছে মত মেলে। ছোট ডেটা ভুলগুলো প্রতিটি স্ক্রীন, API এবং মাইগ্রেশনে ছড়িয়ে পড়ে।
শুরুতে দেখুন মূল এন্টিটিগুলো বাস্তব বিশ্বের সাথে মেলে কি না। একটি সাধারণ CRM সাধারণত Needs: Customers, Contacts, Deals, এবং Notes। যদি আপনি অস্পষ্ট নাম দেখেন যেমন "ClientItem" বা "Record", আপনি ইতোমধ্যেই ভ্রান্ত পথে যাচ্ছেন।
একটি পাঁচ-মিনিট স্কিমা স্ক্যান:
একটি ছোট উদাহরণ: একটি Invoices টেবিল যদি unique invoice_number ছাড়া থাকে ডেমোতে ঠিক মনে হতে পারে। এক মাস পরে ডুপ্লিকেট উঠবে, পেমেন্ট ভুল রেকর্ডে পড়বে, এবং আপনি ক্লিনআপ স্ক্রিপ্ট ও ক্ষমাসূচক ইমেল লিখতে বসবেন। রিভিউতে ধরলে এটা ৩০ সেকেন্ডেই ঠিক করা যায়।
যদি আপনি কেবল একটি প্রশ্ন জিজ্ঞেস করেন, এটি করুন: আপনি কি এই স্কিমা একটি নতুন সহকর্মীর সামনে দুই মিনিটে বুঝিয়ে দিতে পারবেন? যদি না পারেন, তার উপর নির্মাণ করার আগে সেটাকে শক্ত করুন।
Auth বাগগুলো ব্যয়বহুল কারণ সুখপথ (happy-path) ডেমো সেগুলো লুকায়। দুটি সাধারণ ব্যর্থতা হলো "সবাই সব কিছুই করতে পারবে" এবং "কেউ কিছুই করতে পারবে না"।
রোলগুলো সহজ ভাষায় লিখুন: admin, staff, customer। অ্যাপ যদি টিম ধরে চলে, তাহলে workspace member এবং workspace owner যোগ করুন। যদি আপনি এক বাক্যে একটি রোল ব্যাখ্যা করতে না পারেন, নিয়মগুলো ছড়িয়ে যাবে।
তারপর একটি নিয়ম প্রয়োগ করুন: ডিফল্টভাবে কম অধিকার। নতুন রোলগুলো শুরু হোক কোনো এক্সেস ছাড়া বা কেবল readonly থেকে এবং ঠিক যা দরকার তা পেয়েই বাড়ুক। AI-জেনারেটেড কোড প্রায়ই পারমিশিভ শুরু করে কারণ তা টেস্ট পাস করায়।
দ্রুত যাচাই করতে একটি ছোট access matrix ব্যবহার করুন এবং UI ও API-তে সত্যিই চেষ্টা করে দেখুন:
Ownership চেকগুলো বিশেষ নজর দাবি করে। "User can read Task" যথেষ্ট নয়। হওয়া উচিত: "user can read Task where task.ownerId == user.id" (বা ব্যবহারকারী ওয়ার্কস্পেসে আছে)।
এজ কেসগুলোই লিকের স্থান: আমন্ত্রিত কিন্তু গ্রহণ না করা ব্যবহারকারী, ডিলিট করা অ্যাকাউন্ট, পুরানো সেশন সহ সরানো ওয়ার্কস্পেস মেম্বার। একটি মিস হওয়া এজ কেসই এক সপ্তাহের ক্লিনআপে পরিণত হতে পারে।
আপনি যদি Koder.ai ব্যবহার করেন, অ্যাসিস্ট্যান্টকে রোলসমূহ এবং একটি access table আউটপুট করতে বলুন এবং তারপর প্রতিটি রোলের জন্য দুইটি টেস্ট অ্যাকাউন্ট দিয়ে যাচাই করুন।
বিনাশকারী অ্যাকশনগুলো ছোট ভুল থেকে কয়েক দিনের ক্লিনআপ পর্যন্ত যাওয়ার দ্রুততম পথ।
প্রথমে, এমন সবকিছু তালিকাভুক্ত করুন যা ডেটা মুছে বা ওভাররাইট করে। এটা কেবল delete বোতাম নয়। এটা reset, sync, import/replace, rebuild index, seed অ্যাকশন, এবং বিস্তৃত অ্যাডমিন টুলস।
কিছু স্পষ্ট সেফটি সিগন্যাল খুঁজুন:
অধিকাংশ ইউজার-জেনারেটেড ডেটার জন্য soft delete প্রেফার করুন। একটি সহজ deleted_at ফিল্ড এবং ফিল্টারিং মুছে ফেলা সম্ভব করে এবং যদি পরে কোনো বাগ দেখা দেয় তাহলে সময় দেয় উল্টো করার জন্য।
স্কিমা পরিবর্তনকেও সম্ভাব্য বিনাশকারী হিসেবে বিবেচনা করুন। কলাম ড্রপ করা, টাইপ বদলানো, এবং কনস্ট্রেইন্ট কষাকষি করা ডেটা হারিয়ে দিতে পারে এমনকি কেউ ডিলিট এন্ডপয়েন্ট কল না করলেও। যদি AI একটি মাইগ্রেশন প্রস্তাব করে, জিজ্ঞেস করুন: বিদ্যমান সারিগুলোর কি হবে, এবং কীভাবে আমরা তা পুনরুদ্ধার করব?
আপনি যদি রোলব্যাক প্ল্যান এক বাক্যে ব্যাখ্যা করতে না পারেন, তাহলে সেই বিনাশকারী পরিবর্তন শিপ করবেন না।
বেশিরভাগ ক্লিনআপ স্টোরি একইভাবে শুরু হয়: ডেভে অ্যাপ কাজ করেছে, তারপর প্রোডাকশন আলাদা আচরণ করল।
ডেভ ও প্রোড আলাদা রাখুন উদ্দেশ্যপ্রণোদিতভাবে: আলাদা ডাটাবেস, কীগুলো, বকেট ও ইমেল প্রোভাইডার। যদি দুইটি পরিবেশ একই ডাটাবেস দেখায়, একটি টেস্ট স্ক্রিপ্ট বাস্তব ডেটা দূষিত করতে পারে, এবং একটি "দ্রুত রিসেট" সব মুছে ফেলতে পারে।
তারপর সিক্রেটগুলো দেখুন। যদি আপনি কনফিগ ফাইলে, প্রম্পটে, বা কমিট মেসেজে কী দেখেন, ধরে নিন তা লিক হবে। সিক্রেটগুলো ডেপ্লয় টাইমে ইনজেক্ট করা উচিত (env vars বা সিক্রেট ম্যানেজার)। প্রোডাকশনকে যদি প্রয়োজনীয় সিক্রেট মিস করে স্টার্ট না করতে পারে, তাহলে সেটা একটি খরচবহুল নীরব fallback-এর চেয়ে সস্তা ব্যর্থতা।
তারপর ব্রাউজার-ফেইসিং সেটিংস চেক করুন: allowed origins (CORS), redirect URLs, OAuth callback URLs। এগুলো প্রায়ই প্রায় সঠিক করা হয়, এবং এভাবেই আপনি কোড ঠিক থাকলেও "ব্রোকেন লগইন" ডিবাগ করতে বসেন।
একটি পাঁচ-মিনিট ডিপ্লয়মেন্ট চেক:
আপনি যদি Koder.ai থেকে ডিপ্লয় করেন, এও নিশ্চিত করার সময় যে আপনি সঠিক পরিবেশ ডিপ্লয় করেছেন এবং রোলব্যাক উপলব্ধ আছে যদি কোনো কিছু ঠিক না লাগে।
AI-জেনারেটেড পরিবর্তন গ্রহণ করে শিপ করার আগে এক মিনিট বিরতি নিন। আপনি স্টাইল রিভিউ করছেন না। আপনি তাদের ভুল খুঁজছেন যা বড় ক্লিনআপে পরিণত হয়।
একটি উদাহরণ: আপনি একটি "admin delete user" ফিচার মার্জ করেন। ৬০ সেকেন্ডে আপনি লক্ষ্য করবেন ব্যাকএন্ডে কোন রোল চেক নেই, কেবল একটি গোপন UI বাটন আছে। এক বাস্তব ব্যবহারকারী সরাসরি এন্ডপয়েন্ট কল করলেই এমনটি ঘটতে পারে। সেই এক টুকরা কেবল আপনার একটা ইনসিডেন্ট থেকে বাঁচায়।
একটি প্রশ্ন দিয়ে শেষ করুন যা বাস্তবতা জোর করে:
এখানে একটি বাস্তব ব্যবহারকারী খারাপভাবে কি করতে পারে, জানি বা ভুল করে?
যদি উত্তরটিতে থাকে “অন্যদের ডেটা মুছে ফেলা”, “প্রাইভেট রেকর্ড দেখা”, বা “প্রোডাকশন ভাঙা”, তাহলে থামুন এবং পরিবর্তনটা শক্ত করুন।
আপনি একটি ছোট CRM নির্মাণ করছেন এবং AI টুলকে একটি "Delete customer" বাটন যোগ করতে বলেন। কয়েক মিনিটে এটা UI, একটি ব্যাকএন্ড এন্ডপয়েন্ট, এবং সম্পর্কিত রেকর্ড মুছে ফেলার জন্য একটি ডাটাবেস পরিবর্তন জেনারেট করে।
সবকিছু কাজ করছে মনে হয়: বাটন দেখা যায়, রিকোয়েস্ট 200 রিটার্ন করে, এবং কাস্টোমার লিস্ট থেকে মুছে যায়। অনেক দল এগিয়ে চলে।
একটি ৫-মিনিট রিভিউ দুইটি সমস্যা ধরেছে:
একটি দ্রুত রিভিউ বাস্তবে করায়:
একটি প্রম্পট টুইক শিপ হওয়ার আগে এটা ঠিক করে দেয়:
“Make delete customer a soft delete. Keep invoices and logs. Only admins can delete. Add a confirmation step that requires typing DELETE. Return a clear error message when unauthorized.”
পুনরাবৃত্তি এড়াতে প্রকল্প নোটে তিনটি জিনিস ডকুমেন্ট করুন: delete নিয়ম (soft vs hard), permission requirement (who can delete), এবং প্রত্যাশিত সাইড ইফেক্টগুলো (কোন সম্পর্কিত ডেটা থাকে)।
AI আউটপুট আত্মবিশ্বাসী শোনায় কিন্তু অনুমান লুকিয়ে রাখতে পারে। লক্ষ্য হলো সেই অনুমানগুলো দৃশ্যমান করা।
যেসব শব্দগুলো ফলো-আপ প্রশ্ন ট্রিগার করা উচিত: “assume”, “default”, “simple”, “should”, “usually”. এগুলো প্রায়ই মানে “আমি কিছু বেছে নিয়েছি নিশ্চিত না হয়ে যে এটা আপনার অ্যাপের জন্য ঠিক আছে।”
উপযোগী প্রম্পট প্যাটার্ন:
“Rewrite your proposal as acceptance criteria. Include: required fields, error states, and 5 edge cases. If you made assumptions, list them and ask me to confirm.”
আর দুটি প্রম্পট যা ঝুঁকি দ্রুত উন্মোচন করে:
Auth-এর জন্য:
“Show roles and permissions for each API route and UI action. For every role: allowed actions, denied actions, and one example request that should fail.”
নির্ধারণ করুন কী সবই মানব-ভেরিফাই করা উচিত, এবং তা সংক্ষিপ্ত রাখুন:
বেশিরভাগ দীর্ঘ ক্লিনআপ একই ছোট সিদ্ধান্ত থেকে শুরু হয়: আউটপুটকে বিশ্বাস করা কারণ এটা এখন কাজ করছে।
“It works on my machine” হলো ক্লাসিক ফাঁদ। একটি ফিচার লোকাল টেস্ট পাস করলেও বাস্তব ডেটা সাইজ, বাস্তব পারমিশন বা একটু আলাদা পরিবেশে ব্যর্থ হতে পারে। ফিক্সটি জরুরি প্যাচগুলোর গচ্ছে পরিণত হয়।
স্কিমা ড্রিফট আরেকটি চুম্বক। টেবিলগুলো নাম, কনস্ট্রেইন্ট এবং ডিফল্ট ছাড়া বিকশিত হলে এক-অফ মাইগ্রেশন ও অদ্ভুত ওয়ার্কঅ্যারাউন্ড তৈরি হয়। পরে কেউ জিজ্ঞেস করলে “status মানে কী?” আর কেউ উত্তর দিতে পারছে না।
অথ পরে যোগ করলে কষ্টদায়ক কারণ এটা অনুমানগুলো পুনর্লিখে দেয়। যদি আপনি সবকিছু এমনভাবে তৈরি করেন যেন প্রতিটি ব্যবহারকারী সব কিছুই করতে পারে, আপনি সপ্তাহগুলো ব্যয় করবেন এলোমেলো এন্ডপয়েন্ট ও স্ক্রিনে ছিদ্র塞 করতে।
বিনাশকারী অ্যাকশন সবচেয়ে বড় দূর্ঘটনা ঘটায়। “Delete project” বা “reset database” সহজে বাস্তবায়নযোগ্য এবং সহজে অনুতপ্ত হয়ে যায় যদি soft delete, স্ন্যাপশট বা রোলব্যাক প্ল্যান না থাকে।
কয়েকটি পুনরাবৃত্ত কারণ যা বহু-দিনের ক্লিনআপ দেয়:
চেকপয়েন্টগুলো স্থায়ী করতে সহজ পথ হলো সেগুলোকে ইতোমধ্যে থাকা মুহূর্তগুলোর সাথে যুক্ত করা: ফিচার শুরু করা, মার্জ করা, ডিপ্লয় করা এবং যাচাই করা।
একটি হালকা রিদম:
আপনি যদি Koder.ai-এ কাজ করেন, এর planning mode “নির্মাণের আগে” চেকপয়েন্ট হিসেবে কাজ করতে পারে: পরিবর্তন জেনারেট করার আগে সিদ্ধান্তগুলো লেখে রাখুন যেমন “orders শুধুমাত্র সাইন-ইন করা ব্যবহারকারী তৈরি করতে পারবে, কিন্তু status পরিবর্তন শুধুমাত্র অ্যাডমিনই করতে পারবে।” স্ন্যাপশট ও রোলব্যাকও নিশ্চিত করে যে “আমি নিশ্চিত নই” হওয়াই রিভার্ট করার কারণ হতে পারে, তারপর একটি পরিষ্কার প্রম্পট দিয়ে পুনরায় জেনারেট করুন।
পাঁচ মিনিট সবকিছু ধরবে না। তবে এটা ব্যয়বহুল ভুলগুলো যখন সস্তা অবস্থায় থাকে তখনই স্থায়ীভাবে ধরতে দেয়।
দৈবক্রমে জেনারেট করা কোনো ফিচার তৈরি হওয়ার ঠিক পরে, ডিপ্লয়মেন্টের ঠিক আগে, এবং যেকোনো পরিবর্তনের পরে যা ডেটা, auth, বিলিং বা প্রোডাকশন সেটিংসে স্পর্শ করে — এই মুহূর্তগুলোতে চেকপয়েন্ট ব্যবহার করুন। এই মুহূর্তগুলোই সবচেয়ে বড় "ব্লাস্ট রেডিয়াস" থাকে, তাই ছোট রিভিউ দামী ভুলগুলো আগেভাগে ধরতে সাহায্য করে।
কঠোর থাকতে হবে: ৫ মিনিট টাইমার সেট করুন এবং প্রতি বার একই ধাপ অনুসরণ করুন। চেঞ্জটি এক বাক্যে নাম দিন, এটা কি স্পর্শ করে (ডেটা, রোল, পরিবেশ), চারটি ঝুঁকিপূর্ণ ক্ষেত্র স্ক্যান করুন, একটি সহজ বাস্তব-পরীক্ষা চালান, তারপর সিদ্ধান্ত নিন: এগোনো, প্রম্পট সমন্বয় ও পুনরায় জেনারেট, অথবা রোলব্যাক।
কারণ সমস্যা ক্রস-কাটিং হয়। একটি ছোট স্কিমা ত্রুটি API, স্ক্রিন, রিপোর্ট এবং মাইগ্রেশনে ছড়িয়ে পড়ে, এবং পরে ঠিক করা মানে একাধিক স্তর পুনর্লিখন করে খরচ বাড়ে। পরিবর্তনের সময় ধরলেই এটা সাধারণত দ্রুত ঠিক করা যায়—বড় ক্লিনআপের বদলে এক ছোট সম্পাদনা।
পরীক্ষা করুন যে টেবিল ও ফিল্ডগুলো বাস্তব বিশ্ব ধারণাকে প্রতিফলিত করে, নামগুলো ধারাবাহিক ও পাঠযোগ্য, সম্পর্কগুলো সম্পূর্ণ (যেখানে প্রযোজ্য one-to-many বা many-to-many), এবং কনস্ট্রেইন্টগুলো ইচ্ছাকৃত (not null, unique, foreign keys)। সাধারণ লুকআপগুলোর জন্য ইনডেক্সও চেক করুন যাতে ডেটা বাড়লেও পারফরম্যান্স ভেঙে না পড়ে।
ধরা নিন UI মিথ্যাচার করছে এবং ব্যাকএন্ড নিয়মগুলো পরীক্ষা করুন। রোলগুলো স্পষ্ট ভাষায় লিখুন, ডিফল্টভাবে least access রাখুন, এবং ownership চেকগুলো সার্ভার-সাইডে যাচাই করে দেখুন — উদাহরণস্বরূপ অন্য কারো রেকর্ড অ্যাক্সেস করার চেষ্টা করে আইডি বদলে দেখুন। তালিকা/সার্চ/ডাউনলোড এন্ডপয়েন্টগুলোও মিস করা না উচিত।
যে কোনো অপারেশন যে ডেটা মুছে বা ওভাররাইট করতে পারে—ডিলিট, রিসেট, ইমপোর্ট/রিপ্লেস, সিঙ্ক, রিবিল্ড ইনডেক্স, সিড অ্যাকশন এবং বিস্তৃত অ্যাডমিন টুলস—এইগুলোকে গুণে দেখুন। বিপজ্জনক অপারেশনের জন্য স্পষ্ট কনফার্মেশন (type-to-confirm উত্তম), সীমিত স্কোপ, ট্রিগারকারী ব্যক্তি লগ করা এবং ডিফল্ট হিসেবে ড্রাই-রান/প্রিভিউ বা আর্কাইভ প্রেফার করুন।
বহু ব্যবসায়িক ডেটার জন্য ডিফল্টভাবে soft delete ব্যবহার করুন যাতে দুর্ঘটনাবশত মুছে গেলে ফিরে পাওয়া যায় এবং বাগ তদন্ত করা যায়। যেখানে সত্যিই স্থায়ী অপসারণের দরকার সেখানে hard delete ব্যবহার করুন এবং শিপ করার আগে এক বাক্যে recovery প্ল্যান বুঝিয়ে দিন।
ডেভ ও প্রোড আলাদাভাবে রাখুন: আলাদা ডাটাবেস, কী, বকেট ও ইমেল প্রোভাইডার। সিক্রেটগুলো কনফিগে বা প্রম্পটে টাইপ না করে ডেপ্লয়মেন্ট-টাইমে ইনজেক্ট করুন (env vars বা সিক্রেট ম্যানেজার)। CORS, redirect এবং OAuth callback গুলো সঠিক ডোমেইনের সাথে মিলেছে কি তা নিশ্চিত করুন। প্রোডাকশনে লগিং ও error reporting চালু রাখুন কিন্তু সংবেদনশীল ডেটা লগ না করার বিষয়টি নিশ্চিত করুন।
একটি সেফেটি নেট হিসেবে বিবেচনা করুন, না যে চিন্তার বদলে দেবে। ঝুঁকিপূর্ণ পরিবর্তনের আগে স্ন্যাপশট নিয়ে রাখুন এবং যদি রিভিউতে বাস্তব ঝুঁকি পাওয়া যায় তাৎক্ষণিকভাবে রোলব্যাক করে নিন। এরপর একটি পরিষ্কার প্রম্পট দিয়ে পুনরায় জেনারেট করুন যাতে মিসিং কনস্ট্রেইন্ট, রোল চেক বা কনফার্মেশন যোগ করা থাকে।
এটা একটি এক-মিনিট স্ক্যান: স্কিমা স্পষ্ট ও কনস্ট্রেইন্ট সহ আছে কি, auth ডিফল্ট-ডিনাই কি এবং সার্ভার-সাইড চেক আছে কি, বিপজ্জনক অ্যাকশনের জন্য কনফার্মেশন ও রিকভারি আছে কি, এবং ডেভ/প্রোড আলাদা আছে কি। শেষের প্রশ্নটি জিজ্ঞেস করুন: বাস্তবে একজন ব্যবহারকারী এখানে সবচেয়ে খারাপ কি করতে পারে? যদি উত্তরটি অন্যের ডেটা মুছে ফেলা, প্রাইভেট রেকর্ড দেখা বা প্রোডাকশন ভাঙা থাকে, থামুন এবং শক্ত করুন।