ARCHITECTURE.md

Этот файл — верхнеуровневая карта системы. Он должен оставаться лаконичным и указывать на более глубокие документы, когда нужно.

Форма системы

• Продукт: [замените названием продукта]
• Основной пользовательский сценарий: [замените основным сценарием]
• Поверхности рантайма: [desktop / web / cli / services / workers]
• Источник истины для продуктового поведения: docs/product-specs/

Карта доменов

Домен	Назначение	Основные точки входа	Связанная спецификация
[domain-a]	[чем владеет]	[модули / роуты / команды]	[путь к спецификации]
[domain-b]	[чем владеет]	[модули / роуты / команды]	[путь к спецификации]

Модель слоёв

Используйте фиксированную направленную модель, чтобы агенты не выдумывали ad hoc архитектуру:

Types -> Config -> Repo -> Service -> Runtime -> UI

Сквозные сущности должны попадать через явные провайдеры или границы адаптеров, а не тянуться напрямую через слои.

Жёсткие правила зависимостей

• Нижние слои не должны зависеть от верхних.
• UI не должен обходить контракты рантайма или сервисов.
• Доступ к данным должен идти через репозитории или эквивалентные адаптеры.
• Общие утилиты должны оставаться универсальными и не накапливать доменную логику.
• Новые зависимости должны быть обоснованы в соответствующем плане или дизайн-документе.

Сквозные интерфейсы

Сущность	Утверждённая граница	Заметки
Логирование и трейсинг	[провайдер / путь утилиты]	[только структурированно, никакого ad hoc console]
Аутентификация	[путь провайдера]	[правила токенов/сессий]
Внешние API	[путь клиента или провайдера]	[ограничение скорости / правила ретраев]
Feature flags	[граница флагов]	[владение]

Текущие горячие точки

• [область, которую агентам сложнее всего безопасно менять]
• [область со слабыми границами или хрупкими тестами]

Чеклист изменений

Когда вы трогаете архитектурно значимый код:

1. Обновите этот файл, если изменилась карта доменов или допустимые границы.
2. Обновите соответствующий дизайн-документ в docs/design-docs/, если изменилась логика рассуждений.
3. Добавьте или обновите исполняемую проверку, если правило должно быть проверено механически.