@nodefony/devkit 10.0.0-alpha.1

package/dist/types/nodefony/service/DevkitService.d.ts

@@ -0,0 +1,143 @@
+import { Service, Module } from "nodefony";
+import type { IMcpToolDeps, IProtectedResourceInput } from "nodefony";
+import type { IDevkitCard, IDevkitService } from "../interfaces/IDevkitService.js";
+import { type DevkitConfig } from "../config/config.js";
+/**
+ * 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");
+ * ```
+ */
+declare class DevkitService extends Service implements IDevkitService {
+    module: Module;
+    private readonly cfg;
+    constructor(module: Module);
+    /**
+     * 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.)
+     */
+    init(): Promise<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(): IDevkitCard;
+    /**
+     * 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(): DevkitConfig["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(): IMcpToolDeps;
+    /**
+     * 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(): readonly string[];
+    /**
+     * 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(): readonly IProtectedResourceInput[];
+    status(): {
+        ready: boolean;
+    };
+}
+export default DevkitService;

package/dist/types/nodefony/src/card.d.ts

@@ -0,0 +1,18 @@
+/**
+ * La composition de la carte vit désormais dans le CŒUR
+ * (`nodefony` → `src/cli/cardReport.ts`) ; ce fichier n'en est plus que le point
+ * d'entrée historique du module.
+ *
+ * Pourquoi elle a déménagé : la carte doit répondre sur une application **non
+ * construite** et dans un terminal **sans `NODE_ENV`** — deux situations où
+ * aucun module n'est chargé, celui-ci compris. Une capacité qui doit tenir sans
+ * installation ne peut pas dépendre d'un module : c'est la règle que `check`,
+ * `env` et `inspect` suivent déjà, et elle est inscrite au `CLAUDE.md` de ce
+ * paquet (« y déplacer une capacité qui doit marcher sans installation ou
+ * application cassée » est justement ce qu'il interdit).
+ *
+ * Ce qui reste ici : la porte **HTTP**, servie par `DevkitService` quand le
+ * Kernel tourne — elle seule connaît les modules réellement CHARGÉS. Une
+ * composition, deux portes, aucune divergence possible.
+ */
+export { buildCard, renderCard } from "nodefony";

package/dist/types/nodefony/src/errors/DevkitError.d.ts

@@ -0,0 +1,14 @@
+/**
+ * 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).
+ */
+export declare class DevkitError extends Error {
+    readonly code: string;
+    readonly context?: Record<string, unknown> | undefined;
+    constructor(message: string, code?: string, context?: Record<string, unknown> | undefined);
+}
+export default DevkitError;

package/dist/types/nodefony/src/mcp/guard.d.ts

@@ -0,0 +1,66 @@
+/**
+ * Gardes du transport MCP — ce qui protège une porte locale SANS authentification.
+ *
+ * Ces deux contrôles ne sont pas un pis-aller : ce sont exactement les
+ * exigences que la spec pose au transport lui-même, indépendamment de toute
+ * autorisation (`transports/streamable-http` §Security & Endpoint) —
+ * « Servers **MUST** validate the `Origin` header on all incoming connections
+ * to prevent DNS rebinding attacks » et « When running locally, servers
+ * **SHOULD** bind only to localhost ».
+ *
+ * Fonctions **pures** : elles reçoivent ce qu'elles jugent, elles ne le lisent
+ * nulle part. C'est ce qui les rend éprouvables sans serveur ni requête réelle
+ * — et ce qui permet de vérifier le refus, qui est le comportement qui compte.
+ */
+/** Verdict d'une garde : passer, ou refuser en disant pourquoi. */
+export type GuardVerdict = {
+    allowed: true;
+} | {
+    allowed: false;
+    why: string;
+};
+/** Ce que la garde a besoin de savoir d'une requête. */
+export interface IGuardInput {
+    /** En-tête `Origin`, `undefined` s'il est absent. */
+    origin?: string;
+    /** Adresse distante de la connexion (`socket.remoteAddress`). */
+    remoteAddress?: string;
+}
+/** Réglages qui gouvernent les gardes (viennent de la config du module). */
+export interface IGuardPolicy {
+    /** Origines de navigateur admises ; vide = aucune. */
+    allowedOrigins: readonly string[];
+    /** Accepter une adresse distante non locale. */
+    allowRemote: boolean;
+}
+/**
+ * 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
+ */
+export declare function isLocalAddress(address?: string): boolean;
+/**
+ * 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
+ */
+export declare function checkMcpAccess(input: IGuardInput, policy: IGuardPolicy): GuardVerdict;

package/dist/types/nodefony/src/mcp/protocol.d.ts

@@ -0,0 +1,139 @@
+/**
+ * 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. */
+export declare 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.
+ */
+export declare const MCP_SUPPORTED_VERSIONS: readonly ["2026-07-28"];
+/**
+ * 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.
+ */
+export declare const META_PROTOCOL_VERSION = "io.modelcontextprotocol/protocolVersion";
+/** Clé de métadonnée portant l'identité du serveur dans `server/discover`. */
+export declare 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.
+ */
+export declare const MCP_ENDPOINT_PATH = "/nodefony/mcp";
+/** Codes d'erreur JSON-RPC 2.0 employés par ce serveur. */
+export declare const JsonRpcError: {
+    /** Corps illisible. */
+    readonly PARSE_ERROR: -32700;
+    /** Message qui n'est pas une requête JSON-RPC valide. */
+    readonly INVALID_REQUEST: -32600;
+    /** Méthode inconnue — la spec exige alors un `404` HTTP. */
+    readonly METHOD_NOT_FOUND: -32601;
+    /** Paramètres absents ou mal typés. */
+    readonly INVALID_PARAMS: -32602;
+    /** Échec côté serveur. */
+    readonly 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.
+ */
+export declare 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).
+     */
+    readonly 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.
+     */
+    readonly UNSUPPORTED_PROTOCOL_VERSION: -32022;
+};
+/** Identifiant d'une requête JSON-RPC (jamais `null` pour une requête). */
+export type JsonRpcId = string | number;
+/** Message entrant : requête (avec `id`) ou notification (sans `id`). */
+export interface IJsonRpcMessage {
+    jsonrpc?: unknown;
+    id?: unknown;
+    method?: unknown;
+    params?: unknown;
+}
+/** Réponse JSON-RPC de succès. */
+export interface IJsonRpcSuccess {
+    jsonrpc: "2.0";
+    id: JsonRpcId;
+    result: unknown;
+}
+/** Réponse JSON-RPC d'erreur. */
+export interface IJsonRpcFailure {
+    jsonrpc: "2.0";
+    /** `null` quand l'erreur survient avant d'avoir pu lire un `id`. */
+    id: JsonRpcId | null;
+    error: {
+        code: number;
+        message: string;
+        data?: unknown;
+    };
+}
+/** Ce que le serveur MCP rend, avant traduction en réponse HTTP. */
+export interface IMcpHttpReply {
+    /** Statut HTTP à poser. */
+    status: number;
+    /**
+     * Corps JSON, ou `null` pour un `202 Accepted` sans corps — la spec l'exige
+     * pour une notification acceptée.
+     */
+    body: IJsonRpcSuccess | IJsonRpcFailure | null;
+}
+/** Fabrique une réponse de succès. */
+export declare function jsonRpcSuccess(id: JsonRpcId, result: unknown): IJsonRpcSuccess;
+/** Fabrique une réponse d'erreur. */
+export declare function jsonRpcFailure(id: JsonRpcId | null, code: number, message: string, data?: unknown): IJsonRpcFailure;
+/**
+ * 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.
+ */
+export declare function isNotification(message: IJsonRpcMessage): boolean;

package/dist/types/nodefony/src/mcp/server.d.ts

@@ -0,0 +1,48 @@
+import { type IJsonRpcMessage, type IMcpHttpReply } from "./protocol.js";
+import { type IMcpToolDeps } from "./tools.js";
+/**
+ * Cœur du serveur MCP : un message JSON-RPC entre, une réponse HTTP sort.
+ *
+ * **Fonction pure** — elle ne touche ni au socket, ni au conteneur, ni à
+ * l'horloge. C'est ce qui permet d'éprouver le protocole entier (statuts
+ * compris) sans démarrer de serveur, et c'est aussi ce qui rend le transport
+ * interchangeable : le jour où un transport `stdio` serait nécessaire pour
+ * répondre application éteinte, il appellerait cette même fonction.
+ *
+ * ## Ce que la révision 2026-07-28 change, et pourquoi c'est ce qui rend cette
+ * porte viable
+ *
+ * Les sessions de niveau protocole ont disparu. Rien n'est retenu entre deux
+ * appels : chaque `POST` porte tout ce qu'il faut pour être servi. Un
+ * redémarrage du serveur de développement — celui que le superviseur déclenche
+ * à chaque fichier sauvegardé — ne casse donc aucun état, et la réponse
+ * suivante vient du code qui vient d'être rechargé. Aucun cache à invalider,
+ * jamais : la fraîcheur est une propriété du protocole, pas une discipline.
+ */
+/** Ce que ce serveur sait faire, annoncé à l'initialisation. */
+interface IServerInfo {
+    name: string;
+    version: string;
+}
+/** Tout ce dont le traitement d'un message a besoin. */
+export interface IMcpServerContext extends IMcpToolDeps {
+    /** Allowlist des outils (`devkit.mcp.tools`). */
+    tools: readonly string[];
+    /** Identité annoncée au client. */
+    serverInfo: IServerInfo;
+}
+/** En-têtes HTTP dont le protocole se sert. */
+export interface IMcpHeaders {
+    /** `MCP-Protocol-Version`, absent chez un client de l'ère legacy. */
+    protocolVersion?: string;
+}
+/**
+ * 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)
+ */
+export declare function handleMcpMessage(message: IJsonRpcMessage, context: IMcpServerContext, headers?: IMcpHeaders): Promise<IMcpHttpReply>;
+export {};

package/dist/types/nodefony/src/mcp/tools.d.ts

@@ -0,0 +1,81 @@
+import { type IAdminBrokerLike } from "nodefony";
+/**
+ * Catalogue des outils MCP, et leur exécution.
+ *
+ * ⚠️ **Rien n'est calculé ici.** Chaque outil traduit un appel JSON-RPC vers une
+ * brique qui répond DÉJÀ à une autre porte : `inspect` lit le plan
+ * d'administration par `readAdminSubject` (la même fonction que la commande
+ * `nodefony inspect`), `card` appelle le service du module (la même que la route
+ * HTTP). Une source, plusieurs portes — un outil qui recalculerait sa réponse
+ * finirait par contredire la commande, et c'est lui qu'on croirait sur parole.
+ *
+ * ⭐ **La description d'un outil est le premier critère de son déclenchement.**
+ * Un modèle n'appelle pas ce qu'il ne comprend pas : le POC de 2026-05 l'a payé
+ * cash — un outil à description neutre n'a jamais été appelé, un skill
+ * auto-déclenché prenait la main à chaque fois. Ces descriptions disent donc ce
+ * que l'outil rend ET quand s'en servir, pas seulement son nom.
+ */
+/** Ce dont les outils ont besoin pour répondre — injecté, jamais lu ici. */
+export interface IMcpToolDeps {
+    /** Le service `adminBroker` du conteneur, ou `undefined` s'il manque. */
+    broker: IAdminBrokerLike | undefined;
+    /** Compose la carte de visite de l'application. */
+    getCard: () => unknown;
+    /**
+     * Racine depuis laquelle lire le disque (graphe symbolique, diagnostic).
+     *
+     * Injectée plutôt que lue par `process.cwd()` : le serveur répond dans le
+     * process de l'application, dont le dossier courant n'est pas garanti être
+     * celui du projet — et un outil qui diagnostiquerait le mauvais dossier
+     * conclurait « rien à signaler » avec aplomb.
+     */
+    projectRoot: string;
+}
+/** Un outil tel que `tools/list` le publie. */
+export interface IMcpToolDefinition {
+    name: string;
+    description: string;
+    inputSchema: Record<string, unknown>;
+}
+/** Ce que rend `tools/call` — du contenu, et l'aveu d'un échec métier. */
+export interface IMcpToolResult {
+    content: {
+        type: "text";
+        text: string;
+    }[];
+    isError?: boolean;
+}
+/**
+ * Outils publiés, filtrés par l'allowlist de configuration.
+ *
+ * Une clé inconnue dans la configuration est simplement ignorée : elle ne peut
+ * rien ouvrir. C'est le sens d'une allowlist — ce qui n'est pas nommé ICI
+ * n'existe pas, et la faute de frappe d'un utilisateur ne peut pas activer
+ * autre chose que ce qu'il voulait.
+ *
+ * ⚠️ **`Object.hasOwn` n'est pas une précaution de style.** Sans lui,
+ * `tools: ["toString"]` résolvait une méthode héritée d'`Object.prototype` :
+ * la valeur n'étant pas `undefined`, elle franchissait le filtre et un outil
+ * fantôme entrait dans le catalogue publié. Trouvé par le test, pas à la
+ * relecture.
+ *
+ * @param enabled - clés d'outils autorisées (`devkit.mcp.tools`)
+ */
+export declare function listMcpTools(enabled: readonly string[]): IMcpToolDefinition[];
+/**
+ * Exécute un outil par son nom public.
+ *
+ * Un échec métier (sujet inconnu, module absent) rend un résultat `isError`,
+ * **pas** une erreur JSON-RPC : le protocole réserve celle-ci aux fautes de
+ * protocole. La distinction compte pour l'agent — une erreur de protocole
+ * signifie « tu t'y prends mal », un `isError` signifie « ta demande est
+ * recevable, voici pourquoi elle n'aboutit pas » ; c'est la seconde qu'il peut
+ * corriger seul.
+ *
+ * @param name - nom public de l'outil (`nodefony_inspect`…)
+ * @param args - arguments fournis par l'agent
+ * @param enabled - allowlist de configuration
+ * @param deps - briques qui répondent réellement
+ * @returns le résultat de l'outil, ou `null` si le nom n'est pas exposé
+ */
+export declare function callMcpTool(name: string, args: Record<string, unknown>, enabled: readonly string[], deps: IMcpToolDeps): Promise<IMcpToolResult | null>;