# 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 как подсистему долгоживущих сервисов:

```text
TradeRuntimeRegistry
│
├── TradeStreamConsistencyController
└── TradeRecoveryController
```

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

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

`TradeRuntimeRegistry` не хранит:

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

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

```text
consistency:BTCUSD
        ↓
TradeStreamState
```

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

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

---

# Предпосылки

## Build 057

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

Каталог:

```text
src/market_data/acquisition/runtime/
```

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

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

---

## Build 060.1

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

```text
Trade
```

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

---

## Build 060.17

Построен Trades Feed.

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

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

---

## Build 060.18

Введены:

```text
TradeStreamConsistencyController
TradeStreamState
```

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

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

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

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

```text
Trade Stream Consistency
```

---

## Build 060.19

Введён:

```text
TradeRecoveryController
```

Recovery:

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

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

---

## Build 060.20

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

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

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

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

```text
TradeRuntimeRegistry
src/market_data/acquisition/runtime/trade/
```

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

---

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

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

```text
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 обычно каталогизирует сервисы, адаптеры или реализации контрактов.

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

```text
symbol → TradeStreamState
```

Это State Store.

---

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

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

```text
str → Any
```

Это создаёт:

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

---

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

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

```text
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 является:

```text
TradeStreamConsistencyController
```

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

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

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

```text
TradeStreamConsistencyController
        ↓
State access abstraction
        ↓
Store by symbol
        ↓
TradeStreamState
```

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

```text
TradeStreamStateStore
```

---

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

Build 060.20.1 заменяет:

```text
TradeRuntimeRegistry
```

на:

```text
TradeStreamStateStore
```

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

```text
TradeStreamConsistencyController
        ↓
TradeStreamStateStoreProtocol
        ↓
TradeStreamStateStore
        ↓
TradeStreamState
```

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

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

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

---

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

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

Владелец:

```text
Trade Stream Consistency
```

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

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

---

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

Владелец:

```text
TradeStreamStateStore
```

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

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

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

---

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

Владелец:

```text
Acquisition Composition
```

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

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

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

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

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

---

## Исполнение Acquisition

Владелец:

```text
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 хранит только:

```text
TradeStreamState
```

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

## 3. Symbol Is the Public Key

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

```text
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

Новые файлы:

```text
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

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

```python
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:
        ...
```

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

```text
get_or_create(symbol)
```

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

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

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

---

# Создание TradeStreamState

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

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

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

---

# Исключения Store

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

```text
TradeStreamStateStoreError
├── InvalidTradeStreamSymbolError
└── TradeStreamStateNotFoundError
```

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

---

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

Market Data Storage хранит:

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

TradeStreamStateStore хранит:

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

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

---

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

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

```text
start
stop
heartbeat
reconnect
schedule
supervise
runtime events
transport lifecycle
```

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

```text
symbol → TradeStreamState
```

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

---

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

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

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

```text
TradeStreamConsistencyProtocol
```

---

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

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

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

---

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

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

```text
TradeGapState
TradeGapStateStore
```

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

```text
TradeRecoveryStateStore
```

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

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

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

---

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

```text
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
```

Подкаталог:

```text
runtime/trade/
```

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

---

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

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

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

```text
TradeRecoveryController
        ↓
TradeStreamConsistencyProtocol
        ↓
TradeStreamConsistencyController
        ↓
TradeStreamStateStore
```

Recovery не знает о Store.

---

# Dependency Injection

```text
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 использует:

```text
in-memory only
```

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

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

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

---

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

## Новые файлы

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

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

```text
trade_stream_consistency_controller.py
```

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

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

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

```text
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.

---

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

Новый файл:

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

Он заменяет:

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

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

```text
test_trade_stream_consistency_controller.py
```

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

```text
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

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

```text
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:

```text
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:

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

После Build:

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

---

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

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

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

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

```text
Trade Stream State
```

и:

```text
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 исправляет архитектурную неточность без изменения бизнес-поведения.

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

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

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

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