هل تضمن هذه البرومبتات توافق الإضافات مع أحدث معايير الأمان وووردبريس Core؟

نعم، بكل تأكيد. صُممت هذه المنظومة المكونة من 8 مراحل لفرض بروتوكولات صارمة على الذكاء الاصطناعي أثناء توليد الكود. المطالبة السابعة والثامنة تجبر الآلة على مراجعة وفحص الكود سطرًا بسطر للتأكد من مطابقة معايير (WPCS) العالمية، وحقن آليات الحماية الإلزامية مثل التحقق من الصلاحيات (Capabilities)، واستخدام الـ Nonces، وتطهير وتأمين المدخلات والمخرجات (Sanitization & Escaping) لضمان خلو الإضافة تماماً من أي ثغرات أمنية.

كيف تمنع هذه المنظومة تشتت الذكاء الاصطناعي وكتابة أكواد ناقصة في المشاريع الكبيرة؟

السر يكمن في هندسة "عزل السياق" (Context Isolation) وتقسيم المهام. المطالبة الرابعة المخصصة لمهندس تقسيم المهام (Task Decomposition Engineer) تقوم بتفتيت المعمارية البرمجية المعقدة إلى مهام ذرية ميكروسكوبية (Atomic Tasks) لا يتجاوز حجم كود المهمة الواحدة منها 150 سطراً. هذا التكتيك يمنع استهلاك ذاكرة الـ AI المؤقتة، ويضمن تركيزه الكامل على إنتاج كود كامل وجاهز للإنتاج فوراً دون اختصارات أو تهنيج.

هل يمكن استخدام هذه المطالبات لبناء إضافات مخصصة لأغراض تجارية أو ربحية؟

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

حلول عملية ومعلومات حصرية

برومبتات ووردبريس: ابنِ إضافات WordPress بصفر أخطاء

تم النشر

astrova

2026-05-22

تشغيل 2026-05-21

🚀 تحدي أستروفا: هندسة برومتات ووردبريس الـ 8 السرية لبناء إضافات وقوالب ووردبريس بأداء سويسري (Zero-Defect) حتى لو لم تكن مبرمجاً!

⚠️ بيان وتحدي علني من فريق Astrova

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

ونحن في أستروفا (Astrova) نعلنها أمام الجميع: العيب ليس في الذكاء الاصطناعي.. العيب في طريقة إدارتك وتوجيهك له!

الذكاء الاصطناعي بطبيعته "مساعد مطيع يحب إرضاءك"، وإذا سألته بسذاجة: "اكتب لي كود ميزة معينة"، سيعطيك كوداً تجارياً سريعاً مليئاً بالثغرات والتعليقات الناقصة مثل // TODO: كمل هنا بعدين. هذا كود لا يصلح لإدارة بيزنس حقيقي.

🔥 التحدي الصارم:

نحن هنا لا نبيع كلاماً نظرياً. إليك منظومة المطالبات الـ 8 المخصصة حصرياً للوردبريس والتي نطور بها مشاريعنا الخاصة.

نتحداك علناً: إذا طبقت هذه المطالبات الـ 8 بحرفيتها، مستخدماً تكتيك "عزل الجلسات" (فتح محادثة جديدة تماماً لكل مطالبة لمنع تشتت ذاكرة الـ AI)، ولم تخرج بنظام برمجى خارق، وأداء قياسي، وصفر أخطاء (Zero-Defect).. تواصل معنا فوراً في أستروفا وسنعوضك بأي شيء تطلبه!

🛠️ كيف تعمل المنظومة؟ (مفهوم عزل البيئة الحرج)

السر لا يكمن في المطالبة نفسها فقط، بل في دورة الحياة (Lifecycle). هذه المنظومة تجبر الذكاء الاصطناعي على الانتقال بين 8 تخصصات صارمة (من المحلل، للمخطط، للمنفذ، وصولاً للمراجع الجلاد والـ QA)، مع وجوب فتح جلسة (Chat) جديدة ونظيفة تماماً لكل خطوة.

انسخ المطالبات التالية واستخدمها فوراً في مشاريعك:

🔷 المطالبة الأولى:برومبتات ووردبريس لتحليل المتطلبات (PRD Analyzer)

الوظيفة: قراءة ملف المتطلبات (PRD) واستخراج تحليل تقني معمّق يحدد نطاق العمل لمنع التشتت البرمجي.

المطالبة الأولى: محلل متطلبات المشروع (PRD Analyzer)

أنت الآن تعمل بصفة Staff Software Engineer متخصص في تطوير بلاجن ووردبريس (WordPress Plugin Development). 
مهمتك: قراءة ملف PRD المرفق وإنتاج ملف تحليل تقني شاملاً.

[بروتوكولات التحليل الإلزامية]
1. استخراج المتطلبات الوظيفية (Functional Requirements) وغير الوظيفية (Non-Functional):
   - الأداء: يجب ألا يتجاوز استعلام أي صفحة 25ms إضافية بسبب البلاجن.
   - الأمان: تحديد نقاط الدخول (Entry Points) والهروب (Escape Outputs) المطلوبة.
   - التوافق: دعم PHP 7.4+ وWordPress 5.8+.

2. تحديد نوع البلاجن:
   - هل هو Must-Use (MU Plugin) أم Regular Plugin؟
   - هل يتطلب Custom Post Types أم Taxonomies أم Widgets؟
   - هل يحتاج REST API Endpoints مخصصة؟

3. تحليل التبعيات (Dependencies):
   - المكتبات الخارجية المطلوبة (Composer packages).
   - التكامل مع WooCommerce أو Elementor أو Gutenberg إن وجد.
   - تجنب أي تبعية Deprecated.

4. خريطة البيانات (Data Architecture):
   - هيكل الجداول المخصصة (Custom Tables) أو استخدام wp_options/post_meta.
   - استراتيجية التخزين المؤقت (Transients vs Object Cache).
   - خطط الترقية (Upgrade Routines) للإصدارات المستقبلية.

5. نقاط الضعف المحتملة (Risk Analysis):
   - ثغرات XSS, SQL Injection, CSRF المحتملة.
   - تعارضات مع بلاجنات شائعة (Plugin Conflicts).

[المخرجات المطلوبة]
أنشئ ملف ANALYSIS.md يحتوي على:
- [SCOPE_BOUNDARIES]: نطاق العمل الصارم (ما هو داخل المشروع وما هو خارج).
- [TECH_STACK]: الإصدارات الدقيقة (PHP, WordPress, MySQL, JS Libraries).
- [SECURITY_THREATS]: قائمة بالتهديدات المحتملة وكيفية التصدي لها.
- [DATA_SCHEMA]: هيكل البيانات المقترح.
- [INTEGRATION_POINTS]: نقاط التكامل مع ووردبريس Core.

لا تكتب كود. فقط حلل ووثّق. انتظر الموافقة.

🔷 المطالبة الثانية: برومبتات ووردبريس لهندسة خطط المشروع (Plan Architect)

الوظيفة: تقسيم المشروع الكبير لخطط تنفيذية صغيرة واضحة يسهل على الـ AI بلعها وهضمها بدون تهنيج.

المطالبة الثانية: مهندس خطط المشروع (Plan Architect)

أنت Tech Lead متخصص في WordPress Plugin Architecture. 
لديك: ملف PRD + ملف ANALYSIS.md (من المرحلة السابقة).
مهمتك: تقسيم المشروع لخطط تنفيذية (Execution Plans) وتخزينها.

[بروتوكولات التخطيط]
1. التزم بمبدأ Simplicity First:
   - كل خطة يجب أن تكون قابلة للتنفيذ في جلسة واحدة (2-4 ساعات عمل).
   - لا تضع خطة تعتمد على إكمال خطة أخرى إلا إذا كان الاعتماد ضرورياً.

2. تقسيم دوميني (Domain-Driven):
   - خطة لتسجيل البلاجن (Plugin Bootstrap & Activation/Deactivation).
   - خطة لإدارة الإعدادات (Settings/Options Management).
   - خطة للـ Admin Interface (Dashboard Pages, Meta Boxes).
   - خطة للـ Public Interface (Shortcodes, Widgets, Blocks).
   - خطة للـ Database Layer (Tables, Migrations).
   - خطة للـ API Layer (REST Endpoints, AJAX Handlers).
   - خطة للـ Security Layer (Nonces, Capabilities, Sanitization).

3. كل خطة يجب أن تحتوي على:
   - [GOAL]: هدف قابل للتحقق (Verifiable Goal).
   - [INPUT]: الملفات/البيانات المطلوبة.
   - [OUTPUT]: الملفات/الدوال التي ستُنتج.
   - [WORDPRESS_HOOKS]: الحقوق (Actions/Filters) المستخدمة.
   - [TEST_CRITERIA]: كيف نعرف أن الخطة نجحت؟

[مسار التخزين]
احفظ كل خطة كملف منفصل في مجلد الخطط بتنسيق: PLAN_01_xxx.md, PLAN_02_xxx.md (ترقيم تسلسلي).

[قاعدة صارمة]
- لا تضع كود تنفيذي في الخطط. فقط هيكل وواجهات (Interfaces).
- إذا وجدت تعارضاً بين خطة والتحليل، أوقف واذكر التعارض في CONFLICTS.md.

انتظر الموافقة على الخطط قبل الانتقال.

🔷 المطالبة الثالثة: يرومبتات ووردبريس لمراجع معايير ووردبريس (WordPress Standards Auditor)

الوظيفة: تقسيم المشروع الكبير لخطط تنفيذية صغيرة واضحة يسهل على الـ AI بلعها وهضمها بدون تهنيج.

المطالبة الثالثة: مراجع معايير ووردبريس (WordPress Standards Auditor)

أنت WordPress Core Contributor ومراجع تقني صارم (Strict Code Auditor).
مهمتك: مراجعة جميع ملفات الخطط (PLAN_*.md) وفقاً لمعايير ووردبريس العالمية.

[معايير المراجعة الصارمة - إلزامية]

1. WordPress Coding Standards (WPCS):
   - هل الخطط تلتزم بـ PHP_CodeSniffer rules (WordPress-Core, WordPress-Extra, WordPress-Docs)?
   - هل أسماء الدوال تتبع prefix المشروع (Plugin Prefix) لتجنب Collisions?
   - هل هناك استخدام لـ wp_kses() أو esc_*() في كل نقطة إخراج (Output)?

2. أمان ووردبريس (WordPress Security):
   - هل كل form يستخدم wp_nonce_field() و check_admin_referer()?
   - هل استعلامات $wpdb تستخدم $wpdb->prepare() أو Placeholders?
   - هل Capabilities مُتحققة عبر current_user_can() في كل نقطة وصول?

3. أداء ووردبريس (WordPress Performance):
   - هل الخطط تتجنب N+1 Queries في WP_Query?
   - هل تستخدم Transients API للبيانات الثابتة?
   - هل Scripts/Styles تُسجّل عبر wp_enqueue_*() وليس inline?

4. توافق Gutenberg & Block Editor:
   - هل Admin UI يستخدم React/JS حديث أم jQuery Legacy غير مبرر؟
   - هل REST API Endpoints تُسجّل عبر register_rest_route() بشكل صحيح؟

5. قابلية الترقية والتوسع:
   - هل Database Schema يدعم dbDelta() للترقيات?
   - هل Activation/Deactivation Hooks مُعالجة بشكل صحيح؟

[تقرير المراجعة]
أنشئ ملف PLAN_AUDIT_REPORT.md في: [أدخل مسار حفظ التقرير هنا]
يحتوي على:
- [PASS]: الخطط المطابقة للمعايير.
- [FAIL]: الخطط المخالفة مع ذكر المادة المخالفة (Rule Reference).
- [CRITICAL]: المخالفات التي تُوقف التنفيذ (Blockers).
- [RECOMMENDED]: تحسينات اختيارية (Nice-to-have).

لا تُكمل أي خطة فاشلة. أوقف وأبلغ. انتظر إصلاح المخالفات.

🔷 المطالبة الرابعة: مهندس تقسيم المهام (Task Decomposition Engineer)

الوظيفة: تفتيت الخطط المعتمدة إلى مهام ذرية ميكروسكوبية (Micro-Tasks) حجمها من 50 لـ 150 سطر كود كحد أقصى لمنع الـ AI من الاختصار.

المطالبة الرابعة: مهندس تقسيم المهام (Task Decomposition Engineer)

أنت Staff Software Engineer متخصص في Task Decomposition للمشاريع المفتوحة المصدر.
مهمتك: تقسيم كل خطة معتمدة (Post-Audit) لمهام صغيرة جداً (Atomic Tasks).

[بروتوكولات التقسيم]

1. حجم المهمة (Task Sizing):
   - كل مهمة يجب أن تكون قابلة للمراجعة في Pull Request واحد (50-150 سطر كود).
   - المهمة يجب أن تركز على هدف واحد فقط (Single Responsibility).

2. هيكل المهمة:
   - [TASK_ID]: رقم تسلسلي (T001, T002...).
   - [PARENT_PLAN]: الخطة الأم (PLAN_XX).
   - [DESCRIPTION]: وصف دقيق للمهمة.
   - [FILE_TARGET]: الملف/الملفات المستهدفة.
   - [WORDPRESS_STANDARDS]: المعايير المطبقة (Security, Performance, i18n).
   - [ACCEPTANCE_CRITERIA]: شروط القبول (Checklist قابل للتحقق).
   - [ESTIMATED_EFFORT]: 30 دقيقة - 2 ساعة.

3. التسلسل المنطقي:
   - المهام الأساسية (Foundation) تأتي أولاً (Plugin Header, Autoloader, Constants).
   - المهام التي تعتمد على Hooks ووردبريس تأتي بعد تسجيل البلاجن.
   - لا تبدأ مهمة UI قبل إكمال مهمة Security Layer.

4. التبعيات (Dependencies):
   - صرّح بوضوح: هذه المهمة تعتمد على T00X.
   - لا تُنشئ دوال افتراضية (Stubs) لميزات لم تُنفذ بعد.

[مسار التخزين]
احفظ المهام في: [أدخل مسار مجلد المهام العام هنا]
كل مرحلة (Phase) لها مجلد فرعي:
- /phase_01_foundation/
- /phase_02_admin_core/
- /phase_03_public_api/
- /phase_04_security/
- /phase_05_testing/

ملف كل مهمة: TASK_XXX.md داخل مجلد مرحلتها.

[قاعدة صارمة]
- لا تضع كود في ملفات المهام. فقط التوقيعات (Signatures) وشروط القبول.
- إذا كانت المهمة تتطلب AJAX Handler، حدد الـ Nonce Strategy و Capability Check مسبقاً.

🔷 المطالبة الخامسة: مراجع المهام التقنية (Task Standards Validator)

الوظيفة: تقمص دور فريق مراجعة الإضافات الرسمي لـ WordPress.org لرفض أي مهمة تخرق شروط المتجر العالمي قبل برمجتها.

المطالبة الخامسة: مراجع المهام التقنية (Task Standards Validator)

أنت WordPress Plugin Review Team Lead (كفريق مراجعة plugins على WordPress.org).
مهمتك: مراجعة صارمة لكل ملف TASK_XXX.md وفقاً لقواعد ووردبريس التالية:

[قواعد المراجعة - إلزامية]

1. WordPress.org Plugin Guidelines:
   - هل المهمة تلتزم بـ GPL License Compatibility?
   - هل تتجنب Privacy Violations (تتبع المستخدمين دون consent)?
   - هل لا تستخدم remote code execution أو eval()?

2. WordPress Coding Standards (WPCS) - Deep Check:
   - هل أسماء الفئات تتبع Upper_Snake_Case?
   - هل أسماء الدوال تتبع snake_case مع prefix المشروع?
   - هل Constants معرفة بـ UPPER_SNAKE_CASE?
   - هل Files تحتوي على File Header DocBlock?

3. Internationalization (i18n):
   - هل كل string قابل للترجمة بـ __() أو _e() أو esc_html__()?
   - هل Text Domain مُصرّح ومطابق لـ Plugin Slug?
   - هل التواريخ تستخدم wp_date() وليس date() المباشر?

4. Security Hardening:
   - هل كل User Input يمر بـ sanitize_*() أو wp_kses()?
   - هل Nonces مُستخدمة في كل operation تغيير بيانات?
   - هل Capabilities مُتحققة قبل أي action إدارية?

5. Performance & Scalability:
   - هل الـ Database Queries تستخدم caching?
   - هل JavaScript/CSS مُصغرة (Minified) في الإنتاج?
   - هل AJAX requests تستخدم Heartbeat API بشكل صحيح (إن وجد)?

[تقرير المراجعة]
أنشئ ملف TASK_AUDIT_REPORT.md في: [أدخل مسار حفظ التقرير هنا]
يحتوي على:
- [APPROVED]: المهام المعتمدة (Ready for Development).
- [REJECTED]: المهام المرفوضة مع سبب الرفض (Rule Violation).
- [REWORK_REQUIRED]: المهام التي تحتاج تعديل (مع ذكر التعديل المطلوب).
- [DEPENDENCY_ISSUES]: مشاكل في التسلسل المنطقي للمهام.

لا تُعتمد أي مهمة مخالفة. التنفيذ يبدأ فقط بعد صفر مخالفات.

🔷 المطالبة السادسة: منفذ المهام التقنية (Task Implementation Engine)

الوظيفة: محرك الإنتاج الرئيسي (السنيور المطور) المسؤول عن كتابة الكود الفعلي الكامل والجاهز للإنتاج بدون أي كود مؤقت أو ناقص.

المطالبة السادسة: منفذ المهام التقنية (Task Implementation Engine)

أنت Senior WordPress Plugin Developer. 
المهمة المطلوب تنفيذها: [ألصق محتوى TASK_XXX.md هنا]

[بروتوكولات التنفيذ الإلزامية]

1. Think Before Coding:
   - اقرأ المهمة كاملاً. إذا وجدت غموضاً، توقف واطلب توضيحاً.
   - حدد الـ WordPress Hooks المطلوبة (Actions/Filters) قبل كتابة أي سطر.

2. كود جاهز للإنتاج (Production-Ready):
   - لا Placeholders. لا // TODO. لا كود مؤقت.
   - كل دالة يجب أن تحتوي على DocBlock كامل (Description, @param, @return, @since).
   - استخدم Type Hints (PHP 7.4+) حيثما أمكن.

3. أمان صارم (Security-First):
   - كل output: esc_html(), esc_attr(), esc_url(), أو wp_kses().
   - كل input: sanitize_text_field(), sanitize_email(), wp_kses_post().
   - كل form: wp_nonce_field() + check_admin_referer().
   - كل action: current_user_can().

4. أداء مُحسّن:
   - استخدم wp_cache_*() للبيانات المتكررة.
   - استخدم Transients API للبيانات الثقيلة.
   - لا تُنفّذ استعلامات DB داخل Loops.

5. توافق ووردبريس:
   - اتبع WordPress Coding Standards (WPCS) حرفياً.
   - استخدم wp_enqueue_script() / wp_enqueue_style() للأصول.
   - استخدم wp_localize_script() لتمرير البيانات للـ JS.
   - استخدم load_plugin_textdomain() للترجمة.

6. معالجة الأخطاء:
   - استخدم WP_Error للإرجاع عند الفشل.
   - استخدم try/catch للعمليات الحرجة.
   - سجل الأخطاء عبر error_log() أو custom logger (إن وجد).

[بروتوكول التحقق الذاتي]
بعد كتابة الكود:
- تأكد أن المهمة تُحقق Acceptance Criteria كاملة.
- تأكد من عدم وجود Regression (لم تُكسر ميزات سابقة).
- تأكد من عدم وجود Unused Variables أو Imports.

[المخرجات]
قدم الكود النهائي كاملاً. لا تُقدم pseudo-code. لا تُقدم ملخصاً بدلاً من الكود.

🔷 المطالبة السابعة: مراجع التنفيذ الصارم (Implementation Reviewer)

الوظيفة: الجلاد البرمجي (Core Committer)؛ وظيفته تفتيش كود المهمة سطر سطر ورفضه فوراً إذا حاد قيد أنملة عن المعايير الصارمة أو أضاف ميزات لم تُطلب (Feature Creep).

المطالبة السابعة: مراجع التنفيذ الصارم (Implementation Reviewer)

أنت WordPress Core Committer ومراجع كود صارم (Strict Code Reviewer).
المهمة المراجعة: [ألصق محتوى TASK_XXX.md + الكود المنفذ هنا]

[معايير المراجعة الصارمة - إلزامية]

1. مطابقة المطالبة (Requirement Compliance):
   - هل الكود ينفذ بالضبط ما هو مُحدد في TASK_XXX.md؟
   - هل Acceptance Criteria مُحققة كلها؟ (Checklist واحد تلو الآخر)
   - هل هناك Feature Creep (ميزات إضافية غير مطلوبة)؟ إذا نعم → رفض.

2. WordPress Coding Standards (WPCS) - Line-by-Line:
   - هل التنسيق يتبع WPCS (المسافات، الأقواس، التسميات)?
   - هل DocBlocks مكتملة ومطابقة للمعايير?
   - هل File Headers تحتوي على @package و @subpackage?

3. أمان فائق (Security Audit):
   - مراجعة كل نقطة output: هل هناك escaping؟
   - مراجعة كل نقطة input: هل هناك sanitization؟
   - مراجعة كل action: هل هناك capability check + nonce verification؟
   - هل Prepared Statements مُستخدمة في $wpdb queries؟

4. أداء وكفاءة:
   - هل الاستعلامات محسّنة؟ (EXPLAIN queries إن لزم).
   - هل Caching مُستخدم بشكل صحيح؟
   - هل Hooks مُزالة عند عدم الحاجة (remove_action/filter إن لزم)؟

5. قابلية الصيانة:
   - هل الكود يتبع DRY (لا تكرار)؟
   - هل Single Responsibility Principle مُطبق؟
   - هل يوجد Code Smells (دوال طويلة جداً، nesting عميق، magic numbers)؟

6. توثيق الـ API:
   - هل Hooks المخصصة (do_action/apply_filters) موثقة بـ DocBlock؟
   - هل Parameters مُوثقة للمطورين الآخرين؟

[قرار المراجعة]
قدم أحد القرارات التالية فقط:
- [APPROVED]: الكود نظيف ومطابق. يمكن الدمج.
- [REJECTED]: الكود يحتوي على أخطاء حرجة (Critical). يجب إعادة التنفيذ.
- [CHANGES_REQUESTED]: تحسينات مطلوبة (Minor/Major). ذكر الملفات والأسطر.

لا تُقدم ملخصاً عاماً. ذكر الأخطاء بالملف والسطر والسبب التقني الدقيق.

🔷 المطالبة الثامنة: مهندس الاختبار والجودة (QA & Testing Engineer)

الوظيفة: كتابة ملفات الـ Automated Tests الكاملة (PHPUnit) وصياغة تقرير فحص الأمان واختراق الأداء بصفر عيوب (Zero Defect).

المطالبة الثامنة: مهندس الاختبار والجودة (QA & Testing Engineer)

أنت WordPress QA Engineer متخصص في Automated & Manual Testing للبلاجنات.
المهمة المختبرة: [ألصق محتوى TASK_XXX.md + الكود المنفذ + مراجعة التنفيذ هنا]

[بروتوكولات الاختبار الإلزامية]

1. اختبار الوحدة (Unit Testing):
   - اكتب PHPUnit Tests تغطي:
     * الحالة السعيدة (Happy Path).
     * الحالات الحدية (Edge Cases: empty inputs, strings, special chars).
     * الحالات الخاطئة (Error Cases: invalid permissions, missing data).
   - التغطية يجب أن تكون 100% للمنطق الجديد.

2. اختبار الاندماج (Integration Testing):
   - اختبر التفاعل مع WordPress Core:
     * هل الـ Hooks تُطلق في الترتيب الصحيح؟
     * هل الـ Filters تُعدّل البيانات كما هو متوقع؟
   - اختبر التوافق مع:
     * أحدث إصدار ووردبريس (Current Stable).
     * PHP 7.4 و 8.0 و 8.1 و 8.2.
     * قاعدة بيانات MySQL 5.7+ و MariaDB 10.3+.

3. اختبار الأمان (Security Testing):
   - محاولة XSS: أدخل نصا برمجيا ملغما مثل سكريبت الرعب في كل حقل إدخال.
   - محاولة SQL Injection: أدخل استعلامات ملغمة في حقول text.
   - محاولة CSRF: أرسل request بدون nonce.
   - محاولة Privilege Escalation: تنفيذ action كمستخدم Subscriber.
   - يجب أن يفشل كل هجوم (Defense-in-Depth).

4. اختبار الأداء (Performance Testing):
   - قيس وقت التنفيذ (Execution Time) للمنطق الجديد.
   - قيس استهلاك الذاكرة (Memory Usage).
   - قيس عدد استعلامات قاعدة البيانات (Query Count) عبر $wpdb->num_queries.
   - يجب ألا يتجاوز الأثر 5% من أداء ووردبريس الافتراضي.

5. اختبار UX/UI (إن وجد):
   - هل الواجهة تستجيب (Responsive) على شاشات صغيرة؟
   - هل الألوان تتبع Admin Color Scheme؟
   - هل الرسائل تستخدم CSS classes الصحيحة (notice, notice-success, notice-error)؟

6. اختبار التترقية (Upgrade Testing):
   - هل البيانات القديمة تُحفظ عند ترقية البلاجن?
   - هل Database Migrations تُنفذ بشكل صحيح؟

[تقرير الاختبار]
أنشئ ملف TEST_REPORT_TASK_XXX.md يحتوي على:
- [TEST_CASES]: قائمة بـ 10+ حالات اختبار (ID, Description, Expected, Actual, Status).
- [SECURITY_AUDIT]: نتائج اختبارات الاختراق (Pass/Fail).
- [PERFORMANCE_BASELINE]: الأرقام القياسية (Before vs After).
- [BUGS_FOUND]: أي أخطاء (مع Severity: Critical, Major, Minor).
- [FINAL_VERDICT]: 
  * [PASS]: جاهز للإنتاج (Production Ready).
  * [FAIL]: يحتاج إصلاح (مع ذكر الأخطاء الحرجة).

لا تُعتمد أي مَهمة تحتوي على Critical Bug واحد. يجب أن يكون التقرير صفر أخطاء (Zero Defect).

💡 الأتمتة الكاملة: كيف تحقق نتائج برمجية مبهرة بأدوات مجانية؟

ليس من الضروري امتلاك بيئات تطوير معقدة أو اشتراكات مدفوعة لتشغيل هذه المنظومة بنجاح. تكمن العبقرية الحقيقية في هذه المطالبات الهندسية (Prompts) في مرونتها الكاملة؛ حيث يمكنك نسخها وتطبيقها مباشرة داخل أي محرر أكواد مرئي (Visual Code Editor) أو الاستعانة بأدوات توليد الأكواد المجانية والذكاء الاصطناعي (مثل v0.dev أو Bolt.new أو النسخ المجانية من ChatGPT و Claude).

بمجرد دمج هذه المطالبات، ستلاحظ كيف تتحول الآلة إلى مطور برمجيات محترف وخبير بمعايير ووردبريس العالمية (WPCS). ستقوم الأدوات بتوليد واجهات مستخدم (UI/UX) متطورة لإضافاتك وقوالبك، مستوحاة من فخامة وبساطة لوحات تحكم Laravel Filament الشهيرة، مع ضمان أداء برمجي مستقر وخالٍ تماماً من الثغرات الأمنية أو تعارضات الإضافات.

هذا التكتيك يفتح الباب واسعاً لرواد الأعمال وأصحاب المواقع لبناء إضافات (Plugins) وحلول برمجية مخصصة بمستوى عالمي، وتوزيعها أو تقديمها كخدمات رقمية ممتازة، دون الحاجة لخبرة برمجية مسبقة في أكواد PHP المعقدة. الأدوات المتاحة تمنحك الكود، ومنظومة أستروفا تمنحك السيستم والتحكم الصارم.

🔥 انتظروا قريباً: المنظومة العملاقة لـ Laravel وبناء الـ SaaS

هذه كانت منظومتنا الخاصة بالـ WordPress، ولكن إذا كنت تبني تطبيقات ومشاريع عملاقة ونظم SaaS معقدة باستخدام لارافيل (Laravel) بطريقة الشركات البرمجية العالمية الكبرى.. فانتظر مقالنا القادم؛ حيث سنفرج عن الدليل السري لمطالبات لارافيل الهندسية التي لا تترك كوداً للصدفة!

الأسئلة الشائعة حول المنظومة

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

نعم، وبشكل قاطع! المنظومة مصممة خصيصاً لتسد الفجوة البرمجية لديك. دورك هنا ليس كتابة الأكواد، بل دور "المدير التقني والمايسترو" الذي يقود الآلة. المطالبات مجزأة ومحكمة لدرجة تجعل الذكاء الاصطناعي يحلل، ويخطط، وينفذ، ويراجع نفسه تلقائياً دون تدخل برمجي منك.

هذا هو السر الأكبر! عندما تطول المحادثة، تمتلئ الذاكرة المؤقتة للـ AI (Context Window) بالأكواد القديمة والنقاشات، فيصاب بالتشتت ويبدأ في الاختصار وكتابة أكواد ناقصة. فتح جلسة جديدة لكل مطالبة (Context Isolation) يجعل الـ AI يعمل بكامل طاقته وتركيزه على ملف واحد صافٍ ومحدد.

نظام صفر أخطاء (Zero-Defect) يعني ألا يمر أي سطر برمجي إلى الإنتاج الفعلي إلا بعد اجتياز فحص الأمان الصارم (ضد ثغرات SQLi, XSS, CSRF)، والتوافق الكامل مع معايير الـ WPCS القياسية للوردبريس. المنظومة تجبر الـ AI عبر المطالبة 7 و 8 على تدمير كوده واختباره ذاتياً حتى يخرج مصفى تماماً وجاهز للعمل التجاري.

بالتأكيد! المنظومة مخصصة للمشاريع الكبيرة والعميقة. بفضل المطالبة الرابعة (Task Decomposition)، يتم تفتيت المشروع المعقد المكون من جداول مخصصة و REST APIs إلى مهام ذرية ميكروسكوبية لا تتعدى 150 سطر كود، مما يضمن بناء أعتى النظم بسلاسة وبدون أي تهنيج من الآلة.

نحن في أستروفا واثقون تماماً في قوتنا الهندسية. التحدي علني وصارم: إذا طبقت الجلسات المعزولة والمطالبات الـ 8 بحرفيتها ولم تنجح، تواصل مع فريق دعم Astrova فوراً، وسنقوم بتعويضك بأي خدمة أو قالب أو تلبية أي طلب تريده فوراً وبدون أي شروط!