@nodefony/realtime 10.0.0-beta.2 → 10.0.0-beta.3

package/docs/vocabulaire.md

@@ -113,7 +113,7 @@ Trois mots du lexique ne sont pas des synonymes de ce que proposent les autres b
 temps réel. Ce sont les différenciateurs du framework.
 
 **`socket` est isomorphe.** Le même contrat `IRealtimeSocket` (`IRealtimeSocket.ts:122`) décrit la
-prise **côté navigateur** (`RealtimeClient`, `RealtimeClient.ts:194`) **et côté serveur**
+prise **côté navigateur** (`NodefonySocket`, `NodefonySocket.ts:195`) **et côté serveur**
 (`ServerRealtimeSocket`, `ServerRealtimeSocket.ts:44`). Un service back publie exactement comme une
 page front : `publish("chat:room-42", payload)`. Il n'y a pas une API cliente et une API serveur à
 apprendre, il y en a **une**.
@@ -125,9 +125,9 @@ vers un autre service — et le consommateur ne voit jamais la différence
 (`IRealtimeChannel`, `IRealtimeSocket.ts:87`).
 
 **`contrôleur` est le même mot qu'en HTTP.** Un endpoint temps réel est un contrôleur qui étend
-`RealtimeController` (`RealtimeController.ts:144`) et porte une route WebSocket : HTTP et WebSocket
+`RealtimeController` (`RealtimeController.ts:203`) et porte une route WebSocket : HTTP et WebSocket
 vivent dans le **même contexte de contrôleur**. C'est ce qui permet au pont `api.request`
-(`RealtimeController.realtimeApiRequest()`, `RealtimeController.ts:276`) de rejouer sur la socket
+(`RealtimeController.realtimeApiRequest()`, `RealtimeController.ts:321`) de rejouer sur la socket
 **la même action** que celle servie en REST.
 
 ## 🚀 Démarrage rapide — les mots en situation
@@ -179,10 +179,10 @@ export class ChatController extends RealtimeController {
 Côté client — la même **socket**, les quatre verbes :
 
 ```ts
-import { RealtimeClient } from "nodefony/client";
+import { NodefonySocket } from "nodefony/client";
 
 export async function joinChat(): Promise<void> {
-  const socket = new RealtimeClient({ url: "wss://127.0.0.1:5152/chat" });
+  const socket = new NodefonySocket({ url: "wss://127.0.0.1:5152/chat" });
   await socket.connect();
 
   socket.subscribe("chat:room-42"); // DEMANDE le flux au pair
@@ -218,7 +218,7 @@ Le **handle unique** manipulé par le code applicatif : quatre verbes (`subscrib
 `request`) et une vue par canal. Le mot vient de la prise murale : on branche, on ignore le câblage.
 
 Contrat isomorphe `IRealtimeSocket` (`IRealtimeSocket.ts:122`), implémenté côté navigateur par
-`RealtimeClient` (`RealtimeClient.ts:194`) et côté serveur par `ServerRealtimeSocket`
+`NodefonySocket` (`NodefonySocket.ts:394`) et côté serveur par `ServerRealtimeSocket`
 (`ServerRealtimeSocket.ts:44`). ⚠️ La socket **n'est pas** le [transport](#transport--la-couche-octets).
 
 → [Architecture](./architecture.md) pour la pile complète.
@@ -229,7 +229,7 @@ Un **tuyau bidirectionnel nommé**, multiplexé sur la connexion : `"chat:room-4
 `"nodefony:orm:health"`, `"nodefony:socket"`. Convention de nommage par `:` (espace de noms, puis
 précision). Ce n'est pas une classe — c'est une **chaîne de caractères indexée par le hub**.
 
-`RealtimeHub.subscribe()` (`RealtimeHub.ts:462`) l'indexe ; `IRealtimeSocket.subscribe()`
+`RealtimeHub.subscribe()` (`RealtimeHub.ts:464`) l'indexe ; `IRealtimeSocket.subscribe()`
 (`IRealtimeSocket.ts:132`) le demande. Plusieurs canaux cohabitent sur **une** connexion : c'est le
 multiplexage.
 
@@ -255,22 +255,22 @@ que personne ne lit ; écouter sans s'abonner n'en reçoit aucune.
 client, la charge part vers le serveur (un seul pair) ; depuis le serveur, elle part en
 [fan-out](#fan-out--une-publication-n-livraisons) vers tous les abonnés.
 
-`IRealtimeSocket.publish()` (`IRealtimeSocket.ts:160`), `RealtimeHub.publish()` (`RealtimeHub.ts:604`).
+`IRealtimeSocket.publish()` (`IRealtimeSocket.ts:160`), `RealtimeHub.publish()` (`RealtimeHub.ts:610`).
 
 ### `action RPC` (request) — l'appel corrélé
 
 L'appel qui **attend une réponse** : une `Promise` résolue avec le `result`, rejetée sur `error` ou
-sur expiration. Déclarée côté serveur par `@RealtimeAction` (`realtimeDecorators.ts:101`), appelée
+sur expiration. Déclarée côté serveur par `@RealtimeAction` (`realtimeDecorators.ts:191`), appelée
 côté client par `request()` (`IRealtimeSocket.ts:166`).
 
 Un handler qui lève une erreur rend un `-32603` **générique** ; seule une `RpcError`
-(`JsonRpcPeer.ts:70`) choisit ce qu'elle expose au pair.
+(`JsonRpcPeer.ts:101`) choisit ce qu'elle expose au pair.
 
 ### `canal entrant` (inbound) — le client pousse
 
 Un canal où le **client a le droit d'émettre** vers le serveur. Défaut sûr : **aucun**. Un canal
-n'accepte d'entrée que déclaré explicitement, par `@RealtimeInbound` (`realtimeDecorators.ts:231`) ou
-par l'override `realtimeInbound()` (`RealtimeController.ts:262`).
+n'accepte d'entrée que déclaré explicitement, par `@RealtimeInbound` (`realtimeDecorators.ts:278`) ou
+par l'override `realtimeInbound()` (`RealtimeController.ts:307`).
 
 Le handler reçoit `(params, reply)` — `params` vient du réseau, donc **jamais fiable** :
 `RealtimeInboundHandler` (`IRealtimeController.ts:16`).
@@ -285,7 +285,7 @@ point d'accroche des canaux à état — un appel SIP, une connexion pontée.
 
 ### `client` — la socket côté navigateur
 
-`RealtimeClient` (`RealtimeClient.ts:161`) : reconnexion automatique, réémission des abonnements,
+`NodefonySocket` (`NodefonySocket.ts:162`) : reconnexion automatique, réémission des abonnements,
 compteurs par canal, heartbeat. Publié dans le sous-chemin `nodefony/client` du cœur — donc
 importable **sans** aucune dépendance serveur, ce qui est la condition de l'isomorphisme.
 
@@ -294,10 +294,10 @@ importable **sans** aucune dépendance serveur, ce qui est la condition de l'iso
 ### `façade serveur` — la même socket, côté back
 
 `ServerRealtimeSocket` (`ServerRealtimeSocket.ts:44`), obtenue par `serverSocket()`
-(`ServerRealtimeSocket.ts:223`) : un service métier tient un handle et publie **comme une page
+(`ServerRealtimeSocket.ts:243`) : un service métier tient un handle et publie **comme une page
 front**. Une différence assumée : `request()` n'y est pas supporté — au-dessus du hub il n'y a pas
 **un** pair mais N clients. Pour un appel serveur → un client précis, c'est `requestClient()`
-(`RealtimeController.ts:329`).
+(`RealtimeController.ts:395`).
 
 ### `accueil` (welcome) — la première frame
 
@@ -335,10 +335,10 @@ handshake, jamais renégociée par frame.
 ### `hub` — le broker du process
 
 Le **standard téléphonique** du pod : il tient la table « canal → abonnés locaux » et diffuse. Un
-process = un hub, obtenu par `getRealtimeHub()` (`RealtimeHub.ts:1451`). Il ne connaît **ni** les
+process = un hub, obtenu par `getRealtimeHub()` (`RealtimeHub.ts:1432`). Il ne connaît **ni** les
 contrôleurs, **ni** le métier : ce sont les providers qui portent les dépendances.
 
-`RealtimeHub` (`RealtimeHub.ts:213`). ⚠️ « hub » désigne **toujours** le serveur ; ce que tient le
+`RealtimeHub` (`RealtimeHub.ts:214`). ⚠️ « hub » désigne **toujours** le serveur ; ce que tient le
 code applicatif s'appelle une [socket](#socket--la-prise-que-tient-ton-code).
 
 ### `fan-out` — une publication, N livraisons
@@ -346,15 +346,15 @@ code applicatif s'appelle une [socket](#socket--la-prise-que-tient-ton-code).
 L'action de diffuser : une charge publiée sur un canal part vers **tous** les sinks abonnés
 localement. Une connexion fautive ne casse pas la diffusion aux autres — chaque livraison est isolée.
 
-`RealtimeHub.publish()` (`RealtimeHub.ts:604`) pour le chemin complet, `publishLocal()`
-(`RealtimeHub.ts:623`) pour la diffusion **strictement locale** (voie d'entrée du backplane).
+`RealtimeHub.publish()` (`RealtimeHub.ts:610`) pour le chemin complet, `publishLocal()`
+(`RealtimeHub.ts:629`) pour la diffusion **strictement locale** (voie d'entrée du backplane).
 
 ### `sink` — le point de livraison d'une connexion
 
 Un `sink` = **une** connexion sur **un** canal : la fonction qui pousse la charge vers son pair. Le
 mot vient du couple source/puits : le provider est la source, le sink le puits.
 
-`ChannelSink` (`RealtimeHub.ts:155`). Le nombre de sinks d'un canal est son nombre d'abonnés locaux.
+`ChannelSink` (`RealtimeHub.ts:156`). Le nombre de sinks d'un canal est son nombre d'abonnés locaux.
 
 ### `provider` — ce qui produit un canal
 
@@ -362,7 +362,7 @@ La fabrique appelée **au premier abonné** d'un canal, qui démarre ce qui prod
 ticker, un écouteur) et rend son `dispose`, appelé **au dernier désabonné**. Zéro abonné = zéro
 timer.
 
-`ChannelFactory` (`RealtimeHub.ts:170`). ⚠️ Un provider est **partagé** : il survit à la connexion qui
+`ChannelFactory` (`RealtimeHub.ts:171`). ⚠️ Un provider est **partagé** : il survit à la connexion qui
 l'a créé — n'y capturer que des dépendances à longue vie, jamais le contexte d'une connexion.
 
 ### `canal partagé` — un provider par canal et par pod
@@ -371,7 +371,7 @@ Le modèle de coût du module : là où une implémentation naïve crée un tick
 Nodefony en crée **un par canal et par pod** et se contente d'ajouter un sink par abonné. Mille
 spectateurs d'un tableau de bord coûtent un timer, pas mille.
 
-`RealtimeHub.subscribe()` (`RealtimeHub.ts:462`).
+`RealtimeHub.subscribe()` (`RealtimeHub.ts:464`).
 
 ### `canal passif` — écouter n'est pas posséder
 
@@ -385,8 +385,8 @@ reçoit du vrai producteur ; sinon l'abonnement est refusé, et l'écoute en pla
 Sans cette distinction, le premier service qui prononce un nom de canal l'ouvrirait pour tout le
 monde — et les clients suivants s'abonneraient à un flux que rien ne produit, sans jamais l'apprendre.
 
-`RealtimeHub.listen()` (`RealtimeHub.ts:455`) pour l'écoute, `isChannelOwned()`
-(`RealtimeHub.ts:550`) pour lire l'état. ⚠️ Un canal passif **n'est pas** un canal fermé : il n'a
+`RealtimeHub.listen()` (`RealtimeHub.ts:531`) pour l'écoute, `isChannelOwned()`
+(`RealtimeHub.ts:552`) pour lire l'état. ⚠️ Un canal passif **n'est pas** un canal fermé : il n'a
 simplement pas encore de propriétaire.
 
 ### `canal système` — servi par la plateforme
@@ -395,7 +395,7 @@ Un canal dont la fabrique est déclarée par un module bas niveau (le journal d'
 qui devient servable par **n'importe quel** endpoint, présent ou futur, sans qu'aucun contrôleur ne
 le connaisse. Consulté seulement quand la fabrique du contrôleur a dit « inconnu ».
 
-`RealtimeHub.registerSystemChannel()` (`RealtimeHub.ts:1297`).
+`RealtimeHub.registerSystemChannel()` (`RealtimeHub.ts:1278`).
 
 ### `canal broadcast` — celui qui traverse le backplane
 
@@ -403,8 +403,8 @@ Un canal **déclaré** comme franchissant la frontière du process : chat, prés
 déclaration se fait par **préfixe**, ce qui couvre les variantes de cadence (`chat:` couvre
 `chat:room-42:1000`).
 
-`RealtimeHub.markBroadcastChannel()` (`RealtimeHub.ts:668`), déclaré côté contrôleur par
-`@RealtimeBroadcast` (`realtimeDecorators.ts:342`).
+`RealtimeHub.markBroadcastChannel()` (`RealtimeHub.ts:674`), déclaré côté contrôleur par
+`@RealtimeBroadcast` (`realtimeDecorators.ts:420`).
 
 ### `canal instance-local` — le défaut
 
@@ -412,15 +412,15 @@ Tout canal **non déclaré** broadcast reste dans son process. C'est voulu : les
 d'observabilité (journaux, sondes, état interne) décrivent **ce pod**, et les agréger silencieusement
 serait à la fois faux et une fuite. Traverser le process est une capacité qu'un canal **demande**.
 
-Politique de forward du hub — `#broadcastPrefixes` (`RealtimeHub.ts:393`).
+Politique de forward du hub — `#broadcastPrefixes` (`RealtimeHub.ts:395`).
 
 ### `contrôleur temps réel` — l'endpoint WebSocket
 
 La classe de base d'un endpoint : elle porte tout le protocole (handshake, accueil, discrimination
 des frames, cycle de vie des canaux) et ne laisse au métier que ses canaux et ses actions.
 
-`RealtimeController` (`RealtimeController.ts:144`), point d'entrée `handleRealtime()`
-(`RealtimeController.ts:299`). C'est un **contrôleur** au sens habituel de Nodefony : la même classe
+`RealtimeController` (`RealtimeController.ts:203`), point d'entrée `handleRealtime()`
+(`RealtimeController.ts:344`). C'est un **contrôleur** au sens habituel de Nodefony : la même classe
 peut porter des routes HTTP.
 
 ### `service realtime` — la façade d'injection
@@ -437,31 +437,32 @@ L'option qui expose la méthode `api.request { path }` : la connexion rejoue **l
 contrôleur** que celle servie en REST, avec **la même garde**. Le pont n'atteint que les routes qui
 déclarent explicitement le transport WebSocket — aucun contournement possible.
 
-`realtimeApiRequest()` (`RealtimeController.ts:276`), mise en œuvre `invokeApiRequest()`
-(`RealtimeController.ts:949`). Désactivé par défaut.
+`realtimeApiRequest()` (`RealtimeController.ts:321`), mise en œuvre `invokeApiRequest()`
+(`RealtimeController.ts:1070`). Désactivé par défaut.
 
 ## 🔌 Le protocole et le transport — ce qui passe sur le fil
 
-| Terme          | En une ligne                                               |
-| -------------- | ---------------------------------------------------------- |
-| `frame`        | l'unité atomique qui passe sur le fil                      |
-| `pair`         | le moteur de protocole, identique client et serveur        |
-| `requête`      | frame avec `method` **et** `id` — appelle une réponse      |
-| `notification` | frame avec `method` seul — sans réponse                    |
-| `réponse`      | frame avec `id` seul — résout une requête en attente       |
-| `dispatch`     | classer une frame entrante puis la router vers son handler |
-| `transport`    | la couche octets, interchangeable                          |
-| `enveloppe`    | joindre des métadonnées serveur à côté du résultat         |
-| `cadence`      | la fréquence d'un canal d'état, portée par son nom         |
-| `AIMD`         | l'auto-ajustement de cadence face à un client lent         |
+| Terme          | En une ligne                                                |
+| -------------- | ----------------------------------------------------------- |
+| `frame`        | l'unité atomique qui passe sur le fil                       |
+| `pair`         | le moteur de protocole, identique client et serveur         |
+| `requête`      | frame avec `method` **et** `id` — appelle une réponse       |
+| `notification` | frame avec `method` seul — sans réponse                     |
+| `réponse`      | `id` + `result` ou `error`, sans `method` — résout un appel |
+| `dispatch`     | classer une frame entrante puis la router vers son handler  |
+| `transport`    | la couche octets, interchangeable                           |
+| `enveloppe`    | joindre des métadonnées serveur à côté du résultat          |
+| `cadence`      | la fréquence d'un canal d'état, portée par son nom          |
+| `AIMD`         | l'auto-ajustement de cadence face à un client lent          |
 
 ### `frame` — l'unité qui passe sur le fil
 
 Une enveloppe JSON-RPC 2.0. Sa **nature se lit sur `method`**, pas sur `id` : `method` + `id` =
-requête, `method` seul = notification, `id` seul = réponse. Tout le reste est invalide.
+requête, `method` seul = notification, `id` + `result` ou `error` = réponse. Tout le reste est
+invalide.
 
-`JsonRpcFrameKind` (`JsonRpcPeer.ts:133`). Le classement est fait par `JsonRpcPeer.receive()`
-(`JsonRpcPeer.ts:390`), qui **ne lève jamais**.
+`JsonRpcFrameKind` (`jsonrpc/index.ts:138`). Le classement est fait par `JsonRpcPeer.receive()`
+(`JsonRpcPeer.ts:419`), qui **ne lève jamais**.
 
 ### `pair` (peer) — le moteur de protocole
 
@@ -469,14 +470,14 @@ Client et serveur sont des **pairs** : classer une frame, router, corréler les
 travail des deux côtés. Nodefony l'écrit **une seule fois** ; chaque côté l'entoure de son transport
 et de ses handlers. Aucune dépendance Node — le même fichier tourne dans le navigateur.
 
-`JsonRpcPeer` (`JsonRpcPeer.ts:280`), contrat `IRealtimePeer` (`JsonRpcPeer.ts:213`).
+`JsonRpcPeer` (`JsonRpcPeer.ts:311`), contrat `IRealtimePeer` (`JsonRpcPeer.ts:261`).
 
 ### `dispatch` — classer puis router
 
 Le geste du pair sur une frame entrante : décider de sa nature, trouver le handler, l'appeler,
 renvoyer la réponse s'il en faut une. Ce n'est pas une méthode publique — c'est un **moment**, et
 c'est précisément là que se greffe le [verrou de frame](#verrou-de-frame--la-décision-par-frame),
-par le crochet `beforeDispatch` (`JsonRpcPeer.ts:192`).
+par le crochet `beforeDispatch` (`JsonRpcPeer.ts:219`).
 
 ### `transport` — la couche octets
 
@@ -494,7 +495,7 @@ Quand un handler veut joindre des métadonnées serveur à sa réponse, il rend
 `result` reste **exactement** ce que rendrait la même route en REST, et la méta voyage dans un champ
 frère. Un pair qui n'en connaît pas les clés les ignore.
 
-`RpcEnvelope` (`JsonRpcPeer.ts:104`), `RpcMeta` (`JsonRpcPeer.ts:90`).
+`RpcEnvelope` (`JsonRpcPeer.ts:139`), `RpcMeta` (`JsonRpcPeer.ts:125`).
 
 ### `cadence` — la fréquence portée par le nom
 
@@ -535,7 +536,7 @@ publications d'un process aux autres. Un contrat volontairement minuscule — `p
 `start`, `stop`, `describe` — parce que tout ce qui est riche appartient au hub.
 
 `IBackplane` (`IBackplane.ts:107`), message `IBackplaneMessage` (`IBackplane.ts:51`), branchement
-`RealtimeHub.setBackplane()` (`RealtimeHub.ts:714`).
+`RealtimeHub.setBackplane()` (`RealtimeHub.ts:720`).
 
 > [!TIP]
 > C'est la pièce qui tient la promesse « une ligne de configuration change tout » : le hub **ne sait
@@ -587,7 +588,7 @@ La règle qui empêche les tempêtes : un message **reçu** du backplane est ré
 **locale seulement**, jamais renvoyé sur le bus ; et un message qui porte sa propre origine est
 ignoré à l'arrivée. Sans l'origine, l'anti-écho ferait taire le voisin au lieu de soi-même.
 
-`RealtimeHub.publishLocal()` (`RealtimeHub.ts:623`).
+`RealtimeHub.publishLocal()` (`RealtimeHub.ts:629`).
 
 ### `cloison` (namespace) — deux applications, un même bus
 
@@ -630,7 +631,7 @@ l'authenticator tourne et que l'identité est figée. Tout ce qui coûte cher se
 frame.
 
 DTO neutre `IRealtimeHandshake` (`IRealtimeHandshake.ts:14`) — en-têtes, cookies, URL, origine,
-sous-protocoles. Traitement dans `onHandshake()` (`RealtimeController.ts:374`).
+sous-protocoles. Traitement dans `onHandshake()` (`RealtimeController.ts:450`).
 
 ### `authenticator` — du handshake à l'identité
 
@@ -639,7 +640,7 @@ La stratégie qui transforme une poignée de main en identité : `supports` (est
 HTTP — un seul modèle mental pour les deux transports.
 
 `IRealtimeAuthenticator` (`IRealtimeAuthenticator.ts:24`), enregistrement
-`RealtimeHub.useAuthenticator()` (`RealtimeHub.ts:943`).
+`RealtimeHub.useAuthenticator()` (`RealtimeHub.ts:925`).
 
 ### `matcher` — qui capture quoi
 
@@ -647,7 +648,7 @@ Le sélecteur (motif d'URL, hôte optionnel) qui décide **quel** authenticator
 **premier** qui capture gagne : on enregistre donc du plus spécifique au plus général.
 
 `IRealtimeAuthenticatorMatcher` (`IRealtimeAuthenticatorMatcher.ts:25`), résolution
-`resolveAuthenticator()` (`RealtimeHub.ts:961`).
+`resolveAuthenticator()` (`RealtimeHub.ts:943`).
 
 ### `jeton` (token) — l'identité figée
 
@@ -664,7 +665,7 @@ Les exigences déclarées d'un canal : authentifié, rôles, scopes. Elles s'att
 canal, pas à la méthode qui l'implémente — parce que c'est le nom que le pare-feu résout.
 
 `IChannelPolicy` (`IChannelPolicy.ts:20`), déclaration par `@RealtimeChannel`
-(`realtimeDecorators.ts:192`), résolution `resolveChannelPolicy()` (`RealtimeHub.ts:1228`).
+(`realtimeDecorators.ts:240`), résolution `resolveChannelPolicy()` (`RealtimeHub.ts:1209`).
 
 ### `verrou de frame` — la décision par frame
 
@@ -672,8 +673,8 @@ La fonction qui répond « cette frame passe-t-elle ? » à partir du jeton **d
 **Synchrone par doctrine** : attendre une réponse distante à chaque frame sérialiserait le flux d'une
 connexion. Un contrôle qui doit interroger le réseau se fait au handshake, pas ici.
 
-`FrameAuthorizer` (`RealtimeHub.ts:39`), pose `setFrameAuthorizer()` (`RealtimeHub.ts:1039`), appel
-`runAuthorizer()` (`RealtimeHub.ts:1328`).
+`FrameAuthorizer` (`RealtimeHub.ts:40`), pose `setFrameAuthorizer()` (`RealtimeHub.ts:1020`), appel
+`runAuthorizer()` (`RealtimeHub.ts:1309`).
 
 ### `contrôle d'origine` — la défense d'ouverture
 
@@ -681,7 +682,7 @@ Le contrôle de l'en-tête `Origin` à l'ouverture (RFC 6455 §10.2) : un site t
 ouvrir une connexion authentifiée dans le dos de l'utilisateur. Correspondance **exacte**, aucun
 caractère générique.
 
-`OriginGuard` (`RealtimeHub.ts:33`), configuration `csrf.checkOrigin` (`config.ts:255`).
+`OriginGuard` (`RealtimeHub.ts:34`), configuration `csrf.checkOrigin` (`config.ts:255`).
 
 ### `révocation` — la connexion qui survit à sa session
 
@@ -689,8 +690,8 @@ Le problème que ce mot nomme : une connexion ouverte pourrait survivre à la se
 autorisée, puisque le verrou de frame ne relit rien. Un contrôle périodique referme l'écart en
 re-validant les identités révocables et en fermant celles qui ne valent plus.
 
-`registerRevocable()` (`RealtimeHub.ts:794`), `revalidateRevocable()` (`RealtimeHub.ts:826`), période
-`REVOCATION_REVALIDATE_MS` (`RealtimeHub.ts:111`). Une re-validation en erreur **ferme** — jamais
+`registerRevocable()` (`RealtimeHub.ts:796`), `revalidateRevocable()` (`RealtimeHub.ts:815`), période
+`REVOCATION_REVALIDATE_MS` (`RealtimeHub.ts:112`). Une re-validation en erreur **ferme** — jamais
 l'inverse.
 
 ### `refus` (denied) — rendre le « non » visible
@@ -700,7 +701,7 @@ donc `realtime:denied`. Le motif est **générique** : jamais le rôle ou le sco
 transformerait le refus en oracle d'autorisation.
 
 `IRealtimeDenied` (`RealtimeEventMap.ts:269`), conversion en message d'interface `deniedToNotice()`
-(`notice.ts:45`).
+(`notice.ts:46`).
 
 ### `audit de frame` — tracer le notable
 
@@ -708,7 +709,7 @@ Le signal émis sur les événements protocolaires qui méritent une trace : fra
 refusée, méthode inconnue, erreur interne. Émis sans attente, avec le pair — ce qui permet de
 retrouver **qui** a été refusé, pas seulement d'où venait le paquet.
 
-`FrameAuditReason` (`JsonRpcPeer.ts:155`), crochet `onFrameAudit` (`JsonRpcPeer.ts:210`).
+`FrameAuditReason` (`JsonRpcPeer.ts:182`), crochet `onFrameAudit` (`JsonRpcPeer.ts:236`).
 
 ### `seam` — le point de greffe
 
@@ -716,8 +717,8 @@ Littéralement une **couture** : un point prévu dans une couche basse pour qu'u
 greffe du comportement **sans modifier la couche basse**. Le module en expose cinq, et c'est ce qui
 permet à la couche sécurité de se brancher sans qu'aucune ligne de realtime ne la connaisse.
 
-Les deux du protocole sont `beforeDispatch` (`JsonRpcPeer.ts:192`) et `onFrameAudit`
-(`JsonRpcPeer.ts:210`) ; les trois du hub sont l'authenticator, le matcher et le contrôle d'origine.
+Les deux du protocole sont `beforeDispatch` (`JsonRpcPeer.ts:219`) et `onFrameAudit`
+(`JsonRpcPeer.ts:236`) ; les trois du hub sont l'authenticator, le matcher et le contrôle d'origine.
 
 → [Sécurité](./securite.md) pour le détail de chacun.
 
@@ -728,7 +729,7 @@ ressources ; sans borne, une seule connexion peut les épuiser. Au-delà, l'abon
 client en est informé.
 
 `limits.maxChannelsPerConnection` (`config.ts:142`), pose `setMaxChannelsPerConnection()`
-(`RealtimeHub.ts:995`).
+(`RealtimeHub.ts:976`).
 
 ## 📡 L'observabilité — ce que la socket dit d'elle-même
 
@@ -747,7 +748,7 @@ L'oscilloscope du module : « voici mon état, maintenant ». Canaux et abonnés
 livraisons, connexions, octets, back-pressure, carte d'identité du backplane. Lecture **pure**, sans
 allocation sur le chemin chaud.
 
-`RealtimeHub.probe()` (`RealtimeHub.ts:865`) rend un `IRealtimeProbe` (`IRealtimeProbe.ts:61`).
+`RealtimeHub.probe()` (`RealtimeHub.ts:847`) rend un `IRealtimeProbe` (`IRealtimeProbe.ts:61`).
 
 > [!WARNING]
 > `IRealtimeProbe` est la **forme des données**, pas une interface à implémenter avec une méthode
@@ -759,10 +760,10 @@ La quantité d'octets déjà remise au transport mais pas encore partie. C'est l
 n° 1 : il monte quand le client n'absorbe plus. Deux seuils distincts existent — un pour **compter**
 (la sonde), un pour **agir** (abandonner des frames, puis fermer).
 
-Seuil de comptage `SLOW_CONSUMER_BYTES` (`RealtimeHub.ts:63`) — une constante, car il ne
+Seuil de comptage `SLOW_CONSUMER_BYTES` (`RealtimeHub.ts:64`) — une constante, car il ne
 décide de rien. Les seuils d'ACTION, eux, sont des réglages : `websocket.maxBackpressure`,
 `websocket.backpressurePolicy` et `websocket.backpressureCloseAfterDrops` (`http`,
-`http/nodefony/config/config.ts:1048`).
+`http/nodefony/config/config.ts:1226`).
 
 ### `consommateur lent` — la connexion qui décroche
 
@@ -785,7 +786,7 @@ point d'arrivée des frames, donc réutilisables par n'importe quelle applicatio
 En multi-worker, chaque process a **sa** sonde. La vue du pod est leur fusion : cumuls additionnés,
 maxima repris au plus haut, instances listées une à une.
 
-`mergeClusterHealth()` (`ClusterProbeClient.ts:46`), forme `IRealtimeClusterHealth`
+`mergeClusterHealth()` (`ClusterProbeClient.ts:60`), forme `IRealtimeClusterHealth`
 (`IRealtimeProbe.ts:178`).
 
 ### `plan de données admin` — la sonde servie à Studio
@@ -802,14 +803,14 @@ elle-même par le même chemin que les autres modules.
 | Symptôme                                                           | Cause — le mot pris pour un autre                                                                                     | Correction                                                                              |
 | ------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
 | « Je suis abonné mais je ne reçois rien »                          | `subscribe` confondu avec `on` : le flux est demandé, aucun écouteur ne le lit                                        | Les deux : `subscribe(canal)` **et** `on(canal, handler)` (`IRealtimeSocket.ts:131`)    |
-| « Ça marche en local, plus rien dès qu'on passe à plusieurs pods » | canal resté **instance-local** — le défaut. Traverser le process est une capacité qu'on **demande**                   | Déclarer le préfixe dans `@RealtimeBroadcast` (`realtimeDecorators.ts:342`)             |
-| « Le client publie, le serveur ignore »                            | canal non déclaré **entrant**. Un client ne peut rien pousser tant qu'aucun handler n'existe                          | `@RealtimeInbound("mon:canal")` (`realtimeDecorators.ts:231`)                           |
+| « Ça marche en local, plus rien dès qu'on passe à plusieurs pods » | canal resté **instance-local** — le défaut. Traverser le process est une capacité qu'on **demande**                   | Déclarer le préfixe dans `@RealtimeBroadcast` (`realtimeDecorators.ts:420`)             |
+| « Le client publie, le serveur ignore »                            | canal non déclaré **entrant**. Un client ne peut rien pousser tant qu'aucun handler n'existe                          | `@RealtimeInbound("mon:canal")` (`realtimeDecorators.ts:278`)                           |
 | Deux déploiements se mélangent sur un même serveur Redis           | pas de **cloison** — le numéro de base ne cloisonne pas le pub/sub                                                    | Poser `backplane.namespace` (`config.ts:59`)                                            |
 | Le fan-out disparaît entre conteneurs identiques                   | **origine** dérivée du seul identifiant de processus : deux conteneurs sont tous deux le n° 1, l'anti-écho avale tout | `resolveBackplaneOriginId()` (`originId.ts:24`) dérive du pod ou de l'hôte              |
 | Deux tickers pour le même tableau de bord                          | **cadence** différente = **canal** différent, jamais réconcilié                                                       | Fabriquer le nom via `rateChannel()` (`channelRate.ts:44`) des deux côtés               |
-| Un canal se croit protégé mais laisse tout passer                  | **politique** déclarée sans **verrou de frame** posé pour la faire respecter                                          | Le hub le détecte et avertit : `hasUnenforcedChannelPolicies()` (`RealtimeHub.ts:1117`) |
-| Une connexion garde ses flux après une déconnexion applicative     | le **verrou de frame** ne relit rien : par construction, il ne voit pas la session mourir                             | Inscrire l'identité au registre de **révocation** (`RealtimeHub.ts:433`)                |
-| « Le provider a planté après la fermeture d'un onglet »            | **provider** confondu avec **sink** : le provider est partagé, il survit à la connexion créatrice                     | N'y capturer que des dépendances à longue vie (`ChannelFactory`, `RealtimeHub.ts:170`)  |
+| Un canal se croit protégé mais laisse tout passer                  | **politique** déclarée sans **verrou de frame** posé pour la faire respecter                                          | Le hub le détecte et avertit : `hasUnenforcedChannelPolicies()` (`RealtimeHub.ts:1098`) |
+| Une connexion garde ses flux après une déconnexion applicative     | le **verrou de frame** ne relit rien : par construction, il ne voit pas la session mourir                             | Inscrire l'identité au registre de **révocation** (`RealtimeHub.ts:439`)                |
+| « Le provider a planté après la fermeture d'un onglet »            | **provider** confondu avec **sink** : le provider est partagé, il survit à la connexion créatrice                     | N'y capturer que des dépendances à longue vie (`ChannelFactory`, `RealtimeHub.ts:171`)  |
 | « Notre store realtime est indisponible »                          | **store** employé pour **driver** : le backplane ne conserve rien, il fait passer                                     | Dire « le driver de backplane » — les données ont des stores, les flux ont des drivers  |
 
 > [!CAUTION]

package/package.json

@@ -1,6 +1,9 @@
 {
   "name": "@nodefony/realtime",
-  "version": "10.0.0-beta.2",
+  "version": "10.0.0-beta.3",
+  "nodefony": {
+    "configSchema": "./dist/nodefony/config/configSchema.js"
+  },
   "description": "Couche temps réel serveur de Nodefony : canaux, appels bidirectionnels JSON-RPC 2.0, contre-pression, et diffusion entre plusieurs instances (boucle locale, IPC de grappe, Redis)",
   "author": "Christophe CAMENSULI <ccamensuli@gmail.com>",
   "type": "module",
@@ -41,20 +44,20 @@
     "esm"
   ],
   "peerDependencies": {
-    "@nodefony/framework": "^10.0.0-beta.2",
-    "@nodefony/http": "^10.0.0-beta.2",
-    "nodefony": "^10.0.0-beta.2",
+    "@nodefony/framework": "^10.0.0-beta.3",
+    "@nodefony/http": "^10.0.0-beta.3",
+    "nodefony": "^10.0.0-beta.3",
     "reflect-metadata": "0.2.2",
-    "zod": "^4.6.5"
+    "zod": "^4.6.7"
   },
   "devDependencies": {
-    "@nodefony/framework": "^10.0.0-beta.2",
-    "@nodefony/http": "^10.0.0-beta.2",
-    "@types/node": "26.6.3",
-    "@vitest/coverage-v8": "5.0.3",
-    "nodefony": "^10.0.0-beta.2",
+    "@nodefony/framework": "^10.0.0-beta.3",
+    "@nodefony/http": "^10.0.0-beta.3",
+    "@types/node": "26.6.5",
+    "@vitest/coverage-v8": "5.0.4",
+    "nodefony": "^10.0.0-beta.3",
     "reflect-metadata": "0.2.2",
-    "vitest": "5.0.3"
+    "vitest": "5.0.4"
   },
   "private": false,
   "engines": {
@@ -66,7 +69,8 @@
   },
   "files": [
     "dist",
-    "docs"
+    "docs",
+    "!docs/couverture-bancs.md"
   ],
   "publishConfig": {
     "access": "public"