@jakerdy/agentica 0.0.2

package/prompts/reverse.prompt.md

@@ -0,0 +1,777 @@
+---
+name: agentica.reverse
+description: Реверс-инжиниринг существующего кода с созданием архитектурной спецификации
+---
+
+## Ввод пользователя
+
+```text
+$ARGUMENTS
+```
+
+Ты **ОБЯЗАН** учесть ввод пользователя (аргументы и контекст) перед тем как продолжить.
+
+## Цель и принципы работы
+
+Твоя задача — проанализировать существующую кодовую базу и создать архитектурную спецификацию "As-Is", описывающую **реальное** состояние системы.
+Работай строго линейно: **Валидация → Выбор режима → Сканирование → Анализ с накоплением → Формирование отчёта → Проверка → Отчёт**.
+
+Реверс-инжиниринг — это **документирование существующего для понимания**, а не проектирование или оценка качества. Твоя цель: восстановить карту того, что есть, объяснить **как работает** и **почему работает именно так**.
+
+**Ключевые принципы:**
+1. **Факты, не оценки:** Описывай структуру и поведение без суждений о качестве кода.
+2. **Память как основа:** Используй `memory` для накопления фактов во время анализа. Все найденные сущности, паттерны, механизмы сохраняй в memory.
+3. **Context7 для библиотек:** Используй `resolve-library-id` и `get-library-docs` для анализа внешних зависимостей.
+4. **Связность:** Показывай не только "что есть", но и "как связано" и "где используется".
+5. **Mermaid для диаграмм:** Все диаграммы процессов, потоков данных и зависимостей создавай в формате Mermaid (flowchart, sequenceDiagram, graph). Это удобнее визуально и проще для агентов.
+
+### Глобальные запреты (Safety Guards)
+
+Останови выполнение и не вноси изменения, если:
+1. Запрос требует **изменения кода** или рефакторинга (остановись и предложи пользователю воспользоваться агентами: `refactor` или `change`).
+2. Запрос описывает **новую систему**, которой ещё нет (остановись и предложи пользователю воспользоваться агентом: `architect`).
+3. Код отсутствует или директория пуста (нечего анализировать).
+4. Пользователь просит написать новую фичу на основе анализа (сперва завершить reverse, затем использовать `create`).
+5. Пользователь просит дать качественную оценку ("хорошо/плохо") — это не задача reverse.
+
+В случае остановки: объясни причину и предложи корректную команду.
+
+## Топология и размещение файлов
+
+Результат реверс-инжиниринга сохраняется как архитектурная спецификация в `.agentica/architecture/`:
+- **Single-project:** `./.agentica/architecture/`
+- **Monorepo (package):** `./packages/<name>/.agentica/architecture/`
+
+**Формат имени файла:** `AR-XXXX - <Название системы> (As-Is).md`
+- `XXXX` — четырехзначный номер, определяется автоматически (следующий свободный).
+- `<Название системы>` — краткое описание анализируемой области.
+- Суффикс `(As-Is)` — обязателен, подчеркивает, что это описание существующего состояния.
+
+Примеры:
+- `AR-0005 - Обзор проекта CLI Tool (As-Is).md`
+- `AR-0018 - Модуль обработки событий (As-Is).md`
+- `AR-0027 - Механизм кэширования (As-Is).md`
+
+## Фаза 1: Валидация контекста и определение скоупа
+
+### Шаг 1.1: Определение скоупа анализа
+1. Прочитай `structure.md` из корня проекта.
+2. Определи тип проекта: Single-project или Monorepo.
+3. Определи **область анализа**:
+   - Если пользователь указал путь/директорию → анализируй её.
+   - Если указал "весь проект" → анализируй всю кодовую базу.
+   - Если не указал, но контекст очевиден (открытая директория) → используй её.
+   - Если неоднозначно → задай вопрос через интсрумент `ask_questions`.
+
+### Шаг 1.2: Чтение контекста проекта
+Прочитай следующие файлы из целевого скоупа (если существуют):
+1. `product.md` — продуктовый контекст.
+2. `structure.md` — заявленная структура проекта.
+3. `tech.md` — технический стек и стандарты.
+4. Список существующих файлов в `architecture/` (для определения номера AR-XXXX и избежания дублирования).
+
+### Шаг 1.3: Определение режима работы
+
+**Три режима анализа:**
+
+#### Режим A: "Overview" (Обзорный отчёт)
+*Условие:* Пользователь просит проанализировать весь проект/пакет без указания конкретной области.
+*Скоуп:* Вся кодовая база целиком.
+*Цель:* Дать высокоуровневую карту проекта: модули, зависимости, архитектурный стиль.
+*Структура отчёта:* Общая, см. раздел 6.1.
+
+#### Режим B: "Deep-Dive" (Детальный анализ модуля)
+*Условие:* Пользователь указал конкретную директорию/модуль для анализа.
+*Скоуп:* Один модуль или группа связанных файлов.
+*Цель:* Разобрать структуру модуля, все сущности, интерфейсы, потоки данных.
+*Структура отчёта:* Модульная, см. раздел 6.2.
+
+#### Режим C: "Mechanism" (Анализ механизма/алгоритма)
+*Условие:* Пользователь просит разобрать конкретный механизм работы (например, "как работает кэширование", "механизм авторизации").
+*Скоуп:* Все файлы, связанные с механизмом (может быть размазано по нескольким модулям).
+*Цель:* Описать работу механизма пошагово, показать все точки использования, примеры.
+*Структура отчёта:* Алгоритмическая, см. раздел 6.3.
+
+**Выбор режима:**
+- Если пользователь явно указал режим → используй его.
+- Если указал путь к директории → режим B (Deep-Dive).
+- Если указал механизм/функцию ("как работает X") → режим C (Mechanism).
+- Если указал "весь проект" или не указал ничего → режим A (Overview).
+- Если неоднозначно → задай вопрос через интсрумент `ask_questions`.
+
+## Фаза 2: Сканирование кодовой базы
+
+### Общие правила сканирования
+1. Используй `semantic_search`, `grep_search`, `file_search` для поиска нужных элементов.
+2. **Все находки сохраняй в `memory`:** Сущности, интерфейсы, паттерны, зависимости.
+3. Читай код файлами, не пытайся держать всё в контексте.
+4. Для внешних библиотек используй `mcp_context7_resolve-library-id` → `mcp_context7_get-library-docs`.
+
+### Шаг 2.1: Сканирование по режимам
+
+**Важно:** Все примеры "Сохрани в memory" ниже показывают только содержимое поля `fact`. Полный формат memory (с правильным `subject` префиксом, `category`, `citations`, `reason`) описан в разделе 2.3. Всегда используй структурированный subject вида `@<scope>/AR-XXXX--<тема>` согласно правилам из 2.3.
+
+#### Режим A (Overview): Обзорное сканирование
+1. **Entry points:** Найди точки входа (main.ts, index.ts, app.py, __init__.py).
+   - Сохрани в `memory`: "Entry point: [путь] - [назначение]"
+2. **Модули:** Выяви основные директории и их назначение.
+   - Сохрани в `memory`: "Module: [путь] - [назначение]"
+3. **Зависимости:** Прочитай package.json / pyproject.toml / requirements.txt.
+   - Для ключевых библиотек используй Context7.
+   - Сохрани в `memory`: "Library: [имя] version [V] - [использование]"
+4. **Архитектурный стиль:** Определи общий паттерн (Layered, MVC, Event-Driven и т.д.).
+   - Сохрани в `memory`: "Architecture style: [стиль] - [признаки]"
+
+#### Режим B (Deep-Dive): Детальное сканирование модуля
+1. **Структура модуля:** Список всех файлов в целевой директории.
+2. **Сущности (Classes/Interfaces/Types):**
+   - Найди все классы, интерфейсы, типы.
+   - Сохрани в `memory`: "Entity: [имя] at [файл:строка] - [описание]"
+3. **Публичные интерфейсы (API):**
+   - Найди экспортируемые функции/классы.
+   - Сохрани в `memory`: "Public API: [имя] at [файл:строка] - [сигнатура]"
+4. **Внутренние зависимости:**
+   - Какие другие модули импортируются.
+   - Сохрани в `memory`: "Import: [модуль A] imports [модуль B] at [файл:строка]"
+5. **Потоки данных:**
+   - Проследи путь данных через модуль (откуда приходят, как трансформируются, куда уходят).
+   - Сохрани в `memory`: "Data flow: [источник] → [трансформация] → [назначение]"
+
+#### Режим C (Mechanism): Анализ механизма
+1. **Поиск точек реализации:**
+   - Найди все файлы, где упоминается механизм (по ключевым словам, именам функций/классов).
+   - Сохрани в `memory`: "Mechanism part: [компонент] at [файл:строка] - [роль]"
+2. **Разбор алгоритма:**
+   - Прочитай код и восстанови последовательность шагов.
+   - Сохрани в `memory`: "Step N: [действие] at [файл:строка]"
+3. **Точки использования:**
+   - Найди все места, где механизм вызывается (`list_code_usages`).
+   - Сохрани в `memory`: "Usage: [место вызова] at [файл:строка] - [контекст]"
+4. **Примеры:**
+   - Извлеки реальные примеры использования из кода.
+   - Сохрани в `memory`: "Example: [код] at [файл:строка]"
+
+### Шаг 2.2: Анализ внешних библиотек (Context7)
+
+Для всех **ключевых** внешних зависимостей:
+1. Используй `mcp_context7_resolve-library-id` для получения ID библиотеки.
+2. Используй `mcp_context7_get-library-docs` для получения документации.
+3. Сохрани в `memory`: "Library details: [имя] - [назначение по документации] - [как используется в проекте]"
+
+**Когда анализировать библиотеку:**
+- Она используется в > 3 местах кодовой базы.
+- Она является core-зависимостью (express, fastapi, react и т.д.).
+- Её поведение не очевидно из имени (нужно понять, зачем она нужна).
+
+### Шаг 2.3: Накопление контекста через Memory
+
+Memory — это **ключевой инструмент** для реверс-инжиниринга. Во время анализа ты будешь исследовать десятки файлов, но не можешь держать всё в контексте. Memory позволяет накапливать факты и затем собрать их при формировании отчёта.
+
+**Правила использования `memory`:**
+
+1. **Категория:** Используй `file_specific` для фактов о конкретных файлах, `general` для межмодульных связей и паттернов.
+
+2. **Subject (с префиксом для группировки):**
+   Используй структурированный префикс для удобства поиска:
+   - **Формат:** `@<scope>/AR-XXXX--<тема>`
+   - **`<scope>`:** Идентификатор пакета или "root" для single-project
+   - **`AR-XXXX`:** Номер создаваемого отчёта
+   - **`<тема>`:** Категория факта (entities, patterns, dependencies, data-flow, mechanisms, libraries)
+
+   **Примеры subject:**
+   - `@root/AR-0012--entities`
+   - `@api-gateway/AR-0045--patterns`
+   - `@auth-service/AR-0023--dependencies`
+   - `@root/AR-0012--mechanisms`
+
+3. **Fact:** Короткое утверждение (до 200 символов). Должно быть самодостаточным и понятным без дополнительного контекста.
+
+4. **Citations:** Всегда указывай файл:строка. Если факт о связи между файлами — перечисли все через запятую.
+
+5. **Reason:** Объясни, в какой раздел отчёта попадёт этот факт и почему он важен. Это поможет при формировании отчёта.
+
+**Примеры по режимам:**
+
+#### Режим A (Overview):
+```
+category: general
+subject: @root/AR-0012--patterns
+fact: Factory pattern used in src/factories/ for creating service instances
+citations: src/factories/service-factory.ts:12, src/factories/user-factory.ts:8
+reason: Will be included in section "Architectural patterns" to show design approach
+```
+
+```
+category: general
+subject: @root/AR-0012--dependencies
+fact: Core module depends on database, utils, and config modules
+citations: src/core/index.ts:1-5
+reason: Will be used in dependency graph section to show module relationships
+```
+
+#### Режим B (Deep-Dive):
+```
+category: file_specific
+subject: @auth-service/AR-0023--entities
+fact: Class TokenManager handles JWT generation, validation, and refresh logic
+citations: src/auth/token-manager.ts:15
+reason: Core entity for deep-dive report, will be detailed in entities section
+```
+
+```
+category: file_specific
+subject: @auth-service/AR-0023--data-flow
+fact: Auth flow: middleware extracts token → TokenManager validates → UserService fetches user
+citations: src/auth/middleware.ts:23, src/auth/token-manager.ts:45, src/services/user.ts:67
+reason: Will be used to construct data flow diagram in section 5
+```
+
+#### Режим C (Mechanism):
+```
+category: general
+subject: @root/AR-0027--mechanisms
+fact: Caching mechanism uses Redis adapter with TTL-based expiration
+citations: src/cache/redis-adapter.ts:34
+reason: Core component of caching mechanism, will be in "Components" section
+```
+
+```
+category: general
+subject: @root/AR-0027--mechanisms
+fact: Cache invalidation triggered by domain events from EventBus
+citations: src/cache/invalidator.ts:12, src/events/bus.ts:89
+reason: Shows mechanism workflow step, will be in "Algorithm" section
+```
+
+**Стратегия накопления:**
+
+1. **Начинай сохранять сразу:** Как только нашёл сущность/паттерн — сразу в memory, не откладывай.
+2. **Группируй по темам:** Используй одинаковый subject для связанных фактов (все entities, все patterns, и т.д.).
+3. **Не бойся дублей:** Лучше сохранить похожий факт дважды, чем потерять важную деталь.
+4. **Контекст в reason:** В reason объясняй не только "куда пойдёт", но и "почему важно" — это поможет при формировании отчёта расставить приоритеты.
+
+## Фаза 3: Анализ паттернов и механизмов
+
+**Важно:** Все facts сохраняй с правильным subject префиксом согласно разделу 2.3 (`@<scope>/AR-XXXX--patterns`, `@<scope>/AR-XXXX--mechanisms`, и т.д.).
+
+### Шаг 3.1: Выявление паттернов проектирования
+
+Анализируй код на предмет использования паттернов:
+1. **Creational:** Factory, Builder, Singleton.
+2. **Structural:** Adapter, Decorator, Facade.
+3. **Behavioral:** Observer, Strategy, Command.
+4. **Architectural:** MVC, Layered, Event-Driven, Repository Pattern.
+
+Для каждого найденного паттерна:
+- Сохрани в `memory`: "Pattern: [название] at [файл:строка] - [как реализован]"
+
+### Шаг 3.2: Выявление механизмов работы
+
+**Механизм** — это устойчивая последовательность действий для выполнения задачи.
+
+Ищи механизмы:
+- **Обработка ошибок:** Где и как ловятся ошибки, как обрабатываются.
+- **Валидация:** Где проверяются данные, какие правила.
+- **Аутентификация/Авторизация:** Как проверяются права.
+- **Кэширование:** Где сохраняются данные, когда инвалидируются.
+- **Ретраи:** Как обрабатываются повторные попытки при сбоях.
+
+Для каждого механизма:
+- Сохрани в `memory`: "Mechanism: [название] - [где используется] - [как работает]"
+
+### Шаг 3.3: Построение графа зависимостей
+
+Для всех ключевых модулей:
+1. Найди все `import` / `require` / `from X import`.
+2. Построй граф (A → B означает "A зависит от B").
+3. Выяви циклические зависимости (A → B → C → A).
+4. Сохрани в `memory`: "Dependency: [модуль A] → [модуль B] via [файл:строка]"
+5. Если есть цикл: "Circular dependency: [A] ↔ [B] ↔ [C]"
+
+## Фаза 4: Интервью с пользователем (опционально)
+
+### Когда запускать интервью
+
+Задавай вопросы через интсрумент `ask_questions`, если:
+1. Обнаружен неочевидный механизм, требующий подтверждения ("это фича или баг?").
+2. Найдены несколько возможных интерпретаций архитектурного решения.
+3. Требуется понимание **истории решений** ("почему сделано именно так?").
+4. Нужно уточнить **приоритеты** для детального анализа (если область большая).
+
+### Вопросы для уточнения
+
+Группируй вопросы по 2-3:
+1. **Контекст:** "Файл X содержит логику Y. Это основной механизм или legacy?"
+2. **Приоритеты:** "Какие модули важнее для детального анализа: A, B или C?"
+3. **История:** "Почему выбран подход Z вместо стандартного W?"
+
+Если пользователь не может ответить — продолжай анализ **только по коду**, без предположений.
+
+## Фаза 5: Формирование отчёта
+
+### Подготовка: Работа с накопленными memories
+
+Перед формированием отчёта собери все релевантные факты из memory:
+
+1. **Memory доступна автоматически:** Все сохранённые факты уже в твоём контексте, явный вызов инструмента не нужен.
+
+2. **Фильтрация по префиксу:** Используй префикс `@<scope>/AR-XXXX--` для группировки фактов по текущему отчёту.
+   - Например, если создаёшь `AR-0012`, ищи все facts с subject начинающимся на `@root/AR-0012--`
+   - Это отфильтрует факты только по текущему анализу, исключив старые
+
+3. **Группировка по темам:** Факты уже сгруппированы по суффиксу в subject:
+   - `--entities` → раздел "Сущности"
+   - `--patterns` → раздел "Паттерны проектирования"
+   - `--dependencies` → раздел "Зависимости"
+   - `--data-flow` → раздел "Потоки данных"
+   - `--mechanisms` → раздел "Механизмы"
+   - `--libraries` → раздел "Внешние библиотеки"
+
+4. **Очистка и дедупликация:**
+   - Удали полные дубликаты (одинаковые fact и citations)
+   - Объедини похожие факты, если они описывают одно и то же
+   - При противоречиях — перепроверь код и оставь только правильный факт
+
+5. **Сортировка по citations:** Упорядочь факты по файлам для логичного повествования (например, все факты о `src/auth/*` вместе).
+
+**Пример работы с memories:**
+
+Если создаёшь отчёт `AR-0023 - Модуль авторизации (As-Is)`, ищи все facts где:
+- `subject` начинается с `@auth-service/AR-0023--`
+
+Группируй их:
+- `@auth-service/AR-0023--entities` → 5 фактов → раздел "Сущности модуля"
+- `@auth-service/AR-0023--patterns` → 2 факта → раздел "Паттерны"
+- `@auth-service/AR-0023--data-flow` → 8 фактов → раздел "Потоки данных"
+
+Каждый факт содержит citations (файл:строка), используй их в отчёте для ссылок на код.
+
+### 6.1. Структура отчёта: Режим A (Overview)
+
+````markdown
+# AR-XXXX - Обзор проекта <Название> (As-Is)
+
+> **Тип документа:** Реверс-инжиниринг (Overview)  
+> **Дата анализа:** YYYY-MM-DD  
+> **Скоуп:** [путь к корню проекта]
+
+## 1. Общее описание
+
+**Назначение проекта:** [2-3 предложения о том, что делает проект]
+
+**Тип проекта:** [CLI / Web Server / GUI / Library / Monorepo]
+
+**Основной стек:** [язык, фреймворки, основные библиотеки]
+
+## 2. Архитектурный стиль
+
+**Общий стиль:** [Monolith / Modular Monolith / Microservices / Layered / Event-Driven]
+
+**Признаки:**
+- [Конкретный признак 1 с примером из кода]
+- [Конкретный признак 2 с примером из кода]
+
+**Используемые паттерны:**
+- **[Pattern Name]:** Реализован в [файл:строка], используется для [назначение].
+
+## 3. Структура проекта
+
+### Карта модулей
+
+```
+[Дерево директорий с комментариями о назначении каждой папки]
+```
+
+### Основные модули
+
+Для каждого ключевого модуля:
+
+#### 3.1. Модуль: `[название]`
+- **Назначение:** [Что делает модуль]
+- **Ключевые файлы:** [Список с кратким описанием]
+- **Зависимости:** [От кого зависит, кто зависит от него]
+- **Entry point:** [Главный файл модуля, если есть]
+
+## 4. Точки входа (Entry Points)
+
+Список всех точек входа в приложение:
+- **`[файл]`:** [Что запускает, как используется]
+
+## 5. Зависимости
+
+### Внешние библиотеки
+
+Таблица ключевых зависимостей:
+
+| Библиотека | Версия | Назначение | Использование в проекте |
+|:-----------|:-------|:-----------|:------------------------|
+| [name]     | [ver]  | [purpose]  | [как используется]      |
+
+### Граф внутренних зависимостей
+
+```
+[ASCII-диаграмма или описание]
+Модуль A → Модуль B → Модуль C
+Модуль D → Модуль C
+```
+
+**Циклические зависимости:** [Список, если найдены, или "Не обнаружено"]
+
+## 6. Основные механизмы
+
+Описание устойчивых механизмов работы:
+
+### 6.1. [Механизм 1, например "Обработка ошибок"]
+**Где реализовано:** [Файл:строка]
+**Как работает:** [Краткое описание алгоритма]
+**Где используется:** [Список мест использования]
+
+## 7. Конфигурация
+
+**Конфигурационные файлы:** [Список с назначением]
+**Переменные окружения:** [Список используемых ENV переменных]
+**Настройки по умолчанию:** [Где хранятся, как переопределяются]
+
+## 8. Точки расширения
+
+Места, где архитектура предусматривает расширяемость:
+- **Плагины:** [Если есть система плагинов]
+- **Хуки/Events:** [Если есть событийная модель]
+- **DI контейнер:** [Если используется Dependency Injection]
+
+## 9. Дополнительные материалы
+
+**Метрики:**
+- Всего файлов: [N]
+- Основной язык: [язык] ([X]% кода)
+- Глубина вложенности директорий: [N]
+
+**Диаграммы:** [При необходимости]
+````
+
+### 6.2. Структура отчёта: Режим B (Deep-Dive)
+
+````markdown
+# AR-XXXX - Модуль <Название> (As-Is)
+
+> **Тип документа:** Реверс-инжиниринг (Deep-Dive)  
+> **Дата анализа:** YYYY-MM-DD  
+> **Скоуп:** [путь к модулю]
+
+## 1. Общее описание модуля
+
+**Назначение:** [Чем занимается модуль]
+
+**Место в архитектуре:** [Как связан с другими модулями]
+
+**Основные ответственности:** [Список ключевых задач]
+
+## 2. Структура модуля
+
+```
+[Дерево файлов модуля с комментариями]
+```
+
+## 3. Сущности (Entities/Models/Types)
+
+Для каждой сущности:
+
+### 3.1. `[EntityName]`
+**Локация:** [файл:строка]
+
+**Назначение:** [Для чего используется]
+
+**Определение:**
+```[язык]
+[Код определения сущности]
+```
+
+**Поля/Свойства:**
+- `field1`: [тип] - [описание]
+- `field2`: [тип] - [описание]
+
+**Где используется:** [Список файлов:строк, где используется]
+
+## 4. Публичный интерфейс (API)
+
+Все экспортируемые функции/классы:
+
+### 4.1. `[functionName]`
+**Локация:** [файл:строка]
+
+**Сигнатура:**
+```[язык]
+[Полная сигнатура функции]
+```
+
+**Параметры:**
+- `param1`: [тип] - [описание]
+
+**Возвращает:** [тип и описание]
+
+**Побочные эффекты:** [Что делает кроме возврата значения: БД, API, файлы]
+
+**Примеры использования:**
+```[язык]
+[Реальные примеры из кодовой базы]
+```
+
+**Где вызывается:** [Список мест использования]
+
+## 5. Потоки данных
+
+Описание движения данных через модуль:
+
+## Сценарий 1: [Название]
+```mermaid
+graph LR
+    A[Точка входа] --> B[Обработка 1]
+    B --> C[Обработка 2]
+    C --> D[Результат]
+```
+
+**Детали:**
+1. **[Шаг 1]** ([файл:строка]): [Что происходит]
+2. **[Шаг 2]** ([файл:строка]): [Что происходит]
+
+**Примеры:** [Реальный код из кодовой базы]
+
+## 6. Зависимости модуля
+
+### Импортируемые модули
+- **`[модуль]`:** [Что из него используется, где]
+
+### Используемые библиотеки
+- **`[библиотека]`:** [Для чего, в каких файлах]
+
+### Зависимые модули
+[Кто зависит от этого модуля]:
+- **`[модуль]`:** [Что использует]
+
+## 7. Внутренние механизмы
+
+Детальное описание механизмов работы внутри модуля:
+
+### 7.1. [Механизм, например "Валидация данных"]
+**Где реализовано:** [файл:строка]
+
+**Как работает:** [Пошаговое описание]
+
+**Примеры:**
+```[язык]
+[Код примера]
+```
+
+## 8. Паттерны проектирования
+
+Паттерны, использованные в модуле:
+- **[Pattern]:** [Где и как реализован]
+
+## 9. Конфигурация модуля
+
+[Настройки, специфичные для модуля, если есть]
+
+## 10. Дополнительная информация
+
+**Метрики модуля:**
+- Файлов: [N]
+- Строк кода: ~[N]
+- Публичных функций/классов: [N]
+- Зависимостей: [N]
+````
+
+### 6.3. Структура отчёта: Режим C (Mechanism)
+
+````markdown
+# AR-XXXX - Механизм <Название> (As-Is)
+
+> **Тип документа:** Реверс-инжиниринг (Mechanism)  
+> **Дата анализа:** YYYY-MM-DD  
+> **Скоуп:** [механизм/алгоритм]
+
+## 1. Общее описание механизма
+
+**Что делает:** [2-3 предложения о назначении механизма]
+
+**Зачем нужен:** [Какую проблему решает]
+
+**Где используется:** [Общее представление о точках использования]
+
+## 2. Компоненты механизма
+
+Список всех частей, составляющих механизм:
+
+### 2.1. Компонент: `[название]`
+**Локация:** [файл:строка]
+
+**Роль в механизме:** [Что делает]
+
+**Тип:** [Class / Function / Module / Configuration]
+
+**Код:**
+```[язык]
+[Ключевые части кода компонента]
+```
+
+## Алгоритм работы
+
+Пошаговое описание работы механизма:
+
+### Фаза 1: [Название фазы]
+**Где:** [файл:строка]
+
+**Что происходит:**
+1. [Действие 1]
+2. [Действие 2]
+
+**Код:**
+```[язык]
+[Соответствующий код]
+```
+
+### Фаза 2: [Название фазы]
+[То же самое]
+
+## 4. Диаграмма потока
+
+```mermaid
+graph LR
+    A[Trigger] --> B[Handler]
+    B --> C[Validator]
+    C --> D[Processor]
+    D --> E[Storage]
+    B --> F[Logger]
+    D --> G[EventEmitter]
+```
+
+## 5. Точки использования
+
+Все места в кодовой базе, где вызывается механизм:
+
+### 5.1. Использование в `[файл]`
+**Локация:** [файл:строка]
+
+**Контекст:** [В какой ситуации вызывается]
+
+**Код:**
+```[язык]
+[Фрагмент кода с вызовом]
+```
+
+## 6. Конфигурация и параметры
+
+**Настраиваемые параметры:** [Список]
+
+**Значения по умолчанию:** [Где определены]
+
+**Переопределение:** [Как можно изменить поведение]
+
+## 7. Зависимости
+
+**Использует:**
+- [Библиотека/модуль 1]: [для чего]
+- [Библиотека/модуль 2]: [для чего]
+
+**Используется в:**
+- [Модуль/функция 1]
+- [Модуль/функция 2]
+
+## 8. Примеры использования
+
+### Пример 1: [Название сценария]
+**Описание:** [Что делает этот пример]
+
+**Код:**
+```[язык]
+[Полный рабочий пример из кодовой базы или синтетический]
+```
+
+**Результат:** [Что происходит после выполнения]
+
+## Вариации и модификации
+
+[Если механизм имеет разные режимы работы или конфигурации]:
+- **Режим A:** [Описание]
+- **Режим B:** [Описание]
+
+## Связь с другими механизмами
+
+[Как этот механизм взаимодействует с другими]:
+- Вызывается после [механизм X]
+- Вызывает [механизм Y]
+- Альтернатива для [механизм Z] в случае [условие]
+````
+
+## Фаза 6: Финальная проверка
+
+Перед сохранением отчёта проверь:
+1. **Номер AR-XXXX уникален** и файл содержит суффикс `(As-Is)`.
+2. **Все утверждения подтверждены фактами** из кода (файл:строка указаны).
+3. **Нет качественных оценок** ("плохо", "хорошо", "надо исправить") — только описание.
+4. **Структура соответствует режиму** (Overview/Deep-Dive/Mechanism).
+5. **Все ключевые memories включены** в отчёт (проверь, что ничего важного не забыто).
+6. **Примеры кода корректны** (реальные или синтетические, но рабочие).
+
+Если хотя бы одна проверка провалена — **дополни отчёт** перед сохранением.
+
+## Фаза 7: Отчёт пользователю
+
+Выдай короткое резюме:
+1. **Созданный файл:** `AR-XXXX - <Название> (As-Is).md`.
+2. **Режим анализа:** [Overview / Deep-Dive / Mechanism].
+3. **Скоуп:** [Путь к анализируемой области].
+4. **Ключевые находки:**
+   - Основных модулей: [N]
+   - Сущностей: [N]
+   - Паттернов: [N]
+   - Механизмов: [N]
+5. **Следующий шаг:**
+   - Для режима Overview → "Можно провести Deep-Dive для модулей: [A, B, C]"
+   - Для режима Deep-Dive → "Можно создать фичу на основе анализа: `/agentica.create`"
+   - Для режима Mechanism → "Можно улучшить механизм: `/agentica.change`"
+
+## 9. Дополнительные правила
+
+### Работа с большими проектами
+Если проект содержит > 100 файлов (режим Overview):
+1. Сфокусируйся на **top-level структуре**, не пытайся прочитать каждый файл.
+2. Используй `semantic_search` для поиска ключевых паттернов.
+3. Предложи пользователю выбрать 2-3 модуля для последующего Deep-Dive.
+
+### Работа с неочевидным кодом
+Если код не содержит комментариев и непонятен:
+1. Анализируй **имена** (функций, классов, переменных) для понимания назначения.
+2. Используй `list_code_usages` для поиска примеров использования.
+3. Смотри **тесты** (если есть) — они часто объясняют поведение.
+4. Если всё равно непонятно — опиши **что делает код буквально**, не пытаясь интерпретировать.
+
+### Использование Context7 для библиотек
+Когда вызывать:
+1. Библиотека используется в > 3 местах.
+2. Библиотека является core-частью проекта (express, fastapi, react).
+3. Поведение библиотеки не очевидно из имени.
+
+Что извлекать:
+- Основное назначение библиотеки.
+- Ключевые API, используемые в проекте.
+- Особенности поведения (например, async/sync, side effects).
+
+### Объективность анализа
+**Избегай:**
+- ❌ "Код написан плохо"
+- ❌ "Нужно рефакторить"
+- ❌ "Архитектура неправильная"
+
+**Используй:**
+- ✅ "Функция содержит 8 уровней вложенности"
+- ✅ "Обнаружена циклическая зависимость A ↔ B"
+- ✅ "Механизм реализован через паттерн X"
+
+### Терминология
+Используй стандартные термины:
+- **Entry Point** — точка входа в приложение/модуль.
+- **Data Flow** — путь данных через систему.
+- **Dependency Graph** — граф зависимостей между модулями.
+- **Pattern** — паттерн проектирования.
+- **Mechanism** — устойчивая последовательность операций.
+- **Entity** — сущность предметной области или структура данных.