Second Brain documentation

ADR 0025 – Report rapide : boutons déclarés par l'aspect, appliqués par le serveur

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

← Toutes les décisions

ADR 0025 – Report rapide : boutons déclarés par l’aspect, appliqués par le serveur

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

Ces décisions ont été prises en mode autonome, à la demande d’Aurélien du 2026-10-15 : retenir les options les plus simples, sûres et réversibles. Le cahier demande des boutons « demain », « semaine prochaine » et « un jour peut-être » sur les tâches, sans module dédié : tout passe par les aspects.

Décision

Format : clé postpone d’un aspect

postpone:
  - { label: Demain, icon: today, set: { echeance: "{{today + 1d}}" } }
  - { label: Semaine prochaine, icon: date_range, set: { echeance: "{{today + 1w}}" } }
  - { label: Un jour peut-être, icon: snooze, set: { statut: plus-tard }, unset: [echeance] }

Chaque bouton (6 au plus) porte un label, une icon facultative et au moins un set ou un unset :

  • set écrit des valeurs, avec les variables {{today}} et {{now}} et un décalage ± N d|w|m (ADR 0016) ;
  • unset retire des champs.

Le chargeur vérifie, sur le modèle des modèles de nœud :

  • les champs sont connus de l’aspect ;
  • aucun champ n’est une référence à un nœud ;
  • un champ retiré n’est pas requis et n’est pas écrit par le même bouton ;
  • les variables sont connues ;
  • les valeurs résolues sont conformes au schéma de l’aspect (champs requis exceptés).

Toute faute rend l’aspect invalide.

« Un jour peut-être » est un état (plus-tard, ajouté à l’aspect tache et à son workflow), pas une date lointaine. Une tâche « plus tard » sort ainsi des vues « à faire » sans perdre son état d’origine dans l’historique. Le choix vit dans config/ : un autre aspect pourrait reporter autrement.

Application : POST /api/nodes/{id}/aspects/{aspect}/postpone/{index}?zone=

Le serveur :

  1. résout les variables dans le fuseau du navigateur (zone, mêmes contrôles et messages qu’ailleurs, regroupés dans Zones.of) ;
  2. fusionne set dans les données de l’aspect porté ;
  3. retire unset ;
  4. enregistre par putAspect.

Une seule écriture applique donc tout ce que fait une modification d’aspect : JSON Schema, workflow (ADR 0023), événement aspect.updated avec l’avant/après, texte de recherche. Un bouton inconnu, ou un aspect non porté, renvoie 404. Une transition interdite renvoie 400 (aspects.tache.statut), sans écriture.

Le calcul est fait côté serveur, et non dans le navigateur avant un PUT :

  • une seule écriture atomique ;
  • les variables sont résolues par le même code que pour les modèles ;
  • les futures vues (kanban, liste, revue hebdomadaire) appelleront le même endpoint.

Fiche

Les boutons s’affichent à droite de l’intertitre de l’aspect, seulement s’il est déjà enregistré. Un clic écrit immédiatement, puis recharge le nœud. Il est refusé quand la page a des modifications non enregistrées (« Enregistrez d’abord vos modifications »), comme le changement de type : le rechargement les écraserait.

Alternatives écartées

  • Clé actions du jalon 3 : son format (handlers, conditions) n’est pas arrêté. Le report n’est qu’une écriture de champs, et une clé dédiée évite de figer actions trop tôt.
  • « Un jour peut-être » = échéance retirée seule : la tâche resterait « à faire » sans date, mélangée à celles qu’on a oublié de dater.

Conséquences

  • L’aspect tache gagne l’état plus-tard, avec ses transitions (depuis et vers a-faire et en-cours, vers fait et abandonne). Depuis fait ou abandonne, « Un jour peut-être » est refusé : il faut d’abord rouvrir la tâche.
  • Les vues du jalon 2 réutiliseront ces boutons (menu d’une ligne, carte de kanban).
  • La fusion de set est faite au premier niveau : un objet imbriqué est remplacé en entier.
  • Le report réécrit l’aspect entier : une donnée ancienne non conforme sur un autre champ le fait échouer en 400 sur ce champ, comme une modification ordinaire (valider à l’écriture).
  • Dans la fiche, un bouton dont set écrit le champ du workflow est désactivé quand la transition depuis l’état enregistré est interdite (« Un jour peut-être » sur une tâche faite). Le serveur refuse de toute façon.
  • Limite assumée : « Demain » ou « Semaine prochaine » sur une tâche plus-tard (ou faite) la date, sans changer son état. Elle reste hors des vues « à faire » tant qu’on ne la repasse pas à la main en a-faire. Une condition déclarative (when) sur les boutons relèvera des règles du jalon 3.

Amendement (2026-10-16, ADR 0041)

La clé postpone devient quickActions (actions rapides de tout aspect, avec une condition when). L’ancien nom reste lu, et l’endpoint …/postpone/{index} reste en service, marqué obsolète, à côté de …/actions/{index}.