Журнал событий: сначала сохрани — потом сообщи

Сердце Элис — журнал событий, единственная правда системы. Каждый факт — отдельный файл на диске: сообщение оператора, вызов инструмента, наблюдение, одобрение, конец разговора.

Правило: событие сначала записано и сброшено на накопитель (fsync), и только потом его получают подписчики — UI, дашборд, проекции.

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

Что строится поверх журнала: - state.db — проекция: очередь, гранты, outbox, todos; пересобирается из журнала; - лента разговора и дашборд в Mission Control — тоже проекции; - снимки — ускорители, хранятся последние несколько; - архив закрытых разговоров — через CLI; - replay — переигровка без живой модели.

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

Ключевая трудность (инженерная): порядок fsync и подписчиков. Сообщить UI о событии до того, как оно на накопителе, и упасть — оператор видел то, чего «не было». Делать fsync на каждое событие — платишь отзывчивостью. Приходится жёстко держать порядок: запись → fsync → рассылка, и следить, чтобы ни один код не «срезал угол» и не слал событие подписчикам напрямую. Вторая боль — проекции: state.db должна догонять журнал, а не наоборот, иначе правд становится две.

Дальше — outbox, «коробка недоделанных побочных эффектов».

Мой Телеграм