⚙️ Workflow : Human-in-the-loop de bout en bout

Un agent custodien doit être autonome dans l’analyse, mais conservateur dans l’action. Le workflow ci-dessous garde cette séparation nette.

Cycle complet

Déclencheur : manuel, cron, webhook GitHub, nouveau fichier ou audit planifié.
Préflight : vérifier branche, état Git, règles, plan actif et dossiers à ignorer.
Exécution : lire, auditer, générer corrections ou rapport.
Isolation : créer une branche dédiée ou produire un patch non appliqué.
Rapport : résumer les changements, sources, risques et vérifications.
Validation humaine : revue du diff, questions, corrections.
Merge : seulement après accord explicite.
Publication : build + déploiement, séparés du travail d’édition.

Niveau	Nom	Ce que l’agent peut faire	Risque
0	Report-only	Lire et produire un rapport	Très faible
1	Patch proposal	Générer un patch ou plan	Faible
2	Branch	Modifier une branche dédiée	Moyen
3	PR	Ouvrir une PR avec description	Moyen
4	Staging	Déployer en préproduction	Élevé
5	Publish	Publier en production	À éviter sans humain

Pour ce vault, le niveau raisonnable est 2 ou 3 : branche/PR, validation humaine, puis merge.

Avant chaque run :

Vérifier que le repo est propre (git status --porcelain) : si le repo est dirty (modifications non commitées), l’agent doit avorter et notifier l’opérateur. Il ne doit jamais embarquer un brouillon humain en cours dans son commit. Exception explicite uniquement : git stash avec un nom horodaté si l’opérateur a activé ce mode dans la configuration de l’agent.
vérifier que le plan de maintenance actif est à jour (dans ce vault : répertoire .cursor/plans/ du dépôt) ;
ignorer _private/, build/, dist/, .git/ et les logs obsolètes ;
refuser les commandes destructrices ;
citer les sources pour tout changement factuel.

Pour un run avec livraison git, la PR (description + diff) est la trace principale. Sinon, un rapport en chat suffit :