Diagnostic de build par IA

Les logs de build natif sont longs. Quand un build iOS (Xcode / Fastlane) ou Android (Gradle / Fastlane) échoue, Capgo peut passer le log à un ingénieur IA du build qui identifie ce qui a mal tourné et comment le corriger — pour que vous n’ayez pas à faire défiler des milliers de lignes vous-même.

L'activer

Ajoutez --ai-analytics à votre build :

bunx @capgo/cli@latest build request com.example.app --platform android --ai-analytics

Le diagnostic ne se déclenche que lorsqu'un build échoue — les builds réussis ne sont pas affectés.

Quand il s'exécute

Ce qui se passe en cas d'échec d'un build dépend de l'endroit où vous l'exécutez et de l'utilisation ou non du flag :

Environnement	--ai-analytics	Comportement
Terminal interactif	oui	Diagnostique l'échec immédiatement
Terminal interactif	non	Demande d'abord, puis propose le diagnostic
CI / non interactif	oui	S’exécute automatiquement et affiche le diagnostic sur stderr
CI / non interactif	non	Ignoré — rien n’est envoyé

Ainsi, en CI, vous devez opter pour l’envoi avec --ai-analytics ; dans un terminal, on vous demande toujours d’abord, sauf si le drapeau vous a déjà pré-autorisé.

Ce que vous obtenez

Un rapport markdown court et ciblé :

• Cause probable — une seule phrase.
• Preuves — les 1 à 3 lignes les plus pertinentes extraites de vos logs.
• Correction suggérée — des étapes numérotées pour modifier votre projet (config de signature, une capability manquante, un problème Gradle ou CocoaPods, un conflit de plugin, …).

Si les logs sont ambigus, l'IA le précise et liste les principales hypothèses au lieu d'inventer une erreur inexistante.

Vos logs, votre choix

Le diagnostic par IA est opt-in — rien n’est envoyé à moins que vous ne passiez --ai-analytics ou que vous confirmiez le prompt.

• Capgo IA (par défaut) : votre log de build est réduit et envoyé à l’endpoint d’analyse de Capgo (qui s’exécute sur Cloudflare Workers AI) juste le temps de produire le diagnostic. Les logs de build ne font pas partie du stockage normal — ils sont diffusés dans votre terminal pendant le build.
• Conserver les logs sur votre machine : dans un terminal interactif, vous pouvez plutôt demander à CLI d’écrire un fichier de prompt local — les mêmes instructions de diagnostic plus votre log — que vous collez dans votre propre LLM. Vos logs ne quittent jamais votre machine.

Remarque

L’analyse considère votre log de build comme des données non fiables, de sorte qu’une ligne de log ressemblant à une instruction (une tentative de prompt injection) ne peut pas détourné le diagnostic.