104 lines
3 KiB
Markdown
104 lines
3 KiB
Markdown
# Use cases
|
||
|
||
## todo
|
||
|
||
- le 1/ n'est pas fini, il y a des règlages à faire, j'ai eu des résultats bizarres
|
||
- le 2/ n'est pas commencé
|
||
- le 3/ on verra après
|
||
|
||
## Use case 1
|
||
|
||
!!! example "Use case 1"
|
||
je veux récupérer une liste de path de variable qui a tel rôle
|
||
|
||
1/ "je veux récupérer une liste de path de variable qui a tel rôle + la compréhension de cette variable"
|
||
|
||
et aussi des explications (ce qu'elle a compris de telle ou telle partie de la conf
|
||
par exemple les explications du mode manuel.
|
||
|
||
|
||
exemple: comme le test avec la conf HTTPS.
|
||
|
||
Ce use case est presque fait, à part le fait que ce n'est pas la peine
|
||
de configurer la persona comme un storage, car il se pose des questions
|
||
byzarres ensuite.
|
||
|
||
Ce qu'on veut s'est récupérer les paths des variables
|
||
(pour ensuite les passer a une interface mais c'est un autre use case).
|
||
|
||
|
||
!!! important "Persona"
|
||
**A mettre dans la persona**
|
||
|
||
On considère comme étant une variable non seulement les variables mais
|
||
les familles aussi.
|
||
|
||
Rougail-ai rend compte des sous-groupes.
|
||
Sans la notion de famille, mais Rougail-ai explique spontanément
|
||
les variables à renseigner si tu enclenches le mode manuel par exemple.
|
||
|
||
Il faudrait deux possibilités : les paths oui, pas seulement les nom court.
|
||
|
||
Les deux en fait, les noms longs et les noms courts.
|
||
|
||
Mais les noms longs sont plus importants, parce que si on a le path on a tout le contexte derrière.
|
||
|
||
faire des tests :
|
||
|
||
- lorsque ça retourne une variable
|
||
- lorsque ça retourne une variable qui est une famille en fait
|
||
|
||
|
||
## Use Case 2
|
||
|
||
Ce 2eme usecase c'est
|
||
|
||
!!! example "Use case 2"
|
||
j'aimerais que tu m'explique ma conf
|
||
tiens tu peux m'expliquer comment est configuré le proxy chez moi ?
|
||
|
||
(Sachant qu'il ne faut même pas expliquer à rougail-ai que **c'est** une conf...)
|
||
|
||
2/ "je veux comprendre ma configuration actuelle :
|
||
ça retourne une explication textuelle + une liste de path des variables concernées"
|
||
|
||
En sortie, pour l'instant, on veut juste du texte.
|
||
On veut que rougail-ai nous explique textuellement
|
||
|
||
- la nature de la "conf"
|
||
- la liste des variables qui sont concernées
|
||
|
||
**pour le moment rougail-ai retourne la liste des path qui sont concernés**
|
||
|
||
!!! note "Rappel"
|
||
|
||
on veut que rougail-ai ne fasse rien d'opérationnel,
|
||
on veut qu'elle délègue à rougail dès qu'il y a une opération à calculer.
|
||
|
||
Mais cela c'est un autre use case.
|
||
|
||
---
|
||
|
||
**étapes ultérieures**
|
||
|
||
## Use Case 3
|
||
|
||
3/ "suggère moi une configuration permettant d'arriver à ce resultat
|
||
et il retourne une liste de path + valeur"
|
||
|
||
Rougail-ai peut décider d'ouvrir des widgets genre formulaires.
|
||
|
||
Là on est dans le "generated app".
|
||
|
||
!!! example "Exemple"
|
||
|
||
"ok ton proxy est configuré mais pas le HTTPS pour le moment si tu veux configurer le HTTPS tien voilà la liste des variables"
|
||
|
||
Au niveau de la génération des widgets, c'est déplacé dans un autre projet pour l'instant:
|
||
|
||
- l'ia lance des widgets un peu comme le faisait [zenity](https://forge.cloud.silique.fr/gremond/baklava/src/branch/main/doc/Zenity1.md)
|
||
(sur gnome)
|
||
|
||
|
||
|
||
|