Потоки выполнения — как система реально устроена

Статус: current (as-built), сверено на commit 544d4e51. Этот раздел описывает систему как построено — по реальному коду, а не по замыслу. Целевой дизайн сервисных границ живёт в ../30-services/, целевые бизнес-сценарии — в ../10-business/scenarios/. Эти два корпуса документации не смешиваются: если факт из 60-flows/ расходится с 30-services/ или 10-business/scenarios/, верным считается 60-flows/, а расхождение — повод обновить целевой документ или завести ADR.

Зачем нужен этот раздел

В 30-services/ и 10-business/scenarios/ описано, какой система должна стать. Но за время развития проекта код и целевой дизайн разошлись местами: часть задуманного не реализована, часть реализована иначе, часть endpoint’ов, упомянутых в target-документах, физически не существует (пример: POST /v1/jobs/fetch в supplier-sync — см. entry-points.md).

60-flows/ закрывает этот разрыв: здесь каждый факт проверен непосредственно по коду и снабжён точной ссылкой file:line. Раздел нужен, когда требуется:

• быстро найти реальную точку входа в систему (тикер, HTTP-хендлер, Kafka-consumer, CLI);
• проследить, как конкретный поток данных на самом деле проходит через слои (например, Russvet: supplier-sync → БД/raw-хранилище → charnorm-worker → matcher-worker/LLM → canonical-assignment-worker → БД);
• провести impact-анализ или дебаг, отталкиваясь от проверенного факта, а не от предположения.

Чем это отличается от target-доков

	30-services/, 10-business/scenarios/	60-flows/
Что описывает	Целевую архитектуру, как должно быть	Реальный код, как есть сейчас
Источник истины	Дизайн-решения, ADR, спецификации	Символы кода (file:line)
Актуальность	Может опережать код	Сверяется на конкретный commit
Что делать при расхождении	Считать ориентиром на будущее	Считать фактом; расхождение с target — повод для ADR/обновления target-документа

Как читать раздел

Раздел организован сверху вниз — от точки входа к конкретному use-case:

1. entry-points.md — сквозная карта всех точек входа в систему по всем слоям: тикеры, HTTP, Kafka, CLI. Начинайте отсюда, если не знаете, откуда стартует нужный вам поток.
2. Слой — каталог вида 10-ingestion/, 20-<следующий-слой>/ и т.д. (слои добавляются по мере разбора системы). У каждого слоя есть свой README.md с обзором участников слоя и ссылками на use-case файлы.
3. Use-case файл — конкретный сквозной сценарий внутри слоя (например, 10-ingestion/russvet.md — как данные Russvet проходят весь путь). Такие файлы добавляются последующими задачами инициативы.

Содержание раздела на сейчас

• entry-points.md — карта точек входа (ingestion-core + Russvet).
• 10-ingestion/README.md — обзор слоя загрузки данных от поставщиков.
• 20-analogs/README.md — сквозной конвейер подбора аналогов: от сырья поставщика до выдачи, словарь терминов, состояние «сделано/осталось».

Остальные слои (нормализация, матчинг, canonical-assignment, публичный API и т.д.) будут добавлены последующими задачами инициативы по мере разбора кода.