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

package/docs/protocole.md

@@ -31,7 +31,7 @@ source: "src/packages/@nodefony/realtime/docs/protocole.md"
 > **frames** dont la forme est normée. Trois formes existent, et une seule règle les distingue —
 > **la nature d'une frame se lit sur `method`, jamais sur `id`**. Cette page donne la grammaire
 > champ par champ, les méthodes que le serveur comprend nativement, et ce qui revient exactement
-> quand ça rate. Le moteur est `JsonRpcPeer` (`JsonRpcPeer.ts:271`), écrit une fois et branché des
+> quand ça rate. Le moteur est `JsonRpcPeer` (`JsonRpcPeer.ts:311`), écrit une fois et branché des
 > deux côtés du fil.
 
 📍 [Documentation](../../../../../docs/index.md) › [Realtime](index.md) › **Protocole**
@@ -52,12 +52,12 @@ cœur du protocole : il décide s'il faut répondre, à qui, et si une réponse
 
 ```mermaid
 flowchart TD
-  IN["Frame entrante (JSON déjà parsé)"] --> V{"jsonrpc = 2.0 ?"}
+  IN["Frame entrante (JSON déjà parsé)"] --> V{"frame JSON-RPC 2.0 valide ?"}
   V -->|non| INV["invalid — auditée, AUCUNE réponse"]
   V -->|oui| M{"method présent ?"}
   M -->|"method + id"| REQ["requête — un handler doit rendre result ou error"]
   M -->|"method seul"| NOT["notification — pub/sub, aucune réponse"]
-  M -->|"id seul"| RES["réponse — résout une requête sortante en attente"]
+  M -->|"id + result ou error"| RES["réponse — résout une requête sortante en attente"]
   REQ --> OUT["result · error"]
   NOT --> HUB["subscribe · unsubscribe · canal entrant"]
   RES --> PROM["la Promise de l'appelant"]
@@ -79,7 +79,7 @@ Deux conséquences que le reste de la page décline :
 | Pair (peer)      | Le moteur de protocole d'une connexion — `JsonRpcPeer`, identique client et serveur.  |
 | Requête          | Frame avec `method` **et** `id` — appelle exactement une réponse.                     |
 | Notification     | Frame avec `method` seul — aucune réponse, jamais.                                    |
-| Réponse          | Frame avec `id` seul, portant `result` **ou** `error`.                                |
+| Réponse          | Frame avec `id` sans `method`, portant `result` **ou** `error` bien formé.            |
 | Dispatch         | Classer une frame entrante puis la router vers son handler.                           |
 | Enveloppe        | Réponse qui joint des métadonnées serveur dans un champ **frère** du `result`.        |
 | Accueil, welcome | La 1ʳᵉ notification poussée par le serveur : protocole, canaux, actions, identité.    |
@@ -106,7 +106,7 @@ Nodefony ne l'a pas inventée. Le calcul, mis à plat :
 
 > [!NOTE]
 > **Le batch est une propriété de la norme, pas du moteur Nodefony.** `JsonRpcPeer.receive()`
-> (`JsonRpcPeer.ts:390`) attend un **objet** portant `jsonrpc: "2.0"` ; un tableau de frames n'en
+> (`JsonRpcPeer.ts:419`) attend un **objet** portant `jsonrpc: "2.0"` ; un tableau de frames n'en
 > porte pas et tombe donc en `invalid`. Une frame = un objet. Le multiplexage rend le batch peu
 > utile ici : les canaux voyagent déjà dans la même connexion.
 
@@ -118,21 +118,25 @@ d'une action. La norme fournit la grammaire ; le vocabulaire est nodefonien.
 
 Trois partis pris distinguent cette implémentation d'un simple « serveur WebSocket qui parle JSON ».
 
-**Le même fichier tourne dans le navigateur et dans Node.** `JsonRpcPeer` (`JsonRpcPeer.ts:271`)
+**Le même fichier tourne dans le navigateur et dans Node.** `JsonRpcPeer` (`JsonRpcPeer.ts:311`)
 n'a aucune dépendance Node — seulement `setTimeout`. Classer, router, corréler les `id` : ce travail
 est identique des deux côtés, il est donc écrit **une seule fois**. Chaque côté l'entoure de son
 transport et de ses handlers. Historiquement, cette discrimination vivait à deux endroits qui
-divergeaient ; c'est précisément la classe de bug que l'isomorphisme supprime.
+divergeaient ; c'est précisément la classe de bug que l'isomorphisme supprime. Le classement
+lui-même est `classifyJsonRpcFrame` (`jsonrpc/index.ts:178`), la brique que partage aussi le
+serveur MCP du framework : les deux portes ne peuvent plus diverger sur ce qu'est une frame valide.
 
 **Le rôle se lit sur `method`, pas sur `id`.** La lecture naïve (« `id` présent = requête ») casse
 sur les réponses, qui portent un `id` sans être des appels. `JsonRpcPeer.receive()`
-(`JsonRpcPeer.ts:390`) teste donc `method` d'abord, puis la présence d'un `id`. Une frame `id` seul
-est une **réponse** et ne déclenche jamais `-32601` à tort.
+(`JsonRpcPeer.ts:419`) teste donc `method` d'abord, puis la présence d'un `id` — chaîne ou nombre :
+un `id` `null`, objet ou booléen rend la frame `invalid`, il n'en fait pas une notification. Une
+frame `id` sans `method`, portant `result` ou une `error` bien formée, est une **réponse** et ne
+déclenche jamais `-32601` à tort ; sans l'un ni l'autre, elle est `invalid`.
 
 **Un échec ne raconte rien par défaut.** Un handler qui lève une exception ordinaire produit un
-`-32603 "internal error"` **générique** (`JsonRpcPeer.ts:528`) : ni message d'origine, ni pile
+`-32603 "internal error"` **générique** (`JsonRpcPeer.ts:573`) : ni message d'origine, ni pile
 d'appels. Pour exposer volontairement un refus au pair — un 404, un droit manquant — il existe une
-porte explicite, `RpcError` (`JsonRpcPeer.ts:70`), et elle seule.
+porte explicite, `RpcError` (`JsonRpcPeer.ts:101`), et elle seule.
 
 ## 🚀 Démarrage rapide
 
@@ -202,14 +206,14 @@ export default ChatController;
 
 ```ts
 // frontend/src/chat.ts
-import { RealtimeClient, RpcError } from "nodefony/client";
+import { NodefonySocket, RpcError } from "nodefony/client";
 
 interface ChatHistory {
   messages: string[];
 }
 
 export async function joinChat(): Promise<void> {
-  const socket = new RealtimeClient({
+  const socket = new NodefonySocket({
     url: "wss://127.0.0.1:5152/chat/realtime",
   });
   await socket.connect();
@@ -268,7 +272,7 @@ L'accueil porte cinq champs — `ts`, `protocol`, `channels`, `methods`, `identi
 (`IRealtimeWelcome`, `RealtimeEventMap.ts:231`) — plus un sixième, `env`, **uniquement hors
 production** (`welcomeEnv()`, `welcomeEnv.ts:19`) : c'est lui que porte l'exemple ci-dessus, capturé
 en développement. Émis par le contrôleur au handshake (`peer.notify("realtime:welcome")`,
-`RealtimeController.ts:708`). Il n'y a pas de champ `version`.
+`RealtimeController.ts:796`). Il n'y a pas de champ `version`.
 
 ## 🔌 Anatomie d'une frame, champ par champ
 
@@ -285,7 +289,7 @@ en développement. Émis par le contrôleur au handshake (`peer.notify("realtime
 
 | Champ     | Obligatoire               | Type accepté         | Rôle exact                                                                |
 | --------- | ------------------------- | -------------------- | ------------------------------------------------------------------------- |
-| `jsonrpc` | oui, toujours             | `"2.0"` littéral     | Sans lui, `JsonRpcPeer.receive()` classe `invalid` (`JsonRpcPeer.ts:371`) |
+| `jsonrpc` | oui, toujours             | `"2.0"` littéral     | Sans lui, `JsonRpcPeer.receive()` classe `invalid` (`JsonRpcPeer.ts:419`) |
 | `method`  | sur un appel              | chaîne               | Décide de la nature ET de l'aiguillage (canal, action, verbe pub/sub)     |
 | `params`  | non                       | tout JSON            | Charge applicative. Vient du réseau : **jamais** digne de confiance       |
 | `id`      | sur une requête / réponse | nombre **ou** chaîne | Corrèle l'aller et le retour                                              |
@@ -293,7 +297,7 @@ en développement. Émis par le contrôleur au handshake (`peer.notify("realtime
 > [!IMPORTANT]
 > Le pair accepte un `id` **chaîne** en entrée (conforme à la norme), mais il n'attribue jamais que
 > des `id` **numériques** à ses propres appels sortants. Une réponse portant un `id` chaîne est donc
-> ignorée sans erreur (`JsonRpcPeer.handleResponse()`, `JsonRpcPeer.ts:556`) : elle ne peut, par
+> ignorée sans erreur (`JsonRpcPeer.handleResponse()`, `JsonRpcPeer.ts:579`) : elle ne peut, par
 > construction, correspondre à aucune requête émise par ce pair.
 
 ### La réponse — `result` ou `error`, jamais les deux
@@ -312,9 +316,9 @@ distinguer un 404 d'un refus d'autorisation sans analyser un message de texte.
 
 ### L'enveloppe — joindre une méta sans polluer le `result`
 
-Un handler peut rendre une `RpcEnvelope` (`JsonRpcPeer.ts:104`) au lieu d'une valeur nue. Le pair la
+Un handler peut rendre une `RpcEnvelope` (`JsonRpcPeer.ts:139`) au lieu d'une valeur nue. Le pair la
 déballe : le `result` reste **exactement** la valeur, et la méta voyage dans un champ frère
-`meta` (`RpcMeta`, `JsonRpcPeer.ts:90`).
+`meta` (`RpcMeta`, `JsonRpcPeer.ts:125`).
 
 ```jsonc
 {
@@ -337,20 +341,20 @@ ouvertes à l'application. Colonne `id` : présent = requête (réponse due), ab
 
 | Méthode            | Direction     | `id` ?  | Rôle                                                                  | Ancrage                     |
 | ------------------ | ------------- | :-----: | --------------------------------------------------------------------- | --------------------------- |
-| `subscribe`        | client→server |   non   | « pousse-moi ce canal » — `params.channel`                            | `RealtimeController.ts:522` |
-| `unsubscribe`      | client→server |   non   | « arrête » — dernier abonné, le producteur est libéré                 | `RealtimeController.ts:775` |
-| `ping`             | client→server |   non   | Battement de cœur — **no-op serveur**, aucun pong                     | `RealtimeClient.ts:882`     |
-| `<canal>`          | server→client |   non   | Push d'un message : le **nom du canal est la `method`**               | `RealtimeController.ts:972` |
-| `<canal entrant>`  | client→server |   non   | Le client pousse sur un canal déclaré entrant                         | `RealtimeController.ts:736` |
-| `realtime:welcome` | server→client |   non   | L'accueil : 5 champs, dont l'identité résolue                         | `RealtimeController.ts:693` |
-| `realtime:denied`  | server→client |   non   | Rend OBSERVABLE le refus d'une notification                           | `RealtimeController.ts:496` |
-| `api.request`      | client→server | **oui** | Pont API — rejoue une route HTTP sur la socket (désactivé par défaut) | `RealtimeController.ts:582` |
-| `<action>`         | client→server | **oui** | Toute action déclarée par `@RealtimeAction`                           | `realtimeDecorators.ts:101` |
+| `subscribe`        | client→server |   non   | « pousse-moi ce canal » — `params.channel`                            | `RealtimeController.ts:577` |
+| `unsubscribe`      | client→server |   non   | « arrête » — dernier abonné, le producteur est libéré                 | `RealtimeController.ts:849` |
+| `ping`             | client→server |   non   | Battement de cœur — **no-op serveur**, aucun pong                     | `NodefonySocket.ts:1085`    |
+| `<canal>`          | server→client |   non   | Push d'un message : le **nom du canal est la `method`** du `notify`   | `RealtimeController.ts:874` |
+| `<canal entrant>`  | client→server |   non   | Le client pousse sur un canal déclaré entrant                         | `RealtimeController.ts:825` |
+| `realtime:welcome` | server→client |   non   | L'accueil : 5 champs, dont l'identité résolue                         | `RealtimeController.ts:796` |
+| `realtime:denied`  | server→client |   non   | Rend OBSERVABLE le refus d'une notification                           | `RealtimeController.ts:573` |
+| `api.request`      | client→server | **oui** | Pont API — rejoue une route HTTP sur la socket (désactivé par défaut) | `RealtimeController.ts:651` |
+| `<action>`         | client→server | **oui** | Toute action déclarée par `@RealtimeAction`                           | `realtimeDecorators.ts:191` |
 
 > [!TIP]
 > **L'accueil est ta carte du territoire.** `channels` ne liste que les canaux que ce visiteur
 > pourrait obtenir (filtrés par le même verrou que `subscribe`), `methods` les actions de l'endpoint
-> (`RealtimeController.ts:710`) : un client peut activer ou griser
+> (`RealtimeController.ts:786`) : un client peut activer ou griser
 > ses commandes sans rien coder en dur. Côté navigateur, ils se lisent en `socket.serverMethods` et
 > `socket.serverChannels`.
 
@@ -360,12 +364,12 @@ Les quatre formes de frame circulent en permanence sous tes yeux — ce schéma
 > `nodefony:kernel:ping` et `nodefony:kernel:gc` (`StudioRealtimeController.ts:114`) sont des exemples d'actions,
 > **pas des méthodes du cœur temps réel** : elles sont déclarées par le contrôleur
 > d'administration de `@nodefony/studio`. Un endpoint applicatif ne les expose pas. Le helper
-> `RealtimeClient.ping()` (`RealtimeClient.ts:878`) mesure le RTT en les appelant — il suppose donc
+> `NodefonySocket.ping()` (`NodefonySocket.ts:1085`) mesure le RTT en les appelant — il suppose donc
 > un endpoint qui les déclare, contrairement à la notification `ping` du battement de cœur, qui
 > n'attend jamais de réponse.
 
 `subscribe` et `unsubscribe` ne sont **pas** des actions enregistrées : elles sont traitées dans
-`onRealtimeNotification()` (`RealtimeController.ts:784`). Envoyées avec un `id`, elles seraient
+`onRealtimeNotification()` (`RealtimeController.ts:840`). Envoyées avec un `id`, elles seraient
 classées « requête », ne trouveraient aucun handler et récolteraient un `-32601`.
 
 ## Une conversation type, de bout en bout
@@ -397,52 +401,59 @@ Voici **tout** ce que le moteur produit. Les codes de la plage `-32000`…`-3209
 la norme aux erreurs applicatives serveur ; Nodefony y place son refus d'autorisation et le défaut
 de `RpcError`.
 
-| Code     | Émis par                                                   | Déclencheur                                         | Ce que voit le pair                            |
-| -------- | ---------------------------------------------------------- | --------------------------------------------------- | ---------------------------------------------- |
-| `-32601` | `JsonRpcPeer.handleRequest()` (`JsonRpcPeer.ts:499`)       | requête vers une action non enregistrée             | `method not found: <nom>`                      |
-| `-32603` | même méthode (`JsonRpcPeer.ts:528`)                        | le handler a levé une exception **ordinaire**       | `internal error` — générique, rien d'autre     |
-| `-32001` | le refus du verrou de frame (`JsonRpcPeer.ts:400`)         | `beforeDispatch` a dit non **sur une requête**      | `unauthorized`, sans jamais dire pourquoi      |
-| `-32000` | défaut du constructeur de `RpcError` (`JsonRpcPeer.ts:74`) | le handler expose volontairement son refus          | le message ET le `data` choisis par le handler |
-| `-32602` | le pont API, via `RpcError` (`RealtimeController.ts:787`)  | `api.request` appelé avec un `params.path` invalide | message explicite (l'appel est malformé)       |
+| Code     | Émis par                                                    | Déclencheur                                         | Ce que voit le pair                            |
+| -------- | ----------------------------------------------------------- | --------------------------------------------------- | ---------------------------------------------- |
+| `-32601` | `JsonRpcPeer.handleRequest()` (`JsonRpcPeer.ts:526`)        | requête vers une action non enregistrée             | `method not found: <nom>`                      |
+| `-32603` | même méthode (`JsonRpcPeer.ts:573`)                         | le handler a levé une exception **ordinaire**       | `internal error` — générique, rien d'autre     |
+| `-32001` | le refus du verrou de frame (`JsonRpcPeer.ts:449`)          | `beforeDispatch` a dit non **sur une requête**      | `unauthorized`, sans jamais dire pourquoi      |
+| `-32000` | défaut du constructeur de `RpcError` (`JsonRpcPeer.ts:101`) | le handler expose volontairement son refus          | le message ET le `data` choisis par le handler |
+| `-32602` | le pont API, via `RpcError` (`RealtimeController.ts:1027`)  | `api.request` appelé avec un `params.path` invalide | message explicite (l'appel est malformé)       |
 
 Et un échec qui n'est **pas** une frame : l'expiration. `startCall()` ne reçoit rien dans le délai
 imparti, supprime l'entrée en attente et rejette localement avec `RPC timeout: <méthode>`
-(`JsonRpcPeer.ts:428`). Défaut de 30 000 ms, réglable par appel. Aucun octet ne part sur le fil : c'est une décision du
+(`JsonRpcPeer.ts:502`). Défaut de 30 000 ms, réglable par appel. Aucun octet ne part sur le fil : c'est une décision du
 client, le serveur peut très bien répondre après, sa réponse sera ignorée.
 
+L'inverse n'attend pas : une frame qui porte l'`id` d'une requête en attente sans être une réponse
+valide — ni `result` ni `error` bien formé — fait échouer l'appel **aussitôt**, en `RpcError`
+`-32603` « réponse JSON-RPC invalide » (`JsonRpcPeer.ts:611`). Si elle porte `result` ET une `error`
+bien formée (la norme l'interdit), l'erreur annoncée est rendue telle quelle. Rien ne part sur le
+fil : c'est un échec local, et la frame est auditée `invalid`.
+
 ### Les deux codes de la norme que Nodefony n'émet jamais
 
 `-32700 Parse error` et `-32600 Invalid Request` figurent dans la norme, mais **aucune frame ne les
 porte** ici :
 
 - un JSON illisible n'atteint même pas le pair — le contrôleur l'abandonne à la lecture
-  (`RealtimeController.ts:446`) ;
-- une frame lisible mais non conforme (pas d'objet, `jsonrpc` absent ou faux) est classée `invalid`,
-  signalée à l'audit, et **rien n'est renvoyé** (`JsonRpcPeer.ts:429`).
+  (`RealtimeController.ts:586`) ;
+- une frame lisible mais non conforme — pas d'objet, un lot, `jsonrpc` absent ou faux, `id` `null`,
+  objet ou booléen, `method` non chaîne, réponse sans `result` ni `error` bien formé, ou avec les
+  deux — est classée `invalid`, signalée à l'audit, et **rien n'est renvoyé** (`JsonRpcPeer.ts:423`).
 
 Le choix est délibéré : une frame cassée n'a pas d'`id` digne de confiance, donc pas de corrélation
 possible ; et répondre systématiquement à du bruit offre à un attaquant un amplificateur gratuit.
-Le refus reste **traçable** — c'est le motif `invalid` de `FrameAuditReason` (`JsonRpcPeer.ts:155`),
+Le refus reste **traçable** — c'est le motif `invalid` de `FrameAuditReason` (`JsonRpcPeer.ts:182`),
 qui alimente le journal d'audit avec le pair concerné.
 
 ### Le refus d'une notification n'est pas une erreur
 
 C'est la subtilité la plus importante de la page. Le verrou de frame s'applique aux requêtes **et**
-aux notifications (`beforeDispatch`, `JsonRpcPeer.ts:192`), mais leurs conséquences diffèrent
+aux notifications (`beforeDispatch`, `JsonRpcPeer.ts:219`), mais leurs conséquences diffèrent
 radicalement :
 
 | La frame refusée est… | Ce qui part                                                     | Pourquoi                                             |
 | --------------------- | --------------------------------------------------------------- | ---------------------------------------------------- |
-| une **requête**       | `-32001 "unauthorized"` (`JsonRpcPeer.ts:413`)                  | Un `id` existe : il y a un canal de réponse          |
-| une **notification**  | la notification `realtime:denied` (`RealtimeController.ts:496`) | Aucun `id` : sans elle, le client se croirait abonné |
+| une **requête**       | `-32001 "unauthorized"` (`JsonRpcPeer.ts:449`)                  | Un `id` existe : il y a un canal de réponse          |
+| une **notification**  | la notification `realtime:denied` (`RealtimeController.ts:573`) | Aucun `id` : sans elle, le client se croirait abonné |
 
 `IRealtimeDenied` (`RealtimeEventMap.ts:269`) porte `channel` et `reason` — plus un `detail` optionnel, posé hors production seulement — et le motif
 est **générique**. Jamais « il te manque `ROLE_ADMIN` » : ce serait un oracle d'autorisation, un
 attaquant y lirait la carte des droits. Trois motifs circulent : `forbidden` (le verrou a dit non),
-`limit` (le plafond de canaux de la connexion est atteint, `RealtimeController.ts:811`) et `unknown`
+`limit` (le plafond de canaux de la connexion est atteint, `RealtimeController.ts:852`) et `unknown`
 (aucun producteur ne sert ce nom — jamais un oracle : un canal gardé rend `forbidden`, qu'il existe ou
 non). Côté client,
-`onDenied()` (`RealtimeClient.ts:469`) branche un handler dessus.
+`onDenied()` (`NodefonySocket.ts:678`) branche un handler dessus.
 
 > [!CAUTION]
 > Un `-32403 Forbidden` circule dans d'anciennes notes. **Ce code n'existe pas** dans Nodefony, et il
@@ -461,7 +472,7 @@ en découlent :
    politique du canal ; la demande a exactement la même forme qu'un abonnement autorisé, seule la
    réponse diffère.
 3. **Le client ne pousse que là où c'est déclaré.** Un canal n'accepte d'entrée que si un handler
-   entrant existe pour ce nom (`RealtimeController.ts:608`) ; sinon la notification est ignorée en
+   entrant existe pour ce nom (`RealtimeController.ts:825`) ; sinon la notification est ignorée en
    silence. Le défaut est fermé.
 
 Les mécanismes eux-mêmes — authenticator, verrou de frame, politique de canal, révocation — sont
@@ -469,19 +480,19 @@ décrits dans [la page sécurité](./securite.md).
 
 ## ⚠️ Pièges
 
-| Symptôme                                                         | Cause                                                                                                           | Correction                                                                        |
-| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
-| `subscribe` répond `-32601 method not found`                     | Envoyé **avec un `id`** : classé requête, or c'est une notification (`RealtimeController.ts:592`)               | L'émettre sans `id` — `socket.subscribe(canal)`                                   |
-| Le handler passé à `subscribe` n'est jamais appelé               | `RealtimeClient.subscribe()` prend **un seul** argument (`RealtimeClient.ts:532`)                               | `subscribe(canal)` **et** `on(canal, handler)`, deux gestes distincts             |
-| `request()` expire immédiatement, ou ignore le délai             | Signature **positionnelle** `(méthode, params, ms)` (`RealtimeClient.ts:727`) — un objet d'options n'est pas lu | `request(m, p, 5000)` ; le défaut est 30 000 ms                                   |
-| Un tableau de frames n'obtient aucune réponse                    | Le batch n'est pas implémenté : un tableau n'a pas de `jsonrpc` → `invalid` (`JsonRpcPeer.ts:371`)              | Une frame = un objet ; le multiplexage remplace le batch                          |
-| Une frame malformée ne renvoie **aucune** erreur                 | Ni `-32700` ni `-32600` ne sont émis — silence + audit (`JsonRpcPeer.ts:396`)                                   | Lire le motif `invalid` côté serveur, pas la réponse                              |
-| L'exception du serveur n'arrive jamais au client                 | Zero Trust : tout throw ordinaire devient `-32603` générique (`JsonRpcPeer.ts:528`)                             | Lever une `RpcError` pour exposer volontairement code et `data`                   |
-| Une notification refusée disparaît sans trace côté client        | Sans `id`, aucune réponse possible (`beforeDispatch`, `JsonRpcPeer.ts:151`)                                     | Écouter `realtime:denied` via `onDenied()` (`RealtimeClient.ts:471`)              |
-| `nodefony:kernel:ping` répond `-32601` sur mon endpoint          | L'action `nodefony:kernel:ping` est déclarée par `@nodefony/studio` (`StudioRealtimeController.ts:114`)         | Déclarer la sienne, ou lire `serverMethods` avant d'appeler                       |
-| Le battement de cœur ne renvoie aucun pong                       | La notification `ping` est un no-op serveur (`RealtimeController.ts:791`)                                       | Pour mesurer un RTT, utiliser une action RPC — `ping()` (`RealtimeClient.ts:878`) |
-| Une réponse reçue est ignorée sans message                       | Corrélation sur `id` **numériques** seulement (`JsonRpcPeer.ts:537`)                                            | Ne pas fabriquer soi-même de réponse à `id` chaîne                                |
-| Les premières frames envoyées après `connect()` semblent perdues | Le transport n'est branché qu'une fois le handshake terminé                                                     | Attendre `realtime:welcome` — le client le fait déjà                              |
+| Symptôme                                                         | Cause                                                                                                           | Correction                                                                         |
+| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
+| `subscribe` répond `-32601 method not found`                     | Envoyé **avec un `id`** : classé requête, or c'est une notification (`RealtimeController.ts:809`)               | L'émettre sans `id` — `socket.subscribe(canal)`                                    |
+| Le handler passé à `subscribe` n'est jamais appelé               | `NodefonySocket.subscribe()` prend **un seul** argument (`NodefonySocket.ts:739`)                               | `subscribe(canal)` **et** `on(canal, handler)`, deux gestes distincts              |
+| `request()` expire immédiatement, ou ignore le délai             | Signature **positionnelle** `(méthode, params, ms)` (`NodefonySocket.ts:936`) — un objet d'options n'est pas lu | `request(m, p, 5000)` ; le défaut est 30 000 ms                                    |
+| Un tableau de frames n'obtient aucune réponse                    | Le batch n'est pas implémenté : un tableau n'a pas de `jsonrpc` → `invalid` (`jsonrpc/index.ts:178`)            | Une frame = un objet ; le multiplexage remplace le batch                           |
+| Une frame malformée ne renvoie **aucune** erreur                 | Ni `-32700` ni `-32600` ne sont émis — silence + audit (`JsonRpcPeer.ts:423`)                                   | Lire le motif `invalid` côté serveur, pas la réponse                               |
+| L'exception du serveur n'arrive jamais au client                 | Zero Trust : tout throw ordinaire devient `-32603` générique (`JsonRpcPeer.ts:573`)                             | Lever une `RpcError` pour exposer volontairement code et `data`                    |
+| Une notification refusée disparaît sans trace côté client        | Sans `id`, aucune réponse possible (`beforeDispatch`, `JsonRpcPeer.ts:219`)                                     | Écouter `realtime:denied` via `onDenied()` (`NodefonySocket.ts:678`)               |
+| `nodefony:kernel:ping` répond `-32601` sur mon endpoint          | L'action `nodefony:kernel:ping` est déclarée par `@nodefony/studio` (`StudioRealtimeController.ts:114`)         | Déclarer la sienne, ou lire `serverMethods` avant d'appeler                        |
+| Le battement de cœur ne renvoie aucun pong                       | La notification `ping` est un no-op serveur (`RealtimeController.ts:831`)                                       | Pour mesurer un RTT, utiliser une action RPC — `ping()` (`NodefonySocket.ts:1085`) |
+| Une réponse reçue est ignorée sans message                       | Corrélation sur `id` **numériques** seulement (`JsonRpcPeer.ts:582`)                                            | Ne pas fabriquer soi-même de réponse à `id` chaîne                                 |
+| Les premières frames envoyées après `connect()` semblent perdues | Le transport n'est branché qu'une fois le handshake terminé                                                     | Attendre `realtime:welcome` — le client le fait déjà                               |
 
 ## 🧪 Tests & couverture
 
@@ -491,7 +502,7 @@ carte de l'aperçu, régénérée depuis les résultats réels — jamais figés
 
 - **Le moteur, dans le cœur** (`src/nodefony/src/tests/`) : `JsonRpcPeer.test.ts` (classement des
   frames, corrélation, timeout, erreurs), `JsonRpcPeer.types.test.ts` (le contrat générique tient à
-  la compilation), et la famille `RealtimeClient*.test.ts` — dispatch, identité annoncée par
+  la compilation), et la famille `NodefonySocket*.test.ts` — dispatch, identité annoncée par
   l'accueil, transport, `ping`. Ces suites **ne sont pas comptées** dans la carte du module
   `@nodefony/realtime` : elles appartiennent au workspace `nodefony`.
 - **Le câblage serveur, dans ce module** : `RealtimeController.test.ts` couvre les réponses
@@ -508,7 +519,7 @@ Couverture : `npm run coverage` dans `@nodefony/realtime` et dans le workspace `
 > [!CAUTION]
 > Plusieurs suites bout en bout exigent une infrastructure. **Un test sauté compte comme vert** :
 > avant de conclure « tout passe », vérifier les variables d'environnement — la source unique est
-> `vitest.gates.ts` à la racine, dont le rapport s'affiche en fin d'exécution.
+> `scripts/test/vitest/gates.ts` à la racine, dont le rapport s'affiche en fin d'exécution.
 
 ## 🔗 Pour aller plus loin
 

package/docs/securite.md

@@ -115,11 +115,11 @@ HTTP et WebSocket vivent dans le même contexte : la sécurité en hérite, **on
 politiques.**
 
 - Une zone du firewall couvre HTTP **et** WS par défaut (`realtime: true` —
-  `security/nodefony/config/config.ts:109`). L'opt-out est explicite ; un opt-in aurait été
+  `security/nodefony/config/config.ts:132`). L'opt-out est explicite ; un opt-in aurait été
   _fail-open_ (une zone qui oublie le flag laisserait le WS anonyme).
 - Le verrou de frame consulte la **même** fonction de match que le HTTP, `Firewall.matchPath()`
-  (`firewall.ts:719`), et la **même** hiérarchie de rôles, `Firewall.hasRole()`
-  (`firewall.ts:482`). Invariant par construction : `api.request {path}` n'accorde jamais plus que
+  (`firewall.ts:783`), et la **même** hiérarchie de rôles, `Firewall.hasRole()`
+  (`firewall.ts:521`). Invariant par construction : `api.request {path}` n'accorde jamais plus que
   `GET {path}`.
 - L'identité du handshake est celle du firewall HTTP : `FirewallRealtimeAuthenticator`
   (`FirewallRealtimeAuthenticator.ts:57`) ne relit ni cookie ni base, il **promeut** l'`IUser` déjà
@@ -220,9 +220,9 @@ refus est **visible**, jamais un silence.
 
 ```typescript
 // frontend — le client isomorphe du core
-import { RealtimeClient } from "nodefony/client";
+import { NodefonySocket } from "nodefony/client";
 
-const socket = new RealtimeClient({ url: "wss://app.exemple.com/rt/orders" });
+const socket = new NodefonySocket({ url: "wss://app.exemple.com/rt/orders" });
 
 // Refus poussés par le serveur — première classe côté client.
 socket.onDenied((denied) => {
@@ -261,13 +261,13 @@ Nodefony pose **deux barrières successives**, à deux étages différents.
 | Allowlist stricte    | `@nodefony/realtime` | **inactif** (`enabled: false`)      | configurable  | `close 4003` |
 
 **Barrière 1 — transport, active sans rien faire.** `HttpKernel.checkWebsocketOrigin()`
-(`http-kernel.ts:621`) exige que l'`Origin` du handshake corresponde au `Host` servi, avec tolérance
+(`http-kernel.ts:724`) exige que l'`Origin` du handshake corresponde au `Host` servi, avec tolérance
 loopback en développement et une allowlist optionnelle (`allowedOrigins`,
-`http/nodefony/config/config.ts:552`) acceptant le hostname exact ou un wildcard à un label. Une
+`http/nodefony/config/config.ts:570`) acceptant le hostname exact ou un wildcard à un label. Une
 requête **sans** `Origin` est acceptée : un attaquant non-navigateur n'a pas besoin de CSWSH.
 
 **Barrière 2 — module realtime, opt-in et plus stricte.** `RealtimeHub.checkOrigin()`
-(`RealtimeHub.ts:986`) consulte une garde compilée une fois au boot par `buildOriginGuard()`
+(`RealtimeHub.ts:967`) consulte une garde compilée une fois au boot par `buildOriginGuard()`
 (`RealtimeService.ts:313`) depuis `checkOriginSchema` (`realtime/nodefony/config/config.ts:162`).
 Trois différences comptent :
 
@@ -292,18 +292,18 @@ n'est jamais traitée.
 
 ### Le pipeline exact
 
-`RealtimeController.onHandshake()` (`RealtimeController.ts:374`) exécute, une fois par connexion :
+`RealtimeController.onHandshake()` (`RealtimeController.ts:450`) exécute, une fois par connexion :
 
 1. Construction d'un DTO neutre `IRealtimeHandshake` par `buildHandshakeFromContext()`
-   (`RealtimeController.ts:1198`) — headers, cookies aplatis, url, origin, sous-protocoles. Aucune
+   (`RealtimeController.ts:1356`) — headers, cookies aplatis, url, origin, sous-protocoles. Aucune
    dépendance à `@nodefony/security` dans le contrat.
 2. Contrôle d'origine (verrou 1).
-3. Résolution de l'authenticator par `RealtimeHub.resolveAuthenticator()` (`RealtimeHub.ts:961`) :
+3. Résolution de l'authenticator par `RealtimeHub.resolveAuthenticator()` (`RealtimeHub.ts:943`) :
    les matchers sont testés dans l'ordre d'enregistrement, **le premier qui matche capture**.
 4. `authenticator.authenticate(handshake)` — **async autorisé** (on est en cold path, une fois par
    connexion : lire un store est acceptable ici, jamais par frame).
 5. Pose du token sur la WeakMap `peer → token` via `RealtimeHub.setTokenForPeer()`
-   (`RealtimeHub.ts:1018`), **avant** l'envoi du `welcome` : le lookup est garanti dès la première
+   (`RealtimeHub.ts:999`), **avant** l'envoi du `welcome` : le lookup est garanti dès la première
    frame.
 
 Un `throw` de `authenticate()` ferme la socket en `4001` « unauthorized », après un log `WARNING`
@@ -312,8 +312,8 @@ d'audit défectueux ne peut pas empêcher la fermeture.
 
 ### Les matchers — quelle porte, quel vigile
 
-`RealtimeHub.useAuthenticator()` (`RealtimeHub.ts:943`) associe un sélecteur à une stratégie.
-`compileMatcher()` (`RealtimeHub.ts:1418`) le compile une fois :
+`RealtimeHub.useAuthenticator()` (`RealtimeHub.ts:925`) associe un sélecteur à une stratégie.
+`compileMatcher()` (`RealtimeHub.ts:1399`) le compile une fois :
 
 - `pattern` chaîne → RegExp **préfixe ancrée**, méta-caractères échappés par `RegExp.escape`.
   `"/admin/"` matche `/admin/` et `/admin/foo`, littéralement.
@@ -321,16 +321,16 @@ d'audit défectueux ne peut pas empêcher la fermeture.
 - `host` optionnel → comparaison **stricte** (insensible à la casse) sur l'en-tête `Host`, sans
   wildcard.
 - Le match porte sur le **path**, query comprise, jamais sur l'URL absolue : `handshakePath()`
-  (`RealtimeController.ts:1250`) extrait `pathname + search` du `WebsocketContext.url`, qui est
+  (`RealtimeController.ts:1408`) extrait `pathname + search` du `WebsocketContext.url`, qui est
   absolu. Sans cette extraction, un matcher `^/nodefony/…` ne se déclencherait jamais.
 
 `@nodefony/security` enregistre ces matchers automatiquement dans `Firewall.#wireRealtime()`
-(`firewall.ts:279`) : **une instance d'authenticator par zone protégée**, car le hub dédoublonne par
+(`firewall.ts:306`) : **une instance d'authenticator par zone protégée**, car le hub dédoublonne par
 identité d'instance et une instance partagée n'enregistrerait que le premier matcher.
 
 ### Zero Trust — il y a toujours un token
 
-`RealtimeHub.getTokenForPeer()` (`RealtimeHub.ts:1030`) ne renvoie **jamais** `null` : à défaut de
+`RealtimeHub.getTokenForPeer()` (`RealtimeHub.ts:1011`) ne renvoie **jamais** `null` : à défaut de
 token posé, c'est `ANONYMOUS_REALTIME_TOKEN` (`AnonymousRealtimeToken.ts:18`), singleton gelé,
 `isAuthenticated() === false`, `roles: ["ROLE_ANONYMOUS"]`. Le code consommateur (verrou, audit)
 n'a jamais à écrire « et s'il n'y a pas de token ? ».
@@ -422,7 +422,7 @@ sequenceDiagram
   P-->>C: realtime:denied {channel, reason:"forbidden"}
 ```
 
-Le verrou est **strictement synchrone** — `FrameAuthorizer` (`RealtimeHub.ts:39`). Un `await` par
+Le verrou est **strictement synchrone** — `FrameAuthorizer` (`RealtimeHub.ts:40`). Un `await` par
 frame coûterait une microtask et sérialiserait le pipeline RPC de la connexion. Il ne lit que de la
 mémoire : le token déjà résolu, et la cible de la frame.
 
@@ -468,32 +468,32 @@ Trois durcissements méritent d'être connus :
   `authenticated: true`. Le test porte sur le **namespace du canal**, pas sur le préfixe de la règle
   qui a matché : un préfixe de config plus court ou altéré ne contourne rien.
 - **La config passe avant les défauts** — les règles de `realtimeChannels`
-  (`security/nodefony/config/config.ts:1130`) sont placées en tête, premier match gagnant. On peut
+  (`security/nodefony/config/config.ts:1447`) sont placées en tête, premier match gagnant. On peut
   donc re-cibler `nodefony:syslog` sur `ROLE_SECURITY_AUDITOR` ; on ne peut pas l'ouvrir à l'anonyme.
 
 Le canal du journal d'audit (`nodefony:audit`) est enregistré comme **canal système** sur le hub
-(`RealtimeHub.registerSystemChannel()`, `RealtimeHub.ts:1297`) : il devient servable par n'importe
+(`RealtimeHub.registerSystemChannel()`, `RealtimeHub.ts:1278`) : il devient servable par n'importe
 quel endpoint realtime, sans qu'aucun controller ne le connaisse — et il est gardé par sa règle
 dédiée. Son enregistrement est **couplé** à la pose du verrou (même condition), donc il n'existe
 jamais de canal d'audit non gardé.
 
 ### La policy métier — déclarer sur le canal
 
-`@RealtimeChannel(name, policy)` (`realtimeDecorators.ts:192`) et `@RealtimeInbound(name, policy)`
-(`realtimeDecorators.ts:231`) attachent un `IChannelPolicy` au **nom** du canal. Les trois axes sont
+`@RealtimeChannel(name, policy)` (`realtimeDecorators.ts:240`) et `@RealtimeInbound(name, policy)`
+(`realtimeDecorators.ts:278`) attachent un `IChannelPolicy` au **nom** du canal. Les trois axes sont
 cumulatifs (ET) ; un axe absent n'impose rien :
 
 | Axe             | Sens                                                                          | Évalué par                               |
 | --------------- | ----------------------------------------------------------------------------- | ---------------------------------------- |
 | `authenticated` | token non anonyme                                                             | `satisfies()` (`frameAuthorizer.ts:290`) |
-| `roles`         | un des rôles suffit, **hiérarchie comprise**                                  | `Firewall.hasRole()` (`firewall.ts:482`) |
+| `roles`         | un des rôles suffit, **hiérarchie comprise**                                  | `Firewall.hasRole()` (`firewall.ts:521`) |
 | `scopes`        | un des scopes suffit — axe API (JWT, clé API), une session BFF n'en porte pas | comparaison directe                      |
 
-Une policy **vide** n'est pas enregistrée : `definePolicy()` (`realtimeDecorators.ts:40`) ignore un
+Une policy **vide** n'est pas enregistrée : `definePolicy()` (`realtimeDecorators.ts:91`) ignore un
 objet sans contrainte — le canal reste libre, le registre reste vide. Les déclarations sont publiées
-au hub **au handshake**, pas au boot (`RealtimeHub.registerChannelPolicy()`, `RealtimeHub.ts:1127`,
+au hub **au handshake**, pas au boot (`RealtimeHub.registerChannelPolicy()`, `RealtimeHub.ts:1124`,
 idempotent) ; le décideur les relit par `RealtimeService.resolveChannelPolicy()`
-(`RealtimeService.ts:277`).
+(`RealtimeService.ts:291`).
 
 ### ⚠️ Une policy est attachée à un nom EXACT — les canaux dérivés n'héritent pas
 
@@ -508,7 +508,7 @@ là, le canal fonctionne, et le refus attendu n'arrive jamais.
 
 Le serveur le **dit** désormais. Au premier canal servi dynamiquement sans politique, alors que le
 module en déclare pour d'autres canaux, un avertissement est journalisé une fois
-(`RealtimeHub.noticeUnguardedDynamicChannel()`, `RealtimeHub.ts:1254`) :
+(`RealtimeHub.noticeUnguardedDynamicChannel()`, `RealtimeHub.ts:1251`) :
 
 ```
 le canal "chat:room:1000" est servi par une fabrique DYNAMIQUE et n'est couvert par AUCUNE
@@ -535,21 +535,21 @@ Le verrou n'existe que si quelqu'un le pose. Deux conditions doivent être vraie
 1. `@nodefony/security` est chargé, et
 2. au moins une zone a `security: true` **et** `realtime: true`.
 
-C'est exactement le test de `Firewall.#wireRealtime()` (`firewall.ts:279`) : sans zone qualifiante,
+C'est exactement le test de `Firewall.#wireRealtime()` (`firewall.ts:306`) : sans zone qualifiante,
 `wired` reste faux, `setFrameAuthorizer` n'est jamais appelé, et **aucune** policy de canal n'est
 évaluée — ni métier, ni système. `nodefony:syslog` redevient un canal ordinaire.
 
 Deuxième subtilité : `beforeDispatch` n'est branché sur une connexion que si le verrou est **déjà**
-posé au moment de son handshake (`RealtimeController.ts:504`, via
-`RealtimeHub.hasFrameAuthorizer()` — `RealtimeHub.ts:1058`). Choix de performance délibéré (un hub
+posé au moment de son handshake (`RealtimeController.ts:562`, via
+`RealtimeHub.hasFrameAuthorizer()` — `RealtimeHub.ts:1039`). Choix de performance délibéré (un hub
 non sécurisé garde un coût nul par frame), mais avec une conséquence : **une connexion ouverte avant
 la pose du verrou n'est jamais gardée**, et ce jusqu'à sa fermeture. En fonctionnement normal le
 firewall se construit au boot, avant tout trafic ; le cas ne se présente qu'en appelant
 `setFrameAuthorizer()` à chaud.
 
 **Le refus de dégrader en silence.** Quand des policies sont déclarées sans décideur câblé,
-`RealtimeHub.hasUnenforcedChannelPolicies()` (`RealtimeHub.ts:1117`) renvoie `true` et le controller
-émet un WARNING explicite, une seule fois par process (`RealtimeController.ts:558`) :
+`RealtimeHub.hasUnenforcedChannelPolicies()` (`RealtimeHub.ts:1098`) renvoie `true` et le controller
+émet un WARNING explicite, une seule fois par process (`RealtimeController.ts:639`) :
 
 ```text
 Realtime channel policies declared but NO frame authorizer is wired —
@@ -575,8 +575,8 @@ Le refus doit être observable sans devenir un oracle. Nodefony tranche ainsi :
 
 | Type de frame refusée               | Réponse au client                                                                |
 | ----------------------------------- | -------------------------------------------------------------------------------- |
-| Requête (avec `id`)                 | `-32001 "unauthorized"` — `JsonRpcPeer.receive()` (`JsonRpcPeer.ts:390`)         |
-| Notification (`subscribe`, inbound) | `realtime:denied { channel, reason: "forbidden" }` (`RealtimeController.ts:432`) |
+| Requête (avec `id`)                 | `-32001 "unauthorized"` — `JsonRpcPeer.receive()` (`JsonRpcPeer.ts:419`)         |
+| Notification (`subscribe`, inbound) | `realtime:denied { channel, reason: "forbidden" }` (`RealtimeController.ts:553`) |
 | Dépassement du plafond de canaux    | `realtime:denied { channel, reason: "limit" }`                                   |
 | Canal sans aucun producteur         | `realtime:denied { channel, reason: "unknown" }`                                 |
 
@@ -602,20 +602,20 @@ ne peut pas relire la session. Un administrateur qui se déconnecte garderait se
 
 Nodefony ferme l'écart par deux mécanismes de granularité différente.
 
-| Surface                     | Re-validation        | Fenêtre d'exposition | Où                                                                    |
-| --------------------------- | -------------------- | -------------------- | --------------------------------------------------------------------- |
-| `api.request` (data plane)  | **à chaque frame**   | nulle                | `RealtimeController.invokeApiRequest()` (`RealtimeController.ts:949`) |
-| `subscribe` / flux de canal | **périodique**, 30 s | ≤ 30 s               | `RealtimeHub.revalidateRevocable()` (`RealtimeHub.ts:826`)            |
+| Surface                     | Re-validation        | Fenêtre d'exposition | Où                                                                     |
+| --------------------------- | -------------------- | -------------------- | ---------------------------------------------------------------------- |
+| `api.request` (data plane)  | **à chaque frame**   | nulle                | `RealtimeController.invokeApiRequest()` (`RealtimeController.ts:1070`) |
+| `subscribe` / flux de canal | **périodique**, 30 s | ≤ 30 s               | `RealtimeHub.revalidateRevocable()` (`RealtimeHub.ts:815`)             |
 
 **Sur `api.request`**, `token.isValid()` est appelé avant l'exécution de l'action ; identité périmée
 ou changée → `-32000` avec `status: 401`, et le client bascule sur un `fetch` HTTP porteur du cookie
 courant. Une erreur de re-validation vaut refus (fail-closed).
 
 **Sur les canaux**, le hub n'inscrit au registre de révocation que les connexions dont le token porte
-`isValid` (`RealtimeController.ts:659`) — anonymes et JWT n'y entrent jamais, coût nul.
-`RealtimeHub.registerRevocable()` (`RealtimeHub.ts:794`) démarre un `setInterval` `unref` au premier
+`isValid` (`RealtimeController.ts:715`) — anonymes et JWT n'y entrent jamais, coût nul.
+`RealtimeHub.registerRevocable()` (`RealtimeHub.ts:796`) démarre un `setInterval` `unref` au premier
 inscrit et l'arrête dès que le registre se vide : zéro timer au repos. Période :
-`REVOCATION_REVALIDATE_MS` (`RealtimeHub.ts:111`), 30 s, alignée sur le heartbeat WS.
+`REVOCATION_REVALIDATE_MS` (`RealtimeHub.ts:112`), 30 s, alignée sur le heartbeat WS.
 
 Ce que `realtimeRevocation.attack.test.ts` prouve exactement :
 
@@ -629,7 +629,7 @@ Ce que `realtimeRevocation.attack.test.ts` prouve exactement :
 | registre vide                              | tick no-op, aucun crash                                  |
 
 La source de vérité côté security est `buildSessionRevalidator()`
-(`FirewallRealtimeAuthenticator.ts:240`) : il relit la session BFF **par son id capturé au handshake**
+(`FirewallRealtimeAuthenticator.ts:275`) : il relit la session BFF **par son id capturé au handshake**
 et vérifie qu'elle est toujours vivante **et toujours celle du même utilisateur** — ce second point
 attrape le changement de compte sur un navigateur partagé.
 
@@ -656,12 +656,12 @@ pas** borné.
 Chaque canal ouvert coûte un provider, un ticker et une entrée de Map. Sans borne, une connexion
 peut abonner jusqu'à l'OOM — un déni de service mémoire déclenché par **un seul** client.
 
-`RealtimeController.startChannel()` (`RealtimeController.ts:815`) refuse au-delà de
+`RealtimeController.startChannel()` (`RealtimeController.ts:869`) refuse au-delà de
 `limits.maxChannelsPerConnection` (`realtime/nodefony/config/config.ts:142`), défaut **256**,
 `null` pour illimité. Points prouvés par `realtimeChannelCap.attack.test.ts` :
 
 - le plafond est actif **même sans `RealtimeService`** — le hub porte le défaut 256
-  (`RealtimeHub.ts:374`), il n'y a pas de fenêtre où la garde n'existerait pas ;
+  (`RealtimeHub.ts:380`), il n'y a pas de fenêtre où la garde n'existerait pas ;
 - au-delà, le hub **n'est jamais appelé** : le canal n'est pas ouvert, aucun provider ne démarre ;
 - le refus est **observable** (`realtime:denied`, motif `limit`) ;
 - un re-`subscribe` d'un canal déjà tenu **ne consomme pas de slot** (l'idempotence est vérifiée
@@ -680,7 +680,7 @@ canaux). `WsConnectionTransport.send()` (`WsConnectionTransport.ts:82`) applique
 
 | `bufferedAmount`                                                                                 | Action                                                                                                                      |
 | ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- |
-| > `websocket.maxBackpressure` — 4 MiB par défaut (`http`, `http/nodefony/config/config.ts:1048`) | politique `websocket.backpressurePolicy` : `drop` (défaut) jette la frame — canaux d'état, le prochain snapshot la remplace |
+| > `websocket.maxBackpressure` — 4 MiB par défaut (`http`, `http/nodefony/config/config.ts:1226`) | politique `websocket.backpressurePolicy` : `drop` (défaut) jette la frame — canaux d'état, le prochain snapshot la remplace |
 | `websocket.backpressureCloseAfterDrops` drops CONSÉCUTIFS — 1000 par défaut                      | `close(1013)` « Try Again Later » ; le client se reconnecte et resynchronise                                                |
 
 ### Taille des messages entrants
@@ -728,9 +728,9 @@ Source unique des défauts : `realtimeConfigSchema` (`realtime/nodefony/config/c
 Cette section existe pour éviter une confiance mal placée. Chaque point est vérifié au code.
 
 **1. Il n'y a pas de frontière de canal entre modules.** Un nom de canal est une chaîne dans un
-registre global (`#channelPolicies` du hub singleton, `RealtimeHub.ts:325`). Rien n'empêche le
+registre global (`#channelPolicies` du hub singleton, `RealtimeHub.ts:327`). Rien n'empêche le
 controller du module A de servir un canal au nom d'un canal du module B, ni de déclarer une policy
-plus faible sur ce même nom — la déclaration la plus récente écrase (`RealtimeHub.ts:751`, idempotent
+plus faible sur ce même nom — la déclaration la plus récente écrase (`RealtimeHub.ts:757`, idempotent
 par écrasement). En pratique, l'exploitation exige que le controller fautif accepte le nom (sa
 factory doit renvoyer un provider), donc un override permissif de `createRealtimeChannel` ; et les
 namespaces réservés restent couverts par le plancher système **si** le verrou est posé. Une garde
@@ -769,7 +769,7 @@ n'est pas appliquée.
 | **RFC 6455 §7.4.2** (codes 4000-4999) | `4001` unauthorized / session revoked, `4003` origin not allowed                             |
 | **RFC 6455 §7.4.1 / registre IANA**   | `1008` Policy Violation (origine transport), `1009` Message Too Big, `1013` Try Again Later  |
 | **RFC 6455 §4.1**                     | `Sec-WebSocket-Protocol` normalisé en liste dans le DTO de handshake                         |
-| **RFC 7230 §5.4**                     | Comparaison du `Host` par le matcher d'authenticator                                         |
+| **RFC 9110 §7.2**                     | Comparaison du `Host` par le matcher d'authenticator                                         |
 | **JSON-RPC 2.0 §5.1**                 | `-32001` (plage `Server error`) pour une requête refusée, `-32602` pour des params invalides |
 | **OWASP WSTG-CLNT-10**                | Anti-CSWSH : validation d'`Origin` obligatoire, les navigateurs n'appliquent pas CORS aux WS |
 | **Zero Trust / OWASP A01**            | Zone protégée + anonyme = refus ; token toujours présent, jamais `null`                      |
@@ -777,7 +777,7 @@ n'est pas appliquée.
 ## 📡 Observabilité — Studio
 
 - **Santé de la socket** : `/nodefony/realtime/api/health`, alimenté par `RealtimeHub.probe()`
-  (`RealtimeHub.ts:865`) — canaux, abonnés, fan-out, connexions, back-pressure et carte d'identité
+  (`RealtimeHub.ts:847`) — canaux, abonnés, fan-out, connexions, back-pressure et carte d'identité
   du backplane. Un `drops` qui grimpe signale des clients en souffrance ; un `slowConsumers` non nul
   précède souvent une fermeture `1013`. Même snapshot en flux sur le canal `nodefony:socket`
   (namespace réservé : `ROLE_NODEFONY_ADMIN`).