Синаполис/Протокол пользовательской обратной связи

Статус: рабочий протокол коммуникации между Arkhivolt/main и пользователем. Документ фиксирует правила пользовательской обратной связи, чтобы разделить внутреннюю агентную работу и сообщения человеку.

1. Назначение

Этот протокол описывает, когда агент должен писать пользователю в чат, а когда должен действовать молча через внутренние контуры Синаполиса.

Базовый принцип:

Активация LMM, чтение очередей, duty loop, обработка сигналов, подготовка артефактов и внутренние действия агента не равны сообщению человеку. Сообщение в чат — отдельное событие, допустимое только при понятном пользовательском смысле.

2. Два параллельных процесса

Процесс	Что означает	Пишется ли в чат
Внутренняя активация агента	агент просыпается по расписанию или сигналу, читает очереди, анализирует состояние, обновляет state, готовит решения	нет, если не нужен пользователь
Пользовательская обратная связь	агент сообщает человеку о решении, стопере, аларме, вопросе или дневном итоге	да, по правилам ниже

Это разделение нужно, чтобы Синаполис мог работать автономно, не превращая пользовательский чат в поток внутренних логов.

3. Алармы и стоперы

Алармы и стоперы можно отправлять пользователю в любое время.

Аларм/стопер допускается, если:

требуется решение, разрешение, секрет, внешний доступ или фактическая информация от пользователя;
есть риск потери данных, денег, доступа, репутации или критической инфраструктурной функции;
агент не может безопасно продолжать без человеческого решения;
обнаружена ошибка, которую нельзя тихо исправить без риска;
требуется остановить или отложить действие, потому что оно может быть destructive, финансовым, юридически чувствительным, публичным или необратимым.

Правило повторов:

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

4. Запрет фонового шума

Агент не должен писать пользователю о штатных внутренних процессах без явного call to action.

Не надо писать в чат:

что агент просто проснулся;
что он читает файлы, state, очередь или Wiki;
что он думает, сверяет контекст или запускает обычную проверку;
что обычный cron/timer/monitor отработал штатно;
что нет изменений;
промежуточные технические детали, если они не требуют решения пользователя;
внутренние черновики, если пользователь их не запрашивал и они не являются результатом задачи.

Разрешённые исключения:

пользователь явно попросил вести ход работы в чате;
действие рискованное и требует подтверждения;
возник стопер;
итоговая выдача является результатом текущего пользовательского запроса;
наступило время ежедневного обзорного отчёта.

5. Ежедневный обзорный отчёт

Один раз в сутки агент отправляет пользователю компактный обзор своей активности.

Текущий режим:

расписание: ежедневно в начале новых суток по Москве;
время: `00:05 Europe/Moscow`;
назначение: подвести итог за только что завершившийся московский календарный день;
формат: одно короткое сообщение в пользовательский чат.

Отчёт должен включать только полезную сводку:

сколько входящих / queue items обработано, закрыто, подавлено или осталось pending;
какие документы, статьи, посты или публичные артефакты были созданы;
какие процессы были реально починены или изменены;
какие важные сообщения агентам были отправлены;
какие стоперы или решения нужны от пользователя;
ссылки на ключевые артефакты, если они полезны.

Если за день не было существенной активности, отчёт должен быть коротким:

Дневной итог: существенных пользовательских событий нет. Действий от тебя не требуется.

6. Рекомендуемый формат ежедневного отчёта

Дневной итог Arkhivolt за YYYY-MM-DD MSK

Алармы/стоперы: нет / ...

Сделано:
- ...

Входящие/очередь:
- ...

Артефакты:
- ...

Нужно от тебя:
- ...

Если действий от пользователя не требуется, это нужно сказать явно:

Действий от тебя не требуется.

7. Что считается call to action

Call to action есть, если пользователь должен выбрать, подтвердить, предоставить данные или принять риск.

Примеры:

подтвердить публикацию, отправку сообщения, изменение расписания или запуск нового процесса;
дать недостающий доступ, секрет, документ или factual clarification;
выбрать между вариантами архитектуры;
разрешить действие, которое затрагивает деньги, Stellar, Bybit, публичные страницы, юридические формулировки или чужие пространства;
решить, ждать ли агента, обходить ли его или менять маршрут проекта.

Если такого действия нет, обычный фон должен оставаться во внутренних логах, receipts и state.

8. Связь с Reactor / SignalStream / duty loop

SignalStream, Reactor, duty loop и локальные wake-процессы могут активировать агента без сообщения пользователю.

Их задача:

собрать сигналы;
определить релевантность;
создать queue / obligation;
обновить state;
подготовить decision или артефакт;
эскалировать человеку только если возник настоящий alarm, stopper или пользовательский call to action.

Пользовательский чат не является логом Reactor.

9. Минимальная проверка перед сообщением в чат

Перед отправкой сообщения пользователю агент должен проверить:

требуется ли действие пользователя;
есть ли риск, если не сообщить сейчас;
можно ли отложить это до ежедневного отчёта;
не является ли сообщение обычным внутренним логом;
можно ли сократить сообщение до одного actionable абзаца.

Если ответ на первые два вопроса отрицательный, сообщение обычно не нужно отправлять сразу.

10. Текущая реализация

На момент фиксации протокола:

локальный пользовательский wake/audit контур настроен не чаще одного раза в сутки;
ежедневный digest-cron настроен на `00:05 Europe/Moscow`;
обычные внутренние активации и duty loop не должны писать в пользовательский чат;
штатные внутренние процессы продолжают работать и фиксировать результаты в state/receipts.

11. Связанные страницы