Sigue el ejemplo de Twitter
Esta guía sigue el error tras eliminar una publicación en el ejemplo de Twitter de Panolayer. Leerás la incidencia, seguirás su explicación hasta el código y entenderás el resumen de verificación antes de decidir si fusionar.
Para seguirla, abre Twitter Clone en Prueba una aplicación de ejemplo. Se abre como twitter-starter. Para consultar la configuración completa y el tutorial de corrección, ve a Corrige tu primer error con Panolayer. Las capturas de pantalla muestran una ejecución registrada; el orden y los recuentos de tus incidencias pueden variar.
Empieza en Incidencias
Cuando abres un código base, el motor de verificación de Panolayer empieza a ejecutarse. Analiza el código base hasta el nivel de funciones, símbolos y dependencias, construye la arquitectura visual y revisa el código para identificar errores.
Abre Incidencias. En este ejemplo, la ejecución ha finalizado y el estado indica Verificación completada. Las incidencias que requieren investigación aparecen en Requiere atención.
Verificación completada describe la ejecución. Significa que la ejecución ha finalizado; lee los resultados para ver si ha encontrado fallos.
Lee la incidencia de eliminación
El primer problema del ejemplo indica que una condición puede impedir una eliminación confirmada:
La guarda adicional
canDeletepuede impedir la eliminación a pesar de la confirmación del usuario, en contra del comportamiento declarado de eliminación de la publicación actual.
Una regla es una expectativa sobre el comportamiento de una función: qué debe devolver, qué acción debe realizar o qué espera de ella otro código. Aquí, la expectativa se refiere a eliminar la publicación actual después de que el usuario confirme.
Consulta en conjunto el archivo, la función, el estado y la explicación del problema:
| Lo que ves | Lo que te indica |
|---|---|
components/Post.tsx | El archivo que contiene la función que se va a investigar. |
handleDelete() | La función cuyo comportamiento se comprobó. |
| Fallido | El comportamiento comprobado no cumplía la regla. |
| Gravedad 3 · Funcionalidad | La gravedad y la categoría del problema te ayudan a priorizar la investigación. |
| Detalles | La explicación y la ubicación en el código fuente te ayudan a entender por qué se notificó el problema. |
Haz clic en Detalles. La explicación indica que la función puede retornar antes de tiempo cuando canDelete es false, antes de completar la eliminación descrita por la regla. La referencia al código fuente apunta al código correspondiente.
Comprueba que la regla coincide con el comportamiento previsto antes de decidir qué cambiar. Si la expectativa es incorrecta, corrige la regla. Si el código es incorrecto, corrige el código. Un cambio también puede afectar a los llamadores de otros archivos, así que sigue los llamadores afectados que se muestran en el resultado.
¿Qué significan los estados?
Lee el estado junto con su explicación y el código al que se aplica.
| Resultado | Cómo interpretarlo |
|---|---|
| Superado | La regla evaluada se cumplió para el código comprobado. Esto describe esa regla, no todos los comportamientos posibles de la aplicación. |
| Fallido | La regla evaluada no se cumplió. Lee la explicación e inspecciona el código fuente para decidir qué hay que corregir. |
| Pendiente o en ejecución | El resultado aún no está listo. Espera a que termine la comprobación antes de sacar una conclusión. |
| No disponible | La comprobación no pudo finalizar. Lee el mensaje que la acompaña y resuelve el problema indicado antes de volver a comprobar. |
| Sin comprobar | La expectativa no se ha evaluado. No es un resultado satisfactorio. |
Si la verificación no puede finalizar, sigue el error indicado y consulta Resolver problemas de configuración y del agent.
Corrige el error y deja que la verificación se ejecute de nuevo
En la incidencia de eliminación, haz clic en Corregir y, después, selecciona Panolayer Agent. Panolayer pasa el contexto de la incidencia al agent, así que no necesitas escribir un prompt que explique el error.
Panolayer Agent está integrado. También puedes usar otro agent compatible después de instalarlo; consulta Agents compatibles.
El agent trabaja en su propio Git worktree, manteniendo sus cambios separados de tu rama. Sigue la tarea en Mis agents o haz clic en Abrir en la tarjeta de ejecución para inspeccionar su actividad y sus cambios.
A medida que cambia el código, Panolayer vuelve a comprobar las funciones afectadas y el código conectado, incluidas las llamadas desde otros archivos. Esto ayuda a detectar regresiones más allá de las líneas que editó el agent.
Una regresión es un problema nuevo introducido por el cambio. Si la verificación detecta una durante una corrección, el agent puede repararla y volver a ejecutar la verificación antes de solicitar una fusión. Por lo tanto, una tarea puede tener varias ejecuciones de verificación antes de estar lista para tu revisión.
Lee el resumen de verificación antes de fusionar
Cuando finalice esta ejecución, Panolayer muestra Panolayer Agent está listo para fusionarse. El diálogo resume lo que la verificación comprobó y reparó durante la tarea.
| Campo de resumen | Esta ejecución | Qué significa |
|---|---|---|
| Fallos reparados | 1 | El trabajo reparó un fallo que ya estaba presente antes de que comenzara la tarea. |
| Reglas superadas | 14 de 21 | Catorce de 21 reglas superadas en el código modificado. Lee esto junto con el mensaje de estado y la línea independiente de fallos preexistentes. |
| Ejecuciones de verificación | 1 | Una ejecución de verificación alcanzó un resultado durante este trabajo. Esto cuenta ejecuciones de verificación, no pruebas o reglas individuales. |
| Archivos modificados | 4 | La tarea modificó cuatro archivos. Revisa el conjunto completo de cambios, incluyendo las pruebas y los archivos de dependencias. |
El mensaje de estado dice No hay fallos nuevos, advertencias ni reglas sin comprobar. Lee ese mensaje junto con los recuentos: describe el resultado de este trabajo, mientras que la línea siguiente explica los fallos que permanecen desde antes de que comenzara.
¿Qué ocurre si aparece “Regresiones detectadas”?
Algunas ejecuciones también muestran Regresiones detectadas. Informa de problemas nuevos que la verificación detectó durante el trabajo, lo que ayuda a mantenerlos fuera de la rama de destino. Lee el último resultado para ver qué sigue necesitando atención; el recuento describe las detecciones durante el trabajo, no el número de fallos sin resolver en este momento.
Este campo no se muestra en esta captura de pantalla. El ejemplo de eliminación muestra un fallo preexistente reparado; no demuestra una regresión detectada durante la corrección.
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.