IssuesOpen
P0seguridadAgente Q
AQ-SEC-001Superficie pública sin protección
server/index.js
- CORS con allowlist por entorno
- Auth en endpoints de análisis
Adaptive QA Intelligence
El análisis de QA que se escribe para tu repo
Trece dominios de auditoría estática (seguridad, CI/CD, datos, arquitectura…) son la base del trabajo. Cuando el repositorio tiene particularidades que esos dominios no cubren, Adaptive QA Intelligence genera el expediente a medida y lo deja en issues accionables.
Solo lectura del código · Sin arrancar la app · Consola, API y CI
Así se ve el expediente Adaptive QA Intelligence en el job
Adaptive Graph
Cómo avanza un análisis
Tres zonas: de dónde sale el código, qué hace el núcleo Adaptive y qué llega al tablero del equipo.
Origen
GitHubCuenta y permisos del equipo
RepositorioEl código a revisar (solo lectura)
Rama de evidenciaagente-q/… con informes
Núcleo
Adaptive QA Intelligence
Expediente a medida del repo
Solo lo que los dominios no nombran en tu código
Dominios
13 áreas base: seguridad, CI, datos…
Multi-agente
Varias lecturas, un resultado fusionado
En consola puedes revisar el expediente; en CI puede ir en automático
Entrega
AnálisisInformes por dominio en el portal
Issues en GitHubPrioridad, paths y criterios para PR
Elige qué se revisa
Un paquete listo (Rápida, Núcleo, Seguridad o Completa) o dominios sueltos: seguridad, CI/CD, datos, arquitectura y el resto de las 13 áreas de calidad.
- Rápida
- Núcleo
- Enfoque seguridad
- Completa
Análisis en dos capas
Los dominios cubren el marco estándar del producto. Adaptive QA Intelligence añade un expediente solo sobre lo que es propio de este repositorio y los dominios no nombran.
Recibe trabajo en el tablero
Informes en el portal e issues priorizadas en GitHub. En la consola puedes revisar el expediente Adaptive QA Intelligence antes de seguir; en CI puede ir en automático.
Del repo al tablero
Sin arrancar la aplicación. El issue es la unidad de trabajo del equipo.
- 1
Alcance
Repo, paquete de dominios y Adaptive QA Intelligence si aplica.
- 2
Análisis
Agentes sobre los dominios y el expediente a medida.
- 3
Trabajo listo
Portal, issues en GitHub y rama de evidencia.
En GitHub Issues
Tickets con dominio, prioridad y criterios listos para un PR.
Informe y evidencia en la rama agente-q/…
IssuesOpen
P1ci/cdAgente Q
AQ-CICD-004Workflow con permisos de escritura amplios
.github/workflows/deploy.yml
- contents: read por defecto
- Token de deploy en environment
IssuesOpen
P1datosAgente Q
AQ-DATA-002Migración sin constraint de unicidad
db/migrations/0042_users.sql
- UNIQUE(email) en users
- Backfill documentado en el PR
El mismo análisis: consola, API o Actions
Un job. Tres formas de lanzarlo. Adaptive QA Intelligence se activa con un flag.
GitHub Actions
Composite Action oficial. Varios modelos en CSV: cada uno hace su pasada y el agregador fusiona.
- uses: 686f6c61/agent-q/.github/actions/agenteq-audit@main
with:
api-key: ${{ secrets.AGENTEQ_API_KEY }}
models: grok-4-5,claude-sonnet-5,glm-5-2
aggregator: deepseek-v4-flash
scopes: nucleo
adaptive-skill: "1"API v1
Bearer aq_live_…. Misma idea multi-modelo que la Action y la consola.
POST /api/v1/audits
{
"repoFullName": "owner/repo",
"auditScopes": ["nucleo"],
"aiModels": [
"grok-4-5",
"claude-sonnet-5",
"glm-5-2"
],
"aggregatorModelId": "deepseek-v4-flash",
"metaSkillEnabled": true,
"metaSkillMode": "auto"
}Detalle de inputs, OpenAPI y la Action: documentación en la consola.
Preguntas frecuentes
Dominios, Adaptive QA Intelligence, entrega en GitHub y acceso: el detalle está en cada respuesta.
¿Qué es Agente Q en una frase?
Un equipo de agentes de QA que revisa repositorios en GitHub sin arrancar la aplicación: trabaja por dominios de calidad, genera informes y, con permisos, abre issues accionables en el mismo repo.
¿Ejecuta la aplicación o instala dependencias?
No. Solo lee el árbol, la configuración y el código. No hace install, build ni tests en tu entorno. La verificación dinámica sigue siendo de tu CI.
¿Dónde acaban los hallazgos?
En tres sitios: informes en el portal de Agente Q, issues en GitHub Issues del repositorio (si hay permisos) y una rama de evidencia (agente-q/…) con la documentación. El issue es la unidad de trabajo del equipo; el informe, la evidencia.
¿Puedo elegir qué se revisa?
Sí. Al lanzar una ronda eliges un paquete de alcance (rápida, núcleo, seguridad, completa) o dominios sueltos. No hace falta una pasada completa cada vez: defines el brief de QA.
¿Qué son los dominios?
Son las trece áreas de auditoría estática que forman la base del producto: inventario, arquitectura, seguridad, calidad de código, fiabilidad, datos, pruebas (forma de la suite, sin ejecutarla), CI/CD, rendimiento, UX/API, compliance técnico, operación y preparación estática (runtime). Cada issue lleva un id de dominio (por ejemplo AQ-SEC-001).
¿Rápida, núcleo, seguridad o completa: cuándo cada una?
Rápida: due diligence inicial (inventario, runtime, seguridad ligera, CI y tests). Núcleo: producto estándar (rápida más arquitectura, fiabilidad, datos y calidad). Seguridad: foco AppSec y compliance. Completa: los 13 dominios y consolidación del backlog de trabajo para el equipo.
¿Qué es Adaptive QA Intelligence y Adaptive Graph?
Adaptive QA Intelligence es el expediente de QA a medida de ese repositorio: cubre lo que los 13 dominios no nombran en tu código (colas propias, webhooks de facturación, convenciones del monorepo…). Adaptive Graph es el recorrido del análisis: dominios → lo residual del repo → expediente Adaptive QA Intelligence → revisión en consola o automático en CI → informes e issues (incluidos hallazgos AQ-DYN cuando aplica). El modelo que redacta el expediente se configura en administración.
¿En qué momentos de producto encaja mejor?
Due diligence de un repo desconocido, pasada AppSec antes de un release, limpieza de deuda de CI o calidad en un sprint, o varias lecturas sobre la misma área. Cuando necesitas orden y tickets en el tablero, no otro PDF suelto.
¿Por qué varios agentes o modelos sobre el mismo alcance?
Cada agente hace una pasada completa sobre los dominios del alcance; el agregador fusiona por dominio. Varias lecturas reducen el punto ciego de un solo revisor o un solo modelo, y el resultado se unifica en informes e issues con id de dominio.
¿Sustituye a nuestro CI/CD?
No. Complementa: el dominio de CI/CD revisa pipelines, gates y permisos como código. Los issues salen a GitHub para que el equipo cierre con PR en el mismo flujo de desarrollo e integración continua.
¿Se puede lanzar desde GitHub Actions o por API?
Sí. Hay una Composite Action oficial y una API v1 con Bearer (claves de producto aq_live_…). En CI se crea el job, se hace poll del estado y se fallan los estados que configures. Por defecto los resultados pueden quedar en la plataforma sin escribir en el remoto. Los mismos modelos y dominios valen para la Action y para la API. Adaptive QA Intelligence se activa con un flag en la Action o en el cuerpo de la API (detalle en la documentación de la consola). OpenAPI y llm.txt están en la consola con acceso.
¿Cómo se priorizan las issues?
Con etiquetas P0–P3 y prefijos de dominio (SEC, ARCH, QUAL, CICD…). Hay un tope configurable de issues P0 por job para no aplanar el tablero; el resto se degrada a P1 si hace falta. Las reauditorías no duplican el mismo hallazgo.
¿Qué permisos de GitHub hacen falta?
Lectura del repositorio para auditar. Para publicar issues y la rama de evidencia hacen falta permisos de escritura (App o token con alcance adecuado). Sin escritura, siguen los informes en el portal; no se crean tickets en el repo.
¿Cómo se obtiene acceso?
El registro está cerrado: acceso por invitación o preaprobación. Puedes solicitar acceso desde la landing; el login con GitHub es para cuentas ya autorizadas.
Acceso por invitación
Pedí acceso o entrá si ya estás preaprobado.