Build 060.25: implement Production Runtime Integration

This commit is contained in:
2026-07-31 00:29:36 +03:00
parent c142145361
commit 60bec1eaf9
50 changed files with 14044 additions and 83 deletions

View File

@@ -1,12 +1,245 @@
# Master Roadmap — Dzentra Bot
# Master Roadmap — Dzentra
## Контроль документа
| Свойство | Значение |
|---|---|
| Тип | Master Delivery Roadmap |
| Статус | Active |
| Версия | 2.0 |
| Дата актуализации | 2026-07-31 |
| Текущий завершённый Build | 060.25 |
| Следующий Build | 060.26 |
---
## Цель проекта
Создать Telegram-бота для:
- ручной торговли;
- мониторинга рынка;
- автоторговли;
- аналитики;
- управления стратегиями.
Dzentra развивается из работающего Telegram trading bot в модульную
алгоритмическую торговую платформу, которая поддерживает:
- получение и хранение рыночных данных;
- Market Intelligence и объяснимую аналитику;
- ручные и автоматические торговые решения;
- управление риском, исполнением и позициями;
- аудит и воспроизводимость решений;
- безопасный production runtime;
- исторический Replay и Backtesting.
Целевая карта доменов и направление зависимостей определены в:
```text
docs/architecture/dzentra_target_architecture.md
```
Настоящий roadmap определяет порядок реализации. Подробные решения и
test evidence находятся в документах конкретных Build.
---
# Текущая контрольная точка
```text
Market Data Acquisition
Trades Feed / Time & Sales
Build 060.25 — Production Runtime Integration
Completed
```
060.25.0060.25.8 приняты. Trade Stream:
- подключён к application bootstrap через отдельный feature flag;
- владеет WebSocket lifecycle;
- восстанавливает подписки и пропущенные Trades;
- сохраняет порядок Recovery → buffered Live;
- использует transport Ping/Pong liveness;
- детерминированно останавливает и ожидает owned tasks;
- прошёл 445 целевых тестов и полную регрессию из 1869 тестов.
Подробности:
```text
docs/migrations/build_060_25_architecture.md
docs/migrations/build_060_25.md
```
---
# Активная программа — Market Data Acquisition
## Завершённая ветка Trades Feed
| Build | Результат | Статус |
|---|---|---|
| 060.1060.19 | Canonical Trade, REST/WS pipelines, Consistency и Recovery foundation | Completed |
| 060.20 | Trade Runtime Architecture | Completed |
| 060.20.1 | Trade Stream State Ownership Alignment | Completed |
| 060.21 | Runtime Protocol Integration | Completed |
| 060.22 | Runtime Service Integration | Completed |
| 060.23 | Trade Stream Acquisition Integration | Completed |
| 060.24 | Runtime Recovery Architecture | Completed |
| 060.25 | Production Runtime Integration | Completed |
## Следующие Build
### Build 060.26 — Integration and Regression
**Статус:** Next
Назначение:
- live exchange integration checks;
- длительные reconnect scenarios;
- recovery при реальных сетевых задержках;
- network fault injection;
- stress и soak testing;
- проверка отсутствия утечек задач и ресурсов;
- финальная verification Runtime documentation.
Build не должен превращать сетевые сценарии в обязательную часть
обычного unit suite.
### Build 060.27 — Persistent Market Data Storage
**Статус:** Planned
Назначение:
- долговременное хранение Canonical Trades;
- подготовка хранения Quotes и Candles;
- ключи идемпотентности и ordering;
- raw/canonical retention policy;
- Storage API;
- партиционирование, retention и data provenance.
Результат: история рынка сохраняется независимо от торгового цикла и
времени жизни процесса.
### Build 060.28 — Persistent Checkpoint and Startup Recovery
**Статус:** Planned
Назначение:
- Checkpoint Service;
- сохранение runtime checkpoint;
- восстановление после перезапуска;
- сверка checkpoint с durable Market Data;
- Startup Recovery;
- защита от повторной обработки и пропусков.
Persistent checkpoint не заменяет Market Data Storage и не должен
считаться более достоверным, чем подтверждённая сохранённая история.
### Build 060.29 — Market Data Access and Replay
**Статус:** Planned
Назначение:
- Data Access Layer;
- Historical Queries;
- Replay API;
- детерминированные replay-часы;
- одинаковые Canonical contracts для live и replay consumers.
Полноценные аналитические вычисления не входят автоматически в этот
Build. Они принадлежат Market Data Processing и Feature Engineering и
получат отдельный scope после появления устойчивого Storage/Replay.
### Build 060.30 — Market Data Acquisition Final Documentation
**Статус:** Planned
Назначение:
- итоговый аудит ветки Trades Feed;
- проверка контрактов и направления импортов;
- сверка фактической структуры файлов;
- эксплуатационная документация Runtime;
- обновление architecture overview и project structure;
- фиксация известных ограничений и следующей Feed-ветки.
### Build 061.00 — Validation and Canonicalization Boundary Refactoring
**Статус:** Planned
Сначала выполняется read-only аудит фактического ownership:
```text
schema validation
parser
value validation
normalization
mapper
canonical model
consistency
data quality
missing data recovery
```
Только после аудита определяется, нужен ли отдельный каталог
`market_data/normalization`. Механический перенос существующих
валидаторов не является целью Build.
---
# Дальнейшие программы
После 061.00 следующая Feed-ветка выбирается на основании фактических
production consumers и доступных данных Dzengi.
Кандидаты:
- Quotes lifecycle consolidation;
- OHLCV/Candles production integration;
- Order Book snapshot and delta reconciliation;
- Derivatives Market Data;
- Market Index;
- Exchange Time;
- Exchange and Instrument Status.
Нумерация и точный scope этих Build утверждаются только после отдельного
read-only архитектурного анализа. Старый ориентировочный план из
`build_044.md` сохраняет историческую ценность, но больше не является
актуальной нумерацией.
Следующие верхнеуровневые программы пока не имеют утверждённых Build:
- Market Data Processing;
- Feature Engineering;
- Market Intelligence consolidation;
- Scenario Evaluation;
- Portfolio and Risk boundary;
- Order Management System;
- Position and Account Reconciliation;
- Backtesting and Simulation;
- Production Deployment and Operations.
---
# Правила ведения roadmap
1. Один Build изменяет одну подтверждённую архитектурную область.
2. Перед Build выполняется read-only анализ фактического кода и тестов.
3. Дальние номера являются ориентиром до утверждения architecture plan.
4. Каждый Build имеет критерии завершения и проверяемый test evidence.
5. Архитектурные findings исправляются до статуса Accepted.
6. Итоговый migration report создаётся после завершения Build.
7. Master roadmap хранит только последовательность и статус, а не
дублирует подробную архитектурную спецификацию.
8. Посторонние изменения рабочего каталога не включаются в Build.
---
# Исторический roadmap Stage 0109
Раздел ниже сохраняет историю развития первоначального Telegram bot.
Его локальные пометки `в работе`, `не начат` и прежняя нумерация
являются историческим снимком, а не текущим источником следующего шага.
---
@@ -135,7 +368,7 @@
✔ minimal trading layout
✔ duplicate info removal
#### 07.4.3.2 — Engine Decoupling (NEXT)
#### 07.4.3.2 — Engine Decoupling ✅
✔ split analysis / UI refresh
✔ fast price polling (1s)
✔ slow UI updates (event-driven / 60s)
@@ -1491,5 +1724,12 @@
## Текущий статус проекта
👉 Завершён: 07.4.3.1
👉 Следующий шаг: 07.4.3.2 — Engine Decoupling + Price Polling
Этот блок исторического Stage-roadmap больше не определяет текущий
следующий шаг.
Актуальная контрольная точка:
```text
Завершён: Build 060.25 — Production Runtime Integration
Следующий: Build 060.26 — Integration and Regression
```