كيف بنيت OMLA بتوجيه وكلاء ذكاء اصطناعي بدلاً من كتابة الكود بنفسي

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

ما تحصل عليه في النهاية

قبل أي شرح للطريقة، إليك ما خرج من الطرف الآخر: OMLA، جمعية ترخيص النماذج المفتوحة (Open Model Licensing Association). نظام خلفي لترخيص الإتاوات وموقع عام لنماذج الذكاء الاصطناعي المفتوحة.

البند	النتيجة
الوضع	قيد التأسيس كمنظمة غير ربحية في ولاية واشنطن، وطلب الإعفاء الضريبي 501(c)(3) قيد المراجعة. الموقع يحمل شارة "Beta 0.9.0" عن قصد.
الصفقة	مجاني للاستخدام الشخصي والبحثي والتعليمي. الاستخدام التجاري يستحق 30% من الأكبر بين: الإيرادات المنسوبة أو تكلفة تشغيل النموذج.
قاعدة البيانات	12 جدولًا أساسيًا، Postgres 17 على Supabase، أمان على مستوى الصف في كل مكان، وحسابات الأموال بوحدة السنت الصحيحة (لا أرقام عشرية إطلاقًا)
الهوية	توقيعات هجينة ed25519 + ML-DSA-65، كلاسيكية وما بعد كمومية معًا، بحيث لا يُسقط اختراق كمومي مستقبلي النظام بأكمله. بلا توقيع مُتحقّق منه، لا يوجد بيان إتاوة.
أثر التدقيق	إضافة فقط، بسلسلة تجزئة SHA-256، يُتحقق منها كل ساعة، مع "مرساة" يومية لطرف السلسلة تُخزَّن خارج قاعدة البيانات تمامًا
الواجهة الأمامية	نحو 30 صفحة HTML ثابتة بسيطة، بلا أي إطار عمل، بـ13 لغة، على استضافة مشتركة عادية
من بناه	إنسان واحد ينظّم حركة المرور، وClaude Code يكتب الكود، وسرب محلي من وكلاء نماذج مفتوحة ينفّذ جولات المراجعة والأعمال الروتينية
أين يقف الآن	مُجهَّز ومُختبَر بالكامل. النشر يقتصر على تجربة جافة إلى أن أكتب "GO" بنفسي.

خط زمني تقريبي، تحسّبًا لمن يظن أن هذا حدث في عطلة نهاية أسبوع:

• أواخر مايو 2026 — تحوّل من مشروع شخصي لروبوت محادثة إلى منظمة غير ربحية للترخيص، مع مخطط قاعدة بيانات أولي من 12 جدولًا
• خلال أيام — تقوية التوقيعات ما بعد الكمومية، ودوال الحافة الخاصة بمسار الأموال، وإعادة الكتابة إلى نموذج "بلا حيازة" (تفصيل أدناه)
• أوائل يونيو — دفع النظام الخلفي إلى الإنتاج (قاعدة البيانات، لا الواجهة الأمامية العامة)
• 16 يونيو — اكتملت إعادة الصياغة القانونية، ودخل ترخيص الإصدار 1.0 حيز التنفيذ
• 2 يوليو — تحديث شامل للموقع والنظام الخلفي وإعادة ترجمة لـ13 لغة، مُجهَّز ومُختبَر، وما زال ينتظر "GO" مني وقت كتابة هذه السطور

طرفة عن الأصل: كان اسم OMLA يعني في البداية "Open Machine Learning Assistant"، مشروع روبوت محادثة شخصي. اختيارات البنية التحتية انتقلت كما هي إلى التحوّل نحو الترخيص، بينما تراجع روبوت المحادثة إلى مساعد توثيق محدود النطاق ومُعطَّل عمدًا في الإنتاج. تحويل روبوت محادثة كهواية إلى بنية ترخيص تحتية — زحف نطاق طبيعي تمامًا، أليس كذلك؟

القاعدة الواحدة التي جعلت كل ما تبقّى ممكنًا

قرار تصميمي واحد أنجز معظم العمل الشاق، قبل كتابة أي سطر كود: OMLA لا يحرّك الأموال أبدًا، ولا يحتفظ بها، ولا ينقلها. يحسب المبلغ المستحق وينشر محفظة المستفيد أو بيانات الدفع التي قدّمها بنفسه. المستخدم التجاري يدفع للمبدع مباشرة، من طرف لطرف. لا معالجة دفعات، لا ضمان مالي (escrow)، لا "رصيد OMLA". معرّفات المحافظ هي معلومات توجيه، لا حسابات.

صياغة الترخيص تقولها بوضوح: "OMLA publishes; OMLA does not pay" (أي: OMLA ينشر؛ OMLA لا يدفع).

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

ولم يكن هذا التصميم الأصلي حتى. في منتصف البناء، كان المخطط لا يزال يوحي بالحيازة، لذا أُعيدت تسمية جدول اسمه حرفيًا payments إلى royalty_statements — ترحيل كامل للأعمدة والفهارس والمُشغِّلات (triggers) وسياسات RLS والتعدادات (enums)، فقط لجعل قاعدة البيانات تتوقف عن الكذب بشأن ما تفعله. الصياغة القديمة عادت لتؤذيني لاحقًا رغم ذلك (انظر المطبّات الشائعة).

إليك الطريق الذي يسلكه دولار الإتاوة دون أن يلمسه OMLA إطلاقًا.

الخطوة 4 هي البوابة: بلا توقيع مُتحقق منه في الخطوة 1، لا يوجد بيان إتاوة أبدًا. OMLA ينشر الرقم والمحفظة، وبعدها الأمر بين طرفين آخرين — تمامًا كأن أخبرك أن صديقًا يدين لك بعشرين دولارًا وأترك لكما تسوية الأمر.

الحلقة الفعلية: إنسان، وكلاء، تحقّق، نشر

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

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

النظام الخلفي بأكمله يعمل محليًا أولًا: بيئة Supabase حقيقية، Postgres 17 مع دوال حافة، على جهازي الخاص في حاويات بلا صلاحيات جذر (rootless). الإنتاج هو وجهة نشر، لا مصدر الحقيقة أبدًا. إن اختلفت النسخة المحلية عن الحية، فالنسخة الحية هي المخطئة إلى أن أشحن التغيير.

معيار الجودة موجود في إعدادات المشروع، لا في رأسي فقط: "Audit-ready by default: ship work that can withstand external audit." (أي: جاهز للتدقيق افتراضيًا: اشحن عملًا يصمد أمام تدقيق خارجي). كل عمل يفترض أن مراجعًا مستقلًا، ذكاءً اصطناعيًا كان أم إنسانًا، سيحاول لاحقًا إيجاد ثغرات فيه.

الاختبار مقابل بيئة حقيقية، لا محاكاة

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

deno test                  # 13 unit tests for the edge functions
./test/run.sh              # isolated scratch DB per run, migrations w/ ON_ERROR_STOP,
                            # smoke tests (PQ signatures, wrong-key rejection, audit
                            # hash-chain, payout gate), RLS cross-tenant isolation,
                            # an adversarial suite, then rollback + reapply
./test/integration.sh      # the full money path against the live local stack:
                            # register → tampered payload rejected → wallet verify →
                            # splits → usage report → statement published → replay
                            # (asserts zero duplicate writes) → admin gate → compliance

سطر "إعادة الإرسال مع التأكد من صفر كتابات مكرَّرة" أهم مما يبدو. تقارير الاستخدام تأتي من أنظمة أشخاص آخرين، لذا سيُعاد إرسال أحدها بالخطأ يومًا ما؛ يتحقق الاختبار من أن إعادة إرسال التقرير نفسه تُنتج صفر بيانات جديدة، لا أن شيئًا لم ينهر فحسب. صُلِّبت الحزمة لاحقًا لتؤكد (assert) النتائج بدل تسجيلها فقط — يبدو الأمر متزمّتًا حتى تحتاج يومًا لتصحيح اختبار "نجح" وهو لا يفعل شيئًا.

تدقيقات تُقيّم تدقيقات أخرى

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

تلك البوابة الأخيرة ليست شكلية. في إحدى الجولات، تحقّقت من إصلاحات الوكلاء المحليين ومع ذلك عثرت على تجاوز في مسار البحث (search-path bypass) بالإضافة إلى ثغرات في الأعمدة والتوقيعات والنسب فاتها التمرير الأول. تحوّل ذلك إلى ترحيل تقوية مستقل بحد ذاته: اثنا عشر ملاحظة مرقّمة، كل واحدة شُحنت مع اختبار انحدار (regression test) حتى لا تعود بصمت.

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

بوابة النشر: تجربة جافة حتى أكتبها بنفسي

لدى مُشغِّل النشر وظيفة واحدة: التأكد من أن لا شيء أعلى هذا الخط يصل إلى الإنتاج بالخطأ. تجربة جافة افتراضيًا، في كل مرة؛ الإنتاج لا يُلمَس إلا بعلامة صريحة:

./deploy.sh              # dry run (default) — shows exactly what WOULD happen
./deploy.sh --go         # only a human runs this, only when ready

غلاف موجَّه (wrapper) يذهب خطوة أبعد: تكتب حرفيًا "GO" قبل أي خطوة تُعدِّل الإنتاج. والقاعدة الثابتة للوكلاء، مكتوبة حتى تتوقف عن كونها مجرد اقتراح: لا تُضِف --go أبدًا دون تعليمات بشرية صريحة.

ضمانات أخرى مدمجة في المُشغِّل نفسه، لا مجرد سياسة على الورق:

• مزامنة الواجهة الأمامية لا تستخدم --delete أبدًا، فلا يمكنها محو ملفات على الخادم لا تديرها
• يُؤخذ نسخ احتياطي من جانب الخادم قبل أي استبدال للواجهة الأمامية
• النظام الخلفي يرفض العمل إن لم يطابق المشروع المرتبط المشروعَ المتوقّع في الإنتاج — حاجز صلب ضد الدفع إلى قاعدة بيانات خاطئة
• لا يعمل على البعيد سوى ترحيلات إضافية فقط، لا إعادة تهيئة أبدًا
• دالة روبوت المحادثة للتوثيق مُستبعَدة من كل عملية نشر، كمبدأ
• الأسرار موجودة فقط في ملف بصلاحية 600 خارج المستودع؛ فحص نصي عادي يتأكد أن مفتاح دور الخدمة لا يظهر أبدًا فيما يُشحن

بصراحة، سجل النشر لهذا المشروع هو في معظمه يوميات لتردّدي: تجربة جافة تلو تجربة جافة بينما إعادة تصميم مُجهَّزة بالكامل تنتظر الكلمة. هذا ليس عيبًا. هذا هو الشعور الذي يُفترض أن يمنحه "مقيّد".

مطبّات شائعة

الأجزاء التي آلمت:

• البايت الصفري العرض. يجب أن يكون كود SQL للترحيل ASCII خالصًا. بايت واحد غير مرئي وغير ASCII يمكن أن يشقّ رمز الاقتباس $$ ويدمج جملتي SQL بصمت. أصبح الإصلاح طقسًا: فحص البايتات غير ASCII بـgrep (الهدف صفر) وعدّ رموز $$ (الهدف عدد زوجي)، في كل مرة.
• علامات النسبة المئوية تعضّ. في نص تنسيق RAISE EXCEPTION، %% علامة نسبة مئوية حرفية، وكل قيمة تحتاج بالضبط علامة % واحدة. عضّتني هذه مرة واحدة، وهذا هو السبب الوحيد لتدوينها الآن.
• SECURITY DEFINER يحتاج search_path مثبّتًا. كل دالة definer ودالة مُشغِّل تثبّت مسار بحثها حتى لا يستطيع أحد انتحال جدول في pg_temp وتغذيته ببيانات خاطئة. الاختبار العدائي يعدّ الدوال المثبّتة ويفشل إن انخفض العدد.
• مشرف النظام (superuser) المتقلّب. بعد إعادة تشغيل غير نظيفة، يعود دور Postgres المحلي أحيانًا بلا صلاحيات مشرف نظام. الإصلاح هو إيقاف وتشغيل نظيف للبيئة، لا استكشاف أخطاء. دُوِّن هذا حتى يتوقف الوكلاء عن إعادة اكتشافه.
• طبقة الترجمة تتجاوز HTML بصمت. طبقة الترجمة تتجاوز نص الصفحة بالكامل، لذا "إصلاح" HTML قد يستمر في تقديم صياغة قديمة إن لم يُصلَح ملف اللغة أيضًا. هذا بالضبط سبب عودة صياغة عصر الحيازة القديمة للظهور بعد أن كان يُفترض أنها أُزيلت.
• يمكن خداع سلسلة التدقيق، عن قصد، حتى نعرف ذلك. مهاجم بسيطرة كاملة على قاعدة البيانات يستطيع إسقاط مُشغِّل سلسلة التجزئة وإعادة بناء تاريخ مزيّف متّسق داخليًا؛ الفحص الداخلي وحده لن يكتشف ذلك. لذا مهمة يومية ترسو طرف السلسلة خارج قاعدة البيانات تمامًا، وتثبت حزمة الاختبارات الشقّين في تشغيل واحد: الفحص الداخلي يُخدَع، والمرساة الخارجية لا تزال تكتشف إعادة الكتابة.
• الموقع الحي ليس الموقع المُجهَّز. وقت كتابة هذه السطور، لا يزال الموقع العام يعرض بعض النصوص القديمة (مسودة ترخيص سابقة، بطاقة قديمة عن مسارات الدفع) لأن إعادة التصميم مُجهَّزة، لا منشورة. أيضًا، رابط /about العام مجرد فهرس دليل عارٍ؛ صفحة الإفصاح عن الذكاء الاصطناعي موجودة مستوى واحدًا أسفله.