2026-06-29 | Правки reverse-proxy конфигов (Caddy/Nginx) — только patch/diff + проверка всех хостов снаружи
Решение: Любые изменения /etc/caddy/Caddyfile (и аналогичных конфигов reverse-proxy) выполнять только точечно через patch/diff, никогда не перезаписывать файл целиком; после правки — caddy validate + мягкий systemctl reload caddy и проверка снаружи всех хостов, а не только изменённого.
Почему: Агентская правка OpenClaw при настройке MemOS (24–25.06) перезаписала Caddyfile целиком и удалила блок assistai.unf86.org — веб-консоль OpenClaw стала недоступна на ~5 дней, инцидент вскрылся только при попытке пользователя войти. Точечная правка и проверка всех хостов исключили бы регрессию.
Последствие: Зафиксировать правило в AGENTS.md OpenClaw; при будущих правках Caddy/Nginx — обязательный diff-before/after и live-проверка каждого хоста. Аналог жёсткого цикла edit → restart → live check для сервисных правок Dash.
2026-06-28 | Детектор аномалий балансов LLM-провайдеров как страховка против race condition
Решение: В llm_provider_balances.py внедрить state-базлайн (llm_provider_balances_state.json) + детектор аномалий (баланс ≤ 0, статус не active, ошибка запроса, падение 50%+ за день) + retry 3×8с + сигнализацию ⚠️ в карточке и сводкой в начале отчёта.
Почему: Claudexia (SPA через browser-ak) отдавала нули из-за race condition — SPA не успевал отрисовать баланс за фиксированные 4с. Фиксированная задержка ненадёжна для SPA; страховка через детектор аномалий надёжнее и покрывает все провайдеры, а не только Claudexia.
Последствие: Утренние отчёты получают защиту от ложных нулей и резких падений; аномалии подсвечиваются явно с цифрами и причинами. Завтра 06:01 — первый отчёт с чистым state (без базлайна → без аномалий); полное сравнение — со следующего дня. Порог 50% требует калибровки на реальных данных.
2026-06-23 | Сервисные правки Dash закрывать только полным циклом edit → restart → live check
Решение: Любые изменения Hermes Dash, влияющие на backend/service behaviour или UI в проде, считать незавершёнными без немедленного рестарта сервиса и проверки живого URL.
Почему: В пользовательской сессии код был исправлен раньше фактического применения, из-за чего UI некоторое время показывал устаревшее состояние и создал лишнюю итерацию.
Последствие: Для Dash недостаточно «поправить файл»; done = код применён, сервис перезапущен, live-результат подтверждён.
2026-06-23 | Перезапуск сервисов не делать без явного разрешения
Решение: Если systemd/service-level вмешательство не было явно разрешено пользователем, не дожимать restart по умолчанию даже когда это технически логичный следующий шаг.
Почему: В сессии по аудиту Dash перезапуск уткнулся в блокировку согласия; это не техническая, а операционная граница.
Последствие: В похожих задачах заранее отделять code cleanup от действий с side effects и либо получать разрешение раньше, либо явно планировать stop-point.
2026-06-22 | Hermes Dash audit: first fix security and render architecture
Решение: В доработке Hermes Dash сначала закрывать XSS/небезопасный innerHTML, затем разделять polling по частоте данных и убирать полную перерисовку всех вкладок.
Почему: Аудит показал прямую инъекционную поверхность, лишнюю нагрузку от 20 запросов каждые 30 секунд и неэффективный общий render всех секций.
Последствие: Следующие изменения по дашборду нельзя сводить только к косметике; приоритет — security, data refresh strategy и архитектура рендера.
2026-06-22 | Daily Vault journal всегда фиксирует служебные кроны и реальные пользовательские сессии дня
Решение: В daily за день фиксировать не только отсутствие активности, но и реальные пользовательские сессии с 1–3 checkpoint-блоками плюс служебную отметку о выполненных cron/system checks.
Почему: Иначе журнал теряет хронологию дня и не отражает фактические рабочие изменения, которые уже влияют на контекст.
Последствие: working-context и daily должны синхронно показывать состояние дня, даже если часть активности была смешана с системными проверками.
2026-06-01 | OpenClaw Telegram: полный restart не делали без явного подтверждения
Решение: Не выполнять полный systemctl restart openclaw-gateway, пока не получено явное подтверждение на вмешательство.
Почему: Gateway был жив, а проблема локализовалась в Telegram-канале; полный restart мог создать лишний риск и шум.
Последствие: Нужен точечный recovery именно Telegram-канала или отдельное подтверждение на restart всего gateway.
2026-05-31 | Ежедневный vault-контур без пользовательской активности
Решение: В daily журналах тихие дни фиксировать служебной записью даже без пользовательских сессий.
Почему: Пустой daily не отражает факт работы кронов и синхронизации контекста.
Последствие: Daily/working-context должны обновляться и в дни без пользовательской активности.
Решение: В реестре счетов проекта Ижевск фиксировать ООО «Ромис-технология» как покупателя/заказчика, а в колонке поставщика указывать только фактическое юрлицо-поставщика.
Почему: Нельзя подменять поставщика контактным лицом или стороной переписки; иначе ломается учет счетов и статусов.
Последствие: Новые строки в реестре счетов нужно заполнять по документу, а не по пересланному письму.
2026-05-25 | Telegram API: topics-aware routing
Решение: Для Telegram-контуров Hermes использовать ключ маршрутизации chat_id + message_thread_id; для private chat topics учитывать direct_messages_topic_id.
Почему: Темы/threads в Bot API относятся не только к forum topics в supergroup, а контекст нельзя смешивать в одну общую ленту.
Последствие: В будущих Telegram-интеграциях нужно разделять контекст по теме, а не только по чату.