NetworkTheoryAppliedResearchInstitute · Oct 6, 2026
diff --git a/CONFORMANCE.ar.md b/CONFORMANCE.ar.md
@@ -0,0 +1,56 @@
+> ترجمة مجتمعية (مسوّدة) — سياسة NTARI رقم P2-002، البث العالمي المتعدد اللغات. المصدر: CONFORMANCE.md (الأصل الإنجليزي، لقطة بتاريخ 2026-10-05). مسوّدة مجتمعية بمساعدة آلية، في انتظار مراجعة المشرف الإقليمي وفق §3.1 من P2-002. تبقى المواصفات التقنية الأساسية بالإنجليزية وفق §2.2.
+>
+> تصحيحات الترجمة مساهمات نرحّب بها ونقدّرها كسائر المساهمات، فإذا لاحظت خطأً
+> في هذه الترجمة فيمكنك إصلاحه بنفسك عبر إنشاء fork للمستودع وفتح pull
+> request: https://github.com/NTARI-RAND/sohocloud-protocol
+
+> **الأصل الإنجليزي هو النص المعياري.** هذه الترجمة مقدَّمة للقراءة لا للتفسير: فحيثما اختلفت عن `CONFORMANCE.md`، يكون الحكم للنص الإنجليزي. وتبقى الكلمات المفتاحية المعيارية (MUST، MUST NOT، SHOULD، SHOULD NOT، MAY) وأسماء الحقول والوسوم والمعرّفات بالإنجليزية، لأنها هي عقد المطابقة.
+
+# المطابقة — العمارة ذات الوجهين (Janus-Facing Architecture)
+
+هذه الوثيقة هي الوصف الذاتي لهذه الوحدة بمصطلحات العمارة نفسها، مُقرَّرًا **قبل** أي شيء خاص بمنتج أو بنشر، وفقًا لقاعدة الترتيب في العمارة. وهي تتبع انضباط المقروئية في العمارة: فادّعاء المطابقة إمّا أن يكون مربوطًا بالآلية وبالفحص الذي يفرضها، وإمّا أن يُوسَم بأنه بديل مؤقت. والنثر غير المربوط تسويق.
+
+العمارة هي **العمارة ذات الوجهين (Janus-Facing Architecture, JFA)** — وثيقة العمارة الموحّدة لدى NTARI، وهي توثيق حرّ ضمن مشاع المشروع وفق رخصة AGPL-3.0. وهي تُسمّي الأدوار والآليات، ولا تُسمّي المنتجات أبدًا؛ وهذه الوحدة تُعلن الدور الذي تشغله وتعرض روابطها.
+
+## إعلان الدور
+
+هذه الوحدة هي **بروتوكول التنسيق** لـ**ركيزة** (substrate) في JFA: لغة خط الاتصال (wire) الطرفية في شجرة الاعتماديات (dependency-leaf)، التي يُتعرَّف بها على الأجهزة المملوكة للمشاركين، وتُعلن بها هذه الأجهزة عن قدرتها، وتتسلّم بها العمل وتُبلغ عنه. وضمان الركيزة الذي تخدمه: **التنسيق على بنية تحتية يستطيع المشاركون امتلاكها — بلا نقطة اختناق في الاستضافة لا يمكن إزالتها.**
+
+| مصطلح هذه الوحدة | الدور في العمارة |
+|---|---|
+| Node | بنية تحتية مملوكة للمشاركين — الأجهزة التي يساهم بها الأعضاء |
+| Coordinator | المنسّق: التنسيق (orchestration) من جهة العقدة، وهو دور قابل للاستبدال (pluggable) |
+| Frontend | واجهة أمامية: التطبيق الموجَّه للأعضاء |
+| FeeDeclaration | إعلان الرسوم الذي يحرّره المنسّق، المقروء والقابل للطعن |
+| JobReport | ادّعاء عمل (الترسية المشهودة محجوزة — انظر البدائل المؤقتة) |
+
+## الثوابت وروابطها
+
+| الثابت (في العمارة) | الآلية هنا | الفحص |
+|---|---|---|
+| بروتوكول التنسيق **طرفٌ في شجرة الاعتماديات (dependency leaf)** | يُعلن `go.mod` عدم وجود أي متطلبات؛ المكتبة القياسية فقط | CI: يُفشل `.github/workflows/dependency-leaf.yml` البناء عند إضافة أي اعتمادية |
+| **لا يظهر الأشخاص أبدًا على خط الاتصال** | الهوية الوحيدة التي تعرفها هذه الوحدة هي هوية عبء العمل (workload identity) — NodeID في `identity/` مع ربطه القانوني (canonical) بـ SPIFFE؛ ولا تحمل أي رسالة اسمًا، ولا وسيلة اتصال، ولا حقلًا على هيئة شخص | SPEC (معياري)؛ سطح الأنواع؛ المتجهات الذهبية (golden vectors) |
+| **لا نقطة اختناق في الاستضافة لا يمكن إزالتها** | المنسّق دور قابل للاستبدال: الواجهة الأمامية MAY أن تشغّل منسّقها الخاص أو أن تطابق مباشرةً مع العقد (SPEC §1) | النص المعياري في SPEC؛ يوجد مستهلكان يعملان مقابل الوسم المنشور |
+| **مقروئية الرسوم** | لا توجد الرسوم على خط الاتصال إلا في صورة `FeeDeclaration` يوقّعه المنسّق — محرَّر، ومقروء، وقابل للطعن | `fees/`؛ المتجهات الذهبية |
+| **المقروئية مُخرَجٌ، لا تعليق** | `SPEC.md` معياري، وهو من مُخرَجات البناء: يبني منه المنفِّذ الخارجي دون قراءة هذا المصدر | `testdata/vectors.json` (الحقيقة المرجعية) + `testdata/reproduce_spec.py` (مُعيد إنتاج مستقل) + اختبار `vectors/` الذهبي — أي انحراف بين الشيفرة والمتجهات المُودَعة يُفشل البناء |
+| **ترميز قانوني (canonical) وحتمي** | `canon/` مُرمِّز توقيع مسبوق بالطول ومفصول بالنطاق (domain-separated) | يُعاد توليد المتجهات الذهبية وتُقارَن بايتًا ببايت في كل تشغيل للاختبارات |
+
+## خارج النطاق عمدًا
+
+هذه الوحدة **ليست** اقتصاد الأعضاء، وهذا الغياب ثابتٌ لا فجوة: لا ضمان (escrow)، ولا ائتمان يصدره الأعضاء، ولا عهد للسمعة، ولا سجل مختوم بالحوار، ولا فصل في النزاعات. فهذه كلها تنتمي إلى الطبقات الأعلى (السجل، والعهد، والاقتصاد)، وتعيش في الواجهات الأمامية، وMUST NOT أن تنتقل إلى هذا الطرف. وكذلك فإن تفرّد هوية المشارك (single-participant-identity) التزامٌ يقع على الواجهة الأمامية — فهذه الطبقة لا تعرف أي أشخاص على الإطلاق.
+
+## البدائل المؤقتة والمتبقّيات المفتوحة
+
+نُسمّيها وفقًا لقاعدة الصدق في العمارة: فالمثال التطبيقي الذي يُخفي مواضع قصوره لن يُعلّم إلا الإخفاء.
+
+- **`anchor/` هيكل أولي (stub)، وموسوم بذلك في توثيق الحزمة.** الترسية المشهودة، التي لا تقبل إلا الإضافة، لادّعاءات التشغيل (المهمة داخلة، والنتيجة خارجة، والعدّاد) محجوزة، وغير مبنية. وإلى أن توجد، يبقى حساب المنسّق للعمل المنجَز إقرارًا ذاتيًا — وهذه هي المسألة المفتوحة 6 في العمارة، المقترنة بالمسألة المفتوحة 2.
+- **v0 غير مستقر (UNSTABLE).** قد تتغيّر أشكال الرسائل على خط الاتصال دون ضمانات توافق حتى v1؛ ويثبّت المستهلكون الوسوم المنشورة.
+- **الحوسبة السيادية تشتري مغادرةً آلية، لا اقتصادية** (المسألة المفتوحة 7). يحدّ هذا البروتوكول من مدى التركّز الذي يمكن أن تبلغه الاستضافة؛ لكنه لا يستطيع تمويل مغادرة أحد. مُسمّاة، غير محلولة.
+
+## إعلان الاعتماديات
+
+يعتمد على: المكتبة القياسية للغة Go. ولا شيء غيرها — لا وحدة أخرى من NTARI، ولا وحدة من طرف ثالث، ولا شيء فوق هذه الوحدة أو بجانبها في المكدّس. ويجعل فحص CI أي مخالفةٍ بناءً فاشلًا، بدلًا من أن تكون شيئًا يُلتقط في المراجعة.
+
+## ملاحظات خاصة بالمنتجات (في الأخير، وفقًا لقاعدة الترتيب)
+
+SoHoLINK هو المنسّق المرجعي؛ وCloudy واجهة أمامية مرجعية. وكلاهما يستهلك هذه الوحدة عبر وسم الإصدار المنشور. ولا يُميّز البروتوكول أيًّا منهما: إذ يمكن لأي تنفيذ مطابق أن يحلّ محلّ أيٍّ منهما.
diff --git a/CONFORMANCE.es.md b/CONFORMANCE.es.md
@@ -0,0 +1,56 @@
+> Traducción comunitaria (borrador) — Política P2-002 de NTARI, Difusión Multilingüe Global. Fuente: CONFORMANCE.md (original en inglés, instantánea del 2026-10-05). Borrador comunitario asistido por máquina, pendiente de revisión por mantenedores regionales conforme a P2-002 §3.1. Las especificaciones técnicas centrales permanecen en inglés conforme a §2.2.
+>
+> ¿Encontraste un error en esta traducción? Tu corrección es una contribución
+> bienvenida y valorada: haz un fork del repositorio y abre un pull request en
+> https://github.com/NTARI-RAND/sohocloud-protocol.
+
+> **El original en inglés es normativo.** Esta traducción se ofrece para lectura, no para interpretación: donde difiera de `CONFORMANCE.md`, rige el inglés. Las palabras clave normativas (MUST, MUST NOT, SHOULD, SHOULD NOT, MAY), los nombres de campos, las etiquetas y los identificadores se mantienen en inglés porque constituyen el contrato de conformidad.
+
+# Conformidad — Janus-Facing Architecture
+
+Este documento es la autodescripción del módulo en los propios términos de la arquitectura, expuesta **antes** de cualquier cosa específica del producto o del despliegue, según la regla de orden de la arquitectura. Sigue la disciplina de legibilidad de la arquitectura: una afirmación de conformidad está vinculada al mecanismo y a la verificación que la hacen cumplir, o se etiqueta como suplencia. La prosa no vinculada es marketing.
+
+La arquitectura es **Janus-Facing Architecture (JFA)**: el documento de arquitectura unificada de NTARI, documentación libre bajo el bien común AGPL-3.0 del proyecto. Nombra roles y mecanismos, nunca productos; este módulo declara qué rol ocupa y muestra sus vínculos.
+
+## Declaración de rol
+
+Este módulo es el **protocolo de coordinación** de un **sustrato** de JFA: el lenguaje de transmisión, hoja de dependencias, mediante el cual las máquinas propiedad de los participantes son reconocidas, anuncian su capacidad, y toman e informan trabajo. La garantía del sustrato a la que sirve: **coordinación sobre infraestructura que los participantes pueden poseer — sin un punto de estrangulamiento de alojamiento imposible de eliminar.**
+
+| Término de este módulo | Rol en la arquitectura |
+|---|---|
+| Node | infraestructura propiedad de los participantes — las máquinas que aportan los miembros |
+| Coordinator | el coordinador: orquestación del lado de los nodos, un rol intercambiable |
+| Frontend | un frontend: la aplicación de cara a los miembros |
+| FeeDeclaration | la declaración de tarifas del coordinador, de su autoría, legible e impugnable |
+| JobReport | una afirmación de trabajo (anclaje atestiguado reservado — véanse las suplencias) |
+
+## Invariantes y sus vínculos
+
+| Invariante (arquitectura) | Mecanismo aquí | Verificación |
+|---|---|---|
+| El protocolo de coordinación es una **hoja de dependencias** | `go.mod` declara cero requisitos; solo biblioteca estándar | CI: `.github/workflows/dependency-leaf.yml` hace fallar la compilación ante cualquier dependencia añadida |
+| **Las personas nunca aparecen en la transmisión** | La única identidad que este módulo conoce es la identidad de carga de trabajo — el NodeID de `identity/` con su vinculación SPIFFE canónica; ningún mensaje lleva un nombre, un contacto ni un campo con forma de persona | SPEC (normativo); la superficie de tipos; vectores de referencia |
+| **Sin punto de estrangulamiento de alojamiento imposible de eliminar** | El coordinador es un rol intercambiable: un frontend MAY ejecutar su propio coordinador o emparejar directamente con los nodos (SPEC §1) | Texto normativo de SPEC; existen dos consumidores contra la etiqueta publicada |
+| **Legibilidad de las tarifas** | Las tarifas existen en la transmisión solo como una `FeeDeclaration` firmada por el coordinador — de su autoría, legible, impugnable | `fees/`; vectores de referencia |
+| **La legibilidad es un producto, no un comentario** | `SPEC.md` es normativo y un entregable de la compilación: un implementador externo construye a partir de él sin leer este código fuente | `testdata/vectors.json` (verdad de referencia) + `testdata/reproduce_spec.py` (reproductor independiente) + prueba de referencia de `vectors/` — cualquier divergencia entre el código y los vectores confirmados hace fallar la compilación |
+| **Codificación canónica y determinista** | Codificador de firma de `canon/` con prefijo de longitud y separación por dominio | vectores de referencia regenerados y comparados byte a byte en cada ejecución de pruebas |
+
+## Deliberadamente fuera de alcance
+
+Este módulo **no** es la economía de miembros, y esa ausencia es un invariante, no una carencia: sin depósito de garantía (escrow), sin crédito emitido por los miembros, sin pacto de reputación, sin registro sellado por diálogo, sin adjudicación de disputas. Esas funciones pertenecen a las capas superiores (registro, pacto, economía), viven en los frontends y MUST NOT migrar a esta hoja. La identidad única de participante es igualmente una obligación de los frontends — esta capa no conoce personas en absoluto.
+
+## Suplencias y residuos abiertos
+
+Nombrados según la regla de honestidad de la arquitectura: un ejemplo práctico que ocultara dónde se queda corto solo enseñaría a ocultar.
+
+- **`anchor/` es un stub, etiquetado como tal en la documentación de su paquete.** El anclaje atestiguado y de solo adición de las afirmaciones de empleo (trabajo que entra, resultado que sale, medición) está reservado, no construido. Hasta que exista, el relato de un coordinador sobre el trabajo completado es autoatestiguado — el problema abierto 6 de la arquitectura, acoplado al problema abierto 2.
+- **v0 es UNSTABLE.** Las formas de transmisión pueden cambiar sin garantías de compatibilidad hasta v1; los consumidores fijan etiquetas publicadas.
+- **El cómputo soberano compra una salida mecánica, no económica** (problema abierto 7). Este protocolo limita cuán concentrado puede llegar a estar el alojamiento; no puede financiar la salida de nadie. Nombrado, no resuelto.
+
+## Declaración de dependencias
+
+Depende de: la biblioteca estándar de Go. Nada más — ningún otro módulo de NTARI, ningún módulo de terceros, nada por encima ni al lado de él en la pila. La verificación de CI convierte una infracción en una compilación fallida en lugar de algo que se detecta en una revisión.
+
+## Notas específicas del producto (al final, según la regla de orden)
+
+SoHoLINK es el coordinador de referencia; Cloudy es un frontend de referencia. Ambos consumen este módulo mediante una etiqueta de versión publicada. Ninguno de los dos es privilegiado por el protocolo: cualquier implementación conforme puede reemplazar a cualquiera de ellos.