Vous avez lancé une correction sur votre ordinateur et devez vous éloigner. Le besoin n'est pas de relire tout un dépôt sur un petit écran : vous voulez comprendre l'avancement, débloquer une décision et recevoir les preuves nécessaires avant de publier. Pacerelle peut servir de conversation distante avec votre assistant de code.
Connecter l'assistant qui travaille déjà
Si votre environnement de code possède un hôte MCP, ajoutez le serveur Pacerelle et maintenez une session d'écoute. L'assistant continue d'utiliser les outils, le compte Git et les permissions de cet environnement. Pacerelle ne crée pas automatiquement des commits ou des pull requests.
Avant de partir, envoyez une demande en lecture seule : « Donne la branche courante, les fichiers déjà modifiés et la commande de test prévue. » Ce contrôle établit le contexte. Si la session de l'hôte s'arrête ou attend une validation locale, l'agent doit le signaler ; une application mobile ne supprime pas cette contrainte.
Donner une correction qui se vérifie
Une bonne demande décrit un comportement observable : « Sur le formulaire de contact, empêcher l'envoi avec une adresse invalide, afficher l'erreur près du champ et vérifier qu'une adresse valide fonctionne encore. » Ajoutez les limites : fichiers autorisés, changements déjà présents à préserver et actions nécessitant votre accord.
Avant la modification, l'assistant examine l'état Git et choisit un espace isolé si nécessaire. Il ne doit pas nettoyer le dépôt avec une commande qui efface votre travail. Une branche dédiée sépare l'historique ; un worktree peut aussi séparer les fichiers lorsque plusieurs tâches se déroulent en parallèle.
Demander un compte rendu utile sur mobile
- Ce qui est corrigé, avec le comportement avant et après.
- Les fichiers concernés et le lien vers le diff ou la pull request si elle existe.
- Les contrôles exécutés, leur résultat et ce qu'ils ne couvrent pas.
- Les blocages et décisions encore nécessaires.
- La prochaine action proposée : poursuivre, ouvrir une PR, publier ou attendre une revue.
Une commande de test qui retourne un code d'échec doit rester un échec dans le résumé. Une commande interrompue n'est pas un test réussi. Pour une interface, demandez aussi un essai du parcours réel et du rendu mobile ; un test unitaire ne prouve pas que le bouton est accessible à l'écran.
Séparer correction et publication
L'autorisation de modifier un fichier ne signifie pas toujours autorisation de fusionner ou de déployer. Définissez cette limite dès la demande. Si une décision est nécessaire, elle doit porter sur un commit ou un diff précis et sur l'environnement visé.
Si l'assistant ajoute des changements après votre accord, le contenu à publier a changé. Il faut réévaluer la décision au lieu de réutiliser une ancienne confirmation. Les autorisations Pacerelle montrent comment lier un accord à une opération ; dans un hôte MCP, les contrôles de l'hôte restent également applicables.
Reprendre sans perdre ni doubler le travail
Faites enregistrer la branche, le dernier commit, les changements non commités, les tests effectués et la prochaine étape dans un checkpoint. À la reprise, l'agent doit comparer ce résumé à l'état réel du dépôt. Un autre développeur peut avoir changé la branche entre-temps.
Testez le parcours sur une petite correction : lecture de l'état, modification, test volontairement en échec puis réparation, revue du diff et arrêt avant publication. Vous avez réussi lorsque le résumé mobile correspond aux fichiers et aux résultats réels. Si vous ajoutez un second agent relecteur, gardez la même exigence de preuve décrite dans le guide de collaboration.
Suivre votre prochaine petite correction
Reliez votre hôte MCP et commencez par demander l’état du dépôt, sans modification.