ADR 0092 – Inbox préremplie

Statut : Accepté (2026-10-17, fil B du jalon 4, cadre : ADR 0086, devinettes : ADR 0090)

Une capture sans marque entre dans l’Inbox sans rien de reconnu. L’assistant garde ses devinettes avec le nœud et l’Inbox les montre : on accepte d’un geste (ou tout ce qui est sûr d’un coup) au lieu de rouvrir « Classer comme… » pour chaque élément.

Décision

Suggestions gardées. Migration V16__inbox_suggestions.sql : node.inbox_suggestions (JSONB, null par défaut). À la capture d’un nœud d’inbox non typé, les devinettes non acceptées y sont écrites ({items: [CaptureItem…]}). C’est une donnée dérivée : ni événement node_event, ni updated_at, vidée à la sortie de l’inbox (NodeService.setInbox(false)), absente de l’export. Un nœud sans suggestions gardées (fichier déposé, capture ancienne) les voit calculées au premier affichage d’après son titre, puis gardées.

Lecture. GET /api/nodes/{id}/suggestions?refresh= → {type, typeLabel, items[], autoAccept}. Les champs que le nœud renseigne déjà sont retirés ; type n’est proposé que pour un nœud sans type (celui de la syntaxe de capture) ; refresh=true recalcule d’après le titre actuel et les règles actuelles.

Acceptation par l’API des lots. BulkKind.ACCEPT_SUGGESTIONS (fields facultatif : champs choisis ; onlySure : seulement les valeurs de confiance ≥ autoAccept). Par nœud, dans une seule transaction (InboxSuggestionService.accept est @Transactional : une erreur à un pas défait les précédents, le nœud reste typé comme avant et dans l’Inbox) : changeType (aspects obligatoires manquants alimentés par les valeurs acceptées, ADR 0015), puis patchAspect ou putAspect pour les autres aspects, puis sortie de l’inbox. Un refus (champ requis manquant, transition interdite) est rendu dans failures sans arrêter les autres. Sans rien à accepter, le nœud est rendu tel quel (compté « inchangé »).

Garde. Un nœud qui n’est plus dans l’Inbox (classé ailleurs, onglet périmé) est rendu tel quel : accepter ne préremplit que l’Inbox.

Annuler. Le lot garde l’état d’avant (type, données de chaque aspect porté, aspects ajoutés) : l’annulation, elle aussi en une transaction par nœud, rétablit le type, retire les aspects ajoutés, rend aux autres leurs données et remet le nœud dans l’inbox.

Interface (features/inbox). Chaque ligne affiche le type suggéré et un bouton à bascule par champ avec sa confiance (puces de l’ADR 0091), « Accepter » (tout, ou les champs retenus) et « Recalculer » ; en tête, « Accepter les sûrs (n) » (la sélection cochée sinon tous les éléments affichés). Les suggestions se chargent par ligne visible, trois lectures simultanées au plus. Les lots passent par le retour d’information existant (résumé, « Annuler », refus).

Alternatives écartées

• Appliquer les devinettes à la capture : contraire à ADR 0086 (l’assistant suggère).
• Ne rien garder et tout recalculer : correct mais les règles changent ; le résultat montré à la capture serait différent de celui de l’Inbox. Les suggestions gardées restent aussi disponibles à un futur étage (plongements, B5) coûteux à recalculer.
• Écrire un node_event pour les suggestions : elles ne sont pas le contenu du nœud ; l’acceptation, elle, écrit les événements habituels.

Limites connues

• La puce « Type » n’est pas sélectionnable seule : le type s’accepte avec « Accepter » sans champ choisi, ou avec les sûrs.
• Une acceptation partiellement refusée laisse des suggestions périmées jusqu’à « Recalculer » ou au prochain affichage.
• L’annulation ne retire pas ce que l’assistant a appris de l’acceptation (ADR 0093).