Этот документ описывает повседневную работу с уже внедрённым Memory Bank. Для первого запуска начните с быстрого старта, а для установки и адаптации используйте инструкцию по внедрению.
Документ остаётся во внешней документации шаблона и не копируется в
проект-получатель. Канонические правила конкретного проекта находятся в его
memory-bank/README.md и memory-bank/flows/.
Без долговременной памяти задача часто проходит напрямую от запроса к коду. Обоснование решения остаётся внутри одной сессии, а следующему агенту приходится восстанавливать требования, ограничения и историю проекта заново.
Memory Bank добавляет управляемый цикл:
- агент начинает с подтверждённых знаний о продукте, предметной области, инженерии и эксплуатации;
- задача проходит через подходящий процесс, а не сразу превращается в код;
- проблема, решение, порядок реализации и проверки разделяются между своими документами;
- причины архитектурных решений сохраняются в дизайн-пакетах и ADR — записях архитектурных решений;
- после реализации новые устойчивые знания возвращаются к своим каноническим владельцам.
В результате проект накапливает не только код, но и историю решённых проблем, принятых решений и подтверждённых способов проверки.
Задача
↓
Минимальные факты для маршрутизации
↓
Маршрутизация в подходящий процесс
↓
Связанные требования, сценарии, фичи и решения
↓
Бриф → дизайн-пакет → план реализации
↓
Код → проверки → запрос на слияние
↓
Новые решения, ограничения и подтверждения
возвращаются в Memory Bank
Задача в трекере или прямое поручение должны задавать наблюдаемый результат, границы и способ проверки. Ссылка на исходную задачу остаётся точкой входа для человека и агента.
Не нужно заранее решать, какие документы создавать. Это определяет маршрутизация.
До выбора процесса агент собирает только факты, необходимые для маршрутизации:
- ожидаемый результат и известное поведение;
- наличие действующего дефекта или эксплуатационного воздействия;
- границы одной задачи или признаки крупной инициативы;
- необходимость исследования до решения о реализации.
На этом этапе не нужно загружать всю базу знаний или проектировать решение. Агент начинает с задачи и основных индексов и останавливает предварительный поиск, как только может обосновать маршрут.
Каждая задача начинается с Task Routing. Маршрутизатор выбирает наименьший
процесс, который сохраняет контроль над риском: инцидент, исправление дефекта,
исследование, небольшое изменение, крупную инициативу, рефакторинг или
функциональное изменение.
Два наиболее частых случая:
- Small Change — исходная задача уже содержит намерение, границы и критерии приёмки, а решение следует известному образцу. Отдельный Feature Pack не создаётся.
- Feature Flow — задача представляет одну проверяемую единицу поставки и требует последовательного перехода от проблемы к решению и реализации.
Если в ходе работы исходный маршрут перестал соответствовать задаче, агент останавливается и выполняет маршрутизацию повторно.
После выбора процесса агент читает предусмотренные им источники и находит применимые канонические знания:
- продуктовые цели и требования;
- термины и правила предметной области;
- существующие сценарии использования;
- предыдущие комплекты документов фич;
- архитектурные решения;
- инженерные и эксплуатационные ограничения.
Не загружайте всю базу знаний в каждую сессию. Агент начинает с индексов и переходит только по связям, относящимся к задаче. История прошлых решений нужна, чтобы новое изменение не отменило незаметно уже реализованное требование или ограничение.
Для значимой фичи процесс создаёт Feature Pack — долговременный комплект документов изменения:
Feature Flow рассматривает такую фичу как проверяемый вертикальный срез и следует разработке на основе спецификации: предусмотренные выбранным маршрутом документы создаются и проверяются до начала реализации.
brief.md design.md implementation-plan.md
что и зачем → выбранное решение → реализация и проверки
пространство задачи пространство решения пространство исполнения
brief.mdфиксирует проблему, результат, границы, требования и критерии проверки;- дизайн-пакет фиксирует выбранное решение, аргументы, альтернативы, контракты и значимые риски;
implementation-plan.mdсвязывает решение с конкретными шагами, контрольными точками и проверками.
Шаблоны этих документов — инструменты мышления. Они заставляют агента отделить факты от допущений, назвать ограничения, сравнить варианты и сохранить прослеживаемость. В основе такого проектирования лежит FPF — метод мышления от первых принципов.
Агент работает в отдельной ветке или директории worktree, читает только применимые документы и изменяет код согласно принятому решению. Код владеет реализацией, а Memory Bank — намерением, требованиями, обоснованием и контрактами.
Инструмент запуска создаёт рабочее окружение и сессию агента. Это может быть
ручной запуск Codex, start-issue или
Symphony. Memory Bank задаёт знания и процесс,
которым следует запущенный агент.
После выбора процесса определяется один профиль проверки. Он задаёт минимальную глубину тестов, проверок непрерывной интеграции, подтверждений, согласований и действий при выпуске.
| Профиль | Когда применяется |
|---|---|
documentation |
Изменяются только документы и другие неисполняемые материалы |
low-risk |
Локальное изменение по известному образцу без значимых рисков |
standard |
Обычное исполняемое изменение |
high-risk |
Изменение непосредственно затрагивает рабочие данные, доступ или необратимую внешнюю операцию |
release-deployment |
Изменяются выпуск, развёртывание или откат |
Процесс определяет этапы работы, а профиль — глубину проверки. Это разные решения. Полные правила и минимальные контракты принадлежат каноническому документу по ссылке выше.
Работа не заканчивается успешным тестом или запросом на слияние. Перед завершением агент проверяет, появились ли:
- новое устойчивое правило продукта или предметной области;
- архитектурное решение и его обоснование;
- новый сценарий или ограничение;
- эксплуатационная процедура;
- подтверждение, которое понадобится при будущей проверке.
Каждый такой факт обновляется у единственного канонического владельца. Производные документы ссылаются на него и не создают конкурирующих копий. Feature Pack остаётся историей конкретного изменения и помогает следующим задачам учитывать уже решённые проблемы.
Новая сессия начинает с исходной задачи, memory-bank/README.md, результата
маршрутизации и существующих документов изменения. Ей не требуется полный чат
предыдущего агента: существенный контекст уже находится в репозитории.
- Агент подтверждает маршрут
Small Change. - Исходная задача остаётся владельцем намерения, границ и приёмки.
- Агент реализует локальное изменение, выполняет проверки и открывает запрос на слияние.
- Если обнаружено новое устойчивое решение, задача проходит маршрутизацию повторно.
Feature FlowсоздаётREADME.mdиbrief.mdкомплекта фичи.- После готовности проблемы формируется дизайн-пакет.
- Принятое решение превращается в
implementation-plan.md. - Агент реализует план и собирает предусмотренные подтверждения.
- После слияния Feature Pack сохраняет историю изменения.
Если решение действует шире одной фичи или должно жить дольше её комплекта, оно фиксируется в ADR. Запись сохраняет контекст, выбранный вариант, причины и значимые отклонённые альтернативы. При изменении обстоятельств команда может пересмотреть решение, не восстанавливая аргументацию из старых чатов.
Запустите Codex в корне проекта и передайте задачу вместе с точками входа Memory Bank:
codex -C . \
'Прочитай задачу, ./memory-bank/README.md и ./memory-bank/flows/routing.md.
Выбери подходящий процесс и следуй его каноническому жизненному циклу.
В финале сообщи маршрут, изменённые документы, проверки и открытые риски.'Подробный первый запуск с примером задачи находится в быстром старте.
start-issue может подготовить ветку и директорию worktree и запустить агента
для выбранной задачи. Интеграция с Symphony в этом репозитории выбирает задачи
GitHub по метке, запускает Codex в изолированной рабочей директории и передаёт
готовый запрос на слияние человеку. Подробности и ограничения описаны в
инструкции по Symphony.
Периодически поручайте агенту проверить целостность Memory Bank:
Проведи ревью ./memory-bank на соблюдение принципа единственного источника
истины, противоречия, неработающие ссылки, документы без входящих ссылок,
недостающие README-индексы и неясные зависимости. Предложи минимальные правки
и выполни локальные проверки.