أدرجت النسخة المصغرة من هذا الموضوع هنا لأن سلسلة "محفزاتي المفضلة" من المفترض أن تكون قطع صغيرة وصغيرة الحجم ومكتفية ذاتيا. لكن اليوم حولت هذا النظام إلى نظام مجنون حقا. ليس من المهم إذا كنت تصنع برنامج CRUD آخر في React أو قائمة مهام، لكن إذا كنت تقوم بشيء معقد جدا في Rust أو Golang، أو شيء يتعلق ببيانات معقدة، فهذا النهج مخيف تقريبا فيما يمكنه القيام به. إنها عملية من جولتين. إليكم الجولة الأولى: --- أولا اقرأ كل ملفات AGENTS dot md وملف README dot md بعناية فائقة وافهم كل اللغتين! ثم استخدم وضع وكيل التحقيق في الكود لفهم الكود بالكامل والبنية التقنية والغرض من المشروع. ثم، بعد أن تقوم بعمل دقيق وشامل للغاية وتفهم النظام بأكمله وما يفعله، وغرضه، وكيف يتم تنفيذه وكيف ترتبط كل الأجزاء ببعضها البعض، أحتاجك إلى تحقيق مكثف ودراسة وتأمل عميق حول هذه الأسئلة كما تتعلق بهذا المشروع: هل هناك أي أوجه قصور جسيمة أخرى في النظام الأساسي؟ الأماكن في قاعدة الكود حيث 1) التغييرات ستحرك فعليا من حيث التأخير العام/الاستجابة وسرعة النقل؛ 2) بحيث تكون تغييراتنا قابلة للإثبات من حيث الوظيفة بحيث نعرف بالتأكيد أنها لن تغير المخرجات الناتجة إذا تم استخدام نفس المدخلات؛ 3) حيث يكون لديك رؤية واضحة لنهج أفضل بوضوح من حيث الخوارزميات أو هياكل البيانات (لاحظ أنه لهذا، يمكنك تضمين في تأملاتك هياكل بيانات أقل شهرة وخوارزميات أكثر تعقيدا/تعقيدا/رياضية بالإضافة إلى طرق لإعادة صياغة المشكلة بحيث يتم كشف نموذج آخر، مثل القائمة الموضحة أدناه (ملاحظة: قبل اقتراح أي تحسين، قم بتحديد مقاييس الأساس (زمن الاستجابة p50/p95/p99، معدل الإنتاجية، الذاكرة) والتقاط ملفات تعريف المعالج/التخصيص/الإدخال/الإخراج لتحديد نقاط الاتصال الفعلية): - حذف نمط الاستعلام/الجلب في N+1 - إعادة استخدام المخزن الصفري / إعادة الاستخدام / التشتت وجمع الإدخال/الإخراج - تكاليف تنسيق التسلسل (عبء التحليل/الترميز) - قوائم انتظار محدودة + ضغط عكسي (لمنع انفجار الذاكرة وكمون الذيل) - الأقفال المخططة / الأجزاء لتقليل الخلاف - الحفظ باستخدام استراتيجيات إبطال ذاكرة التخزين المؤقت - تقنيات البرمجة الديناميكية - نظرية التحسين المحدب - التقييم الكسول / الحوسبة المؤجلة - أنماط المكرر/المولد لتجنب ظهور مجموعات كبيرة - المعالجة المتدفقة/المجزأة للأعمال المقيدة بالذاكرة - جداول الحساب المسبق والبحث - البحث القائم على الفهرس مقابل التعرف على المسح الخطي - البحث الثنائي (على البيانات وعلى مساحة الإجابات) - تقنيات النوافذ ذات النقطتين والنوافذ المنزلقة - المجاميع البادئة / المجمعات التراكمية - الفرز الطوبولوجي ووعي DAG للرسوم البيانية للتبعية - كشف الدورة - إيجاد الاتحاد للاتصال الديناميكي - عبور الرسم البياني (BFS/DFS) مع إنهاء مبكر - ديكسترا / A* للمسارات الأقصر الوزن - قوائم الأولوية / الكومات - محاولات لعمليات البادئة - مرشحات بلوم للعضوية الاحتمالية - أشجار الفترات/المقاطع لاستعلامات المدى - الفهرسة المكانية (أشجار k-d، أشجار رباعية، أشجار R) - هياكل بيانات دائمة/غير قابلة للتغيير - دلالة النسخ عند الكتابة - تجميع الكائنات/الاتصال - اختيار سياسة إخلاء الكاش (LRU/LFU/ARC) - اختيار خوارزمية واعية للدفعات - تجميع ودمج الإدخال/الإخراج غير المتزامن - هياكل خالية من القفل للسيناريوهات عالية التنافس - سرقة العمل للتوازي التكراري - تحسين تخطيط الذاكرة (SoA مقابل AoS، موقع ذاكرة مؤقتة) - قصر كهربائي وإنهاء مبكر - الإدخال النصي للقيم المتكررة - الاستدلال التحليلي الاستهلاكي مع مراعاة هذه الأدلة العامة حيثما ينطبق: فحوصات تطبيق DP: - مشاكل فرعية متداخلة؟ → الذاكرة باستخدام مفتاح الحالة المستقرة - تقسيم أو تجميع مثالي؟ → المجموع البادئة + المسافة DP - رسم بياني الاعتماد مع تكرار التنقل؟ → DP طوبولوجي أحادي التمرير فحوصات التحسين المحدب: - التخصيص أو الجدولة بدقة بالقوة؟ → تدفق LP / التكلفة الدنيا مع كسر تعادل حتمي - ملاءمة المعاملات المستمرة مع خسارة صريحة؟ → المربعات الصغرى المنظمة / QP - هدف محدب كبير قابل للتحلل؟ → الطرق القريبة من ADMM لاحظ أيضا أنه إذا كانت هناك مكتبات طرف ثالث مكتوبة بشكل جيد تعرفها وتعمل بشكل جيد، يمكننا تضمينها في المشروع). متطلبات المنهجية: أ) الأساس أولا: تشغيل مجموعة الاختبار وعبء عمل ممثل؛ سجل زمن الاستجابة وسرعة النقل وذروة الذاكرة في P50/P95/P99 باستخدام أوامر دقيقة. ب) الملف الشخصي قبل الاقتراح: التقاط وحدة المعالجة المركزية + تخصيص + ملفات تعريف الإدخال/الإخراج؛ حدد أفضل 3-5 نقاط ساخنة حسب الوقت المئوية قبل اقتراح التغييرات. ج) أوراكل التكافؤ: تعريف المخرجات الذهبية الصريحة + الثواب. لمساحات الإدخال الكبيرة، أضف اختبارات قائمة على الخصائص أو الاختبارات المتحولة. د) إثبات التشاكل لكل تغيير: يجب أن يتضمن كل تفاضل مقترح مخططا قصيرا يشرح لماذا لا يمكن للمخرجات أن تتغير (بما في ذلك الترتيب، وكسر التعادل، وسلوك الفاصلة العائمة، وبذور الحظ). ه) مصفوفة الفرص: ترتيب المرشحين حسب (التأثير ×الثقة) / الجهد قبل التنفيذ؛ ركز فقط على العناصر التي من المحتمل أن تنقل p95+ أو معدل النقل بشكل ذي معنى. و) الفروقات المختلفة: رافعة أداء واحدة لكل تغيير. لا توجد إعادة تثبيط غير مرتبطة. أدرج إرشادات التراجع إذا كان هناك أي خطر. ج) حواجز الانحدار: أضف عتبات مرجعية أو خطافات مراقبة لمنع الانحدارات المستقبلية. استخدم Ultrathink. --- يمكنك تشغيلها مرة واحدة في Claude Code مع Opus 4.5 ومرة في Codex مع GPT 5.2 Codex (بدأت أستخدم High فقط لأن Extra High بطيء جدا بالنسبة لي إلا إذا كنت على وشك الذهاب للنوم). بعد الانتهاء، اضرب كل واحد منهم بحوالي 5 جولات سريعة من هذا: "رائع. راجع كل شيء مرة أخرى بحثا عن أي سهو واضح أو سهو أو أخطاء، أخطاء مفاهيمية، أخطاء فادحة، إلخ. استخدم التفكير الفائق" ثم اجعلهم يحتفظون بالمخرجات هكذا: "حسنا، احفظ كل ذلك ك PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md" "حسنا، احفظ كل ذلك ك PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md" ثم في كود كلود، قم بما يلي: "قارن ما فعلته مع PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md وخذ أفضل العناصر منه وادمجها في خطتك للحصول على خطة هجينة من أفضل العالمين من خلال تعديل ملف الخطة الأصلي." ثم هذا: أعد قراءة AGENTS dot md حتى يبقى الأمر طازجا في ذهنك. الآن اقرأ كل PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md. ثم تحقق من كل خرزة بعناية فائقة-- هل أنت متأكد أن الأمر منطقي؟ هل هو الأمثل؟ هل يمكننا تغيير أي شيء لجعل النظام يعمل بشكل أفضل للمستخدمين؟ نريد مجموعة شاملة ودقيقة من الخرزات لكل هذا مع مهام ومهام فرعية وهيكل التبعية مع تعليقات مفصلة بحيث يكون كل شيء مكتفيا بذاته وموثقا ذاتيا (بما في ذلك الخلفية ذات الصلة، والمنطق/التبرير، والاعتبارات، وما إلى ذلك - أي شيء نرغب أن تعرفه "ذاتنا المستقبلية" عن الأهداف والنوايا وطريقة التفكير وكيف يخدم الأهداف العامة للمشروع). يجب أن تكون الخرزات مفصلة جدا بحيث لا نحتاج أبدا إلى العودة إلى وثيقة خطة التخفيض الأصلية. هل يعكس بدقة كل ملف خطة التخفيض بشكل شامل؟ إذا كانت التغييرات مبررة، قم بتعديل الخرزات أو إنشاء خرزات جديدة أو إغلاق القطع غير الصالحة أو غير القابلة للتطبيق. من الأسهل والأسرع بكثير العمل في "مساحة الخطة" قبل أن نبدأ في تنفيذ هذه الأمور! لا تبسط الأمور أكثر من اللازم! لا تفقد أي ميزات أو وظائف! أيضا، تأكد من أنه كجزء من هذه البندات، ندرج اختبارات وحدات شاملة وسكريبتات اختبار e2e مع تسجيل مفصل ورائع حتى نتأكد من أن كل شيء يعمل بشكل مثالي بعد التنفيذ. تذكر أن تستخدم أداة 'bd' فقط لإنشاء وتعديل الخرزات وإضافة التبعيات إلى الخرز." ثم عدة جولات من: "افحص كل خرزة بعناية فائقة-- هل أنت متأكد أن الأمر منطقي؟ هل هو الأمثل؟ هل يمكننا تغيير أي شيء لجعل النظام يعمل بشكل أفضل للمستخدمين؟ إذا كان الأمر كذلك، راجع الخرز. من الأسهل والأسرع بكثير العمل في "مساحة الخطة" قبل أن نبدأ في تنفيذ هذه الأمور! لا تبسط الأمور أكثر من اللازم! لا تفقد أي ميزات أو وظائف! تأكد أيضا من تضمين اختبارات الوحدات الشاملة ونصوص اختبار e2e مع تسجيل مفصل ورائع حتى نتأكد من أن كل شيء يعمل بشكل مثالي بعد التنفيذ. استخدم التفكير الفائق." ثم أطلق السرب لتنفيذ كل ذلك. إذا استعدوا للجولة الثانية.