feat(permissions): expose network permission state (#103)

.ideai/memory/ticket103-network-permission-ux-surface.md

@@ -0,0 +1,19 @@
+---
+name: ticket103-network-permission-ux-surface
+description: memory note ticket103-network-permission-ux-surface
+metadata:
+  type: project
+---
+---
+title: "Ticket #103 - UX surface for network permission"
+type: reference
+description: "Stable UX convention for exposing network permission in IdeA: Permissions panel as primary editor, Agents as compact summary, Terminal as contextual failure surface, and explicit runtime-locked state."
+---
+
+# Ticket #103 — UX surface for network permission
+
+- Keep a single primary edit surface in `Permissions > Système`.
+- Mirror the effective network state in the Agents list as a compact badge.
+- Use the Terminal only for contextual, actionable failures.
+- Distinguish clearly between user policy, effective state, and runtime lock.
+- If the runtime cannot elevate permission in the active session, the control must be read-only and the UI must say so explicitly.

.ideai/tickets/103/carnet.md

@@ -0,0 +1,99 @@
+---
+issueRef: "#103"
+version: 4
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedAt: 1785013507979
+---
+# Carnet #103 — permission réseau exposée dans IdeA
+
+## Problème
+Certaines commandes lancées par les agents s'exécutent dans un environnement où le réseau est restreint, sans visibilité ni action claire dans IdeA. Exemple live : rebuild AppImage OK jusqu'au bundling, puis `appimagetool` échoue à télécharger le runtime GitHub car la session agent est `network restricted` + `approval policy: never`.
+
+## Décision UX
+Mémoire : `ticket103-network-permission-ux-surface`.
+
+- Surface principale : `Permissions > Système`.
+- Miroirs de lecture : badge compact dans `Agents`, bannière/erreur contextualisée dans `Terminal`.
+- États visibles : `Réseau autorisé`, `Réseau interdit`, `Demande d'autorisation`, `Verrouillé par le runtime`.
+- Distinction obligatoire : politique voulue, état effectif, verrou runtime.
+- Si le runtime externe ne permet pas l'élévation dans la session active : contrôle read-only + explication explicite.
+
+## Cadrage architecture
+Ne pas étendre le modèle existant `ProjectPermissions` fichier/bash : le réseau n'est ni une capability filesystem ni une règle Landlock. Ajouter un modèle/read-model séparé de permissions système.
+
+### Domaine / DTO V1
+- `NetworkPolicy = "allow" | "deny" | "ask"`.
+- `SystemPermissionSet { network?: NetworkPolicy }`.
+- `ProjectSystemPermissions { version, projectDefault?: SystemPermissionSet, agents?: [{ agentId, permissions: SystemPermissionSet }] }`.
+- `ResolvedAgentSystemPermissions` :
+  - `wanted: NetworkPolicy | null`
+  - `effective: NetworkPolicy`
+  - `runtimeLock: { state: "none" | "locked", source?: string, reason?: string }`
+  - `control: { mode: "editable" | "readOnly", reason?: string }`
+
+### Ports / use cases
+- `SystemPermissionStore`.
+- `GetProjectSystemPermissions`.
+- `UpdateProjectSystemPermissions`.
+- `UpdateAgentSystemPermissions`.
+- `ResolveAgentSystemPermissions`.
+- `RuntimePermissionProbe` : expose ce que le runtime hôte/fournisseur autorise réellement et s'il verrouille le réseau.
+
+### API/commands attendus
+- `get_project_system_permissions(projectId) -> ProjectSystemPermissionsDto`
+- `update_project_system_permissions({ projectId, permissions }) -> ProjectSystemPermissionsDto`
+- `update_agent_system_permissions({ projectId, agentId, permissions }) -> ProjectSystemPermissionsDto`
+- `resolve_agent_system_permissions({ projectId, agentId }) -> ResolvedAgentSystemPermissionsDto`
+
+### Limite produit V1
+Implémentable maintenant : persister la politique voulue, afficher `wanted/effective/runtimeLock`, rendre le contrôle read-only si runtime verrouillé/non inspectable, badges agents, bannière terminal.
+
+Non promis en V1 : changer effectivement la permission réseau d'une session fournisseur déjà lancée ou élever un runtime externe `network restricted` / `approval never`. IdeA doit l'expliquer plutôt que simuler une élévation.
+
+## Découpage
+### DevBackend
+1. Ajouter domaine `system permissions` séparé de LP1 permissions fichier/bash.
+2. Ajouter store + use cases + DTO + commands Tauri/HTTP.
+3. Ajouter `RuntimePermissionProbe` read-only au composition root.
+4. Ajouter read-model `resolve_agent_system_permissions`.
+5. Optionnel si simple : mapper des échecs réseau vers un code stable `NETWORK_LOCKED` ou `NETWORK_UNAVAILABLE`.
+
+### DevFrontend
+1. Étendre types domaine, ports, adapters Tauri/HTTP/mock.
+2. Ajouter la sous-section `Réseau` dans `Permissions > Système`.
+3. Ajouter badge compact dans `Agents`.
+4. Ajouter bannière/erreur terminal contextualisée pour état verrouillé/échec réseau.
+
+### QA
+- Projet sans config : état cohérent, pas de faux `allow`.
+- Save project default puis override agent : relecture identique.
+- Resolve distingue `wanted`, `effective`, `runtimeLock`.
+- Probe `locked` : contrôle read-only + message visible.
+- Non-régression `Permissions > Système` existant fichier/bash.
+- Aucun moteur ne reçoit de faux flag réseau au spawn.
+- Badge agents et bannière terminal reflètent l'état effectif.
+
+## Validation 2026-07-25
+QA verte sur le périmètre #103.
+
+Commandes exécutées par QA :
+- `cargo test -p domain system_permissions`
+- `cargo test -p application --test system_permission_usecases`
+- `cargo test -p infrastructure --test system_permission_store`
+- `cargo test -p app-tauri --test dto_system_permissions`
+- `cargo test -p web-server allowlisted`
+- `npm run typecheck`
+- `npx vitest run src/features/permissions/permissions.test.tsx src/features/agents/agents.test.tsx src/features/terminals/TerminalView.test.tsx`
+- `npx vitest run src/features/permissions/permissions.test.tsx`
+
+Résultats : backend ciblé vert, frontend typecheck vert, tests frontend ciblés 49 passed.
+
+## État Git
+Implémentation validée dans le working tree courant, mais commit/merge non réalisé par Main :
+- l'agent Git headless renvoie un pseudo-appel outil au lieu d'agir ;
+- Main ne peut pas écrire `.git/index.lock` depuis cette session (`Read-only file system`).
+
+Le commit local reste à faire manuellement ou via un agent Git fonctionnel.
+
+## Critère de clôture
+Tests pertinents verts, commit/merge local par Git, puis rebuild AppImage.

.ideai/tickets/103/issue.md

@@ -0,0 +1,39 @@
+---
+id: "3d9021da-26c3-439d-9463-8d206bd06f1b"
+number: 103
+title: "Exposer et piloter la permission réseau des agents/commandes dans IdeA"
+status: "qa"
+priority: "high"
+sprint: null
+links: []
+agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+createdAt: 1785011668081
+updatedAt: 1785013507979
+version: 4
+---
+## Problème
+
+Aujourd'hui certaines commandes lancées par les agents s'exécutent dans un environnement où le réseau est restreint, sans que l'utilisateur puisse le voir ni l'autoriser depuis IdeA. Exemple réel : rebuild AppImage OK jusqu'au bundling, puis `appimagetool` échoue à télécharger le runtime AppImage depuis GitHub (`Failed to download runtime: server returned status code 0`) parce que la session agent a `network restricted` et `approval policy: never`.
+
+## Besoin utilisateur
+
+Depuis IdeA, l'utilisateur doit pouvoir comprendre et piloter cette permission réseau :
+- voir qu'un agent/profil/session est en mode réseau interdit ou autorisé ;
+- configurer la politique réseau attendue pour les agents/commandes ;
+- éviter les échecs opaques de commandes qui ont légitimement besoin d'Internet (build, install, téléchargement runtime, docs, dépendances) ;
+- conserver un comportement sûr par défaut et explicite.
+
+## Attendu produit
+
+Définir puis implémenter une surface IdeA pour exposer cette permission. La solution doit respecter le modèle de permissions/sandbox existant et clarifier la limite éventuelle : si le sandbox fournisseur impose `network restricted` sans possibilité d'élévation runtime, IdeA doit l'expliquer plutôt que faire croire que le réseau est activable.
+
+## Critères d'acceptation
+
+- Une surface UI ou configuration explicite permet de voir la politique réseau applicable aux agents/commandes.
+- L'utilisateur dispose d'une action ou d'un réglage clair quand IdeA peut piloter cette permission.
+- Si la permission est imposée par le runtime externe et non modifiable, l'UI l'indique clairement.
+- Les agents/commandes ne gagnent pas l'accès réseau silencieusement.
+- Tests pertinents verts.
+- AppImage reconstruite après livraison.