diff --git a/README.md b/README.md
index 4c98b65..f420c88 100644
--- a/README.md
+++ b/README.md
@@ -2,7 +2,7 @@
 
 **A version-controlled development system that gives coding agents durable knowledge, explicit governance, and repeatable delivery flows.**
 
-[Русская версия](README.ru.md) · [Adoption guide](docs/adoption.md) · [Daily usage](docs/usage.md)
+[Русская версия](README.ru.md) · [Quick start (Russian)](docs/quick-start.md) · [Adoption guide](docs/adoption.md) · [Daily usage](docs/usage.md)
 
 **`AGENTS.md` can tell an agent how to start. Memory Bank preserves what the project means, why decisions were made, how work moves from a problem to verified code, and what the next agent needs to know.**
 
@@ -154,6 +154,7 @@ After installation, `memory-bank/README.md` is the primary index inside the down
 
 ## Documentation
 
+- [Quick start (Russian)](docs/quick-start.md)
 - [Adopting Memory Bank](docs/adoption.md)
 - [Using Memory Bank day to day](docs/usage.md)
 - [Context priming for an agent task](docs/context-priming.md)
diff --git a/README.ru.md b/README.ru.md
index 0d586ae..2d01670 100644
--- a/README.ru.md
+++ b/README.ru.md
@@ -2,7 +2,7 @@
 
 **Версионируемая система, которая даёт агентам долговременные знания о проекте, явные правила и повторяемые процессы разработки.**
 
-[English version](README.md) · [Внедрение](docs/adoption.md) · [Повседневная работа](docs/usage.md)
+[English version](README.md) · [Быстрый старт](docs/quick-start.md) · [Внедрение](docs/adoption.md) · [Повседневная работа](docs/usage.md)
 
 **`AGENTS.md` объясняет агенту, как начать. Memory Bank сохраняет смысл проекта, причины принятых решений, путь от задачи до проверенного кода и знания, необходимые следующему агенту.**
 
@@ -187,6 +187,7 @@ Symphony запускает агентов и работу с репозитор
 
 | Документ | Для кого и зачем |
 | --- | --- |
+| [Быстрый старт](docs/quick-start.md) | Для установки Memory Bank и запуска первой реальной задачи через Codex |
 | [Внедрение Memory Bank](docs/adoption.md) | Для команд, подключающих шаблон к существующему или новому проекту |
 | [Протокол адаптации существующего проекта](docs/brownfield-adaptation-protocol.md) | Для основанной на фактах адаптации репозитория до и после установки Memory Bank |
 | [Протокол создания нового проекта](docs/greenfield-integration-protocol.md) | Для копирования шаблона, извлечения фактов из README и документации, адаптации Memory Bank и создания исходного описания продукта |
diff --git a/docs/adoption.md b/docs/adoption.md
index 100dfaa..a0b1e82 100644
--- a/docs/adoption.md
+++ b/docs/adoption.md
@@ -56,7 +56,11 @@ governance. Project-specific инструкции остаются в собст
 Не переноси project-specific детали обратно в generic-шаблон.
 ```
 
-После внедрения используйте [инструкцию по повседневной работе](usage.md): она описывает связь Memory Bank с task tracker и agent runner, рабочий цикл и стартовые запросы.
+После внедрения проведите первую задачу по
+[инструкции быстрого старта](quick-start.md), затем используйте
+[инструкцию по повседневной работе](usage.md): она описывает накопление
+проектных знаний, выбор процесса, реализацию и возврат новых решений в
+Memory Bank.
 
 ## Опциональная CLI-проверка
 
diff --git a/docs/assets/quick-start-feature-pack.gif b/docs/assets/quick-start-feature-pack.gif
new file mode 100644
index 0000000..71d90c2
Binary files /dev/null and b/docs/assets/quick-start-feature-pack.gif differ
diff --git a/docs/assets/quick-start-routing.gif b/docs/assets/quick-start-routing.gif
new file mode 100644
index 0000000..f5720e5
Binary files /dev/null and b/docs/assets/quick-start-routing.gif differ
diff --git a/docs/assets/quick-start-start-issue.gif b/docs/assets/quick-start-start-issue.gif
new file mode 100644
index 0000000..c65cb8c
Binary files /dev/null and b/docs/assets/quick-start-start-issue.gif differ
diff --git a/docs/quick-start.md b/docs/quick-start.md
new file mode 100644
index 0000000..b3d3d45
--- /dev/null
+++ b/docs/quick-start.md
@@ -0,0 +1,194 @@
+# Быстрый старт: первый запуск Memory Bank
+
+Этот документ помогает установить Memory Bank и провести первую реальную
+задачу через его процессы. На прохождение нужны Git, установленный и
+авторизованный [Codex CLI](https://developers.openai.com/codex/cli/) и
+репозиторий проекта.
+
+Если Memory Bank уже адаптирован, переходите сразу к разделу
+[«Выбрать сценарий запуска»](#3-выбрать-сценарий-запуска).
+
+## 1. Проверить Codex
+
+```bash
+codex --version
+codex login status
+```
+
+Если Codex не авторизован, выполните `codex login` и следуйте его инструкциям.
+
+## 2. Установить и адаптировать Memory Bank
+
+Перейдите в корень проекта. Для воспроизводимого запуска замените `main` в
+адресе протокола на идентификатор конкретного коммита.
+
+### Существующий проект
+
+```bash
+codex --search \
+  'Это существующий проект. Выполни https://github.com/dapi/memory-bank/blob/main/docs/brownfield-adaptation-protocol.md.'
+```
+
+### Новый проект
+
+```bash
+codex --search \
+  'Это новый проект. Выполни https://github.com/dapi/memory-bank/blob/main/docs/greenfield-integration-protocol.md.'
+```
+
+Агент изучит проект, установит содержимое шаблона и адаптирует постоянный
+контекст. Полный порядок и критерии готовности описаны в
+[инструкции по внедрению](adoption.md).
+
+Перед продолжением просмотрите изменения:
+
+```bash
+git status --short
+git diff --check
+```
+
+Если установлена необязательная утилита `memory-bank-cli`, дополнительно
+выполните:
+
+```bash
+memory-bank-cli lint
+memory-bank-cli doctor
+```
+
+## 3. Выбрать сценарий запуска
+
+Используйте один из трёх сценариев. GIF показывают сокращённый ввод в терминале,
+а команды под ними можно копировать. Ответы агента будут зависеть от задачи и
+текущего состояния проекта.
+
+### Вариант 1. Доверить выбор процесса Memory Bank
+
+![Запуск задачи через маршрутизацию Memory Bank](assets/quick-start-routing.gif)
+
+Это основной сценарий. Memory Bank сам определит подходящий процесс и создаст
+только необходимые документы.
+
+```bash
+codex -C . \
+  'Прочитай GitHub issue #123 и выполни его по процессу
+memory-bank/flows/routing.md.'
+```
+
+### Вариант 2. Явно создать Feature Pack
+
+![Создание и проверка Feature Pack перед реализацией](assets/quick-start-feature-pack.gif)
+
+Используйте этот сценарий, когда уже принято решение провести задачу через
+`Feature Flow`.
+
+```bash
+codex -C .
+```
+
+В открывшейся сессии сначала создайте Feature Pack:
+
+```text
+Прочитай GitHub issue #123 и создай по нему Feature Pack согласно процессу
+memory-bank/flows/feature.md.
+```
+
+После создания комплекта запросите ревью:
+
+```text
+Проведи ревью созданного комплекта документов и исправь замечания.
+```
+
+И только после ревью переходите к реализации:
+
+```text
+Приступай к реализации.
+```
+
+### Вариант 3. Автоматизировать запуск через start-issue
+
+![Автоматический запуск задачи через start-issue](assets/quick-start-start-issue.gif)
+
+[`start-issue`](https://github.com/dapi/start-issue) получает задачу GitHub,
+создаёт отдельную ветку и директорию worktree, а затем запускает настроенного
+агента.
+
+```bash
+start-issue 123
+```
+
+В этом варианте команда использует агента и запрос из пользовательской или
+проектной конфигурации `start-issue`.
+
+### Что должно произойти
+
+- Вариант 1 сначала выполняет `Task Routing`, а затем следует выбранному
+  процессу.
+- Вариант 2 создаёт Feature Pack, проводит его ревью и только после обязательных
+  этапов переходит к реализации.
+- Вариант 3 подготавливает изолированную рабочую директорию и передаёт задачу
+  настроенному агенту.
+
+Во всех вариантах агент должен выполнить проверки выбранного профиля и вернуть
+новые устойчивые знания к их каноническим владельцам.
+
+## 4. Посмотреть след задачи
+
+Во время или после работы проверьте, какие документы и файлы появились:
+
+```bash
+git status --short
+rg --files memory-bank/features
+git diff --check
+```
+
+Нормальный результат — не максимальное количество документов, а достаточный
+проверяемый след:
+
+- исходная задача и выбранный маршрут;
+- требования и критерии проверки;
+- обоснование решения, если оно требовалось;
+- изменения кода и тестов;
+- подтверждения выполненных проверок;
+- обновлённые долговременные знания проекта.
+
+## 5. Проверить продолжение в новой сессии
+
+Ценность Memory Bank особенно заметна при смене сессии. Завершите текущую
+сессию и запустите новую:
+
+```bash
+codex -C . \
+  'Продолжи текущую задачу. Начни с ./memory-bank/README.md,
+./memory-bank/flows/routing.md и существующего комплекта документов задачи.
+Не восстанавливай решение из предположений: используй канонические владельцы
+фактов и сообщи, на каком этапе находится работа.'
+```
+
+Новая сессия должна определить состояние задачи по файлам репозитория, а не по
+истории предыдущего чата.
+
+## Автоматический запуск через Symphony
+
+В этом репозитории есть экспериментальная интеграция Symphony с задачами
+GitHub. Она выбирает задачи с меткой `codex-ready`, запускает Codex в
+изолированной рабочей директории и после готового запроса на слияние переводит
+задачу на проверку человеком.
+
+Для локального запуска интеграции самого репозитория Memory Bank:
+
+```bash
+direnv allow
+./bootstrap-symphony.sh
+./run-symphony.sh
+```
+
+Не запускайте Symphony с широкими полномочиями или на всех открытых задачах без
+предварительной проверки окружения. Полные требования и ограничения находятся
+в [инструкции по Symphony](symphony-github-issues.md).
+
+## Что читать дальше
+
+- [Повседневная работа с Memory Bank](usage.md)
+- [Внедрение Memory Bank](adoption.md)
+- [Подготовка контекста задачи](context-priming.md)
+- [Глоссарий](glossary.md)
diff --git a/docs/usage.md b/docs/usage.md
index 44e37d2..51c2af2 100644
--- a/docs/usage.md
+++ b/docs/usage.md
@@ -1,116 +1,242 @@
 # Использование Memory Bank
 
-Этот документ описывает повседневную работу с уже внедрённым Memory Bank. Он остаётся во внешней документации шаблона и не копируется в downstream-проект. Канонические project-side правила находятся в [`memory-bank/README.md`](../template/memory-bank/README.md) и `memory-bank/flows/`; первичная установка и адаптация описаны в [`adoption.md`](adoption.md).
+Этот документ описывает повседневную работу с уже внедрённым Memory Bank. Для
+первого запуска начните с [быстрого старта](quick-start.md), а для установки и
+адаптации используйте [инструкцию по внедрению](adoption.md).
 
-## Рабочая модель
+Документ остаётся во внешней документации шаблона и не копируется в
+проект-получатель. Канонические правила конкретного проекта находятся в его
+`memory-bank/README.md` и `memory-bank/flows/`.
 
-Memory Bank не заменяет task tracker или инструмент запуска агента. Он хранит контекст и правила, issue задаёт конкретную работу, а agent runner создаёт рабочее окружение и запускает coding agent.
+## Что меняется по сравнению с вайб-кодингом
+
+Без долговременной памяти задача часто проходит напрямую от запроса к коду.
+Обоснование решения остаётся внутри одной сессии, а следующему агенту приходится
+восстанавливать требования, ограничения и историю проекта заново.
+
+Memory Bank добавляет управляемый цикл:
+
+- агент начинает с подтверждённых знаний о продукте, предметной области,
+  инженерии и эксплуатации;
+- задача проходит через подходящий процесс, а не сразу превращается в код;
+- проблема, решение, порядок реализации и проверки разделяются между своими
+  документами;
+- причины архитектурных решений сохраняются в дизайн-пакетах и ADR — записях
+  архитектурных решений;
+- после реализации новые устойчивые знания возвращаются к своим каноническим
+  владельцам.
+
+В результате проект накапливает не только код, но и историю решённых проблем,
+принятых решений и подтверждённых способов проверки.
+
+## Повседневный цикл
 
 ```text
-Memory Bank
-контекст, правила, требования и способы проверки
-        ↓
-Issue / Task
-задача и ссылки на нужные документы
-        ↓
-agent runner
-branch → worktree → agent session
-        ↓
-реализация → проверки → PR → evidence
-        ↓
-обновление Memory Bank при появлении новых знаний
+Задача
+  ↓
+Минимальные факты для маршрутизации
+  ↓
+Маршрутизация в подходящий процесс
+  ↓
+Связанные требования, сценарии, фичи и решения
+  ↓
+Бриф → дизайн-пакет → план реализации
+  ↓
+Код → проверки → запрос на слияние
+  ↓
+Новые решения, ограничения и подтверждения
+возвращаются в Memory Bank
 ```
 
-Инструменты вроде [`start-issue`](https://github.com/dapi/start-issue) могут автоматизировать создание ветки и worktree и запуск выбранного агента, но не являются обязательной частью Memory Bank.
+### 1. Сформулировать ожидаемый результат
 
-## Рабочий цикл
+Задача в трекере или прямое поручение должны задавать наблюдаемый результат,
+границы и способ проверки. Ссылка на исходную задачу остаётся точкой входа для
+человека и агента.
 
-1. Подготовьте issue с ожидаемым результатом и ссылками на применимые PRD, epic, use case, feature package или ADR.
-2. Выберите workflow по [`memory-bank/flows/routing.md`](../template/memory-bank/flows/routing.md).
-3. Запустите агента в изолированной ветке или worktree.
-4. Агент читает issue и связанные owner-документы, реализует изменение и выполняет предусмотренные проверки.
-5. Завершите работу через PR и приложите требуемые evidence.
-6. Если появились новые устойчивые правила, ограничения или решения, обновите их canonical owner в Memory Bank.
+Не нужно заранее решать, какие документы создавать. Это определяет
+[маршрутизация](../template/memory-bank/flows/routing.md).
 
-Если issue полностью задаёт intent, scope и acceptance, решение не требует design-документов и все routing predicates выполнены, задача может пройти как `Small Change` напрямую к реализации.
+### 2. Собрать минимум для маршрутизации
 
-## Validation profiles
+До выбора процесса агент собирает только факты, необходимые для маршрутизации:
 
-Delivery flow и validation profile выбираются последовательно и отвечают на разные вопросы:
+- ожидаемый результат и известное поведение;
+- наличие действующего дефекта или эксплуатационного воздействия;
+- границы одной задачи или признаки крупной инициативы;
+- необходимость исследования до решения о реализации.
 
-- flow определяет lifecycle задачи, обязательные owner-документы и handoff;
-- validation profile определяет минимальную глубину tests, CI gates, evidence, approvals и rollout/backout.
+На этом этапе не нужно загружать всю базу знаний или проектировать решение.
+Агент начинает с задачи и основных индексов и останавливает предварительный
+поиск, как только может обосновать маршрут.
 
-```text
-Task Routing → delivery flow → validation profile → план проверок
-             → реализация → evidence → review / merge
-```
+### 3. Выбрать процесс
+
+Каждая задача начинается с `Task Routing`. Маршрутизатор выбирает наименьший
+процесс, который сохраняет контроль над риском: инцидент, исправление дефекта,
+исследование, небольшое изменение, крупную инициативу, рефакторинг или
+функциональное изменение.
 
-Profile не является отдельным flow и не меняет routing order. После выбора flow человек или агент проверяет risk triggers и фиксирует ровно один profile в canonical owner задачи. Сейчас это governance-механизм: `memory-bank-cli lint` проверяет целостность документации, но не вычисляет profile автоматически и не запускает соответствующие test suites.
+Два наиболее частых случая:
 
-Canonical taxonomy и minimum contracts определены в [`memory-bank/engineering/validation-profiles.md`](../template/memory-bank/engineering/validation-profiles.md):
+- **Small Change** — исходная задача уже содержит намерение, границы и критерии
+  приёмки, а решение следует известному образцу. Отдельный Feature Pack не
+  создаётся.
+- **Feature Flow** — задача представляет одну проверяемую единицу поставки и
+  требует последовательного перехода от проблемы к решению и реализации.
 
-- `documentation` — только non-runtime documentation/artifact changes;
-- `low-risk` — локальное executable change по известному паттерну без risk triggers;
-- `standard` — default для обычного executable change;
-- `high-risk` — текущий run непосредственно изменяет production/live data, production access/security state, выполняет реальную финансовую или другую необратимую внешнюю операцию;
-- `release-deployment` — production config, build/release artifact, deployment или rollback path без отдельного high-risk trigger.
+Если в ходе работы исходный маршрут перестал соответствовать задаче, агент
+останавливается и выполняет маршрутизацию повторно.
 
-Если одновременно применимы `high-risk` и `release-deployment`, выбирается `high-risk` и дополнительно выполняются release/deployment obligations. Маленький diff или отсутствие готовой test environment не являются основанием снизить profile. Снижение после сработавшего high-risk или release trigger требует rationale и human approval reference.
+### 4. Восстановить связанный контекст и создать документы
 
-### Где и когда фиксируется profile
+После выбора процесса агент читает предусмотренные им источники и находит
+применимые канонические знания:
 
-| Flow | Момент выбора | Canonical owner |
-| --- | --- | --- |
-| Small Change | До реализации, вместе с routing record | Issue/task; draft PR только если tracker нельзя обновить |
-| Feature | При подготовке `brief.md`, до `Problem Ready` | `memory-bank/features/FT-XXX/brief.md` |
-| Bug Fix | На Entry Gate, до analysis и fix | Bug report или связанная delivery task |
-| Refactoring | На Entry Gate, до characterization и execution plan | Исходная task |
-| Incident / PIR | Для containment и PIR profile не выбирается | Отдельная remediation/prevention task после повторного Task Routing |
-| Epic | Для epic целиком profile не выбирается | Отдельный owner каждой delivery feature/subissue |
+- продуктовые цели и требования;
+- термины и правила предметной области;
+- существующие сценарии использования;
+- предыдущие комплекты документов фич;
+- архитектурные решения;
+- инженерные и эксплуатационные ограничения.
 
-Минимальная запись решения:
+Не загружайте всю базу знаний в каждую сессию. Агент начинает с индексов и
+переходит только по связям, относящимся к задаче. История прошлых решений нужна,
+чтобы новое изменение не отменило незаметно уже реализованное требование или
+ограничение.
+
+Для значимой фичи процесс создаёт Feature Pack — долговременный комплект
+документов изменения:
 
 ```text
-Validation profile: documentation | low-risk | standard | high-risk | release-deployment
-Triggers / rationale: <почему выбранный minimum достаточен>
-Downgrade approval: <human approval ref или none>
+brief.md                 design.md                  implementation-plan.md
+что и зачем       →      выбранное решение   →     реализация и проверки
+пространство задачи      пространство решения      пространство исполнения
 ```
 
-После выбора profile конкретные проверки подключаются на уровне исполнения:
+- `brief.md` фиксирует проблему, результат, границы, требования и критерии
+  проверки;
+- дизайн-пакет фиксирует выбранное решение, аргументы, альтернативы, контракты
+  и значимые риски;
+- `implementation-plan.md` связывает решение с конкретными шагами,
+  контрольными точками и проверками.
 
-- в Small Change команды и ожидаемое evidence записываются в `Verify` routing record;
-- в Feature решение остаётся в `brief.md`, а `implementation-plan.md` связывает его obligations с конкретными automated test surfaces, local suites, CI jobs, manual evidence, approval gates и rollout/backout checkpoints;
-- в Bug Fix reproduction и regression coverage должны удовлетворять minimum contract выбранного profile;
-- в Refactoring baseline, characterization coverage и checkpoint verification должны удовлетворять minimum contract выбранного profile.
+Шаблоны этих документов — инструменты мышления. Они заставляют агента отделить
+факты от допущений, назвать ограничения, сравнить варианты и сохранить
+прослеживаемость. В основе такого проектирования лежит FPF — метод мышления от
+первых принципов.
 
-Если во время работы обнаружен более сильный trigger, сначала обновите profile у canonical owner и только затем продолжайте реализацию. Если новый trigger также нарушает predicates текущего flow — например, в Small Change обнаружились migration или rollout requirements — остановите работу и повторите [Task Routing](../template/memory-bank/flows/routing.md).
+### 5. Реализовать изменение в изолированной директории
 
-### Примеры
+Агент работает в отдельной ветке или директории worktree, читает только
+применимые документы и изменяет код согласно принятому решению. Код владеет
+реализацией, а Memory Bank — намерением, требованиями, обоснованием и
+контрактами.
 
-| Задача | Flow | Profile | Практическое следствие |
-| --- | --- | --- | --- |
-| Исправить локальный UI label по существующему i18n pattern | Small Change | `low-risk` | Targeted UI/i18n check, required CI, semantic read-through и обычный review |
-| Изменить payment calculation | Feature | `standard` | Regression и acceptance coverage, affected local suites, полный required CI, convergence pass и обычный review |
-| Выполнить production backfill, меняющий live customer balances | Feature | `high-risk` | Recovery rehearsal, explicit human approval, separate non-authoring domain review, rollout signals и backout plan |
+Инструмент запуска создаёт рабочее окружение и сессию агента. Это может быть
+ручной запуск Codex, [`start-issue`](https://github.com/dapi/start-issue) или
+[Symphony](symphony-github-issues.md). Memory Bank задаёт знания и процесс,
+которым следует запущенный агент.
 
-## Стартовые запросы
+### 6. Проверить результат
 
-### Создать feature package
+После выбора процесса определяется один
+[профиль проверки](../template/memory-bank/engineering/validation-profiles.md).
+Он задаёт минимальную глубину тестов, проверок непрерывной интеграции,
+подтверждений, согласований и действий при выпуске.
 
-```text
-Прочитай ./memory-bank/README.md, ./memory-bank/flows/routing.md
-и ./memory-bank/flows/feature.md. Сначала определи route текущей задачи.
-Если выбран не Feature Flow, остановись и сообщи подходящий route.
-Если выбран Feature Flow, создай feature package, начиная с README.md и brief.md.
-design.md создавай только по правилам Design Requirement Decision,
-а implementation-plan.md — только после готовности upstream-документов.
+| Профиль | Когда применяется |
+| --- | --- |
+| `documentation` | Изменяются только документы и другие неисполняемые материалы |
+| `low-risk` | Локальное изменение по известному образцу без значимых рисков |
+| `standard` | Обычное исполняемое изменение |
+| `high-risk` | Изменение непосредственно затрагивает рабочие данные, доступ или необратимую внешнюю операцию |
+| `release-deployment` | Изменяются выпуск, развёртывание или откат |
+
+Процесс определяет этапы работы, а профиль — глубину проверки. Это разные
+решения. Полные правила и минимальные контракты принадлежат каноническому
+документу по ссылке выше.
+
+### 7. Вернуть знания в Memory Bank
+
+Работа не заканчивается успешным тестом или запросом на слияние. Перед
+завершением агент проверяет, появились ли:
+
+- новое устойчивое правило продукта или предметной области;
+- архитектурное решение и его обоснование;
+- новый сценарий или ограничение;
+- эксплуатационная процедура;
+- подтверждение, которое понадобится при будущей проверке.
+
+Каждый такой факт обновляется у единственного канонического владельца.
+Производные документы ссылаются на него и не создают конкурирующих копий.
+Feature Pack остаётся историей конкретного изменения и помогает следующим
+задачам учитывать уже решённые проблемы.
+
+### 8. Продолжить работу в новой сессии
+
+Новая сессия начинает с исходной задачи, `memory-bank/README.md`, результата
+маршрутизации и существующих документов изменения. Ей не требуется полный чат
+предыдущего агента: существенный контекст уже находится в репозитории.
+
+## Типовые режимы работы
+
+### Небольшое изменение
+
+1. Агент подтверждает маршрут `Small Change`.
+2. Исходная задача остаётся владельцем намерения, границ и приёмки.
+3. Агент реализует локальное изменение, выполняет проверки и открывает запрос
+   на слияние.
+4. Если обнаружено новое устойчивое решение, задача проходит маршрутизацию
+   повторно.
+
+### Значимая фича
+
+1. `Feature Flow` создаёт `README.md` и `brief.md` комплекта фичи.
+2. После готовности проблемы формируется дизайн-пакет.
+3. Принятое решение превращается в `implementation-plan.md`.
+4. Агент реализует план и собирает предусмотренные подтверждения.
+5. После слияния Feature Pack сохраняет историю изменения.
+
+### Архитектурное решение
+
+Если решение действует шире одной фичи или должно жить дольше её комплекта,
+оно фиксируется в ADR. Запись сохраняет контекст, выбранный вариант, причины и
+значимые отклонённые альтернативы. При изменении обстоятельств команда может
+пересмотреть решение, не восстанавливая аргументацию из старых чатов.
+
+## Способы запуска агента
+
+### Интерактивный Codex
+
+Запустите Codex в корне проекта и передайте задачу вместе с точками входа
+Memory Bank:
+
+```bash
+codex -C . \
+  'Прочитай задачу, ./memory-bank/README.md и ./memory-bank/flows/routing.md.
+Выбери подходящий процесс и следуй его каноническому жизненному циклу.
+В финале сообщи маршрут, изменённые документы, проверки и открытые риски.'
 ```
 
-### Проверить качество Memory Bank
+Подробный первый запуск с примером задачи находится в
+[быстром старте](quick-start.md).
+
+### Автоматизированный запуск
+
+`start-issue` может подготовить ветку и директорию worktree и запустить агента
+для выбранной задачи. Интеграция с Symphony в этом репозитории выбирает задачи
+GitHub по метке, запускает Codex в изолированной рабочей директории и передаёт
+готовый запрос на слияние человеку. Подробности и ограничения описаны в
+[инструкции по Symphony](symphony-github-issues.md).
+
+## Проверка качества базы знаний
+
+Периодически поручайте агенту проверить целостность Memory Bank:
 
 ```text
-Проведи ревью ./memory-bank на SSoT, противоречия, broken links,
-orphan-документы, недостающие README-индексы и неясные зависимости.
-Предложи минимальные правки и запусти локальные проверки.
+Проведи ревью ./memory-bank на соблюдение принципа единственного источника
+истины, противоречия, неработающие ссылки, документы без входящих ссылок,
+недостающие README-индексы и неясные зависимости. Предложи минимальные правки
+и выполни локальные проверки.
 ```