---
issueRef: "#103"
version: 5
updatedBy: {"kind":"user"}
updatedAt: 1785271085635
---
# 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.