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

This commit is contained in:
2026-07-14 09:58:16 +03:00
parent 26deb861bc
commit a996f2f797
443 changed files with 80452 additions and 1335 deletions

View File

@@ -0,0 +1,77 @@
# Build №001 — Common Enums
## Файл
```text
app/src/trading/market_intelligence/common/enums.py
```
## Назначение
Создание единого набора перечислений, используемых всеми аналитическими движками Market Intelligence.
Файл определяет общий язык состояний, статусов, уровней уверенности, ролей таймфреймов и этапов обработки.
---
## Реализовано
Добавлены перечисления:
- `MarketDirection`
- `MarketBias`
- `MarketPhase`
- `MarketRegime`
- `MarketQuality`
- `EngineStatus`
- `ConfidenceLevel`
- `SignalFreshness`
- `RiskLevel`
- `TimeframeRole`
- `CheckStatus`
- `ProcessingStage`
---
## Архитектурные решения
- перечисления не содержат торговой логики;
- перечисления не принимают торговых решений;
- значения используются только для описания состояния рынка и работы движков;
- проверки движков описываются через смысловые этапы обработки, а не через имена файлов;
- добавлен `ConfidenceLevel` для человекочитаемой интерпретации числовой уверенности;
- добавлен `SKIPPED` для корректного описания намеренно пропущенных проверок.
---
## Compile Check
```text
PASSED
```
## Architecture Review
```text
PASSED
```
## Domain Review
```text
PASSED
```
## Обязательные замечания
Нет.
## Рекомендации
В будущем `ProcessingStage` можно расширить, если появится реальная необходимость. До этого перечисление не расширяется заранее.
## Статус
```text
ACCEPTED
```

View File

@@ -0,0 +1,96 @@
# Build №002 — Common Types
## Файл
```text
app/src/trading/market_intelligence/common/types.py
```
## Назначение
Создание общего набора типовых алиасов для подсистемы Market Intelligence.
Файл определяет единый типовой контракт для будущих Engine, payload, диагностики и результатов анализа.
---
## Реализовано
Добавлены типы:
- `SymbolName`
- `TimeframeName`
- `EngineName`
- `EngineVersion`
- `ReasonCode`
- `ReasonText`
- `ScoreValue`
- `ConfidenceValue`
- `ProbabilityValue`
- `WeightValue`
- `AgeSeconds`
- `DurationMs`
- `MetricsDict`
- `PayloadDict`
- `ContextDict`
- `MarketData`
- `DependencyResults`
- `DiagnosticMessages`
- `DiagnosticValue`
Повторно используются существующие типы проекта:
- `JsonDict`
- `JsonList`
из:
```text
src.core.types
```
---
## Архитектурные решения
- используется существующий `core.types` как единый источник истины;
- не создаются дубли `JsonDict` и `JsonList`;
- файл не зависит от runtime, execution, Telegram, Journal, EventBus или Exchange;
- файл не содержит торговой логики;
- комментарии объясняют назначение типов, а не синтаксис Python.
---
## Compile Check
```text
PASSED
```
## Architecture Review
```text
PASSED
```
## Domain Review
```text
PASSED
```
## Обязательные замечания
Нет.
## Рекомендации
`DependencyResults` временно использует `Any`. После появления `EngineResult` в `common/models.py` рекомендуется заменить значение словаря на специализированный тип результата движка.
В будущем допускается переход от универсальных словарей `PayloadDict`, `MetricsDict`, `ContextDict` к специализированным `TypedDict`, если это потребуется для усиления типизации.
## Статус
```text
ACCEPTED
```

View File

@@ -0,0 +1,126 @@
# Build №003 — Common Constants
## Файл
```text
app/src/trading/market_intelligence/common/constants.py
```
## Назначение
Создание общего набора архитектурных констант Market Intelligence.
Файл определяет безопасные диапазоны значений, ограничения диагностики, базовые настройки свежести данных и защитные ограничения аналитического слоя.
---
## Реализовано
Добавлены группы констант:
- диапазоны `score`;
- диапазоны `confidence`;
- диапазоны `probability`;
- диапазоны `weight`;
- значения по умолчанию;
- пороги человекочитаемой оценки;
- время устаревания аналитического результата;
- время жизни аналитического сигнала;
- ограничения количества зависимостей Engine;
- ограничения количества метрик;
- ограничения количества предупреждений и ошибок;
- базовая конфигурация таймфреймов;
- запрещённые торговые поля.
---
## Архитектурные решения
- `common/constants.py` содержит только архитектурные ограничения платформы;
- файл не содержит параметров технических индикаторов;
- файл не содержит параметров торговых стратегий;
- файл не содержит настроек открытия или закрытия сделок;
- константы не зависят от конкретного Engine;
- `FORBIDDEN_TRADING_FIELDS` вводит защиту границ между аналитикой и торговыми действиями.
---
## Compile Check
```text
PASSED
```
## Architecture Review
```text
PASSED
```
## Domain Review
```text
PASSED
```
## Обязательные замечания
Нет.
## Post Review Notes
### Решение №001
Архитектурные константы должны содержать только ограничения платформы.
В `common/constants.py` запрещается размещать:
- параметры технических индикаторов;
- параметры торговых стратегий;
- настройки открытия и закрытия сделок;
- параметры биржи;
- параметры управления позицией.
Такие константы должны размещаться внутри соответствующих Engine.
### Решение №002
Константы должны быть сгруппированы по смысловым разделам:
```text
Score
Confidence
Probability
Runtime
Diagnostics
Architecture
Timeframes
Safety
```
### Решение №003
Таймфреймы являются частью конфигурации платформы, а не жёстким ограничением архитектуры.
`DEFAULT_TIMEFRAMES` описывает базовую конфигурацию первого этапа Market Intelligence.
### Решение №004
Возраст результата анализа и возраст торгового сигнала являются разными понятиями.
- `DEFAULT_STALE_AFTER_SECONDS` — когда аналитический результат считается устаревшим.
- `DEFAULT_SIGNAL_TTL_SECONDS` — когда влияние аналитического сигнала начинает уменьшаться.
### Решение №005
Константы, относящиеся только к одному Engine, не должны находиться в `common/constants.py`.
Они должны переноситься в каталог соответствующего Engine.
---
## Статус
```text
ACCEPTED
```

View File

@@ -0,0 +1,101 @@
# Build №004 — Common Reasons
## Файл
```text
app/src/trading/market_intelligence/common/reasons.py
```
## Назначение
Создание единого реестра машинных кодов причин `ReasonCode`.
Файл определяет стандартный словарь причин, который используется будущими Engine для диагностики, payload, snapshot, событий и журналирования.
---
## Реализовано
Добавлен класс:
```text
ReasonCode
```
Он содержит группы причин для следующих областей:
- Common;
- Data;
- Engine Runtime;
- Validation;
- Market State;
- Structure;
- Trend;
- Momentum;
- Volatility;
- Wave;
- Cycle;
- Liquidity;
- Regime;
- Confidence;
- Signal Aging;
- Timeframe.
---
## Архитектурные решения
- движки публикуют стандартизированные коды причин;
- движки не формируют человекочитаемый текст;
- причины отделены от пользовательского интерфейса;
- причины не содержат торговых действий;
- единый словарь причин используется всеми Engine платформы;
- причины описывают состояние рынка или состояние работы движка.
---
## Compile Check
```text
PASSED
```
## Architecture Review
```text
PASSED
```
## Domain Review
```text
PASSED
```
## Обязательные замечания
Нет.
## Рекомендации
После завершения базовых моделей рекомендуется реализовать отдельный слой формирования человекочитаемых объяснений.
Возможное имя файла:
```text
common/reason_texts.py
```
или:
```text
common/explanations.py
```
Этот слой будет преобразовывать `ReasonCode` в понятные сообщения для журнала, интерфейса и отчётов.
## Статус
```text
ACCEPTED
```

View File

@@ -0,0 +1,88 @@
# Build №005 — Common Scores
## Файл
```text
app/src/trading/market_intelligence/common/scores.py
```
## Назначение
Создание единого слоя оценок для Market Intelligence.
Файл определяет общий способ работы с:
- score;
- confidence;
- probability;
- weight;
- weighted score;
- score breakdown.
---
## Реализовано
Добавлены функции:
- `clamp_score`
- `clamp_confidence`
- `clamp_probability`
- `clamp_weight`
- `classify_score_quality`
- `classify_confidence_level`
Добавлены модели:
- `EngineScore`
- `EngineConfidence`
- `ProbabilityScore`
- `WeightedScore`
- `ScoreBreakdown`
---
## Архитектурные решения
- все числовые оценки приводятся к безопасным диапазонам;
- score всегда работает в диапазоне `0...100`;
- confidence всегда работает в диапазоне `0...1`;
- probability всегда работает в диапазоне `0...100`;
- weight всегда работает в диапазоне `0...1`;
- числовые значения получают человекочитаемую интерпретацию;
- итоговая оценка может объясняться через `ScoreBreakdown`;
- файл не содержит торговых решений.
---
## Compile Check
```text
PASSED
```
## Architecture Review
```text
PASSED
```
## Domain Review
```text
PASSED
```
## Обязательные замечания
Нет.
## Рекомендации
После появления `common/validation.py` часть проверок диапазонов может быть повторно использована в механизме валидации EngineResult и Payload.
## Статус
```text
ACCEPTED
```

View File

@@ -0,0 +1,268 @@
# Build 006.1 — Common Models Extension / EngineMetadata
**Engineering Build Document**
---
## Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 006.1 |
| Название | Common Models Extension / EngineMetadata |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Common |
| Тип | Architecture Extension |
| Версия | 1.0 |
| Язык | Русский |
---
## Причина появления Build
Во время проектирования **Engine Layer** было обнаружено, что базовый контракт Engine требует наличия модели, описывающей сам Engine как архитектурный компонент.
Первоначально предполагалось, что данная модель относится к Engine Layer.
Однако архитектурный анализ показал, что она используется значительно шире.
Модель необходима для:
- Engine Layer;
- Runtime Layer;
- будущего Registry;
- будущего Coordinator;
- построения графа зависимостей;
- диагностики;
- документации.
Следовательно, данная модель является частью **Common Layer**, а не Engine Layer.
Для сохранения чистоты архитектуры было принято решение выпустить отдельный Build 006.1 вместо изменения уже принятого Build 006.
---
## Цель Build
Добавить в Common Layer новую базовую модель:
```text
EngineMetadata
```
которая описывает Engine как компонент платформы, а не результат его работы.
---
## Архитектурное решение
Модель размещается в:
```text
app/src/trading/market_intelligence/common/models.py
```
а не в:
```text
app/src/trading/market_intelligence/engine/
```
поскольку является общим контрактом платформы.
---
## Architecture Decision (ADR)
### Решение
Добавить модель `EngineMetadata` в Common Layer.
### Статус
**Accepted**
### Обоснование
Во время проектирования Engine Layer было установлено, что описание Engine используется не только самим Engine, но и Runtime, Registry, Coordinator и другими архитектурными компонентами.
Следовательно, `EngineMetadata` является общим контрактом платформы и должна располагаться в `common.models`.
Размещение модели в Engine Layer привело бы к неправильному направлению архитектурных зависимостей и нарушило бы принцип повторного использования общих моделей.
### Последствия
После принятия решения:
- Engine Layer использует `EngineMetadata` из Common Layer;
- Runtime зависит только от общих контрактов;
- Coordinator сможет получать описание Engine без знания его реализации;
- архитектурные зависимости остаются однонаправленными.
---
## Состав модели
```python
@dataclass(frozen=True, slots=True)
class EngineMetadata:
# Описание Engine как компонента платформы.
# Metadata не содержит аналитической логики и не является результатом анализа.
# Она используется Runtime, Registry, Coordinator и документацией.
name: EngineName
version: EngineVersion
description: str = ""
supported_timeframes: tuple[TimeframeName, ...] = ()
required_dependencies: tuple[EngineName, ...] = ()
optional_dependencies: tuple[EngineName, ...] = ()
enabled_by_default: bool = True
```
---
## Обоснование полей
### name
Уникальное имя Engine.
Используется Registry, Coordinator и журналированием.
---
### version
Версия реализации Engine.
Позволяет определять, какая именно версия логики сформировала результат анализа.
---
### description
Краткое описание назначения Engine.
Используется документацией, диагностикой и интерфейсами разработчика.
---
### supported_timeframes
Перечень поддерживаемых таймфреймов.
Позволяет Coordinator определить применимость Engine для конкретного анализа.
---
### required_dependencies
Перечень обязательных зависимостей.
Если хотя бы один требуемый Engine недоступен, выполнение данного Engine невозможно.
---
### optional_dependencies
Перечень необязательных зависимостей.
Их отсутствие не запрещает выполнение Engine, но может снизить качество анализа.
---
### enabled_by_default
Признак регистрации Engine по умолчанию.
Позволяет включать или отключать Engine без изменения Runtime.
---
## Что Build НЕ добавляет
Build сознательно не включает:
- Runtime;
- Registry;
- Coordinator;
- Dependency Graph;
- порядок запуска Engine;
- приоритеты выполнения;
- настройки Runtime;
- timeout;
- retry;
- cache policy;
- аналитическую логику.
Эти возможности относятся к следующим Build.
---
## Архитектурные последствия
После появления `EngineMetadata` становится возможным построение базового контракта Engine Layer.
Новая зависимость архитектуры выглядит следующим образом:
```text
Common Layer
├── EngineContext
├── EngineResult
├── EngineDependencyResult
└── EngineMetadata
Engine Layer
├── EngineProtocol
└── Engine Implementation
Runtime Layer
Coordinator Layer
```
---
## Итоги Build
В результате Build 006.1:
- Common Layer получил новый общий контракт платформы;
- устранён архитектурный пробел, обнаруженный при проектировании Engine Layer;
- подготовлена основа для реализации `EngineProtocol`;
- Runtime сможет использовать единый контракт Engine без знания конкретных реализаций.
---
## Acceptance
Build считается завершённым после выполнения:
- ✅ Architecture Review
- ✅ Architecture Decision (ADR)
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Documentation
- ✅ Acceptance
---
## Следующий Build
```text
Build 014
Engine Base Contracts
engine/protocol.py
```

View File

@@ -0,0 +1,263 @@
# Build №006 — Common Models
## Файл
```text
app/src/trading/market_intelligence/common/models.py
```
---
# Назначение
Создание единого архитектурного контракта результатов работы всех аналитических движков платформы.
Данный файл определяет общий формат обмена данными между Engine и является центральной моделью подсистемы **Market Intelligence**.
Любой аналитический движок платформы должен использовать данный контракт независимо от своей предметной области.
---
# Реализовано
Созданы базовые модели:
- `EngineMetric`
- `EngineDiagnostics`
- `EngineEvaluationMeta`
- `EngineDependencyResult`
- `EngineContext`
- `EngineResult`
Все модели реализованы как неизменяемые (`frozen=True`) dataclass с использованием `slots=True`.
---
# Назначение моделей
## EngineMetric
Описывает одну измеряемую характеристику, рассчитанную движком.
Примеры:
- сила движения;
- процент волатильности;
- ширина спреда;
- длительность волны.
Метрика не является торговым решением.
---
## EngineDiagnostics
Хранит техническую диагностику выполнения движка.
Используется для:
- журналирования;
- диагностики;
- проверки качества работы;
- анализа ошибок.
Диагностика полностью отделена от пользовательского интерфейса.
---
## EngineEvaluationMeta
Содержит служебную информацию о расчёте.
Например:
- название движка;
- версия движка;
- время выполнения;
- длительность расчёта;
- возраст входных данных.
---
## EngineDependencyResult
Представляет результат другого аналитического движка в компактной форме.
Используется для построения зависимостей между Engine без прямых импортов.
---
## EngineContext
Определяет единый входной контракт любого аналитического движка.
Контекст содержит только данные, необходимые для анализа рынка.
Контекст не содержит информации о:
- позициях;
- балансе;
- исполнении;
- торговых приказах;
- пользовательском интерфейсе.
---
## EngineResult
Является единым результатом работы любого Engine.
Содержит:
- состояние выполнения;
- оценки;
- уровень уверенности;
- направление рынка;
- режим рынка;
- фазу рынка;
- диагностическую информацию;
- рассчитанные метрики;
- служебные сведения.
EngineResult описывает только результат анализа рынка.
EngineResult не содержит торговых решений.
---
# Архитектурные решения
Во время реализации приняты следующие решения.
## Единый контракт
Все аналитические движки используют один и тот же тип результата.
Это позволяет Coordinator работать с любым Engine одинаковым образом.
---
## Разделение ответственности
Контракт разделён на независимые части:
- входные данные (`EngineContext`);
- результат анализа (`EngineResult`);
- диагностика (`EngineDiagnostics`);
- служебные сведения (`EngineEvaluationMeta`);
- зависимости (`EngineDependencyResult`);
- отдельные измеряемые показатели (`EngineMetric`).
---
## Независимость от торговли
Контракт не содержит:
- открытия позиции;
- закрытия позиции;
- управления ордерами;
- расчёта размера позиции;
- информации о балансе;
- информации о бирже.
Market Intelligence остаётся исключительно аналитическим уровнем платформы.
---
## Независимость движков
Ни один Engine не импортирует другой Engine напрямую.
Передача результатов между движками осуществляется через `EngineDependencyResult`.
Это исключает циклические зависимости и упрощает масштабирование платформы.
---
## Минимальный контекст
Engine получает только необходимые входные данные.
Контекст не превращается в универсальное хранилище состояния платформы.
Это позволяет каждому Engine работать независимо.
---
## Иммутабельность
Все модели объявлены как неизменяемые (`frozen=True`).
После формирования результата он больше не изменяется.
Это обеспечивает:
- предсказуемость;
- безопасную передачу между компонентами;
- стабильное журналирование;
- корректное сравнение результатов.
---
# Compile Check
```text
PASSED
```
---
# Architecture Review
```text
PASSED
```
---
# Domain Review
```text
PASSED
```
---
# Обязательные замечания
Нет.
---
# Рекомендации
В дальнейшем рекомендуется дополнить архитектуру следующими сущностями после появления соответствующей практической необходимости:
- идентификатор результата (`result_id`);
- источник рыночных данных (`data_source`);
- время окончания актуальности результата (`expires_at`).
До появления реальной потребности данные поля не добавляются.
Это соответствует принципу **No Premature Abstractions**.
---
# Статус
```text
ACCEPTED
```
---
# Итоги Build
Build №006 завершил проектирование единого контракта аналитических движков.
Начиная с данного Build все новые Engine должны возвращать результат исключительно через `EngineResult`.
Создание собственных моделей результатов внутри отдельных Engine запрещается.
`common/models.py` становится единым источником истины для архитектуры результатов Market Intelligence.

View File

@@ -0,0 +1,248 @@
# Build 007 — Common Validation Layer
**Build ID:** 007
**Component:** `common/validation.py`
**Stage:** Stage 08.2 — Common Foundation
**Status:** **ACCEPTED**
---
# Цель Build
Создать единый слой архитектурной проверки (**Validation Layer**) для компонентов Market Intelligence.
Validation Layer отвечает за проверку соблюдения Runtime Contract и архитектурных ограничений Common Layer.
Данный слой не анализирует рынок и не принимает торговых решений.
---
# Контекст
К моменту начала Build уже существовали:
- единые перечисления (`enums.py`);
- общие типы (`types.py`);
- архитектурные константы (`constants.py`);
- единый словарь причин (`reasons.py`);
- модели оценок (`scores.py`);
- единые Runtime-модели (`models.py`).
Следующим необходимым компонентом стала централизованная проверка корректности этих моделей.
---
# Реализовано
Создан файл:
```text
app/src/trading/market_intelligence/common/validation.py
```
Добавлены модели:
- ValidationIssue
- ValidationResult
Добавлены проверки:
- validate_engine_context()
- validate_engine_result()
- validate_payload_has_no_trading_fields()
---
# Назначение Validation Layer
Validation Layer выполняет исключительно архитектурную проверку.
Он отвечает за:
- проверку обязательных полей Runtime Contract;
- проверку ограничений Common Layer;
- проверку запрещённых торговых полей;
- формирование диагностического результата проверки.
Validation Layer не анализирует состояние рынка.
---
# Архитектурные решения
Во время Build были подтверждены следующие решения.
## Validation не принимает торговых решений
Validation Layer не выполняет:
- анализ рынка;
- расчёт сигналов;
- принятие торговых решений;
- взаимодействие с биржей.
Он проверяет только соблюдение архитектурного контракта.
---
## Validation возвращает результат проверки
Проверка не использует исключения как основной механизм обработки.
Результатом проверки всегда является объект:
```text
ValidationResult
```
Это позволяет Coordinator и Runtime безопасно обрабатывать ошибки без остановки всей платформы.
---
## Validation использует единые модели Common
Validation Layer повторно использует:
- EngineContext
- EngineResult
- ReasonCode
- CheckStatus
- EngineStatus
Новые дублирующие модели не создаются.
---
## Validation защищает границы Market Intelligence
Добавлена централизованная проверка запрещённых торговых полей.
Используется архитектурная константа:
```text
FORBIDDEN_TRADING_FIELDS
```
Это предотвращает случайное проникновение торговой логики в аналитический слой.
---
## Validation не зависит от конкретных Engine
Validation Layer не содержит:
- знаний о Trend Engine;
- знаний о Wave Engine;
- знаний о Liquidity Engine;
- знаний о Strategy;
- знаний о Execution.
Он одинаково применим для любого аналитического движка платформы.
---
# Compile Check
Статус:
**PASSED**
Проверка выполнена командой:
```bash
python -m compileall src/trading/market_intelligence/common/validation.py
```
Компиляция завершилась успешно.
---
# Architecture Review
Статус:
**PASSED**
Проверено:
- отсутствие циклических зависимостей;
- соблюдение Layer Isolation;
- повторное использование моделей Common;
- соблюдение Runtime Contract;
- отсутствие нарушения зон ответственности.
Обязательные замечания отсутствуют.
---
# Domain Review
Статус:
**PASSED**
Подтверждено:
- отсутствует торговая логика;
- отсутствуют торговые решения;
- отсутствует взаимодействие с биржей;
- отсутствует работа с позициями;
- Validation выполняет только проверку архитектурного контракта.
---
# Engineering Review
Подтверждено формирование законченного архитектурного фундамента Common Layer.
На текущем этапе сформирована следующая последовательность компонентов:
```text
types
enums
constants
reasons
scores
models
validation
```
Validation Layer завершает базовый уровень проверки архитектурного контракта.
---
# Рекомендации
В дальнейшем допускается развитие Validation Layer следующими возможностями:
- специализированные проверки отдельных Engine;
- расширенная проверка Runtime Contract;
- интеграция с будущим Review Layer;
- автоматическая генерация диагностических отчётов.
Данные возможности не входят в текущий Build.
---
# Итог
Build №007 завершает создание базового Validation Layer подсистемы Market Intelligence.
Компонент полностью соответствует:
- Development Process v2.0;
- Architecture Principles;
- Runtime Contract.
Build получает статус:
**ACCEPTED**

View File

@@ -0,0 +1,248 @@
# Build 008 — Common Checks Layer
**Build ID:** 008
**Component:** `common/checks.py`
**Stage:** Stage 08.2 — Common Foundation
**Status:** **ACCEPTED**
---
# Цель Build
Создать единый слой инженерных проверок (**Checks Layer**) для аналитических движков подсистемы Market Intelligence.
Checks Layer предназначен для фиксации прохождения отдельных этапов обработки Engine и формирования единого инженерного отчёта о ходе выполнения анализа.
Данный слой не выполняет проверку корректности моделей и не анализирует состояние рынка.
---
# Контекст
К началу Build уже существовали:
- единые перечисления (`enums.py`);
- общие типы (`types.py`);
- архитектурные константы (`constants.py`);
- единый словарь причин (`reasons.py`);
- модели оценок (`scores.py`);
- Runtime-модели (`models.py`);
- Validation Layer (`validation.py`).
Следующим этапом стало создание отдельного слоя инженерных проверок выполнения Engine.
---
# Реализовано
Создан файл:
```text
app/src/trading/market_intelligence/common/checks.py
```
Добавлены модели:
- EngineCheck
- EngineCheckReport
Добавлены функции:
- build_check()
- build_check_report()
---
# Назначение Checks Layer
Checks Layer используется для фиксации результатов внутренних этапов обработки аналитического движка.
Он позволяет:
- описывать прохождение отдельных этапов Runtime;
- объединять проверки в единый отчёт;
- отделить инженерные проверки выполнения от проверки архитектурного контракта.
Checks Layer не анализирует рынок и не проверяет корректность входных данных.
---
# Архитектурные решения
Во время Build были подтверждены следующие решения.
## Checks Layer не заменяет Validation Layer
Validation Layer и Checks Layer имеют разные области ответственности.
Validation Layer отвечает на вопрос:
> **Корректен ли Runtime Contract?**
Checks Layer отвечает на вопрос:
> **Какие этапы обработки выполнил Engine?**
Таким образом оба слоя взаимно дополняют друг друга, не дублируя функциональность.
---
## Проверка выполняется по этапам обработки
Каждая проверка относится к одному значению `ProcessingStage`.
Например:
- INPUT
- CALCULATION
- VALIDATION
- PAYLOAD
- SNAPSHOT
- RESULT
- EVENT
Это позволяет анализировать работу Engine поэтапно.
---
## Отчёт агрегирует независимые проверки
Engine может сформировать несколько отдельных проверок.
Они объединяются в объект:
```text
EngineCheckReport
```
Отчёт определяет общий инженерный статус выполнения без повторной проверки отдельных этапов.
---
## Checks Layer не содержит предметной логики
Checks Layer не знает:
- что такое тренд;
- что такое волна;
- что такое ликвидность;
- что такое фаза рынка.
Он работает исключительно с инженерными этапами выполнения Runtime.
---
## Checks Layer не зависит от конкретных Engine
Файл не содержит ссылок на:
- Trend Engine;
- Wave Engine;
- Liquidity Engine;
- Coordinator;
- Strategy;
- Execution.
Любой аналитический движок может использовать данный слой без изменений.
---
# Compile Check
Статус:
**PASSED**
Проверка выполнена командой:
```bash
python -m compileall src/trading/market_intelligence/common/checks.py
```
Компиляция завершилась успешно.
---
# Architecture Review
Статус:
**PASSED**
Подтверждено:
- отсутствие циклических зависимостей;
- корректное разделение Validation Layer и Checks Layer;
- соблюдение Layer Isolation;
- повторное использование моделей Common;
- масштабируемость архитектуры.
Обязательные замечания отсутствуют.
---
# Domain Review
Статус:
**PASSED**
Подтверждено:
- отсутствует торговая логика;
- отсутствует анализ рынка;
- отсутствует взаимодействие с биржей;
- отсутствует работа с позициями;
- Checks Layer выполняет исключительно инженерную диагностику выполнения Engine.
---
# Engineering Review
После завершения Build №008 фундамент Common Layer получил два независимых уровня контроля качества:
```text
Runtime Contract
Validation Layer
Checks Layer
```
Validation Layer отвечает за корректность архитектурного контракта.
Checks Layer отвечает за фиксацию прохождения этапов обработки.
Такое разделение обеспечивает независимое развитие обоих компонентов и предотвращает смешивание архитектурных обязанностей.
---
# Рекомендации
В дальнейшем допускается развитие Checks Layer следующими возможностями:
- группировка проверок по Engine;
- сохранение времени выполнения отдельных этапов;
- интеграция с Runtime Review;
- автоматическое формирование инженерных отчётов.
Данные возможности не входят в текущий Build.
---
# Итог
Build №008 завершает создание базового Checks Layer подсистемы Market Intelligence.
Компонент полностью соответствует:
- Development Process v2.0;
- Architecture Principles;
- Runtime Contract.
Build получает статус:
**ACCEPTED**

View File

@@ -0,0 +1,187 @@
# Build 009 — Common Payloads Layer
**Build ID:** 009
**Компонент:** `common/payloads.py`
**Статус:** **Accepted**
---
# Цель Build
Реализовать единый механизм преобразования результатов работы Market Intelligence в стандартный диагностический Payload.
Payload является официальным способом передачи результатов аналитических движков между слоями платформы, а также используется для:
- журналирования;
- диагностики;
- Snapshot;
- Runtime;
- Event;
- последующей сериализации.
Данный Build не реализует торговую логику и не принимает торговых решений.
---
# Реализованные компоненты
Создан файл:
```text
market_intelligence/common/payloads.py
```
Реализованы функции:
- `value_to_payload()`
- `mapping_to_payload()`
- `engine_score_to_payload()`
- `engine_confidence_to_payload()`
- `engine_metric_to_payload()`
- `engine_diagnostics_to_payload()`
- `engine_dependency_to_payload()`
- `engine_result_to_payload()`
---
# Архитектурная задача
До появления данного Build каждый Engine мог потенциально формировать собственный формат диагностических данных.
После реализации общего Payload Layer все Engine используют единый механизм сериализации.
Таким образом достигаются:
- единый формат Runtime;
- единый формат Snapshot;
- единый формат Diagnostics;
- единый формат Event;
- единый формат журналирования.
---
# Архитектурные решения
В ходе реализации приняты следующие решения.
## Единая сериализация
Все значения проходят единый процесс преобразования.
Поддерживаются:
- dataclass;
- Enum;
- Mapping;
- tuple;
- list;
- простые типы Python.
Payload всегда содержит только сериализуемые структуры.
---
## Payload не принимает решений
Payload является исключительно транспортным представлением результата.
Он не содержит:
- торговых команд;
- расчётов позиции;
- рекомендаций на открытие сделки;
- изменений Runtime.
---
## Автоматическая проверка архитектурных ограничений
Перед возвратом итогового Payload выполняется:
```text
validate_payload_has_no_trading_fields()
```
Если обнаружены запрещённые торговые поля, информация сохраняется в диагностическом разделе Payload.
Нарушение не скрывается и становится доступным для анализа во время Runtime и Engineering Review.
---
## Независимость от Engine
Payload Layer не знает:
- конкретные Engine;
- Strategy;
- AutoTrade;
- Exchange;
- Telegram UI.
Компонент работает исключительно с общими моделями слоя Common.
---
# Compile Check
Выполнена проверка:
```bash
python -m compileall \
src/trading/market_intelligence/common/payloads.py
```
Результат:
```text
Compile successful
```
---
# Architecture Review
Результат: **PASSED**
Проверено:
- соблюдение ответственности слоя;
- отсутствие торговой логики;
- независимость от Runtime;
- независимость от UI;
- независимость от AutoTrade;
- единый механизм сериализации.
Архитектурных замечаний не выявлено.
---
# Domain Review
Результат: **PASSED**
Проверено:
- отсутствие торговых решений;
- объяснимость структуры Payload;
- пригодность для журналирования;
- пригодность для диагностики;
- соответствие Runtime Contract.
Замечаний не выявлено.
---
# Итог Build
Build успешно завершил создание общего слоя сериализации результатов Market Intelligence.
Payload становится официальным форматом передачи аналитических результатов между компонентами платформы.
---
# Build Status
**Accepted**

View File

@@ -0,0 +1,193 @@
# Build 010 — Common Snapshots Layer
**Build ID:** 010
**Компонент:** `common/snapshots.py`
**Статус:** **Accepted**
---
# Цель Build
Реализовать единый слой Snapshot для подсистемы Market Intelligence.
Snapshot представляет собой неизменяемый снимок результата работы аналитического движка в определённый момент времени.
Данный Build создаёт единый формат хранения результатов анализа без привязки к конкретному Engine.
---
# Реализованные компоненты
Создан файл:
```text
market_intelligence/common/snapshots.py
```
Реализованы:
- `EngineSnapshot`
- `build_engine_snapshot()`
- `engine_snapshot_to_payload()`
---
# Архитектурная задача
До появления данного Build существовал единый Runtime Result (`EngineResult`), но отсутствовал стандартный механизм фиксации его состояния.
После реализации Snapshot Layer каждый результат анализа может быть сохранён в неизменяемом виде.
Snapshot становится стандартным объектом для:
- журналирования;
- диагностики;
- формирования Event;
- хранения истории анализа;
- последующего сравнения состояний рынка.
---
# Архитектурные решения
В ходе реализации приняты следующие решения.
## Snapshot является неизменяемым
Используется
```python
@dataclass(frozen=True, slots=True)
```
После создания Snapshot его содержимое больше не изменяется.
Это гарантирует воспроизводимость результатов анализа.
---
## Snapshot строится только из EngineResult
Snapshot никогда не вычисляет данные самостоятельно.
Он всегда строится через:
```text
EngineResult
engine_result_to_payload()
EngineSnapshot
```
Таким образом существует единая точка формирования результата анализа.
---
## Snapshot не содержит торговой логики
Snapshot не имеет права хранить:
- команды открытия позиции;
- команды закрытия позиции;
- расчёт размера позиции;
- состояние AutoTrade;
- состояние Exchange;
- Runtime Position.
Snapshot фиксирует исключительно аналитический результат.
---
## Payload является частью Snapshot
Snapshot не копирует отдельные поля EngineResult.
Вместо этого используется единый Payload Layer.
Это исключает дублирование логики сериализации.
---
## Независимость от Runtime
Snapshot Layer не зависит от:
- AutoTrade;
- Exchange;
- Telegram;
- Journal;
- конкретных Engine.
Компонент использует исключительно сущности Common Layer.
---
# Compile Check
Выполнена проверка:
```bash
python -m compileall \
src/trading/market_intelligence/common/snapshots.py
```
Результат:
```text
Compile successful
```
---
# Architecture Review
Результат:
**PASSED**
Проверено:
- соблюдение Single Responsibility;
- неизменяемость Snapshot;
- отсутствие торговой логики;
- использование единого Payload Layer;
- отсутствие нарушения архитектурных границ.
Замечаний не выявлено.
---
# Domain Review
Результат:
**PASSED**
Проверено:
- Snapshot отражает исключительно состояние анализа;
- отсутствуют торговые решения;
- структура пригодна для журналирования;
- структура пригодна для Runtime;
- структура соответствует Runtime Contract.
Замечаний не выявлено.
---
# Итог Build
Build завершил создание общего Snapshot Layer.
Все аналитические движки платформы получили единый механизм фиксации собственного состояния.
Snapshot становится стандартным архитектурным объектом Market Intelligence.
---
# Build Status
**Accepted**

View File

@@ -0,0 +1,205 @@
# Build 011 — Common Events Layer
**Build ID:** 011
**Компонент:** `common/events.py`
**Статус:** **Accepted**
---
# Цель Build
Реализовать единый слой представления событий подсистемы Market Intelligence.
Events Layer определяет стандартный формат аналитических событий, которые в дальнейшем смогут использоваться Runtime, журналом, системой диагностики и EventBus.
Данный Build не реализует публикацию событий и не зависит от конкретного механизма доставки.
---
# Реализованные компоненты
Создан файл:
```text
market_intelligence/common/events.py
```
Реализованы:
- `MarketIntelligenceEvent`
- `build_engine_result_event()`
- `build_engine_snapshot_event()`
- `build_result_snapshot_event()`
- `market_intelligence_event_to_payload()`
---
# Архитектурная задача
До появления данного Build существовали:
```text
EngineResult
Payload
Snapshot
```
Однако отсутствовало единое архитектурное представление аналитического события.
После реализации Events Layer любое завершение работы Engine может быть представлено в виде стандартного события Market Intelligence.
---
# Архитектурные решения
В ходе реализации приняты следующие решения.
## Event является архитектурной моделью
MarketIntelligenceEvent описывает событие анализа рынка.
Сам объект события не занимается публикацией.
Таким образом разделяются:
```text
Event Model
Event Transport
```
Это позволяет использовать любые механизмы доставки без изменения модели события.
---
## Event строится из существующих моделей
События создаются исключительно через существующие архитектурные объекты.
Поддерживаются цепочки:
```text
EngineResult
Event
```
и
```text
EngineResult
Snapshot
Event
```
Никаких дополнительных расчётов внутри Event Layer не выполняется.
---
## Payload не дублируется
Events Layer не сериализует данные самостоятельно.
Используются уже существующие компоненты:
- Payload Layer;
- Snapshot Layer.
Это сохраняет принцип единственного источника истины.
---
## Независимость от EventBus
Common Layer определяет только структуру события.
Он ничего не знает о:
- EventBus;
- Runtime;
- Journal;
- AutoTrade;
- Telegram;
- Exchange.
Таким образом Event Layer остаётся полностью независимым.
---
# Compile Check
Выполнена проверка:
```bash
python -m compileall \
src/trading/market_intelligence/common/events.py
```
Результат:
```text
Compile successful
```
---
# Architecture Review
Результат:
**PASSED**
Проверено:
- соблюдение Single Responsibility;
- отсутствие публикации событий;
- отсутствие торговой логики;
- использование существующих моделей;
- независимость от Runtime;
- отсутствие циклических зависимостей.
Архитектурных замечаний не выявлено.
---
# Domain Review
Результат:
**PASSED**
Проверено:
- событие отражает только факт завершения анализа;
- отсутствуют торговые действия;
- отсутствуют Runtime-решения;
- структура пригодна для журналирования;
- структура соответствует Runtime Contract.
Замечаний не выявлено.
---
# Итог Build
Build завершил создание общего Events Layer.
Market Intelligence получил единый формат аналитических событий, который может использоваться любыми внешними компонентами платформы.
---
# Build Status
**Accepted**

View File

@@ -0,0 +1,226 @@
# Build 012 — Common Timeframes
**Build ID:** 012
**Component:** `common/timeframes.py`
**Status:** ✅ Accepted
**Development Process:** v2.0
---
# Цель Build
Создать единый архитектурный слой описания таймфреймов, который будет использоваться всеми будущими Engine подсистемы Market Intelligence.
До данного Build информация о таймфреймах существовала только внутри отдельных модулей старой системы анализа рынка.
Это затрудняло повторное использование логики и не позволяло создать единый контракт для многоуровневого анализа.
Настоящий Build переносит описание таймфреймов в слой Common и делает его независимым от реализации конкретных аналитических движков.
---
# Реализованные компоненты
Добавлен новый файл:
```text
common/timeframes.py
```
В рамках Build реализованы:
- модель `Timeframe`;
- единый реестр поддерживаемых таймфреймов;
- архитектурные роли таймфреймов;
- карта переходов к старшему таймфрейму;
- функции поиска и проверки таймфреймов;
- преобразование модели в диагностический payload.
---
# Архитектурные решения
## Единая модель Timeframe
Каждый временной интервал представлен неизменяемым объектом `Timeframe`.
Модель содержит только архитектурное описание интервала:
- имя;
- длительность;
- роль;
- описание.
Модель не содержит торговой логики.
---
## Централизованный реестр
Все поддерживаемые интервалы собраны в одном месте.
На текущем этапе поддерживаются:
```text
1m
5m
15m
1h
4h
1d
1w
```
Это создаёт единый источник истины для всей платформы.
---
## Архитектурные роли
Каждому таймфрейму назначается роль:
- LOWER;
- PRIMARY;
- CONFIRMATION;
- HIGHER.
Роль используется будущими движками при построении многоуровневого анализа.
---
## Карта старших таймфреймов
Добавлена централизованная карта переходов:
```text
1m → 5m
5m → 1h
15m → 1h
1h → 4h
4h → 1d
1d → 1w
```
На текущем этапе она полностью совместима с существующей реализацией `MarketAnalysisService`, где рабочий интервал `5m` использует старший `1h`.
---
## Независимость от существующего анализа рынка
Файл не использует:
- `MarketAnalysisService`;
- `ExchangeService`;
- старые модели;
- AutoTrade.
Таким образом создаётся самостоятельный фундамент для новой подсистемы Market Intelligence без изменения существующего поведения бота.
---
# Реализованные функции
Добавлены следующие функции:
- `get_timeframe()`
- `require_timeframe()`
- `is_supported_timeframe()`
- `get_higher_timeframe()`
- `get_timeframes_by_role()`
- `timeframe_to_payload()`
Все функции являются детерминированными и не имеют побочных эффектов.
---
# Compile Check
Статус:
```text
PASSED
```
Проверка:
```bash
python -m compileall src/trading/market_intelligence/common/timeframes.py
```
Результат:
```text
Compiling 'src/trading/market_intelligence/common/timeframes.py'...
```
Ошибок компиляции не обнаружено.
---
# Architecture Review
**Статус:** ✅ Passed
Проверено:
- отсутствие циклических зависимостей;
- отсутствие торговой логики;
- независимость от Runtime;
- независимость от Exchange;
- независимость от AutoTrade;
- соответствие архитектуре Common Layer.
Замечаний нет.
---
# Domain Review
**Статус:** ✅ Passed
Проверено:
- корректность терминологии;
- соответствие философии Market Intelligence;
- отсутствие принятия торговых решений;
- корректное разделение понятий "таймфрейм" и "анализ рынка".
Замечаний нет.
---
# Engineering Review
Положительные результаты Build:
- создан единый источник истины для таймфреймов;
- устранено дублирование будущих определений;
- подготовлен фундамент для Multi-Timeframe Engine;
- сохранена совместимость с существующей системой анализа рынка.
Build не оказывает влияния на работу действующего торгового бота.
---
# Документация
В рамках Build подготовлены:
- `common/timeframes.py`;
- `build-012-common-timeframes.md`;
- обновление `build_history.md`.
---
# Итог
Build успешно завершил создание единого слоя описания таймфреймов.
Следующие аналитические движки смогут использовать единый контракт работы с временными интервалами без зависимости от устаревшей реализации `market_analysis`.
---
**Итоговый статус Build:** ✅ **Accepted**

View File

@@ -0,0 +1,215 @@
# Build 013 — Runtime Architecture
**Build ID:** 013
**Компонент:** Runtime Layer
**Статус:** ✅ Accepted
**Тип Build:** Architecture Build
---
# Цель Build
Спроектировать архитектуру слоя Runtime подсистемы **Market Intelligence**.
До начала реализации первого аналитического Engine необходимо определить единый механизм выполнения движков.
В рамках Build проектируется инфраструктурный слой Runtime, который станет основой для всех последующих Engine.
Исходный код в рамках данного Build не создаётся.
---
# Причина появления Runtime
После завершения Common Layer платформа получила единый набор:
- моделей;
- типов;
- диагностических структур;
- проверки корректности;
- snapshot;
- payload;
- событий.
Следующим логическим уровнем архитектуры является Runtime.
Без Runtime каждый Engine был бы вынужден самостоятельно решать вопросы:
- запуска;
- обработки ошибок;
- проверки результата;
- формирования fallback;
- взаимодействия с Coordinator.
Это неизбежно привело бы к дублированию логики.
---
# Архитектурное решение
Введён новый архитектурный уровень:
```text
Common Layer
Runtime Layer
Engine Layer
Coordinator Layer
```
Runtime становится единственной инфраструктурой выполнения Engine.
---
# Спроектированная структура Runtime
Определена следующая структура каталога.
```text
runtime/
├── __init__.py
├── protocol.py
├── base.py
├── runner.py
├── registry.py
├── dependencies.py
└── validation.py
```
Каждый файл получил единственную область ответственности.
---
# Основные обязанности Runtime
Runtime отвечает исключительно за инфраструктуру выполнения аналитических Engine.
В область ответственности Runtime входят:
- единый контракт Engine;
- единый жизненный цикл выполнения;
- безопасный запуск Engine;
- обработка исключений;
- Runtime Validation;
- регистрация Engine;
- управление зависимостями;
- формирование безопасного EngineResult.
Runtime не содержит аналитической логики.
---
# Основные архитектурные принципы
Во время проектирования подтверждены следующие правила.
- Runtime не анализирует рынок.
- Runtime не принимает торговых решений.
- Runtime не взаимодействует с биржей.
- Runtime не знает об AutoTrade.
- Runtime использует Common как единственный источник базовых моделей.
- Engine взаимодействуют только через Runtime.
---
# Документация
В рамках Build создан новый раздел документации.
```text
docs/market_intelligence/runtime/
```
Созданы документы:
```text
runtime/README.md
runtime/architecture.md
```
Теперь Runtime имеет собственную архитектурную документацию, независимую от Build History.
---
# Реализованные изменения
Исходный код не создавался.
Выполнено архитектурное проектирование Runtime Layer.
---
# Compile Check
Не требуется.
Build содержит исключительно архитектурную документацию.
---
# Architecture Review
**Статус:** PASSED
Подтверждено:
- правильное положение Runtime в архитектуре;
- отсутствие нарушения слоёв;
- независимость Runtime от Engine;
- независимость Runtime от AutoTrade;
- отсутствие циклических зависимостей.
---
# Domain Review
**Статус:** PASSED
Runtime остаётся инфраструктурным уровнем.
Торговая логика отсутствует.
Аналитическая логика отсутствует.
---
# Documentation Review
Созданы новые документы Runtime.
Build History подлежит обновлению.
README Runtime создан.
Архитектурная спецификация Runtime создана.
---
# Следующий Build
```text
Build 014
runtime/protocol.py
```
---
# Итог
Build успешно завершил проектирование Runtime Layer.
Данный Build создаёт архитектурный фундамент для всех будущих аналитических Engine.
Статус Build:
```text
ACCEPTED
```

View File

@@ -0,0 +1,243 @@
# Build 014.1 — Engine Base Contracts / Engine Protocol
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 014.1 |
| Название | Engine Base Contracts / Engine Protocol |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Engine |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Причина появления Build
После завершения проектирования **Engine Layer Architecture** началась разработка Runtime Layer.
Во время проектирования было выявлено, что Runtime не может зависеть от конкретных аналитических движков.
Для обеспечения независимости Runtime требуется единый официальный контракт любого Engine.
Настоящий Build вводит данный контракт.
---
# Цель Build
Создать минимальный контракт любого аналитического движка платформы **Market Intelligence**.
Контракт должен позволять Runtime взаимодействовать с любым Engine без знания его внутренней реализации.
---
# Architecture
Каждый Engine обязан предоставлять два обязательных элемента:
```text
EngineProtocol
├── get_metadata()
└── analyze(context)
```
Назначение методов:
- `get_metadata()` — предоставляет описание Engine без создания экземпляра.
- `analyze()` — выполняет анализ рыночного контекста и возвращает единый результат.
Engine не содержит Runtime-инфраструктуры и не определяет порядок выполнения других Engine.
---
# Architecture Review
Проверка показала соответствие архитектурным принципам проекта.
Подтверждено:
- Engine остаются независимыми друг от друга.
- Metadata полностью отделена от аналитической логики.
- Runtime сможет работать исключительно через контракт.
- Coordinator не зависит от реализации Engine.
- AutoTrade не затрагивается.
Build признан архитектурно корректным.
---
# Architecture Decision (ADR)
## Решение
Ввести единый контракт:
```text
EngineProtocol
```
## Статус
**Accepted**
## Обоснование
Runtime и будущий Coordinator должны работать с любым аналитическим движком посредством единого интерфейса.
Описание Engine должно быть доступно без создания экземпляра.
Поэтому контракт включает:
- `get_metadata()`;
- `analyze(context)`.
## Последствия
После принятия решения:
- Runtime зависит только от `EngineProtocol`;
- новые Engine могут свободно добавляться в платформу;
- архитектурные зависимости остаются однонаправленными;
- Engine Layer получает единый официальный контракт.
---
# Build Design
Создан файл:
```text
app/src/trading/market_intelligence/engine/protocol.py
```
Файл содержит исключительно Protocol.
Он не содержит:
- реализации;
- аналитической логики;
- Runtime;
- Coordinator;
- Registry;
- инфраструктуры исполнения.
---
# Implementation
Реализован следующий контракт:
```python
class EngineProtocol(Protocol):
@classmethod
def get_metadata(cls) -> EngineMetadata:
...
async def analyze(
self,
context: EngineContext,
) -> EngineResult:
...
```
Контракт использует только общие модели Common Layer:
- EngineContext;
- EngineMetadata;
- EngineResult.
---
# Compile Check
Проверено:
- файл успешно импортируется;
- отсутствуют циклические зависимости;
- используются только модели Common Layer;
- контракт не зависит от Runtime;
- контракт не зависит от Coordinator.
Build успешно проходит Compile Check.
---
# Domain Review
Проверено соответствие предметной области.
EngineProtocol:
- описывает исключительно контракт аналитического Engine;
- не содержит аналитической логики;
- не содержит Runtime;
- не содержит Coordinator;
- не содержит торговой логики;
- не зависит от конкретных Engine.
Контракт признан соответствующим архитектуре платформы.
---
# Documentation
В рамках Build обновлены:
- Build History;
- Runtime Contract;
- Engine Layer Architecture;
- Common Models Documentation.
---
# Acceptance
Build считается завершённым.
Выполнены:
- ✅ Architecture
- ✅ Architecture Review
- ✅ Architecture Decision (ADR)
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Documentation
- ✅ Acceptance
Статус Build:
**Accepted**
---
# Итоги Build
В результате Build 014.1:
- создан официальный контракт Engine Layer;
- Runtime получил стабильную точку зависимости;
- завершён фундамент для создания BaseEngine;
- архитектура стала полностью соответствовать принципу Dependency Inversion.
---
# Следующий Build
```text
Build 014.2
Engine Base
engine/base.py
```

View File

@@ -0,0 +1,272 @@
# Build 014.2 — Engine Base / BaseEngine
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 014.2 |
| Название | Engine Base / BaseEngine |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Engine |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Причина появления Build
После введения официального контракта `EngineProtocol` возникла необходимость определить единый жизненный цикл выполнения всех аналитических движков.
Без общего базового класса каждый Engine был бы вынужден самостоятельно реализовывать:
- обработку ошибок;
- проверку входного контекста;
- формирование служебной metadata;
- единый жизненный цикл анализа.
Это неизбежно привело бы к дублированию инфраструктурного кода и постепенному расхождению поведения различных Engine.
---
# Цель Build
Создать инфраструктурный базовый класс `BaseEngine`, который определяет единый жизненный цикл выполнения любого Engine, не включая аналитическую логику.
---
# Architecture
`BaseEngine` представляет собой инфраструктурный шаблон выполнения.
Он отвечает исключительно за организацию жизненного цикла Engine.
Общая модель выглядит следующим образом:
```text
analyze(context)
_validate_context(context)
_analyze_impl(context)
_normalize_result(result)
EngineResult
```
Публичной точкой входа является только метод:
```text
analyze(context)
```
Вся предметная аналитика выполняется исключительно внутри:
```text
_analyze_impl(context)
```
---
# Architecture Review
В ходе проверки подтверждено:
- BaseEngine не содержит аналитической логики;
- Runtime не переносится внутрь Engine;
- Coordinator не зависит от реализации Engine;
- Engine продолжают оставаться полностью независимыми;
- Metadata остаётся отделённой от аналитической логики;
- Runtime сможет использовать единый жизненный цикл всех Engine.
Архитектурное решение признано корректным.
---
# Architecture Decision (ADR)
## Решение
Принято использовать инфраструктурный базовый класс:
```text
BaseEngine
```
вместо минимального абстрактного класса.
## Статус
**Accepted**
## Обоснование
Платформа проектируется как система, включающая большое количество специализированных аналитических движков.
Общая инфраструктура должна быть реализована один раз и использоваться всеми Engine.
Это позволяет:
- устранить дублирование кода;
- унифицировать жизненный цикл выполнения;
- обеспечить одинаковое поведение всех Engine;
- уменьшить вероятность архитектурных расхождений.
## Последствия
После принятия решения:
- все Engine наследуются от BaseEngine;
- Runtime работает через единый жизненный цикл;
- аналитическая логика полностью остаётся в конкретных Engine;
- изменение инфраструктуры выполняется централизованно.
---
# Build Design
Создан файл:
```text
app/src/trading/market_intelligence/engine/base.py
```
Класс содержит только инфраструктурные механизмы.
В его состав входят:
- получение EngineMetadata;
- единый метод `analyze()`;
- базовая проверка входного контекста;
- защищённый метод `_analyze_impl()`;
- нормализация результата;
- безопасное формирование результата при ошибке.
---
# Implementation
Реализованы следующие элементы:
```text
BaseEngine
├── ENGINE_METADATA
├── get_metadata()
├── analyze()
├── _validate_context()
├── _analyze_impl()
├── _normalize_result()
└── _build_error_result()
```
Все методы снабжены комментариями на русском языке в соответствии со стандартом проекта.
---
# Compile Check
Проверка выполнена командой:
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
- успешно скомпилирован `engine/base.py`;
- успешно скомпилирован `engine/protocol.py`;
- отсутствуют синтаксические ошибки;
- отсутствуют циклические импорты;
- успешно компилируется весь пакет `market_intelligence`.
Дополнительно после Code Review внесено улучшение:
`EngineEvaluationMeta.calculated_at` теперь заполняется при нормализации результата и при формировании error-result.
Повторный Compile Check выполнен успешно.
**Статус:** ✅ Passed
---
# Domain Review
Проверено соответствие предметной области.
`BaseEngine`:
- не содержит аналитической логики;
- не принимает торговых решений;
- не взаимодействует с Runtime;
- не взаимодействует с Coordinator;
- не зависит от AutoTrade;
- не обращается к другим Engine;
- не содержит инфраструктуры Telegram, БД или API.
Класс полностью соответствует архитектурной роли инфраструктурной основы Engine Layer.
**Статус:** ✅ Passed
---
# Documentation
В рамках Build обновлены:
- Build History;
- Runtime Contract;
- Engine Layer Architecture.
---
# Acceptance
Build считается завершённым.
Выполнены:
- ✅ Architecture
- ✅ Architecture Review
- ✅ Architecture Decision (ADR)
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Documentation
- ✅ Acceptance
Статус Build:
**Accepted**
---
# Итоги Build
В результате Build 014.2:
- создан инфраструктурный базовый класс Engine Layer;
- определён единый жизненный цикл выполнения Engine;
- устранено дублирование общей инфраструктуры;
- подготовлена основа для реализации всех специализированных аналитических движков платформы.
---
# Следующий Build
```text
Build 014.3
Engine Exceptions
engine/exceptions.py
```

View File

@@ -0,0 +1,235 @@
# Build 014.3 — Engine Exceptions
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 014.3 |
| Название | Engine Exceptions |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Engine |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Причина появления Build
После реализации `EngineProtocol` и `BaseEngine` возникла необходимость стандартизировать обработку внутренних ошибок Engine Layer.
Использование стандартных исключений Python (`ValueError`, `NotImplementedError` и других) не отражало архитектурную модель платформы и затрудняло разделение инфраструктурных ошибок от штатных аналитических состояний.
Настоящий Build вводит единый набор внутренних исключений Engine Layer и интегрирует их в `BaseEngine`.
---
# Цель Build
Создать единый механизм внутренних исключений Engine Layer.
Исключения предназначены исключительно для обнаружения нарушений инфраструктурного жизненного цикла Engine и не являются частью внешнего Runtime Contract.
---
# Architecture
В Engine Layer вводится единая иерархия исключений.
```text
EngineError
├── EngineConfigurationError
├── EngineContractError
├── EngineContextError
└── EngineExecutionError
```
Все исключения используются исключительно внутри Engine Layer.
За пределы Engine Layer передаются только объекты `EngineResult`.
---
# Architecture Review
Проверка подтвердила соответствие архитектурным принципам проекта.
Подтверждено:
- Runtime не зависит от исключений Engine;
- Coordinator работает только с `EngineResult`;
- штатные аналитические состояния не оформляются через исключения;
- исключения используются исключительно для ошибок инфраструктуры Engine Layer;
- архитектурные зависимости остаются однонаправленными.
Архитектурное решение признано корректным.
---
# Architecture Decision (ADR)
## Решение
Ввести единый набор внутренних исключений Engine Layer.
## Статус
**Accepted**
## Обоснование
Исключения необходимы для описания нарушений жизненного цикла Engine:
- ошибок конфигурации;
- ошибок входного контекста;
- нарушений архитектурного контракта;
- внутренних ошибок реализации.
При этом исключения не являются способом передачи аналитического результата.
Внешним контрактом платформы остаётся исключительно `EngineResult`.
## Последствия
После принятия решения:
- BaseEngine использует специализированные исключения Engine Layer;
- Runtime не зависит от механизма исключений;
- Coordinator продолжает работать только через официальный Runtime Contract;
- архитектура сохраняет слабую связанность компонентов.
---
# Build Design
Создан файл:
```text
app/src/trading/market_intelligence/engine/exceptions.py
```
Также обновлён файл:
```text
app/src/trading/market_intelligence/engine/base.py
```
BaseEngine переведён на использование новых исключений.
---
# Implementation
Реализованы классы:
```text
EngineError
├── EngineConfigurationError
├── EngineContractError
├── EngineContextError
└── EngineExecutionError
```
В `BaseEngine` выполнены следующие изменения:
- отсутствие `ENGINE_METADATA` приводит к `EngineConfigurationError`;
- отсутствие обязательных полей `EngineContext` приводит к `EngineContextError`;
- возврат объекта, отличного от `EngineResult`, приводит к `EngineContractError`.
---
# Compile Check
Проверка выполнена командой:
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
- успешно скомпилирован `engine/exceptions.py`;
- успешно скомпилирован обновлённый `engine/base.py`;
- отсутствуют синтаксические ошибки;
- отсутствуют циклические зависимости.
После интеграции исключений выполнена повторная проверка компиляции.
**Статус:** ✅ Passed
---
# Domain Review
Проверено соответствие предметной области.
Подтверждено:
- исключения используются только внутри Engine Layer;
- внешний контракт остаётся `EngineResult`;
- штатные аналитические состояния не оформляются через исключения;
- ошибки контекста отделены от ошибок конфигурации и нарушений контракта;
- Runtime и Coordinator полностью изолированы от внутреннего механизма исключений.
**Статус:** ✅ Passed
---
# Documentation
В рамках Build обновлены:
- Build History;
- Engine Layer Architecture;
- документация Engine Base.
---
# Acceptance
Build считается завершённым.
Выполнены:
- ✅ Architecture
- ✅ Architecture Review
- ✅ Architecture Decision (ADR)
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Documentation
- ✅ Acceptance
Статус Build:
**Accepted**
---
# Итоги Build
В результате Build 014.3:
- создан единый механизм внутренних исключений Engine Layer;
- `BaseEngine` переведён на использование специализированных исключений;
- внешний Runtime Contract не изменился;
- архитектура стала более согласованной и подготовлена к появлению первых аналитических Engine.
---
# Следующий Build
```text
Build 015
Runtime Layer
runtime/protocol.py
```

View File

@@ -0,0 +1,237 @@
# Build 015.1 — Common Models Extension / RuntimeResult
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 015.1 |
| Название | Common Models Extension / RuntimeResult |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Common |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Причина появления Build
Во время проектирования `RuntimeProtocol` было установлено, что Runtime не может возвращать `EngineResult`.
`EngineResult` описывает результат выполнения одного Engine.
Runtime агрегирует результаты нескольких Engine, поэтому ему нужен собственный официальный результат выполнения.
---
# Цель Build
Добавить в Common Layer модель:
```text
RuntimeResult
```
`RuntimeResult` является единым контрактом результата выполнения Runtime Layer.
---
# Architecture
`RuntimeResult` агрегирует результаты нескольких Engine.
Модель не содержит аналитики, не принимает торговых решений и не зависит от конкретных Engine.
Основной источник истины:
```text
engine_results
```
Все производные данные вычисляются из него.
---
# Architecture Review
Проверка подтвердила:
- модель относится к Common Layer;
- RuntimeResult нужен Runtime, Coordinator, стратегиям, диагностике и тестам;
- производные данные не должны храниться отдельно;
- RuntimeResult не должен зависеть от Runtime-реализации.
Архитектура Build признана корректной.
---
# Architecture Decision (ADR)
## Решение
Добавить `RuntimeResult` в `common.models`.
## Статус
**Accepted**
## Обоснование
Runtime выполняет несколько Engine и должен возвращать агрегированный результат.
Размещение `RuntimeResult` в Common Layer сохраняет однонаправленные зависимости и позволяет использовать модель разными слоями платформы.
## Последствия
После принятия решения:
- Runtime сможет возвращать единый результат выполнения;
- Coordinator сможет работать с агрегированным контрактом;
- исключается дублирование списков выполненных и ошибочных Engine;
- RuntimeProtocol можно проектировать без временных моделей.
---
# Build Design
Модель добавлена в файл:
```text
app/src/trading/market_intelligence/common/models.py
```
Расположение:
```text
EngineResult
RuntimeResult
```
---
# Implementation
Реализованы хранимые поля:
```text
engine_results
diagnostics
started_at
finished_at
duration_ms
metadata
```
Реализованы вычисляемые свойства:
```text
successful_results
failed_results
partial_results
stale_results
executed_engines
failed_engines
successful_engines
has_errors
is_successful
total_engines
successful_count
```
---
# Compile Check
Проверка выполнена командой:
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
- успешно скомпилирован `common/models.py`;
- синтаксические ошибки отсутствуют;
- циклические зависимости отсутствуют.
**Статус:** ✅ Passed
---
# Domain Review
Проверено соответствие предметной области.
`RuntimeResult`:
- агрегирует результаты нескольких `EngineResult`;
- не содержит аналитической логики;
- не принимает торговых решений;
- не зависит от Runtime-реализации;
- не зависит от Coordinator;
- не зависит от конкретных Engine;
- производные данные вычисляются из `engine_results`.
**Статус:** ✅ Passed
---
# Documentation
В рамках Build должны быть обновлены:
- Build History;
- Runtime Contract;
- Common Models Documentation;
- будущая документация Runtime Layer.
---
# Acceptance
Build считается завершённым.
Выполнены:
- ✅ Architecture
- ✅ Architecture Review
- ✅ Architecture Decision (ADR)
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Documentation
- ✅ Acceptance
Статус Build:
**Accepted**
---
# Итоги Build
В результате Build 015.1:
- Common Layer получил модель `RuntimeResult`;
- Runtime Layer получил будущий выходной контракт;
- Coordinator сможет работать с агрегированным результатом Runtime;
- подготовлена основа для Build 015.2 — `runtime/protocol.py`.
---
# Следующий Build
```text
Build 015.2
Runtime Protocol
runtime/protocol.py
```

View File

@@ -0,0 +1,284 @@
# Build 015.2 — Runtime Protocol
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 015.2 |
| Название | Runtime Protocol |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Runtime |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Причина появления Build
После появления `RuntimeResult` стало возможно определить официальный контракт Runtime Layer.
Runtime должен взаимодействовать с аналитическими Engine через единый стабильный интерфейс и не зависеть от конкретных реализаций Engine.
---
# Цель Build
Создать файл:
```text
app/src/trading/market_intelligence/runtime/protocol.py
```
и определить в нём официальный контракт Runtime Layer.
---
# Architecture
`RuntimeProtocol` описывает только внешний интерфейс Runtime.
Runtime отвечает за:
- регистрацию Engine;
- удаление Engine;
- получение зарегистрированного Engine;
- выполнение анализа;
- возврат агрегированного `RuntimeResult`.
Runtime не отвечает за:
- аналитику;
- торговые решения;
- порядок стратегий;
- пользовательский интерфейс;
- работу с биржей;
- работу с БД;
- журналирование.
---
# Architecture Review
Проверка подтвердила:
- Runtime работает через `EngineProtocol`;
- Runtime регистрирует классы Engine, а не экземпляры;
- Runtime возвращает `RuntimeResult`;
- Runtime не знает конкретных Engine;
- Runtime не содержит аналитики;
- Runtime не содержит Coordinator-логики;
- AutoTrade не изменяется.
Архитектура Build признана корректной.
---
# Architecture Decision (ADR)
## Решение
Runtime Layer регистрирует классы Engine, а не экземпляры Engine.
Официальный контракт:
```python
register_engine(
engine_type: type[EngineProtocol],
) -> None
```
## Статус
**Accepted**
## Обоснование
`EngineMetadata` доступна без создания экземпляра Engine через `get_metadata()`.
Поэтому Runtime не обязан создавать объект Engine на этапе регистрации.
Регистрация класса позволяет Runtime самостоятельно управлять жизненным циклом экземпляров Engine.
## Обязательное правило
Все Engine обязаны иметь конструктор без пользовательских параметров.
Всё изменяемое состояние и конфигурация анализа передаются через:
```text
EngineContext
```
## Запрещено
```python
register_engine(engine: EngineProtocol)
```
Регистрация экземпляров Engine запрещена.
## Последствия
После принятия решения:
- Runtime контролирует жизненный цикл Engine;
- Engine не сохраняют состояние между запусками;
- Runtime готов к параллельному выполнению;
- Registry сможет хранить типы Engine;
- добавление новых Engine не требует изменения Runtime.
---
# Build Design
Реализуется контракт:
```text
RuntimeProtocol
├── register_engine(engine_type)
├── unregister_engine(engine_name)
├── get_engine(engine_name)
└── analyze(context)
```
Файл не содержит реализации Runtime.
---
# Implementation
Реализован файл:
```text
app/src/trading/market_intelligence/runtime/protocol.py
```
Содержимое контракта:
```python
class RuntimeProtocol(Protocol):
def register_engine(
self,
engine_type: type[EngineProtocol],
) -> None:
...
def unregister_engine(
self,
engine_name: EngineName,
) -> None:
...
def get_engine(
self,
engine_name: EngineName,
) -> type[EngineProtocol] | None:
...
async def analyze(
self,
context: EngineContext,
) -> RuntimeResult:
...
```
---
# Compile Check
Проверка выполнена командой:
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
- успешно скомпилирован `runtime/protocol.py`;
- синтаксические ошибки отсутствуют;
- циклические зависимости отсутствуют.
**Статус:** ✅ Passed
---
# Domain Review
Проверено соответствие предметной области.
`RuntimeProtocol`:
- работает через `EngineProtocol`;
- регистрирует классы Engine;
- возвращает `RuntimeResult`;
- не знает конкретных Engine;
- не содержит аналитики;
- не содержит Coordinator-логики;
- не зависит от AutoTrade;
- не обращается к бирже, БД, Telegram или EventBus;
- получает изменяемые данные анализа только через `EngineContext`.
**Статус:** ✅ Passed
---
# Documentation
В рамках Build должны быть обновлены:
- Build History;
- Runtime Contract;
- Engine Layer Architecture;
- Runtime Architecture.
---
# Acceptance
Build считается завершённым.
Выполнены:
- ✅ Architecture
- ✅ Architecture Review
- ✅ Architecture Decision (ADR)
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Documentation
- ✅ Acceptance
Статус Build:
**Accepted**
---
# Итоги Build
В результате Build 015.2:
- создан официальный контракт Runtime Layer;
- Runtime получил стабильную зависимость от `EngineProtocol`;
- закреплена регистрация классов Engine вместо экземпляров;
- Runtime возвращает агрегированный `RuntimeResult`;
- подготовлена основа для реализации Runtime Registry.
---
# Следующий Build
```text
Build 015.3
Runtime Registry
runtime/registry.py
```

View File

@@ -0,0 +1,296 @@
# Build 015.3 — Common Models Extension / EngineRegistration
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 015.3 |
| Название | Common Models Extension / EngineRegistration |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Common |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Причина появления Build
Во время проектирования `RuntimeRegistry` было установлено, что хранение только класса Engine недостаточно.
Runtime Registry постоянно работает с двумя сущностями:
- типом Engine;
- его Metadata.
Постоянный вызов `Engine.get_metadata()` привёл бы к дублированию логики и усложнил бы реализацию Registry.
Для устранения этой проблемы введена единая модель регистрации Engine.
---
# Цель Build
Добавить в Common Layer новую фундаментальную модель:
```text
EngineRegistration
```
Модель описывает зарегистрированный аналитический движок и является единицей хранения Runtime Registry.
---
# Architecture
`EngineRegistration` представляет собой атомарную запись регистрации Engine.
Модель не является:
- Engine;
- Runtime;
- Registry;
- Runtime Contract.
Это исключительно модель Common Layer.
---
# Architecture Review
Проверка подтвердила:
- модель относится к Common Layer;
- Runtime Registry использует одну запись регистрации вместо двух независимых сущностей;
- отсутствует дублирование Metadata;
- сохраняется разделение Metadata и Logic;
- сохраняется однонаправленная архитектура зависимостей.
Архитектура Build признана корректной.
---
# Architecture Decision (ADR)
## Решение
Добавить модель:
```text
EngineRegistration
```
в `common.models`.
## Статус
**Accepted**
## Обоснование
Во время проектирования Runtime Registry подтверждено, что регистрация Engine является самостоятельной архитектурной сущностью.
Модель объединяет:
- тип Engine;
- его Metadata.
При этом сама Metadata остаётся единственным источником информации об Engine.
## Главное правило
`EngineRegistration` не должен дублировать информацию, уже содержащуюся в `EngineMetadata`.
Запрещается добавлять отдельные поля:
```text
engine_name
engine_version
dependencies
priority
enabled_by_default
registered_at
```
## Последствия
После принятия решения:
- Runtime Registry сможет хранить атомарные записи регистрации;
- Metadata будет доступна без обращения к классу Engine;
- Runtime сохранит контроль над жизненным циклом Engine;
- модель регистрации останется независимой от Runtime-состояния.
---
# Build Design
В файл
```text
app/src/trading/market_intelligence/common/models.py
```
добавлены:
```text
EngineTypeProtocol
EngineRegistration
```
`EngineTypeProtocol` используется как минимальный контракт класса Engine и позволяет избежать запрещённой зависимости:
```text
Common → Engine
```
---
# Implementation
Реализованы:
```text
EngineTypeProtocol
```
```text
EngineRegistration
```
Состав модели:
```text
EngineRegistration
├── engine_type
└── metadata
```
Модель не содержит дополнительных полей.
---
# Compile Check
Проверка выполнена командой:
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
- успешно скомпилирован `common/models.py`;
- синтаксические ошибки отсутствуют;
- циклические зависимости отсутствуют.
**Статус:** ✅ Passed
---
# Domain Review
Проверено соответствие предметной области.
Подтверждено:
- `EngineRegistration` описывает регистрацию Engine, а не сам Engine;
- модель не содержит аналитической логики;
- модель не содержит Runtime-состояния;
- `EngineRegistration` не дублирует данные из `EngineMetadata`;
- Common Layer не импортирует `EngineProtocol`;
- Runtime Registry сможет использовать `EngineRegistration` как единую запись регистрации.
**Статус:** ✅ Passed
---
# Documentation
В рамках Build должны быть обновлены:
- Build History;
- Runtime Architecture;
- Engine Layer Architecture;
- Common Models Documentation.
---
# Acceptance
Build считается завершённым.
Выполнены:
- ✅ Architecture
- ✅ Architecture Review
- ✅ Architecture Decision (ADR)
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Documentation
- ✅ Acceptance
Статус Build:
**Accepted**
---
# Итоги Build
В результате Build 015.3:
- Common Layer получил модель `EngineRegistration`;
- Runtime Registry получил единицу хранения зарегистрированных Engine;
- устранено дублирование вызовов `Engine.get_metadata()`;
- сохранён принцип единственного источника истины;
- сохранена однонаправленная архитектура зависимостей между слоями.
---
# Архитектурные принципы, закреплённые Build
В рамках Build официально закреплены следующие правила.
### EngineRegistration не дублирует Metadata
Если информация уже содержится в `EngineMetadata`, она не должна повторяться в `EngineRegistration`.
### Один источник истины
Описание Engine хранится исключительно в `EngineMetadata`.
`EngineRegistration` только связывает тип Engine с его Metadata.
### Common Layer не зависит от Engine Layer
Для хранения типа Engine используется минимальный локальный протокол:
```text
EngineTypeProtocol
```
Это позволяет избежать запрещённой зависимости:
```text
Common → Engine
```
---
# Следующий Build
```text
Build 015.4
Runtime Registry
runtime/registry.py
```

View File

@@ -0,0 +1,360 @@
# Build 015.4 — Runtime Registry
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 015.4 |
| Название | Runtime Registry |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Runtime |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Причина появления Build
После завершения Build:
- 015.1 (`RuntimeResult`);
- 015.2 (`RuntimeProtocol`);
- 015.3 (`EngineRegistration`);
Runtime получил все необходимые фундаментальные модели для реализации первого инфраструктурного компонента Runtime Layer.
Таким компонентом стал `RuntimeRegistry`.
---
# Цель Build
Создать каталог зарегистрированных аналитических Engine.
Registry является единым источником информации о зарегистрированных Engine и предоставляет минимальный API регистрации.
---
# Architecture
`RuntimeRegistry` отвечает исключительно за регистрацию аналитических Engine.
Registry не выполняет анализ рынка.
Registry не создаёт `EngineContext`.
Registry не запускает Engine.
Registry не агрегирует результаты.
Registry не управляет Coordinator.
Единственная ответственность Registry — управление зарегистрированными Engine.
---
# Architecture Review
Проверка подтвердила:
- Registry соответствует принципу Single Responsibility;
- Registry использует `EngineRegistration`;
- Registry не содержит аналитики;
- Registry не зависит от Coordinator;
- Registry не зависит от AutoTrade;
- Registry не создаёт `EngineContext`;
- Registry не запускает Engine.
Архитектура Build признана корректной.
---
# Architecture Decision (ADR)
## Решение
Добавить компонент:
```text
RuntimeRegistry
```
в Runtime Layer.
## Статус
**Accepted**
## Обоснование
Runtime должен иметь единый каталог зарегистрированных Engine.
Registry хранит записи регистрации и предоставляет к ним доступ другим компонентам Runtime.
Для хранения используется модель:
```text
EngineRegistration
```
## Утверждённая модель хранения
```python
dict[
EngineName,
EngineRegistration,
]
```
## Публичный API
```text
register()
unregister()
get()
contains()
list()
clear()
```
## Запрещено
Registry не должен содержать:
```text
analyze()
run()
execute()
resolve_dependencies()
validate()
build_graph()
sort()
```
## Последствия
После принятия решения:
- Runtime получил единый каталог Engine;
- Registry остаётся независимым от аналитики;
- RuntimeRunner сможет использовать Registry;
- DependencyResolver сможет использовать Registry;
- добавление новых Engine не требует изменения Runtime.
---
# Build Design
Создан файл:
```text
app/src/trading/market_intelligence/runtime/registry.py
```
Внутренний каталог Registry:
```python
self._engines: dict[
EngineName,
EngineRegistration,
]
```
При регистрации Registry самостоятельно создаёт:
```text
EngineRegistration
```
через:
```python
engine_type.get_metadata()
```
Дополнительная фабрика регистрации не используется.
---
# Implementation
Реализован компонент:
```text
RuntimeRegistry
```
Публичный интерфейс:
```text
register()
unregister()
get()
contains()
list()
clear()
```
Registry использует:
```text
EngineRegistration
```
как единственную единицу хранения зарегистрированных Engine.
---
# Compile Check
Проверка выполнена командой:
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
- успешно скомпилирован `runtime/registry.py`;
- синтаксические ошибки отсутствуют;
- циклические зависимости отсутствуют.
**Статус:** ✅ Passed
---
# Domain Review
Проверено соответствие предметной области.
Подтверждено:
- Registry хранит только зарегистрированные Engine;
- Registry использует `EngineRegistration`;
- Registry не содержит аналитики;
- Registry не управляет выполнением Engine;
- Registry не создаёт `EngineContext`;
- Registry не формирует `RuntimeResult`;
- Registry не знает Coordinator;
- Registry не зависит от AutoTrade;
- Registry не обращается к бирже, БД, Telegram или EventBus.
**Статус:** ✅ Passed
---
# Documentation
В рамках Build должны быть обновлены:
- Build History;
- Runtime Architecture;
- Runtime Contract;
- Runtime Layer Documentation.
---
# Acceptance
Build считается завершённым.
Выполнены:
- ✅ Architecture
- ✅ Architecture Review
- ✅ Architecture Decision (ADR)
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Documentation
- ✅ Acceptance
Статус Build:
**Accepted**
---
# Итоги Build
В результате Build 015.4:
- Runtime Layer получил первый инфраструктурный компонент;
- появился единый каталог зарегистрированных Engine;
- Runtime получил единый механизм регистрации аналитических движков;
- Registry использует `EngineRegistration` как атомарную запись;
- подготовлена основа для реализации Runtime Runner.
---
# Архитектурные принципы, закреплённые Build
## Registry отвечает только за регистрацию
`RuntimeRegistry` не выполняет анализ и не управляет выполнением Engine.
Единственная ответственность Registry — управление каталогом зарегистрированных Engine.
---
## EngineRegistration является единицей хранения
Внутри Registry хранится исключительно:
```text
EngineRegistration
```
Хранение отдельных `EngineType` или `EngineMetadata` запрещено.
---
## Runtime самостоятельно создаёт регистрацию
Во время регистрации Registry самостоятельно получает Metadata:
```python
metadata = engine_type.get_metadata()
```
и создаёт:
```text
EngineRegistration
```
Отдельная фабрика регистрации не вводится.
---
## Registry не содержит эксплуатационной логики
Registry не выполняет:
- анализ;
- запуск Engine;
- сортировку;
- разрешение зависимостей;
- построение графов;
- валидацию.
Все перечисленные обязанности относятся к другим компонентам Runtime Layer.
---
# Следующий Build
```text
Build 015.5
Runtime Runner
runtime/runner.py
```

View File

@@ -0,0 +1,275 @@
# Build 015.5 — Runtime Core
**Build Documentation**
---
# Контроль Build
| Свойство | Значение |
|----------|-----------|
| Build | 015.5 |
| Название | Runtime Core |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Проект | Dzentra |
| Тип | Architecture Build |
| Версия | 1.0 |
---
# Цель Build
Завершить формирование базовой инфраструктуры Runtime Layer, реализовав компоненты, необходимые для регистрации аналитических Engine, их безопасного выполнения и обработки внутренних ошибок Runtime.
Build завершает минимальное ядро Runtime перед переходом к разработке Coordinator Layer.
---
# Архитектурная задача
До начала Build Runtime уже содержал:
- Runtime Protocol;
- Runtime Models;
- Runtime Registry.
Отсутствовали компоненты, отвечающие за непосредственное выполнение зарегистрированного Engine и унифицированную модель внутренних исключений Runtime.
Настоящий Build реализует данные компоненты без изменения существующих Runtime Contract.
---
# Архитектурное решение
В рамках Build реализованы два самостоятельных компонента Runtime Layer.
## Runtime Runner
`RuntimeRunner` отвечает исключительно за выполнение одного зарегистрированного Engine.
Ответственность Runner ограничивается:
- созданием экземпляра Engine;
- передачей Runtime Context;
- получением Engine Result.
Runner не содержит:
- логики анализа рынка;
- управления последовательностью выполнения Engine;
- агрегации результатов;
- обработки зависимостей;
- координации Runtime.
---
## Runtime Exceptions
Создан единый набор специализированных исключений Runtime.
Исключения предназначены исключительно для внутренней инфраструктуры Runtime Layer.
Реализованы:
- RuntimeError;
- EngineNotRegisteredError;
- InvalidRuntimeContextError;
- EngineExecutionError.
Наличие собственного пространства исключений исключает использование необобщённых Exception внутри Runtime.
---
# Реализованные файлы
Добавлены:
```text
runtime/exceptions.py
runtime/runner.py
```
Использован существующий компонент:
```text
runtime/registry.py
```
Изменён:
```text
common/models.py
```
В `EngineTypeProtocol` добавлен метод:
```python
analyze(context) -> EngineResult
```
Данное изменение устраняет расхождение между Runtime Registry и Runtime Runner и обеспечивает корректную статическую типизацию без изменения архитектурного контракта Runtime.
---
# Архитектурные зависимости
Build не изменяет существующую модель зависимостей.
Итоговая структура Runtime Layer:
```text
Runtime Layer
├── protocol.py
├── registry.py
├── runner.py
└── exceptions.py
```
Зависимости остаются однонаправленными.
```text
RuntimeRunner
EngineRegistration
EngineProtocol
```
Runtime по-прежнему не зависит от Coordinator и не содержит предметной логики.
---
# Runtime Contract
Build не изменяет:
- Runtime Context;
- Engine Result;
- Runtime Status;
- Runtime Events;
- Runtime Models;
- Runtime Contract.
Все существующие Runtime Contract остаются полностью совместимыми.
---
# Engineering Review
## Architecture Review
Passed.
Компоненты имеют единственную область ответственности.
---
## Dependency Review
Passed.
Циклические зависимости отсутствуют.
Направление зависимостей соответствует утверждённой архитектуре.
---
## Runtime Review
Passed.
Runtime остаётся инфраструктурным уровнем.
Runtime не содержит аналитической или торговой логики.
---
## Code Review
Passed.
Код соответствует принципам:
- Single Responsibility Principle;
- One Source of Truth;
- Stable Foundation;
- Architecture First.
Во время проверки обнаружено частичное дублирование контрактов `EngineProtocol` и `EngineTypeProtocol`.
Для обеспечения корректной статической типизации в `EngineTypeProtocol` добавлен метод `analyze()`.
Архитектурное объединение контрактов признано отдельной задачей и не входит в настоящий Build.
---
## Compile Review
Passed.
Проверка выполнена командой:
```bash
python -m compileall src/trading/market_intelligence
```
Ошибок компиляции не обнаружено.
---
# Изменённые документы
Обновление Runtime Contract не потребовалось.
Настоящий Build документирует исключительно развитие Runtime Layer.
---
# Итоговое состояние Runtime
После завершения Build Runtime Layer имеет следующий состав.
```text
runtime/
├── protocol.py
├── registry.py
├── runner.py
├── exceptions.py
```
Runtime Layer полностью готов к реализации Coordinator Layer.
---
# Следующий Build
Следующим этапом развития платформы является:
> **Build 016 — Coordinator Core**
Coordinator станет первым компонентом, использующим Runtime Registry и Runtime Runner для выполнения полного набора зарегистрированных аналитических Engine.
---
# Итог
Build 015.5 полностью завершает формирование базовой инфраструктуры Runtime Layer.
Все поставленные архитектурные задачи выполнены.
Build успешно прошёл:
- Architecture Review;
- Dependency Review;
- Runtime Review;
- Code Review;
- Compile Review.
Build получает статус:
> **Accepted**

View File

@@ -0,0 +1,265 @@
# Build 015.6 — Runtime Dependencies
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 015.6 |
| Название | Runtime Dependencies |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Runtime |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Причина появления Build
После реализации `RuntimeRegistry` и `RuntimeRunner` Runtime Layer получил возможность хранить и выполнять зарегистрированные Engine.
Однако порядок выполнения Engine должен учитывать зависимости, объявленные в `EngineMetadata`.
Для этого необходим отдельный компонент Runtime Layer, отвечающий только за разрешение зависимостей.
---
# Цель Build
Создать компонент:
```text
RuntimeDependencies
```
который определяет корректный порядок выполнения зарегистрированных Engine на основании их обязательных зависимостей.
---
# Architecture
`RuntimeDependencies` получает:
```text
tuple[EngineRegistration, ...]
```
и возвращает:
```text
tuple[EngineRegistration, ...]
```
в порядке выполнения.
Компонент не создаёт Engine, не запускает Engine, не формирует результаты и не зависит от Coordinator.
---
# Architecture Review
Проверка подтвердила:
- Engine остаются независимыми;
- зависимости объявляются через `EngineMetadata`;
- Runtime не содержит аналитики;
- Runner не смешивается с Dependency Resolver;
- Registry не строит граф зависимостей;
- Coordinator пока не реализуется.
**Статус:** ✅ Passed
---
# Architecture Decision (ADR)
## Решение
В Runtime Layer вводится компонент:
```text
RuntimeDependencies
```
## Статус
**Accepted**
## Обоснование
Engine могут объявлять обязательные зависимости через:
```text
EngineMetadata.required_dependencies
```
Runtime должен определить порядок выполнения Engine до запуска анализа.
Эта ответственность не относится к Registry, Runner, Coordinator или конкретным Engine.
---
# Build Design
Создан файл:
```text
app/src/trading/market_intelligence/runtime/dependencies.py
```
Обновлён файл:
```text
app/src/trading/market_intelligence/runtime/exceptions.py
```
---
# Implementation
Реализован класс:
```text
RuntimeDependencies
```
Публичный API:
```text
resolve(registrations)
```
Внутренние этапы:
```text
_build_registration_map()
_build_graph()
_validate_dependencies()
_topological_sort()
_visit()
```
Добавлены Runtime-исключения:
```text
MissingEngineDependencyError
CircularEngineDependencyError
```
---
# Compile Check
Проверка выполнена командой:
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
- успешно скомпилирован `runtime/dependencies.py`;
- успешно скомпилирован `runtime/exceptions.py`;
- синтаксические ошибки отсутствуют;
- циклические зависимости отсутствуют.
**Статус:** ✅ Passed
---
# Domain Review
Проверено соответствие предметной области.
`RuntimeDependencies`:
- работает только с зарегистрированными Engine;
- берёт зависимости исключительно из `EngineMetadata.required_dependencies`;
- не создаёт экземпляры Engine;
- не запускает Engine;
- не формирует `EngineResult` или `RuntimeResult`;
- не зависит от Coordinator;
- не добавляет аналитической логики.
**Статус:** ✅ Passed
---
# Code Review / Runtime Review
Проверка пройдена.
Подтверждено:
- компонент имеет одну ответственность;
- отсутствующие обязательные зависимости обрабатываются отдельной ошибкой;
- циклические зависимости обрабатываются отдельной ошибкой;
- топологическая сортировка возвращает корректный порядок выполнения;
- зависимости между слоями не нарушены.
**Статус:** ✅ Passed
---
# Documentation
В рамках Build должны быть обновлены:
- Build History;
- Runtime Architecture;
- Runtime Layer Documentation.
Runtime Contract не изменяется.
---
# Acceptance
Build считается завершённым.
Выполнены:
- ✅ Architecture
- ✅ Architecture Review
- ✅ Architecture Decision
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Code Review
- ✅ Runtime Review
- ✅ Documentation
- ✅ Acceptance
Статус Build:
**Accepted**
---
# Итоги Build
В результате Build 015.6:
- Runtime Layer получил механизм разрешения зависимостей;
- порядок выполнения Engine теперь может быть построен из `EngineMetadata`;
- Engine остаются независимыми и не обращаются друг к другу напрямую;
- Registry, Runner и Dependency Resolver имеют разные зоны ответственности;
- Runtime Layer стал готов к следующему этапу — Runtime Validation или Coordinator Core.
---
# Следующий Build
```text
Build 015.7
Runtime Validation
runtime/validation.py
```

View File

@@ -0,0 +1,280 @@
# Build 015.7 — Runtime Validation
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 015.7 |
| Название | Runtime Validation |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Runtime |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Причина появления Build
После реализации компонентов:
- Runtime Registry;
- Runtime Runner;
- Runtime Dependencies;
Runtime Layer получил возможность хранить зарегистрированные Engine, определять порядок их выполнения и запускать анализ.
Однако отсутствовала единая точка проверки корректности Runtime перед началом выполнения.
Проверка конфигурации Runtime должна выполняться централизованно и до запуска любого Engine.
---
# Цель Build
Создать компонент:
```text
RuntimeValidation
```
который подтверждает готовность Runtime Layer к выполнению анализа.
---
# Architecture
`RuntimeValidation` получает:
```text
RuntimeRegistry
```
и выполняет проверку корректности зарегистрированных Engine.
Компонент:
- не создаёт Engine;
- не запускает Engine;
- не изменяет Registry;
- не выполняет анализ рынка;
- не строит граф зависимостей самостоятельно.
Проверка зависимостей делегируется компоненту:
```text
RuntimeDependencies
```
---
# Architecture Review
Подтверждено:
- RuntimeValidation имеет единственную ответственность;
- проверки отделены от Registry и Runner;
- RuntimeDependencies используется повторно без дублирования логики;
- Coordinator не участвует в проверке Runtime;
- архитектурные зависимости соответствуют утверждённой модели Runtime Layer.
**Статус:** ✅ Passed
---
# Architecture Decision (ADR)
## Решение
В Runtime Layer вводится новый инфраструктурный компонент:
```text
RuntimeValidation
```
## Статус
**Accepted**
## Обоснование
Runtime должен гарантировать собственную корректность до запуска первого Engine.
Для этого необходим отдельный компонент, который централизует все проверки конфигурации Runtime.
Проверка зависимостей выполняется посредством использования уже существующего `RuntimeDependencies`.
Это сохраняет принцип единственной ответственности и предотвращает дублирование логики.
---
# Build Design
Создан файл:
```text
app/src/trading/market_intelligence/runtime/validation.py
```
Обновлён файл:
```text
app/src/trading/market_intelligence/runtime/exceptions.py
```
---
# Implementation
Реализован класс:
```text
RuntimeValidation
```
Публичный интерфейс:
```text
validate(registry)
```
Во время проверки выполняются следующие этапы:
```text
_validate_registry()
_validate_metadata()
_validate_duplicates()
RuntimeDependencies.resolve()
```
Добавлены новые исключения Runtime Validation:
```text
RuntimeValidationError
EmptyRuntimeRegistryError
DuplicateEngineRegistrationError
InvalidEngineMetadataError
```
---
# Compile Check
Проверка выполнена командой:
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
- успешно скомпилирован `runtime/validation.py`;
- успешно обновлён `runtime/exceptions.py`;
- синтаксические ошибки отсутствуют.
**Статус:** ✅ Passed
---
# Domain Review
Проверено соответствие предметной области.
Подтверждено:
- RuntimeValidation проверяет только готовность Runtime;
- Engine не создаются;
- Engine не запускаются;
- Registry не изменяется;
- RuntimeResult не формируется;
- аналитическая логика отсутствует;
- проверка зависимостей делегирована RuntimeDependencies.
**Статус:** ✅ Passed
---
# Code Review / Runtime Review
Проверка успешно завершена.
Подтверждено:
- компонент имеет единственную ответственность;
- отсутствует дублирование проверки зависимостей;
- используется существующий RuntimeDependencies;
- корректно проверяются обязательные поля Metadata;
- иерархия Runtime-исключений расширена без нарушения существующей структуры.
Во время Code Review также подтверждено, что проверка повторной регистрации Engine в текущей реализации практически недостижима из-за использования словаря в `RuntimeRegistry`. Тем не менее данная проверка сохранена как часть публичного контракта `RuntimeValidation`, что обеспечивает устойчивость архитектуры при возможном изменении внутренней реализации Registry.
**Статус:** ✅ Passed
---
# Documentation
В рамках Build должны быть обновлены:
- Build History;
- Runtime Architecture;
- Runtime Layer Documentation.
Runtime Contract не изменяется.
---
# Acceptance
Build считается завершённым.
Выполнены:
- ✅ Development Strategy
- ✅ Architecture Design
- ✅ Architecture Review
- ✅ Architecture Decision
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Code Review
- ✅ Runtime Review
- ✅ Documentation
- ✅ Acceptance
Статус Build:
**Accepted**
---
# Итоги Build
В результате Build 015.7 Runtime Layer получил централизованный механизм проверки собственной корректности.
Теперь Runtime способен:
- проверять наличие зарегистрированных Engine;
- проверять обязательные поля Metadata;
- использовать RuntimeDependencies для проверки зависимостей;
- подтверждать готовность Runtime до начала выполнения анализа.
После завершения Build 015.7 базовая инфраструктура Runtime Layer сформирована полностью.
---
# Следующий Build
```text
Build 015.8
Runtime Service
runtime/service.py
```

View File

@@ -0,0 +1,226 @@
# Build 015.8 — Runtime Layer / Runtime Service
**Статус:** ✅ Accepted
---
# Цель Build
Завершить построение базовой инфраструктуры Runtime Layer путём введения единой публичной точки входа — `RuntimeService`.
Build объединяет ранее реализованные компоненты Runtime в единый жизненный цикл выполнения, не нарушая принцип единственной ответственности.
---
# Архитектурная задача
До Build 015.8 Runtime Layer уже содержал:
- Runtime Registry;
- Runtime Validation;
- Runtime Dependencies;
- Runtime Runner.
Однако отсутствовал компонент, объединяющий их в единый процесс выполнения.
Build 015.8 завершает базовую архитектуру Runtime Layer введением Runtime Service.
---
# Реализованные компоненты
```text
runtime/
protocol.py
registry.py
validation.py
dependencies.py
runner.py
service.py
exceptions.py
```
---
# Реализовано
Создан новый компонент:
```text
RuntimeService
```
Runtime Service предоставляет единый публичный API Runtime Layer.
Поддерживаются операции:
- регистрация Engine;
- удаление Engine;
- получение регистрации Engine;
- выполнение полного Runtime Pipeline.
---
# Архитектура выполнения
Во время выполнения Runtime Service использует существующие компоненты Runtime.
```text
RuntimeRegistry
RuntimeValidation
RuntimeDependencies
RuntimeRunner
RuntimeResult
```
Каждый компонент сохраняет собственную область ответственности.
---
# Ответственность Runtime Service
Runtime Service отвечает исключительно за координацию жизненного цикла Runtime.
Он:
- не содержит аналитики;
- не реализует алгоритмы Engine;
- не принимает торговых решений;
- не интерпретирует результаты анализа;
- не содержит собственной логики проверки зависимостей;
- не содержит собственной логики запуска Engine.
Все специализированные задачи делегируются соответствующим Runtime-компонентам.
---
# Публичный API
Реализован следующий публичный интерфейс:
```python
register_engine(...)
unregister_engine(...)
get_engine(...)
analyze(...)
```
Метод `analyze()` возвращает единый объект `RuntimeResult`.
---
# Runtime Pipeline
Во время анализа Runtime выполняет следующие этапы:
```text
Registry
Validation
Dependency Resolution
Engine Runner
RuntimeResult
```
Таким образом Runtime Layer получил полностью определённый жизненный цикл выполнения.
---
# Архитектурные результаты
Build завершил построение публичного фасада Runtime Layer.
После реализации:
- Coordinator больше не должен использовать внутренние Runtime-компоненты напрямую;
- Runtime Layer имеет единственную официальную точку входа;
- детали реализации Runtime полностью инкапсулированы;
- дальнейшее развитие Runtime возможно без изменения внешнего контракта.
---
# Engineering Review
## Architecture Review
Passed.
Runtime Service реализует исключительно координацию компонентов Runtime и не нарушает архитектурные границы.
---
## Domain Review
Passed.
Runtime остаётся инфраструктурным слоем и не содержит аналитической либо торговой логики.
---
## Code Review
Passed.
Выявлено:
- отсутствует дублирование логики;
- отсутствуют циклические зависимости;
- соблюдён принцип единственной ответственности;
- все существующие Runtime-компоненты используются повторно.
---
## Runtime Review
Passed.
Жизненный цикл Runtime полностью соответствует ранее утверждённому Runtime Protocol.
---
# ADR
В рамках Build принято следующее архитектурное решение.
> Runtime Service является единственной публичной точкой входа Runtime Layer.
Внутренние компоненты Runtime (`Registry`, `Validation`, `Dependencies`, `Runner`) рассматриваются как детали реализации и не используются внешними слоями напрямую.
---
# Compile Check
```text
python -m compileall src/trading/market_intelligence
```
Результат:
```text
Passed
```
---
# Итог
Build 015.8 завершил построение базового Runtime Layer.
После завершения Build Runtime включает:
- Runtime Protocol;
- Runtime Registry;
- Runtime Runner;
- Runtime Dependencies;
- Runtime Validation;
- Runtime Service.
Runtime Layer готов к переходу к следующему этапу развития архитектуры — Coordinator Layer.

View File

@@ -0,0 +1,192 @@
# Build 016.1 — Coordinator Models / CoordinatorResult
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 016.1 |
| Название | Coordinator Models / CoordinatorResult |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Common / Coordinator Contract |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Цель Build
Добавить базовые модели результата Coordinator Layer.
Основной результат Build:
```text
CoordinatorResult
```
---
# Причина появления Build
После утверждения архитектуры Coordinator Layer потребовался официальный выходной контракт Coordinator.
`CoordinatorResult` является межслойной моделью:
```text
RuntimeResult
Coordinator
CoordinatorResult
Trading Layer
```
Поэтому модель размещена в Common Layer.
---
# Реализованные модели
В файл:
```text
app/src/trading/market_intelligence/common/models.py
```
добавлены:
```text
CoordinatorDiagnostics
CoordinatorEvaluationMeta
CoordinatorResult
```
---
# Architecture Review
Проверка подтвердила:
- модели корректно размещены в Common Layer;
- `CoordinatorResult` не является торговым решением;
- `CoordinatorResult` не зависит от реализации Coordinator;
- `RuntimeResult` остаётся входом Coordinator;
- `EngineResult` и `RuntimeResult` не изменяются.
**Статус:** ✅ Passed
---
# ADR
Принято решение добавить модели результата Coordinator в Common Layer, так как `CoordinatorResult` является межслойным контрактом между Coordinator Layer и будущим Trading Layer.
**Статус:** Accepted
---
# Implementation
Добавлены модели:
```text
CoordinatorDiagnostics
CoordinatorEvaluationMeta
CoordinatorResult
```
`CoordinatorResult` содержит:
- `runtime_result`;
- `diagnostics`;
- `meta`;
- `payload`;
- `status`;
- `score`;
- `confidence`;
- `reason`;
- `direction`;
- `bias`;
- `phase`;
- `regime`;
- `risk_level`.
---
# Compile Check
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
```text
Passed
```
---
# Domain Review
Подтверждено:
- `CoordinatorResult` является итоговой аналитической интерпретацией `RuntimeResult`;
- модель не содержит торгового решения;
- модель не содержит логики запуска Engine;
- модель не содержит правил Coordinator;
- будущий Trading Layer сможет использовать `CoordinatorResult` как контракт.
**Статус:** ✅ Passed
---
# Code Review
Проверка пройдена.
Замечаний, блокирующих Build, нет.
**Статус:** ✅ Passed
---
# Acceptance
Build завершён.
Выполнены:
- ✅ Architecture Design
- ✅ Architecture Review
- ✅ ADR
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Code Review
- ✅ Documentation
Статус Build:
```text
Accepted
```
---
# Следующий Build
```text
Build 016.2
Coordinator Protocol
coordinator/protocol.py
```

View File

@@ -0,0 +1,189 @@
# Build 016.2 — Coordinator Protocol
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 016.2 |
| Название | Coordinator Protocol |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Coordinator |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Цель Build
Создать официальный публичный контракт Coordinator Layer.
---
# Причина появления Build
После появления модели `CoordinatorResult` Coordinator Layer должен получить стабильный интерфейс взаимодействия.
Контракт Coordinator определяет единственную модель взаимодействия:
```text
RuntimeResult
Coordinator
CoordinatorResult
```
---
# Architecture
`CoordinatorProtocol` описывает только внешний интерфейс Coordinator.
Он не содержит:
- реализации;
- правил согласования;
- валидации;
- исключений;
- торговой логики;
- зависимостей от конкретных Engine;
- зависимостей от внутренних компонентов Runtime.
---
# Architecture Review
Проверка подтвердила:
- Coordinator получает только `RuntimeResult`;
- Coordinator возвращает только `CoordinatorResult`;
- контракт не содержит реализации;
- контракт не зависит от внутренних компонентов Runtime;
- контракт не зависит от конкретных Engine;
- контракт не содержит торговой логики.
**Статус:** ✅ Passed
---
# ADR
Принято решение добавить официальный контракт:
```text
CoordinatorProtocol
```
Утверждённый метод:
```python
async def coordinate(
self,
runtime_result: RuntimeResult,
) -> CoordinatorResult:
...
```
**Статус:** Accepted
---
# Implementation
Создан файл:
```text
app/src/trading/market_intelligence/coordinator/protocol.py
```
Содержимое контракта:
```python
class CoordinatorProtocol(Protocol):
async def coordinate(
self,
runtime_result: RuntimeResult,
) -> CoordinatorResult:
...
```
---
# Compile Check
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
```text
Passed
```
---
# Domain Review
Подтверждено:
- Coordinator принимает исключительно `RuntimeResult`;
- Coordinator возвращает исключительно `CoordinatorResult`;
- протокол не содержит аналитической логики;
- протокол не содержит торговой логики;
- протокол не зависит от конкретных Engine;
- протокол не зависит от реализации Runtime Layer.
**Статус:** ✅ Passed
---
# Code Review
Проверка пройдена.
Замечаний нет.
**Статус:** ✅ Passed
---
# Acceptance
Build завершён.
Выполнены:
- ✅ Architecture Design
- ✅ Architecture Review
- ✅ ADR
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Code Review
- ✅ Documentation
Статус Build:
```text
Accepted
```
---
# Следующий Build
```text
Build 016.3
Coordinator Exceptions
coordinator/exceptions.py
```

View File

@@ -0,0 +1,168 @@
# Build 016.3 — Coordinator Exceptions
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 016.3 |
| Название | Coordinator Exceptions |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Coordinator |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Цель Build
Создать единую иерархию исключений Coordinator Layer.
---
# Причина появления Build
Coordinator Layer является самостоятельным архитектурным уровнем.
Следовательно, он должен иметь собственное пространство ошибок и не использовать исключения Runtime Layer.
---
# Architecture
Создана минимальная иерархия исключений:
```text
CoordinatorError
├── InvalidCoordinatorResultError
├── CoordinatorValidationError
└── CoordinatorExecutionError
```
---
# Architecture Review
Подтверждено:
- Coordinator Layer имеет собственную иерархию исключений;
- исключения не зависят от Runtime Exceptions;
- файл не содержит логики Coordinator;
- файл не зависит от Engine;
- дополнительные исключения не добавлены преждевременно.
**Статус:** ✅ Passed
---
# ADR
Принято решение ввести собственное пространство ошибок Coordinator Layer.
Это обеспечивает:
- независимость Coordinator Layer;
- явные границы между Runtime и Coordinator;
- локальную обработку ошибок Coordinator;
- возможность расширения без изменения Runtime.
**Статус:** Accepted
---
# Implementation
Создан файл:
```text
app/src/trading/market_intelligence/coordinator/exceptions.py
```
Реализованы:
```text
CoordinatorError
InvalidCoordinatorResultError
CoordinatorValidationError
CoordinatorExecutionError
```
---
# Compile Check
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
```text
Passed
```
---
# Domain Review
Подтверждено:
- ошибки относятся исключительно к ответственности Coordinator;
- исключения не пересекаются с Runtime Layer;
- отсутствует торговая логика;
- отсутствует аналитическая логика;
- отсутствуют зависимости от Engine;
- отсутствуют зависимости от Runtime internals.
**Статус:** ✅ Passed
---
# Code Review
Проверка пройдена.
Замечаний нет.
**Статус:** ✅ Passed
---
# Acceptance
Build завершён.
Выполнены:
- ✅ Architecture Design
- ✅ Architecture Review
- ✅ ADR
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Code Review
- ✅ Documentation
Статус Build:
```text
Accepted
```
---
# Следующий Build
```text
Build 016.4
Coordinator Validation
coordinator/validation.py
```

View File

@@ -0,0 +1,212 @@
# Build 016.4 — Coordinator Validation
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 016.4 |
| Название | Coordinator Validation |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Coordinator |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Цель Build
Создать компонент проверки входного `RuntimeResult` перед началом работы Coordinator Layer.
---
# Причина появления Build
Coordinator является следующим архитектурным уровнем после Runtime Layer.
Перед тем как Coordinator начнёт согласовывать результаты аналитических Engine, необходимо убедиться, что входной `RuntimeResult` корректен.
Validation выделяется в самостоятельный компонент, чтобы отделить проверку входных данных от правил согласования и логики Coordinator.
---
# Architecture
Создан компонент:
```text
CoordinatorValidation
```
с единственным публичным методом:
```python
validate(
runtime_result: RuntimeResult,
) -> None
```
Компонент выполняет только предварительную проверку входного результата Runtime.
---
# Проверяемые условия
В Build реализованы следующие проверки:
- RuntimeResult передан;
- RuntimeResult содержит результаты Engine;
- RuntimeResult успешно завершён и не содержит критических ошибок Runtime.
Все остальные проверки будут реализованы в последующих Build Coordinator Rules.
---
# Architecture Review
Подтверждено:
- Validation проверяет только входные данные;
- Validation не изменяет `RuntimeResult`;
- Validation не формирует `CoordinatorResult`;
- Validation не содержит аналитической логики;
- Validation не зависит от внутренних компонентов Runtime;
- Validation использует только публичный контракт `RuntimeResult`.
**Статус:** ✅ Passed
---
# ADR
Принято решение выделить предварительную проверку входного `RuntimeResult` в отдельный компонент Coordinator Layer.
Validation выполняется до запуска правил согласования и обеспечивает корректность входных данных.
**Статус:** Accepted
---
# Implementation
Создан файл:
```text
app/src/trading/market_intelligence/coordinator/validation.py
```
Реализован класс:
```text
CoordinatorValidation
```
Публичный метод:
```python
validate(
runtime_result: RuntimeResult,
)
```
Внутренние проверки:
```text
_validate_runtime_result_exists()
_validate_runtime_has_results()
_validate_runtime_successful()
```
При обнаружении ошибки используется исключение:
```text
CoordinatorValidationError
```
---
# Compile Check
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
```text
Passed
```
---
# Domain Review
Подтверждено:
- компонент проверяет только входной `RuntimeResult`;
- компонент не изменяет `RuntimeResult`;
- компонент не формирует `CoordinatorResult`;
- компонент не согласует результаты Engine;
- компонент не анализирует рынок;
- компонент не принимает торговых решений;
- компонент использует только публичные свойства `RuntimeResult`.
**Статус:** ✅ Passed
---
# Code Review
Проверка пройдена.
Подтверждено:
- компонент минимален и соответствует принципу Single Responsibility;
- отсутствуют лишние зависимости;
- отсутствует логика согласования результатов;
- используется собственная иерархия исключений Coordinator Layer.
Замечаний нет.
**Статус:** ✅ Passed
---
# Acceptance
Build завершён.
Выполнены:
- ✅ Architecture Design
- ✅ Architecture Review
- ✅ ADR
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Code Review
- ✅ Documentation
Статус Build:
```text
Accepted
```
---
# Следующий Build
```text
Build 016.5
Coordinator Rules
coordinator/rules.py
```

View File

@@ -0,0 +1,199 @@
# Build 016.5 — Coordinator Rules
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 016.5 |
| Название | Coordinator Rules |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Coordinator |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Цель Build
Создать компонент базового согласования результатов Engine.
---
# Причина появления Build
После реализации `CoordinatorValidation` Coordinator Layer получил механизм проверки входного `RuntimeResult`.
Следующим шагом стал компонент, который преобразует:
```text
RuntimeResult
```
в:
```text
CoordinatorResult
```
---
# Architecture
Создан компонент:
```text
CoordinatorRules
```
Компонент отвечает за применение правил согласования результатов Engine.
В Build 016.5 реализован минимальный базовый каркас правил без сложных механизмов весов, конфликтов и голосования.
---
# Architecture Review
Подтверждено:
- Rules не запускает Engine;
- Rules не обращается к RuntimeService;
- Rules не выполняет Validation;
- Rules не зависит от CoordinatorService;
- Rules не принимает торговых решений;
- Rules работает только с `RuntimeResult` и формирует `CoordinatorResult`.
**Статус:** ✅ Passed
---
# ADR
Принято решение выделить правила согласования результатов Engine в отдельный компонент Coordinator Layer.
`CoordinatorRules` отвечает за формирование итогового `CoordinatorResult` из `RuntimeResult`.
**Статус:** Accepted
---
# Implementation
Создан файл:
```text
app/src/trading/market_intelligence/coordinator/rules.py
```
Реализован класс:
```text
CoordinatorRules
```
Публичный метод:
```python
coordinate(runtime_result)
```
Внутренние методы:
```text
_resolve_status()
_resolve_score()
_resolve_confidence()
_resolve_direction()
_resolve_bias()
_resolve_phase()
_resolve_regime()
_resolve_risk_level()
```
---
# Compile Check
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
```text
Passed
```
---
# Domain Review
Подтверждено:
- компонент преобразует `RuntimeResult` в `CoordinatorResult`;
- компонент не запускает Engine;
- компонент не обращается к Runtime internals;
- компонент не выполняет Validation;
- компонент не принимает торговых решений;
- компонент пока реализует только базовые правила согласования;
- сложные механизмы весов, конфликтов и голосования не добавлены преждевременно.
**Статус:** ✅ Passed
---
# Code Review
Проверка пройдена.
Подтверждено:
- компонент минимален;
- публичный метод только один;
- Validation не дублируется;
- торговая логика отсутствует;
- лишние зависимости отсутствуют;
- сложные правила не добавлены преждевременно.
**Статус:** ✅ Passed
---
# Acceptance
Build завершён.
Выполнены:
- ✅ Architecture Design
- ✅ Architecture Review
- ✅ ADR
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Code Review
- ✅ Documentation
Статус Build:
```text
Accepted
```
---
# Следующий Build
```text
Build 016.6
Coordinator Service
coordinator/service.py
```

View File

@@ -0,0 +1,252 @@
# Build 016.6 — Coordinator Service
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 016.6 |
| Название | Coordinator Service |
| Статус | **Accepted** |
| Подсистема | Market Intelligence |
| Layer | Coordinator |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Цель Build
Создать единую публичную точку входа Coordinator Layer.
---
# Причина появления Build
После реализации компонентов:
- `CoordinatorProtocol`;
- `CoordinatorValidation`;
- `CoordinatorRules`;
Coordinator Layer получил все необходимые внутренние элементы, однако отсутствовал компонент, объединяющий их в единый рабочий процесс.
Эту роль выполняет `CoordinatorService`.
---
# Architecture
Создан компонент:
```text
CoordinatorService
```
Он реализует официальный контракт:
```text
CoordinatorProtocol
```
и обеспечивает последовательность выполнения:
```text
RuntimeResult
CoordinatorValidation
CoordinatorRules
CoordinatorResult
```
---
# Architecture Review
Подтверждено:
- Service является единственной публичной точкой входа Coordinator Layer;
- Service принимает только `RuntimeResult`;
- Service возвращает только `CoordinatorResult`;
- Service реализует `CoordinatorProtocol`;
- Service делегирует проверку `CoordinatorValidation`;
- Service делегирует согласование `CoordinatorRules`;
- Service не содержит собственной бизнес-логики;
- Service не зависит от внутренних компонентов Runtime Layer.
**Статус:** ✅ Passed
---
# ADR
Принято решение объединить внутренние компоненты Coordinator Layer через единый сервис.
`CoordinatorService` становится единственной точкой взаимодействия внешних слоёв с Coordinator.
Все внутренние компоненты Coordinator инкапсулируются внутри Service.
**Статус:** Accepted
---
# Implementation
Создан файл:
```text
app/src/trading/market_intelligence/coordinator/service.py
```
Реализован класс:
```text
CoordinatorService
```
Публичный метод:
```python
coordinate(
runtime_result: RuntimeResult,
) -> CoordinatorResult
```
Внутренние зависимости:
```text
CoordinatorValidation
CoordinatorRules
```
Последовательность работы:
```text
Validation
Rules
CoordinatorResult
```
---
# Compile Check
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
```text
Passed
```
---
# Domain Review
Подтверждено:
- компонент является публичной точкой входа Coordinator Layer;
- принимает только `RuntimeResult`;
- возвращает только `CoordinatorResult`;
- не содержит правил согласования;
- не изменяет `RuntimeResult`;
- не запускает Engine;
- не принимает торговых решений;
- не обращается к Runtime internals.
**Статус:** ✅ Passed
---
# Code Review
Проверка пройдена.
Подтверждено:
- `CoordinatorService` реализует `CoordinatorProtocol`;
- публичный метод только один;
- Validation и Rules не дублируются;
- отсутствуют лишние зависимости;
- отсутствует торговая логика.
Замечаний нет.
**Статус:** ✅ Passed
---
# Acceptance
Build завершён.
Выполнены:
- ✅ Architecture Design
- ✅ Architecture Review
- ✅ ADR
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Code Review
- ✅ Documentation
Статус Build:
```text
Accepted
```
---
# Итог Build
Build 016.6 завершает построение **Coordinator Foundation**.
Coordinator Layer полностью сформирован и включает:
```text
Coordinator
├── models
├── protocol
├── exceptions
├── validation
├── rules
└── service
```
Теперь Coordinator Layer обладает:
- единым публичным API;
- собственными моделями;
- собственным пространством исключений;
- механизмом предварительной проверки входных данных;
- базовыми правилами согласования;
- сервисом-оркестратором.
Архитектурный фундамент Coordinator завершён.
---
# Следующий Build
```text
Build 017
Trading Layer Architecture
```

View File

@@ -0,0 +1,363 @@
# Build 016 — Coordinator Layer Architecture
**Статус:** ✅ Accepted
---
# Цель Build
Определить архитектуру нового слоя **Coordinator Layer**, отвечающего за объединение результатов аналитических Engine в единое представление состояния рынка.
Build не содержит реализации компонентов и фиксирует исключительно архитектурные решения, необходимые для дальнейшего развития платформы.
---
# Архитектурная задача
После завершения Runtime Layer платформа способна:
- зарегистрировать Engine;
- проверить корректность Runtime;
- определить порядок выполнения Engine;
- выполнить все зарегистрированные Engine;
- собрать результаты в единый `RuntimeResult`.
Однако `RuntimeResult` представляет собой лишь совокупность независимых результатов Engine.
Для получения единой аналитической картины рынка необходим отдельный архитектурный слой.
---
# Причина появления Coordinator Layer
Каждый Engine анализирует только собственную область ответственности.
Например:
```text
Trend Engine
UP
Structure Engine
BULLISH
Wave Engine
IMPULSE
Liquidity Engine
LOW
```
Каждый вывод корректен в рамках своего Engine.
Однако платформа должна получить единый ответ на вопрос:
> **Каково текущее состояние рынка с учётом всех аналитических компонентов одновременно?**
Эта ответственность не относится к Runtime Layer.
---
# Назначение Coordinator Layer
Coordinator Layer становится следующим архитектурным уровнем после Runtime Layer.
Он получает:
```text
RuntimeResult
```
и формирует:
```text
CoordinatorResult
```
Coordinator отвечает исключительно за согласование результатов аналитических Engine.
---
# Ответственность Coordinator
Coordinator обязан:
- принимать `RuntimeResult`;
- анализировать результаты всех Engine;
- учитывать статус каждого Engine;
- учитывать confidence каждого Engine;
- выявлять подтверждения между Engine;
- выявлять противоречия между Engine;
- оценивать полноту аналитических данных;
- формировать единый `CoordinatorResult`.
Coordinator не изменяет результаты Engine.
Coordinator не выполняет повторный анализ рынка.
---
# Что Coordinator не делает
Coordinator не должен:
- запускать Engine;
- создавать Engine;
- обращаться к Runtime Registry;
- обращаться к Runtime Runner;
- выполнять анализ рыночных данных;
- рассчитывать технические индикаторы;
- принимать торговые решения;
- взаимодействовать с биржей;
- взаимодействовать с Telegram;
- работать с базой данных;
- работать с AutoTrade.
Coordinator является исключительно аналитическим слоем согласования результатов.
---
# Архитектурная схема
```text
Market Data
Engine
Runtime
RuntimeResult
Coordinator
CoordinatorResult
Trading Layer
```
---
# Границы Coordinator Layer
Coordinator располагается между Runtime Layer и будущим Trading Layer.
Runtime отвечает за выполнение Engine.
Coordinator отвечает за согласование результатов.
Trading Layer принимает решения на основании `CoordinatorResult`.
Таким образом каждый слой имеет собственную область ответственности.
---
# Предварительная структура Coordinator Layer
```text
coordinator/
├── __init__.py
├── models.py
├── protocol.py
├── exceptions.py
├── validation.py
├── rules.py
└── service.py
```
Каждый компонент имеет самостоятельную область ответственности.
---
# Предполагаемые компоненты
## models.py
Определяет модели Coordinator Layer.
Основной моделью станет:
```text
CoordinatorResult
```
В дальнейшем могут появиться дополнительные модели диагностики и согласования.
---
## protocol.py
Определяет официальный публичный контракт Coordinator Layer.
---
## exceptions.py
Содержит исключения Coordinator Layer.
---
## validation.py
Проверяет корректность входного `RuntimeResult`.
---
## rules.py
Содержит правила согласования результатов Engine.
Именно данный компонент будет определять принципы объединения аналитических выводов.
---
## service.py
Является единственной публичной точкой входа Coordinator Layer.
Получает `RuntimeResult`.
Возвращает `CoordinatorResult`.
---
# Допустимые зависимости
Coordinator может использовать:
```text
Common Layer
RuntimeResult
Coordinator Models
```
Coordinator не должен зависеть от внутренних компонентов Runtime.
---
# Архитектурные принципы
При проектировании Coordinator подтверждены следующие инженерные принципы.
## Single Responsibility
Coordinator отвечает исключительно за согласование результатов Engine.
---
## Stable Foundation
Coordinator строится поверх полностью завершённого Runtime Layer.
---
## One Source of Truth
Единым результатом работы Coordinator становится `CoordinatorResult`.
---
## Architecture First
Сначала утверждается архитектура слоя.
Только после этого начинается реализация его компонентов.
---
# Architecture Review
Во время архитектурной проверки подтверждено:
- Runtime и Coordinator имеют различные области ответственности;
- отсутствует пересечение обязанностей;
- Runtime остаётся инфраструктурным слоем;
- Coordinator становится аналитическим слоем согласования;
- Trading Layer не зависит от внутренних компонентов Runtime.
Architecture Review завершён успешно.
---
# Architecture Decision Record (ADR)
Принято следующее долгосрочное архитектурное решение.
> Coordinator Layer вводится как самостоятельный архитектурный слой между Runtime Layer и Trading Layer.
Coordinator становится единственным компонентом платформы, ответственным за объединение результатов аналитических Engine.
---
# План реализации Build 016.x
Разработка Coordinator Layer утверждена в следующей последовательности.
```text
016.1
Coordinator Models
016.2
Coordinator Protocol
016.3
Coordinator Exceptions
016.4
Coordinator Validation
016.5
Coordinator Rules
016.6
Coordinator Service
```
Такая последовательность повторяет архитектурный подход, ранее использованный при построении Runtime Layer.
---
# Итог
Build 016 завершает проектирование нового архитектурного слоя платформы.
В результате утверждены:
- назначение Coordinator Layer;
- область ответственности;
- архитектурные границы;
- место слоя в общей архитектуре;
- структура компонентов;
- последовательность дальнейшей реализации.
После завершения Build архитектура платформы принимает следующий вид.
```text
Common Layer
Engine Layer
Runtime Layer
Coordinator Layer
Trading Layer
```
Coordinator Layer официально включён в архитектуру подсистемы **Market Intelligence** и готов к реализации в серии Build **016.x**.

View File

@@ -0,0 +1,187 @@
# Build 017.1 — Trading Models / TradingDecision
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 017.1 |
| Название | Trading Models / TradingDecision |
| Статус | **Accepted** |
| Подсистема | Trading |
| Layer | Common / Trading Contract |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Цель Build
Добавить базовые модели Trading Layer.
Основной результат Build:
```text
TradingDecision
```
---
# Причина появления Build
После утверждения архитектуры Trading Layer потребовался официальный выходной контракт слоя.
`TradingDecision` является межслойной моделью:
```text
CoordinatorResult
Trading Layer
TradingDecision
Execution / Risk / Portfolio
```
Поэтому модель размещена в Common Layer.
---
# Реализованные модели
В файл:
```text
app/src/trading/market_intelligence/common/models.py
```
добавлены:
```text
TradingDiagnostics
TradingEvaluationMeta
TradingDecision
```
---
# Architecture Review
Проверка подтвердила:
- модели корректно размещены в Common Layer;
- `TradingDecision` является результатом Trading Layer;
- `TradingDecision` не является ордером;
- `TradingDecision` не исполняет сделку;
- `TradingDecision` не управляет позицией;
- модель не зависит от Execution / Risk / Portfolio слоёв.
**Статус:** ✅ Passed
---
# ADR
Принято решение добавить модели Trading Layer в Common Layer, так как `TradingDecision` является межслойным контрактом между Trading Layer и будущими слоями Execution / Risk / Portfolio.
**Статус:** Accepted
---
# Implementation
Добавлены модели:
```text
TradingDiagnostics
TradingEvaluationMeta
TradingDecision
```
`TradingDecision` содержит:
- `coordinator_result`;
- `diagnostics`;
- `meta`;
- `payload`;
- `status`;
- `score`;
- `confidence`;
- `reason`.
---
# Compile Check
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
```text
Passed
```
---
# Domain Review
Подтверждено:
- `TradingDecision` использует `CoordinatorResult` как входной аналитический контракт;
- модель не является ордером;
- модель не исполняет сделку;
- модель не содержит биржевой логики;
- модель не управляет позицией;
- модель не содержит Risk Plan / Entry Plan / Exit Plan.
**Статус:** ✅ Passed
---
# Code Review
Проверка пройдена.
Замечаний, блокирующих Build, нет.
**Статус:** ✅ Passed
---
# Acceptance
Build завершён.
Выполнены:
- ✅ Architecture Design
- ✅ Architecture Review
- ✅ ADR
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Code Review
- ✅ Documentation
Статус Build:
```text
Accepted
```
---
# Следующий Build
```text
Build 017.2
Trading Protocol
```

View File

@@ -0,0 +1,191 @@
# Build 017.2 — Trading Protocol
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 017.2 |
| Название | Trading Protocol |
| Статус | **Accepted** |
| Подсистема | Trading |
| Layer | Trading |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Цель Build
Создать официальный публичный контракт Trading Layer.
---
# Причина появления Build
После появления модели `TradingDecision` Trading Layer должен получить стабильный интерфейс взаимодействия.
Контракт Trading определяет единственную модель взаимодействия:
```text
CoordinatorResult
Trading
TradingDecision
```
---
# Architecture
`TradingProtocol` описывает только внешний интерфейс Trading Layer.
Он не содержит:
- реализации;
- Validation;
- Rules;
- Execution;
- Risk;
- Portfolio;
- биржевой логики;
- логики исполнения сделок.
---
# Architecture Review
Подтверждено:
- вход — только `CoordinatorResult`;
- выход — только `TradingDecision`;
- контракт не содержит реализации;
- контракт не зависит от Runtime;
- контракт не зависит от Coordinator internals;
- контракт не работает с биржей;
- контракт не исполняет сделки.
**Статус:** ✅ Passed
---
# ADR
Принято решение добавить официальный контракт:
```text
TradingProtocol
```
Утверждённый метод:
```python
async def decide(
coordinator_result: CoordinatorResult,
) -> TradingDecision:
...
```
**Статус:** Accepted
---
# Implementation
Создан файл:
```text
app/src/trading/market_intelligence/trading/protocol.py
```
Содержимое контракта:
```python
class TradingProtocol(Protocol):
async def decide(
self,
coordinator_result: CoordinatorResult,
) -> TradingDecision:
...
```
---
# Compile Check
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
```text
Passed
```
---
# Domain Review
Подтверждено:
- Trading принимает только `CoordinatorResult`;
- Trading возвращает только `TradingDecision`;
- протокол не содержит реализации;
- протокол не содержит торговых правил;
- протокол не содержит логики исполнения сделок;
- протокол не зависит от Runtime;
- протокол не зависит от Coordinator internals.
**Статус:** ✅ Passed
---
# Code Review
Проверка пройдена.
Замечаний нет.
**Статус:** ✅ Passed
---
# Acceptance
Build завершён.
Выполнены:
- ✅ Architecture Design
- ✅ Architecture Review
- ✅ ADR
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Code Review
- ✅ Documentation
Статус Build:
```text
Accepted
```
---
# Следующий Build
```text
Build 017.3
Trading Exceptions
trading/exceptions.py
```

View File

@@ -0,0 +1,180 @@
# Build 017.3 — Trading Exceptions
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 017.3 |
| Название | Trading Exceptions |
| Статус | **Accepted** |
| Подсистема | Trading |
| Layer | Trading |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Цель Build
Создать собственную иерархию исключений Trading Layer.
---
# Причина появления Build
После утверждения архитектуры Trading Layer, моделей и публичного контракта необходимо сформировать собственное пространство ошибок.
Каждый архитектурный слой платформы Dzentra использует собственную иерархию исключений, что обеспечивает слабую связанность между слоями и независимую обработку ошибок.
---
# Architecture
Trading Layer получает собственую иерархию исключений:
```text
TradingError
├── InvalidTradingDecisionError
├── TradingValidationError
└── TradingExecutionError
```
Иерархия полностью независима от Runtime Layer и Coordinator Layer.
---
# Architecture Review
Подтверждено:
- Trading Layer имеет собственное пространство ошибок;
- исключения не зависят от Coordinator;
- исключения не зависят от Runtime;
- файл не содержит Validation;
- файл не содержит Rules;
- файл не содержит Service;
- специализированные исключения преждевременно не добавляются.
**Статус:** ✅ Passed
---
# ADR
Принято решение выделить собственную иерархию исключений Trading Layer.
Trading не использует ошибки других слоёв платформы.
Будущие компоненты Validation, Rules и Service будут использовать исключительно `TradingError` и его наследников.
**Статус:** Accepted
---
# Implementation
Создан файл:
```text
app/src/trading/market_intelligence/trading/exceptions.py
```
Реализованы исключения:
```text
TradingError
InvalidTradingDecisionError
TradingValidationError
TradingExecutionError
```
Иерархия соответствует архитектурному стандарту платформы.
---
# Compile Check
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
```text
Passed
```
---
# Domain Review
Подтверждено:
- ошибки относятся только к Trading Layer;
- исключения не пересекаются с Coordinator / Runtime / Engine;
- файл не содержит Validation;
- файл не содержит Rules;
- файл не содержит Service;
- торговая логика отсутствует;
- специализированные ошибки Risk / Position / Entry / Exit не добавлены преждевременно.
**Статус:** ✅ Passed
---
# Code Review
Проверка пройдена.
Подтверждено:
- `TradingError` является базовым исключением Trading Layer;
- все специализированные исключения наследуются только от `TradingError`;
- файл не импортирует другие архитектурные слои;
- отсутствуют лишние зависимости;
- структура полностью соответствует архитектурному стандарту Dzentra.
Замечаний нет.
**Статус:** ✅ Passed
---
# Acceptance
Build завершён.
Выполнены:
- ✅ Architecture Design
- ✅ Architecture Review
- ✅ ADR
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Code Review
- ✅ Documentation
Статус Build:
```text
Accepted
```
---
# Следующий Build
```text
Build 017.4
Trading Validation
trading/validation.py
```

View File

@@ -0,0 +1,224 @@
# Build 017.4 — Trading Validation
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 017.4 |
| Название | Trading Validation |
| Статус | **Accepted** |
| Подсистема | Trading |
| Layer | Trading |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Цель Build
Создать компонент предварительной проверки входного `CoordinatorResult` перед началом работы Trading Layer.
---
# Причина появления Build
Trading Layer принимает торговое решение только на основании результата Coordinator Layer.
Перед применением торговых правил необходимо убедиться, что входной аналитический результат корректен и пригоден для дальнейшего использования.
Для этого вводится отдельный компонент:
```text
TradingValidation
```
Он отделяет проверку входных данных от бизнес-логики принятия решений.
---
# Architecture
TradingValidation является первым этапом жизненного цикла Trading Layer:
```text
CoordinatorResult
TradingValidation
TradingRules
TradingDecision
```
Validation выполняет исключительно проверку входного контракта и не содержит торговых правил.
---
# Architecture Review
Подтверждено:
- компонент принимает только `CoordinatorResult`;
- компонент не изменяет `CoordinatorResult`;
- компонент не формирует `TradingDecision`;
- компонент не содержит Trading Rules;
- компонент не взаимодействует с Runtime, Coordinator internals, биржей или внешними сервисами;
- используются только публичные свойства `CoordinatorResult`.
**Статус:** ✅ Passed
---
# ADR
Принято решение выделить проверку входного результата в самостоятельный компонент.
Trading Layer использует исключительно публичный API `CoordinatorResult`:
- `is_usable`;
- `has_errors`.
Trading Layer не анализирует внутренние статусы Coordinator и не зависит от его реализации.
**Статус:** Accepted
---
# Implementation
Создан файл:
```text
app/src/trading/market_intelligence/trading/validation.py
```
Реализован класс:
```text
TradingValidation
```
Публичный метод:
```python
validate(
coordinator_result: CoordinatorResult,
) -> None
```
Выполняемые проверки:
1. Передан ли `CoordinatorResult`;
2. Пригоден ли результат (`is_usable`);
3. Отсутствуют ли критические ошибки (`has_errors`).
---
# Compile Check
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
```text
Passed
```
---
# Domain Review
Подтверждено:
- компонент проверяет только входной `CoordinatorResult`;
- компонент не изменяет входные данные;
- компонент не содержит Trading Rules;
- компонент не принимает торговых решений;
- компонент использует только публичные свойства `CoordinatorResult`;
- отсутствуют зависимости от Runtime, Coordinator internals и других слоёв.
**Статус:** ✅ Passed
---
# Code Review
Проверка пройдена.
Подтверждено:
- единственный публичный метод — `validate()`;
- используется специализированное исключение `TradingValidationError`;
- проверки разделены на приватные методы;
- отсутствует бизнес-логика;
- отсутствуют лишние зависимости.
Замечаний нет.
**Статус:** ✅ Passed
---
# Acceptance
Build завершён.
Выполнены:
- ✅ Development Strategy
- ✅ Architecture Design
- ✅ Architecture Review
- ✅ ADR
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Code Review
- ✅ Documentation
Статус Build:
```text
Accepted
```
---
# Итог Build
Build 017.4 завершил создание компонента предварительной проверки Trading Layer.
Теперь фундамент Trading содержит:
```text
Trading Foundation
├── Models
├── Protocol
├── Exceptions
└── Validation
```
Trading Layer получил собственный механизм проверки входного аналитического контракта без нарушения архитектурной изоляции между слоями.
---
# Следующий Build
```text
Build 017.5
Trading Rules
trading/rules.py
```

View File

@@ -0,0 +1,194 @@
# Build 017.5 — Trading Rules
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 017.5 |
| Название | Trading Rules |
| Статус | **Accepted** |
| Подсистема | Trading |
| Layer | Trading |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Цель Build
Создать компонент базового формирования `TradingDecision` из `CoordinatorResult`.
---
# Причина появления Build
После реализации `TradingValidation` Trading Layer получил механизм проверки входного `CoordinatorResult`.
Следующим шагом стал компонент, который преобразует:
```text
CoordinatorResult
```
в:
```text
TradingDecision
```
---
# Architecture
Создан компонент:
```text
TradingRules
```
В Build 017.5 реализован базовый каркас правил без BUY / SELL / HOLD / EXIT логики.
---
# Architecture Review
Подтверждено:
- Rules не выполняет Validation;
- Rules не обращается к Runtime;
- Rules не обращается к Coordinator internals;
- Rules не работает с биржей;
- Rules не исполняет сделки;
- Rules не управляет позицией;
- Rules формирует только базовый `TradingDecision`.
**Статус:** ✅ Passed
---
# ADR
Принято решение выделить правила формирования торгового решения в отдельный компонент Trading Layer.
`TradingRules` отвечает за формирование `TradingDecision` из `CoordinatorResult`.
**Статус:** Accepted
---
# Implementation
Создан файл:
```text
app/src/trading/market_intelligence/trading/rules.py
```
Реализован класс:
```text
TradingRules
```
Публичный метод:
```python
decide(coordinator_result)
```
Внутренние методы:
```text
_resolve_status()
_resolve_score()
_resolve_confidence()
_resolve_reason()
```
---
# Compile Check
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
```text
Passed
```
---
# Domain Review
Подтверждено:
- компонент преобразует `CoordinatorResult` в `TradingDecision`;
- компонент не выполняет Validation;
- компонент не обращается к Runtime;
- компонент не обращается к Coordinator internals;
- компонент не исполняет сделки;
- компонент не управляет позициями;
- компонент не содержит BUY / SELL / HOLD / EXIT логики;
- компонент формирует только базовый каркас `TradingDecision`.
**Статус:** ✅ Passed
---
# Code Review
Проверка пройдена.
Подтверждено:
- компонент минимален;
- публичный метод только один;
- Validation не дублируется;
- торговая логика не добавлена преждевременно;
- лишние зависимости отсутствуют.
**Статус:** ✅ Passed
---
# Acceptance
Build завершён.
Выполнены:
- ✅ Architecture Design
- ✅ Architecture Review
- ✅ ADR
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Code Review
- ✅ Documentation
Статус Build:
```text
Accepted
```
---
# Следующий Build
```text
Build 017.6
Trading Service
trading/service.py
```

View File

@@ -0,0 +1,253 @@
# Build 017.6 — Trading Service
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 017.6 |
| Название | Trading Service |
| Статус | **Accepted** |
| Подсистема | Trading |
| Layer | Trading |
| Тип | Architecture + Implementation |
| Версия | 1.0 |
| Язык | Русский |
---
# Цель Build
Создать единую публичную точку входа Trading Layer.
---
# Причина появления Build
После реализации компонентов:
- `TradingProtocol`;
- `TradingValidation`;
- `TradingRules`;
Trading Layer получил все необходимые внутренние элементы, однако отсутствовал компонент, объединяющий их в единый рабочий процесс.
Эту роль выполняет `TradingService`.
---
# Architecture
Создан компонент:
```text
TradingService
```
Он реализует официальный контракт:
```text
TradingProtocol
```
и обеспечивает последовательность выполнения:
```text
CoordinatorResult
TradingValidation
TradingRules
TradingDecision
```
---
# Architecture Review
Подтверждено:
- Service является единственной публичной точкой входа Trading Layer;
- Service принимает только `CoordinatorResult`;
- Service возвращает только `TradingDecision`;
- Service реализует `TradingProtocol`;
- Service делегирует проверку `TradingValidation`;
- Service делегирует формирование решения `TradingRules`;
- Service не содержит собственной торговой логики;
- Service не зависит от внутренних компонентов Runtime или Coordinator.
**Статус:** ✅ Passed
---
# ADR
Принято решение объединить внутренние компоненты Trading Layer через единый сервис.
`TradingService` становится единственной точкой взаимодействия внешних слоёв с Trading Layer.
Все внутренние компоненты Trading инкапсулируются внутри Service.
**Статус:** Accepted
---
# Implementation
Создан файл:
```text
app/src/trading/market_intelligence/trading/service.py
```
Реализован класс:
```text
TradingService
```
Публичный метод:
```python
decide(
coordinator_result: CoordinatorResult,
) -> TradingDecision
```
Внутренние зависимости:
```text
TradingValidation
TradingRules
```
Последовательность работы:
```text
Validation
Rules
TradingDecision
```
---
# Compile Check
```bash
python -m compileall src/trading/market_intelligence
```
Результат:
```text
Passed
```
---
# Domain Review
Подтверждено:
- компонент является публичной точкой входа Trading Layer;
- принимает только `CoordinatorResult`;
- возвращает только `TradingDecision`;
- не содержит торговых правил;
- не изменяет `CoordinatorResult`;
- не обращается к Runtime / Coordinator internals;
- не работает с биржей;
- не исполняет сделки.
**Статус:** ✅ Passed
---
# Code Review
Проверка пройдена.
Подтверждено:
- `TradingService` реализует `TradingProtocol`;
- публичный метод только один;
- Validation и Rules не дублируются;
- отсутствуют лишние зависимости;
- отсутствует торговая логика.
Замечаний нет.
**Статус:** ✅ Passed
---
# Acceptance
Build завершён.
Выполнены:
- ✅ Development Strategy
- ✅ Architecture Design
- ✅ Architecture Review
- ✅ ADR
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Code Review
- ✅ Documentation
Статус Build:
```text
Accepted
```
---
# Итог Build
Build 017.6 завершает построение **Trading Foundation**.
Trading Layer полностью сформирован и включает:
```text
Trading
├── models
├── protocol
├── exceptions
├── validation
├── rules
└── service
```
Теперь Trading Layer обладает:
- единым публичным API;
- собственными моделями;
- собственным пространством исключений;
- механизмом предварительной проверки входных данных;
- базовыми правилами формирования торгового решения;
- сервисом-оркестратором.
Архитектурный фундамент Trading завершён.
---
# Следующий Build
```text
Build 018
Execution Layer Architecture
```

View File

@@ -0,0 +1,230 @@
# Build 017.7 — Trading Boundary Correction
**Engineering Build Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 017.7 |
| Название | Trading Boundary Correction |
| Статус | **Accepted** |
| Подсистема | Trading / Market Intelligence |
| Тип | Architecture Refactoring |
| Версия | 1.0 |
| Язык | Русский |
---
# Цель Build
Исправить архитектурную границу между **Market Intelligence** и **Trading Decision**.
---
# Причина появления Build
В ходе подготовки к Build 018 было обнаружено, что Trading Foundation был размещён внутри:
```text
src/trading/market_intelligence/trading/
```
Это нарушало границу ответственности, поскольку `market_intelligence` должен содержать только компоненты анализа рынка.
---
# Architecture
Trading Foundation перенесён в самостоятельный слой:
```text
src/trading/decision/
```
Целевая структура:
```text
src/trading/decision/
├── __init__.py
├── models.py
├── protocol.py
├── exceptions.py
├── validation.py
├── rules.py
└── service.py
```
---
# Architecture Review
Подтверждено:
- `market_intelligence` содержит только компоненты анализа рынка;
- `TradingDecision` больше не находится в `market_intelligence/common/models.py`;
- Trading Decision вынесен в самостоятельный слой `src/trading/decision`;
- существующий `src/trading/execution/` не затронут;
- дублирования Execution Layer не создано.
**Статус:** ✅ Passed
---
# ADR
Принято решение перенести Trading Foundation из `market_intelligence` в самостоятельный слой `decision`.
`market_intelligence/common/models.py` должен содержать только модели Market Intelligence:
```text
Engine*
Runtime*
Coordinator*
```
Trading Decision использует `CoordinatorResult`, но не является частью Market Intelligence.
**Статус:** Accepted
---
# Implementation
Создан каталог:
```text
app/src/trading/decision/
```
Создан файл:
```text
app/src/trading/decision/models.py
```
Перенесены файлы:
```text
protocol.py
exceptions.py
validation.py
rules.py
service.py
```
Удалены модели Trading из:
```text
app/src/trading/market_intelligence/common/models.py
```
Удалён старый каталог:
```text
app/src/trading/market_intelligence/trading/
```
---
# Compile Check
Проверены оба контура:
```bash
python -m compileall src/trading/market_intelligence
python -m compileall src/trading/decision
```
Результат:
```text
Passed
```
---
# Domain Review
Подтверждено:
- `market_intelligence` снова содержит только Market Intelligence компоненты;
- Trading Decision вынесен в самостоятельный слой;
- `decision` корректно использует `CoordinatorResult` как входной контракт;
- существующая подсистема `execution` не затронута;
- дублирования Execution Layer не создано.
**Статус:** ✅ Passed
---
# Code Review
Проверка пройдена.
Подтверждено:
- новые импорты используют `src.trading.decision`;
- старых импортов из `src.trading.market_intelligence.trading` не обнаружено;
- `TradingDecision` находится в `decision/models.py`;
- `market_intelligence/common/models.py` очищен от Trading-моделей;
- архитектурная граница восстановлена.
**Статус:** ✅ Passed
---
# Acceptance
Build завершён.
Выполнены:
- ✅ Development Strategy
- ✅ Architecture Design
- ✅ Architecture Review
- ✅ ADR
- ✅ Build Design
- ✅ Implementation
- ✅ Compile Check
- ✅ Domain Review
- ✅ Code Review
- ✅ Documentation
Статус Build:
```text
Accepted
```
---
# Итог Build
Build 017.7 восстановил правильную архитектурную границу:
```text
Market Intelligence
CoordinatorResult
Decision Layer
TradingDecision
Execution
```
Теперь `market_intelligence` отвечает только за аналитику рынка, а `decision` отвечает за формирование торгового решения.
---
# Следующий Build
```text
Build 018
Execution Layer Architecture
```

View File

@@ -0,0 +1,325 @@
# Build 017 — Trading Layer Architecture
**Engineering Architecture Document**
---
# Контроль документа
| Свойство | Значение |
|----------|-----------|
| Build | 017 |
| Название | Trading Layer Architecture |
| Статус | **Accepted** |
| Подсистема | Trading |
| Тип | Architecture |
| Версия | 1.0 |
| Язык | Русский |
---
# Цель Build
Утвердить архитектуру Trading Layer как самостоятельного слоя платформы Dzentra.
Build не содержит реализации кода и фиксирует место Trading Layer в общей архитектуре системы.
---
# Причина появления Trading Layer
После завершения Coordinator Layer аналитическая часть платформы заканчивается формированием объекта:
```text
CoordinatorResult
```
Дальнейшая задача платформы — принять торговое решение на основе уже готовой аналитики.
Поэтому вводится отдельный слой Trading Layer.
---
# Архитектурная роль
Trading Layer располагается между аналитической подсистемой Market Intelligence и слоем исполнения сделок.
Архитектурная цепочка выглядит следующим образом:
```text
Market Data
Market Intelligence
CoordinatorResult
Trading Layer
TradingDecision
Execution Layer
```
Таким образом Trading Layer полностью отделяет аналитическую часть платформы от исполнения торговых операций.
---
# Вход Trading Layer
Единственным входом является:
```text
CoordinatorResult
```
Trading Layer не обращается напрямую к:
- Engine;
- Runtime;
- Coordinator internals;
- Market Data.
Вся аналитическая информация поступает исключительно через публичную модель `CoordinatorResult`.
---
# Выход Trading Layer
Результатом работы Trading Layer станет:
```text
TradingDecision
```
Модель `TradingDecision` будет разработана в последующих Build.
На данном этапе фиксируется только её архитектурная роль.
---
# Ответственность Trading Layer
Trading Layer отвечает за:
- интерпретацию аналитического состояния рынка;
- применение торговых правил;
- выбор торгового действия;
- формирование итогового `TradingDecision`.
---
# Trading Layer не отвечает за
Следующие задачи находятся вне ответственности Trading Layer:
- анализ рыночных данных;
- запуск Engine;
- выполнение Runtime;
- внутреннюю работу Coordinator;
- исполнение ордеров;
- управление биржевым API;
- работу с Telegram;
- управление позициями;
- управление портфелем.
---
# Архитектурная структура
Trading Layer повторяет архитектурный шаблон Runtime Layer и Coordinator Layer.
Предварительная структура:
```text
trading/
├── common/
├── models.py
├── protocol.py
├── exceptions.py
├── validation.py
├── rules.py
└── service.py
```
---
# Ответственность компонентов
## models.py
Содержит модели Trading Layer.
Например:
- TradingDecision;
- диагностические модели;
- служебные структуры.
---
## protocol.py
Определяет официальный публичный контракт Trading Layer.
Будущий интерфейс:
```python
async def decide(
coordinator_result: CoordinatorResult,
) -> TradingDecision:
...
```
---
## exceptions.py
Содержит собственную иерархию исключений Trading Layer.
Не использует исключения Coordinator Layer.
---
## validation.py
Проверяет корректность входного `CoordinatorResult`.
Не содержит торговых правил.
---
## rules.py
Центральный компонент Trading Layer.
Отвечает за:
- интерпретацию аналитики;
- применение торговых правил;
- выбор итогового торгового решения;
- формирование `TradingDecision`.
---
## service.py
Единая публичная точка входа Trading Layer.
Связывает:
```text
Validation
Rules
```
и предоставляет единый API внешним слоям платформы.
---
# Ограничения зависимостей
Trading Layer не должен иметь прямых зависимостей от:
- Engine Layer;
- Runtime internals;
- Coordinator internals;
- Exchange API;
- Telegram;
- базы данных;
- EventBus.
Взаимодействие с аналитической подсистемой осуществляется исключительно через `CoordinatorResult`.
---
# Architecture Review
Проверка подтвердила:
- Trading Layer является самостоятельным архитектурным слоем;
- аналитика полностью отделена от торговых решений;
- определены чёткие входные и выходные контракты;
- соблюдена изоляция между слоями платформы.
**Статус:** ✅ Passed
---
# Architecture Decision (ADR)
Принято решение выделить принятие торговых решений в отдельный слой платформы.
Trading Layer использует исключительно результат Coordinator и формирует независимый объект `TradingDecision`, который в дальнейшем станет входом для Execution Layer.
**Статус:** Accepted
---
# Последовательность Build 017.x
План дальнейшего развития Trading Layer:
```text
017 Trading Layer Architecture
017.1 Trading Models
017.2 Trading Protocol
017.3 Trading Exceptions
017.4 Trading Validation
017.5 Trading Rules
017.6 Trading Service
```
---
# Acceptance
Build завершён.
Выполнены:
- ✅ Development Strategy
- ✅ Architecture Design
- ✅ Architecture Review
- ✅ Architecture Decision (ADR)
- ✅ Build Design
- ✅ Documentation
Build не содержит реализации программного кода, поэтому этапы Implementation и Compile Check не требуются.
Статус Build:
```text
Accepted
```
---
# Итог
Build 017 открывает новый этап развития платформы Dzentra.
Если Build 013016 сформировали аналитическую подсистему **Market Intelligence**, то начиная с Build 017 начинается построение **Trading Layer** — подсистемы принятия торговых решений.
Это завершает проектирование аналитической части платформы и создаёт фундамент для разработки профессиональной системы управления торговлей.
---
# Следующий Build
```text
Build 017.1
Trading Models
trading/common/models.py
```