chore : initial claude-config repo

- global CLAUDE.md (time tracking via MCP lesstime) - workspace CLAUDE.md (dev_malio inventory) - commands : ticket-writer, push-tickets-lesstime, full-project-review, bump-version - MCP install guide (Code + Desktop) + .mcp.json.example - scripts/install.sh + sync.sh
2026-05-13 17:03:07 +02:00
commit ea27f27f7f
12 changed files with 1438 additions and 0 deletions
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1,17 @@
+# Secrets — never commit
+.mcp.json
+.credentials.json
+*.local.json
+*.local.md
+
+# OS / editor
+.DS_Store
+*.swp
+*.swo
+.vscode/
+.idea/
+
+# Logs / backups
+*.log
+*.bak
+*~
--- a/README.md
+++ b/README.md
@@ -0,0 +1,78 @@
+# claude-config — Configuration Claude Code partagée Malio
+
+Repo qui versionne **toute la configuration Claude Code** liée à l'écosystème Malio :
+
+- Le `CLAUDE.md` global (règles communes à tous les projets, time tracking obligatoire via MCP Lesstime)
+- Le `CLAUDE.md` de workspace `dev_malio/` (inventaire des projets, ports, conventions)
+- Les **slash commands** custom (`ticket-writer`, `push-tickets-lesstime`, `full-project-review`, `bump-version`)
+- La doc d'installation du **MCP Lesstime** pour Claude Code et Claude Desktop
+- Un **template** de `.mcp.json` (token à remplacer)
+- Un script d'install qui crée les symlinks depuis `~/.claude/`
+
+> Le but : pouvoir cloner ce repo sur une nouvelle machine et retrouver instantanément la même config Claude pour bosser sur les projets Malio.
+
+## Structure
+
+```
+claude-config/
+├── README.md                ← ce fichier
+├── .gitignore               ← exclut les vrais secrets (.mcp.json, credentials)
+├── global/
+│   └── CLAUDE.md            ← copie de ~/.claude/CLAUDE.md (règles globales)
+├── workspace/
+│   └── CLAUDE.md            ← copie de dev_malio/CLAUDE.md (inventaire projets)
+├── commands/                ← slash commands user (~/.claude/commands/*.md)
+│   ├── ticket-writer.md
+│   ├── push-tickets-lesstime.md
+│   ├── full-project-review.md
+│   └── bump-version.md
+├── mcp/
+│   ├── INSTALL.md           ← guide install MCP Lesstime (Code + Desktop)
+│   └── .mcp.json.example    ← template config MCP (sans token)
+└── scripts/
+    ├── install.sh           ← symlinks vers ~/.claude/
+    └── sync.sh              ← repompe les changements locaux dans le repo
+```
+
+## Installation rapide
+
+```bash
+cd /home/matthieu/dev_malio/claude-config
+./scripts/install.sh
+```
+
+Le script :
+1. Sauvegarde l'existant (`~/.claude/CLAUDE.md`, `~/.claude/commands/`) dans `~/.claude/backup-<date>/`
+2. Crée des symlinks de ce repo vers `~/.claude/`
+3. Affiche les étapes manuelles restantes (créer `~/.claude/.mcp.json` à partir du template avec ton token Lesstime)
+
+## Configurer le MCP Lesstime
+
+1. Récupérer un token API personnel sur http://project.malio-dev.fr/profile
+2. Copier le template : `cp mcp/.mcp.json.example ~/.claude/.mcp.json`
+3. Remplacer `REPLACE_WITH_YOUR_LESSTIME_API_TOKEN` par le token
+
+Détails complets dans [`mcp/INSTALL.md`](mcp/INSTALL.md), y compris l'install Claude Desktop (via `mcp-remote`).
+
+## Synchroniser
+
+Si tu modifies un fichier directement dans `~/.claude/` ou dans `dev_malio/CLAUDE.md`, lance :
+
+```bash
+./scripts/sync.sh
+```
+
+Le script recopie les sources locales dans le repo (sans toucher au `.mcp.json` réel). Tu n'as plus qu'à `git diff` / `git commit`.
+
+## Règles de versionning
+
+- **Ne jamais committer de secret** : `.mcp.json`, tokens, mots de passe → exclus par `.gitignore`
+- **Bumper le `CLAUDE.md` global** quand on change une règle qui s'applique à tous les projets
+- **Mettre à jour la doc MCP** (`mcp/INSTALL.md`) si la procédure de connexion change côté serveur Lesstime
+- Les `CLAUDE.md` **par projet** restent dans leur projet respectif (Inventory, Lesstime, SIRH, Coltura, infra-postgres). Ce repo ne versionne que les configs **transverses**.
+
+## Ressources
+
+- Doc officielle Claude Code : https://docs.anthropic.com/claude-code
+- Repo MCP Lesstime côté serveur : `dev_malio/Lesstime/src/Mcp/`
+- Doc MCP : https://modelcontextprotocol.io/
--- a/commands/bump-version.md
+++ b/commands/bump-version.md
@@ -0,0 +1,42 @@
+---
+name: bump-version
+description: Bump the app version, commit, tag, and push
+arguments:
+  - name: version
+    description: "Version number (e.g. 0.3.7). If omitted, auto-increments the patch version."
+    required: false
+---
+
+# Bump Version
+
+## Steps
+
+1. **Fetch remote**: Run `git fetch origin` to get latest state.
+
+2. **Check if local is behind**: If local branch is behind remote, rebase first (`git rebase origin/{branch}`). Stash unstaged changes if needed.
+
+3. **Determine version**: If `$ARGUMENTS` is provided, use it (strip leading `v` if present). Otherwise, read `config/version.yaml`, parse the current `app.version`, and increment the patch number (e.g. `0.3.6` → `0.3.7`).
+
+4. **Check remote tags**: Run `git ls-remote --tags origin` and verify tag `v{version}` does NOT already exist. If it does, keep incrementing patch until a free version is found, or ERROR if a specific version was requested.
+
+5. **Update version file**: Edit `config/version.yaml` to set `app.version: '{version}'`.
+
+6. **Stage version file**: `git add config/version.yaml` — ALWAYS stage this file explicitly.
+
+7. **Also stage any other pending changes**: Check `git status` for other staged files. If there are unstaged changes to tracked files, ask the user if they should be included.
+
+8. **Commit**: Commit with message `chore : bump version to v{version}`.
+
+9. **Tag**: Create git tag `v{version}`.
+
+10. **Push**: Run `git push origin {current_branch} --tags`.
+
+11. **Confirm**: Display the new version, tag, and push result.
+
+## Critical Rules
+
+- The version in `config/version.yaml` MUST always match the git tag.
+- ALWAYS check remote tags BEFORE committing to avoid conflicts.
+- ALWAYS `git add config/version.yaml` explicitly — never assume it's staged.
+- ALWAYS fetch and sync with remote BEFORE starting.
+- Format: `v{version}` for tags (e.g. `v0.3.7`), without `v` in yaml (e.g. `0.3.7`).
--- a/commands/full-project-review.md
+++ b/commands/full-project-review.md
@@ -0,0 +1,326 @@
+---
+name: full-project-review
+description: Use when the user asks for a complete project review, code audit, educational review, codebase health check, or intern/junior review. Triggers on words like "review", "audit", "revue", "review de projet", "code quality check". Produces a structured REVIEW.md with prioritized findings and a TICKETS.md with actionable fix tickets.
+---
+
+# Full Project Review
+
+## Overview
+
+Audit complet et educatif d'un projet. Produit un `REVIEW.md` structure couvrant securite, bugs, dead code, incoherences, documentation, frontend, CSS, CI/CD -- avec explications pedagogiques et tableau de priorites. Genere ensuite un `TICKETS.md` avec des tickets actionnables pour corriger les findings.
+
+**Principe :** Chaque finding explique le probleme, pourquoi c'est un probleme, et comment le corriger. Pas juste une liste de bugs -- un outil d'apprentissage.
+
+## When to Use
+
+- L'utilisateur demande une "review", "audit", "revue de code", "code quality check"
+- Review educative pour un junior/stagiaire
+- Health check avant mise en production
+- Onboarding sur un nouveau projet
+
+## Process
+
+```dot
+digraph review_flow {
+  rankdir=TB;
+  "1. Lire CLAUDE.md, AGENTS.md, README" -> "2. Lancer 2 agents en parallele";
+  "2. Lancer 2 agents en parallele" -> "3. Lire les fichiers critiques identifies";
+  "3. Lire les fichiers critiques identifies" -> "4. Rediger REVIEW.md structure";
+  "4. Rediger REVIEW.md structure" -> "5. Generer TICKETS.md";
+  "5. Generer TICKETS.md" -> "6. Resume au user";
+}
+```
+
+### Phase 1 -- Comprendre le contexte
+
+**REQUIRED:** Invoke `superpowers:brainstorming` if user requirements are unclear (scope of review, educational vs production audit, specific concerns).
+
+Lire dans cet ordre :
+1. `CLAUDE.md` / `AGENTS.md` / `GEMINI.md` -- les regles du projet
+2. `README.md` -- ce que le projet pretend etre
+3. `package.json` / `nuxt.config.ts` / `pyproject.toml` -- stack technique
+4. `.env.example` -- variables d'environnement
+5. `.gitignore`, CI workflows
+
+### Phase 2 -- Lancer 2 agents specialises en parallele
+
+**REQUIRED:** Use `superpowers:dispatching-parallel-agents` pattern for this phase.
+
+**Agent 1 : Exploration profonde** (`feature-dev:code-explorer`)
+
+Prompt :
+```
+I need a comprehensive deep-dive review of this entire project.
+
+Explore EVERYTHING and report back with detailed findings. Focus on:
+
+1. **Project structure** -- all directories, file organization
+2. **Documentation quality** -- README.md, CLAUDE.md, AGENTS.md, any .md files, comments quality
+3. **Configuration files** -- package.json, framework config, tsconfig, .env.example, docker files, CI/CD
+4. **Server-side code** -- all backend files (API routes, middleware, plugins, utils, config)
+5. **Frontend code** -- pages, components, composables, layouts, entry point
+6. **Security practices** -- auth, input validation, env vars handling, shell command safety (execFile vs shell execution)
+7. **Code quality** -- dead code, unused imports, inconsistent patterns, error handling
+8. **Dependencies** -- deps list, unnecessary deps, version alignment
+9. **Git hygiene** -- .gitignore, what is tracked that should not be
+
+Read ALL files you can find. Be thorough. Report raw findings with file paths and line numbers. Do not filter -- I want everything, good and bad.
+```
+
+**Agent 2 : Security and code quality** (`feature-dev:code-reviewer`)
+
+Prompt :
+```
+Do a thorough security and code quality review of this project.
+
+Focus specifically on:
+
+1. **Security vulnerabilities** -- injection risks (shell, SQL, XSS), auth bypass, hardcoded secrets, SSRF, path traversal
+2. **Error handling** -- uncaught exceptions, missing try/catch, error info leaks
+3. **API design** -- inconsistent responses, missing validation, HTTP status codes
+4. **Authentication** -- middleware bypass possibilities, token handling, cookie security
+5. **Input validation** -- all user inputs, query params, body params
+6. **Performance issues** -- memory leaks, blocking operations, missing timeouts
+7. **TypeScript usage** -- any types, missing types, type safety issues
+8. **Frontend issues** -- XSS risks, reactive state issues, missing loading/error states
+
+Read all server files, all components, all pages. Be thorough and report with file paths and line numbers. Report confidence levels for each finding.
+```
+
+### Phase 3 -- Lire les fichiers critiques identifies
+
+After agents return, manually read each flagged file to:
+- Verify findings (no false positives)
+- Understand full context (agents can miss nuances)
+- Identify cross-cutting patterns
+
+### Phase 4 -- Rediger REVIEW.md
+
+**REQUIRED:** Use `superpowers:verification-before-completion` before declaring the review complete -- verify key findings by re-reading the actual code.
+
+### Phase 5 -- Generer TICKETS.md
+
+Apres le REVIEW.md, generer un fichier `TICKETS.md` contenant des tickets actionnables pour corriger les findings. Ce document est destine a un developpeur (junior, stagiaire, ou l'auteur du code) qui va implementer les corrections.
+
+**Chaque ticket doit contenir :**
+1. Un identifiant unique (T-001, T-002, ...)
+2. Un titre court et clair
+3. **Pourquoi** -- une phrase expliquant le probleme (sans jargon inutile)
+4. **A faire** -- les etapes concretes, avec le code exact avant/apres quand c'est pertinent
+5. **Fichiers** -- la liste des fichiers concernes
+
+**Regles de redaction des tickets :**
+- Grouper par priorite (P0, P1, P2, P3) dans le meme ordre que le REVIEW.md
+- Un ticket = un changement atomique commitable independamment
+- Si un finding du REVIEW.md genere plusieurs changements dans des fichiers differents mais lies (ex: renommer une variable partout), c'est UN seul ticket
+- Si un finding est purement informatif et n'a pas d'action concrete, ne pas creer de ticket
+- Inclure le code exact a modifier (avant/apres) pour les tickets P0 et P1 -- le developpeur ne doit pas avoir a deviner
+- Pour les tickets P2/P3, une description claire suffit si le changement est evident
+- Terminer par un tableau recapitulatif avec estimation de temps par priorite
+- Suggerer une convention de commit : `fix(T-XXX): description courte`
+
+**Niveau de langage :**
+- Ecrire pour un stagiaire BTS SIO 2eme annee (niveau debutant-intermediaire)
+- Pas de jargon sans explication : si on dit "injection SQL", expliquer en une phrase ce que ca veut dire
+- Les etapes "A faire" doivent etre des instructions pas-a-pas qu'on peut suivre sans deviner
+- Montrer le code exact avant/apres (copier-coller ready) pour les P0 et P1
+- Si une commande git est necessaire, donner la commande complete
+- Privilegier les explications concretes ("si quelqu'un trouve ce lien, il peut poster des messages dans ton Discord") plutot qu'abstraites ("vecteur d'attaque via endpoint non authentifie")
+
+**Structure du TICKETS.md :**
+
+```markdown
+# Tickets correctifs -- Projet {NOM}
+
+> Liste de taches issues de la review du {DATE}.
+> Chaque ticket est autonome : contexte, ce qu'il faut faire, fichiers concernes.
+> Commence par les P0, puis P1, etc.
+
+---
+
+## P0 -- Urgents (securite)
+
+### T-001 -- {Titre}
+**Pourquoi :** {explication courte}
+**A faire :**
+1. {etape avec code avant/apres}
+2. {etape}
+**Fichiers :** `chemin/fichier.sh`
+
+---
+
+## P1 -- Importants
+...
+
+## P2 -- Documentation
+...
+
+## P3 -- Nice to have
+...
+
+## Resume
+
+| Priorite | Tickets | Estimation |
+|----------|---------|------------|
+| **P0** | T-001 a T-00X | ~Xh |
+| **P1** | T-00X a T-00X | ~Xh |
+| **P2** | T-00X a T-00X | ~Xh |
+| **P3** | T-00X a T-00X | ~Xmin |
+| **Total** | XX tickets | ~Xh |
+
+> Commence par T-001 -- c'est le plus urgent.
+> Pour chaque ticket, fais un commit dedie avec le numero du ticket dans le message (ex: `fix(T-001): description`).
+```
+
+## Structure du REVIEW.md
+
+```markdown
+# Review complete -- Projet {NOM}
+
+> Audit educatif du projet. Chaque point explique le probleme, pourquoi c'est un probleme, et comment le corriger.
+> Document genere le {DATE}.
+
+---
+
+## Table des matieres
+1. Securite
+2. Bugs fonctionnels
+3. Code mort et violations des regles projet
+4. Incoherences de patterns
+5. Documentation et configuration
+6. Frontend et UX
+7. CSS et design system
+8. CI/CD et dependances
+9. Bonnes pratiques a retenir
+
+---
+
+## 1. Securite
+### 1.1 {GRAVITE} -- {Titre court}
+**Fichier :** `chemin/fichier.ts` ligne XX
+{Explication du probleme}
+{Pourquoi c'est grave}
+{Code exemple avant/apres si pertinent}
+**Correction :** {Solution concrete}
+
+...
+
+## 9. Bonnes pratiques a retenir
+### Ce qui est bien fait dans le projet
+{Liste des points positifs -- toujours inclure, la review doit etre equilibree}
+
+### Les regles a graver
+{10 regles tirees des findings, numerotees}
+
+---
+
+## Resume par priorite
+| Priorite | # | Probleme | Fichier |
+|----------|---|----------|---------|
+| **P0** | x.x | ... | `fichier:ligne` |
+| **P1** | x.x | ... | `fichier:ligne` |
+| **P2** | x.x | ... | `fichier:ligne` |
+| **P3** | x.x | ... | `fichier:ligne` |
+```
+
+## Niveaux de gravite
+
+| Label | Signification | Exemples |
+|-------|--------------|----------|
+| **CRITIQUE** | Faille de securite exploitable ou bug bloquant | Injection shell, auth bypass, crash en prod |
+| **IMPORTANT** | Bug silencieux ou risque serieux | NaN dans une commande, undefined non garde, dead code trompeur |
+| **MOYEN** | Probleme reel mais impact limite | Fuite de processus, timeout manquant, validation incomplete |
+| **MINEUR** | Polish, coherence, dette technique | Typo CSS, import inconsistant, nom trompeur |
+
+## Priorites de resume
+
+| Priorite | Critere |
+|----------|---------|
+| **P0** | Securite exploitable + bugs qui cassent des fonctionnalites |
+| **P1** | Bugs silencieux + violations des regles projet + risques operationnels |
+| **P2** | Incoherences de patterns + documentation cassee + config incorrecte + CI manquante |
+| **P3** | Dead code mineur + polish frontend + typos CSS |
+
+## Checklist des categories a couvrir
+
+Ne pas oublier de verifier chacun de ces points :
+
+### Securite
+- [ ] Execution de commandes : `execFile` (safe) vs execution shell (injectable)
+- [ ] Input validation sur tous les parametres utilisateur (query, body, headers)
+- [ ] Auth : bypass possible ? Token/cookie securise ? Login requis ?
+- [ ] Secrets dans le code source ou dans la config publique du framework
+- [ ] `robots.txt` -- ouvert ou ferme pour un outil interne ?
+- [ ] Limite de taille sur les uploads
+- [ ] Timeout sur les fetch/requetes sortantes
+- [ ] Informations d'infrastructure dans les fichiers versionnes (hostnames, usernames, chemins absolus)
+- [ ] Processus enfants nettoyes en cas de deconnexion client
+- [ ] Chemins hardcodes (`/home/username/...`) au lieu de `$HOME` ou variables d'env
+
+### Bugs fonctionnels
+- [ ] Variables d'environnement non definies -> `undefined`, `NaN`, comportement silencieux
+- [ ] Code qui s'ecrase lui-meme (double assignation)
+- [ ] Incoherences de nommage entre fichiers (tiret vs underscore, etc.)
+- [ ] Fonctions dupliquees entre fichiers
+- [ ] Types manquants ou `any` implicite
+
+### Code mort
+- [ ] Fonctions declarees mais jamais appelees
+- [ ] Variables assignees mais jamais lues dans le template/output
+- [ ] Wrappers d'une ligne qui n'ajoutent rien
+- [ ] Fallbacks legacy pour des configs obsoletes
+- [ ] CSS pour des classes qui n'existent plus
+- [ ] `computed()` sur des constantes
+
+### Incoherences
+- [ ] Imports : melange de patterns pour le meme module
+- [ ] Auto-imports vs imports explicites dans le meme fichier
+- [ ] Indentation (2 vs 4 espaces) entre fichiers
+- [ ] Acces aux env vars : runtimeConfig vs process.env direct vs shims
+
+### Documentation
+- [ ] README : formatage casse, sections manquantes, commandes incoherentes
+- [ ] `.env.example` : commentaires explicatifs presents ?
+- [ ] `package.json` : nom correct ? champ `engines` ?
+- [ ] `.env` centralise et reference par chemin relatif dans les scripts
+- [ ] Doc SSH : meme cle/user/host dans toutes les commandes d'un bloc
+
+### Frontend
+- [ ] Etat actif sur la navigation (highlight de la page courante)
+- [ ] HTML duplique au lieu de composants partages
+- [ ] Texte statique trompeur (ex: "Production" hardcode)
+- [ ] Imports depuis `server/` dans du code client
+- [ ] Null guards sur les donnees dynamiques
+
+### CI/CD
+- [ ] Build et lint AVANT la release
+- [ ] Version Node alignee entre README, CI, et `package.json`
+- [ ] Dependances installees mais non utilisees
+
+## Regles de redaction
+
+1. **Toujours inclure les points positifs** -- une review 100% negative est demotivante et inexacte
+2. **Chaque finding = probleme + pourquoi + correction** -- educatif, pas juste une liste
+3. **Code exemple quand c'est utile** -- avant/apres, pas juste le mauvais code
+4. **Fichier et ligne pour chaque point** -- le lecteur doit pouvoir naviguer directement
+5. **Langue du projet** -- si le projet est en francais, la review est en francais
+6. **Pas de faux positifs** -- lire le fichier avant de signaler, comprendre le contexte
+7. **Tableau de priorites en fin de document** -- vue d'ensemble rapide pour le decideur
+
+## Skills superpowers a invoquer
+
+| Phase | Skill | Pourquoi |
+|-------|-------|----------|
+| Phase 1 | `superpowers:brainstorming` | Si le scope de la review n'est pas clair |
+| Phase 2 | `superpowers:dispatching-parallel-agents` | Pour lancer les 2 agents en parallele |
+| Phase 4 | `superpowers:verification-before-completion` | Verifier les findings avant de livrer |
+| Phase 5 | _(pas de skill)_ | Generer TICKETS.md a partir du REVIEW.md |
+| Apres | `superpowers:requesting-code-review` | Si l'utilisateur demande ensuite de corriger les findings |
+
+## Common Mistakes
+
+- **Signaler un probleme sans lire le fichier** -- les agents peuvent se tromper, toujours verifier
+- **Oublier les positifs** -- demotive l'equipe, semble partial
+- **Review trop longue sans structure** -- le tableau de priorites est essentiel
+- **Suggestions non-actionables** -- "ameliorez la securite" n'aide personne, "remplacez X par Y dans `fichier:ligne`" aide
+- **Ignorer AGENTS.md/CLAUDE.md** -- le projet a ses propres regles, les findings doivent les referencer
--- a/commands/push-tickets-lesstime.md
+++ b/commands/push-tickets-lesstime.md
@@ -0,0 +1,189 @@
+---
+name: push-tickets-lesstime
+description: Use after full-project-review to push TICKETS.md tickets into Lesstime project management via MCP. Triggers on "push tickets", "envoyer tickets", "creer les tickets dans lesstime", "sync tickets lesstime", "pousser les tickets".
+---
+
+# Push Tickets to Lesstime
+
+## Overview
+
+Prend le fichier `TICKETS.md` genere par le skill `full-project-review` et cree les taches correspondantes dans Lesstime via le **MCP `lesstime`** (`mcp__lesstime__*`). Chaque ticket devient une tache avec la bonne priorite, le bon groupe et la description complete.
+
+## When to Use
+
+- Apres un `full-project-review` qui a genere un `TICKETS.md`
+- L'utilisateur demande de "pousser", "sync", "envoyer" les tickets dans Lesstime
+- L'utilisateur veut creer les taches dans son gestionnaire de projet
+
+## Prerequis
+
+- Un fichier `TICKETS.md` doit exister dans le repertoire courant (genere par `full-project-review`)
+- Le MCP `lesstime` doit etre disponible (verifier `mcp__lesstime__list-projects` retourne du contenu). Si non, signaler le probleme a l'utilisateur — ne pas fallback sur curl.
+
+## Outils MCP utilises
+
+| Operation | Tool MCP |
+|-----------|----------|
+| Lister projets | `mcp__lesstime__list-projects` |
+| Lister users | `mcp__lesstime__list-users` |
+| Lister statuts (globaux) | `mcp__lesstime__list-statuses` |
+| Lister priorites (globales) | `mcp__lesstime__list-priorities` |
+| Lister tags (globaux) | `mcp__lesstime__list-tags` |
+| Lister groupes d'un projet | `mcp__lesstime__list-groups` (`projectId` optionnel) |
+| Creer un groupe | `mcp__lesstime__create-group` |
+| Creer une tache | `mcp__lesstime__create-task` |
+
+## Champs `create-task`
+
+| Champ | Type | Description |
+|------|------|-------------|
+| `projectId` | int (required) | Cible du ticket |
+| `title` | string (required) | Titre du ticket |
+| `description` | string | Markdown complet |
+| `statusId` | int | Defaut "A faire" = 1 |
+| `priorityId` | int | Voir `list-priorities` |
+| `effortId` | int | S/M/L — voir `list-efforts` |
+| `assigneeId` | int | User assignee |
+| `collaboratorIds` | int[] | Collaborateurs |
+| `groupId` | int | Groupe (per-project) |
+| `tagIds` | int[] | Tags globaux |
+| `deadline` | string (ISO date) | Optionnel |
+
+**Tous les IDs sont des entiers** — pas d'IRI a construire, le MCP s'occupe de la conversion.
+
+## IDs verifies (cache — toujours reconfirmer via les outils `list-*`)
+
+| Type | Label | ID |
+|------|-------|----|
+| Statut | A faire | 1 |
+| Statut | En cours | 2 |
+| Statut | Bloque | 3 |
+| Statut | En attente de validation | 4 |
+| Statut | Termine | 5 |
+| User | admin | 2 |
+| User | Tristan | 3 |
+| User | Lucile | 4 |
+| User | Matthieu | 5 |
+| User | matteo | 6 |
+| User | kevin | 7 |
+| User | geoffrey | 8 |
+| User | Julie | 10 |
+| Projet | Lesstime | 5 |
+| Projet | Coltura | 6 |
+| Projet | Inventory | 7 |
+| Projet | Ferme | 8 |
+| Projet | Malio UI | 11 |
+| Projet | SIRH | 12 |
+| Projet | Infrastructure | 13 |
+| Projet | Qualiopi | 14 |
+| Projet | ADMIN | 16 |
+| Projet | Maintenance-LIOT | 17 |
+| Projet | Vaultwarden | 18 |
+| Projet | ednotif-bundle | 19 |
+| Projet | Formation | 20 |
+
+## Process
+
+```dot
+digraph push_flow {
+  rankdir=TB;
+  "1. Lire TICKETS.md" -> "2. Discovery MCP (parallele)";
+  "2. Discovery MCP (parallele)" -> "3. Demander projet cible + config";
+  "3. Demander projet cible + config" -> "4. Mapper priorites P0/P1/P2/P3";
+  "4. Mapper priorites P0/P1/P2/P3" -> "5. create-group si besoin";
+  "5. create-group si besoin" -> "6. create-task pour chaque ticket";
+  "6. create-task pour chaque ticket" -> "7. Resume au user";
+}
+```
+
+### Phase 1 — Lire et parser TICKETS.md
+
+Lire le fichier `TICKETS.md` du repertoire courant. Extraire :
+- La liste des tickets avec leur ID (T-001, T-002, ...)
+- Le titre de chaque ticket
+- La priorite (P0, P1, P2, P3) — derivee de la section dans laquelle se trouve le ticket
+- Le corps complet (Pourquoi + A faire + Fichiers) — sera la description de la tache
+
+**Parsing :**
+- Les sections `## P0`, `## P1`, `## P2`, `## P3` delimitent les groupes de priorite
+- Chaque `### T-XXX -- {Titre}` est un ticket
+- Tout le contenu entre deux `### T-XXX` constitue la description du ticket
+
+### Phase 2 — Discovery MCP (appels paralleles)
+
+Appeler en parallele :
+- `mcp__lesstime__list-projects`
+- `mcp__lesstime__list-users`
+- `mcp__lesstime__list-statuses`
+- `mcp__lesstime__list-priorities`
+- `mcp__lesstime__list-tags`
+
+Apres le choix du projet : `mcp__lesstime__list-groups` avec `projectId`.
+
+### Phase 3 — Demander le projet cible
+
+Presenter a l'utilisateur la liste des projets Lesstime et lui demander :
+1. **Quel projet ?** (`projectId`)
+2. **Quel statut initial ?** (`statusId`, defaut "A faire" = 1)
+3. **Creer des groupes par priorite ?** (ex: "P0 - Urgents", "P1 - Importants")
+4. **Assigner a quelqu'un ?** (`assigneeId`, optionnel)
+5. **Tags a ajouter ?** (`tagIds`, optionnel)
+
+### Phase 4 — Mapper les priorites
+
+Mapper les priorites du TICKETS.md aux priorites Lesstime via `list-priorities` :
+- P0 → priorite la plus haute disponible (ex: "Urgent", "Critical")
+- P1 → priorite haute
+- P2 → priorite moyenne
+- P3 → priorite basse
+
+Si le mapping n'est pas evident, demander confirmation a l'utilisateur.
+
+### Phase 5 — Creer les groupes (si demande)
+
+Si l'utilisateur veut des groupes par priorite et qu'ils n'existent pas, appeler `mcp__lesstime__create-group` pour chacun :
+
+```
+create-group({ projectId: <id>, title: "P0 - Urgents (securite)", color: "#D32F2F" })
+create-group({ projectId: <id>, title: "P1 - Importants",         color: "#F57C00" })
+create-group({ projectId: <id>, title: "P2 - Documentation",      color: "#FBC02D" })
+create-group({ projectId: <id>, title: "P3 - Nice to have",       color: "#388E3C" })
+```
+
+Stocker les `id` retournes pour les reutiliser dans la phase suivante.
+
+### Phase 6 — Creer les taches
+
+Pour chaque ticket dans TICKETS.md :
+1. Construire le titre : `"T-XXX -- {titre}"`
+2. Construire la description : corps complet du ticket (Pourquoi + A faire + Fichiers)
+3. Appeler `mcp__lesstime__create-task` avec `projectId`, `statusId`, `priorityId`, `assigneeId`, `groupId`, `tagIds`
+
+**Gestion d'erreurs :** si un `create-task` echoue, logguer l'erreur et continuer avec le suivant. Reporter toutes les erreurs en fin de batch.
+
+### Phase 7 — Resume
+
+Afficher au user :
+- Nombre de taches creees
+- Repartition par groupe / priorite
+- Lien `http://project.malio-dev.fr/my-tasks` si assignees au user login
+- Taches echouees avec raison
+
+## Mapping par defaut (groupes)
+
+| TICKETS.md | Lesstime Group | Couleur |
+|------------|----------------|---------|
+| P0 | "P0 - Urgents (securite)" | `#D32F2F` |
+| P1 | "P1 - Importants" | `#F57C00` |
+| P2 | "P2 - Documentation" | `#FBC02D` |
+| P3 | "P3 - Nice to have" | `#388E3C` |
+
+## Common Mistakes
+
+- **Bypasser le MCP** : ne jamais retomber sur curl + JWT REST. Si le MCP est down, signaler a l'utilisateur.
+- **Oublier la phase Discovery** : les IDs (statuts, priorites, groupes) peuvent varier — toujours `list-*` avant de creer.
+- **Ne pas demander confirmation** : toujours valider le projet cible et le mapping avec l'utilisateur avant de creer.
+- **Creer sans groupes** : les groupes rendent la vue Lesstime beaucoup plus lisible.
+- **Description trop courte** : inclure le corps complet du ticket, pas juste le titre.
+- **Oublier les groupes existants** : toujours `list-groups` avant `create-group` pour eviter les doublons.
+- **Ne pas gerer les erreurs** : si une tache echoue, continuer avec les suivantes et reporter a la fin.
--- a/commands/ticket-writer.md
+++ b/commands/ticket-writer.md
@@ -0,0 +1,259 @@
+---
+name: ticket-writer
+description: Skill pour rediger des tickets de gestion de projet (features) a partir d'ecrans Figma et du contexte projet. Utiliser ce skill des que l'utilisateur mentionne "ticket", "feature", "tache", "user story", "creer un ticket", "ecrire un ticket", ou demande de transformer un ecran/maquette en ticket de developpement. Aussi declencher quand l'utilisateur uploade des screenshots Figma et veut les convertir en specifications fonctionnelles. Ce skill est concu pour des projets CRM/ERP mais fonctionne pour tout projet.
+---
+
+# Ticket Writer — Redacteur de tickets projet
+
+## Quand utiliser ce skill
+
+- L'utilisateur demande de creer/ecrire un ou plusieurs tickets
+- L'utilisateur fournit des ecrans Figma et veut des tickets
+- L'utilisateur veut transformer une feature en ticket structure
+- L'utilisateur mentionne "ticket", "feature", "tache", "story", "spec"
+
+## Workflow
+
+### 1. Collecter le contexte
+
+**Avant d'ecrire quoi que ce soit**, rassemble ces informations :
+
+- **Ecrans Figma** : L'utilisateur doit fournir des captures d'ecran ou images des maquettes. Si une URL Figma est fournie, utilise `get_design_context` ou `get_screenshot` du MCP Figma pour recuperer le design. Analyse en detail (champs, boutons, navigation, etats, modale, etc.)
+- **CLAUDE.md / Context projet** : Lis le fichier `CLAUDE.md` a la racine du projet s'il existe. Il contient la stack technique, les conventions, les patterns utilises, les dependances, etc.
+- **Infos complementaires** : Demande a l'utilisateur ce qui manque — quel module du CRM/ERP ? Quel role utilisateur ? Quelles regles metier ?
+
+### 2. Analyser les ecrans Figma
+
+Quand tu recois une image Figma, extrais systematiquement :
+
+- **Les elements d'interface** : champs de formulaire, boutons, tableaux, filtres, menus, modales, onglets
+- **Les donnees affichees** : colonnes de tableau, labels, placeholder, valeurs par defaut
+- **Les actions possibles** : CTA, liens, navigation, tri, recherche, pagination
+- **Les etats** : vide, charge, erreur, loading, succes, hover, disabled
+- **Les relations** : liens entre ecrans, flux de navigation
+
+### 3. Rediger le ticket
+
+Utilise **strictement** cette structure pour chaque ticket :
+
+```markdown
+## [Titre court et explicite de la feature]
+
+### Description
+Explication claire en 2-3 phrases de CE QUE fait la feature, POUR QUI, et POURQUOI.
+
+### Ecran(s) de reference
+Reference aux maquettes Figma concernees (nom de l'ecran ou lien).
+
+### Comportement attendu
+Description detaillee du comportement fonctionnel :
+- Quand l'utilisateur fait X, il se passe Y
+- Les donnees affichees sont Z
+- Le formulaire contient les champs : [liste]
+- La validation fait : [regles]
+
+### Regles metier
+- Regle 1
+- Regle 2
+- Conditions specifiques
+
+### Cas limites / Edge cases
+- Que se passe-t-il si la liste est vide ?
+- Que se passe-t-il si l'utilisateur n'a pas les droits ?
+- Que se passe-t-il en cas d'erreur serveur ?
+- Donnees manquantes ou invalides ?
+
+### Tips & Rappels projet
+> Cette section est generee a partir du contexte projet (CLAUDE.md, stack, conventions).
+
+- Rappels sur les composants UI a reutiliser
+- Conventions de nommage ou patterns a respecter
+- Endpoints API existants a utiliser ou a creer
+- Gestion d'etat (store, context, etc.)
+- Contraintes de permissions / roles
+- Points d'attention performance (pagination, lazy loading, etc.)
+- Internationalisation (i18n) si applicable
+- Tests a prevoir
+
+### Criteres d'acceptation
+- [ ] Critere 1
+- [ ] Critere 2
+- [ ] Critere 3
+```
+
+### 4. Les Tips & Rappels — Comment les generer
+
+C'est la section la plus importante. Elle doit **contextualiser** le ticket par rapport au projet reel. Pour la remplir :
+
+1. **Lis CLAUDE.md** : extrais la stack (React, Vue, Next, etc.), l'ORM, le style (Tailwind, CSS Modules), la structure des dossiers
+2. **Identifie les patterns recurrents** : si le projet utilise un pattern pour les formulaires, les tableaux, les modales -> rappelle-le
+3. **Mentionne les composants existants** : "Reutiliser le composant `<DataTable>` deja utilise sur la page Contacts"
+4. **Pointe les API** : "L'endpoint `GET /api/v1/clients` existe deja pour la liste, verifier s'il faut un filtre supplementaire"
+5. **Permissions** : "Verifier les roles — cette page est reservee aux admins et managers"
+6. **Pieges courants** : "Attention au debounce sur la recherche", "Ne pas oublier le loading state sur les actions async"
+
+### 5. Validation et push vers Lesstime
+
+Apres avoir presente les tickets a l'utilisateur, **demande confirmation** avant de pousser :
+
+1. Affiche un resume des tickets rediges (titre + priorite)
+2. Demande : "Veux-tu pousser ces tickets dans Lesstime ?"
+3. Si oui, execute la phase Push (voir ci-dessous)
+
+## Integration Lesstime — Push des tickets
+
+### Connexion via le MCP `lesstime`
+
+**Tout passe par les outils MCP `mcp__lesstime__*`. Pas de curl, pas de JWT a gerer manuellement, pas d'IRI.**
+
+Le MCP expose les operations suivantes :
+
+| Operation | Tool MCP |
+|-----------|----------|
+| Lister projets | `mcp__lesstime__list-projects` |
+| Lister users | `mcp__lesstime__list-users` |
+| Lister statuts (globaux) | `mcp__lesstime__list-statuses` |
+| Lister priorites (globales) | `mcp__lesstime__list-priorities` |
+| Lister efforts (globaux) | `mcp__lesstime__list-efforts` |
+| Lister tags (globaux) | `mcp__lesstime__list-tags` |
+| Lister groupes d'un projet | `mcp__lesstime__list-groups` (`projectId` optionnel) |
+| Creer un groupe | `mcp__lesstime__create-group` |
+| Creer une tache | `mcp__lesstime__create-task` |
+| Mettre a jour une tache | `mcp__lesstime__update-task` |
+
+### Champs `create-task`
+
+| Champ | Type | Description |
+|------|------|-------------|
+| `projectId` | int (required) | Cible du ticket |
+| `title` | string (required) | Titre du ticket |
+| `description` | string | Markdown complet |
+| `statusId` | int | Defaut "A faire" = 1 |
+| `priorityId` | int | Voir `list-priorities` |
+| `effortId` | int | S/M/L — voir `list-efforts` |
+| `assigneeId` | int | User assignee |
+| `collaboratorIds` | int[] | Collaborateurs |
+| `groupId` | int | Groupe (per-project) |
+| `tagIds` | int[] | Tags globaux |
+| `deadline` | string (ISO date) | Optionnel |
+| `scheduledStart` / `scheduledEnd` | string (ISO datetime) | Optionnel |
+
+**Tous les IDs sont des entiers, pas des IRI.** Le MCP gere la conversion en interne. Le piege historique `group` vs `taskGroup` n'existe plus : c'est simplement `groupId`.
+
+### IDs verifies (cache — toujours reconfirmer via les outils `list-*`)
+
+| Type | Label | ID |
+|------|-------|----|
+| Statut | A faire | 1 |
+| Statut | En cours | 2 |
+| Statut | Bloque | 3 |
+| Statut | En attente de validation | 4 |
+| Statut | Termine | 5 |
+| User | admin | 2 |
+| User | Tristan | 3 |
+| User | Lucile | 4 |
+| User | Matthieu | 5 |
+| User | matteo | 6 |
+| User | kevin | 7 |
+| User | geoffrey | 8 |
+| User | Julie | 10 |
+| Projet | Lesstime | 5 |
+| Projet | Coltura | 6 |
+| Projet | Inventory | 7 |
+| Projet | Ferme | 8 |
+| Projet | Malio UI | 11 |
+| Projet | SIRH | 12 |
+| Projet | Infrastructure | 13 |
+| Projet | Qualiopi | 14 |
+| Projet | ADMIN | 16 |
+| Projet | Maintenance-LIOT | 17 |
+| Projet | Vaultwarden | 18 |
+| Projet | ednotif-bundle | 19 |
+| Projet | Formation | 20 |
+
+### Notion de Groupe dans Lesstime
+
+Les **groupes** dans Lesstime organisent visuellement les taches a l'interieur d'un projet (sections/categories sur le board). Ils sont per-projet.
+
+**Utilisation des groupes pour les tickets :**
+
+- **Un groupe par ecran/feature** : pour des tickets issus d'ecrans Figma. Ex: "Repertoire Clients", "Fiche Client", "Commandes Fournisseurs".
+- **Un groupe par module** : si les tickets couvrent un module entier. Ex: "Commerciale - Clients", "Logistique - Reception".
+- **Un groupe par priorite** : pour les reviews de code. Ex: "P0 - Urgents", "P1 - Importants".
+
+**Workflow groupes :**
+
+1. `mcp__lesstime__list-groups` avec `projectId` pour voir les groupes existants
+2. Si un groupe correspondant existe, reutiliser son `id`
+3. Sinon `mcp__lesstime__create-group` avec `projectId`, `title`, et optionnellement `color`
+4. Passer `groupId` a chaque `create-task` pour ranger la tache
+
+**IMPORTANT :** Toujours demander a l'utilisateur comment organiser les groupes avant de creer :
+- Par ecran Figma (recommande pour les features)
+- Par module/section de l'app
+- Par priorite (recommande pour les reviews)
+- Sans groupe (tout a plat)
+
+### Process de push
+
+```dot
+digraph push_flow {
+  rankdir=TB;
+  "1. User valide les tickets" -> "2. Discovery MCP (projects/users/statuses/groups/tags)";
+  "2. Discovery MCP (projects/users/statuses/groups/tags)" -> "3. Demander projet + groupes + assignee + tags";
+  "3. Demander projet + groupes + assignee + tags" -> "4. create-group si besoin";
+  "4. create-group si besoin" -> "5. create-task pour chaque ticket";
+  "5. create-task pour chaque ticket" -> "6. Resume au user + lien my-tasks";
+}
+```
+
+**Phase 1 — Discovery MCP** (appels paralleles) :
+- `mcp__lesstime__list-projects`
+- `mcp__lesstime__list-users`
+- `mcp__lesstime__list-statuses`
+- `mcp__lesstime__list-tags`
+- `mcp__lesstime__list-groups` avec `projectId` cible
+
+**Phase 2 — Demander configuration** :
+1. Quel projet cible (projectId) ?
+2. Comment organiser les groupes ? (par ecran / par module / par priorite / sans)
+3. Statut initial ? (defaut "A faire" = 1)
+4. Assigner a quel user (assigneeId) ?
+5. Tags a ajouter (tagIds) ?
+
+**Phase 3 — Creer les groupes manquants** via `mcp__lesstime__create-group` avec `projectId`, `title` et `color`.
+
+**Phase 4 — Creer les taches** : boucler sur la liste et appeler `mcp__lesstime__create-task` pour chaque ticket avec :
+- `title` : prefixe numero d'ordre `X/N - Titre` (ex: `1/5 - Entites Permission`). L'ordre reflete les dependances.
+- `description` : corps complet du ticket en markdown.
+- `projectId`, `statusId`, `assigneeId`, `groupId`, `tagIds`.
+
+**Phase 5 — Resume** : nombre de taches creees, lien `http://project.malio-dev.fr/my-tasks` si assignee correspond au user login, eventuelles erreurs.
+
+## Principes de redaction
+
+- **Sois precis, pas vague** : "Un champ texte pour le nom du client (max 255 car)" > "Un champ pour le nom"
+- **Decris le QUOI, pas le COMMENT** : Le ticket decrit la feature, pas l'implementation (sauf dans Tips)
+- **Un ticket = une feature atomique** : Si c'est trop gros, decoupe en sous-tickets
+- **Pense aux cas limites** : C'est souvent ce qu'on oublie et qui cree les bugs
+- **Les tips doivent etre actionnables** : Pas de conseil generique, que du concret lie au projet
+
+## Exemple rapide
+
+Si l'utilisateur donne un ecran de liste de contacts avec recherche et filtres :
+
+**Titre** : Liste des contacts avec recherche et filtres
+
+**Comportement** : L'ecran affiche un tableau pagine de contacts. Une barre de recherche en haut permet de filtrer par nom/email. Des filtres dropdown permettent de filtrer par statut (actif/inactif) et par entreprise.
+
+**Tips** : "Le composant `<SearchInput>` du design system gere deja le debounce. Utiliser `useQuery` avec les params de filtre. L'endpoint `GET /api/contacts` supporte deja `?search=&status=&company_id=&page=&limit=`."
+
+## Common Mistakes
+
+- **Bypasser le MCP** : ne jamais retomber sur curl + JWT REST quand le MCP `lesstime` est disponible. Signaler le probleme a l'utilisateur s'il est down.
+- **Oublier la phase Discovery** : les IDs de projets/statuts/groupes/users peuvent varier — toujours `list-*` avant de creer.
+- **Ne pas demander confirmation avant push** : toujours valider les tickets ET la config Lesstime (projet, groupes, assignee, tags) avec l'utilisateur avant de creer.
+- **Creer sans groupes** : les groupes rendent la vue Lesstime beaucoup plus lisible, toujours proposer.
+- **Description trop courte dans Lesstime** : inclure le corps complet du ticket (comportement + regles + edge cases + tips), pas juste le titre.
+- **Oublier les groupes existants** : toujours `list-groups` avant `create-group` pour eviter les doublons.
+- **Ne pas gerer les erreurs** : si un `create-task` echoue, continuer avec les suivants et reporter a la fin.
--- a/global/CLAUDE.md
+++ b/global/CLAUDE.md
@@ -0,0 +1,93 @@
+# CLAUDE.md global — Règles pour tous les projets
+
+## Time Tracking obligatoire
+
+Claude DOIT créer une time entry dans Lesstime au démarrage de chaque tâche de développement, ou sur demande explicite de l'utilisateur ("lance le chrono", "start timer", "track le temps").
+
+### Déclencheurs
+
+1. **Début d'une tâche de dev** : feature, bugfix, refactoring, infra, review
+2. **Demande explicite** : "lance le chrono", "start timer", "track le temps"
+3. **Depuis un ticket Lesstime** : lier directement au `taskId` du ticket référencé
+
+### Méthode — via le MCP `lesstime`
+
+**Toujours passer par les outils MCP `mcp__lesstime__*`, jamais par curl.**
+
+1. **Vérifier qu'il n'y a pas de timer actif** :
+   `mcp__lesstime__list-time-entries` avec `userId: 5`, puis chercher une entrée dont `stoppedAt` est `null`.
+
+2. **Stopper l'éventuel timer actif** avant d'en créer un nouveau :
+   `mcp__lesstime__update-time-entry` avec `id: <activeId>` et `stoppedAt: "<ISO8601 maintenant>"`.
+
+3. **Créer le timer** :
+   ```
+   mcp__lesstime__create-time-entry({
+     userId: 5,
+     startedAt: "<ISO8601 avec timezone, ex 2026-05-13T10:00:00+02:00>",
+     title: "<description courte>",
+     projectId: <projectId>,
+     tagIds: [<tagId>, ...],
+     taskId: <taskId>      // optionnel : si lié à un ticket Lesstime
+   })
+   ```
+   Retient l'`id` retourné.
+
+4. **Stopper le timer en fin de tâche** :
+   ```
+   mcp__lesstime__update-time-entry({
+     id: <timerId>,
+     stoppedAt: "<ISO8601 maintenant>"
+   })
+   ```
+
+### Paramètres obligatoires
+
+- **userId** : TOUJOURS `5` (Matthieu)
+- **startedAt** : ISO 8601 avec timezone (ex: `2026-05-13T14:30:00+02:00`)
+- **title** : description courte de la tâche en cours
+- **projectId** : selon le mapping ci-dessous
+
+### Tags (choisir selon le type de travail)
+
+| Tag | tagId |
+|-----|-------|
+| RDV | 1 |
+| Frontend | 2 |
+| Backend | 3 |
+| UI/UX | 4 |
+| Infra | 5 |
+| Maintenance | 6 |
+| IA | 7 |
+| Réunion | 8 |
+| Gestion projet | 9 |
+| Formation | 10 |
+
+> En cas de doute, appeler `mcp__lesstime__list-tags` pour la liste à jour.
+
+### Mapping projets
+
+| Projet | projectId |
+|--------|-----------|
+| Lesstime | 5 |
+| ERP Liot / Coltura | 6 |
+| Inventory | 7 |
+| Ferme | 8 |
+| Malio UI | 11 |
+| SIRH | 12 |
+| Infrastructure | 13 |
+| Qualiopi | 14 |
+| ADMIN | 16 |
+| Maintenance-LIOT | 17 |
+| Vaultwarden | 18 |
+
+> En cas de doute, appeler `mcp__lesstime__list-projects`.
+
+### Règles
+
+- **Un seul timer actif à la fois** (contrainte DB) — toujours stopper l'actif avant d'en créer un nouveau
+- **Toujours stopper le timer** en fin de tâche ou sur demande
+- **Informer l'utilisateur** quand un timer est lancé/stoppé (id, titre, projet, tags)
+- **Lier au ticket Lesstime** si un ticket est référencé (`taskId`)
+- **Choisir les tags intelligemment** selon le type de travail
+- **Fallback curl interdit** sauf si le MCP `lesstime` est indisponible — dans ce cas, signaler le problème à l'utilisateur
--- a/mcp/.mcp.json.example
+++ b/mcp/.mcp.json.example
@@ -0,0 +1,19 @@
+{
+    "mcpServers": {
+        "lesstime": {
+            "type": "http",
+            "url": "http://project.malio-dev.fr/_mcp",
+            "headers": {
+                "Authorization": "Bearer REPLACE_WITH_YOUR_LESSTIME_API_TOKEN"
+            }
+        },
+        "inventory": {
+            "type": "http",
+            "url": "http://inventory.malio-dev.fr/_mcp",
+            "headers": {
+                "X-Profile-Id": "admin-default-profile",
+                "X-Profile-Password": "REPLACE_WITH_YOUR_INVENTORY_PASSWORD"
+            }
+        }
+    }
+}
--- a/mcp/INSTALL.md
+++ b/mcp/INSTALL.md
@@ -0,0 +1,228 @@
+# Installation MCP Lesstime — Claude Code & Claude Desktop
+
+Guide d'installation du serveur MCP **Lesstime** (Malio) pour exposer les outils de gestion de projet (projets, tâches, time-entries, etc.) directement dans Claude Code et Claude Desktop.
+
+---
+
+## 1. Prérequis
+
+### 1.1 Node.js (npx)
+
+Claude Desktop a besoin de `npx` pour lancer le proxy `mcp-remote`. Vérifier qu'il est installé :
+
+```bash
+which npx
+node --version
+```
+
+Si rien ne sort, installer Node.js :
+- **Debian/Ubuntu** : `sudo apt install nodejs npm`
+- **Via nvm** (recommandé) : voir https://github.com/nvm-sh/nvm
+
+### 1.2 Token API Lesstime
+
+Chaque utilisateur a son **propre token**, lié à ses droits dans l'application. Il n'existe **pas** de token partagé.
+
+1. Aller sur **http://project.malio-dev.fr/profile** (connecté avec son compte Lesstime)
+2. Section **Token API MCP**
+3. Cliquer sur **Régénérer**
+4. **Copier le token affiché immédiatement** (il ne sera plus visible après)
+
+> ⚠️ Le token est un secret personnel. Ne jamais le commiter, ne jamais le partager dans Slack / mail / logs publics. Si tu le compromets, retourne sur le profil et régénère-en un nouveau (l'ancien est invalidé).
+
+---
+
+## 2. Installation Claude Code
+
+Claude Code supporte nativement les transports MCP `http`. C'est la méthode la plus simple.
+
+### 2.1 Éditer le fichier de config
+
+```bash
+# Créer le dossier si besoin
+mkdir -p ~/.claude
+
+# Ouvrir le fichier
+nano ~/.claude/.mcp.json
+```
+
+### 2.2 Coller la configuration
+
+```json
+{
+  "mcpServers": {
+    "lesstime": {
+      "type": "http",
+      "url": "http://project.malio-dev.fr/_mcp",
+      "headers": {
+        "Authorization": "Bearer TON_TOKEN_ICI"
+      }
+    }
+  }
+}
+```
+
+Remplacer `TON_TOKEN_ICI` par le token récupéré à l'étape 1.2.
+
+### 2.3 Redémarrer Claude Code
+
+```bash
+/exit
+```
+
+puis relancer la commande `claude` dans le terminal. Le serveur `lesstime` doit apparaître dans la liste des MCPs connectés.
+
+---
+
+## 3. Installation Claude Desktop
+
+Claude Desktop ne supporte **pas** nativement le transport HTTP — il faut passer par un wrapper local `mcp-remote` (lancé via `npx`).
+
+### 3.1 Localiser le fichier de config
+
+Sur Linux :
+
+```
+~/.config/Claude/claude_desktop_config.json
+```
+
+Sur macOS :
+
+```
+~/Library/Application Support/Claude/claude_desktop_config.json
+```
+
+Sur Windows :
+
+```
+%APPDATA%\Claude\claude_desktop_config.json
+```
+
+### 3.2 Éditer le fichier
+
+```bash
+mkdir -p ~/.config/Claude
+nano ~/.config/Claude/claude_desktop_config.json
+```
+
+### 3.3 Ajouter le bloc `mcpServers`
+
+Si le fichier est **vide** ou inexistant :
+
+```json
+{
+  "mcpServers": {
+    "lesstime": {
+      "command": "npx",
+      "args": [
+        "-y",
+        "mcp-remote",
+        "http://project.malio-dev.fr/_mcp",
+        "--allow-http",
+        "--header",
+        "Authorization: Bearer TON_TOKEN_ICI"
+      ]
+    }
+  }
+}
+```
+
+Si le fichier contient **déjà** d'autres clés (ex. `preferences`), ajouter juste la clé `mcpServers` à côté, sans toucher au reste :
+
+```json
+{
+  "preferences": {
+    "...": "..."
+  },
+  "mcpServers": {
+    "lesstime": {
+      "command": "npx",
+      "args": [
+        "-y",
+        "mcp-remote",
+        "http://project.malio-dev.fr/_mcp",
+        "--allow-http",
+        "--header",
+        "Authorization: Bearer TON_TOKEN_ICI"
+      ]
+    }
+  }
+}
+```
+
+> 💡 Le flag `--allow-http` est **obligatoire** : `mcp-remote` refuse par défaut les URLs non-HTTPS. Comme `project.malio-dev.fr` est en HTTP, sans ce flag tu auras l'erreur : `Error: Non-HTTPS URLs are only allowed for localhost or when --allow-http flag is provided`.
+
+### 3.4 Redémarrer Claude Desktop
+
+Quitter **complètement** l'app (`Ctrl+Q` ou via le menu — fermer la fenêtre ne suffit pas), puis relancer. Le serveur `lesstime` doit apparaître dans la liste des outils MCP disponibles.
+
+---
+
+## 4. Vérification
+
+Une fois Claude (Code ou Desktop) relancé, demander par exemple :
+
+> *« Liste-moi les projets via le MCP lesstime »*
+
+Si tout est bien configuré, Claude appelle l'outil `list-projects` et renvoie la liste des projets actifs (ADMIN, COLTURA, Ferme, Formation, etc.).
+
+### Outils exposés par le MCP Lesstime
+
+Le serveur expose une vingtaine d'outils, regroupés par entité :
+
+- **Projets** : `list-projects`, `get-project`, `create-project`, `update-project`
+- **Tâches** : `list-tasks`, `get-task`, `create-task`, `update-task`, `delete-task`
+- **Récurrences de tâches** : `create-task-recurrence`, `update-task-recurrence`, `delete-task-recurrence`
+- **Time-entries** : `list-time-entries`, `create-time-entry`, `update-time-entry`, `delete-time-entry`
+- **Groupes** : `list-groups`, `create-group`, `update-group`
+- **Référentiels** : `list-clients`, `list-users`, `list-statuses`, `list-priorities`, `list-tags`, `list-efforts`
+
+---
+
+## 5. Troubleshooting
+
+### Erreur : `Non-HTTPS URLs are only allowed for localhost...`
+
+Tu as oublié `--allow-http` dans les `args` de la config Claude Desktop. Voir 3.3.
+
+### Erreur : `command not found: npx`
+
+Node.js n'est pas installé ou pas dans le PATH. Voir 1.1.
+
+### Erreur 401 / 403 dans les logs
+
+Token invalide ou révoqué. Régénérer un nouveau token sur http://project.malio-dev.fr/profile et le remettre dans la config.
+
+### Le serveur ne monte pas après redémarrage
+
+- Vérifier que le JSON est **syntaxiquement valide** (virgule manquante, accolades non fermées). On peut tester avec : `cat ~/.config/Claude/claude_desktop_config.json | jq .`
+- Vérifier les logs Claude Desktop :
+  - Linux : `~/.config/Claude/logs/`
+  - macOS : `~/Library/Logs/Claude/`
+- Vérifier que le serveur Lesstime est joignable : `curl http://project.malio-dev.fr/_mcp` (devrait répondre, même si c'est une erreur 401 sans header).
+
+### Tester `mcp-remote` à la main
+
+```bash
+npx -y mcp-remote http://project.malio-dev.fr/_mcp --allow-http --header "Authorization: Bearer TON_TOKEN_ICI"
+```
+
+Le process doit rester en vie et écouter sur stdin. Ctrl+C pour quitter.
+
+---
+
+## 6. Désinstallation
+
+Pour retirer le MCP : supprimer la clé `"lesstime"` du bloc `mcpServers` dans le fichier de config correspondant, puis redémarrer Claude.
+
+Si plus aucun serveur n'est configuré, on peut laisser un bloc vide :
+
+```json
+{
+  "mcpServers": {}
+}
+```
+
+---
+
+*Dernière mise à jour : 13 mai 2026*
--- a/scripts/install.sh
+++ b/scripts/install.sh
@@ -0,0 +1,64 @@
+#!/usr/bin/env bash
+# install.sh — Symlink claude-config files into ~/.claude/
+#
+# Idempotent : sauvegarde l'existant puis remplace par des symlinks vers ce repo.
+
+set -euo pipefail
+
+REPO_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
+CLAUDE_DIR="${HOME}/.claude"
+BACKUP_DIR="${CLAUDE_DIR}/backup-$(date +%Y%m%d-%H%M%S)"
+
+echo "→ Repo            : ${REPO_DIR}"
+echo "→ Claude config   : ${CLAUDE_DIR}"
+echo
+
+mkdir -p "${CLAUDE_DIR}/commands"
+
+backup_and_link() {
+    local src="$1"
+    local dst="$2"
+    if [[ -e "$dst" && ! -L "$dst" ]]; then
+        mkdir -p "$BACKUP_DIR"
+        echo "  · backup $dst → $BACKUP_DIR/"
+        mv "$dst" "$BACKUP_DIR/"
+    elif [[ -L "$dst" ]]; then
+        rm "$dst"
+    fi
+    ln -s "$src" "$dst"
+    echo "  ✓ link  $dst → $src"
+}
+
+echo "→ Lien : ~/.claude/CLAUDE.md"
+backup_and_link "${REPO_DIR}/global/CLAUDE.md" "${CLAUDE_DIR}/CLAUDE.md"
+
+echo
+echo "→ Liens : ~/.claude/commands/*.md"
+for src in "${REPO_DIR}/commands/"*.md; do
+    name="$(basename "$src")"
+    backup_and_link "$src" "${CLAUDE_DIR}/commands/${name}"
+done
+
+echo
+echo "→ Lien : dev_malio/CLAUDE.md (workspace)"
+WORKSPACE_DIR="$(dirname "${REPO_DIR}")"
+backup_and_link "${REPO_DIR}/workspace/CLAUDE.md" "${WORKSPACE_DIR}/CLAUDE.md"
+
+echo
+if [[ -d "$BACKUP_DIR" ]]; then
+    echo "✓ Backups stockés dans : $BACKUP_DIR"
+fi
+
+echo
+echo "═══════════════════════════════════════════════"
+echo "✅ Symlinks installés."
+echo
+echo "Étape manuelle restante — configurer le MCP Lesstime :"
+echo
+echo "  1. Récupère un token API sur http://project.malio-dev.fr/profile"
+echo "  2. cp ${REPO_DIR}/mcp/.mcp.json.example ${CLAUDE_DIR}/.mcp.json"
+echo "  3. Remplace REPLACE_WITH_YOUR_LESSTIME_API_TOKEN dans ${CLAUDE_DIR}/.mcp.json"
+echo "  4. Redémarre Claude Code (/exit puis claude)"
+echo
+echo "Voir ${REPO_DIR}/mcp/INSTALL.md pour Claude Desktop."
+echo "═══════════════════════════════════════════════"
--- a/scripts/sync.sh
+++ b/scripts/sync.sh
@@ -0,0 +1,42 @@
+#!/usr/bin/env bash
+# sync.sh — Repompe les modifs locales (~/.claude/ + dev_malio/CLAUDE.md) dans le repo
+#
+# À lancer quand tu as édité directement les fichiers actifs hors du repo
+# (ex. modif dans ~/.claude/commands/foo.md) et que tu veux les commiter.
+
+set -euo pipefail
+
+REPO_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
+CLAUDE_DIR="${HOME}/.claude"
+WORKSPACE_DIR="$(dirname "${REPO_DIR}")"
+
+echo "→ Sync depuis :"
+echo "    ${CLAUDE_DIR}/CLAUDE.md      → ${REPO_DIR}/global/"
+echo "    ${CLAUDE_DIR}/commands/*.md  → ${REPO_DIR}/commands/"
+echo "    ${WORKSPACE_DIR}/CLAUDE.md   → ${REPO_DIR}/workspace/"
+echo
+
+copy_if_real() {
+    local src="$1"
+    local dst="$2"
+    if [[ -L "$src" ]]; then
+        echo "  · skip (symlink) $src"
+        return
+    fi
+    if [[ -f "$src" ]]; then
+        cp "$src" "$dst"
+        echo "  ✓ copy $src → $dst"
+    fi
+}
+
+copy_if_real "${CLAUDE_DIR}/CLAUDE.md"            "${REPO_DIR}/global/CLAUDE.md"
+copy_if_real "${WORKSPACE_DIR}/CLAUDE.md"         "${REPO_DIR}/workspace/CLAUDE.md"
+
+for src in "${CLAUDE_DIR}/commands/"*.md; do
+    [[ -e "$src" ]] || continue
+    name="$(basename "$src")"
+    copy_if_real "$src" "${REPO_DIR}/commands/${name}"
+done
+
+echo
+echo "✓ Sync terminé. Lance 'git status' dans ${REPO_DIR}/ pour voir les diffs."
--- a/workspace/CLAUDE.md
+++ b/workspace/CLAUDE.md
@@ -0,0 +1,81 @@
+# CLAUDE.md — dev_malio (workspace racine)
+
+Dossier racine contenant tous les projets MALIO. Chaque projet a son propre `CLAUDE.md` avec les conventions détaillées.
+
+## Projets
+
+| Projet | Description | Stack | Ports (API / Frontend / PG) |
+|--------|-------------|-------|----------------------------|
+| **Inventory** | Gestion d'inventaire industriel (machines, pièces, composants) | Symfony 8 + API Platform 4 + Nuxt 4 | 8081 / 3001 / 5433 |
+| **Lesstime** | Gestion de projet (tâches, time tracking, portail client) | Symfony 8 + API Platform 4 + Nuxt 4 | 8082 / 3002 / 5435 |
+| **SIRH** | Gestion RH (contrats, absences, heures, frais) | Symfony + API Platform + Nuxt 4 | — |
+| **Coltura** | CRM/ERP | Symfony 8 + API Platform 4 + Nuxt 4 | 8083 / 3004 / 5437 |
+| **Ferme** | Gestion exploitation agricole (réceptions, pesées, expéditions, bovins) | Symfony 8 + API Platform 4 + Nuxt 4 | — |
+| **infra-postgres** | Infrastructure PostgreSQL partagée (Docker) | PostgreSQL 16 Alpine | 5432 |
+
+> **sous-app/** — Dossier de sous-projets divers (scripts, outils, anciens prototypes). **Ignorer sauf demande explicite.**
+
+## Stack commune
+
+Tous les projets applicatifs partagent :
+- **Backend** : PHP 8.4, Symfony 8, API Platform 4, Doctrine ORM, PostgreSQL 16
+- **Frontend** : Nuxt 4 (SPA, SSR off), Vue 3 Composition API, TypeScript, Tailwind CSS
+- **Containers** : Docker Compose
+- **CI/CD** : Gitea (organisation MALIO-DEV)
+
+### Différences notables
+
+| | Inventory | Lesstime | Coltura | SIRH | Ferme |
+|---|-----------|----------|---------|------|-------|
+| **Auth** | Session cookies | JWT HTTP-only cookie | JWT HTTP-only cookie | — | JWT (Lexik) |
+| **UI lib** | DaisyUI 5 | @malio/layer-ui | @malio/layer-ui | Tailwind custom | Tailwind + Zod |
+| **Frontend** | Submodule git | Dossier local | Dossier local | Dossier local | Dossier local |
+| **PDF** | — | — | — | — | Dompdf + Twig |
+| **i18n** | Non | @nuxtjs/i18n | @nuxtjs/i18n | Non (UI fixe FR) | @nuxtjs/i18n |
+| **MCP** | Non | Oui (25 tools STDIO+HTTP) | Non | Non | Non |
+
+## Conventions partagées
+
+### Commits (tous les projets)
+```
+<type>(<scope optionnel>) : <message>
+```
+Espace obligatoire autour du `:`. Types : `build`, `chore`, `ci`, `docs`, `feat`, `fix`, `perf`, `refactor`, `revert`, `style`, `test`
+
+### Commandes communes
+```bash
+make start              # Démarrer les containers
+make stop               # Arrêter
+make test               # PHPUnit
+make shell              # Shell dans le container PHP
+make db-reset           # Reset BDD
+make php-cs-fixer-allow-risky  # Linter PHP
+```
+
+### Règles
+- Toujours lire un fichier avant de le modifier
+- Reproduire le style existant du projet
+- Ne jamais committer sans demande explicite
+- Ne jamais force push sans confirmation
+- Ne jamais modifier la config git
+- PostgreSQL : noms de colonnes toujours en **minuscules** dans le SQL brut
+
+## Infrastructure
+
+- **infra-postgres** : instance PostgreSQL partagée sur le port 5432, user unique `malio`
+- Les apps se connectent via `host.docker.internal:5432` ou via leur propre container PG
+- Backups : `pg_dumpall` avec rotation 7 jours (`infra-postgres/backup.sh`)
+
+## Navigation rapide
+
+- Inventory : `Inventory/CLAUDE.md`
+- Lesstime : `Lesstime/CLAUDE.md`
+- SIRH : `SIRH/CLAUDE.md`
+- Coltura : `Coltura/CLAUDE.md`
+- Ferme : pas de CLAUDE.md dédié (à créer si besoin)
+- Infra PG : `infra-postgres/CLAUDE.md`
+
+## Langue
+- UI des apps : français
+- Communication utilisateur : français
+- Code (variables, commentaires) : anglais