ваше сообщение коммита

This commit is contained in:
2026-02-20 14:18:08 +03:00
parent 8702a355a1
commit 24e560fc83
44 changed files with 8354 additions and 95 deletions

89
LICENSE
View File

@@ -1,65 +1,66 @@
ЛИЦЕНЗИЯ ПРОПРИЕТАРНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
**English** | [Русский](LICENSE.ru)
Авторские права (c) 2024-2025 Тарабанов Александр Викторович
Все права защищены.
PROPRIETARY SOFTWARE LICENSE
Данное программное обеспечение и связанные с ним файлы документации
("Программное обеспечение") являются собственностью и конфиденциальной
информацией Тарабанова Александра Викторовича.
Copyright (c) 2024-2025 Alexander Viktorovich Tarabanov
All rights reserved.
УСЛОВИЯ И ПОЛОЖЕНИЯ:
This software and associated documentation files (the "Software") are the
property and confidential information of Alexander Viktorovich Tarabanov.
1. ПРЕДОСТАВЛЕНИЕ ЛИЦЕНЗИИ
При соблюдении условий данной Лицензии, Тарабанов Александр Викторович
предоставляет вам неисключительную, непередаваемую лицензию на использование
Программного обеспечения для ваших бизнес-операций и внутренних целей.
TERMS AND CONDITIONS:
2. РАЗРЕШЕННОЕ ИСПОЛЬЗОВАНИЕ
Вы можете:
- Использовать Программное обеспечение для ваших бизнес-операций
- Устанавливать и запускать Программное обеспечение на ваших системах
- Использовать Программное обеспечение для предоставления услуг вашим клиентам
- Интегрировать Программное обеспечение в ваши бизнес-процессы
1. GRANT OF LICENSE
Subject to the terms of this License, Alexander Viktorovich Tarabanov
grants you a non-exclusive, non-transferable license to use the Software
for your business operations and internal purposes.
3. ОГРАНИЧЕНИЯ
Вы НЕ можете:
- Перепродавать, перераспределять или сублицензировать Программное обеспечение третьим лицам
- Дарить, передавать или предоставлять Программное обеспечение третьим лицам
- Модифицировать, адаптировать или создавать производные работы без явного разрешения
- Обратно инжинирить, декомпилировать или дизассемблировать Программное обеспечение
- Удалять или изменять любые уведомления об авторских правах
- Использовать Программное обеспечение в образовательных учреждениях без разрешения
2. PERMITTED USE
You may:
- Use the Software for your business operations
- Install and run the Software on your systems
- Use the Software to provide services to your clients
- Integrate the Software into your business processes
4. КОММЕРЧЕСКАЯ ПЕРЕПРОДАЖА И МОДИФИКАЦИИ
Коммерческая перепродажа, распространение или модификации данного Программного
обеспечения требуют явного письменного разрешения от Тарабанова Александра
Викторовича (info@hb3-accelerator.com).
3. RESTRICTIONS
You may NOT:
- Resell, redistribute, or sublicense the Software to third parties
- Give, transfer, or provide the Software to third parties
- Modify, adapt, or create derivative works without express permission
- Reverse engineer, decompile, or disassemble the Software
- Remove or alter any copyright notices
- Use the Software in educational institutions without permission
5. ОБНОВЛЕНИЯ И МОДИФИКАЦИИ
Любые обновления, модификации или производные работы требуют явного письменного
разрешения от правообладателя.
4. COMMERCIAL RESALE AND MODIFICATIONS
Commercial resale, distribution, or modification of this Software requires
express written permission from Alexander Viktorovich Tarabanov
(info@hb3-accelerator.com).
6. ПРЕКРАЩЕНИЕ ДЕЙСТВИЯ
Данная лицензия автоматически прекращает действие при нарушении ее условий.
5. UPDATES AND MODIFICATIONS
Any updates, modifications, or derivative works require express written
permission from the copyright holder.
7. ОТКАЗ ОТ ГАРАНТИЙ
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРЕДОСТАВЛЯЕТСЯ "КАК ЕСТЬ", БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ.
6. TERMINATION
This license automatically terminates upon breach of its terms.
По вопросам лицензирования: info@hb3-accelerator.com
Веб-сайт: https://hb3-accelerator.com
7. DISCLAIMER OF WARRANTIES
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT ANY WARRANTIES.
Licensing inquiries: info@hb3-accelerator.com
Website: https://hb3-accelerator.com
GitHub: https://github.com/VC-HB3-Accelerator
Подробная информация о лицензии: legal/README.md
For full license details: legal.en/README.md (or legal.ru/README.md)
## 🔐 ЦИФРОВАЯ ПОДПИСЬ
## 🔐 DIGITAL SIGNATURE
Данный файл подписан цифровой подписью для защиты авторских прав.
This file is signed with a digital signature for copyright protection.
**Проверка подписи:**
**Verify signature:**
```bash
gpg --verify LICENSE.asc LICENSE
```
**GPG Key ID:** 4603583F81054FEECE7E821E026FD26F71D70B17
**Дата подписи:** 2024-10-24
**Автор:** Тарабанов Александр Викторович
**Signature date:** 2024-10-24
**Author:** Alexander Viktorovich Tarabanov

67
LICENSE.ru Normal file
View File

@@ -0,0 +1,67 @@
[English](LICENSE) | **Русский**
ЛИЦЕНЗИЯ ПРОПРИЕТАРНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Авторские права (c) 2024-2025 Тарабанов Александр Викторович
Все права защищены.
Данное программное обеспечение и связанные с ним файлы документации
("Программное обеспечение") являются собственностью и конфиденциальной
информацией Тарабанова Александра Викторовича.
УСЛОВИЯ И ПОЛОЖЕНИЯ:
1. ПРЕДОСТАВЛЕНИЕ ЛИЦЕНЗИИ
При соблюдении условий данной Лицензии, Тарабанов Александр Викторович
предоставляет вам неисключительную, непередаваемую лицензию на использование
Программного обеспечения для ваших бизнес-операций и внутренних целей.
2. РАЗРЕШЕННОЕ ИСПОЛЬЗОВАНИЕ
Вы можете:
- Использовать Программное обеспечение для ваших бизнес-операций
- Устанавливать и запускать Программное обеспечение на ваших системах
- Использовать Программное обеспечение для предоставления услуг вашим клиентам
- Интегрировать Программное обеспечение в ваши бизнес-процессы
3. ОГРАНИЧЕНИЯ
Вы НЕ можете:
- Перепродавать, перераспределять или сублицензировать Программное обеспечение третьим лицам
- Дарить, передавать или предоставлять Программное обеспечение третьим лицам
- Модифицировать, адаптировать или создавать производные работы без явного разрешения
- Обратно инжинирить, декомпилировать или дизассемблировать Программное обеспечение
- Удалять или изменять любые уведомления об авторских правах
- Использовать Программное обеспечение в образовательных учреждениях без разрешения
4. КОММЕРЧЕСКАЯ ПЕРЕПРОДАЖА И МОДИФИКАЦИИ
Коммерческая перепродажа, распространение или модификации данного Программного
обеспечения требуют явного письменного разрешения от Тарабанова Александра
Викторовича (info@hb3-accelerator.com).
5. ОБНОВЛЕНИЯ И МОДИФИКАЦИИ
Любые обновления, модификации или производные работы требуют явного письменного
разрешения от правообладателя.
6. ПРЕКРАЩЕНИЕ ДЕЙСТВИЯ
Данная лицензия автоматически прекращает действие при нарушении ее условий.
7. ОТКАЗ ОТ ГАРАНТИЙ
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРЕДОСТАВЛЯЕТСЯ "КАК ЕСТЬ", БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ.
По вопросам лицензирования: info@hb3-accelerator.com
Веб-сайт: https://hb3-accelerator.com
GitHub: https://github.com/VC-HB3-Accelerator
Подробная информация о лицензии: legal/README.md
## 🔐 ЦИФРОВАЯ ПОДПИСЬ
Данный файл подписан цифровой подписью для защиты авторских прав.
**Проверка подписи:**
```bash
gpg --verify LICENSE.asc LICENSE
```
**GPG Key ID:** 4603583F81054FEECE7E821E026FD26F71D70B17
**Дата подписи:** 2024-10-24
**Автор:** Тарабанов Александр Викторович

101
README.md
View File

@@ -1,71 +1,90 @@
# Digital Legal Entity (DLE) — шаблон приложения
# Digital Legal Entity (DLE) — Application Template
## Определение продукта
## Product definition
**Digital Legal Entity (DLE)** — микросервисная платформа с веб-приложением для локальной установки на серверах компании.
**Digital Legal Entity (DLE)** is a microservices platform with a web application for on-premise deployment on company servers.
**Включает:**
- Инструменты настройки ИИ-агентов
- Систему смарт-контрактов с поддержкой:
- Налоговых, бухгалтерских, банковских и иных идентификаторов, установленных регулятором
**Includes:**
- AI agent configuration tools
- Smart contract system with support for:
- Tax, accounting, banking, and other identifiers set by the regulator
**Преимущества:**
- Управление и автоматизация бизнес-процессов
- Замена разрозненных SaaS-сервисов с ежемесячными подписками
- Соответствие требованиям регуляторов к хранению и обработке данных
**Benefits:**
- Business process management and automation
- Replacement of fragmented SaaS services with monthly subscriptions
- Compliance with regulator requirements for data storage and processing
## Documentation (English)
## Доступные документы
| Document | Description |
|----------|-------------|
| [application-description.md](docs.en/application-description.md) | Platform overview, main benefits, and economic impact. |
| [ai-assistant.md](docs.en/ai-assistant.md) | AI agents: architecture, creating agents for business processes, examples, and economics. |
| [blockchain-for-business.md](docs.en/blockchain-for-business.md) | Business case and use cases for blockchain in DLE. |
| [security.md](docs.en/security.md) | Security model, access control, and safeguards. |
| [service-terms.md](docs.en/service-terms.md) | Terms of purchase and service for the license. |
| [FAQ.md](docs.en/FAQ.md) | Frequently asked questions. |
| Файл | Краткое описание |
| --- | --- |
| [application-description.md](docs/application-description.md) | Обзор назначения платформы, ключевых преимуществ и экономического эффекта. |
| [ai-assistant.md](docs/ai-assistant.md) | ИИ-агенты: архитектура, создание агентов под бизнес-процессы, примеры и экономический эффект. |
| [blockchain-for-business.md](docs/blockchain-for-business.md) | Бизнес-обоснование и кейсы использования блокчейна в DLE. |
| [security.md](docs/security.md) | Модель безопасности, контроль доступа и защитные механизмы. |
| [service-terms.md](docs/service-terms.md) | Подробные условия приобретения и обслуживания лицензии. |
### Technical and backend docs
### Смежные материалы
- [Setup guide](docs.en/back-docs/setup-instruction.md) — full application setup
- [AI assistant setup](docs.en/back-docs/setup-ai-assistant.md) — RAG and Ollama
- [Blockchain integration](docs.en/back-docs/blockchain-integration-technical.md) — smart contracts and multichain
- [Tables system](docs.en/back-docs/tables-system.md) — spreadsheets and RAG
- [Multi-agent architecture](docs.en/back-docs/multi-agent-architecture.md)
- [Юридические документы](legal/README.md) — лицензия, авторские права, требования к атрибуции
### Related
- [Legal documents (EN)](legal.en/README.md) — license, copyright, attribution
- [Юридические документы (RU)](legal.ru/README.md) — лицензия, авторские права
## Полный шаблон приложения Digital Legal Entity для развертывания на собственной инфраструктуре.
---
## Требования
- Docker и Docker Compose
## Full Digital Legal Entity application template for on-premise deployment
## Быстрый запуск
## Requirements
### Автоматическая установка (рекомендуется)
- Docker and Docker Compose
**Для Linux/macOS/WSL:**
## Quick start
### Automated install (recommended)
**Linux/macOS/WSL:**
```bash
curl -fsSL https://raw.githubusercontent.com/VC-HB3-Accelerator/DLE/main/setup.sh | bash
```
Скрипт автоматически скачивает последние артефакты из релиза и разворачивает `docker-data`.
The script downloads the latest release artifacts and deploys `docker-data`.
### Релизы и артефакты
- [Релиз v1.0.3](https://github.com/VC-HB3-Accelerator/DLE/releases/tag/v1.0.3) (Latest) — содержит полный шаблон приложения с Docker образами, томами и ключом шифрования. Архив разделен на части (`dle-template.tar.gz.part-*`) для удобства загрузки.
- [Релиз v1.0.2](https://github.com/VC-HB3-Accelerator/DLE/releases/tag/v1.0.2) — предыдущая версия.
- [Релиз v1.0.1](https://github.com/VC-HB3-Accelerator/DLE/releases/tag/v1.0.1) — предыдущая версия.
- [Релиз v1.0.0](https://github.com/VC-HB3-Accelerator/DLE/releases/tag/v1.0.0) — предыдущая версия.
### Releases and artifacts
- [Release v1.0.3](https://github.com/VC-HB3-Accelerator/DLE/releases/tag/v1.0.3) (Latest) — full application template with Docker images, volumes, and encryption key. Archive split into parts (`dle-template.tar.gz.part-*`) for easier download.
- [Release v1.0.2](https://github.com/VC-HB3-Accelerator/DLE/releases/tag/v1.0.2) — previous version.
- [Release v1.0.1](https://github.com/VC-HB3-Accelerator/DLE/releases/tag/v1.0.1) — previous version.
- [Release v1.0.0](https://github.com/VC-HB3-Accelerator/DLE/releases/tag/v1.0.0) — previous version.
### Run the application
### Запуск приложения
```bash
docker-compose up -d
```
### Доступ к приложению
### Access
#### Продакшн (production)
- **Frontend**: http://localhost:9000 (HTTP)
#### Production
- **Frontend:** http://localhost:9000 (HTTP)
### Stop
### Остановка
```bash
docker-compose-down
docker-compose down
```
### Контакты
### Contacts
- **Email:** info@hb3-accelerator.com
- **Поддержка:** https://hb3-accelerator.com/
- **Support:** https://hb3-accelerator.com/
---
**Russian documentation:** [README.ru.md](README.ru.md) | [docs.ru](docs.ru/) (incl. [FAQ](docs.ru/FAQ.md))

73
README.ru.md Normal file
View File

@@ -0,0 +1,73 @@
# Digital Legal Entity (DLE) — шаблон приложения
## Определение продукта
**Digital Legal Entity (DLE)** — микросервисная платформа с веб-приложением для локальной установки на серверах компании.
**Включает:**
- Инструменты настройки ИИ-агентов
- Систему смарт-контрактов с поддержкой:
- Налоговых, бухгалтерских, банковских и иных идентификаторов, установленных регулятором
**Преимущества:**
- Управление и автоматизация бизнес-процессов
- Замена разрозненных SaaS-сервисов с ежемесячными подписками
- Соответствие требованиям регуляторов к хранению и обработке данных
## Доступные документы
| Файл | Краткое описание |
| --- | --- |
| [application-description.md](docs.ru/application-description.md) | Обзор назначения платформы, ключевых преимуществ и экономического эффекта. |
| [ai-assistant.md](docs.ru/ai-assistant.md) | ИИ-агенты: архитектура, создание агентов под бизнес-процессы, примеры и экономический эффект. |
| [blockchain-for-business.md](docs.ru/blockchain-for-business.md) | Бизнес-обоснование и кейсы использования блокчейна в DLE. |
| [security.md](docs.ru/security.md) | Модель безопасности, контроль доступа и защитные механизмы. |
| [service-terms.md](docs.ru/service-terms.md) | Подробные условия приобретения и обслуживания лицензии. |
| [FAQ.md](docs.ru/FAQ.md) | Часто задаваемые вопросы. |
### Смежные материалы
- [Юридические документы](legal.ru/README.md) — лицензия, авторские права, требования к атрибуции
- [Документация на английском](README.md) — [docs.en](docs.en/) (в т.ч. [FAQ](docs.en/FAQ.md))
## Полный шаблон приложения Digital Legal Entity для развертывания на собственной инфраструктуре.
## Требования
- Docker и Docker Compose
## Быстрый запуск
### Автоматическая установка (рекомендуется)
**Для Linux/macOS/WSL:**
```bash
curl -fsSL https://raw.githubusercontent.com/VC-HB3-Accelerator/DLE/main/setup.sh | bash
```
Скрипт автоматически скачивает последние артефакты из релиза и разворачивает `docker-data`.
### Релизы и артефакты
- [Релиз v1.0.3](https://github.com/VC-HB3-Accelerator/DLE/releases/tag/v1.0.3) (Latest) — содержит полный шаблон приложения с Docker образами, томами и ключом шифрования. Архив разделен на части (`dle-template.tar.gz.part-*`) для удобства загрузки.
- [Релиз v1.0.2](https://github.com/VC-HB3-Accelerator/DLE/releases/tag/v1.0.2) — предыдущая версия.
- [Релиз v1.0.1](https://github.com/VC-HB3-Accelerator/DLE/releases/tag/v1.0.1) — предыдущая версия.
- [Релиз v1.0.0](https://github.com/VC-HB3-Accelerator/DLE/releases/tag/v1.0.0) — предыдущая версия.
### Запуск приложения
```bash
docker-compose up -d
```
### Доступ к приложению
#### Продакшн (production)
- **Frontend**: http://localhost:9000 (HTTP)
### Остановка
```bash
docker-compose-down
```
### Контакты
- **Email:** info@hb3-accelerator.com
- **Поддержка:** https://hb3-accelerator.com/

21
docs.en/FAQ.md Normal file
View File

@@ -0,0 +1,21 @@
**English** | [Русский](../docs.ru/FAQ.md)
# DLE — Frequently Asked Questions
## General
**Q: What is DLE?**
A: Digital Legal Entity (DLE) is a microservices platform with a web application for on-premise deployment. It includes AI agents, smart contracts, CRM, and blockchain governance. See [Platform description](application-description.md).
**Q: How do I install DLE?**
A: Use the [Setup guide](back-docs/setup-instruction.md). Quick start: Docker Compose; see root [README](../../README.md).
**Q: Where are the terms of service and licensing?**
A: [Terms of Purchase and Service](service-terms.md). Legal overview: [legal.en/README.md](../../legal.en/README.md).
**Q: How do I get support?**
A: https://hb3-accelerator.com/ | info@hb3-accelerator.com
---
*This FAQ will be expanded. For full documentation see the [docs.en](.) index and [README](../../README.md).*

188
docs.en/ai-assistant.md Normal file
View File

@@ -0,0 +1,188 @@
**English** | [Русский](../docs.ru/ai-assistant.md)
# DLE AI Agents — Building Specialized Business Agents
> **Concept:** one local model — many specialized agents. Each agent is tailored to a specific business process: its own prompt, rules, knowledge base, and interface.
## Table of Contents
1. [What and Why](#what-and-why)
2. [Architecture](#architecture)
3. [How to Create an Agent](#how-to-create-an-agent)
4. [Agent Examples](#agent-examples)
5. [Technology Stack](#technology-stack)
6. [Advantages Over Cloud Solutions](#advantages-over-cloud-solutions)
7. [Economic Impact](#economic-impact)
---
## What and Why
DLE provides **tools to create AI agents** — specialized assistants, each responsible for a distinct business process.
This is not one generic chatbot. It is a **builder** where you:
- Create an agent for a specific task (support, content, procurement, analytics)
- Set its role via system prompt
- Attach a knowledge base (RAG tables) with relevant data
- Configure behavior rules (strict, creative, hybrid)
- Bind to channels (web chat, Telegram, Email)
- Get an isolated specialist working 24/7
All agents use **one local Ollama model** on your server. They differ by system prompts, rules, and connected data. Data never leaves your server.
---
## Architecture
### Principle: One Model — Many Agents
One Ollama instance (e.g. qwen2.5:7b) serves multiple agents. Each has its own prompt, rules, RAG tables, channels, and UI. Agents are isolated and do not affect each other.
### Request Flow
User request → agent determined by channel/route → agent config (prompt, rules, RAG) → query vectorization (Ollama mxbai-embed-large) → RAG search (FAISS) → LLM response with RAG context + system prompt + history → optional cache (TTL 1 h) → response to user.
---
## How to Create an Agent
### Step 1. Basic Info
- **Name** — e.g. “Support Agent”, “Content Editor”, “AI Procurement”
- **Role** — support, content_editor, analyst, purchaser, etc.
- **Description** — what the agent is for
### Step 2. System Prompt
Defines identity and behavior. Examples:
**Support:** “You are a professional customer support assistant. Answer only from the knowledge base. If no answer — suggest contacting an operator. Do not invent prices, terms, or conditions.”
**Content editor:** “You are a professional content marketer and editor. Use company style from the knowledge base. Follow platform guidelines. Use keywords and hashtags from the base.”
### Step 3. Rules (JSON)
```json
{
"searchRagFirst": true,
"generateIfNoRag": false,
"checkUserTags": true,
"temperature": 0.3,
"maxTokens": 500
}
```
| Parameter | Effect | Support | Content | Analytics |
|-----------|--------|----------|---------|-----------|
| temperature | Creativity (0.01.0) | 0.3 | 0.7 | 0.2 |
| searchRagFirst | Search knowledge base first | true | true | true |
| generateIfNoRag | Generate if not in base | false | true | false |
| maxTokens | Max response length | 500 | 2000 | 1000 |
### Step 4. Knowledge Base (RAG Tables)
Attach spreadsheets the agent will search: Support → FAQ, product docs; Content → platform instructions, style, examples, keywords; Procurement → supplier base, terms, prices. Tables need columns designated as “Question for AI” and “Answer for AI” for vector indexing.
### Step 5. Channels and Interface
Channels: web chat, Telegram, Email, SMS. Route: e.g. `/content-editor`. Set which roles can access.
### Step 6. Activate
Enable the agent; it starts handling requests on the selected channels.
---
## Agent Examples
### 1. Customer Support Agent
**Task:** answer customer questions 24/7 from the knowledge base. Strict mode (only from base), temperature 0.3, RAG: FAQ, docs. Channels: web chat, Telegram, Email. If no answer → suggest operator.
### 2. Content Editor Agent
**Task:** create social posts, blog articles, emails in company style. Creative mode, temperature 0.7, RAG: platform instructions, style, examples, keywords, CTAs. Interface: `/content-editor`, Editor role.
### 3. AI Procurement Agent
**Task:** help choose suppliers and compare terms. Hybrid mode, temperature 0.5, RAG: supplier base, terms and prices. Example: “Who supplies electronics with delivery up to 3 days?” → top 3 from table with filters.
### 4. Other Possible Agents
Analyst (reports, trends), HR assistant (screening, policies), Translator (glossaries, style), Legal assistant (contracts, norms). Each = new combination of prompt, rules, and tables.
---
## Technology Stack
| Component | Technology | Purpose |
|-----------|------------|---------|
| LLM | Ollama (qwen2.5:7b or other) | Generation, dialogue |
| Embedding | mxbai-embed-large | Text vectorization |
| Vector DB | FAISS | Semantic search |
| Main DB | PostgreSQL | Agents, knowledge, history |
| Cache | Node.js Map + TTL | Fast repeat queries (< 50ms) |
| Queue | AI Queue | Priority processing |
| Encryption | AES-256 | Prompts and settings encrypted |
### RAG Search Methods
Semantic (FAISS), keyword, hybrid (e.g. 70% semantic, 30% keyword). Optional: fuzzy search, stemming, keyword extraction.
---
## Advantages Over Cloud Solutions
| | DLE (local) | ChatGPT API | Claude API |
|-|-------------|-------------|------------|
| **Cost** | $0 | ~$0.02/request | ~$0.03/request |
| **Confidentiality** | 100% on your server | Data at OpenAI | Data at Anthropic |
| **Speed (cached)** | < 50ms | 5002000ms | 5002000ms |
| **Offline** | Yes | No | No |
| **Business tuning** | Full: prompts, rules, RAG | Limited | Limited |
| **API limits** | None | Yes | Yes |
| **Number of agents** | Unlimited | Separate API per use | Separate API per use |
---
## Economic Impact
### API Cost Savings
| Requests/month | ChatGPT API | Claude API | DLE |
|----------------|-------------|------------|-----|
| 10,000 | $2,400/year | $3,600/year | $0 |
| 50,000 | $12,000/year | $18,000/year | $0 |
| 100,000 | $24,000/year | $36,000/year | $0 |
### Process Automation Savings
Each agent replaces routine work. Example for a mid-size company: support agent ($57,600), procurement ($64,800), HR ($57,600), content ($86,400), analyst ($144,000), partners ($43,200), training ($30,000), API savings ($24,00036,000) **total about $507,600519,600/year**. DLE license: $1,000 one-time.
### 5-Year Comparison with SaaS
Typical SaaS stack (CRM, chatbot, email, AI API): ~$39,000 over 5 years. DLE: $1,000 + $0 AI + free updates 5 years **savings about $38,000**.
---
## Additional Materials
- [Multi-agent architecture](./back-docs/multi-agent-architecture.md) technical spec
- [AI assistant setup](./back-docs/setup-ai-assistant.md) deployment steps
- [Tables system](./back-docs/tables-system.md) RAG tables
- [FAQ](./FAQ.md)
---
## Support
- **Email:** info@hb3-accelerator.com
- **Chat:** https://hb3-accelerator.com
- **Docs:** [FAQ](./FAQ.md)
---
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
**Last updated:** February 2026

View File

@@ -0,0 +1,195 @@
**English** | [Русский](../docs.ru/application-description.md)
# Digital Legal Entity (DLE) — Platform Description
## Definition
**Digital Legal Entity (DLE)** is a microservices platform with a web application for on-premise deployment on company servers. It includes tools for configuring AI agents and a smart contract system with support for tax, accounting, banking, and other identifiers set by the regulator.
It provides management and automation of business processes, allows moving away from fragmented SaaS services with monthly subscriptions, and meets regulator requirements for data storage and processing.
---
## Table of Contents
1. [Who It's For](#who-its-for)
2. [Why DLE, Not SaaS](#why-dle-not-saas)
3. [Main Capabilities](#main-capabilities)
4. [Economic Impact](#economic-impact)
5. [Technical Details](#technical-details)
6. [Purchase Terms](#purchase-terms)
7. [Documentation](#documentation)
---
## Who It's For
DLE is for organizations that need their own IT infrastructure with transparent governance:
- Commercial organizations (LLC, JSC, sole proprietors, holdings)
- Non-profit organizations (NPOs, foundations, associations)
- Government bodies (municipalities, agencies)
- Investment and venture funds
- Startups and small business
- Cooperatives and associations
---
## Why DLE, Not SaaS
| Parameter | DLE | Typical SaaS |
|-----------|-----|--------------|
| Cost | $1,000 one-time | $200-500/month |
| Data ownership | On your server | At provider |
| Customization | Full (source code) | Limited |
| AI | Local, no limits, $0 | Cloud, paid API |
| Blockchain | Built-in | No |
| Updates | Free for 5 years | Depends on plan |
| Regulatory compliance | Full (data on-premise) | Depends on provider |
---
## Main Capabilities
### 1. AI Agents
One local Ollama model — many specialized agents. Each agent is tailored to a specific business process: its own prompt, rules, and knowledge base (RAG tables).
You create agents for company tasks: customer support, analytics, accounting, HR, marketing, procurement, and any other processes. Data never leaves your server.
More: [DLE AI Agents](./ai-assistant.md)
### 2. CRM and Contact Management
- Centralized contact database with interaction history
- Grouping by tags and categories
- Tasks and reminders
- Import/export (CSV, Excel)
- Document and template builder
### 3. Omnichannel Communications
Single interface for all channels: Telegram bot, Email, Web chat, SMS, web forms. One context per client across channels. AI auto-replies trained on your data.
### 4. Blockchain Governance and Tokenization
- Smart contracts with regulator identifier support
- Asset tokenization (real estate, IP, equity)
- Governance through token holder voting
- Multichain support (Ethereum, Polygon, BSC, Arbitrum, Optimism, Avalanche, Base)
More: [Blockchain for Business](./blockchain-for-business.md)
### 5. Groups and Team Spaces
- Customizable spaces for projects
- Granular permissions (20+ types)
- Roles: Editor, ReadOnly, User
- Integration with CRM and communications
### 6. Internal Tools
- Spreadsheets (Excel-like)
- Analytics and reporting
- Metrics monitoring
- WebSSH for server management
### 7. Security
- TLS 1.3, AES-256 encryption
- SIWE (wallet sign-in), sessions in DB
- Granular permissions (20+ types), token gating
- GDPR, CCPA, 152-FZ compliance
- All data on your server
More: [DLE Security](./security.md)
---
## Economic Impact
### 5-Year Comparison with SaaS
| Expense | SaaS stack | DLE |
|---------|------------|-----|
| CRM | $12,000 | — |
| Chatbot | $9,000 | — |
| Email campaigns | $6,000 | — |
| AI (API) | $12,000 | — |
| **Total** | **$39,000** | **$1,000** |
Savings: $38,000 over 5 years. Pay once — use indefinitely.
### Local AI vs Cloud APIs
| | DLE (local) | Cloud APIs |
|-|-------------|------------|
| Cost | $0 | ~$0.02-0.03/request |
| Confidentiality | Data on your server | Data at provider |
| Limits | None | Yes |
| Offline | Yes | No |
| Business tuning | Full (agents, RAG) | Limited |
---
## Technical Details
### Technology Stack
| Component | Technology |
|-----------|------------|
| Frontend | Vue.js 3, Vite, Element Plus |
| Backend | Node.js, Express |
| Database | PostgreSQL, pgvector |
| AI | Ollama (qwen2.5:7b), FAISS Vector Search |
| Blockchain | Ethers.js v6, Hardhat |
| Containerization | Docker Compose |
### Minimum Requirements
| Parameter | Value |
|-----------|-------|
| CPU | 4 cores |
| RAM | 12 GB (app + AI + Vector Search) |
| Storage | 100 GB SSD |
| OS | Ubuntu 20.04+, Debian 11+, CentOS 8+ (any Linux with Docker) |
### Deployment
One-command installation via Docker Compose. More: [Setup Guide](./back-docs/setup-instruction.md)
---
## Purchase Terms
| Package | Price | Tokens | Votes |
|---------|-------|--------|-------|
| Standard | $1,000 USDT (one-time) | 1 | 1 |
| Premium | $10,000 USDT (one-time) | 10 | 10 |
Perpetual license, full source code, free updates 5 years, technical support, governance tokens on blockchain, ready document pack for regulator.
More: [Terms of Purchase and Service](./service-terms.md)
---
## Documentation
**Product:**
- [AI Agents](./ai-assistant.md) — architecture, agent examples, setup
- [Blockchain for Business](./blockchain-for-business.md) — asset tokenization, use cases
- [Security](./security.md) — multi-layer protection, compliance
- [Terms of Service](./service-terms.md) — licensing, support, warranties
- [FAQ](./FAQ.md) — frequently asked questions
**General:**
- [Main page](../README.md)
- [Legal documentation](../legal.en/README.md)
---
**Contacts:** info@hb3-accelerator.com · https://hb3-accelerator.com · [GitHub](https://github.com/VC-HB3-Accelerator)
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
**Last updated:** 2026-02-19

View File

@@ -0,0 +1,109 @@
**English** | [Русский](../../docs.ru/back-docs/MULTICHAIN_GOVERNANCE_TOKEN_TRANSFER.md)
# DLE Multichain Governance Token Transfer
## Overview
The DLE multichain governance system lets token holders create proposals to transfer tokens from their wallet to another address (or treasury) through voting in every network where the DLE contract is deployed. Each network has its own quorum; proposals are coordinated and shown as a single card.
## Architecture
- One DLE can be deployed on several chains (e.g. Sepolia, Arbitrum Sepolia, Base Sepolia).
- Each DLE contract per chain runs independently.
- Proposals are created, voted on, and executed **per chain**.
- Proposal IDs are **unique per chain** (e.g. ID=1 on Sepolia and ID=1 on Arbitrum Sepolia are different).
Proposals with the same description and initiator are **grouped** into one card showing status and voting in all chains.
---
## Process: Token transfer
### Stage 1: Create proposal
1. User fills form: description, recipient address, amount (tokens), voting duration, connected wallet (sender).
2. System determines all networks with deployed DLE.
3. **Sequential creation per chain:** switch MetaMask to each network (1 s delay), call DLE `createProposal(...)`, get proposal ID for that chain, delay 3 s (5 s Base Sepolia) after tx. Retry on RPC errors (e.g. up to 3 with exponential backoff).
4. User signs **one transaction per chain** in MetaMask.
**Contract:** `createProposal(description, duration, operation, targetChains, timelockDelay)`.
**Operation:** `_transferTokens(sender, recipient, amount)`**signature `_transferTokens(address,address,uint256)`**. All three parameters required. **Sender** must be initiator (from `signer.getAddress()` when creating in **that** chain). **Amount** must be in wei: `ethers.parseUnits(amount.toString(), 18)`.
**Encoding (ethers.js):** use Interface with `_transferTokens(address,address,uint256)` and encode sender (from signer for current chain), recipient, amountInWei. **Critical:** encode operation **inside** the loop over chains so sender is correct per chain.
**Result:** N proposals (one per chain), each with its own ID; UI shows one card with status per chain.
---
### Stage 2: Voting
1. User sees one card with all chains.
2. Chooses vote For or Against.
3. **Sequential voting:** for each active chain (state active, not executed/canceled): switch network, 1 s delay, **check token balance in that chain** (if none, skip with warning), call `vote(proposalId, support)` with **that chains proposal ID**, delay after tx.
4. One MetaMask signature per active chain.
**Contract:** `vote(proposalId, support)`. Use per-chain proposal ID. Quorum is per chain. Balance checked per chain; if no tokens in a chain, skip voting there.
---
### Stage 3: Execute proposal
**Condition:** Proposal can be executed only when it is **ReadyForExecution** (and quorum reached) **in every** chain where it is active.
1. System checks readiness in all chains.
2. **Sequential execution:** for each ready chain: switch network, 1 s delay, call `executeProposal(proposalId)` with **that chains ID**, delay after tx.
3. One signature per ready chain.
**Contract:** `executeProposal(proposalId)`. Operation `_transferTokens(sender, recipient, amount)`: sender = initiator (checked), recipient and amount from proposal. Tokens are transferred from initiators wallet.
---
## Cancel proposal
Only initiator can cancel, while proposal is active. **Sequential cancel** in all active chains (switch network, delay, `cancelProposal(proposalId, reason)`), one signature per chain.
---
## Important details
1. **Proposal IDs:** Each chain has its own counter. Same numeric ID on different chains = different proposals. UI stores per-chain IDs and uses them for vote/execute/cancel.
2. **Grouping:** Key `${description}_${initiator}`. One card = one logical proposal across chains.
3. **Quorum:** Independent per chain. Execution requires quorum **in all** chains.
4. **Sequential operations:** Create, vote, execute, cancel are done **one chain at a time** (no `Promise.all`) because MetaMask works with one network at a time.
5. **Errors:** Retry on retryable RPC errors; if one chain fails, continue others and report. On vote, skip chains where user has no balance (with warning).
6. **Security:** Sender must equal initiator on execute; balance checked per chain; state and data validated before each call.
7. **Token source:** Tokens are transferred **from the initiators wallet**, not from the contract balance.
---
## UI (summary)
Card: description, initiator, list of chains (name, status, proposal ID, For/Against, quorum), actions: Vote For/Against (if active), Execute (if ready in all), Cancel (if initiator). Statuses: Active, Ready for execution, Executed, Canceled, Expired.
---
## Contract functions (reference)
- `createProposal(description, duration, operation, targetChains, timelockDelay)` → proposalId
- `vote(proposalId, support)`
- `executeProposal(proposalId)`
- `cancelProposal(proposalId, reason)`
- `_transferTokens(sender, recipient, amount)` (internal)
---
## Encoding and implementation notes
- **Correct:** Encode `_transferTokens(sender, recipient, amountInWei)` **inside** the chain loop with `sender = await signer.getAddress()` for that chain. Use `ethers.parseUnits(amount.toString(), 18)`.
- **Wrong:** Encode once before loop; use `_transferTokens(address,uint256)`; omit sender; wrong parameter order in `createProposal`.
- **Wrong:** Use `Promise.all` for execute/vote across chains (MetaMask cannot handle multiple networks in parallel).
All critical encoding and multichain flow issues in the codebase are documented as fixed; implementation follows this spec and the contract.
---
## Conclusion
Multichain governance for DLE provides decentralized token transfer decisions with per-chain quorums and a single UI for managing proposals across all deployed networks.
**Important:** All critical bugs in operation encoding have been fixed; code matches the documentation and contract.

View File

@@ -0,0 +1,82 @@
**English** | [Русский](../../docs.ru/back-docs/TASK_REQUIREMENTS.md)
# Task: Multichain Governance System for DLE
## Status
- ✅ Transfer proposal form works
- ✅ Proposals created in all DLE chains
- ✅ Voting in each chain separately
- ✅ Quorum per chain
- ✅ Personal transfer from proposal initiator
- ✅ Proposals grouped by description + initiator
- ✅ Server coordination with cryptographic proofs
- ✅ No hardcoded chains — deployedNetworks from API
## Context
DLE (Digital Legal Entity) is a decentralized legal entity with contracts in multiple blockchain networks. The task is to implement token governance via multichain governance: token holders can transfer tokens through voting with quorum.
## Architecture
- **Frontend:** Vue.js with Web3
- **Backend:** Node.js for coordination and API
- **Smart contracts:** DLE contracts in each supported network
- **Database:** PostgreSQL for metadata
- **WebSocket:** Real-time sync across networks
## Supported networks
- Ethereum Sepolia (chainId: 11155111)
- Arbitrum Sepolia (chainId: 421614)
- Base Sepolia (chainId: 84532)
## Functional requirements
### 1. Transfer tokens proposal form
**URL:** `/management/transfer-tokens?address=<DLE_ADDRESS>`
**Fields:** Recipient address (required), Amount (tokens, required), Description (optional), Voting duration (days, required).
### 2. Proposal creation
1. Get `deployedNetworks` from API `/dle-v2`
2. Create proposals in all DLE networks (sequentially with MetaMask; one proposal per chain)
3. Encode operation: `_transferTokens(sender, recipient, amount)` — sender = initiator
### 3. Voting
1. Voting is per chain
2. Quorum per chain: `(forVotes / totalSupply) >= quorumPercentage`
3. Vote weight = voters token balance
### 4. Execution
1. Each contract checks its local quorum
2. Backend aggregates quorum results and can sign global status
3. Execution with global quorum proof or per-chain execution
## Technical spec (summary)
- **Proposal:** id, description, forVotes, againstVotes, executed, canceled, deadline, initiator, operation, targetChains, snapshotTimepoint, hasVoted
- **_transferTokens(sender, recipient, amount)** internal; emits TokensTransferredByGovernance
- **Backend:** QuorumCoordinator (collect results, generate global proof)
- **API:** GET /dle-v2, POST create/vote/execute proposal endpoints
- **Frontend:** TransferTokensFormView (validation, encode operation, create in all chains), DleProposalsView (grouped list, status per chain, vote/execute)
## Security
On-chain checks (balance, deadlines, quorum), cryptographic proofs for global quorum, validation, graceful degradation if a chain is down.
## Testing
Acceptance: form works; proposals in all chains; voting per chain; quorum per chain; transfer from initiator; server coordination; grouping; error handling. Cases: create in multichain; vote when one chain down; execute with global quorum; execute with partial quorum (must fail); sufficient/insufficient initiator balance.
## Deployment
Backend with RPC to all networks, DB, SSL, monitoring. Env: RPC URLs, DATABASE_URL, SERVER_PRIVATE_KEY for signing.
---
Fully functional multichain governance for DLE tokens is implemented, with decentralized decisions and optional trusted-server coordination with cryptographic proofs.

View File

@@ -0,0 +1,165 @@
**English** | [Русский](../../docs.ru/back-docs/blockchain-integration-technical.md)
# Digital Legal Entity (DLE) Blockchain Integration
## Table of Contents
1. [Introduction](#introduction)
2. [Smart Contract Architecture](#smart-contract-architecture)
3. [DLE Core Contract](#dle-core-contract)
4. [Module System](#module-system)
5. [Multichain Architecture](#multichain-architecture)
6. [Voting (Governance) System](#voting-governance-system)
7. [Smart Contract Deployment](#smart-contract-deployment)
8. [Wallet Authentication](#wallet-authentication)
9. [Frontend Integration](#frontend-integration)
10. [Security](#security)
11. [Practical Examples](#practical-examples)
---
## Introduction
Digital Legal Entity (DLE) uses blockchain for **tokenized governance** (similar to a blockchain-based joint-stock company) and **transparent decision-making** via smart contracts.
### Why Blockchain in DLE?
1. **Governance like a joint-stock company** — decisions by token holders through on-chain voting
2. **Transparency** — all votes and operations recorded on blockchain
3. **Censorship resistance** — smart contract enforces token holder rights
4. **Immutability** — decision history cannot be altered
5. **Multichain support** — operation across multiple chains
### DLE Governance Model
| Aspect | Implementation |
|--------|----------------|
| **Voting** | Token holders (as shareholders) |
| **Quorum** | 51%+ of tokens to pass decisions |
| **Asset distribution** | Via voting (as in JSC) |
| **Parameter changes** | Via token holder voting |
| **Application code** | Proprietary (author) |
| **Updates** | Author develops; token holders vote on priorities |
### Supported Blockchains
DLE works with **EVM-compatible** networks: Ethereum (mainnet & testnets), Polygon, Arbitrum, BSC, Base, and others.
---
## Smart Contract Architecture
DLE ecosystem: **DLE Core Contract** (ERC20Votes, tokens, proposals, multichain) ↔ **Modules** (HierarchicalVotingModule, TreasuryModule, TimelockModule) ↔ **DLEReader** (batch reads, RPC optimization).
Standards: OpenZeppelin ERC20, ERC20Votes, ERC20Permit, ReentrancyGuard, ECDSA.
---
## DLE Core Contract
File: `backend/contracts/DLE.sol`
Structures: **DLEInfo** (name, symbol, location, coordinates, jurisdiction, okvedCodes, kpp, creationTimestamp, isActive), **Proposal** (id, description, forVotes, againstVotes, executed, canceled, deadline, initiator, operation, governanceChainId, targetChains, snapshotTimepoint, hasVoted).
### Main Features
- **Governance tokens (ERC20):** 1 token = 1 vote; transfers disabled (only via governance); EIP-712 for meta-transactions.
- **Voting (ERC20Votes):** snapshots (flash-loan protection), votes from past block, optional delegation.
- **Multichain:** same address across chains (deterministic deploy); voting on one chain; execution on target chains.
- **Modules:** mapping(bytes32 => address) modules, activeModules; add/remove only via voting.
### Operations Available via Voting
_addModule, _removeModule, _addSupportedChain, _removeSupportedChain, _transferTokens, _updateDLEInfo, _updateQuorumPercentage, _updateVotingDurations.
---
## Module System
### 1. HierarchicalVotingModule
DLE can hold tokens of other DLEs and vote in them. Functions: addExternalDLE, createProposalInExternalDLE, voteInExternalDLE.
### 2. TreasuryModule
Treasury and asset management. transferTokens(token, recipient, amount) only callable by DLE contract. getTokenBalance(token).
### 3. TimelockModule
Delayed execution (timelock), cancel before execution. scheduleProposal(proposalId, operation, delay), executeTimelockProposal(operationHash).
### 4. DLEReader
Batch read: getDLEFullInfo(dleAddress), getAllProposals(dleAddress).
---
## Multichain Architecture
Deterministic deploy: same address on all chains. Voting on one chain (governance chain); execution on target chains via executeWithSignatures(proposalId, operationHash, signers, signatures).
---
## Voting (Governance) System
**createProposal(description, duration, operation, chainId, targetChains, initiator)** — returns proposalId.
**vote(proposalId, support)** — true = For, false = Against.
**execute(proposalId)** — when deadline passed, quorum reached, For > Against, not executed.
**Quorum:** quorumPercentage of totalSupply; change only via voting.
---
## Smart Contract Deployment
**Script:** `backend/scripts/deploy/deploy-multichain.js` — multichain deploy, deterministic address, verification, retry, nonce management. Run: `yarn deploy:multichain`.
**Modules:** `backend/scripts/deploy/deploy-modules.js``yarn deploy:modules`. Config in DB (settings: supported_chain_ids, rpc_providers, dle_config). Verification via Etherscan API; supported: Etherscan, Polygonscan, Arbiscan, BSCScan, Basescan.
---
## Wallet Authentication
**SIWE (Sign-In with Ethereum):** request nonce → sign message in wallet → POST signature → backend verifies signature and token balance → session created. getUserAccessLevel(address) from contract balance and thresholds (editor, readonly).
---
## Frontend Integration
Connect wallet (MetaMask/WalletConnect), sign SIWE message, authenticateWithWallet. getDLEContract, createProposal, voteOnProposal, getProposal. Vue component example for proposal card and vote buttons.
---
## Security
See [DLE Security](../security.md). Summary: ReentrancyGuard, transfers disabled, vote snapshots, EIP-712, parameter validation, custom errors.
---
## Practical Examples
See [Blockchain for Business](../blockchain-for-business.md). Technical scenarios: multichain deploy, adding modules, hierarchical voting, treasury management.
---
## Conclusion
Blockchain in DLE provides: governance like a JSC, full transparency, multichain support, modular design, OpenZeppelin-based security.
### Resources
- [Main README](../../README.md)
- [FAQ](../FAQ.md)
- [Setup](./setup-instruction.md)
- [Terms](../service-terms.md)
- [Legal](../../legal.en/README.md)
**Contacts:** https://hb3-accelerator.com/ | info@hb3-accelerator.com | https://github.com/VC-HB3-Accelerator
---
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
**Last updated:** October 2025

View File

@@ -0,0 +1,118 @@
**English** | [Русский](../../docs.ru/back-docs/multi-agent-architecture.md)
# Multi-Agent AI Architecture in DLE
> **Concept:** Separate specialized agents for different tasks, using one local Ollama model with different system prompts, rules, and interfaces.
---
## Table of Contents
1. [Architecture concept](#architecture-concept)
2. [Agent types](#agent-types)
3. [System architecture](#system-architecture)
4. [Agent configuration](#agent-configuration)
5. [Agent interfaces](#agent-interfaces)
6. [Knowledge base](#knowledge-base)
7. [Agent workflow](#agent-workflow)
---
## Architecture concept
### Principles
1. **One model, many agents** — all use one Ollama instance (e.g. qwen2.5:7b); differentiation by prompts and rules.
2. **Isolation** — each agent has its own prompt, rules, RAG tables, channels, route, permissions.
3. **Task specialization** — support (user Q&A), content editor (posts, articles), others (analyst, translator, procurement).
4. **Separate interfaces** — each agent has its own UI and access path.
---
## Agent types
### 1. Support agent
**Role:** Answer user messages. Uses RAG (FAQ, docs), strict mode (minimal generation), system prompt “professional support assistant”. Interface: chat (web, Telegram, email). Knowledge: FAQ, product docs, client knowledge base.
### 2. Content editor agent
**Role:** Create content on request. RAG: platform instructions, company style, examples. Creative mode. System prompt “content marketer and editor”. Interface: `/content-editor` page. Knowledge: platform instructions, style, examples, keywords, CTAs.
### 3. Other possible agents
Analyst (reports, trends), Translator (localization), Procurement (suppliers, terms).
---
## System architecture
Single Ollama model → multiple agents (Support, Content editor, Others), each with own prompt, rules, RAG, interface.
**Storage:** table `ai_agents` — id, name, role, description, system_prompt_encrypted, rules_id, selected_rag_tables, enabled_channels, interface_route, permissions_required, is_active. Links to `ai_assistant_rules` and RAG tables.
---
## Agent configuration
Steps: (1) Basic info — name, role, description. (2) System prompt. (3) Rules (from or new). (4) RAG tables. (5) Interface — route, permissions, channels. (6) Activate and test.
Example: Support — strict (temperature 0.3, searchRagFirst, no generateIfNoRag), FAQ + docs, chat. Content editor — creative (0.7, generateIfNoRag), instructions + style + examples, `/content-editor`, web only.
---
## Agent interfaces
**Support:** embedded in main chat (HomeView); auto on message; expand/collapse; history.
**Content editor:** page `/content-editor` — request field, content type, platform, generate → edit → save/export, history. Editor role only.
---
## Knowledge base
Support: FAQ, Documentation, Client knowledge base. Content editor: Platform instructions, Company style, Content examples, Keywords, CTAs. RAG search → context → LLM; each agent only sees its own tables.
---
## Agent workflow
**Support:** message → RAG search (FAQ, docs) → if found use it, else suggest operator → send reply.
**Content editor:** request + type + platform → RAG (instructions, style, examples, keywords) → generate content → show in UI → edit/save/export.
---
## Advantages
Specialization, flexibility, isolation, scalability (one model, many agents), clear responsibility.
---
## Comparison: single vs multiple agents
| | Single agent | Multiple agents |
|--|--------------|-----------------|
| Specialization | General, less precise | Per-task, more precise |
| Configuration | One set for all | Per task |
| Knowledge base | Shared | Isolated per agent |
| Interface | One | Per agent |
| Flexibility | Harder to adapt | Easy to add agents |
---
## Next steps
1. Create `ai_agents` table
2. Agent management service
3. Adapt AI Assistant for multiple agents
4. Content editor UI
5. Support agent (adapt existing)
6. Content editor knowledge base
7. Test both agents
---
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
**Last updated:** January 2026

View File

@@ -0,0 +1,132 @@
**English** | [Русский](../../docs.ru/back-docs/setup-ai-assistant.md)
# AI Assistant Setup with Vector Search
## Full guide to launching the intelligent assistant
This document describes the step-by-step setup of the AI assistant for business tasks using spreadsheets and vector search.
---
## What you will have after setup
✅ Working AI assistant with local model (Ollama)
✅ Knowledge base for customer answers (FAQ)
✅ Supplier and procurement automation
✅ Staff training system
✅ Vector search over your data
✅ Significant time and cost savings
> 💡 **Economics:** See [DLE AI Agents](../ai-assistant.md) for architecture, examples, and savings.
---
## Time required
- **Quick setup:** 2030 minutes (basic FAQ)
- **Full setup:** 12 hours (all features)
---
## Step 1: Install and run Ollama
1. **Settings****Integrations****Ollama****Details**
2. Check status: “Ollama is running” or “Ollama API not responding”
3. If not running: `docker-compose up -d ollama` or `ollama serve`
4. **Install model:** e.g. qwen2.5:7b (recommended), llama2:7b, mistral:7b
5. **Install embedding model:** mxbai-embed-large:latest (recommended) or nomic-embed-text:latest
> ⚠️ Embedding model is required for RAG (vector search).
---
## Step 2: Create knowledge base (spreadsheets)
### 2.1 FAQ table
1. **Tables****+ Create table**
2. Name: e.g. “FAQ Frequently asked questions”, description for AI
3. **Add columns:**
- **Question** — type Text, **purpose: Question for AI** (required for RAG)
- **Answer** — type Text, **purpose: Answer for AI**
- **Product** (optional) — Multiselect, purpose: Product filter
- **Tags** (optional) — Multiselect, purpose: User tags
- **Priority** (optional) — Number, purpose: Priority
### 2.2 Fill with sample Q&A
Add rows: e.g. “How to pay?” / “We accept card, PayPal, bank transfer…”; “Delivery time?” / “35 business days…”; “Return policy?” / “Within 14 days…”. Minimum ~2030 questions recommended.
### 2.3 Enable as AI source
In table settings enable **“Use as source for AI”** and save. Table is then indexed for vector search.
---
## Step 3: AI provider (Ollama) settings
1. **Settings****Integrations****Ollama**
2. Base URL: Docker `http://ollama:11434`, local `http://localhost:11434`
3. **LLM model:** e.g. qwen2.5:7b
4. **Embedding model:** mxbai-embed-large:latest
Save.
---
## Step 4: AI Assistant settings
1. **Settings****Integrations****AI Assistant****Details**
2. **System prompt** — e.g. “You are a professional support assistant. Answer from the knowledge base. If not found, suggest contacting an operator. Always end with How else can I help?’”
3. **Models:** select same LLM and embedding as above
4. **Selected RAG tables:** choose your FAQ table
5. **Rules (JSON):** e.g. `searchRagFirst: true`, `generateIfNoRag: true`, `temperature: 0.7`, `maxTokens: 500`
6. **RAG search:** e.g. Hybrid, max results 5, relevance threshold 0.1; optional keyword extraction, fuzzy search, stemming
Save.
---
## Step 5: Test
1. **RAG tester** (on assistant settings page): choose table, ask e.g. “How to pay?” → check answer and score (good: about -300 to 0).
2. **Web chat:** open main page, ask e.g. “What is the delivery cost?” — answer should come from your FAQ.
3. Try questions inside and outside the knowledge base; test with typos (fuzzy search).
---
## Step 6 (optional): Extra tables and channels
- **Suppliers table:** columns for company, category, contact, email, phone, prices, payment terms, delivery, rating. Enable as AI source; add prompt instructions for “TOP-3 suppliers” style answers.
- **Staff knowledge base:** questions/answers by category (Sales, HR, IT). Same RAG setup.
- **Telegram:** create bot via @BotFather, add token and username in Settings → Integrations → Telegram; link to AI assistant.
- **Email:** IMAP/SMTP in Settings; for Gmail use app password. Link to AI assistant.
---
## Step 7: Monitoring and tuning
- **Status:** Settings → AI Assistant → Monitoring: Backend, Postgres, Ollama, Vector Search should be green.
- **RAG quality:** Score -300…0 = good; >300 = not found. Improve by adding variants of questions and adjusting relevance threshold.
- **Speed:** Smaller model or fewer RAG results if responses are slow.
---
## Troubleshooting
- **Ollama not responding:** `docker-compose restart ollama`, check logs.
- **Wrong answers:** Check RAG score; add more questions; lower relevance threshold; ensure column purposes “Question for AI” and “Answer for AI”.
- **Vector search error:** Install embedding model; on table page use “Rebuild index”; ensure table is enabled as AI source.
- **Wrong language:** Add “Always answer in English” (or desired language) to system prompt; choose suitable model (e.g. qwen2.5:7b for multilingual).
---
## Technical reference (developers)
- **DB:** ai_providers_settings, ai_assistant_settings, ai_assistant_rules (encrypted fields, RAG tables, rules JSON).
- **API:** GET/PUT settings per provider and assistant; rules CRUD; Ollama status, models, install.
- **Flow:** Message → UnifiedMessageProcessor → language check → dedup → load settings and rules → RAG search → generate LLM response → return. Security: AES-256 for sensitive fields; admin-only for settings.
---
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
Version: 1.0.0 | Date: October 25, 2025

View File

@@ -0,0 +1,157 @@
<!--
Copyright (c) 2024-2025 Alexander Viktorovich Tarabanov
All rights reserved.
This software is proprietary and confidential.
Unauthorized copying, modification, or distribution is prohibited.
For licensing inquiries: info@hb3-accelerator.com
Website: https://hb3-accelerator.com
GitHub: https://github.com/VC-HB3-Accelerator
-->
**English** | [Русский](../../docs.ru/back-docs/setup-instruction.md)
# Digital Legal Entity — Application Setup Guide
## Full system initialization
This document describes the full process of preparing the application for use with blockchain, smart contracts, and the access control system.
---
## Step 1: Install software
1. Clone the project repository to your machine
2. Run the application via Docker Compose or locally as per your setup
3. Open the web app in a browser: `http://localhost:9000` (production) or `http://localhost:5173` (dev)
---
## Step 2: Connect crypto wallet
1. Ensure a browser wallet is installed (MetaMask, WalletConnect, or similar)
2. Create or import an account that holds governance tokens
3. In the web app click **"Connect wallet"**
4. Choose wallet type and confirm connection
5. After success you will see your account address in the top corner
---
## Step 3: Add RPC providers (Security → RPC providers)
1. Go to **Settings****Security** tab
2. Find **"RPC providers"**
3. Click **"Add"**
4. For each blockchain network fill in:
- **Network name** (e.g. Ethereum, Polygon, BSC)
- **RPC URL** (e.g. `https://eth-mainnet.g.alchemy.com/v2/YOUR-API-KEY`)
- **Chain ID**
5. Click **"Save"** for each provider
6. The system will verify the connection
> ⚠️ **Important:** Obtain API keys from providers (Alchemy, Infura, QuickNode, etc.) before adding
---
## Step 4: Multichain smart contract deployment
1. Go to **Settings****Blockchain** tab
2. Fill in the form
3. Click **"Start deployment"**
---
## Step 5: Complete deployment and save contract address
1. Wait for deployment to finish (typically 30120 seconds)
2. After success the **"Contract management"** page opens
3. **Copy the deployed contract address** (e.g. `0x742d35Cc6634C0532925a3b844Bc...`)
---
## Step 6: Configure authentication via smart contract
1. Return to **Settings****Authentication** tab
2. In **"Smart contract address"** paste the address from step 5
3. Set access thresholds:
- **Minimum tokens for editing** (e.g. 100)
- **Minimum tokens for viewing** (e.g. 1)
---
## Step 7: AI and database configuration
1. Go to **Settings****AI** tab
2. Open **"Database"** subsection
3. Change default passwords
4. Click **"Generate new encryption key"**
- The system creates a cryptographic key
- **Store the key securely** (needed for data recovery)
---
## Step 8: Internet access (optional)
If you need external access to the web app:
1. Go to **Settings****Server** tab
2. Select **WEB SSH** or another suitable service
3. Fill in the form to migrate the local app to a host with public IP and domain
4. Click **"Publish"**
5. Wait for migration to complete
> Requires a registered domain and DNS access
---
## Step 9: Legal documents for personal data
### 9.1 Company legal information
1. Go to **CRM****Content**
2. Open the **"Company legal information"** form
3. Fill in: full name, short name, legal form, legal address, actual address, Tax ID/OGRN/KPP, contacts, DPO responsible person, applicable jurisdiction (GDPR, CCPA, etc.)
4. Click **"Save"**
### 9.2 Document templates
1. In **Content** go to **"Templates"**
2. Select templates: Privacy Policy, User Agreement, Consent to data processing, Cookie policy
3. For each: **Preview**, edit if needed, then **Publish for public** / **Publish for internal** / **Print** (PDF)
4. Confirm; documents are added to the app
> ⚠️ Consult a lawyer before publishing to ensure legal compliance
---
## Application ready
After these steps the application is fully configured.
**Next:**
- AI assistant setup: see `setup-ai-assistant.md`
- Smart contract management: see `manage-smart-contracts.md`
---
## Security tips
✓ Store contract addresses and encryption keys securely
✓ Use strong DB passwords
✓ Back up configuration regularly
✓ Never share wallet private keys
✓ Use HTTPS in production
---
## Documentation
- [AI Agents](../ai-assistant.md)
- [Blockchain for Business](../blockchain-for-business.md)
- [Security](../security.md)
- [Blockchain technical docs](./blockchain-integration-technical.md)
- [FAQ](../FAQ.md)
- [Application description](../application-description.md)
**Support:** https://hb3-accelerator.com/ | info@hb3-accelerator.com

View File

@@ -0,0 +1,68 @@
**English** | [Русский](../../docs.ru/back-docs/system-messages-management.md)
# Technical Specification: System Messages Management
## 1. Goal and context
- Manage display of system messages on the home page (`/`, `HomeView.vue`) and provide an admin UI for creating and moderating them in Content (`/content`, `ContentListView.vue`).
- System messages support statuses “draft” and “published”, are stored in the database, and exposed via REST API.
## 2. Current state
- Home is built by `HomeView.vue` with assistant chat (`ChatInterface.vue`); system messages are those with `message.role === 'system'` (`Message.vue`).
- Content (`ContentListView.vue`) has cards: Create page, Templates, Published, Settings, Internal. No entity or API for system messages yet; `pagesService.js` only handles pages (`/pages`).
## 3. User scenarios
- **View on home (/):** Published system messages loaded into assistant chat as collapsible cards with clickable title. On click: expand to show full text **or** send a prepared AI assistant reply (content stored with message, chosen by `reply_type`). Messages visually marked as system; optional “read” state in localStorage.
- **Content section:** New card “System messages” with “Details” → `/content/system-messages/table` (user table, no separate dashboard). Table: rows per message, checkboxes for bulk: publish, unpublish, move to draft, delete. Row “Details” → view/edit form.
- **Create/Edit:** Routes `/content/system-messages/create`, `/content/system-messages/:id/edit`. Form: title, summary, main content (Markdown/HTML), reply type (`inline` | `assistant_reply`), assistant reply content (when `assistant_reply`), severity (info/warning/danger), publish_at, expire_at, visible to guests. Buttons: Save as draft, Publish; on edit: Update, Unpublish, Delete. Validation: title and main content (or assistant reply when applicable) required; expire_at ≥ publish_at.
## 4. UI requirements
- In `ContentListView.vue` add “System messages” card to `management-blocks`.
- Table page: BaseLayout, scoped styles; sort, filter by status, search by title; header and row checkboxes; action bar when selection exists; “Create message” opens create form.
- Form: rich text (at least Markdown), preview, character/word count; reply type switch with conditional “Assistant reply” field; severity presets (icon/color).
## 5. Routing and components
- Routes: `/content/system-messages/table` → SystemMessagesTableView; `/content/system-messages/create` → SystemMessageCreateView; `/content/system-messages/:id` → SystemMessageDetailsView; `/content/system-messages/:id/edit` → SystemMessageEditView.
- Components under `src/views/content/system-messages/` and shared in `src/components/system-messages/`.
- Service: `src/services/systemMessagesService.js`.
## 6. API and data
- **Table** `system_messages`: id (uuid), title, summary, content, reply_type (inline | assistant_reply), assistant_reply_content, severity (info | warning | danger), status (draft | published), visible_for (all | authenticated | guests), publish_at, expire_at, created_at, updated_at, created_by, updated_by, slug.
- **REST:** GET /system-messages (pagination, filters), GET /system-messages/published (public, by date/audience), GET /system-messages/:id (editors), POST, PATCH, DELETE; optional POST publish/unpublish.
- Auth and permission (e.g. MANAGE_LEGAL_DOCS) on protected endpoints. New migration, validation (e.g. Joi), logging (winston).
## 7. Frontend logic
- **HomeView:** On load, fetch published messages (by audience) via `systemMessagesService.getPublished({ includeExpired: false })`; cache; on expand either show content (inline) or trigger sending assistant_reply_content; optional “read” in localStorage.
- **ContentListView:** Add “System messages” card.
- List: pagination, sort by date, status badges.
- Form: client-side validation; on publish redirect to list; on draft save stay with notification.
## 8. Security and access
- Create/edit for roles with PERMISSIONS.MANAGE_LEGAL_DOCS.
- GET /system-messages/published: filter by status=published, publish_at ≤ now, expire_at > now (or null), visible_for by guest/auth.
- In chat response hide created_by, updated_by, internal fields. CSRF, CORS, rate-limit as in existing routes.
## 9. Testing
- Backend: CRUD tests in tests/system-messages/*.test.js (Mocha); filters and role access; migration rollback/apply.
- Frontend: unit tests for form and list if present; E2E: draft → publish → visible on home.
- Regression: existing content list and assistant chat still work; `yarn lint`, `yarn test`.
## 10. Integration and DevOps
- Update docker-compose if needed (e.g. migrations on startup). Document new env vars in README and setup-instruction. Optional seed script for test messages.
## 11. Open points
- Audit history (system_messages_history)? Multi-language? WebSocket event for new messages (wsHub)?
## 12. Deliverables
Backend: routes, controllers, service, migration. Frontend: pages, service, updated routes, HomeView, ContentListView. Docs: README, application-description or tables-system if schemas change, this spec.

View File

@@ -0,0 +1,188 @@
**English** | [Русский](../../docs.ru/back-docs/tables-system.md)
# DLE Spreadsheet (Tables) System
> **Internal working document**
---
## Table of Contents
1. [System overview](#system-overview)
2. [Database architecture](#database-architecture)
3. [Field types](#field-types)
4. [Features](#features)
5. [Table relations](#table-relations)
6. [AI (RAG) integration](#ai-rag-integration)
7. [API reference](#api-reference)
8. [Examples](#examples)
9. [Security](#security)
---
## System overview
### What it is
The tables system in DLE is a **full database with a GUI** — similar to **Notion Database** or **Airtable** — built into the app.
### Features
- 6 field types (text, number, relation, lookup, multiselect, multiselect-relation)
- Relations between tables (1:1, 1:N, N:N)
- Lookup and data rollup
- Filtering and sorting
- Real-time updates (WebSocket)
- AI integration (RAG search)
- AES-256 encryption for data
- Placeholders for API access
- Cascade delete, bulk operations
### vs Excel/Sheets
| | Excel/Sheets | DLE Tables |
|-|--------------|------------|
| Data typing | Weak | Strict (6 types) |
| Relations | No | Yes (relation, lookup) |
| AI search | No | Yes (RAG, vector) |
| Real-time | Partial | Full (WebSocket) |
| Encryption | No | AES-256 |
| API | Limited | Full REST |
---
## Database architecture
### Main tables (PostgreSQL)
- **user_tables:** id, name_encrypted, description_encrypted, is_rag_source_id, created_at, updated_at
- **user_columns:** id, table_id, name_encrypted, type_encrypted, placeholder_encrypted, placeholder, options (JSONB), order, created_at, updated_at
- **user_rows:** id, table_id, order, created_at, updated_at
- **user_cell_values:** id, row_id, column_id, value_encrypted, created_at, updated_at, UNIQUE(row_id, column_id)
- **user_table_relations:** id, from_row_id, column_id, to_table_id, to_row_id, created_at, updated_at
Cascade: delete table → columns, rows, cell values, relations. Indexes on relation columns for performance.
---
## Field types
1. **Text** — plain text
2. **Number** — numeric
3. **Multiselect** — multiple choices from a list (options.choices)
4. **Multiselect-relation** — multiple rows from another table (options: relatedTableId, relatedColumnId); stored in user_table_relations
5. **Relation** — single row in another table (1:1 or N:1); one row in user_table_relations
6. **Lookup** — value pulled from related table (options: relatedTableId, relatedColumnId, lookupColumnId)
---
## Features
### CRUD
- **Create table:** POST /tables (name, description, isRagSourceId); name/description encrypted
- **Add column:** POST /tables/:id/columns (name, type, order, purpose, options)
- **Add row:** POST /tables/:id/rows (auto index for RAG if applicable)
- **Save cell:** POST /tables/cell (row_id, column_id, value); upsert; update vector store
- **Delete row:** DELETE /tables/row/:rowId (rebuild vector store)
- **Delete column:** DELETE /tables/column/:columnId (cascade relations and cell values)
- **Delete table:** DELETE /tables/:id (admin; cascade all)
### Filtering
- GET /tables/:id/rows?product=… — by product
- ?tags=… — by user tags
- ?relation_&lt;columnId&gt;=&lt;to_row_ids&gt; — by relation
- ?multiselect_&lt;columnId&gt;=… — by multiselect
### Placeholders
Auto-generated from column name (transliteration, uniqueness). Used for API: GET /tables/:id/data?fields=placeholder1,placeholder2.
### Order
PATCH /tables/:id/rows/order with array of { rowId, order }.
### WebSocket
Events: table-update, table-relations-update, tags-update. Frontend subscribes and reloads when needed.
### Bulk
Select rows (checkboxes); bulk delete or other actions; after delete, vector store rebuilt as needed.
---
## Table relations
- **N:1 (Relation):** one column links to one row in another table (e.g. Task → Project).
- **N:N (Multiselect-relation):** multiple links (e.g. Contacts → Tags).
- **Lookup:** show a field from the related row (e.g. Order → Product → Product.price).
API: GET/POST/DELETE on /tables/:tableId/row/:rowId/relations (column_id, to_table_id, to_row_id or to_row_ids for multiselect).
---
## AI (RAG) integration
- Tables (or selected tables) can be **RAG sources**. Columns with **purpose** “question” and “answer” are used for vector indexing.
- On row create/update: rows with question/answer are upserted into vector store (FAISS). On row delete: rebuild for that table.
- **Rebuild index:** POST /tables/:id/rebuild-index (admin). Reads question/answer columns and rebuilds vector index.
- **RAG flow:** User asks → vector search in table(s) → top_k results with score and metadata (answer, product, userTags, priority) → LLM gets context and generates reply. Filter by product/tags in metadata if needed.
---
## API reference (summary)
- **Tables:** GET/POST /tables, GET/PATCH/DELETE /tables/:id
- **Columns:** POST /tables/:id/columns, PATCH/DELETE /tables/column/:columnId
- **Rows:** POST /tables/:id/rows, DELETE /tables/row/:rowId, PATCH /tables/:id/rows/order
- **Cell:** POST /tables/cell (upsert)
- **Filtered rows:** GET /tables/:id/rows?…
- **RAG:** POST /tables/:id/rebuild-index
- **Relations:** GET/POST/DELETE …/row/:rowId/relations
- **Placeholders:** GET /tables/:id/placeholders, GET /tables/placeholders/all
---
## Examples
### FAQ for AI
Create table with columns: Question (purpose: question), Answer (purpose: answer), Product (multiselect, purpose: product), Tags (multiselect, purpose: userTags). Add rows; enable as RAG source. AI will search by question and return answer; filter by product/tags.
### CRM
Tables: Companies (name, website, industry), Contacts (name, email, company relation, company website lookup). Relation from Contact to Company; lookup “company website” from Company via relation.
### Tasks
Tables: Projects (name, status), Tasks (name, project relation, priority, status). Filter tasks by project: GET .../rows?relation_&lt;projectColumnId&gt;=&lt;projectRowId&gt;.
---
## Security
- **Encryption:** AES-256 for name_encrypted, description_encrypted, value_encrypted, placeholder_encrypted. placeholder and options can be plain for indexing/performance.
- **Access:** View for authenticated users; edit for users with edit rights; delete and rebuild-index for admins (e.g. userAccessLevel.hasAccess). Token balance checked for access level.
- **SQL:** Parameterized queries only. Validate types, existence, uniqueness (e.g. placeholder). Cascade deletes to avoid orphaned data. Optional rate limiting on tables routes.
---
## Performance
- Parallel queries for table meta, columns, rows, cell values where possible. Indexes on user_table_relations. UNIQUE(row_id, column_id) for fast upsert. WebSocket instead of polling. Optional server-side cache for frequent GET /tables/:id.
Typical: GET /tables 50100 ms, GET /tables/:id 150300 ms, POST cell 100200 ms, rebuild-index 15 s. Tables up to ~10k rows fine; larger may need pagination/lazy load.
---
## Limits and future
Current: no server-side pagination, no formulas, no grouping, no change history, limited server-side sort. Possible: pagination, sort params, formula fields, audit table, export/import, table templates.
---
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
Version: 1.0.0 | Date: October 25, 2025 | Status: Internal

View File

@@ -0,0 +1,231 @@
**English** | [Русский](../docs.ru/blockchain-for-business.md)
# Blockchain Integration for Business: Solving Real Problems
## Table of Contents
1. [Introduction: Why Business Needs Blockchain](#introduction-why-business-needs-blockchain)
2. [Smart Contract as Universal Identifier](#smart-contract-as-universal-identifier)
3. [Asset Tokenization](#asset-tokenization)
4. [Solving Governance Problems](#solving-governance-problems)
5. [Financial Operations Without Banks](#financial-operations-without-banks)
6. [Transparency and Trust](#transparency-and-trust)
7. [Automation and Cost Reduction](#automation-and-cost-reduction)
8. [Practical Use Cases](#practical-use-cases)
9. [Economic Impact](#economic-impact)
---
## Introduction: Why Business Needs Blockchain
### Traditional Business Problems
| Problem | Consequences | Costs |
|---------|--------------|-------|
| Multiple bank accounts | Complex accounting, fees | 2-5% of turnover |
| Bureaucracy | Slow decisions, paperwork | 20-30% of time |
| Opaque governance | Shareholder conflicts, corruption | Up to 40% of value |
| Illiquid assets | Cannot quickly sell/divide | Lost opportunities |
| Geographic restrictions | Difficulties with international partners | Missed profit |
| Slow transactions | 3-7 days for bank transfers | Capital freeze |
### Solution: Digital Legal Entity on Blockchain
DLE turns a company into a **digital organization** with blockchain identity:
- One smart contract address = full company identification
- Any assets tokenized and easily manageable
- Transparent governance through voting
- Instant financial operations without intermediaries
- Global availability 24/7
---
## Smart Contract as Universal Identifier
### Concept: One Address for Everything
In traditional business, a company has many identifiers: Tax ID/EIN, bank accounts (local currency, USD, EUR), email, phone, legal address, multiple accounting systems.
**With DLE:** one smart contract address (e.g. `0x742d35Cc6634C0532925a3b844Bc9377F91cAB6C`) replaces everything: tax identifier, bank account (multi-currency), email/phone for communications, legal identity, asset accounting system.
### Key Benefits
- **Tax identifier:** one address in all countries; link to Tax ID/EIN/VAT stored in contract; instant verification, impossible to forge.
- **Bank account:** address accepts USDT, USDC, ETH, any ERC20; fees 50-100x lower; transactions in 30 seconds; 24/7 operation.
- **Communications:** contract address = message address; cryptographic signatures; omnichannel integration (blockchain, Telegram, email, web).
---
## Asset Tokenization
**Tokenization** — turning any asset into a digital token on blockchain: fast buy/sell, fractional ownership, exchange, value tracking, instant transfer worldwide.
### Asset Types
| Asset | Traditional problem | DLE solution |
|-------|---------------------|--------------|
| Real estate | Illiquidity, 3-6% fees, cannot divide | Tokens = shares; sale in 30 sec; 0.1% fee; auto rent distribution |
| Shares and equity | IPO expensive and slow; LLC shares illiquid | “IPO” in 1 day; $100-1,000 instead of $500,000+; auto dividend payouts |
| IP (patents, music) | Complex licensing, opaque royalties | Tokens = revenue shares; automatic royalties; secondary market |
| Goods and inventory | “Dead” capital in warehouse | Tokens = shares in goods; liquidity; hedging |
| Jewellery, art | High entry barrier | Fractional ownership from $20; liquidity; transparent custody |
### Treasury Model
Company assets are placed in the Treasury Module of the smart contract. Token holders own shares proportionally to tokens. Asset income is distributed automatically.
---
## Solving Governance Problems
### Traditional Issues
- **Opacity:** closed meetings, no record of decisions, votes unverifiable.
- **Slowness:** from proposal to registration — 3 months.
- **High costs:** $31,500-161,000/year (accountant, lawyer, notary, registry, audit).
- **Corruption:** conflicts of interest hard to track.
### DLE Solution
- Every proposal (Proposal) is public: ID, description, initiator, For/Against votes, date, result.
- Voting 1-7 days instead of 3 months; automatic execution in 30 seconds.
- Costs: $200-2,000/year (gas, RPC, hosting) instead of $31,500-161,000.
- Conflicts of interest detected automatically (ownership transparency).
### Hierarchical Governance
DLE can hold tokens of other DLEs (holding). Parent company votes in subsidiaries automatically; consolidated governance; transparent structure; auto dividends bottom-up.
---
## Financial Operations Without Banks
### Comparison
| Parameter | Bank | DLE (crypto) |
|-----------|------|---------------|
| Transfer time | 3-7 days | 30 sec - 5 min |
| Fee | $25-50 + 2-5% conversion | $0.10-5 |
| Operating hours | Mon-Fri, 9:00-18:00 | 24/7/365 |
| Freezes | Possible | Not possible |
**Example:** $100,000 transfer to China — traditionally $3,080 in fees + 5 days; with DLE (USDT) — $2 + 30 seconds.
### DLE Capabilities
- **Multi-currency treasury:** one address holds USDT, USDC, EURC, ETH, BTC, tokenized assets.
- **Auto payouts:** dividends and salaries — one transaction, everyone receives in 30 seconds.
- **Global payments:** no geographic limits (subject to local laws and taxes).
---
## Transparency and Trust
Blockchain is the source of truth. Every token holder sees in real time: treasury assets, liabilities, operation history. Impossible to hide expenses, withdraw funds secretly, or fake balance.
Every decision is recorded forever: initiator, votes, owners, status. History cannot be rewritten. Ownership transparency allows automatic detection of conflicts of interest.
DLE reputation: immutable operation history, partner ratings, public metrics, verified assets.
---
## Automation and Cost Reduction
### Removing Intermediaries
Traditional transaction: 7-12% fees + 3-7 days. Blockchain: $0.10-5, 30 seconds. Savings on $1M turnover: $69,500-119,500 (99%).
### Process Automation
| Process | Before | After |
|---------|--------|-------|
| Decision-making | 55-85 days, $2,000-10,000 | 1-7 days, $2-5 |
| Dividend payout | 10-17 days, $500-2,000 | 30 sec, $5-20 |
| Audit and reporting | $13,000-90,000/year | $0 (blockchain = continuous audit) |
| Escrow | $500-2,000 | Smart contract $5 |
| Multisig | Notary $100-500 | $2-10 |
---
## Practical Use Cases
### Case 1: Startup Raising Investment
**Situation:** tech startup seeking $500,000.
**Traditional:** 10-19 months; lawyers $20,000-50,000, valuers $5,000-10,000, registration $2,000-5,000. Total: $27,000-65,000.
**With DLE:** create DLE in 1 day; issue 10M tokens (70% founders, 30% investors); list on DEX in 3 days; deploy $100, listing $500. Total: 4 days + $600.
**Result:** 90x faster, 45-100x cheaper, access to global investors, instant liquidity.
### Case 2: Real Estate Fund
**Situation:** fund owns $10M office building, needs funds for new project.
**Traditional:** bank loan 12-18%, setup 2-3 months, valuation+lawyers $50,000; or sale 6-18 months, fee 3-5% ($300,000-500,000); or REIT $50,000-200,000, 6-12 months.
**With DLE:** tokenization in 1 day (10M tokens at $1); sell 30% in 2 weeks → $3M; rent $100,000/month auto-distributed (70% fund, 30% holders); cost $1,000.
**Result:** $3M in 2 weeks, asset retained (70%), passive income continues, cost $1,000 vs $50,000-200,000.
---
## Economic Impact
### Summary Table (business with $1M/year turnover, 10 employees, 5 shareholders)
| Item | Traditional | With DLE | Savings |
|------|-------------|----------|---------|
| Bank fees | $26,950/year | $1,200/year | $25,750 (96%) |
| Corporate governance | $54,000/year | $12,000/year | $42,000 (78%) |
| Raising investment (1 deal) | $50,000 | $600 | $49,400 (99%) |
| **Total direct savings** | | | **$117,150/year** |
| Additional profit from speed | — | ~$1,000,000 | Missed opportunities |
**ROI:** 1,117% on DLE adoption. Payback: < 1 month.
### Comparison with Competitors
| Solution | Cost/year | Fees | Speed | Transparency |
|----------|-----------|------|-------|--------------|
| Traditional business | $54,000+ | 3-7% | 3-7 days | Low |
| SaaS solutions | $12,000-60,000 | 2-5% | 1-3 days | Medium |
| DLE on blockchain | $1,200-3,000 | 0.01-0.5% | 30 sec | Full |
---
## Conclusion
Digital Legal Entity addresses fundamental business problems:
1. **Financial freedom:** operations without banks, instant transfers, 99% fee savings.
2. **Universal identity:** one address = all identifiers, cryptographic protection.
3. **Tokenization:** any asset liquid, fractional ownership from $1, global market 24/7.
4. **Transparent governance:** every shareholder sees everything, auto-execution, protection from corruption.
5. **Automation:** smart contracts instead of lawyers, 90-99% time and money savings.
**For a business with $1M/year turnover:** savings $117,000/year; additional profit ~$1,000,000; ROI 1,117%; payback < 1 month.
### Get Started
1. [Read the FAQ](../FAQ.md) answers to common questions
2. [Install DLE](./back-docs/setup-instruction.md) step-by-step guide
3. [Configure blockchain](./back-docs/blockchain-integration-technical.md) technical documentation
4. [Get support](https://hb3-accelerator.com/) we can help!
---
## Additional Resources
- [FAQ](../FAQ.md)
- [Installation](./back-docs/setup-instruction.md)
- [Blockchain technical documentation](./back-docs/blockchain-integration-technical.md)
- [Terms of Service](./service-terms.md)
- **Support:** https://hb3-accelerator.com/ | info@hb3-accelerator.com
---
**© 2024-2026 Alexander Viktorovich Tarabanov. All rights reserved.**
**Last updated:** February 2026

193
docs.en/security.md Normal file
View File

@@ -0,0 +1,193 @@
**English** | [Русский](../docs.ru/security.md)
# Digital Legal Entity (DLE) Security
## Table of Contents
1. [Introduction](#introduction)
2. [Security Model](#security-model)
3. [Token-Based Access Control](#token-based-access-control)
4. [Smart Contract Security](#smart-contract-security)
5. [Wallet Compromise Protection](#wallet-compromise-protection)
6. [Web Application Security](#web-application-security)
7. [Module Management](#module-management)
8. [Audit and Monitoring](#audit-and-monitoring)
9. [Security Recommendations](#security-recommendations)
10. [Attack Scenarios and Mitigation](#attack-scenarios-and-mitigation)
---
## Introduction
Digital Legal Entity (DLE) is built with **security at every layer**:
- Access control via blockchain tokens
- Smart contract protection from compromise
- Tokens cannot be stolen even if wallet is compromised
- Governance only through voting with quorum
### Key Security Principles
1. **Secure by default** — all actions denied until explicitly allowed
2. **Least privilege** — each entity gets only required rights
3. **Transparency** — all actions recorded on blockchain
4. **Immutability** — history cannot be forged
5. **Collective control** — critical operations only through voting
---
## Security Model
### Security Architecture
```
┌─────────────────────────────────────────────────────────────┐
│ DLE Protection Layers │
├─────────────────────────────────────────────────────────────┤
│ │
│ Layer 1: Blockchain (Immutable Base) │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ • DLE smart contract (audited, immutable) │ │
│ │ • Governance tokens (ERC20Votes) │ │
│ │ • Full operation history on blockchain │ │
│ │ • Rules cannot change without voting │ │
│ └───────────────────────────────────────────────────────┘ │
│ ↑ │
│ Layer 2: Web Application (Backend) │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ • Real-time token checks │ │
│ │ • Wallet authentication (SIWE) │ │
│ │ • Data encryption (AES-256) │ │
│ │ • Rate limiting and DDoS protection │ │
│ └───────────────────────────────────────────────────────┘ │
│ ↑ │
│ Layer 3: Frontend (Vue.js) │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ • Wallet connection │ │
│ │ • Transaction signing │ │
│ │ • XSS protection (DOMPurify) │ │
│ │ • CSRF tokens │ │
│ └───────────────────────────────────────────────────────┘ │
│ ↑ │
│ Layer 4: User │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ • Wallet private key (MetaMask, WalletConnect) │ │
│ │ • Confirmation for each operation │ │
│ └───────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
```
### Threat Model
| Threat | Risk level | Mitigation |
|--------|------------|------------|
| **Wallet compromise** | Medium | Tokens cannot be transferred without voting |
| **Web app compromise** | Low | All rights checked on blockchain, governance via blockchain explorers |
| **Smart contract compromise** | Low | Audit, OpenZeppelin, immutability |
| **DDoS** | Medium | Rate limiting, CDN, backup servers |
| **Phishing** | High | User education, domain verification |
| **Insider threat** | Low | All actions through voting |
### Critical: Web Application Is Only an Interface
**Key DLE architecture point:**
The web app (frontend + backend) provides **convenience**. It may be compromised or unavailable — **but business assets remain protected**. Real control and assets are on the blockchain; you can manage via Etherscan/Polygonscan etc. and deploy a new frontend connected to the same contracts.
**If the web app is compromised:** assets stay on chain, contracts keep working, tokens cannot be stolen, governance is possible via blockchain explorers, and a new frontend can be deployed.
---
## Token-Based Access Control
**Without tokens, access to the application is NOT possible.**
Access flow: user connects wallet → backend checks token balance in smart contract → if no tokens → access denied; if tokens exist → access granted (level depends on amount).
### Access Levels
| Token balance | Access level | Rights |
|---------------|--------------|--------|
| **0 tokens** | ❌ No access | "No access" page only |
| **1+ tokens** | ✅ ReadOnly | View data |
| **100+ tokens** | ✅ Editor | Edit, create |
| **Any amount** | 🗳️ Voting | 1 token = 1 vote |
Token checks run on every request; balance is read from the contract. If tokens are transferred away, access is lost immediately; if received, access is granted. The check cannot be bypassed.
---
## Smart Contract Security
**CRITICAL:** Governance tokens **cannot** be transferred by normal means. `transfer`, `approve`, and `transferFrom` are disabled and revert. Tokens can only be moved through governance (voting with quorum). Transfers use snapshots for voting power to prevent flash-loan attacks. All parameters are validated; custom errors save gas.
---
## Wallet Compromise Protection
If an attacker obtains a private key: they cannot send tokens (transfer disabled), sell on DEX (approve disabled), or use transferFrom. They could only create a proposal to transfer tokens to themselves — which requires other token holders to vote and reach quorum, so it will usually fail.
Protections: Timelock (delayed execution so others can react), multisig for critical ops, and cold/hardware wallets for large holders.
---
## Web Application Security
- **SIWE (Sign-In with Ethereum):** nonce generated and stored encrypted; signature verified; private key never leaves wallet.
- **Data encryption:** AES-256 for wallet addresses, nonces, session data, private messages.
- **Rate limiting** on API and stricter limits on auth.
- **CSRF** and **XSS** (DOMPurify) protection.
- **Helmet.js** for secure headers.
- **Clean logs:** sensitive data (addresses, nonces) redacted.
---
## Module Management
Only the DLE smart contract can call module functions (`onlyDLE` modifier). Owner, backend, or attacker cannot call modules directly. Adding/removing modules is only through voting.
---
## Audit and Monitoring
All actions are recorded in contract events (ProposalCreated, ProposalVoted, ProposalExecuted, ModuleAdded, TokensTransferred). Backend subscribes to events and can alert token holders. Critical events can trigger email/Telegram and logging.
---
## Security Recommendations
**For token holders:** Use hardware wallet; store seed phrase safely; enable notifications; review every proposal; split tokens (hot 1020%, cold 8090%).
**For admins:** Regular updates; daily DB backups; log monitoring; encryption key rotation; firewall (only 80/443 if needed).
**For developers:** Audit contracts (Slither, Mythril); run tests and coverage; code review; `yarn audit` for dependencies.
---
## Attack Scenarios and Mitigation
**Phishing:** Backend validates domain in SIWE; frontend can warn if hostname is wrong. Users should check URL and use bookmarks.
**Backend compromise:** Token checks are on-chain; balances and rules cannot be changed by backend. Users can verify on Etherscan and manage via explorers.
**51% attack:** Timelock gives time to react; other holders can vote against or take legal action.
**Social engineering:** Frontend shows what is being signed; support never asks to sign messages. Users should never sign on request from “support”.
---
## Conclusion
DLE provides multi-layer protection: blockchain (tokens not stealable), audited contracts, quorum voting, timelock, backend checks, frontend hardening, and monitoring. Access is token-gated; tokens are protected even if wallet or web app is compromised; governance can continue via blockchain explorers.
### Next Steps
1. [Technical documentation](./back-docs/blockchain-integration-technical.md)
2. [Secure setup](./back-docs/setup-instruction.md)
3. [FAQ](../FAQ.md)
4. [Support](https://hb3-accelerator.com/)
---
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
**Last updated:** October 2025

343
docs.en/service-terms.md Normal file
View File

@@ -0,0 +1,343 @@
**English** | [Русский](../docs.ru/service-terms.md)
# Digital Legal Entity — Terms of Purchase and Service
## Table of Contents
1. [Licensing Model](#1-licensing-model)
2. [Pricing](#2-pricing)
3. [Voting System](#3-voting-system)
4. [Updates and Maintenance](#4-updates-and-maintenance)
5. [Technical Support and Training](#5-technical-support-and-training)
6. [Refunds and Warranties](#6-refunds-and-warranties)
7. [Liability](#7-liability)
8. [Terms of Use](#8-terms-of-use)
9. [Security and Privacy](#9-security-and-privacy)
10. [Governance Smart Contract](#10-governance-smart-contract)
11. [Payment and Sellers](#11-payment-and-sellers)
12. [Changes to Terms](#12-changes-to-terms)
13. [Contacts](#13-contacts)
**Legal documents:** [legal.en/README.md](../legal.en/README.md) — license, copyright, attribution requirements.
---
## 1. Licensing Model
### 1.1. Core Principles
| Parameter | Value |
|-----------|-------|
| License type | Perpetual |
| Term | Unlimited |
| Updates | Free for 5 years for token holders |
| Revocation | License cannot be revoked by the company |
### 1.2. License and Tokens
Each DLE license is tied to a **governance token on the blockchain**. The token confirms the right to use the platform and grants a vote in product development.
| Parameter | 1 token | 10 tokens |
|-----------|---------|-----------|
| Number of licenses | 1 | 1 |
| Lines of business | 1 | 1 |
| Votes in voting | 1 | 10 |
| Service terms | Same | Same |
**Voting:** 1 token = 1 vote. Decisions are made by majority (51%+) via smart contract on the blockchain.
### 1.3. Line of Business
- One license — one line of business.
- Separate licenses required for multiple lines of business.
---
## 2. Pricing
### 2.1. Licenses
| Package | Price | Tokens | Votes |
|---------|-------|--------|-------|
| Standard | $1,000 USDT (one-time) | 1 | 1 |
| Premium | $10,000 USDT (one-time) | 10 | 10 |
All prices are **excluding taxes**. Taxes are the buyers responsibility (VAT, Sales Tax, Income Tax, etc. as per jurisdiction).
### 2.2. Whats Included in Both Licenses
- Perpetual right to use the platform
- Full source code and documentation
- Free updates for 5 years (for token holders)
- Technical support (SLA by issue priority)
- Governance tokens on the blockchain
- Vote in product development
- Access to online training sessions
- Ready document pack for the regulator
The only difference between packages is the number of tokens and thus votes.
### 2.3. Payment Methods
- **Cryptocurrency (USDT)** — directly or via authorized partners
- **Bank transfer** — in local currency via authorized dealers
- **Credit cards** — via partners payment systems
All transfer, conversion, and payment processing fees are borne by the buyer.
### 2.4. Purchase Process
1. Choose seller (authorized dealer or author directly)
2. Agree price in USDT or local currency equivalent
3. Receive payment details
4. Send payment
5. Confirmation and payment document
6. Receive token and platform access
---
## 3. Voting System
### 3.1. Process
1. **Proposal** — community proposes a new feature
2. **Registration** — vote is created in the smart contract on the blockchain
3. **Voting** — each token = 1 vote, For or Against
4. **Decision** — with 51%+ For, the feature is taken into development
### 3.2. Frequency
- Voting is open continuously (asynchronous)
- Quarterly review of results
- Development by priority (vote count)
### 3.3. Voting Portal
**URL:** https://hb3-accelerator.com/
Available: create proposals, vote, view results, track development status, voting history.
**Requirements:** wallet with tokens (MetaMask, WalletConnect, etc.).
---
## 4. Updates and Maintenance
### 4.1. Free Updates (5 Years)
For all license token holders from the token transfer date recorded on the blockchain:
- Bug fixes
- Performance improvements
- New features (approved by voting)
- Security updates
**Frequency:**
| Type | Frequency |
|------|------------|
| Security patches | As soon as found |
| Regular updates | Weekly (Wednesdays) |
| Major features | Per voting results |
### 4.2. Update Platform
**URL:** https://hb3-accelerator.com/
License holders can: download all versions, read release notes, get new version notifications, read migration documentation.
**Access requirement:** license token on wallet at request time.
---
## 5. Technical Support and Training
All license holders get access to support and training via the portal: https://hb3-accelerator.com/
Detailed support terms, training, online sessions, and platform setup are in the [accelerator program](https://github.com/VC-HB3-Accelerator/.github/blob/main/Версия%20на%20русском/accelerator-program.md).
---
## 6. Refunds and Warranties
### 6.1. General
License is perpetual — standard refund is not provided.
### 6.2. 70% Refund Program
**70% of the license price** may be refunded within **5 years** of purchase if all of the following are met:
1. More than **51% negative votes** in token holder voting
2. Complaints concern **lack of update releases**
3. Voting is conducted **via smart contract on the blockchain**
4. Request is submitted **within 5 years** of the license date
**Process:** request at hb3-accelerator.com → confirmation on smart contract → 70% refund within 30 days.
### 6.3. Payment Dispute
Within 30 days of payment — in case of calculation error, double payment, or other justified reasons.
---
## 7. Liability
### 7.1. Authors Warranties
- License is perpetual (right to use not limited in time)
- Updates and basic maintenance free for 5 years
- Core functionality remains available
- Vote in product development
### 7.2. Not Guaranteed
- Specific new features (depend on voting)
- Specific release schedule
- Support when modifying source code
- Performance beyond recommended limits
### 7.3. Limitation of Authors Liability
Author is not liable for: lost profit, indirect damages, data loss, business interruption, reputational harm, fines, or sanctions.
**Maximum liability:** not more than the license fee paid. Only direct damages from direct breach of contract are covered.
### 7.4. User Responsibility
User is responsible for: data backup, use in accordance with the license, protecting wallet private keys, compliance with applicable law, timely application updates.
---
## 8. Terms of Use
### Allowed
- Use for managing own business
- Deployment on own infrastructure
- Data backup
- Local configuration changes
- Voting on product development
- Transfer of license to heirs
### Prohibited
- Resale or sublicensing
- Using one license for more than one line of business
- Reverse engineering and source code modification
- Removal of copyright and license notices
- Sharing between independent organizations
- Educational use without permission
- Deploying SaaS based on the platform
---
## 9. Security and Privacy
| Mechanism | Description |
|-----------|-------------|
| TLS 1.3 | All connections encrypted |
| AES-256 | Critical data encrypted at rest |
| Key management | User controls encryption keys |
| GDPR | Compliance (with DPA) |
More: [DLE Security](./security.md)
---
## 10. Governance Smart Contract
### 10.1. Architecture
DLE uses an on-chain smart contract for licenses and voting:
- **ERC20** — each license is represented by governance tokens (1 or 10)
- **ERC20Votes** — built-in voting
- **ERC20Permit** — signatures for gasless transfers
- **Multichain** — voting supported across multiple networks
### 10.2. Voting via Smart Contract
**Creating proposals:** token holders only. Voting duration: 1 hour to 30 days.
**Process:** proposal → voting (1 token = 1 vote) → quorum 51%+ → execution.
**Execution:** via direct call on the voting chain or via signatures on other chains.
### 10.3. Contract Security
- ReentrancyGuard
- Tokens transfer only through governance
- Vote snapshots vs flash-loans
- EIP-712 signatures for contract wallets
- All parameters validated before execution
### 10.4. License Transfer
License = tokens tied to wallet address. Transfer = moving tokens to a new address through governance. New owner automatically gets voting rights.
---
## 11. Payment and Sellers
### 11.1. Authorized Sellers
Licenses are sold **only through companies** with official written authorization from the author.
**Seller requirements:** legal entity, signed contract, listed on hb3-accelerator.com, compliance with licensing terms.
### 11.2. Seller for Russian Federation
**LLC "ERAYTI"**
- OGRN: 1222600014383
- INN: 2636220809
- Address: 355007, Stavropol Krai, Stavropol, ul. Burmistrova, 65B, premises 2
- Contacts: 18900@эрайти.рф, +7 (968) 269-92-64
### 11.3. Direct Purchase from Author
- Email: info@hb3-accelerator.com
- Website: https://hb3-accelerator.com
- GitHub: https://github.com/VC-HB3-Accelerator
---
## 12. Changes to Terms
### For New Licenses
- Terms may change for new purchases
- 60 days notice before changes take effect
- Applies only to licenses purchased after the change date
### For Existing Licenses
- Your license terms **do not change** after purchase
- Fixed rights apply perpetually
- Backward compatibility is maintained
---
## 13. Contacts
- **Support portal:** https://hb3-accelerator.com/
- **Email:** info@hb3-accelerator.com
- **GitHub:** https://github.com/VC-HB3-Accelerator/DLE
- **Legal status:** Proprietary software (see [LICENSE](../LICENSE))
- **Legal documentation:** [legal.en/README.md](../legal.en/README.md)
---
## Additional Documentation
- [Platform description](./application-description.md)
- [AI Agents](./ai-assistant.md) — specialized agent system
- [Blockchain for Business](./blockchain-for-business.md) — digital asset registration and business use cases
- [DLE Security](./security.md) — multi-layer protection
- [FAQ](./FAQ.md) — frequently asked questions
---
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
**Last updated:** February 2026

21
docs.ru/FAQ.md Normal file
View File

@@ -0,0 +1,21 @@
[English](../docs.en/FAQ.md) | **Русский**
# DLE — Часто задаваемые вопросы
## Общее
**В: Что такое DLE?**
О: Digital Legal Entity (DLE) — микросервисная платформа с веб-приложением для локальной установки. Включает ИИ-агентов, смарт-контракты, CRM и блокчейн-управление. См. [Описание платформы](application-description.md).
**В: Как установить DLE?**
О: По [Инструкции по настройке](back-docs/setup-instruction.md). Быстрый старт: Docker Compose; см. корневой [README](../../README.md).
**В: Где условия обслуживания и лицензирование?**
О: [Условия приобретения и обслуживания](service-terms.md). Обзор юридической документации: [legal.ru/README.md](../../legal.ru/README.md).
**В: Как получить поддержку?**
О: https://hb3-accelerator.com/ | info@hb3-accelerator.com
---
*Этот FAQ будет дополняться. Полная документация — в [docs.ru](.) и [README](../../README.md).*

View File

@@ -1,3 +1,5 @@
[English](../docs.en/ai-assistant.md) | **Русский**
# ИИ-агенты DLE — система создания специализированных агентов для бизнеса
> **Концепция**: одна локальная модель — множество специализированных агентов. Каждый агент заточен под конкретный бизнес-процесс: свой промпт, свои правила, своя база знаний, свой интерфейс.

View File

@@ -1,3 +1,5 @@
[English](../docs.en/application-description.md) | **Русский**
# Digital Legal Entity (DLE) — описание платформы
## Определение
@@ -182,7 +184,7 @@ DLE создано для организаций, которым нужна со
**Общая:**
- [Главная страница](../README.md)
- [Юридическая документация](../legal/README.md)
- [Юридическая документация](../legal.ru/README.md)
---

View File

@@ -0,0 +1,663 @@
[English](../../docs.en/back-docs/MULTICHAIN_GOVERNANCE_TOKEN_TRANSFER.md) | **Русский**
# Мультичейн-управление переводом токенов DLE
## Обзор системы
Система мультичейн-управления DLE позволяет холдерам токенов создавать предложения по переводу токенов со своего кошелька на другой адрес (или в казну) через процесс голосования во всех сетях, где развернут контракт DLE. Каждая сеть имеет независимый кворум, но предложения координируются и отображаются как единое целое.
## Архитектура
### Мультичейн-контракты DLE
- Один DLE может быть развернут в нескольких блокчейн-сетях (например, Sepolia, Arbitrum Sepolia, Base Sepolia)
- Каждый контракт DLE в каждой сети работает независимо
- Предложения создаются, голосуются и выполняются в каждой сети отдельно
- ID предложений уникальны для каждой сети (предложение с ID=1 в Sepolia и предложение с ID=1 в Arbitrum Sepolia - это разные предложения)
### Группировка предложений
- Предложения с одинаковым описанием и инициатором группируются в одну карточку
- Карточка отображает статус предложения во всех сетях DLE
- Каждая сеть в карточке имеет свой собственный ID предложения, состояние и результаты голосования
## Процесс перевода токенов
### Этап 1: Создание предложения
#### Описание процесса
1. Пользователь заполняет форму перевода токенов:
- **Описание предложения** - текстовое описание цели перевода
- **Адрес получателя** - адрес кошелька или казны, на который будут переведены токены
- **Количество токенов** - количество DLE токенов для перевода
- **Длительность голосования** - период времени, в течение которого можно голосовать
- **Ваш подключенный кошелек** - автоматически заполняется адресом подключенного кошелька (токены будут отправлены с этого адреса)
2. Система определяет все сети, где развернут контракт DLE
3. **Последовательное создание предложений в каждой сети:**
- Для каждой сети DLE:
- Переключение MetaMask на соответствующую сеть
- Задержка 1 секунда после переключения
- Создание предложения в контракте DLE этой сети
- Получение уникального ID предложения для этой сети
- Задержка 3 секунды после подтверждения транзакции (5 секунд для Base Sepolia)
- При ошибках RPC выполняется автоматический retry с экспоненциальной задержкой (до 3 попыток)
4. **Подписи в MetaMask:**
- Пользователь должен подписать транзакцию создания предложения в каждой сети DLE
- Количество подписей = количество сетей DLE
- Каждая подпись создает отдельное предложение в соответствующей сети
#### Технические детали
- **Функция контракта:** `createProposal(description, duration, operation, targetChains, timelockDelay)`
- **Порядок параметров:** `description`, `duration`, `operation`, `targetChains` (массив), `timelockDelay`
- **targetChains:** Массив ID сетей, где будет выполнена операция (обычно `[chainId]` для текущей сети)
- **Операция:** `_transferTokens(sender, recipient, amount)` - где `sender` = адрес инициатора предложения
- **Сигнатура:** `_transferTokens(address,address,uint256)` - **все три параметра обязательны!**
- `sender` получается автоматически из `signer.getAddress()` при создании предложения
- **ID предложения:** Генерируется автоматически контрактом в каждой сети (начинается с 0, инкрементируется)
- **Группировка:** Предложения с одинаковым `description` и `initiator` группируются в одну карточку
#### Кодирование операции
Операция для выполнения должна быть закодирована в формате ABI (Application Binary Interface) перед передачей в `createProposal`.
**Для операции перевода токенов `_transferTokens(address,address,uint256)`:**
1. **Сигнатура функции:** `_transferTokens(address,address,uint256)`
2. **Селектор функции:** Первые 4 байта от `keccak256(signature)`
3. **Параметры:**
- `sender` - адрес отправителя (инициатора предложения)
- `recipient` - адрес получателя токенов
- `amount` - количество токенов (в wei, т.е. количество * 10^18)
**Пример кодирования (JavaScript/ethers.js):**
```javascript
// Способ 1: Использование Interface (рекомендуется)
const functionSignature = '_transferTokens(address,address,uint256)';
const iface = new ethers.Interface([`function ${functionSignature}`]);
const encodedOperation = iface.encodeFunctionData('_transferTokens', [
senderAddress, // адрес инициатора
recipientAddress, // адрес получателя
ethers.parseUnits(amount.toString(), 18) // количество в wei
]);
// Способ 2: Ручное кодирование
const functionSignature = '_transferTokens(address,address,uint256)';
const selectorBytes = ethers.keccak256(ethers.toUtf8Bytes(functionSignature));
const selector = '0x' + selectorBytes.slice(2, 10); // первые 4 байта
const abiCoder = ethers.AbiCoder.defaultAbiCoder();
const encodedParams = abiCoder.encode(
['address', 'address', 'uint256'],
[senderAddress, recipientAddress, ethers.parseUnits(amount.toString(), 18)]
);
const encodedOperation = ethers.concat([selector, encodedParams]);
```
**Важные моменты:**
- `sender` должен совпадать с адресом инициатора предложения (проверяется в контракте при выполнении)
- `amount` **ОБЯЗАТЕЛЬНО** передается в wei (1 токен = 10^18 wei) - используйте `ethers.parseUnits(amount.toString(), 18)`
- **КРИТИЧЕСКИ ВАЖНО:** `sender` должен определяться из `signer.getAddress()` при создании предложения в каждой сети отдельно, а не один раз до цикла
- Операция кодируется для каждой сети отдельно с актуальным адресом signer для этой сети
- Контракт декодирует операцию при выполнении и проверяет соответствие `sender` и `initiator`
**КРИТИЧЕСКИ ВАЖНО - Правильная реализация:**
```javascript
// ✅ ПРАВИЛЬНО: Кодирование внутри цикла с актуальным адресом signer для каждой сети
async function createProposalsInAllChains(allChains, formData) {
const results = [];
for (let index = 0; index < allChains.length; index++) {
const chainId = allChains[index];
// 1. Переключаемся на нужную сеть
await switchToVotingNetwork(chainId.toString());
await new Promise(resolve => setTimeout(resolve, 1000)); // Задержка после переключения
// 2. КРИТИЧЕСКИ ВАЖНО: Получаем адрес signer для текущей сети
const provider = new ethers.BrowserProvider(window.ethereum);
const signer = await provider.getSigner();
const senderAddress = await signer.getAddress(); // Адрес инициатора из signer!
// 3. Кодируем операцию с актуальным адресом signer для этой сети
const transferCallData = encodeTransferTokensCall(
senderAddress, // адрес инициатора из signer (обязательно!)
formData.recipient, // адрес получателя
formData.amount // количество (будет сконвертировано в wei)
);
// 4. Создаем предложение
const proposalData = {
description: formData.description,
duration: formData.duration,
operation: transferCallData,
targetChains: [chainId],
timelockDelay: 0
};
await createProposal(contractAddress, proposalData);
}
}
function encodeTransferTokensCall(sender, recipient, amount) {
const functionSignature = '_transferTokens(address,address,uint256)';
const iface = new ethers.Interface([`function ${functionSignature}`]);
// КРИТИЧЕСКИ ВАЖНО: конвертируем amount в wei
const amountInWei = ethers.parseUnits(amount.toString(), 18);
const encodedCall = iface.encodeFunctionData('_transferTokens', [
sender, // адрес инициатора (обязательно! должен быть из signer.getAddress())
recipient, // адрес получателя
amountInWei // количество в wei (обязательно!)
]);
return encodedCall;
}
// ❌ НЕПРАВИЛЬНО: Кодирование один раз до цикла
// const transferCallData = encodeTransferTokensCall(formData.sender, ...); // НЕПРАВИЛЬНО!
// for (const chainId of allChains) {
// await createProposal(contractAddress, { operation: transferCallData, ... }); // sender может не совпасть!
// }
// ❌ НЕПРАВИЛЬНО: Отсутствует sender или amount не в wei
// const transferFunctionSelector = ethers.id("_transferTokens(address,uint256)"); // НЕПРАВИЛЬНО!
// const amount = transferData.amount; // НЕПРАВИЛЬНО! Нужна конвертация в wei
```
**Другие поддерживаемые операции:**
- `_addModule(bytes32,address)` - добавление модуля
- `_removeModule(bytes32)` - удаление модуля
- `_addSupportedChain(uint256)` - добавление поддерживаемой сети
- `_removeSupportedChain(uint256)` - удаление поддерживаемой сети
- `_updateVotingDurations(uint256,uint256)` - обновление времени голосования
- `_updateQuorumPercentage(uint256)` - обновление процента кворума
- `_updateDLEInfo(...)` - обновление информации DLE
- `_setLogoURI(string)` - обновление URI логотипа
#### Результат
- Создано N предложений (по одному в каждой сети DLE)
- Каждое предложение имеет уникальный ID в своей сети
- Все предложения отображаются как одна карточка в интерфейсе
- Карточка показывает статус предложения в каждой сети
---
### Этап 2: Голосование
#### Описание процесса
1. Пользователь видит карточку предложения с информацией о всех сетях DLE
2. Пользователь выбирает голос "За" или "Против"
3. **Последовательное голосование во всех активных сетях:**
- Система определяет все активные цепочки (state === 0 или 'active', не выполнены, не отменены)
- Для каждой активной сети:
- Переключение MetaMask на соответствующую сеть
- Задержка 1 секунда после переключения
- **Проверка баланса токенов в этой сети** (балансы могут отличаться в разных сетях)
- Если баланс отсутствует, сеть пропускается с предупреждением
- Голосование продолжается в других сетях
- Голосование с использованием **уникального ID предложения для этой сети**
- Задержка 3 секунды после подтверждения транзакции (5 секунд для Base Sepolia)
4. **Подписи в MetaMask:**
- Пользователь должен подписать транзакцию голосования в каждой активной сети DLE
- Количество подписей = количество активных сетей DLE
- Каждая подпись регистрирует голос в соответствующей сети
#### Технические детали
- **Функция контракта:** `vote(proposalId, support)` - где `proposalId` уникален для каждой сети
- **Проверка ID:** Система использует `chain.id` (ID предложения из конкретной сети), а не общий ID группы
- **Проверка баланса:** Баланс токенов проверяется **в каждой сети отдельно** перед голосованием
- В мультичейн-системе балансы могут отличаться в разных сетях
- Если в сети нет токенов, голосование в этой сети пропускается
- Контракт также проверяет баланс через `getPastVotes()` и вернет ошибку, если токенов нет
- **Вес голоса:** Зависит от баланса токенов голосующего в соответствующей сети
- **Независимые кворумы:** Каждая сеть имеет свой собственный кворум
#### Результат
- Голос зарегистрирован во всех активных сетях DLE
- Каждая сеть обновляет свои счетчики голосов (forVotes, againstVotes)
- Карточка предложения обновляется с новыми данными голосования
---
### Этап 3: Выполнение предложения
#### Условия выполнения
**КРИТИЧЕСКИ ВАЖНО:** Предложение может быть выполнено только при условии, что кворум достигнут **во всех сетях DLE**, где предложение активно.
Условия для каждой сети:
- Состояние предложения: `ReadyForExecution` (state === 5)
- Кворум достигнут: `forVotes >= quorumRequired`
- Большинство голосов "За": `forVotes > againstVotes`
- Предложение не выполнено: `executed === false`
- Предложение не отменено: `canceled === false`
- Истек период голосования (если применимо)
- Истек период timelock (если применимо)
#### Описание процесса
1. Система проверяет, что предложение готово к выполнению во всех активных сетях DLE
2. **Последовательное выполнение во всех готовых сетях:**
- Для каждой сети, где предложение готово к выполнению:
- Переключение MetaMask на соответствующую сеть
- Задержка 1 секунда после переключения
- Выполнение предложения с использованием **уникального ID предложения для этой сети**
- Задержка 3 секунды после подтверждения транзакции (5 секунд для Base Sepolia)
3. **Подписи в MetaMask:**
- Пользователь должен подписать транзакцию выполнения в каждой готовой сети DLE
- Количество подписей = количество готовых сетей DLE
- Каждая подпись выполняет перевод токенов в соответствующей сети
#### Технические детали
- **Функция контракта:** `executeProposal(proposalId)` - где `proposalId` уникален для каждой сети
- **Операция перевода:** `_transferTokens(sender, recipient, amount)`
- `sender` = адрес инициатора предложения (проверяется в контракте)
- `recipient` = адрес получателя из предложения
- `amount` = количество токенов из предложения
- **Проверка безопасности:** Контракт проверяет, что `sender` совпадает с `initiator` предложения
- **Перевод токенов:** Токены переводятся с кошелька инициатора, а не с баланса контракта
#### Результат
- Перевод токенов выполнен во всех готовых сетях DLE
- Каждая сеть независимо выполняет перевод с кошелька инициатора
- Карточка предложения обновляется, показывая статус "Выполнено" во всех сетях
---
## Отмена предложения
### Условия отмены
- Только инициатор предложения может отменить его
- Предложение должно быть активным (не выполнено, не отменено)
- Отмена возможна в любой момент до выполнения
### Процесс отмены
1. **Последовательная отмена во всех активных сетях:**
- Для каждой активной сети:
- Переключение MetaMask на соответствующую сеть
- Задержка 1 секунда после переключения
- Отмена предложения с использованием **уникального ID предложения для этой сети**
- Задержка 3 секунды после подтверждения транзакции
2. **Подписи в MetaMask:**
- Пользователь должен подписать транзакцию отмены в каждой активной сети DLE
- Количество подписей = количество активных сетей DLE
### Технические детали
- **Функция контракта:** `cancelProposal(proposalId, reason)`
- **Проверка прав:** Контракт проверяет, что вызывающий является инициатором предложения
---
## Важные особенности системы
### 1. Уникальность ID предложений
- **Каждая сеть имеет свой собственный счетчик предложений**
- Предложение с ID=1 в Sepolia и предложение с ID=1 в Arbitrum Sepolia - это **разные предложения**
- При группировке система сохраняет ID из каждой сети отдельно
- При голосовании/выполнении/отмене используется правильный ID для каждой сети
### 2. Группировка предложений
- Предложения группируются по ключу: `${description}_${initiator}`
- Одна карточка = одно логическое предложение во всех сетях
- Карточка отображает:
- Общее описание
- Инициатора
- Список сетей с их статусами
- Результаты голосования по каждой сети
- Общий статус (активно/выполнено/отменено)
### 3. Независимые кворумы
- **Каждая сеть имеет свой собственный кворум**
- Кворум рассчитывается на основе общего предложения токенов в соответствующей сети
- Голосование в одной сети не влияет на кворум в другой сети
- Для выполнения предложения кворум должен быть достигнут **во всех сетях**
### 4. Последовательное выполнение операций
- Все операции (создание, голосование, выполнение, отмена) выполняются **последовательно**, а не параллельно
- Это необходимо, так как MetaMask может работать только с одной сетью одновременно
- Между операциями есть задержки для стабилизации MetaMask
- **КРИТИЧЕСКИ ВАЖНО:** Использование `Promise.all` для параллельного выполнения недопустимо и приведет к ошибкам
### 5. Обработка ошибок
- **Retry для временных ошибок RPC:**
- Автоматический retry до 3 попыток
- Экспоненциальная задержка (2s, 4s, 8s)
- Только для retryable ошибок (Internal JSON-RPC error, rate limiting)
- **Ошибки в отдельных сетях:**
- Если операция не удалась в одной сети, процесс продолжается для других сетей
- Пользователь получает сводку успешных и неудачных операций
- **Обработка отсутствия баланса:**
- Перед голосованием в каждой сети проверяется баланс токенов
- Если в сети нет токенов, голосование в этой сети пропускается с предупреждением
- Голосование продолжается в других сетях, где баланс есть
- Контракт также проверяет баланс и вернет ошибку `ErrNoPower`, если токенов нет
### 6. Безопасность
- **Проверка инициатора:** При выполнении контракт проверяет, что `sender` совпадает с `initiator`
- **Проверка баланса:** Перед голосованием проверяется наличие токенов **в каждой сети отдельно**
- Балансы могут отличаться в разных сетях
- Если в сети нет токенов, голосование в этой сети пропускается
- Контракт также проверяет баланс через `getPastVotes()` и вернет ошибку `ErrNoPower`, если токенов нет
- **Проверка состояния:** Перед каждой операцией проверяется актуальное состояние предложения
- **Валидация данных:** Все данные предложения валидируются перед отправкой в контракт
### 7. Перевод токенов
- **Источник токенов:** Токены переводятся с кошелька инициатора предложения, а не с баланса контракта
- **Получатель:** Может быть любой адрес (кошелек или казна)
- **Количество:** Указывается инициатором при создании предложения
- **Проверка баланса:** Контракт проверяет достаточность баланса инициатора перед выполнением
---
## Пользовательский интерфейс
### Карточка предложения
- **Заголовок:** Описание предложения
- **Инициатор:** Адрес создателя предложения
- **Список сетей:**
- Название сети
- Статус (Активно/Выполнено/Отменено/Истекло)
- ID предложения в этой сети
- Результаты голосования (За/Против)
- Кворум (достигнут/не достигнут)
- **Действия:**
- Голосовать "За" / "Против" (если активно)
- Выполнить (если готово к выполнению)
- Отменить (если инициатор)
### Индикаторы статуса
- **Активно:** Предложение открыто для голосования
- **Готово к выполнению:** Кворум достигнут во всех сетях
- **Выполнено:** Перевод токенов выполнен во всех сетях
- **Отменено:** Предложение отменено инициатором
- **Истекло:** Истек период голосования
---
## Технические детали реализации
### Кодирование операций
Подробное описание процесса кодирования операций для создания предложений см. в разделе [Кодирование операции](#кодирование-операции) (Этап 1: Создание предложения).
### Структура данных предложения
```javascript
{
id: number, // ID группы (из первой сети)
description: string, // Описание предложения
initiator: address, // Адрес инициатора
deadline: number, // Дедлайн голосования
chains: [ // Массив данных по каждой сети
{
id: number, // УНИКАЛЬНЫЙ ID для этой сети
chainId: number, // ID сети (11155111, 421614, 84532)
networkName: string, // Название сети
contractAddress: address, // Адрес контракта DLE в этой сети
state: number, // Состояние (0=Active, 3=Executed, 4=Canceled, 5=ReadyForExecution)
forVotes: bigint, // Голоса "За"
againstVotes: bigint, // Голоса "Против"
quorumRequired: bigint, // Требуемый кворум
executed: boolean, // Выполнено
canceled: boolean, // Отменено
transactionHash: string // Хеш транзакции создания
}
],
createdAt: number, // Время создания
uniqueId: string // Уникальный ключ группировки
}
```
### Функции контракта DLE
#### createProposal
```solidity
function createProposal(
string memory _description,
uint256 _duration,
bytes memory _operation,
uint256[] memory _targetChains,
uint256 _timelockDelay
) public returns (uint256 proposalId)
```
#### vote
```solidity
function vote(uint256 _proposalId, bool _support) public
```
#### executeProposal
```solidity
function executeProposal(uint256 _proposalId) public
```
#### cancelProposal
```solidity
function cancelProposal(uint256 _proposalId, string memory _reason) public
```
#### _transferTokens (internal)
```solidity
function _transferTokens(
address _sender,
address _recipient,
uint256 _amount
) internal
```
---
## Примеры использования
### Пример 0: Кодирование операции перевода токенов
Перед созданием предложения необходимо закодировать операцию. **КРИТИЧЕСКИ ВАЖНО:** Используйте правильную сигнатуру и конвертируйте amount в wei.
```javascript
import { ethers } from 'ethers';
// Получаем адрес инициатора из signer
const signer = await provider.getSigner();
const sender = await signer.getAddress(); // Адрес инициатора (обязательно!)
// Параметры перевода
const recipient = '0x1234567890123456789012345678901234567890'; // Получатель
const amount = 100; // 100 токенов (в обычных единицах, не в wei)
// Кодирование операции
const functionSignature = '_transferTokens(address,address,uint256)';
const iface = new ethers.Interface([`function ${functionSignature}`]);
// КРИТИЧЕСКИ ВАЖНО: конвертируем amount в wei
const amountInWei = ethers.parseUnits(amount.toString(), 18); // 100 * 10^18 wei
const encodedOperation = iface.encodeFunctionData('_transferTokens', [
sender, // адрес инициатора (обязательно!)
recipient, // адрес получателя
amountInWei // количество в wei (обязательно!)
]);
// encodedOperation теперь можно использовать в createProposal
// Результат: 0x... (селектор функции + закодированные параметры)
// Создание предложения с правильным порядком параметров
const tx = await dle.createProposal(
"Перевод 100 токенов в казну", // description
86400, // duration (1 день в секундах)
encodedOperation, // operation
[chainId], // targetChains (массив!)
0 // timelockDelay
);
```
**Результат:** Закодированная операция в формате bytes, готовая для передачи в `createProposal`.
**Частые ошибки:**
- ❌ Использование `_transferTokens(address,uint256)` - неправильная сигнатура
- ❌ Отсутствие параметра `sender` - контракт не сможет проверить инициатора
- ❌ Передача `amount` без конвертации в wei - неправильное количество токенов
- ❌ Неправильный порядок параметров в `createProposal` - ошибка вызова контракта
### Пример 1: Создание предложения в 3 сетях
1. Пользователь создает предложение "Перевод 100 токенов в казну"
2. Система определяет 3 сети: Sepolia, Arbitrum Sepolia, Base Sepolia
3. Создаются 3 предложения:
- Sepolia: ID=5
- Arbitrum Sepolia: ID=3
- Base Sepolia: ID=7
4. Все 3 предложения отображаются как одна карточка
### Пример 2: Голосование
1. Пользователь голосует "За" за предложение
2. Система голосует в 3 сетях:
- Sepolia: vote(5, true)
- Arbitrum Sepolia: vote(3, true)
- Base Sepolia: vote(7, true)
3. Каждое голосование требует отдельной подписи в MetaMask
### Пример 3: Выполнение
1. Кворум достигнут во всех 3 сетях
2. Система выполняет предложение в 3 сетях:
- Sepolia: executeProposal(5)
- Arbitrum Sepolia: executeProposal(3)
- Base Sepolia: executeProposal(7)
3. В каждой сети токены переводятся с кошелька инициатора на адрес получателя
---
## Ограничения и особенности
### Ограничения
- MetaMask может работать только с одной сетью одновременно
- Операции выполняются последовательно, что может занять время при большом количестве сетей
- Ошибки RPC могут потребовать ручного retry
### Особенности
- Если предложение не создано в одной из сетей (из-за ошибки), оно все равно может быть создано в других сетях
- Голосование возможно только в тех сетях, где предложение активно
- Выполнение возможно только если кворум достигнут во всех активных сетях
---
## Безопасность
### Защита от атак
- Проверка инициатора при выполнении
- Проверка баланса перед переводом
- Независимые кворумы в каждой сети
- Валидация всех входных данных
### Рекомендации
- Всегда проверяйте адрес получателя перед созданием предложения
- Убедитесь, что у вас достаточно токенов для перевода
- Проверяйте статус предложения перед голосованием/выполнением
- Следите за транзакциями в каждой сети
---
## Известные проблемы и исправления
### Исправленные критические ошибки
#### 1. Отсутствие конвертации amount в wei
**Проблема:** Параметр `amount` передавался без конвертации в wei, что приводило к неправильному количеству токенов при выполнении.
**Исправление:** Добавлена обязательная конвертация через `ethers.parseUnits(amount.toString(), 18)` перед кодированием операции.
**Файл:** `frontend/src/views/smartcontracts/TransferTokensFormView.vue`
**Статус:** ✅ Исправлено
#### 2. Неправильная сигнатура функции _transferTokens
**Проблема:** Использовалась неправильная сигнатура `_transferTokens(address,uint256)` вместо `_transferTokens(address,address,uint256)`, что приводило к ошибкам декодирования в контракте.
**Исправление:** Исправлена сигнатура функции и добавлен обязательный параметр `sender` (адрес инициатора).
**Файл:** `frontend/src/utils/dle-contract.js` (функция `createTransferTokensProposal`)
**Статус:** ✅ Исправлено
#### 3. Неправильный порядок параметров в createProposal
**Проблема:** В функцию `createProposal` передавался `governanceChainId` вместо `targetChains` в 4-м параметре, что нарушало сигнатуру контракта.
**Исправление:** Исправлен порядок параметров согласно сигнатуре контракта: `description`, `duration`, `operation`, `targetChains`, `timelockDelay`.
**Файл:** `frontend/src/utils/dle-contract.js` (функция `createTransferTokensProposal`)
**Статус:** ✅ Исправлено
#### 4. Неправильное кодирование операции при создании предложений (КРИТИЧЕСКАЯ)
**Проблема:** Операция перевода токенов кодировалась один раз до цикла по сетям, используя адрес из `formData.value.sender`. По документации, `sender` должен определяться из `signer.getAddress()` при создании предложения в каждой сети, что гарантирует совпадение с инициатором предложения.
**Исправление:**
- Кодирование операции перемещено внутрь цикла по сетям
- Добавлено получение адреса signer для каждой сети через `await signer.getAddress()`
- Добавлена проверка соответствия адреса signer адресу из формы
- Операция теперь кодируется с актуальным адресом signer для каждой сети отдельно
**Файл:** `frontend/src/views/smartcontracts/TransferTokensFormView.vue` (функция `submitForm`)
**Статус:** ✅ Исправлено (2025-01-XX)
#### 5. Параллельное выполнение в executeMultichainProposal (КРИТИЧЕСКАЯ)
**Проблема:** Функция `executeMultichainProposal` использовала `Promise.all` для параллельного выполнения операций во всех сетях одновременно. Это не работает с MetaMask, который может работать только с одной сетью одновременно.
**Исправление:**
- Заменен `Promise.all` на последовательный цикл `for`
- Добавлено переключение сетей через `switchToVotingNetwork` для каждой сети
- Добавлены задержки после переключения сетей (1 секунда) и после подтверждения транзакций (3 секунды, 5 секунд для Base Sepolia)
- Добавлена фильтрация только готовых к выполнению цепочек
**Файл:** `frontend/src/composables/useProposals.js` (функция `executeMultichainProposal`)
**Статус:** ✅ Исправлено (2025-01-XX)
#### 6. Отсутствие переключения сетей в voteOnMultichainProposal
**Проблема:** Функция `voteOnMultichainProposal` не использовала переключение сетей и проверку баланса токенов, что требовалось по документации для корректной работы в мультичейн-среде.
**Исправление:**
- Добавлено переключение сетей через `switchToVotingNetwork` для каждой сети
- Добавлена проверка баланса токенов перед голосованием в каждой сети через `checkTokenBalance`
- Добавлены задержки после переключения сетей (1 секунда) и после подтверждения транзакций (3 секунды, 5 секунд для Base Sepolia)
- Добавлена фильтрация только активных цепочек
- Добавлена обработка ошибок с пропуском сетей при отсутствии баланса
**Файл:** `frontend/src/composables/useProposals.js` (функция `voteOnMultichainProposal`)
**Статус:** ✅ Исправлено (2025-01-XX)
### Текущая корректная реализация
Все функции кодирования операций и мультичейн-операции теперь используют:
- ✅ Правильную сигнатуру: `_transferTokens(address,address,uint256)`
-Все три параметра: `sender`, `recipient`, `amount`
- ✅ Конвертацию amount в wei: `ethers.parseUnits(amount.toString(), 18)`
- ✅ Правильный порядок параметров в `createProposal`
- ✅ Определение `sender` из `signer.getAddress()` при создании предложения в каждой сети
- ✅ Последовательное выполнение операций во всех мультичейн-функциях (не параллельное)
- ✅ Переключение сетей перед каждой операцией в мультичейн-функциях
- ✅ Проверку баланса токенов перед голосованием в каждой сети
### Проверка корректности
Перед развертыванием убедитесь, что:
1. Функция `_transferTokens` кодируется с **тремя** параметрами (sender, recipient, amount)
2. `amount` всегда конвертируется в wei перед кодированием
3. `sender` получается из `signer.getAddress()` при создании предложения в каждой сети и совпадает с инициатором предложения
4. Порядок параметров в `createProposal` соответствует сигнатуре контракта
5. Все мультичейн-операции (создание, голосование, выполнение) используют последовательное выполнение с переключением сетей
6. При голосовании проверяется баланс токенов в каждой сети отдельно
---
## Заключение
Система мультичейн-управления DLE обеспечивает децентрализованное управление переводом токенов через независимые кворумы в каждой сети, при этом предоставляя единый интерфейс для управления предложениями во всех сетях одновременно.
**Важно:** Все критические ошибки в кодировании операций исправлены. Код соответствует документации и контракту.

View File

@@ -0,0 +1,219 @@
[English](../../docs.en/back-docs/TASK_REQUIREMENTS.md) | **Русский**
# Задание: Реализация мульти-чейн governance системы для DLE
## Статус выполнения
- ✅ Форма создания предложения работает
- ✅ Предложение создается во всех цепочках DLE
- ✅ Голосование происходит отдельно в каждой цепочке
- ✅ Кворум считается отдельно для каждой цепочки
- ✅ Личный перевод токенов от инициатора предложения
- ✅ Группировка предложений по description + initiator
- ✅ Серверная координация с криптографическими доказательствами
- ✅ Убрана хардкод цепочек - используются deployedNetworks из API
## Контекст
DLE (Digital Legal Entity) - децентрализованная юридическая сущность с контрактами в нескольких блокчейн-сетях. Необходимо реализовать систему управления токенами через мульти-чейн governance, где холдеры токенов могут переводить токены через голосование с кворумом.
## Архитектура системы
### Мульти-чейн компоненты
- **Frontend**: Vue.js приложение с Web3 интеграцией
- **Backend**: Node.js сервер для координации и API
- **Smart Contracts**: DLE контракты в каждой поддерживаемой сети
- **Database**: PostgreSQL для хранения метаданных
- **WebSocket**: Real-time синхронизация между сетями
### Поддерживаемые сети
- Ethereum Sepolia (chainId: 11155111)
- Arbitrum Sepolia (chainId: 421614)
- Base Sepolia (chainId: 84532)
## Требования к функционалу
### 1. Форма создания предложения о переводе токенов
**URL:** `/management/transfer-tokens?address=<DLE_ADDRESS>`
**Поля формы:**
- Адрес получателя (обязательное, address)
- Сумма перевода (обязательное, number в токенах)
- Описание предложения (опциональное, string)
- Время голосования (обязательное, number в днях)
### 2. Логика создания предложений
1. **Определение сетей:** Получение списка `deployedNetworks` через API `/dle-v2`
2. **Параллельное создание:** Предложения создаются одновременно во ВСЕХ сетях DLE
3. **Кодирование операции:** `_transferTokens(address,uint256)` для перевода токенов от инициатора
### 3. Логика голосования
1. **Независимое голосование:** Каждая сеть голосует отдельно
2. **Локальный кворум:** Кворум считается по формуле `(forVotes / totalSupply) >= quorumPercentage`
3. **Голосование токенами:** Вес голоса = баланс токенов избирателя
### 4. Логика исполнения
1. **Локальное исполнение:** Каждый контракт проверяет свой локальный кворум
2. **Серверная координация:** Backend собирает результаты кворумов из всех сетей
3. **Криптографические доказательства:** Сервер подписывает глобальный статус кворума
4. **Глобальное исполнение:** Контракт проверяет подпись и выполняет операцию
## Техническая спецификация
### Smart Contract (DLE.sol)
#### Структура Proposal
```solidity
struct Proposal {
uint256 id;
string description;
uint256 forVotes;
uint256 againstVotes;
bool executed;
bool canceled;
uint256 deadline;
address initiator; // Создатель предложения
bytes operation; // Закодированная операция
uint256[] targetChains; // Целевые сети для исполнения
uint256 snapshotTimepoint; // Точка снимка для голосования
mapping(address => bool) hasVoted;
}
```
#### Функция _transferTokens
```solidity
function _transferTokens(address _sender, address _recipient, uint256 _amount) internal {
require(balanceOf(_sender) >= _amount, "Insufficient balance");
_transfer(_sender, _recipient, _amount);
emit TokensTransferredByGovernance(_recipient, _amount);
}
```
#### События
```solidity
event ProposalCreated(uint256 proposalId, address initiator, string description);
event QuorumReached(uint256 proposalId, uint256 chainId);
event ProposalExecuted(uint256 proposalId, bytes operation);
```
### Backend (Node.js)
#### Сервис координации кворумов
```javascript
class QuorumCoordinator {
// Сбор результатов голосования из всех сетей
async collectQuorumResults(proposalId) {
// Слушать события QuorumReached из всех сетей
// Сохранять в базу данных
}
// Генерация криптографических доказательств
async generateGlobalQuorumProof(proposalId) {
// Подписать глобальный статус кворума
// Вернуть подпись для контрактов
}
}
```
#### API Endpoints
- `GET /dle-v2` - получение информации о DLE и сетях
- `POST /api/dle-proposals/get-proposals` - получение списка предложений
- `POST /api/dle-proposals/create-proposal` - создание предложения
- `POST /api/dle-proposals/vote-proposal` - голосование
- `POST /api/dle-proposals/execute-proposal` - исполнение
### Frontend (Vue.js)
#### Компонент TransferTokensFormView
- Валидация формы
- Кодирование операции перевода
- Параллельное создание предложений во всех сетях
- Обработка ошибок и отображение результатов
#### Компонент DleProposalsView
- Группировка предложений по `description + initiator`
- Отображение статуса по каждой сети
- Кнопки голосования для каждой активной сети
- Кнопка исполнения при глобальном кворуме
## Алгоритм работы
### Сценарий использования
1. **Пользователь открывает форму** `/management/transfer-tokens?address=0xdD27...9386`
2. **Вводит данные:**
- Получатель: `0x123...abc`
- Сумма: `1000` токенов
- Описание: `"Перевод средств подрядчику"`
- Время: `7` дней
3. **Нажимает "Создать"**
4. **Система:**
- Определяет сети: Sepolia, Arbitrum Sepolia, Base Sepolia
- Создает предложения в каждой сети параллельно
- Кодирует `_transferTokens(инициатор, получатель, сумма)`
5. **На странице предложений** появляется одна карточка с статусом по сетям
6. **Пользователи голосуют** в каждой сети отдельно
7. **При локальном кворуме** контракт эмитирует `QuorumReached`
8. **Backend собирает** результаты из всех сетей
9. **При глобальном кворуме** сервер подписывает доказательство
10. **Пользователь вызывает** `executeWithGlobalQuorum()` с подписью
11. **Контракт проверяет** подпись и выполняет перевод
## Безопасность
### Уровни защиты
1. **On-chain проверки:** Баланс токенов, сроки голосования, кворум
2. **Криптографические доказательства:** Подпись сервера для глобального кворума
3. **Многоуровневая валидация:** Локальный + глобальный кворум
4. **Отказоустойчивость:** Graceful degradation при недоступности сетей
### Риски и mitigation
- **Сервер скомпрометирован:** Проверка подписи предотвращает подделку
- **Сеть недоступна:** Локальное голосование работает независимо
- **Replay attacks:** Проверка ID предложения и chainId
- **Front-running:** Использование commit-reveal схемы при необходимости
## Тестирование
### Критерии приемки
- [x] Форма создания предложения работает
- [x] Предложение создается во всех цепочках DLE
- [x] Голосование происходит отдельно в каждой цепочке
- [x] Кворум считается отдельно для каждой цепочки
- [x] Перевод токенов происходит от инициатора предложения
- [x] Серверная координация с криптографическими доказательствами
- [x] Группировка предложений в интерфейсе
- [x] Обработка ошибок и edge cases
### Test cases
1. Создание предложения в мульти-чейн среде
2. Голосование в одной сети при недоступности других
3. Исполнение при глобальном кворуме
4. Исполнение при частичном кворуме (должен fail)
5. Перевод токенов от инициатора с достаточным балансом
6. Попытка перевода с недостаточным балансом (должен fail)
## Развертывание
### Требования к инфраструктуре
- **Backend сервер** с доступом к RPC всех сетей
- **Database** для хранения метаданных предложений
- **SSL сертификаты** для безопасной коммуникации
- **Monitoring** для отслеживания состояния сетей
### Переменные окружения
```bash
# RPC URLs
SEPOLIA_RPC_URL=https://1rpc.io/sepolia
ARBITRUM_SEPOLIA_RPC_URL=https://sepolia-rollup.arbitrum.io/rpc
BASE_SEPOLIA_RPC_URL=https://sepolia.base.org
# Database
DATABASE_URL=postgresql://user:pass@localhost:5432/dle
# Server keys for signing
SERVER_PRIVATE_KEY=0x...
```
## Заключение
Реализована полнофункциональная мульти-чейн governance система для управления токенами DLE. Система обеспечивает децентрализованное принятие решений с координацией через trusted server с криптографическими доказательствами, обеспечивая баланс между удобством использования и безопасностью.

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,418 @@
[English](../../docs.en/back-docs/multi-agent-architecture.md) | **Русский**
# 🏗️ Архитектура множественных ИИ-агентов в DLE
> **Концепция**: Создание отдельных специализированных агентов для разных задач, использующих одну локальную модель Ollama, но с разными системными промптами, правилами и интерфейсами.
---
## 📋 Содержание
1. [Концепция архитектуры](#концепция-архитектуры)
2. [Типы агентов](#типы-агентов)
3. [Архитектура системы](#архитектура-системы)
4. [Настройка агентов](#настройка-агентов)
5. [Интерфейсы агентов](#интерфейсы-агентов)
6. [База знаний для агентов](#база-знаний-для-агентов)
7. [Процесс работы агентов](#процесс-работы-агентов)
---
## 🎯 Концепция архитектуры
### Основные принципы
1. **Одна модель, множество агентов**
- Все агенты используют одну локальную модель Ollama (qwen2.5:7b)
- Различие между агентами — в системных промптах и правилах
- Каждый агент имеет свою специализацию и роль
2. **Изоляция агентов**
- Каждый агент имеет свои настройки (системный промпт, правила, RAG таблицы)
- Агенты не влияют друг на друга
- Можно создавать, редактировать и удалять агентов независимо
3. **Специализация по задачам**
- Агент поддержки — отвечает на вопросы пользователей
- Агент-редактор — создает контент по запросу
- Возможность создания дополнительных агентов (аналитик, переводчик и т.д.)
4. **Отдельные интерфейсы**
- Каждый агент имеет свой интерфейс доступа
- Интерфейсы адаптированы под задачи агента
- Разные права доступа для разных агентов
---
## 🤖 Типы агентов
### 1. Агент поддержки (Support Agent)
**Роль**: Отвечать на сообщения пользователей
**Задачи**:
- Обработка входящих сообщений от пользователей
- Поиск ответов в базе знаний (FAQ, документация)
- Генерация ответов на основе найденной информации
- Эскалация сложных вопросов к операторам
**Характеристики**:
- Использует RAG для поиска в FAQ и документах
- Системный промпт: "Вы — профессиональный ассистент службы поддержки"
- Правила: строгий режим (только из базы знаний, минимум генерации)
- Интерфейс: встроен в чат (web, telegram, email)
**База знаний**:
- FAQ таблицы
- Документация продукта
- База знаний для клиентов
---
### 2. Агент-редактор (Content Editor Agent)
**Роль**: Создавать контент по запросу пользователя
**Задачи**:
- Создание постов для социальных сетей
- Написание статей для блога
- Генерация email-рассылок
- Создание рекламных текстов
**Характеристики**:
- Использует RAG для поиска инструкций платформ и стиля компании
- Системный промпт: "Вы — профессиональный контент-маркетолог и редактор"
- Правила: креативный режим (больше генерации, использование примеров)
- Интерфейс: отдельная страница "Редактор контента"
**База знаний**:
- Инструкции платформ (ВК, Telegram, Instagram и т.д.)
- Стиль компании (tone of voice, запрещенные слова)
- Примеры контента (референсы)
- Ключевые слова и хэштеги
- CTA блоки
---
### 3. Потенциальные дополнительные агенты
**Агент-аналитик**:
- Анализ данных и создание отчетов
- Выявление трендов
- Прогнозирование
**Агент-переводчик**:
- Перевод контента на разные языки
- Локализация материалов
- Адаптация под культурные особенности
**Агент-закупщик**:
- Поиск поставщиков
- Анализ условий
- Рекомендации по выбору
---
## 🏛️ Архитектура системы
### Компоненты системы
```
┌─────────────────────────────────────────────────────────┐
│ Единая модель Ollama │
│ (qwen2.5:7b) │
└────────────────┬────────────────────────────────────────┘
├─────────────────┬───────────────────────┐
│ │ │
↓ ↓ ↓
┌────────────────────┐ ┌──────────────────┐ ┌──────────────┐
│ Агент поддержки │ │ Агент-редактор │ │ Другие агенты│
│ │ │ │ │ │
│ • Системный промпт │ │ • Системный │ │ • Свои │
│ • Правила (строгие)│ │ промпт │ │ настройки │
│ • RAG: FAQ │ │ • Правила │ │ │
│ • Интерфейс: чат │ │ (креативные) │ │ │
│ │ │ • RAG: инструкции │ │ │
│ │ │ • Интерфейс: │ │ │
│ │ │ редактор │ │ │
└────────────────────┘ └──────────────────┘ └──────────────┘
```
### Хранение настроек агентов
**Таблица `ai_agents`**:
- `id` — уникальный идентификатор агента
- `name` — название агента (например, "Агент поддержки", "Агент-редактор")
- `role` — роль агента (support, content_editor, analyst и т.д.)
- `description` — описание назначения агента
- `system_prompt_encrypted` — системный промпт (зашифрован)
- `rules_id` — ссылка на правила агента (из таблицы `ai_assistant_rules`)
- `selected_rag_tables` — массив ID таблиц для RAG поиска
- `enabled_channels` — на каких каналах активен (web, telegram, email)
- `interface_route` — маршрут для интерфейса агента
- `permissions_required` — требуемые права доступа
- `is_active` — активен ли агент
- `created_at`, `updated_at` — даты создания и обновления
**Связь с правилами**:
- Каждый агент может использовать набор правил из `ai_assistant_rules`
- Правила определяют поведение: temperature, maxTokens, searchRagFirst и т.д.
- Можно создавать правила специально для каждого агента
**Связь с RAG таблицами**:
- Каждый агент может использовать свои RAG таблицы
- Агент поддержки: FAQ, документация
- Агент-редактор: инструкции платформ, стиль компании, примеры
---
## ⚙️ Настройка агентов
### Создание нового агента
**Шаг 1: Базовая информация**
- Название агента
- Роль (support, content_editor и т.д.)
- Описание назначения
**Шаг 2: Системный промпт**
- Определяет роль и поведение агента
- Указывает, как агент должен работать
- Содержит контекст о компании и стиле
**Шаг 3: Правила (Rules)**
- Создание или выбор существующих правил
- Настройка параметров генерации (temperature, maxTokens)
- Настройка поведения RAG (searchRagFirst, generateIfNoRag)
**Шаг 4: База знаний (RAG таблицы)**
- Выбор таблиц для поиска информации
- Агент поддержки: FAQ, документация
- Агент-редактор: инструкции, стиль, примеры
**Шаг 5: Интерфейс**
- Определение маршрута для доступа к агенту
- Настройка прав доступа
- Выбор каналов (web, telegram, email)
**Шаг 6: Активация**
- Включение/выключение агента
- Тестирование работы агента
### Примеры настроек
**Агент поддержки**:
- Системный промпт: "Вы — профессиональный ассистент службы поддержки..."
- Правила: строгий режим (temperature: 0.3, searchRagFirst: true, generateIfNoRag: false)
- RAG таблицы: FAQ, Документация продукта
- Интерфейс: встроен в чат
- Каналы: web, telegram, email
**Агент-редактор**:
- Системный промпт: "Вы — профессиональный контент-маркетолог и редактор..."
- Правила: креативный режим (temperature: 0.7, searchRagFirst: true, generateIfNoRag: true)
- RAG таблицы: Инструкции платформ, Стиль компании, Примеры контента
- Интерфейс: отдельная страница /content-editor
- Каналы: только web (для редакторов)
---
## 🖥️ Интерфейсы агентов
### Агент поддержки — интерфейс чата
**Расположение**: Встроен в основной чат (HomeView)
**Особенности**:
- Автоматическая активация при получении сообщения от пользователя
- Показ статуса генерации ответа
- Возможность отключения AI для конкретного сообщения
- История диалога с контекстом
**Права доступа**:
- Доступен всем пользователям
- Автоматически отвечает на сообщения
---
### Агент-редактор — интерфейс редактора
**Расположение**: Отдельная страница `/content-editor`
**Особенности**:
- Поле для ввода запроса на создание контента
- Выбор типа контента (пост ВК, статья блога, email и т.д.)
- Выбор платформы (ВКонтакте, Telegram, Instagram и т.д.)
- Показ процесса генерации
- Редактирование сгенерированного контента
- Сохранение готового контента
- История созданного контента
**Права доступа**:
- Только для пользователей с ролью Editor
- Требуется авторизация
**Функционал интерфейса**:
1. **Форма запроса**:
- Текстовое поле для описания задачи
- Выбор типа контента (выпадающий список)
- Выбор платформы (чекбоксы или выпадающий список)
- Дополнительные параметры (тон, длина, ключевые слова)
2. **Процесс генерации**:
- Индикатор загрузки
- Показ найденных инструкций
- Показ процесса генерации
3. **Результат**:
- Готовый контент в редактируемом поле
- Кнопка "Сохранить"
- Кнопка "Перегенерировать"
- Кнопка "Экспортировать" (копировать, скачать)
4. **История**:
- Список созданного контента
- Фильтры по типу, платформе, дате
- Возможность редактирования и удаления
---
## 📚 База знаний для агентов
### Структура базы знаний
**Для агента поддержки**:
- Таблица "FAQ" — часто задаваемые вопросы
- Таблица "Документация" — описание функций продукта
- Таблица "База знаний для клиентов" — расширенная информация
**Для агента-редактора**:
- Таблица "Инструкции платформ" — правила размещения контента
- Таблица "Стиль компании" — tone of voice, запрещенные слова
- Таблица "Примеры контента" — референсы для разных типов контента
- Таблица "Ключевые слова" — семантическое ядро, хэштеги
- Таблица "CTA блоки" — призывы к действию
### Как агенты используют базу знаний
1. **RAG поиск**:
- Пользователь задает вопрос/запрос
- Агент выполняет векторный поиск в своих RAG таблицах
- Находит релевантную информацию
2. **Контекст для генерации**:
- Найденная информация передается в LLM как контекст
- LLM генерирует ответ/контент на основе контекста
- Системный промпт направляет, как использовать контекст
3. **Фильтрация по роли**:
- Агент поддержки ищет только в FAQ и документации
- Агент-редактор ищет только в инструкциях и примерах
- Изоляция данных между агентами
---
## 🔄 Процесс работы агентов
### Агент поддержки — процесс ответа
1. **Получение сообщения**:
- Пользователь отправляет сообщение в чат
- Система определяет, что нужно использовать агента поддержки
2. **RAG поиск**:
- Агент ищет ответ в своих RAG таблицах (FAQ, документация)
- Использует векторный поиск для семантического поиска
3. **Генерация ответа**:
- Если найден ответ в базе знаний → использует его
- Если не найден → в строгом режиме предлагает связаться с оператором
- Генерирует ответ с учетом системного промпта и правил
4. **Отправка ответа**:
- Ответ отправляется пользователю в чат
- Сохраняется в истории диалога
---
### Агент-редактор — процесс создания контента
1. **Получение запроса**:
- Редактор открывает интерфейс `/content-editor`
- Вводит запрос: "Создай пост для ВКонтакте о новой функции"
- Выбирает тип контента и платформу
2. **RAG поиск инструкций**:
- Агент ищет инструкции для выбранной платформы
- Ищет стиль компании
- Ищет примеры похожего контента
- Ищет релевантные ключевые слова
3. **Генерация контента**:
- Агент генерирует контент на основе:
- Системного промпта (роль редактора)
- Найденных инструкций платформы
- Стиля компании
- Примеров контента
- Ключевых слов
4. **Результат**:
- Готовый контент показывается в интерфейсе
- Редактор может редактировать контент
- Сохранить или экспортировать
---
## 🎯 Преимущества архитектуры
### 1. Специализация
- Каждый агент решает свою задачу оптимально
- Не нужно жертвовать качеством для универсальности
### 2. Гибкость
- Легко создавать новых агентов для новых задач
- Можно настраивать каждого агента независимо
### 3. Изоляция
- Агенты не мешают друг другу
- Можно тестировать и обновлять агентов независимо
### 4. Масштабируемость
- Легко добавлять новых агентов
- Каждый агент использует одну модель, нет перегрузки
### 5. Контроль
- Четкое разделение ответственности
- Легко отслеживать, какой агент что делает
---
## 📊 Сравнение с единым агентом
| Характеристика | Единый агент | Множественные агенты |
|----------------|--------------|----------------------|
| **Специализация** | Универсальный, но менее точный | Специализированный, более точный |
| **Настройка** | Один набор настроек для всех задач | Отдельные настройки для каждой задачи |
| **База знаний** | Все таблицы для всех задач | Изолированные таблицы для каждой задачи |
| **Интерфейс** | Один интерфейс | Отдельные интерфейсы для каждой задачи |
| **Гибкость** | Сложно адаптировать под разные задачи | Легко создавать новых агентов |
| **Производительность** | Одна модель для всех | Одна модель, но разные промпты |
---
## 🚀 Следующие шаги
1. **Создание таблицы `ai_agents`** в базе данных
2. **Создание сервиса для управления агентами**
3. **Модификация AI Assistant для работы с несколькими агентами**
4. **Создание интерфейса для агента-редактора**
5. **Настройка агента поддержки (уже существует, нужно адаптировать)**
6. **Создание базы знаний для агента-редактора**
7. **Тестирование работы обоих агентов**
---
**© 2024-2025 Тарабанов Александр Викторович. Все права защищены.**
**Последнее обновление**: Январь 2026

View File

@@ -0,0 +1,931 @@
[English](../../docs.en/back-docs/setup-ai-assistant.md) | **Русский**
# Инструкция по настройке AI Ассистента с векторным поиском
## 🤖 Полное руководство по запуску интеллектуального помощника
Этот документ описывает пошаговый процесс настройки AI ассистента для решения бизнес-задач через электронные таблицы и векторный поиск.
---
## 📚 Что вы настроите
После выполнения инструкции у вас будет:
✅ Работающий AI ассистент с локальной моделью (Ollama)
✅ База знаний для ответов клиентам (FAQ)
✅ Автоматизация работы с поставщиками
✅ Система обучения персонала
✅ Векторный поиск по вашим данным
✅ Значительная экономия времени и ресурсов
> 💡 **Экономический эффект**: См. [ИИ-агенты DLE](../ai-assistant.md) — архитектура, примеры агентов и расчёты экономии.
---
## ⏱️ Время настройки
- **Быстрая настройка**: 20-30 минут (базовый FAQ)
- **Полная настройка**: 1-2 часа (все возможности)
---
## Шаг 1: Установка и запуск Ollama
### 1.1 Проверка статуса Ollama
1. Перейдите в **Настройки** → вкладка **Интеграции**
2. Найдите блок **"Ollama"** и нажмите **"Подробнее"**
3. Проверьте статус подключения:
-**"Ollama is running"** — все готово, переходите к шагу 1.3
-**"Ollama API not responding"** — переходите к шагу 1.2
### 1.2 Запуск Ollama (если не запущен)
Если Ollama не запущен, выполните в терминале:
```bash
# Для Docker (рекомендуется)
docker-compose up -d ollama
# Или локально
ollama serve
```
Обновите страницу и проверьте статус снова.
### 1.3 Установка модели для AI
1. В разделе **Ollama** нажмите **"Установить модель"**
2. Выберите модель:
- **qwen2.5:7b** (рекомендуется) — для русского языка, 4.7 GB
- **llama2:7b** — для английского, 3.8 GB
- **mistral:7b** — универсальная, 4.1 GB
3. Нажмите **"Установить"**
4. Дождитесь завершения загрузки (5-10 минут в зависимости от скорости интернета)
> 💡 **Подсказка**: Модель скачивается один раз и хранится локально
### 1.4 Установка Embedding модели
1. В том же разделе найдите **"Установить Embedding модель"**
2. Выберите модель:
- **mxbai-embed-large:latest** (рекомендуется) — 670 MB
- **nomic-embed-text:latest** — альтернатива, 274 MB
3. Нажмите **"Установить"**
> ⚠️ **Важно**: Embedding модель нужна для векторного поиска (RAG)
---
## Шаг 2: Создание базы знаний (электронные таблицы)
### 2.1 Создание таблицы FAQ
1. Перейдите в **Таблицы** (в главном меню)
2. Нажмите **"+ Создать таблицу"**
3. Заполните:
- **Название**: `FAQ - Часто задаваемые вопросы`
- **Описание**: `База знаний для AI ассистента по работе с клиентами`
4. Нажмите **"Создать"**
### 2.2 Настройка столбцов таблицы
Добавьте следующие столбцы:
#### Столбец 1: Вопрос (обязательный для RAG)
1. Нажмите **"+ Добавить столбец"**
2. Заполните:
- **Название**: `Вопрос`
- **Тип**: `Текст`
- **Назначение**: Выберите `Вопрос для AI`
3. Нажмите **"Сохранить"**
> ⚠️ **Критично**: Обязательно выберите назначение "Вопрос для AI" — это поле будет индексироваться для векторного поиска
#### Столбец 2: Ответ (обязательный для RAG)
1. Нажмите **"+ Добавить столбец"**
2. Заполните:
- **Название**: `Ответ`
- **Тип**: `Текст`
- **Назначение**: Выберите `Ответ AI`
3. Нажмите **"Сохранить"**
#### Столбец 3: Продукт (опционально, для фильтрации)
1. Нажмите **"+ Добавить столбец"**
2. Заполните:
- **Название**: `Продукт`
- **Тип**: `Множественный выбор`
- **Варианты**: `Базовый`, `Премиум`, `Корпоративный`
- **Назначение**: Выберите `Фильтр по продукту`
3. Нажмите **"Сохранить"**
#### Столбец 4: Теги (опционально, для категоризации)
1. Нажмите **"+ Добавить столбец"**
2. Заполните:
- **Название**: `Теги`
- **Тип**: `Множественный выбор`
- **Варианты**: `Оплата`, `Доставка`, `Возврат`, `Гарантия`, `Техподдержка`
- **Назначение**: Выберите `Теги пользователя`
3. Нажмите **"Сохранить"**
#### Столбец 5: Приоритет (опционально)
1. Нажмите **"+ Добавить столбец"**
2. Заполните:
- **Название**: `Приоритет`
- **Тип**: `Число`
- **Назначение**: Выберите `Приоритет`
3. Нажмите **"Сохранить"**
> 💡 **Подсказка**: Вопросы с более высоким приоритетом будут показываться AI первыми
### 2.3 Заполнение базы знаний
Добавьте типовые вопросы и ответы:
**Пример 1: Оплата**
| Вопрос | Ответ | Продукт | Теги | Приоритет |
|--------|-------|---------|------|-----------|
| Как оплатить заказ? | Мы принимаем оплату банковской картой, через PayPal, или банковским переводом. Выберите удобный способ при оформлении заказа. | Все | Оплата | 10 |
| Можно ли оплатить частями? | Да, для заказов от 50,000₽ доступна рассрочка на 3, 6 или 12 месяцев без переплаты. | Премиум, Корпоративный | Оплата | 8 |
**Пример 2: Доставка**
| Вопрос | Ответ | Продукт | Теги | Приоритет |
|--------|-------|---------|------|-----------|
| Сколько времени занимает доставка? | Стандартная доставка: 3-5 рабочих дней по России. Экспресс-доставка: 1-2 дня в крупных городах. | Все | Доставка | 10 |
| Сколько стоит доставка? | Бесплатная доставка при заказе от 5,000₽. Для заказов менее 5,000₽ стоимость доставки 300₽. | Все | Доставка | 9 |
**Пример 3: Возврат**
| Вопрос | Ответ | Продукт | Теги | Приоритет |
|--------|-------|---------|------|-----------|
| Как вернуть товар? | Возврат возможен в течение 14 дней с момента получения. Товар должен быть в оригинальной упаковке, с сохранением товарного вида. Свяжитесь с поддержкой для оформления возврата. | Все | Возврат | 10 |
| Когда вернут деньги? | Возврат денежных средств производится в течение 5-10 рабочих дней после получения товара на наш склад. | Все | Возврат | 8 |
> 💡 **Рекомендация**: Добавьте минимум 20-30 вопросов для качественной работы AI. Чем больше вопросов, тем точнее ответы!
### 2.4 Активация таблицы как источника для AI
1. В правом верхнем углу таблицы найдите **⚙️ Настройки таблицы**
2. Включите переключатель **"Использовать как источник для AI"** ✅
3. Нажмите **"Сохранить"**
> ✅ **Готово!** Таблица теперь индексируется для векторного поиска
---
## Шаг 3: Настройка AI провайдера (Ollama)
### 3.1 Открытие настроек Ollama
1. Перейдите в **Настройки****Интеграции**
2. Найдите блок **"Ollama"** и нажмите **"Подробнее"**
### 3.2 Проверка Base URL
1. Проверьте поле **Base URL**:
- Для Docker: `http://ollama:11434`
- Для локального: `http://localhost:11434`
2. Если URL неверный, исправьте и нажмите **"Сохранить"**
### 3.3 Выбор модели
1. В поле **"Модель (LLM)"** выберите установленную модель:
- `qwen2.5:7b` (рекомендуется для русского)
2. В поле **"Embeddings-модель"** выберите:
- `mxbai-embed-large:latest`
3. Нажмите **"Сохранить"**
---
## Шаг 4: Настройка AI Ассистента
### 4.1 Открытие настроек ассистента
1. Перейдите в **Настройки****Интеграции**
2. Найдите блок **"ИИ-ассистент"** и нажмите **"Подробнее"**
### 4.2 Настройка системного промта
В поле **"Системный промт"** введите инструкции для AI:
**Базовый промт (для начала)**:
```
Вы — профессиональный ассистент службы поддержки компании.
Правила:
1. Отвечайте вежливо и профессионально
2. Используйте информацию из базы знаний
3. Если информации нет — предложите связаться с оператором
4. Отвечайте кратко и по существу
5. Всегда заканчивайте вопросом "Чем еще могу помочь?"
```
**Продвинутый промт (с персонализацией)**:
```
Вы — профессиональный ассистент службы поддержки компании "Название вашей компании".
О компании:
- Мы занимаемся [краткое описание бизнеса]
- Наши ценности: качество, надежность, клиентоориентированность
Стиль общения:
- Дружелюбный, но профессиональный
- Обращайтесь к клиенту на "Вы"
- Используйте эмодзи умеренно (1-2 на сообщение)
Правила ответа:
1. ОБЯЗАТЕЛЬНО: Отвечайте ТОЛЬКО на русском языке. Все вопросы и ответы должны быть на русском языке
2. Сначала ищите ответ в базе знаний (RAG)
3. Если нашли — отвечайте на основе найденной информации
4. Если не нашли — честно скажите и предложите помощь оператора
5. Не придумывайте информацию о ценах, сроках, условиях
6. При сложных вопросах предлагайте связаться с менеджером
Всегда заканчивайте: "Чем еще могу помочь? 😊"
```
### 4.3 Выбор моделей
1. **LLM-модель**: Выберите `qwen2.5:7b (ollama)`
2. **Embedding-модель**: Выберите `mxbai-embed-large:latest (ollama)`
> 💡 **Подсказка**: Модели автоматически подтянутся из настроек Ollama
> 📊 **Размер контекстного окна**:
> - **Qwen2.5:7b**: Базовый контекст = **32,768 токенов** (~24,000 русских слов)
> - Всего данных, отправляемых в модель:
> - Системный промпт: ~500-2000 символов (~300-1200 токенов)
> - История диалога: до 20 сообщений (~100-500 токенов на сообщение = ~2000-10000 токенов)
> - RAG контекст: ~500-2000 токенов (из найденных данных)
> - Текущий вопрос: ~50-200 токенов
> - **Итого**: примерно 3,000-15,000 токенов (запас достаточен)
> - Если нужен больший контекст → используйте Qwen3 с YaRN (до 131K токенов)
### 4.4 Выбор RAG-таблицы
1. В поле **"Выбранные RAG-таблицы"** выберите созданную таблицу:
- `FAQ - Часто задаваемые вопросы`
2. Нажмите **"Сохранить"**
### 4.5 Настройка правил AI (Rules)
Создайте набор правил для управления поведением AI:
1. Нажмите кнопку **"Создать"** рядом с полем "Набор правил"
2. В модальном окне заполните:
**Название**: `Гибридный режим (RAG + генерация)`
**Описание**: `AI сначала ищет в базе знаний, если не находит — генерирует ответ`
**Правила (JSON)**:
```json
{
"checkUserTags": true,
"searchRagFirst": true,
"generateIfNoRag": true,
"temperature": 0.7,
"maxTokens": 500
}
```
3. Нажмите **"Сохранить"**
4. Выберите созданное правило в выпадающем списке
> 💡 **Что означают параметры**:
> - `checkUserTags: true` — учитывать теги пользователя при поиске
> - `searchRagFirst: true` — сначала искать в базе знаний
> - `generateIfNoRag: true` — генерировать ответ, если ничего не найдено
> - `temperature: 0.7` — баланс между точностью и креативностью (0.0-1.0)
> - `maxTokens: 500` — максимальная длина ответа
### 4.6 Настройки RAG поиска
Разверните раздел **"🔍 Настройки RAG поиска"**:
**Базовые настройки:**
1. **Метод поиска**: Выберите `Гибридный поиск` (рекомендуется)
2. **Максимальное количество результатов**: `5`
3. **Порог релевантности**: `0.1` (от 0.01 до 1.0)
**Извлечение ключевых слов:**
1.**Включить извлечение ключевых слов**
2. **Минимальная длина слова**: `3`
3. **Максимальное количество ключевых слов**: `10`
4.**Удалять стоп-слова**
**Веса поиска (для гибридного):**
1. **Семантический поиск**: `70%` (точность)
2. **Поиск по ключевым словам**: `30%` (скорость)
**Дополнительные настройки:**
1.**Нечеткий поиск** (для опечаток)
2.**Стемминг слов** (находит разные формы слова)
3.**Поиск синонимов** (пока отключен)
### 4.7 Сохранение настроек
Нажмите кнопку **"Сохранить"** внизу формы.
---
## Шаг 5: Тестирование AI Ассистента
### 5.1 Использование встроенного тестера
1. На странице настроек AI ассистента прокрутите вниз до блока **"🔍 Мониторинг системы"**
2. В разделе **"🧠 Тест RAG-функциональности"**:
- Убедитесь, что выбрана таблица `FAQ - Часто задаваемые вопросы`
- Введите тестовый вопрос: `Как оплатить заказ?`
- Нажмите **"Тестировать RAG"**
3. Наблюдайте за процессом:
- 🔍 Ищем ответ в базе знаний... (векторный поиск)
- 🤖 Генерируем ответ с помощью ИИ... (LLM генерация)
- ✅ Готово!
4. Проверьте результат:
- Должен отобразиться ответ из вашей таблицы
- Score (оценка близости): чем ближе к 0, тем лучше
> 💡 **Хороший Score**: от -300 до 0 (ответ найден)
> ⚠️ **Плохой Score**: больше 300 (ответ не найден, AI придумает свой)
### 5.2 Тестирование через Web Chat
1. Перейдите на главную страницу приложения
2. Найдите виджет **"💬 Чат с AI"** (обычно справа внизу)
3. Нажмите на виджет, чтобы открыть чат
4. Введите вопрос: `Сколько стоит доставка?`
5. Проверьте ответ AI
**Ожидаемый результат:**
```
🤖 AI Ассистент:
Бесплатная доставка при заказе от 5,000₽.
Для заказов менее 5,000₽ стоимость доставки 300₽.
Чем еще могу помочь? 😊
```
### 5.3 Тестирование разных сценариев
Попробуйте задать различные вопросы:
**✅ Вопрос из базы знаний:**
```
Пользователь: "Как вернуть товар?"
AI: [Ответ из таблицы FAQ]
```
**⚠️ Вопрос НЕ из базы знаний:**
```
Пользователь: "Какая погода сегодня?"
AI: "Извините, я специализируюсь на вопросах о нашей компании и продуктах.
По вопросам погоды обратитесь к специализированным сервисам.
Чем еще могу помочь?"
```
**🎯 Вопрос с опечаткой:**
```
Пользователь: "Как аплатить заказ?" (опечатка)
AI: [Найдет правильный ответ благодаря нечеткому поиску]
```
---
## Шаг 6: Расширенные возможности (опционально)
### 6.1 Создание таблицы для работы с поставщиками
#### Структура таблицы "База поставщиков"
1. Создайте новую таблицу: `База поставщиков`
2. Добавьте столбцы:
| Столбец | Тип | Описание |
|---------|-----|----------|
| Название компании | Текст | Наименование поставщика |
| Категория товаров | Множественный выбор | Электроника, Мебель, Одежда, и т.д. |
| Контактное лицо | Текст | ФИО менеджера |
| Email | Текст | Электронная почта |
| Телефон | Текст | Контактный телефон |
| Цены | Текст | Прайс-лист (краткое описание) |
| Условия оплаты | Текст | Отсрочка, предоплата, и т.д. |
| Минимальный заказ | Число | Минимальная сумма заказа |
| Срок доставки | Текст | Сроки поставки |
| Рейтинг | Число | Оценка от 1 до 10 |
| Примечания | Текст | Дополнительная информация |
3. Активируйте как источник для AI
4. Заполните данными о ваших поставщиках
#### Промт для AI закупщика
Добавьте в системный промт:
```
ДОПОЛНИТЕЛЬНО - Работа с поставщиками:
Когда пользователь спрашивает о поставщиках:
1. Ищите в базе "База поставщиков"
2. Фильтруйте по категории товаров
3. Сортируйте по рейтингу и условиям
4. Предоставьте ТОП-3 рекомендации
Формат ответа:
🏆 TOP-3 поставщика по запросу "[категория]":
1. [Название] ⭐ [Рейтинг]/10
📧 [Email] | 📞 [Телефон]
💰 Условия: [Условия оплаты]
🚚 Доставка: [Срок доставки]
📦 Минимум: [Минимальный заказ]₽
2. ...
3. ...
Рекомендую связаться с [Название первого поставщика] — лучшие условия.
```
### 6.2 Создание таблицы для обучения персонала
#### Структура таблицы "База знаний для сотрудников"
1. Создайте новую таблицу: `База знаний для сотрудников`
2. Добавьте столбцы:
| Столбец | Тип | Описание |
|---------|-----|----------|
| Вопрос | Текст | Вопрос сотрудника (назначение: Вопрос для AI) |
| Ответ | Текст | Подробный ответ (назначение: Ответ AI) |
| Категория | Множественный выбор | Продажи, HR, Финансы, IT, Маркетинг |
| Отдел | Множественный выбор | Для какого отдела актуально |
| Сложность | Число | От 1 (простой) до 5 (сложный) |
| Инструкции | Текст | Пошаговые инструкции (если есть) |
| Ссылки | Текст | Ссылки на документы/видео |
| Дата обновления | Дата | Когда информация обновлялась |
3. Примеры вопросов:
**Категория "Продажи":**
- "Как оформить возврат клиенту?"
- "Какие скидки можно давать постоянным клиентам?"
- "Как работать с корпоративными клиентами?"
**Категория "HR":**
- "Как оформить отпуск?"
- "Куда обращаться по больничному?"
- "Как происходит адаптация новых сотрудников?"
**Категория "IT":**
- "Как получить доступ к корпоративной почте?"
- "Что делать при проблемах с VPN?"
- "Как создать заявку в техподдержку?"
### 6.3 Создание связей между таблицами
#### Пример: Связь "Клиенты" → "Заказы"
1. Создайте таблицу **"Клиенты"**:
- Название, Email, Телефон, Статус (VIP/Обычный)
2. Создайте таблицу **"Заказы"**:
- Номер заказа, Дата, Сумма
3. В таблице "Заказы" добавьте столбец:
- **Название**: `Клиент`
- **Тип**: `Связь (Relation)`
- **Связанная таблица**: выберите `Клиенты`
- **Показывать поле**: выберите `Название`
4. Добавьте еще один столбец в "Заказы":
- **Название**: `Email клиента`
- **Тип**: `Lookup (Подстановка)`
- **Связь через**: выберите столбец `Клиент`
- **Подставлять поле**: выберите `Email`
**Результат**: При выборе клиента автоматически подставится его Email!
#### Использование AI с связанными таблицами
AI автоматически понимает связи и может отвечать на вопросы:
```
Пользователь: "Покажи все заказы клиента Иванов"
AI: [Ищет в таблице Заказы, фильтрует по клиенту Иванов]
```
---
## Шаг 7: Интеграция с Telegram и Email (опционально)
### 7.1 Настройка Telegram бота
1. Перейдите в **Настройки****Интеграции****Telegram**
2. Создайте бота через [@BotFather](https://t.me/botfather) в Telegram:
- Отправьте `/newbot`
- Выберите имя и username бота
- Скопируйте **Bot Token**
3. В настройках DLE введите:
- **Bot Token**: вставьте токен от BotFather
- **Bot Username**: username вашего бота (например, `@mycompany_bot`)
4. Нажмите **"Сохранить"**
5. В настройках AI ассистента выберите этот Telegram бот в поле **"Telegram-бот"**
**Результат**: AI будет отвечать на сообщения в Telegram!
### 7.2 Настройка Email интеграции
1. Перейдите в **Настройки****Интеграции****Email**
2. Заполните IMAP настройки (для получения писем):
- **IMAP Host**: `imap.gmail.com` (для Gmail)
- **IMAP Port**: `993`
- **IMAP User**: ваш email
- **IMAP Password**: пароль приложения (не основной пароль!)
3. Заполните SMTP настройки (для отправки писем):
- **SMTP Host**: `smtp.gmail.com`
- **SMTP Port**: `587`
- **SMTP User**: ваш email
- **SMTP Password**: пароль приложения
- **From Email**: email для отправки
4. Нажмите **"Тест IMAP"** и **"Тест SMTP"** для проверки
5. Нажмите **"Сохранить"**
6. В настройках AI ассистента выберите этот Email в поле **"Email для связи"**
> ⚠️ **Важно для Gmail**: Создайте "Пароль приложения" в настройках безопасности Google
**Результат**: AI будет отвечать на входящие email автоматически!
---
## Шаг 8: Мониторинг и оптимизация
### 8.1 Проверка статуса сервисов
1. Перейдите в **Настройки****Интеграции****ИИ-ассистент**
2. Прокрутите вниз до **"🔍 Мониторинг системы"**
3. Нажмите **"🔄 Обновить статус"**
4. Проверьте статусы:
- 🟢 **Backend**: должен быть "Работает"
- 🟢 **Postgres**: должен быть "Работает"
- 🟢 **Ollama**: должен показывать количество моделей
- 🟢 **Vector Search**: должен быть "Работает"
> ⚠️ Если что-то красное (🔴) — см. раздел "Решение проблем" ниже
### 8.2 Анализ качества ответов
Регулярно проверяйте качество ответов AI:
1. **Score в тестере RAG**:
- **-300 до 0** ✅ — отличное совпадение
- **0 до 300** ⚠️ — среднее совпадение
- **>300** ❌ — совпадение не найдено
2. **Если Score плохой**:
- Добавьте больше похожих вопросов в таблицу
- Используйте разные формулировки одного вопроса
- Увеличьте порог релевантности (например, до 0.2)
### 8.3 Оптимизация настроек RAG
Экспериментируйте с настройками для улучшения результатов:
**Для более точных ответов:**
```
Метод поиска: Семантический
Порог релевантности: 0.05 (ниже = строже)
Веса: Семантический 100% / Ключевые слова 0%
```
**Для более быстрых ответов:**
```
Метод поиска: Поиск по ключевым словам
Максимальное количество результатов: 3
```
**Для баланса (рекомендуется):**
```
Метод поиска: Гибридный
Веса: Семантический 70% / Ключевые слова 30%
Порог релевантности: 0.1
```
---
## ✅ AI Ассистент готов к работе!
### Что у вас теперь есть
**Локальный AI ассистент** без зависимости от облака
**База знаний FAQ** для ответов клиентам
**Векторный поиск** для точных ответов
**Настроенные правила** поведения AI
**Система мониторинга** для контроля качества
### Экономический эффект
При правильной настройке AI ассистента вы получите:
**Автоматизацию рутинных задач** - высвобождение времени для стратегии
**Повышение качества обслуживания** - AI работает 24/7 без усталости
**Снижение операционных расходов** - меньше персонала на рутинных задачах
**Ускорение принятия решений** - мгновенный доступ к информации
> 💡 **Подробная информация**: См. [ИИ-агенты DLE](../ai-assistant.md#экономический-эффект) — архитектура, примеры агентов и расчёты экономии.
---
## 📚 Следующие шаги
### Расширьте возможности AI
1. **Добавьте больше таблиц**:
- База знаний для партнеров
- Инструкции для персонала
- Каталог продуктов
- База контактов
2. **Создайте правила для разных сценариев**:
- Строгий режим (только RAG) — для финансов
- Креативный режим (больше генерации) — для маркетинга
- Гибридный режим (баланс) — для поддержки
3. **Интегрируйте с другими системами**:
- CRM (синхронизация клиентов)
- Складская система (остатки товаров)
- Бухгалтерия (счета и оплаты)
### Обучите команду
1. Покажите сотрудникам, как работает AI
2. Объясните, как добавлять новые вопросы в базу
3. Установите процесс регулярного обновления базы знаний
4. Назначьте ответственного за качество ответов AI
---
## 🆘 Решение проблем
### Проблема: Ollama не запускается
**Симптомы**: Статус "Ollama API not responding"
**Решение**:
```bash
# Проверить контейнер
docker ps | grep ollama
# Перезапустить
docker-compose restart ollama
# Проверить логи
docker-compose logs ollama
```
### Проблема: AI отвечает неточно
**Симптомы**: Ответы не соответствуют базе знаний
**Решение**:
1. Проверьте Score в тестере (должен быть < 300)
2. Добавьте больше вариантов вопросов в таблицу
3. Уменьшите порог релевантности (например, до 0.05)
4. Проверьте, что столбцы имеют правильные назначения ("Вопрос для AI", "Ответ AI")
### Проблема: Vector Search не работает
**Симптомы**: Статус Vector Search показывает ошибку
**Решение**:
1. Проверьте, установлена ли Embedding модель
2. Пересоберите индекс: на странице таблицы нажмите **"🔄 Пересобрать индекс"**
3. Проверьте, что таблица активирована как источник для AI
### Проблема: AI отвечает на неправильном языке
**Симптомы**: Ответы на английском вместо русского
**Решение**:
1. Измените системный промт, добавив в начало: `ВСЕГДА отвечай на русском языке.`
2. Используйте модель `qwen2.5:7b` вместо `llama2:7b`
3. В правилах AI установите `"language": "ru"`
### Проблема: Медленные ответы
**Симптомы**: AI отвечает дольше 5-10 секунд
**Решение**:
1. Используйте меньшую модель (`mistral:7b` вместо `qwen2.5:14b`)
2. Уменьшите `maxResults` в настройках RAG (например, до 3)
3. Отключите "Поиск синонимов" в дополнительных настройках
4. Используйте SSD для хранения моделей
---
## 📖 Дополнительная документация
### Изучите возможности AI
- 🤖 **[ИИ-агенты DLE](../ai-assistant.md)** архитектура, примеры агентов и экономический эффект
- 📊 **[Система электронных таблиц](./tables-system.md)** - техническое описание таблиц
- **[Конфигурация AI](./setup-ai-assistant.md#техническая-документация-для-разработчиков)** - технические детали настройки
### Общая документация
- 🛡 **[Безопасность](../security.md)** - как AI защищает ваши данные
- 💼 **[Блокчейн для бизнеса](../blockchain-for-business.md)** - интеграция AI с блокчейном
- 📋 **[FAQ](../FAQ.md)** - часто задаваемые вопросы
### Поддержка
- 💬 **Чат поддержки**: https://hb3-accelerator.com/
- 📧 **Email**: info@hb3-accelerator.com
- 📚 **База знаний**: https://hb3-accelerator.com
---
## 🔧 Техническая документация (для разработчиков)
### Архитектура системы AI
```
┌───────────────────────────────────────────────────────────┐
│ Настройка AI Ассистента в DLE │
├───────────────────────────────────────────────────────────┤
│ │
│ 🤖 AI Провайдеры: │
│ ├── OpenAI (GPT-4, GPT-3.5) │
│ ├── Anthropic (Claude) │
│ ├── Google (Gemini) │
│ └── Ollama (локальные модели) │
│ │
│ ⚙️ Настройки AI: │
│ ├── System Prompt │
│ ├── Выбор LLM модели │
│ ├── Выбор Embedding модели │
│ ├── Выбор RAG-таблиц │
│ ├── Правила (Rules) │
│ └── Настройки RAG поиска │
│ │
│ 📋 Правила (Rules): │
│ ├── JSON конфигурация поведения │
│ ├── Создание/редактирование/удаление │
│ └── Привязка к AI ассистенту │
│ │
│ 🔗 Интеграции: │
│ ├── Email (IMAP + SMTP) │
│ └── Telegram Bot │
│ │
│ 🔍 RAG: │
│ ├── Выбор таблиц для поиска │
│ ├── Настройки поиска (гибридный/семантический) │
│ ├── Порог релевантности │
│ └── Извлечение ключевых слов │
│ │
│ 📊 Мониторинг: │
│ ├── Статус сервисов (Backend, Ollama, Postgres) │
│ ├── Тест RAG-функциональности │
│ └── Отслеживание прогресса │
│ │
└───────────────────────────────────────────────────────────┘
```
### База данных
#### Таблица: `ai_providers_settings`
```sql
CREATE TABLE IF NOT EXISTS ai_providers_settings (
id SERIAL PRIMARY KEY,
provider_encrypted TEXT, -- Провайдер: openai, anthropic, google, ollama
api_key_encrypted TEXT, -- API ключ (зашифрован)
base_url_encrypted TEXT, -- Base URL для API
selected_model_encrypted TEXT, -- Выбранная LLM модель
embedding_model_encrypted TEXT, -- Выбранная Embedding модель
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
updated_at TIMESTAMP NOT NULL DEFAULT NOW()
);
```
#### Таблица: `ai_assistant_settings`
```sql
CREATE TABLE IF NOT EXISTS ai_assistant_settings (
id SERIAL PRIMARY KEY,
system_prompt_encrypted TEXT, -- Системный промт
selected_rag_tables INTEGER[], -- Массив ID RAG-таблиц
languages TEXT[], -- Массив поддерживаемых языков
model_encrypted TEXT, -- Выбранная LLM модель
embedding_model_encrypted TEXT, -- Выбранная Embedding модель
rules JSONB, -- Правила (DEPRECATED)
rules_id INTEGER REFERENCES ai_assistant_rules(id), -- Ссылка на правило
telegram_settings_id INTEGER, -- Ссылка на Telegram бота
email_settings_id INTEGER, -- Ссылка на Email настройки
rag_settings JSONB, -- Настройки RAG поиска
updated_at TIMESTAMP DEFAULT NOW(),
updated_by INTEGER
);
```
#### Таблица: `ai_assistant_rules`
```sql
CREATE TABLE IF NOT EXISTS ai_assistant_rules (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL, -- Название набора правил
description TEXT, -- Описание правила
rules JSONB NOT NULL, -- JSON конфигурация
rules_encrypted TEXT, -- Зашифрованная версия правил
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
```
### Backend API
#### Настройки AI провайдеров
- **GET** `/settings/ai-settings/:provider` Получить настройки провайдера
- **PUT** `/settings/ai-settings/:provider` Сохранить настройки провайдера
- **DELETE** `/settings/ai-settings/:provider` Удалить настройки провайдера
- **GET** `/settings/ai-settings/:provider/models` Получить список моделей
- **POST** `/settings/ai-settings/:provider/verify` Проверить API ключ
#### Настройки AI ассистента
- **GET** `/settings/ai-assistant` Получить настройки ассистента
- **PUT** `/settings/ai-assistant` Сохранить настройки ассистента
#### Правила AI
- **GET** `/settings/ai-assistant-rules` Получить все правила
- **GET** `/settings/ai-assistant-rules/:id` Получить правило по ID
- **POST** `/settings/ai-assistant-rules` Создать правило
- **PUT** `/settings/ai-assistant-rules/:id` Обновить правило
- **DELETE** `/settings/ai-assistant-rules/:id` Удалить правило
#### Ollama (локальные модели)
- **GET** `/ollama/status` Проверить статус Ollama
- **GET** `/ollama/models` Получить список моделей
- **POST** `/ollama/install` Установить модель
- **DELETE** `/ollama/models/:modelName` Удалить модель
### Frontend страницы
- **`/settings/ai`** Главная страница интеграций
- **`/settings/ai/:provider`** Настройки AI провайдера
- **`/settings/ai/assistant`** Настройки AI ассистента
### Процесс обработки сообщения
```
1. Пользователь → Сообщение
2. UnifiedMessageProcessor
3. Проверка языка (только русский)
4. Дедупликация (хеш сообщения)
5. Загрузка настроек (aiAssistantSettingsService)
6. Загрузка правил (aiAssistantRulesService)
7. RAG поиск (ragService)
├── Семантический поиск (vector search)
├── Поиск по ключевым словам
└── Гибридный поиск
8. Генерация ответа (generateLLMResponse)
├── System Prompt
├── История разговора
├── Контекст из RAG
└── Правила
9. Ответ → Пользователь
```
### Безопасность
- **Шифрование**: Все чувствительные поля зашифрованы с помощью AES-256
- **Права доступа**: Только администраторы могут изменять настройки
- **Валидация**: Проверка всех входных данных и API ключей
---
**© 2024-2025 Тарабанов Александр Викторович. Все права защищены.**
**Версия документа**: 1.0.0
**Дата создания**: October 25, 2025

View File

@@ -0,0 +1,197 @@
<!--
Copyright (c) 2024-2025 Тарабанов Александр Викторович
All rights reserved.
This software is proprietary and confidential.
Unauthorized copying, modification, or distribution is prohibited.
For licensing inquiries: info@hb3-accelerator.com
Website: https://hb3-accelerator.com
GitHub: https://github.com/VC-HB3-Accelerator
-->
[English](../../docs.en/back-docs/setup-instruction.md) | **Русский**
# Инструкция по настройке приложения Digital Legal Entity
## 🚀 Полный процесс инициализации системы
Этот документ описывает полный процесс подготовки приложения к работе с поддержкой блокчейна, смарт-контрактов и системы управления доступом.
---
## Шаг 1: Установка софта
1. Клонируйте репозиторий проекта на ваше локальное устройство
2. Запустите приложение через Docker Compose или локально в зависимости от конфигурации
3. Откройте веб-приложение в браузере: `http://localhost:9000` (production) или `http://localhost:5173` (dev режим)
---
## Шаг 2: Подключение крипто кошелька
1. Убедитесь, что у вас установлен браузерный кошелек (MetaMask, WalletConnect или аналог)
2. В кошельке создайте или импортируйте аккаунт с токеном управления
3. В веб-приложении нажмите на кнопку **"Подключить кошелек"**
4. Выберите тип кошелька и подтвердите подключение
5. После успешного подключения вы увидите адрес вашего аккаунта в верхнем углу
---
## Шаг 3: Добавление RPC провайдеров (Безопасность → RPC провайдеры)
1. Перейдите в **Настройки** → вкладка **Безопасность**
2. Найдите раздел **"RPC провайдеры"**
3. Нажмите кнопку **"Добавить"**
4. Заполните форму для каждой блокчейн сети, которую хотите использовать:
- **Название сети** (например: Ethereum, Polygon, BSC)
- **RPC URL** (ссылка для подключения, пример: `https://eth-mainnet.g.alchemy.com/v2/YOUR-API-KEY`)
- **ID сети** (Chain ID)
5. Нажмите **"Сохранить"** для каждого провайдера
6. Система автоматически проверит корректность подключения
> ⚠️ **Важно**: Получите API ключи от провайдеров (Alchemy, Infura, Quicknode и т.д.) перед добавлением
---
## Шаг 4: Настройка мультидеплоя смарт контрактов
1. Перейдите в **Настройки** → вкладка **Блокчейн**
2. Заполните форму
3. Нажмите **"Запустить деплой"**
---
## Шаг 5: Завершение деплоя и сохранение адреса контракта
1. Ожидайте завершения деплоя (зависит от сети, обычно 30-120 секунд)
2. После успешного завершения откроется страница **"Управление контрактами"**
3. **Копируйте адрес развернутого контракта** (обычно он выглядит как: `0x742d35Cc6634C0532925a3b844Bc...`)
---
## Шаг 6: Настройка аутентификации через смарт контракт
1. Вернитесь в **Настройки** → вкладка **Аутентификация**
2. В поле **"Адрес смарт контракта"** вставьте адрес, скопированный на шаге 5
3. Установите пороги для управления доступом:
- **Минимальное количество токенов для редактирования** (например: 100 токенов)
- **Минимальное количество токенов для просмотра** (например: 1 токен)
---
## Шаг 7: Настройка ИИ и базы данных
1. Перейдите в **Настройки** → вкладка **ИИ**
2. Откройте подраздел **"База данных"**
3. Замените дефолтные пароли
4. Нажмите **"Сгенерировать новый ключ шифрования"**
- Система автоматически создаст криптографический ключ
- **Сохраните ключ в безопасном месте** (он понадобится для восстановления данных)
---
## Шаг 8: Настройка доступа через интернет (опционально)
**Если вам нужен доступ к веб приложению извне через интернет:**
1. Перейдите в **Настройки** → вкладка **Сервер**
2. На странице **Сервер** выберите **WEB SSH** или иной подходящий сервис
3. Заполните форму для миграции локального приложения на виртуальное устройство с:
- **Публичным IP адресом**
- **Подключением к вашему доменному имени**
4. Нажмите **"Опубликовать"**
5. Дождитесь завершения процесса миграции
> **Примечание**: Этот шаг требует наличия зарегистрированного доменного имени и доступа к DNS настройкам
---
## Шаг 9: Настройка юридических документов для работы с персональными данными
### 9.1 Заполнение юридической информации о компании
1. Перейдите в **CRM** → раздел **Контент**
2. Найдите и откройте форму **"Юридическая информация компании"**
3. Заполните все необходимые поля:
- **Полное наименование организации** (юридическое название)
- **Краткое наименование**
- **Организационно-правовая форма** (ООО, ИП, АО и т.д.)
- **Юридический адрес**
- **Фактический адрес** (если отличается)
- **ИНН / ОГРН / КПП** (регистрационные данные)
- **Контактные данные** (телефон, email, сайт)
- **Ответственное лицо за обработку персональных данных** (ФИО, должность)
- **Применимая юрисдикция** (GDPR, CCPA, российское законодательство и т.д.)
4. Нажмите **"Сохранить"**
> 💡 **Подсказка**: Все введенные данные автоматически подставятся во все шаблоны юридических документов
### 9.2 Работа с шаблонами документов
1. В разделе **Контент** перейдите в подраздел **"Шаблоны"**
2. Выберите необходимые шаблоны документов, требуемые регуляторами:
- **Политика конфиденциальности**
- **Пользовательское соглашение**
- **Согласие на обработку персональных данных**
- **Политика использования cookies**
3. Для каждого шаблона:
- Нажмите **"Предварительный просмотр"** для проверки автоматически заполненных данных
- При необходимости отредактируйте специфичные параметры обработки данных
- Выберите действие:
- **"Опубликовать для публичного использования"** — документ будет доступен на сайте
- **"Опубликовать для внутреннего использования"** — документ доступен только внутри CRM
- **"Распечатать"** — экспорт в PDF для печати или подписания
4. Подтвердите публикацию
5. Система автоматически добавит документы на соответствующие страницы приложения
> ⚠️ **Важно**: Рекомендуется проконсультироваться с юристом перед публикацией документов для обеспечения полного соответствия требованиям законодательства
---
## ✅ Приложение готово к работе!
После завершения всех шагов ваше приложение полностью сконфигурировано и готово к использованию.
**Следующие этапы:**
- 📖 Настройка AI ассистента (см. документ: `setup-ai-assistant.md`)
- 🔐 Управление смарт контрактами (см. документ: `manage-smart-contracts.md`)
---
## 🆘 Рекомендации по безопасности
✓ Сохраняйте адреса контрактов и ключи шифрования в безопасном месте
✓ Используйте мощные пароли для БД
✓ Регулярно создавайте резервные копии конфигурации
✓ Никогда не делитесь приватными ключами кошелька
✓ Используйте HTTPS для доступа к приложению в продакшене
---
## 📝 Что дальше?
После завершения базовой настройки вы можете:
1. Добавлять пользователей и управлять их разрешениями
2. Создавать группы для совместной работы
3. Настраивать AI ассистента для автоматизации задач
4. Управлять смарт контрактами для расширения функциональности
5. Интегрировать внешние сервисы и боты
---
## 📚 Дополнительная документация
### Изучите возможности DLE
- 🤖 **[ИИ-агенты](../ai-assistant.md)** — система создания специализированных агентов под бизнес-процессы
- 💼 **[Блокчейн для бизнеса](../blockchain-for-business.md)** - как токенизация активов решает бизнес-задачи
- 🛡️ **[Безопасность](../security.md)** - многоуровневая защита вашего бизнеса
### Техническая информация
- 🔗 **[Техническая документация по блокчейну](./blockchain-integration-technical.md)** - для разработчиков
- 📋 **[FAQ](../FAQ.md)** - часто задаваемые вопросы
- 📝 **[Описание приложения](../application-description.md)** - обзор функциональности
### Поддержка
- 💬 **Чат поддержки**: https://hb3-accelerator.com/
- 📧 **Email**: info@hb3-accelerator.com

View File

@@ -0,0 +1,134 @@
[English](../../docs.en/back-docs/system-messages-management.md) | **Русский**
# Техническое задание: управление системными сообщениями
## 1. Цель и контекст
- Обеспечить управляемое отображение системных сообщений на главной странице (`/`, компонент `HomeView.vue`) и добавить административный интерфейс для их создания и модерации в разделе контента (`/content`, компонент `ContentListView.vue`).
- Системные сообщения должны поддерживать статусы «черновик» и «опубликовано», храниться в базе данных и быть доступны через REST API.
## 2. Актуальное состояние
- Главная страница строится компонентом `HomeView.vue` и отображает чат ассистента (`ChatInterface.vue`), в котором выделены системные сообщения (`Message.vue`) по признаку `message.role === 'system'`.
- Раздел контента (`ContentListView.vue`) содержит карточки переходов: «Создать страницу», «Шаблоны», «Публичные», «Настройка», «Внутренние». Карточки ведут на существующие маршруты `content-create`, `content-templates`, `content-published`, `content-settings`, `content-internal`.
- В проекте отсутствуют сущности и API для системных сообщений; текущий `pagesService.js` работает только со страницами (`/pages`).
## 3. Новые пользовательские сценарии
- **Просмотр системных сообщений (главная, `/`):**
- Опубликованные системные сообщения подгружаются в чат ассистента и отображаются в виде свернутых карточек с кликабельным заголовком.
- При клике на заголовок сообщение раскрывается: в ленте чата отображается полный текст сообщения **или** отправляется предзаготовленный ответ от ИИ ассистента (контент «ответа» хранится вместе с сообщением и выбирается по флагу `reply_type`).
- Сообщения должны явно маркироваться как системные (цвет, иконка). При повторном открытии пользователь видит последнее состояние раскрытия; возможно локальное запоминание «прочитано».
- **Раздел «Системные сообщения» (`/content`):**
- На странице `/content` появляется новая карточка «Системные сообщения» с кнопкой «Подробнее». Переход ведёт на страницу с пользовательской таблицей (`/content/system-messages/table`), построенной на уже существующих компонентах таблиц (см. `UserTablesList.vue`), без отдельного дэшборда карточек.
- Таблица отображает системные сообщения построчно, с возможностью множественного выбора через чекбоксы; доступные массовые действия: публикация, снятие с публикации, перевод в черновики, удаление.
- Для каждого сообщения по клику «Подробнее» (внутри строки) открывается просмотр/редактирование с формой (см. ниже).
- **Создание/редактирование (`/content/system-messages/create`, `/content/system-messages/:id/edit`):**
- Форма с полями: заголовок, краткое описание, основной текст (Markdown/HTML), тип ответа (`inline` — показывать контент, `assistant_reply` — отправлять подготовленный ответ от ассистента), поле «Ответ ассистента» (активно при `assistant_reply`), тег важности (info/warning/danger), дата начала публикации (опционально), дата окончания (опционально), флаг отображения гостям.
- Кнопки: «Сохранить как черновик», «Опубликовать». При редактировании — «Обновить», «Снять с публикации», «Удалить».
- Проверки: обязательность заголовка и основного текста (или ответа ассистента в соответствующем режиме); валидация дат (окончание ≥ начало).
- **Работа с таблицей системных сообщений:**
- Колонки: чекбокс выбора, заголовок (кликабелен), статус, тип ответа, период действия, целевая аудитория (гости/авторизованные/все), дата создания, автор.
- Массовые действия выполняются для выбранных строк; одиночные действия доступны через контекстное меню/кнопки в строке (редактировать, опубликовать, снять с публикации, удалить).
## 4. Требования к интерфейсу
- В `ContentListView.vue` в сетку `management-blocks` добавить карточку «Системные сообщения» с кнопкой `Подробнее`. По дизайну карточка должна соответствовать существующим блокам (заголовок, описание, кнопка).
- Страница с таблицей системных сообщений:
- Использовать `BaseLayout` и локальные стили (`scoped`).
- Таблица поддерживает сортировку, фильтрацию по статусам и поиск по заголовку.
- Чекбоксы в шапке и строках для массового выбора; панель действий появляется при наличии выбора.
- Кнопка «Создать сообщение» открывает форму создания.
- Форма создания/редактирования:
- Rich-text (минимум Markdown) с предпросмотром и счётчиками символов/слов.
- Переключатель режима показа (`inline`/`assistant_reply`) с условным отображением поля «Ответ ассистента» (можно использовать `<transition>`).
- Поле для выбора иконки/цвета по `severity` (статические пресеты).
- Главная страница:
- Системные сообщения отображаются в блоке чата как свернутые карточки (`system-message-collapsed`). При клике заголовок разворачивает карточку (`system-message-expanded`) или инициирует отправку ассистента (UI показывает «сообщение от ассистента»).
- Для развёрнутых сообщений предусмотреть кнопку «Свернуть» и (опционально) «Отметить как прочитанное». Состояние хранить в `localStorage`.
## 5. Маршрутизация и компоненты
- Добавить маршруты в `router/index.js`:
- - `/content/system-messages/table``SystemMessagesTableView.vue`
- - `/content/system-messages/create``SystemMessageCreateView.vue`
- - `/content/system-messages/:id``SystemMessageDetailsView.vue` (просмотр)
- - `/content/system-messages/:id/edit``SystemMessageEditView.vue`
- При необходимости для модальных/вложенных маршрутов можно использовать дочерние маршруты или именованные вью.
- Создать соответствующие Vue-компоненты в `src/views/content/system-messages/` и общий набор переиспользуемых элементов (таблица, форма, фильтры, массовые действия) в `src/components/system-messages/`.
- Создать сервис `src/services/systemMessagesService.js` с методами для нового API.
## 6. Требования к API и данным
- **Новая таблица** `system_messages` (PostgreSQL):
- `id` (uuid, pk)
- `title` (text, not null)
- `summary` (text, nullable)
- `content` (text, not null)
- `reply_type` (enum: inline, assistant_reply; default inline)
- `assistant_reply_content` (text, nullable; требуется при `reply_type = assistant_reply`)
- `severity` (enum: info, warning, danger; default info)
- `status` (enum: draft, published; not null)
- `visible_for` (enum: all, authenticated, guests; default all)
- `publish_at` (timestamp, nullable)
- `expire_at` (timestamp, nullable)
- `created_at`, `updated_at`
- `created_by`, `updated_by` (references users/identities, nullable)
- `slug` (text, уникальный, для адресации по ссылке при необходимости)
- **REST API (Express):**
- `GET /system-messages` (пагинация, фильтры по статусу, поиску)
- `GET /system-messages/published` (фильтрация по дате/аудитории; публичная)
- `GET /system-messages/:id` (доступ только авторизованным редакторам)
- `POST /system-messages` (создание; права `MANAGE_LEGAL_DOCS`)
- `PATCH /system-messages/:id` (редактирование; проверка статусов)
- `DELETE /system-messages/:id` (мягкое удаление или физическое)
- `POST /system-messages/:id/publish` и `POST /system-messages/:id/unpublish` (опционально, если не использовать PATCH)
- Все защищённые эндпоинты должны требовать авторизацию и права (см. `permissions.js`, `usePermissions`).
- Добавить новую миграцию (`backend/scripts/run-migrations.js`) и ORM/SQL-файлы в существующем формате проекта.
- Обновить логирование и обработку ошибок `winston`, добавить валидацию входных данных (например, `Joi` или кастомную).
## 7. Логика отображения на фронтенде
- `HomeView.vue`:
- При инициализации запрашивать опубликованные системные сообщения (учитывая текущую аудиторию) через `systemMessagesService.getPublished({ includeExpired: false })`.
- Кэшировать ответ в сторе или локальном состоянии; при подписке на WebSocket можно предусмотреть `system_message_updated` событие.
- Добавить обработчик раскрытия: по клику на заголовок либо подставлять полный текст сообщения (`inline`), либо инициировать цепочку отправки `assistant_reply_content` в чат (без участия пользователя).
- Добавить обработчик скрытия сообщения, сохраняющий идентификатор в `localStorage` и фильтрующий локально.
- `ContentListView.vue`:
- Добавить новую карточку «Системные сообщения» в сетку `management-blocks`, не нарушая адаптивную сетку (обновить `grid-template-columns` при необходимости).
- Страницы списков:
- Реализовать пагинацию (lazy loading или обычная), сортировку по дате.
- Для статусов использовать цветовые бейджи (info/warning/danger).
- Форма создания:
- Поддерживать сабмит через `yarn lint`-friendly код; валидация на клиенте (например, с использованием `computed`/`watch`).
- При успешной публикации перенаправлять на список опубликованных; при сохранении черновика — оставаться на странице с уведомлением.
## 8. Требования к безопасности и доступу
- Сценарии создания/изменения доступны только ролям с `PERMISSIONS.MANAGE_LEGAL_DOCS`.
- Публичный список (`GET /system-messages/published`) фильтрует по:
- `status === 'published'`.
- `publish_at <= now()` (или null).
- `expire_at > now()` (или null).
- `visible_for` проверяется на основе контекста (гость/авторизованный).
- При выдаче через чат скрывать поля `created_by`, `updated_by`, внутренние метки.
- Учитывать CSRF, CORS, rate-limit (перенять конфиг из существующих роутов).
## 9. Тестирование
- **Backend:**
- Юнит-тесты для CRUD в `tests/system-messages/*.test.js` (Mocha).
- Проверка фильтров publish/expire и доступа по ролям.
- Тест миграции (откат/применение).
- **Frontend:**
- Юнит-тесты Vue (если настроены) для основных компонентов (форма, список).
- E2E (при наличии) — сценарий: создание черновика → публикация → отображение на главной.
- **Регрессионные проверки:**
- Убедиться, что существующий список контента и чат ассистента продолжают работать без ошибок (`yarn lint`, `yarn test`).
## 10. Интеграция и DevOps
- Обновить `docker-compose.yml` при необходимости (например, добавить миграции в стартовый процесс).
- Убедиться, что новые переменные окружения (если будут, например, лимиты количества сообщений) документированы в `README.md` и `setup-instruction.md`.
- Добавить скрипт seeding (опционально) для тестовых системных сообщений.
## 11. Открытые вопросы
- Нужно ли хранить историю публикаций (auditing)? Если да — предусмотреть таблицу `system_messages_history`.
- Требуется ли поддержка многоязычности? (При отсутствии — ограничение на один язык, RU).
- Нужно ли уведомление по WebSocket при появлении новых сообщений? (Если да — добавить событие в `wsHub.js`).
## 12. Итоговые артефакты
- Backend: новые маршруты, контроллеры, сервис, миграция.
- Frontend: новые страницы и сервис, обновлённые маршруты и компоненты `HomeView`, `ContentListView`.
- Документация: обновление `README.md` (раздел запуск), `application-description.md` или `tables-system.md` при изменении схем, настоящая спецификация.

File diff suppressed because it is too large Load Diff

View File

@@ -1,3 +1,5 @@
[English](../docs.en/blockchain-for-business.md) | **Русский**
# Блокчейн-интеграция для бизнеса: Решение реальных проблем
## Содержание
@@ -207,7 +209,7 @@ Digital Legal Entity решает фундаментальные проблем
### Начните сейчас
1. [Изучите FAQ](../public-docs/FAQ.md) — ответы на популярные вопросы
1. [Изучите FAQ](../FAQ.md) — ответы на популярные вопросы
2. [Установите DLE](./back-docs/setup-instruction.md) — пошаговая инструкция
3. [Настройте блокчейн](./back-docs/blockchain-integration-technical.md) — техническая документация
4. [Получите поддержку](https://hb3-accelerator.com/) — мы поможем!
@@ -216,7 +218,7 @@ Digital Legal Entity решает фундаментальные проблем
## Дополнительные ресурсы
- [FAQ](../public-docs/FAQ.md)
- [FAQ](../FAQ.md)
- [Установка](./back-docs/setup-instruction.md)
- [Техническая документация по блокчейну](./back-docs/blockchain-integration-technical.md)
- [Условия обслуживания](./service-terms.md)

View File

@@ -1,3 +1,5 @@
[English](../docs.en/security.md) | **Русский**
# Безопасность Digital Legal Entity (DLE)
## Содержание
@@ -1299,7 +1301,7 @@ function signMessage(message) {
1. [Изучите техническую документацию](./back-docs/blockchain-integration-technical.md)
2. [Настройте безопасное окружение](./back-docs/setup-instruction.md)
3. [Прочитайте FAQ](../public-docs/FAQ.md)
3. [Прочитайте FAQ](../FAQ.md)
4. [Получите поддержку](https://hb3-accelerator.com/)
---

View File

@@ -1,3 +1,5 @@
[English](../docs.en/service-terms.md) | **Русский**
# Условия приобретения и обслуживания Digital Legal Entity
## Содержание
@@ -16,7 +18,7 @@
12. [Политика изменения условий](#12-политика-изменения-условий)
13. [Контакты](#13-контакты)
**Юридические документы**: [legal/README.md](../legal/README.md) — лицензия, авторские права, требования к атрибуции.
**Юридические документы**: [legal.ru/README.md](../legal.ru/README.md) — лицензия, авторские права, требования к атрибуции.
---
@@ -327,7 +329,7 @@ DLE использует смарт-контракт на блокчейне д
- **Email**: info@hb3-accelerator.com
- **GitHub**: https://github.com/VC-HB3-Accelerator/DLE
- **Юридический статус**: Проприетарное ПО (см. [LICENSE](../LICENSE))
- **Юридическая документация**: [legal/README.md](../legal/README.md)
- **Юридическая документация**: [legal.ru/README.md](../legal.ru/README.md)
---

View File

@@ -0,0 +1,120 @@
**English** | [Русский](../legal.ru/ATTRIBUTION_REQUIREMENTS.md)
# Attribution Requirements
## Mandatory Attribution
When using any code from the DLE (Digital Legal Entity) project, including individual functions, modules, or algorithms, the source must be cited.
## Attribution Formats
### In code comments
```javascript
/**
* Source: DLE (Digital Legal Entity)
* Author: Alexander Viktorovich Tarabanov
* License: Proprietary
* Link: https://github.com/VC-HB3-Accelerator/DLE
*/
```
### In documentation
```markdown
## Used Components
- **DLE Authentication Module** - Alexander Viktorovich Tarabanov
- License: Proprietary
- Source: https://github.com/VC-HB3-Accelerator/DLE
```
### In configuration files
```json
{
"attributions": {
"DLE": {
"author": "Alexander Viktorovich Tarabanov",
"license": "Proprietary",
"source": "https://github.com/VC-HB3-Accelerator/DLE",
"contact": "info@hb3-accelerator.com"
}
}
}
```
## What Requires Attribution
### Source must be cited for:
- Any functions or methods
- Algorithms and logic
- Data structures
- Configuration files
- UI styles and components
- Documentation and comments
### Does not require attribution:
- Standard libraries and frameworks
- Well-known algorithms
- Basic programming patterns
## Attribution Violations
### Considered a violation:
- Using code without citing the source
- Removing or modifying attribution
- Incorrect author attribution
### Consequences:
- Automatic license termination
- Possibility of legal action
- Demand for immediate cessation of use
## Examples of Correct Attribution
### In a JavaScript file
```javascript
// Document validation function
// Source: DLE (Digital Legal Entity) - Alexander Viktorovich Tarabanov
// License: Proprietary
function validateDocument(doc) {
// implementation
}
```
### In a Python file
```python
# Blockchain transaction processing module
# Source: DLE (Digital Legal Entity) - Alexander Viktorovich Tarabanov
# License: Proprietary
class BlockchainProcessor:
# implementation
```
### In a README file
```markdown
## Used Components
This project uses components from DLE (Digital Legal Entity):
- **Authentication System** - Alexander Viktorovich Tarabanov
- **Document Processing** - Alexander Viktorovich Tarabanov
- **Blockchain Integration** - Alexander Viktorovich Tarabanov
**License:** Proprietary
**Contact:** info@hb3-accelerator.com
```
## Contact for Questions
**Alexander Viktorovich Tarabanov**
Email: info@hb3-accelerator.com
Website: https://hb3-accelerator.com
---
**© 2024-2026 Alexander Viktorovich Tarabanov. All rights reserved.**

35
legal.en/AUTHORS.md Normal file
View File

@@ -0,0 +1,35 @@
**English** | [Русский](../legal.ru/AUTHORS.md)
# DLE (Digital Legal Entity) Project Authors
## Lead Developer
**Alexander Viktorovich Tarabanov**
- **GitHub:** [@VC-HB3-Accelerator](https://github.com/VC-HB3-Accelerator)
- **Organization:** HB3 Accelerator
- **Email:** info@hb3-accelerator.com
- **Website:** [hb3-accelerator.com](https://hb3-accelerator.com)
## Contributors
- **LLC "ERAYTI" (ООО "ЭРАЙТИ")**
- **Role:** Official seller and licensing partner for clients in the Russian Federation
- **Contacts:** 18900@эрайти.рф, +7 (968) 269-92-64
## Contact Information
### For copyright and licensing inquiries:
- **Email:** info@hb3-accelerator.com
- **GitHub Issues:** [Create an issue](https://github.com/VC-HB3-Accelerator/DLE/issues)
- **Website:** [hb3-accelerator.com](https://hb3-accelerator.com)
## Project History
- **2024-2026:** Development and release of the first version of DLE
- **Author:** Alexander Viktorovich Tarabanov
- **License:** Proprietary Software License
- **Status:** Active development
---
**All rights reserved.** See [LICENSE](../LICENSE) for details.

79
legal.en/CONTRIBUTING.md Normal file
View File

@@ -0,0 +1,79 @@
**English** | [Русский](../legal.ru/CONTRIBUTING.md)
# Contributor Guide
## Licensing
By contributing to the DLE (Digital Legal Entity) project, you agree that your code will be distributed under the **Proprietary Software License**.
## Copyright
All contributors must:
- Include their name in commits
- Agree to transfer rights to the code to the project author
- Not infringe third-party copyrights
## Contribution Process
### 1. Preparation
- Fork the repository
- Clone your fork locally
- Create a feature branch for your changes
### 2. Development
- Follow the project's coding standards
- Add code comments in English (or the project's primary language)
- Test your changes
### 3. Commits
- Use clear commit messages
- Include your name in commits
- Split large changes into logical parts
### 4. Pull Request
- Create a Pull Request with a description of changes
- Explain what issues your code addresses
- Wait for review from the project author
## Code Standards
### Naming
- Files and folders: kebab-case
- Variables and functions: camelCase
- Constants: UPPER_SNAKE_CASE
- Classes: PascalCase
### Comments
```javascript
/**
* @copyright 2024-2026 Alexander Viktorovich Tarabanov
* @license Proprietary
* @author [Your name] <your-email@example.com>
*/
```
### Git messages
```
feat: add new authentication function
fix: fix data validation error
docs: update API documentation
style: code formatting
refactor: refactor user module
test: add tests for new functionality
```
## Contacts
### For contribution questions:
- **Email:** info@hb3-accelerator.com
- **GitHub Issues:** [Create issue](https://github.com/VC-HB3-Accelerator/DLE/issues)
### Project author:
**Alexander Viktorovich Tarabanov**
Email: info@hb3-accelerator.com
---
**Thank you for contributing to the DLE project!**

View File

@@ -0,0 +1,104 @@
**English** | [Русский](../legal.ru/COPYRIGHT_NOTICE.md)
# Copyright Notice
## For use in code file headers
Add the following header at the top of each source file:
### JavaScript
```javascript
/**
* @copyright 2024-2026 Alexander Viktorovich Tarabanov
* @license Proprietary
* @author Alexander Viktorovich Tarabanov <info@hb3-accelerator.com>
* @see https://github.com/VC-HB3-Accelerator
* @see https://hb3-accelerator.com
*/
```
### Python
```python
"""
@copyright 2024-2026 Alexander Viktorovich Tarabanov
@license Proprietary
@author Alexander Viktorovich Tarabanov <info@hb3-accelerator.com>
@see https://github.com/VC-HB3-Accelerator
@see https://hb3-accelerator.com
"""
```
### Vue
```vue
<!--
@copyright 2024-2026 Alexander Viktorovich Tarabanov
@license Proprietary
@author Alexander Viktorovich Tarabanov <info@hb3-accelerator.com>
@see https://github.com/VC-HB3-Accelerator
@see https://hb3-accelerator.com
-->
```
### CSS/SCSS
```css
/*
@copyright 2024-2026 Alexander Viktorovich Tarabanov
@license Proprietary
@author Alexander Viktorovich Tarabanov <info@hb3-accelerator.com>
@see https://github.com/VC-HB3-Accelerator
@see https://hb3-accelerator.com
*/
```
### HTML
```html
<!--
@copyright 2024-2026 Alexander Viktorovich Tarabanov
@license Proprietary
@author Alexander Viktorovich Tarabanov <info@hb3-accelerator.com>
@see https://github.com/VC-HB3-Accelerator
@see https://hb3-accelerator.com
-->
```
### Configuration files
```json
{
"_copyright": "2024-2026 Alexander Viktorovich Tarabanov",
"_license": "Proprietary",
"_author": "Alexander Viktorovich Tarabanov <info@hb3-accelerator.com>",
"_website": "https://hb3-accelerator.com",
"_github": "https://github.com/VC-HB3-Accelerator"
}
```
## Key files for adding headers
### Frontend
- `frontend/src/main.js`
- `frontend/src/App.vue`
- All Vue components
- All CSS/SCSS styles
### Backend
- `backend/src/index.js`
- All modules and controllers
- Configuration files
### Documentation
- `README.md`
- `docs/` — all documentation files
## Automation
Consider using pre-commit hooks to automatically add copyright headers to new files.
---
**All rights reserved.** See [LICENSE](../LICENSE) for details.

137
legal.en/README.md Normal file
View File

@@ -0,0 +1,137 @@
**English** | [Русский](../legal.ru/README.md)
# DLE Legal Documentation
## Project Intellectual Property Protection
**Language:** English
---
## Document Overview
This section contains legal documentation for the protection of the DLE (Digital Legal Entity) project's intellectual property.
### Confidential Documents
**Patent documents (do not publish):**
- [patents/](patents/) — patent applications and innovation processes
- Russian Federation patent applications
- Technical specifications
- Innovation processes
- Strategic plans
**Important:** Patent documents contain confidential information and must not be published in public repositories.
### Public Documents
**Copyright and licenses:**
- [AUTHORS.md](AUTHORS.md) — author information
- [CONTRIBUTING.md](CONTRIBUTING.md) — contributor guidelines
- [COPYRIGHT_NOTICE.md](COPYRIGHT_NOTICE.md) — copyright notice templates
**Licensing and terms:**
- [Terms of Purchase and Service](../docs.en/service-terms.md) — detailed licensing terms
- [ATTRIBUTION_REQUIREMENTS.md](ATTRIBUTION_REQUIREMENTS.md) — attribution requirements
- [USAGE_NOTIFICATION.md](USAGE_NOTIFICATION.md) — usage notifications
**File overview**
| File | Purpose |
|------|----------|
| [AUTHORS.md](AUTHORS.md) | Author information and contacts |
| [CONTRIBUTING.md](CONTRIBUTING.md) | Contribution guidelines for project contributors |
| [COPYRIGHT_NOTICE.md](COPYRIGHT_NOTICE.md) | Copyright notice templates |
| [service-terms.md](../docs.en/service-terms.md) | Detailed licensing and service terms |
| [ATTRIBUTION_REQUIREMENTS.md](ATTRIBUTION_REQUIREMENTS.md) | Required attribution formats and examples |
| [USAGE_NOTIFICATION.md](USAGE_NOTIFICATION.md) | Usage notification instructions and template |
**Full terms of service:** [docs.en/service-terms.md](../docs.en/service-terms.md)
- Licensing model (Perpetual License)
- Pricing: Standard and Premium
- Voting system via smart contract
- 70% refund program
- Technical support: https://hb3-accelerator.com/
---
## Licensing Model
### Perpetual License
- **Price:** 1,000 USDT (Standard) or 10,000 USDT (Premium)
- **Term:** perpetual (no time limit)
- **Updates:** free for 5 years for license token holders (see [docs.en/service-terms.md](../docs.en/service-terms.md))
- **Voting:** blockchain voting for new feature development
### DLE Smart Contract Governance
Application development is governed via an on-chain smart contract:
- 1 token = 1 vote
- 51%+ for majority decisions
- Multichain voting and execution support
- Transparency — all decisions on blockchain
### Licensee Portal
- **Portal:** https://hb3-accelerator.com/
- **Download updates:** https://hb3-accelerator.com/
- **Support:** https://hb3-accelerator.com/
### Protection Structure
```
legal/
├── AUTHORS.md — Project authors
├── CONTRIBUTING.md — Contribution guidelines
├── COPYRIGHT_NOTICE.md — Copyright notice templates
├── ATTRIBUTION_REQUIREMENTS.md — Attribution requirements
├── USAGE_NOTIFICATION.md — Usage notifications
└── README.md — This file
docs/
└── service-terms.md — Terms of purchase and service
```
### Protection Mechanisms
**1. Copyright:** All files contain the copyright of Alexander V. Tarabanov. Proprietary license applies. Copying without permission is prohibited.
**2. Patent protection:** Confidential documents in the `patents/` folder. Folder in `.gitignore`. Documents are not published in repositories.
**3. Licensing:** Strict proprietary license. Attribution required when using the software.
**4. Monitoring:** Code usage notifications. Attribution requirements.
### Usage Recommendations
**For developers:**
1. Read [LICENSE](../LICENSE) before use
2. Comply with [ATTRIBUTION_REQUIREMENTS.md](ATTRIBUTION_REQUIREMENTS.md)
3. Notify the author per [USAGE_NOTIFICATION.md](USAGE_NOTIFICATION.md)
**For use:**
1. Respect copyright
2. Cite the source when using
3. Do not transfer to third parties
---
## Contacts
**Author:** Alexander Viktorovich Tarabanov
**Email:** info@hb3-accelerator.com
**Website:** https://hb3-accelerator.com
**GitHub:** https://github.com/VC-HB3-Accelerator
---
## Legal Notice
All documents in this section are protected by copyright. Unauthorized use, copying, or distribution is prohibited.
For permission to use, contact the author at the above addresses.
---
**Last updated:** 2026-02-19

View File

@@ -0,0 +1,137 @@
**English** | [Русский](../legal.ru/USAGE_NOTIFICATION.md)
# Usage Notification Requirements
## Mandatory Notifications
When using code from the DLE (Digital Legal Entity) project in any form, including private repositories, the author must be notified.
## When Notification Is Required
### Notification required:
- Use in private repositories
- Integration into existing systems
- Creation of derivative works
- Use for educational purposes
### Notification not required:
- Personal code study
- Functional testing
- Demonstration of capabilities
## Notification Format
### Email notification
```
Subject: DLE Usage Notification
Dear Alexander Viktorovich Tarabanov,
We are notifying you of the use of code from the DLE (Digital Legal Entity) project:
## Project information:
- Project name: [NAME]
- Description: [DESCRIPTION]
- Type of use: [EDUCATIONAL/PERSONAL]
## Components used:
- [LIST OF USED MODULES/FUNCTIONS]
## Contact information:
- Name: [FULL NAME]
- Email: [EMAIL]
- Organization: [ORGANIZATION]
## Intended use:
- [DESCRIPTION OF PLANS]
Sincerely,
[FULL NAME]
[EMAIL]
```
### GitHub Issue
Create an issue in the repository with the `usage-notification` label:
- Project description
- List of components used
- Contact information
- Intended use
## Notification Deadlines
- **Before starting use** — for commercial projects
- **Within 30 days** — for educational projects
- **Within 90 days** — for personal projects
## Consequences of Failure to Notify
### License violation:
- Automatic termination of rights to use
- Possibility of demand to cease use
- Potential legal consequences
### Exceptions:
- Use for demonstration purposes
- Short-term testing
- Study of architecture and algorithms
## Usage Monitoring
### Automated monitoring:
- Tracking repository forks
- Monitoring code mentions
- Analysis of npm/pip dependencies
### Manual monitoring:
- Search on GitHub/GitLab
- Technical blog monitoring
- Conference and presentation tracking
## Notification Contacts
**Alexander Viktorovich Tarabanov**
- **Email:** info@hb3-accelerator.com
- **GitHub Issues:** [Create issue](https://github.com/VC-HB3-Accelerator/DLE/issues)
- **Subject:** "DLE Usage Notification"
## Notification Templates
### For commercial use
```
Subject: Commercial DLE Usage Notification
We are notifying you of commercial use of DLE in the project [NAME].
Licensing is required to continue use.
Project details are attached.
```
### For educational use
```
Subject: Educational DLE Usage Notification
We are notifying you of the use of DLE for educational purposes.
Project: [NAME]
Institution: [NAME]
Permission is required for use in courses.
```
### For personal use
```
Subject: Personal DLE Usage Notification
We are notifying you of personal use of DLE in the project [NAME].
Use: [DESCRIPTION]
Thank you for creating an excellent tool!
```
---
**© 2024-2026 Alexander Viktorovich Tarabanov. All rights reserved.**

View File

@@ -1,3 +1,5 @@
[English](../legal.en/ATTRIBUTION_REQUIREMENTS.md) | **Русский**
# Требования к атрибуции
## Обязательная атрибуция

View File

@@ -1,3 +1,5 @@
[English](../legal.en/AUTHORS.md) | **Русский**
# Авторы проекта DLE (Digital Legal Entity)
## Основной разработчик

View File

@@ -1,3 +1,5 @@
[English](../legal.en/CONTRIBUTING.md) | **Русский**
# Руководство для контрибьюторов
## Лицензирование

View File

@@ -1,3 +1,5 @@
[English](../legal.en/COPYRIGHT_NOTICE.md) | **Русский**
# Уведомление об авторских правах
## Для использования в заголовках файлов кода

View File

@@ -1,3 +1,5 @@
[English](../legal.en/README.md) | **Русский**
# Юридическая документация DLE
## Защита интеллектуальной собственности проекта
@@ -28,7 +30,7 @@
- [COPYRIGHT_NOTICE.md](COPYRIGHT_NOTICE.md) — шаблоны копирайтов
**Лицензирование и условия:**
- [Условия приобретения и обслуживания](../docs/service-terms.md) — подробные условия лицензирования
- [Условия приобретения и обслуживания](../docs.ru/service-terms.md) — подробные условия лицензирования
- [ATTRIBUTION_REQUIREMENTS.md](ATTRIBUTION_REQUIREMENTS.md) — требования к атрибуции
- [USAGE_NOTIFICATION.md](USAGE_NOTIFICATION.md) — уведомления об использовании
@@ -39,11 +41,11 @@
| [AUTHORS.md](AUTHORS.md) | Сведения об авторах и контактная информация |
| [CONTRIBUTING.md](CONTRIBUTING.md) | Правила участия для контрибьюторов проекта |
| [COPYRIGHT_NOTICE.md](COPYRIGHT_NOTICE.md) | Шаблоны уведомлений об авторских правах |
| [service-terms.md](../docs/service-terms.md) | Подробные условия лицензирования и обслуживания |
| [service-terms.md](../docs.ru/service-terms.md) | Подробные условия лицензирования и обслуживания |
| [ATTRIBUTION_REQUIREMENTS.md](ATTRIBUTION_REQUIREMENTS.md) | Форматы и примеры обязательной атрибуции |
| [USAGE_NOTIFICATION.md](USAGE_NOTIFICATION.md) | Инструкция и шаблон уведомления об использовании |
**Полные условия обслуживания:** [docs/service-terms.md](../docs/service-terms.md)
**Полные условия обслуживания:** [docs.ru/service-terms.md](../docs.ru/service-terms.md)
- Лицензионная модель (Perpetual License)
- Тарифы: Standard и Premium
- Система голосования через смарт-контракт
@@ -58,7 +60,7 @@
- **Цена:** 1 000 USDT (Standard) или 10 000 USDT (Premium)
- **Срок:** бессрочный (без ограничения по времени)
- **Обновления:** бесплатно в течение 5 лет для держателей лицензионных токенов (см. [docs/service-terms.md](../docs/service-terms.md))
- **Обновления:** бесплатно в течение 5 лет для держателей лицензионных токенов (см. [docs.ru/service-terms.md](../docs.ru/service-terms.md))
- **Голосование:** блокчейн-голосование за развитие новых функций
### Управление через смарт-контракт DLE

View File

@@ -1,3 +1,5 @@
[English](../legal.en/USAGE_NOTIFICATION.md) | **Русский**
# Требования к уведомлению об использовании
## Обязательные уведомления