Файл .workaignore

.workaignore — это текстовый файл в корне проекта, которым вы говорите WorkAI, какие пути не включать в индекс кодовой базы. Всё, что попало под правило, не сканируется, не разбивается на фрагменты и не уходит в индекс, а значит не появляется в результатах семантического поиска агента. Файл необязательный: без него работают только встроенные правила.

Где лежит файл #

Ровно один файл, ровно в корне проекта — рядом с package.json или .git. Вложенные .workaignore во внутренних папках не читаются: правила для подпапок пишите в корневом файле путями от корня.

Файл — часть проекта, поэтому его можно коммитить в репозиторий: тогда правила будут одинаковыми у всей команды.

Почему не .gitignore #

.gitignore для индексации не используется, и это осознанное решение, а не недоработка. Эти два файла решают разные задачи: .gitignore отвечает на вопрос «что не коммитить», а индексу нужен исходный код вместе с документацией и конфигами — то есть частично как раз то, что многие проекты из Git исключают. Если бы WorkAI читал .gitignore, из поиска молча выпадали бы нужные файлы.

Поэтому правила для WorkAI задаются отдельно. Дублировать в .workaignore типовые каталоги сборки не нужно — они уже исключены (см. ниже).

Синтаксис правил #

Формат близок к .gitignore, но проще:

# комментарии начинаются с решётки, пустые строки игнорируются

legacy/                  # каталог целиком
docs/internal/notes.md   # конкретный файл от корня проекта
*.sample.json            # маска по имени
**/migrations/**         # каталог с таким именем на любом уровне вложенности

Что важно знать про сопоставление:

• правило проверяется и по пути от корня проекта, и по имени файла. Строка notes.md исключит файл с таким именем в любой папке, а не только в корне;
• каталог на произвольной глубине надёжнее задавать маской **/имя/**. Запись legacy/ закрывает только legacy в корне;
• ведущий слэш просто отбрасывается: /legacy и legacy работают одинаково;
• отрицающие правила вида !keep-this.ts не поддерживаются — исключений из исключений нет, пишите правила так, чтобы они сразу описывали только то, что нужно скрыть.

Что исключено и без вашего участия #

Даже с пустым или отсутствующим .workaignore в индекс не попадают:

• файлы с секретами: .env и его варианты, *.key, *.pem, сертификаты и хранилища ключей, SSH-ключи, credentials.json, secrets.json, файлы учётных данных облачных провайдеров. Это правило приоритетнее пользовательских: разрешить такой файл через .workaignore нельзя;
• типовые каталоги зависимостей и сборки: node_modules, dist, build, out, .next, venv, __pycache__, target, vendor, coverage, .git, .cache и подобные;
• бинарные файлы, архивы, изображения, видео, шрифты, базы данных, логи, бэкапы, временные файлы;
• тесты и фикстуры: каталоги test, tests, spec, specs, e2e, fixtures, __tests__, __mocks__ и файлы вида *.test.ts, *.spec.ts, *.e2e.ts;
• сгенерированное и служебное: *.generated.*, *.gen.*, *.min.*, *.bundle.*, *.d.ts, *.stories.*, protobuf-генерация, снапшоты .snap, source maps .map, package-lock.json, yarn.lock, pnpm-lock.yaml.

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

Кроме того, индексируются только файлы из фиксированного списка расширений — около трёх десятков: .ts, .tsx, .js, .jsx, .py, .go, .rs, .java, .c, .cpp, .cs, .php, .rb, .swift, .kt, .md, .json, .yaml, .yml, .toml, .xml и ещё несколько. Всё остальное — например .css, .html, .sql, .sh — в индекс не попадёт и без правила.

На что правила влияют, а на что нет #

.workaignore управляет индексом кодовой базы. Исключённый путь не будет найден семантическим поиском агента (vector_search) — подробнее про инструменты поиска на странице Поиск по коду.

Он не запрещает агенту работать с файлом другими способами: если вы сами назовёте путь, приложите файл к сообщению или агент найдёт его текстовым поиском по содержимому либо по имени, файл будет прочитан. .workaignore — это про то, что уезжает в индекс, а не про запрет доступа к диску.

Отдельно работает защита секретов при вложениях: файл, который выглядит как хранилище учётных данных, не будет приложен к сообщению, даже если вы выбрали его вручную.

Когда изменения вступят в силу #

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

Обратный случай тоже стоит держать в голове: если вы убрали правило и вернули папку в индекс, её содержимое появится в поиске не мгновенно, а после того как пройдёт очередная индексация.

С чего начать #

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

# крупные сгенерированные артефакты
src/api/generated/**
**/locales/**

# данные и дампы
data/dumps/**
*.sample.json

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