موجهات Vibe لبناء تطبيق CRUD: مجموعة كاملة للنسخ واللصق

ما الذي تبنيه هذه المجموعة من الموجهات (بالعربية البسيطة)

مجموعة الموجهات هذه مصممة لتوليد تطبيق CRUD كامل وعامل: الشاشات التي يستخدمها الناس، الـ API الذي يتعامل مع الطلبات، وقاعدة بيانات PostgreSQL التي تخزّن البيانات. كما تتضمن تسجيل الدخول والتحكّم بالأدوار، بحيث يمكن لمستخدمين مختلفين رؤية وفعل أشياء مختلفة.

CRUD هي أربع عمليات يومية يحتاجها تطبيقك:

• Create: إضافة سجل جديد (مثل عميل أو مهمة)
• Read: عرض قائمة وفتح عنصر مفرد
• Update: تعديل عنصر موجود
• Delete: حذف عنصر (غالبًا مع خطوة تأكيد)

على الواجهة الأمامية، ستحصل في النهاية على مجموعة شاشات متوقعة: صفحة قائمة، صفحة تفاصيل، نموذج إنشاء، نموذج تعديل، بالإضافة إلى صفحة تسجيل دخول وتنقّل أساسي. على الخادم، سيكون لديك نقاط نهاية تتطابق مع تلك الشاشات (list, get by id, create, update, delete)، مدعومة بجدول في Postgres وعمليات تحقق بسيطة.

جودة الموجه أهم من اختيار النموذج. النموذج يستطيع فقط اتباع ما تحدده. إذا كانت موجهاتك غامضة ستحصل على أسماء حقول غير متطابقة، مسارات مفقودة، مصادقة غير كاملة، أو واجهة لا تتوافق مع الـ API. موجهٌ محكم يعمل كعقد: الواجهة، الـ API، وقاعدة البيانات تتفق على نفس الأسماء والقواعد.

قبل أن تبدأ، قرّر بعض التفاصيل حتى يبقى البناء متسقًا:

• الكيان الرئيسي وعدد الحقول (6 إلى 12) مع الأسماء، الأنواع، مطلوب أم اختياري
• الأدوار (مثال: admin, manager, viewer) وما الذي يمكن لكل دور فعله
• القواعد الأساسية (من يمكنه التعديل، حذف ناعم أم قاسي، الحقول المطلوبة)
• شاشات "المسار السعيد" التي تحتاجها في اليوم الأول
• أي قيود (حقول فريدة، نطاقات تواريخ، قيم حالة)

إذا كنت تستخدم Koder.ai، يمكن أن تكون هذه محادثة واحدة تنتج واجهة React، API بـ Go، ومخطط PostgreSQL متناسقين بدون حاجة لتوصيل يدوي.

ورقة التحضير: التفاصيل القليلة التي تحتاجها قبل الموجه

بناء CRUD جيد يبدأ بمجموعة صغيرة من القرارات. اكتبها أولًا وستبقى موجهاتك واضحة، شاشاتك تبدو صحيحة، وAPI يطابق قاعدة البيانات.

ابدأ بكيان أساسي واحد. هذا هو "الشيء" الذي يديره تطبيقك يوميًا (Item, Customer, Appointment). أضف كيانًا ثانيًا فقط إذا كان مطلوبًا فعلاً في اليوم الأول (مثال: Item يحتاج Category). إذا بدأت بثلاثة أو أربعة ستقضي معظم وقتك في فك العلاقات بدل الحصول على تطبيق يعمل.

اكتب حقول الكيان مع النوع ومثال. المثال مهم لأنه يوجّه التسميات، التنسيق، والتحقّق.

• Field: type - example (ملاحظات)
• name: text - "Paper towels" (مطلوب، 2-80 حرفًا)
• quantity: number - 24 (الحد الأدنى 0)
• reorder_date: date - 2026-02-01 (اختياري)
• status: enum - "in_stock" | "low" | "out" (الافتراضي in_stock)

بعد ذلك، قوّم الأدوار والصلاحيات بلغة بسيطة. اجعلها محددة. بالنسبة للعديد من التطبيقات، 2 إلى 3 أدوار كافية:

• Admin: إدارة المستخدمين، CRUD كامل على كل السجلات
• Manager: CRUD على السجلات، لا يدير المستخدمين
• Viewer: للقراءة فقط

أخيرًا، أنشئ 5 إلى 10 سجلات نموذجية. هذه تدفع تسميات الواجهة، خيارات القوائم المنسدلة، والقيم الافتراضية المعقولة. مثال (المخزون): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.

إذا كنت تبني في Koder.ai، ألصق ورقة التحضير هذه في موجهك الأول حتى تتمكن المنصة من الحفاظ على اتساق التطبيق عبر الشاشات، المصادقة، وAPI المدعوم بـ PostgreSQL.

الموجه الأساسي: ضع قواعد البناء كله

ابدأ بموجه واحد "قواعد الطريق". يحافظ على اتساق البناء عبر الشاشات، الـ API، وقاعدة البيانات، ويقلّل الرجوع عند إضافة مميزات لاحقًا.

اطلب خطة قصيرة قبل أي شيفرة. تريد أن يسمي النموذج الشاشات والمسارات، الجداول، ونقاط نهاية الـ API. كما اطلب منه أن يذكر الافتراضات مقدمًا (مثل ما الأدوار الموجودة) وأن يحافظ على تلك الافتراضات دون تغيير إلا بموافقتك.

هنا موجه أساسي للنسخ واللصق:

You are building a complete full-stack CRUD app.

Tech targets (do not change):
- Frontend: React web app
- Backend: Go REST API
- Database: PostgreSQL

Before writing any code, produce a short plan (max 25 lines) that includes:
1) Screens + key UI components
2) Routes/navigation
3) Roles and permissions
4) PostgreSQL tables (with columns and relationships)
5) API endpoints (method + path) for auth and CRUD

Assumptions:
- If any detail is missing, make a reasonable default and list it under “Assumptions”.
- Keep assumptions consistent across UI, API, and DB. If you must change an assumption, stop and ask.

Rules:
- Use simple, boring CRUD first. No “nice to have” features unless asked.
- Include input validation, basic error messages, and loading states.
- Use clear names that match across layers (same field names in UI, API, and DB).

Non-goals (do NOT implement):
- Payments, subscriptions, invoices
- Complex workflows/approvals
- Multi-tenant org hierarchy
- Real-time chat/notifications

Now ask me 5 clarifying questions max. If I answer “default”, proceed with your assumptions.

مثال ملموس: إذا اختارت الخطة role: admin|member فلا ينبغي لاحقًا أن تختلق manager لحل حالة واجهة. هذا الموجه يجبرها على التوقّف وطلب موافقتك بدل الانحراف.

موجهات للنسخ واللصق: الشاشات والتنقل

الشاشات الجيدة تأتي من خريطة صفحات واضحة أولًا. استخدم الموجهات أدناه قبل طلب قاعدة البيانات أو شيفرة الـ API. هذا يحافظ على ثبات المسارات وأسماء الواجهة لاحقًا، وهو المكان الذي تتعطل فيه كثير من البُنى.

الموجه 1: قائمة الصفحات وتدفقات المستخدم

You are building a full-stack CRUD app UI. Start by proposing a complete page list and user flows.

App concept (1 sentence): <PASTE YOUR APP CONCEPT>
Entities (list): <ENTITY_1>, <ENTITY_2>
Roles: <ROLE_1>, <ROLE_2> (include an Admin role)

Deliverables:
1) A table of pages with: Route, Page name, Who can access, Primary actions, Empty state behavior.
2) Key user flows (bullets): sign up, sign in, create record, edit, delete, search/filter, admin manages users.
3) Route naming rules: kebab-case paths, consistent singular/plural, no duplicates.
4) Component naming rules: PascalCase, one top-level page component per route.
Ask me 5 questions max only if needed.

بعد أن يجيب، قفل الأسماء. إذا غيرت أسماء المسارات لاحقًا، سيتعرّض الـ API والاختبارات للانحراف.

الموجه 2: التنقل والنماذج التي تتصرف جيدًا

Using the approved page list and route names, generate:

A) Navigation
- A simple top nav for desktop and a compact mobile menu.
- Show which items appear for each role.
- Add a clear "You do not have access" page and redirect rules.

B) Page skeletons
For each page, create a minimal UI with:
- A visible page title and short helper text.
- Loading state, empty state, error state.
- A primary button for the main action.

C) Accessible forms
For all create/edit forms:
- Labels tied to inputs, required markers, inline validation errors.
- Disable submit while saving, show a spinner, prevent double submits.
- Toast or inline success message after save.

D) Consistent action names
Use these verbs exactly: list, view, create, update, delete.
Use these UI actions: onCreate, onUpdate, onDelete, onSearch.

إذا كانت الواجهة المعادة معقّدة جدًا، اطلب منها الاحتفاظ بتخطيط واحد فقط، نمط جدول واحد، ونمط نموذج واحد عبر كل الصفحات.

موجهات للنسخ واللصق: المصادقة والأدوار

إذا أردت نتائج متوقعة، كن صريحًا بكيفية تسجيل دخول المستخدمين، مدة الجلسات، وما يفعله كل دور. هذه الموجهات تفترض تسجيل دخول بسيط بالبريد+كلمة مرور ونهج يعتمد الجلسة.

ألصق هذا أولًا لتوليد تسجيل الدخول، تسجيل الخروج، وتعامل الجلسة:

Implement authentication for this app.

Requirements:
- Add UI screens: Login, Logout action, and a simple “My account” page that shows the logged-in user email and role.
- Use email + password login.
- Session handling: keep the user logged in across refresh; include a clear “Log out” button.
- API endpoints: POST /auth/login, POST /auth/logout, GET /auth/me.
- Show friendly error messages for wrong password, unknown email, and locked/disabled accounts.

Security (keep it simple):
- Password rules: minimum 12 characters; must include at least 1 letter and 1 number.
- Store passwords securely (hash + salt). Never store plain text.
- Basic protections: rate-limit login attempts per email/IP and return generic error text that doesn’t reveal which part was wrong.

Deliverables:
- Working UI flows + backend endpoints.
- Seed one default admin user for local testing and tell me the credentials.
- Add clear comments explaining where to change password rules and session duration.

الآن أضف الأدوار وقواعد الحماية. اجعل الصلاحيات صغيرة وسهلة الاختبار:

Add role-based access control (RBAC) with these roles: admin, manager, viewer.

Rules:
- admin: can create, edit, delete, and manage users/roles.
- manager: can create and edit records, cannot delete, cannot manage users.
- viewer: read-only.

Enforcement:
- Protect both routes (screens) and API endpoints. Do not rely on the UI alone.
- If a user lacks permission, show a “Not allowed” page in the UI and return HTTP 403 from the API.

Deliverables:
- A simple “Users” admin screen to list users and change roles.
- A clear table (in text) mapping each route + API endpoint to required role.
- Add automated checks or middleware so every protected endpoint enforces the rules.

فحوصات يدوية سريعة تلتقط معظم الأخطاء:

• سجّل الدخول بكل دور وتأكد مما يمكنه وما لا يمكنه رؤيته.
• حاول تنفيذ إجراء مقيد وتأكد من حصولك على 403.
• تأكد أن تسجيل الخروج يمسح الجلسة ويعيد التطبيق إلى شاشة تسجيل الدخول.

إذا بنيت في Koder.ai، احتفظ بتغييرات المصادقة وRBAC في لقطة واحدة لتتمكن من التراجع بسهولة إذا تشابكت الصلاحيات.

موجهات للنسخ واللصق: مخطط PostgreSQL ونموذج البيانات

موجه مخطط جيد يقوم بوظيفتين: يفرض علاقات جداول واضحة (حتى تبقى الواجهة والـ API متوافقة)، ويمنع قواعد بيانات "قريبة من الصحيحة" (نقص فهارس، طوابع زمنية، أو خريطة الأدوار).

قبل اللصق، قرّر هذين الإعدادين (سطر واحد لكل):

• Primary keys: uuid أو bigserial
• Soft delete: yes (استخدم deleted_at) أو no (حذف قاسي)

ألصق هذا أولًا لقفل نموذج البيانات:

You are building the PostgreSQL data model for a full-stack CRUD app.

Domain: <DESCRIBE YOUR APP IN 1 SENTENCE>
Core entities: <LIST 3-6 ENTITIES>

Rules:
- Use PostgreSQL.
- Choose primary key type: <uuid|bigserial>.
- Timestamps: every table must have created_at and updated_at.
- Soft delete: <yes|no>. If yes, add deleted_at and default queries should ignore deleted rows.
- Define users, roles, and permissions storage:
  - users table (email unique, password_hash, status)
  - roles table (name unique)
  - user_roles join table (user_id, role_id) with unique(user_id, role_id)
- For each core entity: define columns, types, required vs optional, and relationships.
- Call out any many-to-many relationships and introduce join tables.
- Propose indexes for common lookups (foreign keys, email, name/search fields).

Output:
1) A short ERD description in plain English.
2) The final table list with columns and constraints.
3) The index list with rationale.

ثم ألصق هذا الموجه لتوليد الترقيات أو خطوات الإعداد التي تطابق المشروع:

Now generate the actual database setup for this project.

Requirements:
- Provide SQL migrations (up and down) for all tables, constraints, and indexes.
- Ensure foreign keys and on-delete behavior are explicit.
- Include extensions you rely on (for example uuid generation), but only if needed.
- Add a seed migration for: one admin user, one admin role, and the user_roles link.

Output:
- migrations/ file names in order
- contents of each up/down migration
- brief notes on how to apply migrations in the project

إذا كان هناك غموض، أضف سطرًا واحدًا آخر: “اسألني حتى 5 أسئلة إذا كان أي علاقة أو حقل غير واضح قبل كتابة SQL.”

موجهات للنسخ واللصق: API CRUD بـ Go (مدعوم بـ Postgres)

إذا كانت مخرجات الـ backend تعود غير مكتملة، هذا الموجه يجبر الأساسيات: مسارات واضحة، تحقق، ترقيم، وفحص الأدوار في كل معالج.

انسخ هذا كما هو، ثم استبدل القيم النائبة (RESOURCE, FIELDS, ROLES) بتفاصيل تطبيقك.

You are building the backend API in Go for a Postgres-backed CRUD resource.

Resource
- RESOURCE name (singular/plural): <Item/items>
- Table: <items>
- Primary key: <id UUID>
- Fields (name, type, required?, rules):
  - <name TEXT required, 2..80 chars>
  - <qty INT required, min 0>
  - <status TEXT optional, one of: active, archived>
- Ownership: <tenant_id UUID required> and <created_by UUID required>

Auth and roles
- Roles: <admin, manager, viewer>
- Authorization rules:
  - Every endpoint must check role and tenant_id.
  - admin: full access
  - manager: create, read, update, list; cannot delete
  - viewer: read and list only

API requirements
1) Implement REST endpoints:
- POST /api/items
- GET /api/items/{id}
- PUT /api/items/{id}
- DELETE /api/items/{id}
- GET /api/items

2) Define request/response JSON shapes for each endpoint, including examples.

3) Validation
- Return 400 with field-level errors (clear messages) when invalid.
- Return 401 if no auth, 403 if role not allowed, 404 if not found in tenant.

4) List endpoint
- Support filtering by: <status>
- Support sorting by: <created_at,name> with order asc/desc
- Support pagination: page, page_size; return total, page, page_size, items.

5) Data access
- Use database/sql (or pgx) with parameterized queries only.
- Include migrations SQL for the table and indexes (tenant_id + created_at).

Deliverables
- Go code: routes, handlers, DTOs, validation helpers, repository layer
- SQL: migration(s)
- Notes: any assumptions

بعد التوليد، قم بتمرير سريع للتحقق من الاتساق: رموز الحالة تتطابق مع جسم الخطأ، نقطة النهاية القائمة تعيد ترتيبًا ثابتًا، وكل معالج يفحص الدور وملكية tenant قبل الوصول للقاعدة.

إذا كنت تستخدم Koder.ai، نبه أنها يجب أن تبقى في Go وأن القاعدة تظل PostgreSQL حتى تتطابق الشيفرة المصدّرة مع الستاك المتوقع.

خطوة بخطوة: التوليد، التشغيل، والتحقق

ولّد كل شيء (الواجهة، الـ API، القاعدة)، ثم انتقل إلى وضع تحقق صارم. الهدف ليس التباهي بالشاشات، إنما إثبات أن الحلقة الكاملة تعمل: UI - auth - roles - Postgres - API - UI.

تشغيل تحقق بسيط

1. شغّل التطبيق وحمّل الشاشة الرئيسية. تأكد أن التنقل يعمل ولا ترى بيانات عنصر نائب. إذا كانت الصفحة فارغة، سجّل أول رسالة خطأ مرئية (تنبيه واجهة، console، أو سجل الخادم).

2. أنشئ حساب اختبار لكل دور (Admin, Manager, Viewer). سجّل الدخول والخروج بكل مستخدم. تأكد أن التطبيق يعرض الدور في مكان مرئي (قائمة الملف الشخصي، الإعدادات، أو شارة صغيرة).

3. اختر شاشة CRUD وقم بدورة كاملة: أنشئ سجلًا، حدّث الصفحة، ثم عدّل واحذفه. التحقق الأساسي هو الثبات: بعد التحديث، يجب أن يعكس السجل ما في Postgres، ليس الذاكرة فقط.

4. جرّب إجراءات ممنوعة عن عمد. سجّل كأقل دور وحاول الوصول إلى شاشة خاصة بالمدير، استدعِ إجراء مقيد (كالحذف)، وحاول تعديل سجل لا تملكه. تريد نتائج واضحة: إما واجهة تحظر العملية مع رسالة، أو خطأ 403 بدون تغيير بيانات.

5. اختبر حالات الحواف الأساسية: قوائم فارغة، أسماء طويلة جدًا، حقول مطلوبة مفقودة، وصيغ غير صحيحة (بريد إلكتروني، تواريخ). تأكد أن التطبيق يعرض تحققًا مفيدًا ولا ينهار.

إذا كنت تستخدم Koder.ai، خذ لقطة بعد أول اختبار CRUD مكتمل فعّال. تعطيك نقطة تراجع آمنة قبل إضافة الميزات.

إخفاقات شائعة في الموجهات وكيفية إصلاحها

معظم البُنى "المعطلة" ليست معطلة حقًا. تفتقد قيدًا واحدًا يحافظ على توافق الواجهة والـ API والبيانات.

1) طلبت الكثير دفعة واحدة

عندما تطلب الشاشات، المصادقة، الأدوار، المخطط، وكل حالات الحافة دفعة واحدة، غالبًا ما يصبح التطبيق غير متسق (المسارات لا تتطابق، النماذج تتغيّر، صفحات نصف منجزة).

الإصلاح: قسم العمل حسب الطبقة وأجبر الأداة على إعادة صياغة ما ستولده قبل كتابة الشيفرة. في Koder.ai، يساعد ذلك في توافق عدة وكلاء.

2) الأدوار غامضة، فتفوت فحوصات

إذا قلت فقط "admin و user" قد تحصل على تسمية دور في الواجهة لكن لا توجد تفويضات على الخادم.

الإصلاح: عرّف الأذونات كأفعال (create, read, update, delete) لكل مورد، واطلب فرضها على الخادم في كل نقطة نهاية.

3) نقص أنواع الحقول يسبب انحراف

إذا وصفت الحقول بالإنجليزية العامة ("price", "date", "status"), قد تعرض النماذج حقول نصية بينما PostgreSQL يتوقع أرقامًا أو تواريخ أو enums.

الإصلاح: حدد أنواع الحقول، القابلية للـ null، القيم الافتراضية، والقيود، واطلب قواعد تحقق مشتركة.

4) لا حالات تحميل ولا أخطاء، فتبدو الواجهة مكسورة

بدون حالات تحميل وأخطاء، الطلب الفاشل يبدو كصفحة مجمّدة.

الإصلاح: اطلب مؤشرات تحميل، حالات فارغة، ورسائل خطأ مرئية لكل شاشة.

5) تغيير الأسماء منتصف البناء

إعادة تسمية "Projects" إلى "Workspaces" في منتصف المشروع يكسر المسارات والمعالجات وأسماء الجداول.

الإصلاح: اقفل قاموس مصطلحات مبكرًا. عند التغيير، اطلب خطة إعادة تسمية (بحث/استبدال، ترحيل) بدل أن يقتحم النموذج التغيير.

استخدم موجه الإصلاح هذا عندما يخرج التطبيق عن المسار:

``text Audit the current app and list mismatches between: (1) routes, (2) API endpoints, (3) database tables/columns, (4) UI form fields. Then propose a minimal patch plan. Rules: do not invent new names, do not add new features, keep existing behavior, and update tests if present. Output: a checklist of changes, then apply them.

إذا استمرت حالات عدم التوافق، فغالبًا تفتقد لبيان "مصدر الحقيقة الواحد". أضف جملة: "مخطط Postgres هو مصدر الحقيقة؛ يجب أن تطابقه الواجهة والـ API تمامًا." 

## قائمة تحقق سريعة قبل إتمام العمل

قبل أن تقضي وقتًا في التلميع، قم بمرور سريع لتأكيد أن التطبيق يتصرف كمنتج حقيقي. هنا يفشل معظم تطبيقات CRUD: اختلافات طفيفة بين الشاشات والقواعد والبيانات.

- **الشاشات تطابق مواصفات الكيان**: كل شاشة (list, details, create, edit) تستخدم أسماء الحقول والكيان التي حددتها بالضبط.
- **الأدوار غير غامضة**: اكتب جدول سماح/منع بسيط لكل دور وتأكد أن الواجهة والـ API يطبقان نفس القواعد.
- **استجابات الـ API متسقة**: اختر نمطًا واحدًا (رموز الحالة، شكل الخطأ، شكل الترقيم) وتحقق من اتباع كل نقطة نهاية له.
- **قيود القاعدة تطابق تحقق النماذج**: إذا كانت DB تتطلب بريدًا فريدًا أو اسمًا غير فارغ، تحقق ذلك قبل الإرسال وأعرض رسالة واضحة عند رفض الـ API.
- **الإنشاء/التعديل/الحذف يبقى بعد التحديث**: أنشئ سجلًا، حدّث، احذف، ثم حدّث الصفحة وتأكد أن التغيرات باقية.

اختبار ملموس: سجّل كأقل دور وحاول فعل عملية تتوقع حظرها (مثل الحذف). إذا نجحت، أصلح السياسة في مكان واحد أولًا (الـ API)، ثم عدّل الواجهة لتعكس ذلك.

## مثال واقعي: متتبع مخزون بسيط

تخيل فريق تقنية معلومات صغير يعير أجهزة للموظفين. يحتاجون مكانًا واحدًا لرؤية ما هو متوفر، من لديه ماذا، ومتى يجب إرجاعه. هذا سيناريو جيد لأنه يفرض الأدوار، بعض الشاشات، وقاعدة بيانات حقيقية.

### ورقة التحضير معبأة كمثال

انسخ هذا كما هو لتستخدمه كمدخل خطوة التحضير (انسخه ثم عدّل الأسماء):

```text
App name: IT Equipment Loans
Goal: Track inventory and loans. Staff can request items. Admin approves and records check-out and return.
Roles:
- admin: manage inventory, approve/deny requests, edit any loan, see all
- staff: browse inventory, create a request, see own requests/loans
- viewer: read-only access to inventory and aggregate loan status
Core screens:
- Login
- Inventory list + item detail
- Request item (staff)
- Admin requests queue
- Loans list (filter: active/overdue)
Data rules:
- An item can have 0 or 1 active loan at a time
- Due date required for approved loans
- Overdue if due_date < today and not returned
Sample data:
- Items: MacBook Pro 14 (MBP-014), Dell 27 Monitor (MON-227), USB-C Dock (DOC-031)
- Users: alice(admin), ben(staff), carla(viewer)

ترتيب اللصق

ألصق موجهاتك بهذا الترتيب حتى يبقى التطبيق متسقًا:

1. الموجه الأساسي (القواعد العامة، الستاك، التسمية، التعامل مع الأخطاء)
2. الشاشات والتنقل (Inventory, Requests, Loans, Admin queue)
3. المصادقة والأدوار (admin, staff, viewer)
4. مخطط PostgreSQL وبيانات البذرة (items, loans, requests, users)
5. API CRUD بـ Go (نقاط النهاية والتحقّق التي تطابق القواعد)

نتيجة جيدة تبدو هكذا: يستطيع الموظف طلب “MBP-014”، يقوم المدير بالموافقة مع تاريخ استحقاق، وتظهر قائمة المخزون أنه غير متاح مع اسم المستعير.

إذا كان البناء قريبًا لكن ليس صحيحًا، عدّل شيئًا واحدًا في كل مرة: شدّد صلاحيات الدور (viewer لا يجب أن يرى أزرار التعديل)، أعد صياغة قاعدة "سجل واحد فقط معار في كل مرة"، أو اطلب إعادة تسمية الحقول حتى تطابق تسميات الواجهة وأعمدة DB.

الخطوات التالية: التوسيع بأمان وإعادة استخدام مجموعة الموجهات

بمجرد عمل الأساسيات، عامل التغييرات التالية كإصدارات صغيرة. اختر ميزة واحدة، حدّد ماذا تعني كلمة "مكتملة"، ثم اطلبها.

ترتيب منطقي للعديد من التطبيقات:

• سجل تدقيق: سجّل من أي غير ماذا ومتى، واظهره على شاشة خاصة بالمسؤول.
• تحميل ملفات: أرفق مستندًا أو صورة بسجل، خزّن بيانات وصفية في Postgres، وحافظ على الوصول خلف المصادقة.
• إشعارات بسيطة: عرض تنبيهات داخل التطبيق (مثلاً “مخزون منخفض” أو “تعليق جديد”) مع إجراء "تحديد كمقروء".

عندما تكسر التغييرات البناء، لا تحاول إصلاح كل شيء مرة واحدة. استعد للخلف، ثم أعد تطبيق التغيير بموجه أصغر وأكثر تحديدًا. إذا كنت تستخدم Koder.ai، اللقطات والاسترجاع عمليان خاصة قبل تغييرات تمس مخطط DB، قواعد المصادقة، أو مكوّنات الواجهة المشتركة.

وضع التخطيط يساعد أيضًا عندما تمتد الميزة عبر عدة طبقات. اطلب منها إعادة صياغة الخطة أولًا (الشاشات، نقاط نهاية الـ API، تغييرات قاعدة البيانات، الأدوار)، ثم وافق على تلك الخطة قبل توليد الشيفرة. يمنع ذلك عدم التوافق الشائع حيث تتوقع الواجهة حقولًا لا يعيدها الـ API، أو يكتب الـ API في أعمدة غير موجودة.

إذا أردت الاستمرار خارج المنصة، صدّر الشيفرة المصدرية وعدّل في سير عملك الاعتيادي. احتفظ بمجموعة الموجهات بجانب المستودع كـ"تعليمات البناء" حتى تستطيع إعادة إنشاء التطبيق لاحقًا أو تعريف عضو جديد.

إذا كنت تبني على Koder.ai (koder.ai), تتوافق مجموعة الموجهات هذه جيدًا مع افتراضات React + Go + PostgreSQL للمنصة، ومن السهل التكرار بأمان باستخدام اللقطات أثناء تحسين المتطلبات.

أخيرًا، احفظ موجه قالب قابل لإعادة الاستخدام للمشروع التالي. احتفظ بالأجزاء الثابتة (الستاك، قواعد CRUD، اتفاقيات المصادقة والأدوار، أنماط Postgres) واستبدل الأسماء فقط. مع الوقت تصبح موجهاتك وصفة قابلة للتكرار بدل تجربة لمرة واحدة.