# План: web-split (разбиение `internal/web`)

**Статус:** согласовано  
**Версия:** `1.x`; внутренний рефакторинг, сам по себе breaking не тянет.

---

## Что это

`internal/web` — самый крупный пакет проекта: ~50 файлов (включая шаблоны и
static), ~25 `.go` / ~4000 строк Go, в одной плоскости лежат хендлеры всех
разделов панели, сессии, security-заголовки, проверка Origin, валидация форм и
рендер шаблонов.

Кандидаты на выделение — `web/handlers` и `web/auth`, либо разрез по доменам
панели.

## Почему сейчас

На нынешнем размере плоский пакет читается: имена файлов (`handlers_domains.go`,
`handlers_apps.go`, `handlers_monitor.go`) работают не хуже каталогов, а
разбиение потянуло бы за собой экспорт того, что сейчас пакетно-приватно, — то
есть расширение внутреннего API ради косметики.

Смысл появляется, когда пакет начнёт расти: **domain-admin** и **inbound-relay**
добавляют в него код — роль приносит авторизацию в каждый хендлер, входящий
релей — отдельные страницы и хендлеры входящих доменов. Рефакторинг дешевле
делать перед этим ростом, чем после.

## Рекомендуемый порядок

**web-split → domain-admin → inbound-relay** (см. [roadmap](../roadmap.md)).

1. **web-split** — заложить структуру пакета (в т.ч. место под `web/auth`), пока
   нет сквозных правок от роли и новых inbound-хендлеров.
2. **domain-admin** — авторизация в каждом хендлере опирается на уже выбранную
   схему пакета.
3. **inbound-relay** — новый вертикальный срез; проще добавить в уже разрезанный
   пакет, чем рефакторить вместе с двумя предыдущими фичами.

Порядок рекомендация, не блокер.

## Готово, когда

Решение принято осознанно в момент старта работ — либо пакет разрезан по
выбранной схеме, либо зафиксировано, что он остаётся плоским. После разрезки:
`build`/`vet`/`test` зелёные, поведение панели неизменно.

## Риски

- Преждевременное разбиение — лишний внутренний API и churn без выгоды;
- откладывание до после роста — сложнее рефакторинг в перемешку с фичами.