نصائح ذهبية — هذا كل ما تحتاج معرفته
هيكلنا الكود (الدرس 8)، والنظام (الدرس 9). المتبقي هو البيانات. البيانات هي الأخطر. الكود يخطئ فيكتشفه الاختبار. النظام يخطئ فيكتشفه /health. البيانات تخطئ ولا يعرف أحد. تُكتشف بعد 3 أشهر في التقرير الربعي.
للوكيل: “اصنع المخطط بأعمدة صريحة وقيود بدلاً من JSONB. amount يجب أن يكون أكبر من صفر، وstatus يقبل قيماً محددة فقط.”
JSONB يقبل أي شيء. بعد 6 أشهر 100 صيغة مختلطة. الأعمدة الصريحة والقيود هي قانون البيانات. انتهاك القيد = رفض فوري من DB.
للوكيل: “أدخل هذا الإكسل في DB. يجب احترام قيود DDL. الصفوف التي تنتهك القيود افصلها في ملف منفصل مع التقرير.”
الوكيل ينفذ التحويل، قيود DB تتحقق. الصفوف المرفوضة تُبلَّغ مع السبب. أنت تتحقق من المرفوض فقط.
المخطط قانون أضعه بنفسي
قاعدة البيانات فيها مخطط (schema). المخطط يُعرِّف (定義) ما هي البيانات الصالحة وما ليست. NOT NULL, FOREIGN KEY, CHECK — يجب المرور من هذه القيود ليُخزَّن. لا يهم من يدخل البيانات. إنسان أو برنامج أو ذكاء اصطناعي — يستوفي المخطط يدخل، لا يستوفي يُرفض. نمط يعمل منذ 1970.
المخطط قانون. قانون أضعه بنفسي.
| حكم القانون | مخطط البيانات |
|---|---|
| قابل للتحقق | CHECK (amount > 0) — DB يتحقق تلقائياً |
| الانتهاك معرَّف | انتهاك NOT NULL، FOREIGN KEY — منفصل |
| قابل للإنفاذ | الانتهاك = رفض INSERT |
القانون ليس عدالة (正義) بل تعريف (定義).
مخطط بلا بيانات = مجتمع بلا قانون. أي أحد يدخل أي شيء. خطأ لا يُعرف. يُكتشف بعد 3 أشهر.
خط دفاع ثلاثي
الخط 1 — قيود DB (الأقوى): NOT NULL, UNIQUE, CHECK, FOREIGN KEY. لا يمكن تجاوزها.
الخط 2 — قواعد عمل (Rego): “خصم أكثر من 30% يحتاج موافقة مدير”. قواعد إعلانية خارج الكود.
الخط 3 — سقاطة الترحيل: DDL يتغير → yongol validate → ملف ترحيل (up + down) → تطبيق staging → تحقق بيانات → تطبيق إنتاج (بوابة موافقة).
نفس النمط، مجالات مختلفة
| الدرس 8: الكود | الدرس 9: النظام | الدرس 10: البيانات | |
|---|---|---|---|
| هل يُقرأ | filefunc | /health | DDL |
| هل يُتحقق | go test + tsma | CI/CD + صحة | قيود DB + Rego |
| هل يُتراجع | git revert | صورة سابقة | migration down |
| هل يُحفظ التقدم | session.json | Terraform state | سجل الترحيل |
كلها نفس البنية: أعلن، تحقق، أقفل، احفظ.
رؤية الدرس 10
عالم الدرس 1:
"اصنع تطبيق" → كود يخرج → ينهار عند 5 ميزات
عالم الدرس 10:
"اصنع SaaS إدارة طلبات"
→ القرارات: تعريف المخطط، إعلان الميزات، إعلان القواعد
→ الكود: yongol يولّد من SSOT (الدرس 8)
→ النظام: CI/CD يؤتمت البناء-النشر-المراقبة (الدرس 9)
→ البيانات: DDL يفرض المخطط، Rego يتحقق من القواعد (الدرس 10)
→ الموافقة: الإنسان يضغط "موافقة" فقط
→ لا ينهار عند 200 endpoint
| الدرس | ماذا تعلمنا | النتيجة |
|---|---|---|
| 1 | البرمجة بالإحساس | “بالكلام يخرج كود” |
| 2 | لماذا ينهار | انحراف، تلاشي سياق، تملق |
| 3 | كيف نمنعه | Hurl, Git, CI/CD |
| 4 | جدار 200 endpoint | yongol — SSOT إعلاني |
| 5 | ذكاء اصطناعي بلجام | Reins Engineering 3 أعمدة |
| 6 | قفل وتقدم | Ratchet Pattern |
| 7 | عكس التملق | IFEval — التغذية تصنع التقارب |
| 8 | هيكلة الكود | filefunc + tsma |
| 9 | هيكلة النظام | 4 شروط — Agent Operable System |
| 10 | هيكلة البيانات | المخطط قانون — Agent Operable Data |
كود → نظام → بيانات. نفس المبدأ يعمل في المجالات الثلاثة.
أعلن، تحقق، أقفل، احفظ. القرار للإنسان، التنفيذ والتحقق للآلة. حكم القانون لا حكم الفرد.
بالكلام يُصنع. ليس الكود فقط، بل النظام والبيانات أيضاً. لكن هذا يحتاج لجاماً، وسكة، وقانوناً. تصميم ذلك اللجام والسكة والقانون هو Reins Engineering.
مقالات ذات صلة
سلسلة دروس Reins Engineering الكاملة
| الدرس | العنوان |
|---|---|
| الدرس 1 | كيف تأمر الذكاء الاصطناعي |
| الدرس 2 | كيف لا تثق بالذكاء الاصطناعي |
| الدرس 3 | التطبيق الذي لا ينكسر |
| الدرس 4 | القرارات خارج الكود |
| الدرس 5 | ذكاء اصطناعي بلجام |
| الدرس 6 | إذا نجح أقفله |
| الدرس 7 | كيف تعكس التملق |
| الدرس 8 | مصنع الوكيل |
| الدرس 9 | الأتمتة ما بعد الكود |
| الدرس 10 | قانون البيانات |
مصادر الأدلة
- E.F. Codd, “A Relational Model of Data” (1970) — الأساس النظري لسلامة البيانات القائمة على المخطط
- OPA / Rego — لغة سياسات إعلانية لتحقق قواعد العمل خارج الكود
- yongol DDL → sqlc — تحقق تبادلي متواصل من المخطط للكود
- مبدأ حكم القانون — قابلية التحقق، تعريف الانتهاك، قابلية الإنفاذ تنطبق على الكود والنظام والبيانات بالتساوي