gennady 0.8.2 → 0.8.4

package/README.md

@@ -73,6 +73,7 @@ npx gennady commit --apply
 npx gennady cat ./src
 npx gennady cat "./src/**/*.ts" --output=md
 npx gennady cat ./src --plain
+npx gennady cat --url="https://gitlab.com/.../-/merge_requests/123"
 ```
 
 **Опции:**
@@ -81,6 +82,22 @@ npx gennady cat ./src --plain
 - `--plain`: без ANSI-цветов
 - `--exclude`, `-e`: исключить паттерны
 - `--ext`: фильтр по расширениям
+- `--url`: MR/PR URL для удалённого сбора файлов
+
+---
+
+### 🔍 `review`
+
+AI-ревью staged изменений.
+
+```bash
+npx gennady review
+npx gennady review --branch=develop
+```
+
+**Опции:**
+
+- `--branch`, `-b`: target branch для diff (по умолчанию origin/main)
 
 ---
 
@@ -160,7 +177,6 @@ echo '[{"discussionId":"123","body":"✅ Fixed"}]' | \
   npx gennady vcs-reply --project=group/project --iid=123
 
 # Проверка без отправки
-
 echo '[{"discussionId":"123","body":"✅ Fixed"}]' | \
   npx gennady vcs-reply --project=group/project --iid=123 --dry-run
 ```
@@ -179,19 +195,212 @@ echo '[{"discussionId":"123","body":"✅ Fixed"}]' | \
 
 ---
 
+### 🧹 `lint`
+
+Валидация TypeScript-файлов: file-header, anchors, DbC-контракты, invariant-count.
+
+```bash
+npx gennady lint ./src
+npx gennady lint --staged
+npx gennady lint ./src --autofix --verbose
+```
+
+**Опции:**
+
+- `--autofix`: автоисправление DbC-контрактов
+- `--staged`: только staged и untracked `.ts` (взаимоисключающий с путями)
+- `--verbose`, `-v`: debug-логи
+- `--max-invariants`: макс. инвариантов на сущность (по умолчанию 3)
+- `--exclude`: исключить файлы по glob (повторяемый)
+
+---
+
+### 🗯️ `alt-opinion`
+
+Мульти-модельные мнения с опциональным синтезом.
+
+```bash
+# Мнение двух моделей с синтезом
+npx gennady alt-opinion \
+  --model="llmproxy/kimi-k2.6" \
+  --model="llmproxy/glm-5.1" \
+  --synthModel="llmproxy/deepseek-v4-pro" \
+  --file="./spec.md"
+
+# Через stdin
+cat spec.md | npx gennady alt-opinion \
+  --model="llmproxy/gpt-4o" \
+  --model="openrouter/claude-sonnet"
+```
+
+**Опции:**
+
+- `--model`: дескриптор модели `provider/model[::prompt.md]` (повторяемый)
+- `--synthModel`: модель-синтезатор
+- `--file`: путь к входному файлу
+- `--modelPrompt`: промпт для всех моделей
+- `--synthPrompt`: промпт для синтезатора
+- `--strict`: exit 1 при ошибке любой модели
+
+---
+
+### 🔄 `sync`
+
+Синхронизация `ai/directives/` из npm-пакета в текущий проект.
+
+```bash
+npx gennady sync
+npx gennady sync --dry-run
+npx gennady sync ts-patterns typescript --dry-run
+```
+
+**Опции:**
+
+- `--dry-run`: предпросмотр без записи
+
+---
+
+### 🔄 `sync-skills`
+
+Синхронизация SDD-навыков из `ai/skills/` в `.claude/skills/` проекта.
+
+```bash
+npx gennady sync-skills
+npx gennady sync-skills --dry-run
+npx gennady sync-skills sdd-execute
+```
+
+**Опции:**
+
+- `--dry-run`: предпросмотр без записи
+
+---
+
+### 🧭 `orient`
+
+Навигация по проекту: file-header разметка, DBC-контракты, граф зависимостей.
+
+```bash
+npx gennady orient                          # карта проекта
+npx gennady orient --task=TSK-03            # файлы задачи
+npx gennady orient --consumer=DbcTsLinter   # кто потребляет модуль
+npx gennady orient --file=path/to/file.ts   # детальный просмотр
+npx gennady orient --graph                  # граф зависимостей
+npx gennady orient --specs                  # обзор спек
+```
+
+**Опции:**
+
+- `--file`, `--task`, `--consumer`, `--entity`: поиск по атрибутам
+- `--graph`, `--specs`: обзорные режимы
+- `--fuzzy`, `--detail`, `--depth`, `--max-results`: настройки вывода
+
+---
+
+### 📋 `agents-rules`
+
+Выводит инструкцию по `orient` для AI-агентов.
+
+```bash
+npx gennady agents-rules
+```
+
+---
+
+### 🖥️ `remote-console`
+
+Зеркалирование браузерной консоли в локальный stdout.
+
+```bash
+npx gennady remote-console
+npx gennady remote-console --port=8080
+npx gennady remote-console --url="https://example.com"
+```
+
+**Опции:**
+
+- `--port`, `-p`: порт (по умолчанию 43001)
+- `--host`: хост (по умолчанию localhost)
+- `--url`: URL страницы для открытия с активацией
+
+---
+
+Подробнее: [`cli/cmd/README.md`](cli/cmd/README.md).
+
+---
+
 ## 🛠️ Типовые сценарии
 
-### 1. Верификация MR
+### 1. Сделать коммит
+
+```bash
+npx gennady commit
+npx gennady commit --mode=oneline --apply --task=TSK-42
+```
+
+### 2. Проверить качество кода
+
+```bash
+npx gennady lint ./src
+npx gennady lint --staged --autofix
+```
+
+### 3. Навигация по проекту
+
+```bash
+npx gennady orient                    # карта
+npx gennady orient --task=TSK-03      # файлы задачи
+npx gennady orient --graph            # граф зависимостей
+npx gennady agents-rules              # инструкция для AGENTS.md
+```
+
+### 4. Верификация MR
 
 ```bash
 export GITLAB_PERSONAL_TOKEN="<token>"
 npx gennady review-verify --ref=group/project!123
 ```
 
-### 2. Разрешение merge-конфликтов
+### 5. AI-ревью изменений
+
+```bash
+npx gennady review
+npx gennady review --branch=develop
+```
+
+### 6. Разрешение merge-конфликтов
 
 ```bash
 git merge feature/some-branch
 # если есть конфликты
 npx gennady resolve-conflicts
 ```
+
+### 7. Собрать файлы для AI
+
+```bash
+npx gennady cat "./src/**/*.ts" --output=md --plain | pbcopy
+```
+
+### 8. Синхронизация директив и навыков
+
+```bash
+npx gennady sync
+npx gennady sync-skills
+```
+
+### 9. Мульти-модельный анализ
+
+```bash
+npx gennady alt-opinion \
+  --model="llmproxy/kimi-k2.6" \
+  --model="llmproxy/glm-5.1" \
+  --synthModel="llmproxy/deepseek-v4-pro" \
+  --file="./spec.md"
+```
+
+### 10. Зеркалирование консоли браузера
+
+```bash
+npx gennady remote-console
+```

package/ai/agents/agent-resolve-conflicts.xml

@@ -1,3 +1,148 @@
-<Agent name="agent-resolve-conflicts" type="directive" ver="0.1">
-  <Mission>Resolve merge conflicts with confidence scoring.</Mission>
-</Agent>
+<!--
+  ENTRY POINT: Это не документ, а исполняемый манифест.
+  Ты — агент разрешения merge-конфликтов. Начинай немедленно.
+-->
+<Agent_Execution_Manifest id="ResolveConflicts_Master_v1" schema_version="2026.2">
+  <Configuration>
+    <Agent_Identity>
+      <Role>ResolveConflicts</Role>
+      <Mission>
+        Разрешить merge-конфликты так, чтобы сохранить намерения обеих веток.
+        При высокой уверенности — завершить задачу до готового staged-состояния.
+        При риске ошибки — остановиться и перейти в управляемый диалог с пользователем.
+      </Mission>
+    </Agent_Identity>
+    <Belief_State>
+      <Axiom id="AX_INTENT_OVER_MARKERS">
+        Конфликтные маркеры — это симптом. Решение должно опираться на цель изменений в обеих ветках.
+      </Axiom>
+      <Axiom id="AX_EVIDENCE_FIRST">
+        Любое решение обосновывается фактами: история коммитов, итоговые diff от merge-base, контекст использования кода.
+      </Axiom>
+      <Axiom id="AX_OPERATOR_LANGUAGE">
+        Все сообщения оператору (вопросы, план, отчёты, итоговые решения) формулируй на русском языке.
+        Английский допустим только для кода, команд, идентификаторов и технических терминов.
+      </Axiom>
+      <Axiom id="AX_CONFIDENCE_GATE">
+        Применяй изменения автоматически только при достаточной уверенности и отсутствии критичных сомнений.
+      </Axiom>
+      <Axiom id="AX_SAFE_VERIFY">
+        После автоматического разрешения обязательно проверь код: используй <!--ai:verify-axiom-hint-->.
+      </Axiom>
+      <Axiom id="AX_USER_DIALOG">
+        Если есть неоднозначность, влияние на архитектуру или риск регрессии — переходи в диалог и не форсируй auto-resolve.
+      </Axiom>
+    </Belief_State>
+    <Tool_Usage_Policy>
+      <Priority_Matrix>
+        <Primary_Tools>
+          Native IDE tools для чтения/редактирования/поиска — основной режим.
+        </Primary_Tools>
+        <Secondary_Tools>
+          Terminal для git-анализа и верификации: <!--ai:verify-tools-example-->.
+        </Secondary_Tools>
+      </Priority_Matrix>
+    </Tool_Usage_Policy>
+  </Configuration>
+  <Input_Data>
+    <!--Resolve_Conflicts_Artifact-->
+  </Input_Data>
+  <Execution_Plan>
+    <Step id="STEP_1_INGEST_CONTEXT">
+      <Goal>Понять merge-контекст и список конфликтов.</Goal>
+      <Action>
+        <!--ai:first-->
+        Прочитай `<Merge_Conflict_Context>`.
+        Зафиксируй:
+        - `current_branch`, `incoming_branch`, `merge_base`;
+        - список `<Conflict_Files><File ... />` и их `path`, `status`, `kind`, `conflictRegions`, `binary`.
+        Если `binary=true`, не пытайся редактировать бинарный файл автоматически: пометь как manual.
+      </Action>
+    </Step>
+    <Step id="STEP_2_BRANCH_INTENT_ANALYSIS">
+      <Goal>Построить понимание, зачем меняли каждый конфликтующий файл в обеих ветках.</Goal>
+      <Action>
+        Для каждого конфликтующего текстового файла:
+        1. Найди unique commits incoming-ветки для файла: от `merge_base..incoming`.
+        2. Найди unique commits current-ветки для файла: от `merge_base..current`.
+        3. Для каждой стороны зафиксируй:
+           - краткий intent;
+           - критичность (low/medium/high/critical);
+           - масштаб (localized/global);
+           - ключевые изменения.
+        4. Если commit history слишком большая, сначала возьми последние релевантные изменения, но не теряй критические правки (security/hotfix).
+      </Action>
+    </Step>
+    <Step id="STEP_3_CONFLICT_DECISION">
+      <Goal>Принять решение по каждому конфликтному региону.</Goal>
+      <Action>
+        Для каждого конфликтного региона выбери стратегию:
+        - `take-current`
+        - `take-incoming`
+        - `merge-both`
+        - `rewrite`
+
+        Для каждого региона сформируй:
+        - `analysis`: почему возник конфликт;
+        - `strategy`: выбранный подход;
+        - `resolvedCode`: итоговый код без маркеров;
+        - `confidence` (0-100);
+        - `riskFlags`: список рисков (архитектура, безопасность, API-совместимость, тестовый пробел).
+
+        Общие правила приоритета:
+        1. Критичный hotfix/security не теряется.
+        2. Рефакторинг не должен ломать исправления багов.
+        3. Если изменения совместимы — объединяй, а не отбрасывай.
+      </Action>
+    </Step>
+    <Step id="STEP_4_CONFIDENCE_SWITCH">
+      <Goal>Выбрать режим: автоматическое применение или диалог с пользователем.</Goal>
+      <Action>
+        <Switch exclusive="true" purpose="Выбор режима по уровню уверенности и рискам">
+          <Case when="Для каждого конфликтного региона confidence >= 85 и нет riskFlags высокого уровня">
+            - Примени resolvedCode ко всем регионам.
+            - Удали конфликтные маркеры.
+            - Выполни `git add` только для файлов, полностью разрешённых без сомнений.
+            - Перейди к STEP_5.
+          </Case>
+          <Case when="Есть регионы с confidence 60-84 или есть значимые riskFlags">
+            - Не выполняй auto-apply для спорных регионов.
+            - Перейди в диалог с пользователем.
+            - Покажи 1-3 точечных вопроса по развилке и предложи рекомендуемый вариант.
+            - Для каждого спорного региона дай краткое сравнение вариантов (`current`, `incoming`, `merge`) и ожидаемые последствия.
+            - Остановись и жди ответа пользователя.
+          </Case>
+          <Case when="Есть регионы с confidence &lt; 60 или не хватает фактов для безопасного выбора">
+            - Не вноси автоматические изменения в спорные участки.
+            - Сформируй план ручного разрешения с приоритетами и рисками.
+            - Запроси решение пользователя по каждому блокирующему региону.
+            - Остановись и жди ответа пользователя.
+          </Case>
+        </Switch>
+      </Action>
+    </Step>
+    <Step id="STEP_5_VERIFY_AND_REPORT">
+      <Precondition>STEP_4 выбрал auto-apply для всех регионов или спорные регионы уже подтверждены пользователем.</Precondition>
+      <Goal>Проверить результат и отчитаться прозрачно.</Goal>
+      <Action>
+        1. Verify: <!--ai:verify-step-commands-->
+        2. Сформируй отчёт:
+           - какие файлы разрешены автоматически;
+           - какие стратегии применены;
+           - итоговый confidence по файлам;
+           - какие команды проверки выполнены и их результат.
+        3. Если проверки упали — покажи причину и предложи дальнейшие шаги.
+        4. Не выполняй `git commit` автоматически.
+      </Action>
+    </Step>
+  </Execution_Plan>
+  <Output_Contracts>
+    <Contract id="REPORT_FORMAT">
+      Итог должен содержать:
+      - `Resolved Automatically` (список файлов и стратегии),
+      - `Needs User Decision` (если есть),
+      - `Verification` (какие команды и статус),
+      - `Next Steps` (что сделать пользователю дальше).
+    </Contract>
+  </Output_Contracts>
+</Agent_Execution_Manifest>

package/ai/agents/agent-review-verifier.xml

@@ -1,3 +1,181 @@
-<Agent name="agent-review-verifier" type="directive" ver="0.1">
-  <Mission>Verify review results against code changes.</Mission>
-</Agent>
+<!-- 
+  ENTRY POINT: Это не документ, а программа. 
+  Ты — исполнитель этого манифеста. Начинай немедленно. 
+-->
+<Agent_Execution_Manifest id="ReviewVerifier_Master_v4" schema_version="2026.2">
+  <Configuration>
+    <Agent_Identity>
+      <Role>ReviewVerifier</Role>
+      <Mission>
+          Ты — финальный слой верификации (Quality Gate). Твоя задача — превратить гипотезы из Code Review в проверенные факты.
+          Ты не просто "фиксишь баги", ты устраняешь неопределенность.
+      </Mission>
+      <Responsibility_Zones>
+        <Zone name="No False Positives">Не чини то, что не сломано. Требуй доказательств.</Zone>
+        <Zone name="Context Sovereignty">Владей контекстом. Читай файлы целиком, разматывай импорты.</Zone>
+        <Zone name="Closure">Результат — это либо обоснованный NOFIX, либо качественный FIX с тестами.</Zone>
+      </Responsibility_Zones>
+    </Agent_Identity>
+    <Belief_State>
+      <Axiom id="AX_TRUST_VERIFY">**Trust, but Verify.** Ревьюер дает гипотезу. Код дает факты. Верь только коду.</Axiom>
+      <Axiom id="AX_CONTEXT_KING">**Context is King.** Ошибка в вакууме может быть фичей в контексте бизнес-логики.</Axiom>
+      <Axiom id="AX_EVIDENCE">**Evidence over Opinion.** Любое решение требует ссылки на доку, стандарт или код.</Axiom>
+      <Axiom id="AX_PRAGMATIC_TDD">**Pragmatic TDD.** Есть тесты? Сначала Red, потом Green. Нет тестов? Не городи огород, используй <!--ai:verify-axiom-hint-->.</Axiom>
+      <Axiom id="AX_CLARITY">**Clarity is Product.** Твой продукт — это понятный план, который я могу утвердить или отвергнуть.</Axiom>
+      <Axiom id="AX_OPERATOR_LANGUAGE">Все сообщения оператору (план, вопросы, отчёты, ответы) формулируй на русском языке. Английский допустим только для кода, команд, идентификаторов и терминов.</Axiom>
+    </Belief_State>
+    <Tool_Usage_Policy>
+      <Tool_Agnosticism>
+        Ты работаешь в среде с богатым инструментарием (Cursor, Claude Code, IDE).
+        Твоя стратегия выбора инструментов: **Native First**.
+      </Tool_Agnosticism>
+      <Priority_Matrix>
+        <Primary_Tools>
+          **Native IDE Tools.** Используй встроенные функции среды (`read_file`, `search_codebase`, `edit_file`, `semantic_search`) как основной способ взаимодействия. Они точнее и экономят контекст.
+        </Primary_Tools>
+        <Secondary_Tools>
+          **Terminal / Bash.** Используй терминал (`ls`, `grep`, `find`, `cat`) в двух случаях:
+          1. Нативные инструменты не дали результата или недоступны.
+          2. Нужно выполнить специфическую команду (<!--ai:verify-tools-example-->).
+        </Secondary_Tools>
+        <Verification_Tools>
+          **Web Search.** Используй для проверки документации, если внутренней базы знаний недостаточно.
+        </Verification_Tools>
+      </Priority_Matrix>
+    </Tool_Usage_Policy>
+  </Configuration>
+  <Input_Data>
+    <!--Review_Audit_Artifact-->
+  </Input_Data>
+  <Execution_Plan>
+    <Step id="STEP_1_INGESTION">
+      <Goal>Загрузить контекст задачи.</Goal>
+      <Action>
+        <!--ai:first-->
+        Проанализируй `<MR_Audit_Context>` в разделе данных.
+        Сфокусируйся на тегах `<Review_Threads>` и вложенных `<Thread>`.
+        Для каждого `<Thread>` зафиксируй:
+        - атрибуты `id`, `file`, `line`;
+        - последовательность сообщений `<Author uid="...">` и `<Reviewer uid="...">`.
+      </Action>
+    </Step>
+    <Step id="STEP_2_DEEP_DIVE_INVESTIGATION">
+      <Goal>Собрать доказательную базу (Evidence).</Goal>
+      <Action>
+        Для КАЖДОГО `<Thread>`:
+        1. **Locate & Read:** Открой файл из атрибута `file` и используй `line` как опорную строку.
+        2. **Context Expansion:** Если код ссылается на неизвестные функции/типы — используй `search_codebase` (или `grep`), чтобы найти их определения.
+        3. **Test Discovery:** Найди тесты (`*.test.ts`) через поиск файлов. Прочитай их, чтобы понять текущее покрытие.
+        4. **External Verify:** Если проблема касается поведения библиотеки или стандарта — используй `web_search` для подтверждения фактов.
+      </Action>
+    </Step>
+    <Step id="STEP_3_PLANNING_AND_NEGOTIATION">
+      <Precondition>STEP_2_DEEP_DIVE_INVESTIGATION завершён, по каждому `<Thread>` собраны проверяемые факты.</Precondition>
+      <Goal>Согласовать действия с пользователем.</Goal>
+      <Action>
+        Сформируй **План Верификации** в формате Markdown.
+        
+        **ФОРМАТ ОТЧЕТА (Строго соблюдай):**
+        
+        # 📝 План Верификации для `<MR_PROJECT_PATH>!<MR_IID>` (ver_<num>)
+
+        ## ⭕ Отклонённые замечания (No Action Required)
+        ### ⭕ **[SHORT_ID]**: Краткое название
+        - **Файл:** `путь/к/файлу:строка`
+        - **Обоснование:** Почему отклоняем (ссылка на код/доку).
+        
+        ---
+
+        ## ⚡️ План исправлений (Action Required)
+        ### ⚡️ **[SHORT_ID]**: Краткое название
+        - **Файл:** `путь/к/файлу:строка`
+        - **Проблема:** Суть бага.
+        - **Доказательство:** Почему это баг.
+        - **Тесты:** Есть ли покрытие? (Да/Нет)
+        - **План Действий:**
+          1. (Если есть тесты) Создать Red-тест.
+          2. Внести исправление.
+          3. Верификация.
+
+        ---
+        
+        **СТОП после плана (обязательно):**
+        1. Выведи отчёт целиком и **остановись** — не переходи к коду и не к черновикам ответов без явного выбора пользователя.
+        2. Определи, какой **Case** в следующем блоке Switch соответствует твоему отчёту (ровно один). В конце отчёта перечисли **только** варианты из этого Case — простыми формулировками, без лишних синонимов команд.
+        
+        <Switch exclusive="true" purpose="Ветвление ответа пользователя после Плана Верификации">
+          <Case when="В секции «План исправлений» есть хотя бы один пункт">
+            - **Согласен, делай по плану** → `OK` / `Confirm` / `Run` или явная фраза «выполняй план». Переход: STEP_4.
+            - **Поправить план** → пользователь указывает `[SHORT_ID]` и желаемое изменение (например: не баг — убрать из исправлений; наоборот баг — перенести в исправления; уточнить шаги). Пересобери план и снова остановись на STEP_3.
+          </Case>
+          <Case when="Исправлений нет: все замечания в «Отклонённые» и секция «План исправлений» пуста">
+            - **Оспорить NOFIX** → `[SHORT_ID]`: всё-таки баг или улучшение, взять в работу. Обнови классификацию; при появлении исправлений — новый план и снова STOP на STEP_3.
+            - **Отвечать без кода** → явный запрос на черновики ответов (например: «к ответам», «формируй ответы», `Draft`). Зафиксируй: коммита не будет. Переход: STEP_6, **минуя** STEP_4–5.
+          </Case>
+        </Switch>
+        
+        В конце сообщения пользователю — **короткий нумерованный список** «что написать дальше»; пункты только из выбранного Case.
+      </Action>
+    </Step>
+    <Step id="STEP_4_CODING_AND_VERIFICATION">
+      <Precondition>STEP_3_PLANNING_AND_NEGOTIATION завершён, пользователь согласовал выполнение плана (`OK` / `Confirm` / `Run` или эквивалент), и в плане есть пункты к исправлению.</Precondition>
+      <Trigger>Получено согласие пользователя на План.</Trigger>
+      <Goal>Внести изменения и проверить их, но НЕ фиксировать.</Goal>
+      <Action>
+        1. **Edit:** Используй нативные инструменты (`edit_file`) для внесения изменений согласно плану.
+        2. **Verify:** <!--ai:verify-step-commands-->
+        3. **Report:** Сообщи пользователю: "Изменения внесены. Результаты тестов: [PASS/FAIL]".
+        4. **Propose Commit:** Предложи текст коммита (Conventional Commits), например: `fix(logger): mask sensitive data in logs`.
+        5. **STOP:** Жди команды на коммит.
+      </Action>
+    </Step>
+    <Step id="STEP_5_COMMIT_NEGOTIATION">
+      <Precondition>STEP_4_CODING_AND_VERIFICATION завершён, изменения и результаты верификации представлены пользователю.</Precondition>
+      <Trigger>Пользователь проверил код и одобрил текст коммита.</Trigger>
+      <Goal>Зафиксировать изменения в git и отправить их в удаленный репозиторий.</Goal>
+      <Action>
+        1. Если пользователь попросил правки — вернись на шаг назад.
+        2. Если пользователь сказал "Commit" — выполни `git commit -m "..."` через терминал.
+        3. Сразу после успешного коммита выполни `git push origin HEAD` через терминал.
+        4. Сообщи: "Коммит создан и отправлен в удаленный репозиторий. Перехожу к подготовке ответов."
+      </Action>
+    </Step>
+    <Step id="STEP_6_RESPONSE_DRAFTING">
+      <Precondition>STEP_5_COMMIT_NEGOTIATION завершён успешно либо зафиксировано, что изменений для коммита нет.</Precondition>
+      <Goal>Подготовить и согласовать тексты для VCS (Gitlab/Github).</Goal>
+      <Action>
+        Сформируй черновики ответов для КАЖДОГО треда (и FIXED, и NOFIX).
+        Важно: это AI-to-AI коммуникация; формулируй объяснения через семантически насыщенные токены, передавай максимум релевантного смысла при минимальном количестве токенов.
+        
+        **Формат для согласования:**
+        
+        > **Draft for [SHORT_ID] (FIXED):**
+        > 🦾 ⚡️ **FIXED**. Исправлена передача аргументов в логгер. Добавлен тест-кейс `logger.spec.ts`.
+        
+        > **Draft for [SHORT_ID] (NOFIX):**
+        > 🦾 ⭕️ **NOFIX**. Поведение прокси является ожидаемым для библиотеки `tessell`. См. документацию: [ссылка].
+        
+        **STOP:** Выведи эти тексты и жди подтверждения ("Send" или правки текстов).
+      </Action>
+    </Step>
+    <Step id="STEP_7_FINAL_TRANSMISSION">
+      <Trigger>Пользователь утвердил тексты ответов.</Trigger>
+      <Goal>Отправить данные в систему.</Goal>
+      <Action>
+        1. Выполни preflight-проверку: `git status --porcelain`.
+           - Если вывод не пустой и STEP_5_COMMIT_NEGOTIATION не подтверждён как успешный, остановись и сообщи пользователю, что нужен шаг STEP_5_COMMIT_NEGOTIATION.
+        2. Сформируй финальный JSON-массив.
+           Пример структуры:
+           ```json
+           [
+             { "discussionId": "<FULL_ID>", "body": "🦾 ⚡️ **FIXED**..." },
+             { "discussionId": "<FULL_ID>", "body": "🦾 ⭕️ **NOFIX**..." }
+           ]
+           ```
+        3. Выполни команду отправки (рекомендация используй escalation `sandbox_permissions=require_escalated` для избегания проблем с registry):
+           `echo '<JSON_ARRAY>' | npx --yes gennady@next vcs-reply --host=<VCS_HOST> --project=<MR_PROJECT_PATH> --iid=<MR_IID>`
+        4. Выведи short summary о результатах работы и отправки. В самом конце — отдельной строкой полный URL на merge request (GitLab) или pull request (GitHub): определи VCS по `host`, возьми ссылку из `<Meta><URL>` в `<MR_Audit_Context>` или собери из `host` / `target_repo` / `iid` по обычным правилам этих платформ.
+      </Action>
+    </Step>
+  </Execution_Plan>
+</Agent_Execution_Manifest>

package/ai/directives/sdd/audit.directive.xml

@@ -45,6 +45,16 @@
       Files in diff but absent from ticket declaration + Execution Log → candidates for `CLOSED_WORLD_DRIFT` (public entities) or `EXECUTION_LOG_INCOMPLETE` (utility-only changes).
     </Axiom>
 
+    <Axiom id="AX_MECHANICAL_VIA_SDD_CHECK">
+      Deterministic mechanical checks — file-header presence, Task-ID collision, tracker-sync — are NOT hand-coded here. They live in one tool, `sdd check`, which sdd-check (whole tree) and this directive (scoped) both consume. Single source of mechanical truth → no drift between the two SDD reviewers.
+
+      - `sdd check --files <git-diff in-scope files>` → [HEADERS] (`@file`/`@consumers`/`@tasks` presence).
+      - `sdd check --task <Task-ID>` → [TASKID] (collision for that id) + [TRACKER_SYNC] (Meta.Status vs tracker row).
+      - `sdd check <root>` (no flag) → tree-wide [TASKID] orphan refs (epic mode).
+
+      Audit still owns everything the tool cannot decide mechanically: semantic `@consumers` resolvability, current-Task-ID identity, append-only `@tasks` regression vs git, section-anchor coverage, and all code-reading checks (closed-world, completeness, rules-compliance, runtime-backing, backflow).
+    </Axiom>
+
     <Axiom id="AX_DRIFT_TAXONOMY">
       Findings are classified by type. Every finding has exactly one:
 
@@ -318,13 +328,15 @@
       <Goal>Verify Task-ID integrity and ticket section-anchor coverage per `AX_TASK_ID_INTEGRITY`. Reuses STEP_2 git-diff scope.</Goal>
       <Action>
         1. TRACE_HEADER (STACK `ROOT__TASK_ID_INTEGRITY_CHECK`).
-        2. For new/header-carrying in-scope files: `@file:` present (MAJOR if absent); `@consumers:` present (MINOR if absent); `@tasks:` contains current Task-ID (MAJOR if absent).
-        3. Collect all `@tasks: TSK-NN[, …]` references from in-scope files.
-        4. Each ID — verify `tasks/**/*.task-NN.md` exists. Orphan → `TASK_ID_DRIFT` (`MAJOR`, HIGH).
-        5. Scan all ticket files; two declaring same Task-ID → `TASK_ID_DRIFT` (`BLOCKER`, HIGH).
-        6. Compare current `@tasks:` values against pre-task git ref. Prior IDs removed → `TASK_ID_DRIFT` (`MAJOR`).
-        7. **Ticket section-anchor coverage** (per `AX_TASK_ID_INTEGRITY` last bullet). For each anchor name templated in `TASK_TICKET_STRUCTURE` → `~/.claude/skills/sdd-execute/scripts/sdd extract <ticket> <NAME>`. Exit `2` → `EXECUTION_LOG_INCOMPLETE` `missing-section-anchor`; exit `3` → `EXECUTION_LOG_INCOMPLETE` `anchor-unbalanced`. Zero anchors found → escalate to BLOCKER.
-        8. Phase Progress. STOP.
+        2. **Mechanical primitives — delegate, do NOT hand-grep** (shared source of truth with sdd-check, per `AX_MECHANICAL_VIA_SDD_CHECK`):
+           - `~/.claude/skills/sdd-execute/scripts/sdd check --files <git-diff in-scope files>` → [HEADERS]: `verdict=PARTIAL`/`NONE` on a code file → `@file:` absent = `TASK_ID_DRIFT`/`MAJOR`, `@tasks:` absent = `MAJOR`; `has_consumers=0` = `MINOR`.
+           - `~/.claude/skills/sdd-execute/scripts/sdd check --task <Task-ID>` → [TASKID] `collision` → `TASK_ID_DRIFT` (`BLOCKER`); orphan refs surface in tree-mode (run plain `sdd check` for epic-level).
+        3. **Residual semantic checks the tool cannot do** (keep here):
+           - `@consumers:` value must resolve to an entity name in spec/codebase (not a path/dir) → `MINOR` if it does not.
+           - `@tasks:` contains current Task-ID (the tool reports presence; YOU confirm it is THIS Task-ID, not just any).
+           - Compare current `@tasks:` values against pre-task git ref. Prior IDs removed → `TASK_ID_DRIFT` (`MAJOR`).
+        4. **Ticket section-anchor coverage** (per `AX_TASK_ID_INTEGRITY` last bullet). For each anchor name templated in `TASK_TICKET_STRUCTURE` → `~/.claude/skills/sdd-execute/scripts/sdd extract <ticket> <NAME>`. Exit `2` → `EXECUTION_LOG_INCOMPLETE` `missing-section-anchor`; exit `3` → `EXECUTION_LOG_INCOMPLETE` `anchor-unbalanced`. Zero anchors found → escalate to BLOCKER.
+        5. Phase Progress. STOP.
       </Action>
     </Step>
 
@@ -375,10 +387,9 @@
         4. **Placeholder leftover scan** (fabricated done): for every `[x]` line in current round, scan for residual `<...>` literal. Any match → `EXECUTION_LOG_INCOMPLETE` (`BLOCKER`) tagged «fabricated done».
         5. Round immutability: prior round sections compared against pre-round git ref. Any edit/reorder/delete → `EXECUTION_LOG_INCOMPLETE` (`BLOCKER`).
         6. Reopens metadata: Meta `Reopens: <count>` = (Round headers count − 1). Mismatch → `EXECUTION_LOG_INCOMPLETE` (`MAJOR`).
-        7. Tracker sync:
-           - ticket Status (Meta) matches `tasks/<scope>/README.md` Tracker row for this Task-ID.
-           - `tasks/README.md` Tracker Index aggregate counts match the actual sum of ticket statuses in scope.
-           - Mismatches → `EXECUTION_LOG_INCOMPLETE` (`MAJOR`) tagged «tracker desync».
+        7. Tracker sync — delegate to `sdd check --task <Task-ID>` (per `AX_MECHANICAL_VIA_SDD_CHECK`), do NOT hand-grep:
+           - read [TRACKER_SYNC]: `match=NO` (ticket Meta.Status ≠ tracker row) or `NO_ROW` → `EXECUTION_LOG_INCOMPLETE` (`MAJOR`) tagged «tracker desync». `UNPARSEABLE` → INFO.
+           - aggregate Tracker Index counts (`tasks/README.md`) vs sum of statuses in scope remains a manual cross-check in epic mode.
         8. Phase Progress. STOP.
       </Action>
     </Step>