✅ Verificación e informe fiel

Acabas de cambiar una línea del prompt o pedir una corrección, y ella parece cierta. Detente ahí: parecer correcto no es evidencia de nada. Una edición es solo una conjetura con apariencia de solución: una hipótesis. La pregunta que importa no es «¿quedó bien?», sino «¿cómo sé que quedó bien?». Y la respuesta siempre es la misma: porque pasó una verificación real.

"An edit is a hypothesis. A passing check is the evidence."

Aquí está el error más común y más invisible: ejecutar un check que parece verificación, pero no verifica nada. Un ls que confirma que el archivo existe. Un echo que imprime "ok". Un comando cualquiera que terminó con código cero. Nada de eso demuestra que tu cambio haya funcionado. El check real es la prueba, el build, el lint o el typecheck que el proyecto realmente usa — y ejecutar la tarea de verdad, no un sustituto reconfortante.

Verificar se refiere a lo que ya ocurrió. Confirmar se refiere a lo que aún ocurrirá, y es especialmente importante cuando la acción es difícil de deshacer o tiene efectos externosEliminar, sobrescribir, publicar, enviar un correo, llamar a un servicio externo: en esos casos, lo correcto es comprobarlo antes. Un «¿puedo?» breve cuesta un segundo; un correo enviado por error cuesta una relación.

<seguranca>
Para ações difíceis de reverter ou voltadas para fora (deletar, sobrescrever,
publicar, enviar a serviço externo): confirme antes, a menos que duravelmente
autorizado ou mandado prosseguir.
Aprovação num contexto não se estende ao próximo.
Antes de deletar/sobrescrever, olhe o alvo: se o que achar contradiz como foi
descrito, ou você não o criou, levante isso em vez de prosseguir.
</seguranca>

¿Verificaste? Ahora di la verdad sobre lo que pasó. Si la prueba falló, di que falló y muestra la salida. Si te saltaste un paso, di que te lo saltaste. Si está hecho y verificado, afírmalo sin rodeos, sin «creo que», sin «probablemente». La confianza se construye con informes precisos, no con informes optimistas. La IA que presenta como listo un resultado sin verificar está erosionando lo único que la hace útil: que puedas creer lo que dice.

"Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that; when something is done and verified, state it plainly without hedging."

El error es normal: lo que separa la disciplina de la suerte es la respuesta al error. El mal reflejo es volver a ejecutar el mismo comando, exactamente igual, esperando un resultado diferente. Eso es tantear a oscuras. El buen reflejo es un ciclo corto: diagnosticar → corregir → volver a verificar. Lees el error, entiendes el estado, elaboras una corrección informada y solo entonces lo intentas de nuevo. Mira el diagrama de arriba: ese es exactamente el camino de abajo.

<recuperacao>
Quando um comando falha: não repita igual esperando resultado diferente.
Leia o erro → inspecione o arquivo/estado → forme a correção → corrija → re-verifique.
Nunca largue um turno que falhou em silêncio. Se não resolver, diga claramente, com a evidência.
</recuperacao>

La última regla, y la más sencilla de cumplir: no desaparezcas. Si una tarea se atascó y no pudiste resolverla, eso no es excusa para terminar el turno fingiendo que salió bien ni para irte sin decir nada. Di claramente qué pasó, muestra la evidencia y sé honesto sobre dónde te detuviste. Un «no pude, y fue por esto» vale infinitamente más que un silencio que te deja descubrir el daño después.