إنتقل إلى المحتوى الرئيسي

أساس المنصة

يدعم Libre WebUI ملف solo محليًا أولًا وملف team مشتركًا. يستخدم solo SQLite وكائنات ثنائية محلية مشفّرة ومتجهات مضمّنة مشفّرة وتنسيقًا محليًا وعاملًا دائمًا مضمّنًا. ويستخدم team ‏PostgreSQL وكائنات خاصة متوافقة مع S3 وPGVector وتنسيق Redis وعاملًا دائمًا خارجيًا. يرفض بدء التشغيل الملفات المختلطة بدل تقسيم الحالة بصمت بين خوادم خلفية محلية ومشتركة.

المرحلة الحالية​

المجالالأساس المنفذالعمل المتبقي على المستدعين
الاستمراريةمستودعات SQLite وPostgreSQL وهجرات ثابتة ومعاملات مجمعةيجب أن تستخدم المجالات الجديدة حدود المستودعات
الكائناتمخازن تدفق محلية ومتوافقة مع S3 مشفّرة، ونطاقات وchecksums وحصص دائمةنقل مرفقات المحادثة والصور الرمزية والحقول الثنائية المضمّنة المتبقية
المتجهاتمتجهات مضمّنة مشفّرة وACL في PGVector وإعادة بناء فهرس مستندات آمنة عند الحذفيجب أن يحافظ مستدعو التضمين الجدد على عقد السلطة ودورة الحياة نفسه
التنسيقأحداث محلية وRedis وcache وleases وحدود معدل وإبطال وصحةإبقاء Redis غير موثوق بوصفه مصدرًا للحقيقة
المهام/الأحداثقوائم SQLite/PostgreSQL وأحداث معاملية وعاملون وإعادة ومحاولة وإلغاء وإدارةيحتاج كل أثر جانبي جديد إلى تصميم idempotency أو outbox
التشغيلبوابات صحة وأرشيفات نسخ موقعة ومشفّرة واستعادة إلى هدف نظيف وتحققتمرين الاستعادة والقبول بين النسخ لكل بيئة نشر

ملفات بيئة التشغيل​

LIBRE_PLATFORM_MODE=solo هو الافتراضي. يختار SQLite والكائنات المحلية والمتجهات المضمّنة والتنسيق المحلي والعامل الدائم المضمّن. يمكن اختيار Redis في وضع solo، لكن ذلك لا يجعل SQLite أو الملفات المحلية آمنة للمشاركة بين النسخ.

يتطلب LIBRE_PLATFORM_MODE=team كل الاعتماديات المشتركة معًا:

  • DATABASE_BACKEND=postgres مع DATABASE_URL؛
  • BLOB_STORE_BACKEND=s3؛
  • VECTOR_STORE_BACKEND=pgvector؛
  • COORDINATION_BACKEND=redis مع REDIS_URL؛ و
  • JOB_WORKER_MODE=external.

هذه المحددات مجموعة متماسكة. يفشل بدء team إذا غابت أي اعتمادية مشتركة أو اختلط خادم خلفي محلي بالملف.

ترحيل تثبيت solo قائم​

أوقف كل تطبيقات Libre والعاملين قبل الترحيل. تستخدم الأمثلة أمر libre-webui المثبّت عالميًا من npm أو Homebrew. إن لم تثبّته عالميًا، فاستبدله بـ npx --yes libre-webui@latest. ومن نسخة المصدر، ابنِ مرة واحدة واستبدل libre-webui migrate-postgres بـ npm run migrate:postgres --. اضبط بيئة PostgreSQL وS3 ومفتاح التشفير ذي الإصدارات للهدف كما في نشر team الهدف تمامًا، ثم شغّل التحليل للقراءة فقط أولًا:

libre-webui migrate-postgres \
  --source /absolute/path/to/data.sqlite \
  --plugins /absolute/path/to/plugins \
  --mode dry-run

لا تطبق إلا على الهدف الفارغ الذي يحدده التقرير. يترك التشغيل الفاشل سجل استيراد ذا checksum؛ استأنف المصدر والهدف نفسيهما بدل بدء استيراد غير ذي صلة:

libre-webui migrate-postgres \
  --source /absolute/path/to/data.sqlite \
  --plugins /absolute/path/to/plugins \
  --mode apply

# Only after an interrupted apply of this exact source and target:
libre-webui migrate-postgres \
  --source /absolute/path/to/data.sqlite \
  --plugins /absolute/path/to/plugins \
  --mode apply --resume

libre-webui migrate-postgres \
  --source /absolute/path/to/data.sqlite \
  --plugins /absolute/path/to/plugins \
  --mode validate

لا تُكتب علامة الاكتمال حتى تُنقل الصفوف العلائقية وتعريفات المكوّنات والكائنات المحلية المشفّرة والمتجهات المضمّنة ومتجهات الشخصيات القديمة وتُصادق جميعها في PostgreSQL/S3/PGVector. لا يخترع الأمر مفتاح تشفير للمصدر؛ يجب أن يطابق ENCRYPTION_KEY ملف .encryption_key للمصدر، وأن يحتوي STORAGE_ENCRYPTION_KEYS المفتاح النشط المضبوط وإدخال legacy المطابق.

تشغيل ملف team المضمّن​

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

cp deploy/team/.env.example /absolute/path/to/libre-team.env
chmod 600 /absolute/path/to/libre-team.env

استبدل كل قيمة REPLACE_* قبل بدء التشغيل. ولّد كلمة مرور PostgreSQL بأبجدية آمنة في URL (مثل openssl rand -hex 32) لأن القيمة الحرفية نفسها هي كلمة مرور الخادم وجزء من DATABASE_URL. يجب أن يكون ENCRYPTION_KEY وكل قيمة داخل STORAGE_ENCRYPTION_KEYS بطول 64 حرفًا سداسيًا عشريًا بالضبط. في تثبيت جديد، يجب أن يساوي إدخال legacy قيمة ENCRYPTION_KEY؛ ولترحيل SQLite يجب أن يساويا مفتاح المصدر. استخدم مفتاحًا نشطًا مختلفًا لكتابات الكائنات الجديدة، واحتفظ بالمفاتيح القديمة حتى يثبت حصر الكائنات أنها غير مستخدمة.

يمكن للملف نفسه ضبط POSTGRES_MIGRATION_MODE وPOSTGRES_POOL_MAX ومهلات PostgreSQL المدعومة وREDIS_CONNECT_TIMEOUT_MS وOLLAMA_BASE_URL وOLLAMA_TIMEOUT وOLLAMA_LONG_OPERATION_TIMEOUT وOLLAMA_MAX_CONTEXT؛ وترسل بيئة Compose المشتركة كل قيمة بصورة متطابقة إلى التطبيق والعامل الخارجي. تقبل مهلات الموفّر 1,000-3,600,000 ملي ثانية، ويقبل السياق الأقصى 128-2,097,152 رمزًا، ولا يمكن أن تكون المهلة الطويلة أقصر من القياسية؛ وتفشل القيم المشوهة نقطتي دخول الخادم قبل إنشاء الحالة. لا يدعم العاملون الدائمون الخارجيون ملفات Agent CLI الثنائية المحلية للعقدة أو ملفات رموز Codex OAuth، لذلك يثبت ملف team مساري الموفّرين على التعطيل ويرفض بدء التشغيل محاولة تفعليهما. ثم شغّل نسخ التطبيق والعامل الدائم الخارجي وPostgreSQL/PGVector وRedis وbucket MinIO ذا الإصدارات والبوابة:

docker compose --env-file /absolute/path/to/libre-team.env \
  -f docker-compose.team.yml up --build --scale libre-webui=3 -d
docker compose --env-file /absolute/path/to/libre-team.env \
  -f docker-compose.team.yml ps

لا يربط ملف team الأساسي أي مقبس Docker عمدًا، لذلك لا تتوفر Work المدعومة بـ Docker. لا تفعّلها إلا بإضافة overlay الإنتاج المضمّن إلى كل أمر دورة حياة:

docker compose --env-file /absolute/path/to/libre-team.env \
  -f docker-compose.team.yml -f docker-compose.team.work.yml \
  up --build --scale libre-webui=3 -d
docker compose --env-file /absolute/path/to/libre-team.env \
  -f docker-compose.team.yml -f docker-compose.team.work.yml ps

يوجه overlay عمليتي التطبيق والعامل إلى proxy واحد مصفى لمقبس Docker على شبكة داخلية فقط. لا تتلقى أي عملية المقبس الخام أو عضوية مجموعة المقبس، وتظل مساحات Work المجلدية على المضيف معطلة. لا يكشف proxy إلا المعلومات والصور والحاويات وexec والوحدات والشبكات وطرق الكتابة التي تتطلبها استدعاءات دورة الحياة. يضيّق ذلك سطح API لكنه لا يجعل Docker حدًا بين المستأجرين؛ فلا يزال إنشاء الحاويات يستطيع bind-mount لمسارات المضيف. استخدم VM مخصصة أو daemon لـ Work بلا root أو منفصلًا عندما تهم عزلة المضيف.

لا تكشف خدمات PostgreSQL أو Redis أو MinIO المملوكة لـ Compose مباشرةً. للاعتماديات المُدارة، استخدم ملف Helm لفريق واحتفظ بـ TLS متحقق منه؛ ولا يعطّل ملف Compose ‏TLS لـ PostgreSQL إلا على شبكة المشروع الخاصة. تظل الجاهزية فاشلة حتى يوجد عامل خارجي.

حد الاستمرارية والترحيل​

تستخدم الهوية والتفويض الآن مستودعات غير متزامنة. تتلقى دالة callback للمعاملة وحدة عمل مرتبطة باتصال قاعدة البيانات نفسه؛ ويُرفض استخدام المستودع العام داخل تلك الدالة. هذا هو حد المعاملة الذي يستخدمه pool اتصالات PostgreSQL مع الحفاظ على سلوك SQLite الحالي.

لا يتبنى منسق هجرة SQLite التثبيتات الحالية إلا بعد التحقق من schema المطلوب. يسجل رقم الهجرة واسمها وchecksum، ويتحقق منها في كل بدء، ويرفض السجلات الأحدث أو المجهولة أو غير المتطابقة، ويفشل البدء عند فشل الهجرة أو التحقق من schema. تستهلك الجاهزية وحصر الاستعادة عقد الفحص القياسي نفسه.

قبل استيراد خدمات التطبيق ذات الحالة، ينسخ بدء التشغيل قاعدة SQLite القائمة وملفات WAL/SHM النشطة إلى دليل مؤقت خاص ويتحقق من النسخة. يجب أن يملك PLATFORM_PREFLIGHT_TMP_DIR مساحة حرة تكفي القاعدة وWAL. تربط عمليات نشر Docker وHelm المضمّنة تخزينًا مؤقتًا مخصصًا على القرص هناك؛ ولا يعتمد البدء على tmpfs المحدود في /tmp. يحظر مفتاح تشفير قديم مفقود أو دليل بيانات تاريخي متداخل البدء قبل إنشاء مفتاح بديل أو قاعدة أو حالة مكوّن.

يضيف schema v4 رمز مساواة ذا مفتاح لبريد الهوية المشفّر. تتطلب الاستعادة وجود كل رمز ومطابقته بريده الموثق. يسمح البدء برمز مفقود مع بريد موثّق أو قيمة قديمة ليست غلافًا أثناء نافذة الانهيار الضيقة بعد التزام v4، كي يُكمل تهيئة المستودع ملء التشفير والرموز. قبلت الإصدارات القديمة أي سلسلة بريد واستخدمت قيمة فارغة لمسح الحقل؛ يحافظ التبني على القيم غير الفارغة ويطبع الفارغة إلى NULL. تظل القيم التالفة الشبيهة بالأغلفة وأي عدم تطابق غير null سببًا لفشل الفحص.

تستخدم خدمات التطبيق مستودعات غير متزامنة بحسب dialect. يقتصر SQLite الأصلي على مهايئات SQLite وفحص الهجرة أو الاستعادة وفحوص الصحة المحقونة صراحةً. يُهيأ تخزين التشغيل من Persistence المحددة؛ ولا يعود تفعيل PostgreSQL إلى singleton SQLite أو ملفات JSON التاريخية المعتمدة على دليل العمل الحالي.

تبقى بيئة المهام الدائمة المشتركة محايدة تجاه برنامج التشغيل. تُقرأ صلاحية الفاعل عبر مستودع الهوية المحدد، بينما يقتصر بناء مستودع المهام الأصلي على حد واحد لتركيب المهايئات. يتلقى ناشرو المجال المعاملاتيون منفذًا متزامنًا opaque في SQLite ومنفذًا مرتبطًا بالمعاملة في PostgreSQL؛ ولا يتلقون handle من better-sqlite3. يرفض اختبار حد الاستمرارية handles برامج التشغيل الأصلية في عقود المهام والموارد والهوية والمحادثة وWork المشتركة.

أساس تخزين الكائنات والمتجهات​

تستخدم وسائط المعرض المولّدة وملفات مصدر المستندات BlobStore؛ وتستخدم RAG للمستندات وذاكرة الشخصيات VectorStore. تُقرأ صفوف معرض SQLite القديمة بالصيغة القديمة والجديدة وتُتبنى كمراجع كائنات عند أول وصول. البيانات الوصفية العلائقية والمرجع الدائم هما المرجع؛ ولا تُحفظ عناوين الموفّر أو مفاتيح S3 المادية كمحتوى للتطبيق. لا تستخدم مرفقات المحادثة والصور الرمزية والحقول الثنائية المضمّنة الأخرى مخزن الكائنات بعد، ولا ينبغي وصفها بأنها رُحّلت.

تصادق بوابة الاستعادة كل كائن دائم وغلاف متجه مضمّن تسلسليًا تحت حدود إجمالية صريحة. كما تصادق بصرامة أغلفة النص القديمة القابلة للتمييز وكل غلاف ثنائي لصوت محفوظ باستخدام ENCRYPTION_KEY للتطبيق؛ ولا تستخدم fallback التوافق في التشغيل الذي يفك ثم يعيد الأصل. ولا تهيئ تخزين المصدر أو تصلحه أو تعيد كتابته أو تحذفه؛ فتحظر اللقطة نصوص مشفّرة تالفة ومفاتيح مجهولة أو خاطئة وبنى كائنات غير قياسية وتجاوز حدود التحقق.

الحدود الافتراضية للاستعادة هي 250,000 كائن محلي، و64 GiB من بايتات الكائنات المشفّرة والصريحة، و250,000 صف متجه، و4 GiB من النص المتجهي المشفّر المتسلسل، و500 مليون مكوّن متجهي. يمكن للاختبارات والمستدعين المضمّنين تجاوز حدود كل تشغيل عبر RecoveryInventoryOptions؛ ولا تأخذ CLI عينة من الحالة الزائدة أو تتجاوزها بصمت.

تستخدم مصادقة النصوص المشفّرة القديمة افتراضيًا مليون حقل مرشح ممتلئ و16 GiB لكل من إجمالي البايتات المخزنة والنص الصريح الموثق. تظل صفوف النص الصريح من أجيال schema القديمة متوافقة لأن أغلفة النص القديمة لا تملك علامة دائمة؛ ولا يعد التقرير إلا الأغلفة الموثقة. أغلفة الأصوات المحفوظة واضحة دائمًا وتُصادق مع هوية الملف والمالك والحقل كبيانات إضافية.

الكائنات المحلية المشفّرة​

يقتصر BlobStore على المالك ويعرض put/read بالتدفق والبيانات الوصفية وstat ونطاقات بايت شاملة وحذفًا idempotent. يكتب LocalEncryptedBlobStore كائنات opaque بمفاتيح UUID تحت جذر يقدمه التطبيق؛ وهدف التكامل هو ${DATA_DIR}/blobs. يستخدم ملفات staging حصرية وfsync وإعادة تسمية ذرية داخل نظام الملفات نفسه، مع أدلة 0700 وملفات 0600.

لكل كائن مفتاح بيانات عشوائي 256-bit. يشفّر AES-256-GCM البيانات الوصفية الخاصة ويصادق مستقلًا أجزاء جسم محدودة. تربط البيانات الموثقة الإضافية معرّف الكائن والمالك والغرض وفهرس الجزء وطول النص الصريح. يلف keyring التخزين ذو الإصدارات كل مفتاح بيانات. يسجل descriptor الحجم الصريح وSHA-256 ونوع المحتوى ووقت الإنشاء وإصدار التنسيق ومعرّف مفتاح التشفير. تتحقق القراءة الكاملة من SHA-256؛ وتصادق قراءة النطاق كل جزء تلمسه.

يحجز عقد الحصة السعة قبل التدفق، ويستهلك البايتات الفعلية، ولا يلتزم إلا بعد الظهور الذري، ويحرر الحجوزات الفاشلة. يستخدم SQLite ‏BEGIN IMMEDIATE؛ ويستخدم PostgreSQL معاملات serializable وأقفال صفوف. تُلتزم بيانات كائن S3 واستخدام الحصة أو تُرجع في معاملة قاعدة واحدة. يصالح بدء التشغيل الحجوزات المنتهية وكائنات الحصة التي يفتقد كائنها المادي. يضبط BLOB_QUOTA_BYTES_PER_USER الحد الدائم لكل مالك ويحد BLOB_QUOTA_RESERVATION_TTL_MS الحجوزات المتروكة.

يستخدم BLOB_STORE_BACKEND=s3 ‏bucket خاصًا متوافقًا مع S3. يرفع Libre مفاتيح كائنات opaque وتدفقات أجزاء مشفّرة في التطبيق، ويحفظ descriptors المشفّرة في PostgreSQL، ويدعم نطاقات HTTP الشاملة، ويتحقق من SHA-256 للنص الصريح والمشفّر، وينفّذ حذفًا idempotent. يبقى صف الحذف دائمًا حتى ينجح الحذف المادي والإزالة الذرية للبيانات والحصة؛ تعيد المصالحة محاولات الحذف المقطوعة وتزيل الأيتام المادية القديمة. تغطي حزمة MinIO المشروطة بـ Docker القراءة والحذف بين النسخ وعزلة المستأجرين وتنافس الحصص والتدفقات غير المستهلكة وإخفاقات قاعدة البيانات المحقونة عند حدود الالتزام والحذف.

المتجهات المضمّنة المشفّرة​

يتطلب VectorStore فاعلًا في كل استعلام وتغيير. تحمل السجلات namespace ومعرّفًا opaque محدودًا بالمستأجر ومالكًا ومعرّف مورد ونموذج تضمين وأبعادًا وإصدارًا ومراجعة مصدر وسمات مساواة ومنح مستخدم أو مجموعة اختيارية.

يطبق SQLite شروط namespace والنموذج والأبعاد والإصدار والمالك أو المنحة والمورد والسمة قبل مغادرة التضمينات المشفّرة القاعدة. لا يُفك ويُرتب بدرجة cosine إلا ذلك المرشح المحدود والمصرح به. يُعزل معرّف المتجه opaque نفسه لكل مالك من دون كشف وجود مستأجر آخر. تستبدل عمليات upsert التضمينات وACL والسمات ذريًا؛ ويقتصر الحذف على المالك ويتتابع إلى الصفوف ذات الصلة.

تستخدم التضمينات AES-256-GCM مع ربط بيانات الهوية والنموذج كبيانات موثقة إضافية. تبقى الهوية والمنح والنموذج والإصدار والمراجعة وبيانات التصفية القابلة للاستعلام صريحة، لذلك يجب ألا يضع المستدعون أسرارًا في سمات التصفية. التضمينات نفسها بيانات مشتقة حساسة.

يطبق VECTOR_STORE_BACKEND=pgvector شروط namespace والنموذج والأبعاد والإصدار والمورد والسمة والمالك والمنحة داخل عبارة SQL نفسها التي تنفذ ترتيب المسافة وLIMIT. يُحظر post-filter لأقرب الجيران العموميين. يُحل تفويض المجموعة من محلل موثوق للعضوية الحالية في كل استعلام؛ وتُهمل groupIds التي يقدمها المستدعي. وبذلك يسري السحب فورًا ولا تستطيع مطالبات المجموعة المزورة استرجاع مرشحين.

يلتقط استيعاب المستند ونقطة صيانة إعادة توليد التضمينات مواصفة تنفيذ ثابتة قبل بدء العمل: حالة التفعيل والنموذج وإصدار المتجه وإصدار المقسّم وحجم الجزء والتداخل وعتبة التشابه. تتحكم المواصفة نفسها في توليد الأجزاء والنشر العلائقي وupsert للمتجه والاستعلام الدلالي؛ ولا يستطيع تغيير تفضيل أثناء التشغيل إنتاج أجزاء مختلطة النماذج أو الاستعلام بعتبة أخرى. تسجل بيانات المستند المنشورة مراجعة الأجزاء الإجمالية وهذه المواصفة كي يبقى SQL manifest الفهرس الموثوق.

تحمل إعادة التوليد lease تنسيق ذاتي التجديد لكل مستند وتعيد فحص صف المالك وعلامة حذفه الدائم قبل النشر العلائقي وقبل وبعد تغيير المتجه. قد يلتزم حذف أثناء upsert؛ فيزيل فحص السلطة اللاحق المتجهات المعاد إنشاؤها. لا تغيّر قراءات team الدلالية في PostgreSQL ‏PGVector مطلقًا. قد يعيد SQLite نشر التضمينات العلائقية كسولًا فقط عندما يثبت manifest المخزن تطابق النموذج الحالي وضبط الأجزاء بدقة؛ ويعيد التغيير الاختياري تحميل الصف والأجزاء مع حمل lease المستند نفسها. تُتجاوز المراجعة المشغولة أو المتقادمة وتظل مؤهلة لـ fallback الكلمات المفتاحية أو إعادة توليد صريحة.

تُستبدل فهارس المستندات في دفعات معوضة من 1,000 متجه كحد أقصى، وتصفّح فحوص الفهرس الدقيق manifest المورد كاملًا بدل افتراض أن دفعة تغيير واحدة هي المستند كله. يجوز للمستند نشر 100,000 جزء كحد أقصى، فلا يتجاوز أي مستند سقف الأجزاء الإجمالي للأرشيف المحمول. يرفض الاستيعاب الجزء 100,001 قبل التضمين أو النشر العلائقي أو المتجهي، ويضع المهمة الدائمة في dead-letter بلا إعادة محاولة؛ ارفع حجم جزء التضمين أو أزل فواصل الفقرات المفرطة قبل الرفع مجددًا.

قد تحتوي قواعد solo قبل manifest متجهات مستند مضمّنة موثقة بلا سجل للنموذج أو المقسّم الذي أنشأها. تعتبر أول قراءة دلالية وجودها إشارة ترقية فقط: تعيد تقسيم نص المستند الموثوق وتولّد كل متجه مجددًا وفق المواصفة الحالية الملتقطة مع حمل lease المستند. لا تنسخ الحمولة القديمة أو تصفها بتفضيل اليوم. يترك فشل الموفّر أو lease مشغولة الصف القديم كما هو وقابلًا للبحث بالكلمات المفتاحية.

يفشل ترحيل SQLite إلى team مغلقًا عندما لا يغطي metadata manifest الحالي الموثق وفهرس منصة متجهي مشفّر دقيق مستندًا قديمًا كهذا بالكامل. لا تثبت التفضيلات الحالية نموذج متجه تاريخي. عندما تبلغ المحاكاة عن هذا الحاجز، شغّل الإصدار الحالي في وضع solo/SQLite باستخدام DATA_DIR وENCRYPTION_KEY نفسيهما، وفعّل نموذج التضمين المطلوب واختره، واستخدم الإعدادات -> المستندات -> إعادة توليد التضمينات لكل مالك متأثر، ثم أعد محاكاة الترحيل. عندئذٍ فقط يجوز لقراءات مستودع team تجاهل النص المشفّر المضمّن المحفوظ بينما تنتقل المتجهات المثبتة إلى PGVector.

تختلف السرية بحسب الخادم الخلفي. يشفّر SQLite المضمّن التضمينات بـ AES-256-GCM في التطبيق بعد تطبيق شروط ACL للبيانات. يجب أن يعمل PGVector على التضمين الرقمي، لذلك لا يشفّر التطبيق ذلك العمود. تعامل مع التضمينات كبيانات مشتقة حساسة: اطلب TLS ووحدات ونسخ PostgreSQL مشفّرة ودور تطبيق بأقل الصلاحيات وإدارة قاعدة مقيدة وسجلات SQL لا تتضمن متجهًا أو محتوى مصدر. يبقى نص المصدر ومحتوى ذاكرة الشخصية وبيانات المعرض وdescriptors الكائنات مشفّرة في أغلفة. سمات المتجه صريحة وقابلة للاستعلام، ويجب ألا تحتوي أسرارًا.

مفاتيح تشفير التخزين​

أثناء فترة ترحيل المستدعين الحالية، يجب على النشرات التي تفعّل keyring ذا إصدارات ضبط ENCRYPTION_KEY ثابت بطول 64 حرفًا، وتضمين المفتاح نفسه تحت إدخال legacy الدقيق في STORAGE_ENCRYPTION_KEYS، وضبط STORAGE_ENCRYPTION_ACTIVE_KEY_ID على إدخال واحد. تستخدم الكتابات المفتاح النشط، وتقبل القراءات كل معرّفات المفاتيح المضبوطة لدعم التدوير المرحلي. يمنع شرط legacy المؤقت خدمة التشفير القائمة من إنشاء مفتاح مختلف بصورة مستقلة. احتفظ بالمفاتيح القديمة حتى يُعاد كتابة أو لف كل كائن ومتجه والتحقق منه.

عند غياب الخريطة، يقبل المهايئ ENCRYPTION_KEY القائمة ذات 64 حرفًا بمعرّف legacy، أو يقرأ ملف ${DATA_DIR}/.encryption_key القائم عند غياب مفتاح البيئة. لا تقبل factory التخزين إلا ملف مفتاح عاديًا غير رمزي بأذونات خاصة؛ ولا تنشئ الملف أو تعيد كتابته أو تستبدله. إذا تعارض ضبط البيئة الصريح مع المفتاح الدائم، يفشل البدء مغلقًا. أثناء التدوير، يجب أن يبقى مفتاح legacy المكتشف من البيئة أو الملف في الخريطة ذات الإصدارات تحت المعرّف legacy الدقيق حتى تُعاد كتابة الأغلفة القديمة والتحقق منها. تفشل المفاتيح المفقودة أو المشوهة أو غير المطابقة أو المجهولة مغلقة.

تطبق استعلامات المتجهات المضمّنة شروط ACL والبيانات في SQLite، ثم تجمع عدد المرشحين والبايتات المشفّرة وعمل التقييم بحسب الأبعاد قبل إرجاع أي نص مشفّر إلى Node لفكه. تفشل الاستعلامات التي تتجاوز أي ميزانية مغلقة ويجب تضييقها بنطاق المورد أو البيانات.

التنسيق​

يوفّر عقد المنسق أحداثًا وإدخالات cache منتهية وleases مسيّجة واستهلاك حد معدل بنافذة ثابتة. التنفيذ المحلي مخصص لملف solo ذي النسخة الواحدة. يستخدم تنفيذ Redis عملاء أوامر واشتراك منفصلين وحمولات محدودة وفحوص صحة وnamespaces للمفاتيح ونصوصًا ذرية ورموز مالك فريدة وانتهاء lease ورموز fencing. ولا يعود إلى التنسيق المحلي بعد خطأ Redis.

Redis ليس مصدر الحقيقة. يجب أن تبقى صلاحيات الوصول والمهام الدائمة والأحداث القابلة للإعادة في قاعدة البيانات؛ وRedis طبقة تنبيه وإبطال cache وحضور وحصة وتنسيق. كما يجب على العمل الحرج التحقق من lease قاعدة البيانات أو رمز fencing قبل الالتزام بأثر جانبي.

تستخدم تذاكر التطبيق وcache والإبطال المشترك وحدود الاتصال وأحداث Work وأقفال بيئة التشغيل الموزعة هذا الحد. لا يجعل اختيار Redis وحده الاستمرارية المحلية قابلة للمشاركة؛ ويتطلب وضع team الملف المشترك كاملًا.

المهام والأحداث الدائمة​

توفّر هجرة SQLite v3 جداول المهام الدائمة والمحاولات ورأس تدفق الأحداث والأحداث المرتبة. يدعم عقد الخدمة enqueue ‏idempotent وإعادات محدودة وإلغاء وتقدمًا وheartbeat واسترداد lease وحالة dead-letter وإعادة حسب المؤشر العام. تستخدم حمولات JSON المشفّرة keyring المنصة مع هوية المهمة أو الحدث بياناتٍ موثقة؛ ومراجع الحمولة معرّفات opaque محدودة.

تضيف هجرة SQLite v13 وهجرة PostgreSQL v12 الفهرس المطابق (stream_id, subject_id, global_cursor) المستخدم لإعادة المحادثة المحدودة بالتوليد. تُطبق مرشحات التدفق والموضوع قبل حد الاستدراك، فلا تستهلك توليدات جلسة طويلة السابقة ميزانية إعادة التوليد الحالي ولا تفرض مسح تدفق الأحداث كاملًا.

يسجل بدء التطبيق والعامل المستقل معالجات مدققة لاستيعاب المستند ومتابعة الوسائط وتنظيف الموارد القابل للإعادة. يعرض حد الإدارة فحصًا وإلغاء محدودين. يكون enqueue idempotent، وتضيف مسارات الإنشاء والحذف العلائقية مهمتها الدائمة في معاملة SQLite/PostgreSQL نفسها. يزيل تنظيف الموارد المتجهات والكائنات الخاصة والمراجع الدائمة وإدخالات cache والعمل المنتظر الموجه إلى المورد بعمليات آمنة للإعادة.

يعد حصر الاستعادة كل حالة مهمة ونتيجة محاولة، ويسجل تدفقات الأحداث وآخر مؤشر، ويحظر العمل الجاري غير الآمن، ويصادق الحمولات المشفّرة تحت حدود إجمالية. كما يرفض عدم تطابق رأس التدفق والتسلسلات غير المتصلة لكل تدفق.

تسيّج رموز lease الرتيبة العاملين القدماء عن التزامات قاعدة لاحقة. لا يوفر fencing تنفيذًا مرة واحدة بالضبط؛ فقد يكمل العامل أثرًا جانبيًا خارجيًا ويفشل قبل تسجيل النجاح. لذلك يتطلب تبني المعالج مفاتيح idempotency لدى الموفّر أو بروتوكول outbox/inbox معاملاتيًا، وإعادة تحقق من صلاحية الفاعل قبل كل أثر جانبي مباشرةً.

تضيف هجرة SQLite v4 رمز بحث بريد فريدًا ذا مفتاح بجانب نص الهوية المشفّر العشوائي. الرمز HMAC تحت مفتاح تشفير التطبيق؛ ويعيد فرض تفرد البريد ذريًا من دون تخزين النص الصريح أو استخدام تشفير حتمي. يصادق بدء التشغيل كل بريد هوية قديم ويملؤه قبل قبول الحركة.

الصحة والاستعادة​

تميّز فحوص النشر الآن حياة العملية من جاهزية الاعتماديات:

  • /health و/health/live للعملية فقط؛
  • يفحص /health/ready قاعدة البيانات وسجل schema القياسي وقابلية كتابة تخزين البيانات والاعتماديات المطلوبة المسجلة مع حجب التفاصيل. ولا ينتظر الموفّرين الاختياريين؛ و
  • يتطلب /health/deep مسؤولًا حاليًا ويشغّل فحوص سلامة SQLite والمفاتيح الأجنبية في عامل محدود خارج حلقة HTTP. كما يجمع فحوص الموفّرين الاختيارية على مستوى الخادم، مثل Ollama، كتحذيرات من دون تغيير الجاهزية الأساسية.

شغّل libre-webui recovery-check --json؛ ومن نسخة المصدر ابنِ الخادم الخلفي مرة واستخدم npm run recovery:check -- --json. الحصر للقراءة فقط ويبلغ عن هويات schema والمفتاح وجذر الكائنات المحلية وأعداد المتجهات القديمة ومتجهات المنصة، ويصادق نص كائنات ومتجهات المنصة المحلية المشفّر ونص التطبيق القديم والأصوات المحفوظة وحمولات المهام والأحداث الدائمة المشفّرة، ويبلغ عن أحجام البيانات وتعريفات المكوّنات وهل تقع في جذر النسخ والوسائط المضمّنة وموارد Work وتصنيفات ملكيتها الدقيقة ونقاط المهام والمحاولات والأحداث وعمليات Work والمعاينات والمهام النشطة والحواجز والاستثناءات المعروفة. هذه بوابة قبل النسخ وليست نسخة كاملة. راجع الاستعداد للاستعادة.

التشغيل المعتمد متعدد النسخ​

ملف team معتمد لثلاث نسخ تطبيق أو أكثر وعامل دائم خارجي واحد على الأقل، بشرط ضبط كل الاعتماديات المشتركة معًا: PostgreSQL وPGVector وRedis وكائنات متوافقة مع S3 وأسرار مشتركة ثابتة وJOB_WORKER_MODE=external. يفرض chart Helm هذه المتطلبات وقت render؛ ويفشل عدد نسخ أكبر من واحد بلا ملف team الكامل بدل نشر بنية غير آمنة. وتنتخب هجرات schema قائدًا واحدًا عبر قفل advisory في PostgreSQL حتى لا تتسابق نسخ مختلفة الإصدارات على السجل.

الاعتماد قابل للتنفيذ لا أمنيّة: يشغّل خط الإصدار تمرينًا بثلاث نسخ (npm run test:team-platform) يبني الصورة الحقيقية ويختبر استئناف التدفق بين النسخ وموت عامل أثناء الكتابة مع إعادة حتمية وعودة تعطل Redis إلى SQL الموثوق وإنفاذ السحب أثناء فقد المنسق واتساق حد المعدل المشترك وإعادة حذف S3 وعزلة المستأجر تحت الحمل. يمكن للمشغّلين تشديد pods أكثر باستخدام secrets.existingSecret (الإشارة إلى Secret يديره المشغّل بدل render قيم chart في واحد) وnetworkPolicy.enabled (رفض افتراضي للدخول عدا منفذ التطبيق؛ لا يقبل العامل الدائم دخولًا). تبقى إعدادات أمان pod صارمة في كلتا الحالتين: مستخدم غير root ونظام ملفات جذري للقراءة فقط وقدرات مسقطة وseccomp ‏RuntimeDefault ومنع رفع الصلاحيات.

عمليات الانتقال المعروفة المتبقية​

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

يجب أن تسجل الآثار الجانبية الطويلة أو الظاهرة خارجيًا الجديدة هدف مورد دائمًا، وتدعم الإلغاء والإعادة، وتستخدم حد enqueue/outbox معاملاتيًا مع التغيير العلائقي المالك. أضف كل مورد جديد إلى بوابات قبول الرفع والقراءة والبحث والحذف والنسخ والاستعادة بين النسخ قبل تفعيله في نشر team.