Code Guardian 17.17: «terminado» ahora significa: objetivo medido

Con la 17.17, una tarea puede llevar una prueba central: una prueba que mide el propio objetivo. Una tarea así solo se da por terminada cuando la prueba central se mide en verde. Tras cada ajuste, el agente se detiene y pregunta si va a venir algo más. Los cambios pequeños reciben una revisión más reducida. En cambio, un fallo de la 17.16 no está corregido, y este artículo explica qué significa eso para usted.

El artículo sobre las versiones anteriores se encuentra en Code Guardian 17.14 a 17.16: novedades.

Qué debería hacer ahora

1. Ejecute el instalador. Las definiciones de agentes modificadas localmente las respalda antes de sustituirlas y se lo comunica.
2. Compruebe si jq está instalado. Sin jq no todos los cerrojos comprueban (véase más abajo).
3. Si en su caso se ejecuta el servicio Leitstand (Claude Code), reinícielo una vez y recargue las pestañas de Leitstand abiertas. Hasta entonces, la página y el servicio no encajan.
4. Cree la próxima tarea con una prueba central.
5. Revise usted mismo los comandos de borrado, despliegue y migración dentro de un bloque con una redirección a continuación. Las formas figuran en la última sección.

¿Qué es una prueba central?

La prueba central es la única prueba que mide el propio objetivo de la tarea. Las nuevas carpetas de tareas pueden llevarla.

• aufgabe.py neu --kriterien-entfaellt solo funciona ya junto con --kernprobe "<text> | lauf | <kommando>".
• aufgabe.py abschliessen bloquea mientras la prueba central esté en rojo, nunca se haya medido o esté caducada.
• Si sigue en rojo y una respuesta del agente no la ha medido, el agente recibe en la siguiente entrada una línea [kern].

Un rojo que no mide nada del objetivo no cuenta. Es el caso, por ejemplo, de un programa que no se encuentra, de una ruta de pytest incorrecta o de un andamiaje de pruebas ausente. Al definirla, termina con salida 2 y una indicación. Al medir, aparece «rot (Bedienfehler)».

Además, las ejecuciones de pruebas de phpunit, pest, paratest y php artisan test ya no prueban nada si no han ejecutado ni una sola prueba. Esto vale también con salida 0. Detrás de envoltorios como composer test o bash -c, la herramienta no lo detecta.

Para usted esto significa: «terminado» quiere decir que se ha medido el propio objetivo, y no solo algo a su alrededor.

¿Por qué se detiene el agente tras cada ajuste?

Tras cada ajuste, el agente muestra qué ha cambiado y cómo se ha comprobado. Después pregunta: «¿Más ajustes o cierre?». La auditoría, la revisión en frío, la documentación y el commit se ejecutan a continuación una vez para todo el lote. Usted los inicia con su palabra.

Los cerrojos de Bash siguen activos. Hay excepciones:

• En el piloto automático, con «sin preguntas» y sin terminal, el cierre se ejecuta como hasta ahora, por cada cambio.
• Las correcciones de errores en el flujo DEBUG se ejecutan como hasta ahora, de principio a fin.
• Los workers que dirige un orquestador no se detienen.

Para usted esto significa: usted reúne varios ajustes, y la auditoría y la revisión se ejecutan una vez para todos.

¿Cuándo se ejecuta qué revisión?

La herramienta pruef-bedarf.py indica, para cada paso de revisión y con su motivo, si es necesario. Lo delicado conserva ambas revisiones, incluso como cambio de una sola línea. La lista de bloqueo abarca áreas delicadas como el inicio de sesión, el pago, el esquema de la base de datos, el despliegue, las dependencias y los secretos.

Nada de esto bloquea. aufgabe.py abschliessen muestra la necesidad y cuenta cada semana cuántas veces se ejecutó una revisión por debajo del umbral. El árbitro es el decimoquinto agente de revisión; en la 17.16 eran 14.

Para usted esto significa: los cambios pequeños sin área delicada ya no reciben una revisión grande. Los cambios delicados no se alivian.

¿Me detiene ahora un cerrojo con más frecuencia?

En dos puntos, sí.

• Un comando que empieza con una variable, por ejemplo $X rm -rf …, se examina como si la variable no estuviera. Si el valor es desconocido delante de argumentos de borrado, el cerrojo pregunta.
• Una copia por ssh desde el directorio personal del servidor a un destino fuera de él, por ejemplo un directorio web, cuenta como despliegue.

Esto se midió sobre un conjunto de comandos reales. Ningún comando que antes estuviera bloqueado pasa ahora.

Para usted esto significa: más preguntas en estas dos formas, pero ninguna nueva permeabilidad.

¿Qué más hay de nuevo?

• Vínculo con el objetivo: la herramienta todo_ziel.py asigna los puntos abiertos a los objetivos de .goals/index.json. La lista de tareas muestra los puntos sin objetivo, y el inicio de sesión menciona el objetivo.
• Leitstand: la nueva pestaña «Git» muestra por proyecto las ramas y los worktrees, qué sesión trabaja en qué y qué aún no está en main. Solo lee, no necesita red y no modifica nada.
• CodeGuardMaster: muestra un aviso en el equipo cuando una pregunta dirigida a usted lleva abierta demasiado tiempo o una prueba central lleva mucho en rojo. En macOS usa osascript, en Linux notify-send y, si no, solo el archivo meldungen.md.
• Detector de migraciones: informa de dropForeign, dropUnique y dropPrimary como [constraint]. Con un down() vacío se añade [irreversible], salida 1.
• design-beweis: mide páginas protegidas mediante Basic-Auth con CG_DESIGN_HTTP_USER y CG_DESIGN_HTTP_PASS, solo hacia la propia dirección. Una sesión de la aplicación se pasa con --sitzung.
• session-orchestrator: cada sesión puede llevar un rol formulado libremente (rolle setzen selbst "<text>", como máximo cinco líneas). Sobrevive a la compactación. Tras /clear suele desaparecer.

El paquete de Claude cuenta ahora con 5 modos, 7 gates, 15 hooks, 22 detectores, 31 skills, 15 agentes de revisión y 82 herramientas.

¿Qué correcciones incluye?

Son correcciones y no nuevas capacidades:

• El DECISION GATE vuelve a mostrar el cuadro de diálogo de la pregunta después de que se hayan sustituido comillas. Hasta ahora, la pregunta se transmitía sin diálogo.
• El detector de migraciones informaba hasta ahora de las migraciones de Alembic, en silencio, como «nada encontrado». Ahora aparecen como UNSEEN y ponen la ejecución en rojo. Su contenido todavía no se evalúa.
• Si faltaba jq, el instalador decía hasta ahora que no se comprobaba nada en absoluto. Eso no era cierto. Ahora la advertencia indica qué rige: los cuatro cerrojos de comandos para borrado, despliegue, migración y secreto en un commit siguen bloqueando. Los demás no comprueban en absoluto sin jq, entre ellos el cerrojo de escritura para ejecuciones sin supervisión. El mensaje menciona 11 de 15.
• El detector de pruebas de JS ahora muta de verdad los archivos con caracteres especiales en el nombre, por ejemplo pages/[id].vue. Antes, la ejecución sin mutación se daba por superada.
• Los detectores de pruebas de JS y PHP terminan una ejecución de mutación sin informe legible con salida 2 («Mutation nicht gemessen») en lugar de con salida 0.
• En el modo automático de Claude Code, el piloto automático no queda activado. La documentación ahora lo dice.

¿Qué cambia para los usuarios de Codex?

La edición de Codex recibe la prueba central, el punto de parada, los cerrojos más estrictos y las correcciones de los detectores. También allí están design-beweis (no remedido específicamente en Codex), PATHEXT y el aviso legal austriaco. Diferencias con Claude Code:

• No hay árbitro. Para la lógica, allí rige el límite de 100 líneas.
• El revisor de planes se omite en planes pequeños: como máximo dos consumidores, un punto de entrada, sin lista de bloqueo.
• El punto de parada se omite «en una ejecución sin terminal con las autorizaciones desactivadas».
• El session-orchestrator, y con él los roles por sesión, no existe en el paquete de Codex.
• La pestaña «Git» de Leitstand, CodeGuardMaster, la línea [kern], la indicación del objetivo al iniciar la sesión, la advertencia de jq, la nota sobre el modo automático y la corrección del DECISION GATE pertenecen solo a la edición de Claude.
• El saludo de Codex menciona 81 herramientas.

¿Qué límites siguen abiertos?

Estos son los límites abiertos más importantes. Otros figuran en el changelog del portal de clientes.

• Comandos en un bloque con una redirección a continuación: el artículo de la 17.16 anunciaba que este fallo se corregiría en la versión siguiente. Eso no ha ocurrido en la 17.17. Comprobado: los cerrojos de borrado, despliegue y migración se comportan ahí como en la 17.16. Siguen sin reconocer estos comandos en todas sus formas. No hay una nueva fecha. En comandos de esta forma no se fíe de los cerrojos, sino revíselos usted mismo antes de autorizarlos. Las formas a las que nos referimos son estas:

  { befehl; } < eingabe
  ( befehl ) < eingabe
  while read zeile; do befehl; done < eingabe
  if bedingung; then befehl; fi < eingabe

• Piloto automático y punto de parada: si el piloto automático está activo, la indicación no oculta por sí sola el punto de parada. La excepción figura solo en el texto de la indicación.
• CodeGuardMaster: si una ejecución se cuelga, el servicio no inicia una segunda en macOS. El bloqueo no se avisa por sí solo.

Para usted esto significa: la aceptación está más ligada al objetivo, y la revisión sigue el tamaño del cambio. Un fallo en los cerrojos sigue abierto, y usted lo revisa por su cuenta.

Encontrará más información sobre el producto en la página del producto.

Fuentes

• Changelog de Code Guardian 17.17 (paquete de Claude y paquete de Codex), en el portal de clientes

Fecha: 10.11.2026