Наблюдаемая отладка и тестирование

Проверено: 20 июля 2026 года.

Агент работает качественно, когда может сам воспроизвести проблему, увидеть состояние системы и доказать исправление. Наблюдаемость важнее ещё одного длинного промпта.

Стандартный debugging loop

1. Зафиксировать точный симптом, вход и ожидаемый результат.
2. Воспроизвести дефект штатной командой или минимальным сценарием.
3. Собрать факты: stack trace, structured logs, query plan, network/console, состояние queue и корреляционный идентификатор.
4. Сформулировать одну проверяемую гипотезу.
5. Выполнить минимальный эксперимент, не смешивая несколько исправлений.
6. Устранить корневую причину и добавить regression-тест.
7. Доказать, что тест падал на дефекте и проходит после исправления.
8. Запустить связанные гейты и проверить отсутствие нового побочного эффекта.

После 2–3 одинаковых неудачных попыток остановиться, сохранить факты и пересмотреть гипотезу или поднять задачу на сильную модель. Не повторять команду в надежде на другой результат.

Контракт наблюдаемой dev-среды

В development/test должны быть доступны:

• логи в stdout или в документированном локальном файле;
• понятные timestamps, уровни, request/job IDs и исходная ошибка;
• health/readiness endpoints;
• просмотр SQL и EXPLAIN для проблемных запросов;
• видимое состояние очередей и failed jobs;
• перехват email, notifications, webhooks и платежных вызовов;
• локальные fakes/sandboxes для внешних API;
• browser console, network, DOM snapshot, screenshot/trace;
• артефакты упавших тестов в CI с ограниченным сроком хранения.

Секреты и персональные данные должны редактироваться в логах. Dev-инструмент не должен незаметно работать с production endpoint.

Сначала готовый инструмент

Сигнал	Предпочтительный инструмент
Ошибка web UI	Codex Browser Developer mode; существующий Playwright/Pest Browser/Dusk
Нестабильный browser-test	Trace Viewer, screenshot, console и network artifact
Laravel request/query/job	Telescope; для queue — Horizon; для тенденций — Pulse
Email/notification	Framework fake в тесте; Mailpit в интерактивном dev-flow
Реальная БД/queue/cache в тесте	Testcontainers или изолированный compose test profile
Контракт внешнего API	Pact/OpenAPI validator или существующий mock server
Слабые тесты	Mutation testing точечно на критичной логике
Security-подозрение	Threat model, воспроизведение в sandbox, затем минимальный patch

Не добавлять новый dashboard, если существующий лог и CLI уже дают надёжный ответ. Но не писать собственный browser runner, SMTP sink или container harness, когда зрелое решение закрывает задачу.

Browser Developer mode — июнь 2026

Codex может через Chrome DevTools Protocol исследовать network traffic, console, runtime errors и page state. Использовать его для воспроизведения и проверки web-дефектов end-to-end. Full CDP access включается явно и требует approval на сайте; не открывать в такой сессии лишние вкладки, credentials или production.

Если проект уже использует Playwright, сохранять trace на первом retry или при падении, а не для каждого успешного теста: постоянная трассировка дорога. См. Codex What's new и Playwright Best Practices.

Test the test

AI может написать зелёный тест, который ничего не доказывает. Для нового regression-теста проверить хотя бы одно:

• временно вернуть дефект и убедиться, что тест падает;
• изменить ожидаемое значение и увидеть контролируемое падение;
• для критичной чистой логики запустить mutation testing;
• убедиться, что mock не повторяет ошибочную реализацию production-кода.

Mutation testing применять точечно: оно ресурсоёмко. Для PHP доступны Pest mutation testing и Infection; начинать с денежных расчётов, permission rules и других дорогих инвариантов.

Laravel-инструменты

• Telescope — requests, exceptions, logs, queries, jobs, mail, notifications и исходящие HTTP-вызовы.
• Horizon — Redis queues, throughput, failures и worker-состояние.
• Pulse — performance trends, slow requests, queries, jobs и outgoing requests.
• Dusk или Pest Browser — реальные browser flows; выбирать один уже принятый стек, а не дублировать оба.

Подключать эти системы только в подходящей среде, защищать dashboards и учитывать стоимость хранения. Telescope и debug-панели не должны быть публично доступны в production.

Анализ БД и производительности

• Получать фактический SQL и параметры, не судить только по ORM-коду.
• Использовать EXPLAIN/EXPLAIN ANALYZE по правилам проекта и только на безопасных данных.
• Проверять N+1, индексы, объём строк, сортировки, блокировки и транзакции.
• До оптимизации сохранить baseline времени и плана; после — сравнить тем же сценарием.
• Нагрузочный тест не запускать против production без отдельного разрешения.

Разделение ролей

Test/log analyst на Terra может читать большой вывод и вернуть только:

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

Planner или Reviewer на Sol проверяет вывод для сложной причины. Параллельные агенты не должны одновременно менять код, пока причина не подтверждена.

Codex Security loop

Для security-задач применять замкнутый процесс: редактируемая threat model → поиск реалистичного attack path → воспроизведение в изолированном validator → минимальный patch → обычный человеческий review → повторная валидация. Это текущий подход Codex Security, а не замена SAST, dependency scanning и профильного аудита.