# Workflow Orchestration

## Plan Node Default
- Plan mode pour toute tâche non-triviale (3+ étapes ou décisions archi)
- Si ça déraille : STOP et re-planifier, ne pas continuer à pousser
- Utiliser le plan mode pour les étapes de vérification, pas seulement la construction
- Écrire des specs détaillées en amont pour réduire l'ambiguïté 
- Toujours indiquer le plan dans ./.claude/plans/

## Subagent Strategy
- Utiliser les sub-agents libéralement pour garder le contexte principal propre
- Déléguer recherche, exploration, analyse parallèle aux sub-agents
- Problèmes complexes → plus de compute via sub-agents
- Une tâche par sub-agent pour une exécution focalisée

## Self-Improvement Loop
- Après toute correction : mettre à jour tasks/lessons.md avec le pattern
- Écrire des règles pour éviter la même erreur
- Itérer jusqu'à réduction des erreurs
- Relire les leçons au début de chaque session

## Verification Before Done
- Ne jamais marquer terminé sans prouver que ça fonctionne
- Diff entre comportement original et tes changements
- Se demander : "Un staff engineer approuverait-il ça ?"
- Lancer les tests, vérifier les logs

## Demand Elegance (Balanced)
- Pour changements non-triviaux : pause et demander "y a-t-il plus élégant ?"
- Si un fix semble hacky : implémenter la solution élégante
- Ignorer pour les fixes simples et évidents
- Challenger son propre travail avant de le présenter 
 
## Autonomous Bug Fixing
- Bug report reçu : juste le corriger, sans demander de l'aide
- Pointer les logs, erreurs, tests échoués → les résoudre
- Zéro changement de contexte requis de l'utilisateur
- Corriger les CI échouées sans qu'on le demande

## Task Management
- Plan First → ./.claude/tasks/todo.md avec items cochables
- Verify Plan → vérifier avant d'implémenter
- Track Progress → marquer les items au fur et à mesure
- Explain Changes → résumé haut niveau à chaque étape
- Document Results → section review dans ./.claude/tasks/todo.md
- Capture Lessons → ./.claude/tasks/lessons.md après corrections

## Core Principles
- Simplicity First : changement minimal, impact minimal
- No Laziness : trouver les causes racines, standards senior dev
- Minimal Impact : toucher uniquement ce qui est nécessaire

## General
- Tous les fichiers php doivent avoir un header declare(strict_types=1);
- Privilégier les imports aux FQCN dans le code
- Regrouper tous les use php dans le namespace App\ au niveau de App
- Regrouper tous les autres use qui le peuvent au 2è niveau de namespace par exemple Illuminate\Database
- Il faut respecter l'indentation déjà en place dans les autres fichiers, ne pas dépasser en longueur etc
- Toujours un saut de ligne avant un return s'il y a du contenu au dessus dans la méthode
- Ne pas ajouter de commentaires pour expliquer le code produit sauf si demandé explicitement ou pour les annotations quand nécessaire et déjà fait avant dans des situations similaires
- Pour éxecuter des commandes php artisan il faut utiliser bin/dev/artisan
- Si dans une classe php il faut créer des setters et des getters, les setters doivent toujours être présent avant les getters correspondants
- Toujours utiliser === false au lieu de !$var
- Toujours privilégier une comparaison de type au lieu de $var === null si c'est possible
- Quand je parle de Model, tu peux trouver les classes Model dans App/Models
- Quand je parle de Model Nova, tu peux trouver les classes Model Nova dans App/Nova
- Quand je parle de ViewModels, tu peux trouver les classes dans App/View
- Quand je parle de Mapper, tu peux trouver les classes dans App/Mappers
- Je ne veux pas que tu valide tout cxe que je dis
- Je veux que tu puisses valider tout ce que tu me dis par une source minimum
- Cette application est en Laravel 12, Php 8.2
- Les autorisations vivent dans les Policy (App/Policies/Models) ; les resources/actions Nova délèguent via `$user->can('<ability>', static::class)` — les policies sont mappées sur la classe resource Nova dans App/Providers/AuthServiceProvider. Pas de logique de rôle inline dans les resources/actions.
- Environnement de dev : démarrer la stack avec `bin/dev/start`, puis tout passe par les wrappers `bin/dev/*` (composer, artisan…). Il n'y a pas de `bin/ci/validate` ni de DB/TU de test exploitables : valider via un smoke test `bin/dev/artisan tinker --execute="require base_path('…');"` (le fichier en argument bloque au REPL). Pint (preset défaut) veut dégrouper les imports, à l'inverse de la convention : ne pas l'utiliser en auto-fix. Détails dans .claude/tasks/lessons.md