حل المشكلات

Docker لا يعمل

failed to connect to the docker API at unix:///…/docker.sock; check if the path is correct and if the daemon is running

تعرض إصدارات Docker الأقدم الرسالة "Cannot connect to the Docker daemon" بدلًا من ذلك. وفي الحالتين، محرك Docker غير مُشغَّل.

1. 01

   افتح Docker Desktop

   شغّل Docker Desktop وانتظر حتى يُظهر أن المحرك يعمل. على Linux، شغّل الخدمة: sudo systemctl start docker.
2. 02

   تحقق من أن Docker يستجيب

   الطرفيةنسخ

   docker info

   النتيجة المتوقعة: يطبع قسم Server بدلًا من رسالة خطأ.
3. 03

   شغّل أمر التشغيل مرة أخرى

   docker compose up --build للحزمة الكاملة، أو أمرَي docker build وdocker run الخاصين بك لتطبيق واحد.

المنفذ مستخدم بالفعل

ports are not available: exposing port TCP 0.0.0.0:3031 … bind: address already in use
Bind for 0.0.0.0:3031 failed: port is already allocated
Error: listen EADDRINUSE: address already in use :::3031

يأتي السطران الأولان من Docker، والأخير من yarn dev. هناك برنامج آخر يستمع بالفعل على 3030 أو 3031 أو 8000: غالبًا تشغيل سابق للمطعم، أو خادم تطوير لمشروع آخر.

1. 01

   اعرف ما الذي يشغل المنفذ

   على macOS أو Linux، مع المنفذ الوارد في الرسالة:

   الطرفيةنسخ

   lsof -i :3031

   على Windows، في PowerShell:

   الطرفيةنسخ

   netstat -ano | findstr :3031
2. 02

   أوقفه

   أغلق ذلك البرنامج، أو أوقف التشغيل السابق: Ctrl+C في طرفيته، أو docker compose down في مجلده، أو docker stop للحاوية التي شغّلتها بـ docker run. ثم شغّل المطعم مرة أخرى.
3. 03

   أو شغّل المطعم على منافذ أخرى

   مع الحزمة الكاملة في Docker، أنشئ ملفًا باسم .env في المجلد food-studio-full-stack، بجوار docker-compose.yml، وفيه المنفذ الذي تحتاج إليه. ينقل SITE_PORT الموقع، وADMIN_PORT لوحة التحكم، وAPI_PORT واجهة API؛ والعناوين التي تستخدمها التطبيقات، ومنها CORS_ORIGIN، تتبعها تلقائيًا.

   food-studio-full-stack/.envنسخ

   ADMIN_PORT=3041

   ثم شغّل الأمر نفسه مرة أخرى. التشغيل الذي فشل يكمل من حيث توقف:

   الطرفيةفي food-studio-full-stackنسخ

   docker compose up --build

   النتيجة المتوقعة: يجيب التطبيق على منفذه الجديد، هنا localhost:3041محلي.

فشل بناء Docker

ينزّل البناء الأول الصور الأساسية وكل الاعتماديات، ثم يبني الصور. وعندما يعترضه شيء، يتوقف بالرسالة "failed to solve" مع الخطوة التي فشلت.

• لا اتصال أو انتهت المهلة: يحتاج البناء إلى الإنترنت. شغّل الأمر مرة أخرى بعد عودة الاتصال؛ الخطوات المكتملة محفوظة في ذاكرة التخزين المؤقت.
• لا توجد مساحة كافية على الجهاز (No space left on device): حرّر مساحة في Docker Desktop، أو تحقق مما يستخدمه Docker بالأمر docker system df.
• يفشل عند الخطوة نفسها في كل مرة: أعد البناء من دون ذاكرة التخزين المؤقت، ثم شغّل التطبيقات.

docker compose build --no-cache
docker compose up

لحزمة التطبيق الواحد، أضف --no-cache إلى أمر docker build الخاص بك.

التشغيل الأول الذي يبدو عالقًا يكون عادة ما زال يملأ بيانات المطعم التجريبي. لا يبدأ الموقع ولوحة التحكم إلا بعد أن تعلن واجهة API أنها سليمة.

يقول Yarn إن إصداره 1.22

This project's package.json defines "packageManager": "yarn@4…". However the current global version of Yarn is 1.22…

كل تطبيق يثبّت Yarn 4 عبر Corepack. تعني هذه الرسالة أن Corepack غير مفعّل بعد، فأجاب Yarn القديم المثبّت عامًّا بدلًا منه.

corepack enable

ثم شغّل yarn install مرة أخرى. إذا لم يكن مع Node.js لديك Corepack، فثبّته أولًا بالأمر npm install -g corepack.

يفشل التثبيت أو التشغيل على إصدار أقدم من Node.js

يعلن كل تطبيق أنه يحتاج إلى Node.js 24 أو أحدث، وتعمل صورة Docker الخاصة به على Node.js 24. لا يوقف Yarn الإصدار الأقدم بنفسه، لذلك يظهر أثر Node.js الأقدم لاحقًا، في صورة تثبيت يفشل في بناء حزمة أو تطبيق يتوقف عند التشغيل.

node -v

إذا طبع إصدارًا أقل من 24، ثبّت Node.js 24 أو أحدث، وشغّل corepack enable مرة أخرى، ثم احذف مجلد node_modules الخاص بالتطبيق وشغّل yarn install مرة أخرى. مع Docker لا ينطبق أي من هذا: تجلب الصور Node.js الخاص بها.

الموقع يعيد الخطأ 500 أثناء التطوير

في أول مرة يفتح فيها yarn dev صفحة، يقوم Next.js بتنزيل خطوط Google الخاصة بالموقع. بدون اتصال بالإنترنت، أو عندما يكون fonts.googleapis.com محظورًا، تعيد كل صفحة الخطأ 500 وتذكر وحدة تحكم المتصفح اسم ملف خط، مثل ibm_plex_sans_arabic.

اتصل بالإنترنت ثم أعد تحميل الصفحة. يقوم yarn build وبناء Docker بتنزيل الخطوط مرة واحدة وقت البناء، فلا يحتاجها الموقع المبني بعد ذلك.

تتوقف واجهة API قبل أن تبدأ

The API cannot start: JWT_SECRET is not set. Set it in back-end/.env to the output of: …
The API cannot start: JWT_SECRET is still the example value from .env.example, so anyone can sign a token for any account. …
The API cannot start: CORS_ORIGIN is not set. List the storefront and admin dashboard origins, comma separated, …

تتحقق واجهة API من إعداداتها قبل أن تبدأ، وتطبع سطرًا واحدًا لكل مشكلة. الأسباب:

• لا يوجد ملف `.env`، أو `JWT_SECRET` فارغ. أنشئ الملف في مجلد واجهة API بالأمر cp .env.example .env.
• ما زال `JWT_SECRET` بقيمة المثال مع `NODE_ENV=production`. يستطيع أي شخص توقيع رمز باستخدام المثال العام، لذا يرفضه التشغيل في وضع الإنتاج. ولّد سرًا خاصًا بك.
• `CORS_ORIGIN` فارغ مع `NODE_ENV=production`. اكتب عنوانَي الموقع ولوحة التحكم، مفصولين بفاصلة.

ولّد سرًا بالأمر:

node -e "console.log(require('crypto').randomBytes(48).toString('hex'))"

مع Docker لا تحتاج إلى ذلك: الحاوية التي ليس لها JWT_SECRET خاص بها، أو التي تستخدم قيمة المثال، تولّد سرًا وتحفظه في وحدة تخزين البيانات.

• أساسيات واجهة API

القائمة فارغة ولا يستطيع أحد تسجيل الدخول

→ No database at /data/database.sqlite. Creating the tables, no data (set SEED_DEMO_DATA=true for the demo).

أُنشئت قاعدة البيانات بالجداول فقط. يحدث ذلك عندما تبدأ حاوية واجهة API على وحدة تخزين جديدة من دون SEED_DEMO_DATA=true، أو عندما تعمل الحزمة الكاملة مع SEED_DEMO_DATA=false في ملف .env بجوار docker-compose.yml، أو من دون Docker عندما يُشغَّل yarn db:sync بدلًا من yarn seed. لا توجد قائمة ولا مطبخ ولا حساب لتسجيل الدخول به.

• من دون Docker: شغّل yarn seed في مجلد واجهة API. يضيف المطعم التجريبي وحساباته إلى الجداول الموجودة لديك.
• الحزمة الكاملة في Docker: احذف SEED_DEMO_DATA=false من ملف .env، ثم شغّل docker compose down -v وdocker compose up. تُنشأ وحدة تخزين البيانات من جديد مع المطعم التجريبي.
• حاوية واجهة API: احذف الحاوية، واحذف وحدة التخزين الخاصة بها، وشغّلها مرة أخرى مع -e SEED_DEMO_DATA=true، كما في «ابدأ من جديد» أدناه.

لا تعيد الحاوية تعبئة قاعدة بيانات موجودة أبدًا، أيًا كانت قيمة SEED_DEMO_DATA، لذلك لا يهم هذا المتغير إلا مع وحدة تخزين جديدة.

فشل تسجيل الدخول

• تحقق من الحساب والتطبيق. يسجّل الفريق الدخول إلى لوحة التحكم على المنفذ 3031: owner@foodstudio.example مع FoodDemo2026!. ويسجّل العملاء الدخول إلى الموقع على المنفذ 3030: sam@foodstudio.example مع FoodDemo2026!. لا يستطيع حساب العميل فتح لوحة التحكم، ولا يستطيع حساب الفريق تسجيل الدخول على الموقع.
• تقول لوحة التحكم «تعذّر تسجيل دخولك. تحقق من بريدك الإلكتروني وكلمة المرور ثم حاول مرة أخرى.» عند كلمة مرور خاطئة، أو بريد غير معروف، أو قاعدة بيانات بلا حسابات. وبعد محاولات فاشلة كثيرة تطلب منك الانتظار بضع دقائق بدلًا من ذلك. تحقق من النقاط أدناه واحدة تلو الأخرى.
• لا توجد حسابات في قاعدة البيانات عندما تُنشأ مع SEED_DEMO_DATA=false. راجع «القائمة فارغة ولا يستطيع أحد تسجيل الدخول» أعلاه.
• عشر محاولات تسجيل دخول فاشلة من عنوان واحد خلال 15 دقيقة تقفل نموذج تسجيل الدخول ذلك أمام هذا العنوان. تجيب واجهة API بـ 429 حتى يمر 15 دقيقة على أقدم محاولة فاشلة. انتظر، أو أعد تشغيل واجهة API: العدد محفوظ في ذاكرتها.
• غيّرت كلمة مرور المالك ولم تعد تعرفها: ابدأ من جديد ببيانات تجريبية جديدة، أدناه.

فشل تسجيل الدخول

• تحقق من الحساب والمسار. يسجّل الفريق الدخول على POST /api/auth/login (المالك هو owner@foodstudio.example مع FoodDemo2026!)؛ والعملاء على POST /api/auth/customer/login (sam@foodstudio.example مع FoodDemo2026!). تسجيل الدخول الفاشل يجيب بـ 401 مع الرسالة نفسها سواء كان البريد الإلكتروني أو كلمة المرور خاطئًا.
• لا يعمل أي حساب على الإطلاق: أُنشئت قاعدة البيانات من دون المطعم التجريبي. شغّل yarn seed، أو شغّل الحاوية مع -e SEED_DEMO_DATA=true على وحدة تخزين جديدة.
• الإجابة `429` تعني أن عنوانًا واحدًا فشل في 10 محاولات تسجيل دخول على ذلك المسار خلال 15 دقيقة. يزول ذلك بعد مرور 15 دقيقة على أقدم محاولة فاشلة، أو عند إعادة تشغيل واجهة API. يغيّر RATE_LIMIT_LOGIN هذا العدد.

فشل تسجيل الدخول

يسجّل تطبيقك الدخول عبر واجهة API الخاصة بالقالب، لذلك يجب أن يكون الحساب موجودًا فيها. على واجهة API معبّأة بالبيانات، يسجّل الفريق الدخول إلى لوحة التحكم بـ owner@foodstudio.example والعملاء إلى الموقع بـ sam@foodstudio.example، وكلاهما مع FoodDemo2026!. إذا لم يعمل أي حساب، فإما أن واجهة API بدأت من دون بياناتها التجريبية (شغّل yarn seed في مجلدها، أو شغّل حاويتها على وحدة تخزين جديدة مع -e SEED_DEMO_DATA=true)، وإما أن التطبيق لا يصل إلى واجهة API: راجع المشكلة التالية.

تبقى الصفحات فارغة ويُبلغ المتصفح عن CORS

Access to fetch at 'http://localhost:8000/api/…' from origin 'http://localhost:3041' has been blocked by CORS policy

تعرض وحدة التحكم في المتصفح هذا السطر عندما تعمل واجهة أمامية على عنوان لا تقبله واجهة API. تجيب واجهة API المتصفحات فقط من العناوين الموجودة في CORS_ORIGIN، وقيمته الافتراضية http://localhost:3030 وhttp://localhost:3031. الموقع أو لوحة التحكم المنقولان إلى منفذ آخر، أو المقدَّمان على نطاقك الخاص، يُرفضان حتى تُضاف عناوينهما.

CORS_ORIGIN=http://localhost:3030,http://localhost:3041
FRONTEND_URL=http://localhost:3041

• اكتب كل عنوان تمامًا كما يعرضه المتصفح، مع البروتوكول والمنفذ ومن دون شرطة مائلة في النهاية، مفصولة بفواصل. ثم أعد تشغيل واجهة API.
• FRONTEND_URL هو عنوان لوحة التحكم، الذي تتصل منه إشعاراتها المباشرة، وSTOREFRONT_URL هو عنوان الموقع، الذي يُرسَل إليه العميل من رابط الدفع ورابط إعادة تعيين كلمة المرور. انقلهما مع التطبيق.
• لحاوية واجهة API، مرّر القيم نفسها باستخدام -e، مثل -e CORS_ORIGIN=http://localhost:3030,http://localhost:3041.
• مع الحزمة الكاملة في Docker لا تعدّل هذه القيم: تضبطها SITE_PORT وADMIN_PORT وSITE_URL وADMIN_URL في ملف .env بجوار docker-compose.yml.
• الواجهة الأمامية التي لا تصل إلى واجهة API إطلاقًا، لأنها متوقفة أو على عنوان آخر، تفشل بالطريقة نفسها من دون سطر CORS. تحقق من أن localhost:8000/api/healthمحلي يجيب، ومن أن NEXT_PUBLIC_API_BASE_URL في الواجهة الأمامية يشير إلى واجهة API تلك.

• الإطلاق

صور الأطباق لا تظهر

تقدّم واجهة API الصور التجريبية على /media/food-studio/…، وتكتب تعبئة البيانات العنوان الكامل لكل صورة من PUBLIC_MEDIA_URL، وقيمته الافتراضية http://localhost:8000/media. لا تظهر الصورة عندما لا يصل هذا العنوان إلى واجهة API من المتصفح.

• تعمل واجهة API على منفذ أو نطاق آخر. اضبط PUBLIC_MEDIA_URL على العنوان العام لواجهة API متبوعًا بـ /media، مثل -e PUBLIC_MEDIA_URL=http://localhost:8010/media مع docker run -p 8010:8000. مع الحزمة الكاملة في Docker، يضبطه API_PORT وAPI_URL نيابة عنك.
• انتقلت واجهة API بعد التشغيل الأول. أعد تشغيل واجهة API مع ضبط PUBLIC_MEDIA_URL على العنوان الجديد (مع Docker Compose، يتولى ذلك API_PORT أو API_URL). عند بدء التشغيل توجّه كل صورة محفوظة تحت /media/food-studio/ و/media/uploads/ إلى ذلك العنوان، ويذكر سجلها عدد الصور التي غيّرتها.
• الملفات المرفوعة إلى مخزن لا تظهر. يجب أن يكون R2_PUBLIC_URL العنوان العام للمخزن، ويجب أن يسمح المخزن بالقراءة العامة.
• تظهر الصور، لكن ببطء وبحجمها الكامل. لا تغيّر الواجهات الأمامية حجم الصور إلا إذا جاءت من مضيف https المحدد في NEXT_PUBLIC_MEDIA_HOSTNAME (ومع Docker Compose، MEDIA_HOSTNAME)، مكتوبًا كاسم المضيف وحده، مثل pub-1234.r2.dev. أي صورة أخرى تُعرض كما هي. أعد بناء الواجهة الأمامية بعد تغييره.

• متغيرات البيئة

تغيير ملف .env للواجهة الأمامية لا يُحدث أي أثر

كل قيمة NEXT_PUBLIC_* تُضمَّن في كود JavaScript الذي يحمّله المتصفح عند بناء التطبيق. تغيير الملف لا يغيّر شيئًا حتى يُبنى التطبيق من جديد.

الطلبات الجديدة لا تظهر في لوحة التحكم تلقائيًا

يستخدم جرس لوحة التحكم وتحديثات الطلبات المباشرة اتصال WebSocket بواجهة API. تتصل لوحة التحكم بـ NEXT_PUBLIC_WEBSOCKET_BASE_URL، أي عنوان واجهة API من دون /api، ولا تقبل واجهة API الاتصال إلا من FRONTEND_URL، أي عنوان لوحة التحكم نفسها.

• اضبط الاثنين ليطابقا المكان الذي تعمل فيه التطبيقات فعلًا، ثم أعد تشغيل واجهة API وأعد بناء لوحة التحكم.
• إذا لم يُضبط FRONTEND_URL فلا يُقبل إلا http://localhost:3031، لذلك يُرفض الاتصال المباشر على أي عنوان آخر.
• إعادة تحميل الصفحة تعرض دائمًا أحدث الطلبات: التحديثات المباشرة وحدها تعتمد على الاتصال.

ميزة تقول إنها غير متصلة

لا تعمل المدفوعات بالبطاقة و PayPal، ورفع الملفات إلى مخزن، وبريد إعادة تعيين كلمة المرور، والمساعد الذكي، واستوديو الذكاء الاصطناعي إلا عند ضبط متغيراتها في ملف .env الخاص بواجهة API. في .env.example تكون معلّقة كتعليقات، لذلك يبدأ الملف المنسوخ نظيفًا وتبقى كل هذه الميزات متوقفة.

• احذف # الموجودة قبل السطر والصق قيمتك الحقيقية مكان قيمة المثال.
• أعد تشغيل واجهة API بعد تغيير ملف .env الخاص بها. مع Docker Compose تقرأ واجهة API الملف back-end/.env أيضًا، لذلك يكفي تشغيل docker compose up مرة أخرى؛ أما حاوية واجهة API المنفردة فتحتاج إلى --env-file .env في أمر docker run الخاص بها.
• يحتاج بريد إعادة تعيين كلمة المرور إلى RESEND_API_KEY وMAIL_FROM معًا. من دونهما، يستجيب «نسيت كلمة المرور» كالمعتاد، ويذكر السجل: "Mail is not configured: set RESEND_API_KEY and MAIL_FROM to send password reset messages."

• متغيرات البيئة

طلب مدفوع يبقى غير مدفوع

لا يُعدّ الطلب مدفوعًا إلا بعد أن تؤكد واجهة API الدفع مع Stripe أو PayPal، عندما يعود العميل أو عندما يصل webhook المزوّد. إذا بقي الطلب غير مدفوع بعد أن دفع العميل:

• لم يعد العميل إلى واجهة API. يرسل المزوّد المتصفح إلى API_PUBLIC_URL، وقيمته الافتراضية http://localhost:8000. على نطاقك الخاص، اضبطه على العنوان العام لواجهة API.
• لم يُضبط الـ webhook. وجّهه إلى عنوان واجهة API الخاصة بك متبوعًا بـ /api/payments/webhooks/stripe أو /api/payments/webhooks/paypal، واضبط STRIPE_WEBHOOK_SECRET أو PAYPAL_WEBHOOK_ID. الاستدعاء غير الموقّع أو المعدَّل يُرفض بـ 401.
• غادر العميل صفحة الدفع. الطلب الذي لم يعد إليه أحد يُتحقق منه لدى المزوّد، بعد 35 دقيقة لـ Stripe و3 ساعات لـ PayPal، ويُلغى إن لم يُدفع، فيعيد المخزون والنقاط.

• المدفوعات

صفحة إتمام الطلب تقول إن المطبخ مغلق أو إن العنوان خارج المنطقة

This kitchen is closed. Choose another kitchen.
Delivery is unavailable here. Try pickup.

• مغلق. لا يستقبل المطبخ الطلبات إلا خلال ساعات عمله، وبحسب منطقته الزمنية. عندما تكون ساعة الخدمة على «الساعة الحقيقية»، ترفض صفحة إتمام الطلب التوصيل والاستلام معًا خارج هذه الساعات. غيّر الساعات من «الإعدادات»، ثم «المطعم»، أو جرّب مطبخًا آخر.
• خارج المنطقة. لا يصل التوصيل إلا إلى الرموز البريدية التي يحددها المطبخ. توصّل المطابخ التجريبية إلى رموز بريدية مثل 10001 و10002. أضف رموزك البريدية إلى كل مطبخ من «الإعدادات»، ثم «المطعم».
• أقل من الحد الأدنى. يحتاج طلب التوصيل إلى قيمة طعام لا تقل عن الحد الأدنى للتوصيل، وهو $10.00 في الإعدادات التجريبية.

كل زائر يرى رسالة «محاولات كثيرة جدًا» خلف خادم وكيل

النماذج العامة محدودة لكل عنوان زائر: الطلبات، وجلسات الدفع، والتتبّع، والتسجيل، ونموذج التواصل، وإعادة تعيين كلمة المرور، ومحاولات تسجيل الدخول الفاشلة. خلف خادم وكيل عكسي، قد يبدو كل زائر بعنوان الوكيل الوحيد فيتشاركون حصة واحدة. أخبر واجهة API بعدد الخوادم الوكيلة التي تقف أمامها:

TRUST_PROXY=1

تغيّر متغيرات RATE_LIMIT_* في .env.example كل حد. الأعداد محفوظة في ذاكرة واجهة API، لذلك تمسحها إعادة التشغيل.

MySQL يرفض البدء أو ملء البيانات

تنشئ واجهة API جداولها في قاعدة بيانات موجودة مسبقًا؛ ولا تنشئ قاعدة البيانات نفسها. أنشئ أولًا قاعدة بيانات فارغة، وضع اسمها في DB_DATABASE في ملف .env الخاص بواجهة API، ثم شغّل yarn seed (أو yarn db:sync للجداول من دون بيانات تجريبية).

• تحقق من قيم الاتصال الخمس DB_*، ومن أن DB_TYPE=mysql.
• مع NODE_ENV=production لا تنشئ واجهة API العاملة أي جداول، لذلك يجب تشغيل أحد هذين الأمرين قبل التشغيل الأول (yarn seed:prod أو yarn db:sync:prod بعد yarn build).
• لا تنشئ صورة Docker قاعدة البيانات بنفسها إلا مع SQLite. مع MySQL، شغّل أمر تعبئة البيانات أو أمر إنشاء الجداول مرة واحدة بنفسك.

• استخدم MySQL بدلًا من SQLite

حاوية واجهة API لا تجد نقطة الدخول الخاصة بها

exec /usr/local/bin/docker-entrypoint.sh: no such file or directory

في السكربت نهايات أسطر بنمط Windows، وقد يضيفها محرر نصوص أو Git على Windows. يزيلها ملف Dockerfile المرفق مع واجهة API أثناء البناء، لذلك لا تظهر هذه المشكلة إلا مع صورة مبنية من Dockerfile معدَّل. أبقِ السطر sed -i 's/\r$//'، أو احفظ السكربت بنهايات أسطر LF، ثم أعد البناء من دون ذاكرة التخزين المؤقت.

المجلد يبدو مختلفًا

شغّل الأوامر داخل المجلد الذي يُستخرج إليه ملف ZIP. إذا لم يكن الأمر unzip متوفرًا، فاستخرجه بمدير الملفات بدلًا من ذلك؛ تضيف بعض الأدوات مجلدًا إضافيًا يحمل اسم ملف ZIP، فانتقل إلى المجلد الداخلي.

ابدأ من جديد ببيانات تجريبية جديدة

مع الحزمة الكاملة في Docker، من المجلد food-studio-full-stack:

docker compose down -v
docker compose up

مع حاوية واجهة API منفردة، احذف الحاوية أولًا (يعرضها docker ps -a، ويحذفها docker rm -f مع معرّفها)، ثم احذف وحدة التخزين وشغّلها مرة أخرى:

docker volume rm foodstudio-data
docker run -p 8000:8000 -v foodstudio-data:/data -e SEED_DEMO_DATA=true foodstudio-api

من دون Docker، أوقف واجهة API، ثم في مجلدها:

rm -f database.sqlite* && yarn seed

في PowerShell:

Remove-Item database.sqlite*; yarn seed

تشغيل yarn seed مرة أخرى على قاعدة بيانات تحتفظ بها ليس إعادة تعيين: يضيف ما هو ناقص فقط ولا يغيّر أي قيمة عدّلتها. يحذف yarn db:reset كل الجداول، على SQLite و MySQL على حد سواء؛ شغّل yarn seed بعده.