Code Guardian 17.13: está terminado lo que está probado

El agente informa «pruebas en verde», pero la ejecución de las pruebas nunca tuvo lugar. A partir de Code Guardian 17.13, una tarea así ya no se cierra. Este resumen de las versiones 17.10 a 17.13 responde a una sola pregunta: ¿cómo nota usted que el resultado es correcto?

El artículo sobre la versión anterior lo encuentra aquí: Code Guardian 17.9: novedades.

Qué debería hacer ahora

1. Solo para usuarios de Codex con valores de perfil propios: anote sus valores de agents/cg-*.toml. Una actualización los restablece.
2. Instale la actualización con bash install.sh. Los nuevos avisos surten efecto de inmediato.
3. Usuarios de Codex: vuelva a introducir después sus valores.
4. Cree su próxima tarea con aufgabe.py neu; aufgabe.py es la herramienta para las carpetas de tareas. La nueva carpeta lleva automáticamente «Graph: ja».

¿Cuándo se considera terminada una tarea en Code Guardian?

Desde la versión 17.13, cada carpeta de tareas nueva lleva un grafo de trabajo con seis nodos. Esos seis los prueba usted; el cierre lo registra el propio Code Guardian.

Cada nodo está abierto, afirmado, probado o no procede. «Afirmado» significa: registrado como hecho, pero sin justificante comprobado. Eso no cierra nada, porque una línea escrita a mano no prueba nada.

Un nodo solo está probado con un justificante: un archivo de registro con exit=0, un commit o un «no procede» motivado. El registro y el commit deben ser más recientes que el inicio del grafo, es decir, el momento en que la carpeta recibió su grafo.

Al cerrar, Code Guardian vuelve a comprobar todos los nodos. Si falta una prueba, avisa con «NICHT FERTIG: N Graph-Knoten ohne Beleg». Una mera afirmación no cierra ninguna tarea.

Para usted esto significa: «terminado» es verificable. Un tercero ve en la carpeta qué se comprobó y con qué.

Cómo probar un nodo

1. Consultar el estado, solo lectura: aufgabe.py graph --id <id>.
2. Elegir un justificante por nodo, con aufgabe.py beleg --id <id> --knoten <knoten> y exactamente una de estas indicaciones:
   • --datei <protokoll>: la última línea no vacía debe llevar exit=0, y el archivo debe ser más reciente que el inicio del grafo.
   • --sha <sha>: el commit debe ser más reciente que el inicio del grafo y estar en una rama o etiqueta.
   • --entfaellt <grund>: sin motivo, el nodo sigue abierto.
   • Caso especial de la comprobación previa: aquí --rot <protokoll> prueba la ejecución en rojo antes del cambio, cuyo código de salida es distinto de 0.
3. Cerrar con aufgabe.py abschliessen.

Tras un git commit, el hook prueba por sí mismo el nodo edit si el commit tiene como máximo diez minutos. La ejecución de pruebas (suite) no la prueba nunca.

Si aparece NICHT FERTIG: aufgabe.py abschliessen indica, para cada nodo que falta, la llamada adecuada a aufgabe.py beleg. Ejecútela y cierre de nuevo. Tenga en cuenta: abschliessen solo lee la sección ## Erkenntnisse. Las conclusiones bajo un título propio no cuentan.

¿Se bloquea con esto mi trabajo en curso?

No. El bloqueo solo rige para las carpetas nuevas con «Graph: ja». Las carpetas existentes reciben el grafo y solo un aviso.

Hay tres avisos nuevos: [graph], [wiederaufnahme] y [abbruch]. El último informa de un subagente de comprobación interrumpido, que hasta ahora desaparecía en silencio. Ninguno de estos avisos bloquea nada.

Además, se ha corregido la falsa alarma de la valla, el límite de archivos de una tarea, en repositorios anidados.

Para usted esto significa: la obligación de prueba solo afecta a las tareas que cree de nuevo. Todo lo demás sigue funcionando como hasta ahora.

¿Cómo sé de dónde procede un hallazgo?

La revisión conoce ahora el nivel de riesgo H. Rige cuando un cambio toca la lista de bloqueo, es decir, áreas como base de datos, pagos, despliegue y secretos. También rige cuando el análisis de patrones de código relevantes para la seguridad devuelve un valor superior a 0.

Entonces los brazos de revisión, es decir, los agentes de comprobación independientes, trabajan con mayor profundidad de razonamiento (xhigh). En el bloque de cierre se enciende la luz «Risiko H». Tras tres rondas de revisión en frío entra en vigor un tope de rondas: la revisión no da vueltas sin fin.

Cada hallazgo incluye una clasificación del tipo de error junto con un patrón de búsqueda para los lugares donde el mismo error aún puede esconderse. A ello se suma el origen: propio, preexistente o indeterminado. El origen no desplaza ningún veredicto. Solo muestra si el hallazgo procede de su cambio.

Antes de cambios en una arquitectura existente, Code Guardian exige además una ficha de resumen con siete campos.

Para usted esto significa: los cambios arriesgados se comprueban con más profundidad, y usted ve de inmediato si un hallazgo es suyo.

¿Son correctas mis cifras cuando trabajo con copias de trabajo?

Sí, ese es el objetivo de estos cambios: sus hallazgos y cifras se refieren a su código y ya no a copias de él. Quien trabaja con copias de trabajo de Git bajo .claude/worktrees/ obtenía hasta ahora cifras distorsionadas.

Desde la versión 17.12, las copias de trabajo ya no se cuentan dos veces. Se han adaptado siete herramientas, a las que se suman correcciones para Windows en la búsqueda de clones y la comprobación de dependencias.

La versión 17.13 completa el trabajo: otras herramientas de comprobación, entre ellas la búsqueda de cicatrices, el inventario de planes y los análisis para PHP, Python, JS y HTML, omiten las copias de trabajo y la caché de PHPStan. Además, las herramientas ya no heredan GIT_DIR ni GIT_WORK_TREE.

Excepción: la búsqueda de secretos y la detección de textos legales siguen comprobando a propósito las copias de trabajo.

Para usted esto significa: quien trabaja bajo .claude/worktrees/ no tiene que hacer nada. Las herramientas adaptadas pasan por alto las copias por sí solas.

¿Puede Code Guardian aprender por sí mismo?

Desde la versión 17.11 existe el skill auto-self-improve. Echa la vista atrás por sí mismo después del trabajo hecho. Está desactivado por defecto, registra todo antes de cada cambio y no toca ningún cerrojo de protección. Desde la versión 17.12 espera mientras haya una consulta abierta dirigida a usted.

Para activarlo: en ~/.claude/code-guardian.conf, establezca la línea auto_self_improve = true. El valor por defecto es false.

También desde la versión 17.11: el skill autorun para trabajar de forma desatendida y un aviso en caso de bucles, que hace visible un paso que fracasa una y otra vez. Ninguno de los dos activa un cerrojo de protección, y el aviso no bloquea nada.

Para usted esto significa: usted decide si la revisión retrospectiva se ejecuta por sí sola. Sin su ajuste, todo queda como antes.

¿Por qué me detiene un cerrojo, y por qué con menos frecuencia?

Los cerrojos son los bloqueos de protección ante comandos arriesgados. Una parada debe tener un motivo; un comando inofensivo, ninguno.

Desde la versión 17.10, los cerrojos de migración y despliegue reconocen una llamada remota incluso cuando ssh no aparece literalmente en el comando, sino que viene de una variable. Hasta ahora, una migración o un despliegue en una máquina ajena pasaba entonces sin detenerse. El cerrojo de borrado reconoce el borrado remoto mediante una variable ssh, también detrás de timeout.

Al mismo tiempo hay menos falsas alarmas:

• Se permite un grep de lectura sobre un script de despliegue (17.11).
• Un nombre de despliegue dentro de un literal ya no cuenta como despliegue (17.11).
• Una carga útil de ssh completamente entrecomillada que solo borra un archivo desechable creado por usted mismo ya no salta (17.10).

Los textos de rechazo del cerrojo de borrado son más claros. El cerrojo ahora pregunta cuando un número del comando no se lee con claridad (por ejemplo nan o inf), en lugar de adivinar.

Para usted esto significa: menos paradas con comandos inofensivos, más atención ante riesgos reales.

¿Qué límites siguen abiertos?

Los llamamos abiertos:

• Obligación de prueba: solo rige para las carpetas nuevas con «Graph: ja». Lo que puede hacer: cree de nuevo las tareas importantes, y entonces la obligación se aplica.
• Variable ssh: se reconoce por su grafía, y no todas las grafías están cubiertas. Lo que puede hacer: en comandos arriesgados, escriba ssh literalmente en el comando en lugar de llamarlo a través de una variable.
• Informe de autorización: los cerrojos de migración y despliegue aún aceptan un informe escrito por uno mismo. La laguna está prevista para una próxima versión. Lo que puede hacer: lea usted mismo con ojo crítico los informes de autorización.
• Windows: una ejecución terminada con normalidad ya no cuenta como interrumpida. El límite conocido: una ejecución que se interrumpe exclusivamente en el lanzador de Windows bajo Git bash deja de reconocerse como interrupción con la corrección. Lo que puede hacer: ante una interrupción así, compruebe usted mismo la salida.
• Codex: bajo Codex, el nivel de riesgo H solo se notifica y no eleva nada. Lo que puede hacer: ajuste usted mismo la profundidad de razonamiento en el perfil.

Para usted esto significa: en migración y despliegue, no confíe únicamente en un informe de autorización.

¿Qué cambia para los usuarios de Codex?

La salida de Codex recibe el grafo de trabajo con obligación de prueba y las indicaciones de origen. A ello se suman tres diferencias:

• El nivel de riesgo H solo se notifica, no eleva nada. La profundidad de razonamiento de los brazos de revisión la ajusta usted mismo en el perfil.
• Una actualización sobrescribe los perfiles de agente agents/cg-*.toml y restablece los valores propios. Para eso están pensados los pasos 1 y 3 de arriba.
• La medición de costes mostraba hasta ahora con session-cost --geld un cero silencioso en lugar de los valores. Ahora las cantidades de tokens proceden de los mensajes de Codex.

Para usted esto significa: anote los valores de su perfil antes de la actualización y vuelva a introducirlos después.

¿Qué aporta Code Guardian de forma medible?

Estado de la medición comparativa: la última ejecución válida, del 15.10.2026, mide la v17.10: de media 5,9 con frente a 5,2 sin Code Guardian. El valor es una puntuación por tarea; cuanto más alto, mejor. El valor p es 0,017 y el resultado es «probado».

Para las versiones 17.11 a 17.13 aún no hay una medición propia. En total hay 10 comparaciones válidas.

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

Preguntas frecuentes sobre Code Guardian 17.13

¿Qué hago ante NICHT FERTIG?

Ejecute la llamada que aufgabe.py abschliessen indica para cada nodo que falta. Después, cierre de nuevo.

¿Cómo activo la revisión retrospectiva automática?

En ~/.claude/code-guardian.conf, establezca la línea auto_self_improve = true. No toca ningún cerrojo de protección y no modifica nada irreversible.

¿Qué ocurre tras tres rondas de revisión en frío?

La luz muestra «Rundendeckel 3 Runden — Ansatz überdenken». Replantee entonces el enfoque en lugar de dar una cuarta vuelta.

¿Debo tener algo en cuenta como usuario de Codex?

Sí: los pasos 1 y 3 de arriba y la profundidad de razonamiento de los brazos de revisión en el perfil.

Nota sobre la versión 17.11

En la nota sobre la versión 17.11, dos datos eran imprecisos: los tres agentes de revisión no eran nuevos, y la ficha de resumen tiene siete campos.

Fuentes

• Registro de cambios de Code Guardian 17.10–17.13 (paquete Claude y paquete Codex), en el portal de clientes
• Medición comparativa del fabricante, ejecución del 15.10.2026

Fecha: 26.10.2026