Document de référence présenté dans son intégralité. Le cahier des charges décrit le périmètre prévu ; il ne constitue pas une preuve de recette.
TEC-INT-003 — Notifications autorisées et données frontend complètes
Statut : valide
Sources : DEC-0051, DEC-0045, DEC-0016, DEC-0019
Prescription : Elena doit utiliser Reverb comme transport de notification principalement destiné au frontend, jamais comme source de vérité ; pour un objet simple, le serveur doit pouvoir pousser directement une représentation juste et complète pour l’usage frontend autorisé, sans relecture GraphQL systématique.
Raison fonctionnelle : actualiser l’interface sans requête redondante tout en préservant la confidentialité et la cohérence de l’état affiché.
Contraintes et invariants :
la vérité métier demeure persistée et contrôlée côté serveur ; aucune mutation métier n’est exécutée par le canal WebSocket ; les commandes restent REST ;
les événements métier ne sont pas diffusés sur des canaux publics ; l’abonnement est authentifié et autorisé et chaque diffusion respecte les droits effectifs de ses destinataires ;
la complétude désigne la représentation nécessaire à l’usage frontend, après autorisation objet/champ/ligne, pas la sérialisation brute du modèle Eloquent ;
un événement dépendant d’une mutation n’est publié qu’après son commit ; un rollback ne produit pas d’état métier présenté comme acquis ;
la voie nominale d’un objet simple dont le contrat de notification est complet utilise directement ce payload ; une relecture est réservée à une donnée absente, un objet complexe, une incohérence détectée ou une resynchronisation ;
les doublons et événements obsolètes ne doivent ni doubler un effet UI ni écraser un état plus récent ; le contrat de chaque événement précise comment le frontend reconnaît une représentation complète, une invalidation et une mise à jour applicable.
Données : les payloads sont des projections explicites et typées de l’état validé ; un identifiant, un champ ou une relation interdits ne sont pas envoyés. Deux acteurs de droits différents ne reçoivent une charge commune que si chacun peut lire tous ses éléments. Aucun cache frontend n’est une autorité de permission.
Interfaces et événements : Reverb complète les lectures GraphQL sans devenir une API de requête concurrente. Les contrats d’événement décrivent la projection, ses conditions d’application et la stratégie de resynchronisation. Une reconnexion ou une perte de continuité exige une remise en cohérence par lecture autorisée ; aucune livraison métier garantie ne repose uniquement sur WebSocket.
Sécurité et audit : les règles de TEC-SEC-007/008 couvrent abonnements et émissions ; une révocation invalide l’autorisation de recevoir les données suivantes, même si la connexion reste ouverte. Les caches d’autorisation et abonnements ne permettent pas de continuer à diffuser après révocation effective. Le transport ne remplace ni l’audit indépendant ni la livraison durable de DEC-0019.
Exploitation : HTTP et Reverb sont des rôles séparés de la même image selon TEC-OPS-003 ; déconnexions et erreurs sont observables sans journaliser les payloads sensibles. Une indisponibilité de Reverb ne transforme pas un succès transactionnel en échec métier : le frontend retrouve l’état validé par les lectures autorisées.
Vérification : VER-OPS-006
Questions ouvertes : aucune
Paramètres et contrats complémentaires à instruire : contrats détaillés par événement, mécanisme concret de détection d’obsolescence et de révocation, limites de taille/fréquence et dimensionnement. Ces paramètres ne suspendent pas les invariants de confidentialité et de cohérence.
Réalisation : elena:Modules/Manufacturing/app/Events/Publishers/WorkorderStartedBroadcast.php, elena:routes/channels.php, elena:compose.dev.yaml ; le canal public actuel est un écart à corriger dans le produit.