TEC-INT-006 — Idempotence commune différée

TEC-INT-006 — Idempotence commune, différée et opt-in

• Statut : valide
• Priorité : Must
• Sources : DEC-0061, DEC-0019, DEC-0050, DEC-0248
• Prescription : Elena doit prévoir un contrat d’idempotence réutilisable sur la plupart des commandes REST, sans l’activer par défaut. L’implémentation et la qualification de ce mécanisme commun sont différées à une passe dédiée après le gros du travail d’implémentation des API, lorsque leurs usages sont suffisamment connus.
• Raison fonctionnelle : prévenir les doubles effets sans imposer prématurément le coût du mécanisme sur des endpoints dont les usages ne sont pas encore établis.
• Contraintes et invariants :
  • pendant la phase principale, documenter la cible et éviter des contrats qui rendraient son ajout incompatible ; aucun middleware, registre générique, stockage ou code inactif n’est exigé immédiatement au seul titre de cette décision ;
  • le contrat commun n’est pas limité à la création d’identités : il doit pouvoir être adopté largement par les commandes API, natives ou personnalisées, selon leur sémantique ; les lectures GraphQL ne reçoivent pas ce mécanisme ;
  • lors de la passe dédiée, inventorier les usages et risques de double effet, qualifier le mécanisme et décider explicitement de l’activation commande par commande ; une option absente vaut désactivation, jamais activation globale implicite ;
  • pour une commande activée : même acteur, commande, clé et intention normalisée permettent reprise ou restitution du résultat sans nouvel effet ; même clé avec intention divergente produit un conflit ; une nouvelle opération volontaire utilise une nouvelle clé ;
  • les opérations concurrentes et interrompues sont gérées par un registre durable appartenant au module fournisseur, pas seulement par un verrou de cache. Les effets externes exigent une stratégie de reprise/réconciliation explicite ; aucune garantie magique d’exécution unique d’un système externe n’est déduite de la clé.
• Données : par commande activée, définir portée et format de clé, empreinte d’intention, états incomplets, résultat rejouable, durée de conservation et comportement après expiration ; aucune durée universelle n’est actée.
• Interfaces et événements : l’adoption doit être explicite et documentée dans le contrat API. Un endpoint non activé ne promet aucune déduplication par clé ; la simple présence d’un en-tête ne l’active pas. Le frontend/SDK doit connaître les capacités avant d’automatiser les reprises ; une corrélation n’est pas une clé d’idempotence.
• Sécurité et audit : revérifier les droits sur chaque rejeu avant de révéler un résultat ; isoler acteurs et commandes. Le report de la généralisation REST ne retire ni les protections existantes ni les obligations de rejeu sûr des jobs, d’effets obligatoires ou d’audit déjà prescrites.
• Exploitation : inscrire une passe post-implémentation principale API dans le plan, avec inventaire d’éligibilité, contrats par commande, réalisation, tests de panne et activation explicite. Aucun calendrier chiffré ou endpoint à activer n’est décidé ici.
• Vérification : VER-OPS-015
• Questions ouvertes : aucune
• Paramètres hors arbitrage : date de la passe, liste d’endpoints, forme concrète du mécanisme et paramètres par commande. La validation de la cible ne vaut ni livraison immédiate ni activation.
• Réalisation : la création d’identité comporte déjà un mécanisme spécifique ; cette décision n’en commande pas le retrait. Généralisation et conformité restent à démontrer.

Activation ciblée Lot 0 — DEC-0248

Le report général ci-dessus comporte une exception explicite : convertQuotation adopte le mécanisme commun pour satisfaire DEC-0195. Sa réalisation et sa qualification sont des prérequis de livraison de cette commande au Lot 0, sans attendre la passe générale. Aucune autre commande n’est activée ; les protections spécifiques existantes restent conservées. Ce choix de prescription ne prétend pas activer le produit réel.

Sales possède le registre durable de cette commande. Instance, acteur, commande, clé et intention normalisée délimitent la reprise ; même demande sans nouvel effet, intention divergente en conflit, droits actuels revérifiés avant restitution. Une conversion volontaire distincte utilise une nouvelle clé et conserve la confirmation fonctionnelle requise. Registre, résultat, copie, liens et audit durable sont atomiques. Le contrat Sales fixe les garanties de concurrence, restauration et non-réexécution après purge ; ses paramètres de clé, empreinte et conservation sont à qualifier avant activation. VER-FCT-026 et VER-OPS-015 sont obligatoires dès ce jalon, pas seulement à la passe générale. Aucun support de tentative numérotée Billing n’est réutilisé.