Code Guardian 17.16: terminado solo con prueba, y un hueco en las barreras

¿Cuándo está terminada una tarea? Desde la 17.15, las carpetas de tareas nuevas solo se cierran cuando cada criterio obligatorio está probado. El segundo motivo para leer esta actualización: las barreras para borrar, desplegar y migrar tienen un hueco, y la 17.16 ha corregido la nota al respecto. Este resumen de la 17.14 a la 17.16 explica cuándo una tarea se da por terminada, qué detectan ahora las barreras, qué hueco queda y qué debe hacer usted antes.

El artículo sobre la versión anterior está en Code Guardian 17.13: novedades.

Qué debe hacer usted ahora

1. Ejecute el instalador. Durante la actualización, informa por separado de cada archivo de una skill complementaria que haya sido modificado o ampliado localmente.
2. Compruebe que tiene instalado Python 3.9 o superior. Si falta python3, en cada edición de código aparece una línea [toolchain] con la solución.
3. Cree su próxima tarea con aufgabe.py neu. La carpeta nueva incluye criterios de aceptación.
4. Ejecute con beleg-lauf.py las pruebas que deban servir como evidencia. Así el registro queda sellado.
5. Escriba los comandos de borrado, despliegue y migración sin un bloque con redirección, o compruébelos usted mismo. Las formas concretas figuran en la sección «¿Qué límites siguen abiertos?».

¿Cuándo se cierra ahora una tarea?

Desde la 17.15, las carpetas de tareas nuevas (aufgabe.py neu) incluyen criterios de aceptación. Se congelan y se sellan antes de su primer commit propio. aufgabe.py abschliessen solo cierra cuando cada criterio obligatorio está probado.

Para usted esto significa: «Terminado» exige una prueba para cada criterio obligatorio. Una afirmación no basta.

¿Cómo se convierte un registro de pruebas en evidencia?

La nueva herramienta beleg-lauf.py sella un registro de pruebas con el estado del contenido de su árbol de trabajo. Si el árbol cambia durante la ejecución, la evidencia se considera caducada. Las pruebas omitidas (SKIP) no prueban nada. Si HEAD apunta entretanto a otro commit, por ejemplo tras un rebase, el rechazo nombra exactamente ese caso.

A esto se suman los casos de aceptación ocultos. Un criterio del tipo review · holdout solo se cumple con casos que escribe un subagente nuevo después de la congelación y que no son visibles durante la construcción. Cada caso necesita un registro sellado.

Para usted esto significa: Lance con beleg-lauf.py la ejecución de pruebas que deba servir como evidencia y no modifique nada del árbol de trabajo mientras tanto. No cuente con pruebas omitidas.

¿Qué pueden hacer las dos skills nuevas?

El paquete de Claude cuenta ahora con 31 skills, antes eran 29. Las dos nuevas solo se inician cuando usted las invoca y figuran en la lista de bloqueo de la barrera de escritura. En ejecución desatendida no se pueden sobrescribir.

goalengine

• Qué hace: Convierte una intención de objetivo en un contrato de objetivo con versiones fijas. Un contrato solo es válido tras la aprobación expresa de una versión concreta y queda congelado a partir de ese momento. Un criterio solo se considera cumplido con prueba: un commit, un registro con exit=0, una URL o una comprobación manual con nombre. Al aprobar, genera un prompt /goal listo para copiar.
• Qué no hace: Ningún hook impone el contrato.
• Dónde lo ve: El panel de control (Leitstand) tiene las nuevas pestañas «Goal Engineering» y «Todos» para cada proyecto. Sus objetivos están en la carpeta .goals/ de cada proyecto; en ~/.claude/goals/ solo figura la lista de proyectos con objetivos.

codeguard-master

• Qué hace: Vigila los proyectos de su equipo que usted le indique (sin lista, los que tienen objetivos de goalengine). A intervalos fijos recopila la situación sin usar ningún modelo.
• Qué no hace: No interviene por sospecha. Solo cuando un desencadenante fijo se activa de nuevo, un modelo sin herramientas elige unas pocas medidas, con un intervalo mínimo y un presupuesto diario. Los textos salientes proceden únicamente de plantillas fijas. Si acierta con demasiada poca frecuencia, pasa a limitarse a avisar.
• Qué cuesta: La programación periódica mediante launchd la configura usted mismo, y cada ejecución del modelo consume tokens.

Para usted esto significa: Ambas skills son opcionales. Sin que usted las invoque, no ocurre nada.

¿Qué cambia en la comprobación tras cada cambio de archivo?

Desde la 17.14 se ejecuta en un único proceso de python3, el módulo hooks/_cg_reminder.py. Antes lanzaba unos 115 procesos auxiliares. Los textos y el orden de los avisos siguen igual. No tiene que hacer nada: la comprobación se ejecuta sola tras cada edición y solo necesita python3 (véase el paso 2 más arriba).

Resultado en Windows: En el caso típico (mediana), la comprobación es entre 2,4 y 7,7 veces más rápida que antes. Solo con archivos Markdown sigue igual.

Objetivo y estado: En Windows, la comprobación no debería tardar apenas más que en Linux y macOS. Medido, esto significa: de cada 100 ejecuciones, 95 duran como máximo 1,25 veces lo que tarda el más lento de los otros dos sistemas. Para scripts de shell y Markdown, esto se cumple según la medición provisional. El estado de los demás lenguajes figura en la sección «¿Qué límites siguen abiertos?».

Otros cambios de la 17.14 que notará:

• [security-shape] solo señala formas relevantes para la seguridad en las líneas que ha escrito la edición. El aviso solo se ejecuta para PHP, Python, JavaScript, TypeScript y Vue.
• El nuevo aviso [plan-abweichung] se emite una vez por archivo y sesión cuando edita un archivo de código que no figura en ningún TRACE abierto. Nunca bloquea.
• log-inventur.py inventur localiza las fuentes de registro y marca qué archivo es AKTUELL y cuál VERALTET.

¿Me detiene ahora una barrera con más frecuencia?

Donde antes se escapaba algo, sí. Donde detenía sin razón, con menos frecuencia.

Más estricto desde la 17.15:

• Las barreras de borrado y de migración examinan un programa que entra por pipe en un intérprete como si fuera un programa después de -c.
• Un comentario de escape ya no libera nada si le sigue una línea ejecutable.
• Un informe de despliegue solo vale ya para los destinos de su línea Target:.

Las barreras detectan ahora además:

• rsync, scp y sftp hacia una dirección IPv6,
• un script de despliegue por stdin o precedido de un modificador de shell,
• un intérprete con un archivo .sql.

Dos consecuencias de este mayor rigor, el linter de SQL y env -S, figuran en la lista de límites abiertos más abajo.

Menos falsas alarmas: La mera lectura y los archivos de configuración ya no cuentan como «escrito e iniciado». Los comandos de lectura de npm y composer ya no cuentan como escritores, y palabras como «form» o «platform» ya no cuentan como comando de borrado. Tampoco provoca ya una falsa alarma un mensaje de commit con comillas escapadas.

Novedad: Si el mismo rechazo de una barrera o el mismo error de una herramienta se produce por tercera vez, Code Guardian indica una vez la salida prevista. El aviso nunca bloquea.

Además, los agentes de revisión con acceso a la shell ya no escriben en su árbol de trabajo. Las pruebas de git con escritura solo se ejecutan en un repositorio desechable.

Para usted esto significa: Más rechazos con las formas recién detectadas, menos con la mera lectura. A la tercera parada igual, Code Guardian indica la salida.

¿Qué correcciones incluye?

Son correcciones, no capacidades nuevas:

• En la actualización, el bytecode de Python ya no cuenta como archivo de una skill complementaria modificado localmente.
• aufgabe.py encuentra la carpeta de tareas también desde una copia de trabajo de git (aviso de un cliente).
• El recordatorio de auditoría ya no aparece para archivos del scratchpad ni de $TMPDIR.
• El inicio de sesión vuelve a llegar completo: ancla, número de todos y aviso de deriva vuelven a estar en el contexto.
• El indicador de cuota del panel de control muestra una medición reciente incluso cuando Claude Code solo proporciona el valor semanal.
• Code Guardian solo muestra el aviso sobre /clear tras abschliessen cuando la sesión ya no mantiene ninguna tarea abierta.

Además, novedad: Con aufgabe.py uebergabe escribe un archivo de traspaso al final de la sesión.

¿Qué cambia para los usuarios de Codex?

La edición de Codex incorpora los criterios de aceptación, beleg-lauf.py, las barreras más estrictas y la comprobación en un solo proceso. Las skills goalengine y codeguard-master no existen allí. Otras diferencias:

• Una llamada de PowerShell de solo lectura con $env: o Select-String ya no se detiene como env -S.
• Las pruebas de git con escritura de los agentes de revisión se omiten y el informe las indica como no ejecutadas.
• El instalador rechaza un CODEX_HOME relativo, también con --probe, y lo hace antes del primer acceso de escritura. Defínalo con una ruta absoluta, por ejemplo $HOME/.codex, o déjelo vacío.

¿Qué límites siguen abiertos?

Esta lista es el lugar completo para todas las reservas de este artículo.

• Comandos en un bloque con redirección detrás: La nota de la 17.15 mencionaba aquí solo una grafía poco frecuente en la barrera de migración. Era demasiado estrecho, y la 17.16 corrige los textos; el comportamiento de las barreras no ha cambiado. Las barreras de borrado, de despliegue y de migración pasan por alto los comandos de un bloque cuya entrada se redirige solo después del bloque. La misma instrucción sin bloque sí la detectan. Se trata de estas formas:

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

  Se corregirá en la siguiente versión. Hasta entonces, escriba los comandos de riesgo sin un bloque con redirección o compruebe usted mismo el borrado, el despliegue y la migración dentro de un bloque así.
• Linter de SQL: También se detiene un linter puro con un archivo .sql. La versión no indica ninguna salida.
• env -S: Con palabras adicionales provoca una consulta en el paquete de Claude y un bloqueo en Codex. Tampoco aquí indica la versión ninguna salida.
• Tiempo de ejecución en Windows: Para PHP, Python, JavaScript y CSS, el objetivo aún no se ha alcanzado. La base de macOS de la medición provisional se midió bajo carga; está prevista una nueva medición en una máquina en reposo para la próxima versión. La aceptación del objetivo está fijada para la próxima versión y no se cuenta como completada.
• Codex: Los casos de aceptación ocultos (review · holdout) no están disponibles allí.

Para usted esto significa: La aceptación se ha vuelto demostrable y las barreras son más estrechas. Queda un hueco hasta la siguiente versión, y lo señalamos.

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

Fuentes

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

Fecha: 04.11.2026