В цитате, опубликованной Simon Willison и приписанной Geoffrey Huntley, описан способ проверять изменения агента до commit: искать в diff прямые вызовы модулей наблюдаемости в обход внутренней библиотеки диагностики. Это пример подхода, а не проверенная здесь реализация.
Идея: проверять diff
По словам Huntley в цитате, его pre-commit hook проверяет git diff на такие вызовы; при обнаружении обхода он останавливает commit и добавляет агенту подсказку использовать библиотеку диагностики. Оригинальная публикация Simon Willison с цитатой Geoffrey Huntley.
Фраза «ten out of ten» — субъективная оценка внутри цитаты, а не измеренный результат. В публикации нет кода hook, списка модулей, правил поиска по diff или независимой проверки эффективности. Поэтому ниже — шаблон для проектирования проверки, а не готовый исполняемый hook.
Шаблон для адаптации к репозиторию
Сначала определите названия или пути к модулям наблюдаемости, разрешённый интерфейс библиотеки диагностики, проверяемые языки и файлы, механизм запуска hook и допустимые исключения. Возьмите эти значения из кода и правил своего репозитория, не подставляйте их наугад.
Переменные: [OBSERVABILITY_MODULES] — прямые точки входа, которые требуется обнаруживать; [DIAGNOSTICS_API] — рекомендуемая библиотека или интерфейс; [FILE_SCOPE] — проверяемые файлы; [EXCEPTIONS] — подтверждённые исключения; [HOOK_RUNNER] — используемый механизм pre-commit.
Спроектируй проверку pre-commit для этого репозитория.
Входные данные:
- Модули наблюдаемости: [OBSERVABILITY_MODULES]
- Разрешённая библиотека диагностики: [DIAGNOSTICS_API]
- Область проверки: [FILE_SCOPE]
- Исключения: [EXCEPTIONS]
- Механизм запуска hook: [HOOK_RUNNER]
Требования:
1. Проверяй только изменения, попавшие в staged diff.
2. Опиши, как находить прямые вызовы перечисленных модулей в обход разрешённого интерфейса.
3. При нарушении предложи завершать проверку с ненулевым кодом и сообщать файл, строку или фрагмент, если их можно надёжно определить.
4. Выводи краткую подсказку: используй [DIAGNOSTICS_API] либо проверь документированное исключение.
5. Не изменяй файлы автоматически и не добавляй исключения без подтверждения.
6. Покажи проект решения, предположения и случаи, которые простой поиск по diff может пропустить.
7. Не утверждай, что проверка работает, пока её не реализовали и не запустили на согласованных примерах.Иллюстрация ожидаемого поведения, не выполненный тест. Если diff содержит импорт элемента из [OBSERVABILITY_MODULES] и прямой вызов API в обход [DIAGNOSTICS_API], правило может остановить commit и подсказать перейти на разрешённый интерфейс. Это не результат запуска на конкретном репозитории.
Что проверить перед внедрением
- Определите, что считать обходом: импорт, вызов функции, создание клиента или другой паттерн. Слишком общий поиск может давать ложные срабатывания, а узкий — пропускать другие формы вызова.
- Проверьте обработку staged diff, переименований, нескольких языков и исключений: hook должен анализировать именно те изменения, которые будут зафиксированы.
- Сформулируйте сообщение об ошибке так, чтобы оно объясняло, что исправить, а не только блокировало commit.
- Проверьте правила на искусственных положительных и отрицательных примерах в безопасном окружении и вручную разберите неоднозначные случаи. Само наличие hook не доказывает его полноту или эффективность.
- Документация объясняет предпочтительный путь, а автоматическая проверка может остановить изменение, соответствующее заданному правилу. Ни один из этих механизмов сам по себе не подтверждает, что правило охватывает все варианты.
