xonecode 0.38.44 → 0.39.4

package/dist/agent/grafo/describirImagen.d.ts

@@ -0,0 +1,79 @@
+import { z } from "zod";
+import { type ImagenReferida } from "../../core/referenciasDeImagen.js";
+import type { Papel } from "../../core/ports.js";
+import { type InvocarVisual } from "../dispositivos/juezVisual.js";
+/**
+ * `describe_image`: que el agente VEA una imagen (IXCODE-23).
+ *
+ * ## Por qué existe, medido
+ *
+ * Con una imagen adjunta, el agente contestaba «en este harness no tengo visión» sin abrirla. Dos
+ * causas, las dos nuestras: el aviso de adjuntos se lo DECÍA («no hay visión en este harness
+ * todavía»), y el `read_file` de TrueForge devolvía «fichero binario» ante un PNG. Pero el modelo sí
+ * ve: medido contra la API, `deepseek-flash` nombró el color de un cuadrado liso y describió bien un
+ * icono adjunto («un círculo negro con un símbolo de suma blanco»). No faltaba la visión, faltaba el
+ * camino hasta ella.
+ *
+ * ## Por qué una llamada APARTE y no la imagen en la conversación
+ *
+ * - En un API compatible con OpenAI, el resultado de una tool es TEXTO: una imagen devuelta por
+ *   `read_file` no le llega al modelo como imagen. La única entrada sería un mensaje de usuario falso.
+ * - Una imagen en el historial se PAGA en cada llamada siguiente (se cobra por píxeles, no por bytes),
+ *   y se quedaría en la foto de TrueForge y en la traza. Una descripción se paga UNA vez y es texto.
+ *
+ * Es el camino que ya usa `xone_critica_visual` (`invocarVisualConModelos`), con otra pregunta: el
+ * crítico JUZGA una pantalla, ésta DESCRIBE lo que haya.
+ *
+ * ## Las guardas
+ *
+ * La MISMA regla de ruta que las maquetas del crítico (`imagenReferida`, lista blanca de forma, sin
+ * dotfiles) y la misma lectura (`lectorDeReferencias`, texto y `realpath`): una tool de LangChain
+ * añadida por xonecode no pasa por el middleware de permisos, así que sin esto mandaría a un modelo
+ * cualquier fichero de la máquina. Todo rechazo se DEVUELVE, nunca se lanza. De un error de lectura
+ * solo cruza el `code` (su mensaje lleva la ruta absoluta).
+ *
+ * **Acepta también la ruta COMPLETA de la máquina** (petición suya: es la que el agente ve a veces en
+ * un error o la que pega la persona), pero solo si cae dentro de lo montado —el proyecto, los adjuntos
+ * y los artefactos de la sesión—: se TRADUCE a su ruta virtual y pasa por la misma regla. Fuera de ahí
+ * se rechaza con el camino (`traer_de_la_maquina` y después esta), para que no sea una forma de mandar
+ * a un modelo cualquier fichero de la máquina.
+ *
+ * **Límite declarado**: un modelo SIN visión puede no fallar y describir lo que no recibió. La
+ * respuesta dice que la descripción es de un modelo, y quien la lee no debe darla por medida.
+ */
+export declare const NOMBRE_DESCRIBIR_IMAGEN = "describe_image";
+/** El papel del modelo que mira. `afilado` es del juez (`core/modelos.ts`); describir es trabajo. */
+export declare const PAPEL_DE_DESCRIBIR: Papel;
+/** Tope de bytes de la imagen: una captura de pantalla son cientos de KB; esto para un fichero absurdo antes de mandarlo. */
+export declare const TOPE_DE_BYTES_DE_IMAGEN: number;
+export declare const PROMPT_DE_DESCRIPCION: string;
+export interface DependenciasDeDescribir {
+    invocar: InvocarVisual;
+    /** Lee la imagen ya validada (`crearLectorDeReferencias`). Lanza con un `code`. */
+    leer: (imagen: ImagenReferida) => Promise<Buffer>;
+    /**
+     * Las carpetas montadas, para traducir una ruta COMPLETA a la virtual. Ausentes, solo vale la virtual.
+     * El orden importa: las de la sesión viven DENTRO del proyecto (`.xonecode/sesiones/…`), así que se
+     * miran antes que la raíz.
+     */
+    carpetas?: {
+        raiz: string;
+        adjuntos?: string;
+        artefactos?: string;
+    };
+}
+/**
+ * La ruta virtual de una ruta completa que cae dentro de lo montado, o `undefined`. Solo compara TEXTO:
+ * lo que salga pasa después por `imagenReferida` y por el `realpath` del lector, como cualquier otra.
+ */
+export declare function rutaVirtualDe(completa: string, carpetas: NonNullable<DependenciasDeDescribir["carpetas"]>): string | undefined;
+export declare function crearDescribirImagen(deps: DependenciasDeDescribir): import("@langchain/core/tools").DynamicStructuredTool<z.ZodObject<{
+    ruta: z.ZodString;
+    pregunta: z.ZodOptional<z.ZodString>;
+}, z.core.$strip>, {
+    ruta: string;
+    pregunta?: string | undefined;
+}, {
+    ruta: string;
+    pregunta?: string | undefined;
+}, string, unknown, "describe_image">;

package/dist/agent/grafo/diferenciaDeCapturas.d.ts

@@ -0,0 +1,33 @@
+import { z } from "zod";
+export declare const NOMBRE_DIFERENCIA_DE_CAPTURAS = "diferencia_de_capturas";
+export interface DependenciasDeDiferencia {
+    leerArtefacto: (nombre: string) => Promise<Buffer>;
+}
+export declare function crearDiferenciaDeCapturas(deps: DependenciasDeDiferencia): import("@langchain/core/tools").DynamicStructuredTool<z.ZodObject<{
+    antes: z.ZodString;
+    despues: z.ZodString;
+    zona: z.ZodOptional<z.ZodObject<{
+        x: z.ZodNumber;
+        y: z.ZodNumber;
+        ancho: z.ZodNumber;
+        alto: z.ZodNumber;
+    }, z.core.$strip>>;
+}, z.core.$strip>, {
+    antes: string;
+    despues: string;
+    zona?: {
+        x: number;
+        y: number;
+        ancho: number;
+        alto: number;
+    } | undefined;
+}, {
+    antes: string;
+    despues: string;
+    zona?: {
+        x: number;
+        y: number;
+        ancho: number;
+        alto: number;
+    } | undefined;
+}, string, unknown, "diferencia_de_capturas">;

package/dist/agent/grafo/ejecucionCancelable.d.ts

@@ -0,0 +1,45 @@
+export interface ResultadoDeEjecucion {
+    output: string;
+    exitCode: number | null;
+    truncated: boolean;
+}
+/** El hijo, visto por este módulo — sin `stdin`, que `execute` nunca teclea. */
+interface ProcesoDeShell {
+    pid?: number;
+    stdout: {
+        on: (evento: "data", cb: (dato: unknown) => void) => void;
+    };
+    stderr: {
+        on: (evento: "data", cb: (dato: unknown) => void) => void;
+    };
+    on: (evento: "close" | "error", cb: (...args: unknown[]) => void) => void;
+    kill: (senal?: string) => boolean;
+}
+export type LanzarShell = (comando: string, opciones: {
+    env: Record<string, string>;
+    cwd: string;
+}) => ProcesoDeShell;
+/**
+ * **`detached: true` no es cosmético: es la causa raíz.** Sin él, el hijo comparte el grupo
+ * de proceso de xonecode entero, y `process.kill(-pid)` (dentro de `matarGrupoReal`) mataría
+ * ESE grupo — el propio xonecode incluido. `LocalShellBackend.execute` de la librería no lo
+ * pone, y por eso su `child.kill()` solo alcanza al hijo inmediato.
+ *
+ * **`detached` es solo de POSIX.** Es lo que hace al hijo líder de su propio grupo para que
+ * `process.kill(-pid)` alcance al árbol; en Windows no hay grupos de proceso POSIX, así que
+ * `matarGrupoReal` usa `taskkill /T` (recorre el árbol por PID, no por grupo) y no lo
+ * necesita — y ahí `detached: true` le abre al hijo su PROPIA ventana de consola visible (lo
+ * dice la documentación de Node). `windowsHide: true` va siempre, en las dos plataformas: en
+ * POSIX no hace nada, en Windows evita esa ventana.
+ */
+export declare const lanzarReal: LanzarShell;
+export declare function crearExecuteCancelable(opciones: {
+    env: Record<string, string>;
+    cwd: string;
+    timeoutS: number;
+    maxOutputBytes?: number;
+}, deps?: {
+    lanzar?: LanzarShell;
+    matarGrupo?: (pid: number, senal: string) => void;
+}): (comando: string, senal?: AbortSignal) => Promise<ResultadoDeEjecucion>;
+export {};

package/dist/agent/grafo/escriturasEnSerie.d.ts

@@ -0,0 +1,31 @@
+/**
+ * Dos escrituras sobre el MISMO fichero no se solapan: la segunda espera a que acabe la
+ * primera. Sobre ficheros distintos no cambia nada.
+ *
+ * **El fallo que cierra es silencioso, que es lo que lo hace grave.** `write` y `edit` del
+ * backend son leer-modificar-escribir sobre el fichero entero, así que dos a la vez se pisan
+ * y **las dos contestan que bien**. Reproducido contra el backend real: cuatro `edit`
+ * concurrentes, cuatro resultados sin error, **una** aplicada. Y ocurre de verdad — en una
+ * sesión de MyAllXOne la traza de errores registró dos `edit` sobre `/funciones.js` entrando
+ * en el MISMO milisegundo, con el testigo `escrituraSolapada` disparado.
+ *
+ * **Por qué serializar basta**, que era la objeción razonable: la segunda edición calculó su
+ * `old_string` contra un contenido que la primera acaba de cambiar. Cierto — y por eso este
+ * envoltorio va POR FUERA de quien edita, no por dentro: cuando le llega el turno, el camino
+ * de escritura vuelve a leer el fichero y vuelve a buscar el `old_string` contra lo que hay
+ * AHORA. Si el ancla sigue, la edición es correcta; si desapareció, el backend contesta que
+ * no lo encuentra y el modelo recibe su error y reintenta. Medido: en serie, cuatro ediciones
+ * independientes se aplican las cuatro, y dos que se pisan dan una aplicada y **un error
+ * visible** — en vez de una aplicada y un cambio perdido sin que nadie se entere.
+ *
+ * **Dónde va en la pila**: por dentro de las guardas de RUTA —que contestan con una
+ * comparación de texto y deben seguir contestando primero, ver `proyecto.ts`— y por fuera de
+ * `sinContenidoInvalido`, para que leer el fichero de antes, validar y escribir sean un solo
+ * turno. Al revés, dos validaciones podrían intercalarse entre la lectura y la escritura, que
+ * es exactamente la carrera que esto viene a quitar.
+ *
+ * **No toca `read`, `ls`, `glob` ni nada que no escriba.** Serializar lecturas no arregla
+ * nada y convertiría en secuencial el trabajo que sí puede ir en paralelo, que es la mitad de
+ * lo que el agente hace.
+ */
+export declare function escriturasEnSerie<T extends object>(backend: T): T;

package/dist/agent/grafo/excluirTools.d.ts

@@ -0,0 +1,37 @@
+/**
+ * Quita del PROMPT las tools que un agente no puede usar.
+ *
+ * ## Por qué, medido el 17-09-2026
+ *
+ * El inspector (`agent/turno/inspectorDePrompt.ts`) enseñó que en un turno de la pregunta más
+ * barata que tenemos, los esquemas de las tools eran **12.350 de los 14.135 caracteres** de la
+ * primera llamada — el 87 % — y que se reenvían ENTEROS en cada una: ~12.400 de los 15.466
+ * tokens del turno. La pregunta ocupaba cuarenta caracteres.
+ *
+ * Y dentro de eso, el orquestador —que es de SOLO LECTURA por `permisosDe`— cargaba los
+ * esquemas de `write_file`, `edit_file` y `delete`: 3.743 caracteres, unos 940 tokens POR
+ * LLAMADA, por tres tools que tiene prohibido usar. `permissions` acota el PERMISO; el esquema
+ * viaja igual.
+ *
+ * ## Qué es y qué NO es
+ *
+ * **No es una frontera de seguridad**, y eso no es una opinión nuestra: deepagents tiene el
+ * mismo middleware (`createToolExclusionMiddleware`, que no exporta) y su propia documentación
+ * lo dice con esas palabras — «exclusions calibrate the agent per model; they are not a security
+ * boundary». La frontera sigue siendo `permisosDe`, intacta, y esto es coste.
+ *
+ * Por eso hace las DOS cosas: quita la tool de la petición (que es lo que ahorra) **y** rechaza
+ * su llamada si aun así llegara. Solo lo primero sería fiar la barrera a que el modelo no
+ * invente un nombre que no ha visto, y en este repo eso no es una barrera.
+ */
+import { createMiddleware } from "langchain";
+import { type QuienDecidePermisos } from "./perfiles.js";
+export declare function excluirTools(nombres: readonly string[]): ReturnType<typeof createMiddleware>;
+/**
+ * Las que este perfil NO puede usar, DERIVADAS de lo que ya decide `toolsDe`.
+ *
+ * Escritas a mano serían una segunda lista que hay que acordarse de actualizar, y el día que un
+ * perfil gane una capacidad se quedaría sin ella en silencio — el patrón de fallo de este repo.
+ * Así, conceder una tool en `perfiles.ts` la saca de aquí sola.
+ */
+export declare function toolsQueNoUsa(perfil: QuienDecidePermisos): string[];

package/dist/agent/grafo/fuentesDeGoogle.d.ts

@@ -0,0 +1,37 @@
+import { z } from "zod";
+import { NOMBRE_BUSCAR_FUENTE, NOMBRE_TRAER_FUENTE, recibeFuentes } from "../../core/fuentes.js";
+import type { FuentesPort } from "../../core/ports.js";
+import type { QuienDecidePermisos } from "./perfiles.js";
+export { NOMBRE_BUSCAR_FUENTE, NOMBRE_TRAER_FUENTE, recibeFuentes };
+export declare function crearBuscarFuente(fuentes: FuentesPort): import("@langchain/core/tools").DynamicStructuredTool<z.ZodObject<{
+    consulta: z.ZodString;
+    limite: z.ZodOptional<z.ZodCoercedNumber<unknown>>;
+}, z.core.$strip>, {
+    consulta: string;
+    limite?: number | undefined;
+}, {
+    consulta: string;
+    limite?: unknown;
+}, string, unknown, "buscar_fuente">;
+export interface DondeTraerFuente {
+    /** La raíz REAL del proyecto en disco. */
+    raiz: string;
+    /** De quién son los permisos que hay que reaplicar. */
+    perfil: QuienDecidePermisos;
+}
+export declare function crearTraerFuente(fuentes: FuentesPort, donde: DondeTraerFuente): import("@langchain/core/tools").DynamicStructuredTool<z.ZodObject<{
+    familia: z.ZodString;
+    peso: z.ZodCoercedNumber<unknown>;
+    cursiva: z.ZodOptional<z.ZodBoolean>;
+    file_path: z.ZodString;
+}, z.core.$strip>, {
+    familia: string;
+    peso: number;
+    file_path: string;
+    cursiva?: boolean | undefined;
+}, {
+    familia: string;
+    peso: unknown;
+    file_path: string;
+    cursiva?: boolean | undefined;
+}, string, unknown, "traer_fuente">;

package/dist/agent/grafo/generarFondoSvg.d.ts

@@ -0,0 +1,52 @@
+import { z } from "zod";
+import { NOMBRE_GENERAR_FONDO } from "../../core/fondosSvg.js";
+import { recibeBuscarIcono } from "./buscarIcono.js";
+export { NOMBRE_GENERAR_FONDO };
+/**
+ * Generar el fondo SVG de un frame o un botón (degradado, sombra, resplandor), para lo que XOne
+ * no trae propio (IXCODE-18). **Pura y sin red**: no hay puerto, siempre está montada donde se
+ * reparte. Las plantillas, y por qué no llevan ningún filtro, están en `core/fondosSvg.ts`.
+ *
+ * **Solo lee**, como `buscar_icono`: el SVG lo escribe `write_file` con su aprobación. Y va a los
+ * MISMOS especialistas (`recibeBuscarIcono`, la regla de dato de quien escribe el proyecto), en
+ * los dos motores. Los rechazos se DEVUELVEN como texto, nunca se lanzan.
+ */
+export declare const recibeGenerarFondo: typeof recibeBuscarIcono;
+export declare function crearGenerarFondoSvg(): import("@langchain/core/tools").DynamicStructuredTool<z.ZodObject<{
+    tipo: z.ZodEnum<{
+        "degradado-lineal": "degradado-lineal";
+        "degradado-radial": "degradado-radial";
+        sombra: "sombra";
+        glow: "glow";
+    }>;
+    nombre: z.ZodString;
+    ancho: z.ZodUnion<readonly [z.ZodNumber, z.ZodString]>;
+    alto: z.ZodUnion<readonly [z.ZodNumber, z.ZodString]>;
+    colores: z.ZodArray<z.ZodString>;
+    angulo: z.ZodOptional<z.ZodCoercedNumber<unknown>>;
+    radio: z.ZodOptional<z.ZodCoercedNumber<unknown>>;
+    intensidad: z.ZodOptional<z.ZodEnum<{
+        [x: string]: string;
+    }>>;
+    fondo: z.ZodOptional<z.ZodString>;
+}, z.core.$strip>, {
+    tipo: "degradado-lineal" | "degradado-radial" | "sombra" | "glow";
+    nombre: string;
+    ancho: string | number;
+    alto: string | number;
+    colores: string[];
+    angulo?: number | undefined;
+    radio?: number | undefined;
+    intensidad?: string | undefined;
+    fondo?: string | undefined;
+}, {
+    tipo: "degradado-lineal" | "degradado-radial" | "sombra" | "glow";
+    nombre: string;
+    ancho: string | number;
+    alto: string | number;
+    colores: string[];
+    angulo?: unknown;
+    radio?: unknown;
+    intensidad?: string | undefined;
+    fondo?: string | undefined;
+}, string, unknown, "generar_fondo_svg">;

package/dist/agent/grafo/incorporarAdjunto.d.ts

@@ -0,0 +1,98 @@
+import { z } from "zod";
+import type { Agente } from "../../core/agentes.js";
+import { NOMBRE_INCORPORAR_ADJUNTO } from "../../core/adjuntos.js";
+import { type QuienDecidePermisos } from "./perfiles.js";
+export { NOMBRE_INCORPORAR_ADJUNTO };
+/**
+ * Meter un ADJUNTO del chat en el PROYECTO (IXCODE-7): «pon este icono en el menú».
+ *
+ * ## Por qué es una tool y no un `read_file` + `write_file`
+ *
+ * Las tools de fichero son de TEXTO (`write(filePath, content: string)`), y un PNG no
+ * sobrevive a esa ida y vuelta: lleva ceros en su cabecera y se copiaría corrupto sin que nadie
+ * se enterara hasta abrir la app. Es el mismo reparto que `copiar_artefacto`: el harness copia
+ * los BYTES porque el agente no puede, y darle una shell para eso sería peor que el problema.
+ *
+ * ## Por qué pasa por la APROBACIÓN, y `copiar_artefacto` no
+ *
+ * `copiar_artefacto` es del documentador, confinado por `escribeEn` a `/doc/`. Ésta es de quien
+ * escribe el proyecto ENTERO, así que el destino puede ser cualquier fichero de la app —también
+ * uno que ya existe, que se REEMPLAZA—. Eso es exactamente lo que `write_file` no hace sin que
+ * alguien lo apruebe, y una tool que lo hiciera sería la puerta trasera de la aprobación. Por
+ * eso va en el HITL por su NOMBRE, en los dos motores (`perfiles.ts#hitlDe`, las capacidades de
+ * TrueForge), y por eso el destino se llama `file_path`: es la clave que leen `seDetieneEn`, la
+ * tarjeta (`interrupts.ts#ficheroDe`) y el modo autónomo al anotar la ruta.
+ *
+ * ## Las guardas, reaplicadas A MANO
+ *
+ * Una tool propia no pasa por el middleware de permisos ni por la pila del backend: escribe al
+ * disco directo. Así que lo que ahí es gratis aquí hay que decirlo:
+ *
+ * 1. **El ORIGEN es un adjunto de verdad**: un nombre de la lista BLANCA de forma
+ *    (`nombreDeAdjuntoAceptable`), no un `startsWith` — sin eso sería `/adjuntos/../.env`.
+ * 2. **El DESTINO lo puede escribir ESTE agente** (`puedeEscribirRuta`), y no es un sitio de
+ *    artefacto equivocado (`artefactoFueraDeSitio`).
+ * 3. **El destino es el PROYECTO**: ni `/artefactos/`, ni `/planes/`, ni `/adjuntos/`, ni
+ *    `/skills/`, ni los otros montajes del backend (`/hotswap/`, las descargas de deepagents,
+ *    `/MEMORIA_PROYECTO.md`). Detrás de esas rutas el backend tiene OTRA carpeta; esta tool
+ *    escribiría en la del proyecto un fichero con ese nombre. Y es además lo que sostiene a
+ *    `seDetieneEn`: por `/artefactos/` y `/planes/` NO se pregunta, así que la única barrera ahí
+ *    es este rechazo (`incorporarAdjunto.test.ts` lo ata ruta a ruta).
+ * 4. **Ni una vista APLANADA** (`X.xml` con su `X.xne`): la regla es del proyecto, no del
+ *    backend por el que esta tool no pasa.
+ * 5. **Y todo, dos veces: por TEXTO y por `realpath`**, como `copiar_artefacto` y las escrituras
+ *    de los motores externos. En APFS `.XONECODE` abre `.xonecode`, y un enlace dentro de la raíz
+ *    puede apuntar fuera. **A diferencia de `copiar_artefacto`, la contención se comprueba ANTES
+ *    de crear carpetas**: sobre el primer ancestro que existe, para que un destino que sale del
+ *    proyecto no deje un árbol vacío fuera. El fichero final, si existe, no puede ser un enlace:
+ *    escribir lo seguiría.
+ *
+ * Todo rechazo se DEVUELVE como texto, nunca se lanza (un `throw` se lleva el turno), y de un
+ * error de Node solo viaja su `code`: su mensaje lleva la ruta de la máquina.
+ */
+/**
+ * Quién la recibe: escribe el PROYECTO y no está confinado por `escribeEn`. Regla de DATO, no una
+ * lista de nombres: de los de serie da `designer-xone` y `developer-xone`, que es lo que se
+ * decidió. Quien ejecuta no: la shell ya se le quitó el `write_file` para que tocar el proyecto
+ * siga siendo el camino del diff. Y quien va acotado por `escribeEn` (el documentador) tiene
+ * `copiar_artefacto` para lo suyo.
+ *
+ * **Solo llega a `motor: "modelo"`**, sin que esta función lo mire: los de motor externo se montan
+ * aparte y no reciben tools propias (corren en otro proceso), y tampoco ven `/adjuntos/`: es una
+ * ruta virtual de nuestro backend. El inventario que lee el orquestador lo dice
+ * (`core/adjuntos.ts#conAdjuntos`).
+ */
+export declare function recibeIncorporarAdjunto(a: Pick<Agente, "soloLectura" | "ejecucion" | "escribeEn">): boolean;
+export interface DondeIncorporar {
+    /** La raíz REAL del proyecto en disco. */
+    raiz: string;
+    /** La carpeta REAL de adjuntos de esta sesión (o tarea). Puede no existir todavía. */
+    carpetaDeAdjuntos: string;
+    /** De quién son los permisos que hay que reaplicar. */
+    perfil: QuienDecidePermisos;
+}
+/**
+ * ¿Por qué no vale `ruta` como destino, mirando SOLO el texto? `undefined` = vale.
+ *
+ * Se aplica dos veces: a lo que escribió el modelo y a la ruta que sale del `realpath`.
+ * Todo se compara también sin mayúsculas (APFS: `/Adjuntos/` es la misma carpeta en disco).
+ */
+export declare function motivoDeDestino(perfil: QuienDecidePermisos, ruta: string): string | undefined;
+/**
+ * (5b) ¿Por qué no vale `destinoVirtual` mirando el DISCO? `undefined` = vale. ANTES de crear nada:
+ * el primer ancestro que existe tiene que caer dentro de la raíz, y lo que resulta se vuelve a
+ * juzgar como ruta virtual (un enlace `/icons` → `.xonecode/` pasa el texto y no esto). El
+ * fichero final, si ya está, no puede ser un enlace (se seguiría) ni una carpeta. Exportada
+ * porque `traer_fuente` escribe un binario al proyecto con las MISMAS guardas. Nunca lanza.
+ */
+export declare function motivoDeDestinoEnDisco(donde: Pick<DondeIncorporar, "raiz" | "perfil">, destinoVirtual: string): string | undefined;
+export declare function crearIncorporarAdjunto(donde: DondeIncorporar): import("@langchain/core/tools").DynamicStructuredTool<z.ZodObject<{
+    adjunto: z.ZodString;
+    file_path: z.ZodString;
+}, z.core.$strip>, {
+    adjunto: string;
+    file_path: string;
+}, {
+    adjunto: string;
+    file_path: string;
+}, string, unknown, "incorporar_adjunto">;

package/dist/agent/grafo/lectorDeReferencias.d.ts

@@ -0,0 +1,28 @@
+import type { ImagenReferida } from "../../core/referenciasDeImagen.js";
+/**
+ * La lectura de una maqueta (`core/referenciasDeImagen.ts` decide QUÉ rutas valen; esto las abre).
+ *
+ * **La comprobación se repite dos veces: por el TEXTO (la regla pura) y por el `realpath`.** Un enlace
+ * simbólico dentro del proyecto puede apuntar a `/etc` o a `~/.ssh`, y el texto de la ruta no lo dice:
+ * es lo que hacen también las escrituras de los motores externos y el lector de Ficheros. Se resuelve
+ * el enlace y se exige que lo que salga siga DENTRO de la carpeta de su origen.
+ *
+ * Solo lee y solo abre lo que ya pasó la regla. **Lanza con un `code`** (ENOENT si el origen no está
+ * montado o el fichero no existe, EACCES si el enlace sale de la carpeta): quien la llama devuelve
+ * solo ese código, porque el mensaje de un error de Node lleva la ruta absoluta de la máquina.
+ */
+export interface CarpetasDeReferencia {
+    /** La carpeta de artefactos de la sesión. */
+    artefactos?: string;
+    /** La carpeta de adjuntos (de solo lectura). Ausente = `/adjuntos/` no está montada. */
+    adjuntos?: string;
+    /** La raíz del proyecto. */
+    raiz: string;
+}
+export declare function crearLectorDeReferencias(carpetas: CarpetasDeReferencia): (imagen: ImagenReferida) => Promise<Buffer>;
+/**
+ * El `code.html` que acompaña a una maqueta —el de Stitch: `screen.png` y `code.html` en la misma carpeta—,
+ * con su ruta en disco, o `undefined` si no hay. Con la MISMA comprobación que la lectura: por el texto de
+ * la carpeta y por el `realpath`, para que un enlace no lleve a renderizar un HTML de fuera.
+ */
+export declare function crearLocalizadorDeHtmlDeMaqueta(carpetas: CarpetasDeReferencia): (imagen: ImagenReferida) => string | undefined;

package/dist/agent/grafo/marcarCriteriosDelPlan.d.ts

@@ -0,0 +1,47 @@
+import { z } from "zod";
+/**
+ * Marcar en el plan lo que se COMPROBÓ en el aparato.
+ *
+ * ## Por qué existe
+ *
+ * Un criterio de un `TASKS.md` dice cosas como «pulsarla abre la pantalla nueva», y quien lo
+ * comprueba es el `device-controller`, en el emulador. Pero ese agente no tiene `write_file` ni
+ * `edit_file` —ejecuta, y el camino normal de tocar ficheros es el del desarrollador—, y el
+ * orquestador es de solo lectura: medido en una sesión real, el conductor comprobó en el
+ * emulador la entrada del drawer, la lista y el detalle, y el plan siguió con todas las casillas
+ * a cero. Lo verificado no volvía nunca al plan.
+ *
+ * ## Por qué una tool y no `edit_file`
+ *
+ * Porque lo que se le concede es EXACTAMENTE marcar casillas, y eso lo decide el código:
+ * `marcarCriterios` (`core/tareasDelPlan.ts`) solo cambia `- [ ]` a `- [x]` en la sección de UNA
+ * tarea. Un `edit_file` le abriría el fichero entero —y en deepagents, a quien ejecuta no se le
+ * pueden pasar `permissions` junto a su backend con shell—.
+ *
+ * ## Las guardas
+ *
+ * - El nombre del plan es un SLUG (`motivoDePlanInaceptable`): es un segmento de ruta, y sin esto
+ *   `../..` saldría de la carpeta de planes.
+ * - Ni la carpeta ni el fichero pueden ser un enlace (`lstat`), y el camino REAL tiene que seguir
+ *   dentro de `.xonecode/planes/`: lo mismo que `planesEnDisco.ts` al leer.
+ * - No crea nada: sin `TASKS.md` no hay criterios que marcar.
+ *
+ * **Límite declarado**: escribe directo al disco, sin la cola de `escriturasEnSerie`. Un
+ * `edit_file` del desarrollador sobre el MISMO `TASKS.md` a la vez podría pisar la marca.
+ */
+export declare const NOMBRE_MARCAR_CRITERIOS = "marcar_criterios_del_plan";
+export declare function crearMarcarCriteriosDelPlan(donde: {
+    raiz: string;
+}): import("@langchain/core/tools").DynamicStructuredTool<z.ZodObject<{
+    plan: z.ZodString;
+    tarea: z.ZodString;
+    criterios: z.ZodArray<z.ZodNumber>;
+}, z.core.$strip>, {
+    plan: string;
+    tarea: string;
+    criterios: number[];
+}, {
+    plan: string;
+    tarea: string;
+    criterios: number[];
+}, string, unknown, "marcar_criterios_del_plan">;

package/dist/agent/grafo/memoriaDeProyecto.d.ts

@@ -0,0 +1,15 @@
+export declare const NOMBRE_ARCHIVO_MEMORIA = "memoria.md";
+/** Ruta que ve el agente dentro de su backend virtual. Vive en `core/memoria.ts`, que la
+ *  reconoce también en el flujo de tools. */
+export { RUTA_MEMORIA_VIRTUAL } from "../../core/memoria.js";
+/** Ruta real dentro del backend virtual; nunca se enseña al agente. */
+export declare const RUTA_MEMORIA_INTERNA = "/.xonecode/memoria.md";
+/** Almacén interno de los historiales que DeepAgents ya ha resumido. */
+export declare const RUTA_HISTORIAL_RESUMIDO = "/.xonecode/conversation_history";
+export declare function rutaMemoriaDeProyecto(raiz: string): string;
+export declare const PLANTILLA_MEMORIA = "# Memoria del proyecto\n\nEsta memoria recoge solo hechos confirmados, decisiones acordadas y riesgos que ayudan a\ncontinuar el trabajo. No es un transcript ni guarda secretos, credenciales o contenido de\nficheros completos.\n\n## Decisiones\n\n- A\u00FAn no hay decisiones registradas.\n\n## Estado y convenciones\n\n- A\u00FAn no hay estado persistente registrado.\n\n## Riesgos y pendientes\n\n- A\u00FAn no hay riesgos o pendientes registrados.\n";
+/**
+ * Crea la memoria inicial una sola vez. `flag: wx` es la barrera contra pisar una
+ * memoria existente, incluso si dos sesiones arrancan a la vez.
+ */
+export declare function asegurarMemoriaDeProyecto(raiz: string): boolean;

package/dist/agent/grafo/navegacionXone.d.ts

@@ -0,0 +1,60 @@
+import { z } from "zod";
+import type { CargarIndice } from "../navegacion/indiceEnDisco.js";
+import type { CargarEstilos } from "../navegacion/estilosEnDisco.js";
+/**
+ * `xone_navegacion`: preguntar por la ESTRUCTURA del proyecto sin leer ficheros.
+ *
+ * **Por qué existe, medido.** Sobre un proyecto real de 41 `.xne`, contestar «¿qué
+ * colecciones tiene el proyecto?» leyendo ficheros cuesta unos 18.000 tokens; contestarla
+ * desde el índice cuesta 141. Y una pregunta de capacidad («¿podríamos hacer un CRM?») llegó
+ * a gastar 21 pasos de exploración. Lo caro no es abrir un `.xne` —son un par de kilobytes—,
+ * es **no saber cuál de los cuarenta y uno abrir**. `grep` y `regex_search` buscan TEXTO;
+ * esto contesta sobre el modelo ya resuelto, así que un `mapcol` encuentra su colección
+ * aunque el nombre aparezca en otros veinte sitios.
+ *
+ * **El esquema es deliberadamente pequeño.** El inspector midió que el 87 % de una llamada
+ * son los esquemas de las tools y quitarle al orquestador tres que no podía usar valió un
+ * −24 % del turno. Una tool con una operación enumerada y un nombre opcional cuesta poco en
+ * cada llamada; cuatro tools separadas costarían cuatro veces eso para siempre.
+ *
+ * **Las rutas que devuelve son VIRTUALES y ya están filtradas.** Quien las traduce y aplica
+ * `puedeLeerRuta` y `esVistaAplanada` es el adaptador (`navegacion/modeloDeProyecto.ts`), y
+ * lo hace en la FUENTE: lo que el agente no puede abrir no llega ni a estar en el índice. Se
+ * filtra ahí y no aquí a propósito — es el único sitio donde una ruta se crea, está probado
+ * contra una fuga, y un segundo filtro sobre los mismos datos sería un segundo sitio donde
+ * equivocarse sin añadir barrera. Lo que esta tool NO hace nunca es aceptar una ruta del
+ * modelo: se pregunta por NOMBRE, así que no hay ruta que validar a la entrada.
+ */
+/** Topes. Una respuesta que no cabe se recorta DICIENDO cuánto se dejó fuera: una lista
+ *  truncada en silencio se lee como la lista entera, y sobre eso se concluye de más. */
+export declare const LIMITES_NAVEGACION: {
+    readonly inventario: 200;
+    readonly referencias: 60;
+    readonly campos: 150;
+    readonly definiciones: 20;
+    readonly problemas: 40;
+};
+/**
+ * La tool. `cargar` entra por parámetro —y con él la raíz ya fijada— para que el modelo no
+ * pueda decir sobre QUÉ proyecto pregunta: si pudiera, esto sería una tool que lee cualquier
+ * carpeta de la máquina.
+ */
+export declare function crearNavegacionXone(cargar: CargarIndice, ficheros: ReadonlySet<string>, cargarEstilos?: CargarEstilos): import("@langchain/core/tools").DynamicStructuredTool<z.ZodObject<{
+    operacion: z.ZodEnum<{
+        estilos: "estilos";
+        detalle: "detalle";
+        app: "app";
+        inventario: "inventario";
+        definicion: "definicion";
+        referencias: "referencias";
+        campos: "campos";
+        problemas: "problemas";
+    }>;
+    nombre: z.ZodOptional<z.ZodString>;
+}, z.core.$strip>, {
+    operacion: "estilos" | "detalle" | "app" | "inventario" | "definicion" | "referencias" | "campos" | "problemas";
+    nombre?: string | undefined;
+}, {
+    operacion: "estilos" | "detalle" | "app" | "inventario" | "definicion" | "referencias" | "campos" | "problemas";
+    nombre?: string | undefined;
+}, string, unknown, "xone_navegacion">;

package/dist/agent/grafo/opcionesDeFicheros.d.ts

@@ -0,0 +1,23 @@
+/**
+ * Presupuesto de las herramientas de ficheros.
+ *
+ * DeepAgents 1.13 incorpora `max_count` y `output_mode` en `grep`. El valor por
+ * defecto de la librería (1.000) sigue siendo demasiado generoso para un agente
+ * que explora proyectos XOne: 100 resultados bastan para localizar candidatos y
+ * el modelo puede subirlo explícitamente en una búsqueda excepcional.
+ *
+ * A partir de 6k tokens la salida se conserva bajo `/large_tool_results/` y se
+ * sustituye por una referencia paginable. Así una lectura o búsqueda accidental
+ * no consume toda la ventana antes de que actúe el resumen de conversación.
+ *
+ * **Esa carpeta se monta FUERA del proyecto** (`core/descargas.ts`,
+ * `agent/grafo/proyecto.ts#backendConDescargas`), y hasta el 10-09-2026 no: la escribe la librería
+ * llamando al backend directamente, esa ruta no estaba montada en ninguna parte y caía en el
+ * `FilesystemBackend` de la raíz. Medido en el AppDemo real del usuario, 26 KB de salida
+ * cruda de una tool dentro de la app XOne y commiteados. Bajar este tope no era el arreglo:
+ * el desalojo es la función, el fallo era el sitio.
+ */
+export declare const OPCIONES_BUSQUEDA_FICHEROS: {
+    readonly grepMaxCount: 100;
+    readonly toolTokenLimitBeforeEvict: 6000;
+};