Segui l'esempio Twitter
Questa guida segue il bug di eliminazione dei post nell'esempio Twitter di Panolayer. Leggerai il problema, seguirai la sua spiegazione fino al codice e comprenderai il riepilogo di verifica prima di decidere se eseguire il merge.
Per seguire, apri Twitter Clone in Prova un'app di esempio. Si apre come twitter-starter. Per la configurazione completa e la procedura di correzione, vedi Correggi il tuo primo bug con Panolayer. Gli screenshot mostrano un'esecuzione registrata; l'ordine e i conteggi dei problemi possono variare.
Inizia da Problemi
Quando apri una codebase, il motore di verifica di Panolayer inizia l'esecuzione. Analizza la codebase fino a funzioni, simboli e dipendenze, costruisce l'architettura visiva e controlla il codice per identificare bug.
Apri Problemi. In questo esempio, l'esecuzione è terminata e lo stato indica Verifica completata. I problemi che richiedono indagine compaiono sotto Richiede attenzione.
Verifica completata descrive l'esecuzione. Significa che l'esecuzione è terminata; leggi i risultati per vedere se sono stati trovati errori.
Leggi la segnalazione di eliminazione
La prima segnalazione dell'esempio riporta che una condizione può bloccare un'eliminazione confermata:
Il controllo aggiuntivo
canDeletepuò impedire l'eliminazione nonostante la conferma dell'utente, in contrasto con il comportamento dichiarato di eliminazione del post corrente.
Una regola è un'aspettativa sul comportamento di una funzione: cosa deve restituire, quale azione deve eseguire o cosa altro codice si aspetta da essa. Qui l'aspettativa riguarda l'eliminazione del post corrente dopo la conferma dell'utente.
Leggi insieme file, funzione, stato e spiegazione della segnalazione:
| Cosa vedi | Cosa ti dice |
|---|---|
components/Post.tsx | Il file che contiene la funzione da esaminare. |
handleDelete() | La funzione di cui è stato verificato il comportamento. |
| Non superato | Il comportamento verificato non soddisfa la regola. |
| Gravità 3 · Funzionalità | La gravità e la categoria della segnalazione aiutano a dare priorità all'indagine. |
| Dettagli | La spiegazione e la posizione nel codice aiutano a capire perché è stata segnalata. |
Fai clic su Dettagli. La spiegazione indica che la funzione può uscire in anticipo quando canDelete è false, prima di completare l'eliminazione descritta dalla regola. Il riferimento al codice punta al codice interessato.
Controlla che la regola corrisponda al comportamento previsto prima di decidere cosa modificare. Se l'aspettativa è errata, correggi la regola. Se il codice è errato, correggi il codice. Una modifica può anche influire sui chiamanti in altri file, quindi segui i chiamanti interessati mostrati nel risultato.
Cosa significano gli stati?
Leggi lo stato insieme alla sua spiegazione e al codice a cui si applica.
| Risultato | Come leggerlo |
|---|---|
| Superato | La regola valutata ha avuto esito positivo per il codice verificato. Descrive quella regola, non ogni possibile comportamento dell'applicazione. |
| Non superato | La regola valutata non è stata rispettata. Leggi la spiegazione ed esamina il codice sorgente per decidere cosa correggere. |
| In attesa o in esecuzione | Il risultato non è pronto. Attendi il completamento della verifica prima di trarre conclusioni. |
| Non disponibile | La verifica non è riuscita a completarsi. Leggi il messaggio associato e risolvi il problema segnalato prima di verificare di nuovo. |
| Non verificato | L'aspettativa non è stata valutata. Non è un risultato positivo. |
Se la verifica non può essere completata, segui l'errore segnalato e consulta Risolvi problemi di configurazione e dell'agent.
Correggi il bug e lascia che la verifica venga eseguita di nuovo
Per il problema di eliminazione, fai clic su Fix, quindi seleziona Panolayer Agent. Panolayer passa il contesto del problema all’agent, quindi non serve scrivere un prompt che spieghi il bug.
Panolayer Agent è integrato. Puoi anche usare un altro agent supportato dopo averlo installato; vedi Agent supportati.
L’agent lavora in un proprio Git worktree, mantenendo le sue modifiche separate dal tuo branch. Segui il task in My Agents oppure fai clic su Open nella scheda dell’esecuzione per controllarne l’attività e le modifiche.
Man mano che il codice cambia, Panolayer controlla di nuovo le funzioni interessate e il codice collegato, compresi i chiamanti in altri file. Questo aiuta a individuare regressioni anche oltre le righe modificate dall’agent.
Una regressione è un nuovo problema introdotto dalla modifica. Se la verifica ne rileva una durante una correzione, l’agent può correggerla ed eseguire di nuovo la verifica prima di richiedere un merge. Un task può quindi avere diverse esecuzioni di verifica prima di essere pronto per la tua revisione.
Leggi il riepilogo della verifica prima del merge
Al termine di questa esecuzione, Panolayer mostra Panolayer Agent è pronto per il merge. La finestra di dialogo riepiloga ciò che la verifica ha controllato e riparato durante l'attività.
| Campo di riepilogo | Questa esecuzione | Cosa significa |
|---|---|---|
| Errori riparati | 1 | Il lavoro ha riparato un errore già presente prima dell'inizio dell'attività. |
| Regole superate | 14 su 21 | Quattordici regole superate su 21 sul codice modificato. Leggi questo insieme al messaggio di integrità e alla riga separata degli errori preesistenti. |
| Esecuzioni di verifica | 1 | Un'esecuzione di verifica ha raggiunto un risultato durante questo lavoro. Conta le esecuzioni di verifica, non i singoli test o regole. |
| File modificati | 4 | L'attività ha modificato quattro file. Esamina l'intero set di modifiche, inclusi eventuali test e file delle dipendenze. |
Il messaggio di integrità dice Nessun nuovo errore, avviso o regola non controllata. Leggi quel messaggio insieme ai conteggi: descrive il risultato di questo lavoro, mentre la riga successiva spiega gli errori rimasti da prima che iniziasse.
Cosa succede se appare “Regressioni rilevate”?
Alcune esecuzioni mostrano anche Regressioni rilevate. Segnala nuovi problemi rilevati dalla verifica durante il lavoro, contribuendo a tenerli fuori dal branch di destinazione. Leggi il risultato più recente per vedere cosa richiede ancora attenzione; il conteggio descrive le rilevazioni durante il lavoro, non il numero di errori ancora irrisolti.
Questo campo non è mostrato in questa schermata. L'esempio di eliminazione mostra un errore preesistente riparato; non dimostra una regressione rilevata durante la correzione.
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.