feat: add market data architecture and complete migration through build 039

docs/market_intelligence/decisions/decision-002-build-lifecycle.md

@@ -0,0 +1,209 @@
+# Decision 002 — Build Lifecycle
+
+## Статус
+
+**Accepted**
+
+---
+
+# Дата принятия
+
+Принято во время проектирования Stage-08.2 **Engine Runtime Contract**.
+
+---
+
+# Контекст
+
+После принятия решения **Architecture First** возник вопрос:
+
+> Каким образом должна развиваться архитектура платформы?
+
+Были рассмотрены различные подходы к организации процесса разработки.
+
+Главной целью являлось обеспечение стабильного роста платформы без накопления незавершённых изменений и архитектурной деградации.
+
+---
+
+# Проблема
+
+При длительной разработке больших систем часто возникают следующие проблемы:
+
+- одновременно изменяется большое количество компонентов;
+- невозможно определить момент логического завершения работы;
+- документация перестаёт соответствовать коду;
+- проверки выполняются нерегулярно;
+- ошибки обнаруживаются слишком поздно;
+- архитектурные решения принимаются уже после написания кода.
+
+В результате становится сложно определить, какая часть системы действительно готова.
+
+---
+
+# Рассмотренные варианты
+
+## Вариант 1
+
+Разрабатывать большие функциональные блоки без промежуточных этапов.
+
+### Преимущества
+
+- меньше организационной работы;
+- меньше промежуточной документации.
+
+### Недостатки
+
+- большие объёмы изменений;
+- сложность проверки;
+- высокий риск архитектурных ошибок;
+- длительный цикл обратной связи;
+- увеличение сложности сопровождения.
+
+---
+
+## Вариант 2
+
+Разбивать разработку на небольшие логически завершённые Build.
+
+Каждый Build представляет собой самостоятельный этап разработки.
+
+После завершения Build выполняются все проверки качества.
+
+### Преимущества
+
+- небольшие объёмы изменений;
+- высокая предсказуемость;
+- возможность проверки каждого этапа;
+- документация развивается одновременно с кодом;
+- упрощается поиск ошибок;
+- архитектурные решения принимаются постепенно.
+
+### Недостатки
+
+- требуется сопровождать историю Build;
+- увеличивается объём инженерной документации.
+
+---
+
+# Принятое решение
+
+Разработка Dzentra ведётся исключительно последовательностью небольших логически завершённых Build.
+
+Каждый Build должен иметь:
+
+- понятную цель;
+- ограниченную область изменений;
+- завершённую реализацию;
+- обязательную проверку качества;
+- обновлённую документацию.
+
+Build считается завершённым только после прохождения полного жизненного цикла.
+
+---
+
+# Жизненный цикл Build
+
+Каждый Build проходит следующие этапы:
+
+```text
+Architecture Design
+        ↓
+Implementation
+        ↓
+Compile Check
+        ↓
+Architecture Review
+        ↓
+Domain Review
+        ↓
+Documentation Update
+        ↓
+User Confirmation
+        ↓
+Build Closed
+```
+
+До завершения всех этапов переход к следующему Build не допускается.
+
+---
+
+# Причины принятия решения
+
+Использование небольших Build обеспечивает:
+
+- постепенное развитие архитектуры;
+- раннее обнаружение ошибок;
+- минимизацию технического долга;
+- постоянную актуальность документации;
+- простоту сопровождения;
+- возможность безопасного возврата к предыдущим решениям.
+
+---
+
+# Последствия
+
+После принятия настоящего решения:
+
+- каждая новая функциональность реализуется отдельным Build;
+- Build имеет собственную документацию;
+- Build фиксируется в общей истории разработки;
+- архитектурные решения принимаются постепенно;
+- документация обновляется одновременно с исходным кодом.
+
+---
+
+# Правила Build
+
+Каждый Build должен удовлетворять следующим требованиям.
+
+## Логическая завершённость
+
+Build реализует одну законченную архитектурную задачу.
+
+---
+
+## Независимость
+
+Build должен быть понятен без изучения будущих Build.
+
+---
+
+## Проверяемость
+
+После завершения Build должны существовать все необходимые проверки.
+
+---
+
+## Документирование
+
+Каждый Build сопровождается отдельным документом в каталоге:
+
+```text
+docs/market_intelligence/builds/
+```
+
+---
+
+## История
+
+Каждый завершённый Build регистрируется в:
+
+```text
+build_history.md
+```
+
+---
+
+# Связанные документы
+
+- `development_process.md`
+- `architecture_principles.md`
+- `build_history.md`
+- `runtime_contract.md`
+
+---
+
+# История изменений
+
+| Версия | Изменение |
+|---------|-----------|
+| 1.0 | Первое принятие архитектурного решения. |