--base/--target (et toutes les autres options) s'appliquent de la même manière à chaque dépôt de la liste, donc le mode multi-dépôts convient mieux lorsqu'ils font tous un diff par rapport à la même référence (par exemple, le main de chacun). Les dépôts avec des conventions différentes nécessitent des exécutions séparées.

Options

Quoi analyser

• --base, -b (aucune) : référence à partir de laquelle faire le diff, par ex. main ou HEAD~3. Si omise, zairo analyse les changements non commités à la place.
• --target, -t (aucune) : référence vers laquelle faire le diff. Nécessite --base ; si omise (avec --base défini), il fait le diff par rapport à votre arbre de travail.
• --depth, -d (1) : nombre de sauts d'appelants/appelés à inclure dans le graphe d'impact autour de chaque changement.
• --language, -l (auto) : force une langue au lieu de laisser Trailmark la détecter automatiquement.

Analyse LLM

• --graph-only (désactivé) : ignore l'analyse de vulnérabilités et construit uniquement le graphe d'impact — aucun résultat, pas de report.sarif.
• --model (gemini/gemini-2.5-pro) : toute chaîne de modèle LiteLLM.
• --concurrency, -c (5) : requêtes LLM parallèles, au sein de l'analyse d'un seul dépôt.
• --batch-size (1) : regroupe ce nombre de nœuds dans une seule requête LLM au lieu d'un appel par nœud — moins de requêtes (aide avec les limites de débit du fournisseur), au prix d'une isolation de panne partagée : une réponse mauvaise/malformée fait échouer chaque nœud de ce lot, pas seulement un. La mise en cache reste par nœud dans les deux cas.
• --max-tokens (4096) : budget de sortie par requête. Les modèles de raisonnement consomment aussi ce budget pour la réflexion interne, donc augmentez-le si vous voyez des réponses vides.
• --cache / --no-cache (cache activé) : ignore la ré-analyse du code inchangé depuis la dernière exécution (mis en cache par hash de contenu dans <output>/.llm_cache.json).
• --tokens (désactivé) : affiche combien de jetons l'analyse a réellement utilisés (les hits de cache ne comptent pas, car aucun appel n'a été fait).

Sortie et contrôle

• --output, -o (zairo_out) : où les rapports sont écrits. Mode multi-dépôts : chaque dépôt reçoit son propre <output>/<repo-slug>/, plus un rollup.* combiné ici aussi.
• --fail-on (aucune) : sort avec un code non nul si un résultat à cette sévérité ou au-dessus apparaît (low/medium/high/critical). Erreur si combiné avec --graph-only (rien sur quoi contrôler). Mode multi-dépôts : vérifié sur tous les dépôts combinés. Voir Contrôle CI / PR.
• --verbose, -v (désactivé) : affiche ce qui se passe étape par étape (commandes git, configuration de l'arbre de travail, progression de l'analyse par nœud).
• --debug, -vv (désactivé) : tout ce que --verbose affiche, plus l'invite exacte envoyée au LLM et sa réponse brute pour chaque nœud — écrit dans <output>/debug.log (par dépôt en mode multi-dépôts), car c'est trop volumineux pour la console.

Mode multi-dépôts uniquement

• --repos-file (aucune) : un chemin de dépôt par ligne (commentaires # autorisés), fusionné avec les dépôts donnés directement.
• --repo-concurrency (1) : combien de dépôts analyser en même temps. Le total des requêtes LLM en vol peut atteindre --concurrency × --repo-concurrency, donc surveillez les limites de débit de votre fournisseur. Au-dessus de 1, la progression affiche une ligne de résumé par dépôt à la fin au lieu du détail étape par étape en direct.
• --continue-on-error / --stop-on-error (continuer) : continuez à analyser le reste de la liste, ou arrêtez-vous, lorsqu'un dépôt échoue. Dans les deux cas, tout dépôt en échec fait toujours échouer le code de sortie global.

Exécutez zairo --help à tout moment pour obtenir cette même liste depuis la CLI.

Fichiers de sortie

• report.json (toujours) : le graphe d'impact brut (nœuds, arêtes et tout résultat associé), sous forme de données.
• report.html (toujours) : un visualiseur de graphe de dépendances interactif autonome (Cytoscape.js). Cliquez sur un nœud pour voir ses résultats.
• report.sarif (sauf si --graph-only est utilisé) : résultats au format SARIF 2.1.0, pour le code scanning GitHub ou tout autre consommateur SARIF. Toujours écrit, même pour une analyse propre (un journal vide mais valide), afin qu'une interface d'analyse puisse marquer les alertes précédemment signalées comme résolues. Les résultats sont regroupés en règles par CWE lorsque le modèle en a tagué un, donc les problèmes récurrents du même type se regroupent en une seule règle au lieu d'une nouvelle par variante de formulation.

Le mode multi-dépôts produit les mêmes trois fichiers par dépôt, plus rollup.json / rollup.html / rollup.sarif : statut par dépôt et compteurs de sévérité, un tableau de bord avec des liens vers les rapports de chaque dépôt, et tous les résultats SARIF de chaque dépôt fusionnés en un seul journal multi-exécutions.

Code supprimé

Une fonction/classe/module supprimé entièrement (pas seulement modifié) apparaît toujours dans report.html, avec le statut deleted : un nœud en pointillés et estompé marquant l'endroit où il se trouvait. Le graphe de Trailmark ne peut pas représenter cela par lui-même (il ne reflète que l'arbre tel qu'il est actuellement), donc zairo détecte les suppressions séparément : il analyse aussi les fichiers modifiés tels qu'ils existaient à --base (ou HEAD, si --base n'a pas été donné) et fait le diff des deux ensembles de symboles. Une fonction supprimée n'est jamais envoyée au scanner LLM (il ne reste aucun code vivant à analyser), donc elle ne porte que son nom, son type et son ancien emplacement, jamais de résultats.

Contrôle CI / PR

--fail-on <low|medium|high|critical> sort avec un code non nul si un résultat à cette sévérité ou au-dessus est trouvé (sur tous les dépôts combinés, en mode multi-dépôts), afin qu'une étape CI puisse bloquer une fusion sur cette base. Quelques points à connaître :

• Il génère une erreur s'il est combiné avec --graph-only (il n'y aurait rien sur quoi contrôler).
• Il ne supprime jamais la sortie SARIF : celle-ci est toujours écrite même en cas d'échec du contrôle, afin qu'une interface d'analyse reflète l'état actuel dans les deux cas.

Voir examples/github-actions/zairo-pr-scan.yml pour un workflow complet d'analyse de PR : il exécute zairo sur le diff de la PR, téléverse report.sarif vers le code scanning de GitHub, et fait échouer le job si le contrôle échoue.