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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уровень эскалации:

• если пользователь игнорирует актуальный аларм или стопер в течение суток, вопрос следует эскалировать в рабочий чат `3839707989`;
• в рабочем чате нужно кратко описать стопер и попросить `@itolstov` помочь;
• эскалация должна содержать только необходимый минимум: что заблокировано, какое решение нужно, почему нельзя безопасно ждать дальше;
• приватные данные, секреты, токены, пароли, приватные ключи и чувствительные raw-материалы в рабочий чат не отправляются;
• если стопер касается финансового, Stellar, Bybit, юридического, публичного или 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. Минимальная проверка перед сообщением в чат

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

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

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

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

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

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

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

• Program:Synapolis Development
• Синаполис/Проактивная обработка сигналов
• Synapolis:SignalStream v0.2/Onboarding