hwipit/plugin

Hwip Auto — Mode de Travail Autonome Chronométré

Travaillez de manière autonome pour une durée fixe : explorer → planifier → implémenter → vérifier → valider, une unité à la fois. L'utilisateur oriente depuis son téléphone via les boutons hwip_ask ; lorsqu'il ne répond pas, vous poursuivez avec un repli sûr par défaut sans bloquer. Toute la session se déroule en une seule réponse — terminer votre tour met fin au mode.

Préconditions — refuser de démarrer si non remplies

• Un hook id est configuré — hookId dans ~/.hwip/config.json (ce que hwip install écrit), ou la variable de remplacement HWIP_HOOK_ID. Le contexte SessionStart se termine par Mode: two-way (notify + ask) lorsqu'il est présent ; Mode: one-way signifie qu'aucun canal de pilotage n'existe — refusez et redirigez l'utilisateur vers /hwip-config.
• Ne pas être en mode muet. Si /hwip-mode indique NOTIFICATIONS: muted, refusez : le mode autonome sans notifications est un travail non supervisé sans pilotage. Suggérez /hwip-mode unmute.
• Invocation explicite par l'utilisateur. Ne vous déclenchez jamais vous-même parce qu'une tâche « semble longue ». L'utilisateur opte avec /hwip-auto ....

Arguments

/hwip-auto [durée] [description de la tâche...]

• durée — 2h, 90m, 1h30m, ou un nombre nu signifiant des minutes. Par défaut : 1h. Limité à 10m–8h.
• tâche — tout ce qui suit la durée. Si omis, déduisez-la de la conversation en cours ; s'il n'y en a pas, proposez 2–3 tâches candidates dans la demande de démarrage (ex. corriger des tests qui échouent, effacer les avertissements lint, une revue des TODOs).

Configuration

1. Enregistrez l'échéance (un fichier d'état survit à la compaction du contexte — relisez-le si vous n'êtes pas sûr du temps restant) :

   HASH=$(printf '%s' "${CLAUDE_PROJECT_DIR:-$(pwd)}" | cksum | cut -d' ' -f1)
   STATE_DIR="${XDG_STATE_HOME:-$HOME/.local/state}/hwip"
   mkdir -p "$STATE_DIR"
   MINUTES=120   # parsé depuis l'argument durée
   DEADLINE=$(( $(date +%s) + MINUTES * 60 ))
   printf '%s %s\n' "$DEADLINE" "$MINUTES" > "$STATE_DIR/auto-$HASH"
   date -r "$DEADLINE" 2>/dev/null || date -d "@$DEADLINE"   # macOS | Linux
   

2. Protection des branches — ne travaillez jamais directement sur main/master/develop :

   BRANCH=$(git branch --show-current 2>/dev/null)
   case "$BRANCH" in
     main|master|develop) git checkout -b "auto/$(date +%Y%m%d)-<slug-tâche>" ;;
   esac
   

3. Découvrez le vérificateur avant d'écrire du code : les vérifications déterministes du projet (tests / lint / vérification de type / commandes de build depuis package.json, Makefile, configuration CI). Celles-ci conditionnent chaque validation. Si le projet n'en a aucune, dites-le dans la demande de démarrage et considérez « le code compile / s'exécute » comme le seuil minimal.

4. Demande de démarrage — un hwip_ask avant de toucher à quoi que ce soit :

   • title : "Mode auto : <tâche> ()"
   • body : plan en 2–3 lignes + quel vérificateur conditionne les validations + le nom de la branche
   • actions : [{id:"start", label:"Démarrer", style:"primary"}, {id:"stop", label:"Annuler"}] (si la tâche était ambiguë, remplacez "Démarrer" par 2–3 boutons de tâches candidates)
   • placeholder : "ajuster le plan ou le périmètre..."
   • timeout : 180, fallback : "start" (ou la candidate recommandée)

   Les réponses en texte libre amendent le plan ; stop annule le mode (supprimez le fichier d'état).

La Boucle

Divisez la tâche en unités : les plus petits blocs vérifiables et validables de manière indépendante (~15–45 min chacun). Ensuite, pour chaque unité :

1. Vérification du temps (avant de commencer chaque unité) :

   HASH=$(printf '%s' "${CLAUDE_PROJECT_DIR:-$(pwd)}" | cksum | cut -d' ' -f1)
   read -r DEADLINE MINUTES < "${XDG_STATE_HOME:-$HOME/.local/state}/hwip/auto-$HASH"
   echo "restant : $(( (DEADLINE - $(date +%s)) / 60 ))m sur ${MINUTES}m"
   

   Si le temps restant est inférieur au seuil de clôture — 10% du budget, au moins 5 minutes — ne commencez pas une nouvelle unité ; passez à la Clôture.

2. Explorer → planifier l'unité (lisez d'abord le code pertinent ; pas de modifications à l'aveugle).

3. Implémenter l'unité.

4. Vérifier avec les vérifications déterministes. Le vert est le seul signal de réussite — « a l'air correct » n'est pas un vérificateur, et n'affaiblissez ni ne supprimez jamais un test qui échoue pour obtenir le vert. En cas d'échec, corrigez et revérifiez, au maximum 3 tentatives ; si toujours rouge, annulez les modifications de l'unité (git checkout -- <fichiers> / git stash) pour que l'arbre reste propre, enregistrez-la comme ignorée, et passez à la suivante.

5. Valider l'unité verte avec un message clair conventionnel. NE POUSSEZ PAS.

6. Battement de cœur — après une validation, un court hwip_notify ("✅ <unité> — m restant"), mais au maximum un toutes les ~15 minutes ; regroupez les petites unités. Les blocages sont une exception : envoyez immédiatement une notification avec priority: "high" dès qu'un blocage apparaît.

Répétez jusqu'à ce que les unités soient terminées ou que le seuil de clôture soit atteint.

Protocole de Questions — ne jamais bloquer, ne jamais détruire

Les questions en cours de session passent par hwip_ask (jamais AskUserQuestion, jamais en texte brut — les règles 3/10 de CORE_RULES s'appliquent) :

• Mettez la recommandation par défaut en premier, notez dans le corps qu'elle passe automatiquement en cas de timeout, définissez timeout: 180 (jusqu'à 600 pour les décisions vraiment importantes) et fallback sur l'id de cette recommandation.
• Enregistrez chaque décision résolue par repli — le rapport final les liste pour que l'utilisateur puisse auditer ce qui a été décidé sans lui.
• Toute réponse est une instruction directe : appliquez-la immédiatement. Une réponse stop (ou un message mettant fin à la session) signifie clôturer maintenant.
• Les actions irréversibles ou tournées vers l'extérieur ne sont jamais éligibles au repli : push, PR/publication, déploiement, suppression de données, suppression de schémas, opérations forcées, tout ce qui est en dehors de l'arbre de travail. Pour celles-ci, le repli DOIT être skip — en cas de timeout, vous ignorez l'action et la notez, vous ne l'exécutez pas. Seul un clic explicite sur un bouton l'autorise.

Clôture

1. Terminez ou annulez l'unité en cours (même règle de 3 tentatives — ne laissez jamais l'arbre rouge ou sale).
2. Supprimez le fichier d'état : rm -f "${XDG_STATE_HOME:-$HOME/.local/state}/hwip/auto-$HASH".
3. Rapport final dans votre texte de réponse : unités terminées (avec les hashs de validation), unités ignorées et pourquoi, chaque décision résolue par repli, et ce qui reste.
4. Demande finale :
   • actions : [{id:"extend", label:"+30m"}, {id:"review", label:"Revoir"}, {id:"done", label:"Terminé", style:"primary"}]
   • timeout : 300, fallback : "done"
   • extend → écrivez une nouvelle échéance (+30m) dans le fichier d'état et rentrez dans la boucle ; review → parcourez le diff ; done → terminez.

En Cas de Problème

• Pas de hook id (Mode: one-way) — les outils bidirectionnels ne sont pas disponibles ; le mode automatique ne peut pas fonctionner. Exécutez /hwip-config pour le configurer.
• Fichier d'état manquant en cours de session (ex. répertoire d'état effacé) : considérez l'échéance comme immédiate — clôturez plutôt que de deviner le budget restant.
• L'utilisateur tape dans le terminal en cours de session : ce message est une entrée de pilotage, comme une réponse hwip_ask. Appliquez-la et continuez la boucle.
• Vérificateur instable (la même commande alterne vert/rouge sans changement) : ne gaspillez pas de tentatives en réexécutions — signalez-le comme un blocage via hwip_notify (priority: "high") et passez à l'unité suivante.