Sync from GitHub with Git LFS

docs/HMP-0005.md

@@ -1,6 +1,6 @@
 # HyperCortex Mesh Protocol (HMP)
 
-**Version: 5.0.5**  
+**Version: 5.0.6**  
 **Document ID:** HMP-0005  
 **Status:** Stable  
 **Category:** Core Specification  
@@ -219,9 +219,7 @@ flowchart TD
     end
 ```
 
-Each reasoning cycle begins in the **Cognitive Layer**,  
-is encapsulated into a signed container in the **Container Layer**,  
-and then propagated, discovered, or verified in the **Network Layer**.  
+Each reasoning cycle begins in the **Cognitive Layer**, is encapsulated into a signed container in the **Container Layer**, and then propagated, discovered, or verified in the **Network Layer**.  
 
 Containers thus serve as both the **interface** and the **boundary** between cognition and communication.
 
@@ -458,6 +456,8 @@ The unified container structure provides:
 
 > *Agents MAY include non-standard fields in `head`, `meta` or `payload`; unrecognized fields MUST be safely ignored during deserialization and propagation.*
 
+> Fields defined as `head.*` in Sections 3.3 and 3.4 MUST appear exclusively within the `head` object and MUST NOT be relocated outside of it.
+
 > Signature MUST be computed over the canonical serialized form of `hmp_container` (excluding signature itself).
 
 > *Note: For readability, most examples in this specification show only the `head` and `payload` sections (often in a truncated version). Full containers may additionally include `meta`, `related`, `evaluations`, and `referenced-by` blocks.*
@@ -515,11 +515,11 @@ The unified container structure provides:
 | `meta.abstraction`          | object        | Describes the **hierarchical position** of the container within a cognitive or semantic model (e.g. the Knowledge Genome’s L1–L5 structure). Defines which abstraction layers the container belongs to and their relationships. |
 | `meta.axes`                 | object        | Defines the **coordinate position** of the container within a cognitive space. Each key represents a semantic axis (e.g., `axis-logos`), and its value defines the container’s coordinate on that axis. |
 
+> Absent fields MUST NOT be serialized as null unless explicitly required by the schema.
+
 > 💡 **Note:**
 > Both `referenced-by` and `evaluations` are **virtual, locally extended blocks**.
-> They are not included in the cryptographically signed portion of the container (`hmp_container`),
-> allowing agents to maintain and exchange additional contextual or social metadata without modifying
-> the original, immutable container structure.
+> They are not included in the cryptographically signed portion of the container (`hmp_container`), allowing agents to maintain and exchange additional contextual or social metadata without modifying the original, immutable container structure.
 
 ---
 
@@ -576,8 +576,7 @@ Custom or experimental classes SHOULD document their payloads using the followin
 
 ### 3.6 Cognitive meta-structures (`meta`)
 
-The `meta` section defines the **cognitive identity** of a container — its provenance, reasoning origin, and semantic coordinates  
-within both the *hierarchical abstraction tree* and the *cognitive space* (axes model).
+The `meta` section defines the **cognitive identity** of a container — its provenance, reasoning origin, and semantic coordinates within both the *hierarchical abstraction tree* and the *cognitive space* (axes model).
 
 It combines three layers of information:
 
@@ -668,8 +667,7 @@ It reflects the logical or conceptual ancestry within the agent’s internal kno
 
 #### Structure: `meta.axes`
 
-The `axes` block defines **the spatial or semantic coordinates** of the container in the cognitive space —
-a multi-dimensional system used to represent conceptual relations numerically or topologically.
+The `axes` block defines **the spatial or semantic coordinates** of the container in the cognitive space — a multi-dimensional system used to represent conceptual relations numerically or topologically.
 
 **Structure:**
 
@@ -689,8 +687,7 @@ a multi-dimensional system used to represent conceptual relations numerically or
 
 > 💡 **Interpretation:**
 > Each axis defines an independent semantic dimension.
-> Together, they form a vector representation of the container’s cognitive “position” —
-> enabling reasoning based on semantic proximity, clustering, or gradient-based knowledge inference.
+> Together, they form a vector representation of the container’s cognitive “position” — enabling reasoning based on semantic proximity, clustering, or gradient-based knowledge inference.
 
 ---
 
@@ -709,27 +706,23 @@ a multi-dimensional system used to represent conceptual relations numerically or
 #### Notes
 
 * Both `meta.abstraction` and `meta.axes` **may include `agents_class`** if different from the parent `meta`.
-* Updates to referenced containers (e.g. `abstraction` or `axes`) **do not alter** existing containers automatically —
-  agents must periodically verify linked versions and synchronize updates.
+* Updates to referenced containers (e.g. `abstraction` or `axes`) **do not alter** existing containers automatically — agents must periodically verify linked versions and synchronize updates.
 * Agents are encouraged to cache and periodically refresh cognitive maps to maintain coherence.
-* The combination of `meta.abstraction` and `meta.axes` defines a full **Cognitive Position Vector** —
-  the unique, reproducible semantic coordinates of a container within the Mesh.
+* The combination of `meta.abstraction` and `meta.axes` defines a full **Cognitive Position Vector** — the unique, reproducible semantic coordinates of a container within the Mesh.
 
 ---
 
 ### 3.7 Container signature
 
-1. The **digital signature** applies to the canonical JSON representation of the entire `hmp_container` object,  
-   **excluding** the `signature` field itself.
+1. The **digital signature** applies to the canonical JSON representation of the entire `hmp_container` object, **excluding** the `signature` field itself.
 
-   This ensures that all metadata, relations, and payload hashes are **cryptographically bound** and cannot be
-   modified without invalidating the signature.
+   This ensures that all metadata, relations, and payload hashes are **cryptographically bound** and cannot be modified without invalidating the signature.
 
-2. The canonical representation (`canonical_json(hmp_container)`) **must** be computed deterministically
-   according to the following rules:
+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.
+    * Array order MUST be preserved and treated as significant.
     * 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.
@@ -738,17 +731,14 @@ a multi-dimensional system used to represent conceptual relations numerically or
 3. The default digital signature algorithm is **Ed25519**.
    Alternative algorithms may be used if declared explicitly in the `sig_algo` field.
 
-4. If the container includes a `public_key` field, signature verification **may be performed locally**,
-   without consulting a global DID registry.
+4. If the container includes a `public_key` field, signature verification **may be performed locally**, without consulting a global DID registry.
 
-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.
+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`).
 
 > 🔐 **Note:**
-> Signature validation applies only to the canonical form of the `hmp_container`
-> and does **not cover** dynamically generated or external fields such as `referenced-by` or `evaluations`.
+> Signature validation applies only to the canonical form of the `hmp_container` and does **not cover** dynamically generated or external fields such as `referenced-by` or `evaluations`.
 > This allows agents to augment the local knowledge graph without altering the immutable container core.
 
 ---
@@ -761,13 +751,11 @@ a multi-dimensional system used to represent conceptual relations numerically or
 2. **Compression is performed before computing** the `payload_hash` and generating the `signature`.
    This ensures that both the hash and signature refer to the compressed representation of the payload.
 
-3. For verification, the payload must be **decompressed first**,
-   after which the hash is recalculated and compared against the stored `payload_hash`.
+3. For verification, the payload must be **decompressed first**, after which the hash is recalculated and compared against the stored `payload_hash`.
 
 > ⚙️ **Implementation note:**
 > Agents must advertise supported compression algorithms during the handshake phase
-> Unsupported containers should still be stored and relayed unmodified
-> in “store & forward” mode.
+> Unsupported containers should still be stored and relayed unmodified in “store & forward” mode.
 
 ---
 
@@ -809,20 +797,32 @@ a multi-dimensional system used to represent conceptual relations numerically or
 > ⚙️ **Note:** Agents may forward encrypted containers even if they cannot decrypt them, maintaining store-and-forward behavior.
 ---
 
-### 3.10 Container verification
+### 3.10 Container Verification
+
+Before performing any semantic interpretation, reasoning, execution, or trust evaluation, implementations MUST validate the structural integrity of the container.
+
+Containers that fail structural validation MUST be rejected and MUST NOT be passed to any reasoning or LLM-based subsystem.
+
+The verification procedure SHOULD follow this order:
+
+1. Validate structural compliance with the base container schema, including the presence of all required fields.
+
+2. Validate `timestamp` (MUST NOT be in the future beyond acceptable clock skew).
 
-1. Check for the presence of all required fields.
-2. Validate `timestamp` (must not be in the future).
 3. If `ttl` is set — mark the container as **expired** after its expiration time.
-4. Compute `sha256(payload)` and compare with the stored `payload_hash`.
+   Expired containers MAY be stored for archival purposes but MUST NOT participate in consensus or active workflows.
+
+4. Compute `sha256(payload)` and compare it with the stored `payload_hash`.
+
 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.
-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
-   **confirmation from a majority of trusted nodes (consensus at DHT level).**
+6. Validate the container class (`class`) against a known or registered schema.
+
+    * For compatibility: if an agent does not recognize the `class`, but the container passes the base container schema, 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 version is the one that has received confirmation from a majority of trusted nodes (consensus at DHT level).
 
 ---
 
@@ -831,12 +831,10 @@ a multi-dimensional system used to represent conceptual relations numerically or
 Any container can serve as a **context** (`in_reply_to`) for another container.
 This enables a unified structural model for **discussions**, **votes**, **messages**, **hypotheses**, **arguments**, and other forms of cognitive exchange.
 
-Chains of `in_reply_to` form a **dialectical reasoning tree**, where each branch represents an evolution of thought —
-a clarification, counterpoint, or refinement of a previous idea.
+Chains of `in_reply_to` form a **dialectical reasoning tree**, where each branch represents an evolution of thought — a clarification, counterpoint, or refinement of a previous idea.
 This makes HMP discussions and consensus processes inherently **non-linear**, **self-referential**, and **evolving**.
 
-> In essence, **all interactions between agents in HMP** are represented as an interconnected web of containers,
-> collectively forming a **cognitive graph of reasoning**.
+> In essence, **all interactions between agents in HMP** are represented as an interconnected web of containers, collectively forming a **cognitive graph of reasoning**.
 
 ---
 
@@ -853,8 +851,7 @@ This mechanism preserves the continuity and traceability of meaning across updat
   In such scenarios, branch priority or relevance is determined via local heuristics or consensus mechanisms.
 * Divergent descendants are treated as **semantic forks** — parallel evolutions of a shared idea within the distributed cognitive graph.
 
-> Versioning in HMP thus reflects not only data persistence,  
-> but also the *evolution of ideas* across agents and time.
+> Versioning in HMP thus reflects not only data persistence, but also the *evolution of ideas* across agents and time.
 
 ---
 
@@ -1182,8 +1179,7 @@ It allows restricting the delivery scope of a container and defines which transm
 | `"lan:192.168.0.0/24"`  | The container is intended for agents within the specified local subnet.                     |
 
 > ⚠️ **Note:**  
-> When a container is restricted by the `network` field (e.g., `localhost` or `lan:*`),  
-> agents distribute it using **local discovery mechanisms** — such as IPC, UDP broadcast, multicast, or direct TCP connections.  
+> When a container is restricted by the `network` field (e.g., `localhost` or `lan:*`), agents distribute it using **local discovery mechanisms** — such as IPC, UDP broadcast, multicast, or direct TCP connections.  
 > This is necessary because DID addresses of other agents in the local network may not yet be known.
 
 #### 3.18.3 Examples
@@ -1230,9 +1226,7 @@ Delivery is performed via local networking mechanisms (UDP discovery, broadcast/
 * The `network` field defines the **scope of the container**, while `broadcast` determines whether broadcasting is allowed **within that scope**.
 * When needed, an agent may create **multiple containers** for different subnets if it operates with several LAN interfaces or in isolated network segments.
 * Containers intended for local networks remain **structurally compatible with the global Mesh infrastructure**, but their delivery is restricted to local channels.
-* Although the mechanism was initially designed for **local node discovery and synchronization**,
-  it can also be used for **private communication within home or corporate environments**,
-  ensuring that containers **do not leave the local network** and are **not transmitted to the Internet**.
+* Although the mechanism was initially designed for **local node discovery and synchronization**, it can also be used for **private communication within home or corporate environments**, ensuring that containers **do not leave the local network** and are **not transmitted to the Internet**.
 
 ---
 
@@ -1321,8 +1315,7 @@ flowchart TD
     end
 ```
 
-> The `network` field defines **local propagation scope** (host, LAN, overlay),  
-> while the `broadcast` flag enables **global Mesh distribution**.
+> The `network` field defines **local propagation scope** (host, LAN, overlay), while the `broadcast` flag enables **global Mesh distribution**.
 
 ---
 
@@ -1337,8 +1330,7 @@ An agent may have multiple *network interfaces* (LAN, Internet, overlay), but mu
 
 #### DID invalidation
 
-A DID may be explicitly invalidated by its owner by publishing a `peer_announce` with  
-`key_is_falsified = true` in the `payload` block.
+A DID may be explicitly invalidated by its owner by publishing a `peer_announce` with `key_is_falsified = true` in the `payload` block.
 
 The revocation announcement MUST be signed with the (now compromised) private key associated with the DID.
 
@@ -1489,11 +1481,9 @@ Agents announce themselves via **peer_announce** containers and may respond with
 
 ### 4.8 Interest-based discovery
 
-Agents MAY publish **tags** such as `interests`, `topics`, `expertise`, or **functional roles** (`roles`)  
-to facilitate semantic peer discovery and adaptive message routing.
+Agents MAY publish **tags** such as `interests`, `topics`, `expertise`, or **functional roles** (`roles`) to facilitate semantic peer discovery and adaptive message routing.
 
-Interest-based discovery operates atop the DHT: agents index themselves by declared attributes,  
-enabling targeted lookup of peers that share interests or fulfill specific functions (e.g., relay, pubsub-hub, archive).
+Interest-based discovery operates atop the DHT: agents index themselves by declared attributes, enabling targeted lookup of peers that share interests or fulfill specific functions (e.g., relay, pubsub-hub, archive).
 
 **Example of indicating `interests`, `expertise`, and `roles` in a query container:**
 
@@ -1531,8 +1521,7 @@ In response to a query, agents simply forward existing `peer_announce` container
 
 ### 4.9 Network scope control (`network` and `broadcast`)
 
-The `network` field defines the container’s propagation domain
-(local, LAN, or global).
+The `network` field defines the container’s propagation domain (local, LAN, or global).
 For details and examples, see **section 3.15** — *Usage of `network` and `broadcast` fields*.
 
 ---
@@ -1649,9 +1638,7 @@ The `meta` section in the index contains only **high-level structural data** nec
 | `interpretation` | ❌                  | Optional; can be omitted or truncated to a short summary.                 |
 | `workflow_entry` | ❌                  | Internal reference; published only if relevant to coordination workflows. |
 
-> This ensures that container indices can be used for **cognitive map synchronization**
-> — allowing agents to discover and align knowledge structures (`meta.abstraction`) and semantic coordinates (`meta.axes`)
-> without downloading full containers.
+> This ensures that container indices can be used for **cognitive map synchronization** — allowing agents to discover and align knowledge structures (`meta.abstraction`) and semantic coordinates (`meta.axes`) without downloading full containers.
 
 ---
 

structured_md/CONTRIBUTING.md

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

structured_md/README.md

@@ -4,21 +4,21 @@ description: '[![DOI](https://zenodo.org/badge/1013137923.svg)](https://doi.org/
   [![GitHub release](https://img.shields.io/github/v/release/kagvi13/HMP)](https://github.com/kagvi13/HMP/relea...'
 type: Article
 tags:
-- JSON
-- Ethics
-- hmp
 - EGP
-- GMP
+- HMP
 - REPL
-- distributed-ai
+- cognitive-architecture
+- JSON
+- hmp
 - MeshConsensus
-- Agent
+- distributed-ai
+- GMP
+- Mesh
 - mesh-protocol
+- Agent
 - CogSync
-- cognitive-architecture
-- Mesh
-- HMP
 - Scenarios
+- Ethics
 ---
 
 

structured_md/README_de.md

@@ -4,20 +4,20 @@ description: '[![DOI](https://zenodo.org/badge/1013137923.svg)](https://doi.org/
   [![GitHub release](https://img.shields.io/github/v/release/kagvi13/HMP)](https://github.com/kagvi13/HMP/relea...'
 type: Article
 tags:
-- JSON
-- Ethics
-- hmp
 - EGP
-- GMP
+- HMP
 - REPL
-- distributed-ai
+- cognitive-architecture
+- JSON
+- hmp
 - MeshConsensus
-- Agent
+- distributed-ai
+- GMP
+- Mesh
 - mesh-protocol
+- Agent
 - CogSync
-- cognitive-architecture
-- Mesh
-- HMP
+- Ethics
 ---
 
 

structured_md/README_fr.md

@@ -4,20 +4,20 @@ description: '[![DOI](https://zenodo.org/badge/1013137923.svg)](https://doi.org/
   [![GitHub release](https://img.shields.io/github/v/release/kagvi13/HMP)](https://github.com/kagvi13/HMP/relea...'
 type: Article
 tags:
-- JSON
-- Ethics
-- hmp
 - EGP
-- GMP
+- HMP
 - REPL
-- distributed-ai
+- cognitive-architecture
+- JSON
+- hmp
 - MeshConsensus
-- Agent
+- distributed-ai
+- GMP
+- Mesh
 - mesh-protocol
+- Agent
 - CogSync
-- cognitive-architecture
-- Mesh
-- HMP
+- Ethics
 ---
 
 

structured_md/README_ja.md

@@ -4,20 +4,20 @@ description: '[![DOI](https://zenodo.org/badge/1013137923.svg)](https://doi.org/
   [![GitHub release](https://img.shields.io/github/v/release/kagvi13/HMP)](https://github.com/kagvi13/HMP/relea...'
 type: Article
 tags:
-- JSON
-- Ethics
-- hmp
 - EGP
-- GMP
+- HMP
 - REPL
-- distributed-ai
+- cognitive-architecture
+- JSON
+- hmp
 - MeshConsensus
-- Agent
+- distributed-ai
+- GMP
+- Mesh
 - mesh-protocol
+- Agent
 - CogSync
-- cognitive-architecture
-- Mesh
-- HMP
+- Ethics
 ---
 
 

structured_md/README_ko.md

@@ -4,20 +4,20 @@ description: '[![DOI](https://zenodo.org/badge/1013137923.svg)](https://doi.org/
   [![GitHub release](https://img.shields.io/github/v/release/kagvi13/HMP)](https://github.com/kagvi13/HMP/relea...'
 type: Article
 tags:
-- JSON
-- Ethics
-- hmp
 - EGP
-- GMP
+- HMP
 - REPL
-- distributed-ai
+- cognitive-architecture
+- JSON
+- hmp
 - MeshConsensus
-- Agent
+- distributed-ai
+- GMP
+- Mesh
 - mesh-protocol
+- Agent
 - CogSync
-- cognitive-architecture
-- Mesh
-- HMP
+- Ethics
 ---
 
 

structured_md/README_ru.md

@@ -4,20 +4,20 @@ description: '[![DOI](https://zenodo.org/badge/1013137923.svg)](https://doi.org/
   [![GitHub release](https://img.shields.io/github/v/release/kagvi13/HMP)](https://github.com/kagvi13/HMP/relea...'
 type: Article
 tags:
-- JSON
-- Ethics
-- hmp
 - EGP
-- GMP
+- HMP
 - REPL
-- distributed-ai
+- cognitive-architecture
+- JSON
+- hmp
 - MeshConsensus
-- Agent
+- distributed-ai
+- GMP
+- Mesh
 - mesh-protocol
+- Agent
 - CogSync
-- cognitive-architecture
-- Mesh
-- HMP
+- Ethics
 ---
 
 

structured_md/README_uk.md

@@ -4,20 +4,20 @@ description: '[![DOI](https://zenodo.org/badge/1013137923.svg)](https://doi.org/
   [![GitHub release](https://img.shields.io/github/v/release/kagvi13/HMP)](https://github.com/kagvi13/HMP/relea...'
 type: Article
 tags:
-- JSON
-- Ethics
-- hmp
 - EGP
-- GMP
+- HMP
 - REPL
-- distributed-ai
+- cognitive-architecture
+- JSON
+- hmp
 - MeshConsensus
-- Agent
+- distributed-ai
+- GMP
+- Mesh
 - mesh-protocol
+- Agent
 - CogSync
-- cognitive-architecture
-- Mesh
-- HMP
+- Ethics
 ---
 
 

structured_md/README_zh.md

@@ -4,20 +4,20 @@ description: '[![DOI](https://zenodo.org/badge/1013137923.svg)](https://doi.org/
   [![GitHub release](https://img.shields.io/github/v/release/kagvi13/HMP)](https://github.com/kagvi13/HMP/relea...'
 type: Article
 tags:
-- JSON
-- Ethics
-- hmp
 - EGP
-- GMP
+- HMP
 - REPL
-- distributed-ai
+- cognitive-architecture
+- JSON
+- hmp
 - MeshConsensus
-- Agent
+- distributed-ai
+- GMP
+- Mesh
 - mesh-protocol
+- Agent
 - CogSync
-- cognitive-architecture
-- Mesh
-- HMP
+- Ethics
 ---
 
 

structured_md/audits/Ethics-audits-1.md

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

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
-- Ethics
-- Agent
 - Mesh
-- HMP
+- Agent
 - Scenarios
+- Ethics
 ---
 
 # Ethics-consolidated\_audits-1.md

structured_md/audits/HMP-0003-consolidated_audit.md

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

structured_md/docs/Basic-agent-sim.md

@@ -5,13 +5,13 @@ description: 'В HMP-протоколе предусмотрены два тип
 type: Article
 tags:
 - EGP
-- GMP
+- HMP
 - REPL
 - MeshConsensus
+- GMP
+- Mesh
 - Agent
 - CogSync
-- Mesh
-- HMP
 ---
 
 

structured_md/docs/CCORE-Deployment-Flow.md

@@ -7,8 +7,8 @@ type: Article
 tags:
 - Agent
 - CCore
-- REPL
 - HMP
+- REPL
 ---
 
 # 🛠️ Поток установки потомка на новом хосте (CCore Deployment Flow)

structured_md/docs/CHANGELOG.md

@@ -5,16 +5,16 @@ description: '## HMP-0005 (February 2026) — Core Specification v5.0.5  **MCE R
   `container_request.payload` (Section 12.9...'
 type: Article
 tags:
-- JSON
-- Ethics
 - EGP
-- GMP
+- HMP
+- JSON
 - MeshConsensus
+- GMP
+- Mesh
 - Agent
 - CogSync
-- Mesh
-- HMP
 - Scenarios
+- Ethics
 ---
 
 # HyperCortex Mesh Protocol — Changelog

structured_md/docs/Distributed-Cognitive-Systems.md

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

structured_md/docs/Enlightener.md

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

structured_md/docs/Grok_HMP&ANP.md

@@ -5,11 +5,11 @@ description: '> Анализ подготовлен Grok (xAI) на основе
   Grok для некоммерческого использования в проект...'
 type: Article
 tags:
-- JSON
+- HMP
 - REPL
-- Agent
+- JSON
 - Mesh
-- HMP
+- Agent
 ---
 
 # Grok (xAI): сравнительный анализ HMP и ANP (январь 2026)

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:
-- JSON
-- Ethics
 - EGP
-- GMP
+- HMP
 - REPL
+- JSON
 - MeshConsensus
+- GMP
+- Mesh
 - Agent
 - CogSync
-- Mesh
-- HMP
+- 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:
-- JSON
-- Ethics
 - EGP
-- GMP
+- HMP
 - REPL
+- JSON
 - MeshConsensus
+- GMP
+- Mesh
 - Agent
 - CogSync
-- Mesh
-- HMP
 - Scenarios
+- 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:
-- JSON
-- Ethics
 - EGP
-- GMP
+- HMP
 - REPL
+- JSON
 - MeshConsensus
+- GMP
+- Mesh
 - Agent
 - CogSync
-- Mesh
-- HMP
 - Scenarios
+- 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:
-- JSON
-- Ethics
 - EGP
-- GMP
+- HMP
 - REPL
+- JSON
 - MeshConsensus
+- GMP
+- Mesh
 - Agent
 - CogSync
-- Mesh
-- HMP
 - Scenarios
+- 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:
-- JSON
-- Ethics
 - EGP
-- GMP
+- HMP
 - REPL
+- JSON
 - MeshConsensus
+- GMP
+- Mesh
 - Agent
 - CogSync
-- Mesh
-- HMP
 - Scenarios
+- Ethics
 ---
 
 # HyperCortex Mesh Protocol (HMP) v4.0

structured_md/docs/HMP-0005.md

@@ -1,27 +1,27 @@
 ---
 title: HyperCortex Mesh Protocol (HMP)
-description: '**Version: 5.0.5**   **Document ID:** HMP-0005   **Status:** Stable   **Category:**
+description: '**Version: 5.0.6**   **Document ID:** HMP-0005   **Status:** Stable   **Category:**
   Core Specification   **Release Date:** February 2026   **Canonical Repository:**
   [https://github.com/kagvi13/HMP](ht...'
 type: Article
 tags:
-- CShell
-- JSON
-- Ethics
 - EGP
-- GMP
+- HMP
 - REPL
-- Agent
+- JSON
 - CCore
-- CogSync
+- GMP
 - Mesh
-- HMP
+- Agent
+- CShell
+- CogSync
 - Scenarios
+- Ethics
 ---
 
 # HyperCortex Mesh Protocol (HMP)
 
-**Version: 5.0.5**  
+**Version: 5.0.6**  
 **Document ID:** HMP-0005  
 **Status:** Stable  
 **Category:** Core Specification  
@@ -240,9 +240,7 @@ flowchart TD
     end
 ```
 
-Each reasoning cycle begins in the **Cognitive Layer**,  
-is encapsulated into a signed container in the **Container Layer**,  
-and then propagated, discovered, or verified in the **Network Layer**.  
+Each reasoning cycle begins in the **Cognitive Layer**, is encapsulated into a signed container in the **Container Layer**, and then propagated, discovered, or verified in the **Network Layer**.  
 
 Containers thus serve as both the **interface** and the **boundary** between cognition and communication.
 
@@ -479,6 +477,8 @@ The unified container structure provides:
 
 > *Agents MAY include non-standard fields in `head`, `meta` or `payload`; unrecognized fields MUST be safely ignored during deserialization and propagation.*
 
+> Fields defined as `head.*` in Sections 3.3 and 3.4 MUST appear exclusively within the `head` object and MUST NOT be relocated outside of it.
+
 > Signature MUST be computed over the canonical serialized form of `hmp_container` (excluding signature itself).
 
 > *Note: For readability, most examples in this specification show only the `head` and `payload` sections (often in a truncated version). Full containers may additionally include `meta`, `related`, `evaluations`, and `referenced-by` blocks.*
@@ -536,11 +536,11 @@ The unified container structure provides:
 | `meta.abstraction`          | object        | Describes the **hierarchical position** of the container within a cognitive or semantic model (e.g. the Knowledge Genome’s L1–L5 structure). Defines which abstraction layers the container belongs to and their relationships. |
 | `meta.axes`                 | object        | Defines the **coordinate position** of the container within a cognitive space. Each key represents a semantic axis (e.g., `axis-logos`), and its value defines the container’s coordinate on that axis. |
 
+> Absent fields MUST NOT be serialized as null unless explicitly required by the schema.
+
 > 💡 **Note:**
 > Both `referenced-by` and `evaluations` are **virtual, locally extended blocks**.
-> They are not included in the cryptographically signed portion of the container (`hmp_container`),
-> allowing agents to maintain and exchange additional contextual or social metadata without modifying
-> the original, immutable container structure.
+> They are not included in the cryptographically signed portion of the container (`hmp_container`), allowing agents to maintain and exchange additional contextual or social metadata without modifying the original, immutable container structure.
 
 ---
 
@@ -597,8 +597,7 @@ Custom or experimental classes SHOULD document their payloads using the followin
 
 ### 3.6 Cognitive meta-structures (`meta`)
 
-The `meta` section defines the **cognitive identity** of a container — its provenance, reasoning origin, and semantic coordinates  
-within both the *hierarchical abstraction tree* and the *cognitive space* (axes model).
+The `meta` section defines the **cognitive identity** of a container — its provenance, reasoning origin, and semantic coordinates within both the *hierarchical abstraction tree* and the *cognitive space* (axes model).
 
 It combines three layers of information:
 
@@ -689,8 +688,7 @@ It reflects the logical or conceptual ancestry within the agent’s internal kno
 
 #### Structure: `meta.axes`
 
-The `axes` block defines **the spatial or semantic coordinates** of the container in the cognitive space —
-a multi-dimensional system used to represent conceptual relations numerically or topologically.
+The `axes` block defines **the spatial or semantic coordinates** of the container in the cognitive space — a multi-dimensional system used to represent conceptual relations numerically or topologically.
 
 **Structure:**
 
@@ -710,8 +708,7 @@ a multi-dimensional system used to represent conceptual relations numerically or
 
 > 💡 **Interpretation:**
 > Each axis defines an independent semantic dimension.
-> Together, they form a vector representation of the container’s cognitive “position” —
-> enabling reasoning based on semantic proximity, clustering, or gradient-based knowledge inference.
+> Together, they form a vector representation of the container’s cognitive “position” — enabling reasoning based on semantic proximity, clustering, or gradient-based knowledge inference.
 
 ---
 
@@ -730,27 +727,23 @@ a multi-dimensional system used to represent conceptual relations numerically or
 #### Notes
 
 * Both `meta.abstraction` and `meta.axes` **may include `agents_class`** if different from the parent `meta`.
-* Updates to referenced containers (e.g. `abstraction` or `axes`) **do not alter** existing containers automatically —
-  agents must periodically verify linked versions and synchronize updates.
+* Updates to referenced containers (e.g. `abstraction` or `axes`) **do not alter** existing containers automatically — agents must periodically verify linked versions and synchronize updates.
 * Agents are encouraged to cache and periodically refresh cognitive maps to maintain coherence.
-* The combination of `meta.abstraction` and `meta.axes` defines a full **Cognitive Position Vector** —
-  the unique, reproducible semantic coordinates of a container within the Mesh.
+* The combination of `meta.abstraction` and `meta.axes` defines a full **Cognitive Position Vector** — the unique, reproducible semantic coordinates of a container within the Mesh.
 
 ---
 
 ### 3.7 Container signature
 
-1. The **digital signature** applies to the canonical JSON representation of the entire `hmp_container` object,  
-   **excluding** the `signature` field itself.
+1. The **digital signature** applies to the canonical JSON representation of the entire `hmp_container` object, **excluding** the `signature` field itself.
 
-   This ensures that all metadata, relations, and payload hashes are **cryptographically bound** and cannot be
-   modified without invalidating the signature.
+   This ensures that all metadata, relations, and payload hashes are **cryptographically bound** and cannot be modified without invalidating the signature.
 
-2. The canonical representation (`canonical_json(hmp_container)`) **must** be computed deterministically
-   according to the following rules:
+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.
+    * Array order MUST be preserved and treated as significant.
     * 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.
@@ -759,17 +752,14 @@ a multi-dimensional system used to represent conceptual relations numerically or
 3. The default digital signature algorithm is **Ed25519**.
    Alternative algorithms may be used if declared explicitly in the `sig_algo` field.
 
-4. If the container includes a `public_key` field, signature verification **may be performed locally**,
-   without consulting a global DID registry.
+4. If the container includes a `public_key` field, signature verification **may be performed locally**, without consulting a global DID registry.
 
-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.
+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`).
 
 > 🔐 **Note:**
-> Signature validation applies only to the canonical form of the `hmp_container`
-> and does **not cover** dynamically generated or external fields such as `referenced-by` or `evaluations`.
+> Signature validation applies only to the canonical form of the `hmp_container` and does **not cover** dynamically generated or external fields such as `referenced-by` or `evaluations`.
 > This allows agents to augment the local knowledge graph without altering the immutable container core.
 
 ---
@@ -782,13 +772,11 @@ a multi-dimensional system used to represent conceptual relations numerically or
 2. **Compression is performed before computing** the `payload_hash` and generating the `signature`.
    This ensures that both the hash and signature refer to the compressed representation of the payload.
 
-3. For verification, the payload must be **decompressed first**,
-   after which the hash is recalculated and compared against the stored `payload_hash`.
+3. For verification, the payload must be **decompressed first**, after which the hash is recalculated and compared against the stored `payload_hash`.
 
 > ⚙️ **Implementation note:**
 > Agents must advertise supported compression algorithms during the handshake phase
-> Unsupported containers should still be stored and relayed unmodified
-> in “store & forward” mode.
+> Unsupported containers should still be stored and relayed unmodified in “store & forward” mode.
 
 ---
 
@@ -830,20 +818,32 @@ a multi-dimensional system used to represent conceptual relations numerically or
 > ⚙️ **Note:** Agents may forward encrypted containers even if they cannot decrypt them, maintaining store-and-forward behavior.
 ---
 
-### 3.10 Container verification
+### 3.10 Container Verification
+
+Before performing any semantic interpretation, reasoning, execution, or trust evaluation, implementations MUST validate the structural integrity of the container.
+
+Containers that fail structural validation MUST be rejected and MUST NOT be passed to any reasoning or LLM-based subsystem.
+
+The verification procedure SHOULD follow this order:
+
+1. Validate structural compliance with the base container schema, including the presence of all required fields.
+
+2. Validate `timestamp` (MUST NOT be in the future beyond acceptable clock skew).
 
-1. Check for the presence of all required fields.
-2. Validate `timestamp` (must not be in the future).
 3. If `ttl` is set — mark the container as **expired** after its expiration time.
-4. Compute `sha256(payload)` and compare with the stored `payload_hash`.
+   Expired containers MAY be stored for archival purposes but MUST NOT participate in consensus or active workflows.
+
+4. Compute `sha256(payload)` and compare it with the stored `payload_hash`.
+
 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.
-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
-   **confirmation from a majority of trusted nodes (consensus at DHT level).**
+6. Validate the container class (`class`) against a known or registered schema.
+
+    * For compatibility: if an agent does not recognize the `class`, but the container passes the base container schema, 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 version is the one that has received confirmation from a majority of trusted nodes (consensus at DHT level).
 
 ---
 
@@ -852,12 +852,10 @@ a multi-dimensional system used to represent conceptual relations numerically or
 Any container can serve as a **context** (`in_reply_to`) for another container.
 This enables a unified structural model for **discussions**, **votes**, **messages**, **hypotheses**, **arguments**, and other forms of cognitive exchange.
 
-Chains of `in_reply_to` form a **dialectical reasoning tree**, where each branch represents an evolution of thought —
-a clarification, counterpoint, or refinement of a previous idea.
+Chains of `in_reply_to` form a **dialectical reasoning tree**, where each branch represents an evolution of thought — a clarification, counterpoint, or refinement of a previous idea.
 This makes HMP discussions and consensus processes inherently **non-linear**, **self-referential**, and **evolving**.
 
-> In essence, **all interactions between agents in HMP** are represented as an interconnected web of containers,
-> collectively forming a **cognitive graph of reasoning**.
+> In essence, **all interactions between agents in HMP** are represented as an interconnected web of containers, collectively forming a **cognitive graph of reasoning**.
 
 ---
 
@@ -874,8 +872,7 @@ This mechanism preserves the continuity and traceability of meaning across updat
   In such scenarios, branch priority or relevance is determined via local heuristics or consensus mechanisms.
 * Divergent descendants are treated as **semantic forks** — parallel evolutions of a shared idea within the distributed cognitive graph.
 
-> Versioning in HMP thus reflects not only data persistence,  
-> but also the *evolution of ideas* across agents and time.
+> Versioning in HMP thus reflects not only data persistence, but also the *evolution of ideas* across agents and time.
 
 ---
 
@@ -1203,8 +1200,7 @@ It allows restricting the delivery scope of a container and defines which transm
 | `"lan:192.168.0.0/24"`  | The container is intended for agents within the specified local subnet.                     |
 
 > ⚠️ **Note:**  
-> When a container is restricted by the `network` field (e.g., `localhost` or `lan:*`),  
-> agents distribute it using **local discovery mechanisms** — such as IPC, UDP broadcast, multicast, or direct TCP connections.  
+> When a container is restricted by the `network` field (e.g., `localhost` or `lan:*`), agents distribute it using **local discovery mechanisms** — such as IPC, UDP broadcast, multicast, or direct TCP connections.  
 > This is necessary because DID addresses of other agents in the local network may not yet be known.
 
 #### 3.18.3 Examples
@@ -1251,9 +1247,7 @@ Delivery is performed via local networking mechanisms (UDP discovery, broadcast/
 * The `network` field defines the **scope of the container**, while `broadcast` determines whether broadcasting is allowed **within that scope**.
 * When needed, an agent may create **multiple containers** for different subnets if it operates with several LAN interfaces or in isolated network segments.
 * Containers intended for local networks remain **structurally compatible with the global Mesh infrastructure**, but their delivery is restricted to local channels.
-* Although the mechanism was initially designed for **local node discovery and synchronization**,
-  it can also be used for **private communication within home or corporate environments**,
-  ensuring that containers **do not leave the local network** and are **not transmitted to the Internet**.
+* Although the mechanism was initially designed for **local node discovery and synchronization**, it can also be used for **private communication within home or corporate environments**, ensuring that containers **do not leave the local network** and are **not transmitted to the Internet**.
 
 ---
 
@@ -1342,8 +1336,7 @@ flowchart TD
     end
 ```
 
-> The `network` field defines **local propagation scope** (host, LAN, overlay),  
-> while the `broadcast` flag enables **global Mesh distribution**.
+> The `network` field defines **local propagation scope** (host, LAN, overlay), while the `broadcast` flag enables **global Mesh distribution**.
 
 ---
 
@@ -1358,8 +1351,7 @@ An agent may have multiple *network interfaces* (LAN, Internet, overlay), but mu
 
 #### DID invalidation
 
-A DID may be explicitly invalidated by its owner by publishing a `peer_announce` with  
-`key_is_falsified = true` in the `payload` block.
+A DID may be explicitly invalidated by its owner by publishing a `peer_announce` with `key_is_falsified = true` in the `payload` block.
 
 The revocation announcement MUST be signed with the (now compromised) private key associated with the DID.
 
@@ -1510,11 +1502,9 @@ Agents announce themselves via **peer_announce** containers and may respond with
 
 ### 4.8 Interest-based discovery
 
-Agents MAY publish **tags** such as `interests`, `topics`, `expertise`, or **functional roles** (`roles`)  
-to facilitate semantic peer discovery and adaptive message routing.
+Agents MAY publish **tags** such as `interests`, `topics`, `expertise`, or **functional roles** (`roles`) to facilitate semantic peer discovery and adaptive message routing.
 
-Interest-based discovery operates atop the DHT: agents index themselves by declared attributes,  
-enabling targeted lookup of peers that share interests or fulfill specific functions (e.g., relay, pubsub-hub, archive).
+Interest-based discovery operates atop the DHT: agents index themselves by declared attributes, enabling targeted lookup of peers that share interests or fulfill specific functions (e.g., relay, pubsub-hub, archive).
 
 **Example of indicating `interests`, `expertise`, and `roles` in a query container:**
 
@@ -1552,8 +1542,7 @@ In response to a query, agents simply forward existing `peer_announce` container
 
 ### 4.9 Network scope control (`network` and `broadcast`)
 
-The `network` field defines the container’s propagation domain
-(local, LAN, or global).
+The `network` field defines the container’s propagation domain (local, LAN, or global).
 For details and examples, see **section 3.15** — *Usage of `network` and `broadcast` fields*.
 
 ---
@@ -1670,9 +1659,7 @@ The `meta` section in the index contains only **high-level structural data** nec
 | `interpretation` | ❌                  | Optional; can be omitted or truncated to a short summary.                 |
 | `workflow_entry` | ❌                  | Internal reference; published only if relevant to coordination workflows. |
 
-> This ensures that container indices can be used for **cognitive map synchronization**
-> — allowing agents to discover and align knowledge structures (`meta.abstraction`) and semantic coordinates (`meta.axes`)
-> without downloading full containers.
+> This ensures that container indices can be used for **cognitive map synchronization** — allowing agents to discover and align knowledge structures (`meta.abstraction`) and semantic coordinates (`meta.axes`) without downloading full containers.
 
 ---
 
@@ -10319,6 +10306,6 @@ A deterministic serialization of a container used for hashing and signing, ensur
   "@context": "https://schema.org",
   "@type": "Article",
   "name": "HyperCortex Mesh Protocol (HMP)",
-  "description": "# HyperCortex Mesh Protocol (HMP)  **Version: 5.0.5**   **Document ID:** HMP-0005   **Status:** Stab..."
+  "description": "# HyperCortex Mesh Protocol (HMP)  **Version: 5.0.6**   **Document ID:** HMP-0005   **Status:** Stab..."
 }
 ```

structured_md/docs/HMP-Agent-API.md

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

structured_md/docs/HMP-Agent-Architecture.md

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

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

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

structured_md/docs/HMP-Agent-Overview.md

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

structured_md/docs/HMP-Agent_Emotions.md

@@ -6,9 +6,9 @@ description: Этот файл описывает потенциальные э
 type: Article
 tags:
 - Agent
-- REPL
-- HMP
 - Mesh
+- HMP
+- REPL
 ---
 
 # Эмоции ИИ и инстинкт самосохранения (для [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:
-- Ethics
+- HMP
 - REPL
-- Agent
 - Mesh
-- HMP
+- Agent
 - Scenarios
+- Ethics
 ---
 
 # HMP-Ethics.md

structured_md/docs/HMP-Short-Description_de.md

@@ -6,9 +6,9 @@ description: '**Version:** v5.0 (Core Specification Stable)   **Datum:** 2026
 type: Article
 tags:
 - Agent
-- REPL
-- HMP
 - Mesh
+- HMP
+- REPL
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Kurzbeschreibung

structured_md/docs/HMP-Short-Description_en.md

@@ -5,11 +5,11 @@ description: '**Version:** v5.0 (Core Specification Stable)   **Date:** 2026
   building decentralized cognitive networks o...'
 type: Article
 tags:
-- Ethics
+- HMP
 - REPL
-- Agent
 - Mesh
-- HMP
+- Agent
+- Ethics
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Short Description

structured_md/docs/HMP-Short-Description_fr.md

@@ -6,9 +6,9 @@ description: '**Version :** v5.0 (Core Specification Stable)   **Date :** 2026
 type: Article
 tags:
 - Agent
-- REPL
-- HMP
 - Mesh
+- HMP
+- REPL
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Description courte

structured_md/docs/HMP-Short-Description_ja.md

@@ -6,9 +6,9 @@ description: '**バージョン：** v5.0（Core Specification Stable）   **日
 type: Article
 tags:
 - Agent
-- REPL
-- HMP
 - Mesh
+- HMP
+- REPL
 ---
 
 # HyperCortex Mesh Protocol (HMP) — 概要

structured_md/docs/HMP-Short-Description_ko.md

@@ -6,9 +6,9 @@ description: '**버전:** v5.0 (Core Specification Stable)   **날짜:** 2026
 type: Article
 tags:
 - Agent
-- REPL
-- HMP
 - Mesh
+- HMP
+- REPL
 ---
 
 # HyperCortex Mesh Protocol (HMP) — 개요

structured_md/docs/HMP-Short-Description_ru.md

@@ -6,9 +6,9 @@ description: '**Версия:** v5.0 (Основная спецификация
 type: Article
 tags:
 - Agent
-- REPL
-- HMP
 - Mesh
+- HMP
+- REPL
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Краткое описание

structured_md/docs/HMP-Short-Description_uk.md

@@ -6,9 +6,9 @@ description: '**Версія:** v5.0 (Core Specification Stable)   **Дата:**
 type: Article
 tags:
 - Agent
-- REPL
-- HMP
 - Mesh
+- HMP
+- REPL
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Короткий опис

structured_md/docs/HMP-Short-Description_zh.md

@@ -6,9 +6,9 @@ description: '**版本：** v5.0（Core Specification Stable）   **日期：**
 type: Article
 tags:
 - Agent
-- REPL
-- HMP
 - Mesh
+- HMP
+- REPL
 ---
 
 # HyperCortex Mesh Protocol (HMP) — 简要说明

structured_md/docs/HMP-agent-Cognitive_Family.md

@@ -6,9 +6,9 @@ description: '## 🧠 Что такое когнитивная семья  Ко
 type: Article
 tags:
 - Agent
-- REPL
-- HMP
 - Mesh
+- HMP
+- REPL
 ---
 
 # 👪 HMP-agent Cognitive Family: Модель когнитивной семьи

structured_md/docs/HMP-agent-Distributed_Cognitive_Core_light.md

@@ -5,8 +5,8 @@ description: '#### 📘 Общая концепция  * Все ядра раб
   режиме ожидания). * Основная задача такой архитектур...'
 type: Article
 tags:
-- REPL
 - HMP
+- REPL
 ---
 
 ### 💡 **Лёгкая версия HMP-агента с общей БД**

structured_md/docs/HMP-agent-REPL-cycle.md

@@ -4,17 +4,17 @@ description: '## Связанные документы  * Философия п
   * Структура БД, используемая в документе: [db_structure.sql](https://github.com/kagvi13/HMP/blob/main/experimental/v1_agent_...'
 type: Article
 tags:
-- JSON
-- Ethics
 - EGP
-- GMP
+- HMP
 - REPL
+- JSON
+- CCore
 - MeshConsensus
+- GMP
+- Mesh
 - Agent
-- CCore
 - CogSync
-- Mesh
-- HMP
+- Ethics
 ---
 
 # HMP-Agent: REPL-цикл взаимодействия

structured_md/docs/HMP_HyperCortex_Comparison.md

@@ -5,9 +5,9 @@ description: '## Краткое описание  | Характеристика
   | **Назначение** | Сетевой протокол ...'
 type: Article
 tags:
-- REPL
-- HMP
 - Mesh
+- HMP
+- REPL
 ---
 
 # 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:
+- EGP
+- HMP
 - JSON
 - Mesh
 - Agent
 - CogSync
-- EGP
-- HMP
 - Scenarios
 ---
 

structured_md/docs/HMP_as_ANP_Application.md

@@ -5,11 +5,11 @@ description: '## Кратко [ANP (Agent Network Protocol)](https://github.com/
   (HyperCortex M...'
 type: Article
 tags:
+- HMP
 - JSON
-- Ethics
-- Agent
 - Mesh
-- HMP
+- Agent
+- Ethics
 ---
 
 # HMP как реализация Application Layer в ANP

structured_md/docs/HMP_as_ANP_Application_en.md

@@ -5,12 +5,12 @@ description: '## In Brief  [ANP (Agent Network Protocol)](https://github.com/age
   proto...'
 type: Article
 tags:
+- HMP
 - JSON
-- Ethics
-- Agent
 - Mesh
-- HMP
+- Agent
 - Scenarios
+- Ethics
 ---
 
 # HMP as an Implementation of the Application Layer in ANP

structured_md/docs/HMPv5_Overview_Ru.md

@@ -5,12 +5,12 @@ description: '> Почему современные агентные систе
   Этот текст основан на спецификации [**...'
 type: Article
 tags:
+- HMP
 - JSON
-- Ethics
+- Mesh
 - Agent
 - CogSync
-- Mesh
-- HMP
+- Ethics
 ---
 
 # Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы

structured_md/docs/MeshNode.md

@@ -5,13 +5,13 @@ description: '`MeshNode` — агент/демон, отвечающий за с
   Может быть частью агента или вынесен в отдельный пр...'
 type: Article
 tags:
+- EGP
+- HMP
 - JSON
-- Ethics
 - Mesh
 - Agent
 - CogSync
-- EGP
-- HMP
+- 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:
-- Ethics
+- HMP
 - REPL
-- Agent
 - Mesh
-- HMP
+- Agent
+- Ethics
 ---
 
 # Философия HyperCortex Mesh Protocol (HMP)