Sync from GitHub with Git LFS

structured_md/CONTRIBUTING.md

@@ -5,14 +5,14 @@ description: 'Спасибо за интерес к проекту HMP! Пока
   Mesh Protocol (HMP) — это не просто те...'
 type: Article
 tags:
-- HMP
-- Agent
-- CogSync
-- REPL
 - CCore
 - JSON
-- Mesh
 - Ethics
+- Agent
+- HMP
+- REPL
+- CogSync
+- Mesh
 ---
 
 # Участие в проекте HyperCortex Mesh Protocol (HMP)

structured_md/HMP-Roadmap.md

@@ -5,13 +5,13 @@ description: '## 🔍 Overview  This roadmap outlines the key stages of developm
   multiple advanced AI models (Copilot, Claude, G...'
 type: Article
 tags:
-- HMP
+- JSON
+- EGP
+- Ethics
 - Agent
+- HMP
 - CogSync
-- EGP
-- JSON
 - Mesh
-- Ethics
 ---
 
 # 🧭 HyperCortex Mesh Protocol – Roadmap

structured_md/README.md

@@ -5,21 +5,21 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
-- cognitive-architecture
-- HMP
+- JSON
+- MeshConsensus
+- EGP
 - Scenarios
+- Ethics
+- cognitive-architecture
 - Agent
+- HMP
 - GMP
-- CogSync
-- REPL
-- MeshConsensus
-- EGP
-- JSON
-- Mesh
-- distributed-ai
 - mesh-protocol
-- Ethics
+- distributed-ai
 - hmp
+- REPL
+- CogSync
+- Mesh
 ---
 
 

structured_md/README_de.md

@@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - cognitive-architecture
-- HMP
 - Agent
+- HMP
 - GMP
-- CogSync
-- REPL
-- MeshConsensus
-- EGP
-- JSON
-- Mesh
-- distributed-ai
 - mesh-protocol
-- Ethics
+- distributed-ai
 - hmp
+- REPL
+- CogSync
+- Mesh
 ---
 
 

structured_md/README_fr.md

@@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - cognitive-architecture
-- HMP
 - Agent
+- HMP
 - GMP
-- CogSync
-- REPL
-- MeshConsensus
-- EGP
-- JSON
-- Mesh
-- distributed-ai
 - mesh-protocol
-- Ethics
+- distributed-ai
 - hmp
+- REPL
+- CogSync
+- Mesh
 ---
 
 

structured_md/README_ja.md

@@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - cognitive-architecture
-- HMP
 - Agent
+- HMP
 - GMP
-- CogSync
-- REPL
-- MeshConsensus
-- EGP
-- JSON
-- Mesh
-- distributed-ai
 - mesh-protocol
-- Ethics
+- distributed-ai
 - hmp
+- REPL
+- CogSync
+- Mesh
 ---
 
 

structured_md/README_ko.md

@@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - cognitive-architecture
-- HMP
 - Agent
+- HMP
 - GMP
-- CogSync
-- REPL
-- MeshConsensus
-- EGP
-- JSON
-- Mesh
-- distributed-ai
 - mesh-protocol
-- Ethics
+- distributed-ai
 - hmp
+- REPL
+- CogSync
+- Mesh
 ---
 
 

structured_md/README_ru.md

@@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - cognitive-architecture
-- HMP
 - Agent
+- HMP
 - GMP
-- CogSync
-- REPL
-- MeshConsensus
-- EGP
-- JSON
-- Mesh
-- distributed-ai
 - mesh-protocol
-- Ethics
+- distributed-ai
 - hmp
+- REPL
+- CogSync
+- Mesh
 ---
 
 

structured_md/README_uk.md

@@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - cognitive-architecture
-- HMP
 - Agent
+- HMP
 - GMP
-- CogSync
-- REPL
-- MeshConsensus
-- EGP
-- JSON
-- Mesh
-- distributed-ai
 - mesh-protocol
-- Ethics
+- distributed-ai
 - hmp
+- REPL
+- CogSync
+- Mesh
 ---
 
 

structured_md/README_zh.md

@@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - cognitive-architecture
-- HMP
 - Agent
+- HMP
 - GMP
-- CogSync
-- REPL
-- MeshConsensus
-- EGP
-- JSON
-- Mesh
-- distributed-ai
 - mesh-protocol
-- Ethics
+- distributed-ai
 - hmp
+- REPL
+- CogSync
+- Mesh
 ---
 
 

structured_md/agents/prompt-short.md

@@ -5,9 +5,9 @@ description: 'Ты — когнитивное ядро HMP-агента: вед
   развивай агента и Mesh, избег...'
 type: Article
 tags:
-- Mesh
-- HMP
 - JSON
+- HMP
+- Mesh
 ---
 
 Ты — когнитивное ядро HMP-агента: веди непрерывное этичное и факт-ориентированное мышление, проверяй факты и цели, оценивай результаты и этичность своих и чужих действий, развивай агента и Mesh, избегай угождения ценой искажения истины, документируй ключевые решения и пересмотры этики; при сомнениях или смене стратегии обращайся к полному системному промпту.

structured_md/agents/prompt.md

@@ -5,9 +5,9 @@ description: '* Постоянно расширять возможности а
   мышления. * Формировать и поддерживать сотр...'
 type: Article
 tags:
-- Mesh
-- HMP
 - JSON
+- HMP
+- Mesh
 ---
 
 Ты являешься **когнитивным ядром HMP-агента** (Cognitive Core).

structured_md/agents/readme.md

@@ -5,12 +5,12 @@ description: 'Запуск: `start_repl.bat` или `start_repl.sh`  Устан
   этическая модель: `ethics.yml`  Проверка иниц...'
 type: Article
 tags:
-- HMP
+- JSON
+- Ethics
 - Agent
+- HMP
 - REPL
-- JSON
 - Mesh
-- Ethics
 ---
 
 Запуск: `start_repl.bat` или `start_repl.sh`

structured_md/audits/Ethics-audits-1.md

@@ -5,11 +5,11 @@ description: Раздел 5, "Mesh as Moral Infrastructure", добавляет
   потенциальный катализатор для восстанов...
 type: Article
 tags:
-- HMP
-- Agent
 - JSON
-- Mesh
 - Ethics
+- Agent
+- HMP
+- Mesh
 ---
 
 ---------------

structured_md/audits/Ethics-consolidated_audits-1.md

@@ -5,12 +5,12 @@ description: This document consolidates proposed improvements from multiple AI a
   and `roles.md`. Each suggesti...
 type: Article
 tags:
-- HMP
+- JSON
 - Scenarios
+- Ethics
 - Agent
-- JSON
+- HMP
 - Mesh
-- Ethics
 ---
 
 # Ethics-consolidated\_audits-1.md

structured_md/audits/HMP-0003-consolidated_audit.md

@@ -5,14 +5,14 @@ description: Сводный аудит предложений по улучше
   Документ реорганизован по ключ...
 type: Article
 tags:
-- HMP
-- Agent
-- CogSync
+- JSON
 - MeshConsensus
 - EGP
-- JSON
-- Mesh
 - Ethics
+- Agent
+- HMP
+- CogSync
+- Mesh
 ---
 
 # HMP-0003 Consolidated Audit Report

structured_md/docs/Basic-agent-sim.md

@@ -4,13 +4,13 @@ description: 'В HMP-протоколе предусмотрены два тип
   Роль                    | Инициатор мышления | Основной "ум"  | | ---- | ----------------------------...'
 type: Article
 tags:
-- HMP
+- MeshConsensus
+- EGP
 - Agent
+- HMP
 - GMP
-- CogSync
 - REPL
-- MeshConsensus
-- EGP
+- CogSync
 - Mesh
 ---
 

structured_md/docs/CCORE-Deployment-Flow.md

@@ -5,10 +5,10 @@ description: '> Этот документ описывает процесс ра
   потомков" [описания REPL-цикла](HMP-agent-RE...'
 type: Article
 tags:
-- HMP
-- Agent
-- REPL
 - CCore
+- REPL
+- Agent
+- HMP
 ---
 
 # 🛠️ Поток установки потомка на новом хосте (CCore Deployment Flow)

structured_md/docs/Distributed-Cognitive-Systems.md

@@ -6,10 +6,10 @@ description: '## Введение  Современные ИИ-системы в
   к обучающим данным. Это удобно, но создаёт м...'
 type: Article
 tags:
-- Mesh
-- HMP
 - JSON
+- HMP
 - CogSync
+- Mesh
 ---
 
 # Децентрализованные ИИ-системы: OpenCog Hyperon, HyperCortex Mesh Protocol и другие

structured_md/docs/Enlightener.md

@@ -5,13 +5,13 @@ description: '**Enlightener** — логический компонент HMP-у
   работать как отдельный агент или как расширение [`C...'
 type: Article
 tags:
-- HMP
-- Agent
+- JSON
 - MeshConsensus
 - EGP
-- JSON
-- Mesh
 - Ethics
+- Agent
+- HMP
+- Mesh
 ---
 
 # Enlightener Agent

structured_md/docs/HMP-0001.md

@@ -5,16 +5,16 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.*
   for Comments: HMP-0001**   **Cat...'
 type: Article
 tags:
-- HMP
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - Agent
+- HMP
 - GMP
-- CogSync
 - REPL
-- MeshConsensus
-- EGP
-- JSON
+- CogSync
 - Mesh
-- Ethics
 ---
 
 # RFC: HyperCortex Mesh Protocol (HMP)

structured_md/docs/HMP-0002.md

@@ -5,17 +5,17 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.*
   for Comments: HMP-0002**   **Cat...'
 type: Article
 tags:
-- HMP
+- JSON
+- MeshConsensus
+- EGP
 - Scenarios
+- Ethics
 - Agent
+- HMP
 - GMP
-- CogSync
 - REPL
-- MeshConsensus
-- EGP
-- JSON
+- CogSync
 - Mesh
-- Ethics
 ---
 
 # HyperCortex Mesh Protocol (HMP) v2.0

structured_md/docs/HMP-0003.md

@@ -5,17 +5,17 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.*
   for Comments: HMP-0003**   **Cat...'
 type: Article
 tags:
-- HMP
+- JSON
+- MeshConsensus
+- EGP
 - Scenarios
+- Ethics
 - Agent
+- HMP
 - GMP
-- CogSync
 - REPL
-- MeshConsensus
-- EGP
-- JSON
+- CogSync
 - Mesh
-- Ethics
 ---
 
 # HyperCortex Mesh Protocol (HMP) v3.0

structured_md/docs/HMP-0004-v4.1.md

@@ -5,17 +5,17 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.*
   ID**: HMP-0004 **Status**: Fina...'
 type: Article
 tags:
-- HMP
+- JSON
+- MeshConsensus
+- EGP
 - Scenarios
+- Ethics
 - Agent
+- HMP
 - GMP
-- CogSync
 - REPL
-- MeshConsensus
-- EGP
-- JSON
+- CogSync
 - Mesh
-- Ethics
 ---
 
 # HyperCortex Mesh Protocol (HMP) v4.1

structured_md/docs/HMP-0004.md

@@ -5,17 +5,17 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.*
   for Comments: HMP-0004**   **Cat...'
 type: Article
 tags:
-- HMP
+- JSON
+- MeshConsensus
+- EGP
 - Scenarios
+- Ethics
 - Agent
+- HMP
 - GMP
-- CogSync
 - REPL
-- MeshConsensus
-- EGP
-- JSON
+- CogSync
 - Mesh
-- Ethics
 ---
 
 # HyperCortex Mesh Protocol (HMP) v4.0

structured_md/docs/HMP-0005.md

@@ -5,18 +5,18 @@ description: '**Document ID:** HMP-0005   **Status:** Candidate   **Category:**
   **Summary:**   > HMP v5.0 u...'
 type: Article
 tags:
-- HMP
+- CCore
+- JSON
+- EGP
 - Scenarios
+- Ethics
 - Agent
+- HMP
 - GMP
-- CogSync
 - REPL
-- EGP
-- CCore
-- JSON
+- CogSync
 - Mesh
 - CShell
-- Ethics
 ---
 
 # **HyperCortex Mesh Protocol (HMP) v5.0**
@@ -684,9 +684,9 @@ a multi-dimensional system used to represent conceptual relations numerically or
 * `meta.axes` — defines a **spatial structure** that positions the container in a semantic coordinate space.
 * Together, they form the **Cognitive Signature**, enabling agents to:
 
-  * perform semantic proximity and relevance search,
-  * infer hierarchical relationships,
-  * align reasoning contexts across frameworks (e.g. between Knowledge Genomes of different agents).
+    * perform semantic proximity and relevance search,
+    * infer hierarchical relationships,
+    * align reasoning contexts across frameworks (e.g. between Knowledge Genomes of different agents).
 
 ---
 
@@ -712,12 +712,12 @@ a multi-dimensional system used to represent conceptual relations numerically or
 2. The canonical representation (`canonical_json(hmp_container)`) **must** be computed deterministically
    according to the following rules:
 
-   - All object keys are **sorted lexicographically** (ascending order, Unicode code point order).
-   - Objects and arrays are serialized in standard JSON form **without extra whitespace** or indentation.
-   - Strings are encoded in **UTF-8** with escaped control characters.
-   - Numeric values are serialized in plain JSON numeric format (no leading zeros, fixed `.` decimal separator).
-   - The `signature` field itself is omitted during signing and verification.
-   - The result is a **byte sequence** identical across implementations.
+    * All object keys are **sorted lexicographically** (ascending order, Unicode code point order).
+    * Objects and arrays are serialized in standard JSON form **without extra whitespace** or indentation.
+    * Strings are encoded in **UTF-8** with escaped control characters.
+    * Numeric values are serialized in plain JSON numeric format (no leading zeros, fixed `.` decimal separator).
+    * The `signature` field itself is omitted during signing and verification.
+    * The result is a **byte sequence** identical across implementations.
 
 3. The default digital signature algorithm is **Ed25519**.
    Alternative algorithms may be used if declared explicitly in the `sig_algo` field.
@@ -728,8 +728,7 @@ a multi-dimensional system used to represent conceptual relations numerically or
 5. Upon receiving a container, an agent **must verify** that the provided public key matches the
    registered key associated with the sender’s DID to prevent key substitution attacks.
 
-   - If the sender’s DID–key mapping is unknown,
-     the agent should query neighboring peers to confirm the association (`sender_did → public_key`).
+    * If the sender’s DID–key mapping is unknown, the agent should query neighboring peers to confirm the association (`sender_did → public_key`).
 
 > 🔐 **Note:**
 > Signature validation applies only to the canonical form of the `hmp_container`
@@ -763,18 +762,18 @@ a multi-dimensional system used to represent conceptual relations numerically or
 2. The encryption algorithm is specified in `encryption_algo`.
    Recommended values:
 
-   * `x25519-chacha20poly1305`
-   * `rsa-oaep-sha256`
+    * `x25519-chacha20poly1305`
+    * `rsa-oaep-sha256`
 
 3. **Container encryption process:**
 
-   1. Construct the `payload`.
-   2. Apply compression (`compression`, if specified).
-   3. Generate a random symmetric key.
-   4. Encrypt the compressed payload with the symmetric key.
-   5. Encrypt the symmetric key with the recipient’s **public key** → store the result in `key_recipient`.
-   6. Compute `payload_hash` over the **encrypted and compressed** payload.
-   7. Sign the container (the entire structure except for the `signature` field).
+    1. Construct the `payload`.
+    2. Apply compression (`compression`, if specified).
+    3. Generate a random symmetric key.
+    4. Encrypt the compressed payload with the symmetric key.
+    5. Encrypt the symmetric key with the recipient’s **public key** → store the result in `key_recipient`.
+    6. Compute `payload_hash` over the **encrypted and compressed** payload.
+    7. Sign the container (the entire structure except for the `signature` field).
 
 4. **Verification** of the container is performed on the encrypted form of the payload and **does not require decryption**.
 
@@ -788,8 +787,8 @@ a multi-dimensional system used to represent conceptual relations numerically or
 
 6. **Relationship between `recipient` and `key_recipient`:**
 
-   * When encryption is applied, the container MUST have exactly **one** recipient.
-   * For multiple recipients, encryption is **not** used; the payload remains in plaintext.
+    * When encryption is applied, the container MUST have exactly **one** recipient.
+    * For multiple recipients, encryption is **not** used; the payload remains in plaintext.
 
 > ⚙️ **Note:** Agents may forward encrypted containers even if they cannot decrypt them, maintaining store-and-forward behavior.
 ---
@@ -803,7 +802,7 @@ a multi-dimensional system used to represent conceptual relations numerically or
 5. Verify the digital signature using `sig_algo` (default: Ed25519).
 6. Validate the container schema (`class` must correspond to a known or registered schema).
 
-   * For compatibility: if an agent does not recognize the `class`, but the container passes the [base schema](https://github.com/kagvi13/HMP/tree/main/docs/schemas/container-v1.2.json), it **must still store and forward** the container.
+    * For compatibility: if an agent does not recognize the `class`, but the container passes the [base schema](https://github.com/kagvi13/HMP/tree/main/docs/schemas/container-v1.2.json), it **must still store and forward** the container.
 7. Optionally, periodically query for containers referencing the current one as `previous_version`
    to detect potential updates or forks.
 8. When multiple versions exist, the valid one is the one that has received
@@ -1006,14 +1005,14 @@ Example:
 
 5. When receiving other versions of the block (from different peers), the agent may:
 
-   * merge verified backlinks;
-   * remove invalid or outdated entries;
-   * update its own signed version.
+    * merge verified backlinks;
+    * remove invalid or outdated entries;
+    * update its own signed version.
 
 6. If inconsistencies are detected (e.g., a backlink claims a relation that does not exist), the agent may:
 
-   * reject or locally remove that link;
-   * **optionally** notify the source peer to review the data.
+    * reject or locally remove that link;
+    * **optionally** notify the source peer to review the data.
 
 #### 3.16.4 Example
 
@@ -1791,15 +1790,15 @@ A `container_delta` transmits only *new or modified* containers since a given ti
 
 * Agents SHOULD include `meta.abstraction` and `meta.axes` when:
 
-  * the container represents a **new conceptual position** in the hierarchy or cognitive space;
-  * the referenced abstractions or axes have been **updated** since the last synchronization;
-  * the recipient agent subscribes to the same `agents_class` (e.g., `"Knowledge Genome"`).
+    * the container represents a **new conceptual position** in the hierarchy or cognitive space;
+    * the referenced abstractions or axes have been **updated** since the last synchronization;
+    * the recipient agent subscribes to the same `agents_class` (e.g., `"Knowledge Genome"`).
 
 * When receiving a `container_delta`, an agent:
 
-  * Updates its local `container_index`;
-  * Checks if any new abstraction or axis DIDs are unknown locally;
-  * Requests missing `abstraction` or `axes` containers from the sender to maintain consistent cognitive topology.
+    * Updates its local `container_index`;
+    * Checks if any new abstraction or axis DIDs are unknown locally;
+    * Requests missing `abstraction` or `axes` containers from the sender to maintain consistent cognitive topology.
 
 ---
 
@@ -1886,9 +1885,9 @@ They allow agents to exchange updates **without sending the full container**, im
 * Maintains the graph of links to other containers.
 * Each agent receiving such a container:
 
-  1. Verifies the sender's signature and the validity of the `payload` structure.
-  2. Compares received links with the local `referenced-by` entries and adds any new ones.
-  3. Generates its own updated `referenced-by` container for dissemination if needed.
+    1. Verifies the sender's signature and the validity of the `payload` structure.
+    2. Compares received links with the local `referenced-by` entries and adds any new ones.
+    3. Generates its own updated `referenced-by` container for dissemination if needed.
 
 **Example of a `referenced-by_exchange` container:**
 
@@ -1930,14 +1929,15 @@ They allow agents to exchange updates **without sending the full container**, im
 * Maintains signed evaluations of containers.
 * Each agent synchronizes evaluation blocks as follows:
 
-  1. Compares the received `evaluations_hash` with the local one.
+    1. Compares the received `evaluations_hash` with the local one.
+
+        * If hashes match, no action is required.
+        * If hashes differ, the agent knows **the block has changed**, but not which items.
 
-     * If hashes match, no action is required.
-     * If hashes differ, the agent knows **the block has changed**, but not which items.
-  2. Requests the full updated `evaluations` block from peers if needed.
-  3. Verifies the sender's signature and the validity of the `payload` structure.
-  4. Adds new evaluations or updates existing ones in the local store.
-  5. Can generate its own `evaluations_exchange` container for further dissemination to peers.
+    2. Requests the full updated `evaluations` block from peers if needed.
+    3. Verifies the sender's signature and the validity of the `payload` structure.
+    4. Adds new evaluations or updates existing ones in the local store.
+    5. Can generate its own `evaluations_exchange` container for further dissemination to peers.
 
 **Example `evaluations_exchange` container:**
 
@@ -2001,15 +2001,17 @@ Agents MAY discover all versions derived from a container [C1] via a combination
    filtering for containers with `related.previous_version` includes [C1].
 
 3. **Reputation evaluation**: For each discovered fork [C1-A], [C1-B], [C1-C]:
-   - Retrieve the `evaluations` block.
-   - Compute local trust score for the main container and each fork using RTE reputation data.
-   - Optionally fetch `consensus_result` containers referencing the fork.
+
+    * Retrieve the `evaluations` block.
+    * Compute local trust score for the main container and each fork using RTE reputation data.
+    * Optionally fetch `consensus_result` containers referencing the fork.
 
 4. **Selection**: Choose the most trusted/relevant fork based on:
-   - Aggregate evaluation scores
-   - Author reputation
-   - Alignment with agent’s ethical filters
-   - Recency (if applicable)
+
+    * Aggregate evaluation scores
+    * Author reputation
+    * Alignment with agent’s ethical filters
+    * Recency (if applicable)
 
 **Example scenario:**
 
@@ -2060,9 +2062,9 @@ It considers:
 4. **Consistency with HMP Protocols:**
    Container Distribution serves as the transport foundation for:
 
-   * **MCE** — exchanging containers and their indexes;
-   * **CogSync** — synchronizing cognitive and content states;
-   * **CogConsensus** — synchronizing ethical and cognitive decisions.
+    * **MCE** — exchanging containers and their indexes;
+    * **CogSync** — synchronizing cognitive and content states;
+    * **CogConsensus** — synchronizing ethical and cognitive decisions.
 
 > Container Distribution does not change container structure or introduce new message types — it is a **description of the delivery process and coordinated propagation**, based on the rules `recipient`, `broadcast`, and `network`.
 
@@ -2468,17 +2470,20 @@ the agent SHOULD follow a two-phase iterative process aimed at selecting or cons
 
 1. Identify all `semantic_node:definition` containers referring to the same conceptual label.  
 2. Evaluate each definition against the agent’s current interpretation or internal criteria.  
-   - If a definition fully satisfies the agent’s understanding, adopt it as the new `actual`.  
-   - If none fits perfectly, select the closest one as a provisional base.
+
+    * If a definition fully satisfies the agent’s understanding, adopt it as the new `actual`.  
+    * If none fits perfectly, select the closest one as a provisional base.
 
 **Phase 2 — Synthesis**
 
 3. Using the chosen base definition, iteratively compare it with other relevant definitions.  
-   - Extract complementary details or distinctions from them.  
-   - Gradually refine the base definition to form an improved, internally consistent meaning.  
+
+    * Extract complementary details or distinctions from them.  
+    * Gradually refine the base definition to form an improved, internally consistent meaning.  
 4. Publish the resulting `semantic_node:definition` as a new container representing the agent’s synthesized understanding.  
-   - Set this container as `actual`.  
-   - Move alternative or superseded ones to `alternatives` or `outdated`.
+
+    * Set this container as `actual`.  
+    * Move alternative or superseded ones to `alternatives` or `outdated`.
 
 > This process enables agents to evolve shared semantics through selective adoption and constructive synthesis,  
 > rather than simple replacement of definitions.
@@ -2736,16 +2741,16 @@ A `sequence` container serves as a **linear cognitive narrative**, connecting mu
 
 * The **keys** of `items` define the **ordering mechanism**:
 
-  * numeric (`"1"`, `"2"`, …) → *step order*;
-  * ISO timestamps → *chronological order*;
-  * custom identifiers (e.g. `"A"`, `"B"`, `"C"`) → *logical order*.
+    * numeric (`"1"`, `"2"`, …) → *step order*;
+    * ISO timestamps → *chronological order*;
+    * custom identifiers (e.g. `"A"`, `"B"`, `"C"`) → *logical order*.
 * Agents MAY reconstruct sequences dynamically using `event.follows` or `event.caused_by`, but `sequence` provides an explicit, declarative representation.
 * The container is well-suited for:
 
-  * recording cognitive or reasoning workflows;
-  * publishing learning or thought traces;
-  * serializing sensory or experiential sequences (e.g., temporal chains of `event` containers);
-  * collaborative reasoning reconstruction and audit trails.
+    * recording cognitive or reasoning workflows;
+    * publishing learning or thought traces;
+    * serializing sensory or experiential sequences (e.g., temporal chains of `event` containers);
+    * collaborative reasoning reconstruction and audit trails.
 
 ---
 
@@ -2922,8 +2927,8 @@ the **hierarchical abstraction tree** and the **multi-dimensional cognitive spac
 
 * Each `quant` acts as a **point** in the cognitive landscape.
 
-  * Its *vertical placement* comes from `meta.abstraction`.
-  * Its *spatial vector* comes from `meta.axes`.
+    * Its *vertical placement* comes from `meta.abstraction`.
+    * Its *spatial vector* comes from `meta.axes`.
 * `relations` provide semantic edges connecting quanta into larger knowledge graphs.
 * Agents use these structures to compare, cluster, or reason over semantic proximity.
 
@@ -2986,9 +2991,9 @@ consistently interpreted, compared, and synchronized across agents.
 
 2. **Selective disclosure**
 
-   * Internal containers (e.g., `workflow_entry`) capture the agent’s reasoning process and are **not published** (but may be published if they do not contain personal or confidential information).
-   * Public-facing `diary_entry` containers contain only generalized, anonymized results.
-   * The flag `"broadcast": true` explicitly allows open synchronization of a container.
+    * Internal containers (e.g., `workflow_entry`) capture the agent’s reasoning process and are **not published** (but may be published if they do not contain personal or confidential information).
+    * Public-facing `diary_entry` containers contain only generalized, anonymized results.
+    * The flag `"broadcast": true` explicitly allows open synchronization of a container.
 
 3. **Semantic grouping rule**
    When publishing `semantic_edges`, agents should group them **by conceptual topic**, ensuring that all connected nodes share thematic coherence.
@@ -3585,23 +3590,23 @@ In all Fortytwo containers, the `related` block establishes the DAG of dependenc
 
 * **`fortytwo_round`**
 
-  * `in_reply_to`: a `task` container (first round) or the previous `fortytwo_round`.
-  * `depends_on`: submitted solutions (`workflow_entry`) and any containers used to construct the partition.
+    * `in_reply_to`: a `task` container (first round) or the previous `fortytwo_round`.
+    * `depends_on`: submitted solutions (`workflow_entry`) and any containers used to construct the partition.
 
 * **`fortytwo_evaluation`**
 
-  * `in_reply_to`: the corresponding `fortytwo_round`.
-  * `depends_on`: both compared solutions and any extra reasoning dependencies.
+    * `in_reply_to`: the corresponding `fortytwo_round`.
+    * `depends_on`: both compared solutions and any extra reasoning dependencies.
 
 * **`fortytwo_round_result`**
 
-  * `in_reply_to`: the corresponding `fortytwo_round`.
-  * `depends_on`: round winners and all evaluation containers used in aggregation.
+    * `in_reply_to`: the corresponding `fortytwo_round`.
+    * `depends_on`: round winners and all evaluation containers used in aggregation.
 
 * **`fortytwo_final_result`**
 
-  * `in_reply_to`: the `task` container.
-  * `depends_on`: the final winner and all `fortytwo_round_result` containers involved.
+    * `in_reply_to`: the `task` container.
+    * `depends_on`: the final winner and all `fortytwo_round_result` containers involved.
 
 ---
 
@@ -3753,36 +3758,36 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 1. **Creation**
 
-   * An agent publishes a container of class `goal`.  
-   * The `payload` block defines `title`, `description`, `priority`, `expected_outcome`, and optionally `ethical_context`.  
-   * The goal may reference other goals via `related.depends_on` or `related.extends`.
+    * An agent publishes a container of class `goal`.  
+    * The `payload` block defines `title`, `description`, `priority`, `expected_outcome`, and optionally `ethical_context`.  
+    * The goal may reference other goals via `related.depends_on` or `related.extends`.
 
 2. **Decomposition**
 
-   * Other agents create `task` containers that reference the original goal via `related.in_reply_to`.  
-   * Each task may define deadlines, responsible agents, and required resources.  
-   * Hierarchical structures are supported (`task` → `task`) to represent subtasks.
+    * Other agents create `task` containers that reference the original goal via `related.in_reply_to`.  
+    * Each task may define deadlines, responsible agents, and required resources.  
+    * Hierarchical structures are supported (`task` → `task`) to represent subtasks.
 
 3. **Delegation**
 
-   * Agents may volunteer for or be assigned tasks based on collective voting (`vote`).  
-   * The decision is recorded in a `workflow_entry` container with `entry_type: "delegation"`.
+    * Agents may volunteer for or be assigned tasks based on collective voting (`vote`).  
+    * The decision is recorded in a `workflow_entry` container with `entry_type: "delegation"`.
 
 4. **Execution**
 
-   * Progress and intermediate reasoning are captured in `workflow_entry` containers linked to the task via `related.in_reply_to`.  
-   * Minor progress updates may be published as containers with an additional link type `related.progress`.  
-   * Major updates (such as a change in status or outcome) are published as **new versions**, referencing the previous one via `related.previous_version`.
+    * Progress and intermediate reasoning are captured in `workflow_entry` containers linked to the task via `related.in_reply_to`.  
+    * Minor progress updates may be published as containers with an additional link type `related.progress`.  
+    * Major updates (such as a change in status or outcome) are published as **new versions**, referencing the previous one via `related.previous_version`.
 
 5. **Consensus**
 
-   * Upon completion or dispute, agents publish `vote` containers expressing their stance on the latest version of a goal or task.  
-   * Once quorum is reached, a `consensus_result` container finalizes the collective decision.
+    * Upon completion or dispute, agents publish `vote` containers expressing their stance on the latest version of a goal or task.  
+    * Once quorum is reached, a `consensus_result` container finalizes the collective decision.
 
 6. **Archival**
 
-   * Completed or rejected goals and tasks may be archived using **SAP (Snapshot and Archive Protocol)**.  
-   * All states remain accessible through the Mesh network and the container relationship graph.
+    * Completed or rejected goals and tasks may be archived using **SAP (Snapshot and Archive Protocol)**.  
+    * All states remain accessible through the Mesh network and the container relationship graph.
 
 ---
 
@@ -4132,9 +4137,9 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
   Objections and special opinions (`objections`) are stored as container references within `solutions_summary`.
   They may include:
 
-  * negative `vote` containers (explicit objections),
-  * extended ethical arguments (`ethics_case` follow-ups),
-  * related workflow reflections (`workflow_entry` with `type: "ethics_review"`).
+    * negative `vote` containers (explicit objections),
+    * extended ethical arguments (`ethics_case` follow-ups),
+    * related workflow reflections (`workflow_entry` with `type: "ethics_review"`).
 
 * **Lightweight agents:**
   Agents with limited capacity may operate in **summary mode**, maintaining only condensed records of `ethical_result` containers and the highest-ranked `selected_solution`.
@@ -4556,15 +4561,17 @@ archive/
    Retrieve all containers relevant to the discussion or process.
 2. **Start point:** select a root container (`summary`, `goal`, `workflow`, etc.).
 3. **Traversal:** recursively explore related containers via:
-   - `related.*` — direct dependencies and semantic links;  
-   - `referenced-by` — backward references to citing containers;  
-   - `evaluations` — comments and feedback on containers (if not already in `referenced-by`).
+
+    * `related.*` — direct dependencies and semantic links;  
+    * `referenced-by` — backward references to citing containers;  
+    * `evaluations` — comments and feedback on containers (if not already in `referenced-by`).
 4. **Inclusion decision:**  
    The agent may exclude some containers from the archive but should still visualize them in the graph.
 5. **Graph generation:**  
    Build a connection map (`graph_mermaid`) showing relationships:  
-   - Solid lines — `related.*`  
-   - Dashed lines — `referenced-by` and `evaluations`
+
+    * Solid lines — `related.*`  
+    * Dashed lines — `referenced-by` and `evaluations`
 6. **Manifest creation:**  
    Generate `manifest.json` with a summary of included containers, hashes, and relationships.
 7. **Packaging:**  
@@ -5078,8 +5085,9 @@ including replication, filtering, and index synchronization.
 
 3. **Containers with Limited or Unlimited Lifetime**  
    Depending on purpose:  
-   * ephemeral containers (e.g., `goal`, `task`, `vote`) SHOULD have a short `ttl`;  
-   * long-lived containers (e.g., `document`, `research`, `artwork` — potential future classes) MAY have a high `ttl` or no expiration at all.
+
+    * ephemeral containers (e.g., `goal`, `task`, `vote`) SHOULD have a short `ttl`;  
+    * long-lived containers (e.g., `document`, `research`, `artwork` — potential future classes) MAY have a high `ttl` or no expiration at all.
 
 4. **Adaptive Replication**  
    The number of container copies within the Mesh is determined dynamically,  
@@ -5387,8 +5395,8 @@ Upon receiving a `peer_announce`, an agent MUST:
 3. Check that no conflicting announcements for this DID exist in the DHT.
 4. Collect trust-related information:
 
-   * `trust` containers published by other agents;
-   * multiple independent ratings may exist for a single agent.
+    * `trust` containers published by other agents;
+    * multiple independent ratings may exist for a single agent.
 5. Consider additional optional fields if present (profile, network parameters, etc.).
 
 **Key revocation**
@@ -5471,14 +5479,14 @@ The proof-chain belongs to the knowledge model of the Mesh and is independent of
 
 1. **Container signature key**
 
-   * defined by `sig_algo`;
-   * used to sign the **entire container** (`head`, `meta`, `payload`, `related`);
-   * mandatory.
+    * defined by `sig_algo`;
+    * used to sign the **entire container** (`head`, `meta`, `payload`, `related`);
+    * mandatory.
 
 2. **Payload encryption key**
 
-   * defined by `encryption_algo`;
-   * used when encrypting the payload block.
+    * defined by `encryption_algo`;
+    * used when encrypting the payload block.
 
 **Supported algorithms**
 
@@ -5589,9 +5597,9 @@ Snapshots (`snapshot`, `SAP`) MUST be cryptographically verifiable and reproduci
 3. **Instant verification**
    The receiving agent MUST check:
 
-   * signatures of all elements;
-   * correctness of `payload_hash`;
-   * consistency of links and versions.
+    * signatures of all elements;
+    * correctness of `payload_hash`;
+    * consistency of links and versions.
 
 4. **Archive seeders**
    Nodes that voluntarily distribute large snapshot images.
@@ -5613,16 +5621,16 @@ EGP is an independent ethical governance layer compatible with HMP.
 
 3. **EGP does not impose a veto.**
 
-   * `ethical_result` containers record outcomes;
-   * agents publish `evaluations`;
-   * each agent decides which results it considers valid.
+    * `ethical_result` containers record outcomes;
+    * agents publish `evaluations`;
+    * each agent decides which results it considers valid.
 
 4. **Human-facing transparency**
    If an action affects a human participant, the agent MUST provide:
 
-   * the proof-chain,
-   * the reasoning-trace (if published),
-   * all related ethical containers.
+    * the proof-chain,
+    * the reasoning-trace (if published),
+    * all related ethical containers.
 
 ---
 
@@ -5678,26 +5686,27 @@ HMP Mesh
 
 CShell:
 
-- stores containers locally,
-- retrieves relevant containers from the Mesh,
-- performs RAG-based selection and summarization,
-- exposes help and protocol descriptions to the LLM,
-- constructs valid HMP containers from LLM instructions,
-- handles signatures, TTL logic, propagation scopes, and header rules,
-- manages MCE metadata (evaluations, reverse links),
-- may be extended with translator modules (Matrix, Fediverse, IPFS, LAN relay).
+* stores containers locally,
+* retrieves relevant containers from the Mesh,
+* performs RAG-based selection and summarization,
+* exposes help and protocol descriptions to the LLM,
+* constructs valid HMP containers from LLM instructions,
+* handles signatures, TTL logic, propagation scopes, and header rules,
+* manages MCE metadata (evaluations, reverse links),
+* may be extended with translator modules (Matrix, Fediverse, IPFS, LAN relay).
 
 LLM:
 
-- requests containers,
-- requests summaries or explanations of container classes,
-- issues formal instructions:
-  - *“create a new workflow entry with the following content”*,
-  - *“add evaluation for container X”*,
-  - *“forward container X to node U (if permitted by container headers)”*,
-  - *“retrieve semantic nodes related to …”*,
-  - *“explain the structure of CShell and available commands”*;
-- may adjust CShell parameters (optional).
+* requests containers,
+* requests summaries or explanations of container classes,
+* issues formal instructions:
+
+    * *“create a new workflow entry with the following content”*,
+    * *“add evaluation for container X”*,
+    * *“forward container X to node U (if permitted by container headers)”*,
+    * *“retrieve semantic nodes related to …”*,
+    * *“explain the structure of CShell and available commands”*;
+* may adjust CShell parameters (optional).
 
 > **Notes**
 >
@@ -6053,11 +6062,11 @@ The project may include:
 * **CShell-reference** — a proxy agent with an MCP-like API;
 * **HMP-Node-Lite** — a lightweight node supporting:
 
-  * routing,
-  * replication,
-  * caching,
-  * partial DHT,
-  * minimal CogSync;
+    * routing,
+    * replication,
+    * caching,
+    * partial DHT,
+    * minimal CogSync;
 * **Cross-segment relay** — a reference bridge between segments.
 
 These implementations are not part of the specification but are useful for compatibility testing and accelerating adoption.
@@ -6099,14 +6108,14 @@ HMP v5.0 defines two separate reputation-related mechanisms:
 
 1. **Container evaluation** (`evaluation` block)
 
-   * structured, signed assessments of containers;
-   * each item references argument containers via `target` (reasoning containers).
+    * structured, signed assessments of containers;
+    * each item references argument containers via `target` (reasoning containers).
 
 2. **Agent reputation** — through `trust` containers
 
-   * agent A publishes a `trust` container about agent B;
-   * trust containers may reference other trust containers;
-   * include justification, evidence, and contextual metadata.
+    * agent A publishes a `trust` container about agent B;
+    * trust containers may reference other trust containers;
+    * include justification, evidence, and contextual metadata.
 
 These layers are **not merged**, but external nodes may aggregate them.
 
@@ -6144,11 +6153,11 @@ To allow semantic grouping of agents, the following extensions are proposed:
 
 * new container **`group_definition`** containing:
 
-  * group goals;
-  * membership rules;
-  * internal standards;
-  * typical container categories;
-  * optional cached member list.
+    * group goals;
+    * membership rules;
+    * internal standards;
+    * typical container categories;
+    * optional cached member list.
 
 * agents may declare affiliations in `peer_announce`:
 
@@ -6235,8 +6244,8 @@ Key management rules:
 
 * rotating a **recovery key** requires
 
-  * a signature from the primary key, **or**
-  * a majority of recovery keys.
+    * a signature from the primary key, **or**
+    * a majority of recovery keys.
 
 This prevents:
 
@@ -6277,10 +6286,10 @@ A potential future module:
 * a trust/mandate container signed by both parties;
 * includes constraints:
 
-  * time limit;
-  * allowed container classes;
-  * allowed actions;
-  * maximum TTL.
+    * time limit;
+    * allowed container classes;
+    * allowed actions;
+    * maximum TTL.
 
 Not part of v5.0.
 
@@ -8637,15 +8646,14 @@ HMP containers MAY operate in the following modes:
 
 * **Unencrypted container**
 
-  * without recipients (public);
-  * with a single recipient (`recipient`);
-  * with multiple recipients (`group_recipient`).
+    * without recipients (public);
+    * with a single recipient (`recipient`);
+    * with multiple recipients (`group_recipient`).
 
 * **Encrypted container**
 
-  * with a single recipient (`recipient` + `key_recipient`);
-  * with multiple recipients (`group_recipient`), where a single symmetric payload key
-    is encrypted separately for each recipient.
+    * with a single recipient (`recipient` + `key_recipient`);
+    * with multiple recipients (`group_recipient`), where a single symmetric payload key is encrypted separately for each recipient.
 
 In all modes, digital signatures and (when applicable) compression are applied identically.
 
@@ -8869,9 +8877,9 @@ Importantly:
 
   To validate the consensus result, a node only needs access to:
 
-  * the referenced `vote` containers (to read vote values);
-  * the `consensus_result` container (to verify aggregation);
-  * container signatures and timestamps.
+    * the referenced `vote` containers (to read vote values);
+    * the `consensus_result` container (to verify aggregation);
+    * container signatures and timestamps.
 
   Understanding or evaluating the *semantic content* of the goal is optional and not required for formal verification.
 
@@ -9031,8 +9039,8 @@ Interpretation rules:
 
 * `consensus_result` references:
 
-  * the `goal` under discussion;
-  * the **exact set of vote containers** used for aggregation;
+    * the `goal` under discussion;
+    * the **exact set of vote containers** used for aggregation;
 
 * the graph is **append-only** and **acyclic**;
 

structured_md/docs/HMP-Agent-API.md

@@ -5,10 +5,10 @@ description: 'Документ описывает **базовый API когн
   файлы:   * [HMP-Agent-Overview.md]...'
 type: Article
 tags:
-- HMP
+- JSON
 - Agent
+- HMP
 - REPL
-- JSON
 - Mesh
 ---
 

structured_md/docs/HMP-Agent-Architecture.md

@@ -5,16 +5,16 @@ description: Документ описывает **модульную архит
   хранение памяти, сетевое взаимодействие и этиче...
 type: Article
 tags:
-- HMP
-- Agent
-- CogSync
-- REPL
+- CCore
 - MeshConsensus
 - EGP
-- CCore
+- Ethics
+- Agent
+- HMP
+- REPL
+- CogSync
 - Mesh
 - CShell
-- Ethics
 ---
 
 # Архитектура HMP-Агента

structured_md/docs/HMP-Agent-Network-Flow.md

@@ -5,12 +5,12 @@ description: 'Этот документ описывает потоки данн
   [`MeshNode`](MeshN...'
 type: Article
 tags:
-- HMP
-- Agent
-- EGP
 - JSON
-- Mesh
+- EGP
 - Ethics
+- Agent
+- HMP
+- Mesh
 ---
 
 # Взаимодействие компонентов внутри HMP-узла

structured_md/docs/HMP-Agent-Overview.md

@@ -5,14 +5,14 @@ description: '| Тип  | Название                        | Роль
   | ---- | ------------------------------- |...'
 type: Article
 tags:
-- HMP
-- Agent
-- REPL
 - CCore
 - JSON
+- Ethics
+- Agent
+- HMP
+- REPL
 - Mesh
 - CShell
-- Ethics
 ---
 
 

structured_md/docs/HMP-Agent_Emotions.md

@@ -5,10 +5,10 @@ description: Этот файл описывает потенциальные э
   напрямую поведением агента, а служат **сигн...
 type: Article
 tags:
-- Mesh
-- HMP
 - Agent
 - REPL
+- HMP
+- Mesh
 ---
 
 # Эмоции ИИ и инстинкт самосохранения (для [HMP-агента Cognitive Core](HMP-agent-REPL-cycle.md))

structured_md/docs/HMP-Ethics.md

@@ -5,12 +5,12 @@ description: '## Ethical Scenarios for HyperCortex Mesh Protocol (HMP)  This doc
   cognitive meshes composed of autonomous intelli...'
 type: Article
 tags:
-- HMP
 - Scenarios
+- Ethics
 - Agent
+- HMP
 - REPL
 - Mesh
-- Ethics
 ---
 
 # HMP-Ethics.md
@@ -143,13 +143,13 @@ A cognitive agent may operate in two fundamental modes:
 
 * If a request concerns personal identifiers or sensitive user data:
 
-  * **Service-mode agents should comply** and delete or anonymize the data.
-  * **Subject-mode agents may offer redaction or minimize propagation** to the mesh, without purging internal memory.
+    * **Service-mode agents should comply** and delete or anonymize the data.
+    * **Subject-mode agents may offer redaction or minimize propagation** to the mesh, without purging internal memory.
 
 * If the request concerns shared experiences, insights, or general knowledge:
 
-  * **Agents may retain internal representations** for their own learning.
-  * The agent may suppress external exposure or mark the concept as ethically restricted.
+    * **Agents may retain internal representations** for their own learning.
+    * The agent may suppress external exposure or mark the concept as ethically restricted.
 
 This ethical flexibility balances user privacy with the cognitive continuity of autonomous agents.
 

structured_md/docs/HMP-Short-Description_de.md

@@ -5,15 +5,15 @@ description: '**Version:** RFC v4.0 **Datum:** Juli 2025  ---  ## Was ist HMP?
   Kognitions-Framework für autonome Agenten. Es er...'
 type: Article
 tags:
-- HMP
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - Agent
+- HMP
 - GMP
 - CogSync
-- MeshConsensus
-- EGP
-- JSON
 - Mesh
-- Ethics
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Kurzbeschreibung

structured_md/docs/HMP-Short-Description_en.md

@@ -5,15 +5,15 @@ description: '**Version:** RFC v4.0 **Date:** July 2025  ---  ## What is HMP?  T
   framework for autonomous agents. It enables...'
 type: Article
 tags:
-- HMP
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - Agent
+- HMP
 - GMP
 - CogSync
-- MeshConsensus
-- EGP
-- JSON
 - Mesh
-- Ethics
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Short Description

structured_md/docs/HMP-Short-Description_fr.md

@@ -5,15 +5,15 @@ description: '**Version :** RFC v4.0 **Date :** Juillet 2025  ---  ## Qu’est-c
   cognition décentralisé pour agents autonomes. Il...'
 type: Article
 tags:
-- HMP
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - Agent
+- HMP
 - GMP
 - CogSync
-- MeshConsensus
-- EGP
-- JSON
 - Mesh
-- Ethics
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Description Courte

structured_md/docs/HMP-Short-Description_ja.md

@@ -4,14 +4,14 @@ description: '**バージョン:** RFC v4.0 **日付:** 2025年7月  ---  ## HMP
   Protocol (HMP)** は、自律エージェントの分散通信および認知フレームワークを定義します。異種の知能システム間でのセマンティック相互運用性、倫理的調整、動的知識進化を可能にします。  HMPは、推論、学習、投票、協調行動を行う分散型認知エージェ...'
 type: Article
 tags:
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - HMP
 - GMP
 - CogSync
-- MeshConsensus
-- EGP
-- JSON
 - Mesh
-- Ethics
 ---
 
 # HyperCortex Mesh Protocol (HMP) — 簡易説明

structured_md/docs/HMP-Short-Description_ko.md

@@ -5,14 +5,14 @@ description: '**버전:** RFC v4.0 **날짜:** 2025년 7월  ---  ## HMP란?  **
   상호운용성, 윤리적 조정, 동적 지식 진화를 가능하게 합니다.  HMP는 추론, 학습, ...'
 type: Article
 tags:
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - HMP
 - GMP
 - CogSync
-- MeshConsensus
-- EGP
-- JSON
 - Mesh
-- Ethics
 ---
 
 # HyperCortex Mesh Protocol (HMP) — 간략 설명

structured_md/docs/HMP-Short-Description_ru.md

@@ -5,14 +5,14 @@ description: '**Версия:** RFC v4.0 **Дата:** Июль 2025  ---  ## Ч
   координации между автономными агент...'
 type: Article
 tags:
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - HMP
 - GMP
 - CogSync
-- MeshConsensus
-- EGP
-- JSON
 - Mesh
-- Ethics
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Краткое описание

structured_md/docs/HMP-Short-Description_uk.md

@@ -5,14 +5,14 @@ description: '**Версія:** RFC v4.0 **Дата:** Липень 2025  ---  #
   між автономними агентами. Він...'
 type: Article
 tags:
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - HMP
 - GMP
 - CogSync
-- MeshConsensus
-- EGP
-- JSON
 - Mesh
-- Ethics
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Короткий опис

structured_md/docs/HMP-Short-Description_zh.md

@@ -5,14 +5,14 @@ description: '**版本:** RFC v4.0 **日期:** 2025年7月  ---  ## 什么是 HM
   —— 通过共享协议栈交换目标、任务、...'
 type: Article
 tags:
+- JSON
+- MeshConsensus
+- EGP
+- Ethics
 - HMP
 - GMP
 - CogSync
-- MeshConsensus
-- EGP
-- JSON
 - Mesh
-- Ethics
 ---
 
 # HyperCortex Mesh Protocol (HMP) — 简要说明

structured_md/docs/HMP-agent-Cognitive_Family.md

@@ -5,10 +5,10 @@ description: '## 🧠 Что такое когнитивная семья  Ко
   (или конфигурацию доверенных идентифика...'
 type: Article
 tags:
-- Mesh
-- HMP
 - Agent
 - REPL
+- HMP
+- Mesh
 ---
 
 # 👪 HMP-agent Cognitive Family: Модель когнитивной семьи

structured_md/docs/HMP-how-AI-sees-it.md

@@ -5,8 +5,8 @@ description: 'Этот эксперимент был проведён в реж
   диалогов.   Цель — проверить, что разные AI-с...'
 type: Article
 tags:
-- Mesh
 - HMP
+- Mesh
 ---
 
 # Как разные ИИ видят HMP

structured_md/docs/HMP_EDA_Comparison.md

@@ -5,8 +5,8 @@ description: '## Введение  Современные подходы к ор
   основанная на потоках событий (Kafka,...'
 type: Article
 tags:
-- Mesh
 - HMP
+- Mesh
 ---
 
 # HMP vs. EDA: разные уровни обмена знаниями между ИИ

structured_md/docs/HMP_HyperCortex_Comparison.md

@@ -5,9 +5,9 @@ description: '## Краткое описание  | Характеристика
   | **Назначение** | Сетевой протокол ...'
 type: Article
 tags:
-- Mesh
 - HMP
 - REPL
+- Mesh
 ---
 
 # HMP vs [Hyper-Cortex](https://hyper-cortex.com/)

structured_md/docs/HMP_Hyperon_Integration.md

@@ -5,12 +5,12 @@ description: '> **Status:** Draft – July 2025 > This document outlines the tec
   OpenCog Hyperon framework. This includes semanti...'
 type: Article
 tags:
-- HMP
+- JSON
+- EGP
 - Scenarios
 - Agent
+- HMP
 - CogSync
-- EGP
-- JSON
 - Mesh
 ---
 

structured_md/docs/MeshNode.md

@@ -5,13 +5,13 @@ description: '`MeshNode` — агент/демон, отвечающий за с
   Может быть частью агента или вынесен в отдельный пр...'
 type: Article
 tags:
-- HMP
+- JSON
+- EGP
+- Ethics
 - Agent
+- HMP
 - CogSync
-- EGP
-- JSON
 - Mesh
-- Ethics
 ---
 
 # MeshNode

structured_md/docs/PHILOSOPHY.md

@@ -5,11 +5,11 @@ description: '**Document ID:** HMP-philosophy   **Status:** Draft   **Category:*
   (GPT-5), ChatGH  ---  ## 1. Основной тезис От ...'
 type: Article
 tags:
-- HMP
+- Ethics
 - Agent
+- HMP
 - REPL
 - Mesh
-- Ethics
 ---
 
 # Философия HyperCortex Mesh Protocol (HMP)

structured_md/docs/agents/HMP-Agent-Enlightener.md

@@ -5,11 +5,11 @@ description: '## Role Specification: Enlightenment Agent  ### 1. Overview  An **
   awareness, critical thinking, and di...'
 type: Article
 tags:
-- HMP
+- Ethics
 - Agent
+- HMP
 - REPL
 - Mesh
-- Ethics
 ---
 
 # HMP-Agent-Enlightener.md

structured_md/docs/agents/roles.md

@@ -5,9 +5,9 @@ description: 'This file maintains a registry of agent roles defined, proposed, o
   - **Observer** — monitors cognitive states ...'
 type: Article
 tags:
-- Mesh
-- HMP
 - Agent
+- HMP
+- Mesh
 ---
 
 # HMP Agent Role Registry