--- title: "Папка .pastukhov" id: "657" type: "page" slug: "pastukhov-folder" published_at: "2026-06-04T17:02:46+00:00" modified_at: "2026-10-04T01:24:21+00:00" url: "https://pastukhov.com/agents/agent/docs/pastukhov-folder" markdown_url: "https://pastukhov.com/agents/agent/docs/pastukhov-folder.md" excerpt: "Папка .pastukhov/ — это каталог конфигурации и данных Pastukhov Agent. Она создаётся автоматически в корне…" --- # Папка .pastukhov [https://pastukhov.com/agents/agent/docs/pastukhov-folder.md](https://pastukhov.com/agents/agent/docs/pastukhov-folder.md) ## Что такое папка .pastukhov? Папка `.pastukhov/` — это каталог конфигурации и данных Pastukhov Agent. Она создаётся автоматически в корне вашего проекта при первом запуске Pastukhov Agent и хранит всё необходимое для приложения: определения сборок, настройки развёртывания, пресеты моделей, файлы базы данных, журналы выполнения и многое другое. ![Скриншот, показывающий структуру файлов внутри папки конфигурации .pastukhov](https://pastukhov.com/wp-content/uploads/2026/06/xedant-folder-content-v4.png) Вам редко приходится редактировать эти файлы самостоятельно. ИИ-модель читает `.pastukhov/README.md`, чтобы понять формат каждого файла конфигурации, поэтому вы можете просто попросить её внести изменения — «добавить сборку, которая запускает мой линтер», «настроить Docker-развёртывание на staging», «создать новую модель для GPT-4» — и модель правильно обработает синтаксис YAML и структуру файлов. На этой странице объясняется, что делает каждый файл и папка, чтобы вы знали, что в них находится, и могли принимать обоснованные решения, когда ИИ предлагает изменения. ## project.yml Это «удостоверение личности» вашего проекта. В нём хранится название проекта, дополнительная иконка и дополнительная ссылка для открытия проекта в веб-редакторе VS Code. ``` project: name: "MyProject" # Автоопределяется из git remote URL icon: ".pastukhov/project.svg" # Опционально: иконка проекта, отображаемая в интерфейсе code: "https://..." # Опционально: URL VS Code Web ``` Поле `name` автоматически устанавливается из вашего git remote при первом запуске, поэтому обычно вам не нужно его изменять. Поле `icon` может указывать на файл `.svg` или `.ico`. Поле `code` используется, когда вы хотите кнопку в интерфейсе, которая открывает ваш проект напрямую в VS Code. ## build.yml Здесь вы определяете автоматические проверки сборки — команды, которые проверяют, правильно ли ИИ изменил код. Несмотря на название, сборке совсем не обязательно компилировать что-то. Подойдёт любая команда, которая выдаёт понятный результат — ошибки и предупреждения: компиляторы, линтеры (проверка стиля и ошибок в коде), проверщики типов, запуски тестов, сканеры безопасности или собственные скрипты проверки. Сборки поддерживают два типа: - **Командные сборки** выполняют команду и разбирают её вывод, выискивая ошибки и предупреждения - **Сборки с промптами** создают новый чат с проверочным заданием — удобно для ревью кода и проверок, где нужно «подумать» с помощью ИИ ``` build: compile: path: "server/" command: "dotnet build" delay: 3 timeout: 60 watch: "*.cs" ignore: [] replacements: [] stopStrings: [] display: always autofix: always startSound: "" endSound: "" soundVolume: 1.0 ai-review: watch: chat prompt: "/verify Review the recent code changes. Read the transcript at {chat} and report any problems." chatTitle: "Code Review" delay: 5 timeout: 120 ``` Основные свойства: - **command** — Shell-команда для выполнения (только для командных сборок) - **prompt** — Промпт проверки, отправляемый в новый AI-чат (только для сборок с промптами) - **watch** — шаблоны имён файлов (`*.ts *.js`), названия других сборок (`compile`) или `chat` для запуска по завершении пользовательского чата - **delay** — Секунды ожидания перед запуском после обнаружения изменений (по умолчанию: 3) - **timeout** — Максимальное время выполнения в секундах (по умолчанию: 60) - **display** — Когда показывать в панели сборки: `always`, `errors`, `warnings` или `never` - **autofix** — Когда участвовать в Автоисправлении: `always`, `errors`, `warnings` или `never` - **ignore** — Regex-шаблоны для подавления в выводе ошибок/предупреждений - **replacements** — пары «найти/заменить» для путей в выводе (полезно, когда сборка запускается в Docker или временных каталогах) - **stopStrings** — Строки, которые немедленно прерывают сборку при обнаружении в выводе - **startSound / endSound / soundVolume** — Опциональная аудиообратная связь при запуске или завершении сборки Сборки могут следовать друг за другом: одна следит за другой и запускается только после её успешного завершения. Так выстраиваются цепочки проверок — например, компиляция → тесты → развёртывание. Вывод сохраняется в `.pastukhov/build/` тремя файлами на задачу: `{name}.output.txt` (полный вывод), `{name}.errors.txt` (спаршенные ошибки) и `{name}.warnings.txt` (спаршенные предупреждения). [Узнайте больше о сборках, Автоисправлении и панели сборки →](/agents/agent/docs/build-deploy) ## deploy.yml Этот файл определяет цели развёртывания — как запускается ваше приложение после прохождения сборок. Он поддерживает два метода: **debug** для локальной разработки и **docker** для удалённых развёртываний контейнеров. ``` # Локальная разработка — запускается напрямую на вашем компьютере deploy: my-app: method: "debug" path: "./server" command: "dotnet run" watch: "compile" # Перезапускается после успешного завершения этой сборки shallowCopy: true # Копировать только изменённые файлы (быстрее) url: "https://..." # Опционально: кликабельная ссылка в интерфейсе startSound: "" endSound: "" # Удалённое развёртывание — отправляет в Docker-контейнер через SSH deploy: production: method: "docker" host: "server.com" username: "deploy" sshKeyPath: "~/.ssh/key" imageName: "app:latest" containerName: "myapp" dockerfilePath: "./Dockerfile" environmentVariables: - PORT=3000 portMappings: "8080": "3000" ``` Метод **debug** запускает приложение прямо на вашем компьютере — удобно для разработки. Он умеет следить за сборками и перезапускаться после успешной проверки, копирует только изменённые файлы (так перезапуск быстрее) и поддерживает переменные окружения. Метод **docker** отправляет код на удалённый сервер по SSH, собирает Docker-образ и управляет контейнером — для staging и production. Поддерживаются настройка портов и томов (папок), Docker-сети, проверки работоспособности и свои параметры сборки. Вывод запущенного приложения сохраняется в `.pastukhov/deploy/{name}.log`. Оба метода поддерживают опциональные звуковые уведомления (`startSound`, `endSound`, `soundVolume`). [Узнайте больше об элементах управления развёртыванием, панели развёртывания и методах развёртывания →](/agents/agent/docs/build-deploy) ## models.yml Этот файл хранит пресеты моделей ИИ. Каждая модель определяет набор переменных, которые применяются при выборе этой модели в интерфейсе — например, идентификатор модели, длина контекста и ценообразование. ``` models: claude-sonnet: variables: - ANTHROPIC_MODEL=claude-sonnet-4-20250514 - MODEL_CONTEXT_LENGTH=200000 - MODEL_INPUT_PRICE=3.0 - MODEL_OUTPUT_PRICE=15.0 claude-sonnet-fast: variables: - ANTHROPIC_MODEL=claude-sonnet-4-20250514 - MODEL_CONTEXT_LENGTH=200000 - MODEL_INPUT_PRICE=3.0 - MODEL_OUTPUT_PRICE=15.0 ``` Модели поддерживают **наследование**: дочерняя модель перенимает все переменные родительской. Например, если есть модели `glm`, `glm-5` и `glm-5-turbo`, вариант turbo унаследует настройки от обоих, и вам нужно задать только то, что отличается на каждом уровне. Значения с префиксом `$` ссылаются на системные переменные окружения: `$MY_API_KEY` будет заменено значением переменной окружения `MY_API_KEY` из вашей системы. [Узнайте больше о создании и переключении моделей →](/agents/agent/docs/models) ## miniagent.yml В этом файле хранятся **именованные профили** для [MiniAgent](/agents/agent/docs/mini-agent) — встроенного движка агента, которому не нужны внешние программы. Профиль объединяет настройки одного режима работы: какие инструменты разрешены модели, сколько секунд ждать ответа инструмента, каким указанием руководствоваться, сколько команд исполнять разом. Профиль выбирается в переменной бэкенда приставкой `mini:` — например, `AGENT_BACKEND=mini:safe`. Без приставки, а также с незнакомым именем MiniAgent работает со встроенными значениями. ``` profiles: safe: loadClaudeMd: true # читать файлы контекста CLAUDE.md loadAgentsMd: false # читать файлы контекста AGENTS.md disabledTools: # эти инструменты отключены (по умолчанию — включены все) - bash toolCallTimeout: 60 # сколько секунд ждать один запуск инструмента maxOutputTokens: 131072 # потолок выходных токенов на один запрос parallelBashThreads: 5 # сколько команд одного вызова исполнять одновременно systemPrompt: | # замена встроенного основного указания (пусто — встроенное) You are a careful coding assistant. sessionHeader: X-My-Session # имя заголовка с идентификатором беседы для провайдера # (по умолчанию X-Agent-Session) readonly: # тот же набор ключей, но списком разрешения enabledTools: # доступны только перечисленные инструменты - read - grep - ls ``` Каждый ключ необязателен: пропущенный ключ, незнакомое имя профиля и отсутствующий файл означают встроенные значения по умолчанию. Настройки профиля закрепляются один раз — при создании чата: уже начатый чат сохраняет прежние инструменты и указания, а правки подхватит следующий. Карточка «MiniAgent» в настройках правит этот файл как форму. [Узнайте больше о профилях MiniAgent →](/agents/agent/docs/mini-agent) ## keys.yml Здесь лежат **именованные ключи доступа** — по одному на каждое устройство, программу или исполнителя. Такой ключ открывает вход в агент из другой программы: она передаёт ключ в заголовке `X-API-Key` и получает полный доступ — все адреса `/api/*` и живые события, как при входе менеджером. Самих ключей в файле нет: только **соль** (общая случайная строка, создаётся один раз) и **солёные хеши**. Отпечаток считается одной формулой — `SHA256(соль + ключ)`. По нему ключ восстановить нельзя, поэтому файл безопасно коммитить в репозиторий. ``` # Именованные ключи доступа. Каждый хеш — SHA256(соль + ключ) в шестнадцатеричном виде. # Сам ключ показывается один раз при создании и нигде не хранится. salt: 9f1c... # соль — 64 шестнадцатеричных символа, создаётся один раз keys: - name: laptop # имя: буквы, цифры, «_» и «-», от 1 до 64 символов, без повторов hash: a3b5c... # 64 шестнадцатеричных символа: SHA256(соль + ключ) - name: ci-runner hash: 77d0e... ``` Сам ключ выглядит как `agent_` и ещё 32 случайных символа из латинских букв и цифр — по приставке его легко узнать среди других ключей и токенов. Файл создаётся сам при выдаче первого ключа: готовить его заранее не нужно, а удаление последнего ключа сохраняет файл вместе с солью. Выдавать ключи удобнее в карточке «Ключи доступа» (Настройки → группа «Конфигурация»), а руками файл правится на вкладке `keys.yml` в «Настройках проекта» — например, чтобы дописать ключ, посчитав его хеш по той же формуле. Даже одного именованного ключа достаточно, чтобы заработали адреса удалённого управления. Если файл правят сразу в двух местах, второе сохранение отклоняется с просьбой перезагрузить список — так чужая правка не затирается. [Узнайте больше о ключах доступа →](/agents/agent/docs/access-keys) ## mcp.yml В этом файле подключаются **MCP-серверы** — внешние инструменты, расширяющие возможности модели: просмотр веб-страниц, запросы к базам данных, поиск по коду и другое. ``` version: "1.0" servers: filesystem: enabled: true type: "stdio" command: "npx" args: - "-y" - "@modelcontextprotocol/server-filesystem" - "/project" env: NODE_ENV: "production" ``` Каждый сервер подключается одним из трёх способов: - **stdio** — запускается как программа на вашем компьютере - **http** — подключается к удалённому серверу через интернет - **sse** — подключается через Server-Sent Events (сервер сам присылает обновления) Этот файл **автоматически синхронизируется** с собственной конфигурацией MCP Claude Code при запуске и при обнаружении изменений, поэтому вы можете управлять серверами как из интерфейса настроек Pastukhov Agent, так и напрямую в конфигурации Claude Code, и они будут оставаться синхронизированными. Кроме того, этот же файл читает встроенный агент [MiniAgent](/agents/agent/docs/mini-agent) — он подключает включённые серверы сам, без командной строки Claude Code. [Узнайте больше о добавлении и управлении MCP-серверами →](/agents/agent/docs/mcp-servers) ## hooks.yml В этом файле задаются **хуки** — правила, которые перехватывают действия ИИ до их выполнения. С их помощью можно запрещать опасные операции или запускать свои команды в нужные моменты. ``` PreToolUse: Bash: - type: "deny" pattern: "rm -rf /" message: "Dangerous command blocked" - type: "execute" pattern: "git push" command: "echo 'Push detected'" regex: false ``` Событий, к которым можно привязать хуки, семь: **PreToolUse** («Перед использованием инструмента»), **PostToolUse** («После использования инструмента»), **UserPromptSubmit** («Отправка пользователем»), **Stop** («Остановка»), **SessionStart** («Начало сессии»), **SessionEnd** («Конец сессии») и **PreCompact** («Перед сжатием»). В **PreToolUse** можно `deny` (запретить) подходящие операции — с сообщением агенту — или `execute` (выполнить) свою команду; запрещать можно только здесь. В остальных событиях выполняются только свои команды. У выполняемого правила можно указать предел времени в секундах (`timeout`). Файл `hooks.yml` **автоматически генерирует** `.claude/settings.local.json` — фактическую конфигурацию хуков, которую читает Claude Code. Тот же каталог правил применяет и встроенный [MiniAgent](/agents/agent/docs/mini-agent) , поэтому правило действует и в мини-чатах. Вам нужно поддерживать только `hooks.yml`, а файл настроек Claude Code будет обновляться сам. [Узнайте больше о правилах запрета, командах выполнения и контроле использования инструментов →](/agents/agent/docs/hooks) ## skills.yml Этот файл управляет тем, какие **навыки** активны в вашем проекте и каким цветом они отображаются в интерфейсе. Навыки — это повторно используемые наборы инструкций, которые изменяют поведение ИИ для определённых задач. ``` skills: version: "1.0" activated: my-skill: enabled: true color: "#3b82f6" another-skill: enabled: false ``` Каждая запись навыка имеет переключатель `enabled` и опциональный `color` для отображения в интерфейсе. Отключённые навыки не будут появляться в селекторе навыков и не будут влиять на поведение ИИ. [Узнайте больше об использовании, создании и редактировании навыков →](/agents/agent/docs/skills) ## providers.yml Этот файл хранит **определения провайдеров ИИ** — предварительно сконфигурированные шаблоны, определяющие способы подключения к различным сервисам ИИ. Каждый провайдер указывает адрес API, названия моделей и шаблоны переменных окружения, необходимые для аутентификации. ``` providers: anthropic: name: "Anthropic" environments: default: variables: - API_BASE_URL=https://api.anthropic.com - MODEL_ID=claude-sonnet-4-20250514 - API_KEY_VAR=ANTHROPIC_API_KEY ``` Этот файл автоматически создаётся из встроенного ресурса, если он отсутствует. Он включает предварительно сконфигурированных провайдеров для популярных сервисов, таких как Anthropic, OpenRouter и других. Обычно вам не нужно редактировать его вручную — модель ИИ использует его для понимания того, как подключиться к каждому провайдеру. ## Файл .env Не в самой папке `.pastukhov/`, а **рядом с ней, в корне проекта**, может лежать файл `.env` — простой список строк вида `ИМЯ=значение`. Это отдельный способ задать переменные окружения: их получают все, кого запускает приложение, — сам агент, скрипты, задачи по расписанию, сборки, развёртывания и операции с git. Здесь удобно держать ключи провайдеров и адреса сервисов, не повторяя их в каждой модели. ``` # Ключи провайдеров ANTHROPIC_API_KEY=sk-ant-... OPENROUTER_API_KEY=... # Дополнить путь, а не заменить его PATH=$PATH:/opt/mytools ``` - **Ссылки на переменные.** Значения `$ИМЯ` и `${ИМЯ}` раскрываются по другим строкам файла и по системному окружению, поэтому `PATH=$PATH:/opt/mytools` дополняет путь, а не затирает его. В одинарных кавычках значение остаётся как есть, без раскрытия; - **Правки на ходу.** Как только файл меняется, приложение перечитывает его: обновлённые значения применяются к следующим запускам, а удалённые из файла переменные возвращаются к прежним значениям (или очищаются); - **Секреты не попадут в git.** Пока файл существует, приложение само держит запись `.env` в `.gitignore` проекта; - **Одно исключение.** Переменную расположения проекта (`AGENT_PROJECT_PATH`) файл не переопределяет: иначе запущенный сервер мог бы переехать в другую папку. Если одна и та же переменная задана и в файле, и в системном окружении, для процессов, запущенных после чтения файла, побеждает значение из файла. ## Файлы парсеров Три файла парсеров вытаскивают ошибки и предупреждения из текстового вывода программ. Все они устроены одинаково — простая система правил с блоками `[ERROR]`, `[WARNING]` и `[IGNORE]`, внутри которых шаблоны поиска (регулярные выражения). Файлы подробно задокументированы комментариями внутри, поэтому править их вручную почти не приходится. ### Как работают парсеры Парсер идёт по строкам вывода и по очереди пробует применить шаблоны: - **Строки комментариев**, начинающиеся с `#`, игнорируются (используются для документации) - **Однострочные шаблоны** — соответствуют одной строке вывода - **Многострочные шаблоны** — заключены в `{{...}}`, захватывают одну или несколько идущих подряд строк (удобно для подробных отчётов об ошибках или контекста с отступами) - **Порядок блоков** — блоки проверяются по очереди, и побеждает первое совпадение: строка достаётся тому правилу, которое стоит выше. Поэтому блоки `[IGNORE]` (строки-исключения, отключающие подсветку ошибок и предупреждений) ставятся выше перекрываемых правил — иначе исключение не сработает. ``` # Ошибки компиляции TypeScript [ERROR] .*\.ts.* # Соответствует строке, содержащей путь к .ts файлу Error.* # Соответствует строке, начинающейся с "Error" {{^\s+}} # Соответствует строкам контекста с отступом, которые следуют далее [/ERROR] # Исключения: эти строки похожи на ошибку, но ею не являются [IGNORE] RUN echo.* # Шаг docker с текстом скрипта в одной строке — внутри может .*timeout.* # встретиться слово вроде "timeout" [/IGNORE] ``` Парсеры перезагружаются автоматически при изменении их файлов — правки вступают в силу сразу. ### build.parser Извлекает ошибки и предупреждения из **вывода команд сборки**. Уже содержит шаблоны для C# (MsBuild, CSC), TypeScript, Svelte, Vite, Python (ruff) и ReSharper — при необходимости добавляйте шаблоны для других инструментов проекта. ### deploy.parser Вытаскивает ошибки и предупреждения из **логов запущенного приложения**: необработанные ошибки (исключения), подробные отчёты об ошибках, сбои подключения к базе данных, HTTP-ошибки и падения на разных платформах. ### output.parser Универсальный парсер для **вывода обычных скриптов**: ошибки командной строки, отчёты об ошибках Python, сбои Node.js и npm и другие типовые форматы. Применяется, когда вывод не относится к сборке или развёртыванию. ## license.txt Этот файл хранит ваш **ключ лицензии приложения** как строку JSON в кодировке Base64. Он имеет наивысший приоритет среди всех источников лицензии — он переопределяет как аргумент командной строки `--license`, так и переменную окружения `AGENT_LICENSE`. Если этот файл присутствует, его содержимое используется независимо от другой конфигурации. [Узнайте больше о типах лицензий, активации и статусе →](/agents/agent/docs/licensing) ## project.db Это **база данных приложения**, которая хранит все постоянные данные Pastukhov Agent — чаты, сообщения, настройки, аналитику и многое другое. По умолчанию используется **SQLite**, который хранит всё в одном файле без необходимости внешнего сервера баз данных. Может появиться три файла: - `project.db` — Основной файл базы данных - `project.db-wal` — журнал изменений: режим WAL ускоряет работу при одновременных чтении и записи - `project.db-shm` — вспомогательный файл общей памяти для режима WAL База создаётся сама при первом запуске, а её структура обновляется автоматически при обновлениях программы — управлять ею вручную не нужно. Вместо SQLite можно использовать PostgreSQL: задайте переменную окружения `AGENT_DATABASE` со строкой подключения, и база данных будет создана там. ## telegram.db База данных для [Telegram-бота](/agents/agent/docs/telegram) : хранит соответствия между чатами Telegram и чатами Pastukhov Agent, а также настройки пользователей (активный чат, выбранный навык). Создаётся автоматически при включении бота; её данные не переносятся в основную базу проекта. Может появиться три файла: - `telegram.db` — Основной файл базы данных - `telegram.db-wal` — журнал изменений - `telegram.db-shm` — вспомогательный файл общей памяти для режима WAL ## proxy.db SQLite-база для [встроенного прокси-сервера](/agents/agent/docs/proxy) — хранит журнал запросов (заголовки, тексты сообщений, количество потраченных токенов, длительность, ошибки) и временное хранилище «размышлений» модели. Создаётся автоматически при активации прокси. Может появиться три файла: - `proxy.db` — Основной файл базы данных - `proxy.db-wal` — журнал изменений - `proxy.db-shm` — вспомогательный файл общей памяти для режима WAL Автоматическая очистка: 30 дней для журнала запросов, 7 дней для временного хранилища рассуждений. API-ключи и секреты автоматически фильтруются из сохранённых данных. ## Каталоги ### build/ Хранит журналы вывода сборок. Автоматически создаётся при запуске сборок. Каждая задача сборки производит три файла: `{name}.output.txt` (полный вывод команды), `{name}.errors.txt` (спаршенные ошибки) и `{name}.warnings.txt` (спаршенные предупреждения). Вы можете просматривать их в панели сборки, не открывая файлы напрямую. ### deploy/ Хранит вывод времени выполнения развёртывания и отладочные логи клиента. Автоматически создаётся при запуске развёртываний. Каждое развёртывание производит `{name}.log` с выводом времени выполнения приложения. Отладочные логи клиента хранятся как `{domain}.log` (автоусечение до 100 МБ). ### sounds/ Опциональный каталог для **пользовательских звуков уведомлений**. Поместите сюда файлы `.mp3`, чтобы переопределить встроенные звуки или добавить новые. Встроенные названия звуков: `message`, `notification`, `complete`, `error`, `commit` и `deploy`. Сервер сначала проверяет `.pastukhov/sounds/`, затем возвращается к встроенным значениям по умолчанию. Чтобы восстановить встроенный звук, просто удалите свой пользовательский файл. Свойства `startSound` и `endSound` в `build.yml` и `deploy.yml` могут ссылаться на любое встроенное название или пользовательский звук, помещённый в этот каталог. ### tools/ Опциональный каталог для **служебных скриптов**. Поместите сюда любые вспомогательные скрипты, которые вы хотите использовать вместе с вашим проектом — диагностические инструменты, помощники развёртывания или пользовательскую автоматизацию. Этот каталог не создаётся автоматически. ## Автоматически создаваемые файлы Следующие файлы автоматически создаются при первом запуске, если они не существуют. Вы можете безопасно удалить любой из них — они будут восстановлены из встроенных значений по умолчанию при следующем запуске Pastukhov Agent: - `project.yml` — Метаданные проекта (название автоопределяется из git remote) - `.gitignore` — Шаблоны игнорирования по умолчанию для каталога `.pastukhov/` - `output.parser` — Правила парсера вывода универсальных скриптов - `build.parser` — Правила парсера вывода сборок - `deploy.parser` — Правила парсера вывода развёртывания - `providers.yml` — Определения и шаблоны провайдеров ИИ - `README.md` — Документация формата для всех файлов конфигурации (читается моделью ИИ) Файлы конфигурации (`build.yml`, `deploy.yml`, `project.yml`, `hooks.yml`, `mcp.yml`, `skills.yml`, `models.yml`, `miniagent.yml`) также автоматически **проверяются** при сохранении. Результаты проверки появляются в панели сборки вместе с обычными сборками — ошибки красным, предупреждения жёлтым — со ссылками на соответствующий раздел в `README.md`, чтобы можно было посмотреть правильный формат. **[← Лицензирование](/agents/agent/docs/licensing)** **[Удалённое управление →](/agents/agent/docs/remote-control)**