blomios/IdeA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6bd5e64dd1a12ff5e4269fa16af3201d7072d16a
IdeA/.ideai/tickets/103/issue.md
Blomios 5955ea37a2 chore(tickets): synchronise l'état ticketing courant 
Met à jour les carnets/issues existants et ajoute les tickets #108,
#109, #111, #112 créés durant le cycle. État runtime sans rapport
avec le lot de code #82, isolé dans son propre commit.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-29 15:57:37 +02:00

2.2 KiB
Raw Blame History

id, number, title, status, priority, sprint, links, agentRefs, createdBy, updatedBy, createdAt, updatedAt, version
id number title status priority sprint links agentRefs createdBy updatedBy createdAt updatedAt version
3d9021da-26c3-439d-9463-8d206bd06f1b 103 Exposer et piloter la permission réseau des agents/commandes dans IdeA closed high null
agentId role
a6ced819-b893-4213-b003-9e9dc79b9641 assigned
kind agent_id
agent a6ced819-b893-4213-b003-9e9dc79b9641
kind
user
1785011668081 1785271085635 5

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.