01 Why This Exists

01 · Зачем это нужно

Проблема

Аккаунт REG.RU — это 116 документированных команд API v2 с разными форматами ошибок, ограничениями по типам услуг и лимитом 1200 запросов в час. Типичные способы работы с ними:

• личный кабинет — по одной операции за раз, без истории и автоматизации;
• самописные скрипты — решают одну задачу и ломаются на первой бизнес-ошибке, потому что транспортные и бизнес-ошибки не различаются;
• обёртки над отдельными командами — не дают общей картины: домены, DNS, хостинги и баланс живут в разных местах.

Для AI-агента ситуация хуже: у него нет ни браузерной сессии, ни стабильного контракта, а пароли хостингов вообще не должны попадать в контекст модели.

Решение

REG.RU Control собирает работу с аккаунтом в одну панель и один API:

1. Инвентарь — домены, хостинги, VPS, серверы, лицензии, баланс в одной базе.
2. Действия — продление, автопродление, NS, DNS-записи, DNSSEC, сертификат.
3. Секреты — шифрованное хранилище с отдельным правом на раскрытие и аудитом.
4. API и MCP — те же функции доступны человеку, интеграции и агенту.

Принципы

Принцип	Следствие
Один процесс без зависимостей	установка — git clone, .env, migrate; нет Composer/Node/внешней СУБД
Бэкенд самодостаточен	интерфейс — лишь один из клиентов; каждая функция есть в HTTP API
Секреты закрыты по умолчанию	пароли шифруются, списки их не содержат, раскрытие — право secrets:read и запись в журнал
Ошибки не проглатываются	транспортные повторяются ограниченно, бизнес-ошибки возвращаются с кодом
Честные ограничения	если REG.RU не отдал пароль или зона не на его NS — панель пишет это прямо, а не имитирует успех

Что это не решает

• Не заменяет личный кабинет REG.RU для партнёрских/финансовых операций, недоступных типу аккаунта.
• Не управляет зонами, делегированными не на ns1.reg.ru/ns2.reg.ru.
• Не является SaaS: данные и ключи остаются на вашем сервере.
• Не рассчитана на несколько экземпляров с общей SQLite.

Дальше: Установка · Архитектура