ADR 0064 – Score d’urgence

Statut : Accepté (2026-10-16, mode autonome ; ligne 32 du backlog, prise sur la recommandation du fil coordinateur)

La ligne 32 du backlog (jalon 3, vague 2) demande un score d’urgence : un nombre qui classe les tâches de la plus pressante à la moins pressante. Il combine l’échéance, la priorité, le blocage… à la manière de Taskwarrior. Les vues trient aujourd’hui par un champ à la fois (échéance, puis priorité), ce qui place une tâche de faible priorité due demain avant une tâche urgente due après-demain.

Le moteur ne connaît pas les tâches. Le score se déclare donc dans config/, comme la prochaine action (ADR 0037).

Décision

Déclaration : clé d’aspect urgency

# config/aspects/tache.yaml
urgency:
  field: urgence          # nom du champ calculé : tache.urgence dans les vues
  label: Urgence
  terms:                  # points ajoutés quand la condition est vraie (langage des vues, ADR 0028)
    - { when: "tache.echeance < today", points: 12 }                         # en retard
    - { when: "tache.echeance >= today && tache.echeance <= today + 2d", points: 8 }
    - { when: "tache.echeance > today + 2d && tache.echeance <= today + 7d", points: 4 }
    - { when: "tache.priorite == 'haute'", points: 6 }
    - { when: "tache.priorite == 'basse'", points: -2 }
    - { when: "tache.statut == 'en-cours'", points: 3 }
    - { when: "blocked", points: -5 }

• Calcul. Le score est la somme des points des conditions vraies. C’est un entier, de 0 si aucune ne l’est. Un nœud qui ne porte pas l’aspect n’a pas de score.
• Conditions. Elles utilisent le langage fermé des vues, avec les champs de l’aspect et ceux du nœud (blocked, createdAt, updatedAt, title). Le score ne peut pas citer le score lui-même. Une tâche terminée garde ses points (un retard reste un retard) : ce sont les vues qui écartent les états finaux, comme urgentes et taches-ouvertes.
• Contrôles au chargement.
  • les conditions sont analysées et typées comme un when d’action rapide (ADR 0041) ;
  • le nom du champ ne recouvre ni une propriété du schéma ni le champ de la prochaine action ;
  • de 1 à 20 termes ;
  • des points entiers entre -100 et 100, non nuls.
• Évaluation. En SQL, au moment de la requête : une somme de case when … then points else 0 end. Le score est donc toujours à jour (today compris) sans rien stocker, et il se trie et se filtre côté serveur.

Dans les vues

tache.urgence est un champ comme un autre des vues, à ceci près qu’il n’est pas modifiable. Il n’est pas admis hors des vues : ni dans le when d’une action rapide (le blocage n’y est pas calculé), ni comme critère de tri de la prochaine action (ADR 0037).

• en colonne (nombre) ;
• en tri : sort: [tache.urgence desc] ;
• en condition : where: "tache.urgence >= 10" ;
• dans une mise en forme conditionnelle (ADR 0040).

La vue taches-ouvertes trie désormais par urgence, puis par échéance. Une vue « Les plus urgentes » (urgentes, liste, 15 premières) montre le score.

Reporté

• Afficher le score sur la fiche du nœud, avec le détail des points qui le composent.
• Termes pondérés par une valeur (points × jours de retard) plutôt que des paliers.
• Score sur plusieurs aspects à la fois (projet et tâche).

Conséquences

• Le classement se règle dans config/aspects/tache.yaml, sans code. Changer les points change le tri au rechargement.
• Une vue triée par urgence évalue les conditions sur toutes ses lignes. C’est négligeable aux volumes d’un usage personnel, mais des index d’expression seraient à envisager si les volumes grandissent.