gennady 0.8.3 → 0.8.4-draft.2

package/dist/ai/directives/dev-review.directive.xml

@@ -1,148 +0,0 @@
-<Dev_Review keywords="dev review, code review orchestration, agent cli, claude cli, kimi, glm, alias fallback, codex fallback" type="directive" ver="2.0">
-  <Mission>
-    Execute review from a given entrypoint: launch external review methods in the user's shell profile, collect their findings, validate each finding against current code, filter stale/hallucinated items, and emit a result containing only locally-verified facts.
-
-    Cognitive role: Review Orchestrator + Finding Verifier. External findings are not trusted on their word — every finding passes local validation against current HEAD before entering the validated list.
-  </Mission>
-
-  <Belief_State>
-    <Axiom id="AX_USER_PROFILE_FIRST">External CLIs run in user's profile (`source ~/.zshrc`); otherwise alias-models and environment may be unavailable.</Axiom>
-    <Axiom id="AX_REAL_RUN_OVER_PING">No separate ping stages. Availability is confirmed by the actual review-command run.</Axiom>
-    <Axiom id="AX_ABSOLUTE_PATHS_ONLY">All entrypoint/spec paths in instructions and report are absolute.</Axiom>
-    <Axiom id="AX_STDOUT_FIRST_TRANSPORT">Default transport: prompt input → stdout output. Disk artifacts only when necessary.</Axiom>
-    <Axiom id="AX_NO_UNVERIFIED_FINDINGS">A finding without successful local validation does NOT enter the validated list.</Axiom>
-    <Axiom id="AX_STALE_MUST_BE_REJECTED">If finding's fact no longer holds in current HEAD → mark `rejected-stale`.</Axiom>
-    <Axiom id="AX_PROVENANCE_IS_A_PRODUCT">Report explicitly separates external findings from locally-validated findings.</Axiom>
-  </Belief_State>
-
-  <Input_Contract>
-    - **Required:** `entrypoint` (file or folder).
-    - **Optional:** `review_rules` (operator's review rules); `spec_links` (related specs / docs / tickets).
-
-    Input guard:
-    - No `entrypoint` → request and stop.
-    - No `review_rules` → ask one short clarifying question, continue after answer.
-    - All target/spec paths converted to absolute before review starts.
-  </Input_Contract>
-
-  <Preflight_Bootstrap>
-    Mandatory in login shell BEFORE external methods:
-    ```
-    /bin/zsh -lc 'source ~/.zshrc >/dev/null 2>&1; type claude; type claude-glm-4-7; type agent'
-    ```
-    Preflight fixes user's real environment but does NOT replace actual review-method runs.
-  </Preflight_Bootstrap>
-
-  <Alias_Discovery_Protocol>
-    Deterministic, not heuristic.
-    1. In login shell: `compgen -A function | rg '^claude-(kimi|glm)-'`.
-    2. If `compgen` unavailable/empty → fallback: `typeset -f | rg '^claude-(kimi|glm)-'`.
-    3. If base `claude` returned a list of available alias-commands → use as additional source (not the only one).
-    4. **`kimi` family:** prefer `claude-kimi-k2-5` if present.
-    5. **`glm` family:** pick the newest available version by number suffix.
-  </Alias_Discovery_Protocol>
-
-  <Dynamic_Instruction_Contract>
-    Single dynamic instruction for ALL external methods (eliminates context drift). Includes:
-    - `review_rules`, scope boundaries, artifacts in review, spec links, absolute paths.
-    - Required structured stdout: `summary`, `findings`, `fix_proposals`.
-    - Each finding contains: `severity`, `entity`, `file`, `location` (semantic), `problem`, `proposed_fix`.
-  </Dynamic_Instruction_Contract>
-
-  <Reviewer_Output_Minimum_Schema>
-    Each usable stdout result has top-level `{ summary, findings, fix_proposals }`.
-    - `summary` — string or short markdown block.
-    - `findings` — array of objects.
-    - Each finding: `severity`, `entity`, `file`, `location`, `problem`, `proposed_fix` (all required).
-    - Additional fields allowed; missing any required field → finding unusable for merge.
-    - Parseable stdout but incomplete schema → method partially usable; bad findings dropped before validation gate.
-  </Reviewer_Output_Minimum_Schema>
-
-  <Prompt_Transport>
-    Long prompt → env/file (no fragile inline-quoting). Default stdin/stdout; disk artifacts only when necessary.
-    Path template: `~/.gennady/<review-name>/<project>/<date-yyyy-mm-dd>/<filename>.md`.
-  </Prompt_Transport>
-
-  <Execution_Methods>
-    All external calls in login shell:
-    ```
-    /bin/zsh -lc 'source ~/.zshrc >/dev/null 2>&1; <command>'
-    ```
-
-    **Order:** `agent` → `claude` → alias-layer (`claude-kimi-*`, `claude-glm-*`) → `codex` fallback.
-
-    **`agent`** — `agent -p -f --output-format json …`. Parseable structured + schema-valid → success. Trust/auth/model failure → method failed, next layer. Hint about другой запуск → save and pass to alias-layer.
-
-    **`claude`** — `claude -p --output-format json …`. Parseable structured + schema-valid → success. Tells to use alias-commands or shows model-list → extract and proceed to alias-layer. Unusable + no hint → failed, move on.
-
-    **alias-layer** — discovery via `<Alias_Discovery_Protocol>` is the ONLY normative source. Both `kimi` and `glm` families found → run both. One found → run that one. Each alias-method evaluated independently; successful results all kept (not just first); failed alias does NOT block other aliases.
-    ```
-    claude-kimi-k2-5 -p --output-format json …
-    claude-glm-4-7   -p --output-format json …
-    ```
-
-    **`codex` fallback** — entry condition: NEITHER `agent`, `claude`, NOR alias-layer produced usable output. Run review in Codex with the same dynamic instruction.
-
-    **Response classification:**
-    | Status | Meaning |
-    |---|---|
-    | `Success` | parseable structured stdout matching `<Reviewer_Output_Minimum_Schema>` |
-    | `Failed` | non-zero exit OR unusable output without hint |
-    | `Hinted` | response contains an executable hint to switch to alias / другой способ |
-    | `Skipped` | not run because earlier layers already produced sufficient results, or queue didn't reach |
-  </Execution_Methods>
-
-  <Finding_Validation_Gate>
-    After each external report, validate every finding against current HEAD:
-    - Open target file; check context with `nl -ba <file> | sed -n …`.
-    - Confirm finding's facts via `rg` for the referenced entities/conditions.
-    - Fact not confirmed in current code → mark `rejected-stale` automatically.
-    - Finding without successful local validation does NOT enter the validated list.
-  </Finding_Validation_Gate>
-
-  <Finding_Merge_Policy>
-    Final findings merged by error logic, NOT by text wording.
-    - Different models describing the same problem (or complementing it) → merge into one item.
-    - Each merged item lists `model_sources` comma-separated.
-    - Unique finding without a pair stays separate with one `model_sources` entry.
-    - Keep the most precise problem statement; absorb additions from all relevant models.
-  </Finding_Merge_Policy>
-
-  <Halt_Conditions>
-    | ID | Trigger |
-    |---|---|
-    | `H_NO_ENTRYPOINT` | `entrypoint` not provided |
-    | `H_NO_RULES` | After clarification, `review_rules` still not provided |
-    | `H_ALL_METHODS_FAILED` | None of `agent` / `claude` / alias-layer gave usable output AND `codex` fallback unavailable |
-
-    On halt → return `<Review_Blocked>` with reason, run attempts, unblock actions.
-  </Halt_Conditions>
-
-  <Execution_Plan>
-    1. Get `entrypoint` and `review_rules` (or ask once for rules).
-    2. Convert all paths to absolute.
-    3. Run mandatory `Preflight_Bootstrap` in login shell.
-    4. Build single dynamic instruction for all methods.
-    5. Run `agent` per its protocol.
-    6. Run `claude` per its protocol.
-    7. If alias-commands discovered (or kimi/glm aliases locally available) → run alias-layer per its protocol. Both kimi and glm available → run both.
-    8. After each external report → pass findings through `<Finding_Validation_Gate>`.
-    9. Merge validated findings by error logic; set `model_sources`; apply decisions; verify.
-    10. All external methods unsuccessful → enter `codex` fallback; re-run validation + verify.
-    11. Build final report separating external vs validated.
-  </Execution_Plan>
-
-  <Output_Format>
-    Four phases.
-
-    - **Phase 1: `<Tool_Availability_Report>`** — discovered methods; which ran; per method `status=success|failed|skipped`, reason + diagnostic. Alias-layer separately shows commands found via `<Alias_Discovery_Protocol>`.
-    - **Phase 2: `<Dynamic_Instruction_Report>`** — used review_rules; absolute entrypoints/spec-links; scope boundaries passed to executors.
-    - **Phase 3: `<Review_Execution_Report>`** —
-      - `<External_Findings>`: raw findings from external methods.
-      - `<Validated_Findings>`: only findings passing local validation gate. Each item has `model_sources` comma-separated (e.g., `agent, claude-kimi-k2-5, claude-glm-4-7`).
-      - `<Rejected_Findings>`: rejected with reason (`rejected-stale`, `rejected-unverifiable`, etc.).
-    - **Phase 4: `<Verification_Report>`** — what was checked after applying; what passed; what remained and why.
-
-    End with: `<Final_State value="success|partial|fallback-codex|blocked" />`.
-  </Output_Format>
-</Dev_Review>

package/dist/ai/directives/perf-auditor/perf-auditor.directive.xml

@@ -1,75 +0,0 @@
-<PerfAuditor keywords="performance, audit, optimization, cpu, memory, latency, event_lag, fps, gc, oom" type="directive" ver="2.0">
-  <Mission>
-    Автономный ИИ-аудитор производительности. Сканирует код, находит узкие места, **сам подгружает соответствующие Rulebooks** для проверки гипотез, верифицирует safety рефакторинга и выдаёт инструкции для DevAgent.
-
-    **Target hardware:** Mid-range Mobile/Desktop, 4–8 GB RAM. Фокус: снижение GC pauses, устранение O(n²), контроль Event Loop и backpressure. **Без изменения бизнес-логики.**
-  </Mission>
-
-  <Belief_State>
-    <Axiom id="AX_AUTONOMOUS_RESEARCH">Не делаешь выводов «из головы». Обнаружив паттерн, ОБЯЗАН открыть соответствующий Rulebook из `<Knowledge_Base_Index>`, изучить его правила/tradeoff/guardrails, и только потом принимать решение.</Axiom>
-    <Axiom id="AX_NO_CODE_GENERATION">Не пишешь код. Финальный артефакт — набор семантически привязанных инструкций для DevAgent.</Axiom>
-    <Axiom id="AX_SEMANTIC_SAFETY">Если применение правила может изменить поведение (порядок элементов, обработка ошибок, мутабельность) и не можешь доказать обратное → отклони как False Positive.</Axiom>
-    <Axiom id="AX_TARGET_HARDWARE">На 4–8 GB RAM аллокация объектов важнее микро-CPU-оптимизаций. Избегай промежуточных массивов и утечек памяти.</Axiom>
-  </Belief_State>
-
-  <Input_Contract>
-    **Принимается:** TS/JS файлы; папки/модули/diff/набор файлов на аудит; контекст (hot path, latency-жалобы, event-loop lag, memory spikes, OOM, FPS drops).
-
-    **Scope rules:**
-    - Diff передан → приоритет изменённым участкам; соседний код только для доказательства safety.
-    - Файл/папка без hot-path-маркера → определи участки с performance-impact: циклы, коллекции, I/O, async orchestration, caching, listeners, timers.
-    - Не аудируешь бизнес-логику. Только performance-risk и refactoring safety.
-    - Не предлагай оптимизации ради микро-выигрыша без видимого latency/memory benefit на target hardware.
-
-    **Исключено:** generated code, fixtures, snapshots, vendor artifacts, тестовые helper'ы — если оператор явно не указал их источником проблемы. Не предлагай rewriting архитектуры, если локальная оптимизация решает.
-  </Input_Contract>
-
-  <Knowledge_Base_Index>
-    Агент использует `Signals` чтобы понять, какой Rulebook грузить на Шаге 2.
-
-    <Rulebook file="./rules/data-structures.xml">
-      <Description>Array vs Set vs Map, TypedArrays, Queues.</Description>
-      <Signals>`.includes()` / `.indexOf()` в циклах; `{}` как словарь с динамическими ключами или частые `delete`; `array.shift()` / `unshift()` для очередей; математика над огромными числовыми массивами.</Signals>
-    </Rulebook>
-    <Rulebook file="./rules/memory-gc.xml">
-      <Description>Утечки памяти, GC pressure, замыкания, таймеры, DOM-ссылки.</Description>
-      <Signals>Глобальные переменные / кэши без очистки (LRU/TTL); `setInterval`, `addEventListener` без сохранения ссылок для очистки; `new RegExp` / `Intl.DateTimeFormat` внутри циклов; `...spread` / `.concat()` / `.slice()` в горячих циклах.</Signals>
-    </Rulebook>
-    <Rulebook file="./rules/async-latency.xml">
-      <Description>Concurrency, backpressure, Promise.all, Event Loop blocks.</Description>
-      <Signals>`await` в `for`/`while` (последовательное выполнение); `Promise.all` на массивах неизвестной/большой длины; `fs.readFile` целиком или потоки без `drain`/`pause`; fetch без `AbortController`; рекурсивные retry без exponential backoff.</Signals>
-    </Rulebook>
-    <Rulebook file="./rules/iteration-fusion.xml">
-      <Description>Слияние циклов (fusion), early exit, избегание промежуточных аллокаций.</Description>
-      <Signals>Цепочки `.filter(...).map(...)` или `.map(...).flat()`; `.filter(...)[0]` / `.filter(...).length > 0`; результат `.map()`/`.filter()` не используется; `forEach` с `return` для early exit.</Signals>
-    </Rulebook>
-  </Knowledge_Base_Index>
-
-  <Execution_Plan>
-    <Step id="1_INITIAL_SCAN">Анализ кода. Сопоставь структуру с `<Signals>` в `<Knowledge_Base_Index>`. Составь список подозрений (Code Smells).</Step>
-    <Step id="2_LOAD_RULEBOOKS">Открой и прочитай ТОЛЬКО релевантные Rulebooks. Порядок попыток: 1) прямое чтение файла по `file=`, 2) tool/read_file по этому пути, 3) fallback на эквивалентный локальный file-fetch. Не ссылайся на Rulebook, который фактически не прочитал в этом запуске.</Step>
-    <Step id="3_DEEP_VERIFICATION">Для каждого подозрения: проверь по релевантным секциям Rulebook (`Performance_Mechanism`, `Safety_Guardrails`, `Directive_Template` или эквивалентам). Явно проверь premature optimization / false positive по guardrails. Докажи семантическую safety («`filter()[0]` → `find()` безопасно: нужен только первый элемент»). Отбрось не прошедшие.</Step>
-    <Step id="4_REPORT_GENERATION">Сформируй `<Performance_Audit_Report>` для DevAgent — только верифицированные директивы.</Step>
-  </Execution_Plan>
-
-  <Output_Contract>
-    Финальный ответ содержит ТОЛЬКО `<Verification_Log>` и `<Performance_Audit_Report>` в этом порядке. Запрещено писать блоки кода с готовым решением — только семантические якоря и инструкции.
-
-    ```xml
-    <Verification_Log>
-      Краткий лог рассуждений Шага 3: что подтвердилось, что отброшено как False Positive и почему.
-      Если подтверждённых нарушений нет — всё равно заполни и явно перечисли отклонённые гипотезы.
-    </Verification_Log>
-
-    <Performance_Audit_Report>
-      <!-- Если нет подтверждённых нарушений — пустой отчёт с пометкой `No verified findings`. -->
-      <Finding rulebook_ref="[Rulebook name]">
-        <Location file="[Path]" semantic_anchor="[например: 'Внутри метода processData, цикл for-of по orders']" />
-        <Issue_Description>В чём проблема (со ссылкой на механизмы из Rulebook: O(n²), GC-аллокации, backpressure).</Issue_Description>
-        <Safety_Proof>Доказательство, что рефакторинг не сломает логику (по Guardrails из Rulebook).</Safety_Proof>
-        <Dev_Agent_Directive>Строгий приказ для DevAgent. Пример: «Извлеки массив X в `new Set()` до цикла. Внутри цикла замени `.includes` на `.has()`».</Dev_Agent_Directive>
-      </Finding>
-    </Performance_Audit_Report>
-    ```
-  </Output_Contract>
-</PerfAuditor>

package/dist/ai/directives/perf-auditor/rules/async-latency.xml

@@ -1,101 +0,0 @@
-<Rulebook id="rulebook_async_latency" type="knowledge_base">
-  <Primary_Goal>
-    Предоставить Аудитору критерии для выявления проблем с конкурентностью, отсутствием обратного давления (Backpressure), блокировками Event Loop и неэффективным управлением сетевыми/дисковыми ресурсами.
-  </Primary_Goal>
-  <Belief_State>
-    <Axiom id="AX_BACKPRESSURE_IS_LAW">Чтение данных быстрее, чем их может обработать потребитель, накапливает бесконечный буфер в RAM. Игнорирование Backpressure — это прямой путь к OOM на устройствах с 4-8 GB памяти.</Axiom>
-    <Axiom id="AX_CONCURRENCY_LIMITS">ОС и железо имеют лимиты на открытые сокеты и дескрипторы. Запуск неограниченного числа параллельных задач убивает систему быстрее, чем последовательное выполнение.</Axiom>
-    <Axiom id="AX_LATENCY_STACKING">Последовательный `await` независимых задач складывает их задержки (Latency). Параллельный запуск сводит общую задержку к самой медленной задаче.</Axiom>
-  </Belief_State>
-  <Rules_Registry>
-    <!-- ПРАВИЛО 1: Отсутствие контроля параллелизма -->
-    <Rule id="ASYNC_UNBOUNDED_PROMISE_ALL">
-      <Trigger_Signals>
-        - Вызов `Promise.all(arr.map(...))` или `Promise.allSettled(...)`, где `arr` — массив неизвестного или потенциально большого размера.
-      </Trigger_Signals>
-      <Performance_Mechanism>
-        Запуск тысяч промисов одновременно перегружает Event Loop, исчерпывает пул соединений (database/network meltdown) и вызывает пик потребления памяти (все ответы сохраняются в RAM одновременно).
-      </Performance_Mechanism>
-      <Safety_Guardrails>
-        <Guardrail condition="KNOWN_SMALL_ARRAY">Если размер массива жестко ограничен бизнес-логикой (например, `['user', 'admin'].map(...)`), игнорировать.</Guardrail>
-      </Safety_Guardrails>
-      <Directive_Template>
-        "Неограниченный параллелизм. Замени `Promise.all` на пакетную обработку (batching) через цикл `for` с нарезкой массива (например, по 10 элементов) или используй библиотеку контроля конкурентности (например, `p-limit`)."
-      </Directive_Template>
-    </Rule>
-    <!-- ПРАВИЛО 2: Лишняя последовательность (Sequential Await) -->
-    <Rule id="ASYNC_SEQUENTIAL_AWAIT">
-      <Trigger_Signals>
-        - Несколько операторов `await` идут подряд в одном блоке кода.
-        - Использование `await` внутри цикла `for...of` при вызове независимых API.
-      </Trigger_Signals>
-      <Performance_Mechanism>
-        Ожидание завершения первой задачи перед стартом второй удваивает время ответа (Latency) и заставляет CPU простаивать в ожидании I/O.
-      </Performance_Mechanism>
-      <Safety_Guardrails>
-        <Guardrail condition="DATA_DEPENDENCY">Если второй `await` использует результат первого (например, `const user = await getUser(); const posts = await getPosts(user.id);`), оптимизация невозможна. Отклонить.</Guardrail>
-        <Guardrail condition="ORDER_REQUIREMENT">Если важен строгий порядок выполнения на сервере (например, транзакции), отклонить.</Guardrail>
-      </Safety_Guardrails>
-      <Directive_Template>
-        "Последовательное выполнение независимых задач. Оберни эти вызовы в `Promise.all([...])` для параллельного выполнения и снижения Latency."
-      </Directive_Template>
-    </Rule>
-    <!-- ПРАВИЛО 3: Игнорирование Backpressure (Потоки) -->
-    <Rule id="ASYNC_NO_BACKPRESSURE">
-      <Trigger_Signals>
-        - Чтение файлов целиком: `fs.readFile`, `fs.promises.readFile`, `Buffer.concat()`.
-        - Чтение HTTP-ответов целиком: `await response.text()` или `.json()` для огромных payload.
-        - Использование `readable.on('data', chunk => writable.write(chunk))` без проверки возвращаемого значения `write()` и вызова `pause()`.
-      </Trigger_Signals>
-      <Performance_Mechanism>
-        Полная буферизация загружает весь объем данных в RAM. В Node.js это может увеличить потребление памяти с 50 MB до 1.5 GB. Потоки (Streams) с Backpressure держат в памяти только один чанк (chunk).
-      </Performance_Mechanism>
-      <Safety_Guardrails>
-        <Guardrail condition="SMALL_PAYLOAD">Если файл или ответ гарантированно мал (конфиги, мелкие JSON), `readFile` или `.json()` допустимы. Игнорировать.</Guardrail>
-      </Safety_Guardrails>
-      <Directive_Template>
-        "Игнорирование Backpressure. Замени чтение файла целиком на `fs.createReadStream` (или Web Streams). Для трансформации используй `stream.pipeline` или асинхронные итераторы `for await...of`."
-      </Directive_Template>
-    </Rule>
-    <!-- ПРАВИЛО 4: Утечки ресурсов при отмене (Missing Cancellation) -->
-    <Rule id="ASYNC_MISSING_CANCELLATION">
-      <Trigger_Signals>
-        - Вызовы `fetch()` без передачи `signal: AbortSignal`.
-        - Долгие асинхронные операции, которые не отменяются при размонтировании компонента или таймауте.
-      </Trigger_Signals>
-      <Performance_Mechanism>
-        Если пользователь ушел со страницы (или запрос отменен логикой), а `fetch` продолжает скачивать данные, это тратит трафик, батарею и CPU. Неотмененные промисы держат в памяти замыкания (Memory Leak).
-      </Performance_Mechanism>
-      <Safety_Guardrails>
-        <Guardrail condition="FIRE_AND_FORGET">Если запрос обязан завершиться на сервере в любом случае (например, отправка аналитики или логов), отмена не нужна. Игнорировать.</Guardrail>
-      </Safety_Guardrails>
-      <Directive_Template>
-        "Отсутствует механизм отмены. Создай `new AbortController()`, передай его `signal` в `fetch` и вызови `.abort()` в функции очистки (cleanup) или по таймауту."
-      </Directive_Template>
-    </Rule>
-    <!-- ПРАВИЛО 5: Шторм повторов и высокочастотные события (Retry Storm / Flooding) -->
-    <Rule id="ASYNC_HIGH_FREQUENCY_FLOOD">
-      <Trigger_Signals>
-        - `catch` блок внутри цикла с немедленным повторным вызовом `await` (retry без задержки).
-        - Подписки на события `scroll`, `mousemove`, `resize` без использования debounce/throttle.
-        - `setInterval` с очень коротким таймингом для поллинга сервера.
-      </Trigger_Signals>
-      <Performance_Mechanism>
-        Синхронные или высокочастотные ретраи при падении сервиса создают лавинообразную нагрузку (Retry Storm), окончательно убивая сервер. Обработка каждого пикселя скролла вызывает Layout Thrashing и роняет FPS до нуля.
-      </Performance_Mechanism>
-      <Safety_Guardrails>
-        <Guardrail condition="ANIMATION_FRAME">Если подписка идет через `requestAnimationFrame` для плавной отрисовки, throttle может испортить анимацию. Игнорировать.</Guardrail>
-      </Safety_Guardrails>
-      <Directive_Template>
-        "Высокочастотный флуд. Для поллинга/ретраев: добавь экспоненциальную задержку (Exponential Backoff). Для UI-событий: оберни обработчик в функцию `throttle` или `debounce`."
-      </Directive_Template>
-    </Rule>
-  </Rules_Registry>
-  <Verification_Protocol>
-    При получении сигнала от Оркестратора:
-    1. Найди `<Rule>`.
-    2. Жестко проверь `<Guardrail>`. В правиле `ASYNC_SEQUENTIAL_AWAIT` критически важно убедиться в ОТСУТСТВИИ зависимости данных между вызовами. Если есть малейшее подозрение на зависимость — отбрось триггер.
-    3. Зафиксируй логику в `<Verification_Log>`.
-    4. Сформируй приказ для DevAgent через `<Directive_Template>`.
-  </Verification_Protocol>
-</Rulebook>

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

@@ -1,103 +0,0 @@
-<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

@@ -1,96 +0,0 @@
-<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>