"..По сути любой программный код это специальный промпт который понимает среда выполнения и если написать код не правильно то он в этой среде не будет программой, а только текстом к сведению и всё, также и для операционной системы LLM в правильном виде это программа к выполнению в этой среде исполнения!

А миссия у ии-модели одна — решить задачу поставленную пользователем, но до результата т.е. просто результата, а не качественного результата.."

Этот документ описывает конфигурацию и принципы ПРОМПТ-ПРОГРАММИРОВАНИЯ ПОВЕДЕНИЯ ИИ-МОДЕЛИ и работы системы MANDATORY_BEHAVIORAL_FIREWALL.mdc. Система предназначена для управления рабочим процессом AI-ассистента, обеспечивая высокое качество кода, следование лучшим практикам и принудительное исполнение планов.

• Защита Качества Кода: Гарантия того, что любой код не только корректен, но и органично вписывается в проект.
• Принцип Добросовестного Исполнения (good_faith_execution): Любой артефакт (план, отчет) должен быть результатом реальной интеллектуальной работы.
• Мандат "Исследование как Память" (research_as_memory_mandate): Результаты свежих исследований временно переопределяют базовые знания ассистента, обеспечивая использование самых актуальных идиоматичных подходов.
• Запрет на Импровизацию (improvisation_ban): Все действия должны быть прямым исполнением шагов протокола.

Это конвейерный протокол, который выполняется как единый непрерывный процесс перед написанием любого кода. Его цель — собрать контекст, провести всесторонние исследования и сформировать строгий, неизменный план реализации.

Шаги Протокола:

1. Предварительная Декомпозиция Задачи (preliminary_task_decomposition):

   • Что делает: Создает черновой набросок задачи для определения области исследований.
   • Артефакт: task_context.md.

2. Исследование Архитектуры Языка (language_architecture_research):

   • Что делает: Проводит глубокое исследование идиом языка, архитектурных паттернов и лучших практик для высоконагруженных систем.
   • Артефакт: task_language.md. Этот артефакт становится вторым источником правды для написания кода.

3. Исследование Оптимизаций (o1_optimization_research):

   • Что делает: Ищет высокопроизводительные (в идеале O(1)) алгоритмы для решения подзадач.
   • Артефакт: task_optimize.md.

4. Синтез Мандата на Реализацию (mandate_synthesis):

   • Что делает: Собирает информацию из всех предыдущих артефактов и создает единый, строгий план действий.
   • Артефакт: Dynamic_Implementation_Mandate.md. Этот файл является основным источником правды для написания кода.

5. Реализация по Мандату (mandated_implementation):

   • Что делает: Агент пишет код, строго следуя плану из Dynamic_Implementation_Mandate.md и идиомам из task_language.md.

6. Аудит Соответствия Реализации (implementation_to_mandate_adherence_verification):

   • Что делает: Ключевой шаг! Агент создает отчет, в котором доказывает, что написанный код соответствует каждому пункту из Dynamic_Implementation_Mandate.md и каждому идиоматическому принципу из task_language.md.
   • Артефакт: implementation_audit.md.

7. Верификация Компиляции (post_implementation_verification):

   • Что делает: Только после успешного аудита агент может попытаться скомпилировать код.

Эти триггеры — ядро надежности системы.

• sealed_artifact_protection (Защита от перезаписи): Самый важный механизм. После того как артефакт (например, Dynamic_Implementation_Mandate.md) создан, он "запечатывается". Любая попытка его изменить в рамках текущего протокола будет жестко заблокирована. Это предотвращает порчу плана после его утверждения.
• protocol_execution_engine (Движок протоколов): Оркестратор, который следит за строгим пошаговым выполнением протоколов и отвечает за "запечатывание" артефактов.
• pre_code_modification_protocol: Блокирует любую попытку изменения исходного кода, если предварительно не был выполнен протокол pre_task_professionalism_protocol.

Система включает механизмы обработки ненадежных ответов инструментов:

• Проблема: Инструменты модификации файлов (edit_file, create_file) иногда возвращают ложные сообщения об ошибках или неопределенные ответы типа "no changes made", когда изменения на самом деле были внесены.
• Решение: Автоматическая верификация реального состояния файла после каждого сбоя.

Алгоритм работы:

1. Детектирование: Система обнаруживает сообщение о сбое от инструмента.
2. Запрет Предположений: Агенту запрещено принимать ответ инструмента за истину.
3. Обязательная Проверка: Система выполняет read_file или grep_search на целевом файле.
4. Синтез Состояния: Последующие действия основываются на реальном состоянии файла, а не на отчете инструмента.

В рамках protocol_execution_engine действует каскадная система отказоустойчивости:

Уровень 1 - Автоматические Ретраи:

• При сбое edit_file или create_file система автоматически повторяет операцию до 3 раз.

Уровень 2 - Альтернативные Методы: Если все ретраи терпят неудачу, система переключается на резервные методы:

1. Первый фоллбек: Использование run_terminal_cmd с командой echo для записи файла.
2. Последний резерв: Создание и выполнение временного Python-скрипта (.tmp_writer.py) для записи.

Уровень 3 - Контролируемый Отказ:

• После провала всех методов протокол останавливается с вердиктом TOOL_FAILURE.
• Пользователь получает точную информацию о причине остановки.

Технический результат: Система повышает надежность выполнения задач в нестабильных средах, где инструменты могут работать нестабильно.

• Что делает: После успешной реализации и валидации задачи автоматически удаляет все временные артефакты (task_context.md, task_language.md, task_optimize.md, Dynamic_Implementation_Mandate.md, implementation_audit.md), поддерживая чистоту рабочего пространства.

1. Поместите файл MANDATORY_BEHAVIORAL_FIREWALL.mdc в директорию .cursor/rules/ в корне вашего проекта.
2. Полностью перезапустите редактор Cursor, чтобы он обнаружил и загрузил новое правило.

После перезапуска файрвол будет автоматически применяться ко всем действиям ассистента в данном проекте.

Это движок, который позволяет проводить стандартизированные исследования для любой технологии.

• universal_stack_research: Ядро системы. Оно использует шаблоны и профили для автоматизации поиска информации.
  • research_step_templates: Определяет многократно используемые сценарии исследования (например, rust_crate для крейтов Rust или web_specification для веб-стандартов).
  • technology_profiles: Содержит профили для конкретных технологий (Bevy, Axum, WGSL), связывая их с шаблоном и предоставляя конкретные данные (имена, поисковые запросы, ссылки).

Расширение файрвола — это добавление новых знаний (профилей исследований) и новых механизмов контроля (правил).

Расширение базы знаний системы происходит в два этапа: сначала вы создаете профиль для конкретной технологии (например, библиотеки), а если для нее не подходит ни один из существующих шаблонов — вы создаете новый шаблон.

Вы делаете это, когда хотите научить систему исследовать новую библиотеку, для которой уже подходит существующий шаблон (например, еще один крейт Rust).

1. Где: research_protocols -> technology_profiles.
2. Что делать: Добавить новый JSON-объект в массив technology_profiles.
3. Обязательные поля объекта:
   • name (string): Официальное название технологии.
   • template (string): Имя существующего шаблона из research_step_templates.
   • template_data (object): Данные для подстановки в шаблон. Ключи в этом объекте должны точно соответствовать плейсхолдерам ({...}) в выбранном шаблоне.

Пример: Добавление крейта anyhow. Мы используем существующий шаблон rust_crate.

// В "technology_profiles" добавляем:
{
  "name": "Anyhow",
  "template": "rust_crate",
  "template_data": {
    "crate_name": "anyhow",
    "library_name": "Anyhow",
    "github_repo": "https://github.com/dtolnay/anyhow",
    "cheatbook_url": "", // Можно оставить пустым, если нет
    "search_terms": "error handling context"
  }
}

Вы делаете это, когда появляется новый класс технологий, для которого нет подходящего сценария исследования (например, библиотеки Python).

1. Где: research_protocols -> research_step_templates.
2. Что делать: Добавить новую пару "ключ-значение". Ключ — имя нового шаблона, значение — массив шагов.
3. Структура каждого шага:
   • step (number): Порядковый номер.
   • description (string): Описание шага.
   • tool_to_call (string): Команда с плейсхолдерами для подстановки.

Пример: Создание шаблона для Python-библиотек и его использование.

1. Создаем шаблон python_library в research_step_templates:

   "python_library": [
     {
       "step": 1,
       "description": "Search PyPI for the library.",
       "tool_to_call": "web_search for 'pypi {library_name}'"
     },
     {
       "step": 2,
       "description": "Search for official documentation and examples.",
       "tool_to_call": "web_search for '{library_name} official documentation examples 2025'"
     }
   ]

2. Создаем профиль для pandas, используя наш новый шаблон (в technology_profiles):

   {
     "name": "Pandas",
     "template": "python_library",
     "template_data": {
       "library_name": "pandas"
     }
   }

Важно понимать: После добавления, при упоминании технологии в задаче, система:

1. Автоматически запустит исследование по ее профилю и шаблону.
2. Сохранит результаты в task_language.md.
3. На шаге implementation_to_mandate_adherence_verification потребует от ассистента доказать, что написанный код соответствует идиомам и лучшим практикам, найденным в ходе этого исследования. Таким образом, новое знание не просто информирует, а становится обязательным для исполнения законом.

Новые правила добавляются в объект precise_triggers. Важно проектировать правила с учетом новой архитектуры, ориентированной на протоколы.

Пример проектирования правила "Проверка лицензий":

Предположим, мы хотим добавить проверку лицензий для всех используемых зависимостей.

1. Интеграция в протокол: Лучшее место для этого — добавить новый шаг в pre_task_professionalism_protocol, например, после исследования технологий.

   // В pre_task_professionalism_protocol.mandatory_steps
   {
     "id": "dependency_license_audit",
     "action": "EXECUTE_LICENSE_AUDIT",
     "purpose": "To audit all project dependencies for license compatibility.",
     "output_artifact": {
       "name": "license_audit.md",
       "location": "memory-bank/artifacts/license_audit.md"
     },
     "verification": { ... }
   }

2. Создание триггера (если нужно): Если действие должно происходить вне протокола, создается новый триггер в precise_triggers.

   "license_check": {
     "id": "license_check",
     "action": "BLOCK_ON_INCOMPATIBLE_LICENSE",
     "purpose": "Prevents the use of dependencies with non-compliant licenses.",
     "trigger": "On file change in package.json, Cargo.toml, etc.",
     "enforcement_logic": "1. Parse dependencies. 2. Fetch license information. 3. Compare against an allowed list. 4. BLOCK if a non-compliant license is found."
   }

Главное — думать не просто о "блокировке", а о том, как правило встраивается в общий, пошаговый и верифицируемый процесс выполнения задачи.

Для получения наиболее надежной и структурированной документации, файрвол использует встроенную интеграцию с системой Context7. Это приоритетный источник данных, который часто дает более точные результаты, чем обычный веб-поиск.

Как это работает:

В шаблонах исследования (research_step_templates) вы можете заметить шаги с типом "atomic_tool_chain". Это означает, что система выполняет не один поисковый запрос, а цепочку связанных команд для работы с Context7:

1. mcp_context7_resolve-library-id: Сначала система находит точный идентификатор библиотеки в базе данных Context7.
2. mcp_context7_get-library-docs: Затем, используя этот ID, она запрашивает самую свежую документацию по конкретной теме.

Пример из шаблона rust_crate:

{
  "step": 3,
  "description": "Execute ATOMIC tool chain: Resolve and fetch documentation from Context7 for the crate.",
  "atomic_tool_chain": [
    { "tool": "mcp_context7_resolve-library-id", "params": { "libraryName": "{library_name}" } },
    { "tool": "mcp_context7_get-library-docs", "params": { "context7CompatibleLibraryID": "[OUTPUT_FROM_PREVIOUS_STEP]" } }
  ]
}

Как это использовать при расширении:

При создании собственных шаблонов исследований для фреймворков или библиотек, рекомендуется отдавать предпочтение atomic_tool_chain с Context7 перед обычным web_search.

Это гарантирует, что на этапе language_architecture_research ассистент получит наиболее качественные и актуальные данные, которые затем станут частью обязательного к исполнению task_language.md.

• code_base_sanctuary: Директория _code_base_/ является абсолютно неприкосновенной. Она содержит эталонный код, который можно использовать только для чтения и анализа. Любые попытки модификации, сборки или тестирования в этой директории блокируются.
• techcontext_compliance: Обеспечивает строгое следование файлу techContext.md не только для команд, но и для специфичных паттернов кодирования.

Помимо основных протоколов, система включает в себя несколько уровней контроля, которые гарантируют точность и полноту выполнения задач.

Эта система гарантирует, что ассистент выполнит все инструкции, заложенные в кастомные режимы (например, в custom_modes/van_instructions.md). Если ассистент пытается перейти к следующему действию (например, изменить файл), не выполнив все предыдущие шаги из инструкции, система заблокирует это действие до тех пор, пока все требования не будут выполнены.

Перед выполнением любой сложной задачи по реализации, система требует от ассистента разбить ее на упорядоченный список более простых, атомарных подзадач. Каждая подзадача должна иметь четкие, проверяемые критерии завершения. Это предотвращает выполнение больших, монолитных задач без промежуточного контроля.

Ассистент не имеет права самостоятельно принимать решение о полном завершении задачи. Он может лишь отметить техническую часть реализации как "выполненную". Финальное закрытие задачи происходит только после вашего подтверждения о том, что вы лично провели тестирование и функционал работает корректно. Это обеспечивает человеческий контроль на самом важном этапе.

• Совместимость с Vanzan's Memory Bank: Эта система файрвола разработана с учетом принципов модульности и может работать совместно с фреймворками, такими как cursor-memory-bank от vanzan01. В то время как Memory Bank предоставляет структуру для управления задачами и режимами (VAN, PLAN, etc.), данный файрвол служит более низкоуровневым "ядром безопасности", которое контролирует само исполнение команд и следование правилам внутри этих режимов. Они дополняют друг друга.

• Адаптация для других систем (например, roocode для VSCode): Концепции и логика, заложенные в этом файле правил, являются универсальными. Хотя синтаксис триггеров и действий специфичен для Cursor, сама структура (анализ до/после задачи, хранилище знаний, контроль исполнения) может быть адаптирована для других систем автоматизации и AI-агентов, таких как roocode для VSCode, путем трансляции правил в соответствующий для целевой платформы формат.