Project context, symbols и verify
Как Istok Code подхватывает контекст проекта, ищет определения символов, запускает проверки и использует /fix после упавшего verify.
- Нужно, чтобы агент лучше понимал стек и команды проекта
- Хотите запускать проверки без ручного поиска test и lint команд
- Нужен рабочий путь от ошибки verify до следующего исправления
- Понимание project-aware режима без магии и выдумок
- Умение использовать symbols, verify и fix как единый quality loop
- Чёткое понимание ограничений: symbols это практичный поиск, но не IDE-семантика во всех случаях
Что делает project context
Команда istok-code project и slash-команда /project показывают, как CLI видит текущий проект: корень, стек, менеджер пакетов, найденные проверки и важные проектные файлы вроде README и AGENTS.md. Это полезно не как справка ради справки, а как быстрый способ понять, с чем именно агент будет работать дальше.
Project context нужен не только пользователю, но и самому агенту. Он подмешивается в системный контекст, чтобы команды, пути и проверки выбирались под реальный проект, а не по абстрактной догадке. Если корень проекта не найден или команды проверки пустые, сначала исправляйте это, а не заставляйте verify работать в пустоте.
Как использовать symbols без завышенных ожиданий
Команда istok-code symbols <name> [--refs] [--path <dir>] и slash-команда /symbols делают практичный поиск определений по исходникам проекта. Это особенно полезно перед правками и рефакторингом, когда нужно быстро найти функцию, класс, тип или константу и понять, в каком файле она живёт.
Важно понимать ограничение этого режима. Symbols это проектный инструмент для CLI, а не полный IDE-движок. Он хорошо подходит для поиска вероятных определений и мест использования, но не обещает идеальное семантическое разрешение во всех языках и всех сложных сценариях. Если ищете слишком общий символ, сужайте область через --path и, при необходимости, добавляйте --refs.
- Начинайте с точного имени символа, а не с половины большой фразы.
- Для монорепы и крупных проектов сужайте поиск через --path.
- Используйте --refs, когда нужно не только определение, но и фактические места использования.
Как работает verify и почему это лучше ручного угадывания
Команда istok-code verify [verify|test|lint|build] и slash-команда /verify делают одно важное дело: запускают проверки проекта из того контекста, который CLI уже нашёл. Это позволяет не вспоминать вручную нужные package scripts или build-команды для каждого репозитория.
Режим verify пытается использовать проектовые команды, а не выдумывать общесистемные варианты. Если в проекте есть lint, test и build, общий verify прогоняет их по очереди и останавливается на первом падении. Если корень проекта не найден или проверок нет, CLI честно сообщает об этом, а не притворяется, что проверка прошла.
Проверьте /project
Убедитесь, что CLI вообще видит корень проекта и хотя бы один тип проверки.
Запустите /verify или istok-code verify
Для полного цикла используйте общий verify, для точечного случая запускайте test, lint или build отдельно.
Читайте первое падение, а не весь шум подряд
Verify специально останавливается на первом проблемном месте, чтобы следующий шаг был точным.
Как связаны auto_verify_after_edits и /fix
В локальной конфигурации есть ключ auto_verify_after_edits со значениями off, suggest и on. По умолчанию используется suggest. Это означает, что после реальных правок CLI предлагает запустить verify, но не делает это насильно. Режим on автоматически стартует проверку после завершения хода с изменениями файлов.
Если verify упал, следующий полезный шаг это /fix. Команда работает не как абстрактная просьба "попробуй ещё раз", а как передача агенту контекста последнего упавшего verify: какой командой упало и какой хвост ошибки был получен. Поэтому /fix особенно полезен сразу после конкретного падения, а не через много сообщений спустя.