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 /it/docs/desktop/first-feature.md (or send Accept: text/markdown).
Costruisci la tua prima feature
Un percorso end-to-end da una modifica nativa della shell a una finestra verificata.
Procedura dettagliata per principianti
Prerequisiti: leggi le due guide per principianti qui sotto, completa la configurazione locale Desktop e apri questo repository alla sua radice nel tuo editor. La shell legge SUPASTACK_APP_URL come impostazione del terminale all'avvio — non da un file .env salvato.
Termini rapidi: uno spazio di lavoro è costituito da utenti, dati e impostazioni separati di un team. Il server è il backend affidabile; mantenere le chiavi del provider fuori dal browser e dal codice del telefono. Una migrazione è una modifica del database con versione che crea o aggiorna tabelle. Un modello AI è il motore che risponde; il catalogo dei modelli è l'elenco del server degli ID e dei prezzi dei modelli disponibili. Un fornitore è un servizio esterno come un servizio di intelligenza artificiale, posta elettronica o fatturazione. Un diritto è una concessione che consente a un'area di lavoro di utilizzare una funzionalità. Un webhook è un messaggio che un servizio invia allo URL di un altro servizio.
1. Apri .agents/skills/add-a-desktop-capability/SKILL.md — o chiedi al tuo agente di codifica di seguirlo — e fai una piccola modifica nativa, ad esempio una nuova voce del menu Visualizza o una scorciatoia di richiamo diversa.
2. Esegui cargo check, avvia la shell ed esercita la modifica nella finestra aperta.
3. Ripeti su ogni sistema operativo che intendi distribuire — il comportamento di tray, scorciatoia e menu differisce per piattaforma.
Per codice personalizzato, nomina il comportamento, il menu o la scorciatoia che influisce e cosa dovrebbe succedere su ogni SO. Dai al tuo agente di codifica questo compito e chiedigli di leggere AGENTS.md, .ai/PROJECT_CONTEXT.md e gli specchi .ai/ dei file che toccherà; di elencare file e controlli prima di modificare; e di mostrarti il diff. Usa valori di esempio; non incollare mai un segreto reale.
Decidere prima nativo o prodotto
Qualsiasi cosa un utente viva come UI di prodotto — schermate, dati, impostazioni — appartiene all'app web e arriva automaticamente nella finestra. Solo il comportamento a livello SO appartiene a Rust: finestre, tray, menu, scorciatoie globali, avvio all'accesso e controlli degli aggiornamenti.
apps/desktop/src-tauri/src/lib.rs
apps/desktop/src-tauri/tauri.conf.json
apps/desktop/src-tauri/capabilities/default.jsonMantenere stretta la sandbox della webview
La webview può chiamare solo ciò che capabilities/default.json elenca. Una modifica che richiede un nuovo plugin aggiunge il crate in Cargo.toml, lo registra in lib.rs e concede il permesso minimo nelle capabilities — mai un wildcard.
Lo stato persistente della shell — posizione della finestra, zoom, canale di aggiornamento, preferenze della finestra — vive nella directory dei dati dell'app tramite i sidecar inclusi, non in file che gestisci a mano.
Verificare su ogni SO di destinazione
Esegui cargo test, poi una finestra reale su Windows, macOS e Linux: ripristino dello stato della finestra, chiusura nel tray, focus dell'istanza singola e la scorciatoia di richiamo con la tua modifica attiva. Un SO che passa non dimostra gli altri due.