IdeA/.ideai/tickets/103/carnet.md

issueRef, version, updatedBy, updatedAt

issueRef	version	updatedBy	updatedAt
#103	4	kind agent_id agent a6ced819-b893-4213-b003-9e9dc79b9641	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.