99 lines
5.2 KiB
Markdown
99 lines
5.2 KiB
Markdown
---
|
|
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. |