// tier: helix-primary · order 19

HelixConstitution shippedlicense: TBD

Git-submodule inheritancefind_constitution.sh (parent-walk + superproject recursion)install_upstreams.sh (multi-provider push)§1.1 mutation meta-testsPropagation gates (CM-COVENANT-114-NNN-PROPAGATION)submodules-catalogue.mdMulti-format export (md/html/pdf/docx)

Source

• HelixDevelopment/HelixConstitution
• vasic-digital/HelixConstitution

// architecture

الدستور الهندسي العالمي الذي ترثه كل مشروع — قانون مكافحة التضليل، مفروض آلياً، ومشترك كوحدة فرعية واحدة في Git.

HelixConstitution هو مجموعة القواعد الوحيدة المحايدة للمشروع — تُضاف كوحدة فرعية في Git من قبل كل مشروع Helix/vasic-digital — التي تُشفّر الانضباط الهندسي غير القابل للتفاوض (مكافحة التضليل، التحقق القائم على الأدلة فقط، سلامة البيانات والمضيف، التوثيق وتغطية الاختبارات) وتنشره على أسطول يضم أكثر من 140 مستودعاً. إنه العمود الفقري للحكم الذي يجعل العائلة بأكملها متماسكة.

Constitution عالمي وقابل للتوريث، يُوزّع كوحدة فرعية في Git. يحدد قواعد إلزامية وغير قابلة للتفاوض — بوابات أدلة مكافحة التضليل، الحصانة ضد الإيجابيات الكاذبة، سلامة البيانات والمضيف، الانضباط في التغطية والتوثيق — التي يرثها كل مشروع مستهلك تلقائياً، ويمكنه توسيعها ولكن لا يُسمح له بتخفيفها أبداً.

HelixConstitution هو المصدر المرجعي الوحيد للحقائق المتعلقة بالممارسات الهندسية المشتركة عبر كل مشروع يختار الانضمام إليه بإضافته كوحدة فرعية في Git — قانون هندسي موزّع ومُثبّت بالإصدار تماماً مثل الكود. محوره الرئيسي — Constitution.md — وثيقة مُرقّمة ومُحدّثة باستمرار بحجم ~1 ميغابايت، تحتوي على بنود مرقّمة (عائلة العهد §11.4.x، حالياً حتى §11.4.170) بالإضافة إلى أدلة تشغيلية لكل وكيل (CLAUDE.md، AGENTS.md، QWEN.md، GEMINI.md) التي تستوردها بالمرجع بحيث يقرأ البشر وكل وكيل CLI من كتاب قواعد واحد متطابق. الوراثة مصممة بثلاث طبقات متعمداً: الطبقة الأساسية العالمية (هذه الوحدة الفرعية)، طبقة المشروع (Constitution/CLAUDE/AGENTS الخاصة بالمشروع التي توسّعها)، وطبقة فرعية اختيارية لكل دليل فرعي — تُقيّم من الأعلى إلى الأسفل، حيث يمكن للمشروع *تشديد* القواعد لكنه ممنوع معمارياً من *تخفيفها*. والنتيجة هي أسطول يضم أكثر من 140 مستودعاً لا يمكن أن ينحرف بصمت عن المسار، لأن الانضباط الذي يشتركون فيه مُثبّت، وليس محفوظاً في الذاكرة.

الوثيقة لا تتنازل عن حيادها التام تجاه أي مجال محدد: أي شيء يذكر بائعاً معيناً، أو رقم جزء من المعدات، أو منفذاً، أو إصدار مكتبة يجب نقله إلى Constitution الخاص بالمشروع المستهلك، ولا يُفترض أبداً عالمية أي قاعدة — بل يجب *كسبها* من خلال اختبار صريح بأربعة أجزاء قبل السماح بإدراج القاعدة في الأساس. عمودها الفلسفي هو مكافحة التضليل، ويُعبّر عنه من خلال عائلة مترابطة من العهود — §1.1 الحصانة ضد الإيجابيات الكاذبة، §11.4 عهد جودة المستخدم النهائي، §11.4.6 عدم التخمين، §11.4.69 تصنيف الأدلة الإيجابية — التي يجمع تأثيرها على رسم خط صلب واحد: معيار الإطلاق ليس "اجتياز الاختبارات"، بل "يمكن لمستخدم حقيقي استخدام الميزة"، وكل نتيجة إيجابية يجب أن تستند إلى دليل مادي مسجّل وإلا فلا تُحسب. وثيقة مرافقة submodules-catalogue.md (142 مستودعاً) تحول سؤال "هل نمتلك بالفعل شيئاً يفعل هذا؟" إلى عادة تلقائية تبحث في الكتالوج أولاً قبل كتابة سطر جديد من الكود. تساعد السكربتات المساعدة في تحديد موقع الوحدة الفرعية من أي عمق تفرعي وتوزيع كل تعديل على أربعة مزودي Git مستقلين، بحيث يصبح كتاب القواعد الموثوق به مستحيلاً فقدانه.

المحتوى

تطبيقات منتجات ضخمة متعددة وعشرات الوحدات الفرعية القابلة لإعادة الاستخدام المنفصلة، التي كتبها نفس المالك، ظلت تعيد اشتقاق القواعد نفسها التي اكتُسبت بصعوبة — وظلت تصطدم بنفس فئة الفشل: الاختبارات وتقارير الحالة التي تزعم النجاح بينما الميزة معطلة بالنسبة للمستخدم النهائي ("خداع النجاح" و"خداع الفشل"). كل مرساة تحليلية في سجل Constitution تسجل حادثة حقيقية (مثل خداع النجاح في توجيه الصوت D3 بتاريخ 2026-05-20 حيث ظهرت نتيجة التحقق باللون الأخضر مع حقل "الترميز المستخدم" فارغًا، أو واجهة المستخدم ذات الزر العملاق بتاريخ 2026-06-25 التي اجتازت اختبارات تكافؤ الرموز بينما كانت الشاشة الحقيقية معطلة). يوجد سجل Constitution لمنع هذا النوع بأكمله من النجاح المزيف آليًا، مرة واحدة، بشكل شامل — بحيث لا يمكن للانضباط أن يتشتت بين المشاريع أو يُنسى بصمت.

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

• Constitution كوحدة فرعية — قانون هندسي موزع ومثبت بالإصدارات تمامًا مثل الكود، مع علامات إصدار مقصودة على نمط v1.0.0 وتثبيت لكل مشروع، بحيث يعرف كل مستودع *بالضبط* أي نسخة من القانون ملتزم بها.
• مبدأ مضاد للخداع كمبدأ تحقيقي من الدرجة الأولى — كل بند يعود إلى تفويض مشغل حرفي وغالبًا إلى الحادثة الحقيقية التي حفزته، لذا يقرأ كتاب القواعد كسوابق قضائية وليس كأراء.
• اختبار القواعد نفسها (§1.1) — كل بوابة مقترنة بطفرة يجب أن تحول النتيجة من نجاح إلى فشل، لذا فإن "البوابة ليست خدعة" لا تُزعم وإنما تُثبت في كل تشغيل؛ البوابة التي لا يمكن أن تفشل تُعامل أسوأ من عدم وجود بوابة على الإطلاق.
• الشمولية المكتسبة — اختبار صريح من أربعة أجزاء يحدد ما إذا كانت القاعدة شاملة بحق أم مجرد قاعدة خاصة بالمشروع، مما يحافظ على القاعدة الأساسية نحيفة وقابلة للنقل وخالية من تسرب البائعين.

كركيزة حوكمة إلزامية، فإن HelixConstitution ليست وثيقة يستشيرها الفريق — بل هي الهيكل الحامل الذي بُني عليه الفريق:

• العمود الفقري للحوكمة: يضيف كل مشروع Helix/vasic-digital هذه الوحدة الفرعية ويستوردها من CLAUDE.md / AGENTS.md / QWEN.md / ملف Constitution.md الخاص به؛ تُطبق القواعد دون استثناء، من أول التزام، دون إمكانية إلغاء الاشتراك لكل مشروع.
• البوابات والتفويضات: تحدد نموذج التغطية بأربع طبقات — وجود المصدر، البقاء بعد البناء، السلوك أثناء التشغيل، البوابة غير خداعة — التي يجب على الميزة اجتيازها على جميع المستويات الأربعة قبل اعتبارها مكتملة، بالإضافة إلى قائمة متنامية من التفويضات المسماة: معالجة بيانات الاعتماد (§11.4.10)، تزامن الوثائق دائمًا (§11.4.60)، تفويض الوحدات الفرعية للحاويات (§11.4.76)، CodeGraph (§11.4.78)، تغطية نوع الاختبار الإلزامية (§11.4.169)، وغير ذلك.
• الانتشار: بوابات CM-COVENANT-114-NNN-PROPAGATION تؤكد وجود نص البند *حرفيًا* عبر الأسطول المستهلك، بحيث لا يمكن إسقاط ميثاق بصمت في زاوية من النظام؛ عدم الامتثال هو عائق إطلاق صارم دون ثغرات للهروب.
• الاكتشاف: يحول submodules-catalogue.md سؤال "هل نمتلك بالفعل شيئًا يقوم بـ X؟" إلى إجابة بنظرة واحدة قبل إنشاء أي وحدة جديدة، مما يقضي على الجهد المكرر من المصدر.
• اتساق وكلاء AI: يُعبّر عن نفس القانون بشكل متطابق لكل وكيل CLI (Claude Code، Codex/Cursor/Aider/OpenCode/Crush/Kimi عبر AGENTS.md، Qwen Code عبر QWEN.md)، لذا مهما كان الأداة التي تلمس الكود، فإنها تلتزم بميثاق واحد لا يتغير.

المحتوى

• تحديد موقع الوحدة الفرعية من أي عمق متداخل عشوائي — لا يزال يتعين على القاعدة المدفونة على عمق ثلاث وحدات فرعية العثور على القانون دون معرفة مكان وجوده → يقوم find_constitution.sh بالصعود عبر الأدلة الرئيسية ويتبع مؤشر مشروع Git الرئيسي بشكل تكراري، مع احترام تجاوز CONSTITUTION_DIR وتخطيطين مدعومين (constitution/، submodules/constitution/)، مما يجعل عملية التحديد حتمية مهما بلغ عمق التداخل.
• الحفاظ على مرجعية مستودع واحد عبر أربعة مزودي خدمات Git — المرايا عديمة الفائدة إذا انحرفت → يقرأ install_upstreams.sh عناوين Upstreams/*.sh البعيدة التصريحية ويضبط origin بعنوان دفع متعدد، بحيث يقوم أمر git push واحد بنشر التحديثات بشكل ذري إلى GitHub (الرئيسي)، GitLab، GitFlic، وGitVerse، ولا يمكن لأي مرآة أن تتخلف عن الركب.
• منع تضخم القواعد/تسرب المشروع إلى القاعدة العالمية — كل إغراء بـ"إضافته هنا وحسب" يقوّض قابلية النقل → يُطبّق اختبار العالمية المكتسبة المكون من أربعة أجزاء بالإضافة إلى تصنيف §11.4.17 (العالمي مقابل المشروع) على *كل* قاعدة جديدة، مما يدفع المخاوف الخاصة بالمشروع إلى العودة إلى طبقة المشروع حيث تنتمي.
• إثبات فعالية بوابة الوراثة — البوابة التي لا تفشل أبداً هي بوابة لا يمكن الوثوق بها → meta_test_inheritance.sh، اختبار ميتا حارس، يحذف عمداً مرساة §11.4 ويؤكد أن البوابة تلتقط الخطأ، مما يجعل آلية التنفيذ نفسها تخضع لإعادة التحقق المستمر ضد الأعطال الصامتة.

• وراثة وحدات Git الفرعية — *السبب:* وحدات Git الفرعية هي الآلية الوحيدة التي تسمح بأن يكون كتاب القواعد موثوقاً *ومرتبطاً بإصدار محدد لكل مستهلك*، ويتم تحديثه عبر زيادة صريحة قابلة للمراجعة بدلاً من النسخ واللصق الصامت؛ *الكيفية:* تضيف المشاريع المستهلكة الوحدة الفرعية وتستورد @import ملفات الوكيل الخاصة بها، وتُقيّم الطبقات الثلاث من الأعلى إلى الأسفل مع عقد صارم يمتد ولا يضعف عند كل حد.
• find_constitution.sh — *السبب:* القواعد عديمة الفائدة إذا لم يتمكن الكود المتداخل بعمق من العثور عليها بشكل موثوق، وتشفير المسارات سيؤدي إلى كسرها بمجرد إعادة تنظيم المشروع؛ *الكيفية:* صعود عبر الأدلة الرئيسية بالإضافة إلى تكرار git rev-parse --show-superproject-working-tree، مدعوماً بتجاوز CONSTITUTION_DIR، مما يحدد كلا التخطيطين المدعومين.
• install_upstreams.sh + Upstreams/ — *السبب:* التكرار عبر أربعة مزودين حقيقي فقط إذا لم يتطلب أي جهد إضافي للحفاظ عليه، وإلا فسوف تتدهور المرايا؛ *الكيفية:* تُحوّل ملفات .sh البعيدة التصريحية لكل مزود إلى origin متعدد URL، مما يقلص أربعة أوامر دفع إلى واحد.
• اختبارات ميتا الطفرات §1.1 — *السبب:* البوابة التي لا تفشل أبداً أسوأ من عدم وجودها لأنها تولّد ثقة زائفة؛ *الكيفية:* تُزاوج كل بوابة مع طفرة حذف/إعادة تسمية يجب أن تحول النتيجة من نجاح إلى فشل ثم تُستعاد، بحيث تثبت كل بوابة أنها لا تزال فاعلة عند كل تشغيل.
• بوابات الانتشار (CM-COVENANT-114-NNN-PROPAGATION) — *السبب:* العهد عالمي فقط إذا كان موجوداً بشكل قابل للتحقق في *كل* مستهلك، وليس فقط في المستودع الرئيسي؛ *الكيفية:* بحث حرفي عن رقم البند عبر المستهلكين، مدعوماً باختبار ميتا §1.1 المقترن الذي يثبت أن فحص الانتشار نفسه يمكن أن يفشل.
• submodules-catalogue.md (§11.4.74) — *السبب:* أسرع طريقة لانتهاك مبدأ مكافحة التكرار هي عدم معرفة ما تملكه أصلاً؛ *الكيفية:* جرد يضم 142 مستودعاً مجمعة حسب القدرات، مع تسجيل فحص الكتالوج في المتتبع *قبل* إنشاء أي شيء جديد.
• التصدير متعدد الصيغ — *السبب:* يجب أن يكون القانون نفسه قابلاً للاستهلاك على قدم المساواة من قبل البشر الذين يقرؤونه، والأدوات التي تحلله، والأرشيفات التي تحفظه؛ *الكيفية:* يُصدر كل مستند أصلي بصيغ .md / .html / .pdf / .docx من مصدر واحد.

المحتوى

• الحالة: تم الشحن. يخضع للتحديث المستمر ويُستخدم كوحدة فرعية عبر الأسطول (المستودعات العامة الأصلية والمكررة).
• الرخصة: لم تُحدد بعد — لم تُذكر صراحةً في المادة المصدرية التي تمت مراجعتها؛ يُرجى التأكد من ملف الرخصة في المستودع قبل النشر.
• مرايا المنبع الإضافية: GitLab helixdevelopment1/helixconstitution، GitFlic helixdevelopment/helixconstitution، GitVerse helixdevelopment/HelixConstitution.

درجة الأولوية: Helix-أساسية — ركيزة حاكمة إلزامية لكيفية بناء كل ما يتعلق بعائلة Helix.