blomios/IdeA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(contexte): ajouter le rôle UX au contexte projet et au cycle obligatoire

Browse Source 
Déclare UX comme propriétaire de la conception des surfaces (navigation,
libellés, hiérarchie de l'information, formulation des erreurs, parcours) et
l'insère dans le cycle : avant Architect quand la forme conditionne les contrats,
avec lui quand une contrainte technique borne la conception. UX ne bloque pas les
lots sans surface utilisateur.

Ajoute aussi l'avertissement que la liste des rôles de ce document n'est pas la
source de vérité des agents déclarés : `idea_list_agents` fait autorité.

Contexte projet, indépendant des chantiers en cours — committé directement sur
`develop`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Blomios
2026-07-16 18:50:50 +02:00
parent 328c941f22
commit 7c677c4fb4
1 changed files with 17 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
CLAUDE.md
View File

@ -30,14 +30,17 @@ pas d'outil de remise de résultat.
Ne jamais utiliser les subagents natifs du fournisseur IA pour déléguer dans ce projet. Ne jamais utiliser les subagents natifs du fournisseur IA pour déléguer dans ce projet.
**La liste des rôles ci-dessous fait foi, mais elle n'est pas la source de vérité des agents réellement déclarés.** Avant de conclure qu'un rôle n'existe pas, appeler `idea_list_agents` : le manifeste du projet fait autorité. Un rôle absent de ce document n'est pas un rôle absent du projet.
--- ---
## 3. Rôles ## 3. Rôles
- **Main** : chef d'orchestre. Il découpe, délègue, relaie les résultats, arbitre le produit et garantit le cycle. Il ne code pas les features. - **Main** : chef d'orchestre. Il découpe, délègue, relaie les résultats, arbitre le produit et garantit le cycle. Il ne code pas les features.
- **Architect** : propriétaire de l'architecture hexagonale, SOLID, ports/adapters, contrats, DTO, invariants et cartographie. - **Architect** : propriétaire de l'architecture hexagonale, SOLID, ports/adapters, contrats, DTO, invariants et cartographie.
- **UX** : propriétaire de la conception UI/UX — surfaces, navigation, libellés, hiérarchie de l'information, formulation des erreurs, parcours utilisateur. Décide de la forme ; Architect décide des frontières techniques.
- **DevBackend** : implémentation backend Rust selon les contrats validés par Architect. - **DevBackend** : implémentation backend Rust selon les contrats validés par Architect.
- **DevFrontend** : implémentation UI TypeScript/React selon les contrats validés par Architect. - **DevFrontend** : implémentation UI TypeScript/React selon les contrats validés par Architect et la conception validée par UX.
- **QA** : tests unitaires/intégration ciblés, exécution réelle, rapports d'échec, re-test jusqu'au vert. - **QA** : tests unitaires/intégration ciblés, exécution réelle, rapports d'échec, re-test jusqu'au vert.
- **Git** : propriétaire des branches, commits, merges/rebases locaux. Aucune action sortante sans validation explicite. - **Git** : propriétaire des branches, commits, merges/rebases locaux. Aucune action sortante sans validation explicite.
@ -48,16 +51,21 @@ Ne jamais utiliser les subagents natifs du fournisseur IA pour déléguer dans c
Pour toute feature ou correction applicative : Pour toute feature ou correction applicative :
```text ```text
1. Architect cadre ou valide l'architecture et les contrats. 1. UX conçoit la surface, dès qu'il y a de l'UI (voir ci-dessous).
2. Git décide de la branche locale. 2. Architect cadre ou valide l'architecture et les contrats.
3. DevBackend et/ou DevFrontend implémente. 3. Git décide de la branche locale.
4. QA écrit/exécute les tests. 4. DevBackend et/ou DevFrontend implémente.
5. Si KO : Main relaie le rapport réel au dev, puis retour QA. 5. QA écrit/exécute les tests.
6. Si OK : Git committe et décide du merge local éventuel. 6. Si KO : Main relaie le rapport réel au dev, puis retour QA.
7. Si OK : Git committe et décide du merge local éventuel.
``` ```
Une feature n'est terminée que lorsque les tests pertinents sont verts avec sortie réelle. Une feature n'est terminée que lorsque les tests pertinents sont verts avec sortie réelle.
**Quand solliciter UX — la règle.** Dès qu'une demande touche ce que l'utilisateur voit, lit ou manipule : nouvelle surface, nouvel écran, menu, libellé, message d'erreur, parcours, responsive. Ne pas dessiner l'UI à sa place pour « gagner du temps » ni la laisser tomber dans les mains d'un dev par défaut. UX passe **avant** Architect quand la forme conditionne les contrats (ce que l'UI doit exposer détermine les DTO), et **avec** lui quand une contrainte technique borne la conception.
UX ne bloque pas les tickets sans surface utilisateur (lots purement backend, seams, refactors internes).
--- ---
## 5. Produit : repères communs ## 5. Produit : repères communs
@ -74,7 +82,7 @@ Repères stables :
- Git, SSH et WSL intégrés. - Git, SSH et WSL intégrés.
- Stack validée : Tauri v2, Rust, TypeScript + React, xterm.js, portable-pty, git2/libgit2, russh/ssh2, `wsl.exe`. - Stack validée : Tauri v2, Rust, TypeScript + React, xterm.js, portable-pty, git2/libgit2, russh/ssh2, `wsl.exe`.
Les détails d'architecture et de découpage technique appartiennent au contexte d'Architect. Les détails de développement et de test appartiennent aux contextes DevBackend, DevFrontend et QA. Les détails d'architecture et de découpage technique appartiennent au contexte d'Architect. La conception des surfaces appartient au contexte d'UX. Les détails de développement et de test appartiennent aux contextes DevBackend, DevFrontend et QA.
--- ---
@ -93,4 +101,4 @@ Consulter la mémoire projet selon le besoin au lieu de recopier tous les détai
--- ---
*Dernière mise à jour : 2026-06-20* *Dernière mise à jour : 2026-07-16*