الدرس 3. التطبيق الذي لا ينكسر — Hurl وGit وCI/CD

نصائح ذهبية — هذا كل ما تحتاج معرفته

أربع عبارات هي كل شيء.

للوكيل: “اصنع اختبار Hurl” يكتب الذكاء الاصطناعي عقداً يتحقق أن الميزة تعمل بشكل صحيح. نص عادي يمكن لغير المبرمج قراءته.

للوكيل: “أضف هذه الميزة. لكن يجب أن تمر اختبارات Hurl الحالية” هذه العبارة تمنع الانحراف. إذا أضاف الذكاء الاصطناعي ميزة جديدة وكسر ميزة قديمة، يخبرك Hurl بنص أحمر.

للوكيل: “اعمل commit” يحفظ الحالة الحالية. مثل نقطة الحفظ في اللعبة. إذا فشل العمل التالي ترجع هنا.

للوكيل: “ارجع” العودة لآخر نقطة حفظ. استعادة ما كسره الذكاء الاصطناعي.

نمط هذه العبارات الأربع

إكمال ميزة → “اصنع اختبار Hurl” → تأكيد النجاح → “اعمل commit” → الميزة التالية → “يجب أن تمر Hurl الحالية” → مشكلة؟ “ارجع”

هذه هي السقاطة (Ratchet). ترس يتقدم فقط ولا يرجع. سواء 5 أو 50 ميزة، الحالية لا تنكسر.

لماذا ينجح هذا؟

تعلمنا في الدرس 2: الرأي يُنتج تملقاً، الحقيقة تُنتج تصحيحاً. ما يرجعه Hurl ليس رأياً بل حقيقة. “test failed: status 401, expected 200” — لا مجال للتملق هنا.

تجربة سريعة

اصنع اختبار Hurl واحداً لتطبيق المهام من الدرس 2. 3 دقائق كافية.

للوكيل: “اكتب اختبار Hurl يتحقق أن ميزة إضافة المهام تعمل بشكل صحيح”

سينشئ الذكاء الاصطناعي ملف .hurl.

للوكيل: “شغّل اختبار Hurl”

إذا نجح يظهر أخضر. الآن اكسره عمداً.

للوكيل: “غيّر اسم id إلى todo_id في استجابة API إضافة المهام”

للوكيل: “شغّل اختبار Hurl”

يفشل بنص أحمر. هذا هو كشف الانحراف.

للوكيل: “ارجع”

أخضر مرة أخرى. هذا جوهر السقاطة.

لماذا يجب أن تأمر بهذه الطريقة

في الدرس 2 رأينا المشاكل. انحراف المنطق، تلاشي السياق، تحيز التملق. بعد 5 ميزات ينكسر الحالي، والذكاء الاصطناعي يعلن كذباً “يعمل جيداً”.

في هذا الدرس نتعلم ثلاث أدوات لمنع هذه المشاكل. كلها يستخدمها مهندسو البرمجيات منذ عقود. لا تحتاج لقراءة الكود. الذكاء الاصطناعي يكتب وينفذ. أنت تسأل فقط “هل نجح؟”

أدوار الأدوات الثلاث:

Hurl — إعلان عقود API بنص عادي

ما هو Hurl

Hurl هو ملف يسجل “كيف يجب أن يعمل هذا الـ API”.

بتشبيه اللعبة: في RPG عند شراء جرعة من NPC القاعدة هي “جرعة واحدة → -50 ذهب، +100 صحة”. التحقق أن هذه القاعدة لم تتغير بعد التحديث. هذا ما يفعله Hurl.

لنرى ملف Hurl فعلي:

# إضافة مهمة
POST http://localhost:8080/api/todos
{
  "title": "شراء حليب",
  "priority": "high"
}
HTTP 201
[Asserts]
jsonpath "$.id" exists
jsonpath "$.title" == "شراء حليب"
jsonpath "$.priority" == "high"
jsonpath "$.completed" == false

يمكن لغير المبرمج قراءته:

• POST — طلب “أضف” للخادم
• http://localhost:8080/api/todos — عنوان قائمة المهام
• { “title”: “شراء حليب” } — بيانات مرسلة
• HTTP 201 — استجابة النجاح يجب أن تكون 201
• jsonpath “$.title” == “شراء حليب” — البيانات المرجعة يجب أن تحتوي “شراء حليب”

هذا هو العقد. “عند إضافة مهمة يأتي 201، والعنوان والأولوية يرجعان كما هما.” إذا انكسر العقد يخبرك Hurl بنص أحمر.

واحد آخر:

# الوصول بدون مصادقة يُرفض
GET http://localhost:8080/api/todos
HTTP 401

“الوصول لقائمة المهام بدون تسجيل دخول يجب أن يرجع 401 (مصادقة مطلوبة).” هذا أيضاً عقد. إذا كسر الذكاء الاصطناعي كود المصادقة أثناء “التنظيف”، يكتشفه Hurl فوراً.

لماذا Hurl — الفرق عن اختبارات الوحدة

“لماذا Hurl وهناك أدوات اختبار كثيرة؟” للمبرمج بالإحساس سبب خاص.

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

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

Hurl يتحقق من السلوك وليس الكود. الكود يمكن للذكاء الاصطناعي تغييره بحرية. السلوك لا يجب أن يتغير. هذا التمييز هو مفتاح كشف الانحراف.

لماذا تنجح هذه الطريقة — الأبحاث تثبتها

تعلمنا تحيز التملق في الدرس 2. نصيحة “اكتب اختبارات” تختلف نتيجتها حسب كيف تُعطى.

بحث TDAD (Test-Driven AI Development, 2026) جرّب هذا بالضبط. طلب من AI إصلاح أخطاء مع شروط اختبار مختلفة:

نتيجة مذهلة. “اتبع TDD” يزيد الأمر سوءاً. لأن AI يتشتت محاولاً اتباع التعليمات الإجرائية. لكن “هذا الملف يجب أن ينجح” كسياق محدد يخفض الانحدار 70%.

الفرق واضح:

• “طوّر مع كتابة اختبارات” → تعليمات إجرائية → تشتت AI
• “ملف Hurl هذا يجب أن ينجح” → عقد محدد → انحدار أقل 70%

ليس تعليمات للطريقة، بل عقد بما يجب أن ينجح. “العبارة 3” أعلاه هي بالضبط هذا.

Git — نقطة حفظ يمكن العودة إليها

ما هو Git

في الألعاب تحفظ. قبل معركة البوس تحفظ، وإذا خسرت تحمّل.

Git هو ميزة الحفظ للكود. “هذه الحالة تعمل جيداً” → حفظ (commit). العمل التالي فشل → العودة للحفظ السابق.

البرمجة بالإحساس بدون Git:

ميزة 1 → تعمل
ميزة 2 → تعمل
ميزة 3 → ميزة 1 انكسرت!
→ أريد العودة... كيف كانت حالة ميزة 2؟
→ أقول للذكاء الاصطناعي "ارجع لما كان" → لا يعرف "ما كان"
→ أبدأ من الصفر

مع Git:

ميزة 1 → تعمل → commit (حفظ 1)
ميزة 2 → تعمل → commit (حفظ 2)
ميزة 3 → ميزة 1 انكسرت!
→ "ارجع للحفظ 2" → ميزة 1 و2 تعملان
→ أعيد ميزة 3 بطريقة مختلفة

استخدام Git: كلمتان تكفيان

لا حاجة لتعلم عشرات أوامر Git. المبرمج بالإحساس يحتاج شيئين.

“اعمل commit” — حفظ الحالة الحالية

"اعمل commit للحالة الحالية. الرسالة 'إكمال ميزة إضافة المهام'"

“ارجع” — استعادة الحالة السابقة

"ارجع لآخر commit"

أو أبعد:

"ارجع لـ commit 'إكمال ميزة إضافة المهام'"

متى تعمل commit

القاعدة بسيطة:

1. عند إكمال ميزة وعملها جيداً → commit
2. عند نجاح جميع اختبارات Hurl → commit
3. قبل البدء بميزة جديدة → commit حتماً

بدون commit عند حدوث مشكلة لا مكان للعودة إليه. مثل 3 ساعات لعب بدون حفظ.

نمط جيد:
إكمال ميزة → نجاح Hurl → commit → الميزة التالية

نمط سيء:
ميزة 1 → ميزة 2 → ميزة 3 → ... → شيء انكسر → لا مكان للعودة

CI/CD — الآلة تحرس تلقائياً

ما هو CI/CD

CI (التكامل المستمر) هو “تشغيل الاختبارات تلقائياً كل مرة يُرفع كود”. CD (النشر المستمر) هو “النشر تلقائياً عند نجاح الاختبارات”.

الآن يكفي معرفة CI. CD لاحقاً.

بدون CI:

أنت: "أضف ميزة"
AI:  "تم!"
أنت: (تتحقق من الميزة الجديدة فقط في الشاشة) "ممتاز!"
→ لا تعلم أن ميزة قديمة انكسرت وتمضي

مع CI:

أنت: "أضف ميزة"
AI:  (يكتب الكود)
الآلة: (تشغّل جميع اختبارات Hurl تلقائياً)
الآلة: "اختبار تسجيل الدخول فشل!"
أنت: "تسجيل الدخول انكسر. أصلحه."
AI:  (يصلح)
الآلة: "جميع الاختبارات نجحت"
أنت: "اعمل commit"

لا تحتاج لتشغيل Hurl يدوياً كل مرة. الآلة تشغّلها تلقائياً.

الأدوات الثلاثة معاً: قفل السقاطة

Hurl + Git + CI تصبح سقاطة (ratchet). ترس يدور في اتجاه واحد فقط. يتقدم عند الدوران، يتوقف عند التحرير لكن لا يرجع.

ميزة 1 مكتملة → اختبار Hurl → الكل نجح → commit → قفل
ميزة 2 مكتملة → اختبار Hurl إضافي → الحالي + الجديد نجحا → commit → قفل
ميزة 3 قيد العمل → اختبار Hurl حالي فشل → commit مرفوض → إصلاح → الكل نجح → commit → قفل

القواعد بسيطة:

1. عند نجاح اختبار Hurl يُقفل
2. الاختبار المقفل لا يُحذف ولا يُعدَّل
3. عند إضافة ميزة جديدة يُضاف اختبار Hurl جديد
4. يجب نجاح جميع الاختبارات الحالية + الجديدة للـ commit

عندما تطلب “أعد هيكلة الكود”، يغيّر AI الكود بحرية. لكن إذا انكسر اختبار Hurl يُرفض الـ commit. يجب على AI الحفاظ على جميع السلوكيات الحالية أثناء العمل.

كيف تُحل مشاكل الدرس 2

الملخص

ما تعلمناه:

1. Hurl — يعلن “يجب أن يعمل هكذا” كعقد بنص عادي. يتحقق من السلوك لا الكود
2. Git — ينشئ نقطة حفظ “يمكن العودة لهذه اللحظة”
3. CI/CD — يركّب التحقق الآلي “فحص تلقائي كل مرة”
4. السقاطة — الثلاثة معاً “إذا نجح يُقفل ولا يرجع”

المبدأ الأساسي:

لا تعلّم AI الطريقة. أعطه عقداً بما يجب أن ينجح.

“اتبع TDD” → الانحدار يزداد. “Hurl هذا يجب أن ينجح” → الانحدار ينخفض 70%. الفرق بين التعليمات والعقد.

لا تغيّر النموذج، أضف عقوداً.

تمهيد للدرس التالي

في الدرس 3 تعلمنا حماية كل API بـ Hurl. لكن مع كبر المشروع ليست API فقط ما يحتاج حماية. بنية قاعدة البيانات، سياسات الأمان، مكونات الواجهة — كلها يجب أن تتطابق.

في الدرس 4 نتعلم yongol. إدارة API وDB والأمان والواجهة بمواصفات إعلانية واحدة، ونقل هدف عمل AI من الكود إلى المواصفات. الطريقة لاختراق جدار 200 endpoint الذي تنهار عنده البرمجة بالإحساس.

مقالات ذات صلة

• Hurl يمنع انحراف البرمجة بالإحساس
• Ratchet Pattern

سلسلة دروس Reins Engineering الكاملة

مصادر الأدلة

• TDAD (Test-Driven AI Development) 2026 — تعليمات إجرائية “اتبع TDD” ترفع الانحدار لـ 9.94%، توفير ملف اختبار في السياق يخفض الانحدار لـ 1.82% (انخفاض 70%)
• تجربة Ratchet Pattern — وكيل ذاتي 40/527 (7.6%) مقابل سقاطة CLI 527/527 (100%)، نفس النموذج مع اختلاف من يقرر الانتهاء