Документировать API и сервис агента-кодера

AGENTS.md

@@ -8,6 +8,11 @@
 ## Примечание
 - Если внешний инструмент/интеграция требует английский формат, допускается английский, но рядом желательно дать краткое пояснение на русском.
 
+## Сервис агента-кодера
+- В проекте есть локальный Telegram-бот-сервис агента-кодера в папке `SHiNE-agent-bot-coder/`.
+- Сервис принимает сообщения из Telegram, ведёт историю диалога, ставит задачи в очередь и вызывает Codex CLI для обработки запросов по проекту.
+- Подробные правила работы сервиса, его очередь, история, systemd-запуск и особенности ответов описывать в `SHiNE-agent-bot-coder/AGENT.md`.
+
 ## Документация блокчейна
 - Актуальная документация по форматам блокчейна находится в `Dev_Docs/Blockchain/README.md`.
 - Это точка входа (оглавление), рядом расположены детальные файлы по форматам, типам каналов и командным сообщениям.
@@ -24,6 +29,13 @@
 - Логика личных сообщений в коде должна всегда соответствовать `Dev_Docs/Personal_Messages/README.md`.
 - Документ по личным сообщениям обязан поддерживаться в актуальном состоянии.
 
+## Документация API сервера
+- Актуальная документация по публичному JSON/WebSocket API сервера находится в `Dev_Docs/API/`.
+- При любом изменении серверного API/эндпоинтов/операций `op` обязательно обновлять соответствующие документы в `Dev_Docs/API/`.
+- Перед изменением самого серверного API обязательно явно предупредить пользователя, какие операции, поля запросов/ответов или коды ошибок будут изменены, и запросить отдельное подтверждение.
+- Без явного подтверждения пользователя формат серверного API не менять; допускается только приведение документации в соответствие уже существующему коду.
+- Если добавляется новая операция `op`, нужно обновить общий список операций в `Dev_Docs/API/09_Operations_Index.md` или создать его, если файла ещё нет.
+
 ## Известная проблема (временная пометка)
 - Мнения по связям пользователя (`known_person`, `shine_confirmed`, `shine_seen`) в UI могут отображаться нестабильно.
 - Требуется отдельная доработка и финальная проверка end-to-end: запись мнения в блокчейн → обновление `connections_state` → ответ `GetUserConnectionsGraph` → отображение в UI.
@@ -77,10 +89,6 @@
 - После подтверждения, что фича проверена и работает корректно, соответствующий файл удалять.
 - В `Dev_Docs/Pending_Features/README.md` вести краткий регламент и поддерживать актуальность.
 
-## Коммуникация в начале нового чата
-- В начале каждого нового чата (в первом ответе пользователю) дополнительно сообщать, сколько сейчас недопроверенных фич лежит в `Dev_Docs/Pending_Features/` (без учёта `README.md`).
-- В том же первом ответе обязательно уточнять у пользователя, проверил ли он эти фичи и можно ли пометить их как завершённые (удалить соответствующие файлы).
-
 ## Коммуникация по новым задачам (обязательно)
 - При получении нового задания сначала кратко пересказать задачу своими словами.
 - До начала реализации задать недостающие уточняющие вопросы (если они есть).