diff --git a/family/how-to/arr-stack-taiga.md b/family/how-to/arr-stack-taiga.md
index de6642da..70250f08 100755
--- a/family/how-to/arr-stack-taiga.md
+++ b/family/how-to/arr-stack-taiga.md
@@ -255,9 +255,19 @@ Nautilus Pompilius (artist 69, MBID 247efe0f-80f1-477c-a4a0-b5cb1b8c832e) monito
 
 Реальная общая причина ожидания: активные загрузки Transmission 4.1.3 перестали учитывать уже записанные блоки и не завершались, удерживая очередь. У 26 активных музыкальных загрузок downloadedEver превышал размер раздачи более чем вдвое; суммарное превышение около 2,97 ТБ, помимо отдельно проверенной Мельницы (887 ГБ при размере 125 МБ). Это не признак выполненной загрузки. У большинства haveValid=0 при наличии файлов в incomplete; corruptEver не объяснял объём повторов. Перед восстановлением сохранены settings, live session, torrents/resume и снимки RPC в `/mnt/RED_2TB/docker/transmission/backfill-recovery-20261104T114242Z/`.
 
-Выполнена штатная `torrent-verify`: сначала одна диагностическая раздача Мельницы восстановилась до 100%, затем все 26 загрузок с тем же подтверждённым признаком. Всего восстановлен прогресс 27 загрузок; первые три дошли до 100%. В History Lidarr подтверждён реальный импорт Мельницы и Ногу свело!, Би-2 получил отдельный albumImportIncomplete. Затем Transmission штатно перезапущен, ограничения очереди 10 / stalled 5 минут сохранились. После перезапуска haveValid и percentDone растут вместе с принятыми байтами (например, The Hatters с 5,6% до 44,7%); очередь больше не следует оценивать только по downloadedEver. Конкретный кодовый дефект клиента не установлен; не приписывать его неподтверждённо cache-size или известной ошибке нулевых файлов.
+Выполнена штатная `torrent-verify`: сначала одна диагностическая раздача Мельницы восстановилась до 100%, затем все 26 загрузок с тем же подтверждённым признаком. Всего восстановлен прогресс 27 загрузок; первые три дошли до 100%. В History Lidarr подтверждён реальный импорт Мельницы и Ногу свело!, Би-2 получил отдельный albumImportIncomplete. Затем Transmission штатно перезапущен, ограничения очереди 10 / stalled 5 минут сохранились. После перезапуска haveValid и percentDone растут вместе с принятыми байтами (например, The Hatters с 5,6% до 44,7%); очередь больше не следует оценивать только по downloadedEver. На этом этапе было выполнено только разовое восстановление. Причина и постоянная настройка установлены последующим расследованием ниже.
 
-Для проверки именно запроса пользователя Nautilus поднят штатным `queue-move-top` из конца общей очереди; это разовая смена порядка проверки после общего восстановления, без индивидуального профиля, ручного повторного добавления релиза или исключения в worker. Реальная приёмка: Nautilus сам перешёл из queued в downloading через обычную очередь (без torrent-start-now). На 2026-11-04 11:52:22 UTC downloadedEver=29 592 161, haveValid=28 035 681, percentDone≈0,213%, rateDownload=2 236 416 байт/с, peersConnected=1, errorString пуст. Снимок `/mnt/RED_2TB/docker/transmission/backfill-recovery-20261104T114242Z/nautilus-transfer-verified.json`. Полную загрузку и импорт 14-ГБ пакета ещё не считать завершёнными.
+**Установленная причина и предотвращение повторения.** В Docker log первая локальная ошибка — 2026-11-02T11:34:24+0700 (04:34:24 UTC): у Би-2 «Горизонт Событий» файл с русским названием имеет компонент 272 байта (277 с `.part`) при лимите файловой системы 255. Ошибка `Filename too long (36)` оставляет непишущиеся блоки в общем кеше Transmission 4.1.3. Последующие записи других раздач повторно пытаются вытеснить этот блок и получают чужую ошибку; байты принимаются, но `GotBlock` не публикуется и прогресс не растёт. Это соответствует [разбору и коду PR 9049](https://github.com/transmission/transmission/pull/9049). PR не устанавливался: он ещё не включён в релиз.
+
+Штатная [возможность обхода внутреннего кеша](https://github.com/transmission/transmission/pull/5668) присутствует в текущем бинарнике: в `Cache::write_block` при `cache-size-mb=0` выполняется запись через `tr_ioWrite` без общего кеша. Установлено **`cache-size-mb=0`**, подтверждено в RPC и settings.json после перезапуска. Это предотвращает распространение ошибки одного торрента на остальные; кеш файловой системы ZFS продолжает работать. Периодические перезапуски или перепроверки как «лечение» не добавлялись.
+
+Воспроизведение выполнено в изолированных временных контейнерах из **того же image SHA** `d3adeda7a820f2fb562243e413b50973d2fc2ba0fe78eb0612b76dd8936c7a50`, с внутренней Docker-сетью, собственными синтетическими сидером/трекером, без mounts production и без внешних раздач. При кеше 4 МБ намеренно длинное имя первой раздачи вызывает ту же ошибку, а исправная соседняя принимает 8 192 000 байт с haveValid=0 и 0%. При кеше 0 та же ошибочная раздача останавливается отдельно, исправная принимает ровно 8 388 608 байт, проверяет их и достигает 100%. Результаты: `cache-regression-20261104T121040Z/cache-{4,0}/result.json` под каталогом бэкапа. Контейнеры и временная сеть удалены.
+
+Устранён также исходный триггер для будущей музыки: native `script-torrent-added` вызывает `/config/hooks/normalize_music_paths.py`. Только у Lidarr-торрентов он автоматически сокращает недопустимые UTF-8-компоненты пути через штатный `torrent-rename-path`, учитывая 255 байт для каталога и 250 байт для имени файла с резервом `.part`. Короткий вариант ≤240 байт сохраняет расширение и получает 12-символьный хеш исходного имени, чтобы различать похожие длинные названия. Меняется путь в клиенте, содержимое и infohash не меняются; обычные имена, другие категории и пользовательские паузы сохраняются. RPC выполняется на собственном интерфейсе контейнера с существующей авторизацией: loopback в данной установке исключён из WHITELIST; правила доступа не расширялись.
+
+Проверены 4 теста UTF-8-границ файлов/каталогов, различения одинаковых обрезанных префиксов, обновления дочерних путей, сохранения пользовательских пауз и возобновления только ошибки длинного имени локально и на NAS. Дополнительная нативная приёмка on-add hook: синтетическое русское имя из 284 байт автоматически сокращено, обе раздачи дошли до 100%, SHA256 файла совпал с исходными данными. Результаты `hook-regression-20261104T121545Z/cache-0-hook/result.json`. На production проверена **341** ожидающая музыкальная раздача, найден и исправлен **1** длинный компонент (hash `faba14712299d9a29836366a48ed9f0283eef76b`, 272→240 байт); только этот ранее автоматически начатый, но остановленный по Filename too long торрент возвращён в обычную очередь. Остальные паузы сохранены. Снимки `added-hook-before.json`, `overlong-paths-before.json`, `overlong-paths-fixed.json` и исходный/новый скрипт — в том же бэкапе. Для отката вернуть только сохранённые поля кеша и on-add hook; не подменять живую БД или весь каталог загрузок.
+
+Для проверки именно запроса пользователя Nautilus поднят штатным `queue-move-top` из конца общей очереди; это разовая смена порядка проверки после общего восстановления, без индивидуального профиля, ручного повторного добавления релиза или исключения в worker. Реальная приёмка: Nautilus сам перешёл из queued в downloading через обычную очередь (без torrent-start-now). На 2026-11-04 11:52:22 UTC downloadedEver=29 592 161, haveValid=28 035 681, percentDone≈0,213%, rateDownload=2 236 416 байт/с, peersConnected=1, errorString пуст. Снимок `/mnt/RED_2TB/docker/transmission/backfill-recovery-20261104T114242Z/nautilus-transfer-verified.json`. После постоянного исправления подтверждены 8 144 194 145 принятых байт, haveValid=7 846 218 337, прогресс 58,6%, скорость 8 503 296 байт/с, ошибок нет. Исходно сбойная раздача Би-2 также вернулась к status=4, errorString пуст; после постоянного исправления ещё одна другая раздача завершилась сама. Итоговые настройки и состояние сохранены в `root-fix-final-validation.json`: cache-size-mb=0 и on-add hook включён как в живом RPC, так и на диске; Health Lidarr `[]`. Полную загрузку и импорт 14-ГБ пакета ещё не считать завершёнными.
 
 ### Общая обработка названий RuTracker и очереди Transmission, 2026-11-02