Почему я разделил память и выполнение

В какой-то момент количество информации, с которой я работаю, стало слишком большим.

Проекты, технические решения, задачи, схемы, заметки, промежуточные выводы.

Пока проект активен, кажется, что вся его логика находится в голове. Но стоит переключиться на другую работу и вернуться через несколько недель, часть контекста приходится восстанавливать заново.

Мне нужна была система, которая хранит не просто заметки, а состояние проекта.

Одним из первых подходов был 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.

#ObsidianMCP@annsFlow

Оглавление темы 📌

Навигация по проектам канала 📍

Все проекты 🎶

💻 annFlow