ADR 0107 – Rituel du matin et du soir

Statut : Accepté (2026-10-17, vague 3 du document d’idées)

« Planifier la journée » (ADR 0070) additionne les estimations d’une vue et prévient au-delà d’une capacité, mais ne guide pas : on regarde, on déplace à la main. Un assistant en étapes prolonge cette idée : le matin on choisit ce qu’on fait aujourd’hui, le soir on solde la journée et on reporte le reste.

Décision

Configuration : clé ritual d’un dashboard

# config/dashboards/maintenant.yaml
ritual:
  eveningFrom: 17              # heure locale à partir de laquelle la page propose le soir
  date: tache.echeance         # champ date écrit pour planifier ou reporter
  sum: tache.estimation        # champ nombre (minutes) additionné
  capacity: 360                # minutes disponibles par jour
  morning:                     # vues proposées le matin (1 à 4), dédoublonnées dans l'ordre
    - { view: aujourdhui, label: Du jour }
    - { view: taches-en-cours, label: En cours }
  evening: aujourdhui          # vue des tâches ouvertes à reporter le soir

• Toutes les valeurs sont dans config/ : aucune capacité, heure ni nom de vue ou de champ dans le code. Le rituel est lu sur le dashboard d’accueil, sinon le premier dashboard qui en déclare un (findRitual).
• Contrôles au chargement (DefinitionLoader.checkRitual, méta-schéma) : date est un champ date d’aspect, sum un champ nombre (pas un score calculé), les vues existent et portent date et sum parmi leurs colonnes (la page lit les valeurs des lignes reçues, comme le widget « Aujourd’hui »). Un dashboard invalide est ignoré et signalé par /api/definitions/status, sans faire tomber l’application. eveningFrom 0 à 23, capacity ≥ 1, tous deux obligatoires : pas de valeur cachée dans le code.
• Une vue de plus dans config/ : taches-en-cours (tâches au statut « en cours », mêmes colonnes que aujourdhui).

Page /rituel

Page chargée à la demande, commande de palette « Rituel du matin et du soir » (proposée seulement si un rituel est configuré). Matin ou soir selon l’heure locale (eveningFrom), forcé par ?moment=matin|soir ou par les boutons Matin / Soir. Assistant en deux étapes, avec un fil des étapes.

• Matin : 1. Choisir : les tâches des vues morning (une seule fois chacune, étiquetée par sa source), cases à cocher ; les tâches déjà dues (date aujourd’hui ou passée) sont cochées au départ, les tâches en cours se choisissent. Barre de charge (splitLoad, ADR 0088) et « 2 h 30 retenues sur 2 h · 30 min de trop », avertissement au-delà de la capacité (sans bloquer). 2. Planifier : récapitulatif ; « Planifier la journée » écrit la date du jour dans les tâches cochées qui ne l’ont pas déjà (replanification, ADR 0038 : PATCH /api/nodes/{id}/aspects/{aspect}, validation, workflow et node_event du serveur) ; option « Reporter à demain les tâches échues non retenues » (décochée au départ).
• Soir : 1. Bilan : terminés, créés et modifiés aujourd’hui (GET /api/journee, ADR 0067), avec la liste des tâches terminées. 2. Reporter : les tâches de la vue evening encore ouvertes, toutes cochées ; choix « Demain » ou « Dans une semaine » ; « Reporter N tâches » écrit la nouvelle date par la même replanification. Les tâches décochées ne sont pas touchées.
• Les écritures passent par reschedule (quatre requêtes en parallèle, erreurs par tâche affichées) et rafraîchissent les widgets de l’accueil (DashboardRefresh). Aucune nouvelle route serveur.
• Page de repli sans rituel configuré : message qui renvoie à la clé ritual.

Alternatives écartées

• Nouveau type de définition config/rituals/ : un chargeur, un registre et une route de plus pour un seul jeu de valeurs ; la clé d’un dashboard réutilise le chargement, le contrôle des vues et l’API existants, au prix de dépendre d’un dashboard (acceptable : le rituel prolonge la page d’accueil).
• Étendre les revues guidées (config/reviews/) : une revue montre des vues à parcourir, pas des choix cochés ni une charge ; le mélange alourdirait son modèle.
• Écrire dans une opération groupée serveur (API des lots) : donnerait « Annuler » mais pas besoin ici (la replanification est rejouable depuis la page ou la fiche) ; peut s’ajouter plus tard sans changer la configuration.
• Reporter « Un jour peut-être » depuis le soir : action rapide propre à un aspect (rang dans l’aspect), non générique ; les deux reports de date suffisent.

Limites connues

• Le rituel ne mémorise pas qu’il a été fait : on peut le rejouer ; les tâches déjà planifiées pour aujourd’hui sont simplement recochées.
• Deux vues sont supposées renvoyer des tâches du même aspect que date (sinon une tâche sans cet aspect est ignorée à l’écriture).
• La capacité est la même chaque jour (pas de jour férié ni de capacité réduite).

Corrections de la revue

• Règle d’écriture des dates : le rituel n’écrit jamais une date antérieure à la date actuelle de la ligne et ne ramène jamais une échéance à venir à aujourd’hui. Le matin, toToday ne concerne que les lignes cochées sans date ou en retard (date < aujourd’hui) ; une date d’aujourd’hui ou à venir n’est pas touchée (« garde sa date » dans le récapitulatif). Le soir, seules les lignes dont la date est définie et ≤ aujourd’hui sont proposées et reportées ; les autres ne sont pas touchées. Les choix de report ont un décalage d’au moins 1 jour. Le résumé du matin compte les dates réellement écrites.
• Choix de report dans config/ : clé obligatoire ritual.carry: [{ label, days }] (1 à 4 choix, days 1 à 365). Le méta-schéma et DefinitionLoader.checkRitual refusent un décalage inférieur à 1, un décalage ou un libellé en double ; plus de constante dans le code (CARRY_CHOICES retiré). Les textes de la page sont neutres (« éléments », « échus »), sans vocabulaire propre à l’aspect tache.
• Chargements désordonnés : un jeton de génération dans load_ ignore la réponse d’un chargement plus ancien ; les boutons Matin / Soir sont désactivés pendant une écriture. L’état d’erreur propose « Réessayer ».
• selectionLoad (inutilisé : la page calcule la charge par splitLoad) est retiré.