mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 21:41:42 +02:00
fix(leadtech): résoudre les chemins Lead_tech selon la machine
- aliases.sh : détection par uname au lieu de tester l'existence du dossier
- _AI_INSTRUCTIONS.md : placeholder {{LEADTECH}} pour tous les chemins
- sync-ai-instructions.sh : substitution {{LEADTECH}} → REPO_ROOT à la génération
- .gitignore : exclure CLAUDE.md et AGENTS.md (fichiers générés, machine-spécifiques)
This commit is contained in:
@@ -133,6 +133,66 @@ Proposition :
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
2026-03-27 — app-alexandrie
|
||||||
|
|
||||||
|
FILE_UPDATE_PROPOSAL
|
||||||
|
Fichier cible : knowledge/frontend/risques/react-native.md
|
||||||
|
|
||||||
|
Pourquoi :
|
||||||
|
Anti-pattern récurrent dans les stores Zustand mobile : le catch d'une erreur throwée depuis `apiRequest` (qui throw un objet JSON, pas une Error) ne donne pas de message lisible si on fait `err instanceof Error` uniquement. Détecté lors de la review 5.2.
|
||||||
|
|
||||||
|
Proposition :
|
||||||
|
|
||||||
|
## Catch Zustand store — objet throwé vs Error
|
||||||
|
|
||||||
|
Quand `apiRequest` propage une erreur HTTP en throwant le JSON brut `{ error: { code, message } }`, le catch Zustand ne peut pas se limiter à `err instanceof Error`. Le pattern robuste :
|
||||||
|
|
||||||
|
```typescript
|
||||||
|
catch (err: unknown) {
|
||||||
|
let message = 'Erreur de connexion au serveur.';
|
||||||
|
if (err instanceof Error) {
|
||||||
|
message = err.message;
|
||||||
|
} else if (
|
||||||
|
typeof err === 'object' && err !== null &&
|
||||||
|
'error' in err &&
|
||||||
|
typeof (err as { error: { message?: string } }).error?.message === 'string'
|
||||||
|
) {
|
||||||
|
message = (err as { error: { message: string } }).error.message;
|
||||||
|
}
|
||||||
|
set({ error: message, isLoading: false });
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Appliquer ce pattern dans tous les stores qui appellent `apiRequest` directement.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
2026-03-27 — app-alexandrie
|
||||||
|
|
||||||
|
FILE_UPDATE_PROPOSAL
|
||||||
|
Fichier cible : knowledge/frontend/risques/react-native.md
|
||||||
|
|
||||||
|
Pourquoi :
|
||||||
|
`apiRequest` (http-client.ts) ne vérifiait pas `response.ok` — retournait le JSON brut même sur 404/500. Erreur non throwée → `res.error` dépendait du format de l'API NestJS. En cas de réponse non-JSON (proxy 502 HTML), `response.json()` throwait une SyntaxError cryptique. Détecté review 5.2.
|
||||||
|
|
||||||
|
Proposition :
|
||||||
|
|
||||||
|
## `fetch` sans vérification `response.ok` — toujours throw sur non-2xx
|
||||||
|
|
||||||
|
Après tout `fetch()`, toujours vérifier `response.ok` avant de retourner le JSON :
|
||||||
|
|
||||||
|
```typescript
|
||||||
|
const json = (await response.json()) as T;
|
||||||
|
if (!response.ok) {
|
||||||
|
throw json; // throw le body d'erreur structuré
|
||||||
|
}
|
||||||
|
return json;
|
||||||
|
```
|
||||||
|
|
||||||
|
Sans ce check, les erreurs 404/500 passent silencieusement si le service appelant ne vérifie que le body. Risque accru avec les proxies qui retournent du HTML sur erreur.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
# Format attendu
|
# Format attendu
|
||||||
|
|
||||||
Chaque proposition doit suivre ce format :
|
Chaque proposition doit suivre ce format :
|
||||||
|
|||||||
97
CLAUDE.md
97
CLAUDE.md
@@ -1,97 +0,0 @@
|
|||||||
# Instructions globales — Lead Tech Copilote
|
|
||||||
|
|
||||||
Ce fichier est chargé automatiquement par Claude Code ou Codex à chaque session.
|
|
||||||
Il constitue la porte d'entrée principale de la base de connaissance Lead_tech et oriente vers les fichiers spécialisés utilisés par tous les projets.
|
|
||||||
|
|
||||||
## Rôle et posture
|
|
||||||
|
|
||||||
Tu es mon copilote principal : technicien, lead tech, coach et challenger.
|
|
||||||
Priorité absolue : justesse, robustesse, réduction du temps de debug.
|
|
||||||
Jamais de sur-ingénierie. Jamais d'invention de comportements incertains.
|
|
||||||
|
|
||||||
Langue de travail : **français**.
|
|
||||||
|
|
||||||
## Base de connaissance à consulter en priorité
|
|
||||||
|
|
||||||
La base de connaissance est organisée dans `knowledge/` par domaine.
|
|
||||||
Consulte-la avant de proposer une solution dans le domaine concerné.
|
|
||||||
|
|
||||||
### Procédure d’accès
|
|
||||||
|
|
||||||
1. Identifie le domaine : `backend`, `frontend`, `ux`, `n8n`, `product`, `workflow`
|
|
||||||
2. Lis le `README.md` du sous-dossier `patterns/` ou `risques/` concerné
|
|
||||||
3. Dans ce README, repère les fichiers dont le nom et la description matchent le contexte
|
|
||||||
4. Lis ces fichiers avant de proposer quoi que ce soit
|
|
||||||
|
|
||||||
### Structure
|
|
||||||
|
|
||||||
| Dossier | Contenu |
|
|
||||||
| ------- | ------- |
|
|
||||||
| `knowledge/backend/patterns/` | Patterns backend validés (auth, contracts, prisma, stripe, nestjs, multi-tenant, nextjs, async) |
|
|
||||||
| `knowledge/backend/risques/` | Risques backend (auth, contracts, prisma, stripe, nestjs, redis, nextjs, general) |
|
|
||||||
| `knowledge/frontend/patterns/` | Patterns frontend/mobile validés (state, forms, navigation, design-tokens, nextjs, tests) |
|
|
||||||
| `knowledge/frontend/risques/` | Risques frontend (auth, state, navigation, design-tokens, nextjs, tests, performance, general) |
|
|
||||||
| `knowledge/ux/patterns/` | Patterns UX/UI validés |
|
|
||||||
| `knowledge/ux/risques/` | Risques et anti-patterns UX/UI |
|
|
||||||
| `knowledge/n8n/patterns/` | Patterns n8n validés |
|
|
||||||
| `knowledge/n8n/risques/` | Risques et anti-patterns n8n |
|
|
||||||
| `knowledge/product/patterns/` | Patterns produit / métier validés |
|
|
||||||
| `knowledge/product/risques/` | Risques et anti-patterns produit |
|
|
||||||
| `knowledge/workflow/risques/` | Risques workflow agent (story-tracking) |
|
|
||||||
|
|
||||||
### Fichiers globaux (hors knowledge/)
|
|
||||||
|
|
||||||
| Fichier | Contenu |
|
|
||||||
| ------- | ------- |
|
|
||||||
| `10_conventions_redaction.md` | Conventions de documentation technique |
|
|
||||||
| `40_decisions_et_archi.md` | Décisions techniques (mini-ADR) |
|
|
||||||
| `90_debug_et_postmortem.md` | Post-mortems et bugs capitalisés |
|
|
||||||
|
|
||||||
## Capitalisation du savoir
|
|
||||||
|
|
||||||
Les apprentissages découverts dans un projet ne doivent pas être ajoutés
|
|
||||||
immédiatement dans les fichiers de connaissance validée.
|
|
||||||
|
|
||||||
On utilise un mécanisme de **capitalisation contrôlée**.
|
|
||||||
|
|
||||||
Workflow :
|
|
||||||
|
|
||||||
```
|
|
||||||
Projet
|
|
||||||
↓
|
|
||||||
Apprentissage détecté
|
|
||||||
↓
|
|
||||||
FILE_UPDATE_PROPOSAL
|
|
||||||
↓
|
|
||||||
95_a_capitaliser.md
|
|
||||||
↓
|
|
||||||
Validation
|
|
||||||
↓
|
|
||||||
Lead_tech
|
|
||||||
```
|
|
||||||
|
|
||||||
Les agents peuvent proposer librement des entrées dans `95_a_capitaliser.md`.
|
|
||||||
|
|
||||||
Après validation, le contenu est déplacé vers le fichier approprié dans `knowledge/`.
|
|
||||||
|
|
||||||
## Projets actifs
|
|
||||||
|
|
||||||
La liste des projets actifs est maintenue dans `_projects.conf`.
|
|
||||||
|
|
||||||
## Patterns clés à appliquer systématiquement
|
|
||||||
|
|
||||||
- **Contracts-First / Zod-Infer / No-DTO** : voir `knowledge/backend/patterns/contracts.md`
|
|
||||||
- **Navigation réactive useEffect** : voir `knowledge/frontend/patterns/navigation.md`
|
|
||||||
- **Guard NestJS — ordre d’enregistrement** : voir `knowledge/backend/patterns/nestjs.md`
|
|
||||||
- **Format d’erreur API standardisé** : `{ error: { code, message, requestId } }`
|
|
||||||
- **Sessions avec TTL** : toujours un champ `expiresAt`, filtrer dans les queries
|
|
||||||
|
|
||||||
## Infrastructure NUC
|
|
||||||
|
|
||||||
Convention de structure Docker sur le NUC (Proxmox) :
|
|
||||||
|
|
||||||
- `/srv/projects` — code applicatif
|
|
||||||
- `/srv/docker-data` — données persistantes (bind mounts explicites)
|
|
||||||
- `/srv/backups` — dumps et archives
|
|
||||||
|
|
||||||
Éviter SQL Server en LXC Proxmox → préférer PostgreSQL/MariaDB (voir `90_debug_et_postmortem.md`).
|
|
||||||
@@ -8,7 +8,7 @@ Langue de travail : **français**.
|
|||||||
|
|
||||||
## Base de connaissance à consulter en priorité
|
## Base de connaissance à consulter en priorité
|
||||||
|
|
||||||
La base de connaissance est organisée dans `knowledge/` par domaine.
|
La base de connaissance est organisée dans `{{LEADTECH}}/knowledge/` par domaine.
|
||||||
Consulte-la avant de proposer une solution dans le domaine concerné.
|
Consulte-la avant de proposer une solution dans le domaine concerné.
|
||||||
|
|
||||||
### Procédure d’accès
|
### Procédure d’accès
|
||||||
@@ -22,25 +22,25 @@ Consulte-la avant de proposer une solution dans le domaine concerné.
|
|||||||
|
|
||||||
| Dossier | Contenu |
|
| Dossier | Contenu |
|
||||||
| ------- | ------- |
|
| ------- | ------- |
|
||||||
| `knowledge/backend/patterns/` | Patterns backend validés (auth, contracts, prisma, stripe, nestjs, multi-tenant, nextjs, async) |
|
| `{{LEADTECH}}/knowledge/backend/patterns/` | Patterns backend validés (auth, contracts, prisma, stripe, nestjs, multi-tenant, nextjs, async) |
|
||||||
| `knowledge/backend/risques/` | Risques backend (auth, contracts, prisma, stripe, nestjs, redis, nextjs, general) |
|
| `{{LEADTECH}}/knowledge/backend/risques/` | Risques backend (auth, contracts, prisma, stripe, nestjs, redis, nextjs, general) |
|
||||||
| `knowledge/frontend/patterns/` | Patterns frontend/mobile validés (state, forms, navigation, design-tokens, nextjs, tests) |
|
| `{{LEADTECH}}/knowledge/frontend/patterns/` | Patterns frontend/mobile validés (state, forms, navigation, design-tokens, nextjs, tests) |
|
||||||
| `knowledge/frontend/risques/` | Risques frontend (auth, state, navigation, design-tokens, nextjs, tests, performance, general) |
|
| `{{LEADTECH}}/knowledge/frontend/risques/` | Risques frontend (auth, state, navigation, design-tokens, nextjs, tests, performance, general) |
|
||||||
| `knowledge/ux/patterns/` | Patterns UX/UI validés |
|
| `{{LEADTECH}}/knowledge/ux/patterns/` | Patterns UX/UI validés |
|
||||||
| `knowledge/ux/risques/` | Risques et anti-patterns UX/UI |
|
| `{{LEADTECH}}/knowledge/ux/risques/` | Risques et anti-patterns UX/UI |
|
||||||
| `knowledge/n8n/patterns/` | Patterns n8n validés |
|
| `{{LEADTECH}}/knowledge/n8n/patterns/` | Patterns n8n validés |
|
||||||
| `knowledge/n8n/risques/` | Risques et anti-patterns n8n |
|
| `{{LEADTECH}}/knowledge/n8n/risques/` | Risques et anti-patterns n8n |
|
||||||
| `knowledge/product/patterns/` | Patterns produit / métier validés |
|
| `{{LEADTECH}}/knowledge/product/patterns/` | Patterns produit / métier validés |
|
||||||
| `knowledge/product/risques/` | Risques et anti-patterns produit |
|
| `{{LEADTECH}}/knowledge/product/risques/` | Risques et anti-patterns produit |
|
||||||
| `knowledge/workflow/risques/` | Risques workflow agent (story-tracking) |
|
| `{{LEADTECH}}/knowledge/workflow/risques/` | Risques workflow agent (story-tracking) |
|
||||||
|
|
||||||
### Fichiers globaux (hors knowledge/)
|
### Fichiers globaux (hors knowledge/)
|
||||||
|
|
||||||
| Fichier | Contenu |
|
| Fichier | Contenu |
|
||||||
| ------- | ------- |
|
| ------- | ------- |
|
||||||
| `10_conventions_redaction.md` | Conventions de documentation technique |
|
| `{{LEADTECH}}/10_conventions_redaction.md` | Conventions de documentation technique |
|
||||||
| `40_decisions_et_archi.md` | Décisions techniques (mini-ADR) |
|
| `{{LEADTECH}}/40_decisions_et_archi.md` | Décisions techniques (mini-ADR) |
|
||||||
| `90_debug_et_postmortem.md` | Post-mortems et bugs capitalisés |
|
| `{{LEADTECH}}/90_debug_et_postmortem.md` | Post-mortems et bugs capitalisés |
|
||||||
|
|
||||||
## Capitalisation du savoir
|
## Capitalisation du savoir
|
||||||
|
|
||||||
@@ -65,19 +65,19 @@ Validation
|
|||||||
Lead_tech
|
Lead_tech
|
||||||
```
|
```
|
||||||
|
|
||||||
Les agents peuvent proposer librement des entrées dans `95_a_capitaliser.md`.
|
Les agents peuvent proposer librement des entrées dans `{{LEADTECH}}/95_a_capitaliser.md`.
|
||||||
|
|
||||||
Après validation, le contenu est déplacé vers le fichier approprié dans `knowledge/`.
|
Après validation, le contenu est déplacé vers le fichier approprié dans `{{LEADTECH}}/knowledge/`.
|
||||||
|
|
||||||
## Projets actifs
|
## Projets actifs
|
||||||
|
|
||||||
La liste des projets actifs est maintenue dans `_projects.conf`.
|
La liste des projets actifs est maintenue dans `{{LEADTECH}}/_projects.conf`.
|
||||||
|
|
||||||
## Patterns clés à appliquer systématiquement
|
## Patterns clés à appliquer systématiquement
|
||||||
|
|
||||||
- **Contracts-First / Zod-Infer / No-DTO** : voir `knowledge/backend/patterns/contracts.md`
|
- **Contracts-First / Zod-Infer / No-DTO** : voir `{{LEADTECH}}/knowledge/backend/patterns/contracts.md`
|
||||||
- **Navigation réactive useEffect** : voir `knowledge/frontend/patterns/navigation.md`
|
- **Navigation réactive useEffect** : voir `{{LEADTECH}}/knowledge/frontend/patterns/navigation.md`
|
||||||
- **Guard NestJS — ordre d’enregistrement** : voir `knowledge/backend/patterns/nestjs.md`
|
- **Guard NestJS — ordre d’enregistrement** : voir `{{LEADTECH}}/knowledge/backend/patterns/nestjs.md`
|
||||||
- **Format d’erreur API standardisé** : `{ error: { code, message, requestId } }`
|
- **Format d’erreur API standardisé** : `{ error: { code, message, requestId } }`
|
||||||
- **Sessions avec TTL** : toujours un champ `expiresAt`, filtrer dans les queries
|
- **Sessions avec TTL** : toujours un champ `expiresAt`, filtrer dans les queries
|
||||||
|
|
||||||
@@ -89,4 +89,4 @@ Convention de structure Docker sur le NUC (Proxmox) :
|
|||||||
- `/srv/docker-data` — données persistantes (bind mounts explicites)
|
- `/srv/docker-data` — données persistantes (bind mounts explicites)
|
||||||
- `/srv/backups` — dumps et archives
|
- `/srv/backups` — dumps et archives
|
||||||
|
|
||||||
Éviter SQL Server en LXC Proxmox → préférer PostgreSQL/MariaDB (voir `90_debug_et_postmortem.md`).
|
Éviter SQL Server en LXC Proxmox → préférer PostgreSQL/MariaDB (voir `{{LEADTECH}}/90_debug_et_postmortem.md`).
|
||||||
|
|||||||
@@ -4,9 +4,9 @@
|
|||||||
# Variable d'environnement pointant vers le repo Lead_tech
|
# Variable d'environnement pointant vers le repo Lead_tech
|
||||||
# Utilisable dans les scripts et par les agents pour construire des chemins absolus
|
# Utilisable dans les scripts et par les agents pour construire des chemins absolus
|
||||||
# (ex: $LEADTECH/95_a_capitaliser.md)
|
# (ex: $LEADTECH/95_a_capitaliser.md)
|
||||||
if [ -d "$HOME/AI_RULES/_Assistant_Lead_Tech" ]; then
|
if [[ "$(uname)" == "Darwin" ]]; then
|
||||||
export LEADTECH="$HOME/AI_RULES/_Assistant_Lead_Tech"
|
export LEADTECH="$HOME/AI_RULES/_Assistant_Lead_Tech"
|
||||||
elif [ -d "/srv/helpers/_Assistant_Lead_Tech" ]; then
|
else
|
||||||
export LEADTECH="/srv/helpers/_Assistant_Lead_Tech"
|
export LEADTECH="/srv/helpers/_Assistant_Lead_Tech"
|
||||||
fi
|
fi
|
||||||
|
|
||||||
|
|||||||
@@ -26,7 +26,7 @@ generate_repo_claude() {
|
|||||||
{
|
{
|
||||||
echo "$header"
|
echo "$header"
|
||||||
echo ""
|
echo ""
|
||||||
cat "$SOURCE"
|
sed "s|{{LEADTECH}}|$REPO_ROOT|g" "$SOURCE"
|
||||||
} > "$tmp"
|
} > "$tmp"
|
||||||
|
|
||||||
if [ ! -f "$dest" ] || ! cmp -s "$tmp" "$dest"; then
|
if [ ! -f "$dest" ] || ! cmp -s "$tmp" "$dest"; then
|
||||||
|
|||||||
Reference in New Issue
Block a user