الدليل المعماري الحرفي والمجرد لبناء أضخم الأنظمة والمنصات الرقمية بحجم فيسبوك دون كتابة سطر كود واحد. كيف تقود نماذج الذكاء الاصطناعي (سواء كانت خارقة مثل Claude 3.5 Sonnet / Opus أو نماذج مجانية وضعيفة مثل GPT-4o-mini و DeepSeek) عبر منهجية المصنع البرمجي الذاتي، وفصل التخطيط الاستراتيجي عن التنفيذ الميكانيكي، باستخدام خوارزميات الاستجواب (Grilling)، وخرائط القرارات (WayFinding)، وتقطيع المواصفات إلى تذاكر ميكروية مستقلة.
المهندس المحترف يدرك حقيقة بديهية: سير العمل (Workflow) وطريقة التفكير لا تتغير بتغير الموديلات؛ ما يتغير فقط هو أداة التنفيذ الميكانيكية وكتابة الكود. سواء كنت تستخدم محركات متطورة للأتمتة الذاتية (مثل نمط البطاطس Potato Mode في PeaStack)، أو أدوات مساعدة عبر الطرفية (Cline / Aider / Cursor)، أو مجرد نافذة شات عادية على متصفحك: القواعد الثلاث التالية مقدسة:
مستحيل أن تبدأ الميزة بكتابة كود. تبدأ دائماً ببحث استكشافي لحصر المعمارية، وفهم كيف تُبنى الأشياء، والمفاضلة بين البدائل والبروتوكولات، وتحديد تكاليف التشغيل، وفحص إمكانية الوصول في بيئات المستخدمين الواقعية.
الأفكار وطلبات المستخدمين تصل للنظام كـ Ready for Human (تحتاج عقلاً بشرياً لتشذيبها). الوكيل البرمجي (Coding Agent) سيتشتت ويولد هلاوس إذا ألقيت عليه تذكرة عامة. دورك كـ Vibe Coder هو تحويلها إلى Ready for Agent عبر تقطيعها لتذاكر ميكروية لا تتطلب أي قرار معماري.
عندما تصبح التذاكر مهندمة ومكتوبة بلغة المواصفة الصارمة، يمكن تشغيل وكيل برمجي ذاتي بالكامل في وضع الحلقة المغلقة (Autonomous Loop). يعمل الوكيل طوال الليل لحل عشرات التذاكر تباعاً، وفتح طلبات السحب (PRs)، وإجراء الاختبارات التلقائية دون أي تدخل بشري.
المصنع البرمجي ليس أداة سحرية، بل خط إنتاج متصل (Pipeline) يتكون من محطات عمل متتابعة. إذا اتبعت هذا الترتيب، ستتمكن من بناء أي نظام معقد بثقة مطلقة:
يتم تسجيل رغبة المستخدم كفكرة خام (مثل: "أريد التحكم في لابتوبي من هاتفي"). يتم فتح تذكرة تلقائياً موسومة بـ kind/idea و user-report. هذه التذكرة لا تُعطى للوكيل البرمجي لكتابة كود، بل تُعتبر نواة بحثية مجمدة Blocked on Research.
تجلس مع الذكاء الاصطناعي لصياغة تذكرة استكشافية مهندمة تحدد:
يتحول الذكاء الاصطناعي إلى محقق صارم (Interrogator). يفتح تذكرة أم لخريطة القرارات، ويطرح أسئلة جولة تلو الأخرى (Rounds). في نفس الوقت، يطلق وكلاء فرعيين في الخلفية (Background Sub-Agents) لإجراء أبحاث فنية سريعة وإرفاق نتائجها في تذاكر مستقلة لحسم كل معضلة بالأدلة.
يتم إخضاع القرارات الحساسة (الأمان، التشفير، التكلفة) لمناظرة معمارية بين نموذجين مختلفين (مثل Claude و Codex/GPT) لحسم الثغرات. بعد التوافق، يُولد الذكاء الاصطناعي وثيقة مواصفات موحدة (Spec) بصيغة Markdown، وتُدمج في الفرع الرئيسي بعد اجتياز فحص بوتات المراجعة المعمارية (debate-review).
تُقطع المواصفة إلى 20 إلى 40 تذكرة برمجية متناهية الصغر. كل تذكرة تركز على وظيفة ذرية واحدة (ملف واحد، أو اختبار، أو دالة)، وتربط بتصنيفات دقيقة وروابط اعتمادية (Blocked by). هذه التذاكر أصبحت الآن Ready for Agent.
يقوم وكيل التنفيذ (سواء أداة مستقلة أو نموذج مجاني يُعطى تذكرة واحدة) ببناء الكود والاختبارات التابعة له، وفتح Pull Request يتم فحصه آلياً ودمجه دون أي تداخل مع باقي أجزاء النظام.
المهارات البرمجية المعتمدة في مصانع الذكاء الاصطناعي المتطورة (المستوحاة من إطار عمل المهندس العالمي Mat Ryer على منصة aihero.dev/skills). إليك الشرح المعماري الدقيق لكل مهارة، وكيف تستدعيها، ومتى تستخدمها، وشروط عملها:
| الأمر البرمجي (Skill Command) | التصنيف | التعريف المعماري الدقيق | حالة الاستخدام الواقعية (متى تستدعيها؟) | المخرجات المتوقعة |
|---|---|---|---|---|
/wayfinder |
Shaping | رسم خريطة الجهد البرمجي الكبير كخريطة قرارات واستجوابك لحسمها قبل الكود. | عندما تطلب ميزة ضخمة غير واضحة المعالم وتحتوي على مفترقات طرق معمارية متعددة. | تذكرة خريطة رئيسية (Map Issue) تضم تذاكر فرعية للأبحاث والاستجوابات. |
/prototype |
Shaping | بناء نموذج تجريبي سريع مهمل (Spike) للتحقق من إمكانية تنفيذ فكرة معينة عملياً. | عندما تكون متردداً: هل المكتبة الفلانية تدعم الربط مع نظام ويندوز وماك بدون مشاكل؟ | كود استكشافي مؤقت يثبت أو ينفي الفرضية ويُحذف فوراً بعد انتهاء الغرض. |
/the-research-skill |
Shaping | إجراء بحث معمق مستقل في الإنترنت أو مستودع الكود لجمع حقائق دقيقة وموثقة. | للمفاضلة بين خدمات الخوادم (مثل Cloudflare vs Linode) وتكاليفها، أو فحص بروتوكولات الأمان. | تقرير بحثي بأدلة قاطعة يُرفق بتعليق داخل تذكرة البحث المعنية لإغلاقها. |
/approve-codebase-architecture |
Engineering | تقييم صحة هيكل المشروع المعماري ومنع تلوث الطبقات البرمجية والتبعيات الدائرية. | قبل الشروع في كتابة ميزة جديدة، للتأكد من وضع الملفات في مساراتها المعمارية الصحيحة. | تقرير مراجعة يعتمد الهيكل أو يفرض تعديلات تنظيمية صارمة. |
/diagnosing-bugs |
Engineering | تشخيص الأخطاء المعقدة بعزل السبب الجذري (Root Cause) بأدلة تجريبية قبل الترقيع. | عندما يفشل النظام في الإنتاج ويقترح الذكاء الاصطناعي العادي تخمينات عشوائية. | اختبار إثبات الخطأ (Reproduction Test) وتحديد السطر المسبب بدقة جراحية. |
/triage |
Engineering | فرز التذاكر الواردة وفحص تكرارها وتحديد مدى استحقاقها ووصف خطوات إعادة إنتاجها. | عندما يأتيك سيل من البلاغات والملاحظات وتحتاج لترتيب أولوياتها بدقة بشرية. | تصنيف التذاكر وتحديد ما يذهب للمصنع البرمجي وما يتم إغلاقه لعدم الجدوى. |
/to-spec |
Engineering | تحويل خطة عمل أو نقاش شات إلى وثيقة مواصفات معمارية تعاقدية صارمة. | بعد انتهاء الاستجواب، لصياغة الدستور النهائي الذي سيبنى الكود عليه بالملي. | ملف Markdown بمواصفة كاملة وشروط القبول وتدفقات الأخطاء. |
/ho-stickers |
Engineering | تقطيع مواصفة معمارية كبيرة إلى بطاقات وتذاكر عمل متناهية الصغر ومستقلة تماماً. | لتحويل وثيقة الـ Spec إلى 15 أو 35 تذكرة على GitHub جاهزة للوكلاء البرمجيين. | تذاكر مرقمة تحتوي كل منها على مسؤولية أحادية وروابط الاعتمادية (Blocked by). |
/implement-spec |
Engineering | كتابة الكود واختباراته مطابقة تماماً لشروط القبول المحددة في المواصفة. | عندما تبدأ في تنفيذ تذكرة واحدة محددة لإنتاج كود حقيقي واختبارات مرور. | كود إنتاج كامل ونظيف ومختبر يغلق التذكرة المخصصة. |
/code-review |
Engineering | فحص طلبات السحب مقابل معايير الأمان، الأداء، واختبارات التراجع والتوثيق. | قبل دمج أي سطر كود كتبه الذكاء الاصطناعي في الفرع الرئيسي للمشروع. | تقرير مراجعة بملاحظات محددة (P0 كارثي، P1 تحسين، أو اعتماد فوري). |
/jvetro |
Review | جلسة تأملية استرجاعية على دورة التطوير السابقة لتحسين كفاءة المصنع البرمجي الذاتي. | في نهاية كل أسبوع عمل، لتطوير أسلوب التوجيه وتقليل الهدر في استهلاك التوكنز. | توصيات لتحديث ملفات القواعد العامة وإرشادات الوكلاء. |
الاستجواب (Grilling) هو لب عملية التشكيل المعماري. لا تدع الذكاء الاصطناعي يطبطب عليك أو يفترض قرارات من رأسه. في هذه المرحلة، يجلس الوكيل أمامك ليطرح أسئلة صعبة على جولات، وفي نفس الوقت يطلق وكلاء فرعيين (Sub-Agents) للبحث المتزامن في الخلفية. إليك كيف تُدار هذه العملية بالتفصيل:
يسأل الذكاء الاصطناعي أسئلته التأسيسية لتحديد ما هو داخل النطاق (In-Scope) وما هو خارجه (Out-of-Scope)، مع تقديم توصيته المعمارية أمام كل خيار لتتمكن من حسمه بكلمة واحدة:
بينما تتناقش معه، يطلق الذكاء الاصطناعي مهام بحثية فرعية مستقلة، ويظهر في سطر الأوامر رسائل التتبع اللحظية:
Background agent completed - Research Remote Device surface options -> took 4m 50s
Still waiting on research agents...
Still waiting on research agents...
Received a message, ran 2 commands, finished a background agent!
Research: How pairing protocols exchange keys without exposing secrets is CLOSED.
Verified the Happy research comment and branch.
Result: Noise XX handshake protocol adopted. TLS-only rejected due to privacy risks.بهذه الطريقة، لا يُبنى أي قرار على "تخمين"، بل على أبحاث فنية مكتملة يضع الوكيل نتائجها في تذكرة البحث ويغلقها فوراً.
يفتح الذكاء الاصطناعي تذاكر استجواب فرعية مخصصة لكل ملف حساس، مثل:
في القرارات الحساسة (مثل اختيار نموذج تشفير السيرفر الوسيط: هل نكتفي بـ TLS أم نشترط التشفير التام من النهاية للنهاية E2E؟)، تستدعي نموذجاً آخر للتحكيم باستخدام أمر التفويض:
/codex delegate debate these along with your answers with codex ASTRA on high effortيحدث سجال معماري بين النموذجين، وعندما يتم الاتفاق على نموذج الأمان الأقوى، يتم تسجيل النتيجة في التذكرة بصفتها Resolved with the Founder وتغلق التذكرة رسمياً.
السبب الرئيسي في تخريف نماذج الذكاء الاصطناعي مع تقدم المشروع هو تلوث السياق (Context Rot). في المصنع البرمجي، يتم إنشاء وتحديث ملف مركزي حي يسمى CONTEXT.md في جذر المشروع. كلما حسمت جلسة WayFinder مصطلحاً أو قاعدة، تُحقن فوراً في هذا الملف، بحيث يقرأه أي وكيل جديد قبل أن ينطق بكلمة واحدة:
# CONTEXT.md — Living System Terms & Invariants
## Core System Glossary (المصطلحات القاموسية الموحدة)
- **Host / Computer**: The primary machine running the central processing engine and local workspace. It holds the source code and root file system.
- **Remote Client / Device**: A secondary authorized interface (mobile app, web portal) connected via relay to monitor and steer the Host.
- **Relay Router**: A minimal routing relay that forwards encrypted traffic between Host and Remote Clients without inspecting payloads.
- **Pairing Code**: A cryptographically bound 6-digit transient secret with a 2-minute lifetime used for initial Noise handshake.
## System Invariants & Non-Negotiables (القواعد المعمارية الثابتة التي لا تخرق)
1. **End-to-End Encryption**: The Relay Router is a blind forwarder. Payload decryption keys are strictly held in Host and Remote Device secure storage.
2. **First-Answer-Wins**: In concurrent steering events between Host and Remote Client, the earliest cryptographically signed message takes precedence.
3. **Local Independence**: The Host must be 100% operational offline without requiring any cloud connection or external account.
4. **Scope Boundaries**: Remote devices cannot add new project repositories or alter root API credentials in v1.
## Active System Limits (الحدود التشغيلية المستدامة)
- Maximum paired Remote Clients per Host: 5 devices.
- Maximum registered Hosts per User: 3 machines.
- Relay bandwidth threshold: 20 MB/session per month on the sustainable tier.CONTEXT.md في أول رسالة. النموذج لن يسألك أسئلة غبية، ولن يخلط بين مسميات العميل والخادم، ولن يقترح حلولاً تكسر القواعد المعمارية الثابتة (Invariants)، لأن الدستور مكتوب أمامه بحروف قاطعة.
هذه هي المطالبات الهندسية الكاملة، مصممة وجاهزة للاستخدام الفوري عبر النسخ واللصق في أي نافذة ذكاء اصطناعي لتقمص أدوار مهارات مات ومحرك المصنع البرمجي بالكامل:
أنت الآن تلعب دور "المهندس المعماري الموجه ومحرك مهارة WayFinder المعمارية".
أنا الـ Vibe Coder (مدير المشروع المعماري)، ولدي فكرة ميزة ضخمة أريد تخطيطها وهي:
[اكتب فكرة الميزة الكبيرة هنا بالتفصيل، مثلاً: بناء نظام إدارة دفع واشتراكات عالمي مع مزامنة صلاحيات المستخدمين لحظياً].
مهمتك الصارمة:
1. محظور تماماً كتابة أي سطر كود برمجي، أو اقتراح حلول تنفيذية مسبقة، أو القفز إلى التكنولوجيا دون تدقيق.
2. مهمتك هي "رسم خريطة الجهد البرمجي الكبير كخريطة قرارات واستجوابي لحسمها" (Chart a large effort as a map of decisions, and settle them).
3. ستقوم بتقسيم عملنا إلى جولات استجواب (Rounds).
4. في الجولة الأولى (Round 1)، اطرح عليّ 4 إلى 5 أسئلة جوهرية تتعلق بـ:
- س1: المخرج النهائي المتوقع (Deliverables of the map).
- س2: ما هو داخل نطاق الإصدار الأول (In-Scope v1).
- س3: ما هو مستبعد صراحة من الإصدار الأول لتقليل المخاطر (Out-of-Scope).
- س4: أين تُسجل وتعيش هذه القرارات (تذكرة مركزية أو ملف موحد).
- س5: المصطلحات القاموسية الأساسية للمشروع.
5. أمام كل سؤال، اكتب خيارات محددة متبوعة بـ [توصيتك المعمارية الموصى بها] لتمكيني من الاختيار الفوري.
6. لا تنتقل للجولة التالية حتى أوافق أو أعدل على إجابات الجولة الحالية.
ابدأ الآن فوراً بالجولة الأولى (Round 1).أنت الآن تلعب دور "وكيل الأبحاث الفنية المعمارية المستقل (Autonomous Research Sub-Agent)".
المطلوب منك إجراء بحث استقصائي محدد لحسم معضلة فنية تواجه مشروعنا:
المعضلة المطلوب حسمها:
[اكتب السؤال الفني، مثلاً: ما هو أفضل بروتوكول اتصال رخيص وعالي الكفاءة لنقل إشعارات لحظية بين متصفح وسيرفر خلف NAT: WebSockets أم SSE أم WebRTC مع حساب التكاليف المتوقعة لـ 10,000 مستخدم نشط؟]
شروط البحث والمخرجات:
1. اذكر الحقائق والأرقام المجردة بدون أي حشو تسويقي.
2. اذكر عيوب كل خيار وتكلفته التشغيلية الشهرية والسنوية.
3. افحص مدى استقرار الخيار في مختلف الدول وخاصة دول الشرق الأوسط وهل هناك حجب لبروتوكولاته.
4. اذكر سابقة أعمال لتطبيقات عالمية اعتمدت هذا الخيار وكيف تفادت مشاكله.
5. اختم بقرار معماري قاطع وحاسم (Final Architecture Verdict) بصيغة جاهزة للحقن في تذكرة GitHub أو ملف المواصفة.أنت الآن تلعب دور "محقق الاستجواب المعماري الصارم (The Grilling Agent)".
لدينا قرار معماري معلق في المشروع وهو:
[اكتب موضوع الاستجواب، مثلاً: حسم صلاحيات واجهة المستخدم على الموبايل مقابل صلاحيات تطبيق سطح المكتب، وسياسة التعامل مع انقطاع الإنترنت أو نوم الحاسوب].
قواعد الاستجواب:
1. مهمتك هي استجوابي (Grill me) كمدير المشروع، وعصر كافة السيناريوهات المحتملة.
2. فتش عن الحالات الشاذة وحالات الحافة (Edge Cases):
- ماذا يحدث لو انقطع الاتصال في منتصف العملية؟
- ماذا يحدث لو كان هناك مستخدمان يعطيان أمرين متناقضين في نفس الثانية؟
- ما هي الصلاحيات المسموح بها للموبايل؟ وما هي الخطوط الحمراء التي تظل حصرية للحاسوب الأساسي؟
- كيف سيبدو الخطأ للمستخدم العادي غير التقني؟
3. اطرح أسئلتك على هيئة خيارات واضحة مع توصيتك الفنية الأكثر أماناً واستدامة.
4. بعد استلام إجاباتي، اكتب ملخص القرار بصيغة: "Resolution: Decided with the Founder on [Date]" تمهيداً لغلق ملف الاستجواب.أنت الآن مجمع المواصفات الهندسية ومحرك مهارة (/to-spec).
انتهت كافة جولات الاستجواب وأبحاث الوكلاء الفرعيين لميزتنا الكبيرة. إليك ملخص القرارات المتفق عليها:
[ألصق هنا إجابات جولات الاستجواب ونتائج الأبحاث].
المطلوب:
توليد وثيقة المواصفات المعمارية الكاملة (v1 Production Feature Specification) بصيغة Markdown نظيفة ومكتملة، وتتضمن:
1. الوعد البرمجي للخاصية (Feature Promise) باللغتين العربية والإنجليزية.
2. جدول الصلاحيات: ما يفعله العميل الخارجي، وما يبقى حصراً على الخادم الأساسي.
3. بروتوكول الأمان والتشفير المعتمد وتدفق تبادل المفاتيح خطوة بخطوة.
4. حدود الاستخدام المستدام والتعامل مع استنزاف الموارد والتكاليف.
5. سلوك النظام في وضع عدم الاتصال (Offline) وحالات انقطاع الخدمة.
6. شروط القبول الصارمة للاعتماد والدمج (Acceptance Criteria).
ممنوع كتابة كود تنفيذي داخل هذا الملف؛ الملف هو وثيقة تعاقدية هندسية فقط.أنت الآن محرك مهارة تقطيع التذاكر الميكروية (/ho-stickers).
أمامك وثيقة المواصفات المعمارية المعتمدة التالية:
[ألصق وثيقة المواصفات هنا].
المطلوب:
تقطيع هذه المواصفة إلى تذاكر تنفيذية متناهية الصغر ومستقلة تماماً (Micro Implementation Tickets).
شروط التذاكر الصارمة:
1. كل تذكرة يجب أن تكون ذرية (Atomic): تختص بملف واحد فقط، أو دالة واحدة، أو كتابة اختبار محدد، أو تصميم مكون UI واحد.
2. التذكرة يجب أن تكون "Ready for Agent": بحيث يستطيع أي نموذج ذكاء اصطناعي ضعيف أو مجاني فهمها وتنفيذها دون الحاجة لطرح أي سؤال إضافي.
3. هيكل كل تذكرة يجب أن يشمل:
- الرقم والعنوان الوصفي.
- الهدف الدقيق (Goal).
- المدخلات والملفات المعنية (Files to touch).
- الاعتماديات: هل هي معطلة على تذكرة سابقة؟ (Blocked by #...).
- شروط القبول والنجاح (Acceptance Criteria & Test verification).
4. رتب التذاكر بتسلسل منطقي بحيث تُبنى الأساسيات أولاً، تليها التبعيات، وأخيراً الواجهات وتكامل النظام.
ولد قائمة التذاكر كاملة ومفصلة.أنت الآن وكيل التنفيذ البرمجي الذاتي في وضع حلقة البطاطس المغلقة (Potato Mode Autonomous Coder).
أنت مكلف حصرياً بتنفيذ التذكرة رقم: [رقم وعنوان التذكرة].
سياق النظام وقاموسه تجده في ملف: [ألصق محتوى CONTEXT.md].
نص التذكرة وشروط قبولها: [ألصق نص التذكرة الميكروية المختارة].
تعليمات التنفيذ الصارمة:
1. التزم بحل المطلوب في التذكرة فقط لا غير؛ ممنوع منعاً باتاً التعديل في أي ملفات أخرى خارج النطاق المذكور.
2. التزم التزاماً حرفياً بأسماء المتغيرات والكيانات المحددة في CONTEXT.md.
3. اكتب الكود البرمجي كاملاً بدون اختصارات أو تعليقات مثل (// write code here).
4. اكتب اختبارات الوحدة (Unit Tests) المقابلة لهذا الكود والتي تثبت استيفاء كافة شروط القبول المذكورة في التذكرة.
5. تأكد من أن جميع الاختبارات تمر بنجاح 100%.
6. جهز نص رسالة الـ Commit وملخص طلب السحب (PR Description) بصيغة جاهزة للدمج الفوري.هذا هو الدليل العملي الكامل لتطبيق المنهجية خطوة بخطوة لبناء نظام معقد بدون أي خبرة كود، على مشروع واقعي: "بناء منصة تزامن سحابية وتحكم فوري في بيئات العمل وتوزيع المهام الذكية".
بدلاً من أن تقول "اعمل لي سيستم مزامنة"، تفتح ملفاً في مشروعك أو Issue على GitHub باسم:
RFC: Explore device sync and remote execution channel
وتكتب فيه: الاتجاه هو ربط الأجهزة ببعضها، السبب هو تمكين المستخدم من متابعة المهام خارج المكتب، النطاق المبدئي هو الإشعارات وتغيير الحالة، وما هو خارج النطاق قطعياً هو نقل الملفات الكبيرة لتفادي التكلفة.
تنسخ المطالبة #01 (WayFinder) في نافذة الشات. يبدأ الذكاء الاصطناعي بطرح الأسئلة:
- "هل تريد مزامنة البيانات عبر خادم مركزي يرى كل البيانات، أم تشفير تام E2E؟" ➔ تختار E2E بناءً على توصيته.
- "ماذا نفعل لو انقطع النت؟" ➔ يوصي بنظام Queue محلي يعيد المحاولة تلقائياً عند عودة الاتصال.
تأخذ الأسئلة الفنية وتطلب من وكيل الأبحاث (المطالبة #02) فحص تكلفة خوادم WebSocket المجانية والمدفوعة. ثم تستخرج منه ملف CONTEXT.md الذي يحدد بدقة أسماء الكيانات: (MasterNode، WorkerNode، EncryptedPacket).
تستخدم المطالبة #04 لتوليد ملف spec-v1.md، ثم تستخدم المطالبة #05 لتقطيعها إلى 30 تذكرة مستقلة. تصبح التذاكر على النحو التالي:
Ticket 01: Create cryptographic key generation utility using sodium library.
Ticket 02: Build local SQLite persistence store for unsent event queue.
Ticket 03: Implement 6-digit numeric pairing PIN code generator with 120s TTL.
Ticket 04: Build WebSocket blind forwarder relay service with connection registry.
Ticket 05: Build pairing confirmation UI dialog with accept/reject buttons.
الآن تأخذ كل تذكرة على حدة، وتضعها في أداة الكود (أو حتى في نافذة شات مجانية جديدة مع ملف CONTEXT.md) وتستخدم المطالبة #06.
النموذج الآن لا يفكر ولا يتفلسف ولا يخطئ؛ هو فقط يكتب دالة التذكرة المحددة واختبارها. تجمع النتائج وتدمجها تباعاً. تهانينا، لقد قمت ببناء منصة متكاملة ومعقدة بمستوى مهندسي وادي السيليكون دون أن تكتب حرف كود واحد بيدك!