Почему я разделил память и выполнение
В какой-то момент количество информации, с которой я работаю, стало слишком большим.
Проекты, технические решения, задачи, схемы, заметки, промежуточные выводы.
Пока проект активен, кажется, что вся его логика находится в голове. Но стоит переключиться на другую работу и вернуться через несколько недель, часть контекста приходится восстанавливать заново.
Мне нужна была система, которая хранит не просто заметки, а состояние проекта.
Одним из первых подходов был Apple Freeform. Мне сразу подошла сама идея Canvas: раскладывать информацию пространственно, видеть связи и собирать проект не только линейным текстом.
Но довольно быстро стало понятно, что одного холста недостаточно.
Мне нужны были обычные файлы, Markdown, понятная структура каталогов, Canvas, API и возможность строить поверх всего этого собственные правила.
Так основной памятью стал Obsidian.
Но почти сразу появилась другая проблема.
В Obsidian удобно хранить архитектуру проекта, технические решения, документацию, причины изменений, планы и историю.
Но ежедневное выполнение задач удобнее держать отдельно.
Для этого у меня остался Todoist.
Сначала естественной казалась идея максимально связать две системы между собой: изменения в Obsidian отражаются в Todoist, изменения в Todoist возвращаются обратно.
На практике такая симметрия быстро создаёт новые проблемы.
Кто главный, если данные расходятся?
Что считать актуальным состоянием проекта?
Нужно ли изменение задачи переписывать обратно в документацию?
В итоге я пришёл к более простой архитектуре.
Obsidian хранит память.
Todoist управляет выполнением.
Подробное состояние проекта живёт в файлах. Например, текущий план находится в implementation_plan.md, а история важных решений сохраняется в decisions_log.md.
Todoist не пытается стать второй копией этой памяти. Он показывает то, что нужно сделать сейчас.
Из этого постепенно появилось одно из главных правил всей моей системы.
Один факт = один владелец.
Если это проектное решение, оно принадлежит проектной памяти.
Если это действие, которое нужно выполнить, оно принадлежит execution-слою.
Связь между ними остаётся, но они больше не пытаются быть зеркалами друг друга.
И здесь появился следующий вопрос.
Если реальная память проекта находится в Obsidian, как дать языковой модели доступ именно к ней, а не каждый раз вручную переносить документы в диалог?
Первым рабочим ответом на этот вопрос стал мой Obsidian MCP-сервер.
В следующем посте разберу, как через него LLM получила доступ к моему Obsidian.