# Дорожная Карта Реализации Phantom Protocol: От Прототипа к Production

**Автор:** Manus AI  
**Дата:** 22 ноября 2025  
**Версия:** 1.0

---

## Резюме

Этот документ представляет собой **полную дорожную карту разработки**, необходимую для приведения Phantom Protocol 2025 в соответствие с его официальной документацией. Анализ показал, что проект находится примерно на **30% готовности** относительно заявленного функционала. Для достижения полного соответствия потребуется **10-30 месяцев разработки** в зависимости от размера команды и приоритетов.

---

## 📊 Текущее Состояние vs Целевое

| Компонент | Текущий статус | Целевой статус | Разрыв |
|:---|:---|:---|:---|
| **Ядро протокола** | ✅ 95% | ✅ 100% | 5% |
| **Hidden Services** | ❌ 0% (только .h) | ✅ 100% | **100%** |
| **Exit Nodes** | ❌ 0% (только .h) | ✅ 100% | **100%** |
| **TLD система** | ⚠️ 40% (прототип) | ✅ 100% | **60%** |
| **DNS интеграция** | ❌ 0% (нет DHT) | ✅ 100% | **100%** |
| **Примеры** | ⚠️ 25% (2 из 8) | ✅ 100% | **75%** |
| **Тесты** | ⚠️ 20% (только deploy) | ✅ 100% | **80%** |
| **Документация** | ✅ 90% | ✅ 100% | 10% |

**Общая готовность:** ~30%

---

## 🎯 Стратегия Реализации

### Фаза 0: Критическое Исправление (НЕМЕДЛЕННО)
**Срок:** 1 неделя  
**Команда:** 1 разработчик

Исправление критической уязвимости в SOCKS5 прокси, которая создает ложное чувство безопасности.

### Фаза 1: Стабилизация Ядра (Месяцы 1-2)
**Срок:** 2 месяца  
**Команда:** 2-3 разработчика

Доработка основного функционала до production-ready состояния.

### Фаза 2: Hidden Services (Месяцы 3-6)
**Срок:** 4 месяца  
**Команда:** 3-4 разработчика

Полная реализация скрытых сервисов с нуля.

### Фаза 3: Exit Nodes (Месяцы 7-9)
**Срок:** 3 месяца  
**Команда:** 2-3 разработчика

Реализация выходных узлов и интеграция с SOCKS5.

### Фаза 4: TLD Система (Месяцы 10-15)
**Срок:** 6 месяцев  
**Команда:** 4-5 разработчиков

Завершение TLD системы и достижение заявленной производительности.

### Фаза 5: Примеры и Тесты (Месяцы 16-18)
**Срок:** 3 месяца  
**Команда:** 2-3 разработчика

Создание всех заявленных примеров и функциональных тестов.

---

## 📋 Детальный Чек-лист

### 🚨 ФАЗА 0: Критическое Исправление (1 неделя)

#### Задача 0.1: Исправить SOCKS5 Fallback
**Приоритет:** 🚨 КРИТИЧЕСКИЙ  
**Сложность:** Средняя (3-5 дней)  
**Ответственный:** Senior Developer

**Описание:**  
В текущей реализации `socks5-proxy.py` при ошибке подключения к Phantom-узлу автоматически устанавливается прямое, неанонимное соединение. Это создает критическую угрозу безопасности.

**Что нужно сделать:**

1. **Удалить fallback-код** из `socks5-proxy.py`:
   ```python
   # УДАЛИТЬ ЭТИ СТРОКИ:
   except socket.error as e:
       logger.info(f"Fallback: прямое подключение к {target_host}:{target_port}")
       self.socket.connect((target_host, target_port))
   ```

2. **Реализовать fail-secure поведение:**
   ```python
   except socket.error as e:
       logger.error(f"Не удалось подключиться к Phantom сети: {e}")
       logger.error("Соединение прервано для обеспечения безопасности")
       self._send_error_response(SOCKS5_HOST_UNREACHABLE)
       return False
   ```

3. **Добавить предупреждение в логи:**
   ```python
   logger.warning("⚠️ ВНИМАНИЕ: Прямое подключение ЗАПРЕЩЕНО для анонимности")
   ```

4. **Обновить документацию:**
   - Добавить в `user-guide-complete-ru.md` раздел о том, что прокси **никогда** не устанавливает прямое соединение
   - Добавить предупреждение о необходимости проверки логов

**Критерий приемки:**
- ✅ При ошибке подключения к Phantom прокси завершает работу с ошибкой
- ✅ Никогда не устанавливается прямое соединение
- ✅ В логах четко указано, что соединение прервано для безопасности
- ✅ Документация обновлена

---

### 🔴 ФАЗА 1: Стабилизация Ядра (2 месяца)

#### Задача 1.1: Завершить портирование на OpenSSL 3.0+
**Приоритет:** 🔴 Высокий  
**Сложность:** Средняя (1-2 недели)  
**Ответственный:** Senior C Developer

**Что нужно сделать:**
1. Проверить все файлы на использование deprecated функций
2. Заменить оставшиеся вызовы устаревших API
3. Добавить unit-тесты для криптографических функций
4. Провести security audit портированного кода

**Критерий приемки:**
- ✅ Компиляция без warnings
- ✅ Все unit-тесты проходят
- ✅ Security audit не выявил уязвимостей

#### Задача 1.2: Оптимизация Kademlia DHT
**Приоритет:** 🔴 Высокий  
**Сложность:** Высокая (3-4 недели)  
**Ответственный:** Distributed Systems Expert

**Что нужно сделать:**
1. Профилирование производительности DHT
2. Оптимизация алгоритмов поиска узлов
3. Реализация кэширования маршрутов
4. Тесты производительности под нагрузкой

**Критерий приемки:**
- ✅ Время поиска узла < 100ms
- ✅ Сеть стабильна при 1000+ узлов
- ✅ Нагрузочные тесты пройдены

#### Задача 1.3: Улучшение обработки ошибок
**Приоритет:** 🟡 Средний  
**Сложность:** Средняя (1-2 недели)  
**Ответственный:** Mid-level Developer

**Что нужно сделать:**
1. Добавить структурированное логирование
2. Реализовать graceful degradation
3. Улучшить обработку сетевых ошибок
4. Добавить метрики для мониторинга

**Критерий приемки:**
- ✅ Все критические пути имеют обработку ошибок
- ✅ Логи структурированы и информативны
- ✅ Система корректно восстанавливается после сбоев

---

### 🔴 ФАЗА 2: Hidden Services (4 месяца)

#### Задача 2.1: Создать phantom_hidden_service.c
**Приоритет:** 🔴 Высокий  
**Сложность:** Очень высокая (6-8 недель)  
**Ответственный:** Senior C Developer + Crypto Expert

**Что нужно сделать:**

1. **Реализовать генерацию ключей сервиса:**
   ```c
   int phantom_hs_init(struct phantom_hidden_service **hs, const char *service_name) {
       // Генерация Ed25519 keypair для сервиса
       // Вычисление service_id = hash(public_key)
       // Сохранение приватного ключа в защищенное хранилище
   }
   ```

2. **Реализовать создание дескриптора:**
   ```c
   struct phantom_hs_descriptor* phantom_hs_create_descriptor(
       struct phantom_hidden_service *hs,
       const char *introduction_points[],
       int num_points
   ) {
       // Создание зашифрованного дескриптора
       // Подпись дескриптора приватным ключом
       // Возврат готового дескриптора
   }
   ```

3. **Реализовать публикацию в DHT:**
   ```c
   int phantom_hs_publish(struct phantom_hidden_service *hs) {
       // Создание дескриптора с introduction points
       // Шифрование дескриптора
       // Публикация в Kademlia DHT по ключу service_id
       // Периодическое обновление (каждые 24 часа)
   }
   ```

4. **Реализовать поиск сервиса:**
   ```c
   struct phantom_hs_descriptor* phantom_hs_lookup(const char *service_id) {
       // Поиск дескриптора в DHT по service_id
       // Расшифровка дескриптора
       // Проверка подписи
       // Возврат дескриптора или NULL
   }
   ```

5. **Реализовать установку соединения:**
   ```c
   int phantom_hs_connect(const char *service_id, struct phantom_hs_connection **conn) {
       // Поиск дескриптора сервиса
       // Выбор introduction point
       // Построение туннеля к introduction point
       // Согласование rendezvous point
       // Установка зашифрованного соединения
   }
   ```

**Критерий приемки:**
- ✅ Все функции из `phantom_hidden_service.h` реализованы
- ✅ Дескрипторы успешно публикуются и находятся в DHT
- ✅ Клиент может установить соединение с сервисом
- ✅ Соединение зашифровано end-to-end
- ✅ Unit-тесты покрывают все функции

**Оценка времени:** 6-8 недель

#### Задача 2.2: Создать CLI-инструмент phantom-hidden-service
**Приоритет:** 🔴 Высокий  
**Сложность:** Средняя (2-3 недели)  
**Ответственный:** Mid-level Developer

**Что нужно сделать:**

1. **Создать файл `tools/phantom-hidden-service.c`:**
   ```c
   // Парсинг аргументов командной строки
   // Интеграция с phantom_hidden_service.c
   // Вывод результатов в user-friendly формате
   ```

2. **Реализовать команды:**
   - `--create --name <name>` - создание нового сервиса
   - `--bind <service_id>:port --target host:port` - привязка к локальному сервису
   - `--list` - список всех сервисов
   - `--delete <service_id>` - удаление сервиса

3. **Добавить в Makefile:**
   ```makefile
   phantom-hidden-service: tools/phantom-hidden-service.c src/phantom_hidden_service.o
       $(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS)
   ```

**Критерий приемки:**
- ✅ Инструмент компилируется и запускается
- ✅ Все команды из документации работают
- ✅ Вывод понятен пользователю
- ✅ Обработка ошибок корректна

**Оценка времени:** 2-3 недели

#### Задача 2.3: Написать функциональные тесты
**Приоритет:** 🔴 Высокий  
**Сложность:** Высокая (2-3 недели)  
**Ответственный:** QA Engineer + Developer

**Что нужно сделать:**

1. **Создать тестовый скрипт `test-hidden-services.sh`:**
   ```bash
   #!/bin/bash
   # Запуск локальной Phantom сети (5 узлов)
   # Создание hidden service
   # Запуск веб-сервера на порту 8080
   # Привязка к hidden service
   # Попытка подключения клиента
   # Скачивание тестового файла
   # Проверка целостности данных
   ```

2. **Создать Python-тест для автоматизации:**
   ```python
   def test_hidden_service_creation():
       # Тест создания сервиса
   
   def test_hidden_service_publish():
       # Тест публикации в DHT
   
   def test_hidden_service_connection():
       # Тест установки соединения
   
   def test_hidden_service_data_transfer():
       # Тест передачи данных
   ```

**Критерий приемки:**
- ✅ Все тесты проходят автоматически
- ✅ Покрытие кода > 80%
- ✅ Тесты интегрированы в CI/CD

**Оценка времени:** 2-3 недели

---

### 🔴 ФАЗА 3: Exit Nodes (3 месяца)

#### Задача 3.1: Создать phantom_exit_node.c
**Приоритет:** 🔴 Высокий  
**Сложность:** Очень высокая (4-6 недель)  
**Ответственный:** Senior Network Developer

**Что нужно сделать:**

1. **Реализовать инициализацию выходного узла:**
   ```c
   int phantom_exit_init(struct phantom_exit_node **node, const char *config_file) {
       // Загрузка конфигурации (exit policy)
       // Инициализация сетевых сокетов
       // Регистрация в DHT как exit node
   }
   ```

2. **Реализовать обработку запросов:**
   ```c
   int phantom_exit_handle_request(
       struct phantom_exit_node *node,
       struct phantom_tunnel *tunnel,
       const char *target_host,
       uint16_t target_port
   ) {
       // Проверка exit policy
       // Установка TCP-соединения с target
       // Проксирование данных между tunnel и target
       // Обработка ошибок и таймаутов
   }
   ```

3. **Реализовать exit policy:**
   ```c
   int phantom_exit_check_policy(
       struct phantom_exit_node *node,
       const char *target_host,
       uint16_t target_port
   ) {
       // Проверка по whitelist/blacklist
       // Проверка портов (разрешены ли 80, 443, и т.д.)
       // Возврат ALLOWED/DENIED
   }
   ```

**Критерий приемки:**
- ✅ Выходной узел успешно регистрируется в DHT
- ✅ Клиент может найти exit node через DHT
- ✅ Exit node корректно проксирует трафик
- ✅ Exit policy работает корректно

**Оценка времени:** 4-6 недель

#### Задача 3.2: Интегрировать SOCKS5 с Phantom
**Приоритет:** 🔴 Высокий  
**Сложность:** Высокая (3-4 недели)  
**Ответственный:** Senior Developer

**Что нужно сделать:**

1. **Переписать `socks5-proxy.py` на C:**
   - Создать `tools/phantom-socks5-proxy.c`
   - Использовать реальные функции из `libphantom.so`
   - Удалить все симуляции и fallback-код

2. **Реализовать построение туннеля:**
   ```c
   int socks5_build_phantom_tunnel(
       const char *target_host,
       uint16_t target_port,
       int hops,
       struct phantom_tunnel **tunnel
   ) {
       // Поиск exit node в DHT
       // Построение туннеля через hops узлов к exit node
       // Отправка запроса на подключение к target
       // Возврат готового туннеля
   }
   ```

**Критерий приемки:**
- ✅ SOCKS5 прокси использует реальную сеть Phantom
- ✅ Нет fallback на прямое соединение
- ✅ Трафик проходит через заданное количество хопов
- ✅ Exit node успешно подключается к целевому хосту

**Оценка времени:** 3-4 недели

---

### 🔴 ФАЗА 4: TLD Система (6 месяцев)

#### Задача 4.1: Завершить все TODO
**Приоритет:** 🔴 Высокий  
**Сложность:** Высокая (4-6 недель)  
**Ответственный:** Senior Developer

**Что нужно сделать:**

1. **Найти все TODO:**
   ```bash
   grep -rn "TODO" src/phantom_dns*.c src/phantom_domain_registry.c src/phantom_consensus.c
   ```

2. **Для каждого TODO:**
   - Проанализировать, что нужно реализовать
   - Написать реализацию
   - Добавить unit-тест
   - Удалить пометку TODO

**Критерий приемки:**
- ✅ Команда `grep -r "TODO" src/` не находит пометок в TLD-файлах
- ✅ Все функции полностью реализованы
- ✅ Unit-тесты покрывают новый код

**Оценка времени:** 4-6 недель

#### Задача 4.2: Интегрировать DNS с Kademlia DHT
**Приоритет:** 🔴 Высокий  
**Сложность:** Очень высокая (8-10 недель)  
**Ответственный:** Distributed Systems Expert

**Что нужно сделать:**

1. **Реализовать хранение DNS-записей в DHT:**
   ```c
   int phantom_dns_dht_store(
       const char *domain,
       const struct phantom_dns_record *record
   ) {
       // Вычисление ключа DHT = hash(domain)
       // Сериализация DNS-записи
       // Сохранение в Kademlia DHT
       // Репликация на k ближайших узлов
   }
   ```

2. **Реализовать поиск DNS-записей:**
   ```c
   struct phantom_dns_record* phantom_dns_dht_lookup(
       const char *domain,
       uint16_t type
   ) {
       // Вычисление ключа DHT
       // Поиск в Kademlia DHT
       // Десериализация записи
       // Проверка подписи валидатора
       // Возврат записи или NULL
   }
   ```

3. **Реализовать кэширование:**
   - Локальный кэш DNS-записей
   - TTL и инвалидация
   - LRU eviction policy

**Критерий приемки:**
- ✅ DNS-записи успешно сохраняются в DHT
- ✅ DNS-резолвер находит записи через DHT
- ✅ Кэширование работает корректно
- ✅ Производительность приемлема (< 100ms на запрос)

**Оценка времени:** 8-10 недель

#### Задача 4.3: Реализовать консенсус
**Приоритет:** 🔴 Высокий  
**Сложность:** Очень высокая (8-12 недель)  
**Ответственный:** Distributed Systems Expert + Crypto Expert

**Что нужно сделать:**

1. **Выбрать алгоритм консенсуса:**
   - Изучить варианты (Raft, PBFT, PoS)
   - Выбрать подходящий для TLD системы

2. **Реализовать механизм голосования:**
   ```c
   int phantom_consensus_vote(
       struct phantom_consensus_state *state,
       const struct phantom_dns_update *update
   ) {
       // Валидаторы голосуют за обновление DNS
       // Сбор голосов
       // Достижение кворума (>2/3 валидаторов)
       // Применение обновления
   }
   ```

3. **Реализовать разрешение конфликтов:**
   - Обработка fork'ов в DNS-истории
   - Выбор канонической версии

**Критерий приемки:**
- ✅ Валидаторы достигают консенсуса
- ✅ Конфликты разрешаются корректно
- ✅ Система устойчива к Byzantine failures

**Оценка времени:** 8-12 недель

#### Задача 4.4: Оптимизация производительности
**Приоритет:** 🟡 Средний  
**Сложность:** Очень высокая (6-8 недель)  
**Ответственный:** Performance Engineer

**Что нужно сделать:**

1. **Профилирование:**
   - Найти узкие места
   - Измерить текущую производительность

2. **Оптимизация:**
   - Параллелизация запросов
   - Оптимизация структур данных
   - Использование zero-copy техник

3. **Нагрузочное тестирование:**
   - Создать генератор нагрузки
   - Достичь 100,000+ QPS

**Критерий приемки:**
- ✅ Система обрабатывает 100,000+ DNS запросов/сек
- ✅ Латентность < 50ms (p99)
- ✅ Стабильность под нагрузкой

**Оценка времени:** 6-8 недель

#### Задача 4.5: Реализовать шардинг
**Приоритет:** 🟡 Средний  
**Сложность:** Очень высокая (6-8 недель)  
**Ответственный:** Distributed Systems Expert

**Что нужно сделать:**

1. **Разделить пространство доменов:**
   - Consistent hashing для распределения доменов
   - Группы валидаторов для каждого шарда

2. **Реализовать координацию шардов:**
   - Маршрутизация запросов к правильному шарду
   - Балансировка нагрузки

**Критерий приемки:**
- ✅ Домены распределены по шардам
- ✅ Система масштабируется до миллиардов доменов
- ✅ Балансировка нагрузки работает

**Оценка времени:** 6-8 недель

---

### 🟡 ФАЗА 5: Примеры и Тесты (3 месяца)

#### Задача 5.1: Реализовать остальные 6 примеров
**Приоритет:** 🟡 Средний  
**Сложность:** Высокая (8-10 недель)  
**Ответственный:** Mid-level Developer

**Что нужно сделать:**

1. **Anonymous File Storage** (2 недели)
2. **Encrypted Messenger** (2 недели)
3. **TCP Tunnels** (1 неделя)
4. **Hidden Websites** (2 недели) - зависит от Hidden Services
5. **Custom TLD** (1 неделя) - зависит от TLD системы
6. **VPN через Phantom** (2 недели)

**Критерий приемки:**
- ✅ Все 8 примеров реализованы и работают
- ✅ Примеры используют реальную сеть Phantom
- ✅ Документация обновлена

**Оценка времени:** 8-10 недель

#### Задача 5.2: Создать функциональные тесты
**Приоритет:** 🟡 Средний  
**Сложность:** Высокая (4-6 недель)  
**Ответственный:** QA Engineer

**Что нужно сделать:**

1. **End-to-end тесты:**
   - Тест полного цикла передачи данных
   - Тест анонимности (проверка, что IP не раскрыт)
   - Тест устойчивости к отказам узлов

2. **Интеграционные тесты:**
   - Тесты взаимодействия компонентов
   - Тесты совместимости версий

**Критерий приемки:**
- ✅ Все критические сценарии покрыты тестами
- ✅ Тесты проходят автоматически в CI/CD
- ✅ Покрытие кода > 70%

**Оценка времени:** 4-6 недель

---

### 🟢 ФАЗА 6: Документация (1 месяц)

#### Задача 6.1: Обновить документацию
**Приоритет:** 🟢 Низкий  
**Сложность:** Средняя (2-3 недели)  
**Ответственный:** Technical Writer

**Что нужно сделать:**

1. **Разделить документацию:**
   - ✅ **Реализовано** - что работает сейчас
   - 🚧 **В разработке** - что находится в процессе
   - 📋 **Планируется** - что будет реализовано

2. **Добавить предупреждения:**
   ```markdown
   ⚠️ **ВНИМАНИЕ:** Данная функция находится в стадии разработки.
   Не используйте в продакшене.
   ```

3. **Создать roadmap:**
   - Публичная дорожная карта с датами
   - Статусы для каждой функции

**Критерий приемки:**
- ✅ Документация соответствует реальности
- ✅ Нет вводящих в заблуждение заявлений
- ✅ Roadmap опубликован

**Оценка времени:** 2-3 недели

#### Задача 6.2: Провести полную русификацию
**Приоритет:** 🟢 Низкий  
**Сложность:** Средняя (2-3 недели)  
**Ответственный:** Developer + Translator

**Что нужно сделать:**

1. **Добавить русские комментарии:**
   - Пройтись по всем 71 файлам
   - Добавить комментарии к функциям и структурам
   - Сохранить английские комментарии для совместимости

**Критерий приемки:**
- ✅ Все публичные API имеют русские комментарии
- ✅ Ключевые алгоритмы прокомментированы на русском

**Оценка времени:** 2-3 недели

---

## 📊 Итоговая Оценка Ресурсов

### Временные оценки по фазам

| Фаза | Срок (мин) | Срок (макс) | Команда |
|:---|:---:|:---:|:---|
| **Фаза 0: Критическое** | 3 дня | 1 неделя | 1 dev |
| **Фаза 1: Ядро** | 6 недель | 8 недель | 2-3 devs |
| **Фаза 2: Hidden Services** | 10 недель | 14 недель | 3-4 devs |
| **Фаза 3: Exit Nodes** | 7 недель | 10 недель | 2-3 devs |
| **Фаза 4: TLD** | 32 недели | 46 недель | 4-5 devs |
| **Фаза 5: Примеры/Тесты** | 12 недель | 16 недель | 2-3 devs |
| **Фаза 6: Документация** | 4 недели | 6 недель | 1-2 devs |
| **ИТОГО** | **~18 месяцев** | **~26 месяцев** | **3-5 devs** |

### Оценка стоимости (приблизительная)

**Предположения:**
- Средняя зарплата разработчика: $80,000/год
- Команда: 4 разработчика
- Срок: 24 месяца

**Расчет:**
- $80,000 × 4 devs × 2 года = **$640,000**
- + Инфраструктура, тестирование, управление: **+30%**
- **Итого: ~$830,000**

---

## 🎯 Рекомендации по Приоритизации

### Сценарий 1: Минимальный Viable Product (MVP)
**Цель:** Быстро получить работающий продукт  
**Срок:** 6-9 месяцев  
**Команда:** 3-4 разработчика

**Что включить:**
- ✅ Фаза 0: Критическое исправление
- ✅ Фаза 1: Стабилизация ядра
- ✅ Фаза 3: Exit Nodes (только SOCKS5)
- ⚠️ Фаза 2: Hidden Services (базовая версия)
- ❌ Фаза 4: TLD (отложить)

### Сценарий 2: Полная Реализация
**Цель:** Соответствие всей документации  
**Срок:** 18-26 месяцев  
**Команда:** 4-5 разработчиков

**Что включить:**
- ✅ Все фазы

### Сценарий 3: Фокус на Безопасности
**Цель:** Создать надежную анонимную сеть  
**Срок:** 12-15 месяцев  
**Команда:** 3-4 разработчика

**Что включить:**
- ✅ Фаза 0: Критическое
- ✅ Фаза 1: Ядро
- ✅ Фаза 2: Hidden Services
- ✅ Фаза 3: Exit Nodes
- ⚠️ Фаза 4: TLD (упрощенная версия)
- ✅ Усиленное тестирование безопасности

---

## 📝 Заключение

Приведение Phantom Protocol 2025 в полное соответствие с документацией — это **амбициозный проект**, требующий значительных ресурсов и времени. Однако проект имеет **прочный фундамент** в виде портированного ядра и качественной архитектуры.

**Ключевые выводы:**

1. **Критическое исправление** (Фаза 0) должно быть выполнено **немедленно** из-за угрозы безопасности.

2. **Реалистичная оценка:** Полная реализация потребует **18-26 месяцев** работы команды из 4-5 разработчиков.

3. **Приоритизация:** Рекомендуется начать с MVP-подхода, фокусируясь на критических функциях (Hidden Services, Exit Nodes).

4. **Документация:** Необходимо **немедленно обновить** документацию, чтобы она отражала текущее состояние, а не желаемое будущее.

5. **Прозрачность:** Публикация roadmap с четкими датами и статусами поможет управлять ожиданиями пользователей.

---

**Автор:** Manus AI  
**Контакт:** https://help.manus.im  
**Лицензия:** MIT