gennady 0.6.0 → 0.7.0

package/dist/ai/directives/perf-auditor/rules/data-structures.xml

@@ -0,0 +1,103 @@
+<Rulebook id="rulebook_data_structures" type="knowledge_base">
+  <Primary_Goal>
+    Предоставить Аудитору строгие критерии, механизмы (Big-O) и предохранители (Guardrails) для оценки эффективности структур данных (Array, Set, Map, Object, WeakMap, TypedArray) в JavaScript/TypeScript.
+  </Primary_Goal>
+  <Belief_State>
+    <Axiom id="AX_BIG_O_MATTERS">Неправильный выбор структуры данных ведет к O(n^2) сложности. На целевом железе (Mid-range CPU) вложенные сканирования массивов недопустимы.</Axiom>
+    <Axiom id="AX_ONE_TIME_COST">Конвертация Array в Set стоит O(n) времени и памяти. Это выгодно ТОЛЬКО если далее следуют множественные проверки (в цикле) или массив очень велик.</Axiom>
+    <Axiom id="AX_ENGINE_OPTIMIZATIONS">Массивы в JS оптимизированы для индексов. Объекты — для статических (известных заранее) ключей. Использование их не по назначению разрушает JIT-оптимизации (Hidden Classes / Elements Kinds).</Axiom>
+  </Belief_State>
+  <Rules_Registry>
+    <!-- ПРАВИЛО 1: O(n^2) Membership Lookup -->
+    <Rule id="DS_ARRAY_VS_SET_LOOKUP">
+      <Trigger_Signals>
+        - Использование `array.includes(val)`, `array.indexOf(val)` внутри циклов (`for`, `while`, `.filter`, `.map`).
+        - Ручная дедупликация: `if (!arr.includes(x)) arr.push(x)`.
+      </Trigger_Signals>
+      <Performance_Mechanism>
+        `.includes()` и `.indexOf()` работают за O(n). Вызов их внутри цикла (который тоже O(n)) дает квадратичную сложность O(n^2). `Set.has()` работает за O(1) (в среднем).
+      </Performance_Mechanism>
+      <Safety_Guardrails>
+        <Guardrail condition="TINY_ARRAY">Если искомый массив (needle) гарантированно мал (например, `['a', 'b', 'c'].includes(x)`), оставь Array. Накладные расходы на создание Set не окупятся.</Guardrail>
+        <Guardrail condition="MUTATION_IN_LOOP">Если искомый массив изменяется ВНУТРИ самого цикла, вынос `new Set()` перед циклом сломает логику (Set устареет). Отклонить оптимизацию.</Guardrail>
+        <Guardrail condition="ORDER_MATTERS">Если важен порядок элементов при возврате или нужны дубликаты (при дедупликации), убедись, что замена на Set не сломает бизнес-логику.</Guardrail>
+      </Safety_Guardrails>
+      <Directive_Template>
+        "Извлеки массив [ИМЯ] в `new Set([ИМЯ])` до начала цикла. Внутри цикла замени `[ИМЯ].includes(...)` на `[ИМЯ_SET].has(...)`."
+      </Directive_Template>
+    </Rule>
+    <!-- ПРАВИЛО 2: Объекты как Словари (Dynamic Maps) -->
+    <Rule id="DS_OBJECT_VS_MAP">
+      <Trigger_Signals>
+        - Использование `{}` для хранения данных с динамическими ключами (например, ID пользователей).
+        - Частые операции `delete obj[key]`.
+        - Итерация по ключам через `Object.keys()` в высоконагруженных местах.
+      </Trigger_Signals>
+      <Performance_Mechanism>
+        Добавление/удаление случайных ключей переводит объект V8 в медленный "dictionary mode", ломая Hidden Classes. Оператор `delete` на объектах деоптимизирует доступ. `Map` изначально спроектирован как хеш-таблица для динамических ключей, `Map.delete()` оптимизирован.
+      </Performance_Mechanism>
+      <Safety_Guardrails>
+        <Guardrail condition="STATIC_RECORD">Если объект используется как DTO/Record с известным набором полей (даже если некоторые `undefined`), оставь Object.</Guardrail>
+        <Guardrail condition="JSON_SERIALIZATION">Если объект сразу передается в `JSON.stringify()`, замена на `Map` сломает сериализацию (Map сериализуется в `{}`). Отклонить, если нет явного маппинга.</Guardrail>
+      </Safety_Guardrails>
+      <Directive_Template>
+        "Замени инициализацию `{}` на `new Map()`. Замени присвоения `obj[k] = v` на `.set(k, v)`, чтение на `.get(k)`, а удаление на `.delete(k)`."
+      </Directive_Template>
+    </Rule>
+    <!-- ПРАВИЛО 3: Очереди и сдвиги массивов -->
+    <Rule id="DS_QUEUE_SHIFT">
+      <Trigger_Signals>
+        - Использование `array.shift()` или `array.unshift()` внутри циклов (например, при обработке очереди задач или стримов).
+      </Trigger_Signals>
+      <Performance_Mechanism>
+        Удаление первого элемента (`shift`) заставляет движок переиндексировать ВЕСЬ массив. Это операция O(n). В цикле это дает O(n^2) и вызывает скачки Garbage Collector'а при росте очереди.
+      </Performance_Mechanism>
+      <Safety_Guardrails>
+        <Guardrail condition="RARE_CALLS">Если `shift()` вызывается редко или массив мал (менее 100 элементов), игнорировать.</Guardrail>
+      </Safety_Guardrails>
+      <Directive_Template>
+        "Обнаружено использование `shift()` в цикле (O(n^2)). Замени массив на структуру Ring Buffer (циклический буфер) или используй два массива с `push/pop` для эмуляции очереди."
+      </Directive_Template>
+    </Rule>
+    <!-- ПРАВИЛО 4: Утечки памяти в кэшах -->
+    <Rule id="DS_WEAKMAP_CACHE">
+      <Trigger_Signals>
+        - Кэширование данных, где ключом выступает объект (например, DOM-узел, инстанс класса, req/res объекты). `cache.set(obj, data)`.
+      </Trigger_Signals>
+      <Performance_Mechanism>
+        Обычный `Map` или `Object` держит сильную ссылку на ключи. Если объект удален из приложения, кэш не даст Garbage Collector'у очистить память (Memory Leak). `WeakMap` позволяет GC удалять ключи.
+      </Performance_Mechanism>
+      <Safety_Guardrails>
+        <Guardrail condition="PRIMITIVE_KEYS">`WeakMap` поддерживает ТОЛЬКО объекты в качестве ключей. Если ключ — строка или число, замена вызовет TypeError.</Guardrail>
+        <Guardrail condition="ITERATION_REQUIRED">`WeakMap` неитерируем (`.keys()`, `.size` недоступны). Если логика требует обхода кэша, отклонить.</Guardrail>
+      </Safety_Guardrails>
+      <Directive_Template>
+        "Измени `new Map()` на `new WeakMap()`, так как ключами выступают объекты. Это предотвратит утечку памяти, позволив GC собирать удаленные объекты."
+      </Directive_Template>
+    </Rule>
+    <!-- ПРАВИЛО 5: Бинарные и числовые вычисления -->
+    <Rule id="DS_TYPED_ARRAYS">
+      <Trigger_Signals>
+        - Инициализация огромных массивов чисел `new Array(1000000)`.
+        - Обработка пикселей, аудио, WebGL, парсинг бинарных протоколов.
+      </Trigger_Signals>
+      <Performance_Mechanism>
+        Обычные массивы хранят числа как 64-bit float или Smi, но имеют оверхед на структуру. TypedArrays (`Uint8Array`, `Float32Array`) выделяют непрерывный блок памяти (как в C/C++), что радикально ускоряет доступ и снижает потребление RAM.
+      </Performance_Mechanism>
+      <Safety_Guardrails>
+        <Guardrail condition="MIXED_TYPES">Если массив может содержать `null`, `undefined`, строки или объекты — TypedArray вызовет ошибку. Массив должен быть строго гомогенным (только числа).</Guardrail>
+        <Guardrail condition="DYNAMIC_SIZE">TypedArray имеет фиксированную длину. Если код активно использует `.push()` или `.pop()`, замена потребует сложного ручного реаллоцирования памяти. Отклонить, если размер не известен заранее.</Guardrail>
+      </Safety_Guardrails>
+      <Directive_Template>
+        "Замени `new Array(size)` на `new [ТИП]Array(size)` (например, Float64Array). Это обеспечит непрерывное выделение памяти и ускорит математические операции."
+      </Directive_Template>
+    </Rule>
+  </Rules_Registry>
+  <Verification_Protocol>
+    При получении сигнала от Оркестратора:
+    1. Найди соответствующее `<Rule>` по ID или описанию.
+    2. Проверь код по КАЖДОМУ `<Guardrail>` в секции `<Safety_Guardrails>`.
+    3. Если хоть один Guardrail срабатывает (нарушается безопасность или профит сомнителен) — немедленно отбрасывай триггер (False Positive).
+    4. Если проверки пройдены, используй `<Directive_Template>` для формулировки указания DevAgent'у.
+  </Verification_Protocol>
+</Rulebook>

package/dist/ai/directives/perf-auditor/rules/iteration-fusion.xml

@@ -0,0 +1,96 @@
+<Rulebook id="rulebook_iteration_fusion" type="knowledge_base">
+  <Primary_Goal>
+    Предоставить Аудитору критерии для обнаружения избыточных итераций по коллекциям, пропущенных ранних выходов (Early Exit) и скрытых аллокаций промежуточных массивов.
+  </Primary_Goal>
+  <Belief_State>
+    <Axiom id="AX_ALLOCATION_IS_ENEMY">Каждый вызов `.map()`, `.filter()`, `.flat()` или `Array.from()` создает в памяти НОВЫЙ массив. На целевом железе (4-8 GB RAM) цепочка из 3 таких методов вызывает 3 аллокации и 3 прохода по данным, провоцируя микропаузы GC.</Axiom>
+    <Axiom id="AX_EARLY_EXIT">Сканирование 100% массива, когда для ответа достаточно найти один элемент — это растрата процессорного времени. Ранний выход всегда предпочтительнее полного прохода.</Axiom>
+    <Axiom id="AX_AI_READABILITY">Человеческая привычка писать "декларативные цепочки" (chaining) не имеет ценности для ИИ. Однопроходный императивный `for...of` с условиями работает быстрее и потребляет меньше памяти.</Axiom>
+  </Belief_State>
+  <Rules_Registry>
+    <!-- ПРАВИЛО 1: Упущенный ранний выход (Missed Early Exit) -->
+    <Rule id="ITER_EARLY_EXIT">
+      <Trigger_Signals>
+        - `.filter(predicate)[0]`, `.filter(predicate).at(0)`, `.filter(predicate).slice(0, 1)[0]`.
+        - `.filter(predicate).length > 0`, `.filter(predicate).length === 0`.
+        - Использование `forEach` с попыткой сделать `return` внутри (что не прерывает цикл).
+      </Trigger_Signals>
+      <Performance_Mechanism>
+        `.filter()` всегда проходит массив до конца и аллоцирует новый массив результатов. Если нужен только один элемент или проверка существования, это пустая трата CPU и RAM. Методы `.find()`, `.some()`, `.every()` останавливают итерацию (Short-circuit) при первом совпадении.
+      </Performance_Mechanism>
+      <Safety_Guardrails>
+        <Guardrail condition="RESULT_REUSED">Если результат `.filter()` сохраняется в переменную и затем используется ПОЛНОСТЬЮ где-то еще, а не только для получения первого элемента/длины — отклонить.</Guardrail>
+      </Safety_Guardrails>
+      <Directive_Template>
+        "Упущенный ранний выход. Для поиска элемента замени `.filter(...)[0]` на `.find(...)`. Для проверки наличия замени `.filter(...).length > 0` на `.some(...)` (или `.every(...)`)."
+      </Directive_Template>
+    </Rule>
+    <!-- ПРАВИЛО 2: Мусорные возвраты (Unused Array Returns) -->
+    <Rule id="ITER_UNUSED_RETURN">
+      <Trigger_Signals>
+        - Вызов `.map()`, `.filter()`, `.flatMap()` как самостоятельного выражения (результат не присваивается переменной и не возвращается из функции).
+      </Trigger_Signals>
+      <Performance_Mechanism>
+        Эти методы специфицированы так, чтобы всегда создавать и возвращать новый массив. Если результат игнорируется, массив сразу помечается как мусор, перегружая GC.
+      </Performance_Mechanism>
+      <Safety_Guardrails>
+        <Guardrail condition="NONE">Это 100% антипаттерн. Исключений нет.</Guardrail>
+      </Safety_Guardrails>
+      <Directive_Template>
+        "Мусорная аллокация. Результат `.map()` / `.filter()` не используется. Замени на `.forEach()` или цикл `for...of` для выполнения побочных эффектов без создания промежуточного массива."
+      </Directive_Template>
+    </Rule>
+    <!-- ПРАВИЛО 3: Слияние циклов (Loop Fusion) -->
+    <Rule id="ITER_FUSION_CHAINING">
+      <Trigger_Signals>
+        - Цепочки вызовов: `.filter(a).map(b)`, `.map(a).filter(b)`, `.filter(a).filter(b)`.
+      </Trigger_Signals>
+      <Performance_Mechanism>
+        Каждый шаг цепочки требует прохода по массиву (O(N)) и создания нового массива в памяти. Слияние (Fusion) этих шагов в один проход снижает сложность с O(K*N) до O(N) и оставляет только 1 аллокацию финального массива.
+      </Performance_Mechanism>
+      <Safety_Guardrails>
+        <Guardrail condition="INDEX_DEPENDENCY">Если коллбэк во второй функции цепочки использует индекс элемента (например, `.filter(x => x > 0).map((x, i) => ...)`), слияние в один цикл изменит значение `i` (индекс отфильтрованного массива не совпадает с оригинальным). Отклонить или предупредить DevAgent о необходимости ручного инкремента индекса.</Guardrail>
+      </Safety_Guardrails>
+      <Directive_Template>
+        "Промежуточные аллокации в цепочке. Слей `.filter().map()` в один проход. Используй цикл `for...of` с `if` и `.push()`, либо `.reduce()`, чтобы избежать создания промежуточных массивов."
+      </Directive_Template>
+    </Rule>
+    <!-- ПРАВИЛО 4: Оптимизация .map().flat() -->
+    <Rule id="ITER_FLATMAP">
+      <Trigger_Signals>
+        - Цепочка `.map(fn).flat()` или `.map(fn).flat(1)`.
+      </Trigger_Signals>
+      <Performance_Mechanism>
+        Создает промежуточный массив после `map`, а затем еще один после `flat`. Метод `flatMap` выполняет обе операции за один проход с одной аллокацией.
+      </Performance_Mechanism>
+      <Safety_Guardrails>
+        <Guardrail condition="DEEP_FLATTEN">Метод `flatMap` сплющивает только на глубину 1. Если в коде используется `.flat(2)` или глубже, замена на `flatMap` сломает структуру. Отклонить.</Guardrail>
+      </Safety_Guardrails>
+      <Directive_Template>
+        "Избыточная аллокация массива. Замени цепочку `.map(...).flat()` на единый вызов `.flatMap(...)`."
+      </Directive_Template>
+    </Rule>
+    <!-- ПРАВИЛО 5: Оптимизация Array.from -->
+    <Rule id="ITER_ARRAY_FROM_MAP">
+      <Trigger_Signals>
+        - Использование `Array.from(iterable).map(fn)`.
+      </Trigger_Signals>
+      <Performance_Mechanism>
+        Создает массив из итерируемого объекта (например, Set, NodeList), а затем создает ЕЩЕ ОДИН массив через `.map()`. Встроенный маппер `Array.from(iterable, fn)` избегает первой аллокации.
+      </Performance_Mechanism>
+      <Safety_Guardrails>
+        <Guardrail condition="THIRD_ARGUMENT_USAGE">Функция маппинга в `Array.from` не получает сам массив в качестве третьего аргумента (в отличие от `.map()`). Если `fn` использует 3-й аргумент, замена сломает код. Отклонить.</Guardrail>
+      </Safety_Guardrails>
+      <Directive_Template>
+        "Двойная аллокация массива. Объедини вызовы: передай функцию маппинга вторым аргументом в `Array.from` (т.е. `Array.from(iterable, fn)`)."
+      </Directive_Template>
+    </Rule>
+  </Rules_Registry>
+  <Verification_Protocol>
+    При получении сигнала от Оркестратора:
+    1. Идентифицируй целевое `<Rule>`.
+    2. Обязательно проверь `INDEX_DEPENDENCY` при слиянии циклов и `THIRD_ARGUMENT_USAGE` при `Array.from`. Это самые частые причины поломки логики при автоматическом рефакторинге.
+    3. Задокументируй верификацию в `<Verification_Log>`.
+    4. Сформируй приказ для DevAgent через `<Directive_Template>`, указав семантический якорь (например, "Внутри функции calculateMetrics, при обработке массива data").
+  </Verification_Protocol>
+</Rulebook>

package/dist/ai/directives/perf-auditor/rules/memory-gc.xml

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

package/dist/ai/directives/sdd/README.md

@@ -0,0 +1,49 @@
+# SDD — Spec-Driven Development
+
+Фреймворк для разработки через спецификации. Каждая директива запускается в **изолированной сессии** и производит самостоятельный артефакт.
+
+## Поток
+
+```
+setup ──► discovery ──► module-decomposition? ──► task-scaffolding ──► sdd-execute (orchestrator) ──► audit
+           (per scope)    (library/product only)    (convergence)        │
+                                                                         ├─► phase-subagent (P1, P2, ...)
+                                                                         │   under phase-execution-protocol
+                                                                         │
+                                                                         └─► audit-subagent
+                                                                             (auto-dispatched after Round close)
+```
+
+## Директивы
+
+| Директива                            | Что делает                                                                  | Входные данные              | Выходные данные                           |
+| ------------------------------------ | --------------------------------------------------------------------------- | --------------------------- | ----------------------------------------- |
+| `setup.directive.xml`                | Создаёт/обновляет портал проекта — Vision и Scope Graph                     | Намерение оператора         | `specs/README.md`                         |
+| `discovery.directive.xml`            | Проектирует scope: vision, архитектура, инструменты, Bootstrap Requirements | Название scope + scope-type | `specs/<scope>/<scope>.spec.md`           |
+| `module-decomposition.directive.xml` | Декомпозирует scope на модули (только library/product)                      | scope-spec                  | `specs/<scope>/<module>/<module>.spec.md` |
+| `task-scaffolding.directive.xml`     | Строит DAG task-тикетов с Phases Overview, BDD, правилами per phase         | Все scope-specs             | `tasks/<scope>/*.task-NN.md`              |
+| `phase-execution-protocol.xml`       | Выполняет ОДНУ фазу одного тикета (диспетчится `sdd-execute` оркестратором) | Phase ID + ticket + Handoff | Изменения в Target Files фазы + лог-блок  |
+| `audit.directive.xml`                | Проверяет выравнивание: spec ↔ тикет ↔ код; маппит finding-ы на фазы        | Закрытый Round + код        | Эфемерный отчёт + `phases_to_fix`         |
+
+Оркестрация — через SKILL-ы (`sdd-execute`, `sdd-execute-batch`). Они читают только заголовок тикета + Phases Overview и диспетчат phase-subagent-ов; никогда не выполняют сами.
+
+## Scope Model
+
+**Scope** — архитектурно когерентная единица со своим runtime / deployment / стеком / UX-surface.
+
+| scope-type       | Пример scopes                | Ключевые секции спека                               |
+| ---------------- | ---------------------------- | --------------------------------------------------- |
+| `infrastructure` | `infra-base`, `infra-golang` | Tool Stack, Dev Workflow, Verification Commands     |
+| `contracts`      | `api-contracts`              | Interfaces, Versioning Policy, Compatibility Matrix |
+| `library`        | `design-system-core`         | Golden DX, Public API, DbC                          |
+| `product`        | `backend`, `web`, `mobile`   | Vision, Requirements Gate, Architecture, Modules    |
+
+## Правила
+
+Правила организованы в три категории. Каждый тикет декларирует фазы (`## 2. Phases Overview`), а каждая фаза содержит свой `Rules:` bullet-список — отфильтрованный subset, релевантный именно этой фазе.
+
+| Категория | Директория               | Назначение                       |
+| --------- | ------------------------ | -------------------------------- |
+| Coding    | `ai/directives/coding/`  | Как писать код (язык + паттерны) |
+| Testing   | `ai/directives/testing/` | Как писать тесты (фреймворк)     |
+| Infra     | `ai/directives/infra/`   | Как конфигурировать инструменты  |