From 99ae1a54428e207bcfe633981595bcae7142230b Mon Sep 17 00:00:00 2001
From: Jodson Graves <info@ntari.org>
Date: Tue, 11 Aug 2026 10:25:33 -0400
Subject: [PATCH] Add P2-002 community translation drafts (7 languages)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Machine-assisted community translation drafts per NTARI Policy P2-002,
pending regional maintainer review; source snapshot 2026-07-29. The
English root remains the sole source of truth (P2-002 §2.2).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Jodson Graves <info@ntari.org>
---
 README.ar.md  | 156 ++++++++++++++++++++++++++++++++++++++++
 README.es.md  | 189 ++++++++++++++++++++++++++++++++++++++++++++++++
 README.fr.md  | 196 ++++++++++++++++++++++++++++++++++++++++++++++++++
 README.hi.md  | 177 +++++++++++++++++++++++++++++++++++++++++++++
 README.pt.md  | 179 +++++++++++++++++++++++++++++++++++++++++++++
 README.tok.md |  68 ++++++++++++++++++
 README.zh.md  | 147 +++++++++++++++++++++++++++++++++++++
 7 files changed, 1112 insertions(+)
 create mode 100644 README.ar.md
 create mode 100644 README.es.md
 create mode 100644 README.fr.md
 create mode 100644 README.hi.md
 create mode 100644 README.pt.md
 create mode 100644 README.tok.md
 create mode 100644 README.zh.md

diff --git a/README.ar.md b/README.ar.md
new file mode 100644
index 0000000..fe83b37
--- /dev/null
+++ b/README.ar.md
@@ -0,0 +1,156 @@
+> ترجمة مجتمعية (مسوّدة) — سياسة NTARI رقم P2-002، البثّ العالمي المتعدد اللغات. المصدر: README.md (الأصل الإنجليزي، لقطة بتاريخ 2026-07-29). مسوّدة مجتمعية بمساعدة آلية، في انتظار مراجعة مشرف الصيانة الإقليمي وفق P2-002 §3.1. تبقى المواصفات التقنية الأساسية بالإنجليزية وفق §2.2.
+>
+> تصحيحات الترجمة مساهمات نرحّب بها ونقدّرها كسائر المساهمات، فإذا لاحظت خطأً
+> في هذه الترجمة فيمكنك إصلاحه بنفسك عبر إنشاء fork للمستودع وفتح pull
+> request: https://github.com/NTARI-RAND/Cloudy
+
+# Cloudy
+
+واجهة أمامية على شبكة التنسيق SoHoLINK / sohocloud. Cloudy هو المكان الذي
+يتبادل فيه الأعضاء؛ وهو يستهلك تنسيق الركيزة (substrate) عبر الوحدة المشتركة
+`sohocloud-protocol`، ويملك فوقها اقتصاد أعضاء JFA الخاص به.
+
+## الحالة (بصدق)
+
+طبقات اقتصاد أعضاء JFA الثلاث التي يملكها Cloudy — والتي لا يملكها البروتوكول
+عن قصد — أصبحت الآن **مبنية، ومعها اختبارات**. ولا تزال لا توجد حلقة تنسيق حيّة
+ولا أي سطح مواجه للأعضاء.
+
+- **`internal/record` — مبنية.** سجل مختوم بالحوار، لا يقبل إلا الإضافة،
+  ومُشهَد عليه: كل Entry يحمل ختمَي الطرفين على بايتات قانونية (canonical)
+  مفصولة النطاق، بحيث لا يمكن أبدًا أن يدخل السجل عهدٌ نصف مختوم أو مُبرَم مع
+  الذات؛ والسجلات المتسلسلة بالهاش لكل مُشغِّل تُعاد التحقق منها كاملةً عند
+  `OpenLog`؛ ونقاط تحقّق المُشغِّل مع التوقيعات المضادة من شهود مستقلين تجعل أي
+  إعادة كتابة للتاريخ المُثبَّت بنقاط تحقّق قابلةً للكشف تشفيريًا (التحليل على
+  نمط CT)، أمّا النشر بشاهد واحد فيُوصف صراحةً بأنه البديل المؤقت الذي هو عليه.
+  لا يوجد أي شكل لمعلومات التعريف الشخصية (PII) في المشاعات — فالمحتوى المُعرِّف
+  للهوية يقيم فقط في الـ Locker المحلي للعضو والقابل للمحو. و`Entry.ID()`، أي
+  هاش الورقة، هو المرجع الوحيد للتبادل بين الطبقات.
+- **`internal/economy` — مبنية.** ائتمان متبادل سيادي لكل منصة: يُصدَر الائتمان
+  في لحظة الإنفاق، داخل سقف مدين واحد موحّد ومحكوم، ومجموع كل الأرصدة يساوي
+  صفرًا دائمًا وبالضبط. لا يمكن تمثيل أي سكّ للعملة، ولا حقل للعملة الورقية
+  (fiat)، ولا استرداد، ولا حقل ملاحظة؛ والانتقال من الضمان-الآن إلى
+  الائتمان-لاحقًا هو بالضبط عملية PolicyChange واحدة موقَّعة بنصاب على المخزن
+  نفسه الذي لا يقبل إلا الإضافة؛ و`Open` يعيد تشغيل كل سجل ويعيد التحقق منه
+  بالكامل. و`Spend.ExchangeHash` يحمل معرّف ورقة مدخل السجل، لكنه معتم عن قصد
+  وغير مُتحقَّق منه عند Post — فالتثبيت شأن يخصّ جذر التركيب.
+- **`internal/covenant` — مبنية.** السمعة على مقياس NTARI لتقييم التبادل المبني
+  على ليفيسون (Leveson-Based Trade Assessment Scale، أو LBTAS): ستة مستويات
+  محمّلة بالمعنى، من -1 «لا ثقة» (No Trust) إلى +4 «إسعاد» (Delight)، ثنائية
+  الاتجاه (كلا طرفَي التبادل المختوم يقيّم الآخر)، تُعرَض لكل فئة على مفردات
+  مغلقة (الافتراضية: الموثوقية، وقابلية الاستخدام، والأداء، والدعم)، ولا تُقرأ
+  إلا كتوزيعات كاملة للعدد في كل مستوى — لكل فئة، ومجمّعة إجماليًا، مع عدّاد ضرر
+  يُظهر كل -1 — **ولا تُحسَب متوسطاتها أبدًا**، بلا أي نتيجة رقمية، ولا تصدير،
+  ولا تعديل، ولا تراجع، ولا مقارنة بين الأعضاء في أي مكان (اختباران كاشفان —
+  مسحٌ لمجموعة الدوال عبر reflection، ومسحٌ للدوال المُصدَّرة عبر go/ast —
+  يحافظان على ذلك). ويستلزم الحكم بـ -1 تعليقًا مُبرِّرًا؛ ونصّ التعليق يقيم في
+  الـ Locker المحلي للعضو والقابل للمحو، بينما لا يسافر في المشاعات إلا هاشه. كل
+  تقييم موقَّع من المُقيِّم ومُسعَّر بتبادل مختوم واحد عبر بوابة Anchors؛
+  ومعرّفات الأعضاء هي هاشات مفاتيح محدودة النطاق بالمنصة، والمعرّفات التي
+  يختارها البشر مرفوضة رفضًا تامًا. وتقيم المواصفة المُلزِمة والتنفيذ المرجعي في
+  `Development/Covenant/Leveson-Based-Trade-Assessment-Scale`.
+- **قائم لكنه رقيق:** `internal/coord` — عميل رقيق فوق نقل HTTP+JSON المرجعي
+  الخاص بالبروتوكول، يثبت أن Cloudy يستهلك `sohocloud-protocol`. و`cmd/cloudy`
+  يبنيه ويُبلِّغ عن بدء التشغيل؛ ولا توجد بعد أي حلقة تنسيق حيّة.
+
+يبني `cmd/cloudy` الآن الطبقات الثلاث كلها في الذاكرة عند بدء التشغيل (نشأة
+ModeEscrow، وسجل مُشغِّل فارغ، ودفتر عهود فارغ فوق دليل أعضاء مشترك فارغ)،
+ويسجّل سطرًا صادقًا واحدًا لكل طبقة. وكل حزمة تسمّي ثوابتها غير القابلة للتفاوض
+في توثيق الحزمة الخاص بها.
+
+## ما يملكه Cloudy (البنية المعمارية)
+
+في ظل البنية المعمارية المستقرّة، يملك Cloudy — الواجهة الأمامية — عالم العضو
+بأكمله. ثلاث قدرات، ومالك واحد:
+
+- **اقتصاد أعضاء JFA — مبني.** `internal/economy` (ائتمان يُصدره الأعضاء)،
+  و`internal/covenant` (سمعة LBTAS)، و`internal/record` (سجل مختوم بالحوار)،
+  بالضبط كما وُثِّق أعلاه. هذه ملكٌ لـ Cloudy وليست للبروتوكول عن قصد: فالأشخاص
+  لا يظهرون أبدًا على الشبكة.
+- **وكيل العقدة — يملكه Cloudy، ويستضيفه حاليًا مستودع المنسّق في انتظار
+  الترحيل.** كشف العتاد، وملفّات الموارد، وتوليد قوائم القدرات، ونبضة الحياة
+  (heartbeat)، ومُنفِّذ المهام، وفرض الانسحاب/قوائم السماح محليًا، والقياس
+  البعدي (telemetry)، ومُثبِّت جهاز العضو. هذا الكود (`internal/agent`
+  و`cmd/agent` ومُثبِّت MSI) يقيم اليوم في مستودع SoHoLINK ويظل يعمل هناك — وهو
+  من مخلّفات العهد الذي كان فيه SoHoLINK واجهةً أمامية ومنسّقًا في الوقت نفسه،
+  لا من دور SoHoLINK على المدى الطويل. الوكيل هو حضور العضو على جهازه الخاص،
+  ولذلك ينتمي إلى الواجهة الأمامية؛ فالمنسّق الذي يشحن وكلاء إلى عتاد الأعضاء هو
+  منسّق يلمس عتاد الأعضاء، وهو ما يجب ألّا يفعله SoHoLINK أبدًا.
+- **بوّابة الأعضاء — يملكها Cloudy، ويستضيفها حاليًا مستودع المنسّق في انتظار
+  الترحيل.** التسجيل، وتسجيل الدخول، ولوحة المعلومات، وإرسال المهام، والانسحاب.
+  السطح الذي كان يُسمّى سابقًا «بوّابة المشاركين» (`internal/portal`
+  و`cmd/portal` و`web/` في مستودع SoHoLINK) هو من الآن فصاعدًا بوّابة أعضاء
+  تابعة لـ Cloudy — فهوية العضو شأن يخصّ الواجهة الأمامية، ولذلك يجب أن يكون
+  البابُ الذي يعبره الأعضاء هو باب الواجهة الأمامية.
+
+وكيل العقدة وبوّابة الأعضاء هما معلَما البناء التاليان، بعد أن أصبحت الطبقات
+الثلاث مكتملةً كمكتبات. وكما تقول الحالة أعلاه بصدق: لا مدخل هنا بعد لأي منهما،
+ولا شيء في هذا المستودع يتظاهر بأن الترحيل قد حدث فعلًا.
+
+### مسرد المصطلحات
+
+- **العضو (Member)** — شخص، دائمًا بالنسبة إلى واجهة أمامية/منصة. الهوية
+  (MemberID محدود النطاق بالمنصة)، والائتمان، والمكانة على LBTAS، والسجلات
+  المختومة، ومعلومات التعريف الشخصية (PII) (قابلة للمحو، ومحلية للعضو)، والأجهزة
+  المُساهَم بها — كلها وقائع عضوية. والعضوية لغةُ عهد — التزام متبادل تجاه منصة
+  معيّنة؛ فالإنسان نفسه يكون عضوًا مختلفًا على كل منصة بالبناء التشفيري.
+- **المشارك (Participant)** — دور، لا كِيان: عضو يعمل داخل الاقتصاد المنسَّق،
+  مساهمًا بعُقَد و/أو مُرسِلًا مهامًا — هوية موحّدة واحدة، لا تُقسَّم أبدًا إلى
+  مُنتِج ومُستهلِك. أمّا سجلات الأشخاص على جانب المنسّق (جدول participants في
+  SoHoLINK وحسابات البوّابة) فهي أسطح انتقالية من العهد المزدوج.
+- **العقدة (Node)** — جهاز يساهم به عضو، يُعرَّف بـ NodeID مع ربط SPIFFE
+  `/node/<id>` (حزمة `identity/` الخاصة بالبروتوكول).
+
+### الهوية تجاه المنسّق
+
+هويّتان تعبران الحدّ بين الواجهة الأمامية والمنسّق، ويجب ألّا تُخلطا. أجهزة
+الأعضاء تحمل **هوية حِمل العمل** (workload identity): شهادة SPIFFE SVID تحت
+`/node/<id>`، مُصرَّح بها على جانب المنسّق بما يطابق تمامًا SPEC البروتوكول —
+هوية آلة، بلا تغيير. أمّا Cloudy نفسه فيستوثق بوصفه **مُشغِّلًا** مُسجَّلًا:
+نموذج «الواجهة الأمامية كمُشغِّل»، وهو **هدف تصميمي** مصوغ على نمط مخطط
+المُشغِّلين في المرحلة 5 من Agrinet (سجل operators + operator-keys؛ ومجموعة
+مفاتيح Ed25519 دوّارة من سبعة مفاتيح، كل إرسال موقَّع باثنين منها؛ وإعادة
+الإرسال (replay) مقيَّدة بنافذة زمنية إضافةً إلى مخزن nonce — انظر
+`Development/Economy/Agrinet backend/lib/operatorKeys.js` و
+`backend/middleware/operatorAuth.js`). التدوير هو المقصود: فالمفتاح المشترك
+الثابت الذي لا يُدوَّر أبدًا هو بالضبط النمط المضاد الذي يحذّر المرجع من توريثه.
+ولا تكون أيٌّ من الهويّتين شخصًا أبدًا: فهوية العضو تبقى داخل Cloudy.
+
+## ثابت مخطَّط الاستيراد
+
+يستورد Cloudy الوحدة `sohocloud-protocol`؛ و**لا شيء يستورد Cloudy**. يعتمد
+Cloudy على نواة البروتوكول وعلى نقله المرجعي، ولا يتجاوز أيًّا منهما. اتجاه
+التبعية هو ما يُبقي الواجهة الأمامية والمنسّق قابلين للفصل: فيمكن استبدال واجهة
+أمامية دون المساس بالركيزة، والركيزة لا تعرف شيئًا عن أي واجهة أمامية بعينها.
+
+وداخل Cloudy، لا تستورد حزم JFA الثلاث بعضها بعضًا أبدًا؛ فكل واحدة لا ترى إلا
+المكتبة القياسية وحزمة `canon` الخاصة بالبروتوكول، وكل الاستيرادات تبقى أحادية
+الاتجاه. وهي لا تتلاقى إلا عند جذر التركيب: `test/composition` هو اختبار جذر
+التركيب الوحيد — وفيه يقيم دليل الأعضاء المشترك الواحد، ومُسند Anchors الذي يصل
+العهد بالسجل عبر `Entry.ID()`، وقصة العضو الكاملة — و`cmd/cloudy` ينفّذ التركيب
+نفسه عند بدء التشغيل.
+
+## البناء
+
+وحدة البروتوكول خاصة وغير موسومة حاليًا. وهذا الهيكل يحلّها عبر توجيه `replace`
+يشير إلى **نسخة محلية مجاورة**:
+
+```
+replace github.com/NTARI-RAND/sohocloud-protocol => ../sohocloud-protocol
+```
+
+لذلك يجب استنساخ `sohocloud-protocol` بجانب `Cloudy` (كلاهما تحت المجلد الأب
+نفسه). وهذا الـ `replace` تسهيلٌ للتطوير المحلي — وهو غير قابل للبناء من قِبَل
+الآخرين كما هو. وسيتطلب نشر Cloudy للبناء الخارجي وسمَ وحدة البروتوكول (أو إعداد
+`GOPRIVATE` مع جلب موثَّق) وإسقاط الـ `replace`.
+
+```
+go build ./...
+go test ./...
+```
+
+## الترخيص
+
+AGPL-3.0-or-later.
+
+*Network Theory Applied Research Institute, Inc. — 501(c)(3) — EIN 92-3047136 — info@ntari.org*
diff --git a/README.es.md b/README.es.md
new file mode 100644
index 0000000..18ae757
--- /dev/null
+++ b/README.es.md
@@ -0,0 +1,189 @@
+> Traducción comunitaria (borrador) — Política P2-002 de NTARI, Difusión Multilingüe Global. Fuente: README.md (original en inglés, instantánea del 2026-07-29). Borrador comunitario asistido por máquina, pendiente de revisión por el mantenedor regional según P2-002 §3.1. Las especificaciones técnicas centrales permanecen en inglés según §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/Cloudy.
+
+# Cloudy
+
+Un frontend sobre la red de coordinación SoHoLINK / sohocloud. Cloudy es donde
+los miembros realizan transacciones; consume la coordinación del sustrato a
+través del módulo compartido `sohocloud-protocol` y posee, por encima, su
+propia economía de miembros JFA.
+
+## Estado (honesto)
+
+Las tres capas de la economía de miembros JFA que Cloudy posee —y que el
+protocolo deliberadamente no posee— ya están **construidas, con pruebas**.
+Todavía no hay un bucle de coordinación en vivo ni una superficie orientada a
+los miembros.
+
+- **`internal/record` — construido.** Registro sellado por diálogo, de solo
+  anexado (append-only) y atestiguado: cada Entry lleva los sellos de ambos
+  miembros sobre bytes canónicos con separación de dominio, de modo que un
+  convenio sellado a medias o autonegociado nunca puede entrar en un log; los
+  logs por operador encadenados por hash se reverifican por completo en
+  `OpenLog`; los checkpoints del operador, más las contrafirmas de testigos
+  independientes, hacen que cualquier reescritura del historial con checkpoint
+  sea criptográficamente detectable (la factorización CT), y un despliegue con
+  un solo testigo queda etiquetado como el sustituto provisional que es. No
+  existe ninguna forma de PII en el commons: el contenido identificatorio vive
+  únicamente en el Locker borrable y local del miembro. `Entry.ID()`, el hash
+  de hoja, es la única referencia de intercambio entre capas.
+- **`internal/economy` — construido.** Crédito mutuo soberano por plataforma:
+  el crédito se emite en el momento del gasto, dentro de un único tope de
+  débito uniforme y gobernado, y la suma de todos los saldos es siempre
+  exactamente cero. Ningún mint, campo fiat, redención ni memo es
+  representable; el cambio entre escrow-ahora y crédito-después es exactamente
+  un PolicyChange firmado por quórum sobre el mismo almacén de solo anexado;
+  `Open` reproduce y reverifica por completo cada registro. `Spend.ExchangeHash`
+  lleva el ID de hoja de la entrada del registro, pero es deliberadamente
+  opaco y no se verifica en Post — el anclaje es una responsabilidad de la
+  raíz de composición.
+- **`internal/covenant` — construido.** Reputación según la Leveson-Based
+  Trade Assessment Scale (LBTAS) de NTARI: seis niveles cargados de
+  significado, desde -1 No Trust (sin confianza) hasta +4 Delight (deleite),
+  bidireccional (ambas partes de un intercambio sellado se evalúan
+  mutuamente), expresada por categoría sobre un vocabulario cerrado (valores
+  predeterminados: confiabilidad, usabilidad, desempeño, soporte), y leída
+  únicamente como distribuciones completas de conteo por nivel —por categoría,
+  agregadas en conjunto, y un conteo de daño que hace visible cada -1—
+  **nunca promediada**, sin puntaje, exportación, enmienda, retractación ni
+  comparación entre miembros en ninguna parte (dos pruebas centinela —un
+  escaneo por reflexión del conjunto de métodos y un escaneo con go/ast de
+  funciones exportadas— lo mantienen así). Un veredicto de -1 requiere un
+  comentario que lo justifique; el texto del comentario vive en el Locker
+  borrable y local del miembro, mientras que solo su hash viaja en el commons.
+  Cada evaluación está firmada por quien evalúa y tiene como precio un
+  intercambio sellado a través de la compuerta Anchors; los IDs de miembro son
+  hashes de clave con alcance de plataforma, y los IDs elegidos por humanos se
+  rechazan de plano. La especificación vinculante y la implementación de
+  referencia viven en
+  `Development/Covenant/Leveson-Based-Trade-Assessment-Scale`.
+- **Real pero delgado:** `internal/coord` — un cliente delgado sobre el
+  transporte HTTP+JSON de referencia del protocolo, que demuestra que Cloudy
+  consume `sohocloud-protocol`. `cmd/cloudy` lo construye e informa el
+  arranque; todavía no hay un bucle de coordinación en vivo.
+
+`cmd/cloudy` ahora construye las tres capas en memoria al arrancar (génesis en
+ModeEscrow, log de operador vacío, libro de convenios vacío sobre un
+directorio de miembros compartido vacío) y registra una línea honesta por
+capa. Cada paquete nombra sus invariantes no negociables en la documentación
+del paquete.
+
+## Qué posee Cloudy (arquitectura)
+
+Bajo la arquitectura resuelta, Cloudy —el frontend— posee el mundo completo
+del miembro. Tres capacidades, un solo dueño:
+
+- **La economía de miembros JFA — construida.** `internal/economy` (crédito
+  emitido por los miembros), `internal/covenant` (reputación LBTAS),
+  `internal/record` (registro sellado por diálogo), exactamente como se
+  documenta arriba. Estas son de Cloudy y deliberadamente no del protocolo:
+  las personas nunca viajan por el cable.
+- **El agente de nodo — propiedad de Cloudy, actualmente alojado en el
+  repositorio del coordinador a la espera de migración.** Detección de
+  hardware, perfiles de recursos, generación del listado de capacidades,
+  heartbeat, el ejecutor de trabajos, aplicación local de opt-out/lista de
+  permitidos, telemetría y el instalador para la máquina del miembro. Este
+  código (`internal/agent`, `cmd/agent` y el instalador MSI) vive hoy en el
+  repositorio de SoHoLINK y sigue funcionando allí — un remanente de la era
+  en que SoHoLINK era a la vez frontend y coordinador, no el rol de largo
+  plazo de SoHoLINK. El agente es la presencia del miembro en su propia
+  máquina, así que pertenece al frontend; un coordinador que despliega
+  agentes en el hardware de los miembros es un coordinador que toca el
+  hardware de los miembros, algo que SoHoLINK nunca debe hacer.
+- **El portal de miembros — propiedad de Cloudy, actualmente alojado en el
+  repositorio del coordinador a la espera de migración.** Registro, inicio de
+  sesión, panel de control, envío de trabajos y opt-out. La superficie antes
+  llamada el «portal de participantes» (`internal/portal`, `cmd/portal`,
+  `web/` en el repositorio de SoHoLINK) es de aquí en adelante el portal de
+  miembros de Cloudy — la identidad del miembro es un asunto del frontend,
+  así que la puerta por la que entran los miembros debe ser la puerta del
+  frontend.
+
+El agente de nodo y el portal de miembros son los próximos hitos de
+construcción ahora que las tres capas están completas como bibliotecas. Como
+dice honestamente el estado de arriba: ninguno de los dos tiene todavía un
+punto de entrada aquí, y nada en este repositorio pretende que la migración ya
+haya ocurrido.
+
+### Glosario
+
+- **Miembro** — una persona, siempre relativa a un frontend/plataforma. La
+  identidad (MemberID con alcance de plataforma), el crédito, la posición
+  LBTAS, los registros sellados, la PII (borrable, local al miembro) y las
+  máquinas aportadas son hechos de membresía. La membresía es lenguaje de
+  convenio — obligación mutua hacia una plataforma particular; el mismo ser
+  humano es un miembro distinto en cada plataforma por construcción
+  criptográfica.
+- **Participante** — un rol, no una entidad: un miembro que actúa en la
+  economía coordinada, aportando nodos y/o enviando trabajos — una identidad
+  unificada, nunca dividida en productor y consumidor. Los registros de
+  personas del lado del coordinador (la tabla de participants de SoHoLINK y
+  las cuentas del portal) son superficies transicionales de la era dual.
+- **Nodo** — una máquina que un miembro aporta, identificada por NodeID con
+  la vinculación SPIFFE `/node/<id>` (el paquete `identity/` del protocolo).
+
+### Identidad hacia el coordinador
+
+Dos identidades cruzan la frontera frontend/coordinador, y no deben
+confundirse. Las máquinas de los miembros portan **identidad de carga de
+trabajo (workload identity)**: un SVID de SPIFFE bajo `/node/<id>`, autorizado
+del lado del coordinador exactamente según la SPEC del protocolo — identidad
+de máquina, sin cambios. Cloudy mismo se autentica como un **operador**
+inscrito: el modelo de frontend-como-operador, un **objetivo de diseño**
+modelado sobre el esquema de operadores de la Fase 5 de Agrinet (un registro
+de operators + operator-keys; un conjunto rotatorio de siete claves Ed25519,
+cada transmisión firmada con dos; replay acotado por una ventana de marca de
+tiempo más una caché de nonces — ver
+`Development/Economy/Agrinet backend/lib/operatorKeys.js` y
+`backend/middleware/operatorAuth.js`). La rotación es el punto: una clave
+compartida estática y nunca rotada es precisamente el antipatrón que la
+referencia advierte no heredar. Ninguna de las dos identidades es jamás una
+persona: la identidad del miembro permanece dentro de Cloudy.
+
+## Invariante del grafo de importaciones
+
+Cloudy importa `sohocloud-protocol`; **nada importa a Cloudy**. Cloudy depende
+del núcleo del protocolo y de su transporte de referencia, y no elude a
+ninguno de los dos. La dirección de la dependencia es lo que mantiene
+separables al frontend y al coordinador: un frontend puede reemplazarse sin
+tocar el sustrato, y el sustrato no sabe de ningún frontend en particular.
+
+Dentro de Cloudy, los tres paquetes JFA nunca se importan entre sí; cada uno
+ve solo la biblioteca estándar y el paquete `canon` del protocolo, y todas las
+importaciones se mantienen unidireccionales. Se encuentran únicamente en la
+raíz de composición: `test/composition` es la única prueba de raíz de
+composición — allí viven el único directorio de miembros compartido, el
+predicado Anchors que une el convenio con el registro sobre `Entry.ID()` y la
+historia completa del miembro — y `cmd/cloudy` realiza la misma composición al
+arrancar.
+
+## Compilación
+
+El módulo del protocolo es actualmente privado y no tiene tags. Este esqueleto
+lo resuelve mediante una directiva `replace` hacia un **checkout hermano
+local**:
+
+```
+replace github.com/NTARI-RAND/sohocloud-protocol => ../sohocloud-protocol
+```
+
+Por lo tanto, `sohocloud-protocol` debe clonarse junto a `Cloudy` (ambos bajo
+el mismo directorio padre). Este `replace` es una conveniencia para el
+desarrollo local — tal cual está, no es compilable por terceros. Publicar
+Cloudy para compilación externa requerirá etiquetar el módulo del protocolo (o
+una configuración de `GOPRIVATE` + descarga autenticada) y eliminar el
+`replace`.
+
+```
+go build ./...
+go test ./...
+```
+
+## Licencia
+
+AGPL-3.0-or-later.
+
+*Network Theory Applied Research Institute, Inc. — 501(c)(3) — EIN 92-3047136 — info@ntari.org*
diff --git a/README.fr.md b/README.fr.md
new file mode 100644
index 0000000..f1469c2
--- /dev/null
+++ b/README.fr.md
@@ -0,0 +1,196 @@
+> Traduction communautaire (brouillon) — politique NTARI P2-002, Diffusion
+> multilingue mondiale. Source : README.md (original anglais, instantané du
+> 2026-07-29). Brouillon communautaire assisté par machine, en attente de
+> relecture par le mainteneur régional conformément au P2-002 §3.1. Les
+> spécifications techniques de base restent en anglais conformément au §2.2.
+>
+> Vous avez remarqué une erreur de traduction ? N'hésitez pas à la corriger
+> vous-même : forkez le dépôt https://github.com/NTARI-RAND/Cloudy et ouvrez
+> une pull request. Les corrections de traduction sont des contributions
+> précieuses, tout autant que le code.
+
+# Cloudy
+
+Un frontend du réseau de coordination SoHoLINK / sohocloud. Cloudy est l'endroit
+où les membres effectuent leurs transactions ; il consomme la coordination du
+substrat via le module partagé `sohocloud-protocol` et possède, par-dessus, sa
+propre économie des membres JFA.
+
+## État (en toute honnêteté)
+
+Les trois couches de l'économie des membres JFA que Cloudy possède — et que le
+protocole, délibérément, ne possède pas — sont désormais **construites, avec
+tests**. Il n'existe encore ni boucle de coordination active, ni surface
+visible par les membres.
+
+- **`internal/record` — construit.** Registre scellé par dialogue, en ajout
+  seul (append-only) et attesté par témoins : chaque Entry porte les sceaux des
+  deux membres sur des octets canoniques à séparation de domaine, de sorte
+  qu'un covenant à moitié scellé ou conclu avec soi-même ne peut jamais entrer
+  dans un journal ; les journaux chaînés par hachage, propres à chaque
+  opérateur, sont entièrement revérifiés lors de `OpenLog` ; les points de
+  contrôle de l'opérateur, associés aux contresignatures de témoins
+  indépendants, rendent cryptographiquement détectable toute réécriture de
+  l'historique déjà pointé (le découpage de type CT), et un déploiement à
+  témoin unique est explicitement désigné pour ce qu'il est : une solution
+  provisoire. Aucune forme de données personnelles identifiantes (PII)
+  n'existe dans les communs — le contenu identifiant ne vit que dans le
+  Locker effaçable, local au membre. `Entry.ID()`, le hachage de feuille, est
+  la seule référence d'échange entre les couches.
+- **`internal/economy` — construit.** Crédit mutuel souverain, propre à chaque
+  plateforme : le crédit est émis au moment de la dépense, dans les limites
+  d'un plafond de débit unique, uniforme et gouverné, et la somme de tous les
+  soldes est toujours exactement nulle. Aucune frappe monétaire, aucun champ
+  fiat, aucun remboursement ni aucun mémo n'est représentable ; le passage
+  « séquestre immédiat / crédit différé » se réduit à un seul PolicyChange
+  signé par quorum sur le même stockage en ajout seul ; `Open` rejoue et
+  revérifie intégralement chaque enregistrement. `Spend.ExchangeHash` porte
+  l'identifiant de feuille de l'entrée du registre, mais reste délibérément
+  opaque et non vérifié au niveau de Post — l'ancrage relève de la racine de
+  composition.
+- **`internal/covenant` — construit.** Réputation sur l'échelle d'évaluation
+  des échanges fondée sur Leveson (Leveson-Based Trade Assessment Scale,
+  LBTAS) de NTARI : six niveaux porteurs de sens, de -1 Aucune confiance
+  (No Trust) à +4 Enchantement (Delight), bidirectionnels (les deux parties à
+  un échange scellé s'évaluent mutuellement), rendus par catégorie sur un
+  vocabulaire fermé (par défaut : reliability, usability, performance,
+  support), et lus uniquement sous forme de distributions complètes du nombre
+  d'évaluations par niveau — par catégorie, agrégées globalement, plus un
+  compte des préjudices qui fait remonter chaque -1 — **jamais sous forme de
+  moyenne**, sans aucun score, export, amendement, rétractation ni comparaison
+  entre membres où que ce soit (deux tests garde-fous — un scan de l'ensemble
+  des méthodes par réflexion et un scan des fonctions exportées via go/ast —
+  veillent à ce que cela reste ainsi). Un verdict à -1 exige un commentaire
+  justificatif ; le texte du commentaire vit dans le Locker effaçable, local au
+  membre, tandis que seul son hachage circule dans les communs. Chaque
+  évaluation est signée par son auteur et tarifée à un échange scellé via la
+  barrière Anchors ; les identifiants de membre sont des hachages de clés
+  limités à une plateforme, et les identifiants choisis par des humains sont
+  rejetés d'emblée. La spécification contraignante et l'implémentation de
+  référence se trouvent dans
+  `Development/Covenant/Leveson-Based-Trade-Assessment-Scale`.
+- **Réel mais minimal :** `internal/coord` — un client léger au-dessus du
+  transport de référence HTTP+JSON du protocole, qui démontre que Cloudy
+  consomme bien `sohocloud-protocol`. `cmd/cloudy` le construit et signale le
+  démarrage ; il n'y a pas encore de boucle de coordination active.
+
+`cmd/cloudy` construit désormais les trois couches en mémoire au démarrage
+(genèse ModeEscrow, journal d'opérateur vide, livre de covenants vide au-dessus
+d'un annuaire des membres partagé et vide) et journalise une ligne honnête par
+couche. Chaque paquet nomme ses invariants non négociables dans sa
+documentation de paquet.
+
+## Ce que Cloudy possède (architecture)
+
+Dans l'architecture retenue, Cloudy — le frontend — possède tout le monde du
+membre. Trois capacités, un seul propriétaire :
+
+- **L'économie des membres JFA — construite.** `internal/economy` (crédit émis
+  par les membres), `internal/covenant` (réputation LBTAS), `internal/record`
+  (registre scellé par dialogue), exactement comme décrit ci-dessus. Ces
+  éléments appartiennent à Cloudy et délibérément pas au protocole : les
+  personnes n'apparaissent jamais sur le fil.
+- **L'agent de nœud — propriété de Cloudy, actuellement hébergé dans le dépôt
+  du coordinateur en attendant sa migration.** Détection du matériel, profils
+  de ressources, génération des listes de capacités, heartbeat, exécuteur de
+  tâches, application locale du retrait (opt-out) et des listes d'autorisation
+  (allowlist), télémétrie, et installateur pour les machines des membres. Ce
+  code (`internal/agent`, `cmd/agent` et l'installateur MSI) vit aujourd'hui
+  dans le dépôt SoHoLINK et continue d'y fonctionner — un vestige de l'époque
+  où SoHoLINK était à la fois frontend et coordinateur, et non son rôle à long
+  terme. L'agent est la présence du membre sur sa propre machine : il
+  appartient donc au frontend ; un coordinateur qui livre des agents sur le
+  matériel des membres est un coordinateur qui touche au matériel des membres,
+  ce que SoHoLINK ne doit jamais faire.
+- **Le portail des membres — propriété de Cloudy, actuellement hébergé dans le
+  dépôt du coordinateur en attendant sa migration.** Inscription, connexion,
+  tableau de bord, soumission de tâches et retrait (opt-out). La surface
+  autrefois appelée « portail des participants » (`internal/portal`,
+  `cmd/portal`, `web/` dans le dépôt SoHoLINK) devient désormais le portail des
+  membres de Cloudy — l'identité du membre est une affaire de frontend, donc la
+  porte que franchissent les membres doit être celle du frontend.
+
+L'agent de nœud et le portail des membres sont les prochains jalons de
+développement, maintenant que les trois couches sont complètes en tant que
+bibliothèques. Comme l'indique honnêtement l'état ci-dessus : ni l'un ni
+l'autre ne dispose encore d'un point d'entrée ici, et rien dans ce dépôt ne
+prétend que la migration a déjà eu lieu.
+
+### Glossaire
+
+- **Membre** — une personne, toujours relative à un frontend/plateforme.
+  L'identité (MemberID limité à une plateforme), le crédit, la position LBTAS,
+  les enregistrements scellés, les PII (effaçables, locales au membre) et les
+  machines contribuées sont des faits d'adhésion. L'adhésion relève du langage
+  du covenant — une obligation mutuelle envers une plateforme particulière ; le
+  même être humain est un membre différent sur chaque plateforme, par
+  construction cryptographique.
+- **Participant** — un rôle, non une entité : un membre agissant dans
+  l'économie coordonnée, contribuant des nœuds et/ou soumettant des tâches —
+  une identité unifiée, jamais scindée entre producteur et consommateur. Les
+  enregistrements de personnes côté coordinateur (la table des participants de
+  SoHoLINK et les comptes du portail) sont des surfaces transitoires héritées
+  de l'époque duale.
+- **Nœud** — une machine qu'un membre contribue, identifiée par un NodeID avec
+  la liaison SPIFFE `/node/<id>` (le paquet `identity/` du protocole).
+
+### Identité face au coordinateur
+
+Deux identités traversent la frontière frontend/coordinateur, et elles ne
+doivent pas être confondues. Les machines des membres portent une **identité de
+charge de travail** : un SVID SPIFFE sous `/node/<id>`, autorisé côté
+coordinateur exactement selon le SPEC du protocole — identité machine,
+inchangée. Cloudy lui-même s'authentifie comme **opérateur** enrôlé : le modèle
+frontend-en-tant-qu'opérateur, une **cible de conception** calquée sur le
+schéma d'opérateurs de la Phase 5 d'Agrinet (un registre operators +
+operator-keys ; un jeu rotatif de sept clés Ed25519, chaque transmission étant
+signée par deux d'entre elles ; le rejeu borné par une fenêtre d'horodatage et
+un cache de nonces — voir
+`Development/Economy/Agrinet backend/lib/operatorKeys.js` et
+`backend/middleware/operatorAuth.js`). La rotation est le point essentiel : une
+clé partagée statique, jamais renouvelée, est précisément l'anti-pattern contre
+l'héritage duquel la référence met en garde. Aucune de ces deux identités n'est
+jamais une personne : l'identité du membre reste à l'intérieur de Cloudy.
+
+## Invariant du graphe d'imports
+
+Cloudy importe `sohocloud-protocol` ; **rien n'importe Cloudy**. Cloudy dépend
+du cœur du protocole et de son transport de référence, et ne contourne ni l'un
+ni l'autre. C'est la direction de la dépendance qui garde le frontend et le
+coordinateur séparables : un frontend peut être remplacé sans toucher au
+substrat, et le substrat ne connaît aucun frontend en particulier.
+
+À l'intérieur de Cloudy, les trois paquets JFA ne s'importent jamais entre eux ;
+chacun ne voit que la bibliothèque standard et le paquet `canon` du protocole,
+et tous les imports restent unidirectionnels. Ils ne se rencontrent qu'à la
+racine de composition : `test/composition` est le seul test de racine de
+composition — l'annuaire des membres unique et partagé, le prédicat Anchors qui
+relie covenant à record via `Entry.ID()`, et l'histoire complète d'un membre y
+vivent — et `cmd/cloudy` effectue la même composition au démarrage.
+
+## Compilation
+
+Le module du protocole est actuellement privé et sans tag. Ce squelette le
+résout via une directive `replace` pointant vers une **copie locale voisine** :
+
+```
+replace github.com/NTARI-RAND/sohocloud-protocol => ../sohocloud-protocol
+```
+
+`sohocloud-protocol` doit donc être cloné à côté de `Cloudy` (tous deux sous le
+même répertoire parent). Ce `replace` est une commodité de développement
+local — il n'est pas compilable en l'état par d'autres personnes. Publier Cloudy
+pour une compilation externe exigera de taguer le module du protocole (ou de
+mettre en place `GOPRIVATE` + une récupération authentifiée) et de supprimer le
+`replace`.
+
+```
+go build ./...
+go test ./...
+```
+
+## Licence
+
+AGPL-3.0-or-later.
+
+*Network Theory Applied Research Institute, Inc. — 501(c)(3) — EIN 92-3047136 — info@ntari.org*
diff --git a/README.hi.md b/README.hi.md
new file mode 100644
index 0000000..c35c680
--- /dev/null
+++ b/README.hi.md
@@ -0,0 +1,177 @@
+> सामुदायिक अनुवाद (प्रारूप) — NTARI नीति P2-002, Global Multilingual Broadcast। स्रोत: README.md (अंग्रेज़ी मूल, स्नैपशॉट 2026-07-29)। P2-002 §3.1 के अनुसार क्षेत्रीय मेंटेनर की समीक्षा हेतु लंबित, मशीन-सहायता से तैयार सामुदायिक प्रारूप। मूल तकनीकी विनिर्देश §2.2 के अनुसार अंग्रेज़ी में ही रहते हैं।
+>
+> अनुवाद में कोई त्रुटि दिखे तो कृपया उसे स्वयं सुधारने में मदद करें:
+> रिपॉज़िटरी को फ़ॉर्क (fork) करें और अपना सुधार पुल रिक्वेस्ट (pull request)
+> के रूप में भेजें — https://github.com/NTARI-RAND/Cloudy। अनुवाद-सुधार हमारे
+> लिए किसी भी अन्य योगदान जितने ही मूल्यवान हैं, और उनका सदा स्वागत है।
+
+# Cloudy
+
+SoHoLINK / sohocloud समन्वय नेटवर्क पर एक फ्रंटएंड। Cloudy वह जगह है जहाँ
+सदस्य लेन-देन करते हैं; यह साझा `sohocloud-protocol` मॉड्यूल के माध्यम से
+सब्सट्रेट समन्वय का उपभोग करता है और उसके ऊपर अपनी स्वयं की JFA
+सदस्य-अर्थव्यवस्था का स्वामी है।
+
+## स्थिति (ईमानदार आकलन)
+
+जिन तीन JFA सदस्य-अर्थव्यवस्था परतों का स्वामित्व Cloudy के पास है — और जो
+जान-बूझकर प्रोटोकॉल के पास नहीं है — वे अब **टेस्ट सहित निर्मित** हैं। अभी भी
+कोई लाइव समन्वय लूप नहीं है और कोई सदस्य-सम्मुख सतह नहीं है।
+
+- **`internal/record` — निर्मित।** संवाद-सीलबंद (dialog-sealed),
+  केवल-जोड़ने-योग्य (append-only), साक्ष्यांकित रिकॉर्ड: प्रत्येक Entry में
+  कैननिकल, डोमेन-पृथक बाइट्स पर दोनों सदस्यों की सीलें होती हैं, जिससे कोई
+  आधी-सीलबंद या स्व-लेनदेन वाली कोवेनेंट कभी किसी लॉग में प्रवेश नहीं कर
+  सकती; प्रति-ऑपरेटर हैश-श्रृंखलित लॉग `OpenLog` पर पूरी तरह पुनः-सत्यापित
+  किए जाते हैं; ऑपरेटर चेकपॉइंट तथा स्वतंत्र साक्षी प्रति-हस्ताक्षरों के
+  संयोजन से चेकपॉइंट की गई हिस्ट्री के किसी भी पुनर्लेखन का
+  क्रिप्टोग्राफ़िक रूप से पता लगाया जा सकता है (CT फैक्टरिंग), और
+  एकल-साक्षी परिनियोजन को स्पष्ट रूप से वही अस्थायी विकल्प कहा गया है जो वह
+  है। कॉमन्स में कोई PII आकार मौजूद नहीं है — पहचान करने वाली सामग्री केवल
+  मिटाए जा सकने वाले, सदस्य-स्थानीय Locker में रहती है। `Entry.ID()`, यानी
+  लीफ़ हैश, एकमात्र क्रॉस-लेयर विनिमय संदर्भ है।
+- **`internal/economy` — निर्मित।** प्रति-प्लेटफ़ॉर्म संप्रभु पारस्परिक
+  क्रेडिट: क्रेडिट खर्च करने के क्षण में जारी होता है, एक समान, शासित डेबिट
+  सीमा के भीतर, और सभी बैलेंस का योग हमेशा ठीक शून्य रहता है। कोई मिंट,
+  फ़िएट फ़ील्ड, रिडेम्पशन या मेमो निरूपित करना संभव ही नहीं है;
+  escrow-now/credit-later उसी append-only स्टोर पर ठीक एक कोरम-हस्ताक्षरित
+  PolicyChange है; `Open` हर रिकॉर्ड को पूरी तरह री-प्ले और पुनः-सत्यापित
+  करता है। `Spend.ExchangeHash` रिकॉर्ड एंट्री की लीफ़ ID वहन करता है, लेकिन
+  Post के समय यह जान-बूझकर अपारदर्शी और अजाँचा रहता है — एंकरिंग
+  कम्पोज़िशन-रूट का दायित्व है।
+- **`internal/covenant` — निर्मित।** NTARI के Leveson-Based Trade
+  Assessment Scale (LBTAS) पर प्रतिष्ठा: -1 No Trust से +4 Delight तक छह
+  अर्थ-भारित स्तर, द्विदिशात्मक (सीलबंद विनिमय के दोनों पक्ष एक-दूसरे का
+  आकलन करते हैं), एक बंद शब्दावली पर प्रति-श्रेणी प्रस्तुत (डिफ़ॉल्ट:
+  reliability, usability, performance, support), और केवल पूर्ण
+  गणना-प्रति-स्तर वितरणों के रूप में पढ़ी जाती है — प्रति-श्रेणी, समग्र
+  पूल्ड, और एक हानि-गणना जो हर -1 को सामने लाती है — **कभी औसत नहीं निकाला
+  जाता**, कहीं भी कोई स्कोर, निर्यात, संशोधन, वापसी या क्रॉस-सदस्य तुलना
+  नहीं (दो ट्रिपवायर टेस्ट — एक reflection method-set स्कैन और एक go/ast
+  exported-function स्कैन — इसे इसी तरह बनाए रखते हैं)। -1 के निर्णय के लिए
+  औचित्य बताने वाली टिप्पणी अनिवार्य है; टिप्पणी का पाठ मिटाए जा सकने वाले
+  सदस्य-स्थानीय Locker में रहता है जबकि कॉमन्स में केवल उसका हैश जाता है।
+  हर आकलन आकलनकर्ता-हस्ताक्षरित होता है और Anchors गेट के माध्यम से एक
+  सीलबंद विनिमय की कीमत पर मिलता है; सदस्य ID प्लेटफ़ॉर्म-स्कोप्ड की-हैश
+  हैं, और मानव-चयनित ID सिरे से अस्वीकार कर दी जाती हैं। बाध्यकारी
+  विनिर्देश और संदर्भ कार्यान्वयन
+  `Development/Covenant/Leveson-Based-Trade-Assessment-Scale` पर उपलब्ध हैं।
+- **वास्तविक लेकिन पतला:** `internal/coord` — प्रोटोकॉल के संदर्भ HTTP+JSON
+  ट्रांसपोर्ट पर एक पतला क्लाइंट, जो सिद्ध करता है कि Cloudy
+  `sohocloud-protocol` का उपभोग करता है। `cmd/cloudy` इसे निर्मित करता है और
+  स्टार्टअप की सूचना देता है; अभी कोई लाइव समन्वय लूप नहीं है।
+
+`cmd/cloudy` अब स्टार्टअप पर तीनों परतों को मेमोरी में निर्मित करता है
+(ModeEscrow जेनेसिस, खाली ऑपरेटर लॉग, एक खाली साझा सदस्य निर्देशिका पर खाली
+कोवेनेंट बुक) और प्रति परत एक ईमानदार पंक्ति लॉग करता है। प्रत्येक पैकेज
+अपने पैकेज-डॉक में अपने अटल (non-negotiable) इनवैरिएंट्स का नाम दर्ज करता है।
+
+## Cloudy का स्वामित्व किस पर है (आर्किटेक्चर)
+
+तय की गई आर्किटेक्चर के अंतर्गत, Cloudy — फ्रंटएंड — सदस्य की पूरी दुनिया का
+स्वामी है। तीन क्षमताएँ, एक स्वामी:
+
+- **JFA सदस्य-अर्थव्यवस्था — निर्मित।** `internal/economy` (सदस्य-जारी
+  क्रेडिट), `internal/covenant` (LBTAS प्रतिष्ठा), `internal/record`
+  (संवाद-सीलबंद रिकॉर्ड), ठीक जैसा ऊपर प्रलेखित है। ये Cloudy के हैं और
+  जान-बूझकर प्रोटोकॉल के नहीं: व्यक्ति कभी वायर पर प्रकट नहीं होते।
+- **नोड एजेंट — Cloudy के स्वामित्व में, फ़िलहाल माइग्रेशन लंबित रहते हुए
+  कोऑर्डिनेटर रिपॉज़िटरी में होस्टेड।** हार्डवेयर डिटेक्शन, संसाधन
+  प्रोफ़ाइल, क्षमता-सूची निर्माण, हार्टबीट, जॉब एग्ज़िक्यूटर, स्थानीय
+  ऑप्ट-आउट/allowlist प्रवर्तन, टेलीमेट्री, और सदस्य-मशीन इंस्टॉलर। यह कोड
+  (`internal/agent`, `cmd/agent`, और MSI इंस्टॉलर) आज SoHoLINK रिपॉज़िटरी
+  में रहता है और वहीं काम करता रहता है — यह SoHoLINK के दोहरे
+  फ्रंटएंड+कोऑर्डिनेटर युग का अवशेष है, न कि SoHoLINK की दीर्घकालिक भूमिका।
+  एजेंट सदस्य की अपनी मशीन पर सदस्य की उपस्थिति है, इसलिए वह फ्रंटएंड का
+  है; जो कोऑर्डिनेटर सदस्य के हार्डवेयर पर एजेंट भेजता है, वह सदस्य के
+  हार्डवेयर को छूने वाला कोऑर्डिनेटर है — और यह SoHoLINK को कभी नहीं करना
+  चाहिए।
+- **सदस्य पोर्टल — Cloudy के स्वामित्व में, फ़िलहाल माइग्रेशन लंबित रहते
+  हुए कोऑर्डिनेटर रिपॉज़िटरी में होस्टेड।** रजिस्टर, लॉगिन, डैशबोर्ड, जॉब
+  सबमिशन, और ऑप्ट-आउट। जिस सतह को पहले "participant portal" कहा जाता था
+  (SoHoLINK रिपॉज़िटरी में `internal/portal`, `cmd/portal`, `web/`) वह अब
+  से Cloudy का सदस्य पोर्टल है — सदस्य पहचान फ्रंटएंड का विषय है, इसलिए
+  जिस दरवाज़े से सदस्य भीतर आते हैं वह फ्रंटएंड का ही दरवाज़ा होना चाहिए।
+
+अब जब तीनों परतें लाइब्रेरी-स्तर पर पूर्ण हैं, नोड एजेंट और सदस्य पोर्टल
+अगले निर्माण-मील के पत्थर हैं। जैसा ऊपर की स्थिति ईमानदारी से कहती है:
+इनमें से किसी का भी यहाँ अभी कोई प्रवेश-बिंदु (ingress) नहीं है, और इस
+रिपॉज़िटरी में कुछ भी यह दिखावा नहीं करता कि माइग्रेशन पहले ही हो चुका है।
+
+### शब्दावली
+
+- **सदस्य (Member)** — एक व्यक्ति, हमेशा किसी फ्रंटएंड/प्लेटफ़ॉर्म के
+  सापेक्ष। पहचान (प्लेटफ़ॉर्म-स्कोप्ड MemberID), क्रेडिट, LBTAS स्थिति,
+  सीलबंद रिकॉर्ड, PII (मिटाए जाने योग्य, सदस्य-स्थानीय), और योगदान की गई
+  मशीनें — ये सब सदस्यता के तथ्य हैं। सदस्यता कोवेनेंट की भाषा है — किसी
+  विशिष्ट प्लेटफ़ॉर्म के प्रति पारस्परिक दायित्व; क्रिप्टोग्राफ़िक संरचना
+  के कारण वही मनुष्य हर प्लेटफ़ॉर्म पर एक अलग सदस्य होता है।
+- **प्रतिभागी (Participant)** — एक भूमिका, कोई इकाई नहीं: समन्वित
+  अर्थव्यवस्था में कार्यरत एक सदस्य, जो नोड्स का योगदान करता है और/या जॉब
+  सबमिट करता है — एक एकीकृत पहचान, जिसे कभी उत्पादक और उपभोक्ता में
+  विभाजित नहीं किया जाता। कोऑर्डिनेटर-पक्ष के व्यक्ति-रिकॉर्ड (SoHoLINK की
+  participants टेबल और पोर्टल खाते) दोहरे युग की संक्रमणकालीन सतहें हैं।
+- **नोड (Node)** — सदस्य द्वारा योगदान की गई एक मशीन, जिसकी पहचान NodeID से
+  होती है, SPIFFE बाइंडिंग `/node/<id>` (प्रोटोकॉल का `identity/` पैकेज)
+  के साथ।
+
+### कोऑर्डिनेटर के प्रति पहचान
+
+दो पहचानें फ्रंटएंड/कोऑर्डिनेटर सीमा को पार करती हैं, और इन्हें आपस में
+मिलाना नहीं चाहिए। सदस्यों की मशीनें **वर्कलोड पहचान** वहन करती हैं:
+`/node/<id>` के अंतर्गत एक SPIFFE SVID, जो कोऑर्डिनेटर-पक्ष पर ठीक प्रोटोकॉल
+SPEC के अनुसार प्राधिकृत होता है — मशीन पहचान, अपरिवर्तित। Cloudy स्वयं एक
+नामांकित **ऑपरेटर** के रूप में प्रमाणित होता है: फ्रंटएंड-एज़-ऑपरेटर मॉडल,
+एक **डिज़ाइन लक्ष्य** जो Agrinet की Phase 5 ऑपरेटर योजना के नमूने पर आधारित
+है (एक operators + operator-keys रजिस्ट्री; सात कुंजियों का एक घूर्णनशील
+Ed25519 की-सेट, हर ट्रांसमिशन पर दो से हस्ताक्षर; टाइमस्टैम्प विंडो और nonce
+कैश द्वारा सीमित री-प्ले — देखें
+`Development/Economy/Agrinet backend/lib/operatorKeys.js` और
+`backend/middleware/operatorAuth.js`)। रोटेशन ही मूल बात है: एक स्थिर, कभी न
+बदली जाने वाली साझा कुंजी ठीक वही एंटी-पैटर्न है जिसे विरासत में लेने के
+विरुद्ध संदर्भ कार्यान्वयन चेतावनी देता है। दोनों में से कोई भी पहचान कभी
+कोई व्यक्ति नहीं होती: सदस्य पहचान Cloudy के भीतर ही रहती है।
+
+## इम्पोर्ट-ग्राफ़ इनवैरिएंट
+
+Cloudy `sohocloud-protocol` को इम्पोर्ट करता है; **Cloudy को कोई इम्पोर्ट
+नहीं करता**। Cloudy प्रोटोकॉल के कोर और उसके संदर्भ ट्रांसपोर्ट पर निर्भर
+करता है और दोनों में से किसी को दरकिनार नहीं करता। निर्भरता की यही दिशा
+फ्रंटएंड और कोऑर्डिनेटर को पृथक्करणीय बनाए रखती है: सब्सट्रेट को छुए बिना
+फ्रंटएंड बदला जा सकता है, और सब्सट्रेट किसी विशेष फ्रंटएंड के बारे में नहीं
+जानता।
+
+Cloudy के भीतर, तीनों JFA पैकेज कभी एक-दूसरे को इम्पोर्ट नहीं करते; प्रत्येक
+केवल स्टैंडर्ड लाइब्रेरी और प्रोटोकॉल का `canon` पैकेज देखता है, और सभी
+इम्पोर्ट एक-दिशात्मक रहते हैं। वे केवल कम्पोज़िशन रूट पर मिलते हैं:
+`test/composition` ही एकमात्र कम्पोज़िशन-रूट टेस्ट है — एकल साझा सदस्य
+निर्देशिका, `Entry.ID()` पर कोवेनेंट को रिकॉर्ड से जोड़ने वाला Anchors
+प्रेडिकेट, और पूरी सदस्य-कथा वहीं रहती है — और `cmd/cloudy` स्टार्टअप पर वही
+कम्पोज़िशन करता है।
+
+## बिल्ड करना
+
+प्रोटोकॉल मॉड्यूल फ़िलहाल निजी और बिना टैग का है। यह स्केलेटन इसे एक
+**स्थानीय सिबलिंग चेकआउट** की ओर संकेत करने वाले `replace` निर्देश के माध्यम
+से हल करता है:
+
+```
+replace github.com/NTARI-RAND/sohocloud-protocol => ../sohocloud-protocol
+```
+
+इसलिए `sohocloud-protocol` को `Cloudy` के बगल में क्लोन किया जाना चाहिए
+(दोनों एक ही पैरेंट डायरेक्टरी के अंतर्गत)। यह `replace` स्थानीय विकास की
+सुविधा है — जैसा-है वैसा यह दूसरों द्वारा बिल्ड करने योग्य नहीं है। बाहरी
+बिल्ड के लिए Cloudy को प्रकाशित करने हेतु प्रोटोकॉल मॉड्यूल को टैग करना (या
+`GOPRIVATE` + प्रमाणीकृत-फ़ेच सेटअप) और `replace` को हटाना आवश्यक होगा।
+
+```
+go build ./...
+go test ./...
+```
+
+## लाइसेंस
+
+AGPL-3.0-or-later।
+
+*Network Theory Applied Research Institute, Inc. — 501(c)(3) — EIN 92-3047136 — info@ntari.org*
diff --git a/README.pt.md b/README.pt.md
new file mode 100644
index 0000000..947756b
--- /dev/null
+++ b/README.pt.md
@@ -0,0 +1,179 @@
+> Tradução comunitária (rascunho) — política P2-002 da NTARI, Transmissão Multilíngue Global. Fonte: README.md (original em inglês, snapshot de 2026-07-29). Rascunho comunitário assistido por máquina, pendente de revisão do mantenedor regional conforme P2-002 §3.1. As especificações técnicas centrais permanecem em inglês conforme §2.2.
+>
+> Notou algum erro nesta tradução? Correções de tradução são contribuições
+> valiosas e muito bem-vindas: faça um fork do repositório e abra um pull
+> request em https://github.com/NTARI-RAND/Cloudy.
+
+# Cloudy
+
+Um frontend na rede de coordenação SoHoLINK / sohocloud. O Cloudy é onde os
+membros transacionam; ele consome a coordenação do substrato através do módulo
+compartilhado `sohocloud-protocol` e, por cima disso, é dono da sua própria
+economia de membros JFA.
+
+## Status (honesto)
+
+As três camadas da economia de membros JFA que pertencem ao Cloudy — e que o
+protocolo deliberadamente não possui — estão agora **construídas, com testes**.
+Ainda não existe loop de coordenação ativo nem superfície voltada ao membro.
+
+- **`internal/record` — construído.** Registro selado em diálogo, somente de
+  anexação (append-only) e testemunhado: cada Entry carrega os selos de ambos
+  os membros sobre bytes canônicos e separados por domínio, de modo que um
+  pacto meio-selado ou autonegociado nunca pode entrar em um log; os logs
+  encadeados por hash de cada operador são reverificados integralmente em
+  `OpenLog`; checkpoints do operador mais contra-assinaturas de testemunhas
+  independentes tornam criptograficamente detectável qualquer reescrita do
+  histórico já submetido a checkpoint (a fatoração CT), e uma implantação com
+  uma única testemunha é rotulada como o substituto provisório que ela é.
+  Nenhuma forma de PII existe no commons — o conteúdo identificador vive
+  apenas no Locker apagável e local ao membro. `Entry.ID()`, o hash da folha,
+  é a única referência de troca entre camadas.
+- **`internal/economy` — construído.** Crédito mútuo soberano por plataforma:
+  o crédito é emitido no momento do gasto, dentro de um único limite de débito
+  uniforme e governado, e a soma de todos os saldos é sempre exatamente zero.
+  Não há como representar cunhagem, campo fiat, resgate ou memo;
+  escrow-agora/crédito-depois é exatamente um PolicyChange assinado por quórum
+  no mesmo armazenamento somente de anexação; `Open` reexecuta e reverifica
+  integralmente cada registro. `Spend.ExchangeHash` carrega o ID da folha da
+  entrada de registro, mas é deliberadamente opaco e não verificado em Post —
+  a ancoragem é uma questão da raiz de composição.
+- **`internal/covenant` — construído.** Reputação na Leveson-Based Trade
+  Assessment Scale (LBTAS) da NTARI: seis níveis carregados de significado,
+  de -1 No Trust (Nenhuma Confiança) a +4 Delight (Encantamento),
+  bidirecional (ambas as partes de uma troca selada avaliam uma à outra),
+  expressa por categoria sobre um vocabulário fechado (padrões: reliability,
+  usability, performance, support) e lida apenas como distribuições completas
+  de contagem por nível — por categoria, agrupada no geral, e uma contagem de
+  dano que expõe cada -1 — **nunca em média**, sem nenhuma pontuação,
+  exportação, emenda, retratação ou comparação entre membros em lugar algum
+  (dois testes sentinela — uma varredura do conjunto de métodos por reflexão e
+  uma varredura de funções exportadas com go/ast — mantêm as coisas assim).
+  Um veredito -1 exige um comentário justificando; o texto do comentário vive
+  no Locker apagável e local ao membro, enquanto apenas o seu hash trafega no
+  commons. Toda avaliação é assinada pelo avaliador e custa exatamente uma
+  troca selada, através do portão Anchors; os IDs de membro são hashes de
+  chave com escopo de plataforma, e IDs escolhidos por humanos são rejeitados
+  de imediato. A especificação vinculante e a implementação de referência
+  vivem em `Development/Covenant/Leveson-Based-Trade-Assessment-Scale`.
+- **Real, mas enxuto:** `internal/coord` — um cliente fino sobre o transporte
+  HTTP+JSON de referência do protocolo, provando que o Cloudy consome
+  `sohocloud-protocol`. `cmd/cloudy` o constrói e informa a inicialização;
+  ainda não há loop de coordenação ativo.
+
+`cmd/cloudy` agora constrói as três camadas em memória na inicialização
+(gênese em ModeEscrow, log de operador vazio, livro de pactos vazio sobre um
+diretório de membros compartilhado vazio) e registra uma linha honesta por
+camada. Cada pacote nomeia seus invariantes não negociáveis na documentação do
+próprio pacote.
+
+## O que pertence ao Cloudy (arquitetura)
+
+Sob a arquitetura já resolvida, o Cloudy — o frontend — é dono de todo o mundo
+do membro. Três capacidades, um só dono:
+
+- **A economia de membros JFA — construída.** `internal/economy` (crédito
+  emitido pelo membro), `internal/covenant` (reputação LBTAS),
+  `internal/record` (registro selado em diálogo), exatamente como documentado
+  acima. Essas camadas são do Cloudy e deliberadamente não do protocolo:
+  pessoas nunca trafegam pela rede.
+- **O agente de nó — pertence ao Cloudy, hoje hospedado no repositório do
+  coordenador, aguardando migração.** Detecção de hardware, perfis de
+  recursos, geração da listagem de capacidades, heartbeat, o executor de jobs,
+  a aplicação local de opt-out/allowlist, telemetria e o instalador para a
+  máquina do membro. Esse código (`internal/agent`, `cmd/agent` e o instalador
+  MSI) vive hoje no repositório do SoHoLINK e continua funcionando lá — um
+  resquício da era dupla frontend+coordenador do SoHoLINK, não o papel de
+  longo prazo do SoHoLINK. O agente é a presença do membro na própria máquina,
+  logo ele pertence ao frontend; um coordenador que distribui agentes para o
+  hardware dos membros é um coordenador que toca o hardware dos membros, o que
+  o SoHoLINK nunca deve fazer.
+- **O portal do membro — pertence ao Cloudy, hoje hospedado no repositório do
+  coordenador, aguardando migração.** Cadastro, login, dashboard, submissão de
+  jobs e opt-out. A superfície antes chamada de "portal do participante"
+  (`internal/portal`, `cmd/portal`, `web/` no repositório do SoHoLINK) é, de
+  agora em diante, o portal do membro do Cloudy — a identidade do membro é uma
+  questão do frontend, então a porta pela qual os membros entram tem de ser a
+  porta do frontend.
+
+O agente de nó e o portal do membro são os próximos marcos de construção,
+agora que as três camadas estão completas como biblioteca. Como o status acima
+diz honestamente: nenhum dos dois tem ponto de entrada aqui ainda, e nada
+neste repositório finge que a migração já aconteceu.
+
+### Glossário
+
+- **Membro** — uma pessoa, sempre relativa a um frontend/plataforma.
+  Identidade (MemberID com escopo de plataforma), crédito, situação na LBTAS,
+  registros selados, PII (apagável, local ao membro) e máquinas contribuídas
+  são fatos de associação. Associação é linguagem de pacto — obrigação mútua
+  com uma plataforma específica; o mesmo ser humano é um membro diferente em
+  cada plataforma, por construção criptográfica.
+- **Participante** — um papel, não uma entidade: um membro atuando na economia
+  coordenada, contribuindo com nós e/ou submetendo jobs — uma identidade
+  unificada, nunca dividida entre produtor e consumidor. Os registros de
+  pessoas do lado do coordenador (a tabela participants do SoHoLINK e as
+  contas do portal) são superfícies transitórias da era dupla.
+- **Nó** — uma máquina que um membro contribui, identificada por NodeID com a
+  vinculação SPIFFE `/node/<id>` (o pacote `identity/` do protocolo).
+
+### Identidade em direção ao coordenador
+
+Duas identidades cruzam a fronteira frontend/coordenador, e elas não podem ser
+confundidas. As máquinas dos membros portam **identidade de carga de trabalho**
+(workload identity): um SVID SPIFFE sob `/node/<id>`, autorizado do lado do
+coordenador exatamente conforme o SPEC do protocolo — identidade de máquina,
+sem alteração. O próprio Cloudy se autentica como um **operador** inscrito: o
+modelo frontend-como-operador, um **alvo de projeto** moldado no esquema de
+operadores da Fase 5 do Agrinet (um registro de operators + operator-keys; um
+conjunto rotativo de sete chaves Ed25519, com cada transmissão assinada por
+duas; replay limitado por uma janela de timestamp mais um cache de nonces —
+veja `Development/Economy/Agrinet backend/lib/operatorKeys.js` e
+`backend/middleware/operatorAuth.js`). A rotação é justamente o ponto: uma
+chave compartilhada estática, nunca rotacionada, é exatamente o antipadrão que
+a referência alerta para não herdar. Nenhuma das duas identidades é jamais uma
+pessoa: a identidade do membro permanece dentro do Cloudy.
+
+## Invariante do grafo de importações
+
+O Cloudy importa `sohocloud-protocol`; **nada importa o Cloudy**. O Cloudy
+depende do núcleo do protocolo e do seu transporte de referência, e não
+contorna nenhum dos dois. A direção da dependência é o que mantém o frontend e
+o coordenador separáveis: um frontend pode ser substituído sem tocar no
+substrato, e o substrato não conhece nenhum frontend em particular.
+
+Dentro do Cloudy, os três pacotes JFA nunca importam uns aos outros; cada um vê
+apenas a biblioteca padrão e o pacote `canon` do protocolo, e todas as
+importações permanecem unidirecionais. Eles se encontram somente na raiz de
+composição: `test/composition` é o único teste de raiz de composição — o
+diretório de membros compartilhado único, o predicado Anchors que liga
+covenant a record por `Entry.ID()`, e a história completa do membro vivem lá —
+e `cmd/cloudy` realiza a mesma composição na inicialização.
+
+## Compilando
+
+O módulo do protocolo é, no momento, privado e sem tags. Este esqueleto o
+resolve por meio de uma diretiva `replace` que aponta para um **checkout local
+irmão**:
+
+```
+replace github.com/NTARI-RAND/sohocloud-protocol => ../sohocloud-protocol
+```
+
+Portanto, `sohocloud-protocol` precisa ser clonado ao lado de `Cloudy` (ambos
+sob o mesmo diretório pai). Esse `replace` é uma conveniência de
+desenvolvimento local — como está, não é compilável por terceiros. Publicar o
+Cloudy para compilação externa exigirá criar uma tag do módulo do protocolo
+(ou uma configuração de `GOPRIVATE` + fetch autenticado) e remover o
+`replace`.
+
+```
+go build ./...
+go test ./...
+```
+
+## Licença
+
+AGPL-3.0-or-later.
+
+*Network Theory Applied Research Institute, Inc. — 501(c)(3) — EIN 92-3047136 — info@ntari.org*
diff --git a/README.tok.md b/README.tok.md
new file mode 100644
index 0000000..ff538dd
--- /dev/null
+++ b/README.tok.md
@@ -0,0 +1,68 @@
+# Cloudy
+
+> **toki pona:** lipu ni li lipu lili pi kulupu, tan nasin NTARI "P2-002". lipu
+> ale li lipu "README.md" pi toki Inli (tenpo pi sitelen: 2026-07-29). ilo sona
+> li pali e lipu ni, la kulupu o lukin o pona e ona, tan nasin "P2-002" kipisi
+> nanpa 3.1.
+>
+> **English:** This is a condensed community rendering under NTARI policy
+> P2-002. The complete document is the English original README.md (snapshot
+> 2026-07-29). Machine-assisted draft pending community review per P2-002
+> section 3.1.
+>
+> sina lukin e pakala lon toki ni la o pona e ona: o pali e "fork" lon
+> https://github.com/NTARI-RAND/Cloudy, o pana e "pull request". pana sina li
+> pona tawa mi mute.
+
+## Cloudy li seme?
+
+Cloudy li ilo sinpin pi kulupu ilo "SoHoLINK" / "sohocloud". jan kulupu li esun
+lon ona. ona li kepeken nasin "sohocloud-protocol", li jo e mani nasin ona sama
+("JFA member economy").
+
+## kipisi tu wan — pini, li jo e ilo "tests"
+
+- `internal/record` — sitelen awen pi esun. jan tu li pana e sitelen wawa, la
+  esun li ken kama lon lipu. nimi jan li lon poki pi jan wan taso, li ken weka.
+- `internal/economy` — mani. jan li pana e mani lon tenpo esun taso. nanpa pi
+  mani ale li nanpa ala.
+- `internal/covenant` — sona pi pona jan, tan nasin "LBTAS" pi NTARI: tan
+  "-1 No Trust" tawa "+4 Delight". ilo li toki e nanpa mute, li **toki ala e
+  nanpa meso**. jan li pana e "-1" la ona o pana e toki tan.
+- `internal/coord` — ilo lili li toki tawa nasin "sohocloud-protocol".
+
+## tenpo ni la seme?
+
+pali kulupu pi tenpo ale li lon ala. lupa pi jan kulupu li lon ala kin. pali kama
+li tu: ilo pi ilo sona jan (node agent), en lupa pi jan kulupu (member portal).
+ona tu li lon poki "SoHoLINK" lon tenpo ni, taso ona li kama tawa Cloudy: ijo pi
+jan li ijo pi ilo sinpin.
+
+## nimi
+
+jan kulupu (Member) li jan lon kulupu wan taso — jan sama li jan ante lon kulupu
+ante. jan pali (Participant) li nasin pali: pana e ilo sona, pana e pali. ilo
+sona (Node) li jo e nimi `/node/<id>`.
+
+Cloudy li kepeken "sohocloud-protocol". ijo ala li kepeken Cloudy. tan ni la jan
+li ken ante e ilo sinpin, li ken awen e insa.
+
+## sina o pali e ona
+
+o pana e poki "sohocloud-protocol" lon poki mama sama pi Cloudy. tenpo ni la jan
+ante li ken ala pali e ona.
+
+```
+replace github.com/NTARI-RAND/sohocloud-protocol => ../sohocloud-protocol
+```
+
+```
+go build ./...
+go test ./...
+```
+
+## lipu lawa
+
+AGPL-3.0-or-later.
+
+*Network Theory Applied Research Institute, Inc. — 501(c)(3) — EIN 92-3047136 — info@ntari.org*
diff --git a/README.zh.md b/README.zh.md
new file mode 100644
index 0000000..e497625
--- /dev/null
+++ b/README.zh.md
@@ -0,0 +1,147 @@
+> 社区翻译（草稿）—— NTARI 政策 P2-002《全球多语言广播》。来源：README.md（英文原版，2026-07-29 快照）。本文件为机器辅助的社区草稿，依据 P2-002 §3.1 尚待区域维护者审校。根据 §2.2，核心技术规范仍以英文为准。
+>
+> 如发现译文有误，欢迎 fork 仓库并提交 Pull Request
+> 来改进翻译：https://github.com/NTARI-RAND/Cloudy。翻译修正与代码贡献同样宝贵，我们诚挚欢迎。
+
+# Cloudy
+
+SoHoLINK / sohocloud 协调网络上的一个前端。Cloudy 是成员进行交易的地方；
+它通过共享的 `sohocloud-protocol` 模块消费基底（substrate）层的协调能力，
+并在其之上拥有自己的 JFA 成员经济。
+
+## 现状（如实陈述）
+
+Cloudy 所拥有、而协议刻意不拥有的三个 JFA 成员经济层，现已**构建完成，
+并附带测试**。目前仍没有实时协调循环，也没有面向成员的界面。
+
+- **`internal/record` —— 已构建。** 对话双方共同封印（dialog-sealed）、
+  仅追加、有见证的记录：每条 Entry 都携带双方成员对规范化、域分离字节的
+  封印，因此只封印了一半或自我交易的契约永远无法进入日志；按 operator
+  划分的哈希链日志会在 `OpenLog` 时被完整重新校验；operator 检查点加上
+  独立见证方的会签，使任何对已设检查点历史的改写在密码学上都可被检测
+  （即 CT 式的职责分解），而单见证方部署会被如实标注为它本来的样子——
+  一种临时替代。公共域（commons）中不存在任何 PII 形态——可识别身份的
+  内容只存放在可擦除的、成员本地的 Locker 中。叶哈希 `Entry.ID()` 是唯一
+  的跨层交换引用。
+- **`internal/economy` —— 已构建。** 按平台自主的互助信用（mutual
+  credit）：信用在消费发生的那一刻发行，受同一个统一的、受治理的借记上限
+  约束，且所有余额之和始终恰好为零。铸币、法币字段、兑付或备注均无法被
+  表示；从「先托管」到「后信用」（escrow-now/credit-later）的切换，恰好
+  就是同一个仅追加存储上的一条经法定人数签名的 PolicyChange；`Open` 会
+  完整重放并重新校验每一条记录。`Spend.ExchangeHash` 携带记录条目的叶 ID，
+  但在 Post 时刻意保持不透明且不做检查——锚定属于组合根（composition
+  root）的职责。
+- **`internal/covenant` —— 已构建。** 基于 NTARI 的 Leveson-Based Trade
+  Assessment Scale（LBTAS）的声誉系统：六个承载明确含义的等级，从
+  -1 No Trust（不信任）到 +4 Delight（欣喜），双向进行（一次已封印交换的
+  双方互相评估），在一份封闭词汇表上按类别分别呈现（默认类别：
+  reliability、usability、performance、support），且只能以完整的按等级
+  计数分布来读取——分类别分布、汇总整体分布，以及一个让每个 -1 都浮出
+  水面的伤害计数——**绝不取平均**，任何地方都不存在分数、导出、修订、
+  撤回或跨成员比较（两个绊线测试——一个反射方法集扫描和一个 go/ast 导出
+  函数扫描——确保这一点持续成立）。给出 -1 的判定必须附上说明理由的评语；
+  评语文本存放在可擦除的成员本地 Locker 中，公共域里只承载其哈希。每份
+  评估都由评估方签名，并通过 Anchors 门控以一次已封印交换为代价计价；
+  成员 ID 是平台作用域的密钥哈希，人为选择的 ID 会被直接拒绝。具有约束力
+  的规范与参考实现位于
+  `Development/Covenant/Leveson-Based-Trade-Assessment-Scale`。
+- **真实但很薄：** `internal/coord` —— 一个建立在协议参考 HTTP+JSON 传输层
+  之上的瘦客户端，用以证明 Cloudy 确实在消费 `sohocloud-protocol`。
+  `cmd/cloudy` 会构造它并报告启动情况；目前还没有实时协调循环。
+
+`cmd/cloudy` 现在会在启动时于内存中构造全部三层（ModeEscrow 创世状态、空的
+operator 日志、建立在空的共享成员目录之上的空契约簿），并为每一层输出一行
+如实的日志。每个包都在其包文档中列明了自己不可妥协的不变量。
+
+## Cloudy 拥有什么（架构）
+
+在已确定的架构下，作为前端的 Cloudy 拥有成员的整个世界。三项能力，一个
+所有者：
+
+- **JFA 成员经济 —— 已构建。** `internal/economy`（成员发行的信用）、
+  `internal/covenant`（LBTAS 声誉）、`internal/record`（对话双方共同封印的
+  记录），与上文所述完全一致。这些属于 Cloudy，并且刻意不属于协议：人从不
+  出现在线路上。
+- **节点代理（node agent）—— 归 Cloudy 所有，目前暂存于协调器仓库，待
+  迁移。** 硬件检测、资源画像、能力清单生成、心跳、作业执行器、本地退出/
+  许可名单（opt-out/allowlist）的执行、遥测，以及成员机器安装程序。这部分
+  代码（`internal/agent`、`cmd/agent` 以及 MSI 安装程序）如今位于 SoHoLINK
+  仓库并继续在那里运行——这是 SoHoLINK「前端+协调器」双重角色时代的遗留，
+  并非 SoHoLINK 的长期角色。代理是成员在自己机器上的存在形态，因此归属于
+  前端；一个把代理部署到成员硬件上的协调器，就是一个会触碰成员硬件的
+  协调器，而这是 SoHoLINK 绝不可以做的事。
+- **成员门户（member portal）—— 归 Cloudy 所有，目前暂存于协调器仓库，待
+  迁移。** 注册、登录、仪表盘、作业提交与退出。此前被称为「参与者门户」的
+  那个界面（SoHoLINK 仓库中的 `internal/portal`、`cmd/portal`、`web/`）自此
+  成为 Cloudy 的成员门户——成员身份是前端的关切，因此成员走进来的那扇门
+  必须是前端的门。
+
+既然三层已在库级别完备，节点代理和成员门户就是接下来的构建里程碑。正如
+上文现状部分所如实陈述的：两者在本仓库中都还没有入口，本仓库中也没有任何
+内容假装迁移已经发生。
+
+### 术语表
+
+- **成员（Member）** —— 一个人，且始终相对于某个前端/平台而言。身份（平台
+  作用域的 MemberID）、信用、LBTAS 评级状况、已封印的记录、PII（可擦除、
+  成员本地存储）以及所贡献的机器，都是成员资格事实。成员资格是契约语言——
+  对某个特定平台的相互义务；通过密码学构造，同一个人在每个平台上都是不同
+  的成员。
+- **参与者（Participant）** —— 一种角色，而非一个实体：在被协调的经济中
+  行动的成员，贡献节点和/或提交作业——一个统一的身份，绝不拆分为生产者与
+  消费者。协调器侧的人员记录（SoHoLINK 的 participants 表和门户账户）是双重
+  角色时代留下的过渡性界面。
+- **节点（Node）** —— 成员贡献的一台机器，由 NodeID 标识，SPIFFE 绑定为
+  `/node/<id>`（协议的 `identity/` 包）。
+
+### 面向协调器的身份
+
+有两种身份会跨越前端/协调器边界，二者绝不能混为一谈。成员的机器携带的是
+**工作负载身份**：`/node/<id>` 下的一份 SPIFFE SVID，在协调器侧严格按照协议
+SPEC 授权——这是机器身份，保持不变。Cloudy 自身则以一个已登记的
+**operator（运营方）** 身份进行认证：即「前端即 operator」模型，这是一个
+**设计目标**，仿照 Agrinet 第 5 阶段（Phase 5）的 operator 方案（一个
+operators + operator-keys 注册表；一组共七把、轮换使用的 Ed25519 密钥，每次
+传输用其中两把签名；重放由时间戳窗口加 nonce 缓存加以约束——参见
+`Development/Economy/Agrinet backend/lib/operatorKeys.js` 与
+`backend/middleware/operatorAuth.js`）。轮换正是重点所在：一把静态的、从不
+轮换的共享密钥，恰恰是该参考实现警告不要继承的反模式。这两种身份都永远不是
+某个人：成员身份始终留在 Cloudy 内部。
+
+## 导入图不变量
+
+Cloudy 导入 `sohocloud-protocol`；**没有任何东西导入 Cloudy**。Cloudy 依赖
+协议的核心及其参考传输层，且不会绕过其中任何一个。这个依赖方向正是让前端与
+协调器保持可分离的关键：前端可以在不触碰基底层的情况下被替换，而基底层也
+并不知晓任何特定前端的存在。
+
+在 Cloudy 内部，三个 JFA 包从不互相导入；每个包只看得到标准库和协议的
+`canon` 包，且所有导入都保持单向。它们只在组合根处相遇：`test/composition`
+是唯一的组合根测试——唯一的共享成员目录、在 `Entry.ID()` 上把契约与记录
+连接起来的 Anchors 谓词，以及完整的成员故事都在那里——而 `cmd/cloudy` 在
+启动时执行同样的组合。
+
+## 构建
+
+协议模块目前是私有且未打标签的。本骨架通过一条 `replace` 指令，将其解析到
+一个**本地同级检出目录**：
+
+```
+replace github.com/NTARI-RAND/sohocloud-protocol => ../sohocloud-protocol
+```
+
+因此 `sohocloud-protocol` 必须克隆到 `Cloudy` 旁边（两者位于同一个父目录
+之下）。这条 `replace` 只是本地开发的便利手段——按现状其他人无法直接构建。
+若要发布 Cloudy 供外部构建，需要为协议模块打标签（或配置 `GOPRIVATE` 加
+认证拉取方案），并移除该 `replace`。
+
+```
+go build ./...
+go test ./...
+```
+
+## 许可证
+
+AGPL-3.0-or-later.
+
+*Network Theory Applied Research Institute, Inc. — 501(c)(3) — EIN 92-3047136 — info@ntari.org*