// سطح: helix-primary · سفارش 19

HelixConstitution shippedاجازه‌نامه: 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)

منبع

HelixConstitution — inheritance & propagation Inheritance (extend, never weaken) Fleet propagation · gate-checked distributed as submodule Universal base Constitution Git submodule · §11.4.x covenants Project layer own Constitution / CLAUDE / AGENTS Subdirectory overrides optional · most local Constitution repo one source of truth HelixTrack HelixCode HelixQA …140+ repos
// معماری

قانون اساسی مهندسی جهانی که هر پروژه‌ای به ارث می‌برد — قانون ضد بلوف، به‌صورت مکانیکی اجرا شده، به‌عنوان یک زیرماژول گیت به اشتراک گذاشته می‌شود.

HelixConstitution مجموعه قوانین واحد و مستقل از پروژه است — که به‌عنوان زیرماژول گیت توسط هر پروژه Helix/vasic-digital اضافه می‌شود — و نظم مهندسی غیرقابل مذاکره (ضد بلوف، تأیید مبتنی بر شواهد، ایمنی داده‌ها و میزبان، مستندسازی و پوشش تست) را کدگذاری کرده و آن را به مجموعه‌ای از بیش از ۱۴۰ مخزن منتقل می‌کند. این قانون، ستون فقرات حاکمیتی است که انسجام کل خانواده را تضمین می‌کند.

یک Constitution جهانی و قابل ارث‌بری که به‌عنوان زیرماژول گیت ارائه می‌شود. این قانون، قواعد اجباری و غیرقابل مذاکره‌ای را تعریف می‌کند — دروازه‌های شواهد ضد بلوف، مصونیت در برابر مثبت‌های کاذب، ایمنی داده‌ها و میزبان، نظم پوشش تست و مستندسازی — که هر پروژه مصرف‌کننده به‌طور خودکار به ارث می‌برد و می‌تواند آن‌ها را گسترش دهد، اما هرگز تضعیف نمی‌کند.

HelixConstitution منبع واحد و معتبر برای شیوه‌های مهندسی مشترک در هر پروژه‌ای است که با افزودن آن به‌عنوان زیرماژول گیت، به آن ملحق می‌شود — قانونی مهندسی که دقیقاً مانند کد، توزیع و نسخه‌بندی شده است. قلب این قانون، سند Constitution.md است — یک سند نسخه‌بندی‌شده و پیوسته با حجم تقریبی ۱ مگابایت که شامل بندهای شماره‌گذاری‌شده (خانواده پیمان‌های §۱۱.۴.x، در حال حاضر تا §۱۱.۴.۱۷۰) به همراه راهنماهای عملیاتی برای هر عامل (CLAUDE.md، AGENTS.md، QWEN.md، GEMINI.md) است که با ارجاع به آن، انسان‌ها و هر عامل CLI از یک قانون‌نامه واحد پیروی می‌کنند. ارث‌بری به‌صورت عمدی سه‌لایه است: لایه جهانی (این زیرماژول)، لایه پروژه (Constitution/CLAUDE/AGENTS خود پروژه که آن را گسترش می‌دهد) و لایه اختیاری برای هر زیرشاخه — که از بالا به پایین ارزیابی می‌شود و در آن، پروژه می‌تواند قوانین را *سخت‌گیرانه‌تر* کند، اما از نظر معماری مجاز به *تضعیف* آن‌ها نیست. نتیجه، مجموعه‌ای از بیش از ۱۴۰ مخزن است که نمی‌توانند به‌صورت خاموش از هم فاصله بگیرند، زیرا نظم مشترکی که به اشتراک می‌گذارند، نسخه‌بندی شده است، نه صرفاً به خاطر سپرده شده.

این سند به‌طور بی‌چون‌وچرا مستقل از حوزه است: هر چیزی که نام یک فروشنده خاص، شماره قطعه سخت‌افزاری، پورت یا نسخه کتابخانه را ذکر کند، باید به سند Constitution خود پروژه منتقل شود، و جهان‌شمولی هرگز فرض نمی‌شود — بلکه باید با گذراندن یک آزمون چهاربخشی صریح، *کسب* شود تا یک قانون اجازه ورود به لایه پایه را پیدا کند. ستون فقرات فلسفی آن، ضد بلوف است که به‌صورت مجموعه‌ای از پیمان‌های درهم‌تنیده بیان می‌شود — §۱.۱ مصونیت در برابر مثبت‌های کاذب، §۱۱.۴ پیمان کیفیت کاربر نهایی، §۱۱.۴.۶ ممنوعیت حدس‌وگمان، §۱۱.۴.۶۹ طبقه‌بندی شواهد مثبت — که اثر ترکیبی آن‌ها یک خط قرمز واحد است: معیار عرضه هرگز «تست‌ها پاس می‌شوند» نیست، بلکه «یک کاربر واقعی می‌تواند از قابلیت استفاده کند» است، و هر نتیجه سبز باید به شواهد فیزیکی ثبت‌شده استناد کند، وگرنه به حساب نمی‌آید. یک سند همراه به نام submodules-catalogue.md (شامل ۱۴۲ مخزن) پرسش «آیا قبلاً چیزی داریم که این کار را انجام دهد؟» را به یک واکنش غریزی «اول فهرست را بررسی کن، بعد گسترش بده، نه اینکه دوباره پیاده‌سازی کنی» تبدیل می‌کند، پیش از آنکه حتی یک خط کد جدید نوشته شود. اسکریپت‌های کمکی، زیرماژول را از هر عمق تو در تویی پیدا کرده و هر کامیت را به چهار ارائه‌دهنده گیت مستقل ارسال می‌کنند، به‌گونه‌ای که قانون‌نامه معتبر واحد، غیرقابل گم شدن نیز باشد.

محتوا

چندین برنامهٔ محصولی بزرگ و ده‌ها زیرماژولِ قابل استفادهٔ جدا از هم که همگی توسط یک مالک واحد نوشته شده بودند، بارها و بارها همان قواعدِ سخت‌آموخته‌شده را بازتولید می‌کردند — و همواره با یک دسته از شکست‌ها مواجه می‌شدند: تست‌ها و گزارش‌های وضعیتی که ادعای موفقیت می‌کردند در حالی که قابلیت برای کاربر نهایی شکسته بود («بلوف‌های پاس» و «بلوف‌های فیل»). هر لنگرِ پزشکی قانونی در Constitution یک رویداد واقعی را ثبت می‌کند (مثلاً بلوف پاس مسیریابی صوتی D3 در ۲۰۲۶-۰۵-۲۰ که اعتبارسنجی با فیلد خالی «کدک در حال استفاده» سبز شد، یا رابط کاربری دکمهٔ غول‌پیکر در ۲۰۲۶-۰۶-۲۵ که تست‌های برابری توکن را پاس کرد در حالی که صفحهٔ واقعی شکسته بود). Constitution برای این ساخته شده که کل این دسته از موفقیت‌های دروغین را یک بار برای همیشه و به‌طور جهانی از نظر مکانیکی غیرممکن کند — تا این نظم دیگر میان پروژه‌ها جابه‌جا نشود یا به‌آرامی فراموش نگردد.

این سامانه فرهنگ مهندسی را از «مستنداتی که امیدوارند رعایت شوند» به «قانون موروثی، نسخه‌بندی‌شده و به‌طور مکانیکی اجرا‌شده» تبدیل می‌کند — تفاوت میان یک راهنمای سبک و یک کامپایلر. ارتقای یک زیرماژول، قواعد را برای کل ناوگان به‌طور همزمان، اتمی و قابل ردیابی به‌روزرسانی می‌کند. یک پیمان ضدبلوف *به‌طور قطعی* در هر مخزن مصرف‌کننده حضور دارد، نه به‌خاطر اعتماد، بلکه به‌خاطر ساختار: یک دروازهٔ انتشار به‌صورت تحت‌اللفظی شمارهٔ بند را در کل ناوگان جست‌وجو می‌کند، و یک تست جهش‌یافته اثبات می‌کند که خود دروازه بلوف نمی‌زند — بنابراین حتی اجرای قوانین نیز اجرا می‌شود. حاکمیت دیگر آرزویی روی ویکی‌ای که هیچ‌کس نمی‌خواند نیست، بلکه واقعیت قابل ممیزی و تستی است که می‌توان یک وظیفهٔ CI را به آن نشانه گرفت.

  • Constitution به‌عنوان زیرماژول — قانون مهندسی دقیقاً مانند کد توزیع و نسخه‌بندی می‌شود، با تگ‌های عمدی به سبک v1.0.0 و پین‌کردن هر پروژه، تا هر مخزن دقیقاً بداند به کدام نسخهٔ قانون مقید است.
  • ضدبلوف به‌عنوان دکترین پزشکی قانونی درجه‌یک — هر بند به یک دستورالعمل تحت‌اللفظی اپراتور و اغلب به رویداد واقعی‌ای که آن را برانگیخته بازمی‌گردد، بنابراین کتاب قوانین به جای نظرات شخصی، همچون رویهٔ قضایی خوانده می‌شود.
  • متاتستینگ خود قوانین (§۱.۱) — هر دروازه با یک جهش همراه است که باید پاس به فیل تغییر کند، بنابراین «دروازه تقلبی نیست» نه ادعا، بلکه در هر اجرا اثبات می‌شود؛ دروازهٔ‌ای که هرگز شکست نخورد بدتر از نبود دروازه تلقی می‌شود.
  • جهانی‌بودن کسب‌شده — یک آزمون چهاربخشی صریح تصمیم می‌گیرد که آیا یک قانون واقعاً جهانی است یا صرفاً مختص پروژه، تا پایهٔ اصلی کم‌حجم، قابل حمل و عاری از نشت فروشنده باقی بماند.

HelixConstitution به‌عنوان ستون حاکمیتی اجباری، سندی نیست که خانواده به آن مراجعه کند — بلکه ساختار باربر خانواده‌ای است که بر آن بنا شده:

  • ستون فقرات حاکمیتی: هر پروژه از Helix/vasic-digital آن را به‌عنوان زیرماژول اضافه می‌کند و از CLAUDE.md / AGENTS.md / QWEN.md یا Constitution.md خود وارد می‌کند؛ قواعد بدون قید و شرط، از اولین کامیت، و بدون امکان چشم‌پوشی در هر پروژه اعمال می‌شوند.
  • دروازه‌ها و الزامات: این سامانه مدل پوشش چهارلایه را تعریف می‌کند — حضور در سورس، بقا پس از بیلد، رفتار در زمان اجرا، و عدم بلوف دروازه — که یک قابلیت باید در هر چهار سطح پاس کند تا به‌عنوان تکمیل‌شده محسوب شود، به‌علاوه فهرست روبه‌رشد الزامات نام‌گذاری‌شده: مدیریت اعتبارنامه‌ها (§۱۱.۴.۱۰)، همگام‌سازی همیشگی مستندات (§۱۱.۴.۶۰)، الزام زیرماژول کانتینرها (§۱۱.۴.۷۶)، CodeGraph (§۱۱.۴.۷۸)، پوشش اجباری نوع تست (§۱۱.۴.۱۶۹) و موارد دیگر.
  • انتشار: دروازه‌های 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 با پیمایش دایرکتوری‌های والد و دنبال‌کردن اشاره‌گر سوپرپروژه گیت به‌صورت بازگشتی، با درنظرگرفتن جایگزین CONSTITUTION_DIR و دو ساختار پشتیبانی‌شده (constitution/، submodules/constitution/)، فرآیند تشخیص را فارغ از عمق تودرتو قطعی می‌کند.
  • حفظ مرجعیت یک مخزن در چهار ارائه‌دهندهٔ گیت — آینه‌هایی که از همگام‌بودن خارج شوند بی‌ارزشند → install_upstreams.sh با خواندن ریموت‌های اعلانی Upstreams/*.sh و پیکربندی origin با چندین نشانی ارسال، یک git push واحد را به‌صورت اتمی به GitHub (اصلی)، GitLab، GitFlic و GitVerse ارسال می‌کند تا هیچ آینه‌ای عقب نماند.
  • جلوگیری از تورم قوانین / نشت پروژه به پایهٔ جهانی — هر «اضافه‌کردن همین‌جا» وسوسه‌انگیز، قابلیت حمل را تضعیف می‌کند → آزمون چهاربخشی جهانی‌شدنِ کسب‌شده به‌علاوهٔ طبقه‌بندی جهانی در برابر پروژه‌ای طبق §۱۱٫۴٫۱۷ بر *هر* قانون جدید اعمال می‌شود و دغدغه‌های خاص پروژه را به لایهٔ پروژه‌ای که به آن تعلق دارند بازمی‌گرداند.
  • اثبات کارکرد واقعی دروازهٔ وراثت — دروازه‌ای که هرگز شکست نمی‌خورد، دروازه‌ای است که نمی‌توان به آن اعتماد کرد → meta_test_inheritance.sh به‌عنوان یک فرatest نگهبان، عمداً لنگر §۱۱٫۴ را حذف و ادعا می‌کند که دروازه آن را شناسایی می‌کند؛ بدین‌ترتیب مکانیزم اجرایی خود به‌طور مداوم در برابر شکست‌های خاموش بازبینی می‌شود.

  • وراثت زیرماژول گیت — *چرایی:* زیرماژول‌های گیت تنها مکانیزمی هستند که به یک کتاب قانون اجازه می‌دهند هم مرجع باشد و هم برای هر مصرف‌کننده نسخه‌پین شود، به‌طوری که ارتقا با یک تغییر صریح و قابل بازبینی انجام شود نه با کپی-پیست خاموش؛ *چگونگی:* پروژه‌های مصرف‌کننده زیرماژول را اضافه و فایل‌های عامل آن را با @import فراخوانی می‌کنند و سه لایه از بالا به پایین با قرارداد «توسعه نه تضعیف» در هر مرز ارزیابی می‌شوند.
  • find_constitution.sh — *چرایی:* قوانین اگر کدهای عمیقاً تودرتو نتوانند به‌طور قابل اعتماد آن‌ها را بیابند بی‌فایده‌اند و کدگذاری مسیرها با اولین تغییر ساختار پروژه می‌شکند؛ *چگونگی:* پیمایش دایرکتوری والد به‌علاوهٔ بازگشتی git rev-parse --show-superproject-working-tree، با پشتیبانی جایگزین CONSTITUTION_DIR، که هر دو ساختار پشتیبانی‌شده را تشخیص می‌دهد.
  • install_upstreams.sh + Upstreams/ — *چرایی:* افزونگی چهار ارائه‌دهنده تنها زمانی واقعی است که نگهداری آن نیازمند تلاش اضافی صفر باشد، وگرنه آینه‌ها فاسد می‌شوند؛ *چگونگی:* فایل‌های اعلانی .sh برای هر ریموت به یک origin چندگانهٔ URL تبدیل می‌شوند و چهار ارسال را در یک عملیات ادغام می‌کنند.
  • فرatestهای تغییر §۱٫۱ — *چرایی:* دروازه‌ای که هرگز شکست نمی‌خورد بدتر از نداشتن دروازه است زیرا اعتماد کاذب ایجاد می‌کند؛ *چگونگی:* هر دروازه با یک تغییر حذف/تغییرنام همراه است که باید نتیجهٔ PASS را به FAIL تبدیل کند و سپس بازگردانده شود تا در هر اجرا ثابت شود که دروازه هنوز کارکرد خود را دارد.
  • دروازه‌های انتشار (CM-COVENANT-114-NNN-PROPAGATION) — *چرایی:* یک پیمان تنها زمانی جهانی است که در *همهٔ* مصرف‌کنندگان به‌طور قابل تأیید حضور داشته باشد، نه فقط در مخزن اصلی؛ *چگونگی:* جستجوی تحت‌اللفظی شمارهٔ بند در مصرف‌کنندگان، با پشتیبانی یک فرatest تغییر §۱٫۱ که ثابت می‌کند خود بررسی انتشار نیز می‌تواند شکست بخورد.
  • submodules-catalogue.md (§۱۱٫۴٫۷۴) — *چرایی:* سریع‌ترین راه برای نقض نظم ضدتکرار این است که ندانیم چه چیزی را از قبل در اختیار داریم؛ *چگونگی:* فهرستی از ۱۴۲ مخزن، گروه‌بندی‌شده بر اساس قابلیت، که پیش از ساخت هر چیز جدید، بررسی فهرست در ردیاب ثبت می‌شود.
  • صدور چندفرمت — *چرایی:* یک قانون واحد باید به یک اندازه برای انسان‌هایی که آن را می‌خوانند، ابزارهایی که آن را پردازش می‌کنند و آرشیوهایی که آن را نگهداری می‌کنند قابل استفاده باشد؛ *چگونگی:* هر سند معیار به‌صورت .md / .html / .pdf / .docx از یک منبع صادر می‌شود.

محتوا

  • وضعیت: ارسال شده. به‌طور فعال نسخه‌بندی می‌شود و به‌عنوان زیرماژول در سراسر ناوگان (مخازن عمومی اصلی و آینه‌ای) مورد استفاده قرار می‌گیرد.
  • مجوز: نامشخص — در منابع بررسی‌شده به‌صراحت ذکر نشده است؛ پیش از انتشار، با فایل LICENSE مخزن تطبیق داده شود.
  • آینه‌های بالادستی دیگر: GitLab helixdevelopment1/helixconstitution، GitFlic helixdevelopment/helixconstitution، GitVerse helixdevelopment/HelixConstitution.

سطح اولویت: Helix-اصلی — ستونی حاکمیتی اجباری در نحوهٔ ساخت همهٔ موارد خانوادهٔ Helix.