تسجّل مراجعة الإصلاحات المحلية في 2026-10-06 التغييرات الدفاعية في المصدر وحدودها. لا تغيّر نتائج الاختبارات المحلية حالة قبول الإنتاج أدناه.
جاهزية النشر
نقطة التحقق الحالية في 2026-10-19
لم يثبت القبول الإنتاجي بعد. الإصدار المعلن 0.5.12، بعد الإصدارات من 0.3.0 إلى 0.5.12 بين 2026-10-17 و2026-10-19 (سجل التغييرات). وهذا ما غيّر صورة الجاهزية، ولكل بند نطاقه:
- التثبيت بـDocker من جهاز Ubuntu 26.04 فارغ: نجح 14 فحصًا من 14 في آلة KVM محلية (4 vCPU و6144 MiB) في 2026-10-17، ومنها إعادة التشغيل (vm-docker-install-checks.json). ليس خادمًا حقيقيًا.
- وكيل TLS مع عناوين Studio: نجح 27 فحصًا من 27 في 2026-10-17، بشهادة موقّعة ذاتيًا وخادم بديل خلفه (tls-termination.json).
- على الخادم الحقيقي عبر Cloudflare، في 2026-10-17: المفاتيح السرية (live-secret-keys-2026-10-17.json)، ونشر وكيل عبر
/mcpو/v1(live-agent-access-2026-10-17.json)، على بيئة واحدة بلا بيانات تطبيق. - حدود حساب المطوّر: نجح 64 فحصًا من 64 في 2026-10-19 (developer-schema-checks-2026-10-19.json).
ما زال مفتوحًا: التثبيت بـDocker على خادم عام، وStudio على العنوان العام لخادم حقيقي، والاستعادة على خادم جديد من النسخة الخارجية، والاستعادة المنقطعة، وتثبيت كامل تحت حركة حقيقية. التفاصيل في الحالة.
نقطة التحقق في 2026-10-09
لم يثبت القبول الإنتاجي بعد. آخر نقطة تحقق منشورة جرى التحقق منها هي aad7b5403ad14140e9d9499668e863d7488ce15b: نجحت مهام CI 37688338269 الأربع، بما فيها تثبيت Docker واستلام المضيف الخالي. يحفظ سجل CI المحدد الإيداع ونتائج المهام. ينشر هذا الإيداع أدلة إصلاح Source7. لا تنفذ مهام CI المثبت التجريبي داخل الآلة الضيفة أو مسار الاستعادة المحلية الكامل ولا تثبت قبولهما.
تحديث 2026-10-17: يعمل الفرع الرئيسي على خادم حقيقي (sbarbase.sbarah.com، Ubuntu 26.04، أربع أنوية، 16 GiB)، رُقّي من 0.2.0 بالأمر lab/upgrade.py start --to؛ ونجحت عليه استعادة من نسخة محلية واستعادة من Cloudflare R2 وحدها، لبيئة واحدة بلا بيانات تطبيق (سجل المحطات). لم يثبت قبول رسمي للإنتاج. يحتفظ التاريخ أدناه بتواريخه. نجح بناء التجهيز مع تعطيل الشبكة باستخدام 1690 ملف مصدر منشور و6557 عنصرا في ذاكرة الاعتماديات. نجحت عشرة اختبارات فعلية لإصلاح Source7، بما فيها كتابة ملف تطبيق كبير وتجميع خرج التشخيص الكامل من المخرجين بالتوازي. يصلح Source7 خللا تأكد لاحقا في النسختين التاريخيتين Source5 وSource6: حد حجم ملفات العمليات الفرعية كان يمنع أيضا الملفات الكبيرة التي يكتبها dpkg وBun. صار تجميع الخرج في العملية الأم يحد السجلات وحدها. ويتحقق المثبت من أرشيف المصدر الجديد دون تثبيت الإيداع التاريخي أو عدد ملفاته. يقبل سجل Source7 والمراجعة المستقلة الإصلاح المنفذ فقط، مع إبقاء سجل Source5 للتاريخ.
لم ينفذ تشغيل الآلة الضيفة أو تثبيت منظومة Supabase الكاملة أو الاستعادة الكاملة إلى هدف جديد محليا. ما زال دمج مسار التشغيل يخضع للمراجعة، وليست هذه النقطة إصدارا إنتاجيا.
يبقى هدف النشر خدمات Supabase الأصلية على Linux عبر Docker بصورة قابلة للنقل. لا تتحول تجارب أدوات الآلة الافتراضية المحلية إلى مسارات أو بصمات ملفات خاصة بالحاسوب تلزم المنتج. يحتفظ قسم 2026-10-07 التالي بنقطة التحقق السابقة.
نقطة الدمج السابقة في 2026-10-07
لم تثبت الجاهزية للإنتاج بعد. ما زال المصدر يتغير أثناء الدمج، ولذلك لا يوجد قبول نهائي لإصدار يجمع التغييرات الحالية. تخص نتائج الاختبارات وCI السابقة المصدر والبيئة المسجلين معها فقط. تحفظ خطة الدمج متطلبات الإكمال الكاملة.
نقطة التحقق المنشورة الحالية e08ed3b2684bdf04f0288c7162747a2783177026: نجحت مهام CI 37600158231 الأربع: الفحوص العامة وتوافق Python والتثبيت عبر Docker واستلام المضيف الخالي. نجح 2102 اختبار Python 3.12، ونجحت فحوص الموقع 37600311118 للبناء والاختبارات. أصبح استلام المضيف الخالي يعمل تلقائيا عند الرفع إلى main، إضافة إلى الطلب اليدوي الصريح؛ ولم يتغير سلوك طلبات الدمج.
يربط ملخص نقطة التحقق الأصلية الحالية حزمة Docker الجديدة بـ13 تقريرا و254 فحصا ناجحا لإنشاء المشروع وميزات Supabase والنسخ والاستعادة والترقية والتراجع وإعادة التشغيل. هذه حزمة التقارير الجديدة الخاصة بهذا التشغيل، وليست أرشيف baafbad السابق أو تقرير التثبيت التاريخي. ترتبط أدلة التشغيل بإيداع الشيفرة e08ed3b2684bdf04f0288c7162747a2783177026؛ ويحفظ نشر الوثائق اللاحق هذه الهوية دون قبول تشغيل تغييرات شيفرة أحدث.
تحتوي أدلة المضيف الخالي الجديدة على ستة تقارير وبيان تشغيل، مع 58 فحصا فريدا في قوائم التحقق و21 فحصا منفصلا لتهيئة Auth الحية. لا تضيف نسخة تسليم تقرير التجربة المطابقة فحوصا جديدة. يثبت سجل التشغيل الأصلي وحارسا السكربت النهائيان أن وحدة النظام المرفقة أصبحت active وأجابت لوحة الإدارة بعد التجربة. تسجل لقطة JSON السابقة مرحلة إيقاف الوحدة المقصودة أثناء التجربة؛ ولا تصف حالة الخدمة النهائية بعد إعادتها. هذه نقطة تحقق للتثبيت على عامل Ubuntu جديد؛ ولا تثبت إعادة تشغيل الجهاز أو Kali أو الاستعادة الكاملة بعد فقدان المصدر أو استمرارية Cron الباردة والدافئة أو القبول الإنتاجي. تحتفظ فحوص الملفات الثابتة وبديل TLS بنطاقها المنفصل؛ ولم تثبت شهادة عامة.
حفظ فحص واصفات systemd المنفصل على Fedora 44 هويات خمسة واصفات عبر exec لعملية Python بالمعرف نفسه، ضمن نطاق systemd محدود الموارد وتحت ملكية معلومة. يضم الأرشيف العام ملفي الفحص والملخص. لم يشغل ضيفا أو حاوية Docker؛ ويقبل سلوك واصفات Python المحدد فقط، دون آلة Linux ضيفة أو إعادة تشغيل الجهاز أو نشر إنتاجي قابل للنقل.
دخلت إلى شجرة الدمج تغييرات مسار قاعدة البيانات وتسوية كتابات Storage والنقل الإداري ودورة الحياة ومتطلبات الاستعادة. لا تقبل فحوص المكونات على نسخ وسيطة الشجرة التي تغيرت بعدها. تتحقق نقطة CI على e08ed3b من فحوصها القياسية الحالية ومسارات التثبيت. ما زالت استمرارية الخدمات الأصلية المثبتة والاستعادة الكاملة إلى هدف جديد ومضيفون مدعومون إضافيون وفحوص المتصفح والمزودين والتجربة التشغيلية مطلوبة. تبقى صفوف قبول الميزات والإنتاج الـ105 غير مثبتة.
يبقى الهدف تشغيل خدمات Supabase الأصلية على Linux عبر Docker بصورة قابلة للنقل. يشترط مسار قبول المصدر الحالي Docker Engine محليا بصلاحيات rootful، بالإصدار 25 أو أحدث، وCompose بالإصدار 2.20 أو أحدث، ومعمارية x86_64 والقدرات المطلوبة. يرفض الملف الحالي Desktop وARM وrootless وخيار SELinux إذا أعلنه Docker؛ يوضح عقد قبول المضيف التفاصيل. يوفر الحاسوب المحلي مضيفا معزولا دون تبعية خاصة بهذا الجهاز. مسار تثبيت آلة Linux افتراضية مستقلة وإعادة تشغيلها على الحاسوب مخطط له؛ ولم تثبت سلطة إنشائها أو قبول تشغيلها الأصلي. دعم Windows Docker Desktop ما زال فجوة، والآلة الافتراضية الكاملة بنظام Linux على Windows مسار محتمل غير مختبر. لا يشترط خادم خارجي لمواصلة العمل المحلي.
نجح CI المنشور 37411721539 على الإيداع التاريخي 2c4ec82007a47436ba3e338ac03d1ad5e288df45. نجحت فحوص الشيفرة وتوافق Python والتثبيت عبر Docker؛ وتُخطيت مهمة استلام المضيف الخالي. لا تقبل النتيجة المصدر المدمج الحالي أو مضيفا جديدا.
يحفظ ملخص رصد الدمج التاريخي الأعداد الدقيقة وهويات المصدر العام وتسلسل مراجعة البيانات الوصفية. يحتفظ بنتيجة التشغيل الأصلية الفاشلة، ويفصل غياب الموارد الفعلي عن رفض قبول إغلاق المالك والحارس. هو سجل رصد، وليس قبولا للشجرة الحالية.
الأدلة التاريخية السابقة للدمج الحالي
تحتفظ النتائج التالية بتواريخها وهويات مصدرها وحدودها الأصلية، ولا تثبت قبول الشجرة الحالية.
نقطة تحقق منشورة تاريخية baafbad: نجح CI 37592809221 في الفحوص العامة وتوافق Python والتثبيت عبر Docker، ونجحت فحوص الموقع 37595879418 للبناء والاختبارات. نجح 2086 اختبار Python 3.12. تحفظ أدلة الخدمات الحديثة 13 تقريرا و254 فحصا ناجحا لإنشاء المشروع وميزات Supabase والنسخ والاستعادة والترقية والتراجع وإعادة التشغيل. استُبعد تقرير تثبيت تاريخي من العدد الحالي؛ والاستعادة الكاملة إلى خادم جديد وCron والقبول الإنتاجي ما زالت غير مثبتة.
بدأ التشغيل اليدوي 37596046599 على الإيداع نفسه؛ وفشلت مهمة استلام المضيف الخالي عند تمرير عنوان Docker دون مسار المقبس المطابق. اجتاز التصحيح المركز 32 اختبارا ومراجعة مستقلة؛ ونجحت إعادة التشغيل الفعلية اللاحقة على e08ed3b؛ ويبقى الإخفاق الأصلي محفوظا. تحفظ مراجعة الدمج تسلسل الإصلاحات والإخفاقات السابقة وحدود كل نتيجة.
محاولة قياسية كاملة فاشلة تاريخية: نجح فحص إصلاح Namespace المركز في 61 حالة. ثم نفذت محاولة الفحص القياسي الكامل 1623 اختبار Python مع 9 حالات فشل و21 خطأ، وانتهت بالرمز 1. نجحت مراحلها الست الأخرى، ومنها 430 اختبار Bun والحالات المستهدفة المطلوبة الـ41. تظل المحاولة الكاملة فاشلة. طُبقت بعدها عشرة إصلاحات في مصدر تجهيز الاختبارات وتشغيلها؛ وكان يلزم التحقق منها مجددا عند تلك النقطة؛ وتسجل الفقرات أعلاه نتائج CI اللاحقة.
نقطة تحقق تاريخية للإصلاحات في 2026-10-06: تغلق الإصلاحات التي روجعت اتصالات SQLite في recovery_bundle بعد انتهاء معاملاتها الأصلية، وتغلق استجابات HTTPError في notify. وتلتقط 27 دالة اختبار خرج stderr المتوقع كاملا وتتحقق منه، مع تسجيل مسؤولية إغلاق tempfile وحذفه قبل الكتابة التي قد تفشل. يربط اختبار أحدث لإنشاء المورد تحذيره بدورة حياة استجابة HTTPError؛ ولا يثبت ذلك أسباب التخصيص في حزم التحذيرات السابقة.
نتيجة الاختبارات التاريخية: نجح 1504 اختبارا دون فشل أو أخطاء أو تحذيرات أو اختبارات متجاوزة، مع مراجعة مستقلة بعد رمز الخروج صفر. طابقت ملفات المصدر العامة الـ881 المصدر المقبول، وكذلك التقاطا الملفات الـ294 وفحصا صلاحيات الملفات الـ881، وأزيلت الحاويات الثماني دون موارد غير محسومة. تشمل النتيجة 55 اختبارا لمكوّني إكمال طلبات SQL الخاصة الجديدين، واختبارات التجهيز الـ52. التفاصيل في ملخص الاختبارات التاريخي. تحتفظ نتيجة الاختبارات السابقة الـ1449 بنطاقها الأصلي. نجح CI على 6c86b10 لخط الأساس السابق، ولا يشمل الملفات الأربعة الجديدة. لا تثبت اختبارات المكوّنات والتجهيز توافق العميل الخاص المثبت أو تشغيل PostgreSQL أو استمرارية Cron وVault أو الاستعادة الكاملة.
نجحت مهام CI 37388098529 الأربع على إيداع الشيفرة 066f5ec، بما فيها Python 3.12 وتجربة Docker واستلام خدمة systemd على مضيف نظيف. ونجح فحص الموقع 37388119460 للبناء والاختبارات فقط. التفاصيل في ملخص قبول CI؛ وتبقى أدلة التشغيل مرتبطة بإيداع الشيفرة المحدد.
تملك المنصة العادية legacy-shared أدلة تاريخية لاختبارات Docker تشمل التثبيت والمشروع الأول وAuth وREST وStorage وStudio وRealtime وFunctions والنسخ الاحتياطية والترقيات. نجح CI الجديد واستلام الخادم الخالي على إيداع الشيفرة 066f5ec. هذا الحاسوب هو خادم Linux Docker المحلي المعزول الذي اختاره المستخدم؛ ويوفر CI مسارا إضافيا على مضيف جديد. إعداد DNS العام وشهادة TLS العامة من إعدادات المشغل المستقبلية.
ما زال مسار native-dedicated التجريبي غير مكتمل: لم يحصل مرشح PostgreSQL 17.11 على قبول التشغيل أو الإعدادات الفعلية التي تحفظ الخصوصية أو الطلبات الخاصة الفعلية أو استمرارية Cron وVault بعد التشغيل البارد وإعادة التشغيل أو الاستعادة الفيزيائية. لا يجوز تبني وحدات تخزين المرشح المعزولة المحتفظ بها أو قراءتها أو حذفها. وعند نقطة التحقق تلك كانت 0.2.0 نسخة تطوير، ولم تثبت الجاهزية للإنتاج ولا إصدار موقّع.
تجمع الحالة روابط الأدلة الحالية وحدودها. تحتفظ المصفوفة أدناه بتواريخها وحدودها الأصلية؛ ولا يعني هذا التعديل إعادة تنفيذ فحوصها.
مصفوفة الجاهزية التاريخية
| المتطلب | الحالة | الدليل أو الفجوة |
|---|---|---|
| مشغّل التثبيت يشغّل البيئة التي يثبّتها | أُصلح ويغطيه اختبار يمنع عودته | كشف تشغيل أمر الاستلام الموثّق على هذا الخادم عيبًا فات المراجعات: كانت install() تمسك قفل العملية وهي تطلق lab/installation_runtime.py up، وهذا يأخذ القفل نفسه طوال عمره، فكان المثبّت يرفض بيئته هو على كل خادم. صار القفل يُحرَّر بعد خطوة بناء لوحة الإدارة، وبيئة التشغيل نفسها ترتّب بدءها (lab/test_install_lock.py، 5 اختبارات: القفل حر عند بدء التشغيل، والبدء المرفوض يوقف التثبيت، والخطوة الفاشلة تحرّر القفل رغم فشلها، ومثبّت ثانٍ يُرفض) |
| اختبار استلام الخادم بأمر واحد مع الأدلة | منفّذ، والرفض مختبر | deploy/server-acceptance.sh: المتطلبات، والفحص المسبق، والتجربة الكاملة، ونسخة الأدلة للتسليم. تغطي 18 اختبارًا في lab/test_server_acceptance.py غياب متطلب، وملف تهيئة أولية مقروءًا للجميع، والوسائط المجهولة، وعدم تسرّب الأسرار، وتوقف التشغيل عند فشل خطوة، ووصول --bun-dir إلى فحص المتطلبات، وتحرير الوحدة قبل التجربة وإعادتها عند أي خروج، وسلوك فحص حالة الوحدة مع وحدة متوقفة، وهل يحق لكل رسالة فشل أن تعد بملف أدلة |
الفحص المسبق للخادم (Docker أصلي، Bun، /usr/bin/python3 3.12 أو أحدث مع cryptography، صور مثبّتة الإصدار، هامش الذاكرة، القرص، الحالة) |
منفّذ، وثبت عمله | lab/install_server.py check. ما يبلّغ عنه على خادم مشترك يتبع لحظة التشغيل: قيس هنا مرة بالنتيجة Host headroom insufficient: 8187 MiB available, plan needs 8789 MiB (5888 MiB placement + 2560 MiB reserve + 341 MiB measured for the running source stage)، ومرة أخرى بالنتيجة 0 blocker(s), 2 action(s) مع الخطة نفسها. تُفصَّل مكونات الخطة في رسالة المانع، ومنها الكلفة المقيسة لمرحلة المصدر العاملة، فيرفض التشغيل المشترك قبل إنشاء أي حاوية بدل أن يموت في منتصف الطريق. يبلّغ الفحص أيضًا عن التثبيت المحفوظ (11 حاوية للمصدر و8 للهدف)، وعن تثبيت الجيل لهدف الاستعادة الحالي، وعن هدف قديم بلا تثبيت جيل لا تشغّله بيئة التشغيل. المكونات تتغير مع حال الخادم: ملف البصمة المحفوظ في المستودع يسجّل 279 MiB استهلاكًا فعليًا عبر 9 حاويات للمصدر أخذ عيّنتها (docs/evidence/source-stage-footprint.json، أُخذت العيّنة قبيل القبول المشترك في ذلك التشغيل)، مقابل 341 MiB في اللحظة الأسبق المذكورة أعلاه. وحين تعمل حزمة محطة العمل نفسها، يبلّغ الفحص نفسه عن مانعه الصادق: Owned containers are already running; stop or supervise them instead of installing |
| توليد وحدة المشرف والتحقق منها وتثبيتها | التوليد والتحقق نجحا على هذا الخادم، والتثبيت يحتاج صلاحيات root على الخادم | lab/install_server.py supervise: تُعاد كتابة الوحدة المرفقة لمسارات التثبيت وحساب الخدمة ومجلد Bun، ويُتحقق من الناتج بـsystemd-analyze verify، وتُسجَّل أوامر التثبيت بدقة (docs/evidence/supervisor-unit.json، passed: true). يرفض إعادة كتابة وحدة تغيّرت مواضع توجيهاتها، ويرفض مجلد Bun فارغًا، ويرفض حسابًا أو مسارًا ليس بوضوح ما يدّعيه، ويرفض تثبيت وحدة لم تجتز التحقق، ويرفض --apply دون root، ويُفشل التشغيل إذا لم تصبح الوحدة المثبّتة نشطة أبدًا. يثبّت --apply الوحدة في /etc/systemd/system/sbarbase.service، ثم يعيد تحميل systemd ويفعّلها ويشغّلها |
| المسار الخاضع للإشراف تحت systemd | نجح على هذا الخادم، 10 فحوص | docs/evidence/supervised-run.json، الساعة 5:08 مساءً، 10 من 10: حُمّلت وحدة systemd مؤقتة للمستخدم تحاكي توجيهات الوحدة المرفقة (بوابة ExecStartPre وExecStart وPATH)، فقبلت البدء، وشغّلت المشرف ولوحة الإدارة، وأجابت لوحة الإدارة ونطاق الإدارة، وشغّلت الوحدة الحاويات المملوكة، وعمل الفحص المسبق تحت systemd، وعاد systemctl stop بلا خطأ، وأُزيل ملف الوحدة ولم تبقَ حاوية مملوكة تعمل. ليست هذه الوحدةَ المرفقة مثبّتة في /etc/systemd/system؛ ذلك ما يغطيه اختبار الاستلام الآن بالضبط: يثبّت الوحدة بصلاحيات root، ويشغّلها، وتتحقق التجربة من الملف المثبّت نفسه (verify_source: installed، 13 فحصًا، 7:25 مساءً). يجتاز هذا التشغيل الفحص المشدَّد: صف البوابة يشترط سطر البوابة نفسه Preflight: 0 blocker(s) لا أي مخرجات منها، وانتظار لوحة الإدارة لا يقبل إلا حالة كُتبت بعد البدء تحت systemd، لا حالة تركها تشغيل سابق |
| تجربة كاملة لدورة حياة المصدر والهدف | نجحت على هذا الخادم | docs/evidence/deployment-rehearsal.json، 11 من 11 فحصًا، 2026-09-20 17:21: الفحص المسبق، وسلامة الصفحة المبنية، وبدء المشرف، وتقديم لوحة الإدارة، ونطاق هوية الإدارة 200، ومسارات البيئات الثمانية كلها 200، و18 فحصًا حيًا لتهيئة المشغّل، و14 فحصًا مشتركًا للبوابة، وإيقاف نظيف، ولا حاوية مملوكة تعمل بعده. يحمل الدليل أيضًا سياق البدء (attempts_used: 1، بلا رفض) وحالة الوحدة التي رآها (verify: passed على قالب المستودع، verify_source: template، لأن لا وحدة مثبّتة هنا). صف systemd فيه أخضر لأن الوحدة لم تكن مطلوبة: شُغّل المشرف مباشرة ولم تُثبَّت sbarbase.service، ونص الصف نفسه يقول إن شيئًا لم يُجرَّب تحت systemd. نسخة الاستلام (--require-unit، ولها ملف أدلتها docs/evidence/server-acceptance-rehearsal.json) تشترط أن تكون الوحدة المرفقة مثبّتة، وتسجّل الآن 13 من 13 مع verify_source: installed |
| تثبيت جديد على خادم فارغ | نجح في محاكاة على آلة افتراضية محلية، لا على خادم حقيقي | آلة Fedora 44 Cloud افتراضية، 4 معالجات افتراضية، 6 GiB، نسخة نظيفة من المستودع عند 0aa0942: نجح اختبار الاستلام بأمر واحد مع --install-unit --first-project بنتيجة 12 من 12 (vm-empty-server-acceptance.json)، ونجح المشروع الأول بنتيجة 13 من 13، منها supabase-js عبر البوابة (vm-empty-server-first-project.json)، وعادت الخدمة وحدها بعد إعادة التشغيل. كشف الوصول إلى هنا عشرة عيوب لم تستطع محطة العمل إظهارها، وأُصلح كل منها مع اختبار: فحص لوحة الإدارة قبل بنائها، وحدود الإدخال والإخراج على قسم من القرص، ومتطلبات المعالج والذاكرة المأخوذة من ثابت مكتوب في الكود، وإرسال أول تشغيل فاشل إلى التبنّي، ورفض طلبات POST بلا جسم عبر المستمع الحقيقي، ومنفذ مؤقت للوحة الإدارة، ومهلة سحب صامتة، وفحص ثابت لبيئة تشغيل بحجم 6 GiB، وبيئات لم تستطع إعادة التشغيل التالية قبولها (الملخص). أعد التجربة بـlab/vm-rehearsal.sh. الخادم الحقيقي يضيف شبكة عامة وشهادة عامة وقرص مزوّد الخدمة وشبكته |
| القبول المشترك لبيئة التشغيل على هذا الخادم | نجح | docs/evidence/combined-runtime-admission.json كما هو في المستودع: قُبلت حدود حاويات بمجموع 5888 MiB و5.75 معالج مع 9301 MiB متاحة، وشُغّل الهدف في التشغيل نفسه (كل تشغيل مشترك يعيد توليد الملف، فسجّلت تشغيلات سابقة للقياس نفسه 8943 و8766 MiB). سجّلت التجارب المحيطة به 8885 و8481 MiB متاحة (docs/evidence/deployment-rehearsal.json)، ورأت الفحوص المسبقة في تشغيل الاستلام نفسه ما بين 8900 و9453 MiB |
| إنهاء HTTPS | نجح على هذا الخادم، 27 فحصًا | lab/tls_termination_check.py: ينهي deploy/console-tls-proxy.ts اتصال TLS (بشهادة موقّعة ذاتيًا في الفحص) أمام خادم بديل يقدّم الصفحة المبنية الحقيقية. تصل الصفحة وملفاتها عبر HTTPS مطابقة بايتًا ببايت، ومسار إدارة واحد قابل للوصول، وترويستا HSTS وnosniff مضبوطتان، والبروتوكول يُمرَّر على أنه https، وHTTP العادي يأخذ 308، والمضيف الذي ليس المضيف العام ولا loopback ولا عنوان Studio مطابقًا لـ --studio-host يُرفض بـ 421 ولا يصبح وجهة إعادة توجيه أبدًا، وعنوان Studio المطابق يمر باسمه، والترويسات الخاصة بالقفزة الواحدة لا تُمرَّر، والجسم المعلن فوق --max-body يأخذ 413 دون قراءته، والجسم المجزّأ يُرفض لحظة تجاوز التدفق الحد (مع جسم مجزّأ ضمن الحد يصل إلى الخدمة خلفه كضابط إيجابي). يرفض الوكيل مفتاحًا مقروءًا للجميع، وخدمة خلفية على غير loopback، وشهادة مفقودة، ومضيفًا عامًا مفقودًا، ومضيفًا عامًا ليس اسم مضيف مجردًا (docs/evidence/tls-termination.json). الشهادة العامة ووكيل المشغّل الخاص من شأن الخادم |
| خطوة تهيئة المشغّل، حية | نجحت على هذا الخادم، 18 فحصًا | تشغّل التجربة bun lab/bootstrap-check.ts على Auth الإدارة الحية وتسجّل 18 live operator bootstrap checks passed. تغطي إنشاء مشغّل حقيقي في Auth، والتعافي من تهيئة مقطوعة، والتحقق من كلمة المرور، وسجل العملية الخاص، وفهرسًا يتحمل التكرار، واكتشاف المنظمات بعد المصادقة، ثم تحذف حساب الفحص. يكتب السكربت ناتجه في .lab/upstream/bootstrap-verification.json، أما docs/evidence/bootstrap-checks.json فنسخة من تشغيل أقدم ومنفصل للسكربت نفسه، محفوظة للسجل |
| خطوة بناء لوحة الإدارة، معزولة ومتحقق منها | ثبتت على هذا الخادم | lab/console_build_check.py: خرج البناء بالرمز 0، والصفحة 392 بايت، وملفاها المشار إليهما موجودان وبصمتاهما في docs/evidence/console-build.json؛ و8 اختبارات في lab/test_console_build.py |
| طبقة تقديم الملفات الثابتة للوحة الإدارة، معزولة | ثبتت على هذا الخادم، 19 فحصًا | bun lab/console-serve-check.ts: تُقدَّم الصفحة المبنية وملفاها على منفذ loopback مؤقت، وتطابق بايتات الملفات المقدَّمة الملفات المبنية، وتصمد ترويسات الأمان ورفض الأساليب وفحص مضيف loopback. ترسل فحوص تجاوز المسار الطلب الحرفي GET /../src/... ونسخة مرمّزة بالنسبة المئوية عبر مقبس خام، لأن fetch يطبّع مسار التجاوز قبل خروجه من العملية؛ وفحص ثالث يختبر قائمة الملفات المسموحة مباشرة ويثبت أنها ما زالت تقبل ملفًا حقيقيًا (docs/evidence/console-serve.json) |
| الصور مثبّتة الإصدار موجودة ومطابقة لبصماتها | ثبت على هذا الخادم | lab/pinned_images_check.py: كل التثبيتات الخمسة تشير إلى البصمة المثبّتة في docs/evidence/pinned-images.json؛ و6 اختبارات في lab/test_pinned_images.py. يعيد المثبّت الآن التحقق من كل تثبيت بعد التأكد من وجود الصورة |
| تثبيت إصدارات Studio وpostgres-meta | مثبتان في ملفات اعتماد الصور الموزعة | سياسة التحديث، وفحص Studio. تثبيت الصور لا يثبت اعتماد تحديث جديد من Supabase أو قبول كل مكونات البنية التجريبية |
| Studio وpostgres-meta | منفّذان ومثبّتا الإصدار لكل بيئة عند الطلب في البنية المشتركة | دليل Studio، وفحص Docker. هذا النطاق لا يثبت قبول Studio في البنية الأصلية المستقلة أو اعتماد إصدار جديد من Supabase |
| ترحيل التثبيت المحفوظ إلى سلطة HBA مملوكة | منفّذ ونُفّذ فعلًا | تُبنّيت القاعدتان المحفوظتان كلتاهما؛ لكل دور قسم عملية (7 فحوص) وقسم تحقق (12 فحصًا) في docs/evidence/retained-source-adoption.json وretained-target-adoption.json، والقواعد محفوظة بايتًا ببايت |
| مكان تشغيل هدف الاستعادة يبدأ ويخدم | جُرّب حيًا ونجح | docs/evidence/target-placement-rehearsal.json، 12 فحصًا: بدء دورة الحياة، وAuth وREST بالرمز 200، واستئناف التوجيه، وإيقاف نظيف |
| كاتب HBA للهدف الجديد على حاوية مؤقتة | ثبت عمله، 16 فحصًا | docs/evidence/target-hba-creation-checks.json؛ لم يُعد تشغيل مسار الاستعادة الذي يستخدمه مع الكاتب المملوك |
| مراجعة هجومية لكود الهدف والنشر | اكتملت، و12 ملاحظة إلزامية الإصلاح أُصلحت كلها | docs/engineering/reviews/target-and-deployment-review.md؛ الإصلاحات مغطاة أدناه |
| تشغيل الاستلام بحساب التثبيت | أُصلح ويغطيه اختبار يمنع عودته | كشف تشغيل أمر sudo الموثّق عيبًا لم تجده أي مراجعة: كان يشغّل الفحص المسبق والفحوص والتجربة بصلاحيات root، فرفض نموذج الملكية في التثبيت بيئة التشغيل بالرسالة HBA ownership inode mismatch، لأن ملفات الحالة ملك لحساب الخدمة وrequire_lock يقارن مالكها بمعرّف المستخدم العامل. صار السكربت يشغّل كل خطوات التثبيت بحساب --service-user (وافتراضيه مالك نسخة المستودع)، ولا يبقي root إلا لخطوتي الوحدة، فيعمل أمر sudo الواحد كما هو مكتوب على خادم يملك تثبيته حساب خدمة (يغطي lab/test_server_acceptance.py التوجيه، والقيمة الافتراضية، والتحكم عبر sudo -n في النظام، والمسار المباشر للغلاف). كشف التشغيل نفسه النصف الآخر: سياق Docker لحساب الخطوة يحدد الخدمة التي تصلها الخطوات، وsudo لا ينقل DOCKER_HOST من الصدفة التي استدعته إلى السكربت، فرفض الفحص المسبق على هذا الخادم بينما وصل root إلى خدمة Docker قبل ثوانٍ. صار --docker-host يصدّر نقطة الاتصال لكل خطوة، ومنها خطوتا الوحدة، فيتحقق التشغيل من خدمة Docker التي ستستخدمها الخدمة؛ ودليل النشر يذكر متى يلزم هذا الخيار |
| مراجعة هجومية ثالثة لإصلاحات الليلة | اكتملت، و9 ملاحظات إلزامية الإصلاح عولجت | هاجمت المراجعة التغييرات التي أغلقت المراجعة الثانية والعيوب التي كشفها تشغيل الأمر الموثّق. وجدت ما يلي، وهذه المراجعة تصلحه: فحص حالة الوحدة كان يضيف unknown بالضبط حين تكون الوحدة متوقفة، فلم يكن لبوابة الإيقاف أن تنجح أبدًا، وكان كل تشغيل بـ--install-unit يتوقف برفض كاذب ويترك التثبيت متوقفًا؛ والوحدة لم تكن تُحرَّر إلا مع --install-unit، فقد يصطدم --rehearse العادي بتثبيت حي تحت الإشراف، ولم يكن شيء يعيدها بعد فشل (صار فخ يعيدها عند أي خروج)؛ والمولّد كان يرفض /opt/sbarbase، وهو التخطيط الذي تسمّيه الوحدة المرفقة أصلًا؛ وحد الجسم في الوكيل كان ما زال يخزّن الجسم المجزّأ كاملًا قبل رفضه (صار يقرأه ويرفضه عند الحد)؛ وصف بوابة الإشراف كان يقرأ نافذة من 60 سطرًا في سجل systemd قد تحتوي قبول تشغيل سابق (صارت محصورة في البدء الحالي)؛ والحجب فاتته صيغة --bootstrap-file=PATH؛ وانهيار في فحوص TLS أو لوحة الإدارة قد يترك أدلة التشغيل السابق في مكانها (صار كلاهما يمسحها أولًا، وسكربت الاستلام يقول هل كُتب ملف)؛ والصف الذي كان يبلّغ بالأخضر عن "supervised path exercised through systemd" صار يقول ما يعرفه فعلًا. واعتراضاتها الرقمية على هذه الوثيقة (القبول 8766 لا 8943، والبصمة 341 لا 313، والخطة 8789 لا 8761، و14 اختبار استلام لا 10) مصحّحة أعلاه |
| مراجعة هجومية ثانية لأدوات النشر | اكتملت، وعولجت الملاحظات العشرون إلزامية الإصلاح كلها، وصُحّح 17 ادعاء في الوثائق | docs/engineering/reviews/deployment-tooling-review-2.md؛ صُحّح كل ادعاء ثبت خطؤه في مكانه. وأُغلق بعد ذلك أيضًا أخف بندين فيها: صارت rehearse() تعيد السياق الذي تحتاجه الأدلة (المحاولات، وحالة الوحدة، وفشل التثبيت) بدل None لا يُستخدم، وأُعيد اشتقاق مجاميع الفحوص من تشغيلات جديدة بدل نقلها من تشغيلات أقدم |
| تجربة النشر بأمر واحد | منفّذة، وتسجّل الرفض بصدق | lab/deployment_rehearsal.py؛ نجح التشغيل المحفوظ في المستودع بنتيجة 11 من 11 في 2026-09-20 الساعة 5:21 مساءً (docs/evidence/deployment-rehearsal.json). التشغيل حين تنقص ذاكرة الخادم يسجّل الرفض ولا يشغّل شيئًا، وقيس ذلك هنا مرارًا: Combined resource admission refused: host_memory_headroom عند 8736 و8488 و8663 و8187 MiB متاحة، مقابل خطة تراوحت بين 8758 و8810 MiB مع تغيّر الكلفة المقيسة لمرحلة المصدر، ونجح التشغيل الأخضر حين بلغ الخادم 8900 MiB. التشغيل الذي لا يستطيع التثبيت يسجّل installation steps completed بقيمة false مع مسار التشخيص بدل أن يموت بلا أدلة، وdeploy/server-acceptance.sh يقول هل كُتب ملف الأدلة. نسخة الاستلام من التجربة نفسها، التي تشترط الوحدة المثبّتة، تسجّل 13 من 13 |
| تشغيل استلام الخادم | نجح من أوله إلى آخره على هذا الخادم، 13 من 13، بأمر واحد | اكتمل sudo deploy/server-acceptance.sh --rehearse --install-unit --service-user <account> --home /home/<account> --bun-dir /home/<account>/.bun/bin --docker-host unix:///var/run/docker.sock الساعة 7:25 مساءً برمز الخروج 0: المتطلبات، والفحص المسبق 0 blocker(s)، وفحص تقديم الملفات الثابتة للوحة الإدارة (19 فحصًا)، وإنهاء TLS (23 فحصًا)، وتوليد الوحدة وتثبيتها بصلاحيات root في /etc/systemd/system/sbarbase.service، والتجربة مع --require-unit (13 فحصًا: خطوات التثبيت، وسلامة الصفحة المبنية، وامتلاك المشرف للوحة الإدارة، وتقديم لوحة الإدارة، ونطاق الإدارة، وكل مسارات البيئات المسجلة، و18 فحصًا حيًا للتهيئة، و14 فحصًا مشتركًا للبوابة، والوحدة المثبّتة مفعّلة ومتحقق منها، وإيقاف نظيف، ولا حاوية مملوكة باقية)، وإعادة تشغيل الوحدة، ونسخة التسليم (docs/evidence/server-acceptance-latest.json، passed: true، 13 فحصًا). سجّلت تشغيلات سابقة للسكربت نفسه 11 من 12 الساعة 5:11 مساءً، و12 من 12 الساعة 6:08 مساءً مع وحدة مثبّتة يدويًا. هذا التشغيل الأخضر هو الذي وجد العيبين اللذين لم ترهما أي مراجعة، وقد أُصلحا وغطاهما اختبار كما في الصفوف أعلاه. أُزيلت الوحدة بعده وأُعيدت حزمة محطة العمل إلى حالها |
| الإشراف مع سياسة إعادة التشغيل | مثبّتة ومفعّلة ونشطة على هذا الخادم؛ شرطان مسبقان كانا عيبين، وأُصلحا | deploy/sbarbase.service مع فحص مسبق في ExecStartPre، وسياسة لإعادة التشغيل، ومهلة إيقاف 150 ثانية. كشف تثبيتها وتشغيلها فعلًا مانعين لم تجدهما أي مراجعة: كانت الوحدة تطلب ReadWritePaths=$HOME/.secrets، وهو مجلد لا ينشئه شيء، فأفشلها systemd بـ226/NAMESPACE قبل تنفيذ أول أمر (صارت الوحدة تسمّي نسخة المستودع وحدها، واختبار يرفض أي مسار كتابة خارجها)؛ والخدمة على مستوى النظام لا ترث صدفة المشغّل، فعلى خادم يشير سياق Docker فيه إلى مقبس سطح المكتب لا يمكن الوصول إلى خدمة Docker، وصار الفحص المسبق يقول ذلك بالضبط ويسمّي نقطة الاتصال التي جرّبها، بدل أن يبلّغ أن الصور غائبة وأن الخادم تثبيت جديد. بعد إصلاح مسار نسخة المستودع وتوجيه DOCKER_HOST إلى مقبس النظام، ثُبّتت الوحدة وفُعّلت وبلغت active هنا (5:59 مساءً). أعاد تشغيل الاستلام إثبات المسار كله الساعة 7:25 مساءً بحساب خدمة بدل root: التثبيت، والتفعيل، والبدء، والتحقق بـsystemd-analyze verify، وإعادة التشغيل بعد التجربة، ثم الإزالة لترك محطة العمل كما كانت |
| ملف تهيئة المشغّل، يُنشأ دون تسريب كلمة المرور | منفّذ، وثبت عمله | يكتب lab/operator_file.py ملف JSON بصلاحيات 0600 يقرؤه التثبيت من الدخل القياسي: يسأل عن البريد الإلكتروني والمنظمة وكلمة المرور مرتين دون إظهارها، أو يأخذ الكائن نفسه من دخل قياسي محدود (--stdin، 8192 بايت) للأتمتة. يرفض كلمة مرور قصيرة، وبريدًا مشوّهًا، وحقولًا سيرفضها التثبيت، ومسارًا نسبيًا، ومجلدًا أبًا مفقودًا، ورابطًا رمزيًا، وملفًا موجودًا دون --force، وكتابة تفشل في منتصفها. مخرجاته تسمّي المسار والصلاحيات، ولا تذكر كلمة المرور أبدًا. 9 اختبارات في lab/test_operator_file.py، ودليل التشغيل ينشئ الملف به قبل install --bootstrap-file |
| الحساب والتخطيط اللذان يعمل بهما التثبيت | مسمّيان ومتحقق منهما، ويُرفض الحساب المفقود | يقبل lab/install_server.py supervise الخيارات --service-user و--home و--bun-dir، ويمرّرها deploy/server-acceptance.sh. يرفض المثبّت --apply لحساب غير موجود (الافتراضي المرفق sbarbase)، ويسجّل `service_account: present |
| HTTPS والتعرض للشبكة | الإنهاء منفّذ ومفحوص على هذا الخادم؛ الشهادة العامة ووكيل الإنتاج من شأن المشغّل | deploy/console-tls-proxy.ts وlab/tls_termination_check.py (27 فحصًا، docs/evidence/tls-termination.json)؛ دليل التشغيل في docs/guides/server-deployment.md. التثبيت نفسه لا ينشر أي منفذ |
| الترقية والتراجع | lab/upgrade.py مع عودة تلقائية، شُغّل بالأمر start --to في CI وفي الآلة الافتراضية التجريبية. أما قناة التحديث (إصدارات موقّعة، والتثبيت من لوحة الإدارة مع إقرار لتغييرات Auth وStorage وRealtime، والتحديث التلقائي الاختياري، والتصريف، وحارس التشغيل، والاعتماد المشروط بفحوص السلامة) فتغطيها اختبارات الوحدات وحالات CI الخاصة بها، التي نجحت على جهاز CI نظيف في 2026-09-25 (docs/evidence/docker-upgrade-checks.json، 45 فحصًا من 45)، وشُغّلت في الآلة الافتراضية التجريبية المحلية في 2026-09-26 كما يستخدمها المشغّل: إصدارات من مستودع محلي موقّعة بمفتاح مؤقت، ثُبّتت عبر واجهة الإدارة وبالتحديث التلقائي، وعاد صباربيز وحده من إصدار معطوب، وثُبّت إصدار attended يغيّر Auth بعد الإقرار (docs/evidence/vm-channel-checks.json، 114 فحصًا من 114؛ ودورة سطر الأوامر docs/evidence/vm-upgrade-checks.json، 26 فحصًا من 26). ولم يُشغَّل أي جزء منها على خادم حقيقي. لم يُعتمد أي إصدار من الأصل بعد |
docs/guides/upgrades.md وdocs/engineering/UPDATE-CHANNEL.md وdocs/engineering/UPSTREAM-UPDATE-POLICY.md |
| النسخ الاحتياطي والاستعادة | نسخ يومي واستعادة، ونسخ مشفّرة إلى مخزن متوافق مع S3 | دليل المشغّل، وفحص النسخ خارج الخادم: نسخ وجلب واستعادة عبر MinIO مؤقت فعلي. لم يثبت مزوّد خارجي حقيقي أو تعافٍ كامل من فقد الخادم |
| السعة عند 10 مشاريع أو 100 | غير مدّعاة | حدود مضبوطة فقط، بلا قياس لذروة الطلب |
| Realtime وEdge Functions | منفّذان لكل بيئة ضمن البنية المشتركة | فحص Realtime، وفحص Functions، ضمن نطاق كل ملف |
| مجمّع الاتصالات وcron | غير متاحين كميزتين تشغيليتين مدعومتين في البنية المشتركة | وجود امتداد في صورة Supabase وفحص تهيئته لا يثبت دعم الميزة لكل بيئة |
ترتيب التجارب حين يتوفر خادم
- شغّل
/usr/bin/python3 lab/install_server.py checkعلى الخادم. أصلح كل مانع أولًا؛ الخادم الذي يفشل في التحقق لا يُثبَّت نصف تثبيت. - شغّل
/usr/bin/python3 lab/deployment_rehearsal.py --bootstrap-file <0600 JSON>على خادم جديد. يثبّت، ويشغّل الإشراف، ويتحقق من الوصول إلى لوحة الإدارة ونطاق الإدارة، ويفحص كل مسار بيئة مسجل، ثم يوقف المشرف ويتأكد أن لا حاوية مملوكة بقيت تعمل، ويكتبdocs/evidence/deployment-rehearsal.json. - شغّل
/usr/bin/python3 lab/target_placement_rehearsal.pyإذا كان للتثبيت هدف استعادة، لتعيد إثبات مكان التشغيل ذاك على الخادم. - شغّل
/usr/bin/python3 lab/combined-supervisor-check.pyللتجربة الكاملة للمصدر والهدف معًا، وهي تحتاج هامش الذاكرة كاملًا. - احفظ ملفات الأدلة مع سجل النشر. التجربة الفاشلة دليل أيضًا: الرفض يُسجَّل ولا يُخفى.
فجوات التجربة المشتركة التاريخية، سجل الوثائق في 2026-10-06
يتضمن المصدر المدمج الآن آليات دائمة لمنح صلاحيات الإدارة والحد من المحاولات، وملفات النقل الإداري وسجله، وسلطة دورة الحياة والاستعادة. لذلك لا تصف عبارات غياب المصدر أدناه الشجرة الحالية. ما زال تطبيق MFA والحد من المحاولات في التشغيل الأصلي المثبت والنقل الكامل لبيانات الاعتماد والحذف المتقطع وتحرير الموارد وسلامة البيئات المجاورة والاستعادة يحتاج أدلة حالية للدمج. تحفظ البنود التاريخية ما كان ينقص اللقطة المشتركة السابقة؛ ولا تصف المصدر الحالي أو تمنح قبولا للإنتاج.
- الحمل المختلط المستمر، وتشبّع الاتصالات، والسعة عند 10 مشاريع أو 100، كلها لم تُقس بعد؛ التجربة القصيرة تثبت التوفر لا السعة.
- موت المتحكم أثناء تجهيز جارٍ، وانقطاع الكهرباء، والتنسيق بين عدة خوادم، ما زالت بلا إثبات؛ أدلة الانهيار الحالية تغطي نقاط تحقق محددة، لا انهيارات في أي لحظة.
- فحص التحقق من Storage وسكربتات التهيئة القديمة ما زالت تكتب
pg_hba.confمباشرة، كما يحصيهاdocs/engineering/TARGET-HBA-WRITERS.md. هي مسارات وقت الفحص أو مسارات قديمة، لا كتّاب مُدارون في بيئة التشغيل. - تحتاج الوحدة الخاضعة للإشراف مقبس خدمة Docker تصل إليه الخدمة: على خادم فيه
Docker أصلي هو
/var/run/docker.sockمع مجموعةdocker؛ وعلى خادم يشير سياق Docker فيه إلى مقبس سطح المكتب تحتاج ملف الإضافة المذكور في دليل التشغيل. لم تبلغ الوحدةactiveهنا إلا بعد إضافة ذلك الملف. - ترحيل جيل الحاوية منفّذ ومجرَّب مع الانقطاع المفاجئ على بيئات مؤقتة، وشُغّل مرة
واحدة بحضور المشغّل على القاعدة المحفوظة في 2026-09-25، وبقيت كل الصفوف كما هي
(
docs/evidence/generation-migration-retained.json). لا يعمل تلقائيًا، ولا ينقل بين خوادم (docs/engineering/CONTAINER-GENERATION-MIGRATION.md). - التهيئة الأولية تنشئ المشغّل الأول فقط، ومن بعده ينضم المشغّلون بدعوة. لا يوجد MFA، ولا حدّ لمحاولات تسجيل الدخول، ولا إجراء مدعوم للإصلاح أو إعادة الضبط.
سجل التحقق السابق في أكتوبر
هذه تصريحات محفوظة من نوافذ مصدر سابقة، مع نتائجها وروابطها الأصلية، ولا تصف نتيجة V11 التاريخية اللاحقة. لا تثبت أدلة دورة حياة HTTPError اللاحقة أسباب التخصيص في تلك الحزم بأثر رجعي.
آخر نطاق للأدلة في 2026-10-05: دُمجت ستة إصلاحات للمصدر بعد مراجعات مستقلة. أصبح مسارا SQLite يغلقان الاتصال بعد انتهاء المعاملة الأصلية؛ وتلتقط 27 دالة لاختبارات الرفض خرج stderr كاملا وتتحقق منه في ثلاثة ملفات؛ ويمتلك إعداد اختبار tempfile إغلاق الملف ويسجل حذفه قبل الكتابة التي قد تفشل. هذه إصلاحات مصدر، ولم يكن التحقق العملي الكامل للإصدار المعدل قد نُفذ عند تلك النقطة. أصبحت نتائج المصدر والهوية والصلاحيات والمجموعة الكاملة المرتبطة بـ875 ملفا أدلة تاريخية، ولا تقبل هذه الشجرة المعدلة.
حصل نطاق public55 V3 المنفصل على قبول عملي: نجحت 25 حالة للمكوّن و30 للمضخة، وطابقت قراءة الملفات الأصلية الـ290 وقراءة الملفات الأربعة المضافة مع فحص صلاحياتها الأدلة، وحُذفت الحاويات الثلاث المعروفة دون موارد معلقة. وحصل نطاق بيانات المساعدة العامة BusyBox V8 على قبول عملي: أعاد Bash 5.3.3 وBusyBox 1.37.0 في المسارين المحددين بيانات الإصدار والمساعدة مع خروج بالرمز 0، وحُذفت حاويته الوحيدة. لا تقبل النتيجتان طلبا خاصا أو توقيت timeout وإشاراته أو مصدر الملف التنفيذي أو تشغيل المرشح أو استمرارية Vault وCron الباردة والدافئة أو الاستعادة الفيزيائية أو الإنتاج.
أعلنت تجربة نافذة التحذيرات V4 المحفوظة نجاح 1447 اختبارا عاديا، لكنها سجلت ستة ResourceWarnings وخرجت بالرمز 1، وكانت نافذة الملاحظة 839 لكل التحذيرات. تحمل ثلاثة سجلات النوع الدقيق sqlite3.Connection، وثلاثة اسم tempfile.py والسطر 484 مع مصدر NoneType. لا تحدد نافذة الملاحظة موضع التخصيص أو سببه؛ ولم تحدد تلك الحزمة أسباب تخصيص موارد tempfile الثلاثة. يلزم ربط المصدر والهوية والصلاحيات والمجموعة الكاملة من جديد، ثم CI للإصدار النهائي واستلام الخادم الخالي بتشغيل يدوي. تحتفظ نتائج CI والموقع للإيداع المنشور 0e745394 بنطاق ذلك الإيداع فقط.
بدأ هذا التقييم في 20 سبتمبر 2026؛ وصُححت حدود الميزات في 5 أكتوبر 2026. تحتفظ المصفوفة بنتائج التجارب السابقة، ولا تعني إعادة التحديث أن كل صف فُحص على الشيفرة الحالية. نسخة التطوير المعلنة 0.2.0، والنتائج تخص البنية المشتركة الحالية، ولا تثبت قبول native-dedicated أو التشغيل على خادم مستقل أو التوافر العالي أو الاستعادة إلى نقطة زمنية. انظر الحالة وخطة العمل الحالية وسجل الأدلة.
نجحت مهام الفحوص وتوافق Python وتثبيت Docker في CI 37206229288 عند الإيداع المنشور 0e745394. كانت مهمة الخادم الخالي متخطاة وتحتاج إلى تشغيل يدوي جديد. نجح بناء الموقع 37206294329 منفصلا، دون نشر خدمة عامة. تخص النتائج هذا الإيداع وحده؛ تعديل المصدر والوثائق يحتاج فحوصا جديدة.
هذا الحاسوب خادم Linux Docker محلي معزول للتجارب المعلنة؛ ولا يثبت ذلك قبول خادم عام مستقل. أداة التجهيز تعرّف تسليم مواد للتجهيز فقط، ولا توجد نتيجة تجهيز عملي أو تشغيل قاعدة مقبولة هنا.
تحتفظ المحاولة السابقة V9 initV2 بنتيجتها المرفوضة: نجحت الحالات المركزة 14 و9 و29، لكن المجموعة الكاملة نفذت 1447 اختبارا خلال 72.300 ثانية مع فشل واحد و15 خطأ. كانت الأخطاء سبعة في صلاحيات سكربت استلام الخادم وثمانية في مساحة .lab المقروءة فقط، مع فشل فحص إذن التنفيذ. طابقت قراءتا الملفات الـ290 وربط المصدر الـ875، وحُذفت الحاويات الست المعروفة دون موارد معلقة؛ ولم يتكرر عيب Git السابق. العدد 1356 حد قبول أدنى، وليس عدد الاختبارات الفعلي.
حصل التصحيح التاريخي لصلاحيات الملفات ومساحة الاختبارات على قبول مستقل للمصدر وبناء صورتي المصدر والهوية؛ ولم يعد ربط الملفات الـ875 صالحا للشجرة الحالية بعد الإصلاحات الستة. لكن التحقق الكامل اللاحق بقي مرفوضا: أعلنت unittest نجاح 1447 اختبارا خلال 51.862 ثانية، ونجحت الحالات المركزة الـ52، وطابقت قراءتا الملفات الـ290 وفحصا صلاحيات المسارات الـ875 الأدلة المعتمدة، وحُذفت الحاويات الثماني المعروفة دون موارد معلقة. رغم ذلك خرجت حاوية المجموعة الكاملة بالرمز 1 دون علامة النجاح النهائية المطلوبة. لا تحدد تلك الحزمة سبب رفض الابن بدقة، وتخالف أيضا 70 رسالة متوقعة من اختبارات الرفض قواعد خرج المشرف. ثم قبلت مراجعة مستقلة تجربة تشخيص سالبة فقط: نجحت فيها 1447 حالة خام خلال 51.835 ثانية، لكن المرحلة 7 سجلت ستة تحذيرات وخرجت بالرمز 1، مع إتمام التنظيف. تحدد هذه النتيجة بوابة التحذيرات في تجربة التشخيص نفسها، ولا تثبت سبب المحاولة السابقة ولا قبول المجموعة الكاملة. دُمج إصلاح التقاط stderr في 27 دالة اختبار بعد قبول المصدر، مع إصلاحي إغلاق SQLite وإصلاح إعداد tempfile عند فشل الكتابة. لم يكن تحقق المصدر المعدل قد نُفذ عمليا عند تلك النقطة. تحدد تجربة نافذة التحذيرات اللاحقة نافذة الملاحظة 839 وبيانات محدودة عن النوع، دون سبب التخصيص؛ ولم تحدد تلك الحزمة أسباب تخصيص موارد tempfile الثلاثة. يلزم تحقق كامل جديد على المصدر المعدل. تجهيز المواد عمليا، ومضخة الطلبات الخاصة، وتشغيل القاعدة، واستمرارية Vault والاستعادة الفيزيائية والجاهزية للإنتاج لم تُقبل بعد.
فحص GNU التاريخي مرفوض، بينما حصل فحص بيانات مساعدة BusyBox اللاحق على قبول عملي محدود مع Bash 5.3.3 وBusyBox 1.37.0 وخروج بالرمز 0 وتنظيف الحاوية. ما زال سلوك timeout ومصدر الأدوات والتشغيل الخاص غير مقبول. راجع الحالة لنتيجة كل نطاق.