Агенты > Pastukhov Agent > Документация > Папка .pastukhov

Папка .pastukhov

Что такое папка .pastukhov?

Папка .pastukhov/ — это каталог конфигурации и данных Pastukhov Agent. Она создаётся автоматически в корне вашего проекта при первом запуске Pastukhov Agent и хранит всё необходимое для приложения: определения сборок, настройки развёртывания, пресеты моделей, файлы базы данных, журналы выполнения и многое другое.

Скриншот, показывающий структуру файлов внутри папки конфигурации .pastukhov

Вам редко приходится редактировать эти файлы самостоятельно. ИИ-модель загружает навык agent-manager — в нём описаны форматы всех файлов конфигурации, по файлу на каждый в папке references, — поэтому вы можете просто попросить её внести изменения — «добавить сборку, которая запускает мой линтер», «настроить 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 (спаршенные предупреждения).

Узнайте больше о сборках, Автоисправлении и панели сборки →

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).

Узнайте больше об элементах управления развёртыванием, панели развёртывания и методах развёртывания →

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 из вашей системы.

Узнайте больше о создании и переключении моделей →

miniagent.yml

В этом файле хранятся именованные профили для MiniAgent — встроенного движка агента, которому не нужны внешние программы. Профиль объединяет настройки одного режима работы: какие инструменты разрешены модели, сколько секунд ждать ответа инструмента, каким указанием руководствоваться, сколько команд исполнять разом и сколько подагентов запускать одновременно. Профиль выбирается в переменной бэкенда приставкой mini: — например, AGENT_BACKEND=mini:safe. Без приставки, а также с незнакомым именем MiniAgent работает со встроенными значениями.

profiles:
  safe:
    loadClaudeMd: true          # читать файлы контекста CLAUDE.md
    loadAgentsMd: false         # читать файлы контекста AGENTS.md
    disabledTools:              # эти инструменты отключены (по умолчанию — включены все)
      - bash
    toolCallTimeout: 60         # сколько секунд ждать один запуск инструмента
    maxOutputTokens: 384000     # потолок выходных токенов на один запрос
    thinkingLevel: medium       # уровень размышлений: off, minimal, low, medium, high, xhigh, max
                                # (по умолчанию — уровень из имени модели)
    readMaxLines: 500           # сколько строк один вызов read отдаёт за раз
    parallelBashThreads: 5      # сколько команд одного вызова исполнять одновременно
    maxParallelAgents: 4        # сколько подагентов одного чата работать одновременно
    systemPrompt: |             # замена встроенного основного указания (пусто — встроенное)
      You are a careful
      coding assistant.
    sessionHeader: X-My-Session # имя заголовка с идентификатором беседы для провайдера
                                # (по умолчанию X-Agent-Session)

  readonly:                     # тот же набор ключей, но списком разрешения
    enabledTools:               # доступны только перечисленные инструменты
      - read
      - grep
      - ls

Каждый ключ необязателен: пропущенный ключ, незнакомое имя профиля и отсутствующий файл означают встроенные значения по умолчанию. Настройки профиля закрепляются один раз — при создании чата: уже начатый чат сохраняет прежние инструменты и указания, а правки подхватит следующий. Карточка «MiniAgent» в настройках правит этот файл как форму.

Узнайте больше о профилях MiniAgent →

fetch.yml

Здесь живут сервисы загрузки страниц для MiniAgent — тот набор, что питает инструмент fetch. Вызов пробует включённые сервисы по возрастанию приоритета, пока один из них не ответит; поэтому один недоступный прокси или отклонённый ключ не останавливают работу. У записи пять полей: name, type, enabled, priority и settings.

services:
  - name: Direct HTTP      # имя, по которому сервис узнают в сообщениях
    type: Direct           # Direct | Proxied | BrowserEmulation | Nodriver | RemoteBrowser | ScriptFetch
    enabled: true          # выключенный сервис в переборе не участвует
    priority: 100          # меньшее число пробуется первым
    settings:
      TimeoutSec: "30"     # сколько секунд ждать ответа

Секреты. В настройках пишут $ИМЯ, ${ИМЯ} или ${ИМЯ:-значение-по-умолчанию} — значения подставляются в момент вызова сначала из переменных чата (то есть модели), затем из окружения сервера. Так файл можно коммитить в репозиторий: паролей и ключей в нём нет.

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

Файл поставляется с одним включённым сервисом загрузки (Direct), поэтому загрузка работает сразу. Если файла нет, сервер создаёт его при запуске. Список правится как форма в диалоге MiniAgent на странице «Fetch-сервисы»: там же есть действие «Проверить» и копирование определения сервиса.

Узнайте больше про загрузку страниц →

Это второй, отдельный файл для MiniAgent: здесь живут сервисы поиска в интернете — тот набор, что питает инструмент search. Устроен он так же, как fetch.yml: раздел services:, у записи те же пять полей — name, type, enabled, priority и settings. Перебор тот же: включённые сервисы пробуются по возрастанию приоритета, пока один не ответит, поэтому сбой одного ключа не лишает вас поиска.

services:
  - name: Serper (main)
    type: Serper           # Serper | Keenable | SearXNG | DuckDuckGo | Brave | Tavily |
                           # JsonSeo | Tinyfish | Exa | Anysite | ScriptSearch
    enabled: true
    priority: 100
    settings:
      ApiKey: $SERPER_API_KEY   # ключ берётся из переменной, а не лежит в файле
      TimeoutSec: "30"

Секреты. Записываются так же — $ИМЯ или ${ИМЯ:-значение-по-умолчанию}, — поэтому и этот файл можно коммитить в репозиторий.

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

Файл появляется сам, когда вы сохраняете первый сервис поиска в диалоге MiniAgent на странице «Search-сервисы»: готового сервиса нет, его добавляют сами. Пока файла нет, поиска в новых чатах просто нет. Править список удобнее там же формой — добавление, дублирование, сортировка по приоритету и действие «Проверить» у каждого сервиса.

Узнайте больше про поиск в интернете →

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 в «Настройках проекта» — например, чтобы дописать ключ, посчитав его хеш по той же формуле. Даже одного именованного ключа достаточно, чтобы заработали адреса удалённого управления. Если файл правят сразу в двух местах, второе сохранение отклоняется с просьбой перезагрузить список — так чужая правка не затирается.

Узнайте больше о ключах доступа →

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 — он подключает включённые серверы сам, без командной строки Claude Code.

Узнайте больше о добавлении и управлении MCP-серверами →

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, поэтому правило действует и в мини-чатах. Вам нужно поддерживать только hooks.yml, а файл настроек Claude Code будет обновляться сам.

Узнайте больше о правилах запрета, командах выполнения и контроле использования инструментов →

skills.yml

Этот файл управляет тем, какие навыки активны в вашем проекте и каким цветом они отображаются в интерфейсе. Навыки — это повторно используемые наборы инструкций, которые изменяют поведение ИИ для определённых задач.

skills:
  version: "1.0"
  activated:
    my-skill:
      enabled: true
      color: "#3b82f6"
    another-skill:
      enabled: false

Каждая запись навыка имеет переключатель enabled и опциональный color для отображения в интерфейсе. Отключённые навыки не будут появляться в селекторе навыков и не будут влиять на поведение ИИ.

Узнайте больше об использовании, создании и редактировании навыков →

providers.yml

Это не файл проекта, а файл самого приложения: он лежит внутри установки ({приложение}/static/providers.yml) и приходит с каждым обновлением. В нём — готовые пресеты провайдеров ИИ для мастера новой модели: адрес подключения, поля для ключей и набор моделей с уже заполненными ценами и длиной контекста. Смотреть его полезно, а править — негде.

providers:
  - name: anthropic             # короткое имя пресета
    displayName: "Anthropic"    # как он называется в мастере новой модели
    fields: ...                 # поля подключения: ключ, адрес API
    models: ...                 # готовые модели: цены, длина контекста

В репозиторий проекта он не попадает: копии, которые старые сборки писали в папку .pastukhov/, при запуске удаляются. Мастер новой модели читает файл только для чтения; если файл приложения повреждён, мастер покажет панель ошибок, а сервер продолжит работу. Пресеты включают 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. Если этот файл присутствует, его содержимое используется независимо от другой конфигурации.

Узнайте больше о типах лицензий, активации и статусе →

project.db

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

Может появиться три файла:

  • project.db — Основной файл базы данных
  • project.db-wal — журнал изменений: режим WAL ускоряет работу при одновременных чтении и записи
  • project.db-shm — вспомогательный файл общей памяти для режима WAL

База создаётся сама при первом запуске, а её структура обновляется автоматически при обновлениях программы — управлять ею вручную не нужно. Вместо SQLite можно использовать PostgreSQL: задайте переменную окружения AGENT_DATABASE со строкой подключения, и база данных будет создана там.

telegram.db

База данных для Telegram-бота: хранит соответствия между чатами Telegram и чатами Pastukhov Agent, а также настройки пользователей (активный чат, выбранный навык). Создаётся автоматически при включении бота; её данные не переносятся в основную базу проекта.

Может появиться три файла:

  • telegram.db — Основной файл базы данных
  • telegram.db-wal — журнал изменений
  • telegram.db-shm — вспомогательный файл общей памяти для режима WAL

proxy.db

SQLite-база для встроенного прокси-сервера — хранит журнал запросов (заголовки, тексты сообщений, количество потраченных токенов, длительность, ошибки) и временное хранилище «размышлений» модели. Создаётся автоматически при активации прокси.

Может появиться три файла:

  • 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 — Правила парсера вывода развёртывания
  • fetch.yml — Сервисы загрузки страниц для MiniAgent

Файлы конфигурации (build.yml, deploy.yml, project.yml, hooks.yml, mcp.yml, skills.yml, models.yml, miniagent.yml, fetch.yml, search.yml) также автоматически проверяются при сохранении. Результаты проверки появляются в панели сборки вместе с обычными сборками — ошибки красным, предупреждения жёлтым — со ссылкой вида «use agent-manager skill, references/имя-файла.md»: по ней модель сразу находит в навыке нужный файл с правильным форматом.

Журналы сервера лежат вне папки проекта — во временной папке (/tmp/agent/logs), файлами по дням. Они хранятся последние 7 дней, в резервные копии не попадают и доступны в интерфейсе: Настройки → Инструменты → «Журналы». Подробнее — на странице Аналитика и контроль.

← Лицензирование

Удалённое управление →