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

package/docs/vocabulaire.md

@@ -112,9 +112,9 @@ Nodefony **fige** donc trois séparations, et tout le reste en découle :
 Trois mots du lexique ne sont pas des synonymes de ce que proposent les autres bibliothèques
 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**
-(`ServerRealtimeSocket`, `ServerRealtimeSocket.ts:44`). Un service back publie exactement comme une
+**`socket` est isomorphe.** Le même contrat `IRealtimeSocket` (`IRealtimeSocket.ts#IRealtimeSocket`) décrit la
+prise **côté navigateur** (`NodefonySocket`, `NodefonySocket.ts#NodefonySocket`) **et côté serveur**
+(`ServerRealtimeSocket`, `ServerRealtimeSocket.ts#ServerRealtimeSocket`). 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**.
 
@@ -122,12 +122,12 @@ apprendre, il y en a **une**.
 bidirectionnel, chacun avec son cycle de vie et son compteur d'abonnés. Le backing d'un canal est
 **pluggable côté serveur** — pub/sub, encapsulation d'un autre protocole, pont vers TCP/UDP, relais
 vers un autre service — et le consommateur ne voit jamais la différence
-(`IRealtimeChannel`, `IRealtimeSocket.ts:87`).
+(`IRealtimeChannel`, `IRealtimeSocket.ts#IRealtimeChannel.name`).
 
 **`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#RealtimeController`) 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#RealtimeController.realtimeApiRequest`) 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
@@ -217,9 +217,9 @@ export async function joinChat(): Promise<void> {
 Le **handle unique** manipulé par le code applicatif : quatre verbes (`subscribe`, `on`, `publish`,
 `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`
-(`ServerRealtimeSocket.ts:44`). ⚠️ La socket **n'est pas** le [transport](#transport--la-couche-octets).
+Contrat isomorphe `IRealtimeSocket` (`IRealtimeSocket.ts#IRealtimeSocket`), implémenté côté navigateur par
+`NodefonySocket` (`NodefonySocket.ts#NodefonySocket`) et côté serveur par `ServerRealtimeSocket`
+(`ServerRealtimeSocket.ts#ServerRealtimeSocket`). ⚠️ La socket **n'est pas** le [transport](#transport--la-couche-octets).
 
 → [Architecture](./architecture.md) pour la pile complète.
 
@@ -229,8 +229,8 @@ 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()`
-(`IRealtimeSocket.ts:132`) le demande. Plusieurs canaux cohabitent sur **une** connexion : c'est le
+`RealtimeHub.subscribe()` (`RealtimeHub.ts#RealtimeHub.subscribe`) l'indexe ; `IRealtimeSocket.subscribe()`
+(`IRealtimeSocket.ts#IRealtimeSocket.subscribe`) le demande. Plusieurs canaux cohabitent sur **une** connexion : c'est le
 multiplexage.
 
 ### `abonnement` (subscribe) — demander le flux
@@ -238,8 +238,8 @@ multiplexage.
 **Ref-compté** : la demande part vers le pair au **premier** consommateur seulement, et le flux se
 coupe au **dernier** désabonnement. Réémise automatiquement à chaque reconnexion.
 
-`IRealtimeSocket.subscribe()` (`IRealtimeSocket.ts:132`). Le plafond par connexion est réglable
-(`limits.maxChannelsPerConnection`, `config.ts:142`) — au-delà, le canal n'est pas ouvert.
+`IRealtimeSocket.subscribe()` (`IRealtimeSocket.ts#IRealtimeSocket.subscribe`). Le plafond par connexion est réglable
+(`limits.maxChannelsPerConnection`, `config.ts#limitsSchema`) — au-delà, le canal n'est pas ouvert.
 
 ### `réception` (on) — brancher un handler
 
@@ -247,7 +247,7 @@ coupe au **dernier** désabonnement. Réémise automatiquement à chaque reconne
 module : `on` ne demande rien au serveur, `subscribe` si. S'abonner sans écouter reçoit des frames
 que personne ne lit ; écouter sans s'abonner n'en reçoit aucune.
 
-`IRealtimeSocket.on(channel, handler)` (`IRealtimeSocket.ts:141`).
+`IRealtimeSocket.on(channel, handler)` (`IRealtimeSocket.ts#IRealtimeSocket.on`).
 
 ### `publication` (publish) — émettre sans réponse
 
@@ -255,25 +255,28 @@ 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#IRealtimeSocket.publish`), `RealtimeHub.publish()` (`RealtimeHub.ts#RealtimeHub.publish`).
 
 ### `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
-côté client par `request()` (`IRealtimeSocket.ts:166`).
+sur expiration. Déclarée côté serveur par `@RealtimeAction` (`realtimeDecorators.ts#RealtimeAction`), appelée
+côté client par `request()` (`NodefonySocket.ts#NodefonySocket.request`), côté serveur vers UN
+client par `requestClient()` (`RealtimeController.ts#RealtimeController.requestClient`). Elle
+n'appartient pas au contrat commun `IRealtimeSocket` : une requête attend UN pair, et un handle
+serveur au-dessus du hub en a N.
 
 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#RpcError`) 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#RealtimeInbound`) ou
+par l'override `realtimeInbound()` (`RealtimeController.ts#RealtimeController.realtimeInbound`).
 
 Le handler reçoit `(params, reply)` — `params` vient du réseau, donc **jamais fiable** :
-`RealtimeInboundHandler` (`IRealtimeController.ts:16`).
+`RealtimeInboundHandler` (`IRealtimeController.ts#RealtimeInboundHandler`).
 
 ### `handle de canal` — la vue objet d'un canal
 
@@ -281,11 +284,11 @@ Le handler reçoit `(params, reply)` — `params` vient du réseau, donc **jamai
 `pubsub`, `protocol`, `bridge`, `proxy`) et son cycle de vie (`open`/`close`/`send`/`on`). C'est le
 point d'accroche des canaux à état — un appel SIP, une connexion pontée.
 
-`IRealtimeChannel` (`IRealtimeSocket.ts:87`), `channel()` (`IRealtimeSocket.ts:178`).
+`IRealtimeChannel` (`IRealtimeSocket.ts#IRealtimeChannel.name`), `channel()` (`IRealtimeSocket.ts#IRealtimeSocket.channel`).
 
 ### `client` — la socket côté navigateur
 
-`RealtimeClient` (`RealtimeClient.ts:161`) : reconnexion automatique, réémission des abonnements,
+`NodefonySocket` (`NodefonySocket.ts#NodefonySocket`) : 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.
 
@@ -293,11 +296,11 @@ 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` (`ServerRealtimeSocket.ts#ServerRealtimeSocket`), obtenue par `serverSocket()`
+(`ServerRealtimeSocket.ts#serverSocket`) : 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#RealtimeController.requestClient`).
 
 ### `accueil` (welcome) — la première frame
 
@@ -305,7 +308,7 @@ La notification `realtime:welcome`, poussée par le serveur juste après le hand
 protocole, les canaux que ce visiteur peut obtenir, les actions de l'endpoint, et l'identité résolue. Un client
 attend cette frame avant de pousser quoi que ce soit.
 
-`IRealtimeWelcome` (`RealtimeEventMap.ts:231`).
+`IRealtimeWelcome` (`RealtimeEventMap.ts#IRealtimeWelcome`).
 
 ### `identité` — qui est cette connexion
 
@@ -313,7 +316,7 @@ La vue « sur soi » d'une connexion : type de jeton, authentifié ou non, ident
 Aucun secret — seulement ce que le porteur sait déjà de lui-même. Elle est **résolue une fois** au
 handshake, jamais renégociée par frame.
 
-`RealtimeIdentity` (`RealtimeEventMap.ts:212`).
+`RealtimeIdentity` (`RealtimeEventMap.ts#RealtimeIdentity`).
 
 ## 🏗️ Le serveur — ce qui aiguille derrière la prise
 
@@ -335,10 +338,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#getRealtimeHub`). 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#RealtimeHub`). ⚠️ « 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 +349,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#RealtimeHub.publish`) pour le chemin complet, `publishLocal()`
+(`RealtimeHub.ts#RealtimeHub.publishLocal`) 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#ChannelSink`). Le nombre de sinks d'un canal est son nombre d'abonnés locaux.
 
 ### `provider` — ce qui produit un canal
 
@@ -362,7 +365,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#ChannelFactory`). ⚠️ 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 +374,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#RealtimeHub.subscribe`).
 
 ### `canal passif` — écouter n'est pas posséder
 
@@ -385,8 +388,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#RealtimeHub.listen`) pour l'écoute, `isChannelOwned()`
+(`RealtimeHub.ts#RealtimeHub.isChannelOwned`) 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 +398,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#RealtimeHub.registerSystemChannel`).
 
 ### `canal broadcast` — celui qui traverse le backplane
 
@@ -403,8 +406,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#RealtimeHub.markBroadcastChannel`), déclaré côté contrôleur par
+`@RealtimeBroadcast` (`realtimeDecorators.ts#RealtimeBroadcast`).
 
 ### `canal instance-local` — le défaut
 
@@ -412,15 +415,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#RealtimeHub.#broadcastPrefixes`).
 
 ### `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#RealtimeController`), point d'entrée `handleRealtime()`
+(`RealtimeController.ts#RealtimeController.handleRealtime`). 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
@@ -429,7 +432,7 @@ Le service exposé au conteneur sous le nom `realtimeService` : `publish`, `subs
 config gelée. C'est l'API stable pour le code utilisateur, quand `getRealtimeHub()` est l'accès
 interne.
 
-`RealtimeService` (`RealtimeService.ts:48`).
+`RealtimeService` (`RealtimeService.ts#RealtimeService`).
 
 ### `pont API` — la même action, sur la socket
 
@@ -437,31 +440,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#RealtimeController.realtimeApiRequest`), mise en œuvre `invokeApiRequest()`
+(`RealtimeController.ts#RealtimeController.invokeApiRequest`). 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#JsonRpcFrameKind`). Le classement est fait par `JsonRpcPeer.receive()`
+(`JsonRpcPeer.ts#JsonRpcPeer.receive`), qui **ne lève jamais**.
 
 ### `pair` (peer) — le moteur de protocole
 
@@ -469,22 +473,22 @@ 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#JsonRpcPeer`), contrat `IRealtimePeer` (`JsonRpcPeer.ts#IRealtimePeer`).
 
 ### `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#JsonRpcPeerOptions.beforeDispatch`).
 
 ### `transport` — la couche octets
 
 La techno réseau qui porte les frames, **interchangeable** : `WsConnectionTransport`
-(`WsConnectionTransport.ts:46`) côté serveur, `BrowserWsTransport` (`BrowserWsTransport.ts:12`) côté
+(`WsConnectionTransport.ts#WsConnectionTransport`) côté serveur, `BrowserWsTransport` (`BrowserWsTransport.ts#BrowserWsTransport`) côté
 navigateur. Le pair ignore laquelle est branchée.
 
-Contrat `IRealtimeTransport` (`IRealtimeTransport.ts:34`). ⚠️ C'est **le seul** endroit du lexique où
+Contrat `IRealtimeTransport` (`IRealtimeTransport.ts#IRealtimeTransport`). ⚠️ C'est **le seul** endroit du lexique où
 « socket » pourrait désigner la connexion réseau : ici, ce mot est réservé à la
 [prise applicative](#socket--la-prise-que-tient-ton-code).
 
@@ -494,7 +498,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#RpcEnvelope`), `RpcMeta` (`JsonRpcPeer.ts#RpcMeta`).
 
 ### `cadence` — la fréquence portée par le nom
 
@@ -502,7 +506,7 @@ La fréquence d'un canal d'état vit **dans son nom** : `nodefony:orm:health` =
 `nodefony:orm:health:2000` = un rythme explicite. Conséquence voulue : **un canal, une cadence, un
 comptage** — deux cadences sont deux canaux, jamais réconciliés.
 
-`rateChannel()` (`channelRate.ts:44`) côté client, `parseRate()` (`channelRate.ts:63`) côté serveur —
+`rateChannel()` (`channelRate.ts#rateChannel`) côté client, `parseRate()` (`channelRate.ts#parseRate`) côté serveur —
 même fichier, donc même règle des deux côtés.
 
 ### `AIMD` — s'ajuster au client lent
@@ -511,8 +515,8 @@ _Additive Increase, Multiplicative Decrease_ : accélérer par petits pas quand
 d'un coup à la moindre congestion. Le principe de régulation de TCP, appliqué **par canal** à partir
 de ce qui reste en attente dans la connexion.
 
-`AdaptiveRate` (`AdaptiveRate.ts:78`), liaison sur un canal par `bindAdaptiveChannel()`
-(`AdaptiveRate.ts:239`).
+`AdaptiveRate` (`AdaptiveRate.ts#AdaptiveRate`), liaison sur un canal par `bindAdaptiveChannel()`
+(`AdaptiveRate.ts#bindAdaptiveChannel`).
 
 ## 🧩 Le cluster — franchir la frontière du process
 
@@ -534,8 +538,8 @@ Le **fond de panier** d'un rack : la carte qui relie toutes les autres. Ici, le
 publications d'un process aux autres. Un contrat volontairement minuscule — `publish`, `onMessage`,
 `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`).
+`IBackplane` (`IBackplane.ts#IBackplane`), message `IBackplaneMessage` (`IBackplane.ts#IBackplaneMessage`), branchement
+`RealtimeHub.setBackplane()` (`RealtimeHub.ts#RealtimeHub.setBackplane`).
 
 > [!TIP]
 > C'est la pièce qui tient la promesse « une ligne de configuration change tout » : le hub **ne sait
@@ -544,11 +548,11 @@ publications d'un process aux autres. Un contrat volontairement minuscule — `p
 ### `driver` — l'implémentation du transport
 
 Le backplane est un **contrat** ; un driver en est une réalisation, désignée par son **nom** dans la
-configuration (`backplane.driver`, `config.ts:47`). Un registre associe nom → fabrique : aucune
+configuration (`backplane.driver`, `config.ts#backplaneSchema`). Un registre associe nom → fabrique : aucune
 cascade de conditions, et n'importe qui peut enregistrer le sien.
 
-`registerBackplaneDriver()` (`backplaneRegistry.ts:55`), `listBackplaneDrivers()`
-(`backplaneRegistry.ts:68`). Un nom inconnu au démarrage n'arrête rien : le hub reste local, avec un
+`registerBackplaneDriver()` (`backplaneRegistry.ts#registerBackplaneDriver`), `listBackplaneDrivers()`
+(`backplaneRegistry.ts#listBackplaneDrivers`). Un nom inconnu au démarrage n'arrête rien : le hub reste local, avec un
 avertissement.
 
 ### `loopback` — un seul process
@@ -556,14 +560,14 @@ avertissement.
 Le driver du cas mono-process : il n'y a **rien à transporter**, le hub fait tout localement. C'est
 le défaut, et il ne coûte rien.
 
-`LoopbackBackplane` (`LoopbackBackplane.ts:24`).
+`LoopbackBackplane` (`LoopbackBackplane.ts#LoopbackBackplane`).
 
 ### `cluster` — entre workers d'une machine
 
 Le driver qui relie les workers d'un même hôte par le canal de communication inter-process de Node.
 Multi-process sans aucune infrastructure à installer.
 
-`ClusterBackplane` (`ClusterBackplane.ts:89`).
+`ClusterBackplane` (`ClusterBackplane.ts#ClusterBackplane`).
 
 ### `redis` — entre machines
 
@@ -571,7 +575,7 @@ Le driver qui propage les publications en pub/sub, donc entre pods de machines d
 consomme les connexions du module Redis — jamais une dépendance directe. Absent ou injoignable, le
 hub reste local et le démarrage continue.
 
-`RedisBackplane` (`RedisBackplane.ts:193`), canal `resolveRedisChannel()` (`RedisBackplane.ts:31`).
+`RedisBackplane` (`RedisBackplane.ts#RedisBackplane`), canal `resolveRedisChannel()` (`RedisBackplane.ts#resolveRedisChannel`).
 
 ### `origine` (originId) — qui a émis
 
@@ -579,7 +583,7 @@ L'identifiant **unique dans le cluster** du process émetteur, joint à chaque m
 du nom du pod ou de l'hôte, jamais du seul identifiant de processus : deux conteneurs peuvent tous
 deux être le processus n° 1.
 
-`resolveBackplaneOriginId()` (`originId.ts:24`), champ `IBackplane.originId` (`IBackplane.ts:77`).
+`resolveBackplaneOriginId()` (`originId.ts#resolveBackplaneOriginId`), champ `IBackplane.originId` (`IBackplane.ts#IBackplaneInfo.kind`).
 
 ### `anti-écho` — ne pas rejouer sa propre voix
 
@@ -587,7 +591,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#RealtimeHub.publishLocal`).
 
 ### `cloison` (namespace) — deux applications, un même bus
 
@@ -595,8 +599,8 @@ Le suffixe qui isole les canaux d'une application sur un transport mutualisé. N
 numéro de base d'un serveur Redis **ne cloisonne pas** le pub/sub : sans cloison, deux déploiements
 partageant le même serveur se parleraient.
 
-`backplane.namespace` (`config.ts:59`), constante de base `REDIS_RT_CHANNEL`
-(`RedisBackplane.ts:20`).
+`backplane.namespace` (`config.ts#backplaneSchema`), constante de base `REDIS_RT_CHANNEL`
+(`RedisBackplane.ts#REDIS_RT_CHANNEL`).
 
 ### `cross-pod` — la propriété qui compte
 
@@ -604,7 +608,7 @@ L'information que chaque driver déclare sur lui-même : sait-il franchir la mac
 dans la carte d'identité du backplane, journalisée au démarrage et lisible dans la sonde — c'est ce
 qui permet de vérifier en une ligne qu'un déploiement diffuse bien au-delà d'un pod.
 
-`IBackplaneInfo` (`IBackplane.ts:74`).
+`IBackplaneInfo` (`IBackplane.ts#IBackplaneInfo`).
 
 ## 🔐 La sécurité — qui parle, qui a le droit
 
@@ -629,8 +633,8 @@ Le moment de l'ouverture : c'est **là**, et une seule fois, que l'origine est c
 l'authenticator tourne et que l'identité est figée. Tout ce qui coûte cher se paie ici, jamais par
 frame.
 
-DTO neutre `IRealtimeHandshake` (`IRealtimeHandshake.ts:14`) — en-têtes, cookies, URL, origine,
-sous-protocoles. Traitement dans `onHandshake()` (`RealtimeController.ts:374`).
+DTO neutre `IRealtimeHandshake` (`IRealtimeHandshake.ts#IRealtimeHandshake`) — en-têtes, cookies, URL, origine,
+sous-protocoles. Traitement dans `onHandshake()` (`RealtimeController.ts#RealtimeController.onHandshake`).
 
 ### `authenticator` — du handshake à l'identité
 
@@ -638,24 +642,24 @@ La stratégie qui transforme une poignée de main en identité : `supports` (est
 `authenticate` (voici le jeton), `onSuccess` / `onFailure`. Exactement le motif des authenticators
 HTTP — un seul modèle mental pour les deux transports.
 
-`IRealtimeAuthenticator` (`IRealtimeAuthenticator.ts:24`), enregistrement
-`RealtimeHub.useAuthenticator()` (`RealtimeHub.ts:943`).
+`IRealtimeAuthenticator` (`IRealtimeAuthenticator.ts#IRealtimeAuthenticator`), enregistrement
+`RealtimeHub.useAuthenticator()` (`RealtimeHub.ts#RealtimeHub.useAuthenticator`).
 
 ### `matcher` — qui capture quoi
 
 Le sélecteur (motif d'URL, hôte optionnel) qui décide **quel** authenticator prend la connexion. Le
 **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`).
+`IRealtimeAuthenticatorMatcher` (`IRealtimeAuthenticatorMatcher.ts#IRealtimeAuthenticatorMatcher`), résolution
+`resolveAuthenticator()` (`RealtimeHub.ts#RealtimeHub.resolveAuthenticator`).
 
 ### `jeton` (token) — l'identité figée
 
 Ce que l'authenticator produit : type, identifiant, rôles, scopes, et parfois une méthode de
 re-validation. Il est mis en cache sur la connexion et **jamais** recalculé par frame.
 
-`IRealtimeToken` (`IRealtimeToken.ts:18`). La lecture ne rend **jamais** `null` : sans authenticator,
-c'est le jeton anonyme gelé `ANONYMOUS_REALTIME_TOKEN` (`AnonymousRealtimeToken.ts:18`) qui répond —
+`IRealtimeToken` (`IRealtimeToken.ts#IRealtimeToken`). La lecture ne rend **jamais** `null` : sans authenticator,
+c'est le jeton anonyme gelé `ANONYMOUS_REALTIME_TOKEN` (`AnonymousRealtimeToken.ts#ANONYMOUS_REALTIME_TOKEN`) qui répond —
 un refus a donc toujours un auteur identifiable.
 
 ### `politique de canal` — ce qu'un canal exige
@@ -663,8 +667,8 @@ un refus a donc toujours un auteur identifiable.
 Les exigences déclarées d'un canal : authentifié, rôles, scopes. Elles s'attachent au **nom** du
 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`).
+`IChannelPolicy` (`IChannelPolicy.ts#IChannelPolicy`), déclaration par `@RealtimeChannel`
+(`realtimeDecorators.ts#RealtimeChannel`), résolution `resolveChannelPolicy()` (`RealtimeHub.ts#RealtimeHub.resolveChannelPolicy`).
 
 ### `verrou de frame` — la décision par frame
 
@@ -672,8 +676,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#FrameAuthorizer`), pose `setFrameAuthorizer()` (`RealtimeHub.ts#RealtimeHub.setFrameAuthorizer`), appel
+`runAuthorizer()` (`RealtimeHub.ts#RealtimeHub.runAuthorizer`).
 
 ### `contrôle d'origine` — la défense d'ouverture
 
@@ -681,7 +685,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#OriginGuard`), configuration `csrf.checkOrigin` (`config.ts#csrfSchema`).
 
 ### `révocation` — la connexion qui survit à sa session
 
@@ -689,8 +693,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#RealtimeHub.registerRevocable`), `revalidateRevocable()` (`RealtimeHub.ts#RealtimeHub.revalidateRevocable`), période
+`REVOCATION_REVALIDATE_MS` (`RealtimeHub.ts#channelFamily`). Une re-validation en erreur **ferme** — jamais
 l'inverse.
 
 ### `refus` (denied) — rendre le « non » visible
@@ -699,8 +703,8 @@ Une notification refusée serait abandonnée en silence, laissant le client aveu
 donc `realtime:denied`. Le motif est **générique** : jamais le rôle ou le scope manquant, qui
 transformerait le refus en oracle d'autorisation.
 
-`IRealtimeDenied` (`RealtimeEventMap.ts:269`), conversion en message d'interface `deniedToNotice()`
-(`notice.ts:45`).
+`IRealtimeDenied` (`RealtimeEventMap.ts#IRealtimeDenied`), conversion en message d'interface `deniedToNotice()`
+(`notice.ts#deniedToNotice`).
 
 ### `audit de frame` — tracer le notable
 
@@ -708,7 +712,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#FrameAuditReason`), crochet `onFrameAudit` (`JsonRpcPeer.ts#JsonRpcPeerOptions.onFrameAudit`).
 
 ### `seam` — le point de greffe
 
@@ -716,8 +720,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#JsonRpcPeerOptions.beforeDispatch`) et `onFrameAudit`
+(`JsonRpcPeer.ts#JsonRpcPeerOptions.onFrameAudit`) ; 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.
 
@@ -727,8 +731,8 @@ Le nombre maximal de canaux qu'**une** connexion peut ouvrir. Chaque canal ouver
 ressources ; sans borne, une seule connexion peut les épuiser. Au-delà, l'abonnement est refusé et le
 client en est informé.
 
-`limits.maxChannelsPerConnection` (`config.ts:142`), pose `setMaxChannelsPerConnection()`
-(`RealtimeHub.ts:995`).
+`limits.maxChannelsPerConnection` (`config.ts#limitsSchema`), pose `setMaxChannelsPerConnection()`
+(`RealtimeHub.ts#RealtimeHub.setMaxChannelsPerConnection`).
 
 ## 📡 L'observabilité — ce que la socket dit d'elle-même
 
@@ -747,7 +751,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#RealtimeHub.probe`) rend un `IRealtimeProbe` (`IRealtimeProbe.ts#IRealtimeProbe`).
 
 > [!WARNING]
 > `IRealtimeProbe` est la **forme des données**, pas une interface à implémenter avec une méthode
@@ -759,34 +763,34 @@ 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#SLOW_CONSUMER_BYTES`) — 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#httpConfigSchema`).
 
 ### `consommateur lent` — la connexion qui décroche
 
 Une connexion dont le back-pressure dépasse le seuil de comptage. C'est une **métrique**, pas une
 sanction : le seuil de comptage se règle indépendamment des seuils d'action.
 
-`slowConsumer.bytes` (`config.ts:121`), champ `backpressure.slowConsumers`
-(`IRealtimeProbe.ts:102`).
+`slowConsumer.bytes` (`config.ts#slowConsumerSchema`), champ `backpressure.slowConsumers`
+(`IRealtimeProbe.ts#IRealtimeProbe.backpressure`).
 
 ### `compteurs de canal` — mesurés à l'arrivée
 
 Nombre de messages, date du dernier, débit instantané, historique glissant — par canal, calculés au
 point d'arrivée des frames, donc réutilisables par n'importe quelle application.
 
-`IChannelStats` (`IRealtimeSocket.ts:64`), côté serveur `IRealtimeChannelStat`
-(`IRealtimeProbe.ts:47`).
+`IChannelStats` (`IRealtimeSocket.ts#IChannelStats.method`), côté serveur `IRealtimeChannelStat`
+(`IRealtimeProbe.ts#IRealtimeChannelStat`).
 
 ### `santé agrégée` — la vue du pod entier
 
 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`
-(`IRealtimeProbe.ts:178`).
+`mergeClusterHealth()` (`ClusterProbeClient.ts#mergeClusterHealth`), forme `IRealtimeClusterHealth`
+(`IRealtimeProbe.ts#IRealtimeClusterHealth`).
 
 ### `plan de données admin` — la sonde servie à Studio
 
@@ -794,23 +798,23 @@ Le producteur qui expose la sonde sous `/nodefony/realtime/api/health`, selon la
 routage des administrations de modules. C'est de l'**auto-observabilité** : la socket se regarde
 elle-même par le même chemin que les autres modules.
 
-`createRealtimeAdminApi()` (`RealtimeAdminApi.ts:98`), construction `buildOwnHealth()`
-(`RealtimeAdminApi.ts:52`).
+`createRealtimeAdminApi()` (`RealtimeAdminApi.ts#createRealtimeAdminApi`), construction `buildOwnHealth()`
+(`RealtimeAdminApi.ts#buildOwnHealth`).
 
 ## ⚠️ Pièges — les faux-amis du vocabulaire
 
-| 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`)                           |
-| 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`)  |
-| « 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  |
+| 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#IRealtimeSocket.subscribe`)                  |
+| « Ç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#RealtimeBroadcast`)                                   |
+| « 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#RealtimeInbound`)                                                   |
+| 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#backplaneSchema`)                                                                   |
+| 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#resolveBackplaneOriginId`) 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#rateChannel`) 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#RealtimeHub.hasUnenforcedChannelPolicies`) |
+| 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#RealtimeHub.subscribeClient`)                            |
+| « 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#ChannelFactory`)                           |
+| « 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]
 > Deux mots à ne jamais intervertir en réunion : le **hub** tombe et **un** pod perd sa diffusion ;