--- title: "Папка .pastukhov" id: "657" type: "page" slug: "pastukhov-folder" published_at: "2026-06-04T17:02:46+00:00" modified_at: "2026-06-13T00:53:06+00:00" url: "https://pastukhov.com/code/docs/pastukhov-folder" markdown_url: "https://pastukhov.com/code/docs/pastukhov-folder.md" excerpt: "Папка .pastukhov/ — это каталог конфигурации и данных Pastukhov Code. Она создаётся автоматически в корне…" --- # Папка .pastukhov [https://pastukhov.com/code/docs/pastukhov-folder.md](https://pastukhov.com/code/docs/pastukhov-folder.md) ## Что такое папка .pastukhov? Папка `.pastukhov/` — это каталог конфигурации и данных Pastukhov Code. Она создаётся автоматически в корне вашего проекта при первом запуске Pastukhov Code и хранит всё необходимое для приложения: определения сборок, настройки развёртывания, пресеты окружений, файлы базы данных, журналы выполнения и многое другое. ![Скриншот, показывающий структуру файлов внутри папки конфигурации .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 Здесь вы определяете автоматические валидаторы сборки — команды, которые проверяют правильность изменений кода ИИ. Несмотря на название, сборкам не обязательно компилировать что-либо. Любая команда, которая выдаёт структурированный вывод (ошибки и предупреждения), подходит для сборки: компиляторы, линтеры, проверщики типов, запуски тестов, сканеры безопасности или пользовательские скрипты валидации. Сборки поддерживают два типа: - **Командные сборки** запускают shell-команду и парсят её вывод на предмет ошибок и предупреждений - **Сборки с промптами** создают новую сессию AI-чата с промптом валидации — полезно для код-ревью или проверок, требующих ИИ-рассуждений ``` build: compile: path: "server/" command: "dotnet build" delay: 3 timeout: 60 watch: "*.cs" ignore: [] replacements: [] stopStrings: [] display: always autofix: всегда 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** — Когда участвовать в AutoFix: `always`, `errors`, `warnings` или `never` - **ignore** — Regex-шаблоны для подавления в выводе ошибок/предупреждений - **replacements** — Пары поиска/замены для ремаппинга путей (полезно, когда сборки запускаются в Docker или временных каталогах) - **stopStrings** — Строки, которые немедленно прерывают сборку при обнаружении в выводе - **startSound / endSound / soundVolume** — Опциональная аудиообратная связь при запуске или завершении сборки Сборки могут цепляться друг к другу — одна сборка может следить за другой, поэтому она запускается только после успешного завершении родительской. Это позволяет создавать упорядоченные пайплайны, такие как компиляция → тест → развёртывание. Вывод сохраняется в `.pastukhov/build/` тремя файлами на задачу: `{name}.output.txt` (полный вывод), `{name}.errors.txt` (спаршенные ошибки) и `{name}.warnings.txt` (спаршенные предупреждения). [Узнайте больше о сборках, AutoFix и панели сборки →](/code/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`). [Узнайте больше об элементах управления развёртыванием, панели развёртывания и методах развёртывания →](/code/docs/build-deploy) ## environments.yml Этот файл хранит пресеты переменных окружения для разных моделей ИИ. Каждое окружение определяет набор переменных, которые применяются при выборе этой модели в интерфейсе — например, идентификатор модели, длина контекста и ценообразование. ``` environments: 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-вариант наследует от обоих `glm-5` и `glm`, поэтому вам нужно определить только переменные, которые изменяются на каждом уровне. Значения с префиксом `$` ссылаются на системные переменные окружения: `$MY_API_KEY` будет заменено значением переменной окружения `MY_API_KEY` из вашей системы. [Узнайте больше о создании и переключении окружений →](/code/docs/environments) ## mcp.yml Этот файл конфигурирует **MCP-серверы (Model Context Protocol)** — внешние инструменты, которые расширяют возможности модели ИИ. MCP-серверы предоставляют дополнительные возможности, такие как веб-браузинг, запросы к базе данных, поиск кода и многое другое. ``` version: "1.0" servers: filesystem: enabled: true type: "stdio" command: "npx" args: - "-y" - "@modelcontextprotocol/server-filesystem" - "/project" env: NODE_ENV: "production" ``` Каждый сервер может использовать один из трёх типов транспорта: - **stdio** — Запускается как локальный процесс, общающийся через стандартный ввод/вывод - **http** — Подключается к удалённому серверу через HTTP - **sse** — Подключается через Server-Sent Events Этот файл **автоматически синхронизируется** с собственной конфигурацией MCP Claude Code при запуске и при обнаружении изменений, поэтому вы можете управлять серверами как из интерфейса настроек Pastukhov Code, так и напрямую в конфигурации Claude Code, и они будут оставаться синхронизированными. [Узнайте больше о добавлении и управлении MCP-серверами →](/code/docs/mcp-servers) ## hooks.yml Этот файл конфигурирует **хуки Claude Code** — правила, которые перехватывают действия ИИ до их выполнения. Хуки позволяют вам запрещать опасные операции или запускать пользовательские команды в определённых точках выполнения ИИ. ``` PreToolUse: Bash: - type: "deny" pattern: "rm -rf /" message: "Dangerous command blocked" - type: "execute" pattern: "git push" command: "echo 'Push detected'" regex: false ``` Существует два типа событий хуков: - **PreToolUse** — Срабатывает до использования любого инструмента ИИ (Bash, редактирование файлов и т.д.). Вы можете `deny` (запретить) совпадающие операции (блокировать их и показать сообщение) или `execute` (выполнить) shell-команду при совпадении шаблона - **UserPromptSubmit** — Срабатывает при отправке промпта, позволяя предварительную обработку Файл `hooks.yml` **автоматически генерирует** `.claude/settings.local.json` — фактическую конфигурацию хуков, которую читает Claude Code. Это означает, что вам нужно поддерживать только `hooks.yml`, а соответствующий файл настроек Claude Code будет автоматически обновляться. [Узнайте больше о правилах запрета, командах выполнения и контроле использования инструментов →](/code/docs/hooks) ## skills.yml Этот файл управляет тем, какие **навыки** активны в вашем проекте и каким цветом они отображаются в интерфейсе. Навыки — это повторно используемые наборы инструкций, которые изменяют поведение ИИ для определённых задач. ``` skills: version: "1.0" activated: my-skill: enabled: true color: "#3b82f6" another-skill: enabled: false ``` Каждая запись навыка имеет переключатель `enabled` и опциональный `color` для отображения в интерфейсе. Отключённые навыки не будут появляться в селекторе навыков и не будут влиять на поведение ИИ. [Узнайте больше об использовании, создании и редактировании навыков →](/code/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 и других. Обычно вам не нужно редактировать его вручную — модель ИИ использует его для понимания того, как подключиться к каждому провайдеру. ## Файлы парсеров Pastukhov Code использует три файла парсеров для извлечения ошибок и предупреждений из текстового вывода. Все три используют один и тот же формат — простую систему на основе правил с блоками `[ERROR]` и `[WARNING]`, содержащими regex-шаблоны. Файлы парсеров полностью документированы встроенными комментариями, поэтому вам редко нужно редактировать их вручную. ### Как работают парсеры Каждый парсер проходит по строкам вывода, пытаясь сопоставить шаблоны по порядку: - **Строки комментариев**, начинающиеся с `#`, игнорируются (используются для документации) - **Однострочные шаблоны** — regex, соответствующий одной строке вывода - **Многострочные шаблоны** — обёрнуты в `{{...}}`, соответствуют нулям или более последовательных строк (полезно для стек-трейсов или отступного контекста) ``` # Ошибки компиляции TypeScript [ERROR] .*\.ts.* # Соответствует строке, содержащей путь к .ts файлу Error.* # Соответствует строке, начинающейся с "Error" {{^\s+}} # Соответствует строкам контекста с отступом, которые следуют далее [/ERROR] ``` Парсеры автоматически перезагружаются при изменении их файлов, поэтому редакции вступают в силу немедленно. ### build.parser Извлекает ошибки и предупреждения из **вывода команд сборки**. Поставляется с шаблонами для C# (MsBuild, CSC), TypeScript, Svelte, Vite, Python (ruff) и ReSharper. Добавьте шаблоны для любых дополнительных инструментов, используемых в вашем проекте. ### deploy.parser Извлекает ошибки и предупреждения из **вывода времени выполнения развёрнутого приложения**. Обрабатывает необработанные исключения, стек-трейсы, сбои подключения к базе данных, HTTP-коды ошибок и сбои приложения на различных платформах. ### output.parser Универсальный парсер для **вывода универсальных скриптов** — ошибки shell, стек-трейсы Python, исключения Node.js, сбои npm и другие распространённые форматы ошибок. Используется, когда вывод не подходит для категорий сборки или развёртывания. ## license.txt Этот файл хранит ваш **ключ лицензии приложения** как строку JSON в кодировке Base64. Он имеет наивысший приоритет среди всех источников лицензии — он переопределяет как аргумент командной строки `--license`, так и переменную окружения `PASTUKHOV_CODE_LICENSE`. Если этот файл присутствует, его содержимое используется независимо от другой конфигурации. [Узнайте больше о типах лицензий, активации и статусе →](/code/docs/licensing) ## project.db Это **база данных приложения**, которая хранит все постоянные данные Pastukhov Code — чаты, сообщения, настройки, аналитику и многое другое. По умолчанию используется **SQLite**, который хранит всё в одном файле без необходимости внешнего сервера баз данных. Может появиться три файла: - `project.db` — Основной файл базы данных - `project.db-wal` — Write-Ahead Log (режим WAL для лучшей производительности при конкурентной работе) - `project.db-shm` — Файл общей памяти для режима WAL База данных автоматически создаётся при первом запуске, а миграции схемы выполняются автоматически при запуске, поэтому вам никогда не нужно управлять ею вручную. Если вы предпочитаете PostgreSQL вместо SQLite, установите переменную окружения `PASTUKHOV_CODE_DATABASE` в строку подключения PostgreSQL, и база данных будет создана там. ## Каталоги ### 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 Code: - `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`, `environments.yml`) также автоматически **валидируются** при сохранении. Результаты валидации появляются в панели сборки вместе с обычными сборками — ошибки красным, предупреждения жёлтым — со ссылками на соответствующий раздел в `README.md`, чтобы вы могли посмотреть правильный формат. **[← Лицензирование](/code/docs/licensing)** **[Удалённое управление →](/code/docs/remote-control)**