نظام إدارة تعلم ونظام CRM بـ205 000 سطر كود بواسطة وكلاء الذكاء الاصطناعي: ثمن التشغيل، وثلاث حالات للعميل المحتمل، ورمز واحد \r

• حجم قاعدة الكود دون فريق مطورين: 205 104 أسطر من TypeScript/TSX (121 853 سطراً في LMS موزعة على 532 ملفاً، و83 251 سطراً في CRM موزعة على 367 ملفاً)
• سطح واجهة البرمجة والواجهة الوكيلية: 47 موجّهاً و288 إجرائية tRPC في LMS (93 أداة) + 334 أداة في سجل CRM (257 أداة مكشوفة في الواجهة)
• نطاق خلل CRLF غير المرئي الواحد: 138 درساً من أصل 146 درساً تطبيقياً سجّلت صفر عمليات إرسال ناجحة بسبب رمز `\r` في نهاية السطر أثناء التحليل على الخادم
• حصيلة المراجعة العدائية قبل الإطلاق: 14 ثغرة خطيرة في الموجة الأولى + 5 عيوب أدخلتها الإصلاحات نفسها

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

يعمل نظاماي — منصة التعلم LMS (121 853 سطراً من TS/TSX، Next 16.2.6، React 19، Drizzle ORM، 58 ترحيلاً، 16 مساراً، 211 درساً، و55 محاكياً) ونظام CRM المرتبط به (83 251 سطراً، Prisma 7.

6، 48 نموذج قاعدة بيانات، BullMQ، وأربعة وكلاء ذكاء اصطناعي متصلين) — على نسخة واحدة من PostgreSQL. بنينا حزمتنا التقنية الخاصة لسببين: لا توفر أنظمة LMS الجاهزة عنصراً أساسياً يسمح للشبكة العصبية بأن تلعب أولاً دور طالب بمحفّز ضعيف، ثم تدرّب بعد ذلك وفق مقدمة خفية؛ وكان على نظام CRM أن يُركَّب فوق بوت مبيعات يعمل فعلاً على Telegram دون تكرار قواعد البيانات. بالمناسبة، استغرق إعادة طلاء 289 متغير ألوان عند تفريع CRM مساءً واحداً فقط، أما تنظيف بيانات العرض التجريبي الموروثة (205 طلباً تجريبياً، وقيمة احتياطية «هامش ربح 38%»، وشعارات مزيفة «مهام 7») فامتد على شهرين.

كيف عطّل رمز غير مرئي للإرجاع الكربوني \r 138 درساً، وإزالة التكرار، وOAuth؟

أخفى الخلل الأدهى في LMS نفسه عن سجلات الأخطاء تماماً. كان الطلاب يرون كتلة `:::practice` مُعرَضة بشكل صحيح، فيضغطون على «إرسال»، فتظهر لهم رسالة «لم يُعثر على كتلة التمرين». أظهرت إحصاءات قاعدة البيانات أن 138 درساً من أصل 146 سجّلت صفر عمليات إنجاز ناجحة بالضبط. أُنشئ المحتوى على نظام Windows بفواصل أسطر `CRLF` (`\r\n`): كان الواجهة الأمامية يوحّد النص قبل العرض، لكن المحلل على الخادم كان يُقسّم النص عند `\n`، تاركاً رمز `\r` غير مرئي في نهاية السطر:

```typescript // دون توحيد، يكسر \r النهائي المرساة $ في JS، // لأن النقطة (.) لا تشمل \r، فيُحلَّل حقل task فارغاً: md = md.replace(/\r\n?/g, "\n"); const match = line.match(/^(task|starter|goal|model|system)\s:\s?(.)$/i); ```

غيّر نفس الرمز `\r` بصمة التجزئة الخاصة بالنص أثناء تقطيعه إلى شذرات، مما اضطر النظام لإعادة دفع تكلفة توليد المتجهات الدلالية، ثم ظهر في المرة الثالثة في نهاية سر داخل ملف `.env`، مما تسبب في عودة خطأ `invalid_client` من Google OAuth (اكتُشف عبر فحص طول السلسلة النصية `awk -F= '/^GOOGLE_/ {print $1, length($2)}' .env` — 36 بايتاً بدلاً من 35).

لماذا لا يمكن الوثوق بالبيانات القادمة من المتصفح، وكيف يعمل سجل CRM

المكوّن من 334 أداة؟

كشفت المراجعة العدائية قبل الإطلاق عن 14 عيباً خطيراً، وكشفت مراجعة الإصلاحات المكتوبة لها عن 5 عيوب إضافية. في النسخة الأولى من التمرين، كان المتصفح نفسه يرسل إلى الخادم نص المهمة ومصفوفة `history`، مما سمح بتزييف أي رد عبر أدوات المطورين، وكانت 8 محاكيات من أصل 55 تحصل على 71 إلى 90 نقطة بمجرد نسخ نص المهمة في الإجابة. انتقلنا ببناء المقدمة وإعادة تركيب آخر 6 ردود بالكامل إلى الخادم، ورفعنا المهلة الزمنية لمصحح الدرجات من 30 إلى 60 ثانية.

في CRM، تقوم البنية المعمارية بأكملها على سجل واحد موحد من 334 أداة (257 أداة مكشوفة في الواجهة الوكيلية، و77 أداة نظامية مغلقة بعلامة `facadeExposed: false`). يمر كل استدعاء عبر خط أنابيب واحد موحد هو `invoke()`: لا تُستخرج هوية `acting_user` إلا من الجلسة (مع التمييز بين خطأي `missing` و`invalid`، كما في حالة إرسال معرّف جلسة بصيغة `api-...` أو معرّف سالب لمحادثة جماعية)، وتُنقَّى المعاملات بتعبير نمطي `SECRET_KEY_RE` قبل كتابتها في `audit_log`.

لماذا يُقسَّم زر واحد للعميل المحتمل إلى ثلاث حالات، وكيف تُرصد الاجتماعات اليتيمة على

Zoom؟

في المبيعات الفعلية، يكتب مندوب المبيعات للعميل عبر Telegram الشخصي، بينما يستمر البوت في موازاة ذلك بتذكير نفس الشخص. لذلك تطلّب الأمر تقسيم زر واحد هو «تولّي العميل» إلى ثلاث حالات مستقلة: «أتولّى الأمر» (تحديد المسؤول)، و«تم التواصل» (توثيق أول تواصل فعلي)، و«تم الاعتراض» (يصمت البوت ويُسلّم المحادثة إلى الإنسان). ولتجنب أن يتسبب نقران مزدوجان من مديرين مختلفين في تضارب على نفس البطاقة، يبحث CRM عن أقدم سجل حسب `telegram_id` ويقفله عبر `SELECT ... FOR UPDATE`. وعند إنشاء اجتماعات على Zoom وGoogle Calendar، يكون أول إجراء دائماً هو تنفيذ `INSERT` في قاعدة البيانات الخاصة بحالة `creating` وحقلين `zoom_state` / `gcal_state`، بحيث لا تبقى اجتماعات يتيمة غير مُسجَّلة في السحابة في حال تعطّل واجهة برمجة التطبيقات الخارجية.

تعمل هذه الآلية الخاصة بالمحاكيات التفاعلية والسجلات الوكيلية داخل [Hamidun Academy](https://academy.hamidun.com) (مع فترة تجربة مجانية مدتها 72 ساعة)، وضمن منظومة [Nomad AI](https://nomadnet.ai) / [agent.nomadnet.ai](https://agent.nomadnet.ai)، ونستعرض بنية أنظمة CRM وLMS الخاصة بنا بالتفصيل في [Vibe Club](https://hamidun.com/club).