refactoring the command
All checks were successful
Dotnet build and test / build (pull_request) Successful in 8m54s
All checks were successful
Dotnet build and test / build (pull_request) Successful in 8m54s
This commit is contained in:
parent
fc820362b9
commit
6b4e52e7ce
15 changed files with 459 additions and 188 deletions
101
doc/agent-playbook.md
Normal file
101
doc/agent-playbook.md
Normal file
|
|
@ -0,0 +1,101 @@
|
|||
# Playbook d'usage des agents IA (Yavsc)
|
||||
|
||||
Ce playbook normalise l'usage de Copilot, Plan et Explore dans le depot.
|
||||
Il privilegie des sorties verifiables: fichiers, commandes tests, risques.
|
||||
|
||||
## Quand utiliser quel agent
|
||||
|
||||
- Plan: quand la tache est ambigue, transverse ou risquee.
|
||||
- Explore: quand il faut cartographier rapidement des zones du code.
|
||||
- Copilot: quand les specifications sont claires et localisees.
|
||||
|
||||
## Prompt type (base)
|
||||
|
||||
Utiliser ce squelette avant toute tache non triviale:
|
||||
|
||||
```text
|
||||
Contexte: <projet/fichier/fonction>
|
||||
Objectif: <resultat observable>
|
||||
Contraintes: <style, archi, perimetre>
|
||||
Verification: <tests exacts a lancer>
|
||||
Sortie attendue: <fichiers modifies + risques>
|
||||
```
|
||||
|
||||
## 4 scenarios de reference
|
||||
|
||||
## 1) Explorer un bounded context
|
||||
|
||||
Intention:
|
||||
- Comprendre ou implementer un changement dans un BC sans regression laterale.
|
||||
|
||||
Prompt minimal:
|
||||
```text
|
||||
Explore le BC <nom> avec profondeur medium.
|
||||
Retour: composants touches, points d'entree, tests existants et risques.
|
||||
```
|
||||
|
||||
Preuves attendues:
|
||||
- Carte des fichiers a modifier.
|
||||
- Test(s) smoke/mandatory proposes.
|
||||
|
||||
## 2) Ajouter un smoke test
|
||||
|
||||
Intention:
|
||||
- Couvrir rapidement un endpoint ou une route publique.
|
||||
|
||||
Prompt minimal:
|
||||
```text
|
||||
Propose un smoke test pour <route/endpoint> dans le projet de test approprie.
|
||||
Respecte les conventions de doc/testing.md.
|
||||
```
|
||||
|
||||
Preuves attendues:
|
||||
- Fichier test cree/modifie.
|
||||
- Commande precise pour executer le test cible.
|
||||
|
||||
## 3) Corriger une regression backend API
|
||||
|
||||
Intention:
|
||||
- Corriger un bug sans casser un flux voisin.
|
||||
|
||||
Prompt minimal:
|
||||
```text
|
||||
Planifie puis implemente un fix de <symptome> dans <projet>.
|
||||
Ajoute/ajuste un test NonRegression rouge puis vert.
|
||||
```
|
||||
|
||||
Preuves attendues:
|
||||
- Explication cause racine.
|
||||
- Test non-regression associe.
|
||||
- Commande d'execution et resultat attendu.
|
||||
|
||||
## 4) Tracer un flux PostIt/OIDC
|
||||
|
||||
Intention:
|
||||
- Localiser une cassure d'authentification entre client et serveur.
|
||||
|
||||
Prompt minimal:
|
||||
```text
|
||||
Cartographie le flux OIDC PostIt: entrypoints, callback, stockage token,
|
||||
refresh. Donne points de rupture probables et tests/verification proposes.
|
||||
```
|
||||
|
||||
Preuves attendues:
|
||||
- Liste ordonnee des etapes du flux.
|
||||
- Fichiers critiques.
|
||||
- Hypotheses testables.
|
||||
|
||||
## Anti-patterns a eviter
|
||||
|
||||
- Prompt sans objectif verifiable.
|
||||
- Demande trop large sans perimetre de fichiers.
|
||||
- Validation basee uniquement sur "ca semble correct".
|
||||
- Pas de lien entre changement et niveau de test.
|
||||
|
||||
## Gate PR minimale (agent-assiste)
|
||||
|
||||
Avant validation:
|
||||
- Impact architecture explicite.
|
||||
- Rationale de choix agent explicite.
|
||||
- Test(s) executes et justifies.
|
||||
- Risques residuels documentes.
|
||||
73
doc/onboarding-agents.md
Normal file
73
doc/onboarding-agents.md
Normal file
|
|
@ -0,0 +1,73 @@
|
|||
# Onboarding guide: agents IA + architecture + tests
|
||||
|
||||
Ce guide est optimise pour accelerer la prise en main des agents IA
|
||||
(Copilot, Plan, Explore) dans Yavsc, avec une verification rapide
|
||||
par les tests.
|
||||
|
||||
## Resultat attendu
|
||||
|
||||
A la fin du parcours, un contributeur doit pouvoir:
|
||||
- Identifier les projets impactes par une modification.
|
||||
- Choisir l'agent adapte a l'intention de travail.
|
||||
- Produire une proposition de changement verifiable par les tests.
|
||||
|
||||
## Parcours en 3 modules
|
||||
|
||||
## Module A - Comprendre le terrain (30-45 min)
|
||||
|
||||
Objectif: acquerir une lecture fiable de l'architecture.
|
||||
|
||||
1. Lire [README.md](../README.md) puis [Architecture.md](Architecture.md).
|
||||
2. Lire [architecture/decoupage-organisation.md](architecture/decoupage-organisation.md).
|
||||
3. Selon le domaine:
|
||||
- Backend/API: [architecture/workflow-multi-parties.md](architecture/workflow-multi-parties.md)
|
||||
- PostIt: [architecture/postit.md](architecture/postit.md) puis [architecture/postit-oidc.md](architecture/postit-oidc.md)
|
||||
|
||||
Definition of done:
|
||||
- Expliquer en 5 phrases quelles couches sont touchees.
|
||||
- Citer le ou les points d'entree applicatifs a verifier.
|
||||
|
||||
## Module B - Boucle tests rapide (20-30 min)
|
||||
|
||||
Objectif: verifier rapidement sans lancer toute la suite.
|
||||
|
||||
1. Lire [testing.md](testing.md).
|
||||
2. Lancer les smoke tests d'abord, puis mandatory selon le projet.
|
||||
3. N'elargir au test complet que si le scope depasse le BC touche.
|
||||
|
||||
Definition of done:
|
||||
- Fournir la commande test executee.
|
||||
- Expliquer pourquoi ce niveau de test est suffisant.
|
||||
|
||||
## Module C - Usage agentique en production (30-40 min)
|
||||
|
||||
Objectif: utiliser les agents comme accelerateurs, pas comme boites noires.
|
||||
|
||||
1. Plan: decomposer la tache en etapes verifiables.
|
||||
2. Explore: collecter le contexte code/doc precise.
|
||||
3. Copilot: implementer localement et verifier.
|
||||
|
||||
Regles:
|
||||
- Toujours donner un contexte explicite (fichier, but, contrainte).
|
||||
- Demander des preuves observables (fichiers modifies, tests, risques).
|
||||
- Refuser toute sortie non verifiable.
|
||||
|
||||
Definition of done:
|
||||
- Une tache simple est livree avec:
|
||||
- Plan
|
||||
- Changement local
|
||||
- Preuve par test
|
||||
|
||||
## Routine continue (sans echeance fixe)
|
||||
|
||||
Rituels recommandes:
|
||||
- Hebdo: revue des prompts qui ont bien fonctionne.
|
||||
- Mensuel: mise a jour du present guide et du playbook.
|
||||
- A chaque incident: ajouter un anti-pattern dans le playbook.
|
||||
|
||||
## Check-list de validation
|
||||
|
||||
- Le changement indique son impact architecture.
|
||||
- Le choix de l'agent est justifie.
|
||||
- La preuve test est incluse.
|
||||
- Les risques residuels sont explicitement listes.
|
||||
Loading…
Add table
Add a link
Reference in a new issue