dzentra_bot/docs/migrations/build_060_20_1_architecture.md

Build 060.20.1 — Trade Stream State Ownership Alignment

Статус: Architecture Specification
Build: 060.20.1
Ветка: Trades Feed (Time & Sales)
Документ: build_060_20_1_architecture.md
Тип Build: Corrective Architecture Build
Предыдущее рабочее название: Trade Runtime Terminology Alignment

Связанные документы:

• build_060_20_architecture.md;
• build_060_20.md;
• build_060_19_architecture.md;
• build_060_18_architecture.md.

---

Назначение документа

Настоящий документ является официальной архитектурной спецификацией Build 060.20.1 — Trade Stream State Ownership Alignment.

Документ определяет:

• фактическую природу состояния подсистемы Trades Feed;
• владельца инфраструктурного состояния Trade Stream;
• границу между Trade Stream Consistency и Acquisition Runtime;
• причины отказа от TradeRuntimeRegistry;
• целевую модель TradeStreamStateStore;
• публичные контракты;
• файловый план миграции;
• ограничения Scope;
• стратегию тестирования;
• архитектурные инварианты;
• критерии завершения Build.

Build 060.20.1 не отменяет функциональный результат Build 060.20. Он корректирует терминологию, расположение файлов, типизацию и модель владения уже реализованным состоянием.

Документ является единственным источником истины для реализации Build 060.20.1.

---

Статус Build

Build 060.20.1 выполняется непосредственно после Build 060.20 и до начала интеграционных этапов 060.21+.

На момент начала Build в системе уже существуют:

• каноническая модель Trade;
• Trades Feed;
• TradeStreamConsistencyController;
• TradeStreamState;
• TradeRecoveryController;
• REST Recovery Pipeline;
• TradeRuntimeProtocol;
• TradeRuntimeRegistry;
• Runtime-исключения;
• unit-тесты Runtime Registry;
• unit-тесты Trade Stream Consistency;
• unit-тесты Trade Stream State.

Функциональная проблема отсутствует. Система уже сохраняет состояние потока между последовательными операциями.

Проблема носит архитектурный характер:

фактическая реализация Build 060.20 не соответствует терминам, границам и модели владения, зафиксированным в первоначальной Architecture Specification.

---

Причина появления корректирующего Build

Первоначальная спецификация Build 060.20 описывала Trade Runtime как подсистему долгоживущих сервисов:

TradeRuntimeRegistry
│
├── TradeStreamConsistencyController
└── TradeRecoveryController

Предполагалось, что Registry будет регистрировать, хранить и предоставлять Runtime-компоненты.

Фактическая реализация пошла по другой модели.

TradeRuntimeRegistry не хранит:

• TradeStreamConsistencyController;
• TradeRecoveryController;
• Feed;
• Handler;
• адаптеры;
• Supervisor;
• Reconnect;
• Scheduler;
• Heartbeat.

Фактически он хранит объекты состояния по строковым ключам:

consistency:BTCUSD
        ↓
TradeStreamState

Следовательно реализованный компонент является не Registry сервисов, а key-value хранилищем оперативного состояния.

Это расхождение должно быть устранено до дальнейшей интеграции Trades Feed с настоящим Acquisition Runtime.

---

Предпосылки

Build 057

Сформирована базовая архитектура Market Data Acquisition.

Каталог:

src/market_data/acquisition/runtime/

предназначен для компонентов исполнения и жизненного цикла Acquisition:

• supervisor;
• reconnect;
• scheduler;
• heartbeat;
• runtime commands;
• runtime events;
• transport messages;
• WebSocket protocol.

---

Build 060.1

Введена каноническая модель:

Trade

Источник данных не должен влиять на последующую обработку Trade Stream.

---

Build 060.17

Построен Trades Feed.

Feed отвечает за получение и публикацию канонических сделок, но не должен владеть:

• последовательностью;
• дедупликацией;
• Recovery;
• runtime-жизненным циклом;
• историческим хранилищем.

---

Build 060.18

Введены:

TradeStreamConsistencyController
TradeStreamState

TradeStreamConsistencyController отвечает за правила согласованности потока.

TradeStreamState содержит состояние, необходимое для:

• контроля порядка;
• дедупликации;
• обнаружения конфликтующих повторов;
• определения непрерывности;
• сохранения последней принятой позиции потока.

Build 060.18 корректно определил бизнес-владельца состояния:

Trade Stream Consistency

---

Build 060.19

Введён:

TradeRecoveryController

Recovery:

• получает исторические сделки;
• передаёт их в Consistency;
• формирует результат восстановления.

Recovery остаётся stateless и не владеет TradeStreamState.

---

Build 060.20

Build 060.20 обеспечил повторное использование долгоживущего состояния.

Функциональный результат корректен:

• состояние вынесено из локального жизненного цикла операции;
• состояние доступно через отдельный контракт;
• один объект повторно используется для одного символа;
• разные символы получают независимые состояния.

Ошибка заключается в названии и размещении:

TradeRuntimeRegistry
src/market_data/acquisition/runtime/trade/

Реализация получила слишком широкую абстракцию и была помещена в неверную архитектурную область.

---

Архитектурный контекст Dzentra

Общий поток системы:

Market Data Acquisition
        ↓
Data Validation & Normalization
        ↓
Market Data Storage
        ↓
Market Data Processing
        ↓
Feature Engineering
        ↓
Market State Estimation
        ↓
Forecasting Models
        ↓
Trading Decision
        ↓
Risk Management
        ↓
Execution Management

TradeStreamState не является:

• историей сделок;
• Trade Storage;
• Market Cache;
• рыночным фактом;
• признаком;
• оценкой состояния рынка;
• прогнозом;
• торговым решением;
• состоянием позиции;
• состоянием соединения.

TradeStreamState является:

оперативным техническим состоянием алгоритма проверки согласованности канонического потока сделок.

Поэтому состояние принадлежит не Market Data Storage и не Acquisition Runtime, а подсистеме Trade Stream Consistency.

---

Архитектурная проблема

1. Неверный термин Runtime

Runtime в Acquisition отвечает за:

• запуск и остановку;
• supervision;
• reconnect;
• heartbeat;
• scheduling;
• runtime events;
• transport lifecycle.

TradeRuntimeRegistry не выполняет ни одной из этих функций.

---

2. Неверный термин Registry

Registry обычно каталогизирует сервисы, адаптеры или реализации контрактов.

Фактическая реализация хранит:

symbol → TradeStreamState

Это State Store.

---

3. Универсальный dict[str, Any]

Текущий контракт допускает:

str → Any

Это создаёт:

• потерю типобезопасности;
• возможность регистрации несовместимого объекта;
• позднее обнаружение ошибки;
• скрытые соглашения о строковых ключах;
• риск превращения Store в Service Locator.

---

4. Утечка namespace ключей

Controller и его тесты знают строки:

consistency:BTCUSD

Это инфраструктурная деталь, которая не должна быть частью бизнес-логики Consistency.

---

5. Размывание ownership

Будущие состояния Consistency, Gap Detection, Recovery, Subscription и Monitoring могут иметь разные:

• типы;
• инварианты;
• жизненные циклы;
• правила создания;
• правила очистки;
• требования к синхронизации.

Общий Any Registry скрывает эти различия.

---

6. Конфликт с фактической архитектурой Recovery

TradeRecoveryController:

• не имеет собственного состояния;
• не использует TradeRuntimeProtocol;
• не регистрируется в Registry;
• зависит только от TradeStreamConsistencyProtocol.

Следовательно Recovery не является Runtime-компонентом в смысле Build 060.20.

---

7. Конфликт документации и кода

Первоначальная Architecture Specification описывает Registry сервисов.

Engineering Migration Report и код фактически описывают Registry состояния.

Build 060.20.1 фиксирует одну официальную модель.

---

Результаты архитектурного аудита

Проверены:

• Runtime Protocol, Registry и Exceptions;
• Consistency Controller, Protocol и State;
• Recovery Controller и Protocol;
• unit-тесты Runtime Registry;
• unit-тесты Consistency Controller;
• unit-тесты Trade Stream State;
• структура market_data/acquisition;
• результаты repository grep;
• место Trades Feed в общей архитектуре Dzentra.

Единственным production-потребителем Runtime является:

TradeStreamConsistencyController

Не обнаружено production-использование со стороны:

• Recovery;
• Feed;
• Handler;
• Adapter;
• Acquisition Service;
• Supervisor;
• Reconnect;
• Scheduler;
• Heartbeat;
• WebSocket Runtime.

Фактическая модель:

TradeStreamConsistencyController
        ↓
State access abstraction
        ↓
Store by symbol
        ↓
TradeStreamState

Корректная архитектурная абстракция:

TradeStreamStateStore

---

Основное архитектурное решение

Build 060.20.1 заменяет:

TradeRuntimeRegistry

на:

TradeStreamStateStore

Целевая модель:

TradeStreamConsistencyController
        ↓
TradeStreamStateStoreProtocol
        ↓
TradeStreamStateStore
        ↓
TradeStreamState

TradeStreamStateStore является внутренней инфраструктурной зависимостью подсистемы Trade Stream Consistency.

Он не является:

• Acquisition Runtime;
• Composition Root;
• Service Registry;
• Market Data Storage;
• Trade Storage;
• глобальным State Registry;
• Recovery Registry.

---

Модель владения

Семантическое владение

Владелец:

Trade Stream Consistency

TradeStreamConsistencyController и TradeStreamState определяют:

• смысл состояния;
• правила его изменения;
• правила дедупликации;
• правила последовательности;
• реакцию на конфликты и разрывы.

---

Инфраструктурное хранение

Владелец:

TradeStreamStateStore

Store отвечает за:

• хранение TradeStreamState;
• адресацию по символу;
• lazy creation;
• повторное предоставление того же экземпляра;
• удаление состояния;
• очистку состояний.

Store не принимает решений о корректности сделки.

---

Жизненный цикл компонентов

Владелец:

Acquisition Composition

Будущая точка композиции должна:

• создать TradeStreamStateStore;
• создать TradeStreamConsistencyController;
• передать Store в Controller;
• передать Controller потребителям.

Store не создаёт Controller.

Controller не создаёт глобальный Runtime.

Recovery не создаёт Store.

---

Исполнение Acquisition

Владелец:

src/market_data/acquisition/runtime/

Acquisition Runtime отвечает за lifecycle, supervision, reconnect, heartbeat и scheduling.

State Store Consistency к этому уровню не относится.

---

Архитектурные принципы

1. State Ownership Is Local

Каждая stateful-подсистема владеет собственным типом состояния.

2. Store Is Typed

Store хранит только:

TradeStreamState

Использование Any запрещается.

3. Symbol Is the Public Key

Публичный контракт использует:

symbol: str

4. Namespace Is Internal

consistency:<symbol> не является публичным API.

5. Lazy State Creation

State создаётся при первом обращении.

6. One Symbol — One State

Один символ связан с одним экземпляром TradeStreamState.

7. Symbol Isolation

Разные символы имеют независимые состояния.

8. Store Has No Trade Logic

Store не выполняет дедупликацию, sequence validation, Gap Detection или Recovery.

9. Controller Has No Storage Details

Controller не формирует ключи и не выполняет ручную регистрацию.

10. Recovery Remains Stateless

Recovery не получает прямую зависимость от Store.

11. Runtime Means Execution Lifecycle

Термин Runtime резервируется для исполнения и жизненного цикла Acquisition.

12. No Premature Global State Store

Build не создаёт TradeStateStore, TradeRuntimeStateStore или GlobalAcquisitionStateStore.

13. Unique File Naming

Новые файлы:

trade_stream_state_store.py
trade_stream_state_store_protocol.py
trade_stream_state_store_exceptions.py

---

TradeStreamStateStore

Назначение

Типизированное in-memory хранилище состояния Trade Stream Consistency.

Ответственность

• lazy creation;
• получение существующего State;
• проверка наличия;
• удаление по символу;
• очистка;
• проверка корректности символа;
• инвариант str → TradeStreamState.

Не отвечает

• за обработку Trade;
• дедупликацию;
• sequence validation;
• Gap Detection;
• Recovery;
• транспорт;
• подписки;
• persistence;
• thread safety;
• Composition Root.

---

TradeStreamStateStoreProtocol

Целевой контракт:

class TradeStreamStateStoreProtocol(Protocol):
    def get_or_create(self, symbol: str) -> TradeStreamState:
        ...

    def get(self, symbol: str) -> TradeStreamState:
        ...

    def contains(self, symbol: str) -> bool:
        ...

    def remove(self, symbol: str) -> None:
        ...

    def clear(self) -> None:
        ...

Главный метод:

get_or_create(symbol)

Он инкапсулирует сценарий:

получить существующее состояние
или создать новое

Точный набор дополнительных методов будет подтверждён реализацией и тестами. Он не должен возвращать универсальную модель Registry.

---

Создание TradeStreamState

В Build 060.20.1 Store создаёт стандартный TradeStreamState самостоятельно.

Фабрика не вводится, поскольку отсутствуют подтверждённые требования к:

• разным конфигурациям по инструментам;
• разным реализациям State;
• восстановлению из persistence;
• внешнему конструктору.

---

Исключения Store

Предлагаемая минимальная иерархия:

TradeStreamStateStoreError
├── InvalidTradeStreamSymbolError
└── TradeStreamStateNotFoundError

Исключение повторной регистрации не является обязательным, поскольку основной контракт использует get_or_create, а не register.

---

Почему Market Data Storage не является владельцем

Market Data Storage хранит:

• канонические сделки;
• свечи;
• котировки;
• стакан;
• историю;
• рыночный cache.

TradeStreamStateStore хранит:

• техническую позицию алгоритма;
• данные дедупликации;
• последовательность обработки;
• внутреннее состояние Consistency.

Persistence может появиться позднее, но это не переносит ownership в Storage.

---

Почему Acquisition Runtime не является владельцем

Acquisition Runtime отвечает за:

start
stop
heartbeat
reconnect
schedule
supervise
runtime events
transport lifecycle

TradeStreamStateStore отвечает за:

symbol → TradeStreamState

Это разные области ответственности.

---

Почему Recovery не является владельцем

Recovery не определяет семантику TradeStreamState, не изменяет его напрямую и не должен создавать Store.

Recovery использует только:

TradeStreamConsistencyProtocol

---

Почему не создаётся общий TradeStateStore

Общий Store отклонён, потому что:

1. отсутствует второй реальный тип состояния;
2. будущие состояния могут иметь разные lifecycle;
3. Any уничтожает типобезопасность;
4. string namespaces становятся скрытым API;
5. появляется риск Service Locator;
6. ownership становится неочевидным;
7. локальная специализированная модель точнее.

---

Будущие stateful-подсистемы

Если Gap Detection получит отдельное состояние, может появиться:

TradeGapState
TradeGapStateStore

Если Recovery получит session state, cursor или retry state, может появиться:

TradeRecoveryStateStore

Состояние подписок относится к subscriptions либо общей Acquisition Runtime infrastructure.

Monitoring относится к отдельному глобальному модулю Dzentra.

Ни одно из этих состояний не хранится в TradeStreamStateStore.

---

Целевая структура каталогов

src/market_data/acquisition/
│
├── consistency/
│   ├── trade_stream_consistency_controller.py
│   ├── trade_stream_exceptions.py
│   ├── trade_stream_protocol.py
│   ├── trade_stream_state.py
│   ├── trade_stream_state_store.py
│   ├── trade_stream_state_store_protocol.py
│   └── trade_stream_state_store_exceptions.py
│
├── recovery/
│   └── ...
│
└── runtime/
    ├── supervisor.py
    ├── reconnect.py
    ├── scheduler.py
    ├── heartbeat.py
    ├── runtime_commands.py
    ├── runtime_events.py
    ├── transport_messages.py
    └── websocket_protocol.py

Подкаталог:

runtime/trade/

удаляется после подтверждения отсутствия зависимостей.

---

Целевая диаграмма взаимодействия

Trade Source
        ↓
Trade Handler
        ↓
Canonical Trade
        ↓
TradeStreamConsistencyController
        ↓
TradeStreamStateStoreProtocol
        ↓
TradeStreamStateStore
        ↓
TradeStreamState
        ↓
Accepted Canonical Trade Stream

Recovery использует ту же boundary:

TradeRecoveryController
        ↓
TradeStreamConsistencyProtocol
        ↓
TradeStreamConsistencyController
        ↓
TradeStreamStateStore

Recovery не знает о Store.

---

Dependency Injection

Composition Root
        ├── TradeStreamStateStore
        ├── TradeStreamConsistencyController
        │       └── StateStoreProtocol
        └── TradeRecoveryController
                └── TradeStreamConsistencyProtocol

Окончательный Composition Root не входит в Scope Build.

---

Последовательность обработки сделки

1. Controller получает Trade.
2. Controller вызывает get_or_create(symbol).
3. Store валидирует символ.
4. Store возвращает существующий State либо создаёт новый.
5. Controller применяет существующую бизнес-логику.
6. Store сохраняет тот же экземпляр для следующих операций.

---

Persistence и Thread Safety

Build использует:

in-memory only

Не реализуются:

• persistence;
• replay state restoration;
• locks;
• async locks;
• distributed coordination.

Эти требования относятся к отдельным Build.

---

План изменений файлов

Новые файлы

src/market_data/acquisition/consistency/
├── trade_stream_state_store.py
├── trade_stream_state_store_protocol.py
└── trade_stream_state_store_exceptions.py

Изменяемый production-файл

trade_stream_consistency_controller.py

Разрешены только локальные изменения:

• новая зависимость Store Protocol;
• удаление namespace keys;
• переход на get_or_create;
• сохранение существующей бизнес-логики.

Удаляемые файлы

src/market_data/acquisition/runtime/trade/
├── trade_runtime_registry.py
├── trade_runtime_protocol.py
└── trade_runtime_exceptions.py

Неизменяемые production-файлы

• trade_stream_state.py;
• trade_stream_protocol.py;
• trade_stream_exceptions.py;
• Recovery files;
• Feed;
• Handler;
• canonical Trade;
• Supervisor;
• Reconnect;
• Scheduler;
• Heartbeat.

---

План изменений тестов

Новый файл:

tests/unit/market_data/acquisition/consistency/
test_trade_stream_state_store.py

Он заменяет:

tests/unit/market_data/acquisition/runtime/trade/
test_trade_runtime_registry.py

Обновляется:

test_trade_stream_consistency_controller.py

Сохраняется без архитектурных изменений:

test_trade_stream_state.py

---

Таблица переименований

Текущая сущность	Целевая сущность
TradeRuntimeRegistry	TradeStreamStateStore
TradeRuntimeProtocol	TradeStreamStateStoreProtocol
trade_runtime_registry.py	trade_stream_state_store.py
trade_runtime_protocol.py	trade_stream_state_store_protocol.py
trade_runtime_exceptions.py	trade_stream_state_store_exceptions.py
test_trade_runtime_registry.py	test_trade_stream_state_store.py
runtime dependency	state_store dependency
consistency:<symbol>	symbol
dict[str, Any]	dict[str, TradeStreamState]
register + get	get_or_create

---

Совместимость

Старые Runtime-имена не используются production-компонентами вне Consistency.

Поэтому compatibility layer не создаётся.

Не вводятся:

• deprecated aliases;
• re-export старых имён;
• wrappers;
• proxy-классы.

Поведенчески должны полностью сохраниться:

• первая сделка;
• последовательная сделка;
• дубликат;
• конфликтующий дубликат;
• Gap;
• повторное использование State;
• независимость символов;
• Recovery;
• Trades Feed.

---

Архитектурные инварианты

1. TradeStreamState принадлежит Consistency.
2. Store хранит только TradeStreamState.
3. Controller не зависит от TradeRuntimeProtocol.
4. Controller не формирует Runtime keys.
5. Store не содержит Trade business logic.
6. Recovery не зависит от Store напрямую.
7. Acquisition Runtime не хранит Consistency State.
8. Один символ возвращает один State.
9. Разные символы имеют независимые State.
10. Store не использует Any.
11. Глобальный State Registry не создаётся.
12. Алгоритмы TradeStreamState не изменяются.

---

Architectural Decision Records

ADR-060.20.1-01 — State Ownership

TradeStreamState принадлежит Trade Stream Consistency.

ADR-060.20.1-02 — Specialized State Store

Используется TradeStreamStateStore. Универсальный TradeRuntimeRegistry удаляется.

ADR-060.20.1-03 — Runtime Boundary

Acquisition Runtime предназначен для execution lifecycle. State Store размещается в consistency/.

ADR-060.20.1-04 — Typed Storage

Используется:

dict[str, TradeStreamState]

ADR-060.20.1-05 — Symbol-Based Contract

Публичная адресация выполняется по symbol.

ADR-060.20.1-06 — Lazy Creation

State создаётся через get_or_create(symbol).

ADR-060.20.1-07 — Recovery Independence

Recovery не получает прямую зависимость от Store.

ADR-060.20.1-08 — No Global State Store

Будущие stateful-подсистемы получают собственные Store при подтверждённой необходимости.

ADR-060.20.1-09 — No Compatibility Layer

Старые Runtime-имена удаляются после обновления зависимостей.

ADR-060.20.1-10 — Business Logic Preservation

Алгоритмы Consistency, State, Recovery, Feed и Handler сохраняются.

---

Стратегия тестирования

Unit Tests State Store

Проверяются:

• создание Store;
• отсутствие состояния до первого обращения;
• lazy creation;
• повторное получение того же экземпляра;
• независимость символов;
• get;
• contains;
• remove;
• clear;
• некорректный символ;
• отсутствие произвольных компонентов;
• хранение только TradeStreamState.

Unit Tests Consistency Controller

Сохраняются все существующие сценарии.

Дополнительно проверяется:

• использование Store Protocol;
• отсутствие namespace в Controller;
• использование get_or_create;
• независимость от конкретной реализации Store.

Regression Tests

Подтверждаются:

• Trades Feed;
• Handler;
• Canonical Trade;
• Consistency;
• Recovery;
• отсутствие изменений Acquisition Runtime.

---

План реализации

Этап 1

Повторный repository search:

TradeRuntime
trade_runtime
acquisition.runtime.trade
consistency:

Этап 2

Создание trade_stream_state_store_protocol.py.

Этап 3

Создание trade_stream_state_store_exceptions.py.

Этап 4

Реализация trade_stream_state_store.py.

Этап 5

Локальная миграция trade_stream_consistency_controller.py.

Запрещается:

• переписывать рабочие алгоритмы;
• менять порядок бизнес-проверок;
• сокращать код вне Scope;
• менять исключения Consistency без отдельного согласования.

Этап 6

Миграция тестов Registry в тесты State Store.

Этап 7

Обновление тестов Controller.

Этап 8

Удаление старых Runtime-файлов и пустого каталога runtime/trade/.

Этап 9

Unit и regression testing, затем repository grep.

Этап 10

Подготовка build_060_20_1.md.

---

Build Boundary

Build отвечает за

• корректировку ownership;
• замену Runtime Registry на State Store;
• типизацию;
• перенос файлов;
• удаление namespace из Controller;
• обновление тестов;
• синхронизацию документации и кода.

Build НЕ отвечает за

• изменение Consistency algorithms;
• изменение TradeStreamState;
• изменение Recovery;
• WebSocket Trades Feed;
• synchronization;
• thread safety;
• persistence;
• replay;
• checkpointing;
• Market Data Storage;
• Gap Detection;
• Scheduler;
• Monitoring;
• Metrics;
• Health Check;
• окончательный Composition Root;
• Builds 060.21+.

---

Риски и меры контроля

Скрытые imports

Контроль: repository grep до и после изменений.

Непреднамеренное изменение Consistency

Контроль: локальная замена только механизма получения State и сохранение всех тестов.

Преждевременное расширение Store

Контроль: Store хранит только TradeStreamState.

Потеря поведения Registry

Контроль: сохраняются только функционально оправданные операции; универсальный register(Any) не переносится.

Нарушение будущей интеграции

Контроль: зависимость через Protocol и отсутствие связи Store с транспортом.

---

Definition of Done

Архитектура

• владелец State определён как Trade Stream Consistency;
• TradeRuntimeRegistry отсутствует;
• TradeStreamStateStore размещён в Consistency;
• Runtime содержит только execution lifecycle infrastructure;
• Store типизирован;
• namespace keys не являются API;
• Recovery остаётся stateless.

Код

• добавлены три файла Store;
• Controller зависит от Store Protocol;
• бизнес-логика Controller сохранена;
• старые Runtime-файлы удалены;
• отсутствуют imports acquisition.runtime.trade;
• отсутствуют production-ссылки TradeRuntime*.

Функциональность

• State создаётся лениво;
• State повторно используется;
• символы изолированы;
• Consistency, Recovery и Feed работают без изменений.

Тестирование

• тесты Store проходят;
• тесты Controller проходят;
• тесты State проходят;
• тесты Recovery проходят;
• regression suite проходит;
• grep не находит старые зависимости.

Документация

• создан build_060_20_1_architecture.md;
• после реализации создаётся build_060_20_1.md;
• противоречие Build 060.20 устранено.

---

Архитектурный результат

До Build:

TradeStreamConsistencyController
        ↓
TradeRuntimeProtocol
        ↓
TradeRuntimeRegistry
        ↓
dict[str, Any]
        ↓
TradeStreamState

После Build:

TradeStreamConsistencyController
        ↓
TradeStreamStateStoreProtocol
        ↓
TradeStreamStateStore
        ↓
dict[str, TradeStreamState]
        ↓
TradeStreamState

---

Взаимодействие с последующими Build

Build 060.20.1 является обязательной коррекцией перед:

Build 060.21 — Runtime Protocol Integration
Build 060.22 — Runtime Service Integration
Build 060.23 — Acquisition Integration
Build 060.24 — Reconnect & Runtime Recovery

Последующие Build должны различать:

Trade Stream State

и:

Acquisition Runtime

State Store используется для Consistency.

Acquisition Runtime используется для lifecycle, supervision, reconnect и orchestration.

---

Заключение

Build 060.20 функционально обеспечил повторное использование состояния Trade Stream, но первоначальная модель Trade Runtime оказалась шире фактической ответственности кода.

Аудит подтвердил:

• Registry не хранит Runtime-сервисы;
• Recovery не является stateful Runtime-компонентом;
• единственный production-потребитель — Consistency;
• единственный предметный тип состояния — TradeStreamState;
• dict[str, Any] не обеспечивает корректную модульную границу;
• размещение в runtime/trade/ конфликтует с назначением Acquisition Runtime.

Build 060.20.1 исправляет архитектурную неточность без изменения бизнес-поведения.

Окончательное решение:

Trade Stream Consistency
        └── владеет TradeStreamState
                └── хранится в TradeStreamStateStore

TradeStreamStateStore становится специализированной типизированной инфраструктурной зависимостью Consistency.

Acquisition Runtime сохраняет самостоятельную ответственность за исполнение и жизненный цикл системы.