Lovable چیست؟ ساخت MVP امن و انتقال کد به GitHub

ابزارهای ساخت اپ با هوش مصنوعی فاصله ایده تا نمونه قابل‌کلیک را کوتاه کرده‌اند. Lovable می‌تواند با توضیح متنی، رابط کاربری و بخش‌هایی از منطق یک برنامه وب را بسازد، تغییر دهد و منتشر کند. اما خروجی سریع زمانی ارزشمند است که مسئله درست تعریف شده باشد، داده آزمایشی از داده واقعی جدا بماند و تیم مالک کد و تصمیم‌های امنیتی باشد.

در این راهنما یک MVP برای مدیریت درخواست‌های مشتری می‌سازیم. کاربران درخواست ثبت می‌کنند و مدیر وضعیت آن را تغییر می‌دهد. هدف فقط تولید صفحه نیست؛ مشخصات، مدل نقش‌ها، اتصال GitHub، کنترل Secret، بررسی RLS، تست و تحویل قابل‌نگهداری را هم طراحی می‌کنیم.

Lovable چیست؟

Lovable یک محیط ساخت برنامه وب با ورودی زبان طبیعی است. می‌توانید از Prompt اولیه، Template یا تصویر شروع کنید، نتیجه را در Preview ببینید و با گفت‌وگو یا Visual Edit اصلاح کنید. برای قابلیت‌های Backend می‌توان از Lovable Cloud یا اتصال Supabase استفاده کرد و پروژه را برای نسخه‌سازی و ادامه توسعه به GitHub متصل کرد.

Lovable جایگزین تعریف محصول، Code Review یا آزمون امنیت نیست. مدل می‌تواند کد تولید کند، اما نمی‌داند کدام داده برای کسب‌وکار حساس است، چه کسی باید مجوز تأیید داشته باشد یا خرابی کدام جریان هزینه بیشتری دارد. این تصمیم‌ها باید در مشخصات پروژه نوشته شوند.

قبل از Prompt، مسئله را یک صفحه‌ای کنید

Prompt مبهم مانند «یک CRM بساز» دامنه بسیار بزرگی دارد. نسخه اول باید یک مسئله، یک گروه کاربر و یک مسیر اصلی داشته باشد. برای پروژه نمونه، هدف این است: مشتری درخواست پشتیبانی ثبت کند، فقط درخواست‌های خودش را ببیند و مدیر بتواند وضعیت را تغییر دهد.

مشخصات حداقلی MVP

• کاربران: مشتری و مدیر
• ورودی: عنوان، شرح و اولویت درخواست
• خروجی: فهرست درخواست‌ها و وضعیت هر مورد
• قانون دسترسی: مشتری فقط رکوردهای خودش را می‌بیند
• معیار پذیرش: کاربر دوم به URL یا شناسه درخواست کاربر اول دسترسی ندارد
• خارج از محدوده: پرداخت، چت زنده، گزارش پیشرفته و اپ موبایل

هر قابلیت خارج از محدوده را در Backlog نگه دارید. اضافه‌کردن هم‌زمان Dashboard، Notification، Billing و چند Role، هم Prompt را مبهم می‌کند و هم سطح حمله را بالا می‌برد.

Prompt اولیه را چگونه بنویسیم؟

Prompt خوب فقط ظاهر را توصیف نمی‌کند. Roleها، Entityها، Stateها، رفتار خطا و محدودیت امنیتی را مشخص می‌کند. می‌توانید درخواست را در چند بخش روشن بنویسید:

یک اپ واکنش‌گرا برای مدیریت درخواست پشتیبانی بساز. دو نقش Customer و Admin دارد. Customer پس از ورود می‌تواند Ticket با Title، Description و Priority ایجاد کند و فقط Ticketهای خودش را ببیند. Admin همه Ticketها را می‌بیند و Status را بین Open، In Progress و Closed تغییر می‌دهد. رابط فارسی و RTL باشد. برای Loading، Empty، Error و Forbidden حالت جدا طراحی کن. هیچ Secret در Frontend قرار نده و قبل از اتصال Backend ابتدا Plan و مدل داده پیشنهادی را نمایش بده.

در نخستین مرحله از ابزار بخواهید Plan را ارائه دهد، نه اینکه فوراً تمام قابلیت‌ها را تولید کند. Entity و رابطه‌ها را بررسی کنید. اگر تصمیمی مانند نوع Auth یا محل ذخیره فایل روشن نیست، همان‌جا تعیین کنید.

معیار پذیرش را قابل‌آزمون بنویسید

جمله «امن باشد» قابل‌سنجش نیست. بنویسید Customer A نباید با تغییر شناسه Route بتواند Ticket مشتری B را ببیند؛ کاربر ناشناس باید پاسخ Unauthorized بگیرد؛ Admin Action باید در Audit ثبت شود. چنین شرط‌هایی بعداً به تست دستی و خودکار تبدیل می‌شوند.

ساخت مرحله‌ای به‌جای درخواست یک‌باره

1. ابتدا Design System، Navigation و صفحه‌های Static را بسازید.
2. حالت‌های Loading، Empty و Error را با داده Mock بررسی کنید.
3. سپس Auth و Roleها را اضافه کنید.
4. مدل داده و Migration را جداگانه Review کنید.
5. در مرحله بعد CRUD و Policyهای دسترسی را پیاده کنید.
6. در پایان Security Scan، Dependency Audit و تست دو کاربر را اجرا کنید.

بعد از هر مرحله یک نسخه سالم نگه دارید. تغییرهای کوچک تشخیص Regression را آسان می‌کنند و مصرف اعتبار گفت‌وگو را کاهش می‌دهند. اگر نتیجه نادرست است، دقیقاً تفاوت رفتار فعلی و انتظار را توضیح دهید؛ بازنویسی کل پروژه معمولاً مشکل را پنهان می‌کند.

GitHub را زود متصل کنید

مستندات رسمی Lovable اتصال GitHub را برای پشتیبان‌گیری کد، همکاری، کار محلی و استقرار جایگزین ارائه می‌کند. پس از اتصال، Repository منبع مهمی از تاریخچه پروژه است و Sync دوطرفه روی Branch اصلی انجام می‌شود.

اتصال را پس از روزها تغییر انباشته انجام ندهید. وقتی نخستین Skeleton پایدار شد، GitHub را متصل کنید تا هر مرحله Commit قابل‌مرور داشته باشد. Repository را پس از اتصال بی‌برنامه Rename، Move یا Delete نکنید؛ مسیر ثابت بخشی از سازوکار Sync است.

برای نصب GitHub App فقط Repositoryهای لازم را مجاز کنید. مدیر Workspace باید Scope دسترسی را بررسی کند. اتصال ابزار به همه مخزن‌های سازمان، بدون نیاز واقعی، سطح دسترسی را بیش از حد گسترش می‌دهد.

Frontend عمومی است؛ Secret را آنجا نگذارید

کد Frontend در مرورگر دانلود می‌شود و کاربر می‌تواند آن را ببیند یا تغییر دهد. API Key خصوصی، Token مدیریتی و Service Role در Component، فایل JavaScript یا Variable عمومی امن نیست. اگر یک سرویس Secret می‌خواهد، درخواست باید از Function سمت Server عبور کند.

نام Secret را در مستندات بنویسید اما مقدار را در Chat، Screenshot، Issue یا Repository قرار ندهید. اگر Credential به‌اشتباه وارد Frontend یا Git شد، حذف Commit کافی نیست؛ آن را Rotate و دسترسی قبلی را باطل کنید.

مرز امن درخواست خارجی

1. Frontend ورودی را جمع‌آوری می‌کند، اما مرجع اعتماد نیست.
2. Function سمت Server هویت و Schema ورودی را Validate می‌کند.
3. Secret فقط از Secret Store خوانده می‌شود.
4. پاسخ سرویس خارجی به فیلدهای لازم محدود می‌شود.
5. Logها Token و داده شخصی را Redact می‌کنند.

Rate Limit، Timeout و محدودیت اندازه Payload را نیز در Server اعمال کنید. اتصال ساده به API بدون این کنترل‌ها می‌تواند هزینه یا سوءاستفاده ایجاد کند.

دسترسی داده را با RLS کنترل کنید

پنهان‌کردن Button یا Filter کردن List در Frontend مجوز محسوب نمی‌شود. کاربر می‌تواند درخواست HTTP را تغییر دهد. اگر Backend بر PostgreSQL و Supabase تکیه دارد، Row Level Security باید مالکیت سطر را در Database اجرا کند.

برای جدول Ticket، شناسه مالک را از هویت Session تعیین کنید؛ نه از مقدار دلخواه Form. Policy خواندن، ایجاد، ویرایش و حذف را جدا تعریف کنید. Admin Role باید منبع قابل‌اعتماد داشته باشد و صرفاً یک Flag قابل‌ویرایش در Profile کاربر نباشد.

تست را با دو حساب مستقل انجام دهید. ابتدا رفتار مجاز را تأیید کنید، سپس URL، شناسه Record، Role و Payload را تغییر دهید و انتظار Deny داشته باشید. ابزار امنیتی کمک می‌کند، اما تست مجوز باید بخشی از Definition of Done باشد.

Security View را چگونه استفاده کنیم؟

Lovable برای پروژه ابزارهایی مانند تحلیل RLS، بررسی امنیت Database، Code Security Review و Dependency Audit دارد. بعضی Scanها هنگام تغییرهای مرتبط یا پیش از Publish اجرا می‌شوند؛ Code Review امنیتی ممکن است نیاز به اجرای دستی Update داشته باشد.

1. یافته‌های Critical را پیش از انتشار رفع کنید.
2. Warning را بدون دلیل مکتوب Ignore نکنید.
3. پس از تغییر Auth، Schema یا Dependency اسکن را تازه کنید.
4. Diff اصلاح خودکار را مانند هر کد دیگری Review کنید.
5. برای داده حساس یا عملیات مالی Review مستقل حرفه‌ای بگیرید.

عبور از Scan به معنی نبود آسیب‌پذیری نیست. Business Logic، سوءاستفاده از Flow، حریم خصوصی، Backup و Incident Response به بررسی انسانی نیاز دارند.

تست MVP قبل از انتشار

تست تجربه کاربر

• نمای Mobile و Desktop را بررسی کنید.
• Keyboard Navigation، Label و Contrast را آزمایش کنید.
• برای داده خالی، کندی شبکه و خطای Server پیام مناسب داشته باشید.
• فرم از ثبت تکراری جلوگیری کند و نتیجه را واضح نشان دهد.

تست فنی

• Build و Lint بدون خطای جدی اجرا شود.
• Dependencyهای ناشناخته یا آسیب‌پذیر Review شوند.
• Route محافظت‌شده برای کاربر ناشناس باز نشود.
• دو حساب نتوانند داده یکدیگر را بخوانند یا تغییر دهند.
• هیچ Secret در Bundle، Network Response یا Log نباشد.
• Backup، Export و مسیر Rollback حداقل یک‌بار تمرین شود.

انتشار و دامنه اختصاصی

Lovable امکان Publish و ساخت URL اشتراک‌پذیر را فراهم می‌کند و برای دامنه اختصاصی نیز مسیرهایی ارائه می‌دهد. پیش از عمومی‌کردن، Privacy Policy، اطلاعات تماس، Metadata، Favicon، صفحه 404 و رفتار robots را متناسب با نوع پروژه تنظیم کنید.

Preview داخلی نباید ناخواسته در Search Engine ایندکس شود. پس از اتصال دامنه، HTTPS، Redirect نسخه www، Callback URL احراز هویت و Cookieها را آزمایش کنید. تغییر DNS ممکن است زمان ببرد؛ انتشار را درست پیش از کمپین یا رویداد حساس انجام ندهید.

چه زمانی از Lovable استفاده نکنیم؟

• وقتی داده بسیار حساس است و تیم توان Review امنیتی ندارد.
• وقتی قوانین Domain پیچیده‌اند اما مشخصات یا Test وجود ندارد.
• وقتی Vendor Lock-in و مسیر Export برای سازمان پذیرفته نیست.
• وقتی الزامات Runtime، شبکه خصوصی یا Compliance پشتیبانی نمی‌شوند.
• وقتی هدف صرفاً تولید کد زیاد است، نه حل یک مسئله مشخص.

برای Prototype، ابزار داخلی، Landing Page تعاملی یا MVP با دامنه محدود مناسب است؛ به‌شرط اینکه هزینه بازنویسی، مالکیت کد و عملیات پس از انتشار از ابتدا دیده شوند.

برنامه هفت‌مرحله‌ای اجرای پروژه

1. مسئله و کاربران را در یک صفحه تعریف کنید.
2. محدوده MVP و موارد خارج از محدوده را بنویسید.
3. UI را با Mock Data و حالت‌های خطا بسازید.
4. GitHub را متصل و نخستین نسخه سالم را ثبت کنید.
5. Backend، Auth و RLS را مرحله‌ای اضافه کنید.
6. تست دو کاربر، Security Scan و Dependency Audit را اجرا کنید.
7. Preview را با ذی‌نفعان بررسی و سپس Publish کنید.

مسیرهای مکمل یادگیری

اگر Backend پروژه را با PostgreSQL می‌سازید، راهنمای Supabase و RLS مدل دسترسی سطری را توضیح می‌دهد. برای مدیریت Repository و انتشار، آموزش استقرار Next.js روی Vercel مسیر Preview تا Rollback را پوشش می‌دهد. برای مقایسه ابزارهای عامل کدنویسی نیز راهنمای GitHub Copilot CLI مفید است.

جمع‌بندی

Lovable می‌تواند ایده را سریع به یک MVP قابل‌آزمایش تبدیل کند، اما کیفیت محصول از Prompt طولانی به‌تنهایی نمی‌آید. مشخصات روشن، معیار پذیرش، تغییر مرحله‌ای، GitHub، مرز Server و Frontend، RLS و تست منفی اجزای اصلی کارند.

اتصال زودهنگام Repository به شما تاریخچه، Code Review و مسیر خروج می‌دهد. یافته‌های Security View را جدی بگیرید، ولی مسئولیت نهایی امنیت را به Scan یا مدل واگذار نکنید. انتشار زمانی آماده است که تیم بتواند هم رفتار مجاز و هم رفتار ممنوع را ثابت کند.

امروز مشخصات یک‌صفحه‌ای MVP را بنویس، فقط Skeleton آن را بساز و پیش از افزودن Backend، Repository و معیارهای تست دسترسی را آماده کن.

منابع رسمی

• Lovable Quick Start
• Lovable GitHub Integration
• Lovable Security Overview
• Project Security View
• Security Best Practices
• Lovable Two-Factor Authentication