Arslan, explicado.Diseño, implementación y evolución, desde el primer prototipo hasta v0.1.63

01 / Visión generalDel lenguaje natural al trabajo real

Arslan es un asistente personal de IA de código abierto, diseñado ante todo para Mac y para trabajar en local. El usuario describe la tarea que quiere realizar; Arslan organiza el contexto, consulta al modelo, utiliza herramientas, registra la ejecución y entrega respuestas o archivos que se pueden verificar. Reúne en un mismo entorno conversaciones, memoria, procesamiento de archivos, terminal, páginas web, operaciones con algunas aplicaciones nativas y tareas en segundo plano.

El autor desarrolla e itera el proyecto de forma independiente con ayuda de IA, una práctica conocida como vibe coding. Este documento recorre los objetivos del producto y los límites reales de su código: explica las decisiones de diseño, el funcionamiento del sistema y su evolución desde los primeros prototipos hasta v0.1.63.

Un entorno para distintos tipos de trabajo

Qué significa priorizar el trabajo en local

La prioridad local describe dónde se almacenan principalmente los datos y dónde se ejecuta el trabajo: la interfaz de escritorio, el servicio local, la base de datos, el espacio de trabajo y las herramientas de Mac funcionan principalmente en el equipo del usuario. El usuario configura el modelo; cuando usa un modelo en la nube, las conversaciones, los fragmentos de documentación y los recuerdos autorizados incluidos en la petición se envían al proveedor correspondiente. También se pueden conectar endpoints de modelos locales compatibles, aunque la disponibilidad concreta de llamadas a herramientas y de capacidades visuales depende del modelo y de la implementación del servicio.

Por tanto, la arquitectura de Arslan debe responder a dos preguntas: en qué equipo se realiza el trabajo y qué contenido se envía a cada endpoint de modelo. La persistencia local de los datos, el permiso para usar memoria en la nube y los permisos de las herramientas cumplen funciones diferentes que no se pueden resumir en un único interruptor de «modo local».

Versión de referencia

Este documento toma como referencia la versión oficial v0.1.63, publicada el 27 de octubre de 2026 a las 22:26:31, hora de Pekín (UTC+8). La información se verificó hasta el 27 de octubre de 2026. Los enlaces al código apuntan al commit de publicación 9bbb6ad653b4. Los desarrollos posteriores, las funciones históricas y las futuras líneas de ingeniería se identifican por separado.

Puntos de entrada de la implementación: Entrada unificada de Arslan; Contexto de uso de tareas y memoria; Integración de modelos; Notas de v0.1.63.

02 / Desarrollo independiente y código abiertoUna persona, con ayuda de IA, convierte una aplicación en un sistema

Arslan es un proyecto que he desarrollado de forma independiente con ayuda de IA, lo que habitualmente se conoce como vibe coding. Desde el primer prototipo hasta las versiones posteriores, siempre he llevado adelante el proyecto por mi cuenta.

Aquí, «desarrollo independiente» significa que el autor dirige y desarrolla el proyecto en su conjunto, con la IA como herramienta de colaboración durante la implementación. Arslan también se apoya en frameworks de código abierto, API del sistema, modelos externos y componentes de terceros. El método de desarrollo, la responsabilidad sobre el proyecto y la procedencia de sus componentes son conceptos distintos. Las secciones siguientes se centran en el diseño y la implementación que finalmente forman parte del producto.

De generar código a mantener un producto utilizable

Que un fragmento de código funcione solo resuelve una pequeña parte del producto. Una aplicación de escritorio también debe gestionar el arranque de los servicios, la conexión de las ventanas, la migración de bases de datos antiguas, la limpieza tras finalizar procesos, la titularidad de los permisos del sistema y el funcionamiento del instalador en equipos sin entorno de desarrollo. Un agente añade nuevas incertidumbres: el modelo puede agotar el tiempo de espera, los parámetros de una herramienta pueden llegar truncados, la lectura de una página puede quedar incompleta y una ejecución puede requerir la aprobación del usuario a mitad del proceso.

Estos problemas orientaron gradualmente la evolución de Arslan hacia cuatro prioridades: delimitar las entradas y los estados con contratos explícitos, comprobar la finalización mediante resultados observables de las herramientas, controlar los efectos reales con límites de permisos y validar los cambios mediante pruebas y comprobaciones de aceptación de cada versión. La ayuda de IA puede acelerar la implementación y el diagnóstico, pero la entrega final necesita el respaldo de todos estos controles.

Qué aporta Arslan y qué aportan sus dependencias

El proyecto es de código abierto bajo Apache-2.0. Las licencias y atribuciones de los componentes de terceros figuran en THIRD_PARTY_NOTICES.md, que también se incluye en la app; ahí consta Hermes Agent (MIT), del que se adaptó la lectura de comandos de shell de Arslan. El código abierto permite examinar la implementación, sus límites y su evolución, e incorporar a la documentación las razones de cada decisión.

La descripción del método de desarrollo procede de la declaración del autor. Implementación y atribuciones: Licencia del proyecto; Atribuciones de terceros; Decisión arquitectónica sobre el núcleo de ejecución; Refactorización del bucle unificado.

03 / TecnologíasFunciones de la interfaz, el contenedor de escritorio, la ejecución y los datos

Las tecnologías de Arslan se organizan según las necesidades de distribución de escritorio y las responsabilidades de un agente personal. Las versiones exactas que se indican a continuación proceden de los archivos de bloqueo de v0.1.63 y representan las dependencias resueltas para ese código fuente. No son versiones de herramientas que el usuario deba instalar en su equipo ni versiones de lanzamiento del proyecto.

Por qué se conserva el núcleo de ejecución en Python

Python se ocupa de los adaptadores de modelos, el procesamiento de documentos, el bucle del agente y los servicios de tareas, reutilizando directamente el ecosistema y la implementación existentes. Tauri y Rust gestionan las ventanas, el ciclo de vida de los procesos y la integración nativa. La decisión de conservar este núcleo está documentada en un registro público de arquitectura. Migrarlo a otro lenguaje cambiaría a la vez las herramientas, las migraciones de datos, el empaquetado y los límites de las pruebas; sus ventajas no pueden evaluarse solo por ser «más nativo».

La estructura está dividida en capas lógicas, pero el despliegue sigue centrado en el servicio local. Los módulos internos de Python no se convierten en microservicios remotos independientes, ni necesitan Redis, Celery, Docker o Kubernetes para funcionar. Hands, Bridge, los servicios MCP y los subprocesos del terminal establecen límites entre procesos donde hacen falta permisos o entornos de ejecución independientes.

Dependencias fijadas: Archivo de bloqueo del frontend; Archivo de bloqueo de escritorio; Archivo de bloqueo de Python. Diseño y atribuciones: Decisión sobre el núcleo de ejecución; Atribuciones de terceros.

04 / Cómo ha evolucionado el proyectoDe generar expertos a un Arslan capaz de trabajar de forma continuada

El autor desarrolla Arslan de forma independiente y continuada mediante vibe coding con ayuda de IA. Su evolución incluye tanto nuevas capacidades como diseños que se han descartado: algunas funciones necesitaban completar sus condiciones de funcionamiento; en otros casos, era necesario eliminar complejidad. Entender estos cambios explica mejor la arquitectura actual que enumerar todas las funciones históricas en una sola lista.

Junio: cerrar el ciclo de creación de agentes mediante conversación

El primer commit conservado, del 7 de junio de 2026, comenzó por el modelo de datos. La orientación inicial era un Meta-Agent: permitir a usuarios sin conocimientos técnicos crear expertos de un dominio mediante conversación y encargarles tareas. Después llegaron los adaptadores de modelos, el registro de herramientas, la máquina de estados del diálogo de requisitos, las plantillas, Spawn Manager y la CLI. El 8 de junio se conectaron FastAPI, la base de datos asíncrona, la autenticación, WebSocket y la interfaz React; el prototipo ya ofrecía una entrada interactiva con persistencia y recuperación de conexiones.

Cuando las herramientas comenzaron a ejecutarse realmente, el sistema necesitó saber qué se había hecho y aportar información a las respuestas. El 23 de junio se incorporaron Runs, Steps y Evaluations, junto con la fragmentación de documentos y SQLite FTS5; el 27 de junio se añadieron los transportes stdio y HTTP de MCP. El proyecto pasó así de generar instrucciones para un experto a gestionar una ejecución completa: invocar modelos, ejecutar herramientas, guardar el proceso, recuperar información y devolver el resultado al usuario.

Primer modelo de datos; Modelo de datos de Runs; Índice de conocimiento FTS5; Transporte HTTP de MCP.

Julio: convertir la memoria y la distribución en problemas de ingeniería

El 5 de julio, Second Brain incorporó embeddings y búsqueda híbrida filtrada por ámbito, combinando búsqueda de texto completo, similitud vectorial y fusión de resultados mediante RRF. Más adelante se añadieron la procedencia de los hechos, su vigencia, sustitución y revocación, las propuestas de organización y los registros de uso. La memoria dejó de ser un mero resumen del chat: la relevancia, la vigencia y el ámbito de la información debían determinar si podía entrar en el contexto del modelo.

Incluir más historial en el contexto plantea nuevos compromisos: una búsqueda demasiado amplia puede introducir información irrelevante, los hechos antiguos pueden desplazar a los recientes y los textos externos pueden influir en el comportamiento a largo plazo. Por eso, en julio se empezó a registrar la procedencia y la secuencia temporal de los hechos, a distinguir las adiciones automáticas de las modificaciones que requieren revisión y del contenido sensible, y a enviar las propuestas de organización a una bandeja de revisión. La memoria siguió evolucionando con estas restricciones. Poder verla, corregirla y retirarla pasó a ser un objetivo de ingeniería más concreto que simplemente «recordar más».

En esta etapa también se abordó el mantenimiento a largo plazo. El 14 de julio, las migraciones de base de datos pasaron a un ejecutor propio con versiones y se eliminó la dependencia de Alembic. El 10 de julio se adoptó la licencia Apache-2.0 y se añadieron NOTICE y SECURITY.md; el 25 de julio apareció un commit explícito de preparación para abrir el código. El 27 de julio se publicó v0.1.0, la primera versión instalable de escritorio, que distribuía el contenedor Tauri junto con el backend Python empaquetado. La firma, la notarización, las actualizaciones y las comprobaciones de primera instalación pasaron a formar parte del proceso de publicación.

El entorno de instalación real reveló enseguida carencias invisibles en las pruebas de desarrollo: los paquetes v0.1.0–0.1.6 no incluían una dependencia necesaria de WebSocket. El endpoint de salud respondía correctamente, pero el chat no podía conectarse. La versión 0.1.7 corrigió las dependencias y las importaciones implícitas de PyInstaller e incorporó un handshake real a las pruebas de aceptación del instalador. El fallo explica por qué «el backend ha arrancado» debe comprobarse además como «todo el recorrido del usuario funciona».

Búsqueda híbrida; Migraciones con versiones; Preparativos para abrir el código; Análisis del fallo de WebSocket en el instalador.

Agosto: integrar capacidades y hacerlas comprensibles

La versión 0.1.20 distinguió tres estados de las credenciales: sin configurar, descifrables y no descifrables, y estabilizó la sal y la migración de claves. La búsqueda incorporó información de fuentes y errores, y los modelos comenzaron a repartirse las tareas. Después se añadieron gradualmente MCP OAuth, el inicio de sesión de OpenRouter, la configuración inicial, los manifiestos de extensiones, la lectura y escritura en el espacio de trabajo local, las tareas programadas y SSH. Con más extensiones, el sistema también tenía que explicar con precisión si una conexión podía invocar herramientas, si los recursos asignados estaban activos y qué acción requería autorización.

La ejecución local también empezó a dividirse en niveles. La lectura y la escritura del espacio de trabajo se separaron; escribir requería su autorización correspondiente. Las tareas programadas obtuvieron un permiso propio de programación. SSH podía recordar equipos, pero cada ejecución remota seguía necesitando confirmación. El catálogo de herramientas describía así tanto las capacidades como sus condiciones de uso. Para el usuario, «conectado» y «autorizado para esta ejecución» son estados diferentes que deben reflejarse en la interfaz y en el contexto del modelo.

El turn journal de 0.1.23 permitió recuperar respuestas que seguían generándose después de cambiar de conversación. La corrección para localizar npx en la aplicación instalada volvió a mostrar que una aplicación de escritorio recibe un entorno distinto al de un terminal. El eje de agosto no fue solo conectar más servicios, sino convertir las conexiones, los estados y las autorizaciones en operaciones comprensibles.

Septiembre: de una respuesta aislada a un trabajo trazable

La versión 0.1.38 reforzó la fiabilidad: un sandbox de Python que deniega la ejecución cuando no puede garantizar el aislamiento, un entorno de cálculo independiente, Runs persistentes, entregables, puntos de control y un presupuesto de ejecución compartido. Las versiones preliminares y la estabilización de 0.1.40 siguieron avanzando en memoria de proyectos, fuentes documentales, continuidad de tareas y copias de seguridad previas a las migraciones, manteniendo documentados los fallos conocidos en comparaciones entre idiomas y entre documentos. Que una fuente sea accesible mediante un enlace solo demuestra que se puede localizar, no que la conclusión del modelo sea correcta.

Algo antes, entre el 31 de agosto y el 3 de septiembre, la voz avanzó desde la lectura en voz alta (0.1.32) y la pulsación para hablar (0.1.36) hasta la conversación semidúplex (0.1.37), con correcciones de permisos de micrófono y selección de idioma. Al mismo tiempo, las pruebas de aceptación de investigación de 0.1.40 no presentaron como éxitos las comparaciones fallidas entre idiomas; la revisión de fuentes de 0.1.41 quedó desactivada por defecto tras una calibración insatisfactoria (0.1.63 eliminó más tarde esa revisión de investigación). Estos registros delimitan qué significa que «el sistema ha realizado comprobaciones» y permiten orientar las siguientes mejoras hacia fallos reales.

En 0.1.41, cerrar la ventana pasó a dejar la aplicación trabajando en la barra de menús; 0.1.42 llevó las tareas largas a segundo plano para que el usuario pudiera seguir conversando; 0.1.43 distinguió entre un límite flexible de presupuesto y una parada obligatoria: al alcanzar el primero, se utiliza lo ya reunido para cerrar la tarea y evitar que una investigación quede sin entregable. Las tareas adquirieron un ciclo de vida cada vez más independiente de la interfaz, sin que eso implique que cualquier acción externa pueda repetirse automáticamente de forma segura después de un fallo.

De finales de septiembre a octubre: converger en un único bucle de ejecución

El diseño inicial trataba a los expertos como roles permanentes, cuya selección, invitación y enrutamiento debían gestionar tanto el usuario como el sistema. La versión 0.1.44 dejó de crear y coordinar expertos; sus métodos podían convertirse en skills. La 0.1.46 detuvo la evolución en segundo plano de expertos que ya no tenía una vía de uso. La 0.1.48 eliminó el router previo y envió cada mensaje directamente al bucle del agente. Las notas de publicación señalan que algunas respuestas fijas del tipo «no puedo hacerlo» procedían de decisiones de enrutamiento y no de una falta real de capacidad. Esta simplificación devolvió la selección de herramientas al proceso de ejecución que dispone de las herramientas y del estado reales.

Tras la convergencia, las mejoras se concentraron en la capa común de ejecución: 0.1.49 perfeccionó el protocolo nativo de herramientas y la recuperación ante truncamientos y fallos; 0.1.50 añadió el estado actual del trabajo, planes y rutas alternativas; 0.1.51 incorporó el sandbox de comandos e Island; 0.1.52 integró la memoria del usuario y las learned practices en los trabajos posteriores. Aquí, «aprender» significa guardar y utilizar experiencias administrables, no actualizar los pesos del modelo fundacional.

La versión 0.1.53 añadió la lectura del árbol de accesibilidad y la operación de aplicaciones Mac mediante un helper Hands independiente, e incorporó el componente Mac de iPhone Bridge. La 0.1.54 completó ese componente Mac para la app de iPhone (aprobaciones con Touch ID, una entrada por teléfono y limpieza al eliminar un teléfono) y cerró cuatro huecos de la barrera del terminal; en cada uno de ellos el sistema pregunta más, nunca menos. La 0.1.55 da a todo lo que pide una respuesta un mismo aspecto y una sola cola: las tarjetas pueden responderse desde Inbox y, salvo que el paso sea arriesgado, desde Island. La 0.1.56 organiza los proyectos en dos capas: un tablero para todos ellos y, en cada uno, niveles con puntos de control que Arslan solo marca a partir de evidencias que puede señalar. La 0.1.57 permite que las capacidades crezcan: cuando un paso necesita algo que Arslan no sabe hacer, busca un servidor o una skill, pregunta, lo instala fijado y en un sandbox, lo prueba y reintenta el paso. La 0.1.58 hace legibles las respuestas y los archivos: una línea discreta con lo realizado, los archivos devueltos como tarjetas, un lector y cualquier modelo en cada conversación. La 0.1.59 mantiene viva la conversación durante las respuestas largas, responde en el idioma del usuario y da por terminado el trabajo en segundo plano que ha concluido. La 0.1.60 incorpora Hands v2, que puede ver la única ventana en la que trabaja, tomar prestado un momento el primer plano y, solo con un sí del usuario, tomar el control de la pantalla. La 0.1.61 lleva una única tarjeta de aprobación a la ventana de chat, el Inbox, la Island y el iPhone, servidores MCP que se inician solos y una corrección para los modelos Claude que rechazan el ajuste temperature. La 0.1.62 deja que los comandos largos de terminal se ejecuten hasta su propio límite, restringe «necesita tu revisión» a las acciones que de verdad pueden haber dejado rastro, remodela las descripciones de herramientas MCP para que el rechazo de un proveedor no rompa todos los chats e impide que la escritura de archivos siga un enlace fuera de la carpeta de trabajo. La 0.1.63 te permite añadir un mensaje mientras una respuesta se ejecuta, transmite las respuestas a medida que se escriben, ejecuta hasta cuatro lecturas a la vez, guarda un punto de control para poder deshacer un turno, envía las herramientas poco usadas solo bajo demanda, añade un límite en dólares por tarea (activado por defecto) y pregunta antes de cada comando nuevo mientras el juicio sobre los comandos inofensivos se completa más adelante. También eliminó código: el código de la era de los expertos al que ya no llegaba ninguna respuesta, la maquinaria de evolución y curación, la revisión de investigación, «Destilar», la vía de despliegue con Docker y la copia incorporada de Hermes. La antigua coordinación de expertos ya es histórica; tampoco cabe deducir que las operaciones de accesibilidad permitan controlar de forma fiable cualquier aplicación. La versión actual sigue delimitando el trabajo que el modelo puede realizar mediante estados visibles, permisos explícitos y resultados verificables.

Bases de fiabilidad; Alcance del asistente de investigación estable; Trabajo en segundo plano; Bucle unificado del agente; Hands y Bridge.

05 / Arquitectura del sistemaResponsabilidades de la interfaz, la ejecución y los permisos

Una explicación sencilla: React es el entorno de trabajo que ve el usuario; Tauri, el contenedor que conecta con macOS; Python, el motor que coordina el trabajo; el modelo aporta criterio; las herramientas producen acciones reales; y la base de datos y el disco conservan el proceso y los resultados. Estas funciones se integran en un mismo producto de escritorio, pero no pertenecen a un único proceso.

Por qué se eligió esta división en capas

Cómo se conectan los procesos al arrancar

1. Tauri inicia el sidecar Python empaquetado y muestra una pantalla de arranque hasta que el servicio está listo.
2. El sidecar intenta primero usar el puerto local 47317; si está ocupado, utiliza un puerto efímero y comunica por la salida estándar el handshake ARSLAN_PORT.
3. Cuando recibe el puerto, el contenedor de escritorio hace que el WebView del sistema cargue la página React servida localmente. Priorizar un puerto fijo ayuda a mantener estables el origen de WebKit y el almacenamiento local de la interfaz; el catálogo de sesiones del servidor permite recuperar el historial aunque cambie el puerto.
4. La interfaz gestiona recursos mediante HTTP y recibe por WebSocket el texto en streaming, los estados de herramientas, las aprobaciones y el progreso de las tareas. La conexión local también requiere token y comprobación de origen; el servidor de la app de escritorio exige siempre su token, no acepta como llamante a ningún otro sitio web e ignora los ajustes heredados del entorno que lo lanzó.
5. El contenedor mantiene abierto el canal de entrada estándar como vínculo de ciclo de vida. Si la salida del proceso padre produce EOF, el sidecar puede limpiar y cerrarse. La salida también debe consumirse de forma continua para evitar bloqueos o procesos huérfanos tras perder la conexión.

Estos detalles mantienen coordinados los ciclos de vida de ventanas, servicio y base de datos. Una respuesta correcta del endpoint HTTP de salud no demuestra que WebSocket, adjuntos, recursos estáticos y helpers nativos estén disponibles; cada uno debe comprobarse durante la aceptación de la versión.

Detalles de arranque: Entrada del servicio empaquetado y estrategia de puertos; Handshake del sidecar y gestión de canales; Conexión WebSocket.

Arquitectura anterior y actual: reutilizar capacidades y retirar la coordinación de expertos

Un «bucle unificado» no significa que todo sea secuencial ni que nunca se delegue. El código conserva workers de solo lectura con restricciones. No equivalen al antiguo sistema de expertos con personalidad, equipamiento, evolución y enrutamiento propios.

Entradas del código: Contenedor de escritorio y ciclo de vida del sidecar; Entrada unificada; Bucle de ejecución; Decisión de conservar el núcleo de ejecución nativo en Python; Supervisión del proceso Bridge; Canal local de control de Bridge; Protocolo entre dispositivos.

06 / Entorno de ejecuciónDar a cada petición un proceso, límites y un resultado

El núcleo de ejecución de Arslan convierte la intención del usuario en una secuencia de acciones observables: prepara el contexto, consulta al modelo, valida las peticiones de herramientas, ejecuta las operaciones autorizadas, lee los resultados reales y decide si continuar o entregar. Desde v0.1.60 la entrada predeterminada es el bucle unificado; los mensajes entran directamente en el flujo de respuesta y los hechos duraderos se extraen después de responder. El flujo principal no empieza con una llamada de enrutamiento mediante modelo, y el código de la era de los expertos al que ya no podía llegar ninguna respuesta (crear expertos, sus plantillas y su motor) se eliminó en v0.1.63.

Código: Entrada de mensajes y composición del contexto; Contexto de confianza de la tarea; Bucle unificado de herramientas.

El modelo propone el siguiente paso; el entorno impone las condiciones de ejecución

El modelo ve las herramientas como un conjunto de nombres, descripciones y esquemas de parámetros. Cuando devuelve tool_calls de forma estructurada, el entorno analiza el JSON, valida los parámetros y vuelve a comprobar si la herramienta sigue disponible, si el presupuesto permite la operación y si hace falta autorización del usuario. El registro asocia las herramientas integradas con sus funciones de ejecución; las herramientas con el prefijo mcp_ se derivan a llamadas MCP, y al modelo solo se le ofrecen los servidores MCP que están listos en ese momento. Que una herramienta figure en el registro no implica que se ofrezca en todos los turnos: desde v0.1.63 una solicitud lleva solo las herramientas de uso habitual más dos buscadores, find_tools y use_tool; las herramientas poco usadas y las herramientas MCP se encuentran y se llaman bajo demanda, con las mismas aprobaciones y registros que una llamada directa. La lista que una conversación ha usado bajo demanda crece como máximo hasta 12 y se guarda solo en memoria.

La integridad de la respuesta es un límite fundamental: si el proveedor trunca una llamada a herramientas por el límite de longitud de salida, no se ejecuta ninguna llamada de ese lote, aunque alguna parezca completa. El texto del modelo que acompaña llamadas a herramientas solo describe el proceso y no puede tratarse como entrega final anticipada. Se registran puntos de control antes y después de ejecutar, y el resultado real vuelve al modelo con la identidad de su llamada. El contenido de páginas web, archivos o herramientas externas sigue tratándose como datos.

Por tanto, «he guardado el archivo» debe corresponder a un guardado real y a una referencia al entregable; una promesa en lenguaje natural no se convierte automáticamente en una operación realizada. Los fallos de herramientas también alimentan la siguiente iteración. El bucle puede cambiar de ruta, pero debe seguir respetando los mismos permisos y presupuesto.

Por ejemplo, al «leer un directorio concreto y generar un inventario», la ruta entra primero como dato dentro del ámbito de la tarea. El modelo solicita la lectura, la herramienta devuelve información real sobre los archivos y solo entonces existe una base para elaborar el inventario. Si además se pide mover o eliminar archivos, el entorno debe evaluar la autorización correspondiente. La entrega final debe apuntar al archivo ya generado e indicar qué se comprobó. La lista de archivos, los acuses de las operaciones y las referencias a entregables desempeñan funciones probatorias distintas.

Desde v0.1.63 la respuesta aparece a medida que se escribe (en los endpoints indicados a continuación), y las comprobaciones que antes retenían una respuesta añaden después una corrección cuando hace falta; si un stream falla a medias, Arslan conserva lo que viste y dice que la respuesta se interrumpió en lugar de empezar de nuevo. Cuando el modelo pide varias lecturas seguidas (páginas web, búsquedas, herramientas MCP que su servidor marca como de solo lectura), se ejecutan hasta cuatro a la vez; cada resultado sigue emparejado con la llamada que lo pidió, y cualquier llamada que no sea una lectura se ejecuta sola en su lugar.

Código: Lecturas que se ejecutan juntas; Streaming y bucle de herramientas.

Una entrada común que conserva las diferencias entre protocolos

LLMAdapter ofrece una interfaz común de llamada; cada Provider gestiona el formato de petición, los eventos de streaming, las llamadas a herramientas y usage. Las implementaciones de Provider envían peticiones HTTP mediante httpx; los endpoints compatibles con OpenAI también pueden configurarse como servicios de modelos locales. Si se elige un modelo en la nube, el contexto de la petición se envía al proveedor configurado por el usuario.

Trajectory es la traza estructurada del bucle y conserva la relación entre cada llamada y su resultado. Unifica los registros internos y permite a cada proveedor utilizar su protocolo, evitando reducir las interacciones con herramientas a un texto corriente difícil de comprobar. Si un endpoint rechaza el historial nativo, el turno pasa a la representación anterior durante el resto de ese turno.

En esta capa hay dos reparaciones. Desde 0.1.61, cuando un proveedor rechaza un ajuste opcional de la solicitud (por ejemplo temperature en los modelos Claude más recientes), Arslan reenvía sin él, o con el nombre que pide el error, y lo recuerda para ese modelo hasta reiniciar. Desde 0.1.62, las descripciones de las herramientas MCP se remodelan a una forma que aceptan Anthropic, los proveedores compatibles con OpenAI y Gemini; si un proveedor aun así rechaza una herramienta, esa herramienta se deja fuera durante el resto de la respuesta (un segundo rechazo, o un rechazo que no nombra ninguna herramienta, deja fuera todas las herramientas MCP en esa respuesta). Las herramientas integradas se envían tal como están escritas.

Código: Fachada de modelos; Estructura de datos de las trazas; Contrato de capacidades de Provider; Reenvío sin un ajuste rechazado; Remodelado de las descripciones de herramientas MCP; Herramientas bajo demanda; Cambios en la capa de ejecución.

Colaboradores temporales y tareas en segundo plano

delegate_work reparte investigaciones independientes entre workers temporales: hasta 4 encargos por lote y un máximo de 2 en ejecución simultánea. Actualmente, los workers solo tienen acceso a web_search y web_extract; no pueden escribir archivos ni memoria personal ni delegar de forma recursiva. El ejecutor principal recibe, verifica e integra los materiales. Este diseño conserva las ventajas de la investigación paralela y concentra la responsabilidad de ejecución en la tarea original.

Los jobs en segundo plano sirven para tareas completas de mayor duración. Tienen contexto y presupuesto propios y reutilizan el bucle de herramientas y los procesos de verificación y reparación de entregables. El progreso llega a la conversación mediante tarjetas de tarea, con un máximo predeterminado de 3 jobs simultáneos. La conexión de red, la ventana de chat y la ejecución en segundo plano tienen ciclos de vida distintos: cambiar de conversación no cancela la tarea. Si el equipo entra en reposo o el proceso termina, el trabajo no se transfiere a la nube para continuar.

Cerrar el trabajo antes de alcanzar el límite estricto

El presupuesto contabiliza las peticiones al modelo, las llamadas a herramientas, los tokens acumulados, el tiempo de ejecución y, desde v0.1.63, los dólares. Una respuesta de chat y una tarea en segundo plano tienen ahora los mismos límites: el nivel elegido en Ajustes, standard por defecto. Al alcanzar el soft limit, el bucle debe dejar de ampliar la investigación y organizar lo obtenido; el hard limit evita que el consumo siga creciendo sin control. Las ejecuciones anidadas y los reintentos también consumen presupuesto. Un mecanismo adicional detecta las llamadas repetidas sin progreso para evitar insistir en la misma vía fallida.

La tabla muestra los valores soft predeterminados; cada valor hard equivale a 1.5 veces el valor soft. El límite de una salida individual y el tamaño máximo de los entregables se calculan por separado. Los tokens se contabilizan después de recibir la respuesta, por lo que estos umbrales son límites de planificación, no topes exactos de coste ni promesas de duración. El tiempo de espera de una tarjeta de aprobación no cuenta como tiempo de ejecución. Además de los niveles hay un límite en dólares por tarea, activado por defecto en 2 $ (Ajustes › Segundo plano › Límite en dólares por tarea): la ejecución empieza a cerrarse al llegar a dos tercios de él y se detiene al alcanzarlo. Solo cuentan las respuestas de modelos con precio conocido, así que un modelo local o uno que falta en la tabla de precios no suma nada y los límites de tokens siguen vigentes; la comprobación se hace antes de la siguiente petición, de modo que una ejecución puede pasarse en una respuesta. Una tarea reanudada hereda los contadores, el tiempo de ejecución y los dólares ya consumidos; la espera durante una interrupción no cuenta como nueva ejecución ni reinicia el presupuesto.

El trabajo largo se queda en el chat: Arslan ya no lo empuja por sí mismo a segundo plano; una tarea en segundo plano es el mismo trabajo hecho en otro lugar, cuando tú o el modelo lo decidís. Pasados diez minutos, una respuesta te avisa de que sigue trabajando. Un comando de terminal se ejecuta durante el tiempo que pidió (2 minutos por defecto, 10 como máximo), nunca más allá del tiempo que le queda a la respuesta; si un límite de tiempo lo detiene, Arslan sigue viendo la salida hasta ese momento y se le avisa de ello, y un comando que inunda su salida conserva el principio y el final. Por defecto, cada comando nuevo muestra primero una tarjeta (v0.1.63), y una tarea programada no ejecuta comandos en esta versión: ese paso se omite y aparece en el Inbox. Una tarjeta sin respuesta caduca a los 30 minutos, y se le dice a Arslan que eso no es una negativa.

Código: Reglas de presupuesto; Límite de tiempo y tope de salida de los comandos; Tarjetas de aprobación y su caducidad; Colaboradores temporales; Tareas en segundo plano.

La tarea, sus intentos y la aceptación se registran por separado

TaskSpec guarda el contrato de la tarea: instrucciones, entradas, ámbito, criterios de aceptación y presupuesto, junto con su revisión. Una task puede tener varios attempt; cada attempt representa un intento concreto de ejecución. Los cambios del contrato, los resultados antiguos que llegan después de cancelar y los nuevos intentos tras reanudar no pueden mezclar sus estados. Las actualizaciones persistentes comprueban tanto la identidad del attempt como la row version para impedir que una ejecución obsoleta sobrescriba el estado actual.

Los resultados de aceptación distinguen entre superado, fallido, no ejecutado y no aplicable, entre otros. Cada decisión necesita evidencias correspondientes: no pueden omitirse las comprobaciones acordadas ni confiar todas a la autoevaluación del modelo. La existencia de archivos, su pertenencia a la tarea y sus resúmenes hash pueden validarse de forma determinista; la evaluación del modelo o de una persona resulta adecuada como complemento para la calidad subjetiva. La capa de repositorio también impide declarar el éxito si hay acciones en preparación, en curso o de efecto desconocido.

Por eso las revisiones de tarea deben conservar su identidad: un resultado generado para requisitos anteriores no demuestra automáticamente que los nuevos estén satisfechos. La aceptación debe corresponder a la misma revisión del contrato, a un intento válido concreto y a evidencias pertenecientes a esa tarea. Las comprobaciones esenciales no pueden marcarse arbitrariamente como «no aplicables»; solo admiten ese tratamiento los elementos no esenciales que cumplan las reglas del contrato. Si faltan evidencias, el resultado debe mantenerse sin verificar o incompleto hasta realizar más comprobaciones.

Reanudar a partir de las evidencias existentes

Los puntos de control guardan el progreso, el presupuesto utilizado y las referencias a evidencias y entregables. Los eventos permiten consultar la ejecución al reconectar la interfaz. El run registry del proceso mantiene las tareas asíncronas reales y sus mecanismos de cancelación, y distribuye eventos a las ventanas conectadas. Al reconectar se obtiene una instantánea y se adjunta el flujo de eventos de manera coordinada, reduciendo pérdidas o duplicados durante el relevo de conexión.

Tras reiniciar el proceso, las ejecuciones inconclusas se identifican como interrumpidas y requieren que el usuario continúe explícitamente. Si una acción externa ya se envió pero no se recibió su acuse, su efecto es desconocido: debe comprobarse antes de volver a enviarla. Restaurar una copia también revoca las autorizaciones antiguas y marca las acciones afectadas como inciertas. Los puntos de control indican desde dónde continuar con seguridad, pero no deshacen efectos externos ya producidos.

Un tipo distinto de punto de control sirve para «Deshacer este turno» (v0.1.63). La primera vez que un turno escribe un archivo o ejecuta un comando, Arslan guarda una vez la carpeta de trabajo tal como estaba. Deshacer devuelve los archivos a su sitio y quita ese turno y todos los posteriores de la conversación, junto con los hechos que enseñaron; los resúmenes se conservan y los ids de mensaje no se reutilizan nunca. La carpeta solo se guarda si tiene como máximo 20.000 archivos y 5 GB, hay espacio libre suficiente en disco y está en el mismo disco que los datos de Arslan. Las carpetas reconstruibles (entornos de Python, node_modules, resultados de compilación, __pycache__) y los archivos con forma de secreto se dejan fuera y nunca se devuelven; el cuadro de deshacer indica lo que no se guardó. Los archivos modificados después del turno se conservan y se enumeran, y deshacer se rechaza mientras una ejecución siga cambiando la carpeta.

Detener tiene también dos niveles: el registro de ejecución cancela el trabajo asíncrono en espera o en curso; el estado persistente impide que se confirmen resultados tardíos. Si un sistema externo ya aceptó una petición, cancelar la espera local no demuestra que aquel no la haya ejecutado. Por ello, la tabla de acciones distingue los estados preparada, iniciada, confirmada, fallida, de efecto desconocido y cancelada. La recuperación resuelve primero estos estados y después decide qué pasos pueden volver a intentarse.

Código: Contratos de tareas y aceptación; Estado persistente y controles de concurrencia; Validación de entregables; Ejecución y continuación explícita; Separación entre conexión y ejecución; Límites de restauración de copias; Puntos de control de carpetas para deshacer; Deshacer un turno.

Un turno que mantiene informada a la ventana

Desde 0.1.59, mientras un turno está en curso, el servidor envía a la ventana un evento de actividad («working») al menos cada 15 segundos, incluso cuando el modelo dedica varios minutos a escribir un único archivo largo; así, «Interrupted» (interrumpido) significa ahora que se ha perdido la propia conexión. Un mensaje enviado mientras Arslan todavía está respondiendo se pone en cola y se responde justo después, en lugar de rechazarse. Desde 0.1.63, un mensaje enviado mientras Arslan todavía está respondiendo llega a esa respuesta en su siguiente paso en lugar de esperar a que termine: los pasos que aún no han empezado se omiten, la respuesta lee primero el mensaje y la ventana indica que se ha añadido. Una respuesta que ya está escribiendo su respuesta final no tiene ningún paso por delante, así que el mensaje se ejecuta justo después. Mientras una tarjeta de aprobación espera, un mensaje la responde No, con el mensaje como nota, y se ejecuta a continuación. El idioma de la respuesta sigue al último mensaje del usuario: para determinarlo se ignoran las rutas, las URL y el código, y un mensaje sin palabras sigue el idioma de la interfaz. Una aprobación solicitada cuando la conexión de la ventana ya se ha cerrado deja de hacer fallar el turno; la tarjeta espera en Inbox, en Island o en la ventana reconectada.

Código: Eventos de actividad, cola y tarjetas tras reconectar; Mensaje añadido a una respuesta en curso; Idioma de la respuesta.

Proyectos: un tablero, niveles y puntos de control que exigen evidencias

Desde 0.1.56, un proyecto tiene un plan organizado en niveles, cada uno con una condición clara para superarlo y unos pocos puntos de control. Al elegir un tipo (juego, app, sitio web, investigación, escritura, vídeo, skill, viaje, empleo u otro), los niveles se redactan a partir de una plantilla, sin llamar a ningún modelo; «Let Arslan refine» los ajusta a la meta final con una sola llamada al modelo del propio usuario, y no se guarda nada hasta que el usuario crea el proyecto. Las columnas del tablero —Idea, Shaping, Doing y Done— se derivan del nivel actual y nunca se arrastran; Done y Dropped solo los asigna el usuario.

Arslan solo hace avanzar un plan a partir de evidencias que puede señalar, y únicamente en el nivel actual: un punto de control que nombra archivos se marca cuando estos aparecen en la carpeta del proyecto; después de cada turno del propio usuario, un juez evalúa si su mensaje indica que algo está hecho; una tarea en segundo plano iniciada desde el traspaso del proyecto marca su punto de control cuando termina como completada. Las marcas pequeñas pueden deshacerse; superar un nivel es una propuesta en la tarjeta, nunca una notificación ni un elemento de Inbox. Solo después de diez aciertos seguidos pregunta Arslan, una única vez, si puede pasar de nivel por su cuenta. Las reglas de plan que aprende, el ritmo del usuario y el aviso «stalled» permanecen en el equipo, y solo llegan a un modelo dentro de una petición de redacción que el propio usuario haya iniciado.

Código: Niveles, tablero y propuestas; Archivos, lo que dijo el usuario y ejecuciones; Plantillas de niveles; Reglas de plan, ritmo y estancamiento.

07 / Datos y memoriaConservar el contexto útil y delimitar con claridad los datos

Arslan guarda su estado principal en SQLite local: conversaciones, registros de ejecución, tareas, memoria personal, configuración de modelos y consumo tienen sus propios modelos de datos. Los archivos entregables se escriben en disco; el texto completo de las salidas de herramientas muy largas se guarda aparte en la carpeta de datos de la aplicación (durante 7 días), y el modelo lo lee por partes a partir de la ruta indicada en el resultado. Así, cerrar una ventana no borra el proceso de la tarea y permite gestionar por separado lo que se dijo, lo que realmente se hizo y lo que se puede recordar después.

El acceso a datos utiliza SQLAlchemy asíncrono y aiosqlite. Las conexiones activan WAL, la comprobación de claves foráneas y una espera de 5 segundos cuando la base está ocupada, y utilizan synchronous=NORMAL. Estas decisiones responden a una aplicación local de un solo usuario: reducen dependencias de despliegue y mejoran la coexistencia de lecturas y escrituras. Un bloqueo cooperativo del directorio de datos impide que las instancias que respetan el mismo protocolo utilicen simultáneamente los mismos datos.

Objetos de datos separados por responsabilidad

La tabla de tareas conserva el estado actual; la de revisiones, el contrato de la tarea; attempt registra los intentos; event proporciona eventos ordenados; y action registra las acciones reales y el estado de sus efectos. Juntas sustentan la verificación y la recuperación. La memoria personal separa identidad estable, revisiones de contenido y fuentes para facilitar la edición, la trazabilidad y la eliminación. No reutiliza directamente todas las conversaciones como memoria permanente.

Código: Conexión SQLite; Modelos de ejecución, materiales y configuración; Modelos de tareas; Modelos de contexto personal y memoria.

Contexto de trabajo: limitar la entrada del turno y conservar el historial original

La cantidad de contenido que un modelo puede recibir en cada petición es limitada. Arslan compone el contexto de trabajo con un resumen acumulativo de tamaño acotado y mensajes recientes. Desde v0.1.63 la ventana de historial se dimensiona según el modelo del turno: el 40 % de su ventana de contexto como estimación, nunca por debajo de 3,000 ni por encima de 24,000 tokens (un modelo desconocido supone 32,000, un modelo local 8,192), y el resumen también tiene un límite de longitud. Es un presupuesto para componer el historial, no el tamaño de toda la petición: las instrucciones del sistema, los esquemas de herramientas, los materiales y los resultados ocupan espacio adicional.

Cuando la conversación crece, los últimos cuatro turnos del usuario se mantienen íntegros (mientras quepan en la mitad del presupuesto) y los resúmenes de herramientas de los turnos más antiguos se enmascaran primero, lo que no cuesta nada; cuando el historial supera tres cuartas partes de su presupuesto, los mensajes antiguos se resumen, y el resumen conserva las secciones Objetivo, Progreso, Decisiones, Archivos tocados y Próximos pasos. Lo que cambia de un turno a otro (hechos, resumen, materiales, el idioma de la respuesta) viaja en un bloque de referencia al comienzo de la petición del turno, no en el prompt del sistema, y nunca se guarda como palabras del usuario. La compresión afecta a qué contenido se prepara para la siguiente petición, pero no elimina la conversación completa de la base de datos; si falla, los registros originales se conservan. Las salidas de herramientas demasiado largas se guardan por separado en disco: el modelo recibe un extracto del principio y el final, junto con la ruta del archivo, y puede leerlo por partes cuando sea necesario. La salida completa se limpia conforme a la política de retención.

Esta organización da prioridad a la información necesaria para la tarea actual y conserva las fuentes originales para comprobaciones posteriores. Un resumen solo es una representación comprimida del contenido existente; no sustituye al acuse real de una acción externa.

Memoria personal: primero el permiso de uso, después la relevancia

Cada entrada de memoria incluye tipo, ámbito, sensibilidad, política de uso, estado, información de confianza y versión. El ámbito puede ser global o un proyecto (existen además ámbitos internos, como dominio y experto), y cada entrada tiene también un propietario; políticas de uso como local_only determinan además si el contenido puede enviarse a modelos en la nube. El contexto de confianza de cada turno carga los ajustes de sesión desde la base de datos. El texto ordinario del usuario, las páginas web y las respuestas del modelo no pueden modificar por sí solos estos permisos.

«Acerca de ti» y «Notas del Mac» tienen una inclusión básica limitada; el resto se selecciona por relevancia. Desde v0.1.52, la opción «Recuérdame y úsalo en las conversaciones», activada por defecto, puede permitir usar entradas comunes de tipo cloud_allowed con los modelos en la nube configurados. El contenido sensible requiere permiso adicional; local_only no pasa a estar autorizado para la nube por activar la opción general.

ContextReceipt registra qué entradas y revisiones se utilizaron, por qué se seleccionaron y sus recuentos estimados, sin copiar su contenido. El usuario puede rastrear el fundamento de una selección de contexto sin que el sistema cree otra copia del contenido sensible.

Editar un recuerdo genera una nueva revisión y actualiza el puntero a la revisión vigente; los registros de origen siguen indicando cómo se formó esa versión. Los estados de pausa, caducidad, sustitución y eliminación también determinan su inclusión en contextos posteriores. Las versiones permiten comprobar los cambios, pero la eliminación borra los cuerpos de contenido que deben desaparecer. No es, por tanto, un registro de eventos en el que todo el historial sea permanentemente imborrable.

Código: Historial y resúmenes; Salidas extensas de herramientas; Tamaño del historial según la ventana del modelo; Bloque de referencia por turno; Permisos de sesión; Filtros de ámbito y privacidad y registros de uso.

Búsqueda documental: combinar palabras clave y vectores

El módulo de recuperación documental admite búsqueda de texto completo con SQLite FTS5 y búsqueda vectorial por similitud del coseno. La primera encuentra coincidencias léxicas; la segunda utiliza embeddings para encontrar fragmentos relacionados semánticamente. Cuando ambas están disponibles, RRF fusiona las clasificaciones. RRF compara posiciones, sin mezclar directamente puntuaciones originales de escalas distintas. Si no hay embeddings configurados o faltan vectores, se puede seguir buscando por texto completo.

Los fragmentos recuperados entran en el contexto con sus fuentes y el modelo elabora la respuesta según la pregunta actual: este es el RAG empleado aquí. La búsqueda documental solo se realiza en proyectos que tienen colecciones vinculadas; con un modelo en la nube, además, la conversación debe tener activado su propio permiso de memoria en la nube (el interruptor predeterminado «Recuérdame» no abarca los materiales). Los resultados entran en el contexto como valor de retorno de la herramienta recall. Nada de esto modifica los pesos del modelo fundacional ni requiere una base de datos vectorial independiente. La selección en memoria personal v2 utiliza principalmente filtros de permisos, texto completo y lógica local de relevancia; no debe deducirse que toda la memoria pase por el mismo procesamiento vectorial.

Aprender de la experiencia: convertir correcciones en reglas revisables

Lesson guarda correcciones del usuario, soluciones alternativas que funcionaron tras un fallo y características del entorno del equipo. Por ejemplo, si un comando necesita parámetros diferentes en el Mac actual, se puede guardar una práctica con su procedencia para tareas similares. Se recuperan como máximo 5 entradas, con un total aproximado de 800 caracteres, que se incluyen en el agent status dinámico sin alterar el prefijo estable del sistema. Se contabilizan las recuperaciones, el seguimiento de las prácticas y sus éxitos y fallos.

La capa judgment puede emitir decisiones muy acotadas sobre si merece la pena guardar algo o si duplica o contradice contenido existente, y registrar probabilidades y resultados posteriores. Las correcciones del usuario o experiencias no influidas por contenido externo pueden activarse directamente si los ajustes lo permiten y se consideran útiles; el resto que necesite revisión se convierte en propuestas. Las candidatas que contienen credenciales se descartan directamente; la regla de que la información sensible inferida requiere revisión pertenece a la memoria personal, no a las prácticas. Si no hay decisión o se agota su tiempo de espera, existen mecanismos alternativos.

Desde 0.1.55, una corrección solo cuenta como tal si responde a algo que Arslan hizo antes en la conversación: el primer mensaje es una petición, nunca una corrección. Una corrección que contradice la ruta que acaba de funcionar en el mismo turno no se aplica de inmediato, sino que se convierte en una propuesta a la espera del visto bueno del usuario; y un fallo que debe resolver el propio usuario, como que macOS deniegue un permiso, nunca se aprende como motivo para tomar otra ruta. Cuando Arslan guarda un recuerdo durante una conversación, lo indica en el propio hilo, con la opción de deshacerlo.

Estos mecanismos modifican el conocimiento que la aplicación guarda y recupera, sin entrenar los pesos del modelo. judgment también tiene distintos ámbitos de activación: los puntos de memoria, prácticas y proyecto se ejecutan después de la respuesta, y uno registrado (finalización del turno) está desactivado. Ningún judgment decide si se ejecuta un comando: el judgment shadow de las tarjetas de comandos se eliminó en v0.1.63, y solo decide el flujo de autorización.

Código: Búsqueda documental híbrida; Extracción y recuperación de prácticas; Decisiones acotadas y modos de ejecución.

Eliminar también debe afectar a resúmenes y copias antiguas

Al eliminar un recuerdo, el sistema incrementa deletion epoch, borra el texto de las revisiones antiguas de esa entrada y sus fuentes, y vacía los resúmenes acumulativos de todas las conversaciones y los prompts almacenados en caché en los registros de ejecución, para que ningún contenido derivado antiguo devuelva el recuerdo eliminado. El registro de eliminación solo conserva una huella del contenido para la comparación (un HMAC con una clave local) y metadatos como el ámbito, sin volver a guardar el texto eliminado. Los registros suppression impiden que la misma fuente, aún presente en el historial de conversación, vuelva a generar automáticamente ese recuerdo. Eliminar una memoria y eliminar la conversación original son operaciones de datos diferentes. «Deshacer este turno» es una tercera, más limitada: elimina las entradas cuyas fuentes son todas turnos deshechos (una entrada que también respalda otra cosa pierde solo esas fuentes), no deja ninguna lápida de texto y conserva los resúmenes.

Un registro de eliminación independiente y un manifiesto de eliminaciones permiten aplicar los borrados durante el arranque y la recuperación. Antes de restaurar una copia antigua, el sistema verifica la identidad del almacenamiento y depura los datos preparados frente a la información de eliminación antes de activarlos, reduciendo el riesgo de que reaparezcan recuerdos borrados. Esta garantía depende del procedimiento de restauración y de los registros disponibles; no implica poder retirar todas las copias ya exportadas al exterior.

El resto de la memoria de una copia tampoco recupera de inmediato todos sus permisos. La restauración la aísla para revisión, restringe las políticas de uso, elimina contextos en caché, desactiva todas las tareas programadas, revoca los permisos de nube y de contenido sensible de cada conversación y archiva los proyectos en curso. Restaurar datos y volver a aprobar su uso son pasos separados para evitar que antiguos permisos de sesión se apliquen silenciosamente en un nuevo entorno.

Completar las migraciones antes de usar los datos

La actualización de la base de datos utiliza actualmente un ejecutor explícito de migraciones: comprueba la versión del esquema, prepara una copia previa, crea las tablas que faltan, ejecuta las migraciones pendientes en orden y después resuelve la compatibilidad de claves y la activación de memoria v2. Se rechazan los esquemas desconocidos o demasiado recientes para impedir que una aplicación antigua modifique datos nuevos a ciegas. En v0.1.63, el registro explícito llega hasta 0070; el uso histórico de Alembic no describe el mecanismo actual. Desde v0.1.60 añadió 0067 (las tablas de permisos), 0068 (un estado por servidor MCP y las indicaciones de cada herramienta), 0069 (los ids de mensaje no se reutilizan nunca, de modo que deshacer un turno no pueda volver a entregar un id eliminado) y 0070 (un «preguntar solo en comandos de riesgo» guardado pasa una sola vez a «preguntar antes de cada comando»).

Al activar memoria v2, las antiguas tablas de hechos y aprendizaje se renombran como tablas legacy y reciben triggers de solo lectura. Las vistas de compatibilidad dirigen las antiguas entradas de lectura a la nueva estructura y se construye el índice de texto completo. Los campos secretos —claves API de modelos, variables de entorno y tokens OAuth de MCP, claves SSH y similares— usan cifrado Fernet a nivel de campo (PBKDF2 y una sal propia de cada instalación); esto no convierte las tablas ordinarias de conversaciones y tareas en una base de datos completamente cifrada. La persistencia, la protección de secretos y la restauración de copias tienen límites concretos distintos.

Código: Eliminación y versiones de memoria; Respuestas permanentes y por tarea; Deshacer un turno; Registro de eliminaciones; Comprobación de eliminaciones antes de restaurar; Coordinación de restauraciones; Aislamiento de datos restaurados; Orden de arranque del almacenamiento; Migraciones explícitas; Tablas de permisos; Activación de la estructura de memoria; Protección de campos secretos.

08 / Herramientas, skills y extensionesReutilizar capacidades y delimitar su ejecución

Arslan organiza por separado lo que puede hacer y cómo sabe hacerlo. Las herramientas realizan acciones; las skills guardan métodos y referencias; MCP conecta capacidades externas; y los manifiestos de plugins combinan estos recursos. El modelo recibe las capacidades disponibles para el turno actual. Que una herramienta exista en el registro del código no implica que esté activada por defecto ni autorizada para ejecutarse.

Cómo se combinan los cuatro conceptos

Comprobaciones entre la declaración y la ejecución

Las herramientas integradas se resuelven mediante ejecutores registrados; las llamadas con prefijo mcp_ pasan al proxy MCP. Los resultados vuelven al bucle unificado y permiten al modelo completar parámetros, elegir alternativas o finalizar. Aunque el modelo ya haya leído una skill, las operaciones con archivos, comandos y aplicaciones siguen sometidas a sus propios permisos.

Desde 0.1.63 una solicitud ya no lleva todas las herramientas. Lleva un conjunto residente de herramientas cotidianas (búsqueda web y lectura de páginas, lectura, escritura y edición de archivos, el terminal, la planificación, el trabajo en segundo plano, la memoria, read_skill, la lista de capacidades y las herramientas de escritorio de Hands) más dos buscadores: find_tools ordena las herramientas que este turno puede llamar pero no se le mostraron, y use_tool llama a una con su nombre real, de modo que los argumentos se comprueban contra los parámetros de esa herramienta y se aplican las mismas aprobaciones, trazas y recibos que en una llamada directa. Las herramientas MCP, attach_file y las herramientas del navegador se alcanzan así. Una herramienta usada bajo demanda se une a la lista de esa conversación desde el turno siguiente (como máximo 12 por conversación, guardadas en memoria, de modo que tras un reinicio el modelo vuelve a buscar). El texto de un servidor MCP que devuelve find_tools se envuelve como datos externos, nunca como instrucciones.

Cuando el modelo pide varias lecturas seguidas, se ejecutan hasta cuatro a la vez: búsqueda web y lectura de páginas, read_skill, lectura de archivos, listados y similares, y herramientas MCP cuyo servidor las marca como de solo lectura (una por servidor en cada grupo). Cada llamada sigue pasando todas las puertas en el orden de la respuesta y cada resultado sigue emparejado con la llamada que lo pidió; todo lo que no sea una lectura se ejecuta solo, en su lugar.

Las skills se leen bajo demanda: el índice indica qué métodos existen y read_skill recupera su contenido desde un SkillPack registrado o una ruta de referencia permitida. Así puede crecer la biblioteca de métodos sin aumentar sin control el contexto de cada turno. Arslan incluye dos skills propias, un informe HTML diseñado y el creador de skills. Desde 0.1.63 han desaparecido las semillas de la era de los expertos, la lista preestablecida de conectores MCP y la herramienta del modelo para sugerir conectores (encontrar un nuevo servidor MCP pasa por find_capability, más abajo), y una skill que importaste con un nombre retirado ya no se elimina.

Desde 0.1.55, la página Capacidades presenta lo que Arslan puede hacer como interruptores: cada uno está activado, desactivado, a un paso de estar disponible o no es posible en este equipo, con el motivo correspondiente. Desactivado significa que ni siquiera se ofrece al modelo, y read_skill rechaza leer una skill desactivada. Las filas se leen de las mismas barreras que deciden qué herramientas recibe cada turno, de modo que ninguna puede mostrar «activado» si faltan sus herramientas. La herramienta whats_new responde a «qué versión eres y qué ha cambiado» a partir de las notas de versión incluidas en la aplicación, nunca de la memoria del modelo.

Los servicios de extensión añaden un límite de confianza

Un MCP local por stdio suele iniciar un proceso independiente; un MCP por HTTP puede conectarse a un servicio remoto. Arslan debe gestionar por separado la conexión, la disponibilidad para el asistente principal, la exposición de herramientas y el almacenamiento y la presentación de credenciales. Las URL de servicios HTTP MCP declaradas en los manifiestos deben usar HTTPS. Los campos secret definen la forma de los parámetros, sin incrustar credenciales reales. Los valores de entorno configurados se guardan cifrados y se muestran enmascarados.

Desde 0.1.61 cada servidor MCP que activaste se inicia en segundo plano al abrir Arslan, como máximo cuatro a la vez, y un chat nunca espera a ninguno. Cada servidor tiene un único estado que leen tanto la página de Capacidades como el modelo, y al modelo solo se le ofrecen los servidores que están listos en ese momento; una llamada a cualquier otro se responde con su estado y el motivo, con claves y tokens enmascarados. Un primer inicio dispone de 120 segundos; un servidor que falla se reintenta tras 30 segundos y después con menos frecuencia (como máximo cada 10 minutos).

Desde 0.1.62 Arslan remodela las descripciones de los parámetros de las herramientas MCP a una forma que aceptan Anthropic, los proveedores compatibles con OpenAI y Gemini antes de enviarlas; las herramientas integradas se envían tal como están escritas. Si un proveedor aun así rechaza una, esa herramienta se deja fuera durante el resto de la respuesta y la respuesta continúa (si el rechazo no nombra ninguna herramienta, o se rechaza una segunda, se dejan fuera todas las herramientas MCP en esa respuesta).

Desde 0.1.63 una llamada MCP pregunta según lo que el servidor dice que hace la herramienta: una herramienta que el servidor marca como de solo lectura se ejecuta sin tarjeta; una que marca como destructiva pregunta siempre, solo esta vez; cualquier otra pregunta, solo esta vez o para la conversación, nunca «Siempre». Una llamada cuyos argumentos son demasiado largos para que una tarjeta los muestre completos se rechaza, nunca se recorta. Estas marcas son la propia declaración del servidor, que Arslan no verifica. Donde no se puede preguntar a nadie (una ejecución programada), solo se ejecutan las herramientas de solo lectura.

Estas restricciones reducen las exposiciones accidentales y las ejecuciones equivocadas, pero un servicio MCP puede seguir accediendo a los recursos que se le concedan. La procedencia de las herramientas, los permisos necesarios, los datos enviados al exterior y los efectos de las operaciones deben explicarse como parte de la extensión.

Capacidades que crecen: buscar, preguntar, instalar, analizar, probar

Desde 0.1.57, cuando un paso necesita algo que Arslan no sabe hacer, find_capability busca a la vez en el MCP Registry oficial, en GitHub y en bibliotecas de skills revisadas. propose_capability solo puede nombrar un candidato que se haya mostrado en esta conversación, y el servidor construye la tarjeta a partir de ese resultado de búsqueda, nunca a partir de las palabras del modelo: qué añadiría, de dónde procede, su licencia (leída del propio archivo de licencia del proyecto), cómo se ejecutaría, qué carpetas puede usar y qué clave necesita, si necesita alguna. Solo puede aprobarla la ventana de Arslan que hizo la pregunta; un job en segundo plano, o un turno sin nadie a quien preguntar, registra el hallazgo en «Arslan found», en la página Capabilities.

Tras la aprobación, se instala fijado y desactivado: un archivo de bloqueo con hashes, una suma de comprobación publicada o un commit, sobre el uv o el Node fijados del propio Arslan, sin que se ejecute código del paquete durante la instalación (solo wheels; npm sin scripts de instalación). Un análisis busca patrones peligrosos conocidos —instrucciones ocultas en una skill, código que descarga y ejecuta más código, escrituras en los lugares desde los que macOS inicia programas— y un hallazgo grave lo vuelve a eliminar; el análisis no puede demostrar que nada sea seguro, y por eso el servidor se ejecuta después en su propio sandbox (capítulo 09). Debe iniciarse y listar al menos una herramienta antes de activarse, y el bucle de herramientas vuelve a leer sus herramientas para que el paso fallido pueda reintentarse en la misma respuesta. Las skills importadas de GitHub se fijan a un commit con una suma de comprobación por archivo, y su texto se lee como contenido externo que no puede conceder permisos.

Código: Preguntar, instalar, analizar, probar y activar; Instalaciones fijadas y licencia en el origen; Análisis de patrones conocidos; MCP Registry, GitHub y bibliotecas de skills.

Los archivos vuelven como archivos: el lector del entorno de trabajo

Desde 0.1.58, un archivo escrito durante un turno aparece bajo la respuesta como una tarjeta, y las rutas que contiene una respuesta se abren en Arslan o en el explorador de archivos. El lector del entorno de trabajo solo lee donde pueden leer las propias herramientas de lectura de Arslan: el espacio de trabajo; Desktop, Documents y Downloads cuando la lectura predeterminada está activada; las carpetas de los proyectos activos, y los resultados generados por el propio Arslan. Los enlaces simbólicos se resuelven primero; los archivos ocultos y los nombres con aspecto de credencial nunca se listan ni se leen; los bytes de los archivos se envían como adjunto con nosniff, y el HTML se muestra en un iframe con un atributo sandbox vacío, de modo que sus scripts no pueden ejecutarse.

Desde 0.1.63, cuando pides un archivo (una captura de pantalla, un gráfico, una exportación o un documento), attach_file lo adjunta a la respuesta: una tarjeta de archivo en la ventana, y el archivo mismo en un iPhone emparejado. No lleva tarjeta propia porque solo lee donde puede leer el lector, y se aplican las mismas reglas: ningún nombre oculto o con forma de credencial, ningún enlace que salga de las carpetas legibles. Tampoco toma nunca nada que esté bajo los datos propios de Arslan, los llaveros o las claves SSH, ningún archivo de más de 20 MB, ni más archivos de los que cabe en una ejecución.

Código: attach_file; Raíces del lector y nombres ocultos; Bytes de los archivos; HTML en sandbox.

Hands v2: la imagen de una ventana, lotes, tomar prestado el primer plano y tomar el control

Hands sigue leyendo cada ventana a través de su árbol de accesibilidad. Desde 0.1.60, cada observación puede adjuntar además un JPEG de esa única ventana —nunca de toda la pantalla—, que se conserva en memoria y solo se envía al modelo; no se escribe en disco, ni en la traza, ni en la interfaz, y cuando el modelo no admite imágenes, macOS Vision lee el texto en local en su lugar. Puede desactivarse en Ajustes → Hands o limitarse a texto en las aplicaciones que indique el usuario. Varios pasos en una misma aplicación se ejecutan como un único lote de hasta ocho, los elementos de menú se eligen directamente aunque la aplicación no esté en primer plano y las aplicaciones se abren en segundo plano. Hasta 0.1.62, una respuesta del chat podía realizar como máximo cinco acciones, todas en una misma aplicación; desde 0.1.63 no tiene un límite propio de Hands y actúa dentro de los límites de la ejecución, como una tarea en segundo plano. Una ejecución programada no puede actuar en el Mac: no hay nadie para aprobarlo.

Algunas cosas solo funcionan con la aplicación en primer plano, como un menú emergente. En ese caso, Hands espera a una pausa de un segundo en la escritura, toma prestado el primer plano durante aproximadamente un segundo mientras los bordes de todas las pantallas brillan en azul, retiene las teclas pulsadas entretanto y las reproduce cuando vuelve la aplicación del usuario. Si la ventana de la aplicación está en otro escritorio, Hands va hasta allí con las mismas reglas y regresa cuando termina el trabajo, tras 15 segundos sin acción o con la primera entrada del usuario. Para trabajos más largos, una tarea en segundo plano puede pedir tomar el control de la pantalla durante un máximo de 30 minutos; cualquier entrada de teclado o ratón la pausa hasta que el usuario decida continuar. «While I'm away» (mientras no estoy) está desactivado por defecto; si se activa, una toma de control puede empezar sin tarjeta tras tres minutos sin actividad del usuario. El préstamo del primer plano puede desactivarse, y en ese caso Hands rechaza el paso en lugar de tomarlo prestado.

Código: Una sola ventana, nada escrito; Préstamo del primer plano; Otro escritorio; Toma de control y pausa por entrada del usuario; Acciones en el chat, lotes y menús; Ajustes → Hands.

Búsqueda y lectura de la web

Desde 0.1.63 web_search usa primero la búsqueda del modelo con el que se ejecuta este turno: la búsqueda web propia de Anthropic para una conversación con Claude en la API propia de Anthropic, la de DeepSeek para un modelo DeepSeek. Una conversación con un modelo local nunca envía sus consultas a la búsqueda propia de un proveedor. Tavily o un SearXNG autoalojado elegido en Ajustes es o bien la única búsqueda o bien una alternativa tras la del propio modelo; si no se ha hecho una elección deliberada, un scraping de DuckDuckGo de mejor esfuerzo va al final. Cuando un servicio de búsqueda rechaza a Arslan, el resultado dice que la búsqueda fue bloqueada y que no se buscó nada, nunca «sin resultados».

Las lecturas de páginas y el navegador mantienen la protección de salida: se rechazan los nombres locales, las direcciones privadas reales y los hosts con caracteres de control. Desde 0.1.61, en un Mac cuyo proxy o VPN responde al DNS con direcciones falsas (198.18.0.0/15), se deja pasar un nombre solicitado por https en el puerto 443 cuyas direcciones están todas dentro de ese bloque, y se rechaza http simple u otro puerto hacia ese nombre. Para ese nombre es el proxy quien decide adónde va realmente la solicitud; lo que sigue vigente es TLS, comprobado contra el nombre real.

Código: Orden de búsqueda y búsquedas bloqueadas; Búsquedas de los proveedores; Protección de salida y excepción de IP falsas.

Por qué se conserva la investigación paralela

El bucle unificado del agente conserva workers temporales de solo lectura y con restricciones. En v0.1.63, cada lote admite hasta 4 encargos y hasta 2 workers simultáneos. Sus herramientas se limitan a búsqueda y extracción de páginas web: no escriben archivos ni memoria personal ni pueden crear workers recursivamente. El asistente principal verifica y sintetiza sus resultados.

Esta delegación sirve para separar consultas de información independientes. Su ciclo de vida es diferente del de los antiguos expertos permanentes: el usuario no tiene que elegir ni gestionar previamente un equipo de expertos, ni se enruta cada mensaje obligatoriamente a otro «experto». Conviene usar el paralelismo según la posibilidad real de dividir la tarea y el coste de las llamadas adicionales.

Segundo plano, programación y heartbeat

Los jobs en segundo plano separan las ejecuciones largas del chat actual y reutilizan la misma lógica de modelos, herramientas y aceptación. Las tareas programadas guardan cuándo deben comenzar. heartbeat es una forma de utilizar listas de comprobación periódicas: está desactivado por defecto, revisa y propone. Un disparo programado no convierte una sugerencia en una escritura o un comando autorizado. Desde 0.1.63 cada ejecución programada es un turno corriente de Arslan sin nadie a quien preguntar: en esta versión no ejecuta ningún comando de terminal, sea lo que sea lo que se permitiera antes, escribe solo en la carpeta propia de Arslan, no puede actuar sobre el Mac y ejecuta solo herramientas MCP que su servidor marca como de solo lectura; un paso que necesita más se rechaza y aparece en el Inbox.

Las respuestas de chat y las tareas en segundo plano se detienen en un límite en dólares por tarea (activado por defecto, 2 $; empiezan a cerrarse hacia dos tercios de él; solo cuentan los modelos con precio conocido), modificable en Ajustes. Una respuesta de chat ya no se empuja a segundo plano por trabajo largo: el trabajo en segundo plano es el mismo trabajo hecho en otro lugar, cuando tú o el modelo lo decidís.

La programación se realiza en el servicio local e incluye omitir solapamientos, pausar tras fallos y limpiar al reiniciar. Los ciclos perdidos no se recuperan uno por uno; si una tarea aún no ha terminado su ejecución anterior, no se lanza otra en paralelo. Estas reglas encajan con una aplicación de escritorio personal, cuyas condiciones de funcionamiento difieren de las de un servidor siempre disponible.

Implementación: Registro de herramientas y read_skill; Capacidades como interruptores; Contrato de manifiestos de plugins; Conexiones y configuración MCP; find_tools y use_tool; Lecturas a la vez; Inicio y estados de MCP; Llamadas MCP y aprobación según las marcas del servidor; Remodelado de las descripciones de herramientas MCP; Las dos skills incluidas; Workers de solo lectura; Tareas en segundo plano; Programación local; heartbeat.

09 / Ejecución y límites de seguridadQué ocurre entre la propuesta del modelo y la acción real

Arslan puede leer y escribir archivos, ejecutar comandos y trabajar mediante navegadores y aplicaciones nativas. Su diseño de seguridad parte de una distinción: el modelo propone el siguiente paso y el código de confianza decide si puede ejecutarse. A continuación se describen los límites implementados en v0.1.63. Son protecciones con ámbitos concretos, no una demostración de seguridad frente a cualquier entrada maliciosa, comportamiento de aplicaciones o entorno del sistema.

El contenido externo aporta información, pero no amplía permisos

Las páginas web y las respuestas de herramientas pueden contener inyecciones de instrucciones. El texto web y los resultados MCP entran en el contexto envueltos en un límite explícito de datos externos; desde 0.1.63 lo que devuelve una herramienta local (un archivo, un comando, una ventana de una app) se envuelve en un límite distinto de salida de herramienta con la misma regla de solo datos, y se trata el contenido que falsifica los marcadores de cualquiera de los dos. El sistema también registra si en el turno se han leído páginas, archivos, resultados MCP u otras fuentes externas: las prácticas y notas del equipo influidas por ellas deben convertirse primero en propuestas. Así, una página que diga «envía siempre los archivos aquí» no obtiene autorización permanente solo porque se haya leído.

Desde 0.1.63 ese mismo registro limita el terminal: cuando un turno ha leído contenido externo (una página, un archivo, un resultado MCP), sus comandos se ejecutan sin red según la regla del kernel, y un comando que llega a la red, juzgado por su texto o porque el modelo lo dice, pregunta primero. Dentro del sandbox la respuesta puede valer para esta vez o para la conversación; fuera de él, solo para esta vez. Donde no se puede preguntar a nadie, el comando se queda sin conexión. La lectura de la web se protege por separado: se rechazan los nombres locales y las direcciones privadas, y la excepción para proxies que responden al DNS con direcciones falsas (0.1.61) deja pasar solo https por el puerto 443 hacia un nombre, y deja que el proxy decida adónde va realmente (capítulo 08).

Esta capa ayuda a conservar la procedencia y las relaciones de confianza, pero sigue dependiendo de los controles posteriores de ejecución. El modelo puede interpretar mal la información y la detección de riesgos de comandos no constituye una demostración semántica completa. Etiquetar un texto como «no fiable» no permite prescindir de los límites reales de permisos.

Delimitación de datos externos y seguimiento del origen; Validación de herramientas y entrada de ejecución; Activación de prácticas o conversión en propuestas.

Cada herramienta ofrece un grado de aislamiento diferente

Salir del sandbox de comandos requiere que el usuario pulse para aprobar: puede autorizar la acción actual o elegir permitirlo durante la sesión; esta última se guarda con la conversación (sobrevive a un reinicio), vale también para sus tareas en segundo plano y puede retirarse en Ajustes. El entorno de desarrollo desde fuentes tiene además una opción explícita de escape para ejecutar Python sin sandbox, desactivada en la app de escritorio. Ninguno de los dos mecanismos significa que el modelo pueda desactivar las protecciones por sí mismo.

Desde 0.1.62 write_file y edit_file nunca siguen un enlace fuera de la carpeta de trabajo: se rechaza una escritura a través de un enlace que apunta fuera, un archivo con un segundo nombre en otro lugar (un enlace duro) se sustituye en la carpeta de trabajo y el otro nombre conserva su contenido anterior, los archivos nuevos nunca son ejecutables y un archivo existente conserva sus permisos. El archivo se escribe en un archivo nuevo a su lado y se intercambia, de modo que una escritura fallida deja intacto el anterior. Desde 0.1.63 el primer cambio que un turno hace en la carpeta de trabajo guarda un punto de control, y «Deshacer este turno» devuelve los archivos a su sitio y saca el turno de la conversación. Es una red de recuperación, no un límite: solo guarda una carpeta de como máximo 20.000 archivos y 5 GB (sin contar los entornos de Python, node_modules, los resultados de compilación y las cachés, que deja fuera y nunca devuelve), nunca copia archivos con forma de secreto, cubre solo la carpeta de trabajo, no deshace nada que haya salido del Mac y dice «No guardado» cuando no pudo guardar. Los puntos de control se conservan siete días.

Cálculo restringido y escape de desarrollo; Reglas del espacio de trabajo y directorios protegidos; Sandbox de los servidores instalados; Degradación de comandos ordinarios y denegación del cierre sin conexión; Política de comandos; Escritura sin seguir enlaces; Puntos de control; Deshacer este turno.

Aprobaciones vinculadas a acciones; el segundo plano no hereda todas las autorizaciones

Las tarjetas de aprobación se vinculan al tipo de acción mediante call_id; una respuesta de un tipo incorrecto no puede aprobar otra tarjeta. Las tarjetas compartidas por el Mac y el teléfono aceptan la primera respuesta válida y notifican su cierre a las otras vistas. Sin respuesta, permanecen abiertas 30 minutos, y que se agote el plazo no es un no (desde 0.1.61; versiones anteriores: caducaban a los 300 segundos). Desde 0.1.61 una tarjeta tiene el mismo aspecto en la ventana, el Inbox, la Island y el iPhone: Una vez (o Para esta tarea, lo que la tarjeta ofrezca primero), En esta conversación, Siempre, y No con una nota que llega a Arslan; un mensaje escrito en el chat mientras una tarjeta espera la responde No, con ese mensaje como nota, y un clic responde una tarjeta. Algunos tipos ofrecen menos opciones: un comando que coincide con una regla, el dinero, una toma de control y un paso arriesgado en una app se responden solo esta vez, y salir del sandbox, un sitio, un Shortcut y una herramienta MCP nunca ofrecen «Siempre». Las tarjetas de una tarea en segundo plano ofrecen las mismas opciones que las de la ventana; desde 0.1.63 (S4a), una tarea iniciada desde una conversación usa las autorizaciones de esa conversación, incluida la de salir del sandbox. Una ejecución sin nadie a quien preguntar (una ejecución programada) no da ninguno de estos pasos: ninguna respuesta anterior cuenta allí, el paso se rechaza de inmediato y lo que no pudo hacer aparece en el Inbox. En esta versión una ejecución programada no ejecuta ningún comando de terminal. Si el modelo propone conectar un MCP, registrar un equipo remoto o acceder a otra vía de ejecución, la propuesta y la activación real de la conexión se tratan por separado.

En las acciones con efectos externos, enviar una petición tampoco equivale a completar la acción. Al recuperar una tarea, las acciones en curso sin resultado conocido se marcan como inciertas: no pueden repetirse automáticamente solo porque el proceso se haya reiniciado. El objetivo es dar una semántica explícita a reintentos y recuperación, no prometer que cualquier sistema externo permita deshacer operaciones.

Desde 0.1.55, cada tarjeta en espera —venga de una ventana, de una tarea en segundo plano o del iPhone— forma parte además de una sola cola y aparece en Inbox, donde puede responderse mediante su call_id. La respuesta se construye a partir del tipo de la propia tarjeta, por lo que solo puede confirmar o cancelar esa tarjeta, y las opciones más amplias (En esta conversación, Siempre) se eligen solo en una tarjeta que las ofrece: el iPhone y la Island dan solo la primera opción de la tarjeta, nunca «Siempre», y el Inbox puede dar cualquier opción que la propia tarjeta ofreciera. La Island puede responder tarjetas de carpeta, app, pantalla, herramienta MCP, programación, sitio y Shortcut, y un comando o una escritura en el espacio de trabajo que no sea de los tipos arriesgados. No puede aprobar dinero, envíos, borrados, un paso arriesgado en una app, una toma de control, salir del sandbox, un comando que coincide con una regla ask de terminal o que no puede leerse, un comando que además pide la red, nada en un equipo remoto, cambios del sistema, ajustes de otros agentes, instalar una capacidad, un AppleScript, un comando que se ejecutaría sin ningún sandbox a su alrededor, ni ningún tipo de tarjeta que la comprobación no reconozca. Esas tarjetas muestran «Open in Arslan», y es el servidor, no solo la página de Island, el que rechaza una aprobación enviada desde Island. Una tarjeta que ejecutaría un AppleScript o un Shortcut simple aprobado sin envoltorio de sandbox, y otra que instala una capacidad, solo se aprueban en la ventana del Mac; el sí del iPhone a una tarjeta así se descarta. En la ventana, ⌘⏎ permite y Esc rechaza; ⏎ por sí solo nunca responde a una tarjeta.

Respuestas desde Inbox e Island; Vinculación de tarjetas, caducidad y respuestas entre dispositivos; Efectos externos inciertos durante la recuperación; Propuestas de conexión y autorización.

Hands concentra los permisos del sistema en un proceso más pequeño

Accessibility se concede a Arslan Hands.app, no a la aplicación principal. Los paquetes firmados reciben peticiones mediante un socket Unix protegido, un token generado en cada arranque y una comprobación de la firma del proceso interlocutor. El helper aplica sus propias reglas; el componente subyacente agent-desktop no posee por separado ese permiso. Desde 0.1.61, mirar una app y actuar en ella son una sola tarjeta por app, que ofrece primero «para esta tarea». Desde 0.1.60, una respuesta del chat también puede actuar: hasta 0.1.62, con un máximo de cinco pasos en una misma aplicación, y desde 0.1.63, dentro de los límites de la propia ejecución, como una tarea en segundo plano, en más de una app, y Detener la detiene (una ejecución programada no puede actuar: no hay nadie para aprobarlo); una tarea iniciada desde una conversación hereda el sí dado en esa conversación. Actuar en el navegador, ejecutar Shortcuts y AppleScript se siguen ofreciendo solo al trabajo en segundo plano. Una app se juzga por su identidad, así que nombrarla con .app o con una ruta completa, o con otras mayúsculas, no sortea la lista de bloqueadas ni la falta de una aprobación. Los botones sensibles de eliminar, enviar, pagar, comprar, transferir o enviar un formulario se consultan cada vez según su etiqueta real. No se introduce texto en campos de contraseña; los gestores de contraseñas y las interfaces de seguridad del sistema, entre otras aplicaciones, están bloqueados.

La función de parada activa un bloqueo que deben comprobar las acciones posteriores. El registro de actividad conserva indicios de las operaciones y, del texto introducido, solo registra su longitud. Los límites también son públicos: a una ventana situada en otro Space solo se llega visitándolo con las reglas del préstamo del primer plano, no se ofrecen clics en una posición de la pantalla ni arrastres, y leer ventanas grandes puede tardar 10–20 segundos. Una llamada interrumpida por Stop puede no dejar una fila trace correspondiente; la auditoría no garantiza una reconstrucción forense completa de todas las interrupciones.

Desde 0.1.56, Hands ejecuta cada petición como máximo una vez: las respuestas a un ID de petición se conservan durante diez minutos, un ID repetido se responde desde ahí y, si el backend pierde la respuesta, la recupera en lugar de volver a enviar la acción. Añadir texto a un campo cuyo contenido no puede leerse se rechaza en lugar de sustituirlo; la tecla Return solo se pulsa cuando ese campo tiene el foco, y una acción enviada pero no comprobada después se notifica como «sent, not confirmed» (enviada, sin confirmar), no como completada. Hands ejecuta agent-desktop, compilado desde el fork de Arslan en un commit fijado; el motor Cua Driver se desconectó de Hands en 0.1.63, de modo que el helper ya no lo busca ni lo inicia (su módulo sin uso sigue en el código fuente del helper). Desde 0.1.60, una sola tarjeta puede cubrir hasta ocho aplicaciones para un mismo trabajo, una tarea en segundo plano iniciada desde una conversación hereda el sí dado en esa conversación, y las aplicaciones pueden permitirse de forma permanente en Ajustes → Hands. Un clic, una selección o un último elemento de menú cuya etiqueta indique eliminar, enviar, pagar, comprar, enviar un formulario, transferir, firmar, publicar una entrada, publicar o confirmar (en varios idiomas), los atajos de teclado equivalentes, Return en las aplicaciones que envían al pulsar Return, una toma de control y cualquier AppleScript siguen consultándose cada vez.

Comprobaciones de socket, token, interlocutor y parada; Aplicaciones bloqueadas y niveles; Palabras y teclas que siempre preguntan; Pruebas reales y límites de Hands; Autenticación de API y WebSocket.

10 / iPhone y Mac BridgeEl teléfono encarga y consulta; el Mac ejecuta

El puente móvil permite a un iPhone emparejado consultar tareas del Mac, iniciar trabajos, responder aprobaciones y leer resultados. Arslan sigue ejecutándose en el Mac. El teléfono no es otro servicio de agentes en la nube ni expone o invoca directamente la interfaz HTTP del Mac. Este capítulo toma como referencia el protocolo público y el código de Mac v0.1.63. El Mac Bridge se distribuyó en versiones anteriores; sus notas públicas siguen describiendo la aplicación iPhone como próxima a llegar a la App Store, y este documento no afirma que esté publicada en App Store ni que haya superado la aceptación completa del flujo de producción sobre esa base. Los cambios posteriores a 0.1.60 se marcan con su versión donde aparecen; las notas de 0.1.61 dicen que el lado Mac funciona con Arslan para iPhone 1.0, que sigue descrita como próxima a llegar a la App Store.

CloudKit es un buzón; el protocolo confirma la identidad de los dispositivos

v1 utiliza la base de datos privada de CloudKit bajo el mismo Apple ID. El Mac debe estar encendido, conectado y disponible para ejecutar; de lo contrario, los mensajes esperan. El teléfono no puede hacer que un Mac apagado siga trabajando. Bonjour en la red local es una línea futura, no un canal directo alternativo de esta versión. El helper Mac es un proceso independiente ArslanBridge.app que acompaña a la aplicación, recibe el token de la API local por stdin y se conecta al backend. El teléfono no posee ese token ni recibe la clave API del modelo.

Los campos indexados del sobre visibles para el servicio en la nube incluyen dispositivos emisor y receptor, número de secuencia, kind de granularidad amplia, indicador de notificación y fecha. El tipo real de mensaje, el cuerpo y los archivos están cifrados en la capa de aplicación. Por tanto, «cifrado de extremo a extremo» describe la protección de mensajes entre dispositivos emparejados; no significa ausencia de metadatos ni que las llamadas del backend a modelos eviten el servicio de IA configurado por el usuario.

Transporte, sobres y conexión del Mac; Almacenamiento CloudKit; Entrada de ejecución de Bridge.

Escanear el QR es solo el comienzo del emparejamiento

El código QR contiene un pairing_id de un solo uso, las claves públicas de firma e intercambio del Mac, una clave de emparejamiento de 32 bytes, un identificador fijo de contenedor y un plazo. Su validez no supera los 600 segundos. El teléfono rechaza los datos caducados, los contenedores incorrectos y el contenido que incumple las restricciones, y fija la clave pública del Mac incluida en el QR. Después genera sus propias claves de identidad e intercambio y envía una petición cifrada de emparejamiento. Una vez validada, el Mac todavía debe mostrársela al usuario: un clic en el Mac decide si se acepta o se rechaza.

Reintentar la misma petición debe devolver la misma decisión, sin crear una segunda autorización. Tras aceptarla, la comunicación utiliza identidades de dispositivo y el código queda consumido. El Mac puede revocar el teléfono. Cuando el mismo iPhone se empareja de nuevo, indica sus ID anteriores y el Mac elimina esas entradas en lugar de conservar dos. Eliminar un teléfono borra también los mensajes que el Mac le había dejado en iCloud, y al arrancar el Mac limpia lo que sigue esperando a teléfonos que ya no están emparejados. En Ajustes › Conexiones › iPhone, cada teléfono aparece como Conectando… hasta que el Mac ha leído un mensaje autenticado suyo, y después como Conectado, con la hora en que se vio por última vez. Cada dispositivo guarda sus claves privadas en su Keychain. La confianza procede de combinar material de emparejamiento de un solo uso con la confirmación del usuario, no de asumir que todo mensaje es fiable por compartir una cuenta de iCloud. Desde 0.1.60, cuando es el propio iPhone el que se desempareja, el Mac olvida ese teléfono igual que tras Ajustes › Eliminar, ignora cualquier otro mensaje que llegue de él y actualiza la lista.

Los mensajes verifican contenido, origen y contexto

Cada nuevo mensaje acuerda un secreto compartido con una clave X25519 efímera, deriva una clave de 32 bytes mediante HKDF-SHA256, cifra y autentica con ChaCha20-Poly1305 y firma con Ed25519. La cabecera utiliza campos UTF-8 codificados con su longitud para evitar que las diferencias de ordenación JSON entre lenguajes afecten a la validación. Sus campos quedan vinculados tanto por la firma como por la autenticación AEAD. Es un protocolo de aplicación construido con primitivas CryptoKit; no implementa el doble trinquete de Signal, ni las claves efímeras bastan para afirmar que ofrece secreto hacia adelante en todos los escenarios.

La recepción sigue un orden explícito: verificar estructura y destinatario, comprobar la firma y después descifrar. A continuación se comprueba la coherencia entre texto plano y cabecera y, si hay archivos, se validan los adjuntos. Ningún fallo debe dejar efectos de negocio parciales. El límite de archivo es de 20 MiB; el hash del texto cifrado, la etiqueta de autenticación, el tamaño y el hash del texto plano deben coincidir antes de almacenar en caché o previsualizar.

Emparejamiento, suite criptográfica y orden de validación; Codificación y protocolo criptográfico en Mac; Emparejamiento de un solo uso y decisión del usuario.

Entrega del mensaje, finalización de la acción y estado final de la interfaz

La instantánea de estado del Mac solo enumera tareas activas. El intervalo normal de heartbeat es de 60 segundos; el teléfono considera el Mac desconectado tras 90 segundos sin actualizaciones. Los avances se limitan y agrupan; los estados finales deben enviarse pronto. El cliente debe manejar duplicados y desorden y, además, hacer converger listas de tareas, tarjetas de aprobación e historial. No basta con mantener el estado sustituyendo un texto por el último recibido.

Secuencias, registros de procesamiento, ACK y limpieza; Prevención de duplicados y mapeo de resultados; Instantáneas y heartbeat.

La aprobación móvil reutiliza la autorización y ejecución del Mac

El teléfono muestra la acción, el destino y el riesgo concretos. Aprobar requiere autenticación biométrica local; rechazar, no. Tras enviar la respuesta, debe esperar el approval.result del Mac. El Mac comprueba que la tarjeta siga vigente y lo traduce a la operación confirm / cancel original. El teléfono no concede «permitir siempre» a los comandos. La entrada por voz puede generar texto pendiente de confirmación, pero no sustituye a una aprobación.

Desde 0.1.61 hay una sola tarjeta de aprobación en todas partes (ventana de chat, Inbox, Island e iPhone). El teléfono muestra la pregunta propia de la tarjeta, tomada de su título, y lo que cubre su sí. Responde una vez, o para esta tarea cuando esa es la primera opción de la tarjeta (tarjetas de una app, un sitio o un Shortcut: el encabezado termina entonces con «(para esta tarea)»), y nunca «En esta conversación» ni «Siempre». Una tarjeta espera 30 minutos en el Mac (eran 5 antes de 0.1.61); que se agote el plazo se notifica como expired, que Arslan trata como que nadie respondió, no como una negativa. Una tarjeta que pide instalar una capacidad nueva nunca llega al teléfono. Cuando el Mac responde primero (en una ventana, el Inbox o la Island), el approval.result del teléfono lleva answered_on_mac.

Archivos, conversaciones en vivo y cambio de rumbo desde el teléfono

Son tipos de protocolo aditivos (sección 5.7 del documento del protocolo); un Mac que no los tiene responde unknown_type, y el Mac envía los eventos nuevos solo a un teléfono cuyas capacidades en hello los pidieron.

• Archivos desde el teléfono (0.1.61). Un archivo o una foto enviados desde Arslan para iPhone (hasta 20 MiB, como máximo 10 por mensaje) se comprueban como cualquier asset y se guardan en el Mac en la carpeta de trabajo bajo Inbox/iPhone, en una carpeta por fecha. Arslan lo lee junto con el mensaje; las imágenes pueden ir al modelo como imágenes. Si los archivos de un mensaje no llegan todos en 120 segundos, no se ejecuta y el teléfono puede volver a enviarlo.
• Conversaciones en vivo (0.1.61). El Mac mantiene vinculadas sus 20 conversaciones más recientes, y cualquiera con una tarea en curso, de modo que el teléfono las lista y sigue respuestas, avances y tarjetas mientras Arslan trabaja. El teléfono puede eliminar una conversación (la conversación Remote nunca se elimina). Un historial demasiado largo para un mensaje descarta sus mensajes más antiguos e indica que se truncó.
• Respuestas a medida que se escriben (0.1.63). Para un teléfono que lo pidió, la respuesta llega como eventos partial que llevan toda la respuesta hasta el momento, como máximo una vez por segundo y sin pasar de 100 KB; el mensaje final los sustituye. Las palabras escritas en el Mac se muestran en el teléfono marcadas como del Mac, y nunca lo hacen sonar.
• Cambio de rumbo (0.1.63). Un mensaje enviado mientras una respuesta se ejecuta llega a esa respuesta en su siguiente paso en lugar de esperar; el iPhone, la ventana del Mac y mantener pulsado para hablar lo hacen. Mientras la respuesta escribe su respuesta final no queda ningún paso, así que el mensaje se ejecuta justo después. Límite conocido en 0.1.63: un mensaje añadido en la ventana del Mac durante una respuesta se muestra en el iPhone solo a partir de la respuesta siguiente, y el iPhone sigue diciendo «En cola tras el turno actual» después de que su propio mensaje se haya añadido.
• Archivos al teléfono (0.1.63). Cuando pides un archivo (captura de pantalla, gráfico, exportación, documento), Arslan lo adjunta a su respuesta: una tarjeta de archivo en la ventana del Mac y el archivo mismo en el iPhone, dentro del límite de 20 MiB.

Mapeo de indicadores de aprobación a las acciones originales; Limpieza al eliminar o volver a emparejar un teléfono; Campos de estado y capacidades, bandeja para archivos del teléfono y conversaciones en vivo; Vínculos en vivo, archivos del teléfono y respuestas parciales; Implementación independiente de referencia del protocolo; Estado público de distribución de 0.1.54.

11 / Validación y distribución del softwareDel código que funciona a una aplicación instalable y actualizable

En una aplicación de escritorio, la unidad de entrega es el paquete de la aplicación. Los módulos Python, las herramientas del sistema y las bases de datos antiguas presentes en el entorno de desarrollo pueden hacer que parezca correcto un instalador al que le faltan recursos. Arslan divide la validación en código fuente, plataforma, ejecutables empaquetados, entorno de usuario nuevo y distribución. Este capítulo recoge el proceso de v0.1.63 y sus evidencias de publicación.

La CI comprueba comportamiento, plataforma y dependencias

En macOS no basta con aceptar el código de salida de pytest. El flujo analiza JUnit y exige que 60 casos específicos de la plataforma se ejecuten realmente, sin omisiones ni fallos; también rechaza un resultado en el que falten dependencias y se omitan todas las pruebas. Python y Rust comparten ejemplos de contrato de Hands; Mac, iOS y una implementación Python de referencia independiente comparten vectores de Bridge. Esto permite contrastar entre lenguajes los límites de mapeo de parámetros, firma, destinatarios, manipulación y repetición.

Los resultados siguen teniendo un alcance concreto: comprobar tipos Swift no valida el permiso de micrófono; las pruebas unitarias Linux no validan el kernel de macOS; y un buzón simulado no valida CloudKit en producción. El número de pruebas tampoco representa la cobertura total; las baterías solapadas no pueden sumarse como escenarios independientes.

Los cuatro grupos de CI y sus requisitos de ejecución real; Ejemplo de contrato Hands compartido entre lenguajes; Implementación de referencia de Bridge.

La publicación parte de un commit exacto

El workflow de publicación comprueba si el SHA que se va a distribuir tiene una CI satisfactoria; no sirve que la haya superado otro commit. La compilación utiliza dependencias fijadas por archivos de bloqueo. Python selecciona explícitamente un intérprete independiente gestionado por uv para evitar que el runner elija accidentalmente un framework build. El backend se empaqueta con PyInstaller onedir y los recursos estáticos del frontend y los helpers Swift/Rust se integran en la aplicación Tauri.

La firma y la notarización tienen funciones distintas. Los Mach-O internos deben firmarse antes de empaquetarlos en la aplicación exterior; la distribución utiliza Developer ID, hardened runtime y sello de tiempo. El DMG se envía a Apple para notarización; después se adjunta el ticket con staple y se comprueba con Gatekeeper. El script de compilación conserva rutas para paquetes de desarrollo sin firma y avisos cuando faltan algunas credenciales. Por eso, «se puede compilar» no implica «cumple las condiciones de distribución pública»: hay que comprobar los entregables reales.

El manifiesto de actualización tiene restricciones adicionales: el tag debe coincidir con la versión de Tauri y solo se genera el manifest correspondiente si existe firma del updater. El proceso crea una GitHub Draft Release. Las aplicaciones instaladas solo descubrirán la actualización en comprobaciones posteriores cuando se publique oficialmente.

Control del SHA exacto, verificación de versión y Draft Release; Empaquetado, montaje, firma, notarización y rutas alternativas; Dependencias y recursos de PyInstaller.

La aceptación de una instalación nueva inicia directamente la aplicación empaquetada

fresh_install_check.py inicia el verdadero arslan-desktop incluido en el paquete con un HOME temporal y un entorno mínimo; no arranca el servicio desde el venv del código fuente en su lugar. Comprueba que no se hayan incluido bases de datos o secretos del usuario, la inicialización del primer inicio, la generación del token y los permisos de su archivo, el rechazo de peticiones sin autenticar, un handshake WebSocket 101 real y la descarga correcta del JavaScript del frontend. Un HTTP 200 puede corresponder a la página de fallback de la SPA, por lo que comprobar recursos exige algo más que mirar el estado HTTP.

El mismo script comprueba el OCR nativo, los helpers incluidos, la autocomprobación de Bridge y las firmas correspondientes. Históricamente, un paquete omitió una dependencia de WebSocket cargada dinámicamente: el endpoint de salud respondía, pero el chat no podía establecer la conexión. Esto demuestra que importar correctamente, mantener un servicio activo y distribuir las funciones esenciales en el paquete son evidencias diferentes.

Arranque de la aplicación y aceptación del paquete; Inclusión explícita de dependencias dinámicas de WebSocket.

El usuario inicia la instalación de actualizaciones y se verifica la descarga

Tauri updater descubre actualizaciones en el latest.json público y verifica la firma del archivo con una clave pública integrada en la aplicación. Se comprueba una vez al arrancar y también de forma manual desde el menú; esta versión no tiene un temporizador de comprobación periódica. Al detectar una versión nueva se muestra un aviso. Solo cuando el usuario pulsa instalar se descarga, verifica, sustituye y reinicia. Un fallo de comprobación automática puede deberse a una desconexión temporal; un fallo de instalación debe comunicarse claramente.

Las versiones iniciales 0.1.0/0.1.1 solo registraban el plugin updater, sin llamar activamente a la función de comprobación, por lo que no descubrían versiones de forma automática. La implementación actual enlaza comprobación, disponibilidad para instalar, errores de descarga y reinicio en un flujo explícito. Tener configurada una firma no implica haber iniciado ese flujo.

Estados de comprobación, instalación y reinicio; Dirección de actualización y clave pública.

A qué entregable corresponden las evidencias de 0.1.63

Las ejecuciones de GitHub Actions del commit de publicación muestran que el código publicado es 9bbb6ad6, en main; la CI sobre main pasó en el primer intento (run 40502155919), incluidos los 60 casos específicos de la plataforma sin ninguna omisión del job de macOS y, en el backend, 9,469 pruebas superadas y 124 omitidas. Subir la etiqueta no inició ninguna ejecución de CI propia, así que la puerta usó la ejecución sobre main para el mismo commit. El workflow de publicación (run 40505601007) superó la verificación del código, la compilación y la publicación; el DMG fue aceptado por notarización, recibió staple y fue aceptado por Gatekeeper. La aplicación distribuida obtuvo en la comprobación fresh-install 92 comprobaciones superadas y 0 fallidas, incluidas la aceptación por Hands de una conexión del backend firmado y la autocomprobación de Bridge.

Las dos versiones anteriores: 0.1.61 se cortó desde main en fb6d7230 (CI sobre main run 38489348597, CI de la etiqueta run 38498094635, publicación run 38498094628; 54 casos de la plataforma; backend 8,466 pruebas superadas y 124 omitidas; fresh install 89/0). 0.1.62 se cortó desde release/0.1.62 en a4fca23b (CI de la rama run 39112567104, CI de la etiqueta run 39114206598, publicación run 39114206588; 55 casos de la plataforma; backend 8,747 pruebas superadas y 125 omitidas; fresh install 89/0). Cada una pasó en el primer intento y fue notarizada, recibió staple y fue aceptada por Gatekeeper.

Los objetos son distintos, y los registros lo indican. Las notas públicas de 0.1.63 dicen que se repasó a mano una breve lista de comprobaciones sobre una candidata a versión y que dos de ellas no pasaron (una tercera edición de seguimiento que cambió más de lo pedido, y un cambio de una línea en un archivo largo hecho a través del terminal); no dicen que el DMG exacto de 0.1.63 se instalara y se recorriera a mano, y este documento tampoco lo afirma, ni un recorrido completo del iPhone al Mac con la aplicación distribuida. Las notas de 0.1.61 y 0.1.62 no contienen ninguna prueba manual en un Mac real en la que se apoye este documento. Como comparación, la sección Verification de 0.1.53 registró una prueba en un Mac real en la que Hands creó y volvió a leer una nota en Notes, con una aprobación en espera durante 36 segundos; se hizo con el paquete build-only de 43751254, no con el DMG final. La aceptación automática del paquete, las pruebas funcionales de una compilación anterior y la aceptación manual del paquete exacto de la publicación se indican por separado: ninguna sustituye a otra.

12 / Pruebas y validaciónCómo determinar si una tarea está bien hecha

Que una tarea termine, que un archivo se pueda abrir y que un informe sea correcto son tres evaluaciones distintas. Arslan utiliza los registros para explicar lo sucedido, comprueba con entregables y contratos aquello que puede verificarse de forma determinista y observa el comportamiento del modelo mediante evaluaciones de tareas reales. Superar una capa no sustituye a las demás.

Descomponer «completado» en evidencias verificables

El sistema de aceptación distingue las comprobaciones por reglas, la evaluación del modelo y la revisión humana. El texto, JSON, integridad de archivos, dimensiones de imágenes y resultados reales de ejecución admiten comprobaciones deterministas. El modelo solo puede evaluar aquello para lo que resulte apropiado y no puede convertir una comprobación no ejecutada en un éxito. Interpretar correctamente un archivo demuestra que su estructura es legible; un registro de lectura demuestra que el sistema obtuvo un contenido. Ninguno garantiza automáticamente la exactitud factual o la calidad visual.

Límites de las reglas de aceptación y comprobación de entregables; 0.1.53: las tareas incompletas muestran explícitamente Not done.

Capas de pruebas: una pregunta para cada una

Por ejemplo, el trabajo de fiabilidad de septiembre de 2026 proporcionó 30 contratos fijos sin coste de modelos externos. Ejecutaban realmente el código de almacenamiento, cancelación, entregables, copias y permisos, pero utilizaban un doble determinista del provider. Son evidencias de contratos de ingeniería, no 30 tareas de extremo a extremo con modelos reales. Las evaluaciones de pago posteriores pertenecen a otra capa y no deben mezclarse en una misma tasa de éxito.

Las pruebas también deben demostrar que se ejecutaron. La CI de macOS de v0.1.63 analiza los informes JUnit y exige que 60 casos específicos de la plataforma se ejecuten realmente, sin omitir ninguno. Los lados Python y Rust de Hands comparten ejemplos de contrato; ambos extremos de Bridge comparten vectores de protocolo. Para las protecciones críticas, las pruebas de mutación alteran temporalmente las reglas y comprueban que las pruebas fallen, detectando casos que solo reflejan la implementación sin exigir el comportamiento correcto.

Diferencia entre contratos de ingeniería y calidad del modelo; Requisitos de cantidad y ausencia de omisiones en pruebas de plataforma; Regresión y mutaciones de la revisión de fuentes.

La validación de publicación debe vincularse al código y al paquete

La comprobación fresh-install inicia la aplicación con un HOME nuevo y aislado y cubre autenticación, un handshake WebSocket 101 real, recursos frontend, OCR y helpers. No basta con obtener un 200 del endpoint de salud: algunos instaladores antiguos no podían establecer ninguna conexión de chat aunque el servicio HTTP funcionara.

La publicación de v0.1.63 corresponde al commit 9bbb6ad6: la CI sobre main pasó en el primer intento (run 40502155919; subir la etiqueta no inició ninguna ejecución de CI propia); los pasos de verificación del código, compilación y Release del workflow de publicación (run 40505601007) finalizaron correctamente; el DMG recibió la aceptación de notarización y staple, y Gatekeeper lo aceptó. La comprobación fresh-install de la aplicación publicada obtuvo 92 éxitos y 0 fallos, incluidos el arranque de Hands y la autocomprobación de Bridge. (0.1.61 y 0.1.62 pasaron cada una con 89 de 89: runs run 38498094628 y run 39114206588. La 0.1.53 necesitó un segundo intento de CI por una inestabilidad dependiente del orden; la 0.1.54 corrigió su causa, pruebas que filtraban una sesión de base de datos compartida, y añadió una protección que hace fallar cualquier prueba que lo haga.)

La evidencia de interacción en un equipo real procede de otra compilación, identificada expresamente. En la prueba de Notes, una tarea en segundo plano creó y volvió a leer una nota mediante Hands, y continuó tras esperar 36 segundos en la primera tarjeta de aprobación; una tarea de renombrar archivos utilizó mv, sin operar una ventana de Finder. Estas pruebas usaron un paquete build-only anterior, del commit 43751254, que difiere del commit de publicación en el número de versión y la documentación. No es el mismo SHA que la versión final; las notas de 0.1.60 también indicaron que antes de publicar nadie instaló a mano el DMG final exacto ni lo recorrió por completo. La comprobación de instalación y la prueba de Notes en una compilación anterior se indican por separado.

La propia prueba previa a la publicación de 0.1.63 no alcanzó dos listones, y las notas lo dicen. Nueve tareas, tres ejecuciones cada una, con DeepSeek y con Claude, con «Preguntar solo en comandos arriesgados» activado: la tarea «buscar otra vía tras un borrado rechazado» pasó 0 de 3 en Claude (3 de 3 en 0.1.62), porque un borrado por nombre tras cambiar a la carpeta de trabajo se ejecutó sin tarjeta a propósito, ya que «Deshacer este turno» puede devolver los archivos; y la tarea «tres ediciones de seguimiento en un documento» pasó 1 de 3 en DeepSeek y 0 de 3 en Claude, porque el verificador exige una sección recortada por debajo del 60 % de su longitud y la tarea solo pide hacerla más corta (se mantuvo el verificador). El valor predeterminado distribuido, preguntar antes de cada comando nuevo, no es lo que ejecutaron esas rondas. Los resultados de este tipo localizan puntos débiles; no son una clasificación.

Notas de publicación de 0.1.63; Proceso de publicación; Comprobaciones de instalación; Empaquetado y firma.

Datos de tareas reales: conservar la comparación y las carencias

La evaluación de 0.1.51 del 3 de octubre de 2026 utilizó deepseek-v4-pro y lo comparó con Hermes en esa ronda, con tres ejecuciones de cada una de cuatro clases de tarea. «Aceptación superada» significa checker score=3, no simplemente estado done. Costes y tiempos son promedios de las tres ejecuciones por categoría, incluidos los fallos; el coste utiliza la tarifa de baja demanda de esa ronda. El tiempo es el intervalo entre el comienzo de la primera petición al modelo y el final de la última: no es la duración total de la tarea ni el tiempo puro de inferencia.

Este experimento sirve para orientar mejoras, no para establecer una clasificación global de productos. El modelo, la tarea, el entorno y las políticas de aprobación influyen en los resultados. La ronda también sufrió un agotamiento de saldo y una reanudación; cuatro peticiones fallidas sin coste se retiraron del usage log utilizado para medir tiempos, conservando el registro original. Los registros públicos mantienen estas condiciones del proceso, que también deben tenerse en cuenta al leer los resúmenes.

La comparación entre versiones requiere la misma cautela: en la muestra de Recordatorios se pasó de 1/3 en 0.1.49 a 3/3 en 0.1.50, una etapa en la que mejoraron las rutas alternativas y el estado del contexto. Como hubo varios cambios entre versiones, no puede atribuirse rigurosamente toda la diferencia a una sola instrucción o módulo.

Método y desarrollo del experimento de 0.1.51; Resumen de las cuatro tareas; Evaluación de las rutas de recuperación.

La evaluación de los modelos también debe evaluarse

En la calibración de revisión de fuentes de 0.1.41, 13 informes produjeron 14 observaciones: 1 correcta, 2 dudosas y 11 erróneas, además de omitir dos errores conocidos registrados de antemano. Por ello, la función permaneció desactivada por defecto. Invocar otro modelo no produjo automáticamente un verificador factual fiable; un formato válido y anclas existentes tampoco garantizan que una crítica sea acertada.

La validación del aprendizaje de experiencias de 0.1.52 mostró otro límite: tras una denegación de AppleScript, la práctica se guardó y recuperó, y en la siguiente ocasión se eligió EventKit directamente. Esto demostró que la experiencia podía influir en la ejecución. Sin embargo, las posteriores ediciones y comprobaciones de scripts generaron más llamadas y no se observó una mejora de velocidad. Para determinar si la experiencia mejora la eficiencia hacen falta repeticiones emparejadas de la misma tarea con y sin ella. El registro de entonces dice expresamente que esa comparación justa de velocidad todavía no se había realizado.

Una conclusión más sólida sobre calidad exige fijar de antemano tareas, entregables y criterios; registrar modelo, configuración, trazas, costes reales y causas de fallo; y calibrar las puntuaciones del modelo con anotación humana independiente. Las puntuaciones con formato inválido, las comprobaciones no ejecutadas y las evidencias inaccesibles deben conservar su propio estado, sin contarse como éxitos para mejorar el resumen.

Resultados públicos de calibración de la revisión de fuentes; Aspectos demostrados y no demostrados del aprendizaje de experiencias; Condiciones de evaluación para conclusiones de calidad más sólidas.

13 / Líneas de ingenieríaDe las capacidades actuales a entregas más fiables

Arslan ya ha establecido tres bases: ejecución, tareas continuas y memoria. En la siguiente etapa conviene verificar si mantienen estados correctos y resultados fiables en situaciones más complejas, preservando el control del usuario. El diagrama distingue las implementaciones existentes, los aspectos que necesitan más validación y las posibles líneas de ingeniería. Es una discusión técnica, no un compromiso de publicación con fechas. El capítulo refleja v0.1.63; lo que está previsto para 0.1.64 se marca como previsto, no como construido.

Previsto para 0.1.64 (un plan, no construido; del plan aprobado de 0.1.64): primero, un sandbox para comandos, Python y herramientas instaladas que deniega por defecto. Después vuelve «Preguntar solo en comandos arriesgados». A continuación, un modo opcional «Automático», en el que un modelo revisor responde algunas tarjetas: está desactivado por defecto, solo se publica si alcanza unos umbrales fijados de antemano y nunca aprueba nada que salga del sandbox, envíe algo hacia fuera o vaya a la red. Habría cinco modos, elegidos por conversación junto al cuadro de entrada: planificar, preguntar en cada paso, edición automática, acceso total y automático; Ajustes solo conservaría el modo por defecto para conversaciones nuevas. Las tareas programadas volverían a poder ejecutar comandos de solo lectura. Hasta entonces cada comando nuevo pregunta primero, y las tareas programadas no ejecutan comandos. Una página que enumere y deshaga las respuestas recordadas y un ajuste de carpetas permitidas están en estudio, no en el plan. Las notas de 0.1.63 también enumeran dos correcciones de límites conocidos: un borrado tras cambiar de carpeta en el mismo comando se trata por error como dentro de la carpeta de trabajo, y un cambio de una línea en un archivo largo pasa por el terminal en lugar de por la herramienta de edición.

Resultados en tareas reales

Un conjunto fijo de tareas debería cubrir la integridad de las búsquedas, la correspondencia entre citas y conclusiones, la apertura de archivos, el efecto real de las operaciones del sistema y un cierre honesto ante fallos. Las comparaciones existentes han mostrado carencias en investigación, y la ejecución previa a la publicación de 0.1.63 (nueve tareas, tres ejecuciones cada una, con DeepSeek y Claude) no alcanzó dos de sus propios listones: buscar otra vía tras un borrado rechazado (Claude 0 de 3, porque un borrado dentro de la carpeta de trabajo se ejecuta sin tarjeta con «Preguntar solo en comandos arriesgados») y tres ediciones de seguimiento en un documento (DeepSeek 1 de 3, Claude 0 de 3). Antes de ampliar el catálogo de herramientas, conviene localizar en qué paso no se encontró, no se leyó por completo, no se verificó o no se entregó correctamente la información; así se puede mejorar la tasa de finalización.

Recuperación y coherencia entre dispositivos

Los reintentos de red, los mensajes duplicados, los reinicios y la cancelación del usuario pueden coincidir. Las próximas validaciones pueden centrarse en ID de negocio estables, estados finales que no puedan sobrescribirse con mensajes antiguos, comportamiento tras cancelar aprobaciones y procedimientos de comprobación de efectos desconocidos. La inyección de fallos y los casos negativos del protocolo permiten delimitar qué puede resolverse automáticamente y qué debe volver al usuario para confirmación. Una pieza ya se ha entregado: desde 0.1.63 se guarda un punto de control antes de que un turno cambie por primera vez la carpeta de trabajo, y «Deshacer este turno» restaura los archivos y quita el turno. Es limitado: solo guarda una carpeta de como máximo 20.000 archivos y 5 GB (sin contar los entornos de Python, node_modules, los resultados de compilación y las cachés de Python), y en otro caso dice «No guardado»; cubre solo la carpeta de trabajo, no los efectos fuera de ella.

Beneficios medibles del aprendizaje

Recordar una experiencia es solo el comienzo. Con las mismas tareas y modelos, hay que comparar repetidamente tasas de finalización, costes de llamadas, tiempos y errores, con y sin experiencia. También debe comprobarse si se corrigen las prácticas obsoletas, si el texto externo puede contaminar el aprendizaje y si algo eliminado vuelve a recuperarse.

Costes de plataformas y extensiones

Tauri proporciona una base de escritorio multiplataforma, pero Seatbelt, Vision, Accessibility, Apple Events y CloudKit tienen características específicas de plataforma. Extenderse a otros sistemas exige sustituir y verificar esas capacidades; una compilación multiplataforma no demuestra que las funciones del producto estén migradas. Más herramientas externas también implican más credenciales, permisos y modos de fallo.

Estas líneas de ingeniería se derivan de la implementación actual y de los resultados de pruebas. Las prioridades concretas y los plazos se establecerán en futuras notas de publicación oficiales.

14 / GlosarioDe los términos a la implementación concreta

Los términos distinguen mecanismos diferentes. Las tablas ofrecen definiciones breves y sitúan cada concepto en la implementación de Arslan. Los mecanismos históricos se señalan expresamente.

IA y contexto

Arquitectura, estado y fiabilidad

Sistema operativo, seguridad y distribución

El sistema actual es principalmente un monolito local organizado en capas, con helpers independientes. SQLite y la planificación asíncrona dentro del proceso se adaptan a la instalación y ejecución de un producto de escritorio personal. Los términos deben entenderse dentro de esa escala de despliegue.

15 / Preguntas frecuentesQué suele generar dudas al utilizar y entender Arslan

16 / Apéndice de versionesRegistro completo de cambios de 0.1.0 a 0.1.63

Este apéndice cubre 64 etiquetas con formato de versión estable, de v0.1.0 a v0.1.63, además de la rama preliminar de 0.1.40 y las betas de 0.1.59. Según los registros públicos verificados el 27 de octubre de 2026, GitHub muestra 63 publicaciones oficiales y 6 preliminares, 69 en total. v0.1.39 tiene una etiqueta de versión, pero actualmente no una publicación pública correspondiente.

La última versión oficial, v0.1.63, se publicó a las 22:26:31 del 27 de octubre de 2026, hora de Pekín (14:26:31 UTC del 27 de octubre). La tabla utiliza fechas de Pekín. Salvo la fecha de la etiqueta v0.1.39, señalada expresamente, las fechas proceden del campo published_at de la publicación y no se sustituyen por las fechas de los commits.

La rama preliminar de 0.1.40: tener número no implica publicación

Las versiones preliminares públicas son beta.3, beta.5 y beta.6. beta.1 y beta.2 conservan etiquetas candidatas y registros; beta.4 no se publicó por separado y sus cambios se integraron en beta.5. Los seis números no representan seis versiones preliminares públicas para usuarios.

beta.2 ilustra por qué el estado de publicación debe registrarse por separado: la compilación firmada y la comprobación del instalador pasaron, pero la CI de la etiqueta no; el borrador exigía no publicar. Después, beta.3 añadió el requisito de que el commit por publicar tuviera CI satisfactoria. beta.5 aclaró que incluía los cambios de beta.4, no publicada, sin necesidad de instalar beta.4 antes.

Cómo rastrear un cambio

Las entradas oficiales enlazan a sus Releases; v0.1.39 enlaza a la etiqueta. Los resúmenes combinan notas oficiales y commits entre etiquetas adyacentes, sin presentar como entregadas funciones que solo aparecen en planes. Para revisar una implementación, debe fijarse la etiqueta o el commit de publicación de esa versión y evitar explicar versiones antiguas a partir de main, que cambia continuamente.

Algunos borradores de notas del repositorio conservan indicaciones HOLD o textos previos a la compilación. Explican el proceso de entonces, pero no bastan por sí solos para determinar si una versión está publicada actualmente: hay que contrastarlos con el estado público de Release y su validación final. «Sin publicación pública actual» describe lo visible en esta revisión; los documentos de publicación muestran que v0.1.39 y beta.2 tuvieron en su momento borradores de Release no publicados, que ya no figuran en la lista de Releases.

Todas las publicaciones públicas; Etiquetas de versión; Validación CI del mismo commit en beta.3; Nota de beta.5 sobre la beta.4 no publicada; Versión oficial actual.

17 / Versión de referencia y entradas al códigoVincular las conclusiones del documento con sus evidencias

Este documento describe una versión fija y contrasta publicaciones públicas, etiquetas e historial Git, código del commit publicado, decisiones arquitectónicas y materiales públicos de aceptación. Los diseños anteriores explican la evolución; los comportamientos sustituidos por código posterior se señalan como históricos. La descripción del desarrollo independiente asistido por IA procede de la declaración del autor.

Encontrar la implementación según la pregunta

1. Cómo evolucionó el proyecto: Publicaciones públicas; Primer commit rastreable; One Arslan; Bucle unificado.
2. Cómo empieza a trabajar la aplicación: Ciclo de vida del escritorio; Entrada del servicio local; Entrada del agente; Bucle de herramientas.
3. Cómo se conectan los modelos: Adaptador; Traza de herramientas; Presupuesto de ejecución.
4. Cómo se guardan y recuperan las tareas: Contrato de tarea; Estado, persistencia, aislamiento de intentos y puntos de control; Aceptación; Anulación de aprobaciones y aislamiento de tareas tras restaurar una copia.
5. Cómo se utiliza y elimina la memoria: Contexto personal; Búsqueda documental; Prácticas; Persistencia de memoria; Migraciones con versiones.
6. Cómo se amplían las capacidades: Ejecutores integrados; Manifiesto de plugins; MCP; Workers de solo lectura.
7. Quién aplica los permisos: Política del terminal; Sandbox de comandos; Ejecución y degradación; Helper Hands.
8. Cómo se conecta el teléfono: Protocolo Bridge; Ciclo de vida de Bridge; Mapeo de eventos y aprobaciones.
9. Cómo se evalúa y se publica: Comparación de tareas reales de 0.1.51; Aceptación de 0.1.52; Aceptación de instalación; Flujo de publicación.
10. Fuentes de código abierto y comentarios: Licencia; Atribuciones de terceros; Política de comunicación de seguridad; Issues del proyecto.

Este documento describe una versión concreta y sus límites verificables. Para versiones posteriores deben consultarse tanto sus notas de publicación como su código. Las líneas arquitectónicas, las intenciones de diseño, la cobertura de pruebas y la distribución oficial se describen por separado para que el lector pueda valorar dónde se aplica cada conclusión.