db6685cb55
## Problem
Closing a project tab only hid it in that window. The backend workspace
record kept routing the folder's events, notifications, auto-accept and
pending-request recovery, invisibly, until the palette-only **Stop
Workspace** command was run on the active tab. That command still showed
the V1 message "Stop OpenCode instance? This will stop the server."
although V2 has one shared OpenCode service, and it called
`debug.location.evict`, which (per OpenCode source) rejects pending
permissions, cancels pending Forms, fails plugin RPC and kills terminals
of that directory, even for sessions started elsewhere. OpenCode loads
locations on demand and unloads idle ones itself.
## Change
- **Closing a project tab** (×, Ctrl/Cmd+W) removes that tab's backend
workspace record. CodeNomad stops following it; sessions keep running in
OpenCode and reappear when the project is reopened.
- **Another tab of the same folder** has its own record and is
unaffected.
- **The same record shown in another window**: that window's tab closes
through the existing `workspace.stopped` broadcast, with an info
notification ("closed from another window"); the initiating window shows
nothing.
- **CodeNomad never evicts OpenCode locations**: eviction, its
serialization helpers and `locationOwned` bookkeeping are removed. A
failed launch now always removes its logical record (the retention only
existed to retry a failed eviction).
- **Stop Workspace removed** (command, confirm dialog, i18n keys in all
locales).
- Unchanged: opening an open project still offers a new tab (recent row)
or switching (switch button); temporary projects keep Keep / Discard /
Cancel; window close, app quit, reload, restore and backend shutdown
delete nothing; disconnected-instance dismissal stays local.
- Delete failure: error toast, record kept and reachable from the home
page, no automatic retry.
## Docs
Help in all 10 locales (`projects`, `index`, `desktop`, `server`,
`opencode`, `missions`), `AGENTS.md`, `CONTRIBUTING.md`,
`dev-docs/architecture.md`, `packages/server/README.md` and the
architecture-guide skill now describe the new contract.
## Validation
- UI store tests (`--conditions=browser`): app-tabs,
temporary-instances, workspace-list-reconciliation-fence,
instances-restore-ownership — 30/30.
- Server: manager + shared service 54/54; event ownership and workspace
identity suites pass.
- New real-component browser regression (click ×, Ctrl+W, Cmd+W): 3/3;
project restoration (Electron/Tauri) and new-instance launcher browser
suites pass.
- `npm run test:help` 9/9 (250 pages); UI, server and Electron
typechecks.
8.2 KiB
Aide CodeNomad
Ce guide explique comment utiliser l’espace de travail CodeNomad actuel, sur ordinateur ou dans un navigateur, avec votre service OpenCode. Il porte sur les commandes de CodeNomad, les limites d’exécution et la récupération, et non sur la configuration d’OpenCode ou un historique des versions.
À lire en premier
CodeNomad relie votre espace de travail à un service OpenCode partagé en arrière-plan. Les sessions et les messages appartiennent à OpenCode ; les onglets, brouillons de saisie et dispositions appartiennent au client CodeNomad. Fermer un onglet de projet ferme le projet dans CodeNomad ; les sessions continuent dans OpenCode et se retrouvent en rouvrant le projet. Fermer CodeNomad n’arrête pas OpenCode.
- Vérifiez les prérequis de l’hôte et la configuration d’OpenCode.
- Ouvrez un projet, puis choisissez les réglages Agent, Modèle et Réflexion de la conversation.
- Vérifiez la portée concernée avant de modifier des identifiants, de redémarrer un service ou de supprimer l’historique. D’autres clients peuvent utiliser le même service natif.
Le site d’aide public fonctionne sans CodeNomad, son backend ni connexion. Aide → Aide de CodeNomad sur ordinateur et Ouvrir l’aide dans la palette de commandes l’ouvrent séparément dans la langue actuelle de l’interface. Changer de langue ne traduit pas les conversations enregistrées.
Paramètres ouvre la fenêtre native Préférences dans un client de bureau local ; les clients navigateur et distants utilisent les paramètres intégrés. Les chemins tels que Paramètres → Fournisseurs désignent la même section dans les deux interfaces.
Pour un espace de travail autonome dans un navigateur sur un hôte préparé, le guide du serveur explique cette commande et ses exigences d’authentification/TLS :
npx @neuralnomads/codenomad --generate-token --launch
Choisir son client
| Fonctionnalité | Bureau local | Navigateur direct ou fenêtre de serveur distant | Appareil appairé au Contrôle à distance |
|---|---|---|---|
| Projets, conversations, fichiers et historique | Dossiers du backend et sessions natives | Dossiers et sessions du serveur connecté | Surfaces autorisées de l’espace de travail de l’hôte |
| Préférences natives et fenêtres de bureau | Disponibles | Les paramètres navigateur/distants restent dans le client | Commandes réservées au bureau hôte indisponibles |
| Aperçu navigateur de session | Natif dans Electron et Tauri Windows ; iframe sur les autres plateformes Tauri | Iframe si disponible | Points d’accès d’aperçu réservés à l’hôte indisponibles |
| Automatisation native du bureau/navigateur | Fenêtres/aperçus locaux détenus | Ne remplace pas l’automatisation native du bureau | Points d’accès d’automatisation réservés à l’hôte indisponibles |
| Authentification | Initialisation locale ou session par mot de passe | Session par mot de passe du serveur | Identifiant d’appareil appairé |
| Installation PWA | Utiliser l’application native ou un navigateur | Selon le navigateur ; contexte sécurisé requis | Selon le navigateur ; appairage toujours requis |
Pour les limites précises, consultez aperçus navigateur et SideCars, Contrôle à distance et mobile/PWA. Une fenêtre distante ne transforme pas le système de fichiers de votre appareil en espace de travail du serveur.
Savoir à qui appartient l’état
| Terme | Sens dans CodeNomad |
|---|---|
| Onglet de projet / espace de travail / instance | Connexion CodeNomad à un dossier explicitement ouvert ; plusieurs onglets peuvent utiliser le service partagé. |
| Conversation / session | Historique et exécution natifs OpenCode associés à leur répertoire. |
| Famille | Conversation et ses sous-sessions récursives ; intervient dans les déplacements, l’activité, Yolo et les commandes des Missions. |
| Worktree | Copie de travail détenue d’un dépôt, sélectionnée pour la navigation ou l’emplacement des sessions. La parcourir ne déplace pas une conversation. |
| Location | Contexte d’exécution natif OpenCode propre à un répertoire ; fermer un onglet de projet ferme uniquement le projet dans CodeNomad, sans décharger la Location native. |
| Backend CodeNomad | Serveur fournissant l’espace de travail, Git, l’authentification et la connectivité des clients. Son compte et son environnement déterminent l’accès au système de fichiers du backend. |
| Configuration | Paramètres CodeNomad dans le répertoire de configuration du serveur ; les paramètres OpenCode Global/Projet ont leur propre portée native. |
| Fenêtre | Ses propres onglets, navigation, brouillons et vue restaurée. L’historique natif est partagé, pas copié pour chaque fenêtre. |
| Profil de données de bureau | Sélection explicite du stockage natif/client ; n’isole pas automatiquement les sessions OpenCode ni toute la configuration partagée. |
La racine de l’espace de travail limite les dossiers que CodeNomad ouvre ; ce n’est pas un bac à sable pour l’agent. Consultez la sécurité avant d’exposer un hôte ou d’autoriser un accès étendu aux outils.
Explorer par tâche
| Tâche | Guide |
|---|---|
| Installer ou servir l’espace de travail | Installation, Référence serveur, Réseau et TLS |
| Travailler avec plusieurs copies de travail et conversations | Projets, Conversations, Fichiers |
| Rechercher dans l’historique ou le nettoyer sans risque | Historique |
| Répondre aux questions et autorisations natives | Autorisations |
| Coordonner un travail délimité ou quotidien | Missions |
| Configurer l’exécution et les intégrations | OpenCode, Fournisseurs, Intégrations |
| Connecter un autre appareil | Contrôle à distance, Sécurité, Mobile |
| Adapter l’espace de travail | Paramètres, Raccourcis, Voix, Extensions |
| Gérer l’application native | Bureau, Aperçus navigateur et SideCars, Mises à jour |
| Diagnostiquer ou contribuer | Dépannage, Assistance et compilation depuis les sources |
Surveiller le travail sans le modifier
Le panneau Statut expose l’utilisation du fournisseur de la session active et les Shells natifs en arrière-plan. Le statut des conversations et l’activité des enfants indiquent les sessions actives, en compactage ou en attente de saisie. Surveiller un Shell en arrière-plan est distinct de l’envoi d’une demande Shell depuis la zone de saisie ou de l’utilisation d’un SideCar terminal hébergé séparément.
- Ouvrez Statut → Shells en arrière-plan pour la Location de la conversation sélectionnée (ou l’espace de travail ouvert si aucune conversation n’est sélectionnée).
- Consultez la commande, le shell, le répertoire, le statut, le PID et le code de sortie lorsqu’ils sont fournis ; choisissez Afficher la sortie pour voir la sortie native disponible.
- Pour en retirer un, utilisez Arrêter et supprimer pendant son exécution, ou Supprimer après sa sortie, et confirmez la cible.
Supprimer un Shell en cours arrête ce processus ; fermer sa fenêtre de sortie ne l’arrête pas. L’actualisation ou la reconnexion lit l’état natif actuel au lieu de reconstruire les événements de sortie manqués.
Les instantanés d’affichage s’actualisent après les changements natifs, la reconnexion et à la demande des vues visibles. Ce ne sont pas des journaux de rejeu garantis. Si un résultat est incertain, actualisez l’état faisant autorité avant de réessayer une modification ; ne renvoyez pas la demande simplement parce qu’une notification ou un événement a été manqué.