Understand a verification result

Следвайте примера с Twitter

Това ръководство проследява бъга след изтриване на публикация в примера с Twitter на Panolayer. Ще прочетете проблема, ще проследите обяснението му обратно до кода и ще разберете обобщението на верификацията, преди да решите дали да слеете.

За да следвате, отворете Twitter Clone в Изпробвайте примерно приложение. Отваря се като twitter-starter. За пълното ръководство за настройка и поправка вижте Поправете първия си бъг с Panolayer. Екранните снимки показват едно записано изпълнение; редът и броят на вашите проблеми може да се различават.

Започнете с Проблеми

Когато отворите кодова база, Panolayer verification engine започва да работи. Той анализира кодовата база до функциите, символите и зависимостите ѝ, изгражда визуалната архитектура и проверява кода, за да открие грешки.

Отворете Проблеми. В този пример изпълнението е приключило и статусът е Проверката е завършена. Проблемите, които се нуждаят от разследване, се показват под Изискват внимание.

„Проверката е завършена“ описва изпълнението. Това означава, че изпълнението е приключило; прочетете резултатите, за да видите дали са открити неуспехи.

Прочетете проблема с изтриването

Първият проблем в примера съобщава, че дадено условие може да спре потвърдено изтриване:

Допълнителната предпазна проверка canDelete може да предотврати изтриването въпреки потвърждението от потребителя, в противоречие с описаното поведение при изтриване на текущата публикация.

Правило е очакване относно поведението на функция: какво трябва да върне, какво действие трябва да извърши или какво друг код очаква от нея. Тук очакването е свързано с изтриването на текущата публикация, след като потребителят потвърди.

Прочетете файла, функцията, статуса и обяснението на проблема заедно:

Кликнете върху Подробности. Обяснението казва, че функцията може да върне резултат преждевременно, когато canDelete е false, преди да завърши изтриването, описано от правилото. Препратката към изходния код сочи към съответния код.

Проверете дали правилото съответства на желаното поведение, преди да решите какво да промените. Ако очакването е грешно, коригирайте правилото. Ако кодът е грешен, поправете кода. Промяната може да засегне и извикващите функции в други файлове, затова проследете засегнатите извикващи функции, показани в резултата.

Какво означават статусите?

Четете статуса заедно с обяснението му и кода, към който се отнася.

Ако проверката не може да завърши, следвайте отчетената грешка и вижте Отстраняване на проблеми с настройката и агента.

Поправете грешката и оставете проверката да се изпълни отново

При проблема с изтриването щракнете върху Поправи, след което изберете Panolayer Agent. Panolayer предава контекста на проблема на агента, така че не е нужно да пишете промпт, който обяснява грешката.

Panolayer Agent е вграден. Можете също да използвате друг поддържан агент, след като го инсталирате; вижте Поддържани агенти.

Агентът работи в собствен Git worktree, като държи редакциите си отделно от вашия клон. Следете задачата в Моите агенти или щракнете върху Отвори на картата на изпълнението, за да прегледате активността и промените му.

Когато кодът се променя, Panolayer проверява отново засегнатите функции и свързания код, включително извикващите ги в други файлове. Това помага да се уловят регресии извън редовете, редактирани от агента.

Регресия е нов проблем, въведен от промяната. Ако проверката улови такава по време на поправка, агентът може да я отстрани и да изпълни проверката отново, преди да поиска сливане. Затова една задача може да има няколко изпълнения на проверката, преди да е готова за вашия преглед.

Прегледайте обобщението на проверката преди сливане

Когато това изпълнение приключи, Panolayer показва Panolayer Agent е готов за сливане. Диалоговият прозорец обобщава какво е проверила и поправила проверката по време на задачата.

Съобщението за състоянието казва Няма нови неуспехи, предупреждения или непроверени правила. Разгледайте това съобщение заедно с числата: то описва резултата от тази работа, докато следващият ред обяснява неуспехите, останали отпреди нейното начало.

Ами ако се появи „Открити регресии“?

Някои изпълнения също показват Открити регресии. Това отчита нови проблеми, открити от проверката по време на работата, като помага да не попаднат в целевия клон. Прегледайте последния резултат, за да видите какво все още изисква внимание; броят показва откритите по време на работата, а не броя на неразрешените неуспехи в момента.

Това поле не се показва на тази екранна снимка. Примерът с изтриването показва един поправен предварително съществуващ неуспех; той не демонстрира регресия, открита по време на поправката.

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:

1. Check that the repaired issue matches the bug you asked the agent to fix.
2. Read the verification summary, including any new failures, warnings, or checks that could not finish.
3. 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.
4. 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.