Evaluación de plugins en Claude Code: flujo de aceptación para sistemas de IA

Claude Code 2.1.269, fechado el 11 de septiembre de 2026, incorpora `claude plugin eval`. Según Anthropic, el comando ejecuta la batería de evaluación de un plugin y entrega resultados puntuados y reproducibles en informes JSON y HTML. Esa es la capacidad confirmada; no equivale a una certificación de seguridad, cumplimiento o preparación para producción.

La aplicación operativa propuesta por CreatikLab consiste en separar tres actos: ejecutar, conservar evidencia y aprobar. Claude Code ejecuta la evaluación; los informes permiten inspeccionar el resultado; una persona con responsabilidad sobre el proceso decide si se cumplen las condiciones de entrega.

• Confirmado: existe un comando dedicado para ejecutar evaluaciones de plugins.
• Confirmado: el resultado incluye una puntuación y se describe como reproducible.
• Confirmado: se generan formatos JSON y HTML.
• No especificado: umbral universal, catálogo obligatorio de pruebas o certificación para producción.

La batería no debería empezar por lo fácil de automatizar, sino por el fallo que más perjudicaría al proceso. Esta matriz de CreatikLab es una metodología de decisión independiente; no describe funciones adicionales de Claude Code.

• Riesgo funcional — Evidencia: salida esperada y variaciones admitidas. Acción: comparar con un caso aprobado. Responsable: producto.
• Riesgo de herramientas — Evidencia: comandos, herramientas solicitadas y cambios de archivos disponibles. Acción: rechazar accesos o mutaciones sin explicar. Responsable: liderazgo técnico.
• Riesgo de datos — Evidencia: entradas depuradas, salidas y registros. Acción: retirar campos sensibles innecesarios. Responsable: propietario del dato.
• Riesgo de integración — Evidencia: dependencias, configuración y comportamiento ante fallos. Acción: probar degradación. Responsable: plataforma.
• Riesgo de negocio — Evidencia: decisión posterior afectada. Acción: exigir intervención humana cuando el error pueda causar un perjuicio material. Responsable: dueño del proceso.

Regla de aceptación: un riesgo material sin evidencia, acción y responsable impide aprobar el plugin. Una puntuación agregada favorable no compensa la ausencia de una prueba sobre el fallo más importante.

La misma versión permite listar y cambiar estilos de salida, también en Remote Control, sesiones cloud y otras ejecuciones sin interfaz. Además, cuando Bash modifica archivos, el resultado de la herramienta puede incluir un diff de esos cambios mediante la opción `bashEditDiffEnabled`. Anthropic no afirma que ese diff represente todos los efectos posibles de una sesión.

Para observabilidad, `OTEL_METRICS_INCLUDE_REPOSITORY` puede añadir atributos del repositorio a métricas y eventos de OpenTelemetry; los eventos de commit reciben atributos relacionados con la referencia. En entornos con gateway, `CLAUDE_CODE_GATEWAY_MODEL_DISCOVERY_TIMEOUT_MS` permite ampliar el tiempo de descubrimiento de modelos, cuyo valor predeterminado documentado es de tres segundos.

El límite de agentes concurrentes de Workflow puede elevarse con `CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS` dentro del intervalo documentado de uno a 256 para distribuciones vinculadas a inferencia. Es un control de capacidad, no una promesa de mayor calidad. También se corrigen incidencias de caché y estados incorrectos de agentes en segundo plano.

Guardar solo la puntuación no basta. El expediente debe identificar la versión de Claude Code, la revisión del plugin y de la batería, las herramientas permitidas, los ajustes relevantes, las entradas, los resultados esperados y el entorno. Cuando cambia una condición, la nueva ejecución debe etiquetarse como tal.

1. Fijar las revisiones del plugin y de la batería evaluada.
2. Sustituir secretos y datos personales en los casos de prueba.
3. Declarar herramientas permitidas y cambios de archivo previstos.
4. Ejecutar la evaluación en un entorno controlado.
5. Conservar JSON y HTML junto a los metadatos de versión.
6. Registrar anomalías, comentarios y decisión final.
7. Vincular cada corrección con el caso fallido antes de repetir.

La nota oficial no especifica el esquema de los informes, el plazo de conservación ni su modelo de acceso. Antes de automatizar su tratamiento hay que comprobar esos elementos y aplicar las políticas de seguridad y retención de la organización.

Cada fallo necesita clasificación: comportamiento defectuoso del plugin, expectativa ambigua, caso poco realista, diferencia de entorno o dependencia externa. Cambiar el criterio únicamente para elevar la puntuación rompe la trazabilidad si no existe una justificación revisada.

También conviene muestrear casos aprobados. El plugin podría producir la respuesta prevista mediante un comando improcedente, acceso innecesario a datos o cambios de archivos no autorizados. El diff incorporado cuando Bash realiza ediciones puede ayudar a revisar, pero debe tratarse como una pieza de evidencia y no como un registro integral de seguridad.

El expediente debe conservar juntos el informe original, el diagnóstico, la referencia de corrección y la nueva ejecución. Si se acepta una desviación conocida, hay que documentar su alcance, motivo empresarial, control temporal y responsable. Estas condiciones forman parte de la gobernanza propuesta por CreatikLab, no de reglas automáticas de Anthropic.

La puntuación procede de la evaluación; la decisión de aceptación pertenece a la organización. A nivel de batería se conserva el resultado y la identidad del informe. A nivel de caso se registran expectativa, comportamiento observado, clase de fallo y revisión. Tras el despliegue se vigilan intervenciones, incidentes y condiciones de reversión definidas por el negocio.

• Cobertura: riesgos materiales que disponen de un caso explícito.
• Repetibilidad: coherencia de la decisión bajo condiciones controladas equivalentes.
• Mutaciones: capacidad de distinguir cambios previstos e inesperados.
• Intervención: salidas que necesitan corrección o escalado.
• Validez empresarial: cumplimiento de criterios aprobados por el responsable del proceso.
• Trazabilidad: vínculo entre aprobación, versiones, entorno e informes.

No deben compararse puntuaciones de baterías diferentes como si midieran lo mismo. Tampoco se deben deducir ingresos, fiabilidad o leads cualificados a partir de una nota, salvo que exista una prueba definida de esa relación y que el sistema de medición posterior haya sido validado por separado.

Anthropic no detalla en la nota de versión pruebas incluidas de serie, umbral de aprobación, precios, elegibilidad por plan, esquema de informes, conservación de datos ni alcance de despliegue. Ninguno de esos elementos debe inventarse al presupuestar o implantar el flujo.

• No asumir que reproducible significa idéntico bajo cualquier dependencia.
• No confundir un archivo JSON con una auditoría completa.
• No interpretar el informe HTML como validación de permisos.
• No elevar la concurrencia solo porque exista un límite configurable.
• No presentar el diff de Bash como registro exhaustivo de acciones.
• No introducir secretos de producción para dar realismo a una prueba.
• No dejar la aprobación material únicamente en manos del autor del plugin.

La concurrencia exige especial prudencia. El rango documentado indica qué admite el control, no qué configuración conviene a cada organización. Más trabajo simultáneo puede afectar a costes, límites, observabilidad y capacidad de revisión; esas consecuencias deben estudiarse en el entorno donde se operará.

Para comparar proveedores, el comprador debería exigir entregables inspeccionables: registro de riesgos vinculado al comportamiento del plugin, casos versionados, manifiesto de ejecución, informes JSON y HTML, triaje de fallos, revisión de permisos, mapa de observabilidad, criterios de aceptación y procedimiento de reversión. También debe quedar claro quién aprueba y quién resuelve excepciones.

Si el plugin participa en captación o ventas, los leads cualificados se miden en el sistema posterior con una definición acordada por marketing y ventas, como una aceptación comercial o un estado validado del ciclo. La puntuación, el volumen generado y las tareas completadas son señales operativas, no resultados comerciales por sí mismos.

El servicio de automatización con IA de CreatikLab puede entregar una auditoría de aceptación de plugins que cubra diseño de evaluaciones, permisos, revisión de cambios, telemetría, gestión de fallos y evidencia de entrega. Explica a Lia qué hace el plugin, qué sistemas puede modificar, qué pruebas existen y qué fallo tendría mayor impacto.

¿Qué añade Claude Code 2.1.269 para evaluar plugins?

Anthropic indica que incorpora el comando claude plugin eval, capaz de ejecutar la batería de evaluación de un plugin y generar resultados puntuados y reproducibles en JSON y HTML.

¿Una buena puntuación demuestra que el plugin está listo para producción?

No. La función genera evidencia de evaluación, pero Anthropic no la presenta como certificación de seguridad, cumplimiento o preparación para producción. La aceptación requiere controles adicionales y un responsable humano.

¿Para qué sirven los informes JSON y HTML?

El JSON facilita el tratamiento estructurado y el HTML la revisión humana. La nota de versión no detalla sus esquemas, conservación ni permisos, por lo que deben verificarse en el entorno real.

¿La evaluación elimina la revisión humana?

No hay ninguna afirmación oficial en ese sentido. Conviene revisar fallos, aprobaciones sospechosas, comandos, cambios de archivos y consecuencias para el negocio antes de autorizar una entrega.

¿Qué debe mantenerse constante al comparar ejecuciones?

Hay que registrar la versión de Claude Code, el plugin, la batería, los datos de prueba, los permisos, la configuración y el entorno. Si cambian, la comparación debe declararlo.

¿Qué puede entregar CreatikLab?

CreatikLab puede realizar una auditoría de aceptación de plugins con diseño de evaluaciones, permisos, observabilidad, triaje y criterios de reversión mediante su servicio de automatización con IA. Describe el contexto a Lia para continuar el diagnóstico.