Outbox: коробка недоделанных побочных эффектов
Агент решил отправить задачу другой группе или записать файл, и тут процесс упал. Сделалось действие или нет? В Элис на это отвечает outbox — «коробка недоделанных побочных эффектов».
Как это устроено и почему идемпотентность здесь важнее скорости.
Идея. Действие, которое меняет мир, сначала кладёт в state.db запись «надо сделать». Потом выполняется. Потом запись закрывается. После рестарта система первым делом разбирает pending: доделывает или честно закрывает.
Что даёт: • не теряются действия, которые агент «обещал» сделать; • действия не выполняются дважды вслепую; • видно, на каком шаге оборвалось.
Связь с журналом. Outbox живёт в state.db, а state.db — проекция журнала. Поэтому намерение и результат видны и в аудите, и при replay.
Связь со стартом задачи. Восстановление outbox — обязательный шаг запуска, до того как группа возьмёт новую работу. Нельзя начинать новое, не разобравшись с хвостами старого.
Ключевая трудность (инженерная): не все действия идемпотентны. Записать файл тем же содержимым можно ещё раз. Передать задачу на другой хост или отправить что-то наружу — нет: повтор создаёт дубль. У каждого типа эффекта должна быть своя стратегия: повторить, сверить с внешней стороной по ключу или закрыть как невыполненное и сказать об этом. Универсального «retry» тут нет, и честнее закрыть pending с причиной, чем молча задвоить.
Дальше — как стартует задача: от команды до первого вызова модели.
