For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /es/docs/desktop/first-feature.md (or send Accept: text/markdown).
Construye tu primera funcionalidad
Un recorrido de extremo a extremo desde un cambio nativo del shell hasta una ventana verificada.
Guía paso a paso para principiantes
Requisitos previos: lea las dos guías para principiantes a continuación, termine la configuración local de Desktop y abra este repositorio en su raíz en su editor. El shell lee SUPASTACK_APP_URL como configuración de terminal cuando inicia, no desde un archivo .env guardado.
Términos breves: un espacio de trabajo son los usuarios, datos y configuraciones separados de un equipo. El servidor es el backend confiable; Mantenga las claves del proveedor fuera del código del navegador y del teléfono. Una migración es un cambio de base de datos versionada que crea o actualiza tablas. Un modelo de IA es el motor que responde; el catálogo de modelos es la lista del servidor de ID de modelos disponibles y precios. Un proveedor es un servicio externo, como inteligencia artificial, correo electrónico o servicio de facturación. Un derecho es una concesión que permite que un espacio de trabajo utilice una función. Un webhook es un mensaje que un servicio envía al URL de otro servicio.
1. Abra .agents/skills/add-a-desktop-capability/SKILL.md —o pida a su agente de codificación que lo siga— y haga un pequeño cambio nativo, por ejemplo una nueva entrada del menú Ver o un atajo de invocación diferente.
2. Ejecute cargo check, inicie el shell y ejercite el cambio en la ventana abierta.
3. Repita en cada sistema operativo que planee distribuir: el comportamiento de bandeja, atajo y menú difiere por plataforma.
Para código personalizado, nombre el comportamiento, el menú o atajo que afecta y qué debería suceder en cada SO. Dé a su agente de codificación esta tarea y pídale que lea AGENTS.md, .ai/PROJECT_CONTEXT.md y los espejos .ai/ de los archivos que tocará; que enumere archivos y verificaciones antes de editar; y que le muestre el diff. Use valores de ejemplo; nunca pegue un secreto real.
Decidir primero si es nativo o producto
Todo lo que un usuario experimenta como UI de producto —pantallas, datos, configuración— pertenece a la aplicación web y llega a la ventana automáticamente. Solo el comportamiento a nivel de SO pertenece a Rust: ventanas, bandeja, menús, atajos globales, inicio al iniciar sesión y comprobaciones de actualización.
apps/desktop/src-tauri/src/lib.rs
apps/desktop/src-tauri/tauri.conf.json
apps/desktop/src-tauri/capabilities/default.jsonMantener ajustada la sandbox de la webview
La webview solo puede llamar a lo que capabilities/default.json enumera. Un cambio que necesita un nuevo plugin agrega el crate en Cargo.toml, lo registra en lib.rs y otorga el permiso mínimo en capabilities, nunca un comodín.
El estado persistente del shell —posición de la ventana, zoom, canal de actualización, preferencias de ventana— vive en el directorio de datos de la aplicación a través de los sidecars incluidos, no en archivos que usted gestiona a mano.
Verificar en cada SO de destino
Ejecute cargo test, luego una ventana real en Windows, macOS y Linux: restauración del estado de la ventana, cierre a bandeja, enfoque de instancia única y el atajo de invocación con su cambio activo. Un SO que pasa no prueba los otros dos.