¿Qué hace Bug Receipt?
Salida obligatoria de cierre
Para cada decisión de cierre de error o incidencia, devuelve el recibo completo a continuación como el resultado completo visible para el usuario, incluso cuando el usuario solicite una respuesta concisa o no nombre este formato. La concisión acorta los valores de los campos; nunca elimina ni renombra una fila. No reemplaces el recibo con prosa.
BUG RECEIPT · VERIFIED | PARTIAL | BLOCKED
Problem <defecto observado y comportamiento esperado>
Baseline <interacción o comando fallido y resultado decisivo; o not run>
Root cause <mecanismo probado; o unproven hypothesis>
Change <cambio responsable; o none>
Proof <verificación suministrada o ejecutada: resultado; incluye cada capa decisiva>
Gaps <none; o prueba faltante exacta y único experimento/paquete siguiente>
Source executed now | supplied | mixed
Usa not run, unproven o none explícitamente. Nunca omitas una fila para que el recibo parezca completo.
Establece el límite de evidencia
Antes de editar, registra el problema observado, el comportamiento esperado, la verificación directa más sólida y la fuente de evidencia: executed now, supplied o mixed. Nunca impliques que la evidencia proporcionada fue ejecutada en la ejecución actual.
Mantén la evidencia con mínima privacidad. Redacta credenciales, tokens, cookies, datos personales, URL privadas y cargas útiles sensibles; conserva solo los identificadores y extractos necesarios para reproducir o correlacionar la falla.
Reproduce la falla con la verificación segura más reducida cuando sea posible. Si la reproducción no está disponible, conserva la evidencia obtenida y limita el resultado a PARTIAL o BLOCKED.
Traza y repara
- Sigue la ruta del propietario en vivo desde la entrada hasta el síntoma.
- Separa los hechos observados, las inferencias acotadas y las brechas.
- Exige una ubicación concreta o una transición en tiempo de ejecución antes de nombrar la causa raíz.
- Realiza el cambio responsable más pequeño; evita limpieza no relacionada, reintentos, reemplazos silenciosos y excepciones específicas de fixtures.
No conviertas un parche plausible, un registro obsoleto, una lectura de fuente o una compilación exitosa en prueba del comportamiento visible para el usuario.
Cierra el bucle de prueba
Ejecuta solo las verificaciones requeridas por el contrato afectado:
- reproducción original o verificación de aceptación directa;
- verificación negativa o de regresión más cercana;
- compilación afectada o puerta de integración;
- ruta real de UI, API, persistencia, concurrencia o tiempo de ejecución cuando la afirmación cruza ese límite.
Usa estos límites decisivos:
| Superficie | Prueba directa requerida |
|---|---|
| Lógica o prueba fallida | La entrada fallida original o la prueba enfocada ahora pasan |
| Comportamiento de UI | Interacción real más observación relevante de consola y red |
| API o integración | Solicitud, respuesta y comportamiento del servicio responsable |
| Persistencia | Viaje completo de ida y vuelta de escritura/lectura o recarga a través de la ruta del propietario real |
| Condición de carrera o ciclo de vida | Disparador concurrente repetido; éxito cero o uno; evidencia de filas afectadas y transacciones; invariante final |
| Bloqueador entre sistemas | Una solicitud/respuesta fallida sanitizada con marca de tiempo o ID de solicitud, registros de borde y aplicación, y registros del proveedor de identidad cuando el rastro llega a ese propietario |
Asignar estado
VERIFIED: línea base observada, causa concreta, cambio responsable, todas las verificaciones declaradas pasadas, sin brecha material.PARTIAL: existe evidencia útil, pero falta una capa de prueba requerida o no es concluyente.BLOCKED: una condición externa específica impide la reproducción, reparación o prueba.
Para PARTIAL o BLOCKED, nombra el único experimento mínimo o paquete de evidencia correlacionada que cierra la brecha decisiva. Nunca inventes un comando, observación, conteo, ubicación o resultado.
Para un recibo legible por máquina o integración con CI, lee references/receipt-contract.md y adhiérete a sus campos JSON, marcador de fuente de evidencia, regla de compatibilidad e invariantes de estado.
Cuando se solicite un artefacto JSON, comienza desde assets/receipt.template.json, escríbelo en una ruta propiedad de la tarea y valídalo con node scripts/validate-receipt.mjs <receipt.json> desde este directorio del skill. No confirmes el recibo generado a menos que el usuario lo solicite.