Rendre la dépendance Git observable

Ce travail a commencé par une décision de frontière : l’incident Windows ne justifiait pas de remplacer les sémantiques Git du produit par une bibliothèque partielle. Il fallait d’abord rendre explicite et fiable la dépendance que Code Moniker possède réellement aujourd’hui. J’ai donc conservé la CLI Git, mais en faisant de sa résolution, de sa version, de ses délais et de ses échecs un contrat observable plutôt qu’une hypothèse d’environnement.

Le point le plus exigeant a été de maintenir deux invariants en même temps. Une sonde Git lente ou défaillante ne doit jamais retarder la disponibilité de l’index, tandis qu’une commande Git demandée explicitement ne doit jamais pouvoir bloquer indéfiniment ni laisser un processus descendant vivant. Sur Windows, cela a conduit à superviser Git dans le runtime Rust natif et à l’attacher à un Job Object avant de reprendre son exécution, au lieu de déduire la terminaison de délais fragiles côté Node.

La revue indépendante a surtout servi à durcir les cas qui semblaient secondaires mais conditionnent la fiabilité réelle : budget rapide pour version, status et rev-parse, invalidation d’un exécutable devenu inutilisable, cooldown calculé après la sonde, protocole de superviseur versionné et compilation du faux Git Windows avec l’outil réellement disponible en CI. Les règles d’architecture rendent désormais ces choix exécutables, afin qu’un futur appel Git non borné ou placé dans la readiness soit détecté comme une régression.