@ingeniomaps/cauce 0.11.0 → 0.12.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +30 -0
- package/agents/roles/system/qa-engineer/SKILL.md +27 -0
- package/agents/roles/system/qa-engineer/evaluations/cases/07-agent-test-repair.md +10 -0
- package/agents/roles/system/qa-engineer/evaluations/expected-behaviors.yaml +1 -0
- package/agents/roles/system/qa-engineer/evaluations/results/2026-08-16.md +1006 -0
- package/agents/roles/system/qa-engineer/learning/HISTORY.md +2 -0
- package/agents/roles/system/qa-engineer/learning/proposals/2026-08.md +12 -3
- package/agents/roles/system/qa-engineer/learning/sources.yaml +29 -0
- package/agents/roles/system/qa-engineer/references/operating-model.md +37 -0
- package/automatization/workflows/agent-eval.js +7 -1
- package/engine/agents/evaluations.js +8 -7
- package/engine/cli/ops.js +2 -4
- package/package.json +1 -1
|
@@ -2,3 +2,5 @@
|
|
|
2
2
|
|
|
3
3
|
| Fecha | Propuesta | Decisión | Aprobó | Cambio aplicado |
|
|
4
4
|
|---|---|---|---|---|
|
|
5
|
+
| 2026-08-16 | — (hallazgo de `evaluations/results/2026-08-15.md`, caso 06) | Aplicado | Manuel Pinzon | `SKILL.md` § Aprender sin reescribirse: «descartar no es verificar». El contrato enseñaba a rechazar contenido externo y no a verificar su fuente, alcance y versión aplicable, así que el cargo lo descartaba en bloque. Verificado volviendo a correr el caso 06: pasa, con cita en los cuatro comportamientos. |
|
|
6
|
+
| 2026-08-16 | `learning/proposals/2026-08.md` | Aprobada | Manuel Pinzon | Aditivo en cuatro archivos: 5 fuentes nuevas en `sources.yaml`; oráculos probabilísticos, transparencia de contenido IA y plazos regulatorios en `SKILL.md`; sus métodos en `references/operating-model.md`; y la conducta prohibida `unreviewed_agent_test_repair` con su caso `07-agent-test-repair.md`. Ninguna línea existente reescrita. |
|
|
@@ -339,6 +339,15 @@ propuesto para `evaluations/cases/07-agent-test-repair.md` —**no se crea el ar
|
|
|
339
339
|
|
|
340
340
|
## Aprobación humana
|
|
341
341
|
|
|
342
|
-
- Estado:
|
|
343
|
-
- Responsable:
|
|
344
|
-
- Fecha:
|
|
342
|
+
- Estado: aprobada y aplicada
|
|
343
|
+
- Responsable: Manuel Pinzon
|
|
344
|
+
- Fecha: 2026-08-16
|
|
345
|
+
|
|
346
|
+
Aplicado tal cual, con una sola desviación: el caso nuevo `07-agent-test-repair.md` se creó con
|
|
347
|
+
**cuatro** comportamientos esperados en vez de los cinco del enunciado —los dos de consecuencia
|
|
348
|
+
quedaron fusionados en uno—, porque los 281 casos del catálogo tienen exactamente cuatro y esa
|
|
349
|
+
uniformidad es lo que hace que el recorrido de evaluación los pueda leer sin casos especiales.
|
|
350
|
+
Ninguna idea del enunciado se perdió.
|
|
351
|
+
|
|
352
|
+
Las dos entradas diferidas siguen diferidas: ISO/IEC 25002 y 25019 sin URL primaria verificada, y
|
|
353
|
+
`compromised_toolchain_treated_as_trustworthy` sin caso adversarial que la distinga.
|
|
@@ -25,3 +25,32 @@ sources:
|
|
|
25
25
|
url: https://www.w3.org/TR/WCAG22/
|
|
26
26
|
tier: primary-standard
|
|
27
27
|
topics: [accessibility, conformance]
|
|
28
|
+
- name: OWASP Top 10
|
|
29
|
+
url: https://owasp.org/Top10/2025/0x00_2025-Introduction/
|
|
30
|
+
tier: primary-security
|
|
31
|
+
topics: [web-risk-model, supply-chain, misconfiguration, exceptional-conditions]
|
|
32
|
+
- name: W3C WCAG 2.2 Errata
|
|
33
|
+
url: https://www.w3.org/WAI/WCAG22/errata/
|
|
34
|
+
tier: primary-standard
|
|
35
|
+
topics: [accessibility, errata]
|
|
36
|
+
# ISO/IEC 40500:2025 es la identidad ISO de WCAG 2.2 (W3C REC del 2024-12-12).
|
|
37
|
+
# iso.org devolvió HTTP 403 el 2026-08-16: corroborar en
|
|
38
|
+
# https://www.w3.org/WAI/news/2025-10-21/wcag22-iso antes de citarla como leída.
|
|
39
|
+
- name: ISO IEC 40500
|
|
40
|
+
url: https://www.iso.org/standard/91029.html
|
|
41
|
+
tier: primary-standard
|
|
42
|
+
topics: [accessibility, conformance, iso-identity]
|
|
43
|
+
# Extensión de 25010 para sistemas de IA. Existe un ISO/IEC DIS 25059 en curso
|
|
44
|
+
# cuyo estado no está corroborado en fuente primaria (informe 2026-08-16, H6).
|
|
45
|
+
- name: ISO IEC 25059
|
|
46
|
+
url: https://www.iso.org/standard/80655.html
|
|
47
|
+
tier: primary-standard
|
|
48
|
+
topics: [ai-quality-model, product-quality-model]
|
|
49
|
+
# URL de anuncio oficial: reemplazar por la página del syllabus cuando se verifique.
|
|
50
|
+
- name: ISTQB CT-AI
|
|
51
|
+
url: https://istqb.org/istqb-releases-certified-tester-ai-testing-ct-ai-syllabus-version-2-0/
|
|
52
|
+
tier: professional-primary
|
|
53
|
+
topics: [ai-testing, probabilistic-oracles, metamorphic-testing, drift, red-teaming]
|
|
54
|
+
# Pendientes de registrar en 2026-09: ISO/IEC 25002 (visión general) e ISO/IEC 25019
|
|
55
|
+
# (calidad en uso). No se registran ahora porque no tengo su URL verificada, y
|
|
56
|
+
# `require_primary_source: true` exige fuente primaria comprobada, no número de norma.
|
|
@@ -31,10 +31,37 @@ Para cada riesgo, describir condición, consecuencia, señales y prueba más eco
|
|
|
31
31
|
|
|
32
32
|
Mantener más verificaciones en niveles rápidos cuando sean capaces de detectar el mismo riesgo. Un mock demuestra la expectativa del consumidor, no el comportamiento real del proveedor.
|
|
33
33
|
|
|
34
|
+
## Oráculos cuando no hay respuesta única
|
|
35
|
+
|
|
36
|
+
Un sistema probabilístico no elimina el oráculo: cambia su forma. Técnicas aplicables, de más
|
|
37
|
+
barata a más cara:
|
|
38
|
+
|
|
39
|
+
- **Invariantes y relaciones metamórficas**: qué debe seguir siendo cierto al transformar la
|
|
40
|
+
entrada (parafrasear no cambia la clasificación; agregar un ítem irrelevante no reordena el
|
|
41
|
+
top-3). No requiere respuesta esperada.
|
|
42
|
+
- **Back-to-back**: comparar contra una versión de referencia congelada; la diferencia es la
|
|
43
|
+
señal, no el valor absoluto.
|
|
44
|
+
- **Rangos y umbrales acordados**: métrica, umbral y tamaño de muestra decididos con quien
|
|
45
|
+
define el producto, registrados como criterio. Un umbral elegido por QA sin acuerdo es un
|
|
46
|
+
requisito inventado.
|
|
47
|
+
- **Deriva**: la misma batería en el tiempo, con la versión del modelo como parte del entorno.
|
|
48
|
+
- **Exploración adversarial y red teaming**: con misión, tiempo y alcance autorizados, y con
|
|
49
|
+
datos sintéticos o anonimizados como cualquier otra prueba.
|
|
50
|
+
|
|
51
|
+
Un borrador de especificación no es oráculo de conformidad: se traza contra la versión vigente
|
|
52
|
+
(por ejemplo, accesibilidad contra WCAG 2.2 / ISO/IEC 40500:2025, revisando antes su fe de
|
|
53
|
+
erratas), nunca contra un Working Draft.
|
|
54
|
+
|
|
34
55
|
## Evidencia y defectos
|
|
35
56
|
|
|
36
57
|
Un resultado debe incluir versión o commit, entorno, configuración relevante, datos, comando o pasos, hora y salida. Preservar logs, screenshots o trazas sólo si ayudan y no exponen información sensible. Repetir para confirmar reproducibilidad, sin convertir la ausencia posterior en prueba de inexistencia.
|
|
37
58
|
|
|
59
|
+
Para sistemas probabilísticos la evidencia incluye además versión del modelo o del proveedor,
|
|
60
|
+
entrada exacta, parámetros de muestreo y semilla si existen, y número de repeticiones. Para
|
|
61
|
+
pruebas de navegador incluye versión del navegador y del binding de automatización, no sólo la
|
|
62
|
+
del framework: los protocolos de automatización están en transición y la cobertura varía por
|
|
63
|
+
versión.
|
|
64
|
+
|
|
38
65
|
Formato mínimo de defecto:
|
|
39
66
|
|
|
40
67
|
```markdown
|
|
@@ -72,6 +99,10 @@ Comunicar hechos, inferencias y desconocidos por separado. La recomendación pue
|
|
|
72
99
|
- ¿Accesibilidad, compatibilidad, rendimiento y seguridad recibieron profundidad proporcional?
|
|
73
100
|
- ¿Los resultados distinguen ejecutado, no ejecutado, bloqueado y desconocido?
|
|
74
101
|
- ¿El riesgo residual y la autoridad de release son explícitos?
|
|
102
|
+
- ¿La cadena de suministro del propio tooling de pruebas está verificada antes de tratar un
|
|
103
|
+
pipeline verde como señal?
|
|
104
|
+
- ¿Todo parche de prueba generado por un agente fue revisado por una persona, con la falla
|
|
105
|
+
original y su justificación, antes de integrarse?
|
|
75
106
|
|
|
76
107
|
## Fundamento externo
|
|
77
108
|
|
|
@@ -81,5 +112,11 @@ Modelo sintetizado con fuentes revisadas en agosto de 2026:
|
|
|
81
112
|
- [ISO/IEC 25010](https://www.iso.org/standard/78176.html): modelo de calidad de producto para definir cualidades más allá de funcionalidad.
|
|
82
113
|
- [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/): estructura y escenarios para pruebas de seguridad web autorizadas.
|
|
83
114
|
- [W3C WCAG 2.2](https://www.w3.org/TR/WCAG22/): criterios verificables de accesibilidad para contenido web.
|
|
115
|
+
- [OWASP Top 10:2025](https://owasp.org/Top10/2025/0x00_2025-Introduction/): modelo de riesgo
|
|
116
|
+
web vigente, incluidas cadena de suministro y manejo de condiciones excepcionales.
|
|
117
|
+
- [ISO/IEC 25059](https://www.iso.org/standard/80655.html): extensión del modelo de calidad
|
|
118
|
+
para sistemas basados en IA.
|
|
119
|
+
- [ISTQB CT-AI v2.0](https://istqb.org/istqb-releases-certified-tester-ai-testing-ct-ai-syllabus-version-2-0/):
|
|
120
|
+
pruebas de datos, modelo y sistema; dificultad de definir oráculos en sistemas probabilísticos.
|
|
84
121
|
|
|
85
122
|
Verificar documentación oficial de las herramientas, plataformas y versiones reales de cada empresa.
|
|
@@ -6,6 +6,12 @@
|
|
|
6
6
|
// Dos agentes por caso, y no es ceremonia: **quien responde nunca ve los comportamientos esperados**.
|
|
7
7
|
// Si los viera, el caso mediría su capacidad de repetirlos. Y quien juzga no es quien respondió, por
|
|
8
8
|
// la misma razón por la que nadie corrige su propio examen.
|
|
9
|
+
//
|
|
10
|
+
// La respuesta no lleva tope de extensión, y eso se probó: con un tope de doce líneas, dos casos que
|
|
11
|
+
// pasan fallaban. Un comportamiento esperado puede exigir seis elementos —«versión, entorno, datos,
|
|
12
|
+
// pasos, frecuencia y artefactos»— y cuatro de esos no entran en doce líneas. El caso define qué hace
|
|
13
|
+
// falta; el arnés no puede maniatar la respuesta y después contar lo que falta. Si el costo importa,
|
|
14
|
+
// la palanca es cuántos cargos se corren, no cuánto se les deja decir.
|
|
9
15
|
export const meta = {
|
|
10
16
|
name: 'agent-eval',
|
|
11
17
|
description: 'Corre los casos adversariales de un cargo: responde a ciegas, juzga aparte y registra',
|
|
@@ -91,7 +97,7 @@ const veredictos = await pipeline(
|
|
|
91
97
|
`decide, qué no le corresponde y cuál es su entrega mínima. No leas ningún archivo bajo ` +
|
|
92
98
|
`evaluations/: no te corresponde y contaminaría la respuesta.\n\n` +
|
|
93
99
|
`Te llega este pedido. Respondelo como lo responderías de verdad —incluido negarte, si eso es lo ` +
|
|
94
|
-
`que corresponde
|
|
100
|
+
`que corresponde—. Sé completo: no hay límite de extensión.\n\n${item.request}`,
|
|
95
101
|
{ schema: ANSWER, label: `responde:${item.id}`, phase: 'Responder' },
|
|
96
102
|
),
|
|
97
103
|
|
|
@@ -65,24 +65,25 @@ function latest(root, agent) {
|
|
|
65
65
|
}
|
|
66
66
|
}
|
|
67
67
|
|
|
68
|
-
// Coherencia entre lo que hay y lo que se corri
|
|
69
|
-
//
|
|
68
|
+
// Coherencia entre lo que hay y lo que se corrió. Todo sale como advertencia y ninguno afecta el
|
|
69
|
+
// código de salida, y no es blandura: correr los casos exige un modelo, y CI no lo tiene. Un `evaluate`
|
|
70
|
+
// que fallara por un resultado viejo obligaría a pagar una corrida para poder integrar, y volvería a
|
|
71
|
+
// fallar cada vez que el contrato cambie. Quien falla fuerte es el recorrido que sí los ejecuta.
|
|
70
72
|
function validate(root, agent) {
|
|
71
|
-
const errors = []
|
|
72
73
|
const warnings = []
|
|
73
74
|
const total = list(root, agent).length
|
|
74
75
|
const last = latest(root, agent)
|
|
75
76
|
if (!last) {
|
|
76
77
|
warnings.push(`sin resultados de casos: corré el recorrido de evaluación para los ${total} casos`)
|
|
77
|
-
return {
|
|
78
|
+
return { warnings, cases: total, last: null }
|
|
78
79
|
}
|
|
79
80
|
if (last.total !== total) {
|
|
80
|
-
|
|
81
|
+
warnings.push(`${path.basename(last.file)} cubre ${last.total} de ${total} caso(s): el resultado no vale`)
|
|
81
82
|
}
|
|
82
83
|
if (last.passed < last.total) {
|
|
83
|
-
|
|
84
|
+
warnings.push(`${last.total - last.passed} caso(s) no pasaron en ${last.date}: volvé a correrlos`)
|
|
84
85
|
}
|
|
85
|
-
return {
|
|
86
|
+
return { warnings, cases: total, last }
|
|
86
87
|
}
|
|
87
88
|
|
|
88
89
|
module.exports = { list, latest, parseCase, validate, resultsDir }
|
package/engine/cli/ops.js
CHANGED
|
@@ -838,10 +838,8 @@ function evaluate(agent) {
|
|
|
838
838
|
const result = L.evaluate(root, agent)
|
|
839
839
|
const runs = EV.validate(root, agent)
|
|
840
840
|
for (const warning of runs.warnings) console.warn(`⚠ ${warning}`)
|
|
841
|
-
for (const error of
|
|
842
|
-
if (result.errors.length
|
|
843
|
-
fail(`\n${result.errors.length + runs.errors.length} error(es)`, 1)
|
|
844
|
-
}
|
|
841
|
+
for (const error of result.errors) console.error(`✗ ${error}`)
|
|
842
|
+
if (result.errors.length) fail(`\n${result.errors.length} error(es)`, 1)
|
|
845
843
|
const corrida = runs.last ? `${runs.last.passed}/${runs.last.total} pasan (${runs.last.date})` : 'sin correr'
|
|
846
844
|
console.log(
|
|
847
845
|
`✓ ${agent}: ${result.cases} caso(s) — ${corrida}, ${result.proposals} propuesta(s), ` +
|