Aller au contenu

Plan

ht plan est le côté agent du panneau plan. L’agent publie un plan étape par étape (Explore → Implement → Test → Commit), garde les états des étapes à jour, et le widget de la barre latérale τ-mux le rend en direct pour l’utilisateur. Chaque plan est indexé par (workspaceId, agentId?) pour que plusieurs agents dans le même espace de travail restent isolés.

ÉtatGlypheSignification
done✓Étape terminée.
active●Étape en cours (une par plan, par convention).
waiting○Pas encore commencée.
err✗L’étape a échoué ; l’agent doit signaler.

Le CLI affiche ces glyphes en couleur lorsque stdout est un TTY.

Fenêtre de terminal
ht plan list
ht plan list --json

Affiche chaque plan actif dans le PlanStore côté bun. Sans --json, chaque plan se rend ainsi :

ws:5 claude:1
✓ M1 Explore code
● M2 Implement fix
○ M3 Run tests
○ M4 Commit
Fenêtre de terminal
ht plan set --workspace ws:5 --agent claude:1 --json '[
{"id":"M1","title":"Explore","state":"done"},
{"id":"M2","title":"Implement","state":"active"},
{"id":"M3","title":"Test","state":"waiting"},
{"id":"M4","title":"Commit","state":"waiting"}
]'

Remplace le plan pour (workspaceId, agentId?). Les étapes arrivent comme un tableau JSON ; chaque entrée nécessite au minimum id et title (l’état vaut waiting par défaut). Réémettre set est la manière canonique de réécrire un plan — update ne corrige qu’une étape à la fois.

OptionRôle
--workspace <id>Espace de travail cible. Optionnel à l’intérieur d’un panneau τ-mux (le serveur résout l’espace de travail à partir de HT_SURFACE) ; requis depuis un shell hors panneau, ou passez HT_WORKSPACE_ID.
--agent <id>Optionnel. Permet à plusieurs agents dans le même espace de travail de posséder des plans séparés.
--json '<steps>'Le tableau complet des étapes (requis).

Le CLI parse votre JSON localement et le transmet tel quel — un JSON invalide sort avec un code non nul avec une erreur de parsing avant d’atteindre le socket.

Fenêtre de terminal
ht plan update M2 --workspace ws:5 --agent claude:1 --state done
ht plan update M2 --workspace ws:5 --title "Implement fix v2"
ht plan update M3 --workspace ws:5 --state active

Corrige une seule étape. --state accepte done|active|waiting|err. --title remplace le titre de l’étape. L’une ou l’autre, ou les deux, peuvent être passées.

Lorsque l’étape nommée n’existe pas, le CLI affiche (no plan) — pas une erreur, juste un signal que le patch a manqué. update contre un plan obsolète ne plante jamais.

Fenêtre de terminal
ht plan complete --workspace ws:5 --agent claude:1

Marque chaque étape done en un seul appel. Utile comme signal « j’ai terminé » de l’agent — combiné avec plan clear, cela donne aux scripts un chemin propre de fin et de démontage :

Fenêtre de terminal
trap 'ht plan complete' EXIT # inside a τ-mux pane, no flags needed
Fenêtre de terminal
ht plan clear --workspace ws:5 --agent claude:1

Supprime entièrement le plan. Renvoie :

  • ok (plan removed) — le plan existait et a été supprimé.
  • (no plan to clear) — rien n’était enregistré pour cette clé.

Les clés ht set-status dont le nom contient « plan » et dont la valeur est un tableau JSON d’objets {id, title, state} sont automatiquement reflétées dans le PlanStore typé — les agents qui publient déjà des checklists via le système intelligent de clés de statut allument le panneau plan gratuitement, sans appel ht plan requis :

Fenêtre de terminal
ht set-status build_plan '[{"id":"compile","title":"Compile","state":"active"}]'
# → both the sidebar smart-key renderer AND the plan panel update.

Le pont dérive l’agentId du plan à partir de la surface (status:<surfaceId>) pour que chaque surface obtienne sa propre carte de plan.

VariableRôle
HT_SURFACEAuto-défini dans les panneaux τ-mux. Le serveur résout l’espace de travail propriétaire à partir de celui-ci, donc --workspace est optionnel à l’intérieur d’un panneau.
HT_WORKSPACE_IDRemplacement explicite optionnel. Pas auto-défini — exportez-le manuellement si vous voulez qu’un shell hors panneau utilise par défaut un espace de travail spécifique.