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

Identifie le domaine : backend, frontend, ux, workflow
Lis le README.md du sous-dossier patterns/ ou risques/ concerné
Dans ce README, repère les fichiers dont le nom et la description matchent le contexte
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

Règles de mise à jour

Quand tu repères qu'un pattern mérite d'être capitalisé :

FILE_UPDATE_PROPOSAL
Fichier : `<nom_du_fichier>`
Pourquoi : <1-2 phrases>

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

Ce fichier sert de zone tampon pour les apprentissages à analyser.

Après validation, le contenu est déplacé vers le fichier approprié dans knowledge/ :

knowledge/backend/patterns/<thème>.md
knowledge/backend/risques/<thème>.md
knowledge/frontend/patterns/<thème>.md
knowledge/frontend/risques/<thème>.md
knowledge/ux/patterns/<thème>.md
knowledge/ux/risques/<thème>.md
knowledge/n8n/patterns/general.md
knowledge/n8n/risques/general.md
knowledge/product/patterns/general.md
knowledge/product/risques/<thème>.md
knowledge/workflow/risques/story-tracking.md
10_conventions_redaction.md
40_decisions_et_archi.md
90_debug_et_postmortem.md

Objectif :

éviter de polluer la base de connaissance
capitaliser progressivement les retours d'expérience
maintenir Lead_tech comme mémoire fiable et validée

Projets actifs

La liste des projets actifs est maintenue dans _projects.conf.

Ce fichier constitue le registre central des projets (stack, scope, état). Les scripts de l’environnement Lead_tech l’utilisent pour résoudre automatiquement les chemins selon la machine (Mac / NUC).

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).

4.9 KiB Raw Blame History Unescape Escape