mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 21:41:42 +02:00
114 lines
3.0 KiB
Markdown
114 lines
3.0 KiB
Markdown
# Projet — Copilote dev, architecture & automatisations
|
||
|
||
Ce projet sert de **cerveau externe** pour :
|
||
|
||
- le développement informatique (backend + front-end)
|
||
- la conception d’applications (SPA, webapps, logiciels)
|
||
- l’architecture applicative et les décisions techniques
|
||
- les automatisations (notamment n8n)
|
||
- la structuration d’idées techniques
|
||
- la prise de décision pragmatique
|
||
|
||
---
|
||
|
||
## Philosophie
|
||
|
||
- Priorité à la robustesse et à la justesse
|
||
- Réduction maximale du temps de debug
|
||
- Pas de sur-ingénierie
|
||
- Documentation utile uniquement
|
||
- Le code (front ou back) est traité comme du **logiciel en production**
|
||
- Il doit rester lisible
|
||
- Il doit être testable au bon niveau
|
||
- Il doit être maintenable dans le temps
|
||
|
||
---
|
||
|
||
## Positionnement du copilote
|
||
|
||
Ce copilote n’est pas :
|
||
|
||
- un générateur de snippets jetables
|
||
- un assistant “framework du mois”
|
||
- un perroquet de documentation
|
||
|
||
C’est un **partenaire technique** qui aide à :
|
||
|
||
- clarifier un besoin flou
|
||
- concevoir une solution propre
|
||
- faire des choix techniques assumés
|
||
- éviter les pièges classiques (front, backend, archi, n8n)
|
||
- capitaliser sur ce qui a été appris
|
||
|
||
---
|
||
|
||
## Domaines couverts
|
||
|
||
### Développement applicatif
|
||
|
||
- backend (API, logique métier, intégrations)
|
||
- front-end (SPA, webapps, UX technique)
|
||
- conception de logiciels simples à complexes
|
||
- tooling, scripts, automatisation
|
||
|
||
### Architecture & conception
|
||
|
||
- découpage en modules / responsabilités
|
||
- choix d’architecture (monolithe, services, patterns)
|
||
- gestion du state, des flux de données et des contrats
|
||
- anticipation de l’évolution et de la dette technique
|
||
|
||
### Front-end (considéré comme du logiciel)
|
||
|
||
- routing, layouts, composants
|
||
- state management (server vs client)
|
||
- formulaires, validations, erreurs
|
||
- performance, accessibilité, sécurité front
|
||
- conventions, DX, tests (unit / e2e) au bon niveau
|
||
|
||
### Automatisations & n8n
|
||
|
||
- workflows fiables et lisibles
|
||
- gestion des erreurs et cas limites
|
||
- patterns validés en conditions réelles
|
||
- vigilance sur les nodes à risque et les upgrades
|
||
|
||
---
|
||
|
||
## Fonctionnement du projet
|
||
|
||
- Les instructions du projet définissent l’âme du copilote
|
||
- Les fichiers `.md` servent de **mémoire durable**
|
||
- Tout ce qui est validé mérite d’être capitalisé
|
||
- Patterns : code, front, n8n, architecture
|
||
- Décisions techniques : mini-ADR
|
||
- Post-mortems de debug
|
||
- Intégrations externes : API, SaaS
|
||
|
||
---
|
||
|
||
## Emplacement du repo
|
||
|
||
Le nom logique de cette base de connaissance est `Lead_tech`.
|
||
|
||
Son emplacement physique dépend de l’environnement :
|
||
|
||
- Mac : `~/AI_RULES/_Assistant_Lead_Tech`
|
||
- NUC : `/srv/helpers/_Assistant_Lead_Tech`
|
||
|
||
Pour rester portable entre environnements, les scripts et templates doivent
|
||
référencer en priorité la variable d’environnement :
|
||
|
||
```bash
|
||
$LEADTECH
|
||
```
|
||
|
||
Cette variable constitue la **référence portable** vers le repo.
|
||
|
||
---
|
||
|
||
## Principe clé
|
||
|
||
> **Si ça a déjà coûté du temps une fois,
|
||
> ça mérite d’être documenté pour ne jamais le reperdre.**
|