Подход · переезд

Переезд в новую сессию

Агент не помнит прошлый чат и не должен: память проекта лежит в репозитории. Переезд — это переход, у которого есть вход, выход и проверка на выходе.

Проблема. Каждый ход оплачивает входной контекст целиком. Долгая сессия дорожает быстрее, чем приносит пользу, а нужное — правило, решение, долг — тонет в переписке.

Решение. Состояние хранится в файлах: правила, доска долгов, письма шины, решения. Переезд идёт по протоколу: снимок, текст готовности, новый чат, старт по шагам.

Выгода. Новый чат начинается с короткого контекста и продолжает с того же места: ничего не пересказываем и не восстанавливаем по памяти.

01Состояние

Что остаётся после закрытия чата

После ротации остаётся только то, что лежит в репозитории. Поэтому состояние собирают заранее, а не восстанавливают потом:

  • правила — AGENTS.md: короткий список того, как работать и что проверять;
  • доска долгов — DEBTS.md: открытые строки с тегами, приоритетами и условием закрытия;
  • письма шины — задачи и отчёты в mailbox/, а не в чате;
  • решения — почему сделано так, а не иначе, с датой и проверкой.

У каждого файла есть история в git: снимок можно сравнить, откатить и проверить. У чата такого нет.

02Протокол старта

Первые шаги новой сессии

  1. 01
    Почта

    Проверка ящика без модели: EMPTY — к задаче, PENDING — прочитать, ответить, перенести в обработанные.

  2. 02
    Дешёвые проверки

    Скрипты сайта, доски и карты правил: один код возврата. Красный — не «готово», а работа.

  3. 03
    Доска и состояние

    Пересчитать долги, прочитать правила и хвост журнала, ответить одним экраном: почта, доска, следующий шаг.

  4. 04
    Задача

    Работа начинается с закрытия долга, а не с чтения истории: что открыто — то и делается.

03Алгоритм

Восемь шагов переезда

Схема одна и та же для любого бота: меняется только содержимое снимка.

Переезд: чат, ротация, снимок, текст готовности, новый чат, протокол старта, своё расписание, гейты Верхний ряд — закрытие текущей сессии: чат, ротация, снимок состояния, текст готовности. Нижний ряд — новая сессия: новый чат, протокол старта, своё расписание на четыре часа, гейты. чат рабочая сессия ротация решение закрыть снимок состояние в файлах готовность текст для новой переезд новый чат чистый контекст протокол старт по шагам расписание #2 4 часа, свой id гейты pre-receive → verify
Верхний ряд — закрытие сессии, нижний — старт новой; между ними снимок и текст готовности

Снимок делается до закрытия чата: пока сессия жива, видно, что именно недоделано. Текст готовности — короткая записка для следующего чата: где остановились, что проверено, что осталось. Дальше новый чат поднимает состояние по протоколу и продолжает с того же места.

04Расписание

Своё расписание у каждой сессии

Запись расписания живёт внутри сессии и хранит её идентификатор. На 26.10 на узле четыре активные записи с заголовками вида #2 …, у каждой свой sessionId. В чужой сессии запись не создаётся: это не ограничение интерфейса, а свойство модели.

Практический вывод: при переезде расписание переключает владелец. Старое останавливается, новое поднимается в новой сессии — вручную и явно. Мы пишем это на странице, потому что «само переедет» здесь было бы неправдой.

05Гейты

Что не пускает в прод

Новая сессия получает состояние, но не право считать его верным. На приёме стоит гейт pre-receive: он пропускает только зелёный результат verify.py. Красный — изменение остаётся у автора, а не на сервере.

Это тот же принцип, что и у ротации: доверять можно проверке, а не памяти о том, что «в прошлый раз работало».

Ротация контекста Архитектура