Предоставить Аудитору критерии для выявления утечек памяти (Memory Leaks) и избыточного давления на сборщик мусора (GC Pressure). Обеспечить строгие предохранители (Guardrails) при оптимизации аллокаций. На устройствах с малым объемом RAM высокая скорость выделения памяти (Allocation Rate) заставляет GC работать непрерывно. Это блокирует главный поток (Main Thread) и вызывает лаги. Данные, до которых можно добраться от глобального объекта (window/global) или активного замыкания (таймер/событие), никогда не будут удалены GC. Это прямая утечка памяти. Вынос (hoisting) объектов или регулярных выражений из цикла безопасен только в том случае, если их состояние не мутируется и не сохраняется в массив/замыкание на каждой итерации. - Объявление `const cache = new Map();` или `const cache = {};` на уровне модуля (глобально). - Использование функции, которая постоянно делает `cache.set(key, value)`, но нигде не вызывает `cache.delete()` или не имеет лимита размера. Unbounded Cache (неограниченный кэш) бесконечно накапливает ключи и значения. В долгоживущих приложениях (SPA, Node.js серверы) это приводит к исчерпанию памяти (OOM - Out of Memory). Если объект используется как статический справочник (например, маппинг кодов ошибок на строки), размер которого фиксирован и известен заранее — игнорировать. Если уже используется `WeakMap` или `WeakSet`, это безопасно (GC сам очистит память при удалении ключа). "Обнаружен неограниченный кэш [ИМЯ_ПЕРЕМЕННОЙ], ведущий к утечке памяти. Оберни его в реализацию LRU-кэша (с ограничением `maxSize`), либо используй `WeakMap`, если ключами выступают объекты." - Вызов `setInterval(...)` или `window.addEventListener(...)` в компонентах/классах. - Отсутствие вызовов `clearInterval` или `removeEventListener` в методах очистки (например, `componentWillUnmount`, `useEffect` cleanup). Таймеры и глобальные слушатели событий создают "GC Roots" (корни сборки мусора). Любые переменные, захваченные внутри их коллбэков (замыкания), будут жить в памяти вечно, даже если сам компонент или DOM-узел был удален. Если таймер или слушатель должен жить всё время работы приложения (например, глобальный роутер или heartbeat веб-сокета), игнорировать. "Утечка памяти:[ИМЯ_ТАЙМЕРА_ИЛИ_СОБЫТИЯ] не очищается. Сохрани возвращаемый ID таймера или ссылку на функцию-обработчик и добавь вызов очистки (`clearInterval` / `removeEventListener`) в фазу демонтирования/завершения." - `new RegExp(pattern)` внутри циклов `for`, `.map()`, `.filter()`. - `new Intl.DateTimeFormat(...)` или `new Intl.NumberFormat(...)` внутри циклов. Компиляция регулярного выражения или инициализация форматтеров `Intl.*` — крайне тяжелые операции для CPU и памяти. Выполнение их на каждой итерации цикла вызывает катастрофическое падение производительности. Если паттерн регулярки или настройки форматтера зависят от переменной цикла (меняются каждую итерацию), выносить их наружу нельзя. В таком случае предложить кэширование (memoization) инстансов. "Дорогая инициализация [ОБЪЕКТ] внутри цикла. Вынеси инициализацию `new RegExp` / `Intl.*Format` за пределы цикла в константу и переиспользуй её внутри итераций." - Использование spread оператора `...` (например, `acc = [...acc, item]`) внутри `reduce` или циклов. - Вызовы `array.slice()`, `array.concat()` на каждой итерации. - Создание новых объектов `const obj = { id: i }` в высокочастотных циклах (math, render loops). Синтаксис `[...acc, item]` на каждой итерации создает полностью новый массив, копируя все предыдущие элементы. Это дает алгоритмическую сложность O(n^2) по времени и памяти. Создание временных объектов в tight loops переполняет Nursery (младшее поколение кучи), провоцируя постоянные паузы GC. Если архитектура (например, Redux reducer) жестко требует иммутабельности, замена на мутацию (`.push`) сломает стейт-менеджмент. Отклонить, если это чистая функция редюсера. Если создаваемый в цикле объект сохраняется в массив (например, `arr.push(obj)`), НЕЛЬЗЯ выносить создание объекта за цикл и переиспользовать его. Иначе массив будет состоять из ссылок на один и тот же мутированный объект. "Квадратичная аллокация памяти в цикле. Замени копирование `[...acc, item]` или `.concat()` на мутацию локальной переменной через `acc.push(item)`. Для объектов — если объект не сохраняется по ссылке, вынеси его декларацию за цикл и переиспользуй поля." - Сохранение ссылок на DOM-элементы (`document.getElementById(...)`) в JS-объекты или массивы. - Удаление элемента из DOM (`node.remove()` или `innerHTML = ''`), но без `null` в JS-ссылке. Если DOM-узел удален из документа, но JS-переменная всё еще ссылается на него (Detached DOM), сборщик мусора не может удалить ни этот узел, ни всё его поддерево. Это тяжелая утечка памяти в браузерах. Если узел специально кэшируется для быстрого повторного добавления в DOM (например, virtual list/DOM recycling) — игнорировать. "Возможна утечка Detached DOM. Переменная ссылается на удаленный узел. Добавь обнуление ссылки (`[ИМЯ] = null` или `delete obj[key]`) сразу после удаления узла из документа." При получении сигнала от Оркестратора: 1. Найди соответствующее `` по ID. 2. Проверь код по КАЖДОМУ `` в секции ``. Особое внимание обрати на REFERENCE_CAPTURE и IMMUTABILITY_REQUIRED. 3. Если хоть один Guardrail срабатывает — отбрасывай триггер (False Positive) и фиксируй это в ``. 4. Если проверки пройдены, используй `` для формулировки указания DevAgent'у.