# 02. Владение Динамическими Tubes

Статус: не начат. Зависимости: 01.

## Цель

Однозначно назначать процесс всем возможным именам tubes без постоянного реестра самих очередей и без конкурентного claim при каждом создании.

## Контракт

```text
partition = stable_hash(validated_tube_name) % PARTITION_COUNT
owner_slot = partition_map[partition]
```

- Hash работает с точными байтами имени по протоколу: без изменения регистра, locale-зависимой обработки и рандомизации между процессами.
- `PARTITION_COUNT` фиксирован и не равен числу живых процессов по определению. Число разделов, алгоритм и карта выбираются в 01.
- Owner slot не является PID. Перезапуск процесса не меняет принадлежность имён.
- Все процессы подтверждают одинаковые fingerprint/version топологии до обслуживания запросов.
- Данные с несовместимой картой не открываются для записи. Отсутствующая или повреждённая метаинформация не должна вызывать создание новой карты поверх существующих данных.
- Без WAL карта всё равно должна быть единой для живого логического сервера. При полном запуске без сохранённых данных допустима новая явно заданная конфигурация.

## Задачи

1. Реализовать проверку и загрузку карты разделов, стабильный router и тестовые векторы hash.
2. Отделить разрешение владельца от локального поиска/создания объекта. `find` не имеет побочного эффекта `create`.
3. Оставить `tube_find_or_make` или его минимально изменённый эквивалент внутри владельца. Реестр локальных tubes содержит только его объекты.
4. Обрабатывать `use`, `watch`, `ignore` и disconnect через ссылки логических сессий. Подтверждать изменение клиентского состояния после корректного изменения ссылок; предусмотреть rollback частичного attach.
5. Сохранять tube пока есть job любого живого состояния или удерживающая клиентская/системная ссылка. Удалять после освобождения последней ссылки без изменения карты.
6. Определить `default`: одна логическая tube на всём сервере у вычисленного владельца, не отдельная пользовательская очередь в каждом процессе. Сохранить штатную системную ссылку, если она нужна для эквивалентности текущему `prot_init`.
7. При WAL replay создавать tubes у соответствующего владельца; чужое имя в WAL должно выявлять неверную топологию/раскладку данных, а не тихо создавать вторую tube.

## Сценарий Одновременного Создания

Два frontend получают `use emails` и `watch emails`. Оба вычисляют один slot. Его event loop обрабатывает сообщения последовательно: первое создаёт tube, второе находит ту же tube и добавляет свою ссылку. Дополнительная distributed lock или таблица claims на имя не нужна.

Эксклюзивный claim требуется для самого owner slot и обеспечивается supervisor из эпика 06.

## Приёмка

- Hash-векторы одинаковы между процессами и перезапусками; тесты включают допустимые граничные имена, регистр и максимальную длину.
- Параллельные `use`/`watch` одной новой tube через разные frontend создают один объект у одного владельца и корректные счётчики ссылок.
- `stats-tube`/`pause-tube` несуществующего имени возвращают `NOT_FOUND` и не оставляют объект.
- Tube с reserved job не удаляется после ухода остальных клиентов.
- Пустая обычная tube удаляется после последней ссылки; повторное создание попадает в тот же slot.
- `default` представлен один раз в `list-tubes`; подключения не создают локальные копии в остальных owners.
- Авария frontend освобождает его ссылки; запоздалый attach старого поколения не воскрешает сессию.
- Подмена hash, карты или числа разделов при существующих данных приводит к безопасному отказу запуска, а не перемаршрутизации.

## Не Делать

Никакого `hash(name) % live_owners`, переноса очередей при сбое, автоматического распределения новых tubes по текущей нагрузке или долговечного каталога пустых tubes.

## Точки Кода

`tube.c`, `conn.c:on_watch/on_ignore`, `prot.c:prot_init/dispatch_cmd/prot_replay`, `dat.h:Tube`, новый минимальный модуль топологии при необходимости.