Разберём пример с Twitter
Это руководство разбирает баг с удалением поста в примере Twitter от Panolayer. Вы прочитаете описание проблемы, проследите её объяснение до кода и разберётесь в сводке верификации, прежде чем решать, сливать ли изменения.
Чтобы следить за ходом, откройте Twitter Clone в разделе Попробовать пример приложения. Он откроется как twitter-starter. Полный порядок настройки и исправления см. в разделе Исправьте свой первый баг с Panolayer. Скриншоты показывают один записанный запуск; порядок и количество проблем у вас могут отличаться.
Начните с раздела «Проблемы»
Когда вы открываете кодовую базу, запускается Panolayer verification engine. Он разбирает кодовую базу до функций, символов и зависимостей, строит визуальную архитектуру и проверяет код, чтобы выявить баги.
Откройте Проблемы. В этом примере запуск завершён, и статус — Верификация завершена. Проблемы, требующие изучения, отображаются в разделе Требует внимания.
«Верификация завершена» описывает запуск. Это значит, что запуск закончен; прочитайте результаты, чтобы узнать, найдены ли сбои.
Прочитайте проблему с удалением
Первая проблема в примере сообщает, что условие может заблокировать подтверждённое удаление:
Дополнительная проверка
canDeleteможет предотвратить удаление, несмотря на подтверждение пользователя, вопреки заявленному поведению удаления текущего поста.
Правило — это ожидание относительно поведения функции: что она должна возвращать, какое действие выполнять или что от неё ожидает другой код. Здесь ожидание касается удаления текущего поста после подтверждения пользователем.
Читайте файл, функцию, статус и объяснение проблемы вместе:
| Что вы видите | Что это значит |
|---|---|
components/Post.tsx | Файл, содержащий функцию для исследования. |
handleDelete() | Функция, поведение которой проверялось. |
| Провалено | Проверяемое поведение не соответствует правилу. |
| Критичность 3 · Функциональность | Критичность и категория проблемы помогают расставить приоритеты при исследовании. |
| Подробности | Объяснение и ссылка на исходный код помогают понять, почему проблема была зарегистрирована. |
Нажмите Подробности. В объяснении сказано, что функция может завершиться досрочно, когда canDelete равно false, не выполнив удаление, описанное в правиле. Ссылка на исходный код указывает на соответствующий код.
Прежде чем решать, что менять, убедитесь, что правило соответствует предполагаемому поведению. Если ожидание неверно, исправьте правило. Если неверен код, исправьте код. Изменение может затронуть вызывающий код в других файлах, поэтому проверьте всех затронутых вызывающих, показанных в результате.
Что означают статусы?
Читайте статус вместе с его объяснением и кодом, к которому он относится.
| Результат | Как его читать |
|---|---|
| Пройдено | Проверяемое правило выполнено для проверенного кода. Это описывает именно это правило, а не всё возможное поведение приложения. |
| Провалено | Проверяемое правило не выполнено. Прочитайте объяснение и изучите исходный код, чтобы решить, что исправлять. |
| Ожидание или выполнение | Результат ещё не готов. Дождитесь завершения проверки, прежде чем делать выводы. |
| Недоступно | Проверка не смогла завершиться. Прочитайте прилагаемое сообщение и устраните указанную проблему, прежде чем проверять снова. |
| Не проверено | Ожидание не было оценено. Это не пройденный результат. |
Если проверка не может завершиться, перейдите по указанной ошибке и см. раздел Устранение проблем с настройкой и агентом.
Исправьте баг и запустите проверку снова
В проблеме с удалением нажмите Исправить, затем выберите Panolayer Agent. Panolayer передаёт агенту контекст проблемы, поэтому писать промпт с описанием бага не нужно.
Panolayer Agent встроен. Можно также использовать другой поддерживаемый агент, установив его; см. Поддерживаемые агенты.
Агент работает в собственном Git worktree, поэтому его правки не смешиваются с вашей веткой. Следите за задачей в Мои агенты или нажмите Открыть на карточке запуска, чтобы изучить его активность и изменения.
По мере изменения кода Panolayer повторно проверяет затронутые функции и связанный код, включая вызывающий код в других файлах. Это помогает выявлять регрессии за пределами строк, которые изменил агент.
Регрессия — это новая проблема, внесённая изменением. Если проверка обнаружит её во время исправления, агент может устранить её и запустить проверку снова, прежде чем запрашивать слияние. Поэтому у задачи может быть несколько запусков проверки, прежде чем она будет готова к вашему ревью.
Прочитайте сводку проверки перед слиянием
Когда этот запуск завершится, Panolayer покажет Panolayer Agent готов к слиянию. В диалоге перечислено, что было проверено и исправлено в ходе задачи.
| Поле сводки | Этот запуск | Что это значит |
|---|---|---|
| Исправлено ошибок | 1 | В ходе работы исправлена ошибка, существовавшая до начала задачи. |
| Пройдено правил | 14 из 21 | Четырнадцать правил из 21 пройдено на изменённом коде. Читайте это вместе с сообщением о состоянии и отдельной строкой о ранее существовавших ошибках. |
| Запуски проверки | 1 | Один запуск проверки дал результат в ходе этой работы. Считаются запуски проверки, а не отдельные тесты или правила. |
| Изменено файлов | 4 | Задача изменила четыре файла. Просмотрите весь набор изменений, включая тесты и файлы зависимостей. |
В сообщении о состоянии сказано: Нет новых ошибок, предупреждений или непроверенных правил. Читайте это сообщение вместе со счётчиками: оно описывает результат этой работы, а следующая строка объясняет ошибки, оставшиеся с момента до её начала.
Что если появилось «Обнаружены регрессии»?
В некоторых запусках также отображается Обнаруженные регрессии. Здесь сообщается о новых проблемах, которые проверка выявила в ходе работы, — это помогает не допустить их в целевую ветку. Прочитайте последний результат, чтобы понять, что ещё требует внимания; счётчик отражает обнаруженное в ходе работы, а не число нерешённых ошибок на данный момент.
На этом скриншоте поле не показано. В примере с удалением показана одна исправленная ранее существовавшая ошибка; он не демонстрирует регрессию, обнаруженную во время исправления.
Why can it be ready to merge when failures remain?
Panolayer compares the result with the baseline: the state of the codebase before the change. This separates problems introduced by the task from problems that were already there.
- A new failure was introduced by the change and needs investigation before you accept the work.
- A pre-existing failure was present before the task started. It can still matter, but this task did not introduce it.
- A repaired failure was present before the task and was fixed during the work.
In the screenshot, the dialog reports 7 pre-existing failures that do not block this merge. The selected deletion issue was repaired, and those other issues remain separate work.
The repository’s issue list and an agent’s verification summary can cover different scopes. The issue list shows what needs attention in the codebase; the merge summary describes the agent’s work against its baseline. An agent’s result can report no new failures while the repository still has pre-existing issues.
You can assign a pre-existing issue as another task using Fix. That gives the agent a specific issue to work on next.
Ready to merge does not mean every issue in the repository is resolved. Read what this task repaired, what it introduced, and what was already there.
Decide what reaches your branch
You control the merge. Before accepting the result:
- Check that the repaired issue matches the bug you asked the agent to fix.
- Read the verification summary, including any new failures, warnings, or checks that could not finish.
- Open Details for more context and inspect the agent’s changed files. Review the relevant tests and run the application when the behavior needs a runtime check.
- Confirm the target branch. Choose Merge into main when you’re satisfied, or Not now to keep reviewing.
Verification gives you evidence for the decision. Read it alongside the code and relevant tests; it does not cover every possible bug.