--base/--target (y cualquier otra opción) se aplican de la misma manera a cada repositorio de la lista, por lo que el modo multi-repositorio encaja mejor cuando todos comparan contra lo mismo (p. ej., el main de todos). Los repositorios con convenciones diferentes necesitan ejecuciones separadas.

Banderas

Qué escanear

• --base, -b (ninguno): referencia desde la que comparar, p. ej. main o HEAD~3. Si se omite, zairo escanea los cambios sin confirmar.
• --target, -t (ninguno): referencia hasta la que comparar. Requiere --base; si se omite (con --base definido), compara contra tu árbol de trabajo.
• --depth, -d (1): cuántos saltos de llamadores/llamados incluir en el grafo de impacto alrededor de cada cambio.
• --language, -l (auto): fuerza un lenguaje en lugar de dejar que Trailmark lo detecte automáticamente.

Escaneo con LLM

• --graph-only (desactivado): omite el escaneo de vulnerabilidades y solo construye el grafo de impacto — sin hallazgos, sin report.sarif.
• --model (gemini/gemini-2.5-pro): cualquier cadena de modelo LiteLLM.
• --concurrency, -c (5): solicitudes LLM en paralelo, dentro del escaneo de un solo repositorio.
• --batch-size (1): agrupa esta cantidad de nodos en una sola solicitud LLM en lugar de una llamada por nodo — menos solicitudes (ayuda con los límites de tasa del proveedor), a costa del aislamiento de fallos compartido: una respuesta mala o malformada hace fallar todos los nodos de ese lote, no solo uno. El caché sigue siendo por nodo en cualquier caso.
• --max-tokens (4096): presupuesto de salida por solicitud. Los modelos de razonamiento también consumen esto en el pensamiento interno, así que súbelo si ves respuestas vacías.
• --cache / --no-cache (caché activado): omite volver a escanear código sin cambios desde la última ejecución (almacenado en caché por hash de contenido en <output>/.llm_cache.json).
• --tokens (desactivado): imprime cuántos tokens usó realmente el escaneo (los aciertos de caché no cuentan, ya que no hicieron ninguna llamada).

Salida y control

• --output, -o (zairo_out): dónde van los informes. Modo multi-repositorio: cada repositorio recibe su propio <output>/<repo-slug>/, más un rollup.* combinado aquí también.
• --fail-on (ninguno): sale con código distinto de cero si aparece un hallazgo en esta severidad o superior (low/medium/high/critical). Da error si se combina con --graph-only (no habría nada sobre lo que controlar). Modo multi-repositorio: se verifica en todos los repositorios combinados. Consulta Control de CI / PR.
• --verbose, -v (desactivado): imprime lo que sucede paso a paso (comandos git, configuración del árbol de trabajo, progreso del escaneo por nodo).
• --debug, -vv (desactivado): todo lo que imprime --verbose, más el prompt exacto enviado al LLM y su respuesta cruda para cada nodo — escrito en <output>/debug.log (por repositorio en modo multi-repositorio), ya que es demasiado para imprimir en la consola.

Solo modo multi-repositorio

• --repos-file (ninguno): una ruta de repositorio por línea (se permiten comentarios con #), combinada con cualquier repositorio dado directamente.
• --repo-concurrency (1): cuántos repositorios escanear a la vez. Las solicitudes LLM totales en vuelo pueden alcanzar --concurrency × --repo-concurrency, así que ten en cuenta los límites de tasa de tu proveedor. Por encima de 1, el progreso imprime una línea de resumen por repositorio al completarse en lugar de detalles paso a paso en vivo.
• --continue-on-error / --stop-on-error (continuar): sigue escaneando el resto de la lista, o detente, cuando un repositorio falla. En cualquier caso, cualquier repositorio fallido sigue haciendo fallar el código de salida general.

Ejecuta zairo --help en cualquier momento para ver esta misma lista desde la CLI.

Archivos de salida

• report.json (siempre): el grafo de impacto crudo (nodos, aristas y cualquier hallazgo adjunto), como datos.
• report.html (siempre): un visor de grafo de dependencias interactivo y autónomo (Cytoscape.js). Haz clic en un nodo para ver sus hallazgos.
• report.sarif (a menos que se use --graph-only): hallazgos en SARIF 2.1.0, para el escaneo de código de GitHub o cualquier otro consumidor de SARIF. Siempre se escribe, incluso para un escaneo limpio (un registro vacío pero válido), para que una interfaz de escaneo pueda marcar alertas previamente reportadas como resueltas. Los hallazgos se agrupan en reglas por CWE cuando el modelo etiquetó una, de modo que los problemas recurrentes del mismo tipo se colapsan en una sola regla en lugar de una nueva por variante de redacción.

El modo multi-repositorio produce los mismos tres archivos por repositorio, más rollup.json / rollup.html / rollup.sarif: estado por repositorio y recuentos de severidad, una tabla de panel que enlaza con los informes de cada repositorio, y los resultados SARIF de cada repositorio combinados en un único registro de múltiples ejecuciones.

Código eliminado

Una función/clase/módulo eliminado por completo (no solo editado) sigue apareciendo en report.html, con estado deleted: un nodo discontinuo y atenuado que marca dónde solía estar. El grafo de Trailmark no puede representar esto por sí solo (solo refleja el árbol tal como está ahora), por lo que zairo detecta las eliminaciones por separado: también analiza los archivos modificados tal como existían en --base (o HEAD, si no se dio --base) y compara los dos conjuntos de símbolos. Una función eliminada nunca se envía al escáner LLM (no queda código vivo que escanear), por lo que solo lleva su nombre, tipo y ubicación anterior, nunca hallazgos.

Control de CI / PR

--fail-on <low|medium|high|critical> sale con código distinto de cero si se encuentra algún hallazgo en esa severidad o superior (en todos los repositorios combinados, en modo multi-repositorio), de modo que un paso de CI pueda bloquear una fusión (merge) por ello. Un par de cosas que vale la pena saber:

• Da error si se combina con --graph-only (no habría nada sobre lo que controlar).
• Nunca suprime la salida SARIF: esta se sigue escribiendo incluso con un control fallido, de modo que una interfaz de escaneo refleje el estado actual en cualquier caso.

Consulta examples/github-actions/zairo-pr-scan.yml para ver un flujo de trabajo completo de escaneo de PR: ejecuta zairo en el diff del PR, sube report.sarif al escaneo de código de GitHub y hace fallar el trabajo si el control falla.