ADR 0026 – États finaux du workflow et sous-tâches

Statut : Accepté (2026-10-15, mode autonome)

Décisions prises en mode autonome (Aurélien, 2026-10-15 : options les plus simples, sûres et réversibles).

Contexte

Le cahier demande des sous-tâches « avec progression calculée » et des dépendances « bloqué par ». Les deux supposent de savoir quand une tâche est terminée, ce qui ne se déduit pas des transitions : fait → a-faire existe pour rouvrir une tâche. La hiérarchie des nœuds (ADR 0007) n’a qu’un parent ; une sous-tâche est donc un enfant.

Décision

workflow.final

workflow:
  field: statut
  transitions: { … }
  final: [fait, abandonne]

La clé final est facultative. Elle liste des états de l’énumération ; le chargeur refuse un état inconnu. Pour tache, une tâche abandonnée compte comme terminée : elle ne bloque plus rien et n’attend plus rien. Workflows.statusOf donne l’état d’un nœud (premier aspect à workflow dans l’ordre des noms, ADR 0024) et indique s’il est final.

Progression calculée à la lecture

GET /api/nodes/tree ajoute à chaque ligne :

• done : l’état est final ;
• childrenTracked : le nombre d’enfants hors corbeille qui ont un état ;
• childrenDone : le nombre de ces enfants dont l’état est final.

GET /api/nodes/{id} porte la même progression (progress: { tracked, done }), sans limite d’enfants. La fiche ne dépend donc pas du panneau de contexte, fermé sur mobile.

Le calcul se fait en SQL, en une requête par niveau affiché et sans stockage. Seul le champ d’état est extrait du JSONB (data ->> champ), les noms d’aspects et de champs venant des définitions et passés en paramètres. Les états sont ensuite comptés par parent ; Java ne fait que le test final. Les rollups matérialisés restent au jalon 3. Un enfant sans état, comme une note jointe à une tâche, n’entre pas dans le compte.

Interface

• Arbre : la méta d’une ligne devient « état · terminés/suivis » (par exemple « en-cours · 2/3 »), et un nœud terminé est barré.
• Section Sous-nœuds du panneau de contexte :
  • le compte devient « 2/3 », avec une barre de progression (role="progressbar") ;
  • les enfants terminés sont barrés ;
  • un bouton « + » crée un enfant du même type, par exemple « + Tâche », à côté de « Nouveau sous-nœud ». Il n’apparaît que si ce type impose un aspect à workflow ;
  • la progression affichée est celle du serveur (tous les enfants) ; un lecteur d’écran entend « 2 terminés sur 3 ».
• Fiche : une ligne « Progression » s’ajoute dans les propriétés, avec une barre et « 2 terminés sur 3 ». Elle n’apparaît que si au moins un enfant a un état. Le libellé est neutre, car la progression vaut pour tout workflow déclaré.

Alternatives écartées

• Déduire « terminé » des états sans sortie : fait en a une (rouvrir).
• Progression stockée sur le parent : il faudrait la tenir à jour à chaque écriture d’un enfant, ce que les règles du jalon 3 feront proprement.
• Lien typé « sous-tâche de » : il doublerait la hiérarchie, alors que l’arbre, le fil d’Ariane et le dépôt de fichiers en profitent déjà.

Conséquences

• La progression ne compte que les enfants directs : les petits-enfants ne remontent pas.
• La section Sous-nœuds liste au plus 200 enfants, mais sa progression porte sur tous.
• Les dépendances « bloqué par » (ligne suivante du jalon 2) s’appuieront sur done.