@nodefony/devkit 10.0.0-alpha.1

package/dist/nodefony/service/DevkitService.js

@@ -0,0 +1,198 @@
+import defaults from "../config/config.js";
+import { buildCard } from "../src/card.js";
+import __decorateMetadata from "../../_virtual/_@oxc-project_runtime@0.148.0/helpers/esm/decorateMetadata.js";
+import __decorate from "../../_virtual/_@oxc-project_runtime@0.148.0/helpers/esm/decorate.js";
+import { Module, Nodefony, Service, extend, injectable, mcpDeclaredScopes } from "nodefony";
+//#region nodefony/service/DevkitService.ts
+/**
+* Réponse partagée quand la porte MCP n'est pas protégée — le cas par défaut.
+* Allouer un tableau vide pour dire « rien » est la dépense que la règle de
+* lazy-allocation proscrit.
+*/
+const EMPTY_PROTECTED_RESOURCES = Object.freeze([]);
+/**
+* Service principal du module — la logique vit ici, pas dans les controllers
+* (un controller traduit du HTTP/WS ; un service, lui, est réutilisable par la
+* CLI, un job, un autre module).
+*
+* Cycle : `constructor` (fusion défauts + config de l'app) → `init`
+* (branchements kernel) → méthodes métier.
+*
+* Un service porte DEUX noms, et c'est normal :
+*   `@injectable()`             → nomme la CLASSE (`DevkitService`),
+*                                 c'est ce qu'on écrit dans `@inject("…")`
+*   `super("devkit", …)` → nomme l'INSTANCE, sa clé dans le conteneur,
+*                                 c'est ce qu'on écrit dans `kernel.get("…")`
+* Les deux mènent à la MÊME instance : le conteneur les réconcilie via la classe.
+* (Le décorateur ne peut pas deviner la clé — il s'exécute au chargement de la
+* classe, le `super()` seulement à la construction.)
+*
+* ⚠️ Ne JAMAIS redéclarer `options` comme propriété : la classe `Service` parente
+* l'assigne déjà via le 4ᵉ argument du `super()`. On garde une référence typée
+* `cfg` pour lire la config sans se battre avec TypeScript.
+*
+* POUR L'UTILISER AILLEURS, deux voies, toutes deux légales :
+*
+* ```ts
+* // 1. INJECTION par le constructeur — la dépendance est DÉCLARÉE, donc le
+* //    conteneur l'ordonnance et elle se voit dans la signature (nom de CLASSE).
+* import { inject, injectable, Service, Module } from "nodefony";
+*
+* @injectable()
+* class ReportService extends Service {
+*   constructor(
+*     module: Module,
+*     @inject("DevkitService") private devkit: DevkitService,
+*   ) {
+*     super("report", module.container, module.notificationsCenter);
+*   }
+* }
+*
+* // 2. RÉSOLUTION par le conteneur, pour une dépendance tardive ou optionnelle
+* //    (nom d'INSTANCE).
+* const devkit = this.container.get("devkit");
+* ```
+*/
+let DevkitService = class DevkitService extends Service {
+	module;
+	cfg;
+	constructor(module) {
+		const merged = extend(true, {}, defaults, module.options ?? {});
+		super("devkit", module.container, module.notificationsCenter, merged);
+		this.module = module;
+		this.cfg = merged;
+	}
+	/**
+	* Hook de démarrage d'un service : appelé UNE fois par le kernel, après la
+	* construction. C'est ici qu'on s'abonne aux événements du kernel — jamais
+	* dans le constructeur, où le kernel n'est pas encore prêt.
+	*
+	* ⚠️ Il s'appelle `init`, pas `initialize`. Le kernel ne cherche que `init`
+	* (`guardServiceInitialize`) : une méthode nommée `initialize` sur un service
+	* n'est JAMAIS appelée, et rien ne le signale — le code y dort en silence.
+	* (`initialize` existe bien, mais sur un CONTROLLER, où il tourne à CHAQUE
+	* requête : deux cycles de vie distincts, d'où deux noms.)
+	*/
+	async init() {
+		this.log("service devkit initialisé", "DEBUG");
+		return this;
+	}
+	/**
+	* Carte de visite de l'application — recalculée à CHAQUE lecture.
+	*
+	* Tout est DÉRIVÉ de l'état du Kernel : le module ne stocke rien en propre, et
+	* ne peut donc pas décrire une application qui n'est plus celle-là. Un cache
+	* mentirait au premier module ajouté ; le coût ne le justifie pas (quelques
+	* lectures de champs, sur une route de développement appelée à la main).
+	*
+	* `buildCard` reste PURE et reçoit cet état : c'est la frontière qui rend la
+	* composition de la carte éprouvable sans Kernel ni serveur.
+	*/
+	getCard() {
+		const kernel = this.module.kernel;
+		return buildCard({
+			appName: kernel?.projectName ?? "application",
+			appVersion: kernel?.version ?? "0.0.0",
+			nodefonyVersion: Nodefony.version,
+			environment: kernel?.environment ?? "unknown",
+			modules: Object.keys(kernel?.modules ?? {}),
+			source: "runtime"
+		});
+	}
+	/**
+	* Réglages du serveur MCP, tels que l'application les a effectivement.
+	*
+	* La porte HTTP les LIT ici plutôt que de relire la configuration de son
+	* côté : les défauts du schéma sont déjà fusionnés avec ce que l'app a passé
+	* dans `use()`, une seconde lecture finirait par diverger de celle-ci.
+	*/
+	mcpSettings() {
+		return this.cfg.mcp;
+	}
+	/**
+	* Ce dont les outils MCP intégrés ont besoin pour répondre.
+	*
+	* Composé ICI, et non dans la porte HTTP, parce que DEUX questions les
+	* réclament — « que sert-on à cet appelant ? » (la porte) et « qu'exige cette
+	* porte ? » ({@link DevkitService.declaredMcpScopes}, lue sans requête, au
+	* moment de publier le document RFC 9728). Deux compositions auraient fini
+	* par diverger, et c'est le document publié qui aurait eu tort.
+	*
+	* @returns broker d'administration (absent si `@nodefony/framework` n'est pas
+	*          monté — les outils le DISENT alors, ils ne plantent pas), carte de
+	*          visite et racine de l'APPLICATION (jamais `process.cwd()` : le
+	*          serveur répond dans le process de l'app, dont le dossier courant
+	*          n'est pas garanti être celui du projet).
+	*/
+	mcpToolDeps() {
+		const kernel = this.module.kernel;
+		return {
+			broker: this.get("adminBroker") ?? void 0,
+			getCard: () => this.getCard(),
+			projectRoot: kernel?.path ?? process.cwd()
+		};
+	}
+	/**
+	* Les scopes que la porte MCP EXIGE — dérivés des outils qu'elle déclare.
+	*
+	* 🔴 **Aucune liste de configuration ne double celle-ci**, et c'est la
+	* correction d'un mensonge normatif : la liste écrite publiait `admin:write`
+	* qu'aucun outil n'exige, et taisait le scope de tout outil déclaré par un
+	* module — deux écarts qu'aucun contrôle ne pouvait voir, puisque rien ne
+	* reliait les deux. Une application qui veut voir un scope publié le pose sur
+	* son outil (`IMcpTool.scopes`), seul endroit où un scope a un EFFET.
+	*
+	* Vide quand la porte n'exige rien : `scopes_supported` est alors OMIS du
+	* document (RFC 9728 §2, champ optionnel) plutôt que publié vide.
+	*
+	* @returns les scopes dédupliqués et triés
+	*/
+	declaredMcpScopes() {
+		return mcpDeclaredScopes({
+			builtins: this.cfg.mcp.tools,
+			deps: this.mcpToolDeps(),
+			modules: this.module.kernel?.modules
+		});
+	}
+	/**
+	* Ce que ce module protège, à publier en RFC 9728 — la porte MCP, ou rien.
+	*
+	* ⭐ **Le document n'est plus monté ici.** Il l'était, par un controller
+	* dédié, et cela faisait deux implémentations d'une même règle : celle du
+	* pare-feu (les zones qui déclarent leur ressource) et celle-ci. Deux copies
+	* divergent — chacune passe ses propres tests — et elles pouvaient en plus se
+	* disputer un chemin, que `Router.createRoute` attribue au premier arrivé sans
+	* un mot. Le module DÉCLARE désormais, `@nodefony/framework` monte.
+	*
+	* 🔴 **Effet voulu du changement** : le document n'est plus servi que sur
+	* l'autorité de `resource`. L'ancien controller répondait sur n'importe
+	* laquelle — exactement le défaut corrigé sur le document d'émetteur, qu'un
+	* vrai client MCP avait trouvé : recevoir le document d'une autre autorité le
+	* fait ARRÊTER, là où un `404` l'aurait laissé continuer.
+	*
+	* Rôle éteint (aucun serveur d'autorisation déclaré) ⇒ rien : un document sans
+	* `authorization_servers` apprendrait au client qu'un jeton est nécessaire
+	* sans lui dire où l'obtenir, ce que la spécification MCP interdit.
+	*
+	* @returns une entrée pour la porte MCP, ou aucune
+	*/
+	publishedProtectedResources() {
+		const mcp = this.cfg.mcp;
+		const authz = mcp.authorization;
+		if (!mcp.enabled || authz.authorizationServers.length === 0) return EMPTY_PROTECTED_RESOURCES;
+		return [{
+			resource: authz.resource,
+			authorizationServers: authz.authorizationServers,
+			scopesSupported: this.declaredMcpScopes(),
+			resourceName: authz.resourceName,
+			resourceDocumentation: authz.resourceDocumentation
+		}];
+	}
+	status() {
+		return { ready: this.cfg.enabled };
+	}
+};
+DevkitService = __decorate([injectable(), __decorateMetadata("design:paramtypes", [typeof Module === "undefined" ? Object : Module])], DevkitService);
+var DevkitService_default = DevkitService;
+//#endregion
+export { DevkitService_default as default };

package/dist/nodefony/src/card.js

@@ -0,0 +1,2 @@
+import { buildCard, renderCard } from "nodefony";
+export { buildCard, renderCard };

package/dist/nodefony/src/errors/DevkitError.js

@@ -0,0 +1,21 @@
+//#region nodefony/src/errors/DevkitError.ts
+/**
+* Erreur du module devkit.
+*
+* Deux champs qui font la différence en production :
+*  - `code` : identifiant MACHINE (stable, grep-able, consommé par Studio et
+*    l'audit) — le message, lui, peut changer sans rien casser ;
+*  - `context` : payload structuré joint au log (jamais de secret ici).
+*/
+var DevkitError = class extends Error {
+	code;
+	context;
+	constructor(message, code = "DEVKIT_ERROR", context) {
+		super(message);
+		this.code = code;
+		this.context = context;
+		this.name = "DevkitError";
+	}
+};
+//#endregion
+export { DevkitError, DevkitError as default };

package/dist/nodefony/src/mcp/guard.js

@@ -0,0 +1,51 @@
+//#region nodefony/src/mcp/guard.ts
+/**
+* Une adresse est-elle celle de la machine locale ?
+*
+* Couvre les trois formes que Node rend selon la pile réseau : IPv4
+* (`127.x.x.x`), IPv6 (`::1`), et l'IPv4 encapsulée en IPv6
+* (`::ffff:127.0.0.1`) — la plus fréquente sur un serveur à double pile, et
+* celle qu'une comparaison naïve à `"127.0.0.1"` rate.
+*
+* @param address - `socket.remoteAddress`, éventuellement absent
+* @returns `true` si l'appel vient de cette machine
+*/
+function isLocalAddress(address) {
+	if (!address) return false;
+	const bare = address.startsWith("::ffff:") ? address.slice(7) : address;
+	if (bare === "::1" || bare === "localhost") return true;
+	return /^127\.\d{1,3}\.\d{1,3}\.\d{1,3}$/.test(bare);
+}
+/**
+* Décide si un appel MCP peut être servi.
+*
+* ⭐ **La règle sur `Origin` est contre-intuitive, et c'est elle qui protège.**
+* Un client MCP légitime est un *process* (Cursor, Claude Code, un agent tiers)
+* : il n'envoie **aucun** `Origin`, cet en-tête étant posé par les navigateurs.
+* Une page web malveillante, elle, en pose **toujours** un lorsqu'elle vise
+* `https://localhost:5152`. Donc : *absent* → on passe ; *présent et hors
+* allowlist* → `403`. C'est ce qui referme le DNS rebinding, le seul vecteur
+* réel contre un serveur MCP local.
+*
+* L'ordre des contrôles est délibéré : la localité d'abord, parce qu'un appel
+* distant ne doit même pas apprendre quelles origines sont admises.
+*
+* @param input - ce que la requête présente
+* @param policy - les réglages du module
+* @returns le verdict, avec le motif quand il refuse
+*/
+function checkMcpAccess(input, policy) {
+	if (!policy.allowRemote && !isLocalAddress(input.remoteAddress)) return {
+		allowed: false,
+		why: `adresse non locale (${input.remoteAddress ?? "inconnue"}) — voir devkit.mcp.allowRemote`
+	};
+	if (input.origin !== void 0 && input.origin !== "") {
+		if (!policy.allowedOrigins.includes(input.origin)) return {
+			allowed: false,
+			why: `origine « ${input.origin} » non admise — voir devkit.mcp.allowedOrigins`
+		};
+	}
+	return { allowed: true };
+}
+//#endregion
+export { checkMcpAccess, isLocalAddress };

package/dist/nodefony/src/mcp/protocol.js

@@ -0,0 +1,127 @@
+//#region nodefony/src/mcp/protocol.ts
+/**
+* Model Context Protocol — types et constantes du transport « Streamable HTTP ».
+*
+* Révision visée : **2026-07-28**, celle qui a supprimé les sessions de niveau
+* protocole et le flux `GET`. C'est ce qui rend cette porte possible sans
+* process dédié : chaque message est un `POST` autonome, donc un redémarrage du
+* serveur de développement ne casse rien — le client rejoue simplement sa
+* requête, et la réponse vient du code qui vient d'être rechargé.
+*
+* @see https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
+*/
+/** Révision du protocole que ce serveur annonce. */
+const MCP_PROTOCOL_VERSION = "2026-07-28";
+/**
+* Versions que ce serveur sait servir — publiées par `server/discover` et
+* listées dans l'erreur `UnsupportedProtocolVersion`.
+*
+* Une seule pour l'instant, et c'est délibéré : annoncer une révision qu'on
+* n'a pas éprouvée reviendrait à promettre une sémantique qu'on ne tient pas.
+*/
+const MCP_SUPPORTED_VERSIONS = [MCP_PROTOCOL_VERSION];
+/**
+* Clé de métadonnée par laquelle un client MODERNE déclare sa révision.
+*
+* ⭐ **C'est la différence d'ÈRE, et elle commande tout le reste.** Jusqu'à
+* `2025-11-25` (ère « legacy »), un client ouvrait une session par un handshake
+* `initialize`. Depuis `2026-07-28` (ère « modern »), il n'y a plus de session :
+* chaque requête porte elle-même sa version et les capacités du client, dans
+* `params._meta`. Un serveur qui n'écouterait que `initialize` serait un
+* serveur *legacy* — quelle que soit la version qu'il prétend annoncer.
+*/
+const META_PROTOCOL_VERSION = "io.modelcontextprotocol/protocolVersion";
+/** Clé de métadonnée portant l'identité du serveur dans `server/discover`. */
+const META_SERVER_INFO = "io.modelcontextprotocol/serverInfo";
+/**
+* Chemin de l'endpoint MCP.
+*
+* ## Pourquoi `/nodefony/mcp`, et pas `/nodefony/devkit/api/mcp`
+*
+* Cette URL est un **contrat public** : elle est écrite dans le `.mcp.json` de
+* chaque utilisateur. Y faire figurer le module qui l'implémente la rendrait
+* caduque au premier déménagement — or ce serveur a vocation à bouger le jour
+* où une application voudra s'exposer en production (le devkit, lui, est
+* `policy: "dev"`). Le nom d'un module est un détail d'implémentation ; une URL
+* ne l'est pas.
+*
+* Le segment `api` est écarté pour une autre raison : il désigne le plan
+* d'administration JSON de Studio, avec son contrôle d'accès par rôle. Le MCP
+* n'est ni REST ni destiné à Studio — ranger deux protocoles sous le même
+* segment promettrait une parenté qui n'existe pas.
+*
+* Et `/mcp` à la racine, qui est la convention de fait ailleurs, prendrait un
+* chemin qui **appartient à l'application** : `/nodefony` est le préfixe
+* réservé du framework, donc sans collision possible.
+*
+* Constante et **non configurable** : une route décorée est statique, et un
+* réglage qui n'agirait pas serait pire qu'aucun réglage.
+*/
+const MCP_ENDPOINT_PATH = "/nodefony/mcp";
+/** Codes d'erreur JSON-RPC 2.0 employés par ce serveur. */
+const JsonRpcError = {
+	/** Corps illisible. */
+	PARSE_ERROR: -32700,
+	/** Message qui n'est pas une requête JSON-RPC valide. */
+	INVALID_REQUEST: -32600,
+	/** Méthode inconnue — la spec exige alors un `404` HTTP. */
+	METHOD_NOT_FOUND: -32601,
+	/** Paramètres absents ou mal typés. */
+	INVALID_PARAMS: -32602,
+	/** Échec côté serveur. */
+	INTERNAL_ERROR: -32603
+};
+/**
+* Codes réservés par la spec MCP, hors plage JSON-RPC standard.
+*
+* Ils ne sont pas décoratifs : un client s'en sert pour se rattraper seul —
+* renégocier une version sur `-32022`, relire `tools/list` puis réessayer sur
+* `-32020`. Rendre un `-32600` générique à leur place le priverait de cette
+* reprise et transformerait un désaccord réparable en échec définitif.
+*/
+const McpProtocolError = {
+	/**
+	* Les en-têtes HTTP contredisent le corps, ou un en-tête requis manque.
+	* La spec impose `400` **et** ce code (`streamable-http` §Server Validation).
+	*/
+	HEADER_MISMATCH: -32020,
+	/**
+	* La révision demandée n'est pas servie. La réponse **doit** lister celles
+	* qu'on sert, sans quoi le client n'a rien pour choisir.
+	*/
+	UNSUPPORTED_PROTOCOL_VERSION: -32022
+};
+/** Fabrique une réponse de succès. */
+function jsonRpcSuccess(id, result) {
+	return {
+		jsonrpc: "2.0",
+		id,
+		result
+	};
+}
+/** Fabrique une réponse d'erreur. */
+function jsonRpcFailure(id, code, message, data) {
+	return {
+		jsonrpc: "2.0",
+		id,
+		error: data === void 0 ? {
+			code,
+			message
+		} : {
+			code,
+			message,
+			data
+		}
+	};
+}
+/**
+* Un message est-il une NOTIFICATION (pas d'`id`) plutôt qu'une requête ?
+*
+* La distinction commande le statut HTTP : une notification acceptée rend
+* `202` **sans corps**, une requête rend son objet JSON.
+*/
+function isNotification(message) {
+	return message.id === void 0 || message.id === null;
+}
+//#endregion
+export { JsonRpcError, MCP_ENDPOINT_PATH, MCP_PROTOCOL_VERSION, MCP_SUPPORTED_VERSIONS, META_PROTOCOL_VERSION, META_SERVER_INFO, McpProtocolError, isNotification, jsonRpcFailure, jsonRpcSuccess };

package/dist/nodefony/src/mcp/server.js

@@ -0,0 +1,133 @@
+import { JsonRpcError, MCP_PROTOCOL_VERSION, MCP_SUPPORTED_VERSIONS, META_PROTOCOL_VERSION, META_SERVER_INFO, McpProtocolError, isNotification, jsonRpcFailure, jsonRpcSuccess } from "./protocol.js";
+import { callMcpTool, listMcpTools } from "./tools.js";
+//#region nodefony/src/mcp/server.ts
+/**
+* Extrait la révision déclarée dans `params._meta`, s'il y en a une.
+*
+* Un client MODERNE la pose à chaque requête ; un client LEGACY ne pose rien
+* et négocie par `initialize`. L'absence n'est donc pas une faute : c'est un
+* indice d'ère.
+*/
+function metaVersion(params) {
+	const meta = params._meta;
+	if (typeof meta !== "object" || meta === null) return void 0;
+	const value = meta[META_PROTOCOL_VERSION];
+	return typeof value === "string" ? value : void 0;
+}
+/**
+* Contrôle la cohérence et le support de la révision annoncée.
+*
+* Deux refus distincts, et la spec impose les deux :
+*  - **en-tête ≠ `_meta`** → `400` + `HeaderMismatch` (`-32020`). Le motif est
+*    une vraie faille : un répartiteur de charge peut router sur l'en-tête
+*    pendant que le serveur exécute d'après le corps — deux sources de vérité
+*    pour une même requête.
+*  - **révision inconnue** → `400` + `UnsupportedProtocolVersion` (`-32022`),
+*    **avec la liste de celles qu'on sert** : c'est elle qui permet au client
+*    de se rattraper au lieu d'abandonner.
+*
+* @returns `null` si tout va bien, sinon la réponse de refus
+*/
+function checkProtocolVersion(id, params, headers) {
+	const fromMeta = metaVersion(params);
+	const fromHeader = headers.protocolVersion;
+	if (fromMeta && fromHeader && fromMeta !== fromHeader) return {
+		status: 400,
+		body: jsonRpcFailure(id, McpProtocolError.HEADER_MISMATCH, "MCP-Protocol-Version ne correspond pas à _meta", {
+			header: fromHeader,
+			meta: fromMeta
+		})
+	};
+	const declared = fromMeta ?? fromHeader;
+	if (!declared) return null;
+	if (!MCP_SUPPORTED_VERSIONS.includes(declared)) return {
+		status: 400,
+		body: jsonRpcFailure(id, McpProtocolError.UNSUPPORTED_PROTOCOL_VERSION, "Unsupported protocol version", {
+			supported: [...MCP_SUPPORTED_VERSIONS],
+			requested: declared
+		})
+	};
+	return null;
+}
+/**
+* Traite UN message JSON-RPC.
+*
+* @param message - corps du `POST`, déjà parsé
+* @param context - outils autorisés et briques qui répondent
+* @param headers - en-têtes du transport (`MCP-Protocol-Version`)
+* @returns statut HTTP et corps à écrire (corps `null` = `202` sans contenu)
+*/
+async function handleMcpMessage(message, context, headers = {}) {
+	if (message === null || typeof message !== "object" || typeof message.method !== "string") return {
+		status: 400,
+		body: jsonRpcFailure(null, JsonRpcError.INVALID_REQUEST, "message JSON-RPC invalide : `method` manquante")
+	};
+	const method = message.method;
+	if (isNotification(message)) return {
+		status: 202,
+		body: null
+	};
+	const id = message.id;
+	const params = typeof message.params === "object" && message.params !== null ? message.params : {};
+	const refus = checkProtocolVersion(id, params, headers);
+	if (refus) return refus;
+	switch (method) {
+		case "server/discover": return {
+			status: 200,
+			body: jsonRpcSuccess(id, {
+				resultType: "complete",
+				supportedVersions: [...MCP_SUPPORTED_VERSIONS],
+				capabilities: { tools: {} },
+				instructions: "Outils d'introspection d'une application Nodefony : ce qui est monté (inspect), ce qui manque (check), ce qu'une API du framework signifie (symbols), et par où commencer (card).",
+				_meta: { [META_SERVER_INFO]: context.serverInfo }
+			})
+		};
+		case "initialize": return {
+			status: 200,
+			body: jsonRpcSuccess(id, {
+				protocolVersion: MCP_PROTOCOL_VERSION,
+				capabilities: { tools: {} },
+				serverInfo: context.serverInfo
+			})
+		};
+		case "ping": return {
+			status: 200,
+			body: jsonRpcSuccess(id, {})
+		};
+		case "tools/list": return {
+			status: 200,
+			body: jsonRpcSuccess(id, { tools: listMcpTools(context.tools) })
+		};
+		case "tools/call": {
+			const name = typeof params.name === "string" ? params.name : "";
+			const args = typeof params.arguments === "object" && params.arguments !== null ? params.arguments : {};
+			if (!name) return {
+				status: 400,
+				body: jsonRpcFailure(id, JsonRpcError.INVALID_PARAMS, "`name` est requis pour `tools/call`")
+			};
+			let result;
+			try {
+				result = await callMcpTool(name, args, context.tools, context);
+			} catch (error) {
+				return {
+					status: 200,
+					body: jsonRpcFailure(id, JsonRpcError.INTERNAL_ERROR, `l'outil « ${name} » a échoué : ${error.message}`)
+				};
+			}
+			if (result === null) return {
+				status: 200,
+				body: jsonRpcFailure(id, JsonRpcError.INVALID_PARAMS, `outil inconnu « ${name} » — voir tools/list`)
+			};
+			return {
+				status: 200,
+				body: jsonRpcSuccess(id, result)
+			};
+		}
+		default: return {
+			status: 404,
+			body: jsonRpcFailure(id, JsonRpcError.METHOD_NOT_FOUND, `méthode inconnue « ${method} »`)
+		};
+	}
+}
+//#endregion
+export { handleMcpMessage };